synchonisation de structure ch3-6

Author: jnavila

book/04-git-server/sections/generating-ssh-key.asc

@@ -1,8 +1,8 @@
 [[s_generate_ssh_key]]
-== Génération des clés publiques SSH
-(((clés SSH)))
+=== Génération des clés publiques SSH
 
-Cela dit, de nombreux serveurs Git utilisent une authentification par clés publiques SSH.
+(((clés SSH)))
+De nombreux serveurs Git utilisent une authentification par clés publiques SSH.
 Pour fournir une clé publique, chaque utilisateur de votre système doit la générer s'il n'en a pas déjà.
 Le processus est similaire sur tous les systèmes d'exploitation.
 Premièrement, l'utilisateur doit vérifier qu'il n'en a pas déjà une.
@@ -23,7 +23,7 @@ Si vous ne voyez pas ces fichiers (ou n'avez même pas de répertoire `.ssh`), v
 
 [source,console]
 ----
-$ ssh-keygen
+$ ssh-keygen -o
 Generating public/private rsa key pair.
 Enter file in which to save the key (/home/schacon/.ssh/id_rsa):
 Created directory '/home/schacon/.ssh'.
@@ -36,6 +36,7 @@ d0:82:24:8e:d7:f1:bb:9b:33:53:96:93:49:da:9b:e3 [email protected]
 ----
 
 Premièrement, le programme demande confirmation de l'endroit où vous souhaitez sauvegarder la clé (`.ssh/id_rsa`) puis il demande deux fois d'entrer un mot de passe qui peut être laissé vide si vous ne souhaitez pas devoir le taper quand vous utilisez la clé.
+Cependant, si vous utilisez un mot de passe, assurez-vous d'ajouter l'option `-o` ; cela sauvegarde la clé privé dans un format qui est plus résistant au craquage par force brute des mots de passe que le format par défaut.
 
 Maintenant, chaque utilisateur ayant suivi ces indications doit envoyer la clé publique à la personne en charge de l'administration du serveur Git (en supposant que vous utilisez un serveur SSH réglé pour l'utilisation de clés publiques).
 Ils doivent copier le contenu du fichier `.pub` et l'envoyer par courriel.

book/04-git-server/sections/git-daemon.asc

@@ -1,4 +1,4 @@
-== Démon (_Daemon_) Git
+=== Démon (_Daemon_) Git
 
 (((servir des dépôts, protocole git)))
 Dans la suite, nous allons configurer un _daemon_ qui servira des dépôts sur le protocole « Git ».
@@ -13,46 +13,45 @@ Grossièrement, il suffit de lancer la commande suivante en tant que _daemon_ :
 
 [source,console]
 ----
-git daemon --reuseaddr --base-path=/opt/git/ /opt/git/
+git daemon --reuseaddr --base-path=/srv/git/ /srv/git/
 ----
 
 `--reuseaddr` autorise le serveur à redémarrer sans devoir attendre que les anciennes connexions expirent, l'option `--base-path` autorise les utilisateurs à cloner des projets sans devoir spécifier le chemin complet, et le chemin en fin de ligne indique au _daemon_ Git l'endroit où chercher des dépôts à exporter.
 Si vous utilisez un pare-feu, il sera nécessaire de rediriger le port 9418 sur la machine hébergeant le serveur.
 
 Transformer ce processus en _daemon_ peut s'effectuer de différentes manières qui dépendent du système d'exploitation sur lequel il est lancé.
-Sur une machine Ubuntu, c'est un script Upstart.
-Donc dans le fichier :
+
+Puisque `systemd` est le système d'init le plus habitituel sur les distributions Linux modernes, vous pouvez l'utiliser pour cela.
+Placez simplement un fichier `/etc/systemd/system/git-daemon.service` avec le contenu suivant :
 
 [source,console]
 ----
-/etc/event.d/local-git-daemon
-----
+[Unit]
+Description=Start Git Daemon
 
-mettez le script suivant :
+[Service]
+ExecStart=/usr/bin/git daemon --reuseaddr --base-path=/srv/git/ /srv/git/
 
