Je souhaiterais que ma sauvegarde se déroule comme suit:
1 - Montage du volume de backup externe
2 - Sauvegarde
3 - Démontage du volume de backup externe
Je pensais pouvoir le faire avec Carbon Copy Cloner, en lui indiquant un
"preflight script", mais il se trouve qu'il vérifie /avant/ si le volume
de destination est disponible. Donc ça ne marche pas.
Du coup je m'oriente vers la ligne de commande, et à force de chercher
un peu partout, j'ai pondu un script de ce genre :
Mes questions:
a/ est-ce qu'on peut faire mieux ou plus simple (les lignes disktool
notamment restent assez absconces pour moi) ?
b/ est-ce qu'il est possible de faire en sorte que rsync ne nécessite
pas sudo, afin de rendre tout ça complètement automatique et transparent
?
c/ quelle est ensuite la meilleure méthode, sous Mac OS X 10.5, pour
programmer le lancement à intervalle régulier ? Cron ?
Merci pour vos lumières !
--
[SbM]
<http://sebastienmarty.free.fr> - <http://tradintosh.free.fr>
<http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr>
"If the French were really intelligent, they'd speak English" (W. Sheed)
> Il n'a pas été mis à jour depuis près de 2 ans (PSyncX), je ne sais pas > si c'est très sûr...
Est-ce qu'il y aurait des raisons pour qu'il y ait des problèmes ? Après tout, il ne fait que copier des fichiers...
Je constate que l'avant-dernière version de SuperDuper! n'était pas compatible Leopard, et que CCC a également été mis à jour. J'imagine que ce n'est pas pour rien, il doit notamment y avoir eu des changements au niveau des fichiers système, je ne sais pas...
Si on va par là, /bin/echo ne semble pas avoir été mis à jour depuis novembre 2007...
Oui mais bon, c'est pas le même problème ;)
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
Julien Salort <lists@juliensalort.org> wrote:
sebastienmarty@yahoo.fr (SbM) writes:
> Il n'a pas été mis à jour depuis près de 2 ans (PSyncX), je ne sais pas
> si c'est très sûr...
Est-ce qu'il y aurait des raisons pour qu'il y ait des problèmes ? Après
tout, il ne fait que copier des fichiers...
Je constate que l'avant-dernière version de SuperDuper! n'était pas
compatible Leopard, et que CCC a également été mis à jour. J'imagine que
ce n'est pas pour rien, il doit notamment y avoir eu des changements au
niveau des fichiers système, je ne sais pas...
Si on va par là, /bin/echo ne semble pas avoir été mis à jour depuis
novembre 2007...
Oui mais bon, c'est pas le même problème ;)
--
[SbM]
<http://sebastienmarty.free.fr> - <http://tradintosh.free.fr>
<http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr>
"If the French were really intelligent, they'd speak English" (W. Sheed)
> Il n'a pas été mis à jour depuis près de 2 ans (PSyncX), je ne sais pas > si c'est très sûr...
Est-ce qu'il y aurait des raisons pour qu'il y ait des problèmes ? Après tout, il ne fait que copier des fichiers...
Je constate que l'avant-dernière version de SuperDuper! n'était pas compatible Leopard, et que CCC a également été mis à jour. J'imagine que ce n'est pas pour rien, il doit notamment y avoir eu des changements au niveau des fichiers système, je ne sais pas...
Si on va par là, /bin/echo ne semble pas avoir été mis à jour depuis novembre 2007...
Oui mais bon, c'est pas le même problème ;)
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
Nicolas-Michel_REMOVE
Julien Salort wrote:
Est-ce qu'il y aurait des raisons pour qu'il y ait des problèmes ? Après tout, il ne fait que copier des fichiers...
Non, psync ne fait pas "que" copier des fichiers. Il copie aussi les permissions et les resources. Il gère les excludes, qui peuvent varier suivant la version du système. Il ne gère pas les ACL, par contre.
Ceci dit c'est assez simple à tester, on le lance 2x et si la seconde fois il a encore du taff, c'est qu'il y a un problème.
-- Nicolas Michel
Julien Salort <lists@juliensalort.org> wrote:
Est-ce qu'il y aurait des raisons pour qu'il y ait des problèmes ? Après
tout, il ne fait que copier des fichiers...
Non, psync ne fait pas "que" copier des fichiers.
Il copie aussi les permissions et les resources.
Il gère les excludes, qui peuvent varier suivant la version du système.
Il ne gère pas les ACL, par contre.
Ceci dit c'est assez simple à tester, on le lance 2x et si la seconde
fois il a encore du taff, c'est qu'il y a un problème.
Est-ce qu'il y aurait des raisons pour qu'il y ait des problèmes ? Après tout, il ne fait que copier des fichiers...
Non, psync ne fait pas "que" copier des fichiers. Il copie aussi les permissions et les resources. Il gère les excludes, qui peuvent varier suivant la version du système. Il ne gère pas les ACL, par contre.
Ceci dit c'est assez simple à tester, on le lance 2x et si la seconde fois il a encore du taff, c'est qu'il y a un problème.
-- Nicolas Michel
Nicolas-Michel_REMOVE
Patrick Stadelmann wrote:
La commande que launchd exécute effectivement, c'est un champ "commande" et un série de champs "arguments". La "commande" peut très bien être un script, qui peut donc être modifié à volonté.
Oui mais tu peux pas mettre du bash dans ce champ non ?
Le reste des champs dans la .plist, c'est utilisé par launchd pour configurer l'environnement avant de lancer la commande. CCC y ajoute en plus des champs à l'usage de son helper, champs qui sont simplement ignorés par launchd.
Tu es en train de dire que launchd lance CCC sans lui communiquer les arguments et que ensuite CCC va relire le fichier pour aller chercher les arguments qui ont été ignorés par launchd ?
Sans avoir vérifié j'ai pensé que launchd envoie les arguments à CCC.
Si ton script /etc/init.d lance ccc_helper au boot et que c'est ce dernier qui attend l'heure voulue pour démarrer le backup, il y aurait exactement le même problème.
Oui mais non, init.d contient des scripts que tu peux modifier comme des scripts qu'ils sont pour ensuite les mettre dans une crontab plutôt que dans rc.d. tout ça n'est que du langage unix, ça n'est pas un machin spécifique.
-- Nicolas Michel
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
La commande que launchd exécute effectivement, c'est un champ "commande"
et un série de champs "arguments". La "commande" peut très bien être un
script, qui peut donc être modifié à volonté.
Oui mais tu peux pas mettre du bash dans ce champ non ?
Le reste des champs dans la .plist, c'est utilisé par launchd pour
configurer l'environnement avant de lancer la commande. CCC y ajoute en
plus des champs à l'usage de son helper, champs qui sont simplement
ignorés par launchd.
Tu es en train de dire que launchd lance CCC sans lui communiquer les
arguments et que ensuite CCC va relire le fichier pour aller chercher
les arguments qui ont été ignorés par launchd ?
Sans avoir vérifié j'ai pensé que launchd envoie les arguments à CCC.
Si ton script /etc/init.d lance ccc_helper au boot et que c'est ce
dernier qui attend l'heure voulue pour démarrer le backup, il y aurait
exactement le même problème.
Oui mais non, init.d contient des scripts que tu peux modifier comme des
scripts qu'ils sont pour ensuite les mettre dans une crontab plutôt que
dans rc.d.
tout ça n'est que du langage unix, ça n'est pas un machin spécifique.
La commande que launchd exécute effectivement, c'est un champ "commande" et un série de champs "arguments". La "commande" peut très bien être un script, qui peut donc être modifié à volonté.
Oui mais tu peux pas mettre du bash dans ce champ non ?
Le reste des champs dans la .plist, c'est utilisé par launchd pour configurer l'environnement avant de lancer la commande. CCC y ajoute en plus des champs à l'usage de son helper, champs qui sont simplement ignorés par launchd.
Tu es en train de dire que launchd lance CCC sans lui communiquer les arguments et que ensuite CCC va relire le fichier pour aller chercher les arguments qui ont été ignorés par launchd ?
Sans avoir vérifié j'ai pensé que launchd envoie les arguments à CCC.
Si ton script /etc/init.d lance ccc_helper au boot et que c'est ce dernier qui attend l'heure voulue pour démarrer le backup, il y aurait exactement le même problème.
Oui mais non, init.d contient des scripts que tu peux modifier comme des scripts qu'ils sont pour ensuite les mettre dans une crontab plutôt que dans rc.d. tout ça n'est que du langage unix, ça n'est pas un machin spécifique.
-- Nicolas Michel
sebastienmarty
Michel Nicolas Alex wrote:
Patrick Stadelmann wrote:
> La commande que launchd exécute effectivement, c'est un champ "commande" > et un série de champs "arguments". La "commande" peut très bien être un > script, qui peut donc être modifié à volonté.
Oui mais tu peux pas mettre du bash dans ce champ non ?
Si, un script bash, sans problème : c'est ce que j'ai finalement fait pour monter mon disque avant le backup.
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
Michel Nicolas Alex <Nicolas-Michel_REMOVE@THIS_bluewin.ch> wrote:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> La commande que launchd exécute effectivement, c'est un champ "commande"
> et un série de champs "arguments". La "commande" peut très bien être un
> script, qui peut donc être modifié à volonté.
Oui mais tu peux pas mettre du bash dans ce champ non ?
Si, un script bash, sans problème : c'est ce que j'ai finalement fait
pour monter mon disque avant le backup.
--
[SbM]
<http://sebastienmarty.free.fr> - <http://tradintosh.free.fr>
<http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr>
"If the French were really intelligent, they'd speak English" (W. Sheed)
> La commande que launchd exécute effectivement, c'est un champ "commande" > et un série de champs "arguments". La "commande" peut très bien être un > script, qui peut donc être modifié à volonté.
Oui mais tu peux pas mettre du bash dans ce champ non ?
Si, un script bash, sans problème : c'est ce que j'ai finalement fait pour monter mon disque avant le backup.
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
Patrick Stadelmann
In article <1iyo64m.lc3d8g1m31s00N%, (Michel Nicolas Alex) wrote:
Patrick Stadelmann wrote:
> La commande que launchd exécute effectivement, c'est un champ "commande" > et un série de champs "arguments". La "commande" peut très bien être un > script, qui peut donc être modifié à volonté.
Oui mais tu peux pas mettre du bash dans ce champ non ?
Directement, non. Mais tu mettre le chemin d'un script bash ;-)
> Le reste des champs dans la .plist, c'est utilisé par launchd pour > configurer l'environnement avant de lancer la commande. CCC y ajoute en > plus des champs à l'usage de son helper, champs qui sont simplement > ignorés par launchd.
Tu es en train de dire que launchd lance CCC sans lui communiquer les arguments et que ensuite CCC va relire le fichier pour aller chercher les arguments qui ont été ignorés par launchd ?
Oui. Le seul paramètre que CCC demande à launchd de lui passer, c'est l'UUID qui se trouve dans le nom du .plist.
Sans avoir vérifié j'ai pensé que launchd envoie les arguments à CCC.
> Si ton script /etc/init.d lance ccc_helper au boot et que c'est ce > dernier qui attend l'heure voulue pour démarrer le backup, il y aurait > exactement le même problème.
Oui mais non, init.d contient des scripts que tu peux modifier comme des scripts qu'ils sont pour ensuite les mettre dans une crontab plutôt que dans rc.d.
Tu peux faire ça avec launchd aussi. Le problème avec ccc, c'est qu'il ne fournit pas une commande pour lancer le backup (ce qui permettrait de monter le disque avant), mais une commande pour lancer un démon qui s'occupera lui de lancer le backup. Indépendamment du mécanisme qui lance le démon, tu ne pourras pas facilement exécuter une commande juste avant le début du backup. Tu pourras uniquement exécuter une commande juste avant de lancer le démon (alors que le backup n'aura peut-être lui que dans plusieurs jours).
tout ça n'est que du langage unix, ça n'est pas un machin spécifique.
Les .plist de launchd, c'est un chemin vers une commande Unix (script, exécutable binaire, ...) avec un set de paramètre. Le reste, c'est des champs utilisé pour configurer l'environnement (user, chroot, ...) pour la commande.
Patrick -- Patrick Stadelmann
In article
<1iyo64m.lc3d8g1m31s00N%Nicolas-Michel_REMOVE@THIS_bluewin.ch>,
Nicolas-Michel_REMOVE@THIS_bluewin.ch (Michel Nicolas Alex) wrote:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> La commande que launchd exécute effectivement, c'est un champ "commande"
> et un série de champs "arguments". La "commande" peut très bien être un
> script, qui peut donc être modifié à volonté.
Oui mais tu peux pas mettre du bash dans ce champ non ?
Directement, non. Mais tu mettre le chemin d'un script bash ;-)
> Le reste des champs dans la .plist, c'est utilisé par launchd pour
> configurer l'environnement avant de lancer la commande. CCC y ajoute en
> plus des champs à l'usage de son helper, champs qui sont simplement
> ignorés par launchd.
Tu es en train de dire que launchd lance CCC sans lui communiquer les
arguments et que ensuite CCC va relire le fichier pour aller chercher
les arguments qui ont été ignorés par launchd ?
Oui. Le seul paramètre que CCC demande à launchd de lui passer, c'est
l'UUID qui se trouve dans le nom du .plist.
Sans avoir vérifié j'ai pensé que launchd envoie les arguments à CCC.
> Si ton script /etc/init.d lance ccc_helper au boot et que c'est ce
> dernier qui attend l'heure voulue pour démarrer le backup, il y aurait
> exactement le même problème.
Oui mais non, init.d contient des scripts que tu peux modifier comme des
scripts qu'ils sont pour ensuite les mettre dans une crontab plutôt que
dans rc.d.
Tu peux faire ça avec launchd aussi. Le problème avec ccc, c'est qu'il
ne fournit pas une commande pour lancer le backup (ce qui permettrait de
monter le disque avant), mais une commande pour lancer un démon qui
s'occupera lui de lancer le backup. Indépendamment du mécanisme qui
lance le démon, tu ne pourras pas facilement exécuter une commande juste
avant le début du backup. Tu pourras uniquement exécuter une commande
juste avant de lancer le démon (alors que le backup n'aura peut-être lui
que dans plusieurs jours).
tout ça n'est que du langage unix, ça n'est pas un machin spécifique.
Les .plist de launchd, c'est un chemin vers une commande Unix (script,
exécutable binaire, ...) avec un set de paramètre. Le reste, c'est des
champs utilisé pour configurer l'environnement (user, chroot, ...) pour
la commande.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1iyo64m.lc3d8g1m31s00N%, (Michel Nicolas Alex) wrote:
Patrick Stadelmann wrote:
> La commande que launchd exécute effectivement, c'est un champ "commande" > et un série de champs "arguments". La "commande" peut très bien être un > script, qui peut donc être modifié à volonté.
Oui mais tu peux pas mettre du bash dans ce champ non ?
Directement, non. Mais tu mettre le chemin d'un script bash ;-)
> Le reste des champs dans la .plist, c'est utilisé par launchd pour > configurer l'environnement avant de lancer la commande. CCC y ajoute en > plus des champs à l'usage de son helper, champs qui sont simplement > ignorés par launchd.
Tu es en train de dire que launchd lance CCC sans lui communiquer les arguments et que ensuite CCC va relire le fichier pour aller chercher les arguments qui ont été ignorés par launchd ?
Oui. Le seul paramètre que CCC demande à launchd de lui passer, c'est l'UUID qui se trouve dans le nom du .plist.
Sans avoir vérifié j'ai pensé que launchd envoie les arguments à CCC.
> Si ton script /etc/init.d lance ccc_helper au boot et que c'est ce > dernier qui attend l'heure voulue pour démarrer le backup, il y aurait > exactement le même problème.
Oui mais non, init.d contient des scripts que tu peux modifier comme des scripts qu'ils sont pour ensuite les mettre dans une crontab plutôt que dans rc.d.
Tu peux faire ça avec launchd aussi. Le problème avec ccc, c'est qu'il ne fournit pas une commande pour lancer le backup (ce qui permettrait de monter le disque avant), mais une commande pour lancer un démon qui s'occupera lui de lancer le backup. Indépendamment du mécanisme qui lance le démon, tu ne pourras pas facilement exécuter une commande juste avant le début du backup. Tu pourras uniquement exécuter une commande juste avant de lancer le démon (alors que le backup n'aura peut-être lui que dans plusieurs jours).
tout ça n'est que du langage unix, ça n'est pas un machin spécifique.
Les .plist de launchd, c'est un chemin vers une commande Unix (script, exécutable binaire, ...) avec un set de paramètre. Le reste, c'est des champs utilisé pour configurer l'environnement (user, chroot, ...) pour la commande.
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article <1iyo64m.lc3d8g1m31s00N%, (Michel Nicolas Alex) wrote:
Patrick Stadelmann wrote:
> La commande que launchd exécute effectivement, c'est un champ "commande" > et un série de champs "arguments". La "commande" peut très bien être un > script, qui peut donc être modifié à volonté.
Oui mais tu peux pas mettre du bash dans ce champ non ?
Directement, non. Mais tu peux mettre le chemin d'un script bash ;-)
> Le reste des champs dans la .plist, c'est utilisé par launchd pour > configurer l'environnement avant de lancer la commande. CCC y ajoute en > plus des champs à l'usage de son helper, champs qui sont simplement > ignorés par launchd.
Tu es en train de dire que launchd lance CCC sans lui communiquer les arguments et que ensuite CCC va relire le fichier pour aller chercher les arguments qui ont été ignorés par launchd ?
Oui. Le seul paramètre que CCC demande à launchd de lui passer, c'est l'UUID qui se trouve dans le nom du .plist.
Sans avoir vérifié j'ai pensé que launchd envoie les arguments à CCC.
> Si ton script /etc/init.d lance ccc_helper au boot et que c'est ce > dernier qui attend l'heure voulue pour démarrer le backup, il y aurait > exactement le même problème.
Oui mais non, init.d contient des scripts que tu peux modifier comme des scripts qu'ils sont pour ensuite les mettre dans une crontab plutôt que dans rc.d.
Tu peux faire ça avec launchd aussi. Le problème avec ccc, c'est qu'il ne fournit pas une commande pour lancer le backup (ce qui permettrait de monter le disque avant), mais une commande pour lancer un démon qui s'occupera lui de lancer le backup. Indépendamment du mécanisme qui lance le démon, tu ne pourras pas facilement exécuter une commande juste avant le début du backup. Tu pourras uniquement exécuter une commande juste avant de lancer le démon (alors que le backup n'aura peut-être lui que dans plusieurs jours).
tout ça n'est que du langage unix, ça n'est pas un machin spécifique.
Les .plist de launchd, c'est un chemin vers une commande Unix (script, exécutable binaire, ...) avec un set de paramètre. Le reste, c'est des champs utilisé pour configurer l'environnement (user, chroot, ...) pour la commande.
Patrick -- Patrick Stadelmann
In article
<1iyo64m.lc3d8g1m31s00N%Nicolas-Michel_REMOVE@THIS_bluewin.ch>,
Nicolas-Michel_REMOVE@THIS_bluewin.ch (Michel Nicolas Alex) wrote:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> La commande que launchd exécute effectivement, c'est un champ "commande"
> et un série de champs "arguments". La "commande" peut très bien être un
> script, qui peut donc être modifié à volonté.
Oui mais tu peux pas mettre du bash dans ce champ non ?
Directement, non. Mais tu peux mettre le chemin d'un script bash ;-)
> Le reste des champs dans la .plist, c'est utilisé par launchd pour
> configurer l'environnement avant de lancer la commande. CCC y ajoute en
> plus des champs à l'usage de son helper, champs qui sont simplement
> ignorés par launchd.
Tu es en train de dire que launchd lance CCC sans lui communiquer les
arguments et que ensuite CCC va relire le fichier pour aller chercher
les arguments qui ont été ignorés par launchd ?
Oui. Le seul paramètre que CCC demande à launchd de lui passer, c'est
l'UUID qui se trouve dans le nom du .plist.
Sans avoir vérifié j'ai pensé que launchd envoie les arguments à CCC.
> Si ton script /etc/init.d lance ccc_helper au boot et que c'est ce
> dernier qui attend l'heure voulue pour démarrer le backup, il y aurait
> exactement le même problème.
Oui mais non, init.d contient des scripts que tu peux modifier comme des
scripts qu'ils sont pour ensuite les mettre dans une crontab plutôt que
dans rc.d.
Tu peux faire ça avec launchd aussi. Le problème avec ccc, c'est qu'il
ne fournit pas une commande pour lancer le backup (ce qui permettrait de
monter le disque avant), mais une commande pour lancer un démon qui
s'occupera lui de lancer le backup. Indépendamment du mécanisme qui
lance le démon, tu ne pourras pas facilement exécuter une commande juste
avant le début du backup. Tu pourras uniquement exécuter une commande
juste avant de lancer le démon (alors que le backup n'aura peut-être lui
que dans plusieurs jours).
tout ça n'est que du langage unix, ça n'est pas un machin spécifique.
Les .plist de launchd, c'est un chemin vers une commande Unix (script,
exécutable binaire, ...) avec un set de paramètre. Le reste, c'est des
champs utilisé pour configurer l'environnement (user, chroot, ...) pour
la commande.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1iyo64m.lc3d8g1m31s00N%, (Michel Nicolas Alex) wrote:
Patrick Stadelmann wrote:
> La commande que launchd exécute effectivement, c'est un champ "commande" > et un série de champs "arguments". La "commande" peut très bien être un > script, qui peut donc être modifié à volonté.
Oui mais tu peux pas mettre du bash dans ce champ non ?
Directement, non. Mais tu peux mettre le chemin d'un script bash ;-)
> Le reste des champs dans la .plist, c'est utilisé par launchd pour > configurer l'environnement avant de lancer la commande. CCC y ajoute en > plus des champs à l'usage de son helper, champs qui sont simplement > ignorés par launchd.
Tu es en train de dire que launchd lance CCC sans lui communiquer les arguments et que ensuite CCC va relire le fichier pour aller chercher les arguments qui ont été ignorés par launchd ?
Oui. Le seul paramètre que CCC demande à launchd de lui passer, c'est l'UUID qui se trouve dans le nom du .plist.
Sans avoir vérifié j'ai pensé que launchd envoie les arguments à CCC.
> Si ton script /etc/init.d lance ccc_helper au boot et que c'est ce > dernier qui attend l'heure voulue pour démarrer le backup, il y aurait > exactement le même problème.
Oui mais non, init.d contient des scripts que tu peux modifier comme des scripts qu'ils sont pour ensuite les mettre dans une crontab plutôt que dans rc.d.
Tu peux faire ça avec launchd aussi. Le problème avec ccc, c'est qu'il ne fournit pas une commande pour lancer le backup (ce qui permettrait de monter le disque avant), mais une commande pour lancer un démon qui s'occupera lui de lancer le backup. Indépendamment du mécanisme qui lance le démon, tu ne pourras pas facilement exécuter une commande juste avant le début du backup. Tu pourras uniquement exécuter une commande juste avant de lancer le démon (alors que le backup n'aura peut-être lui que dans plusieurs jours).
tout ça n'est que du langage unix, ça n'est pas un machin spécifique.
Les .plist de launchd, c'est un chemin vers une commande Unix (script, exécutable binaire, ...) avec un set de paramètre. Le reste, c'est des champs utilisé pour configurer l'environnement (user, chroot, ...) pour la commande.
Patrick -- Patrick Stadelmann
Nicolas-Michel_REMOVE
Patrick Stadelmann wrote:
Oui. Le seul paramètre que CCC demande à launchd de lui passer, c'est l'UUID qui se trouve dans le nom du .plist.
ah, ok, merci.
> Oui mais non, init.d contient des scripts que tu peux modifier comme des > scripts qu'ils sont pour ensuite les mettre dans une crontab plutôt que > dans rc.d.
Tu peux faire ça avec launchd aussi.
Ah ? J'ai pas dû tout comprendre. On peut lancer un launchd.plist uniquement avec cron, sans passer par launchd ?
Le problème avec ccc, c'est qu'il ne fournit pas une commande pour lancer le backup (ce qui permettrait de monter le disque avant), mais une commande pour lancer un démon qui s'occupera lui de lancer le backup.
C'est un défaut de CCC que d'utiliser launchd, en somme :) (oui, je sais, je suis chiant. Mais c'est pour ça qu'on m'aime non ?)
Indépendamment du mécanisme qui lance le démon, tu ne pourras pas facilement exécuter une commande juste avant le début du backup. Tu pourras uniquement exécuter une commande juste avant de lancer le démon (alors que le backup n'aura peut-être lui que dans plusieurs jours).
C'est juste. Mais si le mécanisme qui lance le démon est du bash, tu en fais ce que tu veux. Par exemple tu le modifies, puis tu lances quand tu en as besoins, via un cron job, puis tu l'arrêtes. -- Nicolas Michel
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Oui. Le seul paramètre que CCC demande à launchd de lui passer, c'est
l'UUID qui se trouve dans le nom du .plist.
ah, ok, merci.
> Oui mais non, init.d contient des scripts que tu peux modifier comme des
> scripts qu'ils sont pour ensuite les mettre dans une crontab plutôt que
> dans rc.d.
Tu peux faire ça avec launchd aussi.
Ah ?
J'ai pas dû tout comprendre.
On peut lancer un launchd.plist uniquement avec cron, sans passer par
launchd ?
Le problème avec ccc, c'est qu'il
ne fournit pas une commande pour lancer le backup (ce qui permettrait de
monter le disque avant), mais une commande pour lancer un démon qui
s'occupera lui de lancer le backup.
C'est un défaut de CCC que d'utiliser launchd, en somme :)
(oui, je sais, je suis chiant. Mais c'est pour ça qu'on m'aime non ?)
Indépendamment du mécanisme qui
lance le démon, tu ne pourras pas facilement exécuter une commande juste
avant le début du backup. Tu pourras uniquement exécuter une commande
juste avant de lancer le démon (alors que le backup n'aura peut-être lui
que dans plusieurs jours).
C'est juste. Mais si le mécanisme qui lance le démon est du bash, tu en
fais ce que tu veux. Par exemple tu le modifies, puis tu lances quand tu
en as besoins, via un cron job, puis tu l'arrêtes.
--
Nicolas Michel
Oui. Le seul paramètre que CCC demande à launchd de lui passer, c'est l'UUID qui se trouve dans le nom du .plist.
ah, ok, merci.
> Oui mais non, init.d contient des scripts que tu peux modifier comme des > scripts qu'ils sont pour ensuite les mettre dans une crontab plutôt que > dans rc.d.
Tu peux faire ça avec launchd aussi.
Ah ? J'ai pas dû tout comprendre. On peut lancer un launchd.plist uniquement avec cron, sans passer par launchd ?
Le problème avec ccc, c'est qu'il ne fournit pas une commande pour lancer le backup (ce qui permettrait de monter le disque avant), mais une commande pour lancer un démon qui s'occupera lui de lancer le backup.
C'est un défaut de CCC que d'utiliser launchd, en somme :) (oui, je sais, je suis chiant. Mais c'est pour ça qu'on m'aime non ?)
Indépendamment du mécanisme qui lance le démon, tu ne pourras pas facilement exécuter une commande juste avant le début du backup. Tu pourras uniquement exécuter une commande juste avant de lancer le démon (alors que le backup n'aura peut-être lui que dans plusieurs jours).
C'est juste. Mais si le mécanisme qui lance le démon est du bash, tu en fais ce que tu veux. Par exemple tu le modifies, puis tu lances quand tu en as besoins, via un cron job, puis tu l'arrêtes. -- Nicolas Michel
