• Un’unica configurazione SSH per domarle tutte


    Ho quattro macchine su cui lavoro regolarmente: due desktop (uno Windows, uno Ubuntu) e due laptop (anche qui, uno per sistema). A questi si aggiungono alcuni server Linux VPS a cui mi collego per vari progetti. Sono tanti endpoint, tante chiavi SSH e tanti profili di terminale da tenere sincronizzati.

    Per un po’ ho semplicemente convissuto col caos. Ogni volta che configuravo una nuova macchina, o reinstallavo un sistema operativo, ripetevo lo stesso rituale: ricreare la configurazione SSH, copiare le chiavi in qualche modo, reinserire tutti gli alias degli host, riconfigurare colori e font del terminale. E ogni volta che cambiavo qualcosa su una macchina — un nuovo server da aggiungere, una nuova chiave da registrare — dovevo ricordarmi di replicare quella modifica su tutte le altre. Inevitabilmente, me ne dimenticavo. Le configurazioni divergevano. Una macchina aveva l’alias, un’altra no. Era una seccatura lenta e sotterranea, che non raggiungeva mai il livello di crisi, ma non spariva mai.

    Alla fine ho deciso di risolvere il problema per davvero. La soluzione che ho trovato è semplice nel concetto, solida nella pratica, e richiede circa venti minuti di configurazione iniziale.

    L’idea di fondo: una cartella sola, ovunque

    Il ragionamento è questo: invece di tenere chiavi SSH e file di configurazione sparsi su ogni singola macchina, si mette tutto in un’unica cartella all’interno del proprio cloud storage — OneDrive, Dropbox, Google Drive, qualunque si usi già. Ogni macchina poi punta a quella cartella, invece di mantenere una copia separata.

    Il meccanismo che rende possibile tutto questo si chiama collegamento simbolico (o symlink). Funziona come un cartello stradale: quando il client SSH cerca il suo file di configurazione nel posto solito, trova un cartello che lo reindirizza alla cartella condivisa sul cloud. Dall’esterno non cambia nulla. Sotto il cofano, tutte le macchine leggono dalla stessa unica fonte di verità.

    Su Windows i collegamenti simbolici funzionano allo stesso modo — ed è la scelta giusta anche lì. Forse hai sentito parlare degli hard link, un concetto correlato, ma gli hard link funzionano solo all’interno dello stesso disco. Dato che la cartella del cloud storage di solito si trova su un percorso diverso (o addirittura su un disco diverso) rispetto al profilo utente, i collegamenti simbolici sono la scelta corretta anche su Windows.

    Un prerequisito importante: il client di cloud storage deve essere configurato per mantenere i file disponibili localmente, non solo nel cloud. Su OneDrive questa opzione si chiama “Mantieni sempre su questo dispositivo”. I file devono trovarsi fisicamente su disco, accessibili anche offline.

    Creare la cartella condivisa

    All’interno della directory sincronizzata col cloud, crea questa struttura:

    ~/CloudSync/ssh-terminal/
    ├── ssh/
    │   ├── config
    │   ├── id_ed25519_workstation
    │   ├── id_ed25519_server
    │   └── id_ed25519_development
    └── terminals/
        ├── windows-terminal.json
        └── gnome-terminal-profiles/
    

    La sottocartella ssh/ contiene le chiavi SSH e il file di configurazione. La sottocartella terminals/ contiene le impostazioni dei terminali. Vedremo come popolarle entrambe nei passi successivi.

    Il file di configurazione SSH

    SSH legge le sue impostazioni da un file di testo semplice chiamato config, normalmente situato in ~/.ssh/config. È lì che si definiscono gli alias degli host, si specifica quale chiave usare per quale server, si impostano le opzioni di connessione. Se non l’hai mai usato, è una di quelle cose che, una volta scoperte, ti chiedi come hai fatto a farne a meno.

    Un esempio tipico di configurazione:

    # Esempio di configurazione SSH condivisa
    Host server-produzione
        HostName 192.168.1.100
        User administrator
        IdentityFile ~/.CloudSync/ssh-terminal/ssh/id_ed25519_production
        Port 22
    
    Host sviluppo
        HostName dev.example.com
        User developer
        IdentityFile ~/.CloudSync/ssh-terminal/ssh/id_ed25519_development
    

    Nota che i percorsi di IdentityFile usano il carattere ~ (tilde) per rappresentare la home directory. Vale la pena capire esattamente cosa significa, perché è il segreto della portabilità.

    Su Linux e su Windows, ogni utente ha una home directory: una cartella personale dove il sistema conserva file, impostazioni e configurazioni. Su Linux è tipicamente /home/tuonome, su Windows C:\Users\tuonome. Il carattere tilde (~) è un’abbreviazione che sia Bash su Linux che PowerShell su Windows espandono automaticamente alla home directory dell’utente corrente. Quindi ~/.ssh/config diventa /home/tuonome/.ssh/config su Linux, e C:\Users\tuonome\.ssh\config su Windows.

    Questo è ciò che rende il file di configurazione davvero portabile: dato che ogni macchina espande ~ alla propria home directory locale, la stessa riga funziona ovunque senza modifiche. Se avessimo scritto il percorso completo — /home/luca/CloudSync/... — funzionerebbe solo sulle macchine in cui il nome utente e la struttura delle directory coincidono esattamente.

    Una volta che il file config è pronto nella cartella condivisa, lo si collega al percorso che SSH si aspetta:

    Windows (PowerShell come Amministratore)

    New-Item -ItemType SymbolicLink `
      -Path "$env:USERPROFILE\.ssh\config" `
      -Target "$env:USERPROFILE\CloudSync\ssh-terminal\ssh\config"
    

    Ubuntu

    ln -sf ~/CloudSync/ssh-terminal/ssh/config ~/.ssh/config
    

    Da questo momento in poi, modificare il file di configurazione nella cartella cloud lo aggiorna istantaneamente su tutte le macchine. Aggiungi un nuovo server sul desktop, e il laptop lo conoscerà già alla prossima sincronizzazione.

    Profili del terminale: Windows Terminal

    Windows Terminal conserva l’intera configurazione — profili, schemi di colori, font, scorciatoie da tastiera — in un unico file JSON. Questo lo rende un candidato ideale per questo approccio.

    Il file si trova in:

    $env:LOCALAPPDATA\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json
    

    Chiudi Windows Terminal, poi sostituisci quel file con un collegamento simbolico alla copia condivisa:

    # Esegui in PowerShell come Amministratore, con il Terminale chiuso
    New-Item -ItemType SymbolicLink `
      -Path "$env:LOCALAPPDATA\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json" `
      -Target "$env:USERPROFILE\CloudSync\ssh-terminal\terminals\windows-terminal.json"
    

    È anche possibile definire profili SSH direttamente all’interno della configurazione di Windows Terminal, in modo che i server specifici appaiano come voci con nome nel menu a tendina:

    {
        "$schema": "https://aka.ms/terminal-profiles-schema",
        "profiles": {
            "list": [
                {
                    "name": "SSH Produzione",
                    "commandline": "ssh server-produzione",
                    "icon": "ms-appx:///ProfileIcons/server.png"
                }
            ]
        }
    }
    

    Profili del terminale: GNOME Terminal e Ptyxis su Ubuntu

    Sia GNOME Terminal che Ptyxis conservano la propria configurazione in dconf, un database di impostazioni a basso livello usato in tutto l’ambiente desktop GNOME. Pensalo come l’equivalente GNOME del Registro di sistema di Windows: un database strutturato dove le applicazioni memorizzano le proprie preferenze. Non c’è un singolo file a cui creare un collegamento, ma è possibile esportare e importare l’intera configurazione come uno snapshot in testo semplice usando lo strumento da riga di comando dconf.

    L’approccio è identico per entrambi i terminali — cambia solo il percorso all’interno del database dconf.

    GNOME Terminal

    Per esportare i profili attuali:

    dconf dump /org/gnome/terminal/legacy/profiles:/ \
      > ~/CloudSync/ssh-terminal/terminals/gnome-terminal-profiles/profiles.dconf
    

    Per ripristinarli su un’altra macchina:

    dconf load /org/gnome/terminal/legacy/profiles:/ \
      < ~/CloudSync/ssh-terminal/terminals/gnome-terminal-profiles/profiles.dconf
    

    Ptyxis

    Ptyxis è un emulatore di terminale più recente, ora predefinito nelle distribuzioni basate su GNOME più aggiornate, come Fedora 41 e Ubuntu 25.10. Usa un percorso dconf diverso:

    dconf dump /org/gnome/Ptyxis/ \
      > ~/CloudSync/ssh-terminal/terminals/ptyxis-profiles/profiles.dconf
    

    Per ripristinare:

    dconf load /org/gnome/Ptyxis/ \
      < ~/CloudSync/ssh-terminal/terminals/ptyxis-profiles/profiles.dconf
    

    Automatizzare il ripristino dei profili all’avvio

    È possibile automatizzare il ripristino in modo che i profili vengano applicati automaticamente ad ogni accesso, aggiungendo un controllo al proprio profilo di shell (~/.profile). Adatta il percorso e la chiave dconf al terminale che utilizzi:

    #!/bin/bash
    # Per GNOME Terminal:
    if [[ -f ~/CloudSync/ssh-terminal/terminals/gnome-terminal-profiles/profiles.dconf ]]; then
        dconf load /org/gnome/terminal/legacy/profiles:/ \
          < ~/CloudSync/ssh-terminal/terminals/gnome-terminal-profiles/profiles.dconf
    fi
    
    # Per Ptyxis:
    if [[ -f ~/CloudSync/ssh-terminal/terminals/ptyxis-profiles/profiles.dconf ]]; then
        dconf load /org/gnome/Ptyxis/ \
          < ~/CloudSync/ssh-terminal/terminals/ptyxis-profiles/profiles.dconf
    fi
    

    Una nota sulla sicurezza

    Conservare chiavi SSH private in una cartella sincronizzata col cloud è un compromesso ragionevole, ma richiede alcune precauzioni.

    Usa sempre le passphrase

    Ogni chiave privata deve essere protetta da una passphrase robusta. Questo garantisce che anche se qualcuno dovesse accedere al tuo cloud storage, non potrebbe usare le chiavi senza conoscere la passphrase. Per generare le chiavi:

    ssh-keygen -t ed25519 -a 100 -C "workstation@$(hostname)" \
      -f ~/CloudSync/ssh-terminal/ssh/id_ed25519_$(hostname)
    

    Il flag -t ed25519 seleziona un algoritmo moderno ed efficiente. Il flag -a 100 aumenta il numero di cicli di derivazione della chiave, rendendo significativamente più difficile un attacco a forza bruta sulla passphrase.

    Usa chiavi separate per ogni dispositivo

    Invece di condividere una singola coppia di chiavi su tutte le macchine, mantieni chiavi distinte per dispositivo o livello di fiducia:

    • Workstation principale: id_ed25519_workstation
    • Sistemi secondari: id_ed25519_backup
    • Ambienti di sviluppo: id_ed25519_development

    In questo modo, se una macchina viene compromessa, puoi revocare solo quella chiave senza influire su tutto il resto.

    Limita i permessi sui file

    PiattaformaCosa fare
    WindowsRimuovi i permessi ereditati del gruppo “Utenti” dalla directory SSH
    Linuxchmod 700 ~/CloudSync/ssh-terminal/ssh && chmod 600 ~/CloudSync/ssh-terminal/ssh/id_*

    SSH su Linux si rifiuterà di usare chiavi con permessi troppo permissivi — quindi questo passaggio non è opzionale.

    Quando qualcosa va storto

    Alcuni problemi che potresti incontrare, e come risolverli:

    ProblemaWindowsLinux
    Creazione del collegamento fallisceEsegui PowerShell come AmministratoreProva con sudo ln -sf
    Configurazione non caricataRiavvia Windows Terminaldconf reset -f /org/gnome/terminal/legacy/profiles:/
    Chiavi non trovateVerifica che la sincronizzazione cloud sia completatals -la ~/CloudSync/ssh-terminal/ssh/
    Passphrase richiesta continuamenteStart-Service ssh-agent; ssh-addssh-add ~/CloudSync/ssh-terminal/ssh/id_*

    Per andare oltre: configurazione condizionale

    SSH supporta gli include condizionali, che permettono di caricare blocchi di configurazione diversi a seconda del sistema operativo o di altre condizioni. È utile se hai alcune impostazioni che differiscono genuinamente tra Windows e Linux:

    # ~/.ssh/config
    Include ~/.ssh/config.d/common.conf
    
    Match exec "uname -s | grep -q ^Linux"
        Include ~/.ssh/config.d/linux.conf
    

    Il file comune contiene tutto ciò che è condiviso tra le macchine. I file specifici per piattaforma gestiscono le eccezioni.

    Il risultato

    Una volta messo in piedi, configurare una nuova macchina richiede circa cinque minuti: installa il client di cloud sync, aspetta che la cartella si scarichi, esegui due o tre comandi di collegamento, fatto. Ogni alias degli host, ogni chiave, ogni schema di colori del terminale — già lì, esattamente come li hai lasciati sulle altre macchine.

    Ma la cosa più importante è un’altra: quando fai una modifica — aggiungi un nuovo server, ruoti una chiave, ritocchi un profilo del terminale — la fai una volta sola, e si propaga ovunque automaticamente. Niente più replicazione manuale. Niente più configurazioni che divergono. Niente più sorprese quando ti siedi a una macchina e scopri che è rimasta indietro.

    È una di quelle soluzioni che, una volta installata, dimentichi di avere. Ed è esattamente questo il punto.

    Reazioni nel fediverso
  • Ignoranti certificati

    I certificati a chiave pubblica sono la base della sicurezza delle comunicazioni online con protocolli come https o, più in generale, TLS.

    Benchè a livello di programmazione, gli algoritmi coinvolti e la loro implementazione non siano esattamente lineari, a livello di utilizzo come amministratore di sitema sono relativamente semplici, forse troppo.

    Continua a leggere
    Reazioni nel fediverso
  • Installazioni nascoste via Windows Update

    Da un mesetto ho messo un Palo Alto PA-220 in modalità virtual wire tra il router Internet e lo switch di casa.

    Questa mattina controllo il report dell’ACC e trovo tanto traffico Windows Update, eppure non è patch tuesday.

    Continua a leggere
    Reazioni nel fediverso
  • Informazioni? Chiedi all’AI (se ti accontenti del 2023).

    È da tempo che non scrivo qualcosa, ma ho letto un articolo che mi ha fatto immediatamente pensare che sarei dovuto tornare qui.

    Da qualche anno ho iniziato a seguire in modo sempre più serio la pallavolo femminile. Per questo sono piuttosto interessato a leggere i pochi articoli dedicati a questo sport.

    Nota polemica: questo sport, diversamente da “quell’altro”, partecipa sempre ai mondiali o agli europei e, di solito, nella peggiore delle ipotesi, si classifica tra le prime 4, se non addirittura vincendoli.

    Mi è capitato tra le mani un articolo online (su Movmag.com) che, dopo averlo letto, mi ha lasciato perplesso: sembra proprio che chi l’ha scritto abbia una conoscenza limitatissima di questo sport, tanto da aver probabilmente utilizzato una Generative AI gratuita.

    (altro…)
  • Esfiltrare NTDS.dit senza accesso ai DC

    In un dominio Active Directory gli hash delle password degli utenti sono registrati nel file NTDS.dit presente in ogni Domain Controller (DC), il cui path di default è C:\Windows\NTDS\NTDS.dit

    Esistono vari modi per fare una copia degli hash, ma tutti quelli normalmente elencati partono dal presupposto che si abbia accesso di un certo tipo ad un Domain Controller.

    Molte linee guida raccomandano di monitorare e regolare bene l’accesso ai DC, ma si dimenticano di un dettaglio.

    I backup.

    Continua a leggere
    Reazioni nel fediverso
  • Ultimo HyperTrek in HTML

    Per fare un tuffo nel passato e ricordarsi di come era il web quando era solamente HTML senza script o popup vari, ho deciso di caricare l’ultima versione di HyperTrek 100% HTML prima che venisse convertita in PHP+MySQL.

    http://www.hypertrek.org

    Mancano dei pezzi nella pagina di download e, ovviamente, non è detto che funzionino i link esterni, ma un vero geek non ha bisogno di questi avvertimenti perché ci arriva da solo.

    Per qualcosa di un po’ più aggiornato, il progetto continua su https://wikitrek.org

    Edit 2024-12-27 sera: i file di download ci sono tutti, solo hypertrek.zip è lo ZIP con il sito che vedete, gli altri sono più vecchi. Si possono scaricare anche il vecchio WinTrekHelp e i sorgenti della Norton Guide.

  • Migrare un telefono Android

    Passare ad un telefono nuovo è sempre una rottura.

    Android adesso fa le cose abbastanza semplici: si accende il telefono nuovo con a fianco quello vecchio collegato in Wifi, si seguono le istruzioni, si aspetta il tempo di trasferimento, si sposta la SIM ed il gioco è fatto.

    Quasi.

    Continua a leggere
  • Bloccare New Outlook

    Microsoft ha annunciato che da inizio 2025 inizierà a forzare il passaggio da Outlook Desktop a New Outlook.

    New Outlook non è altro che un brutto wrapper di Outlook Web Access, più limitato nelle funzionalità di Outlook Desktop, specialmente se si possiedono più account.

    Continua a leggere
  • Copia interna della zona pubblica

    Capita spesso di voler creare dei nomi della LAN interna con il FQDN di un nome a dominio pubblico o di voler sovrascrivere alcuni host con IP pubblico con gli stessi nomi, ma con IP interno.

    La soluzione più comune è creare una zona con lo stesso nome della zona esterna con gli stessi contenuti, a meno di quelli che devono essere differenti.

    Continua a leggere
  • Un UPS non fa primavera

    Questo post scaturisce da una conversazione che ho avuto pochi giorni fa con un elettricista a proposito di come debba essere inserito un UPS in un impianto elettrico un e della utilità dei relativi accessori.
    Mi sono reso conto di una ignoranza generalizzata di come funzioni un UPS e di quali siano i suoi punti di forza e di debolezza: di conseguenza ho deciso di riassumere qui una serie di argomenti che ho usato per convincere il fornitore che il modo di fare che proponevo io fosse il migliore.

    Come prima cosa ci sarebbe da ribadire il concetto per cui, invece di essere il fornitore sedicente esperto nel campo, a suggerire al cliente (povero ignorante) le soluzioni migliori, per l’ennesima volta sono stato io a dovermi documentare, a dover trovare la soluzione giusta e anche a dover convincere l’altra persona della bontà delle mie conclusioni.
    Non ne usciremo mai.

    Premetto che quanto racconto qui di seguito si applica in prima battuta a una server room, ma i concetti che stanno dietro alla spiegazione sono idealmente applicabili a impianti di ogni genere, al limite anche a quello di un datacentre.

    Premesse

    UPS è l’acronimo della frase inglese “Uninterruptible Power Supply” termine che in italiano è normalmente tradotto come “gruppo di continuità“.
    Nonostante esistano molti tipi di questi apparecchi, basati su varie tecnologie, nella sua forma più basica è sostanzialmente una batteria che viene installata tra la fornitura di corrente e gli apparati da alimentare.

    Il suo scopo è quello di smorzare eventuali fluttuazioni di corrente che potrebbero rivelarsi dannose e di erogare energia anche in caso di blackout. A seconda dei casi, la quantità di energia immagazzinata è progettata per durare i minuti necessari al graceful shutdown delle apparecchiature collegata, oppure per permettere loro di funzionare anche per periodi di tempo lunghi senza corrente esterna.
    Le apparecchiature discusse sopra sono spesso quelle definite business-critical, ovvero che sono fondamentali per il funzionamento di una qualsivoglia organizzazione.
    All’atto pratico, sono spesso server e dispositivi di rete.

    A questo punto è chiaro quindi che un UPS è un apparecchio importante, anzi fondamentale, nella progettazione di una infrastruttura IT, ma molti pensano che sia il classico silver bullet: lo compro, lo installo, me lo dimentico e tutto andrà bene.
    Anche no, questo funziona solo nei film: un UPS non fa primavera!

    Reality check

    Per prima cosa bisogna rendersi conto di due fondamentali verità:

    • Lo UPS prima o poi si guasterà
    • lo UPS deve essere manutenuto e, dopo qualche anno, andrà sostituito

    Una volta fatto pace con queste due ineluttabilità, si può iniziare a ragionare su cosa serva intorno allo UPS per renderlo davvero efficace.

    Dopo aver installato il vostro UPS ed essere andati a letto tranquilli, una telefonata vi sveglia dicendo che nella vostra infrastruttura IT non funziona nulla. Cosa sarà successo? Strano sembra che non ci sia elettricità da nessuna parte. Seguendo i cavi e controllando gli apparati, si scopre che l’UPS è guasto!
    Ebbene, sì, succede. Ve lo hanno venduto come un apparato indistruttibile e invece è proprio lui a tradirvi. Tuttavia avete collegato tutti i vostri apparati alle uscite del UPS pensando di essere protetti e dovrete quindi ricablare tutto, riparare lo UPS e poi ricablare tutto di nuovo.
    Forse esiste una soluzione migliore?

    Certo che sì.
    Avrete notato che i vostri preziosi e costosi apparati di rete, così come i server e i NAS sono dotati di due (a volte anche quattro) prese elettriche.
    Invece di collegarle entrambe allo UPS, provate a collegarne una all’UPS e l’altra alla rete elettrica diretta: in caso di assenza di corrente da una delle due sorgenti, l’altra fonte continuerà a fornire energia, tenendo accesi i vostri apparecchi.

    Regola numero 1: in ogni rack ricordate di portare due alimentazioni, una dalla rete elettrica, l’altra dall’UPS.

    Sento già le proteste dal pubblico: molti apparati professionali hanno le due (quattro, sei, quello che volete) prese elettriche, ma molti non lo hanno!
    Classico è l’esempio del vostro Internet Service Provider che vi fa pagare un prezzo ragionevole per la vostra bella connessione a internet, ma che poi vi porta il router di fascia media con una presa elettrica e stop.
    Certo, è possibile avere il router della [inserite marca costosissima a piacere] con doppia alimentazione, ma vi costa millemila euro al mese in più.

    Grazie, no.
    Quei mille euro li investo veramente, ma non in un router che dite voi, bensì in una cosa molto più utile: uno Automatic Transfer Switch.
    Un ATS è un apparecchio intelligente che ha due alimentazioni e una o più uscite.
    Avrete forse intuito che le due alimentazioni vanno collegate, una alla rete elettrica pubblica e l’altra allo UPS.
    Alle uscite del ATS si collegano i vari apparati dotati di singola presa elettrica e il commutatore si occupa automaticamente di passare da un’alimentazione all’altra quando una viene a mancare. Una serie di condensatori fanno si che l’alimentazione non fluttui nelle frazioni di secondo necessarie per commutare.

    Regola numero 2: investite in un ATS e usatelo per alimentare gli apparati low end, dotati di singola presa elettrica.

    Quindi dobbiamo alimentare lo UPS, alimentare gli apparati con doppia sorgente elettrica e alimentare lo ATS.
    Siamo a posto, finito?

    Non esattamente, manca in effetti un tassello, forse meno importante, ma comunque da considerare.
    L’ultimo componente da considerare è il cosiddetto maintenance bypass, un apparecchio che consente di “aggirare” lo UPS per permetterne la manutenzione o addirittura lo smantellamento.

    Ricordiamo che lo UPS è un apparecchio elettrico che, non solo è alimentato spesso a corrente trifase, ma che contiene anche una discreta quantità di energia (normalmente chimica) e quindi va trattato con attenzione.
    Alcune azione manutentive richiedono lo spegnimento, inoltre l’apparecchio ovviamente si può guastare in maniera catastrofica o semplicemente raggiungere la fine della sua vita operativa, necessitando smontaggio completo.

    Il bypass ha la funzione di prelevare la corrente dalla rete, trasmetterla al UPS, dopodiché prenderne l’uscita “protetta” e distribuirla al carico.
    Il lettore avrà già capito che, agendo sugli opportuni comandi, il bypass permette di scegliere se “tagliare fuori” lo UPS dal circuito elettrico distribuendo la corrente di rete a tutti gli apparati a valle.
    Effettuata questa operazione, lo UPS può essere testato, riparato o eventualmente sostituito senza disturbare il carico.

    Di nuovo sento una protesta: se i miei apparati hanno già doppia alimentazione oppure alimentazione tramite ATS, cosa mi serve avere un bypass che, in caso di guasto al UPS, non fa altro che distribuire due volte la corrente di rete?
    Fondamentalmente corretto, ma non considera la Legge di Murphy: nel momento in cui una delle due alimentazioni non è disponibile l’altro alimentatore potrebbe avere un guasto, mandando quindi a gambe all’aria la ridondanza.

    Regola numero 3: investite in un maintenance bypass e fate in modo che si possa isolare lo UPS in qualsiasi momento.

    Pessimismo?

    Pensate che sia pessimista?
    Permettetemi un aneddoto.
    Dopo 10 anni di onorato servizio, causa mancanza di parti di ricambio e impossibilità a prolungare il contratto di assistenza, ho dovuto programmare la sostituzione di un UPS. Grazie a tutto quanto scritto sopra, è stato facile isolare l’apparecchio in una normale giornata lavorativa senza interrompere l’operatività.

    Tutto bene e tutti contenti, ma cosa capita a metà del lavoro? Si verifica un black-out e, essendo lo UPS ovviamente smontato e fuori linea, si spegne tutto.
    Avrei dovuto avere due UPS in modo da fare manutenzione alternata, ma che probabilità c’era che succedesse una cosa del genere?
    Piccolissima, eppure è successo.

    Anything that can go wrong, will go wrong

    Conclusioni

    Riassumendo, quando si progetta un impianto elettrico per centri dati (di ogni dimensione) è opportuno ricordare:

    • Una alimentazione dalla rete per apparecchi con ingressi ridondanti
    • una alimentazione per un apparecchio ATS
    • una alimentazione per un maintenance switch (che poi la erogherà al UPS)

    Bisognerà poi distribuire:

    • L’alimentazione del ATS agli apparecchi con una sola presa
    • l’alimentazione del maintenance bypass (che la prende dalla rete o dal UPS) agli apparati con due prese
    • la stessa alimentazione di cui sopra all’ingresso del ATS

    Spero di avervi convinto che, anche in questo caso, esiste un modo giusto è un modo sbagliato per progettare una soluzione di alimentazioni ridondante.
    Quella giusta sembra più cara e più complicata. Alla lunga si rivelerà quella più flessibile.

  • Il formato DBF

    Chi vi scrive ha mosso i primi passi nel mondo dei database con dBase II su CP/M, ha passato gran parte del servizio di leva davanti ad un M24 con dBase III+, si è guadagnato da vivere per un po’ di anni scrivendo applicazioni in Clipper.

    Quindi, il DBF è stato mio compagno di viaggio informatico per qualche tempo, qui trovate una bellissima e molto documentata storia di quel formato e dell’ecosistema che ha generato da quando è nato ai giorni nostri: The Rise, Fall, and Surprising Survival of dBase.

  • Come non si scrivono le istruzioni

    Un collega mi segnala questa perla che potrebbe essere lo zero Kelvin di come si scrive una guida per configurare i record del DNS per utilizzare il loro servizio.

    Si tratta di una guida su come modificare il record SPF, ma le parti che ci si aspetterebbe che fossero copiabili come testo sono tutte immagini.

    (altro…)