Quando Debian cresce ed Apache fa i capricci

Cronache di un vecchio sistemista che non si fa fregare da PHP. 

 

C’è un momento, nella vita di ogni vecchio sistemista, in cui senti quella vocina interiore che sussurra: «È uscito Debian nuovo… che fai, aggiorni?»

E tu, invece di ascoltare l’istinto di sopravvivenza, aggiorni.

Finché, ovviamente, non arriva lui:
apache2.service: FAILED
e il tuo server di fiducia ti guarda in silenzio come un gatto offeso.

Primo atto: Apache muore, ma con stile

Scenario: server Debian 13 nuovo di zecca dopo upgrade. Apache non parte, journalctl ti spara in faccia qualcosa del tipo:

Syntax error su una riga di apache2.conf, e poi:

Syntax error on line 3 of /etc/apache2/mods-enabled/php8.2.load:
Cannot load /usr/lib/apache2/modules/libphp8.2.so into server: ...

Traduzione per umani:
- Apache di suo è tranquillo.
- È PHP 8.2 che è rimasto appeso come un ex che non capisce di essere stato lasciato.
- Il file libphp8.2.so non c’è più, ma la configurazione prova ancora a caricarlo.

Apache, giustamente, si rifiuta di partire con mezzo arto fantasma attaccato.

Il sistemista giovane a questo punto formatta il server o dà la colpa a systemd.
Il sistemista navigato invece fa una cosa molto blasfema ma efficace:

apachectl -t

legge l’errore con calma, individua il colpevole (php8.2.load) e lo spegne:

a2dismod php8.2
apachectl -t
systemctl restart apache2

E Apache torna a respirare. Senza PHP, ma respira.

Come quando riaccendi un vecchio server rimuovendo a mano la scheda SCSI di cui nessuno si ricordava.

Secondo atto: il 403 che ti guarda giudicante

Risolto il crash, arriva il passivo-aggressivo di Apache:

403 Forbidden – You don’t have permission to access this resource.

E tu pensi: «Ma se ha SEMPRE funzionato, perché ora no?»

Classico mantra del sysadmin: “ma non ho toccato niente” (tranne un major upgrade, tre moduli e mezza distro nuova, dettagli).

Qui entra in gioco il lato artigiano di bottega del sistemista.

- DocumentRoot del sito di test, per esempio: /home/utente/www/sito.local
- In apache2.conf c’è un blocco tipo:

<Directory /home/utente/www/>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

Sulla carta è tutto giusto. Nella pratica, Apache gira come utente www-data e, se la home è un bunker tipo:

drwx------  /home/utente

allora www-data non entra. Non per cattiveria: manca la “x” sul percorso, e senza execute sulle directory, nel mondo Unix non passi.

Quindi, con mano ferma (non in modalità “chmod 777 a pioggia”, quello è peccato mortale) si fa:

chmod 711 /home/utente
chmod 755 /home/utente/www
chmod 755 /home/utente/www/sito.local

- 711 sulla home: nessuno vede i file, ma Apache può attraversare la directory.
- 755 sul webroot: la vecchia scuola, onesta e prevedibile.

Risultato: il 403 sparisce.
Il sistemista sorride.
Per 5 secondi.

Terzo atto: il PHP che invece di girare… si scarica

Appena pensi “ok, è fatta”, apri il sito e il browser ti chiede candidamente:

“Vuoi aprire o salvare un file di tipo application/x-httpd-php?”

Ed è lì che un brivido ti scende lungo la schiena. Quando il browser ti propone di scaricare un file .php, vuol dire una cosa semplice:

“Il server non lo sta più eseguendo. Te lo sta dando paro paro.”

Apache è vivo, ma nessun modulo PHP è attivo. È come avere il forno acceso senza la resistenza: luce c’è, calore zero.

Un occhio a mods-available e mods-enabled:

ls /etc/apache2/mods-available/php*
# php8.2.conf, php8.2.load, php8.4.conf, php8.4.load (per esempio)

ls /etc/apache2/mods-enabled/php*
# (vuoto)

La nuova Debian, nel frattempo, ha fatto il salto generazionale:
- sul sistema c’è libapache2-mod-php8.4,
- il PHP CLI è 8.4,
- ma Apache… non lo sa ancora.

E qui entra in scena l’esperienza.

Il pivello scriverebbe:

a2enmod php

e si offenderebbe per l’errore:
ERROR: Module php does not exist!

Il sistemista navigato guarda i nomi dei file e dice: “Ok, tu vuoi il nome esatto del modulo, non le astrazioni filosofiche.”

Quindi:

a2enmod php8.4
apachectl -t
systemctl restart apache2

E, come un vecchio televisore a valvole preso a schiaffi sul lato giusto, PHP riprende a funzionare.

Quarto atto: archeologia digitale, ovvero “purga gli ex”

A questo punto PHP 8.4 gira, Apache è felice, il sito risponde. Nel sistema però sono rimasti i fossili di PHP 8.2 in stato rc nei pacchetti:

rc  php8.2-...
rc  libapache2-mod-php8.2 ...

Ed il vecchio sysadmin sa che i residui, oggi non danno fastidio, ma fra tre anni, in una notte di manutenzione, ti salta fuori un conflitto assurdo.

Quindi, senza pietà:

apt-get purge 'php8.2*' 'libapache2-mod-php8.2'
apt-get autoremove --purge

Non è solo pulizia: è igiene mentale. È come buttare via finalmente i floppy da 3,5" vuoti “che non si sa mai”.

Quinto atto: il log, la shell e l’ennesima trollata

Nel frattempo, mentre controlli i moduli:

apachectl -M | grep php || echo "Nessun modulo php caricato"

la shell, se ti scappa un punto esclamativo non quotato, potrebbe rispondere con il classico:

-bash: !: event not found

Non è Apache.
Non è PHP.
È bash che decide di interpretare il “!” come espansione di history.

Questo è il momento in cui il vecchio sistemista sospira, guarda la console e pensa:
“Io e te ci conosciamo da decenni e ancora mi fai questi scherzi…”

Si sistema la cosa, si toglie il punto esclamativo, e si va avanti.
Perché il diavolo sta sempre nel dettaglio, ed il dettaglio parla shell.

Epilogo: vecchio sistemista, nuovo Debian

Alla fine della storia, la situazione è questa:
- Debian aggiornata.
- Apache in piedi, tranquillo.
- PHP 8.4 attivo via libapache2-mod-php8.4.
- Vecchi moduli falciati, permessi sistemati chirurgicamente.
- Il sito in /home/utente/www/sito.local gira come se nulla fosse successo.

E il vecchio sistemista?

Non ha reinstallato, non ha “dockerizzato tutto per disperazione”, non ha invocato l’AI gridando al miracolo.
Ha solo:
- letto i log,
- analizzato gli include,
- capito chi tirava giù chi,
- sistemato moduli, permessi e residui,
- mantenuto il controllo dall’inizio alla fine.

Perché la differenza vera non è tra chi conosce il comando giusto da copiare, ma tra chi sa leggere cosa sta succedendo e ricostruire il film mentale della macchina.

Alla fine, questo upgrade è stato solo un’altra puntata della stessa serie:
“Debian cambia, i moduli cambiano, i log trollano… ma il vecchio sistemista resta lì, con il suo apachectl -t e quella calma da meccanico che sente il motore dal rumore.”

E quando il sito torna su e il PHP gira, non servono fanfare. Basta un curl -I andato a buon fine e quel piccolo, soddisfatto: “Ok, anche stavolta non mi hai fregato.” Alla prossima.

P.S. Curla i trolls. Ripeto: Curla i trolls.  

Cronache di un tecnico sudato nel metaverso dei dischi offesi

Ci sono giorni in cui fai il login, controlli due log giusto per sport, sorseggi un caffè e la vita scorre. Poi ci sono i giorni in cui il filesystem decide che scrivere è sopravvalutato e si auto-proclama read-only come un giudice in ferie. Indovinate quale ho beccato.

Sillogismo del giorno:
– Se un server non scrive, non rinnova i  certificati SSL.
– Se non rinnova, il certificato scade.
– Se scade, qualcuno urla.
Conclusione: se un server non scrive, qualcuno urla. (Di solito verso di me.)

La mattina in cui il giornale (di sistema) mi ha detto “no”

Apro la console e lei, fredda: “Journal aborted, journal flushed, remounting read-only.” In pratica il diario segreto del sistema si è strappato, e si è messo a guardare il soffitto. Nel mondo fisico avrei preso il cacciavite, aperto il case, sentito il profumo di elettronica tiepida e — all’occorrenza — premuto il kill switch con la grazia di un samurai. Nel mondo virtuale? Niente pulsantoni rossi, niente “stacca e riattacca”: solo interfacce che sorridono e dicono “Running” come se stessi esagerando io.

