Author: Paul Tomblin

Debian stable just updated. Usually when Debian drops a new “stable”, it means its bombproof as hell and tested out the wazoo. This time, I’m not so sure that is true.

First candidate is a virtualbox that I use to keep some client data on an encrypted partition and safer than just leaving it on my desktop machine.

First attempt threw some errors about problems with “default-jre” and “openjdk-6-jre”, but I don’t use java on this virtualbox so I just removed them.

Second attempt gave a huge problem because of some conflict between CPAN installed Perl modules in /usr/local/share/perl/5.10… and the new 5.14 modules. It seems to me that the installer should just remove /usr/local from the Perl paths and ignore any locally installed stuff.

I tried removing that directory manually, but by that time the install was so screwed up that I actually went back to a clone I’d made of the virtualbox and tried again. This time I removed the JRE stuff and moved /usr/local/share/perl out of the way. The upgrade went much more smoothly, except the screen goes totally blank for a long time during the upgrade, and when it’s done the reboot prompt is showing empty boxes instead of letters. Fortunately I guessed correctly as to which box was the “ok” button.

After it upgraded, I discovered that Postgres 8 was marked as deprecated, so I did a pg-dumpall, removed it, imported the dump into Postgres 9, and all was well, no problems. Then I had to get RT working again, so I used aptitude to install as many of the packages as I could that formerly had been in /usr/local/share/perl. The only one I couldn’t find a deb for was Plack::Handler::Starlet, so I let CPAN install it.

Once that was up and running to my satisfaction, I figured it was time to move on to my linode. The linode hosts my navaid.com databases and a bunch of mailman mailing lists, and not much else. Remembering the Postgres 8 to 9 thing, I made sure to pg-dumpall before I started. There were no files in any local perl directories, and no jre, so I was good to go.

As it was updating, I saw it removing the Postgres 8 version of postgis. Oh oh, I thought, that’s not good. I’ve discovered in the past that you can’t simply recreate a postgis database using a pg-dumpall dump. So after the upgrade, I of course tried to install postgis for PostgreSQL 9, and once again panicked as it dragged in a ton of X11 crap I don’t need. Then I tried and failed to do a restore of the dump file. What I ended up doing was

1. creating the database user for that site
2. creating the databases for that site
3. running the scripts that come with postgis for creating the spatial functions
4. coping the pg dump file, and cutting out anything related to other DBS, and cutting out the drop and creation of these DBS.
5. running this cut down version of the dump file
6. making another copy of the dump file that includes all the other DBS, including the drop and create commands and running it.

Everything seems to be running now.

Some time I’ve got to go on and upgrade my xen host and guest oses on my colo box, but I’m really reluctant to do that one because if something goes wrong, I’ll have to drive in and try to fix it while standing in a freezing cold server rack farm.

There is something strange going on with my colo box. I tried to reboot it last month and it didn’t come up – I had to call my provider and get them to power cycle it. Nothing useful in the logs.

Yesterday I had to install a security update to the xen hypervisor, but I didn’t reboot. This morning, I discovered that the websites working on the xen guest (the domU in xen parlance) were not working. So I tried to log in, or ping, and discovered it wasn’t talking to the network. Fortunately the xen host (aka dom0) was working – I could log into it, then use xm console xen1 to log into the guest. Couldn’t find anything wrong, except it’s not talking to the network. Even “ifdown eth0; ifup eth0” doesn’t cure it. So I tried to reboot the guest, but it didn’t seem to come back up. I wondered if the hypervisor update I installed yesterday was the problem, so then I rebooted the whole computer, and it didn’t come back up either.

I drove down to the colo facility, and connected a monitor and keyboard, but nothing showed up. On the front panel, there are a couple of blinking lights. I power cycled. It came up just fine. Logged into the host, xm consoled into the guest, verified that I could ssh out, and from my home computer I could wget a few web pages from it. Issued a reboot command, and it booted just fine. Poked around the BIOS settings to see if there was something about not booting if there wasn’t a keyboard or something stupid like that, but couldn’t find anything. Booted, verified once more, and came home.

Until the next time, I guess.

