Tags archives: alessandro-rendina

 

0

Virtual Machine Manager


Virtual Machine Manager o anche virt-manager é un interfaccia utente per desktop progettata per gestire le macchine virtuali attraverso libvirt. scritto in Python sviluppato da Redhat e rilasciato sotto licenza GPLv2.

Le principali funzionalità di virt-manager sono:
  • creare, modificare, avviare e fermare una macchina virtuale,
  • accedere alla console delle VM,
  • visualizzare le statistiche sulle performance delle VM,
  • usare macchine virtuali KVM, Xen, o QEMU controllandole sia in locale che in remoto,
  • usare container LXC

Nel caso di Fedora, virt-manager si collega alla libreria libvirt per creare macchine di tipo KVM.
Le VM in Fedora vengono lanciate in “Full Virtualization”, cioé utilizzano delle funzionalitá hardware del processore per fornire alle VM un ambiente completamente virtualizzato: Il sistema operativo ospite ha a disposizione tutte le funzionalitá come se girasse su un hardware reale.
Fedora mette a disposizione diversi software per collegarsi alla libreria libvirt. Libvirt é una libreria che permette di collegarsi in maniera indipendente all’hypervisor che si intende usare. I tools che Fedora mette a disposizione per collegarsi a libvirt sono:
  • virsh
  • virt-manager
  • virt-install

Per chi usa GNOME esiste anche un software chiamato gnome-boxes che ha grosso modo le stesse funzioni di virt-manager.

Per installare tutti i software di virtualizzazione Fedora mette a disposizione un gruppo apposito, per avere informazioni a riguardo:
dnf group info “Virtualization”

per installarlo:
dnf group install “Virtualization”

Le macchine installate da virt-manager utilizzeranno una rete privata, se si ha bisogno di esporre i servizi delle proprie macchine su altre reti si puó usare firewalld o iptables per effettuare forward su porte specifiche o creare un bridge come descritto in un mio articolo precedente.

Per creare una nuova macchina virtuale, si deve lanciare virt-manager e fornire la password di root o la propria se si fa parte del gruppo sudoers.
Con virt-manager é possibile anche aprire un hypervisor remoto. Per fare questo é sufficiente prendere dal menu File la voce “Add a connection” e inserire i dati SSH del server che si intende utilizzare. Questo tipo di connessione é veramente comoda per l’utilizzo di macchine virtuali su un server internet.

Per creare una macchina virtuale si puó prendere la voce “New virtual machine” sempre dal menu File o cliccare sul bottone corrispondente. Si aprirá il wizard per la creazione di una nuova VM.

Il percorso consiste di cinque passi:
  1. scegliere il tipo di installazione,
  2. scegliere il media di installazione,
  3. configurare quanta memoria e quante cpu utilizzare,
  4. configurare lo spazio a disposizione della VM,
  5. dare un nome alla macchina ospite (guest), configurare la rete, architettura, e altre impostazioni hardware.

Il wizard inizia con la selezione del tipo di installazione, sceglieremo “Local install media”. É possibile usare un DVD-ROM o una Iso, se si sceglie la iso apparirá una finestra che permette di sfogliare tra le cartelle.

La finestra riconoscerà automaticamente il sistema operativo, se non riesce é possibile selezionarlo dal menu a tendina.

Cliccando su forward si accede alla finestra successiva che permette di configurare il numero di CPU da utilizzare e la quantitá di memoria. Per le mie esigenze io di solito metto tutte le CPU che ho a disposizione e 4GB o 8GB di memoria, ma questo dipende da cosa si intende fare con la macchina.


Adesso si deve configurare lo spazio a disposizione, il tipo di filesystem utilizzato é dinamico, cioé si “allargherà” man mano che inserite dati reali. Quindi dovete pensare alla dimensione massima che pensate di utilizzare, per le mie esigenze di solito 60GB sono piú che sufficienti.
Il successivo passaggio consiste nell'installazione del sistema operativo.

Virtual Machine Manager é un ottimo software per la gestione di macchine virtuali, io l’ho trovato particolarmente utile nella gestione remota. Permette infatti di installare un sistema operativo in remoto e ottenere la sua console.

Alcuni riferimenti:
https://en.wikipedia.org/wiki/Virtual_Machine_Manager
https://virt-manager.org/
https://docs.fedoraproject.org/en-US/Fedora/25/html/Virtualization_Getting_Started_Guide/index.html

 

0

Creare un bridge con Network-Manager

Trattare le macchine virtuali in articoli della lunghezza di due pagine stampate è complicato. L'argomento è vasto e necessiterebbe di continui approfondimenti. Questo articolo non tratta specificatamente le macchine virtuali, in realtà, tratta le reti. Ma dopo aver configurato il bridge in questo modo sarà possibile “agganciargli” sia dispositivi virtuali, sia dispositivi reali a seconda delle proprie esigenze.
Come si è già detto, in primo luogo dobbiamo verificare che il nostro processore supporti la virtualizzazione, questo si può verificare cercando la voce “vmx” in /proc/cpuinfo per i processori Intel e “svm” in quelli basati su AMD.
Il modulo che deve essere caricato dal kernel si chiama “kvm”, c'è un secondo modulo che si chiama "kvm_intel" o "kvm_amd" a seconda del proprio processore. La maggioranza delle distribuzioni carica questi moduli all'avvio o automaticamente.
Per l'utilizzo di questo software è necessario avere i privilegi di root o un utente sudo, è possibile effettuare configurazioni con privilegi inferiori, ma questo va oltre lo scopo del nostro articolo.

