linux – David Mercereau

sysgit : versionner les fichiers de configuration système (co-administration-sys

Contexte : besoin de historiser les configs système à plusieurs

Administrer un serveur Linux à plusieurs (co-administration) peut rapidement tourner au casse-tête si on ne garde pas de trace des modifications «

Qui qu’a modifié le main.cf ? Pourquoi ? Elle était super ma config

Le service ne redémarre pas : qu’est-ce qui c’est passé depuis ma dernière connexion ?

C’est un problème que j’ai rencontré aussi bien dans un contexte associatif (serveurs de retzien.fr) que professionnel (infrastructure retzo.net). Lorsqu’un service tombe en panne du jour au lendemain, on entend souvent « mais pourquoi ça ne marche plus alors que ça marchait hier ? » ou « qui a fait ce changement, et pourquoi ? » Faute de trouver un outil existant correspondant à mes besoins ( et après en avoir discuté sur le forum CHATONS), j’ai développé sysgit, un petit outil shell open source conçu pour versionner les fichiers de configuration système et possiblement multi-admin.

Pourquoi utiliser Git pour les fichiers de configuration ?

Git est un système de gestion de versions largement utilisé par les développeurs, mais il s’applique tout aussi bien aux fichiers de configuration. L’idée est d’enregistrer chaque modification apportée aux configs dans un dépôt Git, avec un historique clair. On peut ainsi commenter chaque changement, comparer les différences, et revenir en arrière en cas de besoin. En administration système collaborative, Git apporte surtout de la visibilité sur qui a changé quoi et quand. Chaque admin peut suivre l’évolution des fichiers critiques, ce qui facilite le débogage et la communication au sein de l’équipe. En somme, versionner ses configs, c’est s’assurer une forme de documentation et d’audit continu, plutôt que de subir des modifications non tracées. Coupler à un outil comme gitlab/redmine ou autre qui gère aussi les issus/tickets ça permet d’avoir le volet « projet/tâche » relier aux différentes actions / modifications du/des serveurs

Il existe déjà un outil dédié nommé etckeeper qui permet de versionner le répertoire /etc avec Git. Cependant, etckeeper se limite à /etc et ne gère pas facilement d’autres chemins du système. C’est justement cette limite qui a motivé la création de sysgit.

Présentation de sysgit

sysgit est un script shell (bash) qui facilite le suivi de configuration sur un serveur en s’appuyant sur Git. En bref, sysgit c’est :

Un wrapper Git multi-chemins : il versionne plusieurs chemins/fichiers de configuration du système dans un dépôt unique, au lieu d’un dépôt par répertoire.
Aucun déplacement de fichiers : le work-tree utilisé par Git est la racine du système (/), ce qui évite de devoir déplacer vos fichiers ou utiliser des liens symboliques. On ne suit que les chemins que l’on ajoute explicitement au dépôt.
Historique clair et centralisé : l’objectif est de garder un journal de modifications lisible de toutes les configurations « sensibles » du système, sans déployer d’outil lourd de gestion de config (on reste sur du Git pur). En pratique, l’historique des commits fait office de log des changements sur le serveur.

Techniquement, sysgit ne réinvente rien : il s’appuie sur Git. Les commandes sysgit ne font que lancer git avec les bons paramètres de répertoire (options –git-diret –work-treeajustées). Cela signifie que le dépôt Git de configuration est stocké à part (en dehors de vos dossiers système) et que vous pouvez toujours interagir avec lui via Git standard au besoin.

Fonctionnalités principales de sysgit

Comparé à etckeeper ou à un usage “manuel” de Git, sysgit apporte plusieurs fonctionnalités utiles :

Scope étendu : on peut suivre tous les fichiers de configuration importants du système, pas juste /etc. Par exemple, libre à vous d’inclure /opt/monapp/config.yml, /var/spool/cron/crontabs, /root/.ssh/authorized_keys, etc.
Dépôt unique : un seul dépôt Git centralise l’historique de tous ces chemins. Inutile de multiplier les dépôts ou de gérer des symlinks pour différents dossiers.
Sélection fine des fichiers : vous ajoutez explicitement les chemins à versionner (whitelist) plutôt que de tout versionner en bloc. Vous ne suivez ainsi que ce qui vaut la peine d’être historisé (configs critiques), ce qui allège l’historique. Mais vous pouvez aussi ajouter tout un répertoire (/etc par exemple si vous le souhaitez)
Profils multi-admin : sysgit gère plusieurs profils d’auteurs Git, très pratique sur un serveur administré à plusieurs. Concrètement, si un admin effectue un commit en root il choisie « qui il est » (son identité) et celle-ci est conserver tel une sessions le temps de sa connexion.

root@srvmail:~# sysgit status
Choisir un profil:
 1) David - david.*********@retzien.fr
 0) Creer un nouveau profil
Votre choix: 0
Nom: Serge
Email: serge.*********@retzien.fr
Sur la branche master
Modifications qui ne seront pas validées :
  (utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)
  (utilisez "git restore <fichier>..." pour annuler les modifications dans le répertoire de travail)
	modifié :         ../etc/sympa/sympa_transport
	modifié :         ../etc/sympa/sympa_transport.db

aucune modification n'a été ajoutée à la validation (utilisez "git add" ou "git commit -a")
root@srvmail:~# sysgit add /etc/sympa/sympa_transport*
En tant que Serge <serge.*********@retzien.fr> (preciser -p pour changer)
root@srvmail:~# sysgit commit -m "Suppressoin de mailing liste"
En tant que Serge <serge.*********@retzien.fr> (preciser -p pour changer)
sending incremental file list
root@srvmail:~# sysgit log
En tant que Serge <serge.*********@retzien.fr> (preciser -p pour changer)
commit 428bb2401993b91e90a4dabac53d8d129fb378b4 (HEAD -> master)
Author: Serge <serge.*********@retzien.fr>
Date:   Tue Jan 20 10:07:22 2026 +0100

    Suppressoin de mailing liste

