una bella novita': FreeBSD 10
Inviato: sabato 1 febbraio 2014, 20:36
sono sempre stato interessato a FreeBSD, sin da quando oracle compro' sun microsystems ed il futuro di OpenSolaris divenne incerto, poi certo, la sua fine.
OpenSolaris era parecchio promettente, e sebbene non maturo per un uso desktop, aveva parecchie caratteristiche al tempo invidiate da linux: (dopo aver scritto, ho deciso di mettere uno spoiler)
purtroppo, con la fine del progetto opensolaris, quanto di piu' simile ad esso era FreeBSD, che conoscevo (poco) e che aveva appena implementato una vecchia versione di zfs.
tanto vecchia che non supportava nemmeno la deduplicazione, e me ne accorsi solo un anno dopo cercando di attivarla su una macchina freebsd 8 non aggiornata. Ma il supporto alla deduplicazione, che credevo automatico, era quanto mi spinse a scegliere freebsd, da giovane ed idiota (non che sia cambiato).
FreeBSD aveva alcuni vantaggi:
-zfs
-jail parte del sistema base, un meccanismo di virtualizzazione a livello di sistema operativo simile alle zone solaris o ad openvz
-solidita' del sistema base. mai avuto un crash non dovuto ad un... intervento umano
-separazione netta tra il sistema base ed i software di terze parti, relegati ad /usr/local, che mai andavano ad intaccare i binari di sistema, le librerie di sistema, o le loro configurazioni.
-ottima documentazione
-flessibilita' del sistema dei ports. Gentoo si ispiro' a questi, ma rimangono flessibili senza la complessita' di gentoo. Hanno, penso, lo stesso numero di software di debian.
-facilita' di aggiornamento, con freebsd-update. facile ed indolore, e stai sicuro che esiste "separazione" tra aggiornare "il sistema" ed "i software"
-facilita' nel controllare l'integrita' del sistema base, sia per bassa complessita' che per la funzione "IDS" di freebsd-update, che confrontava un hash sha256 di ogni file di sistema con un "known good" specifico per release ed architettura, fornito dal progetto freebsd.
-si puo' innalzare il "securelevel" sino a non permettere il caricamento di moduli kernel o il cambiamento di regole di firewalling. lo si puo' decrementare solo riavviando.
gli svantaggi:
-poca integrazione. 2 diversi meccanismi per fare resource capping, per limitare le jail, per controllare memoria e cpu servivano due sottosistemi diversi, ed uno richiedeva ricompilazione del kernel... (mi e' sempre riuscita su bsd, a differenza di linux)
-arretratezza del sistema dei pacchetti binari, il che richiede dei punti a parte:
-i tool pkg_ erano del decennio scorso. pkg_add, ad esempio. se ci avete mai avuto a che fare, non devo commentare. Pensate a slackware, senza gli "abomini", come credo li consideri bubu
-scarsita' di pacchetti binari/precompilati. arretratezza del software, spesso senza nemmeno aggiornamenti di sicurezza
-non esisteva, come in debian, la policy di separare un pacchetto in piu' componenti, installabili a piacere. un port corrispondeva ad un pacchetto, ed era compilato con le opzioni di default
questo significa, ad esempio, che apache era un solo pacchetto, il port 'apache' compilato a default, idem php, e non esisteva mod_php con i pacchetti binari del progetto. neanche php-fpm.
-i pacchetti non erano firmati, ne esisteva checksum. facile installare pacchetti corrotti. facile essere compromessi installando software modificato dal mirror, o via mitm
questo portava a dovere usare i port.
i port erano, e sono, firmati, aggiornati, molto flessibili. Si possono scegliere con un comodo menu curses le opzioni di compilazioni desiderate.
il che significa anche compilare, compilare, compilare, e quando c'e' un aggiornamento, ricompilare, e ricompilare tutte le librerie da cui dipende il pacchetto, ed i port che le forniscono. Non bello, su una macchina lenta. una mazzata sui testicoli sufficiente, dopo un anno e mezzo, ad abbandonare l'os.
-mancanza di supporto alla virtualizzazione. Non c'era virtualbox, non c'era un hypervisor come kvm, poco supporto a xen. Potevi scegliere tra la virtualizzazione a livello di sistema operativo, con le jail, e l'emulazione qemu/bochs
-scarso supporto a portatili, drm/kms intel, etc.
cosa cambia FreeBSD 10?
in FreeBSD 10 abbiamo:
migliorato supporto hardware, ovviamente.
supporto ai portatili molto migliorato, con KMS intel (e credo anche amd), supporto a piu' SoC wifi.
un hypervisor, http://bhyve.org/, al suo primo esordio. E' simile a kvm, usa anche VirtIO per garantirsi supporto dei sistemi operativi gia' compatibili con kvm. Da provare, incerte stabilita' e performance.
pkg(ng). una nuova infrastruttura per i pacchetti binari, un nuovo package manager.
e' una novita' pari all'introduzione di APT in debian.
il progetto FreeBSD ha deciso di concentrarsi di piu' sui pacchetti binari, oramai necessari, specie con la crisi di utenti e fondi del progetto.
pkg introduce diverse novita':
-concetto di repository. Si ispira ad aptitude/apt-get.
-i pacchetti sono firmati. non direttamente come in linux:
il singolo pacchetto ha una descrizione che include l'hash sha256 di ogni file fornito, e del suo path nel sistema.
il repository fornisce un file con le "signatures", che include, per ogni pacchetto/definizione, il suo hash (suppongo sha256), ed altri valori che non ho ancora indagato.
la signature e' firmata, ed e' fornita la chive pubblica con cui e' firmata.
il sistema arriva, in /usr/share/keys/pkg, con l'hash/impronta di ogni chiave pubblica supportata, e supporta la revoca.
si', a differenza di linux che firma ogni pacchetto, a loro piacciono gli hash, ma il risultato e' lo stesso, e probabilmente e' piu' rapido.
a proposito di rapidita', pkg e' veloce, e si basa su un database sqlite stile rpm, mentre dpkg usa ancora migliaia di file.
permette ricerca, autoremove, aggiornamento, addirittura controllo di integrita', controlla l'integrita' dei pacchetti installati confrontando l'hash dei singoli file con quello descritto.
su ubuntu, se viene backdoorato apache, hai voglia ad accorgertene con apt.
l'installer supporta finalmente una installazione zfs base, che prima andava eseguita a mano.
e' stato introdotto questo: http://info.iet.unipi.it/~luigi/netmap/
che dovrebbe permettere ottime performance di rete per le app/nic compatibili.
zfs supporta il TRIM per gli ssd, e fuse e' nel sistema base.
gli sto dando una occhiata in vm, per ora, prima di decidere se passare al fisico, e sembra molto piu' user friendly. Alla portata degli utenti archlinux, mentre prima richiedeva competenze, e pazienza, solitamente tipiche degli utenti gentoo
OpenSolaris era parecchio promettente, e sebbene non maturo per un uso desktop, aveva parecchie caratteristiche al tempo invidiate da linux: (dopo aver scritto, ho deciso di mettere uno spoiler)
Spoiler
Mostra
ZFS. Presente il suo figlio illegittimo brtfs? Bene, ZFS era tutto questo, con qualcosa in piu', quindi un volume manager (una sorta), supporto alla deduplicazione dei dati, la compressione on the fly, gli snapshot, permetteva di creare array RAID software con un comando, e proteggeva dalla corruzione silente dei dati.
i dati nei dischi rigidi si corrompono, un bit cambia valore, e non lo scopri sino a che qualche file non si corrompe o qualcosa smette di funzionare. molti controller raid ignorano la cosa, si fidano del primo dato che arriva.
ZFS controllava per discrepanze, e teneva un hash dei blocchi. dalla modalita' menefreghista, alla modalita' nsa, alla modalita' menefrighista+controllo all'accesso. questo serviva ad individuare la corruzione silente, ed a "deduplicare" a livello di blocchi, file, o byte. Ovvero, hai 10 versioni di un filmato, con piccole modifiche o tagli. Con un volume zfs deduplicato, gran parte dei dati in comune tra i file verrebbero salvati una sola volta.
esisteva poi la possibilita' di riservare determinata capacita' a tenere copie dei dati da utilizzare qualora l'originale fosse risultato corrotto, stile fec.
insomma, gia' prima del 2010 era qualcosa di molto, molto futuristico e flessibile.
OpenSolaris aveva poi le "zone", un meccanismo di virtualizzazione a livello di sistema operativo, un po' come linuz vz. il kernel e' in comune, non c'e' questo overhead, ma possono esistere piu' "zone" separate, con piu' o meno privilegi, il loro utente root, le loro librerie. Vari ambienti.
OpenSolaris aveva lo scheduler di solaris, che solo recentemente linux ha avvicinato a modo suo, coi cgroup, ma ancora non ci siamo.
opensolaris supportava reti virtuali (crossbow) ben prima di Open vSwitch.
opensolaris supportava un modello di permessi molto avanzato, difficile da ottenere con sudo e selinux. non solo aveva un MAC come selinux, ma permetteva di delegare ad utenti normali compiti eseguibili da root, senza fornire a questi competo accesso root.
era possibile delegare a tiziocaio, con un meccanismo simile a sudo, la possibilita' di riavviare un servizio, diciamo apache. Ma non di cambiarne la configurazione, o di fermarlo. granulare e semplice.
ora, dico era possibile perche' opensolaris purtroppo e' morto, esistono cloni ed ovviamente, oracle solaris, che non posso permettermi, oltre che closed source.
i dati nei dischi rigidi si corrompono, un bit cambia valore, e non lo scopri sino a che qualche file non si corrompe o qualcosa smette di funzionare. molti controller raid ignorano la cosa, si fidano del primo dato che arriva.
ZFS controllava per discrepanze, e teneva un hash dei blocchi. dalla modalita' menefreghista, alla modalita' nsa, alla modalita' menefrighista+controllo all'accesso. questo serviva ad individuare la corruzione silente, ed a "deduplicare" a livello di blocchi, file, o byte. Ovvero, hai 10 versioni di un filmato, con piccole modifiche o tagli. Con un volume zfs deduplicato, gran parte dei dati in comune tra i file verrebbero salvati una sola volta.
esisteva poi la possibilita' di riservare determinata capacita' a tenere copie dei dati da utilizzare qualora l'originale fosse risultato corrotto, stile fec.
insomma, gia' prima del 2010 era qualcosa di molto, molto futuristico e flessibile.
OpenSolaris aveva poi le "zone", un meccanismo di virtualizzazione a livello di sistema operativo, un po' come linuz vz. il kernel e' in comune, non c'e' questo overhead, ma possono esistere piu' "zone" separate, con piu' o meno privilegi, il loro utente root, le loro librerie. Vari ambienti.
OpenSolaris aveva lo scheduler di solaris, che solo recentemente linux ha avvicinato a modo suo, coi cgroup, ma ancora non ci siamo.
opensolaris supportava reti virtuali (crossbow) ben prima di Open vSwitch.
opensolaris supportava un modello di permessi molto avanzato, difficile da ottenere con sudo e selinux. non solo aveva un MAC come selinux, ma permetteva di delegare ad utenti normali compiti eseguibili da root, senza fornire a questi competo accesso root.
era possibile delegare a tiziocaio, con un meccanismo simile a sudo, la possibilita' di riavviare un servizio, diciamo apache. Ma non di cambiarne la configurazione, o di fermarlo. granulare e semplice.
ora, dico era possibile perche' opensolaris purtroppo e' morto, esistono cloni ed ovviamente, oracle solaris, che non posso permettermi, oltre che closed source.
tanto vecchia che non supportava nemmeno la deduplicazione, e me ne accorsi solo un anno dopo cercando di attivarla su una macchina freebsd 8 non aggiornata. Ma il supporto alla deduplicazione, che credevo automatico, era quanto mi spinse a scegliere freebsd, da giovane ed idiota (non che sia cambiato).
FreeBSD aveva alcuni vantaggi:
-zfs
-jail parte del sistema base, un meccanismo di virtualizzazione a livello di sistema operativo simile alle zone solaris o ad openvz
-solidita' del sistema base. mai avuto un crash non dovuto ad un... intervento umano
-separazione netta tra il sistema base ed i software di terze parti, relegati ad /usr/local, che mai andavano ad intaccare i binari di sistema, le librerie di sistema, o le loro configurazioni.
-ottima documentazione
-flessibilita' del sistema dei ports. Gentoo si ispiro' a questi, ma rimangono flessibili senza la complessita' di gentoo. Hanno, penso, lo stesso numero di software di debian.
-facilita' di aggiornamento, con freebsd-update. facile ed indolore, e stai sicuro che esiste "separazione" tra aggiornare "il sistema" ed "i software"
-facilita' nel controllare l'integrita' del sistema base, sia per bassa complessita' che per la funzione "IDS" di freebsd-update, che confrontava un hash sha256 di ogni file di sistema con un "known good" specifico per release ed architettura, fornito dal progetto freebsd.
-si puo' innalzare il "securelevel" sino a non permettere il caricamento di moduli kernel o il cambiamento di regole di firewalling. lo si puo' decrementare solo riavviando.
gli svantaggi:
-poca integrazione. 2 diversi meccanismi per fare resource capping, per limitare le jail, per controllare memoria e cpu servivano due sottosistemi diversi, ed uno richiedeva ricompilazione del kernel... (mi e' sempre riuscita su bsd, a differenza di linux)
-arretratezza del sistema dei pacchetti binari, il che richiede dei punti a parte:
-i tool pkg_ erano del decennio scorso. pkg_add, ad esempio. se ci avete mai avuto a che fare, non devo commentare. Pensate a slackware, senza gli "abomini", come credo li consideri bubu
-scarsita' di pacchetti binari/precompilati. arretratezza del software, spesso senza nemmeno aggiornamenti di sicurezza
-non esisteva, come in debian, la policy di separare un pacchetto in piu' componenti, installabili a piacere. un port corrispondeva ad un pacchetto, ed era compilato con le opzioni di default
questo significa, ad esempio, che apache era un solo pacchetto, il port 'apache' compilato a default, idem php, e non esisteva mod_php con i pacchetti binari del progetto. neanche php-fpm.
-i pacchetti non erano firmati, ne esisteva checksum. facile installare pacchetti corrotti. facile essere compromessi installando software modificato dal mirror, o via mitm
questo portava a dovere usare i port.
i port erano, e sono, firmati, aggiornati, molto flessibili. Si possono scegliere con un comodo menu curses le opzioni di compilazioni desiderate.
il che significa anche compilare, compilare, compilare, e quando c'e' un aggiornamento, ricompilare, e ricompilare tutte le librerie da cui dipende il pacchetto, ed i port che le forniscono. Non bello, su una macchina lenta. una mazzata sui testicoli sufficiente, dopo un anno e mezzo, ad abbandonare l'os.
-mancanza di supporto alla virtualizzazione. Non c'era virtualbox, non c'era un hypervisor come kvm, poco supporto a xen. Potevi scegliere tra la virtualizzazione a livello di sistema operativo, con le jail, e l'emulazione qemu/bochs
-scarso supporto a portatili, drm/kms intel, etc.
cosa cambia FreeBSD 10?
in FreeBSD 10 abbiamo:
migliorato supporto hardware, ovviamente.
supporto ai portatili molto migliorato, con KMS intel (e credo anche amd), supporto a piu' SoC wifi.
un hypervisor, http://bhyve.org/, al suo primo esordio. E' simile a kvm, usa anche VirtIO per garantirsi supporto dei sistemi operativi gia' compatibili con kvm. Da provare, incerte stabilita' e performance.
pkg(ng). una nuova infrastruttura per i pacchetti binari, un nuovo package manager.
e' una novita' pari all'introduzione di APT in debian.
il progetto FreeBSD ha deciso di concentrarsi di piu' sui pacchetti binari, oramai necessari, specie con la crisi di utenti e fondi del progetto.
pkg introduce diverse novita':
-concetto di repository. Si ispira ad aptitude/apt-get.
-i pacchetti sono firmati. non direttamente come in linux:
il singolo pacchetto ha una descrizione che include l'hash sha256 di ogni file fornito, e del suo path nel sistema.
il repository fornisce un file con le "signatures", che include, per ogni pacchetto/definizione, il suo hash (suppongo sha256), ed altri valori che non ho ancora indagato.
la signature e' firmata, ed e' fornita la chive pubblica con cui e' firmata.
il sistema arriva, in /usr/share/keys/pkg, con l'hash/impronta di ogni chiave pubblica supportata, e supporta la revoca.
si', a differenza di linux che firma ogni pacchetto, a loro piacciono gli hash, ma il risultato e' lo stesso, e probabilmente e' piu' rapido.
a proposito di rapidita', pkg e' veloce, e si basa su un database sqlite stile rpm, mentre dpkg usa ancora migliaia di file.
permette ricerca, autoremove, aggiornamento, addirittura controllo di integrita', controlla l'integrita' dei pacchetti installati confrontando l'hash dei singoli file con quello descritto.
su ubuntu, se viene backdoorato apache, hai voglia ad accorgertene con apt.
l'installer supporta finalmente una installazione zfs base, che prima andava eseguita a mano.
e' stato introdotto questo: http://info.iet.unipi.it/~luigi/netmap/
che dovrebbe permettere ottime performance di rete per le app/nic compatibili.
zfs supporta il TRIM per gli ssd, e fuse e' nel sistema base.
gli sto dando una occhiata in vm, per ora, prima di decidere se passare al fisico, e sembra molto piu' user friendly. Alla portata degli utenti archlinux, mentre prima richiedeva competenze, e pazienza, solitamente tipiche degli utenti gentoo