Ce n'est pas à proprement parler une question relative à Unix, mais je ne
suis pas sûr de connaître un groupe francophone plus approprié.
Je commence à avoir de plus en plus de hooks pour mon dépot svn personnel.
D'habitude, j'aime bien maintenir les scripts que j'utilise sous svn. La
question se pose donc pour les scripts exécutés par les hooks...
Est-ce ça vous paraît raisonnable de maintenir ces scripts eux-même dans le
dépôt, et qu'un script post-commit en fasse un checkout à chaque fois, avec
des liens symboliques du répertoire hooks du dépôt vers ce checkout ? Ou
bien est-ce un moyen probable de tout casser ?
Ou bien est-ce plus propre d'avoir un deuxième dépôt, dédié aux hooks du
premier ? Ou toute autre solution ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Vincent Lefevre
Dans l'article <get5bp$60$, mpg écrit:
Je commence à avoir de plus en plus de hooks pour mon dépot svn personnel. D'habitude, j'aime bien maintenir les scripts que j'utilise sous svn. La question se pose donc pour les scripts exécutés par les hooks...
Idem.
Est-ce ça vous paraît raisonnable de maintenir ces scripts eux-même dans le dépôt,
C'est ce que je fais.
et qu'un script post-commit en fasse un checkout à chaque fois, avec des liens symboliques du répertoire hooks du dépôt vers ce checkout ?
Comme je modifie les scripts rarement, je le fais à la main.
Ou bien est-ce un moyen probable de tout casser ?
S'il n'y a pas de bug dans tes scripts de mise à jour, il ne devrait pas y avoir de problème. Mais fais bien attention...
Si tu casses seulement le répertoire hooks, tu peux toujours réparer en virant les scripts à la main, en faisant un checkout et en réinstallant des scripts corrects. Mais si tu casses le répertoire db en te trompant dans un chemin, c'est plus grave. :)
Ou bien est-ce plus propre d'avoir un deuxième dépôt, dédié aux hooks du premier ? Ou toute autre solution ?
Je ne pense pas qu'un deuxième dépôt change quoique ce soit.
Attention tout de même avec les mises à jours automatiques: si quelqu'un pirate une de tes machines où il y a un répertoire de travail, il pourra plus facilement prendre le contrôle du dépôt (s'il en a vraiment envie, car c'est tout de même assez spécifique).
Dans l'article <get5bp$60$2@talisker.lacave.net>,
mpg <mpg@elzevir.fr> écrit:
Je commence à avoir de plus en plus de hooks pour mon dépot svn personnel.
D'habitude, j'aime bien maintenir les scripts que j'utilise sous svn. La
question se pose donc pour les scripts exécutés par les hooks...
Idem.
Est-ce ça vous paraît raisonnable de maintenir ces scripts eux-même
dans le dépôt,
C'est ce que je fais.
et qu'un script post-commit en fasse un checkout à chaque fois, avec
des liens symboliques du répertoire hooks du dépôt vers ce checkout ?
Comme je modifie les scripts rarement, je le fais à la main.
Ou bien est-ce un moyen probable de tout casser ?
S'il n'y a pas de bug dans tes scripts de mise à jour, il ne devrait
pas y avoir de problème. Mais fais bien attention...
Si tu casses seulement le répertoire hooks, tu peux toujours réparer
en virant les scripts à la main, en faisant un checkout et en
réinstallant des scripts corrects. Mais si tu casses le répertoire
db en te trompant dans un chemin, c'est plus grave. :)
Ou bien est-ce plus propre d'avoir un deuxième dépôt, dédié aux
hooks du premier ? Ou toute autre solution ?
Je ne pense pas qu'un deuxième dépôt change quoique ce soit.
Attention tout de même avec les mises à jours automatiques: si
quelqu'un pirate une de tes machines où il y a un répertoire de
travail, il pourra plus facilement prendre le contrôle du dépôt
(s'il en a vraiment envie, car c'est tout de même assez spécifique).
Je commence à avoir de plus en plus de hooks pour mon dépot svn personnel. D'habitude, j'aime bien maintenir les scripts que j'utilise sous svn. La question se pose donc pour les scripts exécutés par les hooks...
Idem.
Est-ce ça vous paraît raisonnable de maintenir ces scripts eux-même dans le dépôt,
C'est ce que je fais.
et qu'un script post-commit en fasse un checkout à chaque fois, avec des liens symboliques du répertoire hooks du dépôt vers ce checkout ?
Comme je modifie les scripts rarement, je le fais à la main.
Ou bien est-ce un moyen probable de tout casser ?
S'il n'y a pas de bug dans tes scripts de mise à jour, il ne devrait pas y avoir de problème. Mais fais bien attention...
Si tu casses seulement le répertoire hooks, tu peux toujours réparer en virant les scripts à la main, en faisant un checkout et en réinstallant des scripts corrects. Mais si tu casses le répertoire db en te trompant dans un chemin, c'est plus grave. :)
Ou bien est-ce plus propre d'avoir un deuxième dépôt, dédié aux hooks du premier ? Ou toute autre solution ?
Je ne pense pas qu'un deuxième dépôt change quoique ce soit.
Attention tout de même avec les mises à jours automatiques: si quelqu'un pirate une de tes machines où il y a un répertoire de travail, il pourra plus facilement prendre le contrôle du dépôt (s'il en a vraiment envie, car c'est tout de même assez spécifique).
Le (on) lundi 10 novembre 2008 13:08, Vincent Lefevre a écrit (wrote) :
Est-ce ça vous paraît raisonnable de maintenir ces scripts eux-même dans le dépôt,
C'est ce que je fais.
Ok.
et qu'un script post-commit en fasse un checkout à chaque fois, avec des liens symboliques du répertoire hooks du dépôt vers ce checkout ?
Comme je modifie les scripts rarement, je le fais à la main.
Vu.
Attention tout de même avec les mises à jours automatiques:
Oui, je vais sans doute les faire à la main finalement.
si quelqu'un pirate une de tes machines où il y a un répertoire de travail, il pourra plus facilement prendre le contrôle du dépôt (s'il en a vraiment envie, car c'est tout de même assez spécifique).
Vu que la seule méthode d'accès au dépôt est svn+ssh, je pense que ça ne devrait pas être un problème spécifique (je veux dire, soit l'attaquant a "craqué" ma clé ssh, et je suis dans la m*rde de toutes façons, soit il ne peut pas commiter dans le dépôt donc pas de problèmes non plus).
Manuel.
Le (on) lundi 10 novembre 2008 13:08, Vincent Lefevre a écrit (wrote) :
Est-ce ça vous paraît raisonnable de maintenir ces scripts eux-même
dans le dépôt,
C'est ce que je fais.
Ok.
et qu'un script post-commit en fasse un checkout à chaque fois, avec
des liens symboliques du répertoire hooks du dépôt vers ce checkout ?
Comme je modifie les scripts rarement, je le fais à la main.
Vu.
Attention tout de même avec les mises à jours automatiques:
Oui, je vais sans doute les faire à la main finalement.
si
quelqu'un pirate une de tes machines où il y a un répertoire de
travail, il pourra plus facilement prendre le contrôle du dépôt
(s'il en a vraiment envie, car c'est tout de même assez spécifique).
Vu que la seule méthode d'accès au dépôt est svn+ssh, je pense que ça ne
devrait pas être un problème spécifique (je veux dire, soit l'attaquant
a "craqué" ma clé ssh, et je suis dans la m*rde de toutes façons, soit il
ne peut pas commiter dans le dépôt donc pas de problèmes non plus).
Le (on) lundi 10 novembre 2008 13:08, Vincent Lefevre a écrit (wrote) :
Est-ce ça vous paraît raisonnable de maintenir ces scripts eux-même dans le dépôt,
C'est ce que je fais.
Ok.
et qu'un script post-commit en fasse un checkout à chaque fois, avec des liens symboliques du répertoire hooks du dépôt vers ce checkout ?
Comme je modifie les scripts rarement, je le fais à la main.
Vu.
Attention tout de même avec les mises à jours automatiques:
Oui, je vais sans doute les faire à la main finalement.
si quelqu'un pirate une de tes machines où il y a un répertoire de travail, il pourra plus facilement prendre le contrôle du dépôt (s'il en a vraiment envie, car c'est tout de même assez spécifique).
Vu que la seule méthode d'accès au dépôt est svn+ssh, je pense que ça ne devrait pas être un problème spécifique (je veux dire, soit l'attaquant a "craqué" ma clé ssh, et je suis dans la m*rde de toutes façons, soit il ne peut pas commiter dans le dépôt donc pas de problèmes non plus).
Manuel.
mpg
Le (on) mardi 11 novembre 2008 01:22, mpg a écrit (wrote) :
Ok.
Et j'ai failli oublier : merci pour ta réponse.
Manuel.
Le (on) mardi 11 novembre 2008 01:22, mpg a écrit (wrote) :
Le (on) mardi 11 novembre 2008 01:22, mpg a écrit (wrote) :
Ok.
Et j'ai failli oublier : merci pour ta réponse.
Manuel.
Vincent Lefevre
Dans l'article <gfaj8v$2apr$, mpg écrit:
Vu que la seule méthode d'accès au dépôt est svn+ssh, je pense que ça ne devrait pas être un problème spécifique (je veux dire, soit l'attaquant a "craqué" ma clé ssh, et je suis dans la m*rde de toutes façons, soit il ne peut pas commiter dans le dépôt donc pas de problèmes non plus).
Tu peux très bien avoir une clé SSH spécifique à ton serveur Subversion (c'est ce que j'ai fait: le serveur a son propre utilisateur "svn", son propre .ssh/authorized_keys, avec une clé par machine où j'ai un répertoire de travail).
Dans l'article <gfaj8v$2apr$1@talisker.lacave.net>,
mpg <mpg@elzevir.fr> écrit:
Vu que la seule méthode d'accès au dépôt est svn+ssh, je pense que ça ne
devrait pas être un problème spécifique (je veux dire, soit l'attaquant
a "craqué" ma clé ssh, et je suis dans la m*rde de toutes façons, soit il
ne peut pas commiter dans le dépôt donc pas de problèmes non plus).
Tu peux très bien avoir une clé SSH spécifique à ton serveur Subversion
(c'est ce que j'ai fait: le serveur a son propre utilisateur "svn",
son propre .ssh/authorized_keys, avec une clé par machine où j'ai un
répertoire de travail).
Vu que la seule méthode d'accès au dépôt est svn+ssh, je pense que ça ne devrait pas être un problème spécifique (je veux dire, soit l'attaquant a "craqué" ma clé ssh, et je suis dans la m*rde de toutes façons, soit il ne peut pas commiter dans le dépôt donc pas de problèmes non plus).
Tu peux très bien avoir une clé SSH spécifique à ton serveur Subversion (c'est ce que j'ai fait: le serveur a son propre utilisateur "svn", son propre .ssh/authorized_keys, avec une clé par machine où j'ai un répertoire de travail).
