« VCS/Git/CreateRemoteRepository » : différence entre les versions

De TartareFR
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
 
(9 versions intermédiaires par le même utilisateur non affichées)
Ligne 38 : Ligne 38 :
Bien évidemment, il faudra redémarrer le service xinetd pour que celui-ci prenne en compte les modifications apportées.<pre>systemctl restart xinetd.service</pre>
Bien évidemment, il faudra redémarrer le service xinetd pour que celui-ci prenne en compte les modifications apportées.<pre>systemctl restart xinetd.service</pre>


== Ajout d'un utilisateur et un groupe dédié au service ==
=== Création du répertoire de travail de git ===
mkdir -p /var/lib/git
cp /etc/skel/.bash* /var/lib/git/
 
=== Ajout d'un utilisateur et un groupe dédié au service ===
  useradd -r -d /var/lib/git -s /bin/bash -c 'Git user' git
  useradd -r -d /var/lib/git -s /bin/bash -c 'Git user' git
et mise en place d'un mot de passe
et mise en place d'un mot de passe
  passwd git
  passwd git
 
{{Admon/tip|Génération de mot passe|Le projet KDE fournit un générateur de mot de passe: <app>kpassgen</app>.}}
== Création du répertoire de travail de git ==
Changement du l'utilisateur et du groupe propriétaires du répertoire de travail
mkdir -p /var/lib/git
cp /etc/skel/.bash* /var/lib/git/
  chown -R git:git /var/lib/git
  chown -R git:git /var/lib/git


== Initialisation de ssh ==
=== Initialisation de ssh ===
  su - git
  su - git
  ssh-keygen -t rsa
  ssh-keygen -t rsa
Ligne 55 : Ligne 57 :
  chmod 644 .ssh/known_hosts
  chmod 644 .ssh/known_hosts


== Selinux ==
=== Mise en place d'un dépôt existant ===
  semanage fcontext -a -t ssh_home_t '/var/lib/git/.ssh(/.*)?'
Avec le compte utilisateur '''git''', on exporte notre dépôt existant directement dans le répertoire de travail.
  restorecon -R -v /var/lib/git
su - git
  $ git clone --bare file:///home/didier/vcs/scripts scripts.git
On autorise l'export de notre projet par le service git
  $ touch scripts.git/git-daemon-export-ok


== Ajout d'un utilisateur local ==
=== Mise en place d'un nouveau dépôt ===
  cat /home/$USER/.ssh/id_rsa.pub >> /var/lib/git/.ssh/authorized_keys
  # su - git
$ mkdir newrepo.git
$ cd newrepo.git
$ git init --bare
On autorise l'export de notre projet par le service git
$ touch newrepo.git/git-daemon-export-ok


== Mise en place du dépôt nu ==
=== Ajout d'un utilisateur local existant ===
Pour permettre le push, il faudra configurer un accès ssh pour chaque développeur. Attribuer le dépôt git à un groupe unix puis rattacher les développeurs à celui-ci est une bonne pratique.


Avec un compte user, on exporte notre dépôt
  cat /home/$USER/.ssh/id_rsa.pub >> /var/lib/git/.ssh/authorized_keys
  cd /tmp
git clone --bare file:///home/didier/vcs/scripts scripts.git
 
