pawelko.net

I started playing with kvm 28-4~bpo.1 on my etch. I installed Fedora Core 9, but during boot I had a lot of messages like
ata2.00: status: { DRDY ERR }
and
HSM violation

So I backported kvm 72+dfsg-4 from lenny and got rid of this error.
Download : /xmedia/divers/kvm_72+dfsg-4_amd64.deb

Here is how I configured my Linksys WRT54G routeur/AP to connect to my office's Zywall 70

              --------                  --------
      Home --| WRT54G |--- Internet ---| Zywall |--- Office
              --------                  --------                
192.168.3.X         W.W.W.W          Z.Z.Z.Z          192.168.2.x

Linksys WRT54G

Backup your access point, go to http://openwrt.org, read carefully the wiki, and install the latest OpenWRT release. WhiteRussian RC6 worked for me.
I upgraded from an old Alchemy release, and all my settings were kept.
Install openswan

#ipkg update
#ipkg install openswan

Create /etc/ipsec.d/private/zywall

conn zywall
       right=%defaultroute
       rightsubnet=192.168.3.0/24
       rightid=@someid
       left=Z.Z.Z.Z
       leftsubnet=192.168.2.0/24
       leftid=@someid
       authby=secret
       pfs=no
       ike=aes128-sha1-modp1024
       esp=3des-md5-96
       keylife=9600s
       keyingtries=0
       auto=add
       dpddelay=30

Modify /etc/ipsec.conf to include your new config

# Add connections here
include /etc/ipsec.d/private/zywall

Add you preshared key in /etc/ipsec.secrets

@someid @someid: PSK "mysecret"

Zywall 70

Open "VPN Rule (IKE)" tab and add a new gateway policy

• Remote Gateway Address : W.W.W.W
• Pre-Shared Key : mysecret
• Negotiation Mode : Main
• Encryption Algorithm: AES
• Authentication Algorithm : SHA1
• SA Life Time (Seconds): 9600
• Key Group : DH2

Add a new network policy

• Active: Yes
• Local Network
  • Address Type: Subnet address
  • Starting IP Address: 192.168.2.0
  • Subnet Mask: 255.255.255.0
• Remote Network
  • Address Type: Subnet address
  • Starting IP Address: 192.168.3.0
  • Subnet Mask: 255.255.255.0
• Encapsulation Mode: Tunnel
• Active Protocol: ESP
• Encryption Algorithm : 3DES
• Authentication Algorithm: MD5
• SA Life Time (Seconds): 28800
• Prefect Forward Secrecy: None
• Enable Replay Detection: Yes

It should now work. Try to connect the VPN from the WRT54G:

# ipsec auto --up zywall
104 "zywall" #26: STATE_MAIN_I1: initiate
003 "zywall" #26: ignoring unknown Vendor ID payload [afcad71368a1f1c96b8696fc7757]
003 "zywall" #26: ignoring unknown Vendor ID payload [625027749d5ab97f5616c1602765cf480a3b7d0b]
106 "zywall" #26: STATE_MAIN_I2: sent MI2, expecting MR2
108 "zywall" #26: STATE_MAIN_I3: sent MI3, expecting MR3
004 "zywall" #26: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp1024}
117 "zywall" #27: STATE_QUICK_I1: initiate
004 "zywall" #27: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x595ef372 <0xb540297d xfrm=3DES_0-HMAC_MD5 NATD=none DPD=none}

Hiding the personnal network

It works, but my colleagues can now browse my home network. I want to "masquerade" the 192.168.3 subnet, so all connections seems to come from 192.168.203.1 :

                  ---------                  --------
      Home -- (NAT) WRT54G |--- Internet ---| Zywall |--- Office
                  ---------                  --------                
192.168.3.x  192.168.203.x  W.W.W.W   Z.Z.Z.Z          192.168.2.x

Edit /etc/firewall.user :

iptables -t nat -A postrouting_rule -d 192.168.2.0/255.255.255.0 -j SNAT --to 192.168.203.1
iptables -A forwarding_rule -d 192.168.2.0/24 -j ACCEPT

Run /etc/firewall.user to apply theses rules Modify the ipsec rules to use 192.168.203.x instead of 192.168.3.x

Notes

• The local and remote ID must be the same
• 3DES/MD5 is not the most secure cypher for phase 2, but other cyphers does not seem to work
• See openwrt wiki for encryption and speed
• This should work with any zywall model and with ipsec-capable Prestige models (652, 662). Some buggy firmwares (Zywall 10) use local and/or remote id instead of "secure gateway address".

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

