I suspected that upgrading from 0.9.3 directly to 1.3-stable would be a nightmare, so i was planning on upgrading to 1.0-stable, then to 1.1-stable, then 1.2-stable and finally 1.3-stable.

All looked well, and i started taking backups. Of course, the whole Redmine installation was setup using the Ubuntu repositories, so clearly, all of the ruby, rails, rake and rubygems packages were from Ubuntu 10.04. Which would cause a bit of a problem, as i needed newer versions of certain packages. So i ran the following commands (after taking backups of course.) to remove redmine and all it’s dependencies and reinstall whatever is necessary to run rubygems, rake and libapache2-mod-passenger.

aptitude remove redmine
aptitude install rubygems rake libapache2-mod-passenger

This made sure i had a basic setup. After that i used svn to get all the versions

svn co http://redmine.rubyforge.org/svn/branches/1.0-stable redmine-1.0
svn co http://redmine.rubyforge.org/svn/branches/1.1-stable redmine-1.1
svn co http://redmine.rubyforge.org/svn/branches/1.2-stable redmine-1.2
svn co http://redmine.rubyforge.org/svn/branches/1.3-stable redmine-1.3

This gave me the opportunity to just go into the appropriate directory, follow the guide on Redmine.org on how to upgrade and do that for each major release. On occasion rake would throw me an exception stating i needed a gem installed or a newer version installed, but overall that wasn’t a real problem. Just make sure you run

gem install -v=<correct version> <gemname>

This all went good until i got to the point of upgrading to 1.3. Apparently version 1.3 needs a later release off rubygems. Whenever i tried running rake to do the db migration, i ended up getting the following error:

rake aborted!
super: no superclass method `requirement' for <rails::gemdependency:0x7f9e87ea7a18>;

This is a little problematic as the Ubuntu 10.04 LTS repository does not allow for a newer version to be installed from it. My solution was to just get the package from a newer distribution using a backport available thanks to a Ubuntu PPA from Mackenzie Morgan (Thanks!):

add-apt-repository ppa:maco.m/ruby
aptitude update
aptitude install rubygems

This installs a version which can be used by Redmine 1.3-stable. After that, everything looked great, i could log in, i checked the configuration and it worked!

Or i thought… Whenever i opened the issues list of the project, i would get a Server error (500), the log reflected this:

ActionView::TemplateError (undefined method `-' for nil:NilClass) on line #28 of app/views/issues/_list.html.erb:
25:     
26:     < % previous_group = group %>
27:   < % end %>
28:   <tr id="issue-<%= issue.id %>" class="hascontextmenu < %= cycle('odd', 'even') %> < %= issue.css_classes %> < %= level > 0 ? "idnt idnt-#{level}" : nil %>">
29:     <td class="checkbox hide-when-print">< %= check_box_tag("ids[]", issue.id, false, :id => nil) %></td>
30:     <td class="id">< %= link_to issue.id, :controller => 'issues', :action => 'show', :id => issue %></td>
31:         < % query.columns.each do |column| %>< %= content_tag 'td', column_content(column, issue), :class => column.css_classes %>< % end %>

Googling the error returned me to a bug report from version 1.0, which presented me with a simple solution, i just had to run a simple query on the database:

update issues set parent_id = NULL, root_id = id, lft = 1, rgt = 2;

It seems that in Ubuntu 11.10 the directory containing running processes information and lock files has changed, or well, it has for certain programs. This results in a system where certain daemons/programs expect to find sockets in /var/run, while they are present in /run, or vice versa.

This might result in a boot problem looking like this:

The first lines are not so important, what is important are the last two. It says:

unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket : connection refused
Waiting for network configuration...

After that last one, you might get that it waits for another 60 seconds for network configuration, but it will get stuck in boot after that.

Luckily i had my 3G enabled phone close, so i could do some searching, which gave me a link to a bug report and a forum post with a fix. In short, few simple steps can help you out here:

1. reboot into recovery mode
2. start a root shell
3. mount the filesystem as read/write:
   

   mount -o remount,rw /

