tech addict

When I initially built my primary server, the latest stable postgresql package was 8.0.x. At this time that same tree is still marked as stable. I'm sure that this is largely due to the overall postgresql upgrade philosophy, which involves dumping (backing up) all your dbs and the restoring them after the upgrade. Since that isn't a seamless process, I'm sure they want an upgrade to be a conscious decision. That being said, the current upgrade path involves switching from the dev-db/postgresql package to the dev-db/postgresql-base/dev-db/postgresql-server packages.

Many thanks to @dberkholz for pointing me at the package maintainer's blog (which doesn't come up when searching google due to the large number of portage search/info listings). Here's what I ended up doing:

• pg_dumpall > /tmp/please_work.dump
• /etc/init.d/postgresql stop && emerge unmerge libpq postgres

• echo "dev-db/postgresql-base ~amd64" >> /etc/portage/package.keywords
  echo "dev-db/postgresql-server ~amd64" >> /etc/portage/package.keywords
  echo "virtual/postgresql-server ~amd64" >> /etc/portage/package.keywords
  echo "virtual/postgresql-base ~amd64" >> /etc/portage/package.keywords

• emerge -uD postgresql-base postgresql-server
• emerge --config "=dev-db/postgresql-server-8.3.3"
• rc-update add postgresql-8.3 default

Now here's where you get to rebuild everything that links to libpq and update postgresql.conf as needed. Once that's done you use pg_restore to reload all your data. I had some grants fail, so I needed to redo them manually. So far so good, the db seems to be a bit faster and less resource hungry. I may post the rrd graphs from cacti later, but there is a noticeable difference.

I've finally gotten motivated enough to switch over to apache 2.2. Unfortunately the ebuild for apache 2.2 is currently masked due to problems with some modules (mod_auth_mysql and mod_fastcgi). I don't use mod_auth_mysql, so that posed me no problem, but I have trac setup with fastcgi. I did a little research regarding mod_fastcgi's problems, which some people have already resolved on their own. Fastcgi is currently unmaintained so those patches or any sort of real fix (the problem stems from the removal of deprecated apis) aren't being added to the main tree. I used a patch and created my own ebuild, both of which I've added to the bugzilla ticket for the problem.
After installing, I had to revise my vhost setup due to some change in the vhost handling. Apparently *.hasno.info will cause issues if you have trac.hasno.info and wiki.hasno.info defined as ServerAliases. I've switch over to using mod_rewrite for all of my *.hasno.info web routing.

Earlier this evening I resolved to finally hunt down the source of some thundirbird timeouts. The mail client would periodically timeout when getting mail. It would do this from the local network. Now my mailbox is in no way small. The mailing lists I subscribe to see to that. My mailserver is using reiserfs and maildir, so I was pretty sure it wasn't a filesystem related issue. In addition, the server is running on a set of hardware raid5 drives which rules out a disk speed issue.

While watching the mail logfile, I noticed the following error: imapd-ssl: FAMPending: timeout which led me to the enhanced idle support found in courier-imapd. When there isn't any activity at the mail client, it will enter an idle state and be sent mail reciept notifications. It's supposed to be much better than polling. After looking at the famd stuff, I came upon gamin. Gamin is a replacement for fam, that does not provide the full fam featureset or run as a system-wide daemon. Both of those changes are positive, fam was designed to handle more cases than I need or want. As far as the lack of a system-wide daemon goes, its a security plus. Gamin spawns a daemon as the calling user (its implemented as a library). After unmerging famd and installing gamin, imap interaction is much peppier.

We'll I've migrated from my old dual p3 server, to a newer dual p3 server with a raid controller and u160 drives (not to mention doubling the ram, 1gb to 2gb). I decided to rebuild my gentoo install to clear away the cruft as it was initially created using ~x86 for everything, which is obviously a bad idea for a production machine (which i consider my server to be). Upon setting up the network I found that gentoo now has "native" support for interface bonding.

The majority of the servers in my closet are running intel processors (mostly P3's). Apparently intel publishes microcode updates for its processors, which should supposedly improve the processor's performance and/or reliability. I have no idea if it does improve anything at this point as Intel does not provide a changelog for the microcode. Gentoo has an ebuild for the linux microcode utility which you can setup to auto-upgrade you're processor at boot. Microcode changes do not survive power-down, so they must be re-applied at boot.

Sep 21 18:00:26 sakuya kernel: microcode: CPU1 updated from revision 0x0 to 0x7, date = 05052000 Sep 21 18:00:26 sakuya kernel: microcode: CPU0 updated from revision 0xc to 0x13, date = 02062001

As you can see, there were quite a few revisions between my released P3 800's and the published intel microcode. I'll update this in a few weeks with my findings.