1

I'm not a system administrator by training, so I've been learning things as I go along. Bear with me in my lack of knowledge. :)

I've been tasked with analyzing one of my employer's servers. It's running CentOS, and its main function is to serve as our organization's package repository for various package managers (RPM, DEB), but it has other functions too. Trouble is, it's so old that no one knows exactly how it's configured...

We're going to need to move this server to a new physical machine, and so I've been asked to figure out how it's configured, what's running on it, etc. I know that's a rather ambiguous definition, and that I'll for sure miss things, but I'd like to do as thorough a job as possible.

My question is, what areas should I be checking? How would you go about replicating a machine's configuration and environment if you didn't have any prior knowledge about it. Here are some I can think of:

  • Cron Jobs
  • Installed packages
  • Running services

p.s. I'll of course be automating the configuration of everything I can once I can figure out this server, so that this won't happen to the next guy after me.

Improve this question
2
  • I understand this situation. However, it's really hard to give an answer that will be complete and useful - basically the question boils down to "take all your experience and boil it down to a checklist", which is really not possible. But you've got the main things already in your question; I'd add that identifying the people using it and asking them to verify that the new server functions as well as the old is imperative. Also keep the old server around for a while, or at least a tar backup of it, to help in fixing any problems.
    – Jenny D
    Apr 20, 2013 at 14:33
  • Yeah I definitely understand that it's impossible for anyone to tell me exactly how to replicate my server, since there's so much variability. I did want to make sure I wasn't missing anything major that is generally common-knowledge across server environments.
    – dsw88
    Apr 22, 2013 at 15:30

3 Answers 3

Reset to default
2

To start, I would get as much information as possible about the server running state.

What are the running processes?

# ps aux

What is the network configuration?

# ip address
# ip route

Do we have listening processes?

# netstat -lp

What are the used files?

# lsof

What are the installed packages?

# rpm -qa

Maybe some firewall rules?

for t in `echo "mangle nat filter raw"`
do
  echo ">> $t"
  iptables -t $t -nvL
done

Among the interesting folders, you have:

  • /etc, where most of the system configuration is saved.
  • /home, some services can use this folder to store data.
  • /opt, third party applications can be installed there.
  • /root, administrator's home folder, can contain useful scripts.
  • /srv, standard folder for services data.
  • /usr/local/{bin,etc,sbin,*}, can contain locally installed files.
  • /var/log, can give useful information about what's running on the system.

With that you should have a first idea of what's running your server.

Improve this answer
1
  • Thanks this is really valuable information. I know I won't catch everything, but this helps tremendously.
    – dsw88
    Apr 22, 2013 at 15:32
2

A good start is to use Blueprint to reverse-engineer the system. This will pull package, installation and some basic configuration information.

Also, since this is a CentOS/Redhat system, take a look at the installation file in /root/anaconda-ks.cfg. That will give you some ideas on the system's initial installation options.

Improve this answer
1
  • Thanks for the tip to use Blueprint, I didn't know tools like that existsed! I'm clearly in the dark still about a lot of things, but I'll learn as I go. I think I'll give Blueprint a spin!
    – dsw88
    Apr 22, 2013 at 15:32
1

The three things you mention are a good start. I would also do:

  • rpm -V $(rpm -qa) to see what was changed in installed packages
  • find /[belmosuv]* | xargs -n1 rpm -q --whatprovides | grep 'not owned' to find files installed without a package manager
  • Back up at least /home and /root (hence excluded from the find above), preferably the entire machine so you can always find the bits you will inevitably miss
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .