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.

A good while back I asked if anyone knew how to have a machine respond properly over two interfaces. We'll after some actually looking (read: using google for a bit) I found out how. As a note this assumes your using linux, I have no idea how one would accomplish this using fbsd, obsd, or solaris.

Compile in Advanced routing and enable some of the sub options as your feel. If you want to route based on content/iptables rules, I suggest enabling iptables and enabling the route based on mark stuff.

Once the kernel is all set, install iproute2. Use the ip addr command to add another ip (if you don't have one in mind already). Then, edit /etc/iproute2/rt_tables and add a table to the list for your second gateway (i used cable). Once you've done that run ip rule add from <src ip here> table cable. Then run ip route add default via <other gateway here> table cable. Once that is all set your should be able to route to that machine from both gateways. The iptables rule integration is another blog entry. Suffice it to say that if you want your torrents using one pipe and your ftp traffic another, it is indeed possible.

As a side note, I am currently quite annoyed with valve, over what seems to be hlds' inability to listen on multiple ip addresses. I have assigned two addresses on different subnets to a box and can only hit one. The other can be hit if hlds is explicitly told to listen on that ip. Very frustrating when your trying to split the bandwidth over multiple pipes.