Archivi categoria: OpenSuse

Arrivano OpenSUSE Leap 15 e Uyuni

Facebooktwittergoogle_plusredditlinkedin

La settimana scorsa si è tenuta a Praga l’annuale OpenSUSE Conference in cui è stata annunciata la nuova release derivata da SUSE Linux Enterprise 15: OpenSUSE Leap 15.

Leap 15 è una non-rolling release indirizzata al mondo enterprise in grado di supportare l’hardware più recente e con alle spalle una community molto vasta.

Le novità di questa release:

  • Possibilità di migrare a SUSE Linux Enterprise;
  • Nuovo sistema di partizionamento;
  • Utilizzo di Firewalld;
  • Possibilità di scegliere tra il ruolo server o transactional server;
  • Ottimizzazione per l’utilizzo in cloud;
  • Utilizzo di Wayland di default.

Gli aggiornamenti periodici di manutenzione e sicurezza per Leap 15 saranno di tre anni, più il rilascio dei Service Pack da installare però manualmente.

In aggiunta, la community di OpenSUSE ha annunciato Uyuni, il forking di Spacewalk, un software di system management.

Spacewalk è un progetto di Red Hat disponibile su GitHub e consente di avere un inventario di tutti i sistemi, installare/aggiornare i pacchetti, controllare i servizi, deployare configurazioni e qualsiasi cosa riguardante la gestione e l’amministrazione del sistema. Il dubbio che attanaglia gli utilizzatori -e gli sviluppatori di openSUSE- è che Spacewalk è la base che Red Hat ha sempre utilizzato per Satellite 5 riversando sulla controparte community le modifiche; dall’annuncio però di Red Hat Satellite 6, riscrittura completa del sistema, non solo l’effort dell’azienda del cappello rosso su Spacewalk è drasticamente diminuito, ma anche le richieste di merging per aggiunta di funzionalità vengono spesso bloccate o, peggio ancora, completamente ignorate.

Fino alla fine di Aprile le stesse FAQ di Spacewalk citavano quanto segue:

Spacewalk is a community project; its code is open source and GPLv2-licensed, and its contributors come from all over the world and from many different companies. As Red Hat’s participation ramps down, there will be an opportunity for the participation from other community members to ramp up. Someone (or several someones!) will need to take over some of the management role that currently rests on Red Hat. What exactly that will look like is still an open question, and one that the Spacewalk community will need to be talking about over the next several years.

Spacewalk è un progetto della comunità; il suo codice è open source e licenziato con GPLv2, ed i suoi contribuenti arrivano da tutte le parti del mondo e tante diverse aziende. Con lo scemare della partecipazione di Red Hat, ci sarà l’opportunità di un incremento della partecipazioni di altri membri della comunità. Qualcuno (o diverse persone!) dovranno rimpiazzare parte dei ruoli di gestione che al momento ha Red Hat. Come questo avverrà è ancora una domanda aperta, ed una di quelle su cui la comunità Spacewalk dovrà discutere nei prossimi anni.

Ed è qui che entra in gioco Uyuni di openSUSE; questo prodotto sarà leggermente diverso ed utilizzerà il il framework di React per l’interfaccia web (andando a sostituire l’attuale componente Java), offrirà l’integrazione con Kubernetes ed il supporto ai container, ed utilizzerà Salt per la gestione delle configurazioni. In poche parole, la base è quella ma si andrà ad allontanarsi parecchio da quello che è l’attuale Spacewalk che conosciamo.

Vi lasciamo al video di presentazione del progetto, buona visione.

OpenSuSe inaugura i Transactional Updates

Facebooktwittergoogle_plusredditlinkedin

Per il 25 maggio  è atteso il rilascio della prossima versione stabile di openSUSE, ovvero Leap 15, ma è notizia di ieri la conferma dell’uso dei Transational Updates, già in test nella versione di sviluppo Tumbleweed (come scrivevamo qualche tempo fa). Il nuovo meccanismo sarà disponibile di default, e selezionando il nuovo ruolo “Transational Server” sarà anche attivo di default – con ogni notte aggiornamento e, se necessario, riavvio automatico.

L’obbiettivo del nuovo sistema è quello di rendere gli update dei pacchetti atomici: ogni volta che verrà richiesto un aggiornamento, tutti i pacchetti interessati saranno attivati in blocco e non singolarmente; altro obbiettivo è dare un metodo di rollback rapido ed affidabile, ovvero poter tornare esattamente allo stato pre-update (e certamente funzionante ) in caso di problemi.
openSUSE ha scelto di utilizzare delle tecnologie esterne al formato di pacchetti stesso (al contrario di Ubuntu con SNAP), basandosi sulle funzionalità di btrfs di fare ed usare snapshot del filesystem. Ricordiamo che Red Hat, di cui openSUSE rimane una derivata, non potrà adottare la stessa strategia in quanto ha annunciato l’abbandono del supporto a btrfs, e gli altri filesystem non hanno una funzionalità simili con un supporto altrettanto maturo.

