![Evento Apple Unleashed: MacBook Pro, AirPods 3, HomePod Mini e altro](/f/3ff6817ce2a8cade62b312f6cb6761d2.jpg?width=100&height=100)
Un paio di mesi fa, la Linux Foundation ha annunciato il LFCS (Amministratore di sistema certificato Linux Foundation), un nuovo entusiasmante programma il cui obiettivo è consentire a persone di ogni parte del mondo di ottenere la certificazione nell'esecuzione di attività di amministrazione di sistema di base e intermedie su sistemi Linux. Ciò include il supporto di sistemi e servizi già in esecuzione, insieme alla ricerca e all'analisi di problemi di prima mano, oltre alla capacità di decidere quando sollevare problemi ai team di progettazione.
Il seguente video descrive una breve introduzione al programma di certificazione The Linux Foundation.
Questo post è la parte 7 di una serie di 10 tutorial, qui in questa parte spiegheremo come gestire il processo e i servizi di avvio del sistema Linux, necessari per l'esame di certificazione LFCS.
Il processo di avvio di un sistema Linux è costituito da diverse fasi, ciascuna rappresentata da un componente diverso. Il diagramma seguente riassume brevemente il processo di avvio e mostra tutti i componenti principali coinvolti.
Quando premi il Potenza pulsante sulla macchina, il firmware che è memorizzato in a EEPROM chip nella scheda madre inizializza il INVIARE (Autotest all'accensione) per verificare lo stato delle risorse hardware del sistema. Quando il INVIARE è terminato, il firmware quindi cerca e carica il 1° stadio boot loader, situato nel MBR o nel EFI partizione del primo disco disponibile e gli assegna il controllo.
Il MBR si trova nel primo settore del disco contrassegnato come avviabile in BIOS impostazioni ed è 512 byte di dimensione.
Il seguente comando esegue un backup del MBR (in questo esempio, /dev/sda è il primo disco rigido). Il file risultante, mbr.bkp può tornare utile se la tabella delle partizioni diventa corrotta, ad esempio, rendendo il sistema non avviabile.
Ovviamente, per poterlo utilizzare in seguito in caso di necessità, dovremo salvarlo e conservarlo da qualche altra parte (come un USB guidare, per esempio). Quel file ci aiuterà a ripristinare l'MBR e ci farà ripartire se e solo se nel frattempo non cambiamo il layout del disco rigido.
# dd if=/dev/sda of=mbr.bkp bs=512 count=1.
# dd if=mbr.bkp of=/dev/sda bs=512 count=1.
Per i sistemi che utilizzano il EFI/UEFI metodo, il firmware UEFI legge le sue impostazioni per determinare quale applicazione UEFI deve essere avviata e da dove (cioè, in quale disco e partizione si trova la partizione EFI).
Successivamente, il 2° stadio boot loader (noto anche come boot manager) viene caricato ed eseguito. GRUB [Grand Unified Boot] è il boot manager più utilizzato in Linux. Una delle due versioni distinte può essere trovata sulla maggior parte dei sistemi utilizzati oggi.
Sebbene gli obiettivi del LFCS esame non richiedono esplicitamente conoscenze su GRUB internals, se sei coraggioso e puoi permetterti di rovinare il tuo sistema (potresti provare prima su una macchina virtuale, per ogni evenienza), devi eseguire.
# update-grub.
Come radice dopo aver modificato la configurazione di GRUB per applicare le modifiche.
Fondamentalmente, GRUB carica l'impostazione predefinita kernel e il inizia o initramfs Immagine. In poche parole, initrd o initramfs aiutano a eseguire il rilevamento dell'hardware, il caricamento del modulo del kernel e il rilevamento dei dispositivi necessari per montare il vero filesystem di root.
Una volta che il vero filesystem di root è attivo, il kernel esegue il sistema e il gestore dei servizi (dentro o sistema, la cui identificazione del processo o PID è sempre 1) per iniziare il normale processo di avvio dello spazio utente per presentare un'interfaccia utente.
Tutti e due dentro e sistema sono demoni (processi in background) che gestiscono altri demoni, come il primo servizio ad avviarsi (durante l'avvio) e l'ultimo servizio a terminare (durante lo spegnimento).
Il concetto di runlevel in Linux specifica diversi modi di utilizzare un sistema controllando quali servizi sono in esecuzione. In altre parole, un runlevel controlla quali attività possono essere eseguite nello stato di esecuzione corrente = runlevel (e quali no).
Tradizionalmente, questo processo di avvio è stato eseguito sulla base di convenzioni che hanno avuto origine con Sistema V UNIX, con il sistema che passa l'esecuzione di raccolte di script che avviano e arrestano i servizi quando la macchina entra in un runlevel specifico (che, in altre parole, è una modalità diversa di esecuzione del sistema).
All'interno di ogni runlevel, i singoli servizi possono essere impostati per l'esecuzione o per essere arrestati se in esecuzione. Le ultime versioni di alcune delle principali distribuzioni si stanno allontanando dal Sistema V standard a favore di un servizio piuttosto nuovo e gestore di sistema chiamato sistema (che sta per demone di sistema), ma di solito supporta sysv comandi per motivi di compatibilità. Ciò significa che puoi eseguire la maggior parte dei ben noti sysv init in una distribuzione basata su systemd.
Leggi anche: Perché "systemd" sostituisce "init" in Linux
Oltre ad avviare il processo di sistema, dentro guarda al /etc/inittab file per decidere quale runlevel deve essere inserito.
Livello di esecuzione | Descrizione |
0 | Arrestare il sistema. Il runlevel 0 è uno stato di transizione speciale utilizzato per arrestare rapidamente il sistema. |
1 | Alias anche a s, o S, questo runlevel è talvolta chiamato modalità di manutenzione. Quali servizi, se presenti, vengono avviati a questo runlevel varia in base alla distribuzione. Viene in genere utilizzato per la manutenzione del sistema di basso livello che potrebbe essere compromessa dal normale funzionamento del sistema. |
2 | Multiutente. Sui sistemi Debian e derivati, questo è il runlevel predefinito e include, se disponibile, un login grafico. Sui sistemi basati su Red-Hat, questa è la modalità multiutente senza rete. |
3 | Sui sistemi basati su Red-Hat, questa è la modalità multiutente predefinita, che esegue tutto tranne l'ambiente grafico. Questo runlevel e i livelli 4 e 5 di solito non sono usati su sistemi basati su Debian. |
4 | Tipicamente inutilizzato per impostazione predefinita e quindi disponibile per la personalizzazione. |
5 | Sui sistemi basati su Red-Hat, modalità multiutente completa con login GUI. Questo runlevel è come il livello 3, ma con un accesso GUI disponibile. |
6 | Riavvia il sistema. |
Per passare da un runlevel a un altro, possiamo semplicemente emettere una modifica del runlevel utilizzando il pulsante dentro comando: inizia n (dove N è uno dei runlevel elencati sopra). Si prega di notare che questo non è il modo consigliato per portare un sistema in esecuzione a un runlevel diverso perché non dà alcun avviso agli utenti che hanno effettuato l'accesso (facendo perdere loro lavoro e terminando i processi anormalmente).
Invece, il spegnimento comando dovrebbe essere utilizzato per riavviare il sistema (che prima invia un messaggio di avviso a tutti gli utenti che hanno effettuato l'accesso e blocca eventuali ulteriori accessi; quindi segnala a init di cambiare runlevel); tuttavia, il runlevel predefinito (quello su cui verrà avviato il sistema) deve essere modificato nel /etc/inittab prima il file.
Per questo motivo, segui questi passaggi per passare correttamente da un runlevel a un altro, come root, cerca la seguente riga in /etc/inittab.
id: 2:initdefault:
e cambia il numero 2 per il runlevel desiderato con il tuo editor di testo preferito, come vim (descritto in Come usare l'editor vi/vim in Linux – Parte 2 di questa serie).
Quindi, esegui come root.
# spegnimento -r ora.
Quella ultimo Il comando riavvierà il sistema, avviandolo nel runlevel specificato durante l'avvio successivo, ed eseguirà gli script che si trovano nel /etc/rc[runlevel].d directory per decidere quali servizi devono essere avviati e quali no. Ad esempio, per il runlevel 2 nel seguente sistema.
Per abilitare o disabilitare i servizi di sistema all'avvio, useremo comando chkconfig in CentOS/openSUSE e sysv-rc-conf in Debian e derivati. Questo strumento può anche mostrarci qual è lo stato preconfigurato di un servizio per un particolare runlevel.
Leggi anche: Come fermare e disabilitare i servizi indesiderati in Linux
Elenco della configurazione del runlevel per un servizio.
# chkconfig --list [nome servizio] # chkconfig --list postfisso. # chkconfig --list mysqld.
Nell'immagine sopra possiamo vedere che suffisso è impostato per avviarsi quando il sistema entra nei runlevel 2 attraverso 5, mentre mysqld verrà eseguito per impostazione predefinita per i runlevel 2 attraverso 4. Supponiamo ora che questo non sia il comportamento previsto.
Ad esempio, dobbiamo accendere mysqld per runlevel 5 e disattivare postfix per i runlevel 4 e 5. Ecco cosa faremmo in ogni caso (eseguire i seguenti comandi come root).
# chkconfig --level [livello (i)] servizio attivo. # chkconfig --level 5 mysqld on.
# chkconfig --level [livello (i)] servizio disattivato. # chkconfig --level 45 postfisso disattivato.
Ora eseguiremo compiti simili in a Basato su Debian sistema usando sysv-rc-conf.
Configurare un servizio per avviarsi automaticamente su un runlevel specifico e impedirne l'avvio su tutti gli altri.
1. Usiamo il seguente comando per vedere quali sono i runlevel dove mdadm è configurato per l'avvio.
# ls -l /etc/rc[0-6].d | grep -E 'rc[0-6]|mdadm'
2. Noi useremo sysv-rc-conf per impedire a mdadm di avviarsi su tutti i runlevel tranne 2. Seleziona o deseleziona (con la barra spaziatrice) come desiderato (puoi spostarti su, giù, sinistra e destra con i tasti freccia).
# sysv-rc-conf.
Quindi premere Q abbandonare.
3. Riavvieremo il sistema ed eseguiremo di nuovo il comando da PASSO 1.
# ls -l /etc/rc[0-6].d | grep -E 'rc[0-6]|mdadm'
Nell'immagine sopra possiamo vedere che mdadm è configurato per avviarsi solo su runlevel 2.
sistema è un altro servizio e gestore di sistema adottato da diverse importanti distribuzioni Linux. Ha lo scopo di consentire l'esecuzione di più elaborazioni in parallelo durante l'avvio del sistema (a differenza di sysvinit, che tende sempre ad essere più lento perché avvia i processi uno alla volta, controlla se uno dipende da un altro e attende l'avvio dei demoni in modo da poter avviare più servizi) e fungere da gestione dinamica delle risorse per un'esecuzione sistema.
Pertanto, i servizi vengono avviati quando necessario (per evitare di consumare risorse di sistema) invece di essere avviati senza un motivo valido durante l'avvio.
Visualizzazione dello stato di tutti i processi in esecuzione sul sistema, entrambi sistema nativo e SysV services, eseguire il comando seguente.
# systemctl.
Il CARICARE mostra se la definizione dell'unità (fare riferimento alla UNITÀ colonna, che mostra il servizio o qualsiasi cosa gestita da systemd) è stata caricata correttamente, mentre il ATTIVO e SUB le colonne mostrano lo stato corrente di tale unità.
Quando il ATTIVO colonna indica che lo stato di un'unità è diverso da attivo, possiamo controllare cosa è successo usando.
# stato systemctl [unità]
Ad esempio, nell'immagine sopra, media-samba.mount è in stato di guasto. Corriamo.
# stato systemctl media-samba.mount.
Possiamo vederlo media-samba.mount fallito perché il processo di montaggio sull'host dev1 non è stato possibile trovare la condivisione di rete su //192.168.0.10/gacanepa.
Una volta che la condivisione di rete //192.168.0.10/gacanepa diventa disponibile, proviamo ad avviare, quindi arrestare e infine riavviare l'unità media-samba.mount. Dopo aver eseguito ogni azione, eseguiamo systemctl status media-samba.mount per verificarne lo stato.
# systemctl avvia media-samba.mount. # stato systemctl media-samba.mount. # systemctl stop media-samba.mount. # systemctl riavvia media-samba.mount. # stato systemctl media-samba.mount.
Sotto sistema puoi abilitare o disabilitare un servizio all'avvio.
# systemctl enable [servizio] # abilita un servizio # systemctl disable [servizio] # impedisce l'avvio di un servizio all'avvio.
Il processo di abilitazione o disabilitazione di un servizio per l'avvio automatico all'avvio consiste nell'aggiungere o rimuovere collegamenti simbolici nel /etc/systemd/system/multi-user.target.wants directory.
In alternativa, puoi scoprire lo stato attuale di un servizio (abilitato o disabilitato) con il comando.
# systemctl è abilitato [servizio]
Per esempio,
# systemctl è abilitato postfix.service.
Inoltre, puoi riavviare o spegnere il sistema con.
# riavvio systemctl. # arresto del sistemactl.
parvenu è un sostituto basato su eventi per il /sbin/init daemon e nasce dalla necessità di avviare servizi solo quando servono (anche supervisionandoli mentre sono in esecuzione) e gestendo gli eventi man mano che si verificano, superando così il classico sysvinit. basato sulle dipendenze sistema.
È stato originariamente sviluppato per la distribuzione Ubuntu, ma è utilizzato in Red Hat Enterprise Linux 6.0. Sebbene fosse pensato per essere adatto per l'implementazione in tutte le distribuzioni Linux in sostituzione per sysvinit, nel tempo è stato oscurato da sistema. Il 14 febbraio 2014, Mark Shuttleworth (fondatore di Canonical Ltd.) ha annunciato che le versioni future di Ubuntu avrebbero utilizzato systemd come demone di inizializzazione predefinito.
Perché il SysV script di avvio per il sistema è stato così comune per così tanto tempo, un gran numero di pacchetti software include script di avvio SysV. Per ospitare tali pacchetti, Upstart fornisce una modalità di compatibilità: esegue gli script di avvio SysV nelle solite posizioni (/etc/rc.d/rc?.d, /etc/init.d/rc?.d, /etc/rc?.d, o un luogo simile). Pertanto, se installiamo un pacchetto che non include ancora uno script di configurazione Upstart, dovrebbe comunque avviarsi nel solito modo.
Inoltre, se abbiamo installato utilità come chkconfig, dovresti essere in grado di usarli per gestire i tuoi servizi basati su SysV proprio come faremmo sui sistemi basati su sysvinit.
Gli script Upstart supportano anche l'avvio o l'arresto di servizi basati su una più ampia varietà di azioni rispetto agli script di avvio SysV; ad esempio, Upstart può avviare un servizio ogni volta che è collegato un particolare dispositivo hardware.
Un sistema che utilizza Upstart e i suoi script nativi sostituisce esclusivamente il /etc/inittab file e il runlevel specifico SysV directory di script di avvio con .conf script in /etc/init directory.
Questi *.conf Gli script (noti anche come definizioni di lavoro) sono generalmente costituiti da quanto segue:
Per esempio,
# Il mio servizio di test - Descrizione demo dello script Upstart "Ecco la descrizione di 'Il mio servizio di test'" autore "Dave Null <[e-mail protetta]>" # Stanze # # Le strofe definiscono quando e come un processo viene avviato e interrotto. # Vedi un elenco di strofe qui: http://upstart.ubuntu.com/wiki/Stanzas#respawn. # Quando avviare il servizio. avvia su runlevel [2345] # Quando interrompere il servizio. ferma su runlevel [016] # Riavvia automaticamente il processo in caso di crash. rigenerarsi. # Specifica la directory di lavoro. chdir /home/dave/myfiles. # Specifica il processo/comando (aggiungi argomenti se necessario) da eseguire. exec bash backup.sh arg1 arg2.
Per applicare le modifiche, dovrai dire a upstart di ricaricare la sua configurazione.
# initctl reload-configuration.
Quindi inizia il tuo lavoro digitando il seguente comando.
$ sudo start yourjobname.
In cui si il tuo nome di lavoro è il nome del lavoro che è stato aggiunto in precedenza con il nomelavoro.conf sceneggiatura.
Una guida di riferimento più completa e dettagliata per Upstart è disponibile nel sito web del progetto sotto il menu "Libro di cucina”.
Una conoscenza del processo di avvio di Linux è necessaria per aiutarti con le attività di risoluzione dei problemi e per adattare le prestazioni del computer e l'esecuzione dei servizi alle tue esigenze.
In questo articolo abbiamo analizzato cosa succede dal momento in cui si preme il Potenza interruttore per accendere la macchina finché non si ottiene un'interfaccia utente completamente operativa. Spero che tu abbia imparato a leggerlo tanto quanto ho fatto io mentre lo mettevo insieme. Sentiti libero di lasciare i tuoi commenti o domande qui sotto. Non vediamo l'ora di sentire i nostri lettori!