web-dev-qa-db-fra.com

L'arrivée est-elle encore un solide remplacement pour l'anacron?

FAQ Upstart dit:

Upstart remplacera-t-il cron, atd ou anacron?

Oui. Une fonctionnalité prévue pour Upstart est la possibilité de générer des événements à une heure planifiée particulière, une heure planifiée régulière ou des intervalles chronométrés particuliers.

Cependant, le bas de la page indique qu'il a été écrit en 2009. Ces fonctionnalités planifiées sont-elles déjà en place, et est-il pratique d'utiliser upstart au lieu d'anacron?

En outre, un parvenu peut-il gérer les tâches par utilisateur hors de la boîte (contrairement à anacron, par exemple)?

upstartanacron
4
Geoffrey Irving

Depuis Upstart 1.10 (utilisé dans Ubuntu 13.10):

La documentation actuelle de Upstart est à http://upstart.ubuntu.com/cookbook

La fonctionnalité Cron et Anacron n'a pas encore été implémentée dans Upstart.

Référence: http://upstart.ubuntu.com/cookbook/#run-a-job-periodically

11.26 Exécuter un travail périodiquement

Actuellement, cela ne peut pas être géré directement par Upstart. Cependant, la fonction "Événements temporels" sur laquelle on travaille actuellement résoudra ce problème.

Jusqu'à ce que les événements temporels soient disponibles, vous devez soit utiliser cron (8), soit quelque chose comme:

 # /etc/init/timer.conf

 instance $JOB_TO_RUN

 script   for var in SLEEP JOB_TO_RUN   do
     eval val=\${$var}
     if [ -z "$val" ]
     then
       logger -t $0 "ERROR: variable $var not specified"
       exit 1
     fi   done

   eval _sleep=\${SLEEP}   eval _job=\${JOB_TO_RUN}

   while [ 1 ]   do
     stop  $_job || true
     sleep $_sleep
     start $_job || true   done end script

Les tâches par utilisateur peuvent faire référence à 1) l'exécution d'un travail en tant qu'utilisateur [Upstart fait cela] ou 2) l'émission et l'écoute d'événements au niveau utilisateur au lieu d'événements système [Upstart le fait aussi]

L'exécution d'un travail en tant qu'utilisateur est décrite sur http://upstart.ubuntu.com/cookbook/#run-a-job-as-a-different-user

11.43.2 Changer d'utilisateur

Certains démons commencent à s'exécuter en tant que super-utilisateur, puis organisent en interne pour supprimer leur niveau de privilège à un autre utilisateur (moins privilégié). Cependant, certains démons n'ont pas besoin de le faire: ils n'ont jamais besoin de privilèges root et peuvent donc être invoqués en tant qu'utilisateur non root.

Comment exécutez-vous un "travail système" mais l'avez-vous exécuté en tant qu'utilisateur non root? À partir d'Upstart 1.4, Upstart a la possibilité d'exécuter une tâche système en tant qu'utilisateur spécifié à l'aide des strophes setuid et setgid.

Cependant, si vous n'utilisez pas Upstart 1.4, il est facile d'atteindre l'objectif requis. Il existe plusieurs méthodes que vous pouvez utiliser. La méthode recommandée pour les systèmes Debian et Ubuntu est d'utiliser l'utilitaire d'aide start-stop-daemon (8) comme ceci:

 exec start-stop-daemon --start -c myuser --exec command

L'avantage d'utiliser start-stop-daemon (8) est qu'il change simplement l'utilisateur et le groupe sous lequel la commande est exécutée. Cela a également un avantage sur su (1) dans la mesure où su (1) doit bifurquer pour pouvoir maintenir sa session PAM ouverte, et est donc plus difficile à suivre pour upstart, tandis que start-stop-daemon (8) exécutera simplement le commande donnée après avoir changé l'uid/gid.

