Objective: Create the Linux user james, assign the specified password, create two groups with exact group IDs, and configure the user's primary and supplementary group memberships.

The task requires these operations to be performed in the specified order:

Requirement

Expected configuration

Username

james

Password

Foundation

Supplementary group

commander

Supplementary group GID

15002

Primary group

pilot

Primary group GID

15001

Important: Adding james to commander must not change the user's primary group. Only the final operation changes the primary group to pilot.

Step 1: Connect to the correct Linux server.

The video specifies host lfcs00091.

From the candidate terminal, execute:

ssh lfcs00091

This establishes an SSH connection to the designated Linux server.

All account and group-management operations must be performed on this host.

Step 2: Check whether user james already exists.

Execute:

id james

If the account does not exist, an expected message is:

id: ‘james’: no such user

You can also execute:

getent passwd james

This searches the configured user-account databases.

If the account already exists, inspect it before changing anything. Since the task explicitly requests creating the user, the normal exam starting state should not already contain the account.

Step 3: Create the user james.

Execute:

sudo useradd -m james

sudo runs the command with administrative privileges.

useradd creates a new Linux user account.

-m creates a home directory for the user.

james is the required username.

On a typical Ubuntu system configured for private user groups, the command creates an account with a home directory at:

/home/james

The default primary group is determined by the system's account-creation policy. It is commonly a private group named james.

The official Linux useradd(8) documentation confirms that -m creates a home directory and that default primary-group behavior depends on system configuration.

Linux manual page

Step 4: Verify that the user was created successfully.

Execute:

id james

An illustrative output is:

uid=1001(james) gid=1001(james) groups=1001(james)

The numerical UID and initial GID can differ on the actual system.

Check the account entry:

getent passwd james

Verify the home directory:

ls -ld /home/james

The account should exist before proceeding.

Step 5: Set the user's password to Foundation.

Execute:

sudo passwd james

The system will request a new password.

Enter:

Foundation

When prompted to confirm, enter:

Foundation

The password is case-sensitive.

A successful operation normally displays:

passwd: password updated successfully

The passwd command securely processes the supplied password and updates the account's password authentication information.

The official passwd(1) manual confirms that an administrator can assign a password to another user and that the utility requests the new password interactively.

Linux manual page

Step 6: Verify the user's password status.

Execute:

sudo passwd -S james

The output may resemble:

james P 2026-10-12 0 99999 7 -1

The date and password-aging fields will depend on the system.

The important value is:

P

This indicates that the account has a usable password.

This command does not reveal or independently confirm the plaintext password. To verify the actual credential, authenticate as james using Foundation through an appropriate login method.

Do not attempt to read the plaintext password from /etc/shadow. Linux stores password hashes rather than recoverable plaintext passwords.

Step 7: Check whether the group commander already exists.

Before creating the group, execute:

getent group commander

If the group does not exist, the command normally produces no output.

Also check whether GID 15002 is already allocated:

getent group 15002

If both checks produce no results, the requested group name and ID are available.

Step 8: Create group commander with GID 15002.

Execute:

sudo groupadd -g 15002 commander

groupadd creates a new Linux group.

-g 15002 assigns the exact numerical GID.

commander is the required group name.

The -g option explicitly controls the group's numerical identifier.

The official groupadd(8) documentation confirms that this option creates a group using the specified GID and normally requires it to be unique.

Linux manual page

Step 9: Verify that group commander was created.

Execute:

getent group commander

Expected output, before adding members:

commander:x:15002:

The fields in /etc/group are arranged as:

group_name:password:GID:user_list

Therefore:

commander is the group name.

x indicates the group password field is not stored directly in /etc/group.

15002 is the assigned GID.

The final field lists supplementary group members.

Step 10: Record james's current primary group.

Before adding james to commander, execute:

id -gn james

This displays the user's current primary group name.

To display its numerical GID:

id -g james

On a typical Ubuntu system, the group name may initially be:

james

The purpose of this step is to establish the primary-group value before making any changes to supplementary memberships.

Step 11: Add james to commander as a supplementary group.

Execute:

sudo usermod -aG commander james

This is one of the most important commands in the task.

Option

Purpose

usermod

Modifies an existing user account

-a

Appends to existing supplementary group memberships

-G commander

Specifies the supplementary group

james

Specifies the target user

The combination -aG adds commander to the user's supplementary memberships without changing the primary group.

The official usermod(8) manual confirms this behavior.

Linux manual page

Step 12: Understand why -aG is required.

Compare these commands:

sudo usermod -aG commander james

This is correct because it appends commander to the supplementary groups.

sudo usermod -G commander james

This can replace the user's existing supplementary group list with the specified list, removing memberships that were not included.

sudo usermod -g commander james

This would change the primary group to commander.

The last command is incorrect at this stage because the task explicitly states:

Do not change user james's primary group.

Therefore, use:

sudo usermod -aG commander james

Step 13: Verify supplementary group membership.

Execute:

id james

An illustrative result is:

uid=1001(james) gid=1001(james) groups=1001(james),15002(commander)

This confirms that commander was added as a supplementary group.

Check the group entry:

getent group commander

Expected:

commander:x:15002:james

Step 14: Verify that the primary group has not changed.

Execute:

id -gn james

Compare its output against the primary group recorded in Step 10.

The value must remain unchanged at this stage.

For example, if the original primary group was james, the output should remain:

james

Also check:

id -g james

This should return the original primary GID.

Do not proceed until both conditions are met: james belongs to commander, and the original primary group is unchanged.

Step 15: Check whether the group pilot already exists.

Execute:

getent group pilot

Check whether GID 15001 is available:

getent group 15001

The group name and numerical GID should be available for the requested group creation.

Step 16: Create group pilot with GID 15001.

Execute:

sudo groupadd -g 15001 pilot

groupadd creates a new group.

-g 15001 sets its numerical GID to 15001.

pilot is the requested group name.

The exact GID matters. Do not allow Linux to choose an automatically assigned GID.

Step 17: Verify group pilot.

Execute:

getent group pilot

Expected:

pilot:x:15001:

This verifies the group name and assigned numerical identifier.

At this stage, the group has been created, but the user's primary group has not yet been changed.

Step 18: Set pilot as the primary group for james.

Execute:

sudo usermod -g pilot james

This is the final account-modification command required by the task.

usermod modifies the existing user account.

-g pilot sets the primary login group to pilot.

james identifies the account being modified.

Unlike uppercase -G, which controls supplementary groups, lowercase -g specifies the primary group.

The official usermod(8) documentation distinguishes these options explicitly.

Linux manual page

The new primary group must already exist, which is why pilot was created first.

Step 19: Verify the user's new primary group.

Execute:

id -gn james

Expected output:

pilot

Verify the numerical GID:

id -g james

Expected:

15001

These commands establish that the account's primary group is now pilot.

Step 20: Verify that commander remains a supplementary group.

Execute:

id james

An illustrative final result is:

uid=1001(james) gid=15001(pilot) groups=15001(pilot),15002(commander)

The UID and any additional supplementary groups may differ.

The important conditions are:

Primary GID: 15001, belonging to pilot.

Supplementary membership: commander, GID 15002.

Changing the primary group with usermod -g should not remove the existing supplementary commander membership.

Step 21: Inspect the final account database entry.

Execute:

getent passwd james

An illustrative entry is:

james:x:1001:15001::/home/james:/bin/sh

The fourth field is the primary GID, which must be 15001.

The login shell and other fields may vary according to the system defaults.

Step 22: Verify the group definitions.

Execute:

getent group commander

getent group pilot

Expected group definitions:

commander:x:15002:james

pilot:x:15001:

It is normal for the pilot group entry not to list james explicitly in its final member field. A user's primary group is determined by the GID stored in the user-account record, while /etc/group lists explicit supplementary group membership.

The id james command is the most convenient way to verify both kinds of group membership together.

Linux manual page

Step 23: Verify the password status again.

Execute:

sudo passwd -S james

Confirm that the account still reports a usable password with status P.

The group modifications should not change the password.

Step 24: Perform the final verification.

Execute:

id james

id -gn james

id -g james

id -Gn james

getent group commander

getent group pilot

sudo passwd -S james

The required final configuration is:

Requirement

Expected result

User exists

james

Password configured

Foundation

commander exists

Yes

commander GID

15002

commander membership

Supplementary

pilot exists

Yes

pilot GID

15001

pilot membership

Primary

Other supplementary memberships

Preserved

Final Solution

Execute the following commands in order.

# Connect to the required server

ssh lfcs00091

# Create user james with a home directory

sudo useradd -m james

# Set password interactively to Foundation

sudo passwd james

# Create commander with GID 15002

sudo groupadd -g 15002 commander

# Add james to commander as a supplementary group

sudo usermod -aG commander james

# Verify primary group has not changed

id -gn james

# Create pilot with GID 15001

sudo groupadd -g 15001 pilot

# Change james's primary group to pilot

sudo usermod -g pilot james

# Verify the complete user configuration

id james

id -gn james

id -g james

# Verify the created groups

getent group commander

getent group pilot

# Verify the account has a usable password

sudo passwd -S james

When executing:

sudo passwd james

enter Foundation twice when prompted.

Expected final result:

uid=1001(james) gid=15001(pilot) groups=15001(pilot),15002(commander)

The UID is illustrative. The required group names, GIDs, and memberships must match exactly.

Technical Verification and References

The commands have been checked against the Linux account-management manuals:

Linux useradd(8)

— Creating user accounts.

Linux passwd(1)

— Assigning and checking user passwords.

Linux groupadd(8)

— Creating groups with specified GIDs.

Linux usermod(8)

— Managing primary and supplementary group memberships.

Linux id(1)

— Verifying user and group identities.

Video verification finding: Question 15 is visible at approximately 32:14–32:18 of the recording. Its full task statement and target host lfcs00091 are readable. The candidate moves to the next task without demonstrating these account-management commands, so the solution is independently documentation-verified rather than confirmed through successful execution in the video.

Expected result: User james has password Foundation, belongs to commander (GID 15002) as a supplementary group, and uses pilot (GID 15001) as the primary group.

next now

Worked for 4m 23s

Objective: Correct the Linux system clock by performing a one-time synchronization against NTP servers from pool.ntp.org, without enabling continuous or automatic time synchronization and without modifying the hardware clock.

The video shows the candidate successfully executing:

sudo ntpdate pool.ntp.org

This is a valid solution. The terminal output confirms that the system clock was adjusted using an NTP server.

The official Ubuntu ntpdate(8) documentation confirms that ntpdate can synchronize the system clock manually without establishing an ongoing synchronization service.

Ubuntu Manpages

Step 1: Connect to the correct Linux server.

The video specifies host lfcs00103.

From the candidate terminal, execute:

ssh lfcs00103

This establishes an SSH session with the server whose system clock requires correction.

All subsequent commands must be executed on this host.

Step 2: Inspect the current system date and time.

Execute:

date

This displays the system's current local date and time.

For UTC:

date -u

The -u option displays the system time in Coordinated Universal Time.

Record the initial date and time so you can compare the system clock before and after synchronization.

The task states that the system clock has drifted. Therefore, its displayed time may differ significantly from the actual time reported by NTP servers.

Step 3: Check the current time synchronization status.

Execute:

timedatectl status

This displays information such as:

Local time.

Universal time.

RTC (hardware clock) time.

Configured timezone.