Je souhaite conserver plein de copies de sauvegarde de machines virtuelles tournant sur mon hyperviseur étant un kvm/libvirt/archipel sur une squeeze. Il y a un candidat idéal pour cela: zfs, qui pour des raisons de licence n'a pas d'implémentation native dans linux. Pour commencer, j'ai fait quelques tests avec zfs-fuse (0.6.9-1), sans tuning particulier. Ca marche correctement, mais pas très vite (moins de 10 Mo/s). J'ai ensuite utilisé le zfs natif. Les performances brutes étaient bien meilleures mais ça tirait énormément sur la RAM et tout finissait par devenir très lent, et la sauvegarde d'une des VM ne se terminait jamais. En essayant de tuner la taille du ARC cache, je n'ai réussi qu'à obtenir un plantage complet du noyau (le dmesg parlait de lui même).

Je suis donc retourné à zfs-fuse en attendant de trouver mieux. Maintenant que j'ai une rotation des VM sur une semaine, je peux avoir une idée précise des ressources requises par la déduplication:

#  zpool status -D zpool
 pool: zpool
state: ONLINE
scrub: none requested
config:

       NAME                               STATE     READ WRITE CKSUM
       zpool                              ONLINE       0     0     0
         disk/by-id/dm-name-archipel-zfs  ONLINE       0     0     0

errors: No known data errors

DDT entries 282985, size 354 on disk, 222 in core

bucket              allocated                       referenced
      __
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
    1    49,6K   6,20G   2,25G   2,25G    49,6K   6,20G   2,25G   2,25G
    2    11,1K   1,39G    583M    583M    27,6K   3,45G   1,42G   1,42G
    4     171K   21,4G   12,6G   12,6G    1,13M    145G   85,5G   85,5G
    8    43,7K   5,46G   3,11G   3,11G     358K   44,7G   25,4G   25,4G
   16      741   92,6M   59,3M   59,3M    13,5K   1,69G   1,04G   1,04G
   32      129   16,1M   8,19M   8,19M    4,67K    598M    298M    298M
   64        3    384K   67,5K   67,5K      330   41,2M   7,78M   7,78M
  128        1    128K   4,50K   4,50K      133   16,6M    598K    598K
   1K        1    128K   4,50K   4,50K    1,27K    162M   5,71M   5,71M
   2K        1    128K      7K      7K    3,98K    509M   27,8M   27,8M
  16K        1    128K   7,50K   7,50K    23,7K   2,96G    178M    178M
Total     276K   34,5G   18,6G   18,6G    1,60M    205G    116G    116G

Je vois ici que j'ai 282985 entrées pour la déduplication, chaque entrée occupant 222 octets en RAM. J'en déduis donc que mon cache pour la dédup est d'environ 60 Mo (ce qui est peu !). Par défaut ZFS alloue un quart de la taille du cache ARC pour le cache des metadata, donc fait partie la table DDT. Le cache ARC doit donc être au moins de 240 Mo. Par défaut, la valeur sur ma Debian était de 100 Mo. Cela apparait au démarrage de fuse:

# grep -i zfs /var/log/syslog
Nov 28 21:12:39 archipel zfs-fuse: ARC caching: maximum ARC size: 100 MiB
Nov 28 21:12:39 archipel zfs-fuse: ARC setup: min ARC size set to 16777216 bytes
Nov 28 21:12:39 archipel zfs-fuse: ARC setup: max ARC size set to 104857600 bytes

J'ai donc modifié la ligne "max-arc-size = 240" dans le fichier /etc/zfs/zfsrc et relancé zfs-fuse

#invoke-rc.d zfs-fuse restart

A titre d'exemple, le temps de sauvegarde de ma VM zimbra est passé de 16 minutes à 6 minutes ! En réglant le cache à 500 Mo, je descends à 3 minutes pour la même sauvegarde. Ce qui correspond à peu près aux temps que j'obtenais avec les modules zfs natifs, mais qui eux provoquaient de nombreux plantages, alors qu'avec zfs-fuse j'ai une solution parfaitement stable. Un réglage du cache à 1 Go n'a pas donné de meilleurs résultats.

Conclusion : Voici la formule appliquée dans mon cas avec zfs-fuse : max-arc-size = Taille du cache DDT * 8