Si l’imprimante de mon multifonction Epson WorkForce WF-2865 connecté en WiFi ne m’a guère posé problème, l’utilisation du scanner a été plus délicate...

On commence par installer sane :

sudo apt install sane sane-utils

On édite le fichier /etc/sane.d/dll.conf :

sudo nano /etc/sane.d/dll.conf

et on décommente la ligne du pilote epson2.

Pour l’étape suivante, on va avoir besoin de connaître l’adresse de notre imprimante au sein de notre réseau ; pour ce faire, on utilise l’utilitaire nmap qu’il convient d’installer :

sudo apt install nmap

On peut ensuite, pour effectuer un scan rapide, lancer la commande suivante :

sudo nmap -sn 192.168.1.0/24

et on obtient, entre autres :

[...]Nmap scan report for 192.168.1.12
Host is up (-0.17s latency).
MAC Address: 38:9D:92:29:1C:FC (Seiko Epson)
[...]

Nous pouvons désormais éditer le ficier /etc/sane.d/epson2.conf :

sudo nano /etc/sane.d/epson2.conf

en modifiant la fin du fichier de la sorte :

#net autodiscoverynet 192.168.1.12

On se rend ensuite sur le site d’Epson pour récupérer le logiciel ImageScan ainsi que les pilotes pour notre architecture.

Par exemple :

wget https://download2.ebz.epson.net/imagescanv3/common/deb/arm/imagescan-bundle-common-3.65.0.arm.deb.tar.gztar xvzf imagescan-bundle-common-3.65.0.arm.deb.tar.gz
cd imagescan-bundle-common-3.65.0.arm.deb/
sudo ./install.sh

On ouvre ensuite le fichier /etc/imagescan/imagescan.conf :

sudo nano /etc/imagescan/imagescan.conf

et on le modifie pour obtenir cela :

[devices]myscanner.udi    = esci:networkscan://192.168.1.12:1865
myscanner.vendor = Epson
myscanner.model  = WF2865

Désormais vous devriez voir votre scanner dans Imagescan et sane (et tous les logiciels qui s’appuient sur lui tels xsane ou Gimp) devrait trouver votre périphérique sans soucis !

Le skin Belchertown pour WeeWX proposé par Pat O’Brien est extrêmement complet (et complexe, du moins pour moi) et est particulièrement intéressant pour ses graphiques dynamiques en JavaScript.

Installation et configuration de base

Son installation n’est pas particulièrement difficile puisqu’il suffit de suivre les instructions fournies ; ainsi, à ce jour :

wget https://github.com/poblabs/weewx-belchertown/releases/download/weewx-belchertown-1.2/weewx-belchertown-release-1.2.tar.gzsudo wee_extension --install weewx-belchertown-release-1.2.tar.gz

Ensuite, il convient de passer à sa configuration en ayant pris soin, afin de bénéficier de certaines options dont le module de prévisions à sept jours, de remplir certaines conditions.

La configuration de base est la suivante :

sudo nano /etc/weewx/weewx.conf

[StdReport]    ...
    [[Belchertown]]
        skin = Belchertown
        HTML_ROOT = /var/www/html/weewx/

MQTT

Nous allons surtout nous intéresser à la mise en place du rafraîchissement automatique des graphiques et de l’affichage des données permises par ce skin grâce au protocole MQTT (Message Queuing Telemetry Transport). Il convient d’abord d’installer et de configurer un « serveur », un broker, en l’occurrence mosquitto tel que nous l’avons vu dans un précédent article à partir du post de Pat O’Brien sur son blog.

Bien sûr, dans mon cas, WeeWX ne récupérant des données de la station météo que toutes les cinq voire dix minutes, l’utilisation du plugin weewx-mqtt ne se justifie pas forcément...

Une fois le broker Mosquitto installé et configuré, il faut installer le plugin weewx-mqtt :

sudo pip3 install paho-mqttwget -O weewx-mqtt.zip https://github.com/matthewwall/weewx-mqtt/archive/master.zip
wee_extension --install weewx-mqtt.zip

