LFCS Exam Dumps - Linux Foundation Certified SYSADMIN Questions and Answers

Objective: Configure persistent Linux resource limits for the existing user james, ensuring that:

The hard process limit is 32768.

The soft process limit is 16384.

The limits are applied when the user starts a new PAM-managed login session.

The configuration remains available after a system reboot.

The appropriate solution uses Linux-PAM's resource-limit configuration, typically in /etc/security/limits.d/.

The official Linux-PAM documentation specifies the configuration syntax and confirms that nproc is the resource identifier for process limits.

Step 1: Connect to the correct Linux server.

The video specifies host lfcs00089.

From the candidate terminal, execute:

ssh lfcs00089

This establishes an SSH session with the designated server.

All subsequent configuration changes must be performed on this host.

Step 2: Verify that the user james exists.

Execute:

id james

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

Example output:

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

The numeric identifiers may differ on the actual server.

You can also check the account database:

getent passwd james

The task specifies an existing user, so there is no need to create a new account or modify the user's password.

Step 3: Understand soft and hard process limits.

Linux implements process-related resource restrictions using RLIMIT_NPROC.

Limit

Required value

Purpose

Soft

16384

Default process/thread creation limit enforced for the user's processes

Hard

32768

Maximum value to which an unprivileged user may raise the soft limit

The hard limit must be at least as large as the soft limit. Here:

\[ 16384 \leq 32768 \]

Therefore, the requested configuration is valid.

On Linux, RLIMIT_NPROC actually accounts for processes and threads associated with the real user ID, subject to kernel privilege exceptions. It is not a separate allowance for every running application.

Step 4: Inspect any existing persistent limits.

Before changing the system, execute:

sudo cat /etc/security/limits.conf

Then list any existing supplemental configuration files:

sudo ls -la /etc/security/limits.d/

Search specifically for process-limit settings:

sudo grep -RnsE \

'^[[:space:]]*([^#[:space:]] +[[:space:]]+)+(soft|hard|-)[[:space:]] +nproc' \

/etc/security/limits.conf /etc/security/limits.d/ 2 > /dev/null

Also check for any existing entries concerning james:

sudo grep -RnsE '^[[:space:]]*james[[:space:]] ' \

/etc/security/limits.conf /etc/security/limits.d/ 2 > /dev/null

These checks help identify existing user-specific limits and avoid contradictory configuration entries.

Step 5: Understand the persistent configuration locations.

The primary resource-limit configuration file is:

/etc/security/limits.conf

Additional administrator-defined limits can be stored under:

/etc/security/limits.d/

Both locations are supported by Linux-PAM.

The configuration format is:

< domain > < type > < item > < value >

For this task:

Field

Required value

Description

Domain

james

Existing username

Type

soft or hard

Which resource limit to configure

Item

nproc

Number of processes/threads

Value

16384 or 32768

Required limit

A dedicated configuration file is preferable because it keeps the account-specific policy separate from the system's general resource-limit settings.

Step 6: Create the persistent configuration file.

Execute:

sudo nano /etc/security/limits.d/90-james-nproc.conf

This opens a new configuration file.

If the file already exists, inspect its contents before modifying it.

Step 7: Add the required soft and hard process limits.

Insert the following two lines:

james soft nproc 16384

james hard nproc 32768

This is the exact configuration required for the task.

Explanation of the first line:

james soft nproc 16384

james selects the target user.

soft specifies the default soft resource limit.

nproc refers to the process/thread limit.

16384 establishes the required soft value.

Explanation of the second line:

james hard nproc 32768

james selects the same user.

hard specifies the hard resource limit.

nproc identifies the resource.

32768 establishes the maximum hard value.

These settings apply specifically to james rather than all users.

The Linux-PAM manual explicitly supports user-specific soft and hard nproc entries.

Step 8: Save the configuration.

If using Nano:

Press Ctrl + O to save.

Press Enter to confirm the filename.

Press Ctrl + X to exit.

If using Vim:

Press Esc.

Type :wq.

Press Enter.

The file should be located at:

/etc/security/limits.d/90-james-nproc.conf

