Supporting Linux endpoints often means you must act with admin rights, but only for a moment. CompTIA A+ Core 2 (220-1202), Domain 1, Objective 1.9 focuses on Linux administrative and package management tasks, especially su, sudo, apt, and dnf. These tools show up in day-to-day support work because you'll fix broken installs, add needed utilities, apply updates, and reduce risk from unsafe changes.
This post sets a practical baseline. First, it explains safe privilege use with su and sudo, including what changes in your shell session. Next, it covers package management on Debian-based systems with apt and on Red Hat-based systems with dnf. Finally, it closes with simple troubleshooting habits you can practice in a VM.
Using su and sudo safely when you need admin power
Admin access is like a master key. It opens every door, so it also raises the cost of mistakes. The guiding idea is least privilege, which means you only take the access you need, for the shortest time, to do one task. In support work, that usually looks like running one command as root, then returning to a normal user shell.
Linux offers two common ways to act as an admin:
suswitches your session to another user (oftenroot).sudoruns a single command (or a short set of commands) with elevated rights.
A quick comparison helps you choose the safer tool for the job.
| Topic | su | sudo |
|---|---|---|
| Typical use | Become root for a session | Run one admin command at a time |
| Authentication | Often asks for the target user password (root) | Often asks for your password |
| Audit trail | Limited unless extra logging is set | Better logging on many systems |
| Risk | Higher, easy to stay root too long | Lower, encourages short admin actions |
In practice, many organizations prefer sudo because it supports tighter control. Admins can allow only certain commands, and logs can show who did what. Still, su appears on real systems, and you should understand it.
A simple habit helps in both cases: watch your prompt. Many distros show # for root and $ for standard users. Also, check your identity with id if you're unsure. Small checks prevent large mistakes.
Treat root access like a chemical you only handle with gloves. The goal isn't fear, it's controlled contact.
su basics, switching users, and common mistakes to avoid
The su command means "substitute user" or "switch user." If you run su with no username, it usually tries to switch to root. For example, su then entering the root password drops you into a root shell.
However, there's an important variant: su - (or su - root). The dash tells Linux to start a login shell for the target user. That detail matters because it loads the target user's environment, including settings like PATH, default shell variables, and the working context you'd expect for that account.
This difference can explain confusing behavior. Suppose you run su (without the dash) and then try a command that root can normally run. It may fail because your environment still looks like your original user's shell. On the other hand, su - resets things to match the target account, which often makes admin commands behave as expected.
Pay attention to PATH. Root may have system paths that a standard user doesn't. If a command runs for root but not for a user, it might be a path issue, not a missing package. Similarly, a command might fail after su (without -) because the environment didn't switch cleanly.
Common mistakes show up repeatedly in help desk work:
- Forgetting the dash in
su -, then chasing "missing command" errors that come from environment differences. - Staying root too long, then editing or deleting the wrong file because every command now has full power.
- Running risky commands from the wrong directory, for example, using
rmwhile standing in/or a shared mount.
If you must use su, be deliberate. Do the task, then exit with exit and confirm you're back as your normal user.
sudo essentials, how it's controlled, and how to verify your access
sudo stands for "superuser do." Instead of switching your whole session, it runs a command with elevated rights. For example, sudo apt update runs the update as root, but you remain a standard user before and after.
Access to sudo is controlled by policy. At a high level, that policy lives in the sudoers configuration. On many systems, admins manage it with visudo, which edits the sudoers file safely. The key benefit is validation. If you make a syntax mistake with a normal editor, you can lock everyone out of admin access. visudo helps prevent that.
As a support tech, you often won't edit sudoers, but you should recognize where control comes from. You should also know how to check whether your account can use sudo:
sudo -llists what commands you're allowed to run.sudo -vupdates your cached credentials (helpful before a long install).idshows your user ID and group IDs.groupsshows your group membership (some distros grant sudo via groups likesudoorwheel).
One detail trips up beginners: sudo may prompt for your user password, not the root password. That's common in environments where root logins are discouraged.