Discussioni sul sistema operativo Linux
 

Script di avvio di OpenVPN su Debian 8.2

Void 23 Nov 2015 09:16
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
M_M 23 Nov 2015 10:22
lun, 23 nov 2015, 09:16:36, Void ha scritto:

> ho fatto una piccola modifica a /etc/init.d/openvpn:

A systemd non sei ancora arrivato?

> case "$1" in
> start)
> log_daemon_msg "Starting $DESC"
> . /etc/openvpn/firewall # <== questa aggiunta
> mkdir -p /run/openvpn
>
>
> Ma sembra che non venga eseguito...

La prima cosa che mi verrebbe in mente sarebbe di controllare i permessi
ma immagino che questo tu l'abbia gia` fatto ...
Non riesci a fare delle prove sul terminale cosi` da poter leggere gli
errori che lo script restituisce?

> /etc/openvpn/firewall è un semplice
> script bash che configura iptables.

A parte che collocare un proprio script eseguibile nella directory di
sistema deputata a contenere i ******* 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' ?
Void 23 Nov 2015 11:36
Ciao M_M, lunedì 23 novembre 2015 10:22 hai scritto:


>> ho fatto una piccola modifica a /etc/init.d/openvpn:
> A systemd non sei ancora arrivato?

In effetti no...


>> . /etc/openvpn/firewall # <== questa aggiunta
>> mkdir -p /run/openvpn
>> Ma sembra che non venga eseguito...
> Non riesci a fare delle prove sul terminale cosi` da poter leggere gli
> errori che lo script restituisce?

Lo script non restituisce errori, semplicemente sembra non richiamare
/etc/openvpn/firewall

Al boot viene avviato correttamente OpenVPN, ma non /etc/openvpn/firewall


> A parte che collocare un proprio script eseguibile nella directory di
> sistema deputata a contenere i ******* di configurazione delle
> applicazioni cosi` come creare una directory in /run, non mi sembrano

Hai ragione, ho spostato firewall sotto /usr/local/bin: meglio?

"mkdir -p /run/openvpn" era nello script originale di OpenVPN, quindi lo
lascerei...


> 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' ?

Rinominato in openvpnfirewall.sh


Ciao e grazie,
Void
M_M 23 Nov 2015 12:13
lun, 23 nov 2015, 11:36:26, Void ha scritto:

> Lo script non restituisce errori, semplicemente sembra non richiamare
> /etc/openvpn/firewall
>
> Al boot viene avviato correttamente OpenVPN, ma non /etc/openvpn/firewall

> "mkdir -p /run/openvpn" era nello script originale di OpenVPN, quindi lo
> lascerei...

Eh! direi .. :-) Scusa, ogni tanto prendo abbagli incredibili ..:-/

> 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

?
Andrea D'Amore 23 Nov 2015 14:14
On 2015-11-23 10:36:26 +0000, Void said:

> Lo script non restituisce errori, semplicemente sembra non richiamare
> /etc/openvpn/firewall

Secondo me la domanda si riferiva all'esecuzione proprio di
/etc/openvpn/firewall , se esegui quello che uscita e che valore di
ritorno vedi?

> 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
Void 23 Nov 2015 14:58
Ciao Andrea D'Amore, lunedì 23 novembre 2015 14:14 hai scritto:


> /etc/openvpn/firewall , se esegui quello che uscita e che valore di
> 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
Void 23 Nov 2015 15:04
Ciao M_M, lunedì 23 novembre 2015 12:13 hai scritto:


> 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
Andrea D'Amore 23 Nov 2015 15:38
On 2015-11-23 13:58:39 +0000, Void said:

> Riportocomunque sorgente e uscita:
[…]
> 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
Andrea D'Amore 23 Nov 2015 15:43
On 2015-11-23 14:04:56 +0000, Void said:

> In qualche ritaglio di tempo ho iniziato a guardare systemd e hofatto
> queste modifiche:
> […]
> Insomma, ho aggiunto la direttiva ExecStartPost, ma non trovo un output
> disystemd o di openvpnfirewall.sh che mi faccia pensare che sia
> 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
M_M 23 Nov 2015 15:52
lun, 23 nov 2015, 15:04:56, Void ha scritto:

> Niente. In qualche ritaglio di tempo ho iniziato a guardare systemd e ho
> fatto queste modifiche:

Sei un razzo! :-O
Guarda se per caso piu` in generale ti possono interessare:

http://mmpages.altervista.org/repository/PDF/systemd-for-admins.pdf
e
http://mmpages.altervista.org/repository/anyother/blfs-systemd-units-20150210.tar.bz2

