Welcome to Germany, Spotify

So, finally spotify made it to Germany.

If you tried to fetch the linux client, you  probably have noticed that nothing but the .deb is currently available.
You might also have tried to use alien, and get few requires not  met although the libraries are all where they should be.

Here's a quick x86_64 version:

spotify-client-qt-0.6.6.10.gbd39032.58-2.x86_64.rpm

(a 1:1 alien conversion plus a couple of Requires: adjusted to fit the bill) originated from spotify-client-qt_0.6.6.10.gbd39032.58-1_amd64.deb.

Tested on OpenSuSE 11.4 and SLES11sp1
I don't need a 32 bit package, but if you do, let me know: that can be arranged.
Works on my box, but feel free to give it a try if you feel lazy.

Code is not mine, all the usual terms and conditions of Spotify still apply: I just repackaged it.
If anyone has a problem with this, I'd gladly take if offline.

Octave segfaulting at start?

Just in case someone still tries to run octave on a SLE 10, let me warn you that 
https://savannah.gnu.org/bugs/?30685 
is going to bite you.
A segfault awaits you behind the corner.

I've prepared a package that implements the (in)famous hack consisting of removing the gnulib:: namespace.
If you want to spare yourself some time, either fetch it from OBS or add this repo and feel free toping me in any update is needed/wanted.

by-uuid, where are you?

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 !

Openais - zombies and the revenge of the undead

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

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.

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

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.

Growing a md device

I am not quite sure why so often people are  stumbling on this, but at this point I will invest a couple of line on the topic:

I am trying to grow my md, I already did this, and it used to work. This time I get the following error:

 Elbereth:~ # mdadm /dev/md2 --grow --size=max
 mdadm: Cannot set device size for /dev/md2: Device or resource busy

Short answer: You forgot your bitmap. Or at least there is a good chance you did.

Longer one: Currently, you cannot grow a md device that holds an internal bitmap. This is not too tragic, you can still remove the bitmap, grow your device and put the bitmap back, as long as you are not going to have a major failure during the process, you'll be just fine.
What if you happen to have the up mentioned failure? Well, do not focus on the bitmap too much, with a bad failure during a grow operation - bitmap or not - you are going to have quite a bit of trouble anyway.

Practically speaking:

mdadm --grow --bitmap=none /dev/mdX

to remove it and then grow you array as usual.
Once done, you put it back with a:

mdadm --grow --bitmap=internal /dev/mdX

Have fun!