Newsgroup: it.comp.os.linux.sys
Titolo: OpenVZ o LXC?

Leggevo che da Debian 7 il supporto a OpenVZ sarà rimosso in favore di LXC o analogo.
 
Quindi, ad oggi, volendo isolare determinate applicazioni senza mettere in piedi intere VM portandosi dietro tutto il sistema operativo, cosa usereste? LXC si può ritenere stabile?
 
Per me è fondamentale poter limitare il quantitativo di RAM, CPU e disco allocata ad ogni istanza e se riuscissi a farlo senza installare ogni volta 1GB di sistema operativo per portarmi dietro solo Apache, sarebbe meglio.
 
(che poi, AFAIK, anche VZ si porta dietro l'intero sistema, ma ha sicuramente meno overhead di KVM o Xen)

 LXC o analogo.
 
 
Le soluzioni opensorc sono essenzialmente  3:
 
- openvz
- lxc
- linux-vserver
 
La meno matura è lxc.
 
Vserver lo uso da secoli in produzione ma da wheezy non sarà in debian 
(tanto mi compilavo sempre i kernel a manella, poco male)
 
Openvz è quella che mi piace meno ma per te credo sia l'unica che 
permette di assegnare cpu e memoria secondo necessità in maniera decente.
 
Afaik.
 

 permette di assegnare cpu e memoria secondo necessità in maniera decente.
 
A dire il vero, io devo poter far girare istanze di apache isolate e limitarle all'utilizzo, di, ad esempio, 200MB di ram.
vorrei ovviamente evitare di portarmi dietro giga e giga di sistema operativo (anche se tramite un debootstrap riesco a fare una base piuttosto piccola) dove di quei 200MB 198 sono del sistema e 2MB restano ad apache)
 
Mi serve qualcosa con veramente poco overhead e LXC mi sembrava perfetto.
 
Non conosco vserver, senza che mi vado a leggere 200 pagine, sai dirmi se il guest si porta dietro l'intero sistema operativo?
 
 
(ho fatto ora un debootstrap su Ubuntu e viene 278M, più che accettabile, il problema dei sistemi di virtualizzazione standard è che devono virtualizzare tutto mentre a me basterebbe dal kernel in giù, in stile VZ)

 stile VZ)
 
OpenVZ mai usato.
Sia LXC che linux-vserver necessitano di sistemi completi a meno del 
kernel e del bootloader.
Fondamentalmente, considerale delle chroot avanzate e le uso anche io per 
isolare i vari servizi (apache in primis).
 
Quindi sia con lxc che con vserver devi bootstrappare.
 
Nota: lxc era qualche mese fa molto molto indietro in termini di 
sicurezza e uscire dalla jail (o fare danni fuori) era molto semplice.
Non so se la situazione sia cambiata nell'ultimo periodo.
 

 Leggevo che da Debian 7 il supporto a OpenVZ sarï¿œ rimosso in favore di LXC o analogo.
 
Se vuoi un consiglio per questo utilizzo installati proxmox. E' una
Debian squeeze e supporta nativamente openvz e KVM (sempre mantenuti
aggiornati) e ti permette di gestire tutto al meglio in modo semplice.
Volendo puoi anche dare ai clienti l'accesso diretto all'interfaccia web
di configurazione per operare sulle loro macchine.
Essendo sponsorizzata dal governo austriaco ï¿œ molto ben seguita e ben
supportata (mai avuto un problema serio per causa sua fino ad oggi).
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 Non so se la situazione sia cambiata nell'ultimo periodo.
 
L'ho notato. Non credo sia un problema visto che gli utilizzatori avranno accesso solo ad apache ed a un repository di git. Non credo di rilasciare ssh.
(fai riferimento al link fatto da dentro il guest per eseguire comandi sull'host?)
 

 sull'host?)
 
... ed in generale al fatto che essendo in sviluppo, i kernel non erano 
ancora pronti al 100% sul fronte sicurezza...
 
La situazione attuale non la conosco.

 La situazione attuale non la conosco.
 
Bah, troppe complicazioni, se tanto devo ricompilare vado di OpenVZ, 
che almeno funziona ed è pensato e progettato allo scopo.
 
Tnx.

 meglio.
 
mmh... il sistema in realtà lo installi sempre. Si tratta di un sistema 
leggermente customizzato (niente di particolare: qualche init-script 
modificato).
Insieme a LXC ci sono degli script per creare dei sistemi custom, tipo 
ubuntu, debian, fedora.
 
 
 

 in Ubuntu il passo è già stato fatto da un paio di anni.
 
Il motivo qual'è stato, si sa?
 
Visto che il funzionamento di LXC è analogo a quello di OpenVZ (inizialmente pensavo che LXC si portasse dietro solo le applicazioni che volevo io) tra i due preferisco OpenVZ, sicuramente più stabile e maturo.

 Il motivo qual'ï¿œ stato, si sa?
 
LXC ï¿œ nativamente disponibile nel kernel in quanto per svolgere il
proprio compito sfrutta solo caratteristiche giï¿œ disponibili nei
sorgenti vanilla. In particolare sfrutta cgroups e namespaces per
isolare i sistemi.
 
Questo offre certamente dei vantaggi significativi, non in termini di
flessibilitï¿œ che ï¿œ certamente superiore in openvz o in virtualserver, ma
in termini di manutenzione e patching.


 in termini di manutenzione e patching.
 
Ecco perchè volevo evitare di ricompilare.
Mi è venuto in mente ora: i clienti non avranno *MAI* accesso come root al container, questo è poco ma sicuro, pertanto anche il bug famoso che permetteva
di eseguire comandi sull'host tramite un link non sarebbe sfruttabile nemmeno
in versioni buggate. Dico bene?
 
Ad oggi risultano bug di cui tenere conto? Considerato che:
 
a) al 99% i clienti non useranno SSH
b) quel 1% di clienti userà SSH ma *MAI* come root e magari castrato ulteriormente con jailkit o qualche altro sistema per permette un chroot di ssh
 
considerati questi 2 punti, LXC dovrebbe essere considerato adeguatamente sicuro.

 considerati questi 2 punti, LXC dovrebbe essere considerato adeguatamente sicuro.
 
Non ne farei una questione di sicurezza di LXC quanto di adeguatezza
alle tue necessitï¿œ.


 alle tue necessità.
 
Ho fatto dei rapidi test ieri e sembra perfetto.
Devo solo verificare se parte l'oom-killer in caso si termini la ram.