Un server, Debian, systemd e assurdità varie

Ho un Raspberry Pi che gira per casa, anzi, non gira: sta fermo vicino al router. Dopo vari altri usi, da tempo sopra ci stanno OpenVPN, ddclient, Nginx e PHP (che non formano lo stack LEMP perché uso sqlite). Nulla di particolarmente esoterico.

Però è lento e ogni volta che lo avvio torna al 1970.

Il ritorno al 1-1-1970 è dovuto al fatto che non ha un RTC.
Dopo “accurate” indagini con top, ho concluso che il fattore limitante della velocità è la CPU, seguita dalla SD.

Potrei installare MariaDB e sperare che sia un po’ più veloce di sqlite, potrei usare software PHP meno laggoso e mal programmato, ma il fatto di dover continuamente lottare con NTP per costringerlo a ogni riavvio a sincronizzarsi davvero col server perché ogni volta trova qualche scusa per non farlo, mi hanno fatto passare la voglia. L’impressione generale è anche che Arch per ARM, per RPi specificamente perché non ho altri aggeggi ARM su cui provarlo, sia gestito più “come viene viene” rispetto ad Arch normale, con pacchetti aggiunti e rimossi senza criterio dall’immagine di installazione, strane configurazioni che mandano a farsi benedire ogni tentativo di far funzionare netctl e poca comunicazione sui cambiamenti rilevanti dall’upstream che potrebbero trasformare un “pacman -Syu” in un disastro.
Ma è chiaramente solo una mia impressione assolutamente non corrispondente alla realtà…

Comunque, come dice il vecchio detto, “throw more computing power at it”: vediamo come rimpiazzare il RPi.

Esistono altri graziosi aggeggini ARM, ma o sono lenti, o vanno importati dalla Cina e con le tasse vengono a costare il triplo del prezzo sbandierato a destra e a manca e già di suo doppio rispetto al RPi, o hanno problemi di compatibilità con Linux che richiedono di installare driver proprietari con metodi poco ortodossi e tenersi per anni vecchie versioni del kernel perché il produttore non ha alcun interesse a rilasciare nulla di più nuovo, o una combinazione di tutte queste cose. E non risolverei il problema “lottare con NTP in continuazione”.
Infine, il prezzo sembra basso, ma bisogna includere anche SSD, alimentatore perché ovviamente ognuno usa uno dei 2352590328 connettori esistenti e un case di qualche genere, quindi la convenienza magicamente svanisce.

Io voglio la stabilità, è un server, che diamine! Se davvero la volessi forse non avrei dovuto installare Arch sul RPI, ma su Raspbian non sono mai riuscito a far funzionare OpenVPN nonostante sia facile e ci siano milioni di guide, mentre su Arch è andato tutto magicamente a posto all’istante seguendo la prima guida trovata su internet.

Quindi lanciamo un altro po’ di cash in direzione del server e costruiamo un PC x86_64: scheda madre con CPU Intel J1900 annessa, 4 Gb di RAM, 60 Gb di SSD, case ultraeconomico con alimentatore da 75 W per un computer che ne consuma 20 se proprio va male ma meno non si trovava, ed ecco fatto.

Vediamo ora quali sono le principali distro Linux da server esistenti in questo momento.

  • Ubuntu server LTS: un grave problema è che solo alcuni (pochi) pacchetti sono veramente supportati per i 5 anni promessi: per gli altri ci si attacca. Inoltre, sembra che nell’ultima LTS sia stata effettuata una scelta discutibile su quale versione del kernel metterci. Inoltre, tutte le volte che ho preso Ubuntu in mano, è andato in frantumi solo a guardarlo.
  • CentOS: 10 anni di supporto e la versione 7 è uscita qualche giorno fa. La principale critica che ho trovato è che “il package manager yum una volta faceva schifo ma oggi è irrilevante”. Nginx non sembra stare nei repository ufficiali (ma ddclient sì, sorprendentemente?), ma Apache va bene lo stesso. Un altro problema è che dopo un po’ ci si ritrova a far girare software vecchissimo, ma che almeno funziona. L’opinione generale è “usalo se sai già usarlo”, mi sembra poco gradito agli smanettoni.
  • Debian: a breve arriva la 8, che ha anche un nome ma io trovo più facile fare mente locale con una sequenza di numeri ordinata rispetto a una sequenza di nomi arbitrari. A parte la digressione sulla nomenclatura, sembra essere un buon candidato.

