commande sudo essayant de rechercher le nom d'hôte

Récemment, j'ai changé le fichier sudoers et le nom d'hôte via / etc / hostname. Après avoir modifié ces fichiers, ma commande sudo prend beaucoup de temps. En outre, il indique sudo incapable de résoudre l'hôte kaagini (nom d'hôte de ma machine).

Pourquoi sudo doit-il connaître le nom d'hôte pour autoriser quelque chose ??

Mon fichier sudoers a une commande "Defaults env_reset". J'ai vu des questions similaires, mais le contexte n'est pas une connexion à distance ici. L'erreur s'affiche sur un hôte local.

La recherche initiale du problème indique que le fichier / etc / hosts doit avoir le nom d'hôte réel pour 127.0.0.1. Cela a résolu mon problème. Mais ma vraie question est: pourquoi avons-nous besoin de cela pour sudo ?? Si le sudo fonctionne quel que soit le lieu de connexion.

sudo root sudoers

— prathmesh.kallurkar
source

superuser.com/questions/how-to-ask

— Der Hochstapler

@OliverSalzburg J'ai correctement reformulé la question. Veuillez me faire savoir si quelque chose ne va pas

— prathmesh.kallurkar

Réponses:

Le /etc/sudoersfichier est conçu pour pouvoir être distribué sur plusieurs serveurs. Pour ce faire, chaque autorisation dans le fichier a une partie hôte.

Il est généralement défini sur ALL=ce qui signifie que l'autorisation est valide pour n'importe quel serveur, mais il peut être défini sur des hôtes spécifiques:

%sudo    kaagini=(ALL) ALL

Pour que sudo sache si cette règle doit être appliquée, il doit rechercher l'hôte sur lequel il s'exécute. Il utilise un appel qui repose sur le fait d' /etc/hostsêtre correct, c'est pourquoi il échoue s'il n'est pas correct.

On pourrait faire valoir qu'il sudon'a pas besoin de se soucier de faire une recherche de nom si la partie hôte est définie sur ALL=pour toutes les autorisations, mais cela ne fonctionne tout simplement pas de cette façon - il semble déterminer où il s'exécute avant de traiter les règles .

C'est vraiment pour faciliter la maintenance car sudo ne lit que / etc / sudoers pour voir ce que l'utilisateur peut faire sur la machine actuelle. Mais en tant qu'administrateur avec 100 serveurs, cela peut nécessiter la maintenance de 100 fichiers / etc / sudoers différents. Étant donné que sudoers a une partie hôte dans les autorisations, vous pouvez conserver un seul fichier sudoers et le distribuer à toutes les machines, tout en conservant une granularité sur ce que les utilisateurs peuvent faire sur chaque machine.

— Paul
source

Merci d'avoir répondu. Pouvez-vous revenir sur le fichier sudoers distribué ?? Voir, j'ai un système d'exploitation fonctionnant sur machineA. Le fichier d'autorisations (/ etc / sudoers) pour ce système d'exploitation doit-il être stocké sur d'autres machines? Ou votre réponse signifie que la commande sudo peut dire quelque chose comme l'utilisateur John peut sudo de machineA mais pas de machineB ??

— prathmesh.kallurkar

C'est vraiment pour la facilité d'entretien. sudo lit uniquement / etc / sudoers pour voir ce que l'utilisateur peut faire sur la machine actuelle. Mais en tant qu'administrateur avec 100 serveurs, cela peut nécessiter la maintenance de 100 fichiers / etc / sudoers différents. Parce que sudoers a une partie hôte dans les autorisations, vous pouvez conserver un seul fichier sudoers et le distribuer à toutes les machines, tout en conservant une granularité sur ce que les utilisateurs peuvent faire sur chaque machine.

— Paul

une autre question ... est-ce que l'administrateur du serveur doit scp le nouveau fichier sudoers à chaque fois qu'il y a un changement dans le fichier sudoers principal ou sudo fournit-il un moyen de maintenir le fichier sudoers sur le réseau ??

— prathmesh.kallurkar

@ prathmesh.kallurkar Non, il n'y a pas de méthode intégrée de distribution, mais c'est Linux, donc c'est normal. Vous utiliseriez rsync ou scp ou un autre outil pour faire cette partie.

— Paul

Je considère que c'est un bug (s'il n'y a que TOUTES les règles, alors sudo n'a pas besoin de connaître son nom d'hôte) et j'ai donc déposé bugzilla.sudo.ws/show_bug.cgi?id=916

— Matthias Urlichs

Grâce au rapport de bogue lié déposé par Matthias Urlichs dans un autre commentaire, la commande suivante a résolu le problème pour moi:

Defaults !fqdn

Placez cette ligne dans le /etc/sudoersfichier

— kjones
source

-3

Puppet est un logiciel de gestion de configuration capable de configurer automatiquement une flotte de serveurs en lisant les fichiers Puppet Manifests. Un tel fichier pourrait inclure une définition de votre fichier / etc / sudoers, qui peut ensuite être poussé vers tous vos "agents" de marionnettes depuis votre "maître" de marionnettes. Tous les hôtes obtiendront alors la même copie de votre fichier / etc / sudoers, qui peut (et devrait) inclure des définitions HOST, vous pouvez donc accorder à certains utilisateurs certaines commandes sur certains hôtes (mais pas sur d'autres).

— Felipe Alvarez
source

Pouvez-vous développer votre réponse pour expliquer ce qu'est la marionnette, où la trouvez-vous et comment l'utilisez-vous pour résoudre le problème? De la file d'attente des avis

— fixer1234

Veuillez lire Comment puis-je recommander un logiciel pour obtenir des conseils sur la façon de recommander un logiciel. Vous devez fournir au moins un lien, des informations supplémentaires sur le logiciel lui-même et comment il peut être utilisé pour résoudre le problème dans la question.

— DavidPostill