• Autore:   Elia Argentieri
  • Ultima modifica:   23 giu 2022 18:29
  • Redazione:   23 giu 2022 18:27
  • Sorgente di questa pagina
  • Tempo di lettura:   6 minuti

Quest’ultimo mese è stato molto turbolento per questo sito. Si sono succeduti diversi eventi che hanno reso impossibile mantenere in piedi tutti i servizi offerti.

Ci sono stati problemi con il fornitore di connettività ad internet e la morte di dischi rigidi invecchiati. Una dietro l’altra!

Vediamo come sta andando.

Lo stato dei servizi monitorati da uptimerobot.com
Lo stato dei servizi monitorati da uptimerobot.com

Procediamo con ordine: prima ci si è messa la Tiscali, operatore telefonico e internet per quanto mi riguarda assolutamente da evitare! Già quando il passaggio a Tiscali divenne effettivo ad Ottobre dello scorso anno, se il buon giorno si vede dal mattino… il router fornito da loro non permette l’inoltro di porte TCP e UDP… ma cosa me lo vendi a fare l’IPv4 statico se poi non posso configurare il NAT?!? Incompetenza pura.

Soluzione: compro un router decente e uso quello al posto di quello fornito da loro. Grazie AGCOM che ci consenti di usare il “router libero”!

Nuovo problema: dopo mesi, ci accorgiamo che manca la banda promessa e scopro che Tiscali ha dei GIGANTESCHI problemi di peering. Non male! Ai piani alti di Tiscali penseranno che possono permettersi di trascurare questi piccoli dettagli a cui non importa a nessuno, come la qualità dei router e gli accordi tra operatori. Infondo il loro lavoro è solo quello di farci arrivare la bolletta a casa ogni mese e farcela pagare, mica quello di fornire un servizio migliore della concorrenza. /S

Per loro il problema della banda non sussiste in quanto la portante arriva sul mio router a 130Mbps e rotti. Bene, peccato che gli speedtest dicano altro. Hanno ovviamente tentato di scaricare la colpa sulla mia rete locale, proponendomi di modificare il DNS, ridurre il numero di dispositivi collegati al Wi-Fi, riavviare il router, chiudere le porte TCP (?) e per finire mi hanno detto che senza il loro router non potevano fare le prove necessarie per sistemare il guasto. Ovviamente non sanno con chi stanno parlando… Comunque li ho accontentati e ho rimontato il router “homix” della Tiscali e ciò ha riaperto il problema dell’inoltro delle porte.

Soluzione: adesso uso Cloudflare. Non mi piace come soluzione, ma è l’unica alternativa gratuita ed efficace che ho trovato. Cloudflare potremmo definirlo come un Man in the Middle as a Service, o MitMaaS. Però almeno il loro servizio funziona e sembra di qualità. Uno dei servizi offerti è Argo Tunnel, che consente a server non raggiungibili da Internet, come il mio povero serverino censurato da Tiscali, di stabilire una connessione persistente con Cloudflare e diventare così raggiungibile tramite Cloudflare. Dimentichiamo la sicurezza e la privacy: tutti i nostri dati viaggeranno in chiaro all’interno dell’infrastruttura di Cloudflare. Poco male per un sito pubblico, non proprio ideale per le password di accesso a servizi interni, come Pleroma, Home Assistant, Seafile, CalDAV, ecc. Consoliamoci col fatto che ci dovrebbero proteggere dagli hacker cattivi…

Nuovo problema: è morto il disco rigido del server. Ad essere sinceri non è ancora morto, ma visto che ogni poco manda in crash il sistema, perchè perde settori, eviterei accanimenti terapeutici e andrei avanti con la nuova tecnologia a stato solido.

Visto che l’uptime del servizio era ormai rovinato, quando ho comprato un SSD Crucial MX500 da 1 TB per sostituire il defunto disco rigido, non mi sono accontentato di tenere Manjaro, una distribuzione assolutamente non adatta ad uso server, ma ho deciso di passare a NixOS 22.05 stabile. Ormai da un po’ lo uso sul desktop e ci ho un po’ preso la mano, ma è in ambito server che NixOS brilla di più.

Sebbene non tutti i servizi siano in piedi, perchè c’è da riconfigurare tutto usando il linguaggio nix, non ho riscontrato problemi, anzi spesso configurare un servizio su NixOS è molto, molto più rapido e veloce che usando distribuzioni classiche, senza contare il fatto che otteniamo un sacco di vantaggi come aggiornamenti atomici, rollback facili e riproducibilità dalla configurazione.

Per ora l’unico servizio che da problemi su NixOS è, guarda caso, Seafile, che ancora una volta, da problemi vista la sua stranezza. Comunque prima o poi si risolverà anche questa.

Se confrontiamo Manjaro con NixOS in ambito server, è facile capire quale delle due vince a man bassa. Se Manjaro è così inadatta, perché l’ho scelta in primo luogo, vi starete chiedendo. Ebbene prima di Manjaro usavo Debian, una distribuzione eccellente per server, ma che ha il ben noto problema di fornire pacchetti un po’ datati. Vista la necessità impellente di montare un server di Minetest per giocarci, non era proprio il modello di rilascio adatto: non potevo aspettare mesi che arrivasse l’aggiornamento sul server, mentre il client era già aggiornato, c’è la smania di provare la nuova versione! Così, dopo essermi entusiasmato con il rilascio puntuale di pacchetti aggiornati, la velocità di pacman e la semplicità dei pacchetti di Manjaro, ho voluto provarla anche su server. Nel tempo si è rivelata una pessima scelta: aggiornamenti che contengono pacchetti rotti, con dipendense sbagliate, script di aggiornamento totalmente assenti (per esempio ad ogni rilascio maggiore di PostgreSQL va fatto l’aggiornamento a manina). Questi problemi portano a sprecare un sacco di tempo a capire cos’è successo, come risolverlo e mantenere in piedi la baracca, solo per un aggiornamento “stabile”.

La cosa bella di Arch e Manjaro è che hanno l’AUR (Arch User Repository). Fantastico. C’è di tutto. Peccato che manchi quasi tutto dai repository ufficiali delle già citate distro. L’effetto finale è che sembra di aver installato Gentoo, da quanto ci tocca far frullare i compilatori. L’AUR, infatti, è una distribuzione di sorgenti, quindi non fornisce la comodità di un build server, da cui possiamo scaricare i pacchetti già compilati e pronti all’uso, no, ci tocca eseguire i PKGBUILD (alla fine sono degli script shell).

Allora parliamo di nixpkgs, il repository principale di NixOS. Anche in questo caso stiamo parlando di una distribuzione di sorgenti, con una grossa differenza però: prima che nix decida di compilare un pacchetto, va a controllare se quel dato pacchetto, identificato da un hash, è già stato compilato e reso disponibile sulla cache binaria di nixpkgs. Nella stragrande maggioranza dei casi, il pacchetto è in cache e basta scaricarlo e installarlo, già pronto all’uso. Potremmo dire che è un modello di distribuzione “ibrido” o più precisamente a sorgenti con cache binaria.

A questo punto potrei pubblicare i miei file di configurazione di NixOS per mostrarvi esattamente come è configurato il server e per permettervi di replicare e personalizzare il vostro server di NixOS, ma rimandiamo ad un prossimo articolo (^o^;)

またね!