Bonjour, j'ai un besoin d'aide urgente : samedi matin nous avaons basculé notre exploitation d'un serveur NIS vers un nouveau server en LDAP (nous avions procédé à deux mois de tests avec quelques machines et tout allait bien)

Lundi matin, l'horreur, overload de fichiers, ca a ramé, planté... on a environ 90 machines sur le réseau et le serveur est un poweredge 2900.

On a essayé de corriger tous les raccourics qui pointaient encore vers le serveur NIS
On a augmenté la taille du nombre de fichiers ouverts autorisés... mais rien n'y fait, ca repart de te temsp en temps puis à nouveau le nombre de fichiers ouverts devient critique.

Le nombre de sockets ouverts est impressionnant et c'est apparemment ca qui fout en l'air le système.

Est-ce-que quelqu'un aurait une solution ?

merci d'avance
A combien t'as monte la limite de fd ouverts ? 2000 ? 4000 ? 8000 ?

(edit) Maintenant que j'te relis.. en fait, c'est pas vraiment normal pour un parc de seulement 90 machines. On est bien 200 personnes ici mais c'est vrai qu'on s'en sert pas pour l'autentification. Verifie que t'es bien a jour, et vois si y'a pas un bug deja rapporte sur le bugzilla.
On a passé le nombre de fichiers à 65000 ... et il est repassé tout seul comme un grand à 1024... on a refait la manip pour le réaugmenter

L'erreur qu'on a dans l'analyseur de système :

slapd 2425 Warning : cannot open /etc/hosts.deny : too many open files
On a passé le nombre de fichiers à 65000 ... et il est repassé tout seul comme un grand à 1024... on a refait la manip pour le réaugmenter
Le nombre de fichiers ouvert fait partie de l'environnement. C'est pas parce que tu fais "ulimit -n machin" que la limite change pour le systeme.
Il faut que la limite soit fixee par le processus pere avant de lancer le processus fils. De plus, il me semble que le noyau ait une limite dure a 4 ou 8000. Donc 65k, ca m'etonnerait que ca marche.
ok donc ca sert à rien ce qu'on a fait...

quelles est la bonne manip pour augmenter le nombre de fichiers ?
Vois le "man ulimit" d'un cote. Et de l'autre comme je te l'ai dit c'est environnemental, donc hérité d'un processus pere vers un processus fils. Donc tu positionnes la limite et tu redemarre le processus.

Ensuite il faut que tu saches que root impose sa propre limite aux users - toujours par heritage. Une sorte de limite "soft" qu'on peut monter jusqu'a la limite du noyau.

Mais encore une fois, je doute que tout ceci soit normal, donc va verifier le bugzilla.
Concernant LDAP, le service nscd est-il activé sur les clients, ce serait une bonne idée... (c'est un cache de résolution de noms très pratique dans le cas d'un annuaire centralisé, nis ou ldap)

Voir aussi le ldap.conf des clients qui contient des paramètres de réglages des connexions.

A+
OK, donc j'ai activé nscd qui ne l'atait pas sur mon poste.

Dans les ldap.conf des users j'ai uniquement ca :
host 192.168.174.220
base dc=ia74
nss_initgroups_ignoreusers root,ldap
ssl no
tls_cacertdir /etc/openldap/cacerts
pam_password md5

rien de concluant chez bugzilla.

j'ai lu ça : http://www.linuxplusvalue.be/mylpv.php?id=203
mais j'avoue que je ne comprend pas tout

Sinon, on a ça dans les logs pour chaque utilisateur qui essaie de se connecter :
sur le serveur :
automount : /usr/sbin/showmount : can't get address for .directory
automount : lookup for .directory failed
automount : failed to mount /net/.directory
automount : >>mount n'est pas un répertoire
automount : mount(nfs): nfs: mount failure 192.168.174.220:/home.diectory on /home/.directory
automount : failed to mount /home/.directory


sur les clients :
Mar 20 16:07:02 ia74-amarylis automount[10438]: lookup(ldap): got answer, but no first entry for (&(objectclass=nisObject)(cn=.directory))
Mar 20 16:07:02 ia74-amarylis automount[10438]: lookup(ldap): got answer, but no first entry for (&(objectclass=automount)(cn=.directory))
Mar 20 16:07:02 ia74-amarylis automount[10438]: lookup(ldap): got answer, but no first entry for (&(objectclass=nisObject)(cn=/))
Mar 20 16:07:03 ia74-amarylis automount[10438]: >> mount: N'est pas un répertoire
Mar 20 16:07:03 ia74-amarylis automount[10438]: mount(nfs): nfs: mount failure 192.168.174.220:/home/.directory on /home/.directory
Mar 20 16:07:03 ia74-amarylis automount[10438]: failed to mount /home/.directory