Per l'installazione useremo una Fedora 25, in questo articolo installiamo solamente il software necessario, la configurazione delle macchine virtuali verrà trattata in altri articoli. Quindi:

dnf install qemu-kvm libvirt virt-install bridge-utils
systemctl start libvirtd
systemctl enable libvirtd

Adesso andiamo a creare il bridge, useremo nmcli l'interfaccia a linea di comando di network-manager:

# aggiungiamo il bridge
nmcli c add type bridge autoconnect yes con-name br0 ifname br0

significato delle opzioni (man nmcli e man nm-settings):
  • c, con, connection: network-manager salva le configurazioni di rete come “connection”. Le “connection” descrivono come creare o connettersi ad una rete.
  • add: crea una nuova connessione utilizzando le proprietà specificate.
  • type bridge: specifica il tipo di connessione
  • autoconnect yes: la connessione deve essere effettuata automaticamente appena la risorsa diventa disponibile.
  • con-name br0: nome della nuova connessione
  • if-name br0: il nome dell'interfaccia di rete

# impostiamo l'indirizzo IP
nmcli c mod br0 ip4 192.168.10.10/24 ipv4.method manual

significato delle opzioni:
  • mod, modify: aggiunge, modifica o rimuove proprietà nel profilo della connessione. La proprietà è specificata subito dopo, nel caso specifico, br0.
  • ip4, ipv4.addresses: array di indirizzi di rete.
  • method: l'indirizzo viene impostato manualmente.

# impostiamo il gateway
nmcli c mod br0 gw4 192.168.10.1

significato delle opzioni:
  • gw4, ipv4.gateway: gateway

# impostiamo il DNS:
nmcli c mod br0 ipv4.dns 192.168.10.1

significato delle opzioni:
  • ipv4.dns: dns

# cancelliamo le impostazioni attuali della scheda di rete (ho scelto eth0)
nmcli c del eth0

significato delle opzioni:
  • del, delete: cancella una connessione configurata

# aggiungiamo l'interfaccia come membro del bridge
nmcli c add type bridge-slave autoconnect yes con-name eth0 ifname eth0 master br0

significato delle opzioni:
  • bridge-slave: si aggancia al bridge
  • master: nome del dispositivo master

effettuate un reboot e verificate che il bridge sia operativo lanciando “ip addr”.

Network-Manager è un software complesso e di livello molto alto. Ha una montagna di opzioni e quando si comincia a comprenderlo diventa come un coltellino svizzero. Difficile farne a meno.
Con questo articolo spero di aver risposto alla domanda di jboss, se ho dimenticato qualcosa scrivetelo nei commenti diventerà uno spunto per il prossimo articolo.
Non pretendo di essere completo ed esaustivo, anzi, preferisco dimenticare qualcosa e lasciare che la mente di chi legge cominci a lavorare per cercare la soluzione.

 

0

Virtual Machines


