![Spiegazione della crittografia dei dati: protocollo Perfect Forward Secrecy (PFS)](/f/00936bbfe9acabe105ee27cda2d0e263.png?width=100&height=100)
LINUX come sappiamo è un kernel e non un sistema operativo, viene fornito con diverse distribuzioni come: Debian, Fedora, Ubuntu eccetera. e tanti altri. Sistema operativo Ubuntu sviluppato da Mark Shuttleworth è popolarmente conosciuto e ampiamente utilizzato da molti. Inoltre, essendo gratuito e Open Source, la sua nuova versione viene rilasciata ogni anno a cui contribuiscono migliaia di sviluppatori che contribuiscono al suo sviluppo. Ma come funziona? Quali tutti i processi, l'elenco degli eventi lo fanno funzionare e qual è il significato di questi processi?
Questo articolo ti porterà un po' più in profondità negli interni di Sistema operativo Ubuntu che sono molto interessanti e aiuterebbero un principiante ad avere una completa comprensione del suo funzionamento.
Linux ha un processo per il suo funzionamento, ogni servizio di sistema compreso la gestione dell'alimentazione, l'avvio, la gestione degli arresti anomali del sistema è un processo che ha un file di configurazione in "
/etc/init” che descrive l'evento su cui verrà eseguito e l'evento corrispondente su cui interromperà la sua esecuzione, insieme a ciò mantiene anche i suoi altri file di configurazione che descrivono il suo comportamento in fase di esecuzione nel sistema “/etc/", rendendo così il sistema un evento guidato.Se ci sono eventi generati, qualcuno dovrebbe essere lì per catturarli ed eseguirli?? Bene, ovviamente, il controller è il nostro processo principale che esiste come genitore di tutti i processi con ID processo 1 cioè. dentro. Questo è il processo che inizia con l'avvio del sistema e non si ferma mai. Questo processo muore solo quando il sistema viene spento poiché non esiste alcun processo che sia il genitore di init.
Versioni precedenti di Ubuntu Prima 6.10 incluso vecchio stile sysvinit che è stato utilizzato per eseguire gli script in "/etc/rcx.d” directory ad ogni avvio e arresto del sistema. Ma, dopo parvenu il sistema ha sostituito il vecchio stile sysvinit sistema, ma fornisce comunque la compatibilità con le versioni precedenti.
Le ultime versioni di Ubuntu hanno questo sistema parvenu, ma dalla sua evoluzione da Ubuntu 6.10 ha subito diverse revisioni essendo la versione corrente 1.13.2 come il 4 settembre 2014. L'ultimo sistema upstart ha 2 inizio processi, uno per i processi di sistema e l'altro che gestisce la sessione dell'utente attualmente connesso ed esiste solo fino a quando l'utente non è connesso, chiamato anche x-sessione dentro.
L'intero sistema è stato impostato come gerarchico, costituito dalla relazione antenato-figlio durante l'accensione e lo spegnimento del sistema.
Per esempio: Una piccola relazione gerarchica tra entrambi i processi init è: system init (1) -> display manager (spazio kernel) -> display manager (spazio utente) -> user init (o x-session init).
I file di configurazione per i processi gestiti da system init risiedono in “/etc/init” e per quelli gestiti da init di sessione risiedono in “/usr/share/upstart” (come per le attuali versioni upstart sopra 1.12) e questi file di configurazione sono la chiave per molti segreti scoperti sui processi come descritto in questo articolo.
Ubuntu riconosce due tipi di processi:
La gerarchia che si crea sul sistema è dovuta alla relazione di dipendenza tra i processi che possiamo comprendere visualizzando i loro file di configurazione. Partiamo innanzitutto da una semplice relazione gerarchica tra i processi che fanno avviare il sistema e comprendiamo il significato di ciascuno di essi.
Dentro è il primo processo che si avvia all'accensione del sistema ed è classificato sotto lavoro e soggiorno job in quanto non viene mai ucciso e solo la volta che init viene ucciso è allo spegnimento, cioè init muore solo e anche quello una volta per sessione e cioè allo spegnimento. All'accensione, init genera il primo evento sul sistema, ovvero l'evento di avvio. Ogni file di configurazione in "/etc/init” ha due linee che definiscono l'evento che causa l'avvio e l'arresto del processo. Queste linee sono come evidenziate nella figura seguente:
Questo è un file di configurazione di un processo failsafe-x e queste condizioni start on e stop on descrivono l'evento su cui partirà il processo. Alla generazione dell'evento di avvio da parte del processo init, quei processi che hanno l'avvio come condizione di avvio sono eseguito in parallelo e questo definisce solo la gerarchia e tutti i processi che vengono eseguiti all'avvio sono figli di dentro.
I processi che iniziano all'avvio sono elencati come sotto e questi sono tutti lavori work-and-die:
1. Nome host – Questo è un processo che comunica semplicemente al sistema il suo nome host definito nel file /etc/hostname.
2. kmod – Carica i moduli del kernel, ovvero tutti i driver dal file /etc/modules.
3. montala – Questo processo genera molti eventi ed è principalmente responsabile del montaggio di tutti i filesystem all'avvio, inclusi i filesystem locali e remoti.
Il /proc anche il file viene montato da questo stesso processo e dopo tutto il lavoro di montaggio l'ultimo evento generato da esso è l'evento del filesystem che fa ulteriormente avanzare la gerarchia.
4. plymouth – Questo processo viene eseguito all'avvio di mountall ed è responsabile di mostrare quella schermata nera che si vede all'avvio del sistema che mostra qualcosa come di seguito:
5. pronto per plymouth – Indica che Plymouth è alzato.
Di seguito sono riportati i processi principali, altri che vengono eseguiti anche all'avvio includono, come udev-fallback-grafica, eccetera. Tornando alla gerarchia di avvio, in poche parole gli eventi e i processi che seguono sono come in sequenza:
1. dentro insieme alla generazione dell'evento di avvio.
2. montala montare i file system, plymouth (insieme all'avvio di mountall) che mostra la schermata iniziale e kmod che carica i moduli del kernel.
3. filesystem-locale evento generato da mountall che causa l'esecuzione di dbus. (Dbus è il bus di messaggi a livello di sistema che crea un socket che consente ad altri processi di comunicare tra loro tramite inviando messaggi a questo socket e il ricevitore ascolta i messaggi su questo socket e filtra quelli destinati a esso).
4. filesystem-locale insieme al dbus avviato e all'evento static-network-up causato dalla rete del processo che viene eseguita anche sull'evento del filesystem locale, provoca l'esecuzione di network-manager.
5. filesystem virtuale l'evento generato da mountall causa l'esecuzione di udev. (udev è il gestore dei dispositivi per Linux che gestisce l'hot-plug dei dispositivi ed è responsabile della creazione dei file nella directory /dev e della loro gestione.) udev crea file per ram, rom ecc. nella directory /dev quelli il mountall ha finito di montare i filesystem virtuali e ha generato l'evento filesystem virtuale che indica il montaggio di /dev directory.
6. udev provoca l'esecuzione di upstart-udev-bridge che indica che la rete locale è attiva. Quindi, dopo che mountall ha finito di montare l'ultimo filesystem e ha generato l'evento del filesystem.
7. filesystem L'evento insieme all'evento static-network-up causa l'esecuzione del lavoro rc-sysinit. Ecco, arriva la retrocompatibilità tra sysvinit più vecchio e upstart...
9. rc-sysinit esegue il comando telinit che indica il runlevel del sistema.
10. Dopo aver ottenuto il runlevel, init esegue gli script che iniziano con "S' o 'K' (avvio di lavori che hanno 'S' all'inizio del loro nome e uccidendo quelli che hanno 'K' all'inizio del loro nome) nella directory /etc/rcX.d (dove 'X' è il runlevel corrente).
Questo piccolo insieme di eventi fa sì che il sistema si avvii ogni volta che lo si accende. E questo evento di attivazione dei processi è l'unica cosa responsabile della creazione della gerarchia.
Ora, un altro componente aggiuntivo di cui sopra è la causa dell'evento. Quale processo causa quale evento è specificato anche nello stesso file di configurazione del processo come mostrato di seguito in queste righe:
Sopra c'è una sezione del file di configurazione del processo mountall. Questo mostra gli eventi che emette. Il nome dell'evento è uno che segue la parola "evento’. L'evento può essere quello definito nel file di configurazione come sopra o può essere il nome del processo insieme al prefisso "starting", "started", "stopping" o "stopped".
Quindi, qui definiamo due termini:
Quindi, segue la gerarchia e quindi la dipendenza tra i processi:
Generatore di eventi (genitore) -> Cattura eventi (figlio)
Fino ad ora, devi aver capito come la gerarchia di genitore-figlio la dipendenza tra i processi è stabilita da attivazione di eventi meccanismo attraverso un semplice meccanismo di avvio.
Ora, questa gerarchia non è mai una relazione uno a uno con un solo genitore per un figlio. In questa gerarchia possiamo avere uno o più genitori per un bambino o uno dei processi è essere un genitore di più di un bambino. Come si realizza?? Bene, la risposta sta nei file di configurazione stessi.
Queste linee sono prese dal processo – networking e qui l'inizio a condizione sembra un po' troppo complesso composto da tanti eventi e cioè – filesystem-locali, udevtrigger, contenitore, livello di esecuzione, rete.
Il filesystem locale viene emesso da mountall, udevtrigger è il nome del lavoro, l'evento contenitore viene emesso da container-detect, l'evento runlevel emesso da rc-sysinit e la rete è di nuovo un lavoro.
Quindi, in una gerarchia il processo di rete è figlio di mountall, udevtrigger e container-detect in quanto non può continuare il suo funzionamento (funzionamento del process sono tutte le righe che sono definite nelle sezioni script o exec nel file di configurazione di process) fino a quando i processi sopra non generano il loro eventi.
Allo stesso modo, possiamo avere un processo come genitore di molti se l'evento generato da un processo viene memorizzato nella cache da molti.
Come definito in precedenza, possiamo avere una vita breve (oppure lavora e muori lavori) o di lunga durata (o soggiorno-e-lavoro) lavori ma come distinguerli??
I lavori che hanno entrambiinizia su' e 'fermati' condizioni specificate nei loro file di configurazione e hanno una parola 'compito' nel loro file di configurazione sono lavora e muori i lavori che iniziano sull'evento generato, eseguono il loro script o la sezione exec (durante l'esecuzione, bloccano gli eventi che li hanno causati) e muoiono successivamente rilasciando quegli eventi che hanno bloccato.
Quei lavori che non hanno 'fermati' condizione nel loro file di configurazione sono di lunga durata o soggiorno-e-lavoro lavoro e non muoiono mai. Ora i lavori di permanenza e lavoro possono essere ulteriormente classificati come:
Quindi, ogni processo in LINUX dipende da alcuni e ha alcuni processi dipendenti da esso e questa relazione è molti su molti ed è specificata con il sistema upstart insieme ad altri dettagli del processo.