Yop

Aller au contenu | Aller au menu | Aller à la recherche

mardi, 15 avril 2014

Ballon de haute altitude avec le Raspberry Pi

Un de mes projets autours du Rasp, était d'envoyer un ballon dans la stratosphère.

Le rasp était utilisé pour tout centraliser; les logs, le gps, les capteurs, le lien radio, les sms ... et un des 2 dispositifs photo avec la caméra "officielle" du Rasp.

J'ai mis une partie des photos sur http://picts.hab.uggy.org/

Au sol, le tout était également géré sous GnuLinux.

Le site de référence qui m'a permis de réussir ce projet est UKHAS

Je vais probablement monter un petit blog/site sur ce sujet des ballons stratosphériques et leur "gestion" sous GnuLinux.

vendredi, 27 décembre 2013

Mise à dispostion rapide de screenshots

J'utilise généralement Shutter pour prendre des screenshots.

J'évite de stoquer ces screenshots sur les sites publics, donc jusqu'à présent, quand je voulais ensuite partager ce screenshot, en gros:
- je l'enregistrais localement
- je faisais un scp du fichier dans le répertoire qui va bien sur un serveur web
- Je faisais des copier/coller de l'URL avec le nom du fichier pour communiquer l'URL.

On peut faire des variantes avec sshfs, scripter quelques trucs.. etc.. mais c'est pas forcément l'idéal.

Mais ce coup ci, j'en avais plusieurs à faire et j'ai donc cherché un truc "propre" pour simplifier le process.