Whether an NTP synchronization service is active.

Whether the system reports its clock as synchronized.

An illustrative output is:

Local time: Sat 2026-10-03 11:30:00 UTC

Universal time: Sat 2026-10-03 11:30:00 UTC

RTC time: Sat 2026-10-03 11:30:00

Time zone: Etc/UTC (UTC, +0000)

System clock synchronized: no

NTP service: inactive

These values are illustrative rather than the actual output from the video.

Since the question asks for manual one-time synchronization, there is no need to configure an automatic NTP service.

Step 4: Verify that the ntpdate utility is available.

Execute:

command -v ntpdate

If installed, this command displays its executable path.

For example:

/usr/sbin/ntpdate

You can inspect the utility's manual:

man ntpdate

The task's demonstrated environment already has ntpdate available.

Therefore, installing additional software is unnecessary.

Step 5: Verify hostname resolution for the NTP server pool.

The task specifies:

pool.ntp.org

Check that the hostname resolves:

getent ahosts pool.ntp.org

This should return IP addresses associated with the NTP pool.

pool.ntp.org is a DNS-based collection of public NTP servers rather than one fixed machine.

Using the pool allows the time client to obtain available servers without manually specifying individual server addresses.

A successful synchronization also requires network connectivity to an NTP server, normally using UDP port 123.

Step 6: Check for an existing time synchronization daemon if necessary.

Execute:

systemctl is-active systemd-timesyncd

systemctl is-active chrony

systemctl is-active ntp

Some services may not be installed, so an inactive, unknown, or unit-not-found result is possible.

The task says not to configure automatic synchronization. It does not require enabling any of these services.

If an existing synchronization daemon interferes with a one-time adjustment, investigate and handle that conflict without unnecessarily modifying its persistent configuration.

Do not enable a daemon merely to synchronize the clock once.

Step 7: Synchronize the system clock manually using ntpdate.

Execute the primary solution:

sudo ntpdate pool.ntp.org

This is the command demonstrated in the video.

Command component

Purpose

sudo

Grants privileges to modify the system clock

ntpdate

Queries NTP servers and adjusts the local system clock

pool.ntp.org

Specifies the requested NTP server pool

The utility contacts NTP servers, estimates the difference between the local clock and server time, and corrects the local clock.

Depending on the implementation and magnitude of the error, it may step or slew the clock.

A step changes the displayed system time immediately. A slew changes the clock gradually.

The ntpdate manual documents the clock-setting behavior and the difference between querying and updating the clock.

Ubuntu Manpages

Step 8: Examine the synchronization output.

The recording shows that the ntpdate command corrected a substantial clock error.

The terminal includes a successful adjustment message of the form:

CLOCK: time stepped by 37212257.308748

It also reports that the system clock moved from an incorrect date in July 2025 to October 3, 2026.

This is significant because it confirms that the command did more than merely query an NTP server: it actually changed the system clock.

Your terminal output will depend on the clock's actual drift when the command runs.

A small drift may result in a different adjustment message.

Step 9: Verify the command's exit status.

Immediately after the synchronization command completes, execute:

echo $?

Expected:

0

The official ntpdate documentation specifies that a zero exit status indicates a successful clock update.

Ubuntu Manpages

A nonzero status indicates that the operation failed.

If the operation fails, investigate the actual error rather than assuming that the clock has been corrected.

Possible issues include unavailable DNS resolution, unreachable NTP servers, firewall restrictions, or interference from another time synchronization process.

Step 10: Verify the corrected system time.

Execute:

date

Then:

date -u

These commands display the system time after the NTP adjustment.

Compare the new values with the values recorded before synchronization.

The corrected clock should be consistent with the time reported by the selected NTP servers.

Step 11: Optionally check the remaining time offset without changing the clock.

Execute:

sudo ntpdate -q pool.ntp.org

The -q option means query only.

It obtains time information and reports the estimated offset without setting the clock.

This is useful after synchronization because it allows you to check whether the remaining clock difference is small.

Do not confuse:

sudo ntpdate -q pool.ntp.org

with:

sudo ntpdate pool.ntp.org

The first command queries only; the second performs the requested clock adjustment.

A small reported offset provides supporting evidence that the local clock is close to the NTP reference time.

Step 12: Do not configure automatic synchronization.

The task explicitly states:

Do not configure automatic time synchronization.

Therefore, do not enable a continuous time synchronization service as part of the solution.

For example, avoid:

sudo timedatectl set-ntp true

Also avoid enabling a daemon solely for this task:

sudo systemctl enable --now chrony

Likewise, do not create a cron job that runs ntpdate periodically.

These operations would establish ongoing synchronization behavior rather than performing the required one-time adjustment.

The command:

sudo ntpdate pool.ntp.org

already satisfies the one-time synchronization requirement when it completes successfully.

Step 13: Do not manually update the hardware clock.

Linux maintains two conceptually distinct clocks:

Clock

Description

System clock

Kernel-maintained clock used by running applications

Hardware clock (RTC)

Battery-backed or virtualized real-time clock used across system restarts

The task specifically instructs that the hardware clock does not need to be updated.

Therefore, do not execute:

sudo hwclock --systohc

This command copies the system clock to the hardware clock and is unnecessary for the task.

The exam environment is already configured to perform the appropriate hardware-clock update during shutdown.

Step 14: Do not modify persistent NTP configuration files.

The task does not require editing files such as:

/etc/chrony/chrony.conf

/etc/systemd/timesyncd.conf

/etc/ntp.conf

These files belong to time synchronization service configurations and are unrelated to the required manual one-time operation.

There is also no requirement to change the timezone.

Step 15: Verify the system status after synchronization.

Execute:

timedatectl status

Inspect the system time.

One important technical detail: after a manual ntpdate adjustment, timedatectl may still report:

System clock synchronized: no

This does not necessarily mean the one-time NTP adjustment failed.

That status may depend on whether a running time synchronization service or the kernel's synchronization status has marked the clock as synchronized.

For this task, rely primarily on the successful ntpdate execution, the resulting clock adjustment, and an optional read-only NTP offset check.

Do not enable automatic synchronization simply to change the timedatectl status.

Step 16: Alternative solution if ntpdate is unavailable.

If the host provides Chrony instead of ntpdate, the officially documented one-time synchronization command is:

sudo chronyd -q 'pool pool.ntp.org iburst'

chronyd is Chrony's time synchronization program.

-q instructs it to set the system clock once and exit.

pool pool.ntp.org selects servers from the specified NTP pool.

iburst performs an initial burst of requests for quicker synchronization.

This is the alternative recommended by Ubuntu's current time synchronization documentation.

Frequently Asked Questions

+1

Use this alternative only if appropriate for the installed environment. If another Chrony daemon is already running, avoid launching a competing clock controller without resolving that conflict.

For the environment demonstrated in the supplied video, ntpdate is available and is the simpler, directly demonstrated solution.

Step 17: Perform final verification.

Execute:

date -u

Confirm the corrected system time.

If needed, check the NTP offset without changing the clock:

sudo ntpdate -q pool.ntp.org

The completed task should satisfy:

Requirement

Expected result

Correct host

lfcs00103

NTP server pool

pool.ntp.org

System clock synchronized once

Yes

Method

Manual NTP adjustment

Automatic synchronization configured

No

Hardware clock manually changed

No

Clock adjustment

Successful

Final Solution

The essential commands are:

# Connect to the designated server

ssh lfcs00103

# Check the current system time

date -u

# Perform one-time synchronization

sudo ntpdate pool.ntp.org

# Verify the corrected time

date -u

# Optional: query the remaining offset without modifying the clock

sudo ntpdate -q pool.ntp.org

The single command that performs the requested adjustment is:

sudo ntpdate pool.ntp.org

Technical Verification and References

Ubuntu ntpdate(8) Manual

— Documents one-time clock synchronization, query-only mode and exit status.

Chrony Official FAQ

— Documents chronyd -q for one-time clock synchronization.

Ubuntu Server — Time Synchronization

— Explains NTP, Chrony and one-shot synchronization.

Video verification finding: At approximately 30:30–30:46, the candidate connects to lfcs00103 and executes sudo ntpdate pool.ntp.org. The terminal displays a successful clock-step operation, correcting a large time difference. No continuous synchronization service or hardware-clock modification is shown.

Expected result: The system clock on lfcs00103 is corrected through a single NTP synchronization against pool.ntp.org. No automatic time synchronization is configured, and the hardware clock is left unchanged.

next batch now

Step 1: Connect to the correct server.

The video specifies that the task must be completed on host lfcs00082.

From the candidate terminal, connect using:

ssh lfcs00082

This establishes an SSH session with the server where the cron job must be configured.

Step 2: Verify that the user james exists.

Execute:

id james

This displays the user's UID, primary GID, and group memberships.

An example of valid output is:

uid=1001(james) gid=1001(james) groups=1001(james)

The exact numerical IDs may differ. The important requirement is that the user james exists.

Step 3: Verify that the script exists.

Execute:

ls -l /home/james/bin/scanfiles.sh

This verifies the script's location, ownership, and permissions.

You can also check whether james has execute permission:

sudo -u james test -x /home/james/bin/scanfiles.sh

echo $?

An exit status of 0 confirms that the user can execute the script. If the check fails, investigate file and directory permissions.

The task does not require creating or modifying the script.

Step 4: Open the crontab for user james.

Execute:

sudo crontab -u james -e

- sudo provides the privileges needed to manage another user's crontab.

- crontab manages scheduled cron jobs.

- -u james selects the crontab belonging to user james.

- -e opens the selected crontab in a text editor.

This is important because the task explicitly requires scheduling the job for james, not for root or the candidate account.

Step 5: Add the cron job.

Insert the following entry into the crontab:

15 17 * * * /home/james/bin/scanfiles.sh > /home/james/report.txt

This is the exact scheduling command required to satisfy the task.

Step 6: Understand the cron expression.

The cron entry contains five scheduling fields followed by the command.

Field Value Description

Minute 15 Execute at minute 15

Hour 17 Execute at 17:00 (5 PM)

Day of month * Every day of the month

Month * Every month

Day of week * Every day of the week

Therefore, the script executes once daily at 17:15 according to the cron daemon's configured timezone.

The command portion is:

/home/james/bin/scanfiles.sh > /home/james/report.txt

It consists of:

- /home/james/bin/scanfiles.sh — the executable script.

- > — the shell's STDOUT redirection operator.

- /home/james/report.txt — the destination file for standard output.

The > operator creates the report file if it does not exist and the user has permission. If it exists, the output is overwritten on each execution.

Do not replace > with > > because > > appends output. Also, do not use 2 > & 1, because the task requests STDOUT only, not STDERR.

Step 7: Save the crontab.

If the crontab opens in Vim:

1. Press i to enter insert mode.

2. Add the cron entry.

3. Press Esc.

4. Type :wq and press Enter.

If it opens in Nano, press Ctrl+O, Enter, then Ctrl+X.

Once saved, the crontab command installs the updated schedule automatically.

Step 8: Verify the installed cron job.

Execute:

sudo crontab -u james -l

The output must include:

15 17 * * * /home/james/bin/scanfiles.sh > /home/james/report.txt

This verifies that the job is installed under the correct user account.

Step 9: Check the cron service.

On the Ubuntu system shown in the recording, execute:

systemctl status cron

The service should report:

Active: active (running)

If it is inactive, start it:

sudo systemctl start cron

To check whether the service is enabled for startup:

systemctl is-enabled cron

If cron is disabled and must remain operational after reboot, enable it:

sudo systemctl enable cron

Step 10: Verify the final configuration.

Run:

sudo crontab -u james -l

sudo -u james test -x /home/james/bin/scanfiles.sh

systemctl is-active cron

These commands verify that:

1. The required cron entry belongs to james.

2. The script is executable by james.

3. The cron service is active.

The report file is not necessarily present immediately after installing the cron entry. It will be created or overwritten when the scheduled job executes successfully.

Final Solution

The essential command is:

sudo crontab -u james -e

Add:

15 17 * * * /home/james/bin/scanfiles.sh > /home/james/report.txt

Then verify:

sudo crontab -u james -l

Technical verification: This solution follows the documented Linux crontab(1) and crontab(5) syntax. A user-specific crontab executes commands under the owner's account and uses five scheduling fields followed by the command.

Linux manual page

+1

Expected result: The script runs every day at 17:15 as james, directing its standard output to /home/james/report.txt. The schedule's configuration is verified; actual runtime success depends on the script, its permissions, and the target system.

Step 1: Connect to the correct Linux server.

The video specifies that this task must be completed on host lfcs00077.

From the candidate terminal, execute:

ssh lfcs00077

All disk inspection, file creation, and deletion operations must be performed on this host.

Step 2: Inspect all mounted filesystems and disk utilization.

Execute:

df -hT

This displays information about mounted filesystems, including their utilization.

An illustrative output is:

Filesystem Type Size Used Avail Use% Mounted on

/dev/sda1 ext4 40G 16G 24G 40% /

/dev/sdb1 ext4 20G 18G 2G 90% /data/app1

/dev/sdc1 ext4 30G 27G 3G 90% /data/app2

/dev/sdd1 ext4 50G 30G 20G 60% /data/app3

This output is an example, not data obtained from the actual exam host.

Explanation of the columns:

Column

Description

Filesystem

Device or filesystem source

Type

Filesystem type, such as ext4 or XFS

Size

Total filesystem capacity

Used

Used disk space

Avail

Available disk space

Use%

Percentage of disk space utilized

Mounted on

Directory where the filesystem is mounted

The task requires identifying application data partitions utilizing more than 85%.

For example:

/dev/sdb1 — 90% utilized — qualifies.

/dev/sdc1 — 90% utilized — qualifies.

/dev/sdd1 — 60% utilized — does not qualify.

The system partition /dev/sda1 should not be included merely because it appears in df output. The task specifically refers to application data partitions.

Step 3: Identify the available block devices.

Execute:

lsblk

For more detailed output:

lsblk -p -o NAME,SIZE,FSTYPE,MOUNTPOINTS

lsblk lists available block devices.

-p displays full device paths.

-o specifies the output columns.

NAME identifies the device.

SIZE displays its capacity.

FSTYPE shows the filesystem type.

MOUNTPOINTS lists its mountpoints.

An illustrative output is:

NAME SIZE FSTYPE MOUNTPOINTS

/dev/sda 40G

└─/dev/sda1 40G ext4 /

/dev/sdb 20G

└─/dev/sdb1 20G ext4 /data/app1

/dev/sdc 30G

└─/dev/sdc1 30G ext4 /data/app2

/dev/sdd 50G

└─/dev/sdd1 50G ext4 /data/app3

The output establishes the relationship between block devices, filesystems, and application data mountpoints.

This is necessary because the task requires saving device file paths, not mountpoint paths.

Step 4: Display filesystems using a consistent output format.

Execute:

df -P

The -P option uses the POSIX output format, which displays each filesystem on a single line.

This is useful when processing filesystem information with awk.

To identify all mounted filesystems whose reported utilization exceeds 85%, execute:

df -P | awk 'NR > 1 {

usage = $5

gsub(/%/, "", usage)

if (usage > 85)

print $1, usage "%", $6

}'

NR > 1 skips the header.

$5 extracts the utilization percentage.

gsub(/%/, "", usage) removes the percentage symbol.

usage > 85 selects filesystems whose reported utilization exceeds 85%.

$1 displays the filesystem source.

$6 displays the mountpoint.

An illustrative result is:

/dev/sdb1 90% /data/app1

/dev/sdc1 90% /data/app2

Important: This command identifies all filesystems over the threshold, not necessarily only application data filesystems. You must inspect the results and exclude unrelated system partitions.

Official GNU documentation confirms the purpose and output format of df -P.

Step 5: Verify the mountpoint associated with each qualifying device.

Execute:

findmnt -rno SOURCE,TARGET,FSTYPE

This shows the source devices, their mountpoints, and filesystem types.

For an individual qualifying mountpoint, use:

findmnt --mountpoint /data/app1

And:

findmnt --mountpoint /data/app2

These paths are illustrative. Replace them with the actual qualifying application data mountpoints.

Ensure that each selected filesystem:

Is an application data partition.

Has reported utilization greater than 85%.

Has an identified block-device path.

Is mounted at a known location.

Only proceed once these conditions are confirmed.

Step 6: Create the required ~/partitions.txt file.

The task requires saving the absolute paths of qualifying device files, one per line.

For example, suppose the qualifying devices are:

/dev/sdb1

/dev/sdc1

Execute:

printf '%s\n' /dev/sdb1 /dev/sdc1 > ~/partitions.txt

Replace /dev/sdb1 and /dev/sdc1 with the actual device paths identified on the exam server.

printf '%s\n' prints each supplied argument on a separate line.

/dev/sdb1 and /dev/sdc1 represent the qualifying device files.

> redirects output into the required file.

~/partitions.txt is the output file specified in the task.

The file must contain device paths rather than utilization percentages or mountpoint paths.

