12 ottobre 2021

ProFTPd: FTP server su Linux usando Webmin

proFTPd

E' uno dei server FTP più diffusi per Linux, usato da una folta schiera di siti e progetti presenti su Internet per gestire il trasferimento di file. Qui su Wikipedia le schede di confronto con altri server FTP.

Installazione e configurazione di base con Webmin

Per molti amministratori di Linux, l'unico modo di procedere è via command line, configurando tutto a manina. Per quelli più pigri come me, a volte è più comodo e conveniente avere una interfaccia centrale un po' più grafica che predispone molti moduli e opzioni, secondo delle linee guida comuni.

Per i server senza GUI, questa interfaccia è Webmin, che guarda caso, dispone anche del modulo proFTPd nella sezione 'Server'.

Se non è installato, cercate nella lista dei moduli non utilizzati, premete il tasto "Installa modulo" e Webmin si preoccuperà dell'installazione e dell'attivazione del server, mettendolo tra i servizi avviati al boot.


 

Non è detto che le vostre esigenze siano proprio le stesse del creatore del modulo Webmin. Infatti ho scoperto che molte delle configurazioni descritte sotto le ho dovute configurare comunque da terminale, o dalla sezione 'Configurazione manuale dei file' del modulo Webmin.

Infatti, se avete dimestichezza con l'inglese, o se vi fidate dei traduttori automatici, vi consiglio la lettura della documentazione scritta dall'autore del modulo Webmin. Tra le decine di opzioni e di configurazioni  possibili, ha reso in forma grafica e 'assistita' quelli più utili ai suoi scopi e alle sue preferenze. Le altre dovrete smanettarle voi in qualche altro modo. Questo è uno dei motivi per scrivere la paginetta di blog con i miei appunti.

Opzionale: server virtuali

Dato che nella mia configurazione non ho necessità di gestire tanti siti diversi con lo stesso server, non ho configurato questa opzione. 
Per attivare questa opzione, sarà necessario disporre di più IP pubblici a cui associare dei nomi di server diversi, ma tutti afferenti alla stessa istanza di proFTPd. 

Webmin mette a disposizione una paginetta dedicata in cui configurare i settaggi specifici per i server virtuali da configurare. Le opzioni che valgono per tutti i server non vanno ripetuti, ma inseriti in una sezione 'Global' del file di configurazione.

Per tenere tutto in ordine, è consigliabile definire un file aggiuntivo di configurazione per ogni server virtuale. Questo è lo standard che segue anche il modulo Webmin.

Opzionale: utenti virtuali

Gli utenti di default di proFTPd sono gli utenti configurati nel vostro Linux: root, administrator, pippo, pluto e paperino. Per questi utenti potete stabilire se effettivamente possono collegarsi in FTP, quale directory utilizzare come 'Home', cosa possono fare o non fare e con che permessi.
 
Se dovete aprire l'accesso FTP ad utenti che non sono i vostri utenti di rete, ma clienti, collaboratori o semplicemente amici, non è necessario creare gli utenti come Users di Linux.
Per questa necessità proFTPd ha pensato di tenerli distinti dagli utenti 'veri' e li chiama utenti 'virtuali'.

Gli utenti virtuali hanno tutte le caratteristiche degli utenti veri, ma sono elencati altrove rispetto agli utenti di sistema, e invece di essere autenticati dal sistema, verranno autenticati dal server FTP.
 
Se sono tanti, potrebbero essere inseriti in una tabella di database, ad esempio, come in questo quesito di Stack Overflow.

Nel nostro caso, sono pochi, e a me basta un piccolo file dedicato, che è una delle opzioni consentite, come descritto in questa domanda posta su Stack Overflow (già sentito nominare?).
Questo file di configurazione specifico va indicato nel file di configurazione generale, insieme all'indicazione del modulo di autenticazione, come segue:

<IfModule mod_tls.c>
TLSEngine    on
TLSLog    /var/log/proftpd/tls.log
TLSProtocol    TLSv1.2
 

Per aggiungere gli utenti è necessario usare un programmino accessorio chiamato ftpasswd, nel quale indicheremo tutti i parametri che caratterizzano l'utente.
Di default il programmino ci chiederà la password, che cripterà secondo le nostre indicazioni, in modo che non sia leggibile da chi dovesse aprire il file, e aggiungerà un nuovo utente in coda al file.