Step 9: Verify the saved configuration.

Execute:

sudo cat /etc/security/limits.d/90-james-nproc.conf

Expected output:

james soft nproc 16384

james hard nproc 32768

Check the file permissions:

ls -l /etc/security/limits.d/90-james-nproc.conf

A typical configuration file has permissions of 644 and is owned by root.

If the file permissions are incorrect, restore appropriate permissions:

sudo chmod 644 /etc/security/limits.d/90-james-nproc.conf

The file should be readable by the PAM module when login sessions are established.

Step 10: Verify that PAM applies resource limits.

The settings are interpreted by the PAM module:

pam_limits.so

Check whether the module is configured:

sudo grep -Rns 'pam_limits.so' /etc/pam.d/

A relevant configuration entry resembles:

session required pam_limits.so

session identifies the PAM session-management phase.

required means the module must succeed for the relevant PAM operation to succeed.

pam_limits.so applies the configured resource limits when the session is established.

The official Linux-PAM documentation confirms that this module applies resource limits to user sessions.

On Ubuntu, inspect the PAM configuration used by the relevant login method, including sshd, login, su, and any referenced common-session files.

Do not blindly add duplicate pam_limits.so entries. If the module is absent from the actual login path, configure it appropriately before testing.

Step 11: Understand when the changes take effect.

The limits defined in /etc/security/limits.d/90-james-nproc.conf are persistent settings, but they are not automatically applied to every currently running process.

Linux-PAM applies these limits when an applicable new login session begins.

Therefore:

Existing sessions may retain their previous limits.

New PAM-managed sessions can receive the new values.

Changes survive reboot because the configuration is stored on disk.

There is no need to restart the entire operating system simply to load the configuration.

The Linux-PAM manual specifically explains that configured resource limits are applied per login session.

Step 12: Start a fresh session as james.

If you have administrative access, you can attempt to create a new login session with:

sudo su - james

This starts a login-style shell using the su PAM service, provided that service is configured to apply PAM resource limits.

Alternatively, open a new SSH login as james, using the account's existing credentials if permitted:

ssh james@localhost

A fresh SSH login is particularly useful if the actual login service is the intended target of the configuration.

Check the active user:

whoami

Expected:

james

Do not assume that simply running sudo -u james ulimit ... is a valid test. ulimit is a shell builtin, and changing the execution user does not necessarily create a PAM session or apply its resource-limit policy.

Step 13: Verify the soft process limit.

Inside the new login session belonging to james, execute:

ulimit -Su

ulimit displays or controls process resource limits.

-S selects the soft limit.

-u selects the maximum process/thread resource limit.

Expected output:

16384

This confirms that the session received the required soft limit.

Step 14: Verify the hard process limit.

In the same session, execute:

ulimit -Hu

-H selects the hard limit.

-u selects the process/thread resource limit.

Expected output:

32768

The GNU Bash manual confirms that -S and -H distinguish soft and hard limits, and that -u refers to the maximum number of processes available to a user.

Step 15: Verify both limits together.

Execute:

printf 'Soft limit: '

ulimit -Su

printf 'Hard limit: '

ulimit -Hu

Expected output:

Soft limit: 16384

Hard limit: 32768

This is the most direct practical verification of the two requested values.

Step 16: Verify the kernel's process-limit information.

Linux also exposes resource limits through the /proc filesystem.

Inside the new james session, execute:

cat /proc/self/limits

Find the line:

Max processes

The relevant values should be:

Limit Soft Limit Hard Limit

Max processes 16384 32768

The displayed output contains additional columns and other resource limits, but the Max processes entry is the one relevant to this task.

For a more concise check, execute:

grep 'Max processes' /proc/self/limits

Expected values:

Max processes 16384 32768

You can also use:

prlimit --pid $$

This displays resource limits for the current shell process.

Step 17: Check for conflicting limits if the values are incorrect.

If the new session does not show the required values, investigate rather than repeatedly adding duplicate configuration entries.

First, inspect user-specific rules:

sudo grep -Rns 'james' \

/etc/security/limits.conf /etc/security/limits.d/

