Zulip est une application de messagerie qu’on pourrait assimiler à Slack ou Microsoft Teams. Bien que par défaut, l’équipe de développement encourage à utiliser son service centralisé, il est possible d’auto-héberger sa propre instance Zulip. À noter que Zulip n’est pas du tout un réseau fédéré.

Containérisation & sécurité

Cette section part du principe que vous utilisez un environnement debian ou ubuntu sur lequel docker n’est pas installé. L’installation d’un serveur Zulip est pour le moins… opaque. Oui, l’installeur est censé affiché toutes les étapes de son exécution, mais 1) comment vérifier que c’est bien le cas, autrement qu’en lisant entièrement le script? 2) parfois les infos s’affichent vite, ce qui peut rendre assez ardu de suivre tout ce qui se passe. Pour palier à ce problème, une solution très simple est de le faire tourner dans un conteneur LXC. À défaut d’être aussi sécurisé qu’une VM, ça nous permettra au moins de relativement isoler le système, et d’éviter que l’installation de Zulip casse quoique ce soit sur notre serveur. Pour la gestion du LXC, on va simplifier ça avec LXD, qui permet d’automatiser quelques tâches pour nous.

Installation de LXD

On installe :

sudo apt install lxd

On lance la configuration de LXD (un prompt va nous poser quelques questions)  :

sudo lxd init

Et enfin, on ajoute les droits LXD  à notre utilisateur, pour ne pas avoir à passer en root à chaque fois qu’on veut interagir avec nos conteneurs :

sudo adduser utilisateur lxd

Création du conteneur

Pour Zulip, on peut se lancer sur une debian toute simple.

lxc launch images:debian/trixie MonConteneur

On peut lister les différents conteneurs créés et voir leurs adresses ip à l’aide de la commande lxc list. On va noter l’adresse IP  de notre conteneur pour plus tard. S’il manque des IPs fonctionnelles à notre conteneur, on procède comme indiqué dans le point suivant.

Si le réseau ne passe pas

Il arrive parfois que la configuration du pare-feu empêche LXD d’ajouter les conteneurs au réseau qu’il aura créé. Pour régler ça, on va mettre à jour notre pare-feu, et ça devrait être bon. Ici, je vais utiliser les règles proposées dans la documentation d’Ubuntu, qui conviennent très bien dans notre cas.

# permet au conteneur d’obtenir une IP de la part de l’hôte
sudo ufw allow in on lxdbr0 to any port 67 proto udp
sudo ufw allow in on lxdbr0 to any port 547 proto udp

# permet au conteneur d’utiliser la résolution DNS de l’hôte
sudo ufw allow in on lxdbr0 to any port 53

# permet au conteneur d’avoir accès aux connexions sortantes
CIDR4="$(lxc network get lxdbr0 ipv4.address | sed 's|\.[0-9]\+/|.0/|')"
CIDR6="$(lxc network get lxdbr0 ipv6.address | sed 's|:[0-9]\+/|:/|')"
sudo ufw route allow in on lxdbr0 from "${CIDR4}"
sudo ufw route allow in on lxdbr0 from "${CIDR6}"

Agir dans le conteneur

Pour passer des commandes au conteneur, on utilisera la commande suivante :

lxc exec MonConteneur -- la commande

Si on a besoin d’entrer dans l’environnement, ça suit la même logique :

lxc exec MonConteneur -- /bin/bash

Installation de Zulip

Téléchargement

Pour la suite, on va se baser sur la documentation de Zulip, pour installer l’instance de manière standard. Mais avant tout, on va rentrer dans l’environnement en root avec la commande renseignée précédemment, lxc exec MonConteneur -- /bin/bash. Ensuite on se contente de suivre ce que nous dit la documentation. Téléchargement de la dernière version en date.

cd $(mktemp -d)
curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz

On vérifie le sha256sum.

sha256sum zulip-server-latest.tar.gz

Si tout est bon, on extrait le tout.

tar -xf zulip-server-latest.tar.gz