On modifie ensuite sa configuration qui dépend de la section [Restful] dans le fichier /etc/weewx/weewx.conf :

[Restful]    ...
    [[MQTT]]
        server_url = mqtt://USER:PASSWORD@SERVER:PORT/
        topic = weewx
        unit_system = METRIC
        binding = archive, loop
        aggregation = aggregate
        [[[tls]]]
            tls_version = tlsv12
            ca_certs = /etc/ssl/certs/ca-certificates.crt

On en profite pour éditer la configuration du skin Belchertown de la sorte :

[StdReport]    ...
    [[Belchertown]]
        skin = Belchertown
        HTML_ROOT = /var/www/html/weewx/
        mqtt_websockets_enabled = 1
        mqtt_websockets_host = "SERVER"
        mqtt_websockets_port = 9001
        mqtt_websockets_ssl = 1
        mqtt_websockets_topic = "weather/loop"
        disconnect_live_website_visitor = 1800000

Il ne nous reste plus qu’à relancer weewx :

sudo service restart weewx

On peut vérifier le bon fonctionnement du plugin weewx-mqtt en lançant la commande mosquitto_sub pour suivre le topic weewx/loop ou en épluchant /var/log/syslog à la recherche d’une ligne de ce type :

tail -f /var/log/syslog | grep weewx[snip]
Mar  1 06:48:23 raspberrypi weewx[3998] INFO weewx.restx: MQTT: Published record 2021-03-01 06:45:00 CET (1614588300)
[snip]

J’ai découvert le protocole MQTT (Message Queuing Telemetry Transport) lors de l’interfaçage de ma station météo Netatmo et du logiciel WeeWX sur mon Raspberry Pi ; il s’agit d’un protocole de messagerie de type publication-abonnement, extrêmement rapide et léger, utilisé notamment dans l’internet des objets.

Nous allons ici voir comment installer et configurer un broker, un agent MQTT, en l’occurrence Mosquitto, en nous appuyant très largement sur l’article « How to setup your own MQTT Broker » de Pat O’Brien.

Installation et premiers tests

On commence par l’installer :

sudo apt install mosquitto mosquitto-clients

Nous pouvons dès lors « jouer » un peu...
On peut commencer par vérifier la version de notre agent ou le temps écoulé depuis son lancement :

mosquitto_sub -t \$SYS/broker/versionmosquitto_sub -t \$SYS/broker/uptime

Puis commencez par ouvrir deux sessions dans votre terminal (on ne saurait trop vous conseiller d’utiliser tmux, présenté dans cet article) : dans la première, on lance la commande mosquitto_sub -t test/# puis dans la seconde on lance mosquitto_pub -t test/test -m "Test message"...

Configuration, accès, SSL

Il convient de préciser d’emblée que Mosquitto est très regardant sur le formatage de ses fichiers de configuration et qu’il n’accepte pas d’espace en fin de ligne.

On commence par éditer un fichier /etc/mosquitto/conf.d/myconfig.conf :

persistence false# mqtt
listener 1883
protocol mqtt

# websockets
listener 9001
protocol websockets

On redémarre alors Mosquitto :

sudo service mosquitto restart

Gestion des accès

Mosquitto permet de gérer topic par topic les droits de publication et d’abonnement.

On commence par générer un couple identifiant / mot de passe, ainsi :

sudo mosquitto_passwd -c /etc/mosquitto/passwd USER

puis on édite un fichier /etc/mosquitto/acl

# Autoriser l'abonnement anonyme à $SYStopic read $SYS/#

# Autoriser l'abonnement et la publication anonymes à test 
topic test/#

# Autoriser le seul abonnement anonyme à testlecture
topic read testlecture/#

# Accès limité pour l'écriture sur testlecture
# Abonnement et publication sur secret pour USER seulement
user USER
topic write testlecture
topic secret/#

on édite ensuite le fichier /etc/mosquitto/conf.d/myconfig.conf pour qu’il ressemble à cela :

persistence falseallow_anonymous true
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl

# mqtt
listener 1883
protocol mqtt

# websockets
listener 9001
protocol websockets

