Red Hat Linux Interview Series 28

[Chetan_Tiwary_]

Q.) Troubleshoot the issue when a  Network interface does not come up automatically at boot time.

Q.) What is the difference between Response SLA and Resolution SLA as per ITIL terminology.

Q.) How will you create an ext4 file system, using an external device as journal with a block size of 4096 Bytes ?

Bonus Q.) How will you convert an existing ext4 file system with an internal journal to an external journal ?

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.

[Trevor]

If the network interface ain't starting up when the system boots, where
do we begin?

To troubleshoot a network interface failing to start on RHEL 9, I would first begin

by checking for hardware issues.  When checking for hardware issues, examine 

the following:

- Cable connection: Ensure the network cable is properly connected and
     not damaged.

- Physical device status: Check if the network card is detected by the system
     using ls /dev/net/, and if it is properly recognized.

- BIOS settings: Verify the network interface is enabled in your BIOS settings.

If all is good with the investigation of hardware issues, proceed to have a look
at the system logs for error messages related to the network interface, using
either the dmesg or journalctl command.

If nothing is gleaned from the system logs, then it's time turn to our attention
to the NetworkManager configuration.  If the network interface isn't starting
on boot in RHEL 9, the most likely culprit is an issue with the NetworkManager
configuration, particularly if the "autoconnect" setting is not properly set to "yes"
within the  network connection profile.

Check the connection profile settings, using the command

                      # nmcli connection show connection_name

and make the necessary adjustment if needed.  What we're looking for here

primarily is the profile setting for "connection.autoconnect".

Note1:  The connection_name to used in the previous command can be 

attained from the following command:    #  nmcli connection show

Note2:  The location of profile files are in the 
/etc/NetworkManager/system-connections directory.  In these

profile files, the connection details are stored in keyfile format.

If the connection.autoconnect setting does require adjustment, edit the 

connection profile using the following command:

                 # nmcli connection modify connection-name autoconnect yes

Restart the NetworkManager service, to apply changes, if an adjustment was
made to the connection profile.

Note: It wouldn't hurt to verify that the key ipv4.method, in the connection
profile is set to auto.  If necessary, this can be easily set by using the following 

command:   

            #  nmcli connection modify connection_profile  ipv4.method auto

I would take a different approach to troubleshoot a network interface was not
functioning, due to something other than failing to start on bootup.

[Chetan_Tiwary_]

@Trevor think here about the network interface setting file and the option to enable it on boot.

[Trevor · Accepted solution]

What is the difference between Response SLA and Resolution SLA as per ITIL terminology.

In ITIL, a service level agreement (SLA) defines the expected level of
service and the responsibilities of an IT service provider and their customer:

Response time: How quickly the provider will respond to a request for support

Resolution time: How quickly the provider will resolve an issue


In ITIL terminology, a "Response SLA" refers to the time frame within which
a service provider must acknowledge and respond to a customer's incident
or request, while a "Resolution SLA" refers to the total time taken to completely
resolve that issue once it has been reported. Essentially, the response time is
when the customer receives initial contact, and the resolution time is when
the problem is fully fixed.

Response SLA focuses on initial contact:
This means the service provider must acknowledge the issue and
provide a response within a specified time frame, even if they
haven't fully resolved it yet.

Resolution SLA focuses on complete problem resolution:
This includes the entire process from when the issue is reported
to when it is fully fixed and closed.

Here is an example of each one:

Response SLA:
A service provider might have a "response SLA" of 15 minutes, meaning
they must acknowledge a customer's support ticket within 15 minutes
of it being submitted.

Resolution SLA:
The "resolution SLA" for the same issue might be 12 hours, indicating
that the problem should be completely resolved within 12 hours of
the initial report.

[Chetan_Tiwary_]

@Trevor You are the ITIL "prince"!! Wonderful explanation!

[Trevor · Accepted solution]

How will you create an ext4 file system, using an external device as journal with a block size of 4096 Bytes ?

In Linux, an "external journal" refers to a separate storage device 

used to record file system changes (the "journal") instead of storing 

it on the same physical disk as the main data.  This allows for improved 

performance and data integrity, by potentially placing the journal on a 

faster device like a solid-state drive (SSD) or a dedicated RAID array, 

especially when dealing with heavy write operations on the primary disk.

Essentially, an external journal is a dedicated space for the journal log to

be separate from the main file system data.

The benefits of placing the journal on a different device is that it can 

reduce disk contention, and improve write performance, as the journal 

writes don't compete with regular data writes on the main disk.

You can specify a separate device to store the journal log using the logdev 

option when formatting the filesystem - if you wish.  I won't do so in the
steps that I use to set this up.

Okay, here are the steps:

1)  Create the external journal device:

#  mkfs.ext4  -F  -O  journal_dev  -b 4096  /dev/sda1

- uses a block size of 4096 bytes

- block device is the first partition, on the first disk, on the scsi controller

Step 2)  Create the ext4 filesystem, using the external journal created in Step 1

#  mkfs.ext4  -F  -J  device=/dev/sda1   -b 4096  /dev/sdb1

-  the ext4 filesystem is created on the first partition, on 2nd drive, on scsi

     controller

-  /dev/sda1  is the device on which the external journal was created

Step 3)  You can verify the journal values that are set with the following command:

#   tune2fs  -l  /dev/vdb1  |  grep  -i  journal

This wasn't asked in the question, but I'll include it anyway.

To mount this ext4 filesystem (/dev/sdb1):

1)  Create a mount point

#   mkdir   /mnt/fs_with_journal/

- there's nothing special about the mount point name of "fs_with_journal"

2)  mount the ext4 filesystem 

#  mount  -o  data=journal  /dev/sdb1   /mnt/fs_with_journal/

If everything is setup properly, every time /dev/sdb1 is accessed, 

it uses /dev/sda1 (the device with the external journal).

[Trevor]

Bonus Q.) How will you convert an existing ext4 file system with an internal journal to an external journal ?

Answer:  I won't be greedy, and gobble up all the queries.  I'll hold off on responding
to this one for a max of 24 hours.  If there are no takers by then, I'll go ahead and
weigh in.  24-hr Expiration:  12:57am CST/10-27-2024

[Chetan_Tiwary_]

@Trevor The golf course is yours to conquer!