ca n'arrete pas, est-ce que ca peut plomber les perfs ce genre de fichier introuvable ?
Comme on a migré les données du serveur NIS avec les scripts fournis avec OpenLDAP, est-il possible qu'il y ait des soucis dans la conversion de certains paramètres qui donneraient ce .directory qui fait tâche ?
Pas franchement le problème vient des postes clients mais tu peux faire une rapide recherche dans les scripts en question si tu veux.

Si on relit en fait, les postes clients continuent à se connecter comme s'ils utilisaient nis (un script) --> (objectclass=nisObject)(cn=.directory).

Vous avez fait les tests avec des postes vierges ou deja sur le réseau géré.
Je sais pas si cela peut aider mais j'ai déja eu ce genre de problèmes...

Le nombre maximal de fichiers ouvert géré par le kernel est un problème connu

sous root,

cat 65535 >/proc/sys/fs/file-max

bien entendu, si on veut pas le refaire à chaque fois, il faut faire un script qui sera lancé au rc.local pas exemple


On peut procéder plus proprement avec sysctl et le fichier associé /etc/sysctl.conf


# increase system file descriptor limit
fs.file-max = 65535


Un lien interessant pour le sysadmins et autres geeks

Administrer le kernel linux à la vollée (en anglais)
d'ailleurs on y retrouve pas mal de descriptions interessantes

/proc/sys/fs/file-max
This specifies the maximum number of file handles that can be allocated. You may need to increase this value if users get error messages stating that they cannot open more files because the maximum number of open files has been reached. This can be set to any number of files and can be changed by writing a new numeric value to the file.

Default setting: 4096
Ok, on a fait un test avec un nouveau compte créé sur ldap et qui n'existait pas sur le NIS --> il ne tente pas de connexions vers un .directory.

Demain on va regarder tous les comptes et voir où peut être le truc qui coince.

Merci pour votre aide !

On a deja tenté d'augmenter le file-max mais ca n'a rien changé.
a titre d'information le file-max ne fait que changer la limite maximum que ulimit vous permettra de fixer par la suite. On retombe sur nos pattes donc.
5 jours plus tard
On a fini par isoler le problème :
des postes encore sous FC3 tentaient de se connecter à un cn inexistant du nom de .directory
On n'a pas trouvé d'où ca venait mais du coup on en profite pour migrer ces qulques postes en FC6 qui eux ne posent pas de problèmes.
Le seul indice qu'on ait c'est que le script qu'on a lancé pour passer tous les postes en LDAP a foiré sur les FC3 et FC4, ca doit tenir de la vétusté des systèmes.

Si quelqu'un a une idée de la cource du problème, j'aimerais bien comprendre !
21 jours plus tard
Je reposte pour savoir si quelqu'un aurait une idée :

J'ai passé tout mon parc en FC5 et FC6. Les anciens postes qui tournaient en NIS et qui ont été passés sous LDAP. A priori il reste des bribes de config de NIS, certains postes font des appels à /home/nis qui n'existe plus et ca me pourrit mon serveur. Quels sont les fichiers qui contiennent une config spécifique à NIS, sachant que ca ne tient pas aux comptes des utiliseurs mais à la config locale ?

Par contre je suis toujours cantonné à un peu plus de 1000 fichiers ouverts en même temps et ca bloque au bout d'un moment. J'ai 90 utilisateurs et il faudrait que je puisse augmenter ce nombre mais je ne trouve pas où c'est.
On a commencé par réinstaller deux PC qui ouvraient des ports pour NIS : depuis la réinstallation, plus de soucis. Il y a donc un paramétrage qui reste de l'ancienne config, mais je ne trouve pas dans quel fichier...
4 mois plus tard
Ca y est j'ai trouvé ce qu'il fallait ajouter à ma configuration :

dans le fichier /etc/openldap/slapd.conf il faut ajouter la ligne idletimeout 20
Cela ferme les ports ouverts qui ne sont plus utilisés pendant 20 secondes. Maintenant que j'ai mis ce paramètre tout marche parfaitement.