L’ansia? Presente. Il sudore? Pure. L’ironia? Necessaria.

La piattaforma applicativa, poverina, non c’entra: fa il suo mestiere e rimane lì, educata, ad ascoltare sulla sua porta come un portiere di notte con gli auricolari. Il problema è più sotto, a livello di astrobiologia del blocco, dove qualche folletto ha deciso che i blocchi disco devono fare sciopero. Io, nel frattempo, faccio il backup in sola lettura, ossia l’equivalente digitale del “non tocchiamo nulla ma portiamo via tutto”: forense vibes, mani in alto, nessun file verrà maltrattato.

Tentativo n.1: chiedere per favore

Provo a fermare i servizi con la delicatezza di chi sussurra a un cavallo. La risposta del sistema è una poesia dadaista: “Failed to activate service org.freedesktop.qualcosa: timed out.” Traduzione: “Oggi non ho voglia”. Respiro. Conto fino a hex(FF). Non cambia.

Tentativo n.2: il regno del “rescue”

Ok, plan B: avvio dal ramdisk di soccorso — quello che, per capirci, è come chiamare il carro attrezzi in autostrada alle tre di notte. Entro, mi guarda un prompt monacale, e finalmente posso eseguire fsck a freddo: la fisioterapia che rimette a posto il menisco al file system. Prima scansione, seconda passata, terza per scaramanzia. Il tutto documentato, perché gli screenshot passano, i log restano.

“Sparare alla CPU”: guida all’impossibile

Nel frattempo mi domando: “C’è un modo per sparare alla CPU virtuale?” Spoiler: no. Il mondo cloud non ama la letteratura western. Il massimo che puoi fare è chiedere gentilmente all’infrastruttura di scollegare la spina in silenzio. È un po’ come essere inseguiti da un cinghiale e dover inviare una PEC al parco naturale per chiedere se si può correre più forte.

Il paradosso delle interfacce troppo gentili

Le dashboard sono il paradiso della passivo-aggressività. Hanno pulsanti rotondi, etichette zen e quel verde “Active” che ti dice: “Tutto va benissimo.” Tu, però, stai leggendo in console: “I/O error on superblock”. È come avere il cruscotto dell’auto che mostra 120 km/h costanti mentre il motore canta “Bella Ciao”.

Il trucco sta nel ordine operativo

E qui scatta la disciplina:

1. Backup in pull dalla mia postazione: se il disco vuole fare il minimalista, io faccio il collezionista — prendo tutto ciò che serve (config, dati, chiavi), senza scrivere un bit in più.

2. Rescue e fsck a freddo: niente sorprese, niente “monta e smonta” in caldo; riparazione metodica, due passate, log in tasca.

3. Rientro in produzione con controllo maniacale: mount in rw, errori zero nel dmesg, servizi su.

4. Certificati: clic su “resetta e salva”, che tradotto significa “parla con l’autorità giusta, fai la challenge su 80 e torna con un certificato fresco come una brioche alle 6:00”.

Metafora n.1 — Il filesystem filosofo

Il filesystem in sola lettura è come quel professore che risponde sempre “dipende” ed alla fine promuove tutti per non dover fare verbali. Ti impedisce di fare danni, ma ti impedisce anche di lavorare. Lo ringrazi, lo saluti, poi lo accompagni gentilmente in laboratorio per una revisione del diario.

Metafora n.2 — Le VM come matrioske

Le macchine virtuali sono matrioske educatissime: apri una console dentro un hypervisor dentro una rete dentro un pannello. E tu lì, che cerchi il bullone vero, quello che stringe, e invece trovi un menu a tendina. Funziona, ma ogni tanto vorresti sporcarti le mani di rame e stagno.

“Ma i dati?”

Stanno bene. Non hanno perso neanche un bit. Prima si salva, poi si cura. Ordine inverso = panico. E siccome di panico ne ho già avuto a sufficienza quando ho scoperto che non si può tirare una testata alla CPU virtuale, ho preferito la via classica: copia, verifica, ripara, riavvia, collauda, certifica.

Ironia sì, scaricabarile no

