Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have an old dedicated server running an out of date version of Fedora Core. As a result of the age of the distro, its repositories are no longer maintained, so the software on the server is getting badly out of date, and I would like to bring things current to avoid security risks.

Since this is the only server of a small public-facing ecommerce website, I'm trying to minimize downtime - an hour or two I can tolerate if it's during a low access period, but I don't have hardware access to the machine, so wiping it and installing a new distro would likely result in extended downtime during a peak time while the non-emergency support people are in.

What are my options here to get it up to date?

Things I've looked at so far:

  1. In-place distro upgrade by pointing yum to newer servers.
  2. Set up a short term VPS, and bring the site online there as a temporary host while the main server is down, using DNS with a short TTL to cut over from one server to the other.

First option just seems messy, and like it's a failure waiting to happen. I like the sound of the second option in that it seems to be a clean way to do it, plus it means I can ditch Fedora and go to CentOS. However, it will be a lot of work cleaning up the site code to make it portable. This needs done anyway and will be my long term solution, but it will take time, during which the main server is vulnerable. Is there anything I can do in the short term to mitigate the threat to the server until I have the time to arrange a proper switchover?

share|improve this question
add comment

4 Answers

up vote 3 down vote accepted

First of all i think you need to access the security threats on your current linux install you can find that out here, maybe its not as bad as you think but until you have audited your setup it is difficult to gauge. The problem with fedora is it is very bleeding edge. A move to centOS in the long run is a very good idea. I would suggest setting up a VM somewhere with a centOS install and trying your site and seeing exactly what breaks. It is quite possible that is not as bad as you imagine (ok i seem to be saying that alot in this answer..). If you can get this site working change the DNS to point to the new centOS site and then replace the server mirroring the setup.

share|improve this answer
    
Thanks for the link. Main concern with the porting is a lot of hardcoded URLs and paths that I need to change out to a more adaptable version so that I can run it under a subdomain (www2 or such) for testing - aside from that, there's nothing particularly OS dependent. –  matthock Oct 6 '09 at 13:39
add comment

Rough Plan

  1. Backup the website first!

  2. Change your DNS to short TTL.

  3. Build the new website on the new server with something like www2.example.com

  4. TEST IT WELL to make sure you're ready for the changeover.

  5. Change your DNS over to the new site.

  6. Keep the old site around for a while... just to be 100% safe.

Note: When I say "new site" and "new server" what I really mean is some separate isolated instance from the main one. Virtual machine, different machine, different distro, whatever works for you. The idea is to build your new site, bring it up to date, patched, secure, and then switch over to it. I'm not a big fan of keeping "insecure/dead weight" on the network.

share|improve this answer
    
Good plan on the DNS TTL! –  Nerdling Oct 6 '09 at 0:40
add comment

Of the two I would recommend the second option, or a mix of the two: use the VPS to hold and run the site while you upgrade the main machine.

Upgrading a distro that old may mean upgrading through a couple of versions (as a direct upgrade between that version and the latest may not be a supported operation) so as well as the advantage of leaving you with a nice clean system to start off from again rebuilding from scratch with the up-to-date distro release may actually be noticable quicker and easier than the upgrade option.

Which ever way you go, make sure you take a full backup of the original machine, even if you think everything has transferred OK to the VPS, just in case you have missed some setting/script/data that you don't notice now but will discover you need in a few weeks time and you wish you'd kept a second copy of.

As well as using a short TTL for DNS settings, I also recommend running forwarders (rinetd will do for most TCP protocols such as HTTP(S) which may be all you need, you'll need something more clever like a full NAT or VPN arrangement to handle other types of traffic too) form the old machine to the VPS for a while to cover DNS propagation time, and the same on the VPS when moving back to the main server. This means that even if there are ISPs out there with badly configured DNS caches that don't respect short TTLs (and there are in my experience) you'll still not lose those visitors. This does mean leaving both machines running along side each other for longer (I'd suggest at least an extra day for both switches), but is worth it if your site is making money.

share|improve this answer
    
Thanks for the comment on rinetd - hadn't heard of that before, that's a good idea as a backup for DNS servers that ignore short TTLs. –  matthock Oct 6 '09 at 13:42
add comment

I think the best you can do here is some basic hardening of the server you have until you can provision a replacement. Disable any network accessible services that aren't required for your application, assuming you are using apache disable modules you aren't using and maybe go through a doc like the CIS Security guide. You say it's a shopping cart web site, that probably implies apache/mod_ssl are the only network accessible services (and ssh but that can be restricted to only be allowed from wherever you are doing management). I would take a look at security vulns published for apache and openssl from the time these were last updated, weed through the ones that don't apply to your configuration and try to mitigate the ones that do. That just leaves your shopping cart software as a source of problems, ideally its dependancies won't be terribly OS specific so you may be able to update it independently of moving the whole thing to a more supportable OS.

None of this is a guarantee that you won't get popped, or that you haven't already had trouble that you just aren't aware of yet, but it's probably the best you can do with the tools that you have.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.