Ltsp su architettura X86_64

In alcuni commenti ad un post precedente si era parlato di LTSP server su architettura a 64 bit. Io, non avendolo mai provato e presumendo complicazioni, sconsigliavo di farlo. Avendo adesso a disposizione una macchina a 64bit ho deciso invece di provare.
Ho installato una versione di Ubuntu Gutsy per AMD64, poi ho creato l'ambiente server per ltsp usando i comandi già descritti in questo post. Dal momento che il server dhcp risiedeva su un'altra macchina della rete ho dovuto semplicemente modificare qualche parametro per indirizzare le richieste di tftp al server giusto. L'unica piccola (ma sostanziale) differenza in tutto il processo è stato il comando per creare l'ambiente chroot dei client: ho infatti usato "sudo ltsp-build-client --arch i386".
Con questa opzione attivata viene infatti costruito un ambiente chroot in grado di far partire i pc con architettura uguale o superiore a i386 (cioè tutti i cosiddetti x86). La scelta è logica poichè i thin client per definizione sono macchine poco potenti e difficilmente vengono costruiti su architetture diverse dalla x86, e comunque all'occorrenza anche un pc con processore X86_64 gira tranquillamente con sistema operativo a 32 bit per i386.
Nella pratica succede che i thin client fanno il boot e avviano i processi di sistema di base a 32 bit nell'ambiente chroot, dopodichè in ambiente grafico (e a questo punto siamo sul server) le applicazioni che vengono lanciate sono a 64 bit. I vantaggi sono evidenti: se vogliamo gestire un numero molto elevato di thin client l'architettura X86_64 è in grado di usare in modo molto più efficiente quantità di memoria ram superiore ai 4Gb. Per una esaustiva discussione sulle differenze tra sistemi a 32 e 64 bit suggerisco di dare un'occhiata qua.

Postfix, Exchange e pipelining

Talvolta da postfix non è possibile inviare posta verso alcuni domini e nei log si trovano dei messaggi abbastanza generici che parlano di "timeout after DATA". In questi casi di solito i problemi vengono attribuiti alla configurazione di alcuni apparati di rete, e come soluzione si suggerisce di agire sulla dimensione degli MTU (Wietse Wenema, creatore di Postfix, in un post su una mailing list suggeriva di usare MTU = 1000, ma ho perso il link) e di disabilitare l'MTU auto discovery (in linux si disabilita con sysctl -w net.ipv4.ip_no_pmtu_disc=1). In altri casi qualcuno suggeriva di agire sui timeout, in postfix ce ne sono parecchi che si possono modificare (per vedere l'attuale configurazione di postfix e avere nel contempo l'elenco dei parametri di configurazione utilizzabili basta digitare "postconf" da linea di comando).

Nel mio caso succedeva che i messaggi solo testo partivano mentre quelli contenenti allegati non ne volevano sapere. Nessuna delle soluzioni suggerite sopra aveva funzionato, il server remoto era un Exchange, si presentava come Microsoft ESMTP Server 6.0.3790.3959. Dopo parecchio tempo speso a cercare la soluzione ho scoperto questo. In pratica alcune versioni di Exchange durante la fase di negoziazione del protocollo millantano di supportare la funzione PIPELINING, mentre invece non è vero: la connessione inizia ma non succede nulla, alla fine del tempo a disposizione la connessione viene chiusa e compare l'errore nei logs.

Occorre quindi dire a postfix di non tenere in considerazione l'opzione pipelining se gli viene proposta da quel particolare server. Ecco come si fa:

Edito il file /etc/postfix/main.cf e aggiungo la riga:

smtp_discard_ehlo_keyword_address_maps = hash:/etc/postfix/ehlo_keywords

Poi edito /etc/postfix/ehlo_keywords in questo modo:

<ip_server_remoto_bacato> pipelining

salvo, chiudo e lancio il comando postmap /etc/postfix/ehlo_keywords

A questo punto "postfix reload" ed il gioco è fatto.

LTSP su Ubuntu Gutsy: sempre più facile

Oggi è il 18 Ottobre, data in cui dovrebbe uscire la release 7.10 di Ubuntu (Gutsy Gibbon). Sul sito di Ubuntu ancora non è comparso nessun annuncio, tuttavia è da parecchie ore che non escono pacchetti aggiornati, quantomeno riguardo al software che uso io, quindi ritengo che i miei pc su cui gira Gutsy possano essere ormai considerati "stabili".

Ho provato a ricreare l'ambiente LTSP server + thin client per verificare eventuali differenze rispetto alla release precedente e, ovviamente, eventuali miglioramenti. Sulla macchina destinata a fare da server (in realtà il mio desktop in ufficio) ho lanciato il comando:

aptitude install ltsp-server ltspfs

e ho accettato di installare le relative dipendenze.

Non ho assolutamente preso in considerazione questo messaggio:

NOTE: you will probably want to add to /etc/exports:
/opt/ltsp *(ro,no_root_squash,async)
and then run:
invoke-rc.d nfs-kernel-server reload

perchè il pacchetto nfs-kernel-server non è installato e non è stato richiesto durante la fase di installazione, si tratta probabilmente di un refuso. Finita l'installazione ho semplicemente lanciato il comando:

ltsp-build-client

e ho aspettato la fine del processo.

Backup su server FTP

Segnalo un utile strumento che serve a mantenere sincronizzati una directory locale e una remota su un server ftp.
Si tratta di FTPSync.pl che, come si intuisce dal nome, è uno script in Perl.

