LFCS Linux Foundation Certified System Administrator (LFCS) Question and Answers

Objective: Increase the storage capacity of the LVM-backed filesystem mounted at /var/log by approximately 0.2 GB, using free space from the existing volume group system, without unmounting the filesystem or interrupting access to existing log files.

The solution requires two operations:

Extend the logical volume using lvextend.

Grow the filesystem online so that it can use the additional capacity.

For the ext4 filesystem demonstrated in the video, the principal commands are:

sudo lvextend -L +0.2G /dev/system/log

sudo resize2fs /dev/system/log

The commands must be executed in the correct order. The first expands the underlying logical volume, while the second expands the ext4 filesystem. Both operations can be performed without unmounting a supported ext4 filesystem.

Linux manual page

+1

Step 1: Connect to the correct Linux server.

The video identifies the required host as lfcs00093.

From the candidate terminal, execute:

ssh lfcs00093

This establishes an SSH session with the server containing the LVM-backed /var/log filesystem.

All subsequent commands must be executed on this host.

Step 2: Verify that /var/log is a separate mounted filesystem.

Execute:

findmnt /var/log

This displays the source device, filesystem type, mountpoint and mount options.

For a more concise result:

findmnt -no SOURCE,FSTYPE,TARGET /var/log

The recording identifies the logical volume as:

/dev/system/log

The mountpoint is:

/var/log

This matters because /var/log could otherwise simply be a directory inside the root filesystem. The task specifically concerns a separate LVM-backed filesystem mounted there.

Step 3: Inspect the existing filesystem capacity.

Execute:

df -hT /var/log

This reports:

Filesystem device.

Filesystem type.

Total filesystem capacity.

Used space.

Available space.

Utilization percentage.

Mountpoint.

Record the existing size before extending the volume.

Step 4: Inspect the LVM configuration.

Execute:

sudo pvs

sudo vgs

sudo lvs

These commands provide three levels of LVM information:

Command

Information displayed

pvs

Physical volumes contributing disk capacity

vgs

Volume groups and their available space

lvs

Logical volumes and their current sizes

Confirm that the volume group system contains the logical volume log.

Step 5: Verify the logical volume directly.

Execute:

sudo lvdisplay /dev/system/log

Inspect the logical volume name, volume group, current size, logical extent allocation and status.

The logical volume must belong to:

system

And its name must be:

log

You can also execute:

sudo lvs /dev/system/log

This provides a concise overview.

Step 6: Check available free capacity in the volume group.

Execute:

sudo vgs system

For specific fields:

sudo vgs -o vg_name,vg_size,vg_free,vg_extent_size system

The VFree value must be sufficient to allocate the requested extension.

LVM allocates storage in units called physical extents. Consequently, an extension requested as 0.2G may be rounded to an appropriate extent boundary.

Do not add a new disk or create another volume group. The question requires using available capacity from the existing volume group system.

Step 7: Confirm the filesystem type before resizing.

Execute:

findmnt -no FSTYPE --mountpoint /var/log

The filesystem type determines which utility must be used to expand it.

Filesystem

Online expansion command

ext4

resize2fs /dev/system/log

XFS

xfs_growfs /var/log

The commands demonstrated for this task use resize2fs, which is appropriate for ext4.

Important: Do not run resize2fs against XFS or xfs_growfs against ext4.

Step 8: Check the size of the logical volume before modification.

Execute:

sudo lvs -o lv_name,vg_name,lv_size --units m /dev/system/log

This displays the current logical volume capacity in MiB.

For example, the original volume might have a size of 96 MiB. That is an illustrative starting point; use the actual value reported by the server.

You should record the initial capacity to verify the increase afterward.

Step 9: Extend the logical volume by 0.2 GB.

Execute:

sudo lvextend -L +0.2G /dev/system/log

This is the principal LVM expansion command.

sudo executes the command with administrative privileges.

lvextend increases the capacity of an existing logical volume.

-L specifies the capacity adjustment.

+0.2G requests an additional 0.2 GiB, subject to LVM's extent allocation.

/dev/system/log is the existing logical volume.

The plus sign is essential.

Compare:

sudo lvextend -L +0.2G /dev/system/log

with:

sudo lvextend -L 0.2G /dev/system/log

The first command adds capacity to the existing logical volume.

The second requests an absolute resulting size of 0.2 GiB, which would not correctly implement the task's requirement.

The official LVM documentation confirms that + makes the size relative to the current logical volume capacity.

Linux manual page

Step 10: Understand the effect of LVM extent allocation.

LVM allocates logical volume storage in physical extents.

For example, if the existing volume was 96 MiB and the requested increase was 0.2 GiB:

0.2

×

1024

=

204.8

MiB

0.2×1024=204.8 MiB

If the volume group uses 4 MiB physical extents, LVM may round the increase upward to 208 MiB.

The resulting size would then be:

96

+

208

=

304

MiB

96+208=304 MiB

This illustrates why the final capacity may differ slightly from the mathematical increase.

Such rounding is normal and does not indicate that LVM incorrectly extended the volume.

Step 11: Verify that the logical volume extension succeeded.

After the command completes, execute:

sudo lvs /dev/system/log

For more detailed output:

sudo lvdisplay /dev/system/log

Confirm that the logical volume has increased by the requested approximate capacity.

Also verify that the volume group has allocated free extents to the extended logical volume:

sudo vgs system

Important: The block device may now have additional capacity, but the filesystem itself may still show its previous size.

This is expected when lvextend is run without its filesystem-resizing option.

Step 12: Extend the ext4 filesystem without unmounting.

