Yop

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

Mot-clé - GNULinux

Fil des billets - Fil des commentaires

mercredi, 26 juillet 2017

Personnalisation de bannière SSH avec image et texte


  • Récupérer une image idéalement en 32x32

J'ai pris un .png par exemple sur IconArchive.
(Mes 2 lecteurs, partagez vos sources d'icônes pour bannière en commentaires)

  • Installation de quelques paquets

Je ne suis plus trop sûr de ce qu'il faut exactement mais probablement

$ sudo apt-get install imagemagick texinfo openjdk-7-jdk coreutils perl git
  • Installation de util-say pour convertir les images en "texte"
$ git clone https://github.com/maandree/util-say.git
$ ./util-say/img2ponysay dilbert.png > dilbert.txt
Error: Unable to access jarfile ./util-say/util-say.jar
$ cd util-say &&  make && cd ..
$ ./util-say/img2ponysay dilbert.png > dilbert.txt
$  cat dilbert.txt 

  • ponysay a rajouté les lignes avec les $ qu'il faut virer dans notre cas

Suppression de la ligne qui contient "balloon":

 $ sed '/balloon/d' dilbert.txt  

Suppression des lignes avec les $:

 $ sed s/\\$\\\\\\$//g dilbert.txt 

Suppression des 5 premiers caractères de chaque ligne pour décaller l'image vers la gauche:

 $ sed 's/^.\{5\}//g' dilbert.txt 

Suppression des 3 premières lignes:

 $  sed 1,3d dilbert.txt 

Donc la ligne globale:

 $  sed '/balloon/d' dilbert.txt | sed s/\\$\\\\\\$//g | sed 's/^.\{5\}//g' | sed 1,3d > dilbert_cleaned.txt 

  • Script pour rajouter du texte

On édite le script ci-dessous pour modifier la police, les couleurs, et toutes les infos que l'on souhaite.

#!/bin/bash
NAME="Server"
OUT="/tmp/$NAME"
IP_PRV=""
IP_NAT=""
IP_PUB="1.2.3.4"
SERVICE="XXXX Paris"
HD="1 x 50GB"

echo "" > $OUT
echo "" >> $OUT
echo "" >> $OUT

toilet -f Graffiti $NAME | lolcat -f -F 0.3 >> $OUT

cecho () {
  local _color=$1; shift
  echo -ne "$(tput setaf $_color)$@$(tput sgr0)"
}

black=0; red=1; green=2; yellow=3; blue=4; pink=5; cyan=6; white=7;
echo "" >> $OUT

#cecho $white "IP Prv:  " >> $OUT
#echo "$IP_PRV" | toilet -f term | lolcat -f -F 0.4 >> $OUT

#cecho $white "IP NAT:  " >> $OUT
#echo "$IP_NAT" | toilet -f term | lolcat -f -F 0.4 >> $OUT

cecho $white "IP Pub:  " >> $OUT
echo "$IP_PUB" | toilet -f term | lolcat -f -F 0.4 >> $OUT

cecho $white "Service: " >> $OUT
echo "$SERVICE" | toilet -f term | lolcat -f -F 0.4 >> $OUT

cecho $white "Disks: " >> $OUT
echo "$HD" | toilet -f term | lolcat -f -F 0.4 >> $OUT

cat $OUT


echo ""
echo ""
echo "File output into $OUT"

On peut bien entendu modifier le script pour récupérer les infos automatiquement du serveur et ne pas avoir a modifier les valeurs à la main.

  • On installe les 2 paquets suivants utilisés par le script au-dessus
 $ sudo apt-get install toilet lolcat 

Allez voir le man de chaque commande pour les options.

  • On execute le script
 $ ./ip.sh 

A chaque execution, les couleurs seront un peu différentes

  • On joint les 2 fichiers en un seul
 $  paste dilbert_cleaned.txt  /tmp/Server > server.motd 

  • On copie le fichier server.motd dans /etc/motd du serveur
  • Vérifier dans le /etc/ssh/sshd_config que vous avez bien la ligne:
 PrintMotd yes 

dimanche, 8 novembre 2015

Rooter/jailbreaker le Kindle PW2 par le port série

Introduction

Il n'y a même pas la possibilité par défaut sur un Kindle de changer les images de veille. Rien que pour cette raison, on est tenté de rooter/jailbreaker son Kindle afin d'en reprendre un peu le controle. (My device, my rules).

Quand je me le suis procuré il y a quelques mois, il est arrivé en version 5.6 quelquechose et il n'est pas possible à l'heure où sont écrites ces lignes, de le rooter/jailbreaker de manière uniquement logicielle.

Dans des versions précédentes, il était possible de faire passer le JailBreak pour une mise à jour, mais ceci a été "corrigé" par Amazon.

La seule solution est pour l'instant d'ouvrir le Kindle, et d'accèder au port série. (Au moins il y en a un, c'est déjà çà).