Next, inspect all process-limit rules:

sudo grep -Rns 'nproc' \

/etc/security/limits.conf /etc/security/limits.d/

Then check whether pam_limits.so is active in the login method used for testing.

Potential reasons for an unexpected value include an overriding limits configuration, a session started without PAM resource-limit processing, or resource limits imposed by a systemd-managed service.

If the user runs an application under a systemd service, systemd's LimitNPROC= setting may also be relevant. However, configuring a systemd service is not required by the task.

Step 18: Verify persistence.

The persistent configuration resides at:

/etc/security/limits.d/90-james-nproc.conf

Execute:

sudo cat /etc/security/limits.d/90-james-nproc.conf

Expected:

james soft nproc 16384

james hard nproc 32768

Because this configuration is stored under /etc, it remains present after the system reboots unless it is changed or removed.

For end-to-end verification, start a fresh login session after reboot and repeat:

ulimit -Su

ulimit -Hu

Expected:

16384

32768

A reboot is not necessary for normal verification, and should not be performed unnecessarily during the LFCS exam.

Step 19: Confirm that unrelated users remain unchanged.

The file contains rules for:

james

It does not use the wildcard:

*

Therefore, this particular configuration does not apply indiscriminately to all users.

Avoid adding entries such as:

* soft nproc 16384

* hard nproc 32768

Those would impose the specified limits more broadly, instead of targeting the user named in the task.

Step 20: Perform final verification.

The final configuration must satisfy all requirements:

Requirement

Expected result

Existing user

james

Resource type

nproc

Soft limit

16384

Hard limit

32768

Persistent configuration

Present

Fresh login session

Correct limits applied

Other users

No unnecessary changes

Final Solution

The essential commands are:

Copy commands

# Connect to the correct server

ssh lfcs00089

# Verify the user exists

id james

# Create the persistent resource-limit configuration

printf '%s\n' \

'james soft nproc 16384' \

'james hard nproc 32768' | \

sudo tee /etc/security/limits.d/90-james-nproc.conf

# Verify the configuration

sudo cat /etc/security/limits.d/90-james-nproc.conf

# Confirm PAM resource-limit integration

sudo grep -Rns 'pam_limits.so' /etc/pam.d/

# Start a new PAM-managed login session

# (provided the su PAM stack applies pam_limits)

sudo su - james

# Verify the soft limit

ulimit -Su

# Verify the hard limit

ulimit -Hu

# Verify through procfs

grep 'Max processes' /proc/self/limits

The required configuration is:

james soft nproc 16384

james hard nproc 32768

Technical Verification and References

Linux-PAM limits.conf(5) — Confirms the configuration file syntax and nproc resource identifier.

Linux-PAM pam_limits(8) — Explains how limits are applied when PAM sessions are established.

GNU Bash — ulimit — Documents soft and hard resource-limit verification.

Linux getrlimit(2) — Defines the kernel's process-limit behavior.

Video verification finding: At approximately 29:01–29:05, Question 9 appears with host lfcs00089. The recording shows the full task statement but does not demonstrate the required configuration being completed. The solution above is independently validated against Linux-PAM documentation.

Expected result: User james receives a soft process limit of 16384 and a hard process limit of 32768 in applicable new login sessions. The settings are stored persistently and remain configured after reboot.

Objective: Configure the Linux NFS (Network File System) server so that two specified client hosts can access the same backup directory with different permissions.

The required configuration is:

NFS client

Required access

Export options

lfcs00098nfs1

Read and write (store backups)

rw,sync,insecure

lfcs00098nfs2

Read-only (restore backups)

ro,sync,insecure

The essential distinction is that the first client must be able to create and modify backup files, while the second client must be restricted to reading existing backup data.

The task explicitly requires the insecure option for both client hosts.

Linux NFS uses /etc/exports to configure which directories are shared, which hosts can access them, and which permissions apply.

Step 1: Connect to the correct Linux server.

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

From the candidate terminal, execute:

ssh lfcs00098

This establishes an SSH connection to the designated NFS server.

All NFS export configuration changes must be performed on this server, not on the client hosts.

