1.0 Operating Systems

Linux is a free, open-source, Unix-inspired operating system family known for flexibility, strong community support, and use across everything from older desktops to modern servers and cloud platforms.

When CompTIA refers to Linux, it usually means a Linux-based operating system distribution. The Linux kernel handles the core communication between hardware and software, while the distribution adds system tools, package management, desktop environments, default applications, documentation, and update repositories.

Linux is open source, which means its source code can be reviewed, modified, shared, and improved under open-source licensing. That does not always mean every Linux deployment is free to support. Many organizations choose paid enterprise support for predictable updates, vendor assistance, compliance needs, and long-term lifecycle planning.

The Basics

Linux follows many Unix design ideas: a hierarchical file system, strong file permissions, multiuser operation, text-based configuration, small tools that work together, and a powerful shell. It is Unix-like, but it is not proprietary Unix. That distinction matters because Linux behaves like Unix in many ways while remaining its own operating system ecosystem.

A Linux system can use a graphical desktop, a command-line shell, or both. Technicians often use Terminal because it provides fast access to files, processes, services, packages, logs, network settings, and system state. A GUI may be easier for everyday use, but the command line is a major Linux support skill.

A World Of Choice

Linux comes in many distributions, often called distros. Ubuntu is common for desktop use, labs, training, and cloud workloads. Debian is known for stability and a massive software repository. Red Hat Enterprise Linux and related enterprise distributions are common in business environments where paid support, lifecycle predictability, and certified software stacks matter.

Each distribution can differ in package manager, release cycle, default desktop, security tooling, repository policy, and support community. A technician should not stop at the word Linux. Always identify the distro, version, kernel, package manager, architecture, support status, and update source before making changes.

Why Technicians Like Linux

Where Linux Needs Planning

Linux is powerful, but it is not automatically the right answer for every user. Newer laptops, specialty peripherals, fingerprint readers, gaming hardware, and proprietary business applications may require extra driver or compatibility research. Some hardware works immediately, some works after installing drivers or firmware, and some may not be fully supported.

Support expectations also matter. A home user might rely on community documentation. A business may need vendor-backed support, predictable patching, tested repositories, and a distribution with a clear lifecycle. The best Linux choice is the one that fits the hardware, applications, user skill level, security needs, and support model.

Technician Workflow

1. Identify the use case. Decide whether the system is for desktop productivity, development, servers, recovery, security tools, cloud work, or older hardware reuse.
2. Choose the distribution. Match distro features, package manager, support lifecycle, and community or vendor backing to the scenario.
3. Verify hardware support. Check CPU architecture, storage, wireless, graphics, printers, peripherals, firmware, and any specialty drivers.
4. Plan software needs. Confirm required applications, package sources, repositories, licensing, update method, and compatibility with existing workflows.
5. Secure and update. Apply updates, use least privilege, understand sudo/admin access, and keep software from trusted repositories when possible.
6. Document the system. Record the distribution, version, kernel, desktop environment, package manager, support path, and any driver or configuration changes.

Bottom line: Linux is free, flexible, and community-powered, but great support still depends on choosing the right distribution, verifying hardware and software compatibility, and documenting the support plan.

Linux file management starts in the terminal: use commands such as ls, pwd, mv, cp, and rm to inspect folders, confirm your location, move data, copy data, and remove files safely.

Linux and macOS share many command-line ideas because both are Unix-like systems, but this section focuses on Linux behavior. The command line is especially important for servers, recovery environments, remote administration, low-resource systems, and situations where a graphical file manager is unavailable.

Before changing files, know where you are and what you are targeting. Linux commands can be direct and powerful, which is useful for technicians, but it also means a wrong path, wildcard, or delete command can remove the wrong data quickly.

Work In A Terminal

Most Linux distributions include a terminal application. In a shell prompt, commands are entered as text, and the system returns output immediately. You can use the terminal to navigate directories, list files, copy data, rename items, remove files, view manuals, and combine commands with pipes or redirection.

If you are practicing, use a lab system, a virtual machine, or a live USB environment. That gives you a safe place to learn command behavior before working on a user system or a production server.

List And Locate

Colorized output can help identify item types. Many distributions show directories in one color, compressed archives in another, and executable scripts in another. Do not rely on color alone, though. Use long listings and file names to confirm what you are handling.

Move, Copy, And Remove

The mv command moves files or renames them. For example, mv report.txt old-report.txt renames a file in the current directory, while mv report.txt Documents/ moves it into the Documents folder. If the destination exists, mv may overwrite data, so confirm the target before pressing Enter.

The cp command copies files. Use it when you need a duplicate while preserving the original. To copy directories, Linux commonly requires a recursive option such as cp -r source-folder backup-folder. When preserving ownership, timestamps, and permissions matters, technicians may choose more advanced options or tools after confirming the scenario.

The rm command removes files. It does not use the Windows Recycle Bin, and deleted files are often gone immediately. By default, rm removes files, not non-empty directories. To remove a directory tree, rm -r foldername is used, but that recursive option is high risk and should be handled with care.

Read The Manual

The man command opens built-in manual pages. Use man ls, man cp, or man rm when you need syntax, options, examples, and warnings. Manual pages are a technician habit: they reduce guessing and help you choose the least risky command.

Command Safety Habits

