Things I discovered yesterday
Feb 18, 2009- Installing Firefox in an OpenVZ container can make you lose /dev/null
- OpenSolaris sleep(1) needs the network to be up
- People are injecting foreskins into their face
- Dubai is really screwed
You might think that recording and then splitting it into separate audio
files based on silences
between each track would be easy to do - sadly not.
Aside from crashing a few times and failing to recover properly, I’ve
been hit by these
enormous frustrations:
Seriously, how do people actually use this thing?
After dealing with more code that gets it wrong I was reminded of the
numerous reasons why openpty() is such a broken API.
The prototype of
this “convenience” function is this:
int openpty(int *amaster, int *aslave, char *name, struct termios *termp, struct winsize *winp);
Now, sin number one should be obvious: the interface isn’t
const-correct. You’re passing in the winp
values, but there’s no
indication of that. Worse, you’re doing the same with termp
. Why
worse? Well, think about how you use this API. Typically, you want to
create the master/slave pair of the pseudo-terminal, then change the
terminal settings of the slave. (Let’s leave the master out of this for
now - but the settings are not always symmetrical.)
But where do we get the terminal settings from? We don’t have an open
slave to base them on yet! So you find
code
doing a cfmakeraw()
on stack junk and passing that in, because the API
almost insists you do the wrong thing.
Indeed, doing it right, namely with a
tcgetattr()/cfmakeraw()/tcsetattr()
stanza, you’d expect term
to be
an out parameter, that you could then use - precisely opposite to how it
actually works, and what const correctness suggests to the user. You can
see some
other
amusing
examples
of how people worked around the API though.
I’m sure you will have spotted by now that the name
parameter is
outgoing, but has no len
. It’s therefore impossible to use without the
risk of buffer overflow.
This API is not going to score well on the Rusty
scale.
What’s worst of all about openpty()
, though, is that it’s
non-standard, so almost every piece of code out there keeps its own
private copy of this broken, pointless interface. Yay!
I was bored so played around with Review Board a little more, including installing it myself.
Things seem to have got easier to install, at least to some degree. You
can use easy_install,
though at least
for CentOS 5.2, you’ll need to install a newer version of setuptools
first. It’s also far from automated, missing
out basic dependencies like pysqlite2, patchutils, and even patch
itself. Discovering these can be, and in my case was, rather tedious
work.
After that it’s pretty easy to install, for the sqlite version anyway.
The documentation isn’t exactly clear on
what permissions changes you need to make: you need to chown all of db/
to the apache user as well for anything to work. Expect to set up a
virtual host for the installation, like I did above.
Don’t forget to enable logging in the admin interface whilst you’re messing around.
Sadly, the Mercurial support seems some way behind. For example, it doesn’t pick up changeset comments.
The diff parser (how is this not in a library by now?) can’t handle git diffs, and the failure mode is horrible (basically, silent failure, with no debugging messages). This is because hg git diffs don’t contain the revisions being diffed, so Review Board can’t pull the files from the repo. Undoubtedly a Mercurial misfeature, but it does make Review Board near useless for my purposes unfortunately.
It can handle ssh repositories (which is all opensolaris.org provides), but there’s a horrible work around needed: you have to set up a correct known_hosts file in the apache user’s home directory. Yuck.
As for the main interface, it’s generally pretty slick. I can imagine it getting cumbersome quickly with large code reviews though. Compare and contrast Review Board’s diff viewer with webrev. The latter to me at least, is much more scalable, even though the actual diff mechanism is less smart. In particular, I can review each file with webrev in a separate tab, whereas Review Board insists on one big (very big!) screen. I’d still give my right arm for a webrev-based Review Board :)
Another thing I’d like to see is more integration with the repository, so I can click on a file and it will take me off to the repo browser for looking through history.
I’ve only just read the XML-RPC spec. I knew it was simple, but I didn’t know it was stupid. Seriously, no parameter names? Only 32-bit integers? And no “NULL”? WTF?
As a final part to my entries on OpenSolaris and Xen, let's go through the steps needed to turn OpenSolaris into a dom0. Thanks to Trevor O for documenting this for 2008.05. And as before, expect this process to get much, much, easier soon!
I'm going to do the work in a separate BE, so if we mess up, we shouldn't have broken anything. So, first we create our BE:
$ pfexec beadm create -a -d xvm xvmFirst, let's install the packages. If you've updated to the development version, a simple pkg install xvm-gui will work, but let's assume you haven't:
$ pfexec beadm mount xvm /tmp/xvm-be $ pfexec pkg -R /tmp/xvm-be install SUNWvirt-manager SUNWxvm SUNWvdisk SUNWvncviewer $ pfexec beadm umount xvm
Now we need to actually reboot into Xen. Unfortunately beadm is not yet aware of how to do this, so we'll have to hack it up. We're going to run some awk over the menu.lst file which controls grub:
$ awk ' /^title/ { xvm=0; } /^title.xvm$/ { xvm=1; } /^(splashimage|foreground|background)/ { if (xvm == 1) next } /^kernel\$/ { if (xvm == 1) { print("kernel\$ /boot/\$ISADIR/xen.gz") sub("^kernel\\$", "module$") gsub("console=graphics", "console=text") gsub("i86pc", "i86xpv") $2=$2 " " $2 } } { print }' /rpool/boot/grub/menu.lst >/var/tmp/menu.lst.xvm
Let's check that the awk script (my apologies) worked properly:
$ tail /var/tmp/menu.lst.xvm ... #============ End of LIBBE entry ============= title xvm findroot (pool_rpool,0,a) bootfs rpool/ROOT/xvm kernel$ /boot/$ISADIR/xen.gz module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=text module$ /platform/i86pc/$ISADIR/boot_archive #============ End of LIBBE entry =============
Looks good. We'll move it into place, and reboot:
$ pfexec cp /rpool/boot/grub/menu.lst /rpool/boot/grub/menu.lst.saved $ pfexec mv /var/tmp/menu.lst.xvm /rpool/boot/grub/menu.lst $ pfexec reboot
This should boot you into xVM. If everything worked OK, let's enable the services:
$ svcadm enable -r xvm/virtd ; svcadm enable -r xvm/domains
At this point, you should be able to merrily go ahead and install domains!
Update: Todd Clayton pointed out the issue I've filed here: SUNWxvm needs to depend on SUNWvdisk. I've updated the instructions above with the workaround.
Update update: Rich Burridge has fixed it. Nice!
I think atheists and believers alike should agree to abide by the Advertising Standard Agency’s decision, when it comes - agreed?