For the ext4 filesystem, execute:

sudo resize2fs /dev/system/log

This is the second essential command.

resize2fs expands or resizes ext2, ext3 and ext4 filesystems.

/dev/system/log specifies the logical volume containing the filesystem.

No explicit size is given, so resize2fs expands the filesystem to occupy the available device capacity.

On a supported modern Linux kernel, ext4 supports online expansion while mounted.

The official resize2fs(8) manual explicitly confirms that mounted ext4 filesystems can be expanded online.

Linux manual page

Step 13: Examine the filesystem expansion output.

An illustrative successful output might be:

resize2fs 1.46.5

Filesystem at /dev/system/log is mounted on /var/log; on-line resizing required

The filesystem on /dev/system/log is now 77824 (4k) blocks long.

The version, block count and other details will vary.

The critical points are that online resizing is performed and the command completes successfully.

Immediately check the command's exit status:

echo $?

Expected:

0

If resize2fs reports an error, diagnose it rather than running lvextend again. The logical volume may already have been extended successfully, and a second lvextend would request additional capacity beyond the task's requirement.

Step 14: Verify the new filesystem capacity.

Execute:

df -hT /var/log

The filesystem's total size should now reflect the extended logical volume.

To inspect the size using MiB units:

df -BM /var/log

Compare the result against the initial measurement taken before performing the extension.

There may be a small difference between logical volume capacity and usable filesystem space because the filesystem maintains its own metadata and reserved structures.

Step 15: Verify that /var/log remains mounted.

Execute:

findmnt --mountpoint /var/log

The command should identify the same filesystem mounted at:

/var/log

You can also execute:

mount | grep ' on /var/log '

The task states:

Without unmounting the LVM-backed filesystem mounted at /var/log

Therefore, do not execute:

sudo umount /var/log

Unnecessary unmounting could interrupt running services and would violate the task.

Step 16: Verify the filesystem remains accessible.

Execute:

ls -ld /var/log

Then:

sudo ls -la /var/log

Confirm that the directory and its existing log files remain accessible.

There is no requirement to delete logs, format the filesystem, or recreate the mount.

Do not execute commands such as:

sudo mkfs.ext4 /dev/system/log

That command creates a new filesystem and would risk destroying existing data.

The task requires expanding the current filesystem, not recreating it.

Step 17: Alternative method using automatic filesystem expansion.

LVM also provides the option:

sudo lvextend -r -L +0.2G /dev/system/log

The -r or --resizefs option requests that the filesystem be resized along with the logical volume.

This can simplify the procedure when the installed LVM filesystem tooling supports the mounted filesystem's online expansion.

The official LVM documentation describes --resizefs as resizing the underlying filesystem together with the logical volume.

Linux manual page

However, do not execute this alternative after already running the two-command solution. Doing so would request another 0.2 GiB increase.

For this question, the explicit two-command procedure is preferable because each stage can be inspected separately:

sudo lvextend -L +0.2G /dev/system/log

sudo resize2fs /dev/system/log

Step 18: Confirm that no unnecessary storage changes were made.

The task does not require:

Creating a new logical volume.

Adding a physical disk.

Creating another volume group.

Modifying unrelated logical volumes.

Unmounting /var/log.

Reformatting the filesystem.

Rebooting the server.

Avoid commands such as:

sudo lvcreate

sudo vgcreate

sudo mkfs.ext4

sudo umount /var/log

These operations are not needed for the requested online expansion.

Step 19: Perform final verification.

Execute:

sudo lvs /dev/system/log

df -hT /var/log

findmnt --mountpoint /var/log

The completed task must satisfy the following:

Requirement

Expected result

Correct host

lfcs00093

Volume group

system

Logical volume

log

Mountpoint

/var/log

Requested increase

Approximately 0.2 GiB

Logical volume extended

Yes

Filesystem expanded

Yes

Filesystem unmounted

No

Existing data preserved

Yes

Filesystem accessible

Yes

Final Solution

The essential command sequence for the ext4 filesystem is:

# Connect to the designated server

ssh lfcs00093

# Verify the filesystem mount

findmnt --mountpoint /var/log

# Record the current filesystem size

df -hT /var/log

# Inspect the volume group and logical volume

sudo vgs system

sudo lvs /dev/system/log

# Confirm the filesystem is ext4

findmnt -no FSTYPE --mountpoint /var/log

# Extend the logical volume by 0.2G

sudo lvextend -L +0.2G /dev/system/log

# Expand the ext4 filesystem online

sudo resize2fs /dev/system/log

# Verify the new logical volume size

sudo lvs /dev/system/log

# Verify filesystem expansion

df -hT /var/log

# Confirm the filesystem remains mounted

findmnt --mountpoint /var/log

Technical Verification and References

The solution has been checked against the relevant official Linux storage manuals:

LVM lvextend(8)

— Documents relative logical volume expansion using the + prefix and the optional filesystem-resizing feature.

Linux resize2fs(8)

— Documents online ext4 filesystem expansion.

Linux xfs_growfs(8)

— Documents the corresponding online expansion utility for XFS.

Video review: The demonstrated procedure uses lvextend to increase the logical volume and resize2fs to grow the filesystem. That is the correct operational sequence for a mounted ext4 filesystem. The commands should be considered successfully verified on the target host only after their exit statuses, updated capacity and mounted state are checked.

Expected result: The existing LVM-backed filesystem at /var/log has approximately 0.2 GiB of additional capacity allocated from the system volume group. The filesystem is expanded online and remains mounted and accessible throughout the operation.

next batch now

Worked for 3m 42s

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.