Step 7: Verify the contents of partitions.txt.

Execute:

cat ~/partitions.txt

For the illustrative devices, the expected content is:

/dev/sdb1

/dev/sdc1

Each qualifying device must appear on a separate line.

You can also number the lines to inspect the format:

cat -n ~/partitions.txt

Example:

1 /dev/sdb1

2 /dev/sdc1

Verify that no device from an application data filesystem at 85% or below appears in this file.

Step 8: Confirm that each saved path is a block device.

Execute:

while IFS= read -r device; do

ls -l "$device"

done < ~/partitions.txt

The device entries should represent valid block devices.

To check one device directly:

test -b /dev/sdb1

echo $?

An exit status of 0 indicates that the path refers to a block device.

Use the actual path from partitions.txt.

Step 9: Identify log files larger than 5 MB on qualifying partitions.

The next requirement is to delete *.log files greater than 5 MB, but only from qualifying data partitions.

For example, if /dev/sdb1 is mounted at /data/app1, execute:

sudo find /data/app1 -xdev -type f \

-name '*.log' -size +5000000c -print

Parameter

Purpose

/data/app1

Searches the selected qualifying filesystem

-xdev

Prevents descending into other mounted filesystems

-type f

Selects regular files

-name '*.log'

Selects filenames ending with .log

-size +5000000c

Selects files larger than 5,000,000 bytes

-print

Displays matching files without deleting them

The task says 5 MB. The command above uses the strict decimal definition of 5 MB.

In GNU find, the alternative:

-size +5M

uses 5 MiB (5,242,880 bytes) rather than decimal megabytes. Both conventions occur in Linux administration, but they are not numerically identical. GNU Findutils documents these units explicitly.

Step 10: Preview the matching files on every qualifying partition.

For example, if /data/app1 and /data/app2 are the two qualifying mountpoints, execute:

sudo find /data/app1 -xdev -type f \

-name '*.log' -size +5000000c -print

Then:

sudo find /data/app2 -xdev -type f \

-name '*.log' -size +5000000c -print

Example results might be:

/data/app1/logs/application.log

/data/app1/logs/error.log

/data/app2/reports/debug.log

These filenames are illustrative.

Review the output before deleting anything.

This matters because the task expressly prohibits modifying other data partitions.

Step 11: Delete qualifying log files from the first selected partition.

After confirming the filesystem and matching files, execute:

sudo find /data/app1 -xdev -type f \

-name '*.log' -size +5000000c -delete

The -delete action removes the matching files permanently.

Do not execute the command against the entire root filesystem or an unqualified data partition.

The -xdev option is particularly important. It prevents traversal into other mounted filesystems located beneath the selected mountpoint.

Step 12: Delete qualifying log files from any additional qualifying partition.

For the second illustrative mountpoint:

sudo find /data/app2 -xdev -type f \

-name '*.log' -size +5000000c -delete

Repeat only for the remaining application data partitions whose utilization was greater than 85% during the initial inspection.

Do not apply deletion commands to other partitions.

GNU Findutils documents that -delete performs deletion directly and that its predicates should be tested using -print first.

Step 13: Verify that the matching log files have been removed.

Execute:

sudo find /data/app1 -xdev -type f \

-name '*.log' -size +5000000c -print

Then:

sudo find /data/app2 -xdev -type f \

-name '*.log' -size +5000000c -print

If there are no matching files remaining, the commands should produce no output.

If files remain, investigate permission errors or files that changed during the operation.

Step 14: Verify disk utilization after deletion.

Execute:

df -hT

Compare the disk utilization with the initial results.

For example:

Partition

Before

After

/dev/sdb1

90%

77%

/dev/sdc1

90%

82%

/dev/sdd1

60%

60%

These percentages are illustrative, not measured results.

There is no requirement to reduce the qualifying partitions below 85%; the task asks only to delete matching log files.

If a deleted file remains open in a running process, its storage space might not be released until the process closes the file. That does not justify stopping unrelated services without evidence.

Step 15: Confirm that other data partitions were not modified.

Review the original list of partitions and verify that deletion was limited to the selected qualifying mountpoints.

For example, do not execute:

sudo find /data/app3 -name '*.log' -delete

if /data/app3 had utilization of only 60%.

The task explicitly states:

Do not modify any other data partitions.

Therefore, applying a blanket cleanup command across /data, /, or all mounted filesystems would be incorrect.

Step 16: Verify the saved device list again.

Execute:

cat ~/partitions.txt

Confirm that it still contains the original qualifying device paths.

Do not regenerate this list after deletion.

For example, suppose /dev/sdb1 was initially 90% utilized but dropped to 77% after cleanup. It must still appear in ~/partitions.txt because it qualified during the initial inspection.

Step 17: Perform final verification.

Execute:

cat ~/partitions.txt

df -hT

lsblk -p -o NAME,FSTYPE,MOUNTPOINTS

Then run the file search on each qualifying mountpoint once more.

The completed task must meet these conditions:

Requirement

Expected result

Application data partitions inspected

Yes

Partitions greater than 85% identified

Yes

Device paths saved in ~/partitions.txt

Yes

One absolute device path per line

Yes

Matching log files greater than 5 MB deleted

Yes

Only qualifying partitions affected

Yes

Unrelated data partitions unchanged

Yes

Final Solution

The essential command sequence below illustrates the procedure. The two device paths and mountpoints are examples and must be replaced with the actual qualifying values on lfcs00077.

Copy commands

# Connect to the correct host

ssh lfcs00077

# Inspect disk utilization and mounted devices

df -hT

lsblk -p -o NAME,SIZE,FSTYPE,MOUNTPOINTS

# Find filesystems over 85%

df -P | awk 'NR > 1 {

usage=$5

gsub(/%/, "", usage)

if (usage > 85)

