Configurazione LTSP su thinserver: DHCP, condivisioni Windows e Kerberos

Important: prima di applicare modifiche in produzione, testarle su un ambiente di staging identico (stesso dominio Kerberos/AD, reti e versioni di Ubuntu). Esegui backup delle configurazioni critiche (/etc, /home, /etc/fstab).

Indice

• DHCP e PXE per thin client
• Preparazione del thin client e tema desktop
• Montare condivisioni Windows all’accesso
• Rimozione delle condivisioni al logout (pam_script)
• SSH senza password tramite Kerberos
• Problemi comuni e soluzioni
• Checklist per amministratori e utenti
• Metodo di rollout e rollback
• Sicurezza, privacy e note GDPR
• FAQ

DHCP Server Settings

Questa sezione mostra la configurazione DHCP necessaria per consentire ai thin client di avviare il sistema tramite PXE dal thinserver. I blocchi di configurazione presentati sono pronte da inserire nel file dhcpd.conf del tuo server DHCP (o nella sezione appropriata del tuo server ISC DHCP).

Mantieni le righe del blocco di codice esattamente come sono quando le copi nel file di configurazione; i valori IP e MAC sono esempi e devono essere adattati al tuo ambiente.

default-lease-time            21600;
max-lease-time                21600;

option subnet-mask            255.255.255.0;
option broadcast-address      10.255.255.255;
option routers                10.0.0.1;
option domain-name-servers    10.0.0.10
option domain-name            "domain.internal";
option root-path              "/opt/ltsp/i386";

host thinclient1 {
        next-server             10.0.0.10;
        hardware ethernet       00:AA:BB:CC:DD:EE;
        fixed-address           10.0.0.100;
        filename                "ltsp/i386/pxelinux.0";
        option root-path        "10.0.0.10:/opt/ltsp/i386";
}

host thinclient2 {
        next-server             10.0.0.10;
        hardware ethernet       00:BB:CC:DD:EE:FF;
        fixed-address           10.0.0.101;
        filename                "ltsp/i386/pxelinux.0";
        option root-path        "10.0.0.10:/opt/ltsp/i386";
}

Note essenziali:

• next-server: IP del TFTP/PXE server (thinserver). Assicurati che il servizio TFTP sia raggiungibile.
• filename: path di boot PXE. Conferma che il file pxelinux.0 esista nella share TFTP.
• option root-path: percorso NFS/remote root per LTSP.

Thin Client Setup

Per rendere più semplice l’uso ai client ho applicato un tema personalizzato (XPGnome) e alcune modifiche ai menu di avvio. Ho inoltre installato applicazioni comuni come Adobe Reader 9 e Skype (esempi).

Se hai problemi con icone mancanti (ad esempio l’icona “Log Out”), una soluzione praticabile è ridimensionare un’immagine sorgente con GIMP in queste dimensioni: 32×32, 24×24, 22×22 e 16×16. Rinomina il file in system-log-out.png e posizionalo nei percorsi delle icone Gnome:

/usr/share/icons/GnomeXP/{dimensione}/actions

Esempio pratico:

• Icona originale: 48×48
• Convertita in: 32×32, 24×24, 22×22, 16×16
• Percorso di installazione: /usr/share/icons/GnomeXP/32x32/actions/system-log-out.png (e analoghi per le altre dimensioni)

Il risultato finale può apparire come nell’immagine qui sotto.

Per rendere le impostazioni di tema e menu predefinite per ogni nuovo utente, copia le cartelle di configurazione dell’utente che ha personalizzato l’ambiente (ad esempio .config, .gconf, .icons, .local, .themes) nella skeleton directory:

sudo cp -a /home/utente/.config /home/utente/.gconf /home/utente/.icons /home/utente/.local /home/utente/.themes /etc/skel/

Avvertenza: ogni successiva modifica che vuoi applicare a tutti gli utenti richiederà di aggiornare /etc/skel o di distribuire uno script che sincronizzi le modifiche.

Montare condivisioni Windows all’accesso

Obiettivo: montare automaticamente le condivisioni Windows specificate nei file batch di logon (net use) all’accesso dell’utente Linux. La soluzione usa uno small-wrapper Bash + uno script Perl che genera script di mount specifici per utente, e sfrutta Kerberos per l’autenticazione senza password interattiva.

Architettura di alto livello:

• NETLOGON (da dc.domain.internal) viene montato su thinserver (es. /mnt/logon)
• Per ogni utente esiste un file di logon bat (jdoe.bat) in /mnt/logonbat
• Uno script mount.pl legge il .bat e genera /home/$USER/.mount.sh e /home/$USER/.umount.sh
• Uno script win_share.sh viene lanciato all’accesso tramite “Startup Applications” per eseguire .mount.sh

