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



 
 
 

11 dicembre 2020

Centos: la fine di un epoca

 CentOS, la distro di Linux che molti hanno usato per costruire i propri server, è agli sgoccioli, almeno nella forma in cui l'avevamo imparata a conoscere nell'ultima decina di anni.

Red Hat, l'azienda che dal 2014 sostiene l'iniziativa, e ha investito parecchio in quella che era a tutti gli effetti la versione gratuita di Red Had Enterprise Linux (RHEL), la versione aziendale e a pagamento, ha pubblicato una serie di annunci in cui spiega che il ruolo di Centos cambierà nel prossimo futuro.


 Invece di essere la versione Community e gratuita di RHEL, Centos diventerà il banco di prova per le modifiche a RHEL. In pratica una inversione di ruoli, con Centos nel ruolo di "beta" di RHEL, con il nome di "Centos Stream".

Per tutti quelli che la sceglievano per motivi di affidabilità e continuità, garantita dal "fratello maggiore", questo drastico cambio di rotta significa guardare altrove.

La mossa ha creato non poco scompiglio nella comunità degli estimatori, utilizzatori e contribuenti di questo sistema che una decina di anni fa era la versione di Linux più diffusa al mondo.

In particolare, il co-fondatore di Centos, Gregory Kurtzer, ha prontamente rilanciato la sfida, con un fork, dichiarando di voler avviare un nuovo progetto di Linux gratuito, che ha battezzato Rocky Linux, in onore di Rocky McGaugh, suo partner nell'avventura Centos.

Per voi che utilizzate CentOS 7, non c'è da preoccuparsi nell'immediato futuro: Red Hat ha dichiarato che non sono previste variazioni al calendario e la versione 7 verrà manutenuta ufficialmente almeno fino al 2024.

Fonti e riferimenti:

26 novembre 2020

Nagios e monitoraggio Windows

Un post veramente lungo, dedicato agli amministratori di rete. Da leggere solo in caso di bisogno!

Nagios è un complesso sistema di monitoraggio di risorse informatiche, cioè un programma che interroga o riceve messaggi sullo stato dei computer e dispositivi sulla rete e le aggrega in un unico posto.

La sola visualizzazione sarebbe utile, ma insufficiente. La vera forza dei sistemi di monitoraggio è quella di avvisare il responsabile di sistema di eventuali malfunzionamenti o stress dei dispositivi monitorati, cosa che normalmente avviene tramite email.

Chiaramente è meglio avere il sistema di monitoraggio su una macchina diversa da quelle che si vogliono controllare, perché, normalmente, non si guastano contemporaneamente. Inoltre sarà improbabile che il monitoraggio interferisca con altri processi produttivi, ma rimarrà un "osservatore esterno", distaccato e imparziale. 

Nagios è disponibile in versione a pagamento, denominata 'Nagios XI' e nella versione gratuita, 'Nagios Core', che è la versione di cui mi sto segnando alcuni appunti.

Premetto subito che, se installare Nagios Core non è complesso, questo non si può dire per la sua configurazione. Infatti, la semplicità di configurazione la potete avere in cambio della licenza della versione a pagamento.

Nagios è pensato per essere installato su Linux, ma, evidentemente, è attrezzato per dialogare via rete con svariati dispositivi, usando protocolli e linguaggi diversi.

Nel 2016 ...

Nel 2016 avevo installato Nagios Core su Centos7 per monitorare dei server Windows, utilizzando NSClient++, un 'agente' gratuito per Windows, che vorrebbe parlare con Nagios attraverso il protocollo NRPE (Nagios Remote Plugin Executor).   

Quattro anni dopo le cose sono abbastanza cambiate.

NSClient++ è ancora disponibile, ma l'ultima versione risale al 2018.

NRPE è sconsigliato o 'deprecated', e riceve solo aggiornamenti per la sicurezza. Nonostante questo troverete sul web diverse pagine recenti che vi guidano nell'installazione di NRPE e NSClient.

As of NRPE version 4.0.1, this project is deprecated.

Qual'è la strada attualmente consigliata per il monitoraggio di macchine Windows da Nagios Core?

Nel 2020

Dalle indicazioni di Nagios e dallo stato di sviluppo delle varie librerie su GitHub, ho capito che il sistema più aggiornato si chiama NCPA, o Nagios Cross-Platform Agent.

La documentazione Nagios è molto chiara:

NSClient++ is one of many agents that can be used to monitor Windows devices. [...] However, for ease of use and greater functionality, Nagios Enterprises recommends using a multi-platform agent called NCPA