Quando ero ragazzo, se volevo studiare un sistema operativo, dovevo installarlo nel computer e probabilmente distruggere tutti i miei dati finché non capivo come funzionava.
Ricordo una legge di Murphy che diceva: “La preparazione tecnica di un sistemista è direttamente proporzionale ai danni subiti dal suo sistema”.
Oggi per fortuna è possibile simulare praticamente qualunque cosa.
Per esempio, puoi creare quattro macchine virtuali in un computer, quattro in un altro e farle comunicare tra loro, simulando uno scambio di dati tra due data-center.
Questi sistemi ormai sono talmente affidabili, che l'unica differenza apprezzabile rispetto ad una macchina reale, è nelle prestazioni. Non è un caso che Cloud e Cluster ormai sono strettamente connessi con le virtualizzazioni e le containerizzazioni.
Per quanto riguarda le implementazioni, esistono molte soluzioni e la maggioranza possono essere usate a livello professionale. Io ne ho installate diverse, ma la mia preferita, quando devo studiare o testare qualcosa, è KVM (Kernel-based Virtual Machine). KVM, è un'infrastruttura che si innesta nel kernel di Linux e permette di implementare la virtualizzazione da parte di altri software.
Per ottenere questo risultato sfrutta Intel VT (Intel Virtualization Technology) o AMD-V (AMD Virtualization).
KVM ha, in diversi casi, anche il supporto alla paravirtualizzazione, che non è una vera e propria virtualizzazione, ma è un sistema di condivisione dell'hardware gestito dal kernel ed è molto usato ad esempio per le schede di rete, migliorando le prestazioni del sistema virtualizzato.
Per contro, il crash di un dispositivo paravirtualizzato in una macchina virtuale può provocare crash anche nelle altre. Per implementare questo tipo di soluzione il kernel ospitante deve essere modificato, da qui la necessità di un'infrastruttura a livello kernel.
Naturalmente, non esiste solo KVM, esistono anche altre soluzioni e tra le più famose ci sono: LXC, OpenVZ, Xen. Queste seguono gli stessi principi, per poi dividersi nei dettagli e nelle implementazioni, a volte per ragioni storiche a volte per esigenze e obiettivi diversi.
Come dicevo, questa infrastruttura si trova a livello del kernel e per usarla bisogna “mandare qualcuno a parlarci”. Ossia ci vuole un software specifico, e di solito quando ci vuole un software ci vogliono anche delle librerie. Sto parlando di Libvirt.
Esistendo diverse implementazioni a livello kernel, esistono anche specifiche chiamate di sistema per ogni implementazione.
I programmatori si troverebbero quindi, costretti ad imparare ogni chiamata di KVM o di OpenVZ, o di qualunque altra implementazione. Libvirt risolve questo problema unificando queste chiamate e creando astrazione. Il programmatore può in questo modo disinteressarsi della specifica implementazione, concentrandosi sul suo progetto.
Libvirt è composta di un'API (Advanced Programming Interface), un daemon e un tool di management, così come dei wrapper, che permettono di comunicare con la libreria attraverso linguaggi ad alto livello come Python, Perl, Ocaml, Ruby, Java, Javacript (via Node.js) e PHP.
I tool di management più famosi sono virsh (a linea di comando) e virtual machine manager (grafico).
Veniamo all'ultimo pezzo del nostro puzzle: abbiamo bisogno di un componente software che attraverso la libreria libvirt vada a parlare per nostro conto con KVM; questo pezzo si chiama hypervisor e si trova tra il tool di management e KVM.
Ossia: noi parliamo col tool di management, il tool parla con l'hypervisor e l'hypervisor attraverso le libreria comunica con KVM; il nostro stack è così completo.
Nomi di hypervisor comunemente utilizzati sono: LXC, OpenVZ, QEMU, Xen, Virtualbox, VMWare. Quello che uso io, per i miei test nel portatile è QEMU.
Dopo tutta questa prosopopea, possiamo finalmente fare un elenco delle funzionalità di KVM:
  • Over-committing: il sistema può allocare più CPU virtualizzate di quelle realmente esistenti.
  • Thin provisioning: permette di allocare lo spazio in modo flessibile per ogni virtual machine.
  • Disk I/O throttling: permette di impostare un limite alle richieste di I/O del disco mandate dalle VM alla macchina ospitante.
  • Virtual CPU hot add capability: permette di aumentare la potenza del processore    “a caldo” cioè mentre la virtual machine è in funzione.
  • Automatic NUMA balancing: aumenta le prestazioni delle applicazioni che girano su sistemi di tipo NUMA.
Per chi se lo stesse chiedendo, non stiamo parlando di Mauro Numa, campione italiano di fioretto, né di Shozo Numa, famoso scrittore giapponese di fantascienza autore del libro Kachikujin yapū, da cui è stato tratto il manga “Yapoo – Il bestiame umano”, racconto con sfumature sadomaso del quale immagino l'umanità non potesse fare a meno. No! Parliamo della “Non-Uniform Access Memory”, architettura di memoria sviluppata per sistemi multiprocessore studiata appositamente per velocizzare l'apporto di dati ai processori da parte delle memorie.
Una curiosità: questa tecnologia venne sviluppata in Italia negli anni '80, quando ci si occupava ancora di informatica e in Italia si trovavano tra i computer più veloci del pianeta. So che fa caldo, ma non divaghiamo!
Per installare tutto questo popò di roba dovete innanzitutto verificare che il vostro processore abbia “competenze virtuali”, cioè le tecnologie di virtualizzazione di cui sopra:
per sistemi intel: grep --color 'vmx' /proc/cpuinfo, mentre per sistemi amd: grep –color 'svm' /proc/cpuinfo
Se non appare niente, potrebbe darsi che queste estensioni siano disabilitate nel bios o che il vostro processore non supporti la virtualizzazione. lsmod | grep kvm vi informa se il modulo kvm è stato caricato. Deve mostrare kvm, kvm_intel o kvm_amd.
I nomi dei pacchetti cambiano a seconda della distribuzione, su internet è abbastanza facile trovare l'elenco, in generale dovete installare quelli concernenti virt-manager, libvirt, qemu e avviare il daemon libvirtd se non è già attivo.
Per una spiegazione dettagliata su questi software è necessario un articolo specifico. Magari la prossima volta.

 

0

GNU/Linux Init System


Fino al 2006 il sistema di init delle distribuzioni di Linux aderiva essenzialmente a 2 standard, c'erano le distribuzioni che usavano System V e quelle che usavano il BSD-Style.
Entrambi si appoggiavano al programma "init" e un sistema di script scritti in shell. Non erano molto distanti l'uno dall'altro e chiunque conoscesse un po' di shell scripting era in grado di comprendere velocemente come era costruito il boot del sistema.
Nel 2006, Ubuntu e tutte le sue derivate iniziarono ad utilizzare un nuovo sistema: Upstart, che venne anche adottato successivamente da RedHat e Fedora.
Nel 2010 venne rilasciata la prima release di un altro sistema di init inizialmente progettato da dipendenti di Redhat: systemd. Durante il 2015 tutte le maggiori distribuzioni Linux passarono a systemd.
L'approccio rivoluzionario di systemd ha da subito creato dibattito e opinioni controverse, perché rompe alcune importanti tradizioni Unix, tra le quali il principio di semplicitá, cioé che un software deve fare una sola cosa e farla bene. Alcune distribuzioni, anche se contrarie, sono state obbligate ad adottarlo de-facto, per via di alcune dipendenze legate a GNOME.