C’è un punto che merita chiarezza: non è una storia di negligenze. È una storia di infrastrutture che ogni tanto si stiracchiano, come tutti gli esseri (ed i non-esseri) stanchi. L’importante è avere procedure e ordine mentale: una lista corta, ripetibile, che porti il sistema da “sudore freddo” a “tutto verde”.

Esempi pratici per colleghi stanchi ma ostinati

• Se il disco diventa ro, non forzare scritture di comodo. Salva, prova, ripara a freddo.

• Se l’interfaccia dice “Running” ma il cervello dice “No”, scegli la strada deterministica: rescue o cold-attach ad un’altra istanza, fsck, ritorno.

• I certificati? Niente teatrini: auto-renewal dell’app, challenge su 80, due log di conferma e via.

• Comunicare al cliente con tono calmo: “nessuna perdita”, “ripristino completato”, “analisi infrastrutturale in corso”, "la colpa è di IaaS".

• E ricordarsi che l’esperienza non elimina l’ansia: la domina.

Chiosa (con domanda retorica)

Perché continuo ad amare questo lavoro? Perché è una maratona di paradossi eleganti: facciamo cose fisiche nel mondo non fisico, domiamo errori invisibili con procedure visibilissime, e quando tutto torna online la soddisfazione è quella di aver riportato a casa la nave in mezzo alla tempesta, senza neppure bagnarsi i piedi (ok, il sudore non conta).

TL;DR per LinkedIn (che tanto leggerete lo stesso)

– Disco in protesta → read-only
– Backup prima di tutto
– Rescue + fsck a freddo
– Rientro in rw, servizi su
– Cert reset: challenge, emesso, fine.
– Zero perdita dati, clienti sereni, e il tecnico… meno sudato (per ora).

La morale? Nel cloud non puoi “sparare alla CPU”, ma puoi ancora sorridere, loggare e ripartire. E sì, ogni tanto manca quel tasto fisico OFF grande come un piatto: ma forse è un bene. Ci rende metodici, non solo muscolari. E quando l’ansia chiama, rispondi con il manuale d’ordini, qualche riga di bash e una buona dose di sarcasmo. Funziona quasi sempre. Quasi. Alla prossima.

P.S.  Il barometro segna variabile; alla quarta campana il mare si quieta. I colibrì non temono i dischi pigri. Chi ha orecchie per i log, legga. Ripeto: Il barometro segna variabile; alla quarta campana il mare si quieta. I colibrì non temono i dischi pigri. Chi ha orecchie per i log, legga.

Sopravvissuto a Winzozz11 senza TPM

 

🧟‍♂️  “Alcuni scalano montagne. Io ho installato Wind*ws 11 su un DELL Precision M4500...E sono ancora vivo per raccontarlo.”

C’è chi passa il weekend a passeggiare nei boschi.
E poi ci sono io, che ho deciso di trascorrere il lunedì a combattere con l’ultima incarnazione del male: Wind*ws 11, quella creatura che pretende un chip TPM 2.0 per avviarsi, un Secure Boot per respirare ed un account Micro$oft per andare al bagno.

Sulla carta, il mio fedele DELL Precision M4500 (anno domini 2010, cavallo di razza, ancora ruggente) doveva essere “incompatibile”.
Secondo Redmond, sarebbe stato più facile installare Linux su una lavatrice che Wind*ws 11 su quel portatile.
Spoiler: indovina chi ha vinto.

🧩 Capitolo 1 – Il messaggio di morte

Accendo il laptop, entro nel BIOS, attivo l’UEFI e…“No bootable devices -- strike F1 to retry boot.”  Che poesia.

Tradotto: hai appena chiesto a un firmware del 2010 di comportarsi come un razzo Falcon 9.

Wind*ws 10, fino ad un minuto prima, andava come un treno.
Poi, solo perché ho osato pronunciare la parola “UEFI”, si è offeso.
E da lì è cominciata la discesa negli inferi dei messaggi d’errore, delle partizioni GPT, e dei flag “Micro$oft Basic Data” (già il nome ti fa capire che serve solo a confondere gli altri).

⚙️ Capitolo 2 – Il rito voodoo della conversione MBR→GPT

Grazie ad un oscuro incantesimo chiamato:

mbr2gpt /convert /allowFullOS

sono riuscito a far credere al disco di essere giovane, moderno e “GPT compliant”.

