L'administration système et de services en ligne implique des choix d'organisation, de nommage, de rangement… Ceux-ci peuvent être très variés d'une équipe à l'autre.

Afin d'avoir une forme d'homogénéité dans le Chapril, voici sous forme de FAQ, quelques conventions techniques à suivre, dans la mesure du possible.

Bien sûr, ces conventions sont ouvertes au changement et aux propositions d'évolution. Mais ça se fera de façon concertée. En attendant, elles restent une référence importante pour tout déploiement d'un service dans le Chapril.

Le dossier /etc/ est « gité » via EtcKeeper. Penser à commiter dès que vous y faites une modification.

Traditionnellement, le fichier de configuration d'un site web est dans /etc/apache2/sites-available/ ou /etc/nginx/sites-available/.

Conventions techniques recommandées :

• donner le nom complet du service : foo.chapril.org.conf.

Exemples :

=(^-^)=root@lamp:/etc/apache2/sites-available# ll
total 44
-rw-r--r-- 1 root root  498 sept. 27 14:11 banner.chapril.org.conf
-rw-r--r-- 1 root root  953 août  14 16:37 date.chapril.org.conf
-rw-r--r-- 1 root root 6338 juil. 18  2017 default-ssl.conf
-rw-r--r-- 1 root root  495 août  14 16:38 paste.chapril.org.conf
-rw-r--r-- 1 root root  466 sept. 24 17:34 v1.chapril.org.conf
-rw-r--r-- 1 root root 1828 oct.  13 19:37 v2.chapril.org.conf
-rw-r--r-- 1 root root 1917 nov.  29 23:40 www.chapril.org.conf

L'emplacement par défaut pour les fichiers web d'un service, c'est /var/www/foo.chapril.org.

Traditionnellement, les logs HTTP sont dans /var/log/apache2/ ou /var/log/nginx/. C'est bien. Mais comme on est susceptible d'avoir beaucoup de service et que les fichiers sont « logrotatées », ça devient vite illisible.

Conventions techniques recommandées :

• pour chaque site web, créer un dossier dédié pour les logs : /var/log/apache2/foo.chapril.org/ ;
• nommage du fichier de log nominal : foo.chapril.org-access.log ;
• nommage du fichier de log erreurs : foo.chapril.org-error.log.

Exemples :

=(^-^)=root@lamp:/var/log/apache2# ll */*access*log
-rw-r----- 1 root adm 2562895 janv.  9 09:22 banner.chapril.org/banner.chapril.org-access.log
-rw-r----- 1 root adm 3692761 janv.  9 09:23 date.chapril.org/date.chapril.org-access.log
-rw-r----- 1 root adm 1248800 janv.  9 09:24 paste.chapril.org/paste.chapril.org-access.log
-rw-r----- 1 root adm 2033797 janv.  9 09:23 v1.chapril.org/v1.chapril.org-access.log
-rw-r----- 1 root adm 2105783 janv.  9 09:22 v2.chapril.org/v2.chapril.org-access.log
-rw-r----- 1 root adm 5313214 janv.  9 09:23 www.chapril.org/www.chapril.org-access.log
=(^-^)=root@lamp:/var/log/apache2# ll */*error*log
-rw-r----- 1 root adm   4093 janv.  9 01:19 banner.chapril.org/banner.chapril.org-error.log
-rw-r----- 1 root adm 206183 janv.  9 09:23 date.chapril.org/date.chapril.org-error.log
-rw-r----- 1 root adm      0 janv.  1 00:00 paste.chapril.org/paste.chapril.org-error.log
-rw-r----- 1 root adm    222 janv.  1 17:45 v1.chapril.org/v1.chapril.org-error.log
-rw-r----- 1 root adm    196 janv.  1 17:45 v2.chapril.org/v2.chapril.org-error.log
-rw-r----- 1 root adm  23273 janv.  9 08:13 www.chapril.org/www.chapril.org-error.log

Pour profiter des IP proxifiées, activer le combined :

 CustomLog ${APACHE_LOG_DIR}/foo.chapril.org/foo.chapril.org-access.log combined-proxy

Pour le projet foo.chapril.org, les mettre dans le dossier /var/log/foo.chapril.org/.

Tout service a son « home directory » dans /srv/ avec comme nom le nom complet du service. Le dossier ne sera jamais gitifié. L'idée est d'avoir un espace dédié aux fichiers du service, ceux d'exploitation ou simplement de maintenance (exports SQL…).

Exemples :

=(^-^)=root@lamp:/srv# ll
total 16
drwxr-xr-x 2 root            root            4096 juil. 18 23:46 bin
drwxr-xr-x 7 datechaprilorg  datechaprilorg  4096 sept. 23  2018 date.chapril.org
drwxr-xr-x 4 pastechaprilorg pastechaprilorg 4096 janv. 10 15:59 paste.chapril.org
drwxr-xr-x 2 root            root            4096 oct.   2 23:54 www.chapril.org

Dans ce dossier, on trouvera notamment :

• un dossier tools : dépôt Git pour les scripts nécessaires à l'exploitation (sondes, rapport d'activité, autres…) ;
• des liens :
  • www : vers le DocumentRoot du site du service,
  • un vers le fichier cron.d s'il y en a un,
  • …

La création d'un utilisateur système dédié au service est optionnelle et dépend des besoins du service, de son déploiement et de son exploitation.

Convention :

• nom du compte : prendre le nom complet du service sans les points (exemple : foochaprilorg) ;
• type de compte : donner le type système au compte ;
• shell : assigner /bin/false ou la valeur nécessaire au service ;
• home directory : /srv/foo.chapril.org/

L'idéal serait un nommage parlant :

• la base : foochaprilorg_redmine_db ou foochaprilorg_bare_db ;
• le compte Mariadb : foochaprilorg_dbadmin.

Mais dans la pratique, on peut se simplifier la vie :

• la base : nomduproduit_db (exemples : kanboard_db, framadate_db) ;
• le compte : nomduproduit (exemples : kanboard, framadate).

Dans le cas d'un service nécessitant beaucoup d'espace disque, alors créer une partition dédiée. Cette partition data ne devra contenir que des données, pas de code de l'application du service.

Exemple : https://admin.chapril.org/doku.php?id=admin:services:drop.chapril.org#preparation

L'équipe infra gère le flux mail. Configuration à faire : localhost sur le port 25.

L'adresse de courriel d'un service nommé foo est foo-support@chapril.org.

En cas de demande d'information sur ce courriel, ouvrir un ticket de traçage en prenant garde soit de masquer les informations sensibles, soit en cochant « privé » à la création du ticket.

La sagesse unixienne recommande aux utilisateurs de passer par crontab -u user -e pour déclarer une tâche cron sans perturber le système. C'est vraiment une bonne idée. Sauf que sur nos vm, nous ne sommes pas des utilisateurs mais des adminsys. Et même si certains services tournent sous un compte Unix dédié, il s'agit d'un compte système et non d'un compte utilisateur classique.

En conséquence, les recommandations sont les suivantes :

• les tâches cron sont à déclarer dans /etc/cron.d/ ;
• les tâches cron sont à mettre dans un ou plusieurs fichiers dédiés au service ;
• le nommage doit reprendre le nom du service (foochaprilorg, foochaprilorg-bare) ;
• penser à commiter en cas de modification (avoir bien configuré son SSH pour transférer les variables GIT nécessaires) ;
• logger la tâche cron (exemple : …/task.sh » /var/log/foo.chapril.org/bar.log 2>&1).

Exemples de nommage :

=(^-^)=root@lamp:/etc/cron.d# ll
total 16
-rw-r--r-- 1 root root  63 juil. 18 16:30 backup
-rw-r--r-- 1 root root 375 janv.  6 23:10 datechaprilorg
-rw-r--r-- 1 root root 134 déc.   7 10:48 pastechaprilorg
-rw-r--r-- 1 root root 712 janv.  1  2017 php

Avantages :

• facilité d'accès pour les adminsys quand ils cherchent le cron d'un service ;
• historisation et traçabilité de la configuration ;
• alertes Icinga2 si oublie de commit ;
• sauvegarde automatique ;
• …

Pour certains services, la personnalisation passe par la modification du code du service. Afin de suivre et pouvoir propager les modifications dans les futures versions, la mise sous Git du code est nécessaire (si ce n'est pas déjà fait).

À ce moment là, il faut créer une branche dédiée au Chapril nommée chapril-x.y.z en reprenant le numéro de la version du projet officielle.

En tant qu'animateur d'un service, bien sûr. Cela reste de la communication, au pire la personne le réassignera. Le mieux étant de la contacter avant.

Les tickets ne sont pas le cœur du projet. Le cœur du projet, ce sont l'équipe, les utilisateurs et les services. Les tickets servent à construire une image de où on en est. Donc ce n'est pas la priorité mais quand même bien nécessaire pour suivre et assurer une qualité à l'activité.

Quelques principes :

• un ticket non assigné est un ticket en souffrance ;
• ne pas laisser trop longtemps les tickets en statut « Résolu » ;
• …

L'organisation du Chapril est faite pour faciliter la vie des animateurs de services. Besoin d'une action en dehors de la vm du service ? Alors interpeler un membre de l'équipe infra :D

Par simplicité, si possible, privilégier la directive php_admin_value open_basedir.

Chaque service du Chapril a son courriel de support : foo-support@chapril.org.

Et parfois, des utilisateurs écrivent à cette adresse. Voici un plan de traitement :

• 1) répondre en privé :
  • expéditeur :
    • utiliser son courriel @april.org, c'est l'idéal,
    • éviter absolument d'utiliser une adresse GAFAM ou FAI,
  • en copie :
    • foo-support@chapril.org
  • contenu :
    • dire qui l'on est.

Modèle de courriel de réponse :

  Bonjour Ada,
  
  Je suis Christian Momon, l'animateur bénévole du service foo.chapril.org. Nous sommes
heureux que nos services numériques libres, éthiques et loyaux puissent vous être utiles.

 [réponse à la demande]

 En vous souhaitant, au nom de toute l'équipe du Chapril, un agréable
usage de nos services libres, éthiques et loyaux.

 Librement,

 Christian (Cpm).

• 2) créer un ticket :
  • sujet : copiercollerlesujetducourrielavecescrochets
  • description : copier/coller le courriel en anonymisant un peu :

  Le 20/01/2010, Laurence R. a écrit sur foo-support@chapril.org :
    Bonjour,
    […]
 

• ajouter en commentaire le copier/coller de votre réponse

• 3) partager
  • sur chapril@ : si le sujet est pertinent : par exemple, en cas de remerciements, ça fera toujours plaisir à l'équipe
  • …

Privilégier l'UTF8. Par exemple, avec Mysql/MariaDB, systématiquement faire du utf8mb4.

Ça permet de gérer les émoticons dans la base. Ça permettra surtout d'éviter des migrations de bases…

Exemple :

CREATE DATABASE IF NOT EXISTS gitea_db DEFAULT CHARACTER SET utf8mb4 COLLATE 'utf8mb4_unicode_ci';