Newsgroup: it.comp.os.linux.sys
Titolo: Creare chroot

mettiamo che io voglia creare un chroot per lanciarci tomcat (appserver
java), e voglio farlo nel minor tempo possibile.
Se copio l'intero sistema in una dir e chrooto su quella, funziona,
giusto? 
-- 
Herbie



Si. ma a te serve una ambiente per far girare tomcat, e così
facendo invece avrai messo tanta, ma tanta, ma tanta roba inutile... tra
cui, tanto per citarne una, persino il kernel, che in ambiente chroot
non ti serve a nulla.
su ubuntu/debian l'ambiente chroot si crea tramite il comando
"debootstrap". Cerca una guida per la tua distribuzione.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 "debootstrap". Cerca una guida per la tua distribuzione.
Ma anche no.
debootstrap ti installa una distro base, e si porta dietro
qualcosa tipo 100M di roba, tra cui se ben ricordo, perl
e python, cosa che in chroot non servono.
Un chroot mediamente se supera i 10M è già troppo.
Sono una manciata di librerie, il programma da chrootare e basta.
Che poi con un debootstrap si possa fare anche un chroot è un
conto, ma non è il sistema corretto per farlo, dato che installa
mezzo sistema.

 e python, cosa che in chroot non servono.
Se tu stai parlando di chrootare il demone ftp sono d'accordo con te.
E' una lista di programmi ridotta, che si porta appresso perché se non
ricordo male ti fa installare qualche metapacchetto di base. Non è una
gran cosa e non è un gran problema e a rimuove qualche pacchetto non ci
vuole nulla.
Ma fai una prova a fare 'apt-rdepends tomcat6' .... e poi fammi
sapere ... ops .... tra le dipendenze vedo anche un perl-base che
contiene anche l'eseguibile di perl.


 e python, cosa che in chroot non servono.
� il prezzo per fare le cose "nel minor tempo possibile."
Che sono oggi 100MB? Non valgono un'ora di tempo sprecata a cercare e
copiare le librerie a mano.

Concordo!!
"Nisciuno" <nisc...@nisciuno.invalid> ha scritto nel messaggio 
news:hs8ego$hec$1...@speranza.aioe.org...


 contiene anche l'eseguibile di perl.
Si, ma tu hai detto che (cito):
"su ubuntu/debian l'ambiente chroot si crea tramite il comando debootstrap".
Be, e' sbagliato.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 copiare le librerie a mano.
Be, puoi sempre scriptare.
A parte questo, su una VPS 100M potrebbero fare la differenza, mentre
invece � sbagliato il concetto. Il chroot non lo fai con quel tool, quel
tool pu� essere usato *anche* per fare il chroot (per questioni di
praticit�) ma non va bene generalizzare dicendo che su debian per fare
il chroot si deve usare quel tool, perch� fa una installazione base di
un intero sistema. Il chroot � un subset di un sistema, grazie al
cappero che se installi tutto il sistema avrai anche un chroot pronto.


 Be, e' sbagliato.