L’installation en elle-même

On va faire tourner l’installeur avec les arguments qui nous concernent. Dans notre cas, on veut les notifications push, accepter les TOS automatiquement, refuser d’envoyer les statistiques d’utilisation, pas de certificat SSL parce qu’on est derrière un proxy, et évidemment le hostname et l’adresse mail de contact qu’il faut obligatoirement indiquer.

./zulip-server-*/scripts/setup install --push-notifications --agree-to-terms-of-service --no-submit-usage-statistics --hostname exemple.fr --email=contact@exemple.fr

L’installeur va tourner tout seul, et créer un utilisateur zulip, qui fera tourner l’instance. Une fois l’installation finie, il nous fournira un lien à usage unique, permettant de créer l’organisation de notre instance. À ce stade, le lien ne sera pas fonctionnel, donc on le met de côté, pour ne pas le perdre.

Création du reverse proxy

On va créer un fichier de configuration nginx, puis certbot pour installer un certificat SSL.

sudo vim /etc/nginx/sites-available/zulip

Et on remplit comme suit, en utilisant la documentation pour les reverse proxies :

server {
    listen 80;
    listen [::]:80;
    server_name exemple.fr

    location /.well-known/acme-challenge/ { allow all; }

    location / {
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto $scheme;
        proxy_set_header    Host $host;
        proxy_http_version  1.1;
        proxy_buffering     off;
        proxy_read_timeout  20m;
        proxy_pass http:/X.X.X.X:80;
	}	
}

On active le tout avec un lien symbolique :

sudo ln -s /etc/nginx/sites-available/zulip /etc/nginx/sites-enabled/zulip

Et on relance nginx :

sudo systemctl restart nginx

Si tout va bien, on va pouvoir passer à la certification :

sudo certbot --nginx -d exemple.fr

On vérifie qu’il ne reste pas un port 80  inutilement ouvert dans la config nginx. Sinon, on édite et on relance nginx à nouveau. Désormais, notre instance est normalement accessible sur le web.

Configurer les mails sortants

Avant de créer notre organisation, je vous conseille de passer par cette étape, pour que tout fonctionne au mieux. En premier lieu, on va éditer /etc/zulip/settings.py, et s’assurer de configurer le serveur SMTP. On s’assure d’éditer les lignes suivantes :

EMAIL_HOST = "smtp.fournisseurmail.fr"
EMAIL_HOST_USER = "utilisateur@fournisseurmail.fr"
[…]
EMAIL_USE_TLS = TRUE
EMAIL_PORT = 587
[…]
TOKENIZED_NOREPLY_EMAIL_ADDRESS = "nepasrepondre+{token}@exemple.fr"
[…]
INSTALLATION_NAME = "Exemple"

On vérifier si les mails fonctionne bien en faisant tourner la commande suivante. Normalement on devrait obtenir un mail de la part de contact@exemple.fr et un autre de nepasrepondre+{token}@exemple.fr. Si ça tombe dans les spams, il faudra bidouiller de votre côté, je n’ai pas eu ce problème.

su zulip -c '/home/zulip/deployments/current/manage.py send_test_email monadressemailperso@monfournisseurmail.fr'

Dernière ligne droite

On peut enfin cliquer sur le lien que nous a donné l’installeur ! On le ressort de nos notes, on clique dessus, et on suit les différentes étapes proposées. Félicitations, notre Zulip est désormais fonctionnel !

Si t’as apprécié ce post, envoie-moi une disquette.

Edito

Cet article a été rédigé et publié en quelques minutes, son accessibilité est moins travaillée que d’habitude.

Environnement

• OS serveur : Debian 10 à jour
• OS client : Distribution GNU/Linux à jour
• Un utilisateur avec les droits sudo sur chaque machine

Côté serveur #1

sudo apt install wireguard
wg genkey | tee private_key | wg pubkey > public_key
sudo mkdir /etc/wireguard/helper

Créer et éditer le fichier de configuration du serveur, pour cet exemple, c’est wg0.conf.