Step 2: Verify that the NFS server software is installed.

On the Ubuntu environment shown in the video, the NFS server package is normally:

nfs-kernel-server

Check whether the package is installed:

dpkg -l nfs-kernel-server

You can also inspect the service:

systemctl status nfs-kernel-server

If the package is installed and the service is running, continue.

The task is to configure an existing NFS server, so do not reinstall packages unnecessarily.

Step 3: Verify that the backup directory exists.

The task specifies the NFS export directory:

/srv/backup

Execute:

ls -ld /srv/backup

This displays the directory's permissions, owner and group.

For example:

drwxr-xr-x 2 root root 4096 Oct 12 10:00 /srv/backup

The output above is illustrative.

If the directory does not exist, first establish whether the task environment is incomplete. If it is genuinely necessary to create the specified export point, execute:

sudo mkdir -p /srv/backup

Do not modify existing backup files or directory ownership unless needed for authorized client access.

Step 4: Inspect the existing NFS export configuration.

The primary NFS export configuration file is:

/etc/exports

Display its contents:

sudo cat /etc/exports

You can also inspect the configuration using:

sudo nano /etc/exports

The file defines local directories exported to NFS clients.

The general format is:

/directory client1(options) client2(options)

Each client hostname is immediately followed by its own parenthesized options.

There must be no space between the hostname and the opening parenthesis.

This syntax is explicitly documented in the Linux NFS exports(5) manual.

Step 5: Check the currently active NFS exports.

Execute:

sudo exportfs -v

This lists the currently active exports and their effective options.

Check whether /srv/backup is already exported and whether either required client already has an entry.

If an existing configuration is present, modify it carefully rather than creating overlapping or conflicting export entries.

Step 6: Verify that the NFS client hostnames can be resolved.

The task identifies two clients:

lfcs00098nfs1

lfcs00098nfs2

Check name resolution:

getent hosts lfcs00098nfs1

Then:

getent hosts lfcs00098nfs2

These commands query the operating system's configured hostname-resolution services.

Both hostnames should resolve correctly in the exam environment.

Do not replace these hostnames with invented IP addresses.

NFS export configuration supports hostnames, including single hostnames recognized by the system resolver.

Step 7: Back up the existing NFS exports configuration.

Before making changes, execute:

sudo cp -a /etc/exports /etc/exports.bak

This creates a backup copy while preserving file metadata.

It allows recovery if the configuration is accidentally modified incorrectly.

Step 8: Edit the /etc/exports file.

Execute:

sudo nano /etc/exports

Alternatively:

sudo vim /etc/exports

Navigate to the end of the file, or locate the existing export for /srv/backup if one is already present.

Step 9: Configure read/write access for the backup-storage client.

The first requirement is:

First, configure the NFS server to allow access to /srv/backup for host lfcs00098nfs1 to store backups.

The corresponding export configuration is:

/srv/backup lfcs00098nfs1(rw,sync,insecure)

/srv/backup

This is the directory that the NFS server makes available to the specified client.

lfcs00098nfs1

This is the only client identified by this entry.

rw — Read/Write

Allows the NFS client to perform both read and write operations, subject to the underlying filesystem permissions.

This is necessary because the client must store backups.

sync — Synchronous Writes

Makes the NFS server acknowledge write requests only after the relevant changes have been committed to stable storage, as defined by the NFS server's write semantics.

This is appropriate for backup data where durability matters.

insecure — Allow Unprivileged Source Ports

Normally, NFS's secure export behavior requires certain client requests to originate from a privileged port below 1024.

The insecure option relaxes this restriction, permitting requests from unprivileged source ports.

The task explicitly requires this option.

The official NFS manual confirms the behavior of rw, sync and insecure.

Step 10: Configure read-only access for the backup-restore client.

The second requirement is:

Next, configure the NFS server to allow access to /srv/backup for host lfcs00098nfs2 to restore backups only.

The corresponding configuration is:

/srv/backup lfcs00098nfs2(ro,sync,insecure)

lfcs00098nfs2

Specifies the second authorized NFS client.

ro — Read Only

Allows the client to read existing backup files but prevents writes through the NFS export.

This matches the requirement to restore backups only.

sync

Specifies synchronous server behavior. It is safe to include this option even though the export is read-only.

insecure

Allows requests from unprivileged client source ports, as explicitly requested.

The most important difference between the two client definitions is:

lfcs00098nfs1(rw,sync,insecure)

lfcs00098nfs2(ro,sync,insecure)

The second client must not be given rw access.

Step 11: Add the complete NFS export configuration.

The preferred combined entry in /etc/exports is:

/srv/backup lfcs00098nfs1(rw,sync,insecure) lfcs00098nfs2(ro,sync,insecure)

This single line defines the same exported directory with separate permissions for the two clients.

The configuration can also be expressed as two client-specific entries, provided the resulting export table is valid and does not contain conflicting definitions.

Using one line is concise and follows the official exports(5) syntax for multiple clients sharing an export path.

NFS server export table

Step 12: Save the NFS configuration file.

If using Nano, press Ctrl+O, Enter and Ctrl+X.

If using Vim, press Esc, type :wq, and press Enter.

Verify the saved configuration:

sudo cat /etc/exports

The file must contain:

/srv/backup lfcs00098nfs1(rw,sync,insecure) lfcs00098nfs2(ro,sync,insecure)

Preserve any unrelated exports already present on the system.

Step 13: Apply the NFS export configuration.

Execute:

sudo exportfs -ra

exportfs manages the NFS export table.

-r refreshes the export table from the configuration.

-a applies the operation to all configured exports.

This command reloads export definitions without requiring a complete operating system reboot.

For verbose output, you can execute:

sudo exportfs -rav

Ubuntu's official NFS server documentation and the Linux NFS manual describe using exportfs to apply changes made to /etc/exports.

Step 14: Verify the active NFS export configuration.

Execute:

sudo exportfs -v

The output should show /srv/backup exported to both client hosts.

The effective configuration must include the following permissions:

Client

Required effective access

lfcs00098nfs1

rw,insecure

lfcs00098nfs2

ro,insecure

The command may also display other default export options such as root_squash, wdelay, sec=sys, or no_subtree_check, depending on the installed version and configuration.

Their presence does not necessarily indicate an error.

What matters is that the two specified clients have the correct effective access and the required insecure option.

Step 15: Check the NFS server service.

Execute:

sudo systemctl status nfs-kernel-server

The service should report an active operating state.

For a concise check:

systemctl is-active nfs-kernel-server

Expected:

active

If the service is inactive, inspect the logs:

sudo journalctl -u nfs-kernel-server -n 50 --no-pager

If the service is installed and configured correctly but stopped, start it:

sudo systemctl start nfs-kernel-server

There is ordinarily no need to restart a healthy NFS server merely because export rules changed; exportfs -ra is designed to refresh the export table.

Step 16: Verify the backup directory permissions.

Execute:

ls -ld /srv/backup

NFS export permissions and Unix filesystem permissions are separate controls.

Even if lfcs00098nfs1 has an export configured with rw, its application user must also have the necessary filesystem permissions to write to the directory.

Likewise, ro at the export level prevents NFS writes from lfcs00098nfs2, regardless of permissive underlying file permissions.

Do not automatically execute:

sudo chmod 777 /srv/backup

This would unnecessarily grant broad filesystem access.

Also avoid adding:

no_root_squash

unless explicitly required.

The task does not request disabling NFS root squashing, and doing so could expose unnecessary privileges to clients.

Step 17: Verify NFS access from the backup-storage client.

If the client is accessible, connect to:

ssh lfcs00098nfs1

Create a temporary mountpoint:

sudo mkdir -p /mnt/lfcs-backup-test

Mount the NFS export, using the actual NFS server hostname and a protocol version supported by the server:

sudo mount -t nfs lfcs00098:/srv/backup /mnt/lfcs-backup-test

Verify the mount:

findmnt /mnt/lfcs-backup-test

Using a client identity authorized to write to the backup directory, test file creation:

touch /mnt/lfcs-backup-test/lfcs-write-test