Lasciami stare il mio Adamo che questa volta ha risposto in modo
congruo alla richiesta dell'OP.
Poi si`, l'affermazione sopra non e` precisa per cui e` giusto
precisare, ma a domanda la risposta data risolveva in modo congruo.

 precisare, ma a domanda la risposta data risolveva in modo congruo.
Be, sinceramente non volevo polemizzare tanto per fare, ma il
chroot non si fa con debootstrap. Non ho idea delle librerie necessarie
per tomcat, ma installare un sistema base come chroot secondo me �
sbagliato proprio concettualmente. Da un certo punto di vista, vanifichi
i vantaggi del chroot, se dentro la gabbia ci metti il mondo.


 A parte questo, su una VPS 100M potrebbero fare la differenza,
Il mondo è già complicato! Non complichiamolo ulteriormente.
L'OP ha chiesto: va bene copiare giga e giga a rotta di collo per
tirare su un ambiente per tomcat?
Gli ho suggerito un metodo alquanto rapido che  - ahimé - gli farà
sprecare una ventina di MB in più del previsto, ma rispetto al metodo
da lui proposto gli farà risparmiare svariati giga e una notevole
quantità di tempo rispetto a metodi alternativi.

 quantit� di tempo rispetto a metodi alternativi.
AFAIR esiste uno script che si piglia un eseguibile e ti crea il
chroot a partire da quello, facendo il check ricorsivo delle dipendenze.


 a partire da quello, facendo il check ricorsivo delle dipendenze.
Se la memoria non mi inganna uno è makejail
Enrico

 chroot a partire da quello, facendo il check ricorsivo delle dipendenze.
Ecco, il punto è proprio questo, come trovo tutti i file da mettere in
chroot?
Per ora ho creato il mio chroot, con un metodo simile a quello indicato,
ma per gentoo. In pratica ho installato da stage3 (sistema base) e
aggiunto jdk e tomcat
Mi sono venuti sun 670Mb, se tolgo portage (il sist. di dipendenze
gentoo), ma d'altra parte solo il jdk 1.6 sono 200Mb....
Per ora non è un problema perché sta su un disco a casa mia, ma certo se
avessi avuto un server virtuale..
-- 
Herbie

 gentoo), ma d'altra parte solo il jdk 1.6 sono 200Mb....
'mmazza oh :o)
Ma Gentoo ti installa tutto il suo ambiente per compilare (leggasi:
tutte le sue menate per far funzionare portage, make, gcc... blabla),
anche in chroot?
Se è così il caso di gentoo è un p' particolare e non credo che
riuscirai a "striminzirla" più di tanto. Da un'latra parte ti vuoi
riservare la possibilità di aggiornarla di tanto in tanto. Quindi come
fai a rimuovere portage?
Se penso che a ogni aggiornamento ti devi mettere a compilare su ogni
chroot, non so perché ma - anche se amo gentoo - la cosa mi pare che
possa ispirare il suicidio.

 Se la memoria non mi inganna uno è makejail
Mi sa anche a me.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 Mi sa anche a me.
ma probabilmente, se ti crea un ambiente più ridotto, mi sa anche a
me.
Solo che l'OP con la Gentoo è nella mXXXX più totale: altro che 10 MB
e 100 MB ^_^

 i vantaggi del chroot, se dentro la gabbia ci metti il mondo.
Dici? Il chroot non � nato per risparmiare spazio, ma per avere processi
attivi su filesystem separati nello stesso sistema. Se nell'ambiente
parallelo ci metti il mondo amen, avrai il tuo mondo parallelo.

 parallelo ci metti il mondo amen, avrai il tuo mondo parallelo.
A me han sempre insegnato che una cosa quando non c'�, non si rompe.
Analogamente, se nel tuo ambiente ci metti il mondo, avrai anche un
mondo di possibilit� in pi� che un malintenzionato possa uscire dalla
gabbia.
Probabilmente son due modi differenti di vedere le cose, io meno roba
metto meglio �. A quanto pare a te piace maggiormente un approccio in
stile Windows, che di default si porta dietro tutto.
Per� non ho capito una cosa, che centrano i filesystem in un chroot?


 Per� non ho capito una cosa, che centrano i filesystem in un chroot?
Perch� questo � uno dei suoi vantaggi principali. La sicurezza aggiuntiva
del chroot non � sostanziosa, qualunque processo di root ne pu� uscire, e i
processi non privilegiati si possono mettere al sicuro in altri modi pi�
semplici o pi� affidabili. Se comunque uno mette un processo in chroot per
questo motivo, farlo sullo stesso filesystem del sistema ospite � un
controsenso.
� quello che fanno ad es. su 
sdf.lonestar.org
 per tutti gli accessi di shell
sul sistema. In caso di disastro si da di restore e si riparte. Se questo
non basta allora serve un ambiente virtuale, ma in questo caso altro che
100MB ti servono...

 controsenso.
Forse oggi non sono del tutto concentrato, ma ... "stesso filesystem" si
intende "stessa partizione"? 
-- 
Herbie

 intende "stessa partizione"?
Direi di si`.
Andrea

 Direi di si`.
Ma perché chroot su partizione separata è più sicuro? 
La partizione sarà tipo /mnt/chroot, e non si può uscire da lì come da
una dir? non è, cioè, una dir comune?
-- 
Herbie

 e 100 MB ^_^
sì, però scusa, guarda che gentoo i pacchetti li crea come quelli che
installate binari, l'unica cosa è che servono installati anche i tool
per la compilazione, che a parte gcc non so quanto occupino
-- 
Herbie



 Te lo dico subito:
$ apt-get remove gcc-4.4
[SNIP]
After this operation, 93.3MB disk space will be freed.
Do you want to continue [Y/n]? 
Insieme a gcc, toglie g++ ....
ci sono gli header, che in una chroot non servono a nulla, ci sono
tante altre cose. Secondo me con la gentoo in un ambiente del genere
l'80% dello spazio lo sprechi  con portage
Chiaro che nel tuo caso c'è pure il JDK, e Tomcat che non sono un
piccolo demone.




Esiste qualche motivo per cui sono state concepite le jail di bsd, le
zone di solaris, le KVM di linux.
mo' mettiamo da parte il dicorso della partizione.
Ti spiego cosa mi viene in mente e cosa si può fare di cattivo e anche
di semplice:
Tralasciamo il fatto in se che root dentro la gabbia può killare
processi al di fuori della gabbia (eh già! Pensa che ti può buttare
tutto giù da dentro la gabbia!).
E se per caso ti corrisponde l'ID numerico del gruppo del web server,
l'utente del chroot può killare l'utente dell'ambiente superiore).
Supponiamo che abbia fatto le cose per bene e non abbia montato in
bind l'intera /dev, ma solo /dev/shm e /dev/pts, in modo tale da
evitare che possa segare i device dal chroot. Cosa fa allora
l'ipotetico "criminal attacker"?
apt-get install udev (blabla..... lavora un pò.... si installa tutto)
provo a lanciare udevd
mmh ... mi da errore: error binding control socket, seems udevd is
already running
Un grep su udev del comando ps mi mostra il  processo che gira fuori
dalla gabbia.
Io sono root nella gabbia e lo killo (non ci provoo nemmeno perché mi
secca....)
Lancio il mio udev, configuro smanetto, appena mi compare /dev/sda lo
sputtano e ho sputtanato tutto il sistema.
Diciamo che, puoi metterti a fare un po' di tuning, del tipo:
dall'esterno della gabbia togli la shell al root che è dentro la gabbia,
e poi lanci un chattr +i sul file passwd. Ti puoi inventare questo e
altro. Di fatto hai un sottosistema che vede i processi del sistema
dove sta girando e pu
Io uso chroot perché necessito di due apache: uno con mpm-worker e uno
con mpm-prefork.


 Diciamo che, puoi metterti a fare un po' di tuning, del tipo:
Nelle opzioni di grsec, puoi impostare gli enforce per il chroot.
Non chiedetemi altro: non l'ho mai usato in "produzione".

Il Mon, 10 May 2010 12:10:04 +0000, Enrico scrisse:

Ci sarebbe, ad esempio
mkchroot.sh
distribuito con rssh sotto debian...

 Ma perché chroot su partizione separata è più sicuro?
Non lo so. Non l'ho detto. Magari forse perche' su un filesystem puoi
usare delle opzioni di mount che lo rendono piu` sicuro (ammesso che
ci funzionino ancora i programmi chrooted) tipo noexec.
Comunque mi risulta strano che per Gentoo non ci sia documentazione su
come creare un ambiente chrooted minimale, dato che era famosa per
l'ottima documentazione e l'utenza particolarmente sveglia e
"hackerosa".
Andrea

 
posso sbagliare, ma  secondo me gli propone semplicemente il
vecchio processo di installazione della Gentoo, quello che partiva da
chroot e che ovviamente includeva portage e i tool per la compilazione.
