Linux Foundation Certified System Administrator (LFCS) LFCS Exam Questions with Experts Answers Updated Recently

Objective: Enable IPv4 packet forwarding on the Linux server and ensure that the setting remains enabled after a system reboot.

In Linux, IPv4 forwarding is controlled by the kernel parameter:

net.ipv4.ip_forward

This parameter determines whether the Linux kernel can forward IPv4 packets between network interfaces.

Value

Meaning

0

IPv4 forwarding disabled

1

IPv4 forwarding enabled

The task requires a persistent configuration, not merely a temporary runtime change.

The official Linux kernel documentation confirms that setting net.ipv4.ip_forward to 1 enables forwarding of IPv4 packets.

Step 1: Connect to the correct Linux server.

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

From the candidate terminal, execute:

ssh lfcs00081

This establishes an SSH session with the designated server.

All remaining commands must be executed on this host.

Step 2: Inspect the current IP forwarding configuration.

Execute:

sysctl net.ipv4.ip_forward

This displays the current value of the IPv4 forwarding parameter.

If forwarding is disabled, the output is:

net.ipv4.ip_forward = 0

If forwarding is already enabled, the output is:

net.ipv4.ip_forward = 1

You can also inspect the corresponding kernel interface directly:

cat /proc/sys/net/ipv4/ip_forward

Expected output when forwarding is disabled:

0

The /proc/sys/ hierarchy provides an interface for viewing and modifying runtime kernel parameters.

Step 3: Check the existing persistent configuration.

Before modifying anything, check whether the parameter is already configured elsewhere.

Execute:

sudo grep -RnsE '^[[:space:]]*net\.ipv4\.ip_forward[[:space:]] *=' \

/etc/sysctl.conf /etc/sysctl.d/ \

/run/sysctl.d/ /usr/lib/sysctl.d/ 2 > /dev/null

This searches the relevant sysctl configuration files.

For example, the output might include:

/etc/sysctl.conf:28:net.ipv4.ip_forward=0

This indicates that the existing configuration explicitly disables IPv4 forwarding.

If the parameter appears in multiple files, inspect the effective configuration order before changing it.

Step 4: Enable IPv4 forwarding immediately.

Execute:

sudo sysctl -w net.ipv4.ip_forward=1

sudo executes the command with administrative privileges.

sysctl reads or modifies kernel parameters.

-w writes a new value to a kernel parameter.

net.ipv4.ip_forward=1 enables IPv4 forwarding.

Expected output:

net.ipv4.ip_forward = 1

This change takes effect immediately.

However, this command alone does not guarantee persistence after reboot.

Therefore, additional configuration is required.

Step 5: Create a persistent sysctl configuration file.

The preferred method on a systemd-based Linux system is to create a dedicated file in:

/etc/sysctl.d/

Execute:

sudo nano /etc/sysctl.d/99-lfcs-ip-forward.conf

Add this exact line:

net.ipv4.ip_forward = 1

Save the file.

The complete file should contain:

net.ipv4.ip_forward = 1

Why this works:

/etc/sysctl.d/ stores persistent administrator-defined kernel settings.

.conf files in this directory are read during system startup.

The filename prefix 99- normally positions the file after most package-provided configuration files.

The setting enables IPv4 forwarding whenever it is applied.

The systemd sysctl.d(5) documentation confirms that these configuration files are used to apply kernel parameters during boot.

Step 6: Check for settings that could override the new value.

A particularly important consideration is /etc/sysctl.conf.

On Ubuntu systems using the procps implementation, sysctl --system processes /etc/sysctl.conf after the configuration files in sysctl.d.

Therefore, an existing entry such as:

net.ipv4.ip_forward = 0

inside /etc/sysctl.conf could override the value in the new file when sysctl --system is executed.

Inspect it:

sudo grep -n 'net.ipv4.ip_forward' /etc/sysctl.conf

If an active, conflicting entry is present, edit it:

sudo nano /etc/sysctl.conf

Change:

net.ipv4.ip_forward = 0

to:

net.ipv4.ip_forward = 1

Alternatively, remove the duplicate active entry and rely on the dedicated /etc/sysctl.d/99-lfcs-ip-forward.conf file.

Do not modify unrelated sysctl parameters.

The official sysctl(8) manual documents how --system processes configuration files and how /etc/sysctl.conf can override earlier values.

Step 7: Apply the persistent configuration immediately.

Execute:

sudo sysctl --system

This loads the sysctl settings from the system configuration.

The relevant output should include:

net.ipv4.ip_forward = 1

Review the command output for conflicting settings or errors.

Check the command's exit status immediately:

echo $?

A successful execution should normally return:

0

Step 8: Verify that IPv4 forwarding is enabled in the running kernel.

Execute:

sysctl net.ipv4.ip_forward

Expected:

net.ipv4.ip_forward = 1

Verify through the kernel interface:

cat /proc/sys/net/ipv4/ip_forward

Expected:

1

These two commands confirm the same runtime kernel setting through different interfaces.

Step 9: Verify the persistent configuration file.

Execute:

cat /etc/sysctl.d/99-lfcs-ip-forward.conf

Expected output:

net.ipv4.ip_forward = 1

You can also confirm that the setting remains active after reapplying its configuration:

sudo sysctl --system

sysctl net.ipv4.ip_forward

The final result should remain:

net.ipv4.ip_forward = 1

This confirms both that the runtime setting is enabled and that the system configuration can reapply it successfully.

Step 10: Verify persistence after a reboot, if permitted.

The strongest practical verification is to reboot the server and check the parameter afterward.

Only perform this step if rebooting the exam host is permitted and you can reconnect safely.

Execute:

sudo reboot

After the server finishes restarting, reconnect:

ssh lfcs00081

Then execute:

sysctl net.ipv4.ip_forward

Expected:

net.ipv4.ip_forward = 1

If the value remains 1, IPv4 forwarding has been restored successfully during startup.

Important: A reboot is not necessary to apply the change. sudo sysctl --system is sufficient for immediate activation. Avoid an unnecessary reboot during an exam if the required state can already be verified.

Step 11: Understand why both runtime and persistent changes matter.

There are two separate requirements to consider:

Configuration method

Immediate effect

Persistent after reboot

sudo sysctl -w net.ipv4.ip_forward=1

Yes

No, by itself

Write 1 to /proc/sys/net/ipv4/ip_forward

Yes

No, by itself