Prerequisiti: il thinserver deve poter montare la share NETLOGON usando un account con privilegi di lettura. In questo esempio l’account è “public” con password “password” (sostituire con account reale e più sicuro).

Crea la directory di mount per NETLOGON:

sudo mkdir /mnt/logon

Aggiungi la riga seguente in /etc/fstab (adatta il percorso e le credenziali):

//dc.domain.internal/netlogon      /mnt/logon           cifs   username=public,password=password 0  0

Monta le share:

sudo mount -a

Ora creiamo gli script. I blocchi di codice qui sotto devono essere copiati esattamente nei file indicati (attenzione ai permessi e proprietà):

1. win_share.sh (salvalo in /usr/local/bin/ e rendilo eseguibile)

#!/bin/sh
# Check to see if .mount.sh and .umount.sh exist, if so delete them!

if [ -f /home/$USER/.mount.sh ]; then
   rm /home/$USER/.mount.sh
fi

if [ -f /home/$USER/.umount.sh ]; then
   rm /home/$USER/.umount.sh
fi

# Create the .mount.sh and .umount.sh scripts from users batch file

/usr/local/bin/mount.pl $USER

# Mount network shares when logging on.
/home/$USER/.mount.sh

2. mount.pl (salvalo in /usr/local/bin/ e rendilo eseguibile)

#!/usr/bin/perl
# Build dynamic ~user/.mount.sh based on logon.bat

$user = $ARGV[0];
$file = "/mnt/logonbat/$user.bat";  # <-- Change this from $user to the name of the batch script if you only use one.

die if ! $user;
die if ! -e $file;

open (PAM_CONF, ">/home/$user/.mount.sh");
open (LOGOFF, ">/home/$user/.umount.sh");

print PAM_CONF qq{#!/bin/sh
if [ ! -d /home/$user/Home ]; then
mkdir /home/$user/Home
fi
mount.cifs //server/$user /home/$user/Home -o username=$user,sec=krb5
};

print LOGOFF qq{#!/bin/sh
if [ "`cat /proc/mounts | grep /home/$user/Home | wc -l`" -ge "1" ]; then 
umount.cifs /home/$user/Home 
fi \n};

