diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
deleted file mode 100644
index eea81f7a16ac70c6441f191906bb573eab37277c..0000000000000000000000000000000000000000
--- a/.gitlab-ci.yml
+++ /dev/null
@@ -1,163 +0,0 @@
-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
diff --git a/README.md b/README.md
index 17644781f4fc878c534fe35e2e3e9a5408818cc3..cb63e56b7b96cf465f726a3ced0605464e67808e 100644
--- a/README.md
+++ b/README.md
@@ -1,66 +1,58 @@
# Dockerfiles de Picasoft
+**Lisez cette documentation avant toute chose : elle fait office de référence générale et contient des informations supplémentaires par rapport aux README des dossiers :D**
+
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.
## Philosophie
Historiquement, Picasoft procède de la manière suivante :
-* Construire ses Dockerfile à la main et les pousser sur un registre privé.
-* Gérer un Docker Compose global par VM, qui contient la configuration et les secrets.
+* Construire les images Docker à partir de Dockerfiles sur une machine quelconque, puis les pousser manuellement sur un registre privé.
+* Gérer un fichier Compose global par machine, 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 ?
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.
+Son dernier objectif est de permettre de rendre publics nos fichiers Compose et la configuration, sans exposer les secrets (mots de passe, etc).
-## Contenu du dépôt
+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 quelconque, ce qui s'inscrit dans la philosophie Docker.
-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.
+## Contenu du dépôt
-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 des 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 fichier d'exemple de secrets (mots de passe...) nécessaires 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.
-
-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.
-
-### Je veux lancer un service existant sur une machine virtuelle
-
-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).
+Chaque service a son propre fichier Compose, lui permettant d'être déployé indépendamment des autres.
-### Je veux mettre à jour un service
+Des exemples concrets peuvent être trouvés au niveau de [pica-mattermost](./pica-mattermost) ou [pica-etherpad](./pica-etherpad).
-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).
+## Guides
-### Je veux mettre en place un nouveau service
+### Lancer ou redémarrer un service sur une machine de Picasoft
-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).
+Lire [la documentation de déploiement et de maintenance](./doc/launch_service.md).
-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**).
+### Mettre à jour un service ou sa configuration
-Un dossier [template](./template) prêt à copier est aussi disponible.
+Lire [la documentation de mise à jour des services](./doc/update_and_test.md).
-### Je veux améliorer la chaîne d'intégration
+### Mettre en place un nouveau service
-Lisez la [documentation "développeur" pour la chaîne d'intégration](./doc/guide_developpeur_ci.md), qui rentre plus dans le détail.
+Lire [la documentation de versionnage d'un nouveau service](./new_service.md) et [les bonnes pratiques pour Docker](./doc/guide_bonnes_pratiques.md).
diff --git a/pica-mail-copy-certs/Dockerfile b/deprecated/pica-mail-copy-certs/Dockerfile
similarity index 100%
rename from pica-mail-copy-certs/Dockerfile
rename to deprecated/pica-mail-copy-certs/Dockerfile
diff --git a/pica-mail-copy-certs/README.md b/deprecated/pica-mail-copy-certs/README.md
similarity index 88%
rename from pica-mail-copy-certs/README.md
rename to deprecated/pica-mail-copy-certs/README.md
index 746b9a8852a1c0d1b169418cedea7810e8aff155..62a073127b8d548a53b6fbd0cb94e1c2d1527054 100644
--- a/pica-mail-copy-certs/README.md
+++ b/deprecated/pica-mail-copy-certs/README.md
@@ -1,8 +1,10 @@
+**Doit être remplacé par `pica-tls-certs-monitor`.**
+
# Mise à jour des certificats du serveur mail
Le script `update-certs-pica-mail.sh` contient les instructions nécessaires pour extraire les certificats générés par Traefik pour le domaine `mail.picasoft.net` et créer les fichiers nécessaires (certificat, clé privée) pour le serveur mail.
-Exécutées hors de l'image Docker, rajoutez `export DOMAIN=mail.picasoft.net` avant les instructions.
+Exécutées hors de l'image Docker, rajoutez `export DOMAIN=mail.picasoft.net` avant les instructions.
Le souci est que Traefik gère les requêtes HTTP(S), mais pas TLS en général. Pour les autres services TCP, Traefik peut générer les certificats mais ne les servira pas, il faut les extraire et copier manuellement.
diff --git a/pica-mail-copy-certs/update-certs-pica-mail.sh b/deprecated/pica-mail-copy-certs/update-certs-pica-mail.sh
similarity index 100%
rename from pica-mail-copy-certs/update-certs-pica-mail.sh
rename to deprecated/pica-mail-copy-certs/update-certs-pica-mail.sh
diff --git a/doc/guide_bonnes_pratiques.md b/doc/guide_bonnes_pratiques.md
index f03a8036b974e7e8b64e95f96ed3101cd8f383be..a2dc03edfe86eb985c50a2f2c5ad49fda7552716 100644
--- a/doc/guide_bonnes_pratiques.md
+++ b/doc/guide_bonnes_pratiques.md
@@ -18,13 +18,7 @@ Il y a plusieurs cas.
### Je veux faire tourner un service existant, tel quel
-Si un service existant a une image Docker officielle, référencée sur le Docker Hub, alors on créera un Dockerfile *dummy*, ne contenant qu'une instruction `FROM`. Exemple :
-
-```Dockerfile
-FROM grafana:4.8
-```
-
-Le reste est identique : on crée notre `docker-compose.yml`, notre `README.md`, notre `clair-whitelist.yml`, et les fichiers de secrets d'exemple.
+Si un service existant a une image Docker officielle, référencée sur le Docker Hub, et qu'elle nous suffit, on s'en servira tel quel dans le `docker-compose.yml`.
### Je veux customiser un service existant
diff --git a/doc/guide_deploiement.md b/doc/guide_deploiement.md
deleted file mode 100644
index 23889a44ef34274d9a080dae6c76d8178622f771..0000000000000000000000000000000000000000
--- a/doc/guide_deploiement.md
+++ /dev/null
@@ -1,135 +0,0 @@
-# Déployer un service
-
-Dès lors que la chaîne d'intégration a construit une image Docker, il est possible de tester et de déployer le service concerné.
-
-## Test du service
-
-Avant de mettre un service en production, il faut vérifier que le service se lance bien comme prévu. Pour ce faire, on se rend sur une machine virtuelle de test (exemple : `pica01-test.picasoft.net`) et on se rend dans `/DATA/docker/dockerfiles`.
-
-Il faut être connecté au registre de test pour la suite : on s'assure de bien avoir exécuté la commande `docker login registry.test.picasoft.net`. Les identifiants sont sur le [pass](https://gitlab.utc.fr/picasoft/interne/pass).
-
-Pour que le service réponde à nos critères, il faut s'assurer qu'il démarre **indépendamment** de ce qui existe sur la machine. Le script [`docker_test.sh`](./docker_test.sh) s'occupe de tout cela pour vous, tout en s'assurant que les URL soient adaptés à la machine de test, par exemple.
-Il suffit de lancer la commande `$ ./docker_test.sh <nom du dossier, e.g. pica-mattermost>`.
-
-Vérifiez que les logs ne produisent aucune erreur et que le service fonctionne bien sur l'infrastructure de test.
-
-En cas d'erreur, vous pouvez lancer des commandes manuellement, relancer le service, changer les fichiers de configurations, etc, pour diagnostiquer.
-
-Lorsque le test a fonctionné, on se rend sur la page [Pipelines](https://gitlab.utc.fr/picasoft/projets/dockerfiles/pipelines) on choisit la pipeline correspondant au commit de modification que l'on a testé, et on lance le push de l'image sur le registre de production (`push-prod`).
-
-## Déploiement en production
-
-On se rend sur la machine de production, dans le dossier `/DATA/docker/dockerfiles`.
-
-Si on déploie un service pour la première fois, il faudra copier les fichiers `*.secrets.example` en `*.secrets`, et remplacer les valeurs d'example par des valeurs **secrètes**.
-
-Il faut être connecté au registre de production pour la suite : on s'assure de bien avoir exécuté la commande `docker login registry.picasoft.net`. Les identifiants sont sur le [pass](https://gitlab.utc.fr/picasoft/interne/pass).
-
-Si des volumes sont déclarés `external` (ce que nous ne [recommendons pas](./guide_bonnes_pratiques.md)), il faut les créer manuellement au prélable.
-
-**Certains services présentes des cas particuliers : regardez bien leur README avant de lancer les commandes qui suivent.**
-On peut ensuite se rendre dans le dossier et lancer, en général :
-
-```bash
-# Tirer la nouvelle version des images
-docker-compose pull
-# (Re)création des volumes, des réseaux, des conteneurs
-docker-compose up -d
-# Lecture des logs
-docker-compose logs -f
-```
-
-Attention : un conteneur noté `Unhealthy` à cause d'un mauvais `HEALTHCHECK` sera **exclu** de Traefik, même s'il fonctionne bien!
-
-## Exemple de test et de déploiement complet
-
-Je me rends sur `pica01-test` et je teste la nouvelle version de l'image :
-
-```bash
-$ ssh qduchemi@pica01-test.picasoft.net
-qduchemi@pica01-test:~$ cd /DATA/docker/dockerfiles
-qduchemi@pica01-test:/DATA/docker/dockerfiles$ ./docker_test.sh pica-mattermost
-Starting procedure for pica-mattermost/...
-
-==== Create dumb secret files ====
- File pica-mattermost//secrets/mattermost-db.secrets created
-
-==== Stop and remove existing containers ====
-Network docker_default is external, skipping
-
-==== RESET HARD and pull Dockerfiles repository ====
-Using branch master, is this correct ? [y/N]
-y
-HEAD is now at 472e0d7 [Mattermost] Bump to version 5.19.0
-Username for 'https://gitlab.utc.fr': qduchemi
-Password for 'https://qduchemi@gitlab.utc.fr':
-Already up-to-date.
-
-==== Replace production URL with testing URL in all files ====
- Found in ./entrypoint.sh
- Found in ./docker-compose.yml
-
-==== Remove and re-create named external volumes ====
-mattermost-config
-mattermost-config
-mattermost-data
-mattermost-data
-mattermost-plugins
-mattermost-plugins
-mattermost-db
-mattermost-db
-
-==== Remove old images ====
-Error: No such image: registry.test.picasoft.net/pica-mattermost:5.19.0
-Error: No such image: postgres:9.4-alpine
-
-==== Pull new versions of images ====
-Pulling mattermost-db ... done
-Pulling mattermost ... done
-
-==== Lauch pica-mattermost ====
-Creating mattermost-db ... done
-Creating mattermost-app ... done
-
-==== Print logs (use Ctrl+C to stop) ====
-Attaching to mattermost-app, mattermost-db
-[...]
-```
-
-Je vérifie que les logs sont ok, je se rend sur [team.test.picasoft.net](https://team.test.picasoft.net) et je constate que tout fonctionne.
-
-Je me rends de nouveau sur le [pipeline](https://gitlab.utc.fr/picasoft/projets/dockerfiles/pipelines/54707) et je lance manuellement l'étape `push-prod` pour pousser l'image sur le registre de production.
-
-Je me rends ensuite sur la machine de production (`pica02` Ã ce jour) et je lance la nouvelle version du service :
-```bash
-$ ssh qduchemi@pica02.picasoft.net
-qduchemi@pica02:~$ cd /DATA/docker/dockerfiles/pica-etherpad
-qduchemi@pica02:/DATA/docker/dockerfiles$ docker-compose pull
-Pulling mattermost-db ... done
-Pulling mattermost ... done
-qduchemi@pica02:/DATA/docker/dockerfiles$ docker-compose up -d
-Recreating mattermost-db ... done
-Recreating mattermost-app ... done
-qduchemi@pica02:/DATA/docker/dockerfiles$ docker-compose logs -f
-Attaching to mattermost-app, mattermost-db
-[...]
-```
-
-J'attends que l'application ait démarré, je vérifie que tout est ok sur [team.picasoft.net](https://team.picasoft.net).
-
-La mise à jour est terminée ! :)
-
-## Troubleshooting
-
-Cette section répertorie les problèmes anecdotiques indépendants des modifications des fichiers.
-
-### Erreurs de connexion à la base de données
-
-Si le conteneur `*-app` n'arrive pas à se connecter à la BDD du conteneur `*-db`, il est possible que `*-db` soit en train de tourner avec des anciens identifiants. Pour corriger ce problème **sur la VM de test**, il faudra:
-
-* effacer les conteneurs `*-app` et `*-db`
-* effacer leurs volumes
-* créer à nouveau leurs volumes
-* relancer le script `./docker_test.sh`.
-
-**Note:** Le script s'occupe déjà d'effacer et créer à nouveau les volumes, mais ça ne fonctionne pas dans le cas de `pica-etherpad`, probablement dû à un bug de `docker-compose config --volumes` qui retourne `etherpad-db-volume` et non `etherpad-db`.
diff --git a/doc/guide_developpeur_ci.md b/doc/guide_developpeur_ci.md
deleted file mode 100644
index 2e4102a4166bbfc52ff148760b80d4b56e7743d3..0000000000000000000000000000000000000000
--- a/doc/guide_developpeur_ci.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# Explications et améliorations de la CI
-
-Cette section répertorie des détails un peu plus poussés sur le fonctionnement de la chaîne d'intégration, qui viendraient parasiter le guide de fonctionnement normal.
-
-Tout est configuré dans le fichier [.gitlab-ci.yml](../.gitlab-ci.yml). Sa lecture est sans doute un peu cryptique pour certaines parties, on pourra consulter la documentation de Gitlab pour l'explication des différentes directives.
-
-## Formalisme du dépôt
-
-Pour que la CI fonctionne correctement, il faut respecter plusieurs contraintes. Il ne s'agit pas de bonnes pratiques, mais de conventions (discutables).
-
-On peut utiliser le [template fourni](../template) pour partir sur une bonne base.
-
-* Chaque service géré par la chaîne d'intégration a son dossier `pica-*` ou `meta-*`,
-* Chaque dossier contient au moins un `Dockerfile`, un `docker-compose.yml` et un `clair-whitelist.yml`,
-* Le nom final de l'image est spécifiée dans le `docker-compose.yml`, au format `registry.picasoft.net/nom:version`, et le nom doit correspondre au dossier,
-* Les secrets sont répertoriés dans des fichiers `*.secrets.example` dans un sous-dossier `secrets`, avec des valeurs d'exemple,
-* Les fichiers de secrets sont injectés dans le conteneur via la directive `env_file`, sans l'extension `.example`.
-
-Sur la machine où est clonée le dépôt :
-* Le dossier `secrets` doit avoir comme permissions `770` et les fichiers à l'intérieur de ce dossier `660`. Tous les dossiers et fichiers de ce dépôt doivent avoir pour groupe `docker` (gid: `999`),
-
-## Des analyses de sécurité ?
-
-Les analyses de sécurité permettent d'auditer les images Docker que nous construisons, afin de prévenir un maximum de failles de sécurité sur nos services. En effet, bien que les conteneurs Docker soient en théorie isolés du système lui-même, ils contiennent des données critiques. Il faut donc s'assurer que l'image est suffisamment propre avant de la lancer, d'autant qu'on se base parfois sur des images pré-construites.
-
-Les analyses sont de deux types : statique ou dynamique.
-
-L'analyse statique est effectuée par [Clair Scanner](https://github.com/arminc/clair-scanner) : son objectif est d'analyser l'intégralité des paquets installés dans une image Docker et de reporter les vulnérabilités présentes sur ces paquets ([CVE, ou Common Vulnerabilities and Exposures](https://cve.mitre.org/)). Cette analyse ne dit rien sur la sécurité du **service** en lui-même, mais plutôt sur la sécurité des bibliothèques dont il dépend.
-
-Cette analyse n'échoue que lorsque des CVE de niveau `High` ou plus sont détectées. Le fichier `clair-whitelist.yml` sert justement à autoriser certaines CVE de niveau `High` à contourner cette restriction, après une analyse qui aurait déterminé qu'elle n'affecte pas la sécurité de notre service.
-
-L'analyse dynamique est effectuée par [Docker Bench for Security](https://github.com/docker/docker-bench-security), qui lance le service en interne et vérifie que le ou les conteneurs lancés respectent une liste de bonnes pratiques. Docker Bench for Security ne fait jamais échouer la CI, même lorsque les bonnes pratiques ne sont pas respectées, car ce n'est pas toujours possible. Il faut néanmoins tendre vers le respect de ces bonnes pratiques. En pratique, nous utilisons très peu cette étape et sa pertinence devra être discutée.
-
-## Étapes manuelles ou automatiques ?
-
-Le push sur le registre de production est **toujours** manuel, car il faut s'assurer au préalable que le service a été testé par un humain avant de le pousser.
-
-La mise à jour d'un `Dockerfile` entraîne le lancement de l'ensemble de la CI.
-
-La mise à jour d'une liste blanche de CVE (voir [Formalisme du dépôt](#formalisme-du-dpt)) déclenche uniquement l'analyse de sécurité statique sur la dernière image construite (pas de nécessité de reconstruire l'image).
-
-La mise à jour d'un `docker-compose.yml` déclenchait l'analyse de sécurité dynamique sur la dernière image construite (pas de nécessité de reconstruire l'image) : à présent, elle n'est déclenchée que manuellement.
-
-La mise à jour d'un fichier autre donne la possibilité de déclencher manuellement les étapes de la CI : on appréciera au cas par cas s'il est nécessaire de reconstruire l'image. Par exemple, mettre à jour le `README` ou un fichier de secrets d'exemple ne devrait pas déclencher la CI, tandis que mettre à jour un fichier de configuration devrait déclencher la CI.
-
-## Meta-images
-
-On prévoit à terme d'utiliser ce dépôt pour construire aussi les images qu'il utilise lui même. Pour l'instant, c'est en test avec `meta-registry-test` pour construire l'image utilisée par le registry docker sur `pica01-test`.
diff --git a/doc/guide_utilisateur_ci.md b/doc/guide_utilisateur_ci.md
deleted file mode 100644
index ff22784cd4b2773e3c695b1b9d3d8120ae133d37..0000000000000000000000000000000000000000
--- a/doc/guide_utilisateur_ci.md
+++ /dev/null
@@ -1,85 +0,0 @@
-# Utilisation de la chaîne d'intégration
-
-## Introduction
-
-Ce dépôt utilise la [chaîne d'intégration de Gitlab](https://docs.gitlab.com/ee/ci/), ou **CI**, pour automatiser certaines tâches dès lors que des changements ont lieu sur le dépôt. L'idée est en particulier d'automatiser la construction des images Docker et les analyses de sécurité, ce qui permet d'améliorer la sécurité de l'infrastructure, d'unifier les procédures, de garder un historique clair des modifications et de synchroniser l'état des services sur les machines avec l'état de ce dépôt.
-
-La CI est déclenchée dès lors qu'une modification est susceptible d'altérer un service est détectée.
-
-Elle va effectuer les opérations suivantes, partiellement ou complètement selon le contexte :
-* Construction de l'image Docker et push vers le registre de test,
-* Analyses de sécurité,
-* Push vers le registre de production.
-
-Chaque étape peut échouer et bloquer les étapes ultérieures. Il faudra régler les problèmes et mettre à jour le dépôt afin de relancer la CI le cas échéant.
-
-## Mettre à jour un service
-
-On peut vouloir mettre à jour :
-* Le service (*e.g.* changer un numéro de version dans le Dockerfile),
-* La configuration (éditer un fichier quelconque),
-* La configuration des volumes (*e.g.* changer le point de montage du Docker Compose),
-* etc.
-
-En principe, il suffit de récupérer ce dépôt, de faire les mises à jour souhaitées, de commit les changements et de les pousser pour que l'image soit construite si besoin. Le cas échéant, pour des services "maisons", il est de bon ton de mettre à jour un fichier `CHANGELOG.md` pour résumer les modifications.
-
-Si le code du service à mettre à jour est intégré au dépôt par un submodule, on lancera la commande suivante pour le mettre à jour à la dernière version. Voir la documentation des submodules pour utiliser un tag ou une branche spécifique.
-```
-git submodule update --recursive --remote <dossier du service>
-```
-
-Si vous mettez à jour un fichier de configuration qui nécessite de reconstruire l'image, il faudra lancer la CI manuellement depuis la page [Pipelines](https://gitlab.utc.fr/picasoft/projets/dockerfiles/pipelines). Si vous mettez à jour un fichier de configuration qui est monté dans le conteneur via Docker Compose, aucune action de la CI n'est nécessaire, **même pas l'action `push-prod`**.
-
-Notez que le **nom final** de l'image construite est celui que vous indiquez dans le `docker-compose.yml`. Si vous mettez à jour un service en lui-même (option 1 de la liste ci-dessus), il faut impérativement modifier la version de l'image construite dans ce fichier dans le `docker-compose.yml`.
-
-**Attention, la CI se déclenche en regardant les modifications apportées lors du dernier commit. Si vous modifiez le `Dockerfile` dans un commit, puis le `README` dans un autre, et que vous poussez le tout, la construction ne se déclenchera pas automatiquement.**
-
-Vous pouvez suivre les différentes étapes de la CI sur la page [Pipelines](https://gitlab.utc.fr/picasoft/projets/dockerfiles/pipelines), et il est **recommandé** de lire les logs des différentes étapes en cliquant sur chacune d'entre elles. Si la construction et les analyses de sécurité se passent bien, tous les voyants sont au vert (sauf la dernière étape, qui doit être déclenchée manuellement). Sinon, référez-vous à la section [Troubleshooting](#troubleshooting). Si l'analyse de sécurité n'est pas déclenchée, c'est qu'elle n'a pas besoin de l'être.
-
-Enfin, il est de bon ton de vérifier que les CVE whitelistées dans le fichier `clair-whitelist.yml` sont toujours détectées dans le scan de Clair (étape `clair`). Si non, on pourra les enlever de la liste.
-Notez aussi que souvent, les nouvelles CVE sont classées `High`, puis rétrogradée en `Medium`, voire `Negligeable`, parce qu'on s'est rendu compte que l'impact est moins grand qu'on le croyait. Dans ce cas, il convient d'enlever les CVE retrogradées de la liste blanche.
-
-On peut ensuite [déployer le service](guide_deploiement.md).
-
-## Exemple de mise à jour
-
-On veut mettre à jour Mattermost de la version 5.18.0 à la version 5.19.0. On fait les modifications dans le Dockerfile et on pousse le commit. Les modifications dépendent évidemment du service, on peut voir le commit [472e0d72](https://gitlab.utc.fr/picasoft/projets/dockerfiles/commit/472e0d72534659e215270adade6746b65b6f65e3) pour l'exemple.
-
-Le [pipeline](https://gitlab.utc.fr/picasoft/projets/dockerfiles/pipelines/54707) se lance automatiquement. Je suis les logs des jobs un par un pour vérifier que tout se passe bien.
-
-La construction de l'image et les analyses de vulnérabilité se passent bien : aucun paquet n'introduit de nouvelle vulnérabilité.
-
-Je [déploie la nouvelle version du service](./guide_deploiement.md).
-
-Si tout se passe bien, je me rends de nouveau sur le [pipeline](https://gitlab.utc.fr/picasoft/projets/dockerfiles/pipelines/54707) et je lance manuellement l'étape `push-prod` pour pousser l'image sur le registre de production.
-
-## Astuces
-
-Il est possible de relancer une pipeline plus ancienne, pour reconstruire une ancienne version de l'image, quand cela est nécessaire, et revenir exactement dans l'état du commit concerné.
-
-## Troubleshooting
-
-Des erreurs peuvent survenir à plusieurs étapes de la CI.
-Les logs de chaque étape donnent des informations sur la nature de l'erreur.
-
-### Impossibilité de pull une image
-
-Parfois, un timeout empêche de pull l'image depuis le registre de test entre deux étapes, avec des messages de timeout ou de type `Unknown blob`. Il faudra dans ce cas redémarrer le registre de test (sur `pica01-test`, probablement) et relancer la chaîne d'intégration.
-
-### Lors de la construction de l'image
-
-Si l'erreur ne vient pas d'un Dockerfile mal écrit, elle peut venir d'un nom d'image mal formaté dans le Docker Compose (voir [Formalisme du dépôt](./guide_developpeur_ci#formalisme-du-dpt)).
-
-### Lors de l'analyse de sécurité statique
-
-Cette analyse échoue lorsque des CVE avec une criticité `High` ou plus sont détectées. Les CVE de niveau plus faible étant inévitables, la CI n'échoue pas et se contente de les afficher.
-
-Clair vous indique quels paquets sont vulnérables. Plusieurs choix s'offrent à vous : mitiger la CVE (choix à privilégier) ou mettre la CVE en liste blanche.
-
-On regardera à ce titre le [Mini guide pour mitiger une CVE !](mini_guide_cve.md)
-
-Ensuite, on pousse les modifications et la CI ré-effectuera les tests de vulnérabilités, en reconstruisant l'image si nécessaire.
-
-### Lors de l'analyse de sécurité dynamique
-
-Il est fort probable que l'erreur provienne d'un mauvais Docker Compose, et que Docker Bench for Security n'arrive pas à lancer votre ou vos conteneur(s), par exemple à cause d'un fichier manquant ou d'un mauvais formattage.
diff --git a/doc/images/clair_log_1.png b/doc/images/clair_log_1.png
deleted file mode 100644
index 122ba761aeff7f593dfd1abe230817eea2170801..0000000000000000000000000000000000000000
Binary files a/doc/images/clair_log_1.png and /dev/null differ
diff --git a/doc/images/clair_log_2.png b/doc/images/clair_log_2.png
deleted file mode 100644
index 9cd2ca831173472dbcdb8771ddc18b65a7e6b0df..0000000000000000000000000000000000000000
Binary files a/doc/images/clair_log_2.png and /dev/null differ
diff --git a/doc/launch_service.md b/doc/launch_service.md
new file mode 100644
index 0000000000000000000000000000000000000000..8bca9b78fbc1d889a20ddeec129e48fb3b8f594a
--- /dev/null
+++ b/doc/launch_service.md
@@ -0,0 +1,89 @@
+## Administration des services
+
+Chaque service versionné sur ce dépôt est lancé sur une des machines virtuelles de Picasoft.
+
+En particulier, les fichier `docker-compose.yml` présents dans chaque dossier, ainsi que les fichiers de configuration et de secrets, permettent de lancer n'importe quel service de façon autonome, sur n'importe quel machine.
+
+Pour chacune des opérations détaillées dans cette page, on suppose que :
+* Vous savez sur quel machine tourne ou doit tourner le service (`pica01`, `monitoring`...)
+* Vous avez une connexion SSH active sur cette machine
+* Vous êtes dans le dossier `<clone_depot>/<service>`, sur la branche `master`. Le clone devrait se trouver dans `/DATA/docker/dockerfiles`.
+* Vous êtes connecté au registre de production : on s'assure de bien avoir exécuté la commande `docker login registry.picasoft.net`. Les identifiants sont sur le [pass](https://gitlab.utc.fr/picasoft/interne/pass).
+
+La branche `master` devant refléter l'état des services en production, toutes les opérations sur les machines de production devront être réalisées depuis `master` : cela signifie que les branches sur lesquelles vous travaillez devront être fusionnées à la fin de vos tests, et donc avant la mise en production.
+
+### Opérations usuelles
+
+Consulter les logs d'un service à la recherche d'une erreur :
+
+```bash
+# n est le nombre de lignes à afficher, optionnel
+docker-compose logs -f [--tail <n>]
+```
+
+Redémarrer un service, par exemple si celui-ci a planté :
+
+```bash
+# Le nom du service est optionnel : si on veut tout
+# redémarrer, on ne le met pas. Sinon, on indique
+# le nom du service présent dans le fichier
+# docker-compose.yml.
+docker-compose restart [service]
+```
+
+Re-créer le conteneur si nécessaire, par exemple suite à une mise à jour de l'image ou de la configuration :
+
+```bash
+docker-compose pull
+# Le nom du service est optionnel : si on veut tout
+# redémarrer, on ne le met pas. Sinon, on indique
+# le nom du service présent dans le fichier
+# docker-compose.yml.
+docker-compose up -d [service]
+```
+
+Le `docker-compose pull` est **essentiel** : il permet de récupérer les nouvelles versions des images et de s'assurer qu'on a bien la dernière version indiquée dans le Compose.
+
+Éteindre un service :
+```bash
+docker-compose stop
+```
+
+etc.
+
+Attention : un conteneur noté `Unhealthy` à cause d'un mauvais `HEALTHCHECK` sera **exclu** de Traefik, même s'il fonctionne bien!
+
+### Lancement d'un nouveau service
+
+Lorsque vous lancez un nouveau service, il y a parfois quelques opérations à faire avant de lancer les conteneurs.
+En effet, bien qu'en théorie un `docker-compose up -d` suffise, il y a quelques cas particulier.
+
+#### Secrets
+
+Les secrets, tels que les mots de passe, ne sont évidemment pas présents sur ce dépôt. Lorsque des secrets sont utilisés, ils sont **systématiquement** indiqués par la présence de fichiers dans un sous-répertoire `secrets`.
+
+Dans ce cas, on copiera tous les fichiers `.secrets.example` en `.secrets`, et on remplacera les valeurs.
+
+Cette opération n'est nécessaire que lors du premier lancement.
+Il y a plusieurs situations.
+
+1. Le mot de passe est "inédit", et ne concerne pas les utilisateurs (comme le mot de passe d'un utilisateur de base de données). On pourra générer un mot de passe avec la commande suivante :
+
+```bash
+< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c${1:-32};echo;
+```
+
+2. Le mot de passe est connu, par exemple le mot de passe d'un compte LDAP. On le récupérera sur le [pass](https://gitlab.utc.fr/picasoft/interne/pass).
+3. Le mot de passe est "inédit", mais doit être accessibles aux administrateurs (par exemple le mot de passe d'administration d'Etherpad). On le créera directement dans le [pass](https://gitlab.utc.fr/picasoft/interne/pass) (`picapass insert...`) et on le copiera dans le fichier de secrets.
+
+#### Création des volumes
+
+Si des volumes sont déclarés `external` dans le fichier Compose (ce que nous ne [recommendons pas](./guide_bonnes_pratiques.md)), il faut les créer manuellement au prélable :
+
+```bash
+docker volume create <volume>
+```
+
+#### Opérations manuelles
+
+Certains services (comme [le serveur mail](../pica-mail)) nécessitent des opérations manuelles : créer des dossiers, puis générer des clés ou des certificats... Il faudra être attentif à le faire avant tout lancement.
diff --git a/doc/mini_guide_cve.md b/doc/mini_guide_cve.md
deleted file mode 100644
index ed1fcd1e98560773495f6dec18c6c77ea96eec90..0000000000000000000000000000000000000000
--- a/doc/mini_guide_cve.md
+++ /dev/null
@@ -1,81 +0,0 @@
-# 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))
-
-
-
-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).
-
-
-
-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.
diff --git a/doc/new_service.md b/doc/new_service.md
new file mode 100644
index 0000000000000000000000000000000000000000..d66d5d47a4e2a63b4e1a182cba733f7a6c4c0c3e
--- /dev/null
+++ b/doc/new_service.md
@@ -0,0 +1,61 @@
+# Versionnage d'un nouveau service
+
+L'idée de ce dépôt est de rendre nos services **indépendants** des machines virtuelles sur lesquels ils sont lancés, c'est-à -dire qu'à partir de ce dépôt, on devrait pouvoir remonter sans aucun problème un service sur une machine quelconque (sauf les données, bien sûr).
+
+Cette page donne quelques pistes pour versionner un nouveau service sur ce dépôt.
+
+On pourra partir du dossier [template](../template) comme base.
+
+Pour le contenu des fichiers `Dockerfile` et `docker-compose.yml`, on se réferera au [guide des bonnes pratiques](./guide_bonnes_pratiques.md) en cas de doute.
+
+## Choix des fichiers à versionner
+
+Pour savoir si vous avez versionné tout les fichiers nécessaires, posez-vous la question suivante :
+
+> Si je fais un `git pull` puis un `docker-compose up -d`, est-ce-que mon service démarre correctement ?
+
+Si oui, vous avez versionné les fichiers nécessaires. Si non, il faut remédier au problème. La seule exception concerne les opérations nécessaires pour créer les secrets (voir plus bas).
+
+### Fichiers nécessaires
+
+Pour chaque service, on aura au moins :
+* Un `README.md`, qui explique de quoi il s'agit, comment lancer le service, comment le mettre à jour, etc. On pourra s'inspirer des services existants et du template.
+* Un `docker-compose.yml`, qui permet de lancer le service sur les machines de Picasoft. Les images utilisées doivent toujours avoir un tag de version précis (voir bonnes pratiques).
+
+### Image personnalisée
+
+Si on utilise une image construite par nos soins, il faut rajouter :
+* Un ou plusieurs `Dockerfile`, qui permet(tent) de construire l'image.
+* Un `CHANGELOG.md`, qui indique les modifications effectuées au fil des versions.
+
+Le Dockerfile peut contenir des directives `COPY` pour ajouter des fichiers à l'image. S'il s'agit d'un ou deux fichiers de configuration, ou d'un entrypoint, aucun souci pour le versionner sur ce dépôt. S'il s'agit de code à proprement parler, il est préférable de créer un dépôt spécifique qui contiendra le code du service, et de faire un `git pull` dans le `Dockerfile` (ou d'utiliser un sous-module Git).
+
+En effet, ce dépôt n'est pas voué à contenir le code des services, mais simplement les fichiers nécessaires pour construire l'image, configurer et lancer le service.
+
+### Fichiers de configuration
+
+Il est préférable de versionner la configuration du service sur ce dépôt, pour pouvoir relancer rapidement le service sur une machine quelconque sans devoir récupérer la configuration sur l'ancienne machine.
+
+Cependant, si la configuration est souvent modifiée via l'interface d'administration du service, il est préférable de ne pas la versionner. Par exemple, Mattermost utilise un fichier `config.json`, mais on le modifie essentiellement à travers la Console Administrateur (interface graphique). Versionner ce fichier obligerait à modifier la configuration "à la main", puis à redémarrer Mattermost à chaque changement de paramètre.
+
+Par contre, Etherpad utilise un fichier `config.json` qui n'est pas modifiable via une interface graphique, et qui est pris en compte uniquement au démarrage. C'est donc un bon fichier à versionner.
+
+La *rule of thumb* est donc la suivante : on versionnera **tous les fichiers qui ne sont pas modifiés dynamiquement quand le service est lancé**.
+
+### Cas particuliers
+
+Certaines images officielles demandent d'effectuer des opérations manuellement avant de les lancer (initialisation de base de données, etc).
+
+Dans ce cas, on pourra créer un `entrypoint` qui remplace l'officiel et qui effectue ces opérations si jamais le service est lancé pour la première fois, puis qui lance le service normalement. On pourra marquer le fait qu'un service a déjà été initialisé en créant un fichier "marqueur" dans un volume. Voir [Plume](../pica-plume) pour un exemple.
+
+De manière générale, on hésitera pas à faire un `entrypoint` personnalisé si celui de l'image officielle ne suffit pas à nos besoins et qu'on ne peut pas configurer le service comme on le veut grâce aux variables d'environnement.
+
+## Gestion des secrets
+
+Un service a souvent besoin de secrets pour démarrer. Par secrets, on entend souvent mot de passe, ou clé privée.
+
+En général, les secrets sont configurés via des variables d'environnement. Quand c'est le cas, on créera un dossier `secrets`, puis des fichiers en `.secrets.example` qui contiennent une variable d'environnement par ligne. Voir les services existants pour un exemple.
+
+Quand le service demande les secrets en clair dans un fichier de configuration, et qu'on ne peut pas faire référence aux variables d'environnement dans le fichier, on gardera le système des variables d'environnement et on remplacera l'`entrypoint` pour injecter les variables dans le fichier de configuration.
+
+On trouvera un exemple dans [pica-metrics-bot](../pica-metrics-bot), où l'on voit que le fichier de configuration contient des marqueurs (`INFLUXDB_USER` par exemple), qui sont remplacés au démarrage du service par les valeurs des variables d'environnement correspondantes.
diff --git a/doc/update_and_test.md b/doc/update_and_test.md
new file mode 100644
index 0000000000000000000000000000000000000000..09caf7459677fe21efae571fa6a2de277503d1ca
--- /dev/null
+++ b/doc/update_and_test.md
@@ -0,0 +1,180 @@
+# Mise à jour et test d'un service
+
+Cette page indique les différentes manières de mettre à jour un service et de le tester, avant sa mise en production.
+
+On peut vouloir mettre à jour :
+* Le service (*e.g.* changer un numéro de version dans le Dockerfile),
+* La configuration (éditer un fichier quelconque),
+* La configuration des volumes (*e.g.* changer le point de montage du Docker Compose),
+* etc.
+
+Dans tous les cas, les modifications apportées à n'importe quel fichier de ce dépôt **doivent être poussées sur ce dépôt**.
+Vous pouvez effectuer les modifications sur votre machine ou sur une machine de Picasoft, du moment qu'elles sont synchronisées avec le dépôt.
+
+## Comment mettre à jour un service ?
+
+Il est pertinent de créer une branche avant chaque mise à jour où vous n'êtes pas sûr des modifications, et ne de fusionner dans `master` que lorsque les tests ont été effectués.
+
+### Mise à jour de la configuration
+
+On appelle configuration tout ce qui ne nécessite pas de reconstruire une image :
+* Modification du `docker-compose.yml` (environnement, point de montage, tag d'une image officielle...)
+* Modification d'un fichier de configuration
+* Modification d'une page web d'accueil
+* etc.
+
+Il suffit de mettre à jour les fichiers souhaitées, éventuellement de signaler les changements à l'équipe ou en commentaire, puis de synchroniser avec le dépôt.
+
+Si vous mettez à jour le tag d'une image officielle (*e.g* `postgres:10` → `postgres:12`), lisez au préalable la documentation de mise à jour ! Certaines nécessitent des interventions manuelles, et le README du service le précise en général.
+
+Toute image indiquée dans le fichier Compose **doit avoir un tag** (*e.g* `postgres:12` et pas `postgres`). N'utilisez jamais un tag vide (équivalent à `latest`).
+
+### Mise à jour d'une image maison
+
+Apportez vos modifications au Dockerfile (ajout d'un paquet...). Vous pouvez travailler en local et tester l'image sur votre machine si vous voulez.
+
+Si le code du service à copier dans l'image est intégré au dépôt par un submodule, on lancera la commande suivante pour le mettre à jour à la dernière version. Voir la documentation des submodules pour utiliser un tag ou une branche spécifique.
+```
+git submodule update --recursive --remote <dossier du service>
+```
+
+Synchronisez ensuite le tout avec le dépôt (`git commit`, `git push...`).
+
+## Comment tester le service mis à jour ?
+
+Avant de mettre en production un service, il faut s'assurer que la mise à jour n'a rien cassé. Même si vous avez testé la nouvelle image sur votre machine, il faut également la tester sur l'infrastructure de Picasoft, en particulier parce que les services ont souvent besoin de Traefik pour fonctionner.
+
+Pour ce faire, rendez-vous sur `pica01-test`, dans le clone du dépôt (usuellement `/DATA/docker/dockerfiles`).
+
+Attention, notez que parfois il y a des problèmes indépendants du service quand celui-ci est accessible via Traefik :
+* Tant que le `HEALTHCHECK` n'est pas passé, Traefik ne route pas vers le service (on vérifiera que le conteneur est noté `healthy` dans la sortie de `docker ps`)
+* Parfois, Traefik ne route pas vers le service et renvoie un `Gateway Timeout`. Un `docker restart traefik` résoud le problème s'il vient de là .
+
+### Automatiquement
+
+Le script [docker_test.sh](../docker_test.sh) permet d'automatiser toutes les étapes pour tester un service et s'assurer qu'il fonctionne bien indépendamment des données précédentes, qui auraient été conservées dans un volume, par exemple. Il permet aussi de remplacer toutes les URL de production par des URL de test.
+
+Il a le désavantage qu'on comprend moins ce que l'on fait. Pour s'en servir, lancez :
+
+```bash
+$ ./docker_test.sh <nom du dossier, e.g. pica-mattermost>
+```
+
+Vérifiez que les logs ne produisent aucune erreur et que le service fonctionne bien sur l'infrastructure de test, en y accédant via son URL par exemple (attention : remplacer `picasoft.net` par `test.picasoft.net` dans votre navigateur).
+
+### Manuellement
+
+Si vous voulez tester le service "à la main", ou que le script ne fonctionne pas pour vous, ou pour toute autre raison, suivez ces étapes :
+
+#### Synchronisation
+
+Synchronisez vous **exactement** avec le dépôt :
+
+```bash
+# master ou votre branche perso
+git checkout <votre branche>
+git pull
+```
+
+#### Remise à zéro
+
+Si le service était déjà lancé sur la machine de test, éteignez-le et remettez les volumes à 0 :
+
+```bash
+docker-compose down -v
+```
+
+Si des volumes sont déclarés comme `external` dans le fichier Compose, supprimez-les manuellement :
+
+```bash
+docker volume rm <volume>
+```
+
+#### Construction des images
+
+Si le service utilise des images "maison", il faut les construire. Si le fichier Compose est bien fait, il suffit de lancer :
+
+```bash
+docker-compose build
+```
+
+Sinon, il faut construire les images à la main. À répéter pour chaque image maison du service concerné :
+
+```bash
+docker build [-f <Dockerfile>] -t <image> <context>
+```
+
+* Si le `Dockerfile` a un nom différent, on utilise le switch `-f`
+* `<image>` doit avoir rigoureusement la valeur de la directive `image` du fichier Compose
+* `<context>` est le contexte que reçoit Docker pour construire l'image (base pour copier les fichiers). En général, c'est le dossier du service (donc `.`, puisqu'on est dedans).
+
+#### Remplacement des URLs
+
+Si nécessaire. Certains services ne sont pas accessibles depuis Internet.
+
+Remplacez les URL de production (`.picasoft.net`) par des URL de tests (`.test.picasoft.net`), sauf dans le nom de l'image :
+
+* Si le service utilise Traefik, voir du côté de `traefik.frontend.rule` dans le fichier Compose
+* Si le service utilise des fichiers de configuration, remplacez les références aux URL...
+
+### Créer les fichiers d'example
+
+Copier tous les `.secrets.example` en `.secrets`.
+
+#### Récupérer les nouvelles images
+
+Si le service utilise des images officielles, on s'assure qu'elles sont bien à jour avec la commande :
+
+```bash
+docker-compose pull
+```
+
+#### Lancer le service
+
+```bash
+docker-compose up -d
+```
+
+#### Vérifier que tout fonctionne bien
+
+```bash
+docker-compose logs -f
+```
+
+On constate l'absence d'erreurs dans les logs, et si le service est accessible via Internet, on regarde que tout fonctionne bien depuis l'URL de test.
+
+### En cas de problème
+
+À partir de là , c'est carte blanche : on peut modifier la configuration, le Dockerfile, reconstruire les images, etc. L'infrastructure de test est un bac à sable.
+
+Si jamais les modifications ont permis de résoudre le problème, on les commit et on les synchronise avec le dépôt.
+
+### Revenir à l'état initial
+
+On se resynchronise avec l'état du dépôt en enlevant toutes les modifications induites par les tests.
+```bash
+git reset --hard
+```
+
+## Que faire après les tests ?
+
+Une fois qu'on est convaincu que la nouvelle version du service fonctionne bien, on peut le mettre en production.
+
+Au préalable, si le service utilise des images maison, on les pousse sur le registre de production. Pour ce faire, vous devez connecté au registre de production : on s'assure de bien avoir exécuté la commande `docker login registry.picasoft.net`. Les identifiants sont sur le [pass](https://gitlab.utc.fr/picasoft/interne/pass).
+
+```bash
+docker-compose push
+```
+
+Cette commande pratique indique à Docker Compose de pousser toutes les images du fichier.
+
+On peut aussi le faire manuellement, pour chaque image maison (*i.e.* dont le nom commence par `registry.picasoft.net`) :
+
+```bash
+# <image> doit correspondre exactement
+# Ã la directive image du fichier Compose
+# et commencer par registry.picasoft.net
+docker push <image>
+```
+
+Une fois les images poussées, on se rend sur la machine de production et on [lance le service](./launch_service.md).
diff --git a/docker-compose/mail.yml b/docker-compose/mail.yml
deleted file mode 100644
index 8be69a810dcba09b2a832c6abcc98ffb3ba60741..0000000000000000000000000000000000000000
--- a/docker-compose/mail.yml
+++ /dev/null
@@ -1,95 +0,0 @@
-version: "3"
-
-services:
- mail-mda:
- image: pica-mail-mda
- container_name: pica-mail-mda
- ports:
- - "143:143"
- - "993:993"
- networks:
- - mail
- hostname: pica-mail-mda
- volumes:
- - /var/lib/docker/volumes/mail-mda-maildir/_data:/home
- - /DATA/docker/mail/ssl/:/certs-ssl/:ro
- environment:
- LDAP_ADDRESS: ldap.picasoft.net
- LDAP_NSS_CN: cn=mail,ou=Services,dc=picasoft,dc=net
- LDAP_DNPASS:
- LDAP_BASE: dc=picasoft,dc=net
- USER_FILTER: (uid=%n)
- PASSWORD_FILTER: (uid=%n)
-
- mail-mta:
- image: pica-mail-mta
- container_name: pica-mail-mta
- ports:
- - "25:25"
- - "465:465"
- - "587:587"
- networks:
- - mail
- volumes:
- - /var/lib/docker/volumes/mail-mta-log/_data:/var/log
-#doit contenir selecteur.domaine.rsa
- - /DATA/docker/mail/opendkim/:/etc/dkimkeys/
- - /DATA/docker/mail/ssl/:/certs-ssl/
- environment:
-#adresse et port du serveur LMTP i.e. le MTA
- LMTP_LAN_HOSTNAME: pica-mail-mda.pica_mail
- LMTP_PORT: 24
-#nom d'hôte sous lequel Postfix répondra aux requêtes SMTP
- MY_HOSTNAME: mail.picasoft.net
-#domaine des mails
- MY_DOMAIN: picasoft.net
-#domaines mails qu'on s'autorise à relayer (qui ont le droit de passer à travers notre serveur si ils sont en expéditeur ou destinataire)
- RELAY_DOMAINS: picasoft.net
-#réglage de la connexion au serveur LDAP: protocole (ldap ou ldaps), hôte et port
- LDAP_PROTOCOL: ldap
- LDAP_SERVER_HOSTNAME: ldap.picasoft.net
- LDAP_PORT: 389
-#réglage du bind : login et mot de passe d'un compte qui a suffisamment de droits pour lire l'arborescence (à l'exception des mots de passe)
- LDAP_BIND_DN: cn=mail,ou=Services,dc=picasoft,dc=net
- LDAP_BIND_PW:
-#réglage de la manière dont on répertorie les comptes et les adresses existantes
-#la config actuelle fait que la possession d'une adresse mail se fait ainsi : login => login@picasoft.net
-#cependant, nous avons quand même deux couches différentes: l'existence d'un compte (SASL) et l'existence d'une adresse
-#ce qui fait qu'on peut créer une adresse valide sans nécessairement lui associer un compte valide
-#ainsi, on pourra recevoir des mails dans la boîte, mais on ne pourra pas se connecter en tant que cet utilisateur
-#pour ce faire, il suffit d'utiliser des attributs LDAP différents
-#nous utilisons donc le cn pour l'existence d'un compte LDAP, et l'uid pour l'existence d'une adresse
-#niveau de l'arborescence à partir duquel les entrées sont trouvées:
- LDAP_SEARCH_BASE: dc=picasoft,dc=net
-#filtre permettant de répertorier les comptes SASL
- LDAP_SASL_FILTER: "cn=%u"
-#filtre permettant de répertorier les adresses mail
- LDAP_VIRTUAL_MAILBOX_FILTER: "uid=%s"
-#ajout de listes noires pour éviter le SPAM. La décision politique et l'éthique associée sortent du cadre de la conception de cette image et doivent être discutées par l'asso; en tout cas, si on lève cette restriction, elle doit être remplacée par une autre (un spamassassin par exemple).
- SMTPD_CLIENT_RESTRICTIONS: reject_rbl_client sbl.spamhaus.org, reject_rbl_client dnsbl.sorbs.net
-#prefixe DKIM, utilise pour identifier la clef
- DKIM_SELECTOR: janv2019
- labels:
- - "traefik.frontend.rule=Host:mail.picasoft.net"
- - "traefik.port=80"
- - "traefik.enable=true"
- - "traefik.docker.network=pica_mail"
-
- mail-copy-certs:
- image: pica-mail-copy-certs
- container_name: pica-mail-copy-certs
- volumes:
-#contient acme.json
- - /DATA/docker/traefik/certs/:/DATA/docker/traefik/certs/
-#output
- - /DATA/docker/mail/ssl/:/DATA/docker/mail/ssl/
- environment:
- - DOMAIN=mail.picasoft.net
-
-
-
-
-networks:
- mail:
-
-#attention, docker-compose préfixe le nom du réseau créé par le nom du projet (contenu dans le .env, sinon c'est le nom du dossier)
diff --git a/docker_test.sh b/docker_test.sh
index 9836eb342dd1457401fc7f1e2238734029f6eb85..02d46c7b5b84afacfbaaf4e843c46073895bf5f0 100755
--- a/docker_test.sh
+++ b/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 ===="
diff --git a/image_modified_last_commit.sh b/image_modified_last_commit.sh
deleted file mode 100755
index 99a4ea6d2b8c0be5684a2782e9a5cf0c3a47bdc4..0000000000000000000000000000000000000000
--- a/image_modified_last_commit.sh
+++ /dev/null
@@ -1,36 +0,0 @@
-#!/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
diff --git a/meta-registry-test/Dockerfile b/meta-registry-test/Dockerfile
deleted file mode 100644
index 0e902f8c79f3b8358d6e489f8c7b60492ea0d9cb..0000000000000000000000000000000000000000
--- a/meta-registry-test/Dockerfile
+++ /dev/null
@@ -1 +0,0 @@
-FROM registry:2.7
diff --git a/meta-registry-test/README.md b/meta-registry-test/README.md
deleted file mode 100644
index c7e86f0293d0d244770cd4115c59065d6dd63ac5..0000000000000000000000000000000000000000
--- a/meta-registry-test/README.md
+++ /dev/null
@@ -1,30 +0,0 @@
-(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`.
diff --git a/meta-registry-test/clair-whitelist.yml b/meta-registry-test/clair-whitelist.yml
deleted file mode 100644
index a9d6ed5bdae04856ade1de9572cbdfee041aa4b9..0000000000000000000000000000000000000000
--- a/meta-registry-test/clair-whitelist.yml
+++ /dev/null
@@ -1 +0,0 @@
-generalwhitelist:
diff --git a/meta-registry-test/secrets/htpasswd.example b/meta-registry-test/secrets/htpasswd.example
deleted file mode 100644
index d0267063570136d825471934cd38008b4927a422..0000000000000000000000000000000000000000
--- a/meta-registry-test/secrets/htpasswd.example
+++ /dev/null
@@ -1 +0,0 @@
-picauser:$2y$05$axvpLiYg.ADRa2I8xAU/weLb7urnUIgoehsQuKut1/dlIhDOQ.iPy
diff --git a/noCI-uploads/README.md b/noCI-uploads/README.md
deleted file mode 100644
index 63d1e3c4aa9a083dcdfdfee3f3cd357e9f5781cc..0000000000000000000000000000000000000000
--- a/noCI-uploads/README.md
+++ /dev/null
@@ -1,3 +0,0 @@
-https://wiki.picasoft.net/doku.php?id=technique:adminsys:sftp
-
-https://hub.docker.com/r/atmoz/sftp
diff --git a/pica-ci-base/Dockerfile b/pica-ci-base/Dockerfile
deleted file mode 100644
index 27362e267c4032a4a7b956a6eeb639971c6caa1a..0000000000000000000000000000000000000000
--- a/pica-ci-base/Dockerfile
+++ /dev/null
@@ -1,12 +0,0 @@
-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
diff --git a/pica-db-backup-rotation/README.md b/pica-db-backup-rotation/README.md
index aa72315238b1e6a2ebf0948ef871a6240dbc7a2f..a731f8e12f2798864a7b57656c3a12da989ad842 100644
--- a/pica-db-backup-rotation/README.md
+++ b/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
diff --git a/pica-db-backup-rotation/clair-whitelist.yml b/pica-db-backup-rotation/clair-whitelist.yml
deleted file mode 100644
index a9d6ed5bdae04856ade1de9572cbdfee041aa4b9..0000000000000000000000000000000000000000
--- a/pica-db-backup-rotation/clair-whitelist.yml
+++ /dev/null
@@ -1 +0,0 @@
-generalwhitelist:
diff --git a/pica-db-backup-rotation/docker-compose.yml b/pica-db-backup-rotation/docker-compose.yml
index f08f62d1828e1f0663c5f73efb4207412328780a..6452e8ef27cdcc7a8df58540b32acce9e3da9a2c 100644
--- a/pica-db-backup-rotation/docker-compose.yml
+++ b/pica-db-backup-rotation/docker-compose.yml
@@ -3,9 +3,9 @@ version: "3.7"
services:
db-backup-rotation:
image: registry.picasoft.net/pica-db-backup-rotation:1.4
+ build: .
container_name: db-backup-rotation
volumes:
- /DATA/BACKUP/:/backup/
- ./config:/config
- restart: always
-#
+ restart: unless-stopped
diff --git a/pica-db-backup/README.md b/pica-db-backup/README.md
index ef351466f6b70bf4f7ef7a9d8e33bd7897c03ca7..38cfc82ea18829aa16437603840a0e22d4105779 100644
--- a/pica-db-backup/README.md
+++ b/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.
diff --git a/pica-db-backup/clair-whitelist.yml b/pica-db-backup/clair-whitelist.yml
deleted file mode 100644
index a9d6ed5bdae04856ade1de9572cbdfee041aa4b9..0000000000000000000000000000000000000000
--- a/pica-db-backup/clair-whitelist.yml
+++ /dev/null
@@ -1 +0,0 @@
-generalwhitelist:
diff --git a/pica-db-backup/docker-compose.yml b/pica-db-backup/docker-compose.yml
index 08d1ec882c7dad9f2c99a1a9cd2a2a30752000de..a60e92739b8a7efc335bbce7a49339f2b7d82c80 100644
--- a/pica-db-backup/docker-compose.yml
+++ b/pica-db-backup/docker-compose.yml
@@ -14,6 +14,7 @@ networks:
services:
db-backup:
image: registry.picasoft.net/pica-db-backup:1.3
+ build: .
container_name: db-backup
volumes:
- /DATA/BACKUP/:/backup/
diff --git a/pica-dokuwiki/README.md b/pica-dokuwiki/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..5812954310121777cb95f514b211c96890067011
--- /dev/null
+++ b/pica-dokuwiki/README.md
@@ -0,0 +1,19 @@
+## Dokuwiki
+
+Ce dossier contient les ressources nécessaires pour lancer une instance de Dokuwiki.
+Nous maintenons une image de ce service.
+
+Pour Dokuwiki, tout est fichier, il n'y a pas de bases de données : l'administration est donc très simple.
+
+### Configuration
+
+La configuration se fait directement dans Dokuwiki, une fois lancé. Il n'y a pas de manière simple de pré-configurer Dokuwiki via un fichier de configuration. Il y a trop de paramètres, et mettre à jour ce dépôt à chaque changement de paramètre serait très peu pratique.
+
+### Lancement
+
+Un simple `docker-compose up -d` suffit.
+
+### Mise à jour
+
+Il faudra changer la release téléchargée et extraite dans le [Dockerfile](./Dockerfile), si possible en précisant une version claire.
+Mettre ensuite à jour le fichier `CHANGELOG.md` pour indiquer les changements effectués.
diff --git a/pica-dokuwiki/clair-whitelist.yml b/pica-dokuwiki/clair-whitelist.yml
deleted file mode 100644
index 8d9487aeccf49d626937023f87807d14e12c56db..0000000000000000000000000000000000000000
--- a/pica-dokuwiki/clair-whitelist.yml
+++ /dev/null
@@ -1,5 +0,0 @@
-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
diff --git a/pica-dokuwiki/docker-compose.yml b/pica-dokuwiki/docker-compose.yml
index e68725a66704ec839d84a7fd3277c45d8d22aee0..1cdb815e99e460d5cb16dedceb05808ed1eb525e 100644
--- a/pica-dokuwiki/docker-compose.yml
+++ b/pica-dokuwiki/docker-compose.yml
@@ -10,20 +10,21 @@ networks:
external: true
services:
- dokuwiki-app:
- image: registry.picasoft.net/pica-dokuwiki:stable
- container_name: dokuwiki-app
- volumes:
- - dokuwiki-app-volume:/var/www/html
- security_opt:
- - no-new-privileges
- mem_limit: "2048m"
- cpus: "0.20"
- pids_limit: 1024
- labels:
- - "traefik.frontend.rule=Host:wiki.picasoft.net"
- - "traefik.port=80"
- - "traefik.enable=true"
- restart: unless-stopped
- networks:
- - docker_default
+ dokuwiki-app:
+ image: registry.picasoft.net/pica-dokuwiki:stable
+ build: .
+ container_name: dokuwiki-app
+ volumes:
+ - dokuwiki-app-volume:/var/www/html
+ security_opt:
+ - no-new-privileges
+ mem_limit: "2048m"
+ cpus: "0.20"
+ pids_limit: 1024
+ labels:
+ - "traefik.frontend.rule=Host:wiki.picasoft.net"
+ - "traefik.port=80"
+ - "traefik.enable=true"
+ restart: unless-stopped
+ networks:
+ - docker_default
diff --git a/pica-etherpad/README.md b/pica-etherpad/README.md
index 143c962c992dbbb9e23e5b50dd131e6825b7b835..320a7a79df597beafa977e28b247f02e81226bef 100644
--- a/pica-etherpad/README.md
+++ b/pica-etherpad/README.md
@@ -6,15 +6,6 @@ Le Docker Compose associé permet de lancer deux instances : une principale et u
Tous les fichiers présents ici suffisent à lancer correctement les conteneurs (application et base de données), si un Traefik tourne sur la machine cible.
-<!-- TOC depthFrom:2 depthTo:6 withLinks:1 updateOnSave:1 orderedList:0 -->
-
-- [Configuration](#configuration)
-- [Ajouter ou modifier un paramètre](#ajouter-ou-modifier-un-paramtre)
-- [Mise à jour de l'image](#mise-jour-de-limage)
-- [Ajout d'un plugin](#ajout-dun-plugin)
-
-<!-- /TOC -->
-
## Mise à jour de l'image
Pour mettre à jour la version d'Etherpad, il faut simplement modifir la variable `ETHERPAD_VERSION_BUILD` du [Dockerfile](./Dockerfile) et le tag dans l'image dans [docker-compose.yml](./docker-compose.yml).
@@ -44,7 +35,7 @@ Toutes les paramètres sont configurables via l'environnement. On pourra regarde
Le [docker-compose.yml](./docker-compose.yml) proposé inclut deux versions : une principale, usuellement sur [pad.picasoft.net](https://pad.picasoft.net), et une hebdomadaire, usuellement sur [week.pad.picasoft.net](https://week.pad.picasoft.net).
-Pour les lancer sur différentes machines, on lancera à la main :
+Pour les lancer sur différentes machines, on lancera :
```bash
# Pour l'instance principale, sur la machine A
diff --git a/pica-etherpad/clair-whitelist.yml b/pica-etherpad/clair-whitelist.yml
deleted file mode 100644
index 4ca3a9ab2415a29b226a81d45a9099ac411f66b2..0000000000000000000000000000000000000000
--- a/pica-etherpad/clair-whitelist.yml
+++ /dev/null
@@ -1,3 +0,0 @@
-generalwhitelist:
- CVE-2020-13249: mariadb-10.3 -> Pas de contre mesure, utilisé uniquement dans l'entrypoint (https://security-tracker.debian.org/tracker/CVE-2020-13249)
- CVE-2020-8492: python3.7 -> Pas de contre mesure, utilisé uniquement dans l'entrypoint pour ping PGSQL (https://security-tracker.debian.org/tracker/CVE-2020-8492)
diff --git a/pica-etherpad/docker-compose.yml b/pica-etherpad/docker-compose.yml
index 6df32940f472c58a0d98058cffdfb07f29f1f0c0..55ff0570d3a1ba827b43f37f197093a832b9e9d1 100755
--- a/pica-etherpad/docker-compose.yml
+++ b/pica-etherpad/docker-compose.yml
@@ -22,6 +22,7 @@ networks:
services:
etherpad-app:
image: registry.picasoft.net/pica-etherpad:1.8.4
+ build: .
container_name: etherpad-app
depends_on:
- etherpad-db
diff --git a/pica-grafana-prom/README.md b/pica-grafana-prom/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..6c21e0e01d345b7253b8a1cf3c1c667626f86257
--- /dev/null
+++ b/pica-grafana-prom/README.md
@@ -0,0 +1,56 @@
+# Grafana et Prometheus
+
+Ce dossier contient les ressources nécessaires pour lancer une instance de Grafana **et** de Prometheus, qui nous servent à collecter et visualiser les métriques des services (via [pica-metrics-bot](../pica-metrics-bot)) et des machines (via Prometheus).
+
+Pour plus de facilité, ces deux services doivent communiquer via le même réseau, c'est pourquoi ils sont dans le même Docker Compose. Il n'y a pas de raisons de mettre ces deux services sur une machine différente, ce qui aurait pour seul effet de créer de la complexité supplémentaire.
+
+Notez que Rhizome a aussi un compte créé manuellement sur l'instance Grafana : il faudra faire attention à les prévenir en cas de mise à jour ou de déplacement de l'instance.
+
+## Configuration
+
+Prometheus est un logiciel libre qui permet la collecte et le traitement de métriques, ainsi que le déclenchement d'alertes. Son fonctionnement est simple : un serveur va collecter régulièrement des métriques auprès de plusieurs *exporters*. Par exemple pour exporter des métriques systèmes, on utilise un *node_exporter* que l'on installe sur la machine, et on configure le serveur Prometheus (distant potentiellement) pour scraper cet exporter régulièrement.
+
+### Prometheus
+
+La configuration se fait dans [prometheus.yml](./prometheus.yml).
+
+Pour collecter des métriques, il est nécessaire d'installer des *exporters* sur les machines cible : [voir la documentation](https://wiki.picasoft.net/doku.php?id=technique:monitoring:metrics:system_metrics).
+
+### Grafana
+
+Attention : même si l'authentification LDAP est activée, elle semble ne pas fonctionner : la connexion ne fonctionne que grâce à l'utilisateur administrateur. Voir [cette page](https://grafana.com/docs/grafana/latest/auth/ldap/#ldap-debug-view) pour investiguer et régler le problème.
+
+#### Emplacements
+
+La configuration est réalisée :
+
+* Par les variables d'environnement de [Compose](./docker-compose.yml), qui permettent d'accéder à tous les paramètres de la configuration (voir la [documentation](https://grafana.com/docs/grafana/latest/administration/configuration/#configure-with-environment-variables)) : cette méthode est utilisée pour tous les paramètres non-critiques.
+* Par le fichier [ldap.toml](./ldap.toml) pour la configuration spécifique au LDAP. Ce fichier peut faire référence à des variables d'environnement avec [cette syntaxe](https://grafana.com/docs/grafana/latest/auth/ldap/#using-environment-variables), pour les données critiques (*e.g.* mot de passe)
+* Par le fichier [grafana.secrets](./secrets/grafana.secrets.example), pour les secrets.
+
+#### Utilisateurs
+
+Il y a trois types d'utilisateurs :
+
+* L'administrateur de l'instance, configuré via l'environnement (Compose et secret)
+* Les utilisateurs LDAP
+* Les utilisateurs créés manuellement, comme Rhizome
+
+### Lancement
+
+Copier `grafana.secrets.example` dans `grafana.secrets` et remplacer les valeurs. Le mot de passe LDAP de `grafana` se trouve dans le [pass](https://gitlab.utc.fr/picasoft/interne/pass).
+Lancer :
+
+```bash
+docker-compose up -d
+```
+
+### Mise à jour
+
+Il suffit de mettre à jour le tag dans Compose.
+
+Concernant Grafana, pour le moment, nous utilisons une image de notre registre privé, mais il probable qu'il soit plus pertinent d'utiliser les images officielles (`grafana/grafana`).
+
+Cette possibilité devra être étudiée à la prochaine mise à jour.
+
+Il ne devrait pas y avoir de manipulation spécifiques pour mettre à jour une instance Docker : voir [la documentation de Grafana](https://grafana.com/docs/grafana/latest/installation/upgrading/#docker) et la [documentation de Prometheus](https://hub.docker.com/r/prom/prometheus) pour le vérifier.
diff --git a/pica-grafana-prom/docker-compose.yml b/pica-grafana-prom/docker-compose.yml
new file mode 100644
index 0000000000000000000000000000000000000000..2a6a8c1894d2271fcf3f10194f8f477e0e1def3b
--- /dev/null
+++ b/pica-grafana-prom/docker-compose.yml
@@ -0,0 +1,46 @@
+version: '3.7'
+
+networks:
+ metrics:
+ docker_default:
+ name: docker_default
+
+volumes:
+ grafana:
+ name: grafana
+ prometheus:
+ name: prometheus
+
+services:
+ grafana:
+ image: registry.picasoft.net/grafana:6.4.4
+ container_name: grafana
+ volumes:
+ - grafana:/var/lib/grafana
+ - ./ldap.toml:/etc/grafana-ldap/ldap.toml
+ environment:
+ - GF_DEFAULT_INSTANCE_NAME=picasoft
+ - GF_SERVER_ROOT_URL=https://grafana.picasoft.net
+ - GF_SECURITY_ADMIN_USER=picasoft
+ - GF_AUTH_LDAP_ENABLED=true
+ - GF_AUTH_LDAP_CONFIG_FILE=/etc/grafana-ldap/ldap.toml
+ - GF_AUTH_LDAP_ALLOW_SIGN_UP=false
+ env_file: ./secrets/grafana.secrets
+ labels:
+ - "traefik.frontend.rule=Host:grafana.picasoft.net"
+ - "traefik.port=3000"
+ - "traefik.enable=true"
+ networks:
+ - docker_default
+ - metrics
+ restart: unless-stopped
+
+ prometheus:
+ image: "prom/prometheus:v2.14.0"
+ container_name: prometheus
+ volumes:
+ - ./prometheus.yml:/etc/prometheus/prometheus.yml
+ - prometheus:/prometheus
+ networks:
+ - metrics
+ restart: unless-stopped
diff --git a/pica-grafana-prom/ldap.toml b/pica-grafana-prom/ldap.toml
new file mode 100644
index 0000000000000000000000000000000000000000..0c053a2f2642fbdcf30334807a765dbd2821defb
--- /dev/null
+++ b/pica-grafana-prom/ldap.toml
@@ -0,0 +1,65 @@
+# To troubleshoot and get more log info enable ldap debug logging in grafana.ini
+# [log]
+# filters = ldap:debug
+
+[[servers]]
+# Ldap server host (specify multiple hosts space separated)
+host = "ldap.picasoft.net"
+# Default port is 389 or 636 if use_ssl = true
+port = 389
+# Set to true if ldap server supports TLS
+use_ssl = false
+# Set to true if connect ldap server with STARTTLS pattern (create connection in insecure, then upgrade to secure connection with TLS)
+start_tls = false
+# set to true if you want to skip ssl cert validation
+ssl_skip_verify = true # Le LDAP est accessible que depuis les VM Picasoft, il me semble qu'il n'y a pas de ssl configuré
+# set to the path to your root CA certificate or leave unset to use system defaults
+# root_ca_cert = "/path/to/certificate.crt"
+# Authentication against LDAP servers requiring client certificates
+# client_cert = "/path/to/client.crt"
+# client_key = "/path/to/client.key"
+
+# Search user bind dn
+bind_dn = "cn=grafana,ou=Services,dc=picasoft,dc=net"
+# Search user bind password
+# If the password contains # or ; you have to wrap it with triple quotes. Ex """#password;"""
+bind_password = '${LDAP_GRAFANA_PASSWORD}'
+
+# User search filter, for example "(cn=%s)" or "(sAMAccountName=%s)" or "(uid=%s)"
+search_filter = "(&(objectClass=posixAccount)(uid=%s))"
+
+# An array of base dns to search through
+search_base_dns = ["ou=People,dc=picasoft,dc=net"]
+
+## For Posix or LDAP setups that does not support member_of attribute you can define the below settings
+## Please check grafana LDAP docs for examples
+group_search_filter = "(&(objectClass=posixGroup)(memberUid=%s))"
+group_search_base_dns = ["ou=Groups,dc=picasoft,dc=net"]
+group_search_filter_user_attribute = "uid" # J'ai laissé la valeur par défaut, aucune idée si ça va marcher
+#group_search_filter_user_attribute = "cn" # J'ai laissé la valeur par défaut, aucune idée si ça va marcher
+
+# Specify names of the ldap attributes your ldap uses
+[servers.attributes]
+name = "givenName"
+surname = "sn"
+username = "cn"
+#member_of = "memberOf" # Celui là on ne l'utilise pas
+email = "mail"
+
+# Map ldap groups to grafana org roles
+[[servers.group_mappings]]
+group_dn = "cn=admin,ou=Groups,dc=picasoft,dc=net"
+org_role = "Admin"
+# To make user an instance admin (Grafana Admin) uncomment line below
+# grafana_admin = true
+# The Grafana organization database id, optional, if left out the default org (id 1) will be used
+# org_id = 1
+
+[[servers.group_mappings]]
+group_dn = "cn=tech,ou=Groups,dc=picasoft,dc=net"
+org_role = "Editor"
+
+[[servers.group_mappings]]
+# If you want to match all (or no ldap groups) then you can use wildcard
+group_dn = "*"
+org_role = "Viewer"
diff --git a/pica-grafana-prom/prometheus.yml b/pica-grafana-prom/prometheus.yml
new file mode 100644
index 0000000000000000000000000000000000000000..de3a5876cf6eb730fcca8518c7d4d3217889aa60
--- /dev/null
+++ b/pica-grafana-prom/prometheus.yml
@@ -0,0 +1,36 @@
+# my global config
+global:
+ scrape_interval: 1m # Set the scrape interval to every 1 minute
+ evaluation_interval: 1m # Evaluate rules every 1 minute
+scrape_configs:
+ - job_name: 'voice-mumble'
+ static_configs:
+ - targets:
+ - 'voice.picasoft.net'
+ - job_name: 'pica01'
+ static_configs:
+ - targets:
+ - 'pica01.picasoft.net:9100'
+ relabel_configs:
+ - source_labels: [__address__]
+ regex: '.*'
+ target_label: instance
+ replacement: 'pica01'
+ - job_name: 'pica02'
+ static_configs:
+ - targets:
+ - 'pica02.picasoft.net:9100'
+ relabel_configs:
+ - source_labels: [__address__]
+ regex: '.*'
+ target_label: instance
+ replacement: 'pica02'
+ - job_name: 'monitoring'
+ static_configs:
+ - targets:
+ - 'monitoring.picasoft.net:9100'
+ relabel_configs:
+ - source_labels: [__address__]
+ regex: '.*'
+ target_label: instance
+ replacement: 'monitoring'
diff --git a/pica-grafana-prom/secrets/grafana.secrets.example b/pica-grafana-prom/secrets/grafana.secrets.example
new file mode 100644
index 0000000000000000000000000000000000000000..afae639fd50cce45efb6a8aa33f28d97972663ad
--- /dev/null
+++ b/pica-grafana-prom/secrets/grafana.secrets.example
@@ -0,0 +1,2 @@
+GF_SECURITY_ADMIN_PASSWORD=password
+LDAP_GRAFANA_PASSWORD=ldap_password
diff --git a/pica-influxdb-rhizome/README.md b/pica-influxdb-rhizome/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..ce95363ea60506aef1dfdc482884cde923149473
--- /dev/null
+++ b/pica-influxdb-rhizome/README.md
@@ -0,0 +1,22 @@
+## InfluxDB Rhizome
+
+Nous hébergeons une base InfluxDB pour le compte de Rhizome.
+
+Ce dossier contient les ressources nécessaires pour lancer l'instance.
+
+### Lancement
+
+Copier `influxdb-rhizome.secrets.example` dans `influxdb-rhizome.secrets` et remplacer les valeurs, puis lancer :
+
+```bash
+docker-compose up -d && docker-compose logs -f
+```
+
+Communiquer les identifiants aux personnes en charge chez Rhizome.
+
+### Mise à jour
+
+Il suffit de changer le tag dans [Compose](./docker-compose.yml).
+Il n'est probablement pas pertinent d'utiliser notre propre version d'InfluxDB. Lors de la prochaine mise à jour, je recommande d'utiliser [l'image officielle](https://hub.docker.com/_/influxdb).
+
+Voir sur la documentation si des étapes sont nécessaires pour passer d'une version majeure à une autre : ça devrait se faire sans soucis.
diff --git a/pica-influxdb-rhizome/docker-compose.yml b/pica-influxdb-rhizome/docker-compose.yml
new file mode 100644
index 0000000000000000000000000000000000000000..289717bd05ebfb3ae12ab61cb0416de126a86562
--- /dev/null
+++ b/pica-influxdb-rhizome/docker-compose.yml
@@ -0,0 +1,28 @@
+version: '3.7'
+
+volumes:
+ influxdb_rhizome:
+
+networks:
+ docker_default:
+ name: docker_default
+
+services:
+ influxdb_rhizome:
+ image: registry.picasoft.net/influxdb:1.7.9
+ container_name: influxdb_rhizome
+ volumes:
+ - influxdb_rhizome:/var/lib/influxdb
+ environment:
+ - INFLUXDB_HTTP_AUTH_ENABLED=true
+ - INFLUXDB_DATA_MAX_VALUES_PER_TAG=0
+ # See https://docs.influxdata.com/influxdb/v1.7/administration/upgrading/#switch-between-tsm-and-tsi-indexes
+ - INFLUXDB_DATA_INDEX_VERSION=tsi1
+ env_file: ./influxdb-rhizome.secrets
+ labels:
+ - "traefik.frontend.rule=Host:influxdb.rhizome.picasoft.net"
+ - "traefik.port=8086"
+ - "traefik.enable=true"
+ networks:
+ - docker_default
+ restart: unless-stopped
diff --git a/pica-influxdb-rhizome/secrets/influxdb-rhizome.secrets.example b/pica-influxdb-rhizome/secrets/influxdb-rhizome.secrets.example
new file mode 100644
index 0000000000000000000000000000000000000000..271f311190661e9f414ef9885f023f52a2eb1b24
--- /dev/null
+++ b/pica-influxdb-rhizome/secrets/influxdb-rhizome.secrets.example
@@ -0,0 +1,7 @@
+INFLUXDB_DB=rhizome
+INFLUXDB_ADMIN_USER=rhizome-admin
+INFLUXDB_ADMIN_PASSWORD=password
+INFLUXDB_WRITE_USER=rhizome-write
+INFLUXDB_WRITE_USER_PASSWORD=password
+INFLUXDB_READ_USER=rhizome-read
+INFLUXDB_READ_USER_PASSWORD=password
diff --git a/pica-lufi/README.md b/pica-lufi/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..ab5b4a635496c2df431c4b8b7ddaf06eeb5e0a5b
--- /dev/null
+++ b/pica-lufi/README.md
@@ -0,0 +1,5 @@
+## Lufi
+
+Ce dossier comprend un travail en cours pour créer une instance de Lufi, un service libre de partage de fichier chiffrés.
+
+À mettre à jour.
diff --git a/pica-lufi/docker-compose.yml b/pica-lufi/docker-compose.yml
index 15ffdf44fdabbc7c487c706c6bd44160de35612f..ee0b392182082a1252c8884e869f1b6490603572 100644
--- a/pica-lufi/docker-compose.yml
+++ b/pica-lufi/docker-compose.yml
@@ -6,17 +6,9 @@ volumes:
lufi-files:
services:
- lufidb:
- image: postgres:12
- container_name: lufidb
- restart: always
- env_file:
- - lufi.env
- volumes:
- - lufidb-data:/var/lib/postgresql/data
-
lufi:
- image: lufi
+ image: registry.picasoft.net/lufi:0.04.6
+ build: .
container_name: lufi
init: true
depends_on:
@@ -29,7 +21,16 @@ services:
- lufi-data:/lufi/data
- lufi-files:/lufi/files
labels:
- - "traefik.frontend.rule=Host:drop.test.picasoft.net"
+ - "traefik.frontend.rule=Host:drop.picasoft.net"
- "traefik.backend=lufi"
- "traefik.port=8081"
- "traefik.enable=true"
+
+ lufidb:
+ image: postgres:12
+ container_name: lufidb
+ restart: always
+ env_file:
+ - lufi.env
+ volumes:
+ - lufidb-data:/var/lib/postgresql/data
diff --git a/docker-compose/.env b/pica-mail/.env
similarity index 100%
rename from docker-compose/.env
rename to pica-mail/.env
diff --git a/pica-mail/README.md b/pica-mail/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..dbc6562c5e5c9cd69f7b85751555d761182fddc8
--- /dev/null
+++ b/pica-mail/README.md
@@ -0,0 +1,45 @@
+## Serveur mail de Picasoft
+
+Ce dossier contient les ressources pour lancer le serveur mail de Picasoft.
+Toutes les images sont personnalisées selon nos besoins et construites à la main.
+
+Cette documentation se limite à Docker. Pour plus d'informations sur le serveur mail en général, voir [la documentation sur le Wiki](https://wiki.picasoft.net/doku.php?id=technique:mail:start).
+
+### Construction des images
+
+Deux images sont nécessaires pour le serveur mail : le MTA et le MDA.
+Les deux Dockerfile sont présents dans les dossier [pica-mail-mda](./pica-mail-mda) et [pica-mail-mta](./pica-mail-mta).
+Pour plus de facilité, Docker Compose sait construire ces images simultanément : il suffit de lancer
+
+```bash
+docker-compose build
+```
+
+Puis de les pousser sur le registre de production :
+
+```bash
+docker-compose push
+```
+
+### Configuration
+
+La configuration se fait essentiellement via les variables d'environnement de [Compose](./docker-compose.yml).
+Deux dossiers supplémentaires doivent exister :
+
+* `/DATA/docker/mail/opendkim`, dont le contenu sera peuplé [comme indiqué dans la documentation](https://wiki.picasoft.net/doku.php?id=technique:mail:dkim).
+* `/DATA/docker/mail/ssl`, qui doit contenir les certificats SSL du serveur mail. Pour le moment, ils sont extraits de Traefik avec [ces commandes](../deprecated/pica-mail-copy-certs/update-certs-pica-mail.sh), mais dans le futur ils devront être gérés par [TLS Certs Monitor](../pica-tls-certs-monitor).
+
+### Lancement
+
+Copier `mail.secrets.example` dans `mail.secrets` et remplacer les valeurs. Le mot de passe LDAP du compte `mail` est sur le [pass](https://gitlab.utc.fr/picasoft/interne/pass).
+
+Lancer :
+```bash
+docker-compose up -d
+```
+
+### Mise à jour
+
+Il suffit de mettre à jour les Dockerfile. Il sera alors de bon ton de créer un fichier `CHANGELOG.md` pour expliquer les changements et d'ajouter un tag aux images pour faire la différence.
+
+En cas de modification de la configuration, pas besoin de changer le tag.
diff --git a/pica-mail/docker-compose.yml b/pica-mail/docker-compose.yml
new file mode 100644
index 0000000000000000000000000000000000000000..bb08baad83f72393b5c36a6ce06928b07ecb72b6
--- /dev/null
+++ b/pica-mail/docker-compose.yml
@@ -0,0 +1,90 @@
+version: "3.7"
+
+#attention, docker-compose préfixe le nom du réseau créé par le nom du projet (contenu dans le .env, sinon c'est le nom du dossier)
+networks:
+ mail:
+
+volumes:
+ mail-mda-maildir:
+ name: mail-mda-maildir
+ mail-mta-log:
+ name: mail-mta-log
+
+services:
+ mail-mda:
+ image: registry.picasoft.net/pica-mail-mda
+ build:
+ dockerfile: ./pica-mail-mda/Dockerfile
+ container_name: pica-mail-mda
+ ports:
+ - "143:143"
+ - "993:993"
+ networks:
+ - mail
+ hostname: pica-mail-mda
+ volumes:
+ - mail-mda-maildir:/home
+ - /DATA/docker/mail/ssl/:/certs-ssl/:ro
+ environment:
+ LDAP_ADDRESS: ldap.picasoft.net
+ LDAP_NSS_CN: cn=mail,ou=Services,dc=picasoft,dc=net
+ LDAP_BASE: dc=picasoft,dc=net
+ USER_FILTER: (uid=%n)
+ PASSWORD_FILTER: (uid=%n)
+ env_file: ./secrets/mail.secrets
+
+ mail-mta:
+ image: registry.picasoft.net/pica-mail-mta
+ build:
+ dockerfile: ./pica-mail-mta/Dockerfile
+ container_name: pica-mail-mta
+ ports:
+ - "25:25"
+ - "465:465"
+ - "587:587"
+ networks:
+ - mail
+ volumes:
+ - mail-mta-log:/var/log
+ #doit contenir selecteur.domaine.rsa
+ - /DATA/docker/mail/opendkim/:/etc/dkimkeys/
+ - /DATA/docker/mail/ssl/:/certs-ssl/
+ env_file: ./secrets/mail.secrets
+ environment:
+ #adresse et port du serveur LMTP i.e. le MTA
+ LMTP_LAN_HOSTNAME: pica-mail-mda.pica_mail
+ LMTP_PORT: 24
+ #nom d'hôte sous lequel Postfix répondra aux requêtes SMTP
+ MY_HOSTNAME: mail.picasoft.net
+ #domaine des mails
+ MY_DOMAIN: picasoft.net
+ #domaines mails qu'on s'autorise à relayer (qui ont le droit de passer à travers notre serveur si ils sont en expéditeur ou destinataire)
+ RELAY_DOMAINS: picasoft.net
+ #réglage de la connexion au serveur LDAP: protocole (ldap ou ldaps), hôte et port
+ LDAP_PROTOCOL: ldap
+ LDAP_SERVER_HOSTNAME: ldap.picasoft.net
+ LDAP_PORT: 389
+ #réglage du bind : login d'un compte qui a suffisamment de droits pour lire l'arborescence (à l'exception des mots de passe)
+ LDAP_BIND_DN: cn=mail,ou=Services,dc=picasoft,dc=net
+ #réglage de la manière dont on répertorie les comptes et les adresses existantes
+ #la config actuelle fait que la possession d'une adresse mail se fait ainsi : login => login@picasoft.net
+ #cependant, nous avons quand même deux couches différentes: l'existence d'un compte (SASL) et l'existence d'une adresse
+ #ce qui fait qu'on peut créer une adresse valide sans nécessairement lui associer un compte valide
+ #ainsi, on pourra recevoir des mails dans la boîte, mais on ne pourra pas se connecter en tant que cet utilisateur
+ #pour ce faire, il suffit d'utiliser des attributs LDAP différents
+ #nous utilisons donc le cn pour l'existence d'un compte LDAP, et l'uid pour l'existence d'une adresse
+ #niveau de l'arborescence à partir duquel les entrées sont trouvées:
+ LDAP_SEARCH_BASE: dc=picasoft,dc=net
+ #filtre permettant de répertorier les comptes SASL
+ LDAP_SASL_FILTER: "cn=%u"
+ #filtre permettant de répertorier les adresses mail
+ LDAP_VIRTUAL_MAILBOX_FILTER: "uid=%s"
+ #ajout de listes noires pour éviter le SPAM. La décision politique et l'éthique associée sortent du cadre de la conception de cette image et doivent être discutées par l'asso; en tout cas, si on lève cette restriction, elle doit être remplacée par une autre (un spamassassin par exemple).
+ SMTPD_CLIENT_RESTRICTIONS: reject_rbl_client sbl.spamhaus.org, reject_rbl_client dnsbl.sorbs.net
+ #prefixe DKIM, utilise pour identifier la clef
+ DKIM_SELECTOR: janv2019
+ labels:
+ - "traefik.frontend.rule=Host:mail.picasoft.net"
+ - "traefik.port=80"
+ - "traefik.enable=true"
+ - "traefik.docker.network=pica_mail"
diff --git a/pica-mail-mda/Dockerfile b/pica-mail/pica-mail-mda/Dockerfile
similarity index 100%
rename from pica-mail-mda/Dockerfile
rename to pica-mail/pica-mail-mda/Dockerfile
diff --git a/pica-mail-mda/README.md b/pica-mail/pica-mail-mda/README.md
similarity index 100%
rename from pica-mail-mda/README.md
rename to pica-mail/pica-mail-mda/README.md
diff --git a/pica-mail-mda/entrypoint.sh b/pica-mail/pica-mail-mda/entrypoint.sh
similarity index 100%
rename from pica-mail-mda/entrypoint.sh
rename to pica-mail/pica-mail-mda/entrypoint.sh
diff --git a/pica-mail-mda/fichiers_de_configuration.sh b/pica-mail/pica-mail-mda/fichiers_de_configuration.sh
similarity index 100%
rename from pica-mail-mda/fichiers_de_configuration.sh
rename to pica-mail/pica-mail-mda/fichiers_de_configuration.sh
diff --git a/pica-mail-mta/Dockerfile b/pica-mail/pica-mail-mta/Dockerfile
similarity index 100%
rename from pica-mail-mta/Dockerfile
rename to pica-mail/pica-mail-mta/Dockerfile
diff --git a/pica-mail-mta/README.md b/pica-mail/pica-mail-mta/README.md
similarity index 98%
rename from pica-mail-mta/README.md
rename to pica-mail/pica-mail-mta/README.md
index fd7a85113e12cb982367b71a84ea61d794ce9fbc..db8dfdaa7966298e6c7c90b8ee561dd1f48c53e1 100644
--- a/pica-mail-mta/README.md
+++ b/pica-mail/pica-mail-mta/README.md
@@ -7,4 +7,4 @@ Pour run, utiliser le docker-compose en se plaçant dans son répertoire (pour q
```
cd ../docker-compose
docker-compose -f mail.yml up
-```
\ No newline at end of file
+```
diff --git a/pica-mail-mta/config.sh b/pica-mail/pica-mail-mta/config.sh
similarity index 100%
rename from pica-mail-mta/config.sh
rename to pica-mail/pica-mail-mta/config.sh
diff --git a/pica-mail-mta/entrypoint.sh b/pica-mail/pica-mail-mta/entrypoint.sh
similarity index 100%
rename from pica-mail-mta/entrypoint.sh
rename to pica-mail/pica-mail-mta/entrypoint.sh
diff --git a/pica-mail-mta/local_mailbox_ldap_sasl/Dockerfile b/pica-mail/pica-mail-mta/local_mailbox_ldap_sasl/Dockerfile
similarity index 100%
rename from pica-mail-mta/local_mailbox_ldap_sasl/Dockerfile
rename to pica-mail/pica-mail-mta/local_mailbox_ldap_sasl/Dockerfile
diff --git a/pica-mail-mta/local_mailbox_ldap_sasl/README.md b/pica-mail/pica-mail-mta/local_mailbox_ldap_sasl/README.md
similarity index 100%
rename from pica-mail-mta/local_mailbox_ldap_sasl/README.md
rename to pica-mail/pica-mail-mta/local_mailbox_ldap_sasl/README.md
diff --git a/pica-mail-mta/local_mailbox_ldap_sasl/entrypoint2.sh b/pica-mail/pica-mail-mta/local_mailbox_ldap_sasl/entrypoint2.sh
similarity index 100%
rename from pica-mail-mta/local_mailbox_ldap_sasl/entrypoint2.sh
rename to pica-mail/pica-mail-mta/local_mailbox_ldap_sasl/entrypoint2.sh
diff --git a/pica-mail-mta/local_mailbox_ldap_sasl/local_users b/pica-mail/pica-mail-mta/local_mailbox_ldap_sasl/local_users
similarity index 100%
rename from pica-mail-mta/local_mailbox_ldap_sasl/local_users
rename to pica-mail/pica-mail-mta/local_mailbox_ldap_sasl/local_users
diff --git a/pica-mail-mta/local_mailbox_ldap_sasl/saslauthd-postfix b/pica-mail/pica-mail-mta/local_mailbox_ldap_sasl/saslauthd-postfix
similarity index 100%
rename from pica-mail-mta/local_mailbox_ldap_sasl/saslauthd-postfix
rename to pica-mail/pica-mail-mta/local_mailbox_ldap_sasl/saslauthd-postfix
diff --git a/pica-mail-mta/local_mailbox_unix_sasl/Dockerfile b/pica-mail/pica-mail-mta/local_mailbox_unix_sasl/Dockerfile
similarity index 100%
rename from pica-mail-mta/local_mailbox_unix_sasl/Dockerfile
rename to pica-mail/pica-mail-mta/local_mailbox_unix_sasl/Dockerfile
diff --git a/pica-mail-mta/local_mailbox_unix_sasl/README.md b/pica-mail/pica-mail-mta/local_mailbox_unix_sasl/README.md
similarity index 100%
rename from pica-mail-mta/local_mailbox_unix_sasl/README.md
rename to pica-mail/pica-mail-mta/local_mailbox_unix_sasl/README.md
diff --git a/pica-mail-mta/local_mailbox_unix_sasl/entrypoint2.sh b/pica-mail/pica-mail-mta/local_mailbox_unix_sasl/entrypoint2.sh
similarity index 100%
rename from pica-mail-mta/local_mailbox_unix_sasl/entrypoint2.sh
rename to pica-mail/pica-mail-mta/local_mailbox_unix_sasl/entrypoint2.sh
diff --git a/pica-mail-mta/local_mailbox_unix_sasl/local_users b/pica-mail/pica-mail-mta/local_mailbox_unix_sasl/local_users
similarity index 100%
rename from pica-mail-mta/local_mailbox_unix_sasl/local_users
rename to pica-mail/pica-mail-mta/local_mailbox_unix_sasl/local_users
diff --git a/pica-mail-mta/local_mailbox_unix_sasl/saslauthd-postfix b/pica-mail/pica-mail-mta/local_mailbox_unix_sasl/saslauthd-postfix
similarity index 100%
rename from pica-mail-mta/local_mailbox_unix_sasl/saslauthd-postfix
rename to pica-mail/pica-mail-mta/local_mailbox_unix_sasl/saslauthd-postfix
diff --git a/pica-mail-mta/minimal-postfix/Dockerfile b/pica-mail/pica-mail-mta/minimal-postfix/Dockerfile
similarity index 100%
rename from pica-mail-mta/minimal-postfix/Dockerfile
rename to pica-mail/pica-mail-mta/minimal-postfix/Dockerfile
diff --git a/pica-mail-mta/opendkim-tables.sh b/pica-mail/pica-mail-mta/opendkim-tables.sh
similarity index 100%
rename from pica-mail-mta/opendkim-tables.sh
rename to pica-mail/pica-mail-mta/opendkim-tables.sh
diff --git a/pica-mail-mta/rsyslog.conf b/pica-mail/pica-mail-mta/rsyslog.conf
similarity index 100%
rename from pica-mail-mta/rsyslog.conf
rename to pica-mail/pica-mail-mta/rsyslog.conf
diff --git a/pica-mail-mta/sasl-test/Dockerfile b/pica-mail/pica-mail-mta/sasl-test/Dockerfile
similarity index 100%
rename from pica-mail-mta/sasl-test/Dockerfile
rename to pica-mail/pica-mail-mta/sasl-test/Dockerfile
diff --git a/pica-mail-mta/sasl-test/README.md b/pica-mail/pica-mail-mta/sasl-test/README.md
similarity index 100%
rename from pica-mail-mta/sasl-test/README.md
rename to pica-mail/pica-mail-mta/sasl-test/README.md
diff --git a/pica-mail-mta/sasl-test/entrypoint2.sh b/pica-mail/pica-mail-mta/sasl-test/entrypoint2.sh
similarity index 100%
rename from pica-mail-mta/sasl-test/entrypoint2.sh
rename to pica-mail/pica-mail-mta/sasl-test/entrypoint2.sh
diff --git a/pica-mail-mta/sasl-test/ldap-virtual-mailbox-maps b/pica-mail/pica-mail-mta/sasl-test/ldap-virtual-mailbox-maps
similarity index 100%
rename from pica-mail-mta/sasl-test/ldap-virtual-mailbox-maps
rename to pica-mail/pica-mail-mta/sasl-test/ldap-virtual-mailbox-maps
diff --git a/pica-mail-mta/sasl-test/saslauthd-postfix b/pica-mail/pica-mail-mta/sasl-test/saslauthd-postfix
similarity index 100%
rename from pica-mail-mta/sasl-test/saslauthd-postfix
rename to pica-mail/pica-mail-mta/sasl-test/saslauthd-postfix
diff --git a/pica-mail-mta/saslauthd-postfix b/pica-mail/pica-mail-mta/saslauthd-postfix
similarity index 100%
rename from pica-mail-mta/saslauthd-postfix
rename to pica-mail/pica-mail-mta/saslauthd-postfix
diff --git a/pica-mail-mta/spam/dkimkeys/README.PrivateKeys b/pica-mail/pica-mail-mta/spam/dkimkeys/README.PrivateKeys
similarity index 100%
rename from pica-mail-mta/spam/dkimkeys/README.PrivateKeys
rename to pica-mail/pica-mail-mta/spam/dkimkeys/README.PrivateKeys
diff --git a/pica-mail-mta/spam/dkimkeys/rsakeys.table b/pica-mail/pica-mail-mta/spam/dkimkeys/rsakeys.table
similarity index 100%
rename from pica-mail-mta/spam/dkimkeys/rsakeys.table
rename to pica-mail/pica-mail-mta/spam/dkimkeys/rsakeys.table
diff --git a/pica-mail-mta/spam/dkimkeys/signingdomains.table b/pica-mail/pica-mail-mta/spam/dkimkeys/signingdomains.table
similarity index 100%
rename from pica-mail-mta/spam/dkimkeys/signingdomains.table
rename to pica-mail/pica-mail-mta/spam/dkimkeys/signingdomains.table
diff --git a/pica-mail-mta/spam/ignore.hosts b/pica-mail/pica-mail-mta/spam/ignore.hosts
similarity index 100%
rename from pica-mail-mta/spam/ignore.hosts
rename to pica-mail/pica-mail-mta/spam/ignore.hosts
diff --git a/pica-mail-mta/spam/nov2018.picasoft.net.rsa b/pica-mail/pica-mail-mta/spam/nov2018.picasoft.net.rsa
similarity index 100%
rename from pica-mail-mta/spam/nov2018.picasoft.net.rsa
rename to pica-mail/pica-mail-mta/spam/nov2018.picasoft.net.rsa
diff --git a/pica-mail-mta/spam/opendkim b/pica-mail/pica-mail-mta/spam/opendkim
similarity index 100%
rename from pica-mail-mta/spam/opendkim
rename to pica-mail/pica-mail-mta/spam/opendkim
diff --git a/pica-mail-mta/spam/opendkim.conf b/pica-mail/pica-mail-mta/spam/opendkim.conf
similarity index 100%
rename from pica-mail-mta/spam/opendkim.conf
rename to pica-mail/pica-mail-mta/spam/opendkim.conf
diff --git a/pica-mail-mta/spam/opendmarc b/pica-mail/pica-mail-mta/spam/opendmarc
similarity index 100%
rename from pica-mail-mta/spam/opendmarc
rename to pica-mail/pica-mail-mta/spam/opendmarc
diff --git a/pica-mail-mta/spam/opendmarc.conf b/pica-mail/pica-mail-mta/spam/opendmarc.conf
similarity index 100%
rename from pica-mail-mta/spam/opendmarc.conf
rename to pica-mail/pica-mail-mta/spam/opendmarc.conf
diff --git a/pica-mail-mta/test-auth_local_user/Dockerfile b/pica-mail/pica-mail-mta/test-auth_local_user/Dockerfile
similarity index 100%
rename from pica-mail-mta/test-auth_local_user/Dockerfile
rename to pica-mail/pica-mail-mta/test-auth_local_user/Dockerfile
diff --git a/pica-mail-mta/test-auth_local_user/README.md b/pica-mail/pica-mail-mta/test-auth_local_user/README.md
similarity index 100%
rename from pica-mail-mta/test-auth_local_user/README.md
rename to pica-mail/pica-mail-mta/test-auth_local_user/README.md
diff --git a/pica-mail-mta/test-auth_local_user/entrypoint2.sh b/pica-mail/pica-mail-mta/test-auth_local_user/entrypoint2.sh
similarity index 100%
rename from pica-mail-mta/test-auth_local_user/entrypoint2.sh
rename to pica-mail/pica-mail-mta/test-auth_local_user/entrypoint2.sh
diff --git a/pica-mail-mta/test-auth_local_user/local_users b/pica-mail/pica-mail-mta/test-auth_local_user/local_users
similarity index 100%
rename from pica-mail-mta/test-auth_local_user/local_users
rename to pica-mail/pica-mail-mta/test-auth_local_user/local_users
diff --git a/pica-mail/secrets/mail.secrets.example b/pica-mail/secrets/mail.secrets.example
new file mode 100644
index 0000000000000000000000000000000000000000..5ff81c657a5489e80c15df948335a4051ddfd551
--- /dev/null
+++ b/pica-mail/secrets/mail.secrets.example
@@ -0,0 +1,2 @@
+LDAP_DNPASS=ldap_password
+LDAP_BIND_PW=ldap_password
diff --git a/pica-mattermost/clair-whitelist.yml b/pica-mattermost/clair-whitelist.yml
deleted file mode 100644
index 519b80a6902a5d1ace39d4a9a4ec35524560f5b6..0000000000000000000000000000000000000000
--- a/pica-mattermost/clair-whitelist.yml
+++ /dev/null
@@ -1,2 +0,0 @@
-generalwhitelist:
- CVE-2016-4074: jq -> pas de contre mesure, pas utilisé par Mattermost mais juste par l'entrypoint, pas de risque en remote
diff --git a/pica-mattermost/docker-compose.yml b/pica-mattermost/docker-compose.yml
index 2cc8287301d94cd195f4d5a2e8afd0def6a9f652..5f66f8f384daa7649f44274765c76eb8ee687de4 100644
--- a/pica-mattermost/docker-compose.yml
+++ b/pica-mattermost/docker-compose.yml
@@ -17,6 +17,7 @@ volumes:
services:
mattermost:
image: registry.picasoft.net/pica-mattermost:5.23.0
+ build: .
container_name: mattermost-app
links:
- mattermost-db:mattermost-db
diff --git a/pica-metrics-bot/clair-whitelist.yml b/pica-metrics-bot/clair-whitelist.yml
deleted file mode 100644
index a9d6ed5bdae04856ade1de9572cbdfee041aa4b9..0000000000000000000000000000000000000000
--- a/pica-metrics-bot/clair-whitelist.yml
+++ /dev/null
@@ -1 +0,0 @@
-generalwhitelist:
diff --git a/pica-metrics-bot/docker-compose.yml b/pica-metrics-bot/docker-compose.yml
index 33a13cd0353fd35abff4ce81980dab5c9eda5b97..9755a65c2d295848403d786e2179304e5272d65a 100644
--- a/pica-metrics-bot/docker-compose.yml
+++ b/pica-metrics-bot/docker-compose.yml
@@ -12,6 +12,7 @@ networks:
services:
metrics-bot:
image: registry.picasoft.net/pica-metrics-bot:v1.0.2
+ build: .
container_name: pica-metrics-services
volumes:
- ./config.json:/config.json
diff --git a/pica-mumble-web/README.md b/pica-mumble-web/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..c1c98c796d2c2946b75167075953bb8e8ddf0742
--- /dev/null
+++ b/pica-mumble-web/README.md
@@ -0,0 +1,19 @@
+## Interface Mumble web
+
+Ce dossier contient les fichiers nécessaires pour lancer un serveur web facilitant l'accès au serveur Mumble que nous hébergeons.
+
+### Lancement
+
+Il suffit de lancer un `docker-compose up -d`.
+Il faudra veiller à ce qu'un serveur Mumble soit associé, voir configuration.
+
+### Configuration
+
+Voir [config.json](./config.json).
+
+Le serveur Mumble associé est configuré via la variable d'environnement `MUMBLE_SERVER` du fichier [docker-compose.yml](./docker-compose.yml).
+Il est préférable d'utiliser une URL qu'un nom de conteneur, pour permettre à l'interface web de tourner sur une machine différente du serveur Mumble.
+
+### Mise à jour
+
+La mise à jour se fait via le [Dockerfile](./Dockerfile). Puisqu'elle ne se base sur aucune version précise pour le moment, et même sur une branche modifiée pour utiliser un thème Framasoft, on veillera à créer un fichier `CHANGELOG.md` et à choisir un tag "maison" pour décrire les changements effectués.
diff --git a/pica-mumble-web/clair-whitelist.yml b/pica-mumble-web/clair-whitelist.yml
deleted file mode 100644
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..0000000000000000000000000000000000000000
diff --git a/pica-mumble-web/config.json b/pica-mumble-web/config.json
new file mode 100644
index 0000000000000000000000000000000000000000..43658d2fc1996bd70db8b673638b1d4d2647932a
--- /dev/null
+++ b/pica-mumble-web/config.json
@@ -0,0 +1,44 @@
+// Note: You probably do not want to change any values in here because this
+// file might need to be updated with new default values for new
+// configuration options. Use the [config.local.js] file instead!
+
+window.mumbleWebConfig = {
+ // Which fields to show on the Connect to Server dialog
+ 'connectDialog': {
+ 'address': false,
+ 'port': false,
+ 'token': false,
+ 'username': true,
+ 'password': false,
+ 'channelName': true
+ },
+ // Default values for user settings
+ // You can see your current value by typing `localStorage.getItem('mumble.$setting')` in the web console.
+ 'settings': {
+ 'voiceMode': 'ptt', // one of 'cont' (Continuous), 'ptt' (Push-to-Talk), 'vad' (Voice Activity Detection)
+ 'pttKey': 'ctrl + shift',
+ 'vadLevel': 0.3,
+ 'toolbarVertical': false,
+ 'showAvatars': 'always', // one of 'always', 'own_channel', 'linked_channel', 'minimal_only', 'never'
+ 'userCountInChannelName': false,
+ 'audioBitrate': 40000, // bits per second
+ 'samplesPerPacket': 960
+ },
+ // Default values (can be changed by passing a query parameter of the same name)
+ 'defaults': {
+ // Connect Dialog
+ 'address': window.location.hostname,
+ 'port': '443',
+ 'token': '',
+ 'username': '',
+ 'password': '',
+ 'joinDialog': false, // replace whole dialog with single "Join Conference" button
+ 'matrix': false, // enable Matrix Widget support (mostly auto-detected; implies 'joinDialog')
+ 'avatarurl': '', // download and set the user's Mumble avatar to the image at this URL
+ // General
+ 'theme': 'Framasoft',
+ 'easyMode': true
+ }
+}
+
+let config = window.mumbleWebConfig
diff --git a/pica-mumble-web/docker-compose.yml b/pica-mumble-web/docker-compose.yml
index 3c9b0eebb0da36c99f28f1022860037b8f3f5524..13e2bf9070627ebfbf5b6a3a3281002c0b53cc8f 100644
--- a/pica-mumble-web/docker-compose.yml
+++ b/pica-mumble-web/docker-compose.yml
@@ -7,13 +7,14 @@ networks:
services:
mumble-web:
image: registry.picasoft.net/pica-mumble-web:1.3.0
+ build: .
container_name: mumble-web
environment:
- MUMBLE_SERVER: "murmur:64738"
+ MUMBLE_SERVER: "voice.picasoft.net:64738"
networks:
- docker_default
volumes:
- - /DATA/docker/volumes/mumble-web/config.js:/home/node/dist/config.local.js
+ - ./config.js:/home/node/dist/config.local.js
labels:
- "traefik.frontend.rule=Host:voice.picasoft.net"
- "traefik.port=8080"
diff --git a/pica-murmur/README.md b/pica-murmur/README.md
index 94e274429f16a12b15ccbdbde70fe1b1d100d00e..388750cdf2af61273bd337a8aa98799b3f3a5c69 100644
--- a/pica-murmur/README.md
+++ b/pica-murmur/README.md
@@ -11,5 +11,11 @@ Some environment variables allow to configure Murmur at startup :
## Mounted volumes
Murmur store its server database and configuration files under `/data/` folder. You should mount this directory on your host.
+Also, Murmur uses a certificate generated by [TLS Certs Monitor](../pica-tls-certs-monitor) : the folder `/DATA/docker/certs/voice.picasoft.net` on the machine should contain the certificate. See the specific documentation.
+
## Network
Murmur is listening both TCP and UDP on port 64738. You should bind this container port to your host.
+
+## Update
+
+Update the version installed in the Dockerfile and the tag in Compose.
diff --git a/pica-murmur/clair-whitelist.yml b/pica-murmur/clair-whitelist.yml
deleted file mode 100644
index 82e705c5a9dda07792d93b2b24af4eb1e201b693..0000000000000000000000000000000000000000
--- a/pica-murmur/clair-whitelist.yml
+++ /dev/null
@@ -1,12 +0,0 @@
-generalwhitelist:
- CVE-2019-19816: On utilise pas btrfs
- CVE-2019-19814: On utilise pas f2fs
- CVE-2019-19074: ¯\_(ツ)_/¯
- CVE-2020-10543: ¯\_(ツ)_/¯
- CVE-2020-10878: ¯\_(ツ)_/¯
- CVE-2019-19813: On utilise pas btrfs
- CVE-2019-19815: On utilise pas f2fs
- CVE-2020-8492: ¯\_(ツ)_/¯
- CVE-2013-7445: ¯\_(ツ)_/¯
- CVE-2020-13974: DISPUTED
- CVE-2020-14155: ¯\_(ツ)_/¯
diff --git a/pica-murmur/docker-compose.yml b/pica-murmur/docker-compose.yml
index b05c0c11dccb70e3fc805157d8de3cca311dbd5e..d42e2cf8615d3c7c8e941b5cc11b9a9cb3b3f066 100644
--- a/pica-murmur/docker-compose.yml
+++ b/pica-murmur/docker-compose.yml
@@ -11,6 +11,7 @@ volumes:
services:
murmur:
image: registry.picasoft.net/pica-murmur:1.3.0
+ build: .
container_name: murmur
environment:
MAX_USERS: 2000
diff --git a/nextcloud-docker/13.0/Dockerfile b/pica-nextcloud/13.0/Dockerfile
similarity index 100%
rename from nextcloud-docker/13.0/Dockerfile
rename to pica-nextcloud/13.0/Dockerfile
diff --git a/nextcloud-docker/13.0/config/apache-pretty-urls.config.php b/pica-nextcloud/13.0/config/apache-pretty-urls.config.php
similarity index 100%
rename from nextcloud-docker/13.0/config/apache-pretty-urls.config.php
rename to pica-nextcloud/13.0/config/apache-pretty-urls.config.php
diff --git a/nextcloud-docker/13.0/config/apcu.config.php b/pica-nextcloud/13.0/config/apcu.config.php
similarity index 100%
rename from nextcloud-docker/13.0/config/apcu.config.php
rename to pica-nextcloud/13.0/config/apcu.config.php
diff --git a/nextcloud-docker/13.0/config/apps.config.php b/pica-nextcloud/13.0/config/apps.config.php
similarity index 100%
rename from nextcloud-docker/13.0/config/apps.config.php
rename to pica-nextcloud/13.0/config/apps.config.php
diff --git a/nextcloud-docker/13.0/config/autoconfig.php b/pica-nextcloud/13.0/config/autoconfig.php
similarity index 100%
rename from nextcloud-docker/13.0/config/autoconfig.php
rename to pica-nextcloud/13.0/config/autoconfig.php
diff --git a/nextcloud-docker/13.0/cron.sh b/pica-nextcloud/13.0/cron.sh
similarity index 100%
rename from nextcloud-docker/13.0/cron.sh
rename to pica-nextcloud/13.0/cron.sh
diff --git a/nextcloud-docker/13.0/entrypoint.sh b/pica-nextcloud/13.0/entrypoint.sh
similarity index 100%
rename from nextcloud-docker/13.0/entrypoint.sh
rename to pica-nextcloud/13.0/entrypoint.sh
diff --git a/nextcloud-docker/15.0/Dockerfile b/pica-nextcloud/15.0/Dockerfile
similarity index 100%
rename from nextcloud-docker/15.0/Dockerfile
rename to pica-nextcloud/15.0/Dockerfile
diff --git a/nextcloud-docker/15.0/config/apache-pretty-urls.config.php b/pica-nextcloud/15.0/config/apache-pretty-urls.config.php
similarity index 100%
rename from nextcloud-docker/15.0/config/apache-pretty-urls.config.php
rename to pica-nextcloud/15.0/config/apache-pretty-urls.config.php
diff --git a/nextcloud-docker/15.0/config/apcu.config.php b/pica-nextcloud/15.0/config/apcu.config.php
similarity index 100%
rename from nextcloud-docker/15.0/config/apcu.config.php
rename to pica-nextcloud/15.0/config/apcu.config.php
diff --git a/nextcloud-docker/15.0/config/apps.config.php b/pica-nextcloud/15.0/config/apps.config.php
similarity index 100%
rename from nextcloud-docker/15.0/config/apps.config.php
rename to pica-nextcloud/15.0/config/apps.config.php
diff --git a/nextcloud-docker/15.0/config/autoconfig.php b/pica-nextcloud/15.0/config/autoconfig.php
similarity index 100%
rename from nextcloud-docker/15.0/config/autoconfig.php
rename to pica-nextcloud/15.0/config/autoconfig.php
diff --git a/nextcloud-docker/15.0/config/redis.config.php b/pica-nextcloud/15.0/config/redis.config.php
similarity index 100%
rename from nextcloud-docker/15.0/config/redis.config.php
rename to pica-nextcloud/15.0/config/redis.config.php
diff --git a/nextcloud-docker/15.0/cron.sh b/pica-nextcloud/15.0/cron.sh
similarity index 100%
rename from nextcloud-docker/15.0/cron.sh
rename to pica-nextcloud/15.0/cron.sh
diff --git a/nextcloud-docker/15.0/entrypoint.sh b/pica-nextcloud/15.0/entrypoint.sh
similarity index 100%
rename from nextcloud-docker/15.0/entrypoint.sh
rename to pica-nextcloud/15.0/entrypoint.sh
diff --git a/nextcloud-docker/15.0/upgrade.exclude b/pica-nextcloud/15.0/upgrade.exclude
similarity index 100%
rename from nextcloud-docker/15.0/upgrade.exclude
rename to pica-nextcloud/15.0/upgrade.exclude
diff --git a/pica-nextcloud/README.md b/pica-nextcloud/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..a6aecadd2d0fd7feb3fde8dbc15a28a932f7703b
--- /dev/null
+++ b/pica-nextcloud/README.md
@@ -0,0 +1,56 @@
+## NextCloud
+
+Ce dossier contient les ressources nécessaires pour lancer une ou plusieurs instances NextCloud.
+
+Deux instances sont gérées : celle de Picasoft et celle de Compiègne en Transition.
+Celle de Picasoft utilise une image officielle ainsi que MySQL ; celle de CeT utilise une image construite par nos soins et une base PostgreSQL.
+
+### Lancement
+
+Pour l'instance de Compiègne en Transition :
+* Copier `cloudcet.secrets.example` dans `cloudcet.secrets` et remplacer les valeurs
+* Lancer `docker-compose -f docker-compose-cet.yml up -d`.
+
+Pour l'instance de Picasoft :
+* Copier `pica.secrets.example` dans `pica.secrets` et remplacer les valeurs
+* Lancer `docker-compose -f docker-compose-pica.yml up -d`.
+
+### Mise à jour
+
+Pour les prochaines mises à jour du cloud CeT, il est peut être plus pertinent de se baser sur l'image officielle.
+Dans ce cas, supprimer la directive `build` de Compose.
+
+Pour mettre à jour l'instance de Picasoft, il suffit de mettre à jour le tag de l'image de `nextcloud-app`.
+
+Attention : **toutes les mises à jour de version majeure doivent se faire une par une**.
+Exemple :
+* 15 -> 16, puis
+* 16 -> 17, puis
+* 17 -> 18.
+
+Sinon, il y a risque de casse.
+
+### Mise à jour de PostgreSQL (CeT)
+
+Il peut arriver que la version de PostgreSQL ne soit plus supportée par NextCloud.
+Sans en arriver là , il est bon de régulièrement mettre à jour PostgreSQL :
+> While upgrading will always contain some level of risk, PostgreSQL minor releases fix only frequently-encountered bugs, security issues, and data corruption problems to reduce the risk associated with upgrading. For minor releases, the community considers not upgrading to be riskier than upgrading. https://www.postgresql.org/support/versioning/
+
+Les mise à jours mineures (changement du Y de la version X.Y) peuvent se faire sans intervention humaine. On veillera à bien regarder les logs.
+
+En revanche, le passage d'une version majeure à une autre nécessitera une intervention manuelle.
+
+La documentation complète est ici : https://www.postgresql.org/docs/current/upgrading.html
+
+De manière générale, la façon la plus simple est de se rendre dans l'ancien conteneur, de réaliser un `pg_dumpall` et de le copier en lieu sûr (`docker cp`).
+Ensuite, on supprime l'ancien volume de base de données, on relance le nouveau conteneur de base de données (qui sera sans donnée), on monte le fichier de dump, et on lance un `psql -U <user> -d <db> -f <dump_file>` (valeurs de `user` et `db` à matcher avec le fichiers de secrets).
+
+On attend, et **si tout s'est bien passé**, on peut lancer le conteneur applicatif (NextCloud).
+
+### Mise à jour de MariaDB (Picasoft)
+
+[Selon la documentation](https://mariadb.com/kb/en/upgrading-between-major-mariadb-versions/) :
+
+> MariaDB is designed to allow easy upgrades. You should be able to trivially upgrade from ANY earlier MariaDB version to the latest one (for example MariaDB 5.5.x to MariaDB 10.5.x), usually in a few seconds.
+
+L'idée est d'éteindre le conteneur applicatif (NextCloud), puis de lancer la nouvelle version du conteneur, d'entrer dedans, de lancer la commande `mysql_upgrade` et de redémarrer le conteneur.
diff --git a/pica-nextcloud/docker-compose-cet.yml b/pica-nextcloud/docker-compose-cet.yml
new file mode 100644
index 0000000000000000000000000000000000000000..a778a77709b5a5eff54656d456318371d8e01733
--- /dev/null
+++ b/pica-nextcloud/docker-compose-cet.yml
@@ -0,0 +1,36 @@
+version: '3.7'
+# TODO switch to volumes
+networks:
+ docker_default:
+ name: docker_default:
+ cloud_cet:
+ name: cloud_cet
+
+services:
+ cloudcet:
+ build:
+ context: ./15.0
+ dockerfile: ./15.0/Dockerfile
+ container_name: cloudcet
+ image: registry.picasoft.net/nextcloud:15.0
+ labels:
+ - "traefik.frontend.rule=Host:cloudcet.picasoft.net"
+ - "traefik.port=80"
+ - "traefik.enable=true"
+ networks:
+ - docker_default
+ - cloud_cet
+ volumes:
+ - /DATA/docker/cet/nc:/var/www/html
+ depends_on:
+ - cloudcet_db
+ restart: unless-stopped
+
+ cloudcet_db:
+ container_name: cloudcet_db
+ image: postgres:9.6
+ volumes:
+ - /DATA/docker/cet/nc_db:/var/lib/postgresql/data
+ env_file:
+ - ./secrets/cloudcet.secrets
+ restart: unless-stopped
diff --git a/pica-nextcloud/docker-compose-pica.yml b/pica-nextcloud/docker-compose-pica.yml
new file mode 100644
index 0000000000000000000000000000000000000000..b50386a30f97ac10fdd36e3cebf97c2e568adc46
--- /dev/null
+++ b/pica-nextcloud/docker-compose-pica.yml
@@ -0,0 +1,58 @@
+version: '3.7'
+
+volumes:
+ nextcloud-db:
+ nextcloud:
+
+networks:
+ nextcloud:
+ docker_default:
+ name: docker_default
+
+services:
+ nextcloud-app:
+ image: nextcloud:17.0.1-fpm-alpine
+ container_name: nextcloud-app
+ restart: unless-stopped
+ volumes:
+ - nextcloud:/var/www/html
+ environment:
+ - MYSQL_HOST=nextcloud-db
+ env_file:
+ - /DATA/docker/secrets/nextcloud-db.secrets
+ depends_on:
+ - nextcloud-db
+ networks:
+ - nextcloud
+ restart: unless-stopped
+
+ nextcloud-web:
+ image: nginx:alpine
+ container_name: nextcloud-web
+ volumes:
+ - nextcloud:/var/www/html:ro
+ - ./nginx.conf:/etc/nginx/nginx.conf:ro
+ env_file: ./pica.secrets
+ depends_on:
+ - nextcloud-app
+ networks:
+ - nextcloud
+ - docker_default
+ labels:
+ - "traefik.frontend.rule=Host:cloud.picasoft.net"
+ - "traefik.port=80"
+ - "traefik.enable=true"
+ # https://docs.nextcloud.com/server/16/admin_manual/configuration_server/reverse_proxy_configuration.html
+ - "traefik.frontend.redirect.permanent=true"
+ - "traefik.frontend.redirect.regex=https://(.*)/.well-known/(card|cal)dav"
+ - "traefik.frontend.redirect.replacement=https://$$1/remote.php/dav/"
+ restart: unless-stopped
+
+ nextcloud-db:
+ image: mariadb:10.3.17
+ container_name: nextcloud-db
+ volumes:
+ - nextcloud-db:/var/lib/mysql
+ networks:
+ - nextcloud
+ env_file: ./pica.secrets
diff --git a/pica-nextcloud/nginx.conf b/pica-nextcloud/nginx.conf
new file mode 100644
index 0000000000000000000000000000000000000000..5ec547f771e2a3bee2d6757ec9fe96f1913dce4b
--- /dev/null
+++ b/pica-nextcloud/nginx.conf
@@ -0,0 +1,161 @@
+worker_processes auto;
+
+error_log /var/log/nginx/error.log warn;
+pid /var/run/nginx.pid;
+
+
+events {
+ worker_connections 1024;
+}
+
+
+http {
+ include /etc/nginx/mime.types;
+ default_type application/octet-stream;
+
+ log_format main '$remote_addr - $remote_user [$time_local] "$request" '
+ '$status $body_bytes_sent "$http_referer" '
+ '"$http_user_agent" "$http_x_forwarded_for"';
+
+ access_log /var/log/nginx/access.log main;
+
+ sendfile on;
+ #tcp_nopush on;
+
+ keepalive_timeout 65;
+
+ set_real_ip_from 10.0.0.0/8;
+ set_real_ip_from 172.16.0.0/12;
+ set_real_ip_from 192.168.0.0/16;
+ real_ip_header X-Real-IP;
+
+ #gzip on;
+
+ upstream php-handler {
+ server nextcloud-app:9000;
+ }
+
+ server {
+ listen 80;
+
+ # Add headers to serve security related headers
+ # Before enabling Strict-Transport-Security headers please read into this
+ # topic first.
+ add_header Strict-Transport-Security "max-age=15768000;
+ includeSubDomains";
+ #
+ # WARNING: Only add the preload option once you read about
+ # the consequences in https://hstspreload.org/. This option
+ # will add the domain to a hardcoded list that is shipped
+ # in all major browsers and getting removed from this list
+ # could take several months.
+ add_header X-Content-Type-Options nosniff;
+ add_header X-XSS-Protection "1; mode=block";
+ add_header X-Robots-Tag none;
+ add_header X-Download-Options noopen;
+ add_header X-Permitted-Cross-Domain-Policies none;
+ add_header Referrer-Policy no-referrer;
+
+ root /var/www/html;
+
+ location = /robots.txt {
+ allow all;
+ log_not_found off;
+ access_log off;
+ }
+
+ # The following 2 rules are only needed for the user_webfinger app.
+ # Uncomment it if you're planning to use this app.
+ #rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
+ #rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json
+ # last;
+
+ location = /.well-known/carddav {
+ return 301 $scheme://$host/remote.php/dav;
+ }
+ location = /.well-known/caldav {
+ return 301 $scheme://$host/remote.php/dav;
+ }
+
+ # set max upload size
+ client_max_body_size 10G;
+ fastcgi_buffers 64 4K;
+
+ # Enable gzip but do not remove ETag headers
+ gzip on;
+ gzip_vary on;
+ gzip_comp_level 4;
+ gzip_min_length 256;
+ gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
+ gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;
+
+ # Uncomment if your server is build with the ngx_pagespeed module
+ # This module is currently not supported.
+ #pagespeed off;
+
+ location / {
+ rewrite ^ /index.php$request_uri;
+ }
+
+ location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
+ deny all;
+ }
+ location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
+ deny all;
+ }
+
+ location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+)\.php(?:$|/) {
+ fastcgi_split_path_info ^(.+\.php)(/.*)$;
+ include fastcgi_params;
+ fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
+ fastcgi_param PATH_INFO $fastcgi_path_info;
+ # fastcgi_param HTTPS on;
+ #Avoid sending the security headers twice
+ fastcgi_param modHeadersAvailable true;
+ fastcgi_param front_controller_active true;
+ fastcgi_pass php-handler;
+ fastcgi_intercept_errors on;
+ fastcgi_request_buffering off;
+ }
+
+ location ~ ^/(?:updater|ocs-provider)(?:$|/) {
+ try_files $uri/ =404;
+ index index.php;
+ }
+
+ # Adding the cache control header for js and css files
+ # Make sure it is BELOW the PHP block
+ location ~ \.(?:css|js|woff2?|svg|gif)$ {
+ try_files $uri /index.php$request_uri;
+ add_header Cache-Control "public, max-age=15778463";
+ # Add headers to serve security related headers (It is intended to
+ # have those duplicated to the ones above)
+ # Before enabling Strict-Transport-Security headers please read into
+ # this topic first.
+ add_header Strict-Transport-Security "max-age=15768000;
+ includeSubDomains";
+ #
+ # WARNING: Only add the preload option once you read about
+ # the consequences in https://hstspreload.org/. This option
+ # will add the domain to a hardcoded list that is shipped
+ # in all major browsers and getting removed from this list
+ # could take several months.
+ add_header X-Content-Type-Options nosniff;
+ add_header X-XSS-Protection "1; mode=block";
+ add_header X-Robots-Tag none;
+ add_header X-Download-Options noopen;
+ add_header X-Permitted-Cross-Domain-Policies none;
+ add_header Referrer-Policy no-referrer;
+
+ # Optional: Don't log access to assets
+ access_log off;
+ }
+
+ location ~ \.(?:png|html|ttf|ico|jpg|jpeg)$ {
+ try_files $uri /index.php$request_uri;
+ # Optional: Don't log access to other assets
+ access_log off;
+ }
+ }
+
+}
diff --git a/pica-nextcloud/secrets/cloudcet.secrets.example b/pica-nextcloud/secrets/cloudcet.secrets.example
new file mode 100644
index 0000000000000000000000000000000000000000..80481752f22bbf67c8761d5d201ef558515d2144
--- /dev/null
+++ b/pica-nextcloud/secrets/cloudcet.secrets.example
@@ -0,0 +1,5 @@
+POSTGRES_USER=user
+POSTGRES_PASSWORD=password
+POSTGRES_DB=compi_en_trans
+NEXTCLOUD_ADMIN_USER=admin
+NEXTCLOUD_ADMIN_PASSWORD=password
diff --git a/pica-nextcloud/secrets/pica.secrets.example b/pica-nextcloud/secrets/pica.secrets.example
new file mode 100644
index 0000000000000000000000000000000000000000..f50e98165e3d294e24c60f9d716b565be40d026e
--- /dev/null
+++ b/pica-nextcloud/secrets/pica.secrets.example
@@ -0,0 +1,4 @@
+MYSQL_ROOT_PASSWORD=password
+MYSQL_DATABASE=nextcloud
+MYSQL_USER=nextcloud
+MYSQL_PASSWORD=password
diff --git a/pica-nginx/README.md b/pica-nginx/README.md
index 0a5db6ca26ea89c35baec84cd7ab3946ff137b32..3546fe5ffca6a5290ba2087df751f8fe8ab6f149 100644
--- a/pica-nginx/README.md
+++ b/pica-nginx/README.md
@@ -1,55 +1,48 @@
# pica-nginx
-Ce dossier contient une image NGINX maintenue par l'association.
+Ce dossier contient une image Nginx maintenue par l'association.
L'image est basée sur `debian:stretch`, mais n'est pas encore au point (cf. [cette carte](https://kanban.picasoft.net/b/7fCn765LCNGraBhxA/team-technique-picasoft/pgtqebNDqsBMSj6ke)).
Elle sert de base à tous les sites web simples hébergés par Picasoft (ex: `www`, `school`, `radio`...)
+Le fichier `docker-compose.yml` associé permet de lancer tous les conteneurs des sites, sans contenu (il faudra le copier ultérieurement, avec un `docker cp` par exemple).
+
+## Lancement
+
+Si tous les sites sont lancés sur la même machine, un simple `docker-compose up -d` suffira.
+
+Autrement, il faudra préciser à `docker-compose` le nom des services à lancer.
+
+## Mise à jour de l'image
+
+Mettre à jour le Dockerfile si besoin, puis changer la clé sous `x-image-name: &NGINX_IMAGE` dans le fichier `docker-compose.yml` en indiquant la date du jour.
+
+Par exemple, `registry.picasoft.net/pica-nginx:stretch-20200323` deviendra `registry.picasoft.net/pica-nginx:stretch-20200714` si je mets à jour l'image le 14 juillet 2020.
+
+Relancer les sites sur la machine de production.
+
## Ajouter un nouveau site
-Exemple de `docker-compose.yml`
+Exemple d'ajout sous la directive `services` de Compose :
```
-version: "3.7"
-
-volumes:
- mon_site:
-
-networks:
- docker_default:
- external: true
- name: "docker_default"
-
-services:
- mon_site:
- container_name: mon_site
- image: registry.picasoft.net/pica-nginx:stretch-20190915
- volumes:
- - mon_site:/var/www/html
- labels:
- - "traefik.frontend.rule=Host:test01.test.picasoft.net"
- - "traefik.port=80"
- - "traefik.enable=true"
- environment:
- - AUTOINDEX=true
- restart: always
- networks:
- - docker_default
+mon_site:
+ container_name: mon_site
+ image: *NGINX_IMAGE
+ volumes:
+ - mon_site:/var/www/html
+ labels:
+ - "traefik.frontend.rule=Host:mon_site.picasoft.net"
+ - "traefik.port=80"
+ - "traefik.enable=true"
+ environment:
+ - AUTOINDEX=true
+ restart: always
+ networks:
+ - docker_default
```
## Environnement
La variable d'environnement `AUTOINDEX`, losrqu'elle a pour valeur `true`, permet d'activer l'affichage des répertoires et leur contenu (en ajoutant `autoindex on;` à `/etc/nginx/nginx.conf` - [plus d'infos](https://nixcp.com/nginx-autoindex/))
-
-
-## Mise à jour de l'image
-
-1. Cloner ce repo
-1. Construire l'image (sur `pica01-test` par exemple): \
- `docker build -t registry.picasoft.net/pica-nginx:20190915 <repo_cloné>/pica-nginx/` \
- Ne pas oublier d'indiquer la date du jour dans le tag
-1. `docker push registry.picasoft.net/pica-nginx:20190915`
-1. Sur la machine cîble: \
- `docker pull registry.picasoft.net/pica-nginx:20190915`
-1. Mettre à jour le `docker-compose.yml`
diff --git a/noCI-websites/docker-compose.yml b/pica-nginx/docker-compose.yml
similarity index 81%
rename from noCI-websites/docker-compose.yml
rename to pica-nginx/docker-compose.yml
index 35bade6bc2c421f53b85607722e5b755cd7c9951..d15ce79a6693b82db2d895adbb2111138eecfe7b 100644
--- a/noCI-websites/docker-compose.yml
+++ b/pica-nginx/docker-compose.yml
@@ -2,22 +2,25 @@ version: "3.7"
volumes:
website:
- external: true
+ name: website
doc:
- external: true
+ name: doc
school:
- external: true
+ name: school
radio:
- external: true
+ name: radio
culture:
- external: true
+ name: culture
stiegler:
- external: true
+ name: stiegler
networks:
docker_default:
external: true
+x-image-name: &NGINX_IMAGE
+ registry.picasoft.net/pica-nginx:stretch-20200323
+
services:
####################
@@ -26,7 +29,8 @@ services:
website:
container_name: website
- image: registry.picasoft.net/pica-nginx:stretch-20200323
+ image: *NGINX_IMAGE
+ build: .
volumes:
- website:/var/www/html
labels:
@@ -44,7 +48,8 @@ services:
doc:
container_name: doc
- image: registry.picasoft.net/pica-nginx:stretch-20200323
+ image: *NGINX_IMAGE
+ build: .
volumes:
- doc:/var/www/html
labels:
@@ -62,7 +67,8 @@ services:
school:
container_name: school
- image: registry.picasoft.net/pica-nginx:stretch-20200323
+ image: *NGINX_IMAGE
+ build: .
volumes:
- school:/var/www/html
labels:
@@ -80,7 +86,8 @@ services:
radio:
container_name: radio
- image: registry.picasoft.net/pica-nginx:stretch-20200323
+ image: *NGINX_IMAGE
+ build: .
volumes:
- radio:/var/www/html
labels:
@@ -98,7 +105,8 @@ services:
culture:
container_name: culture
- image: registry.picasoft.net/pica-nginx:stretch-20200323
+ image: *NGINX_IMAGE
+ build: .
volumes:
- culture:/var/www/html
labels:
@@ -118,7 +126,8 @@ services:
stiegler:
container_name: stiegler
- image: registry.picasoft.net/pica-nginx:stretch-20200323
+ image: *NGINX_IMAGE
+ build: .
volumes:
- stiegler:/var/www/html
labels:
diff --git a/pica-plume/README.md b/pica-plume/README.md
index 1c2270aa65f79616f7277b3e61863af484e2d328..d8092cbddedd9d5cceb4bd37917cfc843d2861e3 100644
--- a/pica-plume/README.md
+++ b/pica-plume/README.md
@@ -16,10 +16,6 @@ En plus, nous ajoutons :
Mettre à jour `VERSION` **et** `PLUME_VERSION` dans le [Dockerfile](./Dockerfile) et ajuster le tag de l'image construite dans le [docker-compose.yml](./docker-compose.yml)
-Vérifier que les vulnérabilités de [clair-whitelist.yml](./clair-whitelist.yml) n'ont toujours pas de contre-mesures, sinon appliquez les contre mesures (une mise à jour peut tout à faire résoudre le problème, dans ce cas pensez à enlever les vulnérabilités).
-
-**Attention : vérifier le passage de [l'image de base](https://github.com/Plume-org/Plume/blob/master/Dockerfile) à Debian Buster** : quand ce sera fait, le nombre de CVE diminuera très fortement.
-
### Configuration et lancement
Copier le fichier `plume.secrets.example` dans `plume.secrets` et `plume_db.secrets.example` dans `plume_db.secrets` et remplacez les valeurs par des mots de passe de production.
diff --git a/pica-plume/clair-whitelist.yml b/pica-plume/clair-whitelist.yml
deleted file mode 100644
index 4b0c60a8797a6f53b9bd5ccec2e2c17d09dd1bd8..0000000000000000000000000000000000000000
--- a/pica-plume/clair-whitelist.yml
+++ /dev/null
@@ -1,14 +0,0 @@
-generalwhitelist:
- CVE-2017-14062: libidn -> Selon Debian c'est fixed dans cette version.
- CVE-2019-12900: bzip2 -> Pas exploitable, d'après les notes dans le tracker de Debian. Une nouvelle version du paquet fix, peut-être le mettre à jour un jour.
- CVE-2018-6485: glibc -> Debian dit "Minor issue"
- CVE-2017-12424: shadow -> Idem
- CVE-2019-9169: glibc -> Idem
- CVE-2018-1000001: glibc -> Idem
- CVE-2016-2779: util-linux -> Idem
- CVE-2019-8457: sqlite3 -> dépendance du client PG utilisé uniquement dans l'entrypoint
- CVE-2020-8492: python3.5 -> dépendance du client PG utilisé uniquement dans l'entrypoint
- CVE-2020-13630: sqlite3 -> dépendance du client PG utilisé uniquement dans l'entrypoint
- CVE-2020-10543: perl -> trop de paquets en dépendent, pas de contre mesures
- CVE-2020-10878: perl -> trop de paquets en dépendent, pas de contre mesures
- CVE-2020-14155: pcre3 -> pas de contre-mesure
diff --git a/pica-plume/docker-compose.yml b/pica-plume/docker-compose.yml
index ea6361b55bdfb9ec44719ebcc3989d7a5995fa31..cce72fbf10f44658eeae490517540b0ce43c05be 100644
--- a/pica-plume/docker-compose.yml
+++ b/pica-plume/docker-compose.yml
@@ -19,6 +19,7 @@ networks:
services:
blog:
image: registry.picasoft.net/pica-plume:0.5.0
+ build: .
container_name: blog
env_file:
- ./secrets/plume_db.secrets
diff --git a/pica-registry/README.md b/pica-registry/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..bee49d7d70a7b74747bde4d7c5c13e78c935e98d
--- /dev/null
+++ b/pica-registry/README.md
@@ -0,0 +1,25 @@
+## Registre Docker
+
+Ce dossier contient les ressources nécessaires pour lancer un registre Docker privé.
+Ce registre sert à stocker l'ensemble des images Docker construites par Picasoft.
+
+Il est accessible via HTTPS, donc par Traefik, et ne nécessite donc pas la création manuelle de certificats.
+
+### Configuration
+
+Les utilisateurs autorisés à accéder au registre sont configurés dans le fichier `auth`.
+Le format est le suivant : un utilisateur par ligne, `<user>:<encrypted_password>`.
+
+Pour plus de facilité, on peut lancer la commande suivante pour créer un nouvel utilisateur :
+```bash
+docker run --entrypoint htpasswd registry:2 -Bbn pica password >> ./auth
+```
+
+En remplaçant `pica` et `password` par les valeurs souhaitées.
+Tous les identifiants doivent être renseigné dans le [pass](https://gitlab.utc.fr/picasoft/interne/pass).
+
+Le reste de la configuration se fait essentiellement par l'environnement dans [Compose](./docker-compose.yml), et ne devrait pas avoir à être modifié.
+
+### Mise à jour
+
+Il suffit de changer le tag dans [Compose](./docker-compose.yml). En cas de mise à jour majeure (2 -> 3), regarder les instructions correspondantes sur le [Docker Hub](https://hub.docker.com/_/registry/).
diff --git a/pica-registry/auth.example b/pica-registry/auth.example
new file mode 100644
index 0000000000000000000000000000000000000000..93fd9cde491e77394ea8971eaef6b86f0785c7a9
--- /dev/null
+++ b/pica-registry/auth.example
@@ -0,0 +1 @@
+pica:<encrypted_password>
diff --git a/meta-registry-test/docker-compose.yml b/pica-registry/docker-compose.yml
similarity index 52%
rename from meta-registry-test/docker-compose.yml
rename to pica-registry/docker-compose.yml
index c3ae73e74d291f2ecb0fa7dbaa62e7f6ef40fb76..a8c9bd7e4da30a0ba48867bc29fd824a3cca7700 100644
--- a/meta-registry-test/docker-compose.yml
+++ b/pica-registry/docker-compose.yml
@@ -1,30 +1,27 @@
-version: "3.7"
-
-volumes:
- registry-data:
- name: "registry-data"
+version: '3.7'
networks:
docker_default:
- external: true
+ name: docker_default
+
+volumes:
+ registry:
+ name: registry
services:
registry:
- container_name: registry
restart: always
- image: registry.test.picasoft.net/meta-registry-test:0.1
+ image: registry:2
+ container_name: registry
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
+ - registry:/var/lib/registry
+ - ./auth:/auth
labels:
- - "traefik.frontend.rule=Host:registry.test.picasoft.net"
+ - "traefik.frontend.rule=Host:registry.picasoft.net"
- "traefik.port=5000"
- "traefik.enable=true"
- networks:
- - docker_default
diff --git a/pica-tls-certs-monitor/README.md b/pica-tls-certs-monitor/README.md
index 57c0f9aeaf60efc8dbe7a4c3ef1af0dbf15d3eb9..f3b24d6347e7278e4650552eceaafe63e412d9a5 100644
--- a/pica-tls-certs-monitor/README.md
+++ b/pica-tls-certs-monitor/README.md
@@ -28,4 +28,4 @@ On a choisi une bonne fois pour toutes `/DATA/docker/certs` comme dossier de sto
## Mise à jour
-Il suffit de mettre à jour la variable d'environnement `TLS_CERTS_MONITOR_VERSION` dans le Dockerfile, quand une nouvelle release (tag) apparaît sur le dépôt.
+Il suffit de mettre à jour la variable d'environnement `TLS_CERTS_MONITOR_VERSION` dans le Dockerfile, quand une nouvelle release (tag) apparaît sur le dépôt, ainsi que le numéro de version de l'image dans Compose.
diff --git a/pica-tls-certs-monitor/clair-whitelist.yml b/pica-tls-certs-monitor/clair-whitelist.yml
deleted file mode 100644
index a9d6ed5bdae04856ade1de9572cbdfee041aa4b9..0000000000000000000000000000000000000000
--- a/pica-tls-certs-monitor/clair-whitelist.yml
+++ /dev/null
@@ -1 +0,0 @@
-generalwhitelist:
diff --git a/pica-tls-certs-monitor/docker-compose.yml b/pica-tls-certs-monitor/docker-compose.yml
index 63f9ed8fe32f25fb20a53b41079d6e6337d9aa8b..ea8331e9fc7119324edfcbed490377429455b82e 100644
--- a/pica-tls-certs-monitor/docker-compose.yml
+++ b/pica-tls-certs-monitor/docker-compose.yml
@@ -3,6 +3,7 @@ version: '3.7'
services:
tls-certs-monitor:
image: registry.picasoft.net/pica-tls-certs-monitor:v1.5
+ build: .
container_name: tls-certs-monitor
volumes:
- /DATA/docker/traefik/certs/acme.json:/certs/acme.json
diff --git a/pica-traefik/README.md b/pica-traefik/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..0544aa4a2f67adb20a15621f8056acdc35e103ce
--- /dev/null
+++ b/pica-traefik/README.md
@@ -0,0 +1,42 @@
+## Traefik
+
+Ce dossier contient les ressources nécessaires pour lancer Traefik, un reverse proxy adapté pour Docker.
+C'est la pièce la plus importante de l'infrastructure, puisque l'ensemble des communications HTTP(S) passent d'abord par Traefik, et il est aussi utilisé pour [générer des certificats pour les services TCP](../pica-tls-certs-monitor).
+
+Ce service doit être lancé sur l'ensemble des machines de l'infrastructure.
+
+### Configuration
+
+La configuration a lieu dans le fichier [traefik.toml](./traefik.toml).
+Notez que toute modification dans ce fichier impactera l'ensemble des machines, puisque le même fichier est utilisé pour l'ensemble des machines.
+
+À des fins de tests, il peut être modifié localement sur les machines, mais doit toujours rester synchronisé avec ce dépôt à long terme.
+
+Pour la génération des certificats, Traefik utilise Let's Encrypt. Il n'y a aucune configuration à faire de ce côté. Attention, le nombre de certificats générables est limité à 50 par semaine.
+
+Si on lance plein de conteneurs de tests, on utilisera temporairement [l'environnement de qualification](https://letsencrypt.org/fr/docs/staging-environment/) de Let's Encrypt, en ajoutant la directive `caServer = "https://acme-staging-v02.api.letsencrypt.org/directory"` sous la section `[acme]`.
+
+### Lancement
+
+Assurez-vous que le dossier `/DATA/docker/traefik/certs` existe.
+C'est dans ce dossier que seront conservés tous les certificats générés par Traefik.
+
+### Mise à jour
+
+Il suffit de mettre à jour le tag de l'image dans Compose.
+Attention, Traefik v2 introduit énormément de changements et [nous ne sommes pas certains](https://wiki.picasoft.net/doku.php?id=technique:adminsys:migration-traefik-v2) de la manière d'effectuer la migration.
+
+Aussi, Traefik v1.6 est utilisé pour tenterd d'éviter un bug introduit dans la 1.7, qui rend certains services redémarrés inaccessibles (voir [cette discussion](https://team.picasoft.net/picasoft/pl/66aorsxhtffrjytyhnecn436wa)).
+
+Avant toute mise à jour, il faudra discuter avec l'équipe technique et modifier ce README le cas échéant.
+
+### Todo
+
+*Voir si on peut passer Traefik en "host" au niveau du réseau pour qu'il ait accès à tous les réseaux* :
+https://kanban.picasoft.net/b/7fCn765LCNGraBhxA/team-technique-picasoft/kjvc3iw2pFvszCTcR
+
+Actuellement, Traefik est dans le réseau `docker_default` sur toutes les machines, et les conteneurs souhaitant être accessibles via Traefik doivent être explicitement dans ce réseau.
+
+Ceci induit une complexité supplémentaire au niveau des fichiers Compose.
+
+Il serait peut être bon de permettre à Traefik d'accéder à tous les réseaux et de supprimer énormément de directives "inutiles" dans les Compose.
diff --git a/pica-traefik/docker-compose.yml b/pica-traefik/docker-compose.yml
new file mode 100644
index 0000000000000000000000000000000000000000..daaf9802d24f03b53766fa67ec286b8a2a18522f
--- /dev/null
+++ b/pica-traefik/docker-compose.yml
@@ -0,0 +1,18 @@
+version: '3.7'
+
+services:
+ traefik:
+ container_name: traefik
+ # DO NOT UPGRADE
+ # SEE THIS BEFORE AND DISCUSS : https://team.picasoft.net/picasoft/pl/66aorsxhtffrjytyhnecn436wa
+ image: traefik:1.6.6
+ ports:
+ - "80:80"
+ # Uncomment to expose the web interface. Warning : do not use without setting a password in traefik.toml
+ #- "8080:8080"
+ - "443:443"
+ volumes:
+ - /var/run/docker.sock:/var/run/docker.sock
+ - ./traefik.toml:/traefik.toml
+ - /DATA/docker/traefik/certs:/certs
+ restart: always
diff --git a/pica-traefik/traefik.toml b/pica-traefik/traefik.toml
new file mode 100644
index 0000000000000000000000000000000000000000..351461989e113a1faf7e831ca614f1a7922cfd56
--- /dev/null
+++ b/pica-traefik/traefik.toml
@@ -0,0 +1,35 @@
+logLevel = "INFO"
+debug = true
+defaultEntryPoints = ["http", "https"]
+
+[docker]
+endpoint = "unix:///var/run/docker.sock"
+watch = true
+exposedbydefault = false
+
+[api]
+
+[entryPoints]
+ [entryPoints.http]
+ address = ":80"
+ compress = false
+ [entryPoints.http.redirect]
+ entryPoint = "https"
+ [entryPoints.https]
+ address = ":443"
+ compress = false
+ [entryPoints.https.tls]
+ # Accept only TLS1.1 and 1.2
+ MinVersion = "VersionTLS11"
+ # Accept all ciphers excepting TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA and TLS_RSA_WITH_3DES_EDE_CBC_SHA
+ # CipherSuites = ["TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA","TLS_RSA_WITH_AES_128_GCM_SHA256","TLS_RSA_WITH_AES_256_GCM_SHA384","TLS_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_256_CBC_SHA" ]
+ # Keep only ECDHE :
+ CipherSuites = ["TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA" ]
+
+[acme]
+ email = "picasoft@assos.utc.fr"
+ storage = "/certs/acme.json"
+ entryPoint = "https"
+ onHostRule = true
+ [acme.httpChallenge]
+ entryPoint = "http"
diff --git a/pica-uploads/README.md b/pica-uploads/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..b4b797cb5fd89fa775f5b3b66e5bc7246fbd8ec5
--- /dev/null
+++ b/pica-uploads/README.md
@@ -0,0 +1,35 @@
+## Serveur SFTP et serveur web associé
+
+Ce dossier contient les fichiers nécessaires pour faire tourner le serveur SFTP de chez Picasoft ainsi qu'un serveur web permettant d'accéder aux fichiers.
+
+Il se base sur des images pré-construites et ne nécessite pas de construction manuelle d'image.
+
+### Principe
+
+Le Compose fournit permet de lancer deux services :
+* Un serveur SFTP
+* Un serveur web
+
+Ces deux services accèdent au même volume Docker. Le serveur web sert le contenu du volume, tandis que le serveur SFTP écrit dans le volume.
+
+Ce mécanisme permet de rendre immédiatement disponibles tous les fichiers uploadées via SFTP via le serveur web.
+
+### Configuration
+
+Le fichier de secrets contient la configuration nécessaire pour créer les utilisateurs autorisés à téléverser des fichiers sur le serveur SFTP.
+
+La syntaxe utilisée [est documentée ici](https://hub.docker.com/r/atmoz/sftp/).
+
+Notez que l'UID indiqué doit être celui de l'utilisateur `www-data` du serveur web, puisqu'il doit pouvoir accéder à ces fichiers. Le GID utilisé est celui du groupe `docker` de l'hôte, mais ce n'est pas un pré-requis.
+
+### Lancement
+
+Il suffit de copier le fichier `sftp.secrets.example` dans `sftp.secrets` et de choisir un mot de passe. Plusieurs utilisateurs peuvent être créés. Ce mot de passe doit être renseigné dans le [pass](https://gitlab.utc.fr/picasoft/interne/pass).
+
+### Mise à jour
+
+Il suffit de mettre à jour les tags des images utilisées dans le Docker Compose, de pousser les modifications sur ce dépôt et de relancer les nouveaux conteneurs.
+
+### Utilisation
+
+Voir la documentation utilisateur ici : https://wiki.picasoft.net/doku.php?id=technique:adminsys:sftp
diff --git a/noCI-uploads/docker-compose.yml b/pica-uploads/docker-compose.yml
similarity index 100%
rename from noCI-uploads/docker-compose.yml
rename to pica-uploads/docker-compose.yml
diff --git a/noCI-uploads/secrets/sftp.secrets.example b/pica-uploads/secrets/sftp.secrets.example
similarity index 100%
rename from noCI-uploads/secrets/sftp.secrets.example
rename to pica-uploads/secrets/sftp.secrets.example
diff --git a/pica-wekan/Dockerfile b/pica-wekan/Dockerfile
deleted file mode 100644
index b0d69e341ddbddc1639070394237727caa53238c..0000000000000000000000000000000000000000
--- a/pica-wekan/Dockerfile
+++ /dev/null
@@ -1,261 +0,0 @@
-FROM ubuntu:disco
-LABEL maintainer="wekan"
-
-# Set the environment variables (defaults where required)
-# DOES NOT WORK: paxctl fix for alpine linux: https://github.com/wekan/wekan/issues/1303
-# ENV BUILD_DEPS="paxctl"
-ENV BUILD_DEPS="apt-utils bsdtar gnupg gosu wget curl bzip2 build-essential python3 python3-pip git ca-certificates gcc-8" \
- DEBUG=false \
- NODE_VERSION=v8.16.0 \
- METEOR_RELEASE=1.6.0.1 \
- USE_EDGE=false \
- METEOR_EDGE=1.5-beta.17 \
- NPM_VERSION=latest \
- FIBERS_VERSION=2.0.0 \
- ARCHITECTURE=linux-x64 \
- SRC_PATH=./ \
- WITH_API=true \
- ACCOUNTS_LOCKOUT_KNOWN_USERS_FAILURES_BEFORE=3 \
- ACCOUNTS_LOCKOUT_KNOWN_USERS_PERIOD=60 \
- ACCOUNTS_LOCKOUT_KNOWN_USERS_FAILURE_WINDOW=15 \
- ACCOUNTS_LOCKOUT_UNKNOWN_USERS_FAILURES_BERORE=3 \
- ACCOUNTS_LOCKOUT_UNKNOWN_USERS_LOCKOUT_PERIOD=60 \
- ACCOUNTS_LOCKOUT_UNKNOWN_USERS_FAILURE_WINDOW=15 \
- EMAIL_NOTIFICATION_TIMEOUT=30000 \
- MATOMO_ADDRESS="" \
- MATOMO_SITE_ID="" \
- MATOMO_DO_NOT_TRACK=true \
- MATOMO_WITH_USERNAME=false \
- BROWSER_POLICY_ENABLED=true \
- TRUSTED_URL="" \
- WEBHOOKS_ATTRIBUTES="" \
- OAUTH2_ENABLED=false \
- OAUTH2_LOGIN_STYLE=redirect \
- OAUTH2_CLIENT_ID="" \
- OAUTH2_SECRET="" \
- OAUTH2_SERVER_URL="" \
- OAUTH2_AUTH_ENDPOINT="" \
- OAUTH2_USERINFO_ENDPOINT="" \
- OAUTH2_TOKEN_ENDPOINT="" \
- OAUTH2_ID_MAP="" \
- OAUTH2_USERNAME_MAP="" \
- OAUTH2_FULLNAME_MAP="" \
- OAUTH2_ID_TOKEN_WHITELIST_FIELDS=[] \
- OAUTH2_REQUEST_PERMISSIONS=['openid','profiles','email'] \
- OAUTH2_EMAIL_MAP="" \
- LDAP_ENABLE=false \
- LDAP_PORT=389 \
- LDAP_HOST="" \
- LDAP_BASEDN="" \
- LDAP_LOGIN_FALLBACK=false \
- LDAP_RECONNECT=true \
- LDAP_TIMEOUT=10000 \
- LDAP_IDLE_TIMEOUT=10000 \
- LDAP_CONNECT_TIMEOUT=10000 \
- LDAP_AUTHENTIFICATION=false \
- LDAP_AUTHENTIFICATION_USERDN="" \
- LDAP_AUTHENTIFICATION_PASSWORD="" \
- LDAP_LOG_ENABLED=false \
- LDAP_BACKGROUND_SYNC=false \
- LDAP_BACKGROUND_SYNC_INTERVAL=100 \
- LDAP_BACKGROUND_SYNC_KEEP_EXISTANT_USERS_UPDATED=false \
- LDAP_BACKGROUND_SYNC_IMPORT_NEW_USERS=false \
- LDAP_ENCRYPTION=false \
- LDAP_CA_CERT="" \
- LDAP_REJECT_UNAUTHORIZED=false \
- LDAP_USER_AUTHENTICATION=false \
- LDAP_USER_SEARCH_FILTER="" \
- LDAP_USER_SEARCH_SCOPE="" \
- LDAP_USER_SEARCH_FIELD="" \
- LDAP_SEARCH_PAGE_SIZE=0 \
- LDAP_SEARCH_SIZE_LIMIT=0 \
- LDAP_GROUP_FILTER_ENABLE=false \
- LDAP_GROUP_FILTER_OBJECTCLASS="" \
- LDAP_GROUP_FILTER_GROUP_ID_ATTRIBUTE="" \
- LDAP_GROUP_FILTER_GROUP_MEMBER_ATTRIBUTE="" \
- LDAP_GROUP_FILTER_GROUP_MEMBER_FORMAT="" \
- LDAP_GROUP_FILTER_GROUP_NAME="" \
- LDAP_UNIQUE_IDENTIFIER_FIELD="" \
- LDAP_UTF8_NAMES_SLUGIFY=true \
- LDAP_USERNAME_FIELD="" \
- LDAP_FULLNAME_FIELD="" \
- LDAP_MERGE_EXISTING_USERS=false \
- LDAP_EMAIL_FIELD="" \
- LDAP_EMAIL_MATCH_ENABLE=false \
- LDAP_EMAIL_MATCH_REQUIRE=false \
- LDAP_EMAIL_MATCH_VERIFIED=false \
- LDAP_SYNC_USER_DATA=false \
- LDAP_SYNC_USER_DATA_FIELDMAP="" \
- LDAP_SYNC_GROUP_ROLES="" \
- LDAP_DEFAULT_DOMAIN="" \
- LDAP_SYNC_ADMIN_STATUS="" \
- LDAP_SYNC_ADMIN_GROUPS="" \
- HEADER_LOGIN_ID="" \
- HEADER_LOGIN_FIRSTNAME="" \
- HEADER_LOGIN_LASTNAME="" \
- HEADER_LOGIN_EMAIL="" \
- LOGOUT_WITH_TIMER=false \
- LOGOUT_IN="" \
- LOGOUT_ON_HOURS="" \
- LOGOUT_ON_MINUTES="" \
- CORS="" \
- DEFAULT_AUTHENTICATION_METHOD=""
-
-RUN set -o xtrace && \
- apt-get update -y && apt-get install -y --no-install-recommends ${BUILD_DEPS} && \
- pip3 install -U pip setuptools wheel
-
-RUN git clone https://github.com/wekan/wekan && cd wekan && git checkout v2.75 && cd .. && mkdir /home/wekan && cp -r ./wekan /home/wekan/app && \
- useradd --user-group --system --home-dir /home/wekan wekan
-
- # Meteor installer doesn't work with the default tar binary, so using bsdtar while installing.
- # https://github.com/coreos/bugs/issues/1095#issuecomment-350574389
-RUN cp $(which tar) $(which tar)~ && \
- ln -sf $(which bsdtar) $(which tar) && \
- \
- # Download nodejs
- wget https://nodejs.org/dist/${NODE_VERSION}/node-${NODE_VERSION}-${ARCHITECTURE}.tar.gz && \
- wget https://nodejs.org/dist/${NODE_VERSION}/SHASUMS256.txt.asc && \
- #---------------------------------------------------------------------------------------------
- # Node Fibers 100% CPU usage issue:
- # https://github.com/wekan/wekan-mongodb/issues/2#issuecomment-381453161
- # https://github.com/meteor/meteor/issues/9796#issuecomment-381676326
- # https://github.com/sandstorm-io/sandstorm/blob/0f1fec013fe7208ed0fd97eb88b31b77e3c61f42/shell/server/00-startup.js#L99-L129
- # Also see beginning of wekan/server/authentication.js
- # import Fiber from "fibers";
- # Fiber.poolSize = 1e9;
- # OLD: Download node version 8.12.0 prerelease that has fix included, => Official 8.12.0 has been released
- # Description at https://releases.wekan.team/node.txt
- #wget https://releases.wekan.team/node-${NODE_VERSION}-${ARCHITECTURE}.tar.gz && \
- #echo "1ed54adb8497ad8967075a0b5d03dd5d0a502be43d4a4d84e5af489c613d7795 node-v8.12.0-linux-x64.tar.gz" >> SHASUMS256.txt.asc && \
- \
- # Verify nodejs authenticity
- grep ${NODE_VERSION}-${ARCHITECTURE}.tar.gz SHASUMS256.txt.asc | shasum -a 256 -c - && \
- #export GNUPGHOME="$(mktemp -d)" && \
- #\
- # Try other key servers if ha.pool.sks-keyservers.net is unreachable
- # Code from https://github.com/chorrell/docker-node/commit/2b673e17547c34f17f24553db02beefbac98d23c
- # gpg keys listed at https://github.com/nodejs/node#release-team
- # and keys listed here from previous version of this Dockerfile
- #for key in \
- #9554F04D7259F04124DE6B476D5A82AC7E37093B \
- #94AE36675C464D64BAFA68DD7434390BDBE9B9C5 \
- #FD3A5288F042B6850C66B31F09FE44734EB7990E \
- #71DCFD284A79C3B38668286BC97EC7A07EDE3FC1 \
- #DD8F2338BAE7501E3DD5AC78C273792F7D83545D \
- #C4F0DFFF4E8C1A8236409D08E73BC641CC11F4C8 \
- #B9AE9905FFD7803F25714661B63B535A4C206CA9 \
- #; do \
- #gpg --keyserver ha.pool.sks-keyservers.net --recv-keys "$key" || \
- #gpg --keyserver pgp.mit.edu --recv-keys "$key" || \
- #gpg --keyserver keyserver.pgp.com --recv-keys "$key" ; \
- #done && \
- #gpg --verify SHASUMS256.txt.asc && \
- # Ignore socket files then delete files then delete directories
- #find "$GNUPGHOME" -type f | xargs rm -f && \
- #find "$GNUPGHOME" -type d | xargs rm -fR && \
- rm -f SHASUMS256.txt.asc && \
- \
- # Install Node
- tar xvzf node-${NODE_VERSION}-${ARCHITECTURE}.tar.gz && \
- rm node-${NODE_VERSION}-${ARCHITECTURE}.tar.gz && \
- mv node-${NODE_VERSION}-${ARCHITECTURE} /opt/nodejs && \
- ln -s /opt/nodejs/bin/node /usr/bin/node && \
- ln -s /opt/nodejs/bin/npm /usr/bin/npm && \
- \
- #DOES NOT WORK: paxctl fix for alpine linux: https://github.com/wekan/wekan/issues/1303
- #paxctl -mC `which node` && \
- \
- # Install Node dependencies
- npm install -g npm@${NPM_VERSION} && \
- npm install -g node-gyp && \
- npm install -g fibers@${FIBERS_VERSION} && \
- \
- # Change user to wekan and install meteor
- cd /home/wekan/ && \
- chown wekan:wekan --recursive /home/wekan && \
- curl "https://install.meteor.com" -o /home/wekan/install_meteor.sh && \
- #curl "https://install.meteor.com/?release=${METEOR_RELEASE}" -o /home/wekan/install_meteor.sh && \
- # OLD: sed -i "s|RELEASE=.*|RELEASE=${METEOR_RELEASE}\"\"|g" ./install_meteor.sh && \
- # Install Meteor forcing its progress
- sed -i 's/VERBOSITY="--silent"/VERBOSITY="--progress-bar"/' ./install_meteor.sh && \
- echo "Starting meteor ${METEOR_RELEASE} installation... \n" && \
- chown wekan:wekan /home/wekan/install_meteor.sh && \
- \
- # Check if opting for a release candidate instead of major release
- if [ "$USE_EDGE" = false ]; then \
- gosu wekan:wekan sh /home/wekan/install_meteor.sh; \
- else \
- gosu wekan:wekan git clone --recursive --depth 1 -b release/METEOR@${METEOR_EDGE} git://github.com/meteor/meteor.git /home/wekan/.meteor; \
- fi; \
- \
- # Get additional packages
- #mkdir -p /home/wekan/app/packages && \
- #chown wekan:wekan --recursive /home/wekan && \
- # REPOS BELOW ARE INCLUDED TO WEKAN REPO
- #cd /home/wekan/app/packages && \
- #gosu wekan:wekan git clone --depth 1 -b master https://github.com/wekan/flow-router.git kadira-flow-router && \
- #gosu wekan:wekan git clone --depth 1 -b master https://github.com/meteor-useraccounts/core.git meteor-useraccounts-core && \
- #gosu wekan:wekan git clone --depth 1 -b master https://github.com/wekan/meteor-accounts-cas.git && \
- #gosu wekan:wekan git clone --depth 1 -b master https://github.com/wekan/wekan-ldap.git && \
- #gosu wekan:wekan git clone --depth 1 -b master https://github.com/wekan/wekan-scrollbar.git && \
- #gosu wekan:wekan git clone --depth 1 -b master https://github.com/wekan/meteor-accounts-oidc.git && \
- #gosu wekan:wekan git clone --depth 1 -b master --recurse-submodules https://github.com/wekan/markdown.git && \
- #gosu wekan:wekan mv meteor-accounts-oidc/packages/switch_accounts-oidc wekan-accounts-oidc && \
- #gosu wekan:wekan mv meteor-accounts-oidc/packages/switch_oidc wekan-oidc && \
- #gosu wekan:wekan rm -rf meteor-accounts-oidc && \
- sed -i 's/api\.versionsFrom/\/\/api.versionsFrom/' /home/wekan/app/packages/meteor-useraccounts-core/package.js && \
- cd /home/wekan/.meteor && \
- gosu wekan:wekan /home/wekan/.meteor/meteor -- help; \
- \
- # extract the OpenAPI specification
- npm install -g api2html@0.3.3 && \
- mkdir -p /home/wekan/python && \
- chown wekan:wekan --recursive /home/wekan/python && \
- cd /home/wekan/python && \
- gosu wekan:wekan git clone --depth 1 -b master https://github.com/Kronuz/esprima-python && \
- cd /home/wekan/python/esprima-python && \
- python3 setup.py install --record files.txt && \
- cd /home/wekan/app &&\
- gosu wekan:wekan mkdir -p ./public/api && \
- gosu wekan:wekan python3 ./openapi/generate_openapi.py --release $(git describe --tags --abbrev=0) > ./public/api/wekan.yml && \
- gosu wekan:wekan /opt/nodejs/bin/api2html -c ./public/logo-header.png -o ./public/api/wekan.html ./public/api/wekan.yml; \
- # Build app
- cd /home/wekan/app && \
- gosu wekan:wekan /home/wekan/.meteor/meteor add standard-minifier-js && \
- gosu wekan:wekan /home/wekan/.meteor/meteor npm install && \
- gosu wekan:wekan /home/wekan/.meteor/meteor build --directory /home/wekan/app_build && \
- cp /home/wekan/app/fix-download-unicode/cfs_access-point.txt /home/wekan/app_build/bundle/programs/server/packages/cfs_access-point.js && \
- rm /home/wekan/app_build/bundle/programs/server/npm/node_modules/meteor/rajit_bootstrap3-datepicker/lib/bootstrap-datepicker/node_modules/phantomjs-prebuilt/lib/phantom/bin/phantomjs && \
- chown wekan:wekan /home/wekan/app_build/bundle/programs/server/packages/cfs_access-point.js && \
- #Removed binary version of bcrypt because of security vulnerability that is not fixed yet.
- #https://github.com/wekan/wekan/commit/4b2010213907c61b0e0482ab55abb06f6a668eac
- #https://github.com/wekan/wekan/commit/7eeabf14be3c63fae2226e561ef8a0c1390c8d3c
- #cd /home/wekan/app_build/bundle/programs/server/npm/node_modules/meteor/npm-bcrypt && \
- #gosu wekan:wekan rm -rf node_modules/bcrypt && \
- #gosu wekan:wekan npm install bcrypt && \
- cd /home/wekan/app_build/bundle/programs/server/ && \
- gosu wekan:wekan npm install && \
- #gosu wekan:wekan npm install bcrypt && \
- mv /home/wekan/app_build/bundle /build && \
- \
- # Put back the original tar
- mv $(which tar)~ $(which tar) && \
- \
- # Cleanup
- apt-get remove --purge -y ${BUILD_DEPS} && \
- apt-get autoremove -y && \
- npm uninstall -g api2html &&\
- rm -R /var/lib/apt/lists/* && \
- rm -R /home/wekan/.meteor && \
- rm -R /home/wekan/app && \
- rm -R /home/wekan/app_build && \
- cat /home/wekan/python/esprima-python/files.txt | xargs rm -R && \
- rm -R /home/wekan/python && \
- rm /home/wekan/install_meteor.sh
-
-ENV PORT=8080
-EXPOSE $PORT
-USER wekan
-
-CMD ["node", "/build/main.js"]
diff --git a/pica-wekan/README.md b/pica-wekan/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..5d204200d615601b0af9997a2ed802b312a5d865
--- /dev/null
+++ b/pica-wekan/README.md
@@ -0,0 +1,20 @@
+## Wekan
+
+Ce dossier contient les ressources nécessaires pour lancer une instance Wekan sur les serveurs de Picasoft.
+Il se base sur des images pré-construites et ne nécessite donc pas de construction manuelle.
+
+L'instance comporte une base de données MongoDB et un serveur applicatif.
+
+### Configuration
+
+La configuration se fait essentiellement via le [docker-compose.yml](./docker-compose.yml), au niveau des variables d'environnement.
+
+### Lancement
+
+Il suffit d'un `docker-compose up -d`.
+
+### Mise à jour
+
+Il suffit de mettre à jour les tags des images dans le [docker-compose.yml](./docker-compose.yml), et de vérifier au niveau de la page des [Releases](https://github.com/wekan/wekan/releases) s'il y a eu des modifications.
+
+On pourra aussi consulter le Compose du dépôt officiel pour effectuer les nouvelles configurations.
diff --git a/pica-wekan/clair-whitelist.yml b/pica-wekan/clair-whitelist.yml
deleted file mode 100644
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..0000000000000000000000000000000000000000
diff --git a/pica-wekan/docker-compose.yml b/pica-wekan/docker-compose.yml
index d43b4b788a671750be6c9bb7b53ada6a538bf8cc..22ca460a3621b588a4cfe7884e4f56df2daef86d 100644
--- a/pica-wekan/docker-compose.yml
+++ b/pica-wekan/docker-compose.yml
@@ -1,66 +1,44 @@
version: '2.4'
+volumes:
+ wekan:
+
networks:
docker_default:
- external: true
name: "docker_default"
-
-
+ wekan:
+ name: "wekan"
services:
+ wekan-db:
+ image: mongo:4.0.12
+ container_name: wekan-db
+ restart: always
+ command: mongod --smallfiles --oplogSize 128
+ expose:
+ - 27017
+ volumes:
+ - wekan:/data/db
+ networks:
+ - wekan
wekan-app:
- image: pica-wekan:2.75
+ image: wekanteam/wekan:v3.57
container_name: wekan-app
- restart: always
- links:
- - wekan-db:wekan-db
- networks:
- - docker_default
labels:
- - "traefik.frontend.rule=Host:wekan2.test.picasoft.net"
+ - "traefik.frontend.rule=Host:kanban.picasoft.net"
- "traefik.port=8080"
- "traefik.enable=true"
+ restart: always
+ links:
+ - wekan-db:wekan-db
environment:
- MONGO_URL=mongodb://wekan-db:27017/wekan
- - ROOT_URL=http://wekan2.test.picasoft.net # <=== using only at same laptop/desktop where Wekan is installed
- - WITH_API=true
- #---------------------------------------------------------------
- #
- # LOGOUT_ON_MINUTES : The number of minutes
- # example : LOGOUT_ON_MINUTES=55
- #- LOGOUT_ON_MINUTES=
- #-------------------------------------------------------------------
- security_opt:
- - no-new-privileges
- mem_limit: "4096m"
- cpus: "0.60"
- pids_limit: 1024
+ - ROOT_URL=https://kanban.picasoft.net
+ - CARD_OPENED_WEBHOOK_ENABLED=false
+ - WEBHOOKS_ATTRIBUTES=cardId,listId,user
depends_on:
- wekan-db
-
- wekan-db:
- image: mongo:3.2.21
- #-------------------------------------------------------------------------------------
- container_name: wekan-db
- restart: always
- command: mongod --smallfiles --oplogSize 128
networks:
- docker_default
- expose:
- - 27017
- #volumes:
- #- wekan-db:/data/db
- #- wekan-db-dump:/dump
- #volumes:
- #- /DATA/docker/wekan-db:/data/db
- security_opt:
- - no-new-privileges
- mem_limit: "2048m"
- cpus: "0.20"
- pids_limit: 1024
-volumes:
- wekan-db:
- driver: local
- wekan-db-dump:
- driver: local
+ - wekan
diff --git a/template/README.md b/template/README.md
index 98ac25e6abfd1991ab01c1bb4d1c4fe4803b73ef..d54268b9c3aebf3f8afe6655174a023454356202 100644
--- a/template/README.md
+++ b/template/README.md
@@ -6,12 +6,18 @@ In this README, you should explain, if applicable, the following :
* How to configure (secrets, environment variables...)
* How to start (usually just a `docker-compose up -d` and copying the secret files : this is the goal)
* How to update the service itself (usually just changing a tag in the Docker Compose file and an argument in the Dockerfile)
-* How to update the customization of the service : add more environment variables, change configurtion, etc.
+* How to update the customization of the service : add more environment variables, change configuration, etc.
* How to administrate the service (e.g. CLI tool)
* Warnings about breaking changes (e.g. "you cannot update the database to a major version without doing this or that")
And everything that you find useful.
+If you use a single folder for multiple Dockerfiles, *e.g.* 2, you can either :
+* Create two subfolder containing a Dockerfile
+* Or create two Dockerfile, with the name `<service>.Dockerfile`
+
+For example, the mail service uses two Dockerfile : one for the MTA, one for the MDA.
+
This README should act as a reference for all administration tasks.
-However it should not contain user documentation, nor general advices about how to resolve build errors and so on (this is the job of the CI documentation).
+However it should not contain user documentation, nor general advices about how to resolve build errors and so on (please use the Wiki).
diff --git a/template/clair-whitelist.yml b/template/clair-whitelist.yml
deleted file mode 100644
index f03bd1a81d750ab8e56c7d145c370f9e46fc4194..0000000000000000000000000000000000000000
--- a/template/clair-whitelist.yml
+++ /dev/null
@@ -1,4 +0,0 @@
-# Put all CVE as sub-keys
-# The format is :
-# CVE-XXX-XXX: <paquet name> -> <reason>
-generalwhitelist:
diff --git a/template/docker-compose.yml b/template/docker-compose.yml
index 81c97073f9115e58056884fe602861e79452363d..c4fbd859d9959b1881a61385dbdc044915f74db1 100644
--- a/template/docker-compose.yml
+++ b/template/docker-compose.yml
@@ -30,9 +30,15 @@ services:
# Main application
app:
# This is the name of the image
- # which will be built on the registry
+ # which will be built and pushed on the registry
# Never use latest as a tag
- image: registry.picasoft.net/<image>:<tag>
+ image: registry.picasoft.net/pica-<service>:<tag>
+ # When using a local Dockerfile,
+ # add this directive so that then `docker-compose build`
+ # command works. See other options here
+ # (such as using an alternate Dockerfile) :
+ # https://docs.docker.com/compose/compose-file/#build
+ build: .
# Use a comprehensive name for easy
# understanding of `docker ps` output
container_name: app
@@ -80,8 +86,10 @@ services:
restart: unless-stopped
# Some services have a database : here is an example
+ # Here is could be postgres:12. We do not build it manually,
+ # so no need for `build` key nor registry.picasoft.net prefix.
db:
- image: registry.picasoft.net/<image>:<tag>
+ image: <image>:<tag>
container_name: db
# Database secrets should be in a separate file
env_file: