venerdì 21 dicembre 2012

PgDay.IT nel numero di Dicembre di BSD Magazine

Il numero di Dicembre di BSD Magazine riporta un mio breve riassunto dell'evento nazionale dedicato a PostgreSQL (PGDay 2012) organizzato dai componenti dell'associazione ITPUG assieme ad altri volontari ed appassionati.


mercoledì 28 novembre 2012

portsnap patch to use fetch (instead of wget)

I did some review to my micro portsnap patch, thanks also to the suggestion on the FreeBSD forums and -stable mailing list.
In particular, as someone pointed out, using wget(1) is not a good idea because it is not part of the base system and requires an admin to manually install it from ports or packages. That is not a big deal in my opinion, and it is the reason why I made a change so that it was possible to configure, using /etc/portsnap.conf, a way to specify that wget(1) was required. To make it even clearer, I also created a function check_downloader that is used to check the presence of the program executable used to download stuff (either phttpget or wget).
I was not fully happy with such patch, but I have not a better idea until someone on the -stable mailing list pointed out that FreeBSD (of course!) has already a downloader: fetch(1).
The problem with fetch(1) is that it requires a full URL while portsnap was internally dealing with clean server names.
So I reverted the patch in order to avoid using wget(1) and to use fetch(1) by means of a flag in /etc/portsnap.conf and introduced a new variable in the internal portsnap implementation, SERVER_PROTOCOL, that simply handles "http" in the case of the usage of fetch(1).
The patch has moved into another path within my repository and is available here.

martedì 27 novembre 2012

Do we really need UPDATE/DELETE with LIMIT?

Reading Planet PostgreSQL last day I found a strange poll about the need to place a LIMIT statement in an UPDATE/DELETE query.
My answer to such question is simply NO, and I placed also a comment on the blog of the proposing author, but I cannot find it anymore...
In order to better understand why I do not believe this feature is required, let's consider a sample query:

UPDATE accounts 
SET active = 'f' 
LIMIT 100;

The idea is to disable the first 100 accounts. This query is fully supported in MySQL.
What is clear to me is that such a query is defective by design: you are using a LIMIT statement on a wrong design of the data and or of the unique constraints on such data. 
The right way to do it is by using a WHERE statement that filters the data you are going to manipulate. While I see that LIMIT is a quick trick to do the job, it is the wrong one since it allows DBAs to implement data in any almost unstructered way being able to manipulate them later using a kind of indexing.
It is true, however, that such a scenario could be useful when importing and handling legacy data, that could come from other old systems and with wrong constraints, but once the database is fully reimplemented the need for such a feature is almost inutily in my opinion.

lunedì 26 novembre 2012

portsnap patch to use wget

portsnap is the tool used on FreeBSD to download the ports tree and to update it. Internally, portsnap uses phttpget to download the various files to work with. The problem of the latter is that it does not handle very well the http_proxy variable, that is set when behind an http proxy. Well, let's say, phttpget handles http_proxy very badly: when the http_proxy variable is in the form of

http_proxy="http://user:password@proxy:port"

the program does a very awkward parsing of the variable value getting the "password@proxy:port" as the proxy port, that is it gets confused by the colon within the string. This is of course very annoying and prevents the adoption of FreeBSD behind an http proxy. I searched by myself the solution for quite a lot, and finally I wrote a simple patch to portsnap to substitute the use of phttpget with wget, that handles normally the http_proxy variable.
The result is available on one of my git repositories and can be applied as follows (I suggest making a copy of portsnap into portsnap_wget):

cp /usr/bin/portsnap /usr/bin/portsnap_wget
patch -p0 /usr/bin/portsnap_wget portsnap_wget.diff

After that, and assuming of course that you have installed wget from either packages or ports, it is possible to use the portsnap_wget command as the usual portsnap to download updates either when behind a proxy or not:

portsnap_wget fetch update

With regard to the patch, it did not involved only changing the download program to wget, but also to change the definition of the files to download, that now are not passed via xargs but within a loop.

PgDay 2012: arrivederci all'anno prossimo!

La sesta edizione del PgDay italiano e' ormai alle spalle.
Come organizzatore sono soddisfatto del lavoro svolto: l'evento si e' rivelato ancora una volta all'altezza delle aspettative.
La qualita' tecnica degli interventi e' stata elevata, la partecipazione ampia (95 fra partecipanti e speaker) e l'attenzione ottima. Devo ammettere che, nonostante gli ottimi e inflessibili
chairs (moderatori), alcune sessioni hanno sforato leggermente per via delle molte domande a riprova della forte attenzione e interesse dei partecipanti per gli argomenti trattati.
Gli eventi sociali, nell'ordine una PgBeer, una PgBistecca (Fiorentina!) e una nuova PgBeer sono stati divertentissimi e l'atmosfera che si respirava era di amicizia e voglia di collaborazione.
Fa anche molto piacere che PostgreSQL si sta affermando sempre piu' come scelta aziendale e per le Pubbliche Amministrazioni, segno questo della maggiore consapevolezza della community italiana dell'alta qualita' di questo database enterprise.

La conferenza e' stata aperta da un keynote di Simon Riggs e Andres Fraud sulla multi-master replication, una feature che pian piano sta prendendo forma all'interno del codebase PostgreSQL, anche se ci vorranno ancora alcune release per poter sfruttare questa funzionalita' in produzione.
A seguire due sessioni parallele per 14 talk totali: una sala dedicata ai case studies e una dedicata ai tutorial.
Io ho svolto due tutorial introduttivi a PostgreSQL, anche se il tempo tiranno non mi ha permesso di far vedere tutte le fantastiche features del prodotto. Pazienza, le slide scaricabili presto dal sito dell'evento permetteranno alle persone interessate di approfondire.
Mio anche il discorso (breve) di chiusura lavori, mentre il presidente Gabriele ha fatto quello di apertura.

Molto graditi i gadget per i partecipanti: oltre alla classica penna blu con l'elefante, degli adesivi e depliant informativi sulla neo nata 9.2, anche una chiavetta USB bianca con elefante blu e necklace.

Insomma, come ogni anno, un bell'evento ormai tradizione del panorama italiano PostgreSQL, nonche' una bella occasione per rivedere colleghi e amici (e aggiungerne di nuovi!).

lunedì 19 novembre 2012

Computer History...

Something nice I found on Planet Gnome a few days ago:
 
In the beginning was the command line
The machines were full of null and void
And darkness covered the screens and the terminals
The fingers of the programmers moved upon the surface of the keyboards

And then Xerox said, Let there be mice: and there were mice
And Steve Jobs saw that the mice were good
He took the idea to the Lisa team, and later on to the Mac
They fancied themselves pirates, and even had a flag