Bene, installiamo Debian.

Il problema è che è Debian 7, non c’è systemd! Nonostante l’odio inverecondo che l’intero genere umano sta riversando ininterrottamente su systemd dalla sua nascita fino ad ora, io voglio systemd, a me systemd piace, mi sembra molto più semplice e ordinato gestire tutto da lì che da milioni di file di configurazione sparsi.
Non parlo solo di “systemctl start\stop\enable\disable\restart\reload”, che già in varie forme esisteva in tutte le distro. Parlo anche dei comandi timedatectl, hostnamectl, localectl, della possibilità di configurare le interfacce di rete, di creare dei simil-cron-job, dell’esistenza del journal e del comando journalctl, della possibilità di creare directory (temporanee, di solito) all’avvio, e un’infinità di altre cose.
Tuttavia, ad esempio, localectl si usa una volta e mai più, bene. C’erano già prima dei comandi e dei file di configurazione che facevano la stessa cosa e anche più, bene.
La mia esperienza era che per settare la keymap (senza avere a disposizione una GUI) bisognava aggiungere righe inimagginabili in file impensabili, rovistando selvaggiamente nella documentazione per capire quali erano e dove stavano e avendo più possibilità di file da andare a modificare, metà delle quali non funzionanti perché la guida risale al 2002 o altri file le sovrascrivevano. Con “localectl set-keymap it” tutto va a posto, subito, funziona, senza stare a leggere e interpretare guide, senza stare tanto a pensare su qualcosa di così banale.

Fortunatamente bisogna installare solo due pacchetti con apt-get per avere systemd, ho cercato accuratamente su internet ma non c’è altro da fare. Meno male.

Se avvio aptitude, mi dice che systemd non è ben installato e lo vuole disinstallare. Aptitude, pls.

Non so che altro fare, visto che su internet non trovo informazioni a riguardo.
Il manuale, guida, wiki o quello che è di Debian è un’accozzaglia di comandi da accettare con fede incondizionata, spesso vecchi e non più funzionanti. Sempre che ci sia qualcosa riguardo a quello che sto cercando di fare: di solito dice, seppure con belle parole, “RTFM”; cioè di leggersi tutto il manuale facendo “man nomecomando”.

In quei manuali c’è tutto, certo, ma trovare proprio quella cosa che ti serve è un’impresa. Ad esempio, nel tentativo di assegnare al server un IP statico e cose simili, ho consultato il manuale di nonsocosa Debian usasse allo scopo. Ho trovato l’opzione che mi serviva, ma era descritta in maniera tale che non si capisse QUALI “comandi” devo scrivere in QUALE ordine e su QUALE riga nel file di configurazione. Ma sono chiaramente io troppo stupido per leggere un manuale.

La guida\wiki di Debian forniva solo due esempi stitici e con una riga in più che non era presente nel file di default che non so a cosa diamine serva, c’era solo scritto “mettici quella riga”. Oltre alle altre da mettere.

Fortunatamente l’intuizione e l’esempio stitico hanno fatto il miracolo e al riavvio il server aveva l’IP da me assegnato.

Ora, vediamo un po’ come funziona systemd: male.
Non so cosa diamine succeda, io l’ho installato nella maniera dichiarata da più fonti come l’unica vera e autentica maniera di installarlo.

I comandi timedatectl, hostnamectl, localectl e journalctl non esistono. Cominciamo bene, insomma.
Almeno systemctl va.

Facciamo una breve digressione: avete presente il pannello dei servizi di Windows, services.msc? I servizi stanno tutti in un luogo, puoi avviarli e fermarli e vederli e smanettarli come ti pare.
Così funziona systemctl in teoria, così funziona systemctl in pratica su Arch. Col vantaggio, rispetto a Windows, che gli “unit files” stanno tutti in /usr/lib/systemd/system/. Se vuoi modificare a mani nude la loro configurazione, o aggiungerne altri che in realtà vanno in /etc/systemd/system/. La wiki di Arch (sempre sia lodata e siano lodati anche quelli che la scrivono!) spiega anche come creare le unit, invece di mandarti a quel paes… ehm… dirti di leggere il manuale.

