Dienstag, 6. Dezember 2011

by-uuid, where are you?

0 Kommentare
Are you missing entries in /dev/disk/by-uuid ?

 Run "uuidgen" this will spawn a uuid like:
2edddab5-d555-414f-9db6-4c80c11897f5

After that, run tune2fs to assign the generated uuid to the filesystem on the device:
elbereth:~ # tune2fs /dev/yourdevice -U
2edddab5-d555-414f-9db6-4c80c11897f5

You're ready to go, don't forget to retrigger you udev rules with

udevadm trigger
Enjoy your new persistent name !



Dienstag, 4. Oktober 2011

Openais - zombies and the revenge of the undead

0 Kommentare
Are you trying to start your cluster and all you get out of it is a set of duplicate and defunct processes, similar to the following?

4129 ?        Ssl    0:01 /usr/sbin/corosync
4134 ?        S      0:00  \_ /usr/lib64/heartbeat/stonithd
4135 ?        S      0:00  \_ /usr/lib64/heartbeat/cib
4136 ?        Z      0:00  \_ [lrmd] <defunct>
4137 ?        S      0:00  \_ /usr/lib64/heartbeat/attrd
4138 ?        Z      0:00  \_ [pengine] <defunct>
4139 ?        Z      0:00  \_ [crmd] <defunct>
4141 ?        S      0:00  \_ /usr/lib64/heartbeat/stonithd
4142 ?        S      0:00  \_ /usr/lib64/heartbeat/cib
4143 ?        S      0:00  \_ /usr/lib64/heartbeat/lrmd
4144 ?        S      0:00  \_ /usr/lib64/heartbeat/attrd
4145 ?        S      0:00  \_ /usr/lib64/heartbeat/pengine
4652 ?        S      0:00  \_ /usr/lib64/heartbeat/crmd


Check /etc/corosync/service.d/
If in there you see a pcmk file *and* Pacemaker is specified as service in your /etc/corosync/corosync.conf  you have your answer.
Just leave your .config file as is and get rid of the pcmk file instead.
Reboot your node, and you' re ready to go.

Autoyast - yast2-samba-client: bits and pieces

0 Kommentare
Your autoinstallation fails to join your AD domain unless you run a net join as post installation script?
You can specify  the join credentials within the samba-client section of your profile like this  ( this goes after samba's </global> )
<join>         
     <password>whatever</password>
     <user>Administrator</user> 
</join>  

Also, are you setting your <realm> and the result in your smb.conf is an empty "realm=" entry?
Try setting it twice, in both <samba-client> and <samba-server> sections, that should do the trick.

Freitag, 22. Juli 2011

Missing the obvious, udp fragments and a short moment of frustration.

0 Kommentare
Do you know *that* final level boss, the one that seems impossible to beat even after hours and hours of attempts and uncountable retries? Yes, the very same that after a night spent lost in your own frustration and a day that kept you busy with some other business falls - piece of cake - at the first attempt?

Sometimes can be hard to keep track of the big picture when you are busy looking for details. All the small bits are in the end saturating your field of vision leaving you cluttered and even more confused than before.

This is exactly what I've been experiencing in the last 2 days, missing the obvious that was already in front of my eyes. This post is not meant as a technical explanation - the "solution" is way to obvious - but as a personal reminder, against the often unproductive habit to get lost in details.

Let's say that someone, for whatever reason, wants to DROP all udp fragments, and this using iptables.

No problem. Easy to write a rule for that, as long as you remember one detail: fragments are reassembled before entering the INPUT chain, and therefore would be best to do it in PREROUTING.
The rule by itself doesn't leave much space for mistakes:

iptables -t raw -A PREROUTING -p udp -j DROP

would do, and just to make sure, let's add some logging to make sure that all works as it should:

iptables -t raw -I PREROUTING -f -p udp -j LOG --log-prefix match_fragment_prerouting

A quick setup to test the whole, using elbereth as sender and mjolnir as receiver:

mjolnir:/# netcat -vv -l -u -p xxxx -s xxx.xxx.xxx.xxx.

elbereth:/# hping3 xxx.xxx.xxx.xxx. -V -2 -f -x --file /tmp/lotsofdata -d 2000 -p xxxx

And guess what? All my 2000 bytes are happily displayed and no packet matched my rule.

I will spare you all the inconclusive tests I did, and all the traces I've taken, while too blind to see what the problem really was, but please believe me, it was a lot. From doubts about the correct positioning of the rule, to datacenter's pixies and poltergeists.

This morning, I decided to reset the test environment completely and take two new traces, as clean as possible, and start again with it.
And there I finally saw captain obvious appearing from far away:

On the trace taken on mjolnir's side, I could see all the udp fragments *and * the reassembled packet.

And the captain gets closer.

A quick addition to my iptables' logging, to add an extra entry that would log not only the fragments, but any udp packet.

Run the test again, and my fear was confirmed, the rules are working, but no fragment ever reaches iptables, only reassembled packets.
Only reassembled packets I said?

And here captain obvious appeared next to me, enjoying the scene of me slapping my own head before, after and while typing

lsmod|grep conntrack

A pat on my shoulder, and he was away again, looking for someone else that missed the obvious, at least for a while.