Ma facciamo una carrellata dei sistemi di init esistenti:

Sysvinit
Il system V nasce nel 1983! Si, é piú vecchio di molti di voi che leggete!
Venne sviluppato da una cordata di aziende tra cui IBM, HP, Solaris e Illumos Distributions. Non ho fatto una ricerca approfondita, ma attualmente viene utilizzato da Devuan, PCLinuxOS e LFS. Diciamo che siamo alla fine del suo percorso.

Systemd
Come dicevo, oggi é il piú utilizzato. Lo usano Fedora, Redhat, Debian, Ubuntu, OpenSuse.

BSD-Style
Credo che lo usino solo CRUX e Slackware.

OpenRC
Usato essenzialmente da Gentoo e derivate, ovviamente la natura di queste distribuzioni permette anche di usare uno qualunque degli altri sistemi di init.

La polemica
Systemd non é un semplice init, fa molte cose che nella filosofia Unix sono compito di altri software.
Piú che ad un classico init system somiglia ad svchost.exe di Windows.
Gestisce il power management, i punti di mount, cron, criptazione del disco, socket API/inetd, syslog, la configurazione della rete, gestione del login, readahead, GPT partition discovery, registrazione dei container, hostname, locale, time management, e altre cose.

La motivazione di molti esperti che criticano questo software é semplicemente che se viene trovato un bug, anche minore, in uno qualunque dei moduli che systemd gestisce, é (in teoria) possibile buttare giú l'intero sistema di init del sistema operativo.
In aggiunta, un sacco di upgrade software che una volta non richiedevano il reboot, a causa di queste invasioni di campo oggi lo richiedono. E' monolitico e pesantemente orientato al desktop. Questo lo rende una scelta poco saggia per molti utilizzi di Linux.
A dispetto di tutte queste critiche systemd é stato adottato da tutte le distribuzioni piú importanti e GNOME lo richiede obbligatoriamente. Inutile dire che chi lavora in questo campo lo deve studiare e ci deve avere a che fare.

Riguardo a systemd Linus Torvalds ha dichiarato che non ha opinioni precise. Ha avuto qualche problema con gli sviluppatori riguardo ad alcune compatibilitá e bug, in quanto erano un po' altezzosi, e pensa che alcune scelte sono insensate (la sua esatta parola: insane), come ad esempio i log binari, ma questi sono dettagli, non grandi problemi.

Theodore T'so uno sviluppatore del kernel di Linux e ingegnere Google sostiene che la cosa peggiore é che stanno cercando di risolvere problemi reali di alcuni usi specifici, e che questo va a discapito di assunti piú generali fatti in altre parti del sistema.
Inoltre, il passaggio a questo sistema é stato fatto troppo velocemente e loro non considerano necessariamente una loro responsabilitá mettere a posto il resto dell'ecosistema Linux.
T'so mette, inoltre, in evidenza alcune atteggiamenti che ha notato anche in GNOME 3. Cioé che loro si interessano solamente di una piccola parte degli utenti desktop Linux e hanno abbandonato alcuni modi di interagire col desktop in favore dei touchscreen per attrarre un pubblico meno specializzato, cioé, se non ti trovi nel loro target diventi un utente di serie B.
Per contro, tutti ammettono che system v é ormai datato, ma nessuno sembra volersi assumere la responsabilitá di scrivere un nuovo init. Quindi, almeno ad oggi, sembrano non esserci alternative.
Quello che sembra trasparire tra le righe é che systemd sia un tentativo di uniformare con la forza l'ecosistema Linux e che questo vada ad alienare e marginalizzare una parte della comunitá open-source.
Debian per spiegare la scelta di systemd ha prodotto un documento dove descrive tutti i vantaggi che il sistema ottiene con il suo passaggio. Il documento é lungo, ma tra i vantaggi c'é una maggiore velocitá nel boot, una maggiore semplicitá nella gestione dei file di boot dei pacchetti, che prima dovevano essere scritti dai manutentori e oggi sono uguali per tutte le distribuzioni che adottano systemd.
Un migliore sistema di shutdown dei processi, un sistema strutturato dei log, un migliorato sistema dei virtual TTY. Un sistema centralizzato di startup e monitoring dei processi, piú funzionale nei sistemi di high availability. Un sistema unificato per la gestione di molte impostazioni di sistema come timedatectl, hostnamectl, loginctl etc. etc.
un sistema di API che permette alle applicazioni di interfacciarsi con systemd. Attualmente queste API vengono usate solo da GNOME, ma puó essere usato da qualunque linguaggio di programmazione e non si esclude che altri desktop inizino ad usarle. Puó essere lanciato indifferentemente in macchine virtuali e container, salta semplicemente le parti di configurazione incompatibili. Ha un supporto watchdog completo. Puó essere utilizzato all'interno di initramfs. E' facile effettuarne il debug e sta cercando di muovere nella direzione di un sistema configuration-less (/etc/ vuoto).