IMG_20151107_220727.jpg-s.jpg


La technique dans les grandes lignes:

- Ouvrir le Kindle et se connecter sur le port série
- Booter sur la 2ème partition de debug/diag
- Trouver le mot de passe de cette partition de debug/diag et se connecter en root dessus
- Une fois root sur la partion de debug/diag, monter la partition "principale" pour éditer le fichier /etc/passwd pour en débloquer l'accès root.
- Rebooter sur la 1ère partition et s'y connecter en root.
- Lancer le script de JailBreak

Si j'ai bien compris, Amazon n'autorise que les applications qu'ils ont signés eux (avec leur clé privée) à s'installer. Le JailBreak consiste à ajouter une autre clé publique (dont la communauté connait la clé privée) rendant donc possible l'installation d'applications non authorisée par Amazon.

uggy-kindle-pubKey.png-s.jpg


Connaitre sa version de firmare

Menu/Paramètres/Menu/Infos sur l'appareil/Version du micrologiciel


Trouver son numéro de série/modèle

http://wiki.mobileread.com/wiki/Kindle_Serial_Numbers


Avoir un accès console avec niveaux logiques 1.8V

Le port série des Kindles (au moins mon PW2) communique avec des niveaux logiques 1.8V.

Il faut donc utiliser un port série qui utilise ces niveaux logiques et non les classiques 3.3V et 5V

J'ai utilisé un PL2303HXrevD (dans les 4€ sur Ebay)

PIN4 The power pin for the serial port signals.
The range can be from 1.8V~3.3V

