In questa sezione vengono riportate esperienze di amministrazione su reti composte da sistemi misti.
In breve: questo documento spiega come recuperare i dati contenuti sul disco fisso dopo la distruzione della tabella delle partizioni. L'ho scritto perche` mi e` veramente successo, e un po' per scommessa e un po' perche` non avevo nessuna voglia di perdere definitivamente i miei dati, ho rimesso a posto il mio disco con una operazione di chirurgia del software e ho deciso che, visto il successo della stessa, la mia esperienza potrebbe tornare utile a qualcuno (soprattutto considerando il numero sempre crescente di dischi distrutti dal Virus 98).
mount -t vfat /dev/hdb6 /mnt, e... Bad superblock!
less -f /dev/hda1si vede nè più nè meno che il reale contenuto del disco. È così che ho scoperto che tutte le partizioni DOS iniziano con la stringa esadecimale EB xx 90 4D (dove xx cambia da disco in disco, ma non so precisamente che cosa rappresenti), quindi non resta che dare il seguente comando ed attendere pazientemente i risultati:
cat /dev/hdb | dump -z | grep "eb.. 904d"che non significa altro che: "leggi il contenuto del file /dev/hdb, passalo dump che lo legge da standard input e lo converte in esadecimale, e mostrami le linee che contengono la stringa 'eb(seguito da 2 caratteri qualunque) 904d'". Dopo alcuni attimi infatti viene fuori una serie di numeri che indica fra l'altro anche dove questa stringa è stata trovata. Perfetto! Moltiplichiamo l'indice di riga per 16 (nella mia versione di dump i numeri sono indici di righe di 16 byte ma sulla vostra potrebbe essere diversamente), dividiamolo per 512 (la dimensione di un settore del disco), creiamo con fdisk una partizione che parte da quel settore e finisca un po' oltre le dimensioni che le avevamo assegnato (lo sapete quanto sono grandi le vostre partizioni, vero?), ed ecco recuperata la nostra prima partizione! È vero! Montatela se non ci credete! Il guaio è che dump è terribilmente lento, ed è limitato a file di 256 MB di dimensioni (infatti non credo che fosse stato progettato per l'uso che ne ho fatto io), ed è qui che viene in aiuto fsgrab, che serve a leggere i dati "grezzi" dall'hard disk a partire da una posizione specificata dall'utente. Sapendo le dimensioni approssimative delle partizioni, è possibile iniziare la ricerca a partire da un certo posto nell'intorno dell'inizio della seconda partizione. Supponendo che la vostra partizione iniziasse al 250mo MB, questo è il comando:
fsgrab -b 1 -s 261095424 -c 5000000 /dev/hdb | dump -z | grep "eb.. 904d"Sono partito deliberatamente 1 MB più indietro per non rischiare di partire più avanti, e prima o poi, a seconda della CPU che avete a bordo (perchè il collo di bottiglia è dump) vi verrà fuori il numero di linea in cui è stata trovata la stringa. Se fate in modo che la posizione di partenza di fsgrab sia un multiplo di 512 e la riga, opportunamente moltiplicata per 16, è ancora un multiplo di 512, avete il 99% di probabilità di aver trovato l'inizio di un'altra partizione. Segnatevi la riga, moltiplicate per 16, sommate al punto di partenza, dividete per 512 e avrete il settore d'inizio della seconda partizione. Due parole di riguardo andrebbero spese a proposito delle partizioni estese: quando trovate la seconda partizione, non mettetela come unità logica in una partizione estesa perchè credo (anche se non ne ho le prove certe) che il creare un'unità logica implichi il creare una seconda tabella delle partizioni nel bel mezzo del disco, che andrebbe a distruggere dei dati! Se avete "quasi" beccato il punto d'inizio ma siete finiti un po' troppo avanti, potreste anche distruggere la FAT, e allora il filesystem sarebbe proprio da buttare (se qualcuno mi può chiarire questo dubbio, può gentilmente mandarmi un e-mail?). Piuttosto, fatene una partizione primaria (la cui mappa di allocazione si trova sicuramente all'inizio del disco) perchè tanto per Linux non è un problema, o ancora più saggiamente, se avete un po' di spazio su un altro disco, provate a "estrarre" su un file con fsgrab i primi 5 o 6 MB della partizione e montatela come loop-device: in questo modo è impossibile far danni perchè state lavorando su una copia. In ogni caso, montate e pregate.
Introduzione
------------
- Ancora un HowTo?!
- Sì, perchè no?
Qmail è un server di posta per sistemi Unix abbastanza particolare: i suoi pregi sono una buona sicurezza, dato che non gira come root, un'estrema compattezza, e una configurabilità tutto sommato abbastanza flessibile e facile, una volta che se ne è capito il meccanismo (che però è abbastanza diverso dagli altri server, almeno da quanto ho potuto constatare). L'intento di questo mini-howto è quello di spiegare a grandi linee il funzionamento e la configurazione di qmail in modo da mettere in funzione un server "domestico" in grado di mandare la posta su Internet su richiesta. Ho deciso di scriverlo perchè la documentazione del programma dice poco o niente a riguardo di questa configurazione particolare, e l'howto che avevo trovato quando ho messo in funzione il /mio/ server era molto poco chiaro e mi ha fatto sudare parecchio prima di ottenere una configurazione funzionante. Cercherò quindi di essere il più chiaro e sintetico possibile, in modo che chiunque possa avere il proprio serverino funzionante entro pochi minuti. Ovviamente non è mia intenzione spiegare tutti i segreti di qmail... anche perchè non li conosco. (-: Per questo c'è l'ottima documentazione a corredo.
Avvertenza
------------
Proprio perchè non sono un esperto e questo documento è alla sua primissima stesura, ovviamente è aperto a qualunque correzione, chiarimento o aggiunto.
Convenzioni
------------
In questo testo, i comandi da dare sono indentati di 4 spazi, e preceduti da "#" se sono dati come utente root, oppure da "$" altrimenti. Il contenuto dei file è invece preceduto e seguito da una riga di "=", che non vanno inclusi nei file.
Installazione
------------
Purtroppo l'ultima installazione che ho fatto di qmail risale alla notte dei tempi (segno che se non altro funziona bene!), quindi non sarò precisissimo. Ricordo comunque che la compilazione non aveva posto nessun problema, ma ci sono un paio di cose a cui stare attenti *prima* di lanciare il gcc: qmail gira con 5 o 6 processi diversi, con compiti specifici e uid e gid diversi, quindi prima di compilare occorre verificare quali siano questi uid e gid, e inserirli nei propri /etc/passwd e /etc/group. Dopo la compilazione, non si potranno più cambiare (del resto non ce ne sarebbe motivo).
qmail è distribuito con una licenza particolare che ne impedisce la distribuzione in forma binaria, per cui i sorgenti andranno comunque compilati. Una volta ottenuti i binari, li si può installare quante volte si vuole su macchine diverse, ma *non* si possono distribuire!
Nella mia distribuzione Debian 2.1 "slink", gli uid e gid sono già presenti di default, e non andrebbero cambiati, visto che anche il pacchetto Debian con i sorgenti è configurato sugli stessi valori. Beh, se siete a caccia di problemi cambiateli pure... (-: Su altre distribuzioni, penso che sia più o meno "idem con patate". Nel mio caso, gli identificatori sono questi:
(da /etc/passwd) ======================================== qmaild:x:71:65534:qmail daemon:/var/qmail:/bin/sh qmails:x:72:70:qmail send:/var/qmail:/bin/sh qmailr:x:73:70:qmail remote:/var/qmail:/bin/sh qmailq:x:74:70:qmail queue:/var/qmail:/bin/sh qmaill:x:75:65534:qmail log:/var/qmail:/bin/sh qmailp:x:76:65534:qmail pw:/var/qmail:/bin/sh ======================================== (da /etc/group) ======================================== qmail:x:70: ========================================
So che nel pacchetto qmail originale gli uid sono diversi, infatti ho dovuto ricompilare passando dalla Slackware alla Debian, comunque l'importante è che siano consistenti tra i database di sistema e i sorgenti.
Detto questo, possiamo compilare e installare con i soliti "make" e "make install".
Configurazione
------------
Dopo l'installazione, se tutto è andato bene, la "home" di qmail (/var/qmail) dovrebbe contenere almeno queste directory:
alias/ bin/ boot/ control/ doc/
In Debian, bin/ è posta per la maggior parte sotto /usr/sbin e non è presente sotto /var/qmail, perciò se non la vedete, non preoccupatevi. (-: Veniamo al dunque: la prima cosa da fare è far sì che il nostro server sappia come si chiama. Entriamo in control/ (d'ora in poi lavoreremo in questa directory salvo indicazione contraria), e con il nostro editor del cuore (io sono un fan di vim, perciò lo userò nei miei esempi... che gli utenti di emacs non si offendano (-: ), editiamo il file "me", e ci mettiamo il nome completo (host + dominio) del nostro server. Nel mio caso:
# vim me ======================================== phoenix.radiance.it ========================================
Dopo di che, dobbiamo dire al server quali indirizzi deve considerare locali, ovvero, per metterla in termini semplici, il nostro server deve capire, all'arrivo di un messaggio, se deve spedirlo da qualche altra parte oppure se deve "atterrare" sul suo disco. (-: Il file "locals" serve a questo scopo.
# vim locals ======================================== localhost phoenix.radiance.it radiance.it localhost.radiance.it ========================================
I primi due nomi sono abbastanza ovvi, ma il terzo e il quarto meritano una spiegazione: il terzo serve a far sì che gli e-mail con @radiance.it vengano accettati, altrimenti vengono rifiutati o spediti da qualche altra parte, a seconda di altre impostazioni di cui per ora non ci interessa occuparci -- ad ogni modo, è bene mettere la terza riga solo se il server che stiamo configurando è il MX principale del nostro dominio. Il quarto invece serve a far sì che anche se qmail aggiunge da solo il dominio "radiance.it", i messaggi arrivino lo stesso (questa modifica l'ho portata in un secondo momento: ringrazio Stefano Giunchi per aver evidenziato il problema). In seguito, dobbiamo stabilire una regola simile per la posta in uscita, ovvero, decidere come vogliamo che i nostri destinatari vedano l'indirizzo del nostro server. Per questo, usiamo il file "defaulthost".
# vim defaulthost ======================================== phoenix.radiance.it ========================================
Così facendo, i nostri e-mail arriveranno a nome di @phoenix.radiance.it. Se avessimo messo "radiance.it", naturalmente arriverebbero come @radiance.it... chiaro, no?
La cosa vale anche per quando mandiamo a qualcuno un e-mail specificando solo lo username e non l'host: se lo mandiamo a , arriverà a @phoenix.radiance.it.
Il file "defaultdomain" ha una funzione simile, ma serve a definire il dominio di default, ovvero, a poter specificare una macchina diversa dalla nostra (ma nello stesso nostro dominio) nel campo "destinatario" del nostro e-mail. Per esempio, se dò come indirizzo "@penguin", qmail capirà che deve mandare il messaggio a @penguin.radiance.it. Quindi, in sostanza e per tagliare corto:
# vim defaultdomain ======================================== radiance.it ========================================
C'è da dire che io, in "defaulthost" sul mio server principale, ho messo "radiance.it", in modo che la posta esca come @radiance.it, il che mi sembra molto più carino che non @penguin.radiance.it. Questione di gusti, comunque. Tanto, se siete come la maggioranza dei comuni mortali, non avete una rete su cui scambiare posta, ma vi interessa solo mandarla su Internet, quindi di questo dettaglio estetico non ve ne importa tendenzialmente un fico secco. ;-)
Già che ci siamo, parliamo anche di "rcpthosts": questo file serve a stabilire i destinatari per i quali vogliamo ricevere dei messaggi sul nostro server... Ok, non si capisce, allora faccio due esempi tipici ed opposti:
Visto lo scopo che ci siamo prefissati, di nuovo per farla breve:
# rm -f rcpthosts... tanto per andare sul sicuro. (-:
Bene, a questo punto, se avessimo dovuto configurare un host su Internet saremmo a posto, ma purtroppo qui finisce la parte semplice e iniziano le "gabole" per rendere qmail adatto ai nostri scopi. Per fortuna, non sono molto difficili da mettere in pratica. (-:
Mappatura degli alias (aka gabole)
-----------------------------
Qui viene il bello. (-: Dobbiamo far corrispondere gli indirizzi che hanno senso sulla nostra rete (il nostro host è in rete con sè stesso) con gli indirizzi che hanno senso su Internet, e inoltre dobbiamo mettere in funzione una coda che trattiene i messaggi indefinitamente fino a quando ci colleghiamo. Per portare a termine questi due compiti ingrati, ci viene in aiuto il meccanismo di aliasing di qmail. Il concetto di fondo non è immediato da afferrare, però fortunatamente il funzionamento è semplice e lineare, per cui con un pò di esperimenti si riesce a capire...
Partiamo subito con un esempio: la chiave di tutto sono il file "control/virtualdomains", e la directory "alias/".
Diciamo che il mio indirizzo su Internet è goofy@disneyland.com (col CAVOLO che scrivo il mio indirizzo vero su un testo che posto su it.comp.linux!), e che il mio account locale è invece luciano@phoenix.radiance.it (questo invece è quello vero, perchè tanto non mi possono spammare).
Dobbiamo fare in modo che:
Possono sembrare problematiche di natura diversa, ma il bello di qmail è che si risolvono tutte allo stesso modo. (-:
Un'occhiata al mio "virtualdomains" (sempre sotto /var/qmail/control) chiarirà molte cose e offrirà anche uno spunto in seguito...
# vim virtualdomains ======================================== :alias-outside goofy@disneyland.com:alias-phoenix .radiance.it: radiance.it: ========================================
La sintassi di questo file è semplicissima: la parte a sinistra dei due punti indica l'indirizzo a cui mandiamo un e-mail, e la parte a destra indica a chi va reindirizzato. Se non c'è scritto niente prima o dopo i due punti, si intende il valore di default. In questo caso, le prime due righe significano:
Il che mi permette di mandare la posta a penguin.radiance.it e rawpower.radiance.it direttamente, senza passare dalla coda. La quarta riga ha la sua ragion d'essere nel fatto che penguin.radiance.it è il MX principale della mia rete, e si riconosce anche come "radiance.it", perciò se mando un mail a @radiance.it, sarà instradato verso penguin.radiance.it.
Ora vediamo come definire gli alias... Anche qui, il concetto non è immediato da afferrare, ma è di nuovo semplice e lineare. Cambiamo contesto, e ora entriamo nella directory /var/qmail/alias, che è tra l'altro la home dell'utente alias.
Innanzi tutto, incominciamo a creare la directory della coda, poi procederemo con la teoria.
# su - alias $ maildirmake outbound
E` *importantissimo* dare il comando "su - alias" per agire a nome dell'utente alias, altrimenti tutto l'accrocchio *non* funzionerà. D'ora in poi, agiremo solo come utente alias salvo indicazione contraria. Ho chiamato la directory "outbound" per chiarire che non c'entra con "outside": potete sostituire questi nomi come meglio vi pare.
Ogni utente può definirsi un numero arbitrario di alias, che però devono incominciare con il suo username seguito da un "-". Per metterli in funzione, basta mettere nella propria home un file denominato ".qmail-", seguito dal nome dell'alias, che contiene una o più regole per trattare il messaggio spedito a quell'alias. Un file che termina in "default" prenderà in considerazione tutti i messaggi il cui destinatario inizia con la parte precedente al "default" stesso.
Nel caso generico, mettiamo che io, con login "luciano", abbia nella mia home un file ".qmail-forward", in tal caso è possibile mandare un messaggio a luciano-forward@phoenix.radiance.it. Il destino di quel messaggio sarà deciso dal contenuto di quel file, ma ora che il meccanismo dovrebbe essere più o meno chiaro (spero), torniamo all'utente alias.
Facciamo un esempio pratico: la "coda" è rappresentata, negli esempi che abbiamo fatto finora, dall'alias "alias-outside". Nella home dell'utente alias, quindi, andremo a mettere un ".qmail-outside-default", che prenderà tutti i messaggi spediti a un qualunque indirizzo che inizia con "alias-outside-" (se non vi è chiaro perchè, cercate di mettere bene a fuoco i due paragrafi precedenti). (-:
Spediamo un messaggio a un indirizzo che non compare nei virtualdomains: verrà "preso" dalla prima riga (quella di default), e inoltrato a alias-outside. L'utente alias ha un .qmail-outside-default, che "prenderà" il messaggio. Vediamo come è fatto questo file, che guarda caso ha una sintassi semplicissima... (-:
$ vim .qmail-outside-default ======================================== ./outbound/ ========================================
Lo slash finale significa che la destinazione è una maildir (ovvero: una directory con un file per messaggio) e *va messo assolutamente*: se lo si omette, si intende una mailbox, e di nuovo l'accrocchio non funziona. Quindi, i messaggi, di default, finiranno lì dentro. Mitico, proprio quello che ci serviva. (-:
Ora, facciamo in modo che i messaggi per gli indirizzi "remoti", se spediti in locale, non facciano il giro su Internet per poi tornare allo stesso posto... Ci vorrà un alias per ogni utente che ha un indirizzo su Internet, e la sintassi è ovviamente la stessa per tutti.
$ vim .qmail-phoenix-goofy ======================================== &luciano@phoenix.radiance.it ========================================
La "&" significa: "reindirizza il messaggio a". Chiaro, no? (-: Mando un messaggio a "goofy@disneyland.com", alias me lo acchiappa e lo spedisce al mio indirizzo locale, /senza/ andare su Internet. Ripetere il tutto per ogni utente per il quale sia necessario.
Gli utenti che vorranno mandare posta su Internet dovranno far sì che nelle intestazioni degli e-mail da loro spediti compaia il loro indirizzo su Internet anzichè quello locale. L'operazione è abbastanza semplice, ma richiede la cooperazione degli utenti (doh!). Si tratta di impostare alcune variabili dalla shell, che sono:
$ export MAILUSER="goofy" $ export MAILHOST="disneyland.com" $ export MAILNAME="Goofy" $ export QMAILINJECT="f"
Il che farà sì che i messaggi arrivino con indirizzo del mittente "goofy@disneyland.com", e nome del mittente "Goofy". Se gli utenti sono piuttosto utonti, si può comunque sempre automatizzare tutto con uno script richiamato da /etc/profile, che legga un file di configurazione.
Okay, ci siamo quasi... Ora vediamo come spedire i messaggi dalla coda su Internet. Per fare ciò occorre un programma del pacchetto "serialmail", che dovrebbe trovarsi sullo stesso sito di qmail, o almeno credo. (-: Lo si compila e lo si installa nel solito modo (non c'è niente da configurare), dopo di che... abracadabra...
# su - alias $ maildirsmtp ~alias/outbound/ alias-outside-
dove:
Ecco fatto: con un pò di fortuna i messaggi in uscita dovrebbero essere stati spediti. (-: Un ultimo accorgimento che suggerirei, ma che non so quanto sia valido dal punto di vista della sicurezza, è quello di rendere maildirsmtp di proprietà dell'utente alias e poi impostare a 1 il suo bit di suid. In questo modo ci si risparmia la noia di diventare root ogni volta e poi di "impersonare" alias, e tutti gli utenti (anche quelli che non conoscono la password di root) possono mandare la posta quando meglio credono.
Bene, direi che se non ci sono domande, questo mini-mica-tanto-howto è finito. Quando avrò un pò di tempo andrò a cercare nei meandri del mio hard-disk l'autore dell'howto a cui mi sono ispirato e lo metterò nei ringraziamenti, ma per ora si è fatto tardi, ho due occhi come due cocomeri e concludo qui questa prima "edizione" alpha. Commenti e suggerimenti sono ovviamente i benvenuti.
Cercherò in questa sede di documentare alcune delle modifiche che abbiamo portato a una distribuzione standard Debian, in modo da evidenziare gli accorgimenti da attuare per integrare un server Linux in una rete basata su Microsoft Windows NT e tramandarli ai posteri, visto che non è un'operazione completamente scontata come potrebbe sembrare. Il primo problema che abbiamo dovuto affrontare è quello di dove mettere i dati degli utenti. Le possibilità erano:
Ovviamente abbiamo optato per la terza soluzione, ma ci sono state alcune difficoltà, previste e non.
La prima differenza rispetto a un sistema Linux in una rete Unix risiede nel diverso metodo di autenticazione degli utenti. In una rete Unix si usa generalmente il protocollo NFS, basato esclusivamente sulla fiducia tra il file server e pochi altri host. Ciò significa che solitamente gli host a cui gli utenti si collegano montano il ramo /home del file server sul loro ramo /home, il database degli utenti (/etc/passwd) è condiviso con quello del file server, e uid e gid degli utenti sono uguali per tutte le macchine. Inutile dire che questo modo di procedere è estremamente brutto, poco sicuro, e difficile da gestire. In una rete NT, invece, dal momento che le stazioni di lavoro sono dei PC e non dei "dumb terminals" o delle stazioni X, il modello di sicurezza è completamente diverso, molto più capillare che non nel caso di Unix, e ovviamente incompatibile con Linux. Ciò significa, in particolare, che a meno di usare software particolari, non si può stabilire nessun rapporto di fiducia tra la macchina Linux e il file server NT, e in particolare che la macchina Linux è vista come un client qualunque. Agli utenti della macchina Linux saranno quindi richieste due autenticazioni: prima quella per accedere a Linux, poi quella per accedere ai propri dati personali sul server NT. A questo punto, però, ci troviamo di fronte a un potenziale buco di sicurezza: dal momento che tutti gli utenti del sistema Linux usano di fatto la stessa macchina, sul filesystem del server Linux saranno montate tutte le home degli utenti, con l'autenticazione fornita dagli utenti, ma con i permessi di accesso assegnati dal sistema Linux. In pratica, ogni utente ha pieno accesso ai propri dati personali, i quali però sono protetti esclusivamente dal sistema Linux, in quanto NT "vede" Linux come tanti client collegati contemporaneamente dalla stessa macchina. È quindi di fondamentale importanza assegnare dei permessi molto restrittivi ai file (per esempio permesso di scrittura solo all'utente, e di lettura al massimo a un gruppo), dal momento che SMBFS non supporta i permessi di NT e assegna gli stessi permessi a tutto lo share importato, sottodirectory comprese. (È da notare però che SMBFS non ha alcun modo di "scavalcare" i permessi assegnati da NT, poichè viene visto come un client). Si noti, infine, che se NT permettesse la multi-utenza, le problematiche di sicurezza sarebbero simili. Poste queste premesse, abbiamo fatto del nostro meglio per ridurre al minimo l'intervento manuale degli utenti, mettere una pezza alle suddette problematiche di sicurezza e in genere addolcire la pillola dell'ambiente Unix a chi è costretto ad usarlo per esigenze didattiche: io sono un sostenitore ad oltranza dell'interfaccia a linea di comando (ho scritto questa pagina inserendo le tag HTML a mano come mia consuetudine), ma molti non la pensano come me.
La prima modifica essenziale è stata quella di introdurre negli script di login un'opzione per distinguere tra un utente "normale" e un utente "con la home su NT", facendo sì che l'unica cosa che l'utente debba fare sia inserire la password di NT (non si poteva assolutamente fare altrimenti senza compromettere la sicurezza del sistema). Il modo più semplice da noi ideato è quello di mettere tutte le home NT in /home/nt-users così che lo script di avvio capisca con una semplice occhiata a /etc/passwd come deve comportarsi. La parte interessante di /etc/profile (per shell sh-compatibili), da me implementata, è la seguente:
# /etc/profile
ulimit -u 30 # questo serve a prevenire i "denial of service"
if (grep ^$USER: /etc/passwd | grep -q "/home/nt-users"); then
/root/bin/ntconnect
export HOME=/home/nt-users/$USER/Linux
killall smbmount-2.1.x
if ! [ -x $HOME ]; then
# Se non esiste una directory "Linux", la crea al volo
# con le impostazioni di default
mkdir $HOME
cp /etc/skel/keax.kxc $HOME
cp /etc/skel/.xsession $HOME
fi
fi
Il che significa (press'a poco): se l'utente è un utente con la home su NT, allora chiama lo script ntconnect, imposta la home directory nella sottodirectory "Linux" dello share, uccidi il processo smbmount (che non serve più dal momento che l'operazione di mount è effettuata dal kernel), e infine, se non è presente una directory "Linux", creala mettendoci dentro i file di configurazioni minimi indispensabili. Tutto questo serve a simulare in qualche modo il funzionamento di un host Unix normale con il filesystem locale anzichè remoto.
La chiave di tutto il sistema di "connessione trasparente" è quindi rappresentata da ntconnect, che consiste in questo semplice script:
#!/bin/sh
# ~root/bin/ntconnect
retry=1
while [ $retry -gt 0 ] && ! grep -q $USER /proc/mounts
do
/usr/bin/smbmount-2.1.x //sfs/$USER -U $USER -c "mount /home/nt-users/$USER -u $
UID -g 101 -f 755 -d 711" && retry=0
if [ $retry -eq 0 ]; then
sleep 1
fi
done
export HOME=/home/nt-users/$USER/Linux
cd
Lo script controlla prima che la home dell'utente non sia già montata sul filesystem, in tal caso "esporta" la variabile HOME e vi punta la directory corrente, altrimenti entra in un ciclo che termina quando la directory viene montata (potrebbe rivelarsi un ciclo infinito dal momento che qui al LIB gli account vengono disabilitati dopo 3 tentativi falliti), e in caso di esito positivo... uhh, sono un po' imbarazzato... aspetta un secondo e poi esce, poichè il kernel mette a disposizione il mount-point solo dopo un piccolo ritardo.In una sessione telnet, questo piccolo ritardo passa inosservato e non causa problemi, ma i problemi sorgono in una sessione X quando lo script di inizializzazione della sessione cerca di leggere i file di configurazione personali. L'accesso viene tentato immediatamente, e se i file non vengono trovati, la sessione "ricade" sulle (brutte) impostazioni di default. A mia parziale discolpa riguardo all'uso della pausa di un secondo per risolvere la race condition potrei aggiungere che controllare rigorosamente il "montaggio" avrebbe implicato l'esecuzione di diverse decine di fork() e di exec() al secondo, con conseguente aumento del carico sul sistema. Poichè un secondo è un margine abbastanza sicuro anche in condizioni di carico elevato, ho ritenuto che rischiare di non avviare una sessione grafica ogni tanto fosse meglio che sovraccaricare sempre il sistema per evitare questo rischio (comunque non ditelo a Tisato lo stesso).
Un'altra modifica riguarda appunto le sessioni X: bisogna fare in modo che la home sia già montata prima di leggere un qualunque file di configurazione, quindi è stato necessario modificare lo script di sessione di sistema (/etc/X11/Xsession) con la seguente aggiunta:
# /etc/X11/xsession
if (grep ^$USER: /etc/passwd | grep "/home/nt-users") && ! grep -q $USER /proc/mounts; then
xmessage -geometry +180+220 -file /etc/ntconnect.msg &
xterm -geometry 80x8+150+100 -e ~root/bin/ntconnect
export HOME=/home/nt-users/$USER/Linux
if ! [ -x $HOME ]; then
mkdir $HOME
cp /etc/skel/keax.kxc $HOME
cp /etc/skel/.xsession $HOME
fi
fi
Questo fa sì che, se la home directory non è già montata, prima di fare qualunque altra cosa venga aperto un xterm dove viene eseguito lo script ntconnect, che funziona allo stesso modo che nella sessione telnet. Se la directory Linux non esiste, significa che è la prima volta che l'utente si collega, e quindi gli vengono creati automaticamente la directory "Linux" e i file di inizializzazione della sessione X, che verranno caricati pochi istanti dopo.
Ma ecco sorgere il problema più irritante che abbiamo dovuto affrontare: dopo circa un quarto d'ora di inattività, le connessioni al server NT "saltano" e non c'è più modo di accedere ai propri dati se non quello di smontare la propria directory (operazione che richiede privilegi di root) e rimontarla. Ovviamente era improponibile impedire agli utenti di fare una pausa ogni tanto o costringerli a rivolgersi all'amministratore ogni volta che fanno una pausa (mettetevi nei panni degli amministratori...), quindi abbiamo risolto il problema con un piccolo script che tiene attive le connessioni forzando una scrittura ogni due minuti.
#!/bin/sh
# ~root/bin/keepalived
while [ 1 ]
do
for d in /home/nt-users/*
do
touch $d/Linux/.keepalive 2> /dev/null
done
sleep 120
done
Come si intuisce dal comando touch, abbiamo cercato di tenere lo script il meno intrusivo possibile, a maggior ragione perchè viene eseguito con privilegi di root, e quindi si limita ad entrare nelle directory degli utenti e aggiornare ogni due minuti la data e l'ora del file .keepalive, di dimensione 0 byte, eventualmente creandolo se non c'è. Spero non lo consideriate un oltraggio alla vostra privacy, ma non si poteva proprio fare altrimenti (a meno di usare un altro filesystem, infatti sto facendo esperimenti con coda).
Bene, siamo proprio arrivati alla fine. Come premio per avere avuto la pazienza di leggermi fin qui, vi dò qualche trucchetto per configurare al meglio la vostra sessione grafica malgrado il pessimo server X che abbiamo a disposizione. Tanto per incominciare, potete scegliere un window manager diverso dal twm di default, che può piacere e non piacere (io personalmente lo trovo carino). Basta creare nella propria home directory uno script .xsession che contenga tutti i programmi che si intendono avviare automaticamente, seguiti dal window-manager che più vi aggrada. Un esempio semplice potrebbe essere il seguente, quelli complicati scopriteveli voi che è più divertente:
#!/bin/sh # ~/.xsession (deve avere il permesso di esecuzione) xterm -geometry +20+20 & unclutter & exec fvwm
l window-manager deve essere messo per ultimo perchè la sessione termina quando termina l'ultimo programma, e il window-manager è presumibilmente il primo a partire e l'ultimo a terminare, inoltre il comando exec permette di risparmiare un po' di memoria dal momento che in questo modo la shell che esegue la sessione viene terminata.
Il file .Xresources permette di modificare l'aspetto delle applicazioni fin nei minimi dettagli, e suppongo che un xterm con scritte in nero su fondo bianco e molti tasti che non funzionano non sia il massimo della vita. Allora, fino a che non installeranno un server X decente, la soluzione semplice e pulita è la seguente: uno script che legga da solo tutte le "resources" presenti in /etc/X11/Xresources/, le mandi al server, e fornisca un'interfaccia quanto meno accettabile.
#!/bin/sh
# ~/bin/updatexres
for f in /etc/X11/Xresources/*
do
xrdb -merge $f
done
Ecco fatto, potete chiudere l'xterm, aprirne un altro, e constatare che ha il fondo nero, le scritte bianche, e una simpatica scrollbar in stile NeXT, troppo bella.
Ok, per ora è tutto: se avete domande e/o suggerimenti, non esitate a sottoporli al V.P.D.F. ("Vostro Pinguino Di Fiducia").