GNU/Linux >> Linux Esercitazione >  >> Debian

Debian:non sei sicuro di cosa avvii questo file di unità di sistema?

Quindi ho esaminato la configurazione di openvpn sul mio server basato su Debian 9 e ho trovato qualcosa che non riesco a spiegare nei file dell'unità systemd per il demone openvpn. Il demone stesso si avvia e funziona senza problemi, ma non riesco a capire perché... Mi spiego meglio 🙂

Quindi ho installato openvpn e ho una configurazione corretta in /etc/openvpn/server.conf file. Niente di sbagliato finora.

Tuttavia, a quanto pare due unità systemd sono in esecuzione per openvpn, vale a dire openvpn.service e [email protetta] . Quest'ultimo sembra essere quello che effettivamente accetta le connessioni VPN in entrata e simili, il primo non sembra fare molto. Apparentemente funziona solo per avviare quest'ultimo, suppongo...

Verifica di /etc/systemd/system/multi-user.target.wants/ la directory per i file correlati a openvpn mostra solo il file openvpn.service, che di origine è un collegamento simbolico a un file con nome simile in /lib/systemd/system. Il contenuto di questo file è:

# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.

[Unit]
Description=OpenVPN service
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true
WorkingDirectory=/etc/openvpn

[Install]
WantedBy=multi-user.target

Ok bello. Quindi questo funziona solo /bin/true. Quindi cosa avvia esattamente [email protetta] demone? So che il file unit per questo è /lib/systemd/[email protected] ma non riesco a trovare alcun indizio sul mio sistema su cosa esegue esattamente questo file di unità. (Mi aspettavo di trovare un collegamento simbolico per questo in /etc/systemd/system da qualche parte, ma non c'è.) Il contenuto di questo file è:

[Unit]
Description=OpenVPN connection to %i
PartOf=openvpn.service
ReloadPropagatedFrom=openvpn.service
Before=systemd-user-sessions.service
Documentation=man:openvpn(8)
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO

[Service]
PrivateTmp=true
KillMode=mixed
Type=forking
ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10 --cd /etc/openvpn --config /etc/openvpn/%i.conf --writepid /run/openvpn/%i.pid
PIDFile=/run/openvpn/%i.pid
ExecReload=/bin/kill -HUP $MAINPID
WorkingDirectory=/etc/openvpn
ProtectSystem=yes
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_READ_SEARCH CAP_AUDIT_WRITE
LimitNPROC=10
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw

[Install]
WantedBy=multi-user.target

Quindi questo file unitario ha molta più sostanza del file openvpn.service. Ma cosa lo fa scattare? Ho notato il PartOf=openvpn.service parte nel file sopra, ma cercare il significato di questo nelle pagine man non mi ha reso molto più saggio.

Continuerò la ricerca perché voglio solo sapere cosa fa funzionare questa cosa!

Se qualcuno ha qualche idea su come viene eseguito questo specifico file di unità o su cosa lo avvia, per favore fatemelo sapere 🙂

Risposta accettata:

Devi sapere due cose:

  • Ci sono molti altri non documentati directory in cui systemd conserva i file delle unità.
  • Debian e Ubuntu forniscono un generatore in /lib/systemd/system-generators/openvpn-generator che inserisce i collegamenti simbolici "vuole" in una di quelle directory non documentate, una per ogni *.conf file in /etc/openvpn .

I collegamenti simbolici causano openvpn.service comportarsi come un bersaglio e "volere" tutte le varie istanze del modello; come spiega il commento all'inizio dell'unità di servizio.

Nota che Debian e Ubuntu non sono allineati con ciò che le persone di OpenVPN ste stesse fornitura per systemd, che è ciò che viene utilizzato su Arch, CentOS, Fedora e simili. Debian e Ubuntu soppiantano completamente ciò che viene fornito nella stessa OpenVPN per tutto questo, con le proprie cose per systemd. Quindi, perlomeno, fai attenzione quando leggi doco quale sistema operativo quel doco presume tu abbia.

Correlati:Linux – Come passare dalla sessione tty a quella xorg?

La gente di OpenVPN era abituata fornisci un [email protected] unità modello ma nessun generatore né openvpn.service target-as-a-service. Uno doveva abilitare e disabilitare esplicitamente [email protected]name se stessi con i normali meccanismi di sistema per farlo, ed erano "ricercati" direttamente da multi-user.target , piuttosto che da un intermediario target-as-a-service.

Le persone di OpenVPN oggi fornire [email protected] distinto e [email protected] modelli, continua a non fornire un generatore o un openvpn.service target-as-a-service e si aspettano che tu abiliti e disabiliti esplicitamente [email protected]name e [email protected]name te stesso con i normali meccanismi systemd per farlo. Il *.conf i file sono stati spostati da /etc/openvpn e in /etc/openvpn/client e /etc/openvpn/server , anche.

Ulteriori letture

  • Jonathan de Boyne Pollard (2016). "Percorsi di ricerca di sistema mancanti da systemd.unit pagina manuale“. Errata per systemd doco . Risposte frequenti.
  • https://unix.stackexchange.com/a/233581/5132
  • https://unix.stackexchange.com/a/206490/5132
  • "configurazione del servizio systemd". OpenVPN . Arch wiki.
  • "configurazione del servizio systemd". OpenVPN . Wiki di parabola.
  • Assia cristiana (30-12-2016). L'aggiornamento di OpenVPN 2.4.0 richiede l'interazione amministrativa . Novità dell'arco.
  • https://askubuntu.com/a/640026/43344

Debian
  1. Debian – "askfirst" Getty con Systemd ("premi Invio per attivare questa console")?

  2. Correzione `Nome utente non è nel file sudoers. Questo incidente è segnalato su Debian

  3. Come utilizzare Systemd per riavviare un servizio in caso di inattività?

  4. File unità Systemd - WantedBy e After

  5. Il file di servizio esiste ma non viene trovato da systemd

Come installare Vai su Debian 9

Come installare Vai su Debian 10 Linux

Come eseguire uno script all'avvio in Debian 11

Come eseguire lo script della shell come servizio Systemd in Linux

@reboot non funziona in CRON

reindirizzare i log del servizio systemd su file