Il primo e` un PDF che ho ricavato da alcune pagine del blog di
Poettering lasciando i contenuti integrali ed aggiungendo di mio solo un
indice iniziale, ed il secondo e` una collezione di servizi per
systemd. Purtroppo non ricordo la fonte ma come puoi leggere nella
licenza sono liberamente ridistribuibili a patto di non alterarne il
contenuto, cosa che naturalmente non ho fatto.
>
> # 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... :-/

e fosse

ExecStartPost=/bin/sh -c "..."

?
Void 23 Nov 2015 16:04
Ciao Andrea D'Amore, lunedì 23 novembre 2015 15:43 hai scritto:


> Ma sullo stesso sistema dove stai usando sysvinit? Mi sembra strano che
> 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
openvpn@openvpn.service
loaded active running OpenVPN connection to openvpn
system-openvpn.slice
loaded active active system-openvpn.slice

# systemctl status openvpn@openvpn.service
? openvpn@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/openvpn@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
Void 23 Nov 2015 18:02
Ciao Andrea D'Amore, lunedì 23 novembre 2015 15:38 hai scritto:


> 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.

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
Max_Adamo 23 Nov 2015 20:28
Il Mon, 23 Nov 2015 16:04:26 +0100, Void ha scritto:

> Ciao Andrea D'Amore, lunedì 23 novembre 2015 15:43 hai scritto:
>
>
>> Ma sullo stesso sistema dove stai usando sysvinit? Mi sembra strano che
>> 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

I comandi che fanno al caso tuo dovrebbero essere questi due:

systemctl status -l openvpn@server.service

journalctl -u openvpn@server.service


se journalctl dovessere essere troppo lungo lo pulisci con:
journalctl --vacuum-time=7days

--
Massimiliano Adamo
Andrea D'Amore 24 Nov 2015 09:37
On 2015-11-24 07:36:26 +0000, Andrea D'Amore said:

>> (c'è un metodo migliore di ps perverificarlo?)
> ps --pid 1

"migliore _di ps_"

Promemoria: leggere meglio i messaggi prima di rispondere.

--
Andrea
M_M 24 Nov 2015 10:55
Andrea D'Amore <anddam+NOSPAM@brapi.net> ha scritto:

> ps --pid 1

Piu` in generale, trovo interessanti anche questi

$ ps xawf -eo pid,user,cgroup,args

$ systemd-cgls
(Recursively show control group contents)
Void 24 Nov 2015 12:01
Ciao M_M, lunedì 23 novembre 2015 15:52 hai scritto:


> http://mmpages.altervista.org/repository/PDF/systemd-for-admins.pdf
> http://mmpages.altervista.org/repository/anyother/blfs-systemd->
units-20150210.tar.bz2

Grazie, il primo da una rapida occhiata sembra ben fatto!


> e fosse
> 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... :-/
Void 24 Nov 2015 12:14
Ciao Max_Adamo, lunedì 23 novembre 2015 20:28 hai scritto:

> I comandi che fanno al caso tuo dovrebbero essere questi due:

# systemctl status -l openvpn@openvpn.service
? openvpn@openvpn.service - OpenVPN connection to openvpn
Loaded: loaded (/lib/systemd/system/openvpn@.service; disabled)
Active: active (running) since lun 2015-11-23 17:59:01 CET; 18h ago
Process: 30298 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: 30316 (openvpn)
CGroup: /system.slice/system-openvpn.slice/openvpn@openvpn.service
??30316 /usr/sbin/openvpn --daemon ovpn-openvpn --status
/run/openvpn/openvpn.status 10 --cd /etc/openvpn --config
/etc/openvpn/openvpn.conf

# journalctl -u openvpn@openvpn.service | grep Masquerade
(no output)

"Masquerade" appare nell'output dello script openvpnfirewall.sh che vorrebbe
essere chiamato all'avvio di OpenVPN.


> se journalctl dovessere essere troppo lungo lo pulisci con:
> journalctl --vacuum-time=7days

Grazie mille! Ma mi sembra un grep di /var/log/syslog, o no?


Ciao,
Void
Max_Adamo 24 Nov 2015 19:00
Il Tue, 24 Nov 2015 12:14:46 +0100, Void ha scritto:

> Ciao Max_Adamo, lunedì 23 novembre 2015 20:28 hai scritto:
>
>> I comandi che fanno al caso tuo dovrebbero essere questi due:
>
> # systemctl status -l openvpn@openvpn.service ? openvpn@openvpn.service
> - OpenVPN connection to openvpn

il thread è un *****aio :) Ti faccio quindi una domanda un po' a caso.
Dopo aver modificato lo script (aggiungendo il postexecscript) hai
lanciato: systemctl daemon-reload
è importante, perché non vede automaticamente le modifiche che fai allo
script di startup.

>> se journalctl dovessere essere troppo lungo lo pulisci con: journalctl
>> --vacuum-time=7days
>
> 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 ******* binari visualizzabili solo con journalctl. In Ubuntu
il syslog c'è sempre.
Il vantaggio è che non devi greppare.



--
Massimiliano Adamo
Max_Adamo 24 Nov 2015 19:21
Il Mon, 23 Nov 2015 15:04:56 +0100, Void ha scritto:

> 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... :-/

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
M_M 25 Nov 2015 01:45
mar, 24 nov 2015, 12:01:30, Void ha scritto:

> Dagli esempi del PDF che mi hai segnalato si direbbe di no, dice chiaramente
> di mettere come argomento il path dello script da eseguire.

Era solo una manovra diversiva :-), tutte le guide indicano di mettere come
argomento il path, solo che a te non va ... solo un paio di giorni fa ho
copiato questo esempio
usr ******* doc/util-linux/examples/fstrim.service
nella directory
/usr/lib/systemd/system/
e linkato in
/etc/systemd/system/multi-user.target.wants/
per utilizzarlo col nuovo SSD che avevo acquistato e naturalmente anche
in quel caso c'era il classico PATH del comando trim.
Io proverei a sostituire lo script sh con un altro che semplicente
scriva qualcosa in un ******* cosi` tagli la testa al toPo e vedi se funge
o no.

> 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
M_M 25 Nov 2015 01:57
Void <void@eh.no> ha scritto:

> 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.
Void 25 Nov 2015 09:43
Ciao Max_Adamo, martedì 24 novembre 2015 19:00 hai scritto:


> il thread è un *****aio :)

In che senso?


> Dopo aver modificato lo script (aggiungendo il postexecscript) hai
> lanciato: systemctl daemon-reload

Sì, ma nel dubbio l'ho rilanciato e... niente: con journalctl -u
openvpn@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?


Ciao e buona giornata,
Void
Void 25 Nov 2015 10:00
Ciao M_M, mercoledì 25 novembre 2015 01:45 hai scritto:


> Io proverei a sostituire lo script sh con un altro che semplicente
> scriva qualcosa in un ******* cosi` tagli la testa al toPo e vedi se funge

ExecStartPost=/bin/sh -c "/usr/bin/touch /tmp/Nebbia"
o
ExecStartPost=/usr/bin/touch /tmp/Nebbia

... il ******* non è stato creato: mi verrebbe da dire che la ExecStartPost non

funzioni con la mia versione (215) di systemd. O forse è il Type=forking che
non va d'accordo con la ExecStartPost?


> How to stay with sysvinit in Debian Jessie :-)

No, ormai il dado è tratto! ;-)


Ciao e grazie,
Void
MaxAdamo 25 Nov 2015 10:25
Il giorno mercoledì 25 novembre 2015 09:43:05 UTC+1, Void ha scritto:
> Ciao Max_Adamo, martedì 24 novembre 2015 19:00 hai scritto:
>
>
>> il thread è un *****aio :)
>
> In che senso?
>

tanti messaggi... difficile trovare il bandolo della matassa :)

>> Dopo aver modificato lo script (aggiungendo il postexecscript) hai
>> lanciato: systemctl daemon-reload
>
> Sì, ma nel dubbio l'ho rilanciato e... niente: con journalctl -u
> openvpn@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...
>

fammi controllare su una macchinetta virtuale...

# apt-cache show systemd|grep Version
Version: 225-1ubuntu9

Allora, io avevo uno script che veniva eseguito alla fine che serviva ad
aggiungere, oltre alle chiavi, la funzionalita' Google OneTimePass:

ExecStartPost=/usr/bin/expect /lib/systemd/system/openvpn_otp.exp


funzionava alla grande.
Puo' essere quel che dici tu (che la tua versione e' vecchia), puo' essere un
bug in quella versione.
Per esempio, su una versione precedente io lanciavo:

systemctl list-unit-files --state enabled

e mi faceva vedere tutti i servizi. Adesso lo hanno sistemato, e si vedono
solo i servizi in stato "enabled".

> Altro dubbio: se provo a usare la line completion con servire opevp[tab]
> [tab] mi viene fuori sia openvpn che openvpn@openvpn: sono equivalenti?

penso di si. Dovrebbe essercene un altro per il client:
openvpn@client.service (mi sembra)
M_M 25 Nov 2015 14:17
mer, 25 nov 2015, 10:00:04, Void ha scritto:

> ExecStartPost=/usr/bin/touch /tmp/Nebbia
>
> ... il ******* non è stato creato: mi verrebbe da dire che la ExecStartPost
non
> funzioni con la mia versione (215) di systemd.

In quest post del 2011 leggo:
https://lists.fedoraproject.org/pipermail/devel/2011-July/153897.html

<cite>
[Unit]
Description=Test ordering + time of Exec

[Service]
Type=oneshot
ExecStartPre=/usr/bin/logger 1
ExecStartPre=/bin/sleep 1
ExecStartPre=/usr/bin/logger 2
ExecStartPre=/bin/sleep 2
ExecStart=/usr/bin/logger 3
ExecStart=/bin/sleep 3
ExecStart=/usr/bin/logger 4
ExecStart=/bin/sleep 4
ExecStartPost=/usr/bin/logger 5
ExecStartPost=/bin/sleep 5
ExecStartPost=/usr/bin/logger 6
ExecStartPost=/bin/sleep 6
ExecStartPost=/usr/bin/logger 7
RemainAfterExit=yes

[root at valhalla system]# grep logger /var/log/messages
Jul 8 11:37:30 valhalla logger: 1
Jul 8 11:37:31 valhalla logger: 2 <-- waited for 1s
Jul 8 11:37:33 valhalla logger: 3 <-- waited for 2s
Jul 8 11:37:36 valhalla logger: 4 <-- waited for 3s
Jul 8 11:37:40 valhalla logger: 5 <-- waited for 4s
Jul 8 11:37:45 valhalla logger: 6 <-- waited for 5s
Jul 8 11:37:51 valhalla logger: 7 <-- waited for 6s
[root at valhalla system]#
</cite>

e Lennart risponde:
https://lists.fedoraproject.org/pipermail/devel/2011-July/153904.html

<cite>
Yes, correct. ExecStartPre= lines are executed in the same order as they
appear in the unit ******* and one by one. There is never more than
one ExecStartPre= process running, and if it is then this would be a bug.
</cite>

per cui direi che il tuo dubbio non sussiste.

In un altro msg ho letto anche questo ma non so se possa tornarti utile
https://lists.fedoraproject.org/pipermail/devel/2011-July/153902.html

<cite>
But if you really need a shell script, then go for it, stick it in
/usr/lib/<yourpackage>/scripts/ or so, and execute that from ExecStart=.
</cite>

Cmq io ora sto usando questa versione
$ systemd --version
systemd 228
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS
+KMOD -IDN

pero` la 215 in testing me la ricordo bene; tutti sapevano che era la
versione deputata ad essere il nuovo gestore della futura Jessie in
Debian Stable e aldila` delle critiche e dubbi, alcuni IMHO
fondatissimi, mi e` sembrato che molti abbiano avuto per lei un occhio
di riguardo, anche nel testing, onde scongiurare quel clima di ansia e
insicurezza che l'idea di un futuro con systemd aveva creato fra i
professionisti come te.
Poi che ne so? magari hai appena scoperto un baco .. ;-)

> O forse è il Type=forking che
> non va d'accordo con la ExecStartPost?

'Type=forking' l'ho gia` trovato scritto in vari servizi: sapessi a che
serve e come funziona effettivamente tenterei di darti una risposta :-D
cosi` come senza sepere ne` leggere ne` scrivere, proverei ad usare lo
stesso servizio ma senza l'@ nel nome.

>> How to stay with sysvinit in Debian Jessie :-)
>
> 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 stu***** 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 .. :-/
MaxAdamo 25 Nov 2015 16:37
Il giorno mercoledì 25 novembre 2015 01:57:24 UTC+1, M_M ha scritto:
> Void <void@eh.no> ha scritto:
>
>> 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.

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.
Void 3 Dic 2015 10:38
Ciao M_M, mercoledì 25 novembre 2015 14:17 hai scritto:


> ExecStartPre=/usr/bin/logger 1
> ExecStartPre=/bin/sleep 1
> [root at valhalla system]# grep logger /var/log/messages

Questo è molto strano: ho provato a modificare il ******* in
/etc/systemd/system/, ma non trovo nulla in messages, quindi il ******* viene
bellamente ignorato...

Ho sacrilegamente provato allora a modificare direttamente il *******
/lib/systemd/system/openvpn@.service, aggiungendo la riga:

ExecStartPost=/usr/local/bin/openvpnfirewall.sh

systemctl daemon-reload && service openvpn@openvpn restart e il tutto ha
funzionato perfettamente! :-)

Rimane da capire perché /etc/systemd/system/openvpn@.service non venga
considerato...


> per cui direi che il tuo dubbio non sussiste.

Sì, in effetti.


> $ systemd --version
> 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


Ciao e buona giornata,
Void

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Discussioni sul sistema operativo Linux | Tutti i gruppi | it.comp.os.linux.sys | Notizie e discussioni linux | Linux Mobile | Servizio di consultazione news.