Linux Config and Root

On a real help desk, Linux issues rarely fail in dramatic ways, they fail in quiet ones. A single wrong line in a config file can break name resolution, block logins, or stop a service from starting. That's why Linux config files and root access matter for both troubleshooting and security in day-to-day support work, and why they appear in CompTIA A+ Core 2 (220-1202), Domain 1 (Operating Systems), Objective 1.9.

A configuration file is a plain text file that controls how the system behaves. Most system-wide settings live in /etc because it's the standard location for host configuration, from user accounts to networking to storage. When you know which file to check, you can confirm what the system should do before you change anything.

This guide breaks down the common files you're expected to recognize, including /etc/passwd, /etc/shadow, /etc/hosts, /etc/fstab, and /etc/resolv.conf. It also explains core OS components (the kernel, the bootloader, and systemd), so you can place errors in the right part of the startup and runtime flow. Finally, you'll learn what the root account can do, why that power creates risk, and how to use it safely while you fix problems fast.

Key Config Files

For CompTIA A+ Core 2 (220-1202), Domain 1 (Operating Systems), Objective 1.9, you need to recognize a small set of Linux configuration files and explain what they control. These files also show up constantly in real support work because they sit on common failure paths, logins, name lookups, boot mounts, and DNS. The goal is simple: know where to look, confirm what the system is trying to do, then change it using the safest method.

/etc/passwd and /etc/shadow, how user accounts really work

Linux splits account identity from password secrets. That split is the main idea to remember, because it explains both security and troubleshooting behavior.

/etc/passwd is the user account directory. It lists users and basic properties, and it is typically world-readable so programs can map user IDs to names. Each line represents one account and uses colon-separated fields. At a basic level, you should recognize these fields:

Username: The account name used at login (for example, jane).
UID: The user ID number. It drives ownership and permissions.
GID: The primary group ID number.
Home directory: Where the user lands after login (for example, /home/jane).
Shell: The program started at login (for example, /bin/bash).

Modern systems do not store password hashes in passwd. Instead, the password field usually contains an x, which means, "check the shadow file."

/etc/shadow holds the password hash and password aging controls. This file must stay protected because it contains sensitive authentication data. You will usually see permissions that prevent non-root users from reading it (often -rw------- with owner root). In shadow, you commonly see:

The hashed password field (or a marker like ! or * for locked accounts).
Aging settings such as last change date, minimum days, maximum days, and warning period.

A quick workflow helps you confirm what you are dealing with:

View contents safely with less /etc/passwd (and sudo less /etc/shadow if allowed).
Check permissions with ls -l /etc/passwd /etc/shadow.
Confirm the user's shell path exists, because a bad shell can block login even with a correct password.

If /etc/passwd points to a shell that does not exist (or is not executable), the login may fail or exit right away. This can look like a "password problem" even when it is not.

Editing these files by hand is risky because one typo can break access. Prefer system tools that validate format and update related settings:

Use useradd and usermod for account changes.
Use passwd for password and aging changes.
If you must edit manually in an emergency, work slowly and keep a backup copy first.

/etc/hosts, the local name lookup file that can save you in a pinch

/etc/hosts is a simple text file that maps hostnames to IP addresses on the local machine. It is a fallback when DNS fails, and it is also a controlled override when you want a specific name to resolve to a specific IP.

A typical line looks like: an IP address, then one or more names (the canonical name first, then aliases). Because this file lives on the host, it is fast, predictable, and independent of network DNS.

However, whether it "wins" over DNS depends on the system's name service order. That order is defined in /etc/nsswitch.conf. You do not need to memorize the full file, but you should know the idea: the system can consult files (meaning /etc/hosts) before dns, or the other way around, depending on configuration.

Common, practical uses include:

Testing a website against a staging server by mapping a domain name to a staging IP.
Fixing a hostname that will not resolve during an outage, so you can still reach a key system by name.
Mapping internal services when DNS is not available in a lab, a recovery environment, or a small network.

This file can also create confusing failures. A stale entry may point you to the wrong server, and the symptoms look like "the service is broken" when the real issue is name resolution.

When troubleshooting "wrong server" issues, check /etc/hosts early. A single old mapping can override DNS and waste hours.

For safe handling, keep entries minimal, comment what you change, and remove temporary mappings when you are done. Also, if only one user reports the problem, check their machine first, because hosts is local to each system.

/etc/fstab, controlling what mounts at boot (and how to avoid a boot failure)

A "mount" is how Linux attaches storage into the folder tree. Instead of drive letters, Linux makes a disk, partition, or network share appear at a directory path (the mount point), such as /home or /mnt/data. The file /etc/fstab controls what should mount automatically, often at boot.

Each fstab line describes one mount. You do not need to memorize every option, but you should understand the main columns because exam questions and real outages both target them.

Here is what the columns mean at a high level:

Column	What it means	Why it matters
Device (or `UUID=`)	What to mount	The system must find the correct disk or share
Mount point	Where it appears in the filesystem	A wrong path can hide data or block logins
Filesystem type	Format (for example, `ext4`, `xfs`, `vfat`)	The wrong type can prevent mounting
Options	How to mount (for example, `defaults`, `ro`)	Controls boot behavior and permissions
Dump	Backup flag (often `0`)	Rarely used on modern systems
fsck order	Filesystem check order (0, 1, 2)	Affects boot-time checks and repair

Using UUID= instead of device names like /dev/sdb1 is a common best practice. Device names can change between boots, especially with USB storage or changing controller order. UUIDs stay stable for a given filesystem, so the entry remains correct.

Some mounts are "nice to have" rather than required. In those cases, safer options can prevent boot failures:

nofail can allow boot to continue if the device is missing.
x-systemd.automount can mount on first access, which reduces boot-time dependency on slow devices.

The safest workflow is disciplined and repeatable:

Make a backup: sudo cp /etc/fstab /etc/fstab.bak.
Edit carefully (prefer a tool like visudo style, but for fstab, you are often using a normal editor).
Test without rebooting: run sudo mount -a to attempt all mounts.
If mount -a reports errors, fix them before restarting.

A bad fstab line can be severe. If the system cannot mount a required filesystem, it may drop into emergency mode during boot. That is why mount -a is so valuable. It gives you the same failure signal, but in a safer moment.

/etc/resolv.conf, DNS settings, and why NetworkManager can rewrite them

/etc/resolv.conf defines how the system performs DNS lookups. When DNS is wrong, almost everything "network-like" feels broken. You can still ping an IP, but names fail. Package installs fail. Domain logins may fail. Even simple tools like curl can look unreliable.

The file usually contains:

nameserver lines, which list DNS server IP addresses.
A search line, which adds default domain suffixes (useful in corporate networks).

If nameserver points to an unreachable address, name lookups time out. If it points to the wrong DNS server, you may reach the wrong internal resources or fail to resolve private names.

The tricky part is that many Linux distributions do not treat resolv.conf as a static file. It may be managed by:

NetworkManager, common on desktops and many server builds.
systemd-resolved, common on newer systemd-based distributions, sometimes using a stub resolver.

As a result, manual edits often disappear after a reconnect or reboot. In some setups, /etc/resolv.conf is even a symlink to a generated file, which is a strong hint that a service controls it.

Practical troubleshooting stays focused:

Confirm the current content: cat /etc/resolv.conf.
Check if it is a symlink: ls -l /etc/resolv.conf.
Identify the manager:
- If NetworkManager is in use, prefer nmcli or the GUI network settings.
- If systemd-resolved is in use, check active DNS status with resolvectl status.

Once you know the owner, make changes through that tool. This avoids the "edit, revert, edit again" loop that burns time during an incident. If you must apply a temporary fix, document it and still correct the real network profile afterward, so the system stays stable on the next reconnect.

Linux Startup Core

For CompTIA A+ Core 2 (220-1202), Domain 1 (Operating Systems), Objective 1.9, you need to recognize the kernel, the bootloader, and systemd as key OS components. In practice, these three pieces explain most "won't boot" and "boots but nothing works" tickets. When you can place a failure in the right layer, you stop guessing and start testing.

Think of startup like a relay race. The bootloader hands control to the kernel, then the kernel starts systemd, and systemd brings up services like networking and login. Each handoff has its own logs and clues, so a good support workflow checks the right place first.

The kernel, what it does and what changes when you update it

The Linux kernel is the bridge between hardware and software. User programs do not talk to the disk controller or network card directly. Instead, they ask the kernel to do it. That role makes the kernel central to performance, stability, and hardware support.

At a support level, remember four core jobs:

Drivers and device support: The kernel includes drivers (built-in or loadable) that let hardware work. If a driver is missing or incompatible, the device may vanish or misbehave.
Memory management: The kernel allocates RAM, uses caches, and manages swap behavior. Memory pressure can show up as slow systems, crashes, or the OOM killer ending processes.
Process scheduling: The kernel decides which processes run, when they run, and on which CPU cores. Poor scheduling symptoms often look like "random lag."
Filesystems: The kernel implements filesystem drivers (like ext4, xfs, vfat) and storage layers. If the kernel cannot read the root filesystem, the system cannot boot.

Kernel updates matter because they can change driver behavior and module compatibility. Many drivers load as kernel modules, which are add-ons the kernel can load at runtime. A module built for an older kernel version often will not load on a newer one, because the kernel's internal interfaces may change. As a result, a Wi-Fi card, GPU driver, or storage controller can stop working right after an update.

A few quick checks usually tell you what you are running and what loaded:

Confirm the running version with uname -r.
List loaded modules with lsmod (useful when a device is missing).
Scan the kernel ring buffer with dmesg for driver errors, firmware warnings, and device detection messages.