Un autre problème potentiel à prendre en compte est que le démon start-stop n'impose pas de limites PAM ("Pluggable Authentication Module") au processus qu'il démarre. Ces limites peuvent être définies à l'aide des strophes Upstart appropriées, vous ne pouvez tout simplement pas spécifier les limites via PAMs limits.conf (5).

Bien sûr, vous souhaiterez peut-être que des restrictions PAM soient en place, auquel cas vous devez utiliser su (1) ou Sudo (8), tous deux liés aux bibliothèques PAM.

Le conseil général n'est PAS d'utiliser su (1) ou Sudo (8), car les restrictions PAM ne sont vraiment pas appropriées pour les services système. Par exemple, PAM fera une entrée wtmp (5) à chaque appel de su (1) ou Sudo (8) et ces enregistrements ne sont pas appropriés pour les services système.

Si vous souhaitez utiliser su (1) ou Sudo (8), les exemples ci-dessous vous montrent comment.

En utilisant su (1):

 exec su -s /bin/sh -c command $user

Notez que bien que vous puissiez simplifier ce qui précède comme suit, il n'est pas recommandé car si l'utilisateur "$ user" est un compte système avec un shell spécifié comme/bin/false, le travail n'exécutera pas la commande spécifiée: il échouera en raison à/bin/false renvoyant "1":

 exec su -c command $user

Le travail échouera silencieusement si l'utilisateur "$ user" est un compte système avec un shell spécifié comme/bin/false.

Pour éviter que le fork (2) provoqué par le shell soit généré, vous pouvez plutôt spécifier:

 exec su -s /bin/sh -c 'exec "$0" "$@"' $user -- /path/to/command
 --arg1=foo -b wibble

Cette technique est particulièrement utile si votre travail est un travail de service qui utilise l'attente.

Un exemple de base en utilisant Sudo (8):

 exec Sudo -u $user command

Les travaux de niveau utilisateur (appelés "travaux de session") sont décrits sur http://upstart.ubuntu.com/cookbook/#session-job

4.2.3 Travail de session

Depuis Upstart v1.7

Les travaux de session sont analogues aux anciens travaux utilisateur. Contrairement aux anciens travaux utilisateur, les travaux de session ne sont pas gérés par Upstart s'exécutant en tant que PID 1 - ils sont gérés par les propres init de session des utilisateurs.

Contrairement à Upstart exécuté en tant que PID 1, un initiateur de session peut lire ses fichiers de configuration de travail à partir de plusieurs répertoires. La liste des travaux de répertoires à partir de laquelle on lit est la suivante (dans l'ordre):

 $XDG_CONFIG_HOME/upstart/ (or $HOME/.config/upstart/ if $XDG_CONFIG_HOME not set).
 $HOME/.init/ (deprecated - supported for legacy User Jobs).
 $XDG_CONFIG_DIRS
 /usr/share/upstart/sessions/

Le nom de chaque travail est considéré comme étant le nom de base lorsque l'un des noms de répertoire ci-dessus a été supprimé. Par exemple, si un fichier de configuration de travail existe sous la forme $ HOME/.config/upstart/hello/world.conf, son nom sera "hello/world" tandis que si un fichier de configuration de travail existe sous/usr/share/upstart/sessions/foo/bar.conf, son nom sera "foo/bar".

Upstart résout toutes les collisions de noms en acceptant simplement le premier travail valide (ou fichier de remplacement) qu'il trouve. Par exemple, si les deux fichiers suivants existent:

 $HOME/.init/foo.conf $HOME/.config/upstart/foo.conf

Seul le premier, $ HOME/.init/foo.conf sera utilisé. Attendu que si les fichiers suivants existent:

 $HOME/.init/foo.conf $HOME/.config/upstart/foo.conf
 $HOME/.config/upstart/foo.override

Upstart lira d'abord $ HOME/.init/foo.conf, puis appliquera toutes les modifications dans $ HOME/.config/upstart/foo.override.

2
user535733