Project

General

Profile

Segnalazione #323

Nuova versione di fuss-client: si blocca l'aggancio alla rete

Added by Piergiorgio Cemin over 4 years ago. Updated over 4 years ago.

Status:
Risolto
Priority:
Urgente
Assignee:
Start date:
06/21/2017
Due date:
% Done:

0%


Description

Il processo di fuss-client -a
si blocca a
kt_util: write_kt /etc/krb5.keytab

e non c'è modo che vada avanti

Tutto aggiornato, server e client

typescript (3.11 KB) Piergiorgio Cemin, 06/21/2017 03:22 PM

top.png View (60 KB) Piergiorgio Cemin, 06/22/2017 05:14 PM

History

#1 Updated by Christopher R. Gabriel over 4 years ago

  • Status changed from Nuovo to Commenti
  • Assignee changed from Christopher R. Gabriel to Piergiorgio Cemin

Ciao Piero, potresti cortesemente mandare l'output completo del comando, come si fa con fuss-server, descritto anche qui: https://work.fuss.bz.it/projects/server/wiki/Bug_Reporting

Grazie

#2 Updated by Piergiorgio Cemin over 4 years ago

  • File typescript added
  • Assignee changed from Piergiorgio Cemin to Christopher R. Gabriel

Ecco il file

#3 Updated by Christopher R. Gabriel over 4 years ago

  • Assignee changed from Christopher R. Gabriel to Elena Grandi

#4 Updated by Elena Grandi over 4 years ago

  • Assignee changed from Elena Grandi to Piergiorgio Cemin

Ho notato sulle prove locali che all'aumentare delle macchine configurate quel comando tende a diventare discretamente lento (decine di minuti sulle mie macchine lente): è possibile che sia quello il caso?

#5 Updated by Piergiorgio Cemin over 4 years ago

  • Assignee changed from Piergiorgio Cemin to Elena Grandi

Posso solo dirti che ieri sono stato via tre ore e quando sono tornato il client su cui avevo lanciato fuss-client era ancora fermo a quel punto. ho bloccato il processo con CTRL*C per sfinimento. Questo pomeriggio posso tentare di lasciar andare il processo a oltranza
Io avevo messo in rete fino a quel punto 14 (+ o - 1) client. Il tempo non dovrebbe superare i due minuti o tre minuti, altrimenti l'aggancio dei client alla rete diventa un problema

#6 Updated by Piergiorgio Cemin over 4 years ago

Allego immagine del carido col comando top.
Si notano 4 processi ktutil, che occupano quasi tutta la memoria, sembrano aperti da tempo inenarrabile.
Ora provo per curiosità ad ammazzarli.

#7 Updated by Christopher R. Gabriel over 4 years ago

Piu' che la memoria direi la CPU. Nel syslog, auth.log o daemon log c'e' per caso qualcosa di rilevante?

#8 Updated by Piergiorgio Cemin over 4 years ago

Ho killato tutti i processi ktutil sul server, ho avviato fuss-client -a e si crea un processo
ktutil all'esecuzione di
kt_util: write_kt /etc/krb5.keytab (esecuzione si fa per dire) che occupa il 99% della CPU.
Dopo 11 minuti è ancora tutto fermo, con la CPU occupata dal processo ktutil dal 99 al 99,6%
(Scusa, prima ho sbagliato a scrivere, non la RAM)

#9 Updated by Piergiorgio Cemin over 4 years ago

  • Assignee changed from Elena Grandi to Christopher R. Gabriel

auth.log:

Jun 22 17:39:01 torri CRON21367: pam_unix(cron:session): session opened for user root by (uid=0)
Jun 22 17:39:01 torri CRON21367: pam_unix(cron:session): session closed for user root
Jun 22 17:40:01 torri CRON21428: pam_unix(cron:session): session opened for user root by (uid=0)
Jun 22 17:40:01 torri CRON21429: pam_unix(cron:session): session opened for user munin by (uid=0)
Jun 22 17:40:01 torri CRON21428: pam_unix(cron:session): session closed for user root
Jun 22 17:40:08 torri CRON21429: pam_unix(cron:session): session closed for user munin
Jun 22 17:45:01 torri CRON21871: pam_unix(cron:session): session opened for user munin by (uid=0)
Jun 22 17:45:01 torri CRON21870: pam_unix(cron:session): session opened for user root by (uid=0)
Jun 22 17:45:01 torri CRON21870: pam_unix(cron:session): session closed for user root
Jun 22 17:45:08 torri CRON21871: pam_unix(cron:session): session closed for user munin

syslog:

un 22 17:47:22 torri named554: client 127.0.0.1#28582/key torri.etorricelli.blz: signer "torri.etorricelli.blz" approved
Jun 22 17:47:22 torri named554: client 127.0.0.1#28582/key torri.etorricelli.blz: updating zone 'etorricelli.blz/IN': deleting rrset at 'info-01.etorricelli.blz' A
Jun 22 17:47:22 torri named554: client 127.0.0.1#28582/key torri.etorricelli.blz: updating zone 'etorricelli.blz/IN': adding an RR at 'info-01.etorricelli.blz' A
Jun 22 17:47:22 torri dhcpd: Added new forward map from info-01.etorricelli.blz to 192.168.10.76
Jun 22 17:47:22 torri dhcpd: DHCPREQUEST for 192.168.10.76 from 78:e3:b5:92:87:ad (info-01) via eth1
Jun 22 17:47:22 torri dhcpd: DHCPACK on 192.168.10.76 to 78:e3:b5:92:87:ad via eth1
Jun 22 17:47:22 torri named554: client 127.0.0.1#28582/key torri.etorricelli.blz: signer "torri.etorricelli.blz" approved
Jun 22 17:47:22 torri named554: client 127.0.0.1#28582/key torri.etorricelli.blz: updating zone '10.168.192.in-addr.arpa/IN': deleting rrset at '76.10.168.192.in-addr.arpa' PTR
Jun 22 17:47:22 torri named554: client 127.0.0.1#28582/key torri.etorricelli.blz: updating zone '10.168.192.in-addr.arpa/IN': adding an RR at '76.10.168.192.in-addr.arpa' PTR
Jun 22 17:47:33 torri named554: error (unexpected RCODE SERVFAIL) resolving 'natalia.fuss.bz.it/A/IN': 62.48.33.132#53
Jun 22 17:48:09 torri named554: error (network unreachable) resolving './NS/IN': 2001:503:ba3e::2:30#53
Jun 22 17:48:09 torri named554: error (network unreachable) resolving 'firefox.com/DS/IN': 2001:503:ba3e::2:30#53
Jun 22 17:48:48 torri named554: client 127.0.0.1#28582/key torri.etorricelli.blz: updating zone 'etorricelli.blz/IN': update unsuccessful: lab-fisica-01.etorricelli.blz: 'name not in use' prerequisite not satisfied (YXDOMAIN)
Jun 22 17:48:48 torri dhcpd: DHCPREQUEST for 192.168.10.61 from 00:0f:fe:d7:44:e0 (lab-fisica-01) via eth1
Jun 22 17:48:48 torri dhcpd: DHCPACK on 192.168.10.61 to 00:0f:fe:d7:44:e0 (lab-fisica-01) via eth1
Jun 22 17:48:48 torri named554: client 127.0.0.1#28582/key torri.etorricelli.blz: updating zone 'etorricelli.blz/IN': update unsuccessful: lab-fisica-01.etorricelli.blz: 'name not in use' prerequisite not satisfied (YXDOMAIN)
Jun 22 17:48:48 torri dhcpd: DHCPREQUEST for 192.168.10.61 from 00:0f:fe:d7:44:e0 (lab-fisica-01) via eth1
Jun 22 17:48:48 torri dhcpd: DHCPACK on 192.168.10.61 to 00:0f:fe:d7:44:e0 (lab-fisica-01) via eth1
Jun 22 17:48:48 torri named554: client 127.0.0.1#28582/key torri.etorricelli.blz: updating zone 'etorricelli.blz/IN': update unsuccessful: lab-fisica-01.etorricelli.blz/DHCID: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
Jun 22 17:48:48 torri named554: client 127.0.0.1#28582/key torri.etorricelli.blz: updating zone 'etorricelli.blz/IN': update unsuccessful: lab-fisica-01.etorricelli.blz: 'name not in use' prerequisite not satisfied (YXDOMAIN)
Jun 22 17:48:48 torri dhcpd: DHCPREQUEST for 192.168.10.61 from 00:0f:fe:d7:44:e0 (lab-fisica-01) via eth1
Jun 22 17:48:48 torri dhcpd: DHCPACK on 192.168.10.61 to 00:0f:fe:d7:44:e0 (lab-fisica-01) via eth1
Jun 22 17:48:48 torri named554: client 127.0.0.1#28582/key torri.etorricelli.blz: updating zone 'etorricelli.blz/IN': update unsuccessful: lab-fisica-01.etorricelli.blz/DHCID: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
Jun 22 17:48:48 torri dhcpd: Forward map from lab-fisica-01.etorricelli.blz to 192.168.10.61 FAILED: Has an address record but no DHCID, not mine.
Jun 22 17:48:48 torri named554: client 127.0.0.1#28582/key torri.etorricelli.blz: updating zone 'etorricelli.blz/IN': update unsuccessful: lab-fisica-01.etorricelli.blz: 'name not in use' prerequisite not satisfied (YXDOMAIN)
Jun 22 17:48:48 torri dhcpd: DHCPREQUEST for 192.168.10.61 from 00:0f:fe:d7:44:e0 (lab-fisica-01) via eth1
Jun 22 17:48:48 torri dhcpd: DHCPACK on 192.168.10.61 to 00:0f:fe:d7:44:e0 (lab-fisica-01) via eth1
Jun 22 17:48:48 torri named554: client 127.0.0.1#28582/key torri.etorricelli.blz: updating zone 'etorricelli.blz/IN': update unsuccessful: lab-fisica-01.etorricelli.blz/DHCID: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
Jun 22 17:48:48 torri dhcpd: Forward map from lab-fisica-01.etorricelli.blz to 192.168.10.61 FAILED: Has an address record but no DHCID, not mine.