If the directory permissions permit this identity to write, the command should succeed.

This tests the read/write access requested for lfcs00098nfs1.

Root access from the client may be mapped to an unprivileged user because of NFS root squashing, so a failure when using root does not automatically mean that the export is configured incorrectly.

Step 18: Verify read-only access from the restore client.

Connect to:

ssh lfcs00098nfs2

Create a mountpoint if necessary:

sudo mkdir -p /mnt/lfcs-backup-test

Mount the export:

sudo mount -t nfs lfcs00098:/srv/backup /mnt/lfcs-backup-test

Verify that backup files can be listed and read:

ls -la /mnt/lfcs-backup-test

Where a readable file is available, open or inspect it using a suitable command.

Next, attempt to create a temporary file:

touch /mnt/lfcs-backup-test/lfcs-readonly-test

This operation must fail because the export is read-only.

An illustrative error is:

Read-only file system

Even if the error wording differs, the important result is that write access is denied by the server.

Step 19: Clean up any test resources.

On the writing client, remove only the temporary verification file you created:

rm -f /mnt/lfcs-backup-test/lfcs-write-test

Unmount the temporary client mount:

sudo umount /mnt/lfcs-backup-test

Repeat the unmount on the other client.

Do not delete or alter actual backup files.

Step 20: Perform final verification on the NFS server.

Reconnect to the NFS server:

ssh lfcs00098

Verify the persistent configuration:

sudo grep '/srv/backup' /etc/exports

Expected:

/srv/backup lfcs00098nfs1(rw,sync,insecure) lfcs00098nfs2(ro,sync,insecure)

Verify the active exports:

sudo exportfs -v

Confirm NFS service health:

systemctl is-active nfs-kernel-server

The final state must satisfy every requirement.

Requirement

Expected result

Exported directory

/srv/backup

Backup-storage client

lfcs00098nfs1

Backup-storage access

Read/write

Backup-restore client

lfcs00098nfs2

Backup-restore access

Read-only

insecure for first client

Present

insecure for second client

Present

Active exports

Correctly refreshed

NFS service

Active

Final Solution

The essential server-side commands are:

# Connect to the NFS server

ssh lfcs00098

# Check the export directory

ls -ld /srv/backup

# Examine existing exports

sudo cat /etc/exports

sudo exportfs -v

# Back up the configuration

sudo cp -a /etc/exports /etc/exports.bak

# Edit the exports file

sudo nano /etc/exports

Add or update the /srv/backup entry to read:

/srv/backup lfcs00098nfs1(rw,sync,insecure) lfcs00098nfs2(ro,sync,insecure)

Save and execute:

# Apply changes

sudo exportfs -ra

# Verify active exports

sudo exportfs -v

# Confirm NFS service status

systemctl is-active nfs-kernel-server

# Verify persistent configuration

sudo grep '/srv/backup' /etc/exports

Technical Verification and References

The solution has been checked against the official Linux NFS manuals and Ubuntu Server documentation.

Linux NFS exports(5) — Defines the export configuration syntax, rw, ro, sync and insecure options.

Ubuntu Server — Network File System (NFS) — Documents the NFS server configuration and export-management procedure.

Linux exportfs(8) — Documents reloading, managing and displaying active exports.

Video verification finding: Task 10 identifies the NFS server lfcs00098 and requires separate access modes for lfcs00098nfs1 and lfcs00098nfs2. The essential answer is the NFS export configuration above. Actual client access must be tested on the relevant systems; correct syntax alone does not establish that network connectivity and filesystem permissions are functioning.

Expected result: The NFS server exports /srv/backup to lfcs00098nfs1 with read/write access and to lfcs00098nfs2 with read-only access. Both client configurations explicitly include insecure, and the settings remain persistent in /etc/exports.

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 Linux server.

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

From the candidate terminal, execute:

ssh lfcs00100

This establishes an SSH connection to the designated server.

All remaining commands must be executed on this host.

Step 2: Navigate to the existing Git repository.

Execute:

cd ~/optimal-bedbug

- cd changes the current directory.

- ~ refers to the current user's home directory.

- optimal-bedbug is the existing Git repository specified in the task.

Verify the current working directory:

pwd

List the repository contents:

ls -la

Check whether it is a valid Git repository:

git rev-parse --show-toplevel

The output should identify the root directory of optimal-bedbug.

The repository is already cloned. Therefore, there is no requirement to execute git init or git clone.

Step 3: Inspect the repository status.

Execute:

git status

This displays the current branch, modified files, staged changes, and working tree status.

Also execute:

git branch --show-current

This identifies the active branch.

Check the configured remote:

git remote -v

An example output might be:

origin git@example.com:training/optimal-bedbug.git (fetch)

origin git@example.com:training/optimal-bedbug.git (push)

The remote URL is illustrative. Use the remote already configured in the existing repository.

Do not modify unrelated repository configuration.

Step 4: Locate and inspect the hosts file.

Execute:

ls -l hosts

Display its complete contents:

cat hosts

The task requires editing the file named hosts in the repository.

Locate the section:

[webservers]

This is an inventory-style group heading.

The entries belonging to [webservers] appear below the heading and continue until the next group heading or the end of the file.

Step 5: Identify the commented host entries.

To display the [webservers] section, execute:

awk '

/^\[webservers\]$/ {inside=1; print; next}

/^\[/ {inside=0}

inside {print}

' hosts

- awk processes the file line by line.

- /^\[webservers\]$/ identifies the exact group heading.

- inside=1 enables output for the selected group.

- /^\[/ identifies a subsequent group heading.

- inside=0 stops output when another group begins.

- inside {print} displays entries belonging to [webservers].

Look for host entries beginning with #.

For illustration, the original section might look like:

[webservers]

#192.168.10.11

#192.168.10.12

192.168.10.13

#192.168.10.14

[dbservers]

#192.168.20.11

192.168.20.12

These addresses are examples only. Preserve the actual addresses and hostnames found in the video environment.

The task requires uncommenting all host entries in [webservers] only.

Step 6: Edit the hosts file.

Open the file using Nano:

nano hosts

Alternatively, use Vim:

vim hosts

Navigate to:

[webservers]

Remove the leading comment character # from every commented host entry in that group.

For example:

Before:

[webservers]

#192.168.10.11

#192.168.10.12

192.168.10.13

#192.168.10.14

[dbservers]

#192.168.20.11

192.168.20.12

After:

[webservers]

192.168.10.11

192.168.10.12

192.168.10.13

192.168.10.14

[dbservers]

#192.168.20.11

192.168.20.12

Important requirements:

- Remove # only from commented host entries belonging to [webservers].

- Do not remove the [webservers] group heading.

- Do not change the IP addresses or hostnames.

- Do not uncomment entries belonging to other groups.

- Do not remove comments that are descriptive notes rather than host entries.

- Preserve the original file structure and unrelated content.

Step 7: Save the modified file.

If using Nano:

1. Press Ctrl + O.

2. Press Enter to save.

3. Press Ctrl + X to exit.

If using Vim:

1. Press Esc.

2. Type :wq.

3. Press Enter.

Step 8: Verify the changes before committing.

Execute:

git diff -- hosts

This displays the difference between the working version of hosts and its previous Git version.

For example:

[webservers]

-#192.168.10.11

-#192.168.10.12

+192.168.10.11

+192.168.10.12

192.168.10.13

-#192.168.10.14

+192.168.10.14

- Lines beginning with - were removed from the previous file version.

- Lines beginning with + were added.

- Unprefixed context lines are unchanged.

Confirm that the differences are limited to the requested modifications.

If unrelated lines have changed accidentally, correct them before proceeding.

Step 9: Stage the modified hosts file.

Execute:

git add hosts

git add places the current file contents into Git's staging area, also called the index.

This prepares the modification for the next commit.

Do not use:

git add .

because it stages all changed files under the current directory, potentially including unrelated modifications.

The task specifically concerns the hosts file.

Step 10: Verify the staged changes.

Execute:

git diff --cached -- hosts

This shows the changes staged for the commit.

Also check:

git diff --cached --name-only

Ideally, the only staged file should be:

hosts

If unrelated changes were previously staged, avoid including them in this task's commit.

Step 11: Commit the changes using the exact required message.

Execute:

git commit -m "Enables missing hosts"

- git commit creates a new commit from the staging area.

- -m provides the commit message directly.

- "Enables missing hosts" is the exact message specified in the task.

Do not change the spelling or capitalization.

A successful commit may produce output similar to:

[main a1b2c3d] Enables missing hosts

1 file changed, 3 insertions(+), 3 deletions(-)

The branch name, commit hash and change count will depend on the actual repository.

If unrelated changes are already staged, use the file-specific commit operation instead:

git commit --only -m "Enables missing hosts" -- hosts

This creates a commit containing the selected file's modification rather than unrelated staged files.

Step 12: Verify that the commit was created.

Execute:

git log -1 --oneline

The most recent commit should have the required message.

For example:

a1b2c3d Enables missing hosts

Check which files were included in the commit:

git show --stat --oneline HEAD

The commit should contain the requested modification to hosts.

You can inspect the full commit:

git show --format=fuller HEAD -- hosts

This confirms the exact lines committed.

Step 13: Push the commit to the remote repository.

Execute:

git push

The git push command transfers local commits to the configured remote repository and updates the destination branch.

If the current branch already tracks a remote branch, this should be sufficient.

A successful push may display output similar to:

To git@example.com:training/optimal-bedbug.git

123abcd..a1b2c3d main - > main

If Git reports that no upstream branch is configured, first inspect:

git remote -v

git branch --show-current

If the intended remote is origin, execute:

git push -u origin HEAD

- -u configures upstream tracking for the successfully pushed branch.

- origin specifies the destination remote.

- HEAD refers to the current local branch.

Do not use git push --force. Force-pushing can overwrite remote history and is not required by this task.

Git's official documentation confirms that git push updates remote references and that --set-upstream configures branch tracking.

git-push Documentation

Step 14: Verify that the push completed successfully.

Execute:

git status -sb

Inspect the branch's tracking relationship and whether any commits remain ahead of the remote-tracking branch.

Next:

git branch -vv

This displays the local branches and their upstream tracking information.

To check whether your latest commit has reached the configured upstream, execute:

git rev-parse HEAD

git rev-parse '@{upstream}'

For a straightforward successful push of the current branch, both hashes should normally be identical.

You can also check whether any local commits remain unpushed:

git log '@{upstream}..HEAD' --oneline

If it produces no output, the local branch contains no commits ahead of its upstream tracking reference.

A clean working tree alone does not prove a successful push. The remote update must succeed separately.

Step 15: Perform the final verification.

Execute:

cd ~/optimal-bedbug

git status

git log -1 --oneline

git show --format= --name-only HEAD

git branch -vv

Then inspect the [webservers] section again:

awk '

/^\[webservers\]$/ {inside=1; print; next}

/^\[/ {inside=0}

inside {print}

' hosts

Confirm that all required host entries are uncommented.

Final Solution

Essential commands in execution order

Copy commands

ssh lfcs00100

cd ~/optimal-bedbug

# Examine the repository and inventory

git status

cat hosts

# Edit the file

nano hosts

# Uncomment all host entries under [webservers]

# Save and close the editor

# Review the changes

git diff -- hosts

# Stage the modified file

git add hosts

# Verify staged changes

git diff --cached -- hosts

# Commit using the exact message

git commit -m "Enables missing hosts"

# Push to the configured remote

git push

# Final verification

git log -1 --oneline

git status -sb

Technical Verification and References

The solution has been checked against the official Git documentation.

- Git add: Adds modified file contents to the staging area in preparation for a commit.

GitHub

- Git commit: Records staged modifications as a new commit using the specified commit message.

git-commit Documentation

- Git push: Transfers commits to the configured remote repository and updates remote branch references.

git-push Documentation

Official documentation: Git Command Reference.

Expected result: All host entries within [webservers] in ~/optimal-bedbug/hosts are uncommented. The modification is committed with the exact message Enables missing hosts, and the new commit is successfully pushed to the remote repository.

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.