(Attention, le PL2303HX (pas révision D) ne supporte pas le 1.8V d'après la datasheet)

Il suffit de décoller doucement la PIN4 du chip (par exemple avec une petit aiguille) afin de pouvoir la connecter ensuite à du 1.8V (ou 3V3 ou 5V pour d'autres usages)

IMG_20151108_190546.jpg-s.jpg


Trouver le mot de passe de la partition diag (2ème partition)

J'avais initialement utilisé le code suivant trouvé sur le forum http://www.mobileread.com/forums/

#!/usr/bin/env python
import hashlib
print("fiona%s"%hashlib.md5("XXXYOURSERIALXXX\n".encode('utf-8')).hexdigest()[7:11])

Mais dans mon cas, le mot de passe ainsi trouvé n'a ensuite PAS fonctionné.
Même problème avec le site https://www.sven.de/kindle/ qui utilise le même "algo".

J'ai donc utilisé kindletool qui lui m'a donné un mot de passe différent qui a fonctionné sur mon Kindle.

$ ./kindletool info XXXYOURSERIALXXX
Platform is Wario or newer
Root PW fionaXXX
Recovery PW fionaXXXX
$


Démonter le Kindke pour accéder au port console

Je me suis basé sur cette vidéo

Si vous acheter le PL2303HXrevD à HongKong sur un site d'enchère (environ 4€), cà vaut peut être le coup d'acheter en même temps les "Metal spudger" (2€ les 2) mais sinon un couteau avec une lame fine peut faire l'affaire.

Le plus difficile est de ne pas laisser de trace pour passer le spudger sous la coque au tout début.
La suite du démontage est triviale.
Faire cependant attention à la bande de plastique blanche au niveau des LEDs car elle joue sur la répartition de la lumière sur la dalle.


Connecter le port série

uggy-serial-kindle.png-s.jpg

Les pins sont toutes petites, donc à souder avec précaution

IMG_20151107_220202.jpg-s.jpg

Pour les branchements, TX sur RX, RX sur TX, Gnd sur Gnd, le fil vert sur le bouton vert etc..

Les paramètres sont: 8N1 115200

J'ai utilisé "screen"

$ screen /dev/ttyUSB0 115200


Sortir de "veille" le kindle

Si tout se passe bien le port série devrait s'afficher comme ceci

uggy-kindle-Serial.png-s.jpg

Il dit "Welcome", c'est qu'on a le droit de se connecter :)


Boot de la partition diag

Rebooter le Kindle, tapez sur n'importe quelle touche au début du boot pour arreter la séquence (il y a un créneau que de quelques secondes), allez en mode diag en tapant bootm 0xE41000

uggy-kindle-bootm.png-s.jpg


Choisir "Exit, Reboot or Disable Diags" puis "Exit to login prompt" etc...

uggy-kindle-menu1.png-s.jpg

uggy-kindle-menu2.png-s.jpg

uggy-kindle-menu3.png-s.jpg

uggy-kindle-menu4.png-s.jpg


Se logguer

Utiliser le compte de la partition diag trouvé à l'une des étapes précédentes: root/fionaXXX

uggy-kindle-root-diag.png-s.jpg


Monter la partition principale (la 1ère partition) et éditer le fichier etc/passwd

uggy-kindle-passwd1.png-s.jpg


Modifier la ligne pour root.

root:*: -> Indique un mot de passe chiffré dans /etc/shadow
root:: -> Indique qu'il n'y a pas de mot de passe

uggy-kindle-passwd2.png-s.jpg

uggy-kindle-passwd3.png-s.jpg

Pour l'instant on choisi d'enlever le mot de passe


Rebooter, tester l'accès root à la partition principale

uggy-kindle-root-main.png-s.jpg


Télécharger les fichiers de jailBreak

http://www.mobileread.com/forums/showthread.php?t=186645


Connecter l'USB, copier les fichiers à la racine sur le Kindle (USB classique) puis déconnecter l'USB


Executer le scipt de jaibreak avec l'acces root (partition principale, pas diag)

uggy-kindle-jb.png-s.jpg


Conclusion

Ce billet de couvre pas l'installation des outils que l'on peut alors utiliser.

Mais j'ai commencé par personnaliser l'écran de "veille"...

IMG_20151108_191509.jpg-s.jpg

Crédit: De nombreux posts et personnes de http://www.mobileread.com/forums/

lundi, 23 février 2015

Problème de dimension du terminal lors de connexions à travers un port série

Amené à travailler avec le terminal, à travers des connexions série, on constate un problème d'ajustement de la taille après l'utilisation de certaines commandes telles que vi etc...

J'utilise généralement la commande suivante pour me connecter sur le port série /dev/ttyUSB0

screen /dev/ttyUSB0 115200

Le problème est que certains logiciels comme l'éditeur vi considèrent que le la fenêtre de terminal n'est que de 24 lignes. Cela reste ainsi ensuite même après être sorti de l'éditeur. Ce qui laisse une bande vide en bas empêchant d'utiliser toute la hauteur du terminal.

serialProblemeLignesVides.png

Le problème, expliqué par Akkana Peck sur son blog est que screen n'a pas de possibilité d'envoyer par le port série, la taille originale de la fenêtre du terminal, (alors que c'est ce qui se passe en SSH par exemple).

Il ne semble pas non plus y avoir une commande qui permet de demander au terminal sa taille.

Cela n'a pas l'air simple à résoudre, heureusement pour nous, Akkana partage un petit script en python qui ruse en allant déplacer le curseur pour trouver la bonne taille etc.. et permet de résoudre le problème.

TerminalSerialResolution.png

On peut également le mettre par exemple dans le fichier .bash_profile pour qu'il se lance à l'ouverture de la session.

Je ne sais pas s'il quelqu'un connait une meilleure solution à ce problème ? Mais en tout cas cela fonctionne parfaitement pour moi depuis plusieurs mois... et je me suis dit qu'il pouvait être utile de partager l'astuce :)

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.

- page 1 de 32