Newsgroup: it.comp.os.linux.sys
Titolo: Script di avvio di OpenVPN su Debian 8.2

Ciao a tutti,
 
 
ho fatto una piccola modifica a /etc/init.d/openvpn:
 
[...]
case "$1" in
start)
  log_daemon_msg "Starting $DESC"
 
  . /etc/openvpn/firewall          # <== questa aggiunta
 
  mkdir -p /run/openvpn
[...]
 
Ma sembra che non venga eseguito... /etc/openvpn/firewall è un semplice 
script bash che configura iptables.
 
 
Ciao e buona giornata,
  Void

 script bash che configura iptables.
 
A parte che collocare un proprio script eseguibile nella directory di
sistema deputata a contenere i file di configurazione delle
applicazioni cosi` come creare una directory in /run, non mi sembrano
scelte molto corrette, non credi che, anche se non e` strettamente
necessario, non sarebbe stato male attribuire allo script 'firewall' un
nome piu` significativo ed una estensione, come ad esempio,
'iptablesdirective.sh' ?
 
 

 'iptablesdirective.sh' ?
 
Rinominato in openvpnfirewall.sh
 
 
Ciao e grazie,
  Void

 Rinominato in openvpnfirewall.sh
 
Provo ancora a dirne una:
 
e se togliessi il punto, cioe` il comando 'source', lasciando solo sulla
riga
 
/usr/local/bin/openvpnfirewall.sh
 
?

 Al boot viene avviato correttamente OpenVPN, ma non /etc/openvpn/firewall
 
Se metti un messaggio di log in /etc/openvpn/firewall (o il percorso 
che hai aggiornato) poi lo vedi all'avvio del servizio openvpn?
Puoi mostrare il contenuto di /etc/openvpn/firewall?
 
-- 
Andrea
 

 ritorno vedi?
 
Quello che era /etc/openvpn/firewall e che ho poi rinominato funziona 
correttamente. Ne ho la conferma da almeno una manciata di persone che si 
collegano correttamente in VPN dopo che averlo lanciato a mano. Riporto 
comunque sorgente e uscita:
 
 
# cat /usr/local/bin/openvpnfirewall.sh    
#!/bin/sh 
 
echo "Rimozione di tutte le regole presenti sul firewall" 
iptables -F INPUT 
iptables -F OUTPUT 
iptables -F FORWARD 
iptables -t nat -F 
 
echo "Impostazioni delle regole predefinite" 
iptables -P INPUT ACCEPT 
iptables -P OUTPUT ACCEPT 
iptables -P FORWARD DROP 
 
echo "Attivazione delle regole per gruppi" 
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT 
 
iptables -A FORWARD -i tun0 -o eth0 -s 
192.168.17.0/25
 -d 
192.168.0.0/20
 -j 
ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -s 
192.168.0.0/20
 -d 
192.168.17.0/25
 -j 
ACCEPT
 
iptables -A FORWARD -i tun0 -o eth0 -s 192.168.17.129 -d 192.168.11.122 -j 
ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -s 192.168.11.122 -d 192.168.17.129 -j 
ACCEPT
 
iptables -A FORWARD -i tun0 -o eth0 -s 192.168.17.133 -d 192.168.10.17 -j 
ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -s 192.168.10.17 -d 192.168.17.133 -j 
ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -s 192.168.17.133 -d 192.168.10.44 -j 
ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -s 192.168.10.44 -d 192.168.17.133 -j 
ACCEPT
 
iptables -A FORWARD -i tun0 -o eth0 -s 192.168.17.137 -d 192.168.10.19 -j 
ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -s 192.168.10.19 -d 192.168.17.137 -j 
ACCEPT
 
iptables -A FORWARD -i tun0 -o eth0 -s 
192.168.17.0/24
 -d 
10.209.12.0/24
 -j 
ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -s 
192.168.17.0/24
 -d 
10.209.32.0/24
 -j 
ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -s 
192.168.17.0/24
 -d 
10.209.40.0/24
 -j 
ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -s 
192.168.17.0/24
 -d 
172.16.0.0/18
 -j 
ACCEPT
iptables -A FORWARD -j LOG 
 