commit e952c0fd43317cba8afead584b7933621eb307f7
Author: David <david.*********@retzien.fr>
Date:   Tue Jan 20 09:37:19 2026 +0100

    Changement éditeur par défaut

Intégration d’etckeeper : un script de migration est fourni pour importer l’historique existant d’un dépôt etckeeper, si vous utilisiez déjà cet outil. Vous pouvez ainsi passer à sysgit sans perdre vos anciens historiques de /etc.
Auto-commit programmable : sysgit peut s’utiliser avec un timer systemd afin d’automatiser un commit chaque nuit (pour capturer les changements éventuels qui n’auraient pas été committés manuellement).
Hook APT/dpkg : un hook est prévu pour effectuer automatiquement un commit dès qu’une installation ou mise à jour de paquet modifie des fichiers de config (similaire à ce que fait etckeeper). Cela garantit que même les changements induits par les paquets sont tracés sans intervention manuelle.
Rappel en fin de session : enfin, sysgit peut rappeler à l’administrateur de committer les modifications non sauvegardées lors de sa déconnexion (bash logout) s’il en détecte. Ce petit mémo évite d’oublier de versionner un changement avant de fermer sa session.
Mise à jour facile : petit coquin je vous connais, trop la flemme de mettre à jour des petits outils comme ça qui sont pas dans un package apt (je parle pour moi). Ici rien de plus facile : sysgit -u

Installation de sysgit

L’outil sysgit étant tout récent, il n’est pas (encore) empaqueté dans les distributions. Son installation reste malgré tout simple :

Prérequis : assurez-vous d’avoir Git installé sur le serveur (sudo apt install git sur Debian/Ubuntu si nécessaire).
Installation rapide par script : mais vous pouvez préférer récupérer le projet depuis Framagit :

wget -O /tmp/sysgit-install.sh https://framagit.org/kepon/sysgit/-/raw/main/install.sh
sudo bash /tmp/sysgit-install.sh

Utilisation typique de sysgit

Une fois l’installation effectuée, l’utilisation de sysgit se rapproche de celle de Git, avec quelques commandes dédiées. Voici un mini-tutoriel d’usage courant :

# 1. Initialiser le dépôt "système" (une seule fois au départ)
sysgit init
# 2. Choisir les fichiers/répertoires à versionner
sysgit add -A /etc # par exemple tout /etc
sysgit add /root/.bashrc # fichiers de conf utilisateur
sysgit add /var/spool/cron/crontabs # répertoire de crons
... # (ajoutez autant de chemins que nécessaire)

# 3. Vérifier l'état et enregistrer l'état initial
sysgit status # liste les modifications en attente (fichiers ajoutés)
sysgit commit -m "État initial" # crée le premier commit avec tous ces fichiers

echo "# Modification d'un fichier suivi" >> /root/.bashrc
sysgit diff # affiche les différences

Une fois ce dépôt initialisé avec vos configs de base, au quotidien ça consiste simplement à committer toute modification de configuration. Par exemple, si vous modifiez /etc/ssh/sshd_config, vous exécuterez ensuite sysgit status (pour voir les changements non committés), éventuellement sysgit diff (pour visualiser les différences), puis sysgit commit -m « Msg » pour valider la modification dans l’historique. Vous pouvez bien sûr pousser le dépôt vers un serveur Git distant (Gitea, GitHub, etc.) pour sauvegarde ou partage, via les commandes usuelles (sysgit remote add origin …, sysgit push).

Pour la consultation, sysgit expose toutes les commandes Git classiques : sysgit log pour l’historique des commits, sysgit show <commit> pour détailler un commit précis, sysgit checkout <commit> — <fichier> pour restaurer une ancienne version d’un fichier, etc. En interne, “c’est du Git normal” – vous bénéficiez donc de toute la puissance de Git pour naviguer dans l’historique.

Mémo des commandes sysgit

Voici un récapitulatif des principales commandes fournies par sysgit :

sysgit init – Initialiser un nouveau dépôt de configuration (à exécuter une fois par serveur).
sysgit add <chemin> – Ajouter un fichier à suivre (peut être répété pour chaque élément à versionner).
sysgit add -A <chemin> – Ajouter un répertoire à suivre
sysgit status – Afficher les modifications non committées (équivalent de git status).
sysgit diff – Afficher les différences entre les fichiers suivis et la dernière version committée.
sysgit commit -m « Message » – Enregistrer (committer) les changements avec un message descriptif.
sysgit log – Consulter l’historique des commits (qui a changé quoi et quand).
sysgit show <SHA> – Afficher le détail d’un commit (identifié par son hash ou identifiant).
sysgit checkout <SHA> –– <fichier> – Restaurer un fichier suivi à l’état qu’il avait lors d’un commit donné (pratique pour annuler une modification).
sysgit push / sysgit pull – Envoyer ou récupérer les changements vers/depuis un dépôt Git distant (si configuré, pour sauvegarde ou partage entre admins).

(Toutes les autres commandes Git peuvent être utilisées via sysgit de la même manière, en passant simplement par l’alias sysgit.)

Liens utiles

PvMonit v1.0 : Monitoring de mon installation photovoltaïque autonome

Je ne maintient actuellement plus PvMonit. Je tâche de faire prochainement un article pour vous donner quelques alternative.

PvMonit est arrivé à une version « mature », une version 1.0. PvMonit est un logiciel sous licence Beerware qui vous permet de monitorer votre installation électrique solaire autonome, plus particulièrement avec les appareils Victron.

Nouvelle version pvmonit dispo ici. Avec une « sur-couche » à PvMonit pour gérer le surplus d’électricité : Déclencher des actions à la demande. Exemple : les batteries sont pleines, on allume une pompe à eau puis la résistance électrique d’un chauffe eau. Ou encore, les batteries sont sous un seuil critique, on coupe tout sauf l’éclairage…. toutes les applications sont possibles !

PvMonit C’est quoi ?

PvMonit, c’est donc un petit logiciel de monitoring photovoltaïque pour matériel Victron compatible Ve.direct (le minimum pour que cela fonctionne est d’avoir un BMV 600, 700 ou 702…), particulièrement adapté pour les installations autonomes (hors réseau). Il permet une vue « en direct » par interface web et un enregistrement de l’historique (avec emoncms, branche d’OpenEnergyMonitor).

Mon usage

Je collecte les information de mon système photovoltaïque (température, état des batteries, production solaire, etc…) par une carte électronique (Arduino) qui se trouve dans un local à 35m de mon habitation. Je transporte ces données par un 3 fils dans un câble réseau. Celui-ci est connecté à un mini ordinateur (raspberry pi 0) sur lequel j’ai un écran LCD qui m’affiche l’état du système et j’ai un interface web (démo) ou j’ai plus de détails. Il y a aussi un historique qui est enregistré via emoncms (démo).

Au niveau Matériel

2 versions possibles :

Une version Raspberry PI 3B, si vous avez un point wifi actif (même occasionnellement) et que votre matériel solaire est à porté de wifi. C’est une solution plutôt simple (si on touche un peu sous linux).
Une version Raspberry Pi 0 + Arduino : plus complexe à mettre en œuvre (il faut savoir souder et avoir plus de connaissances), mais beaucoup plus souple et moins chère. Particulièrement adapté si votre installation réseau est loin (max 60m) de votre maison ;

	Version Raspberry PI 3B	Version Arduino + Raspberry Pi 0
Consommation électrique	0,37A (pi 3b) * 5V = ~1,85W	0,22A (pi 0) + 0,08A (arduino MEGA) = 0,30A * 5V = ~1,5W
Difficulté	***	*****
Prix matériel (détails)	200 €	110 €

Raspberry Pi 3B & Ve.direct USB (officiel)

L’usage des câbles ve.direct USB officiel permet de simplifier le montage.

Le hub USB avec les câbles Ve.direct sous la multi

Arduino + Raspbery Pi 0

L’usage d’un arduino pour collecter les données donne de la souplesse pour pouvoir ajouter des sondes à volonté et permet de parcourir de grande distance jusqu’au Raspberry PI qui récupère les informations. Un schéma de câblage détaillé :

Voilà ce que ça donne, c’est plus de boulot, plus de soudure mais plus DIY, plus fun :-p

Installation

Il ne faut pas se mentir, ça demande de bonnes connaissances techniques en linux/réseau voir arduino/soudure (si vous choisissiez cette option).

J’ai fais un très long tuto d’installation dans le fichier INSTALL.md du dépôt git : https://framagit.org/kepon/PvMonit/blob/master/INSTALL.md

Firewall : Mon script iptables

Je partage ici mon script de firewall iptable. C’est un script « à l’ancienne », dans du bash… ça fait le taf, mais rien de bien transsudant. En gros :

On ferme tout les ports sauf ceux qui nous intéresse (80, 25, icmp…)
Petite fonction pour ouvrir les ports mis en écoute sur Portsentry. Portsentry c’est un petit logiciel de sécurité en mode « pot de miel ». On met des ports en écoute mais il n’y a rien derrière. Dès que quelqu’un tente de s’y connecter (un robot ou quelqu’un de malveillant), ça bloque son IP dans le firewall pour un temps donnée. C’est radical si vous déplacez le port SSH du 22 vers autre chose et que vous mettez Portsentry à écouter (entre autre) sur le 22…
Mode maintenance du serveur web (lancé via ./iptables.sh maintenance). Il permet de mettre une page de maintenance pour tout le monde sauf pour vous (j’explique en détail dans cet article)

#!/bin/bash

## IP :
# Chez moi
MOI="A.A.A.A" 
# Mon serveur
SRV1="X.X.X.X"

IPT="/sbin/iptables"
PORTSENTRYCONF="/etc/portsentry/portsentry.conf"

export IPT PORTSENTRYCONF

function portsentryOpen() {
	. ${PORTSENTRYCONF}
	IFS=',' read -ra TCP_PORTS_SPLIT <<< "${TCP_PORTS}"
	for TCP_PORT in "${TCP_PORTS_SPLIT[@]}"; do 
		${IPT} -A INPUT -p tcp --dport ${TCP_PORT} -j ACCEPT
	done
	IFS=',' read -ra UDP_PORTS_SPLIT <<< "${UDP_PORTS}"
	for UDP_PORT in "${UDP_PORTS_SPLIT[@]}"; do 
		${IPT} -A INPUT -p udp --dport ${UDP_PORT} -j ACCEPT
	done
}

# Remise a 0
${IPT} -F
${IPT} -t nat -F

# Les connexions entrantes sont bloquées par défaut
${IPT} -P INPUT DROP
# Les connexions destinées à être routées sont acceptées par défaut
${IPT} -P FORWARD ACCEPT
# Les connexions sortantes sont acceptées par défaut
${IPT} -P OUTPUT ACCEPT


######################
# Règles de filtrage #
######################
# Nous précisons ici des règles spécifiques pour les paquets vérifiant
# certaines conditions.
 
# Pas de filtrage sur l'interface de "loopback"
${IPT} -A INPUT -i lo -j ACCEPT
 
# Accepter le protocole ICMP (notamment le ping)
${IPT} -A INPUT -p icmp -j ACCEPT
  
