coldtobi's blog

• Main
• Archives
• Albums
• Links
• Admin

• Blog and Website [94]
• DSL RAM [2]
• Electronics and Atmel AVR [11]
• fanctrl [3]
• General [8]
• German [1]
• La Fonera [22]
• Lifetype [17]
• Linux / Debian [33]
• Monetizing A Blog [8]
• my 2 cents [15]
• Netzfunde [18]
• Nice Links [1]
• solarpowerlog [2]
• Thecus N2100 [16]
• Tips and Tricks [18]

• N2M: parallel build dpkg-buildpackage and pdebuild
• Windows CE: Assertion failed in wincore.cpp line 1034
• CakePHP: Baking a Application in Minutes
• Enabling InnoDB support in debian (MySQL)
• Flattr.
• Pollin Net-IO PHP Library
• Link to safe

• RSS 0.90
• RSS 1.0
• RSS 2.0
• Atom

• Privacy Policy
• Disclosure Policy

The Moving Experience.

Well, now it is time for a resume. As you can read this, the blog is online and AFAIK it is (mostly) working. For the things that are not working, I simply did not find time to analyze why it does not work.

More accurate would be, however, that it is now working again. The new owner of my hosting company schedued the move of the server on the lastSaturday @ 3pm MET. It started actually a little later, and finished about thee hour later. At least, three hours later the domain names resolved to the new IP, and some services where actually available again.

The first thought was to write an update to this article, announing the "mission acomplished".  Well, entering the URL of this blog's admin site, revealed the first problems: "Internal Server Error".

Looking at more services running at my site, I discovered that more services were not working correctly: Perl was down, other PHP/SQL-based scripts failed with some nasty errors, and some more basic services were not functioning.

As some minutes later the Perl services came live again, I thought about not-really-completed-move and decided to wait for the next day to evaluate if the problems are still persistent.

The next day came, and the very first thing I did this day was checking the state of my site. "500 Internal Server Error".. Damn.

Googling about my server revealed, that there is also a blogger on the same server, telling in an article about the move, that his move workes. So I called customer support -- I supposed there is someone in the support centre, as they also planned moving server on this day, even it was Sunday.

Compliments to this service! The guy figured out the problem -- almost instantly! While moving the server, the changed also the settings of this server, "to improve security", as the man on the other side phone underlined. This also implied, that the disabled apache2's mod_rewrite, a needful thing in my lifetype's blogging plattform. 

But activating the rewrite module for my account didn't bring it back to life. Still an internal server error. But the culprit was also found very fast: liftype is using Files sections in the .htaccess. like this example:

<Files post>
ForceType application/x-httpd-php
</Files>

This was causing the problems: The server does not accept this modifications in the .htaccess, and was bailing out the 500s. Uncommenting brought finally the server up again.

Another issue was (but not related to the lifetype), that they are not using mod_php anymore,  but using suphp. suphp has the advantage, that the scripts are actually running with the (script-file) owner's username and not anymore under the identity of the system user "www-data", which has the disadvantage that all script-created files has also this ownership. As the data was synced to the new server, this files retained their ownership of www-data, which made them inaccessible by the (now running under a differnt user) scripts. But thats nothing a chown -w could now fix.

So the state of all the (visible) services are, that they are now up again.

As a summary, I worked, but it could have been planned better. So if you are a hoster planning to do such a move, please, consider these basic points:

1. PLANNING: Please announce your schedule some more time in advance. At least more then (exactly) 20 hours and 19 minutes ahead of the "scheduled" moving time. You announced this in June, but without any concrete time frame. This is not a schedule at all.
2. PLANNING: Tell your customers, what you are planning to change.If you introduce changed that severe, PLEASE, tell us, your customers. "Some security improvements" are not really capable -- for serious webmasters -- to determine if there are any troubles on the horizon. MAYBE you turn your server on some days prior with your desired configuration, and let your customers try out your configuration, to see if there are problems to be expected. 
3. PLANNING: Moving *Three days* before the old servers are switched is admireable. I couldn't be that cool hoping that everything will work that fine. 
   

Howver, your fast response on the phone saved you definttly some points.