1. Confirm your location. Run pwd before copying, moving, or removing anything important.
2. List before changing. Use ls or ls -l to verify exact names, permissions, and targets.
3. Use tab completion. Let the shell complete paths and names to reduce typing errors.
4. Be careful with wildcards. Commands such as rm *.log can affect many files at once.
5. Treat rm -r as high risk. Recursive deletes can remove entire folder trees.
6. Practice safely. Learn command behavior in a lab, VM, or test directory before making production changes.

Bottom line: Linux file commands are fast, precise, and powerful. Verify the path, choose the right command, understand the options, and protect user data before making changes.

Linux permissions control who can read, modify, and execute files or directories. A technician must understand r, w, x, ownership, groups, chmod, and chown before changing access.

Permissions are one of the core security controls in Linux. They decide whether a user can view a file, edit a file, run a script, enter a directory, or manage content inside a directory. When permissions are wrong, users may be locked out, scripts may fail, services may not start, or sensitive data may be exposed.

The safest approach is to inspect first, change only what is required, and then verify the result. Use ls -l to view permission strings, owners, and groups before using commands such as chmod or chown.

Permission Basics

Linux separates access into three main identity categories: user or owner (u), group (g), and others (o). Some commands also use all users (a) when applying a permission change broadly. This layered model lets administrators grant access without giving everyone full control.

Reading Permission Strings

A long listing might show something like -rwxr--r--. The first character identifies the object type, such as regular file or directory. The next three characters show owner permissions, the next three show group permissions, and the final three show permissions for others.

For example, rwxr--r-- means the owner can read, write, and execute, while the group and others can only read. That pattern is common for files that should be usable by the owner but only viewable by everyone else.

Using chmod

The chmod command changes permissions. It can use symbolic mode, such as chmod u+x script.sh, or numeric octal mode, such as chmod 744 script.sh. Symbolic mode is readable when adding or removing one permission. Numeric mode is efficient when setting a complete permission pattern.

In octal permissions, read is worth 4, write is worth 2, and execute is worth 1. Add the values together for each identity category. A value of 7 means read, write, and execute. A value of 6 means read and write. A value of 5 means read and execute. A value of 4 means read only. A value of 0 means no permissions.

Common examples include chmod 744 script.sh to let the owner do everything while group and others can only read, chmod a-w first.txt to remove write access from everyone, and chmod 640 notes.txt to give the owner read/write, the group read-only, and others no access.

Changing Ownership

The chown command changes file ownership. It can set the owner, the group, or both. For example, sudo chown brotocoljoe script.sh changes the file owner to brotocoljoe. A format such as sudo chown brotocoljoe:admins script.sh can set both owner and group when the group exists.

Ownership changes often require elevated privileges because changing who controls a file can affect security, service behavior, and user access. Use sudo only when the task requires administrator-level access, and verify the result afterward with ls -l.

Technician Workflow

1. Identify the symptom. Decide whether the issue is read access, write access, script execution, directory traversal, or ownership.
2. Inspect the current state. Use ls -l to view permissions, owner, and group before changing anything.
3. Choose the narrowest fix. Add or remove only the permission needed for the correct user or group.
4. Use the right command. Use chmod for permission bits and chown for ownership.
5. Be careful with broad changes. Avoid granting write or execute access to everyone unless the scenario truly requires it.
6. Verify and document. Recheck permissions, test the workflow, and record what changed and why.

Bottom line: Linux permissions are powerful because they are precise. Match access to the user, group, and task, use least privilege, and verify every permission or ownership change.

Linux filesystem management is about finding files quickly, checking file system health, and connecting storage devices into the directory tree with commands such as find, fsck, and mount.

Linux treats storage differently from Windows. Instead of assigning every volume a drive letter, Linux attaches storage to directories called mount points. A USB drive, extra disk, network share, or recovery volume becomes available somewhere in the existing file system, such as /mnt/usb, /media/user/drive, or another administrator-defined location.

For technicians, this means storage troubleshooting usually starts with three questions: Where is the file? Is the file system healthy? Is the storage device mounted where users and services expect it to be?

Find Files Fast

The find command searches through directories for files and folders that match a name, extension, size, owner, time, permission, or other property. It is useful when a user does not know where a file was saved, when logs are spread across multiple folders, or when you need to locate files by pattern.

A common example is find . -name "*.txt". The dot means start in the current directory, and -name "*.txt" matches text files. The command can search deeply through subfolders, so choose the starting point carefully. Searching from / scans the whole file system and can take longer or produce many permission warnings.

Check File System Health

The fsck command checks and repairs Linux file systems. It looks for logical errors, orphaned files, metadata inconsistencies, and other file system problems. It is similar in purpose to Windows chkdsk, but the Linux workflow depends heavily on whether the volume is mounted, in use, read-only, or scheduled for checking during startup.

Use fsck carefully. Running repair operations against a mounted, active file system can risk data corruption. Many checks are best performed from recovery media, single-user mode, or during boot before the file system is actively being used. Always back up important data when possible before repairing storage.

Attach Storage With mount

The mount command makes a storage device available at a directory location. That directory is the mount point. For example, mount /dev/sdb1 /mnt/usb attaches the partition /dev/sdb1 to the folder /mnt/usb, allowing users or administrators to browse the files there.

Running mount by itself displays currently mounted file systems, but the list can be long because Linux mounts many system, virtual, temporary, and device-related file systems. Technicians often combine mount information with other commands to confirm device names, file system type, available space, and whether a volume is mounted read-only or read/write.

