pawelko.net

Pour la version française, suivre ce lien.

My Kiss-DP500 DVD/DivX player can't play a lot of divx, because of the new codec extensions (QPEL, GMC, etc...). Most "recent" firmwares are buggy, and I often have to recode my movies.
The magic command line is:
mencoder baddivx.avi -of avi -oac mp3lame -lameopts cbr:br=128 -ovc lavc -lavcopts vcodec=mpeg4:vhq -ffourcc DX50 -o newdivx.avi

Of course, you need mencoder and appropriate plugins.
You can use this script, it takes the avi file name as an argument and creates and kiss-friendly version : divxconvert.sh

Photorec est un utilitaire fonctionnant sous Linux et Windows qui est capable (entre autres) de scanner des cartes flash illisibles et de restaurer les fichiers qui y sont enregistrés.

Voici un bref tutoriel basé sur un cas réél : la batterie était vide et l'appareil photo s'est probablement éteint durant l'écriture sur la carte, la table des fichiers étant ainsi corrompue. La récupération a été effectuée sous Linux, pour plus de souplesse.

Windows ne veut plus de la carte ("Vous devez formater le disque avant de l'utiliser")
Parfois linux accepte la carte sans broncher, ce n'est pas le cas cette fois-ci.

Sur une Debian ou Archlinux, il faut installer le paquet testdisk, qui comprend photorec.

Pour avoir l'erreur détaillée, il suffit de lancer la commande dmesg dans un terminal.

$ dmesg
sd 2:0:0:3: [sde] 512000 512-byte hardware sectors (262 MB)
sd 2:0:0:3: [sde] Write Protect is off
sd 2:0:0:3: [sde] Mode Sense: 43 00 00 08
sd 2:0:0:3: [sde] Assuming drive cache: write through
sd 2:0:0:3: [sde] 512000 512-byte hardware sectors (262 MB)
sd 2:0:0:3: [sde] Write Protect is off
sd 2:0:0:3: [sde] Mode Sense: 43 00 00 08
sd 2:0:0:3: [sde] Assuming drive cache: write through
sde: sde1
FAT: invalid media value (0x78)
VFS: Can't find a valid FAT filesystem on dev sde1.
FAT: invalid media value (0x78)
VFS: Can't find a valid FAT filesystem on dev sde1.

Premièrement, il est préférable de travailler sur une copie de la carte, que nous allons créer dans le répertoire "photorec"

$ mkdir photorec
$ cd photorec
$ cat /dev/sde > sde.img

On obtient donc un fichier sde.img de la taille de la carte flash. On peut vérifier qu'il s'agit bien d'une image de disque :

$ file sde.img
sde.img: x86 boot sector

Il suffit ensuite de lancer photorec en lui indiquant le fichier image

$ photorec sde.img

• Sélectionner le fichier sde.img
• Choisir le type de partition intel
• Sélectionner la partition
• Choisir le système de fichiers Other (FAT)
• Choisir "Free"
• Taper Y pour enregistrer les images trouvées dans le répertoire en cours, dans le répertoire recup_dir.1

S'il manque des images, relancer l'opération en modifiant les options

• Brute force: Yes
• Whole disk

Une fois les images récupérées, le fichier .img peut être supprimé, et la carte formatée.

Astuce : Si des images jpeg semblent endommagées avec certains logiciels (comme Photoshop), essayer de les ouvrir avec Gimp.

Site officiel de photorec

Une petite démonstration de la puissance et de la souplesse de Linux :

Le contexte

Suite à un déménagement, ma connexion ADSL tardait à revenir, et mes mails commençaient à s'entasser sur un MX secondaire herbegé par un ami. Ne voulant pas attendre, je me décidais à utiliser une connexion internet RTC pour rapatrier mon courrier, mais je ne voulais pas modifier la configuration du serveur mail distant. De plus, l'adresse IP de la connexion RTC n'étant pas fixe, cela m'aurait obligé à modifier cette configuration à chaque connexion.

La solution

mxsecondaire essayait de se connecter à mxprincipal (dont l'ancienne IP fixe était A.A.A.A) de façon régulière. Il fallait donc arriver à détourner de trafic de mxsecondaire à destination de mxprincipal:25 pour l'amener à bon port.

La solution consistait donc à:

• Connecter mxprincipal à internet via un windows XP qui possédait un modem RTC
• Ouvrir une session ssh de mxprincipal sur mxsecondaire, en activant le forward de ports de mxsecondaire:65000 vers mxprimaire:25
• Sur mxsecondaire, détourner le trafic sortant vers A.A.A.A:25 et le renvoyer vers 127.0.0.1:65000
• Attendre une saisie de l'utilisateur pour remettre tout correctement en place et se déconnecter

LA ligne de commande

Evidemment, en bon linuxien, il fallait que tout cela se fasse en une seule ligne de commande, lancée depuis mxprimaire

ssh mxsecondaire -R 65000:localhost:25 "iptables -A OUTPUT -t nat -p tcp -d A.A.A.A 
--dport 25 -j DNAT --to 127.0.0.1:65000 &&  echo "Appuyer sur entrée pour quitter" && 
read && iptables -D OUTPUT -t nat -p tcp -d A.A.A.A --dport 25 -j DNAT --to 127.0.0.1:65000"

Petite explication de texte:

ssh mxsecondaire -R 65000:localhost:25

On se connecte en ssh de mxprimaire vers mxsecondaire, en activant le forward du port 65000 distant vers le port 25 local, et en executant la commande indiquée après. Une fois l'éxécution de celle-ci terminée, la connexion ssh est fermée.

iptables -A OUTPUT -t nat -p tcp -d A.A.A.A --dport 25 -j DNAT --to 127.0.0.1:65000 

On dit au noyau de rediriger tout le traffic sortant à destination de A.A.A.A:25 vers le port 65000

echo "Appuyer sur entrée pour quitter" && read 

On attend l'appui sur entrée pour continuer (le temps que les emails soient rapatriés)

iptables -D OUTPUT -t nat -p tcp -d A.A.A.A --dport 25 -j DNAT --to 127.0.0.1:65000

On annule ce qui a été fait auparavant

Et voilà... En espérant que ça en inspirera d'autres.

English version here

Il est loin le temps où la grande majorité des divx passaient sans problème sur ma platine de salon Kiss DP-500. Entre les nouveaux codecs, les extensions de codecs existants (QPEL, GMC, etc..) et les derniers firmwares de Kiss qui sont bourrés de défauts, il est rare qu'un film passe du premier coup. Pour y remédier, une simple ligne de commande suffit :

mencoder mauvaisdivx.avi -of avi -oac mp3lame -lameopts cbr:br=128 -ovc lavc -lavcopts vcodec=mpeg4:vhq -ffourcc DX50 -o nouveaudivx.avi

Veillez cependant à installer mencoder et les plugins adéquats.

Et voici un petit script qui prend en paramètre le nom du fichier à convertir, et crée un fichier avec le suffixe -KISS qui passe sans problème sur la platine: divxconvert.sh

La problématique est la suivante: Je veux tranquillement migrer mes virtualhosts apache d'un serveur web vers l'autre. Ces serveurs sont sur mon lan, et mon routeur forwarde le port 80 vers mon ancien serveur web. Je ne pourrais basculer ce transfert de ports vers le nouveau serveur qu'une fois tous mes virtualhosts migrés.

La solution consiste donc à demander à apache d'utiliser le nouveau serveur web comme proxy pour chaque virtualhost migré. La configuration du serveur virtuel (sur l'ancien serveur) passe donc de :

<VirtualHost *:80>
 ServerName monvirtualhost.pawelko.net
 DocumentRoot /mnt/data/monvirtualhost
</VirtualHost>

en

<VirtualHost *:80>
 ServerName monvirtualhost.pawelko.net
 <IfModule mod_proxy.c>
    ProxyRequests Off
    ProxyRemote * http://monnouveauserveur
    ProxyPass  /  http://monvirtualhost.pawelko.net/
    ProxyPassReverse / http://monvirtualhost.pawelko.net/
 </IfModule>
</VirtualHost>

Une fois tous les virtualhosts migrés, je n'aurais plus qu'à forwarder le port 80 vers mon nouveau serveur

rpcapd is a deamon that captures traffic on a host, and is able to send it to a remote network sniffer, as ethereal.

It's included with recent winpcap releases, so running it on windows is very easy : it's located in C:\program files\winpcap

It's more tricky for linux : rpcapd should compile and work under linux, but I had to remove parts of windows-related code that prevented correct compilation.

Remote linux sniffer :

• Download rpcapd.gz for linux, statically compiled for linux/i386
• Gunzip and run as root : ./rpcapd -n

Local Windows ethereal :

• Install winpcap 4.0
• Install Wireshark 0.99
• Go to "Capture Options" and specify remote host : rpcap://remotehost/remoteif
• Start sniffing

It's a always good idea to use a capture filter to exclude traffic between local and remote host.

Example with windows 192.168.50.25 remotely sniffing from linux 192.168.50.38:

Update: Do the same without rpcapd Update 2 : Compile your own version, download for other archs here

Voici comment faire en sorte qu'une souris bluetooth (en l'occurence une Logitech Laser Travel Mouse) soit reconnectée automatiquement au démarrage par ma Debian 5.

Ceci n'est qu'une adaptation des informations trouvées sur cette page

• Ouvrir un terminal en tant que root
• Installer le package bluez-utils

#apt-get install bluez-utils

• Allumer la souris
• Appuyer quelques secondes sur le bouton "Connect" de la souris, jusqu'à ce que le voyant clignote
• Lancer la recherche de souris:

#hidd --search
Searching ...
  	Connecting to device 00:07:61:EA:91:63

• La souris doit maintenant fonctionner
• Editer le fichier /etc/default/bluetooth afin qu'il contienne les lignes suivantes (remplacer évidemment l'adresse mac par celle obtenue lors de la recherche) :

############ HIDD
#
# HID daemon
HIDD_ENABLED=1
HIDD_OPTIONS="--connect 00:07:61:EA:91:63 --master --server"

• La souris doit maintenant être connectée dès qu'elle est allumée

L'objectif

Un ami m'a soumis la problématique suivante: Il souhaite louer un serveur hébergé chez OVH (donc avec une seule interface réseau) avec vmware server pour héberger plusieurs machines virtuelles, dont une devant faire office de serveur pptp. Il comptait s'appuyer sur le "NAT Networking" de vmware server pour gérer la translation d'adresses, ce qui ne pose pas de problèmes pour le port TCP/1723 (PPTP) mais ne fonctionne pas avec le protocole 47 (GRE).
La solution est simple: Linux sachant parfaitement remplir ce rôle, il suffit de lui confier et de reléguer le "vm network" sur une interface virtuelle.

Voici donc un guide pas à pas concernant vmware server 2.0 sur une Debian 5.0.2.
Les paramètres sont les suivants:

• IP "publique" de l'hôte: 192.168.3.1 (oui je sais, c'est une maquette)
• Réseau privé: 172.16.0.0/24
• IP privée de l'hôte: 172.16.0.1
• IP serveur virtuel PPTP: 172.16.0.2

Ajout de l'interface virtuelle tap1

Installer le paquet contenant le binaire tunctl

apt-get install uml-utilities

Ajouter dans /etc/network/interfaces:

auto tap1
iface tap1 inet static
       pre-up tunctl -u root -t tap1
       pre-up ifconfig tap0 up
       post-down tunctl -d tap0
       address 172.16.0.1
       netmask 255.255.255.0

puis activer tap1

ifup tap1

vérifier le tout

#ifconfig tap1
tap1      Link encap:Ethernet  HWaddr 00:ff:c0:7f:c8:83
          inet adr:172.16.0.1  Bcast:172.16.0.255  Masque:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:3805 overruns:0 carrier:0
          collisions:0 lg file transmission:500
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Configuration vmware

Nous avons donc une nouvelle interface réseau, nous allons maintenant dire à vmware server de se "bridger" sur cette interface, et non pas une autre. Pour cela, lancer la commande

vmware-config.pl

et modifier la partie concernant les bridges, soit en ajoutant un nouveau brigde, soit en modifiant le bridge actuel pour qu'il utilise tap1. Dans notre cas, la deuxième solution semble la plus appropriée, les vm n'ayant plus à être connectées directements via l'interface "publique".
Les machines virtuelles peut maintenant être connectées à ce bridge, et se voir affecter une adresse IP en 172.16.0.x avec comme passerelle 172.16.0.1

Configuration iptables

Désormais, il n'y a plus qu'à paramétrer netfilter afin qu'il route correctement les paquets pptp. Tout d'abord on active le routage:

echo 1 > /proc/sys/net/ipv4/ip_forward

Puis on natte le réseau privé:

iptables -t nat -A POSTROUTING -s 172.16.0.0/24 -j  MASQUERADE

En renvoyant le port pptp et le protocole GRE vers notre VM:

iptables -t nat -A PREROUTING -d 192.168.3.9 -p 47 -j DNAT --to-destination 172.16.0.2
iptables -t nat -A PREROUTING -d 192.168.3.9 -p tcp --dport 1723 -j DNAT --to-destination 172.16.0.2

Si ça ne fonctionne pas, penser à charger le module "Netfilter NAT helper module for PPTP":

modprobe nf_nat_pptp

Conclusion

Cette astuce peut-être appliquée dans d'autres cas, par exemple pour simplement profiter de réseaux virtuels supplémentaires avec vmware server (ou encore kvm), ces réseaux contenant l'hôte et les invités.