Déplacement du dépôt précédemment exporté et on change l'utilisateur et le groupe
mv /tmp/*.git /var/lib/git/
chown -R git:git *.git
 
On autorise l'export de notre projet par le service git
# touch /var/lib/git/scripts.git/git-daemon-export-ok


Pour permettre le push, il faudra configurer un accès ssh pour chaque développeur. Attribuer le dépôt git à un groupe unix puis rattacher les développeurs à celui-ci est une bonne pratique.
=== Ajout d'un nouvel utilisateur local ===
Git offre un shell de connexion minimaliste git-shell ne permettant que les opérations push et pull. <br />
Git offre un shell de connexion minimaliste git-shell ne permettant que les opérations push et pull. <br />
Ici, on crée un compte pour l'utilisateur joe avec git-shell pour shell de connexion et l'ajouter au groupe repo1 :
Ici, on crée un compte pour l'utilisateur joe avec git-shell pour shell de connexion et on l'ajoute au groupe repo1 :
  # groupadd repo1
  # groupadd repo1
  # useradd joe -s /usr/bin/git-shell -G repo1
  # useradd joe -s /usr/bin/git-shell -G repo1
  # chgrp -R repo1 /var/lib/git/repo1
  # chgrp -R repo1 /var/lib/git/repo1
=== Selinux ===
'''Les dépôts''' git doivent avoir le contexte '''git_sys_content_t'''
Le répertoire caché <path>/var/lib/git/.ssh</path> qui doit avoir le contexte '''ssh_home_t'''.
On fixe les permissions selinux comme ceci
semanage fcontext -a -t ssh_home_t '/var/lib/git/.ssh(/.*)?'
semanage fcontext -a -t git_system_t '/var/lib/git/.*\.git(/.*)?'
restorecon -Rv /var/lib/git


== Tests ==
== Tests ==


=== Accès lecture seule ===
=== Accès lecture seule ===
Ici n'importe qui ayant accès au serveur peut cloner le dépôt.
<pre>
<pre>
$ git clone git://localhost/rpm
$ git clone git://localhost/rpm
Ligne 94 : Ligne 109 :
Resolving deltas: 100% (6/6), done.
Resolving deltas: 100% (6/6), done.
</pre>
</pre>
On modifie le dépôt local.
<pre>
<pre>
$ touch test
$ touch test
$ git status
# On branch master
# Untracked files:
#  (use "git add <file>..." to include in what will be committed)
#
#      test
nothing added to commit but untracked files present (use "git add" to track)
$ git add test
$ git add test
$ git commit -m 'Add test file'
$ git commit -m 'Add test file'
[master 4fc0b91] Add test file
[master 4fc0b91] Add test file
  1 file changed, 0 insertions(+), 0 deletions(-)
  1 file changed, 0 insertions(+), 0 deletions(-)
  create mode 100644 test
  create mode 100644 test
</pre>
Mais la modification du dépôt distant rapporte une erreur.
<pre>
$ git push
$ git push
fatal: remote error: access denied or repository not exported: /rpm
fatal: remote error: access denied or repository not exported: /rpm
</pre>
</pre>
Nous avons donc bien un dépôt public en lecture seule


=== Accès en lecture écriture ===
=== Accès en lecture écriture ===
Il faut avoir préalablement importer la clé ssh publique de l'utilisateur comme expliqué [[#Ajout_d.27un_utilisateur_local|ici]].
On peut tout de suite testé si la clé est bien intégrée
$ ssh git@localhost
Last login: Wed Jan 23 18:30:23 2013 from localhost
$
On clone le dépôt sans problème
<pre>
<pre>
$ git clone git@localhost:rpm.git
$ git clone git@localhost:rpm.git
Ligne 124 : Ligne 144 :
Resolving deltas: 100% (6/6), done.
Resolving deltas: 100% (6/6), done.
</pre>
</pre>
On modifie le dépôt local
<pre>
<pre>
$ cd rpm
$ cd rpm
Ligne 132 : Ligne 154 :
  1 file changed, 0 insertions(+), 0 deletions(-)
  1 file changed, 0 insertions(+), 0 deletions(-)
  create mode 100644 test
  create mode 100644 test
 
</pre>
On synchronise le dépôt distant facilement
<pre>
$ git push
$ git push
Counting objects: 4, done.
Counting objects: 4, done.
Ligne 142 : Ligne 166 :
   af18a33..e6bab0d  master -> master
   af18a33..e6bab0d  master -> master
</pre>
</pre>
Nous avons bien accès en lecture/écriture sur le dépôt distant.
{{Admon/note|Push sur un dépôt distant vide|A la première synchronisation sur un dépôt distant vide, il faut préciser le dépôt distant<pre>git push origin master</pre>}}

Dernière version du 24 janvier 2013 à 10:32

LogoGit.svg

Configurer Git-daemon

Installation

# yum install git-daemon

Initialisation du repository

Le paquet git-daemon offre une configuration initiale satisfaisante utilisant le service xinetd.

On vérifie la présence de la ligne suivante dans le fichier /etc/services :

$ grep 9418 /etc/services
git             9418/tcp                # git pack transfer service
git             9418/udp                # git pack transfer service

Par défaut, la configuration exporte les dépôts git présents dans les répertoires utilisateurs <path>~/vcs</path> (paramètre user-path) et <path>/var/lib/git</path> (paramètre base-path).

On supprimera le switch --export-all pour limiter l'export aux seuls dépôts possédant le fichier <path>git-daemon-export-ok</path>.

 $ cat /etc/xinetd.d/git
 # default: off
 # description: The git dæmon allows git repositories to be exported using \
 #	the git:// protocol.
 service git
 {
 	 disable	= no
         socket_type     = stream
         wait            = no
         user            = git
         server          = /usr/libexec/git-core/git-daemon
         server_args     = --base-path=/var/lib/git --user-path=~/vcs --syslog --inetd --verbose
         log_on_failure  += USERID
         # xinetd doesn't do this by default. bug #195265
         flags		= IPv6
 }

Bien évidemment, il faudra redémarrer le service xinetd pour que celui-ci prenne en compte les modifications apportées.

systemctl restart xinetd.service

Création du répertoire de travail de git

mkdir -p /var/lib/git
cp /etc/skel/.bash* /var/lib/git/

Ajout d'un utilisateur et un groupe dédié au service

useradd -r -d /var/lib/git -s /bin/bash -c 'Git user' git

et mise en place d'un mot de passe

passwd git
Idea.png
Génération de mot passe
Le projet KDE fournit un générateur de mot de passe: <app>kpassgen</app>.

Changement du l'utilisateur et du groupe propriétaires du répertoire de travail

chown -R git:git /var/lib/git

Initialisation de ssh

su - git
ssh-keygen -t rsa
touch .ssh/known_hosts .ssh/authorized_keys
chmod 600 .ssh/authorized_keys
chmod 644 .ssh/known_hosts

Mise en place d'un dépôt existant

Avec le compte utilisateur git, on exporte notre dépôt existant directement dans le répertoire de travail.

su - git
$ git clone --bare file:///home/didier/vcs/scripts scripts.git

On autorise l'export de notre projet par le service git

$ touch scripts.git/git-daemon-export-ok

Mise en place d'un nouveau dépôt

# su - git
$ mkdir newrepo.git
$ cd newrepo.git
$ git init --bare

On autorise l'export de notre projet par le service git

$ touch newrepo.git/git-daemon-export-ok

Ajout d'un utilisateur local existant

Pour permettre le push, il faudra configurer un accès ssh pour chaque développeur. Attribuer le dépôt git à un groupe unix puis rattacher les développeurs à celui-ci est une bonne pratique.

cat /home/$USER/.ssh/id_rsa.pub >> /var/lib/git/.ssh/authorized_keys

Ajout d'un nouvel utilisateur local

Git offre un shell de connexion minimaliste git-shell ne permettant que les opérations push et pull.
Ici, on crée un compte pour l'utilisateur joe avec git-shell pour shell de connexion et on l'ajoute au groupe repo1 :

# groupadd repo1
# useradd joe -s /usr/bin/git-shell -G repo1
# chgrp -R repo1 /var/lib/git/repo1

Selinux

Les dépôts git doivent avoir le contexte git_sys_content_t

Le répertoire caché <path>/var/lib/git/.ssh</path> qui doit avoir le contexte ssh_home_t.

On fixe les permissions selinux comme ceci

semanage fcontext -a -t ssh_home_t '/var/lib/git/.ssh(/.*)?'
semanage fcontext -a -t git_system_t '/var/lib/git/.*\.git(/.*)?'
restorecon -Rv /var/lib/git

Tests

Accès lecture seule

Ici n'importe qui ayant accès au serveur peut cloner le dépôt.

$ git clone git://localhost/rpm
Cloning into 'rpm'...
remote: Counting objects: 96, done.
remote: Compressing objects: 100% (89/89), done.
remote: Total 96 (delta 6), reused 96 (delta 6)
Receiving objects: 100% (96/96), 56.60 MiB | 41.59 MiB/s, done.
Resolving deltas: 100% (6/6), done.

On modifie le dépôt local.

$ touch test
$ git add test
$ git commit -m 'Add test file'
[master 4fc0b91] Add test file
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test

Mais la modification du dépôt distant rapporte une erreur.

$ git push
fatal: remote error: access denied or repository not exported: /rpm

Nous avons donc bien un dépôt public en lecture seule

Accès en lecture écriture

Il faut avoir préalablement importer la clé ssh publique de l'utilisateur comme expliqué ici.

On peut tout de suite testé si la clé est bien intégrée

$ ssh git@localhost
Last login: Wed Jan 23 18:30:23 2013 from localhost
$

On clone le dépôt sans problème

$ git clone git@localhost:rpm.git
Cloning into 'rpm'...
remote: Counting objects: 96, done.
remote: Compressing objects: 100% (89/89), done.
remote: Total 96 (delta 6), reused 96 (delta 6)
Receiving objects: 100% (96/96), 56.60 MiB | 21.12 MiB/s, done.
Resolving deltas: 100% (6/6), done.

On modifie le dépôt local

$ cd rpm
$ touch test
]$ git add test
$ git commit -m 'Add test file'
[master e6bab0d] Add test file
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test

On synchronise le dépôt distant facilement

$ git push
Counting objects: 4, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 269 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To git@localhost:rpm.git
   af18a33..e6bab0d  master -> master

Nous avons bien accès en lecture/écriture sur le dépôt distant.

Note.png
Push sur un dépôt distant vide
A la première synchronisation sur un dépôt distant vide, il faut préciser le dépôt distant
git push origin master