Chroot: una breve introduzione
In questi giorni ho deciso di cominciare una guida più o meno completa ad un comando che purtroppo, nel mondo degli smanettoni “non avanzati”, è poco conosciuto; si tratta di chroot.
Infatti, tra un impegno ed un altro, mi sono accorto sul forum di Arch Linux, e non solo, di dover fornire spiegazioni riguardo questa utility, che non è, d’altronde, ricca di documentazione e spiegata come vorrei (e come vorrebbero). 
Innanzi tutto, una breve introduzione: chroot serve per entrare in una data directory provvista di filesystem Unix e, all’interno di questa, bash, per sfruttarla alla stregua di una vera e propria directory radice, allo scopo di eseguire programmi o riparare, come mi è successo spesse volte, problemi vari. Nello specifico, mi sono trovato a spiegare chroot nell’ambito della risoluzione di problemi legata a sistemi che, in circostanze varie, non eseguono correttamente la procedura di boot, per cui non ci si può loggare all’interno del sistema per riparare i danni.
Chroot quindi, oltre che una utility per scopi più o meno noti, può servire da trucchetto d’emergenza per riparare al fatto di aver fatto una razzata; spesso si sente dire “Linux va formattato solo in caso di problemi gravissimi”. Ebbene, questo è falso, perchè in caso di problemi gravissimi abbiamo il nostro chroot pronto a darci una mano in qualsiasi circostanza 
Ma vediamone per bene il funzionamento: innanzi tutto, abbiamo bisogno, come ho detto su, di una subdirectory con un filesystem Unix e la bash installata; nel caso in cui dovessimo riparare dei danni, la nostra partizione target può diventare facilmente una subdirectory del sistema operativo che stiamo utilizzando tramite una semplice operazione di montaggio. Creiamo quindi il punto di aggancio:
sudo mkdir /media/target
E montiamo, finalmente, il nostro pseudo-filesystem, o la partizione bersaglio dei cambiamenti che vogliamo effettuare, legandolo in questo modo alla nostra root reale.
mount /dev/sdaX /media/target
A questo punto, se vogliamo solo modificare dei file senza compiere operazioni che interessino i dispositivi o i dati presenti in /proc, possiamo anche saltare il montaggiodi altre parti del nostro sistema base nel sistema bersaglio. Però, c’è un però.
Però, se vogliamo compiere operazioni come un aggiornamento, che interessa ovviamente alcuni dati di /dev e alcuni dati di /proc, conviene rendere disponibili queste informazioni al sistema ospite; come fare? Tramite altri due comandi di montaggio, il primo che riguardi la directory /dev, e l’altro che interessi /proc: in questa maniera rendiamo leggibili le informazioni riguardo l’hardware della macchina al sistema ospite, che potrà, in parecchi casi, averne bisogno. Per esempio per una ricompilazione del kernel. Per esempio.
Ordunque, andiamo a montare /dev con alcune opzioni che non so minimamente cosa significhino, ma dato che sono scritte sul Gentoo Handbook e le ho usate moltissime volte le prendo per buone 
sudo mount -o bind /dev /media/target/dev
E andiamo poi a montare uno pseudo-proc, almeno da quanto ho capito per via della sintassi di comando leggermente più articolata.
sudo mount -t proc none /media/target/proc
A questo punto, siamo pronti. Possiamo tuffarci nel sistema ospite, ed iniziare riparazioni, modifiche, aggiornamenti, installazioni e quant’altro:
sudo chroot /media/target
Come vediamo, il PS1 è cambiato, e rappresenta il .bashrc che abbiamo impostato per l’utente root sulla directory target, nella quale adesso siamo loggati come root e possiamo effettuare ogni tipo di modifica.
Per uscire dalla nuova directory radice, ovviamente, basta un semplice comando exit 
In questo modo, si possono far eseguire programmi in una sandbox a prova di bomba, in quanto non condivide nulla, a parte qualche informazione, con la macchina ospitante. Godetevi il vostro chroot, e cominciate a usarlo massivamente per i compiti più disparati. Posso veramente dire: chroot, mai più senza
novembre 22nd, 2009 at 14:01
Ottima guida per un comando veramente versatile e potente… gentoo insegna
novembre 22nd, 2009 at 14:09
Bell'articolo, tornerà utile a molti
Certo che chroot è un po' la virtualizzazione dei poveri ;D
novembre 22nd, 2009 at 14:15
È più potente della virtualizzazione: in questo caso non vengono consumate risorse da macchine virtuali di nessun tipo; hai un sistema operativo completamente sandboxato e pienamente funzionante
novembre 22nd, 2009 at 14:16
Assolutamente si, da quando ho scoperto chroot lo uso per un sacco di cose
novembre 22nd, 2009 at 14:23
no vabbè, non diciamo cazzate
per isolamento e flessibilità, non c'è paragone
novembre 22nd, 2009 at 14:24
io chroot la uso spesso con systemrescue cd (Live CD) per entrare in arch e mettere a posto…devo dire che mi ha salvato il *ulo molte volte…
novembre 22nd, 2009 at 14:28
Infatti mi sono trovato a rimettere a posto parecchie volte, o a fornire istruzioni sul forum, per Arch che non bootavano più, o magari avevano un problema di troppo.
Chroot al potere!
novembre 22nd, 2009 at 15:52
Dici? Cioè, ovvio che non puoi far girare il sistema al 100%, ma per esempio un webserver in chroot gira tranquillamente, con accesso diretto alla macchina, senza lo spreco di risorse portato dalla virtualizzazione.
Questione di esigenze
novembre 22nd, 2009 at 15:58
Eh.. però è un inferno da mettere su in scenari un pelo più complessi, o se si ha bisogno di poter fare un revert dello stato..
In ogni caso è un ottimo sistema per fare ripristino, e una mutanda di latta aggiuntiva in casi particolari
novembre 22nd, 2009 at 16:27
Sulla reversibilità hai assolutamente ragione, i dischi vmdk/vdi sono il massimo
Tra l'altro un disco virtuale può essere replicato su centinaia di macchine mentre una chroot no.
novembre 22nd, 2009 at 18:40
io monterei anche /sys
novembre 22nd, 2009 at 18:46
Come mai?
Non ne ho mai avuto bisogno
In teoria uno dovrebbe montare anche /dev/pty al posto giusto ma chi ne ha voglia
novembre 22nd, 2009 at 19:05
Ottima guida per i newbie.
Complimenti!
novembre 22nd, 2009 at 19:21
Grazie
novembre 22nd, 2009 at 20:44
“ma per esempio un webserver in chroot gira tranquillamente”
Che poi è la soluzione migliore. per un webserver esposto alla giungla.
Se catturano la macchina, a parte il webserver non controllano un bel nulla.
Rispetto ad una vm la memoria è condivisa.
Puoi installare una intera distribuzione a 32 bit in chroot in una 64, oppure un'altra distribuzione in un chroot.
novembre 22nd, 2009 at 20:47
Per quello c'è solaris con ZFS è prossimamente un giorno chissà sto cavolo di brfs.
Inoltre i dischi vdi non brillano certo per velocità paragonati a un disco vero.
novembre 22nd, 2009 at 20:49
Io con arch ho preso l'abitudine di avere sempre 2 kernel, quello di arch che fa da riserva, e il mio vanilla che uso regolarmente.
Tranquillo che uno dei 2 boota regolarmente.
novembre 22nd, 2009 at 20:56
Beh anche il virtuale ha un suo perchè, però
novembre 22nd, 2009 at 20:57
Non se scoppia qualche servizio all'avvio
novembre 22nd, 2009 at 21:57
chroot è usabile per sandboxare qualunque cosa si voglia … alcuni esempi
- Linux From Scratch : http://www.linuxfromscratch.org/index.html
- Script per chroot-are privoxy , tor , distccd e irssi : http://northernsecurity.net/download/
novembre 22nd, 2009 at 22:02
utile, mi segno tutto, casomai un giorno mi servisse
novembre 22nd, 2009 at 22:02
Dimenticavo … con FreeBSD si può usare jail : http://www.freebsd.org/cgi/man.cgi?query=jail&f...
novembre 22nd, 2009 at 22:05
novembre 22nd, 2009 at 23:00
Io devo ancora mettermici bene. Ma alla fine, libro alla mano, siamo capaci tutti!
novembre 22nd, 2009 at 23:01
Grazie della dritta Unixistica
novembre 22nd, 2009 at 23:41
In 2 anni di arch (agosto 2007) l'unico fail al boot mi è capitato con un aggiornamento del kernel “ufficiale” che evidentemente non era stato creato e impacchettato “a modo”.
Da quel giorno sempre usato il kernel ufficiale bloccato alla prima versione della serie in corso, e il vanilla custom regolarmente aggiornato da ME.
Mai più visti casini.
novembre 23rd, 2009 at 16:01
e perchè non sarebbe replicabile ? la tarro e me la metto dove cavolo voglio, uguale uguale. anzi, non si verifica nemmeno il problema di immagini disco tra versioni del virtualizzatore diverse che a volte configura qualche incompatibilità.
novembre 23rd, 2009 at 16:05
Ah già mi sa che c'hai ragione ._.
novembre 23rd, 2009 at 20:10
dimenticavo (2) … altre chicche :
-l'opzione -o bind (in alcuni casi bisogna usare l'opzione -B oppure –bind ; è possibile usare la stessa opzione in /etc/fstab per montare direttamente al boot ; man 8 mount vi darà tutte le informazioni a riguardo
) serve a montare un filesystem su un altro mount point ed averlo quindi disponibile in due mount points
- nel caso di openssh , con le ultime versioni non è necessario farlo girare in chroot ( tra l'altro facendo i salti mortali ) a patto di non usare scp ma il solo sftp nella versione linkata staticamente al demone ssh : http://www.debian-administration.org/articles/590
novembre 24th, 2009 at 00:59
razzata == cazzata da root
novembre 24th, 2009 at 09:17
il modulo bind di mount serve per montare un determinato percorso in più punti, un pò come il link simbolico ma molto più potente in quanto viene gestito come una specie di partizione condivisa. Per dire, il repository di arch sul portalinux risiede fisicamente sulla home del tuo utente ma viene montato col modulo bind dentro la doc root del sito per renderla visibile
-t proc invece monta il filesystem di tipo proc, sostanzialmente ci hai azzeccato solo che non ti monta uno pseudo-proc, ma un proc vero e proprio solo che lo fai a manella
quando avvi la tua distribuzione gli script di init danno quel comando li per montarti /proc sul sistema.
Grande articolo cmq complimentazioni!
novembre 24th, 2009 at 10:09
Grazie dei complimenti, e grazie delle utilissime delucidazioni, Maestro
novembre 24th, 2009 at 10:09
LOL
novembre 24th, 2009 at 10:35
Disqus ha scritto:
novembre 24th, 2009 at 11:06
cmq un consiglio, imposta disqus per mettere in thread al massimo 2/3 risposte altrimenti diventa una roba illegibile
novembre 26th, 2009 at 20:33
Ci sono un paio di imprecisioni, per /dev è meglio fare “mount –rbind” e non “mount –bind” (sennò ti perdi pts e shm). E a volte è utile montare anche sysfs
novembre 27th, 2009 at 08:55
Mh, grazie del consiglio
Me lo segno
dicembre 2nd, 2009 at 10:45
[...] Con l’occasione vedremo anche un applicazione pratica del chroot, comando spiegato in maniera molto esaustiva dal nerd Bl@ster [...]
febbraio 5th, 2010 at 13:43
[...] Introduzione al chroot sul blog di Bl@ster. [...]
febbraio 13th, 2010 at 19:50
[...] Ottima introduzione al chroot sul blog di Bl@ster. [...]
aprile 25th, 2010 at 17:52
[...] articolo è uno spunto dal post di Bl@ster, ossia prepare un sistema per effettuare i nostri test con Arch Linux basato su [...]
giugno 8th, 2010 at 06:13
Hhe article's content rich variety which make us move for our mood after reading this article. surprise, here you will find what you want! Recently, I found some wedsites which commodity is colorful of fashion.
http://www.inin-from.com
agosto 16th, 2010 at 18:23
[...] del post di blaster [1] su come eseguire il chroot in un sistema, ho deciso di creare questa micro guida. Lo scopo è [...]