Personalmente credo che la polemica non sia ancora finita e non é detto che systemd conservi il vantaggio che ha oggi, anche se ormai si trova praticamente su tutte le distribuzioni. Se non nasce un progetto alternativo é molto probabile che le distribuzioni che sono ancora su system v, siano destinate a soccombere. La mia impressione é che piaccia al mondo commerciale ma non a quello tecnico. Io stesso non ho ancora escluso di passare a distribuzioni che non lo usano.

L'articolo finirebbe qui. Ma ho trovato in un documento la cronistoria, la metto in coda perché credo sia interessante.

La controversia
Il progetto di systemd ha provato un acceso dibattito nella comunitá del free software. I critici sostengono che systemd é eccessivamente complesso e soffre di un continuo scivolamento verso nuove funzionalitá, e la sua architettura viola i principi progettuali di un sistema unix-like. C'é anche la preoccupazione che stia formando un sistema di inter-dipendenze togliendo ai manutentori delle distribuzioni libertá di scelta, visto che l'adozione di alcuni software user-space obbliga la sua installazione.

Nel maggio 2011 Fedora é stata la prima importante distribuzione Linux ad abilitare systemd per default.

Nel 2012, in una intervista, Patrick Volkerding, leader di Slackware ha espresso riserver sull'architettura di systemd, affermando che ritiene che il suo progetto sia contrario alla filosofia Unix di utilitá interconnesse con precise e definite funzionalitá. Volkerding non ha escluso il suo supporto, ma ad oggi Slackware non supporta systemd.

Nel gennaio 2013, Lennart Poettering (systemd) ha creato un documento chiamato the The Biggest Myths dove tenta di calmare le preoccupazioni riguardo a systemd.

Tra l'ottobre 2013 e Febbraio 2014 un lungo dibattito lacera la comunitá Debian, la decisione culmina nella scelta di systemd per debian 8 Jessie. Il dibattito viene largamente pubblicizzato e continua anche dopo la decisione. Dopo questa decisione, nel febbraio, Mark Shuttleworth (Ubuntu) seguirá Debian in questa decisione, abbandonando Upstart, nonostante i suoi commenti dell'ottobre 2013 dove dichiarava che era difficile giustificare l'atteggiamento estremamente invasivo di systemd.

Nel marzo 2014, Eric Raymond dichiara che gli obiettivi di systemd provocheranno una crescita sproporzionata delle sue dimensioni e un continuo arrampicarsi verso le funzionalitá di altri software. Nell'aprile 2014 Linus Torvalds esprimerá delle riserve riguardo all'atteggiamento di Kay Sievers, uno sviluppatore chiave di systemd nei confronti di  utenti e bug report riguardo a modifiche spedite da lui al kernel Linux. Alla fine dell'Aprile 2014 viene lanciata una campagna di boicottaggio di systemd con un sito web che ne spiega le motivazioni.

Nell'agosto 2014, in un articolo pubblicato su InfoWorld, Paul Venezia parlando della controversia riguardo systemd attribuisce la controversia ad un problema di ego da parte dei programmatori di systemd che pensano di non poter sbagliare. L'articolo paragona systemd a svchost.exe un componente critico del sistema Windows.

Nel novembre 2014, alcuni membri di Debian e componenti del comitato tecnico: Joey Hess, Russ Allbery, Ian Jackson, e il manuntentore del pacchetto systemd Tollef Fog Heen lasciano le loro posizioni. Tutti e quattro giustificano la loro scelta parlando di un eccessivo stress legato alla disputa sull'integrazione di systemd in Debian, che ha reso la manutenzione dei pacchetti virtualmente impossibile.

Nel dicembre 2014, nasce un fork di Debian chiamato Devuan, da parte di un gruppo che si autonomina "Veteran Unix Admins". La loro intenzione é fornire una variante di Debian non basata su systemd.

Nell'agosto 2015, systemd rilascia una shell di login, chiamabile via machinectl shell.

Nell'ottobre 2015, viene pubblicato un articolo intitolato "Deficienze strutturali e semantiche nell'architettura systemd per la gestione dei servizi nel mondo reale". L'articolo critica systemd in molte aree, compreso il suo progetto come un sistema ad oggetti con troppi livelli opachi che lo rendono incline ad essere esposto a casi di fallimento, un modello di esecuzione difficile da predire, un'ordine di boot non deterministico, lo stato implicito delle configurazioni dei file unit e la sua generale inadeguatezza nel fornire un'astrazione esterna uniforme per i tipi di unitá.

Riferimenti:
https://wiki.debian.org/Debate/initsystem/systemd
http://blog.erratasec.com/2015/08/about-systemd-controversy.html#.WVYZNico9hE
http://www.zdnet.com/article/linus-torvalds-and-others-on-linuxs-systemd/
http://0pointer.de/blog/projects/the-biggest-myths.html
http://without-systemd.org/wiki/index.php/Main_Page
https://chiefio.wordpress.com/2016/05/18/systemd-it-keeps-getting-worse/

 

0

Debian 9 Stretch


Leggendo la news di Marco Giannini sull’arrivo della nuova versione stable di Debian, mi sono accorto che il mio portatile stava passando da testing a stable. Quale occasione più ghiotta per parlare di quella che probabilmente è la più vecchia distribuzione di Linux ancora in vita?

