That’s the last time I trust Ubuntu to upgrade correctly

I host Barcamp Chicago’s website.  It’s a custom Django site on Ubuntu.  I recently upgraded the server to the latest LTS and later discovered my Postgresql database was gone.  Postgresql had gone from 8.3 to 8.4 in the upgrade, but since it didn’t warn me about needing to migrate the data I assumed it took care of that.  That was a mistake.  I had three databases on Postgresql 8.3 and none of them were present anymore.  I read on a forum that I could reinstall 8.3, but that person was working from Karmic not Lucid like I had.  I ultimately had to:

  1. add the Karmic repositories to apt,
  2. shut down 8.4,
  3. install 8.3,
  4. go through the normal data dump procedure for upgrading Postgresql manually,
  5. uninstall 8.3,
  6. start 8.4,
  7. and load all the data again.

After that the CLI showed my databases were present so I relaunched the barcamp site, but it still wasn’t connecting.  A little more googling revealed that Postgresql likes to increment the port number it listens on when there are two versions installed on the same machine.  That was indeed the problem, so I changed the port number back, restarted it and Apache, and finally I’m back to where I started.

I should have known better than to trust Ubuntu to migrate the data, but even if I did that myself I’d never expect a minor version upgrade to listen on a different port when that upgrade disables the old version anyway.

Better Apt Behavior

Ubuntu added a nifty feature to bash recently: when you run a command that isn’t installed on your system it tells you what package you need to get it. What they need to do next is apply the same type of thing to apt. When I run “apt-get install flup” and it tells me there’s no package called “flup”, it should automatically run “apt-cache search flup” and recommend “Here are some packages you might have meant: … python-flup, …” Maybe it could even list the top 10 most likely packages and have me press 0-9 to install one of them. Either way, it’s silly that I have to first search for the package so I can find out what the distro named it, then run almost the same command again to install it.

Cgi::irc and Ubuntu

I don’t like using Pidgin(Gaim) or Mirc for an irc client when I’m on windows, and I’d rather just not bother having a client on whatever machine I’m using in general, so I usually install cgi::irc on a server and use that. I recently reinstalled Ubuntu on my server and had to reinstall cgi::irc. After that, when I tried to connect to any server I kept getting the error:




***Access Denied: No connections allowed


I tried to find an error log somewhere on the system but there wasn’t one. Eventually I grepped the source for “No connections allowed” and found it on line 715 of nph-irc.cgi. This is in the code to handle ip access restrictions. So I go to the config file and find a file called “ipaccess” which only contains a rule to allow connections from 127.0.0.1. This was the problem. I didn’t care about ip restrictions, so I went to the main config file and commented out the line:




ip_access_file = ipaccess


Now I can log in to my cgi::irc no problem. I could also have added more rules to “ipaccess”, but I didn’t want to fiddle with it, and I’d probably end up with the same situation as I have now.



It’s important to note that the default Ubuntu (7.04 Feisty Fawn) cgi::irc package comes configured like this and doesn’t tell you that you have to change it in order to make it useful. Maybe this should have a configuration prompt on installation as is done with packages like Postfix.