Probleme avec NIS: Unable to send; errno = Operation not permitted
2 réponses
Cyril Bouthors
Je tombe actuellement sur des problemes non reproductibles avec NIS:
j'ai de temps en temps l'erreur suivante quand j'essaye d'acceder aux
informations utilisateurs (uid, homedir, ...) comme par exemple avec
la commande "chown www-data file":
do_ypcall: clnt_call: RPC: Unable to send; errno = Operation not permitted
et bien sur chown plante juste apres, alors que la meme commande
fonctionne dans 99%+ des cas. On dirait que c'est quand meme lie a la
charge, ca arrive relativement souvent pendant les cron.daily.
J'utilise un maitre NIS contenant plusieurs milliers d'utilisateurs et
une quainzaine d'esclaves NIS. Ce probleme apparait partout.
Je pense a une limite depassee dans certains cas, comme le nombre
maximum de connexions concurrentes ou quelque chose comme ca mais je
ne trouve rien. Google trouve seulement 4 pages a propos de cette
erreur sur le web et aucune sur usenet, aucune reponse.
Joyeux Noel avec NIS.
--
Cyril Bouthors
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Antoine Bellot
Cyril Bouthors a écrit:
do_ypcall: clnt_call: RPC: Unable to send; errno = Operation not permitted
à vue de nez comme ça, ton problème semble provenir du fait que portmap ne répond pas/plus.
Pourrais-tu préciser ce qu'est exactement ton portmapper/ton serveur NIS ? A-t-il quelque chose dans ses logs, voire les logs de tcpd ? Le système sous-jacent utilise-t-il un filtre de paquets ou un mécanisme de protection contre le déni de services ? existe-t-il un équipement réseau intermédiaire (au hasard, un switchL3 Cisco) qui dispose de mécanismes de protection contre les dénis de service ?
Tu peux probablement limiter le problème en modifiant tes scripts pour utiliser des UIDs/GIDs extraits de fichiers statiques régulièrement diffusés depuis le serveur NIS (via ssh, par exemple) pour éviter de trop charger NIS pour les scripts de maintenance.
-- Antoine Bellot : It's not an exact reference, due to the fact that the API changes from version to version, and that the kernel API is not required to match the documentation. -- Jamie Lokier abt LDD-3
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Cyril Bouthors a écrit:
do_ypcall: clnt_call: RPC: Unable to send; errno = Operation not permitted
à vue de nez comme ça, ton problème semble provenir du fait que portmap
ne répond pas/plus.
Pourrais-tu préciser ce qu'est exactement ton portmapper/ton serveur NIS
? A-t-il quelque chose dans ses logs, voire les logs de tcpd ? Le
système sous-jacent utilise-t-il un filtre de paquets ou un mécanisme de
protection contre le déni de services ? existe-t-il un équipement réseau
intermédiaire (au hasard, un switchL3 Cisco) qui dispose de mécanismes
de protection contre les dénis de service ?
Tu peux probablement limiter le problème en modifiant tes scripts pour
utiliser des UIDs/GIDs extraits de fichiers statiques régulièrement
diffusés depuis le serveur NIS (via ssh, par exemple) pour éviter de
trop charger NIS pour les scripts de maintenance.
--
Antoine Bellot :
It's not an exact reference, due to the fact that the API changes
from version to version, and that the kernel API is not required
to match the documentation. -- Jamie Lokier abt LDD-3
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
do_ypcall: clnt_call: RPC: Unable to send; errno = Operation not permitted
à vue de nez comme ça, ton problème semble provenir du fait que portmap ne répond pas/plus.
Pourrais-tu préciser ce qu'est exactement ton portmapper/ton serveur NIS ? A-t-il quelque chose dans ses logs, voire les logs de tcpd ? Le système sous-jacent utilise-t-il un filtre de paquets ou un mécanisme de protection contre le déni de services ? existe-t-il un équipement réseau intermédiaire (au hasard, un switchL3 Cisco) qui dispose de mécanismes de protection contre les dénis de service ?
Tu peux probablement limiter le problème en modifiant tes scripts pour utiliser des UIDs/GIDs extraits de fichiers statiques régulièrement diffusés depuis le serveur NIS (via ssh, par exemple) pour éviter de trop charger NIS pour les scripts de maintenance.
-- Antoine Bellot : It's not an exact reference, due to the fact that the API changes from version to version, and that the kernel API is not required to match the documentation. -- Jamie Lokier abt LDD-3
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Cyril Bouthors
Antoine Bellot writes:
à vue de nez comme ça, ton problème semble provenir du fait que portmap ne répond pas/plus.
Je n'avais pas pense a ca, je vais creuser dans ce sens et reviendrai poster ici si besoin. C'est une tres bonne piste a mon sens car j'ai aussi des problemes avec NFS:
Alors que je ne constate rien sur le serveur, j'ai de temps en temps cela dans les logs des clients NFS:
kernel: nfs: server 10.0.0.1 not responding, still trying kernel: nfs: server 10.0.0.1 OK
Et sur le systeme, un find ou un quelconque autre acces aux fichiers montes en NFS reponds de temps en temps "Operation not permitted" et echoue. Je n'ai pas non plus reussi a reproduire le probleme. Ca le fait essentiellement aux periodes de pointe.
Pourrais-tu préciser ce qu'est exactement ton portmapper
Celui du package "portmap" dans Debian/Sid.
ton serveur NIS ?
Celui du package "nis" dans Debian/Sid.
A-t-il quelque chose dans ses logs, voire les logs de tcpd ?
Rien de special.
Le système sous-jacent utilise-t-il un filtre de paquets ou un mécanisme de protection contre le déni de services ?
Non.
existe-t-il un équipement réseau intermédiaire (au hasard, un switchL3 Cisco) qui dispose de mécanismes de protection contre les dénis de service ?
Non, le seul equipement reseau intermediaire est un switch FastEthernet D-Link simple, non manageable.
Tu peux probablement limiter le problème en modifiant tes scripts pour utiliser des UIDs/GIDs extraits de fichiers statiques régulièrement diffusés depuis le serveur NIS
L'idee de base etait d'utiliser NIS en local configure en tant que slave pour accomplir la meme tache: les fichiers statiques sont diffuses a chaque mise a jour grace a ypxfr. C'est (en theorie) distribue et resistant aux pannes, en pratique j'ai des "Operation not permitted" reguliers.
Je suis un utilisateur novice de NIS et je m'apercois que ca ne marche pas si bien que ca devrait, je vais donc peut etre utiliser le systeme classique de fichiers passwd en DB, qui fonctionne, principalement parce qu'il est simplissime (1 fichier).
Je n'ai pas trouve de documentation expliquant comment configurer un systeme pour utiliser passwd.db et non /etc/passwd. Une piste ? -- Cyril Bouthors
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Antoine Bellot <Antoine.Bellot@eat-it.ath.cx> writes:
à vue de nez comme ça, ton problème semble provenir du fait que
portmap ne répond pas/plus.
Je n'avais pas pense a ca, je vais creuser dans ce sens et reviendrai
poster ici si besoin. C'est une tres bonne piste a mon sens car j'ai
aussi des problemes avec NFS:
Alors que je ne constate rien sur le serveur, j'ai de temps en temps
cela dans les logs des clients NFS:
kernel: nfs: server 10.0.0.1 not responding, still trying
kernel: nfs: server 10.0.0.1 OK
Et sur le systeme, un find ou un quelconque autre acces aux fichiers
montes en NFS reponds de temps en temps "Operation not permitted" et
echoue. Je n'ai pas non plus reussi a reproduire le probleme. Ca le
fait essentiellement aux periodes de pointe.
Pourrais-tu préciser ce qu'est exactement ton portmapper
Celui du package "portmap" dans Debian/Sid.
ton serveur NIS ?
Celui du package "nis" dans Debian/Sid.
A-t-il quelque chose dans ses logs, voire les logs de tcpd ?
Rien de special.
Le système sous-jacent utilise-t-il un filtre de paquets ou un
mécanisme de protection contre le déni de services ?
Non.
existe-t-il un équipement réseau intermédiaire (au hasard, un
switchL3 Cisco) qui dispose de mécanismes de protection contre les
dénis de service ?
Non, le seul equipement reseau intermediaire est un switch
FastEthernet D-Link simple, non manageable.
Tu peux probablement limiter le problème en modifiant tes scripts
pour utiliser des UIDs/GIDs extraits de fichiers statiques
régulièrement diffusés depuis le serveur NIS
L'idee de base etait d'utiliser NIS en local configure en tant que
slave pour accomplir la meme tache: les fichiers statiques sont
diffuses a chaque mise a jour grace a ypxfr. C'est (en theorie)
distribue et resistant aux pannes, en pratique j'ai des "Operation not
permitted" reguliers.
Je suis un utilisateur novice de NIS et je m'apercois que ca ne marche
pas si bien que ca devrait, je vais donc peut etre utiliser le systeme
classique de fichiers passwd en DB, qui fonctionne, principalement
parce qu'il est simplissime (1 fichier).
Je n'ai pas trouve de documentation expliquant comment configurer un
systeme pour utiliser passwd.db et non /etc/passwd. Une piste ?
--
Cyril Bouthors
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
à vue de nez comme ça, ton problème semble provenir du fait que portmap ne répond pas/plus.
Je n'avais pas pense a ca, je vais creuser dans ce sens et reviendrai poster ici si besoin. C'est une tres bonne piste a mon sens car j'ai aussi des problemes avec NFS:
Alors que je ne constate rien sur le serveur, j'ai de temps en temps cela dans les logs des clients NFS:
kernel: nfs: server 10.0.0.1 not responding, still trying kernel: nfs: server 10.0.0.1 OK
Et sur le systeme, un find ou un quelconque autre acces aux fichiers montes en NFS reponds de temps en temps "Operation not permitted" et echoue. Je n'ai pas non plus reussi a reproduire le probleme. Ca le fait essentiellement aux periodes de pointe.
Pourrais-tu préciser ce qu'est exactement ton portmapper
Celui du package "portmap" dans Debian/Sid.
ton serveur NIS ?
Celui du package "nis" dans Debian/Sid.
A-t-il quelque chose dans ses logs, voire les logs de tcpd ?
Rien de special.
Le système sous-jacent utilise-t-il un filtre de paquets ou un mécanisme de protection contre le déni de services ?
Non.
existe-t-il un équipement réseau intermédiaire (au hasard, un switchL3 Cisco) qui dispose de mécanismes de protection contre les dénis de service ?
Non, le seul equipement reseau intermediaire est un switch FastEthernet D-Link simple, non manageable.
Tu peux probablement limiter le problème en modifiant tes scripts pour utiliser des UIDs/GIDs extraits de fichiers statiques régulièrement diffusés depuis le serveur NIS
L'idee de base etait d'utiliser NIS en local configure en tant que slave pour accomplir la meme tache: les fichiers statiques sont diffuses a chaque mise a jour grace a ypxfr. C'est (en theorie) distribue et resistant aux pannes, en pratique j'ai des "Operation not permitted" reguliers.
Je suis un utilisateur novice de NIS et je m'apercois que ca ne marche pas si bien que ca devrait, je vais donc peut etre utiliser le systeme classique de fichiers passwd en DB, qui fonctionne, principalement parce qu'il est simplissime (1 fichier).
Je n'ai pas trouve de documentation expliquant comment configurer un systeme pour utiliser passwd.db et non /etc/passwd. Une piste ? -- Cyril Bouthors
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