Command Quick Reference

Technician Workflow

1. Identify the storage goal. Decide whether you need to locate data, repair a file system, attach a device, or confirm what is already mounted.
2. Verify the target. Confirm the correct file path, partition, device name, and mount point before running commands.
3. Protect the data. Back up important files when possible, especially before repairs, formatting, partitioning, or forced mounts.
4. Use the least risky command. Search with find, inspect mounted file systems with mount, and reserve fsck repairs for appropriate recovery conditions.
5. Check permissions. File permissions and mount options can control who can read, write, or execute content on attached storage.
6. Verify and document. Confirm the files are accessible, the file system is healthy, and the mount point works as expected.

Bottom line: Linux storage support is about precision. Find the right file, check the right file system, mount the right device, and verify access before declaring the system healthy.

Linux protects the system by separating everyday user access from elevated administrative access. Use sudo for one controlled command and su when you intentionally need to switch into another user session.

Administrative privileges are required for tasks that can affect the operating system, services, packages, security settings, storage, users, ownership, and protected configuration files. This separation helps prevent accidental damage and limits what malware or a compromised user account can change.

Linux administrators should follow least privilege: use normal user access for normal work, elevate only when the task requires it, verify the result, and return to standard permissions as soon as possible.

Using sudo

The sudo command runs a specific command with elevated privileges, usually as the root user. For example, sudo systemctl restart nginx restarts a service with administrative rights while keeping the rest of the session under the current user account.

This is the preferred approach for most administrative tasks because the scope is limited. The elevated access applies to the command being run, then the user returns to regular permissions. On many systems, sudo also logs what command was run and by whom, which helps with accountability and troubleshooting.

Using su

The su command switches to another user account. When used as su -, it commonly starts a login shell for the root user or another specified account, loading that user environment. This is useful for extended administrative work, but it also increases risk because every command runs as that user until the session is exited.

Because su changes the working session, technicians should be deliberate when using it. Confirm who you are with commands such as whoami, keep the session short, and type exit when elevated work is finished.

sudo vs. su

Common Administrative Tasks

Elevated access may be needed to install or update packages, restart services, edit protected files under /etc, mount storage, change file ownership, manage users, review security configuration, or repair system components. The need for elevated access is a clue that the command can affect more than the current user.

Examples include sudo apt update to refresh package information, sudo chown brotocoljoe script.sh to change ownership, and sudo systemctl restart ssh to restart a service. Each command should be chosen for a specific purpose, not run elevated out of habit.

Technician Workflow

1. Start as a standard user. Confirm the task cannot be completed safely without elevated access.
2. Choose the narrowest elevation. Prefer sudo for one command when possible.
3. Verify the command. Check spelling, paths, package names, service names, and target files before pressing Enter.
4. Use su carefully. Switch sessions only when extended administrative work is truly needed.
5. Exit elevated sessions. Type exit when finished so future commands do not run with unnecessary power.
6. Document the change. Record what command was run, why it was needed, and how the result was verified.

Bottom line: Elevated access is powerful. Use sudo for focused administrative commands, reserve su for intentional user-session changes, and always protect the system by using the least privilege needed.

Linux package managers install, update, remove, and track software from trusted repositories while handling the supporting dependencies that applications need to run.

Package management is one of the biggest differences between Linux and a typical click-next desktop installer workflow. Instead of hunting for random installers on the web, a technician usually asks the distribution package manager to pull known software from configured repositories, verify package information, install the required files, and record what changed on the system.

This matters for security and support. Packages delivered through trusted repositories are maintained for that distribution, updated through a central process, and easier to inventory or remove later. When software comes from unknown sources, the technician inherits extra risk: untrusted code, missing updates, broken dependencies, architecture mismatches, and weak rollback documentation.

What Package Managers Do

APT And .deb Systems

APT, commonly run with the apt command, is used on Debian-based distributions such as Debian, Ubuntu, and Linux Mint. These systems commonly use .deb packages and repository metadata designed for the Debian package ecosystem.

The normal APT workflow starts by refreshing package information with sudo apt update. That command does not install every update by itself; it updates the local list of what versions are available from configured repositories. After metadata is current, sudo apt upgrade installs available upgrades for packages already on the system.

To install software, use sudo apt install <package>. To remove software, use sudo apt remove <package>. APT will show what it plans to install, upgrade, or remove, including dependencies. Read that prompt carefully before approving it, especially on a production system or a user computer.

DNF And .rpm Systems

DNF is common on Fedora and Red Hat-family systems, including Red Hat Enterprise Linux, CentOS Stream, Rocky Linux, and AlmaLinux. These distributions commonly use .rpm packages and repository metadata built for the RPM ecosystem.

A technician can check available updates with sudo dnf check-update. To apply updates, use sudo dnf upgrade. To install software, use sudo dnf install <package>. To remove software, use sudo dnf remove <package>.

DNF and APT have a similar goal even though the commands, package formats, repositories, and distribution families differ. The exam clue is usually the distribution family: Debian, Ubuntu, or Linux Mint points toward APT and .deb; Fedora, RHEL, CentOS Stream, Rocky, or AlmaLinux points toward DNF and .rpm.

Common Commands

Why sudo Is Common

