Uno introduzione a systemd per Centos 7

Articolo di Stuart Burns pubblicato su Openlogic.com

Con il rilascio di Red Hat Enterprise Linux 7  e CentOS versione 7, ora è un buon momento per parlare di systemd, che sostituirà il classico System V (SysV) per tutti gli script di avvio e runlevel. Le distribuzioni basate su Red Hat-stanno migrando a systemd perché fornisce modi più efficienti di gestione dei servizi e tempi di avvio più rapidi. Con systemd ci sono meno file da modificare, e tutti i servizi sono compartimenti stagni separati gli uni dagli altri. Ciò significa che nel caso in cui si dovesse rovinare un file di configurazione, non si influirà automaticamente sugli altri servizi.

Systemd è il responsabile del sistema e dei servizi di default in Red Hat Fedora dal rilascio di Fedora 15, quindi è ampiamente testato sul campo. Esso fornisce una maggiore coerenza e capacità di risoluzione dei problemi SysV – per esempio, segnalerà se un servizio non è ripartito, è sospeso, o è in errore. Forse il più grande motivo per il passaggio a systemd è che consente a più servizi di partire, allo stesso tempo, in parallelo, rendendo i tempi di avvio della macchina più veloci di quanto lo sarebbero con un runlevel classico.

Sotto systemd, i servizi sono ora definiti nei file che vengono chiamati unit, che sono file di testo che contengono tutte le informazioni di configurazione di cui un servizio ha bisogno per partire, incluse le sue dipendenze. I file Service si trovano in /usr/lib/systemd/system/. Molti ma non tutti i file in quella directory terminano con un .service; systemd gestisce anche sockets e devices.

Non sarà più possibile modificare direttamente gli script per configurare il runlevel. All’interno di systemd, i runlevel sono stati sostituiti dal concetto di stati. Gli stati possono essere descritti come “best effort” per far si che un host arrivi ad una certa configurazione desiderata, che si tratti della modalità utente singolo, rete in modalità non grafica, o qualcos’altro. Systemd ha alcuni stati predefiniti creati in concomitanza con i runlevel legacy. Sono essenzialmente alias, progettati per imitare runlevel utilizzando systemd.

Gli stati  richiedono componenti aggiuntivi al di là dei servizi. Pertanto, systemd utilizza i file della macchina non solo per configurare i servizi, ma anche per gestire sockets e device. I nomi di queste unità finiscono in .sockets, .devices, e così via.

I targets, sono gruppi logici di unit che forniscono una serie di servizi. Pensate ad un target come un wrapper in cui è possibile inserire più unit, creando così un modo ordinato di lavorare.

I file unit sono costruiti da diverse sezioni configurabili, comprese le descrizioni dell’unit e le dipendenze. Systemd consente inoltre agli amministratori di definire esplicitamente le dipendenze di un servizio e le caricano prima che il serviziosia inizializzato.

Ogni file di tipo unit ha una riga del tipo After= che può essere utilizzato per definire ciò che è richiesto al servizio prima che il servizio corrente possa iniziare. Le linee WantedBy=  specificano che un target richiede una determinata unit.

I target hanno nomi più significativi rispetto a quelli utilizzati in sistemi basati su SysV. Un nome come graphical.target fornisce agli amministratori un’idea di cosa fornisce il file! Per visualizzare il target corrente nel quale il sistema risiede, utilizzare il comando systemctl get-default. Per configurare il target di default, usare il comando systemctl set-default targetname.target. targetname che può essere tra l’altro:

• rescue.target
• multi-user.target
• graphical.target
• reboot.target

Guardando quanto sopra appare evidente che anche se non c’è corrispondenza diretta tra runlevel ed i target, systemd fornisce quello che potrebbe vagamente essere definito come “livelli equivalenti”.

