[...] The Unix philosophy (like successful folk traditions in other engineering disciplines) is bottom-up, not top-down. It is pragmatic and grounded in experience. It is not to be found in official methods and standards, but rather in the implicit half-reflexive knowledge, the expertise that the Unix culture transmits. It encourages a sense of proportion and skepticism — and shows both by having a sense of (often subversive) humor.

Doug McIlroy, the inventor of Unix pipes and one of the founders of the Unix tradition, had this to say at the time:

(i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.

(ii) Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.

(iii) Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.

(iv) Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.

He later summarized it this way (quoted in A Quarter Century of Unix):

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

Sto pensando alla scena di Idiocracy dove l’addetto all’infermeria non sa che pulsante pigiare per un mal di testa.

Mi piace continuare a pensare che i flussi di testo siano ancora un’interfaccia universale e utile per tutti, non solo per i programmi.

I mailclient (mutt, thunderbird, outlook) operano in maniere differenti, a seconda del fatto che sappiano parlare direttamente il protocollo SMTP o no. Di sicuro gli MTA sanno parlare l’SMTP, ma non aiutano gli utenti finali a scrivere le mail.
Mentre un client come thunderbird parla direttamente i protocolli necessari con l’MTA remoto, uno come mutt si limita a “impostare” la mail, e poi la consegna ad un MTA locale che la dovrebbe consegnare al mailserver che fa da ponte con il resto del mondo.
(Nota: Attualmente anche mutt ha il supporto SMTP (dalla ver. 1.5.x), ma c’è chi dice sia una bestemmia usarlo per questo. Nel caso interessi, guardare le FAQ e settare le variabili smtp_* (ie: smtp_url) SENZA l’account name – che si incarta.)

Ogni box unix ha un MTA locale – la sua natura di stazione multi-utente fa si che gli utenti della box abbiano la possibilità di comunicare fra di loro come default.
Le debian installano autonomamente la versione light di exim con una configurazione che permette di inviare e ricevere mail localmente.
Nel caso sia necessario configurare senza troppe pretese l’exim-light per permettere all’MTA locale di comunicare con l’MTA sul mailserver della lan, si può usare:

# dpkg-reconfigure exim4-config

sfruttando come smarthost il mailserver di cui sopra.

La nuova versione di FreeBSD è la 7.1; fare il CD di boot e installarla è stato banale.
Ho deciso di completare un’installazione minima (senza pacchetti), per poi personalizzarla ed esplorarla a modo in un secondo tempo.

Giusto per iniziare bene, ho scagliato l’appartenenza ai gruppi – se si vuole che un normal user possa diventare root, meglio appartenere al gruppo wheel.

In generale, # sysinstall è il comando sempre pronto a dare una mano: sysinstall -> Configure -> Distribution -> man per esempio.
I sorgenti del kernel sono accattabili attraverso sysinstall in Configure -> Distribution -> src -> sys, e serve “base” per avere il Makefile e altre cose utili sul fs.

Visto che ci sono altre cose su quel sito meritevoli di nota, e poichè mi sono ritrovato a cascarci sopra per caso… lo risegnalo in tutto il suo splendore:

The Grymoire – a web site containing a collection of useful incatations for wizards, be you computer wizards, magicians, or whatever.
La parte Unix.

Era troppo fantasy per non segnalarlo per bene…
Mi ha ricordato tanto i bei vecchi tempi di Rolemaster. :-/

Il Network File System (NFS per gli amici) ebbe origine quando la condivisione di drive non era comune come oggi (in ambiente Win): questo fs permette di condividere spazio nell’hdd di un grande server con molti piccoli client.
Un esempio tipico è quello di un server centrale che detiene le home dei singoli utenti sul suo hdd locale, ma le condivide tramite NFS (quindi i client montano in effetti le home degli utenti dal server, e non sfruttano quelle sulle proprie macchine).

Dal mio punto di vista “casalingo” NFS può risultare molto utile per concedere un po’ di spazio a box che non ne hanno tanto, e magari per tenere certi dati del client su box di cui mi fido di più. Il bello è che essendo partizioni montate, il client è convinto di operare sul suo hdd, che in realtà è virtuale: di fatto il client salva i dati sul server.

Fase (1)

La procedura di installazione di NFS si svolge su due fronti, ovviamente:

• Su client è necessario installare nfs-common e portmap.
  

  radon:# apt-get install nfs-common portmap
  Reading package lists… Done
  Building dependency tree
  Reading state information… Done
  nfs-common is already the newest version.
  portmap is already the newest version.
  0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

• Sul server:
  

  idrogeno:# apt-get install nfs-kernel-server nfs-common portmap
  Se tutto va bene si conclude con:
  [...]
  Setting up nfs-kernel-server (1:1.1.2-6) …
  Creating config file /etc/exports with new version
  Creating config file /etc/default/nfs-kernel-server with new version
  Starting NFS common utilities: statd.
  Exporting directories for NFS kernel daemon….
  Starting NFS kernel daemon: nfsd mountd.

(A onor del vero, di solito sono già installati nelle distro.)

Fase (2)

Se l’installazione dei programmi è avanzata senza intoppi, è necessario editare sul server il file /etc/exports con una riga come la seguente:

/home/sim/nfs_radon 192.168.0.3(rw,no_root_squash)

Questa riga indica che i contenuti della dir /home/sim/nfs_radon del server verranno condivisi con l’IP 192.168.0.3 con determinate condizioni indicate fra parentesi. Se si vuole che la dir sia condivisa da altri IP, si possono aggiungere a destra separati da uno spazio da quello precedente (fra parentesi servono le opzioni per ogni singolo client, o gruppo di client).
A questo punto sul server si rende effettiva la condivisione dando il comando:

idrogeno:# exportfs -a
exportfs: /etc/exports [1]: Neither ’subtree_check’ or ‘no_subtree_check’ specified for export “192.168.0.3:/home/sim/nfs_radon”.
Assuming default behaviour (‘no_subtree_check’).
NOTE: this default has changed since nfs-utils version 1.0.x

A questo punto server-side siamo a posto.

Fase (3)

Ora bisogna lavorare client-side, e dobbiamo dire alle box di montare la partizione condivisa NFS come fosse una partizione qualsiasi.
Il modo più semplice e diretto è usare mount indicandogli la dir remota sul server e il mount point locale:

radon:# mount 192.168.0.1:/home/sim/nfs_radon /mnt/nfs

Se per caso nella dir locale vi erano dei file o altro, questi non verranno cancellati ma la dir remota si sovrapporrà a quella locale nascondendone il reale contenuto fino al prossimo umount.
Ovviamente è anche possibile montare la dir NFS in automatico all’avvio del client, con il solito /etc/fstab. Una riga come questa abiliterà il mount:

/home/user> cat /etc/fstab
# /etc/fstab — static file system information

#<device>	<mountpoint>	<fstype>	<options>	<dbg>	<pass>
/dev/sda1	/	ext2	defaults	0	0
proc	/proc	proc	rw	0	0
192.168.0.1:/home/sim/nfs_radon	/mnt/nfs	nfs	rw,nodev,nosuid	0	0

A questo punto, il gioco è fatto: la dir del server è condivisa col client.

La guida di Debianhelp, che ho trovato molto utile e comoda.
Il Linux NFS-HOWTO.

Name	Flags	Part Type	FS Type	[Label]	Size (MB)
sda1		Primary	Linux ext3		60003.42
sda2	Boot	Primary	Linux ext3	[idrogeno]	98999.48
sda3		Primary	Linux swap / Solaris		1036.39

Ma cos’è la swap partition?
Una utile guida mi viene in aiuto: Linux Partition HOWTO, di Anthony Lissot version 3.5, 30 Nov 2005, (basata sulla guida di Kristian Koehntopp del 1997)

Ogni processo funzionante sul nostro computer è localizzato in un numero di blocchi nella RAM. Questi blocchi sono chiamati pages. Il set di istruzioni che andrà presto in uso è detto working set; Linux prova a predire questi accessi alla memoria (assumendo che le pages usate di recente siano usate anche nel prossimo futuro) e tiene queste pages nella RAM, se possibile.

In Linux, RAM e spazio swap si sommano (non è vero per tutti gli Unix). In sostanza: 256 Mb di RAM + 256 Mb di swap fanno un totale di 512 Mb di memoria virtuale.

Se ci sono troppi processi avviati sulla box, il kernel tenterà di liberare RAM scrivendo le pages sul disco: questa è la ragione per cui esiste lo spazio di swap; in effetti esso incrementa l’ammontare di memoria disponibile – è necessario comunque ricordare che l’I/O del disco è centinaia di volte più lento della RAM. (Insomma, la memoria è di emergenza, e non un’extra.)

Se la memoria diventa così scarsa che il kernel va a leggere i processi (working set) sul disco, la box comincia a rallentare enormemente e il disco viene letto in maniera molto insistente.

Starting Nmap 4.53 ( http://insecure.org ) at 2008-02-08 21:54 CET

Interesting ports on idrogeno (192.168.0.1):
Running: Linux 2.6.X
OS details: Linux 2.6.22 – 2.6.23
Uptime: 6.947 days (since Fri Feb  1 23:10:31 2008)
Network Distance: 0 hops

Interesting ports on [elio] 192.168.0.2:
Running: Microsoft Windows XP
OS details: Microsoft Windows XP SP2
Network Distance: 1 hop

Interesting ports on [radon] 192.168.0.3:
Running: FreeBSD 6.X
OS details: FreeBSD 6.2-STABLE – 6.3-PRERELEASE
Uptime: 0.009 days (since Fri Feb  8 21:42:34 2008)
Network Distance: 1 hop

Nmap done: 256 IP addresses (3 hosts up) scanned in 24.720 seconds