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..bfe1045f844d3379dec98f3b91cf827ccd843bc2 100644
--- a/README.md
+++ b/README.md
@@ -2,10 +2,12 @@
Ce dépôt centralise les Dockerfiles et autre ressources utilisées pour construire **et** déployer les images Docker tournant en production sur l'infrastructure de Picasoft.
+Certains services ne respectent pas encore la structure de ce dépôt (exemple : `nextcloud-docker`, ou Traefik qui reste géré uniquement sur les VM) : ils seront migrés prochainement.
+
## Philosophie
Historiquement, Picasoft procède de la manière suivante :
-* Construire ses Dockerfile à la main et les pousser sur un registre privé.
+* Construire les images Docker à partir de Dockerfiles sur une machine quelconque, puis les pousser manuellement sur un registre privé.
* Gérer un Docker Compose global par VM, qui contient la configuration et les secrets.
Cette approche pose plusieurs problèmes. Comment savoir ce qu'il y a dans une image, si on perd le Dockerfile ? Quel Dockerfile correspond à quelle version de l'image ? Si on perd l'accès à la machine, comment récupérer la configuration, remonter rapidement le service ? Comment versionner les changements de configuration ? Revenir à la version d'il y a deux semaines ?
@@ -13,54 +15,44 @@ Cette approche pose plusieurs problèmes. Comment savoir ce qu'il y a dans une i
L'objectif de ce dépôt est de rendre possible le déploiement de n'importe quel service Picasoft avec la procédure suivante :
* Cloner le dépôt
* Se rendre dans le répertoire du service
-* Lancer un `docker-compose up -d`
+* Lancer un `docker-compose up -d` pour démarrer le service
Son objectif secondaire est de pouvoir revenir à l'état antérieur d'un service. En versionnant toute la configuration nécessaire, revenir à une ancienne version du service revient à :
* Cloner le dépôt
* Checkout un commit quelconque
* Lancer le service normalement
-Pour y arriver, il construit automatiquement les images de l'ensemble des services et les met à disposition sur un registre, avec une version. Mise à part les données à proprement parler du service, il n'y a donc aucune différence entre un service lancé sur une de nos machines et un service lancé à partir de ce dépôt sur une machine virtuelle quelconque, ce qui s'inscrit dans la philosophie Docker.
+Mises à part les données à proprement parler du service, il n'y a donc aucune différence entre un service lancé sur une de nos machines et un service lancé à partir de ce dépôt sur une machine virtuelle quelconque, ce qui s'inscrit dans la philosophie Docker.
## Contenu du dépôt
-Ce dépôt contient toutes les ressources permettant de déployer les services que nous maintenons sur n'importe quelle machine virtuelle de l'infrastructure de Picasoft, sans prérequis.
-
-Cela signifie que le bon fonctionnement d'un service n'est pas dépendant de la machine virtuelle sur laquelle on essaye de le lancer.
+Le dépôt est organisé en dossiers. Chaque dossier correspond à un *service* Picasoft au sens large, c'est-à -dire à un ensemble de conteneurs liés entre eux *techniquement* (*e.g.* Mattermost et sa base de données) et/ou *sémantiquement* (*e.g.* sites web statiques, relai et boîte à mail).
-Ainsi, chaque service versionné sur ce dépôt contiendra :
+Ainsi, chaque dossier de ce dépôt contiendra, selon les situations :
-* Un `Dockerfile` permettant de construire l'image,
+* Zéro, un ou plusieurs `Dockerfile` permettant de construire les images personnalisées pour Picasoft,
* Un fichier `docker-compose.yml` permettant de lancer le service,
* Si possible, un ou des fichiers de configuration permettant de personnaliser le service selon nos besoins,
* Un fichier d'exemple de secrets (mot de passe...) nécessaire au lancement du service,
* Un `README.md` résumant les paramètres modifiables sur le dépôt, les mécanismes pour en rajouter, etc,
* Pour les images maison, un `CHANGELOG.md` résumant les modifications faites au fil des version.
-Il n'y a pas de Docker Compose global : chaque service a son propre Docker Compose.
+Il n'y a pas de Docker Compose global : chaque service a son propre Docker Compose, lui permettant d'être déployé indépendamment des autres.
Un exemple concret peut être trouvé au niveau de [pica-mattermost](./pica-mattermost) ou [pica-etherpad](./pica-etherpad).
-## Mais je commence par où, bordel ?
-
-Ce dépôt peut faire peur, mais pour la plupart des usages il est très simple à exploiter.
+## Guides d'utilisation
-### Je veux lancer un service existant sur une machine virtuelle
+### Lancer ou redémarrer un service sur une machine de Picasoft
-Si le service que vous souhaitez lancer est référencé sur ce dépôt, lisez [la documentation de déploiement](./doc/guide_deploiement.md#déploiement-en-production).
+Lire [la documentation de déploiement et de maintenance]().
-### Je veux mettre à jour un service
+### Mettre à jour un service ou sa configuration
-Il faut pour cela utiliser la chaîne d'intégration de ce dépôt, qui construit automatiquement les images Docker. [Lisez la documentation utilisateur de la chaîne d'intégration.](./doc/guide_utilisateur_ci.md).
+Lire [la documentation de mise à jour des services]().
-### Je veux mettre en place un nouveau service
+### Mettre en place un nouveau service
-Il faudra d'une part [respecter les conventions utilisées par la chaîne d'intégration](./doc/guide_developpeur_ci.md#formalisme-du-dpt).
-
-Ensuite, il faudra jeter un oeil [aux bonnes pratiques](./doc/guide_bonnes_pratiques.md) à l'oeuvre sur l'infrastructure de Picasoft (partie **Formalisme du dépôt**).
+Lire [la documentation de versionnage d'un nouveau service]() et [les bonnes pratiques pour Docker]().
Un dossier [template](./template) prêt à copier est aussi disponible.
-
-### Je veux améliorer la chaîne d'intégration
-
-Lisez la [documentation "développeur" pour la chaîne d'intégration](./doc/guide_developpeur_ci.md), qui rentre plus dans le détail.
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/docker-compose/README.md b/docker-compose/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..22bbe021cfad1d4a8e40b4f488ebee07d611edbb
--- /dev/null
+++ b/docker-compose/README.md
@@ -0,0 +1 @@
+**Fusionner `pica-mail-mta` et `pica-mail-mda` et ajouter le fichier Compose `mail.yml`**.
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/docker-compose.yml b/meta-registry-test/docker-compose.yml
deleted file mode 100644
index c3ae73e74d291f2ecb0fa7dbaa62e7f6ef40fb76..0000000000000000000000000000000000000000
--- a/meta-registry-test/docker-compose.yml
+++ /dev/null
@@ -1,30 +0,0 @@
-version: "3.7"
-
-volumes:
- registry-data:
- name: "registry-data"
-
-networks:
- docker_default:
- external: true
-
-services:
- registry:
- container_name: registry
- restart: always
- image: registry.test.picasoft.net/meta-registry-test:0.1
- environment:
- REGISTRY_AUTH: htpasswd
- REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
- REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
- REGISTRY_STORAGE_DELETE_ENABLED: "true"
- REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /var/lib/registry
- volumes:
- - registry-data:/var/lib/registry
- - ./secrets/htpasswd:/auth/htpasswd
- labels:
- - "traefik.frontend.rule=Host:registry.test.picasoft.net"
- - "traefik.port=5000"
- - "traefik.enable=true"
- networks:
- - docker_default
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/nextcloud-docker/README.md b/nextcloud-docker/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..890d6ff3c12526e23ef7a5e2cbbfd73642f23a6c
--- /dev/null
+++ b/nextcloud-docker/README.md
@@ -0,0 +1 @@
+**Ajouter le docker-compose et la documentation de mise à jour**
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/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-dokuwiki/README.md b/pica-dokuwiki/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..e4fd392e9b8e3bae577aa0556db03129c36a4442
--- /dev/null
+++ b/pica-dokuwiki/README.md
@@ -0,0 +1 @@
+À compléter (mise à jour...)
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-etherpad-db/README.md b/pica-etherpad-db/README.md
index 26924f2314171a923ce385d8b029c0c9801d00ed..26750256c6f515002abb384b15dd75668fabf8ff 100644
--- a/pica-etherpad-db/README.md
+++ b/pica-etherpad-db/README.md
@@ -1 +1,3 @@
+**Doit être fusionné avec le dossier `pica-etherpad` (deux Dockerfiles, un Docker Compose)**.
+
This image limits the [mysql binary log](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) to 30 hours (=108000 seconds) via the [binlog_expire_logs_seconds](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_expire_logs_seconds) variable.
diff --git a/pica-etherpad-db/clair-whitelist.yml b/pica-etherpad-db/clair-whitelist.yml
deleted file mode 100644
index a9d6ed5bdae04856ade1de9572cbdfee041aa4b9..0000000000000000000000000000000000000000
--- a/pica-etherpad-db/clair-whitelist.yml
+++ /dev/null
@@ -1 +0,0 @@
-generalwhitelist:
diff --git a/pica-etherpad-db/docker-compose.yml b/pica-etherpad-db/docker-compose.yml
deleted file mode 100644
index 9f5a107cbd4b3987656809c733397cf8a1ba59de..0000000000000000000000000000000000000000
--- a/pica-etherpad-db/docker-compose.yml
+++ /dev/null
@@ -1,7 +0,0 @@
-version : "2.4"
-
-# THIS IS A DUMMY docker-compose.yml USED ONLY BY THE CI
-
-services:
- etherpad-db:
- image: registry.picasoft.net/pica-etherpad-db:mysql8.picapatch2
diff --git a/pica-etherpad/README.md b/pica-etherpad/README.md
index 143c962c992dbbb9e23e5b50dd131e6825b7b835..0220f346b56dc5c0e088f0058c7e30e8b84c2b0b 100644
--- a/pica-etherpad/README.md
+++ b/pica-etherpad/README.md
@@ -44,7 +44,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 c270dcf6ff19e2e09adf1f5ba3b8592acabe183c..69494f2c6a4ea577e895ef9062b87c4278d641e3 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-lufi/docker-compose.yml b/pica-lufi/docker-compose.yml
index 15ffdf44fdabbc7c487c706c6bd44160de35612f..fd51118ace69d820157a2c81e1042fcf3e4484d4 100644
--- a/pica-lufi/docker-compose.yml
+++ b/pica-lufi/docker-compose.yml
@@ -6,17 +6,8 @@ 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
container_name: lufi
init: true
depends_on:
@@ -29,7 +20,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/pica-mail-copy-certs/README.md b/pica-mail-copy-certs/README.md
index 746b9a8852a1c0d1b169418cedea7810e8aff155..62a073127b8d548a53b6fbd0cb94e1c2d1527054 100644
--- a/pica-mail-copy-certs/README.md
+++ b/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-mda/README.md b/pica-mail-mda/README.md
index 2318c77215855da15814edf279970957de4a078d..bcbcc8de627a6671baaa0efadd2ad7304e9aa634 100644
--- a/pica-mail-mda/README.md
+++ b/pica-mail-mda/README.md
@@ -1,3 +1,5 @@
+**Doit être mis à jour pour respecter le formalisme du dépôt et inclure le Docker Compose**.
+
# Pour construire l'image :
```
diff --git a/pica-mail-mta/README.md b/pica-mail-mta/README.md
index fd7a85113e12cb982367b71a84ea61d794ce9fbc..d7967b846a00c1ab723ee1256f77e34dd50be665 100644
--- a/pica-mail-mta/README.md
+++ b/pica-mail-mta/README.md
@@ -1,3 +1,5 @@
+**Doit être mis à jour pour respecter le formalisme du dépôt et inclure le Docker Compose**.
+
# Conteneur MTA (Postfix)
## Pour build:
```
@@ -7,4 +9,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-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-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-mumble-web/clair-whitelist.yml b/pica-mumble-web/clair-whitelist.yml
deleted file mode 100644
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..0000000000000000000000000000000000000000
diff --git a/pica-murmur/README.md b/pica-murmur/README.md
index 94e274429f16a12b15ccbdbde70fe1b1d100d00e..6cbcf39b192d134362939482b6d52e0c048b83bc 100644
--- a/pica-murmur/README.md
+++ b/pica-murmur/README.md
@@ -13,3 +13,7 @@ Murmur store its server database and configuration files under `/data/` folder.
## 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/pica-nginx/README.md b/pica-nginx/README.md
index 0a5db6ca26ea89c35baec84cd7ab3946ff137b32..3435d9eb66ef67f84809246852c3c4d0d60fd2c7 100644
--- a/pica-nginx/README.md
+++ b/pica-nginx/README.md
@@ -1,55 +1,42 @@
# 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).
+
+## 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 86%
rename from noCI-websites/docker-compose.yml
rename to pica-nginx/docker-compose.yml
index 35bade6bc2c421f53b85607722e5b755cd7c9951..74ee7035db10e0d0b20c2cfe5ad00045fa9cdb7e 100644
--- a/noCI-websites/docker-compose.yml
+++ b/pica-nginx/docker-compose.yml
@@ -18,6 +18,9 @@ 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-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/noCI-uploads/README.md b/pica-uploads/README.md
similarity index 100%
rename from noCI-uploads/README.md
rename to pica-uploads/README.md
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/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..9665c0e3f6f605f0c0b2f044138710244623aeea 100644
--- a/pica-wekan/docker-compose.yml
+++ b/pica-wekan/docker-compose.yml
@@ -10,7 +10,8 @@ networks:
services:
wekan-app:
- image: pica-wekan:2.75
+ image: registry.picasoft.net/pica-wekan:2.75
+ build: .
container_name: wekan-app
restart: always
links:
diff --git a/template/README.md b/template/README.md
index 98ac25e6abfd1991ab01c1bb4d1c4fe4803b73ef..694e30748fdce83839fa5fa4474cac6a2fbb4d8b 100644
--- a/template/README.md
+++ b/template/README.md
@@ -6,7 +6,7 @@ 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")
@@ -14,4 +14,4 @@ And everything that you find useful.
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.
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: