Lesson 3: Linux Client Tools and System Components

Linux can look intimidating because it exposes a lot of the system directly.

Files are visible. Permissions are visible. Processes are visible. Mounts are visible. Services are visible. Network state is visible.

That is actually useful.

The mistake is turning that visibility into a command-memorization contest.

A Linux command is valuable when you know which system question it answers.

All command work here uses supplied output or an approved disposable VM.

First identify the Linux environment

Linux is not one desktop product.

A technician may need to identify:

• distribution;
• release/version;
• package ecosystem;
• init or service system;
• desktop environment if relevant;
• filesystem layout;
• current user and privilege context.

If apt is missing on a Fedora-family system, Linux is not broken.

You chose the wrong package tool for the distribution.

Visual reference

See the system before you troubleshoot it

reference sheetCross-Platform Support Surfaces

Robotnix permission simulation
The file and identities are simulated. No real account permissions are changed.

$ whoami
student

$ id
uid=1000(student) gid=1000(student) groups=1000(student),1001(project)

$ ls -l report.txt
-rw-rw-r-- 1 student project 412 report.txt

$ chmod 640 report.txt

$ ls -l report.txt
-rw-r----- 1 student project 412 report.txt

$ chmod 600 report.txt

man, cat, and nano help you understand before changing

man opens manual documentation for supported commands.

cat displays file content.

nano is a text editor commonly available in beginner-friendly Linux environments.

Those three tools solve different problems:

man  → what does this command do?
cat  → what is in this file?
nano → edit text intentionally

Reading comes before editing.

A configuration file should not become an experiment because you skipped the documentation.

The directory tree is one filesystem namespace

Linux presents storage through one directory tree.

Important locations commonly include:

/
/home
/etc
/var
/tmp
/usr

Additional filesystems can be mounted into directories inside that tree.

That means a disk does not need a Windows-style drive letter to be usable.

Different platform, different storage model.

pwd and ls establish context

Before changing files, confirm where you are and what exists.

pwd
ls

pwd answers:

Which directory am I currently in?

ls answers:

What directory entries are visible here?

Simple commands prevent expensive mistakes.

Deleting the correct filename from the wrong directory is still deletion.

cp, mv, and rm change filesystem state

• cp copies;
• mv moves or renames;
• rm removes.

Before a state-changing command, know the source, destination, target scope, overwrite/removal behavior, and recovery expectation.

rm is not a friendly desktop recycle-bin workflow.

Do not experiment on important data.

grep and find answer different search questions

grep searches text patterns in content.

find locates filesystem objects according to criteria such as name, path, type, or metadata.

Question:

Which configuration file contains filesrv.test?

Think content. grep becomes useful.

Question:

Where is app.conf under /etc?

Think object location. find becomes useful.

Ownership and permissions are separate from file existence

A file can exist and still be unusable by the current user.

Linux/Unix-style permissions commonly reason about:

• owner/user;
• group;
• others;
• read (r);
• write (w);
• execute (x).

Example:

-rw-r----- 1 root support 1200 app.conf

If a regular user cannot write the file, the storage device is not automatically broken.

The permission boundary may be doing exactly what it was configured to do.

chmod changes mode; chown changes ownership

Do not solve every permission issue with:

chmod 777

That is not troubleshooting. It is removing the boundary because you did not understand it.

The correct question is:

Which identity should have which access, and what is the narrowest change that satisfies that requirement?

Permissions are security architecture.

sudo, su, and root change privilege context

root is the superuser identity with broad authority.

sudo can allow an authorized user to execute selected commands with elevated privileges according to policy.

su changes user context under the applicable authentication rules.

Elevation is not a convenience button.

If an operation only works as root, ask whether elevation is required or whether ownership and permissions are wrong.

Least privilege still applies.

Package management depends on the distribution

Common package tools include:

apt   Debian/Ubuntu-family environments
dnf   Fedora/RHEL-family environments

Package managers can track repositories, package versions, dependencies, installed state, updates, and removal.

If installation fails, useful boundaries include wrong distribution/package format, repository configuration, network/DNS access, dependency conflict, permissions, or unsupported release.

Do not copy a package command from a random distro guide and assume Linux should understand it.

The kernel and user space are different layers

The kernel manages core resources and hardware interactions.

Applications and most system utilities run in user space above it.

A service crashing does not mean the kernel failed.

A kernel failing to boot is a very different incident from one browser process crashing.

The bootloader starts the path toward the kernel

A bootloader loads or selects the operating system kernel and related boot configuration.

If the system never reaches the kernel, troubleshooting application packages is absurdly high in the stack.

Boot boundary first.

systemd commonly manages services

Many current distributions use systemd as an init and service-management system.

A service can be running, stopped, failed, enabled, disabled, or dependent on other resources.

If a web service is failed while the OS and network remain healthy, the service boundary is where the investigation belongs.

Do not reboot the entire machine because one service stopped.

Process and storage tools answer different questions

ps

Shows process information at a point in time.

top

Shows live process and resource behavior.

df

Shows filesystem capacity and usage.

du

Shows space consumed by files and directories.

df asks:

How full is this filesystem?

du asks:

Where is space being consumed inside the directory tree I measured?

Use them together.

Worked case: root filesystem is nearly full

Evidence:

$ df -h
Filesystem      Size  Used Avail Use%
/dev/example     40G   39G   1G   98%

Application error:

No space left on device

Storage-capacity pressure is strong evidence.

Now supplied du output shows:

/var/log/example-cache  17G

Do not immediately delete the directory.

Ask what owns it, whether it is logs/cache/application data, what retention policy applies, and whether the application can regenerate it safely.

Finding the large directory is evidence, not authorization to erase it.

Mounts connect storage into the directory tree

mount attaches a filesystem to a mount point.

/etc/fstab can define persistent mount configuration.

A storage device can be detected while its filesystem is not mounted where an application expects it.

Worked case:

physical disk: detected
filesystem: healthy
expected mount /data: absent
/etc/fstab entry: wrong UUID in supplied state

The hardware is not the failed boundary.

The mount configuration is.

fsck belongs to filesystem-integrity work

Filesystem checking and repair need the correct device, filesystem state, and recovery procedure.

Running repair against the wrong target or inappropriate active filesystem can create risk.

Use the tool because the evidence points to filesystem integrity, not because the word filesystem appeared in the ticket.

Configuration files expose system intent

At A+ recognition depth, know these files:

/etc/passwd

User-account identifiers and related account information.

/etc/shadow

Protected password/hash and aging information. Access should be restricted.

/etc/hosts

Local hostname-to-address mappings.

/etc/resolv.conf

Resolver configuration or generated resolver state depending on the network stack.

Do not assume manual editing is authoritative on every system. Another service may regenerate it.

/etc/fstab

Persistent filesystem mount configuration.

A small configuration file can have a large boot or mount impact.

Network tools still answer narrow questions

Use tools such as:

ip
ping
curl
dig
traceroute

ip inspects interface, address, and route state.

ping tests reachability under the test's conditions.

dig asks detailed DNS questions.

curl interacts with supported URL-based services and exposes response behavior.

traceroute shows responding routed hops.

Same discipline as Week 9. Do not let the terminal tempt you into overclaiming.

Worked case: local name mapping breaks one client

Evidence:

IP configuration: valid
remote IP: reachable
upstream DNS record: correct
one Linux client resolves filesrv.test to old address
/etc/hosts on that client:
192.0.2.50 filesrv.test

The local hosts-file mapping is the strongest client-specific boundary.

Changing the organization's DNS server would ignore the evidence.

Build a Linux evidence map

For supplied cases, record:

question
command / file / component
observation or modification?
privilege required
risk
evidence supported
evidence not proven
smallest justified next action

Include man, cat, nano, ls, pwd, cp, mv, rm, grep, find, chmod, chown, sudo, su, apt, dnf, mount, fsck, ps, top, df, du, ip, ping, curl, dig, traceroute, the five required /etc files, the kernel, bootloader, systemd, and the root account.

Before you move on

Linux looks technical because the architecture is exposed.

Use that visibility.

Do not type commands because they look advanced.

Ask which file, process, service, mount, identity, or network boundary owns the symptom.

Next we move one layer higher into applications, where the installer can fail even though the operating system is behaving perfectly.