[Interface]
Address = 10.200.200.1/24
ListenPort = 51821
PrivateKey = [coller ici le contenu du fichier 'private_key' généré précedemment]
PostUp = /etc/wireguard/helper/add-nat-routing.sh
PostDown = /etc/wireguard/helper/remove-nat-routing.sh

Créer et éditer le fichier /etc/wireguard/helper/add-nat-routing.sh.

#!/bin/bash
IPT="/sbin/iptables"
IPT6="/sbin/ip6tables"          
 
IN_FACE="eth0"                   # interface réseau connectée à Internet
WG_FACE="wg0"                    # interface réseau connectée à WireGuard
SUB_NET="10.200.200.0/24"            # sous-réseau de WireGuard en IPv4
WG_PORT="51821"                  # port UDP utilisé par WireGuard 
SUB_NET_6="fd42:42:42:42::/112"  # sous-réseau de WireGuard en IPv6
 
## règles IPv4 ##
$IPT -t nat -I POSTROUTING 1 -s $SUB_NET -o $IN_FACE -j MASQUERADE
$IPT -I INPUT 1 -i $WG_FACE -j ACCEPT
$IPT -I FORWARD 1 -i $IN_FACE -o $WG_FACE -j ACCEPT
$IPT -I FORWARD 1 -i $WG_FACE -o $IN_FACE -j ACCEPT
$IPT -I INPUT 1 -i $IN_FACE -p udp --dport $WG_PORT -j ACCEPT
 
## IPv6 (à décommenter si utilisation d’IPv6, non testé) ##
## $IPT6 -t nat -I POSTROUTING 1 -s $SUB_NET_6 -o $IN_FACE -j MASQUERADE
## $IPT6 -I INPUT 1 -i $WG_FACE -j ACCEPT
## $IPT6 -I FORWARD 1 -i $IN_FACE -o $WG_FACE -j ACCEPT
## $IPT6 -I FORWARD 1 -i $WG_FACE -o $IN_FACE -j ACCEPT

Créer et éditer le fichier /etc/wireguard/helper/remove-nat-routing.sh.

#!/bin/bash
IPT="/sbin/iptables"
IPT6="/sbin/ip6tables"          
 
IN_FACE="eth0"                   # interface réseau connectée à Internet
WG_FACE="wg0"                   # interface réseau connectée à WireGuard
SUB_NET="10.200.200.0/24"            # sous-réseau de WireGuard en IPv4
WG_PORT="51821"                 # port UDP utilisé par WireGuard 
SUB_NET_6="fd42:42:42:42::/112"  # sous-réseau de WireGuard en IPv6
 
# règles IPv4 #
$IPT -t nat -D POSTROUTING -s $SUB_NET -o $IN_FACE -j MASQUERADE
$IPT -D INPUT -i $WG_FACE -j ACCEPT
$IPT -D FORWARD -i $IN_FACE -o $WG_FACE -j ACCEPT
$IPT -D FORWARD -i $WG_FACE -o $IN_FACE -j ACCEPT
$IPT -D INPUT -i $IN_FACE -p udp --dport $WG_PORT -j ACCEPT
 
# règles IPv6 (à décommenter si utilisation d’IPv6, non testé) #
## $IPT6 -t nat -D POSTROUTING -s $SUB_NET_6 -o $IN_FACE -j MASQUERADE
## $IPT6 -D INPUT -i $WG_FACE -j ACCEPT
## $IPT6 -D FORWARD -i $IN_FACE -o $WG_FACE -j ACCEPT
## $IPT6 -D FORWARD -i $WG_FACE -o $IN_FACE -j ACCEPT

Rendre les scripts exécutables

