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.

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.

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!).

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

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)

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!

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.

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.

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...

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!

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."

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.

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!

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.

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.