Gitolite qui permet une gestion facile des accès pour chaque utilisateur du serveur git. Il existe un article sur la définition d'exemples dans la rue, mais presque toutes les opérations de gitolite sont un ensemble d'opérations courantes pour les personnes familières, telles que "créer une paire de clés" et "valider", donc plutôt qu'une procédure spécifique N'est-il pas plus rapide de rédiger les exigences nécessaires?
Donc, ceci est un article au lieu d'un mémo. Je l'ai écrit dans la mémoire de la première installation, il peut donc y avoir des erreurs. Si je dois le configurer à nouveau, je peux peut-être le réparer?
L'environnement du serveur de destination de l'installation est CentOS 7, mais si vous pouvez utiliser yum, il n'y aura pas de grande différence.
N'est-il pas possible que git ne soit pas inclus?
Créez une paire de clés pour l'administrateur avec ssh-keygen etc. La clé publique est requise côté serveur. La clé privée est utilisée par l'utilisateur administrateur pour l'accès à distance (non requis sur le serveur).
"Yum install gitolite 3" avec EPEL activé. Par cette opération, l'utilisateur "gitolite3" pour l'opération gitolite est automatiquement créé. Définissez également un committer pour que cet utilisateur soit automatiquement validé lors de l'initialisation (probablement requis). Comme ça
# yum install gitolite3
# su - gitolite3
$ git config --global user.nom nom d'utilisateur
$ git config --global user.adresse e-mail
J'ai également vu un article qui incluait des paramètres d'utilisation du japonais dans le nom de fichier à valider, mais je ne suis pas sûr de son importance.
Puisque l'utilisateur gitolite3 a été créé par le travail ci-dessus, initialisez gitolite3 en utilisant la clé publique créée précédemment.
$ gitolite setup -pk Fichier de clé publique administrative
C'est la fin du travail côté serveur. Puisqu'un référentiel appelé "gitolite-admin" a été créé dans gitlite, il sera géré depuis le côté distant principalement en validant le référentiel.
La condition pour accéder à partir d'un compte administratif est d'accéder «à l'aide d'une clé privée administrative» et «en tant qu'utilisateur gitolite3». Ainsi, par exemple, ajoutez l'entrée suivante à .ssh / config
Héberger gitoliteadmin (veuillez choisir votre nom préféré)
HostName Nom d'hôte, adresse IP, etc.
User gitolite3
IdentityFile ~/.ssh/Nom du fichier de clé privée
Essayons "ssh gitolite admin". Bien sûr, il est OK de définir les informations ci-dessus comme une option de la commande ssh (c'est OK, mais après tout, l'ajout d'une entrée à config par opération git est presque indispensable). Si vous recevez un message de connexion et que vous êtes déconnecté, vous avez réussi.
hello gitadmin, this is gitolite3@*** running gitolite3 3.6.12-1.el7 on git ***
R W gitolite-admin
R W testing
Vous pouvez cloner le référentiel de gestion "gitolite-admin" avec les informations d'accès ci-dessus. Depuis la commande git
git clone gitoliteadmin:/gitolite-admin
Vous pouvez le faire avec votre client git préféré.
Pour ajouter un utilisateur, il suffit d'ajouter (valider) la clé publique de la paire de clés de l'utilisateur que vous souhaitez ajouter au référentiel gitolite-admin.
Par exemple, si vous avez "clé privée: git-user1.pem, clé publique: git-user1.pub", mettez git-user1.pub dans (cloné) gitlite-admin / keydir et git commit & push. Je te le donnerai. La clé privée est détenue par l'utilisateur et utilisée pour l'accès.
L'important est que «ce nom de fichier de clé publique devienne l'identifiant utilisateur pour le contrôle d'accès». Faites donc attention au nom du fichier lors de l'enregistrement de la clé publique. Si le nom du fichier est "git-user1.pub", l'identifiant de l'utilisateur sera "git-user1".
Dans l'état initial, gitlite-admin / conf / gitolite.conf doit avoir le contenu suivant.
repo gitolite-admin
RW+ = gitadmin
repo testing
RW+ = @all
Ajoutez une ligne appelée "repo new repository name" et une ligne avec l'autorisation d'accès "RW + =" à ce fichier, et git commit & push ainsi que l'ajout d'un utilisateur. c'est tout. Peut-être plus facile que git init sur le serveur?
repo gitolite-admin
RW+ = gitadmin
repo testing
RW+ = @all
repo new-repository
RW+ = @all
Pour le réglage des autorisations, définissez l'identifiant de l'utilisateur ou le groupe auquel vous souhaitez autoriser l'accès après "RW + =". Si vous souhaitez définir plusieurs utilisateurs ou groupes, organisez-les en les séparant par des espaces. Les groupes sont définis dans le même fichier que "@ group1 = git-user1 git-user2". Un groupe appelé "@all" est défini dans l'état initial. Il existe trois types d'autorisations: «R (lecture seule)», «RW (lecture / écriture)» et «RW + (tout est possible)».
@group1 = git-user1 git-user2
repo gitolite-admin
RW+ = gitadmin
repo testing
RW+ = @all
repo new-repository
RW+ = gitadmin
RW = @group1
R = git-user3 git-user4
L'accès des utilisateurs est fondamentalement le même que celui de l'administrateur. La condition est d'accéder «en utilisant la clé privée de l'utilisateur» et «avec l'utilisateur gitolite3». Comme exemple de .ssh / config, je pensais que c'était comme ça ... mais c'est complètement différent de celui de gestion (car la clé privée est différente).
Héberger gitolite (veuillez choisir votre nom préféré)
HostName Nom d'hôte, adresse IP, etc.
User gitolite3
IdentityFile ~/.ssh/Nom du fichier de clé privée
C'est aussi la même chose que l'administrateur, et si vous faites ssh gitolite, une liste de référentiels utilisables sera affichée. Essayons de cloner "testing".
git clone gitolite:/testing
Je reçois un avertissement "avertissement: vous semblez avoir cloné un référentiel vide." (Si personne n'a commis quoi que ce soit), mais je m'en fiche.
Dans la plupart des cas, lorsque vous commencez à utiliser gitolite, vous souhaiterez migrer un référentiel qui s'exécutait sur git brut. Ce travail se fait principalement du côté distant. C'est l'un des documents de gestion, mais il est préférable de le faire après l'ajout d'utilisateurs, je vais donc l'écrire ici.
Tout d'abord, effectuez le "Ajouter un référentiel" mentionné ci-dessus avec le compte de gestion. Le fonctionnement ne change pas même en cas de migration. Lorsqu'un nouveau référentiel est créé, il est basique d '"ajouter un serveur git" et de "git push" du côté distant (il existe un référentiel existant).
En principe, il est supposé que vous vous trouvez dans le référentiel que vous souhaitez migrer avec le compte d'utilisateur du côté distant. Si le nom du référentiel est "repo1"
git remote add gitolite ssh://gitolite/repo1 #Ajouter un serveur git
git push gitolite master #Informations de base+maître pousser
git push gitolite --all #Branches autres que master push
git push gitolite --tags #marque
Sera. Cela enregistrera le contenu du référentiel existant en tant que référentiel dans gitolite. Si vous avez beaucoup de référentiels de migration, créez un script shell ou autre.
Par cette opération, "gitolite" devrait être ajouté à votre .git / config en plus de "origin". Vous pouvez le laisser tel quel, mais si vous n'avez pas besoin d'accéder au référentiel d'origine ou que vous souhaitez utiliser origin au lieu de gitolite, vous pouvez re-cloner à partir de gitolite ou éditer .ssh / config. Ok (j'ai fait le dernier)
Une fois que vous le savez, la configuration prend moins d'une minute (sauf pour la migration du référentiel).
Dans l'explication, j'utilise principalement la commande git, mais divers commit et push peuvent être effectués confortablement en utilisant l'arborescence des sources.
Recommended Posts