sudo chmod +x /etc/wireguard/helper/*.sh

Créer et éditer le fichier /etc/sysctl.d/10-wireguard.conf

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Prendre en compte les modifications de sysctl.d

sysctl -p /etc/sysctl.d/10-wireguard.conf

Supprimer le fichier private_key

Côté client #1

wg genkey | tee private_key | wg pubkey > public_key

Créer et éditer le fichier de configuration client de WireGuard, dans cet exemple wg0-client.conf.

[Interface]
Address = 10.200.200.2/32
PrivateKey = [coller ici le contenu du fichier 'private_key' **généré côté client**]
DNS = 80.67.169.12, 80.67.169.40

[Peer]
PublicKey = [coller ici le contenu du fichier 'public_key' **généré côté serveur**
Endpoint = [adresse IP Internet du serveur]:51821
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 21

Supprimer le fichier private_key.

Côté serveur #2

Éditer /etc/wireguard/wg0.conf.

[…]

[Peer]
PublicKey = [coller ici le contenu du fichier 'public_key' **généré côté client**]
AllowedIPs = 10.200.200.2/32

Démarrer WireGuard, puis l’activer au démarrage du serveur.

sudo wg-quick up wg0
sudo systemctl enable wg-quick@wg0.service

Côté client #2

Démarrer WireGuard.

sudo wg-quick up wg0-client

Source

• https://www.cyberciti.biz/faq/how-to-set-up-wireguard-firewall-rules-in-linux/

Si t’as apprécié ce post, envoie-moi une disquette.

Environnement utilisé

Un CPX21 de l’offre Cloud de Hetzner. Je pense que les modifications restent intéressantes pour toute autre configuration équivalente ou moins puissante que celle-ci. Le serveur tourne sous Debian 10.

Pré-requis

Avoir déjà configuré son serveur SSH pour se connecter avec un utilisateur ayant accès aux droits d’administration.

Installer et configurer zRAM

zRAM est un outil permettant de compresser la RAM, pour gagner en mémoire vive disponible. Pour plus de détails, je vous recommande de lire l’introduction de cette page de documentation.

On installe le paquet.

sudo apt install zram-tools

Une fois installé, zRAM se lance tout seule avec une configuration par défaut. Pour configurer zRAM, on édite le fichier /etc/default/zramswap. On modifie la valeur PERCENTAGE pour augmenter la capacité que peut gérer zRAM, la valeur par défaut devrait être 10, on la passe à 100. On relance le service. pour que la modification fasse effet.

sudo systemctl restart zramswap.service

Installer GitLab

Suivre cette documentation

Limiter le nombre de processus

Par défaut, GitLab fait tourner un nombre important de processus, ce qui fait fortement ralentir les serveurs peu puissants. Pour résoudre ce problème, on va éditer /etc/gitlab/gitlab.rb et réduire le nombre de processus simultanés utilisés par les services de GitLab.

[…]
puma['worker_processes']=1
[…]
sidekiq['max_concurrency']=5

On relance GitLab pour que les modifications soient prises en compte.

sudo gitlab-ctl reconfigure

Une fois GitLab relancé, tout devrait fonctionner correctement et l’utilisation de la RAM du serveur ne devrait pas exceder 90%.

Sources

• Faire fonctionner GitLab sur un Raspberry Pi (en)

Si t’as apprécié ce post, envoie-moi une disquette.

Pré-requis

Avoir déjà configuré son serveur SSH pour se connecter avec un utilisateur ayant accès aux droits d’administration.

Mettre en place l’environnement

Tout ce qui est indiqué dans cette partie a lieu sur le serveur

Pour notre exemple, nous allons assumer que vous souhaitez créer un utilisateur qui va publier du contenu web. Les répertoires indiqués le sont à titre d’exemples, adaptez les chemins en conséquence de vos besoins.

Créer l’utilisateur et son groupe

On créé l’utilisateur, puis son groupe, on rajoute l’utilisateur au groupe et enfin, on s’assure qu’il ne puisse accéder qu’au client SFTP.

sudo useradd <username>
sudo groupadd <groupname>
sudo gpasswd -a <username> <groupname>
sudo usermod -s  /usr/lib/openssh/sftp-server <username>

Créer le répertoire de l’utilisateur

On créé le répertoire, on s’assure qu’il appartiennent bien à l’utilisateur root, de le protégér d’écriture de la part d’autres utilisateurs, puis on le définit comme répertoire d’accueil de l’utilisateur.

sudo mkdir /srv/www/domain.tld/
sudo chown root /srv/www/domain.tld
sudo chmod go-w /srv/www/domain.tld
sudo usermod -d /srv/www/domain.tld/ <username>

Créer le répertoire web

C’est dans ce répertoire que l’utilisateur aura les droits pour créer, supprimer et éditer des fichiers et dossiers. On créé le répertoire, on nomme l’utilisateur et son groupe propriétaires puis on leur donne les droits nécessaires.

sudo mkdir /srv/www/domain.tld/public_html
sudo chown <username>:<groupname> /srv/www/domain.tld/public_html
sudo chmod ug+rwX /srv/www/domain.tld/public_html

Finaliser l’environnement

N’oubliez pas de rajouter la clef publique SSH de votre utilisateur dans le dossier nécessaire.

On créé le répertoire .ssh nécessaire et le fichier authorized_keys dans lequel on va mettre la clef publique, enfin, on rend l’utilisateur propriétaire et on s’assure qu’il puisse lire le fichier.

sudo mkdir /srv/www/domain.tld/.ssh
sudo touch /srv/www/domain.tld/.ssh/authorized_keys
sudo chown -R <username>:<groupname> /srv/www/domain.tld/.ssh
sudo chmod u+rX /srv/www/domain.tld/.ssh

Il n’y a plus qu’à copier-coller la clef publique SSH dans le fichier authorized_keys.

Bloquer l’utilisateur dans l’environnement

Tout ce qui est indiqué dans cette partie a lieu sur le serveur

On édite le fichier /etc/ssh/sshd_config on vérifie si la directive Subsystem est bien comme indiquée ci-dessous, sinon, on la corrige ou la créé.

[…]
Subsystem sftp internal-sftp
[…]

On cherche le bloc AllowUsers, s’il est commenté (avec un en début de ligne #), on le décommente (on efface le #) et puis on y ajoute notre utilisateur.

[…]
AllowUsers <username>
[…]

On se rend à la fin du fichier de configuration, et on rajoute la partie suivante.

[…]
Match User <username> # On indique que notre partie concerne l’utilisateur
	ChrootDirectory /srv/www/domain.tld # Là où on veut enfermer l’utilisateur
	AllowTCPForwarding no
	X11Forwarding no
	ForceCommand internal-sftp # On force l’utilisateur à utiliser seulement le terminal SFTP

On redémarre SSH pour que la nouvelle configuration soit prise en compte.

sudo systemctl restart sshd.service

Côté client

Sur le PC de l’utilisateur·trice, on génère simplement la clef, et on utilisera SFTP pour se connecter de manière sécurisée.

Tester la connexion à l’environnement

En essayant de se connecter via SSH avec l’utilisateur SFTP, on devrait obtenir le message suivant : This service allows sftp connections only.. SFTP devrait se connecter sans soucis, la commande pwd affichant /. Toute tentative d’ajouter du contenu dans le dossier racine devrait échouée mais une fois dans le dossier /public_html, l’utilisateur devrait pouvoir ajouter, éditer et supprimer des fichiers et dossiers.

Sources

• Créer l’utilisateur proprement (en)
• Placer l’utilisateur et son dossier web (en)
• Restreindre l’utilisateur à l’environnement SFTP (en)

Pour aller plus loin…

Créer un seul groupe pour les utilisateurs SFTP

Si on doit créer plusieurs utilisateurs, avoir un seul groupe à gérer peut être plus pratique. On peut par exemple l’appeler sftp. À la création de nouveaux utilisateurs, on n’aura qu’à directement ajouter ces derniers au groupe comme indiqué au début de ce billet.

Un lien pour approfondir

• “How to Set File Permissions Using chmod” par l’Université de Washington(en)

Si t’as apprécié ce post, envoie-moi une disquette.