print $1, usage "%", $6

}'

# Confirm actual device-to-mountpoint relationships

findmnt -rno SOURCE,TARGET,FSTYPE

# EXAMPLE DEVICES: replace after identifying qualifying partitions

printf '%s\n' /dev/sdb1 /dev/sdc1 > ~/partitions.txt

# Verify the saved list

cat ~/partitions.txt

# EXAMPLE MOUNTPOINTS: preview before deleting

sudo find /data/app1 -xdev -type f \

-name '*.log' -size +5000000c -print

sudo find /data/app2 -xdev -type f \

-name '*.log' -size +5000000c -print

# Delete only on confirmed qualifying partitions

sudo find /data/app1 -xdev -type f \

-name '*.log' -size +5000000c -delete

sudo find /data/app2 -xdev -type f \

-name '*.log' -size +5000000c -delete

# Final verification

df -hT

cat ~/partitions.txt

Technical Verification and References

The procedures are consistent with the following official documentation:

GNU Coreutils — df command

Linux lsblk(8) — Block Device Inspection

GNU Findutils — File Size Matching

GNU Findutils — Filesystem Boundary Control

GNU Findutils — Deleting Files

Video verification finding: I located Question 6 at approximately 28:04–28:10 of the recording and confirmed the task wording and required host. The video moves to Question 7 without showing a completed terminal solution for Question 6. Therefore, the commands above are an independently documented solution, not a reproduction of commands successfully executed in the recording.

Expected result: The file ~/partitions.txt contains the absolute device paths of the application data partitions that initially exceeded 85% disk utilization. All qualifying .log files larger than the specified threshold are deleted from those partitions only, without modifying any other data partitions.

Step 1: Connect to the correct Linux server.

The video specifies that this task must be performed on host lfcs00101a.

From the candidate terminal, execute:

ssh lfcs00101a

This establishes an SSH session with the server where the Apache service is failing.

All subsequent troubleshooting, configuration changes, and service operations must be performed on this host.

Step 2: Check the current status of the Apache service.

Execute:

sudo systemctl status apache2

This is the primary systemd command for checking the status of Apache.

It displays information such as:

Whether the apache2 service is loaded.

Whether the service is running, inactive or failed.

The process ID and execution status.

Recent service log messages.

Errors reported during startup.

An illustrative failure might appear as follows:

× apache2.service - The Apache HTTP Server

Loaded: loaded (/lib/systemd/system/apache2.service; enabled)

Active: failed (Result: exit-code)

Process: 1234 ExecStart=/usr/sbin/apachectl start

Main PID: 1234 (code=exited, status=1/FAILURE)

This is an example, not an output confirmed from the supplied video.

The Active: failed status means the service was unable to complete startup successfully.

Use the actual error messages to determine the cause.

Step 3: Examine the Apache service logs.

Execute:

sudo journalctl -u apache2 -b --no-pager

journalctl displays logs collected by systemd.

-u apache2 filters messages associated with the Apache service.

-b restricts results to the current boot.

--no-pager prints output directly without opening an interactive pager.

To display only the latest 50 messages:

sudo journalctl -u apache2 -n 50 --no-pager

These logs help identify why Apache failed.

Possible causes include:

Incorrect permissions on the Apache executable.

Invalid configuration directives.

Missing configuration files.

Another process using the required network port.

Inaccessible log directories.

Missing modules or other dependencies.

The official systemd documentation supports using journalctl -u to investigate the logs associated with a particular service.

Freedesktop

Step 4: Check the Apache executable.

On Ubuntu, the Apache server executable is normally located at:

/usr/sbin/apache2

Verify its existence:

ls -l /usr/sbin/apache2

For a more detailed permissions check:

stat -c '%A %a %U:%G %n' /usr/sbin/apache2

A correctly installed executable would typically have permissions similar to:

-rwxr-xr-x 755 root:root /usr/sbin/apache2

The x characters represent execute permission.

For example, if the permissions were incorrectly changed to:

-rw-r--r--

the executable would lack execution permission.

This can prevent Apache from starting successfully.

Step 5: Inspect the complete path permissions.

Execute:

namei -l /usr/sbin/apache2

This examines the permission bits and ownership of each directory component leading to the executable.

It helps distinguish between:

A non-executable Apache binary.

A directory that lacks search permission.

Incorrect ownership or permissions elsewhere in the path.

Also verify which package owns the executable:

dpkg -S /usr/sbin/apache2

On Ubuntu, it normally belongs to the apache2-bin package.

If required, check package-file integrity:

sudo dpkg -V apache2-bin

Package verification can help identify unexpectedly modified permissions or file contents.

Step 6: Correct the executable permission if it is the source of the failure.

In the supplied video, the candidate executes:

sudo chmod +x /usr/sbin/apache2

This is an important observation.

The command adds execute permission to the Apache executable according to the applicable chmod rules.

However, the candidate does not visibly demonstrate the earlier diagnostic output proving that missing execute permission caused the failure.

If the executable genuinely lacks its required execute permission, restore its expected mode:

sudo chmod 755 /usr/sbin/apache2

chmod changes file permissions.

755 grants read, write and execute permissions to the owner.

755 grants read and execute permissions to the group.

755 grants read and execute permissions to other users.

This is appropriate for a standard root-owned Apache executable when its mode has been incorrectly changed.

Do not execute this as a universal fix if the actual failure is a configuration error or port conflict.

Step 7: Verify the corrected permissions.

Execute:

ls -l /usr/sbin/apache2

Expected permissions, assuming the standard installation:

-rwxr-xr-x

For numerical verification:

stat -c '%a %n' /usr/sbin/apache2

Expected:

755 /usr/sbin/apache2

If the file's ownership is also incorrect, compare it with the package's expected ownership before making additional changes.

