Ubuntu 16.04 Sudo avec NIS trop lent, lie (2) lotta ports et reste lotta connection entre le serveur de domaine NIS
Le titre dit tout. Quoi qu'il en soit, je viens de mettre à niveau mon serveur de 14.04 LTS à 16.04 LTS et j'ai réalisé que le Sudo fonctionne trop lentement que 14.04.
Je me suis battu et j'ai obtenu le résultat suivant:
$ Sudo strace Sudo true
---------------------------- snip ---------------- ---------------
...
socket (PF_INET, SOCK_STREAM, IPPROTO_TCP) = 9
bind ( 9, {sa_family = AF_INET, sin_port = htons (722), sin_addr = inet_addr ("0.0.0.0")}, 16) = -1 EADDRINUSE (Adresse déjà utilisée)
Bind (9, {sa_family = AF_INET, sin_port = htons (723), sin_addr = inet_addr ("0.0.0.0")}, 16) = -1 EADDRINUSE (Adresse déjà utilisée)
Bind (9, {sa_family = AF_INET, sin_port = htons (724), sin_addr = inet_addr ("0.0.0.0")}, 16) = -1 EADDRINUSE (adresse déjà utilisée)
Bind (9, {sa_family = AF_INET, sin_port = htons (725), sin_addr = inet_addr ("0.0.0.0")}, 16) = -1 EADDRINUSE (adresse déjà utilisée)
bind (9, {sa_family = AF_INET, sin_port = htons (726), sin_addr = inet_addr ("0.0 .0.0 ")}, 16) = -1 EADDRINUSE (Adresse déjà utilisée)
Bind (9, {sa_family = AF_INET, sin_port = htons (727), sin_addr = inet_addr (" 0.0.0.0 ")} , 16) = -1 EADDRINUSE (Adresse déjà utilisée)
Bind (9, {sa_family = AF_INET, sin_port = htons (728), sin_addr = inet_addr ("0.0.0.0")}, 16) = -1 EADDRINUSE (adresse déjà utilisée)
bind (9, {sa_family = AF_INET, sin_port = htons (729), sin_addr = inet_addr (" 0.0.0.0 ")}, 16) = -1 EADDRINUSE (adresse déjà utilisée)
Bind (9, {sa_family = AF_INET, sin_port = htons (730), sin_addr = inet_addr (" 0.0.0.0 ") }, 16) = -1 EADDRINUSE (Adresse déjà utilisée)
Bind (9, {sa_family = AF_INET, sin_port = htons (731), sin_addr = inet_addr ("0.0.0.0")}, 16) = -1 EADDRINUSE (Adresse déjà utilisée)
Bind (9, {sa_family = AF_INET, sin_port = htons (732), sin_addr = inet_addr ("0.0.0.0")}, 16) = -1 EADDRINUSE (Adresse déjà utilisé)
bind (9, {sa_family = AF_INET, sin_port = htons (733), sin_addr = inet_addr ("0.0.0.0")}, 16) = -1 EADDRINUSE (adresse déjà utilisée)
bind (9, {sa_family = AF_INET, sin_port = htons (734), sin_addr = inet_addr ("0.0.0.0")}, 16) = -1 EADDRINUSE (Adresse déjà utilisée)
bind (9, {sa_family = AF_INET, sin_port = htons (735), sin_addr = inet_addr ("0.0.0.0")}, 16) = -1 EADDRINUSE (adresse déjà en cours d'utilisation)
bind (9, {sa_family = AF_INET, sin_port = htons (736), sin_addr = inet_addr ("0.0.0.0")}, 16) = -1 EADDRINUSE (adresse déjà utilisée)
bind (9, {sa_family = AF_INET, sin_port = htons (737), sin_addr = inet_addr ("0.0.0.0")}, 16) = -1 EADDRINUSE (Adresse déjà utilisée)
bind ( 9, {sa_family = AF_INET, sin_port = htons (738), sin_addr = inet_addr ("0.0.0.0")}, 16) = -1 EADDRINUSE (Adresse déjà utilisée)
Bind (9, {sa_family = AF_INET, sin_port = htons (739), sin_addr = inet_addr ("0.0.0.0")}, 16) = -1 EADDRINUSE (Adresse déjà utilisée)
...
---------------------------- snip -------------------- -----------
Le commandement Sudo lui-même a réussi, cela a pris trop de temps, comme 5 sec.
La plage de ports est 512-1023, il semble qu'il essaie de lier le port de privilège pour quelque chose comme garantir qu'il a le privilège de superutilisateur.
Et après la réussite du Sudo, netstat -an spectacles:
---------------------------- snip ---------------- --------------- ... tcp 0 0 192.168.0.10:959 192.168.0.1:617 TIME_WAIT tcp 0 0 192.168.0.10:910 192.168.0.1:617 TIME_WAIT tcp 0 0 192.168.0.10:932 192.168.0.1:617 TIME_WAIT tcp 0 0 192.168.0.10:34470 192.168. 0,1: 111 TIME_WAIT Tcp 0 0192.168.0.10:966 192.168.0.1:617 TIME_WAIT Tcp 0 0192.168.0.10:903 192.168.0.1:617 TIME_WAIT Tcp 0 0 192.168.0.10:875 192.168.0.1:617 TIME_WAIT Tcp 0 0 192.168.0.10:45452 192.168.0.1:111 TIME_WAIT Tcp 0 0 192.168.0.10:970 192.168.0.1:617 TIME_WAIT tcp 0 0 192.168.0.10:907 192.168.0.1:617 TIME_WAIT tcp 0 0 192.168.0.10:41063 192.168.0.1:111 TIME_WAIT tcp 0 0 192.168.0.10:45659 192.168.0.1:111 TIME_WAIT Tcp 0 0 192.168.0.10:948 192.168.0.1:617 TIME_WAIT Tcp 0 0 192.168.0.10:50370 192.168.0.1:111 TIME_WAIT Tcp 0 0 192.168.0.10:56145 192.168.0.1:111 TIME_WAIT Tcp 0 0 192.168.0.10:929 192.168.0.1:617 TIME_WAIT Tcp 0 0 192.168.0.10 : 909 192.168.0.1:617 TIME_WAIT Tcp 0 0 192.168.0.10:33648 192.168.0.1:111 TIME_WAIT Tcp 0 0 192.168.0.10:33556 192.168.0.1:111 TIME_WAIT tcp 0 0 192.168.0.10:55209 192.168.0.1:111 TIME_WAIT tcp 0 0 192.168.0.10:975 192.168.0.1:617 TIME_WAIT tcp 0 0 192.168.0.10:969 192.168.0.1 : 617 TIME_WAIT Tcp 0 0 192.168.0.10:35903 192.168.0.1:111 TIME_WAIT Tcp 0 0 192.168.0.10:888 192.168.0.1:617 TIME_WAIT ... -------------------------- - snip -------------------------------
Où 192.168.0.10 est mon serveur et 192.168.0.1 est le serveur NIS.
Lorsque j'arrête le ypbind sur mon serveur et exécute le Sudo, plus aucune liaison inutile (2) et plus TIME_WAIT entre mon serveur et le serveur NIS ne sont observés.
Je ne peux pas arrêter le ypbind et je veux que mon ancienne vitesse agile Sudo retourne si mal B)
Que puis-je faire?
Je vous remercie
Nous avons rencontré le même comportement après la mise à niveau de deux systèmes vers 16.04 LTS. Nous utilisons le mode compat avec NIS pour choisir de manière sélective, via + @ netgroup et + user dans/etc/passwd, qui du domaine NIS plus large peut accéder à nos systèmes.
Mon collègue - qui devrait obtenir tout le crédit, mais ne fait pas la chose StackExchange - a trouvé une solution de contournement qui vous permet de conserver le mode compat et la possibilité d'utiliser + @ netgroup et + user dans/etc/passwd. Laissez le mode compat pour passwd et shadow, mais utilisez "files nis" pour le groupe dans /etc/nsswitch.conf:
passwd: compat
shadow: compat
group: files nis
Le mode "compat" pour/etc/group est équivalent à "files nis" si tout ce que vous voulez faire est d'inclure l'intégralité du mappage de groupe NIS.
J'aimerais savoir si cela fonctionne pour votre situation.
J'ai eu le même problème en utilisant des groupes et des utilisateurs NIS. L'authentification de chaque utilisateur est douloureusement lente. Vous pouvez également tcpdumper le trafic entre le client et le serveur NIS et voir une tempête inhabituelle de paquets se passer entre les deux pendant une minute dans mon cas.
Je suis allé jouer avec la config et j'ai eu l'idée de changer la config a la redhat et ça change complètement le comportement de l'auth, login, Sudo très vite. Supprimez simplement le "+ ::::" de/etc/passwd,/etc/shadow,/etc/group et le fichier nsswitch.conf pour modifier les lignes suivantes:
passwd: files nis
group: files nis
shadow: files nis
Dites-moi comment ça se passe.