# Accepter les packets entrants relatifs à des connexions déjà
# établies : cela va plus vite que de devoir réexaminer toutes
# les règles pour chaque paquet.
${IPT} -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# ftp 
${IPT} -A INPUT -p tcp --dport 20 -j ACCEPT 
${IPT} -A INPUT -p tcp --dport 21 -j ACCEPT
# Préalabielemnt, pour pure-ftpd : echo "29700 29750" > /etc/pure-ftpd/conf/PassivePortRange ${IPT} -A INPUT -p tcp --dport 29700:29750 -j ACCEPT
# SSH
${IPT} -A INPUT -p tcp --dport 222 -j ACCEPT
# NTP
${IPT} -A INPUT -p udp --dport 123 -j ACCEPT
# smtp
${IPT} -A INPUT -p tcp --dport smtp -j ACCEPT
# Pour test bricolage smtp
${IPT} -A INPUT -p tcp --dport 587 -j ACCEPT
# imap(s)
${IPT} -A INPUT -p tcp --dport 143 -j ACCEPT
${IPT} -A INPUT -p tcp --dport 993 -j ACCEPT
# sieve
${IPT} -A INPUT -p tcp --dport 4190 -j ACCEPT
# dns
${IPT} -A INPUT -p tcp --dport domain -j ACCEPT
${IPT} -A INPUT -p udp --dport domain -j ACCEPT
# http
${IPT} -A INPUT -p tcp --dport http -j ACCEPT
# https
${IPT} -A INPUT -p tcp --dport https -j ACCEPT

# Maintenance 
if [ "$1" == "maintenance" ] ; then
	echo "Maintenance On"
	/usr/sbin/service lighttpd start
	${IPT} -A INPUT -p tcp --dport 81 -j ACCEPT
	${IPT} -t nat -A PREROUTING \! -s ${MOI} -p tcp --dport 80 -j DNAT --to-destination ${SRV1}:81
	${IPT} -t nat -A POSTROUTING -j MASQUERADE
elif [ -f "/var/run/lighttpd.pid" ] ; then
	echo "Maintenance Off"
	/usr/sbin/service lighttpd stop
fi

# Portsentry 
if [ -f ${PORTSENTRYCONF} ] ; then
	portsentryOpen ${IPT} ${PORTSENTRYCONF}
fi

# End
${IPT} -A INPUT -j LOG --log-prefix "iptables denied: "  --log-level 4
${IPT} -A INPUT -j REJECT

# Si vous utilisez fail2ban, relancé à la fin du script :
#/usr/sbin/service fail2ban restart

PvMonit – Monitoring de mon installation photovoltaïque autonome

Je ne maintient actuellement plus PvMonit. Je tâche de faire prochainement un article pour vous donner quelques alternative.

Nouvel article avec nouvelle version de PvMonit ici même + gestion du surplus électrique

Cet article fait suite à la réalisation de mon installation électrique solaire autonome. Je suis très content de celle-ci, seulement j’ai un grand besoin de maîtrise, et ne pas savoir tout ce qui se passait dans ces petites boîtes bleues me taraudait… Il fallait que je monitor. Coup de chance, les appareils Victron que j’ai installés peuvent se connecter à un ordinateur avec les câbles VE Direct USB.

En bon libriste que je suis, j’ai vite découvert OpenEnergyMonitor project. J’ai failli craquer pour un emonPi – Solar PV mais ça ne correspondait pas complètement à mes contraintes. J’ai donc pris mes petits doigts et j’ai pondu PvMonit.

PvMonit C’est quoi ?

PvMonit c’est donc un petit logiciel de monitoring photovoltaïque pour matériel Victron compatible Ve.direct (USB), particulièrement adapté pour les installations autonomes. Il permet une vue « en direct » et un export de l’historique vers emoncms (une branche d’OpenEnergyMonitor project).

Exemple d’usage de PvMonit (le mien) : je dispose d’un RaspberryPi (mini ordinateur qui ne consomme que ~3W), mes appareils Victron (MPTT, BMV) sont connectés avec des câbles VE.Direct USB. PvMonit est installé sur ce RaspberryPi et me permet :

D’afficher les informations en temps réel sur une page web (local)
- Une copie de cette page est faite toutes les heures (si la connexion internet est allumée) et est accessible ici : http://demo.zici.fr/PvMonit/
De collecter les données toutes les X minutes et les expédier vers emoncms quand internet est là (le wifi n’étant pas toujours allumé)
- Mon tableau de bord est visible ici : http://emoncms.mercereau.info/dashboard/view?id=1

Des images :

Installation de PvMonit

Le matériel

Il vous faudra pour suivre ce tuto :

Un ordinateur faible consommation configuré sous Debian ou un dérivé type Ubuntu/Raspbian (j’ai fait un article sur l’installation de mon Raspberry PI) 68€ (d’occasion avec coque, ventilateur, carte SD)
Les câbles Ve.Direct USB connectés à vos appareils 30€ (x3 car 3 appareils à connecter)
En option :
- Une sonde de température USB pour contrôler la température du local où vivent les batteries. J’utilise « thermomètre USB TEMPer » qui coûte entre 5 et 20€, (ils en parlent ici)
- Une pince ampèremètre USB pour contrôler la consommation de l’habitat. J’utilise la Aviosys 8870 à 27€ quand même, mais il ne semble pas y avoir beaucoup de concurrence pour ce type de produit… (j’en parle ici)

Voici le schéma de mon installation avec le câblage pour PvMonit incorporé :

Et voilà dans la vraie vie :

La pince ampèremétrique USB pour la consommation de l’habitat

Le logiciel : Installation de PvMonit

Requis

Linux (le tutoriel ci-dessous est prévu pour Debian/Rasbian/Ubuntu like)
PHP (5.6 minimum)
Lighttpd/Apache (ou autre serveur web)
Perl
Python

Installation

PvMonit dispose de deux fonctions dissociées et indépendantes que je vais distinguer :

Interface en temps réel
Export vers emoncms

Il y a bien sûr une base commune :

La base / le socle

Installation de PvMonit via le dépôt git et de ses dépendances :

aptitude install php-cli git python-serial sudo
cd /opt
git clone https://framagit.org/kepon/PvMonit.git
cp config-default.php config.php

Vous pouvez maintenant éditer le fichier config.php à votre guise !

Test du script vedirect.py : branchez un appareil Victron avec un Câble Ve.Direct USB et voici un exemple de ce que vous devriez obtenir (Ici un MPTT BlueSolare branché sur le ttyUS0)

$ /opt/PvMonit/bin/vedirect.py /dev/ttyUSB0 
PID:0xA04A
FW:119
SER#:HQ********
V:25660
I:500
VPV:53270
PPV:14
CS:3
ERR:0
LOAD:ON
H19:3348
H20:1
H21:17
H22:33
H23:167
HSDS:52

Pour comprendre chaque valeur, téléchargez la documentation Victron VE Direct Protocol documentation : https://www.victronenergy.fr/support-and-downloads/whitepapers

Interface web en temps réel

Installation des dépendances :

aptitude install lighttpd php-cgi 
lighttpd-enable-mod fastcgi
lighttpd-enable-mod fastcgi-php

Configuration du serveur http, avec le fichier /etc/lighttpd/lighttpd.conf :

server.document-root        = "/opt/PvMonit/www"
server.pid-file             = "/var/run/lighttpd.pid"
server.username             = "www-data"
server.groupname            = "www-data"
server.port                 = 80
index-file.names            = ( "index.html", "index.php")
url.access-deny             = ( "~", ".inc" )
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.assign.pl"
include_shell "/usr/share/lighttpd/include-conf-enabled.pl"

On applique la configuration :

service lighttpd restart

On ajoute ensuite la possibilité à l’utilisateur exécutant lighttpd de lancer les script avec sudo sans mot de passe :

Lancer la commande :

visudo

Ajouter la ligne suivante :

+ www-data ALL=(ALL) NOPASSWD: /usr/bin/perl /opt/PvMonit/bin/ampermetre.pl, /opt/temperv14/temperv14 -c, /usr/bin/python /opt/PvMonit/bin/vedirect.py /dev/tty*

C’est terminé, vous pouvez vous connecter sur votre IP local pour joindre votre serveur web :

Export vers emoncms

Connectez-vous à votre interface emoncms hébergée ou créez un compte sur emoncms.org et rendez-vous sur la page « Input api » https://emoncms.org/input/api :

Récupérez la valeur « Accès en écriture » et ajoutez-la dans le fichier de configuration Pvmonit /opt/PvMonit/config.php :

- $EMONCMS_URL_INPUT_JSON_POST='https://emoncms.chezvous.org/input/post.json';
- $EMONCMS_API_KEY='XXXXXXXXXXXXXXXXXXXXXXXX';
+ $EMONCMS_URL_INPUT_JSON_POST='https://emoncms.org/input/post.json';
+ $EMONCMS_API_KEY='????VOTRE API KEY?????';

Création d’un utilisateur dédié avec pouvoir restreint

adduser --shell /bin/bash pvmonit

Installation des dépendances :

aptitude install lynx

On ajoute ensuite la possibilité à l’utilisateur exécutant l’export de lancer les scripts avec sudo sans mot de passe :

Lancer la commande :

visudo

Ajouter la ligne suivante :

+ pvmonit ALL=(ALL) NOPASSWD: /opt/temperv14/temperv14 -c, /usr/bin/perl /opt/PvMonit/bin/ampermetre.pl, /usr/bin/python /opt/PvMonit/bin/vedirect.py /dev/tty*

Test de collecte :

$ su - pvmonit -c /opt/PvMonit/getForEmoncms.php
2016-11-02T10:55:30+01:00 - C'est un MPTT, modèle "BlueSolar MPPT 100/30 rev2" du nom de MpttBleu
2016-11-02T10:55:30+01:00 - Les données sont formatées comme ceci : V:26180,I:800,VPV:56360,PPV:21,CS:3,ERR:0,H19:3352,H20:5,H21:51,H22:33,H23:167
2016-11-02T10:55:31+01:00 - C'est un MPTT, modèle "BlueSolar MPPT 100/30 rev2" du nom de MpttBlanc
2016-11-02T10:55:31+01:00 - Les données sont formatées comme ceci : V:26200,I:600,VPV:53630,PPV:18,CS:3,ERR:0,H19:1267,H20:4,H21:46,H22:17,H23:201
2016-11-02T10:55:31+01:00 - Après correction, la température est de 11.88°C
2016-11-02T10:55:31+01:00 - Tentative 1 de récupération de consommation
2016-11-02T10:55:32+01:00 - Trouvé à la tentative 1 : la La consommation trouvé est 00.1A
2016-11-02T10:55:32+01:00 - La consommation est de 00.1A soit 23W

Test d’envoi des données :

$ su - pvmonit -c /opt/PvMonit/sendToEmoncms.php 
2016-11-02T10:56:44+01:00 - Données correctements envoyées : 1, données en erreurs : 0

Mettre les scripts en tâche planifiée

crontab -e -u pvmonit

Ajouter :

+# Script de récupération des données, toutes les 5 minutes
+/5 * * * * /usr/bin/php /opt/PvMonit/getForEmoncms.php >> /tmp/PvMonit.getForEmoncms.log
+# Script d'envoi des données, ici toutes les 1/2 heures
+3,33 * * * * /usr/bin/php /opt/PvMonit/sendToEmoncms.php >> /tmp/PvMonit.sendToEmoncms.log

Je n’explique pas ici comment configurer emoncms, les flux pour obtenir de beaux dashboard, je vous laisse lire la documentation…

Voici, pour exemple, mon dashboard : http://emoncms.mercereau.info/dashboard/view?id=1

Sonde température (option)

J’utilise la sonde thermomètre USB TEMPer, cette sonde fonctionne avec le logiciel temperv14 qui est plutôt simple à installer

apt-get install libusb-dev libusb-1.0-0-dev unzip
cd /opt
wget http://dev-random.net/wp-content/uploads/2013/08/temperv14.zip
#ou un miroir
#wget http://www.generation-linux.fr/public/juin14/temperv14.zip
unzip temperv14.zip
cd temperv14/
make

Test de la sonde :

$ /opt/temperv14/temperv14 -c
18.50

Ajout de celle-ci dans le fichier /opt/PvMonit/config.php :

- $TEMPERV14_BIN='';
+ $TEMPERV14_BIN='/usr/bin/sudo /opt/temperv14/temperv14';

Autres documentations à propos de cette sonde :

Pince ampèremétrique (option)

J’utilise la pince ampèremétrique USB Aviosys 8870 pour mesurer ma consommation électrique.

Le petit script perl (/opt/PvMonit/bin/ampermetre.pl) est très simple pour lire la pince ampèremétrique, qui sera branchée en USB et apparaîtra dans votre système sur le port /dev/ttyACM0

Celui-ci dépend de la librairie serialport :

aptitde install libdevice-serialport-perl

Test : :

$ /opt/PvMonit/bin/ampermetre.pl 
00.1A

Ajout de celle-ci dans le fichier /opt/PvMonit/config.php :

- $AMPEREMETRE_BIN = '';
+ $AMPEREMETRE_BIN = '/usr/bin/sudo /usr/bin/perl /opt/PvMonit/bin/ampermetre.pl';

Documentation

Victron VE Direct Protocol documentation : https://www.victronenergy.fr/support-and-downloads/whitepapers

Voilà voilà, bon courage !

RaspberryPi & Raspbian en lecture seul (ReadOnly) pour préserver la carte SD

Mise à jour 2025 : Maintenant la commande raspi-config propose un mode read only. (dans performance) Qui utilise une partition « fantôme » (overlay) qui se superpose à la carte SD. De cette façon le système pense qu’il est toujours en RW, tout fonctionne bien… c’est à mon sens pas toujours une bonne chose parce qu’il faut bien penser à désactiver ce mode pour faire des upgrades par exemple… Sinon au prochain reboot c’est perdu car la superposition ce fait en RAM. Je conseillerai cet usage Overlay + désactiver un max de service comme ci-après pour ceux qui ne maîtrisent pas trop le système, sinon se mettre « vraiment en RO » comme présenté ci après :

Le Raspberry Pi, est un mini ordinateur qui consomme très peu d’énergie. Il n’y a pas de disque dur mécanique, le système se trouve sur une carte SD. L’avantage c’est que ça consomme moins d’énergie mais la carte SD à l’inconvénient de s’abîmer très rapidement quand il y a beaucoup de lecture/écriture (et sa durée de vie n’en ai que moindre). J’ai donc passé mon Raspberry Pi sous Raspbian (une Debian pré-packagé pour Raspberry) et mis en place un système en lecture seul. Il s’agit ici d’une installation type serveur sans interface graphique.

Installation de Raspbian (sans écran sur le Raspberry) avec connexion Wifi

Vue que je n’ai pas d’écran pour installer mon Raspberry, j’ai mis la carte SD dans mon ordinateur portable pour l’installation. Après le téléchargement de « Raspbien lite » sur le site officiel : http://www.raspbian.org. Il suffit d’utiliser la commande dd pour installer l’image :

david@portabuntu:~/Téléchargements$ unip raspbian_lite_latest.zip
david@portabuntu:~/Téléchargements$ sudo dd bs=4M if=2016-05-10-raspbian-jessie-lite.img of=/dev/sdc
330+1 enregistrements lus
330+1 enregistrements écrits
1386217472 octets (1,4 GB) copiés, 86,4596 s, 16,0 MB/s

Attention : remplacer /dev/sdc par le périphérique de votre carte SD ! (/dev/sdb, /dev/mmcblk0… un « sudo fdisk -l » pourra vous en dire plus)

Éjecter la carte SD et remettez là, vous devriez avoir plusieurs partition sur la carte SD :

#1 : FAT32 (partition de boot)
#2 : ext3 (système)

Utilisation de gparted pour agrandir l’espace disque de la partition système :

Attention : cet article est vieux, préféré celui-ci pour la partie wifi : https://www.inpact-hardware.com/article/270/100830-comment-installer-simplement-raspberry-pi-sous-raspbian-avec-ssh-et-wi-fi-sans-ecran

On va maintenant préparer la connexion Wifi pour pouvoir l’attaquer en SSH :

sudo mkdir /mnt/sd-sys
sudo mount /dev/sdc2 /mnt/sd-sys # (la partition ext3)
sudo vi /mnt/sd-sys/etc/network/interfaces

L’édition de se fichier interface qui gère les cartes réseaux :

< iface wlan0 inet manual
< wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
---
> auto wlan0
> iface wlan0 inet static
> address 192.168.1.2
> netmask 255.255.255.0
> gateway 192.168.1.1
> wpa-ssid "VOTRE SSID WIFI"
> wpa-psk "VOTRE CLEF WAP PSK"

On spécifie le serveur DNS en modifiant le fichier /mnt/sd-sys/etc/network/interfaces

< #name_servers=127.0.0.1
---
> name_servers=192.168.1.1

Bien sûr il faut mette des IP’s de votre réseau…

On éjecte la carte :

david@portabuntu:~$ sudo umount /dev/sdc2 
david@portabuntu:~$ sudo eject /dev/sdc

On met la carte SD dans le Raspberry et on l’allume, on partiente que la connexion au Wifi soit faite et on test la connexion ssh :

david@portabuntu:~$ ssh pi@192.168.1.2 
The authenticity of host '192.168.1.2 (192.168.1.2)' can't be established.
ECDSA key fingerprint is fe:ed:f6:fe:e5:ea:28:bb:ad:6d:0c:2e:8f:b1:2c:5b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.2' (ECDSA) to the list of known hosts.
pi@192.168.1.2's password: 

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
pi@raspberrypi:~ $

ça fonctionne !!!!

Passage du système en ReadOnly

Je me suis bien aidé des différents sites suivant :

Le reste des commandes va s’effectuer avec les droits root :

pi@raspberrypi:~ $ sudo -i
root@raspberrypi:~#

Il va falloir minimiser les programmes qui écrivent sur le FileSystème. On commence par désactiver la SWAP :

