Author: Michele Bologna

  • Goodbye DynDNS, benvenuto DtDNS (Update: ora mi appoggio a noip.com)

    Update 2018-08-08: DtDNS ha chiuso i battenti il 2018-08-01. Attualmente mi sto appoggiando a noip.com, sebbene non sia pienamente soddisfatto. Se state cercando della altre alternative, AlternativeTo contiene una sezione riguardo DtDNS. Se avete dei consigli, segnalateli pure nei commenti.

    Ho sempre avuto un dynamic dns con DynDNS il cui IP viene risolto sulla mia connessione casalinga (IP dinamico). Il servizio è gestito in automatico dal software del router: ogni volta che instaura una connessione PPP ADSL, viene aggiornato il corrispondente host dinamico con DynDNS; è tutto gestito in modo trasparente, senza intervento dall’utente.

    Ultimamente DynDNS richiede che l’utente, specie nel servizio gratuito, faccia un login (via web) ogni 30 giorni, pena la disattivazione (momentanea) del dynamic dns. Avrei potuto fare uno script che faccia questo login e metterlo in crontab, ma perché complicarsi la vita?

    Quindi, ho deciso di cambiare servizio di dynamic dns: sono passato a DtDNS. Dopo aver controllato che sia supportato dal software del router (si), ho scelto tra i vari domini offerti dal servizio: la scelta non poteva che ricadere sul più nerd: suroot.com. Per ora, il servizio funziona, le zone DNS si aggiornano velocemente e non ho errori di resolv.

    Infine, ho cancellato il mio account DynDNS: da “Account settings” è sufficiente scegliere “Close account”.

  • Feedly è un degno sostituto per Google Reader

    Sono passati diversi anni dalla nascita di Google Reader (2005), il più famoso ed utilizzato feed reader di RSS/Atom; anzi, tutt’oggi viene utilizzato come piattaforma di sincronizzazione per i reader che funzionano su più dispositivi (personal favorite: Reeder su OSX e iOS).

    Nel frattempo, altri servizi simili a Reader ma più user-friendly (ed adatti anche ai meno nerd) si sono diffusi: uno tra tutti è Twitter. A mio avviso, Twitter non è un sostituto di un RSS/Atom.

    Ma c’è di più: Google ha deciso di terminare Reader dal 1 luglio 2013 (la mia ipotesi: privacy issues), per cui viene a mancare un servizio fondamentale, sia per la lettura dei feed che per la sincronizzazione.

    Se usate Google Reader la prima cosa da fare è assolutamente esportare la lista delle subscriptions OPML tramite Takeout (Settings di Reader -> Export).

    La ricerca di un servizio alternativo è il secondo passo. Nell’ultimo mese ho provato alcuni servizi simili a Google Reader. La scelta è caduta su Feedly (in particolare sulla versione Cloud). Il servizio è gratuito e a mio avviso è il degno sostituto di Google Reader, sia per quanto riguarda l’interfaccia che le funzionalità offerte.

  • Installazione e configurazione di Logwatch su Ubuntu

    Nei server Linux che amministro ho recentemente installato un programma di monitoring dei logs: logwatch.
    Una questione importante ma abbastanza noiosa e per cui non si ha mai molto tempo è – appunto – quella dell’analisi dei log, una sorta di “diario” dell’attività svolta dal sistema.
    Spesso si ricerca nei logs solo quando insorge un problema: la proattività di logwatch, invece, ci permette di avere una sintesi di ciò che è successo e che merita la nostra attenzione direttamente via email.

    Assicuratevi di avere un MTA installato e configurato a dovere [consiglio: postfix o qmail].
    Una volta installato, logwatch invia una mail a root@localhost ogni giorno.
    Modifichiamo quindi l’indirizzo a cui root farà il forward di tutta la posta:

    % cat /etc/aliases
    postmaster: root
    root: michele@bologna.com

    Modifichiamo la schedulazione dell’esecuzione di logwatch da giornaliero a mensile [da cron.daily a cron.weekly]:

    mv /etc/cron.daily/*logwatch /etc/cron.weekly

    Ed infine specifichiamo a logwatch di analizzare i log relativi agli ultimi 7 giorni e il formato da usare (HTML):

    cp /usr/share/logwatch/default.conf /etc/logwatch/conf/logwatch.conf

    Nel file di conf cambiate:

    • Format = html
    • Range = between -7 days and -1 days

    Ecco l’esempio di una mail ricevuta da logwatch:

    logwatch1

    logwatch2

     

     

     

     

    Come potete vedere ci sono informazioni molto interessanti, come:
    * i pacchetti installati/aggiornati tramite dpkg
    * gli accessi tramite ssh
    * gli utilizzatori di sudo
    * lo spazio disco utilizzato
    e altre informazioni sicuramente utili sullo stato della macchina in questione.

    logwatch è entrato nella dotazione software standard che installo su tutte le macchine Linux che amministro.

  • iOS Bootcamp al TAG di Bergamo

    Ieri sera ho partecipato all’incontro “iOS Bootcamp” organizzato dalla community di #pragma mark presso il TAG di Bergamo.
    Non era la prima volta che frequentavo il TAG: un luogo dove incontrare giovani startupper e persone interessanti con cui discutere di tecnologia ed innovazione in un ambiente stimolante e creativo.

    Era la prima volta, però, che partecipavo ad un talk tecnico presso il TAG. L’organizzazione è stata impeccabile: è stato usato EventBrite per gestire gli inviti ed i tickets di ingresso [il talk non aveva alcun costo], la sala era spaziosa, i tempi rispettati, e la dotazione tecnologica a disposizione ha permesso di seguire il talk in completa autonomia. Essendo un talk prettamente tecnico, la sala si è rapidamente trasformata in un covo di nerds, ma rispetto ad altre conferenze non ci sono stati incidenti.

    Incontravo la community di pragma mark e i suoi quattro fondatori: il talk che hanno tenuto ha spaziato lungo tutto l’ecosistema Apple per lo sviluppo di applicazioni iOS e OSX, passando dai provisioning profiles [più croce che delizia per i developers] fino ad arrivare al message-passing tipico di Objective-C [derivante da SmallTalk].
    Il talk è stato presentato in maniera logica, chiara e anche divertente: il trivia che spiega come è nato il nome della community è stato un piacevole break.
    I presentatori sono stati molto disponibili: nella parte di Q&A ho posto alcune domande su ARC e manual memory management e le risposte sono state molto esaustive e chiare.

    L’impressione che ho avuto, quindi, è molto positiva: sicuramente parteciperò ai prossimi talk organizzati da #pragma mark presso il TAG, e ho già sottoscritto il feed RSS dei rispettivi blog.

  • sshuttle: creiamo una VPN (via transparent proxy) con SSH

    In passato vi ho spiegato come creare un tunnel SSH per poter “tunnelizzare” il traffico Internet usando da tramite un server che esponeva il demone sshd. La scomodità di questa soluzione risiede nell’ultimo passo: dobbiamo impostare un tunnel SOCKS per ogni programma di cui vogliamo tunnelizzare il traffico. Ok, questo può non essere una scomodità vera e propria, tuttavia: per esempio, vogliamo tunnelizzare solo il traffico del browser [pensiamo di trovarci in una rete pubblica], mentre il traffico SSH [già cifrato] non ha bisogno di essere tunnelizzato.

    Oggi facciamo un passo oltre: vogliamo sfruttare la connessione SSH che abbiamo per tunnelizzare  tutto il traffico attraverso SSH. Questo è equivalente a creare una VPN con il server remoto, ma l’unica differenza importante è che non si creano interfacce di rete aggiuntive!

    Di conseguenza, l’host locale (che chiamiamo client) instaurerà una connessione SSH verso il server che si assumerà la responsabilità di instaurare la connessione verso gli altri host e di fare da “passacarte” verso il client. La configurazione è molto utile nel caso in cui il client si trovi ad utilizzare una rete pubblica non sicura (pensiamo ad esempio a Starbucks) ma allo stesso tempo voglia che tutto il traffico sia cifrato per evitare problemi di sniffing.

    Il software che ci permette di costruire la VPN (vi ricordo che non è a tutti gli effetti una VPN, anche se ne si hanno tutti i benefici) è sshuttle, disponibile per Linux e OSX.

    Una volta installato solo sul client (lo trovate nei repo di Ubuntu e in homebrew), vi consiglio di configurarlo per fare il forward di tutto il traffico (comprese le richieste DNS) nel seguente modo:

    ./sshuttle --dns -vvr username@sshserver 0/0

    [Nota: 0/0 è uno shortcut per 0.0.0.0 – se volete modificarlo per fare selective routing verso il tunnel di una particolare subnet, sapete cosa dovete modificare ;)]

    Per i più curiosi, ecco una piccola spiegazione di cosa c’è under the hood di sshuttle.

  • Tutte le novità di Java 7

    A metà 2011 è stata rilasciata la versione 7 di Java [nickname Dolphin].
    Due sono le grandi novità di questo rilascio:

    • Java è ora marchiata Oracle (che ha acquisito Sun)
    • La reference implementation è ora OpenJDK (l’implementazione open-source di Java), mentre per le passate versioni rimane HotSpot, la versione di Sun Oracle.

    Le novità più interessanti, dal punto di vista delle API, sono:

    • Una (nuova) versione delle API NIO 2 per la gestione e la navigazione del file-system (come ad esempio: Path, Files)
    • Supporto al multiprocessing (ForkJoinTask / RecursiveTask)
    • La possibilità di usare instanze di String come argomento di switch:
      “`
      switch (s) {
      case "foo": break;
      case "bar": break;
      case "foobar": System.out.println("it's foobar!");
      }
      “`
    • Catturare diversi tipi di Exception con una sola catch [separando le Exception con un ‘|’]:
      “`
      try {
      FileInputStream fi = new FileInputStream("foo.txt");
      }
      catch(FileNotFoundException | IoException e) {
      log.error("error: not found or I/O Exception");
      }
      “`
    • try-with-resource [Automatic Resource Management]: dentro ai blocchi try/catch/finally si rimanda la chiusura degli stream/connessioni al finally. Grazie a try-with-resource è la stessa JVM che si occupa di fare ordine con le risorse utilizzate al termine del blocco.
      “`
      try (FileOutputStream fos = new FileOutputStream(f)) {
      fos.write(buf, 0, len);
      }
      catch (Exception e) {
      log.error(e);
      }
      “`
    • Diamond operator (solo sintassi, evitiamo la ripetizione della classe usando i Generics):
      “`
      List<String> foobar = new ArrayList<>();
      “`
    • Leggibilità dei valori numerici (specifichiamo un separatore ‘_’):
      “`
      long accountNumber = 1234_5678_9012L;
      “`
    • JDBC 4.1 (Annotazioni `@Select` e `@Update` per definire le query, `DataSet` sostituisce ResultSet)
  • Convertire una macchina fisica in una virtuale: VMware vCenter Converter

    Ho recentemente convertito due macchine fisiche Windows in macchine virtuali (per questioni di manutenibilità) con un tool gratuito messo a disposizione da VMware: VMware vCenter Converter.

    Una volta installato si occupa di fare un’immagine virtuale di tutto il contenuto dell’hard disk (comprese eventuali partizioni), creando una macchina virtuale (compatibile con VMware e con Oracle VirtualBox).

    Non ho ancora provato a virtualizzare una macchina Linux (mi sono affidato a clonezilla), ma VMware supporta anche la conversione di Linux da fisico a virtuale.

  • zsh: perché non utilizzo bash

    Su tutte le macchine Linux e OSX che amministro non uso come shell di default la bash; uso invece zsh, perché:

    • zsh si offre di completare anche le opzioni e i parametri dei programmi più usati;
    • zsh fa spelling correction dei comandi digitati, chiedendo interattivamente se volete correggere il comando;
    • zsh offre una customizzazione più spinta della bash (vedremo tra poco il mio prompt);
    • zsh condivide la history tra più sessioni attive contemporaneamente;
    • zsh è già installata, di default, su OSX (ed è nei repo di Ubuntu, percui basta un aptitude install zsh).

    Se questi vantaggi non dovrebbero bastare, ecco il mio prompt:

    Ho scritto un tema ad-hoc, che funziona grazie a oh-my-zsh (un framework di customizzazione per zsh, che consiglio vivamente!). Cos’ha di speciale il mio prompt rispetto ad una semplice bash?

    • Colorazione diversa del prompt se siamo root
    • Colorazione del prompt in base all’esito positivo o negativo dell’ultimo comando utilizzato
    • Visualizzazione dello stato del repo git della directory attuale: branch + status (modifiche unstaged?)

    Ho caricato su github i due temi che ho creato per oh-my-zsh: michelebologna.zsh-theme è quello mostrato in questi screenshot. Ovviamente, prima dovete installare oh-my-zsh. Feedback benvenuti!

  • HTTPS e le applicazioni di terze parti: attenzione!

    “È sufficiente usare HTTPS per essere sicuri: protegge la comunicazione cifrando il traffico e usando certificati validati da CA riconosciute”.

    SBAGLIATO. Spesso si sente pronunciare questa frase, ma non è del tutto vero: ho recentemente letto con molta attenzione un paper presentato alla conferenza CCS 2012, una conferenza dedicata alla Computer Security. Il paper ha un titolo curioso: “The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software“.

    Si parla di HTTPS/SSL in contesti in cui è richiesta una comunicazione cifrata tra due sistemi (trasmissione di dati sensibili); distinguiamo due tecnologie lato end-user per accedere a sistemi HTTPS: un browser (accediamo, per esempio, ad un sito di e-commerce e facciamo il checkout in modalità protetta) oppure un’applicazione 3rd party (per esempio, lo stesso sito di e-commerce tramite un’app dedicata a smartphone/tablets).

    Bene: i browser non sono in discussione e non risentono dei problemi presentati nel paper. Invece, le libraries SSL (due nomi su tutti: OpenSSL e JSSE) che solitamente vengono utilizzate nei back-end o utilizzate dagli sviluppatori per costruire applicazioni che accedono a risorse tramite HTTPS soffrono di alcuni problemi che rendono l’intera comunicazione vulnerabile a diversi tipi di attacchi, come il famoso man-in-the-middle. In breve, il problema principale è il processo di validazione dei certificati SSL (solitamente: si risale la chain fino alla root CA). Se lato client non viene effettivamente fatta la validazione del certificato presentato dal server, il client è una facile preda! Questa non-validazione è causata da molteplici fattori:

    • pigrizia dei developers che, nell’utilizzare queste librerie, disabilitano controlli fondamentali durante la fase di sviluppo (perché si usano dei certificati self-signed) che poi dovrebbero essere riabilitati al go-live. Ma così non accade;
    • utilizzo sbagliato delle API che settano impostazioni non congruenti (setto il check per la verifica del certificato ma poi non ricordo/non so/non è specificato che devo leggere un’ulteriore return code per verificare se la validazione è andata a buon fine).

    Nel paper sono presenti alcuni esempi interessanti con tanto di codice reverse engineered.

    Quali sono i rimedi?

    • Come sviluppatori: configurare correttamente i parametri di validazione SSL della libreria che si usa, controllando anche i valori di ritorno della validazione se devono essere richiamati tramite un’ulteriore chiamata alle API della library utilizzata
    • Come sviluppatori: fare sempre un testing utilizzando certificati SSL non verificati.

    La lettura del paper è davvero molto interessante ed è vivamente consigliata per tutti quelli che hanno a che fare con lo sviluppo di applicazioni 3rd party che accedono a risorse esposte tramite HTTPS/SSL.

  • FizzBuzz reloaded: le differenze tra Java e Ruby

    Tempo fa vi ho parlato di FizzBuzz, un quiz spesso posto ai programmatori alle prime armi.

    Una variante è la seguente:

    Sommare tutti i numeri da 1 a 200 che non sono multipli di 4 e di 7

    La parte divertente sta nella differenza di espressività tra Java e Ruby per ottenere lo stesso risultato. In Java, infatti:

    public class FizzBuzzReloaded {
        public static void main(String[] args) {
            int sum = 0;
    
            for (int i = 1; i <= 200; i++) {
                if (i % 4 != 0 && i % 7 != 0) {
                                 sum += i;
                }
            }
            System.out.println(sum);
        }
    }
    

    In Ruby, invece, grazie alla funzionalità del linguaggio, possiamo semplicemente scrivere:

    (1..200).select {|n| n % 4 != 0 and n % 7 != 0}.inject(:+)