Au bout de quelques secondes de recherche, je suis tombé sur le bien nommé shutter-scp (voir aussi ici. Et c'est exactement ce que je voulais.

Pour l'installation, il suffit de copier un fichier dans le bon répertoire de Shutter (voir le README).
Pour la configuration, il suffit de renseigner où faire le scp (Serveur:Répertoire) ainsi que l'URL qui sera communiquée (à saisir dans le champs "Mot de Passe").

Une fois le screenshot réalisé dans Shutter, un clic pour exporter, un autre pour valider le scp, puis un dernier pour copier l'URL complète.
Avec ma clé SSH chargée en mémoire, pas besoin de mot de passe, en 3 secondes, tout est fait.

ShutterScp1.png

ShutterScp2.png

Merci Christian Weiske

J'avais testé Screencloud qui supporte le SFTP.. Mais il ne supporte pas (encore) l'authentification par clé publique... donc pas possible pour moi.

vendredi, 6 décembre 2013

Backup incrémental avec le Rasp - rdiff-backup


  • Introduction

J'avais lu cet article de Benjamin concernant des sauvergardes distantes chiffrées.

Disposant désormais moi aussi d'un "site distant" où placer un Raspberry (celui avec la chaudière, j'ai pu me lancer également il y a quelques mois.. Mais en utilisant quelques variantes des outils.

- rdiff-backup (au lieu de rsync)
- LoopAES (au lieu de TrueCrypt )

Les raisons principales qui m'ont fait choisir rdiff-backup (par rapport a rsync ou à Duplicity ou encore rsnapshot ou certaines autres solutions sont principalement:

- Incrémental
Donc ne transfère que les modifications.

- Le backup est toujours le mirroir de la dernière version (hormis le répertoire additionel "rdiff-backup-data" qui contient les changements (et suppression).
En gros, il suffit de recopier le répertoire de backup pour repartir comme si de rien n'était si on veut juste restaurer la dernière version de la sauvegarde.

- Conserve les modifications (et suppressions).
Si un fichier est supprimé par erreur de la source, on ne veut PAS qu'il le soit aussi coté backup après synchronisation. Comme il y a bien quand même un "mirroir", le fichier "supprimé" est déplacé dans le répertoire additionel "rdiff-backup-data"

- Permet de restaurer un fichier/répertoire dans sa version à une date donnée.

- Permet de supprimer les anciennes versions de + de XX jours (ou de XX backups) afin de ne pas saturer le disque de backup.

  • Chiffrement

J'ai choisi LoopAES au lieu de Truecrypt uniquement pour des raisons de vitesse d'accès.

Des 2 cotés les données sont chiffrées et rendues accessible dans le répertoire /mnt/.data/

Les passphrases pour déchiffrer les données sont saisient manuellement une fois les Rasps démarrés.
Vu qu'un Rasp ne consomme qu'environ 4€ d'électricité par an, est silencieux et ne chauffe pas, ils restent allumés en théorie en permanence (en + j'ai un petit onduleur).
Les données sont accessible ensuite tout le temps que le Rasp reste allumé.
Mon but est principalement de restreindre l'accès aux données en cas de vol du Rasp/Disque dur. (Le voleur, même geek, à des chances de débrancher le Rasp/disque dur pour le voler ;) )

  • Configuration

- Installation de rdiff-backup des 2 cotés

$ sudo apt-get install rdiff-backup

- Principe

L'authentification SSH se fait par une clé SSH spécifique à la tâche de backup, ce qui permet d'automatiser la connexion et de restreindre les commandes utilisables par cette clé.

Il y a 2 choix possibles dans le sens des connexions.
- Le serveur qui envoit ses données à backuper sur le serveur de backup.
- Le serveur de backup qui vient récupérer les données sur le serveur à backuper.

J'ai choisi la 2ème option:

En cas de compromission du serveur à backuper, aucun accès possible sur le serveur de backup.
En cas de compromission du serveur de backup, un accès restreint à la commande rdiff-backup en lecture seule sur le serveur à backuper (pas d'accès au shell).

command="rdiff-backup --server --restrict-read-only...."

En cas de compromission de la clé privée. Celle ci ne peux pas être utilisée depuis une machine autre que celle déclarée sur le serveur à backuper.

from="1.2.3.4"

- Mise en place des clés SSH

Sur le serveur de backup:

$ ssh-keygen

pas de passphrase car on veut ensuite que la connexion puisse se faire automatiquement

on appelle ces clés par exemple:
id_rsa.backup
id_rsa.backup.pub

dans le fihier .ssh/config du serveur de backup

host ServeurABackuper
hostname host.example.org
user yop
identityfile /home/user/.ssh/id_rsa.backup
port 80

Ajout de la clé publique sur le serveur à backuper dans authorized_keys.
Pensez pour les tests à ne pas utiliser de "SSH Agent Forwarding" ;)
Tester avec une connexion SSH "normale"
Si ok, sécuriser en ajoutant les restrictions suivantes devant la clé:

from="1.2.3.4",command="rdiff-backup --server --restrict-read-only /",no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAABCDxxxx

Tester à nouveaux avec une connexion SSH "normale" (et sans "SSH Agent Forwarding"), la connexion doit être refusée (car seulement la commande rdiff-backup est authorisée avec cette clé)

PTY allocation request failed on channel 0

- Backup

Sur le serveur de backup:

$ rdiff-backup ServeurABackuper::/mnt/.data/ /mnt/.data/backup/ServeurABackuper

Le contenu de /mnt/.data/ du serveur à backuper se retrouve donc dans /mnt/.data/backup/ServeurABackuper/ du serveur de backup.

Est créé en plus, un répertoire propre à rdiff-backup "rdiff-backup-data"

Pour plus d'infos, utiliser les options:

$ rdiff-backup -v5 --print-statistics

- Exemple de suppression d'un fichier

On supprime un fichier sur le serveur à backuper.
On relance un backup.
Le fichier est bien "supprimé" coté répertoire de backup MAIS une copie (compressée en gz et renommée avec la date) est conservée dans le répertoire rdiff-backup-data/increments/

On peut voir les différentes "versions" d'un fichier

rdiff-backup --list-increments file

- Restaurer

Pour une restauration, on peut soit passer par une bête copie classique (cp / scp etc.. ), soit utiliser les options suivantes

rdiff-backup -r now host.net::/remote-dir/file local-dir/file
rdiff-backup -r 10D host.net::/remote-dir/file /tmp/file

10D étant bien entendu la version du fichier "file" d'il y a 10 jours.

Exemple pour restaurer un fichier qui a été supprimé du serveur à backuper hier, puis un backup a eu lieu cette nuit., dans ce cas le fichier a été supprimé le l'image "mirroir", mais est toujours présent dans rdiff-backup-data/increments:

rdiff-backup -r 2D SrvDeBackup::/mnt/.data/backup/xxxxx/yyyyy/file localrep/file

La commande ici est lançée depuis le serveur à backuper. On ne peut pas utiliser "now" car le fichier n'est déjà plus dans le mirroir à cause de la synchro de la nuit. Le fichier zzz n'est en fait plus présent dans /mnt/.data/backup/xxxxx/yyyyy/ mais la commande fonctionnera et ira chercher le fichier en réalité dans rdiff-backup-data/increments/

- Supprimer les anciennes versions de fichiers.

Comme on a pas non plus un espace illimité pour garder 10 000 versions de tous les fichiers (ou les fichiers supprimés) , il est nécessaire de supprimer régulièrement les "vielles" versions.

Ceci est réalisé par la commande suivante:

rdiff-backup --remove-older-than 2W host.net::/remote-dir

Ici les anciennes versions de plus de 2 semaines seront supprimées.
Bien ententu, ceci n'efface PAS les fichiers de la sauvegarde, même s'il datent de 10 ans, uniquement les anciennes versions.

rdiff-backup --remove-older-than 20B host.net::/remote-dir

Ici seules les modifications des 20 dernières sessions de Backups sont conservés.

J'aurais bien vu aussi une option qui aurait pris une taille en paramètre. Par exemple, "tu me supprimes les modifications de sessions de sorte que je n'utilise pas plus de 10Gio d'anciennes sessions"... Mais ceci n'existe pas. Il y a peut être une bonne raison ?

Dans mon cas, la commande est lancée en "local" dans le script tournant sur le serveur de backup

rdiff-backup --remove-older-than 12M --force /mnt/.data/backup/ServeurABackuper

  • Script et mise en cron

Mon script tourne sur le serveur de backup et fonctionne ainsi dans une cron chaque nuit:

- Vérification que le répertoire chiffré est bein accessible en clair et si oui:
- Backup
- Supression des anciennes versions
- Un petit mail récaptulatif

Sinon, petit mail d'alerte, car il y a du avoir un reboot.

  • Conlusion

La solution permet donc d'avoir à moindre frais (Un Rasp + un Disque dur + 4€ d'électricité par an + des beaux parents pour héberger le Rasp ;) ) une solution de backup:

- Discrète (ne prend pas trop de place et est silencieux)
- Incrémental (Optimisation bande passante et temps de backup)
- Securisé (Chiffré + SSH + pas dans le Cloud de la NSA + site distant)
- On peut restaurer tout notre backup facilement. Même en copiant simplement le répertoire.
- On conserve les anciennes versions des modifications/supressions que l'on peut restaurer facilement également.

samedi, 19 octobre 2013

Domotisation d'une chaudière avec le RaspberryPi

  • Introduction

Mon but était de pouvoir allumer le chauffage (chaudière) d'une maison secondaire à distance. La chaudière est équipée d'un thermostat qui peut maintenir une température programmée automatiquement, mais le besoin est de pouvoir passer, à la demande, et à distance, du mode "Hors gel" au mode "JeVeux18°C".
Par exemple X semaines sans rien chauffer du tout.. puis du jour au lendemain décider de vouloir 18°C. (Si vous pensez que ce n'est pas grave d'arriver dans une maison à 2°C, vous n'avez probablement pas encore d'enfants ;) )

Trève de blabla.. en vrac:

- La chaudière est équipée d'un "boitier/thermostat" filaire déporté, qui permet de contrôler la chaudière.
- La première idée était de voir si le fabriquant ne proposait pas un module permettant de réaliser ceci.
-> Oui, a priori c'est possible mon bon Monsieur, en échange d'un peu plus de 300€ HT.
- Mmmm... j'achète 10 Rasp pour ce prix là moi :)
- On va donc partir sur l'utilisation du Rasp, qui de toute façon est déjà sur place ;)
- La seconde idée est de voir quel est le protocole utilisé entre le thermostat et la chaudière.. pour ensuite essayer de l'implémenter sur le Rasp.
- Après investigations, il s'agit du protocole eBUS
- A première vue, cela semblerais à peu près jouable de l'implémenter (UART etc.. ) même si le "projet" à l'air d'être complètement mort.
- Mais très vite, cela semble quand même bien galère... Une partie du peu de doc est en Allemand.. Risque de péter la chaudière et le thermostat, beaucoup de temps à passer pour (essayer d') implémenter le protocole et trouver les bons menus..le tout sans être sûr d'y parvenir..et le tout pour un protocole déjà mort.
- On en vient donc finalement rapidement à la 3ème idée: simuler la séquence d'appui sur les boutons du thermostat filaire existant, qui permet de passer du mode "HorsGel" au mode "JeVeux18°C"

  • Approche

- Démontage du thermostat existant.
- On trouve rapidement les contacts des 2 boutons utilisés pour aller dans les menus.
- On soude les 4 fils, on les fait sortir sur le coté.. et on referme le tout.
- Le thermostat pourra donc toujours être utilisé en "local" en appuyant sur les boutons.. mais ensuite en plus à distance par le Rasp.

chaudiere-filsSoudes.png

- Maintenant il faut pouvoir faire "contact" entre les 2 fils de chaque bouton pour simuler l'appui.
- On est en courant continu.. et avec un ampèremètre, on le mesure l'histoire de voir.
- Plusieurs solutions sont envisageables pour créer le contact et donc simuler l'appui sur le bouton; transistor, relai "normal", reed relay, circuit intégré, etc..
- J'écarte l'idée du transistor, car je ne sais pas ce qu'il y a devant et derrière les boutons "interrupteurs" du thermostat.. n'étant pas spécialiste, je n'ai pas envie de cramer le tout... (qui coûte certainement le même prix que le module de commande à distance ;) )
- Après recherche sur le net.. le 74HCT4066 est censé faire l'affaire.
- Je prends mon 74HCT4066, je n'ai aucun problème pour allumer/éteindre une LED par exemple.. mais cela ne marche pas sur les contacts de la chaudière.. Je ne sais pas pourquoi... (Trop faible intensité ? J'ai bien mis à la masse les entrées non utilisées, j'ai aussi testé avec une résistance de 50 Ohms.. bref..)
- On passe à la solution de backup (c'est que l'hiver approchait ;) ).. des Reed Relay que j'avais en stock. (Commandés aussi pour un autre besoin).
- Les miens (1.8€) sont en "5V" (3,7V minimum pour se fermer) et un "level shifter" est donc nécessaire pour "monter" les 3.3V de la GPIO du Rasp à 5V.
- Je ne m'étant pas sur les Level Shifter dans ce billet. Cela pourra être l'objet d'un autre.
- L'intensité est largement en dessous de la limite.. donc c'est ok.

  • Schémas

chaudiere.png

Je n'ai pas vraiment le temps de faire un beau schéma sous Fritzing.
Donc vous aurez la version "moche/papier" ;)

chaudiere-schema.png


  • Mise en place

- Test sur breadboard avec donc les level shifter et 2 reed relais.
- Les entrées des relais sont donc commandées par 2 GPIOs du Rasp (17 et 18 dans mon cas).
- J'installe wiringPi parce que c'est plus simple (et parce que je le vaux bien).
- Je passe les 2 GPIOs en "sortie"

$ gpio mode 0 out
$ gpio mode 1 out

- Je créé les contacts en passant à 1 les GPIOs pendant 0.3 secondes.
- Pour moi la séquence est assez simple (Bouton A / Bouton B / Bouton A):

gpio write 0 1 && sleep 0.3 && gpio write 0 0 && sleep 1 && gpio write 1 1 && sleep 0.3 && gpio write 1 0 && sleep 1 && gpio write 0 1 && sleep 0.3 && gpio write 0 0

- Les tests sont concluants... \o/

chaudiere-breadboard.png

- On dégaine le fer à souder
- On soude le tout comme sur la breadboard de test..
- On rajoute un DS18B20 (1€) et sa résistance pour pouvoir connaitre la température à distance. (Je ne détaille pas cette partie, voir par exemple ici ou .
- On rajoute une LED pour montrer que le montage est sous tension. (Et pour impressionner Madame).
- On force les GPIOs en mode "sortie" et à 0 dès le boot dans le /etc/rc.local
- On refait un petit script plus propre.
- On re-teste..
- C'est OK, on peut aller boire une bière.

chaudiere-soude.png

  • Futur

- Finaliser le boitier et les câbles vers le thermostat
- Interface web (en plus de SSH) pour avoir la température et allumer la chaudière.
- Voir si on veut commander la chaudière par SMS avec Gammu
- Voir si on veut implémenter d'autres séquences (passage en HorsGel en cas d'oubli en partant)

  • Conclusion

