Posted in the hopes it saves someone some time.

The disks were fine, the rest of the hardware had failed.

Prior to me being involved in this, my friend had installed Ubuntu on an older machine and had installed both drives.

Not having played with RAID for quite some time, I had to acquire some knowledge first – google to the rescue!

In the process I used the wrong option to mdadm (–create instead of –assemble), so I messed up the RAID descriptor on one of the disks. Fortunately, the second disk was fine.

Here is what I ended up doing:

• install mdadm, a utility to configure RAID devices.

• install lvm2, a utility to configure LVM (Logical Volume Manager).

• Run:

mdadm –assemble /dev/md9 /dev/sdc1 –run

(this adds one of the partitions on the existing drives, /dev/sdc1, into a RAID device /dev/md9 running in degraded mode, i.e. with not enough disks – that’s what –run does)

vgchange -a y

(this scans all drives, including the newly created /dev/md9, for logical volumes)

It should print something about a new device with a rather cryptic name, I think something like /dev/vg1_md9/lv1. lvdisplay will show the available volumes.

This new device has a filesystem that can be mounted:

mkdir /tmp/olddrive
mount /dev/vg1_md9/lv1 /tmp/olddrive -o ro

After this, the directory /tmp/olddrive is associated with the contents of the filesystem.

There may be better ways to achieve the same thing, but this is what worked.

If you are not familiar with keyutils, it is a library that allows you to securely store sensitive information, directly inside the Linux kernel. You have a reasonable guarantee that the information cannot be retrieved from the memory or swap.

keyutils comes with a binary, keyctl(1), that gives you access to the kernel’s key management facilities. The man page describes the types of available keyrings. The ones the most interesting to the use case I had in mind were the per-thread, per-process and per-session keyrings.

The need for python bindings came when we realized that our release process requires typing the passphrase for signing packages way too many times, so there was a real need for a key agent of some sort. Searching for gpg-agent protocol specifications (or seahorse) returned some information, but nothing I could readily use (I may not have found the proper examples for speaking assuan; the end result was that I could not get anywhere in this direction).

Future versions of Conary will have the ability to read passphrases from the session keyring, if python-keyutils is installed. You can get python-keyutils from either contrib.rpath.org@rpl:2 or foresight.rpath.org@fl:2-devel (depending on whether you need the python 2.4 or python 2.6 version).

Keep in mind that I only implemented the bare minimum I needed for being able to set and get key information. There are other functions the library provides, that could be useful to have. If you find the need for one, let me know; as usual, patches will be cheerfully accepted.

The code is hosted on bitbucket and can be checked out with Mercurial.

Cimbiote did not go anywhere in the past 2 years and a half, so I dusted it off and started to play with it. As it turns out, major pieces were missing: the ability to create references, support for associations etc.

When trying to add reference support, I found out from the sblim mailing list that there is still hope in the world. Today I finished packaging cmpi-bindings=contrib.rpath.org@rpl:2 and wrote a simple plugin that does not do much, but was enough to prove far superior to cimbiote.

[1] You, in the back row, stop chuckling. We all know that standards are wonderful things, as Tigger would say.

Given a list of words spread on separate lines, sort the words.

One can try to do :sort or !sort on a range, but that will sort the lines, not the words inside the lines.

Easiest I found so far (but requires visual formatting which is only available in vim):

• visual select of the lines you want to sort
• !!fmt -1
• visual select of the lines you want to sort
• :sort
• gw}

Clear as mud

Explanation:

! will run the selection through an external program, in this case fmt (which is a Unix command to format a list of lines). -1 says to format with a text width of 1 character (which effectively breaks the words at the space)

:sort will sort the selected lines

gw} will format from where the cursor is to the end of the paragraph (re-joining the lines).

Metacity will let  you configure keyboard shortcuts for generating events it knows about (sound events, window events etc). For that, all you have to do is go to System->Preference->Keyboard Shortcuts.

But what if you wanted to run  an arbitrary command? In my case, if I suspend my laptop while the display is set to use the external monitor, and I resume trying to use the laptop’s LCD screen, I would have to somehow invoke xrandr to get the display back. Sounds like a keyboard shortcut would solve the problem, since I could type it blindly, without anything on the display.

This is the solution I found:

•  Run gconf-editor
• Go to apps->metacity->keyboard_commands
• edit one of the command_N keys to add the command you want to be run (in my case xrandr)
• go to global_keybindings, edit the run_command_N key and add the keyboard shortcut, like <Ctrl><Alt><Shift>R

No need to restart anything.

You have a program that:

• looks for an empty port in the high numbers
• forks
• in the child
  • it does some computation first (this could take some time)
  • it binds and listens to the port determined in the first step
  • starts processing requests of some sort (like HTTP requests, but any TCP would do)
• in the parent
  • it has to wait for the child to start serving requests, so in a loop it will start communicating with the child. If it gets an ECONNREFUSED, wait some time (a tenth or a hundredth of a second) and try again
  • do a bunch of work here

This all looks reasonable so far. Except that, every now and then, (sometimes more frequently, sometimes very rarely) I was seeing the parent process stuck. A quick /usr/sbin/lsof was showing the most disturbing thing: a socket connected to itself!

27945 misa 10r IPv4 73626638 TCP localhost.localdomain:51308->localhost.localdomain:51308 (ESTABLISHED)

All you can do when you see this is scratch your head and wonder what in the world is going on.

After much running around and lots of tracing of the code, it finally occurred to me what happens.

For the explanation that follows, I will call it a local port the port number used by the socket locally (as returned by getsockname(2)).

Every time you have a socket and you try to connect(2) it (to a remote, known port), the socket library will pick an unused high-numbered port for its end of the connection (as the local port). If the attempt to connect(2) the socket fails and you try again, it will temporarily bind to another port (the’re usually consecutive, until they wrap around and start over).

If you try long enough without succeeding (and it is key that the server and client are both on the same machine – I used localhost for both), connect(2) will pick the port you initially assigned to the server as the local port, and will connect to itself!

One possible solution is to pick an unused port and bind to it before connecting. Then connect(2) will no longer bind to random other ports.

Turns out more modern versions of resize2fs already know how to do that. Not the ones from e2fsprogs=conary.rpath.com@rpl:1, but I was able to install e2fsprogs=conary.rpath.com@rpl:devel into a temporary root and run the new resize2fs from there. Yay.

Now in a Foresight repository near you (foresight.rpath.org@fl:1-contrib).

It’s pretty powerful in that it lets you use the boilerplate builders or you can build your own builders (and nodes!) too. It also allows you to write custom “freshness checks”. make usually verifies if a node is out of date by comparing the timestamps for the source and target nodes. This can get you in trouble when using CVS, for instance, because clocks are not synchronized. It’s also not very useful when what you build doesn’t live on the filesystem.

I will post some examples  shortly. I am currently creating nodes for Mercurial checkouts and they work pretty well. CVC (Conary) nodes will follow shortly.

And yes,  it’s written in Python…