RSYNC over SSH

Logs d’erreur RSYNC / SSH

Permission Denied ou read_passphrase: can’t open /dev/tty: No such device or address

Hello,

Je viens de résoudre ce souci qui m’a bien occupé..

Impossible de se connecter en RSYNC over SSH sur un host distant, malgré avoir stipulé l’ “identity_file” pour SSH…
Rien n’y fait … Rsync me dit « permission denied » et ssh m’indique « read_passphrase: can’t open /dev/tty: No such device or address »

Mais je suis tombé sur un thread qui expliquait que la crontab avait son propre environnement qui n’était pas celui de root (je savais déjà cela mais j’avais pas percuté que c’était encore plus vrai lorsqu’il s’agit de variables d’environnement impliquant le comportement de SSH) … or mes échanges de clés SSH se font avec PassPhrase … donc si environnement différent et bien mon RSYNC over SSH attend une passphrase qui ne peut être saisie => les infos de debug de SSH indiquent d’ailleurs l’erreur

"debug1: read_passphrase: can't open /dev/tty: No such device or address"

=> Bah oui pas de TTY = pas de passphrase = pas autorisé

Sur ma machine j’utilise “Keychain” histoire d’avoir l’agent SSH de lancé afin de ne pas avoir à ressaisir la passphrase à chaque fois que je tente une connexion remote. Keychain génère un fichier qui contient les informations suivantes

SSH_AUTH_SOCK=/tmp/ssh-PWg3yHAARGmP/agent.18891; export SSH_AUTH_SOCK;
SSH_AGENT_PID=18893; export SSH_AGENT_PID;

==> La commande SSH-AGENT retourne les mêmes infos.

Donc, au final ce sont ces infos liées à la session en cours qui permettent les futures authentifications de la session en cours, sans nécessité de rerentrer la passphrase car déjà fait préalablement et mémorisée …


==> La solution est là !!! :

Il suffit dans le script lancée par la crontab, et de “sourcer” le fichier contenant ces informations ou de le faire sur la ligne de commande ds la crontab …

Exemple :

14 09 * * * . /home/foo/.keychain/foo.serveur.org-sh && scp -vvv -P 22 /tmp/mon_fic/toto.sh foo@my-server.fr:. >> /var/log/check_connexion.log 2>&1

ou utilisation de la commande

"source /home/foo/.keychain/foo.serveur.org-sh" 

dans le script qui lance un connexion utilisant le SSH.

=> Avec ce sourcing, plus de souci. Les informations de SSH_AUTH_SOCK et SSH_AGENT_PID sont chargées dans l’environnement de la Crontab et sont donc connues, le RSYNC over SSH se passe alors sans souci.

Ca m’a bien occupé mais voilà, ça fonctionne 🙂


PERL : “Can’t locate feature.pm in @INC” suite à mise jour …

Vous aussi, suite à une mise à jour de votre distribution Linux (apt-get, aptitude, yum ou autre), vous vous êtes retrouvés avec des erreurs PERL du type “Can’t locate feature.pm in @IN” ???

Dans mon cas de figure, ma Debian était encore basée sur des repositories SQUEEZE. Suite à l’arrêt du suivi de SQUEEZE, j’ai du modifier mon “/etc/apt/sources.list” pour faire pointer les repos vers WHEEZY.

La suite logique étant un “aptitude update” (ou apt-get update), j’ai donc tenté un “aptitude full-upgrade” …. et là … Catastrophe , je me suis retrouvé avec des tonnes d’erreurs comme citées en titre de ce post 🙁 (feature.pm, Basename.pm, etc …)

Après plusieurs recherches sur le Net, je n’ai pu trouver un post clair, simple, précis et efficace qui me permettrait d’arriver à mes fins …

