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 autodiscovery
net 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.gz
tar 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 :
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 :
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.
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 :
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.
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 :
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 à $SYS
topic 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 :
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 :
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 :
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 :
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
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 :
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 :
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 ssl
sudo 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 on
RewriteCond %{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 :