The usual Typo update report

You probably got used to read about me updating Typo at this point — the last update I wrote about was almost an year ago when I updated to Typo 6, using Rails 3 instead of 2. Then you probably remember my rant about what I would like of my blog …

Well, yesterday I was finally able to get rid of the last Rails 2.3 application that was running on my server, as a nuisance of a customer’s contract finally expired, and since I was finally able to get to update Typo without having to worry about the Ruby 1.8 compatibility that was dropped upstream. Indeed since the other two Ruby applications running on this server are Harvester for Planet Multimedia and a custom application I wrote for a customer, the first not using Rails at all, and the second written to work on both 1.8 and 1.9 alike, I was able to move from having three separate Rails slot installed (2.3, 3.0 and 3.1), to having only the latest 3.2, which means that security issues are no longer a problem for the short term either.

The new Typo version solves some of the smaller issues I’ve got with it before — starting from the way it uses Rails (now no longer requiring a single micro-version, but accepting any version after 3.2.11), and the correct dependency on the new addressable. At the same time it does not solve some of the most long-standing issues, as it insists on using the obsolete coderay 0.9 instead of the new 1.0 series.

So let’s go in order: the new version of Typo brings in another bunch of gems — which means I have to package a few more. One of them is fog which includes a long list of dependencies, most of which from the same author, and reminds me of how bad the dependencies issue is with Ruby packages. Luckily for me, even though the dependency is declared mandatory, a quick hacking around got rid of it just fine — okay hacking might be too much, it really is just a matter of removing it from the Gemfile and then removing the require statement for it, done.

For the moment I used the gem command to install the required packages — some of them are actually available on Hans’s overlay and I’ll be reviewing them soon (I was supposed to do that tonight, but my job got in the way) to add them to main tree. A few more requires me to write them from scratch so I’ll spend a few days on that soon. I have other things in my TODO pipeline but I’ll try to cover as many bases as I can.

While I’m not sure if this update finally solves the issue of posts being randomly marked as password-protected, at least this version solves the header in the content admin view, which means that I can finally see what drafts I have pending — and the default view also changed to show me the available drafts to finish, which is great for my workflow. I haven’t looked yet if the planning for future-published posts work, but I’ll wait for that.

My idea of forking Typo is still on, even though it might be more like a set of changes over it instead of being a full-on fork.. we’ll see.

Updating HP iLO 2.x

As I wrote yesterday I’ve been doing system and network administration work here in LA as well, and I’ve set up Munin and Icinga to warn me when something required maintenance.

Now some of the first probes that Munin forwarded to Icinga we knew already about (in another post I wrote of how the CMOS battery ran out on two of the servers), but one was something that bothered me before as well: one of the boxes only has one CPU on board and it reports a value of 0 instead of N/A.

So I decided to look into updating the firmware of the DL140 G3 and see if it would help us at all; the original firmware on IPMI device was 2.10 while the latest one available is 2.21. Neither support firmware update via HTML. The firmware download, even when selecting the RedHat Enterprise Linux option is a Windows EXE file (not an auto-extract archive, which you can extract from Linux, but their usual full-fledged setup software to extract in C:SWSetup). When you extract it, you’re presented with instructions on how to build an USB key which you can then use to update the firmware via FreeDOS…

You can guess I wasn’t amused.

After searching around a bit more I found out that there is a way to update this over the network. It’s described in HP’s advanced iLO usage guide, and seems to work fine, but it also requires another step to be taken in Windows (or FreeDOS): you have to use the ROMPAQ.EXE utility to decompress the compressed firmware image.

*I wonder, why does HP provide you with two copies of the compressed firmware image, for a grand total of 3MB, instead of only one of the uncompressed one (2MB)? I suppose the origin of the compressed image is to be found in the 1.44MB floppy disk size limitation, but nowadays you don’t use floppies… oh well.*

After you have the uncompressed image, you have to set up a TFTP server.. which luckily I already had laying around from when I updated the firmware of the APC powerstrips discussed in one of the posts linked above. So I just added the IPMI firmware image, and moved on to the next step.

The next step consists of connecting via telnet to the box and issue two commands: cd map1/firmware1 followed by load -source //$serverip/$filename -oemhpfiletype csr … the file is downloaded via TFTP and the BMC rebooted. Afterwards you have to clear out the SDR cache of FreeIPMI as ipmi-sensors wouldn’t work otherwise.

