Menu Chiudi

Categoria: Informatica

Mantaining qmail in 2019

letture

Plasma5 Wayland e Slackware

letture

plasma 5waylandPochi giorni fa sul blog di Eric Hameleers è apparso un post interessante e incoraggiante per noi fan di Slackware.

Eric è riuscito a far funzionare una sessione di Plasma5 con Wayland su Slackware.

Per chi non lo sapesse, Wayland è il server grafico “del futuro” che dovrebbe prendere il posto di X.Org, o quantomeno relegare X.Org e X11 a un ruolo di secondo piano come compatibilità legacy. La distribuzione Fedora 25 lo ha già adottato come server grafico di default.

Come per tutte le architetture software recenti su Linux, il principale ostacolo all’utilizzo di Wayland su Slackware è il fatto che esso dipende da systemd, e in particolare dalla componente che gestisce i login al sistema, ovvero systemd-logind.

Qualche tempo fa Eric aveva iniziato degli esperimenti sul funzionamento di Wayland su Slackware ricorrendo al software “elogind” che, al pari di eudev già utilizzato da Slackware per quanto riguarda la parte udev, estrapola da systemd il codice di logind rendendolo utilizzabile in un contesto di init tradizionale.

L’esperimento però aveva ottenuto risultati parziali e si era arenato. Nel frattempo però si è aperta una nuova alternativa, costituita dal fatto che l’autore di ConsoleKit2 ha integrato l’implementazione dell’API logind direttamente all’interno di questo software, rendendo non necessario il ricorso a elogind.

Questo ha semplificato la situazione ed ha reso possibile ad Eric di eseguire nuovi test con Plasma5 ottenendo finalmente il risultato sperato: una sessione desktop di Plasma5 che gira su Wayland e non più su X.Org.

Ovviamente occorre ancora del tempo affinchè questa configurazione possa diventare stabile al punto da poter essere usata come default su un desktop “di produzione”, ma rappresenta una pietra miliare fondamentale per assicurare il fatto che Slackware molto probabilmente potrà continuare a offrire un desktop moderno al passo con i cambiamenti tecnologici del mondo Linux senza dover necessariamente adottare l’abominio systemd.

Nel post originario Eric fornisce le indicazioni e i pacchetti binari già pronti per poter sperimentare questa soluzione sulla propria Slackware-current.

nuovi certificati SSL by Let’s Encrypt

letture

httpsTra ieri ed oggi ho cambiato il certificato SSL utilizzato sui siti web di lonestar.it e unixportal.net, e per i servizi di posta SMTP/IMAP di mail.lonestar.it.

Fino ad oggi avevo utilizzato un certificato di tipo wildcard, regolarmente acquistato su StartSSL. Si trattava di un servizio tutto sommato economico per procurarsi un certificato wildcard valido 2 anni. La comodità consiste nel fatto che il certificato era valido per *.lonestar.it, e quindi in qualunque servizio del network.

Ma la Certification Authority di StartSSL è stata deprecata dai maggiori browser a causa di alcune violazioni commesse dopo l’acquisizione da parte di una azienda cinese.

Come conseguenza, a partire dalle versioni recenti di Firefox e Chrome, i certificati emessi da questa authority non vengono più accettati come validi (colore verde accanto alla barra dell’url), ma vengono invece indicati come non riconosciuti (colore rosso accanto alla barra dell’url).

Allora ho deciso di iniziare a utilizzare il servizio gratuito di Let’s Encrypt, che molto successo ha guadagnato in tempi recenti per via della nuova filosofia di rilascio gratuito di certificati a chiunque, per tempi brevi (90 giorni al massimo), in modo da incoraggiare l’adozione dei protocolli https e tls da parte di tutti.

La breve durata dei certificati impone il passaggio a un meccanismo automatico di rinnovo e sostituzione, rispetto alla consuetudine precedente di ottenere un certificato valido per alcuni anni e quindi procedere a installarlo manualmente nei vari server coinvolti.

Let’s Encrypt offre un client ufficiale basato su python per eseguire queste operazioni automatiche sulle distribuzioni più diffuse e per i servizi più comuni. Ma siccome io utilizzo Slackware come distribuzione e s/qmail come servizio di posta, ho preferito utilizzare lo script Dehydrated, che si basa su bash e curl.

