The previous version of myVersionControl was, by default, low security and required user configuration to fully protect repositories. The latest version of myVersionControl is built around the concept of 'protected by default'. This requires our users to consciously relax security and has caught a number of our users by surprise.
This particularly affected clients who on the old system had zero security set up. In the current version of the new system this will mean, as they have no permitted users on that resource, that they will get a rather unpleasant message telling them they have no access. Additionally a new feature in myVersionControl is the ability to control commit permission so unless a user is set up for this also it will mean that they will be able to update/checkout but committing will result in a rather cryptic 'see your administrator' message!
We do think that all these changes are essential for myVersionControl and have been widely requested with a host of advantages in addition to security, however we do appreciate that it is a change in working for many of our users. To this end we are delaying switching on enhanced security to Sunday 30th August at 0100 GMT. All clients are respectfully requested to login to their control panel and update access permissions where appropriate before the Sunday switch on. Our support desk is standing by for any questions regarding this over the weekend.
Ok - phase 1 complete
For the past month, all we've been talking about here is the upgrade. Everywhere I looked, there were reminders. My inbox, my desk, my calendar, my dreams, (the occasional nightmare) even my wife was asking how the upgrade was going. Then last weekend, when it was actually time to push the button of no return, a strange calmness came over me. There was none of the franticness I had imagined, there were couple of minor issues, but overall, it all went as smoothly as anyone could have hoped. Here's what we updated:
So, the first week is nearly over and we haven't had the flood of support tickets we were expecting. There have been a few issues to smooth out, notably with billing (or the lack of it - sorry but that couldn't last forever) and the public site. A handful of users reported some connection issues to begin with, but these were resolved within a few hours.
So now, all thoughts are to the future. We have quite a few goodies in the pipeline including deployment tools and more hooks and integration with third party systems. The feedback we've been getting has been extremely encouraging and I'd urge anyone with an opinion or suggestion to get in touch with us over on our support tender.
- Server infrastructure (don't underestimate the size of that job)
- Subversion now running V 1.6.3
- Trac running V 0.11.4
- MVC Control Panel now on V 2 (hallelujah)
- Support system now upgraded
So, the first week is nearly over and we haven't had the flood of support tickets we were expecting. There have been a few issues to smooth out, notably with billing (or the lack of it - sorry but that couldn't last forever) and the public site. A handful of users reported some connection issues to begin with, but these were resolved within a few hours.
So now, all thoughts are to the future. We have quite a few goodies in the pipeline including deployment tools and more hooks and integration with third party systems. The feedback we've been getting has been extremely encouraging and I'd urge anyone with an opinion or suggestion to get in touch with us over on our support tender.
Memory leaks and network interfaces
Beta testing is approaching completion now, which is a huge source of relief and excitement at myVersionControl.com. We are currently writing the import scripts which will upgrade all our clients to the latest version of myVersionControl and will be writing to all our clients shortly to inform them of what to expect with the new system.
The new subversion servers are zipping along at high speed now with no reported problems however this was not always the case. Infrequently, when doing long checkouts of repositories with many subdirectories we started receiving the following type of error messages:
svn: REPORT request failed on '/svn/repo/!svn/vcc/default'
svn: REPORT of '/svn/repo/!svn/vcc/default': Could not read chunk delimiter: Secure connection truncated
We are used to subversion 'just working'! So this was a source of great consternation and would prevent us from going live with the new servers. After much research we found that it was down to a memory leak in mod_dav_svn which is the subversion module for Apache. It appears that the 'path based authorisation' feature leaks memory, consuming resources that will eventually take Apache down.
myVersionControl do not use the path based authorisation feature. We prefer the use of post and pre-commit hooks to control access as we have much more control over the process this way. This meant that we could switch off that feature with a simple: "SVNPathAuthz Off" directive in the Apache configuration files.
On a completely different note we recently found out that our new 1and1 servers had been set up with only 10Mb/s connection to the network! Found this out by chance when trying to move large amounts of data between servers and was only posting 1000Kb per second! Forcing the cards using ethtool had no effect so we have left this up to the 1and1 engineers who are on the case as I speak! Just goes to show - take nothing for granted!
The new subversion servers are zipping along at high speed now with no reported problems however this was not always the case. Infrequently, when doing long checkouts of repositories with many subdirectories we started receiving the following type of error messages:
svn: REPORT request failed on '/svn/repo/!svn/vcc/default'
svn: REPORT of '/svn/repo/!svn/vcc/default': Could not read chunk delimiter: Secure connection truncated
We are used to subversion 'just working'! So this was a source of great consternation and would prevent us from going live with the new servers. After much research we found that it was down to a memory leak in mod_dav_svn which is the subversion module for Apache. It appears that the 'path based authorisation' feature leaks memory, consuming resources that will eventually take Apache down.
myVersionControl do not use the path based authorisation feature. We prefer the use of post and pre-commit hooks to control access as we have much more control over the process this way. This meant that we could switch off that feature with a simple: "SVNPathAuthz Off" directive in the Apache configuration files.
On a completely different note we recently found out that our new 1and1 servers had been set up with only 10Mb/s connection to the network! Found this out by chance when trying to move large amounts of data between servers and was only posting 1000Kb per second! Forcing the cards using ethtool had no effect so we have left this up to the 1and1 engineers who are on the case as I speak! Just goes to show - take nothing for granted!
Subscribe to:
Posts (Atom)