This did fix the critical notification I was receiving .. to a point. First of all, the fan speed has still bogus thresholds (and I’m not sure if it’s a bug in FreeIPMI or one in the firmware at this point) as it reports the upper limits instead of the lower ones). Second of all the way it fixed the misreported CPU thermal sensor is by … not reporting any temperature off either thermal sensor! Now both CPU temperatures are gone and only ambient temperature is available. D’oh!

Another funky issue is that I’m still fighting to get Munin to tell Icinga that “everything’s okay” — the way Munin contacts send_nsca is connected to the limits so if there are no limits that are present, it seems like it simply doesn’t report anything at all. This is something else I have to fix this week.

Now back to doing the firmware updates on the remaining boxes…

Update: turns out HP updates are worse than the original firmware in some ways. Not only the CPU Thermal Diodes are no longer represented, but the voltages lost their thresholds altogether! The end result of which is that now it says that it’s all a-ok! Even if the 3V battery is reported at 0.04V!. Which basically means that I have to set my own limits on things, but at least it should work as intended afterwards.

Oh and the DL160 G6? First of all, this time the firmware update has a web interface… to tell it which file to request from which TFTP server. Too bad that all the firmware updates that I can run on my systems require the bootcode to be updated as well, which means we’ll have to schedule some maintenance time when I come back from VDDs.

Stable users’ libpng update

Seems like my previous post didn’t make enough of a fuss to get other developers to work on feasible solutions to avoid the problem to hit stable users… and now we’re back to square one for stable users.

Since I also stumbled across two problems today while updating my stable chroots and containers, that represent the local install of remote vservers, and a couple of testing environments for my work, I guess it’s worth writing of a couple of tricks you might want to know before proceeding.

Supposedly, you should be able to properly complete the update without running the libpng-1.4.x-update.sh hack! (and this is important because that hack will create a number of problems on the longer run, so please try to avoid it!). If you have been using --as-needed for a decent amount of time, the update should come almost painless. Almost.

I maintained that revdep-rebuild should be enough to take care of the update for you, but it comes with a few tricks here that make it slightly more complex. First of all, the libpng-1.4 package will try to “preserve” the old library by copying it inside itself, avoiding dynamic link breakage. This supposedly makes for a better user experience as you won’t hit packages that fail to start up for missing libraries, but has two effects; one is that you may be running a program with both libpng objects around, which is not safe; the second is that revdep-rebuild will not pick up the broken binaries at all, this way.

Additionally, there is a slot of the package that will bring in only the library itself, so that binary-only packages linked to the old libpng can be used still; if you have packages such as Opera installed, you might have this package brought in on your system; this will further complicate matters because it will then collide with libpng-1.4… bad thing.