echo "Attivazione del Masquerade" 
iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
 
 
# /usr/local/bin/openvpnfirewall.sh  
Rimozione di tutte le regole presenti sul firewall 
Impostazioni delle regole predefinite 
Attivazione delle regole per gruppi 
Attivazione del Masquerade 
 
 
Ciao e grazie,
  Void

 e se togliessi il punto, cioe` il comando 'source', lasciando solo sulla
 
Niente. In qualche ritaglio di tempo ho iniziato a guardare systemd e ho 
fatto queste modifiche:
 
# cd /lib/systemd/system
# cp openvpn@.service /etc/systemd/system/
# cd /etc/systemd/system/
# vi openvpn@.service 
# cat openvpn@.service 
[Unit]
Description=OpenVPN connection to %i
PartOf=openvpn.service
ReloadPropagatedFrom=openvpn.service
 
[Service]
Type=forking
ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 
10 --cd /etc/openvpn --config /etc/openvpn/%i.conf
ExecStartPost=/usr/local/bin/openvpnfirewall.sh
ExecReload=/bin/kill -HUP $MAINPID
WorkingDirectory=/etc/openvpn
 
[Install]
WantedBy=multi-user.target
# systemctl reenable openvpn@.service
# service openvpn restart
 
Insomma, ho aggiunto la direttiva ExecStartPost, ma non trovo un output di 
systemd o di openvpnfirewall.sh che mi faccia pensare che sia stato 
eseguito... :-/
 
 
Ciao e grazie,
  Void

 iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
 
Questo. Sospettavo qualche comando magari non nel PATH di uno script 
init.d ma /sbin dovrebbe esserci (ho provato copiando e skeleton, 
stampando di PATH ed eseguendo lo script risultante con invoke-rc.d).
 
La risposta all'altra domanda che ho posto forse è più indicativa.
Tu hai uno script A che interpreta uno script B, e dall'esterno vedi 
che apparentemente A viene eseguito e B no. Metti quattro printf, due 
in A subito prima e subito dopo l'interpretazione e due in B all'inizio 
e alla fine, e dovresti vedere dove è il problema.
 
-- 
Andrea
 

 statoeseguito... :-/
 
Ma sullo stesso sistema dove stai usando sysvinit? Mi sembra strano che 
tu faccia girare init/upstart e systemd.
 
Lo stato (eventualmente anche messaggi di output) lo controlli con il 
comando "status" di systemctl, puoi elencare le unit caricate con 
"list-units".
 
-- 
Andrea
 

 eseguito... :-/
 
e fosse
 
ExecStartPost=/bin/sh -c "..."
 
?

 tu faccia girare init/upstart e systemd.
 
In effetti sembrerebbe girare solo systemd (c'è un metodo migliore di ps per 
verificarlo?) e questo spiegherebbe perché le modifiche a 
/etc/init.d/openvpn non sortissero effetti...
 
# systemctl list-units | grep openvpn
openvpn.service
loaded active exited    OpenVPN service
ope...@openvpn.service
loaded active running   OpenVPN connection to openvpn
system-openvpn.slice
loaded active active    system-openvpn.slice
 
# systemctl status ope...@openvpn.service
? ope...@openvpn.service - OpenVPN connection to openvpn
   Loaded: loaded (/lib/systemd/system/openvpn@.service; disabled)
   Active: active (running) since lun 2015-11-23 14:51:08 CET; 1h 6min ago
  Process: 18601 ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status 
/run/openvpn/%i.status 10 --cd /etc/openvpn --config /etc/openvpn/%i.conf 
(code=exited, status=0/SUCCESS)
 Main PID: 18613 (openvpn)
   CGroup: /system.slice/system-openvpn.slice/ope...@openvpn.service
           ??18613 /usr/sbin/openvpn --daemon ovpn-openvpn --status 
/run/openvpn/openvpn.status 10 --cd /etc/openvpn --config 
/etc/openvpn/openvpn.conf
 
 
Ciao,
  Void

 e alla fine, e dovresti vedere dove è il problema.
 
Sì, alla fine sembra che anche il chiamante A non venga eseguito e non vedo 
nessuna delle 4 print. Forse allora davvero init.d è un retaggio del passato 
e la macchina sta facendo tutto con systemd. Faccio altre prove appena 
possibile.
 
 
Ciao e grazie,
  Void
 

 # systemctl list-units | grep openvpn openvpn.service loaded active
 
I comandi che fanno al caso tuo dovrebbero essere questi due: 
 
systemctl status -l ope...@server.service
 
journalctl -u ope...@server.service
 
 
se journalctl dovessere essere troppo lungo lo pulisci con:
journalctl --vacuum-time=7days
 
-- 
Massimiliano Adamo

 ps perverificarlo?)
 
    ps --pid 1
 
oppure
 
    cat /proc/1/comm
 
 
-- 
Andrea
 

     ps --pid 1
 
"migliore _di ps_"
 
Promemoria: leggere meglio i messaggi prima di rispondere.
 
-- 
Andrea
 

     ps --pid 1
 
Piu` in generale, trovo interessanti anche questi
 
$ ps xawf -eo pid,user,cgroup,args
 
$ systemd-cgls
(Recursively show control group contents)
 
 
 

 ExecStartPost=/bin/sh -c "..."
 