Tale capacità di btrfs viene sfruttata da snapper, sviluppata da SUSE stessa proprio per comparare e gestire le snapshot (inizialmente solo per LVM, ora anche con btrfs). A sua volta snapper viene invocato da Zypper, ovvero il gestore di pacchetti di openSUSE. Questa architettura permette di avere la nuova capacità di update transazionale senza modificare i pacchetti per supportarla apposta, e quindi essere compatibile con tutti i pacchetti: futuri, passati o di terze parti.

Le considerazioni già espresse sui limiti della tecnologia rimangono valide, e in particolare il fatto che la capacità di rollback viene annullata al primo avvio “valido” della versione aggiornata; in più, la snapshot di recovery del sistema è quella prima dell’update: in caso di rollback, qualunque modifica fatta tra l’inizio degli aggiornamenti e il reboot della macchina verrà persa.

openSUSE in Windows Subsystem for Linux in Windows 10

Facebooktwittergoogle_plusredditlinkedin

Con il rilascio dell’Anniversary update è stata aggiunta a Windows 10 una funzionalità molto particolare, chiamata Windows Subsystem for Linux (WSL), che consente di eseguire dei binari di tipo ELF64 (eseguibili compilati in modalità nativa Linux), direttamente su Windows, senza l’ausilio di macchine virtuali o emulatori di terze parti.

