RSS
Blog LPI

LPIC-1: Systemd oltre i Service

Gennaio 29, 2019 - di Fabian Thorns

Nel post di oggi esaminiamo alcuni argomenti relativi a systemd che vanno oltre l'avvio e l'interruzione dei services. Questi argomenti sono stati aggiunti alla Certificazione LPIC-1 nella versione 5.0.

L'Obiettivo 101.3 ha già coperto systemd nella versione 4.0. L'oggetto di questo obiettivo è la gestione delle service units. Una service unit controlla l'avvio e l'arresto di un programma. Le unità sono definite in file che terminano in .service che risiedono in /usr/lib/systemd/system/, /run/systemd/system/ or /etc/systemd/system/. È possibile sovrascrivere parametri specifici o anche interi file di unità creando directory e file /etc/systemd/system/. Dai un'occhiata al post sul blog di Justin Ellingwood: Comprensione Systemd Units e Unit Files per ricapitolare la struttura degli unit files.

All'avvio, le unità target specificano quali service unit debbano essere eseguite. Dopo l'avvio del sistema, systemctl fornisce vari sottocomandi per gestire unità, come ad esempio start, Stop, status, enable, disable, mask, unmask or edit. Rivedi il manuale di systemctl (1) e assicurati di essere certo di saper usare i sottocomandi più importanti di systemctl.

Nel tempo, systemd ha cominciato a occuparsi di un numero crescente di aspetti cruciali di un sistema Linux. Poiché sempre più distribuzioni usano systemd per queste attività, la nuova versione di LPIC-1 ne include molte. systemd fornisce la propria infrastruttura di registrazione, il systemd journal. Systemd-journald allega i metadati ai messaggi di registrazione, in modo che sia possibile, per esempio, filtrare i messaggi di log prodotti da una specifica unità systemd in un intervallo di tempo specifico. Il comando journalctl fornisce l'accesso al giornale systemd. Questo comando è coperto dagli Obiettivi 101.2 e 108.2.

Poiché il sistema probabilmente esegue già systemd, è opportuno avere una certa sicurezza di journalctl. Filtra i messaggi da un servizio specifico e ottieni eventi da un intervallo di tempo specifico. Esegui systemd-cat e filtra i messaggi che produce. Scopri dove journald memorizza il journal, per quanto tempo vengono conservati i messaggi e come accedervi in ​​caso di emergenza, per esempio dopo l'avvio in un sistema di salvataggio in tempo reale.

Justin Ellingwood ha scritto una grande introduzione, Come utilizzare Journalctl per visualizzare e manipolare Systemd Log, che ti guida attraverso tutti questi passaggi. Il tutorial ti introduce anche a timedatectl che è coperto dall' l'Obiettivo 108.1. Dovresti cogliere l'occasione per rivedere anche i concetti e la configurazione di rsyslog, che ha sostituito syslog nell' l'Obiettivo 108.2. Il sito Web rsyslog contiene diverse guide introduttive.

Le Timer unit in systemd hanno la capacità di controllare le service unit. Sono coperte dall' l'Obiettivo 107.2. Simile a una cron job, una timer unit attiva una service unit in un momento specifico. Le timer unit di default controllano una service unit con lo stesso nome. man-db.timer, per esempio, da inizio a man-db.service. Dai uno sguardo a una delle unità timer unit che esistono sul tuo systemd e rivedi il systemd.timer(8) manpage per i vari modi di come specificare il tempo di esecuzione. Come esercizio finale, prova a creare la tua service unit systemd e attivarla con un timer systemd. Tutorial: Esercitazione Systemd Timer Tutorial con un esempio di invio automatico di posta - come eseguirlo.

Socket unit, come menzionato in l'Obiettivo 110.2, sono un altro tipo di unità che controlla le service unit. Analogamente a inetd, le socket unit aprono un socket in un file o in una porta, attendono connessioni in entrata e avviano il servizio per ciascuna connessione. Probabilmente troverai alcune socket unit che puoi analizzare sul tuo sistema. Tieni presente che le unità socket possono esporre questi servizi ai client remoti, esponendoli quindi a potenziali aggressori.

systemd gestisce anche i supporti del file system. Mentre le mount unit possono essere utilizzate per attivare mount, systemd le usa anche per monitorarle creando automaticamente unit quando viene visualizzata una nuova mount. L'Obiettivo 104.3 copre la conoscenza delle mount unit. Dovresti investigare su una delle mount unit esistenti sul tuo sistema e capire come interagiscono con mount e /etc/fstab.

L'Obiettivo 109.2 fornisce altri tre esempi di quanti diversi problemi systemd affronti. Il comando hostnamectl è il modo in cui systemd regola l'hostname del computer locale. Il manpage hostnamectl (1) fornisce una panoramica dei sottocomandi disponibili. systemd-networkd e systemd-resolved sono daemon che gestiscono la configurazione di rete. LPIC-1 si aspetta solo che tu ne sia a conoscenza, senza dettagli sulla sua configurazione. Invece, LPIC-1 si concentra su NetworkManager per la configurazione di rete persistente, che esamineremo la prossima settimana.

Post precedente | Prossimo post

Informazioni su Fabian Thorns:

Fabian Thorns

Fabian Thorns is the Director of Certification Development at Linux Professional Institute, LPI. He is M.Sc. Business Information Systems, a regular speaker at open source events and the author of numerous articles and books. Fabian has been part of the exam development team since 2010. Connect with him on LinkedIn, XING or via email (fthorns at lpi.org).