Dans mon cas de figure, la version de Perl installée avec SQUEEZE était la 5.10.1 et celle que WHEEZY installe est la 5.14.2. Mais pour une raison inconnue, à un moment, dans le process de mise à  jour, Perl s’est retrouvé à vouloir utiliser les librairies du Perl 5.10.1 alors que le Perl 5.14.2 était installé. La version 5.10.1 ayant été purgée par le process de mise à jour, Perl pointait donc (la fameuse suite de répertoires inclus via la directive @INC) vers la mauvaise installation de Perl 🙁

Et comment modifie-t-on la liste des répertoires listés via la directive @INC ?
Alors il existe des solutions mais franchement je n’ai rien trouvé de clair, simple, précis et efficace …

La seule solution trouvée qui fut clair, simple, précise et efficace : exporter la variable PERL5LIB valorisée avec le chemin exact des librairies de la bonne version de Perl, soit quelque chose du style :

PERL5LIB=/home/path/lib:/usr/another/path/lib; export PERL5LIB

Une fois ceci effectué, la commande “perl -v” me donnait bien la bonne version attendue de Perl.
J’ai ainsi pu relancer un “aptitude update” puis un “aptitude full-upgrade”

Sans cette “bidouille”, aptitude me proposait une fulltitude de solutions, toutes plus destructrices les unes que les autres.

 

On dit quoi ? Merci Perl 🙁

FIRSTHEBERG : souci de RAID et apparition d’un /dev/md126 ou /dev/md127

En gros, pour faire simple, suite à un reboot serveur, on ne peut se reconnecter au serveur et sur la console d’admin (à laquelle on n’a pas accès) on se retrouve avec une impossibilité de monté le volume nécessaire avec un device inexistant ou corrompu. Dans mon cas, /dev/md3 était inexistant.

dev_md3

Après reboot du serveur par les équipes de FIRSTHEBERG, j’ai pu avoir accès au serveur et je me suis rendu compte que seul /dev/md1 était monté malgré le fait que /dev/md3 était mentionné dans le « fstab », ainsi que dans le fichier de conf de « mdadm » (/etc/mdadm/mdadm.conf)
La commande « cat /proc/mdstat » m’indique que /dev/md3 est inexistant mais je vois apparaitre un /dev/md126 !!!!

D’où sort il ce /dev/md126 !!###$$^^##&&**%%§§???

Un « df –h », me confirme la chose … pas de md3 et évidemment pas de md126 car listé dans aucune conf du RAID Soft

df -h

Sys. de fichiers    Taille  Uti. Disp. Uti% Monté sur 
/dev/md1              9,8G  7,7G  1,6G  84% /
tmpfs                 2,0G     0  2,0G   0% /lib/init/rw
udev                   10M  160K  9,9M   2% /dev
tmpfs                 2,0G     0  2,0G   0% /dev/shm

Bref, on se retrouve avec un serveur amputé d’une partie de ses données.

Si je monte le /dev/md126 sur /var, je retrouve toutes mes données. Je me rends compte aussi que l’outil « mdadm », n’est pas installé.
Ayant monté le /var, j’en profite pour lancé la commande « apt-get install mdadm » … pourquoi cet outil est-il absent … bizarre, bonne question, car cet outil est appelé par un script dans « /etc/init.d » … et ce serveur à été souscrit avec cette option de RAID Logiciel dès le départ … “mdadm” devrait être installé et ce n’est pas le cas 🙁

Bref, il est temps de passer aux choses sérieuses.
Pour résumer, j’ai un md126 en lieu et place d’un md3 …
La commande « cat /proc/mdstat » me donne le résultat suivant

cat /proc/mdstat

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md1 : active raid1 sdb1[1] sda1[0]
10239936 blocks [2/2] [UU]

md126 : active raid1 sdb3[1] sda3[0]
476097472 blocks [2/2] [UU]

unused devices: <none>

Elle devrait me donner le résultat :

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md1 : active raid1 sdb1[1] sda1[0]
10239936 blocks [2/2] [UU]

md3 : active raid1 sdb3[1] sda3[0]
476097472 blocks [2/2] [UU]

unused devices: <none>

Donc prenons le taureau par les cornes, et je démonte le « /dev/md126 ».
Ce device étant un Raid Soft, j’arrête le Raid sur ce device :

mdadm -S /dev/md126 » (réponse : mdadm: stopped /dev/md126

La commande suivante va checker le raid que mdadm voit :

mdadm --detail –scan

ARRAY /dev/md1 metadata=0.90 UUID=10460d6e:c684efe0:9d4deba6:47ca997f

Maintenant que md126 est stoppé, il va falloir recréer (réassembler le raid) pour md3. Pour cela on récupère les infos qui vont bien.
Dans le fichier « /etc/mdadm/mdadm.conf », on voit les informations du RAID :

cat /etc/mdadm/mdadm.conf

ARRAY /dev/md1 UUID=10460d6e:c684efe0:9d4deba6:47ca997f
ARRAY /dev/md3 UUID=d65cbf89:20217a78:9d4deba6:47ca997f

Avec la commande « blkid », on récupère les BlockID des devices de stockage

blkid

/dev/sdb1: UUID="10460d6e-c684-efe0-9d4d-eba647ca997f" TYPE="linux_raid_member"
/dev/sdb3: UUID="d65cbf89-2021-7a78-9d4d-eba647ca997f" TYPE="linux_raid_member"
/dev/sda1: UUID="10460d6e-c684-efe0-9d4d-eba647ca997f" TYPE="linux_raid_member"
/dev/sda3: UUID="d65cbf89-2021-7a78-9d4d-eba647ca997f" TYPE="linux_raid_member"
/dev/sda2: UUID="1ba0b73e-fde6-4209-a516-2954608c111f" TYPE="swap"
/dev/sdb2: UUID="a119d4cf-5b1a-4f85-a30d-fbc6c48c3a7a" TYPE="swap"
/dev/md1: UUID="cf984d55-82e2-49bb-90b6-a82792149bb9" TYPE="ext4"

On voit très bien quels devices font partis des quels raid.
Ainsi md1 = sdb1 + sda1 et md3 = sdb3 + sda3
Et voici ZE commande pour réassembler le RAID avec les bons devices :

mdadm --assemble --verbose /dev/md3 /dev/sda3 /dev/sdb3

Et la réponse à cette commande :

mdadm: looking for devices for /dev/md3
mdadm: /dev/sda3 is identified as a member of /dev/md3, slot 0.
mdadm: /dev/sdb3 is identified as a member of /dev/md3, slot 1.
mdadm: added /dev/sdb3 to /dev/md3 as 1
mdadm: added /dev/sda3 to /dev/md3 as 0
mdadm: /dev/md3 has been started with 2 drives.

La commande  de scan me donne alors les infos suivantes :

mdadm --detail –scan

ARRAY /dev/md1 metadata=0.90 UUID=10460d6e:c684efe0:9d4deba6:47ca997f
ARRAY /dev/md3 metadata=0.90 UUID=d65cbf89:20217a78:9d4deba6:47ca997f

Et la commande « cat /proc/mdstat » me donne :

cat /proc/mdstat

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md3 : active raid1 sda3[0] sdb3[1]
476097472 blocks [2/2] [UU]

md1 : active raid1 sda1[0] sdb1[1]
10239936 blocks [2/2] [UU]

unused devices: <none>

C’est donc tout bon, donc un petit check avec un « fsck /dev/md3 »  et je remonte le /dev/md3 sur /var
Il ne reste plus qu’à lancer la commande : update-initramfs -k all –u
Elle permet de régénérer toutes les images de kernel présentes avec les infos Up2date.

Je reboot et voilà 🙂
C’est fini 😛

Merci qui ?

MySQLTuner : Script d’Optimisation Haute Performance

Vous utilisez MySQL ?

Vous n’êtes pas DBA et  vous n’y connaissez pas grand chose (voir rien) en optimisation de Base de Données MySQL ?

MysqlTunner : Cet outil est fait pour vous !

http://blog.mysqltuner.com/

Pour le télécharger :

http://mysqltuner.pl

Cet outil affichere un rapport de ce qui lui parait normal ou pas, avec d’éventuels conseils d’optimisation.
Cet outil ne remplacera jamais un expert DBA pour optimiser une base de données MySQL complexe, mais pour le commun des mortels, c’est amplement suffisant.

Testez-le !!!

gnuMP3d : Un petit Serveur de Streaming MP3 bien pratique :)

GnuMP3d, vous connaissez ?

Ce petit outil, bien pratique, vous permettra de mettre en place, très aisément, un serveur de streaming MP3 accessible via une IHM Web.

En substance, après avoir récupéré le Package DEBIAN, il sera nécessaire de configurer “gnuMP3d” afin de lui indiquer :

  • le port sur lequel l’IHM sera accessible.
  • le chemin où se situe les MP3.
  • des règles “Allow” ou “Deny” afin d’autoriser ou non une ou plusieurs @IP à se connecter à l’IHM Web.
  • des règles de “DownStreaming” en fonction de l’@IP qui effectue la requête de lecture. Le but est de réduire la qualité du MP3 en cours de lecture si la machine effectuant la lecture est, par exemple, hors LAN.
  • le thème graphique choisi
  • diverses options pour le fonctionnement propre de gnuMP3d

Où Récupéré le paquet DEBIAN ?
En effet, dans les versions récentes d’Ubuntu, ce paquet n’est plus disponible dans les dépôts standards.
Le plus simple, vous pouvez aller sur :

http://launchpadlibrarian.net/14176353/gnump3d_3.0-4_all.deb

et effectuer l’installation du package.

Ensuite, il ne vous reste plus qu’a configurer “gnuMP3d“. Ci-après, en exemple, la configuration qui tourne chez moi.

port = 8888
root = /My_Musics
enable_password_protection = 1
authentication_type = Digest
logfile = /var/log/gnump3d/access.log
log_format = $connected_address – $user [$date] “GET $REQUEST” $HTTP_CODE $SERVED_SIZE “-” “$USER_AGENT”
errorlog = /var/log/gnump3d/error.log
user = nobody
allowed_clients = all
always_stream = 1
advanced_playlists = 1
theme = Musicus
theme_directory = /usr/share/gnump3d/
directory_format = <tr><td width=”10%”>&nbsp;</td><td><a href=”$LINK”>$DIR_NAME</a> $NEW</td><td>$SONG_COUNT</td><td>$DIR_COUNT</td><td>[$RECURSE]</td></tr></a>
new_format = <font color=”red”><b>New</b></font>
new_days   = 7
file_format = <tr><td width=”10%”>&nbsp;</td><td><a href=”$LINK”>$SONG_FORMAT</a></td><td align=”right”>[<a href=”/info$PLAINLINK”>Info</a>] [<a href=”$PLAINLINK”>Download</a>]</td></tr>
song_format = $TRACK – $ARTIST – $ALBUM – $SONGNAME [ $GENRE – $LENGTH / $SIZE ] $NEW
sort_order = $TRACK
downsample_enabled = 1
downsample_clients = ALL
no_downsample_clients = 192.168.1.0/24
downsample_high_mp3   = /usr/bin/lame  –mp3input -b 56 $FILENAME –
downsample_medium_mp3 = /usr/bin/lame  –mp3input -b 32 $FILENAME –
downsample_low_mp3    = /usr/bin/lame  –mp3input -b 16 $FILENAME –
plugin_directory = /usr/share/perl5/gnump3d/plugins
mime_file = /etc/gnump3d/mime.types
file_types = /etc/gnump3d/file.types
now_playing_path = /var/cache/gnump3d/serving
tag_cache = /var/cache/gnump3d/song.tags
shoutcast_streaming = 1
use_client_host = 1

Si votre machine est située derrière un Modem ADSL/Routeur/FW, il ne vous reste plus qu’à rediriger le port que vous souhaitez avoir en dehors de votre LAN (pour l’accès depuis l’extérieure) vers le port défini ici : “port = 8888”.

Amusez-vous bien !

20  * * *