Différences

Ci-dessous, les différences entre deux révisions de la page.

--- admin:procedures:ajouter-administrateur [2017/06/23 10:03] – [Donner accès au password store] fpoulain
+++ admin:procedures:ajouter-administrateur [2025/01/07 21:47] (Version actuelle) – s/{coon,maine}/{korat,persan}/ pilou
@@ Ligne 1: / Ligne 1: @@
 ====== Ajout d'un administrateur au cluster ======
-Il faut pour cela donner accès aux mots de passe et déployer les clés ssh sur le cluster.
+Il faut pour cela donner accès aux mots de passe, donner accès au [[sysadm:git_admin_sys|git]], et déployer les clés ssh sur le cluster.
+===== Donner accès au git =====
+C'est un gitolite qui se configure par un repos git : ''gitolite-admin''. Pour avoir une idée ça ressemble à ça :
+<code>
+$ cd gitolite-admin
+$ tree
+.
+├── conf
+│   └── gitolite.conf
+└── keydir
+    ├── admin-doku.pub
+    ├── benj.pub
+    ├── edausq.pub
+    ├── madix.pub
+    ├── PoluX.pub
+    ├── QGuLL.pub
+    └── vincentxavier.pub
+</code>
+On commence par copier le pubring ssh du nouvel admin dans le dossier ''keydir''.
+Ensuite dans ''conf/gitolite.conf'' on complète la définition @admins avec le nom du pubring qui convient.
+<code conf conf/gitolite.conf>
+admins = edausq PoluX QGuLL vincentxavier benj madix nouvelAdmin
+</code>
+Enfin on commit et on pousse.
+<code>
+git add *
+git commit -m 'ajout nouvelAdmin'
+git push
+</code>
 ===== Déploiement des clés ssh sur le cluster =====
@@ Ligne 11: / Ligne 44: @@
 On installe les nouvelles clés ssh dans ''sexy-chapril/authorized_keys/root''.
-Ensuite on édite ''sexy-chapril/debian/changelog'' est on recopie matatis mutandis la dernière entrée en tête du fichier:
+Ensuite on édite ''sexy-chapril/debian/changelog'' et on recopie matatis mutandis la dernière entrée en tête du fichier:
 <code conf sexy-chapril/debian/changelog>
 sexy-chapril (1.2) stable; urgency=medium
@@ Ligne 43: / Ligne 76: @@
 Pour les accès, la config ssh suivante devrait suffire :
 <code ssh ~/.ssh/config>
-Host coon.chapril.org maine.chapril.org
+Host korat.chapril.org persan.chapril.org
   User root
-  ForwardAgent yes
   SendEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
-Host bastion.cluster.chapril.org
+Host felicette.chapril.org
-  Hostname fip.chapril.org
-  User root
-  ForwardAgent yes
-  SendEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
-Host icinga2.chapril.org
   User root
   Port 2242
-  ForwardAgent yes
   SendEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
 Host *.cluster.chapril.org
   User root
-  ProxyCommand ssh -W %h:22 root@fip.chapril.org -A
+  ProxyJump root@fip.chapril.org
-  ForwardAgent yes
   SendEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
 </code>
@@ Ligne 69: / Ligne 93: @@
 ===== Donner accès au password store =====
-On utilise [[https://www.passwordstore.org/|password store]]. C'est ''pass'' sous debian et le paquet à installer est ''pass''.
+On utilise [[https://www.passwordstore.org/|password store]], [[admin:procedures:configuration_password_store|documenté ici]]. C'est ''pass'' sous debian et le paquet à installer est ''pass''.
 Pour se faciliter la vie si c'est votre unique dépot on peut faire un lien symbolique vers le dépot chapril :
@@ Ligne 81: / Ligne 105: @@
   gpg --list-key `cat .gpg-id`
   gpg --list-key `cat .gpg-id` | grep pub -A1 | grep @ | sed 's/uid *//'
+Des clés GPG sont présentes dans le dossier //…/password-store/ClésGPG///
 Supposons qu'on veuille ajouter l'accès à un certain Frédéric Couchet. On recherche sa clé dans notre trousseau :
@@ Ligne 92: / Ligne 118: @@
 Pass requiert des clés de confiance. Il vous faudra a priori signer la clé si ce n'est déjà fait.
-<note warning>Une signature de clé ça ne se fait pas à la légère !! Assurez vous de pouvoir contrôler préalablement le fingerprint de la clé, présenté en personne par l'admin concerné.</note>
+<note warning>Une signature de clé ça ne se fait pas à la légère !! Assurez vous de pouvoir contrôler préalablement le fingerprint de la clé, présenté via un canal sûr (idéalement en personne) par l'admin concerné.</note>
 On va réencoder le dépôt pour toutes les clés listées en option de init :
@@ Ligne 105: / Ligne 131: @@
 <note important>Attention si vous vous poutrez sur l'étape précédente il est possible que le dépôt ne soit plus lisible par vous ni par personne après.</note>
+<note tip>En cas de soucis voir plus bas.</note>
 Et on peut vérifier que tout s'est bien passé en prenant dans des fichiers de pass :
-  gpg --list-packets --list-only Services/icinga.gpg
+  gpg --list-packets --list-only Infra/icinga.chapril.org/icinga2-icinga.gpg
+On peut aussi vérifier qu'on a soi-même accès :
+  pass Infra/icinga.chapril.org/icinga2-icinga
 Puis on pousse :
@@ Ligne 165: / Ligne 196: @@
 sub   4096R/95F17989 2016-08-08 [expire : 2018-08-08]
 </code>
+==== Soucis avec pass, git ou gpg ====
+=== Aucune assurance que la clef appartienne vraiment à l'utilisateur nommé ===
+L'erreur se  manifeste ainsi :
+<code>
+gpg: DEADBEEF : aucune assurance que la clef appartienne vraiment à l'utilisateur nommé.
+sub  rsa4096/DEADBEEF 2042-42-42 douglas@adams.42
+Empreinte clef princip. : DEAD BEEF
+ Empreinte de sous-clef : DEAD BEEF
+La clef n'appartient PAS forcément à la personne nommée
+dans l'identité. Si vous savez *vraiment* ce que vous
+faites, vous pouvez répondre oui à la prochaine question.
+Faut-il quand même utiliser cette clef ? (o/N) o
+</code>
+Solution: donner un niveau de confiance fort à la clé.
+  gpg --edit-key DEADBEEF
+  tsign
+  --> suivez selon les pointillés