Q.) How can I detect if I'm inside a containerised environment?
Q.) A developer's testing program is filling up disk space with a log file named /var/log/problem.log. It is no longer required. How can you identify and resolve this issue to free up disk space?
Q.) How will you check / display the status of the network bond configured in the RHEL server ?
Level - L2 and above.
I'll be posting a series of Linux-related questions covering various skill levels. Feel free to share your insights and expertise. Your contributions will benefit learners at all stages, from those in current roles to those preparing for Linux interviews.
Looking at that first question:
Q.) How can I detect if I'm inside a containerised environment?
I'm going to take the easy (lazy man) route on responding to this query.
Running the virt-what shell script will inform me as to whether or not I'm
operating inside a container.
Per the manpage for the virt-what shell script:
If nothing is printed and the script exits with code 0 (no
error), then it can mean either that the program is running on
bare-metal or the program is running inside a type of virtual
machine which we don't know about or cannot detect.
Looking at the content of the shell scirpt itself, you will be able to
see how the shell script is doing all of the heavy lifting, that we would
be required to do otherwise. It's certainly nice to know what goes on
behind the scenes, but sometimes you just want to accomplish the
mission!!!
Another little goodie that can be used is a systemd family member:
systemd-detect-virt
Per the manpage of the systemd-detect-virt command:
systemd-detect-virt detects execution in a virtualized
environment. It identifies the virtualization technology and can
distinguish full machine virtualization from container
virtualization. systemd-detect-virt exits with a return value
of 0 (success) if a virtualization technology is detected, and
non-zero (error) otherwise. By default, any type of
virtualization is detected, and the options --container and --vm
can be used to limit what types of virtualization are detected.
Again, I'm not trying to reinvent the wheel, or do any extra work if I
don't have to. There's a utility here to assist me, and I'm going to
take advantage of it's existence!
I'm kinda partial to anything associated with systemd - my prejudice
is showing, I know!!!
The virt-what shell script may not be installed on your system by default,
but I'm sure the systemd-detect-virt file is there. However, if you want
to have the virt-what shell script as backup, you're certainly able to install
the package that it resides in.
Okay, that's all I got for this episode.
On that 2nd question, I know there's something that I'm missing
because, if I know the name of the file (which means it's already
identified), and I know it's filling up my disk space, and I know it
is no longer required, I'm simply going to delete it.
The question has provided me the name of the file, and that the
file is no longer needed. Okay, what am I missing
@Trevor to rephrase the problem statement : There is a program that is being running and continuously filling up the disk space by writing to the /var/log/problem.log . Now, as an admin you have a go ahead to resolve this error. Deleting the log file will not help as the program will recreate it and start refilling it.
Q.) How will you check / display the status of the network bond configured in the RHEL server ?
First, we'll execute a command to identify the name being used for our network
bond. This is a good one to use: # nmcli device status
After executing the above command, we're looking for a name such as
bond# - where the # (pound sign) is a number (0, 1, 2, etc.).
To check the status of a bonded interface in Linux, you can use one of the
following commands:
# cat /proc/net/bonding/bond#
- again, the # refers to the number that is assigned to the name of the
bond interface (e.g. bond0)
OR
# nmcli device status
Network bonding refers to the combination of network interfaces on one host for redundancy and/or increased throughput.
@Trevor great work with explanations! I think these series will become a handy notebook for learners preparing to ace the Linux interviews or who wants to deep dive into the Linux and K8s world.
Kudos to your efforts throughout the series!
Chetan, I have to tip my hat to you for all the insightful questions!!!
Anyone out here, making an effort to really dig into your questions,
is going to have their knowledge elevated well beyond just what is
gained from the classroom!!!
Many thanks for this terrific series!!!
Red Hat
Learning Community
A collaborative learning environment, enabling open source skill development.