Begin to remove CI

.gitlab-ci.yml

-image: docker:19.03.0
-
-# Disable TLS just for the docker daemon running locally, TLS is still used to deploy built images!
-variables:
-  DOCKER_TLS_CERTDIR: ""
-  DOCKER_DRIVER: overlay2
-  GIT_SUBMODULE_STRATEGY: recursive
-
-services:
-    - docker:19.03.0-dind
-
-stages:
-  - ci-base
-  - build
-  - security-tests
-  - push
-
-# Hidden key meant to be included in other jobs, for factorization
-# Login to registry and pull built image
-.pull-modified-image: &pull-modified-image
-  image: $REGISTRY_PROD/pica-ci-base
-  tags: [build]
-  before_script:
-    - sh image_modified_last_commit.sh
-    - source variables
-    - echo $REGISTRY_PASSWORD | docker login $REGISTRY -u $REGISTRY_USERNAME --password-stdin
-    - docker pull $MODIFIED_IMAGE_FULL_TEST
-
-# Build the base image used for all further steps : this is done only when pica-ci's Dockerfile is modified
-pica-ci-base:
-  stage: ci-base
-  tags: [build]
-  before_script:
-    - echo $REGISTRY_PROD_PASSWORD | docker login $REGISTRY_PROD -u $REGISTRY_PROD_USERNAME --password-stdin
-  script:
-    - docker build -f pica-ci-base/Dockerfile . -t $REGISTRY_PROD/pica-ci-base:latest
-    - docker push $REGISTRY_PROD/pica-ci-base:latest
-  after_script:
-    - docker logout $REGISTRY_PROD
-  rules:
-    - if: '$CI_COMMIT_BRANCH == "master" || $CI_COMMIT_BRANCH == "dev-ci"'
-      changes:
-        - "pica-ci-base/Dockerfile"
-      when: manual
-      allow_failure: true
-    - when: never
-
-# Build the image that was modified
-build:
-  stage: build
-  tags: [build]
-  image: $REGISTRY_PROD/pica-ci-base
-  before_script:
-    - sh image_modified_last_commit.sh
-    - source variables
-    # First login on the production registry, in case the image is based on another registry image
-    - echo $REGISTRY_PROD_PASSWORD | docker login $REGISTRY_PROD -u $REGISTRY_PROD_USERNAME --password-stdin
-  script:
-    # Build the image
-    - docker build -f $MODIFIED_IMAGE/Dockerfile $MODIFIED_IMAGE -t $MODIFIED_IMAGE_FULL_TEST
-    - docker logout $REGISTRY_PROD
-    # Then login on the test registry and push the image
-    - echo $REGISTRY_PASSWORD | docker login $REGISTRY -u $REGISTRY_USERNAME --password-stdin
-    - docker push $MODIFIED_IMAGE_FULL_TEST
-  after_script:
-    - docker logout $REGISTRY
-  # Build if Dockerfile changed and previous stage completed successfully
-  rules:
-    - changes:
-      - "pica-*/Dockerfile"
-      - "meta-*/Dockerfile"
-      when: on_success
-    - changes:
-      - "pica-*/**"
-      - "meta-*/**"
-      when: manual
-      allow_failure: true
-    - when: never
-
-# Run CoreOS' Clair and make the CI failed if a critical vulnerability isn't in the whitelist
-clair:
-  stage: security-tests
-  <<: *pull-modified-image
-  script:
-    - docker run -d --name db arminc/clair-db:latest
-    - docker run -p 6060:6060 -d --link db:postgres --name clair --restart on-failure arminc/clair-local-scan:latest
-    - wget https://github.com/arminc/clair-scanner/releases/download/v8/clair-scanner_linux_amd64
-    - mv clair-scanner_linux_amd64 clair-scanner
-    - chmod +x clair-scanner
-    - while( ! wget -q -O /dev/null http://docker:6060/v1/namespaces ) ; do sleep 1 ; done
-    - ./clair-scanner -c http://docker:6060 --ip $(hostname -i) -r clair-report.json -l clair.log -w $MODIFIED_IMAGE/clair-whitelist.yml --threshold="High" $MODIFIED_IMAGE_FULL_TEST
-  artifacts:
-    paths:
-      - clair-report.json
-      - clair.log
-  rules:
-    - changes:
-      - "pica-*/Dockerfile"
-      - "pica-*/clair-whitelist.yml"
-      - "meta-*/Dockerfile"
-      - "meta-*/clair-whitelist.yml"
-      when: on_success
-    - changes:
-      - "pica-*/**"
-      - "meta-*/**"
-      when: manual
-      allow_failure: true
-    - when: never
-
-# Run docker-bench-security and upload the results
-docker-bench-security:
-  stage: security-tests
-  <<: *pull-modified-image
-  script:
-    # Change the Docker Compose to use the "testing" image, not yet pushed on production registry
-    - sed -i -e "s|$MODIFIED_IMAGE_FULL|$MODIFIED_IMAGE_FULL_TEST|g" $MODIFIED_IMAGE/docker-compose.yml
-    # If *.example secrets files exist, remove the .example extension to be able to start the container
-    # Indeed these file are used in Docker Compose with env_file directive
-    - if [[ -d $MODIFIED_IMAGE/secrets ]]; then for i in $MODIFIED_IMAGE/secrets/*.example ; do cp $i $(echo $i| cut -d '.' -f1,2); done; fi;
-    # Let docker-compose create the required volumes and networks
-    - "sed -i -e 's/external: true/external: false/g' $MODIFIED_IMAGE/docker-compose.yml"
-    - cat $MODIFIED_IMAGE/docker-compose.yml
-    - cd $MODIFIED_IMAGE
-    # Login on the production registry, in case there is another image in Docker Compose stored on the production registry
-    - docker logout $REGISTRY
-    - echo $REGISTRY_PROD_PASSWORD | docker login $REGISTRY_PROD -u $REGISTRY_PROD_USERNAME --password-stdin
-    - docker-compose up -d
-    - git clone https://github.com/docker/docker-bench-security.git
-    - cd docker-bench-security
-    - sh docker-bench-security.sh -c container_images,container_runtime,docker_security_operations,community_checks -l ../../report.txt
-  after_script:
-    - docker logout $REGISTRY_PROD
-  artifacts:
-    paths:
-      - report.txt
-  rules:
-    - changes:
-      - "pica-*/**"
-      - "meta-*/**"
-      when: manual
-      allow_failure: true
-    - when: never
-
-
-# Push the generated image on the production registry,
-# once it passed all security tests and has been successfully built
-# and run on the test virtual machine
-push-prod:
-  stage: push
-  <<: *pull-modified-image
-  script:
-    - docker tag $MODIFIED_IMAGE_FULL_TEST $MODIFIED_IMAGE_FULL
-    - echo $REGISTRY_PROD_PASSWORD | docker login $REGISTRY_PROD -u $REGISTRY_PROD_USERNAME --password-stdin
-    # MODIFIED_IMAGE_FULL already should include the registry URL
-    - docker push $MODIFIED_IMAGE_FULL
-  after_script:
-    - docker logout $REGISTRY_PROD
-  rules:
-    - if: '$CI_COMMIT_BRANCH == "master"'
-      changes:
-      - "pica-*/**"
-      when: manual
-    - when: never

README.md

@@ -2,10 +2,12 @@
 
 Ce dépôt centralise les Dockerfiles et autre ressources utilisées pour construire **et** déployer les images Docker tournant en production sur l'infrastructure de Picasoft.
 
+Certains services ne respectent pas encore la structure de ce dépôt (exemple : `nextcloud-docker`, ou Traefik qui reste géré uniquement sur les VM) : ils seront migrés prochainement.
+
 ## Philosophie
 
 Historiquement, Picasoft procède de la manière suivante :
-* Construire ses Dockerfile à la main et les pousser sur un registre privé.
+* Construire les images Docker à partir de Dockerfiles sur une machine quelconque, puis les pousser manuellement sur un registre privé.
 * Gérer un Docker Compose global par VM, qui contient la configuration et les secrets.
 
 Cette approche pose plusieurs problèmes. Comment savoir ce qu'il y a dans une image, si on perd le Dockerfile ? Quel Dockerfile correspond à quelle version de l'image ? Si on perd l'accès à la machine, comment récupérer la configuration, remonter rapidement le service ? Comment versionner les changements de configuration ? Revenir à la version d'il y a deux semaines ?
@@ -13,54 +15,44 @@ Cette approche pose plusieurs problèmes. Comment savoir ce qu'il y a dans une i
 L'objectif de ce dépôt est de rendre possible le déploiement de n'importe quel service Picasoft avec la procédure suivante :
 * Cloner le dépôt
 * Se rendre dans le répertoire du service
-* Lancer un `docker-compose up -d`
+* Lancer un `docker-compose up -d` pour démarrer le service
 
 Son objectif secondaire est de pouvoir revenir à l'état antérieur d'un service. En versionnant toute la configuration nécessaire, revenir à une ancienne version du service revient à :
 * Cloner le dépôt
 * Checkout un commit quelconque
 * Lancer le service normalement
 
-Pour y arriver, il construit automatiquement les images de l'ensemble des services et les met à disposition sur un registre, avec une version. Mise à part les données à proprement parler du service, il n'y a donc aucune différence entre un service lancé sur une de nos machines et un service lancé à partir de ce dépôt sur une machine virtuelle quelconque, ce qui s'inscrit dans la philosophie Docker.
+Mises à part les données à proprement parler du service, il n'y a donc aucune différence entre un service lancé sur une de nos machines et un service lancé à partir de ce dépôt sur une machine virtuelle quelconque, ce qui s'inscrit dans la philosophie Docker.
 
 ## Contenu du dépôt
 
-Ce dépôt contient toutes les ressources permettant de déployer les services que nous maintenons sur n'importe quelle machine virtuelle de l'infrastructure de Picasoft, sans prérequis.
-
-Cela signifie que le bon fonctionnement d'un service n'est pas dépendant de la machine virtuelle sur laquelle on essaye de le lancer.
+Le dépôt est organisé en dossiers. Chaque dossier correspond à un *service* Picasoft au sens large, c'est-à-dire à un ensemble de conteneurs liés entre eux *techniquement* (*e.g.* Mattermost et sa base de données) et/ou *sémantiquement* (*e.g.* sites web statiques, relai et boîte à mail).
 
-Ainsi, chaque service versionné sur ce dépôt contiendra :
+Ainsi, chaque dossier de ce dépôt contiendra, selon les situations :
 
-* Un `Dockerfile` permettant de construire l'image,
+* Zéro, un ou plusieurs `Dockerfile` permettant de construire les images personnalisées pour Picasoft,
 * Un fichier `docker-compose.yml` permettant de lancer le service,
 * Si possible, un ou des fichiers de configuration permettant de personnaliser le service selon nos besoins,
 * Un fichier d'exemple de secrets (mot de passe...) nécessaire au lancement du service,
 * Un `README.md` résumant les paramètres modifiables sur le dépôt, les mécanismes pour en rajouter, etc,
 * Pour les images maison, un `CHANGELOG.md` résumant les modifications faites au fil des version.
 
-Il n'y a pas de Docker Compose global : chaque service a son propre Docker Compose.
+Il n'y a pas de Docker Compose global : chaque service a son propre Docker Compose, lui permettant d'être déployé indépendamment des autres.
 
 Un exemple concret peut être trouvé au niveau de [pica-mattermost](./pica-mattermost) ou [pica-etherpad](./pica-etherpad).
 
-## Mais je commence par où, bordel ?
-
-Ce dépôt peut faire peur, mais pour la plupart des usages il est très simple à exploiter.
+## Guides d'utilisation
 
-### Je veux lancer un service existant sur une machine virtuelle
+### Lancer ou redémarrer un service sur une machine de Picasoft
 
-Si le service que vous souhaitez lancer est référencé sur ce dépôt, lisez [la documentation de déploiement](./doc/guide_deploiement.md#déploiement-en-production).
+Lire [la documentation de déploiement et de maintenance]().
 
-### Je veux mettre à jour un service
+### Mettre à jour un service ou sa configuration
 
-Il faut pour cela utiliser la chaîne d'intégration de ce dépôt, qui construit automatiquement les images Docker. [Lisez la documentation utilisateur de la chaîne d'intégration.](./doc/guide_utilisateur_ci.md).
+Lire [la documentation de mise à jour des services]().
 
-### Je veux mettre en place un nouveau service
+### Mettre en place un nouveau service
 
-Il faudra d'une part [respecter les conventions utilisées par la chaîne d'intégration](./doc/guide_developpeur_ci.md#formalisme-du-dpt).
-
-Ensuite, il faudra jeter un oeil [aux bonnes pratiques](./doc/guide_bonnes_pratiques.md) à l'oeuvre sur l'infrastructure de Picasoft (partie **Formalisme du dépôt**).
+Lire [la documentation de versionnage d'un nouveau service]() et [les bonnes pratiques pour Docker]().
 
 Un dossier [template](./template) prêt à copier est aussi disponible.
-
-### Je veux améliorer la chaîne d'intégration
-
-Lisez la [documentation "développeur" pour la chaîne d'intégration](./doc/guide_developpeur_ci.md), qui rentre plus dans le détail.

doc/mini_guide_cve.md

-# Mini guide pour mitiger une CVE (WIP)
-
-Une CVE est mise en liste blanche en l'ajoutant au fichier `clair-whitelist.yml`, dont on trouvera un exemple [ici](../pica-mattermost/clair-whitelist.yml). Il faut spécifier le nom de la CVE, le paquet affecté et la raison de la mise en liste blanche.
-
-Une mise en liste blanche est **acceptable** si :
-* Clair détecte des vulnérabilités sur le paquet `linux`. En effet, le noyau utilisé par le conteneur est celui de l'hôte. On utilisera le motif `Vulnérabilité Linux`,
-* Le paquet est à jour et ne peut pas être installé dans une version différente à cause de dépendances d'autres paquets,
-* Le paquet ne peut pas être supprimé,
-* Il n'existe pas de contre-mesure à la vulnérabilité,
-* La vulnérabilité, même si elle est classée en criticité `High`, a peu de conséquences pour Picasoft. Cela peut être le cas pour une attaque par déni de service causant un usage de 100% du processeur, qui n'aura d'impact que sur Etherpad en raison des limitations de ressources.
-
-Si jamais il reste un paquet contenant une vulnérabilité `High`, et que les conditions ci-dessus ne sont pas remplies, voici deux choses à tenter avant de le whitelister ou de décider de ne pas déployer la mise à jour.
-
-## Suppression d'un paquet inutile
-
-On prend l'exemple de la `CVE-2020-8492 (High)` détectée par Clair lors d'un build de `pica-db-backup-rotation` ([commit](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/commit/078d448a53da4be9330fd0ac9304a7eb3a26e969), [log de Clair](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/jobs/883005))
-
-![](./images/clair_log_1.png)
-
-Comme on peut le voir sur la capture d'écran ci-dessus, Clair a détecté une nouvelle vulnérabilité avec le label `High`. Cette vulnérabilité concerne plusieurs versions de Python, donc un premier réflexe est de vérifier quelle est la version de Python utilisée dans l'image construite.
-
-Pour cela, récupère la version qui a été poussée sur le registry de test et on lance un conteneur temporaire:
-
-```
-$ docker pull docker pull registry.picasoft.net/pica-db-backup-rotation:1.0
-$ docker run --rm -it registry.picasoft.net/pica-db-backup-rotation:1.0 bash
-```
-
-À l'intérieur du conteneur, on vérifie les versions de Python
-
-```
-root@91ed958145c1:/# python --version
-Python 3.8.2
-root@91ed958145c1:/# python2 --version
-bash: python2: command not found
-```
-
-Ceci semble surprenant, on n'a pas de `python2` et notre `python3` n'est pas vulnérable. Pas de `python2`... vraiment ?
-
-```
-root@95889d5957b6:/# apt list --installed | grep -i python
-
-WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
-
-libpython2.7-minimal/now 2.7.16-2+deb10u1 amd64 [installed,local]
-libpython2.7-stdlib/now 2.7.16-2+deb10u1 amd64 [installed,local]
-libpython2.7/now 2.7.16-2+deb10u1 amd64 [installed,local]
-```
-
-On découvre ainsi qu'il y a bien une partie de Python2 dans notre image. Mais d'où vient-elle ?
-
-```
-root@95889d5957b6:/# apt-cache rdepends libpython2.7
-libpython2.7
-Reverse Depends:
-  libmailutils5
-  mailutils
-```
-
-Et `mailutils` ?
-
-```
-root@95889d5957b6:/# apt-cache rdepends mailutils
-mailutils
-Reverse Depends:
-
-```
-
-Il semblerait qu'on arrive à une impasse, mais non ! On peut toujours exécuter une à une les commandes du [Dockerfile](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/blob/078d448a53da4be9330fd0ac9304a7eb3a26e969/pica-db-backup-rotation/Dockerfile) pour retrouver qu'est-ce qui a installé `mailutils`.
-
-On finit par trouver que c'est cette ligne:
-
-```
-    && apt-get -y install cron \
-```
-
-En effet, lorsqu'on installe cron avec la commande précédente, `apt` installe énormément de dépendances qui ne sont pas nécessaires pour notre cas. On peut donc utiliser l'option `--no-install-recommends` pour installer seulement le nécessaire et ainsi [corriger la CVE](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/commit/5b6bd31225581c40738e9a131a59dec4c8417848).
-
-![](./images/clair_log_2.png)
-
-On remarque que maintenant le nombre de vulnérabilités est passé de 73 à 60, et il n'y a plus aucune vulnérabilité en `High`. On remarque aussi que les CVE-2019-17455 et CVE-2019-18224 qui étaient dans la `clair-whitelist.yml` ne sont plus présentes.

docker-compose/README.md

+**Fusionner `pica-mail-mta` et `pica-mail-mda` et ajouter le fichier Compose `mail.yml`**.

docker_test.sh

@@ -9,7 +9,7 @@ usage() {
   echo "to be sure that it works independently of the former configuration, and then launch 'docker-compose up -d'."
   echo "This way, you can test your Dockerfile | docker-compose on the testing VM as if it was a brand new VM."
   echo -e "\nAlso, it will temporarily replace all occurences of 'picasoft.net' by 'test.picasoft.net' for convenience."
-  echo -e "\nThis script will also use the image uploaded on the testing registry, not the production registry."
+  echo -e "\nThis script will also build and pull all the required images based on the docker-compose.yml file."
   echo -e "\nUSE THIS SCRIPT ONLY ON THE TESTING VM."
   exit 1
 }
@@ -75,10 +75,12 @@ cd "$1"
 
 create_dumb_secrets
 
+# Except for registry URL, useful to push to production registry after build
 echo -e "\n==== Replace production URL with testing URL in all files ===="
 for f in $(grep -l -r ".picasoft.net" .); do
   echo -e "\tFound in" ${f}
   sed -i "s/.picasoft.net/.test.picasoft.net/g" ${f}
+  sed -i "s/registry.test.picasoft.net/registry.picasoft.net/g" ${f}
 done
 
 echo -e "\n==== Remove and re-create named external volumes ===="
@@ -95,7 +97,10 @@ echo -e "\n==== Remove old images ===="
 # For some reasons, sometime docker-compose does not pull the newer image. Force this!
 docker-compose config | grep "image:" | cut -d ':' -f 2- | xargs docker image rm || true
 
-echo -e "\n==== Pull new versions of images ===="
+echo -e "\n==== Build custom images ===="
+docker-compose build
+
+echo -e "\n==== Pull new versions of external images ===="
 docker-compose pull
 
 echo -e "\n==== Lauch $1 ===="

image_modified_last_commit.sh

-#!/bin/sh
-
-# Retrieve the name and the version of the image that was modified in the latest commit
-# This script should become obsolete as soon as a proper way of getting the modified files is added to Gitlab CI
-
-# Image name, without registry nor tag
-RES=""
-for i in $(git log -m -1 --name-only --pretty="format:" --first-parent)
-do
-  case "$i" in
-    *pica*|*meta*)
-      RES=$(echo $i | cut -d '/' -f1)
-      break
-      ;;
-  esac
-done
-
-if [ "$RES" = "" ]; then
-  echo "Error : no folder starting by pica or meta modified in last commit."
-  echo "Please check README.md for further understanding."
-  exit 1;
-fi
-
-echo "export MODIFIED_IMAGE=${RES}" > variables
-echo "Using modified folder : $RES"
-
-# Image name with wanted registry and tag, fetched from Docker Compose
-RES=$(cat $RES/docker-compose.yml | grep $RES: | cut -d ':' -f2- | cut -d '/' -f2- | tr -d ' ' | head -n 1)
-if [ "$RES" = "" ]; then
-  echo "Error : no reference to $RES found in docker-compose.yml."
-  echo "Please check the repository README : the name of the folder must be the same as name of the image."
-  exit 1
-fi
-
-echo "export MODIFIED_IMAGE_FULL_TEST=registry.test.picasoft.net/${RES}" >> variables
-echo "export MODIFIED_IMAGE_FULL=registry.picasoft.net/${RES}" >> variables

meta-registry-test/Dockerfile

-FROM registry:2.7

meta-registry-test/README.md

-(WIP)
-
-[Docker Registry](https://docs.docker.com/registry/) used by the CI/CD in this repo for image testing.
-
-## Usage
-
-### First time
-
-_This guide assumes that a (manually deployed) registry is already running in `pica01-test`_
-
-1. Generate a password in [picapass](https://gitlab.utc.fr/picasoft/interne/pass/)
-2. Generate a new `htpasswd` file with `htpasswd -Bn <username>`. This will prompt you for the password and will display results on stdout
-3. In `pica01-test`, create `/DATA/docker/dockerfiles/meta-registry-test/secrets/htpasswd` and paste there the output of the previous command. Make sure permissions are correct (`660`).
-
-### Updating this image
-
-Update: Same as in general [README.md](/README.md) (don't forget to increase the version number in `docker-compose.yml`). The CI will build an image and deploy it to the old test registry.
-Deploy: not the same !!
-
-### Deploy updates
-
-**Do not use `docker_test.sh` or `docker_prod.sh` to deploy this`.** Deploy manually:
-
-1. `cd /DATA/docker/dockerfiles/ && git pull`
-2. Pull the new image from the old registry (E.g. `docker pull registry.test.picasoft.net/meta-registry-test:0.1`)
-3. `cd /DATA/docker/dockerfiles/meta-registry-test/ && docker-compose up -d`
-
-### Notes
-
-`./secrets/htpasswd.example` contains an example file generated by `htpasswd` for user `picauser` and password `picapassword`.

meta-registry-test/clair-whitelist.yml

-generalwhitelist:

meta-registry-test/docker-compose.yml

-version: "3.7"
-
-volumes:
-  registry-data:
-    name: "registry-data"
-
-networks:
-  docker_default:
-    external: true
-
-services:
-  registry:
-    container_name: registry
-    restart: always
-    image: registry.test.picasoft.net/meta-registry-test:0.1
-    environment:
-      REGISTRY_AUTH: htpasswd
-      REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
-      REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
-      REGISTRY_STORAGE_DELETE_ENABLED: "true"
-      REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /var/lib/registry
-    volumes:
-      - registry-data:/var/lib/registry
-      - ./secrets/htpasswd:/auth/htpasswd
-    labels:
-      - "traefik.frontend.rule=Host:registry.test.picasoft.net"
-      - "traefik.port=5000"
-      - "traefik.enable=true"
-    networks:
-      - docker_default

meta-registry-test/secrets/htpasswd.example

-picauser:$2y$05$axvpLiYg.ADRa2I8xAU/weLb7urnUIgoehsQuKut1/dlIhDOQ.iPy

nextcloud-docker/README.md

+**Ajouter le docker-compose et la documentation de mise à jour**

pica-ci-base/Dockerfile

-FROM docker:19.03.0
-RUN apk update && \
-  apk add build-base \
-  git \
-  iproute2 \
-  libffi-dev \
-  openssl-dev \
-  py-pip \
-  python2-dev \
-  sed \
-  wget \
-  && pip install docker-compose

pica-db-backup-rotation/README.md

@@ -4,7 +4,11 @@ Picasoft réalise régulièrement des backups de ses bases de données. Le servi
 
 Il est flexible et se configure via des fichiers JSON.
 
-La rotation est effectuée une fois par jour.
+## Mise à jour
+
+Effectuer les changements désirés dans le Dockerfile, effectuer les changements désirés dans la configuration, mettre à jour le fichier `CHANGELOG.md` et changer la version du service dans le `docker-compose.yml`.
+
+Il n'est pas nécessaire de modifier le numéro de version pour une simple mise à jour de configuration.
 
 ## Configuration
 

pica-db-backup-rotation/clair-whitelist.yml

-generalwhitelist:

pica-db-backup/README.md

@@ -6,6 +6,12 @@ Il est capable de gérer les bases de données `postgres`, `mysql` ou `mongo` po
 
 Il est flexible et se configure via un fichier JSON.
 
+## Mise à jour
+
+Effectuer les changements désirés dans le Dockerfile, effectuer les changements désirés dans la configuration, mettre à jour le fichier `CHANGELOG.md` et changer la version du service dans le `docker-compose.yml`.
+
+Il n'est pas nécessaire de modifier le numéro de version pour une simple mise à jour de configuration.
+
 ## Configuration
 
 Le fichier dans [`config/backup_config.json`](./config/backup_config.json) recensent les informations sur les différentes bases de données qui doivent être backupées.

pica-db-backup/clair-whitelist.yml

-generalwhitelist:

pica-dokuwiki/README.md

+À compléter (mise à jour...)

pica-dokuwiki/clair-whitelist.yml

-generalwhitelist:
-    CVE-2019-9169: glibc -> Pas de contre-mesure
-    CVE-2017-12424: shadow -> Pas de contre-mesure
-    CVE-2019-18224: libidn2 -> Pas de contre-mesure dans Debian Buster, attendre une mise à jour
-    CVE-2019-11068: libxslt -> dépendance de PHP, pas de contre-mesure

pica-etherpad-db/README.md

+**Doit être fusionné avec le dossier `pica-etherpad` (deux Dockerfiles, un Docker Compose)**.
+
 This image limits the [mysql binary log](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) to 30 hours (=108000 seconds) via the [binlog_expire_logs_seconds](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_expire_logs_seconds) variable.