Before going further, make sure your global IP address is dynamic with: [ip.yunohost.org](http://ip.yunohost.org/). The global IP address of your box changes almost every day.
+
+This tutorial aim to get around dynamic IP issue which is: when the IP public address of your (Internet Service Provider-) box changes, the DNS zone is not updated to point towards the new IP address, and consequently your server is no more reachable via its domain name. After setting up the solution proposed in this tutorial, the redirection from your domain name to the actual IP address of your server will not be lost anymore.
+
+The method proposed here consists of automatizing the fact the box annonces its global IP adress change to the dynamic DNS, so that the DNS zone will automatically be updated.
+
+If you own a domain name at **OVH**, you may go to step 4 and follow this [tutorial](/OVH), given that OVH proposes a DynDNS service.
+
+#### 1. Create an account to a Dynamic DNS service
+Here are sites which offer a DynDNS service free of charge:
+* [DNSexit](https://www.dnsexit.com/Direct.sv?cmd=dynDns)
+* [No-IP](https://www.noip.com/remote-access)
+* [ChangeIP](https://changeip.com)
+* [DynDNS (in italian)](https://dyndns.it)
+* [DynDNS with your own domain](https://github.com/jodumont/DynDNS-with-HE.NET)
+* [Duck DNS](https://www.duckdns.org/)
+
+Register to one of them. It should provide you with one (or more) IP address to reach the service, and a login (that you may be able to self-define).
+
+#### 2. Move the DNS zones
+Copy the [DNS zones](dns_config), except for the NS fields, from the [registrar](/registrar) where you bought your domain name from to the dynamic DNS service you registrer at in step 1.
+
+#### 3. Switch the management of your domain name to the dynamic DNS server
+This step consists in declaring to your [registrar](/registrar) that the DNS service will now be managed by the DynDNS service provider.
+
+For this, fisrt declare in the NS field(s) the IP address provided by the DynDNS service.
+
+Then, remove any other item in the [DNS zones](dns_config) (except the previous NS fields), from the [registrar](/registrar).
+
+#### 4. Configure the client
+This client could be your ISP-box, or a package installed on your server, such as `ddclient`.
+Here, we will use the client provided by the box, which is the more easy way.
+
+Enter the login of the dynamic DNS and its public IP address in your box (interface details may vary by ISP).
+
+Avant d’aller plus loin, assurez-vous que votre adresse IP publique est dynamique à l’aide de : [ip.yunohost.org](http://ip.yunohost.org/). L’adresse IP publique de votre box change à peu près tous les jours.
+
+Ce tutoriel a pour but de contourner le problème d’IP dynamique qui est le suivant : lorsque l’adresse IP publique de la box change, la zone DNS n’est pas mise à jour pour pointer vers la nouvelle adresse IP.
+
+Après avoir mis en place la solution proposée dans ce tutoriel, la redirection du nom de domaine vers l’adresse IP ne sera plus perdue.
+
+La méthode qui sera mise en place consiste à rendre automatique le fait que la box annonce au DNS dynamique qu’elle a changée d’adresse IP publique, et qu’ensuite la zone DNS soit automatiquement changée.
+
+Si vous possédez un nom de domaine chez **OVH**, vous pouvez aller à l’étape 4 et suivre ce [tutoriel](/OVH) étant donné qu’OVH propose un service de DynDNS.
+
+#### 1. Créer un compte pour un service de DNS dynamique
+
+Voici des sites qui proposent un service de DynDNS gratuitement :
+* [DNSexit](https://www.dnsexit.com/Direct.sv?cmd=dynDns)
+* [No-IP](https://www.noip.com/remote-access)
+* [ChangeIP](https://changeip.com)
+* [DynDNS (en italien)](https://dyndns.it)
+* [Duck DNS](https://www.duckdns.org/)
+
+Créer un compte chez l’un d’eux.
+
+#### 2. Déplacer les zones DNS
+Déplacer les [zones DNS](dns_config), à l’exception des champs NS, du [bureau d’enregistrement](/registrar) où vous avez acheté votre nom de domaine vers le DNS dynamique où vous avez créé un compte à l’étape 1.
+
+#### 3. Basculer la gestion de votre nom de domaine vers le serveur DNS dynamique
+Cette étape consiste à faire savoir au [bureau d’enregistrement](/registrar) que le service de DNS sera assuré par le service de DynDNS.
+Redirigez le champ NS vers l’adresse IP donnée par le service de DynDNS.
+
+Ensuite, supprimez les [zones DNS](dns_config), à l’exception des champs NS, du [bureau d’enregistrement](/registrar).
+
+#### 4. Créer un identifiant de DNS dynamique
+Sur le service de DNS dynamique créer un identifiant qui sera entré dans un client de DNS dynamique.
+Ce client peut-être votre box ou un paquet installé sur votre serveur comme `ddclient`.
+Nous allons utiliser le client de la box qui est plus simple à mettre en place.
+
+#### 5. Configurer la box
+Mettez l’identifiant du DNS dynamique et l’[adresse IP publique](http://ip.yunohost.org/) dans votre box.
+
+
+Before setting up a server at home, it is recommended that you know the [possible limitations imposed by your ISP](/isp). If they are too restrictive, you might consider using a VPN to bypass them.
+
+
+## Pre-requisites
+
+- An ARM board with 500MHz CPU and 512 MB of RAM;
+- A power supply for your board;
+- A microSD card: **8GB** capacity (at least) and **Class 10** speed rate are highly recommended (like the [Transcend 300x](http://www.amazon.fr/Transcend-microSDHC-adaptateur-TS32GUSDU1E-Emballage/dp/B00CES44EO));
+- An ethernet cable (RJ-45) to connect your board to your router;
+- A [reasonable ISP](/isp), preferably with a good and unlimited upload bandwidth.
+
+---
+
+## Install with the pre-installed image (recommended)
+
+
+Antes de alojar tu propio servidor en tu casa, te recomendamos que consultes las [posibles restricciones impuestas por tu Proveedor de Internet](/isp). Si tu proveedor es demasiado restrictivo, puedes utilizar un VPN para eludir estas restricciones.
+
+
+- Una tarjeta ARM con un procesador de 500 MHz et 512 Mo de memoria RAM ;
+- Un adaptador de corriente para alimentar la tarjeta ;
+- Una tarjeta microSD : al menos **8 Go** y **Clase 10** (por ejemplo una [Transcend 300x](http://www.amazon.fr/Transcend-microSDHC-adaptateur-TS32GUSDU1E-Emballage/dp/B00CES44EO)) ;
+- Un cable ethernet/RJ-45 para conectar la carte con el router / caja internet. (Con el Raspberry Pi 0, puedes conectar tu tarjeta con un cable OTG y un adaptador Wifi USB.)
+- Un [proveedor de Internet ético](/isp), de preferencia con una buena velocidad de upload.
+
+---
+
+## Instalación con la imagen pre-instalada (recomendada)
+
+
+Avant d'héberger un serveur chez vous, il est recommandé de prendre connaissance des [possibles limitations liées à votre FAI](/isp). Si votre FAI est trop contraignant, vous pouvez envisager d'utiliser un VPN pour contourner ces limitations.
+
+
+- Une carte ARM avec un processeur de 500 MHz et 512 Mo de mémoire vive ;
+- Un adaptateur secteur pour alimenter la carte ;
+- Une carte microSD : au moins **8 Go** et **Classe 10** (par exemple une [Transcend 300x](http://www.amazon.fr/Transcend-microSDHC-adaptateur-TS32GUSDU1E-Emballage/dp/B00CES44EO)) ;
+- Un câble ethernet/RJ-45 pour brancher la carte à votre routeur/box internet. (Avec le Raspberry Pi 0, vous pouvez connecter votre carte avec un câble OTG et un adaptateur Wifi USB.)
+- Un [fournisseur d’accès correct](/isp), de préférence avec une bonne vitesse d’upload.
+
+---
+
+## Installation avec l'image pré-installée (recommandée)
+
+
+# التنصيب على ديبيان
+
+*يمكنكم الإطلاع على طُرق أخرى لتنصيب واي يونوهوست YunoHost **[هنا](/install)**.*
+
+## المتطلبات
+
+

+
+على منصة ARM أو على خادوم إفتراضي خاص أو على خادوم إستضافة أو على حاسوب x86 عادي أو على حاسوب ماكينطوش قديم … إلخ
+
+* على **ديبيان 8** (جيسي) قد تم تنصيبه مِن قبل
+* مُتصل بالإنترنت عبر كابل إيثرنت
+* مباشرة عبر **النفاذ بالمستخدم الجذري root** أو عبر الـ SSH
+
+---
+
+## خطوات التنصيب
+
+
1. التنصيب يدويًا
+
+
2. ما بعد التنصيب
+
diff --git a/install_on_debian_fr.md b/install_on_debian_fr.md
new file mode 100644
index 00000000..013a492e
--- /dev/null
+++ b/install_on_debian_fr.md
@@ -0,0 +1,24 @@
+# Installation sur Debian
+
+*Trouvez d’autres moyens d’installer YunoHost **[ici](/install)**.*
+
+## Prérequis
+
+

+
+Sur une plateforme ARM, un VPS, un serveur dédié, un ordinateur x86 standard, un vieux Macintosh,...
+
+* avec **Debian 10** (Buster) installé
(avec un kernel >= 3.12)
+ * l'ISO Debian 10 ISO peut être téléchargée depuis [cette page](https://www.debian.org/releases/buster/debian-installer/). Prenez la 'netinst CD image' pour votre architecture
+ * N.B. : Avoir un environnement graphique n'est *pas* recommandé ! Les serveurs sont généralement administrés à distance !
+* connecté à Internet
+* avec un **accès root** directement ou par SSH
+
+---
+
+## Étapes d’installation
+
+
1. Installer manuellement
+
+
2. Post-installation
+
diff --git a/install_on_debian_it.md b/install_on_debian_it.md
new file mode 100644
index 00000000..844d77b5
--- /dev/null
+++ b/install_on_debian_it.md
@@ -0,0 +1,23 @@
+# Installazione su Debian
+
+*Altri sistemi per installare Debian **[qui](/install)**.*
+
+### Requisiti
+
+

+
+Su un computer ARM, un VPS, un server dedicato, un computer x86 standard, un vecchio Macintosh, ...
+
+* con **Debian 10** (Buster) installato
(con un kernel >= 3.12)
+ * l'immagine ISO di Debian 10 può essere scaricata da [qui](https://www.debian.org/releases/buster/debian-installer/). Scegli l'immagine 'netinst CD' per la tua architettura.
+ * N.B.: l'uso di un'interfaccia grafica *non* è raccomandato! I server dovrebbero essere amministrati da remoto!
+* connesso ad Internet
+* con un **accesso root** diretto o via SSH
+
+---
+
+## Passi per l'installazione
+
+
1. Installazione manuale
+
+
2. Post-installazione
diff --git a/install_on_raspberry.md b/install_on_raspberry.md
new file mode 100644
index 00000000..fa5706cd
--- /dev/null
+++ b/install_on_raspberry.md
@@ -0,0 +1,58 @@
+# Install YunoHost on a Raspberry Pi
+
+*Find all the ways to install YunoHost **[here](/install)**.*
+
+
+
+
+
+
+
+Before setting up a server at home, it is recommended that you know the [possible limitations imposed by your ISP](/isp). If they are too restrictive, you might consider using a VPN to bypass them.
+
+
+## Pre-requisites
+
+- A Raspberry Pi 2, 3 or 4 (RPi 0 and 1 may work but require some tweaking... see [this issue](https://github.com/YunoHost/issues/issues/1423)) ;
+- An microSD card: **8GB** capacity (at least) and **Class 10** speed rate are highly recommended (like the [Transcend 300x](http://www.amazon.fr/Transcend-microSDHC-adaptateur-TS32GUSDU1E-Emballage/dp/B00CES44EO)) ;
+- A power supply (either an adapter or a MicroUSB cable)i ;
+- An ethernet cable (RJ-45) to connect your Raspberry Pi to your router. (Raspberry Pi Zero users can connect the Pi using an OTG cable, [Wifi dongle](https://core-electronics.com.au/tutorials/raspberry-pi-zerow-headless-wifi-setup.html).) ;
+- A [reasonable ISP](/isp), preferably with a good and unlimited upload bandwidth.
+
+---
+
+## Install with the pre-installed image (recommended)
+
+
0. Download the pre-installed image for Raspberry Pi
+
+
1. Flash the SD card with the image
+
+
2. Boot the board and connect to the web interface at `yunohost.local`
+
+
3. Proceed with the initial configuration (post-installation)
+
+---
+
+## Manual installation (advanced users)
+
+
+We do not recommend the manual installation because it is more technical and longer than using the pre-installed image. This documentation is only intended for advanced users.
+
+
+
+The latest Raspberry Pi OS images requires a screen and a keyboard, as it is no longer possible to connect directly to the Raspberry through SSH. Nevertheless it is possible to re-enable SSH at boot: before starting your Raspberry, put in the boot partition of the SD card an empty file named `ssh` (without extension).
+
+
+0. Install Raspberry Pi OS Lite on the SD card ([instructions](https://www.raspberrypi.org/downloads/raspberry-pi-os/)). The Raspberry Pi OS Lite can be found here: https://downloads.raspberrypi.org/raspbian_lite/images/
+
+1. Connect to your Raspberry Pi with the user `pi`. Set the root password with
+```bash
+sudo passwd root
+```
+
+2. Edit `/etc/ssh/sshd_config` to allow SSH login for root, by replacing `PermitRootLogin without-password` with `PermitRootLogin yes`. Reload the SSH daemon with `service ssh reload`.
+
+3. Disconnect and reconnect, this time as root.
+
+4. Then follow the
generic manual install procedure.
+
diff --git a/install_on_raspberry_de.md b/install_on_raspberry_de.md
new file mode 100644
index 00000000..f9d32bf1
--- /dev/null
+++ b/install_on_raspberry_de.md
@@ -0,0 +1,58 @@
+# YunoHost auf einem Raspberry Pi installieren
+
+*Alle Arten YunoHost zu installieren findest du **[hier](/install)**.*
+
+
+
+
+
+
+
+Vor der Einrichtung eines Servers zuhause ist es empfehlenswert [mögliche Einschränkungen deines Providers](/isp) zu kennen. Wenn er zu viele Einschränkungen vornimmt, kann es sinnvoll sein ein VPN zu nutzen um diese zum umgehen.
+
+
+## Voraussetzungen
+
+- Einen Raspberry Pi 2, 3 oder 4 (RPi 0 and 1 may work but require some tweaking ... see [this issue](https://github.com/YunoHost/issues/issues/1423)) ;
+- Eine microSD Karte: **8 GB** Speicherplatz (mindestens) und **Class 10** Geschwindigkeit werden empfohlen (wie zum Beispiel die [Transcend 300x](http://www.amazon.fr/Transcend-microSDHC-adaptateur-TS32GUSDU1E-Emballage/dp/B00CES44EO)) ;
+- Ein Netzeil (entweder ein Steckernetzteil oder ein MicroUSB Kabel) ;
+- An Netzwerkkabel (RJ-45) um den Raspberry mit dem router zu verbinden. (Raspberry Pi Zero Nutzer können ein OTG Kabel nutzen, [Wifi dongle](https://core-electronics.com.au/tutorials/raspberry-pi-zerow-headless-wifi-setup.html).) ;
+- Einen [geeigneten Provider](/isp), am Besten einen mit einer guten upload Geschwindigkeit.
+
+---
+
+## Install with the pre-installed image (recommended)
+
+
0. Download the pre-installed image for Raspberry Pi
+
+
1. Flash the SD card with the image
+
+
2. Boot the board and connect to the web interface at `yunohost.local`
+
+
4. Proceed to post-installation
+
+---
+
+## Manual installation (advanced users)
+
+
+We do not recommend the manual installation because it is more technical and longer than using the pre-installed image. This documentation is only intended for advanced users.
+
+
+
+The latest Raspberry Pi OS Lite images requires a screen and a keyboard, as it is no longer possible to connect directly to the Raspberry through SSH. Nevertheless it is possible to re-enable SSH at boot: before starting your Raspberry, put in the boot partition of the SD card an empty file named `ssh` (without extension).
+
+
+0. Install Raspberry Pi OS Lite on the SD card ([instructions](https://www.raspberrypi.org/downloads/raspberry-pi-os/)).
+
+1. Connect to your Raspberry Pi with the user `pi`. Set the root password with
+```bash
+sudo passwd root
+```
+
+2. Edit `/etc/ssh/sshd_config` to allow SSH login for root, by replacing `PermitRootLogin without-password` with `PermitRootLogin yes`. Reload the SSH daemon with `service ssh reload`.
+
+3. Disconnect and reconnect, this time as root.
+
+4. Then follow the
generic manual install procedure.
+
diff --git a/install_on_raspberry_es.md b/install_on_raspberry_es.md
new file mode 100644
index 00000000..66d99394
--- /dev/null
+++ b/install_on_raspberry_es.md
@@ -0,0 +1,58 @@
+# Instalar YunoHost en un Raspberry Pi
+
+*Encontrar otros medios de instalar YunoHost **[aquí](/install)**.*
+
+
+
+
+
+
+
+Antes de alojar tu propio servidor en tu casa, te recomendamos que consultes las [posibles restricciones impuestas por tu Proveedor de Internet](/isp). Si tu proveedor es demasiado restrictivo, puedes utilizar un VPN para eludir estas restricciones.
+
+
+## Prerrequisitos
+
+- Un Raspberry Pi 2, 3 o 4 (RPi 0 and 1 may work but require some tweaking ... see [this issue](https://github.com/YunoHost/issues/issues/1423)) ; ;
+- Un adaptador de corriente para alimentar la tarjeta ;
+- Una tarjeta microSD : al menos **8 Go** y **Clase 10** (por ejemplo una [Transcend 300x](http://www.amazon.fr/Transcend-microSDHC-adaptateur-TS32GUSDU1E-Emballage/dp/B00CES44EO)) ;
+- Un cable ethernet/RJ-45 para conectar la tarjeta con tu enrutador o tu caja internet. (Con el Raspberry Pi 0, puedes conectar tu tarjeta con un cable OTG y un adaptador Wifi USB.)
+- Un [proveedor de Internet ético](/isp), de preferencia con buena velocidad de upload.
+
+---
+
+## Instalación con la imagen pre-instalada (recomendada)
+
+
1. Descargar la imagen para Raspberry Pi
+
+
2. Poner la imagen en tu tarjeta SD
+
+
3. Conectar y encender
+
+
4. Proceder a la post-instalación
+
+---
+
+## Instalación manual (desaconsejada)
+
+
+No recomendamos la instalación manual porque es más técnica y más larga que la instalación vía la imagen per-instalada. Esta documentación sobre todo está destinada a los usuarios expertos.
+
+
+
+Las últimas versiones de Raspberry Pi OS necesitan una pantalla y un teclado porque ya no es posible conectarse directamente por SSH al Raspberry por defecto. Sin embargo, es posible reactivar el inicio de SSH al boot : solo hay que poner un archivo llamado `ssh` (vacío, sin extensión) en la partición boot de la tarjeta SD.
+
+
+0. Instalar Raspberry Pi OS Lite ([instrucciones](https://www.raspberrypi.org/downloads/raspberry-pi-os/)) en la tarjeta SD.
+
+1. Conéctate con SSH al Raspberry Pi con el usuario pi. Define una contraseña root con
+```bash
+sudo passwd root
+```
+
+2. Modifica `/etc/ssh/sshd_config` para autorizar root a que se conecte con ssh, reemplazando `PermitRootLogin without-password` por `PermitRootLogin yes`. Recarga el daemon ssh con `service ssh reload`, y luego re-conéctate como root.
+
+3. Desconéctate et reconéctate con el usuario root esta vez.
+
+4. Sigue con el
procedimiento de instalación manual genérico.
+
diff --git a/install_on_raspberry_fr.md b/install_on_raspberry_fr.md
new file mode 100644
index 00000000..e9a18419
--- /dev/null
+++ b/install_on_raspberry_fr.md
@@ -0,0 +1,59 @@
+# Installer YunoHost sur Raspberry Pi
+
+*Toutes les autres façons d’installer YunoHost sont listées **[ici](/install)**.*
+
+
+
+
+
+
+
+Avant d'héberger un serveur chez vous, il est recommandé de prendre connaissance des [possibles limitations liées à votre FAI](/isp). Si votre FAI est trop contraignant, vous pouvez envisager d'utiliser un VPN pour contourner ces limitations.
+
+
+## Prérequis
+
+- Un Raspberry Pi 2, 3 ou 4 (Les RPi 0 et 1 peuvent fonctionner mais nécessitent de bricoler un peu ... voir [cette issue](https://github.com/YunoHost/issues/issues/1423)) ;
+- Un adaptateur secteur pour alimenter la carte ;
+- Une carte microSD : au moins **8 Go** et **Classe 10** (par exemple une [Transcend 300x](http://www.amazon.fr/Transcend-microSDHC-adaptateur-TS32GUSDU1E-Emballage/dp/B00CES44EO)) ;
+- Un câble ethernet/RJ-45 pour brancher la carte à votre routeur/box internet. (Avec le Raspberry Pi 0, vous pouvez connecter votre carte avec un câble OTG et un adaptateur Wifi USB.)
+- Un [fournisseur d’accès correct](/isp), de préférence avec une bonne vitesse d’upload.
+
+---
+
+## Installation avec l'image pré-installée (recommandée)
+
+
1. Télécharger l'image pour Raspberry Pi
+
+
2. Flasher la carte SD avec l'image
+
+
3. Démarrer la carte et se connecter à l'interface web sur `yunohost.local`
+
+
4. Effectuer la configuration initiale (post-installation)
+
+---
+
+## Installation manuelle (déconseillée)
+
+
+Nous déconseillons l'installation manuelle car elle est plus technique et plus longue que l'installation via l'image pré-installée. Cette documentation est surtout destinée aux utilisateurs avancés.
+
+
+
+Les dernières versions de Raspbian nécessitent un écran et un clavier, car il n'est plus possible de se connecter directement en SSH au Raspberry par défaut. Néanmoins, il est possible de réactiver le lancement de SSH au boot : il suffit de placer dans la partition boot de la carte SD un fichier nommé `ssh`, vide et sans extension.
+
+
+0. Installez Raspberry Pi OS Lite ([instructions](https://www.raspberrypi.org/downloads/raspberry-pi-os/)) sur la carte SD.
+Le lien vers Raspberry Pi OS Lite est ici : https://downloads.raspberrypi.org/raspbian_lite/images/
+
+1. Connectez-vous en SSH au Raspberry Pi avec l'utilisateur pi. Définissez un mot de passe root avec
+```bash
+sudo passwd root
+```
+
+2. Modifiez `/etc/ssh/sshd_config` pour autoriser root à se logger en SSH, en remplaçant `PermitRootLogin without-password` par `PermitRootLogin yes`. Rechargez le daemon SSH avec `service ssh reload`, puis re-connectez-vous en root.
+
+3. Déconnectez-vous et reconnectez-vous avec l'utilisateur root cette fois.
+
+4. Poursuivez avec la
procédure d'installation manuelle générique.
+
diff --git a/install_on_virtualbox.md b/install_on_virtualbox.md
new file mode 100644
index 00000000..96eff312
--- /dev/null
+++ b/install_on_virtualbox.md
@@ -0,0 +1,84 @@
+# Install YunoHost on VitualBox
+
+*Find other ways to install YunoHost **[here](/install)**.*
+
+## Requirements
+
+

+
+* An x86 computer with VirtualBox installed and enough RAM capacity to be able to run a small virtual machine.
+* The latest stable **YunoHost ISO image**, available [here](/images).
+
+
+N.B. : Installing YunoHost in a VirtualBox is usually intended for testing. To
+run an actual server on the long-term, you usually need a dedicated physical
+machine (old computer, ARM board...) or a VPS online.
+
+
+---
+
+##
1. Create a new virtual machine
+
+

+
+
+
+* It's okay if you can only have 32-bit versions, just be sure that you downloaded the 32-bit image previously.
+* 256MB RAM is the minimum required, but at least 512MB is recommended (1Go or more if you can).
+* 8GB storage is the minimum required for the system, add whatever is necessary for your apps.
+
+---
+
+##
2. Change network settings
+
+**NB:** You must carry out this step. If not, the install will fail.
+
+Go to **Settings** > **Network**:
+
+

+
+
+
+* Select `Bridged adapter`
+
+* Select your interface's name:
+
+ **wlan0** if you are connected wirelessly, else **eth0**.
+
+---
+
+##
3. Boot up the virtual machine
+
+Start the virtual machine
+
+

+
+
+
+You will have to select your ISO image here, then you should see the YunoHost's boot screen.
+
+
+
+If you encounter the error "VT-x is not available", you need probably need to enable Virtualization in the BIOS of your computer.
+
+
+
+

+
+
+
+* Select `Graphical install`
+
+* Select your language, your location, your keyboard layout and let the installer do the rest :-)
+
+---
+
+##
4. Proceed to post-installation
+
+After the reboot, the system should ask you to proceed with the
+post-installation
+
+
Post-install documentation
+
+
+
diff --git a/install_on_virtualbox_es.md b/install_on_virtualbox_es.md
new file mode 100644
index 00000000..e359db06
--- /dev/null
+++ b/install_on_virtualbox_es.md
@@ -0,0 +1,76 @@
+# Instalar YunoHost en VirtualBox
+
+*Encontrar otros medios de instalar YunoHost **[aquí](/install)**.*
+
+## Prerrequisitos
+
+

+
+* Un ordenador x86 con VirtualBox instalado y bastante RAM disponible para iniciar una pequeña máquina virtual.
+* La última **imagen ISO YunoHost** estable, disponible [aquí](/images).
+
+
+N.B. : Instalar YunoHost en VirtualBox es útil para probar la distribución. Para realmente autoalojarse a largo plazo, probablement necesitarás una máquina virtual (viejo ordenador, tarjeta ARM...) o un VPS.
+
+
+---
+
+##
1. Crear una nueva máquina virtual
+
+

+
+
+
+* No es grave si sólo la versión 32-bit está disponible, pero en este caso asegúrate que 32 bit previamente.
+* 256Mo de RAM es el requisito mínimo, 512Mo está recomendado (1Go o más si puedes).
+* 8Go de almacenaje mínimo requisito.
+
+---
+
+##
2. Modificar la configuración de la red
+
+Ir a **Settings** > **Network** :
+
+

+
+
+
+* Selectiona `Bridged adapter`
+
+* Elige tu interfaz según su nombre :
+
+ **wlan0** si estás conectado sin hilo, **eth0** de otro modo.
+
+---
+
+##
3. Inicia tu máquina virtual
+
+Inicia tu máquina virtual
+
+

+
+
+
+Aquí tienes que seleccionar la imagen ISO, luego deberías ver esta pantalla de bienvenida.
+
+
+
+Si te encuentras con el error "VT-x is not available", probablement hay que activar (enable) la virtualización en la opciones del BIOS de tu ordenador.
+
+
+
+

+
+
+
+* Elige `Instalación gráfica`
+
+* Selecciona tu idioma, tu ubicación, la distribución de tu teclado y deja el ordenador terminar el proceso :-)
+
+---
+
+##
4. Efectuar la post-instalación
+
+Después del reinicio, la máquina debería proponerte de efectuar la post-instalación :
+
+
Documentación de post-instalación
diff --git a/install_on_virtualbox_fr.md b/install_on_virtualbox_fr.md
new file mode 100644
index 00000000..8b851596
--- /dev/null
+++ b/install_on_virtualbox_fr.md
@@ -0,0 +1,81 @@
+# Installer YunoHost sur VirtualBox
+
+*Trouvez d’autres moyens d’installer YunoHost **[ici](/install)**.*
+
+## Prérequis
+
+

+
+* Un ordinateur x86 avec VirtualBox installé et assez de RAM disponible pour lancer une petite machine virtuelle.
+* La dernière **image ISO YunoHost** stable, disponible [ici](/images).
+
+
+N.B. : Installer YunoHost dans une VirtualBox est utile pour tester la
+distribution. Pour réellement s'autohéberger sur le long terme, il vous faudra
+probablement une machine physique (vieil ordinateur, carte ARM...) ou un VPS en
+ligne.
+
+
+---
+
+##
1. Créer une nouvelle machine virtuelle
+
+

+
+
+
+* Ce n'est pas grave si seulement la version 32-bit est dispo, mais dans ce cas soyez sur d'avoir téléchargé l'image 32 bit précédemment.
+* 256Mo de RAM est le minimum requis, 512Mo est recommandé (1Go ou plus si vous pouvez).
+* 8Go de stockage minimum requis pour le système, y ajouter l'espace pour vos applications.
+
+---
+
+##
2. Modifier la configuration réseau
+
+Allez dans **Réglages** > **Réseau** :
+
+

+
+
+
+* Sélectionnez `Accès par pont`
+
+* Choisissez votre interface selon son nom :
+
+ **wlan0** si vous êtes connecté sans-fil, **eth0** sinon.
+
+---
+
+##
3. Lancer votre machine virtuelle
+
+Démarrez votre machine virtuelle
+
+

+
+
+
+Vous devez sélectionner ici l’image ISO, puis vous devriez voir cet écran d’accueil YunoHost.
+
+
+
+Si vous rencontrez l'erreur "VT-x is not available", il vous faut probablement activer (enable) la virtualisation dans les options du BIOS de votre ordinateur.
+
+
+
+

+
+
+
+* Choisissez `Installation graphique`
+
+* Sélectionnez votre langue, votre emplacement, la disposition de votre clavier et laissez l’installeur faire le reste :-)
+
+---
+
+##
4. Effectuer la post-installation
+
+Après le redémarrage, la machine devrait vous proposer d'effectuer la
+post-installation :
+
+
Post-install
+documentation
diff --git a/install_on_vps.md b/install_on_vps.md
new file mode 100644
index 00000000..16578276
--- /dev/null
+++ b/install_on_vps.md
@@ -0,0 +1,19 @@
+# Install on a dedicated server
+
+*Find other ways to install YunoHost **[here](/install)**.*
+
+### Pre-requisite
+
+

+
+* A dedicated or virtual private server
+* with at least **512MB** RAM
+* and **Debian 10.x (Buster) 64bits** as operating system
+
+---
+
+## Installation steps
+
+
1. Install manually
+
+
2. Proceed with the initial configuration (post-installation)
diff --git a/install_on_vps_de.md b/install_on_vps_de.md
new file mode 100644
index 00000000..57916779
--- /dev/null
+++ b/install_on_vps_de.md
@@ -0,0 +1,20 @@
+# Installation auf einem dedizierten Server
+
+*Andere Wege Yunohost zu installieren findest Du **[hier](/install)**.*
+
+### Vorraussetzungen
+
+

+
+* Ein dedizierter (Root-Server) oder virtueller privater Server (VPS)
+* mit mindestens **512MB** RAM
+* und **Debian 10.x (Buster) 64bits** als Betriebssystem
+
+---
+
+## Installationsschritte
+
+
1. Manuelle Installation
+
+
2. Weiter mit der Erstkonfiguration (nach der Installation)
+
diff --git a/install_on_vps_es.md b/install_on_vps_es.md
new file mode 100644
index 00000000..abf498f4
--- /dev/null
+++ b/install_on_vps_es.md
@@ -0,0 +1,20 @@
+# Instalación en un servidor dedicado
+
+*Encontrar otros medios de instalar YunoHost **[aquí](/install)**.*
+
+## Prerrequisitos
+
+

+
+* Un servidor dedicado o virtual
+* con al menos **512MB** RAM
+* y **Debian 10.x (Buster) 64bits** como sistema operativo
+
+---
+
+## Etapas de instalación
+
+
1. Instalar manualmente
+
+
2. Post-instalación
+
diff --git a/install_on_vps_fr.md b/install_on_vps_fr.md
new file mode 100644
index 00000000..09d224db
--- /dev/null
+++ b/install_on_vps_fr.md
@@ -0,0 +1,19 @@
+# Installation sur un serveur dédié
+
+*Trouvez d’autres moyens d’installer YunoHost **[ici](/install)**.*
+
+## Prérequis
+
+

+
+* Un serveur dédié ou virtuel
+* avec au moins **512MB** RAM
+* et **Debian 10.x (Buster) 64bits** comme système d'exploitation
+
+---
+
+## Étapes d’installation
+
+
1. Installer manuellement
+
+
2. Effectuer la configuration initiale (post-installation)
diff --git a/install_on_vps_it.md b/install_on_vps_it.md
new file mode 100644
index 00000000..66658d32
--- /dev/null
+++ b/install_on_vps_it.md
@@ -0,0 +1,20 @@
+# Installa su un server dedicato
+
+*Scopri altri modi di installare YunoHost **[qui](/install)**.*
+
+### Pre-requisiti
+
+

+
+* Un server dedicato o un server privato virtuale (VPS)
+* con almeno **512MB** di RAM
+* e **Debian 10.x (Buster) 64bits** come sistema operativo
+
+---
+
+## Procedura di installazione
+
+
1. Installa manualmente
+
+
2. Post-installazione
+
diff --git a/ipv6.md b/ipv6.md
new file mode 100644
index 00000000..fc183f2d
--- /dev/null
+++ b/ipv6.md
@@ -0,0 +1,46 @@
+# Setting up IPv6
+
+IPv6 may work out of the box in many cases. But in some cases or some specific provider, you may need to tweak things manually to enable IPv6.
+
+## With a VPS from OVH
+
+OVH give one IPv4 address and one IPv6 address for VPS but by default, only IPv4 is OK.
+The OVH's documentation is here : https://docs.ovh.com/gb/en/vps/configuring-ipv6/
+
+### Configure the DNS server
+
+Here : https://yunohost.org/#/dns_subdomains
+
+### Configure the server
+
+On the OVH panel, you will copy 3 element :
+- the IPv6 address
+- the IPv6 gateway address
+- the IPv6 prefix. On OVH's VPS SSD, prefixes are `/128` because you have only *one* IPv6 address.
+
+On your VPS, create a backup of the network configuration with : `cp /etc/network/interfaces ~/interfaces` in home directory.
+Then, you can edit the configuration file (`/etc/network/interfaces`) with the following. It is assumed that :
+
+
+In this example, it is assumed that your network interface is `eth0`. If it's different (check with `ip a`) you need to adapt the example below.
+
+
+```plaintext
+iface eth0 inet6 static
+address
+netmask
+post-up /sbin/ip -6 route add dev eth0
+post-up /sbin/ip -6 route add default via dev eth0
+pre-down /sbin/ip -6 route del default via dev eth0
+pre-down /sbin/ip -6 route del dev eth0
+```
+
+Now, save the file and restart the network service with : `service networking restart`. (TODO : ideally we should find a way to validate the content of the configuration, otherwise it could fuck up the network stack and get disconnected from the VPS ?)
+
+Check your configuration with these commands :
+- `ip a` to display network interfaces and addresses
+- `hostname -I` to display the system IP addresses
+- try to ping an IPv6 server (for example you can use `ping6 ip6.yunohost.org`)
+- try to ping your server from your PC (assuming your PC has IPv6 enabled)
+
+If it's ok, it's ok !
diff --git a/ipv6_fr.md b/ipv6_fr.md
new file mode 100644
index 00000000..6c37e224
--- /dev/null
+++ b/ipv6_fr.md
@@ -0,0 +1,46 @@
+# Configuration de l’IPv6
+
+L'IPv6 peut fonctionner directement dans certains cas. Mais dans d'autres, ou chez certains hébergeurs spécifiques, vous devez activer l'IPv6 manuellement.
+
+## Avec un VPS chez OVH
+
+OVH donne une adresse IPv4 et une IPv6 pour ses VPS, mais par défaut, seule l'IPv4 fonctionne.
+La documentation d'OVH à ce sujet est ici : https://docs.ovh.com/fr/vps/configurer-ipv6/
+
+### Configurer le serveur DNS
+
+Ici : https://yunohost.org/#/dns_subdomains
+
+### Configurer le serveur
+
+Sur le panneau de gestion d'OVH, vous aller récupérer 3 informations :
+- l'adresse IPv6 du serveur
+- l'adresse passerelle IPv6
+- le préfixe IPv6. Les offres VPS SSD d'OVH ne fournissent qu'**une** seule adresse IPV6, le préfixe est donc `/128`
+
+Sur votre VPS, vous aller créer une sauvegarde de votre fichier de configuration des interfaces réseau dans votre répertoire home avec la commande : `cp /etc/network/interfaces ~/interfaces`.
+
+Ensuite, vous pouvez modifier le fichier de configuration `/etc/network/interfaces`.
+
+Dans cet exemple, nous considérons que votre interface réseau est `eth0`. Si elle est différente (vérifiez avec `ip a`) vous devez adapter l'exemple pour correspondre à votre situation.
+
+
+```plaintext
+iface eth0 inet6 static
+address
+netmask
+post-up /sbin/ip -6 route add dev eth0
+post-up /sbin/ip -6 route add default via dev eth0
+pre-down /sbin/ip -6 route del default via dev eth0
+pre-down /sbin/ip -6 route del dev eth0
+```
+
+Maintenant, enregistrez le fichier et redémarrez les services réseau avec : `service networking restart`. (TODO : ideally we should find a way to validate the content of the configuration, otherwise it could fuck up the network stack and get disconnected from the VPS ?)
+
+Vérifiez votre configuration avec les commandes :
+- `ip a` pour afficher les adresses IP des interfaces
+- `hostname -I` pour afficher les adresses IP du système
+- essayez de faire un test de `ping` sur un serveur IPv6 (vous pouvez utiliser `ping6 ipv6.yunohost.org`)
+- essayez de faire un test de `ping` sur votre server depuis votre PC (cela exige que votre PC puisse utiliser l'IPv6)
+
+Et voilà !
diff --git a/isp.md b/isp.md
new file mode 100644
index 00000000..477f175b
--- /dev/null
+++ b/isp.md
@@ -0,0 +1,72 @@
+# Internet service providers
+
+ Main configuration box
+
+Here is a non-comprehensive list of internet service providers by country, which contains criteria about tolerance to self-hosting.
+
+A "no" may cause problems for using your server or may require you to make additional configuration changes. Status in brackets indicates the default behavior.
+
+A list of French and Belgian ISPs is available on the [french page](/isp_fr).
+
+### USA
+| Service provider | Box (modem/router) | uPnP available | Port 25 openable | [Hairpinning](http://en.wikipedia.org/wiki/Hairpinning) | Customizable reverse DNS | Fix IP |
+| --- | --- | --- | --- | --- | --- | --- |
+| Cox | Multiple | Yes | No. Only for business class customer. | No | No | Yes, as a business class customer |
+| Charter | Multiple | Yes | No. Only for business class customer. | No | No | Yes, as a business class customer |
+| DSLExtreme | Multiple | Yes | Yes | No | No | Yes, extra charge. |
+| AT&T| Multiple | Yes | No. Only for business class customer. | unknown. | unknown. | unknown. |
+| Xfinity (Comcast)| Multiple | Yes | No. Only for business class customer. | unknown. | unknown. | Yes, as a business class customer|
+
+### UK
+| Service provider | Box (modem/router) | uPnP available | Port 25 openable | [Hairpinning](http://en.wikipedia.org/wiki/Hairpinning) | Customizable reverse DNS | Fix IP |
+| --- | --- | --- | --- | --- | --- | --- |
+| BT Internet | Yes | - | Yes| - | - | No |
+| Virgin Media | Yes | - | - | - | No | No |
+| ZEN Internet | Yes | - | Yes | - | Yes | - |
+| PlusNet | Yes | Yes | Yes | No | - | Small one off Charge |
+
+### Brazil
+| Service provider | Box (modem/router) | uPnP available | Port 25 openable | [Hairpinning](http://en.wikipedia.org/wiki/Hairpinning) | Customizable reverse DNS | Fix IP |
+| --- | --- | --- | --- | --- | --- | --- |
+| Global Village Telecom | Multiple | Yes | No. Only for Fix IP| No | No | Yes, extra charge. |
+
+### Ireland
+| Service provider | Box (modem/router) | uPnP available | Port 25 openable | [Hairpinning](http://en.wikipedia.org/wiki/Hairpinning) | Customizable reverse DNS | Fix IP |
+| --- | --- | --- | --- | --- | --- | --- |
+| Whizzy Internet | Multiple | Yes | Yes| Yes | Yes | Yes |
+
+### Canada
+| Service provider | Box (modem/router) | uPnP available | Port 25 openable | [Hairpinning](http://en.wikipedia.org/wiki/Hairpinning) | Customizable reverse DNS | Fix IP |
+| --- | --- | --- | --- | --- | --- | --- |
+| Telus | Multiple | - | No. Extra charge | - | - | No. Extra charge |
+| TekSavvy | Multiple | - | Yes | No | - | No. Extra charge |
+
+### Sweden
+
+| Service provider | Box (modem/router) | uPnP available | Port 25 openable | [Hairpinning](http://en.wikipedia.org/wiki/Hairpinning) | Customizable reverse DNS | Fix IP |
+| --- | --- | --- | --- | --- | --- | --- |
+| Telia | Multiple | Yes | No. Business only. | Yes | No. Business only. | No. Business only. |
+| Bredbandsbolaget | Multiple | Yes | No. Business only. | Yes | No. Business only. | No. Business only. |
+| Ownit | Multiple | Yes | Yes | N/A? | ? | Yes |
+
+Ownit reserves port 3 and 4 of their router to TV. With a simple call to their hotline, explaining that you want to selfhost, they can reassign one of the ports to be in bridge mode. It means that your server will have its own public fixed IP address, in addition to the modem's.
+
+### Switzerland
+
+Most of non business IP provided by ISP are blacklisted.
+
+| Service provider | Box (modem/router) | uPnP available | Port 25 openable | [Hairpinning](http://en.wikipedia.org/wiki/Hairpinning) | Customizable reverse DNS | Fix IP |
+| --- | --- | --- | --- | --- | --- | --- |
+| Sunrise | Multiple | No | Yes | No | - | - |
+| Swisscom | Multiple | No | Yes | No | No | No |
+| VTX | Multiple | No | Yes | No | - | - |
+
+### South Korea
+
+| Service provider | Box (modem/router) | uPnP available | Port 25 openable | [Hairpinning](http://en.wikipedia.org/wiki/Hairpinning) | Customizable reverse DNS | Fix IP |
+| --- | --- | --- | --- | --- | --- | --- |
+| LG U+ (HelloVision) | Multiple | Yes | Yes (Without ISP Router) | No | - | Partial |
+| KT(SkyLife, Qook&Show) | Multiple | Yes | Yes | No | - | Partial |
+| SKT (SK Broadband) | Multiple | Yes | Yes | No | - | Partial |
+
+If you want to add international ISPs information, please do consider [modifying this page](/write_documentation).
diff --git a/isp_box_config.md b/isp_box_config.md
new file mode 100644
index 00000000..93247eb6
--- /dev/null
+++ b/isp_box_config.md
@@ -0,0 +1,51 @@
+# Configure port-forwarding
+
+If you are self-hosting at home and without a VPN, you need to forward ports on your home router ("Internet box"). If you want a short explanation on what is and why you need port forwarding, have a look to [this page](port_forwarding).
+
+### 0. Diagnose ports opened
+
+The new diagnosis tool introduced in 3.8 can be used to diagnose that ports are
+correctly exposed.
+
+### 1. Access your box/router administration interface
+
+Your box/router admin interface is usually reachable via http://192.168.0.1 or http://192.168.1.1. Then, you will probably need to authenticate yourself with your internet server provider's credentials.
+
+### 2. Find the local IP of your server
+
+Identify what is thei *local* IP of your server, either :
+- from your box/router interface, which might list devices connected
+- from the YunoHost webadmin, in 'Diagnosis', section 'Internet connectivity', click on 'Details' on the IPv4 report.
+- from the command line in your server, by running `hostname -I`
+
+A local IP address typically looks like `192.168.xx.yy`, or `10.0.xx.yy`.
+
+The local IP address needs to be static, so that the port forwards that you are going to configure in the next step will always reach your server. You should go into your box/router and make sure that the local IP address of your server is static instead of dynamic.
+
+### 3. Forwarding ports
+
+In your router admin interface, look for something like 'router configuration' or 'port forwarding'. The naming differs among the various kinds of boxes.
+
+Opening the ports listed below is necessary for the various services available in YunoHost to work. For each of them, the 'TCP' forwarding is needed. Some interfaces refer to 'external' and 'internal' ports : these are the same in our case.
+
+* Web: 80 (HTTP), 443 (HTTPS)
+* [SSH](/ssh): 22
+* [XMPP](/XMPP): 5222 (clients), 5269 (servers)
+* [Email](/email): 25, 587 (SMTP), 993 (IMAP)
+
+If you use both a modem and a router, then you need to do the following:
+1. first on the modem (the box closest to the internet) create rules to forward the above ports to your router;
+2. then on the router (the box between the modem and your devices) create rules to forward the above ports to the static IP address for your server.
+
+
+ Some internet service providers block port 25 (mail SMTP) by default to fight spam. Some other ISP don't allow to use port 80/443 (web) freely, though it's less likely. Depending on the ISP, it might be possible to open them in the admin interface... Check [this page](/isp) for more info.
+
+
+## Automatic port forwarding / UPnP
+
+A technology called UPnP is available on some internet boxes / routers and allows to automatically forward ports by the machine who needs them. If UPnP is enabled in your local network, then running this command should automatically open the port for you :
+
+```bash
+sudo yunohost firewall reload
+```
+
diff --git a/isp_box_config_es.md b/isp_box_config_es.md
new file mode 100644
index 00000000..022cc596
--- /dev/null
+++ b/isp_box_config_es.md
@@ -0,0 +1,48 @@
+# Configurar la redirección de los puertos
+
+Si te estás auto-alojando en casa y sin VPN, tienes que redirigirse los puertos de tu router (caja/box). Si quieres una explicación sencilla de lo que es y por qué necesitas redirigir los puertos, puedes echar un vistazo a [esta página](/port_forwarding). [Esta página](https://www.testdevelocidad.es/configuraciones/abrir-correctamente-los-puertos-router/) también propone explicaciones detalladas sobre el funcionamiento de los puertos, y las etapas de configuración para un router genérico.
+
+### 0. Diagnosticar los puertos abiertos
+
+Una vez que tienes la redirección configurada, deberías poder comprobar que los puertos están bien abiertos con esta herramienta :
+
+Comprobar la redirección de los puertos
+
+### 1. Acceder a la interfaz de administración de tu router/caja/box
+
+En general la interfaz de administración está accesible desde http://192.168.0.1 o http://192.168.1.1.
+Luego, es posible que tengas que autenticarte con los ID provechos pour tu proveedor de acceso a Internet.
+
+### 2. Descubrir la IP local del servidor
+
+Identifica cuál es la IP local de tu servidor, o sea :
+- desde la interfaz de tu router/caja/box, donde tal vez estén listados los dipositivos conectados a la red local
+- desde la webadmin de YunoHost, en 'Estado del servidor', 'Red'
+- desde la línea de comandos en tu servidor, por ejemplo con `ip a | grep "scope global" | awk '{print $2}'`
+
+En general una dirección IP local se parece a `192.168.xx.yy`, o `10.0.xx.yy`.
+
+### 3. Redirigir los puertos
+
+En la interfaz de administración de tu router/caja/box, tienes que encontrar una categoría que debe llamarse 'Configuración del router', o 'Redirección de puertos'. El nombre difiere según el tipo o la marca del router / de la caja Internet...
+
+Luego tienes que redirigir cada uno de los puertos listados a continuación hacia la IP local de tu router para que los varios servicios de YunoHost funcionen. Para cada uno de ellos, una redirección 'TCP' es necesaria. En algunas interfaces, tal vez encontrarás referencias a un puerto 'externo' y un puerto 'interno' : en nuestro caso, se trata del mismo número de puerto, que sea interno o externo.
+
+* Web: 80 (HTTP), 443 (HTTPS)
+* [SSH](/ssh): 22
+* [XMPP](/XMPP): 5222 (clients), 5269 (servers)
+* [Email](/email): 25, 587 (SMTP), 993 (IMAP)
+
+
+ Algunos proveedores de acceso a Internet bloquean el puerto 25 (mail SMTP) por defecto para luchar con el spam. Otros (más escasos) no permiten utilizar libremente los puertos 80/443. Dependiendo de tu proveedor, puede ser posible de abrir estos puertos en la interfaz... Ver [esta página](/isp) por más informaciones.
+
+
+## Redirección automática / UPnP
+
+Una tecnología llamada UPnP está disponible en algunos routers/cajas/box y permite redirigir automáticamente puertos hacia una máquina que lo pide. Si UPnP está activado en tu casa, ejecutar este comando debería automáticamente redirigir los puertos correctos :
+
+
+```bash
+sudo yunohost firewall reload
+```
+
diff --git a/isp_box_config_fr.md b/isp_box_config_fr.md
new file mode 100644
index 00000000..640044dc
--- /dev/null
+++ b/isp_box_config_fr.md
@@ -0,0 +1,50 @@
+# Configurer la redirection des ports
+
+Si vous vous auto-hébergez à la maison et sans VPN, il vous faut rediriger les ports de votre routeur ("machin-box"). Si vous souhaitez une explication courte de ce qu'est et pourquoi vous avez besoin de rediriger les ports, vous pouvez jeter un œil à [cette page-ci](/port_forwarding). [Cette page-là](https://craym.eu/tutoriels/utilitaires/ouvrir_les_ports_de_sa_box.html) propose également des explications détaillées sur le fonctionnement des ports, et les étapes de configuration pour différents routeurs.
+
+### 0. Diagnostiquer les ports ouverts
+
+Une fois les redirections configurées, l'outil de diagnostic introduit dans
+YunoHost 3.8 vous permettra de vérifier si les ports sont correctement exposés.
+
+### 1. Accéder à l'interface d'administration de votre box/routeur
+
+L'interface d'administration est généralement accessible via http://192.168.0.1 ou http://192.168.1.1.
+Ensuite, il vous faudra peut-être vous authentifier avec les identifiants
+fournis par votre fournisseur d'accès internet (FAI).
+
+### 2. Trouver l'IP locale de votre serveur
+
+Identifiez quelle est l'IP locale de votre serveur, soit :
+- depuis l'interface de votre routeur/box, qui liste peut-être les dispositifs
+ connectés;
+- depuis la webadmin de YunoHost, dans 'Diagnostic', section 'Connectivité Internet', cliquer sur 'Details' à côté de la ligne sur IPv4.
+- depuis la webadmin de YunoHost, dans 'État du serveur', 'Réseau';
+
+Une adresse IP locale ressemble généralement à `192.168.xx.yy`, ou `10.0.xx.yy`.
+
+### 3. Rediriger les ports
+
+Dans l'interface d'administration de votre box/routeur, il vous faut trouver
+une catégorie comme 'Configuration du routeur', ou 'Redirections de ports'. Le
+nom diffère suivant le type / marque de la box...
+
+Il vous faut ensuite rediriger chacun des ports listés ci-dessous vers l'IP locale de votre serveur pour que les différents services de YunoHost fonctionnent. Pour chacun d'eux, une redirection 'TCP' est nécessaire. Certains interfaces font références à un port 'externe' et un port 'interne' : dans notre cas il s'agit du même.
+
+* Web: 80 (HTTP), 443 (HTTPS)
+* [SSH](/ssh): 22
+* [XMPP](/XMPP): 5222 (clients), 5269 (servers)
+* [Email](/email): 25, 587 (SMTP), 993 (IMAP)
+
+
+ Certains fournisseurs d'accès internet bloquent le port 25 (mail SMTP) par défaut pour combattre le spam. D'autres (plus rares) ne permettent pas d'utiliser librement les ports 80/443. En fonction de votre FAI, il peut être possible d'ouvrir ces ports dans l'interface... Voir [cette page](/isp) pour plus d'informations.
+
+
+## Redirection automatique / UPnP
+
+Une technologie nommée UPnP est disponible sur certains routeurs/box et permet de rediriger automatiquement des ports vers une machine qui le demande. Si UPnP est activé chez vous, exécuter cette commande devrait automatiquement rediriger les bons ports :
+
+```bash
+sudo yunohost firewall reload
+```
+
diff --git a/isp_es.md b/isp_es.md
new file mode 100644
index 00000000..6c5ad805
--- /dev/null
+++ b/isp_es.md
@@ -0,0 +1,47 @@
+# Proveedores de acceso a Internet
+
+ Configuración general del router
+
+Aquí tienes una lista (no exhaustiva) de proveedores de acceso a Internet por país, con criterios de compatibilidad con el [self-hosting](/selfhosting).
+
+Un « **no** » puede implicar problemas de utilización del servidor o puede obligarte a hacer configuraciones adicionales. El estatus entre paréntesis indica el comportamiento por defecto.
+
+### Francia
+
+*Nota que algunos de estos proveedores como OVH y Orange también están presentes en España.*
+
+Todos los proveedores de acceso a Internet [miembros de la Federación French Data Network](http://www.ffdn.org/fr/membres) tienen una política a favor del auto-alojamiento / self-hosting.
+* ✔ : sí
+* ✘ : no
+
+| Proveedor de acceso | OVH | [Free](/isp_free) | [SFR](/isp_sfr) | [Orange](/isp_orange) | Bouygues
Télécom | Darty |
+| :---: | :---: | :---: | :---: | :---: | :---: | :---: |
+| **Box/router** | Personal/OVH Télécom | Freebox | Neufbox | Livebox | Bbox | Dartybox |
+| **[UPnP](https://fr.wikipedia.org/wiki/Universal_Plug_and_Play)** | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
+| **[Puerto 25 que se abre](/email)**
(cerrado por defecto) | ✔ | ✔ | ✔ | ✘ | ✔ | ✔ |
+| **[Hairpinning](http://fr.wikipedia.org/wiki/Hairpinning)** | ✔ | ✔ | ✔/✘ | ✘ | ✔ | ✔ |
+| **[Reverse DNS](https://en.wikipedia.org/wiki/Reverse_DNS_lookup)
personalizable ** | ✔ | ✔ (excepto IPv6) | … | ✘ | ✘ | ✘ |
+| **[IP fija](/dns_dynamicip)** | ✔ | ✔ | ✔/✘ | ✘ | ✔ | ✔ |
+| **[IPv6](https://fr.wikipedia.org/wiki/IPv6)** | ✔ | ✔ | ✔ | ✔ | … | … |
+| **[No listado en el DUL](https://en.wikipedia.org/wiki/Dialup_Users_List)** | … | ✘ | … | … | … | … |
+Para obtener una lista más completa y precisa, refiérete a la muy buena documentación (fr) de [wiki.auto-hebergement.fr](http://wiki.auto-hebergement.fr/fournisseurs/fai#d%C3%A9tail_des_fai).
+
+**Truco** : [FDN](http://www.fdn.fr) propone unos [VPN](http://www.fdn.fr/-VPN-.html) que permiten recuperar una (o varias si lo pides) IPv4 fija y un /48 en IPv6 y así « limpiar » tu conexión si tu proveedor es uno los *proveedores limitantes* de la tabla más arriba.
+
+### Bélgica
+
+| Proveedor de acceso | Box/ router | uPnP activable | [Puerto 25 que se abre](/email)| [Hairpinning](http://fr.wikipedia.org/wiki/Hairpinning) | [Reverse DNS](https://en.wikipedia.org/wiki/Reverse_DNS_lookup) | IP fija |
+| :---: | :---: | :---: | :---: | :---: | :---: | :---: |
+| **Proximus** | BBox2 | sí (activado) | sí | **no** | **no** | **no** |
+| | BBox3 | sí (activado) | sí | **no** | **no** | **no** |
+| **Scarlet** | BBox2 | sí (activado) | sí | **no** | **no** | **no** |
+
+**Proximus** no estaría a favor del auto-alojamiento. Hacen que la apertura de los puertos esté más difícil para luchar contra el spam. Es mejor pasar por [Neutrinet](http://neutrinet.be), uno de los [miembros de la Federación French Data Network](http://www.ffdn.org/fr/membres).
+
+### Costa de Marfil
+
+| Proveedor de acceso | Box/ router | uPnP activable | [Puerto 25 que se abre](/email)| [Hairpinning](http://fr.wikipedia.org/wiki/Hairpinning) | [Reverse DNS](https://en.wikipedia.org/wiki/Reverse_DNS_lookup) | IP fija |
+| :---: | :---: | :---: | :---: | :---: | :---: | :---: |
+| **Orange** | Livebox2 | sí (activado) | no | **no** | **no** | **no** |
+| **Moov** | | sí (activado) | | | | |
+| **MTN** | | sí (activado) | | | | |
\ No newline at end of file
diff --git a/isp_fr.md b/isp_fr.md
new file mode 100644
index 00000000..1630b19e
--- /dev/null
+++ b/isp_fr.md
@@ -0,0 +1,45 @@
+# Fournisseurs d’accès à Internet
+
+ Configuration générale box
+
+Voici une liste non exhaustive des fournisseurs d’accès à Internet par pays, contenant les critères de tolérance à l’[auto-hébergement](/selfhosting).
+
+Un « **non** » peut entraîner des problèmes d’utilisation de votre serveur ou peut vous obliger à faire des configurations supplémentaires. Le statut entre parenthèses indique le comportement par défaut.
+
+### France
+
+Tous les fournisseurs d’accès à Internet [membres de la Fédération French Data Network](http://www.ffdn.org/fr/membres) ont une politique favorable à l’auto-hébergement.
+* ✔ : oui
+* ✘ : non
+
+| Fournisseur d’accès | OVH | [Free](/isp_free) | [SFR](/isp_sfr) | [Orange](/isp_orange) | Bouygues
Télécom | Darty |
+| :---: | :---: | :---: | :---: | :---: | :---: | :---: |
+| **Box/routeur** | Personnel/OVH Télécom | Freebox | Neufbox | Livebox | Bbox | Dartybox |
+| **[UPnP](https://fr.wikipedia.org/wiki/Universal_Plug_and_Play)** | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
+| **[Port 25 ouvrable](/email)**
(fermé par défaut) | ✔ | ✔ | ✔ | ✘ | ✔ | ✔ |
+| **[Hairpinning](http://fr.wikipedia.org/wiki/Hairpinning)** | ✔ | ✔ | ✔/✘ | ✔ (depuis la Livebox 4) | ✔ | ✔ |
+| **[Reverse DNS](https://en.wikipedia.org/wiki/Reverse_DNS_lookup)
personnalisable ** | ✔ | ✔ (sauf IPv6, pas de support, et buggué sur certaines plages d'adresses ipv4) | … | ✘ | ✘ | ✘ |
+| **[IP fixe](/dns_dynamicip)** | ✔ | ✔ | ✔/✘ | ✔ (depuis la Livebox 4) | ✔ | ✔ |
+| **[IPv6](https://fr.wikipedia.org/wiki/IPv6)** | ✔ | ✔ | ✔ | ✔ | … | … |
+| **[Non listé sur le DUL](https://en.wikipedia.org/wiki/Dialup_Users_List)** | … | ✘ | … | … | … | … |
+Pour une liste plus complète et précise, référez-vous à la très bonne documentation de [wiki.auto-hebergement.fr](http://wiki.auto-hebergement.fr/fournisseurs/fai#d%C3%A9tail_des_fai).
+
+**Astuce** : [FDN](http://www.fdn.fr) fournit des [VPN](http://www.fdn.fr/-VPN-.html) permettant de rapatrier une (ou plusieurs sur demande) IPv4 fixe et un /48 en IPv6 et ainsi « nettoyer » votre connexion si vous êtes chez l’un des FAI *limitants* du tableau ci-dessus.
+
+### Belgique
+
+| Fournisseur d’accès | Box/ routeur | uPnP activable | [Port 25 ouvrable](/email)| [Hairpinning](http://fr.wikipedia.org/wiki/Hairpinning) | [Reverse DNS](https://en.wikipedia.org/wiki/Reverse_DNS_lookup) | IP fixe |
+| :---: | :---: | :---: | :---: | :---: | :---: | :---: |
+| **Proximus** | BBox2 | oui (activé) | oui | **non** | **non** | **non** |
+| | BBox3 | oui (activé) | oui | **non** | **non** | **non** |
+| **Scarlet** | BBox2 | oui (activé) | oui | **non** | **non** | **non** |
+
+**Proximus** ne serait pas ouvert à l’auto-hébergement. L’ouverture des ports serait plus difficile afin d’éviter tout SPAM. Il serait préférable de passer par [Neutrinet](http://neutrinet.be), un des [membres de la Fédération French Data Network](http://www.ffdn.org/fr/membres).
+
+### Côte d'Ivoire
+
+| Fournisseur d’accès | Box/ routeur | uPnP activable | [Port 25 ouvrable](/email)| [Hairpinning](http://fr.wikipedia.org/wiki/Hairpinning) | [Reverse DNS](https://en.wikipedia.org/wiki/Reverse_DNS_lookup) | IP fixe |
+| :---: | :---: | :---: | :---: | :---: | :---: | :---: |
+| **Orange** | Livebox2 | oui (activé) | non | **non** | **non** | **non** |
+| **Moov** | | oui (activé) | | | | |
+| **MTN** | | oui (activé) | | | | |
diff --git a/isp_free.md b/isp_free.md
new file mode 100644
index 00000000..e97c35fb
--- /dev/null
+++ b/isp_free.md
@@ -0,0 +1 @@
+Unfortunately, this page only exists [in french here](isp_free_fr) for now.
diff --git a/isp_free_fr.md b/isp_free_fr.md
new file mode 100644
index 00000000..58ebb590
--- /dev/null
+++ b/isp_free_fr.md
@@ -0,0 +1,73 @@
+# Free
+
+*Trouvez la liste d’autres fournisseurs d’accès Internet **[ici](/isp)**.*
+
+#### Accès à l’administration de la box (v5/v6)
+
+##### Freebox ≤ v5
+
+Rendez-vous sur la [console d'administration du site de free](https://subscribe.free.fr/login/).
+
+##### Freebox v6 (Revolution / Mini4k)
+
+Allez à l’adresse : [mafreebox.free.fr](http://mafreebox.free.fr/) puis authentifiez-vous.
+
+#### Ouverture des ports
+
+[Liste des ports à ouvrir](/isp_box_config).
+
+##### Freebox ≤ v5
+
+Cela se passe dans la section *Ma Freebox / Configurer mon routeur*. Il faut :
+
+- Rediriger les [ports à ouvrir](/isp_box_config) vers l'adresse locale de votre serveur YunoHost.
+- Définir une DMZ vers votre serveur YunoHost.
+
+La présence conjointe de ces deux règles permettent d'accéder à votre serveur de l'extérieur comme de l'intérieur de votre réseau local.
+
+##### Freebox v6
+[Tutoriel d’ouverture des ports sur Freebox](http://www.astuces-pratiques.fr/informatique/ouvrir-un-port-sur-la-freebox-revolution)
+
+
+#### Déblocage de l’envoi de courriel
+
+Pour pouvoir envoyer des mails, le déblocage se fait dans la [partie client](https://subscribe.free.fr/login/).
+
+Depuis le menu Ma freebox aller sur « Blocage SMTP sortant ».
+
+Pour pouvoir envoyer des mails, passer le blocage en « inactif ».
+
+#### Fonction NAS de la Freebox
+
+Il faut installer le paquet `cifs-utils`
+```bash
+$ sudo apt install cifs-utils
+```
+
+Il faut créer un point de montage (ici `/home/monlogin/freebox`)
+```bash
+$ mkdir ~/freebox
+```
+
+On monte le répertoire NAS par défaut avec les droits de lecture / écriture pour tous
+```bash
+$ sudo mount -t cifs //mafreebox.freebox.fr/Disque\ dur/ /home/monlogin/freebox -o guest,iocharset=utf8,file_mode=0777,dir_mode=0777
+```
+
+##### Automatiser le montage
+
+Une ligne a ajouter à la fin du `/etc/fstab` :
+```bash
+//mafreebox.freebox.fr/Disque\040dur/ /home/monlogin/freebox cifs _netdev,guest,uid=monlogin,gid=users,iocharset=utf8 0 0
+```
+
+Le `_netdev` signale que c'est un périphérique réseau, afin que le système ne le monte que s'il a accès au réseau.
+`guest` est le mode d'identification à la Freebox : pour une connexion authentifié, placer vos identifiants dans un fichier sous la forme
+```bash
+username=your_user
+password=your_pass
+domain=FREEBOX
+```
+et remplacer `guest` par `credentials=/path/to/file` (c'est aussi possible de spécifier directement `username=xx,password=xx` dans le fstab, mais déconseillé pour des raisons de sécurité)
+`uid` et `gid` sont pour les id user et group auxquels appartiendra le répertoire une fois monté. Par défault (sur la Freebox V5 en tout cas), ils se retrouvent avec les uid/gid de 4242.
+Il est aussi possible de mettre des droits particuliers avec les paramètres `file_mode=0777,dir_mode=0777`.
diff --git a/isp_orange.md b/isp_orange.md
new file mode 100644
index 00000000..6649ed5f
--- /dev/null
+++ b/isp_orange.md
@@ -0,0 +1,86 @@
+# Orange
+
+*Find the list of other Internet service providers **[here](/isp)**.*
+
+#### Email
+
+The Orange box has port 25 closed so as to limit the amount of spam that could be sent from a compromised home connection.
+
+The remaining solution to host one own's email at home is to route it through the Orange SMTP servers.
+
+To that end, one has to edit the postfix configuration file with the following command:
+
+```bash
+sudo nano /etc/postfix/main.cf
+```
+
+then, add the SMTP Orange server as a relay on the associated line:
+
+```bash
+relayhost = smtp.orange.fr
+```
+
+restart Postfix :
+
+```bash
+sudo service postfix restart
+```
+
+##### Problems
+
+If you are having an "Authentication required" error, the solution is as follows (note: french website): **[source](http://viruslocker.free.fr/?page_id=1749)**.
+
+Edit the postfix configuration file
+
+```bash
+sudo nano /etc/postfix/main.cf
+```
+then, add the following lines:
+
+```bash
+smtp_sasl_password_maps = hash:/etc/postfix/sasl/mdp_fai.conf
+smtp_sasl_auth_enable = yes
+smtp_sasl_security_options = noanonymous
+relayhost = [smtp.orange.fr]:25
+```
+
+Create the `mdp_fai.conf` file :
+
+```bash
+sudo nano /etc/postfix/sasl/mdp_fai.conf
+```
+
+add
+
+```bash
+# mdp_fai.conf
+[smtp.orange.fr]:25 emailaddress@at.orange:my-own-password
+```
+with your Orange account password.
+
+Integrate the password into Postfix :
+
+```bash
+sudo postmap /etc/postfix/sasl/mdp_fai.conf
+sudo postconf -e smtp_sasl_password_maps=hash:/etc/postfix/sasl/mdp_fai.conf
+```
+
+If you are having an "(SASL authentication failed; cannot authenticate to server smtp-auth.nowhere.com[38.123.22.160]: no mechanism available)" error
+
+Check that `libsasl2-modules` and `sasl2-bin` are present :
+
+```bash
+apt search libsasl2-modules
+apt search sasl2-bin
+```
+
+If they are not present, do install them :
+
+```bash
+apt install libsasl2-modules sasl2-bin
+```
+
+It is possible that postfix does not immediately take into account your modifications. To force it to do so, run
+```bash
+systemctl restart postfix
+```
diff --git a/isp_orange_fr.md b/isp_orange_fr.md
new file mode 100644
index 00000000..b6584b4a
--- /dev/null
+++ b/isp_orange_fr.md
@@ -0,0 +1,86 @@
+# Orange
+
+*Trouvez la liste d’autres fournisseurs d’accès Internet **[ici](/isp)**.*
+
+#### Le courrier électronique
+
+La box d’Orange bloque le port 25 pour limiter l’envoi de spam.
+
+La solution restante pour héberger son courrier chez soi consiste à le faire passer par les serveurs SMTP d’Orange.
+
+Pour cela, il faut éditer le fichier de configuration de postfix avec la commande :
+
+```bash
+sudo nano /etc/postfix/main.cf
+```
+
+puis, rajouter à la ligne le relai SMTP d’Orange :
+
+```bash
+relayhost = smtp.orange.fr
+```
+
+redémarrez Postfix :
+
+```bash
+sudo service postfix restart
+```
+
+##### Problèmes
+
+Si vous avez une erreur "Authentification requise", la solution est la suivante : **[source](http://viruslocker.free.fr/?page_id=1749)**.
+
+Éditer le fichier de configuration de postfix
+
+```bash
+sudo nano /etc/postfix/main.cf
+```
+puis, rajouter à la ligne :
+
+```bash
+smtp_sasl_password_maps = hash:/etc/postfix/sasl/mdp_fai.conf
+smtp_sasl_auth_enable = yes
+smtp_sasl_security_options = noanonymous
+relayhost = [smtp.orange.fr]:25
+```
+
+créer le fichier `mdp_fai.conf` :
+
+```bash
+sudo nano /etc/postfix/sasl/mdp_fai.conf
+```
+
+ajouter
+
+```bash
+# mdp_fai.conf
+[smtp.orange.fr]:25 adresseemail@chez.orange:son-mot-de-passe
+```
+avec votre mot de passe du compte d'orange.
+
+Intégrer le mot de passe à Postfix :
+
+```bash
+sudo postmap /etc/postfix/sasl/mdp_fai.conf
+sudo postconf -e smtp_sasl_password_maps=hash:/etc/postfix/sasl/mdp_fai.conf
+```
+
+Si vous avez une erreur "(SASL authentication failed; cannot authenticate to server smtp-auth.nowhere.com[38.123.22.160]: no mechanism available)"
+
+Vérifier la présence de `libsasl2-modules` et de `sasl2-bin` :
+
+```bash
+apt search libsasl2-modules
+apt search sasl2-bin
+```
+
+Si ils ne sont pas présents, installez-les :
+
+```bash
+apt install libsasl2-modules sasl2-bin
+```
+
+Il est possible que postfix ne prenne pas en compte tout de suite vos modifications. Pour le forcer à le faire, exécutez
+```bash
+systemctl restart postfix
+```
diff --git a/isp_sfr.md b/isp_sfr.md
new file mode 100644
index 00000000..e5002600
--- /dev/null
+++ b/isp_sfr.md
@@ -0,0 +1 @@
+Unfortunately, this page only exists [in french here](isp_sfr_fr) for now.
diff --git a/isp_sfr_fr.md b/isp_sfr_fr.md
new file mode 100644
index 00000000..73413126
--- /dev/null
+++ b/isp_sfr_fr.md
@@ -0,0 +1,14 @@
+# SFR
+*Trouvez la liste d’autres fournisseurs d’accès Internet **[ici](/isp)**.*
+#### Accès à l’administration de la box
+* Allez à cette adresse : http://192.168.1.1.
+* Authentifiez-vous, soit en appuyant sur le bouton de la box pendant 5 secondes soit avec les identifiants d’administration.
+
+
+
+#### Courrier électronique
+Pour pouvoir envoyer des mails, il faut désactiver le filtrage.
+
+
+
+Source : https://assistance.sfr.fr/sfrmail-appli/sfrmail/envoyer-e-mail-serveur-smtp.html
diff --git a/jessie_stretch_migration.md b/jessie_stretch_migration.md
new file mode 100644
index 00000000..b2c78bce
--- /dev/null
+++ b/jessie_stretch_migration.md
@@ -0,0 +1,59 @@
+# Migrating an existing instance to Stretch
+
+This page is dedicated to help you migrating an instance from YunoHost 2.7.x (running on Debian Jessie/8.x) to YunoHost 3.0 (running on Debian Stretch/9.x).
+
+## Important notes
+
+- The YunoHost team did its best to make sure that the migration is as smooth as possible and was tested over the course of several months in several cases.
+
+- With that said, please be aware that this is a delicate operation. System administration is a complicated topic and covering every particular cases is quite hard. Therefore, if you host critical data and services, please [make backups](/backup). And in any case, be patient and attentive during the migration.
+
+- Yet, please don't rush into thinking that you should rush into reinstalling your system. A common "mistake" is to be willing to reinstall a server at the slightest complication. But turns out that reinstalling a system can also be complicated. Instead, if you happen to run into issues, we encourage you to try to investigate and understand what's going on and reach for help instead of just throwing away everything because it looks simpler.
+
+- About external email clients: if you or your users are using external email clients (typically Thunderbird, K9Mail...) be aware that the SMTP port changed from 465 (with SSL/TLS) to 587 (STARTTLS). See [this page of doc dedicated to email clients](/email_configure_client). Webmail configurations such as Rainloop should also be updated using the corresponding administration interface.
+
+- For advanced users: if you have some custom scripts for backups, be aware that we made some backward-incompatible changes in the backup command line. The deprecated `--hooks`/`--ignore-hooks` options were removed, as well as the options `--ignore-apps`, `--ignore-system`. To make things more intuitive, `yunohost backup create --apps wordpress` (for example) will only backup wordpress, i.e. you don't have to add `--ignore-system` to not backup the system.
+
+## Migration procedure
+
+#### From the webadmin
+
+After upgrading to 2.7.14, go to Tools > Migrations to access the migrations interface. You will have to read carefully and accept the disclaimer then launch the migration. The logs will be shown in the message bar (you can hover it to see the whole history).
+
+#### From the command line
+
+After upgrading to 2.7.14, run:
+
+```bash
+sudo yunohost tools migrations migrate
+```
+
+then read carefully and accept the disclaimer.
+
+## During the migration
+
+Depending on your hardware and packages installed, the migration might take up to a few hours.
+
+Note that it is expected to see some errors (in particular about Fail2Ban) during the migration, so don't worry too much about them.
+
+#### If the migration crashed / failed at some point.
+
+If the migration failed at some point, it should be possible to relaunch it. If it still doesn't work, you can try to [get help](/help) (please provide the corresponding messages or whatever makes you tell that it's not working).
+
+## What to do after the upgrade
+
+#### Check that you actually are on Debian Stretch and YunoHost 3.0
+
+You should be able to see this from the webadmin Tools > Diagnosis, and also in the footer of the page. On the command line, you can use `lsb_release -a` and `yunohost --version`.
+
+#### Check that Fail2Ban and the firewall are active
+
+You should be able to see that Fail2Ban and the firewall are active. From the webadmin in Services (look for 'fail2ban' and 'yunohost-firewall'). From the command line, run `yunohost service status fail2ban yunohost-firewall`. They should both have `active: active`.
+
+#### Check that your applications are working
+
+Test that your applications are working. If they aren't, you should try to upgrade them (it is also a good idea to upgrade them even if they are working anyway).
+
+#### Mail users: check your mail score
+
+If you are using mails (especially sending them), check that your score is still good by using [mail-tester](https://www.mail-tester.com/) for example.
diff --git a/jessie_stretch_migration_fr.md b/jessie_stretch_migration_fr.md
new file mode 100644
index 00000000..067f782d
--- /dev/null
+++ b/jessie_stretch_migration_fr.md
@@ -0,0 +1,59 @@
+# Migrer vers Stretch
+
+L'objectif cette page est de décrire le processus de migration d'une instance en YunoHost 2.7.x (tournant sous Debian Jessie/8.x) vers YunoHost 3.0 (tournant sous Debian Stretch/9.x)
+
+## Notes importantes
+
+- L'équipe de YunoHost a fait de son mieux pour que cette migration se passe autant en douceur que possible. Elle a été testée durant plusieurs mois et sur plusieurs types d'installations.
+
+- Néanmoins, vous devez être conscient qu'il s'agit d'une opération délicate. L'administration système est un sujet compliqué et couvrir tous les cas particuliers n'est pas chose aisée. En conséquence, si vous hébergez des données et des systèmes critiques, [faites des sauvegardes](/backup). Et dans tous les cas, soyez patients et attentifs durant la migration.
+
+- Cependant, ne vous précipitez pas non plus à vouloir faire une réinstallation de votre système. Une attitude qui revient régulièrement est de vouloir réinstaller son système à la moindre complication. Pourtant, réinstaller peut aussi s'avérer compliqué. À la place, si vous rencontrez des problèmes, nous vous encourageons à investiguer, chercher à comprendre et trouver de l'aide, plutôt que de se précipiter à vouloir réinstaller simplement parce que cela semble plus simple.
+
+- Si vous ou vos utilisateurs utilisez des clients emails externes (typiquement Thunderbird ou K9Mail) : le port SMTP a changé. Il s'agissait auparavant du port 465 (avec SSL/TLS) qui a été remplacé par 587 (STARTTLS). Voir [cette page de doc dédiée à la configuration des clients mails](/email_configure_client). La configuration des webmails comme Rainloop doit également être mise à jour, en passant par l'interface d'administration dédiée.
+
+- Pour les utilisateurs avancés : si vous avez des scripts personnels pour faire des backups, certains changements cassent (de façon mineure) la rétrocompatibilité de la ligne de commande. Les options dépréciées `--hooks`/`--ignore-hooks` ont été enlevées, ainsi que `--ignore-apps`, `--ignore-system`. Pour rendre les choses plus intuitives, `yunohost backup create --apps wordpress` (par exemple) créera uniquement un backup de wordpress, c.-à-d. pas besoin d'ajouter `--ignore-system` pour ne pas backuper le système.
+
+## Procédure de migration
+
+#### Depuis la webadmin
+
+Après avoir mis à jour vers la version 2.7.14, allez dans Outils > Migrations pour accéder à l'interface de migration. Il vous faudra ensuite lire l'avertissement attentivement et l'accepter pour lancer la migration. Les logs seront affichés dans la barre de message en haut (vous pouvez approcher la souris dessus pour voir l'historique en entier).
+
+#### Depuis la ligne de commande
+
+Après avoir mis à jour vers la version 2.7.14, lancez :
+
+```bash
+sudo yunohost tools migrations migrate
+```
+
+puis lisez attentivement l'avertissement et les instructions.
+
+## Pendant la migration
+
+En fonction de votre matériel et des paquets installés, la migration peut prendre jusqu'à quelques heures.
+
+Notez qu'il est attendu de voir certaines erreurs (en particulier à propos de Fail2Ban) pendant la migration - ne vous en inquiétez pas trop.
+
+#### Si la migration a crashé / échoué à un moment.
+
+Si la migration a échoué a un moment donné, la première chose à faire est de tenter de la relancer. Si cela ne fonctionne toujours pas, il vous faut [trouver de l'aide](/help) (prière de fournir le/les messages correspondants ou tout élément qui vous fait penser que ça n'a pas marché).
+
+## Choses à vérifier après la migration
+
+#### Vérifiez que vous êtes véritablement sous Debian Stretch / YunoHost 3.0
+
+Pour cela, allez dans Outils > Diagnostique. (Vous pouvez aussi regarder ce qui est affiché dans le pied de page). En ligne de commande, vous pouvez aussi utiliser `lsb_release -a` et `yunohost --version`.
+
+#### Vérifiez que Fail2Ban et le pare-feu sont actifs.
+
+Vous devriez voir que Fail2Ban et le firewall sont actifs. Depuis la webadmin, dans Services (chercher 'fail2ban' et 'yunohost-firewall'). Depuis la ligne de commande, faites `yunohost service status fail2ban yunohost-firewall` : les deux devraient être en `active: active`.
+
+#### Vérifiez que les applications fonctionnent
+
+Vérifiez que vos applications installées fonctionnent... Si elles ne fonctionnent pas, il est recommandé de tenter de les mettre à jour. (ou bien de manière générale, il est recommandé de les mettre à jour même si elles fonctionnent !).
+
+#### Si vous utilisez les mails : vérifiez votre score
+
+Si vous utilisez les emails (en particulier les envois), vérifiez que votre score est toujours bon via [mail-tester](https://www.mail-tester.com/) par exemple.
diff --git a/moving_app_folder.md b/moving_app_folder.md
new file mode 100644
index 00000000..941d3d03
--- /dev/null
+++ b/moving_app_folder.md
@@ -0,0 +1,38 @@
+# Moving an app folder to a different storage
+
+Applications folder are (*usually*) located in `/var/www/$appname`
+
+If an application folder is expected to get bigger because of the amount of data
+it contains, it might be relevant to move it to another storage (like an
+external hard drive).
+
+Here's a summary of how to do this the application wordpress. Here, is is assumed that
+[you already mounted the external hard-drive](/external_storage).
+
+#### 1. Move the entire wordpress folder to an external hard drive
+
+```shell
+mv /var/www/wordpress /media/externalharddrive/
+```
+
+#### 2. Create a symbolic link
+
+So that programs looking for files in /var/www/wordpress will actually take them from the harddrive
+
+```shell
+ln -s /media/externalharddrive/wordpress /var/www/wordpress
+```
+
+#### 3. Tweak permissions (maybe?)
+
+After this, note that you may need to tweak the permissions of `/media/externalharddrive` so that `www-data` (or the user corresponding to the app) is able to read through the folder... Something like :
+
+```shell
+chgrp www-data /media/externalharddrive
+chmod g+rx /media/externalharddrive
+
+```
+
+(but it depends on your exact setup... Please update this doc page if you figure
+out what to do exactly)
+
diff --git a/moving_app_folder_fr.md b/moving_app_folder_fr.md
new file mode 100644
index 00000000..88df7bb4
--- /dev/null
+++ b/moving_app_folder_fr.md
@@ -0,0 +1,36 @@
+# Déplacer un dossier d’application vers un autre espace de stockage
+
+Les dossiers d'application se trouvent (*habituellement*) dans `/var/www/$nom_application`
+
+Lorsqu'un dossier d'application devient trop volumineux il peut être intéressant de le déplacer vers un autre espace de stockage (comme un disque dur externe, une carte sd, etc.)
+
+Partant du principe que [le stockage externe est déjà monté](/external_storage), voici un guide pour déplacer le dossier de l'application wordpress :
+
+
+#### 1. Déplacer le dossier wordpress et tout son contenu vers le stockage externe
+
+```shell
+mv /var/www/wordpress /media/externalharddrive/
+```
+___
+
+#### 2. Créer un lien symbolique
+
+Le programme qui va chercher des informations dans le dossier /var/www/wordpress sera redirigé vers le stockage externe.
+
+```shell
+ln -s /media/externalharddrive/wordpress /var/www/wordpress
+```
+___
+
+#### 3. (peut être) bidouiller les permissions
+
+Après tout ça, il est possible que vous ayez à modifier les permissions de `/media/externalharddrive` pour que `www-data` (ou l'utilisateur de l'app) puisse y accéder. Quelque chose comme :
+
+```shell
+chgrp www-data /media/externalharddrive
+chmod g+rx /media/externalharddrive
+
+```
+
+(À préciser par un expert)
diff --git a/news.md b/news.md
new file mode 100644
index 00000000..a3975fc3
--- /dev/null
+++ b/news.md
@@ -0,0 +1,48 @@
+# YunoHost News
+
+
+
+
+
+
+
+
+
diff --git a/noaccess.md b/noaccess.md
new file mode 100644
index 00000000..a2ed2d20
--- /dev/null
+++ b/noaccess.md
@@ -0,0 +1 @@
+Unfortunately, this page only exists [in french here](noaccess_fr) for now.
diff --git a/noaccess_fr.md b/noaccess_fr.md
new file mode 100644
index 00000000..360a13a7
--- /dev/null
+++ b/noaccess_fr.md
@@ -0,0 +1,133 @@
+# Récupérer l’accès à son YunoHost
+
+Il existe de nombreuses causes pouvant empêcher totalement ou partiellement d'accéder en administrateur à un serveur YunoHost. Dans de nombreux cas, un des moyens d'accès est inaccessible, mais les autres sont fonctionnels.
+
+Cette page va vous aider à diagnostiquer, obtenir un accès et si besoin réparer votre système. Les pannes les plus courantes sont priorisées de haut en bas. Il vous suffit de tester chaque hypothèse.
+
+
+## Vous avez accès au serveur via l'adresse IP, mais pas avec le nom de domaine ?
+
+#### Si vous êtes auto-hébergé à la maison : il faut configurer les redirection de ports
+
+Vérifier que vous arrivez à accéder au serveur en utilisant son IP globale (que vous pouvez trouver sur https://ip.yunohost.org). Si cela ne fonctionne pas:
+ - Assurez-vous d'avoir [configuré les redirections de ports](/isp_box_config)
+ - Certaines box de FAI ne supportent pas le hairpinning et vous ne pouvez pas accéder à votre serveur depuis l'intérieur du réseau local (sauf à passer par l'IP locale). Pour contourner le problème, vous pouvez tester d'accéder à votre serveur en passant par un proxy comme proxfree.com
+
+#### Il faut configurer vos enregistrement DNS
+
+(N.B.: ce n'est pas nécessaire si vous utilisez un domaine de type nohost.me, noho.st ou ynh.fr)
+
+Il vous faut configurer vos enregistrement DNS comme expliqué sur [cette page](/dns_config) (à minima l'enregistrement A, et AAAA si vous avez de l'IPv6).
+
+Vous pouvez valider que les enregistrements DNS sont corrects en comparant le résultat de https://www.whatsmydns.net/ avec l'IP globale de votre serveur (si vous êtes hébergé à la maison, vous pouvez obtenir cette IP sur https://ip.yunohost.org)
+
+
+#### Autres causes possibles
+
+- Votre nom de domaine noho.st, nohost.me ou ynh.fr est inaccessible suite à une panne de l'infra YunoHost. Vérifiez sur le forum si d'autre personnes signalent le même problème.
+- Votre nom de domaine est peut-être expiré. Vous pouvez vérifier que votre nom de domaine a expiré en vous connectant sur l'interface de votre registrar ou en utilisant le whois par exemple via la commande `whois NOM_DE_DOMAINE`.
+- Vous avez une IP dynamique. Dans ce cas, il faut mettre en place un script qui se charge de mettre à jour régulièrement votre IP (ou d'utiliser un nom de domaine en nohost.me, noho.st ou ynh.fr qui inclue un tel mécanisme)
+
+
+## Vous êtes face à une erreur de certificat qui vous empêche d’accéder à la webadmin
+
+Si vous venez d'installer votre serveur ou d'ajouter un nouveau domaine, il utilise pour le moment un certificat auto-signé. Dans ce cas, il devrait être possible et légitime d'ajouter *exceptionnellement* une exception de sécurité le temps d'[installer un certificat Let's Encrypt](/certificate) à condition d'être sur une connexion internet sûre (pas avec Tor Browser par exemple).
+
+Une erreur de certificat peut également être affichée dans certain cas où vous avez fait une faute de frappe dans la barre d'adresse de votre navigateur.
+
+
+## Vous avez accès en SSH mais pas à la Web admin ou inversement
+
+#### Vous essayez de vous connecter en SSH avec `root` plutôt qu'avec `admin`
+
+Par défaut, la connexion en SSH doit s'effectuer avec l'utilisateur `admin`. Il est possible de se connecter à la machine avec l'utilisateur `root` *seulement depuis le réseau local* sur lequel se situe le serveur (ou bien via la console web / VNC pour des VPS).
+
+Lorsque vous exécutez des commandes `yunohost` en tant qu'admin, il faut les précéder de la commande `sudo` (par exemple `sudo yunohost user list`). Vous pouvez également devenir `root` en tapant `sudo su`.
+
+#### Vous avez été banni temporairement
+
+Votre serveur YunoHost inclut un mécanisme (Fail2Ban) qui banni automatiquement les IPs qui échouent plusieurs fois à s'authentifier. Dans certains cas, il peut s'agir d'un programme (par exemple un client Nextcloud) qui est configuré avec un ancien mot de passe ou d'un utilisateur qui utilise la même IP que vous.
+
+Si vous avez été banni en tentant d'accéder à une page web, seul les pages web sont inaccessibles, vous devriez donc pouvoir accéder au serveur en SSH. De même, si vous avez été banni en SSH vous devriez pouvoir accéder à la webadmin.
+
+Si vous avez été banni à la fois en SSH et à la webadmin, vous pouvez essayer d'accéder à votre serveur avec une autre IP, par exemple en utilisant la 4G d'un smartphone ou en utilisant Tor Browser.
+
+Voir aussi : [débannir une IP sur Fail2Ban](/fail2ban)
+
+NB : le bannissement dure en général 10 à 12 minutes. Le bannissement n'est actif qu'en IPv4.
+
+
+#### Le serveur web NGINX est cassé
+
+Peut-être que le serveur web NGINX est en panne. Vous pouvez vérifier cela [en ssh](/ssh) avec `yunohost service status ssh`. Si il est en panne, vérifiez que la configuration ne comporte pas d'erreur avec `nginx -t`. Si la configuration est cassée, ceci est peut-être du à une l'installation ou désinstallation d'une application de mauvaise qualité... Si vous êtes perdu, [demandez de l'aide](/help).
+
+Il se peut également que le serveur web (NGINX) ou le serveur ssh aient été tués suite à un manque d'espace disque ou de RAM / swap.
+- Tentez de relancer le service avec `systemctl restart nginx`.
+- Vous pouvez contrôler l'espace disque utilisé avec `df -h`. Si une de vos partitions est remplie à 100%, il faut identifier ce qui prend de la place sur votre système et faire de la place. Il est possible d'installer l'utilitaire `ncdu` avec `apt install ncdu` puis de faire `ncdu /` pour analyser la taille des dossiers de toute l'arborescence.
+- Vous pouvez contrôler l'utilisation de la RAM / swap avec `free -h`. En fonction des résultats, il peut être nécessaire d'optimiser votre serveur pour qu'il utilise moins de RAM (suppression d'app lourdes et inutiles...), d'ajouter de la RAM ou d'ajouter un fichier de swap.
+
+#### Votre serveur est accessible en IPv6 mais pas en IPv4 ou inversement
+
+Vous pouvez le vérifier en tentant de faire des ping sur votre serveur en IPv4 et en IPv6.
+
+Dans un tel cas, il est possible que vous arriviez à accéder à votre web admin en IPv6 mais pas en SSH potentiellement en IPv4 par défaut...
+
+Dans ce cas il faut résoudre votre problème de connectivité.
+
+Dans certains, cas une mise à jour de votre box a activé l'IPv6, entraînant des problèmes de configuration au niveau de votre nom de domaine.
+
+
+## La webadmin fonctionne, mais certaines applications web me renvoient une erreur 502.
+
+Il est fort probablement que le service correspondant à ces applications soit en panne (typiquement pour les applications PHP, il s'agit de php7.0-fpm ou php7.3-fpm). Vous pouvez alors tenter de relancer le service, et si cela ne fonctionne pas, regarder les logs du service correspondant et/ou [demander de l'aide](/help).
+
+
+## Vous avez perdu votre mot de passe administrateur ? (ou bien le mot de passe est refusé)
+
+Si vous arrivez à afficher la page web d'administration (forcez le rafraîchissement avec CTRL + F5 pour être sur) et que vous n'arrivez pas à vous connectez, vous avez probablement un mot de passe erroné.
+
+Si vous êtes certain du mot de passe, il est possible que le service SLAPD qui gère l'authentification soit en panne. Si c'est le cas, il vous faut vous connecter en `root`.
+- Si votre serveur est chez vous, vous avez sans doute accès au réseau local du serveur. Depuis ce réseau, vous pouvez vous connecter [en SSH](/ssh) avec l'utilisateur `root`.
+- Si vous êtes sur un VPS, votre hébergeur vous fournit peut-être la possibilité d'avoir une console sur votre serveur depuis le navigateur web.
+Une fois connecté, il vous faut regarder l'état du service avec la commande `yunohost service status slapd` et/ou tenter de réinitialiser votre mot de passe avec la commande `yunohost tools adminpw`.
+
+Si vous ne pouvez pas ou ne réussissez pas non plus à vous connecter en `root`, vous allez devoir opérer en mode rescue.
+
+TODO: à compléter
+
+
+## Votre VPN a expiré ou ne se monte plus
+
+Si vous utilisez un VPN a IP fixe, peut être que celui-ci est arrivé à expiration ou que l'infrastructure de votre fournisseur est en difficulté.
+
+Dans ce cas, vous pouvez peut être accéder à votre serveur avec son IP locale s'agissant probablement d'un serveur auto-hébergé chez-vous.
+
+Pour connaître votre IP locale, certaines BOX proposent une cartographie du réseau en cours avec les équipements connectés. Sinon, en ligne de commande avec linux:
+```bash
+sudo arp-scan --local
+```
+
+Vous pouvez aussi essayer avec le domaine `yunohost.local` s'il n'y a qu'un seul YunoHost sur votre réseau.
+
+Il faut voir avec votre fournisseur de VPN pour renouveler le VPN et mettre à jour les paramètre de l'app VPN Client.
+
+TODO : à compléter
+
+## Votre serveur est coincé au démarrage
+
+Dans certains cas, votre serveur peut rester coincé au démarrage. Il peut s'agir d'un problème suite à l'installation d'un nouveau kernel. Essayez de choisir un autre kernel avec VNC ou avec l'écran lors du boot.
+
+Si vous êtes en mode `rescue` avec `grub`, dans ce cas il peut s'agir d'un problème de configuration de `grub` ou d'un disque corrompu.
+
+Dans ce cas il faut accéder au disque avec un autre système (mode `rescue` du fournisseur, live USB, lire la carte SD ou le disque dur avec un autre ordinateur) et essayer de vérifier l'intégrité des partitions avec `smartctl`, `fsck` et `mount`.
+
+Si les disques sont corrompus et difficiles à monter, il faut sauvegarder les données et potentiellement refaire un formatage/réinstaller et/ou changer le disque. Si on arrive à monter le disque, il est possible d'utiliser `systemd-nspawn` pour entrer dans la base de données.
+
+Sinon, relancer `grub-update` et `grub-install` en `chroot` ou avec `systemd-nspawn`.
+
+
+## L’accès en VNC ou via écran ne fonctionne pas
+
+Dans ce cas il peut s'agir d'un problème matériel sur votre serveur physique ou d'un problème d'hyperviseur si c'est un VPS.
+
+Si c'est une machine louée contactez le support de votre fournisseur. Sinon, essayez de dépanner votre machine en retirant les composants qui peuvent être en panne.
diff --git a/orga/README.md b/orga/README.md
new file mode 120000
index 00000000..aa9ff0cb
--- /dev/null
+++ b/orga/README.md
@@ -0,0 +1 @@
+yunohost_project_organization_fr.md
\ No newline at end of file
diff --git a/orga/organization_schema.png b/orga/organization_schema.png
new file mode 100644
index 00000000..e51b0d77
Binary files /dev/null and b/orga/organization_schema.png differ
diff --git a/orga/yunohost_project_organization.md b/orga/yunohost_project_organization.md
new file mode 100644
index 00000000..ce306c83
--- /dev/null
+++ b/orga/yunohost_project_organization.md
@@ -0,0 +1,323 @@
+# YunoHost project organisation
+
+## Document objective
+
+This document aims at allowing contributors to feel legitimate in contributing to the YunoHost project together with collective feedback.
+The project is community-based and hasty decisions made by a restricted group of contributors can generate frustrations at a later stage.
+To address this issue, the proposed solution here is to ensure that decisions are taken collectively and that they are sufficiently thought out.
+An advisory council provides orientations for the evolution of the YunoHost project and special interest groups allow more efficient contribution in relation to each specific topic.
+
+## Definition of YunoHost
+
+###Objectives
+
+The goal of YunoHost is to make accessible to the largest number of people, the installation and administration of a server, without prejudice to the quality and reliability of the software.
+
+### Values
+
+#### A free and community-based software
+
+YunoHost is a software under free licence, fully community-based and based on applications which are themselves community-based and often free (Roundcube, baïkal, etc.)
+
+#### That everyone can appropriate
+
+Historically, the project has been very close to initiatives which aim at creating a neutral and decentralised Internet. This proximity especially with the [FFDN](https://www.ffdn.org/), has materialised by having some contributors to create the InternetCu.be whose mission is to facilitate self-hosting by providing a complete solution including a service (via a VPN) and a device. This militant aspect does not inhibit commercial software initiatives hereby companies could propose support or hosting.
+
+## YunoHost organisation
+
+### A theme-based, open structure
+
+The objective of the YunoHost organisation is to allow the largest number of people to contribute to software improvement, whether from a technical point of view (development, application packaging) or otherwise (communication, end-user assistance, documentation, etc.). Inspired by the projects which were reviewed at a recent event (Kodi, Debian, Django, Fedora, Wikipedia, etc.) and by ideas stemming from YunoHost contributors (Jérôme, Bram, opi, scith, ju), a decision was made to organise work by special interest groups, federated thanks to a council to key contributors.
+
+YunoHost project organisation schema
+
+
+
+#### Definition and structure of groups
+
+Groups are structured as a result of the fact that YunoHost counts many sub-projects (a total of 13), but without always knowing who is in charge or who is competent. It has therefore been decided to simplify the organisation into sub-projects according to theme-based groups:
+
+- ##### Core Dev Group
+ - YunoHost Core
+ - Moulinette
+ - Web admin
+ - SSOwat
+ - Dynette
+ - YNH-Dev
+
+- ##### Distribution Group
+ - Creation and maintenance of installation images on various architectures
+ - Distribution of images
+ - Management of Debian packages distribution
+
+- ##### Infra/Sysadmin Group
+ - Infrastructure
+ - Website (wiki, forum, chat room, redmine, Mumble)
+ - Demo
+ - Services
+ - [ip.yunohost.org](https://ip.yunohost.org/) and ip6.yunohost.org
+ - [yunoports](http://ports.yunohost.org/)
+ - nohost.me and noho.st
+ - [yunodash](https://dash.yunohost.org/)
+ - [yunopaste](http://paste.yunohost.org/)
+
+- ##### Apps Group
+ - apps.json list
+ - App development tools (package_checker, package linter)
+
+- ##### Communication Group
+ - Documentation
+ - Communication (announcement of project evolutions on the forum, social networks)
+ - Translation
+ - Mutual assistance (support)
+
+Groups are open to all contributors willing to participate to the development of YunoHost. Everyone can register with the communication channels associated with the group they want to get involved with. Everyone is free to exchange with the rest of the group and to submit a decision point which will follow a prior stage of exchange and improvement of the proposal.
+In order to facilitate its management, each group names a coordinator (and a deputy) whose role is:
+
+- to welcome and to federate new regular contributors to the group
+- to keep the Council informed of decisions taken within the group (see next point)
+
+The choice of a communication tool is left to each group depending on its relevance (forum, chat, email, etc.)
+
+#### Definition and structure of the Council
+
+YunoHost is growing and it's important to maintain a coherence among all the groups. However, it is impossible to impose on every member within every group to take interest or to get involved in all aspects of the project (due to time and competency constraints). To address this, it has been suggested that a meta-group be created where every group has at least one representative: hence the Council.
+The Council is independent of groups and brings together contributors wishing to get involved in the project to the maximum extent. It's role is to:
+
+- take important decisions affecting YunoHost which are dependent on one single group (for instance, changing the wiki engine)
+- regularly follow up on the overall aspect of the project to ensure its cohesion (Mumble meeting)
+- call on the whole community of contributors (or even end-users) when a decision appears divisive between groups or within the Council
+
+To take part at Council-level votes, you must have contributed to the project and have obtained a right to vote (or right of entry) at the Council. This right is delivered by the Council (and may be upon request). The Council is free at any moment to change its decision process.
+To be a member of the Council does not imply that you have access to all resources (infrastructure, repositories, etc.).
+
+### A decision process based on soft consensus
+
+Decisions to be taken can be of 2 kinds:
+
+1. for a group (for example, "to merge a PR" would be assumed by the Dev Group whereas to "post a tweet" would fall under the responsibility of the Communication Group)
+2. for the overall project (for instance, to decide on a release with new features)
+
+If a consensus is not reached over a decision within a particular group, they must refer to the Council for further discussions. If no consensus has been reached, the proposal will be submitted to a vote by all contributors.
+
+#### The decision process in detail
+
+##### 1) Initiating a decision
+- can be initiated by anyone following predefined media within each group (e.g. to open a PR automatically triggers this process)
+- necessarily public with the exception of well-defined situations (bug related to a critical security issue or vote relative to individuals)
+- an end-date is automatically set for every type of proposition. This date is used for various reasons:
+ - to leave enough time for everyone to express themselves and to avoid hasty decisions
+ - to maintain a certain rhythm otherwise if the quota of responses is reached then there's no need to wait for everyone's views within a group
+ - the quota is evaluated according to people registered in a group (or the Council, depending on the situation) who have expressed their desire to be considered as a regular voter => for instance kload could wish to give their opinion at a particular occasion, but with no intention of applying as a active voting member at the Council
+ - so it can be postponed upon simple request by any one member of the group—and only the group, not all contributors.
+
+##### 2) Opening a discussion with several possible responses:
+Anyone can change their position at any moment, but it's expected to let the group react if necessary (e.g. avoid going from positive to negative to reject a proposal altogether after just 3 minutes).
+
+- "simple" replies
+ - "I agree" –> counts as a positive view
+ - "It seems good to me, but I'd rather abide by others' opinion" –> if there are only such views (or like the next one) and at least one positive view and the due date is past, then the proposal is accepted
+ - "no views" / "I'm not in a position to express a helpful view (e.g. I can't code in X)"
+ - delayed reponse
+ - request for clarification, in which case the decision is suspended
+ - refusal: any refusal should be argued and justified
+
+##### 3) Suspension/Postponement
+- while there is no response, a decision is considered suspended; at the moment of a response, the end date is automatically postponed (if needed) (for a duration to be determined, which is shorter than the initial time)
+- in a situation where there are positive and negative views, or where there is a choice between several proposals
+
+##### 4) Request for modifications
+- however, it may happen that discussions take place around these modifications; if such is the case, there is a new decision to be added to the list of existing decisions, and the process applies again (with a postponement of the date)
+- if there aren't enough people agreeing, the date is postponed and a recall must be sent
+- if the result is very close, the group is invited to rediscuss the matter if it is important, otherwise this could turn into a divisive issue and of tensions in the future
+
+##### 5) Closure
+- if the group is unanimous in its decision
+ - with agreements only
+ - with refusals only
+ - no opinions (relying on others' views)
+- For a minor or standard decision, if the quota of responses is reached by the minimal deadline and there's a consensus.
+- The quota of responses means necessary views as detailed below according to different types of decisions. The percentage is based on the number of active members in the group. The coordinator and its deputy are in charge of managing active and inactive members in a group, as they maintain an up-to-date list of members at least at every decision point within the group. (An inactive member who shows up for a decision automatically becomes active).
+- If it isn't possible to have enough people (vacations, not enough members in a group to provide their views), a group can request closing a vote before the voting quota is reached; there's then a new postponement and if the new postponed date is reached, then the proposal is closed according to recorded views.
+
+###### Micro-decision:
+- A decision taken and immediately applied by a single member. This kind of decision must necessarily be reversible, and can be questioned by anyone from any group.
+
+###### Minor decision
+- Initial duration: 1 week.
+- Minimal duration: 3 days.
+- Postponement, if necessary: 3 days.
+- Necessary views: 2 members of a group (the person who initiated the decision can express their view); in an anticipated format, 3 of which 2 members of the group.
+
+###### Standard decision:
+- Initial duration: 2 weeks.
+- Minimal duration: 1 week.
+- Postponement, if necessary: 1 week.
+- Necessary views: 50% of members of a group (the person who initiated the decision can express their view); in an anticipated format, 66% of members.
+- Validation by voting (when applicable): 75% of positive votes.
+
+###### Major decision:
+- Initial duration: 1 month.
+- Postponement, if necessary: 2 weeks.
+- Necessary views: 75% of members of a group (the person who initiated the decision can express their view).
+- Validation by voting (when applicable): 90% of positive votes.
+
+##### 6) Application
+Then a member of a group can announce their decision as effective (and proceed with necessary actions such as releasing, merging, announcing, etc.). If certain actions are required, it's important that people commit themselves to performing them, since a decision without designated people is of little use
+
+## Composition of groups
+
+- Council : Bram, ju, ljf, Maniack, Moul, opi, theodore
+- Core Dev : AlexAubin, Bram, JimboJoe, Ju, ljf, Moul, opi
+- Apps : Bram, cyp, frju365, JimboJoe, Josue-T, Ju, ljf, Maniack C, Maxime, Moul, Scith, Tostaki
+- Infra : Bram, Ju, Maniack C, Moul, opi
+- Communication
+ - Com : Bram, Moul, korbak, ljf, opi, frju365
+ - Doc : Moul, Theodore
+ - Trans : Jean-Baptiste
+- Distribution : Heyyounow
+
+## Summary table of the number of views required for a decision
+
+_Values are rounded (e.g. 5.4 => 5 and 5.5 => 6)._
+
+
+| | **Minor** | **Standard** | **Major** |
+|----------------------|---------|----------|---------|
+| **Council** |
+| Standard closure | 2 | 4 | 5 |
+| Anticipated closure | 3* | 5 |
+| Closure by voting | 5 | 5 | 6 |
+| **Core Dev** |
+| Standard closure | 2 | 3 | 5 |
+| Anticipated closure | 3* | 4 |
+| Closure by voting | 4 | 5 | 5 |
+| **Apps** |
+| Standard closure | 2 | 5 | 8 |
+| Anticipated closure | 3* | 7 |
+| Closure by voting | 7 | 8 | 9 |
+| **Infra** |
+| Standard closure | 2 | 3 | 4 |
+| Anticipated closure | 3* | 3 |
+| Closure by voting | 3 | 4 | 5 |
+| **Communication -> Com** |
+| Standard closure | 2 | 2 | 3 |
+| Anticipated closure | 3* | 3 |
+| Closure by voting | 3 | 3 | 4 |
+| **Communication -> Doc** |
+| Standard closure | 1 | 1 | Council |
+| Anticipated closure | 2* | 2* |
+| Closure by voting | Council | Council | Council |
+| **Distribution** |
+| Standard closure | 1 | Council | Council |
+| Anticipated closure | 1 | Council |
+| Closure by voting | 1 | Council | Council |
+
+\* of which 1 view can be external to the group
+
+For the translation group, the process needs to be adapted.
+
+For the documentation group, the number of views for an anticipated closure of a minor decision eat for the moment limited (there are only 2 people in the group). The other types of decision are taken by the Council.
+
+For the distribution group, since there's only Heyyounow at the moment, the Council will have the task of making Standard and Major decisions.
+
+## Administration group's rights
+This part list administration rights for differents groups of YunoHost project:
+
+(Warning, this is not decision rights here).
+
+### Council
+- No administration right. Authorizations are completed through the other groups membership,
+- Forum: ["Conseil" group member](https://forum.yunohost.org/groups/Conseil).
+
+### Core Dev
+- GitHub: Devs team member inside YunoHost's organization (permission to push, merge…),
+- Redmine: project member of [`YunoHost`](https://dev.yunohost.org/projects/yunohost) and [`Moulinette`](https://dev.yunohost.org/projects/moulinette),
+- Continous integration: writting access to CI-Core,
+- XMPP: ["dev"](xmpp:dev@conference.yunohost.org?join) channel moderator,
+- Forum: ["Dev" group member](https://forum.yunohost.org/groups/Dev).
+
+### Infra
+- Servers: SSH access using SSH key on some (as needed) or every servers,
+- GitHub: [Infra team member inside YunoHost's organization](https://github.com/orgs/YunoHost/teams/infra) (permission to push, merge…),
+- Redmine: [Infra project member](https://dev.yunohost.org/projects/y-u-no-infra/),
+- Forum, Weblate, Redmine, XMPP, CI: administrator,
+- Forum: [Infra group member](https://forum.yunohost.org/groups/Infra).
+
+### Apps
+- GitHub: YunoHost-Apps [Owner](https://github.com/orgs/YunoHost-Apps/people?utf8=%E2%9C%93&query=%20role%3Aowner) (permission to push and merge on all repositories),
+- Redmine: [Apps project member](https://dev.yunohost.org/projects/apps),
+- GitHub: [Apps team member inside YunoHost's organization](https://github.com/orgs/YunoHost/teams/apps) (permission to push, merge…),
+- Continous integration: access to [CI-Apps](https://ci-apps.yunohost.org),
+- XMPP: [Apps channel moderator](https://im.yunohost.org/logs/apps),
+- Forum: [Apps group member](https://forum.yunohost.org/groups/Apps).
+
+### Communication
+- Forum: [Com group member](https://forum.yunohost.org/groups/Communication).
+
+#### Documentation
+- GitHub: [Doc team member of YunoHost's organization](https://github.com/orgs/YunoHost/teams/doc).
+
+#### Communication
+- Diaspora*: [account access](https://framasphere.org/people/01868d20330c013459cf2a0000053625),
+- Twitter: [account access](https://twitter.com/yunohost),
+- Forum: [account access](https://forum.yunohost.org/users/yunohost/activity).
+
+#### Translation
+- Weblate: [translator tool admin](https://translate.yunohost.org/projects/yunohost/).
+
+#### Mutual assistance (support)
+- Forum: moderator status,
+- XMPP: [`support` chanel moderator](xmpp:support@conference.yunohost.org?join).
+
+### Distribution
+- GitHub: [YunoHost's organisation `Distrib` team member](https://github.com/orgs/YunoHost/teams/distribution),
+- Information: image distribution (ISO…) should be done in collaboration with `Infra` group (and `Doc`),
+- Publication: SFTP access can be set up,
+- Forum: [`Distribution` group team member](https://forum.yunohost.org/groups/Distribution).
+
+## Pending decisions for the groups
+
+### Council
+- Should we elect Council members rather than co-opt them? There's a risk of it becoming a "political campaign"!
+- Should special interest group membership be restricted to cooptation like for the Council?
+- Proposal to change Council to Collegiate
+- Migrate the project infrastructure server under YunoHost (with prepackaged apps like pad, dogs and mumble?)
+- New system for documentation
+- Improvement of documentation
+- XMPP server migration
+- Hosting of our Git forge
+- Review the build system: stable <— testing <— branches
+- Freeze nohost.me and abandoning services
+
+### Core Dev Group
+- How to manage pull requests?
+ - Each ticket gives rise to a branch and a ticket; you make a pull/merge request, the community verifies that it works, a decision is taken to integrate.
+
+### Apps Group
+- For community-based apps, issues are on GitHub as they should be, but discussions are on the forum
+
+### Communication Group
+- Bug report from the forum
+- Cleanup of the forum to avoid noise
+- Proposal to delete support chat
+- How to make the forum a more active and central hub
+- How to organise rights on the forum (if groups want to vote on the forum)
+
+### Miscellaneous
+- Request on the forum with notification to the Council members and to representatives of relevant special interest groups
+- Vote over 2 weeks with a post on the forum
+- Create 4 channels for Core Dev, Apps, Communication and Infrastructure
+- A release should be validated by all 4 (or 5) interest groups
+- Communication in French and English
+- Directory or group contact for new people. Maybe just a directory to know who's who. https://yunohost.org/#/contribs to be completed. And to be highlighted.
+- Proposal to leave YunoHost members auto-determine themselves -> How to manage access rights?
+
+## Current means of communication
+
+- Get-togethers at events
+- Weekly Mumble meetings
+- [Forum](https://forum.yunohost.org).
+- [Bugtracker Redmine](https://dev.yunohost.org).
+- Git Forge for code reviews: [YunoHost](https://github.com/YunoHost) [YunoHost-Apps](https://github.com/YunoHost-Apps).
+- [XMPP chat rooms](https://yunohost.org/#/chat_rooms)
diff --git a/orga/yunohost_project_organization_fr.md b/orga/yunohost_project_organization_fr.md
new file mode 100644
index 00000000..dde31a57
--- /dev/null
+++ b/orga/yunohost_project_organization_fr.md
@@ -0,0 +1,299 @@
+# Organisation du projet YunoHost
+
+## Objectif du document
+Ce document a pour objectif de permettre aux contributeurs de se sentir légitimes d’effectuer une contribution dans le projet YunoHost avec un avis collectif. Il vise également à renforcer le projet en le structurant autour de groupes de travail autonomes pouvant résister au départ ou à l'absence de certains contributeurs.
+Le projet étant communautaire, les décisions prises hâtivement et discrètement par un groupe restreint de contributeurs peuvent entraîner des frustrations postérieures.
+Pour pallier ce problème, la solution proposée ici est de faire en sorte que les décisions soient prises collectivement, qu’elles soient suffisamment réfléchies, et qu'elles soient documentées ou rendues publiques.
+Un conseil oriente l’évolution du projet YunoHost, et des groupes d’intérêts permettent de contribuer plus efficacement en fonction des domaines de prédilection de chacun.
+
+## Définition de YunoHost
+
+### Objectifs
+Le but de YunoHost est de rendre accessibles au plus grand nombre l’installation et l’administration d’un serveur, sans délaisser la qualité et la fiabilité du logiciel.
+
+### Valeurs
+
+#### Un logiciel libre et communautaire
+
+YunoHost est un logiciel sous licence libre, entièrement communautaire, et reposant sur des applications elles-mêmes communautaires et souvent libres (Roundcube, Baïkal, etc.).
+
+
+#### Que chacun peut s'approprier
+
+Historiquement, le projet est très proche des initiatives visant à la création d'un internet neutre et décentralisé. Cette proximité, notamment avec la [FFDN](https://www.ffdn.org/), a amené une partie des contributeurs de YunoHost à créer la Brique Internet dont la mission est de faciliter l'auto-hébergement en fournissant une solution complète incluant service (via un VPN) et matériel. Cet aspect militant n'entrave pas des initiatives commerciales du logiciel pour lequel des entreprises pourraient proposer du support ou de l'hébergement.
+
+
+## Organisation de YunoHost
+
+### Une structure ouverte, organisée par thèmes
+L'objectif de l'organisation de YunoHost est de permettre au plus grand nombre de contribuer à l'amélioration du logiciel, que ce soit d'un point de vue technique (développement, packaging d'application) ou non (communication, assistance aux utilisateurs, documentation, etc.). Inspiré par différents projets passés en revue lors de l'événement (Kodi, Debian, Django, Fedora, Wikipédia, etc.) et des idées de contributeur de YunoHost (Jérôme, Bram, opi, scith, ju), il a été décidé d'une organisation en groupes spécialisés, fédérés par un conseil de contributeurs clés.
+
+Schéma d’organisation du projet YunoHost :
+
+
+
+
+#### Définition et constitution des groupes
+La constitution de groupes part du constat que YunoHost compte beaucoup de sous-projets (treize au total), mais que l'on ne sait pas toujours qui en est en charge ou qui y est compétent. Il est donc proposé une simplification de l'organisation des sous-projets en groupes thématiques :
+
+- ##### Groupe Core Dev
+ - Core YunoHost
+ - Moulinette
+ - Admin web
+ - SSOwat
+ - Dynette
+ - YNH-Dev
+
+- ##### Groupe Distribution
+ - Création et maintenance des images d'installation sur diverses architectures
+ - Distribution des images
+ - Gestion de la distribution des paquets Debian.
+
+- ##### Groupe Infra/Adminsys
+ - Infrastructure
+ - Site web (wiki, forum, salon de discussion, Redmine, Mumble)
+ - Démo
+ - Services
+ - [ip.yunohost.org](https://ip.yunohost.org/) et ip6.yunohost.org
+ - [yunoports](http://ports.yunohost.org/)
+ - nohost.me et noho.st
+ - [yunodash](https://dash.yunohost.org/)
+ - [yunopaste](http://paste.yunohost.org/)
+
+- ##### Groupe Apps
+ - Apps Officielles
+ - Apps Communautaires
+ - outils de développements d'app (package_checker, package linter)
+
+- ##### Groupe Communication
+ - Documentation
+ - Communication (annonce évolutions du projet sur le forum, réseaux sociaux)
+ - Traduction
+ - Entraide (support)
+
+Les groupes sont ouverts à tous les contributeurs souhaitant participer au développement de YunoHost. Chacun peut s'inscrire aux canaux de communication associés aux groupes auxquels il souhaite prendre part. Chaque inscrit est libre d'échanger avec le reste du groupe et de proposer une prise de décision à la suite d'une étape d'échange et d'amélioration de la proposition. Il est recommandé aux contributeurs de documenter au maximum leurs décisions et leurs contributions. Ceci permet de renforcer l'autonomie des groupes en cas de départs ou d'absences de certains de leurs membres.
+Afin de faciliter sa gestion, chaque groupe nomme donc un coordinateur (et un remplaçant) dont le rôle est :
+
+- d'accueillir et de fédérer les nouveaux contributeurs réguliers de son groupe
+- de tenir informé le Conseil des décisions prises au sein du groupe (cf. point suivant)
+
+Le choix d'un outil de communication est laissé à chaque groupe en fonction de sa pertinence (forum, chat, ML, etc.).
+
+#### Définition et constitution du Conseil
+
+YunoHost grandissant, il est important de maintenir une cohérence entre tous les groupes, néanmoins il est impossible d'imposer à chacun des membres des groupes de s'intéresser ou de s'impliquer sur tous les aspects du projet (pour des raisons de temps et de compétences). Pour pallier à cela, il est proposé de créer un méta-groupe, où chaque groupe sera représenté par au moins un de ses membres : le Conseil.
+Le Conseil est indépendant des groupes et réunit les contributeurs souhaitant s'impliquer le plus dans le projet, son rôle est de :
+
+- prendre les décisions importantes sur YunoHost qui ne dépendent pas d'un seul groupe (par exemple changer le moteur du wiki)
+- faire des points réguliers sur l'ensemble du projet pour assurer sa cohésion. (réunion Mumble)
+- solliciter l'ensemble de la communauté des contributeurs (ou même des utilisateurs) quand une décision divise les groupes et/ou le Conseil
+
+Le choix d'un outil de communication est laissé au Conseil, ses décisions doivent néanmoins être consultables par l'ensemble de la communauté de contributeurs.
+Pour participer aux votes du Conseil, il faut avoir contribué au projet et avoir obtenu un droit de vote (ou d'entrée) au sein du Conseil. Ce droit est délivré par le Conseil (éventuellement sur demande). Le Conseil est libre à tout moment de modifier le processus de décision.
+Être membre du Conseil n'implique pas forcément d'avoir l'ensemble des accès (infrastructure, dépôt etc.).
+
+### Processus de validation des pull requests
+
+Cette section détaille le processus de validation des pull requests dans les différents dépôts du projet. L'objectif de ce processus est de dégager un « consensus mou ». Il est important de préciser que ce processus est *recommandé* mais ne représente pas un impératif. En particulier, il ne couvre pas toutes les situations qui peuvent se présenter. Il est donc légitime de l'adapter (avec l'accord du groupe concerné) lorsqu'il n'est pas adapté au contexte.
+
+Si un consensus ne peut être trouvé au sein d'un groupe en suivant le processus décrit, il est invité à se tourner vers le Conseil pour en débattre. Si aucun consensus n'est trouvé, la proposition sera soumise au vote de tous les contributeurs.
+
+#### 1. Proposition
+
+N'importe quel contributeur peut proposer une pull request (abrégée PR dans la suite) dans les divers dépôts liés au projet YunoHost (core, apps, infra...).
+
+L'auteur est vivement encouragé à décrire sa proposition en donnant le maximum des informations
+pertinentes. Le groupe peut, à cette fin, proposer un modèle des informations à
+inclure, comme par exemple :
+- status actuel de la PR (ex. : non terminé, en attente de revues, choix techniques à faire...)
+- problème auquel réponds la PR (et références liées, par ex. : ticket sur le bugtracker, post sur le forum...)
+- solution, stratégie, résumé des changements, et/ou choix techniques utilisés dans la PR
+- comment tester la PR
+
+L'auteur est vivement encouragé à respecter les bonnes pratiques suivantes :
+- une PR doit concerner exclusivement un sujet précis. Par exemple, elle ne doit pas à la fois résoudre un bug et ajouter une fonctionnalité (à moins que l'un implique l'autre) ;
+- avant de débuter l'implémentation d'une fonctionnalité qui fait intervenir des choix de conception (nom et format de commande ou d'option, nouvelle API, interface utilisateur...), discuter en amont de manière informelle avec le groupe pour s'assurer que l'implémentation imaginée convienne au plus grand nombre et reste dans l'esprit du projet ;
+- nommer sa PR avec un titre explicite, et la branche associée avec un nom explicite ;
+- donner les références vers d'autres éléments liés à la PR (rapport de bug sur le bugtracker, message sur le forum...)
+
+Une PR peut être créée même si son auteur juge qu'elle n'est pas encore terminée. Dans ce cas, il doit déclarer explicitement dans le fil de discussion de la PR lorsqu'il juge la PR prête. Cela n'empêche pas les autres contributeurs d'émettre des avis sur la PR pendant ce temps.
+
+Il appartient aussi à l'auteur de la PR de juger de son importance. (Ce jugement pourra cependant être contesté par les autres membres du groupe concerné par la PR.) Les niveaux d'importance utilisés sont les suivants :
+- **micro** : concerne uniquement un détail de forme et/ou qui ne nécessite pas d'être débattue et testée. Elle doit être facilement réversible.
+- **mineure** : impacte de manière légère le projet (e.g. refactoring d'une petite partie de code, réparation d'un bug...)
+- **moyenne** : impacte de manière significative l'architecture d'une partie du code (e.g. refactoring de tout un aspect ou de tout un fichier, ajout d'une fonctionnalité importante, sortie d'une version testing...)
+- **majeure** : impacte lourdement l'ensemble du projet (e.g. migration d'une dépendance critique, changement de version de Debian, sortie d'une version stable...)
+
+
+#### 2. Revue et validation collective
+
+(Cette section ne s'applique pas aux PR "micro" qui peuvent être validées directement par leur auteur.)
+
+Une fois la PR déclarée comme terminée, les contributeurs sont invités à donner leurs avis, relire et tester les changements proposés pour les valider. Lorsque des bugs ou des implémentations mauvaises ou incomplètes sont trouvées, les relecteurs rapportent cordialement le problème à l'auteur de la PR sur le fil de discussion. Si le problème trouvé est simple à corriger (e.g. typo ou détail de forme), le relecteur est encouragé à amender la PR pour corriger le problème lui-même. Sinon, l'auteur fait de son mieux pour corriger les problèmes soulevés.
+
+Les relecteurs rapportent également le degré de relecture et de tests effectués (c.f. liste ci-dessous). Selon l'importance de la PR (mineure, moyenne ou majeure), différents quotas de tests et approbations sont à remplir pour que celle-ci soit validée. Les relecteurs peuvent valider une fois chaque type de relecture/test nécessaire (par exemple, un relecteur peut donner un point d'accord sur le principe, un autre point de relecture en diagonale, et un autre point de test dans des cas simples.). L'auteur de la PR ne compte pas dans ces quotas de validation. La proposition doit aussi passer les tests automatiques disponibles dans le groupe (CI, tests unitaires/fonctionnels, linter...).
+
+| | **Mineure** | **Moyenne** | **Majeure** |
+|-----------------------------------|-------------|--------------|-------------|
+| **Accord sur le principe** | 2 | 3 | 4 |
+| **Relecture en diagonale** | 1 | 2 | 3 |
+| **Testé dans les cas simples** | 1 | 2 | 3 |
+| **Relecture attentive** | 0 | 1 | 2 |
+| **Testé dans des cas compliqués** | 0 | 1 | 2 |
+
+Si l'auteur ne fait pas parti du groupe concerné par la PR, tous ces quotas sont augmentés de 1. Dans tous les cas, ces quotas doivent être remplis au moins à 50% par des relecteurs membres du groupe concerné par la PR. (Ainsi, par exemple, un non-membre peut donner son accord sur le principe pour une PR mineure. Mais deux avis de non-membres pour une PR moyenne comptent uniquement pour un seul avis).
+
+
+#### 3. Merge d'une pull request
+
+Une fois les quotas de relecture remplis, et si aucun refus n'a été prononcé et qu'aucune demande de changement n'est en attente, n'importe quel membre du groupe peut alors déclarer et marquer la PR comme "prête à être mergée".
+
+Pendant une durée de 3 jours suivant cette déclaration, les membres du groupe peuvent encore relire, demander des changements ou émettre un refus vis-à-vis de la PR. Dans ce cas, le merge est interrompu et le processus retourne à la partie 2. Pour les PRs moyennes et majeures, la durée est augmentée jusqu'à ce qu'il se soit écoulé au moins une semaine par rapport au moment où la PR a été déclarée comme prête par son auteur.
+
+À l'issue de cette durée, n'importe quel membre du groupe peut merger la PR. Lorsque celle-ci comporte plusieurs commits, il est recommandé d'utiliser la fonction "squash and merge" pour garder l'historique de commit propre.
+
+#### Cas particuliers
+
+Plusieurs cas particuliers peuvent se présenter et dont la résolution est décrite ci-après.
+
+##### Refus d'une PR
+
+Une PR peut être refusée et clôturée par n'importe quel membre du groupe concerné si :
+- la PR a été créée au moins depuis deux semaines
+- au moins deux membres du groupe ont manifesté un désaccord avec le principe de la PR
+- aucun autre membre du groupe n'a manifesté son accord avec le principe de la PR
+
+
+##### Co-création
+
+Une PR peut être développée par plusieurs personnes. Chacun est invité à y faire des commits en se concertant avec l'auteur initial ou le nouveau gestionnaire de PR si l'auteur est indisponible, manque de temps ou souhaite se consacrer à d'autres travaux.
+
+Si ces commits sont conséquents, dans ce cas on peut prendre **partiellement** en compte l'avis des auteurs dans les quotas de relectures et de tests.
+
+Exemple : si une PR est écrite par A et B (50/50), A et B pourront relire le code de l'autre. Dans ce cas, on pourra par exemple compter une relecture pour ces 2 relectures partielles.
+
+
+##### Validation "allégé" en cas de manque de relecteurs
+
+En cas de manque de relecteurs, l'auteur d'une PR peut déclencher une procédure de validation alternative si :
+- l'auteur est membre du groupe concerné par la PR
+- il s'agit d'une PR mineure ou moyenne
+- la PR a été déclarée comme prête
+- il n'y a pas de demande de changement en attente
+- les quotas de relecture "standards" n'ont pas été remplis
+- une semaine s'est écoulée depuis le dernier commentaire ou commit
+
+Dans ce cas, l'auteur annonce sur le fil de discussion de la PR qu'il souhaite engager cette prodécure ainsi que sur la liste de diffusion (ou lors d'une réunion du mardi). À partir de ce moment, les quotas d'accord, relecture et tests pour valider cette PR sont diminués de 1. Au minimum une semaine devra s'écouler avant que cette PR ne soit effectivement mergée. Un autre membre du groupe peut à tout moment mettre fin à cette procédure si il juge la PR trop critique pour être mergée de la sorte.
+
+## Composition des groupes
+
+- Conseil : Bram, ju, ljf, Maniack, Moul, opi, theodore.
+- Core Dev : AlexAubin, Bram, JimboJoe, Ju, ljf, Moul, opi
+- Apps : Bram, cyp, frju365, JimboJoe, Josue-T, Ju, ljf, Maniack C, Maxime, Moul, Scith, Tostaki
+- Infra : Bram, Ju, Maniack C, Moul, opi
+- Communication
+ - Com : Bram, Moul, korbak, ljf, opi, frju365
+ - Doc : Moul, Theodore
+ - Trad : Jean-Baptiste
+- Distribution : Heyyounow
+
+
+## Droits d’administration afférents aux groupes
+Cette partie liste les kits de droits d’administration pour les différents groupes du projet YunoHost :
+
+(Attention, il ne s’agit pas des droits de prises de décisions dans ce cas).
+
+### Conseil
+- Aucun droits d’administration. Les droits sont complétés avec le fait d’être présents dans les autres groupes,
+- Forum : membre du [groupe `Conseil`](https://forum.yunohost.org/groups/Conseil).
+
+### Dev
+- GitHub : membre de l’[équipe `Devs` de l’organisation `YunoHost`](https://github.com/orgs/YunoHost/teams/devs),
+- Redmine : membre des projets [`YunoHost`](https://dev.yunohost.org/projects/yunohost) et [`Moulinette`](https://dev.yunohost.org/projects/moulinette),
+- Intégration continue : droits sur les outils d’intégrations continue CI-core,
+- XMPP : modérateur du salon [`dev`](xmpp:dev@conference.yunohost.org?join),
+- Forum : membre du [groupe `Dev`](https://forum.yunohost.org/groups/Dev).
+
+### Infra
+- Serveurs : accès SSH par clé sur certains (selon les besoins) ou sur la totalité des serveurs,
+- GitHub : membre de l’[équipe `Infra` de l’organisation `YunoHost`](https://github.com/orgs/YunoHost/teams/infra),
+- Redmine: membre du [projet `Infra`](https://dev.yunohost.org/projects/y-u-no-infra/),
+- Forum, Weblate, Redmine, XMPP, CI: administrateur,
+- Forum : membre du [groupe `Infra`](https://forum.yunohost.org/groups/Infra).
+
+### Apps
+- GitHub : propriétaire (Owner) [de l’organisation YunoHost-Apps](https://github.com/orgs/YunoHost-Apps/people?utf8=%E2%9C%93&query=%20role%3Aowner),
+- Redmine : membre du [projet `Apps`](https://dev.yunohost.org/projects/apps),
+- GitHub : membre de l’[équipe `Apps` de l’organisation `YunoHost`](https://github.com/orgs/YunoHost/teams/apps),
+- Intégration continue : accès à [CI-Apps](https://ci-apps.yunohost.org),
+- XMPP : modérateur sur le [salon `Apps`](xmpp:apps@conference.yunohost.org?join),
+- Forum : membre du [groupe `Apps`](https://forum.yunohost.org/groups/Apps).
+
+### Communication
+- Forum : membre du [groupe `Com`](https://forum.yunohost.org/groups/Communication).
+
+#### Doc
+- GitHub : membre de l’[équipe `Doc` de l’organisation `YunoHost`](https://github.com/orgs/YunoHost/teams/doc).
+
+#### Communication
+- Diaspora* : accès au compte [YunoHost](https://framasphere.org/people/01868d20330c013459cf2a0000053625),
+- Twitter : accès au compte [YunoHost](https://twitter.com/yunohost),
+- Forum : accès au compte [`YunoHost`](https://forum.yunohost.org/users/yunohost/activity).
+
+#### Traduction
+- Weblate : administrateur sur l’[outil de traduction](https://translate.yunohost.org/projects/yunohost/).
+
+#### Entraide
+- Forum : statut de modérateur,
+- XMPP : statut de modérateur sur le salon [`support`](xmpp:support@conference.yunohost.org?join).
+
+### Distribution
+- GitHub : membre de l’[équipe `Distrib` de l’organisation `YunoHost`](https://github.com/orgs/YunoHost/teams/distribution),
+- Information : la diffusion des images (ISO…) doit se faire en collaboration avec le groupe `Infra` (et `Doc`),
+- Publication : un accès SFTP peut être mis en place,
+- Forum : membre du [groupe `Distribution`](https://forum.yunohost.org/groups/Distribution).
+
+## Décisions à venir pour les groupes
+### Conseil
+- Faut-il élire les membres du Conseil plutôt que de les coopter ? Risque de se transformer en "campagne politique" !
+- Faut-il limiter l'ouverture des groupes d'intérêts par cooptation comme pour le Conseil ?
+- Proposition de changer Conseil en Collégiale
+- Migrer le serveur d’infrastructure du projet sous YunoHost. (avec apps déjà packagées pad, Gogs, Mumble?)
+- Nouveau système pour la documentation
+- Amélioration de la documentation
+- Migration du serveur XMPP
+- Hébergement de notre forge Git
+- Revoir système de build : stable <— testing <— branches
+- Gel de nohost.me et question de l'abandon des services
+
+### Groupe Dev
+ - Comment gérer les pull request ?
+ - Chaque ticket fait l'objet d'une branche et d'un ticket, tu fais une pull/merge request, la communauté vérifie que ça fonctionne, une décision est prise d'intégrer.
+
+### Groupe Apps
+ - Pour les apps communautaires, les issues sont bien sur GitHub, les discussions sur le forum
+
+### Groupe Communication
+- Rapport de bug à partir du forum
+- Faire en sorte de nettoyer le forum pour éviter le bruit
+- Proposition de supprimer le salon de support
+- Comment rendre le forum plus actif et central
+- Comment s'organiser pour les privilèges sur le forum (si les groupes veulent voter sur le forum)
+
+### Autres
+- Demande sur le forum avec notification des membres du Conseil et des représentants des groupes d’intérêts concernés.
+- Vote sur deux semaines par un post sur le forum
+- Créer quatre canaux pour le Dev, les Apps, la Communication et l'Infrastructure
+- La release devrait être validée par l'ensemble des 4 (ou 5) groupes d’intérêts
+- Communication en français et en anglais
+- Annuaire ou contact des groupes pour les nouveaux arrivants. Voir peut-être annuaire tout court pour savoir qui fait quoi. https://yunohost.org/#/contribs_fr à compléter. Et à mettre en avant.
+- Proposition de laisser les membres YunoHost s'auto déterminer -> Comment gérer les accès ?
+
+## Moyens de communication actuels
+
+- Rencontres à des évènements.
+- Réunions hebdomadaires Mumble.
+- [Forum](https://forum.yunohost.org).
+- [Bugtracker Redmine](https://dev.yunohost.org).
+- Forge Git pour la review de code : [YunoHost](https://github.com/YunoHost) [YunoHost-Apps](https://github.com/YunoHost-Apps).
+- [Salons de discussions XMPP](https://yunohost.org/#/chat_rooms_fr)
diff --git a/overview.md b/overview.md
new file mode 100644
index 00000000..d075c2ea
--- /dev/null
+++ b/overview.md
@@ -0,0 +1,13 @@
+# Overview of the YunoHost ecosystem
+
+This page provide an overview of the ecosystem of a YunoHost server. While this overview contains several approximations, the purpose here is to introduce the global picture before digging into the different aspects.
+
+
+
+Everything starts with the special user **admin**. This is the administrator of the machine who can install, configure and manage things on the server through the web administration interface, or via SSH and the command line interface. *(If you are already familiar with GNU/Linux, it is quite similar to root. YunoHost has this additional 'admin' user for several technical reasons.)*
+
+The administrator can create users and install applications, among other admin actions. Users automatically have their own email adress as well as an XMPP account when they get created. Users will also be able to connect to the user portal (SSO) to access applications. Some applications can typically be installed either as publicly-accessible, or as private, i.e. only some users will have access to it.
+
+Applications and ther features of the server rely on different services to work properly. Services (sometimes also called daemons) are programs that are constantly running on the server to ensure various tasks are done, such as answering to web requests from web browsers, or relaying emails.
+
+
diff --git a/overview_fr.md b/overview_fr.md
new file mode 100644
index 00000000..7aed44ef
--- /dev/null
+++ b/overview_fr.md
@@ -0,0 +1,11 @@
+# Vue d’ensemble de l’écosystème YunoHost
+
+Cette page pose une vue d'ensemble de l'écosystème d'un serveur sous YunoHost. Bien que celle-ci contienne des approximations et des raccourcis, elle permet de poser une première représentation générale avant de rentrer plus dans le détail des différents aspects.
+
+
+
+Tout commence avec l'utilisateur spécial, **admin**. Il s'agit de l'administrateur de la machine qui peut installer, configurer et gérer le serveur à travers l'interface web d'administration, ou via SSH et la ligne de commande. *(Si vous êtes familier avec GNU/Linux, il est similaire à root. YunoHost possède cet utilisateur supplémentaire 'admin' pour plusieurs raisons techniques.)*
+
+L'administrateur peut créer des utilisateurs et installer des applications, parmis d'autres actions d'administration. Les utilisateurs disposent immédiatement d'une adresse e-mail sur le serveur et d'un compte XMPP pour chatter. Les utilisateurs peuvent se connecter au portail utilisateur (SSO) pour accéder aux applications. Les applications peuvent typiquement être installées soient en accès public, ou privé, c'est-à-dire que seuls les utilisateurs du serveur pourront y accéder.
+
+Les applications et autres fonctionnalités du serveur reposent sur plusieurs services pour fonctionner proprement. Les services (aussi appelés daemon) sont des programmes qui tournent constamment pour assurer des tâches, telles que répondre aux requêtes web des navigateurs internet, ou relayer les e-mails.
diff --git a/packaging_apps.md b/packaging_apps.md
new file mode 100644
index 00000000..e6b32749
--- /dev/null
+++ b/packaging_apps.md
@@ -0,0 +1,135 @@
+# App packaging
+
+The purpose of this document is to teach you how to package an application for YunoHost.
+
+### Requirements
+To package an application, here are the requirements:
+* An account on a Git server (e.g. [GitHub](https://github.com/)) to publish the application;
+* Basic knowledge of [Git](/packaging_apps_git), bash shell and other programming stuff;
+* A testing [virtual machine or a distant server](/install) or [VirtualBox](/packaging_apps_virtualbox), to package and test the package. Alternatively you can also use [ynh-dev](https://github.com/yunohost/ynh-dev), it is meant for the core but can totally be used for developping apps, but be aware that for now the documentation on this part is lacking.
+
+### Content
+A YunoHost package is composed of:
+
+* A `manifest.json` file
+* A `scripts` directory, which contains five Shell scripts: `install`, `remove`, `upgrade`, `backup` and `restore`
+* Optional directories, containing `sources` or `conf` files
+* A `LICENSE` file containing the license of the package
+* A presentation page of your package in a `README.md` file
+
+ A basic package
+feel free to use it as a framework.
+
+## Manifest
+Manifest
+
+## Scripts
+Scripts
+
+### Architecture and arguments
+Since YunoHost has a unified architecture, you will be able to guess most of the settings you need. But if you need variable ones, like the domain or web path, you will have to ask the administrator at installation (see `arguments` section in the manifest above).
+
+Arguments management
+
+### NGINX configuration
+NGINX configuration
+
+### Multi-instance
+Multi-instance
+
+### Hooks
+YunoHost provides a hook system, which is accessible via the packager's script callbacks in command line.
+The scripts have to be placed in the `hooks` repository at the root of the YunoHost package, and must be named `priority-hook_name`, for example: `hooks/50-post_user_create` will be executed after each user creation.
+
+**Note**: `priority` is optional, default is `50`.
+
+Take a look at the [Nextcloud package](https://github.com/YunoHost-Apps/nextcloud_ynh/) for a working example.
+
+### Helpers
+Helpers
+
+### Registering a log file
+
+In a lot of case, you might want to register a log file created by your app, to make it available in the webadmin. To register a log, you can create a reference file `/var/log/yunohost/categories/app/APPNAME.yml`.
+
+You can specify a start date by starting the file name with the date formatted as `YYYYMMDD-HHMMSS`.
+
+Example of yml metadata log file:
+```bash
+log_path: /path/to/your/log/file.log
+```
+
+If you want display some context info, you can add:
+```bash
+extra:
+ env:
+ args1: value1
+ args2: value2
+ args3: value3
+```
+
+You can attach the log to an app, domain, service or user like this :
+```bash
+related_to:
+ - ['app', 'APPNAME']
+ - ['service', 'SERVICE1']
+ - ['service', 'SERVICE2']
+ - ['domain', 'DOMAIN.TLD']
+```
+
+This will be used to filter logs and display all log related to an entity like a user, a domain, an app or a service.
+
+### Test it!
+In order to test your package, you can execute your script standalone as `admin` (do not forget to append required arguments):
+```bash
+su - admin -c "/bin/bash /path/to/my/script my_arg1 my_arg2"
+```
+
+Or you can use [command line](/commandline):
+```bash
+yunohost app install /path/to/my/app/package
+```
+Note that it also works with a Git URL:
+```bash
+yunohost app install https://github.com/author/my_app_package.git
+```
+
+### Packaging best practices
+Here is a list of best practices for application install scripts:
+* scripts should use `sudo cp -a ../sources/. $final_path` instead of `sudo cp -a ../sources/* $final_path`;
+* install script must contain support in case of script errors to delete residuals files thanks to `set -e` and [trap](/packaging_apps_trap);
+* install script should use the command-line method instead of calls to curl through web install form;
+* install script should save install answers;
+* application sources should be checked with a control sum (sha256, sha1 or md5) or a PGP signature;
+* scripts should be tested on Debian Buster 32 bits, 64 bits and ARM architectures;
+* backup and restore scripts should be present and functional.
+
+To be define the quality of a package, it'll obtained a [level](/packaging_apps_levels), determined according to somes criteria of installation and according to respect to [package guidelines](packaging_apps_guidelines).
+
+### Package script checker
+Package checker
+
+This Python script checks:
+* that the package is up to date wich last specifications
+* that all files are present
+* that the manifest doesn't have syntax errors
+* that scripts exit well before modifing the system during verification.
+
+### Continuous integration
+
+A continuous integration server is available for packagers who want to test their apps.
+Continuous integration
+
+### Publish and ask for testing your application
+
+* Publishing a [post on the Forum](https://forum.yunohost.org/) in the [`Discuss > Apps` category](https://forum.yunohost.org/c/discuss/discuss-apps/), to ask for testing and feedback on your application.
+
+* If your application is released under a free software license, you may ask the YunoHost app team to integrate your application to the [app repository](https://github.com/YunoHost/apps) (c.f. also the [app list](/apps)). You can add your application even if it is not stable or working yet : the current state can be specified to `notworking`, `inprogress`, or `working`.
+
+* If your application is *not* free software, then in the future, a non-official list might be created to handle them but is non-existent yet.
+
+### Officalization of an application
+
+**!! This section is obsolete as of 08/03/19** - The project's organization regarging this point is to be changed.
+
+To become an official application, it must be tested well enough, be stable and should work on Debian Buster 64 bits, 32 bits and ARM architectures. If you think those conditions are met, ask for [official integration](https://github.com/YunoHost/apps) of your application.
diff --git a/packaging_apps_actions.md b/packaging_apps_actions.md
new file mode 100644
index 00000000..e165e031
--- /dev/null
+++ b/packaging_apps_actions.md
@@ -0,0 +1,149 @@
+# Applications Actions
+
+For now, all those features are EXPERIMENTAL
+and aren't ready for production and are probably going to change again, if you
+still decide to use them don't expect them to be stable and follow to core
+development of YunoHost otherwise they might randomly breaks on your apps
+
+
+Applications "actions" is a packaging feature that allow you to ship with your
+application a list of "actions" executable from both the cli and the admin
+interfaces.
+
+"actions" are a list of custom commands that, optionally, has arguments (like
+the installation script of an application has arguments) and once called will
+called a specific selected command with those arguments. Like an "actions"
+restart service with a argument "service name" could called the command
+`systemctl restart $some_service` (but don't that specific action in your app,
+it's just for example purpose).
+
+Like the installation page generated from the manifest those actions can accept
+a list of arguments.
+
+Their main purpose is to expose procedures that a sysadmin would normally do on
+CLI but that your application user would want to do but don't have the
+knowledge to do by themselves via ssh (or are just too lazy for that).
+
+For example those could be:
+
+* importing data in a application
+* generate a custom backup
+* start a procedure like synchronising file with the file system (nextcloud for example)
+* purge a local cache
+* restart some services
+* modify a theme
+
+Actions looks like this in the admin interface:
+
+
+
+## How to add actions to your application
+
+Adding actions to your application is pretty simple as it is very similar to
+writing your manifest for the application installation.
+
+You need to write an `actions.toml` file in your application at the root level
+like the `manifest.toml`/`manifest.json`.
+
+
+The arguments are written in **[YunoHost Arguments
+Format](/packaging_apps_arguments_format)** like in `manifest.toml/json`
+
+
+The general pattern looks like this:
+
+```toml
+[first_action]
+name = "some name"
+description = "some description that will be displayed"
+
+# can be a bash command like so:
+command = "echo pouet $YNH_ACTION_FIRST_ARGUMENT"
+# or a path to a script like
+command = "/path/to/some/stuff --some-flag $YNH_ACTION_FIRST_ARGUMENT"
+
+user = "root" # optional
+cwd = "/" # optional, "current working directory", by default it's "/etc/yunohost/apps/the_app_id"
+ # also the variable "$app" is available in this variable and will be replace with the app id
+ # for example you can write "/var/www/$app"
+accepted_return_codes = [0, 1, 2, 3] # optional otherwise only "0" will be a non enorous return code
+
+ [first_action.arguments]
+ # here, you put a list of arguments exactly like in manifest.toml/json
+ [first_action.arguments.first_argument]
+ type = "string"
+ ask.en = "service to restart"
+ example = "nginx"
+
+ ... # add more arguments here if needed
+ # you can also have actions without arguments
+
+[another_action]
+name = "another name"
+command = "systemctl restart some_service"
+
+ [another_action.arguments]
+ [another_action.arguments.argument_one]
+ type = "string"
+ ask.en = "some stuff"
+ example = "stuff"
+
+ ... # add more arguments here if needed
+ # you can also have actions without arguments
+```
+
+You can have as much actions as you want and from zero to as many arguments you want.
+
+If you prefer, you can also write your actions in JSON like manifest.json:
+
+```json
+[{
+ "id": "restart_service",
+ "name": "Restart service",
+ "command": "echo pouet $YNH_ACTION_SERVICE",
+ "user": "root", # optional
+ "cwd": "/", # optional
+ "accepted_return_codes": [0, 1, 2, 3], # optional
+ "description": {
+ "en": "a dummy stupid exemple or restarting a service"
+ },
+ "arguments": [
+ {
+ "name": "service",
+ "type": "string",
+ "ask": {
+ "en": "service to restart"
+ },
+ "example": "nginx"
+ }
+ ]
+},
+{
+ ... # other action
+}]
+```
+
+## How to use actions
+
+### In the admin
+
+For now since those features are still
+experimental you won't find any direct links to the app actions on the app
+page
+
+The actions are located on https://some_domain.tld/yunohost/admin/#/apps/$app_id/actions
+
+## With the CLI
+
+The CLI API is very similar to application installation. You have 2 commands:
+
+* `yunohost app list $app`
+* `yunohost app run $app $action_id` ("$action_id" is the this between "[]"
+ like "[another_action]" in the example)
+
+`list` will obviously give you all actions for an application.
+
+`run` will run an existing action for an application and will ask, if needed,
+values for arguments. Like with `yunohost app install` you can use the `-a` and
+pass arguments in the HTTP POST arguments format (like
+`&path=/app&domain=domain.tld&other_value=stuff`)
diff --git a/packaging_apps_advanced.md b/packaging_apps_advanced.md
new file mode 100644
index 00000000..a4e8eef8
--- /dev/null
+++ b/packaging_apps_advanced.md
@@ -0,0 +1,40 @@
+# Advanced features of apps packaging
+
+For now, all those features are EXPERIMENTALS
+and aren't ready for production and are probably going to change again, if you
+still decide to use them don't expect them to be stable and follow to core
+development of YunoHost otherwise they might randomly breaks on your apps
+
+
+## Actions
+
+Actions allow you to ship a list of executables "actions" related to your
+application, for example that could be:
+
+* import data
+* generate a custom backup
+* start a procedure
+* regenerate a local cache
+
+[Full documentation](packaging_apps_actions)
+
+Example in the admin:
+
+
+
+## Configuration Panel
+
+Configuration or "config_panel" allow you to offer a custom configuration panel
+for your application integrated into YunoHost administration panel. This allow
+you to expose whatever configuration you want for your application and this is
+generally used to handle an application configuration file when this is not
+possible inside the application itself.
+
+This is generally also the place where you want to add the option to make an
+application public or not.
+
+[Full documentation](packaging_apps_config_panel)
+
+Example in the admin:
+
+
diff --git a/packaging_apps_arguments_format.md b/packaging_apps_arguments_format.md
new file mode 100644
index 00000000..7663d2a9
--- /dev/null
+++ b/packaging_apps_arguments_format.md
@@ -0,0 +1,331 @@
+# YunoHost Arguments Format
+
+In YunoHost application developpement there are several places where you end up
+writting questions for your user like in the `manifest.json/toml`, the
+`config_panel.json/toml` or `actions.json/toml`.
+
+This page documents this format and all available kind of questions you can ask
+your user. Unless it's stated otherwise, this format applies to everyplace it's
+usable (for now: installation arguments in `manifest.json/toml`,
+`config_panel.json/toml` and `actions.json/toml`)
+
+## YunoHost arguments general format
+
+The general format for an argument looks like this in toml:
+
+```toml
+[maybe.some.stuff.before.the_name]
+type = "one_of_the_available_type"
+ask.en = "the question in english"
+ask.fr = "the question in french"
+help.en = "some help text in english" # optional
+help.fr = "some help text in french" # optional
+example = "an example value" # optional
+default = "some stuff" # optional, not available for all types
+optional = true # optional, will skip if not answered
+```
+
+And in json:
+
+```javascript
+{
+ "name": "the_name",
+ "type": "one_of_the_available_type", // "sting" is not specified
+ "ask": {
+ "en": "the question in english",
+ "fr": "the question in french"
+ },
+ "help": {
+ "en": "some help text in english",
+ "fr": "some help text in french"
+ },
+ "example": "an example value", // optional
+ "default", "some stuff", // optional, not available for all types
+ "optional": true // optional, will skip if not answered
+},
+```
+
+## All avaiable types
+
+### string
+
+This one is the simpliest one and is the default type if you don't specify one.
+
+Example in toml:
+
+```toml
+[maybe.some.stuff.before.the_name]
+type = "string" # optional
+ask.en = "the question in english"
+ask.fr = "the question in french"
+example = "an example value" # optional
+default = "some stuff" # optional
+```
+
+And in json:
+
+```javascript
+{
+ "name": "the_name",
+ "type": "string", // optional
+ "ask": {
+ "en": "the question in english",
+ "fr": "the question in french"
+ },
+ "default": "some stuff", // optional
+ "example": "an example value"
+},
+```
+
+### string with choices
+
+Like string except the user needs to chose in a list of specifics strings.
+
+Example in toml:
+
+```toml
+[maybe.some.stuff.before.the_name]
+type = "string"
+ask.en = "the question in english"
+ask.fr = "la question en français"
+example = "an example value" # optional
+choices = ["fr", "en"]
+default = "en" # optional
+```
+
+And in json:
+
+```javascript
+{
+ "name": "the_name",
+ "type": "string",
+ "ask": {
+ "en": "the question in english",
+ "fr": "the question in french"
+ },
+ "example": "an example value",
+ "choices": ["fr", "en"],
+ "default": "en" // optional
+},
+```
+
+### domain
+
+This type will ask the user to chose one of the domains of their YunoHost instance.
+
+Example in toml:
+
+```toml
+[maybe.some.stuff.before.the_name]
+type = "domain"
+ask.en = "the question in english"
+ask.fr = "the question in french"
+```
+
+And in json:
+
+```javascript
+{
+ "name": "the_name",
+ "type": "domain",
+ "ask": {
+ "en": "the question in english",
+ "fr": "the question in french"
+ }
+},
+```
+
+### Path
+
+This type will ask the user to chose an URL path (generally to happen it to a
+domain) like "/path/to/my/app"
+
+Example in toml:
+
+```toml
+[maybe.some.stuff.before.the_name]
+type = "path"
+ask.en = "the question in english"
+ask.fr = "the question in french"
+default = "/my_app"
+```
+
+And in json:
+
+```javascript
+{
+ "name": "the_name",
+ "type": "path",
+ "ask": {
+ "en": "the question in english",
+ "fr": "the question in french"
+ },
+ "default": "/my_app"
+},
+```
+
+### User
+
+This type will ask the user to select a user in the list of users in their
+YunoHost installation. Generally this is used to select who is going to be the
+admin or who is going to have access to this application.
+
+Example in toml:
+
+```toml
+[maybe.some.stuff.before.the_name]
+type = "user"
+ask.en = "the question in english"
+ask.fr = "the question in french"
+```
+
+And in json:
+
+```javascript
+{
+ "name": "the_name",
+ "type": "user",
+ "ask": {
+ "en": "the question in english",
+ "fr": "the question in french"
+ }
+},
+```
+
+### Password
+
+This type will ask the user to input a password. This is generally used to
+input the password for creating an account on the application.
+
+In CLI it will behave like any password query and won't print any character on
+type (not "\*\*\*...") for security reasons.
+
+Example in toml:
+
+```toml
+[maybe.some.stuff.before.the_name]
+type = "password"
+ask.en = "the question in english"
+ask.fr = "the question in french"
+```
+
+And in json:
+
+```javascript
+{
+ "name": "the_name",
+ "type": "password",
+ "ask": {
+ "en": "the question in english",
+ "fr": "the question in french"
+ }
+},
+```
+
+### Boolean
+
+This type will ask the user to answer true or false to a question.
+
+Example in toml:
+
+```toml
+[maybe.some.stuff.before.the_name]
+type = "boolean"
+ask.en = "the question in english"
+ask.fr = "the question in french"
+default = true
+```
+
+And in json:
+
+```javascript
+{
+ "name": "the_name",
+ "type": "boolean",
+ "ask": {
+ "en": "the question in english",
+ "fr": "the question in french"
+ },
+ "default": true
+},
+```
+
+### Number
+
+Like string except the user needs to enter a number
+
+Example in toml:
+
+```toml
+[maybe.some.stuff.before.the_name]
+type = "number"
+ask.en = "the question in english"
+ask.fr = "the question in french"
+default = 0
+```
+
+And in json:
+
+```javascript
+{
+ "name": "the_name",
+ "type": "number",
+ "ask": {
+ "en": "the question in english",
+ "fr": "the question in french"
+ },
+ "default": 0
+},
+```
+
+### App
+
+This type will ask the user to select an application in the list of installed
+application on their YunoHost.
+
+Example in toml:
+
+```toml
+[maybe.some.stuff.before.the_name]
+type = "app"
+ask.en = "the question in english"
+ask.fr = "the question in french"
+```
+
+And in json:
+
+```javascript
+{
+ "name": "the_name",
+ "type": "app",
+ "ask": {
+ "en": "the question in english",
+ "fr": "the question in french"
+ }
+},
+```
+
+### display_text
+
+This is a special type that allows the application packager to write some text
+that will be simply displayed. This is useful to provide more context.
+
+```toml
+[maybe.some.stuff.before.the_name]
+type = "display_text"
+ask.en = "the text in english"
+ask.fr = "the text in french"
+```
+
+And in json:
+
+```javascript
+{
+ "name": "the_name",
+ "type": "display_text",
+ "ask": {
+ "en": "the text in english",
+ "fr": "the text in french"
+ }
+},
+```
diff --git a/packaging_apps_arguments_management.md b/packaging_apps_arguments_management.md
new file mode 100644
index 00000000..130e3de4
--- /dev/null
+++ b/packaging_apps_arguments_management.md
@@ -0,0 +1,27 @@
+Application packaging
+
+## Arguments management
+#### Retrieve arguments in the install script from manifest
+Arguments are given to the install script from the manifest in it's order. For instance, for Roundcube, `domain` and `path` arguments will respectively be retreived from environment variables or from `$1` and `$2` parameters in the install script.
+
+```bash
+# Retrieve arguments
+domain=$YNH_APP_ARG_DOMAIN
+path=$YNH_APP_ARG_PATH
+```
+
+#### Save arguments for other scripts
+Remove, upgrade, backup and restore scripts could need arguments.
+
+YunoHost could save arguments with this command which is generally used in the install script:
+```bash
+# Store config on YunoHost instance
+ynh_app_setting_set $app domain $domain
+```
+
+Then, the script can retrieve saved arguments with this command:
+```bash
+domain=$(ynh_app_setting_get $app domain)
+```
+
+Those data are saved in `/etc/yunohost/apps//settings.yml`.
diff --git a/packaging_apps_arguments_management_fr.md b/packaging_apps_arguments_management_fr.md
new file mode 100644
index 00000000..6694ac94
--- /dev/null
+++ b/packaging_apps_arguments_management_fr.md
@@ -0,0 +1,28 @@
+Packaging d’application
+
+## Gestion des arguments
+#### Récupérer les arguments du manifeste dans le script d’installation
+Les arguments sont passés au script d’installation dans l’ordre du manifeste. Par exemple pour Roundcube, les arguments `domain` et `path` seront respectivement récupérés via les variables d’environnement ou les paramètres `$1` et `$2` dans le script d’installation.
+
+```bash
+# Retrieve arguments
+domain=$YNH_APP_ARG_DOMAIN
+path=$YNH_APP_ARG_PATH
+```
+
+#### Sauvegarder des arguments pour les autres scripts
+Les scripts remove, upgrade, backup et restore peuvent avoir besoin de ces arguments.
+
+Pour cela, YunoHost peut sauvegarder les arguments avec cette commande :
+```bash
+# Store config on YunoHost instance
+ynh_app_setting_set --app="$app" --key="domain" --value="$domain"
+```
+Elle est généralement utilisée dans le script d’installation.
+
+Ensuite, le script peut récupérer les arguments sauvegardés avec cette commande :
+```bash
+domain=$(ynh_app_setting_get --app "$app" --key=domain)
+```
+
+Ces données sont sauvegardées dans `/etc/yunohost/apps//settings.yml`.
diff --git a/packaging_apps_ci.md b/packaging_apps_ci.md
new file mode 100644
index 00000000..543da54d
--- /dev/null
+++ b/packaging_apps_ci.md
@@ -0,0 +1,44 @@
+# Continuous integration
+
+A continuous integration server is available for any packager willing to test an app with [Package_check](https://github.com/YunoHost/package_check).
+
+ci-apps-dev
+
+This server is free to use for any of you, you just need an account.
+To do so, ask to a member of the Apps group on our [Applications chatroom](/chat_rooms)
+
+To create an account on this CI, you'll need two things:
+- A name (To create an user and to give it a directory).
+- A public ssh key (For your access to the server).
+
+When that's done, you'll be able to access the server and put your apps on it.
+To connect to the server use:
+```bash
+ssh USER@ci-apps-dev.yunohost.org -i YOUR_PRIVATE_KEY
+```
+
+You will find an empty directory, ready to receive your apps.
+As soon as you push an app into your directory, in a 5 minutes maximum delay, a new job will be created for this app and executed by the CI.
+Each time you will update this app, a new test will be executed.
+
+However, to prevent any security issues, your ssh connection will be very limited.
+You can only use `sftp` or `rsync` to copy your apps into that directory. `Git` isn't available, neither most of the usual bash commands.
+To ease your usage of this CI, a small script can be used to copy your apps to your directory.
+
+Copy this [script](https://raw.githubusercontent.com/YunoHost/CI_package_check/master/dev_CI/send_to_dev_ci.sh) into your usual working directory and fill it with your info.
+
+Make sure the content of your `check_process` file is correct then transfer your files.
+When your files have been transfered, you can monitor the CI pipeline on https://ci-apps-dev.yunohost.org.
+
+---
+
+# Other continuous integration servers
+
+For your information, here the list of all our continuous integration servers.
+Those CI are automatic, you can't use them directly. They're working on their own.
+
+- [Official CI](https://ci-apps.yunohost.org): Our official CI, working on a x86-64 system. It is in charge of determining levels for all working apps.
+- [ARM CI](https://ci-apps-arm.yunohost.org): This CI is working with multiple Raspberry-Pi, own by members of the YunoHost community. Tests are running on Raspberry-Pi to determine if apps are working on this architecture.
+- [Unstable/Testing CI](https://ci-apps-unstable.yunohost.org): CI designed to run tests on the branches Unstable and Testing of YunoHost. Its purpose is to test those branches before an official release.
+- [Jessie CI](https://ci-stretch.nohost.me): CI running on a Debian Jessie system. This CI determine is apps are still working with the previous version of Debian and YunoHost before the version 3.
+- [HQ CI](https://ci-apps-hq.yunohost.org): **Incoming...** This CI runs automatic tests on branches of High Quality apps. Except the master branch, which is exclude from this CI, all branches added to a High Quality app will be added to this CI to be tested.
diff --git a/packaging_apps_ci_fr.md b/packaging_apps_ci_fr.md
new file mode 100644
index 00000000..65105e3f
--- /dev/null
+++ b/packaging_apps_ci_fr.md
@@ -0,0 +1,41 @@
+# Intégration continue
+
+Un serveur d'intégration continue est disponible pour tout packager souhaitant tester une application avec [Package_check](https://github.com/YunoHost/package_check).
+
+ci-apps-dev
+
+Ce serveur est libre d'accès pour chacun d'entre vous, vous avez juste besoin d'un compte.
+Pour ce faire, demandez à un membre du groupe Apps sur notre [chatroom Applications](/chat_rooms)
+
+Pour créer un compte sur ce CI, vous aurez besoin de deux choses:
+- Un nom (Pour créer un utilisateur et lui donner un répertoire).
+- Une clé ssh publique (Pour votre accès au serveur).
+
+Une fois cela fait, vous pourrez accéder au serveur et y déposer vos applications.
+Pour vous connecter au serveur, utilisez :
+```bash
+ssh USER@ci-apps-dev.yunohost.org -i YOUR_PRIVATE_KEY
+```
+
+Vous trouverez un répertoire vide, prêt à recevoir vos applications.
+Dès que vous déposer une application dans votre répertoire, dans un délai maximum de 5 minutes, un nouveau job sera créé pour cette application et exécuté par le CI.
+Chaque fois que vous mettrez à jour cette application, un nouveau test sera exécuté.
+
+Cependant, pour éviter tout problème de sécurité, votre connexion ssh sera très limitée.
+Vous ne pouvez utiliser que `sftp` ou `rsync` pour copier vos applications dans ce répertoire. `Git` n'est pas disponible, ni la plupart des commandes bash habituelles.
+Pour faciliter votre utilisation de ce CI, un petit script peut être utilisé pour copier vos applications dans votre répertoire.
+
+Copiez ce [script](https://raw.githubusercontent.com/YunoHost/CI_package_check/master/dev_CI/send_to_dev_ci.sh) dans votre répertoire de travail habituel et indiquez vos informations.
+
+---
+
+# Autres serveurs d'intégration continue
+
+Pour votre information, voici la liste de tous nos serveurs d'intégration continue.
+Ces CI sont automatiques, vous ne pouvez pas les utiliser directement. Ils travaillent seuls.
+
+- [Official CI](https://ci-apps.yunohost.org): Notre CI officiel, travaillant sur un système x86-64. Il est chargé de déterminer les niveaux pour toutes les applications notées 'working'.
+- [ARM CI](https://ci-apps-arm.yunohost.org): Ce CI travaille avec plusieurs Raspberry-Pi, appartenant à des membres de la communauté YunoHost. Les tests sont exécutés sur Raspberry-Pi pour déterminer si les applications fonctionnent sur cette architecture.
+- [Unstable/Testing CI](https://ci-apps-unstable.yunohost.org): CI conçu pour effectuer des tests sur les branches Unstable et Testing de YunoHost. Son rôle est de tester ces branches avant une sortie officielle.
+- [Jessie CI](https://ci-stretch.nohost.me): CI fonctionnant sur un système Debian Jessie. Ce CI détermine si les applications fonctionnent toujours avec la version précédente de Debian et YunoHost avant la version 3.
+- [HQ CI](https://ci-apps-hq.yunohost.org): **A venir...** Ce CI exécute des tests automatiques sur les branches des applications High Quality. A l'exception de la branche master, qui est exclue de ce CI, toutes les branches ajoutées à une application High Quality seront ajoutées à ce CI pour être testées.
diff --git a/packaging_apps_config_panel.md b/packaging_apps_config_panel.md
new file mode 100644
index 00000000..b2296e52
--- /dev/null
+++ b/packaging_apps_config_panel.md
@@ -0,0 +1,303 @@
+# Applications Configuration Panel
+
+For now, all those features are EXPERIMENTAL
+and aren't ready for production and are probably going to change again, if you
+still decide to use them don't expect them to be stable and follow to core
+development of YunoHost otherwise they might randomly breaks on your apps
+
+
+Configuration panel, or "config_panel", is a way for an application to ship a
+custom configuration panel available in the YunoHost's admin interface for the
+application. This is generally used to replace the "you need to manually edit
+this configuration file (or files) in whatever format/language for this
+application in cli and do all those complex commands" to "just use to
+configuration panel to change the options of the application".
+
+Yes, this is one place to add this so asked "how can I make my application from
+public to private and vice versa" user request.
+
+config_panel is probably the most complex YunoHost apps feature as you'll need
+to write both a description of the panel in toml and a script that will need to
+both work in a "display mode" and "handle inputs" mode. But this is still very
+doable and very worth it if you need it.
+
+Here how it looks like in the admin interface:
+
+
+
+## Usage
+
+### Admin interface
+
+The configuration panel for an application can be accessed with this URL:
+
+ https://my_domain.tld/yunohost/admin/#/apps/$app_id/config-panel
+
+For now since those features are still
+experimental you won't find any direct links to the app actions on the app
+page
+
+### CLI
+
+For now the CLI API for the config panel is not very good at all, you can still
+use it but it's really impracticable.
+
+* `yunohost app config show-panel $app_id` will show the panel. **But for now
+it's very broken and will ask question for unfilled value of the panel**.
+
+* `yunohost app config apply` will call the script with apply and... no values
+ since you aren't passing them, except if you are ready to play with the `-a`
+ flag and pass every global value in the HTTP POST format (protip: you don't)
+
+In conclusion: don't use the CLI for now, we need to design something better.
+
+## How to add a config_ panel to your application
+
+### config_panel.toml
+
+First, you need to write a `config_panel.toml` (or `config_panel.json` if you
+REALLY want to but we really don't recommend it as it is very error prone and
+frustrating to write by hand) that will be located at the root of you
+application, next to the manifest.json/toml. It looks like this:
+
+
+The options are written in **[YunoHost Arguments
+Format](/packaging_apps_arguments_format)** like in `manifest.toml/json`
+
+
+```toml
+version = "0.1" # version number, not used yet but important
+name = "name that will be displayed on the admin"
+
+[section_id]
+name = "name of the section that will be displayed"
+
+ [section_id.sub_section_id]
+ name = "sub section"
+
+ # those arguments are in yunohost argument format like manifest.json
+ [section_id.sub_section_id.option_id]
+ ask.en = "the text displayed for the option"
+ type = "argument_option"
+ default = true
+ help = "A public Leed will be accessible for third party apps.
By turning on 'anonymous readers' in Leed configuration, you can made your feeds public."
+
+ [section_id.sub_section_id.another_option_id]
+ ...
+
+ [section_id.another_sub_section_id]
+ name = "stuff"
+
+[another_section_id]
+name = "stuff"
+
+...
+```
+
+
+And a real world example with the rendered admin:
+
+
+
+As a text format:
+
+```toml
+version = "0.1"
+name = "Leed configuration panel"
+
+[main]
+name = "Leed configuration"
+
+ [main.is_public]
+ name = "Public access"
+
+ # those arguments are in yunohost argument format
+ [main.is_public.is_public]
+ ask.en = "Is it a public website ?"
+ type = "boolean"
+ default = true
+ help = "A public Leed will be accessible for third party apps.
By turning on 'anonymous readers' in Leed configuration, you can made your feeds public."
+
+
+ [main.overwrite_files]
+ name = "Overwriting config files"
+
+ [main.overwrite_files.overwrite_nginx]
+ ask.en = "Overwrite the nginx config file ?"
+ type = "boolean"
+ default = true
+ help = "If the file is overwritten, a backup will be created."
+
+ [main.overwrite_files.overwrite_phpfpm]
+ ask.en = "Overwrite the php-fpm config file ?"
+ type = "boolean"
+ default = true
+ help = "If the file is overwritten, a backup will be created."
+
+...
+```
+
+### the scripts/config script
+
+To make your configuration panel functional you need write a "config" script
+that will be located in the "script" folder (like the "install" script). This
+script will be called in two different occasions:
+
+* when the configuration panel is displayed and yunohost needs to fill the values
+* when the configuration is modified by the user
+
+Every option of the configuration panel will be sent to the script
+following this naming convention:
+
+```bash
+YNH_{section_id}_{sub_section_id}_{option_id} (everything in upper case)
+```
+
+For example, this option value:
+
+```toml
+[main]
+name = "Leed configuration"
+
+ [main.is_public]
+ name = "Public access"
+
+ # those arguments are in yunohost argument format
+ [main.is_public.is_public]
+ ...
+```
+
+Will be available under this name in the config script:
+
+```bash
+YNH_CONFIG_MAIN_IS_PUBLIC_IS_PUBLIC
+```
+
+Also, the same "scripts/config" script is called in both situation. To differentiate
+those situation the first argument passed to the config script is either "show"
+or "apply".
+
+A common pattern to handle that is to write your script following this pattern:
+
+```bash
+show_config() {
+ # do stuff
+}
+
+apply_config() {
+ # do stuff
+}
+
+case $1 in
+ show) show_config;;
+ apply) apply_config;;
+esac
+```
+
+#### The "show" part
+
+The show part is when the user ask to see the current state of the
+configuration panel (like opening to configuration panel page on the admin
+interface). The role of the scripts/config script here is to gather all the
+relevant information, by for example parsing a configuration file or querying a
+database, and communicate it to YunoHost. To do so, you need to use the helper
+`ynh_return` like so:
+
+```bash
+ynh_return "YNH_CONFIG_SOME_VARIABLE_NAME=some_value"
+```
+
+For example, for this config_panel:
+
+```toml
+[main]
+name = "Leed configuration"
+
+ [main.is_public]
+ name = "Public access"
+
+ # those arguments are in yunohost argument format
+ [main.is_public.is_public]
+ ...
+```
+
+You would do:
+
+```bash
+ynh_return "YNH_CONFIG_MAIN_IS_PUBLIC_IS_PUBLIC=1"
+```
+
+If you don't provide any value for a configuration **the default value will be used**.
+
+Expanding our previous example you would have this scripts/config script:
+
+```bash
+show_config() {
+ ynh_return "YNH_CONFIG_MAIN_IS_PUBLIC_IS_PUBLIC=1"
+}
+
+apply_config() {
+ # do stuff
+}
+
+case $1 in
+ show) show_config;;
+ apply) apply_config;;
+esac
+```
+
+#### The "apply" part
+
+The "apply" part is called when the user click on "submit" on the configuration
+page on the admin interface. This part is simpler to write:
+
+- the scripts/config will be called with "apply"
+- all the values in the config panel (modified or not) are available as global
+ variables in the script following the format `YNH_{section_id}_{sub_section_id}_{option_id}`
+ (exactly the same than for show)
+- the script is responsible for doing whatever it wants with those information
+- once the script has succeeded, the admin interface displays the config panel
+ again and triggers the same script in "show" mode
+
+Expanding the previous script that could look like that:
+
+```bash
+show_config() {
+ ynh_return "YNH_CONFIG_MAIN_IS_PUBLIC_IS_PUBLIC=1"
+}
+
+apply_config() {
+ value=$YNH_CONFIG_MAIN_IS_PUBLIC_IS_PUBLIC
+ # do some stuff with value
+}
+
+case $1 in
+ show) show_config;;
+ apply) apply_config;;
+esac
+```
+
+Or if you want a full useless simple script that store the value in a file,
+this can look like this:
+
+```bash
+dummy_config_file="dummy_config_file.ini"
+
+show_config() {
+ if [ -e $dummy_config_file ]
+ then
+ ynh_return "YNH_CONFIG_MAIN_IS_PUBLIC_IS_PUBLIC=$(cat $dummy_config_file)"
+ fi
+
+ # the default value will be used
+}
+
+apply_config() {
+ echo $YNH_CONFIG_MAIN_IS_PUBLIC_IS_PUBLIC > $dummy_config_file
+}
+
+case $1 in
+ show) show_config;;
+ apply) apply_config;;
+esac
+```
diff --git a/packaging_apps_fr.md b/packaging_apps_fr.md
new file mode 100644
index 00000000..0a396835
--- /dev/null
+++ b/packaging_apps_fr.md
@@ -0,0 +1,117 @@
+# Packaging d’applications
+
+Ce document a pour but de vous apprendre à packager une application pour YunoHost.
+
+### Prérequis
+Pour packager une application, voici les prérequis :
+* Un compte sur un serveur Git comme [GitHub](https://github.com/) pour pouvoir ensuite publier l’application ;
+* Maîtriser un minimum [Git](/packaging_apps_git), le Shell et d’autres notions de programmation ;
+* Une [machine virtuelle ou sur un serveur distant](/install) ou un environnement de développement, [ynh-dev](https://github.com/yunohost/ynh-dev) ou [VirtualBox](/packaging_apps_virtualbox), pour packager et tester son paquet.
+
+
+Si vous ne comprenez pas ces prérequis, ou si vous ne savez pas comment écrire du code, consulter d'abord l'[introduction au packaging](/packaging_apps_start).
+
+### Contenu
+Un paquet YunoHost est composé :
+
+* d’un `manifest.json`
+* d’un dossier `scripts`, composé de six scripts Shell `install`, `remove`, `upgrade`, `backup`, `change_url` et `restore`
+* de dossiers optionnels, contenant les `sources` ou de la `conf`
+* d’un fichier `LICENSE` contenant la licence du paquet
+* d’une page de présentation du paquet contenu dans un fichier `README.md`
+
+Paquet de base n’hésitez pas à vous en servir comme base de travail.
+
+## Manifeste
+Manifeste
+
+## Les scripts
+Scripts
+
+### Architecture et arguments
+Comme les instances de YunoHost possèdent une architecture unifiée, vous serez capable de deviner la plupart des réglages nécessaires. Mais si vous avez besoin de réglages spécifiques, comme le nom de domaine ou un chemin web pour configurer l’application, vous devrez les demander aux administrateurs lors de l’installation (voir la section `arguments` dans le § **Manifeste** ci-dessus).
+
+Gestion des arguments
+
+### Configuration NGINX
+Configuration NGINX
+
+### Multi-instance
+Multi-instance
+
+### Hooks
+Hooks
+
+### Commandes pratiques
+Commandes pratiques
+
+### Référencement des logs
+Dans de nombreuses situations, vous pouvez vouloir indexer un fichier de log pour qu'il soit affiché dans la webadmin. Pour indexer un log, il faut créer un fichier d'indexation dans `/var/log/yunohost/categories/app/APPNAME.yml`.
+
+Il est possible de spécifier la date de début en commençant le nom de fichier par la date `YYYYMMDD-HHMMSS`.
+
+Exemple de fichier de log d'indexation :
+```bash
+log_path: /chemin/vers/le/fichier.log
+```
+
+Il est possible d'afficher des infos complémentaires, la variable env sera affichée dans la partie "Contexte" :
+```bash
+extra:
+ env:
+ args1: value1
+ args2: value2
+ args3: value3
+```
+
+Il est possible de rattacher le log à une application précise et/ou un service, un nom de domaine, une personne :
+```bash
+related_to:
+ - ['app', 'APPNAME']
+ - ['service', 'SERVICE1']
+ - ['service', 'SERVICE2']
+ - ['domain', 'DOMAIN.TLD']
+```
+
+Ces informations seront utilisées pour permettre de filtrer les logs en relation avec une de ces entités application, service, domaine, personne.
+
+
+### Améliorer la qualité du paquet d’installation
+Vous trouverez ci-dessous une liste des points à vérifier concernant la qualité de vos scripts :
+* Vos scripts utilisent bien `sudo cp -a ../sources/. $final_path` plutôt que `sudo cp -a ../sources/* $final_path` ;
+* Votre script d’installation contient une gestion en cas d’erreurs du script pour supprimer les fichiers résiduels à l’aide de `set -e` et de [trap](/packaging_apps_trap) ;
+* Votre script d’installation utilise une méthode d’installation en ligne de commande plutôt qu’un appel curl via un formulaire web d’installation ;
+* Votre script d’installation enregistre les réponses de l’utilisateur ;
+* Vous avez vérifié les sources de l’application avec une somme de contrôle (sha256, sha1 ou md5) ou une signature PGP ;
+* Vos scripts ont été testés sur Debian Buster 32 bits, 64 bits et ARM ;
+* Les scripts backup et restore sont présents et fonctionnels.
+
+Pour mesurer la qualité d'un paquet, celui-ci obtiendra un [niveau](/packaging_apps_levels), déterminé en fonction de divers critères d'installation et selon le respect des [règles de packaging](/packaging_apps_guidelines).
+
+### Script de vérification du paquet
+Vérificateur de paquets
+
+Il s’agit d’un script Python qui vérifie :
+* que le paquet est à jour concernant les dernières spécifications
+* que tous les fichiers sont présents
+* que le manifeste ne comporte pas d’erreur de syntaxe
+* que les scripts quittent bien avant de modifier le système lors de vérifications.
+
+### Intégration continue
+
+Un serveur d'intégration continue est a disposition des packagers désirant tester leurs applications.
+Intégration continue
+
+### Publiez et demandez des tests de votre application
+
+* Demandez des tests et des retours sur votre application en publiant un [post sur le Forum](https://forum.yunohost.org/) dans la [catégorie `Discussion > Apps`](https://forum.yunohost.org/c/discuss/discuss-apps/).
+
+* Si votre paquet et l'application qu'il contient sont sous licence libre, faites une demande d’ajout de votre application dans le [dépôt des applications](https://github.com/YunoHost/apps) (voir aussi [la liste des apps](/apps)). Vous pouvez ajouter une application même si celle-ci n'est pour le moment pas fonctionelle : l'état d'avancement peut être `notworking`, `inprogress` ou `working`.
+
+* Si votre application n'est *pas* sous licence libre, il se peut qu'une liste non-officielle soit créée pour gérer ces applications. Ce n'est pour l'instant pas le cas.
+
+### Officialisation d’une application
+
+**!! Section obsolète au 08/03/19** - Le fonctionnement du projet est en cours d'évolution sur ce point.
+
+Pour qu’une application devienne officielle, elle doit être suffisamment testée, stable et fonctionner sous Debian Buster 64 bits, 32 bits et ARM. Si ces conditions vous paraissent réunies, demandez l’[intégration officielle](https://github.com/YunoHost/apps) de votre application.
diff --git a/packaging_apps_git.md b/packaging_apps_git.md
new file mode 100644
index 00000000..6093cef1
--- /dev/null
+++ b/packaging_apps_git.md
@@ -0,0 +1,201 @@
+# How to use Git to package apps
+
+Git... Our dear beloved Git, which can be described also as "Goddamn Idiotic Truckload of sh*t", according to Linus.
+Be sure if you don't know Git yet that you will soon agree with that description.
+
+YunoHost and all our apps are on the Git forge GitHub. Which means that if you want to work on an app, sooner or later you're going to have to deal with Git.
+So let's see how to work with Git to be able to contribute in the context of YunoHost.
+
+## Working with GitHub
+
+Let's go first for the easy part, GitHub comes with an "easy" web interface to deal with.
+
+*First things first, unfortunately there's no way around, you need an account on GitHub.*
+
+#### Branches
+
+Then, probably one of the most important thing, **do not work directly on the master branch**.
+Sorry, it has to be said !
+
+Branches are, as GitHub explains, "*a parallel version of a repository. It is contained within the repository, but does not affect the other branches. Allowing you to work freely without disrupting the "live" version.*"
+
+The master branch is the branch that contains the version of the app users will actually install and use.
+The usual thing to do is to work from the testing branch, and when everything is settled and tested, you can merge the testing branch in master, so users will enjoy the new release of your package.
+
+To see and change the current branch, use this button:
+
+
+#### Edit a file
+
+Now that you're on the right branch, let's see how to edit a file on GitHub.
+
+You can edit any file by using the small pencil icon:
+
+
+If you don't have the permission to write on the repository, you will see (as on the picture) that you're going to create a fork (we'll see below what a fork is).
+If you have the permission to write, you will just edit the file, without forking.
+
+#### Commit your changes
+
+When you're done with your modification on the file, you can commit your changes.
+Behind that word, the idea is quite simple, you're just going to save your changes...
+
+
+The first field is the name of your commit, a very short sentence to explain why you did this modification.
+The second field is a large one for a more complete explanation, if you need it.
+
+Finally, if you're editing a repository on which you have permission to write, you can either commit directly to the current branch or create a new branch.
+It's usually better to create a new branch, that way you keep your modifications on a *parallel* version of the repository. Your modifications will be discussed in a pull request (explained below) then finally merged into the original branch.
+
+#### To fork or not to fork
+
+A fork is a copy of a repository into your own account.
+We have seen before that if you don't have permission to write into a repository, editing a file will automatically create a fork.
+Because the fork is on your account, you always have the permission to write on it.
+But even if a fork is not the real repository, but just a copy, a fork is always linked to its parent. We'll see later that to create a fork is really useful when opening a pull request.
+
+When you create a new package, it's common to use the [example app](https://github.com/YunoHost/example_ynh) as a base.
+But, because you don't want to keep that link to the example app, you should not fork the example app. You will rather clone the app.
+Unfortunately, to clone an app is a little bit trickier on GitHub. We will see later how to clone to a local repository instead.
+
+We have seen how to edit a file, and how this could fork the app.
+But, when you want to edit multiple files, the GitHub interface isn't really the best way. In such situation, you would rather clone the repository and work on a local repository.
+You may still need to fork on your own account to be able to save your modifications if you don't have the permission on the distant repository.
+
+#### Pull request
+
+After you have committed your changes, whether on a branch or a fork, you want to propose your modifications to be integrated into the main repository, or the original branch.
+To do so, you're going to *create a pull request*. GitHub usually ask you directly if you want to do so.
+Otherwise, you'll find the button to create a pull request just here:
+
+
+When creating a pull request from a fork, to ease the work of the reviewers, **do never** uncheck the checkbox *Allow edits from maintainers*. That option simply allow the maintainers of the original repository to edit directly your work.
+
+#### YunoHost-Apps organization
+
+Following the [YEP 1.7](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines.md#yep-17), your app has to be into the YunoHost-Apps organization, but if you have never contributed to an app before or never had any app into this organization you may not have the permission.
+
+First, you need the permission to write into the organization, to do so, ask to the Apps group on the Apps XMPP room.
+
+To transfer your app to the YunoHost-Apps organization, go to your repository and to *Settings* tab.
+At the bottom of the page, you will find *Transfer ownership*.
+Into the field *New owner’s GitHub username or organization name*, type *YunoHost-Apps*.
+Your repo will be moved into the organization, you don't have to remove the original repository.
+
+
+## Working with Git locally
+
+As we have seen, you can do a lot of things directly on GitHub.
+But when you need to edit multiple files, or when you need to work on your code on your own, it's better to work directly on your computer.
+
+Before going to the hellish part of Git, let's see 2 different ways to start working with Git.
+
+#### First case: Creating a new package
+
+You have shockingly discovered that the wonderful app you love to use everyday does not yet have its YunoHost package. And because you're nice, you decided to create yourself the package, so everyone will enjoy that app the way you do.
+What a good idea !
+
+The best is to start from the [example app](https://github.com/YunoHost/example_ynh). But as we have explained before, you don't want to fork, because if you do so, you're going to keep that link to the example app and it's really annoying.
+So, you're going to do it differently. You're going to clone !
+
+##### git clone
+
+To clone, you're going to do:
+```bash
+git clone https://github.com/YunoHost/example_ynh
+```
+`git clone` will download a copy of the repository. You will have the complete repository, with its branches, commits, and everything (into that apparently little `.git` directory).
+
+To git clone is usually the starting point of any local work with Git.
+
+*A side note though, if you expect to send your modifications back to the distant repository on GitHub, be sure to have the permission to write on this repository. Otherwise, fork before and clone your fork, on which you do have the permission.*
+
+##### My brand new package, continued
+
+In the context of a new package, you will also need to create a repository on GitHub to nest your package.
+Which is as simple as a big green *New* button.
+Don't bother with README, .gitignore or license. Just create the repository itself.
+you can now git clone that new repository.
+
+
+You now have 2 repositories cloned on your computer.
+Copy all the files from the example_ynh app, **except the .git directory** (You just want the files themselves) to your new package.
+
+*If you want, you can remove the example_ynh app. We don't need it anymore.*
+
+You're ready to work on your new package !
+
+#### Second case: Working locally on a repository
+
+You already have a repository, but what you want is just to work locally, so you can modify multiple files.
+Simply clone the repository, the .git directory is the link to the distant repository. Nothing else to do than a `git clone`.
+
+#### Branches
+
+You do have your local copy of the repository, but because you have read carefully this documentation until then, you know that you should be sure to be on the testing branch before starting to work.
+
+To see the branches, and to know on which you actually are, while into the directory of your repository, type `git branch`.
+The current branch is highlighted and preceded by a `*`.
+
+#### git checkout
+
+If it appears that you're not on the branch you wanted to be, or you're actually on master (which is bad !), you can move to another branch with `git checkout`
+```bash
+git checkout testing
+```
+*Read carefully what Git says when you validate a command, do never forget that Git is sneaky...*
+
+#### Git pull before anything else
+
+You're finally on the right branch, and ready to work.
+**Wait ! A nasty trap is waiting for you...**
+Before ending up in an inextricable situation. Start with a `git pull` to update your branch to the latest change from the distant repository.
+
+*Sometimes, you will encounter an impossible situation where Git is saying that you can't pull because you have local changes. But you don't care of those local modifications, you just want to get the last version of the distant branch. But Git don't care about what YOU want...*
+*I have to admit that my only solution is as highly efficient as dirty... A good old `rm -r` of the repository and a `git clone`*
+
+#### Let's work
+
+Eventually, you can work on your code.
+When you are finally ok with what you have done, it's time to validate your work.
+
+The first step is to inform Git about which file(s) to validate. To do so, we'll use `git add`
+```bash
+git add my_file
+git add my_other_file and_also_this_one
+```
+If you want to validate all your work, you can also simply do
+```bash
+git add --all
+```
+
+To check the current status of your validation, you can use `git status`. It will show you which files will be included into your commit, and which files are modified, but not yet included.
+`git status -v` will show also which part of the files are modified. A good way to be sure that you didn't make a mistake before committing.
+
+#### git checkout -b
+
+Before committing, or after, or before starting to work. Whenever you feel like it !
+You should consider adding your work to a separate branch, that way, it will be easy to create a pull request to merge into the testing branch and discuss with the other packagers what you suggest to change.
+
+To create a new branch and move to this branch, you can use `git checkout -b my_new_branch`.
+
+#### Commit
+
+To commit is simply to validate your work in Git. As you can do in GitHub.
+To have the same fields that you had on GitHub, with the name of the commit, and a longer explanation. You can simply use `git commit`.
+The first line, before the comments, is for the name of the commit.
+After all the comments, you can add an explanation if you want to.
+
+If you want to commit with only a name for your commit, you can use a simple command:
+```bash
+git commit -m "My commit name"
+```
+
+#### Push to the distant repository
+
+Your changes are validated, but only on your local clone of the repository. Now, you have to send those modifications back to the distant repository on GitHub.
+In order to do that, you need to know what is your current branch. (If you don't know, `git branch` will give you that info).
+Then you can git push
+```bash
+git push -u origin BRANCH_NAME
+```
diff --git a/packaging_apps_git_fr.md b/packaging_apps_git_fr.md
new file mode 100644
index 00000000..599c4078
--- /dev/null
+++ b/packaging_apps_git_fr.md
@@ -0,0 +1,201 @@
+# Comment utiliser Git pour packager les applications
+
+Git... Notre cher Git bien-aimé, que l'on peut aussi décrire comme "Goddamn Idiotic Truckload of sh*t" (Un stupide putain gros tas de m\*rde), selon Linus.
+Si vous ne connaissez pas encore Git, soyez sûr que vous serez bientôt d'accord avec cette description.
+
+YunoHost et toutes nos applications sont sur la forge Git GitHub. Ce qui veut dire que si vous voulez travailler sur une application, tôt ou tard vous allez devoir faire face à Git.
+Alors voyons comment travailler avec Git pour pouvoir contribuer dans le contexte de YunoHost.
+
+## Travailler avec GitHub
+
+Commençons par la partie facile, GitHub est livré avec une interface web "facile" à utiliser.
+
+*Tout d'abord et malheureusement, il n'y a pas moyen de contourner ça, vous devez avoir un compte sur GitHub.*
+
+#### Branches
+
+Ensuite, et c'est probablement l'une des choses les plus importantes, **ne travaillez pas directement sur la branche master**.
+Désolé, il fallait que ce soit dit !
+
+Les branches sont, comme l'explique GitHub, "*une version parallèle d'un dépôt. Elle est contenue dans le dépôt, mais n'affecte pas les autres branches. Elle vous permet de travailler librement sans perturber la version "live".*"
+
+La branche master est la branche qui contient la version de l'application que les utilisateurs installeront et utiliseront effectivement.
+La bonne habitude à prendre est de travailler à partir de la branche testing, et lorsque tout est réglé et testé, vous pouvez fusionner la branche testing dans master, afin que les utilisateurs puissent profiter de la nouvelle version de votre package.
+
+Pour voir et modifier la branche actuelle, utilisez ce bouton :
+
+
+#### Modifier un fichier
+
+Maintenant que vous êtes sur la bonne branche, voyons comment éditer un fichier sur GitHub.
+
+Vous pouvez éditer n'importe quel fichier en utilisant l'icône du petit crayon :
+
+
+Si vous n'avez pas la permission d'écrire sur le dépôt, vous verrez (comme sur l'image) que vous allez créer un fork (nous verrons plus loin ce qu'est un fork).
+Si vous avez la permission d'écrire, vous allez simplement modifier le fichier, sans forker.
+
+#### Validez vos modifications
+
+Lorsque vous avez fini de modifier le fichier, vous pouvez faire un commit de vos modifications.
+Derrière ce mot, l'idée est assez simple, vous allez juste enregistrer vos modifications...
+
+
+Le premier champ est le nom de votre commit, une phrase très courte pour expliquer pourquoi vous avez fait cette modification.
+Le deuxième champ est un champ plus grand pour une explication plus complète, si vous en avez besoin.
+
+Enfin, si vous modifiez un dépôt sur lequel vous avez la permission d'écrire, vous pouvez soit faire un commit directement sur la branche en cours, soit créer une nouvelle branche.
+Il est généralement préférable de créer une nouvelle branche, de cette façon vous gardez vos modifications sur une version *parallèle* du dépôt. Vos modifications seront discutées dans une pull request (expliquée ci-dessous) puis finalement fusionnées dans la branche d'origine.
+
+#### Forker ou ne pas forker
+
+Un fork est une copie d'un dépôt sur votre propre compte.
+Nous avons déjà vu que si vous n'avez pas l'autorisation d'écrire dans un dépôt, la modification d'un fichier créera automatiquement un fork.
+Comme le fork est sur votre compte, vous avez toujours la permission d'écrire dessus.
+Mais même si un fork n'est pas le véritable dépôt, mais juste une copie, un fork est toujours lié à son parent. Nous verrons plus tard que la création d'un fork est vraiment utile lors de l'ouverture d'une pull request.
+
+Lorsque vous créez un nouveau package, il est courant d'utiliser l'[application exemple](https://github.com/YunoHost/example_ynh) comme base.
+Mais, comme vous ne voulez pas garder ce lien vers l'application d'exemple, vous ne devez pas forker l'application d'exemple. Vous la clonerez plutôt.
+Malheureusement, cloner une application est un peu plus compliqué sur GitHub. Nous verrons plus tard comment cloner vers un dépôt local à la place.
+
+Nous avons vu comment éditer un fichier, et comment cela peut forker l'application.
+Mais, lorsque vous voulez éditer plusieurs fichiers, l'interface GitHub n'est pas vraiment la meilleure solution. Dans une telle situation, vous préférerez cloner le dépôt et travailler sur un dépôt local.
+Il se peut que vous deviez tout de même forker sur votre propre compte pour pouvoir enregistrer vos modifications si vous n'avez pas les autorisations sur le dépôt distant.
+
+#### Pull request
+
+Après avoir effectué vos commits, que ce soit sur une branche ou un fork, vous souhaitez proposer vos modifications pour qu'elles soient intégrées dans le dépôt principal, ou dans la branche d'origine.
+Pour ce faire, vous allez créer une pull request. GitHub vous demande généralement directement si vous souhaitez le faire.
+Sinon, vous trouverez le bouton de création d'une pull request juste ici :
+
+
+Lors de la création d'une pull request à partir d'un fork, pour faciliter le travail de révision du code, **ne jamais** décocher la case *Allow edits from maintainers*. Cette option permet simplement aux mainteneurs du dépôt d'origine de modifier directement votre travail.
+
+#### Organisation YunoHost-Apps
+
+Conformément à la [YEP 1.7](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines.md#yep-17), votre application doit être intégrée à l'organisation YunoHost-Apps, mais si vous n'avez jamais contribué à une application auparavant ou si vous n'avez jamais eu d'application dans cette organisation, vous n'en aurez peut-être pas l'autorisation.
+
+Tout d'abord, vous devez avoir la permission d'écrire dans l'organisation, pour ce faire, demandez au groupe Apps sur le salon XMPP Apps.
+
+Pour transférer votre application sur l'organisation YunoHost-Apps, allez dans votre dépôt et dans l'onglet *Settings*.
+En bas de la page, vous trouverez *Transfer ownership*.
+Dans le champ *New owner’s GitHub username or organization name*, tapez *YunoHost-Apps*.
+Votre dépôt sera déplacé dans l'organisation, vous n'avez pas besoin de supprimer le dépôt d'origine.
+
+
+## Travailler avec Git en local
+
+Comme nous l'avons vu, vous pouvez faire beaucoup de choses directement sur GitHub.
+Mais lorsque vous devez modifier plusieurs fichiers, ou lorsque vous devez travailler sur votre code de votre côté, il est préférable de travailler directement sur votre ordinateur.
+
+Avant d'aller dans la partie infernale de Git, voyons 2 façons différentes de commencer à travailler avec Git.
+
+#### Premier cas : Créer un nouveau package
+
+Vous avez découvert, choqué, que la merveilleuse application que vous aimez utiliser tous les jours n'a pas encore son package YunoHost. Et parce que vous êtes sympa, vous avez décidé de créer vous-même le package, pour que tout le monde puisse apprécier cette application.
+Quelle bonne idée !
+
+Le mieux est de commencer par l'[application d'exemple](https://github.com/YunoHost/example_ynh). Mais comme nous l'avons déjà expliqué, vous ne voulez pas forker, parce que si vous le faites, vous allez garder ce lien vers l'application d'exemple et c'est vraiment ennuyeux.
+Donc, vous allez le faire différemment. Vous allez cloner !
+
+##### git clone
+
+Pour cloner, vous allez faire :
+```bash
+git clone https://github.com/YunoHost/example_ynh
+```
+`git clone` téléchargera une copie du dépôt. Vous aurez le dépôt complet, avec ses branches, ses commits, et tout le reste (dans cet apparent petit répertoire `.git`).
+
+git clone est généralement le point de départ de tout travail local avec Git.
+
+*Toutefois, si vous comptez envoyer vos modifications sur le dépôt distant sur GitHub, assurez-vous d'avoir les droits d'écriture sur ce dépôt. Sinon, forkez avant et clonez votre fork, pour lequel vous avez la permission.*
+
+##### Mon nouveau package, suite
+
+Dans le contexte d'un nouveau package, vous devrez également créer un dépôt sur GitHub pour y mettre votre package.
+Ce qui n'est pas plus compliqué qu'un gros bouton vert *New*.
+Ne vous embêtez pas avec des README, .gitignore ou licence. Créez simplement le dépôt lui-même.
+vous pouvez maintenant cloner ce nouveau dépôt avec Git.
+
+
+Vous disposez maintenant de 2 dépôts clonés sur votre ordinateur.
+Copiez tous les fichiers de l'application example_ynh, **excepté le répertoire .git** (vous voulez juste les fichiers eux-mêmes) dans votre nouveau package.
+
+*Si vous le souhaitez, vous pouvez supprimer l'application example_ynh. Nous n'en avons plus besoin.*
+
+Vous êtes prêt à travailler sur votre nouveau package !
+
+#### Deuxième cas : Travailler localement sur un dépôt
+
+Vous disposez déjà d'un dépôt, mais ce que vous voulez, c'est travailler localement, de sorte que vous puissiez modifier plusieurs fichiers.
+Il vous suffit de cloner le dépôt, le répertoire .git est le lien vers le dépôt distant. Rien d'autre à faire qu'un `git clone`.
+
+#### Branches
+
+Vous avez bien votre copie local du dépôt, mais comme vous avez lu attentivement cette documentation jusque-là, vous savez que vous devez vous assurer d'être sur la branche testing avant de commencer à travailler.
+
+Pour voir les branches, et savoir sur quelle branche vous êtes réellement, alors que vous êtes dans le répertoire de votre dépôt, tapez `git branch`.
+La branche courante est mise en évidence et précédée d'un "*".
+
+#### git checkout
+
+S'il apparaît que vous n'êtes pas sur la branche où vous vouliez être, ou que vous êtes en fait sur master (ce qui est mal !), vous pouvez passer à une autre branche avec `git checkout`.
+```bash
+git checkout testing
+```
+*Lisez attentivement ce que Git dit quand vous validez une commande, n'oubliez jamais que Git est sournois...*
+
+#### git pull avant tout
+
+Vous êtes enfin dans la bonne branche, et prêt à travailler.
+**Attendez ! Un vilain piège vous attend...**
+Avant de vous retrouver dans une situation inextricable. Commencez par un `git pull` pour mettre à jour votre branche avec les derniers changements du dépôt distant.
+
+*Parfois, vous rencontrerez une situation impossible où Git vous dira que vous ne pouvez pas pull parce que vous avez des changements locaux. Mais vous ne vous souciez pas de ces modifications locales, vous voulez juste obtenir la dernière version de la branche distante. Mais Git ne se soucie pas de ce que VOUS voulez...*
+*Je dois admettre que ma seule solution est aussi efficace que sale... Un bon vieux `rm -r` du dépôt et un `git clone`*
+
+#### Il est temps de travailler
+
+Vous pouvez finalement travailler sur votre code.
+Lorsque vous êtes enfin d'accord avec ce que vous avez fait, il est temps de valider votre travail.
+
+La première étape consiste à informer Git sur le(s) fichier(s) à valider. Pour ce faire, nous utiliserons `git add`.
+```bash
+git add mon_fichier
+ajouter mon_autre_fichier et_aussi_celui_ci
+```
+Si vous souhaitez valider l'ensemble de votre travail, vous pouvez aussi simplement faire
+```bash
+git add --all
+```
+
+Pour vérifier l'état actuel de votre validation, vous pouvez utiliser `git status`. Il vous montrera quels fichiers seront inclus dans votre commit, et quels fichiers sont modifiés, mais pas encore inclus.
+`git status -v` vous indiquera également quelle partie des fichiers est modifiée. Une bonne façon de s'assurer que vous n'avez pas fait d'erreur avant de faire un commit.
+
+#### git checkout -b
+
+Avant de faire un commit, ou après, ou avant de commencer à travailler. Quand vous en avez envie !
+Vous devriez envisager d'ajouter votre travail à une branche séparée, de cette façon, il sera facile de créer une pull request dans la branche testing et de discuter avec les autres packagers de ce que vous suggérez de changer.
+
+Pour créer une nouvelle branche et passer à cette branche, vous pouvez utiliser `git checkout -b my_new_branch`.
+
+#### Commit
+
+Faire un commit, c'est simplement valider son travail dans Git. Comme vous pouvez le faire dans GitHub.
+Pour avoir les mêmes champs que vous aviez sur GitHub, avec le nom du commit, et une explication plus longue. Vous pouvez simplement utiliser `git commit`.
+La première ligne, avant les commentaires, est pour le nom du commit.
+Après tous les commentaires, vous pouvez ajouter une explication si vous le souhaitez.
+
+Si vous voulez faire un commit avec seulement un nom pour votre commit, vous pouvez utiliser une simple commande :
+```bash
+git commit -m "My commit name"
+```
+
+#### Push vers le dépôt distant
+
+Vos modifications sont validées, mais uniquement sur votre clone local du dépôt. Maintenant, vous devez renvoyer ces modifications sur le dépôt distant sur GitHub.
+Pour ce faire, vous devez savoir quelle est votre branche actuelle. (Si vous ne le savez pas, `git branch` vous donnera cette information).
+Ensuite, vous pouvez git push
+```bash
+git push -u origin BRANCH_NAME
+```
diff --git a/packaging_apps_guidelines.md b/packaging_apps_guidelines.md
new file mode 100644
index 00000000..933c4c4c
--- /dev/null
+++ b/packaging_apps_guidelines.md
@@ -0,0 +1,450 @@
+# Packing Applications: Good Practise Guidelines
+
+
+
+This page is under development. As long as this warning is not removed. Consider this information as potentially false.
+The name YEP is not a priori definitive, neither the levels nor the good practices in itself.
+
+
+
+### Introduction
+The purpose of this document is to list the various best practices concerning the creation of YunoHost application packages.
+
+Each good practice is numbered with a number suffixed by the letters YEP (YunoHost Enhancement Proposals), so that it can be easily referenced in the ([package checker](https://github.com/YunoHost/package_check) and [package linter](https://github.com/YunoHost/package_linter)) tools, but also during the reviews of code.
+
+Each YEP is associated with:
+* a status indicating whether the rule has been validated or is still under discussion (draft, validated, refused, obsolete);
+* an indication of the type of test to be carried out (manual or auto if an automatic tool can verify);
+* an indication of the app level from which the rule is required (NOTWORKING, INPROGRESS, WORKING, OFFICIAL), some rules are optional;
+
+### YEP Index
+| ID | Title | Status | Test | Level |
+| ---- | -------- | -------- | ------ | -------- |
+| ** YEP 1 ** | ** Communicate with the community ** | | | |
+| YEP 1.1 | App name and deposit | validated | manual | NOTWORKING (0) |
+| YEP 1.2 | Register the app on a known "directory" | validated | manual | NOTWORKING (0) |
+| YEP 1.3 | Indicate the license associated with the package | validated | AUTO | WORKING (5) |
+| YEP 1.4 | Inform about intention to maintain package | draft | manual | OFFICIAL (6) |
+| YEP 1.5 | Regularly update app status | draft | manual | WORKING (2) |
+| YEP 1.6 | Keeping up-to-date on the evolution of apps packaging | validated | manual | OFFICIAL (6) |
+| YEP 1.7 | Add the app to the [YunoHost-Apps Organization](https://github.com/YunoHost-Apps) | validated | manual | OFFICIAL (6) |
+| YEP 1.8 | Publish test requests | validated | manual | OFFICIAL (6) |
+| YEP 1.9 | Document the app | validated | AUTO | OFFICIAL (6) |
+| YEP 1.10 | Keep a clean version history | draft | manual | OFFICIAL (6) |
+| YEP 1.11 | Add app to [YunoHost bugtracker](https://github.com/YunoHost/issues/issues) | draft | manual | OFFICIAL (NA) |
+| YEP 1.12 | Follow the template from [example_ynh](https://github.com/YunoHost/example_ynh) | draft | manual | OFFICIAL (8) |
+| | | | | |
+| ** YEP 2 ** | ** Stabilize an app ** | ** Status ** | ** Test ** | ** Level ** |
+| YEP 2.1 | Respect the manifest format | validated | Home | INPROGRESS (5) |
+| YEP 2.2 | Using bash for main scripts | validated | Home | WORKING (1) |
+| YEP 2.3 | Save replies during installation | validated | manual | WORKING (3) |
+| YEP 2.4 | Detect and manage errors | draft | manual | WORKING (8) |
+| YEP 2.5 | Copy files correctly | draft | manual | WORKING (1) |
+| YEP 2.6 | Cancel action if input values are incorrect | validated | manual | WORKING (7) |
+| YEP 2.7 | Give sufficient permissions to bash | validated | Home | WORKING (1) |
+| YEP 2.8 | Correctly Changing a System Configuration | draft | manual | WORKING (8) |
+| YEP 2.9 | Remove all traces of the app when deleting | draft | manual | WORKING (6) |
+| YEP 2.10 | Configure application logs | draft | manual | WORKING (9) |
+| YEP 2.11 | Use a variable rather than the id app directly | validated | manual | OFFICIAL (9) |
+| YEP 2.12 | Using Helpers | validated | Home | OFFICIAL (5) |
+| YEP 2.13 | Translate the package in English | draft | manual | OFFICIAL (9) |
+| YEP 2.14 | Fill a conf file correctly | draft | manual | OFFICIAL (9) |
+| YEP 2.15 | Follow the instructions for installing the application | validated | manual | OFFICIAL (1) |
+| YEP 2.16 | Check availability of dependencies on ARM, x86 and x64 | validated | manual | OFFICIAL (8) |
+| YEP 2.17 | Take the original version into account when updating | validated | manual | OFFICIAL (9) |
+| | | | | |
+| ** YEP 2.18 ** | ** Stabilize a webapp ** | ** Status ** | ** Test ** | ** Level ** |
+| YEP 2.18.1 | Launch the script to install a webapp correctly | validated | manual | WORKING (5) |
+| YEP 2.18.2 | Manage installation at the root of a domain name | validated | Home | WORKING (2) |
+| YEP 2.18.3 | Manage installation on a subdomain | validated | Home | WORKING (2) |
+| YEP 2.18.4 | Manage installation on a path `/path` | validated | Home | OFFICIAL (2) |
+| YEP 2.18.5 | Manage the YunoHost tile for easy navigation between applications | validated | manual | OFFICIAL (8) |
+| | | | | |
+| ** YEP 3 ** | ** Secure an app ** | ** Status ** | ** Test ** | ** Level ** |
+| YEP 3.1 | Do not ask or store LDAP password | draft | manual | NOTWORKING (?) |
+| YEP 3.2 | Open a port correctly | draft | manual | WORKING (7) |
+| YEP 3.3 | Facilitating Source Integrity Control | draft | manual | OFFICIAL (6) |
+| YEP 3.4 | Isolate app | draft | manual | OFFICIAL (8) |
+| YEP 3.5 | Follow the recommendations of the app's documentation | validated | manual | OFFICIAL (6) |
+| YEP 3.6 | Update versions containing CVE | draft | manual | OFFICIAL (6) |
+| | | | | |
+| ** YEP 4 ** | ** Integrate an app ** | ** Status ** | ** Test ** | ** Level ** |
+| 4.1 | Link to LDAP | validated | manual | OFFICIAL (4) |
+| YEP 4.2 | Link authentication to SSO | validated | manual | OFFICIAL (4) |
+| YEP 4.2.1 | Sign Out | validated | manual | OFFICIAL (9) |
+| YEP 4.3 | Provide YunoHost Backup Script Functional | validated | Home | OFFICIAL (6) |
+| YEP 4.4 | Provide a YunoHost Restore Functional script | validated | Home | OFFICIAL (6) |
+| YEP 4.5 | Using Hooks | validated | manual | OPTIONAL (8) |
+| YEP 4.6 | Manage multi-instance | validated | manual | OPTIONAL (2) |
+| YEP 4.7 | Add a module to the CLI | validated | manual | OPTIONAL |
+| YEP 4.8 | Add a module to the web admin | draft | manual | OPTIONAL |
+
+### YEP 1
+#### Communicating with the community
+The YEP 1 is a meta YEP, it explains what it takes to interact with the community around a YunoHost application package.
+
+#### YEP 1.1
+##### App name and deposit | validated | manual | NOTWORKING |
+Each YunoHost application has an id registered in the application manifest.
+This identifier must be unique between each application packet.
+It is therefore recommended to verify its availability by consulting the list of applications referenced in the known applications repositories (official, community, internetcube).
+
+In addition, the identifier must respect the regular expression `^[a-z0-9]((_|-)?[A-z0-9])+$`.
+In other words, it must respect the following rules:
+* be in lowercase
+* start with a letter or number
+* be alphanumeric (the underscore is allowed)
+* do not contain two underscores or dashes that follow one another
+* do not end with an underscore or dash
+
+For application names containing spaces, virtually all current packages simply remove them without replacing them with dashes or underscores.
+
+By convention, the YunoHost application repositories are always named their ID followed by the string "\_ynh". Thus one can distinguish the upstream repository of the application, the deposit of the YunoHost package. This notation also makes it possible to find applications not listed by the search engines of platforms offering version managers (GitHub for example).
+
+Example: ID: Example Filing Name: example_ynh
+
+#### YEP 1.2
+##### Register the app on a known "directory" | validated | manual | NOTWORKING |
+It is advised from the beginning of the packaging to register an app on one of the YunoHost application depots.
+
+These deposits have several functions:
+* communicate the existence of a package;
+* indicate the latest version associated with the package (to allow the update of the app by YunoHost);
+* indicate the state of operation of the packet;
+* indicate information about the support of a package.
+
+For the `apps.json` list maintained by the project team, registration is on [the git apps repository](https://github.com/YunoHost/apps). Other non-official lists may exists (including those for non-free apps for example), see more about that in the [community forum](https//forum.yunohost.org).
+
+#### YEP 1.3
+##### Indicate the license associated with the package | draft | AUTO | WORKING |
+The license of the packet must be specified in a `LICENSE` file at the root of the packet. Be careful not to confuse with the license of the application that will be installed whose acronym is to be entered in the `license` field of the manifest.
+
+The application list apps.json only accept packages with a free license, as well as the license for the contained application. Some free applications require non-free dependencies (example: MP3, drivers, etc.). In this case, you should add `&dep-non-free` to the acronym and if possible give details in the README.md of the package, in this case the integration will be accepted on a case-by-case basis.
+
+**NB:** Apps not included in apps.json lists may still be installed: either manually with the URL to the app, or in a more practical way using non-official lists (which can be created and maintained by the community).
+
+In the future, YunoHost will probably display details about the license of the application. To achieve this, the acronym must be the one from this [list of licenses listed in the SPDX](https://spdx.org/licenses/) (if there are 2 acronyms, the one containing the version number). For consistency, the case must be respected.
+
+If the license is not present in the list, in this case it is necessary to indicate `free` or `non-free` depending on whether it is free or not and give the user the opportunity to inquire in the README.md (link, explanations...).
+
+Example: for a GNU Lesser General Public License (LGPL), version 3 the acronym is `LGPL-3.0` if non-free dependencies are used in this case it will be necessary to put LGPL-3.0 & dep-non-free `in the manifesto.
+
+If an application has modules linked to another license (Example: Odoo 9 LGPL-3.0 + a module licensed AGPL-3.0), in this case we will indicate the two licenses separated by a `&`.
+
+If two separate applications are in the same installation package and have separate licenses, in this case we can use `,` to separate the licenses.
+
+In both cases, the maintainer is encouraged to consider creating two separate packages. The manifest of each application is used to ask app-type questions to refer to another application already installed.
+
+Reminder: a question of type `app` answers the identifier of one of the apps already installed.
+
+Some interesting links to help with the choice of license:
+* [Explanatory sheets on free licenses](https://www.inria.fr/content/download/5896/48452/version/2/file/INRIA_recueil_fiches_licences_libres_vf.pdf)
+* [GNU project licensing documentation](https://www.gnu.org/licenses/licenses.html)
+* [A Guide to the GNU Project to Help Choose a License](https://www.gnu.org/licenses/license-recommendations.en.html)
+
+#### YEP 1.4
+##### Inform about intention to maintain package | draft | manual | OFFICIAL |
+The maintainer of the application must undertake to maintain its app over time if he wishes it to join the list of official applications.
+This involves monitoring updates to the upstream application, adhering to the new packaging rules and responding to user requests.
+
+#### YEP 1.5
+##### Regularly update app status | draft | manual | WORKING |
+#### YEP 1.6
+##### Keeping up-to-date on the evolution of apps packaging | validated | manual | OFFICIAL |
+In order to keep up with the evolution of the packaging format and best practices, it is recommended to:
+* follow [the forum's Apps category](https://forum.yunohost.org/c/contribute-room/apps-packaging)
+
+To follow the evolution of YunoHost more generally:
+* join XMPP dev@conference.yunohost.org ([three days of logs are available](https://im.yunohost.org/logs/dev/))
+* follow [Annoucement category of the forum](https://forum.yunohost.org/c/announcement)
+
+#### YEP 1.7
+##### Add the app to the [YunoHost-Apps Organization](https://github.com/YunoHost-Apps) | validated | manual | OFFICIAL |
+Adding an app to the [YunoHost-Apps organization](https://github.com/YunoHost-Apps) lets you share apps with other contributors who might be tempted to package the targeted application.
+
+It is also a way to quickly deploy a security patch if necessary in the event that the maintainer is unavailable.
+
+Transfer Procedure: Ask the [chat room](/chat_rooms) to be invited to the organization by providing the name of their GitHub account.
+Once the invitation is accepted, [transfer its deposit to the organization by following this tutorial](https://help.github.com/articles/transferring-a-repository-owned-by-your-personal-account/# Transferring-a-repository-to-another-user-account-or-to-an-organization).
+
+#### YEP 1.8
+##### Publish test requests | validated | manual | OFFICIAL |
+In order to ensure the proper functioning of a package, it is necessary to publish an announcement in order to open the tests on the package. This announcement can be done on the forum in [Forum Apps category](https://forum.yunohost.org/c/apps).
+
+It is recommended to indicate if some tests have not been conducted.
+
+* Check package with Package linter.
+* Installation in subfolder.
+* Installation at the root of a domain or subdomain.
+* Deletion, in the 2 cases of previous installations.
+* Access to the web interface of the application, with the / final in the address, and omitting it.
+* Upgrade on the same version of the package.
+* Upgrade from an older version of the package.
+* Private installation (secured by SSO).
+* Public installation.
+* Multi-instance installation.
+* User name error.
+* Domain name error.
+* Poorly written path (path / instead of / path for example).
+* Port already used by another application.
+* Source corrupted after download.
+* Error downloading source.
+* Folder already used by another application.
+* Backup and restore.
+
+#### YEP 1.9
+##### Document the app | validated | AUTO | OFFICIAL |
+Above all, it is appropriate to make a correct description of the app in the `description` field of the manifest. Keyword insertion in this description can be a good idea, as a user might be required to search (CTRL + F) among all applications.
+
+There is also README.md, which must and can contain:
+* the name of the app
+* a brief summary of what it does
+* any additional installation if the script is not sufficient
+* instructions to use it (for example to connect your smartphone or computer)
+* the location to report a malfunction / request
+* the roadmap / TODO
+* possibly prerequisites in terms of RAM memories, processor etc. (some equipment has less than 512 MB of RAM)
+
+#### YEP 1.10
+##### Keep a clean version history | draft | manual | OFFICIAL |
+#### YEP 1.11
+##### Add app to [YunoHost bugtracker](https://github.com/YunoHost/issues/issues) | draft | manual | OFFICIAL |
+
+#### YEP 1.12
+##### Follow the template from [example_ynh](https://github.com/YunoHost/example_ynh) | draft | manual | OFFICIAL |
+In order to facilitate the work of the community regarding a package, it has to follow the template shown by the example app.
+This will help other packagers to read, modify and debug the package. Also, it will help extend the life of the package by giving it a standard template that other packagers can quickly understand in the event that a package becomes orphaned.
+As well, a package should not use exotic or uselessly complicated code if it's not really needed. If so, this part of the code should be clearly documented.
+Keep your code as easy as possible, keep everything a script needs directly into it. Do not move functions in another file. Keep it simple and efficient.
+
+### YEP 2
+#### Stabilize an app
+#### YEP 2.1
+##### Respect the manifest format | validated | Home | INPROGRESS |
+The manifest allows to describe an app so that YunoHost can apply the good treatments. For more information see [dedicated documentation](/packaging_apps_manifest).
+
+#### YEP 2.2
+##### Using bash for main scripts | validated | Home | WORKING |
+Action scripts (install, upgrade, remove, backup and restore) must be in the bash so that the CLI/API YunoHost can call them correctly.
+
+That being said, there is nothing to prevent other scripts or function libraries from using these scripts. These are not obliged to be in bash.
+
+However, careful attention must be paid to the correct display of logs of information, warning, or errors. So that a user of the CLI/API YunoHost can understand the operation of the script just executed and if necessary repair its YunoHost instance.
+
+#### YEP 2.3
+##### Save the answers during the installation | validated | manual | WORKING |
+During installation, it is necessary to save each answer to the questions in the manifest. Indeed, even if at the beginning it is not necessary to write an update script, thereafter it will probably be the case. However, without the initial information, the update can be more tedious.
+
+#### YEP 2.4
+##### Detecting and Managing Errors | draft | manual | WORKING |
+The install, upgrade, backup, and restore scripts must detect errors to avoid further scripting in case of blocking error or empty variable usage.
+The use of trap and `set -eu` is recommended to detect and treat errors ([Discussion in progress](https://forum.yunohost.org/t/gestion-des-erreurs-set-e-and-or-trap/2249/5))
+It is also necessary to check the contents of the variables before removing the remove script. For example, an `rm -Rf /var/www/$app` with `$app` empty would have a disastrous result.
+
+At the beginning of the scripts, before any modifications, it is necessary to check the existence of the users mentioned at the installation, as well as the availability of the requested path, the availability of the final file of the application and the size of the passwords if necessary.
+
+ Do not forget that in case of installation error the removal script will be launched automatically by the YunoHost CLI.
+
+#### YEP 2.5
+##### Copy files correctly | draft | manual | WORKING |
+#### YEP 2.6
+##### Cancel action if input values are incorrect | validated | manual | WORKING |
+Each script should verify that the input values are correct.
+
+Here are some examples:
+* Check that the domain name exists
+* Check that the user exists
+* Check that the chosen path is available
+
+If one of the values is incorrect, it is necessary to cancel any modifications made previously to the instance. The best thing is to do all these checks before changing the system.
+
+#### YEP 2.7
+##### Give sufficient permissions to bash | validated | Home | WORKING |
+Some instructions require sudo rights. In this case, do not forget to prefix these instructions with `sudo`.
+
+In other cases it is necessary to give rights using chmod and chown.
+
+#### YEP 2.8
+##### Correctly changing a system configuration | draft | manual | WORKING |
+Changes to the system must be reversible so that the removal of the application is of no consequence to the system leaves no residue.
+For this purpose, the `.d` folders of the system configurations must be used as much as possible. Where it is not possible to do otherwise, clearly indicate the configuration as modified by an application and ensure that the changes will be removed when it is removed.
+
+#### YEP 2.9
+##### Remove all traces of the app when deleting | draft | manual | WORKING |
+Except for dependencies (eg, Debian packages) used by other services or applications.
+
+#### YEP 2.10
+##### Configure application logs | draft | manual | WORKING |
+If possible, the application should use a log file, which will preferably be in /var/log.
+If the log is set up by the install script and not by the application itself, a log-rotate configuration file will have to be added to handle the logs of the application.
+
+#### YEP 2.11
+##### Using a variable rather than the app id directly | validated | manual | OFFICIAL |
+It is advisable to make the scripts as generic as possible, a good way to do this is to use a variable for the app's name to avoid it being found everywhere in scripts. This will make it easier for another package builder to use the script for another app.
+
+#### YEP 2.12
+##### Using Helpers | validated | Home | OFFICIAL |
+In order to simplify packaging, standardize practices, avoid errors and increase the lifetime of a script vis-à-vis future versions of YunoHost. A set of helpers to do many actions is proposed.
+
+For more information :
+* consult [helpers documentation](/packaging_apps_helpers)
+* explore [helpers directory](https://github.com/YunoHost/yunohost/tree/unstable/data/helpers.d)
+
+#### YEP 2.13
+##### Translate the package in English | draft | manual | OFFICIAL |
+#### YEP 2.14
+##### Fill a conf file correctly | draft | manual | OFFICIAL |
+* Just to clear up a little this YEP, but it remains in draft form. *
+The goal is to find a more reliable method than sed to modify the configuration files. sed can possibly have edge effects by modifying unwanted parts of the configuration file, especially with the use of regex.
+
+#### YEP 2.15
+##### Follow the instructions for installing the application | validated | manual | OFFICIAL |
+
+#### YEP 2.16
+##### Check availability of dependencies on ARM, x86, and x64 | validated | manual | OFFICIAL |
+YunoHost installs on ARM, x86 and x64. A package should therefore be tested on these three processor architectures.
+
+Some packages are not available on ARM, in this case it is advisable to study other solutions or to indicate in the README.md that the application does not work on ARM and to block the installation by detection of type d'architecture.
+
+#### YEP 2.17
+##### Take the original version into account when updating | validated | manual | OFFICIAL |
+The update script must be able to run even if the previous updates have not been performed.
+
+For example, it should be possible to perform update jumps from an N-x version to an N version. To do this, it is advisable to save the version numbers in the app settings.
+
+### YEP 2.18
+##### Stabilizing a webapp
+The majority of YunoHost applications are web apps, but some are not. The YEP 2.18.x develop certain specificities related to the web app.
+
+#### YEP 2.18.1
+##### Launch the script to install a webapp correctly | validated | manual | WORKING |
+Often a web app installs itself from forms displayed on a web page. This practice, while practical for a human, is less so for a program.
+
+It is therefore necessary to check if the application does not propose a solution of installation on command line.
+
+If this is not the case, the -H option of curl should be used. In some cases, DNS redirection may not be active at the time of installation.
+`` `Bash
+curl -kL -H "Host: $domain" --data "¶m1=Text1¶m2=text2" https: //localhost$path/install.php > /dev/null 2>&1
+`` `
+
+#### YEP 2.18.2
+##### Manage installation at the root of a domain name | validated | Home | WORKING |
+A web app should be able to install itself at the root of a domain name.
+
+#### YEP 2.18.3
+##### Manage installation on a subdomain | validated | Home | WORKING |
+A web app should be able to install itself on a subdomain directly without subfolders.
+
+#### YEP 2.18.4
+##### Manage installation on a path `/path` | validated | Home | OFFICIAL |
+A web app should be able to install on a path `/path`.
+
+#### YEP 2.18.5
+##### Manage the YunoHost tile to easily navigate between applications | validated | manual | OFFICIAL |
+Except in rare cases it is advisable to integrate the tile YunoHost which allows to return to the menu of the SSO. This integration is done in the NGINX configuration.
+
+Some users have replaced this square with a script adding a menu at the top of each webapp.
+
+### YEP 3
+#### Securing an app
+#### YEP 3.1
+##### Do not ask or store LDAP password | draft | manual | NOTWORKING |
+#### YEP 3.2
+##### Open a port correctly | draft | manual | WORKING |
+If the application requires the opening of a port, it is necessary to check beforehand that this port is not already used by another application. If so, the install script must be able to find another available port.
+It should also be checked whether the port should be open on the router, beyond the local network. If this is not the case, the `--no-upnp` argument must be added to the` yunohost firewall allow` command in order to limit the port opening to the LAN only.
+
+#### YEP 3.3
+##### Facilitating Source Integrity Control | draft | manual | OFFICIAL |
+The upstream application should not be integrated into tarball in the source folder of the package, as this adds to the package and the Git repository and does not allow verification of the integrity of the source.
+The source must be downloaded from the official website, then its integrity must be checked before installing it.
+
+#### YEP 3.4
+##### Isolate app | draft | manual | OFFICIAL |
+In order to avoid edges in case of possible compromise of the application, it must be insulated in order not to affect the other applications.
+To do this, it is necessary to isolate the application in its execution folder by restricting its environment by a chroot, either by a mechanism internal to the application where possible (for example for an ftp server), or by the use of phpfpm.
+Similarly, to restrict the scope of the user running the application, it is preferable to use a user dedicated to the application. Whose rights are restricted to the use of the application only.
+However, this should not exempt from a maximum restriction of rights on application files. As much as possible, the files must belong to root, and the dedicated user must have write rights only on files that specifically request it.
+
+#### YEP 3.5
+##### Follow the recommendations in the app's documentation | validated | manual | OFFICIAL |
+Typically, an application provides documentation to help system administrators perform the installation. It is advisable to follow the recommendations, including the permissions to be granted per file or directory.
+
+However, the package maintainer must remain vigilant, some documentation may be erroneous or insufficient.
+
+#### YEP 3.6
+##### Update versions with CVE | draft | manual | OFFICIAL |
+The [CVE](https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures), or Common Vulnerabilities and Exposures, identify security vulnerabilities common to applications. The corrections of these flaws may concern the application and it is important in this case to follow these updates as closely as possible.
+More generally, the application can propose a patch for a specific vulnerability to itself.
+Generally, this YEP involves tracking an information channel to track application security updates and reacting quickly by updating the package accordingly.
+
+As specified in YEP 1.7, if a security patch is to be deployed urgently, another YunoHost member may be required to commit to the package if necessary.
+
+### YEP 4
+#### Embedding an app
+This meta YEP deals with the integration of an app with the YunoHost environment. Good integration is generally a guarantee of quality and comfort for users.
+
+#### YEP 4.2
+##### Linking Authentication to sso | validated | manual | OFFICIAL |
+The Single Sign On makes it possible to avoid having to create the same users for each app. Thus, a YunoHost user can connect via the Single Sign On to all the apps.
+
+To do this, you must link your app to the LDAP and / or use hooks to duplicate the account credentials in the app's database.
+
+Once this is done, the maintainer can use the REMOTE_USER HTTP statement to check whether a user is logged on or not. In general, modules exist (whether at the level of the technology, the framework or even the app itself).
+
+If required, SSOwat can be used to secure access to one or more parts of the app. It may be relevant to secure access to an administration page with the SSO rather than a `.htaccess` and make the rest of the app accessible to all visitors.
+
+#### YEP 4.2.1
+##### Logout | validated | manual | OFFICIAL |
+When you click on a disconnect action within the app, it should disconnect the user from the SSO. Otherwise, there is a risk that the user will inadvertently leave an open session.
+
+#### YEP 4.3
+##### Provide YunoHost Backup Script Functional | validated | Home | OFFICIAL |
+The application must have a backup script to allow users to back up the application, its configuration, and its data.
+
+#### YEP 4.4
+##### Provide a functional YunoHost restoration script | validated | Home | OFFICIAL |
+The application must have a restore script to allow users to restore an application previously backed up with the backup script.
+
+#### YEP 4.5
+##### Using Hooks | validated | manual | OPTIONAL |
+YunoHost offers the possibility to launch actions with each processing carried out by the command line. This can be practical in many cases.
+
+Examples:
+* Add / delete a user in the app database when using `yunohost user create` or` yunohost user remove`
+* Manage the addition of a new domain name during the `yunohost domain add` action
+* Run a script after the firewall has been reloaded
+
+List of hooks:
+* post_domain_add
+* post_domain_remove
+* post_user_create
+* post_user_delete
+* post_backup_create
+* post_backup_restore
+* pre_backup_delete
+* post_backup_delete
+* post_app_addaccess
+* post_app_removeaccess
+* post_app_clearaccess
+* post_app_addaccess
+* post_iptable_rules
+
+These scripts are to be placed in a `hooks` directory as in this package: https://github.com/YunoHost-Apps/owncloud_ynh/tree/master/hooks.
+
+
+#### YEP 4.6
+##### Manage multi-instance | validated | manual | OPTIONAL |
+It is sometimes practical to be able to install the same app several times. For example, for several different domain names.
+
+However, be careful about how to handle file paths, dependencies, ports used, etc. so that there is no collision.
+
+#### YEP 4.7
+##### Add a module to the CLI | validated | manual | OPTIONAL |
+You can create a module to add commands to the yunohost command line.
+
+To do this, you need to add an actionmaps to `/usr/share/moulinette/actionsmap/`. This actionmaps must start with `ynh_`.
+
+The packages [menu_ynh](https://github.com/YunoHost-Apps/menu_ynh/) and [subscribe_ynh](https://github.com/YunoHost-Apps/subscribe_ynh/) are old (and not up to date) can be used as the basis for this type of module.
+#### YEP 4.8
+##### Add a module to the web admin | draft | manual | OPTIONAL |
diff --git a/packaging_apps_guidelines_fr.md b/packaging_apps_guidelines_fr.md
new file mode 100644
index 00000000..64c1e63e
--- /dev/null
+++ b/packaging_apps_guidelines_fr.md
@@ -0,0 +1,465 @@
+# Packaging d’applications : les bonnes pratiques
+
+
+
+Cette page est en cours d'élaboration. Tant que cet avertissement n'est pas enlevé. Considérez ces informations comme potentiellement fausse.
+Le nom YEP n'est à priori pas définitif, ni les niveaux, ni les bonnes pratiques en elle-même.
+
+
+
+### Introduction
+Ce document a pour but de lister les différentes bonnes pratiques concernant la création de paquet d'application YunoHost.
+
+Chaque bonne pratique est numérotée avec un numéro suffixé par les lettres YEP (YunoHost Enhancement Proposals), ceci afin de pouvoir y faire référence facilement dans les outils d'analyse automatique de paquet ([package checker](https://github.com/YunoHost/package_check), [package linter](https://github.com/YunoHost/package_linter)), mais également lors des revues de code.
+
+Chaque YEP est associée à :
+* un statut indiquant si la règle a été validée ou si elle fait encore l'objet de discussion (brouillon, validé, refusé, obsolète) ;
+* une indication sur le type de test à mener (manuel ou auto si un outil automatique peut vérifier) ;
+* une indication du niveau d'app à partir duquel la règle est nécessaire (NOTWORKING, INPROGRESS, WORKING, OFFICIAL), certaines règles sont optionnelles ;
+
+### Index des YEP
+| ID | Titre | Statut | Test | Niveau |
+|----|--------|--------|------|--------|
+| **YEP 1** | **Communiquer avec la communauté** | | | |
+| YEP 1.1 | Nommer son app et son dépot | validé | manuel | NOTWORKING (0) |
+| YEP 1.2 | Inscrire l'app sur un "répertoire" connu | validé | manuel | NOTWORKING (0) |
+| YEP 1.3 | Indiquer la licence associée au paquet | validé | AUTO | WORKING (5) |
+| YEP 1.4 | Informer sur l'intention de maintenir un paquet | brouillon | manuel | OFFICIAL (6) |
+| YEP 1.5 | Mettre à jour régulièrement le statut de l'app | brouillon | manuel | WORKING (2) |
+| YEP 1.6 | Se tenir informé sur l'évolution du packaging d'apps | validé | manuel | OFFICIAL (6) |
+| YEP 1.7 | Ajouter l'app à l'[organisation YunoHost-Apps](https://github.com/YunoHost-Apps) | validé | manuel | OFFICIAL (6) |
+| YEP 1.8 | Publier des demandes de test | validé | manuel | OFFICIAL (6) |
+| YEP 1.9 | Documenter l'app | validé | AUTO | OFFICIAL (6) |
+| YEP 1.10 | Garder un historique de version propre | brouillon | manuel | OFFICIAL (6) |
+| YEP 1.11 | Ajouter l'app au [bugtracker YunoHost](https://github.com/yunohost/issues/issues) | brouillon | manuel | OFFICIAL (NA) |
+| YEP 1.12 | Suivre le modèle de [example_ynh](https://github.com/YunoHost/example_ynh) | brouillon | manuel | OFFICIAL (8) |
+| | | | | |
+| **YEP 2** | **Stabiliser une app** | **Statut** | **Test** | **Niveau** |
+| YEP 2.1 | Respecter le format du manifeste | validé | auto | INPROGRESS (5) |
+| YEP 2.2 | Utiliser bash pour les scripts principaux | validé | auto | WORKING (1) |
+| YEP 2.3 | Sauvegarder les réponses lors de l'installation | validé | manuel | WORKING (3) |
+| YEP 2.4 | Détecter et gérer les erreurs | brouillon | manuel | WORKING (8) |
+| YEP 2.5 | Copier correctement des fichiers | brouillon | manuel | WORKING (1) |
+| YEP 2.6 | Annuler l'action si les valeurs d'entrées sont incorrectes | validé | manuel | WORKING (7) |
+| YEP 2.7 | Donner des permissions suffisantes aux instructions bash | validé | auto | WORKING (1) |
+| YEP 2.8 | Modifier correctement une configuration système | brouillon | manuel | WORKING (8) |
+| YEP 2.9 | Enlever toutes traces de l'app lors de la suppression | brouillon | manuel | WORKING (6) |
+| YEP 2.10 | Configurer les logs de l'application | brouillon | manuel | WORKING (9) |
+| YEP 2.11 | Utiliser une variable plutôt que l'app id directement | validé | manuel | OFFICIAL (9) |
+| YEP 2.12 | Utiliser les commandes pratiques (helpers) | validé | auto | OFFICIAL (5) |
+| YEP 2.13 | Traduire le paquet en anglais | brouillon | manuel | OFFICIAL (9) |
+| YEP 2.14 | Remplir correctement un fichier de conf | brouillon | manuel | OFFICIAL (9) |
+| YEP 2.15 | Suivre les instructions d'installation de l'application | validé | manuel | OFFICIAL (1) |
+| YEP 2.16 | Vérifier la disponibilité des dépendances sur ARM, x86 et x64 | validé | manuel | OFFICIAL (8) |
+| YEP 2.17 | Prendre en compte la version d'origine lors des mises à jour | validé | manuel | OFFICIAL (9) |
+| | | | | |
+| **YEP 2.18** | **Stabiliser une webapp** | **Statut** | **Test** | **Niveau** |
+| YEP 2.18.1 | Lancer le script d'installation d'une webapp correctement | validé | manuel | WORKING (5) |
+| YEP 2.18.2 | Gérer l'installation à la racine d’un nom de domaine | validé | auto | WORKING (2) |
+| YEP 2.18.3 | Gérer l'installation sur un sous-domaine | validé | auto | WORKING (2) |
+| YEP 2.18.4 | Gérer l'installation sur un chemin `/path` | validé | auto | OFFICIAL (2) |
+| YEP 2.18.5 | Gérer la tuile YunoHost pour faciliter la navigation entre les applications | validé | manuel | OFFICIAL (8) |
+| | | | | |
+| **YEP 3** | **Sécuriser une app** | **Statut** | **Test** | **Niveau** |
+| YEP 3.1 | Ne pas demander ou stocker de mot de passe LDAP | brouillon | manuel | NOTWORKING (?) |
+| YEP 3.2 | Ouvrir un port correctement | brouillon | manuel | WORKING (7) |
+| YEP 3.3 | Faciliter le contrôle de l'intégrité des sources | brouillon | manuel | OFFICIAL (6) |
+| YEP 3.4 | Isoler l'app | brouillon | manuel | OFFICIAL (8) |
+| YEP 3.5 | Suivre les recommendations de la documentation de l'app | validé | manuel | OFFICIAL (6) |
+| YEP 3.6 | Mettre à jour les versions contenant des CVE | draft | manuel | OFFICIAL (6) |
+| YEP 3.7 | Modifier correctement les dépots sources | draft | manuel | NOTWORKING (0) |
+| | | | | |
+| **YEP 4** | **Intégrer une app** | **Statut** | **Test** | **Niveau** |
+| 4.1 | Lier au LDAP | validé | manuel | OFFICIAL (4) |
+| YEP 4.2 | Lier l'authentification au SSO | validé | manuel | OFFICIAL (4) |
+| YEP 4.2.1 | Déconnexion | validé | manuel | OFFICIAL (9) |
+| YEP 4.3 | Fournir un script de sauvegarde YunoHost fonctionnel | validé | auto | OFFICIAL (6) |
+| YEP 4.4 | Fournir un script de restauration YunoHost fonctionnel | validé | auto | OFFICIAL (6) |
+| YEP 4.5 | Utiliser les hooks | validé | manuel | OPTIONAL (8) |
+| YEP 4.6 | Gère le multi-instance | validé | manuel | OPTIONAL (2) |
+| YEP 4.7 | Ajouter un module à la CLI | validé | manuel | OPTIONAL |
+| YEP 4.8 | Ajouter un module à l'admin web | brouillon | manuel | OPTIONAL |
+
+
+### YEP 1
+#### Communiquer avec la communauté
+La YEP 1 est une meta YEP, elle explique ce qu'il faut faire pour échanger avec la communauté autour d'un paquet d'application YunoHost.
+
+#### YEP 1.1
+##### Nommer son app et son dépôt | validé | manuel | NOTWORKING |
+Chaque application YunoHost possède un id inscrit dans le manifeste de l'application.
+Cet identifiant doit être unique entre chaque paquet d'application.
+Il est donc recommandé de vérifier sa disponibilité en consultant la liste des applications référencées dans les dépôts d'applications connus (apps, internetcube).
+
+De plus l'identifiant doit respecter l'expression régulière suivante `^[a-z0-9]((_|-)?[a-z0-9])+$`. Autrement dit, il doit respecter les règles suivantes :
+* être en minuscule
+* commencer par une lettre ou un chiffre
+* être alphanumérique (le underscore est autorisé)
+* ne pas contenir deux underscores ou tirets qui se suivent
+* ne pas terminer par un underscore ou un tiret
+
+Pour les noms d'applications contenant des espaces la quasi-totalité des paquets actuels les retirent simplement sans les remplacer par des tirets ou underscores.
+
+Par convention, les dépôts d'applications YunoHost sont toujours nommés de leur ID suivis de la chaîne de caractère "\_ynh". Ainsi on peut distinguer le dépôt upstream de l'application, du dépôt du paquet YunoHost. Cette notation permet également de trouver des applications non répertoriées à travers les moteurs de recherche des plateformes proposant des gestionnaires de version (GitHub par exemple).
+
+Exemple : ID : exemple Nom de dépôt : exemple_ynh
+
+#### YEP 1.2
+##### Inscrire l'app sur un « répertoire » connu | validé | manuel | NOTWORKING |
+Il est conseillé dès le début du packaging d'inscrire une app sur un des dépôts d'application YunoHost.
+
+Ces dépôts ont plusieurs fonctions :
+* communiquer l'existence d'un paquet ;
+* indiquer la dernière version associée au paquet (afin de permettre la mise à jour de l'app par YunoHost) ;
+* indiquer l'état de fonctionnement du paquet ;
+* indiquer des informations sur le support d'un paquet.
+
+Pour la liste `apps.json` maintenue par l'équipe du projet YunoHost, l'inscription se fait sur [le dépôt Git "apps"](https://github.com/YunoHost/apps). D'autres listes non-officielles (notamment celles incluant des applications non-libres) peuvent exister, se réferer au [Forum](https://forum.yunohost.org) de la communauté.
+
+#### YEP 1.3
+##### Indiquer la licence associée au paquet | brouillon | AUTO | WORKING |
+La licence du paquet est à indiquer dans un fichier `LICENSE` à la racine du paquet. Attention à ne pas confondre avec la licence de l'application qui va être installée dont l'acronyme est à renseigner dans le champ `license` du manifeste.
+
+La liste d'application apps.json n'accepte que les paquets dont la licence est libre, de même pour la licence de l'application contenue. Certaines applications libres nécessitent des dépendances non-libres (exemple: MP3, drivers, etc.). Dans ce cas, il faut ajouter `&dep-non-free` à l'acronyme et si possible donner des précisions dans le README.md du paquet, l'intégration sera dans ce cas acceptée au cas par cas.
+
+**NB :** Les applications non-présentes dans la liste maintenue par le projet peuvent tout de même être installées : soit manuellement via le lien de l'application, soit de manière plus intégrée via des listes non-officielles (qui peuvent être créées et maintenues par la communauté).
+
+Dans le futur, YunoHost affichera sans doute des détails sur la licence de l'application. Pour y parvenir, l'acronyme doit être celui issu de cette [liste de licences répertoriées du SPDX](https://spdx.org/licenses/) (si il y a 2 acronymes, il faut prendre celui contenant le numéro de version). Pour plus de cohérence, la casse doit être respectée.
+
+Si la licence n'est pas présente dans la liste, dans ce cas il faut indiquer `free` ou `non-free` selon qu'elle est libre ou non et donner l'occasion à l'utilisateur de se renseigner dans le README.md (lien, explications...).
+
+Exemple : pour une licence `GNU Lesser General Public License (LGPL), version 3` l'acronyme est `LGPL-3.0` si toutefois des dépendances non libres sont utilisées dans ce cas il faudra mettre `LGPL-3.0&dep-non-free` dans le manifeste.
+
+Si une application a des modules liés avec une autre licence (Exemple : Odoo 9 LGPL-3.0 + un module sous licence AGPL-3.0 ), dans ce cas on indiquera les deux licences séparées par un `&`.
+
+Si deux applications distinctes sont dans le même paquet d'installation et ont des licences distinctes, dans ce cas on peut utiliser le `,` pour séparer les licences.
+
+Dans les deux cas, le mainteneur est encouragé à réfléchir à la possibilité de créer deux paquets distincts. Le manifeste de chaque application permet de poser des questions de type `app` de façon à faire référence à une autre application déjà installée.
+
+Rappel : une question de type `app` prend pour réponse l'identifiant d'une des apps déjà installée.
+
+Quelques liens intéressants pour aider au choix de licence :
+* [Des fiches explicatives sur les licences libres](https://www.inria.fr/content/download/5896/48452/version/2/file/INRIA_recueil_fiches_licences_libres_vf.pdf)
+* [La documentation sur les licences du projet GNU](https://www.gnu.org/licenses/licenses.fr.html)
+* [Un guide du projet GNU pour aider au choix d'une licence](https://www.gnu.org/licenses/license-recommendations.fr.html)
+
+#### YEP 1.4
+##### Informer sur l'intention de maintenir un paquet | brouillon | manuel | OFFICIAL |
+Le mainteneur de l'application doit s'engager à maintenir son app sur la durée si il souhaite que celle-ci rejoigne la liste des applications officielles.
+Cela implique de surveiller les mises à jour de l'application upstream, de respecter les nouvelles règles de packaging et de répondre aux demandes des utilisateurs.
+
+#### YEP 1.5
+##### Mettre à jour régulièrement le statut de l'app | brouillon | manuel | WORKING |
+#### YEP 1.6
+##### Se tenir informé sur l'évolution du packaging d'apps | validé | manuel | OFFICIAL |
+Afin de suivre l'évolution du format de packaging ainsi que des bonnes pratiques, il est recommandé de:
+* suivre [la catégorie Apps packaging du forum](https://forum.yunohost.org/c/contribute-room/apps-packaging)
+
+Pour suivre l'évolution de YunoHost de façon plus générale :
+* rejoindre le salon XMPP dev@conference.yunohost.org ([trois jours de logs sont disponibles](https://im.yunohost.org/logs/dev/))
+* suivre [la catégorie Annoucement du forum](https://forum.yunohost.org/c/announcement)
+
+#### YEP 1.7
+##### Ajouter l'app à l'[organisation YunoHost-Apps](https://github.com/YunoHost-Apps) | validé | manuel | OFFICIAL |
+L'ajout d'une app sur l'[organisation YunoHost-Apps](https://github.com/YunoHost-Apps) permet de faire connaitre l'apps auprès des autres contributeurs qui pourraient être tentés de packager l'application visée.
+
+C'est aussi un moyen pour permettre de déployer rapidement un correctif de sécurité si nécessaire dans le cas où le mainteneur ne serait pas disponible.
+
+Procédure de transfert : demander sur le [salon de discussion `Apps`](/chat_rooms) à être invité à l’organisation en lui fournissant le nom de son compte GitHub.
+Une fois l’invitation acceptée, [transférer son dépôt sur l’organisation en suivant ce tutoriel](https://help.github.com/articles/transferring-a-repository-owned-by-your-personal-account/#transferring-a-repository-to-another-user-account-or-to-an-organization).
+
+#### YEP 1.8
+##### Publier des demandes de test | validé | manuel | OFFICIAL |
+Afin d'assurer le bon fonctionnement d'un paquet, il convient de publier une annonce afin d'ouvrir les tests sur le paquet. Cette annonce peut se faire sur le forum dans [la catégorie Apps du forum](https://forum.yunohost.org/c/support/apps).
+
+Il est recommandé d'indiquer si certains tests n'ont pas été menés.
+
+* Vérifier le package avec Package linter.
+* Installation en sous-dossier.
+* Installation à la racine d'un domaine ou d'un sous-domaine.
+* Suppression, dans les 2 cas d'installations précédent.
+* Accès à l'interface web de l'application, avec le / final dans l'adresse, et en l'omettant.
+* Upgrade sur la même version du package.
+* Upgrade depuis une ancienne version du package.
+* Installation privée (sécurisée par le SSO).
+* Installation publique.
+* Installation multi-instance.
+* Erreur de nom d'utilisateur.
+* Erreur de nom de domaine.
+* Path mal écrit (path/ au lieu de /path par exemple).
+* Port déjà utilisé par une autre application.
+* Source corrompue après téléchargement.
+* Erreur de téléchargement de la source.
+* Dossier déjà utilisé par une autre application.
+* Backup et restore.
+
+#### YEP 1.9
+##### Documenter l'app | validé | AUTO | OFFICIAL |
+Avant tout, il convient de faire une description correcte de l'app dans le champ `description` du manifest. L'insertion de mot clé dans cette description peut être une bonne idée, dans la mesure où un utilisateur pourrait être amené à faire une recherche (CTRL+F) parmi toutes les applications.
+
+Il y a également le README.md, ce dernier doit et peut contenir :
+* le nom de l'app
+* un bref résumé de ce qu'elle fait
+* des éventuels compléments d'installation si le script ne suffit pas lui-même
+* des instructions pour l'utiliser (par exemple pour relier son smartphone ou son ordinateur)
+* l'endroit pour signaler un dysfonctionnement / une demande
+* la roadmap/TODO
+* éventuellement les pré-requis en termes de mémoires RAM, processeur etc. (certains équipements ont moins de 512 Mo de RAM)
+
+#### YEP 1.10
+##### Garder un historique de version propre | brouillon | manuel | OFFICIAL |
+#### YEP 1.11
+##### Ajouter l'app au [bugtracker YunoHost](https://github.com/yunohost/issues/issues) | brouillon | manuel | OFFICIAL |
+
+#### YEP 1.12
+##### Suivre le modèle de [example_ynh](https://github.com/YunoHost/example_ynh) | brouillon | manuel | OFFICIAL |
+Afin de faciliter le travail de la communauté concernant un package, il doit suivre le modèle montré par l'application d'exemple.
+Cela aidera les autres packagers à lire, modifier et débugger le paquet. De plus, cela aidera à prolonger la durée de vie du package en lui donnant un modèle standard que les autres packagers seront en mesure de comprendre rapidement au cas où un package deviendrait orphelin.
+De plus, un package ne devrait pas utiliser de code exotique ou inutilement compliqué si ce n'est pas vraiment nécessaire. Le cas échéant, cette partie du code devrait être clairement documentée.
+Gardez votre code aussi simple que possible, gardez tout ce dont un script a besoin directement dedans. Ne déplacez pas les fonctions dans un autre fichier. Restez simple et efficace.
+
+### YEP 2
+#### Stabiliser une app
+#### YEP 2.1
+##### Respecter le format du manifeste | validé | auto | INPROGRESS |
+Le manifeste permet de décrire une app afin que YunoHost puisse lui appliquer les bons traitements. Pour plus d'information voir la [documentation dédiée](/packaging_apps_manifest).
+
+#### YEP 2.2
+##### Utiliser bash pour les scripts principaux | validé | auto | WORKING |
+Les scripts d'action (install, upgrade, remove, backup et restore) doivent être en bash afin que la CLI/API YunoHost puisse correctement les appeler.
+
+Ceci étant, rien n'empêche à l'intérieur de ces scripts de faire appel à d'autres scripts ou bibliothèques de fonction. Ceux-ci ne sont pas obligés d'être en bash.
+
+Cependant, il faudra porter une attention particulière à l'affichage correct des logs d'information, de warning, ou d'erreurs. Afin qu'un utilisateur de la CLI/API YunoHost puisse comprendre le fonctionnement du script venant d'être exécuté et au besoin réparer son instance YunoHost.
+
+#### YEP 2.3
+##### Sauvegarder les réponses lors de l'installation | validé | manuel | WORKING |
+Lors de l'installation, il est nécessaire de sauvegarder chaque réponse aux questions du manifeste. En effet, même si au début il n'est pas nécessaire d'écrire un script de mise à jour, par la suite ce sera sans doute le cas. Or, sans les informations initiales, la mise à jour peut être plus fastidieuse.
+
+#### YEP 2.4
+##### Détecter et gérer les erreurs | brouillon | manuel | WORKING |
+Les scripts install, upgrade, backup et restore doivent détecter les erreurs pour éviter la poursuite des scripts en cas d'erreur bloquante ou d'usage de variable vide.
+L'usage de trap et de `set -eu` est recommandé pour détecter et traiter les erreurs ([Discussion en cours à ce sujet](https://forum.yunohost.org/t/gestion-des-erreurs-set-e-et-ou-trap/2249/5))
+Il est nécessaire également de vérifier le contenu des variables avant les suppressions du script remove. Par exemple un `rm -Rf /var/www/$app` avec `$app` vide aurait un résultat désastreux.
+
+Au début des scripts, avant toutes modifications, il faut vérifier l'existence des utilisateurs mentionné à l'installation, ainsi que la disponibilité du path demandé, la disponibilité du dossier final de l'application et la taille des mots de passe le cas échéant.
+
+ N'oubliez pas qu'en cas d'erreur d'installation le script de suppression sera lancé automatiquement par la CLI YunoHost.
+
+#### YEP 2.5
+##### Copier correctement des fichiers | brouillon | manuel | WORKING |
+#### YEP 2.6
+##### Annuler l'action si les valeurs d'entrées sont incorrectes | validé | manuel | WORKING |
+Chaque script devrait vérifier que les valeurs d'entrées sont correctes.
+
+Voici quelques exemples :
+* Vérifier que le nom de domaine existe
+* Vérifier que l'utilisateur existe
+* Vérifier que le chemin choisi est disponible
+
+Dans le cas où l'une des valeurs est incorrecte, il est alors nécessaire d'annuler toutes modifications réalisées préalablement sur l'instance. Le mieux étant de faire tous ces contrôles avant de modifier le système.
+
+
+#### YEP 2.7
+##### Donner des permissions suffisantes aux instructions bash | validé | auto | WORKING |
+Certaines instructions nécessitent les droits sudo. Il faut dans ce cas ne pas oublier de préfixer ces instructions par `sudo`.
+
+Dans d'autres cas il est nécessaire de donner des droits à l'aide de chmod et de chown.
+
+#### YEP 2.8
+##### Modifier correctement une configuration système | brouillon | manuel | WORKING |
+Les modifications du système doivent être réversible pour que la suppression de l'application soit sans conséquences pour le système, ne laisse pas de résidus.
+Pour celà, il faut recourir autant que possible aux dossiers `.d` des configurations système. Où lorsqu'il n'est pas possible de faire autrement, d'indiquer clairement la configuration modifiée par une application et s'assurer que les modifications seront retirées lors de sa suppression.
+
+#### YEP 2.9
+##### Enlever toutes traces de l'app lors de la suppression | brouillon | manuel | WORKING |
+À l’exception de dépendances (par exemple : paquets Debian) utilisés par d’autres services ou applications.
+
+#### YEP 2.10
+##### Configurer les logs de l'application | brouillon | manuel | WORKING |
+Si possible, l'application doit utiliser un fichier de log, qui sera de préférence dans /var/log.
+Si le log est mis en place par le script install et non par l'application elle-même, un fichier de configuration pour log-rotate devra être ajouté pour gérer les rotations des logs de l'application.
+
+#### YEP 2.11
+##### Utiliser une variable plutôt que l'app id directement | validé | manuel | OFFICIAL |
+Il est conseillé de rendre les scripts le plus générique possible, un bon moyen d'y parvenir est d'utiliser une variable pour le nom de l'app afin d'éviter qu'il se retrouve partout dans les scripts. Ainsi, un autre packageur pourra plus facilement se servir du script pour une autre app.
+
+#### YEP 2.12
+##### Utiliser les commandes pratiques (helpers) | validé | auto | OFFICIAL |
+Afin de simplifier le packaging, d'uniformiser les pratiques, d'éviter les erreurs et d'augmenter la durée de vie d'un script vis-à-vis des futures versions de YunoHost. Un ensemble de helpers permettant de faire de nombreuses actions est proposé.
+
+Pour plus d'informations :
+* consulter [la documentation des helpers](/packaging_apps_helpers)
+* explorer [le répertoire des helpers](https://github.com/YunoHost/yunohost/tree/unstable/data/helpers.d)
+
+#### YEP 2.13
+##### Traduire le paquet en anglais | brouillon | manuel | OFFICIAL |
+#### YEP 2.14
+##### Remplir correctement un fichier de conf | brouillon | manuel | OFFICIAL |
+*Juste pour éclaircir un peu cette YEP, mais ça reste à l'état de brouillon.*
+Le but est de trouver une méthode plus fiable que sed pour modifier les fichiers de configuration. sed pouvant éventuellement avoir des effets de bord en modifiant des parties non désirées du fichier de configuration, en particulier avec l'usage de regex.
+
+#### YEP 2.15
+##### Suivre les instructions d'installation de l'application | validé | manuel | OFFICIAL |
+
+#### YEP 2.16
+##### Vérifier la disponibilité des dépendances sur ARM, x86 et x64 | validé | manuel | OFFICIAL |
+YunoHost s'installe sur ARM, sur x86 et x64. Un paquet devrait donc être testé sur ces trois architectures processeur.
+
+Certains paquets ne sont pas disponibles sur ARM, il convient dans ce cas d'étudier d'autres solutions ou d'indiquer dans le README.md que l'application ne fonctionne pas sur ARM et de bloquer l’installation par détection du type d’architecture.
+
+#### YEP 2.17
+##### Prendre en compte la version d'origine lors des mises à jour | validé | manuel | OFFICIAL |
+Le script de mise à jour doit pouvoir fonctionner même si les mises à jour précédentes n'ont pas été effectuées.
+
+Ainsi, il doit être possible de faire des sauts de mise à jour d'une version N-x vers une version N. Pour ce faire il est conseillé d'enregistrer les numéros de version dans les settings de l'app.
+
+### YEP 2.18
+##### Stabiliser une webapp
+La majeure partie des applications YunoHost sont des web apps, mais certaines n'en sont pas. Les YEP 2.18.x développent certaines spécificités liées aux web app.
+
+#### YEP 2.18.1
+##### Lancer le script d'installation d'une webapp correctement | validé | manuel | WORKING |
+Bien souvent une web app s'installe à partir de formulaires affichés sur une page web. Cette façon de faire, bien que pratique pour un humain, l'est moins pour un programme.
+
+Il convient donc de vérifier si l'application ne propose pas une solution d'installation en ligne de commande.
+
+Si ce n'est pas le cas, il convient d'utiliser l'option -H de curl. En effet, dans certains cas la redirection DNS pourrait ne pas être active au moment de l'installation.
+```bash
+curl -kL -H "Host: $domain" --data "¶m1=Text1¶m2=text2" https://localhost$path/install.php > /dev/null 2>&1
+```
+
+#### YEP 2.18.2
+##### Gérer l'installation à la racine d’un nom de domaine | validé | auto | WORKING |
+Une web app devrait pouvoir s'installer à la racine d’un nom de domaine.
+
+#### YEP 2.18.3
+##### Gérer l'installation sur un sous-domaine | validé | auto | WORKING |
+Une web app devraient pouvoir s'installer sur un sous-domaine directement sans sous dossiers.
+
+#### YEP 2.18.4
+##### Gérer l'installation sur un chemin `/path` | validé | auto | OFFICIAL |
+Une web app devraient pouvoir s'installer sur un chemin `/path`.
+
+#### YEP 2.18.5
+##### Gérer la tuile YunoHost pour naviguer facilement entre les applications | validé | manuel | OFFICIAL |
+Sauf dans de rare cas il est conseillé d'intégrer la tuile YunoHost qui permet de retourner sur le menu du SSO. Cette intégration se fait dans la configuration NGINX.
+
+Certains utilisateurs ont remplacé ce carré par un script ajoutant un menu en haut de chaque webapp.
+
+### YEP 3
+#### Sécuriser une app
+#### YEP 3.1
+##### Ne pas demander ou stocker de mot de passe LDAP | brouillon | manuel | NOTWORKING |
+#### YEP 3.2
+##### Ouvrir un port correctement | brouillon | manuel | WORKING |
+Si l'application nécessite l'ouverture d'un port, il est nécessaire de vérifier préalablement que ce port n'est pas déjà utilisé par une autre application. Le cas échéant, le script install doit être capable de trouver un autre port disponible.
+Il convient également de vérifier si le port doit être ouvert sur le routeur, au delà du réseau local. Si ce n'est pas le cas, l'argument `--no-upnp` doit être ajouté à la commande `yunohost firewall allow` afin de limiter l'ouverture du port au réseau local uniquement.
+
+#### YEP 3.3
+##### Faciliter le contrôle de l'intégrité des sources | brouillon | manuel | OFFICIAL |
+L'application upstream ne doit pas être intégrée en tarball dans le dossier source du package, car cela alourdit le package et le dépôt Git et ne permet pas la vérification de l'intégrité de la source.
+La source doit donc être téléchargée depuis le site officiel, puis son intégritée doit être vérifiée avant de l'installer.
+
+#### YEP 3.4
+##### Isoler l'app | brouillon | manuel | OFFICIAL |
+Afin d'éviter des effets de bords en cas de compromission éventuelle de l'application, celle-ci doit être isolée pour ne pas risquer d'impacter les autres applications.
+Pour cela, il convient d'isoler l'application dans son dossier d'exécution en restreignant son environnement par un chroot, soit par un mécanisme interne à l'application lorsque c'est possible (par exemple pour un serveur FTP), soit par l'usage de PHP-FPM.
+De même, pour restreindre la portée de l'utilisateur exécutant l'application, il est préférable d'utiliser un utilisateur dédiée à l'application. Dont les droits sont restreint à l'usage de l'application uniquement.
+Toutefois, cela ne doit pas exempter d'une restriction maximale des droits sur les fichiers de l'application. Autant que possible, les fichiers doivent appartenir à root, et l'utilisateur dédié ne doit avoir de droits d'écriture que sur les fichiers le réclamant expressément.
+
+#### YEP 3.5
+##### Suivre les recommandations de la documentation de l'app | validé | manuel | OFFICIAL |
+En général, une application propose une documentation afin d'aider les administrateurs systèmes à réaliser l'installation. Il est conseiller d'en suivre les recommandations, notamment celles concernant les permissions à accorder par fichier ou répertoire.
+
+Le mainteneur de paquet doit toutefois rester vigilant, certaines documentations pouvant être erronées ou insuffisantes.
+
+#### YEP 3.6
+##### Mettre à jour les versions contenant des CVE | draft | manuel | OFFICIAL |
+Les [CVE](https://fr.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures), ou Common Vulnerabilities and Exposures, recensent les failles de sécurités communes aux applications. Les corrections de ces failles peuvent concerner l'application et il est important dans ce cas de suivre au plus près ces mises à jour.
+Plus généralement, l'application peut proposer un correctif pour une faille spécifique à elle-même.
+De manière générale, cette YEP implique de suivre un canal d'information pour suivre les mises à jour de sécurité de l'application et réagir rapidement en mettant à jour le package en conséquence.
+
+Comme précisé dans la YEP 1.7, si un correctif de sécurité doit être déployé en urgence, un autre membre de YunoHost peut être amené à faire un commit sur le package si nécessaire.
+
+#### YEP 3.7
+##### Modifier correctement les dépots sources | draft | manuel | OFFICIAL |
+La modification ou l'ajout des dépôts sources dans /etc/apt/sources.list ou /etc/apt/sources.list.d/ ne doit se faire que si c'est absolument nécessaire. Dans un tel cas, merci d'utiliser le pinning, afin de s'assurer que le dépôt n'aura pas une priorité supérieur aux dépôts de debian et YunoHost.
+
+Dans certains cas, il pourra être préférable de télécharger directement le .deb à partir du dépôt source (avec wget par exemple), ceci est à évaluer en fonction des dépendances, de la nature et du rythme des mises à jour.
+
+L'ajout des backports et des dépôts contrib est autorisée. Le paquet doit demander l'autorisation à l'usager avant de procéder à l'ajout de dépôts nonfree, et si possible, permettre l'installation de l'app sans ce dépôt.
+
+Lorsque l'on désigne la distribution on doit toujours faire référence à son nom (jessie) et non pas au statut de celle-ci (stable). Sans quoi, il y a un risque le jour où debian change de version.
+
+Dans tous les cas, une app ne devrait pas modifier les dépôts sources pour les placer sur testing ou une version non supportée par YunoHost (à l'heure où cette yep est rédigé, YunoHost ne supporte pas la nouvelle stable: debian stretch).
+
+### YEP 4
+#### Intégrer une app
+
+Cette meta YEP traite de l'intégration d'une app avec l'environnement YunoHost. Une bonne intégration est en général un gage de qualité et de confort pour les utilisateurs.
+
+#### YEP 4.2
+##### Lier l'authentification au SSO | validé | manuel | OFFICIAL |
+Le Single Sign On permet d'éviter d'avoir à créer les mêmes utilisateurs pour chaque app. Ainsi, un utilisateur YunoHost pourra se connecter via le Single Sign On à l'ensemble des apps.
+
+Pour se faire, il convient de lier son app au LDAP et/ou d'utiliser des hooks pour dupliquer les identifiants du compte dans la base de données de l'app.
+
+Une fois cette opération appliquée, le mainteneur peut utiliser l'instruction HTTP REMOTE_USER pour vérifier si un utilisateur est connecté ou non. En général, des modules existent (que ce soit au niveau de la technologie, du framework ou même de l'app elle-même).
+
+Au besoin, SSOwat permet de sécuriser l'accès à une ou plusieurs parties de l'app. Il peut ainsi être pertinent de sécuriser l'accès à une page d'administration avec le SSO plutôt qu'un `.htaccess` et de rendre le reste de l'app accessible à tous les visiteurs.
+
+#### YEP 4.2.1
+##### Déconnexion | validé | manuel | OFFICIAL |
+Lorsque l'on clique sur une action de déconnexion au sein de l'app, celle-ci devrait déconnecter l'utilisateur du SSO. Sinon, il y a un risque que l'utilisateur laisse par mégarde une session ouverte.
+
+#### YEP 4.3
+##### Fournir un script de sauvegarde YunoHost fonctionnel | validé | auto | OFFICIAL |
+L'application doit disposer d'un script backup pour permettre aux utilisateurs de sauvegarder l'application, sa configuration et ses données.
+
+#### YEP 4.4
+##### Fournir un script de restauration YunoHost fonctionnel | validé | auto | OFFICIAL |
+L'application doit disposer d'un script restore pour permettre aux utilisateurs de restaurer une application sauvegardée préalablement avec le script backup.
+
+#### YEP 4.5
+##### Utiliser les hooks | validé | manuel | OPTIONAL |
+YunoHost offre la possibilité de lancer des actions à chaque traitement effectué par la ligne de commande. Ceci peut être pratique dans de nombreux cas.
+
+Exemples :
+* Ajouter/supprimer un utilisateur dans la base de données de l'app lorsque l'on utilise `yunohost user create` ou `yunohost user remove`
+* Gérer l’ajout d'un nouveau nom de domaine lors de l'action `yunohost domain add`
+* Lancer un script après que le pare-feu ait été rechargé
+
+Liste des hooks :
+* post_domain_add
+* post_domain_remove
+* post_user_create
+* post_user_delete
+* post_backup_create
+* post_backup_restore
+* pre_backup_delete
+* post_backup_delete
+* post_app_addaccess
+* post_app_removeaccess
+* post_app_clearaccess
+* post_app_addaccess
+* post_iptable_rules
+
+Ces scripts sont à placer dans un répertoire `hooks` comme dans ce paquet : https://github.com/YunoHost-Apps/owncloud_ynh/tree/master/hooks .
+
+
+#### YEP 4.6
+##### Gèrer le multi-instance | validé | manuel | OPTIONAL |
+Il est parfois pratique de pouvoir installer plusieurs fois une même app. Par exemple, pour plusieurs noms de domaine différents.
+
+Il faut toutefois faire attention à la façon de gérer les chemins de fichier, les dépendances, les ports utilisés etc. de sorte qu'il n'y ait pas de collision.
+
+#### YEP 4.7
+##### Ajouter un module à la CLI | validé | manuel | OPTIONAL |
+Il est possible de créer un module afin d'ajouter des commandes à la ligne de commandes yunohost.
+
+Pour ce faire, il faut ajouter un actionmaps dans `/usr/share/moulinette/actionsmap/`. Cet actionmaps doit commencer par `ynh_`.
+
+Les paquets [menu_ynh](https://github.com/YunoHost-Apps/menu_ynh/) et [subscribe_ynh](https://github.com/YunoHost-Apps/subscribe_ynh/) bien qu’anciens (et non à jour) peuvent servir de base pour mettre en place ce genre de module.
+#### YEP 4.8
+##### Ajouter un module à l'admin web | brouillon | manuel | OPTIONAL |
diff --git a/packaging_apps_helpers.md b/packaging_apps_helpers.md
new file mode 100644
index 00000000..1cf5d699
--- /dev/null
+++ b/packaging_apps_helpers.md
@@ -0,0 +1,5572 @@
+
+
+App helpers
+
+Doc auto-generated by this script on 02/03/2021 (Yunohost version 4.1.7.1)
+
+
+
+apt
+
+
+
+
+
+
+
ynh_package_is_installed
+ Check either a package is installed or not
+
+
+
+
+
+ Usage: ynh_package_is_installed --package=name
+
+
+
+
+ Arguments:
+
+
+
+ -p
, --package=
: the package name to check
+
+
+
+
+
+
+
+
+ Example: ynh_package_is_installed --package=yunohost && echo "ok"
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_package_version
+ Get the version of an installed package
+
+
+
+
+
+ Usage: ynh_package_version --package=name
+
+
+
+
+ Arguments:
+
+
+
+ -p
, --package=
: the package name to get version
+
+
+
+
+
+
+
+ Returns: the version or an empty string
+
+
+
+
+ Example: version=$(ynh_package_version --package=yunohost)
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_package_update
+ Update package index files
+
+
+
+
+
+ Usage: ynh_package_update
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_package_install
+ Install package(s)
+
+
+
+
+
+ Usage: ynh_package_install name [name [...]]
+
+
+
+
+ Arguments:
+
+
+
+ name
: the package name to install
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_package_remove
+ Remove package(s)
+
+
+
+
+
+ Usage: ynh_package_remove name [name [...]]
+
+
+
+
+ Arguments:
+
+
+
+ name
: the package name to remove
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_package_autoremove
+ Remove package(s) and their uneeded dependencies
+
+
+
+
+
+ Usage: ynh_package_autoremove name [name [...]]
+
+
+
+
+ Arguments:
+
+
+
+ name
: the package name to remove
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_package_autopurge
+ Purge package(s) and their uneeded dependencies
+
+
+
+
+
+ Usage: ynh_package_autopurge name [name [...]]
+
+
+
+
+ Arguments:
+
+
+
+ name
: the package name to autoremove and purge
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.7.2 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_install_app_dependencies
+ Define and install dependencies with a equivs control file
+
+
+
+
+
+ Usage: ynh_install_app_dependencies dep [dep [...]]
+
+
+
+
+ Arguments:
+
+
+
+ dep
: the package name to install in dependence. Writing "dep3|dep4|dep5" can be used to specify alternatives. For example : dep1 dep2 "dep3|dep4|dep5" will require to install dep1 and dep 2 and (dep3 or dep4 or dep5).
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ This helper can/should only be called once per appexample : ynh_install_app_dependencies dep1 dep2 "dep3|dep4|dep5"Requires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_add_app_dependencies
+ Add dependencies to install with ynh_install_app_dependencies
+
+
+
+
+
+ Usage: ynh_add_app_dependencies --package=phpversion [--replace]
+
+
+
+
+ Arguments:
+
+
+
+ -p
, --package=
: Packages to add as dependencies for the app.
+
+
+
+ -r
, --replace
: Replace dependencies instead of adding to existing ones.
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.8.1 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_remove_app_dependencies
+ Remove fake package and its dependencies
+
+
+
+
+
+ Usage: ynh_remove_app_dependencies
+
+
+
+
+
+
+
+
+ Details:
+
+ Dependencies will removed only if no other package need them.Requires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_install_extra_app_dependencies
+ Install packages from an extra repository properly.
+
+
+
+
+
+
+
+
+
+backup
+
+
+
+
+
+
+
ynh_backup
+ Add a file or a directory to the list of paths to backup
+
+
+
+
+
+ Usage: ynh_backup --src_path=src_path [--dest_path=dest_path] [--is_big] [--not_mandatory]
+
+
+
+
+ Arguments:
+
+
+
+ -s
, --src_path=
: file or directory to bind or symlink or copy. it shouldn't be in the backup dir.
+
+
+
+ -d
, --dest_path=
: destination file or directory inside the backup dir
+
+
+
+ -b
, --is_big
: Indicate data are big (mail, video, image ...)
+
+
+
+ -m
, --not_mandatory
: Indicate that if the file is missing, the backup can ignore it.
+
+
+
+ arg
: Deprecated arg
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ This helper can be used both in a system backup hook, and in an app backup scriptDetails: ynh_backup writes SRC and the relative DEST into a CSV file. And itcreates the parent destination directoryIf DEST is ended by a slash it complete this path with the basename of SRC.Example in the context of a wordpress appynh_backup "/etc/nginx/conf.d/$domain.d/$app.conf"# => This line will be added into CSV file# "/etc/nginx/conf.d/$domain.d/$app.conf","apps/wordpress/etc/nginx/conf.d/$domain.d/$app.conf"ynh_backup "/etc/nginx/conf.d/$domain.d/$app.conf" "conf/nginx.conf"# => "/etc/nginx/conf.d/$domain.d/$app.conf","apps/wordpress/conf/nginx.conf"ynh_backup "/etc/nginx/conf.d/$domain.d/$app.conf" "conf/"# => "/etc/nginx/conf.d/$domain.d/$app.conf","apps/wordpress/conf/$app.conf"ynh_backup "/etc/nginx/conf.d/$domain.d/$app.conf" "conf"# => "/etc/nginx/conf.d/$domain.d/$app.conf","apps/wordpress/conf"#Deprecated usages (maintained for retro-compatibility)ynh_backup "/etc/nginx/conf.d/$domain.d/$app.conf" "${backup_dir}/conf/nginx.conf"# => "/etc/nginx/conf.d/$domain.d/$app.conf","apps/wordpress/conf/nginx.conf"ynh_backup "/etc/nginx/conf.d/$domain.d/$app.conf" "/conf/"# => "/etc/nginx/conf.d/$domain.d/$app.conf","apps/wordpress/conf/$app.conf"How to use --is_big:--is_big is used to specify that this part of the backup can be quite huge.So, you don't want that your package does backup that part during ynh_backup_before_upgrade.In the same way, an user may doesn't want to backup this big part of the app for each of his backup. And so handle that part differently.As this part of your backup may not be done, your restore script has to handle it.In your restore script, use --not_mandatory with ynh_restore_fileAs well in your remove script, you should not remove those data ! Or an user may end up with a failed upgrade restoring an app without data anymore !To have the benefit of --is_big while doing a backup, you can whether set the environement variable BACKUP_CORE_ONLY to 1 (BACKUP_CORE_ONLY=1) before the backup command. It will affect only that backup command.Or set the config do_not_backup_data to 1 into the settings.yml of the app. This will affect all backups for this app until the setting is removed.Requires YunoHost version 2.4.0 or higher.Requires YunoHost version 3.5.0 or higher for the argument --not_mandatory
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_restore
+ Restore all files that were previously backuped in a core backup script or app backup script
+
+
+
+
+
+ Usage: ynh_restore
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_restore_file
+ Restore a file or a directory
+
+
+
+
+
+ Usage: ynh_restore_file --origin_path=origin_path [--dest_path=dest_path] [--not_mandatory]
+
+
+
+
+ Arguments:
+
+
+
+ -o
, --origin_path=
: Path where was located the file or the directory before to be backuped or relative path to $YNH_CWD where it is located in the backup archive
+
+
+
+ -d
, --dest_path=
: Path where restore the file or the dir, if unspecified, the destination will be ORIGIN_PATH or if the ORIGIN_PATH doesn't exist in the archive, the destination will be searched into backup.csv
+
+
+
+ -m
, --not_mandatory
: Indicate that if the file is missing, the restore process can ignore it.
+
+
+
+
+
+
+
+
+
+ Examples:
+
+
+ ynh_restore_file "/etc/nginx/conf.d/$domain.d/$app.conf"
+
+
+
+
+ You can also use relative paths:
+
+
+
+
+ ynh_restore_file "conf/nginx.conf"
+
+
+
+
+
+
+
+
+ Details:
+
+ Use the registered path in backup_list by ynh_backup to restore the file atthe right place.If DEST_PATH already exists and is lighter than 500 Mo, a backup will be made in/home/yunohost.conf/backup/. Otherwise, the existing file is removed.if apps/wordpress/etc/nginx/conf.d/$domain.d/$app.conf exists, restore it into/etc/nginx/conf.d/$domain.d/$app.confif no, search for a match in the csv (eg: conf/nginx.conf) and restore it into/etc/nginx/conf.d/$domain.d/$app.confRequires YunoHost version 2.6.4 or higher.Requires YunoHost version 3.5.0 or higher for the argument --not_mandatory
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_store_file_checksum
+ Calculate and store a file checksum into the app settings
+
+
+
+
+
+ Usage: ynh_store_file_checksum --file=file
+
+
+
+
+ Arguments:
+
+
+
+ -f
, --file=
: The file on which the checksum will performed, then stored.
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ $app should be defined when calling this helperRequires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_backup_if_checksum_is_different
+ Verify the checksum and backup the file if it's different
+
+
+
+
+
+ Usage: ynh_backup_if_checksum_is_different --file=file
+
+
+
+
+ Arguments:
+
+
+
+ -f
, --file=
: The file on which the checksum test will be perfomed.
+
+
+
+
+
+
+
+ Returns: the name of a backup file, or nothing
+
+
+
+
+
+
+ Details:
+
+ This helper is primarily meant to allow to easily backup personalised/manuallymodified config files.Requires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_delete_file_checksum
+ Delete a file checksum from the app settings
+
+
+
+
+
+ Usage: ynh_delete_file_checksum --file=file
+
+
+
+
+ Arguments:
+
+
+
+ -f
, --file=
: The file for which the checksum will be deleted
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ $app should be defined when calling this helperRequires YunoHost version 3.3.1 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_backup_before_upgrade
+ Make a backup in case of failed upgrade
+
+
+
+
+
+ Usage: ynh_backup_before_upgrade
+ ynh_clean_setup () {
+ ynh_restore_upgradebackup
+ }
+ ynh_abort_if_errors
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.7.2 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_restore_upgradebackup
+ Restore a previous backup if the upgrade process failed
+
+
+
+
+
+ Usage: ynh_backup_before_upgrade
+ ynh_clean_setup () {
+ ynh_restore_upgradebackup
+ }
+ ynh_abort_if_errors
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.7.2 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+fail2ban
+
+
+
+
+
+
+
ynh_add_fail2ban_config
+ Create a dedicated fail2ban config (jail and filter conf files)
+
+
+
+
+
+ Usage: 1: ynh_add_fail2ban_config --logpath=log_file --failregex=filter [--max_retry=max_retry] [--ports=ports]
+2: ynh_add_fail2ban_config --use_template [--others_var="list of others variables to replace"]
+| for example : 'var_1 var_2 ...'
+
+
+
+
+ Arguments:
+
+
+
+ -l
, --logpath=
: Log file to be checked by fail2ban
+
+
+
+ -r
, --failregex=
: Failregex to be looked for by fail2ban
+
+
+
+ -m
, --max_retry=
: Maximum number of retries allowed before banning IP address - default: 3
+
+
+
+ -p
, --ports=
: Ports blocked for a banned IP address - default: http,https
+
+
+
+ -t
, --use_template
: Use this helper in template mode
+
+
+
+ -v
, --others_var=
: List of others variables to replace separeted by a space
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ -----------------------------------------------------------------------------This will use a template in ../conf/f2b_jail.conf and ../conf/f2b_filter.conf __APP__ by $appYou can dynamically replace others variables by example : __VAR_1__ by $var_1 __VAR_2__ by $var_2Generally your template will look like that by example (for synapse):f2b_jail.conf: [__APP__] enabled = true port = http,https filter = __APP__ logpath = /var/log/__APP__/logfile.log maxretry = 3f2b_filter.conf: [INCLUDES] before = common.conf [Definition]# Part of regex definition (just used to make more easy to make the global regex) __synapse_start_line = .? \- synapse\..+ \-# Regex definition. failregex = ^%(__synapse_start_line)s INFO \- POST\-(\d+)\- \- \d+ \- Received request\: POST /_matrix/client/r0/login\??%(__synapse_start_line)s INFO \- POST\-\1\- Got login request with identifier: \{u'type': u'm.id.user', u'user'\: u'(.+?)'\}, medium\: None, address: None, user\: u'\5'%(__synapse_start_line)s WARNING \- \- (Attempted to login as @\5\:.+ but they do not exist|Failed password login for user @\5\:.+)$ignoreregex =-----------------------------------------------------------------------------Note about the "failregex" option: regex to match the password failure messages in the logfile. The host must be matched by a group named "host". The tag "" can be used for standard IP/hostname matching and is only an alias for (?:::f{4,6}:)?(?P[\w\-.^_]+)You can find some more explainations about how to make a regex here : https://www.fail2ban.org/wiki/index.php/MANUAL_0_8#FiltersNote that the logfile need to exist before to call this helper !!To validate your regex you can test with this command:fail2ban-regex /var/log/YOUR_LOG_FILE_PATH /etc/fail2ban/filter.d/YOUR_APP.confRequires YunoHost version 3.5.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_remove_fail2ban_config
+ Remove the dedicated fail2ban config (jail and filter conf files)
+
+
+
+
+
+ Usage: ynh_remove_fail2ban_config
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.5.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+getopts
+
+
+
+
+hardware
+
+
+
+
+
+
+
ynh_get_ram
+ Get the total or free amount of RAM+swap on the system
+
+
+
+
+
+ Usage: ynh_get_ram [--free|--total] [--ignore_swap|--only_swap]
+
+
+
+
+ Arguments:
+
+
+
+ -f
, --free
: Count free RAM+swap
+
+
+
+ -t
, --total
: Count total RAM+swap
+
+
+
+ -s
, --ignore_swap
: Ignore swap, consider only real RAM
+
+
+
+ -o
, --only_swap
: Ignore real RAM, consider only swap
+
+
+
+
+
+
+
+ Returns: the amount of free ram
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.8.1 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_require_ram
+ Return 0 or 1 depending if the system has a given amount of RAM+swap free or total
+
+
+
+
+
+ Usage: ynh_require_ram --required=RAM required in Mb [--free|--total] [--ignore_swap|--only_swap]
+| exit: Return 1 if the ram is under the requirement, 0 otherwise.
+
+
+
+
+ Arguments:
+
+
+
+ -r
, --required=
: The amount to require, in Mb
+
+
+
+ -f
, --free
: Count free RAM+swap
+
+
+
+ -t
, --total
: Count total RAM+swap
+
+
+
+ -s
, --ignore_swap
: Ignore swap, consider only real RAM
+
+
+
+ -o
, --only_swap
: Ignore real RAM, consider only swap
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.8.1 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+logging
+
+
+
+
+
+
+
ynh_die
+ Print a message to stderr and exit
+
+
+
+
+
+ Usage: ynh_die --message=MSG [--ret_code=RETCODE]
+
+
+
+
+ Arguments:
+
+
+
+ -m
, --message=
: Message to display
+
+
+
+ -c
, --ret_code=
: Exit code to exit with
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.4.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_print_info
+ Display a message in the 'INFO' logging category
+
+
+
+
+
+ Usage: ynh_print_info --message="Some message"
+
+
+
+
+ Arguments:
+
+
+
+ -m
, --message=
: Message to display
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.2.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_print_warn
+ Print a warning on stderr
+
+
+
+
+
+ Usage: ynh_print_warn --message="Text to print"
+
+
+
+
+ Arguments:
+
+
+
+ -m
, --message=
: The text to print
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.2.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_print_err
+ Print an error on stderr
+
+
+
+
+
+ Usage: ynh_print_err --message="Text to print"
+
+
+
+
+ Arguments:
+
+
+
+ -m
, --message=
: The text to print
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.2.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_exec_err
+ Execute a command and print the result as an error
+
+
+
+
+
+ Usage: ynh_exec_err your_command
+ynh_exec_err "your_command | other_command"
+
+
+
+
+ Arguments:
+
+
+
+ command
: command to execute
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ When using pipes, double quotes are required - otherwise, this helper will run the first command, and the whole output will be sent through the next pipe.If the command to execute uses double quotes, they have to be escaped or they will be interpreted and removed.Requires YunoHost version 3.2.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_exec_warn
+ Execute a command and print the result as a warning
+
+
+
+
+
+ Usage: ynh_exec_warn your_command
+ynh_exec_warn "your_command | other_command"
+
+
+
+
+ Arguments:
+
+
+
+ command
: command to execute
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ When using pipes, double quotes are required - otherwise, this helper will run the first command, and the whole output will be sent through the next pipe.If the command to execute uses double quotes, they have to be escaped or they will be interpreted and removed.Requires YunoHost version 3.2.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_exec_warn_less
+ Execute a command and force the result to be printed on stdout
+
+
+
+
+
+ Usage: ynh_exec_warn_less your_command
+ynh_exec_warn_less "your_command | other_command"
+
+
+
+
+ Arguments:
+
+
+
+ command
: command to execute
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ When using pipes, double quotes are required - otherwise, this helper will run the first command, and the whole output will be sent through the next pipe.If the command to execute uses double quotes, they have to be escaped or they will be interpreted and removed.Requires YunoHost version 3.2.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_exec_quiet
+ Execute a command and redirect stdout in /dev/null
+
+
+
+
+
+ Usage: ynh_exec_quiet your_command
+ynh_exec_quiet "your_command | other_command"
+
+
+
+
+ Arguments:
+
+
+
+ command
: command to execute
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ When using pipes, double quotes are required - otherwise, this helper will run the first command, and the whole output will be sent through the next pipe.If the command to execute uses double quotes, they have to be escaped or they will be interpreted and removed.Requires YunoHost version 3.2.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_exec_fully_quiet
+ Execute a command and redirect stdout and stderr in /dev/null
+
+
+
+
+
+ Usage: ynh_exec_fully_quiet your_command
+ynh_exec_fully_quiet "your_command | other_command"
+
+
+
+
+ Arguments:
+
+
+
+ command
: command to execute
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ When using pipes, double quotes are required - otherwise, this helper will run the first command, and the whole output will be sent through the next pipe.If the command to execute uses double quotes, they have to be escaped or they will be interpreted and removed.Requires YunoHost version 3.2.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_print_OFF
+ Remove any logs for all the following commands.
+
+
+
+
+
+ Usage: ynh_print_OFF
+
+
+
+
+
+
+
+
+ Details:
+
+ WARNING: You should be careful with this helper, and never forget to use ynh_print_ON as soon as possible to restore the logging.Requires YunoHost version 3.2.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_print_ON
+ Restore the logging after ynh_print_OFF
+
+
+
+
+
+ Usage: ynh_print_ON
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.2.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_script_progression
+ Print a progress bar showing the progression of an app script
+
+
+
+
+
+ Usage: ynh_script_progression --message=message [--weight=weight] [--time]
+
+
+
+
+ Arguments:
+
+
+
+ -m
, --message=
: The text to print
+
+
+
+ -w
, --weight=
: The weight for this progression. This value is 1 by default. Use a bigger value for a longer part of the script.
+
+
+
+ -t
, --time
: Print the execution time since the last call to this helper. Especially usefull to define weights. The execution time is given for the duration since the previous call. So the weight should be applied to this previous call.
+
+
+
+ -l
, --last
: Use for the last call of the helper, to fill the progression bar.
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.5.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_return
+ Return data to the Yunohost core for later processing
+(to be used by special hooks like app config panel and core diagnosis)
+
+
+
+
+
+ Usage: ynh_return somedata
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.6.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_debug
+ Debugger for app packagers
+
+
+
+
+
+ Usage: ynh_debug [--message=message] [--trace=1/0]
+
+
+
+
+ Arguments:
+
+
+
+ -m
, --message=
: The text to print
+
+
+
+ -t
, --trace=
: Turn on or off the trace of the script. Usefull to trace nonly a small part of a script.
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.5.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_debug_exec
+ Execute a command and print the result as debug
+
+
+
+
+
+ Usage: ynh_debug_exec your_command
+ynh_debug_exec "your_command | other_command"
+
+
+
+
+ Arguments:
+
+
+
+ command
: command to execute
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ When using pipes, double quotes are required - otherwise, this helper will run the first command, and the whole output will be sent through the next pipe.If the command to execute uses double quotes, they have to be escaped or they will be interpreted and removed.Requires YunoHost version 3.5.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+logrotate
+
+
+
+
+
+
+
ynh_use_logrotate
+ Use logrotate to manage the logfile
+
+
+
+
+
+ Usage: ynh_use_logrotate [--logfile=/log/file] [--nonappend] [--specific_user=user/group]
+
+
+
+
+ Arguments:
+
+
+
+ -l
, --logfile=
: absolute path of logfile
+
+
+
+ -n
, --nonappend
: (optional) Replace the config file instead of appending this new config.
+
+
+
+ -u
, --specific_user=
: run logrotate as the specified user and group. If not specified logrotate is runned as root.
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ If no --logfile is provided, /var/log/${app} will be used as default.logfile can be just a directory, or a full path to a logfile :/parentdir/logdir/parentdir/logdir/logfile.logIt's possible to use this helper multiple times, each config will be added tothe same logrotate config file. Unless you use the option --non-appendRequires YunoHost version 2.6.4 or higher.Requires YunoHost version 3.2.0 or higher for the argument --specific_user
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_remove_logrotate
+ Remove the app's logrotate config.
+
+
+
+
+
+ Usage: ynh_remove_logrotate
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+mysql
+
+
+
+
+
+
+
ynh_mysql_connect_as
+ Open a connection as a user
+
+
+
+
+
+ Usage: ynh_mysql_connect_as --user=user --password=password [--database=database]
+
+
+
+
+ Arguments:
+
+
+
+ -u
, --user=
: the user name to connect as
+
+
+
+ -p
, --password=
: the user password
+
+
+
+ -d
, --database=
: the database to connect to
+
+
+
+
+
+
+
+
+ Example: ynh_mysql_connect_as --user="user" --password="pass" <<< "UPDATE ...;" example: ynh_mysql_connect_as --user="user" --password="pass" < /path/to/file.sql
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_mysql_execute_as_root
+ Execute a command as root user
+
+
+
+
+
+ Usage: ynh_mysql_execute_as_root --sql=sql [--database=database]
+
+
+
+
+ Arguments:
+
+
+
+ -s
, --sql=
: the SQL command to execute
+
+
+
+ -d
, --database=
: the database to connect to
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_mysql_execute_file_as_root
+ Execute a command from a file as root user
+
+
+
+
+
+ Usage: ynh_mysql_execute_file_as_root --file=file [--database=database]
+
+
+
+
+ Arguments:
+
+
+
+ -f
, --file=
: the file containing SQL commands
+
+
+
+ -d
, --database=
: the database to connect to
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_mysql_dump_db
+ Dump a database
+
+
+
+
+
+ Usage: ynh_mysql_dump_db --database=database
+
+
+
+
+ Arguments:
+
+
+
+ -d
, --database=
: the database name to dump
+
+
+
+
+
+
+
+ Returns: the mysqldump output
+
+
+
+
+ Example: ynh_mysql_dump_db --database=roundcube > ./dump.sql
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_mysql_user_exists
+ Check if a mysql user exists
+
+
+
+
+
+ Usage: ynh_mysql_user_exists --user=user
+| exit: Return 1 if the user doesn't exist, 0 otherwise.
+
+
+
+
+ Arguments:
+
+
+
+ -u
, --user=
: the user for which to check existence
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_mysql_setup_db
+ Create a database, an user and its password. Then store the password in the app's config
+
+
+
+
+
+ Usage: ynh_mysql_setup_db --db_user=user --db_name=name [--db_pwd=pwd]
+
+
+
+
+ Arguments:
+
+
+
+ -u
, --db_user=
: Owner of the database
+
+
+
+ -n
, --db_name=
: Name of the database
+
+
+
+ -p
, --db_pwd=
: Password of the database. If not provided, a password will be generated
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ After executing this helper, the password of the created database will be available in $db_pwdIt will also be stored as "mysqlpwd" into the app settings.Requires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_mysql_remove_db
+ Remove a database if it exists, and the associated user
+
+
+
+
+
+ Usage: ynh_mysql_remove_db --db_user=user --db_name=name
+
+
+
+
+ Arguments:
+
+
+
+ -u
, --db_user=
: Owner of the database
+
+
+
+ -n
, --db_name=
: Name of the database
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+network
+
+
+
+
+
+
+
ynh_find_port
+ Find a free port and return it
+
+
+
+
+
+ Usage: ynh_find_port --port=begin_port
+
+
+
+
+ Arguments:
+
+
+
+ -p
, --port=
: port to start to search
+
+
+
+
+
+
+
+ Returns: the port number
+
+
+
+
+ Example: port=$(ynh_find_port --port=8080)
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_port_available
+ Test if a port is available
+
+
+
+
+
+ Usage: ynh_find_port --port=XYZ
+| exit: Return 1 if the port is already used by another process.
+
+
+
+
+ Arguments:
+
+
+
+ -p
, --port=
: port to check
+
+
+
+
+
+
+
+
+ Example: ynh_port_available --port=1234 || ynh_die "Port 1234 is needs to be available for this app"
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.8.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_validate_ip4
+ Validate an IPv4 address
+
+
+
+
+
+ Usage: ynh_validate_ip4 --ip_address=ip_address
+
+
+
+
+ Arguments:
+
+
+
+ -i
, --ip_address=
: the ipv4 address to check
+
+
+
+
+
+
+
+ Returns: 0 for valid ipv4 addresses, 1 otherwise
+
+
+
+
+ Example: ynh_validate_ip4 111.222.333.444
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_validate_ip6
+ Validate an IPv6 address
+
+
+
+
+
+ Usage: ynh_validate_ip6 --ip_address=ip_address
+
+
+
+
+ Arguments:
+
+
+
+ -i
, --ip_address=
: the ipv6 address to check
+
+
+
+
+
+
+
+ Returns: 0 for valid ipv6 addresses, 1 otherwise
+
+
+
+
+ Example: ynh_validate_ip6 2000:dead:beef::1
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+nginx
+
+
+
+
+
+
+
ynh_add_nginx_config
+ Create a dedicated nginx config
+
+
+
+
+
+ Usage: ynh_add_nginx_config "list of others variables to replace"
+
+
+
+
+ Arguments:
+
+
+
+ list
: (Optional) list of others variables to replace separated by spaces. For example : 'path_2 port_2 ...'
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ This will use a template in ../conf/nginx.conf __PATH__ by $path_url __DOMAIN__ by $domain __PORT__ by $port __NAME__ by $app __FINALPATH__ by $final_path __PHPVERSION__ by $YNH_PHP_VERSION ($YNH_PHP_VERSION is either the default php version or the version defined for the app)And dynamic variables (from the last example) : __PATH_2__ by $path_2 __PORT_2__ by $port_2Requires YunoHost version 2.7.2 or higher.Requires YunoHost version 2.7.13 or higher for dynamic variables
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_remove_nginx_config
+ Remove the dedicated nginx config
+
+
+
+
+
+ Usage: ynh_remove_nginx_config
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.7.2 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+nodejs
+
+
+
+
+
+
+
ynh_use_nodejs
+ Load the version of node for an app, and set variables.
+
+
+
+
+
+ Usage: ynh_use_nodejs
+
+
+
+
+
+
+
+
+ Details:
+
+ ynh_use_nodejs has to be used in any app scripts before using node for the first time.This helper will provide alias and variables to use in your scripts.To use npm or node, use the alias `ynh_npm` and `ynh_node`Those alias will use the correct version installed for the appFor example: use `ynh_npm install` instead of `npm install`With `sudo` or `ynh_exec_as`, use instead the fallback variables `$ynh_npm` and `$ynh_node`And propagate $PATH to sudo with $ynh_node_load_PATHExemple: `ynh_exec_as $app $ynh_node_load_PATH $ynh_npm install`$PATH contains the path of the requested version of node.However, $PATH is duplicated into $node_PATH to outlast any manipulation of $PATHYou can use the variable `$ynh_node_load_PATH` to quickly load your node version in $PATH for an usage into a separate script.Exemple: $ynh_node_load_PATH $final_path/script_that_use_npm.sh`Finally, to start a nodejs service with the correct version, 2 solutions Either the app is dependent of node or npm, but does not called it directly. In such situation, you need to load PATH `Environment="__NODE_ENV_PATH__"` `ExecStart=__FINALPATH__/my_app` You will replace __NODE_ENV_PATH__ with $ynh_node_load_PATHOr node start the app directly, then you don't need to load the PATH variable `ExecStart=__YNH_NODE__ my_app run` You will replace __YNH_NODE__ with $ynh_node2 other variables are also available - $nodejs_path: The absolute path to node binaries for the chosen version. - $nodejs_version: Just the version number of node for this app. Stored as 'nodejs_version' in settings.yml.Requires YunoHost version 2.7.12 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_install_nodejs
+ Install a specific version of nodejs
+
+
+
+
+
+ Usage: ynh_install_nodejs --nodejs_version=nodejs_version
+
+
+
+
+ Arguments:
+
+
+
+ -n
, --nodejs_version=
: Version of node to install. When possible, your should prefer to use major version number (e.g. 8 instead of 8.10.0). The crontab will then handle the update of minor versions when needed.
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ ynh_install_nodejs will install the version of node provided as argument by using n.n (Node version management) uses the PATH variable to store the path of the version of node it is going to use.That's how it changes the versionRefer to ynh_use_nodejs for more information about available commands and variablesRequires YunoHost version 2.7.12 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_remove_nodejs
+ Remove the version of node used by the app.
+
+
+
+
+
+ Usage: ynh_remove_nodejs
+
+
+
+
+
+
+
+
+ Details:
+
+ This helper will check if another app uses the same version of node,if not, this version of node will be removed.If no other app uses node, n will be also removed.Requires YunoHost version 2.7.12 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+permission
+
+
+
+
+
+
+
ynh_permission_create
+ Create a new permission for the app
+
+
+
+
+
+ Usage: ynh_permission_create --permission="permission" [--url="url"] [--additional_urls="second-url" [ "third-url" ]] [--auth_header=true|false]
+ [--allowed=group1 [ group2 ]] [--label="label"] [--show_tile=true|false]
+ [--protected=true|false]
+| Not that if 'show_tile' is enabled, this URL will be the URL of the tile.
+| Default is "APP_LABEL (permission name)".
+| Default is false (for the permission different than 'main').
+| won't be able to add or remove the visitors group of this permission.
+| By default it's 'false'
+
+
+
+
+ Arguments:
+
+
+
+ -p,
: - the name for the permission (by default a permission named "main" already exist)
+
+
+
+ -u,
: - (optional) URL for which access will be allowed/forbidden.
+
+
+
+ -A,
: - (optional) List of additional URL for which access will be allowed/forbidden
+
+
+
+ -h,
: - (optional) Define for the URL of this permission, if SSOwat pass the authentication header to the application. Default is true
+
+
+
+ -a,
: - (optional) A list of group/user to allow for the permission
+
+
+
+ -l,
: - (optional) Define a name for the permission. This label will be shown on the SSO and in the admin.
+
+
+
+ -t,
: - (optional) Define if a tile will be shown in the SSO. If yes the name of the tile will be the 'label' parameter.
+
+
+
+ -P,
: - (optional) Define if this permission is protected. If it is protected the administrator
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ example 1: ynh_permission_create --permission=admin --url=/admin --additional_urls=domain.tld/admin /superadmin --allowed=alice bob \ --label="My app admin" --show_tile=trueThis example will create a new permission permission with this following effect:- A tile named "My app admin" in the SSO will be available for the users alice and bob. This tile will point to the relative url '/admin'.- Only the user alice and bob will have the access to theses following url: /admin, domain.tld/admin, /superadminexample 2: ynh_permission_create --permission=api --url=domain.tld/api --auth_header=false --allowed=visitors \ --label="MyApp API" --protected=trueThis example will create a new protected permission. So the admin won't be able to add/remove the visitors group of this permission.In case of an API with need to be always public it avoid that the admin break anything.With this permission all client will be allowed to access to the url 'domain.tld/api'.Note that in this case no tile will be show on the SSO.Note that the auth_header parameter is to 'false'. So no authentication header will be passed to the application.Generally the API is requested by an application and enabling the auth_header has no advantage and could bring some issues in some case.So in this case it's better to disable this option for all API.If provided, 'url' or 'additional_urls' is assumed to be relative to the app domain/path if theystart with '/'. For example: / -> domain.tld/app /admin -> domain.tld/app/admin domain.tld/app/api -> domain.tld/app/api'url' or 'additional_urls' can be treated as a PCRE (not lua) regex if it starts with "re:".For example: re:/api/[A-Z]*$ -> domain.tld/app/api/[A-Z]*$ re:domain.tld/app/api/[A-Z]*$ -> domain.tld/app/api/[A-Z]*$Note that globally the parameter 'url' and 'additional_urls' are same. The only difference is:- 'url' is only one url, 'additional_urls' can be a list of urls. There are no limitation of 'additional_urls'- 'url' is used for the url of tile in the SSO (if enabled with the 'show_tile' parameter)About the authentication header (auth_header parameter).The SSO pass (by default) to the application theses following HTTP header (linked to the authenticated user) to the application: - "Auth-User": username - "Remote-User": username - "Email": user emailGenerally this feature is usefull to authenticate automatically the user in the application but in some case the application don't work with theses header and theses header need to be disabled to have the application to work correctly.See https://github.com/YunoHost/issues/issues/1420 for more informationsRequires YunoHost version 3.7.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_permission_delete
+ Remove a permission for the app (note that when the app is removed all permission is automatically removed)
+
+
+
+
+
+ Usage: ynh_permission_delete --permission="permission"
+
+
+
+
+ Arguments:
+
+
+
+ -p
, --permission=
: the name for the permission (by default a permission named "main" is removed automatically when the app is removed)
+
+
+
+
+
+
+
+
+ Example: ynh_permission_delete --permission=editors
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.7.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_permission_exists
+ Check if a permission exists
+
+
+
+
+
+ Usage: ynh_permission_exists --permission=permission
+| exit: Return 1 if the permission doesn't exist, 0 otherwise
+
+
+
+
+ Arguments:
+
+
+
+ -p
, --permission=
: the permission to check
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.7.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_permission_url
+ Redefine the url associated to a permission
+
+
+
+
+
+ Usage: ynh_permission_url --permission "permission" [--url="url"] [--add_url="new-url" [ "other-new-url" ]] [--remove_url="old-url" [ "other-old-url" ]]
+ [--auth_header=true|false] [--clear_urls]
+| Note that if you want to remove url you can pass an empty sting as arguments ("").
+
+
+
+
+ Arguments:
+
+
+
+ -p,
: - the name for the permission (by default a permission named "main" is removed automatically when the app is removed)
+
+
+
+ -u,
: - (optional) URL for which access will be allowed/forbidden.
+
+
+
+ -a,
: - (optional) List of additional url to add for which access will be allowed/forbidden.
+
+
+
+ -r,
: - (optional) List of additional url to remove for which access will be allowed/forbidden
+
+
+
+ -h,
: - (optional) Define for the URL of this permission, if SSOwat pass the authentication header to the application
+
+
+
+ -c,
: - (optional) Clean all urls (url and additional_urls)
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.7.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_permission_update
+ Update a permission for the app
+
+
+
+
+
+ Usage: ynh_permission_update --permission "permission" [--add="group" ["group" ...]] [--remove="group" ["group" ...]]
+ [--label="label"] [--show_tile=true|false] [--protected=true|false]
+| won't be able to add or remove the visitors group of this permission.
+
+
+
+
+ Arguments:
+
+
+
+ -p,
: - the name for the permission (by default a permission named "main" already exist)
+
+
+
+ -a,
: - the list of group or users to enable add to the permission
+
+
+
+ -r,
: - the list of group or users to remove from the permission
+
+
+
+ -l,
: - (optional) Define a name for the permission. This label will be shown on the SSO and in the admin.
+
+
+
+ -t,
: - (optional) Define if a tile will be shown in the SSO
+
+
+
+ -P,
: - (optional) Define if this permission is protected. If it is protected the administrator
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.7.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_permission_has_user
+ Check if a permission has an user
+
+
+
+
+
+ Usage: ynh_permission_has_user --permission=permission --user=user
+| exit: Return 1 if the permission doesn't have that user or doesn't exist, 0 otherwise
+
+
+
+
+ Arguments:
+
+
+
+ -p
, --permission=
: the permission to check
+
+
+
+ -u
, --user=
: the user seek in the permission
+
+
+
+
+
+
+
+
+ Example: ynh_permission_has_user --permission=main --user=visitors
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.7.1 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_legacy_permissions_exists
+ Check if a legacy permissions exist
+
+
+
+
+
+ Usage: ynh_legacy_permissions_exists
+| exit: Return 1 if the permission doesn't exist, 0 otherwise
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 4.1.2 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_legacy_permissions_delete_all
+ Remove all legacy permissions
+
+
+
+
+
+ Usage: ynh_legacy_permissions_delete_all
+
+
+
+
+
+
+ Example: if ynh_legacy_permissions_exists then ynh_legacy_permissions_delete_all # You can recreate the required permissions here with ynh_permission_create fi Requires YunoHost version 4.1.2 or higher.
+
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+php
+
+
+
+
+
+
+
ynh_add_fpm_config
+ Create a dedicated PHP-FPM config
+
+
+
+
+
+ Usage: 1: ynh_add_fpm_config [--phpversion=7.X] [--use_template] [--package=packages] [--dedicated_service]
+2: ynh_add_fpm_config [--phpversion=7.X] --usage=usage --footprint=footprint [--package=packages] [--dedicated_service]
+low - Less than 20 MB of RAM by pool.
+medium - Between 20 MB and 40 MB of RAM by pool.
+high - More than 40 MB of RAM by pool.
+Or specify exactly the footprint, the load of the service as MB by pool instead of having a standard value.
+To have this value, use the following command and stress the service.
+watch -n0.5 ps -o user,cmd,%cpu,rss -u APP
+
+
+
+
+ Arguments:
+
+
+
+ -v
, --phpversion=
: Version of PHP to use.
+
+
+
+ -t
, --use_template
: Use this helper in template mode.
+
+
+
+ -p
, --package=
: Additionnal PHP packages to install
+
+
+
+ -d
, --dedicated_service
: Use a dedicated PHP-FPM service instead of the common one.
+
+
+
+ -v
, --phpversion=
: Version of PHP to use.
+
+
+
+ -f
, --footprint=
: Memory footprint of the service (low/medium/high).
+
+
+
+ -u
, --usage=
: Expected usage of the service (low/medium/high).
+
+
+
+ -p
, --package=
: Additionnal PHP packages to install for a specific version of PHP
+
+
+
+ -d
, --dedicated_service
: Use a dedicated PHP-FPM service instead of the common one.
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ -----------------------------------------------------------------------------The footprint of the service will be used to defined the maximum footprint we can allow, which is half the maximum RAM.So it will be used to defined 'pm.max_children'A lower value for the footprint will allow more children for 'pm.max_children'. And so for 'pm.start_servers', 'pm.min_spare_servers' and 'pm.max_spare_servers' which are defined from the value of 'pm.max_children'NOTE: 'pm.max_children' can't exceed 4 times the number of processor's cores.The usage value will defined the way php will handle the children for the pool.A value set as 'low' will set the process manager to 'ondemand'. Children will start only if the service is used, otherwise no child will stay alive. This config gives the lower footprint when the service is idle. But will use more proc since it has to start a child as soon it's used.Set as 'medium', the process manager will be at dynamic. If the service is idle, a number of children equal to pm.min_spare_servers will stay alive. So the service can be quick to answer to any request. The number of children can grow if needed. The footprint can stay low if the service is idle, but not null. The impact on the proc is a little bit less than 'ondemand' as there's always a few children already available.Set as 'high', the process manager will be set at 'static'. There will be always as many children as 'pm.max_children', the footprint is important (but will be set as maximum a quarter of the maximum RAM) but the impact on the proc is lower. The service will be quick to answer as there's always many children ready to answer.Requires YunoHost version 2.7.2 or higher.Requires YunoHost version 3.5.1 or higher for the argument --phpversionRequires YunoHost version 3.8.1 or higher for the arguments --use_template, --usage, --footprint, --package and --dedicated_service
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_remove_fpm_config
+ Remove the dedicated PHP-FPM config
+
+
+
+
+
+ Usage: ynh_remove_fpm_config
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.7.2 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+postgresql
+
+
+
+
+
+
+
ynh_psql_connect_as
+ Open a connection as a user
+
+
+
+
+
+ Usage: ynh_psql_connect_as --user=user --password=password [--database=database]
+
+
+
+
+ Arguments:
+
+
+
+ -u
, --user=
: the user name to connect as
+
+
+
+ -p
, --password=
: the user password
+
+
+
+ -d
, --database=
: the database to connect to
+
+
+
+
+
+
+
+
+
+ Examples:
+
+
+ ynh_psql_connect_as 'user' 'pass' <<< "UPDATE ...;"
+
+
+
+
+ ynh_psql_connect_as 'user' 'pass' < /path/to/file.sql
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.5.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_psql_execute_as_root
+ Execute a command as root user
+
+
+
+
+
+ Usage: ynh_psql_execute_as_root --sql=sql [--database=database]
+
+
+
+
+ Arguments:
+
+
+
+ -s
, --sql=
: the SQL command to execute
+
+
+
+ -d
, --database=
: the database to connect to
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.5.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_psql_execute_file_as_root
+ Execute a command from a file as root user
+
+
+
+
+
+ Usage: ynh_psql_execute_file_as_root --file=file [--database=database]
+
+
+
+
+ Arguments:
+
+
+
+ -f
, --file=
: the file containing SQL commands
+
+
+
+ -d
, --database=
: the database to connect to
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.5.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_psql_dump_db
+ Dump a database
+
+
+
+
+
+ Usage: ynh_psql_dump_db --database=database
+
+
+
+
+ Arguments:
+
+
+
+ -d
, --database=
: the database name to dump
+
+
+
+
+
+
+
+ Returns: the psqldump output
+
+
+
+
+ Example: ynh_psql_dump_db 'roundcube' > ./dump.sql
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.5.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_psql_user_exists
+ Check if a psql user exists
+
+
+
+
+
+ Usage: ynh_psql_user_exists --user=user
+| exit: Return 1 if the user doesn't exist, 0 otherwise
+
+
+
+
+ Arguments:
+
+
+
+ -u
, --user=
: the user for which to check existence
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.5.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_psql_database_exists
+ Check if a psql database exists
+
+
+
+
+
+ Usage: ynh_psql_database_exists --database=database
+| exit: Return 1 if the database doesn't exist, 0 otherwise
+
+
+
+
+ Arguments:
+
+
+
+ -d
, --database=
: the database for which to check existence
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.5.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_psql_setup_db
+ Create a database, an user and its password. Then store the password in the app's config
+
+
+
+
+
+ Usage: ynh_psql_setup_db --db_user=user --db_name=name [--db_pwd=pwd]
+
+
+
+
+ Arguments:
+
+
+
+ -u
, --db_user=
: Owner of the database
+
+
+
+ -n
, --db_name=
: Name of the database
+
+
+
+ -p
, --db_pwd=
: Password of the database. If not provided, a password will be generated
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ After executing this helper, the password of the created database will be available in $db_pwdIt will also be stored as "psqlpwd" into the app settings.Requires YunoHost version 2.7.13 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_psql_remove_db
+ Remove a database if it exists, and the associated user
+
+
+
+
+
+ Usage: ynh_psql_remove_db --db_user=user --db_name=name
+
+
+
+
+ Arguments:
+
+
+
+ -u
, --db_user=
: Owner of the database
+
+
+
+ -n
, --db_name=
: Name of the database
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.7.13 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_psql_test_if_first_run
+ Create a master password and set up global settings
+It also make sure that postgresql is installed and running
+Please always call this script in install and restore scripts
+
+
+
+
+
+ Usage: ynh_psql_test_if_first_run
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.7.13 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+setting
+
+
+
+
+
+
+
ynh_app_setting_get
+ Get an application setting
+
+
+
+
+
+ Usage: ynh_app_setting_get --app=app --key=key
+
+
+
+
+ Arguments:
+
+
+
+ -a
, --app=
: the application id
+
+
+
+ -k
, --key=
: the setting to get
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_app_setting_set
+ Set an application setting
+
+
+
+
+
+ Usage: ynh_app_setting_set --app=app --key=key --value=value
+
+
+
+
+ Arguments:
+
+
+
+ -a
, --app=
: the application id
+
+
+
+ -k
, --key=
: the setting name to set
+
+
+
+ -v
, --value=
: the setting value to set
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_app_setting_delete
+ Delete an application setting
+
+
+
+
+
+ Usage: ynh_app_setting_delete --app=app --key=key
+
+
+
+
+ Arguments:
+
+
+
+ -a
, --app=
: the application id
+
+
+
+ -k
, --key=
: the setting to delete
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_webpath_available
+ Check availability of a web path
+
+
+
+
+
+ Usage: ynh_webpath_available --domain=domain --path_url=path
+
+
+
+
+ Arguments:
+
+
+
+ -d
, --domain=
: the domain/host of the url
+
+
+
+ -p
, --path_url=
: the web path to check the availability of
+
+
+
+
+
+
+
+
+ Example: ynh_webpath_available --domain=some.domain.tld --path_url=/coffee
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_webpath_register
+ Register/book a web path for an app
+
+
+
+
+
+ Usage: ynh_webpath_register --app=app --domain=domain --path_url=path
+
+
+
+
+ Arguments:
+
+
+
+ -a
, --app=
: the app for which the domain should be registered
+
+
+
+ -d
, --domain=
: the domain/host of the web path
+
+
+
+ -p
, --path_url=
: the web path to be registered
+
+
+
+
+
+
+
+
+ Example: ynh_webpath_register --app=wordpress --domain=some.domain.tld --path_url=/coffee
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+string
+
+
+
+
+
+
+
ynh_string_random
+ Generate a random string
+
+
+
+
+
+ Usage: ynh_string_random [--length=string_length]
+
+
+
+
+ Arguments:
+
+
+
+ -l
, --length=
: the string length to generate (default: 24)
+
+
+
+
+
+
+
+ Returns: the generated string
+
+
+
+
+ Example: pwd=$(ynh_string_random --length=8)
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_replace_string
+ Substitute/replace a string (or expression) by another in a file
+
+
+
+
+
+ Usage: ynh_replace_string --match_string=match_string --replace_string=replace_string --target_file=target_file
+
+
+
+
+ Arguments:
+
+
+
+ -m
, --match_string=
: String to be searched and replaced in the file
+
+
+
+ -r
, --replace_string=
: String that will replace matches
+
+
+
+ -f
, --target_file=
: File in which the string will be replaced.
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ As this helper is based on sed command, regular expressions andreferences to sub-expressions can be used(see sed manual page for more information)Requires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_replace_special_string
+ Substitute/replace a special string by another in a file
+
+
+
+
+
+ Usage: ynh_replace_special_string --match_string=match_string --replace_string=replace_string --target_file=target_file
+
+
+
+
+ Arguments:
+
+
+
+ -m
, --match_string=
: String to be searched and replaced in the file
+
+
+
+ -r
, --replace_string=
: String that will replace matches
+
+
+
+ -t
, --target_file=
: File in which the string will be replaced.
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ This helper will use ynh_replace_string, but as you can use specialcharacters, you can't use some regular expressions and sub-expressions.Requires YunoHost version 2.7.7 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_sanitize_dbid
+ Sanitize a string intended to be the name of a database
+(More specifically : replace - and . by _)
+
+
+
+
+
+ Usage: ynh_sanitize_dbid --db_name=name
+
+
+
+
+ Arguments:
+
+
+
+ -n
, --db_name=
: name to correct/sanitize
+
+
+
+
+
+
+
+ Returns: the corrected name
+
+
+
+
+ Example: dbname=$(ynh_sanitize_dbid $app)
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+systemd
+
+
+
+
+
+
+
ynh_add_systemd_config
+ Create a dedicated systemd config
+
+
+
+
+
+ Usage: ynh_add_systemd_config [--service=service] [--template=template]
+ynh_add_systemd_config [--service=service] [--template=template] [--others_var="list of others variables to replace"]
+
+
+
+
+ Arguments:
+
+
+
+ -s
, --service=
: Service name (optionnal, $app by default)
+
+
+
+ -t
, --template=
: Name of template file (optionnal, this is 'systemd' by default, meaning ./conf/systemd.service will be used as template)
+
+
+
+ -v
, --others_var=
: List of others variables to replace separated by a space. For example: 'var_1 var_2 ...'
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ This will use the template ../conf/.serviceto generate a systemd config, by replacing the following keywordswith global variables that should be defined before callingthis helper :__APP__ by $app __FINALPATH__ by $final_pathAnd dynamic variables (from the last example) : __VAR_1__ by $var_1 __VAR_2__ by $var_2Requires YunoHost version 2.7.11 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_remove_systemd_config
+ Remove the dedicated systemd config
+
+
+
+
+
+ Usage: ynh_remove_systemd_config [--service=service]
+
+
+
+
+ Arguments:
+
+
+
+ -s
, --service=
: Service name (optionnal, $app by default)
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.7.2 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_systemd_action
+ Start (or other actions) a service, print a log in case of failure and optionnaly wait until the service is completely started
+
+
+
+
+
+ Usage: ynh_systemd_action [--service_name=service_name] [--action=action] [ [--line_match="line to match"] [--log_path=log_path] [--timeout=300] [--length=20] ]
+
+
+
+
+ Arguments:
+
+
+
+ -n
, --service_name=
: Name of the service to start. Default : $app
+
+
+
+ -a
, --action=
: Action to perform with systemctl. Default: start
+
+
+
+ -l
, --line_match=
: Line to match - The line to find in the log to attest the service have finished to boot. If not defined it don't wait until the service is completely started. WARNING: When using --line_match, you should always add `ynh_clean_check_starting` into your `ynh_clean_setup` at the beginning of the script. Otherwise, tail will not stop in case of failure of the script. The script will then hang forever.
+
+
+
+ -p
, --log_path=
: Log file - Path to the log file. Default : /var/log/$app/$app.log
+
+
+
+ -t
, --timeout=
: Timeout - The maximum time to wait before ending the watching. Default : 300 seconds.
+
+
+
+ -e
, --length=
: Length of the error log : Default : 20
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.5.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_clean_check_starting
+ Clean temporary process and file used by ynh_check_starting
+(usually used in ynh_clean_setup scripts)
+
+
+
+
+
+ Usage: ynh_clean_check_starting
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.5.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+user
+
+
+
+
+
+
+
ynh_user_exists
+ Check if a YunoHost user exists
+
+
+
+
+
+ Usage: ynh_user_exists --username=username
+| exit: Return 1 if the user doesn't exist, 0 otherwise
+
+
+
+
+ Arguments:
+
+
+
+ -u
, --username=
: the username to check
+
+
+
+
+
+
+
+
+ Example: ynh_user_exists 'toto' || exit 1
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_user_get_info
+ Retrieve a YunoHost user information
+
+
+
+
+
+ Usage: ynh_user_get_info --username=username --key=key
+
+
+
+
+ Arguments:
+
+
+
+ -u
, --username=
: the username to retrieve info from
+
+
+
+ -k
, --key=
: the key to retrieve
+
+
+
+
+
+
+
+ Returns: string - the key's value
+
+
+
+
+ Example: mail=$(ynh_user_get_info 'toto' 'mail')
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_user_list
+ Get the list of YunoHost users
+
+
+
+
+
+ Usage: ynh_user_list
+
+
+
+
+
+ Returns: string - one username per line
+
+
+
+
+ Example: for u in $(ynh_user_list); do ...
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.4.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_system_user_exists
+ Check if a user exists on the system
+
+
+
+
+
+ Usage: ynh_system_user_exists --username=username
+| exit: Return 1 if the user doesn't exist, 0 otherwise
+
+
+
+
+ Arguments:
+
+
+
+ -u
, --username=
: the username to check
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.2.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_system_group_exists
+ Check if a group exists on the system
+
+
+
+
+
+ Usage: ynh_system_group_exists --group=group
+| exit: Return 1 if the group doesn't exist, 0 otherwise
+
+
+
+
+ Arguments:
+
+
+
+ -g
, --group=
: the group to check
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.5.0.2 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_system_user_create
+ Create a system user
+
+
+
+
+
+ Usage: ynh_system_user_create --username=user_name [--home_dir=home_dir] [--use_shell]
+
+
+
+
+ Arguments:
+
+
+
+ -u
, --username=
: Name of the system user that will be create
+
+
+
+ -h
, --home_dir=
: Path of the home dir for the user. Usually the final path of the app. If this argument is omitted, the user will be created without home
+
+
+
+ -s
, --use_shell
: Create a user using the default login shell if present. If this argument is omitted, the user will be created with /usr/sbin/nologin shell
+
+
+
+
+
+
+
+
+
+ Examples:
+
+
+ Create a nextcloud user with no home directory and /usr/sbin/nologin login shell (hence no login capability)
+
+
+
+
+ ynh_system_user_create --username=nextcloud
+
+
+
+
+ Create a discourse user using /var/www/discourse as home directory and the default login shell
+
+
+
+
+ ynh_system_user_create --username=discourse --home_dir=/var/www/discourse --use_shell
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_system_user_delete
+ Delete a system user
+
+
+
+
+
+ Usage: ynh_system_user_delete --username=user_name
+
+
+
+
+ Arguments:
+
+
+
+ -u
, --username=
: Name of the system user that will be create
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_exec_as
+ Execute a command as another user
+
+
+
+
+
+ Usage: ynh_exec_as $USER COMMAND [ARG ...]
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 4.1.7 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+utils
+
+
+
+
+
+
+
ynh_abort_if_errors
+ Exits if an error occurs during the execution of the script.
+
+
+
+
+
+ Usage: ynh_abort_if_errors
+
+
+
+
+
+
+
+
+ Details:
+
+ This configure the rest of the script execution such that, if an error occursor if an empty variable is used, the execution of the script stopsimmediately and a call to `ynh_clean_setup` is triggered if it has beendefined by your script.Requires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_setup_source
+ Download, check integrity, uncompress and patch the source from app.src
+
+
+
+
+
+ Usage: ynh_setup_source --dest_dir=dest_dir [--source_id=source_id]
+
+
+
+
+ Arguments:
+
+
+
+ -d
, --dest_dir=
: Directory where to setup sources
+
+
+
+ -s
, --source_id=
: Name of the app, if the package contains more than one app
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ The file conf/app.src need to contains:SOURCE_URL=Address to download the app archiveSOURCE_SUM=Control sum# (Optional) Program to check the integrity (sha256sum, md5sum...)# default: sha256SOURCE_SUM_PRG=sha256# (Optional) Archive format# default: tar.gzSOURCE_FORMAT=tar.gz# (Optional) Put false if sources are directly in the archive root# default: true# Instead of true, SOURCE_IN_SUBDIR could be the number of sub directories# to remove.SOURCE_IN_SUBDIR=false# (Optionnal) Name of the local archive (offline setup support)# default: ${src_id}.${src_format}SOURCE_FILENAME=example.tar.gz# (Optional) If it set as false don't extract the source.# (Useful to get a debian package or a python wheel.)# default: trueSOURCE_EXTRACT=(true|false)Details:This helper downloads sources from SOURCE_URL if there is no local sourcearchive in /opt/yunohost-apps-src/APP_ID/SOURCE_FILENAMENext, it checks the integrity with "SOURCE_SUM_PRG -c --status" command.If it's ok, the source archive will be uncompressed in $dest_dir. If theSOURCE_IN_SUBDIR is true, the first level directory of the archive will beremoved.If SOURCE_IN_SUBDIR is a numeric value, 2 for example, the 2 first leveldirectories will be removedFinally, patches named sources/patches/${src_id}-*.patch and extra files insources/extra_files/$src_id will be applied to dest_dirRequires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_local_curl
+ Curl abstraction to help with POST requests to local pages (such as installation forms)
+
+
+
+
+
+ Usage: ynh_local_curl "page_uri" "key1=value1" "key2=value2" ...
+
+
+
+
+ Arguments:
+
+
+
+ page_uri
: Path (relative to $path_url) of the page where POST data will be sent
+
+
+
+ key1=value1
: (Optionnal) POST key and corresponding value
+
+
+
+ key2=value2
: (Optionnal) Another POST key and corresponding value
+
+
+
+ ...
: (Optionnal) More POST keys and values
+
+
+
+
+
+
+
+
+ Example: ynh_local_curl "/install.php?installButton" "foo=$var1" "bar=$var2"
+
+
+
+
+
+ Details:
+
+ For multiple calls, cookies are persisted between each call for the same app$domain and $path_url should be defined externally (and correspond to the domain.tld and the /path (of the app?))Requires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_add_config
+ Create a dedicated config file from a template
+
+
+
+
+
+ Usage: ynh_add_config --template="template" --destination="destination"
+
+
+
+
+ Arguments:
+
+
+
+ -t
, --template=
: Template config file to use
+
+
+
+ -d
, --destination=
: Destination of the config file
+
+
+
+
+
+
+
+
+
+ Examples:
+
+
+ ynh_add_config --template=".env" --destination="$final_path/.env"
+
+
+
+
+ ynh_add_config --template="../conf/.env" --destination="$final_path/.env"
+
+
+
+
+ ynh_add_config --template="/etc/nginx/sites-available/default" --destination="etc/nginx/sites-available/mydomain.conf"
+
+
+
+
+
+
+
+
+ Details:
+
+ The template can be by default the name of a file in the conf directoryof a YunoHost Package, a relative path or an absolute pathThe helper will use the template $template to generate a config file$destination by replacing the following keywords with global variablesthat should be defined before calling this helper : __PATH__ by $path_url __NAME__ by $app __NAMETOCHANGE__ by $app __USER__ by $app __FINALPATH__ by $final_path __PHPVERSION__ by $YNH_PHP_VERSION __YNH_NODE_LOAD_PATH__ by $ynh_node_load_PATHAnd any dynamic variables that should be defined before calling this helper like: __DOMAIN__ by $domain __APP__ by $app __VAR_1__ by $var_1 __VAR_2__ by $var_2The helper will verify the checksum and backup the destination fileif it's different before applying the new template.And it will calculate and store the destination file checksuminto the app settings when configuration is done.Requires YunoHost version 4.1.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_get_debian_release
+ Fetch the Debian release codename
+
+
+
+
+
+ Usage: ynh_get_debian_release
+
+
+
+
+
+ Returns: The Debian release codename (i.e. jessie, stretch, ...)
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.7.12 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_secure_remove
+ Remove a file or a directory securely
+
+
+
+
+
+ Usage: ynh_secure_remove --file=path_to_remove
+
+
+
+
+ Arguments:
+
+
+
+ -f
, --file=
: File or directory to remove
+
+
+
+
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 2.6.4 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_read_manifest
+ Read the value of a key in a ynh manifest file
+
+
+
+
+
+ Usage: ynh_read_manifest --manifest="manifest.json" --key="key"
+
+
+
+
+ Arguments:
+
+
+
+ -m
, --manifest=
: Path of the manifest to read
+
+
+
+ -k
, --key=
: Name of the key to find
+
+
+
+
+
+
+
+ Returns: the value associate to that key
+
+
+
+
+
+
+ Details:
+
+ Requires YunoHost version 3.5.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_app_upstream_version
+ Read the upstream version from the manifest, or from the env variable $YNH_APP_MANIFEST_VERSION if not given
+
+
+
+
+
+ Usage: ynh_app_upstream_version [--manifest="manifest.json"]
+
+
+
+
+ Arguments:
+
+
+
+ -m
, --manifest=
: Path of the manifest to read
+
+
+
+
+
+
+
+ Returns: the version number of the upstream app
+
+
+
+
+
+
+ Details:
+
+ The version number in the manifest is defined by ~ynhFor example : 4.3-2~ynh3This include the number before ~ynhIn the last example it return 4.3-2Requires YunoHost version 3.5.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_app_package_version
+ Read package version from the manifest
+
+
+
+
+
+ Usage: ynh_app_package_version [--manifest="manifest.json"]
+
+
+
+
+ Arguments:
+
+
+
+ -m
, --manifest=
: Path of the manifest to read
+
+
+
+
+
+
+
+ Returns: the version number of the package
+
+
+
+
+
+
+ Details:
+
+ The version number in the manifest is defined by ~ynhFor example : 4.3-2~ynh3This include the number after ~ynhIn the last example it return 3Requires YunoHost version 3.5.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_check_app_version_changed
+ Checks the app version to upgrade with the existing app version and returns:
+
+
+
+
+
+ Usage: ynh_check_app_version_changed
+
+
+
+
+
+
+
+
+ Details:
+
+ - UPGRADE_PACKAGE if only the YunoHost package has changed- UPGRADE_APP otherwiseThis helper should be used to avoid an upgrade of an app, or the upstream partof it, when it's not neededTo force an upgrade, even if the package is up to date,you have to use the parameter --force (or -F).example: sudo yunohost app upgrade MyApp --forceRequires YunoHost version 3.5.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
+
+
ynh_compare_current_package_version
+ Compare the current package version against another version given as an argument.
+This is really useful when we need to do some actions only for some old package versions.
+
+
+
+
+
+ Usage: ynh_compare_current_package_version --comparison lt|le|eq|ne|ge|gt
+| eq (equal), ne (not equal), ge (greater or equal), gt (greater than)
+
+
+
+
+ Arguments:
+
+
+
+ --comparison
: Comparison type. Could be : lt (lower than), le (lower or equal),
+
+
+
+ --version
: The version to compare. Need to be a version in the yunohost package version type (like 2.3.1~ynh4)
+
+
+
+
+
+
+
+
+ Example: ynh_compare_current_package_version --comparison lt --version 2.3.2~ynh1 This example will check if the installed version is lower than (lt) the version 2.3.2~ynh1
+
+
+
+
+
+ Details:
+
+ Generally you might probably use it as follow in the upgrade scriptif ynh_compare_current_package_version --comparison lt --version 2.3.2~ynh1then # Do something that is needed for the package version older than 2.3.2~ynh1fiReturn 0 if the evaluation is true. 1 if false.Requires YunoHost version 3.8.0 or higher.
+
+
+
+
+ Dude, show me the code !
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/packaging_apps_hooks.md b/packaging_apps_hooks.md
new file mode 100644
index 00000000..247301d2
--- /dev/null
+++ b/packaging_apps_hooks.md
@@ -0,0 +1,191 @@
+# The use of YunoHost hooks
+
+Hooks allow you to trigger a script when an action is performed by the system.
+The most obvious case is adding a user. If the app has a `post_user_create` hook, this hook will be triggered as soon as a user is added.
+Therefore, this allows an application to execute actions based on events occurring on the system.
+
+### List of available hooks
+
+- `post_domain_add`
+After adding a domain.
+- `post_domain_remove`
+After deleting a domain.
+- `post_user_create`
+After adding a user.
+- `post_user_delete`
+After deleting a user.
+- `post_iptable_rules`
+After reloading the firewall.
+- `pre_backup_delete`
+Before deleting a backup.
+- `post_backup_delete`
+After deleting a backup.
+- `post_app_addaccess`
+After adding an authorized user to an application.
+- `post_app_removeaccess`
+After the removal of a user's authorization on an application.
+- `post_app_clearaccess`
+After erasing all the access rules on an application.
+- `post_app_install`
+After installing an application.
+- `post_app_upgrade`
+After upgrading an application.
+- `post_app_remove`
+After removing an application.
+- `post_app_change_url`
+After modifying the path and/or the domain name of an application.
+- `post_cert_update`
+After updating a certificate
+- `conf_regen`
+Before and after the regeneration of a service configuration.
+Services supported by `regen-conf`:
+ - avahi-daemon
+ - dnsmasq
+ - dovecot
+ - fail2ban
+ - glances
+ - metronome
+ - mysql
+ - nginx
+ - nslcd
+ - nsswitch
+ - postfix
+ - rspamd
+ - slapd
+ - ssh
+ - ssl
+
+### Hooks setup
+
+With the exception of the `conf_regen` hook, all hooks are used in the same way.
+First of all, you have to understand that a hook is a simple bash script that will be executed by YunoHost when the indicated event occurs.
+To add a hook to YunoHost, you must use a "hooks" folder at the root of the application package. Then, put your script in this folder under the name of the corresponding hook.
+
+> For example:
+For the hook `post_user_create`, the script which will have to be executed for this hook should be placed in `hooks/post_user_create` in the app package.
+
+During the installation and the upgrade of the application, the scripts in the hooks folder will be duplicated in the folder `/etc/yunohost/hooks.d/` in the folder corresponding to the hook, then under the name `50-$app`.
+All hooks belonging to an application will be removed when the apllication is deleted.
+
+### Building a hook script
+
+As a bash script, a hook script must start with the bash shebang.
+
+```bash
+#!/bin/bash
+```
+
+Then you have to take the arguments given by YunoHost when calling the script.
+Each hook offers different arguments.
+
+##### `post_domain_add` and `post_domain_remove`
+
+```bash
+domain=$1
+```
+
+##### `post_user_create`
+
+```bash
+username=$1
+mail=$2
+password=$3 # Clear password
+firstname=$4
+lastname=$5
+```
+##### `post_user_delete`
+
+```bash
+username=$1
+purge=$2 # True/False Indicates whether the user folder has been deleted or not.
+```
+
+##### `post_iptable_rules`
+
+```bash
+upnp=$1 # True/False Indicates if UPnP is activated or not.
+ipv6=$2 # True/False Indicates whether IPV6 is enabled or not.
+```
+
+##### `pre_backup_delete` and `post_backup_delete`
+
+```bash
+backup_name=$1
+```
+
+##### `post_app_install`, `post_app_upgrade`, `post_app_remove` and `post_app_change_url`
+
+Usable variables in these scripts are the same as those available in [associated actions scripts](/packaging_apps_scripts).
+
+Example: for `post_app_install` the variables are the same as for the script `install`
+
+##### `post_app_addaccess` and `post_app_removeaccess`
+
+```bash
+app_id=$1
+users=$2 # All authorized users on the app. Separated by commas.
+```
+
+##### `post_app_clearaccess`
+
+```bash
+app_id=$1
+```
+
+##### `post_cert_update`
+```bash
+domain=$1
+```
+
+The rest of the script depends on what you want to do in it.
+
+### `conf_regen` special case
+The `conf_regen` hook is a more delicate hook, either for its implementation or for its content.
+
+##### `conf_regen` hook setup
+
+A `conf_regen` hook should not be placed in the application's hooks folder. It must be set up manually.
+The hook should be copied, indicating to which service it is linked.
+```bash
+cp hook_regen_conf /usr/share/yunohost/hooks/conf_regen/50-SERVICE_$app
+```
+
+> When removing the application, this hook must be removed manually.
+
+##### Building `conf_regen` hook script
+
+`conf_regen` hook is called two times, a first time after analysis of the configuration and before any modification of the files, then a second time after applying the modifications, if there has been modifications.
+
+`conf_regen` hook script should look like this:
+
+```bash
+#!/bin/bash
+
+force=${2:-0} # 0/1 --force argument
+dryrun=${3:-0} # 0/1 --dry-run argument
+pending_conf=$4 # Path of the pending conf file
+
+do_pre_regen() {
+ # Put your code here for pre regen conf.
+}
+
+do_post_regen() {
+ # Put your code here for post regen conf.
+ # Be careful, this part will be executed only if the configuration has been modified.
+}
+
+case "$1" in
+ pre)
+ do_pre_regen
+ ;;
+ post)
+ do_post_regen
+ ;;
+ *)
+ echo "Hook called with unknown argument \`$1'" >&2
+ exit 1
+ ;;
+esac
+
+exit 0
+```
diff --git a/packaging_apps_hooks_fr.md b/packaging_apps_hooks_fr.md
new file mode 100644
index 00000000..6339cc69
--- /dev/null
+++ b/packaging_apps_hooks_fr.md
@@ -0,0 +1,192 @@
+# Usage des hooks YunoHost
+
+Les hooks permettent de déclencher un script lorsqu'une action est effectuée par le système.
+Le cas le plus évident, est l'ajout d'un utilisateur. Si l'app dispose d'un hook `post_user_create`, ce hook sera déclenché dés qu'un utilisateur sera ajouté.
+Cela permet donc à une application d'exécuter des actions en fonction des évènements intervenant sur le système.
+
+### Liste des hooks disponibles
+
+- `post_domain_add`
+Après l'ajout d'un domaine.
+- `post_domain_remove`
+Après la suppression d'un domaine.
+- `post_user_create`
+Après l'ajout d'un utilisateur.
+- `post_user_delete`
+Après la suppression d'un utilisateur.
+- `post_iptable_rules`
+Après le rechargement du parefeu.
+- `pre_backup_delete`
+Avant la suppression d'un backup.
+- `post_backup_delete`
+Après la suppression d'un backup.
+- `post_app_addaccess`
+Après l'ajout d'un utilisateur autorisé sur une application.
+- `post_app_removeaccess`
+Après la suppression de l'autorisation d'un utilisateur sur une application.
+- `post_app_clearaccess`
+Après l'effacement de toute les règles d'accès sur une application.
+- `post_app_install`
+Après l'installation d'une application.
+- `post_app_upgrade`
+Après l'upgrade d'une applications.
+- `post_app_remove`
+Après la supression d'une applications.
+- `post_app_change_url`
+Après avoir modifié le chemin et/ou le nom de domaine d'une application.
+- `post_cert_update`
+Après la mise à jour d'un certificat.
+- `conf_regen`
+Avant et après la régénération de la configuration d'un service.
+Services pris en charge par `regen-conf` :
+ - avahi-daemon
+ - dnsmasq
+ - dovecot
+ - fail2ban
+ - glances
+ - metronome
+ - mysql
+ - nginx
+ - nslcd
+ - nsswitch
+ - postfix
+ - rspamd
+ - slapd
+ - ssh
+ - ssl
+
+### Mise en place des hooks
+
+À l'exception du hook `conf_regen`, tout les hooks s'utilisent de la même manière.
+Tout d'abord, il faut comprendre qu'un hook est un simple script bash qui sera exécuté par YunoHost lorsque l'évènement indiqué se présentera.
+Pour ajouter un hook à YunoHost, il faut utiliser un dossier "hooks" à la racine du package de l'application. Puis dans celui-ci mettre votre script sous le nom du hooks correspondant.
+
+> Par exemple :
+Pour un hook `post_user_create`, le script qui devra être exécuté pour ce hook doit simplement être placé dans `hooks/post_user_create` dans le package.
+
+Lors de l'installation et de l'upgrade, les scripts dans le dossier hooks seront dupliqués dans le dossier `/etc/yunohost/hooks.d/` dans le dossier correspondant au hook, puis sous le nom `50-$app`.
+Lors de la suppression de l'application, tout les hooks lui appartenant seront supprimés.
+
+### Construire un script de hook
+
+En tant que script bash, un script de hook doit commencer par le shebang bash
+
+```bash
+#!/bin/bash
+```
+
+Ensuite il convient de prendre les arguments donnés par YunoHost lors de l'appel du script.
+Chaque hook propose des arguments différents.
+
+##### `post_domain_add` et `post_domain_remove`
+
+```bash
+domain=$1
+```
+
+##### `post_user_create`
+
+```bash
+username=$1
+mail=$2
+password=$3 # Clear password
+firstname=$4
+lastname=$5
+```
+##### `post_user_delete`
+
+```bash
+username=$1
+purge=$2 # True/False Indique si le dossier utilisateur a été supprimé ou pas.
+```
+
+##### `post_iptable_rules`
+
+```bash
+upnp=$1 # True/False Indique si l'UPnP est activé ou non.
+ipv6=$2 # True/False Indique si l'IPV6 est activé ou non.
+```
+
+##### `pre_backup_delete` et `post_backup_delete`
+
+```bash
+backup_name=$1
+```
+
+##### `post_app_install`, `post_app_upgrade`, `post_app_remove` et `post_app_change_url`
+
+Les variables utilisables dans ces scripts sont les mêmes que celles disponibles dans [les scripts d'actions associés](/packaging_apps_scripts).
+
+
+Example : pour `post_app_install` les variables sont les mêmes que pour le script `install`
+
+##### `post_app_addaccess` et `post_app_removeaccess`
+
+```bash
+app_id=$1
+users=$2 # Tous les utilisateurs autorisés sur l'app. Séparés par des virgules.
+```
+
+##### `post_app_clearaccess`
+
+```bash
+app_id=$1
+```
+
+##### `post_cert_update`
+```bash
+domain=$1
+```
+
+La suite du script dépend de ce que vous voulez effectuer dans celui-ci.
+
+### Cas particulier de `conf_regen`
+Le hook `conf_regen` est un hook plus délicat, que ce soit pour sa mise en place ou pour son contenu.
+
+##### Mise en place d'un hook `conf_regen`
+
+Un hook `conf_regen` ne doit pas être placé dans le dossier hooks de l'application. Il doit être mis en place manuellement.
+Le hook doit être copié en indiquant à quel service il est lié.
+```bash
+cp hook_regen_conf /usr/share/yunohost/hooks/conf_regen/50-SERVICE_$app
+```
+
+> Lors de la suppression de l'application, ce hook devra être supprimé manuellement.
+
+##### Construire un script de hook conf_regen
+
+Un hook `conf_regen` est appelé 2 fois, une première fois après analyse de la configuration et avant une éventuelle modification des fichiers, puis une seconde fois après application des modifications, si il y a eu des modifications.
+
+Un script de hook `conf_regen` devrait donc ressembler à ça :
+
+```bash
+#!/bin/bash
+
+force=${2:-0} # 0/1 --force argument
+dryrun=${3:-0} # 0/1 --dry-run argument
+pending_conf=$4 # Path of the pending conf file
+
+do_pre_regen() {
+ # Put your code here for pre regen conf.
+}
+
+do_post_regen() {
+ # Put your code here for post regen conf.
+ # Be careful, this part will be executed only if the configuration has been modified.
+}
+
+case "$1" in
+ pre)
+ do_pre_regen
+ ;;
+ post)
+ do_post_regen
+ ;;
+ *)
+ echo "Hook called with unknown argument \`$1'" >&2
+ exit 1
+ ;;
+esac
+
+exit 0
+```
diff --git a/packaging_apps_levels.md b/packaging_apps_levels.md
new file mode 100644
index 00000000..ee953e66
--- /dev/null
+++ b/packaging_apps_levels.md
@@ -0,0 +1,72 @@
+# Quality levels of YunoHost application packages
+
+In order to facilitate the packaging of applications by providing successive steps to achieve, each package is assigned a quality level, from 0 to 10.
+A package must meet a number of criteria to reach each level. In addition, to reach a level, the package must have previously reached the previous level.
+
+This classification of applications by levels has 3 advantages:
+- The application packaging is more fun, with clear objectives to achieve and successive steps.
+- A properly packaged application is put forward more than an application that does not comply with packaging rules.
+- Users can quickly see the level of an application and thus know if the package is of good quality.
+
+The level is automatically computed by the automatic test suite ("the CI") which runs tests [here](https://ci-apps.yunohost.org/ci/) and results are summarized [here](https://dash.yunohost.org/appci/branch/stable).
+
+
+
+In the application catalog of the webadmin, an application is only shown to the user if its level is at least 5. Otherwiser, users may have to enable the display of "low-quality" applications to be able to install it.
+
+
+
+## Summary of the level definitions
+
+The following summarizes the current definition of the levels.
+
+The exact definitions are likely to shift over time and are heavily dependent on:
+- the [package linter](https://github.com/YunoHost/package_linter) which performs a static analysis of the app scripts and files to detect issues or deprecated practices
+- the [package check system](https://github.com/YunoHost/package_check) which actually tests the various operations (installs, upgrades, backup...)
+
+#### Level 0
+
+The application does not work at all.
+
+#### Level 1
+
+The application can be installed/removed in at least one configuration.
+
+#### Level 2
+
+The application can be installed/removed in all common configurations.
+
+(Typically this corresponds to full domain vs. sub path installs, private/public
+installs, multi-instance installs)
+
+#### Level 3
+
+The application supports upgrading.
+
+#### Level 4
+
+The application supports backup/restore.
+
+#### Level 5
+
+The application triggers no errors on the package linter
+
+#### Level 6
+
+The application repository is part of the YunoHost-Apps organization, which allows the community to contribute to its maintainance.
+
+#### Level 7
+
+The application triggers no warnings on the package linter.
+
+#### Level 8
+
+The application is long-term good quality, meaning it's been at least level 5 in the application catalog for a certain amount of time (when writing this: level 5+ 90% of the time during the last year)
+
+#### Level 9
+
+The application is considered ["high-quality"](https://github.com/YunoHost/apps/blob/master/hq_validation_template.md): it is well-integrated with YunoHost (in particular SSO/LDAP) and follows the recommended development workflow.
+
+#### Level 10
+
+(No definition yet)
diff --git a/packaging_apps_levels_fr.md b/packaging_apps_levels_fr.md
new file mode 100644
index 00000000..ff75b387
--- /dev/null
+++ b/packaging_apps_levels_fr.md
@@ -0,0 +1,163 @@
+# Niveaux de qualité des packages d’applications YunoHost
+
+Afin de faciliter le packaging d'applications par des étapes successives à atteindre, chaque package est affublé d'un niveau de qualité, de 0 à 10.
+Un package doit satisfaire un certain nombre de critères pour atteindre chaque niveau. De plus pour atteindre un niveau, le package doit avoir préalablement atteint le niveau précédent.
+
+Ce classement des applications par niveaux présente 3 avantages :
+- Le packaging d'application est d'autant plus ludique, avec des objectifs clairs à atteindre et des étapes successives.
+- Une application correctement packagée est davantage mise en avant qu'une application ne respectant pas les règles de packaging.
+- Les utilisateurs peuvent rapidement voir le niveau d'une application et ainsi savoir si le package est de bonne qualité.
+
+## Résumé des niveaux
+
+**Niveau 0**
+L'application ne fonctionne pas.
+
+**Niveau 1**
+L'application s'installe et se désinstalle correctement dans certains cas.
+
+**Niveau 2**
+L'application s'installe et se désinstalle correctement dans toutes les configurations communes.
+
+**Niveau 3**
+L'application peut être mise à jour.
+
+**Niveau 4**
+L'application peut-être sauvegardée et restaurée.
+
+**Niveau 5**
+Le code du package d'application respecte certaines règles de syntaxe.
+
+**Niveau 6**
+Le package d'application est dans l'organisation YunoHost-Apps.
+
+**Niveau 7**
+Le package d'application passe avec succès l'ensemble des tests d'intégrité.
+
+**Niveau 8**
+Le package d'application respecte toute les recommendations de packaging d'apps. C'est une app de très bonne qualité.
+
+**Niveau 9**
+Le package d'application respecte des recommandations de packaging supérieures. Non disponible pour le moment.
+
+**Niveau 10**
+Le package d'application est jugé parfait !
+
+## Les niveaux de qualité en détails :
+
+### Niveau 0
+**L'application ne s'installe pas ou ne fonctionne pas après installation.**
+C'est le niveau le plus bas, une application de niveau 0 est considérée comme non fonctionnelle.
+
+YEP à respecter pour atteindre le niveau 0 :
+- [YEP 1.1](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-11---nommer-son-app-et-son-d%C3%A9pot---valid%C3%A9--manuel--notworking-) : Nommer son app et son dépôt
+- [YEP 1.2](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-12---inscrire-lapp-sur-un-r%C3%A9pertoire-connu---valid%C3%A9--manuel--notworking-) : Inscrire l'app sur un "répertoire" connu
+
+### Niveau 1
+**L'application s'installe et se désinstalle correctement.**
+Mais des exceptions sont possibles, si au moins une méthode d'installation est fonctionnelle ainsi que sa suppression alors l'application est considérée comme fonctionnelle.
+
+YEP à respecter pour atteindre le niveau 1 :
+- [YEP 2.2](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-22---utiliser-bash-pour-les-scripts-principaux---valid%C3%A9--auto--working-) : Utiliser bash pour les scripts principaux
+- [YEP 2.5](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-25---copier-correctement-des-fichiers----brouillon--manuel--working-) : Copier correctement des fichiers
+- [YEP 2.7](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-27---donner-des-permissions-suffisantes-aux-instructions-bash----valid%C3%A9--auto--working-) : Donner des permissions suffisantes aux instructions bash
+- [YEP 2.15](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-215---v%C3%A9rifier-les-param%C3%A8tres-saisies-par-lutilisateur----valid%C3%A9--manuel--official-) : Suivre les instructions d'installation de l'application
+
+### Niveau 2
+**L'application s'installe et se désinstalle dans toutes les configurations communes.**
+
+- Installation en sous-dossier.
+- Installation à la racine d'un domaine ou d'un sous-domaine.
+- Installation privée (sécurisée par le SSO).
+- Installation publique.
+- Installation multi-instance.
+- Désinstallation dans les mêmes circonstances.
+
+*Si une application ne permet pas certaines configurations d'installation, celles-ci doivent être indiquées clairement dans le readme du package. Toutefois, le niveau 2 ne peut pas être atteint si une configuration d'installation est volontairement écartée sans raison valable.*
+*Cela n'empêche pas de restreindre volontairement les installations publiques, privées ou multi-instance si l'application le justifie.*
+
+YEP à respecter pour atteindre le niveau 2 :
+- [YEP 1.5](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-15---mettre-%C3%A0-jour-r%C3%A9guli%C3%A8rement-le-statut-de-lapp---brouillon--manuel--working-) : Mettre à jour régulièrement le statut de l'app
+- *[YEP 2.18.2](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-2182---supporter-linstallation-sur-un-domaine----valid%C3%A9--auto--working-) : Supporter l'installation sur un domaine*
+- *[YEP 2.18.3](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-2183---supporter-linstallation-sur-un-sous-domaine----valid%C3%A9--auto--working-) : Supporter l'installation sur un sous-domaine*
+- *[YEP 2.18.4](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-2184---supporter-linstallation-sur-un-sous-dossier----valid%C3%A9--auto--official-) : Supporter l'installation sur un sous-dossier*
+- *[YEP 4.6](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-46---g%C3%A8re-le-multi-instance----valid%C3%A9--manuel--optional-) : Gère le multi-instance*
+
+### Niveau 3
+**L'application supporte l'upgrade depuis une ancienne version du package.**
+L'application doit pouvoir être mise à jour depuis une version précédente du package sans provoquer d'erreur.
+
+YEP à respecter pour atteindre le niveau 3 :
+- [YEP 2.3](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-23---sauvegarder-les-r%C3%A9ponses-lors-de-linstallation---valid%C3%A9--manuel--working-) : Sauvegarder les réponses lors de l'installation
+
+### Niveau 4
+**L'application peut-être sauvegardée et restaurée sans erreur sur la même machine ou une autre.**
+
+YEP à respecter pour atteindre le niveau 4 :
+- *[YEP 4.3](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-43---fournir-un-script-de-sauvegarde-yunohost-fonctionnel----valid%C3%A9--auto--official-) : Fournir un script de sauvegarde YunoHost fonctionnel*
+- *[YEP 4.4](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-44---fournir-un-script-de-restauration-yunohost-fonctionnel----valid%C3%A9--auto--official-) : Fournir un script de restauration YunoHost fonctionnel*
+
+### Niveau 5
+**L'application ne présente aucune erreur dans [Package linter](https://github.com/YunoHost/package_linter).**
+*Il peut y avoir des faux positifs dans Package linter. Ces situations seront gérées au cas par cas.*
+
+YEP à respecter pour atteindre le niveau 5 :
+- *[YEP 1.3](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-13---indiquer-la-licence-associ%C3%A9e-au-paquet---valid%C3%A9--auto--working-) : Indiquer la licence associée au paquet*
+- *[YEP 2.1](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-21---respecter-le-format-du-manifeste---valid%C3%A9--auto--inprogress-) : Respecter le format du manifeste*
+- [YEP 2.12](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-212---utiliser-les-commandes-pratiques-helpers---valid%C3%A9--auto--official-) : Utiliser les commandes pratiques (helpers)
+- [YEP 2.18.1](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-2181---lancer-le-script-dinstallation-dune-webapp-correctement----valid%C3%A9--manuel--working-) : Lancer le script d'installation d'une webapp correctement
+
+### Niveau 6
+**Le package d'application est dans l'organisation YunoHost-Apps.**
+
+YEP à respecter pour atteindre le niveau 6 :
+- [YEP 1.4](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-14---informer-sur-lintention-de-maintenir-un-paquet----brouillon--manuel--working-) : Informer sur l'intention de maintenir un paquet
+- [YEP 1.6](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-16---se-tenir-inform%C3%A9-sur-l%C3%A9volution-du-packaging-dapps---valid%C3%A9--manuel--official-) : Se tenir informé sur l'évolution du packaging d'apps
+- *[YEP 1.7](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-17---ajouter-lapp-%C3%A0-lorganisation-yunohost-apps---valid%C3%A9--manuel--official-) : Ajouter l'app à l'[organisation YunoHost-Apps](https://github.com/YunoHost-Apps)*
+- [YEP 1.8](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-18---publier-des-demandes-de-test---valid%C3%A9--manuel--official-) : Publier des demandes de test
+- [YEP 1.9](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-19---documenter-lapp---valid%C3%A9--auto--official-) : Documenter l'app
+- [YEP 1.10](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-110---garder-un-historique-de-version-propre----brouillon--manuel--official-) : Garder un historique de version propre
+- [YEP 2.9](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-29---enlever-toutes-traces-de-lapp-lors-de-la-suppression----brouillon--manuel--working-) : Enlever toutes traces de l'app lors de la suppression
+- [YEP 3.3](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-33---faciliter-le-contr%C3%B4le-de-lint%C3%A9grit%C3%A9-des-sources----brouillon--manuel--official-) : Faciliter le contrôle de l'intégrité des sources
+- [YEP 3.5](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-35---suivre-les-recommendations-de-la-documentation-de-lapp----valid%C3%A9--manuel--official-) : Suivre les recommandations de la documentation de l'app
+- [YEP 3.6](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-36---mettre-%C3%A0-jour-les-versions-contenant-des-cve----draft--manuel--official-) : Mettre à jour les versions contenant des CVE
+
+### Niveau 7
+**L'application ne présente aucune erreur dans [Package check](https://github.com/YunoHost/package_check).**
+En considérant le maximum de tests possibles pour l'application.
+
+YEP à respecter pour atteindre le niveau 7 :
+- [YEP 2.4](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-24---d%C3%A9tecter-et-g%C3%A9rer-les-erreurs---brouillon--manuel--working-) : Détecter et gérer les erreurs
+- [YEP 2.6](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-26---annuler-laction-si-les-valeurs-dentr%C3%A9es-sont-incorrectes----valid%C3%A9--manuel--working-) : Annuler l'action si les valeurs d'entrées sont incorrectes
+- [YEP 2.8](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-28---modifier-correctement-une-configuration-syst%C3%A8me----brouillon--manuel--working-) : Modifier correctement une configuration système
+- [YEP 2.10](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-210---configurer-les-logs-de-lapplication----brouillon--manuel--working-) : Configurer les logs de l'application
+- [YEP 2.11](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-211---utiliser-une-variable-plut%C3%B4t-que-lapp-id-directement---valid%C3%A9--manuel--official-) : Utiliser une variable plutôt que l'app id directement
+- [YEP 2.13](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-213---traduire-le-package-en-anglais----brouillon--manuel--official-) : Traduire le package en anglais
+- [YEP 3.2](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-32---ouvrir-un-port-correctement----brouillon--manuel--working-) : Ouvrir un port correctement
+
+### Niveau 8
+**Le package d'application respecte toute les recommandations de packaging d'apps. C'est une app de très bonne qualité.**
+
+YEP à respecter pour atteindre le niveau 8 :
+- [YEP 1.12](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-112) : Respect le modèle de l'application d'exemple
+- Prise en charge du changement d'URL
+- *[YEP 2.16](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-216---v%C3%A9rifier-la-disponibilit%C3%A9-des-d%C3%A9pendances-sur-arm-x86-et-x64----valid%C3%A9--manuel--official-) : Vérifier la disponibilité des dépendances sur ARM, x86 et x64*
+- [YEP 2.18.5](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-2185---ajouter-la-tuile-yunohost-pour-naviguer-facilement-entre-les-applications----valid%C3%A9--manuel--official-) : Ajouter la tuile YunoHost pour naviguer facilement entre les applications
+- [YEP 4.1](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-41---lier-au-ldap----valid%C3%A9--manuel--official-) : Lier au LDAP
+- [YEP 4.2](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-42---lier-lauthentification-au-sso----valid%C3%A9--manuel--official-) : Lier l'authentification au SSO
+- [YEP 4.5](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-45---utiliser-les-hooks----valid%C3%A9--manuel--optional-) : Utiliser les hooks
+
+*Si une application n'est pas disponible sur une architecture, et qu'il est impossible de contourner cette limitation raisonnablement, cette limitation doit être indiquée dans le readme et prise en compte dans le script d'installation. L'installation de l'application sur une architecture non supportée doit être stoppée avant de modifier les fichiers.*
+
+### Niveau 9
+**L'application respecte toutes les YEP optionnelles.**
+
+YEP à respecter pour atteindre le niveau 9 :
+- [YEP 2.14](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-214---remplir-correctement-un-fichier-de-conf----brouillon--manuel--official-) : Remplir correctement un fichier de conf
+- [YEP 2.17](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-217---prendre-en-compte-la-version-dorigine-lors-des-mises-%C3%A0-jour----valid%C3%A9--manuel--official-) : Prendre en compte la version d'origine lors des mises à jour
+- [YEP 3.4](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-34---isoler-lapp----brouillon--manuel--official-) : Isoler l'app
+- [YEP 4.2.1](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_fr.md#yep-421---d%C3%A9connexion----valid%C3%A9--manuel--official-) : Déconnexion
+
+### Niveau 10
+**L'application est jugée parfaite !**
+Ce niveau ultime pour une application ne peux être atteint que suite à étude approfondie du package et par la validation du groupe Apps.
diff --git a/packaging_apps_manifest.md b/packaging_apps_manifest.md
new file mode 100644
index 00000000..f4407aa1
--- /dev/null
+++ b/packaging_apps_manifest.md
@@ -0,0 +1,86 @@
+Application packaging
+
+## Manifest
+The `manifest.json` file defines the app's constants, a bunch of values that YunoHost needs to identify the app and install it correctly. It looks like this:
+```json
+{
+ "name": "Roundcube",
+ "id": "roundcube",
+ "packaging_format": 1,
+ "description": {
+ "en": "Open Source Webmail software",
+ "fr": "Webmail Open Source"
+ },
+ "url": "http://roundcube.net/",
+ "version": "1.0.1~ynh7",
+ "license": "free",
+ "maintainer": {
+ "name": "kload",
+ "email": "kload@kload.fr"
+ },
+ "requirements": {
+ "yunohost": ">= 2.4.0"
+ },
+ "multi_instance": true,
+ "services": [
+ "nginx",
+ "php5-fpm",
+ "mysql"
+ ],
+ "arguments": {
+ "install" : [
+ {
+ "name": "domain",
+ "type": "domain",
+ "ask": {
+ "en": "Choose a domain for Roundcube",
+ "fr": "Choisissez un domaine pour Roundcube"
+ },
+ "example": "domain.org"
+ },
+ {
+ "name": "path",
+ "type": "path",
+ "ask": {
+ "en": "Choose a path for Roundcube",
+ "fr": "Choisissez un chemin pour Roundcube"
+ },
+ "example": "/webmail",
+ "default": "/webmail"
+ }
+ ]
+ }
+}
+```
+
+* **name**: app name. It does not have to be unique, but it should be, since it is the name shown to all the YunoHost administrators in the app list. Any characters are allowed.
+
+* **id**: ID of the app. You have to ensure that this ID is unique before submit an app integration request. See [packaging_apps_guidelines.md#yep-11](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines.md#yep-11) for valid rules.
+
+- **packaging_format**: package version. Actual version is **1**. This key has been set up to make independant packaging evolution versions from YunoHost versions evolution.
+
+* **description**: complete app description. You can make it as detailed as you feel it should be. Only `en` is required right now, but you can translate the description by prepending the locale prefix.
+
+* **url**: software website.
+
+* **version**: version of the package built from the upstream version number and an incremental number for each change in the package without upstream change. Example "1.0.1~ynh7". Must be a string.
+
+* **license**: application license: `free`, `non-free` or a value from the Identifier column from https://spdx.org/licenses/. Be careful to not confuse with package license which must be put in `LICENSE` file.
+
+* **maintainer**: informations about the app maintainer for contact.
+
+- **requirements**: dependency of the application package to a Debian YunoHost package version. For instance, "yunohost": ">> 2.3.12", `yunohost` package version must be up to `2.3.12`.
+
+* [**multi_instance**](/packaging_apps_multiinstance): it defines app's ability to be installed multiple times.
+
+* **services**: services needed by the application among `nginx`, `php5-fpm`, `mysql`, `uwsgi`, `metronome`, `postfix`, `dovecot`…
+
+* **arguments**:
+ * **install**: argument for the YunoHost's administrator to enter at installation.
+ * **name**: argument identification.
+ * **type**: (optional) argument type among `domain`, `path`, `user`, `app`, `boolean`, `string` and `password`. The field will be hidden in the password case.
+ * **choices** : (optional) restrict value to several choices.
+ * **optional** : (optional) field which indicate if this argument is optional. It can have `true` and `false` value.
+ * **ask**: question (at least in `en`) that you can translate.
+ * **example**: (optional) example value to help administrator to fill the input.
+ * **default**: (optional) default value.
diff --git a/packaging_apps_manifest_fr.md b/packaging_apps_manifest_fr.md
new file mode 100644
index 00000000..50a9c611
--- /dev/null
+++ b/packaging_apps_manifest_fr.md
@@ -0,0 +1,86 @@
+Packaging d’application
+
+## Manifeste
+Le fichier `manifest.json` définit les constantes de l’application, un ensemble de valeurs dont YunoHost a besoin pour identifier l’application et l’installer correctement. Voici un exemple :
+```json
+{
+ "name": "Roundcube",
+ "id": "roundcube",
+ "packaging_format": 1,
+ "description": {
+ "en": "Open Source Webmail software",
+ "fr": "Webmail Open Source"
+ },
+ "url": "http://roundcube.net/",
+ "version": "1.0.1~ynh7",
+ "license": "free",
+ "maintainer": {
+ "name": "kload",
+ "email": "kload@kload.fr"
+ },
+ "requirements": {
+ "yunohost": ">= 2.4.0"
+ },
+ "multi_instance": true,
+ "services": [
+ "nginx",
+ "php5-fpm",
+ "mysql"
+ ],
+ "arguments": {
+ "install" : [
+ {
+ "name": "domain",
+ "type": "domain",
+ "ask": {
+ "en": "Choose a domain for Roundcube",
+ "fr": "Choisissez un domaine pour Roundcube"
+ },
+ "example": "domain.org"
+ },
+ {
+ "name": "path",
+ "type": "path",
+ "ask": {
+ "en": "Choose a path for Roundcube",
+ "fr": "Choisissez un chemin pour Roundcube"
+ },
+ "example": "/webmail",
+ "default": "/webmail"
+ }
+ ]
+ }
+}
+```
+
+* **name** : nom de l’application. Son unicité n’est pas nécessaire. Il est tout de même conseillé étant donné que c’est le nom qui apparaît dans la liste des applications pour les administrateurs de serveurs YunoHost.
+
+* **id** : identifiant de l’application. Vous devez vous assurer de son unicité.
+
+- **packaging_format** : version de packaging du paquet. La version **1** est la version actuelle. Cette clé a été mise en place afin de faire évoluer les versions de packaging de manière décorrélée des versions de YunoHost.
+
+* **description** : description complète de l’application. Vous pouvez la détailler comme bon vous semble. Uniquement le champ `en` (english) est requis, vous pouvez également ajouter la traduction en français :)
+
+* **url** : site web de l’application.
+
+* **version** : version du package construit à partir du numéro de version de l’application qui est installée et d'un incrément pour chaque changement du paquet sans changement de version de l'application. "Exemple: 1.0.1~ynh7". Le champ doit être une chaîne de caractères.
+
+* **license** : licence avec laquelle l’application est distribuée : `free`, `non-free` ou une des valeurs de la colonne Identifier du site https://spdx.org/licenses/. Attention à ne pas confondre avec la licence du paquet qui doit être mise dans le fichier `LICENSE`.
+
+* **maintainer** : informations à propos du mainteneur du paquet de l’application pour pouvoir le contacter.
+
+- **requirements** : dépendance du paquet de l’application à la version d’un paquet Debian de YunoHost. Par exemple : "yunohost": ">> 2.3.12", le paquet `yunohost` doit être de version supérieur à `2.3.12`.
+
+* [**multi_instance**](/packaging_apps_multiinstance) : capacité d’une application d’être installée plusieurs fois.
+
+* **services** : liste des services nécessaires au fonctionnement de l’application. `nginx`, `php5-fpm`, `mysql`, `uwsgi`, `metronome`, `postfix`, `dovecot`…
+
+* **arguments** :
+ * **install** : paramètres à demander à l’administrateur lors de l’installation.
+ * **name** : identifiant du paramètre
+ * **type** : (optionnel) type de paramètre parmis `domain`, `path`, `user`, `app`, `boolean`, `string` et `password`. Le champ sera caché dans le cas d’un mot de passe.
+ * **choices** : (optionnel) restreint les réponses possibles à plusieurs choix.
+ * **optional** : (optionnel) champs qui indique si ce paramètre est optionnel. Il peut avoir les valeurs `true` ou `false`.
+ * **ask** : question posée (au minimum en anglais – `en`) que vous pouvez traduire dans plusieurs langues.
+ * **example** : (optionnel) valeur d’exemple pour aider l’administrateur à remplir le formulaire d’installation.
+ * **default** : (optionnel) valeur par défaut.
diff --git a/packaging_apps_multiinstance.md b/packaging_apps_multiinstance.md
new file mode 100644
index 00000000..55d2433a
--- /dev/null
+++ b/packaging_apps_multiinstance.md
@@ -0,0 +1,20 @@
+Application packaging
+
+### Multi-instance
+Multi-instance is application capacity to be installed several times.
+
+#### Scripts
+When YunoHost installs the application, it passes `$YNH_APP_INSTANCE_NAME` var to the script, set to value `id__n` with the application `id` coming from the manifest and `n` being an integer incremented each time a new instance of the application is installed.
+
+**E.g.** in the Roundcube script, database is called `roundcube`, the install directory `roundcube` and the [NGINX configuration](/packaging_apps_nginx_conf) `roundcube`. This way, the second instance of Roundcube will not conflict with the first one, and will be installed in the `roundcube__2` database, in the `roundcube__2`directory, and with the `roundcube__2` NGINX configuration.
+
+Retrieve app identifier (including the multi-instance id):
+```bash
+app=$YNH_APP_INSTANCE_NAME
+```
+
+#### Manifest
+Set `multi_instance` variable to `true` in the [manifest](/packaging_apps_manifest):
+```json
+ "multi_instance": true,
+```
diff --git a/packaging_apps_multiinstance_fr.md b/packaging_apps_multiinstance_fr.md
new file mode 100644
index 00000000..b6c72f1d
--- /dev/null
+++ b/packaging_apps_multiinstance_fr.md
@@ -0,0 +1,21 @@
+Packaging d’application
+
+### Multi-instances
+Le multi-instance est la capacité d’une application à être installée plusieurs fois.
+
+#### Scripts
+Lorsque YunoHost installe l’application, il passe au script dans la variable `$YNH_APP_INSTANCE_NAME` la valeur `id__n` avec l’identifiant de l’application `id` provenant du manifeste et `n` un nombre incrémentée à chaque nouvelle instance de l’application.
+
+**Par exemple** : dans le script Roundcube, il faut nommer la base de données `roundcube`, le dossier d’installation `roundcube` et la [configuration NGINX](/packaging_apps_nginx_conf) `roundcube`. De cette manière, la seconde installation de Roundcube ne rentrera pas en conflit avec la première, et sera installée dans la base de données `roundcube__2`, dans le répertoire `roundcube__2`, et avec la configuration NGINX `roundcube__2`.
+
+
+Récupération de l'identifiant de l'app (incluant l'id multi-instance) :
+```bash
+app=$YNH_APP_INSTANCE_NAME
+```
+
+#### Manifeste
+Passer la variable `multi_instance` à `true` dans le [manifeste](/packaging_apps_manifest) :
+```json
+ "multi_instance": true,
+```
diff --git a/packaging_apps_nginx_conf.md b/packaging_apps_nginx_conf.md
new file mode 100644
index 00000000..2d50ee27
--- /dev/null
+++ b/packaging_apps_nginx_conf.md
@@ -0,0 +1,60 @@
+# NGINX configuration
+
+This tutorial aim to help setup NGINX configuration for application packaging.
+
+#### NGINX configuration
+Configuration must be in `conf/nginx.conf`. We must use **FastCGI** or a **proxy_pass** following the application:
+* **FastCGI** is used with PHP applications:
+```nginx
+location YNH_EXAMPLE_PATH {
+ alias YNH_WWW_PATH ;
+ if ($scheme = http) {
+ rewrite ^ https://$server_name$request_uri? permanent;
+ }
+ index index.php;
+ try_files $uri $uri/ index.php;
+ location ~ [^/]\.php(/|$) {
+ fastcgi_split_path_info ^(.+?\.php)(/.*)$;
+ fastcgi_pass unix:/var/run/php5-fpm.sock;
+ fastcgi_index index.php;
+ include fastcgi_params;
+ fastcgi_param REMOTE_USER $remote_user;
+ fastcgi_param PATH_INFO $fastcgi_path_info;
+ fastcgi_param SCRIPT_FILENAME $request_filename;
+ }
+
+ # Include SSOWAT user panel.
+ include conf.d/yunohost_panel.conf.inc;
+}
+```
+
+* **`proxy_pass`** in Python, Node.js, Go and Java applications:
+```nginx
+location YNH_EXAMPLE_PATH/ {
+ rewrite ^YNH_EXAMPLE_PATH$ YNH_EXAMPLE_PATH/ permanent;
+ proxy_pass http://YNH_EXEMPLE_DOMAIN:YNH_EXAMPLE_PORT/;
+ proxy_set_header Host $host;
+ proxy_buffering off;
+}
+```
+
+#### Install script
+We must modify `conf/nginx.conf` file with application arguments. For this, we use generic terms `YNH_EXAMPLE_PATH` that we modify by desired values with `sed` command:
+```bash
+sed -i "s@YNH_EXAMPLE_PATH@$path@g" ../conf/nginx.conf
+sed -i "s@YNH_EXAMPLE_PORT@$port@g" ../conf/nginx.conf
+sed -i "s@YNH_EXEMPLE_DOMAIN@$domain@g" ../conf/nginx.conf
+```
+We must move that configuration file in NGINX configuration, then reload NGINX configuration:
+```bash
+cp ../conf/nginx.conf /etc/nginx/conf.d/$domain.d/$app.conf
+sudo service nginx reload
+```
+If NGINX won't restart, it's possible that this configuration file isn't right.
+
+#### Remove script
+We must remove NGINX configuration of this application, then reload NGINX configuration:
+```bash
+rm -f /etc/nginx/conf.d/$domain.d/$app.conf
+sudo service nginx reload
+```
diff --git a/packaging_apps_nginx_conf_fr.md b/packaging_apps_nginx_conf_fr.md
new file mode 100644
index 00000000..0061701e
--- /dev/null
+++ b/packaging_apps_nginx_conf_fr.md
@@ -0,0 +1,60 @@
+# Configuration NGINX
+
+Ce tutoriel a pour but d’aider à la mise en place d’une configuration NGINX pour le packaging d’application.
+
+#### Configuration NGINX
+La configuration doit être mise dans `conf/nginx.conf`. Il s’agira d’utiliser **FastCGI** ou un **proxy_pass** suivant l’application :
+* **FastCGI** est utilisé dans les applications PHP :
+```nginx
+location YNH_EXAMPLE_PATH {
+ alias YNH_WWW_PATH ;
+ if ($scheme = http) {
+ rewrite ^ https://$server_name$request_uri? permanent;
+ }
+ index index.php;
+ try_files $uri $uri/ index.php;
+ location ~ [^/]\.php(/|$) {
+ fastcgi_split_path_info ^(.+?\.php)(/.*)$;
+ fastcgi_pass unix:/var/run/php5-fpm.sock;
+ fastcgi_index index.php;
+ include fastcgi_params;
+ fastcgi_param REMOTE_USER $remote_user;
+ fastcgi_param PATH_INFO $fastcgi_path_info;
+ fastcgi_param SCRIPT_FILENAME $request_filename;
+ }
+
+ # Include SSOWAT user panel.
+ include conf.d/yunohost_panel.conf.inc;
+}
+```
+
+* **`proxy_pass`** dans le cas d’applications Python, Node.js, Go et Java :
+```nginx
+location YNH_EXAMPLE_PATH/ {
+ rewrite ^YNH_EXAMPLE_PATH$ YNH_EXAMPLE_PATH/ permanent;
+ proxy_pass http://YNH_EXEMPLE_DOMAIN:YNH_EXAMPLE_PORT/;
+ proxy_set_header Host $host;
+ proxy_buffering off;
+}
+```
+
+#### Script d’installation
+Il s’agit de modifier le fichier `conf/nginx.conf` avec les paramètres de l’application. Pour cela, on utilise des termes génériques `YNH_EXAMPLE_PATH` que l’on modifie par des valeurs souhaitées avec la commande `sed` :
+```bash
+sed -i "s@YNH_EXAMPLE_PATH@$path@g" ../conf/nginx.conf
+sed -i "s@YNH_EXAMPLE_PORT@$port@g" ../conf/nginx.conf
+sed -i "s@YNH_EXEMPLE_DOMAIN@$domain@g" ../conf/nginx.conf
+```
+Il faut ensuite déplacer ce fichier de configuration dans la configuration de NGINX, puis recharger la configuration de NGINX :
+```bash
+cp ../conf/nginx.conf /etc/nginx/conf.d/$domain.d/$app.conf
+sudo service nginx reload
+```
+Si NGINX ne redémarre pas, il se peut que le fichier de configuration ne soit pas correct.
+
+#### Script de suppression
+Il s’agit de supprimer la configuration NGINX pour cette application, puis de recharger la configuration de NGINX :
+```bash
+rm -f /etc/nginx/conf.d/$domain.d/$app.conf
+sudo service nginx reload
+```
diff --git a/packaging_apps_permissions.md b/packaging_apps_permissions.md
new file mode 100644
index 00000000..0a36b39e
--- /dev/null
+++ b/packaging_apps_permissions.md
@@ -0,0 +1,75 @@
+# User groups and permissions
+
+Installing an app creates the permission `app.main` with `all_users` allowed by default.
+
+If you wish to make the application publicly available, instead of the old `unprotected_urls` mechanism, you should give access to the special group `visitors`:
+
+```shell
+ynh_permission_update --permission "main" --add visitors
+```
+
+If you wish to create a custom permission for your app (e.g. to restrict access to an admin interface) you may use the following helpers:
+
+```shell
+ynh_permission_create --permission "admin" --url "/admin" --allowed "$admin_user" --label "Label for your permission"
+```
+
+You don't need to take care of removing permissions or backing up/restoring them as it is handled by the core of YunoHost.
+
+### Migrating away from the legacy permission management
+
+When migrating/fixing an app still using the legacy permission system, it should be understood that the accesses are now to be managed by features from the core, outside of the application scripts!
+
+Application scripts are only expected to:
+- if relevant, during the install script, initialize the main permission of the app as public (`visitors`) or private (`all_users`) or only accessible to specific groups/users ;
+- if relevant, create and initialize any other specific permission (e.g. to some admin interface) in the install script (and *maybe* in some migration happening in the upgrade script).
+
+Applications scripts should absolutely **NOT** mess up with any already-existing app accesses (including `unprotected`/`skipped_uris` settings) during any other case, as *it would reset any admin-defined access rule*!
+
+When migrating away from the legacy permission, you should:
+- remove any management of `$is_public`-like or `$admin_user`-like setting, except for any manifest question meant to either *initialize* the app as public/private or specific permissions ;
+- remove the old legacy permissions. Check out the recommended way to proceed in the example_ynh app (in particular [this code snippet](https://github.com/YunoHost/example_ynh/pull/111/files#diff-57aeb84da86cb7420dfedd8e49bc644fb799d5413d01927a0417bde753e8922f))
+
+It should boil down to :
+```bash
+if ynh_legacy_permissions_exists; then
+ ynh_legacy_permissions_delete_all
+
+ ynh_app_setting_delete --app=$app --key=is_public
+
+ # Create the permission using the new framework (if your app has relevant additional permissions)
+ ynh_permission_create --permission="admin" --url="/admin" --allowed=$admin
+fi
+```
+
+- remove any call to `yunohost app addaccess` and similar actions that are now obsolete and deprecated.
+- if your app use LDAP and support filter, use the filter `'(&(objectClass=posixAccount)(permission=cn=YOUR_APP.main,ou=permission,dc=yunohost,dc=org))'` to allow users who have this permission. (A complete documentation of LDAP [here](https://moulinette.readthedocs.io/en/latest/ldap.html) if you want to undestand how it works with YunoHost)
+
+#### Additional features from 4.1
+
+- Label customization : this is the name displayed to end users in the user portal. You can provide a default label (for example app.admin maybe be labelled 'Admin interface'). The label may be changed later by the admin after installation.
+- Enabling/disabling tile : this toggles wether or not an app is shown in the user portal (if the user has the corresponding permission). The corresponding option is called `show_tile` which may be `True` or `False`. A single app may have multiple tiles in the SSO. The url of each tile corresponds to the `url` parameter of the permission.
+- Multiple url support: a permission may have additional urls associated to it. This give the possiblity to protect many url with the same permission - in particular for tricky use case (for example several pieces of admin interfaces spread over different subpaths).
+- Protecting permission: As a packager, you may choose to "protect" a permission if you believe that it's not relevant for the admin to add/remove this permission to/from the visitors group. For example, this is the case for the API permission of Nextcloud, which in the vast majority of cases should be kept publicly because mobile client won't go through the SSO. Note that when using the helper `ynh_permission_update`, it's still possible to add/remove the `visitor` group of this permission.
+- Disabling auth header: some app authentification mecanism do not appreciate that SSOwat injects the Authorization header (which is an essential mecanism for single sign-on). You can now choose to disable the auth header injection from SSOwat to fix this (instead of the previous hack of using `skipped_uris`)
+
+##### Correspondance between the old and new permission mecanism
+
+| | with auth header | no auth header |
+| :---------- | :--------------- | :------------- |
+| **public** | unprotected_uris | skipped_uris |
+| **private** | protected_uris | N/A |
+
+
+| | with auth header | no auth header |
+| :---------- | :------------------------------------------ | :------------------------------------------- |
+| **public** | auth_header=True, visitor group allowed | auth_header=False, visitor group allowed |
+| **private** | auth_header=True, visitor group not allowed | auth_header=False, visitor group not allowed |
+
+
+All of theses feature are managable by theses following helper:
+- `ynh_permission_create`
+- `ynh_permission_url`
+- `ynh_permission_update`
+
+If you have any question, please contact the app team
diff --git a/packaging_apps_scripts.md b/packaging_apps_scripts.md
new file mode 100644
index 00000000..6e4f6f88
--- /dev/null
+++ b/packaging_apps_scripts.md
@@ -0,0 +1,66 @@
+Application packaging
+
+## Scripts
+
+For now, a YunoHost package must contain five Shell scripts: `install`, `remove`, `upgrade`, `backup` and `restore`. A 6th script `change_url` can also be added optionally.
+These scripts will be executed as `root` on the YunoHost instances.
+
+Examples scripts are available in the [example app](https://github.com/YunoHost/example_ynh/tree/master/scripts)
+
+### Usage
+You have to put everything in the `install` script in order to get the app to install without issue. It means that you have to install dependencies, create required repositories, initialize potential databases, copy sources and configure everything in the single `install` script (and of course do the reverse process in the `remove` script).
+
+It's possible to use helpers and import function library by example from a `_common.sh` file.
+
+### Available variables for these scripts
+#### YNH_CWD
+This var contains the current working directory path of the executed script. It can be useful for find out the initial path if we have move of directory during the script execution. It is used by some helpers to be sure to use the good directory.
+
+#### YNH_APP_ID
+It contains the application's identifier without the instance's number.
+
+Example: strut
+
+#### YNH_APP_INSTANCE_NAME
+It contains the instance name which will is used in a lot of situation to manage multiple setup of the same app.
+
+Example: strut__3
+#### YNH_APP_INSTANCE_NUMBER
+It contains the instance's number. Warning, it's not the number of running instances because an old app might be deleted.
+
+Example: 3
+
+### Variables specific to `install`
+#### YNH_APP_ARG_XXXXXXX
+An environment variable is available for each question asked in the installation.
+
+For example, if in the manifest we have a question like this
+```json
+{
+ "name": "domain",
+ "type": "domain",
+ "ask": {
+ "en": "Choose a domain for OpenSondage",
+ "fr": "Choisissez un nom de domaine pour OpenSondage",
+ "de": "Wählen Sie bitte einen Domain für OpenSondage"
+ },
+ "example": "domain.org"
+}
+```
+
+The name of the question is `domain` so in the script we can access it with YNH_APP_ARG_DOMAIN. The usage is to create a shorter name in the script like this:
+
+```bash
+domain=$YNH_APP_ARG_DOMAIN
+```
+
+### Variables specific to `change_url`
+#### YNH_APP_OLD_DOMAIN
+The old domain where the app was installed.
+#### YNH_APP_OLD_PATH
+The old path where the app was installed.
+#### YNH_APP_NEW_DOMAIN
+The new domain where move the app.
+#### YNH_APP_NEW_PATH
+The new path where move the app.
+
diff --git a/packaging_apps_scripts_fr.md b/packaging_apps_scripts_fr.md
new file mode 100644
index 00000000..8854f287
--- /dev/null
+++ b/packaging_apps_scripts_fr.md
@@ -0,0 +1,67 @@
+Packaging d’application
+
+## Les scripts
+
+Un paquet YunoHost doit contenir cinq scripts Shell : `install`, `remove`, `upgrade`, `backup` et `restore`. Un 6ème script `change_url` peut aussi être ajouté de façon optionnelle.
+Ces scripts seront exécutés en tant que `root` sur les serveurs YunoHost.
+
+Des exemples de ces scripts sont disponibles dans l'[application d'exemple](https://github.com/YunoHost/example_ynh/tree/master/scripts).
+
+### Utilisation
+Vous devez tout mettre dans le script d’`install` pour que votre application soit entièrement installée. Cela signifie que vous devez installer les dépendances, créer les répertoires requis, initialiser les bases de données nécessaires, copier les sources et configurer tout dans l’unique script `install` (et bien sûr faire la procédure inverse dans le script `remove`).
+
+Il est possible d'utiliser des helpers et d'importer une librairie de fonction par exemple depuis un fichier `_common.sh`.
+
+### Variables disponibles pour tous ces scripts
+#### YNH_CWD
+Cette variable contient le chemin du répertoire de travail courant du contexte d'exécution du script. Elle peut être utile pour retrouver le chemin initial si on s'est déplacé pendant l'exécution du script. Elle est utilisée par certains helpers pour être sûr d'utiliser le bon.
+
+#### YNH_APP_ID
+Contient l'identifiant de l'application sans le numéro d'instance
+
+Exemple: strut
+#### YNH_APP_INSTANCE_NAME
+Contient le nom d'instance qui sera utilisé dans de nombreuses situation pour pouvoir gérer l'installation multiple d'une même app.
+
+Exemple: strut__3
+#### YNH_APP_INSTANCE_NUMBER
+Contient le numéro de l'instance. Attention il ne s'agit pas forcément du nombre d'instance toujours installée, car une ancienne application peut avoir été désinstallée.
+
+Exemple: 3
+
+### Variables spécifiques pour `install`
+#### YNH_APP_ARG_XXXXXXX
+Pour chaque question posée lors de l'installation, une variable d'environnement est disponible.
+
+Par exemple, si dans le manifest nous avons une question de cette forme
+```json
+{
+ "name": "domain",
+ "type": "domain",
+ "ask": {
+ "en": "Choose a domain for OpenSondage",
+ "fr": "Choisissez un nom de domaine pour OpenSondage",
+ "de": "Wählen Sie bitte einen Domain für OpenSondage"
+ },
+ "example": "domain.org"
+}
+```
+
+Le nom de la question `domain` donc dans le script on peut accéder à cette variable via $YNH_APP_ARG_DOMAIN. L'usage est de créer une variable plus courte comme ceci:
+
+```bash
+domain=$YNH_APP_ARG_DOMAIN
+```
+
+### Variables spécifiques pour `change_url`
+#### YNH_APP_OLD_DOMAIN
+L'ancien domaine où était installée l'app.
+
+#### YNH_APP_OLD_PATH
+L'ancien chemin où était installée l'app.
+
+#### YNH_APP_NEW_DOMAIN
+Le nouveau domaine où doit être installée l'app.
+
+#### YNH_APP_NEW_PATH
+Le nouveau chemin où doit être installée l'app.
diff --git a/packaging_apps_start.md b/packaging_apps_start.md
new file mode 100644
index 00000000..d6c27ea9
--- /dev/null
+++ b/packaging_apps_start.md
@@ -0,0 +1,66 @@
+# Introduction to packaging
+
+This documentation is here is to provide all the basic concepts and vocabulary needed to understand app packaging. eg: shell, parsing, system administration...
+
+We will detail what is a YunoHost application package, how it works, how to make your own package and how to find help if you need it.
+
+## What is a YunoHost application package
+
+Before we continue, we need to define what is exactly an application package.
+
+To be able to do that, we need to remember that YunoHost at its core is a server operating system whose mission is to simplify selfhosting of internet services. To accomplish that, YunoHost provides, among other things, an administration panel allowing application installation in a few clicks.
+
+If you have ever installed a web application manually, you already know that the process is in reality far more complex, usually involving a lot of steps and discipline.
+
+This is what application packaging is, a series of scripts that automate the installation of a web application and its configuration in order to provide the final user with a few clicks installation process.
+
+### How it works
+
+From the final user perspective, it is as simple as it can be:
+
+1. Pick an application
+2. Fill a form
+3. Wait
+4. Application is ready to use
+
+There is more to see backstage:
+First, when the application is selected, YunoHost will retrieve the corresponding package from github. eg: [Custom Webapp](https://github.com/YunoHost-Apps/my_webapp_ynh).
+Then, YunoHost will read the manifest.json file to know what questions to ask the user through the form.
+
+These seamingly trivial questions are very important. Usually you would need to ask for the domain on which to install, the path to access, the user that will be designated administrator and the default language for the application.
+
+These are critical to configure appropriately the web application during the installation process. To do so, YunoHost will retrieve the answers given by the user and send them to the installation script located in the package "*scripts*" folder.
+
+The install script will handle the user answers to complete the process as you would have done manually.
+
+If the user wants to delete the application, YunoHost will use the remove script from the "*scripts*" folder. It will handle the cleaning process for the user and delete all folders and configuration files that was previsouly installed by the application.
+
+### What is a script?
+
+Scripts used during application packaging are simply a series of bash commands.
+
+### ... bash command?
+
+A [bash](https://en.wikipedia.org/wiki/Bash_%28Unix_shell%29) command is a line of text that will be interpreted by the computer and will produce a result. This is commonly refered to as a command line.
+
+You can ony interact with your server through the command line as it does not provide a graphical interface. Usual access is through [ssh](/ssh).
+
+Package scripts are therefore a series of bash commands as if you had typed them directly in the ssh console.
+
+To know what you can write in a bash script, you should start reading this [simple tutorial](https://debian-facile.org/doc:programmation:shells:debuter-avec-les-scripts-shell-bash) or this [more advanced one](http://aral.iut-rodez.fr/fr/sanchis/enseignement/bash/index.html).
+
+### Ok, I'm good! Where do I start?
+
+Before starting the packaging process, you need to successfully install the application. The script will only perform what you instruct it to do.
+
+Once completed, you need to read a little bit more documentation about application packaging. [This one is more technical](/packaging_apps) but now you should understand all the wizardry.
+
+### HELP! NEED BACKUP!
+
+Fortunately, you are not alone in this!
+
+There are other packagers like you and you can meet them on the [forum](https://forum.yunohost.org/c/apps-packaging) or the [chat](xmpp:apps@conference.yunohost.org?join).
+
+Feel free to join in and ask your questions, there always will be someone to help.
+
+Soon enough you'll see for yourself that packaging applications is not that hard after all.
diff --git a/packaging_apps_start_fr.md b/packaging_apps_start_fr.md
new file mode 100644
index 00000000..182be676
--- /dev/null
+++ b/packaging_apps_start_fr.md
@@ -0,0 +1,55 @@
+# Introduction au packaging
+
+Petite introduction au packaging d'application, pour comprendre de quoi nous parlons et comment ça marche.
+Cette documentation s'adresse avant tout aux packageurs débutants qui ne sont pas à l'aise avec les concepts de shell, parsing et administration système de manière générale.
+
+Nous verrons ici ce qu'est un package d'application YunoHost, comment cela fonctionne, comment faire pour écrire un package et comment se lancer dans l'aventure sans être tout seul.
+
+### De quoi on parle en fait ?
+
+Avant de démarrer, la bonne question c'est "Qu'est-ce qu'un package d'application !?"
+
+Pour répondre à cette question, il faut revenir à ce qu'est YunoHost, c'est un système d’exploitation serveur visant à simplifier l’auto-hébergement de services Internet. Et pour faire ça, YunoHost met à disposition, entre autre, une interface d'administration permettant d'installer des applications en quelques clics.
+Or si vous avez déjà installé une application web à la main, vous savez qu'en réalité c'est bien plus compliqué que quelques clics sur une jolie interface.
+
+C'est là que le package d'application entre en jeu, c'est un ensemble de scripts qui automatise l'installation d'une application web et la préconfigure pour que l'utilisateur final n'ai besoin que de quelques clics pour l'installer facilement.
+
+### Mais alors, comment ça marche ?
+
+Du point de vue de l'utilisateur, c'est très simple, on choisit une application, on répond à quelques questions, ça mouline et c'est prêt.
+
+Mais il se passe bien plus de choses derrière.
+Tout d'abord, lorsque l'application est sélectionnée, YunoHost va aller chercher son package sur GitHub, par exemple l'application [Custom Webapp](https://github.com/YunoHost-Apps/my_webapp_ynh).
+Ensuite, YunoHost lit le fichier manifest.json pour connaître les questions à poser à l'utilisateur.
+
+Mais ces questions anodines sont très importantes, on retrouvera souvent le domaine sur lequel installer l'application, l'adresse à laquelle elle sera accessible, l'utilisateur qui en sera l'administrateur et la langue par défaut de l'application.
+
+Ce sont là des éléments essentiels pour configurer correctement notre application web lors de son installation. Pour ce faire, YunoHost va récupérer les réponses données par l'utilisateur et les envoyer au script install qui se trouve dans le dossier scripts du package.
+
+Le script install va se charger d'installer l'application, en prenant en compte les réponses données par l'utilisateur. Ce script va simplement faire ce que vous auriez fait si vous aviez installé l'application à la main.
+
+Si par la suite l'utilisateur souhaite supprimer l'application, YunoHost utilisera le script remove du dossier script, qui se chargera à la place de l'utilisateur de supprimer l'application, ses dossiers et tout ses fichiers de configuration.
+
+### Qu'y a-t-il dans ces scripts pour que tout soit si simple pour l'utilisateur ?
+
+Les scripts d'un package d'application sont simplement des commandes bash les unes à la suite des autres.
+
+#### ... Et c'est quoi une commande bash ?
+
+Une commande [bash](https://fr.wikipedia.org/wiki/Bourne-Again_shell) c'est une ligne de texte qui sera interprétée et produira un résultat. C'est ce qu'on a l'habitude d'appeler la ligne de commande.
+Or puisque votre serveur, sur lequel est installé YunoHost, ne dispose pas d'une interface graphique, vous n'avez que la ligne de commande de disponible. Vous l'atteignez en général après vous être connecté avec [ssh](/ssh).
+
+Les scripts d'un package ne sont donc qu'une succession de commandes bash, comme si vous les aviez tapées directement dans la console ssh pour installer l'application.
+
+Pour savoir quoi écrire dans un script bash, je vous conseille de commencer par la lecture d'un [tuto simple](https://debian-facile.org/doc:programmation:shells:debuter-avec-les-scripts-shell-bash). Et si vous avez vraiment envie de lire, il y a aussi un [tuto plus complet](http://aral.iut-rodez.fr/fr/sanchis/enseignement/bash/index.html)
+
+### Ok, je crois que j'ai compris ! Par où on commence ?
+
+Avant d'envisager de faire un package d'application, il faut réussir à installer correctement la dites application. Car le script ne fera que ce que vous lui direz de faire.
+
+Ensuite, il faut aller lire (et oui encore) la documentation sur le packaging, mais la vraie cette fois, [celle qui emploie des mots bizarres](/packaging_apps).
+Mais maintenant vous devriez les comprendre tout ces mots étranges.
+
+Mais heureusement, vous n'êtes pas seul pour affronter cette épreuve titanesque, il y a d'autres packageurs que vous pouvez venir rencontrer sur le [forum](https://forum.yunohost.org/c/apps-packaging) et sur le [salon de discussion](xmpp:apps@conference.yunohost.org?join).
+N'hésitez pas à venir poser des questions sur ce que vous ne comprenez pas, il y aura toujours quelqu'un pour vous répondre.
+Et vous constaterez bien vite que ce n'est pas si difficile de packager une application.
diff --git a/packaging_apps_trap.md b/packaging_apps_trap.md
new file mode 100644
index 00000000..a0071e01
--- /dev/null
+++ b/packaging_apps_trap.md
@@ -0,0 +1,113 @@
+# Trap usage
+
+Trap is an internal shell command used to capture the output signals of commands executed in the current shell and its subshells.
+
+Any command executed in the shell returns an exit signal at the end of its execution. Either 0 to indicate the end of the execution of the command, or a non-zero value indicating an interruption thereof.
+
+In the case of installation scripts, trap will allow us to detect a command interrupted in the middle of its execution due to an error.
+Detection of this error will allow the installation to be terminated and returned to the remove script for cleaning up residues.
+
+Trap is used as follows:
+
+```bash
+trap 'commande' liste_de_signaux
+```
+
+To simplify, we will use the pseudo signal `ERR` to gather all the error signals.
+
+We could simply add this line at the beginning of the script:
+
+```bash
+trap "echo Erreur d'installation" ERR
+```
+
+After this line, any command causing an error will trigger the display of the message indicated by trap.
+All of the current shell and the subshell will be supported by trap.
+
+To stop capturing signals with trap, you can simply deactivate trap.
+
+```bash
+trap ERR
+```
+
+Or completely ignore the affected output signals.
+
+```bash
+trap "" ERR
+```
+
+In the latter case, the interrupt signal will have no effect on the shell. This can be useful for a command whose error output should not impact the progress of the installation script.
+
+### Stop the installation script and clean up before exiting.
+In the event of an error in the installation script, trap must allow to stop the installation, then clean up the partially installed residual files before leaving the script.
+For this, we will provide a function dedicated to the installation failure.
+
+```bash
+# Delete files and db if exit with an error
+EXIT_PROPERLY () {
+ trap ERR # Disable trap
+ echo -e "\e[91m \e[1m" # Shell in light red bold
+ echo -e "!!\n $app install's script has encountered an error. Installation was cancelled.\n!!"
+
+ echo -e "\e[22m" # Remove bold
+
+ # Clean hosts
+ sudo sed -i '/#leed/d' /etc/hosts
+
+ if [ $ynh_version = "2.2" ]; then
+ /bin/bash ./remove # Call the script remove. In 2.2, this behavior is not automatic.
+ fi
+ exit 1
+}
+```
+
+The `EXIT_PROPERLY` function must indicate to the user that the installation has failed and clean up any residue that will not be taken care of by the remove script. The latter will be automatically called after exit `1` with YunoHost 2.4
+
+After this function, we can set up signal capture by trap.
+
+```bash
+trap EXIT_PROPERLY ERR
+```
+
+If a command fails during installation, the `EXIT_PROPERLY` function will be called, ending the installation.
+
+To simplify the capture of signals and ignore them for specific commands. It is possible to place trap calls in functions.
+
+```bash
+TRAP_ON () { # Activate signal capture
+ trap EXIT_PROPERLY ERR # Capturing exit signals on error
+}
+TRAP_OFF () { # Ignoring signal capture until TRAP_ON
+ trap '' ERR # Ignoring exit signals
+}
+```
+
+> The `TRAP_OFF` function does not work. For some reason. Using `trap '' ERR` directly works fine however.
+
+To manage possible installation errors, we can therefore simply add this code after retrieving the arguments:
+
+```bash
+# Delete files and db if exit with an error
+EXIT_PROPERLY () {
+ trap ERR # Disable trap
+ echo -e "\e[91m \e[1m" # Shell in light red bold
+ echo -e "!!\n $app install's script has encountered an error. Installation was cancelled.\n!!"
+
+ echo -e "\e[22m" # Remove bold
+
+ # Clean hosts
+ sudo sed -i '/#leed/d' /etc/hosts
+
+ if [ $ynh_version = "2.2" ]; then
+ /bin/bash ./remove # Call the script remove. In 2.2, this behavior is not automatic.
+ fi
+ exit 1
+}
+TRAP_ON () { # Activate signal capture
+ trap EXIT_PROPERLY ERR # Capturing exit signals on error
+}
+TRAP_OFF () { # Ignoring signal capture until TRAP_ON
+ trap '' ERR # Ignoring exit signals
+}
+TRAP_ON
+```
diff --git a/packaging_apps_trap_fr.md b/packaging_apps_trap_fr.md
new file mode 100644
index 00000000..41836279
--- /dev/null
+++ b/packaging_apps_trap_fr.md
@@ -0,0 +1,113 @@
+# Usage de trap
+
+Trap est une commande interne du shell permettant de capturer les signaux de sorties des commandes exécutées dans le shell courant et ses sous-shell.
+
+Toute commande exécutée dans le shell renvoi un signal de sortie à la fin de son exécution. Soit 0 pour indiquer la fin de l'exécution de la commande, soit une valeur non nulle indiquant une interruption de celle-ci.
+
+Dans le cas des scripts d'installation, trap va nous permettre de détecter une commande interrompue au milieu de son exécution en raison d'une erreur.
+La détection de cette erreur permettra de mettre fin à l'installation et de renvoyer vers le script remove en vue d'un nettoyage des résidus.
+
+Trap s'utilise de la manière suivante :
+
+```bash
+trap 'commande' liste_de_signaux
+```
+
+Pour simplifier, nous utiliserons le pseudo signal `ERR` pour rassembler tout les signaux d'erreur.
+
+On pourrait ajouter simplement cette ligne en début de script :
+
+```bash
+trap "echo Erreur d'installation" ERR
+```
+
+Après cette ligne, toute commande provoquant une erreur déclenchera l'affichage du message indiqué par trap.
+L'ensemble du shell courant et du sous-shell sera pris en charge par trap.
+
+Pour arrêter la capture des signaux par trap, on peut simplement désactiver trap.
+
+```bash
+trap ERR
+```
+
+Ou ignorer complètement les signaux de sorties concernés.
+
+```bash
+trap "" ERR
+```
+
+Dans ce dernier cas, le signal d'interruption n'aura aucun effet sur le shell. Cela peux être utile pour une commande dont la sortie en erreur ne doit pas impacter le déroulement du script d'installation.
+
+### Stopper le script d'installation et nettoyer avant de quitter.
+En cas d'erreur du script d'installation, trap doit nous permettre de stopper l'installation, puis de nettoyer les fichiers résiduels partiellement installés avant de quitter le script.
+Pour cela, nous allons prévoir une fonction dédiée à l'échec de l'installation.
+
+```bash
+# Delete files and db if exit with an error
+EXIT_PROPERLY () {
+ trap ERR # Disable trap
+ echo -e "\e[91m \e[1m" # Shell in light red bold
+ echo -e "!!\n $app install's script has encountered an error. Installation was cancelled.\n!!"
+
+ echo -e "\e[22m" # Remove bold
+
+ # Clean hosts
+ sudo sed -i '/#leed/d' /etc/hosts
+
+ if [ $ynh_version = "2.2" ]; then
+ /bin/bash ./remove # Call the script remove. In 2.2, this behavior is not automatic.
+ fi
+ exit 1
+}
+```
+
+La fonction EXIT_PROPERLY doit indiquer à l'utilisateur l'échec de l'installation et nettoyer les résidus qui ne seront pas pris en charge par le script remove. Ce dernier sera automatiquement appelé à la suite de l'exit 1 avec YunoHost 2.4
+
+Après cette fonction, on peut mettre en place la capture des signaux par trap.
+
+```bash
+trap EXIT_PROPERLY ERR
+```
+
+Si une commande échoue durant l'installation, la fonction EXIT_PROPERLY sera appelée, mettant fin à l'installation.
+
+Pour simplifier la capture des signaux et les ignorer pour des commandes ponctuelles. Il est possible de placer les appels à trap dans des fonctions.
+
+```bash
+TRAP_ON () { # Activate signal capture
+ trap EXIT_PROPERLY ERR # Capturing exit signals on error
+}
+TRAP_OFF () { # Ignoring signal capture until TRAP_ON
+ trap '' ERR # Ignoring exit signals
+}
+```
+
+> Ma fonction TRAP_OFF ne fonctionne pas. Pour une raison qui m'échappe. Utiliser `trap '' ERR` directement fonctionne très bien en revanche.
+
+Pour gérer les éventuelles erreur d'installations, on peut donc simplement ajouter ce morceau de code après la récupération des arguments :
+
+```bash
+# Delete files and db if exit with an error
+EXIT_PROPERLY () {
+ trap ERR # Disable trap
+ echo -e "\e[91m \e[1m" # Shell in light red bold
+ echo -e "!!\n $app install's script has encountered an error. Installation was cancelled.\n!!"
+
+ echo -e "\e[22m" # Remove bold
+
+ # Clean hosts
+ sudo sed -i '/#leed/d' /etc/hosts
+
+ if [ $ynh_version = "2.2" ]; then
+ /bin/bash ./remove # Call the script remove. In 2.2, this behavior is not automatic.
+ fi
+ exit 1
+}
+TRAP_ON () { # Activate signal capture
+ trap EXIT_PROPERLY ERR # Capturing exit signals on error
+}
+TRAP_OFF () { # Ignoring signal capture until TRAP_ON
+ trap '' ERR # Ignoring exit signals
+}
+TRAP_ON
+```
diff --git a/packaging_apps_virtualbox.md b/packaging_apps_virtualbox.md
new file mode 100644
index 00000000..3516b4b8
--- /dev/null
+++ b/packaging_apps_virtualbox.md
@@ -0,0 +1,91 @@
+# Create a development environment with VirtualBox
+
+This documentation page aims at explaining how to setup a YunoHost virtual server, using VirtualBox, to work on application packaging.
+
+## Why use VirtualBox rather than an actual YunoHost production server to package an application?
+
+There are mostly two reasons why one should prefer a virtual server rather than their own server:
+
+- You can freely torture a virtual server without any risk of breaking it, since you can always restore it to a former working state. It would really be a pity to break your own real server!
+- In a typical workflow, a virtual server state would be restored from a known snapshot before starting any work on it, so as to always keep a clean system, without any residues of a former installation. This allows to always be as close a possible to a user first installation.
+
+We will discuss VirtualBox in this guide, as it comes with an easy to use GUI. If you prefer a pure commandline approach to handling your virtual machine, you should use [ynh-dev](/dev) instead.
+
+## Installing VirtualBox
+
+From a GNU/Linux system, simply install the `virtualbox-qt` package.
+From a Windows or macOS machine, you'd have to refer to the [VirtualBox download page](https://www.virtualbox.org/wiki/Downloads) to fetch the appropriate installation package. The virtualbox package is deprecated since Debian 9, a `.deb` installation package is available on the abovementioned referenced page.
+
+Whatever your system, there should be no need to install the extension pack or the guest addons.
+
+## Installing YunoHost on VirtualBox
+
+Simply follow the appropriate documentation for [installing on VirtualBox](/install_on_virtualbox) then the [post-installation](/postinstall) guide.
+
+During post-install, there is no need to use an actual domain name in `.nohost.me` or `.noho.st`, as your virtual server won't be reachable from outside your local network.
+We prefer using a fake domain name which will remain associated with your local network, for instance `yunohost.packaging`.
+
+This domain name, not being registered with any DNS server, will be stored in the `hosts` file of the computer which will need to access it. Please refer to the documentation about [using a local DNS](/dns_local_network) for more information.
+
+Your virtual server is now installed. Before starting to use it, we'll see how to create a first snapshot and how to use that feature.
+
+## Using snapshots
+
+VirtualBox becomes even more interesting with its snapshotting feature, which allow to store the virtualized machine state and restore it quickly.
+We'll also see how to use multiple snapshot branches to work on different apps on the same machine.
+
+#### Now, let's create a first snapshot
+
+Before starting to play with the virtual machine, now is a good time to take a first snapshot, so that we don't have to redo the full install process every time.
+First, stop the virtual machine.
+
+Managing snapshots is done in the 'Snapshots' tab
+
+
+Here, we're creating a first snapshot
+
+
+We can now start to work on the virtual machine and create as many snapshots as desired for each milestone of our modifications.
+
+
+
+In this example, after having validated our particular package removal works fine, we can easily get back in time by restoring the virtual machine to its previous state with the package still installed.
+Once the package will be fully functional, it will just be a matter of deleting the snaphots associated with this package work to get the virtual machine back to its initial state.
+For our next test, we will then be back to a freshly installed YunoHost serveur, without any trace of package installation.
+
+#### Using multiple snapshot branches
+
+In addition to successive snapshots, it is also possible to create a new machine state and additional snapshots from an older machine snapshot/state.
+
+
+
+In this example, I have created two branches since my successful package installation, so as to independently test just the application removal, upgrade and backup/restore steps.
+I eventually got back to the virtual machine base state to start a new test on another package, without dropping my former test whatsoever.
+At any time, it is possible to get back to a previous snapshot simply by restoring it.
+The machine always start on the "Current state" state.
+
+
+
+> It is always possible to create a new snapshot, whether the machine is stopped or not. To restore a snapshot however, the machine cannot be running.
+
+## How do we connect to the virtual machine?
+
+Virtual machine connection is similar to any YunoHost server connection, that is by using `ssh`.
+
+```bash
+ssh admin@my.domain
+```
+Or, if the domain has not been added to the `hosts` file, via its IP address.
+
+```bash
+ssh admin@11.22.33.44
+```
+
+We can now work on the virtual machine using the commandline.
+
+To easily copy the package files or use a graphical text editor, one can also connect via `sftp` using a file explorer.
+
+It's a simple matter of using the `sftp://admin@my.domain/` address.
+
+
+> Note: on Windows or macOS, the file explorer does not natively support the `sftp` protocol...
diff --git a/packaging_apps_virtualbox_fr.md b/packaging_apps_virtualbox_fr.md
new file mode 100644
index 00000000..b2ef0158
--- /dev/null
+++ b/packaging_apps_virtualbox_fr.md
@@ -0,0 +1,92 @@
+# Créer un environnement de développement avec VirtualBox
+
+Cette page de documentation va vous expliquer comment mettre en place un serveur YunoHost virtuel, avec VirtualBox, pour travailler sur le packaging d'application.
+
+## Pourquoi utiliser VirtualBox plutôt qu’un serveur YunoHost de production pour packager une application ?
+
+Il y a principalement deux raisons pour préférer l'usage d'un serveur virtuel plutôt que votre propre serveur :
+
+- Vous pouvez torturer à loisir un serveur virtuel sans courir le risque de le casser, puisque vous pourrez toujours restaurer un état précédent. Alors qu'il serait dommage de casser son propre serveur !
+- Un serveur virtuel sera restauré avant de travailler dessus, pour garder en permanence un système sans résidus d'une précédente installation. Cela permet de se rapprocher au plus près d'une première installation par un utilisateur.
+
+Nous parlerons ici de VirtualBox, pour son approche graphique facile à utiliser. Si vous préférez une interface en ligne de commande pour la gestion de la machine virtuelle, tournez-vous de préférence vers [ynh-dev](/dev).
+
+## Installer VirtualBox
+
+Depuis un système GNU/Linux, installer simplement le paquet `virtualbox-qt`.
+Depuis un système Windows ou macOS, il faudra se référer à la page de [téléchargement de VirtualBox](https://www.virtualbox.org/wiki/Downloads) pour récupérer le fichier d'installation adéquat. Le paquet virtualbox est déprécié depuis debian 9, un fichier d'installation .deb est disponible sur la même page.
+
+Quel que soit votre système, il ne devrait pas être nécessaire d'installer l'extension pack ou les additions invités.
+
+## Installer YunoHost sur VirtualBox
+
+Suivez simplement la documentation idoine pour l'[installation sur VirtualBox](/install_on_virtualbox) puis la documentation sur la [post-installation](/postinstall).
+
+Lors de la post-installation, il est inutile d'utiliser un nom de domaine en `.nohost.me` ou `.noho.st`, votre serveur virtuel ne sera pas accessible depuis l'extérieur de votre réseau local.
+Nous préférerons l'usage d'un faux nom de domaine qui restera cantonné au réseau local. Par exemple, `yunohost.packaging`.
+
+Ce nom de domaine n'étant enregistré dans aucun serveur DNS, on l'enregistrera dans le fichier `hosts` de l'ordinateur qui y accédera. Voir la documentation sur le [DNS local](/dns_local_network).
+
+Votre serveur virtuel est à présent installé. Avant de commencer à l'utiliser, nous allons voir comment créer un premier instantané et comment les utiliser.
+
+## Utiliser les instantanés
+
+VirtualBox prend tout son intérêt avec l'usage des instantanés, qui permettent d'enregistrer l'état de la machine à un moment donné et d'y revenir rapidement.
+Nous verrons également par la suite comment utiliser plusieurs branches d'instantanés pour travailler sur des apps différentes sur une même machine.
+
+#### Tout d'abord, créons un premier instantané
+
+Avant de commencer à jouer avec la machine virtuelle, il convient de faire un premier instantané, pour ne pas avoir à recommencer le processus d'installation à chaque fois.
+Arrêtez la machine virtuelle avant tout.
+
+La gestion des instantanés se fait dans l'onglet "Instantanés"
+
+
+Et on crée un premier instantané
+
+
+À présent on peut commencer à travailler sur la machine virtuelle et créer autant d'instantanés que souhaité pour jalonner le travail.
+
+
+
+Dans cet exemple, on pourra facilement revenir en arrière, après avoir testé la suppression du package par exemple et restaurer la machine virtuelle dans l'état précédent avec le package encore installé avec succès.
+Et lorsque le package sera pleinement fonctionnel, il suffira de supprimer les instantanés liés à ce package pour revenir à l'état initial de la machine virtuelle.
+Nous disposerons ainsi d'un serveur YunoHost vierge de toute installation d'application pour notre prochain test.
+
+#### Utiliser plusieurs branches d'instantanés
+
+En plus de l'usage d'instantanés successifs, il est également possible de dériver un nouvel état actuel et de nouveaux instantanés depuis un instantané plus ancien que le dernier.
+
+
+
+Dans cet exemple, j'ai dérivé deux branches depuis mon installation réussie du package, pour tester indépendamment la suppression simple de l'application, l'upgrade et le backup/restore.
+Finalement je suis reparti de la base de la machine virtuelle pour démarrer un nouveau test sur un autre package, sans pour autant abandonner le précédent test.
+À tout moment, il est possible de revenir sur un instantané précédent en le restaurant.
+La machine démarrera toujours sur l'"État actuel".
+
+
+
+> Il est toujours possible de créer un nouvel instantané, que la machine soit à l'arrêt ou non.
+Mais pour restaurer un instantané, la machine ne doit pas être en cours d'exécution.
+
+## Comment se connecter à la machine virtuelle ?
+
+On se connecte à la machine virtuelle comme à n'importe quel serveur YunoHost, en utilisant ssh.
+
+```bash
+ssh admin@mon.domain
+```
+Ou, si le domaine n'a pas été ajouté dans le hosts, en utilisant son ip.
+
+```bash
+ssh admin@11.22.33.44
+```
+
+À présent, on peut travailler sur la machine virtuelle en CLI.
+
+Pour copier facilement les fichiers du package ou utiliser un éditeur de texte graphique, on peut également se connecter en sftp avec un explorateur de fichier.
+
+Il suffit de se connecter à l'adresse `sftp://admin@mon.domain/` avec l'explorateur.
+
+
+> Sur Windows ou macOS, l'explorateur de fichier ne supporte pas nativement le protocole sftp…
diff --git a/plug_and_boot.md b/plug_and_boot.md
new file mode 100644
index 00000000..ad25113e
--- /dev/null
+++ b/plug_and_boot.md
@@ -0,0 +1,30 @@
+
+# Boot and connect to your server
+
+* Plug the SD card (for ARM boards)
+* Plug the ethernet cable
+* Plug the power supply
+* Wait a couple minutes for your server to boot
+
+### Connecting to your server
+
+* Make sure that your computer (desktop/laptop) is connected to the same local network (i.e. same internet box) as your server.
+* Open a browser and type `https://yunohost.local` in the address bar.
+* If your server is up, you will very likely encounter a security warning. This is because your server is for now using what's called a "self-signed certificate" - and because we're accessing the server through a special `.local` domain. You will later be able to add a proper domain and install a certificate automatically recognized by web browsers as described in the [certificate documentation](/certificate). In the meantime, you should add a security exception to accept the current certificate.
+* If you are NOT able to join your server using the `yunohost.local` domain, try to [find the local IP of your server](/finding_the_local_ip) - then in your browser's address bar, type `https://192.168.x.y`
+* [Proceed with the initial configuration (post-installation)](/postinstall)
+
+---
+
+#### [Optional] Connecting your server to the internet through WiFi
+
+* If you want your server to connect using WiFi, you may configure it as explained [here](https://www.raspberrypi.org/documentation/configuration/wireless/wireless-cli.md).
+* Alternatively, you can mount the second partition of the SD card and edit the `wpa-supplicant.conf` file prior to boot the card for the first time. On Windows you can use [Paragon ExtFS](https://www.paragon-software.com/home/extfs-windows/) for this - just don't forget to unmount everytime for changes to take effect.
+
+---
+
+#### [Optional] Direct access with a screen and keyboard
+
+You can also boot your server with a screen and keyboard connected to it to see how the boot process is going on (which can also be useful to troubleshoot issues) and to have a direct access to it.
+
+
diff --git a/plug_and_boot_es.md b/plug_and_boot_es.md
new file mode 100644
index 00000000..d73cdd0d
--- /dev/null
+++ b/plug_and_boot_es.md
@@ -0,0 +1,17 @@
+# Conectar e iniciar el servidor
+
+* Conecta tu servidor con un cable Ethernet (RJ-45) **directamente sobre tu router principal**. También puedes configurar la conexión wifi como explicado [aquí (fr)](http://raspbian-france.fr/connecter-wifi-raspberry-pi-3/). El wifi también puede configurarse sin haber iniciado la tarjeta, "montando" la segunda partición de la tarjeta y finalmente editando el archivo wpa-supplicant.conf. En Windows, puedes utilizar [Paragon ExtFS](https://www.paragon-software.com/home/extfs-windows/), no olvides de "unmount" para que los cambios estén integrados.
+
+* No te olvides de **conectar una pantalla** si quieres observar cómo ocurre el inicio, y un teclado si quieres un acceso con **línea de comandos** a tu servidor.
+
+* Inicia el servidor, el Raspberry Pi va a reiniciarse si-mismo una primera vez, pues espera hasta que veas un gran `Y` cuadrado :
+
+
+
+
+
+
+*Nota el valor `IP` visible en la pantalla : esto es **la dirección IP local** de tu servidor.*
+
+
+
diff --git a/plug_and_boot_fr.md b/plug_and_boot_fr.md
new file mode 100644
index 00000000..9304e31d
--- /dev/null
+++ b/plug_and_boot_fr.md
@@ -0,0 +1,29 @@
+# Démarrer et se connecter à son serveur
+
+* Mettez la carte SD dans le serveur (pour le cas des cartes ARM)
+* Branchez le cable ethernet
+* Branchez l'alimentation
+* Laissez quelques minutes à votre serveur pour démarrer
+
+### Se connecter à son serveur
+
+* Assurez vous que votre ordianteur (de bureau ou portable) est connecté au même réseau local (c'est-à-dire la même box internet) que votre serveur.
+* Ouvrez un navigateur internet et tapez `https://yunohost.local` dans la barre d'adresse.
+* Si votre serveur est actif, vous rencontrerez très probablement un avertissement de sécurité. Cet avertissement viens du fait que votre serveur utilise pour le moment ce qui s'appelle un "certificat auto-signé" - et que nous utisons un domaine spécial en `.local`. Vous pourrez plus tard ajouter 'vrai' domaine et un certificat automatiquement reconnus par les navigateurs comme décrit dans la page sur les [Certificats](/certificate). En attendant, ajoutez une exception de sécurité pour accepter le certificat actuel.
+* Si vous n'arrivez pas à contacter votre serveur avec `yunohost.local`, essayez de [trouver l'IP locale de votre serveur](/finding_the_local_ip) - puis dans la barre d'adresse de votre navigateur, tapez `https://192.168.x.y`
+* [Effectuer la configuration initiale (post-installation)](/postinstall)
+
+---
+
+#### [Optionnel] Connecter le serveur à internet en WiFi
+
+* Vous pouvez aussi configurer la connexion wifi comme expliqué [ici](http://raspbian-france.fr/connecter-wifi-raspberry-pi-3/).
+* La configuration wifi peut aussi se faire sans avoir booté sur la carte, en "montant" la deuxième partition de la carte et enfin éditer le fichier `wpa-supplicant.conf`. Sur Windows vous pouvez utiliser [Paragon ExtFS](https://www.paragon-software.com/home/extfs-windows/). Ne pas oublier de "unmount" pour que les changements soient pris en compte.
+
+---
+
+#### [Optionnel] Accès direct avec un écran et clavier
+
+* Il est possible de brancher un écran et clavier sur votre serveur pour vérifier que le processus de démarrage (boot) se passe bien et pour avoir un accès direct en console.
+
+
diff --git a/port_forwarding.md b/port_forwarding.md
new file mode 100644
index 00000000..c24f5542
--- /dev/null
+++ b/port_forwarding.md
@@ -0,0 +1,6 @@
+# Port forwarding
+
+The sketch below tries to briefly summarize the role and necessity of port
+forwarding when setting up a server at home.
+
+
diff --git a/port_forwarding_es.md b/port_forwarding_es.md
new file mode 100644
index 00000000..3ff93dc3
--- /dev/null
+++ b/port_forwarding_es.md
@@ -0,0 +1,5 @@
+# Redirección de puertos
+
+El esquema aquí abajo intenta explicar brevemente el rol de la redirección de los puertos durante la instalación de un servidor en tu casa.
+
+
diff --git a/port_forwarding_fr.md b/port_forwarding_fr.md
new file mode 100644
index 00000000..1793b27b
--- /dev/null
+++ b/port_forwarding_fr.md
@@ -0,0 +1,6 @@
+# Redirection de ports
+
+Le schéma ci-dessous tente d'expliquer brièvement le rôle de la redirection des
+ports lors de la mise en place d'un serveur à la maison.
+
+
diff --git a/postinstall.md b/postinstall.md
new file mode 100644
index 00000000..c9e671b9
--- /dev/null
+++ b/postinstall.md
@@ -0,0 +1,69 @@
+# Post-Installation
+
+The step called "**post-installation**" is actually the initial configuration of YunoHost. It has to be done just after the installation of the system itself.
+
+NB: if you are in the process of restoring a server from scratch **and** you have a yunohost-made backup, you can skip this process and follow through with the "restoring during the postinstall" step, in the [backup](/backup) page.
+
+### From the web interface
+
+You can perform the post-installation with the web interface by entering in your browser :
+* **`yunohost.local`** OR **the local IP address of your server** if it is on your local network (e.g. at home !). The address typically looks like `192.168.x.y` (see [finding your local IP](/finding_the_local_ip))
+* **the public IP address of your server** if your server is not on your local network. Typically, if you own a VPS, your VPS provider should have given you the IP of the server.
+
+During the first visit, you will very likely encounter a security warning related to the certificate used by the server. For now, your server uses a self-signed certificate. You will later be able to add a certificate automatically recognized by web browsers as described in the [certificate documentation](/certificate). For now, you should add a security exception to accept the current certificate.
+
+You should then land on this page :
+
+
+
+Preview of the Web post-installation
+
+### From the command line
+
+You can also perform the postinstallation with the command `yunohost tools postinstall` directly on the server, or [via SSH](/ssh).
+
+
+
+Preview of the command-line post-installation
+
+
+
+## Informations asked
+
+### Main domain
+
+This is the first domain name linked to your YunoHost server, but also the one which will be used by your server's users to access the **authentication portal**. It will thus be **visible by everyone**, choose it wisely.
+
+* If you do not have a domain name, or if you want to use the YunoHost's DynDNS service, choose a sub-domain of **.nohost.me**, **.noho.st** or **.ynh.fr** (e.g. `homersimpson.nohost.me`). Provided that it's not already taken, the domain will be configured automatically and you won't need any further configuration step.
+
+* If you do know what **DNS** is, you probably want to configure your own domain name here. In this case, please refer to the [DNS page](/dns) page for more informations.
+
+* If you don't own a domain name and don't want a **.nohost.me**, **.noho.st** or **.ynh.fr**, you can use a local domain. More information on how to setup a local domain can be found [here](dns_local_network).
+
+### Administration password
+
+This password will be used to access to your server's [administration interface](/admin). You would also use it to connect via **SSH** or **SFTP**. In general terms, this is your **system's key**, [choose it carefully](http://www.wikihow.com/Choose-a-Secure-Password).
+
+
+
+---
+
+## Congratz!
+
+If you got so far and saw 'YunoHost has been successfully installed' (web
+postinstall) or 'YunoHost has been correctly configured', then congratulations!
+
+### What now ?
+
+- If you're self-hosting at home and without a VPN, you need to [make sure to
+ correctly forward ports on your router/Internet box](isp_box_config) ;
+- If you're using your own domain name (i.e. not a .nohost.me / .noho.st), you
+ need to [configure it according to the recommended DNS
+ configuration](dns_config) ;
+- If you cannot configure your domain name yet (because you didn't register it
+ yet, or because this is a test domain), see last paragraph
+ [here](dns_local_network) for a workaround ;
+- Don't be too afraid of the [certificate warning](certificate), you'll probably
+ be able to install a Let's Encrypt certificate :).
+- Have a look at [the available apps](apps) !
+
diff --git a/postinstall_es.md b/postinstall_es.md
new file mode 100644
index 00000000..f7566951
--- /dev/null
+++ b/postinstall_es.md
@@ -0,0 +1,65 @@
+# Post-instalación
+
+La etapa que llamamos « **post-instalación** » de hecho es la etapa de configuración inicial de YunoHost. Se ejecuta después de la **instalación** del sistema mismo.
+
+NB : Si estàs en el proceso de instalar de nuevo a un servidor **y** que ya tienes un archivo creada por yunohost, no debes seguir a està etapa y encontro seguir a la seccion "Restoring during the postinstall" de la pagina [backup](/backup).
+
+### Vía la interfaz web
+
+Puedes acceder a la post-instalación gráfica entrando en un navegador web :
+* la dirección **IP local de tu servidor** si éste está conectado a tu red local (en general `192.168.x.x`, ver ['Encontrar mi IP' en la página sobre SSH](/ssh))
+* la dirección **IP pública de tu servidor** si éste no está conectado a tu red local (por ejemplo, si es un VPS, tu proveedor debería haberte transmitido la dirección IP).
+
+Durante la primera visita, encontrarás muy probablemente una advertencia de seguridad relacionada al certificado utilizado. De momento, tu servidor utiliza un certificado autofirmado. Después, podrás utilizar un certificado automáticamente reconocido por los navegadores como descrito en la página sobre los [Certificados](/certificate). Mientras tanto, añade una excepción de seguridad para aceptar el certificado vigente.
+
+Luego, llegas en esta página :
+
+
+
+*Vistazo de la post-instalación Web
*
+
+### Vía la interfaz de línea de comando
+
+También puedes acceder a la post-instalación entrando el comando `yunohost tools postinstall` directamente en el servidor o [en SSH](/ssh).
+
+
+
+*Vistazo de la post-instalación con línea de comando
*
+
+## Informaciones solicitadas
+
+### Dominio principal
+
+Es el nombre de dominio que permitirá el acceso a tu servidor así como al portal de autenticación de los usuarios. Entonces estará **visible por todo el mundo** : elígelo en consecuencia.
+
+* YunoHost te propone un DNS dinámico, proveando nombres de dominio del tipo *midominio.nohost.me*, *midominio.noho.st* o *midominio.ynh.fr*. Si no posees un nombre de dominio y/o que quieres aprovechar de este servicio, elige un dominio terminando con `.nohost.me`, `.noho.st` o `.ynh.fr`. Si no está utlizado ya, el dominio automáticamente estará vinculado a tu servidor YunoHost, y no tendrás más etapas de configuración.
+
+* Si, en cambio, dominas la noción de **DNS**, puedes utilizar tu propio nombre de dominio. En este caso, refiérete a la página [yunohost.org/dns](/dns) por más información.
+
+* Si no tienes nombre de dominio y que no quieres uno que acabe con *.nohost.me*, *.noho.st* ou *.ynh.fr*, puedes utilizar un dominio local. Más información sobre cómo [acceder a tu servidor desde la red local](/dns_local_network).
+
+
+### Contraseña de administración
+
+Es la contraseña que permitirá acceder a la [interfaz de administración](/admin) de tu servidor. También podrás utilizarla para conectarte remotamente vía **SSH**, o vía **SFTP** para transferir archivos.
+
+De manera general, ésta es la **llave de entrada en tu sistema**, pues piensa en **[elegirla atentamente](https://es.wikihow.com/escoger-una-contrase%C3%B1a-segura)**.
+
+
+
+---
+
+## Enhorabuena !
+
+Si llegas aquí después de haber visto “YunoHost fue instalado con éxito" desde tu navegador ou tu interfaz de línea de comando, pues felicitaciones !
+
+
+### ¿ Y ahora ?
+
+- Si te auto-alojas en casa y sin VPN, tienes que asegurarte que [los puertos de tu caja internet estén redirigidos](/isp_box_config) ;
+- Si utilizas tu propio nombre de dominio (i.e. que no sea un nohost.me /
+ noho.st), tienes que [configurar el nombre de dominio según la configuración recomendada](/dns_config) ;
+- Si no puedes configurar el nombre de dominio de momento (porque todavía no lo has comprado, ou porque es un dominio test), puedes solucionar temporalmente el problema con las instrucciones del último párrafo [aquí](/dns_local_network) ;
+- No te asustes demasiado por [la advertencia a propósito del certificado](/certificate), tendrás la posibilidad de obtener un certificado Let's Encrypt :).
+- Echa un vistazo a las [aplicaciones disponibles](/apps) !
+
diff --git a/postinstall_fr.md b/postinstall_fr.md
new file mode 100644
index 00000000..1bd4d004
--- /dev/null
+++ b/postinstall_fr.md
@@ -0,0 +1,71 @@
+# Post-Installation
+
+L’étape appelée « **post-installation** » est en fait l’étape de configuration initiale de YunoHost. Il faut l’exécuter après l’**installation** du système en lui-même.
+
+NB : Si vous êtes en train de restaurer un système complet **et** que vous disposez d'un fichier de sauvegarde généré par YunoHost, vous devez sauter cette étape et vous référer à la section "Restaurer durant la postinstallation" sur la page [sauvegardes](/backup).
+
+### Via l'interface web
+
+Vous pouvez accéder à la post-installation graphique en entrant dans un navigateur web :
+* l'adresse **`yunohost.local`** OU l’adresse **IP locale de votre serveur** si celui-ci est connecté à votre réseau local (généralement `192.168.x.x`, voir ['Trouver son IP locale'](/finding_the_local_ip))
+* l’adresse **IP publique de votre serveur** si celui-ci n’est pas connecté à votre réseau local (par exemple dans le cas d'un VPS, votre fournisseur devrait vous avoir transmis l'adresse IP).
+
+Lors de la première visite, vous rencontrerez très probablement un avertissement de sécurité lié au certificat utilisé. Pour le moment, votre serveur utilise un certificat auto-signé. Vous pourrez plus tard ajouter un certificat automatiquement reconnus par les navigateurs comme décrit dans la page sur les [Certificats](/certificate). En attendant, ajoutez une exception de sécurité pour accepter le certificat actuel.
+
+Vous arrivez ensuite sur cette page :
+
+
+
+*Aperçu de la post-installation Web
*
+
+### Via la ligne de commande
+
+Vous pouvez aussi y accéder en entrant la commande `yunohost tools postinstall` directement sur le serveur ou [en SSH](/ssh).
+
+
+
+*Aperçu de la post-installation en ligne de commande
*
+
+## Informations demandées
+
+### Domaine principal
+
+C’est le nom de domaine qui permettra l’accès à votre serveur ainsi qu’au portail d’authentification des utilisateurs. Il sera donc **visible par tout le monde**, choisissez-le en conséquence.
+
+* YunoHost propose un service de DNS dynamique fournissant des noms de domaine de type *mondomaine.nohost.me*, *mondomaine.noho.st* ou *mondomaine.ynh.fr*. Si vous ne possédez pas de nom de domaine et/ou que vous souhaitez profiter de ce service, choisissez un domaine se terminant en `.nohost.me`, `.noho.st` ou `.ynh.fr`. S'il n'est pas déjà utilisé, le domaine sera automatiquement rattaché à votre serveur YunoHost, et vous n’aurez pas d’étape de configuration supplémentaire.
+
+* Si en revanche vous maîtrisez la notion de **DNS**, vous pouvez utiliser votre propre nom de domaine. Dans ce cas, référez-vous à la page [yunohost.org/dns](/dns) pour plus d’informations.
+
+* Si vous n'avez pas de nom de domaine et que vous n'en voulez pas en *mondomaine.nohost.me*, *mondomaine.noho.st* ou *mondomaine.ynh.fr*, vous pouvez utilisez un domaine local. Plus d'infos sur comment [accéder à son serveur depuis le réseau local](/dns_local_network).
+
+
+### Mot de passe d’administration
+
+C’est le mot de passe qui vous permettra d’accéder à l’[interface d’administration](/admin) de votre serveur. Vous pourrez également l’utiliser pour vous connecter à distance via **SSH**, ou en **SFTP** pour transférer des fichiers.
+
+De manière générale, c’est la **clé d’entrée à votre système**, pensez donc à la **[choisir attentivement](http://www.commentcamarche.net/faq/8275-choisir-un-bon-mot-de-passe)**.
+
+
+
+---
+
+## Félicitations !
+
+Si vous arrivez ici après avoir vu "YunoHost a été installé avec succès" depuis
+votre navigateur ou la ligne de commande, alors félicitations !
+
+### Et maintenant ?
+
+- Si vous vous auto-hébergez à la maison et sans VPN, il faut vous assurer
+ de bien [rediriger les ports de votre box internet](/isp_box_config) ;
+- Si vous utilisez votre propre nom de domaine (c.-à-d. pas un nohost.me /
+ noho.st), il vous faut [configurer le nom de domaine d'après la configuration
+ recommandée](/dns_config) ;
+- Si vous ne pouvez pas configurer le nom de domaine pour le moment (parce qu'il
+ n'est pas encore acheté, ou parce que c'est un domaine de test), vous pouvez
+ contourner temporairement le problème avec les instructions du dernier
+ paragraphe [ici](/dns_local_network) ;
+- Ne soyez pas trop effrayé par [l'avertissement à propos du
+ certificat](/certificate), vous aurez probablement la possibilité
+ d'installer un certificat Let's Encrypt :).
+- Jetez un œil aux [applications disponibles](/apps) !
diff --git a/project_budget.md b/project_budget.md
new file mode 100644
index 00000000..7d00f71b
--- /dev/null
+++ b/project_budget.md
@@ -0,0 +1,32 @@
+# Project budget
+
+# Estimated budget for 2020/2021
+
+## Expected revenues
+
+* Donations: 3000€/year
+* Grant from NLNet: 20K€
+
+## Expected expenses
+
+* Development: 20K€
+* Server renting: 500€
+ * VPS Scaleway: 20.33*12: 243.96€/year
+ * VPS Digital O. (forum): 172.80€/year
+* Domain names: ~150€
+ * nohost.me: 11.99€HT/year
+ * ynh.fr: 6.99€HT/year (to be confirmed with frju?)
+ * noho.st: ~35€ TTC/year
+ * YunoHost.org: 13.99€HT/year
+ * YunoHost.com: 9.99€HT/year
+ * labriqueinter.net: 12.49€HT/year
+ * internetcu.be: 17.99€HT/year
+* Communication: ~400€
+* Travel (e.g. to go to conferences): ~700€
+ * AG FFDN 2020: 225€ (en tout)
+ * Event colibris: 150€
+ * FOSDEM ou autre conf: 300€
+* Bank account fees: 7x12€ => ~100€
+* Brique Camp: 500€
+
+**Balance 2020-2021**: +650€
diff --git a/project_budget_fr.md b/project_budget_fr.md
new file mode 100644
index 00000000..608578bf
--- /dev/null
+++ b/project_budget_fr.md
@@ -0,0 +1,35 @@
+# Budget du projet
+
+# Budget prévisionnel pour 2019/2020
+
+## Revenus attendus
+
+* Dons via Liberapay : 3000€
+* Subvention de NLNet : 20K€
+
+## Dépenses prévues
+
+* Developpement : 20K€
+* Location Serveur : ~500 €
+ * VPS Scaleway: 20.33*12: 243.96€/year
+ * VPS Digital O. (forum): 172.80€/year
+* Noms de domaine : ~150 €
+ * nohost.me : 11.99 €HT/ans
+ * ynh.fr : 6.99 €HT/ans (doit être confirmé avec frju ?)
+ * noho.st : ~35 €TTC/ans
+ * yunohost.org : 13.99 €HT/ans
+ * yunohost.com : 9.99 €HT/ans
+ * labriqueinter.net : 12.49 €Ht/ans
+ * internetcu.be : 17.99 €HT/ans
+* Communication : ~400 €
+ * Stickers : 100€
+ * Tracts : 100€
+ * T-shirt : 200€
+* Déplacements (ex. : aller aux conférences) : ~700 €
+ * AG FFDN 2020 : 225€ (en tout)
+ * Event colibris : 150€
+ * FOSDEM ou autre conf : 300€
+* Compte bancaire fees : 7×12 € soit ~100 €
+* Brique Camp : 500€
+
+**Balance 2020-2021** : +650 €
diff --git a/project_organization.md b/project_organization.md
new file mode 120000
index 00000000..c69cb700
--- /dev/null
+++ b/project_organization.md
@@ -0,0 +1 @@
+orga/yunohost_project_organization.md
\ No newline at end of file
diff --git a/project_organization_fr.md b/project_organization_fr.md
new file mode 120000
index 00000000..87648596
--- /dev/null
+++ b/project_organization_fr.md
@@ -0,0 +1 @@
+orga/yunohost_project_organization_fr.md
\ No newline at end of file
diff --git a/registrar.md b/registrar.md
new file mode 100644
index 00000000..dca14d4d
--- /dev/null
+++ b/registrar.md
@@ -0,0 +1,8 @@
+# Registar
+
+Here is a list of Registrars to book domain names:
+* [OVH](http://ovh.com/)
+* [GoDaddy](https://godaddy.com/)
+* [Gandi](http://gandi.net/)
+* [Namecheap](https://www.namecheap.com/)
+* [BookMyName](https://www.bookmyname.com/)
diff --git a/registrar_fr.md b/registrar_fr.md
new file mode 100644
index 00000000..5a72830b
--- /dev/null
+++ b/registrar_fr.md
@@ -0,0 +1,8 @@
+# Bureaux d’enregistrement
+
+Voici une liste des bureaux d’enregistrement pour acheter un nom de domaine :
+* [OVH](http://ovh.com/)
+* [GoDaddy](https://godaddy.com/)
+* [Gandi](http://gandi.net/)
+* [Namecheap](https://www.namecheap.com/)
+* [BookMyName](https://www.bookmyname.com/)
diff --git a/security.md b/security.md
new file mode 100644
index 00000000..7552e072
--- /dev/null
+++ b/security.md
@@ -0,0 +1,180 @@
+# Security
+
+YunoHost has been developed to provide the best security without too much complication. Every protocol used in YunoHost is **encrypted**, only password's hashes are stored and by default each user is able to access their personal directory only.
+
+Two things remain important to note:
+
+* Installing additional apps can **significantly increase** the number of potential security flaws. Do not hesitate to get information about security flaws **before installing an app**, and try to install only apps which will suit your needs.
+
+* The fact that YunoHost is a well-spread software increases the chances of an attack. If a flaw is discovered, it could potentially affect all the YunoHost instances at once. Keep your system **up-to-date** to remain safe.
+
+*If you need advice, do not hesitate to [ask us](/help).*
+
+*To talk about security flaws, contact the [YunoHost security team](/security_team).*
+
+---
+
+## Improve security
+If your YunoHost server is used in a critical production environment, or if you want to improve its safety, you may want to follow those good practices.
+
+**Attention:** *Following those instructions requires advanced knowledge of system administration.*
+
+### SSH authentication via key
+By default, the SSH authentication uses the administration password. Deactivating this kind of authentication and replacing it by a key mechanism is advised.
+
+**On your client**:
+
+```bash
+ssh-keygen
+ssh-copy-id -i ~/.ssh/id_rsa.pub
+```
+
+Type your admnistration password and your key will be copied on your server.
+
+**On your server**, edit the SSH configuration file, in order to deactivate the password authentication.
+
+```bash
+nano /etc/ssh/sshd_config
+
+# Modify or add the following line
+PasswordAuthentication no
+```
+
+Save and restart the SSH daemon.
+```bash
+systemctl restart ssh
+```
+---
+
+### Modify the SSH port
+
+To prevent SSH connection attempts by robots that scan the Internet for any server with SSH enabled, you can change the SSH port.
+
+**On your server**, edit the ssh configuration file, in order to modify the SSH port.
+
+```bash
+nano /etc/ssh/sshd_config
+```
+**Search the line "Port" and replace** port number (by default 22) by another unused number
+```bash
+# What ports, IPs and protocols we listen for
+Port 22 # to replace by 9777 for example
+```
+
+**Open the port** in the firewall (you can use `-6` option to deny ipv4 connection)
+```bash
+yunohost firewall allow TCP 9777
+```
+
+Save and restart the SSH daemon. Switch over to the new port by restarting SSH.
+```bash
+systemctl restart ssh
+```
+Then restart the iptables firewall and close the old port in iptables.
+
+```bash
+yunohost firewall reload
+yunohost firewall disallow TCP # port by default 22
+```
+
+You also need to give `fail2ban` the new SSH port.
+
+To do that you need to create the configuration file `my_ssh_port.conf` with the command
+
+
+```bash
+nano /etc/fail2ban/jail.d/my_ssh_port.conf
+```
+
+and you can then fill it in with
+
+```ini
+[sshd]
+port =
+
+[sshd-ddos]
+port =
+```
+
+Finally you have to restart `fail2ban` in order to apply the new configuration
+
+```bash
+systemctl restart fail2ban
+```
+
+**For the next SSH connections **, you need to add the `-p` option followed by the SSH port number.
+
+**Sample**:
+
+```bash
+ssh -p admin@
+```
+
+---
+
+### Change the user authorized to connect via SSH
+
+To avoid multiple forced login attempts to the admin account by robots, change the authorized user who can connect.
+
+
+In the case of a key authentication, a brute force attack has no chance of succeeding. This step is not really useful in this case.
+
+
+**On your server**, add a user
+```bash
+sudo adduser user_name
+```
+Choose a strong password, since this user will be responsible with obtaining root privileges.
+Add the user to the sudo group to allow them to perform maintenance tasks that require root privileges.
+```bash
+sudo adduser user_name sudo
+```
+
+Now, change the SSH configuration to allow the new user to connect.
+**On your server**, edit the SSH configuration file
+```bash
+sudo nano /etc/ssh/sshd_config
+
+# Look for the section "Authentication" and add at the end of it:
+AllowUsers user_name
+```
+Only users listed in the AllowUsers directive will then be allowed to connect via SSH, which excludes the admin user.
+
+Save and restart the SSH daemon.
+```bash
+systemctl restart ssh
+```
+---
+
+### Change cipher compatibility configuration
+
+The default TLS configuration for services tends to offer good compatibility to support old devices. You can tune this policy for specific services like SSH and NGINX. By default, the NGINX configuration follows the [intermediate compatibility recommendation](https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29) from Mozilla. You can choose to switch to the 'modern' configuration which uses more recent security recommendations, but decreases the compatibility, which may be an issue for your users and visitors using older devices. More details about the compatibility can be found on [this page](https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility).
+
+Changing the compatibility level is not definitive and can be reverted if it doesn't fit with your environment.
+
+**On your server**, change the policy for NGINX
+```bash
+sudo yunohost settings set security.nginx.compatibility -v modern
+```
+
+**On your server**, change the policy for SSH
+```bash
+sudo yunohost settings set security.ssh.compatibility -v modern
+```
+
+### Disable the YunoHost API
+YunoHost administration is accessible through an **HTTP API**, served on the 6787 port by default (only on `localhost`). It can be used to administer a lot of things on your server, so malicious actors can also use it to damage your server. The best thing to do, if you know how to use the [command-line interface](/commandline), is to deactivate the `yunohost-api` service.
+
+```bash
+sudo systemctl disable yunohost-api
+sudo systemctl stop yunohost-api
+```
+
+### YunoHost penetration test
+
+Some [pentests](https://en.wikipedia.org/wiki/Penetration_test) have been done on a YunoHost 2.4 instance (french):
+
+- [1) Preparation](https://exadot.fr/blog/2016-07-03-pentest-dune-instance-yunohost-1-preparation)
+- [2) The functionning](https://exadot.fr/blog/2016-07-12-pentest-dune-instance-yunohost-2-le-fonctionnement)
+- [3) Black Box Audit](https://exadot.fr/blog/2016-08-26-pentest-dune-instance-yunohost-3-audit-en-black-box)
+- [4) Grey Box Audit](https://exadot.fr/blog/2016-11-03-pentest-dune-instance-yunohost-4-audit-en-grey-box)
diff --git a/security_fr.md b/security_fr.md
new file mode 100644
index 00000000..539eed2f
--- /dev/null
+++ b/security_fr.md
@@ -0,0 +1,191 @@
+# Sécurité
+
+YunoHost a été développé dans l’optique de fournir une sécurité maximale tout en restant accessible et facilement installable.
+
+Tous les protocoles que YunoHost utilise sont **chiffrés**, les mots de passe ne sont pas stockés en clair, et par défaut chaque utilisateur n’accède qu’à son répertoire personnel.
+
+Deux points sont néanmoins importants à noter :
+
+* L’installation d’applications supplémentaires **augmente le nombre de failles** potentielles. Il est donc conseillé de se renseigner sur chacune d’elle **avant l’installation**, d’en comprendre le fonctionnement et juger ainsi l’impact que provoquerait une potentielle attaque. N’installez **que** les applications qui semblent importantes pour votre usage.
+
+* Le fait que YunoHost soit un logiciel répandu augmente les chances de subir une attaque. Si une faille est découverte, elle peut potentiellement **toucher toutes les instances YunoHost** à un temps donné. Nous nous efforçons de corriger ces failles le plus rapidement possible, pensez donc à **mettre à jour régulièrement** votre système.
+
+*Si vous avez besoin de conseil, n’hésitez pas à [nous demander](/help).*
+
+*Pour discuter d'une faille de sécurité, contactez l'[équipe sécurité de YunoHost](/security_team).*
+
+---
+
+## Améliorer la sécurité
+
+Si votre serveur YunoHost est dans un environnement de production critique ou que vous souhaitez améliorer sa sécurité, il est bon de suivre quelques bonnes pratiques.
+
+**Attention :** *l’application des conseils suivants nécessite une connaissance avancée du fonctionnement et de l’administration d’un serveur. Pensez à vous renseigner avant de procéder à cette mise en place.*
+
+### Authentification SSH par clé
+
+Voici un [tutoriel plus détaillé](http://doc.ubuntu-fr.org/ssh#authentification_par_un_systeme_de_cles_publiqueprivee).
+
+Par défaut, l’authentification SSH se fait avec le mot de passe d’administration. Il est conseillé de désactiver ce type d’authentification et de le remplacer par un mécanisme de clé de chiffrement.
+
+**Sur votre ordinateur de bureau :**
+
+```bash
+ssh-keygen
+ssh-copy-id -i ~/.ssh/id_rsa.pub
+```
+
+Si vous êtes sur Ubuntu 16.04 vous devez faire `ssh-add` pour initialiser l'agent ssh
+
+
+Entrez le mot de passe d’administration et votre clé publique devrait être copiée sur votre serveur.
+
+**Sur votre serveur**, éditez le fichier de configuration SSH, pour désactiver l’authentification par mot de passe.
+```bash
+nano /etc/ssh/sshd_config
+
+# Modifiez ou ajoutez la ligne suivante
+PasswordAuthentication no
+```
+
+Sauvegardez et relancez le démon SSH.
+```bash
+systemctl restart ssh
+```
+
+---
+
+### Modifier le port SSH
+
+Pour éviter des tentatives de connexion SSH par des robots qui scannent tout Internet pour tenter des connexions SSH avec tout serveur accessible, on peut modifier le port SSH.
+
+**Sur votre serveur**, éditez le fichier de configuration SSH, pour modifier le port SSH.
+
+```bash
+nano /etc/ssh/sshd_config
+```
+
+**Recherchez la ligne « Port »** et remplacez le numéro du port (par défaut 22) par un autre numéro non utilisé
+
+```bash
+Port 22 # à remplacer par exemple par 9777
+```
+
+**Ouvrez le port** choisi dans le parefeu (vous pouvez utiliser l'option `-6` pour interdire la connexion via ipv4)
+
+```bash
+yunohost firewall allow TCP
+```
+
+Sauvegardez et relancez le démon SSH.
+
+```bash
+systemctl restart ssh
+```
+
+Ensuite redémarrez le firewall iptables et fermez l’ancien port dans iptables.
+
+```bash
+yunohost firewall reload
+yunohost firewall disallow TCP # port par défaut 22
+```
+
+Il convient également de donner à `fail2ban` le nouveau port SSH à bloquer en cas de bannissement d'une adresse IP.
+
+Pour cela il suffit de créer le fichier de configuration `my_ssh_port.conf` avec
+
+```bash
+nano /etc/fail2ban/jail.d/my_ssh_port.conf
+```
+
+et de le compléter ainsi :
+
+```ini
+[sshd]
+port =
+```
+
+Il reste enfin à relancer `fail2ban` pour prendre en compte la nouvelle configuration
+
+```bash
+systemctl restart fail2ban
+```
+
+**Pour les prochaines connexions SSH**, il faudra ajouter l’option `-p` suivie du numéro de port SSH.
+
+**Exemple** :
+
+```bash
+ssh -p admin@
+```
+
+---
+
+### Changer l’utilisateur autorisé à se connecter par SSH
+
+Afin d’éviter de multiples tentatives de forçage du login admin par des robots, on peut éventuellement changer l’utilisateur autorisé à se connecter.
+
+
+Dans le cas d’une authentification par clé, la force brute n’a aucune chance de réussir. Cette étape n’est donc pas vraiment utile dans ce cas
+
+
+**Sur votre serveur**, ajoutez un utilisateur.
+```bash
+sudo adduser nom_utilisateur
+```
+Choisissez un mot de passe fort, puisque c’est l’utilisateur qui sera chargé d’obtenir des droits root.
+Ajoutez l’utilisateur au groupe sudo, afin justement de l’autoriser à effectuer des tâches de maintenance nécessitant les droits root.
+```bash
+sudo adduser nom_utilisateur sudo
+```
+
+À présent, modifiez la configuration SSH pour autoriser ce nouvel utilisateur à se connecter.
+**Sur votre serveur**, éditez le fichier de configuration SSH
+```bash
+sudo nano /etc/ssh/sshd_config
+
+# Recherchez le paragraphe « Authentication » et ajoutez à la fin de celui-ci :
+AllowUsers nom_utilisateur
+```
+Seuls les utilisateurs mentionnés dans la directive AllowUsers seront alors autorisés à se connecter via SSH, ce qui exclut donc l’utilisateur admin.
+
+Sauvegardez et relancez le démon SSH.
+```bash
+systemctl restart ssh
+```
+
+---
+
+### Durcir la sécurité de la configuration des services
+
+La configuration TLS par défaut des services tend à offrir une bonne compatibilité avec les vieux appareils. Vous pouvez régler cette politique pour les services SSH et NGINX. Par défaut, la configuration du NGINX suit la [recommandation de compatibilité intermédiaire](https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29) de Mozilla. Vous pouvez choisir de passer à la configuration "moderne" qui utilise des recommandations de sécurité plus récentes, mais qui diminue la compatibilité, ce qui peut poser un problème pour vos utilisateurs et visiteurs qui utilisent de vieux appareils. Plus de détails peuvent être trouvés sur [cette page](https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility).
+
+Changer le niveau de compatibilité n'est pas définitif et il est possible de rechanger le paramètre si vous concluez qu'il faille revenir en arrière.
+
+**Sur votre serveur**, modifiez la politique pour NGINX :
+```bash
+sudo yunohost settings set security.nginx.compatibility -v modern
+```
+
+**Sur votre serveur**, modifiez la politique pour SSH :
+```bash
+sudo yunohost settings set security.ssh.compatibility -v modern
+```
+
+### Désactivation de l’API YunoHost
+
+YunoHost est administrable via une **API HTTP**, servie sur le port 6787 par défaut (seulement sur `localhost`). Elle permet d’administrer une grande partie de votre serveur, et peut donc être utilisée à des **fins malveillantes**. La meilleure chose à faire si vous êtes habitués aux lignes de commande est de désactiver le service `yunohost-api`, et **utiliser la [ligne de commande](/commandline)** en SSH.
+
+```bash
+sudo systemctl disable yunohost-api
+sudo systemctl stop yunohost-api
+```
+
+### Tests d’intrusion de YunoHost
+
+Des [pentests](https://fr.wikipedia.org/wiki/pentest) ont été effectués sur une instance de YunoHost 2.4 :
+
+- [1) Préparation](https://exadot.fr/blog/2016-07-03-pentest-dune-instance-yunohost-1-preparation)
+- [2) Le fonctionnement](https://exadot.fr/blog/2016-07-12-pentest-dune-instance-yunohost-2-le-fonctionnement)
+- [3) Audit en Black Box](https://exadot.fr/blog/2016-08-26-pentest-dune-instance-yunohost-3-audit-en-black-box)
+- [4) Audit en Grey Box](https://exadot.fr/blog/2016-11-03-pentest-dune-instance-yunohost-4-audit-en-grey-box)
diff --git a/security_team.md b/security_team.md
new file mode 100644
index 00000000..a0e1686f
--- /dev/null
+++ b/security_team.md
@@ -0,0 +1,15 @@
+# Security team
+
+Contact the security team by mail: `security@yunohost.org`.
+
+We strongly advise you to encrypt your mail with GPG. Our public key is available on key servers. Below is our fingerprint
+
+```bash
+gpg --fingerprint security@yunohost.org
+pub 4096R/17351899 2016-07-01
+ Empreinte de la clef = 6CBC 45EB A625 FBF3 513D 1227 749D 8972 1735 1899
+uid YunoHost Security
+sub 4096R/446838AF 2016-07-01
+```
+
+See https://gist.github.com/opi/4496024dc3ff29ab2e068fd57092ab7c or https://twitter.com/yunohost/status/748975105393459200 for other trustable fingerprints
\ No newline at end of file
diff --git a/security_team_fr.md b/security_team_fr.md
new file mode 100644
index 00000000..a3ae1720
--- /dev/null
+++ b/security_team_fr.md
@@ -0,0 +1,16 @@
+# Équipe sécurité
+
+Contactez l'équipe sécurité par email : `security@yunohost.org`.
+
+Nous vous recommandons fortement de chiffrer votre mail avec GPG. Notre clé
+publique est disponible sur les serveurs de clés. L'empreinte est ci-dessous :
+
+```bash
+gpg --fingerprint security@yunohost.org
+pub 4096R/17351899 2016-07-01
+ Empreinte de la clef = 6CBC 45EB A625 FBF3 513D 1227 749D 8972 1735 1899
+uid YunoHost Security
+sub 4096R/446838AF 2016-07-01
+```
+
+Voyez https://gist.github.com/opi/4496024dc3ff29ab2e068fd57092ab7c et https://twitter.com/yunohost/status/748975105393459200 pour d'autres empreintes de confiance
diff --git a/selfhosting.md b/selfhosting.md
new file mode 100644
index 00000000..2ab4f82c
--- /dev/null
+++ b/selfhosting.md
@@ -0,0 +1,25 @@
+# Self-hosting
+
+Self-hosting is the activity of having and administrating your own server, typically at home, to host your personal data and services yourself instead of relying exclusively on third-parties. For instance, you can self-host your blog, such that it 'lives' on a machine that you have control of, instead of having it on somebody else's computer (a.k.a. The Cloud) in exchange for money, advertisement or private data.
+
+Self-hosting implies owning a server. A server is a computer which is typically accessible on the network 24/7, and usually does not have any screen or keyboard (it is instead controlled remotely). Contrarily to a popular belief, a server is not necessarily a huge and extra-powerful machine: nowadays, a small, ~$30 ARM board is adequate for self-hosting.
+
+Self-hosting is not about making "your Internet" more secure and does not provide anonymity by itself. Instead, it is about being autonomous, and in control of your services and data - which also means being responsible for them.
+
+## Why should you host yourself ?
+
+- **You believe in a free, open and decentralized internet.** In a centralized internet, private companies and government can spy, analyze and influence people by dictating how they connect with each other, and by filtering content. YunoHost is developed by a community who believe in an open and decentralized internet, and we hope that you do, too!
+
+- **You want to have control of your data and services.** Your pictures, chat messages, browsing history, and that text you are writing for school, have nothing to do on somebody else's server (a.k.a. The Cloud). They are part of your private life, but also part of your family's life, your friend's life, and so on. These data should be managed by *you*, not a random company in the US who wants your data to analyze them and sell the results.
+
+- **You want to learn about how computers and the Internet work.** Operating your own server is a pretty good context to understand the basic mechanisms at the heart of operating systems and the Internet. You might have to deal with command line interface, network architecture, DNS configuration, SSH, and so on.
+
+- **You want to explore new possibilities and customize things.** Ever dreamed of running a Minecraft server for you friends, or a persistent IRC or XMPP client? With your very own server, you can manually install and run virtually any program you want, and customize every bit.
+
+## Why should you *not* host yourself ?
+
+- **Self-hosting requires some work and patience.** Hosting yourself is a bit like growing your own garden or vegetables: it requires work and patience. While YunoHost aims to do all the hard work for you, self-hosting still requires that you take time to learn and configure a few things to setup your server properly. You will also need to perform maintenance tasks (such as upgrades) from time to time, or to ask for support if some things break.
+
+- **With great servers comes great responsibilities.** Operating a server means that you are responsible for the data you are hosting. Nobody will be able to recover them for you if they get lost. YunoHost provides backup features, which you should use regularly to backup the configurations and data you care about. You should also keep an eye on security news and recommendations so that your server or critical data don't get compromised.
+
+- **Quality and performance probably won't be as good as premium services.** YunoHost (and most of the applications packaged for it) are free and open-source software, developed by communities of people in their free time and on the basis of best effort. There is no absolute guarantee that software will work in every possible circumstance. The performance of your self-hosted server is also related to its CPU and RAM, and to the available internet connectivity.
diff --git a/selfhosting_de.md b/selfhosting_de.md
new file mode 100644
index 00000000..4272963c
--- /dev/null
+++ b/selfhosting_de.md
@@ -0,0 +1,26 @@
+# Self-Hosting
+
+Self-Hosting ist das Hosten von Daten oder Software auf eigener IT-Infrastruktur.
+Ihren eigenen Server zu Hause zu haben und zu verwalten, um Ihre persönlichen Daten und Dienste selbst zu hosten, anstatt sich ausschließlich auf Dritte zu verlassen. Beispielsweise können Sie Ihren Blog selbst hosten, sodass er auf einem Computer "lebt", über den Sie die Kontrolle haben, anstatt ihn im Austausch gegen Geld, Werbung oder private Daten auf dem Computer eines anderen Benutzers (a.k.a. The Cloud) zu haben.
+
+Self-Hosting bedeutet, einen Server zu besitzen. Ein Server ist ein Computer, auf den in der Regel rund um die Uhr im Netzwerk zugegriffen werden kann und der normalerweise keinen Bildschirm oder keine Tastatur hat (stattdessen wird er ferngesteuert). Entgegen der landläufigen Meinung ist ein Server nicht unbedingt ein riesiger und besonders leistungsfähiger Computer: Heutzutage ist ein kleines Board (Einplatinencomputer) mit ~ 40 € für das Self-Hosting ausreichend.
+
+Beim Self-Hosting geht es nicht darum, "Ihr Internet" sicherer zu machen, und es bietet auch keine Anonymität an sich. Stattdessen geht es darum, autonom zu sein und Ihre Dienste und Daten zu kontrollieren - was auch bedeutet, dafür verantwortlich zu sein.
+
+## Warum sollten Sie selbst hosten?
+
+- **Sie glauben an ein freies, offenes und dezentrales Internet.** In einem zentralisierten Internet können private Unternehmen und Behörden Personen ausspähen, analysieren und beeinflussen, indem sie diktieren, wie Sie sich miteinander verbinden, und indem sie Inhalte filtern. YunoHost wird von einer Community entwickelt, die an ein offenes und dezentrales Internet glaubt, und wir hoffen, dass Sie dies auch tun!
+
+- **Sie möchten die Kontrolle über Ihre Daten und Dienste haben.** Ihre Bilder, Chatnachrichten, der Browserverlauf und der Text, den Sie für die Schule schreiben, haben auf dem Server eines anderen Benutzers (a.k.a. The Cloud) nichts zu suchen. Sie sind Teil Ihres Privatlebens, aber auch Teil des Lebens Ihrer Familie, Ihres Partners und so weiter. Diese Daten sollten von * Ihnen * verwaltet werden, nicht von einem zufälligen Unternehmen in den USA, dass Ihre Daten analysieren und die Ergebnisse verkaufen möchte.
+
+- **Sie möchten lernen, wie Computer und das Internet funktionieren.** Der Betrieb eines eigenen Servers ist ein guter Kontext, um die grundlegenden Mechanismen von Betriebssystemen und dem Internet zu verstehen. Möglicherweise müssen Sie sich mit der Befehlszeilenschnittstelle, der Netzwerkarchitektur, der DNS-Konfiguration und mit SSH usw. befassen.
+
+- **Sie möchten neue Möglichkeiten erkunden und Dinge anpassen.** Haben Sie jemals davon geträumt, einen Minecraft-Server für Ihre Freunde oder einen dauerhaften IRC- oder XMPP-Client zu betreiben? Mit Ihrem eigenen Server können Sie praktisch jedes gewünschte Programm manuell installieren, ausführen und jedes Bit anpassen.
+
+## Warum Sie vllt. *nicht* selbst hosten sollten?
+
+- **Self-Hosting erfordert etwas Arbeit und Geduld.** Selbst einen Server zu betreiben, ist ein bisschen wie das anlegen eines eigenen Gartens oder der anbau von Gemüse: Es erfordert Arbeit und Geduld. Während YunoHost versucht, die harte Arbeit für Sie zu erledigen, müssen Sie sich für das Self-Hosting noch einige Zeit nehmen, um einige Dinge zu lernen und zu konfigurieren, um Ihren Server richtig einzurichten. Sie müssen auch von Zeit zu Zeit Wartungsaufgaben (wie z. B. Upgrades) ausführen oder um Support-Unterstützung bitten, wenn Probleme auftreten.
+
+- **Mit den eigenen tollen Servern geht eine große Verantwortung einher.** Der Betrieb eines Servers bedeutet, dass Sie für die von Ihnen gehosteten Daten verantwortlich sind. Niemand kann sie für Sie wiederherstellen, wenn sie verloren gehen. YunoHost bietet Sicherungsfunktionen, die Sie regelmäßig verwenden sollten, um die gewünschten Konfigurationen und Daten zu sichern. Sie sollten auch die Sicherheitsnachrichten und -empfehlungen im Auge behalten, damit Ihr Server oder Ihre kritischen Daten nicht gefährdet werden.
+
+- **Qualität und Leistung sind wahrscheinlich nicht so gut wie Premium-Services.** YunoHost (und die meisten dafür bereitgestellten Anwendungen) sind kostenlose und Open-Source-Software, die in den jeweiligen Communitys von Menschen in ihrer Freizeit und auf der Grundlage bester Bemühungen entwickelt werden. Es gibt keine absolute Garantie dafür, dass Software unter allen möglichen Umständen funktioniert. Die Leistung Ihres selbst gehosteten Servers hängt auch von dessen CPU und RAM sowie der verfügbaren Internetverbindung ab.
diff --git a/selfhosting_fr.md b/selfhosting_fr.md
new file mode 100644
index 00000000..86b40080
--- /dev/null
+++ b/selfhosting_fr.md
@@ -0,0 +1,25 @@
+# L’auto-hébergement
+
+L'auto-hébergement est le fait d'avoir et d'administrer son propre serveur, typiquement chez soi, pour héberger soi-même ses données personnelles et des services plutôt que de se reposer exclusivement sur des tiers. Par exemple, il est possible d'auto-héberger son blog de sorte qu'il "vive" dans une machine que vous contrôlez, au lieu qu'il soit sur l'ordinateur de quelqu'un d'autre (a.k.a. le Cloud) en échange d'argent, de publicités ou de données privées.
+
+L'auto-hébergement implique de disposer d'un serveur. Un serveur est un ordinateur qui est destiné à être accessible sur le réseau en permanence, et n'a généralement pas d'écran ni de clavier puisqu'il est administré à distance. Contrairement à une croyance répandue, les serveurs ne sont pas nécessairement des machines énormes et extrêmement puissantes: aujourd'hui, une petite carte ARM à ~30€ est adéquate pour de l'auto-hébergement.
+
+Pratiquer l'auto-hébergement ne rend pas "votre internet" plus sécurisé et ne fournit pas d'anonymat en tant que tel. L'objectif est généralement de pouvoir être autonome et au contrôle de ses services et de ses données - ce qui implique aussi d'en être responsable.
+
+## Pourquoi s'auto-héberger ?
+
+- **Vous croyez en un internet libre, ouvert et décentralisé.** Dans un internet centralisé, les entités privées et les gouvernement peuvent espionner, analyser et influencer les personnes en dictant la façon dont elle peuvent interagir les unes avec les autres, ainsi qu'en filtrant du contenu. YunoHost est développé par une communauté qui croit en un internet ouvert et décentralisé. Nous espérons que vous aussi !
+
+- **Vous voulez avoir le contrôle de vos données et services.** Vos images, vos messages de chat, votre historique de navigation, et votre dissertation pour l'école n'ont rien à faire sur l'ordinateur de quelqu'un d'autre (a.k.a. le Cloud). Ces données font parties de votre vie privée, mais également de celle de votre famille, de vos amis, etc. Ces données devraient être gérées par *vous*, et non par une quelconque entreprise américaine qui cherche à analyser vos données pour revendre les résultats.
+
+- **Vous souhaitez apprendre comment fonctionnent les ordinateurs et Internet.** Opérer son propre serveur est un bon contexte pour apprendre les mécanismes de base au cœur des systèmes d'exploitations (OS) et d'Internet. Il vous faudra possiblement toucher à la ligne de commande et à des morceaux de configuration réseau et DNS.
+
+- **Vous voulez explorer de nouvelles possibilités et personnaliser votre espace.** Avez-vous déjà rêvé d'avoir votre propre serveur Minecraft pour vos ami·e·s, ou un client IRC ou XMPP persistent ? Avec votre propre serveur, vous pouvez manuellement installer et faire tourner n'importe quel programme et personnaliser chaque morceau.
+
+## Pourquoi ne *pas* s'auto-héberger ?
+
+- **L'auto-hébergement requiert du travail et de la patience.** S'auto-héberger est un peu comme avoir son propre jardin ou potager : cela demande du travail et de la patience. Bien que YunoHost cherche à faire tout le travail compliqué pour vous, il vous faudra tout de même prendre le temps d'apprendre et configurer quelques détails pour que votre installation marche correctement. Il vous faudra aussi gérer quelques tâches de maintenance (telles que les mises à jour) de temps en temps, et demander de l'aide si des choses ne fonctionnent pas comme prévu.
+
+- **Avec de grands serveurs viennent les grandes responsabilités.** Opérer un serveur implique d'être responsable des données que vous hébergez : personne ne pourra récupérer des données à votre place si vous les perdez. YunoHost fournit des fonctionnalités de sauvegarde qu'il est recommandé d'utiliser pour sauvegarder les configurations et données importantes. Il vous faut aussi garder un œil sur les recommandations et les nouvelles à propos de la sécurité pour que votre serveur ou vos données ne soient pas compromises.
+
+- **La qualité et les performances ne seront probablement pas aussi bonnes que des services premium.** YunoHost (et la plupart des applications qui sont packagées) sont des logiciels libres et open-source, développés par des communautés bénévoles. Il n'y a pas de garantie absolue que ces logiciels marcheront dans toutes les circonstances possibles. Les performances de votre serveur auto-hébergé sont aussi liées au processeur, à la mémoire vive et à la connectivité internet.
diff --git a/selfhosting_ru.md b/selfhosting_ru.md
new file mode 100644
index 00000000..ec11365b
--- /dev/null
+++ b/selfhosting_ru.md
@@ -0,0 +1,43 @@
+# Самостоятельное развертывание (свой хостинг)
+
+#### Значение
+**Свой хостинг** - это сервер, расположенный у вас дома и предназначенный для размещения информации для личных нужд.
+
+#### Обязанности администратора
+Свой хостинг создает для вас определенные обязанности, если вы хотите разместить на нём сайт, [e-mail](/email), а также запустить [систему мгновенных сообщений](XMPP), ваш сервер должен работать и оставаться онлайн 24/7.
+
+Распространенные проблемы, по причине которых сервер может быть недоступен включают в себя: отсутствие электроэнергии, потеря доступа к Интернету, итд.
+
+К примеру, если вы используете [e-mail](/email) и ваш сервер по какой-то причине становится недоступен, отправленные на него сообщения будут отправлены снова только по прошествии от 3 до 7 дней.
+
+#### Минусы своего хостинга
+* Медленная передача данных. При использовании ADSL, скорость загрузки составляет 1/10 от скорости закачки. К примеру при скорости загрузки 1Мб/с скорость загрузки будет около 100Кб/с;
+* Сервер должен быть доступен 24/7;
+* Перенос данных;
+
+#### Плюсы своего хостинга
+* Анонимность, приватность;
+* Вы - единственный хозяин ваших данных и сервисов;
+* Возможность децентрализации и использования распределенных сетей;
+
+
+
+#### Другие проекты, предназначенные для самостоятельного развертывания
+##### В активной разработке
+- [Cloudron](https://cloudron.io)
+- [Cozy](https://cozy.io)
+- [FreedomBox](https://wiki.debian.org/FreedomBox)
+- [Libre.sh](https://github.com/indiehosters/libre.sh)
+- [Puffin](http://puffin.rocks)
+- [Sandstorm](https://sandstorm.io/)
+- [Sovereign](https://github.com/al3x/sovereign)
+- [UBOS](http://ubos.net)
+
+##### Неподдерживаемые
+- [ArkOS](http://web.archive.org/web/20170603213149/https://arkos.io/)
+- [Host@home](http://web.archive.org/web/20160206150730/http://yeuxdelibad.net/Programmation/Hostathome.html)
+
+
+#### Узнать больше
+* [Decentralized Web Summit](http://www.decentralizedweb.net/)
+* [Feudal Security](https://www.schneier.com/blog/archives/2012/12/feudal_sec.html) Bruce Schneier, famous security expert exposes the risks of a centralized web and the importance of civic action.
diff --git a/shell_variables_scope.md b/shell_variables_scope.md
new file mode 100644
index 00000000..aba9d163
--- /dev/null
+++ b/shell_variables_scope.md
@@ -0,0 +1,219 @@
+### General scope of variables
+
+Variables exists for the current shell and its children only.
+Another script executed from the script is not a child, it's another shell which herited only the environment variables from its caller script, not its globals or locals variables.
+
+When a script is called, it isn't started in the current shell, but in a new instance of bash which herite environment variables from its parent.
+```bash
+var1=value1
+export var2=value2
+
+echo "$var1"
+echo "$var2"
+# var1 and var2 exist
+
+echo "-"
+
+echo "
+echo \"\$var1\"
+echo \"\$var2\"" > other_script.sh
+chmod +x other_script.sh
+./other_script.sh
+# Here, var1 doesn't exist, only var2 still exists.
+# Because it's an environment variable.
+```
+In your current shell, where you launch this script, try
+```bash
+echo $var1 - $var2
+```
+None of this 2 variables exists, because their scope is limited to the script itself. Never its parent.
+
+
+### Functions inside a script
+
+Use a function would not change the scope of variables.
+```bash
+var1=value1
+export var2=value2
+
+set_variable () {
+ var3=value3
+ export var4=value4
+
+ echo "$var1"
+ echo "$var2"
+ echo "$var3"
+ echo "$var4"
+ # All variables exists here
+ # Because the function inherite its variables from the script.
+}
+
+set_variable
+
+echo "$var1"
+echo "$var2"
+echo "$var3"
+echo "$var4"
+# var1 var2, var3 and var4 exist
+# var3 exist because the function is executed in the same shell than the script itself.
+
+echo "-"
+
+echo "
+echo \"\$var1\"
+echo \"\$var2\"
+echo \"\$var3\"
+echo \"\$var4\"" > other_script.sh
+chmod +x other_script.sh
+./other_script.sh
+# Here, var1 and var3 don't exist, only var2 and var4 still exist.
+# Because they're environment variables.
+```
+
+### The usage of locales variables
+
+Locales variables are limited to the function and its children.
+```bash
+var1=value1
+export var2=value2
+
+set_variable () {
+ var3=value3
+ export var4=value4
+ local var5=value5
+
+ echo "$var1"
+ echo "$var2"
+ echo "$var3"
+ echo "$var4"
+ echo "$var5"
+ # All variables exists here
+ # Because the function inherite its variables from the script.
+}
+
+set_variable
+
+echo "-"
+
+echo "$var1"
+echo "$var2"
+echo "$var3"
+echo "$var4"
+echo "$var5"
+# var1 var2, var3 and var4 exist
+# var3 exist because the function is executed in the same shell than the script itself.
+# var5 doesn't exist, because its scope is limited to the function which declare it.
+
+echo "-"
+
+echo "
+echo \"\$var1\"
+echo \"\$var2\"
+echo \"\$var3\"
+echo \"\$var4\"
+echo \"\$var5\"" > other_script.sh
+chmod +x other_script.sh
+./other_script.sh
+# Here, var1, var3 and var5 don't exist, only var2 and var4 still exist.
+# Because they're environment variables.
+```
+
+Using a local variable is usefull for limit it scope to the function only. And not bother the script in its globality with useless variables.
+But there's also another advantage with local variable, do not modify the content of a global variable.
+```bash
+var1=value1
+var2=value2
+var3=value3
+
+set_variable () {
+ echo "$var1"
+ echo "$var2"
+ echo "$var3"
+
+ echo "-"
+
+ var2=new_value2
+ local var3=new_value3
+
+ echo "$var1"
+ echo "$var2"
+ echo "$var3"
+ # Values of var2 and var3 are modified in the function.
+}
+
+set_variable
+
+echo "-"
+
+echo "$var1"
+echo "$var2"
+echo "$var3"
+# var3 retake is original value,
+# because in the function, var3 was declared as a new locale variable.
+# But var2 was directly modified, so its value still changed.
+# Because, var2 in the function is still a global variable.
+```
+
+As seen previously, modified or created variables in a function can affect the main script because the function is executed in the same shell.
+But, the things are different if the function is executed in a sub shell, the function become a child which only inherite from its parent.
+```bash
+var1=value1
+var2=value2
+var3=value3
+
+fonction2 () {
+ echo "-"
+ echo "var1=$var1"
+ echo "var2=$var2"
+ echo "var3=$var3"
+ echo "var4=$var4"
+ echo "var5=$var5"
+ # Even var3, which is local, is inherited from the parent function.
+}
+
+set_variable () {
+ echo "var1=$var1"
+ echo "var2=$var2"
+ echo "var3=$var3"
+ # Variables are inherited from the parent.
+
+ echo "-"
+
+ var2=new_value2
+ local var3=new_value3
+ var4=new_value4
+ export var5=new_value5
+
+ echo "var1=$var1"
+ echo "var2=$var2"
+ echo "var3=$var3"
+ echo "var4=$var4"
+ echo "var5=$var5"
+ # Values of var2 and var3 are modified in the function.
+
+ (fonction2)
+}
+
+(set_variable)
+# Start the function in a sub shell.
+
+echo "-"
+
+echo "var1=$var1"
+echo "var2=$var2"
+echo "var3=$var3"
+echo "var4=$var4"
+echo "var5=$var5"
+# var2 and var3 retake their original values.
+# Because the function is in a child shell which never affect its parent.
+# Likewise, var4 and var5 don't exist, because they're been declared in child shell.
+# The parent never inherite from its children shell.
+```
+
+### Conclusion
+
+- The scope of a variable is always the current shell and its children, never its parent shell.
+- An environment variable may be exported to a new shell, detached from the first one. If the last one executed the second one. But, it can't affect the parents.
+- A locale variable in a function, executed in the current shell, can't affect the environment outside of the function. End allow also to not affect a global variable with the same name.
+- A function executed in a sub shell will never affect its parent, with global or local variables.
+- A parent can NEVER be affected by variables defined or modified in its children shell.
diff --git a/shell_variables_scope_fr.md b/shell_variables_scope_fr.md
new file mode 100644
index 00000000..179f3252
--- /dev/null
+++ b/shell_variables_scope_fr.md
@@ -0,0 +1,219 @@
+### Portée générales des variables
+
+Les variables existent pour le shell courant et ses enfants uniquement.
+Un script exécuté depuis le script n'est pas un enfant, c'est un autre shell qui n'héritera que des variables d'environnement du script appelant, pas des variables globales ou locales.
+
+Lors de l'appel d'un script, il n'est pas démarré dans le shell courant, mais dans une nouvelle instance de bash qui hérite des variables d'environnements de son parent.
+```bash
+var1=value1
+export var2=value2
+
+echo "$var1"
+echo "$var2"
+# var1 et var2 existent
+
+echo "-"
+
+echo "
+echo \"\$var1\"
+echo \"\$var2\"" > other_script.sh
+chmod +x other_script.sh
+./other_script.sh
+# Ici, var1 n'existe pas, seul var2 existe encore.
+# Car c'est une variable d'environnement.
+```
+Dans le shell courant, d'où le script est appelé, faite
+```bash
+echo $var1 - $var2
+```
+Aucune des 2 variables n'existent, car leur portée se limite au script appelé. Jamais au parent.
+
+
+### Les fonctions dans un script
+
+Utiliser une fonction ne change pas la portée des variables.
+```bash
+var1=value1
+export var2=value2
+
+set_variable () {
+ var3=value3
+ export var4=value4
+
+ echo "$var1"
+ echo "$var2"
+ echo "$var3"
+ echo "$var4"
+ # Toutes les variables existent ici
+ # car la fonction hérite des variables du script.
+}
+
+set_variable
+
+echo "$var1"
+echo "$var2"
+echo "$var3"
+echo "$var4"
+# var1 var2, var3 et var4 existent
+# var3 existe car la fonction est exécutée dans le même shell que le script lui-même.
+
+echo "-"
+
+echo "
+echo \"\$var1\"
+echo \"\$var2\"
+echo \"\$var3\"
+echo \"\$var4\"" > other_script.sh
+chmod +x other_script.sh
+./other_script.sh
+# Ici, var1 et var3 n'existent pas, seul var2 et var4 existe encore.
+# Car ce sont des variables d'environnements.
+```
+
+### L'usage des variables locales
+
+Les variables locales sont limitées à une fonction et ses enfants
+```bash
+var1=value1
+export var2=value2
+
+set_variable () {
+ var3=value3
+ export var4=value4
+ local var5=value5
+
+ echo "$var1"
+ echo "$var2"
+ echo "$var3"
+ echo "$var4"
+ echo "$var5"
+ # Toutes les variables existent ici
+ # car la fonction hérite des variables du script.
+}
+
+set_variable
+
+echo "-"
+
+echo "$var1"
+echo "$var2"
+echo "$var3"
+echo "$var4"
+echo "$var5"
+# var1 var2, var3 et var4 existent
+# var3 existe car la fonction est exécutée dans le même shell que le script lui-même.
+# var5 n'existe pas, car sa portée se limite à la fonction qui l'a déclaré
+
+echo "-"
+
+echo "
+echo \"\$var1\"
+echo \"\$var2\"
+echo \"\$var3\"
+echo \"\$var4\"
+echo \"\$var5\"" > other_script.sh
+chmod +x other_script.sh
+./other_script.sh
+# Ici, var1, var3 et var5 n'existent pas, seul var2 et var4 existe encore.
+# Car ce sont des variables d'environnements.
+```
+
+L'intérêt d'utiliser une variable locale est donc de limiter cette variable à la seule fonction qui l'a déclaré. Et donc ne pas polluer le script dans sa globalité avec des variables inutile pour ce dernier.
+Il existe également un second avantage à l'usage d'une variable locale, c'est de ne pas modifier le contenu d'une variable globale.
+```bash
+var1=value1
+var2=value2
+var3=value3
+
+set_variable () {
+ echo "$var1"
+ echo "$var2"
+ echo "$var3"
+
+ echo "-"
+
+ var2=new_value2
+ local var3=new_value3
+
+ echo "$var1"
+ echo "$var2"
+ echo "$var3"
+ # La valeurs de var2 et var3 sont modifiées dans la fonction
+}
+
+set_variable
+
+echo "-"
+
+echo "$var1"
+echo "$var2"
+echo "$var3"
+# var3 a repris sa valeur initiale,
+# car dans la fonction var3 a été déclaré comme une nouvelle variable locale.
+# Mais var2 a été modifiée directement, donc sa valeur reste modifiée.
+# Car var2 dans la fonction est resté une variable globale.
+```
+
+Comme vu précédemment, les variables modifiée ou créée dans la fonction affecte le script car la fonction est exécutée dans le même shell que celui-ci.
+Cela change si on exécute la fonction dans un sous-shell, la fonction devient un enfant qui hérite de son parent uniquement.
+```bash
+var1=value1
+var2=value2
+var3=value3
+
+fonction2 () {
+ echo "-"
+ echo "var1=$var1"
+ echo "var2=$var2"
+ echo "var3=$var3"
+ echo "var4=$var4"
+ echo "var5=$var5"
+ # Même var3, qui est locale, est héritée par la fonction enfant.
+}
+
+set_variable () {
+ echo "var1=$var1"
+ echo "var2=$var2"
+ echo "var3=$var3"
+ # Les variables sont héritées du parent.
+
+ echo "-"
+
+ var2=new_value2
+ local var3=new_value3
+ var4=new_value4
+ export var5=new_value5
+
+ echo "var1=$var1"
+ echo "var2=$var2"
+ echo "var3=$var3"
+ echo "var4=$var4"
+ echo "var5=$var5"
+ # La valeurs de var2 et var3 sont modifiées dans la fonction
+
+ (fonction2)
+}
+
+(set_variable)
+# Démarre la fonction dans un shell fils.
+
+echo "-"
+
+echo "var1=$var1"
+echo "var2=$var2"
+echo "var3=$var3"
+echo "var4=$var4"
+echo "var5=$var5"
+# var2 et var3 ont repris leur valeurs initiales,
+# Car la fonction est dans un shell enfant qui n'affecte pas son parent.
+# De même, var4 et var5 n'existent pas, car elle sont déclarées dans un shell enfant.
+# Le parent n'hérite pas des shells enfants.
+```
+
+### Conclusion
+
+- La portée d'une variable est toujours le shell courant et ses enfants, jamais son shell parent.
+- Une variable d'environnement peut être exportée sur un nouveau shell, indépendant du premier. À condition que ce dernier exécute le second. Mais ne peut pas affecter les parents.
+- Une variable locale dans une fonction, exécutée dans le shell courant, n'affecte pas son environnement en dehors de la fonction. Et permet également de ne pas affecter le contenu d'une variable globale de même nom.
+- Une fonction exécutée dans un sous-shell n'affecte jamais le parent, que ses variables soient globales ou locales.
+- Le parent n'est JAMAIS affecté par les variables définies ou modifiées par ses shells enfants.
diff --git a/sponsors_partners.md b/sponsors_partners.md
new file mode 100644
index 00000000..640ff41b
--- /dev/null
+++ b/sponsors_partners.md
@@ -0,0 +1,15 @@
+# Sponsors and partners
+
+In order to advance and make the project works, in addition to the work of volunteers and donations, YunoHost benefits from the support of sponsors and partners.
+
+Here is a list of YunoHost sponsors, providing infrastructure and services to the project:
+- [GITOYEN](https://gitoyen.net): association bringing together several companies and associations acting as a provider of hosting infrastructure and Internet access.
+- [GLOBENET](http://www.globenet.org): activist association, at the service of freedom of expression, offering internet services.
+- [LDN-NET](https://ldn-fai.net/) : association for the defense of a free, neutral and decentralized Internet whose main means of action is to be an Internet access provider associative and local.
+- [NBS System](https://www.nbs-system.com/): company specialized in hosting, securing Clouds, outsourcing (Information Systems, SaaS Applications, Web Platforms) and managed services.
+- [NLNET](https://nlnet.nl/): The NLnet Foundation supports organizations and people that contribute to an open information society.
+- [TETANEUTRAL-NET](https://tetaneutral.net/): associative Internet access provider currently operating a radio network in Toulouse and its surroundings and a hoster.
+
+Here is a list of YunoHost partners:
+- [FFDN](https://www.ffdn.org/): The FDN federation gathers associative Internet Access Providers who recognize themselves in common values: volunteering, solidarity, democratic functioning and non-profit; defense and promotion of net neutrality.
+- [Framasoft](https://framasoft.org/) : popular education association, a group of friends convinced that an emancipatory digital world is possible, convinced that it will happen thanks to concrete actions on the ground and online with you and for you!
diff --git a/sponsors_partners_fr.md b/sponsors_partners_fr.md
new file mode 100644
index 00000000..72ea6165
--- /dev/null
+++ b/sponsors_partners_fr.md
@@ -0,0 +1,15 @@
+# Mécènes et partenaires
+
+Afin d'avancer et de faire fonctionner le projet, en plus du travail des bénévoles et des dons, YunoHost bénéficie du soutien de mécènes et de partenaires.
+
+Une liste des mécènes de YunoHost, fournissant l'infrastructure et des services aux projets :
+- [GITOYEN](https://gitoyen.net) : association regroupant plusieurs entreprises et associations intervenant comme fournisseur d’infrastructure d’hébergement et d’accès à Internet.
+- [GLOBENET](http://www.globenet.org) : association militante, au service de la liberté d’expression, proposant des services Internet.
+- [LDN-NET](https://ldn-fai.net/) : association pour la défense d’un Internet libre, neutre et décentralisé dont le moyen d’action principale est d’être un fournisseur d’accès Internet (FAI) assocatif et local.
+- [NBS System](https://www.nbs-system.com/): société spécialisée dans l’hébergement, la sécurisation des Clouds, l’infogérance (Systèmes d’information, Applications SaaS, Plateformes web) et les services managés.
+- [NLNET](https://nlnet.nl/) : La Fondation NLnet soutient les organisations et les personnes qui contribuent à une société de l'information ouverte.
+- [TETANEUTRAL-NET](https://tetaneutral.net/) : fournisseur d'accès à Internet associatif opérant actuellement un réseau radio sur Toulouse et ses environs et un hébergeur.
+
+Une liste des partenaires de YunoHost :
+- [FFDN](https://www.ffdn.org/) : La fédération FDN regroupe des Fournisseurs d'Accès à Internet associatifs se reconnaissant dans des valeurs communes : bénévolat, solidarité, fonctionnement démocratique et à but non lucratif ; défense et promotion de la neutralité du Net.
+- [Framasoft](https://framasoft.org/) : association d’éducation populaire, un groupe d’ami·es convaincu·es qu’un monde numérique émancipateur est possible, persuadé·es qu’il adviendra grâce à des actions concrètes sur le terrain et en ligne avec vous et pour vous !
diff --git a/ssh.md b/ssh.md
new file mode 100644
index 00000000..9417769d
--- /dev/null
+++ b/ssh.md
@@ -0,0 +1,89 @@
+# SSH
+
+## What's SSH?
+
+**SSH** stands for Secure Shell, and refers to a protocol that allows to remotely control and administrate a machine using the command line interface (CLI). It is available by default in any terminal on GNU/Linux and macOS. On Windows, you may want to use [MobaXterm](https://mobaxterm.mobatek.net/download-home-edition.html) (after launching it, click on Session then SSH).
+
+## What address to use to connect to your server?
+
+If you are **installing at home** (e.g. on a Raspberry Pi or OLinuXino or old computer):
+ - you should be able to connect to your server using `yunohost.local`.
+ - if `yunohost.local` does not work, your need to [find out the local IP of the server](/finding_the_local_ip).
+ - if you installed a server at home but are attempting to connect from outside your local network, make sure port 22 is correctly forwarded to your server.
+
+If you server is a remote server (VPS), your provider should have communicated you the IP address of the machine
+
+In any cases, if you already configured a domain name pointing to the appropriate IP, it's much better to use `yourdomain.tld` instead of the IP address.
+
+
+## Login credentials
+
+### BEFORE running the post-installation
+
+- If you are **installing at home**, the default credentials are login: `root` and password: `yunohost`
+- If you are **installing a remote server (VPS)**, your provider should have communicated you the login and password (or allowed you to configure an SSH key)
+
+### AFTER running the post-installation
+
+During the postinstall, you've been asked to choose an administration password. This password becomes the new password for the `root` and `admin` users. Additionally, **the `root` SSH login becomes disabled after the postinstall and you should log in using the `admin` user !**. The only exception is that you may still be able to login using `root` *from the local network - or from a direct console on the server* (this is to cover the event where the LDAP server is broken and the `admin` user is unusable).
+
+
+## Connecting
+
+The SSH command typically looks like:
+
+```bash
+# before the postinstall:
+ssh root@11.22.33.44
+
+# or after the postinstall:
+ssh admin@11.22.33.44
+```
+
+Or using the domain name instead of the IP (more convenient):
+
+```bash
+ssh admin@your.domain.tld
+# or with the special .local domain:
+ssh admin@yunohost.local
+```
+
+If you changed the SSH port, you need to add `-p ` to the command, e.g.:
+
+```bash
+ssh -p 2244 admin@your.domain.tld
+```
+
+
+If you connected as `admin` and would like to become `root` for convenience (e.g. to avoid typing `sudo` in front of every command), you can become `root` using the command `sudo su` or `sudo -i`.
+
+
+## Which other users may connect to the server?
+
+By default, only the `admin` user can log in to YunoHost SSH server.
+
+YunoHost's users created via the administration interface are managed by the LDAP directory. By default, they can't connect via SSH for security reasons. If you want some users to have SSH access enabled, use the command:
+
+```bash
+yunohost user ssh allow
+```
+
+It is also possible to remove SSH access using the following:
+
+```bash
+yunohost user ssh disallow
+```
+
+Finally, it is possible to add, delete and list SSH keys, to improve SSH access security, using the commands:
+
+```bash
+yunohost user ssh add-key
+yunohost user ssh remove-key
+yunohost user ssh list-keys
+```
+
+## Security and SSH
+
+N.B. : `fail2ban` will ban your IP for 10 minutes if you perform 5 failed login attempts. If you need to unban the IP, have a look at the page about [Fail2Ban](/fail2ban)
+
+A more extensive discussion about security & SSH can be found on the [dedicated page](/security).
diff --git a/ssh_de.md b/ssh_de.md
new file mode 100644
index 00000000..c112663e
--- /dev/null
+++ b/ssh_de.md
@@ -0,0 +1,97 @@
+# SSH
+
+## Was ist SSH?
+
+**SSH** steht für **S**ecure **Sh**ell, und bezeichnet ein Protokoll, dass es einem erlaubt über ein entferntes System auf die Kommandozeile (Command Line Interface, **CLI**) zuzugreifen. SSH ist standardmäßig auf jedem Terminal auf GNU/Linux oder macOS verfügbar. Für Windows ist Drittsoftware nötig, z.B. [MobaXterm](https://mobaxterm.mobatek.net/download-home-edition.html) (Klicke nach dem Start auf Session und dann SSH).
+
+## Während der YunoHost Installation
+
+#### Finde deine IP
+
+Solltest du auf einem VPS installieren, dann hat der VPS Provider die IP-Adresse, die du bei ihm erfragen solltest.
+
+Wenn du Zuhause installierst (z.B. auf einem Raspberry Pi oder OLinuXino), dann musst du herausfinden, welche IP-Adresse dein Router dem System zugewiesen hat. Hierfür existieren mehrere Wege:
+- Öffne ein Terminal und tippe `sudo arp-scan --local` ein, um eine Liste der aktiven IP-Adressen deines lokalen Netzwerks anzuzeigen;
+- wenn dir der arp-scan eine zu unübersichtliche Zahl an Adressen anzeigt, versuche mit `nmap -p 22 192.168.**x**.0/24` nur die anzuzeigen, deren SSH-Port 22 offen ist. (passe das **x** deinem Netzwerk an);
+- Prüfe die angezeigten Geräte in der Benutzeroberfläche deines Routers, ob du das Gerät findest;
+- Schließe einen Bildschirm und Tastatur an deinen Server, logge dich ein und tippe `hostname --all-ip-address`.
+
+#### Connect
+
+Assuming your IP address is `111.222.333.444`, open a terminal and enter :
+
+```bash
+ssh root@111.222.333.444
+```
+
+A password will be asked. If this is a VPS, your VPS provided should have communicated you the password. If you used a pre-installed image (for x86 computer or ARM board), the password should be `yunohost`.
+
+
+Since YunoHost 3.4, after running the postinstallation, you won't be able to login as `root` anymore. Instead, **you should login using the `admin` user !** In the event that the LDAP server is broken and the `admin` user is unusable, you may still however still be able to login using `root` from the local network.
+
+
+#### Change the password!
+
+After logging in for the first time, you should change the root password. The server might automatically ask you to do so. If not, use the command `passwd`. It is important to choose a reasonably strong password. Note that the root password will be overriden by the admin password when you perform the postinstallation.
+
+#### Let's configure !
+
+We're now ready to begin the [post-installation](postinstall).
+
+## After installing YunoHost
+
+If you installed your server at home and are attempting to connect from outside your local network, make sure port 22 is correctly forwarded to your server. (Reminder : since YunoHost 3.4 you should connect using the `admin` user !)
+
+If you only know the IP address of your server :
+
+```bash
+ssh admin@111.222.333.444
+```
+
+Then, you need to enter your administrator password created at [post-installation step](postinstall).
+
+If you configured your DNS (or tweaked your `/etc/hosts`), you can simply use your domain name :
+
+```bash
+ssh admin@your.domain.tld
+```
+
+If you changed the SSH port, you need to add `-p ` to the command, e.g. :
+
+```bash
+ssh -p 2244 admin@your.domain.tld
+```
+
+
+If you are connected as `admin` and would like to become `root` for more comfort (e.g. to avoid typing `sudo` in front of every command), you can become `root` using the command `sudo su`.
+
+
+## Which users?
+
+By default, only the `admin` user can log in to YunoHost SSH server.
+
+YunoHost's users created via the administration interface are managed by the LDAP directory. By default, they can't connect via SSH for security reasons. If you want some users to have SSH access enabled, use the command:
+
+```bash
+yunohost user ssh allow
+```
+
+It is also possible to remove SSH access using the following:
+
+```bash
+yunohost user ssh disallow
+```
+
+Finally, it is possible to add, delete and list SSH keys, to improve SSH access security, using the commands:
+
+```bash
+yunohost user ssh add-key
+yunohost user ssh remove-key
+yunohost user ssh list-keys
+```
+
+## Security and SSH
+
+N.B. : `fail2ban` will ban your IP for 10 mimutes if you perform 5 failed login attempts. If you need to unban the IP, have a look at the page about [Fail2Ban](/fail2ban)
+
+A more extensive discussion about security & SSH can be found on the [dedicated page](/security).
diff --git a/ssh_es.md b/ssh_es.md
new file mode 100644
index 00000000..6466fa6c
--- /dev/null
+++ b/ssh_es.md
@@ -0,0 +1,91 @@
+# SSH
+
+## ¿ Qué es SSH ?
+
+**SSH** est un acrónimo por Secure Shell, y representa un protocolo que permite controlar remotamente una máquina vía la línea de comandos (CLI). También es un comando básico disponible en los terminales de GNU/Linux y macOS. En Windows, hace falta utilizar el programa [MobaXterm](https://mobaxterm.mobatek.net/download-home-edition.html) (después de haberlo iniciado, clicar sobre Session y luego SSH).
+
+## Durante la instalación de YunoHost
+
+#### Encontrar su IP
+
+Si instalas YunoHost en un VPS, tu proveedor debería haberte comunicado la dirección IP de tu servidor.
+
+Si instalas un servidor en tu casa (por ejemplo en Raspberry Pi u OLinuXino), tienes que encontrar el IP que fue atribuido a tu tarjeta cuando la conectaste a tu router / caja Internet. Hay varias maneras de hacerlo :
+
+- abre una terminal y teclea `sudo arp-scan --local` para enumerar los IP de las máquinas en la red local ;
+- utiliza la interfaz de tu router caja internet para listar las máquinas conectadas, o mira los los ;
+- conecta una pantalla en tu servidor, inicia una sesión y escribe `hostname --all-ip-address`.
+
+#### Conectarse
+
+Suponiendo que tu dirección IP sea `111.222.333.444`, abre una terminal y escribe :
+
+```bash
+ssh root@111.222.333.444
+```
+
+Ahora te piden una contraseña. Si es un VPS, tu proveedor ya te hará comunicado la contraseña. Si utilizaste una imagen pre-instalada (para x86 o tarjetas ARM), el password debería ser `yunohost`.
+
+
+Desde YunoHost 3.4, después de la post-instalación ya no es posible conectarse con el usuario `root`. En lugar de eso, hace falta **conectarse con el usuario `admin`**. Incluso si el servidor LDAP fuera quebrado (haciendo que el usuario `admin` ya no fuera utilizable) todavía deberías poder conectarte con el usuario `root` desde la red local.
+
+
+#### ¡ Cambiar la contraseña root !
+
+Después de haberte conectado por primera vez, tienes que cambiar la contraseña `root`. Tal vez el servidor te pida automáticamente que lo hagas. Si no es el caso, hay que utilizar el comando `passwd`. Es muy importante que elijas una contraseña bastante complicada. Nota que esta contraseña luego estará reemplazada por la contraseña admin elegida durante la post-instalación.
+
+
+## En una instancia que ya está instalada
+
+Si instalaste tu servidor en casa y que quieres conectarte desde fuera de la red local, asegúrate que hayas previamente redirigido el puerto 22 de tu router / caja hacia tu servidor (con el usuario `admin` !)
+
+Si sólo conoces el IP de tu servidor :
+
+```bash
+ssh admin@111.222.333.444
+```
+
+Luego, entra la contraseña de administración que has elegido durante la post-instalación [post-installation](/postinstall).
+
+Si has configurado tus DNS (o modificar tu `/etc/hosts`), puedes utilizar tu nombre de dominio :
+
+```bash
+ssh admin@votre.domaine.tld
+```
+
+Si cambiaste el puerto SSH, hay que añadir `-p ` al comando, por ej. :
+
+```bash
+ssh -p 2244 admin@tu.dominio.tld
+```
+
+
+Si estás conectado como `admin` y quieres ser `root` para tener más confort (por ejemplo, para no teclear `sudo` con cada comando), puedes convertirte en `root` tecleando `sudo su`.
+
+
+## ¿ Qué usuarios ?
+
+Por defecto, sólo el usuario `admin` puede conectarse en SSH en una instancia YunoHost.
+
+Los usuarios YunoHost creados vea la interfaz de administración están administrados por la base de datos LDAP. Por defecto, no pueden conectarse en SSH por razones de seguridad. Si necesitas absolutamente que uno de estos usuarios disponga de un acceso SSH, puedes utilizar el comando :
+```bash
+yunohost user ssh allow
+```
+
+Del mismo modo, es posible cancelar el acceso SSH de un usuario con el comando :
+```bash
+yunohost user ssh disallow
+```
+
+Finalmente, es posible añadir, suprimir y listar llaves SSH, para mejorar la seguridad del acceso SSH, con estos comandos :
+```bash
+yunohost user ssh add-key
+yunohost user ssh remove-key
+yunohost user ssh list-keys
+```
+
+## SSH y seguridad
+
+N.B. : `fail2ban` proscribirá tu IP durante 10 minutos si fracasas más de 5 veces consecutivas en identificarte. Si esto ocurre y que quieres re-validar tu IP, puedes echar un vistazo a la página [Fail2Ban](/fail2ban)
+
+Encontrarás explicaciones más completa sobre la seguridad y SSH en [la página dedicada](/security).
diff --git a/ssh_fr.md b/ssh_fr.md
new file mode 100644
index 00000000..4f2f4acc
--- /dev/null
+++ b/ssh_fr.md
@@ -0,0 +1,84 @@
+# SSH
+
+## Qu’est-ce que SSH ?
+
+**SSH** est un acronyme pour Secure Shell, et désigne un protocole qui permet de contrôler et administrer à distance une machine via la ligne de commande (CLI). C'est aussi une commande disponible de base dans les terminaux de GNU/Linux et macOS. Sous Windows, il vous faudra utiliser le logiciel [MobaXterm](https://mobaxterm.mobatek.net/download-home-edition.html) (après l'avoir lancé, cliquer sur Session puis SSH).
+
+## Quelle adresse utiliser pour se connecter au serveur ?
+
+Si vous hébergez votre serveur **à la maison** (par ex. Raspberry Pi ou OLinuXino ou vieil ordinateur)
+ - vous devriez pouvoir vous connecter à la machine en utilisant `yunohost.local`.
+ - si `yunohost.local` ne fonctionne pas, il vous faut [trouver l'IP locale de votre serveur](/finding_the_local_ip).
+ - si vous avez installé votre serveur à la maison mais essayez d'y accéder depuis l'extérieur du réseau local, assurez-vous d'avoir bien configuré une redirection de port pour le port 22
+
+Si il s'agit d'une machine distante (VPS), votre fournisseur devrait vous avoir communiqué l'IP de votre machine
+
+Dans tous les cas, si vous avez déjà configuré un nom de domaine qui pointe sur l'IP appropriée, il est plus pratique d'utiliser `votre.domaine.tld` plutôt que l'adresse IP
+
+## Identifiants pour se connecter
+
+### AVANT la post-installation
+
+- Si vous faites une **installation à la maison**, les identifiants par défaut sont login: `root`, mot de passe: `yunohost`
+- Si vous faites une **installation sur un serveur distant (VPS)**, votre fournisseur devrait vous avoir communiqué le login et mot de passe (ou vous proposer de configurer une clef SSH)
+
+### APRÈS la post-installation
+
+Durant la postinstallation, vous avez défini un mot de passe d'administration. C'est ce mot de passe qui devient le nouveau mot de passe pour les utilisateurs `root` et `admin`. De plus, **le connection en SSH avec l'utilisateur `root` est désactivée et il vous faut utiliser l'utilisateur `admin` !**. L'exception à cette règle est qu'il reste possible de se logger en root *depuis le réseau local - ou depuis une console en direct sur la machine* (ce qui peut être utile dans l'éventualité ou le serveur LDAP est inactif et l'utilisateur admin ne fonctionne plus)
+
+## Se connecter
+
+Une commande SSH ressemble typiquement à :
+
+```bash
+# avant la postinstall:
+ssh root@11.22.33.44
+
+# ou après la postinstall:
+ssh admin@11.22.33.44
+```
+
+Ou bien en utilisant le nom de domaine plutôt que l'IP (plus pratique) :
+
+```bash
+ssh admin@votre.domaine.tld
+# ou avec le nom de domaine spécial yunohost.local:
+ssh admin@yunohost.local
+```
+
+Si vous avez changé le port SSH, il faut rajouter l'option `-p ` à la commande, par ex. :
+
+```bash
+ssh -p 2244 admin@votre.domaine.tld
+```
+
+
+Si vous êtes connecté en tant qu'`admin` et souhaitez devenir `root` pour plus de confort (par exemple, ne pas avoir à taper `sudo` à chaque commande), vous pouvez devenir `root` en tapant `sudo su` ou `sudo -i`.
+
+
+## Quels utilisateurs ?
+
+Par défaut, seulement l'utilisateur `admin` peut se logger en SSH sur une instance YunoHost.
+
+Les utilisateurs YunoHost créés via l'interface d'administration sont gérés par la base de donnée LDAP. Par défaut, ils ne peuvent pas se connecter en SSH pour des raisons de sécurité. Si vous avez absolument besoin qu'un utilisateur dispose d'un accès SSH, vous pouvez utiliser la commande :
+```bash
+yunohost user ssh allow
+```
+
+De même, il est possible de supprimer l'accès SSH à un utilisateur avec la commande :
+```bash
+yunohost user ssh disallow
+```
+
+Enfin, il est possible d'ajouter, de supprimer et de lister des clés SSH, pour améliorer la sécurité de l'accès SSH, avec les commandes :
+```bash
+yunohost user ssh add-key
+yunohost user ssh remove-key
+yunohost user ssh list-keys
+```
+
+## SSH et sécurité
+
+N.B. : `fail2ban` bannira votre IP pour 10 minutes si vous échouez plus de 5 fois à vous identifier. Pour débannir une IP, vous pouvez regarder la page sur [Fail2Ban](/fail2ban)
+
+Une discussion plus complète de la sécurité et de SSH peut être trouvée sur [la page dédiée](/security).
diff --git a/ssh_it.md b/ssh_it.md
new file mode 100644
index 00000000..83689950
--- /dev/null
+++ b/ssh_it.md
@@ -0,0 +1,92 @@
+# SSH
+
+## Cos'è SSH?
+
+**SSH** sta per Secure Shell, un protocollo che permette di controllare da remoto un computer usando l'interfaccia a linea di comando (command line interface, CLI in inglese). È disponibile di default in ogni emulazione di terminale su GNU/Linux e macOS. Su Windows è possibile usare [MobaXterm](https://mobaxterm.mobatek.net/download-home-edition.html) (dopo averlo avviato si deve cliccare su Session e poi SSH).
+
+## Durante l'installazione di YunoHost
+
+#### Individuare il proprio IP
+
+Se stai installando su un VPS allora il provider dovrebbe averti indicato il tuo indirizzo IP.
+
+Se stai installando su un computer casalingo (ad esempio un Raspberry Pi o un OLinuXino) devi individuare l'indirizzo IP che è stato attribuito al computer dopo averlo collegato al router. Questi sono alcuni sistemi:
+- avvia un terminale e dai il comando `sudo arp-scan --local` per elencare gli indirizzi IP sulla rete locale;
+- usa l'interfaccia del router per vedere la lista dei computer collegati o controllane i log;
+- collega un monitor al tuo server yunohost, fai login e digita `hostname --all-ip-address`.
+
+#### Collegamento
+
+Se come esempio il tuo indirizzo IP è `111.222.333.444` avvia un terminale e digita:
+
+```bash
+ssh root@111.222.333.444
+```
+
+Ti verrà richiesta una password. Nel caso tu stia utilizzando un VPS questa ti dovrebbe essere stata comunicata dal provider. Se invece stai utilizzando un'immagine pre-installata (per computer di tipo x86 o ARM) la password sarà `yunohost`.
+
+
+Dalla versione 3.4 di YunoHost, dopo aver completato il processo di post installazione, non sarà più possibile fare login da `root`: invece **sarà necessario fare login usando l'utente `admin`!**. Nel caso in cui il server LDAP non stia funzionando e l'utente `admin` sia inutilizzabile sarà sempre possibile fare login da `root` solo dalla rete locale.
+
+
+#### Cambio della password
+
+Dopo esserci loggati per la prima volta è necessario cambiare la password di root e ti dovrebbe essere richiesto dal server stesso; nel caso in cui questo non accada usa il comando `passwd`. È importante scegliere una password ragionevolmente robusta. Nota che la password di root verrà sovrascritta dalla password di admin dal processo di postinstallazione.
+
+## Dopo l'installazione
+
+Se hai installato il server a casa e stai provando a collegarti dall'esterno della tua rete locale verifica che la porta 22 sia regolarmente forwardata al server. (Ricorda, dalla versione 3.4 di YunoHost dovrai usare l'utente `admin`!).
+
+Se conosci esclusivamente l'indirizzo IP del tuo server:
+
+```bash
+ssh admin@111.222.333.444
+```
+
+Dopo di che dovrai inserire la password di amministratore creata nella [procedura di postinstallazione](postinstall).
+
+Se invece hai configurato il DNS (o hai modificato il file `/etc/hosts`), puoi semplicemente usare il tuo nome di dominio:
+
+```bash
+ssh admin@your.domain.tld
+```
+
+Se hai modificato la porta in ascolto per SSH devi aggiungere l'opzione `-p ` al comando, cioè:
+
+```bash
+ssh -p 2244 admin@your.domain.tld
+```
+
+
+Se sei loggato come `admin` ma vuoi usare l'utente `root` per maggiore comodità (ad esempio per evitare di scrivere `sudo` prima di ogni comando) puoi usare il comando `sudo su`.
+
+
+## Utenti abilitati
+
+Di default solo l'utente `admin` può loggarsi al server SSH di YunoHost.
+
+Gli utenti creati dall'interfaccia di amministrazione sono gestiti dalla directory LDAP e di default non possono connettersi via SSH per ragioni di sicurezza. Se invece vuoi abilitare all'accesso SSH alcuni utenti usa il comando:
+
+```bash
+yunohost user ssh allow
+```
+
+È sempre possibile eliminare l'accesso SSH con il comando:
+
+```bash
+yunohost user ssh disallow
+```
+
+Infine è possibile aggiungere, eliminare ed elencare le chiavi SSH, usate per migliorare la sicurezza degli accessi SSH con i comandi:
+
+```bash
+yunohost user ssh add-key
+yunohost user ssh remove-key
+yunohost user ssh list-keys
+```
+
+## Sicurezza e SSH
+
+N.B.: `fail2ban` bannerà il tuo IP per 10 minuti nel caso di almeno 5 tentativi di accesso falliti. Se devi togliere il ban al tuo IP leggi la pagina relativa [Fail2Ban](/fail2ban)
+
+Una discussione più approfondita relativa a sicurezza & SSH è su [questa pagina](/security).
diff --git a/stretch_buster_migration.md b/stretch_buster_migration.md
new file mode 100644
index 00000000..84c47b1a
--- /dev/null
+++ b/stretch_buster_migration.md
@@ -0,0 +1,65 @@
+# Migrating an existing instance to Buster
+
+This page is dedicated to help you migrating an instance from YunoHost 3.8.x (running on Debian Stretch/9.x) to YunoHost 4.x (running on Debian Buster/10.x).
+
+## Important notes
+
+- The YunoHost team did its best to make sure that the migration is as smooth as possible and was tested over the course of several months in several cases.
+
+- With that said, please be aware that this is a delicate operation. System administration is a complicated topic and covering every particular cases is quite hard. Therefore, if you host critical data and services, please [make backups](/backup). And in any case, be patient and attentive during the migration.
+
+- Please don't rush into thinking that you should need to reinstall your system from scratch thinking it would be "simpler" (sigh). (A common attitude is to be willing to reinstall a server at the slightest complication...) Instead, if you happen to run into issues, we encourage you to try to investigate and understand what's going on and [reach for help on the chat and the forum](/help).
+
+## Migration procedure
+
+#### From the webadmin
+
+After upgrading to 3.8.5.x, go to Tools > Migrations to access the migrations interface. You will have to read carefully and accept the disclaimer then launch the migration.
+
+#### From the command line
+
+After upgrading to 3.8.5.x, run :
+
+```bash
+sudo yunohost tools migrations migrate
+```
+
+then read carefully and accept the disclaimer.
+
+## During the migration
+
+Depending on your hardware and packages installed, the migration might take up to a few hours.
+
+The logs will be shown in the message bar (you can hover it to see the whole history). They will also be available after the migration (like any other operations) in Tools > Logs.
+
+Note that even if you close the webadmin page for some reason, the migration will continue in the background (but the webadmin will be partially unavailable).
+
+#### If the migration crashed / failed at some point.
+
+If the migration failed at some point, it should be possible to relaunch it. If it still doesn't work, you can try to [get help](/help) (please provide the corresponding messages or whatever makes you tell that it's not working).
+
+## What to do after the upgrade
+
+#### Check that you actually are on Debian Buster and YunoHost 4.x
+
+For this, go in Diagnosis (category Base system) or look at the footer of the webadmin. In the command line, you can use `lsb_release -a` and `yunohost --version`.
+
+#### Check that no issue appeared in the diagnosis
+
+Also in the Diagnosis in the webadmin, make sure that no specific issue appeared after running the migration (for example a service that crashed for some reason).
+
+#### Check that your applications are working
+
+Test that your applications are working. If they aren't, you should try to upgrade them (it is also a good idea to upgrade them even if they are working anyway).
+
+## Current known (minor) issues after the migration
+
+- Some file (`/etc/nsswitch.conf` and `/etc/nslcd.conf`) will appear as manually modified after the migration. You can safely apply the regen-conf with:
+
+```bash
+yunohost tools regen-conf nsswitch nslcd --force
+```
+
+(we will try to do this automatically somehow)
+
+- Sometimes the postgresql migration (that is supposed to happen automatically after the buster migration is ran) fails to run properly... Some users reported that re-launching manually the postgresql migration fixed the issue (we will try to understand and fix this somehow)
diff --git a/stretch_buster_migration_fr.md b/stretch_buster_migration_fr.md
new file mode 100644
index 00000000..e3b3997b
--- /dev/null
+++ b/stretch_buster_migration_fr.md
@@ -0,0 +1,65 @@
+# Migrer vers Buster
+
+L'objectif cette page est de décrire le processus de migration d'une instance en YunoHost 3.8.x (tournant sous Debian Stretch/9.x) vers YunoHost 4.x (tournant sous Debian Buster/10.x)
+
+## Notes importantes
+
+- L'équipe de YunoHost a fait de son mieux pour que cette migration se passe autant en douceur que possible. Elle a été testée durant plusieurs mois et sur plusieurs types d'installations.
+
+- Néanmoins, vous devez être conscient qu'il s'agit d'une opération délicate. L'administration système est un sujet compliqué et couvrir tous les cas particuliers n'est pas chose aisée. En conséquence, si vous hébergez des données et des systèmes critiques, [faites des sauvegardes](/backup). Et dans tous les cas, soyez patients et attentifs durant la migration.
+
+- Ne vous précipitez pas à vouloir faire une réinstallation de votre système en pensant que cela serait "plus simple" (sigh). (Une attitude qui revient régulièrement est de vouloir réinstaller son système à la moindre complication...). À la place, si vous rencontrez des problèmes, nous vous encourageons à investiguer, chercher à comprendre et [trouver de l'aide sur le chat ou le forum](/help).
+
+## Procédure de migration
+
+#### Depuis la webadmin
+
+Après avoir mis à jour vers la version en 3.8.5.x, allez dans Outils > Migrations pour accéder à l'interface de migration. Il vous faudra ensuite lire l'avertissement attentivement et l'accepter pour lancer la migration.
+
+#### Depuis la ligne de commande
+
+Après avoir mis à jour vers la version 3.8.5.x, lancez :
+
+```bash
+sudo yunohost tools migrations migrate
+```
+
+puis lisez attentivement l'avertissement et les instructions.
+
+## Pendant la migration
+
+En fonction de votre matériel et des paquets installés, la migration peut prendre jusqu'à une ou deux heures.
+
+Les logs seront affichés dans la barre de message en haut (vous pouvez approcher la souris dessus pour voir l'historique en entier). Ils seront également consultable après coup (comme les autres opérations) dans Outils > Journaux.
+
+Notez que même si vous fermez la page d'admin, la migration continuera (par contre l'interface d'admin sera partiellement indisponible).
+
+#### Si la migration a crashé / échoué à un moment.
+
+Si la migration a échoué a un moment donné, la première chose à faire est de tenter de la relancer. Si cela ne fonctionne toujours pas, il vous faut [trouver de l'aide](/help) (prière de fournir le/les messages correspondants ou tout élément qui vous fait penser que ça n'a pas marché).
+
+## Choses à vérifier après la migration
+
+#### Vérifiez que vous êtes véritablement sous Debian Buster / YunoHost 4.x
+
+Pour cela, vous pouvez aller dans la partie Diagnostic (section Système de base). (Vous pouvez aussi regarder ce qui est affiché à droite dans le pied de page de la webadmin). En ligne de commande, vous pouvez aussi utiliser `lsb_release -a` et `yunohost --version`.
+
+#### Vérifiez que le diagnostic ne rapporte pas de problème particulier
+
+Également dans la section Diagnostic de la webadmin, vérifiez qu'il n'y a pas de problème apparu suite à la migration (par exemple un service qui ne tournerais plus...)
+
+#### Vérifiez que les applications fonctionnent
+
+Vérifiez que vos applications installées fonctionnent... Si elles ne fonctionnent pas, il est recommandé de tenter de les mettre à jour. (ou bien de manière générale, il est recommandé de les mettre à jour même si elles fonctionnent !).
+
+## Soucis (mineurs) connus après la migration
+
+- Quelques fichiers de configurations (`/etc/nsswitch.conf` et `/etc/nslcd.conf`) apparaîtrons comme manuellement modifiés. Vous pouvez appliquer la regen-conf en toute sécurité pour régler le problème avec la commande:
+
+```bash
+yunohost tools regen-conf nsswitch nslcd --force
+```
+
+(nous allons essayer de corriger ceci automatiquement)
+
+- Il se peut que la migration postgresql (censée s'effectuer automatiquement après la migration à Buster) ne fonctionne pas correctement... Certains utilisateurs ont rapporté que relancer la migration suffisait à résoudre le problème. (Nous allons voir pour comprendre et corriger ce soucis)
diff --git a/tests/check_code_block_syntax.sh b/tests/check_code_block_syntax.sh
new file mode 100644
index 00000000..62e83a0f
--- /dev/null
+++ b/tests/check_code_block_syntax.sh
@@ -0,0 +1,17 @@
+returncode=0
+for FILE in $(ls *.md)
+do
+ NB_OPENING=$(grep -E "^ *\`\`\` *\w+ *$" $FILE | wc -l)
+ NB_CLOSE=$(grep -E "^ *\`\`\` *$" $FILE | wc -l)
+ if [[ "$NB_OPENING" != "$NB_CLOSE" ]]
+ then
+ echo "There are some mistakes in code block syntax in $FILE ..."
+ returncode=1
+ fi
+done
+
+if [[ $returncode == 1 ]]
+then
+ echo "Make sure that all the code block in the problematic files do specific the language in the opening backticks (for example, \`\`\`bash). Otherwise, rendering in the actual website will be broken because of a bug in markdown parsing lib..."
+ exit 1
+fi
diff --git a/tests/dead_links.sh b/tests/dead_links.sh
new file mode 100644
index 00000000..c9fd27ce
--- /dev/null
+++ b/tests/dead_links.sh
@@ -0,0 +1,19 @@
+returncode=0
+
+# Find all markdown links and generate a list of filename.md:N:linktarget (with N the line number)
+for LINK in $(grep -nr -o -E "\]\(\/?(\w|-)+\)" ./*.md | tr -d ']()/')
+do
+ PAGE=$(echo $LINK | awk -F: '{print $3}')
+ [ -e "$PAGE.md" ] || echo "This Markdown link looks dead (page doesn't exist in english?) $LINK"
+ [ -e "$PAGE.md" ] || returncode=1
+done
+
+# Find all HTML/href links and generate a list of filename.md:N:linktarget (with N the line number)
+for LINK in $(grep -nr -o -E 'href="\/?(\w|-)+\"' ./*.md | sed -E 's@href="/?@@g' | tr -d '"')
+do
+ PAGE=$(echo $LINK | awk -F: '{print $3}')
+ [ -e "$PAGE.md" ] || echo "This HTML link looks dead (page doesn't exist in english?) $LINK"
+ [ -e "$PAGE.md" ] || returncode=1
+done
+
+exit $returncode
diff --git a/tests/uniformize_links.sh b/tests/uniformize_links.sh
new file mode 100644
index 00000000..e0e1613d
--- /dev/null
+++ b/tests/uniformize_links.sh
@@ -0,0 +1,15 @@
+for FILE in $(ls *.md);
+do
+ grep -q "Unfortunately, this page only exists" $FILE && continue
+
+ # Replace markdown links with full url ... we only need the relative url
+ sed -i -E 's@\(https://yunohost.org/#/(\w+)\)@(/\1)@g' $FILE
+
+ # Replace (/foo_fr) to (foo)
+ sed -i -E 's@\(\/?((\w|-)+)_(en|fr|es|it|ar|de|oc|ca)\)@(/\1)@g' $FILE
+
+ # Replace href="/foo_fr" to href="foo"
+ sed -i -E 's@href="/?((\w|-)+)_(en|fr|es|it|ar|de|oc|ca)"@href="/\1"@g' $FILE;
+done
+
+git checkout project_organization.md project_organization_fr.md
diff --git a/tests/unreferenced_pages.sh b/tests/unreferenced_pages.sh
new file mode 100644
index 00000000..dbe83931
--- /dev/null
+++ b/tests/unreferenced_pages.sh
@@ -0,0 +1,25 @@
+
+
+MARKDOWN_TARGETS=$(grep -nr -o -E "\]\(\/?(\w|-)+\)" ./*.md | tr -d ']()/' | awk -F: '{print $3}' | sort | uniq)
+HTML_TARGETS=$(grep -nr -o -E 'href="\/?(\w|-)+\"' ./*.md | sed -E 's@href="/?@@g' | tr -d '"' | awk -F: '{print $3}' | sort | uniq)
+
+ALL_TARGETS=$(echo $MARKDOWN_TARGETS $HTML_TARGETS)
+
+PAGES=$(ls *.md | sed -E 's/(_(fr|it|de|ar|oc|es|ru|ca))?\.md//g' | sort | uniq)
+
+returncode=0
+
+for PAGE in $PAGES
+do
+ if [[ $PAGE == "index" ]] || [[ $PAGE == "README" ]] || [[ $PAGE == "default" ]]
+ then
+ continue
+ fi
+ if ! echo $ALL_TARGETS | grep -q -w $PAGE
+ then
+ returncode=1
+ echo "The following page is not referenced by any other page :( -> $PAGE"
+ fi
+done
+
+exit $returncode
diff --git a/theming.md b/theming.md
new file mode 100644
index 00000000..9cc9a19f
--- /dev/null
+++ b/theming.md
@@ -0,0 +1,66 @@
+# Customize the appearance of the user portal
+
+## Using a theme
+
+Since YunoHost 3.5, you can change the theme of the user portal - though for now it requires tweaking via the command line.
+
+You can list the available themes with:
+
+```bash
+$ ls /usr/share/ssowat/portal/assets/themes/
+```
+
+Then you can use `nano /etc/ssowat/conf.json.persistent` to enable the theme you choose like this:
+
+```json
+{
+ "theme": "light",
+ ...other lines...
+}
+```
+
+
+You might need to force the refresh of your browser's cache for the theme to fully propagate. You can do so with Ctrl+Shift+R on Firefox.
+
+
+## Adding someone else's theme
+
+You may add themes created by other people by downloading and extracting the corresponding files in a new folder `the_theme_name` in `/usr/share/ssowat/portal/assets/themes/`.
+
+
+**Beware** that adding third-party themes from random strangers on the internet **is a security risk**. It is equivalent to running someone's else code on your machine, which can be used for malicious purpose such as stealing credentials!
+
+
+## Creating your own theme
+
+You can create your own theme by copying the existing theme of your choice. For instance starting from the light theme:
+
+```bash
+cp -r /usr/share/ssowat/portal/assets/themes/{light,your_own_theme}
+```
+
+Then, edit the files the CSS and JS files in `/usr/share/ssowat/portal/assets/themes/your_own_theme` according to what you want to do:
+
+- `custom_portal.css` can be used to add custom CSS rules to the user portal;
+- `custom_overlay.css` can be used to customize the small YunoHost button overlay, displayed on apps page which includes it;
+- `custom_portal.js` can be used to add custom JS code to be ran both on the user portal or when injecting the small YunoHost button / overlay.
+
+You can also add your own images and assets which can then be used by the CSS and JS files.
+
+### Example : customizing the logo
+
+You may create your own theme simply to change the "branding" of the YunoHost user portal and replace the YunoHost logo with you own!
+
+To do so, upload your logo to `/usr/share/ssowat/portal/assets/themes/your_own_theme/`, and use the following CSS rules:
+
+```css
+/* Inside custom_portal.css */
+#ynh-logo {
+ background-image: url("./your_logo.png");
+}
+
+/* Inside custom_overlay.css */
+#ynh-overlay-switch {
+ background-image: url("./your_logo.png");
+}
+```
diff --git a/theming_fr.md b/theming_fr.md
new file mode 100644
index 00000000..c79f1678
--- /dev/null
+++ b/theming_fr.md
@@ -0,0 +1,66 @@
+# Personnaliser l’apparence du portail utilisateur
+
+## Utiliser un thème
+
+Depuis YunoHost 3.5, il est possible de changer le thème du portail utilisateur - bien que pour l'instant il faille encore faire cette opération via la ligne de commande.
+
+Vous pouvez lister les thèmes disponibles avec :
+
+```bash
+ls /usr/share/ssowat/portal/assets/themes/
+```
+
+Ensuite, vous pouvez utiliser `nano /etc/ssowat/conf.json.persistent` pour activer le thème que vous choisissez comme ceci :
+
+```json
+{
+ "theme" : "light",
+ ...autres lignes.....
+}
+```
+
+
+Vous devrez peut-être forcer le rafraîchissement du cache de votre navigateur pour que le thème se propage complètement. Vous pouvez le faire avec Ctrl+Maj+R sur Firefox.
+
+
+## Ajouter le thème de quelqu'un d'autre
+
+Vous pouvez ajouter des thèmes créés par d'autres personnes en téléchargeant et en extrayant les fichiers correspondants dans un nouveau dossier `nom_du_theme` dans `/usr/share/ssowat/portal/assets/themes/`.
+
+
+**Attention** : l'ajout de thèmes provenant d'inconnus sur Internet **est un risque de sécurité**. Cela équivaut à exécuter du code écrit par quelqu'un d'autre sur votre machine, et peut donc être utilisé à des fins malveillantes comme voler des mots de passe !
+
+
+## Créer votre propre thème
+
+Vous pouvez créer votre propre thème en copiant le thème existant de votre choix. Par exemple à partir du thème `light` :
+
+```bash
+cp -r /usr/share/ssowat/portal/assets/themes/{light,votre_theme}
+```
+
+Ensuite, éditez les fichiers CSS et JS dans `/usr/share/ssowat/portal/assets/themes/votre_theme` selon ce que vous voulez faire :
+
+- `custom_portal.css` peut être utilisé pour ajouter des règles CSS personnalisées au portail utilisateur ;
+- `custom_overlay.css` peut être utilisé pour personnaliser le petit bouton YunoHost, présent sur les apps qui l'intègrent ;
+- `custom_portal.js` peut être utilisé pour ajouter du code JS personnalisé à exécuter à la fois sur le portail utilisateur ou lors de l'injection du petit bouton YunoHost ("overlay").
+
+Vous pouvez également ajouter vos propres images et ressources qui peuvent ensuite être utilisées par les fichiers CSS et JS.
+
+### Exemple : personnaliser le logo
+
+Vous pouvez créer votre propre thème simplement pour changer le "branding" du portail utilisateur YunoHost et remplacer le logo YunoHost par votre propre logo !
+
+Pour ce faire, téléversez votre logo dans `/usr/share/ssowat/portal/assets/themes/votre_theme/`, et ajoutez les règles CSS suivantes :
+
+```css
+/* Dans custom_portal.css */
+#ynh-logo {
+ background-image : url("./votre_logo.png");
+}
+
+/* Dans custom_overlay.css */
+#ynh-overlay-switch {
+ background-image : url("./votre_logo.png");
+}
+```
diff --git a/torhiddenservice.md b/torhiddenservice.md
new file mode 100644
index 00000000..5c1fc0ca
--- /dev/null
+++ b/torhiddenservice.md
@@ -0,0 +1,49 @@
+## Using YunoHost as a Tor Hidden Service
+
+This tuto is not finished ! Some data could leak with this setup like the main domain of your yunohost, so it's not a "Hidden Service".
+
+
+See https://www.torproject.org/docs/tor-hidden-service.html.en
+
+### Installing Tor
+```bash
+apt install tor
+```
+
+### Configuring our hidden service
+Edit `/etc/tor/torrc`, and add these lines:
+
+```bash
+HiddenServiceDir /var/lib/tor/hidden_service/
+HiddenServicePort 80 127.0.0.1:80
+HiddenServicePort 443 127.0.0.1:443
+```
+
+### Restart Tor
+```bash
+service tor restart
+```
+
+### Get your Tor Hidden Service hostname
+```bash
+cat /var/lib/tor/hidden_service/hostname
+```
+
+Your domain looks like *random123456789.onion*
+
+### Add the .onion domain to YunoHost
+```bash
+yunohost domain add random123456789.onion
+```
+
+### Avoid SSO redirection (optional)
+If you want to avoid being redirected to the SSO portal at login, you can deactivate SSOwat for this specific tor domain, by editing the file `/etc/nginx/conf.d/random123456789.onion.conf` and commenting the following line (two times):
+
+```bash
+#access_by_lua_file /usr/share/ssowat/access.lua;
+```
+
+### Restart NGINX
+```bash
+service nginx restart
+```
diff --git a/torhiddenservice_fr.md b/torhiddenservice_fr.md
new file mode 100644
index 00000000..a546f680
--- /dev/null
+++ b/torhiddenservice_fr.md
@@ -0,0 +1,53 @@
+## Utiliser YunoHost comme un service caché Tor
+
+Ce tuto n'est pas complet ! Des données peuvent être récupérée avec cette installation comme le nom de domaine principal de votre yunohost, donc ce n'est pas un "service caché".
+
+Voir https://www.torproject.org/docs/tor-hidden-service.html.en (anglais)
+
+### Installer Tor
+```bash
+apt install tor
+```
+
+### Configurer notre service caché
+Éditer le fichier `/etc/tor/torrc`, et ajouter ces lignes :
+
+```bash
+HiddenServiceDir /var/lib/tor/hidden_service/
+HiddenServicePort 80 127.0.0.1:80
+HiddenServicePort 443 127.0.0.1:443
+```
+
+### Redémarrer Tor
+```bash
+systemctl restart tor
+```
+
+### Obtenir l’adresse du service caché
+```bash
+cat /var/lib/tor/hidden_service/hostname
+```
+
+Le nom de domaine ressemble à *random123456789.onion*
+
+### Ajouter le domaine .onion à YunoHost
+```bash
+yunohost domain add random123456789.onion
+```
+
+### Éviter la redirection vers le SSO (optionnel)
+Si vous voulez éviter d’être redirigé vers le portail à la connexion pour des raisons de traçabilité, vous pouvez désactiver SSOwat pour le domaine, en éditant le fichier `/etc/nginx/conf.d/random123456789.onion.conf` et en commentant la ligne suivante (elle apparaît deux fois dans le fichier) :
+
+```bash
+#access_by_lua_file /usr/share/ssowat/access.lua;
+```
+
+### Vérifier que l'on a pas fait d'erreurs dans la configuration de NGINX
+```bash
+nginx -t
+```
+
+### Si tout est OK on applique les modifications de la configuration
+```bash
+systemctl reload nginx
+```
diff --git a/torhiddenservice_it.md b/torhiddenservice_it.md
new file mode 100644
index 00000000..155c4250
--- /dev/null
+++ b/torhiddenservice_it.md
@@ -0,0 +1,50 @@
+## Collegarsi a YunoHost attraverso un Hidden Service
+
+Questo tutorial non è completo! Con queste impostazioni alcuni dati possono essere rivelati come ad esempio il dominio principale del tuo yunohost, di conseguenza non può essere considerato un reale "Hidden service".
+
+
+Vedi https://www.torproject.org/docs/tor-hidden-service.html
+
+### Installare Tor
+```bash
+apt install tor
+```
+
+### Configurazione dell'hidden service
+Modifica `/etc/tor/torrc` aggiungendo queste righe:
+
+```bash
+HiddenServiceDir /var/lib/tor/hidden_service/
+HiddenServicePort 80 127.0.0.1:80
+HiddenServicePort 443 127.0.0.1:443
+```
+
+### Riavvia Tor
+```bash
+service tor restart
+```
+
+### Copia l'hostname del tuo Hidden Service
+```bash
+cat /var/lib/tor/hidden_service/hostname
+```
+
+Il dominio dell'hidden service sarà una cosa tipo *random123456789.onion*
+
+### Aggiungi il dominio .onion a YunoHost
+```bash
+yunohost domain add random123456789.onion
+```
+
+### Disabilita la redirezione SSO (opzionale)
+Se non vuoi essere rediretto al portale SSO al login puoi disattivare SSOwat specificatamente per questo dominio modificando il file `/etc/nginx/conf.d/random123456789.onion.conf` commentando le seguenti linee (due volte):
+
+```bash
+#access_by_lua_file /usr/share/ssowat/access.lua;
+```
+
+### Riavvia NGINX
+```bash
+service nginx restart
+```
+
diff --git a/try.md b/try.md
new file mode 100644
index 00000000..b7477251
--- /dev/null
+++ b/try.md
@@ -0,0 +1,27 @@
+# Try YunoHost
+
+
+**Note:** This demo server could be down from time to time.
+
+
+
+
+
+
+
+
+
+
+
+***Demo server gracefully provided by
+Gitoyen***
+
diff --git a/try_ar.md b/try_ar.md
new file mode 100644
index 00000000..4ab216e4
--- /dev/null
+++ b/try_ar.md
@@ -0,0 +1,29 @@
+#تجريب YunoHost
+
+
+**ملاحظة :** يمكن لهذا السيرفر التجريبي أن يتوقف من وقت إلى آخر.
+
+
+
+
+
+
+
+
+
+
+
+***تم توفير الخادم التجريبي بفضل
+Gitoyen***
+
+
+
diff --git a/try_ca.md b/try_ca.md
new file mode 100644
index 00000000..42ab0870
--- /dev/null
+++ b/try_ca.md
@@ -0,0 +1,27 @@
+# Prova YunoHost
+
+
+**Nota:** Aquest és un servidor de demostració, podria estar caigut de tant en tant.
+
+
+
+
+
+
+
+
+
+
+
+***Servidor de demostració amablement ofert per
+Gitoyen***
+
diff --git a/try_de.md b/try_de.md
new file mode 100644
index 00000000..5fc341ff
--- /dev/null
+++ b/try_de.md
@@ -0,0 +1,27 @@
+# YunoHost ausprobieren
+
+
+**Hinweis:** Dieser Demo-Server könnte zeitweilig nicht erreichbar sein.
+
+
+
+
+
+
+
+
+
+
+
+***Demo-Server freundlicherweise zur Verfügung gestellt von
+Gitoyen***
+
diff --git a/try_es.md b/try_es.md
new file mode 100644
index 00000000..dc63ee34
--- /dev/null
+++ b/try_es.md
@@ -0,0 +1,29 @@
+# Probar YunoHost
+
+
+**Nota :** Este demo puede dejar de functionar de vez en cuando.
+
+
+
+
+
+
+
+
+
+
+
+***El servidor de demo es ofrecido generosamente por
+Gitoyen***
+
+
+
diff --git a/try_fr.md b/try_fr.md
new file mode 100644
index 00000000..94f943be
--- /dev/null
+++ b/try_fr.md
@@ -0,0 +1,29 @@
+# Essayer YunoHost
+
+
+**Note :** Cette démo peut cesser de fonctionner de temps en temps.
+
+
+
+
+
+
+
+
+
+
+
+***Le serveur de démo est fourni généreusement par
+Gitoyen***
+
+
+
diff --git a/try_it.md b/try_it.md
new file mode 100644
index 00000000..548e3b68
--- /dev/null
+++ b/try_it.md
@@ -0,0 +1,27 @@
+# Prova YunoHost
+
+
+**Nota:** A volte questo server demo può essere irraggiungibile
+
+
+
+
+
+
+
+
+
+
+
+***Il server demo è gentilmente fornito da
+Gitoyen***
+
diff --git a/update.md b/update.md
new file mode 100644
index 00000000..b67f6f18
--- /dev/null
+++ b/update.md
@@ -0,0 +1,18 @@
+# How to update the system
+
+## From the webadmin
+
+On the administraton panel, click on Upgrade the system.
+
+The application search for updates and propose it if so.
+
+If so, click on green update button and updates are applied.
+
+## From the command line
+
+From the command line, you can run:
+
+``` bash
+yunohost tools update
+yunohost tools upgrade --system
+```
diff --git a/update_fr.md b/update_fr.md
new file mode 100644
index 00000000..c025cdef
--- /dev/null
+++ b/update_fr.md
@@ -0,0 +1,19 @@
+# Mettre à jour le système
+
+## Depuis la webadmin
+
+Dans la partie administration, choisir Mettre à jour le système.
+
+L’application recherche les mises à jour et les propose s’il y en a.
+
+Si c’est le cas, cliquer sur le bouton vert « Mettre à jour » et les mises à
+jour se font.
+
+## Depuis la ligne de commande
+
+Depuis la ligne de commande, vous pouvez utiliser :
+
+``` bash
+yunohost tools update
+yunohost tools upgrade --system
+```
diff --git a/use_case_non-profit_organisations.md b/use_case_non-profit_organisations.md
new file mode 100644
index 00000000..a63dafe7
--- /dev/null
+++ b/use_case_non-profit_organisations.md
@@ -0,0 +1,204 @@
+# YunoHost for non-profit organizations
+
+## Table of Contents
+* [Introduction](#introduction)
+* [Who](#who)
+* [What](#what)
+* [When](#when)
+* [Where](#where)
+* [Why](#why)
+* [How](#how)
+* [Conclusion](#conclusion)
+
+## Introduction
+
+The object of this document is to present a specific use of [YunoHost](https://yunohost.org/) for non-profit organizations.
+
+## Who
+
+Non-profit organizations, NGO or any kind of association.
+
+## What
+
+Usually non-profit organizations need to provide several services to several publics:
+
+* Board of Directors / Steering Committee / Volunteers with:
+ * [Mails](#mails)
+ * [Calendar](#calendar)
+ * [Contact](#contact)
+ * [Shared files / Drive](#shared-files)
+ * [Instant communication](#instant-communication)
+ * [Intranet / knowledge database](#intranet)
+ * [ERP / Accounting](#erp-accounting)
+* Members with:
+ * [Public website with private and individual access](#public-web-site)
+ * [Membership](#membership)
+ * [Events registrations](#events-registrations)
+ * [Mailings](#newsletter-mailing)
+ * [Forum](#forum)
+* Public with:
+ * [Public website](#public-web-site)
+ * [Newsletter](#newsletter-mailing)
+
+## When
+
+When ready to move forward.
+
+## Where
+
+You YunoHost for non profit can be hosted in several places:
+* Own hosting on a server, computer or Raspberry behind ASDL, SDSL or Fiber
+* [Chatons](https://chatons.org), [librehosters](https://framagit.org/librehosters/awesome-librehosters) hosting services
+* Commercial hosting services providing Debian virtual machine
+
+## Why
+
+YunoHost can provide mostly all needs of a non-profit organization.
+Keeping their data on their own.
+
+## How
+
+### YunoHost
+
+YunoHost is a Debian GNU/Linux based distribution packaged with free software that automates the installation of a personal web server. The purpose of YunoHost is to allow users to easily host their own web services by enabling a simple point-and-click web interface for installing various web apps.
+
+
+
+Out of the box YunoHost provide:
+* A system of application
+* A web interface
+* A command-line interface (CLI): Moulinette
+* A web server: NGINX
+* A DNS server: Dnsmasq
+* A database: MariaDB
+* A backup system
+* An SSO: SSOwat
+* OpenLDAP
+* Email:
+ * SMTP: Postfix
+ * IMAP & POP3: Dovecot
+ * An antispam: rspamd,rmilter
+* Instant messaging XMPP server: Metronome IM
+
+### Domain Name
+
+The first thing you will need to implement a YunoHost server is a domain name. The domain name can usually be provided with your hosting service.
+
+### Mails
+
+From scratch, YunoHost provide mail system available using POP/IMAP/SMTP.
+Mails accounts will be managed using the web interface or the command line. Created accounts are stored in OpenLDAP.
+
+Additional package can be installed to provide more functionality to the YunoHost mail system:
+* Webmail using [Roundcube](https://github.com/YunoHost-Apps/roundcube_ynh), [Rainloop](https://github.com/YunoHost-Apps/rainloop_ynh)
+* ActiveSync using [Z-Push](https://github.com/YunoHost-Apps/z-push_ynh)
+* Internal distribution group using [Mailman](https://github.com/YunoHost-Apps/mailman_ynh)
+
+### Calendar
+
+To provide personal or shared calendars you will need to install:
+* [Nextcloud](https://github.com/YunoHost-Apps/nextcloud_ynh)
+* [Baïkal](https://github.com/YunoHost-Apps/baikal_ynh)
+
+### Contact
+
+To provide personal contact system you will need to install:
+* [Nextcloud](https://github.com/YunoHost-Apps/nextcloud_ynh)
+* [Baïkal](https://github.com/YunoHost-Apps/baikal_ynh)
+
+### Shared files
+
+To provide shared files system: personal and shared drive, you can install [Nextcloud](https://github.com/YunoHost-Apps/nextcloud_ynh).
+Files will be available from a web interface or using a synchronization client.
+
+### Instant communication
+
+Out of the box, YunoHost provide an XMPP server, for which you can install a web client: [Jappix](https://github.com/YunoHost-Apps/jappix_ynh).
+
+You can also install a matrix server:
+* The server: [Synapse](https://github.com/YunoHost-Apps/synapse_ynh)
+* A web client: [Element](https://github.com/YunoHost-Apps/element_ynh)
+
+### Intranet
+
+For an non-profit organization a good way to implement an intranet is to provide a wiki to let internal users read, edit and add content. Here are some packages to implement a wiki:
+* [DokuWiki](https://github.com/YunoHost-Apps/docuwiki_ynh) using wiki syntax
+* [Wiki.js](https://github.com/YunoHost-Apps/wikijs_ynh) using Markdown syntax
+
+### ERP / Accounting
+
+At some time a non-profit organization could need an accounting/erp system, here are two propositions:
+* [OpenERP/Odoo](https://github.com/YunoHost-Apps/libreerp_ynh)
+* [Dolibarr](https://github.com/YunoHost-Apps/dolibarr_ynh)
+
+### Public Web Site
+
+There are several way to implement a Public Web Site:
+* Simple HTML, CSS, etc. Website using: [Custom Webapp](https://github.com/YunoHost-Apps/my_webapp_ynh)
+* Using a CMS (Content Management System) like [WordPress](https://github.com/YunoHost-Apps/_ynh), [Drupal](https://github.com/YunoHost-Apps/drupal_ynh), [Grav](https://github.com/YunoHost-Apps/grav_ynh), [PluXml](https://github.com/YunoHost-Apps/pluxml_ynh)
+
+But we will propose something more powerful: [CiviCRM on Drupal 7](https://github.com/YunoHost-Apps/civicrm_drupal7_ynh):
+* Drupal that is a powerful open source content management framework
+* with CiviCRM that is an open source constituent relationship management for non-profits
+
+#### Membership
+
+With CiviCRM you can provide online membership and payment.
+
+#### Events Registrations
+
+With CiviCRM, you can provide an online diary to let members or public register for free or with a payment.
+
+#### Newsletter/Mailing
+
+Best way to manage that is using CiviCRM and its mailing module.
+
+### Forum
+
+You have several choices, or having an integrated forum in Drupal or using a dedicated forum system like [Flarum](https://github.com/YunoHost-Apps/flarum_ynh).
+
+### Backup
+
+YunoHost provide is own backup system. Before any package upgrade, YunoHost backup the current version of the package and automaticaly restore it if the upgrade fails.
+YunoHost backup are stored localy in `/home/yunohost.backup/archives`.
+
+But for production, localy stored backup are not enough, so you will need to implement aditional backup strategies:
+* Backup of the the Virtual Machine if provided by the hosting system.
+* [Archivist](https://github.com/YunoHost-Apps/archivist_ynh) is an automatic backup system for your server. Your backups can be send to many other places, local or distant.
+* [Borg](https://github.com/YunoHost-Apps/borg_ynh) and [Borg Server](https://github.com/YunoHost-Apps/borgserver_ynh) allow to externalize backups.
+* [Fallback](https://github.com/YunoHost-Apps/fallback_ynh), if you have two YunoHost servers, provide a way to have a secondary server which you can used if your main server goes down. This secondary server will allow you to deploy a copy of your server to bring back your YunoHost during your break down.
+
+### Go further
+
+#### Federated Photo Gallery
+
+* [Pixelfed](https://github.com/YunoHost-Apps/pixelfed_ynh)
+
+#### Federated Audio Gallery
+
+* [Reel2Bits](https://github.com/YunoHost-Apps/reel2bits_ynh)
+* [Funkwhale](https://github.com/YunoHost-Apps/funkwhale_ynh)
+
+#### Federated Video Gallery
+
+* [PeerTube](https://github.com/YunoHost-Apps/peertube_ynh)
+
+#### Federated Social Networking
+
+* [Mastodon](https://github.com/YunoHost-Apps/mastodon_ynh)
+* [Pleroma](https://github.com/YunoHost-Apps/pleroma_ynh)
+* [Mobilizon](https://github.com/YunoHost-Apps/mobilizon_ynh)
+
+#### Federated Blog
+
+* [Plume](https://github.com/YunoHost-Apps/plume_ynh)
+* [Writefreely](https://github.com/YunoHost-Apps/writefreely_ynh)
+
+#### Chat
+
+* [Mattermost](https://github.com/YunoHost-Apps/mattermost_ynh)
+
+## Conclusion
+
+YunoHost can cover 99% of the needs of non-profit organizations, allowing them to own and protect their data, choose applications they want to use.
+And if one is not available, they can [package it for YunoHost](/contributordoc), it's very simple.
diff --git a/use_case_non-profit_organisations_ca.md b/use_case_non-profit_organisations_ca.md
new file mode 100644
index 00000000..55d1a1ba
--- /dev/null
+++ b/use_case_non-profit_organisations_ca.md
@@ -0,0 +1,204 @@
+# YunoHost per a organitzacions sense ànim de lucre
+
+## Taula de continguts
+* [Introducció](#introduction)
+* [Qui](#who)
+* [Què](#what)
+* [Quan](#when)
+* [On](#where)
+* [Per què](#why)
+* [Com](#how)
+* [Conclusió](#conclusion)
+
+## Introducció
+
+L'objectiu d'aquest document és presentar un cas d'ús específic de [YunoHost](https://yunohost.org) per a organitzacions sense ànim de lucre.
+
+## Qui
+
+Organitzacions sense ànim de lucre, ONGs o qualsevol tipus d'associació.
+
+## Què
+
+Normalment les organitzacions sense ànim de lucre han de donar alguns serveis públics:
+
+* Consell d'administració / Comitè director / Voluntàries amb:
+ * [Correus electrònics](#mails)
+ * [Calendari](#calendar)
+ * [Contacte](#contact)
+ * [Fitxers compartits / Drive](#shared-files)
+ * [Missatgeria instantània](#instant-communication)
+ * [Intranet / base de coneixements](#intranet)
+ * [ERP / Comptabilitat](#erp-accounting)
+* Membres amb:
+ * [Pàgina web pública amb accés privat i individual](#public-web-site)
+ * [Adhesió](#membership)
+ * [Inscripció a esdeveniments](#events-registration)
+ * [Butlletí d'informació](#newsletter-mailing)
+ * [Fòrum](#forum)
+* Públic amb:
+ * [Pàgina web pública](#public-web-site)
+ * [Butlletí d'informació](#newsletter-mailing)
+
+## Quan
+
+Quan l'organització estigui preparada per a fer el pas.
+
+## On
+
+El servidor YunoHost de l'organització pot estar allotjat en diferents llocs:
+* Allotjament propi en un servidor, ordinador o Raspberry darrera una connexió ADSL, SDSL o fibra
+* Serveis d'allotjament de [Chatons](https://chatons.org), [librehosters](https://framagit.org/librehosters/awesome-librehosters)
+* Serveis d'allotjament comercials que ofereixin màquines virtuals Debian
+
+## Per què
+
+YunoHost pot cobrir la majoria de necessitats d'una organització sense ànim de lucre i permet tenir el control sobre les dades de l'organització.
+
+
+## Com
+
+### YunoHost
+
+YunoHost és una distribució GNU/Linux basada en Debian empaquetada amb programari lliure que automatitza la instal·lació d'un servidor web personal. L'objectiu de YunoHost és permetre a les usuàries allotjar fàcilment els seus propis serveis web al oferir una interfície web en la que es poden instal·lar diferents aplicacions només amb uns quants clics.
+
+
+
+YunoHost de base ofereix:
+* Un sistema d'aplicacions
+* Una interfície web
+* Una interfície per línia de comandes (CLI): Moulinette
+* Un servidor web: NGINX
+* Un servidor DNS: Dnsmasq
+* Una base de dades: MariaDB
+* Un sistema de còpies de seguretat
+* Un SSO: SSOwat
+* OpenLDAP
+* Correu electrònic:
+ * SMTP: Postfix
+ * IMAP & POP3: Dovecot
+ * Un antispam: rspamd, rmilter
+* Un servidor de missatgeria instantània XMPP: Metronome IM
+
+### Nom de domini
+
+La primera cosa que s'haurà de tenir per poder instal·lar un servidor YunoHost és un nom de domini. Habitualment el nom de domini el pot oferir el mateix servei d'allotjament.
+
+### Correus electrònics
+
+De base, YunoHost ofereix un sistema de correus electrònics disponible utilitzant POP / IMAP / SMTP.
+Els comptes de correu electrònic es poden gestionar per mitjà de la interfície web o de la línia de comandes. Els comptes creats es guarden en l'OpenLDAP.
+
+Es poden instal·lar paquets addicionals per donar més funcionalitats al sistema de correu electrònic de YunoHost:
+* Un client web utilitzant [Roundcube](https://github.com/YunoHost-Apps/roundcube_ynh), [Rainloop](https://github.com/YunoHost-Apps/rainloop_ynh)
+* ActiveSync utilitzant [Z-Push](https://github.com/YunoHost-Apps/z-push_ynh)
+* Un grup de difusió interna utilitzant [Mailman](https://github.com/YunoHost-Apps/mailman_ynh)
+
+### Calendari
+
+Per oferir calendaris personals o compartits haureu d'instal·lar:
+* [Nextcloud](https://github.com/YunoHost-Apps/nextcloud_ynh)
+* [Baikal](https://github.com/YunoHost-Apps/baikal_ynh)
+
+### Contactes
+
+Per oferir un sistema de contactes personal haureu d'instal·lar:
+* [Nextcloud](https://github.com/YunoHost-Apps/nextcloud_ynh)
+* [Baïkal](https://github.com/YunoHost-Apps/baikal_ynh)
+
+### Fitxers compartits
+
+Per oferir un sistema de fitxers compartit: carpetes personals i compartides, podeu instal·lar [Nextcloud](https://github.com/YunoHost-Apps/nextcloud_ynh).
+Els fitxers estaran disponibles a través d'una interfície web o bé utilitzant un client de sincronització.
+
+### Missatgeria instantània
+
+De base YunoHost ofereix un servidor XMPP, pel que podeu instal·lar un client web: [Jappix](https://github.com/YunoHost-Apps/jappix_ynh).
+
+També podeu instal·lar un servidor matrix:
+* El servidor: [Synapse](https://github.com/YunoHost-Apps/synapse_ynh)
+* Un client web: [Riot](https://github.com/YunoHost-Apps/riot_ynh)
+
+### Intranet
+
+Per a una organització sense ànim de lucre, una bona manera d'implementar una intranet és oferir una wiki interna per a que les usuàries puguin llegir, editar i afegir contingut. Vegeu aquí alguns paquets que permeten implementar una wiki:
+* [DokuWiki](https://github.com/YunoHost-Apps/docuwiki_ynh) utilitzant la sintaxi wiki
+* [Wiki.js](https://github.com/YunoHost-Apps/wikijs_ynh) utilitzant la sintaxi markdown
+
+### ERP / Comptabilitat
+
+Arribats a un cert punt una organització sense ànim de lucre podria necessitar un sistema de comptabilitat / ERP, aquí hi ha dos propostes:
+* [OpenERP/Odoo](https://github.com/YunoHost-Apps/libreerp_ynh)
+* [Dolibarr](https://github.com/YunoHost-Apps/dolibarr_ynh)
+
+### Pàgina web pública
+
+Hi ha múltiples maneres d'implementar una pàgina web pública:
+* Un pàgina simple amb HTML, CSS, etc. utilitzant: [Custom Webapp](https://github.com/YunoHost-Apps/my_webapp_ynh)
+* Utilitzant un CMS (sistema de gestió de contingut) com [Wordpress](https://github.com/YunoHost-Apps/_ynh), [Drupal](https://github.com/YunoHost-Apps/drupal_ynh) , [Grav](https://github.com/YunoHost-Apps/grav_ynh), [PluXml](https://github.com/YunoHost-Apps/pluxml_ynh)
+
+Però us proposem una alternativa una mica més potent: [CiviCRM on Drupal 7](https://github.com/YunoHost-Apps/civicrm_drupal7_ynh):
+* Drupal és un entorn de treball potent de codi obert per la gestió de contingut
+* amb CiviCRM que és un CRM de codi obert per a les organitzacions sense ànim de lucre
+
+### Adhesió
+
+Amb CiviCRM podeu tenir adhesions en línia i pagament.
+
+### Inscripció a esdeveniments
+
+Amb CiviCRM, podeu posar a disposició una agenda en línia per permetre als membres o al públic inscriure's gratuïtament o pagant.
+
+### Butlletí d'informació
+
+La millor manera de gestionar-ho és utilitzar el mòdul de llistes de difusió de CiviCRM.
+
+### Fòrum
+
+Hi ha múltiples opcions, tenir un fòrum integrat a Drupal o utilitzar un sistema dedicat com ara [Flarum](https://github.com/YunoHost-Apps/flarum_ynh).
+
+### Còpies de seguretat
+
+YunoHost ofereix el seu propi sistema de còpies de seguretat. Abans de cada actualització, YunoHost fa una còpia de seguretat de la versió actual del paquet i la restaura automàticament si falla l'actualització.
+Les còpies de seguretat de YunoHost s'emmagatzemen localment a `/home/yunohost.backup/archives`.
+
+Però per un servidor en producció, còpies de seguretat locals no són suficients, així que s'hauran d'implementar còpies de seguretat alternatives:
+* Còpia de seguretat de la màquina virtual si ho permet el sistema d'allotjament.
+* [Archivist](https://github.com/YunoHost-Apps/archivist_ynh) és un sistema de còpies de seguretat automàtiques del servidor. Les còpies de seguretat es poden enviar a d'altres llocs, locals o distants.
+* [Borg](https://github.com/YunoHost-Apps/borg_ynh) i [Borg Server](https://github.com/YunoHost-Apps/borgserver_ynh) permeten externalitzar les còpies de seguretat.
+* [Fallback](https://github.com/YunoHost-Apps/fallback_ynh), si teniu de servidors YunoHost, permet tenir un servidor secundari que pot ser utilitzat en cas que caigui el servidor principal. Aquest servidor secundari permetrà desplegar una còpia del servidor i tornar a posar en marxar YunoHost durant la caiguda.
+
+### Anar més enllà
+
+#### Galeria de fotografies federada
+
+* [Pixelfed](https://github.com/YunoHost-Apps/pixelfed_ynh)
+
+#### Galeria àudio federada
+
+* [Reel2Bits](https://github.com/YunoHost-Apps/reel2bits_ynh)
+* [Funkwhale](https://github.com/YunoHost-Apps/funkwhale_ynh)
+
+#### Galeria vídeo federada
+
+* [PeerTube](https://github.com/YunoHost-Apps/peertube_ynh)
+
+#### Xarxa social federada
+
+* [Mastodon](https://github.com/YunoHost-Apps/mastodon_ynh)
+* [Pleroma](https://github.com/YunoHost-Apps/pleroma_ynh)
+* [Mobilizon](https://github.com/YunoHost-Apps/mobilizon_ynh)
+
+#### Blog federat
+
+* [Plume](https://github.com/YunoHost-Apps/plume_ynh)
+* [Writefreely](https://github.com/YunoHost-Apps/writefreely_ynh)
+
+#### Xat
+
+* [Mattermost](https://github.com/YunoHost-Apps/mattermost_ynh)
+
+## Conclusió
+
+YunoHost por cobrir el 99% de les necessitats de les organitzacions sense ànim de lucre, permetent així que recuperin la sobirania i puguin protegir les seves dades, així com escollir les aplicacions que volen utilitzar.
+I si n'hi ha alguna que no està disponible, poden [empaquetar-la per YunoHost](/contributordoc), és molt senzill.
diff --git a/use_case_non-profit_organisations_fr.md b/use_case_non-profit_organisations_fr.md
new file mode 100644
index 00000000..dcf43fda
--- /dev/null
+++ b/use_case_non-profit_organisations_fr.md
@@ -0,0 +1,203 @@
+# YunoHost pour les organisations à but non lucratif
+
+## Table des matières
+* [Introduction](#introduction)
+* [Qui ](#qui)
+* [Quoi](#quoi)
+* [Quand](#quand)
+* [Où](#o-)
+* [Pourquoi](#pourquoi)
+* [Comment](#comment)
+* [Conclusion](#conclusion)
+
+## Introduction
+
+L'objet de ce document est de présenter une utilisation spécifique de [YunoHost](https://yunohost.org/) pour des organisations à but non lucratif.
+
+## Qui
+
+Organisations à but non lucratif, ONG ou tout type d'association.
+
+## Quoi
+
+Les organisations à but non lucratif doivent généralement fournir différents services à différents publics :
+
+* Conseil d'administration / Comité directeur / Bénévoles avec :
+ * [Mails](#mails)
+ * [Calendrier](#calendrier)
+ * [Contact](#contact)
+ * [Fichiers partagés / Drive](#fichiers-partag-s)
+ * [Communication instantanée](#communication-instantan-e)
+ * [Intranet / Base de connaissances](#intranet)
+ * [ERP / Comptabilité](#erp-comptabilit-)
+* Membres avec :
+ * [Site Web public avec accès privé et individuel](#site-web-public)
+ * [Adhésion](#adh-sion)
+ * [Inscriptions aux événements](#inscriptions-aux-v-nements)
+ * [Mailings](#newsletter-mailing)
+ * [Forum](#forum)
+* Public avec :
+ * [Site Web public](#site-web-public)
+ * [Newsletter](#newsletter-mailing)
+
+## Quand
+
+Lorsque l'organisation à but non lucratif est prête à franchir le pas.
+
+## Où
+
+Le serveur YunoHost peut être hébergé à différents endroits :
+* Hébergement en propre sur un serveur, un ordinateur ou Raspberry derrière ADSL, SDSL ou Fibre
+* [Chatons](https://chatons.org), [librehosters](https://framagit.org/librehosters/awesome-librehosters)
+* Services d'hébergement commercial fournissant une machine virtuelle Debian
+
+## Pourquoi
+
+YunoHost peut répondre à tous les besoins d'une organisation à but non lucratif et lui permettre de conserver la maîtrise de ses données.
+
+## Comment
+
+### YunoHost
+
+YunoHost est une distribution basée sur Debian GNU/Linux qui automatise l’installation d’un serveur Web personnel. Le but de YunoHost est de permettre aux utilisateurs d’héberger facilement leurs propres services Web en proposant une interface Web simple, pointer-cliquer, pour installer diverses applications Web.
+
+
+
+YunoHost fournit immédiatement:
+* Un système d'application
+* Une interface Web
+* Une interface de ligne de commande (CLI) : Moulinette
+* Un serveur Web : NGINX
+* Un serveur DNS : Dnsmasq
+* Une base de données : MariaDB
+* Un système de sauvegarde
+* Un SSO : SSOwat
+* OpenLDAP
+* Email :
+ * SMTP : Postfix
+ * IMAP & POP3 : Dovecot
+ * Un antispam : rspamd, rmilter
+* Serveur XMPP de messagerie instantanée : Metronome IM
+
+### Nom de domaine
+
+La première chose dont vous aurez besoin pour implémenter un serveur YunoHost est un nom de domaine. Le nom de domaine peut généralement être fourni avec votre service d'hébergement.
+
+### Mails
+
+YunoHost fournit par défaut un système de messagerie disponible en utilisant POP / IMAP / SMTP.
+Les comptes de messagerie seront gérés à l'aide de l'interface Web ou de la ligne de commande. Les comptes créés sont stockés dans OpenLDAP.
+
+Des packages supplémentaires peuvent être installés pour fournir davantage de fonctionnalités au système de messagerie YunoHost :
+* un webmail en utilisant [Roundcube](https://github.com/YunoHost-Apps/roundcube_ynh), [Rainloop](https://github.com/YunoHost-Apps/rainloop_ynh)
+* ActiveSync utilisant [Z-Push](https://github.com/YunoHost-Apps/z-push_ynh)
+* Groupe de distribution interne en utilisant [Mailman](https://github.com/YunoHost-Apps/mailman_ynh)
+
+### Calendrier
+
+Pour fournir des calendriers personnels ou partagés, vous devrez installer :
+* [Nextcloud](https://github.com/YunoHost-Apps/nextcloud_ynh)
+* [Baïkal](https://github.com/YunoHost-Apps/baikal_ynh)
+
+### Contact
+
+Pour fournir un système de contact personnel, vous devrez installer :
+* [Nextcloud](https://github.com/YunoHost-Apps/nextcloud_ynh)
+* [Baïkal](https://github.com/YunoHost-Apps/baikal_ynh)
+
+### Fichiers partagés
+
+Pour fournir un système de fichiers partagés : dossiers personnels et dossiers partagés, vous pouvez installer [Nextcloud](https://github.com/YunoHost-Apps/nextcloud_ynh).
+Les fichiers seront disponibles à partir d'une interface Web ou à l'aide d'un client de synchronisation.
+
+### Communication instantanée
+
+Par défaut, YunoHost fournit immédiatement un serveur XMPP pour lequel vous pouvez installer un client Web : [Jappix](https://github.com/YunoHost-Apps/jappix_ynh)
+
+Vous pouvez également installer un serveur Matrix :
+* Le serveur : [Synapse](https://github.com/YunoHost-Apps/synapse_ynh)
+* Un client Web : [Element](https://github.com/YunoHost-Apps/element_ynh)
+
+### Intranet
+
+Pour une organisation à but non lucratif, un bon moyen de mettre en œuvre un intranet est de fournir un wiki permettant aux utilisateurs internes de lire, éditer et ajouter du contenu. Voici quelques paquets pour implémenter un wiki :
+* [DokuWiki](https://github.com/YunoHost-Apps/docuwiki_ynh) utilisant une syntaxe wiki
+* [Wiki.js](https://github.com/YunoHost-Apps/wikijs_ynh) utilisant une syntaxe Markdown
+
+### ERP / Comptabilité
+
+À un moment donné, une organisation à but non lucratif pourrait avoir besoin d’un système de Comptabilité / ERP, voici deux propositions :
+* [OpenERP/Odoo](https://github.com/YunoHost-Apps/libreerp_ynh)
+* [Dolibarr](https://github.com/YunoHost-Apps/dolibarr_ynh)
+
+### Site Web Public
+
+Il existe plusieurs façons d'implémenter un site Web public :
+* Un simple site HTML, CSS, etc. en utilisant : [Custom Webapp](https://github.com/YunoHost-Apps/my_webapp_ynh)
+* Utiliser un CMS (système de gestion de contenu) comme [WordPress](https://github.com/YunoHost-Apps/_ynh), [Drupal](https://github.com/YunoHost-Apps/drupal_ynh), [Grav](https://github.com/YunoHost-Apps/grav_ynh), [PluXml](https://github.com/YunoHost-Apps/pluxml_ynh)
+
+Mais nous proposerons quelque chose de plus puissant : [CiviCRM on Drupal 7](https://github.com/YunoHost-Apps/civicrm_drupal7_ynh) :
+* Drupal qui est un puissant framework de gestion de contenu
+* avec CiviCRM qui est un CRM open source à destination des organisations à but non lucratif
+
+#### Adhésion
+
+Avec CiviCRM, vous pourrez mettre en place des adhésions en ligne avec paiement.
+
+#### Inscriptions aux événements
+
+Avec CiviCRM, vous pourrez mettre à disposition un agenda en ligne avec la possibilité pour les membres ou le public de s'inscrire gratuitement ou en payant.
+
+#### Newsletter/Mailing
+
+Le meilleur moyen de gérer cela consiste à utiliser CiviCRM et son module de mailing.
+
+### Forum
+
+Vous avez plusieurs choix, avoir un forum intégré dans Drupal ou utiliser un système de forum dédié tel que [Flarum](https://github.com/YunoHost-Apps/flarum_ynh).
+
+### Sauvegarde
+
+YunoHost fournit son propre système de sauvegarde. Avant toute mise à niveau de paquet, YunoHost sauvegarde la version actuelle du paquet et la restaure automatiquement si la mise à niveau échoue.
+Les sauvegardes YunoHost sont stockées localement dans `/home/yunohost.backup/archives`.
+
+Mais pour la production, la sauvegarde stockée localement ne suffit pas, vous devez donc mettre en œuvre des stratégies de sauvegarde supplémentaires :
+* Sauvegarde de la machine virtuelle si fournie par le système d'hébergement.
+* [Archivist](https://github.com/YunoHost-Apps/archivist_ynh) est un système de sauvegarde automatique de votre serveur. Vos sauvegardes peuvent être envoyées à de nombreux autres endroits, locaux ou distants.
+* [Borg](https://github.com/YunoHost-Apps/borg_ynh) and [Borg Server](https://github.com/YunoHost-Apps/borgserver_ynh) permettent d'externaliser les sauvegardes.
+* [Fallback](https://github.com/YunoHost-Apps/fallback_ynh), si vous avez deux serveurs YunoHost, fournissez un moyen d'avoir un serveur secondaire que vous pourrez utiliser si votre serveur principal tombe en panne. Ce serveur secondaire vous permettra de déployer une copie de votre serveur pour ramener votre YunoHost lors de votre panne.
+
+### Aller plus loin
+
+#### Galerie de photos fédérées
+
+* [Pixelfed](https://github.com/YunoHost-Apps/pixelfed_ynh)
+
+#### Galerie audio fédérée
+
+* [Reel2Bits](https://github.com/YunoHost-Apps/reel2bits_ynh)
+* [Funkwhale](https://github.com/YunoHost-Apps/funkwhale_ynh)
+
+#### Galerie vidéo fédérée
+
+* [PeerTube](https://github.com/YunoHost-Apps/peertube_ynh)
+
+#### Réseaux sociaux fédérés
+
+* [Mastodon](https://github.com/YunoHost-Apps/mastodon_ynh)
+* [Pleroma](https://github.com/YunoHost-Apps/pleroma_ynh)
+* [Mobilizon](https://github.com/YunoHost-Apps/mobilizon_ynh)
+
+#### Blog fédéré
+
+* [Plume](https://github.com/YunoHost-Apps/plume_ynh)
+* [Writefreely](https://github.com/YunoHost-Apps/writefreely_ynh)
+
+#### Chat
+
+* [Mattermost](https://github.com/YunoHost-Apps/mattermost_ynh)
+
+## Conclusion
+
+YunoHost peut couvrir 99% des besoins des organisations à but non lucratif, leur permettant de posséder et de protéger leurs données, de choisir les applications qu'elles souhaitent utiliser.
+Et s’ils ne sont pas disponibles, ils peuvent [les packager pour YunoHost](/contributordoc), c’est très simple.
diff --git a/use_case_non-profit_organisations_oc.md b/use_case_non-profit_organisations_oc.md
new file mode 100644
index 00000000..26297a99
--- /dev/null
+++ b/use_case_non-profit_organisations_oc.md
@@ -0,0 +1,203 @@
+# YunoHost per organizacion sens tòca lucrativa
+
+## Ensenhador
+* [Introduccion](#introduccion)
+* [Qual ](#qual)
+* [Qué](#qué)
+* [Quand](#quand)
+* [Ont](#ont)
+* [Perque](#perque)
+* [Cossí](#cossí)
+* [Conclusion](#conclusion)
+
+## Introduccion
+
+L'objectiu d’aqueste document es de presentar una utilizacion especifica de [YunoHost](https://yunohost.org/) per d’organizacions sens tòca lucrativa.
+
+## Qual
+
+Organizacions sens tòca lucrativa, ONG o qualque siá associacion.
+
+## Qué
+
+Las organizacions sens tòca lucrativa devon generalament fornir diferents servicis a diferents publics :
+
+* Conselh d'administracion / Comitat director / Benevòls amb :
+ * [Mails](#mails)
+ * [Calendièr](#calendièr)
+ * [Contacte](#contacte)
+ * [Fichièrs partejats / Drive](#fichièrs-partejats)
+ * [Comunicacion instantanèa](#comunicacion-instantan-a)
+ * [Intranet / Basa de coneissenças](#intranet)
+ * [ERP / Comptabilitat](#erp-comptabilitat)
+* Membres amb :
+ * [Site Web public amb accès privat e individual](#site-web-public)
+ * [Adhesion](#adhesion)
+ * [Inscripcions als eveniments](#inscriptions-als-eveniments)
+ * [Infoletras](#infoletras)
+ * [Forum](#forum)
+* Public amb :
+ * [Site Web public](#site-web-public)
+ * [Infoletras](#newsletter-mailing)
+
+## Quand
+
+Quand l'organizacion sens tòca lucrativa es prèsta a passar lo pas.
+
+## Ont
+
+Lo servidor YunoHost pòt èsser albergat a diferents endreches :
+* Albergament en pròpri sus un servidor, un ordenador o Raspberry darrièr una connexion ADSL, SDSL o Fibra
+* [Chatons](https://chatons.org), [librehosters](https://framagit.org/librehosters/awesome-librehosters)
+* Servicis d'albergament comercial que fornís una maquina virtuala Debian
+
+## Perque
+
+YunoHost pòt correspondre als besonhs d'una organizacion sens tòca lucrativa e li permetre de servar lo mestritge de sas donadas.
+
+## Cossí
+
+### YunoHost
+
+YunoHost es una distribucion basada sus Debian GNU/Linux qu’automatiza l’installacion d’un servidor Web personal. La tòca de YunoHost es de permetre als utilizaires d’albergar facilament lors pròpris servicis Web en prepausant una interfàcia Web simpla, als clics, per installar divèrsas aplicacions Web.
+
+
+
+YunoHost provesís sul pic:
+* Un sistèma d'aplicacion
+* Una interfàcia web
+* Una interfàcia en linha de comanda (CLI) : Moulinette
+* Un servidor Web : NGINX
+* Un servidor DNS : Dnsmasq
+* Una basa de donadas : MariaDB
+* Un sistèma de salvagarda
+* Un SSO: SSOwat
+* OpenLDAP
+* Corrièls :
+ * SMTP: Postfix
+ * IMAP & POP3 : Dovecot
+ * Un antispam : rspamd, rmilter
+* Servidor XMPP de messatjariá instantanèa : Metronome IM
+
+### Nom de domeni
+
+La primièra causa que vos fa mestièr per installar un servidor YunoHost es un nom de domeni. Lo nom de domeni pòt èsser generalament fornit amb lo servici d’albergament.
+
+### Corrièls
+
+A la prima installacion YunoHost fornís un sistèma de messatjariá disponible en utilizant POP / IMAP / SMTP.
+Los comptes de messatjariá seràn gerits amb l'interfàcia Web o en linha de comanda. Los comptes creats seràn gardats dins l’OpenLDAP.
+
+De paquets suplementaris pòdon èsser installats per provesir mai de foncionalitats al sistèma de messatjariá YunoHost :
+* un webmail en utilizant [Roundcube](https://github.com/YunoHost-Apps/roundcube_ynh), [Rainloop](https://github.com/YunoHost-Apps/rainloop_ynh)
+* ActiveSync utilizant [Z-Push](https://github.com/YunoHost-Apps/z-push_ynh)
+* Grop de distribucion intèrne en utilizant [Mailman](https://github.com/YunoHost-Apps/mailman_ynh)
+
+### Calendièr
+
+Per fornir de calendièrs personals o partejats, vos calrà installar :
+* [Nextcloud](https://github.com/YunoHost-Apps/nextcloud_ynh)
+* [Baïkal](https://github.com/YunoHost-Apps/baikal_ynh)
+
+### Contacte
+
+Per fornir un sistèma de contacte personal, vos caldrà installar :
+* [Nextcloud](https://github.com/YunoHost-Apps/nextcloud_ynh)
+* [Baikal](https://github.com/YunoHost-Apps/baikal_ynh)
+
+### Fichièrs partejats
+
+Per fornir un sistèma de fichièrs partejats : dorsièrs personals e dorsièrs partejats, podètz installar [Nextcloud](https://github.com/YunoHost-Apps/nextcloud_ynh).
+Las fichièrs seràn disponibles d’una interfàcia web estant o amb un client de sincronizacion.
+
+### Comunicacion instantanèa
+
+Tras l’installacion YunoHost fornís sul pic un servidor XMPP per lo qual podètz installar un client Web : [Jappix](https://github.com/YunoHost-Apps/jappix_ynh)
+
+Podètz tanben installar un servidor Matrix :
+* Lo servidor: [Synapse](https://github.com/YunoHost-Apps/synapse_ynh)
+* Un client web: [Riot](https://github.com/YunoHost-Apps/riot_ynh)
+
+### Intranet
+
+Per una organizacion sens tòca lucrativa, un bon biais de metre en plaça un intranet es de fornir un wiki que permet als utilizaires intèrne de legir, modificar e ajustar de contengut. Vaquí unes paquets per installar un wiki :
+* [DokuWiki](https://github.com/YunoHost-Apps/docuwiki_ynh) utiliza la sintaxi wiki
+* [Wiki.js](https://github.com/YunoHost-Apps/wikijs_ynh) utiliza la sintaxi markdown
+
+### ERP / Comptabilitat
+
+Arriba un moment ont a l’organizacion sens tòca lucrativa li pòsca far besonh un sistèma de comptabilitat / ERP, vaquí doas proposicions :
+* [OpenERP/Odoo](https://github.com/YunoHost-Apps/libreerp_ynh)
+* [Dolibarr](https://github.com/YunoHost-Apps/dolibarr_ynh)
+
+### Site Web Public
+
+Existís mantuns biaisses de construire un site Web public :
+* Un simple site HTML, CSS, etc. en utilizant : [Custom Webapp](https://github.com/YunoHost-Apps/my_webapp_ynh)
+* Utilizar un CMS (sistèma de gestion de contengut) coma [Wordpress](https://github.com/YunoHost-Apps/_ynh), [Drupal](https://github.com/YunoHost-Apps/drupal_ynh), [Grav](https://github.com/YunoHost-Apps/grav_ynh), [PluXml](https://github.com/YunoHost-Apps/pluxml_ynh)
+
+Mas prepausam quicòm de mai potent : [CiviCRM on Drupal 7](https://github.com/YunoHost-Apps/civicrm_drupal7_ynh) :
+* Drupal qu’es un framework potent de gestion de contengut
+* amb CiviCRM qu’es un CRM OpenSource a destinacion de las organizacions sens tòca lucrativa
+
+#### Adhesion
+
+Amb CiviCRM, poiretz metre en plaça d’adhesions en linha amb pagament.
+
+#### Inscripcions als eveniments
+
+Amb CiviCRM, poiretz metre a disposicion un agenda en linha amb la possibilitat pels membres o lo public de s’inscriure gratuitament o en pagant.
+
+#### Infoletra/Lista de difusion
+
+Çò melhor per gerir aquò es d’utilizar CiviCRM e son modul de lista de difusion.
+
+### Forum
+
+Avètz mantun possibilitats, aver un forum integrat a Drupal o utilizar un sistèma dedicat coma [Flarum](https://github.com/YunoHost-Apps/flarum_ynh).
+
+### Salvagarda
+
+YunoHost fornís son pròpri sistèma de salvagarda. Abans tota mesa a nivèl de paquet, YunoHost salvagarda la version actuala del paquet e la restaura automaticament se la mesa a nivèl se debana pas corrèctament.
+Las salvagardas YunoHost son gardadas localament dins `/home/yunohost.backup/archives`.
+
+Mas per la produccion, la salvagarda gardada localament basta pas, vos cal emplegar d’estrategias de salvagarda suplementàrias :
+* Salvagarda de la maquina virtuala se fornida pel sistèma d’albergament.
+* [Archivist](https://github.com/YunoHost-Apps/archivist_ynh) es un sistèma de salvagarda automatic de vòstre servidor. Vòstras salvagardas pòdon èsser enviadas a mantun endreches, locals o alonhats.
+* [Borg](https://github.com/YunoHost-Apps/borg_ynh) e [Borg Server](https://github.com/YunoHost-Apps/borgserver_ynh) permeton d’externalizar las salvagardas.
+* [Fallback](https://github.com/YunoHost-Apps/fallback_ynh), se avètz dos servidors YunoHost, ajatz los mejans d’aver un servidor segondari que poiretz utilizar se lo primièr ven a foncionar pas mai. Aqueste servidor segondari vos permetrà de restablir una còpia de vòstre servidor per dire de corregir los problèmas de l’autre servidor YunoHost.
+
+### Anar mai luènh
+
+#### Galariá de fotografias federada
+
+* [Pixelfed](https://github.com/YunoHost-Apps/pixelfed_ynh)
+
+#### Galariá àudio federada
+
+* [Reel2Bits](https://github.com/YunoHost-Apps/reel2bits_ynh)
+* [Funkwhale](https://github.com/YunoHost-Apps/funkwhale_ynh)
+
+#### Galariá vidèo federada
+
+* [PeerTube](https://github.com/YunoHost-Apps/peertube_ynh)
+
+#### Malhums socials federats
+
+* [Mastodon](https://github.com/YunoHost-Apps/mastodon_ynh)
+* [Pleroma](https://github.com/YunoHost-Apps/pleroma_ynh)
+* [Mobilizon](https://github.com/YunoHost-Apps/mobilizon_ynh)
+
+#### Blog federats
+
+* [Plume](https://github.com/YunoHost-Apps/plume_ynh)
+* [Writefreely](https://github.com/YunoHost-Apps/writefreely_ynh)
+
+#### Chat
+
+* [Mattermost](https://github.com/YunoHost-Apps/mattermost_ynh)
+
+## Conclusion
+
+YunoHost pòt cumplir 99% dels besonhs de las organizacions sens tòca lucrativa, en lor permetent de téner e protegir lors donadas, de causir las aplicacions que vòlon utilizar.
+E se son pas disponiblas, pòdon [crear un paquet per YunoHost](/contributordoc), es fòrça simple.
diff --git a/users.md b/users.md
new file mode 100644
index 00000000..a5c7154d
--- /dev/null
+++ b/users.md
@@ -0,0 +1,35 @@
+# Users and the SSO
+
+## Users
+
+Users are human being who have access to applications and other services on your server. The administrator can add and manage users through the web administration (in the User category) or through the command line (see `yunohost user --help`). After that, users obtain a personal email address (chosen by the admin), an XMPP account, and can log in the user portal to access applications they have permissions over and configure other parameters.
+
+The first user created also automatically gets email aliases `root@main.domain.tld` and `admin@main.domain.tld`, such that mail sent to these adresses will end up in the first user's mailbox.
+
+
+You should be careful about who you give your server access to. In terms of security, this largely increase the attack surface for someone who wants to mess with the server one way or another.
+
+
+## The user portal, or SSO
+
+
+
+The user portal, also called the SSO for 'Single Sign On' allows user to browse easily between the different apps they have access to. In particular, the term 'Single Sign On' comes from the fact that user only need to log in the portal to automatically be logged to all apps that require authentication (or at least those who are integrated with the SSO/LDAP, since this is sometimes technically complicated or not possible at all).
+
+In the portal, users can also click on the avatar in the top-left to configure some other settings such as their identify, mail aliases, automatic mail forwards, or change their password.
+
+
+You should be aware that the SSO can only be reached through the actual domain name (i.e. `https://the.domain.tld/yunohost/sso`), and NOT by just using the IP of the server (i.e. `https://11.22.33.44/yunohost/sso`), contrarily to the webadmin ! This is a bit confusing but is necessary for technical reason. If you are in a situation where you need to access the SSO without having your DNS properly configured for some reason, you might consider tweaking your `/etc/hosts` as described in [this page](dns_local_network).
+
+
+## User groups and permissions
+
+See [this dedicated page](groups_and_permissions).
+
+## SSH access
+
+Users can also be allowed to connect through SSH, and SSH keys can be added for this purpose. So far, this can only be configured via the command line. See `yunohost user ssh --help` for specific commands.
+
+
+Be careful who you give SSH access to. This increases even more the attack surface available to a malicious user.
+
diff --git a/users_fr.md b/users_fr.md
new file mode 100644
index 00000000..fe236849
--- /dev/null
+++ b/users_fr.md
@@ -0,0 +1,35 @@
+# Les utilisateurs et le SSO
+
+## Utilisateurs
+
+Les utilisateurs sont les êtres humains qui ont accès aux applications et autres services sur votre serveur. L'administrateur peut ajouter et gérer des utilisateurs via l'administration web (dans la catégorie Utilisateurs) ou via la catégorie `yunohost user` de la ligne de commande. Après cela, les utilisateurs obtiennent une adresse e-mail personnelle (choisie par l'administrateur), un compte XMPP, et peuvent se connecter au portail utilisateur (SSO) pour accéder aux applications pour lesquelles ils ont des permissions et configurer d'autres paramètres.
+
+Le premier utilisateur créé reçoit aussi automatiquement les alias email `root@main.domain.tld` et `admin@main.domain.tld`, de sorte que le courrier envoyé à ces adresses se retrouvera dans la boîte aux lettres de cet utilisateur.
+
+
+Vous devriez faire attention à qui vous donnez l'accès à votre serveur. En termes de sécurité, cela augmente considérablement la surface d'attaque pour quelqu'un qui veut perturber le serveur d'une manière ou d'une autre.
+
+
+## Le portail utilisateur, ou SSO
+
+
+
+Le portail utilisateur, également appelé SSO pour 'Single Sign On', permet à l'utilisateur de naviguer facilement entre les différentes applications auxquelles il a accès. En particulier, le terme 'Single Sign On' vient du fait que l'utilisateur n'a qu'à se connecter au portail pour être automatiquement connecté à toutes les applications qui nécessitent une authentification (ou du moins celles qui sont intégrées avec le SSO/LDAP, car cela est parfois techniquement compliqué ou pas possible du tout).
+
+Dans le portail, les utilisateurs peuvent également cliquer sur l'avatar en haut à gauche pour configurer d'autres paramètres tels que leur identité, les alias de messagerie, les transferts automatiques de courrier ou changer leur mot de passe.
+
+
+Vous devez être conscient que le SSO ne peut être atteint que par le nom de domaine (c.-à-d. `https://the.domain.tld/yunohost/sso`), et non pas en utilisant l'IP du serveur (c.-à-d. `https://11.22.33.44/yunohost/sso`), contrairement à l'administrateur web ! C'est un peu déroutant dans certaines situations, mais c'est nécessaire pour des raisons techniques. Si vous êtes dans une situation où vous avez besoin d'accéder au SSO sans avoir votre DNS correctement configuré pour une raison quelconque, vous pouvez envisager de modifier votre `/etc/hosts` comme décrit dans [cette page](dns_local_network).
+
+
+## Gestion des groupes d'utilisateurs et permissions
+
+Voir [cette page de documentation dédiée](groups_and_permissions).
+
+## Accès SSH
+
+Les utilisateurs peuvent également être autorisés à se connecter via SSH, et des clés SSH peuvent être ajoutées à cette fin. Jusqu'à présent, ceci ne peut être configuré que via la ligne de commande. Voir `yunohost user ssh --help` pour des commandes spécifiques.
+
+
+Faites attention à qui vous donnez accès à SSH. Cela augmente encore plus la surface d'attaque disponible pour un utilisateur malveillant.
+
diff --git a/vpn_advantage.md b/vpn_advantage.md
new file mode 100644
index 00000000..d2244385
--- /dev/null
+++ b/vpn_advantage.md
@@ -0,0 +1 @@
+Unfortunately, this page only exists [in french here](vpn_advantage_fr) for now.
diff --git a/vpn_advantage_fr.md b/vpn_advantage_fr.md
new file mode 100644
index 00000000..26a22708
--- /dev/null
+++ b/vpn_advantage_fr.md
@@ -0,0 +1,46 @@
+# Avantage d’un VPN pour l’auto-hébergement
+
+L'installation d'un serveur chez soi étant une pratique peu courante, la plupart des connexions Internet fournies aux particuliers sont inadaptées à sa mise en pratique. Un VPN respectant la neutralité du net et fournissant une adresse IPv4 fixe et des adresses IPv6 peut permettre de contourner certaines limitations ou certaines difficultés.
+
+
+Attention : tous les fournisseurs VPN existants ne remplissent pas ces conditions, assurez-vous bien que celui que vous choisissez les remplis.
+
+
+## Avantages
+
+### Plug & Play
+En configurant un VPN sur votre serveur, vous serez en mesure de le rendre accessible au reste d'Internet sans avoir à modifier la configuration du routeur auxquel vous le branchez. Ce point peut être vraiment pratique si vous partez en vacances, que vous déménagez ou si vous avez une coupure d'Internet, car vous serez en mesure de le brancher facilement chez une personne de confiance sans avoir besoin de configurer le routeur de la personne qui vous aide.
+
+De la même façon, vous vous économisez l'ouverture des ports de votre routeur ainsi que le contournement du hairpinning.
+
+### Pas de micro-coupure DNS
+Si votre connexion Internet n'a pas d'IP publique fixe, vous serez obligé de mettre en place un nom de domaine dynamique (Dynamique DNS). Cette solution peut être acceptable, mais la mise à jour du DNS ne se fera qu'à intervalle régulier (Toutes les deux minutes si c'est un nom de domaine en `noho.st` ou `nohost.me`). Il y a donc une chance que cela provoque de temps en temps des erreurs d'affichage dans le navigateur, voir même qu'un autre site s'affiche (les risques sont toutefois réduit car la pratique de l'auto-hébergement n'est pas répandue).
+
+Avec un VPN neutre, ce problème est contourné car le VPN peut être comparé à une connexion Internet Virtuelle, qui a sa propre adresse IPv4 fixe, dès lors plus besoin de mettre à jour le nom de domaine.
+
+### Le cas du mail
+Le mail est un des protocoles les plus complexes à auto-héberger, en général c'est ce qu'un utilisateur auto-héberge en dernier. En effet, il est très facile de se retrouver dans une situation où les emails envoyés par le serveur sont refusés par les serveurs SMTP destinataires.
+
+Pour éviter ça il faut entre autre :
+- configurer le reverse DNS de la connexion Internet (ou du VPN) du serveur
+- une IPv4 fixe
+- que cette IPv4 soit enlevable de toutes les listes noire (notamment l'IP ne doit pas être sur le DUL)
+- pouvoir ouvrir le port 25 (ainsi que les autres ports SMTP)
+
+Malheureusement, aucun des FAI français les plus courants ne respecte la totalité de ces points.
+
+Pour pallier cela, l'usage d'un VPN respectant ces points peut être une alternative.
+
+### Confiance
+Enfin, si vous ne souhaitez pas que le contenu des communications de votre serveur soit espionnable par des équipements présent sur le réseau de votre Fournisseur d'Accès Internet, vous pouvez utiliser un VPN pour chiffrer vos communications et déporter votre confiance sur un fournisseur de VPN. Rappel, depuis 2015, le gouvernement déploie officiellement des boîtes noires chez les gros opérateurs réseau qui ont pour objectif de mettre sur écoute l'ensemble des communications numériques françaises entre autre pour préserver les intérêts scientifiques, économiques et industrielles de la France.
+
+## Inconvénient
+### Coût
+Un VPN neutre a un coût puisque l'opérateur qui le fournis doit faire fonctionner un serveur et utiliser de la bande passante. Les prix des VPN associatifs de la FFDN sont autour de 6 € par mois.
+
+### Trajet des paquets
+Lorsque l'on met en place un VPN sur son serveur, si on ne met pas en place de configuration particulière, le transfert d'un fichier d'un ordinateur du réseau local vers le serveur utilisant le VPN, passera par le bout du VPN c'est-à-dire par le serveur du fournisseur de VPN.
+
+Pour pallier ce point, il y a deux solutions :
+- transformer son serveur en routeur et connecter les équipements de la maison à ce dernier, ces équipements bénéficieront alors de la confidentialité du VPN également.
+- utiliser le serveur YunoHost comme résolveur DNS lorsque l'on est chez soi, de façon à rediriger les noms de domaines du serveur l'ip locale plutôt que l'ip publique. Cette opération peut se faire soit sur chaque équipements, soit sur le routeur (si ce dernier le permet).
diff --git a/whatsyunohost.md b/whatsyunohost.md
new file mode 100644
index 00000000..70d34bb2
--- /dev/null
+++ b/whatsyunohost.md
@@ -0,0 +1,53 @@
+# What is YunoHost?
+
+
+
+YunoHost is an **operating system** aiming for the simplest administration of a **server**, and therefore democratize [self-hosting](selfhosting), while making sure it stays reliable, secure, ethical and lightweight. It is a copylefted libre software project maintained exclusively by volunteers. Technically, it can be seen as a distribution based on [Debian GNU/Linux](https://debian.org) and can be installed on [many kinds of hardware](install).
+
+## Features
+
+-
Based on Debian;
+-
Administrate your server through a **friendly web interface** ;
+-
Deploy **apps in just a few clicks**;
+-
Manage **users** (based on LDAP);
+-
Manage **domain names**;
+-
Create and restore **backups**;
+-
Connect to all apps simultaneously through the **user portal** (NGINX, SSOwat);
+-
Includes a **full e-mail stack** (Postfix, Dovecot, Rspamd, DKIM);
+-
... as well as **an instant messaging server** (XMPP);
+-
Manages **SSL certificates** (based on Let's Encrypt) ;
+-
... and **security systems** (Fail2ban, yunohost-firewall);
+
+## Origin
+
+YunoHost was created in February 2012 after something like this:
+
+ "Shit, I'm too lazy to reconfigure my mail server... Beudbeud, how were you able to get your little server running with LDAP?"
+Kload, February 2012
+
+All that was needed was an admin interface for Beudbeud's server to make something usable, so Kload decided to develop one. Finally, after automating several configs and packaging in some web apps, YunoHost v1 was finished.
+
+Noting the growing enthusiasm around YunoHost and around self-hosting in general, the original developers along with new contributors decided to start work on version 2, a more extensible, more powerful, more easy-to-use, and at that, one that makes a nice cup of fair-trade coffee for the elves of Lapland.
+
+The name **YunoHost** comes from the jargon "Y U NO Host". The [Internet meme](https://en.wikipedia.org/wiki/Internet_meme) should illustrate it:
+
+
+## What YunoHost is not?
+
+Even if YunoHost can handle multiple domains and multiple users, it is **not meant to be a mutualized system**.
+
+First, the software is too young, not tested at scale and thus probably not optimized well enough for hundreds of users at the same time. With that said, we do not want to lead the software in that direction. Virtualization democratizes, and its usage is recommended since it is a more watertight way to achieve mutualization than a "full-stack" system like YunoHost.
+
+You can host your friends, your family and your company safely and with ease, but you must **trust your users**, and they must trust you above all. If you want to provide YunoHost services for unknown persons anyway, a full VPS per user will be just fine, and we believe a better way to go.
+
+## Artworks
+
+Black and white YunoHost PNG logo by ToZz (400 × 400 px):
+
+
+
+
+
+Click to download.
+
+Licence: CC-BY-SA 4.0
diff --git a/whatsyunohost_ar.md b/whatsyunohost_ar.md
new file mode 100644
index 00000000..d1776397
--- /dev/null
+++ b/whatsyunohost_ar.md
@@ -0,0 +1,87 @@
+#ماذا نعني بـ واي يونوهوست YunoHost ؟
+
+
+واي يونوهوست YunoHost هو **نظام لتشغيل الخوادم** صُمِّم لتسهيل الإستضافة الذاتية لخدمات الإنترنت.
+هو مُرتكز و منسجم كافة الإنسجام مع توزيعة [غنو/لينكس ديبيان](https://debian.org).
+
+
+
+
+---
+
+### خصائصه
+
+
+- متعدد المستعملين مع تكامُل LDAP
+- متعدد النطاقات
+- خدمة البريد الإلكتروني
+- خادم المراسلة الفورية
+- نظام للمصادقة الموحَّدة (SSO)
+- نظام للتطبيقات
+- نظام للنسخ الإحتياطي
+- نظام لإعادة توليد الإعدادات و الخدمات
+
+
+
+
+---
+
+### أصل فكرة المشروع
+
+
+تعود نشأة فكرة مشروع واي يونوهوست YunoHost إلى شهر فيفري مِن عام 2012 بعد محادثة بدأت على هذا الشكل تقريبًا :
+
+ « تبًا، لقد سئِمتُ مِن إعادة إعداد خادم البريد الإلكتروني ... Beudbeud، كيف قُمتَ بإعداد خادومك الجميل حول LDAP ؟ »
+Kload، فيفري 2012
+
+
+Il ne manquait en fait qu’une interface d’administration au serveur de Beudbeud pour en faire quelque chose d’exploitable, alors Kload a décidé de la développer. Finalement, après l’automatisation de quelques configurations et le packaging de quelques applications web, la première version de YunoHost était sortie.
+
+Constatant l’engouement croissant autour de YunoHost et de l’auto-hébergement en général, les développeurs et les nouveaux contributeurs ont alors décidé de prendre le cap d’une version 2, plus accessible, plus extensible, plus puissante, et qui prépare du bon café commerce équitable pour les lutins de Laponie.
+
+
+---
+
+### الهدف
+
+يهدف واي يونوهوست YunoHost إلى تسهيل عملية تنصيب و تثبيت و إدارة أي خادمٍ لأكبر عدد ممكن مِن الناس و ذلك دون المساس بجودة و موثوقية البرمجيات.
+
+لم يُدَّخر أي جهد لتسهيل عملية التنصيب و الإنبساط وذلك على أكبر عدد ممكن مِن الأجهزة مهما اختلفت مميزات كل جهاز (في المنزل أو على خادوم إستضافة أو على خادوم شخصي إفتراضي)
+
+
+---
+
+### التسمية
+
+
+**YunoHost** مُستمَدٌّ مِن لُغة الإنترنت العاميّة « Y U NO Host » و بالمعنى التقريبي « لماذا لا تستضيف نفسك بنفسك ». [ميم الإنترنت](https://ar.m.wikipedia.org/wiki/%D9%85%D9%8A%D9%85_%D8%A5%D9%86%D8%AA%D8%B1%D9%86%D8%AA) الذي يصف المعنى بالتقريب هو :
+
+
+
+---
+
+### التطوير
+
+YunoHost est développé pour être le plus **simple** et le moins intrusif possible pour garder la compatibilité avec Debian. Il propose uniquement un ensemble de configurations automatiques et opère via des interfaces accessibles.
+
+Le tout est bien entendu **entièrement libre**. La philosophie de l’[الإستضافة الذاتية](/selfhosting) étant à nos yeux incompatible avec tout autre modèle de développement logiciel.
+
+لا تتردّدوا في زيارة صفحة « [ساهموا](/contribute) ».
+
+
+---
+
+### واي يونوهوست YunoHost ليس
+
+Même si YunoHost est multi-domaine et multi-utilisateur, il reste **inapproprié pour un usage mutualisé**.
+
+Premièrement parce que le logiciel est trop jeune, donc non-testé et non-optimisé pour être mis en production pour des centaines d’utilisateurs en même temps. Et quand bien même, ce n’est pas le chemin que l’on souhaite faire suivre à YunoHost. La virtualisation se démocratise, et c’est une façon bien plus étanche et sécurisée de faire de la mutualisation.
+
+Vous pouvez héberger vos amis, votre famille ou votre entreprise sans problème, mais vous devez **avoir confiance** en vos utilisateurs, et ils doivent de la même façon avoir confiance en vous. Si vous souhaitez tout de même fournir des services YunoHost à des inconnus, **un VPS entier par utilisateur** sera la meilleure solution.
+
diff --git a/whatsyunohost_de.md b/whatsyunohost_de.md
new file mode 100644
index 00000000..959ffd34
--- /dev/null
+++ b/whatsyunohost_de.md
@@ -0,0 +1,52 @@
+# Was ist YunoHost?
+
+