These are my suggested instructions:

  • get a console login, make sure that GNOME, KDE, any other graphical interface is not running; this is particularly important because you might otherwise experience applications that crash mid-runtime;
  • emerge -C =libpng-1.2* make sure that you don’t have the old library around; this works for both the old complete package and for the new library-only binary compatibility package;
  • rm -f /usr/lib/libpng12.so* (replace lib/ with lib64/ on x86-64 hosts; this way you won’t have the old libraries around at all; actually this should be a no-op since you removed it, but this way you ensure you don’t have them around if you had already updated;
  • emerge -1 =libpng-1.4* installs libpng-1.4 without preserving the libraries above; if you had already updated, please do this anyway, this way you’ll make sure it registers the lack of the preserved libraries;
  • revdep-rebuild -- --keep-going it shouldn’t stop anywhere now, but since it might, it’s still a good idea to let it build as much as it can.

Make also sure you follow my suggestion of running lafilefixer incrementally after every merge, that way you won’t risk too much breakage when the .la files gets dropped (which I hope we’ll start doing systematically soon), by adding this snipped to your /etc/portage/bashrc:

post_src_install() {
    lafilefixer "${D}"
}

Important, if you’re using binary packages! Make sure to re-build =libpng-1.4* after you deleted the file, if you had updated it before; otherwise the package will have preserved the files, and will pack it up in the tbz2 file, reinstalling it every time you merged the binary.

This post brought to you by the guy who has been working the past four years to make sure that this problem is reduced to manageable size, and that has been attacked, defamed, insulted and so on so forth for expecting other developers to spend more time testing their packages. If you find this useful, you might want to consider thanking him somehow…

Upgrading Typo

It’s again that time of the year when I get tired and decide to update Typo; although this is probably one of the most invasive changes since I started using this software (it moved from Subversion to GIT), it seems to have been the one with less issues to fix. Although some were quite nasty.

First problem is that the version you can find in git right now is broken and won’t start up… and to “blame” is our very own Hans (graaf)! I say “blame” because it’s not really his fault, and I just worked it around by removing the Dutch localisation, which I don’t need anyway. I had to fix up the theme to work with the new Typo code, but I also took the time to fix a few more obnoxious things in the theme so that it now looks nicer too.

There were just two main issues with the update: the easy one is that the users don’t get activated after migration, which means you cannot login, a psql call after and I’m back in; the other problem is that the Atom feed generated was invalid, because to replace the HTML entities like eacute for é and similar, it decoded all the entities… included the lt/gt used to avoid injecting tags into the posts; luckily for me I had one such “fake tag” right in my previous post so I have noticed this problem right away; I hacked it around for now, as soon as I have little more time I’m going to actually fix it properly.

I had to update the mod_security access restriction since now comments are posted through a single /comments URI, which actually makes it much nicer. I’m going to update it and post it ASAP. The live search support (which I already removed from the template a few days ago) now is optional in Typo itself, which is good; I have to port the Google custom search code to the new sidebar plugin interface, to make it blend better.

I’ll require a couple more packages to be added to portage to work too, but that can happen later, not today that I’m already swamped a bit. I like the new admin interface, although it increased the size of fonts (although not as much as WordPress) and I hate huge fonts (Firefox does not allow me to use smaller fonts it seems; the rest of my system is set to 75dpi – which is fake – but works fine, Firefox does not accept that).

Updating a BIOS without floppies, Windows or CDs

One regression I have with Yamato is that the BIOS cannot be updated through the BIOS itself, like I could do with my previous ASUS motherboard (and Award BIOS). The AMI bios of the Tyan motherboard doesn’t support that.

But since I don’t want to use my Windows installation to do the job (I use it only for work and to play more recent games that don’t play in Wine), I decided to look up something that could allow me to do the upgrade using only Free Software, my Gentoo Linux install, and the files provided by Tyan.

Caution: I make no warranty that the procedure will work properly, if this post gets published it means I was able to get it working myself but it might not work for you! Please remember that you do this at your risk!

I found an interesting post about FreeDOS and USB drives, which made my life much more easier. But as I’m using Linux and in particular Gentoo, I revised a bit the instructions :)

  • first of all, merge the software we’re going to need, this means sys-boot/makebootfat (from my overlay) and app-arch/libarchive (to extract an ISO file later on);
  • proceed then to create the directory where to put the files that will go on the virtual floppy, let’s call it “bios-update”;
  • download the new BIOS from Tyan’s website, and put the content of the zip archive in “bios-update”;
  • download FreeDOS (I suggest you to use the torrent download rather that ibiblio that is so slow!);
  • extract the ISO, with bsdtar it’s just the same as extracting a standard tar file: xf and all;
  • copy freedos/setup/odin/{command.com,kernel.sys} from the FreeDOS ISO to the “bios-update” directory;
  • from freedos/packages/src_base/kernels.zip extract the files source/ukernel/boot/fat{12,16,32lba}.bin.
  • run the makebootfat command with a commandline similar to this: makebootfat -o /dev/sde -E 255 -1 fat12.bin -2 fat16.bin -3 fat32lba.bin -m /usr/share/syslinux/mbr.bin bios-update; note that /dev/sde has to be changed to your USB device.

Now just restart your system with the USB drive in it and run the flash utility as provided by your manufacturer.

As an alternative you may rename an eventual batch file provided by your manufacturer to autoexec.bat so that it is ran at boot; I have no idea (yet) how to stop FreeDOS from asking date and time, but whatever, just press enter at them. You don’t usually have to worry about infinite loops of BIOS updates, as once the update is done, I’ve noticed all BIOS, after update, require you to fill in the configuration again.

I’m tempted to streamline this to a script or make the makebootfat ebuild fetch the needed files out of the FreeDOS ISO, or create an ebuild that install the basic FreeDOS files needed to create the boot disk. But maybe another time.