Hello, I’m yuno.
As an infrastructure engineer, I aim to document my exploration of Linux, Ansible, Python, Excel, and beyond. In this post, I am starting a series focused on practical Linux server operations and maintenance titled “Putting what I studied for LinuC Level 1 to use on an actual Linux server.”
Through my studies for LinuC Level 1, I learned various Linux commands such as top, free, df, ps, systemctl, ss, ip, and ping. However, I pondered their actual sequence of use on a real Linux server.
For instance, if tasked with checking if a server is running normally, several questions arise: where do I start? After checking the CPU, what next should I verify? Is checking the service state with systemctl sufficient for a web server, or should I go further by accessing the web page?
To bridge the gap between knowledge and application, I decided to perform a daily inspection to establish a normal state on my home setup.
For these checks, I will use an Ubuntu Server built on VirtualBox with the following machines:
Connecting from the controller to the tokyo server via SSH, I would check everything step by step, without automating the process with tools like Ansible at this stage. My goal is to execute the commands manually and understand their significance.
First, I connected to the tokyo server:
ssh tokyo@192.168.56.11After connecting, I verified the hostname:
hostnameThe output confirmed it was tokyo. I also checked the IP address:
hostname -IThis revealed 192.168.56.11 among other addresses. Confirming the server’s identity is vital, especially when many servers may have similar configurations, ensuring I operate on the correct one.
I ran uptime to get an overview:
uptimeThe result indicated:
22:44:44 up 15 min, 1 user, load average: 0.04, 0.34, 0.70This revealed that the server had been up for 15 minutes, with one logged-in user and load averages across 1, 5, and 15 minutes. To assess these load averages, I executed:
nprocThe output showed that the server had one CPU assigned. This highlighted the importance of correlating load averages with the number of CPUs, deepening my understanding beyond memorization.
Next, I executed top:
topThe output showed 115 tasks with significant CPU idle time at 99.2%. The absence of zombie processes and I/O wait reinforced that the server was under minimal load. This approach of analyzing various metrics simultaneously illuminated the comprehensive view top provides on server health.
To gain more clarity on memory, I used:
free -hResults returned values indicating available and used memory. Observing only 227MiB free from nearly 1GB raised concerns, but recognizing that Linux uses free memory for caching clarified that the available memory (582MiB) was indeed sufficient.
Next, I examined disk usage:
df -hThis command indicated a 25% disk usage for the root filesystem. I learned that knowing disk usage is inadequate; it’s crucial to ascertain which filesystem is filling up, which adds depth to my understanding of storage.
Since the tokyo server runs nginx, I checked its status:
systemctl status nginxI confirmed it was loaded, enabled, and running. The distinction between "enabled" (set to start at boot) and "active" (currently running) became more evident through practical application.
I also checked the nginx process:
ps aux | grep nginxThis confirmed the presence of both the master and worker processes. Understanding that systemctl and ps can be leveraged together highlighted interconnectedness in server checks.
To confirm if nginx could accept HTTP requests, I executed:
sudo ss -lntp | grep ':80'The output showed it was actively listening on TCP port 80, which was promising.
To further validate, I utilized:
curl -I http://localhostThe result of HTTP/1.1 200 OK confirmed that nginx was responding properly to requests.
Finally, I checked the access logs:
sudo tail -n 20 /var/log/nginx/access.logThis showed my previous curl request registered correctly in the logs, cementing that all connections led back to a single workflow.
I expanded my checks to network status:
ip addrThis confirmed the 192.168.56.11/24 was properly configured. I followed this by testing connectivity to the controller with:
ping -c 4 192.168.56.10Receiving responses without any packet loss reaffirmed network accessibility.
Through this daily inspection, I employed a variety of commands, such as hostname, uptime, top, free, df, systemctl, and ping, all of which formed a comprehensive operational check fundamental in LinuC Level 1.
The most significant lesson learned was the process of connecting checks systematically, allowing for clearer situational understanding.
Next, I intend to cause failures within a controlled environment to see how the checks change and what commands can be employed to address issues effectively.
I look forward to sharing more as I navigate this journey into practical Linux server management!
ChicagoVPS is your gateway to unparalleled hosting solutions. Our state-of-the-art datacenters and powerful network ensures lightning-fast speeds and uninterrupted connectivity for your websites and applications. Whether you’re a startup looking for scalable resources or an enterprise in need of enterprise-grade hosting, our range of plans and customizable solutions guarantee a perfect fit. Trust in ChicagoVPS to deliver excellence, combining unmatched reliability and top-tier support.
For Inquiries or to receive a personalized quote, please reach out to us through our contact form here or email us at sales@chicagovps.net.
