When I check software program on Linux (a daily a part of my job), I would like to make use of a number of servers with numerous architectures operating Linux. I provision the machines, set up the required software program packages, run my assessments, collect the outcomes, and return the machine to the pool in order that others can use it for his or her assessments.
Since I do that so usually (even a number of instances a day), my first 10 minutes on a Linux server have develop into a every day ritual. When I first log right into a Linux server, I search for sure issues utilizing instructions to collect the data I would like. I will undergo my course of on this article, however please word that, normally, I will simply give the command title, so you have to to establish the particular flags for these instructions to get the data that you simply want. Reading man pages for the instructions is an efficient start line.
As quickly as I log right into a server, the very first thing I do is verify whether or not it has the working system, kernel, and hardware structure wanted for the assessments I can be operating. I usually verify how lengthy a server has been up and operating. While this doesn’t matter very a lot for a check system as a result of it is going to be rebooted a number of instances, I nonetheless discover this data useful.
Use the next instructions to get this data. I largely use Red Hat Linux for testing, so in case you are utilizing one other Linux distro, use *-release within the filename as an alternative of redhat-release:
cat /and many others/redhat-release
uname -a
hostnamectl
uptime
2. Is anybody else on board?
Once I do know that the machine meets my check wants, I would like to make sure nobody else is logged into the system on the identical time operating their very own assessments. Although it’s extremely unlikely, provided that the provisioning system takes care of this for me, it is nonetheless good to verify now and again—particularly if it is my first time logging right into a server. I additionally verify whether or not there are different customers (aside from root) who can entry the system.
Use the next instructions to seek out this data. The final command appears for customers within the /and many others/passwd file who’ve shell entry; it skips different providers within the file that should not have shell entry or have a shell set to nologin:
who
who -Hu
grep sh$ /and many others/passwd
three. Physical or digital machine
Now that I do know I’ve the machine to myself, I have to establish whether or not it is a bodily machine or a digital machine (VM). If I provisioned the machine myself, I may make certain that I’ve what I requested for. However, in case you are utilizing a machine that you simply didn’t provision, it is best to verify whether or not the machine is bodily or digital.
Use the next instructions to establish this data. If it is a bodily system, you will notice the seller’s title (e.g., HP, IBM, and many others.) and the make and mannequin of the server; whereas, in a digital machine, it is best to see KVM, VirtualBox, and many others., relying on what virtualization software program was used to create the VM:
dmidecode -s system-manufacturer
dmidecode -s system-product-name
lshw -c system | grep product | head -1
cat /sys/class/dmi/id/product_name
cat /sys/class/dmi/id/sys_vendor
four. Hardware
Because I usually check hardware linked to the Linux machine, I often work with bodily servers, not VMs. On a bodily machine, my subsequent step is to establish the server’s hardware capabilities—for instance, what sort of CPU is operating, what number of cores does it have, which flags are enabled, and the way a lot reminiscence is accessible for operating assessments. If I’m operating community assessments, I verify the sort and capability of the Ethernet or different community gadgets linked to the server.
Use the next instructions to show the hardware linked to a Linux server. Some of the instructions may be deprecated in newer working system variations, however you possibly can nonetheless set up them from yum repos or change to their equal new instructions:
lscpu or cat /proc/cpuinfo
lsmem or cat /proc/meminfo
ifconfig -a
ethtool <devname>
lshw
lspci
dmidecode
5. Installed software program
Testing software program all the time requires putting in extra dependent packages, libraries, and many others. However, earlier than I set up something, I verify what’s already put in (together with what model it’s), in addition to which repos are configured, so I do know the place the software program comes from, and I can debug any bundle set up points.
Use the next instructions to establish what software program is put in:
rpm -qa
rpm -qa | grep <pkgname>
rpm -qi <pkgname>
yum repolist
yum repoinfo
yum set up <pkgname>
ls -l /and many others/yum.repos.d/
6. Running processes and providers
Once I verify the put in software program, it is pure to verify what processes are operating on the system. This is essential when operating a efficiency check on a system—if a operating course of, daemon, check software program, and many others. is consuming up a lot of the CPU/RAM, it is sensible to cease that course of earlier than operating the assessments. This additionally checks that the processes or daemons the check requires are up and operating. For instance, if the assessments require httpd to be operating, the service to begin the daemon won’t have run even when the bundle is put in.
Use the next instructions to establish operating processes and enabled providers in your system:
pstree -pa 1
ps -ef
ps auxf
systemctl
7. Network connections
Today’s machines are closely networked, and they should talk with different machines or providers on the community. I establish which ports are open on the server, if there are any connections from the community to the check machine, if a firewall is enabled, and in that case, is it blocking any ports, and which DNS servers the machine talks to.
Use the next instructions to establish community services-related data. If a deprecated command isn’t out there, set up it from a yum repo or use the equal newer command:
netstat -tulpn
netstat -anp
lsof -i
ss
iptables -L -n
cat /and many others/resolv.conf
eight. Kernel
When doing techniques testing, I discover it useful to know kernel-related data, such because the kernel model and which kernel modules are loaded. I additionally checklist any tunable kernel parameters and what they’re set to and verify the choices used when booting the operating kernel.
Use the next instructions to establish this data:
uname -r
cat /proc/cmdline
lsmod
modinfo <module>
sysctl -a
cat /boot/grub2/grub.cfg
9. Logs
By now, I’ve a good suggestion concerning the server, together with what software program is put in and what processes are operating. One different factor I can’t escape is log information—I have to know the place to verify the data that’s repeatedly being up to date.
Use the next instructions to see your system’s logs:
dmesg
tail -f /var/log/messages
journalctl
Next steps
While instructions and utilities will change, the underlying data they present stays kind of the identical. You want a high-level view of the data you might be in search of and what class it falls into earlier than you possibly can deal with which instructions to grasp.
Since Linux saves most data in information, these instructions principally learn data from the information and current them in an easy-to-understand method. A superb subsequent step is to establish the information every command makes use of to get the data to show. A touch for locating that data is the strace command.