Configure /etc/sysctl.d/*.conf

After loading

Yes

Configure /etc/sysctl.conf on the Ubuntu setup

After loading

Yes

sudo sysctl --system

Applies configured values

Does not itself create persistence

The correct solution must leave the runtime parameter enabled and store the configuration in a location that is processed at startup.

Step 12: Confirm that IPv4 forwarding does not require additional configuration for this task.

The question asks only to enable the IP forwarding kernel feature persistently.

It does not request:

Configuring network interfaces.

Creating routing tables.

Adding NAT or firewall rules.

Enabling IPv6 forwarding.

Installing a routing daemon.

Therefore, these additional changes are unnecessary.

Enabling the kernel's forwarding feature allows Linux to forward IPv4 packets, but successful routing between networks can still depend on interface configuration, routing tables, and firewall policies.

Those are separate operational concerns and are not part of the stated task.

Step 13: Perform the final verification.

Execute:

sysctl net.ipv4.ip_forward

Expected:

net.ipv4.ip_forward = 1

Then:

cat /proc/sys/net/ipv4/ip_forward

Expected:

1

Finally:

cat /etc/sysctl.d/99-lfcs-ip-forward.conf

Expected:

net.ipv4.ip_forward = 1

The resulting configuration must satisfy the following:

Requirement

Expected result

IPv4 forwarding enabled

Yes

Runtime kernel parameter

1

Persistent configuration

Present

Settings reapply successfully

Yes

Other kernel parameters

Unchanged unless affected by the kernel's forwarding transition

IPv4 forwarding after reboot

Enabled

Final Solution

Copy commands

# Connect to the correct server

ssh lfcs00081

# Check current IPv4 forwarding status

sysctl net.ipv4.ip_forward

# Enable IPv4 forwarding immediately

sudo sysctl -w net.ipv4.ip_forward=1

# Make the setting persistent

printf 'net.ipv4.ip_forward = 1\n' | \

sudo tee /etc/sysctl.d/99-lfcs-ip-forward.conf

# Check for a conflicting setting in /etc/sysctl.conf

sudo grep -n 'net.ipv4.ip_forward' /etc/sysctl.conf

# Resolve any active conflicting entry if present,

# then apply persistent settings

sudo sysctl --system

# Verify the effective kernel setting

sysctl net.ipv4.ip_forward

# Verify directly through procfs

cat /proc/sys/net/ipv4/ip_forward

# Verify the persistent configuration

cat /etc/sysctl.d/99-lfcs-ip-forward.conf

Alternative Solution — Method Demonstrated in the Video

The candidate in the recording edits:

sudo vim /etc/sysctl.conf

This is also a valid approach on the Ubuntu environment shown.

Inside the file, locate the IPv4 forwarding setting:

#net.ipv4.ip_forward=1

If the line is commented out, uncomment it so it reads:

net.ipv4.ip_forward=1

If an active entry is already set to 0, change it to 1 instead. Ensure there are no contradictory active entries.

Save and apply:

sudo sysctl -p /etc/sysctl.conf

Verify:

sysctl net.ipv4.ip_forward

Expected:

net.ipv4.ip_forward = 1

Both approaches are valid. A dedicated file under /etc/sysctl.d/ is preferable for keeping administrator-specific changes separate, whereas editing /etc/sysctl.conf closely follows the method attempted in the recording. Use one consistent configuration and ensure no conflicting setting overrides it.

Technical Verification and References

The solution has been checked against official Linux and systemd documentation:

Linux Kernel — IP Sysctl Documentation — Defines the IPv4 forwarding parameter and its behavior.

Linux sysctl(8) — Documents runtime modification and applying system configuration.

systemd sysctl.d(5) — Explains persistent kernel settings loaded during startup.

Video verification finding: At approximately 28:20–29:10, the recording shows Task 8 on host lfcs00081. The candidate edits /etc/sysctl.conf and executes a reboot. However, the visible recording does not establish the precise final contents of the file or show a successful post-reboot check of net.ipv4.ip_forward.

Expected result: The Linux system has IPv4 forwarding enabled with net.ipv4.ip_forward = 1, and the setting is configured to remain enabled after reboot.

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

Step 1: Connect to the correct server.

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

From the candidate terminal, execute:

ssh lfcs00094

This establishes an SSH connection to the designated Linux server.

All subsequent commands must be executed on this host.

Step 2: Navigate to the SSL certificate directory.

Execute:

cd ~/relaxed-llama/ssl

- cd changes the current working directory.

- ~ represents the current user's home directory.

- relaxed-llama/ssl is the directory specified in the task.

Verify the current directory:

pwd

Then list the contents:

ls -la

The directory should contain an SSL certificate file and existing subdirectories corresponding to certificate common names.

Step 3: Identify the SSL certificate file.

Execute:

find . -maxdepth 1 -type f -print

- find . searches from the current directory.

- -maxdepth 1 restricts the search to the current directory.

- -type f identifies regular files.

- -print displays their paths.

An SSL certificate commonly uses an extension such as .crt, .pem, or .cer, although other filenames are possible.

For example, a directory might contain:

/server.crt

/alpha.example.com/

/bravo.example.com/

/charlie.example.com/

These are illustrative filenames, not confirmed contents of the exam server.

Identify the actual certificate filename before continuing.

Step 4: Examine the SSL certificate using OpenSSL.

Once you have identified the certificate, run:

openssl x509 -in CERTIFICATE_FILENAME -noout -subject

Replace CERTIFICATE_FILENAME with the real filename.

For example, if the file is named server.crt:

openssl x509 -in server.crt -noout -subject

- openssl invokes the OpenSSL utility.

- x509 processes an X.509 certificate.

- -in server.crt specifies the certificate file.

- -noout suppresses the encoded certificate output.

- -subject displays the certificate's subject distinguished name.

An illustrative result is:

subject=C = US, ST = California, O = Example Corp, CN = bravo.example.com

The important field is:

CN = bravo.example.com

CN stands for Common Name, an attribute of the certificate's subject.

The actual value must come from the certificate on the designated host.

Step 5: Display the subject CN clearly.

For easier identification, execute:

openssl x509 -in CERTIFICATE_FILENAME \

-noout -subject -nameopt sep_multiline

This prints the subject attributes on separate lines.

Example:

subject=

countryName = US

stateOrProvinceName = California

organizationName = Example Corp

commonName = bravo.example.com

The commonName value is the information required to select the correct destination subdirectory.

Do not confuse the certificate's subject CN with its issuer CN or the Subject Alternative Name extension. The task specifically asks for the subject CN.

Step 6: Locate the matching subdirectory.

List the existing directories:

find . -maxdepth 1 -type d -print

If the certificate's subject CN is bravo.example.com, its matching destination should be:

~/relaxed-llama/ssl/bravo.example.com/

Verify that the matching directory exists:

ls -ld ~/relaxed-llama/ssl/bravo.example.com

Again, bravo.example.com is an example. Substitute the actual CN reported by OpenSSL.

The task states that the subdirectory has already been created.

Therefore, do not create a new directory unless you have established that the supplied environment differs from the task statement.

Step 7: Move the certificate into the correct subdirectory.

The Linux command for moving a file is mv.

Its basic syntax is:

mv SOURCE_FILE DESTINATION_DIRECTORY/

For example, if:

- Certificate filename: server.crt

- Subject CN: bravo.example.com

The command would be:

mv server.crt bravo.example.com/

This moves the certificate from:

~/relaxed-llama/ssl/server.crt

to:

~/relaxed-llama/ssl/bravo.example.com/server.crt

The original filename is preserved.

Before moving the actual file, ensure that the destination does not already contain a different file with the same name. You can use mv -i to request confirmation before overwriting an existing destination.

Do not copy the certificate using cp, because the task specifically requires moving it.

Step 8: Verify that the certificate was moved successfully.

Execute:

ls -l bravo.example.com/

The output should show the certificate inside the directory matching its CN.

Verify that the certificate no longer exists in the original location:

ls -l server.crt

For the illustrative filename, the expected response is:

ls: cannot access 'server.crt': No such file or directory

This indicates the original path no longer contains the file.

Step 9: Verify that the moved certificate is readable and unchanged.

Execute:

openssl x509 \

-in bravo.example.com/server.crt \

-noout -subject

The certificate's subject CN should be identical to the value obtained before the move.

For example:

subject=C = US, ST = California, O = Example Corp, CN = bravo.example.com

This confirms that the certificate is still readable and is located inside the corresponding CN directory.

Step 10: Perform the final directory verification.

Execute:

find ~/relaxed-llama/ssl -maxdepth 2 -type f -print

Confirm that the certificate appears at the expected destination.

The final directory structure should resemble:

~/relaxed-llama/ssl/

├── alpha.example.com/

├── bravo.example.com/

│ └── server.crt

└── charlie.example.com/

This directory structure is illustrative. The actual destination must match the CN obtained from the real certificate.

Final Solution

The essential command sequence is:

1. Navigate to the directory.

cd ~/relaxed-llama/ssl

2. List the files and directories.

ls -la

3. Identify the certificate's subject CN.

openssl x509 -in CERTIFICATE_FILENAME \

-noout -subject -nameopt sep_multiline

4. Move the certificate into its matching existing CN directory.

mv CERTIFICATE_FILENAME CN_DIRECTORY/

5. Verify the destination.

ls -l CN_DIRECTORY/

6. Confirm the certificate's subject again.

openssl x509 -in CN_DIRECTORY/CERTIFICATE_FILENAME \

-noout -subject

Replace CERTIFICATE_FILENAME and CN_DIRECTORY with the actual values discovered on the server.

Technical Verification and References

The solution is based on the officially documented behavior of OpenSSL and the GNU/Linux mv command.

- OpenSSL X.509: The -subject option displays the certificate subject; -noout suppresses certificate output; and -nameopt controls the format of the subject information.

OpenSSL Documentation

- GNU Coreutils: The mv command moves a file into an existing target directory while preserving its filename unless a new filename is explicitly supplied.

Official documentation: OpenSSL X.509 Certificate Command Reference.

Expected result: The existing SSL certificate is moved into the already-created subdirectory whose name matches the certificate's subject CN.

Important: The video reveals the task requirements but does not establish the actual certificate filename or subject CN from the target server. Therefore, assigning a particular destination without inspecting the certificate would be an unverified guess. The procedure above determines the correct destination directly from the certificate.

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.