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.