Quindi ho messo a punto alcuni script che richiedono i certificati, non più wildcard ma nominativi per ciascun servizio, e li installano dove necessario.

Sembra funzionare tutto 🙂

Slackware 14.2 è tra noi!

letture

slackwareCon gaudio e somma gioia annunciamo il rilascio di Slackware Linux 14.2 nella data del 2 luglio 2016!

Sono trascorsi circa 2 anni e mezzo dalla precedente release, e circa 5 mesi dall’inizio delle Release Candidate, quindi ormai i tempi erano ampiamente maturi.

Patrick Volkerding, come di consueto, ha dato il lieto annuncio, sia tramite un post sul sito ufficiale che attraverso i suoi profili di social network.

L’attesa di questa versione è stata circondata da una particolare atmosfera, più intensa di quella solita, per via sia dei lunghi tempi che sono trascorsi che dei particolari cambiamenti che sono stati forzati nella tradizione dell’architettura delle distribuzioni Linux in questi ultimi 2 anni.

Era ormai noto da tempo agli appassionati che Slackware ha trovato il modo di resistere all’introduzione di systemd attraverso l’impiego di [wiki base=”Gentoo EN”]eudev[/wiki] e ConsoleKit2 – e una certa collaborazione da parte del team di KDE, seppur spesso controvoglia -, ma non c’era ancora una release ufficiale basata su queste soluzioni su cui il “grande pubblico” potesse mettere le mani. Noi utilizzatori della versione -current avevamo già tutto in mano da parecchi mesi.

Veniamo ai dettagli tecnici della release.

  • Il kernel in dotazione è la release 4.4.14. La versione 4.4.x è una Long Term Support release, il che garantisce patch e bugfix per almeno i prossimi 2 anni. Inoltre è presente il kernel 4.6 per chi desidera testare qualcosa di più avanzato.
  • La release di Glibc è la 2.23, ovvero l’ultima disponibile come stabile alla data odierna.
  • Il server grafico X11 è alla versione 1.18.3 (X11R7.7)
  • I compilatori inclusi sono il classico GCC alla versione 5.3, e LLVM/Clang 3.8.0
  • La gestione del networking può avvenire tramite NetworkManager, ma è anche possibile continuare ad utilizzare i tradizionali script rc oppure wicd
  • La gestione delle periferiche avviene, come precedentemente detto, tramite eudev 3.1.5, che estrae il proprio codice da systemd dopo che l’originario udev è stato inglobato in esso dal consorzio FreeDesktop.org.
  • Gli strumenti di sviluppo e linguaggi di programmazione inclusi comprendono Perl 5.22.2, Python 2.7.11, Ruby 2.2.5, Subversion 1.9.4, git-2.9.0, mercurial-3.8.2 e altri.
  • KDE è aggiornato alla versione 4.14.21 (ovvero 4.14.3 con kdelibs-4.14.21), mentre XFCE è alla versione 4.12.1. E’ possibile installare KDE/Plasma 5 dal repository di Eric Hameleers e MATE 1.14 dal repository di Willy Sudiarto.

Un paragrafo a parte merita la novità costituita dall’introduzione di Pulseaudio come framework di accesso alle schede audio. La cosa ha lasciato stupita ed in gran parte infastidita la gran parte degli utenti più affezionati, in quanto costituisce una piccola capitolazione. La Slackware si è tenuta lontana per molti anni da questo software che, a fronte dell’introduzione di feature avanzate nella gestione dell’audio in rete, ha introdotto anche latenze e impurità nella riproduzione musicale che disturbano gli audiofili. La scelta è motivata dalla necessità di continuare a dotare il sistema operativo di una piattaforma audio bluetooth completa, e l’architettura bluetooth BlueZ 5 richiede come requisito obbligatorio la presenza di Pulseaudio. Ma per quelli come me che vogliono continuare a tenersi alla larga da Pulseaudio il più possibile, esiste un documento – a cui ho in larga parte contribuito in prima persona – che mostra come configurare il sistema per continuare ad utilizzare l’audio standard ALSA come primario.

La Slackware continua ad uscire sia in versione 32-bit che 64-bit, ed oltre alla versione ARM introdotta con la 14.1 è adesso presente anche un Live CD. Slackware Live Edition è gestita da Eric Hameleers e basata sulla distribuzione -current. Al contrario di altre distribuzioni “live” basate su Slackware già esistenti (Slax, Porteus), la Slackware Live è del tutto identica alla distribuzione originaria.

ISO e torrent della versione 14.2 sono già scaricabili online, ed è possibile ordinare i CD/DVD ufficiali per contribuire al finanziamento del progetto.

Happy Slackin’ !! 😉

L’ipotesi BSD

letture

Beastie-TuxMan mano che col passare del tempo sempre più distribuzioni si stanno arrendendo all’idea di migrare a systemd come gestore di avvio e dei processi – ultime nell’elenco sono Debian e Ubuntu – tra gli utenti scontenti di questa trasformazione, che di fatto rende Linux sempre meno somigliante a un’architettura Unix SystemV/BSD tradizionale, si fa strada l’idea che si può sintetizzare nella frase: “Basta! Abbandono Linux e passo a BSD!

Questo perché systemd, per esplicita scelta del suo autore, non supporta sistemi diversi da Linux, e anzi guarda al mondo BSD con sufficienza considerandolo obsoleto e irrilevante. Di conseguenza non esiste il rischio che la febbre di systemd si estenda anche a questi sistemi, sebbene sia sempre teoricamente possibile che qualche sviluppatore BSD decida di avviare un progetto analogo per quegli ambienti.

L’idea ha accarezzato anche me, in quanto nonostante la mia Slackware sia tuttora saldamente ancorata al tradizionale sysvinit, diventa sempre più concreto il rischio che il passaggio diventi obbligatorio anche per lei in un prossimo futuro, visto che tra le grandi distribuzioni Linux non rimane più nessun altro che non sia passato, e non si può quindi sperare in baluardi di opposizione ai cambiamenti architetturali che systemd impone anche alle altre componenti di sistema che pure Slackware ha necessità di utilizzare.

Ho quindi iniziato ad analizzare alcuni dei sistemi BSD esistenti per capire se sia possibile per me migrare ad uno di essi senza dover subire troppi cambiamenti rispetto al mio abituale modo di usufruire dei miei desktop e del mio laptop.

Quello che rapidamente ho compreso è che, mentre per un utente di una generica distribuzione Linux moderna potrebbe essere relativamente indolore passare a uno dei sistemi operativi basati su FreeBSD, per un utente proveniente da Slackware ci sono diversi ulteriori aspetti da considerare. Questo perché Slackware ha compiuto negli anni diverse scelte “estreme“, e che si rivelano essere persino più estreme di quelle compiute da molti dei sistemi BSD, che sono ritenuti ambienti piuttosto ortodossi e tradizionalisti.

Andiamo a vedere alcune di queste scelte:

Slackware non usa PAM. Si tratta probabilmente dell’unica distribuzione Linux contemporanea che non utilizza PAM e che compila tutto i propri applicativi senza il supporto ai moduli di autenticazione ma solo ai tradizionali file di configurazione allocati in /etc. Unica eccezione è l’inserimento di un modulo pam “dummy” per consentire l’uso di Google Chrome, il quale è distribuito solo in formato binario e ricerca la presenza di questa libreria per avviarsi. L’avversione a PAM è uno dei portabandiera della comunità Slackware. Invece moltissimi dei sistemi BSD, tra cui FreeBSD, usano PAM già da molto tempo. Solo OpenBSD, tra i sistemi che ho visto, non usa PAM e sarebbe quindi accettabile da questo punto di vista.

Slackware non usa grub. Anche se recentemente è stato inserito come pacchetto opzionale, grub non è amato dalla comunità Slackware, che da sempre utilizza LILO come boot loader, e quindi non ha mai imparato la contorta e astrusa sintassi di configurazione di questo bootloader (specie per grub2). Invece molti sistemi di base BSD utilizzano grub come bootloader, ad esempio PC-BSD 10.

Slackware non usa PulseAudio. PulseAudio è il precedente “capolavoro” dello stesso autore di systemd, ed è diventato standard in tutte le maggiori distribuzioni Linux, interponendosi come strato di servizio audio tra le applicazioni e i driver hardware, nella gran parte dei casi senza alcuna utilità effettiva. In Slackware non esiste alcun audio server, ma gli applicativi vengono compilati per dialogare direttamente con i driver ALSA del kernel. Invece quasi tutti i sistemi BSD, sebbene non prevedano PulseAudio come componente di base, hanno compilato i vari software multimediali e ambienti grafici desktop con la dipendenza da PulseAudio.

