Distribuzione FUSS » fuss-client

Non posso pensare ad un comportamento non deterministico di fuss-client nell'ipotesi

1. che si parta dallo stesso clone
2. che si usino gli stessi parametri di fuss-client

Vedo che nell'allegato che mandi (FOTO-etc-clusters-gandhi-laives.png) c'è un po' di fritto misto ed errori di disattenzione:

1. convenzioni diverse nella denominazione dei cluster (vabbè, sono delle stringhe)
2. host finiti nei cluster sbagliati (info1-pc10 finito nel cluster AULA_INFO_2, oppure info15 ??? presente sia in AULA_INFO_2 che nel cluster 1.BLOCCO)
3. host joinati con il hostname originale dell'immagine (fuss9-64bit o fuss9-32bit)
4. bisogna capire poi come mai il host bunker02 sia andato, mentre bunker01 (come vedo dal file /etc/hosts che hai mandato) sia diventato bunker-03 in /etc/clusters

Inoltro il ticket. Immagino che ci sarà un po' di interazione.

Sto cercando di riprodurre la situazione (o meglio, le situazioni) e ho un po' di commenti/domande.

Innanzitutto, la riga corretta da ottenere in /etc/hosts non è quella con due volte il nome della macchina, ma la versione in cui la prima volta c'è il dominio, ad esempio

127.0.1.1 aula01.gandhi.lvs aula01

Per impostare correttamente il dominio, bisogna passare a fuss-client il nome completo della macchina (esempio fuss-client -a -H aula01.gandhi.lvs): questa parte è sicuramente da documentare meglio.

Sia usando -H solo_hostname che usando -H hostname.dominio non sono però riuscita a riprodurre il caso in cui in /etc/hosts risultano due nomi diversi; continuo a provarci, ma avere indizi sulla diversità degli ambienti in cui succede sarebbe utile.

Inoltre confermo che fuss-client -r toglie le configurazioni locali, ma non rimuove la macchina dal cluster, operazione che per vari motivi va fatta lato server; ricordo una conversazione sull'argomento dell'anno scorso, devo cercarla per i dettagli.

mi correggo: ho riprodotto la situazione lanciando più volte fuss-client -a sulla stessa macchina (come se fosse stato lanciato con un parametro sbagliato a -H e poi rilanciato per correggere), proseguo nell'indagine

Ho appena caricato sui repository la versione 9.0.4 di fuss-client che nelle mie prove è più affidabile nell'impostare l'hostname, anche dopo un fuss-client -r -p e successivo nuovo fuss-client -a -H <hostname>

potete provare e vedere se risolve tutti i casi?

La versione

127.0.1.1 HOSTNAME.DOMINIO   HOSTNAME

è però quella corretta, se è stato impostato un dominio

per togliere l'hostname da /etc/clusters posso guardarci, però meglio aprire un'altro ticket

Elena Grandi ha scritto:

La versione
[...]

è però quella corretta, se è stato impostato un dominio

per togliere l'hostname da /etc/clusters posso guardarci, però meglio aprire un'altro ticket

Ok, intanto inoltro ad Andrea per ultima verifica e chiusura.
Apro nuovo ticket per rimozione hostname da /etc/clusters.

Ehm, sorry, intendevo "rimozione del dominio" (ovvero avere in /etc/clusters HOSTNAME e non HOSTNAME.DOMINIO)