dphys-swapfile swapoff
dphys-swapfile uninstall
update-rc.d dphys-swapfile disable

Et on fait du ménage :

apt-get remove --purge logrotate dbus dphys-swapfile  fake-hwclock

Sauf si vous utilisez le DHCP, dans ce cas il faudra ajouter des choses pour que ça fonctionne en RO (« ln -s /tmp /var/lib/dhcp » par exemple…) sinon on supprime aussi le client DHCP :

aptitude purge isc-dhcp-client  dhcpcd5  isc-dhcp-common

On met l’horloge sur le bon fuseau horaire (Europe/Paris pour moi) :

rm /etc/localtime
ln -s /usr/share/zoneinfo/Europe/Paris /etc/localtime

On remplace le « log manager » rsyslogd par busybox one qui fonctionne en RAM et on en FS :

apt-get install busybox-syslogd; dpkg --purge rsyslog

Pour lire les logs il faut utiliser la commande logread (logread -f correspond à un tail -f sur le syslog)

Encore un peu de ménage au démarrage :

systemctl disable bootlogs
systemctl disable sudo # Si vous n'utilisez pas sudo
systemctl disable alsa-utils # Si vous n'utilisez pas le son
systemctl disable console-setup
systemctl disable fake-hwclock # Certainement déjà absent à ce stade

A ce stade je conseil d’installer les petits outils indispensables

On désactive le bash_history soit en supprimant complètement le fichier

history -c
rm ~/.bash_history -rf
export HISTFILESIZE=0
unset HISTFILE
echo "HISTFILESIZE=0" >> ~/.bashrc

Soit en le déplaçant dans /tmp. Il sera remis à 0 à chaque reboot mais fonctionnera en read only.

+ HISTFILE="/tmp/${USER}_bash_history"

Avant de mettre le système en read only on va faire deux alias pour switcher du mode read-only on mode read-write facilement. Ajouter dans bashrc commun : /etc/bash.bashrc :

# Fonction pour connaître le mode en cours
fs_mode=$(mount | sed -n -e "s/^.* on \/ .*(\(r[w|o]\).*/\1/p")
# alias ro/rw pour passer de l'un à l'autre
alias ro='mount -o remount,ro / ; fs_mode=$(mount | sed -n -e "s/^.* on \/ .*(\(r[w|o]\).*/\1/p")'
alias rw='mount -o remount,rw / ; fs_mode=$(mount | sed -n -e "s/^.* on \/ .*(\(r[w|o]\).*/\1/p")'
# Modification du prompt pour afficher le mode en cours
export PS1='\[\033[01;32m\]\u@\h${fs_mode:+($fs_mode)}\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '

Aller hop, on passe au chose sérieuse, on modifie le /etc/fstab :

< /dev/mmcblk0p1  /boot           vfat    defaults          0       2
< /dev/mmcblk0p2  /               ext4    defaults,noatime  0       1
---
> /dev/mmcblk0p1  /boot           vfat    defaults,ro          0       2
> /dev/mmcblk0p2  /               ext4    defaults,noatime,ro  0       1
> tmpfs	/var/log	tmpfs	nodev,nosuid	0	0
> tmpfs	/var/tmp	tmpfs	nodev,nosuid	0	0
> tmpfs	/tmp	tmpfs	nodev,nosuid	0	0

Puis le fichier /boot/cmdline.txt :

< dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
---
> dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait noswap ro

Après un reboot on peut tester :

root@raspberrypi(ro):~# touch /root/testEcriture
touch: cannot touch ‘/root/testEcriture’: Read-only file system
root@raspberrypi(ro):~# rw
root@raspberrypi(rw):~# touch /root/testEcriture
root@raspberrypi(rw):~# rm /root/testEcriture
root@raspberrypi(rw):~# ro
root@raspberrypi(ro):~#

ça fonctionne !

Le petit plus du chef, un petit script ~/.bash_logout pour ne pas oublier de remettre le FS en read only après avoir travaillé dessus…

#!/bin/bash
if [ "$fs_mode" != "ro" ]; then
	read -p "Le FS est en lecture/écriture, ne voudriez vous pas le basculer en lecture seul ? [O/n] " 
	if [[ ! $REPLY =~ ^[Nn]$ ]]
	then
		echo "Bascule en Read/Only"
		ro
	else
		echo "Ok on fait rien tant pi... Mais n'oublie pas que ça use la carte SD :-/"
	fi
fi

[API OVH] Reboot d’un VPS via un script PHP

OVH possède une API qui peut s’avérer très pratique pour automatiser des tâches du manager : https://api.ovh.com

J’ai choisi d’utiliser le PHP pour ces scripts car il est déjà installé sur mes machines, je n’ai donc pas besoin de supplément.

Premier test, lister mes VPS

Je commence gentils, je fais un script qui listera simplement les VPS disponible chez OVH.

Télécharger et décompressé la dernière version de « php-ovh » et ces dépendances : https://github.com/ovh/php-ovh/releases

root@monsrv:~# mkdir ovhphp/
root@monsrv:~# cd ovhphp/
root@monsrv:~/ovhphp# wget https://github.com/ovh/php-ovh/releases/download/v2.0.0/php-ovh-2.0.0-with-dependencies.tar.gz
root@monsrv:~/ovhphp# tar -xzvf php-ovh-2.0.0-with-dependencies.tar.gz

Ensuite on crée un tocken via cette URL : https://api.ovh.com/createToken/?GET=/vps ou on ne va autoriser que le GET sur /vps.

On va obtenir la page suivante, il va falloir conserver Application Key, Application Secret & Consumer Key pour les mettre dans le script :

On va pouvoir créer le script suivant (pensez à recopier vos Application Key, Application Secret & Consumer Key dans les variables) :

#!/usr/bin/php
<?php

// This script is a skeleton of script or application using OVH APIs
// You can launch it with the command php script.php
// Or include it into a website be deleting the first line

