cancel
Showing results for 
Search instead for 
Did you mean: 
Chetan_Tiwary_
Community Manager
Community Manager
  • 874 Views

Red Hat Linux Interview Series 28

Jump to solution

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.

0 Kudos
2 Solutions

Accepted Solutions
Trevor
Starfighter Starfighter
Starfighter
  • 752 Views

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.

Trevor "Red Hat Evangelist" Chandler

View solution in original post

Trevor
Starfighter Starfighter
Starfighter
  • 748 Views

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 "Red Hat Evangelist" Chandler

View solution in original post

7 Replies
Trevor
Starfighter Starfighter
Starfighter
  • 754 Views

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.

 

Trevor "Red Hat Evangelist" Chandler
Chetan_Tiwary_
Community Manager
Community Manager
  • 656 Views

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

Trevor
Starfighter Starfighter
Starfighter
  • 753 Views

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.

Trevor "Red Hat Evangelist" Chandler
Chetan_Tiwary_
Community Manager
Community Manager
  • 656 Views

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

Trevor
Starfighter Starfighter
Starfighter
  • 749 Views

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 "Red Hat Evangelist" Chandler
Trevor
Starfighter Starfighter
Starfighter
  • 747 Views

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

 

Trevor "Red Hat Evangelist" Chandler
Chetan_Tiwary_
Community Manager
Community Manager
  • 654 Views

@Trevor The golf course is yours to conquer!

Join the discussion
You must log in to join this conversation.