Installando NCPA su Windows, Nagios ha due possibilità:

  1. interrogare direttamente le macchine in modalità 'attiva', 
  2. ricevere in maniera 'passiva', dei bollettini periodici, utilizzando il protocollo NRDP, o Nagios Remote Data Processor.

Vediamo un po' in dettaglio alcuni passaggi e collegamenti a pagine web con istruzioni o specifiche dettagliate.

Lato Nagios: installazione Nagios

E' tutto abbastanza regolare, la cosa importante è seguire una guida specifica per la salsa e revisone di Linux che avete scelto. Molti scelgono Centos o Debian, nel mio caso ho usato Ubuntu 18 LTS.
 
Vedi:
Dopo Nagios è necessario installare i suoi plugin.
Vedi:   

Lato Windows: installazione NCPA

Nulla di più semplice. Scaricate l'ultimo installer e seguite il 'wizard'. 
Segnatevi la chiave di sicurezza (il 'token') che avete scelto per far comunicare le due parti, dovrete usarla nella configurazione di Nagios.

Lato Nagios: installazione client/plugin NCPA

Dovrete aggiungere a Nagios il plugin o client, in python, per parlare in NCPA.  
Si chiama 'check_ncpa.py' e si scarica a parte.
 
Dopo l'installazione, verificate il funzionamento del plugin:
  1. portatevi nella cartella del plugin
  2. eseguite:
    ./check_ncpa.py -H <indirizzo server> -t <mytoken> -M 'system/agent_version' 
    Se funziona potete chiedere a NCPA l'elenco di tutte le voci che può inviare:
  3. ./check_ncpa.py -H <indirizzo server> -t mytoken --list

Lato Windows: configurazione NCPA attivo

Istruzioni per la configurazione di NCPA attivo: i default dovrebbero andare bene nella maggior parte dei casi. Segnatevi la chiave di sicurezza (API token) che vi servirà nella configurazione di Nagios.

Ricordatevi di riavviare i servizi NCPA a conclusione delle modifiche dei file di configurazione

Lato Nagios: configurazione Nagios + NCPA

Qui cominciano i dolori. Dovete armarvi di pazienza, e imparare a muovervi tra i file e le cartelle di Nagios. Dovete imparare cosa sono i 'template' o modelli, che vi faranno risparmiare un po' di ripetizioni (voce 'use' dei file di configurazione).

I passaggi, a grandi linee, sono:

  1. Configurazione generale di Nagios. File nagios.cfg. Abilitare il monitoraggio Windows.
  2. Configurazione dei comandi, in objects/commands.cfg. Aggiunta del comando ncpa
  3. Configurazione dei server (host) e delle voci di monitoraggio (services) per ciascun server. File objects/windows.cfg

Se tutto va bene, ad un certo punto, nella schermata di Nagios dovreste vedere delle bellissime righe verdi in corrispondenza del vostro host e relativi servizi, magari con delle informazioni realistiche sull'occupazione disco e carico CPU.


In bocca al lupo!  

ISS control center

Lato Nagios: installazione NRDP

Se volete il monitoraggio passivo, dovrete scaricare anche il plugin per NRDP. Si scarica e si installa a parte. 
 
Sorgenti e istruzioni di installazione: https://github.com/NagiosEnterprises/nrdp
 
Segnatevi la chiave di sicurezza (token) utilizzata. Vi servirà per la configurazione in Windows.

Verificate che la pagina web di NRDP sia attiva, e che il token sia corretto.

Lato Windows: configurazione NRDP passivo

  • Istruzioni per la configurazione dei controlli passivi (in inglese). 
    • Cartella /etc
    • Troverete un file preconfigurato e uno di esempio.
    • Importante: impostare l'URL di destinazione dei messaggi (server Nagios/nrpd)
    • vedi (in inglese) https://www.nagios.org/ncpa/help/2.2/passive.html 
    • Riavviate i servizi NCPA a conclusione delle modifiche dei file di configurazione 


Lato Nagios: configurazione NRDP passivo

Se è andato tutto bene finora,  i messaggi di Windows dovrebbero arrivare a Nagios. Ma Nagios non sa cosa farsene.
Per verificare, controllate il log di Nagios per vedere se segnala i messaggi di provenienza ignota:

grep 'Error: Got' /usr/local/nagios/var/nagios.log 
 
Se trovate le segnalazioni, siamo a cavallo.
Per far 'digerire' questi messaggi, dobbiamo aggiungere alla configurazione di Nagios:

Riferimenti 

Sorgenti ed eseguibili per Nagios:
Sorgenti ed eseguibili di NCPA. Alla data del post, la versione era la 2.2.2 di giugno 2020.
Descrizione del plugin NCPA per i controlli in modalità attiva, in particolare per Windows:
Spiegazione complessiva dell'utilizzo di NCPA in modalità passiva:
Traccia dettagliata di alcune operazioni di configurazione descritte sopra:

Per coloro che vogliono assolutamente continuare ad usare NSClient++, la documentazione:

09 novembre 2020

WikiData e Label

WikiData è il database RDF che ormai da qualche anno agisce come deposito per i dati "universali" di Wikipedia. 

Ad esempio, è ragionevole che ci sia una unica fonte interna che fornisca il dato sulla popolazione di Parigi, invece di affidarsi alle capacità dei volenterosi volontari che dovrebbero riportarla come numero in cento traduzioni diverse dell'articolo sulla capitale della Francia.

Recentemente mi sono avvicinato a questo mondo, e ho provato a creare qualche domanda o 'query' come si dice in gergo. Per questo c'è uno spazio apposito, chiamato Wikidata Query Service.

Sono rimasto affascinato dalle potenzialità di questo sistema e in generale dal paradigma RDF, ma mi hanno sorpreso subito alcune stranezze, che mi segno qui per motivi di cronaca.

Se voglio sapere quante città si chiamano 'Pavia' nel mondo (nel mondo Wikidata, inteso), devo cercare l'etichetta (o 'label') 'Pavia'. Questo non è intuitivo come si potrebbe pensare.

Query trovata su StackOverflow, in risposta alla domanda di un utente perplesso:

SELECT distinct ?item ?itemLabel ?itemDescription
WHERE{  
  ?item ?label "Pavia"@en.  
  ?article schema:about ?item .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }    
}

 Ma cos'è 

SERVICE wikibase:label 

? Mistero. Nel tutorial di SPARQL per WikiData, ci viene spiegato che si tratta di una 'magia'.

Senza questa magia, bisogna scrivere:

SELECT DISTINCT ?item
WHERE
{
  ?item  wdt:P31/wdt:P279* wd:Q486972 .
  ?item rdfs:label "Pavia"@en .
}

... dove

wdt:P31/wdt:P279* wd:Q486972

significa: un "insediamento umano" o sua sottoclasse più specializzata.

Non sono l'unico che si chiede in cosa consista la 'magia' dei label, come potete leggere in quest'altra domanda su StackOverflow

A quanto pare si tratta di una questione di ottimizzazioni e di efficienza.

Se troverò risposte, sarete i primi a saperlo ...



29 ottobre 2020

VPN Wireguard

 A volte anche per gli informatici è difficile stare al passo con l'evoluzione tecnologica. Ma quando una novità, che non è una novità, inizia a diventare diffusa e dirompente, non può passare inosservata.

Oggi vi segnalo WireGuard, che sta diventando lo standard per le Reti Virtuali Private o VPN.

Qui trovate una descrizione su Wikipedia, e qui il sito ufficiale.

Una VPN serve per creare un canale di comunicazione protetto tra il nostro PC e un server su Internet. In questi tempi di smartworking, di furti e ricatti informatici e importanza della privacy, la VPN diventa uno strumento indispensabile per accedere a dati e informazioni che non vogliamo condividere con il mondo intero.

Alla ricerca di una soluzione che sostituisse la vecchia VPN aziendale, ho scoperto Wireguard, un progetto nato nel 2016, ma che ha cominciato a diffondersi seriamente a partire dal 2018.


Logo of WireGuard

Il solo dato della quantità ridotta di codice scritto, mi è bastato per capire che si tratta di un progetto veramente innovativo e moderno. A detta del creatore, Jason A. Donenfeld, Wireguard contiene circa 4mila righe di codice, contro le 400mila e passa del suo predecessore Open Source più diffuso, cioè OpenVPN.

La sua disponibilità su tutti i sistemi operativi più diffusi, Windows, Linux, MacOS, IOS e Android, mi ha ulteriormente convinto che si trattasse di una valida alternativa.

Il tempo materiale per installare un server e un paio di client per le prove, cioè meno di un'ora, hanno sancito il suo ingresso definitivo nell'arsenale degli strumenti informatici personali e aziendali che raccomanderei a tutti.

Quasi dimenticavo: il server di prova gira su un Raspberry!

