So, the clock ticked on and we arrived at renewal time for the Real Private Server [RPS] which I’ve had for a couple of years with OVH. The RPS hadn’t been performing well recently which was starting annoy me. It also didn’t help that the Release 2 operating system by OVH is based on Gentoo which fairly well excluded any possibility of me being able to tinker with it successfully.
So, after a visit to LowEndBox I decided to take out a Virtual Private Server [VPS] with MiniVPS as it seemed like an inexpensive way of keeping a web-based server box that I could tinker with and break as much as I wanted because I’d already moved all the important stuff (websites, DNS, mail, etc) elsewhere.
After picking a new domain name that I could break repeatedly I signed up with MiniVPS. Within minutes the VPS was up and running with 64-bit CentOS6. It was time to begin my introduction to CentOS6 the hard way!
First port of call, install remote administration software that would make my life easier on a day-to-day basis (everybody loves a web interface). I’d encountered Webmin before because it was installed on the OVH RPS so it seemed like a logical place to start. After some reading it seemed that I needed to install the YUM repository to accomplish my goal. Well, that was easier said than done. Not because installing the repository was difficult but because my favourite command line editor GNU Nano wasn’t installed. After a few minutes searching I hit upon
yum install nano
which after using putty to SSH into the box worked like a charm. For a follow-up the necessary repo content was added using
and after following the remaining instructions on the Webmin site. After about 10 minutes I was able to hit
yum install webmin
and voilà, job done. So far so good!
It was always going to happen.
With my current web host (OVH) when setting up my server (RPS) I chose to run it using their custom version of gentoo Linux (OVH Release 2). They offer a number of choices but this seemed like the best pick because it was their release running on their hardware so I figured it would just get the job done.
That was all fine until I went and broke it. Well, when I say broke it, I didn’t break it exactly so much as stupidly try to update it so that it would be running the latest shiny version of things.
This was out not a sensible plan and the net upshot was that I broke the portage system. Impressively though gentoo didn’t fall over despite my ineptitude and kept serving up my websites (including this one) without issue. The only thing was, I had no idea how to put things right!
So, after much tinkering behind the scenes (with gentoo still managing to keep going despite me doing my best to knock lumps out of it and wreck it completely) I managed to get things back on a proper footing, i.e. a working Release 2 running the latest patches from OVH.
Here’s what I did to fix the mess I created which I’m sharing because I thought it might be useful to other people out there who have also “tinkered” with their RPS and struggle, as I did, to read all the technical support that’s mainly found in French on the OVH RPS forums.
Disclaimer: These commands worked for me but they might not work for you so if you decide to use them backup everything on your RPS first because I’m not responsible for any commands you issue to your server!
- Firstly SSH into your RPS with root access. This will land you in the home directory.
- Run the command: echo “2.10” > /etc/ovhrelease as this will fool the OVH updater into thinking you’re running an earlier version of Release 2.
- Run: eselect profile list
- Look at the list and find the number of the profile that matches: default-linux/x86/2007.0/desktop on my RPS it was 4.
- Run: eselect profile set <> where <<NUMBER>> is the profile number you looked up at step 5, e.g. for me it was eselect profile set 4
- Remove any pre-existing upgrade scripts with: rm -rf patch-2.*.sh to make sure that you get a clean update.
- Restore and run the OVH patch-all scripts with: wget ftp://ftp.ovh.net/made-in-ovh/release/patch-all.sh -O patch-all.sh; sh patch-all.sh
- Now, that should, ditch the broken portage tree and run every automatic update script since they released 2.10. I found that this upon reaching patch 2.19 it was necessary to change the profile again.
- Run: eselect profile list again
- Look at the list and find the number of the profile that matches: default/linux/x86/2008.0/desktop on my RPS it was 9.
- Run: eselect profile set <<NUMBER>> where <<NUMBER>> is the profile number you looked up at step 5, e.g. for me it was eselect profile set 9
- Run: sh patch-all.sh
- This should finish the patches and bring you up to current which at the time of writing is 2.30.
Hopefully this will be of some use to those out there like me who just can’t help tinkering with things!