Debian è, forse, la distribuzione più “forkata” in assoluto, 131 fork secondo distrowatch, quasi la metà delle distribuzioni che ci sono in giro. È “mamma” di tante distribuzioni di successo tra le quali Ubuntu e  Knoppix, “nonna” ovviamente, di tutte le “figlie” di Ubuntu come Mint ed Elementary OS, ad esempio.

Debian nasce il 16 agosto 1993, il nome è una composizione dei nomi Debora e Ian. Debora era in quel periodo fidanzata, moglie e poi ex-moglie del compianto Ian Murdock fondatore della nostra amata distribuzione. Ha influenzato profondamente il pensiero del mondo del software libero, Ian scrisse il “Debian Manifesto”, ma in questo percorso, incontriamo anche persone del calibro di Bruce Perence, che insieme a Ean Schuessler (che pare abbia proposto l’idea) scrisse il “Debian Social Contract”, complemento del Manifesto. Questo contratto Contiene le “Debian free software guidelines” che, sorpresa… sorpresa… forniranno la base per la creazione della “Open Source Definition”.
Non voglio appesantire l’articolo con i contenuti di questi documenti che potete facilmente trovare su internet, ma possiamo dire che Debian è stata ed è protagonista nel dibattito pubblico, filosofico e tecnico sul software libero.

La precisione con la quale Debian fornisce documenti sulla filosofia e le modalità di costruzione del sistema operativo fanno invidia ad Amazon, accanto ai documenti già citati, abbiamo anche la “Debian Constitution” e il “Debian Code of Conduct”. Nel ‘97 Bruce Perens fondò l’associazione “Software in The Public Interest” per ricevere donazioni e finanziare il progetto. Oggi quest’associazione oltre a finanziare Debian sostiene tra gli altri, Arch Linux, Drupal, ffmpeg, Fluxbox, freedesktop.org, GNUStep, Jenkins, Libreoffice, OpenWRT, PostgreSQL.

Ma veniamo al lato tecnico, Debian è una distribuzione a scopi generali, ha un solo kernel di default, che viene utilizzato su Desktop e Server, successivamente è possibile installare altri kernel che sono disponibili nel repository, o anche, ricompilarlo, se lo si ritiene opportuno. Una nota di colore: è possibile usare anche kernel FreeBSD ed esiste anche una versione sperimentale di Hurd.
Per quanto riguarda la manutenzione, le gui sono ridotte all’osso ed il grosso si fa da linea di comando, è chiaramente una distribuzione fatta per chi ha un minimo di esperienza o vuole imparare come si gestisce un sistema *nix.
Debian non offre assistenza commerciale, mette a disposizione la documentazione sul proprio sito, esiste anche un ottimo libro open che si chiama “Debian Administrator Handbook”. Ci sono anche un wiki, una mailing list, e un sito di tipo ask.

Debian ha una gestione delle versioni che ci permette di avere, a seconda delle nostre scelte, un S.O. estremamente stabile, moderatamente stabile, piacevolmente instabile.

La versione ufficiale è quella che viene definita “stable”. È più stabile, ma i pacchetti possono essere datati, riceve solo aggiornamenti di sicurezza. Normalmente viene rilasciata ogni due anni, ma la regola è che viene rilasciata solo se è pronta. È la versione consigliata per server e workstation. La “OldStable” viene supportata ancora per un anno dopo il rilascio della nuova stable e dopo viene archiviata.

Testing: è la futura stable, riceve aggiornamenti, quasi come una rolling-release, quando sta per uscire la versione stable va in “freeze” e si trasforma in stable.

Unstable: è la versione di sviluppo, i pacchetti sono aggiornati alla loro ultima versione e possono essere stabili o instabili, a seconda di come la loro casa madre prenda sul serio il rilascio del proprio software. Esistono distribuzioni rolling basate su questo ramo, come ad esempio Sidux.

Dal 2014, sull’onda delle scelte di Ubuntu, è nato il team Debian LTS che prende in mano il supporto della distribuzione dopo 3 anni e lo estende a 5 anni. Attualmente questo team ha il supporto di Wheezy che è esteso fino al 2018, fra un anno prenderà in mano Jessie che verrà supportata fino al 2020.

Per chi se lo fosse chiesto, i nomi delle versioni di Debian vengono dai personaggi del cartone animato Toy Story, che è il primo cartone animato sviluppato completamente in computer grafica. Toy Story, uscì nel ‘95. L’unico nome di versione che non cambia mai, è quello della versione unstable, Sid: il bimbo che nel cartone cerca di distruggere continuamente i giocattoli.

Il supporto hardware di Debian non è buono quanto quello di Ubuntu, perché per ragioni etiche mancano tutti di driver proprietari. Abilitando i repository contrib e non-free è possibile accedere a parte di questi, nel kernel ci sono comunque alcuni blob proprietari, che se tolti probabilmente bloccherebbero il funzionamento del S.O. in tutte le macchine moderne. Questo è un problema che prima o poi il mondo del software libero dovrà porsi.

Il Desktop di default di Debian è GNOME, ma è possibile installare praticamente tutti i desktop e window manager esistenti. Debian lascia l’estetica e la grafica così come è stata pensata dal produttore. Nel caso si desideri qualcosa di più carino si devono modificare manualmente le impostazioni e installare le icone e i font necessari. Naturalmente è possibile installare Debian anche senza nessuna grafica ottenendo un terminale a linea di comando.