In questo articolo (https://www.ictpower.it/sistemi-operativi/windows-subsystem-for-linux-finalmente-in-una-release-ufficiale.htm) abbiamo visto come abilitare questa funzionalità, e come durante l’installazione il sistema scarichi dal Windows Store il pacchetto Ubuntu for Linux, distribuzione prodotta da Microsoft e Canonical appositamente per l’integrazione su Windows.

L’aggiunta di questa funzionalità, passata forse in sordina nei primi tempi, sta ora suscitando qualche gelosia da parte di chi produce distribuzioni Linux a livello commerciale, che vede la possibilità di far conoscere la propria distribuzione ad un pubblico più ampio, sfruttando la popolarità di Windows 10 a livello client. E’ il caso di Hannes Kühnemund, senior Product Manager di SUSE, che in una recente dichiarazione ha affermato che Microsoft per il suo WSL stesse utilizzando la distribuzione errata di Linux, sostenendo che SUSE esiste da molto più tempo rispetto ad Ubuntu, e per questo sicuramente avrebbe meritato maggiore attenzione.

La dichiarazione è stata opportunamente accompagnata dal rilascio, in versione non ufficiale, del pacchetto openSUSE Leap 24.2 integrabile in WSL. OpenSUSE Leap è la versione Open della distribuzione commerciale SUSE Enterprise, ed è quindi possibile scaricarla ed installarla liberamente su qualsiasi client Windows, a patto che sia stata precedentemente attivata la funzionalità WSL, e che durante il relativo wizard di installazione sia stato creato un utente con password.

Non ci rimane che mettere alla prova questa nuova distribuzione, iniziando in primis a capire se questo pacchetto rispetta le promesse circa la possibilità di utilizzarlo senza problemi con Windows 10. Ci aspettiamo, quindi, di poter avviare openSUSE bash, ed utilizzare il gestore dei pacchetti Zypper così come utilizziamo apt-get su Ubuntu.

Per comprendere tutti i passaggi dell’installazione è importante analizzare il filesystem di Windows, individuando la cartella in cui lavora WSL, ossia la cartella dove sono presenti tutti i file relativi al sottosistema linux. Il sistema è composto da due parti fondamentali: la prima comprende tutti i binari e i file di configurazione della distribuzione, la seconda comprende tutto il resto, tra cui ad esempio i dati utente o il path in cui sono montati i dischi Windows. Il tutto si trova nella cartella (nascosta) %localappdata%\lxss. Nel mio caso, ad esempio, il sottosistema Linux si trova nella cartella:

C:\Users\ICTPower\AppData\Local\lxss

Qui troviamo la cartella rootfs, all’interno della quale c’è il sistema operativo Linux vero e proprio insieme ad altre cartelle, tra cui quelle relative agli utenti (home) e quella in cui vengono montati i volumi di Windows (mnt). Notiamo la presenza del file bash.ico, che andremo a modificare in seguito. Lo screenshot seguente mostra come si presenta la cartella %localappdata%\lxss vista dal sistema operativo Windows.

Vediamo, inoltre, che all’interno della cartella rootfs è presente il sistema operativo base:

La cartella %localappdata%\lxss\rootfs\home è vuota, poiché il profilo dell’utente Linux, nel mio caso chiamato gnanoia, si trova nella cartella home al livello superiore, cioè %localappdata%\lxss\home

Ho preferito essere un po’ puntiglioso per questo semplice chiarimento perché è di fondamentale importanza per eseguire correttamente i passaggi seguenti dell’installazione.

L’idea è infatti quella di sostituire la cartella base del sistema operativo (la cartella rootfs con Ubuntu per intenderci), con la corrispondente openSUSE, presente nel pacchetto rilasciato pochi giorni fa.

Iniziamo quindi scaricando il pacchetto openSUSE-42.2.tar.xz, che è l’immagine di un “container” basato su openSUSE. Non approfondiremo in questa sede il concetto di container, rimandando i più curiosi al video presente su questa pagina (https://www.nicolaferrini.it/ita/blog/871-techeroes-come-funzionano-i-container-con-docker.html), ma teniamo solo presente che stiamo effettuando il download di una distribuzione Linux “pronta all’uso”, come se avessimo “catturato” l’immagine base di una macchina openSUSE già installata.

Per iniziare, quindi, apriamo Windows Bash (bash on Ubuntu on Windows) ed eseguiamo:

wget -O openSUSE-42.2.tar.xz https://github.com/openSUSE/docker-containers-build/blob/openSUSE-42.2/docker/openSUSE-42.2.tar.xz?raw=true

Notiamo che all’avvio di Windows bash la cartella di lavoro corrente corrisponde alla home dell’utente Linux, e quindi il download sarà eseguito nella cartella \home\<nomeutente>, e quindi il percorso completo del file scaricato nel mio caso sarà: \home\gnanoia\openSUSE-42.2.tar.xz

Ora creiamo con permessi di root (quindi utilizzando il comando sudo) una cartella chiamata rootfs all’interno della nostra home, estraiamo l’immagine scaricata all’interno di questa cartella, e chiudiamo la shell.

sudo mkdir rootfs

sudo tar -C rootfs -Jxf openSUSE-42.2.tar.xz

exit

A seconda della release di WSL in uso potrebbero essere visualizzati degli errori relativi alla syscall MKNOD, che potrebbe risultare non supportata. Possiamo tranquillamente ignorare gli errori poiché la nostra necessità è semplicemente quella di scompattare l’archivio.

A questo punto dobbiamo sostituire la cartella rootfs originale (quella con Ubuntu) con quella appena creata; poiché questa operazione viene eseguita su cartelle in uso da WSL è necessario stoppare il relativo servizio per proseguire. Eseguiamo quindi da un prompt di DOS con privilegi elevati:

net stop lxssmanager

Possiamo quindi rinominare la cartella %localappdata%\lxss\rootfs in %localappdata%\lxss\rootfs.ubuntu, e copiare al suo posto la cartella con il pacchetto openSUSE appena estratto (la troviamo su %localappdata%\lxss\home\rootfs).

Questa operazione può ovviamente essere eseguita con Windows Explorer o con i seguenti comandi da un prompt di DOS:

cd %localappdata%\lxss\

rename rootfs rootfs.ubuntu

move .\home\<nomeutente>\rootfs .\

Lo screenshot seguente mostra le operazioni eseguite per la sostituzione della cartella rootfs

Possiamo quindi avviare nuovamente il servizio lxssmanager:

net start lxssmanager

L’ultimo passo è quello di settare l’utente predefinito della nuova distribuzione. Non essendo presenti utenti oltre a root sull’immagine openSUSE possiamo eseguire da DOS:

lxrun /setdefaultuser root

Per finire il lavoro con eleganza possiamo sostituire l’icona %localappdata%\lxss\bash.ico (preferibilmente rinominandola ubuntu.ico) con quella di openSUSE scaricabile da:

http://www.iconarchive.com/download/i46667/saki/nuoveXT/Apps-suse.ico

e rinominare con “bash in openSUSE on Windows” il collegamento presente in

C:\Users\<nomeutente>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs

O crearne uno nuovo sul Desktop

Per lo screenshot finale accompagnato dagli applausi del pubblico scegliamo di eseguire il comando

cat /etc/os-release

che ci mostrerà distribuzione e release attualmente in uso

Come promesso vediamo come si comporta il manager di pacchetti, provando ad installare apache utilizzando zypper; se tutto è a posto dovrebbe bastare un semplice comando:

zypper in apache2

Creiamo ora un semplice file index:

echo "Hello World" > /srv/www/htdocs/index.html

Avviamo apache:

httpd

E navighiamo su http://127.0.0.1

Direi che è proprio quello che ci aspettavamo, solo ora mi sento di affermare che è possibile utilizzare anche un userspace openSUSE, e quindi SUSE Linux Enterprise Server su Windows Subsystem for Linux.

Preferire Ubuntu o SUSE a questo punto è una scelta puramente personale, se non fosse così d’altro canto non si chiamerebbero sistemi open 😀

Se invece siete arrivati fin qui per sapere cosa preferisco io… beh… sono in attesa del rilascio di CentOS 😀