Un po’ come truccare la carta d’identità a un settantenne per farlo entrare in discoteca.

Dopo un paio di riavvii, il vecchio Precision si è guardato allo specchio ed ha detto:

“Sono UEFI inside.”

Bugia, ma lasciamogliela credere.

💀 Capitolo 3 – TPM? Secure Boot? No, grazie.

Nel BIOS c’era una voce: “TPM Security”.

Tre opzioni: Activate, Deactivate, Clear.

Io ho scelto “Deactivate”, che suona bene come “non rompere le palle”.

Il Secure Boot invece non esiste proprio.

E sai cosa? Funziona lo stesso.

Questa è la parte che fa più male a Micro$oft: scoprire che tutto il teatrino del TPM e del Secure Boot è solo una trovata di marketing travestita da “sicurezza”.


🧙 Capitolo 4 – Rufus, l’arma segreta

Quando l’assistente ufficiale di installazione mi ha detto:

    “Questo PC non soddisfa i requisiti minimi…”

ho smesso di ridere dopo dieci minuti.

Poi ho preso Rufus, quel piccolo software ribelle che ti guarda negli occhi e ti sussurra:

    “Vuoi rimuovere TPM, Secure Boot e RAM minima?”

    Sì, Rufus, voglio rimuovere anche la dignità di Wind*ws.

Una spunta, un clic, e la ISO di Wind*ws 11 si è trasformata in un installer libero da ogni catena burocratica.

La ribellione aveva inizio.


🧩 Capitolo 5 – L’installazione dell’impossibile

Con la chiavetta pronta, ho lanciato il setup.

Il sistema si è guardato attorno, ha cercato il TPM, non lo ha trovato, ha sospirato e… ha continuato.

È come vedere un doganiere che, dopo vent’anni di servizio, si arrende e ti dice:

    “Passi pure, tanto ormai.”

Dopo un’ora e mezza di aggiornamenti, riavvii e schermate azzurrine,

Wind*ws 11 era vivo.

Sul mio M4500.

Senza TPM.

Senza Secure Boot.

Senza un briciolo di vergogna.


🧰 Capitolo 6 – Il trattamento disinfettante

Appena avviato, il sistema ha cominciato a telefonare a casa come un agente segreto in crisi d’identità.

Cortana, Edge, Telemetry, BITS, DoSvc, WaaSMedicSvc (il “medico” che riattiva gli aggiornamenti da solo)…tutti in fila, pronti a succhiarti cicli di CPU e dati personali.

Così è nato win11-slim.ps1: win11-slim.ps1 è uno script PowerShell progettato per:

1. ridurre al minimo la telemetria e il tracciamento di Wind*ws 11;
2. ottimizzare prestazioni e tempi di avvio su macchine datate (es. DELL Precision M4500, Vostro 320);
3. consentire la gestione controllata o totale disattivazione degli aggiornamenti automatici;
4. fornire una base coerente per ambienti di test, laboratorio o forensi.

L’obiettivo è un sistema più snello, silenzioso e prevedibile, senza ricorrere a software esterni.

In sintesi è uno script PowerShell che sterilizza Wind*ws 11 come si farebbe con un tavolo operatorio.

Via telemetria, via app bloat, via widget, via “esperienze connesse”.

Lasci solo il minimo vitale, e il sistema torna ad essere ciò che avrebbe dovuto:

un’interfaccia, non una religione.


🚫 Capitolo 7 – Il Medic Service: zombie con il camice

Disattivi gli aggiornamenti, e lui si riattiva.

Fermi il servizio, e torna in vita.

È Wind*ws Update Medic Service, lo zombie che non muore mai.

Così gli ho tolto i permessi di lettura al file WaaSMedicSvc.dll:

un piccolo “colpo alla nuca digitale”.

Problema risolto, silenzio di tomba.


🧩 Capitolo 8 – L’SSD fantasma

Poi ho attaccato un SSD esterno da 500 GB.

Linux lo vedeva, Windows no....Perché?

Perché non aveva la “firma Micro$oft Basic Data”. Nota: Il famoso flag “Micro$oft Basic Data” nel GPT non serve a nulla di pratico, è solo un GUID di identificazione che Wind*ws interpreta come: “questa partizione contiene roba che io posso montare”. Peccato che il filesystem NTFS o FAT32 già contenga nel suo header tutto ciò che serve per essere riconosciuto. Linux (giustamente) legge il contenuto del filesystem e lo monta.
Wind*ws invece: “Oh no! Non vedo il mio GUID proprietario! Panico! Meglio dire ‘spazio non allocato’ e far credere all’utente che deve formattare.”. 