#10 Updated by Christopher R. Gabriel over 4 years ago

  • Assignee changed from Christopher R. Gabriel to Elena Grandi

#11 Updated by Elena Grandi over 4 years ago

  • Status changed from Commenti to In elaborazione

#12 Updated by Elena Grandi over 4 years ago

  • Assignee changed from Elena Grandi to Piergiorgio Cemin

Una domanda: con quel server è stato aggiunto più volte lo stesso client (o più client, ma con lo stesso hostname) per fare prove?

Noto che facendolo il file /etc/krb5.keytab sul server sembra crescere con On² anziché con On come dovrebbe, il che giustificherebbe anche la lentezza dopo un po' di prove.

Intanto sistemo questa parte, ma mi servirebbe sapere se è quello il caso anche da voi per sapere se devo cercare altro

#13 Updated by Elena Grandi over 4 years ago

  • Status changed from In elaborazione to Commenti

Ho aggiornato sia fuss-server (versione 8.0.16-1) che fuss-client (versione 8.0.13): adesso l'aggiunta dello stesso client più volte non fa aumentare a dismisura /etc/krb5.keytab del server, che poteva essere una delle cause del rallentamento.

Per il server esistente che mostrava il problema, se è fattibile (macchina di prova con pochi client) si possono cancellare /etc/krb5.keytab sia sul server che sui client e riautenticare le macchine rilanciando fuss-client su tutti i client.
Se invece il numero di client che devono continuare a funzionare è significativo posso cercare / fornire una procedura per ricostruire un keytab ragionevole con il quale ripartire sul server

#14 Updated by Marco Marinello over 4 years ago

Necessario

fuss-server create
dopo aggiornamento del pacchetto da repository (su server)?

#15 Updated by Piergiorgio Cemin over 4 years ago

  • Assignee changed from Piergiorgio Cemin to Elena Grandi

OK.
Domani mattina:
aggiorno fuss-client e fuss-server
fuss-server create
fuss-client -r su tutti i client
elimino /etc/krb5.keytab su server e client e /etc/krb5.conf sui client
fuss-client -a sui client
Ti faccio poi sapere. Per le 10 dovrei aver fatto

#16 Updated by Marco Marinello over 4 years ago

Eseguendo fuss-client con altro utente ssh (opzione -u) ricevo errore alla terza richiesta di password:

scp: client.keytab: Permission denied

#17 Updated by Christopher R. Gabriel over 4 years ago

  • Assignee changed from Elena Grandi to Piergiorgio Cemin

L'utente utilizzato e' sudoer sul server?

#18 Updated by Marco Marinello over 4 years ago

Christopher R. Gabriel ha scritto:

L'utente utilizzato e' sudoer sul server?

Sì, trovato l'errore. Era stato aggiunto a sudo da /etc/sudoer e non al gruppo sudo. Una volta aggiunto funziona.
Forse da documentare nelle wiki che l'utente debba essere membro del gruppo sudo per eseguire l'aggancio.

#19 Updated by Christopher R. Gabriel over 4 years ago

E' gia' descritto sia nell'help del comando:

 
'-u', '--user',
            help=_("sudo-capable user on the server."),

e anche nell'errore che viene mostrato in caso di problemi con la generazione della chiave:

Key generation failed.

                    If this was because of user error (e.g. a wrong
                    password) please try again.

                    If you were asked for the root password and don't
                    have it, you can use ``-u USERNAME`` to specify a user
                    that is enabled to run sudo on the server.

#20 Updated by Piergiorgio Cemin over 4 years ago

  • Status changed from Commenti to Risolto
  • Assignee changed from Piergiorgio Cemin to Elena Grandi

Risollto. Ora l'agganccio è veloce e funziona.
Rifatto fuss-client su tutti i PC dell'aula info. Ora non c'è più il problema, dopo 23 client messi in rete

Also available in: Atom PDF