Markdown e Wiki

 Questo blog vive su Internet, e quindi per voi lettori è una pagina web, scritta in HTML, dove la M sta per Markup, ossia la sintassi che serve per abbellire il testo, creare i collegamenti (la H di HyperText) e identificare i componenti di una pagina web.

La sintassi complessa e lunga da digitare a manina fa in modo che spesso le pagine in HTML, come in questo blog, vengano composte con altri sistemi, e non digitando esplicitamente le etichette HTML, come in <h3>sottotitolo</h3> o <b>grassetto</b>.

Per questo motivo, un certo John Gruber ha proposto un sistema per formattare o abbellire il testo che potesse essere digitato mentre si scrive. Si chiama markdown, dove il 'down' indica la semplificazione verso il basso, rispetto al markup.

 

Con il markdown, ad esempio, il grassetto si indica con degli *asterischi*, il corsivo con delle barre diagonali //, e i titoli con degli uguale === sottotitolo === , con dei !!! punti esclamativi o dei cancelletti, in base alla variante utilizzata.

L'idea è sembrata geniale, tanto che il markdown viene usato dappertutto su internet: nei forum, nei wiki, nei siti di domande e risposte.

Purtroppo Gruber non si è cimentato in una standardizzazione delle sue proposte, che erano un po' ambigue per alcuni versi, e mancavano della ricchezza espressiva richiesta in molti documenti.

Per questo motivo, il markdown non è uno standard, e le varianti si sprecano, spesso incompatibili fra loro. Vi sono diversi candidati per uno standard, o per volume di adozione (standard de facto) o per ricerca di consenso. Ad esempio, su StackOverflow, recentemente si è deciso di passare al CommonMark. Su GithHub regna sovrano il markdown di GitHub, comunemente descritto come GitHub Flavoured Markdown, o 'gh'. Wikipedia ha la sua variante, usata da milioni di Wikipediani.

Oggi ho scoperto una nuova salsa o implementazione che vi segnalo, che a sua volta viene utilizzata per creare dei Wiki su GitHub.

Si chiama Discount, è scritta nel linguaggio C, e trovate qui il sito e la documentazione.

Qui un wiki realizzato con Discount, Make e GitHub: la documentazione del progetto musl.

18 ottobre 2020

Lo ricomprerei: copriwater IKEA anni 2000

Dopo almeno 15 anni di onorato servizio ha ceduto uno dei nostri oggetti IKEA più usati in assoluto: il copriwater!

E' stato l'asse più longevo di sempre, a mio avviso, soprattutto per le cerniere in plastica, a prova di qualunque prodotto corrosivo usato da chi l'ha amorevolmente pulito in questi anni.

Tutti gli altri si sono corrosi e rotti proprio sulle cerniere, solitamente in acciaio cromato. Alcuni dopo pochi mesi di utilizzo. Anche in questo caso si sono rotte le cerniere, ma per stress meccanico. Non voglio indagare sulle cause. 😕


E' uno dei pochi copriwater sganciabili che abbia mai visto (non che sia un esperto del settore 😄), quindi semplice da pulire a fondo. Grazie ad un attento design proprio delle cerniere, ha una parte che rimane attaccata alla tazza e l'asse che si stacca, semplicemente sollevandolo dal verticale. 

E' un prodotto sicuramente "over-engineered" come dicono in inglese. Con questo termine si indica un prodotto in cui i progettisti hanno aggiunto funzionalità e complicazioni che non hanno fondate giustificazioni commerciali. Non riesco ad immaginare le ore di progettazione e di industrializzazione del prodotto, gli stampi per la plastica e i test impiegati dalla casa svedese per assicurarsi la perfetta funzionalità dell'assemblaggio e del prodotto finale.

Sarà per questo motivo, o per altri a me sconosciuti, IKEA non lo produce più e la nuova linea ha le cerniere in metallo come tutte le altre marche.

Intanto che cerco un degno sostituto, ho provveduto alla riparazione, ricostruendo delle cerniere in legno. Non è stato semplice, ma con un po' di manodopera e di aiuto da parte della tribù, ci sono riuscito. 

Se siete curiosi, potete vedere i particolari in questa galleria di immagini.

-----

Note a posteriori: esistono aziende che fanno copriwater sganciabili e con cerniere non metalliche. Peccato che abbia trovato per ora solo produttori USA, con misure incompatibili (interasse fori USA 5''1/2 o 14cm, ITA 16cm). Vedi ad esempio: