Already the topic sounds like self flagellation, but what wouldn't you forced by customers? On this system we are housing customers we did inherit with a company fusion (dont ask more details).
On Sunday morning our box for vhosting Sites with FP-extentions was beginning rebooting every 20 - 30 minutes. In the evening the box was finally offline. Monday morning I did hit the CoLo and the box was running but not responding. So I unplugged it and kicked it in the car boot.
Opening the box didn't make me happy ... scsi devices from the last millenium. :(
I decided to copy the system over to actual discs, so plugged a scsi controller I found somewhere in the labs into a new system and copied all the stuff to new hdd. After that I returned the scsi discs into the fscked system and got it running somehow. It was surprising me, that it only reboots one time at the beginning spontaneously. After that it was running well.
I did stop the FTP-Daemon and the ability to upload with FP (to keep the userfiles in sync with the copy on the new disks).
Now it was time to update the system on the new disks from woody to sarge .. which wasn't really tricky .. I also replaced the Apache 1.3 with 2.0 and ProFTPD with vsftpd. Also the settings of apache and php was more restricted and some other userland stuff. After 2 hours the system was on sarge and more secured since it ever was.
At this point only FP wasn't working ... so I searched around and found a site which was focused on this topic.
I did download the FrontPage 2002 Server Extensions for Unix, Service Release 1.2 and the fpprep.sh
script.
The installation of FP worked this way:
# aptitude install apache2-prefork-dev
# fpprep.sh install
# fp_install.sh
# fpprep.sh restore
Okay ... now I enabled FP:
# echo "LoadModule frontpage_module \
/usr/lib/apache2/modules/mod_frontpage.so" \
> /etc/apache2/mods-available/frontpage.load
# a2enmod frontpage
# /etc/init.d/apache2 restart
Since FP needs all the apache config in one file and on Debian sarge its splitted into small pieces, I used with all calls of owsadm.exe
/etc/apache2/httpd.conf.fpse
(which was created by fpprep.sh
) as apache config file. Our vhost configs are created by a home brewed script and placed info /etc/apache2/sited-available
. To make FP happy, I modified it, to make also some rudimentary vhosts into /etc/apache2/httpd.conf.fpse
. After that, the script is running
# /usr/local/frontpage/version5.0/bin/owsadm.exe -o install \
-t apache-2.0 -u $ADMLOGIN -pw $ADMPASS -xu $ADMLOGIN \
-xg users -s /etc/apache2/httpd.conf.fpse -p 80 -m $DOMAIN
So far, (not) so good.... After one hour to figure out, how M$ Fontpage works, I did found out, that my server extensions wasn't working. I searched some hours again to realize, that it wouldn't be a good idea to run SuExec and FP together. So I did modify my vhost_add script, to not enable SuExec if FP is needed.
SuExec and FP aren't working together!
I did copy the script for making new vhosts and modified it to only generate new vhost configs for /etc/apache2/sites-available
. After that was done, I changed the IP of the b0rked system to another one and took the new online.
It was 22 o'clock on Wednesday and I started to migrate ~300 vhosts thought the migration script by hand. This makes me possible to check, if there are hosts not using FP and unused vhosts. 10 hours later all FP hosts was running. Only mod_security was needed to modify, cause my rules broke FP-upload.
Finally some of the vhosts using PHP needed register global enabled and (nearly) all was fine.