Le serveur physiquement hébergé chez le collectif social web propose plusieurs services web. Cette page décrit ce que l'on a mis en place ainsi que la configuration que nous avons utilisé.

Pour chaque service, on essaie de désigner un responsable. C'est la personne qu'il faut contacter en cas de problème. Ça ne veut pas dire que personne d'autre ne peut toucher au service en question, mais d'une manière générale, il est toujours préférable qu'une personne soit en charge de la maintenance.

Un responsable devra:

• Intervenir en cas de problème sur le service pour le rétablir.
• Se charger de mettre à jour le service.
• Se charger de documenter comment le service à été configuré sur ce wiki.

Quelques bonnes pratiques pour les responsables de service:

• Essayer de trouver un flux RSS avertissant des mises à jour de vos services.
• Quand vous faites un script, assurez-vous d'être alerté des potentielles erreurs (par mail, irc, pushover, slack, ce que vous voulez) afin qu'on ne se retrouve pas avec des backups inutilisables.

Le serveur est actuellement hébergé derrière de la fibre orange. Orange propose de base une adresse IP dynamique (ie. elle change à chaque redémarrage de la box). On ne souhaite pour l'instant pas payer de supplément inutile, on utilise donc un nom de domaine DynDns pour accéder à la machine.

Le serveur est pour l'instant accessible depuis son nom de domaine no-ip . Loris possède pour l'instant les identifiants no-ip si besoin.

On peut accéder à ce serveur via ssh sur le port 5544. Vous pouvez ajouter une entrée dans votre ~/.ssh/config afin de vous connecter plus facilement.

Host baio
 HostName baionet.hopto.org
 User $user
 Port 5544

(remplacez $user par votre login).

Vous pouvez dès lors vous connecter au serveur à l'aide d'un simple

ssh baio

Si vous souhaitez un accès à cette machine, demandez à Loris, Thierry, Éric ou Félix de vous en créer un.

Nous utilisons Nginx en mode reverse proxy pour la plupart de nos services.

Pour créer un nouveau service, créez dans un premier temps son fichier de configuration dans le dossier /etc/nginx/sites-available/${service}.conf.

On va partir de la base suivante:

server {
    listen 80;
    server_name ${service}.baionet.fr;
    location '/.well-known/acme-challenge' {
          default_type "text/plain";
          root         /tmp/letsencrypt-auto/;
    }
    location / {
        return         301 https://${service}.baionet.fr$request_uri;
    }
}

server {
    listen [::]:443 ssl;
    listen 443 ssl;

    server_name ${service}.baionet.fr;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    ssl_certificate /etc/letsencrypt/live/${service}.baionet.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/${service}.baionet.fr/privkey.pem;

    [...]
}

