cd ~

/home/nico

L’autre jour je me suis aperçu que l’allocation IP sur un de mes /24 tenait plus du gruyère que du reste. Du coup j’ai codé vite fait un petit script (en ruby) pour sortir un PNG du /24.

Il suffit de l’invoquer par :

ruby allocation_ip.rb 192.168.1

pour scanner la plage 192.168.1.0/24.

Feel free to hack.

Le fichier.

Aujourd’hui, j’ai tout pété une application maison. Classe non ? Tout ça en upgradant de version de squid (celle de etch vers celle de lenny).

Le topo :

  • Application maison en .net (je me fouette 5 fois par jour pour expier)
  • Application qui fait appel à un webservice
  • En passant par un proxy (squid)
  • *boum*

Pourquoi boum ? parce que squid, par défaut ne gère pas le HTTP 1.1, et que les applications écrites avec le framework .net elles, elles parlent en 1.1. Du coup, lorsque le header “Expect: 100-continue” pointe son nez, squid renvoie un HTTP 417 et au revoir.

Mais j’entends déjà dire “Squid il supporte le HTTP 1.1, takalireladoc”. On parle de ça ?

#          http11       Enables HTTP/1.1 support to clients. The HTTP/1.1
#                       support is still incomplete with an internal HTTP/1.0
#                       hop, but should work with most clients. The main
#                       HTTP/1.1 features missing due to this is forwarding
#                       of requests using chunked transfer encoding (results
#                       in 411) and forwarding of 1xx responses (silently
#                       dropped)

C’est pas exactement ce que j’appelle “supporter”, surtout quand on jette des trucs en silence… Du coup j’ai collé la directive “ignore_expect_100″ à “on”. C’est pas propre, je suis d’accord mais ça ne touche pas toutes les directives 1XX.

Pour toi google : http 417 squid expect error 1.1 1.0

You are in a mall when zombies attack. You have:
1. One weapon
2. One song blasting on the speakers
3. One famous person to fight along side you.

1. A good sword, will do easily, no need for ammunition
2. “Green Hornet” from Kill Bill OST
3. Chuck Norris, I will not even have to use my swor

Apparemment je ne suis pas le seul à avoir remarqué que Google était en train de “streetmapper” la région parisienne.

Par contre moi j’ai fait une photo (avec le portable, désolé de la qualité pourrie). Elle a été prise ici. On ne voit pas le logo Google Streetmap sur la porte de la voiture, dommage.

This post follows this one and is a translation of what I wrote here.

It does not exist (yet) MIBs for ZFS, and particulary to check failed disks. This is quite annoying. Hopefully, Solaris has (since Solaris 10) Fault Manager.

Quick FMd

fmd in 3 commands :

  • fmadm faulty : lists the problems (and their UUID)
  • fmadm repair [UUID] : marks the problem as repaired
  • fmdump : dump problems list, including repaired ones

Installing SNMPd

pkgadd -d [repsdespackages] SUNWsmcmd SUNWsmmgr SUNWsmagt

Run snmpconf (with the -i switch) to setup easily the behaviour of the daemon.

and of course :

svcadm enable sma

SNMPd & FMd
Add into /etc/sma/snmp/snmpd.conf :

dlmod sunFM /usr/lib/fm/amd64/libfmd_snmp.so.1

to activate the snmp module for fmd

and then restart sma :

svcadm restart sma

Please note that the path is arch dependant (x86 64 bits here)

Crash test it

# prepare a file based zfs pool
mkdir crash
cd crash
# Files must be > 64M
dd if=/dev/zero of=pool1 bs=1024k count=64
dd if=/dev/zero of=pool2 bs=1024k count=64
dd if=/dev/zero of=pool3 bs=1024k count=64
# create the pool
sudo zpool create crashtest raidz /home/nico/crash/pool1 /home/nico/crash/pool2 /home/nico/crash/pool3
# break it
rm pool3
# scrub it (to be sure that the system sees the failure)
sudo zpool scrub crashtest
# check that fmd does its job
sudo fmadm faulty

Now, let’s see what informations we get with SNMP :

snmptable -v2c -c public 127.0.0.1 SUN-FM-MIB::sunFmProblemTable

| sunFmProblemUUID | sunFmProblemCode | sunFmProblemURL | sunFmProblemDiagEngine | sunFmProblemDiagTime | SunFmProblemSuspectCount |
| “96397f16-1cea-463b-e9db-de989cd42e81″ | ? | ? | ? | ? | ? |

The module exports 4 tables : sunFmProblemTable, sunFmFaultEventTable, sunFmModuleTable, sunFmResourceTable

the easiest way is to use snmpwalk :
<code>
snmpwalk -c public -v 2c 127.0.0.1 SUN-FM-MIB::sunFmProblemTable
SUN-FM-MIB::sunFmProblemUUID.”96397f16-1cea-463b-e9db-de989cd42e81″ = STRING: “96397f16-1cea-463b-e9db-de989cd42e81″
SUN-FM-MIB::sunFmProblemCode.”96397f16-1cea-463b-e9db-de989cd42e81″ = STRING: ZFS-8000-D3
SUN-FM-MIB::sunFmProblemURL.”96397f16-1cea-463b-e9db-de989cd42e81″ = STRING: http://sun.com/msg/ZFS-8000-D3
SUN-FM-MIB::sunFmProblemDiagEngine.”96397f16-1cea-463b-e9db-de989cd42e81″ = STRING: fmd:///module/zfs-diagnosis
SUN-FM-MIB::sunFmProblemDiagTime.”96397f16-1cea-463b-e9db-de989cd42e81″ = STRING: 2008-2-21,12:31:2.0,+1:0
SUN-FM-MIB::sunFmProblemSuspectCount.”96397f16-1cea-463b-e9db-de989cd42e81″ = Gauge32: 1
</code>

Nagios integration

See this post.

See also

All this stuff is based upon this excellent post.

Récemment au taf je me suis lancé dans la conception d’une architecture MySQL solide. Des applications internes critiques se basent dessus et suite à un soucis j’ai réalisé le manque de fiabilité de l’existant. Après quelques recherches j’ai donc commencé à mettre en place un cluster MySQL.

Cette solution présente pas mal de choses attrayantes, notamment son système de haute dispo “intégrée” qui il faut le dire, fonctionne très bien : j’ai coupé le courant d’un des noeuds comme un sauvage (IPMI <3) et la bascule s’est faite instantanément, sans perte de données. L’administration via la console de management est assez aisée (y’a pas de clicka mais OSEF), bref jusque là : tout va bien.

Ca se corse quand on commence à faire des vraies opérations sur les bases, style :

ALTER TABLE bla ENGINE=ndbcluster

… quand la table fait 1.5Go le moteur souffre, la RAM aussi. Et oui, MySQL Cluster fonctionne en RAM (entièrement !), et ça aussi ça fait un peu peur. Il y a des écritures régulières, mais c’est pas tip top, sauf pour ce qui est des perfs, qui déboitent quand même bien leur maman ours en guenilles. La liste complète des limitations est bien sur disponible, et perso je trouve que c’est trop contraignant pour être vraiment utilisable en environnement de production.

Néanmoins, je ne jette pas la pierre et je garde un oeil sur cette solution qui si elle continue sur la bonne voie sera sûrement utilisable chez moi d’ici 3/4 versions.

OpenSolaris has a nice feature : the fault manager. I wrote a little plugin for Nagios to be able to monitor events that are generated through this facility via SNMP. You will find the (little) howto here.

I would also like to thank all the #opensolaris & #opensolaris-fr crew on freenode for the support and the time they gave to me.

Download : SNMP & fmd

Nan parce que Nagios il aime pas quand les gens sont trop exigeants :

$ /usr/lib/nagios/plugins/check_ping -H 127.0.0.1 -w 25,0% -c 50,0%
PING CRITICAL - Paquets perdus = 0%, RTA = 0.02 ms

Comprendre : 0% de perte sur un ping, c’est critique, cela dit, 1% c’est acceptable :

$ /usr/lib/nagios/plugins/check_ping -H 127.0.0.1 -w 25,1% -c 50,1%
PING OK - Paquets perdus = 0%, RTA = 0.02 ms

Va comprendre Charles !

J’ai mis à jour le fichier concernant le schéma LDAP pour la config lighttpd, vu que j’ai obtenu un pen number auprès de l’IANA.

Si vous avez comme moi la malchance d’avoir un cyrus comme serveur mail, 2 tips pratiques :

Seendb cassée ? faites

> monuser.mondomaine.tld.seen

et à la prochaine connexion elle sera recréée (ne PAS la supprimer)

Compte cassé ? faites

cyrreconstruct -f -u user/monuser.mondomaine.tld

en tant que user cyrus.