require __DIR__ . '/vendor/autoload.php';
use \Ovh\Api;

////////////////////////////////////////////////////
//     Dont forget to update your credentials     //
////////////////////////////////////////////////////

// Please read the documentation to get your credentials
// https://github.com/ovh/php-ovh
$applicationKey = "hsNT*************";
$applicationSecret = "8FcOC***********************";
$consumer_key = "bU5j**************************";

// Information about API and rights asked
$endpoint = 'ovh-eu';

// Get API connector instance
$conn = new Api(    $applicationKey,
                    $applicationSecret,
                    $endpoint,
                    $consumer_key);

////////////////////////////////////////////////////
//       Your logic will be inserted here         //
////////////////////////////////////////////////////

// This is an example
// Here, use the API connector as you want. Here, we are getting all hosting services
$vps = $conn->get('/vps');

print_r($vps);

?>

Lancement du script, voici le résultat :

root@romeo:~/ovhphp# php getvps.php 
Array
(
    [0] => vks00000.ip-XX-XX-XX.eu
)

vks00000.ip-XX-XX-XX.eu c’est le nom de mon VPS (pour l’exemple), ça fonctionne.

Les choses sérieuses : un reboot

Même script avec action cette fois, pour tester le reboot d’un VPS via un script.

De nouveau la création d’API avec l’url https://api.ovh.com/createToken/?POST=/vps/vks00000.ip-XX-XX-XX.eu/reboot. Ici on va autoriser le POST sur /vps/vks00000.ip-XX-XX-XX.eu/reboot.

#!/usr/bin/php
<?php
require __DIR__ . '/vendor/autoload.php';
use \Ovh\Api;
$applicationKey = "fCj********";
$applicationSecret = "vqm**************";
$consumer_key = "Zja************************";
$endpoint = 'ovh-eu';
$conn = new Api(    $applicationKey,
                    $applicationSecret,
                    $endpoint,
                    $consumer_key);
$vps_reboot = $conn->post('/vps/vks00000.ip-XX-XX-XX.eu/reboot');
print_r($vps_reboot);
?>

Au lancement on obtient le numéro de la tâche :

root@romeo:~# php postrebootvps.php
Array
(
    [progress] => 0
    [id] => 5119979
    [type] => rebootVm
    [state] => todo
)

Et ça fait bien redémarrer le VPS…

La finalité

De temps en temps mon VPS est inaccessible. C’est très variable (1 à 2 fois par mois environ) et je ne trouve pas la cause (OVH / système / attaque ?). La seul solution pour le faire repartir c’est un reboot via le manager OVH. En attendant de trouver la cause (je ne désespère pas) j’ai mis en place ce script sur un serveur tiers afin de déclencher un reboot si le serveur est inaccessible.

#!/usr/bin/php
<?php

// Version 0.1 15/03/2015
// Reboot d'un VPS OVH (via l'API OVH) si celui-ci ne répond pas
// Par David Mercereau : http://david.mercereau.info
// Script sous licence BEERWARE

require __DIR__ . '/vendor/autoload.php';
use \Ovh\Api;
    
// Identifiant API OVH : https://api.ovh.com/createToken/
$applicationKey = "fCj********";
$applicationSecret = "vqm*************";
$consumer_key = "Zja***********************";
$endpoint = 'ovh-eu';
// Host à monitorer (IP du VPS)
$serveurMonitorIp = 'A.B.C.D';
// Port à monitorer (doivent être ouvert sur le VPS)
$serveurMonitorPorts = array(80, 22, 25);;
// Site qui permettent de vérifier la connexion internet
$hostsCheck = array('www.wordpress.com', 'fr.wikipedia.org', 'www.ovh.com');

function checkInternet($hostsCheck) {
    $return = true;
    foreach ($hostsCheck as $hostCheck) {
        if (!$sock = @fsockopen($hostCheck, 80, $num, $error, 5)) {
            echo "CheckInternet : Le serveur $hostCheck ne répond pas sur le port 80. Il n'y a pas internet ?\n";
            $return = false;
        }
    }
    return $return;
}

function serveurMonitor($serveurMonitorIp, $serveurMonitorPorts) {
    $return = true;
    foreach ($serveurMonitorPorts as $serveurMonitorPort) {
        if (!$sock = @fsockopen($serveurMonitorIp, $serveurMonitorPort, $num, $error, 5)) {
            echo "ServeurMonitor: Le serveur $serveurMonitorIp ne répond pas sur le port $serveurMonitorPort, Il n'est H.S. ?\n";
            $return = false;
        }
    }
    return $return;
}

if (! serveurMonitor($serveurMonitorIp, $serveurMonitorPorts)) {
    echo "...second test dans 2 minutes, c'est peut être temporaire...\n";
    sleep(120);
    if (! serveurMonitor($serveurMonitorIp, $serveurMonitorPorts)) {
        if  (checkInternet($hostsCheck)) {
            echo "Reboot de $serveurMonitorIp\n";
            // Conneixion à l'API
            $conn = new Api(    $applicationKey,
                                $applicationSecret,
                                $endpoint,
                                $consumer_key);
            $vps_reboot = $conn->post('/vps/vks10057.ip-37-59-126.eu/reboot');
            print_r($vps_reboot);
        } else {
            echo "Le serveur est peut être planté mais peut être pas... il ne semble pas y a voir interne, on fait rien !\n";
        }
    }
} 
exit(0);
?>

En tâche planifiée :

15,45 * * * *  /root/ovhphp/check-serveur.php

Apprendre à sculpter un manchot (tux) en ballon

Tux est un manchot, la mascotte officielle de Linux, Voici une bande dessinée pour vous permettre de le sculpter en ballon. Noter que cette sculpture n’est pas des plus simples. Si vous n’avez jamais fait de sculpture de ballon, préférez commercer par un petit toutou, une fleur, avant de vous attaquer au manchot.

Le format est aux choix :

Si vous préférez apprendre sur vidéo, monsieur ballon vous en propose une.