-[source,console]
-----
-start on startup
-stop on shutdown
-exec /usr/bin/git daemon \
-    --user=git --group=git \
-    --reuseaddr \
-    --base-path=/opt/git/ \
-    /opt/git/
-respawn
-----
+Restart=always
+RestartSec=500ms
 
-Par sécurité, ce _daemon_ devrait être lancé par un utilisateur n'ayant que des droits de lecture seule sur les dépôts — simplement en créant un nouvel utilisateur « git-ro » qui servira à lancer le _daemon_.
-Par simplicité, nous le lancerons avec le même utilisateur « git » qui est utilisé par `git-shell`.
+StandardOutput=syslog
+StandardError=syslog
+SyslogIdentifier=git-daemon
 
-Au redémarrage de la machine, votre _daemon_ Git démarrera automatiquement et redémarrera s'il meurt.
-Pour le lancer sans avoir à redémarrer, vous pouvez lancer ceci :
+User=git
+Group=git
 
-[source,console]
-----
-initctl start local-git-daemon
+[Install]
+WantedBy=multi-user.target
 ----
 
+Vous aurez noté que ce daemon Git est lancé ici avec comme utilisateur et groupe `git`.
+Modifiez-le pour correspondre à vos besoins et assurez-vous que l'utilisateur fourni existe sur le système.
+Vérifiez aussi que le binaire Git est bien à l'emplacement `/usr/bin/git` ou changer le chemin si nécessaire.
+
+Enfin, lancez `systemctl enable git-daemon` pour démarrer automatiquement le service au démarrage ; vous pouvez démarrer et arrêter le service avec respectivement `systemctl start git-daemon` et `systemctl stop git-daemon`.
+
 Sur d'autres systèmes, le choix reste large, allant de `xinetd` à un script de système `sysvinit` ou à tout autre moyen — tant que le programme est démonisé et surveillé.
 
 Ensuite, il faut spécifier à Git quels dépôts sont autorisés en accès non authentifié au moyen du serveur.

book/04-git-server/sections/git-on-a-server.asc

@@ -1,5 +1,5 @@
 [[s_git_on_the_server]]
-== Installation de Git sur un serveur
+=== Installation de Git sur un serveur
 
 Nous allons à présent traiter de la configuration d'un service Git gérant ces protocoles sur votre propre serveur.
 
@@ -34,7 +34,7 @@ Il y a quelques légères différences dans le fichier de configuration mais pou
 La commande extrait le répertoire Git sans répertoire de travail et crée un répertoire spécifique pour l'accueillir.
 
 [[s_bare_repo]]
-=== Copie du dépôt nu sur un serveur
+==== Copie du dépôt nu sur un serveur
 
 À présent que vous avez une copie nue de votre dépôt, il ne reste plus qu'à la placer sur un serveur et à régler les protocoles.
 Supposons que vous avez mis en place un serveur nommé `git.exemple.com` auquel vous avez accès par SSH et que vous souhaitez stocker vos dépôts Git dans le répertoire `/srv/git`.
@@ -74,13 +74,13 @@ Dans les chapitres à venir, nous traiterons de mises en place plus sophistiqué
 Ces sujets incluront l'élimination du besoin de créer un compte système pour chaque utilisateur, l'accès public aux dépôts, la mise en place d'interfaces utilisateur web, etc.
 Néanmoins, gardez à l'esprit que pour collaborer avec quelques personnes sur un projet privé, tout ce qu'il faut, c'est un serveur SSH et un dépôt nu.
 
-=== Petites installations
+==== Petites installations
 
 Si vous travaillez dans un petit groupe ou si vous n'êtes qu'en phase d'essai de Git au sein de votre société avec peu de développeurs, les choses peuvent rester simples.
 Un des aspects les plus compliqués de la mise en place d'un serveur Git est la gestion des utilisateurs.
 Si vous souhaitez que certains dépôts ne soient accessibles à certains utilisateurs qu'en lecture seule et en lecture/écriture pour d'autres, la gestion des accès et des permissions peut devenir difficile à régler.
 
-==== Accès SSH
+===== Accès SSH
 
 (((servir des dépôts, SSH)))
 Si vous disposez déjà d'un serveur auquel tous vos développeurs ont un accès SSH, il est généralement plus facile d'y mettre en place votre premier dépôt car vous n'aurez quasiment aucun réglage supplémentaire à faire (comme nous l'avons expliqué dans le chapitre précédent).

book/04-git-server/sections/gitlab.asc

@@ -1,29 +1,27 @@
-== GitLab
+=== GitLab
 
 (((servir des dépôts, GitLab)))(((GitLab)))
 GitWeb reste tout de même simpliste.
 Si vous cherchez un serveur Git plus moderne et complet, il existe quelques solutions libres pertinentes.
 Comme GitLab est un des plus populaires, nous allons prendre son installation et son utilisation comme exemple.
 Cette solution est plus complexe que l'option GitWeb et demandera indubitablement plus de maintenance, mais elle est aussi plus complète.
 
-=== Installation
+==== Installation
 
 GitLab est une application web reposant sur une base de données, ce qui rend son installation un peu plus lourde que certains autres serveurs Git.
 Celle-ci est heureusement très bien documentée et supportée.
+GitLab recommande fortement d'installer GitLab sur votre serveur via le paquet officiel Omnibus GitLab.
 
-GitLab peut s'installer de différentes manières.
-Pour obtenir rapidement quelque chose qui tourne, vous pouvez télécharger une image de machine virtuelle ou un installateur rapide depuis https://bitnami.com/stack/gitlab[], puis configurer plus finement selon vos besoins.(((bitnami)))
-Une touche particulière incluse par Bitnami concerne l'écran d'identification (accessible via `alt + →`) qui vous indique l'adresse IP, l'utilisateur et le mot de passe par défaut de l'instance GitLab installée.
+Les autres options d'installation de GitLab sont :
 
-[[bitnami]]
-.L'écran d’identification de la machine virtuelle du GitLab de Bitnami.
-image::images/bitnami.png[L'écran d’identification de la machine virtuelle du GitLab de Bitnami.]
+* GitLab Helm chart, pour une utilisation avec Kubernetes,
+* des paquets GitLab dockerisés pour une utilisation dans Docker,
+* depuis les fichiers source,
+* Avec un fournisseur Cloud tel que AWS, Google Cloud Platform, Azure, OpenShift et Digital Ocean.
 
-Pour toute autre méthode, suivez les instructions du readme du _GitLab Community Edition_, qui est consultable à https://gitlab.com/gitlab-org/gitlab-ce/tree/master[].
-Vous y trouverez une aide pour installer GitLab en utilisant une recette Chef, une machine virtuelle sur Digital Ocean, ou encore via RPM ou DEB (qui, au moment de la rédaction du présent livre sont en bêta).
-Il existe aussi des guides « non-officiels » pour faire fonctionner GitLab avec des systèmes d'exploitation ou de base données non standards, un script d'installation totalement manuel et d'autres guides couvrant d'autres sujets.
+Pour de plus amples informations, référez-vous au https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/README.md[readme de GitLab Community Edition (CE)].
 
-=== Administration
+==== Administration
 
 L'interface d'administration de GitLab passe par le web.
 Pointez simplement votre navigateur sur le nom d'hôte ou l'adresse IP où GitLab est hébergé et identifiez-vous comme administrateur.
@@ -34,7 +32,7 @@ Une fois identifié, cliquez sur l’icône « Admin area » dans le menu en h
 .L'entrée « Admin area » dans le menu GitLab.
 image::images/gitlab-menu.png[L’entrée « Admin area » dans le menu GitLab.]
 
-==== Utilisateurs
+===== Utilisateurs
 
 Les utilisateurs dans GitLab sont des comptes qui correspondent à des personnes.
 Les comptes utilisateurs ne sont pas très complexes ; ce sont principalement des collections d'informations personnelles rattachées à chaque information d'identification.
@@ -53,7 +51,7 @@ Tous les projets et les données situées dans son espace de nom sont effacés e
 Il s'agit clairement d'une action plus destructive et permanente, et son usage est assez rare.
 
 [[s_gitlab_groups_section]]
-==== Groupes
+===== Groupes
 
 Un groupe GitLab est un assemblage de projets, accompagné des informations de droits d'accès à ces projets.
 Chaque groupe a un espace de nom de projet (de la même manière que les utilisateurs), donc si le groupe +formation+ a un projet +matériel+, son URL sera `http://serveur/formation/matériel`.
@@ -66,7 +64,7 @@ Chaque groupe est associé à des utilisateurs, dont chacun dispose d'un niveau
 Ces niveaux s'échelonnent de _invité_ : `Guest` (tickets et discussions seulement) à _propriétaire_ : `Owner` (contrôle complet du groupe, ses membres et ses projets).
 Les types de permissions sont trop nombreux pour être énumérés ici, mais GitLab fournit un lien très utile sur son écran d'administration.
 
-==== Projets
+===== Projets
 
 Un projet GitLab correspond grossièrement à un dépôt Git unique.
 Tous les projets appartiennent à un espace de nom unique, que ce soit un utilisateur ou un groupe.
@@ -77,13 +75,13 @@ Si un projet est privé (_Private_), l'accès au projet doit être explicitement
 Un projet interne (_Internal_) est visible par tout utilisateur identifié, et un projet public (_Public_) est un projet visible par tout le monde.
 Notez que ces droits contrôlent aussi bien les accès pour git `fetch` que les accès à l'interface utilisateur web du projet.
 
-==== Crochets (_Hooks_)
+===== Crochets (_Hooks_)
 
 GitLab inclut le support pour les crochets, tant au niveau projet que système.
 Pour ces deux niveaux, le serveur GitLab lance des requêtes HTTP POST contenant un JSON de description lorsque certains événements précis arrivent.
 C'est une excellent moyen de connecter vos dépôts Git et votre instance GitLab avec le reste de vos automatisations de développement, telles que serveurs d'intégration continue, forum de discussion et outils de déploiement.
 
-=== Usage de base
+==== Usage de base
 
 La première chose à faire avec GitLab est de créer un nouveau projet.
 Pour cela, il suffit de cliquer sur l’icône `+` sur la barre d'outils.
@@ -111,7 +109,7 @@ $ git clone https://serveur/espace_de_nom/projet.git
 L'interface utilisateur web donne accès à différentes vues utiles du dépôt lui-même.
 La page d'accueil de chaque projet montre l'activité récente et des liens alignés en haut vous mènent aux fichiers du projet et au journal des _commits_.
 
-=== Coopérer
+==== Coopérer
 
 Le moyen le plus simple de coopérer sur un projet GitLab consiste à donner à un autre utilisateur un accès direct en écriture sur le dépôt Git.
 Vous pouvez ajouter un utilisateur à un projet en sélectionnant la section `Members` des paramètres du projet et en associant le nouvel utilisateur à un niveau d'accès (les différents niveaux d'accès sont abordés dans <<ch04-git-server#s_gitlab_groups_section>>).

book/04-git-server/sections/gitweb.asc

@@ -1,4 +1,4 @@
-== GitWeb
+=== GitWeb
 
 (((servir des dépôts, GitWeb)))(((GitWeb)))
 Après avoir réglé les accès de base en lecture/écriture et en lecture seule pour vos projets, vous souhaiterez peut-être mettre en place une interface web simple de visualisation.

book/04-git-server/sections/hosted.asc

@@ -1,4 +1,4 @@
-== Git hébergé
+=== Git hébergé
 
 Si vous ne vous ne voulez pas vous investir dans la mise en place de votre propre serveur Git, il reste quelques options pour héberger vos projets Git sur un site externe dédié à l'hébergement.
 Cette méthode offre de nombreux avantages : un site en hébergement est généralement rapide à créer et facilite le démarrage de projets, et n'implique pas de maintenance et de surveillance de serveur.