Random tech notes and tutorials

First off, this is related to the post in VMware Communities here: http://communities.vmware.com/message/1576370

I recently updated a VMware Infrastructure to vCenter 4.1. All ESX servers were still on ESXi 3.5. This shouldn’t be a problem, you just can’t use some of the new features available in 4.1. That’s fine, except that I couldn’t view the managed paths in the ESX servers. I would get the error below. I would get the same error when trying to manually migrate a virtual machine to a different ESX server.

You can see the error states Item has already been added. Key in dictionary: ‘Vmomi.Host.PlugStoreTopology+Path’ Key being added: ‘Vmomi.Host.PlugStoreTopology+Path’. And of course you can see that two entries are listed.

I tried multiple solutions, including completely reinstalling vCenter with a new database and reconfiguring. Restarting the ESX servers didn’t matter. The real solution was upgrading all of the ESXi servers to 4.1. This shouldn’t seem necessary, but the upgrade through Upgrade Manager (they got rid of the Host Update Utility after 4.0) was relatively easy and smooth. After having issues with vCenter 4.1 I was reluctant to move the ESX servers there, but so far everything is working great, including migrations and managed paths.

Debian has its own package for Subversion, but most of the time you want to use the latest Subversion package that’s out there. This explains how to build and use that over Apache and HTTPS.

• Installation
• Configuration
• Maintenance and Use

Installation

This particular install does not use the Berkeley DB method of code repository storage, but rather the flat file system storage method. Both have their advantages, but the file is believed to be faster. Read more here.

First setup Apache and get all the Subversion dependencies.

Then we get this warning, but FSFS is fine to use instead of Berkeley.

configure: WARNING: we have configured without BDB filesystem support

You don't seem to have Berkeley DB version 4.0.14 or newer
installed and linked to APR-UTIL.  We have created Makefiles which
will build without the Berkeley DB back-end; your repositories will
use FSFS as the default back-end.  You can find the latest version of
Berkeley DB here:

http://www.oracle.com/technology/software/products/berkeley-db/index.html

Continue with the build:

After install, this error comes up, but it can be ignored and the next few steps will fix.

apxs:Error: Activation failed for custom /etc/apache2/httpd.conf file..
apxs:Error: At least one `LoadModule' directive already has to exist..
make: *** [install-mods-shared] Error 1

Create the file /etc/apache2/mods-available/dav_svn.load with the following:

Copy over the modules from source and install them in the Apache directories; also enable SSL since we want to push this over a secure channel:

Configuration

Create the file /etc/apache2/sites-available/svn so that Apache knows about the SVN repository:

Now enable the site and start/restart Apache:

Setup the initial repository with the svncreate command and make the user running the web service the owner, since they will be the user actually modifying the repository files.

Now we can create the username/password files along with the access files.

Create the access file to your repositories.

And now edit the file. You can set users using r and rw access writes. First you list the repository, and then the folder location after that for more fine grained permissions.

Now reboot the server and test access; it should start up automatically.

Maintenance and Use

The best way to use SVN over HTTPS is with Tortoise for Windows or some other tool if using Linux, like RapidSVN.

Adding Additional Users

To add more users, just run the htpasswd command linked to your dav_svn.passwd file, same as the initial configuration for users.

And now edit the access file containing the other users and defined in the Apache configuration. You can set users using r and rw access writes. First you list the repository, and then the folder location after that for more fine grained permissions.

Backing Up the Repositories

To backup a repository, use the svnadmin dump command which will export the entire database and revisions. You can then tar up and gzip the dump file for compression, and back it up to tape or disk somewhere else. There are also incremental backups that can be done of disk/tape space is an issue.

Restoring the Repositories

Restoring the SVN database is simply rewriting all the revisions from the dump back into a database. The restore process also works well for moving an older repository over to a new one since restoring the dump into a new SVN database will update it to that version.