Task
Persistently configure the OpenSSH daemon to allow keyboard-interactive authentication for user jack.
Do not modify the user's password.
Do not modify any other user's ability to log in.
See the complete solution in Explanation.
Step 1: Connect to the correct Linux server.
The video specifies that this task must be performed on host lfcs00073.
From the candidate terminal, execute:
ssh candidate@lfcs00073
This establishes an SSH connection to the designated Linux server.
All subsequent configuration changes must be performed on this host.
Step 2: Verify that user jack exists.
Execute:
id jack
This displays the user's UID, primary group and supplementary groups.
An example of valid output is:
uid=1001(jack) gid=1001(jack) groups=1001(jack)
The numerical IDs may differ.
You can also verify the account through the system user database:
getent passwd jack
The task requires modifying SSH authentication, not creating or modifying the user account.
Do not execute passwd jack or change the user's existing password.
Step 3: Identify the OpenSSH daemon configuration file.
The primary OpenSSH server configuration file on Ubuntu is:
/etc/ssh/sshd_config
Additionally, OpenSSH may load configuration fragments from:
/etc/ssh/sshd_config.d/
Inspect the primary configuration file:
sudo cat /etc/ssh/sshd_config
Check whether additional configuration files exist:
sudo ls -la /etc/ssh/sshd_config.d/
The effective OpenSSH configuration may depend on directives in both locations.
Step 4: Identify the existing authentication settings.
Execute:
sudo grep -RniE \
'KbdInteractiveAuthentication|ChallengeResponseAuthentication|UsePAM|AuthenticationMethods|Match' \
/etc/ssh/sshd_config /etc/ssh/sshd_config.d/ 2 > /dev/null
This searches for authentication-related directives.
The most important directive is:
KbdInteractiveAuthentication
It controls whether the SSH daemon permits keyboard-interactive authentication.
Possible values:
Configuration
Meaning
KbdInteractiveAuthentication yes
Permits keyboard-interactive authentication
KbdInteractiveAuthentication no
Disables keyboard-interactive authentication
On Ubuntu 22.04, the packaged OpenSSH configuration commonly disables keyboard-interactive authentication globally while enabling PAM.
OpenSSH daemon configuration file
However, the task requires the method to be enabled specifically for jack, without changing other users' login ability.
Therefore, simply changing the global directive from no to yes is not the appropriate solution.
Step 5: Examine the effective configuration before changing anything.
Execute:
sudo sshd -T \
-C user=jack,host=localhost,addr=127.0.0.1
This displays the effective SSH daemon configuration for a connection matching user jack.
To filter the relevant settings:
sudo sshd -T \
-C user=jack,host=localhost,addr=127.0.0.1 \
| grep -E 'kbdinteractiveauthentication|usepam|authenticationmethods'
For example, an initial configuration might show:
kbdinteractiveauthentication no
usepam yes
authenticationmethods any
This is an illustrative output. The actual values must be checked on the server.
Also record the same settings for another existing user, such as candidate:
sudo sshd -T \
-C user=candidate,host=localhost,addr=127.0.0.1 \
| grep -E 'kbdinteractiveauthentication|usepam|authenticationmethods'
These baseline values will be useful when verifying that other users remain unaffected.
Step 6: Back up the existing OpenSSH configuration.
Before modifying the daemon configuration, execute:
sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
cp copies the configuration file.
-a preserves ownership, permissions and other file metadata.
/etc/ssh/sshd_config.bak is the backup copy.
If a configuration error occurs, the original file can be restored.
Keep the existing SSH session open while making these changes.
Step 7: Edit the OpenSSH daemon configuration.
Open the configuration file:
sudo nano /etc/ssh/sshd_config
Alternatively, use Vim:
sudo vim /etc/ssh/sshd_config
Review any existing Match directives before adding the required configuration.
Step 8: Configure keyboard-interactive authentication specifically for jack.
Provided no earlier matching block takes precedence, append the following configuration at the end of /etc/ssh/sshd_config:
Match User jack
KbdInteractiveAuthentication yes
This is the central configuration required for the task.
Match User jack
The Match directive begins a conditional configuration section.
The User jack condition means that the directives inside this section apply to connections authenticating as jack.
KbdInteractiveAuthentication yes
This enables keyboard-interactive authentication for connections satisfying the preceding Match condition.
Other users do not match User jack, so they retain their existing global or user-specific settings.
OpenSSH's official documentation permits KbdInteractiveAuthentication inside a Match section.
OpenSSH daemon configuration file
Important: If the existing configuration already contains a matching Match User jack or Match All block setting this option, edit the appropriate existing rule instead. OpenSSH generally uses the first occurrence of a directive among satisfied Match blocks. Simply appending a later block may not override an earlier matching rule.
Step 9: Save the configuration file.
If using Nano:
Press Ctrl + O to save.
Press Enter to confirm.
Press Ctrl + X to exit.
If using Vim, press Esc, type :wq, and press Enter.
The modified file should contain the user-specific rule:
Match User jack
KbdInteractiveAuthentication yes
Do not add a global AllowUsers jack rule. That could prevent other users from logging in and would violate the task.
Step 10: Verify the PAM authentication setting.
Execute:
sudo sshd -T \
-C user=jack,host=localhost,addr=127.0.0.1 \
| grep usepam
For the normal Ubuntu PAM-based authentication setup, the expected configuration is:
usepam yes
UsePAM yes allows OpenSSH to use PAM for keyboard-interactive authentication.
On Ubuntu, this directive normally appears in the global configuration.
Do not place UsePAM inside the Match User jack block. It is not a valid Match-specific directive in the relevant OpenSSH configuration.
If PAM is globally disabled, investigate the existing authentication design before changing it. Enabling PAM globally could affect other users, contrary to the task's constraints.
Step 11: Validate the SSH configuration syntax.
Before reloading the daemon, execute:
sudo sshd -t
sshd is the OpenSSH server daemon.
-t validates the configuration and checks relevant server key requirements.
A successful validation normally produces no output and returns exit code 0.
Check the result:
echo $?
Expected:
0
If errors are displayed, correct them before proceeding.
Do not restart or reload SSH with an invalid configuration.
Step 12: Verify that keyboard-interactive authentication is enabled for jack.
Execute:
sudo sshd -T \
-C user=jack,host=localhost,addr=127.0.0.1 \
| grep kbdinteractiveauthentication
Expected output:
kbdinteractiveauthentication yes
This confirms the effective server configuration for the specified user and connection context.
Unlike simply inspecting the configuration file, sshd -T -C evaluates applicable Match rules.
OpenSSH daemon
Step 13: Confirm that other users' authentication settings have not changed.
Execute:
sudo sshd -T \
-C user=candidate,host=localhost,addr=127.0.0.1 \
| grep -E 'kbdinteractiveauthentication|usepam|authenticationmethods'
Compare the output with the baseline recorded in Step 5.
If the original configuration had keyboard-interactive authentication disabled for candidate, it should remain disabled.
For example:
kbdinteractiveauthentication no
usepam yes
authenticationmethods any
The important requirement is that other users retain their original effective authentication settings, not that every server necessarily produces these example values.
Also verify any existing AuthenticationMethods policy. If it requires a method sequence that excludes standalone keyboard-interactive authentication, simply enabling KbdInteractiveAuthentication may not permit a keyboard-interactive-only login. Any necessary adjustment must remain specific to jack.
Step 14: Reload the OpenSSH daemon.
After verifying the configuration, execute:
sudo systemctl reload ssh
On Ubuntu, the systemd service is normally named ssh.
Reloading causes the daemon to apply its updated configuration without unnecessarily terminating established SSH sessions.
Step 15: Verify the SSH service is operational.
Execute:
sudo systemctl status ssh --no-pager
Expected active status:
Active: active (running)
You can also execute:
systemctl is-active ssh
Expected:
active
Step 16: Test keyboard-interactive authentication for jack.
From a separate SSH session, execute:
ssh -o PreferredAuthentications=keyboard-interactive \
-o PubkeyAuthentication=no \
-o PasswordAuthentication=no \
jack@localhost
PreferredAuthentications=keyboard-interactive selects keyboard-interactive authentication.
PubkeyAuthentication=no prevents the client from authenticating using a public key.
PasswordAuthentication=no disables the separate SSH password authentication method, without disabling keyboard-interactive prompts.
jack@localhost attempts to connect as user jack.
If PAM supports the account and the user supplies the correct existing credentials, the server should permit keyboard-interactive authentication.
If the server uses a multi-factor AuthenticationMethods policy, adapt the test to that policy and confirm keyboard-interactive authentication is offered at the appropriate stage.
Do not modify jack's password to perform the test.
Step 17: Perform final configuration checks.
Execute:
sudo sshd -t
Verify the setting for jack:
sudo sshd -T \
-C user=jack,host=localhost,addr=127.0.0.1 \
| grep kbdinteractiveauthentication
Expected:
kbdinteractiveauthentication yes
Verify another user's setting:
sudo sshd -T \
-C user=candidate,host=localhost,addr=127.0.0.1 \
| grep kbdinteractiveauthentication
The value must remain consistent with that user's original configuration.
Finally:
systemctl is-active ssh
Expected:
active
Final Solution
1. Connect to the correct host.
ssh candidate@lfcs00073
2. Back up the SSH configuration.
sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
3. Edit the configuration file.
sudo nano /etc/ssh/sshd_config
4. Add the required configuration at the appropriate location, after checking existing Match rules.
Match User jack
KbdInteractiveAuthentication yes
5. Validate the SSH configuration.
sudo sshd -t
6. Verify the effective setting for jack.
sudo sshd -T \
-C user=jack,host=localhost,addr=127.0.0.1 \
| grep kbdinteractiveauthentication
Expected:
kbdinteractiveauthentication yes
7. Reload the SSH daemon.
sudo systemctl reload ssh
8. Confirm that SSH remains active.
systemctl is-active ssh
Expected:
active
Technical Verification and References
The solution has been checked against the official OpenSSH documentation for Ubuntu.
Match User applies specified configuration directives to connections matching a particular username.
KbdInteractiveAuthentication controls whether keyboard-interactive authentication is permitted.
UsePAM enables PAM integration used for keyboard-interactive authentication on typical Ubuntu systems.
sshd -t validates server configuration syntax.
sshd -T -C evaluates effective configuration settings for a particular connection, including applicable Match sections.
Official references:
Ubuntu OpenSSH sshd_config(5)
Ubuntu OpenSSH sshd(8)
OpenSSH Configuration Reference
Expected result: Keyboard-interactive authentication is persistently permitted for user jack, without changing the user's password or altering other users' existing login settings. Successful end-to-end authentication must also be confirmed with a valid login test.
Task
The system service apache2 is failing to start.
First, troubleshoot the failure and fix it.
Finally, start the systemd service and ensure it is running.
See the complete solution in Explanation.
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.
Task
The task is presented as a network traffic redirection diagram in the video.
Original diagram extracted from the recording. Its lower portion is outside the visible exam window.
The visible diagram identifies incoming TCP port 80, traffic from 172.16.123.0/28, and destination port 8080. The candidate's terminal commands also reference destination port 9080.
Transcription limitation: The recording does not reveal the complete diagram or any instructions below it. Therefore, the exact full task statement cannot be reproduced without guessing. The solution below addresses the two redirection paths indicated by the visible diagram and candidate commands, with the rule-ordering error corrected.
See the complete solution in Explanation.
Objective: Configure Linux iptables to perform destination-port redirection using the NAT table.
The recording suggests this intended behavior:
Incoming source
Original destination port
Redirected local port
172.16.123.0/28
TCP 80
TCP 9080
All other IPv4 sources
TCP 80
TCP 8080
The second destination, 9080, comes from the candidate's terminal commands, not the fully visible task diagram. It must therefore be treated as an inferred requirement.
A crucial technical issue is rule priority: the more specific subnet rule must be evaluated before the general port-80 rule. Otherwise, the general rule captures the subnet traffic first.
Step 1: Connect to the correct Linux server.
The recording specifies host lfcs00074.
Execute:
ssh candidate@lfcs00074
This connects to the designated host on which the firewall and NAT configuration must be performed.
Step 2: Verify that iptables is available.
Execute:
sudo iptables --version
This displays the iptables version and may indicate whether the system uses the nf_tables or legacy backend.
For example:
iptables v1.8.x (nf_tables)
The actual version depends on the installed environment.
Step 3: Inspect the existing NAT configuration.
Execute:
sudo iptables -t nat -L -n -v
-t nat selects the Network Address Translation table.
-L lists rules.
-n displays numerical IP addresses and port numbers.
-v provides verbose output, including packet and byte counters.
The NAT table contains chains including PREROUTING, OUTPUT, and POSTROUTING.
For incoming connections being redirected to local services, the relevant chain is normally PREROUTING.
Step 4: Display the PREROUTING rules with line numbers.
Execute:
sudo iptables -t nat -L PREROUTING -n -v --line-numbers
This displays the order in which incoming packets encounter the NAT rules.
Also execute:
sudo iptables -t nat -S PREROUTING
The second command displays the rules in a format similar to the commands used to configure them.
Check whether there are already rules that redirect TCP port 80.
Avoid creating duplicate or contradictory rules.
Step 5: Understand the required redirection mechanism.
The Linux REDIRECT target changes the destination of a matching packet so that it is delivered to the local machine, optionally changing its destination port.
For example:
sudo iptables -t nat -A PREROUTING \
-p tcp --dport 80 \
-j REDIRECT --to-ports 8080
This redirects incoming TCP connections originally targeting port 80 to local port 8080.
The official iptables-extensions(8) manual confirms that REDIRECT is supported in the NAT table's PREROUTING and OUTPUT chains.
Linux manual page
Step 6: Configure the source-specific rule first.
For the inferred special handling of subnet 172.16.123.0/28, execute:
sudo iptables -t nat -I PREROUTING 1 \
-s 172.16.123.0/28 \
-p tcp --dport 80 \
-j REDIRECT --to-ports 9080
Option
Purpose
-t nat
Selects the NAT table
-I PREROUTING 1
Inserts the rule at position 1
-s 172.16.123.0/28
Matches packets originating from that subnet
-p tcp
Matches TCP traffic
--dport 80
Matches original destination port 80
-j REDIRECT
Redirects the packet to the local machine
--to-ports 9080
Changes the destination port to 9080
The -I PREROUTING 1 option is important because it places the specific rule at the beginning of the chain, ahead of broader rules appended later.
Do not run this command if an equivalent correct rule already exists; inspect and reconcile the existing configuration first.
Step 7: Configure the general port redirection.
Provided an equivalent general rule is not already present, execute:
sudo iptables -t nat -A PREROUTING \
-p tcp --dport 80 \
-j REDIRECT --to-ports 8080
This handles incoming TCP port-80 connections that did not match an earlier terminating rule.
Because the source-specific rule has higher priority, the expected behavior is:
Connections from 172.16.123.0/28 are redirected to 9080.
Other incoming TCP port-80 connections are redirected to 8080.
The general rule does not require a source restriction because it is the fallback rule.
Step 8: Understand why the rule order matters.
The candidate initially enters the broad redirect to 8080 and later adds the subnet-specific redirect to 9080.
That sequence is problematic.
Consider these two rules in this order:
sudo iptables -t nat -A PREROUTING \
-p tcp --dport 80 \
-j REDIRECT --to-ports 8080
sudo iptables -t nat -A PREROUTING \
-s 172.16.123.0/28 \
-p tcp --dport 80 \
-j REDIRECT --to-ports 9080
The first rule matches all incoming TCP port-80 connections, including those from the special subnet.
Since a REDIRECT target terminates further rule evaluation for that NAT decision, the later subnet rule will not receive those matching connections.
Correct order:
Rule 1: Subnet 172.16.123.0/28 → Port 9080
Rule 2: Other TCP port-80 connections → Port 8080
The Linux iptables manual documents sequential rule evaluation and matching behavior.
Linux manual page
Step 9: Verify the configured NAT rules.
Execute:
sudo iptables -t nat -L PREROUTING \
-n -v --line-numbers
The relevant rule sequence should resemble:
1 REDIRECT tcp -- 172.16.123.0/28 0.0.0.0/0 tcp dpt:80 redir ports 9080
2 REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 8080
The output format may vary.
If existing unrelated rules are present, preserve them. The two example lines do not imply that the real NAT table should contain only two rules.
Step 10: Correct any incorrectly ordered rules.
If the general port-80 rule is already first, the specific rule can be inserted ahead of it using:
sudo iptables -t nat -I PREROUTING 1 \
-s 172.16.123.0/28 \
-p tcp --dport 80 \
-j REDIRECT --to-ports 9080
Before doing so, make sure an identical subnet rule is not already present.
If the previous candidate commands created duplicate entries, list the chain:
sudo iptables -t nat -L PREROUTING -n --line-numbers
Then carefully remove only confirmed duplicate or erroneous entries by their current rule number:
sudo iptables -t nat -D PREROUTING RULE_NUMBER
Replace RULE_NUMBER with the actual displayed number.
Rule numbers can change after each deletion, so inspect the chain again before deleting another entry.
Do not flush the entire NAT table.
Step 11: Verify that the destination services are available.
Execute:
sudo ss -ltnp
To examine the relevant ports:
sudo ss -ltnp | grep -E ':(8080|9080)\b'
This checks whether processes are listening on TCP ports 8080 and 9080.
The iptables rules may be syntactically correct even if no service is currently listening. However, actual connection delivery requires an appropriate local service and any necessary firewall permission.
A NAT redirection rule does not automatically start the destination application.
Step 12: Check whether filtering rules permit redirected connections.
Execute:
sudo iptables -L INPUT -n -v
Check whether the existing INPUT chain allows connections to the effective destination ports.
The REDIRECT target changes the packet's destination, but a restrictive filter policy can still block delivery.
Do not add broad ACCEPT rules unless the actual task requires them and the existing firewall policy warrants the change.
Step 13: Test traffic from the specified subnet.
From a machine whose source address belongs to:
172.16.123.0/28
Initiate a fresh TCP connection to port 80 on the appropriate IP address of lfcs00074.
For an HTTP-based service, a test could use:
curl -v http://SERVER_IP:80/
Replace SERVER_IP with the real server address.
If the inferred subnet-specific rule is correct, the connection should reach the local service listening on port 9080.
A destination service's response or a packet trace can establish which port received the connection.
Step 14: Test traffic from outside the specified subnet.
From a client outside 172.16.123.0/28, initiate another new connection to the same server's TCP port 80.
The general rule should redirect that traffic to port 8080, provided no earlier rule intercepts it.
Do not rely only on a test from:
curl http://localhost:80
Locally generated traffic traverses the NAT OUTPUT chain rather than the incoming PREROUTING chain. It is therefore not a valid test of these PREROUTING rules.
Step 15: Inspect rule counters.
Execute:
sudo iptables -t nat -L PREROUTING \
-n -v --line-numbers
Review the packet and byte counters.
New matching connections should increment the applicable rule's counters.
Because NAT decisions are generally made for the initial packets of tracked connections, established connections may not increment counters in the way ordinary filter-chain traffic does.
Use fresh connections for testing.
Step 16: Preserve the rules if persistence is required.
The video shows the candidate using:
sudo service netfilter-persistent save
For a system with the appropriate netfilter-persistent plugins installed, the documented command is:
sudo netfilter-persistent save
This saves the active firewall rules through the installed persistence plugins.
Ubuntu's netfilter-persistent(8) manual documents the save operation.
Ubuntu Manpages
Before relying on it, check that the service and IPv4 plugin are installed:
command -v netfilter-persistent
ls -l /usr/share/netfilter-persistent/plugins.d/
If persistence is required, verify the saved IPv4 rules:
sudo grep -A 20 '^\*nat' /etc/iptables/rules.v4
The saved configuration should contain the correctly ordered rules.
Persistence is not explicitly visible in the task statement, so treat it as an additional measure suggested by the recorded candidate actions, not a proven requirement.
Step 17: Perform final verification.
Execute:
sudo iptables -t nat -S PREROUTING
sudo iptables -t nat -L PREROUTING -n -v --line-numbers
sudo ss -ltnp | grep -E ':(8080|9080)\b'
For the inferred two-rule requirement, the expected configuration is:
Verification
Expected behavior
Source subnet
172.16.123.0/28
Original destination
TCP port 80
Special-subnet destination
TCP port 9080
General destination
TCP port 8080
Specific rule priority
Before general rule
NAT table
nat
NAT chain
PREROUTING
Existing unrelated rules
Preserved
Final Solution
For the two redirection paths inferred from the recording, and assuming equivalent rules do not already exist, the essential command sequence is:
# Connect to the required server
ssh candidate@lfcs00074
# Inspect existing NAT rules
sudo iptables -t nat -S PREROUTING
# Specific subnet: TCP 80 → 9080
# This rule must have higher priority.
sudo iptables -t nat -I PREROUTING 1 \
-s 172.16.123.0/28 \
-p tcp --dport 80 \
-j REDIRECT --to-ports 9080
# General traffic: TCP 80 → 8080
sudo iptables -t nat -A PREROUTING \
-p tcp --dport 80 \
-j REDIRECT --to-ports 8080
# Verify rule ordering and counters
sudo iptables -t nat -L PREROUTING \
-n -v --line-numbers
# If persistence is required and configured
sudo netfilter-persistent save
Technical Verification and References
Linux iptables(8)
— Documents rule insertion, ordering, matching and chain operations.
Linux iptables-extensions(8)
— Defines the REDIRECT target and --to-ports option.
Ubuntu netfilter-persistent(8)
— Documents saving and restoring firewall rules.
Video verification finding: The candidate's commands reveal an attempted redirect from port 80 to 8080 and a separate source-specific redirect from port 80 to 9080. The specific rule was appended after the general rule, which would prevent the special-subnet redirect from taking effect as intended. The corrected sequence places the specific rule first.
Verification limitation: The full task diagram is never visible, so the inferred two-rule interpretation cannot be certified as the exact complete exam requirement. The command syntax and priority correction are validated against Linux documentation, but the final intended behavior requires the missing diagram portion and runtime connection tests.
next please
Worked for 3m 12s
Task
First, create a user james with the password set to Foundation.
Next, create a group commander with GID 15002 and add user james.
Do not change user james's primary group.
Then, create a group pilot with GID 15001 and edit user james to use pilot as the primary group.
See the complete solution in Explanation.
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
Context
The system's clock has drifted due to the absence of time synchronization.
Task
Manually and one-off synchronize the system's clock with timeservers in pool.ntp.org.
There is no need to update the hardware clock; the system is configured to do that at shutdown.
Do not configure automatic time synchronization.
See the complete solution in Explanation.
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
Copyright © 2014-2026 Certensure. All Rights Reserved