Ma sì, lo sappiamo ormai, sono solo io che sono troppo stupido per comprendere che RTFM è parte integrante di tutto e dovrei smetterla di lamentarmi e leggere il manuale, anche se non si capisce nulla, anche se contiene errori, anche se non risponde alla mia domanda. Dopotutto il manuale è lì, perché duplicare gli sforzi scrivendo anche una wiki?

…perché allora Debian ha manuali e wiki che non stanno in “man”? Perché la wiki di Arch (e quella di Gentoo) sono unanimemente considerate eccellenti oltre ogni dire?

Ah, basta domande retoriche, torniamo a Debian.
Ho introdotto un confronto con services.msc di Windows: immaginate ora che il pannello contenga tutti i servizi, ma se su alcuni premi “disattiva” ti dice “NESSUN SERVIZIO CON QUEL NOME”, che se cerchi di guardare le proprietà il servizio improvvisamente non esiste, che se cerchi di farne partire uno ti dice “no, non esiste”, che appena installi qualcosa crea un servizio che puoi solo avviare\fermare ma non disattivare\rimuovere\riattivare, che tutte le volte devi aggiungere .service alla fine altrimenti non capisce (ma è il default, secondo la documentazione di systemd era opzionale scriverlo, infatti su Arch funziona senza! Mi sono perso qualcosa?), se cerchi con “find / -name openvpn” dove diamine sta l’unit file di OpenVPN, che sicuramente esiste perché “systemctl start\stop openvpn.service” funziona, non trovi nulla…
Ecco, questo è Debian.

Oh, certo, sono io che non sono riuscito a seguire la semplice e dichiarata da più fonti procedura per installare systemd. Tutta colpa mia, sempre colpa mia…

Inoltre, su Arch, si poteva fare una cosa magnifica col servizio di OpenVPN: avviare più server in contemporanea. Avendo i file serverasd.conf e serverlol.conf, si poteva fare:

systemctl start openvpn@serverasd
systemctl start openvpn@serverlol

ed ecco due server attivati, per aver OpenVPN su due porte diverse in contemporanea.

Su Debian non c’è verso di farlo, non funziona, non va, non parte, non trova il servizio.
Avrei voluto ispezionare l’unit file, ma non sembra esistere da nessuna parte nonostante il servizio sia avviabile e fermabile; ma non attivabile\disattivabile, cosa che systemd fa con un symlink.
Inoltre, /usr/lib/systemd/system/ non esiste.
Ho cercato su internet e ho scoperto che 6 mesi fa l’unit file era borkato e un tale l’ha fatto funzionare e ce ne fornisce il contenuto, ma non la posizione.
Dopo aver fatto i quadrupli salti mortali, ho ottenuto l’agognata informazione che sembra essere un segreto di Stato da talmente è introvabile: la cartella è /lib/systemd/system/. Purtroppo, dentro non c’è nulla che somigli anche solo vagamente a openvpn.service.

Ma che diamine, è un’installazione standard che più standard di così si muore!
Ho aggiornato l’intero sistema con apt-get appena finita l’installazione, cosa peraltro inutile perché ho usato l’immagine “netinstall”, poi in pratica ho fatto

apt-get install systemd systemd-sysv openvpn

e riavviato, e il risultato è questo macello!? Con Debian 8 che dovrebbe essere rilasciato ufficialmente tra meno di un mese e dovrebbe includere systemd di default?

Dopo aver appurato che CentOS (come Arch) supporta server multipli di OpenVPN attivi in simultanea, ho scaricato CentOS.

Dove andremo a finire…

Annunci

3 pensieri su “Un server, Debian, systemd e assurdità varie

  1. Pingback: Un server, CentOS e assurdità varie | while(false) do {/*nothing*/};

  2. Pingback: Accurata descrizione dell’installazione di una distro Linux | while(false) do {/*nothing*/};

  3. Pingback: Sull’abbondanza di distro Linux | while(false) do {/*nothing*/};

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...