Il n'y a pas difficulté particulière à réaliser ceci.. Et pas réellement d’intérêt à publier ces informations propres à une chaudière.. Le but est juste de montrer qu'avec un peu de motivation, un esprit un peu DIY et quelques Euros de composants, on peut facilement utiliser le Rasp pour domotiser plein de choses.. et j'espère que cela donnera des idées à certains pour mettre en place leurs propres projets domotiques ! :)

mardi, 3 septembre 2013

Envoi de SMS par le RaspberryPi

J'ai un projet où le Rasp doit envoyer des informations par SMS.

J'ai acheté 10€ une clé 3G d'occasion pour l'utiliser avec Gammu

  • Informations sur la clé

$ dmesg | grep tty | grep usb
[ 1014.053491] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB0
[ 1014.062066] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB1
[ 1014.069542] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB2
$
$ lsusb | grep -i Huawei
Bus 001 Device 006: ID 12d1:1001 Huawei Technologies Co., Ltd. E169/E620/E800 HSDPA Modem
$

  • Installation de Gammu

$ sudo apt-get install gammu

  • Paramétrage

$ gammu-detect
; Configuration file generated by gammu-detect.
; Please check The Gammu Manual for more information.

[gammu]
device = /dev/ttyUSB0
name = Phone on USB serial port HUAWEI_Technology HUAWEI_Mobile
connection = at

[gammu1]
device = /dev/ttyUSB1
name = Phone on USB serial port HUAWEI_Technology HUAWEI_Mobile
connection = at

[gammu2]
device = /dev/ttyUSB2
name = Phone on USB serial port HUAWEI_Technology HUAWEI_Mobile
connection = at
$

Dans /etc/gammurc on met juste:

[gammu]
device = /dev/ttyUSB0
name = Phone on USB serial port HUAWEI_Technology HUAWEI_Mobile
connection = at

$ gammu identify
Périphérique : /dev/ttyUSB0
Fabricant : Huawei
Modèle : unknown (K3565)
Firmware : 11.111.11.11.11
IMEI : 222222222222222

Si un code PIN est activé

$ gammu getsecuritystatus
Waiting for PIN.
$ gammu entersecuritycode PIN 1234
$ gammu getsecuritystatus
Nothing to enter.
$

  • Envoi de SMS

$ gammu sendsms TEXT 0612345678 -text "Test 1"
If you want break, press Ctrl+C...
Sending SMS 1/1....waiting for network answer..OK, message reference=1
$

$ echo "Test 2" | gammu sendsms TEXT 0612345678
If you want break, press Ctrl+C...
Sending SMS 1/1....waiting for network answer..OK, message reference=2
$

  • Divers

$ gammu getlocation
Latitude : 48.XXXXXX
Longitude : 2.XXXXXX
Range : 50000
Number of samples : 70
$

Gammu envoi la CellID sur le site web du projet open source OpenCellID (GET HTTP).
(Il faut un accès Internet dans ce cas, donc je ne pourrais l'utiliser)

  • Conclusion

Nous avons donc pour 10€ de clé, et 2€ (voir 0€ ;) ) de forfait mensuel une solution d'envoi de SMS illimité.

Pour toutes les infos, voir la doc .

- page 1 de 45