2010-04-13 11 views
24

J'ai un crochet post-mise à jour sur mon serveur, de sorte que lorsque jeQuel utilisateur utilise le hook git?

git push 

il fait une traction sur le répertoire web en direct. Cependant, bien que le push réussisse toujours, le hook de post-mise à jour échoue parfois.

Le crochet est assez simple:

#!/bin/sh 
# 
# An example hook script to prepare a packed repository for use over 
# dumb transports. 
# 
# To enable this hook, rename this file to "post-update". 
cd /var/www 
env -i git pull 

Je pousse des mises à jour à partir d'une variété d'endroits, mais parfois je dois vous connecter en tant que root sur le serveur et manuall faire un

env -i git pull 

Je dois seulement le faire 20% du temps cependant. Des idées pour lesquelles ça échouerait aléatoirement? De même, comment l'obtenir pour enregistrer les messages d'erreur, car il peut fonctionner comme quelqu'un qui ne peut pas écrire dans le système de fichiers?

+0

Poussez-vous de la même façon de tous ces endroits? Autrement dit, l'URL distante est-elle la même pour tous? (en particulier, la partie user @ hostname) – Cascabel

+0

En outre, lorsque vous dites qu'il échoue, voulez-vous dire qu'il échoue avec une erreur d'autorisation refusée qui indique qu'il s'exécute en tant qu'utilisateur avec des privilèges insuffisants? Ou est-ce qu'il échoue pour une raison complètement indépendante, rien à voir avec l'uid qui le gère? – Cascabel

+0

Je suis en train de pousser à partir de différents endroits: parfois, c'est user1 @ hostname, d'autres fois, user2 @ hostname, etc (ils ont tous ce problème). Il échoue sans un message d'erreur que je peux voir, et je ne sais pas comment en obtenir un. Dans ma post-mise à jour, j'ai ajouté:> echo $ USER> /log.txt, mais rien n'y est écrit (le fichier n'est pas non plus créé). Cela me fait penser que l'utilisateur qui pousse, n'a pas d'autorisations. Mais si je ne peux même pas écrire un message d'erreur, comment le saurai-je? – ash

Répondre

18

Les crochets sont exécutés lorsque l'utilisateur appuie sur la touche. Si vous avez une sorte d'installation pré-faite, cela peut être un utilisateur comme git ou gitosis, ou c'est peut-être vous. Regardez simplement comment vous avez configuré la télécommande. (git remote show <remote-name> ou examinez simplement .git/config si vous ne le savez pas) Vraisemblablement, vous êtes en train de pousser via SSH, et il y a un nom d'utilisateur @ hostname dans l'URL.

P.S. Il est assez rapide de le démontrer - il suffit de cloner un repo localement, de lancer un hook post-update avec un echo $USER ou quelque chose de similaire, et d'essayer de pousser comme vous ou un autre utilisateur (directement ou via ssh).

2

j'ai décidé de tester sur mon gitlab ce 6 serveur en créant une pré-réception crochet et faisant écho les informations utilisateur

$ cat /home/git/repositories/foo/foo.git/hooks/pre-recieve 
#!/bin/bash 
set -x 
echo -e "The user the hook is run as is $USER" 
echo -e "Just to doublecheck, the user is $(whoami)" 
exit 1 

On dirait qu'il est exécuté en tant que l'utilisateur git

$ git push 
Counting objects: 3, done. 
Delta compression using up to 8 threads. 
Compressing objects: 100% (2/2), done. 
Writing objects: 100% (3/3), 269 bytes | 0 bytes/s, done. 
Total 3 (delta 1), reused 0 (delta 0) 
remote: + echo -e 'The user the hook is run as is' 
remote: The user the hook is run as is 
remote: ++ whoami 
remote: + echo -e 'Just to doublecheck, the user is git' 
remote: Just to doublecheck, the user is git 
remote: + exit 1 
+0

La raison en est que tous ces serveurs configurent un utilisateur unix pour accepter les connexions ssh entrantes via le fichier '~ git/.ssh/authorized_keys'. Ce fichier délègue de telles connexions à un script qui traite ensuite les données entrantes. Pour de tels serveurs, on peut dériver le nom de la personne effectuant la poussée, par ex. en supposant que c'est la même personne qui a fait le commit le plus récent. Cependant, cela peut ne pas être vrai du tout. Cela dépend du modèle de travail des utilisateurs. Mieux vaut juste vérifier ou signaler l'auteur/committer sur les commits individuels. – cfi