How do you work with old servers?

Question

I've recently fallen into doing more work on LAMP servers, which is pretty new to me. At first it wasn't a problem migrating my preference files, but as I've grown and learned more, my preferences and workflow has become more specific (and less portable*). This morning I was asked to work on an old Red Hat 4 server and it's... it's just so old I don't know what to do with it. Vim 6? Everything installed through RPMForge? Can't even install tree without having to add repositories? No actual user accounts except root? /sbin/ and /usr/sbin/ aren't even in the root user's path?

This thing was installed once and never modified. Every installed package is from the ice age. The first ice age.

So what do you do in this situation? Should I even bother trying to work on on the server, or is there a better way to go about this?

* - really the only thing that broke is support for the Jellybeans color theme, and my usage of Vim tabs.

edit - I guess the way I posed it was unclear, but the emphasis in the question should be on you. What I'm really trying to get a sense for is what other people would do in a similar situation.

Remember: I'm consulting. It's not my job to reinstall the server. It's not my job to do a security audit and harden the server. It's my job to take vague requirements from a non-technical client running a very old server and make them happen in as little time as possible. That's it.

I'm a developer, not a sysadmin; it's all pretty new to me, and getting it up to speed properly would take more time than I can afford to spend. It's been in production for years; I'm just making modifications.

Do I want this server to be improved? Of course! Would I want this project to be something I'm proud of? Yes! Is that going to happen? No. I'm maintaining old software that I have zero interest in that doesn't even receive a lot of traffic. I just want to do the task in a comfortable way without too much hassle.

edit 2 - after a bit of searching and fiddling around, I eventually mounted what I need locally with sshfs and MacFuse. That way I can stay in the terminal and use a mix of local and remote tools based on what I'm doing.

Answer 1

You should understand how to use common(ish) unix tools. vim may have changed between redhat 4 and redhat 300, but I bet you vi is the same (even if they are using vim as a replacement for vi, the vi commands will work as expected). The package tools may not be familiar to you, but I bet you can still download a tgz file, ./configure, make, sudo make install it.

Learning on the latest and greatest is great, but you should also learn the tools your tools are built on. There are things in unixland which remain fairly constant, and if you know and understand how to work with them, you will find yourself more at home on any variant you end up on, regardless of age (within reason here people).

Tree's not installed? I bet grep, find, awk, and sed are. These are your friends.

As an alternative to cygwin/etc, it's not hard to install VirtualBox and setup a Linux box in a virtual environment that you can then use for your development, and push files out to the server later.

Answer 2

Enter "you damn kids" mode.

Your tools should help you do your job more efficiently, without preventing you from understanding what is going on. Really, RH 4 is not that old, and mostly similar to what is around today. It might not have the latest and greatest, but should be sufficient to do what you need (what is it that you need).

Rant over.

On the other hand, if this is going on the net, it really needs to be updated with at least the latest RH 4 packages.

Answer 3

Most service professionals eventually reach a point where they are comfortable telling clients "Your current setup is wrong/dangerous. I'm not going to touch it without making it right."

While it might or might not be legally or morally accurate, from a practical point of view, nontechnical people are going to blame the last person who worked on a system that fails. If you're the last person who even logged in to a server that gets compromised or that stops working, you're likely to be blamed for the failure, even if the things that you changed (or just looked at) have nothing to do with the failure.

This is more obvious with physical things (imagine going to a tire store with bald tires and asking to have the bald tires patched, or going to a brake shop with all 4 wheels' brakes bad, and asking them to fix just 1 wheel's set; or asking the gas company to relight the pilot light on a dangerously rusted water heater) the same principles and considerations apply with software and servers.

It sounds like your client has at least two problems: an unmaintained server environment, and they've got the development and production environments operating on the same physical hardware, so it's not possible to modify one without affecting the other.

If you pretend that's a reasonable way to run things, you'll be expected to fix it when it blows up, and you'll probably be expected to do it for free because it's obviously your fault that it failed at all.

To directly answer your question, I'd tell the client that their shared hardware system is a problem that needs to be fixed, and that the unmaintained server environment is so old that it's cheaper to pay you to move their existing data to a new system versus tracking down all of the changes and dependencies necessary to upgrade the old system. They should (a) get new hardware to run the development system, and (b) install up-to-date software on the new hardware, and then migrate development to that new hardware. The bonus that you get for fixing the shared hardware problem is that you can test the new dev environment prior to making the move, which should make for a more graceful transition.

Answer 4

Your choice is to either go in a update all the packages and add new repositories or just backup the data and sites and reinstall the server.