Forum Linux.général sudo dans un script éxécuté par cron utilisateur

Posté par  .
Étiquettes : aucune
-2
13
sept.
2011

Bonjour,

dans un script j'effectue un backup de postgres par la commande pg_dump.
pg_dump doit être appelé par l'utilisateur postgres.
J'ai donc modifier le fichier sudoers afin que l'utilisateur puisse faire appel a pg_dump en tant que postgres sans mot de passe.
Voici la commande :

#!/bin/bash
sudo -u postgres pg_dump tralala > tralala.sql

Quand je lance le script a la main, tout se passe bien. le sql est bien généré sans qu'un mot de passe me soit demandé.

Quand je met ce script en appel dans le crontab de l'utilisateur. Plus rien. Le SQL généré fait 0ko.

Je ne comprend pas pourquoi, je croyais que les scripts cron étaient exécutés en tant que "utilisateur".

Quelqu'un saurait m'expliquer ce phénomène ?

Merci

  • # après une rapide recherche google

    Posté par  . Évalué à 2.

    Putain de bordel !!!

    http://lmgtfy.com/?q=sudo+cron

    1er lien !!!

    C'est une mailing liste, en suivant les réponses tu auras au moins une piste

    Avant de poser une question sur un forum une mini recherche google (ou au moins une présentation de ce qui a été testé pour pas qu'on perde notre temps à proposer des trucs qui ne marchent pas )

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # Je sais faire une recherche google, merci

    Posté par  . Évalué à 8.

    Bonjour,

    Ok milles excuses. J'assume mon manque de perspicacité. Je ferais plus attention la prochaine fois avant de poster trop rapidement sur un forum.

    J'avais effectué des requêtes google plus complexes ce qui ne m'amenais pas sur ce résultat.

    La réponse est donc :
    par défaut sudo nécessite un terminal (tty) pour fonctionner.
    Or cron ne fournis pas de tty lorsqu'il exécute une commande.
    les sudo ne fonctionnent donc pas.

    Un moyen consiste à désactiver le comportement par défaut de sudo, afin qu'il accepte les sudo hors tty.

    Il faut pour cela commenter la ligne :
    Defaults requiretty
    dans le fichier sudoers.

    Il est également possible de désactiver ce comportement par défaut uniquement pour un utilisateur :
    Defaults:username !requiretty

    Merci

    • [^] # Re: Je sais faire une recherche google, merci

      Posté par  . Évalué à 1.

      Je crois que tu viens de me débloquer un truc sur lequel je bloque depuis 3 jours. Je veux créer des noeuds Erlang en local sur une même machine, Normalement le noeud se lance via rsh, et il est possible de préciser autre chose (ssh par exemple) via l'option -rsh passée à la ligne de commande, ou à la fonction slave:start/3.

      J'ai tenté de passer par un scrpt qui ferait un sudo, en lieu et place du ssh (évite d'avoir la clé du user toto dans le fichier authorized_keys de l'utilisateur toto, ce que je trouve débile). Je vais tester àça, et si ça passe, je lancera un appel à moinssage sur le grognon de service qui a ralé en te disant d'aller sur google; Si t n'avais pas posté ici, je serais encore à me demander comment faire.

    • [^] # Re: Je sais faire une recherche google, merci

      Posté par  . Évalué à 2.

      par défaut sudo nécessite un terminal (tty) pour fonctionner.
      Or cron ne fournis pas de tty lorsqu'il exécute une commande.

      J'utilise sudo depuis des scripts cron depuis des années (en particulier pour faire des mount/umount et des rsync). Je n'ai jamais eu ce problème.
      Donc ça doit vraiment dépendre de la distribution.

  • # Crontab de postgres

    Posté par  (site Web personnel) . Évalué à 7.

    Et pourquoi ne pas tout simplement ajouter la commande pg_dump tralala dans la crontab de postgres au lieu de s'embêter avec sudo et d'attacher cette tâche à un utilisateur humain en particulier ?

    • [^] # Re: Crontab de postgres

      Posté par  . Évalué à 0.

      ah oui... en effet...
      pourquoi n'ai-je pas fait ça, je vais regarder...

      Merci

  • # Avez-vous pensé à...

    Posté par  . Évalué à 1.

    ... déclarer le PATH au début du script ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.