my(@arr)=`cat /mnt/logonbat/$user.bat`;
$mounts = parse_batfile(\@arr);
foreach $mount (@$mounts) {
  chomp($mount);
  ($server,$share) = $mount =~ /\\\\(.*)\\(.*)/;
  $share =~ tr/\cM//d;
  $mnt = $share;

  # skip AUDIT.  It's for PCs only
  next if $mnt =~ /AUDIT/;

  # skip personal shares.  
  next if lc("$mnt") eq lc("$user");
  next if ! $mnt;

  #strip dollar sign from mount point
  $mnt =~ s/\$$//;

  # make sure mount point is unique
  $mnt .= "-$server"  if $seen{$mnt}++;

  # upshift first letter of mnt point
  $mnt =~ s/^( .)(.*)/\u$1$2/g;

#  print PAM_CONF "volume $user cifs $server $share  /home/$user/$mnt  - - -\n";
  print PAM_CONF qq{if [ ! -d /home/$user/$mnt ]; then
mkdir /home/$user/$mnt
fi
mount.cifs //$server/$mnt /home/$user/$mnt -o username=$user,sec=krb5 \n};

  print LOGOFF qq{if [ "`cat /proc/mounts | grep /home/$user/$mnt | wc -l`" -ge "1" ]; then 
umount.cifs /home/$user/$mnt 
fi \n};
}

close PAM_CONF;
close LOGOFF;
system ("chown $user:16777729 /home/$user/.mount.sh");   #  16777729 is my GID for "Domain Users"
system ("chown $user:16777729 /home/$user/.umount.sh");  #  16777729 is my GID for "Domain Users"
system ("chmod +x /home/$user/.mount.sh");
system ("chmod +x /home/$user/.umount.sh");

# All done

sub parse_batfile {
  my($file) = @_;
  my(@mounts);
  foreach $line (@$file) {
    (@val) = split / /,$line;
    if (uc($val[0]) eq "NET" && uc($val[1]) eq "USE") {
       push (@mounts,$val[3]);
    }
    if ($val[0] eq "CALL") {
      my($match) = $val[1]  =~ /\\\\.*\\NETLOGON\\(.*)/ ;
      if ($match) {
        chop($match);
        my(@arr)=`cat /mnt/logonbat/$match`;
        $mounts = parse_batfile(\@arr);
        unshift @mounts, @#$mounts;
      }
    }
  }
  return \@mounts;
}

3. Esempio del file .mount.sh generato (jdoe)

#!/bin/sh
if [ ! -d /home/jdoe/Home ]; then
mkdir /home/jdoe/Home
fi
mount.cifs //server/jdoe /home/jdoe/Home -o username=jdoe,sec=krb5
if [ ! -d /home/jdoe/common ]; then
mkdir /home/jdoe/common
fi
mount.cifs //server/common /home/jdoe/common -o username=jdoe,sec=krb5 
if [ ! -d /home/jdoe/IT ]; then
mkdir /home/jdoe/IT
fi
mount.cifs //server/IT /home/jdoe/IT -o username=jdoe,sec=krb5 

4. Creare la “Startup Application” per lanciare win_share.sh all’accesso utente

Vai in “Preferences/Startup Applications” e aggiungi:

• Nome: Monta condivisioni Windows
• Comando: /usr/local/bin/win_share.sh
• Commento: monta le share definite nel NETLOGON

Rimozione delle condivisioni al logout

Per smontare automaticamente le share quando l’utente esce, usa il modulo PAM: libpam-script. pam_script.so permette di eseguire script alla chiusura della sessione; il motivo per cui la login non usa pam_script è che viene eseguito come root e gli script dipendono dalla variabile $USER.

Installazione (esempio con pacchetto .deb locale):

sudo dpkg -i libpam-script_1.1.4-1_i386.deb

Esempio di .umount.sh generato per jdoe:

#!/bin/sh
if [ "`cat /proc/mounts | grep /home/jdoe/Home | wc -l`" -ge "1" ]; then 
umount.cifs /home/jdoe/Home 
fi 
if [ "`cat /proc/mounts | grep /home/jdoe/common | wc -l`" -ge "1" ]; then 
umount.cifs /home/jdoe/common 
fi 
if [ "`cat /proc/mounts | grep /home/jdoe/IT | wc -l`" -ge "1" ]; then 
umount.cifs /home/jdoe/IT 
fi 

Aggiungi lo script di chiusura di sessione in /usr/share/libpam-script/pam_script_ses_close:

#!/bin/sh
# pam_script_ses_close script to remove windows shares

/home/$PAM_USER/.umount.sh 2>&1 >> /var/log/umount.log

Poi abilita il modulo in /etc/pam.d/common-session aggiungendo:

session     optional            pam_script.so

Testa l’intero flusso: login utente → mount automatico; logout → umount automatico. Controlla /var/log/umount.log per i messaggi di debug in caso di errore.

SSH senza password con Kerberos

Kerberos abilita SSH passwordless usando GSSAPI. Requisiti:

• Thinserver e workstation devono essere parte del dominio Kerberos
• kinit funziona e il ticket Kerberos è valido

Configurazioni consigliate:

Nel file /etc/ssh/sshd_config su thinserver:

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UseDNS yes

Nel file /etc/ssh/ssh_config sulla workstation:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Testa con debug per verificare che SSH faccia uso di GSSAPI:

ssh -v thinserver

Se Kerberos funziona correttamente vedrai messaggi come:

debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Delegating credentials
debug1: Authentication succeeded (gssapi-with-mic).

Se continui a vedere prompt per password, verifica i seguenti punti:

• ticket Kerberos valido (klist)
• host principals corretti nel KDC
• risoluzione DNS coerente (UseDNS yes / no a seconda dell’infrastruttura)

Problemi comuni e soluzioni

Esempi pratici che ho incontrato:

• PROBLEMA: LTSP client si autentica ma esce immediatamente

  • SOLUZIONE:

    gconftool-2 –direct –config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory –type string –set /desktop/gnome/session/required_components/windowmanager metacity

• PROBLEMA: Nessun VNC sui thin client

  • SOLUZIONE: vedi guida di riferimento per installare X11VNC su LTSP (link esterno indicato nella guida originale)

• PROBLEMA: Cambiare schermata di login di default

  • SOLUZIONE: consultare le FAQ ufficiali di Edubuntu/Ubuntu per personalizzazione GDM/LightDM

• PROBLEMA: Impostare password root su thin client

  • SOLUZIONE: consultare la documentazione Edubuntu/Ubuntu

• PROBLEMA: Icona di logout non visibile

  • SOLUZIONE: ridimensionare/fornire icone nelle dimensioni richieste e posizionarle sotto /usr/share/icons

Best practice e quando questa soluzione fallisce

Quando scegliere questa strategia:

• ambiente scolastico o aziendale con molti thin client e una infrastruttura AD/Kerberos già esistente
• necessità di single sign-on e montaggio dinamico di home e share utente

Quando può fallire o non essere la scelta ottimale:

• infrastrutture senza Kerberos o con autenticazione legacy: la parte Kerberos/SAML richiede lavoro aggiuntivo
• ambienti con esigenze di conformità elevate (alcune policy aziendali non permettono mount automatici con credential reuse)
• scarse performance di rete: montare molte share su startup incide sul tempo di login

Alternative praticabili:

• usare autofs per mount on-demand invece di mount immediato all’accesso
• usare client SMB con credenziali per macchina (less secure) o soluzioni basate su NFSv4 con Kerberos
• impiegare un file server centralizzato con proxy/cache per ridurre latenza

Metodo di rollout e rollback (mini-methodology)

1. Env di staging: riproduci dominio AD/Kerberos e rete
2. Applica la configurazione DHCP/PXE e verifica boot del thin client
3. Distribuisci win_share.sh e mount.pl su un subset di utenti power-user
4. Test funzionale: login, creazione .mount.sh, mount delle share, umount al logout
5. Monitoraggio: log (syslog, /var/log/umount.log), tempi di login, errori CIFS
6. Rollout graduale: reparto per reparto
7. Rollback: ripristina /etc/fstab originale, rimuovi la startup application e pulisci /home/*/.mount.sh

Criteri di accettazione:

• tutti i thin client del gruppo test effettuano login senza prompt password
• le share previste sono montate in /home/$USER/* entro X secondi (X stabilito in test)
• logout pulisce tutte le mount senza errori

Checklist per ruoli (amministratore, helpdesk, utente)

Amministratore:

• Verificare KDC e account di servizio
• Controllare /etc/ssh/sshd_config e /etc/ssh/ssh_config
• Provisioning DHCP e TFTP
• Testare PXE boot su macchina fisica
• Abilitare log e rotazione (/var/log/umount.log)

Helpdesk:

• Verificare permessi e proprietà dei file /home/$USER/.mount.sh
• Controllare ticket Kerberos (klist)
• Confermare che /mnt/logon è montato correttamente

Utente:

• Assicurarsi che il proprio file $USER.bat esista in NETLOGON
• Segnalare eventuali errori di mount allo helpdesk con output di /var/log/umount.log

Sicurezza, privacy e note GDPR

• Non salvare password in chiaro in /etc/fstab per deployment di produzione. Preferire credenziali protette (credential files con permessi 600) o Kerberos per autenticazione senza password.
• Minimizzare i privilegi di account usati per mount NETLOGON: un account “public” dovrebbe avere solo permessi di lettura.
• Log utente: evitare di scrivere dati sensibili in log accessibili a utenti non autorizzati.
• Se i dati degli utenti contengono informazioni personali, assicurati che la gestione dei backup e l’accesso ai log rispettino le normative vigenti (GDPR). Documenta retention e processo di accesso ai log.

Test cases e criteri di accettazione (breve)

• Test 1: Login utente jdoe → verificare che /home/jdoe/Home venga montata e sia accessibile
• Test 2: Exec umount su logout → verificare che non restino mount zombie in /proc/mounts
• Test 3: SSH da workstation con ticket Kerberos valido → login senza password
• Criterio di successo: tutti i test passano senza prompt password e senza errori nei log

Diagramma decisionale (quando scegliere autofs vs mount al login)

flowchart TD
  A[Hai Kerberos e AD funzionanti?] -->|No| B[Usa autofs o NFS con account di servizio]
  A -->|Sì| C[Desideri mount immediato all'accesso?]
  C -->|Sì| D[Usa mount-script + Kerberos come descritto]
  C -->|No| E[Usa autofs per mount on-demand]
  D --> F[Valuta impatto sui tempi di login e fallback]
  E --> F

Glossario in una riga

• LTSP: Thin Client Server per avvio remoto; PXE: Preboot Execution Environment; CIFS/SMB: protocollo di condivisione file Windows; Kerberos: sistema di autenticazione a ticket.

FAQ

1. D: Perché gli script non funzionano come root sotto pam_script? R: pam_script esegue gli script come root; gli script forniti fanno affidamento su $USER e devono essere generati con proprietà dell’utente. È per questo che la parte di login usa la Startup Application a livello utente.

2. D: Posso usare autofs invece di generare .mount.sh per ogni utente? R: Sì. autofs monta on-demand e può ridurre il tempo di login. Tuttavia, la soluzione presentata replica esattamente i net use definiti nei .bat di logon e permette logiche personalizzate di mapping.

Riepilogo: questa guida mostra come configurare DHCP/PXE per LTSP, personalizzare l’ambiente desktop dei thin client, montare e smontare automaticamente condivisioni Windows basate su file di logon utilizzando Kerberos e come abilitare SSH passwordless. Include script pronti all’uso, checklist operative, note di sicurezza e una metodologia di rollout.