Je gère les clients NIS sur le bureau Ubuntu dans nos laboratoires d’étudiants. Dans le cadre de notre projet d’été, j’ai installé Ubuntu 18.04 sur un PC et y ai installé un client NIS. Tout semblait aller bien, le domaine est correct, ypwhich
name__, ypcat
et yptest
fonctionnent tous correctement.
Cependant, lorsque je me connecte à l'aide d'un compte NIS (avec un domicile local ou NFS), GDM et LightDM (j'ai essayé les deux) se bloquent et, éventuellement, X se bloque. Fonctionne bien avec un compte local et un répertoire personnel.
Le journal des erreurs ne montre que ce message:
pam_systemd(sshd:session): failed to create session
Si j'essaye le même login NIS en utilisant juste un terminal (Ctrl+Alt+F1) Je peux m'authentifier, mais la session se bloque pendant environ 25 secondes avant de me donner un bash Shell, le répertoire personnel, qu'il soit local ou NFS, est monté correctement. Cela a bien fonctionné pour moi dans Ubuntu 16.04. (J'ai dû ajouter la ligne suivante pour que systemd lance rpc.bind: /bin/systemctl add-wants multi-user.target rpcbind.service
.) J'ai essayé avec Ubuntu 18.04 sans succès. Il semble y avoir un délai entre l'authentification et la création de la session qui est à l'origine de ce problème. J'ai téléchargé et installé les dernières mises à jour, etc., ainsi que le dernier apt-get
, etc.
Merci pour les réponses. J'ai essayé d'installer lightdm et j'ai eu un petit succès en me connectant en tant qu'utilisateur NIS à X. Cependant, je l'ai trouvé incohérent, me connectant parfois à X, parfois à l'expiration, donc impossible à utiliser en laboratoire. J'ai réinstallé 16.04 à nouveau et cela a bien fonctionné, donc j'allais le laisser jusqu'à 18.04 lits un peu. Après avoir fait cela, Paulo, je viens de voir votre réponse! Je vais jeter un oeil à la réinstallation de 18.04 et je reviendrai à la vôtre
Essayé Paulos astuce comme ci-dessus. Malheureusement, je ne pouvais pas mapper les mêmes fichiers d'installation sur Ubuntu 18.04 (c'est-à-dire, je n'ai pas pu trouver un fichier /etc/systemd/system/systemd-login.service.d ou /usr/lib/systemd/systemd-logind.service. Un fichier /etc/system/logind.conf.J'ai essayé d’y insérer une instruction IPAddressAllow (il n’y avait aucune mention ou aucune valeur par défaut), mais il n’a pas été reconnu. J'ai également essayé d’insérer mon propre fichier .conf dans le même répertoire sans succès. Je vais y revenir de nouveau, mais pour le moment, nous espérons que Ubuntu publiera sous peu une mise à jour ou un correctif pour résoudre ce problème.
J'étais aussi touché par cela et au début, j'ai aussi résolu ce problème en commentant
IPAdressDeny=Any
in /lib/systemd/system/systemd-logind.service
comme beaucoup d'autres ici mentionnés auparavant.
Cependant, en plus d'être un risque pour la sécurité, cela ne fonctionnera que jusqu'à la prochaine mise à jour de la chaîne d'outils systemd, comme indiqué dans le Arch-Wiki . Ce que le wiki n'explique pas très bien, c'est comment étendre la configuration du systemd-logind.service de telle sorte qu'une certaine plage d'adresses est inscrite sur la liste blanche et que ces paramètres survivent à une mise à jour. Après quelques lectures dans le documentation RHEL (en particulier la section 10.6.4: Modification des fichiers d'unité existants), la solution suivante a fonctionné pour moi:
Créez un nouveau répertoire dans /etc/systemd/system/
portant exactement le nom du service que vous souhaitez étendre, y compris un .d
. Voici le code: systemd-logind.service.d
Créez un nouveau fichier choose_an_appropriate_name.conf
(par exemple [nis_open_network_interface.conf) dans le répertoire nouvellement créé avec le contenu suivant, qui spécifie l'adresse IP ou la plage d'adresses que vous souhaitez autoriser:
[Service]
IPAddressAllow=10.10.0.0/16
Faites un systemctl daemon-reload
systemctl cat systemd-logind.service
systemctl restart systemd-logind.service
(Ceci vous expulsera de votre session gnome en cours et vous devrez vous reconnecter.)Il n'est pas nécessaire de modifier un autre fichier! À ce stade, vous devriez pouvoir vous connecter à nouveau avec les utilisateurs NIS sans que le système ne soit gelé. Notez cependant que cela est toujours considéré comme non sécurisé (adresses IP en liste blanche) et que le comportement en bac à sable de systemd-logind est souhaité. NIS/YP est un peu dépassé, mais je le trouve toujours aussi souvent. Il peut également y avoir une meilleure solution à cela impliquant un démon de mise en cache de noms utilisant nscd ou sssd comme mentionné dans ce problème de gdtub de systemd et traitant de l'ensemble situation. Mais ceci est hors de ma portée pour le moment.
Cette réponse rassemble tous les éléments des articles précédents et j'espère en clarifier un peu pour donner une bonne solution au problème.
À votre santé
Je faisais face au même problème dans un laboratoire que je configure pour mes étudiants. Ma solution provisoire consistait à utiliser 17,10 clients. Ils fonctionnent même si le serveur est 18.04.
Mais maintenant que je suis rentré chez moi, je viens de trouver un commentaire très intéressant sur Arch Linux wiki . Il attire l'attention sur un changement de systemd survenu le 10/2017. On dirait vraiment que c'est le problème. Ils suggèrent également une solution basée sur "Cela peut être fait en créant un nouveau fichier .conf dans le fichier /etc/systemd/system/systemd-logind.service.d/", qui ajoute la liste blanche au serveur NIS. Je ne pourrai essayer ceci lundi que lorsque je serai de retour au travail (ou je ne résisterai pas et essaierai par SSH). Mais si vous avez accès à votre système, vous pouvez essayer et faire rapport.
Sur Ubuntu 18.04 LTS, vous devriez pouvoir résoudre votre problème en supprimant simplement la ligne.
IPAddressDeny=any
de /lib/systemd/system/systemd-logind.service
Cela ne semble pas être votre cas, étant donné ce que vous avez décrit, mais sachez que vous devez disposer du répertoire de base de l'utilisateur NIS auquel vous essayez de vous connecter, cet utilisateur doit disposer des droits de lecture/écriture pour ce répertoire et la connexion au serveur NIS peut prendre un certain temps.
Je peux confirmer que la deuxième solution mentionnée par Tom fonctionne désormais parfaitement pour moi aussi (Hadnt avait remarqué le mauvais chemin - merci). J'ai également essayé la première solution, mais encore une fois, cela ne semble pas fonctionner pour moi. J'ai aussi par inadvertance repéré le fichier /etc/systemd/system.conf qui a un
J'ai essayé de mettre dans mes entrées de réseau internes c.-à-d. (Par exemple 10.0.0.0/16) mais cela ne semble pas prendre effet. Je suis un novice systemd (venant de Ubuntu 14.04). Pour le moment, la solution 2 est parfaite et je peux contourner les mises à jour, etc., mais j’examinerai à nouveau l’option 1 si le temps le permet, sinon quelqu'un risque de craquer. Merci un million pour l'aide les gars
J'ai essayé le conseil de Paulos, mais il existe divers problèmes liés au travail décrit lorsque vous suivez le lien.
La deuxième solution, je me suis mis au travail. Ils ont juste le mauvais chemin pour Ubuntu, le fichier est ici:
/lib/systemd/system/systemd-logind.service
Je viens de commenter cette ligne:
# IPAddressDeny=any
et après le redémarrage, cela a fonctionné.
La première solution semble cependant la meilleure, mais j’ai rencontré divers problèmes et je ne parviens pas à obtenir la syntaxe exacte. Pour commencer, le nom est faux, ce n'est pas un nom valide, alors il doit s'agir d'un lien symbolique, pas d'un fichier réel. J'ai eu jusqu'à créer
/lib/systemd/system/open_nis_interface.service
et le remplir avec:
[Service]
IPAddressAllow=10.0.0.0/16
puis en reliant:
mkdir /etc/systemd/system/systemd-logind.service.wants/
ln -s /lib/systemd/system/open_nis_interface.service /etc/systemd/system/systemd-logind.service.wants/
Je charge le fichier, mais ma syntaxe n'est pas tout à fait correcte. systemd donne des messages ok si vous exécutez:
dmesg | grep systemd
Comme je l'ai dit, la deuxième méthode consistant à remplacer le fichier système fonctionne pour moi. Quelqu'un peut peut-être terminer la première méthode, ce qui semble être une meilleure solution à long terme.
À M
J'ai eu un problème similaire, j'avais mis à niveau de 17.10 à 18.04. Bien que je puisse me connecter avec un utilisateur local, la session n'a pas duré très longtemps avant de redémarrer. Je ne pouvais pas me connecter avec mon utilisateur nis sans le redémarrage de l'interface graphique.
En basculant le gestionnaire d'affichage sur lightdm, j'ai pu contourner le problème.
Sudo apt install lightdm
Sudo dpkg-reconfigure gdm3
Sélectionnez ensuite lightdm en tant que votre responsable. Redémarrez et j'ai pu me connecter avec mon utilisateur nis.
Cela ne résout pas le temps qu'il faut pour me connecter, cela me permet cependant d'obtenir une interface graphique.