PicciHud/mywiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

rearranged the repository structure

Browse Source
This commit is contained in:
piccihud
2023-05-17 15:24:22 +02:00
parent c203b8305d
commit a38bd885c5
220 changed files with 20 additions and 1231 deletions
Download Patch File Download Diff File Expand all files Collapse all files

147
linux/systemd/systemd.md Normal file
View File

@@ -0,0 +1,147 @@
# Systemd
## Sistema di init
**init**, in un sistema operativo Unix, è il primo processo che il kernel manda in esecuzione dopo che il computer ha terminato la fase di bootstrap. Esso ha il compito di
portare il sistema in uno stato operativo, avviando i programmi e servizi necessari.
Dato che init è sempre il primo processo eseguito, esso ha tipicamente il `PID 1`.
## Systemd
systemd è una suite di demoni, librerie e utilità di amministrazione progettate con lo scopo di centralizzare la gestione e la configurazione dei sistemi operativi Unix-like.
Nacque per Red Hat Linux e fu adottato poi in Debian con lo scopo di rimpiazzare l'init discendente dallo Unix System V
Le attività di systemd sono organizzate in `unità`. Le unità più comuni sono servizi (**.service**), punti di montaggio (**.mount**), device (**.device**), socket (**.socket**)
o temporizzatori (**.timer**). Per esempio l'avvio del demone SSH viene fatto dall'unità ssh.service.
systemd è preinstallato in molte distribuzioni GNU/Linux. Per verificarne la presenza digitare in un terminale:
```bash
ps --no-headers -o comm 1
```
### Uso base
systemctl è lo strumento principale utilizzato per l'introspezione e il controllo dello stato dei servizi gestiti da systemd.
Si può, ad esempio, usare systemctl per abilitare o disabilitare servizi in modo permanente o solo per la sessione corrente.
### Ottenere informazioni sullo stato del sistema
- Visualizzare lo stato del sistema:
`systemctl status`
- Elencare le unità che hanno fallito:
`systemctl --failed`
- Elencare i file di unità installati:
`systemctl list-unit-files`
- Elencare tutte le unità:
`systemctl list-units --all`
### Gestire servizi
- Elencare tutti i servizi in esecuzione:
`systemctl`
- Avviare il servizio "<nome_servizio>.service" immediatamente:
`systemctl start <nome_servizio>.service`
- Fermare il servizio "<nome_servizio>.service" immediatamente:
`systemctl stop <nome_servizio>.service`
- Riavviare il servizio "<nome_servizio>.service" immediatamente:
`systemctl restart <nome_servizio>.service`
- Per ricaricare la configurazione di un servizio digitare:
`systemctl reload <nome_servizio>.service`
- Abilitare l'avvio di "<nome_servizio>.service" all'avvio di sistema:
`systemctl enable <nome_servizio>.service`
- Disabilitare l'avvio di "<nome_servizio>.service" all'avvio di sistema:
`systemctl disable <nome_servizio>.service`
- Per rendere un servizio non avviabile sia manualmente che automaticamente digitare:
`systemctl mask <nome_servizio>.service`
- Per riabilitare un servizio a essere avviabile manualmente o automaticamente digitare:
`systemctl unmask <nome_servizio>.service`
#### Controllo
- Visualizzare lo stato del servizio "<nome_servizio>.service":
`systemctl status <nome_servizio>.service`
- Per verificare se un determinato servizio è attivo digitare:
`systemctl is-active <nome_servizio>.service`
-Per verificare se un determinato servizio viene attivato all'avvio del sistema digitare:
`systemctl is-enabled <nome_servizio>.service`
- Per verificare se un servizio ha fallito l'avvio digitare:
`systemctl is-failed <nome_servizio>.service`
#### Informazioni
- Per elencare tutti i servizi disponibili digitare:
`systemctl list-units --type=service`
- Per elencare i servizi attivi nel sistema digitare:
`systemctl list-units --type=service --state=running`
#### Un esempio con apache2
```bash
sudo systemctl start apache2
sudo systemctl stop apache2
systemctl status apache2
sudo systemctl enable apache2
sudo systemctl disable apache2
```
Abilitare un servizio all’avvio implica che systemctl crearà un link simbolico allo stesso nella cartella utilizzata da Systemd per l’autostart, di solito `/etc/systemd/system/`.
Viceversa disabilitare il servizio rimuoverà questo link.
### Creare o alterare servizi
Le unità sono definite da singoli file di configurazione chiamati file di unità. I file di unità forniti da Debian sono posizionati nella directory `/lib/systemd/system`.
Se esiste un file di unità locale con un nome identico nella directory `/etc/systemd/system`, questo avrà la precedenza e systemd ignorerà il file nella directory /lib/systemd/system.
Gli amministratori di sistema dovrebbero mettere i file di unità nuovi o quelli altamente personalizzati in /etc/systemd/system.
```bash
sudo systemctl edit <nome_servizio>.service
```
## Collegamenti
- [https://www.lffl.org/2020/03/guida-systemctl-systemd.html](https://www.lffl.org/2020/03/guida-systemctl-systemd.html)
- [https://wiki.ubuntu-it.org/AmministrazioneSistema/Systemd](https://wiki.ubuntu-it.org/AmministrazioneSistema/Systemd)
- [https://wiki.debian.org/it/systemd](https://wiki.debian.org/it/systemd)
- [https://wiki.archlinux.org/title/Systemd_(Italiano)/User_(Italiano)](https://wiki.archlinux.org/title/Systemd_(Italiano)/User_(Italiano))
- [https://it.wikipedia.org/wiki/Boot](https://it.wikipedia.org/wiki/Boot)
- [https://it.wikipedia.org/wiki/Systemd](https://it.wikipedia.org/wiki/Systemd)

252
linux/systemd/systemdservices.md Normal file
View File

@@ -0,0 +1,252 @@
---
class: post
title: Systemd e gestione dei servizi
date: "2023-04-16"
layout: post
author: piccihud
published: false
tags:
- guide
---
# Systemd e gestione dei servizi
Systemd rappresenta uno degli strumenti di gestione centralizzata di init, demoni, librerie ed amministrazione del sistema più completo.
Offre diversi tool per la gestione del sistema, come:
- systemctl
- journalctl
- systemd-analyze
- loginctl
## systemctl
systemctl avvia i servizi e ha alcune funzioni per la gestione della sessione.
### I servizi
I servizi, o demoni di sistema, sono software che per lo più girano di sottofondo generando e gestendo l’ambiente in cui l’utente e i programmi operano.
Tutti i servizi si trovano in `/etc/systemd` e `/lib/systemd`.
#### Attivare e disattivare i servizi
Un servizio attivato è un servizio che si avvia con il sistema, per farlo:
```bash
systemctl enable nomeservizio
```
Può essere poi disattivato con:
```bash
systemctl disable nomeservizio
```
Una delle opzioni più utili è sicuramente enable --now:
```bash
systemctl enable --now nomeservizio
```
che esegue enable e start in contemporanea
#### Riepilogo
| Comando | Spiegazione |
|---------|-------------|
systemctl enable <servizio>|Abilita il servizio all’avvio, che viene quindi attivato ogni qualvolta accedete
systemctl start <servizio>|Avvia immediatamente il servizio
systemctl restart <servizio>|Spegne e riavvia il servizio
systemctl stop <servizio>|Spegne il servizio, contrario di start
systemctl disable <servizio>|Disabilita il servizio, contrario di enable
systemctl status <servizio>|Controlla lo stato del servizio, se è attivo, in errore o spento
systemctl poweroff|Spegne il sistema
systemctl reboot|Riavvia il sistema
systemctl suspend|Sospende il sistema
systemctl reboot --firmware-setup|È addirittura possibile riavviare direttamente su interfaccia EFI se disponibile:
### Scrivere un servizio
I servizi si dividono in tre sezioni:
- `Unit`, descrive il servizio, il modo in cui è avviato, i processi che dipendono da esso o quelli da cui dipende, il modo in cui si relaziona al sistema;
- `Service`, descrive il comando o lo script eseguito, come viene eseguito, quante volte e quando considerarlo un fallimento;
- `Install`, ulteriori specifiche su come il sistema deve abilitare il servizio, eventuali alias con cui collegarlo, quante unità attiva.
Ogni sezione ha diverse opzioni disponibili.
È possibile scrivere un servizio Systemd creando nella cartella `/etc/systemd/system` un file di estensione `.service`
Questa la struttura base di un servizio:
```bash
[Unit]
Description=una descrizione del servizio
After=lista di servizi che vengono eseguiti prima
Before=lista di servizi che vengono dopo
Condition....=se non verificata, il servizio non viene eseguito. Esistono vari tipi di condition, come ConditionHost, ConditionPathExist..etc
[Service]
Type=indica il tipo di servizio: simple, exec, forking, oneshot, dbus, notify o idle
RemainAfterExit=true o false, indica se il processo deve rimanere in esecuzione anche dopo l'avvio del sistema
ExecStart=lo script o il comando da eseguire. Lo script indicato nella sezione ExecStart deve essere eseguibile
ExecStop=qui indicare ciò che viene eseguito quando viene terminato il processo
Restart=indica se il processo deve essere eseguito più volte, ad esempio al successo, al fallimento, sempre... viene configurato con un timer, coi valori: no, on-success, on-failure, on-abnormal, on-abort, always...
RestartSec=tempo prima del restart del servizio
TimeoutStartSec=indica quanto tempo deve bloccare l'avvio prima di dire che un servizio è o non è fallito
TimeoutStopSec=idem di sopra, ma in chiusura
Standard....=StandardOutput e StandardError, cioè dove vengono stampati errori o messaggi. I valori possono essere: journal, tty, journal+console, file:/path/per/file (sarà cancellato se esiste), append:/path/per/file (aggiunge alla fine)
[Install]
WantedBy=indica la cartella in cui viene collegato il servizio
```
#### Servizio di avvio
Un esempio di un servizio di avvio generico.
Innanzitutto scrivere uno script che deve essere avviato ogni accensione, che sarà avviato con privilegi elevati (root).
Poniamo ad esempio che il file sia: `/etc/avvio`
È fondamentale che lo script sia eseguibile.
Quindi creare il file `/etc/systemd/system/avvio.service`
```systemd
[Unit]
Description=Esegue /etc/avvio
ConditionPathExists=/etc/avvio
[Service]
Type=oneshot
ExecStart=/etc/avvio
StandardOutput=journal
[Install]
WantedBy=multi-user.target
```
La sezione `[Unit]` fornisce una descrizione del servizio attraverso l’opzione `Description` e poi verifica che lo script da eseguire esista tramite `ConditionPathExist`.
La parte `[Service]` informa che il servizio è oneshot. I servizi oneshot sono servizi di sistema che svolgono un'attività specifica e terminano al termine di tale attività.
In altre parole, il processo è di breve durata. Lo `StandardOutput` dice dove saranno stampati i vari log. Nel caso dell'esempio nel journal.
La parte `[Install]` dice che il file verrà eseguito nella cartella `multi-user` tramite opzione `WantedBy`.
Nei sistemi GNU/Linux l’avvio è sottoposto a più fasi, dette livelli (**run level**):
- livello 0: è il livello di spegnimento (poweroff), raggiunto quando il pc viene spento;
- livello 1: livello di emergenza (rescue), è intermedio tra l’avvio del sistema hardware e quello software;
- da livello 2 a livello 4: si parla di livelli utente (multi-user);
- livello 5: è il livello grafico (graphic), usato dal display manager;
- livello 6: è il livello di spegnimento o riavvio (reboot), in cui il sistema torna a livello 0
Il sistema dei livelli è stato ridefinito su systemd con i `target`. [Qui](https://www.freedesktop.org/software/systemd/man/systemd.special.html) maggiori informazioni sui target.
A meno che non sia uno script abbastanza importante, è difficile vedere services con target diversi da multi-user.target.
È ora possibile avvire il servizio e abilitarlo all'avvio coi comandi:
```bash
systemctl start avvio.servizio
systemctl enable avvio.service
```
#### systemd timer
Ad ogni service si può associare un `timer`. Questa pratica potrebbe essere utile nel caso si volesse che un determinato script venisse ripetuto ogni settimana oppure ogni minuto piuttosto che ad ogni accesso.
Associare al precedente servizio `avvio.service` un `avvio.timer` nella cartella `/etc/systemd/system`:
```bash
[Unit]
Description=un timer associato ad avvio.service
[Timer]
Unit=avvio.service
OnUnitActiveSec=1us
OnUnitInactiveSec=10s
[Install]
WantedBy=multi-user.target
```
Nella sezione `Timer` sono da inserire alcune informazioni: che unità far partire, quando il timer deve partire, ogni quanto il comando deve ripetersi.
```txt
Unit=l'unità da avviare
OnActiveSec=quanti secondi dopo l’avvio del timer
OnBootSec=quanti secondi dopo l’avvio del pc
OnStartupSec=quanti secondi dopo l’avvio di systemd (poco usato)
OnUnitActiveSec=quanti secondi dopo l’attivazione dell’unità di riferimento
OnUnitInactiveSec=quanti secondi dopo che l’unità diventa inattiva
```
Le unità di tempo impostabili sono:
- us =microsecondo
- ms =millisecondo
- s =sec
- m =minuto
- h =ora
- d =giorno
- w =settimana
- M =mese
- y =anno
I tempi di attivazione, se combinati, danno vita al tempo di ripetizione.
Supponiamo di avere OnActiveSec=1us e OnUnitInactiveSec=10s, il timer una volta dato lo start da systemd si avvierebbe subito (1 microsecondo ),
terminerebbe il job, e l’unità diventerebbe inattiva attivando il timer da 10s.
È possibile avviare il timer in un giorno specifico con l'opzione:
```bash
OnCalendar=valore in formato yyyy-MM-gg hh:mm:ss o simili
```
Per avviare un servizio tramite un timer, non va avviato il servizio, ma il timer stesso tramite il comando:
```bash
systemctl start avvio.timer
```
#### Riavvio automatico di un servizio
```bash
/etc/systemd/system/daemon.service
[Unit]
Description=Your Daemon Name
StartLimitIntervalSec=300
StartLimitBurst=5
[Service]
ExecStart=/path/to/executable
Restart=on-failure
RestartSec=1s
[Install]
WantedBy=multi-user.target
```
L'opzione `Restart` è impostata su `on-failure` così che il servizio venga riavviato se dovesse uscire con un *exit code* diverso da zero, oppure se terminato.
L'opzione `RestartSec` configura il tempo necessario da attendere prima di riavviare il servizio.
Altre due opzioni utili sono `StartLimitIntervalSec` e `StartLimitBurst`. Entrambe sono utili per la configurazione di quando Systemd dovrebbe smettere di provare a riavviare un servizio.
Dopo aver aggiornato il file dell'unità di sistema, assicurarsi di eseguire il comando seguente affinché le modifiche abbiano effetto:
```bash
sudo systemctl daemon-reload
```
## Collegamenti
- [https://linuxhub.it/articles/howto-usare-e-comprendere-systemd/](https://linuxhub.it/articles/howto-usare-e-comprendere-systemd/)
- [https://linuxhub.it/articles/howto-creare-un-servizio-o-un-timer-di-systemd/](https://linuxhub.it/articles/howto-creare-un-servizio-o-un-timer-di-systemd/)
- [https://freshman.tech/snippets/linux/auto-restart-systemd-service/](https://freshman.tech/snippets/linux/auto-restart-systemd-service/)
- [https://www.baeldung.com/linux/systemd-service-periodic-restart](https://www.baeldung.com/linux/systemd-service-periodic-restart)

115
linux/systemd/unattended-upgrades.md Normal file
View File

@@ -0,0 +1,115 @@
# unattended-upgrades
Il pacchetto `unattended-upgrades` viene utilizzato per installare automaticamente i pacchetti aggiornati e può essere configurato per installare automaticamente solo gli aggiornamenti di sicurezza.
Può essere installarlo con il seguente comando:
```bash
sudo apt install unattended-upgrades
```
Abilitare quindi il servizio:
```bash
sudo systemctl enable --now unattended-upgrades.service
Synchronizing state of unattended-upgrades.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable unattended-upgrades
sudo systemctl status unattended-upgrades.service
● unattended-upgrades.service - Unattended Upgrades Shutdown
Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; preset: enabled)
Active: active (running) since Sat 2023-04-15 19:21:21 CEST; 4s ago
Docs: man:unattended-upgrade(8)
Main PID: 33300 (unattended-upgr)
Tasks: 2 (limit: 16595)
Memory: 11.8M
CPU: 59ms
CGroup: /system.slice/unattended-upgrades.service
└─33300 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal
apr 15 19:21:21 desktop systemd[1]: Started unattended-upgrades.service - Unattended Upgrades Shutdown.
```
Possiamo configurare le impostazioni del pacchetto modificando il file `/etc/apt/apt.conf.d/50unattended-upgrades`.
Il pacchetto unattended-upgrades può essere configurato per aggiornare tutti i pacchetti o solo gli aggiornamenti di sicurezza.
La prima sezione definisce quali tipi di pacchetti verranno automaticamente aggiornati. Per impostazione predefinita, installerà solo gli aggiornamenti di sicurezza,
se si desidera abilitare gli aggiornamenti dagli altri repository, è possibile decommentare il repository appropriato.
```bash
sudo nano /etc/apt/apt.conf.d/50unattended-upgrades
[...]
Unattended-Upgrade::Origins-Pattern {
// Codename based matching:
// This will follow the migration of a release through different
// archives (e.g. from testing to stable and later oldstable).
// Software will be the latest available for the named release,
// but the Debian release itself will not be automatically upgraded.
//"origin=Debian,codename=${distro_codename}-updates";
//"origin=Debian,codename=${distro_codename}-proposed-updates";
//"origin=Debian,codename=${distro_codename},label=Debian";
"origin=Debian,codename=${distro_codename},label=Debian-Security";
"origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
// Archive or Suite based matching:
// Note that this will silently match a different release after
// migration to the specified archive (e.g. testing becomes the
// new stable).
// "o=Debian,a=stable";
// "o=Debian,a=stable-updates";
// "o=Debian,a=proposed-updates";
// "o=Debian Backports,a=${distro_codename}-backports,l=Debian Backports";
};
```
## Abilitare gli aggiornamenti automatici di sicurezza
Per abilitare l'aggiornamento automatico, è necessario assicurarsi che il file di configurazione `/etc/apt/apt.conf.d/20auto-upgrades` contenga almeno le seguenti due righe,
che dovrebbero essere incluse per impostazione predefinita:
```bash
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
```
La configurazione precedente aggiorna l'elenco dei pacchetti e installa gli aggiornamenti disponibili ogni giorno.
È possibile anche aggiungere la seguente riga che pulirà l'archivio dei download locale ogni 7 giorni:
```bash
APT::Periodic::AutocleanInterval "7";
```
Quindi dare il seguente comando:
```bash
sudo dpkg-reconfigure --priority -low ined upgrades
```
### Verificare che siano correttamente abilitati
Per verificare se gli aggiornamenti automatici funzionano correttamente, procedere nel seguente modo:
```bash
sudo unattended-upgrades --dry-run --debug
```
L'output dovrebbe assomigliare a questo:
```bash
...
pkgs that look like they should be upgraded:
Fetched 0 B in 0s (0 B/s)
fetch.run() result: 0
blacklist: []
whitelist: []
No packages found that can be upgraded unattended and no pending auto-removals
```
La cronologia degli aggiornamenti automatici viene salvata nel file `/var/log/unattended-upgrades/unattended-upgrades.log`.
## Collegamenti
- [https://linuxhint.com/configure-automatic-security-updates-debian/](https://linuxhint.com/configure-automatic-security-updates-debian/)
- [https://noviello.it/come-abilitare-e-configurare-aggiornamenti-automatici-su-ubuntu-18-04/](https://noviello.it/come-abilitare-e-configurare-aggiornamenti-automatici-su-ubuntu-18-04/)