# ftpasswd --passwd --file /etc/proftpd/virtual_users.passwd --sha512 --gid 99 --uid 99 --shell /sbin/nologin --name pincopallo --home /vhosts/example.net/site1/public_html

 
Non è garantito che gli utenti virtuali funzionino al primo colpo. Qui una interrogazione su Stack Overflow (Server Fault) per chiedere perché questi utenti si vedono negare l'accesso.

Chi può fare cosa

Per ogni utente è possibile definire limitazioni sui comandi disponibili. 
La gerarchia pensata dall'autore è, grosso modo:
Server -> Cartella/Directory -> Comandi -> Utenti
 
In questa ottica, si possono creare delle strutture gerarchiche per ogni server, dove per ciascuna cartella radice si elencano i comandi disponibili ai vari utenti. Il sistema è potente, ma anche abbastanza complesso.
Così è possibile creare scenari del tipo: 
  • cartelle in sola lettura
  • cartelle in sola scrittura
  • cartelle 'cieche' dove si può scrivere ma non vedere il contenuto caricato dagli altri
  • Server con determinati utenti e non altri, o restrizioni sugli IP di provenienza
  • cartelle con uno scrittore e scaricatori anonimi

Opzionale: NAT e collegamento PASV

 Se, come nel mio caso, il server FTP si trova dietro un firewall e senza un IP pubblico, dovrete configurare anche il NAT, ossia la mappatura tra IP pubblico e IP privato del server, e con questo, spesso anche il collegamento dati PASV, cioè la modalità di trasferimento per cui le porte vengono fornite dal server e non dal client.

Il collegamento passivo consente di semplificare la configurazione del firewall. Infatti sarà il server ad aprire le porte di trasferimento dati e a comunicarle al client. Sul firewall sarà necessario solo indicare un range di porte, tipicamente tra la 50000 e la 60000, su cui consentire traffico FTP Dati.

Trovate qui la documentazione ufficiale per configurare le opzioni NAT e firewall.

Opzionale: connessione crittografata e TLS

 Come saprete, l'FTP viene visto un po' male da chi si occupa di sicurezza. Infatti, nella sua versione orginale (e ormai arcaica) l'autenticazione FTP viene inviata in chiaro

Per ovviare a questa evidente falla di sicurezza che ci espone ad orecchie indiscrete, gli esperti del settore hanno pensato a due soluzioni diverse: SFTP, ossia FTP Sicuro, e FTP su TLS (Transport Layer Security).

FTP su TLS fa lo stesso percorso dell'HTTPS, ossia stabilisce prima una connessione crittografata e certificata, e poi prosegue con i comandi standard ma su un canale protetto.

Anche questa opzione è stata trascurata dal creatore del modulo Webmin, infatti per abilitarla dobbiamo andare a modificare a manina i file di configurazione, ad esempio dall'ultima paginetta del moduo.

Nel file di configurazione principale, proftpd.conf  attiviamo l'inclusione del modulo, e poi andiamo nel file di configurazione specifico ad impostare tutte le nostre preferenze. 


 

Qui trovate la documentazione ufficiale proFTPd del modulo TFS (in inglese).

Le prime voci sono autoesplicative:

<IfModule mod_tls.c>
TLSEngine    on
TLSLog    var/log/proftpd/tls.log
TLSProtocol    TLSv1.2

Negli esempi trovate abilitati anche SSLv.2 e v.3. Carissimi, sto scrivendo nel 2021, sconsiglio vivamente di attivare qualunque protocollo più antico di TLSv.1.2, pubblicato nel 2008, ormai più di dieci anni fa!

Ma chi ci assicura?

Per utilizzare il TLS serve un certificato. Trovate in circolazione le istruzioni per generare un certificato da command line, ma, dato che stiamo utilizzando Webmin, possiamo anche sfruttare le sue potenzialità in questo ambito.

Dalla pagina di configurazione principale di Webmin, tra gli ultimi sottomoduli, troviamo 'SSL Encryption', come mostrato nella sua documentazione.

Da questo modulo è possibile vedere il certificato auto-firmato di Webmin, richiedere nuovi certificati auto-firmati, configurare la propria centrale di autorità (CA), e anche chiedere certificati esterni a Let's Encrypt.

Nel mio caso, ho semplicemente copiato il percorso del certificato auto-firmato di Webmin, e l'ho riutilizzato pari pari in proFTPd.

TLSRSACertificateFile    /etc/webmin/miniserv.pem
TLSRSACertificateKeyFile    /etc/webmin/miniserv.pem

E' chiaro che, lato client, questo certificato viene segnalato come autentico ma non verificabile, e può richiedere un consenso esplicito da parte dell'utente per considerarlo attendibile. E' sicuramente più professionale chiedere un certificato Let's Encrypt per il nostro dominio, purché ci organizziamo anche per il suo rinnovo periodico. 

Alziamo l'asticella, o forse no

Purtroppo non tutti i client, e tanto più i loro operatori, sono in grado di operare o di configurare un canale protetto. Per questo motivo, è possibile lasciare opzionale sia il collegamento sicuro TLS del canale dei comandi FTP, che quello dei dati. Nel nostro caso, abbiamo lasciato commentato l'istruzione di configurazione che obbliga i client ad usare il TLS.

# Are clients required to use FTP over TLS when talking to this server?
#
#TLSRequired    on

Non bisogna dimenticare che se abbiamo scelto e configurato un trasferimento di tipo passivo o PASV, i collegamenti da proteggere sono due, quello dei comandi FTP e quello del trasferimento dei blocchi di dati. Sarebbe opportuno proteggere anche la seconda connessione, ma, ancora, non tutti i client hanno questo livello di sofisticazione. 

Bisticci con FileZilla

Ho collaudato il server FTP usando FileZilla da Windows, ma non tutto è filato liscio, in particolare da quando ho attivato il TLS.

Come documentato su StackOverflow e in altri blog non sempre il TLS risolve tutti i problemi, anzi a volte ne crea di nuovi.  

Stato:    Connessione stabilita, in attesa del messaggio di benvenuto...
Stato:    Inizializzazione TLS...
Stato:    Verifica del certificato in corso...
Stato:    Connessione TLS stabilita.
Stato:    Accesso effettuato
Stato:    Recupero elenco cartella di "/"...
Comando:    CWD /
Risposta:    250 comando CWD eseguito con successo
Comando:    TYPE I
Risposta:    200 Tipo impostato a I
Comando:    PASV
Risposta:    227 Entering Passive Mode (2,116,27,205,217,118).
Comando:    MLSD
Risposta:    150 Apertura della connessione dati in modalità BINARY per MLSD
Risposta:    425 Impossibile aprire la connessione dati: Operazione non permessa
Errore:    Non è stato possibile leggere il contenuto della cartella
Stato:    Recupero elenco cartella di "/"...
Comando:    CDUP
Risposta:    250 comando CDUP eseguito con successo

Come vedete dal tracciato, il comando MLSD fallisce. Lato proFTPd troverete l'errore corrispondente nel log TLS.

Una possibile soluzione sta nel rilassare le richieste che facciamo ai client TLS, esattamente come indicato nei commenti del file tls.conf

# ... or the same with relaxed session use for some clients (e.g. FireFtp)
TLSOptions        NoCertRequest EnableDiags NoSessionReuseRequired

 

10 giugno 2021

Scuola Montessori a Pavia: rischio di estinzione

Riporto la notizia della frattura fra Istituto Comprensivo di Cava Manara, Ufficio Scolastico Territoriale, Comune di Sommo, Associazione Montessori Attiva di Pavia e genitori sul progetto di scuola Montessoriana che ha trovato spazio presso la scuola Passerini di Sommo, gestita dall'IC di Cava Manara.

Venerdì 7 maggio 2021, con una comunicazione non ufficiale quanto lapidaria, l'ICC di Cava Manara comunica ai genitori dei 25 bambini iscritti alla prima a/s 2021-22 che l'istituto non avrebbe più offerto il corso a didattica differenziata Montessori, chiedendo di scegliere tra il corso tradizionale e il trasferimento, entro lunedì 10.

La comunicazione, un fulmine a ciel sereno, lasciava sbigottiti i genitori e tutte le parti promotrici del progetto.

Il 19 maggio Montessori Attiva e genitori organizzano una manifestazione davanti all'Ufficio Scolastico Provinciale a Pavia in Piazza Italia.

La manifestazione vede la partecipazione di alcuni politici (tra cui il consigliere regionale del M5S Simone Verni) e di una rappresentanza del comune di Sommo, che ha investito soldi ed energie a sostegno dell'iniziativa (interventi di riqualificazione urbana, presidio giornaliero della Polizia Locale, gestione traffico, gestione mensa  ecc.).

Per contro, il personale dell'Ufficio Scolastico, diretto dalla d.ssa Letizia Affatato, e dell'IC di Cava Manara, diretto dalla D.S. d.ssa Oglio, sono marcatamente assenti, non ricevono delegazioni, e sembrano ignorare completamente le proteste.

I giornali locali fanno eco, tra cui "La Provincia Pavese" e "Il Ticino".

https://video.laprovinciapavese.gelocal.it/locale/genitori-e-bimbi-in-protesta-sotto-la-provincia-no-alla-chiusura-del-corso-montessori/147172/147871

https://www.ilgiorno.it/pavia/cronaca/prima-slata-metodo-montessori-1.6382511

In un video caricato su YouTube, Montessori Attiva e genitori spiegano la ragione delle loro proteste e del disappunto per i tempi e i modi con cui l'Istituto ha comunicato di non voler attivare la classe prima per l'anno scolastico 21/22.

Il 24 maggio, il consiglio di istituto approva la formazione della classe prima, a/s 21-22 a metodo differenziato Montessori, a condizione che vi siano sufficienti insegnanti.

In un video caricato su YouTube, l'1 giugno,  la Direttrice Scolastica giustifica il ritiro del sostegno all'iniziativa per mancanza di insegnanti formate. Servirebbero infatti 8 docenti formati per consentire di coprire tutte le ore nelle classi -dalla prima alla quinta- e al massimo la scuola potrebbe averne 5.

Il 2 giugno, un nuovo articolo pubblicato sulla Provincia Pavese riporta la posizione dei genitori che ribadiscono la loro scelta di iscrivere i bambini alla classe prima, metodo Montessori, e l'impegno piuttosto nebuloso della D.S. di "non affossare" questa opportunità.

https://laprovinciapavese.gelocal.it/pavia/cronaca/2021/06/02/news/scuola-montessori-le-mamme-non-ritirano-le-iscrizioni-1.40345257 

D'altronde, l'Associazione Montessori Attiva ha attivamente assistito e ricercato le insegnanti aggiuntive ogni anno, per ogni classe prima avviata. Ha promosso corsi e sostegno per la formazione delle insegnanti in collaborazione con l'Opera Nazionale Montessori.  Quest'anno, finalmente, si giungeva al completamento del ciclo, con l'uscita della classe quinta, la prima partita nel 2016. Insomma, a parte trasferimenti e abilitazioni, si cominciava ad avere un gruppo di docenti montessoriane che facessero da nucleo stabile al plesso, che è la condizione necessaria per non arrivare ogni anno nel dubbio della continuità.

 Parallelamente, a Vigevano, i genitori dell'unico Asilo Nido comunale in provincia a Metodo Montessori, protestano per il rischio di chiusura, a seguito della decisione di affidare il servizio in appalto esterno:

https://laprovinciapavese.gelocal.it/pavia/cronaca/2021/06/05/news/nido-a-rischio-l-insegnamento-montessori-1.40357150

 

 

27 marzo 2021

Franco Lorenzoni: arte e bellezza nella scuola primaria

 Mi segno qui un appunto per la serie didattica primaria / Montessori / maestri e maestre che fanno la differenza.

Riporto la notizia che il maestro (ormai in pensione) Franco Lorenzoni ha ricevuto dall'Università di Milano-Bicocca la laurea honoris causa in Scienze della Formazione Primaria, il 24 marzo 2021.

Un riconoscimento forse tardivo per una persona che da anni si batte e propone concretamente una didattica esperenziale piuttosto che nozionistica, come vorrebbe il curriculum tradizionale della scuola primaria italiana.

Franco Lorenzoni ha insegnato per quarant'anni a Giove in Umbria, e ha fondato con Roberta Passoni la Associazione Cenci casa-laboratorio, dove portare avanti tutte quelle attività formative che nella scuola tradizionale 'stanno strette'.

Ho provato ad ascoltare le parole del Maestro, e mi sono proposto di leggere qualche suo scritto.

Il richiamo a provvedere "spazi dell’educare ispirati alla bellezza" mi suona familiare. E' uno dei temi di Maria Montessori, che ha spesso sottolineato come l'ambiente in cui si svolge l'apprendimento deve essere improntato alla bellezza, perché la bellezza è stimolante, educativa ed è mezzo e fine della formazione.

Riferimenti

 La sua pagina Facebook: https://www.facebook.com/lorenzonifranco53/

Una intervista con resoconto di alcune esperienze didattiche:

https://www.youtube.com/watch?v=rD5BWW7yBQ4&authuser=0

Libri: 


 

 

 

20 gennaio 2021

Monitorare un UPS sulla rete locale usando NUT

 In un post precedente abbiamo visto come monitorare un UPS collegato via USB ad un server Ubuntu

Se abbiamo un UPS con sufficiente potenza e uscite, possiamo alimentare altri dispositivi sulla rete locale, e sarebbe carino aggiornare anche loro sullo stato dell'UPS. In questo modo anche gli altri dispositivi possono chiudersi educatamente, invece di spegnersi senza sapere cosa è successo.

Configurazione locale (Ubuntu)

Prima di tutto dobbiamo modificare la configurazione locale, in modo da aggiungere un utente non locale (in modalità slave), e la disponibilità ad ascoltare sulla scheda/IP collegata alla rete locale qualunque indirizzo IP associato alla macchina (0.0.0.0). Ho corretto queste istruzioni perché ho scoperto che specificare gli indirizzi locali crea dei problemi all'avvio. Non solo, basta che non riesca ad avere la disponibilità di uno solo degli indirizzi IP, che NUT blocca l'avvio del servizio, e vi trovate scollegati dall'UPS senza sapere bene perché. (vedi bug riportato qui: https://github.com/networkupstools/nut/issues/723)

I file di configurazione si trovano in /etc/nut

$ sudo nano upsd.conf
LISTEN 127.0.0.1
LISTEN <my.IP.on.local.network> 
LISTEN 0.0.0.0 3493
$ sudo nano upsd.users 
[upsmonremote]
        password = remotepwd
        upsmon slave

 Vediamo alcuni casi specifici di collegamenti sulla rete locale.


Windows Server 2012R2 con NUT beta Windows binary

Ho scaricato Windows MSI installer 2.6.5-6 da https://networkupstools.org/download.html
 
Di default il programma si installa in C:\Program Files (x86)\NUT e configura un servizio locale.
 
Dal pannello dei servizi, avviare il servizio "Network UPS Tools".

Aprire Event Viewer e verificare i messaggi del servizio, nella sezione "Windows Logs\Application".

Da me si è arrestato con errore, vedi: https://github.com/networkupstools/nut/issues/262 
Come da istruzioni nel link, ho scaricato una versione 32bit di OpenSSL da: https://indy.fulgan.com/SSL/
e copiato libeay32.dll e ssleay32.dll nella directory .\sbin.
 
Riavviare e verificare ancora su Event Viewer.
 
I file di configurazione sono nella sottocartella .\etc
 
nut.conf:
MODE=netclient
 
upsmon.conf:
MONITOR backups@<my.IP.on.local.network> 1 upsmonremote remotepwd slave
SHUTDOWNCMD "C:\\WINDOWS\\system32\\shutdown.exe -s -t 0"
 
Riavviare e verificare.

Synology NAS

Il sistema DSM che gestisce i NAS della Synology è una variante di Linux, che sotto il cofano ha anche il modulo NUT. Per semplificarsi la vita e poter condividere un UPS tra diversi Synology, hanno predisposto un collegamento remoto al master NUT con i seguenti parametri.

UPS device name

ups

slave user name

monuser

slave password

secret

Sapendo questo, possiamo configurare il nostro master NUT con gli stessi parametri, modificando opportunamente i file upsd.conf e upsd.users. A questo punto sarà sufficiente fornire al DSM Synology l'indirizzo IP del master NUT e verificare che i due comunicano. 

Net-SNMP

Fonte: https://raymondjdouglas.com/blog/2018/ups-monitoring
$ sudo yum install net-snmp




18 gennaio 2021

Ubuntu 18: usare NUT per monitorare un UPS APC via USB

Ancora un lungo post dedicato ai sistemisti. Stavolta vi racconto cosa ho fatto per collegare un UPS ad un server Linux Ubuntu, in modo da fare una chiusura ordinata quando va via la corrente.

UPS APC

Abbiamo un UPS APC con interfaccia USB. 

Nel mio caso specifico un Back-UPS BR1500, con uno strano cavetto da RJ45 a USB.

Se non trovate il cavetto, potete costruirvelo o comprarlo su Amazon: non è un cavetto USB standard.

La serie Back-UPS arriva con una versione di software APC "PowerChute" adatta a Windows 10 Home. Ma nessuna delle macchine alimentate dall'UPS gira con Windows Home. Software archiviato.

Se fosse stata una macchina isolata, avremmo potuto installare il driver apcupsd, che non propone nativamente un sistema di propagazione dell'informazione.

Ma noi vorremmo che lo stato dell'UPS sia interrogabile sulla rete locale, in modo che tutti i dispositivi alimentati possano eseguire una chiusura programmata. Per questo motivo l'abbiamo collegato ad un server Ubuntu 18 e abbiamo scelto il software gratuito NUT.

NUT

Il progetto Network UPS Tools, o NUT, è poco manutenuto, ma è stabile da parecchi anni e ben documentato. Le istruzioni che seguono sono state ricavate da:

  1. la documentazione di NUT
  2. https://seuck.blogspot.com/2018/10/ups-monitor-via-usb.html (italiano, grazie Francesco Chirico!)
  3. https://blog.shadypixel.com/monitoring-a-ups-with-nut-on-debian-or-ubuntu-linux/ (inglese, da cui ha attinto il precedente)
  4. https://www.howtoforge.com/monitoring-ups-power-status-with-nut-on-opensuse10.3  (inglese)
  5. https://raymondjdouglas.com/blog/2018/ups-monitoring (in inglese)

La prima cosa da fare è verificare la compatibilità hardware del nostro UPS con i driver di NUT. In questa pagina sono elencati parecchi modelli di UPS e il driver relativo, che dovrete specificare in fase di configurazione.

Nel mio caso, ho trovato nell'elenco un generico modello APC Back-UPS USB che dice funzionare con il driver usbhid-ups.

Andiamo ad installare NUT.

$ sudo apt-get install nut

La directory con i file di configurazione è: /etc/nut

Se necessario, modificate i permesssi sui file. Nel mio caso non ho toccato niente, ma sono quasi tutti impostati con proprietario root e gruppo nut, come se avessi lanciato:

$ sudo chown root:nut /etc/nut/*

Andiamo a configurare NUT.

Se abbiamo paura di pasticciare i file, possiamo tenerci una copia di scorta di quelli di default:

$ sudo cp *.conf *.conf.bak

Il driver

Secondo questo blog, esiste un comando nut-scanner, che potrebbe aiutarvi a determinare il driver corretto. Questo può essere utile nel caso in cui avete già comprato l'UPS e volete fare degli esperimenti per vedere se riuscite a comunicare.

$ sudo nut-scanner -U

Per indicare quale driver usare e con che parametri, modifichiamo il file ups.conf

$ sudo nano ups.conf

creando una nuova sezione per il nostro ups:

 [backups]

    driver = usbhid-ups

    port = auto        # non serve

    desc = "Sant'UPS"    #proteggimi tu

Ho dovuto commentare (con #) l'ultima riga 

#maxretry = 3 

perche è un parametro non richiesto per USB.

Avviamo il driver e verifichiamo che riesca a parlare con l'UPS:

$ sudo upsdrvctl start

Se tutto è andato bene, dovrebbe risponderci qualcosa che assomiglia a:

Network UPS Tools - UPS driver controller 2.7.4
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
Using subdriver: APC HID 0.96

I servizi

Andiamo a configurare i servizi, upsd e upsmon. Come mai questa proliferazione di programmi?

upsd (aka Network Server) comunica con il driver UPS che abbiamo appena avviato, mentre upsmon (aka Monitor) comunica con upsd e lancia il comando di chiusura in base allo stato dell'UPS. Il motivo di questa divisione è che possiamo avere una macchina che comunica fisicamente con l'UPS, e più macchine alimentate dall'UPS che vogliono essere informate dello stato dell'UPS. Secondo lo stile *nix, ogni programma dovrebbe fare una sola cosa (e farla bene 😉)  

Sarà necessario indicare questa configurazione nel file nut.conf, che altrimenti non sa quali moduli serviranno, e quali file di configurazione devono essere consultati, con la parola chiave MODE.

Se questa è l'unica macchina interessata all'UPS, indicheremo MODE=standalone

Se è semplicemente una macchina che è interessata allo stato dell'UPS, indicheremo MODE=netclient. Se invece, come nel nostro caso, questa è la macchina collegata all'UPS e che racconta alle altre come sta andando, indicheremo

MODE=netserver

upsd

Possiamo avviare il daemon upsd senza modificare i file di configurazione, e vedere come va:

$ sudo systemctl start nut-server
$ sudo systemctl status nut-server

Se tutto va bene, dovrebbe dirci che il servizio è partito, parla con il driver dell'UPS e si è messo in ascolto sulla porta di default per rispondere alle domande degli interessati.

upsd[1816]: listening on 127.0.0.1 port 3493
upsd[1816]: Connected to UPS [backups]: usbhid-...
upsd[1816]: listening on ::1 port 3493
upsd[1816]: Connected to UPS [backups]: usbhid-...
upsd[1817]: Startup successful

Una informazione simile ve la può fornire la utility che analizza il traffico e le porte aperte sul sistema, una volta netstat, oggi ss 

$ sudo ss -tlp | grep ups

Questo comando dovrebbe elencarvi una serie di porte aperte in ascolto da upsd.

Se il servizio è partito correttamente, possiamo andare vedere che informazioni si scambiano UPS, driver e server, con il comando upsc:

$ upsc backups@localhost

che dovrebbe restituirci una carrellata di dati del tipo:

battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.runtime: 528
battery.voltage: 27.2
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Back-UPS .....
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.version: 2.7.4
driver.version.data: APC HID 0.96 ...

We have the power!

upsmon

Ora tocca al servizio di monitoraggio, upsmon. Se lo facciamo partire con la configurazione di default il servizio non partirà e ci segnalerà un errore perché nel file di default non sono indicati UPS da monitorare.

Andiamo ad elencare il nostro UPS nel file upsmon.conf, o meglio ad aggiungere il comando di monitoraggio:

$ sudo nano upsmon.conf

inserendo una nuova riga, come quelle negli esempi:

MONITOR backups@localhost 1 upslocaluser pwd master

In questo modo abbiamo detto al servizio di interrogare upsd per avere informazioni sull'UPS che abbiamo configurato localmente, e che avevamo chiamato backups, presentandoci come l'utente upslocaluser, password pwd, scelti da voi, secondo il vostro buon gusto.

Con 1 (uno) indichiamo che deve esserci come minimo 1 UPS (il nostro). Con master indichiamo che siamo quelli che ci spegneremo per ultimi, una volta avvisati gli altri. Infatti se ci spegnessimo prima, le altre macchine potrebbero perdere la possibilità di interrogare l'UPS, e non sapere che tra poco verranno stroncate.

In questo file si impostano parecchi altri parametri, ad esempio per la frequenza di interrogazione, i tempi di attesa prima di avviare la chiusura, e per la sicurezza della comunicazione. Sarà necessario configurarli un po' sperimentalmente, in base al carico sull'UPS, alla velocità di chiusura e al numero di altre macchine che dovranno comunicare.

upsd + upsmon

Ora però dobbiamo tornare a upsd, che purtroppo non sa nulla dell'utente che vuole interrogarlo.

Andiamo a modificare il file upsd.users, aggiungendo il nostro utente locale, ricordando anche qui che è l'utente di upsmon che si chiude per ultimo (master):

$ sudo nano upsd.users 
[upslocaluser]
        password = pwd
        upsmon master

A questo punto possiamo riavviare il server e avviare il monitor:

$ sudo systemctl restart nut-server
$ sudo systemctl start nut-monitor

Facendo una verifica del nostro progresso:  

$ sudo systemctl status nut-monitor

Se anche qui leggete "Startup successful" vuol dire che o avete fatto un buon lavoro, o semplicemente avete la fortuna del principiante!

Per assicurarci che i servizi ripartano ad ogni avvio, usiamo il comando "enable".

$ sudo systemctl enable nut-monitor.service

$ sudo systemctl enable nut-server.service

Client esterni

E per condividere queste informazioni con altre macchine alimentate dall'UPS?

Lo vedremo in un altro post, a seguire!

Aggiornamento:

Ecco il post promesso: 

https://striscialascia.blogspot.com/2021/01/monitorare-un-ups-sulla-rete-locale.html