On redémarre le service avant de vérifier avec la commande netstat que les ports déclarés sont bien ouverts :

$ sudo service mosquitto restart$ sudo netstat -tulpn | grep 1883
tcp        0      0 0.0.0.0:1883            0.0.0.0:*               LISTEN      142015/mosquitto
tcp6       0      0 :::1883                 :::*                    LISTEN      142015/mosquitto
$ sudo netstat -tulpn | grep 9001
tcp6       0      0 :::9001                 :::*                    LISTEN      142015/mosquitto

Pour le canal test, accessible sans authentification ni pour l’abonnement ni pour la publication, on vérifie avec cette commande dans notre première session :

mosquitto_sub -h localhost -p 1883 -t test/#

et dans la seconde nous lançons :

mosquitto_pub -h localhost -p 1883 -t test/1 -m "Hello topic test/1"

Le canal testlecture ne devrait être accessible anonymement qu’en lecture :

mosquitto_sub -h localhost -p 1883 -t testlecture/#

La première des deux commandes suivantes ne devrait rien renvoyer dans notre première session ; il convient en effet de s’authentifier pour publier dans ce canal :

mosquitto_pub -t testlecture/test -m "test"mosquitto_pub -u USER -P PASSWORD -t testlecture/test -m "test"

Enfin, le canal secret nécessite de s’authentifier aussi bien pour l’abonnement que pour la publication :

mosquitto_sub -u USER -P PASSWORD -t secret/#

mosquitto_pub -u USER -P PASSWORD -t secret/test -m "test"

Certificat SSL

Il est bien évidemment possible de rendre cet agent MQTT accessible sur Internet et de le configurer pour qu’il utilise une connexion sécurisée grâce à un certificat comme ceux proposés par Let’s Encrypt. Nous allons considérer ici que vous avez déjà configuré votre nom de domaine et généré le certificat, comme évoqué ici.

Ainsi, dans mon cas, vous devriez pouvoir vous abonner au canal weather produit par WeeWX et son plugin weewx-mqtt avec la commande suivante :

mosquitto_sub -h meteo.momh.fr -p 8883 --capath /etc/ssl/certs/ -t weather/#

Il convient, après avoir généré son certificat, d’éditer le fichier /etc/mosquitto/conf.d/myconfig.conf de la sorte :

# Insecure mqtt to localhost only, and secure mqttlistener 1883 localhost
listener 8883
certfile /etc/letsencrypt/live/DOMAINE/cert.pem
cafile /etc/letsencrypt/live/DOMAINE/chain.pem
keyfile /etc/letsencrypt/live/DOMAINE/privkey.pem
protocol mqtt

# websockets
listener 9001
certfile /etc/letsencrypt/live/DOMAINE/cert.pem
cafile /etc/letsencrypt/live/DOMAINE/chain.pem
keyfile /etc/letsencrypt/live/DOMAINE/privkey.pem
protocol websockets

Après avoir redémarré le service

sudo service mosquitto restart

on peut tester ainsi, avec pour chacune de nos deux sessions, les commandes :

mosquitto_sub -h DOMAINE -p 8883 --capath /etc/ssl/certs/ -u USER -P PASSWORD -t secret/#

mosquitto_pub -h DOMAINE -p 8883 -u USER -P PASSWORD --capath /etc/ssl/certs/ -t secret/test -m "Test message dans le canal secret"

Nous pouvons désormais utiliser notre agent MQTT avec WeeWX !

Ayant « associé » ma station météo Netatmo à mon Raspberry Pi grâce à WeeWX (lire ce post), je souhaite désormais rendre accessible sur Internet le site web ainsi généré. Je considère ainsi que vous avez déjà un serveur Apache fonctionnel et configuré (même si nous aborderons la création d’un VirtualHost par la suite).

DynHost et mise à jour de l’IP

Étant chez OVH, je profite de leur service DynHOST qui « permet de faire pointer un sous-domaine vers une adresse IP dynamique qui sera mise à jour dans votre zone DNS à chaque changement de celle-ci. ».

