sudo
AccountsPackage: sudo
Runs one command with another account's rights, root by default, and logs who asked for it. It is not "becoming root": each command is allowed or refused by /etc/sudoers, and that file is where what an account can really do is read.
What its options do in the lessons
From the same glossary the lessons render under their commands, so the two cannot disagree.
sudo -i- Opens a login shell for the target user — root unless
-unames another: profiles read, environment rebuilt, starting in their home directory. Followed by a command, it runs inside that environment. sudo -u- Runs the command as that user rather than root.
sudo -u postgres psqlopens psql with the identity PostgreSQL expects. sudo -l- Lists what you are allowed to do with sudo, without running anything.
sudo -E- Keeps your environment variables. Avoid by default: clearing them is exactly how sudo stops a caller-chosen variable changing what root does.
sudo -H- Sets
HOMEto the target user's directory, so a tool does not write its configuration into yours. sudo -e- Edits a file without running the editor as root:
sudoeditcopies it to a temporary file, you edit it as yourself, and it is written back into place. Your editor — with its plugins, and its shell-escape commands — never runs with administrative rights.
Lessons that teach it
- Copying files to and from the serverYour first server
- When the connection drops: keeping work runningYour first server
- Updating a server with aptYour first server
- Installing and removing softwareYour first server
- Where a package puts its filesYour first server
- Signals, and why kill -9 is the last resortLinux Fundamentals
- Disabling a service is not stopping itManaging services with systemd
- The exposure score is not a verdictManaging services with systemd
- Creating and removing accountsUsers, sudo and SSH access
- Locking a password is not closing an accountUsers, sudo and SSH access
- sudo, and why nobody works as rootUsers, sudo and SSH access
- Moving SSH to key authenticationUsers, sudo and SSH access
- A key is a line, and the line takes optionsUsers, sudo and SSH access
- A directory two accounts share, done properlyUsers, sudo and SSH access
- Becoming someone else, and which shell you getUsers, sudo and SSH access
- Ports: a process listens, or nothing answersNetworking: how your server is reached
- Unreachable: find the broken layer before touching anythingNetworking: how your server is reached
- Works on the server, refused from outsideNetworking: how your server is reached
- Dropped here or never arrived: one capture decidesNetworking: how your server is reached
- Your first server blockHosting a web application with Nginx
- Serving a React/Vite buildHosting a web application with Nginx
- Reading the access log: what one line already provesHosting a web application with Nginx
- Installing Node.js on an Ubuntu serverHosting a web application with Nginx
- Reverse proxying a Node applicationHosting a web application with Nginx
- Reading the error log: why the 502 happenedHosting a web application with Nginx
- Ninety days, and nothing will warn youHosting a web application with Nginx
- Which server block answers, and why the wrong site sometimes doesHosting a web application with Nginx
- The limits that refuse: 413 and 504Hosting a web application with Nginx
- The headers you think you setHosting a web application with Nginx
- Installing ISPConfig with the autoinstallerISPConfig: hosting several sites on one server
- Creating a site, then putting a Node.js application on itISPConfig: hosting several sites on one server
- What the panel limits, and what its backups do not coverISPConfig: hosting several sites on one server
- Mailboxes and DNS zones from the panelISPConfig: hosting several sites on one server
- When the previous run has not finishedBash scripting for administrators
- ufw: deny by default without locking yourself outFirewall and hardening
- fail2ban: banning repeated attemptsFirewall and hardening
- Three writers, one ruleset: reading what the kernel holdsFirewall and hardening
- The undo you schedule before you need itFirewall and hardening
- The periodic checkFirewall and hardening
- AppArmor: the refusal permissions do not explainFirewall and hardening
- Hardening the SSH daemon without locking yourself outFirewall and hardening
- Telling what changed on diskFirewall and hardening
- Disk, memory and load: reading them correctlyMonitoring a server
- Controlling log growthMonitoring a server
- Busy doing what: reading the processor lineMonitoring a server
- Which disk, and how long each request tookMonitoring a server
- Getting the alert to a humanMonitoring a server
- A query's path, and the propagation mythDNS: pointing a domain at your server
- Why fixing the typo does not help yetDNS: pointing a domain at your server
- Moving a live domain: the record change is the shortest partDNS: pointing a domain at your server
- What an output proves, and what "success" does notDiagnosing a failure: what each output proves
- The check that cannot fail, and the flush that proves nothingDiagnosing a failure: what each output proves
- Revealed is not caused: dating the fault rather than the symptomDiagnosing a failure: what each output proves
- From a symptom to one component: what the hypothesis forbidsDiagnosing a failure: what each output proves
- Two logs that say 14:02: a timestamp is not a numberDiagnosing a failure: what each output proves
- Capture before you repair: the state a fix deletesDiagnosing a failure: what each output proves
- How wide a fix may be, and the record it leavesDiagnosing a failure: what each output proves
- What the fix proved, and what expired on its ownDiagnosing a failure: what each output proves
- Installing Docker: the official repository, not Ubuntu'sDocker: containers for hosting a Node application
- A container with no memory limit, and the process the kernel kills insteadDocker: containers for hosting a Node application
- Publishing a port is not listening on itDocker: containers for hosting a Node application
- Data outlives the container, the port goes through the firewallDocker: containers for hosting a Node application
- The log file nothing is rotatingDocker: containers for hosting a Node application
- An image that is not publicDocker: containers for hosting a Node application
- Git on the server: a read-only key, and .git out of the web rootDeploying: releases, the switch and rolling back
- Releases and a symlink: the switch as one operationDeploying: releases, the switch and rolling back
- Verify before declaring success, and what a rollback does not undoDeploying: releases, the switch and rolling back
- Roles and pg_hba.conf: why psql gets in and the application is refusedAdministering PostgreSQL: access, connections and growth
- A hundred connections, and the arithmetic that exceeds themAdministering PostgreSQL: access, connections and growth
- Reachable from elsewhere: four gates, four different refusalsAdministering PostgreSQL: access, connections and growth
- pg_wal fills, and something is holding itAdministering PostgreSQL: access, connections and growth
- Finding the slow queries, not the slow momentAdministering PostgreSQL: access, connections and growth
- The index a query asked for, and the proof that it workedAdministering PostgreSQL: access, connections and growth
- shared_buffers and work_mem, without the folkloreAdministering PostgreSQL: access, connections and growth
- The build, step by stepThe capstone: from repository to production
- The release that breaks: roll back first, diagnose secondThe capstone: from repository to production
- The five proofs: demonstrate, do not assertThe capstone: from repository to production