Il sistema di gestione dei pacchetti di Debian è dpkg. Insieme a rpm dpkg è uno standard de-facto, l’estensione di questi pacchetti è .deb, esistono vari software che permettono di installarlo, i più famosi sono apt-get, apt, aptitude. Debian, con circa 50.000 pacchetti, ha il repository più vasto del pianeta. Supporta anche tantissime architetture, molte di queste non più commercialmente valide. La natura della sua comunità non legata a doppio filo con il mondo dell’economia le permette di supportare, dove qualcuno ne ravvisi la necessità, anche contesti che ormai sono rari, le architetture supportate sono Arm, Intel i386 e amd64, mips, PowerPC, s390x.

Debian è una delle distribuzioni più “etiche” tra quelle che ci sono in giro, ricordo che all’inizio veniva, da molti, definita estrema. In realtà il suo approccio di fronte al software proprietario è molto pragmatico. Per esempio, fornisce un repository apposito per il software non-free, sarebbe come se Apple o Microsoft fornissero la possibilità di installare software libero automaticamente, direttamente dal programma di installazione. Distribuzioni come, ad esempio, Fedora, non lo fanno. Questa scelta potrebbe essere letta come ipocrita, ma dal punto di vista tecnico, in particolare della sicurezza è importante, perché l’utente che installa software dal repository non-free non si deve porre domande sulla sicurezza del software che sta installando, mentre l’utente Fedora, se incauto, potrebbe compromettere la sicurezza del proprio sistema affidandosi a repository amatoriali.

 

0

Linux Distros


Ho riflettuto un po’ sulla tematica da affrontare in questo mio primo articolo. La prima domanda che mi sono posto è se fosse meglio scrivere di qualche argomento specifico oppure in generale del mondo del software libero.
Al giorno d’oggi è talmente facile trovare how-to o articoli tecnici di alta qualità, che se cercate come installare qualcosa o conoscere se il tal hardware è supportato non dovreste avere il minimo problema. Ciò che invece mi sembra più difficile è comprendere la comunità culturale sottostante il mondo tecnico; ho quindi deciso di parlare di questa tematica.

La Linux Foundation, il progetto GNU, la Mozilla Software Foundation e tutti gli altri, sono produttori di software, ma sono prima di tutto espressione di una comunità culturale, che esprime un certo modo di concepire il software e quindi di produrlo. Infatti, il più grande contributo al mondo del software, da parte della comunità del software libero è probabilmente il capovolgimento del concetto di copyright in copyleft e tutte le conseguenti licenze che ne derivano, a partire dalla GPL.

La mia prima installazione di Linux risale al 1995, me lo ricordo chiaramente, perché aspettavo l’uscita di Windows che però veniva rimandata di mese in mese. Da allora la mia passione è cresciuta e il mio interesse verso Windows è diventato sempre più basso, fino ad essere quasi nullo. Nel frattempo ho studiato molte distribuzioni di Linux, per cui, ragionare in questi termini, per me, è diventato naturale. Al punto che trovo strano il fastidio che provano i neofiti nel vedere così tante distribuzioni in giro.

Troppa libertà di scelta e assenza di informazioni, una certa soggezione nei confronti di ciò che non si conosce e che si deve imparare o re-imparare, generano una certa distanza, una determinata voglia di tornare nella sicura cella di un sistema Windows o Apple, che saranno anche proprietari, ma almeno sono sempre uguali a sé stessi.

Veniamo al dunque: perché ci sono tante distribuzioni?

La risposta è semplice ed allo stesso tempo complessa:

Una nuova distribuzione nasce quando qualcuno ha bisogno di modifiche in quella che sta usando e che col tempo, diventano talmente tante, da giustificarne la creazione di una nuova.

Il Distrowatch page hit ranking indica 291 distribuzioni Unix, che per la maggior parte sono GNU/Linux. Non le ho contate, ma è molto probabile, quando si clicca su una distribuzione, leggere che questa è basata su un’altra precedente.

Ciò non è un caso, infatti, il modo più semplice, e probabilmente anche il più sensato, di creare una nuova distribuzione è effettuare un fork della distribuzione più vicina ai nostri obiettivi. Per questo motivo, sono nate delle “famiglie” che hanno dei capostipiti e delle distribuzioni “figlie” che vengono definite “derivate”.

I capostipiti sono le distribuzioni che sono sopravvissute agli anni ‘90 e che hanno definito lo standard de-facto. Senza presunzione di completezza, credo che si possano indicare come capostipiti: Redhat, Slackware, Debian, Suse. Quest’ultima è una derivata di Slackware, ma dall’inizio ha assunto differenze così sostanziali da meritare uno spazio tutto suo. Successivamente c’è stata una seconda ondata, quella che ha visto nascere ArchLinux, Gentoo, Nix.

Quindi, se vogliamo andare alla sostanza, esistono meno di dieci sistemi operativi che possono essere considerati veramente diversi tra loro. Le derivate tendono a mettere l’accento su qualche caratteristica specifica della distribuzione, ma chi conosce i genitori riuscirà quasi immediatamente a relazionarsi con i figli.

Ovviamente, per fare questo ragionamento ho dovuto escludere tutte le distribuzioni orientate a compiti specifici, come ad esempio quelle per i sistemi mobile o per i router.

