Upgrading FreeBSD

An interesting script to upgrade FreeBSD (and installed ports) from mebsd.com: .

#!/bin/sh
LOG_FILE="/var/log/freebsd-update.log"
echo "Starting updates: `date`" | tee -a ${LOG_FILE}
echo "***"
echo "*** Checking for FreeBSD patches..."
echo "***"
/usr/sbin/freebsd-update fetch | tee -a ${LOG_FILE}
/usr/sbin/freebsd-update install | tee -a ${LOG_FILE}
echo "***"
echo "*** Updating ports tree..."
echo "***"
/usr/sbin/portsnap fetch update | tee -a ${LOG_FILE}
echo "***"
echo "*** Looking for ports to update..."
echo "***"
/usr/local/sbin/portmaster -a --no-confirm | tee -a ${LOG_FILE}
echo "***"
echo "*** Checking installed ports for known security problems..."
echo "***"
/usr/local/sbin/portaudit -Fva | tee -a ${LOG_FILE}
echo "Finished updates: `date`" | tee -a ${LOG_FILE}

This uses "freebsd-update" and "portmaster" which seem to be the "modern" way for people to manage FreeBSD installations.

P.S. Oh well, I still like to recompile world+kernel by hand...

/FreeBSD | Posted at 19:53 | permanent link

Raspberry Pi, Beagle Board, Soekris, NUCs, ...

I've been using Soekris boards for years now (a few net4801s, a net5501, and a net6501). They're excellent machines for FreeBSD or Linux, and broadly compatible with PCs, as they use x86 CPUs.

However, I must say that I am tempted by some of the newest little boards out there that are quite inexpensive: the raspberry pi, and the beagle board. I might just buy one of those to display various info and RSS feeds on a big mounted screen that we've got at the office.

The Raspberry Pi is nice, but I quite like the fact that the beagle board is Open Source Hardware.

/hardware | Posted at 19:44 | permanent link

Speaking about hockey

The Stanley Cup playoffs are just getting underway in North America. The pairings for the first round of the playoffs in the NHL Easter conference ended up being decided on the last day of the season... the 4-2 win of the Otawa Senators against the Boston Bruins last Sunday means that the Montreal Canadiens finished 2nd in the Eastern Conference, and will now play those same Senators in the first playoff round for the first time since the return of the Senators in the NHL in 1992.

Hockey is an exciting game -- I will try to catch a few games on Internet radio over the coming days.

/misc | Posted at 18:53 | permanent link

I despise 'Automatic Private IP Addressing'

The number of times where a Mac, an iPad, or a Windows machine has caused me grief by chosing to self-assign an "Automatic Private IP Address" is becoming annoyingly large.

I would much rather have these machines inform me that there is a problem with the DHCP server on the local LAN and that I should fix it, rather than trying to self assign an IP address in the range of 169.254.x.y, which generally doesn't work and doesn't let the machine talk with any of the other devices on the network... and of course, because the machine that tried to helpfully self assign an address thusly will not notify me of this, meaning that it will take longer to find out what has gone wrong.

Sometimes, especially on Apple devices, it will also be annoyingly hard to make the device snap out of this mode and actually request a brand new IP address from the local DHCP server. Argh! In addition to that, it is usually distressingly hard to disable this behavior in devices, as they all try to be simple and auto-configurable. Argh again!

Another woe of DHCP address assignment are home routers that do not provide options to manage the list of assigned DHCP addresses or their corresponding leases, and which therefore run out of assignable addresses with leases running well into 2021 or something! Recently, my Livebox from Orange ran out of available DHCP addresses, and therefore stopped giving them out... which caused various networking equipment to fail in interesting ways.

So yes, I know: "use static IP addresses". I do that most of the time, but still have my various mobile devices configured for DHCP, simply because that's what ones does when travelling with ones' mobile devices.

Anyway, here's hoping for:

1. a simple way to disable 169.254 addresses in Windows, IOS, and Mac OS X
2. a simple way to edit the DHCP leases table on the old Sagem Livebox

So yeah, I'm not holding my breath :-)

/admin | Posted at 18:52 | permanent link

FreeBSD 9.1 panics resolved

A couple of weeks ago, I upgraded this small machine to FreeBSD 9.1. This is a small and very reliable Soekris net4810-50 box with 128 MB of RAM that has been running FreeBSD for years.

Since upgrading, it has been crashing daily around 03:00 with a panic message that I've finally captured today:

panic: kmem_malloc(4096): kmem_map too small: 38060032 total allocated

Some googling around let me to this thread from December 2012 on freebsd-stable.

which explains a similar situation. The recommendation in the thread is to add:

kern.cam.ctl.disable=1

to /boot/loader.conf to avoid loading the new CAM CTL device, which seems to require lots of RAM.

So, rax.org is back on its feet, hopefully with its usual stability. I'll write again if I encounter any further issues.

I have to say though that I am somewhat surprised that the GENERIC build of FreeBSD suddenly has significantly higher RAM requirements as of FreeBSD 9.1, though of course 128MB of RAM is small in today's world.

/FreeBSD | Posted at 02:10 | permanent link

I *really* hate gettext

OK, so I know that some of this is certainly self-inflicted, but I seem to regularly run into trouble where I try to upgrade a bunch of ports on a FreeBSD installation somewhere, and bam suddenly I get build errors around locales or gettext shared libraries.

Sigh.

Now, I do like my applications to be able to speak French just as much as the next guy, but somehow the amount of grief that this has been causing me over the years is getting to be significant.

Latest issue is trying to rebuild ports on 3 different machines following an upgrade to FreeBSD 9.1. All went smoothly with the O/S upgrade using freebsd-update, but trying to rebuild the ports after fetching the latest versions using portsnap is proving harder than expected (or warranted).

I have downloaded the latest ports, and am trying to do the equivalent of "portmaster -a", and then I get:

./localename.c: In function '_nl_locale_name_thread_unsafe':
./localename.c:2607: error: 'locale_t' undeclared (first use in this function)
./localename.c:2607: error: (Each undeclared identifier is reported only once
./localename.c:2607: error: for each function it appears in.)
./localename.c:2607: error: expected ';' before 'thread_locale'
./localename.c:2608: error: 'thread_locale' undeclared (first use in this function)
./localename.c:2608: error: 'LC_GLOBAL_LOCALE' undeclared (first use in this function)
*** Error code 1

when compiling /usr/ports/devel/gettext/work/gettext-0.18.1.1/gettext-runtime/intl/localename.c, which seems to indicate that "locale_t" is undefined and therefore that configure is probably not picking the requirements for locale on my system correctly, or that I have some old dependencies lying around.

So, hunting around in "/usr/ports/UPDATING" seems to indicate that I should rebuild converters/libiconv first, and then rebuild devel/gettext. So, I did that. But still not success. So it seems I would need to rebuild devel/libtool first, so I did that too. But still gettext won't compile.

Sigh.

This whole i18n thing seems to violate the principle of least astonishment.

Anyway, just a rant because I am frustrated. I'll go back to it and attempt to do things right this time... but I really do hate gettext.

P.S. Sigh... even sudo fails with "sudo: unable to dlopen /usr/local/libexec/sudoers.so: Shared object "libintl.so.9" not found, required by "sudoers.so""... will rebuild it without the NLS option!

P.P.S. Finally solved it by recompiling the world and kernel from source... and then "gettext" compiled correctly. Not sure what changed... this is unpleasant.

/FreeBSD | Posted at 02:08 | permanent link

Accessing ZFS snapshots

I make hourly snapshots of the ZFS filesystems on my home server. This is quite easy using a small script called "zfs-snapshot.sh" (which I found on the web) and the following lines in root's crontab file:

# perform zfs snapshots
3  *  *  *  *   /root/zfs-snapshot.sh pool0 hourly 25
13 0  *  *  *   /root/zfs-snapshot.sh pool0 daily  32
23 0  *  *  0   /root/zfs-snapshot.sh pool0 weekly 60

7  *  *  *  *   /root/zfs-snapshot.sh datapool hourly 25
17 0  *  *  *   /root/zfs-snapshot.sh datapool daily  32
27 0  *  *  0   /root/zfs-snapshot.sh datapool weekly 60

This keeps a day's worth of hourly snapshots, a month's worth a daily backups, and a year's worth of weekly backups (I should perhaps also keep a decade's worth of annual backups?!).

This is useful and can be really easily accessed... For example, I restored "/usr/local/lib/libintl.so.9" from a recent snapshot by doing:

cp /.zfs/snapshot/daily.5/usr/local/lib/libintl.* /usr/local/lib

Accessing snapshots through .../.zfs/snapshot is quite handy.

PS. For the record, the zfs-snapshot.sh script is here.

/FreeBSD | Posted at 15:42 | permanent link