Ceci n'est pas une pipe

Questa è stata una settimana molto, molto dura… ma non posso certo permettere che si concluda senza avere messo online almeno una piccola, miserabile, insignificante tip! Quindi, per fare le cose al volo, vi dico come effettuo la sincronizzazione di un sito Internet che ho elaborato in locale con la copia che è pubblicata nella directory di un certo spazio FTP.

Premetto che questo non è il modo in cui lavoro normalmente: da buon figlio degli anni ’70 io modifico il codice direttamente online, non in produzione, ma online (bash). Questa settimana mi è capitato però di dover mettere mano al sito Internet di un cliente che ha messo a mia disposizione solo ed esclusivamente il suo account FTP. Quindi ho cominciato a sviluppare una copia locale del suo sito internet e tengo sincronizzata la versione online con un solo, semplice, meraviglioso comando:

lftp -u 'username,password' ftp.mydomain.com -e "set ftp:ssl-protect-data true;mirror --reverse /home/ivan/test test; exit;"

In altre parole:

• username: il nome utente dell’account FTP
• password: la password associata al nome utente dell’account FTP
• ftp.mydomain.com: la host dell’account FTP
• /home/ivan/test: la cartella locale (senza slash finale)
• test: la cartella remota (ovvero quella dove si trova pubblicato il sito Internet)

Da notare l’opzione “set ftp:ssl-protect-data true” che protegge l’autenticazione FTP mediante ssl e l’opzione “mirror –reverse” che permette di sincronizzare in upload anziché in download.

Inutile dire che con lo stesso comando si può mantenere un backup remoto di una directory locale, anche se per cose di questo tipo è consigliabile l’utilizzo di `rsync` che fa tutto attraverso una connessione `ssh`.

Niente di più, niente di meno. Buon week end!

Mi capita spesso di dover spostare in massa una grande quantità di file accomunati da una porzione del nome (quasi sempre l’estensione). Ecco la riga di codice che utilizzo in bash per ottenere – ad esempio – lo spostamento di tutti i file con estensione .gz contenuti nella directory corrente (comprese tutte le subdirectory in essa contenute) nella directory target che si chiama /tmp/prova:

find . -type f -name "*.gz" -exec mv {} /tmp/prova \;

Il progetto Ksplice ha un obbiettivo più che ambizioso: integrare in un sistema operativo Linux un layer che permetta di applicare aggiornamenti di sicurezza al kernel senza dover riavviare il sistema.

Per chi non abbia dimestichezza con i sistemi UNIX-like, va detto che riavviare un server (o anche un PC) ad ogni installazione di software non è una cosa normale, credetemi… Sui server di alcuni miei clienti il reboot è stato effettuato oltre un anno fa e tutto fila più che liscio, com’è giusto che sia. Ci sono rare situazioni in cui, però, riavviare il server è obbligatorio ed una di queste è proprio l’installazione di patch che riguardano il kernel. Ebbene, sul sito Internet del MIT c’è da tempo una pagina che promette di rendere superfluo il reboot anche in caso di modifiche sostanziali al kernel Linux!

I sistemisti dell’università americana stanno testando Ksplice dal 2005. I risultati sono impressionanti: il software è riuscito ad applicare automaticamente l’84% delle 50 patch principali rilasciate durante questo lasso di tempo. Ksplice è stato testato su differenti distribuzioni sia a 32 che a 64 bit a partire dal kernel 2.6.8 fino all’ultimissimo 2.6.25, chi volesse può trovare maggiori informazioni sul sito del Massachusetts Institute of Technology, a questo indirizzo:

http://web.mit.edu/ksplice/

Sun ha finalmente deciso di aprire tutto il codice Java, ma proprio tutto, anche quelle porzioni che ha tenuto sino all’ultimo completamente inaccessibili alla community. La versione open source del framework di sviluppo Java si chiama OpenJDK e il suo uso sarà completamente regolato dalla licenza GPL.

A momento in cui scrivo restano ancora fuori gran parte delle librerie per cifratura, grafica, audio e gestione SNMP. Non è cosa da poco, ma il team di Sun sta lavorando per portare a termine il lavoro. La principale conseguenza sarà la riammissione di Java in tutte le distribuzioni GNU/Linux, ora osteggiata a causa della precedente licenza del Java Community Process, incompatibile con la GPL.

Gli obbiettivi di Sun sono gli stessi di tutte le grandi software house che si sono recentemente convertite alla filosofia open: catturare il maggior numero possibile di sviluppatori open source, contrastando così l’avanzata degli altri linguaggi runtime. Una battaglia che fa senz’altro bene anche alla community e alla filosofia che la governa.