Step 8: Check the Apache configuration syntax.

Execute:

sudo apache2ctl configtest

This checks the Apache configuration for syntax errors.

For a valid configuration, the expected output is:

Syntax OK

The Apache control utility supports the configtest operation specifically for validating configuration syntax.

Apache HTTP Server Version 2.4

If it reports an error, inspect the identified file and line.

For example, an illustrative error might be:

Syntax error on line 42 of /etc/apache2/apache2.conf

Invalid command 'InvalidDirective'

In that case, correct the configuration directive instead of modifying executable permissions.

A successful syntax check does not guarantee that Apache can start, but it eliminates many configuration-related problems.

Step 9: Check whether Apache's required network ports are available.

Apache commonly listens on TCP port 80 for HTTP and port 443 for HTTPS.

Execute:

sudo ss -ltnp

To examine those ports specifically:

sudo ss -ltnp | grep -E ':(80|443)\b'

If another service already occupies a port configured for Apache, startup may fail with an address-binding error.

The official Apache documentation identifies port-binding conflicts as a common startup failure.

Apache HTTP Server Version 2.4

Do not stop another service unless the diagnostic evidence establishes that it is the source of the problem and the change is appropriate.

Step 10: Check Apache's own error log if necessary.

Execute:

sudo tail -n 50 /var/log/apache2/error.log

This displays recent entries from the standard Ubuntu Apache error log.

The file may contain additional details not included in the systemd journal.

Look for permission errors, configuration failures, missing resources or binding errors.

If the executable-permission repair was the only required correction, there may be no additional configuration changes to make.

Step 11: Start the Apache service.

After correcting the identified problem, execute:

sudo systemctl start apache2

sudo provides administrative privileges.

systemctl manages systemd services.

start requests that the specified service begin running.

apache2 identifies the Apache service unit.

This command directly satisfies the task's instruction to start the systemd service.

In the video, the candidate uses:

sudo systemctl restart apache2

The restart operation stops and starts an active service or starts it when appropriate.

Either operation can result in Apache running, but systemctl start apache2 is the more direct choice when the service is currently stopped or failed.

Step 12: Verify that Apache is running.

Execute:

sudo systemctl status apache2

Expected successful status:

● apache2.service - The Apache HTTP Server

Loaded: loaded

Active: active (running)

The critical field is:

Active: active (running)

This indicates that systemd considers the service active.

The official systemctl documentation defines the status command as the way to inspect the current runtime state of a service unit.

Linux manual page

Step 13: Verify the active service state directly.

Execute:

systemctl is-active apache2

Expected output:

active

Check the exit status immediately afterward:

echo $?

Expected:

0

The service is considered active when systemctl is-active returns active with a successful exit status.

Step 14: Verify that Apache is listening for connections.

Execute:

sudo ss -ltnp | grep apache2

This should display Apache processes listening on the ports specified in its configuration, provided those sockets can be associated with the process in the command output.

Alternatively, check the configured HTTP port:

sudo ss -ltnp | grep ':80'

An illustrative successful result might include:

LISTEN 0 511 0.0.0.0:80 0.0.0.0:*

The actual listening address and ports depend on Apache's configuration.

Step 15: Test the Apache HTTP service.

Execute:

curl -I http://localhost

This sends an HTTP HEAD request to the local web server.

An example of a successful HTTP response is:

HTTP/1.1 200 OK

Server: Apache/2.4.x (Ubuntu)

Content-Type: text/html

The exact response code depends on the website's configuration. For example, a redirect or authentication response can still show that Apache is accepting connections.

If the service is active but HTTP requests fail, inspect its listener configuration and logs.

Step 16: Confirm that the service remains running.

Execute:

sleep 5

systemctl is-active apache2

Expected:

active

This additional check helps detect a service that starts briefly and then fails.

You can also inspect recent logs:

sudo journalctl -u apache2 -n 20 --no-pager

Confirm that no further startup or runtime failures have occurred.

Step 17: Perform final verification.

Execute:

sudo apache2ctl configtest

systemctl is-active apache2

sudo systemctl status apache2 --no-pager

curl -I http://localhost

The final requirements are:

Verification

Expected result

Apache configuration test

Syntax OK

Apache executable permission

Valid executable permissions

systemd service status

active (running)

HTTP connectivity

A valid response from the configured service

Original startup failure

Resolved

Final Solution

The video suggests the failure may be related to execute permission on /usr/sbin/apache2. The following is the concise command sequence for that specific confirmed failure.

1. Connect to the server.

ssh lfcs00101a

2. Check the service failure.

sudo systemctl status apache2

sudo journalctl -u apache2 -n 50 --no-pager

3. Inspect the Apache executable permissions.

ls -l /usr/sbin/apache2

4. Restore executable permissions if they are incorrect.

sudo chmod 755 /usr/sbin/apache2

5. Validate the Apache configuration.

sudo apache2ctl configtest

6. Start the Apache service.

sudo systemctl start apache2

7. Verify the running service.

sudo systemctl status apache2

systemctl is-active apache2

Expected:

active

8. Verify HTTP connectivity.

curl -I http://localhost

Technical Verification and References

The procedures are consistent with official Apache and systemd documentation:

Apache HTTP Server — apachectl and configtest

Apache HTTP Server — Startup and Troubleshooting

Linux systemctl — Managing Service Units

systemd journalctl — Service Log Inspection

Expected result: The cause preventing apache2 from starting is corrected, and the service is successfully started with systemd and remains in the active (running) state.

Video verification finding: The candidate visibly runs sudo chmod +x /usr/sbin/apache2 and then attempts to restart Apache. That is a valid repair if missing executable permission was the actual fault, but the visible commands do not independently prove the diagnosis or final service state. The diagnostic and verification steps above are necessary for a reliable solution.