Then Steve said, Let there be GUIs: and there were GUIs
And Bill Gates saw that the GUIs were good
DOS begat Windows and a new computing age was born
He licensed it to IBM and every other willing company

Then Bill said, Let there be a computer in every home
And there were computers in every home
And DARPA saw that the computers were good
They built & tested communication between UCLA and Stanford

Then DARPA said, let there be Internet: and there was Internet
And Tim Berners-Lee saw that the internet was good
He had the idea for linking documents and proposed hypertext
Then he connected it to TCP and domain name ideas

Then Tim said, let there be the web: and there was the web
And AltaVista saw that the web was good
The created a search engine and were bought by Yahoo
But along came a little startup named Google

Then Google said let there be PageRank: and there was PageRank
And all SEOs saw that the PageRank was good
Web 2.0 came along and Moore’s law was holding steadfast.
But a bubble was looming on the horizon

Then Steve looked at all that they had started
And he said, It is not good for Nokia to be alone
We shall make a competitor worthy of them

Then Steve said (again), Let there be iPhone: and there was iPhone
And Samsung saw that the iPhone was good
And the rest, as they say, is history

sabato 17 novembre 2012

Shell Script Trick: command

In molti dei miei shell scripts utilizzo delle variabili per memorizzare la posizione assolutadei comandi che lo script andra' ad eseguire, come ad esempio:


#!/bin/sh

PERL_CMD=`which perl`
SED_CMD=$( which sed )

...

if [ -z "$PERL_CMD" ]
then
   echo "Perl executable not found!"
   exit 1
fi

if [ -z "$SED_CMD" ]
then
   echo "Sed executable not found!"
    exit 1
fi

...


Come si puo' notare lo script controlla le proprie dipendenze andando a verificare che ogni variabile/comando sia correttamente valorizzata, altrimenti significa che lo script non ha trovato uno dei comandi (non builtin) richiesti e quindi non puo' procedre.
Questa procedura e' abbastanza laboriosa e ha un problema di performance: ad ogni invocazione di which viene aperto un sottoprocesso che si occupa di cercare il comando specificato.
Grazie ad alcuni suggerimenti ho scoperto un comando builtin, command, che verifica e restituisce il percorso assoluto di un comando senza bisogno di lanciare sotto-processi, quindi con ovvio aumento di performance. Sostanzialmente il comando command si
preoccupa di cercare un programma in ogni entry del $PATH. Il codice quindi diviene:


#!/bin/sh

PERL_CMD=`command perl`
SED_CMD=$( command sed )

...

if [ -z "$PERL_CMD" ]
then
   echo "Perl executable not found!"
   exit 1
fi

if [ -z "$SED_CMD" ]
then
   echo "Sed executable not found!"
   exit 1
fi

...

Sysadmin panics: Stupid Smoking Humble!

...oppure SSH, la differenza risiede solo nel fatto che i sysadmin in panico di cui racconto non hanno ancora capito cosa questo dono del progetto OpenBSD sia. Eh si, perche' loro, i sysadmin in panico, sono cresciuti nell'ovatta del Telnet e guardano con disgusto a questo "nuovo" modo di connessione remota in terminale. 

Sembra incredibile, ma ho conosciuto sysadmins che non avevano mai sentito parlare di X-forwarding, e che ogni volta che un accesso al terminale X era richiesto si alzavano dalla sedia per raggiungere la console. Ora il fatto che ci sia X in console e' un'altra storia; il punto nodale qui e' la mancanza di controllo. Va bene, se la console e' vicina (un'altra stanza? un altro piano?) si puo' anche fare, e due passi non possono che fare bene.  a se la console si trova in un altro edificio? In un'altra citta'? 

PuTTY ha fatto un gran servizio facendo approdare SSH anche sui client Microsoft Windows, ma ha sbagliato una cosa fondamentale permettendo, nella pura logica Windows, di memorizzare la password di  login. 
Come come? Un SSH client con la password pre-impostata? 
Ebbene si, ho assistito anche a queste  configurazioni, e a nulla e' valso il mio modesto tentativo di spiegare le chiavi SSH. 
Chiavi SSH?  
Perche' SSH va messo in moto come un auto? Gia', le chiavi SSH, grande mistero dell'universo dopo le donne!


Una volta mi venne chiesto come mai una connessione di copia (rsync) via SSH da un giorno all'altro aveva  niziato a chiedere la password.  Chissa', forse perche' qualcuno ha modificato le chiavi del server?  Addirittura una volta sono state rimosse le chiavi dell'utente per fare spazio (come le chiavi occupassero cosi'  anto spazio). 

E il file known_hosts? Che rottura: ogni volta che si aggiornano le chiavi di un server anche questo va modificato di conseguenza. Soluzione rapida del sysadmin in panico: cancellare il file! Ebbene si, perche' e'  piu' facile rispondere "yes" ad ogni nuovo host che deve essere memorizzato (nuovamente) piuttosto che  modificare una singola riga di un file di testo! E speriamo che nessuno abbia compromesso uno di quei server  a cui fingerprint dobbiamo nuovamente accettare. 

SSH fa del suo meglio, avvisando il sysadmin che "IT IS POSSIBLE THAT SOMEONE IS DOING  OMETHING NASTY!". 
Povero SSH, non sa che e' proprio il sysadmin a compromettere il sistema!

Emacs Buffer List: ibuffer

The buffer list (C-x C-b) is one of the features of Emacs that I use the most: I work with a lot of buffer and sometimes I get "lost" among them, so I need a quick place to see what I'm editing and quite frankly the buffers list does it well.
However the buffers list works opening a new buffer to allow the user to select the buffer to pop up again, and quite oddily it does not close the buffers list buffer (named "*Buffer List*") after the user has chosen the buffer to edit.
This means that users have to manually close the buffer list window, switching to the editing buffer. Moreover, when the buffer list opens it does not get the focus, so that the lifecycle of using the buffers list results in:
- C-x C-b
- C-x o to give the buffers list the focus
- n/p to move around the buffer entries
- [Enter] to select a buffer
- kill the buffer list (C-x 1 on the other window)

Since the above is quite annoying, I wrote a simple function to wrap the default buffer-list one so that at least it gets the focus automatically.


The function simply calls the original buffer-list and then advance to the next window, that in this case is always the buffer list itself.
However, this does not solve the problem of closing the buffers list window when done. Therefore, while searching the Web I found a more interesting function: ibuffer. Such function opens a more advanced buffers list that automatically get closed when a selection is done.
Therefore my .emacs file now has an entry to remap the C-x C-b key sequence to the ibuffer function:

(global-set-key (kbd "C-x C-b") 'ibuffer)

venerdì 16 novembre 2012

JFK and roles...

I imported the good work of my friend Claudio into JFK: such work allows experimentation of an idea about works that I slightly borrowed from Object Teams. There is still some clean up to be done, but a test case demonstrates the result.

Some work on Aglets after all!

I don't remember the last time I did some work on the Aglets platform, but in the last days something have moved. Thanks to the great work by Thomas, the platform is moving to a much more easy deployment. I took the chance to do a code clean up and to fix some annoying problems with the terrible AGLETS_HOME variable and file paths that were referring to it.

Daniel is free

According to the last message sent from his wife, Daniel is at home and fine:
 Thank God he came home well, and is now recovering, we appreciate all the help and support of you!
I don't know if the battle is over, but at least Daniel's nightmare is!

Update: as Daniel blogs, he spent 6 days in jails and can now be again together with his family since he is free. The trial is not over though, but one piece is done!

mercoledì 14 novembre 2012

Sysadmin panics: stranezze


chmod? chown!

Piu' volte ho visto l'uso di chmod al posto di chown.
Situazione: si vuole dare accesso ad un file o una directory ad un utente che non e' proprietario o non risulta
nel gruppo proprietario.
Cosa si fa quindi?
Un bel chmod 777 e si risolve il problema.
O se ne creano altri (di problemi)?
Eh si, perche' un chmod 777 implica dare anche il permesso di esecuzione a tutto il mondo. E' veramente questo che si vuole? Si vuole poter eseguire un file di testo (che magari viene inavvertitamente infettato e si  tramuta in uno script malevolo)? 
No, quello che si vuole e' zittire rapidamente l'utente dandogli l'accesso. 
La soluzione corretta e' quella di inserire l'utente nel gruppo giusto, facendo nel caso un chown del 
file/directory in modo da consentire la corretta profilazione. 
Se poi si e' dei virtuosi, le ACL possono aiutare!



crontab & chmod = chmod on steroids!

Si e' mai visto una linea in crontab del tipo:

* * * * * * chmod 777 /path/to/some/public/share/*


Io l'ho vista!
Cosa fa?
Modifica ogni minuto i permessi di ogni file in una cartella pubblica dando ogni permesso ad ogni possibile
utente del mondo. Si valuti se la configurazione della share e' quella desiderata e se veramente lo spool del
server debba essere usato come un keyboard-monkey!




Pippo, Pluto e Paperino


Come non sopporto la gente che continua a nominare i file come "pippo", oppure "pluto" oppure "paperino".
Alcuni studenti lasciano la loro home directory piena anche di file dai nomi ben piu' volgari, ma che un  sysadmin debba usare ancora nomi cosi' ridicoli per i propri file di configurazione e' una vergogna.  
Ma ancora peggio e' chi inserisce tali file in un sistema di controllo delle versioni: che senso ha memorizzare la storia di un file di nome pippo127.sh che, evidentemente, o non cambiera' mai (sara' sostituito da pippo128.sh) oppure cambiera' totalmente!


Cavi, label, diagrammi e mount point

Ovvero: siate ordinati, siate coerenti. Se un server dispone di piu' schede di rete, le si rinomini opportunamente e si etichettino i cavi e le prese. E possibilmente, quando si modifica qualcosa si tenga il sistema dei nomi aggiornato! E' frustrante cercare di capire come mai il firewall sta facendo passare il traffico  fra l'interfaccia WAN1 e DMZ indiscriminatamente solo per scoprire che la prima interfaccia e' stata riconfigurata per operare come LAN...
E a tal proposito, si scelgano dei mount point con nomi significativi: non serve a niente montare un device in rete come /mnt/storage, a meno che il dispositivo remoto non si chiami effettivamente "storage". Molto meglio codificare il nome del dispositivo, come ad esempio NAS_p1_s37 (NAS al primo piano nella stanza 37) e si usi un mount point opportuno come /mnt/NAS_p1_s37. Meglio ancora, si suddividano i mount point  per tipo e priorita', cosi' che gli script possano smontare o rimontare tutti i device agilmente come ad esempio /mnt/NAS/NAS_p1_s37.



Commenti da lasciare senza commenti!

Gran cosa i commenti: consentono al sysadmin di aggiungere delle annotazioni nei file di configurazione per  indicare perche' si sta facendo quello che si sta facendo. O almeno per esprimere al mondo quello che si vorrebbe fare (che poi ci si riesca e' un'altra cosa!). Ma i commenti sono utili solo se sono mirati, ossia se sono posizionati nel punto della configurazione alla quale il commento si riferisce. In altre parole, mettere dei commenti in cima ad un file specificando cosa si fa nel file in un punto imprecisato (tipicamente almeno una  videata sotto) e' totalmente inutile. E peggio ancora e' tenere la storia dei commenti nello stesso file: si usi un  sistema di controllo delle versioni per tenere traccia della storia evolutiva di un file.

martedì 13 novembre 2012

Help Daniel Nicoletti

I was reading the Planet KDE when some strange posts got my attention: someone was seeking for help for Daniel Nicoletti. Daniel is a KDE contributor, his last activities were on printing management and the Apper package kit. While moving to a KDE summit, he was arrested and is currently in jail.
To understand why it is required to give  a short story.
More than one year ago, his one year and half old daughter died in a car accident while the Nicoletti family was travelling in Argentina.
A few days ago, on November the 8th, while travelling to hackfest.cm, he was arrested by the Germany police and went to jail. In short, he has been sought by international police for the murder of his daughter.
I don't know the facts, but I suspect it is not Daniel's fault. I never met Daniel, even if he helped me on the KDE developers mailing list a few times.
This incident reports to my mind the Hans Reiser's one, just because two great developers have been marked as guilty.

As a father, I cannot image a nightmare worst than loosing your child and being convicted about that.

That is why I made my little donation hoping it can help finding the right resources to clarify the incident. Please consider doing the same.

Click here to lend your support to:  URGENT flights to go to the Brazilian Consulate in Munich and make a donation at www.pledgie.com !

lunedì 12 novembre 2012

Sysadmin panics: boot & mail

Almost (un)booting...


Capita che anche i server decidano di riavviarsi. Che si tratti di un panic, di mancanza di corrente (al punto da spegnere il gruppo di continuita') o di un problema hardware, il risultato piu' o meno e' lo stesso: il server deve fare un nuovo boot. 
Capita anche che il sysadmin in panico non abbia ben compreso la modalita' di boot della sua creatura, e magari confonda un System V per un BSD o viceversa. 
Ecco quindi script di boot mal configurati che montano cartelle di rete prima che il networking sia pronto. O peggio ancora, script di boot che bloccano completamente il boot chiedendo per password di root o altro. Vale la pena testare sempre l'ambiente di boot del proprio server...



Sendmail and Friends


Alcuni sysadmin ancora faticano a comprendere che sendmail non solo e' un demone di posta, ma e' anche un programma client che si collega ad un SMTP qualsiasi. Ne consegue che quest'ultimo puo'  essere usato per inviare e-mail automatiche anche attraverso SMTP differenti da Sendmail stesso!



Sendmail and Foes


Ormai tutti i server, di qualunque razza, inviano delle e-mail automatiche anche solo per notificare il syadmin di cosa sta succedendo. Ebbene, se la configurazione del demone di spedizione del server e' configurata opportunamente per fare il relay su un server MX di fiducia, per quale motivo ogni sysadmin pretende di installare il proprio mail client che richiede una differente  configurazione di relay? Si usi il "relay ufficiale" e si stia in pace con il mondo. Quando si cambiera' configurazione di posta ci si scordera'  di sicuro che il proprio client deve essere riconfigurato...

venerdì 9 novembre 2012

A bad example of blog article references

I found a quite interesting blog that has a few articles about Emacs, my favourite editor. However, I was disappointed to see that one of such articles was referring to a porno web site.
The article was showing an image of Emacs displaying, in turn, an image of a girl wearing a swimsuit, so nothing really scaring...
I thought she was a model. The article continued discussing how to enable Emacs loading and displaying multi media files, and assumed the user has a collection of the shown girl's video files. I was not aware of who the girl was (oh my!), but luckily the references at the end of the article provided a link to her official web site. As I wrote, I was thinking she was a model, and therefore I clicked the link and immediatly the traffic cop of my employeer blocked my web request.
Not so bad, commercial traffic cops usually get wrong on a lot of web sites and contents.
I totally forgot the incident and the web site.
After a few days, while surfing the web at home, I picked up again the Emacs article and therefore decided to click again on the above web site to discover who the miss really is. 
Well, she is a porn star!

Now I'm angry.
While using top model images is fine for me, I believe that using and redirecting readers to porn sites is totally wrong. Moreover, I don't want my employeer to record even a single click by myself against a porn site, and in fact I never browse sites that are not technical in nature when at work.

As readers can imagine, I'm not posting any backlink to the original article, neither I'm going to provide the name of the porn star here. 
What is really fun, is that I was thinking to collaborate with the blog author to make some more complete articles about Emacs.
Sorry pal, you loose an opportunity!


mercoledì 7 novembre 2012

GEOM naming

As far as I can understand reading the documentation and looking at the FreeBSD GEOM source tree, the naming scheme is as follows:
  • each transformation specification is written upper-case;
  • each transformation class is written lower-case;
  • each module that defines and implements a class lacks the initial g;
  • usually each device that is perceived as a provider uses the module name as a way of indicating the service, such has using an extension or being under a folder with the module name if the /dev directory;
  • each file in the above module has the g_ prefix, followed by the class name (lower-case) and an optional suffix with a leading underscore.
So for instance, in the case of the disk encryption we have that:
  • GELI (upper-case) specifies the transformation, that is the contract for the service;
  • geli (lower-case) is the class implementation, that is the code that implements the above contract;
  • eli is the module that contains the source code, that is the folder in the source tree;
  • eli is the extension of an encrypted device (e.g., /dev/da0s1e.eli);
  • each file in the above source tree is named g_eli with an optional suffix.
As another example consider the mirroring facilities:
  • GMIRROR is the transformation;
  • gmirror is the class implementation;
  • mirror is the module that contains the source code for the class implementation;
  • usually mirrors are under /dev/mirror;
  • each file is named g_mirror and something more.



Who is the best?

Stallman: "God told me I have programmed the best editor in the world!"

Thorvalds: "Well, God told me that I have programmed the best operating system in the world!"


Knuth: "Wait, wait - I never said that."

martedì 6 novembre 2012

Cosa significa softc?

In molti punti del codice kernel di FreeBSD; in particolare nelle implementazioni dei device drivers o dei moduli GEOM, si trova un argomento di funzione chiamato tipicamente softc. Tale nome, storicamente, indica il software control block, una sorta di identificatore universale per indicare "dati privati" al modulo software in esecuzione (ad es. un driver). Nel caso di device driver, il softc viene solitamente memorizzato nel campo si_drv1 della struttura cdev che rappresenta il device relativo.

sabato 3 novembre 2012

iedit: rename comodo in Emacs

Ho scoperto una estensione per Gnu Emacs veramente interessante: iedit.

L'idea e' quella di offrire lo stesso supporto dello strumento refactoring/rename che molti IDE offrono per le variabili di un linguaggio di programmazione. Sia chiaro, e' sempre possibile eseguire una ricerca (con o senza espressione regolare) e un replace accurato con gli strumenti base di Emacs, ma iedit offre veramente quel qualcosa in piu' che non fa sentire la mancanza di un IDE piu' complesso. E' sufficiente installare e caricare il file iedit.el e attivare il modo (impostando una combinazione di tasti o usando M-x iedit). All'attivazione il sistema controlla su che parola il cursore si trova e la evidenzia, evidenziando anche tutte le occorrenze della stessaparola all'interno del buffer; e' quindi possibile editare la parola stessa e si vedranno le modifiche apportate alle altre occorrenze dinamicamente. Per terminare l'editazione e' sufficiente uscire dal modo iedit (M-x iedit o premere nuovamente il key binding stabilito). 
Veramente impressionante!




venerdì 2 novembre 2012

FreeDOS

Nostalgia del vecchio sistema operativo e del suo prompt c:\> ?
E' possibile installare FreeDOS, una versione "libera" del sistema operativo di casa Microsoft. Il sistema presenta anche la possibilita' di una serie di strumenti di rete piu' evoluti rispetto alla versione originale.
Non ho resistito all'idea e mi sono preparato una macchina virtuale!
















Linux & C. dove sei?.

Ero un affezionato lettore di Linux & C., una delle riviste storiche nel panorama Linux nazionale.
Dico ero perché l'ultimo numero uscito quest anno, il 76, è datato Aprile 2012, ossia piu' di 6 mesi fa. Il numero precedente, il 75, è di Dicembre 2011, quindi fra gli ultimi due numeri sono passati circa 3-4 mesi.
Evidentemente io e la redazione abbiamo un differente concetto di mensile.

giovedì 1 novembre 2012

SmartOS


SmartOS è un sistema operativo basato sul kernel del defunto OpenSolaris. E' bene fare un po' di chiarezza: SmartOS non è il nuovo OpenSolaris (come qualcuno ad una conferenza lo ha definito). Il nuovo OpenSolaris, o meglio il suo erede, si chiama OpenIndiana (sempre ammesso che abbia senso parlare dell'erede di OpenSolaris!). SmartOS è un sistema basato sul progetto IllumOS che tiene vivo il kernel dell'allora OpenSolaris dopo che Oracle ha pensato bene di trucidare un progetto così promettente.
Ad ogni modo, il progetto SmartOS sembra promettente e l'azienda che lo gestisce ha assunto buona parte degli ingegneri di Sun che Oracle ha smarrito. Vale quindi la pena osservare l'evoluzione di tale sistema.

Sysadmin panics: gestione

Qualche altro racconto, mano a mano che mi tornano alla mente, sulle sventure dei sysadmin.

Mannaggia a 'sto LDAP!
Ebbene si, mi sono sentito rivolgere anche questa domanda da un sysadmin impavido (e impertinente): "ma a cosa server tutto 'sto LDAP?". Lo ammetto, la gestione LDAP è sicuramente piu' complessa di quella plain, ma è sicuramente migliore di quella NIS (si, mi è capitato di dover gestire anche questo). Inoltre molti dei tools LDAP sono buggati e non funzionano benissimo, cosa che complica ancora di piu' la gestione di molti account. Tuttavia, proprio perché gli account sono molti, si pensi al tempo risparmiato per impostare con un unico account i livelli di accesso a diversi servizi (storage, condivisione file, terminali interattivi, chat, ...).

Tutti 'sti gruppi?
Continuando sulla falsa riga del precedente paragrafo, non si sia avidi nel creare gruppi di utenti: servono per la profilazione e possono essere molto utili. Quindi invece di continuare a creare gli utenti nel gruppo users o peggio ancora in quello staff (perché almeno voglio sperare che nessuno usi wheel), si definiscano dei gruppi per ogni tipologia di applicazione/servizio.

 rc, questo sconosciuto
Capita di trovare sysadmin incompetenti anche fra il personale docente dell'università, a volte addirittura fra i docenti di Unix! E così alla domanda "ma che cosa significano quelle string RC all'inizio di un file?" ci si può sentire rispondere un semplice "non lo so, mai capito e mai usato". Ah, che bella invenzione il controllo delle versioni dei file di configurazione!

Sysadmin panics: aggiornamenti

Gli aggiornamenti sono qualcosa che ogni sysadmin vorrebbe evitare come la peste, ma che purtroppo vanno tenuti in considerazione.

Aggiornamenti in produzione
E' inevitabile, prima o poi i server di produzione devono essere aggiornati. Le procedure di aggiornamento di molti sistemi oggi semplificano la vita ai sysadmin, fin troppo. Capita allora che qualcuno decida di fare a tappeto un aggiornamento del tipo yes-yes-confirm di un server in produzione a pieno carico di lavoro.
Si, so che può sembrare assurdo, ma l'ho visto dal vivo!
Cosa può succedere di male? Che qualche configurazioni non faccia piu' partire alcuni demoni! 
Risultato: server quasi inusabile. 
Backup? No! 
Piano di recovery? No!  
Buona fortuna!

Sindrome del reject-update
Ovvero  tutto quello che non c'è non si rompe!
Gli aggiornamenti sono importanti: risolvono bug, aumentano la sicurezza, aumentano (in genere) le prestazioni. Possibile che ci sia ancora chi pensa che non si possa aggiornare un sistema perché c'è troppo lavoro di configurazione? Ho visto procedure stagnare per colpa di demoni non aggiornati. Ci si domandi se non si è sbagliato a rendere la configurazione così version-dependent e si abbia il coraggio di riprogettare. Nel lungo periodo questa scelta pagherà di piu' e il monte ore risparmiato sarà maggiore di quello speso ad aggiornare.


RTFM!
Ammetto che questo capita anche a me, ma solitamente solo sul mio computer e non su sistemi in produzione. Si legga sempre cosa si sta aggiornando, e se tale aggiornamento rompe una qualche compatibilità e si valuti cosa fare. Ci si prepari comunque al peggio.

martedì 30 ottobre 2012

To be Linux or not

Il team di OpenBSD si è sempre distinto per creatività e serietà.
Ogni release del sistema operativo viene corredato da una canzone e da artwork relativo al "tema" di sviluppo della release stessa. E il tema per la 5.2 è la compatibilità POSIX.
Si sta infatti affermando sempre di piu' il fenomeno di essere Linux-compliant invece che POSIX-compliant. Peggio ancora, perfino POSIX sta iniziando a piegarsi a certi Linux-ismi.
Il fenomeno si è già abbondantemente mostrato con Gnome, almeno nella mia opinione: Gnome si è legato fortemente alla struttura di Linux tanto da rendere i port per le altre piattaformi molto difficili. Il fatto che Linux si sia così diffuso rende il fenomeno ancora piu' incontrollabile: Linux si sta affermando come uno standard de-facto sopra a standard che esso stesso ha perseguito. Di fatto si sta verificando quello che Microsoft stesso ha generato: un sistema che pone monopolio sulla base della sua diffusione. 
Ma non finisce qui: si assiste ormai da tempo alla scrittura di codice legato ad una particolare distribuzione Linux, rendendo quindi il software stesso non portabile per definizione.


lunedì 29 ottobre 2012

Sysadmin panics: maestra non sono stato io!

(ovvero Bikeshed on steroids!)

Grande invenzione le e-mail! Consentono di raggiungere tantissime persone alla distanza di un solo click. E proprio per questa semplicità la maggior parte delle persone, ivi inclusi certi sysadmin che ho avuto il (dubbio) piacere di conoscere, vengono usate in modo errato.

Situazione: un utente notifica il sysadmin di un problema tecnico. Non importa quale sia il problema nello specifico: potrebbe essere un demone fermo, un servizio malfunzionante, un problema di autenticazione o di profilazione, insomma, qualunque cosa di competenza del sysadmin. Ora, piu' o meno diligentemente il sysadmin verifica quanto detto dall'utente e realizza che non c'è nulla che non funzioni nei sistemi segnalati. Il guasto è quindi apparente e forse causato da un erroneo utilizzo dell'utente. 
Bene, cortesia vuole che il sysadmin risponda all'utente informandolo della non riscontrata anomalia. Questo basterebbe a chiudere il caso con buona pace di entrambe le parti.
Eppure un sysadmin dubbioso delle proprie capacità, per paura forse di essere crocifisso in sala mensa come nella classica tradizione di Fantozzi, si affretta a mandare risposta all'utente mettendo in copia anche i propri superiori.
Il dialogo quindi appare come segue:

From: utente generico
To: sysadmin di fiducia
Subject: Malfunzionamento?
Caro sysadmin,
oggi non sono riuscito ad usare/accedere/fruire del servizio/processo/procedura XYZ. Per favore, puoi controllare se qualcosa non sta funzionando a dovere?


From: sysadmin di fiducia
To: utente generico
Cc: superiore 1, superiore 2, capo supremo, god
Subject: Re: Malfunzionamento?

Caro utente,
non ho riscontrato alcun malfunzionamento. I servizi funzionano ogni giorno, ogni ora, ogni minuto nello stesso modo e con regolarità. L'errore deve essere tuo, per favore controlla di aver seguito la procedura di utilizzo in tua dotazione.

Quante volte ho assistito a dialoghi del genere, e forse parecchi anni fa sono caduto anche io (nel ruolo di sysadmin) in una simile trappola.
Cosa c'è che non va?
Il fatto che il sysadmin invii la comunicazione anche a dei superiori.
Quali superiori?
Beh, bisogna distinguere: se sono superiori del sysadmin, dell'utente generico o di entrambi.
Si consideri il primo caso (superiori del sysadmin): in questo caso il sysadmin sta gridando maestra non sono stato io!, ovvero sta cercando di dimostrare attraverso un semplice dialogo con l'utente finale di aver fatto tutto quanto in suo potere per garantire il funzionamento del sistema. L'effetto finale però è che l'utente percepisce l'insicurezza del sysadmin, che ha bisogno non solo di confermare quanto pensa, ma di confermarlo anche ai suoi superiori. Una sorta di "guardate quanto sono diligente".
Si consideri ora il secondo caso (superiori dell'utente generico): in questo caso il sysadmin sta comunicando qualcosa che suona come "oh, questo utente mi sta seccando, si lamenta di cose che non esistono". Il risultato finale è che l'utente non si fiderà piu' del sysadmin, visto che viene preso a pesci in faccia con una comunicazione riservata resa pubblica allo scopo di tentare una umiliazione.

Ma non è finita qui: in entrambi i casi i superiori in questione vengono tirati in ballo in una conversazione privata fra due parti (sysadmin e utente) della quale probabilmente non vogliono e/o non hanno interesse ad essere informati (altrimenti lo sarebbero stati fin dalla prima e-mail). Si consideri il tempo che una persona impiega per leggere la mail di cui sopra, pari a 1 minuto (incluso il tempo per fare click sul messaggio). Si sommi la distrazione del superiore, che viene gettato in una conversazione mentre era impegnato a fare altro. Si moltiplichi tale tempo per il numero di persone in Cc nella e-mail: si ottiene l'ammontare del tempo che il sysadmin, di sua iniziativa, ha deciso che l'azienda e le persone devono sprecare con una sterile polemica.

E comunque non siamo ancora arrivati al peggio.
Mi è capitato personalmente, qualche anno fa, di inviare una comunicazione confidenziale sul malfunzionamento di un server amministrato da un altro sysadmin. Questi mi ha risposto mettendo in Cc un terzo sysadmin cercando di fargli prendere non solo parte alla discussione, ma indirizzandolo verso lo schieramento a suo favore.

Soluzione al problema?
Francamente non ne ho. Posso solo consigliare tutti i sysadmin e, in generale, tutti gli utenti, di riflettere prima di inviare una e-mail: esiste veramente la necessità di coinvolgere le persone nella discussione o lo si sta facendo solo per acquisire sicurezza?


domenica 28 ottobre 2012

Linux Day 2012: un gran evento!

Ho partecipato con piacere al Linux Day 2012 a Modena, organizzato dal LUG Conoscere Linux e dai suoi membri attivi e molto in gamba. Non posso che esprimere parere piu' che positivo circa l'evento, organizzato in modo impeccabile con attrezzature e strutture all'altezza, e con la accoglienza e professionalità del LUG di Modena.
L'evento si è svolto presso il dipartimento di Fisica dell'Università di Modena e Reggio Emilia, all'interno della famosa aula G (ora rinominata L1.1), adatta ad ospitare la buona affluenza di pubblico che questo Linux Day ha avuto. Come ho già detto le attrezzature messe a disposizione erano piu' che adeguate, con musica di sottofondo, proiettori e microfoni e un pannello laterale che mostrava tweet e post in diretta. Al piano inferiore era stata allestita la reception e una sessione interattiva per Asterisk (oggetto di uno dei talk della giornata). Un plauso particolare agli organizzatori per essere riusciti a rispettare con grande precisione il programma della giornata, cosa solitamente difficile perché gli speaker tendono sempre a rubare minuti l'uno all'altro (me compreso!).
IL livello tecnico degli interventi è stato ottimo: la sessione del pomeriggio in particolare ha presentato diversi progetti interessanti relativi a virtualizzazione, VoIP, costruzione di server domestici, ecc. La sessione del mattino è stata invece maggiormente improntata sugli aspetti culturali dell'Open Source e del diritto di autore, anche se non posso esprimermi appieno poiché non sono riuscito a presenziare ad ogni intervento.

Durante la sessione del pomeriggio io ho tenuto un talk introduttivo su PostgreSQL, che ha sollecitato la curiosità di diversi partecipanti che mi hanno posto diverse domande alla fine del talk e della giornata. Per problemi di tempo ho mostrato solo alcune delle feature di PostgreSQL, con particolare riferimento alla server side programming e alla replica, ma senza poter scendere in particolari dettagli. Ovviamente la parte iniziale del mio talk non poteva esimersi dal presentare il progetto, la sua storia e la sua cultura, fattori tutti determinanti per una buona adozione di questo strumento. Alla fine del talk mi è anche stato fatto gradito omaggio del pinguino d'oro, premio del Comune di Modena dato anche a tutti gli speaker invitati all'evento. Farà una bella figura sulla mia scrivania in ufficio.

Infine qualche critica la devo fare, non verso l'evento, ma verso alcuni degli speaker stessi. Sia chiaro, si parla di opinioni personali, ma quando sento uno speaker che parla di diritti di autore e che usa Twitter o di un altro che indica come Facebook sia una delle responsabilità di un buon reparto IT mi si drizzano i peli anche in posti che non sta bene scrivere! 

Ad ogni modo, un ringraziamento particolare agli amici di Conosce Linux che mi hanno ospitato e che hanno organizzato un ottimo evento.
Conitnuate così!

Sysadmin panics: dischi, questi sconosciuti!

Qualche altro episodio esilarante dalla mia esperienza con alcuni sysadmin di dubbio talento!

fsck /your/rw/filesystem
Una delle cose che francamente considero assodate è che un filesystem montato in lettura/scrittura non dovrebbe mai essere passato a nessun tool diagnostico, inscluo fsck. Eppure c'è chi, insospettito da strani comportamenti (non errori!) del proprio filesystem decide di lanciare a tappeto un fsck su ogni file system montato su un server di produzione. Buona fortuna!

 Quando i dischi spariscono....
Le moderne implementazioni di gestione dell'hardware (es. devfs) consentono al sistema di rimuovere o aggiungere i nodi sotto a /dev dinamicamente. Questo significa che se un disco si rompe improvvisamente, e quindi "sparisce" dal sistema, il suo nodo in /dev verrà anch'esso rimosso appena possibile. Ora, non importa quante volte l'amministratore nel panico lanci fsck /dev/missing o fdisk /dev/missing, il disco non tornerà ad apparire. Si prenda atto del fatto che il sistema molto spesso è piu' robusto della mente del sysadmin stesso!

Il partizionamento, questo sconosciuto
Questo mi ricorda un po' il problema dell'inserimento degli account utenti a mano: se si deve "clonare" esattamente la tabella delle partizioni di un disco, non serve copiarla a mano da uno all'altro. Esistono infatti appositi strumenti, come fdisk, che possono fare il lavoro sporco per noi, risultando anche piu' precisi di quello che non saremmo stati. Quindi per cortesia, non fatemi assistere nuovamente a scene di sysadmin che copiano una ad una le partizioni da un disco (o almeno se proprio devo assistervi, almeno che le partizioni siano non piu' di due!).

Il RAID, questo sconosciuto
Grande invenzione il RAID, anche se a volta il suo omonimo insetticida annebbia la mente del sysadmin di turno. Per prima cosa si deve sempre avere chiaro se si parla di RAID software o hardware, e che relazioni ci sono perché ovviamente i due sono stackable. In entrambi i casi però è bene tenere presente che nessuno dei due tipi di RAID è automagico: sostituire un disco rotto e sperare che questo sia partizionato, sincronizzato e messo on-line automaticamente è utopia. Almeno, non ho ancora incontrato un server o un OS che faccia questo. Meglio quindi leggere attentamente la documentazione del RAID in questione. E meglio ancora, si studi il RAID e i suoi livelli, per capire anche come le varie partizioni o i vari dischi devono essere assemblati.

UUID, questo sconosciuto
Se un server inizia a dare errori su una partizione abcdef22a78cd18..... o qualcosa di simile, si provi a costruire la tabella degli UUID dei propri dischi e si controlli che cosa il server tenta di montare. C'è un qualche identificativo sbagliato (ad esempio perché un disco è stato sostituito).  

 

sabato 27 ottobre 2012

Sysadmin panics: sicurezza

Ed ecco come si comportati alcuni dei sysadmin disastrosi che ho conosciuto riguardo alla sicurezza.

Root? Sempre e comunque!
Ho assistito piu' volte a sysadmin che pur di voler mostrare la loro capacità nell'eseguire operazioni remote sui loro server via SSH (come che fosse una gran difficoltà!) non hanno esistato a collegarsi direttamente come root ai server remoti da computer assolutamente non fidati di aule corsi o addirittura da computer di altre persone. E se maliziosamente qualcuno avesse impostato un keylogger?

Ma tanto gli utenti non sanno usare SSH
Diversi anni fa mi trovai a svolgere dei compiti di manutenzione su un server di posta elettronica gestito da una software house esterna. Notai con ribrezzo che tutti gli account utente usati per la posta elettronica avevano abilitato il login. Non solo, la loro shell di login era bash, che per definizione è insicura specialmente in connessioni remote (si pensi a .bash_profile o perggio a .bashrc). Ovviamente ho fatto presente l'errore di configurazione, dovuto al fatto che comandi come useradd e simili, pensando che l'utente sia interattivo, propongo in default una shell di login. Tuttavia mi è stato risposto che, poiché gli utenti che usavano le caselle di posta non erano abbastanza smaliziati da usare anche SSH, non c'era nessun rischio di sicurezza. Devo commentare?
Ad ogni modo, il server in questione venne penetrato, con notevole disservizio. Parecchi anni dopo, la software house in questione continuava ad installare server di posta con utenti abilitati al login da ogni host remoto....

Aggiornamenti? Quando cambiamo il server!
 Gli aggiornamenti software si sa, possono essere problematici e difficilmente sono indolore. Tuttavia, almeno sul fronte della sicurezza, vanno fatti regolarmente seguendo gli advisor dei vari servizi e OS. Non tutti sono propensi agli aggiornamenti, seguendo il principio che quello che funziona non va toccato o si rischia di romperlo. Il principio è vero: se si ha un vaso di cristallo in equilibrio sopra ad un cornicione conviene non toccarlo, o si rischia di farlo cadere. Ma è anche vero che si potrebbe riuscire a metterlo in salvo da un eventuale terremoto. Insomma, io sono propenso a fare gli aggiornamenti il prima possibile e con tutto il lavoro necessario affinché i servizi siano sempre in ordine.
Inutile dire che molti sysadmin non la pensano così, e infatti piu' volte ho dovuto discutere per poter fare aggiornamenti di servizi vecchi di anni. E molto spesso la risposta che ho avuto è stata che le versioni nuove andavano installate con i nuovi server hardware, ovvero visto che all'acquisto di una macchina si deve "spendere" tempo per installare un sistema, quel tempo lo si sarebbe impiegato per installare un sistema aggiornato, risparmiando quindi il tempo "inutile" di aggiornamenti successivi. Inutile commentare oltre.

Password dei servizi
Ho visto così tante password di servizi e demoni impostate tutte uguali a valori noti che mi sono stancato dell'argomento e non intendo nemmeno commentarlo!

Impostare la propria password pensando alla propria banca
Si, un sysadmin impostò una password di amministratore scaduta secondo lo schema delle password della propria banca sostenendo che non era sicuro di poter usare alcuni caratteri perché nel login della sua banca non erano permessi. Se sembra senza senso, è vero. E ancora devo capire cosa mi volesse dire il sysadmin in questione!

Condivisioni, backup e tutto di tutti!
Uno dei miei primi lavori seri fu impostare dei livelli di sicurezza su delle condivisioni di file che risultavano di fatto accessibili a tutti gli utenti indiscriminatamente. E infatti spesso un utente cancellava i file di un altro utente senza motivo. 
Perfino le copie di backup erano "parcheggiate" su condivisioni accessibili a tutti gli utenti. A cosa serve quindi profilare gli utenti se poi chiunque può portarsi a casa l'intero set di dati dell'azienda?

Backup del capo? Totalmente insicuro!
Situazione: il capo chiede al suo sysadmin fidato di fargli una copia di backup dei dati del suo computer (posta e documenti). Il sysadmin ha fretta, quindi decide di posizionare il backup in uno storage di rete. Peccato che scelga una posizione accessibile a tutti gli utenti (si veda il paragrafo precedente). Poco male, visto che il backup viene fatto fuori dall'orario di lavoro, quando i dipendenti di fatto non hanno accesso fisico allo storage. Ben piu' grave è lasciare il backup in suddetta posizione per oltre un mese. 
    
     
  

 

venerdì 19 ottobre 2012

[Mailing List | Forum]-ize yourself!

This could sound weird from me, having been a fan of mailing lists up to almost one year ago. Nowadays I believe much more in technical forums rather than other collaborative spaces.
First of all allow me to explain the need: you are developing/mantaining a piece of code and you get a problem that cannot resolve, so you need for assistance. I'm not going to discuss here the types of support and assistance you can get by proprietary or open source software, I'm supposing you are alone and without any support contract by anyone.
In the programming space there are different ways of getting supports, mainly:
  • IRC (Internet Relay Chat)
  • Mailing Lists
  • Forums
  • Social Networks
Since I'm not a fan of social networks, in any forms they could come, I discourage you to use them as a way of getting support. Consider that social networks are very dynamic, high traffic and easy to confuse readers, so it is quite difficult someone will note your help request in the ocean of messages that flow thru the social network.
IRC is an old fashion way of chatting, and is very respected in the Unix and Unix-related environments. The idea is to have a virtual room that hosts people that discuss about a specific subject. One room means one subject, users do not have to register anywhere, can gain access to server quite easily and can access more rooms at once. My experience is that traffic can become quickly really high or you could fly to a room without any (interested) guest, so your question is going to be dropped and forgotten in the room. Moreover, room logs could not be saved, so even if someone helped you the answer could not be stored somewhere and you could be unable to access the answer again. Usually IRC is used to synchronize committers and developers and to make virtual meetings, but getting help thru it is in my opinion very difficult. Moreover you are required to stay connected for a while, so it requires you to have access to the Internet (even if the required bandwidth is not that much). These are the main reasons why I don't like IRC very much.
As already stated, I was a fan of mailing lists. Mailing lists are channels to which users have to register in order to receive mails. Then users can drop an email to this channel (that is nothing more than a special e-mail address) and all other users registered to such channel will get the mail into their inbox. It is easy to use, it is safe (email travel as pure text), you are sending a message to anyone who is registered (so chances are someone will read your message) and have to just wait for a reply. Moreover, configuring a right set of filter will allow you to manage a ton of e-mail easily. Last but not least you are getting a reply from a valid user behin a valid e-mail address, so you can contact such user directly. This is wrong since you should try to keep the knowledge on the mailing list, so that it is shared and is not something private, but gives you the chance to directly connect to someone else.
Forums are something very popular, that I start used when working behind a stupid firewall blocking my mailing list accounts. Forums can be very good if they provide very technical and constrained topics and if the moderators are doing their job. Moreover, I found that forums that gives you badges as indicators of how much/how often/with which quality you do the forum are attracting developers and committers, that usually are proud of their public image compared to other people. Another aspect of forums is that they tend to be less traffic bloomed than mailing lists, and therefore are the good place for mid-to-advanced users.
To recap, I suggest you to use forums and mailing lists as often as possible and in the correct way: please specify always the system and properties of the context you are working on, the problem you have, the solution you have tried, and any other detail that can help people solving your problem. Remember that on any channel people are volunteers that are donating their free time to you. The best you can do, is to make sure you are not wasting their time!

PGDay 2012: on-line il programma dell'evento

E' disponibile il programma del PGDay 2012 che si svolgerà il 23 Novembre a Prato, nella sede storica di questo evento diventato ormai tradizione nella comunità nazionale (e internazionale) di PostgreSQL.

sabato 13 ottobre 2012

Sysadmin panics...per ridere un po'!

Nel mio lavoro ho conosciuto degli amministratori di sistema, o presunti tali, di un po' tutte le razze. Qualche giorno fa ricordavo, assieme ad un mio amico, alcuni degli episodi piu' divertenti che mi sono capitati lavorando con alcuni sysadmin di dubbia competenza.

Liberare spazio su disco? Fai un reboot!
Una volta un sysadmin si mostrò stupito del fatto che, nonostante avesse forzato un reboot di un server (con ovvio downtime della macchina) lo spazio disco non fosse aumentato. Io francamente mi sarei stupito del contrario! In effetti, tralasciando /tmp (che dovrebbe essere sempre montato a parte), che potrebbe essere pulito da un qualche job allo shutdown o all'avvio, o potrebbe anche essere un filesystem di memoria, non vedo per quale motivo un reboot dovrebbe pulire dei file dal disco. E in effetti se fosse così i nostri dati sarebbero in forte pericolo! Inoltre, anche ammettendo che un processo impazzito stia riempendo log su log, i dati scritti dovrebbero essere persistenti (concetto forse sconosciuto al sysadmin in questione), e quindi il reboot della macchina potrebbe solo avere l'effetto di fermare il processo impazzito (e far impazzire gli utenti nel mentre che la macchina si arresta!).

Account scaduti? Si ricreano a mano!
Un requisito secondo me fondamentale di un sysadmin è la capacità di automatizzare i task ripetitivi. Non importa molto con quale tecnologia e linguaggio, sia Bourne Shell, sia Perl, sia Python, sia Groovy, la cosa fondamentale è che si sia in grado di far fare alle macchine le cose piu' ripetitive e noiose. Eppure ancora ci sono persone che si fanno pagare per il tempo che perdono a inserire manualmente dei dati. Capitò allora che una serie di oltre cento account fossero stati disabilitati per un bug. Ebbene conosco un sysadmin che si è messo in un cantuccio ad inserire, una ad una, le password degli utenti (il fatto che si sappiano le password è un'altra questione...). Se si considera che ogni password va inserita due volte, considerando anche qualche errore di battitura, si capisce benissimo l'ammontare del tempo perso, ovviamente a carico del cliente.
Il primo programma Perl che scrissi per la generazione e manutenzione di grosse moli di account risale al 2003, lo usavo per gestire alcuni laboratori all'università. Nel 2006 ne scrissi uno per un provider di posta, e nel caso di cui sopra, mosso a compassione, ne scrissi uno in meno di 20 minuti per ripristinare tutti gli account disabilitati.   

Router? Gateway? Sono solo numeri!
Ho assistito in diretta al blocco di un intero segmento di rete causato da un sysadmin forse un po' troppo frettoloso che decise di dare un indirizzo IP pubblico al proprio computer per testare la connettività. Peccato che si diede l'indirizzo IP del router, causando un "panico" sul gateway e facendo si che il proprio computer si trasformasse in una sorta di sniffer del poveraccio!

giovedì 11 ottobre 2012

My private library (a part of it)

A part of my computer science collection of books (yes, I've read all of them at least twice!).
If you are interested in a particular book, please drop me an e-mail.


The book that changed my (developer) life

It is "Programming Perl", by Larry Wall and Randal Schwartz. It changed my developer life for two main reasons.
The first reason is that I read the ugly and horrible italian translation, and I found so many errors, typos and code mistakes that learning Perl became a real adventure with such a book. Therefore, it changed my life because it was the book that made me switch to English only tech books. They are the most up-to-date and do not contain silly translation errors.

The second reason is that it showed me how beauty and nice programming can be. It was not tied to Perl itself, but the way the authors were expressing the language. They were showing to the world how they loved programming, how fun can be to automate tasks and to administer complex systems.
Today I appreciate only books by authors that can show me how beauty a technology is, and not those authors that try to simply explain how to use it. I can read the manpages for that!