My Subversion/Trac server was at Trac v0.9.6 and Subversion v1.3.x because those were the latest stable releases when I set up the server. I decided it would be relatively quick and painless to at least get the latest version of Subversion (v1.4.5) installed since I didn’t see anything on the web about Trac v0.9.6 being incompatible with newer Subversion builds.

Using the Windows binary installer, I had no problem installing Subversion v1.4.5 on the server. I tested everything and Subversion still worked, it showed the new version when accessing via web access, and Trac still worked fine.

Alas: Don’t forget that an upgraded version of Subversion will not upgrade your repository. It will upgrade a working copy of a checked-out repository, but it will not upgrade the repository itself.

That said, I was unaware of one more step that you must take to upgrade Subversion on a Subversion/Trac setup: You must also upgrade the Python bindings to Subversion.

This became apparent the next time I created a new repository, which was not a v1.4.x repository, and when I tried to build a Trac environment to point to it, Trac got upset because of the classic “Expected version ‘3′ of repository; found version ‘5′” error. To fix this, you must set up new bindings to the new version of Subversion, as explained in the TracSubversion page.

Now, I obviously love Subversion and I love Trac, but honestly, straight-forward documentation that is easy to understand for someone who doesn’t want to get in the thick of it isn’t really the strong suit for these communities, at least when it comes to installation and deployment on the server. What exactly it means–and how to do it–when they say, “Update the Subversion bindings” is not easy to understand. However, the solution is simple. All that is needed is to download the appropriate “svn-python” Windows installer that matches your version of Subversion and Python (in my case, 1.4.5 and py2.3) and run it on the server.

In my case, I had to stop Apache for the installation to succeed. Upon restarting Apache, everything worked great.

You’ll get display server issues if you try to install Ubuntu v7.10 in Parallels. But the Parallels Tools CD does have drivers to fix those problems. This blog post, Ubuntu 7.10 Install Guide, helps you get past the display server issues long enough to get the OS installed, and then gives instructions on how to get the Parallels Tools installed.

It worked great. Instructions were very clear and the process was mildly simple.

After installing Windows Vista, I could not connect to my Samba fileshares. I’m running Samba v3.0.10 on CentOS v4.4.

It turns out that NTLMv2, the authentication protocol, is required by default on Windows Vista. According to the Samba Features by Release wiki page, support for NTLMv2 in Samba wasn’t fully developed until Samba v3.0.21.

Running yum would be a quick way to upgrade Samba to a more recent release. For some reason, though, the repositories I’m pointing to only have v3.0.10 as the latest available update. Rather than hassling with it, I found an article that attacks the issue from the Vista end.

The article Get Vista and Samba to Work explains how to get Vista to use the older authentication protocols, like the original NTLM. After making this change, I was able to login to my shares immediately.

Basically, all you need to do is run the Local Security Policies console snapin (secpol.msc), open Local Policies –> Security Options –> Network Security: LAN Manager authentication level, and change the setting from “NTLMv2 responses only” to one of the more lenient settings, like “LM and NTLM – use NTLMV2 session security if negotiated”.

This works for me because I have one, sometimes two, machines with Windows Vista connecting to my server. If you had lots of machines connecting to the server, it’d obviously be worth your time to just upgrade Samba to a version that supports NTLMv2.

I've got a Linux server that acts as a fileserver, among other things. I have hundreds of gigabytes of data on it, accessible to any of my computers but in a simplified fashion because I'm not duplicating the data on each computer, plus backup is more straightforward because I just need to backup the server. And Linux is great for automation, and for raw processing of files in bulk.

So, how to back up the data?

I have installed Webmin, which makes backing up directories in the filesystem trivial. With a web form, you can specify everything about your backup: What directories to backup, where to save the backup file, whether you want to just tar it or also bzip the archive; it even handles scheduling it as a cron job, notifying you the results via email, and more.

If you were do to this manually, though, your tar command might look something like this:

You're telling tar, "Please -create a -file at /path/of/archive.tar.bz2, and along the way, compress it using --bzip. The path to archive is /path/to/backup."

I was backing up a 15GB directory and didn't want to make the server spend the extra time compressing all that data, so to save time I did not use the --bzip argument, and so instead it just creates a tar file which I'd name archive.tar.

Great. We're backing up on a regular basis now. I feel much better.

Oh no, I need to retrieve a single file from my backup! How do I do it?

It would be overkill to extract the whole archive, especially when it's really big like my example, when all you need is a single file, perhaps just a few megabytes in size.

Well, if you were to extract the whole archive, you might type:

You're telling tar to extract from the file archive.tar, and be verbose, showing all the files you extract.

Again, that's a waste of time and hard drive space. Instead, --list the archive to find the file you need, and then --extract the exact file by specifying it to tar.

You could just list all the files and try to find your file in the list:

Again, a waste of time. Make Linux do the work. I know the file I need to restore is foobar.txt, so tell Linux to return just that file by piping the archive list into grep:

It crunches through the archive, looking for that file. Finally, it returns, say, "my/path/to/foobar.txt". Excellent! Now ask tar to extract just that single file from the archive:

Now, tar will wade through all the files in the archive, and only extract the single file.