On crée notre DynHost puis on en gère les accès, en créant un nouvel identifiant. Puis, sur notre Raspberry Pi, on installe ddclient :

sudo apt install ddclient

Lors de l’installation, des écrans successifs vont nous permettre de le configurer :

• Fournisseur de service de DNS dynamique : Autre
• Protocole de mise à jour du DNS dynamique : dyndns2
• Serveur de DNS dynamique : www.ovh.com
• Mandataire HTTP : néant
• Identifiant : l’identifiant saisi précédemment (comprenant le nom de domaine en préfixe)
• Mot de passe : le mot de passe correspondant
• Méthode de découverte d’adresse IP : Service de découverte d’IP basée sur le web
• Hôtes à mettre à jour : le DynHost créé précédemment

La configuration peut se faire sinon à la main, en éditant le fichier /etc/ddclient.conf qui doit ressembler à cela :

protocol=dyndns2use=web, web=checkip.dyndns.com
server=www.ovh.com
login=DOMAINE-USER
password='PASSWORD'
DYNHOST

Il vous faut ensuite éditer le fichier /etc/default/ddclient et veiller à bien avoir :

run_daemon="true"

Et enfin, on redémarre ddclient :

sudo service ddclient restart

Redirection des ports

Ensuite, il faut se rendre dans l’interface de gestion de votre Box Internet et configurer, dans la section NAT, la redirection des port 80 et 443 vers ceux de votre Raspberry Pi (pour en connaître l’IP sur votre réseau local, utilisez la commande hostname -I).

Désormais, en saisissant l’URL de votre DynHost, vous devriez accéder à la même page que lorsque vous accédez à l’adresse localhost.

Mise en place du HTTPS

Pour ce faire, nous allons générer un certificat Let’s Encrypt pour notre DynHost.

On commence par copier, dans /etc/apache2/sites-available/, le fichier 000-default.conf vers DYNHOST.conf  ; par exemple :

sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/meteo.momh.fr.conf

puis par le configurer pour pointer vers notre répertoire /var/www/html/weewx ou autre répertoire en fonction du ou des skin(s) que vous utilisez. Par exemple, minimalement :

<VirtualHost *:80>        ServerName meteo.momh.fr

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html/weewx

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

Pour générer le certificat, nous allons utiliser certbot, qu’il convient d’installer :

sudo apt install certbot python3-certbot-apache

puis d’activer le module ssl d’Apache :

sudo a2enmode sslsudo systemctl restart apache2

On peut alors générer notre certificat avec la commande suivante :

sudo certbot --apache -d DynHOST

Il vous est proposé de rediriger l’éventuel traffic HTTP vers HTTPS :

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2

Un certificat est alors généré et un nouvel hôte virtuel est configuré dans Apache, à l’emplacement /etc/apache2/sites-available/DYNHOST-le-ssl.conf. Si vous avez choisi l’option 2, le VirtualHost présenté ci-dessus se voit modifié avec les lignes suivantes :

RewriteEngine onRewriteCond %{SERVER_NAME} =DYNHOST
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

Pour voir que tout fonctionne, on peut utiliser l’outil de test proposé par ssllabs.com.

Il peut être parfois bien utile de pouvoir ouvrir un fichier distant autrement que dans un simple nano ou vi, directement dans votre éditeur local, en l’occurrence dans mon cas Sublime Text.
La combinaison rmate / RemoteSubl est là pour cela !

Sur le client, on commence par installer via le gestionnaire de paquet de Sublime Text le plugin RemoteSubl.

Sur le serveur, il faut installer rmate que l’on peu renommer en rsubl :

sudo curl -o /usr/local/bin/rsubl https://raw.githubusercontent.com/aurora/rmate/master/rmatesudo chmod +x /usr/local/bin/rsubl

Depuis le client, il faut ensuite ouvrir une connection SSH avec un routage de port :

ssh -R 52698:localhost:52698 user@example.com

puis de lancer la commande :

rsubl file.txt

et ce fichier doit s’ouvrir dans Sublime Text, qui doit être préalablement ouvert localement.