(che è una modifica veloce, bisogna solo capire se ci fossero motivi per cui era stata esplicitamente messa l'altra variante)

Elena, direi di lasciare così.
Se qualcuno vuole avere HOSTNAME.DOMINIO in /etc/clusters allora in /etc/hosts mette

127.0.1.1 HOSTNAME.DOMINIO   HOSTNAME

altrimenti usa

127.0.1.1 HOSTNAME

semplicemente come si è sempre fatto. Non vedo alcuna controindicazione ad usare in /etc/hosts solo

127.0.1.1 HOSTNAME

senza .DOMINIO o sto trascurando qualcosa?

In OctoNet ed anche OctoMon è a mio avviso ridondante avere per ciascun host anche il DOMINIO, direi quasi fastidioso.

Che avendo la riga senza .DOMINIO in /etc/hosts la macchina non è in grado di risolvere il proprio FQDN.

Che la cosa causi o meno problemi dipende un po' da cosa sta girando sulla macchina stessa, ma in generale il valore che viene configurato dall'installer o simili è con il dominio.

Voi l'avete sempre corretto per avere solo la versione senza dominio?

Elena Grandi ha scritto:

Che avendo la riga senza .DOMINIO in /etc/hosts la macchina non è in grado di risolvere il proprio FQDN.

Tieni conto però che il .DOMINIO è usato solo all'interno della LAN di ciascuna scuola.
E le macchine risolvono cmq il proprio FQDN anche senza mettere il .DOMINIO in /etc/hosts perché c'è pur sempre il file /etc/resolv.conf che viene aggiornato sicuramente all'avvio della macchina:

$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 35 apr  9 10:39 /etc/resolv.conf -> /var/run/NetworkManager/resolv.conf

$ ls -l /var/run/NetworkManager/resolv.conf
-rw-r--r-- 1 root root 61 lug 20 15:20 /var/run/NetworkManager/resolv.conf

Un esempio con la macchina che sto usando (hostname=fuss9-32bit IP=192.168.0.78):

/etc/hosts

127.0.0.1    localhost
127.0.1.1    fuss9-32bit

/etc/resolv.conf

domain fussbox.blz
search fussbox.blz
nameserver 192.168.0.1

$ host -r 192.168.0.78
78.0.168.192.in-addr.arpa domain name pointer fuss9-32bit.fussbox.blz.

### pingo un'altra macchina
$ ping client1
PING client1.fussbox.blz (192.168.0.95): 56 data bytes
...

$ host -r 192.168.0.95
95.0.168.192.in-addr.arpa domain name pointer client1.fussbox.blz

Che la cosa causi o meno problemi dipende un po' da cosa sta girando sulla macchina stessa, ma in generale il valore che viene configurato dall'installer o simili è con il dominio.

Voi l'avete sempre corretto per avere solo la versione senza dominio?

No, non è in genere stato corretto, ma da un certo momento in poi nel 2017 mi sono accorto che in octonet ed octomon e nei file /etc/clusters comparivano anche i domini che prima non c'erano. Come se prima il dominio, sebbene presente in /etc/hosts, venisse trascurato dal fuss-client e ad un certo punto venisse riconsiderato dal fuss-client.

Concordo con te Simone che /etc/hosts del client ed /etc/clusters sul server sono cose slegate ed in /etc/clusters si può mettere ciò che si vuole. Si parla appunto di quanto viene scritto in /etc/clusters da fuss-client e del fatto che dallo scorso anno fuss-client ad un certo punto ha iniziato a mettere in /etc/clusters anche il nome di dominio.

Per ovviare a ciò la soluzione (che ripeto, a mio avviso non ha conseguenze) è quella di mettere il solo HOSTNAME in /etc/hosts.

Però voglio una vostra ulteriore conferma di ciò che scrivo.

Certamente l'altra soluzione è quella di tenere il DOMINIO in /etc/host come prevede l'installer di Debian ma far sì che fuss-client non lo riporti in /etc/clusters e di conseguenza in OctoNet poiché inutilmente ridondante (sempre a mio parere).

Non è questione di risoluzione del DNS, quella funziona e non dipende dal client la fa il DNS del server ed il DNS il client li prende dal server via DHCP; è che hostname --fqdn (che deve essere indipendente dalla rete per cui non viene chiesto al DNS, ma ricavato localmente) così non funziona (nel senso che non da un nome dominio pienamente qualificato, resta solo l'hostname).

Gli effetti sul client sono sicuramente limitati, ma non sono semplici da stimare visto che comunque c'è una discrepanza fra quello che è l'FQDN secondo il DNS e quello che è l'FQDN secondo la configurazione locale, ed alcuni servizi (postfix ad esempio) usano quello locale. Il caso postfix per il client è poco significativo, ma non è detto la cosa non avvenga anche per altro.

Se in /etc/cluster si preferisce avere solo l'hostname, a questo punto basta far si che vi sia registrato solo quello. Eviterei proprio di forzare ad averlo anche in /etc/hosts solo perché poi venga messo in /etc/cluster.

Collaudata la versione 9.0.7 di fuss-client e fa ciò che è stato concordato con i tecnici.

Lasciamo per ora in sospeso la richiesta di cancellazione di un host da /etc/clusters sul server quando viene lanciato

fuss-client -r -p

Il presente ticket può essere chiuso.