Premier sudo toujours lent


8

La première fois sudoque j'entre sur mon serveur Ubuntu 14.04 est toujours lente. L'invite de mot de passe s'affiche immédiatement, mais après avoir appuyé sur Entrée, il faut environ 10 à 15 secondes pour imprimer la sortie. Toutes les commandes sudo après cela s'exécutent instantanément.

L'exécution de quelque chose comme sudo strace -S time -c sudo echo hine montre rien d'utile dans ce cas, car le sudo de sudo echo hiest déjà le deuxième sudo et s'exécute rapidement. Si un certain temps s'écoule et que je dois ressaisir le mot de passe dans une session en cours, il est à nouveau lent.

Toutes les solutions que j'ai trouvées consistaient à ajouter votre nom d'hôte comme résolution pour 127.0.0.1 dans le /etc/hostsfichier, ce que j'ai fait en vain. su roots'exécute instantanément. La seule chose dont je me souviens avoir changé au cours des derniers jours est le masque de réseau d'un sous-réseau que le serveur achemine, installant samba, dnsutils et bind9. Mais aucun de ces processus n'est en cours d'exécution et le problème persiste, dans l'accès physique, aux sessions ssh ainsi qu'aux sessions tmux.

EDIT: Nouvelle approche

J'ai essayé de courir sudo tcpdump -vvvi any > tcpdump.log tout en déconnectant tous les NIC. Le journal présente un grand nombre des éléments suivants:

18:35:09.453399 IP (tos 0x0, ttl 64, id 49112, offset 0, flags [DF], proto UDP (17), length 76)
    localhost.38498 > localhost.domain: [bad udp cksum 0xfe4b -> 0x1050!] 58546+ SRV? _kerberos._udp.KF.OURLOCALDOMAIN.DE. (48)
18:35:09.457412 IP (tos 0x0, ttl 64, id 49113, offset 0, flags [none], proto UDP (17), length 76)
    localhost.domain > localhost.38498: [bad udp cksum 0xfe4b -> 0x8fcd!] 58546 ServFail q: SRV? _kerberos._udp.KF.OURLOCALDOMAIN.DE. 0/0/0 (48)

Les mêmes entrées apparaissent avec tcp instad de udp. J'ai remplacé le nom de domaine de notre université par OURLOCALDOMAIN.

Maintenant, je pense que kerberos pourrait avoir quelque chose à voir avec cela, mais j'ai supprimé le /etc/krb5.conf et redémarré, toujours pas de changement. Il me semble que le serveur essaie de se valider sur un serveur central kerberos de notre réseau universitaire. Je sais que quelques années auparavant, cette IP était enregistrée sur un serveur qui exécutait la samba pour notre département. Pourrait-il y avoir une connexion? J'ai changé mon nom d'hôte en celui qui était utilisé à l'époque, aucun changement dans le comportement de sudo. Lmwangi suggère quelque chose à propos de PAM, que je connais peu, donc je ne sais pas comment aborder cela. Je me suis également souvenu que j'étais passé de Heimdal Kerberos à MIT Kerberos lors de l'installation de samba, car j'avais des problèmes lors de l'installation de samba. Je vais également essayer les idées des commentaires dans les prochains jours, mais je voyagerai pendant quelques jours donc cela pourrait prendre un certain temps.

EDIT 2: Résolu

Il y avait une entrée de recherche DNS héritée dans le /etc/network/interfacesqui a tout gâché. Je me sens très stupide. Tout fonctionne maintenant.


1
Activer temporairement le bit set-uid stracevous permettra de l'exécuter sans le premier sudo. Il peut également être utile d'utiliser l' -o <file>option pour enregistrer la sortie dans un fichier pour analyse.
garethTheRed

1
C'est celui-là. Ensuite, suivez-le avec sudo -kpour supprimer vos informations d'identification mises en cache. J'ai trouvé cela strace -Tro sudo.log sudo echo hiutile car la dernière colonne indique l'heure de chaque appel. greppour unameet socketen entrée.
garethTheRed

1
Le 5.005153 secondes est de l' -roption (qui devrait peut-être être supprimée). Commencez par la recherche pour les longs appels de la -Tpossibilité - ils sont ceux au sein du <et >- 0,000097 sec dans votre cas.
garethTheRed

1
Avez-vous vérifié ps, top et tous les fichiers journaux du système au cas où quelque chose d'autre se produirait pour causer la lenteur?
mdpc

1
Pouvez-vous publier votre configuration pam? stracevous y arrivera éventuellement, mais il s'agit probablement d'un problème de configuration de niveau supérieur. La plupart des longues pauses pendant l'authentification sont dues à l'échec de l'accès aux serveurs distants et à l'attente d'un délai d'attente. Il se peut que le changement de sous-réseau place le serveur d'authentification sur un sous-réseau différent de celui-ci. sudoenregistre temporairement un enregistrement d'authentification réussie en dessous /var, c'est pourquoi les invocations suivantes sont instantanément exécutées.
Bratchley

Réponses:


2

Je soupçonne que votre box tente de contacter un service d'authentification externe (pensez à NIS / LDAP) à l'aide de PAM ...

Si je comprends bien PAM, vous ne pourriez pas voir la recherche PAM dans vos appels strace. Je vous suggère d'exécuter tshark / tcpdump et de voir si vous pouvez corréler un trafic réseau spécifique à vos tentatives sudo. Les suspects ici seraient des recherches DNS et | Appels LDAP.

tcpdump -i eth0 -w network.pcap -s0 -Av

Si vous découvrez la cause des recherches, recherchez le module PAM approprié pour modifier et résoudre le problème. Alternativement, s'il s'agit d'une recherche DNS, ajoutez simplement une entrée / etc / hosts pour truquer le nom et rediriger vers localhost. Cela rendra votre sudo rapide car la recherche sera rapide et redirigera vers l'hôte local et la transaction réseau échouera rapidement car il n'y a rien à écouter sur localhost ...


Maintenant, cela semble aller dans la bonne direction. J'ai beaucoup d'appels «bad udp cksum» et «bad tcp cksum» dans mon journal. Il est trop long pour poster dans un commentaire donc je mettrai à jour l'OP dans une seconde.
zerweck
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.