So I have a number of VPS servers with CentOS installed.
Now I'm sure Centos is fine for a lot of people but personally I just can't get on with it.
I am a .NET developer, which means I need mono.
The version of mono which ships with CentOS 5 is just too far out of date for my needs now.
And CentOS 6 doesn't seem to have mono at all?!?
So after much battling with trying to compile applications from source, trying to add redhat repositories and install mono from there, trying a number of different solutions I finally gave up and decided to attempt to switch the OS to openSUSE, which I am familar with and I know has an up-to-date mono available with all the bells and whistles that I require.
So now the big question is - how to switch the OS on a remote (other side of world) server with no physical access?
Again I have tried a number of methods most of which ended in a dead-end but the solution I settled on seems to be quite functional, while not ideal.
IMPORTANT: before doing any of the things mentioned in this article please, please, (I cannot stress this enough) PLEASE! do a backup!
Fortunately my VPS provider has a handy "re-install" OS option in case things went spectacularly bad, but I hope never to have to use it.
Also I was working on a new VPS with nothing actually running on it yet, so if I had to delete the VPS and make a new one - it wouldn't be the end of the world.
I strongly recommend that you do NOT attempt any of the following on anything that even remotely resembles a live production server.
If you choose to ignore this warning - don't come running to me!
Fortunately my VPS provider has a handy "re-install" OS option in case things went spectacularly bad, but I hope never to have to use it.
Also I was working on a new VPS with nothing actually running on it yet, so if I had to delete the VPS and make a new one - it wouldn't be the end of the world.
I strongly recommend that you do NOT attempt any of the following on anything that even remotely resembles a live production server.
If you choose to ignore this warning - don't come running to me!
OK with that (somewhat verbose) disclaimer out of the way - let's get on with it!
N.B. For all the following I wil assume that you are familiar with YAST
So SUSE has this handy feature in YAST named "install to directory".
Sadly I couldn't find any way to run yast from within CentOS.
So you need to have an existing installation of SUSE somewhere, on some other server or computer.
So the first few steps are run from an existing installation of SUSE, somewhere.
Optionally you can skip to Step 11.
- Open yast and install the package "yast2-dirinstall"
- Close yast
- Open yast again (this is necassary to load the new module)
- Under software you should now have a new entry "Installation into directory" - open this.
- Set the target directory
- Turn OFF the option to run YAST and SUSEconfig.
- Create Image: No (actually I had this on, but it didn't seem to do anything for me?)
- Set the software. At this point I recommend having a very minimal install to reduce the size of the files to be copied onto the server to be changed.
- bash
- grep
- sed
- yast2
- vim (or your favourite command line editor)
- zypper
- iputils
- Let that run for a while then quit YAST.
- Package the installed to directory into an archive and copy the archive to the server to be changed.
- You can optionally skip steps 1-10. By downloading the image I have created here: http://dev.dj-djl.com/TinySuse12.1.tgz
With a minimal software selection the installed size is almost 900MB (SUSE 12.1)
Also I think it is unlikely that you will be able to get a working X install (although I have not tried) with this method.
You will however need at least the following packages:
The following steps should be performed on the server to be changed.
- Unpack the archive somewhere sensible on your system.
Do NOT unpack it to the root directory! - Use your favorite editor to create a short script which will open the suse environment in a chroot session:
user@centos# vim runsusechrooted.sh#!/bin/bash echo "mounting dev"
sudo mount -o bind /dev tinysuse/dev
echo "mounting proc"
sudo mount -o bind /proc tinysuse/proc
echo "mounting sys"
sudo mount -o bind /sys tinysuse/sys
echo "chrooting"
sudo chroot tinysuse
echo "chroot environment closed."
echo "umounting dev"
sudo umount tinysuse/dev
echo "unmounting proc"
sudo umount tinysuse/proc
echo "unmounting sys"
sudo umount tinysuse/sys
- set the script as executable
chmod +x runsusechrooted.sh - run the script (your system may require you to run this as root):
user@centos# ./runsusechrooted.sh
mounting dev
mounting proc
mounting sys
chrooting
suse:/ # - If you get this far then you now have a successful SUSE environment running inside the parent OS.
Now the fun part begins!
At this point in the process I, at first, attempted to get the VPS to boot from the suse system, with not much luck.The first thing is we need to get a working internet connection. so:
I tried using yast within the suse system to overwrite the bootloader on the VPS.
I tried editing the grub menu from the host centos system.
Nothing that I tried would result in the VPS booting the suse system, it always booted CentOS. Unfortunately I can't even see the grub screen to see what errors may or may not be there. My suspicion is that the VPS provider is somehow skipping the bootloader and going straight into a predefined kernel.
If anyone knows a way to rig it so that the VPS can boot from the new system it would save on all the faff that follows! - Exit out of the chroot environment,copy the resolv.conf from the host, then go back into the chrooted environment:
suse:/ # exit
user@centos# cp /etc/resolv.conf tinysuse/etc/resolv.conf
cp: overwrite `tinysuse/etc/resolv.conf'? y
user@centos# ./runsusechrooted.sh
suse:/ # ping -c 1 www.google.com
PING www.l.google.com (74.125.227.51) 56(84) bytes of data.
64 bytes from dfw06s06-in-f19.1e100.net (74.125.227.51): icmp_seq=1 ttl=56 time=1.83 ms
--- www.l.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.834/1.834/1.834/0.000 ms - N.B. If you think your resolv.conf might change, you might want to try hard-linking it. I've not tested this so I have no idea how well it may work?
- Now we need to install any additional software that may be required:
- suse:/ # yast
- First open the Software->Software Repositories section and add at least the standard SUSE OSS repository by using the community repositories option. you may want to add other repos at this point too.
- Once you have done this you can install software using either yast or zipper.
Thankfully I've devised a cunning hack to get services running in suse too.
- First make sure you don't have a conflicting service running in the host environment, I chose to completely uninstall apache from the host to ensure there are no conflicts.
- user@centos# yum remove httpd
- Next configure the service in suse as normal (I used yast for the initial config, but will manually edit the config files later to suit my setup)
- finally we need a script to start the services.
suse:/ # vim chrootboot.sh
#!/bin/bash
NEW=$1
OLD=$( cat /runlevel )
[ "a${OLD}a" == "aa" ] && OLD=0
IGNORE="network halt reboot"
echo Changing runlevel from $OLD to $NEW
START=$(diff <(ls /etc/init.d/rc${OLD}.d -1 | grep "^S" | sed "s/^S[0-9]*//" |sort ) <(ls /etc/init.d/rc${NEW}.d -1 | grep "^S" | sed "s/^S[0-9]*//" | sort ) | grep "^>" | sed "s/^> //")
STOP=$( diff <(ls /etc/init.d/rc${OLD}.d -1 | grep "^K" | sed "s/^K[0-9]*//" |sort ) <(ls /etc/init.d/rc${NEW}.d -1 | grep "^S" | sed "s/^S[0-9]*//" | sort ) | grep "^<" | sed "s/^< //")
echo Stopping services in runlevel $OLD
echo ${STOP} | grep -v "^ *$" | sed "s/ /\n/g" | grep -v "$(echo $IGNORE | sed "s/ /\\\|/g")" | sed -e "s#^.*\$#ls -1 /etc/rc.d/rc${OLD}.d/K*\0#" | bash | sort | sed -e "s#^/etc/rc.d/rc${OLD}.d/K[0-9]*\([^0-9].*\)\$#/sbin/service \1 stop#" | bash
echo Starting Services in runlevel $1
echo ${START} | grep -v "^ *$" | sed "s/ /\n/g" | grep -v "$(echo $IGNORE | sed "s/ /\\\|/g")" | sed -e "s#^.*\$#ls -1 /etc/rc.d/rc${NEW}.d/S*\0#" | bash | sort | sed -e "s#^/etc/rc.d/rc${NEW}.d/S[0-9]*\([^0-9].*\)\$#/sbin/service \1 start#" | bash
echo $1 > /runlevel
N.B. You may want to disable some services to avoid them erroring when they try to start. - Now if you exit from the chroot environment at this point you will notice that the unmounting fails - this is because the services remain running (this is good!)
- But - if you reboot the host, you will also notice that the services are not started again.
- So now we need a way to start the chrooted services on system boot, and close them cleanly when we reboot.
- For this we will create a new host service.
user@centos# cd /etc/rc.d/init.d
user@centos# vim susechroot#!/bin/bash . /etc/init.d/functions #echo -e "\n\n $(date +%Y-%m-%dT%H%M%S ) $0 $*" >> /susechroot.log case $1 in start) mount -o bind /dev /tinysuse/dev mount -o bind /proc /tinysuse/proc mount -o bind /sys /tinysuse/sys mount none -t devpts /tinysuse/dev/pts chroot /tinysuse /chrootboot.sh 5 touch /var/lock/subsys/susechroot ;; stop) chroot /tinysuse /chrootboot.sh 0 sleep 1 umount /tinysuse/dev umount /tinysuse/proc umount /tinysuse/sys umount /tinysuse/dev/pts rm -f /var/lock/subsys/susechroot ;; status) chroot /tinysuse service --status-all ;; esaccd ../rc3.d
ln -s ../init.d/susechroot S99susechroot
cd ../rc5.d
ln -s ../init.d/susechroot S99susechroot
cd ../rc6.d
ln -s ../init.d/susechroot K0susechroot
cd ../rc0.d
ln -s ../init.d/susechroot K0susechroot
/sbin/service susechroot start
Now whenever we reboot the server it executes the scripts for runlevel 5 in the suse environment on startup.
So if we have, e.g. Apache installed in the suse environment and configured for runlevel 5. We can reboot the server and apache will be started with no manual intervention.
Now if anyone can work out how to use Suse's init system, rather than my custom script - please let me know!
Also just a note that it appears SUSE's and CentOS's init systems are actually quite different.
In SUSE the kill scripts live in the same runlevel directory as the Start scripts, but are only executed when there is no matching Start script in the target runlevel.
In CentOS the kill scripts live in all runlevel directories which do not have a start script.
This confusion delayed me in coming up with the above solution.