4. move everything from /var/run into /run:
   

   mv /var/run/* /run/

5. move /var/lock into /run:
   

   mv /var/lock /run/

6. create symlinks from /var/run to /run and /var/run/lock to /var/lock:
   

   ln -s /run /var/run
   ln -s /run/lock /var/lock

7. reboot

Worked like charm here. Hope this helps.

As this setup is a small environment, i chose to use the MSSQL Server 2005 Express which is bundled with the vCenter 4.1 U1 installer. But with the release of vSphere 5, vCenter no longer supports MSSQL Server 2005 Express.

The solution? Install MSSQL Server 2008 R2 which i have a license for because of my Microsoft Action Pack Subscription and move the database of vCenter 4.1 and Update Manager to this new DB server.

So in one of my Windows Server 2008 Enterprise VM’s i installed the SQL server and set it up to contain the databases for VMware Update Manager and VMware vCenter.

First up: Update manager!

Moving the database to the new server was rather easy. Steps i took:

1. Allowed mixed authentication
2. created a user with sysadmin rights, just for the ease of it
3. Made a database called VIM_UMDB
4. Set the compatibility to 90 (MSSQL 2005)
5. Stopped Update Manager
6. Took a backup of it’s database
7. Restored it to the VIM_UMDB on the new server (overwrite everything)

After this step something went wrong, it took a while before i figured out the problem was with the Database connector. It seems so logical now, but it took me a while to figure it out. So a little guide after you moved the DB:

1. Install the MSSQL 2008 R2 Native Client, this also installs a 32bit driver. You can download it from here (search for Native Client)
2. Open odbcad32.exe (C:\Windows\SysWOW64\odbcad32.exe) , not the regular ODBC configruation. This is where i went wrong, you need to open the 32 bit version to add a 32 bit connector.
3. Add a new connector with the SQL Server Native Client 10.0 driver and name it something you can remember

Now the only thing we need is to change the configuration of the Update Manager so it knows to use the new database connector.

1. Just open C:\Program Files (x86)\VMware\Infrastructure\Update Manager\vci-integrity.xml
2. Find the <database> tag
3. In the <dbtype> tag, fill in: SQL Server Native Client 10.0
4. In the <dsn> tag, fill in the name of the DB connector you created.
5. Save the file
6. Restart the Update Manager

To be sure, connect to your vCenter server with the client, and see if you get an error about the Update Manager. If not, check if you can scan a host or something. If everything works, great, you successfully moved your Update Manager database!

Next: vCenter Database

This should be a bit easier cause VMware has a Knowledge Base article about it (and another one). And my experience with the Update Manager database did help. Basically the first 10 steps (1-7 and 1-3) are the same, except you just create a normal DSN (so don’t use the 32 bit odbcad32.exe). Next steps:

1. Uninstall vCenter… Yes, indeed, uninstall it.
2. Reboot your vCenter server
3. Reinstall vCenter
4. During the install select the newly created database connection.
5. Don’t forget to recreate the statistics rollup job in SQL server (KB Article)

Got this code:

< ?php
$mode = 'D';
$back = 1;
$start = new \DateTime();
$start->setTime(0, 0);
$start->sub(new \DateInterval('P'.$back.$mode));
$end = new \DateTime();
$end->setTime(0, 0);
if( $back > 0 ) {
	$end->sub(new \DateInterval('P'.($back-1).$mode));
} else {
	$end->add(new \DateInterval('P1'.$mode));
}

echo $start->format('Y-m-d H:i:s') . "\n";
echo $end->format('Y-m-d H:i:s') . "\n";
$dt = $start->diff($end);
echo $start->format('Y-m-d H:i:s') . "\n";
echo $end->format('Y-m-d H:i:s') . "\n";
$differenceDays = $dt->format('%a');
echo $differenceDays."\n";
?>

This code results in:

2011-12-03 00:00:00
2011-12-04 00:00:00
2011-12-02 00:00:00
2011-12-04 00:00:00
2

It seems the diff statement changes the starting date to a date before. This is kind of an issue, i need that difference in a project between days, weeks, months and even years. And the issue get’s worse if you use weeks (the difference becomes 14 days instead of 7) in the interval or months (61 instead of 30 or 31). So i decided to use a quickfix to calculate the difference, cause this was not working…

The workaround needed to change depending on the mode variable (day, week, month or year). For day and week it could just be 1 and 7 days, but the amount of days in a month and years changes per month and per year (leap years). So i came up with:

< ?php
switch($mode) {
	case "day":
		$differenceDays = 1;
		break;
	case "week":
		$differenceDays = 7;
		break;
	case "month":
		$differenceDays = date('t',$start->getTimestamp());
		break;
	case "year":
		$differenceDays = 365;
		if( date('L',mktime(0,0,0,1,1,$start->format('Y'))) == 1 ) {
			$differenceDays++;
		}
	break;
}
?>

I decided to use the mktime function, because the getTimestamp() gave some issues concerning timezones (i think ;))

 Update

Dries Verachtert pointed me to a comment on the page of the DateTime sub method. The short of it:

If you use diff() after sub(), the effects of the sub() will be repeated on the date object.
It doesn’t matter if the object is the one diffed or doing the diffing (i.e. which object you call diff() from).
Note that using add() instead of sub() does NOT have the same effect.
This is particularly undesirable — in this example you make a datetime, use sub() to make it a relative time in the past, and then date->diff() to confirm the difference. But the diff() inadvertendly makes the difference 2x.

Strange issue, but i can tell you it’s fixed in 5.3.3, as i have running that on an internal test server, and the code does a perfect job on that.

In the past i have always counted on ULYSSIS for my personal hosting, as i have been vice-president of this organisation and have a free account because of that. But lately, i realized that, although their service is incredible for an organization of volunteers, it is not as open and free as having an own server at your disposal.

Ordering the server was rather easy, i only had an issue with the payment system, but i hope it was just a fluke and not something others experience. At least the service desk helped me out pretty quick. I opened an issue last night and it was fixed by the time i woke up this morning, on a Saturday.

After i got the base VM (Ubuntu 10.04 LTS) running i started to configure it by installing some base packages like apache, openssl, php5, suphp, … After a while i noticed it didn’t have the promised IPv6 address, so i opened another support ticket, and it took them about 15 minutes to fix it. If that’s an indication of response time for the Best Effort SLA, i am impressed.

When the IPv6 address was enabled, i did get into trouble with Apache. Everytime i wanted to start it, it crashed with the following error:

[Sat Dec 03 12:48:52 2011] [error] (9)Bad file descriptor: apr_socket_accept: (client socket)

Whenever i disabled SSL, it worked fine. After a few google searches, i came to the conclusion that the automatically generated SSL certificates became invalid with the change of network interfaces/addresses. I fixed that quickly by creating a new certificate, and my own Certificate Authority . If you need some info on how to do that, you can find a good tutorial on the website of Paul Bramscher.

And now that this blog is moved to the server, we’ll see how it goes. Next step will be to move my Symfony2 project from my development environment (VM on a personal vSphere setup on two local servers) to this server, so i can more easily access it from anywhere.

Other plans include setting up a monitoring system (Nagios) to monitor my internal network and some servers and environments of my smaller clients (who do not have the resources to implement it locally). This kind of monitoring system is already running on my local vSphere farm, but that means it uses my personal internet connection, which is just a commercial connection (once or twice a month it goes down in the middle of the night for 10-15 minutes).