Linux – How to inventory what software/roles a Linux server is “serving up” to clients

linux

Is there a way to identify what "client/server" processes/applications are running on a Linux server to know what the server's role or roles are?

I'm sure it might vary for different flavors of Linux and might be easier on some than on others.

As an admin, recently I've inherited a few Linux servers during an acquisition. I can tell they are running SAMBA, but beyond that I don't know where to look to find what kinds of software they might be serving up to various clients. In the Windows world I can sort of tell by the services that are running, the software that is installed, open ports, etc. Is there a decent way to do something similar in the Linux world that would help people like me determine what all the server does from a client/server role perspective?

Best Answer

Sure, there are a few good ways to get started.

One is to check out what ports are listening and open as you mentioned. For that I'd suggest one or more of the following:

lsof -i
netstat -lnp
nmap localhost

All give roughly the same information.

You could also consult the local firewall configuration for clues. For that look at:

iptables -L -n -v

You could also check who has been logging into the system and talk with those users. To do that, check:

last
who
w
finger

You might query the local package management system to determine which packages are installed. For example, on a RedHat style RPM system you could run:

rpm -qa --last

I'd suggest consulting any existing documentation. With any luck, the previous administrator has put something together.

Related Solutions

Linux/Unix – Recommended Tool to Track Server Changes

I've got etckeeper on my personal workstation, but I've not had to do much with it yet (other than have it track all my changes). Seems like it does a reasonable job of making sure you at least know what's been fiddled with.

I wouldn't write off Puppet as a solution -- as long as some of the services on the machine are your responsibility to maintain, then a system that makes sure that if someone jiggles your config that it gets put back the way you want it is a godsend.

On the other hand, if others make changes regularly (and they don't usually screw it up), you might have to resort to just tracking what other people have done for later disaster recovery. Don't forget that things will be changed all over the place, so a full-machine checkpoint tool might be better. I'd perhaps even consider going full-disk incremental backup on it (like rdiff-backup or something) to be sure you're tracking everything (maybe drop /home and other user-level areas out of the backup, if you just want to track administrative changes).

Linux Server Performance – What Limits Maximum Number of Connections?

I finally found the setting that was really limiting the number of connections: net.ipv4.netfilter.ip_conntrack_max. This was set to 11,776 and whatever I set it to is the number of requests I can serve in my test before having to wait tcp_fin_timeout seconds for more connections to become available. The conntrack table is what the kernel uses to track the state of connections so once it's full, the kernel starts dropping packets and printing this in the log:

Jun  2 20:39:14 XXXX-XXX kernel: ip_conntrack: table full, dropping packet.

The next step was getting the kernel to recycle all those connections in the TIME_WAIT state rather than dropping packets. I could get that to happen either by turning on tcp_tw_recycle or increasing ip_conntrack_max to be larger than the number of local ports made available for connections by ip_local_port_range. I guess once the kernel is out of local ports it starts recycling connections. This uses more memory tracking connections but it seems like the better solution than turning on tcp_tw_recycle since the docs imply that that is dangerous.

With this configuration I can run ab all day and never run out of connections:

net.ipv4.netfilter.ip_conntrack_max = 32768
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_orphan_retries = 1
net.ipv4.tcp_fin_timeout = 25
net.ipv4.tcp_max_orphans = 8192
net.ipv4.ip_local_port_range = 32768    61000

The tcp_max_orphans setting didn't have any effect on my tests and I don't know why. I would think it would close the connections in TIME_WAIT state once there were 8192 of them but it doesn't do that for me.

Best Answer

Related Solutions

Linux/Unix – Recommended Tool to Track Server Changes

Linux Server Performance – What Limits Maximum Number of Connections?

Related Topic