E’ chiaro che tutte queste differenze potrebbero venir superate ricompilando opportunamente i vari componenti di sistema, ma bisogna tenere presente che la filosofia di base dei sistemi BSD è diversa rispetto a quella di una distribuzione Linux. Un BSD è distribuito in pacchetti preconfezionati che comprendono sia il kernel che l’ambiente e tutte le utility base, e l’ipotesi che l’utente finale si ricompili non solo il kernel ma anche, ad esempio, /bin/login affinchè non includa pam non è supportata in maniera ufficiale. Seguire questa strada comporta moltissimo lavoro autonomo di ricompilazione, senza aiuti da parte dei team BSD che invece spingono perché si usino i pacchetti precompilati da loro forniti, e da ripetersi ad ogni nuova uscita e per ogni singola componente che venga fornita in origine con il supporto a pam, pulseaudio, ecc.

Un ulteriore elemento da considerare è che in generale l’utente Linux è abituato a veder arrivare sul proprio sistema le nuove versioni dei pacchetti software pochissimo tempo dopo il loro rilascio, anzi nella maggior parte dei casi nello stesso istante in cui una versione software viene rilasciata ne vengono forniti i pacchetti binari per tutte le distribuzioni principali, e nonostante Slackware non sia quasi mai inclusa tra queste, noi suoi utenti abbiamo imparato già da tempo come compilarceli da soli o in quali repository dedicati andare a cercarli. Nel mondo BSD invece, un po’ per le questioni di licenza, un po’ per le patch alle volte considerevoli che devono essere create in autonomia dagli sviluppatori BSD per adattare i software, un po’ per il fatto che la struttura piramidale dello sviluppo costringe ad aspettare che un determinato software venga incluso tra i Ports ufficiali, ecc. si è costretti ad attendere diverso tempo. quantificabile anche in molti mesi, prima di poter aggiornare. In generale l’utenza BSD è più abituata ad usare la release del proprio sistema così come viene fornita, e ad attendere la successiva release che aggiornerà le componenti di base e le componenti applicative alle varie versioni decise dal team di sviluppo per quello specifico rilascio. L’utenza Slackware invece è più vicina al concetto di “rolling release“, e aggiorna per proprio conto diverse parti del sistema senza dover aspettare le uscite ufficiali della distribuzione. Questo vale soprattutto per l’ambiente KDE, che viene incluso ufficialmente in Slackware ad una certa versione, ma è prassi comune tenere aggiornato grazie a pacchetti software distribuiti separatamente.

Non ultimo aspetto da considerare è quello relativo al supporto da parte di software e driver proprietari. Se negli ultimi anni è diventato ormai abbastanza comune supportare Linux anche da parte di produttori di stampanti, scanner, telecamere, notebook, ecc. lo stesso non si può dire per i BSD, il che può significare dover essere molto oculati nella scelta degli acquisti hardware. Il portabandiera dei sistemi BSD nel mondo x86(_64) è senz’altro FreeBSD, ed è per questo sistema che si concentra la maggior parte dei rilasci software e dei supporti. OpenBSD, NetBSD e gli altri sono spesso costretti a importare le soluzioni FreeBSD o ad attendere tempi lunghi per sviluppare in autonomia delle alternative. Ma, come accennato in precedenza, FreeBSD non rappresenta la scelta ideale per un utente Slackware che non voglia ritrovarsi nella situazione in cui dopo essersi liberato dalla minaccia systemd debba invece aver a che fare con tutte le altre tecnologie che Slackware lo aveva aiutato ad evitare.

In conclusione, migrare da Linux a BSD non è così indolore come si potrebbe pensare, e va valutato seriamente se sia il caso di affrontare le problematiche che ho indicato, e sicuramente altre che ancora non ho scoperto, con lo spirito di adeguarsi alle differenze oppure di fare il possibile per riportare l’esperienza d’uso a quella a cui si è abituati in Linux. Oppure se sia tutto sommato più accettabile l’idea di adeguarsi a systemd e tutti i suoi cambiamenti, tenendo presente che in ogni caso se si ha a che fare per lavoro con ambienti Linux si dovrà comunque acquisire una certa dimestichezza con systemd pure se non lo si userà nel proprio sistema casalingo.

CC BY-NC-SA 4.0 .