Installing, updating, or removing packages changes protected parts of the operating system. Package managers may write under system directories, modify services, add commands, install libraries, update security-sensitive files, or remove software used by other users. That is why package commands are commonly run with sudo.

Do not treat sudo as decoration. It means the command can affect the whole system. Verify the distribution, package name, repository source, prompt details, and business impact before approving the change.

Repositories And Trust

Trusted repositories are configured software sources maintained by the distribution, organization, or approved vendor. They help keep Linux secure and up to date because the package manager can check repository metadata, receive security fixes, and keep package versions aligned with the distribution.

Third-party repositories can be legitimate, but they should be approved and documented. Adding an unknown repository just to make one app install faster can create long-term update, support, and security problems.

Technician Workflow

1. Identify the distribution. Confirm whether the system is Debian/Ubuntu-based, Fedora/RHEL-based, or something else before choosing a command.
2. Choose the right package manager. Use APT for Debian, Ubuntu, Linux Mint, and .deb clues; use DNF for Fedora, RHEL, CentOS Stream, Rocky, AlmaLinux, and .rpm clues.
3. Refresh metadata. Run sudo apt update or check updates with the appropriate DNF workflow before installing or upgrading.
4. Read the prompt. Check package names, dependencies, removals, download size, disk impact, and whether services may restart.
5. Verify the result. Launch the app, check the command version, confirm the service state, or verify the package list after the install, update, or removal.
6. Document the change. Record the distro, package manager, package name, command used, repository source, result, and any follow-up required.

Bottom line: Package managers keep Linux software controlled, updated, and supportable. Identify the distro, use the right package manager, trust the repository source, read the prompt, verify the result, and document the change.

Linux network commands help technicians inspect interfaces, test reachability, retrieve web data, query DNS, and trace the path packets take through a network.

Network troubleshooting is about proving where communication succeeds and where it breaks. A user may report that the internet is down, a server is unreachable, a name will not resolve, or an application cannot connect. Linux gives technicians command-line tools that can separate local interface problems, IP addressing problems, routing problems, DNS problems, firewall filtering, and remote service issues.

The best workflow is layered. Check the local interface first, then test basic reachability, then verify name resolution, then inspect the route or application protocol. Jumping straight to a complex fix wastes time when the real issue may be an address, route, DNS record, or blocked path.

Manage Interfaces With ip

The ip command is the modern all-in-one Linux tool for network interface and routing information. It can show interfaces, IP addresses, link state, routes, and other network configuration details. Older tools such as ifconfig may still appear in some references, but ip is the command technicians should expect on current Linux systems.

When troubleshooting, look for the expected interface, the correct address, the correct subnet prefix, and a valid default route. If the interface has no address, the wrong address, or no route off the local network, higher-level tests such as web access or DNS lookups may fail even though the cable or Wi-Fi signal appears connected.

Test Reachability With ping

The ping command sends ICMP echo requests to test whether a host is reachable and how long the round trip takes. It is a fast first test for basic connectivity, but it is not a complete application test. Some systems block ICMP, some firewalls rate-limit it, and a server can respond to ping while a specific web, file, or database service is still down.

Use ping 8.8.8.8 to test reachability to a known IP address. Use ping example.com when you also want DNS resolution to be part of the test. On many Linux systems, ping continues until stopped with Ctrl+C, while ping -c 5 8.8.8.8 sends a specific number of echo requests.

Retrieve Data With curl

The curl command transfers data to or from a server using URLs. Technicians use it to test web servers, APIs, downloads, redirects, headers, authentication behavior, and basic application-layer reachability. It is especially useful on servers where a full browser may not be available.

For example, curl https://example.com retrieves web content from that URL. If ping works but curl fails, the path may exist while the web service, TLS configuration, proxy, firewall rule, or application endpoint still has a problem. That distinction is excellent technician evidence.

Ask DNS Questions With dig

The dig command queries DNS servers and returns detailed name-resolution information. Use it when a hostname points to the wrong address, resolves slowly, fails for one client, or behaves differently inside and outside the organization.

A basic query such as dig example.com can show the resolved address, responding DNS server, query status, and TTL information. TTL, or Time To Live, tells DNS clients how long they may cache a record. When records have recently changed, TTL can explain why one system still sees old information while another sees the new result.

Trace The Path With traceroute

The traceroute command maps the routers, or hops, between the Linux system and a destination. It uses TTL behavior to reveal each step along the path. This helps identify whether traffic leaves the local network, where latency increases, and where the path appears to stop.

A command such as traceroute 8.8.8.8 can show the journey toward a destination. Some devices block or deprioritize traceroute responses, so missing hops do not always prove a device is down. Use traceroute as path evidence, then compare it with IP settings, routes, DNS, firewall rules, VPN state, and known network diagrams.

Technician Workflow

1. Confirm local network state. Use ip address to verify the interface, address, subnet, and link status.
2. Check the route. Use ip route to confirm the default gateway and route selection.
3. Test a known IP. Use ping against an IP address to test basic reachability without depending on DNS.
4. Test DNS. Use dig or ping a hostname to determine whether name resolution is working.
5. Test the application path. Use curl for web or API checks when you need more than ICMP reachability.
6. Trace the journey. Use traceroute to see where packets travel and where the path may break.
7. Document evidence. Record commands, targets, results, timestamps, interface names, IP addresses, DNS servers, and any change made with sudo.