Traduco parte di quanto scritto nel file README,:

"Ftpsync.pl mantiene sincronizzata una gerarchia di directory locali con una gerarchia di directory remote su un server ftp. E' stato inizialmente scritto per automatizzare operazioni di web publishing ma può risultare utile per numerose altre operazioni, come fare un mirror di siti pubblici non troppo grossi, replicare dati e molto altro.

Perchè usare ftpsync.pl invece di mirror, sitecopy ....?

E' vero, ci sono altri progetti simili, alcuni commenti su questi:

rispetto a mirror, ftpsync.pl è in grado di fare anche PUT, non solo GET (se mirror è in grado di fare anche PUT non prendetevela con me, io non ci sono riuscito). Rispetto a sitecopy, ftpsync.pl non ha alcun problema se il sito remoto dopo l'ultima sincronizzazione viene modificato da altri tool o processi. Ftpsync.pl, a meno di problemi di connettività o di bachi, fornisce sempre una sincronizzazione affidabile. Rispetto a tutti e due ftpsync.pl è estremamente leggero."

Aggiornamento a WP 2.3

Lo sapevo che sarebbe potuto succedere. Aggiornando il blog a Wordpress 2.3 mi si è pesantemente sbelinato il tutto. Il tema che avevo faticosamente modificato e adattato non funziona più. Non vengono più riconosciuti i tags e ci sono tutta una serie di altre fastidiose anomalie.

Sono costretto a tornare temporaneamente al tema di default di WP, nel frattempo vedrò di sistemare il vecchio tema oppure, perchè no, metterne uno nuovo.

Ubuntu LTSP - Thin client per piccola azienda (3)

In questo terzo e ultimo post sui thin client cerco di spiegare alcuni dettagli di messa a punto e gestione della rete basata su server LTSP e thin client. La documentazione ufficiale su questi argomenti si trova invece qua.

Preparazione dei dischi per il boot dalla rete

Non tutti i pc sono in grado di fare il boot direttamente dalla scheda di rete. Anzi, normalmente solo macchine relativamente recenti, diciamo costruite grossomodo dal 2003 in avanti, sono in grado di farlo. Dal momento che uno dei vantaggi dei thin client è proprio quello di poter riciclare pc molti vecchi è assai probabile che sarà necessario preparare un cd o un floppy di avvio che permetta al pc di caricare il sistema operativo dal server ltsp.
Fortunatamente la procedura è molto semplice: grazie a rom-o-matic è possibile "fabbricarsi" una immagine di avvio per ogni scheda di rete. Per fare questo bisogna innanzitutto conoscere il tipo di scheda di rete presente nel thin client, e questo in qualche caso potrebbe non essere semplicissimo. In generale, su pc in grado di avviarsi da cd-rom è sufficiente avviare la macchina con una qualunque distribuzione linux live (io mi porto sempre dietro una Knoppix per ogni evenienza) e usare il comando

lspci

per identificare in maniera corretta la scheda presente sotto la voce "Ethernet controller". Una volta identificata la scheda, se non si conosce il nome del relativo modulo da caricare è sufficiente fare una rapida ricerca su google mettendo il nome e il modello della scheda trovata assieme alla stringa "linux module" ed in genere tra i primi risultati viene riportato il nome del modulo corretto. Mi sono anche capitati pc ancora più vecchi, dotati solo di unità floppy da 3.5", ma in quel caso erano dotati di una vecchia scheda a 10 Mbit, non idonea per un thin client, e ho quindi dovuto sostituirle con schede a 100Mbit che già conoscevo.
Una volta identificata la scheda e il relativo modulo su rom-o-matic si sceglie dal menu a tendina la voce corretta, il tipo di immagine ("Floppy bootable ROM image" per i floppy o "ISO bootable image without floppy legacy emulation" per i cdrom) e si scarica il file che viene prodotto. Per creare un floppy di avvio si può usare semplicemente il comando:

cat <nome_immagine_scaricata>.zdsk > /dev/fd0

mentre per il cd-rom basta masterizzare il file .iso.
Un'opzione interessante del rom-o-matic è che molti parametri di rete possono essere predefiniti nell'immagine che si sta creando. Posso per esempio fissare già un indirizzo ip, un gateway di default e parecchi altri parametri. In teoria tutto questo dovrebbe permettere l'avvio e l'utilizzo di un thin client senza aver bisogno di configurare un server dhcp nella rete.

Samba, Active Directory e permessi

Debian 4.0 etch, samba 3.0.24-6etch4 attaccato ad un Domain Controller Win2000 con Active Directory (http://www.debian-administration.org/articles/340).

Era una situazione di semi emergenza, dovevo sostituire al volo un fileserver Win2K deceduto mettendo tutti gli share da un'altra parte, e cosa meglio di una macchina Linux già pronta, sottoutilizzata e con dello spazio libero? Installo samba e gli altri pacchetti necessari, faccio tutta la procedura per attaccarmi a Active Directory, sistemo le configurazioni. Tutto ok tranne una cosa: non c'è verso di fargli riconoscere a dovere i permessi relativi ai gruppi (non gli utenti, solo i gruppi). Di conseguenza non è possibile dare l'accesso agli utenti, se non facendo una sorta di "liberi tutti" o mettendo esplicitamente il nome di ogni singolo utente nella configurazione: ambedue soluzioni improponibili.