Veniamo però alle differenze, perché dovrei scegliere una distribuzione al posto di un’altra?

La risposta veloce è: scegli quella del tuo vicino di casa, che magari potrebbe consigliarti nel caso di problemi.

La risposta lenta è: dipende. Cioè dipende dall'utilizzo che ne vuoi fare. La presenza stessa di tante distribuzioni attive indica tante esigenze diverse.

Se abbiamo scartato l’idea di far decidere al nostro vicino di casa, dobbiamo chiederci quali criteri vogliamo usare per scegliere la nostra distribuzione. Abbiamo già escluso le distribuzioni con compiti specifici, un elenco di criteri per distribuzioni general purpose potrebbe essere:
  •     Server/Desktop
  •     Comunità (documentazione)
  •     Supporto hardware e questioni etiche
  •     Eleganza/Ambiente Desktop
  •     Stabilità
  •     Semplicità d’uso

Server vs Desktop
Immagino che qui la scelta sia semplice: se la state pensando per il vostro notebook, non scegliete Server! L’unica distribuzione che può stare comodamente in entrambi è probabilmente Debian, le altre hanno tutte una versione Server e una versione Desktop. Le regine incontrastate dei Server sono Red Hat e CentOS, probabilmente al secondo posto ci sono Debian e Ubuntu Server. Numericamente parlando, Debian dovrebbe essere la più presente, ma in ambito Enterprise, incontrerete al 90% CentOS e RedHat. Quindi… Long life and prosper… scusate la battuta geek, ma non ho resistito.

Comunità
Ci sono distribuzioni dove la comunità è molto presente e la documentazione per imparare è veramente ben fatta, alcune di queste sono sostenute da aziende di tipo commerciale, altre sono completamente libere e la distribuzione non è influenzata da decisioni commerciali. Ubuntu è sostenuta essenzialmente da Canonical, ma ha anche una nutrita comunità libera intorno, lo stesso si può dire del rapporto tra Fedora e Redhat, mentre altre come Debian, Gentoo, ArchLinux sono guidate dalle loro rispettive comunità, CentOS fa eccezione perché anche se non ha rapporti con RedHat, delega completamente a lei la scelta del software della distribuzione.

Per capire la differenza, si pensi ad esempio a come Ubuntu ha abbandonato Unity, con un comunicato stampa, e invece Debian, che per passare da sysv a systemd ha avuto un dibattito interno lacerante.

Supporto hardware e questioni etiche
Il supporto hardware, anche se non sembra, è strettamente correlato con le licenze d’uso, perché al giorno d’oggi molte aziende continuano a non rilasciare le proprie sorgenti, in particolare questo problema è legato alle schede video e alle antenne wi-fi e per far funzionare questi hardware si deve accettare di far funzionare codice proprietario nel proprio computer, se ad oggi si tentasse di avere un sistema operativo 100% libero, probabilmente si sarebbe costretti a comperare hardware apposito e a verificare la compatibilità di ogni singola parte interna. In genere più l’approccio della distribuzione verso le questioni etiche è morbido, più si ha un supporto hardware vasto. Lo stesso sta accadendo per i DRM.

Eleganza/Ambiente Desktop
Oggi le maggiori distribuzioni permettono l’installazione di Desktop diversi da quelli di default, ma cambia il livello con il quale l’estetica è curata, se si pensa al crollo di Ubuntu in favore di Mint, con il semplice passaggio da GNOME a Unity, si capisce come il Desktop sia importante.

Stabilità
Nella mia esperienza le distribuzioni maggiormente stabili sono quelle che hanno il ciclo di release classico, cioè con una numerazione che definisce e blocca il numero di versione dei vari software e offre solo gli aggiornamenti di sicurezza. Questo metodo ovviamente rende le distribuzioni meno accattivanti e meno soggette alle novità, probabilmente chi ha un desktop preferisce vedere le novità appena arrivano, per questo motivo sono nate anche le rolling-release, che cercano di essere allineate con l’ultima versione distribuita del software installato, questo a discapito di una minore stabilità del sistema.

Semplicità d’uso
Molti pensano che le distribuzioni semplici da usare siano per i neofiti. Questo modo di ragionare è sbagliato, una delle regole degli Hacker (hacker nell’accezione classica) è di non dover reinventare continuamente la ruota, cioè di non dover riaffrontare continuamente lo stesso problema a meno che non si stia imparando. Ne consegue che molta utenza esperta preferisce concentrarsi sul suo lavoro, piuttosto che sulla customizzazione del sistema e che potrebbe preferire un sistema che vuole poca manutenzione in modo da massimizzare le ore di lavoro. Questo è probabilmente uno dei motivi che giustifica il successo di Ubuntu rispetto ad altre distribuzioni.
Ma anche per i neofiti, partire con una distribuzione che ti costringe a capire già durante la prima installazione come partizionare un hard disk, non è propriamente quello che si definirebbe un inizio con una bassa curva di apprendimento.

Quindi per concludere, direi che qualunque sia la distribuzione che si vuole scegliere, si devono tenere presenti le proprie esigenze, ma se si vuole diventare esperti in materia si devono anche conoscere tutte le distribuzioni “capostipite” o perlomeno le famiglie Redhat e Debian, che sono quelle più comuni.