I really wanted to like ownCloud, the “Dropbox you host yourself” (my description, not theirs). It seemed so promising – I could have as much space as I wanted, it would be more private, etc etc etc. But I’ve had it installed for over a month now, and seen numerous upgrades to both the client and the server, and I’m ready to uninstall.

• The 64 bit Linux client crashes and dies constantly. I’m actually somewhat surprised on the rare mornings when I wake up and discover it hasn’t crashed overnight. Yes, it crashes when nobody is modifying any of the files on any of the systems that share those files, sometimes multiple times a day when I can be bothered to restart it.
• All the clients continually put up an error indicator at random times and then clear up at other random times. Again, usually when nothing is happening.
• While it offers CalDav sync and I was able to add the calendar to my phone, iPad, and laptop calendars, I wasn’t able to use it to break free of the Google Calendar hegemony because I share calendars with other people and I couldn’t very well ask them to convert as well. They had a web based calendar of their own, but it is incredibly basic compared to say, Google Calendar or iCloud calendar.
• Similar problem with the contact syncing.

Frankly I would have put up with all the other problems if the 64 bit Linux client wasn’t such a flakey piece of shit. But I see no reason to keep going with this if I’m getting no synchronization between my main desktop and my other computers.

Last week I installed “ownCloud”, a Dropbox like file sharer where you run the server so nobody you don’t want gets control over your files. It also provides calendar and contact sharing, as well as supposedly providing an rss reader/aggregator to replace Google Reader, although I haven’t figured out how to implement that yet.

Installing it was pretty easy – I used the Debian packages hosted on opensuse for both the server and my linux box, and a more direct install on my MacBook. It took a bit of messing around to get ssl working on my web server because my sites-enabled config files were a mess that just barely worked in the past.

I added the documents folder on my MacBook to the ownCloud, and it synced. I could see all the files on the web interface. Then I moved the Documents dir on my Linux box out of the way, and added the ownCloud Documents dir to it. A little while later, all the documents from the Mac were now there on my Linux box. Then I moved all the docs that had been on the Linux box’s Document dir back into the dir, and watched as they appeared on the web interface and on my Mac. The very next day, the server was reporting that ownCloud version 5.0 was now out, and so I upgraded.

The upgrade didn’t go 100% smoothly. At one point in the web interface part of the upgrade, it appeared to stop doing anything, and so I reloaded the page. I’m not sure if that’s the cause of all my future problems, or just another symptom. At a later time I noticed an error appearing in the web admin page mentioning a duplicate key in an index. That probably isn’t good.

I didn’t run the old 4.7 version long enough to tell if it happened there, but this week I’ve noticed the following big problems:

• frequently throughout the day, the “dock icon” on Linux or the toolbar icon on the Mac will indicate a problem, but it will go away on its own. The error mentions something about being unable to find a sync file.
• the linux client crashes almost every night, and sometimes during the day
• this morning, the linux client hadn’t crashed, but it was consuming 150% of a CPU
• the number of requests to my apache server has gone up astronomically, mostly “PROPFIND” requests on ownCloud.
• when I noticed a dozen or so directories in Documents that I don’t need any more and attempted to remove them on the linux box, 3 of them came back. One of them came back seven or eight times, as I removed it on Linux box and then the web interface, and finally on the Mac

I also tried installing the client on a 32 bit Linux virtualbox vm, and was able to get it to sync the default “ownCloud” directory, but I couldn’t get it to sync “Documents”.

In spite of these problems, as a file sharer I think it’s an awesome idea. I might try blowing the installation away and recreating it to see if that clears some of the annoyances.

Having a central store for my calendar is pretty nice, and I can use caldav to add that calendar to my iPad calendar and others. I exported my whole google calendar and imported it into e owncloud calendar without too much trouble. The drawback is I don’t see any easy way to allow Vicki to copy things onto my calendar like she does with my google calendar. Also, their web interface is pretty basic, but like I say you can just point other calendar programs like the iOS and KDE ones at it.

So if you’re like me and wish Dropbox gave you more disk space, and you just happen to have a spare 20 or 30 gig of unused space on a server somewhere, give ownCloud a try.