Bottom line: Linux network commands turn vague connectivity complaints into evidence. Start local, test reachability, verify DNS, check application access, trace the route, and document what each command proved.

Linux informational commands help technicians discover what is happening on a system before making changes: read help, display file contents, monitor processes, and check disk usage.

A strong Linux technician does not guess first. Informational commands provide evidence. They show what a command does, what a file contains, which processes are running, how busy the system is, and whether storage is under pressure. That visibility turns a vague symptom into something you can test, explain, and document.

These commands are usually safe compared with commands that modify files, packages, permissions, storage, or network settings. They still require care because output may include sensitive paths, usernames, configuration values, tokens, or security-related information. Read only what you need, protect user data, and document relevant findings without exposing private details.

Use man For Command Help

The man command opens manual pages for Linux commands, configuration files, library calls, and system concepts. If you do not remember an option or you need to confirm syntax before touching a production system, man is a technician-friendly first stop.

Display And Combine Files With cat

The cat command displays file contents and can concatenate multiple files. It is useful for quickly viewing short text files, combining files, checking simple configuration values, or sending file content into another command through a pipe.

For example, cat file1.txt file2.txt > both.txt combines the contents of two files into a new output file. Use redirection carefully: > overwrites the destination if it already exists, while >> appends to the destination. When user data matters, verify the file names before pressing Enter.

cat is not ideal for huge logs or binary files. For long output, pair it with tools such as less, grep, head, or tail when appropriate. The exam-level idea is simple: cat displays or combines file contents.

Monitor The System With top

The top command shows a real-time view of system activity. It displays running processes, CPU usage, memory usage, load averages, process IDs, users, and other resource details. Technicians use it when a Linux system feels slow, fans are loud, CPU usage is high, memory pressure is suspected, or a process appears to be consuming too many resources.

Load average is especially useful on Linux systems because it gives a quick view of system demand over time. A single snapshot is not always enough, so watch the pattern for a moment and compare it with the number of CPU cores, active services, recent updates, and user workload.

Inspect Processes With ps

The ps command displays process status. Unlike top, which refreshes interactively, ps gives a point-in-time process listing. It is useful for scripts, documentation, troubleshooting service behavior, and identifying a process ID before taking another action.

Process output can answer practical questions: Is the application running? Which user launched it? What process ID should be investigated? Is a script still active? Is the same service spawning repeated processes?

Check Disk Space With df

The df command reports file system disk space. Use it when updates fail, applications cannot write files, logs stop growing, users cannot save data, or a system behaves unpredictably because a volume is full.

By default, df may show block counts that are not friendly for quick reading. df -h displays human-readable sizes such as KB, MB, GB, or TB. That makes it faster to explain storage pressure to a user or document the amount of free space before and after cleanup.

Disk-space troubleshooting should identify both the full file system and the cause. df tells you whether a file system is full. A follow-up tool such as du can help locate which directory is consuming space.

Technician Workflow

1. Start with the question. Decide whether you need help syntax, file contents, process status, resource usage, or disk capacity.
2. Choose the least disruptive command. Use read-only informational commands before changing files, services, packages, permissions, or storage.
3. Protect sensitive output. Avoid exposing private data from configuration files, logs, process arguments, paths, or usernames.
4. Use readable formats. Prefer df -h when communicating disk capacity and use pagers or filters for long output.
5. Verify patterns. For performance issues, compare top, ps, disk space, recent changes, and user symptoms instead of relying on one clue.
6. Document evidence. Record the command, target, important output, timestamp, and any next step taken.

Bottom line: Informational commands help you see what is happening before you touch the system. Use them to gather evidence, explain symptoms, choose the right fix, and document with confidence.

Linux technicians often edit configuration files, scripts, notes, and logs directly from the terminal. nano is a friendly full-screen text editor that makes basic edits approachable even when no graphical editor is available.

Text editing matters because many Linux support tasks involve plain-text files. Network settings, service configuration, scheduled jobs, shell scripts, documentation, hosts-file entries, package-source lists, and troubleshooting notes may all live in text files. A technician who can safely open, edit, save, and exit a terminal editor can work on servers, recovery shells, SSH sessions, virtual machines, and lightweight systems without needing a desktop environment.

nano is popular because it is simple, visible, and forgiving. It shows common shortcuts on the screen, uses familiar text-editing concepts, and is often installed by default or available quickly through the distribution package manager. It is not the only Linux editor, but it is a practical CompTIA-level answer when the goal is easy terminal editing.

Why Terminal Editors Matter

Open And Edit With nano

To open a file, run a command such as nano file.txt. If the file exists, nano opens it for editing. If the file does not exist, nano starts a new buffer using that file name, and the file is created when you save it.

Inside nano, you type normally, move with the arrow keys, and use keyboard shortcuts for editor actions. The caret symbol shown in nano shortcuts means Ctrl. For example, ^O means press Ctrl+O, and ^X means press Ctrl+X. This on-screen shortcut reminder is one reason nano feels more approachable than editors that require memorized modes.

Common nano Shortcuts

Edit Protected Files Carefully

Many important Linux files are protected. If you need to edit a system file under locations such as /etc, you may need elevated privileges, such as sudo nano /etc/hosts. That command opens the file with administrator rights, so mistakes can affect name resolution, services, boot behavior, authentication, or application function.

Before editing a protected file, confirm the file path, understand the change, and consider making a backup copy. A command such as sudo cp /etc/hosts /etc/hosts.bak preserves a rollback point before opening the file. After editing, verify the related service or workflow and document what changed.

Safe Editing Habits

1. Inspect before editing. Use commands such as cat, less, or grep to understand the current file before changing it.
2. Back up important files. Copy critical configuration files before editing so you can restore the previous version if needed.
3. Use the right privilege level. Open user files as a normal user and use sudo only when the file is protected and the task requires it.
4. Make focused changes. Change the smallest amount needed, especially in configuration files where syntax matters.
5. Save deliberately. Use Ctrl+O to write changes, confirm the filename, then use Ctrl+X to exit.
6. Verify the result. Reopen or display the file, test the service or command affected by the edit, and document the outcome.

When nano Is The Right Choice

nano is a good choice when the technician needs a quick, simple terminal editor. It is especially useful for beginner-friendly labs, remote support, small configuration edits, quick scripts, and recovery tasks. It offers enough power for routine work without requiring a steep learning curve.

Other editors may be preferred in some environments, but exam scenarios usually care about matching the tool to the task. If the clue says simple terminal text editor, easy to use, available in a shell, or editing a text file without a GUI, think nano.

Bottom line: Nano gives Linux technicians a practical way to edit text from any terminal. Open the correct file, protect important data, make focused edits, save intentionally, exit cleanly, verify the result, and document the change.

Linux stores many important system configuration files as plain text, especially under /etc. These files can control users, authentication, hostname resolution, DNS settings, mounted file systems, and startup behavior.

Configuration files are powerful because a small text change can alter how the operating system behaves. That is useful for technicians, but it also means careless edits can lock out users, break name resolution, prevent storage from mounting, disrupt services, or create security problems. Treat these files as system controls, not casual notes.

Many common configuration files can be viewed by standard users, but editing them usually requires administrator privileges. The safe pattern is to inspect first, understand the file format, make a backup, edit with a terminal editor such as sudo nano /etc/filename, verify the related function, and document the change.

Why /etc Matters

The /etc directory holds host-specific system configuration. Package managers install default files there, administrators customize settings there, and services often read their behavior from files or directories below /etc. If a question mentions Linux configuration, system behavior, local users, DNS resolver settings, host mappings, or file systems mounted at boot, /etc should be on your radar.

/etc/passwd: Local User Directory

The /etc/passwd file contains one line per local account. Historically it included password data, but modern systems usually store password hashes in /etc/shadow instead. The name remains for compatibility, but technicians should remember that /etc/passwd is mainly a user account directory.

A typical line includes colon-separated fields: username, password placeholder, user ID or UID, group ID or GID, user details, home directory, and login shell. For example, the shell field may point to /bin/bash, /bin/zsh, or another login program.

Do not manually edit account records unless there is a clear reason and a rollback plan. User-management commands are safer for routine changes because they validate syntax and update related files consistently.

/etc/shadow: Protected Password Data

The /etc/shadow file contains password hashes and password aging information. It is protected because password hashes are sensitive even though they are not plain-text passwords. If attackers can read hashes, they may attempt offline cracking.

Fields in /etc/shadow can track the user, password hash, last password change, minimum days before change, maximum days before change, warning period, inactive days, and account expiration. These settings support password policy enforcement.

Because this file affects authentication, use account and password-management tools whenever possible. If recovery work requires direct inspection, use the least access needed and document carefully.

/etc/hosts: Local Name Resolution

The /etc/hosts file maps hostnames to IP addresses on the local system. It is checked before DNS in many normal resolver workflows, which means it can override external DNS answers. That can be helpful or hazardous.

Common uses include internal servers, development environments, temporary testing, lab systems, and blocking or redirecting names. A stale or incorrect entry can make one workstation reach the wrong server while other systems work normally, so /etc/hosts is a prime troubleshooting target for hostname issues.

/etc/resolv.conf: DNS Resolver Settings

The /etc/resolv.conf file tells the system which DNS resolvers or search domains to use. Entries such as nameserver 1.1.1.1, nameserver 8.8.8.8, or search localdomain influence how names are translated to IP addresses.

Modern distributions may generate or manage this file through NetworkManager, systemd-resolved, DHCP, VPN software, or other network services. If your edit disappears after a reboot or network reconnect, the file may be managed automatically. In that case, change the controlling network configuration instead of repeatedly editing the generated file.

/etc/fstab: Filesystem Roadmap

The /etc/fstab file defines file systems that should be mounted, where they mount, and which options apply. Entries commonly include a device or UUID, mount point, file system type, mount options, dump setting, and pass value for file system checks.

This file is read during boot and by mount tools. A bad entry can slow boot, drop the system into emergency mode, mount a file system read-only, or leave expected storage unavailable. Always verify device identifiers, mount points, file system type, and options before editing.

Safe Technician Workflow

1. Identify the symptom. Decide whether the issue involves users, passwords, local hostname mapping, DNS resolver behavior, or mounted storage.
2. Inspect before editing. Use read-only tools such as cat, less, grep, getent, dig, mount, or findmnt before changing files.
3. Back up the file. Copy the original, such as sudo cp /etc/fstab /etc/fstab.bak, before editing critical configuration.
4. Edit with privilege only when needed. Use sudo nano /etc/filename for protected files and confirm the path before saving.
5. Preserve syntax. Keep field separators, spacing, comments, and required columns correct. One missing colon, bad hostname, or wrong UUID can break behavior.
6. Verify the result. Test login behavior, DNS resolution, hostname lookup, mount status, or boot-related commands after the change.
7. Document and communicate. Record the file, exact change, backup location, reason, verification result, and rollback plan.

Bottom line: Common config files are small, readable, and powerful. Know what each file controls, back it up before changing it, edit with care, verify the outcome, and document every system-impacting change.

A Linux system works because hardware, firmware, a bootloader, the kernel, systemd, services, user space, and applications all hand work to each other in the correct order.

When a technician understands the major operating system components, troubleshooting becomes more organized. A system that will not power on is different from a system that cannot find a boot device. A bootloader problem is different from a kernel panic. A service that fails after boot is different from a hardware device that was never detected. The component layer tells you where to look first.

Core 2 exam questions may use words such as kernel, bootloader, systemd, service, daemon, BIOS, UEFI, boot order, or startup. The key is to match the symptom to the layer of the startup process and choose a tool or file that can confirm what is happening.

The Big Picture

Firmware And The Bootloader

Startup begins before Linux itself runs. When power is applied, firmware initializes hardware and chooses a boot device. On modern systems this is usually UEFI, though BIOS remains an important exam term. Firmware settings can control boot order, secure boot behavior, enabled devices, storage mode, and other platform-level options.

The bootloader bridges firmware and the operating system. It knows where to find the kernel and related boot files, then starts the kernel with the correct options. If a system powers on but cannot find an operating system, inspect boot order, boot device detection, bootloader entries, and files under locations such as /boot.

A useful quick check is ls /boot to view boot-related files. In real support work, bootloader repair can be sensitive, so gather details before changing boot entries or reinstalling boot components.

The Kernel

The kernel is the heart of Linux. It controls access to hardware, schedules processes, manages memory, handles device drivers, exposes filesystems, and coordinates communication between software and physical devices. Applications do not talk directly to hardware in normal operation; they ask the kernel to perform controlled work.

Kernel space is protected so user applications cannot freely overwrite critical OS memory or directly disrupt hardware control. This boundary improves stability and security. When the kernel or a driver fails, the whole system may freeze, panic, lose hardware access, or show boot-time errors.

Technicians can check the running kernel version with uname -r. Kernel updates can deliver bug fixes, security patches, hardware support, and driver improvements, but they should still be tested and documented like other system-impacting updates.

systemd And Services

After the kernel initializes the system, the init process starts the rest of the user-space environment. On many modern Linux distributions, that init system is systemd. It becomes an early parent process and coordinates services, targets, timers, sockets, mounts, logging integration, and more.

Services are background programs, sometimes called daemons, that provide functions such as networking, logging, printing, SSH, scheduled jobs, authentication support, time synchronization, and login sessions. If Linux boots but a feature is unavailable, the service layer is a natural place to investigate.

User Space And Applications

User space is where normal applications, shells, desktop environments, utilities, and user sessions run. It is intentionally separated from kernel space. This separation helps one crashed application fail without automatically crashing the whole operating system.

Applications depend on lower layers. If firmware cannot find storage, the bootloader cannot start. If the kernel cannot initialize a device, services may fail. If systemd cannot start networking or login services, user applications may not function. Troubleshooting works best when you ask which layer must succeed before the symptom could appear.

Startup Flow

1. Power on. The user presses the power button and hardware receives power.
2. BIOS or UEFI runs. Firmware initializes hardware and selects a boot device based on settings.
3. Bootloader starts. The bootloader is loaded from the boot device and locates the Linux kernel.
4. Kernel initializes. The kernel takes control, initializes hardware support, mounts early filesystems, and starts the first user-space process.
5. systemd starts services. Systemd brings up services, targets, login support, networking, and other background components.
6. User logs in. Shells, desktop sessions, and applications run after the OS is ready.

Technician Workflow

1. Identify the stage. Decide whether the symptom occurs before boot, during bootloader selection, during kernel startup, while services start, or after login.
2. Gather evidence. Check firmware messages, boot entries, /boot, kernel version, service status, logs, and user symptoms.
3. Use the right command. Use uname -r for kernel version, ls /boot for boot files, and systemctl status <service> for service state.
4. Avoid blind changes. Bootloader, kernel, and service changes can prevent startup or remote access if handled carelessly.
5. Verify and document. Confirm the system boots, services run, devices appear, users can log in, and applications work.

Bottom line: Linux startup is a chain. Power on, firmware, bootloader, kernel, systemd, services, login, and applications each depend on the layer before them. Find the failed layer, verify with the right command, and document the result.

The root account is the Linux superuser. It has UID 0, unrestricted administrative authority, and the power to install software, change ownership, edit protected files, manage services, and alter the entire system.

Root exists because an operating system needs a trusted administrative identity that can perform work normal users should not be able to do. Installing packages, patching the OS, editing protected configuration, managing users, changing file ownership, mounting storage, and controlling services all require authority beyond a standard account.

That power is useful, but it is also dangerous. A root command can overwrite critical files, remove entire directory trees, expose sensitive data, change security controls, or break remote access. A technician should treat root access like a controlled procedure: know why it is needed, run the smallest necessary command, verify the result, and leave elevated access when finished.

What Root Is

Root Versus sudo

On many Linux distributions, technicians do not log in as root for routine work. Instead, they use sudo to run one command with elevated privileges. This is safer because the elevated scope is limited, the command may be logged, and the technician returns to normal permissions afterward.

A full root shell, such as one started with sudo -i or sudo su -, changes the session context. Every command runs with root authority until the technician exits. That may be useful for extended recovery work, but it is riskier because one typo or wrong path can have system-wide consequences.

Common Root-Level Tasks

Text-Based Administration

Linux administration is heavily text-based. Servers may run headless with no graphical desktop, SSH sessions are command-line driven, and many settings live in human-readable configuration files. This is why root access and terminal editing often appear together in support tasks.

For example, a technician might inspect a configuration file, back it up, edit it with sudo nano, restart a related service, and verify the outcome. That workflow is efficient, but it must be careful because text files may control authentication, DNS, storage, services, or boot behavior.

Root Safety Habits

1. Start as a standard user. Use normal permissions until the task clearly requires administrative authority.
2. Prefer one elevated command. Use sudo for a specific command instead of opening a long root session when possible.
3. Confirm identity. If you are unsure whether you are root, run id or whoami and look for root or UID 0.
4. Verify paths. Check filenames, directories, package names, service names, and device names before pressing Enter.
5. Back up before editing. Copy important configuration files before changing them, especially under /etc.
6. Avoid reckless wildcards. Commands run as root with wildcards, recursion, or force options can damage large parts of the system quickly.
7. Exit elevated sessions. Type exit when root work is complete so later commands do not run with unnecessary power.
8. Document the action. Record what was changed, why root was required, how it was verified, and how to roll back if needed.

Technician Workflow

1. Identify the admin task. Decide whether the work is package management, configuration, permissions, services, storage, or user management.
2. Choose the privilege method. Prefer sudo command for focused work and reserve root shells for justified recovery or extended maintenance.
3. Prepare a rollback. Back up files, capture current settings, and understand the impact before making changes.
4. Run the command carefully. Read prompts, confirm paths, avoid unnecessary force options, and change only what is required.
5. Verify and leave root. Test the result, check logs or service status if needed, then exit elevated context.

Bottom line: Root can do almost anything on Linux. Use that power only when needed, prefer scoped sudo commands, protect text configuration files, verify every change, and leave elevated access as soon as the job is done.

Linux Objective 1.9 is about choosing the right tool for the clue, using elevated privileges only when needed, and verifying the result before you document the change.

At this point in the Linux section, the exam is less about memorizing one isolated command and more about recognizing a scenario. A technician may need to inspect files, change permissions, locate storage, install software, test network connectivity, edit text configuration, check services, identify OS startup components, or use root-level authority safely. The best answer is usually the command or concept that solves the immediate problem with the least unnecessary risk.

Think of Linux support as a layered workflow. First identify the distribution, user context, path, service, package manager, network target, or boot stage. Then gather evidence with read-only commands where possible. After that, make the smallest appropriate change, verify that it worked, and record what changed.

Know The Linux Tool Family

Match Scenario Clues To The Right Feature

• Need current directory? Use pwd.
• Need to list files, permissions, owner, or group? Use ls -l.
• Need to change who can read, write, or execute a file? Use chmod.
• Need to change who owns a file? Use chown.
• Need to find a file by name, type, or location? Use find.
• Need to check available disk space? Use df -h.
• Need to identify what folder is consuming space? Use du.
• Need Debian or Ubuntu software management? Use apt and think .deb.
• Need Fedora, RHEL, Rocky, or AlmaLinux software management? Use dnf and think .rpm.
• Need to test if a host responds? Start with ping, then investigate routing, DNS, or firewall clues.
• Need to query DNS records directly? Use dig.
• Need to trace packet hops? Use traceroute.
• Need to edit a protected text config file? Back it up, then use a command such as sudo nano /etc/filename.
• Need service state? Use systemctl status <service> on systemd-based systems.
• Need full administrative authority? Think root, UID 0, and least privilege.

High-Value Configuration Reminders

Technician Decision Rhythm

1. Identify the system. Determine the Linux distribution, package family, user privilege level, boot stage, service name, path, and target resource.
2. Inspect before changing. Prefer commands such as pwd, ls -l, df -h, ps, top, ip, dig, and systemctl status before making changes.
3. Choose the smallest tool. Use the command that directly matches the clue instead of applying broad fixes.
4. Use privilege carefully. Use sudo only when the command needs protected access. Avoid staying in a root shell longer than necessary.
5. Read prompts. Package managers, removals, permission changes, mount operations, and service changes can affect more than one component.
6. Verify the outcome. Confirm the package installed, file changed, service started, DNS resolved, route worked, disk mounted, or permission problem cleared.
7. Document the change. Record commands used, files edited, packages added or removed, services restarted, and validation results.

Exam Mindset

Debian, Ubuntu, Linux Mint, or .deb clues point to apt. Fedora, Red Hat, RHEL, CentOS Stream, Rocky, AlmaLinux, RPM, or .rpm clues point to dnf. Permission clues usually point to chmod or chown. DNS clues point to dig, /etc/hosts, or /etc/resolv.conf. Service clues point to systemd and systemctl. Superuser, UID 0, unrestricted access, or protected files point to root and sudo.

Bottom line: For Objective 1.9, memorize the command names, but practice the scenarios. The exam wants you to connect the symptom to the correct Linux tool and the safest support workflow.