Dagli esempi del PDF che mi hai segnalato si direbbe di no, dice chiaramente 
di mettere come argomento il path dello script da eseguire.
 
 
Ciao e grazie,
  Void, che oggi teme di avere poco tempo per systemd... :-/

 journalctl --vacuum-time=7days
 
Grazie mille! Ma mi sembra un grep di /var/log/syslog, o no?
 
 
Ciao,
  Void

     ps --pid 1
 
# ps --pid 1
  PID TTY          TIME CMD
    1 ?        00:00:05 systemd
# cat /proc/1/comm
systemd
 
Grazie, almeno abbiamo appurato cosa gira! :-)
 
Tra l'altro, non so se può essere la causa di problemi, sulla macchina gira 
anche xinetd, richiesto da check-mk-agent...
 
 
Ciao,
  Void

 Grazie mille! Ma mi sembra un grep di /var/log/syslog, o no?
 
yes/no/maybe ... evito di dire castronerie su debian, perché non so bene 
come lo hanno implementato. In Arch Linux syslog è scomparso del tutto e 
ci sono solo dei file binari visualizzabili solo con journalctl. In Ubuntu 
il syslog c'è sempre. 
Il vantaggio è che non devi greppare. 
 
 
 
-- 
Massimiliano Adamo

 eseguito... :-/
 
rifaccio nuovamente la domanda che ti ho fatto nell'altro messaggio.
Dopo aver fatto la modifica hai lanciato: systemctl daemon-reload ?
Devi farlo. 
systemd è stupendo (IMO), ma bisogna attrezzarsi per capire che cavolo fa 
e come cavolo lo fa :) 
 
-- 
Massimiliano Adamo

   Void, che oggi teme di avere poco tempo per systemd... :-/
 
How to stay with sysvinit in Debian Jessie :-)
http://people.skolelinux.org/pere/blog/How_to_stay_with_sysvinit_in_Debian_Jessie.html
 
Praticamente rimuovi systemd-sysv ed installi sysvinit-core

 Grazie mille! Ma mi sembra un grep di /var/log/syslog, o no?
 
Si`. di default syslog e` installato sulla Debian ed il journal non e` 
persistente. Nel cap. XVII pag. 61 del PDF che ti ho indicato c'e` spiegato come 
renderlo persistente e a quel punto, se vuoi, rimuovere rsyslog.
 
 

 lanciato: systemctl daemon-reload
 
Sì, ma nel dubbio l'ho rilanciato e... niente: con journalctl -u 
ope...@openvpn.service non vedo l'output dello script che ho messo in 
ExecStartPost=/usr/local/bin/openvpnfirewall.sh. Mi viene un dubbio: mi pare 
che alcune opzioni siano arrivate solo con la versione 218 (vado a memoria) 
di systemd, mentre io ho la 215...
 
Chissà se posso mettere più ExecStart, a questo punto? No, sembra di no...
 
Altro dubbio: se provo a usare la line completion con servire opevp[tab]
[tab] mi viene fuori sia openvpn che openvpn@openvpn: sono equivalenti?


 How to stay with sysvinit in Debian Jessie :-)
 
No, ormai il dado è tratto! ;-)
 
 
Ciao e grazie,
  Void

 [tab] mi viene fuori sia openvpn che openvpn@openvpn: sono equivalenti?
 
penso di si. Dovrebbe essercene un altro per il client: 
ope...@client.service (mi sembra)

 No, ormai il dado è tratto! ;-)
 
E` il rilancio che mi "preoccupava" e cercavo di suggerirti una pausa di
riflessione perche`mi sei sembrato una persona piuttosto oberata di
lavoro, mentre a mio avviso la migrazione a systemd richiede un attimo
di studio su come realizzarla; ad esempio anche se systemd garantisce
una certa retrocompatibilita` con sysv, io penso sia meglio adeguare
anche tutti i propri vecchi script al nuovo standard.
Fortunatamente in systemd ce la si puo` cavare sempre al piu` con una
manciata di righe, ma cmq del tempo te ne prende, e se tu sei gia`
occupatissimo mi sembrava di vederla un po' dura .. :-/
 


ad ogni modo, il seguente:
script-security 2
up /my/script
down /my/other-script
 
funziona solo client side, o funziona anche server side? 
Qualcosa mi dice che "tentar non nuoce" :) 
Al massimo non funziona.

 systemd 228
 
Mah, io ho un po' di confusione:
 
# dpkg -l init systemd xinetd | grep ii | cut -c1-76
ii  init           1.22          amd64        System-V-like init utilities -
ii  systemd        215-17+deb8u2 amd64        system and service manager
ii  xinetd         1:2.3.15-3    amd64        replacement for inetd with man
