Menu Chiudi

Categoria: Informatica

Ricordi di FidoNet

LoneStar 0 Commenti
letture

Giorgio Rutigliano ha recentemente reso disponibile un sito internet dedicato a FidoNet Italia.

FidoNet è la rete telematica amatoriale che è nata e si è diffusa a livello mondiale tra gli anni 80 e i primi anni del 2000, prima che Internet fosse largamente disponibile ed accessibile. Si basava sull’uso dei modem analogici connessi alle normali linee telefoniche voce e sulle comunicazioni asincrone, ovvero l’invio di un messaggio impiegava ore/giorni ad arrivare a destinazione e altrettanto tempo serviva alle risposte per tornare al mittente.

Io ho fatto parte di FidoNet Italia, come nodo membro, da circa il 1989 fino al 1996/97. Ne uscii non tanto per le problematiche legali connesse al Fidobust, ma piuttosto perché crebbe in me la passione per le comunicazioni in tempo reale rappresentate dalle chat, IRC, Videotel e avevo sempre meno interesse a lasciare il mio PC dedicato alla BBS.

Va detto che la rete mondiale FidoNet non ha mai cessato di esistere in questi anni. E’ diminuita moltissimo l’adesione ma un certo numero di nodi è rimasto sempre attivo, sopratutto in paesi dove è diventata anche veicolo di attivismo politico.

Recentemente in Italia si è avuto un ritorno di fiamma per Fidonet e le BBS, anche se limitato ai vecchi utenti e Sysop che ancora hanno memoria del passato, e alcuni nodi stanno tornando ad essere operativi in rete utilizzando internet come trasporto al posto delle vecchie linee telefoniche.

Non ho ancora considerato seriamente l’idea di poter tornare in rete, ma forse chissà…

Il minimalismo nello sviluppo software

LoneStar 0 Commenti
letture

Questo è un interessante talk tenuto alcuni mesi fa dall’amico Katolaz e che descrive cosa sia il minimalismo e quanto questo sia importante nell’ambito dello sviluppo software e nel mondo GNU/Linux.

Mantaining qmail in 2019

LoneStar 0 Commenti
letture

Plasma5 Wayland e Slackware

LoneStar 0 Commenti
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

LoneStar 2 Commenti
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 🙂

CC BY-NC-SA 4.0 .