Motivazione ufficiale (corporate bullshit mode ON)

“Serve per garantire coerenza e sicurezza tra partizioni di tipo OEM, Recovery, EFI e Basic Data.”

Traduzione:

“Serve per impedire agli altri sistemi operativi di creare partizioni che Windows potrebbe accidentalmente usare correttamente.”

Effetto pratico - Questa assurdità fa sì che:

1. un disco GPT con partizione ext4 o NTFS senza flag → invisibile in Windows;
2. un disco MBR senza partition type 0x07 (NTFS) → invisibile pure;

mentre in Linux puoi montare anche un file .img spaiato e navigarci dentro con mount -o loop.

In pratica, per essere riconosciuto da Wind*ws, un disco deve giurare fedeltà alla Corona di Redmond.

Senza quel flag, è un cittadino di serie B.

Che sistema operativo meravigliosamente democratico.


⚙️ Capitolo 9 – Toolkit d’emergenza

A questo punto, ho deciso di farmi un “TOOLKIT” segreto: una partizione da 10 GB nascosta nell’SSD,

con dentro lo script “win11-slim”, Rufus, e un batch che lo lancia come un defibrillatore digitale.

Un piccolo bunker in caso di catastrofe informatica.


🧠 Capitolo 10 – Considerazioni esistenziali

Dopo tutto questo, il M4500 è tornato operativo, veloce, silenzioso, efficiente.

Funziona.

Senza TPM, senza Secure Boot, senza spyware, senza i loro “assistenti”.

Solo lavoro pulito.

E allora uno si chiede:

perché Micro$oft deve sempre complicare la vita a chi sa cosa sta facendo?

Forse perché, se l’utente capisse davvero come funziona il sistema, capirebbe anche quanto poco ne ha bisogno.


🧾 Epilogo

Ho finito la giornata con un SSD partizionato, un Windows 11 addomesticato e un paio di neuroni in meno.

Ma il mio portatile del 2010 ride ancora.

E, ogni volta che si accende senza TPM, da qualche parte nel mondo un manager Micro$oft sente un brivido lungo la schiena.

    “Non tutti gli eroi indossano mantelli. Alcuni usano PowerShell.” 🧙‍♂️💻

Fine. Alla prossima

P.S. le ciambelle sono bucate, Ripeto: le ciambelle sono bucate.

P.P.S. Cerco di non nominare esplicitamente il nome del SO e della casa produttrice perchè, a farlo, ti arrivano addosso tutte le sfighe del mondo ed a me viene un glitch all'occhio destro.

HOSOME TPH07 aspirapolvere a batteria (riparazione)

 

Un aspirapolvere a batteria fa sempre comodo in casa, se uno se lo può permettere ovviamente, dato che costano un rene. Questo modello HOSOME TPH07 è uno dei tanti ciòttoli plasticosi che si trovano in commercio. E' in pratica un "dyson modello vorrei ma non posso".  Come tutti quegli aspirapolvere progettati in modo che il baricentro del peso graviti sulla zona più fragile e debole (progettisti dell'università serale), dopo un pò... si rompono ovviamente e come sempre.... conviene buttare che riparare, è una storiella che ricorre spesso in questo blog. 

Complice di questa obsolescenza programmata o progettazione del caxo causa ingegneri e designers strafatti di egocentrismo, è intervenuta una badante riciclata a donna delle pulizie (o collaboratrice domestica come piace dire ai fighetti radical chic del politically correct). Io che sono da sempre molto pragmatico, la chiamo "la schiava" in quanto, nonostante fosse in regola, veniva schiavizzata da un anziana nobile ultra novantenne abituata sin dall'infanzia alla servitù.

I danni che in poco meno di un anno è riuscita a fare sono difficilmente prevedibili. Spezza in due la scopetta, rompe le clip che agganciano gli accessori, rompe i supporti delle viti della spazzola rotante, strappa i collegamenti che portano l'alimentazione alla spazzola...  per non parlare delle botte, dei graffi, del nastro adesivo usato per tenere assieme il tutto, dello spago da cucina in sostituzione del nastro adesivo e dello sporco incrostato... un disastro che non voglio nemmeno raccontare.