Nous proposons tous nos services via HTTPS, nous allons donc rediriger les requêtes HTTP entrantes vers leur pendant HTTPS. Nous redirigeons également les challenges ACME (necessaire à la génération d'un certificat) vers le dossier adéquat. Voir la partie sur let's encrypt pour apprendre à générer les certificats HTTPS.

Côté configuration du serveur HTTPS, on n'oublie pas de rajouter le header HSTS ainsi que la directive d'écoute en IPv6, nécessaire pour servir à la fois en IPv4 et IPv6.

Le reste de la configuration de votre service se fera à la place du symbole […] dans l'exemple ci-dessus.

Une fois le fichier de configuration écrit, on va l'activer en créant un lien symbolique le pointant dans le dossier /etc/nginx/sites-enabled

cd /etc/nginx/sites-enabled
sudo ln -s /etc/nginx/sites-available/${service} ${service}.conf

Note: le lien doit obligatoirement avoir le suffixe “.conf” pour être chargé par Nginx.

ATTENTION: on est maintenant dans une situation un poil critique. Si notre fichier de configuration n'est pas valide pour une raison ou une autre et qu'on tente de redémarrer nginx, il va s'arrêter sans pouvoir redémarrer. Techniquement, on appelle cette situation LA PLS.

Du coup, on est malin, et avant de redémarrer le service, on teste la configuration avec

sudo nginx -t

S'il y a une erreur, on la corrige et on re-teste.

Si tout roule, on peut alors redémarrer le service nginx afin que notre nouvelle configuration soit prise en compte:

sudo systemctl restart nginx

Afin de proposer un service en HTTPS, on a besoin de d'abord générer un certificat. On va utiliser certbot pour cet effet.

Il y a plusieurs manières d'utiliser certbot, dans notre cas, on va l'utiliser en mode “certonly”: ça nous permettra de générer le certificat sans avoir à arrêter Nginx.

Avant toute chose, on va s'assurer que l'on a bien ajouté la nouvelle entrée dans le fichier de zone DNS et que le changement c'est bien propagé.

Ensuite, on va enlever toute la partie TLS de notre service (depuis la config décrite dans la section nginx) en la commentant.

server {
    listen 80;
    server_name ${service}.baionet.fr;
    location '/.well-known/acme-challenge' {
          default_type "text/plain";
          root         /tmp/letsencrypt-auto/;
    }
    location / {
        return         301 https://${service}.baionet.fr$request_uri;
    }
}

#server {
#    listen [::]:443 ssl;
#    listen 443 ssl;
#
#    server_name ${service}.baionet.fr;
#    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
#    ssl_certificate /etc/letsencrypt/live/${service}.baionet.fr/fullchain.pem;
#    ssl_certificate_key /etc/letsencrypt/live/${service}.baionet.fr/privkey.pem;
#
#    [...]
#}

Note: bien vérifier que le répertoire /tmp/letsencrypt-auto existe sur le disque. Le créer si ce n'est pas le cas.

On teste pour vérifier que tout est ok:

% sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

S'il y a une erreur, on arrête tout là et on la corrige avant de continuer.

On peut redémarrer le serveur web

sudo systemctl restart nginx

Le nouveau service devrait à présent pouvoir répondre à un challenge ACME. Il ne nous reste plus qu'à générer un certificat à l'aide de la commande suivante:

sudo certbot certonly --webroot-path "/tmp/letsencrypt-auto/" -d "${service}.baionet.fr"

Si un message de succès s'affiche, vous êtes tout bon.

Il ne vous reste plus qu'à dé-commenter la partie HTTPS de la configuration Nginx précédemment commentée:

server {
    listen 80;
    server_name ${service}.baionet.fr;
    location '/.well-known/acme-challenge' {
          default_type "text/plain";
          root         /tmp/letsencrypt-auto/;
    }
    location / {
        return         301 https://${service}.baionet.fr$request_uri;
    }
}

server {
    listen [::]:443 ssl;
    listen 443 ssl;

    server_name ${service}.baionet.fr;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    ssl_certificate /etc/letsencrypt/live/${service}.baionet.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/${service}.baionet.fr/privkey.pem;

    [...]
}

Testez à nouveau si la configuration est valide:

sudo nginx -t

Si tout roule, vous pouvez redémarrer nginx:

sudo systemctl restart nginx

Et voilà. La certificat devrait être renouvelé automatiquement par le script de renouvellement, vous n'avez plus rien à faire, vous pouvez continuer à configurer votre service.

Responsable: Félix

Les certificats TLS fournis par let's encrypt ne sont valides que pour 2 mois, c'est assez fatiguant de les renouveler manuellement, c'est pourquoi nous avons mis en place un système de renouvellement automatique qui va tenter de les renouveler tous les 1 et 15 du mois.

Ce script se trouve dans le dossier /root/letsencrypt/run.sh:

#!/usr/bin/env bash
root="/tmp/letsencrypt-auto/"
mkdir -p ${root}
certbot renew
systemctl restart nginx.service

Il se charge de renouveler les certificats et de redémarrer nginx.

Il est déclenché par une règle cron sur le user root:

baionet-server# crontab -l
# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
0 0 1,15 * * /root/letsencrypt/run.sh 2>&1 | mail -s "Certificate renewal on baionet.fr" ${adresse_mail_de_felix}

Sauf cas de problème, vous n'avez probablement pas à y toucher, je laisse surtout ça ici pour documenter ;)

Responsable: Félix

L'installation se trouve dans le dossier /var/www/dokuwiki/.

Dokuwiki ne nécessite pas de base de données, tout est stocké dans des fichiers plats.

Pour l'instant, le wiki est lisible par tout le monde mais uniquement modifiable par les utilisateurs enregistrés. L'administrateur est en charge de créer les comptes.

Bien que l'éditeur de texte de base soit parfait pour les utilisateurs avancés, le système de balises dokuwiki de base peut être un peu intimidant pour les utilisateurs non techniques. Afin de rendre la rédaction d'articles accessible à tout le monde, nous avons installé le plugin ckgedit à l'aide du gestionnaire de plugins de dokuwiki.

Tout est stocké dans des fichiers plats, du coup on se contente de tout zipper et de mettre ça de côté:

#!/usr/bin/env bash
tar -cjf /home/felix/backups/wiki.tar.bz2 /var/www/dokuwiki
chown felix:users /home/felix/backups/wiki.tar.bz2

Tout ça est stocké dans le fichier /root/dokuwiki/ et est exécuté tous les jours à minuit à l'aide de la tache cron suivante:

  0 0   *   *   *   /root/dokuwiki/backup.sh

Le fichier est ensuite automatiquement récupéré par Félix à l'aide d'un autre script tournant sur son ordinateur.

Responsable: Loris

L'installation est située dans /var/www/html/cloud.

Il n'existe pour l'instant pas de solution de backup sur le service de cloud mais du rsync incrémentiel serait peut-être une bonne idée.

Plugins

Pour des raisons de sécurité,le cloud est inaccésible au public, le plugin passman est installé afin de faciliter le partage des mots de passe.