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). :P

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 :D

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 :mrgreen:

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

Per una spiegazione completa dei comandi integro il commento del buon Alex Anghelone, che ci dice a cosa serve tutto questo:

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 :D quando avvi la tua distribuzione gli script di init danno quel comando li per montarti /proc sul sistema.

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 :mrgreen:

Nessun post correlato. Ritenta, sarai più fortunato.

This entry was posted in Arch, Gentoo, Guide, Linux. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.
  • Hilinus

    Ottima guida per un comando veramente versatile e potente… gentoo insegna ;)

  • http://santerotondi.net/ saten

    Bell'articolo, tornerà utile a molti :D

    Certo che chroot è un po' la virtualizzazione dei poveri ;D

  • http://dottorblaster.it/ Bl@ster

    È 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 :)

  • http://dottorblaster.it/ Bl@ster

    Assolutamente si, da quando ho scoperto chroot lo uso per un sacco di cose :D

  • http://santerotondi.net/ saten

    no vabbè, non diciamo cazzate :D
    per isolamento e flessibilità, non c'è paragone :P

  • http://www.ugaciaka.wordpress.com/ ugaciaka

    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…

  • http://dottorblaster.it/ Bl@ster

    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! :D

  • http://dottorblaster.it/ Bl@ster

    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 ;)

  • http://santerotondi.net/ saten

    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 :)

  • http://dottorblaster.it/ Bl@ster

    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. :D

  • http://opensource2007.netsons.org LuNa

    io monterei anche /sys ;)

  • http://dottorblaster.it/ Bl@ster

    Come mai?
    Non ne ho mai avuto bisogno :P
    In teoria uno dovrebbe montare anche /dev/pty al posto giusto ma chi ne ha voglia :D

  • http://www.archlinux.it/ Giovanni Scafora

    Ottima guida per i newbie.
    Complimenti!

  • http://dottorblaster.it/ Bl@ster

    Grazie :)

  • telperion

    “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.

  • telperion

    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.

  • telperion

    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.
    ;)

  • http://dottorblaster.it/ Bl@ster

    Beh anche il virtuale ha un suo perchè, però ;)

  • http://dottorblaster.it/ Bl@ster

    Non se scoppia qualche servizio all'avvio :D

  • linuser

    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/

  • http://dottorblaster.it/ Bl@ster

    utile, mi segno tutto, casomai un giorno mi servisse :)

  • linuser

    Dimenticavo … con FreeBSD si può usare jail : http://www.freebsd.org/cgi/man.cgi?query=jail&f

  • Hilinus

    :D LFS… la provai quest'estate, con tanto di X e pekWM. Molto reattiva ma per me rimane un esercizio di stile… interessante esperienza comunque.

  • http://dottorblaster.it/ Bl@ster

    Io devo ancora mettermici bene. Ma alla fine, libro alla mano, siamo capaci tutti! :D

  • http://dottorblaster.it/ Bl@ster

    Grazie della dritta Unixistica ;)

  • telperion

    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.
    :D

  • http://opensource2007.netsons.org LuNa

    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à.

  • http://dottorblaster.it/ Bl@ster

    Ah già mi sa che c'hai ragione ._.

  • linuser

    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

  • http://it.wikipedia.org/wiki/Speciale:PaginaCasuale scimmia

    razzata == cazzata da root

  • http://www.ilportalinux.it M0rF3uS

    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

    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 :D quando avvi la tua distribuzione gli script di init danno quel comando li per montarti /proc sul sistema.

    Grande articolo cmq complimentazioni!

  • http://dottorblaster.it/ Bl@ster

    Grazie dei complimenti, e grazie delle utilissime delucidazioni, Maestro :D

  • http://dottorblaster.it/ Bl@ster

    LOL

  • http://www.ilportalinux.it M0rF3uS

    Disqus ha scritto:

  • http://www.ilportalinux.it M0rF3uS

    cmq un consiglio, imposta disqus per mettere in thread al massimo 2/3 risposte altrimenti diventa una roba illegibile

  • http://blog.redaelli.eu/ Timothy

    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 :)

  • http://dottorblaster.it/ Bl@ster

    Mh, grazie del consiglio :)
    Me lo segno :P

  • Pingback: Installare openfiler su una penna usb | Il Portalinux

  • Pingback: dARCH LINUX » Blog Archive » Creare un chroot a 32 bit in un sistema a 64

  • Pingback: Darch Linux » Blog Archive » Creare un chroot a 32 bit in un sistema a 64

  • Pingback: carmine's blog » Creare un ambiente di test con chroot!

  • http://www.nike-air-force-one.com nike air force 1

    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

  • Pingback: Crearsi un piccolo ambiente di test con Archlinux « Tulug

  • Xaber1488

    Grazie mille Blaster! Era da tempo che cercavo una guida semplice e chiara riguardante chroot! Complimenti!

  • http://dottorblaster.it/ Bl@ster

    Dai che divento rosso poi :P

  • Pingback: Creare un ambiente di test ArchLinux con chroot! « Carmine Sorrentino's Blog