Un’altra caratteristica importante systemd è cgroups, che sta per gruppi di controllo, questi garantiscono la sicurezza e gestibilità per le risorse di un sistema che siano facilmente in grado di essere utilizzate e controllate. Con cgroups, i servizi che utilizzano la stessa gamma di chiamate di sistema operativo sono raggruppati insieme. Questi gruppi di controllo quindi gestiscono le risorse che controllano. Questo raggruppamento svolge due funzioni: permette agli amministratori di gestire la quantità di risorse che un gruppo di servizi ottiene, e fornisce protezione aggiuntiva  che un servizio in un determinato cgroup non possa andare al di fuori del controllo di cgroups, evitando per esempio che ottenga l’accesso ad altre risorse controllate da altri cgroups.

Cgroups esisteva nel vecchio modello SysV, ma non era implementato molto bene. systemd tenta di risolvere questo problema.

Primi passi in systemd

Sotto systemd è comunque possibile utilizzare il servizio ed i comandi di chkconfig per gestire tali servizi legacy aggiuntivi, come Apache, che non sono è ancora stato spostato sotto la gestione di systemd. È inoltre possibile utilizzare il comando service per gestire i servizi di systemd. Tuttavia, diversi servizi di monitoraggio e di registrazione, tra cui cron e syslog, sono stati riscritti per utilizzare le funzionalità che sono disponibili in systemd, in parte perché la programmazione e alcune delle funzionalità di cron sono ora fornite da systemd.

Come si può iniziare a gestire i servizi con systemd? Ora che Centos 7 è stata rilasciata possiamo iniziare a sperimentare alcune cose con systemd e capirne il suo funzionamento. Per iniziare, come utente root in un terminale, digitare chkconfig. L’output mostra tutti i servizi legacy in esecuzione. Come si può vedere dalla grande dichiarazione di non responsabilità, la maggior parte degli altri servizi che ci si aspetterebbe fossero presenti sono assenti, perché sono stati migrati alla gestione di systemd.

I sistemi operativi basati su Red Hat non utilizzano più il vecchio file /etc/initab, ma invece utilizzano un file di configurazione system.default. E’ possibile fare dei link simbolici al target desiderato in system.default per far si che il target che si sta linkando parta automaticamente al boot della macchina. Per configurare il target per far partire un tipico sistema multi-utente, ad esempio, eseguire il seguente comando:

ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

Dopo aver effettuato il collegamento simbolico, eseguire systemctl, il comando al posto di chkconfig. Compariranno diverse pagine di output, che elencano tutti i servizi disponibili:

• Unit – il nome del servizio
• Load – dà lo stato del servizio (ad esempio Loaded, Failed, ecc)
• Active – indica se lo stato del servizio è attivo
• Description –descrizione testuale dell’unità

I comandi principali e gli argomenti in systemctl sono simili a quelle legacy presenti in chkconfig – per esempio,  systemctl start postfix.service.

Allo stesso modo utilizzare  systemctl stop e systemctl status per fermare un servizio o per avere informazioni. La sintassi è simile agli argomenti di chkconfig by design, per rendere la transizione a systemd la più agevole possibile.

Per vedere tutti i servizi che è possibile far partire ed utilizzare con systemctl ed il loro stato, utilizzare il comando

systemctl list-unit-files --type=service

Anche se non è più possibile attivare un runlevel per un servizio utilizzando chkconfig --level, sotto systemd è possibile attivare o disattivare un servizio, quando parte. Utilizzare systemctl enable service per abilitare un servizio, e systemctl disable service per non farlo partire alla partenza. Per ottenere lo stato attuale di un servizio (abilitato o disabilitato) usare il comando systemctl is-enabled service.

Considerazioni finali su systemd

Può richiedere un certo tempo per abituarsi a systemd, ma è necessario pianificare di usarlo ora, prima che diventi un requisito e la gestione attraverso gli strumenti legacy non sia più disponibile. Si dovrebbe vedere che systemd rende i servizi di gestione più facile di quanto non lo sia con SysV.

Popular Posts:

None Found