Come riparatore dell'impossibile, mi sono messo in testa di riportare in vita questo attrezzo (che, lo so, serve ad un altra persona un pò meno povera di me) e tentare una riparazione a costo zero. Il mio obiettivo è rimettere assieme i pezzi, tentando di ricostruire le parti mancanti.  

Step 1 - Comincio dalle clip. Sono tenute in sede da un perno metallico ed una molla che tiene agganciato il tubo di aspirazione (o l'accessorio) tramite un arpionismo. Della molla nessuna traccia ovviamente. Dei pezzi da incollare nemmeno. Occorre ricostruire. L'ideale sarebbe ridisegnare il pezzo e stamparlo in PLA con una stampante 3D  ma credo che in breve tempo il problema si ripresenterebbe.  Il foro infatti è troppo vicino al bordo e tutta la pressione esercitata per agganciare e sganciare gli accessori va su una porzione di plastica decisamente insufficiente. 

 Allora penso di ricostruite il foro con un rinforzo metallico (una graffetta dei punti per unire i fogli) da affogare  nel pulsante dopo averlo scaldato con un accendino. 

Per rinforzare il tutto si usa poi la combinazione bicarbonato (o grafite) e colla cianoacrilica.  

 

Non importa se la ricostruzione non è perfetta. Con lima e dremel si risagoma il tutto, si inserisce il pulsante nella sede e si pratica il foro. Collaudo finale e..... CRACK!!!... non ho fatto un ottimo lavoro, l'oggetto è troppo piccolo ed affogare perfettamente la graffetta nella plastica è un operazione da fare con molta precisione e pazienza. Non ci sono riuscito, per cui prendo una decisione drastica: il tubo di aspirazione lo attacco con un paio di viti autofilettanti. Non sarà possibile smontarlo facilmente ma chissenefrega del beccuccio e della spazzolina per i punti difficili (per quelli ho un mini aspiratore da 9 euro preso dai cinesi). Ed il primo problema è risolto. 

Step 2: perchè la spazzola non ruota? la faccio breve. Nel tubo telescopico di aspirazione ci sono due fili elettrici che fanno capo a due coppie spina/presa. In prossimità della spazzola i fili sono strappati e non ho la più pallida idea di come la schiava sia riuscita a romperli in quel punto senza aprire il vano con un cacciavite a stella. Nel cercare di trovare il punto di interruzione, approfitto per aprire la spazzola rotante... meglio così perchè era piena zeppa di polvere e pelucchi, oltre a presentare un supporto spezzato (prontamente reincollato con la cianoacrilica).

Step3: la parte più difficile - rimettere assieme il contenitore della polvere a contatto con l'impugnatura che alloggia motore e contatti. Ho optato per una soluzione semplice. Un elastico ben teso è l'unica soluzione possibile in quanto ricostruire l'aggancio è impossibile (ovviamente non ci sono nemmeno i pezzi), avvitare il tutto nemmeno, epossidica bicomponente no, nastro adesivo è brutto e fa molto campo ROM. Allora ho recuperato una camera d'aria delle carrozzine per disabili, della dimensione perfetta per infilarsi su delle piastrine che tenevano unite le stecche di una vecchia saracinesca di legno anni '60. Si taglia alla misura giusta, si fissa la camera d'aria con degli occhielli da 5mm et voilà. Ho indovinato al primo colpo la giusta tensione che impedisce alla vaschetta raccogli polvere di allontanarsi dai contatti che servono per la luce sulla spazzola rotante da pavimento. 

 

Riparazione professionale? NO. Recupero? SI. Il tutto è ancora traballante (un pò) e dovrei pensare ad una soluzione migliore per fissare il tubo telescopico. Inoltre se si preme troppo (ma molto troppo) durante l'avanti ed indietro sul pavimento, l'elastico si stira ed i contatti si staccano... vabbè, basta starci attenti ed andarci pianino senza esagerare. La batteria al litio è ancora buona e sufficiente per una mezz'ora di aspirazione....bene. 

Ed anche questa volta ho contribuito a fare la mia parte in questo pianeta maltrattato da un branco di unani ignoranti e malvagi. Alla prossima. 

P.S.  L'uragano ruota ed est. Ripeto: l'uragano ruota ad est.