Ubuntu 26.04 LTS (Resolute Raccoon) was released on April 23, 2026. It ships with Linux kernel 7.0, GNOME 50, Python 3.14, PHP 8.5, Java 25, TPM-backed full-disk encryption, post-quantum cryptography support in OpenSSL, and a Wayland-only GNOME session. As an LTS release, it receives standard security updates for five years, with expanded coverage available through Ubuntu Pro.

This guide shows how to upgrade to Ubuntu 26.04 LTS from the command line. Ubuntu 25.10 systems can upgrade now, while Ubuntu 24.04 LTS systems will be offered the standard upgrade path after Ubuntu 26.04.1 is released.

Prerequisites #

You need to be logged in as root or a user with sudo privileges to perform the upgrade.

You can upgrade to Ubuntu 26.04 from Ubuntu 25.10 today. Ubuntu 24.04 LTS systems will be offered the standard upgrade path after Ubuntu 26.04.1 is released. If you are running an older release, you must first upgrade to Ubuntu 22.04 and then to 24.04 before continuing.

Make sure you have a working internet connection before starting.

Back Up Your Data #

Before starting a major version upgrade, make sure you have a complete backup of your data. If you are running Ubuntu on a virtual machine, take a full system snapshot so you can restore quickly if anything goes wrong.

Update Currently Installed Packages #

Before starting the release upgrade, bring your existing system fully up to date.

Check whether any packages are marked as held back, as they can interfere with the upgrade:

sudo apt-mark showhold

An empty output means there are no held packages. If there are held packages, unhold them with:

sudo apt-mark unhold package_name

Refresh the package index and upgrade all installed packages:

sudo apt update
sudo apt upgrade

Perform a full distribution upgrade to resolve any remaining dependency changes:

sudo apt full-upgrade

Remove automatically installed dependencies that are no longer needed:

sudo apt --purge autoremove

Upgrade to Ubuntu 26.04 LTS #

You can upgrade from the command line using do-release-upgrade, which works for both desktop and server installations.

do-release-upgrade is part of the update-manager-core package, which is installed by default on most Ubuntu systems. If it is not present, install it first:

sudo apt install update-manager-core

If you are upgrading over SSH, do-release-upgrade may start an additional SSH daemon on port 1022 so you can reconnect if the main session drops. If you use a firewall, you may need to open that port temporarily:

sudo ufw allow 1022/tcp

To begin the release upgrade, run:

sudo do-release-upgrade

If Ubuntu does not offer the new release yet, follow the standard supported rollout for your current version. This guide covers the normal upgrade path.

The tool will disable third-party repositories, update the apt sources to point to the Ubuntu 26.04 repositories, and begin downloading the required packages.

You will be prompted several times during the process. When asked whether services should be automatically restarted, type y. When asked about configuration files, type Y to accept the package maintainer’s version if you have not made custom changes; otherwise keep your current version to avoid losing your customizations.

The upgrade runs inside a GNU screen session and will automatically re-attach if the connection drops.

The process may take some time depending on the number of packages, your hardware, and your internet speed.

Once the new packages are installed, the tool will ask whether to remove obsolete software. Type d to review the list first, or y to proceed with removal.

When the upgrade finishes, you will be prompted to restart the system. Type y to reboot and complete the upgrade.

Verify the Upgrade #

After the system boots, log in and check the Ubuntu version :

lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 26.04 LTS
Release: 26.04
Codename: resolute

You can also confirm the kernel version:

uname -r

The output should show a 7.0.x kernel.

Troubleshooting #

Third-party repository errors during apt update
The upgrade tool disables third-party repositories automatically. If you see errors before running do-release-upgrade, disable the affected sources under /etc/apt/sources.list.d/ and re-enable them one by one after the upgrade completes.

“Packages have been kept back”
Run sudo apt full-upgrade to resolve held-back packages before starting the upgrade. Do not proceed with do-release-upgrade until there are no held packages.

SSH connection drops mid-upgrade
The upgrade runs inside a GNU screen session. Reconnect over SSH and run sudo screen -r to re-attach to the running session.

A service or container does not work after the reboot
If something that worked before the upgrade fails afterward, check its status and logs first. Run systemctl status service_name and journalctl -xe for services, and review your container runtime logs and configuration for Docker or containerd workloads. Third-party packages and older configurations sometimes need updates after a major release upgrade.

GNOME desktop shows only Wayland sessions
Ubuntu 26.04 drops the X11 GNOME session. If you relied on an X11 desktop session, applications that do not support Wayland natively will run through XWayland automatically. For most applications this is transparent, but some older tools may behave differently.

Conclusion #

Your system is now running Ubuntu 26.04 LTS Resolute Raccoon. Re-enable any third-party repositories you disabled before the upgrade and verify that your critical services are running. For a full list of known issues and changes, see the official Ubuntu 26.04 release notes .

Branches are how Git keeps your work separated from the main line of development. A new branch lets you experiment, fix a bug, or build a feature without touching what is already shipped, and a merge brings the work back together when it is ready. The tool that creates, lists, and removes those branches is git branch.

This guide explains how to use git branch to manage local and remote branches, filter by merged or upstream state, rename branches, and clean up stale ones.

git branch Syntax #

The general form of the command is:

git branch [OPTIONS] [BRANCH] [START_POINT]

With no arguments, git branch lists your local branches and marks the currently checked-out one with an asterisk. With a branch name, it creates a new branch pointing at the current commit. With additional flags, it can list remote branches, delete branches, rename them, or set upstream tracking.

Listing Branches #

To list the local branches in the current repository, run git branch with no arguments:

git branch

 develop
* main
feature/login

The asterisk marks the branch you are currently on. The branches are sorted alphabetically.

To include remote-tracking branches, add -a (all):

git branch -a

 develop
* main
feature/login
remotes/origin/HEAD -> origin/main
remotes/origin/develop
remotes/origin/main

Anything prefixed with remotes/ is a local reference to a branch on a remote, not a branch you can commit to directly. Check it out to create a local tracking branch.

To list only remote-tracking branches, use -r:

git branch -r

To see the latest commit on each branch, add -v:

git branch -v

 develop a1b2c3d Add release notes
* main 7e8f9a0 Merge pull request #42
feature/login 3d4e5f6 Stub login form

For even more detail, -vv also prints the upstream branch each local branch tracks and whether it is ahead, behind, or in sync:

git branch -vv

 develop a1b2c3d [origin/develop] Add release notes
* main 7e8f9a0 [origin/main] Merge pull request #42
feature/login 3d4e5f6 [origin/feature/login: ahead 2] Stub login form

Creating a Branch #

To create a new branch, pass the name as an argument. This creates the branch at the current HEAD but does not switch to it:

git branch feature/login

To start the branch from a specific commit, tag, or another branch, pass it as the second argument:

git branch hotfix v1.4.0

git branch hotfix 3d4e5f6

Creating a branch without switching to it is useful when you want to mark a commit for later work. Most of the time, though, you create a branch and switch to it in one step. The modern command for that is git switch -c:

git switch -c feature/login

The older equivalent is git checkout -b feature/login. Both create the branch at the current commit and check it out immediately. See the create and list Git branches guide for a fuller walkthrough.

Renaming a Branch #

To rename the branch you are currently on, use -m with the new name:

git branch -m new-name

To rename any branch, pass both the old and the new name:

git branch -m old-name new-name

If a branch with the target name already exists, this form fails to protect you from overwriting it. To force the rename and overwrite the existing branch, use the capital -M instead. Use -M with care: it discards the destination branch.

After renaming a branch that is already pushed, push the new name to the remote and delete the old one so collaborators see the change. The rename a Git branch guide walks through the full local-and-remote flow.

Deleting a Branch #

To delete a local branch that has been merged into the current branch, use -d:

git branch -d feature/login

Deleted branch feature/login (was 3d4e5f6).

Git refuses to delete a branch that has unmerged work, to protect you from losing commits:

error: The branch 'feature/wip' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature/wip'.

If you are sure the work is no longer needed, force the deletion with -D:

git branch -D feature/wip

You cannot delete the branch you are currently on. Switch to another branch first, then delete it. For remote branch deletion, see the delete local and remote Git branch guide.

Filtering by Merged State #

git branch can filter branches by whether they are fully merged into the current branch. List branches that have been merged:

git branch --merged

This is the safest way to find branches that can be deleted without losing history. Before deleting anything, preview the filtered list:

git branch --merged | grep -vE '^\*|^[[:space:]]*(main|develop)$'

The grep filter keeps the current branch and the protected main and develop branches out of the list. If the output looks correct, pipe the same list to git branch -d:

git branch --merged | grep -vE '^\*|^[[:space:]]*(main|develop)$' | xargs -r git branch -d

To list branches that still have unmerged work, use --no-merged:

git branch --no-merged

These are the branches you should review before deleting, because they contain commits that are not on your current branch.

Filtering Remote Branches Too #

--merged and --no-merged accept a reference argument. To check against main from the remote:

git branch --merged origin/main

This is useful in CI or cleanup scripts where you want to see which local branches are safely merged into the shipped code, regardless of which branch you are currently on.

Setting an Upstream Branch #

An upstream branch tells Git which remote branch your local branch tracks for git pull and git push. To set it on an existing branch, use --set-upstream-to (or -u):

git branch --set-upstream-to=origin/main main

Branch 'main' set up to track remote branch 'main' from 'origin'.

To remove tracking information from a branch, use --unset-upstream:

git branch --unset-upstream main

When you push a new branch to a remote for the first time, pass -u to git push to create the remote branch and set it as the upstream in one step:

git push -u origin feature/login

Showing the Current Branch #

To print just the name of the branch you are on, use --show-current:

git branch --show-current

main

This is the right command for shell prompts and scripts. It prints nothing if you are in a detached HEAD state, which scripts can detect and handle.

Copying a Branch #

git branch -c copies a branch, including its reflog and configuration, to a new name:

git branch -c old-branch new-branch

The original branch is kept. Use the capital -C to force the copy and overwrite an existing target branch. Copying is less common than creating a fresh branch, but it is useful when you want to preserve the history and config of a branch under a new name.

Sorting the Branch List #

By default, branches are listed alphabetically. The --sort option changes the order. To sort by the date of the most recent commit:

git branch --sort=-committerdate

The minus sign reverses the order, so the most recently updated branch appears first. This is handy when you return to a project after a break and want to see what you were working on last.

Quick Reference #

FAQ #

What is the difference between git branch and git checkout?
git branch manages branches: creating, listing, renaming, and deleting. git checkout (and its modern replacement git switch) changes which branch you are on. Creating and switching in one step uses git switch -c or git checkout -b.

How do I delete a remote branch?
git branch -d only deletes local branches. To delete a branch on the remote, run git push origin --delete BRANCH_NAME. The delete local and remote Git branch guide covers the full flow, including cleanup of stale tracking references.

Why does Git say “branch is not fully merged”?
The branch has commits that are not reachable from your current branch. Git is protecting you from losing work. Review the commits with git log BRANCH_NAME, merge them if needed, and then use -d again. If you are certain the commits are not needed, force the delete with -D.

How do I see which branch a remote branch tracks locally?
Run git branch -vv. The output includes each local branch’s upstream in brackets along with its ahead and behind counts relative to that upstream.

Can I list branches sorted by who committed most recently?
Yes. Use git branch --sort=-committerdate to sort branches by the timestamp of their most recent commit, with the freshest branch first. This is a fast way to see what is actively being worked on.

Conclusion #

git branch covers the full lifecycle of a branch: creating it, renaming it, keeping track of what it points at, and deleting it when the work is done. Combined with git switch for moving between branches and git merge for integrating changes, it is the foundation of any Git workflow.

For related Git commands, see the git diff guide for reviewing changes and the git log guide for inspecting branch history.

By default, a Bash script will keep running after a command fails, treat unset variables as empty strings, and hide errors inside pipelines. That is convenient for one-off commands in an interactive shell, but inside a script it is a recipe for silent corruption: a failed backup step that still reports success, an unset path that expands to rm -rf /, a curl | sh pipeline that swallows a 500 error.

Bash strict mode is a short set of flags you put at the top of a script to make the shell fail loudly instead. This guide explains each flag in set -euo pipefail, shows what it changes with real examples, and covers the cases where you need to turn it off.

The Strict Mode Line #

You will see this line at the top of many modern shell scripts:

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

Each flag addresses a different class of silent failure:

• set -e exits immediately when a command returns a non-zero status.
• set -u treats references to unset variables as an error.
• set -o pipefail makes a pipeline fail if any command in it fails, not just the last.
• IFS=$'\n\t' narrows word splitting so unquoted expansions do not split on spaces.

You can enable the options separately, but in practice they are almost always used together.

set -e: Exit on Error #

Without set -e, a failing command in a script does not stop execution. The script happily continues to the next line:

#!/usr/bin/env bash
cp /does/not/exist /tmp/dest
echo "Backup complete"

Running it prints both the error and the success message:

./no-strict.sh

cp: cannot stat '/does/not/exist': No such file or directory
Backup complete

The script exits with status 0, so any caller thinks the backup worked. Adding set -e changes the behavior:

#!/usr/bin/env bash
set -e
cp /does/not/exist /tmp/dest
echo "Backup complete"

./strict.sh
echo $?

cp: cannot stat '/does/not/exist': No such file or directory
1

The script stops at the failing cp, never prints “Backup complete”, and exits with a non-zero status. Anyone scheduling this through cron or a CI pipeline now gets a real failure signal.

Opting Out for a Single Command #

Sometimes you expect a command to fail and want to handle the result yourself. Append || true to tell set -e to ignore the exit status of that one command:

grep "pattern" config.txt || true

You can also use if or &&, which set -e treats as deliberate checks:

if ! grep -q "pattern" config.txt; then
 echo "pattern missing"
fi

This is the canonical way to check for something without exiting the script when it is not there.

set -u: Fail on Unset Variables #

A classic shell footgun is a typo in a variable name. Without strict mode, Bash silently expands the misspelled variable to an empty string:

#!/usr/bin/env bash
TARGET_DIR="/var/backups"
rm -rf "$TARGE_DIR/old"

The script deletes /old because $TARGE_DIR is empty. With set -u, the same script exits before the rm runs:

#!/usr/bin/env bash
set -u
TARGET_DIR="/var/backups"
rm -rf "$TARGE_DIR/old"

./unset-strict.sh: line 4: TARGE_DIR: unbound variable

Handling Optional Variables #

Environment variables that may or may not be set need a default to play nicely with set -u. The ${VAR:-default} syntax provides one without touching the original:

PORT="${PORT:-8080}"
echo "Listening on $PORT"

If $PORT is unset or empty, the script uses 8080. If it is set, the original value is kept.

set -o pipefail: Catch Failures Inside Pipelines #

By default, the exit status of a pipeline is the exit status of the last command. Everything to the left can fail silently:

curl https://bad.example.com/data | tee data.txt

If curl fails with a 404, the pipeline still exits 0 because tee wrote its (empty) input successfully. With set -o pipefail, the pipeline adopts the first non-zero exit status from any command in it:

#!/usr/bin/env bash
set -o pipefail
curl https://bad.example.com/data | tee data.txt
echo "Exit: $?"

curl: (6) Could not resolve host: bad.example.com
Exit: 6

This is the one flag that fixes the most “my script said it succeeded but clearly did not” bugs, and it is the one most often forgotten when people add just set -e.

IFS: Safer Word Splitting #

The Internal Field Separator (IFS) controls how Bash splits unquoted expansions into words. The default is space, tab, and newline, which means a filename with a space in it gets split into two arguments:

files="one two.txt three.txt"
for f in $files; do
 echo "$f"
done

one
two.txt
three.txt

Setting IFS=$'\n\t' removes the space from the separator list. You still get clean splitting on newlines (useful for reading find or ls output) and on tabs (useful for TSV data), but spaces inside values are preserved.

Even with a narrower IFS, always quote your expansions ("$var", "${array[@]}"). IFS tightening is a safety net, not a replacement for quoting.

When Strict Mode Gets in the Way #

Strict mode is opinionated, and a few situations push back. The most common one is reading a file line by line with a while loop and a counter:

count=0
while read -r line; do
 count=$((count + 1))
done < input.txt

That works fine, but if you increment with ((count++)) inside set -e, the script exits on the first iteration because ((count++)) returns the pre-increment value (0), which Bash treats as a failure. Use count=$((count + 1)) or ((count++)) || true to stay compatible.

Another common case is probing for a command:

if ! command -v jq >/dev/null; then
 echo "jq is not installed"
 exit 1
fi

Using command -v inside an if is safe even under set -e, because set -e does not trigger on commands in conditional contexts.

If you need to temporarily disable a flag for a specific block, turn it off and back on:

set +e
some_flaky_command
result=$?
set -e

This is cleaner than sprinkling || true everywhere when you have a block of commands that need softer error handling.

A Minimal Strict Script Template #

Use this as a starting point for new scripts:

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

# Script body goes here.

It is four lines, and it catches the majority of silent failures that cause shell scripts to misbehave in production.

Quick Reference #

Troubleshooting #

Script exits silently with no error message
A command is failing under set -e without printing anything. Run the script with bash -x script.sh to trace execution and see which line aborts.

unbound variable on a variable that sometimes is set
Replace the reference with ${VAR:-} to provide an empty default, or ${VAR:-fallback} to provide a meaningful one.

Pipeline fails on a command that is supposed to stop early
Commands like head can cause the producer to receive SIGPIPE, which pipefail treats as a failure. Either redesign the pipeline or wrap the producer in || true when the early exit is expected.

Strict mode breaks a sourced script
The set flags apply to the current shell. If you source a script that expects the old behavior, either fix the sourced script or wrap the source call between set +e and set -e.

FAQ #

Should every Bash script use strict mode?
For scripts that run unattended (cron jobs, CI steps, deployment scripts), yes. For short interactive helpers, the flags are still useful, but the cost of a missed edge case is lower.

Does strict mode work in sh or dash?
set -e and set -u are POSIX, so they work in any compliant shell. set -o pipefail is a Bash extension that also works in Zsh and Ksh, but not in pure POSIX sh or dash.

Is set -e really that unreliable?
set -e has well-known edge cases, especially around functions and subshells. It is not a replacement for explicit error handling in critical paths, but combined with pipefail and -u it catches far more bugs than it causes.

How do I pass set -euo pipefail to a one-liner?
Use bash -euo pipefail -c 'your command' when invoking Bash from another program such as ssh or a Makefile.

Conclusion #

set -euo pipefail and a tighter IFS catch many of the silent failures that make shell scripts hard to trust. Pair strict mode with clear error handling using Bash functions and a proper shebang line when you want scripts to fail early and predictably.

Sooner or later, every Git user runs into the same question: should you use git fetch or git pull to get the latest changes from the remote? The two commands look similar, and both talk to the remote repository, but they do very different things to your working branch.

This guide explains the difference between git fetch and git pull, how each command works, and when to use one over the other.

Quick Reference #

What git fetch Does #

git fetch downloads commits, branches, and tags from a remote repository and stores them locally under remote-tracking references such as origin/main or origin/feature-x. It does not touch your working directory, your current branch, or the index.

git fetch origin

remote: Enumerating objects: 12, done.
remote: Counting objects: 100% (12/12), done.
From github.com:example/project
4a1c2e3..9f7b8d1 main -> origin/main
a6d4c02..1e2f3a4 feature-x -> origin/feature-x

The output shows which remote branches were updated. After the fetch, the local branch main is still pointing to whatever commit it was on before. Only the remote-tracking branch origin/main has moved.

You can then inspect what changed before doing anything with it:

git log main..origin/main

This is the safe way to look at new work without merging or rebasing yet. It gives you a preview of what the remote has that your branch does not.

What git pull Does #

git pull is a convenience command. Under the hood, it runs git fetch followed by an integration step (a merge by default, or a rebase if configured). In other words:

git pull origin main

is roughly equivalent to:

git fetch origin
git merge origin/main

After git pull, your current branch has moved forward, and your working directory may contain new files, updated files, or merge conflicts that need resolving. The change is immediate and affects your checked-out branch.

Side-By-Side Comparison #

The difference between the two commands comes down to what they change in your repository.

git fetch is read-only from your branch’s perspective. git pull actively changes your branch.

When to Use git fetch #

Use git fetch when you want to see what changed on the remote without integrating anything yet. This is useful before you start new work, before rebasing a feature branch, or when you want to inspect a teammate’s branch safely.

For example, after fetching, you can compare your branch with the remote like this:

git log HEAD..origin/main --oneline

This shows commits that exist on the remote but not in your current branch. Running git fetch often is cheap and has no side effects on your work, which is why many developers do it regularly throughout the day.

When to Use git pull #

Use git pull when you are ready to bring remote changes into your current branch and keep working on top of them. The common flow looks like this:

git checkout main
git pull origin main

This is the quickest way to sync a branch with its upstream when you know the integration will be straightforward, such as on a shared main branch where you rarely have local commits. git pull always updates the branch you currently have checked out, so it is worth confirming where you are before you run it.

If you want a cleaner history without merge commits, configure pull to rebase:

git config --global pull.rebase true

From that point on, git pull runs git fetch followed by git rebase instead of git merge. Your local commits are replayed on top of the fetched changes, producing a linear history.

Avoiding Merge Surprises #

The biggest reason to prefer git fetch over git pull in day-to-day work is control. A bare git pull on a branch where you have local commits can create a merge commit, introduce conflicts, or rewrite history during a rebase, all in one step.

A safer pattern is:

git fetch origin
git log HEAD..origin/main --oneline
git merge origin/main

You fetch first, review what is coming, then decide whether to merge, rebase, or defer the integration. For active feature branches, this workflow avoids most of the “what just happened to my branch” moments.

If you already ran git pull and need to inspect what happened, start with:

git log --oneline --decorate -n 5

This helps you confirm whether Git created a merge commit, fast-forwarded the branch, or rebased your local work.

If the pull created a merge commit that you do not want, ORIG_HEAD often points to the commit your branch was on before the pull. In that case, you can reset back to it:

git reset --hard ORIG_HEAD

Useful Flags #

A few flags make both commands more predictable in real workflows.

• git fetch --all - Fetch from every configured remote, not only origin.
• git fetch --prune - Remove remote-tracking branches that no longer exist on the remote.
• git fetch --tags - Download tags in addition to branches.
• git pull --rebase - Rebase your local commits on top of the fetched changes instead of merging.
• git pull --ff-only - Update the branch only if Git can fast-forward it; prevents unexpected merge commits.

--ff-only is especially useful on shared branches. If your branch cannot move forward by simply advancing the pointer, the pull fails and you decide what to do next.

FAQ #

Does git fetch modify any local files?
No. It only updates remote-tracking references such as origin/main. Your branches, working directory, and staging area stay the same.

Is git pull the same as git fetch plus git merge?
By default, yes. With pull.rebase set to true (or --rebase on the command line), it runs git fetch followed by git rebase instead.

Which one should I use daily?
Prefer git fetch for visibility and git pull --ff-only (or git pull --rebase) for the integration step. A bare git pull works, but it hides two operations behind one command.

How do I see what git fetch downloaded?
Use git log main..origin/main to see commits on the remote that are not yet in your local branch, or git diff main origin/main to compare the content directly.

Can git fetch cause conflicts?
No. Conflicts only happen when you merge or rebase the fetched commits into your branch. Fetching itself is conflict-free.

Conclusion #

git fetch lets you inspect remote changes without touching your branch, while git pull fetches and integrates those changes in one step. If you want more control and fewer surprises, fetch first, review the incoming commits, and then merge or rebase on your own terms. For more Git workflow details, see the git log command and git diff command guides.

When you download an ISO image, a backup archive, or a large release tarball, there is no easy way to tell by looking whether the file arrived intact. A single flipped bit can break a boot image or turn a compressed archive into junk, and a compromised mirror can serve a tampered file that looks legitimate. The fix is to compare a cryptographic fingerprint of the file against a value the publisher has signed or posted somewhere you trust.

This guide shows how to use sha256sum and md5sum to generate, compare, and verify checksums on Linux, and when to use each one.

sha256sum and md5sum Syntax #

Both commands follow the same form:

sha256sum [OPTIONS] [FILE]...
md5sum [OPTIONS] [FILE]...

Without options, each command prints a hex digest followed by two spaces and the file name. Pass -c to verify files against a list of previously generated checksums.

sha256sum vs md5sum #

The two tools do the same job: they read a file and print a fixed-length fingerprint. The difference is the algorithm and, by extension, how safe the result is against intentional tampering.

md5sum uses the MD5 algorithm and produces a 128-bit digest. MD5 is fast but has been broken for years: it is possible to construct two different files that share the same MD5 hash. Treat it as a checksum for accidental corruption only, not for authenticity or security.

sha256sum uses SHA-256 from the SHA-2 family and produces a 256-bit digest. It is the default choice for verifying downloads, release artifacts, and anything where the threat model includes a malicious middle party. Most Linux distributions publish SHA256SUMS files next to their ISO images for exactly this reason.

When in doubt, use sha256sum. Reach for md5sum only when a publisher provides MD5 values and nothing stronger, or when you need quick parity checks between known-good files.

Generating a Checksum for a File #

To produce a SHA-256 digest for a single file, pass it as an argument:

sha256sum ubuntu-24.04.2-desktop-amd64.iso

5e38b55d57d94ff029719342357325ed3bda38fa80054f9330dc789cd2d43931 ubuntu-24.04.2-desktop-amd64.iso

The output is one line: the hex digest, two spaces, and the file name. The same file always produces the same digest, so you can run the command again after a copy or a download and compare the values by eye.

md5sum behaves the same way:

md5sum ubuntu-24.04.2-desktop-amd64.iso

2e3720b76b2f9f96edc43ec4d87d7d52 ubuntu-24.04.2-desktop-amd64.iso

Notice that the MD5 digest is shorter. That is the 128-bit hash encoded in 32 hex characters, compared with 64 hex characters for SHA-256.

Generating Checksums for Multiple Files #

Both commands accept any number of file arguments and print one line per file:

sha256sum *.tar.gz

b2b09c1e04b2a3a4c5d6e7f890123456789abcdef0123456789abcdef01234567 backup-2026-04-01.tar.gz
c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f708192a3b4c5d6e7f8 backup-2026-04-08.tar.gz

To save the output to a checksum file that you can share or verify later, redirect it:

sha256sum *.tar.gz > SHA256SUMS

The resulting SHA256SUMS file can be published alongside the archives, and anyone who downloads them can run a single command to confirm that their copy matches.

Verifying a File Against a Known Checksum #

The most common task is to check that a download matches the digest the publisher posted. Distributions usually ship a SHA256SUMS file that lists every release file and its digest. Change into the directory that holds both the archive and the checksum file, then pass -c:

sha256sum -c SHA256SUMS

ubuntu-24.04.2-desktop-amd64.iso: OK
ubuntu-24.04.2-live-server-amd64.iso: OK

sha256sum reads each line of SHA256SUMS, recomputes the digest for the named file, and prints OK when they match. Any line whose file is missing or whose digest differs prints a clear error and causes the command to exit with a non-zero status, which is convenient in scripts.

When you only care about one file out of many, grep the relevant line into the check:

grep "ubuntu-24.04.2-desktop-amd64.iso" SHA256SUMS | sha256sum -c -

The trailing - tells sha256sum to read the checksum list from standard input. This keeps the verification scoped to a single file without creating a second checksum file.

Comparing a File to a Published Digest #

Sometimes the publisher does not provide a full SHA256SUMS file but instead shows a single digest on a release page. You can compare it directly without creating a file:

echo "5e38b55d57d94ff029719342357325ed3bda38fa80054f9330dc789cd2d43931 ubuntu-24.04.2-desktop-amd64.iso" | sha256sum -c -

ubuntu-24.04.2-desktop-amd64.iso: OK

The key detail is the double space between the digest and the file name. That is the exact format sha256sum produces and expects, and a single space will cause the check to fail.

Quiet and Warn Modes #

During an automated check, the per-file OK lines can be noisy. The --quiet option suppresses successful lines so only failures appear:

sha256sum -c --quiet SHA256SUMS

If every file passes, the command prints nothing and exits with status 0. If a file fails, you see a single failure line and a non-zero exit status, which fits well in a CI job or a backup script.

To flag lines in a checksum file that are not formatted correctly, add --warn. This is helpful when the file was assembled by hand and you want to be sure every entry parses.

Common Options #

The flags below are the ones you are likely to use day to day:

• -c, --check - Read digests from a file and verify each one.
• -b, --binary - Mark files as binary in the output (default on Linux).
• -t, --text - Read files in text mode (rare on Linux, kept for portability).
• --quiet - Suppress OK lines when checking.
• --status - Print nothing; rely on the exit status alone.
• --ignore-missing - Skip files listed in the digest file that are not present.
• --tag - Output BSD-style tagged format, useful when mixing hash algorithms.

md5sum accepts the same flags, which makes it easy to swap one command for the other when the algorithm changes.

Quick Reference #

Verifying a Download End to End #

Putting the pieces together, a typical download check looks like this:

wget https://releases.ubuntu.com/24.04/ubuntu-24.04.2-desktop-amd64.iso
wget https://releases.ubuntu.com/24.04/SHA256SUMS
sha256sum -c --ignore-missing SHA256SUMS

The --ignore-missing flag keeps the check focused on the file you actually downloaded instead of failing on every other release listed in SHA256SUMS.

For full confidence, also verify the signature on SHA256SUMS itself using the publisher’s GPG key. A digest is only as trustworthy as the source you got it from, so a signed checksum file closes the loop.

Troubleshooting #

Checksum mismatch on a freshly downloaded file
Re-download the file, ideally from a different mirror. The most common cause is a truncated transfer or a network error. If the second download still fails, the file on the mirror may be stale or tampered with, and you should report it to the project.

No such file or directory when running with -c
The names in the checksum file are resolved relative to the current directory. Change into the directory that holds the files, or edit the checksum file to use paths that match where the files live.

improperly formatted checksum line warnings
A single space between the digest and the file name instead of two, trailing whitespace, or Windows line endings will all trip the parser. Run dos2unix on the file or recreate it with sha256sum > SHA256SUMS to reset the format.

The MD5 digest matches but you still do not trust the file
You are right to be cautious. MD5 collisions are practical, so match an MD5 against accidental corruption only. Ask the publisher for a SHA-256 digest or a signed checksum file.

FAQ #

Which is faster, sha256sum or md5sum?
md5sum is faster, sometimes noticeably so on large files. The speed difference rarely matters on modern hardware, and it is not a good reason to pick MD5 over SHA-256 for security-sensitive checks.

Can I use sha256sum on a directory?
Not directly. Hash tools operate on files. To produce a digest that represents an entire directory, pipe a deterministic listing such as find ... -type f -print0 | sort -z | xargs -0 sha256sum through another sha256sum.

Where do I find the expected digest for a Linux distro ISO?
Every major distribution publishes a SHA256SUMS or SHA512SUMS file on its download page, usually along with a detached GPG signature. Prefer those files over digests shown in third-party blog posts.

Is sha256sum available by default on Linux?
Yes. Both sha256sum and md5sum ship with the GNU coreutils package, which is installed on every mainstream Linux distribution.

Conclusion #

sha256sum should be the default for verifying downloads and backups, with md5sum reserved for quick corruption checks when the publisher provides nothing stronger. When you pair a SHA-256 digest with a signed checksum file and a trusted key, you can answer the question that matters most: did I get the file the publisher actually shipped?

When you run a PostgreSQL database in production, you rarely want every application and every developer to connect as the postgres superuser. A clean setup gives each service its own login role with a scoped set of privileges, so a bug or a leaked password cannot touch unrelated data.

PostgreSQL handles this with roles. A role can represent a single user, a group, or both at the same time, and privileges are granted to roles rather than to raw login accounts. This guide explains how to create roles, set passwords, grant and revoke privileges, and clean up roles you no longer need.

Roles vs Users in PostgreSQL #

Historically, PostgreSQL had separate CREATE USER and CREATE GROUP statements. Modern versions replaced both with a single concept: the role. A role with the LOGIN attribute can connect to the server, which makes it a user. A role without LOGIN is typically used as a group that other roles inherit privileges from.

In practice, CREATE USER is still valid and is treated as a shortcut for CREATE ROLE ... LOGIN. We will use both forms in this guide.

Connecting to PostgreSQL #

All the commands below run inside the psql shell. On most systems you can open it as the postgres system user:

sudo -u postgres psql

You will see a prompt like this:

postgres=#

Every SQL statement ends with a semicolon. If you forget it, psql keeps waiting for more input.

Creating a Role #

The simplest form of CREATE ROLE takes just a name:

CREATE ROLE linuxize;

This role exists but cannot log in yet and has no password.

To create a login role with a password, use LOGIN:

CREATE ROLE linuxize_login WITH LOGIN PASSWORD 'strong_password_here';

The equivalent shortcut is:

CREATE USER linuxize_user WITH PASSWORD 'strong_password_here';

Both statements produce the same result. Use whichever form reads more clearly in your scripts.

Useful Role Attributes #

You can combine several attributes in a single CREATE ROLE statement. These are the ones you will reach for most often:

• LOGIN - The role can connect to the server.
• PASSWORD 'secret' - Sets the login password.
• SUPERUSER - Grants full access, equivalent to the postgres role. Use sparingly.
• CREATEDB - The role may create new databases.
• CREATEROLE - The role may create and modify other roles.
• INHERIT - The role automatically inherits privileges of roles it is a member of. This is the default.
• VALID UNTIL 'timestamp' - Expires the password at the given time.
• CONNECTION LIMIT n - Caps the number of concurrent connections for this role.

For example, to create a login role that can also create databases and is limited to ten concurrent connections:

CREATE ROLE app_owner WITH LOGIN PASSWORD 'strong_password_here' CREATEDB CONNECTION LIMIT 10;

Listing Existing Roles #

To see every role on the server, use the \du meta-command:

\du

 List of roles
Role name | Attributes
-----------+------------------------------------------------------------
app_owner | Create DB, 10 connections
linuxize |
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS

The Attributes column tells you what each role can do. A blank column means the role has no special attributes beyond the defaults, such as NOLOGIN and INHERIT.

Changing a Role #

Use ALTER ROLE to change attributes, rename a role, or reset a password. To change the password:

ALTER ROLE linuxize WITH PASSWORD 'new_password_here';

To grant an additional attribute:

ALTER ROLE linuxize CREATEDB;

To remove one, prefix it with NO:

ALTER ROLE linuxize NOCREATEDB;

Creating a Database for the Role #

It is common to give each application its own database owned by its login role. Create the database and assign ownership in one statement:

CREATE DATABASE linuxize_app OWNER linuxize;

The owner of a database has full control over it, so the role can create tables, schemas, and other objects without any further grants.

Granting Privileges #

Privileges in PostgreSQL are granted at several levels: database, schema, table, column, sequence, and function. The syntax is consistent across levels:

GRANT privilege_list ON object_type object_name TO role_name;

Database-level Privileges #

To let a role connect to a database and create objects in it:

GRANT CONNECT ON DATABASE linuxize_app TO linuxize;
GRANT CREATE ON DATABASE linuxize_app TO linuxize;

CONNECT controls whether the role can open a session to the database. CREATE controls whether it can create schemas.

Schema-level Privileges #

To let a role create and use objects inside a schema:

GRANT USAGE ON SCHEMA public TO linuxize;
GRANT CREATE ON SCHEMA public TO linuxize;

USAGE is required for almost every operation inside the schema. CREATE lets the role add new tables, views, or functions.

Table-level Privileges #

Table privileges match the common SQL operations:

GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE orders TO linuxize;

To grant every available table privilege at once:

GRANT ALL PRIVILEGES ON TABLE orders TO linuxize;

To grant the same privileges on every existing table in a schema:

GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO linuxize;

This only affects tables that exist at the moment you run the command. Tables created later are not covered.

Default Privileges for Future Objects #

To cover tables created in the future, set default privileges:

ALTER DEFAULT PRIVILEGES IN SCHEMA public
 GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO linuxize;

From this point on, any new table created in public by the current role inherits the listed privileges for linuxize.

Revoking Privileges #

REVOKE is the mirror of GRANT and uses the same structure:

REVOKE INSERT, UPDATE, DELETE ON TABLE orders FROM linuxize;

To strip every privilege on a table:

REVOKE ALL PRIVILEGES ON TABLE orders FROM linuxize;

Revoking a privilege only affects the privileges you previously granted. Ownership is a separate concept: the owner of an object always keeps full control over it, regardless of grants.

Group Roles #

To manage privileges for a team, create a role without LOGIN and add members to it:

CREATE ROLE readonly;
GRANT CONNECT ON DATABASE linuxize_app TO readonly;
GRANT USAGE ON SCHEMA public TO readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly;

GRANT readonly TO linuxize;

linuxize now inherits every privilege granted to readonly. To remove the membership later:

REVOKE readonly FROM linuxize;

This pattern scales better than granting privileges role by role, because you change permissions in one place.

Deleting a Role #

To drop a role, use DROP ROLE:

DROP ROLE linuxize;

PostgreSQL refuses the command if the role still owns any objects or holds any privileges. To clean these up first, reassign the objects and drop dependent privileges in each database where the role owns objects:

REASSIGN OWNED BY linuxize TO postgres;
DROP OWNED BY linuxize;
DROP ROLE linuxize;

REASSIGN OWNED transfers ownership of objects owned by the role in the current database, and DROP OWNED removes any remaining privileges there. If the role owns objects in other databases, repeat the cleanup in each one before dropping the role.

Quick Reference #

Troubleshooting #

ERROR: permission denied for schema public
Grant USAGE on the schema: GRANT USAGE ON SCHEMA public TO role_name;. On PostgreSQL 15 and later, the public schema is no longer writable by default, so you may also need GRANT CREATE ON SCHEMA public.

ERROR: role "name" cannot be dropped because some objects depend on it
Reassign and drop the role’s objects first: REASSIGN OWNED BY name TO postgres; DROP OWNED BY name;, then run DROP ROLE name; again.

FATAL: password authentication failed for user
Check that the role has LOGIN and that the authentication method in pg_hba.conf matches the client (for example, md5 or scram-sha-256). Reload the configuration with SELECT pg_reload_conf(); after editing pg_hba.conf.

New tables are not visible to a read-only user
Grants on ALL TABLES IN SCHEMA only cover tables that exist at grant time. Set ALTER DEFAULT PRIVILEGES for the owning role so new tables inherit the read permissions automatically.

FAQ #

What is the difference between CREATE USER and CREATE ROLE?
CREATE USER is a shortcut for CREATE ROLE ... LOGIN. Both create the same kind of object. Use CREATE USER when you want a login account and CREATE ROLE when you are creating a group role without login.

Can a single role be both a user and a group?
Yes. A role with LOGIN can still be granted to other roles. Members inherit its privileges as long as INHERIT is set, which is the default.

How do I change the owner of an existing database?
Use ALTER DATABASE db_name OWNER TO new_owner;. The new owner gains full control over the database and its objects.

Do I need to restart PostgreSQL after creating a role?
No. Role changes take effect immediately. Only changes to pg_hba.conf or the main server configuration require a reload or restart.

Conclusion #

Roles are the single unit of access control in PostgreSQL. Give each application its own login role, group shared privileges into group roles, and use ALTER DEFAULT PRIVILEGES so future objects stay consistent with your current policy.

For related reading, see how to check the PostgreSQL version and the installation guide for your distribution under the PostgreSQL tag .

Sometimes the change you need is already written, just on the wrong branch. A hotfix may land on main when it also needs to go to a maintenance branch, or a useful commit may be buried in a feature branch that you do not want to merge wholesale. In that situation, git cherry-pick lets you copy the effect of a specific commit onto your current branch.

This guide explains how git cherry-pick works, how to apply one or more commits safely, and how to handle the conflicts that can appear along the way.

Syntax #

The general syntax for git cherry-pick is:

git cherry-pick [OPTIONS] COMMIT...

• OPTIONS - Flags that change how Git applies the commit.
• COMMIT - One or more commit hashes, branch references, or commit ranges.

git cherry-pick replays the changes introduced by the selected commit on top of your current branch. Git creates a new commit, so the result has a different commit hash even when the file changes are the same.

Cherry-Picking a Single Commit #

Start by finding the commit you want to copy. This example lists the recent commits on a feature branch:

git log --oneline feature/auth

a3f1c92 Fix null pointer in auth handler
d8b22e1 Add login form validation
7c4e003 Refactor session logic

The output gives you the abbreviated commit hashes. In this case, a3f1c92 is the fix we want to move.

Switch to the target branch before running git cherry-pick:

git switch main
git cherry-pick a3f1c92

[main 9b2d4f1] Fix null pointer in auth handler
Date: Tue Apr 14 10:42:00 2026 +0200
1 file changed, 2 insertions(+)

Git applies the change from a3f1c92 to main and creates a new commit, 9b2d4f1. The subject line is the same, but the commit hash is different because the parent commit is different.

Cherry-Picking Multiple Commits #

If you need more than one non-consecutive commit, pass each hash in the order you want Git to apply them:

git cherry-pick a3f1c92 d8b22e1

Git creates a separate new commit for each one. This works well when you need a few targeted fixes but do not want the rest of the source branch.

For a range of consecutive commits, use the range notation:

git cherry-pick a3f1c92^..7c4e003

This tells Git to include a3f1c92 and every commit after it up to 7c4e003. If you omit the caret, the starting commit itself is excluded:

git cherry-pick a3f1c92..7c4e003

That form applies every commit after a3f1c92 through 7c4e003.

Applying Changes Without Committing #

Sometimes you want the changes from a commit, but not an automatic commit for each one. Use --no-commit (or -n) to apply the changes to your working tree and staging area without creating the commit yet:

git cherry-pick --no-commit a3f1c92

This is useful when you want to combine several small fixes into one commit on the target branch, or when you need to edit the files before committing.

After reviewing the result, create the commit yourself:

git status
git commit -m "Backport auth null-check fix"

This gives you more control over the final commit message and lets you group related backports together.

Recording Where the Commit Came From #

For maintenance branches and backports, it is often helpful to keep a reference to the original commit. Use -x to append the source commit hash to the new commit message:

git cherry-pick -x a3f1c92

Git adds a line like this to the new commit message:

(cherry picked from commit a3f1c92...)

That extra line makes future audits easier, especially when you need to prove that a fix on a release branch came from a reviewed change on another branch.

Cherry-Picking a Merge Commit #

Cherry-picking a regular commit is straightforward, but merge commits need one extra option. Git must know which parent to treat as the main line:

git cherry-pick -m 1 MERGE_COMMIT_HASH

• -m 1 - Use the first parent as the base, which is usually the branch that received the merge.
• -m 2 - Use the second parent instead.

If you are not sure which parent is which, inspect the history first:

git log --oneline --graph

Cherry-picking merge commits is more advanced and easier to get wrong. If the goal is to bring over an entire merged feature, a normal merge is often clearer than cherry-picking the merge commit itself.

Resolving Conflicts #

If the target branch has changed in the same area of code, Git may stop and ask you to resolve a conflict:

error: could not apply a3f1c92... Fix null pointer in auth handler
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".

Open the conflicted file and look for the conflict markers:

<<<<<<< HEAD
return session.getUser();
=======
if (session == null) return null;
return session.getUser();
>>>>>>> a3f1c92 (Fix null pointer in auth handler)

Edit the file to keep the final version you want, then stage it and continue:

git add src/auth.js
git cherry-pick --continue

If you decide the commit is not worth applying after all, abort the operation:

git cherry-pick --abort

git cherry-pick --abort puts the branch back where it was before the cherry-pick started.

A Safe Backport Workflow #

When you cherry-pick onto a release or maintenance branch, slow down and make the source obvious. A simple workflow looks like this:

git switch release/1.4
git pull --ff-only
git cherry-pick -x a3f1c92
git status

The important part is the sequence. Start from the branch that needs the fix, make sure it is up to date, cherry-pick with -x, then review and test the branch before pushing it. This avoids the common mistake of copying a fix into an outdated branch and shipping an untested backport.

If the picked commit depends on earlier refactors or new APIs that are not present on the target branch, stop there. In that case, either copy the prerequisite commits too or recreate the fix manually.

When to Use git cherry-pick #

git cherry-pick is a good fit when you need a precise change without the rest of the branch:

• Backporting a bug fix from main to a release branch
• Recovering one useful commit from an abandoned feature branch
• Moving a small fix that was committed on the wrong branch
• Pulling a reviewed change into a hotfix branch without merging unrelated work

Avoid it when the target branch needs the full context of the source branch. If the commit depends on earlier commits, shared refactors, or schema changes, a merge or rebase is usually the cleaner option.

Troubleshooting #

error: could not apply ... during cherry-pick
The target branch has conflicting changes. Resolve the files Git marks as conflicted, stage them with git add, then run git cherry-pick --continue.

Cherry-pick created duplicate-looking history
That is normal. Cherry-pick copies the effect of a commit, not the original object. The new commit has a different hash because it has a different parent.

The picked commit does not build on the target branch
The commit likely depends on earlier work that is missing from the target branch. Inspect the source branch history with git log and either cherry-pick the prerequisites too or reimplement the change manually.

You picked the wrong commit
If the cherry-pick already completed, use git revert on the new commit. If the operation is still in progress, use git cherry-pick --abort.

Quick Reference #

For a printable quick reference, see the Git cheatsheet .

FAQ #

What is the difference between git cherry-pick and git merge?
git cherry-pick copies the effect of selected commits onto your current branch. git merge joins two branch histories and brings over all commits that are missing from the target branch.

Does cherry-pick change the original commit?
No. The source commit stays exactly where it is. Git creates a new commit on your current branch with the same file changes.

Should I use -x every time?
Not always, but it is a good habit for backports and maintenance branches. It gives you a clear link back to the original commit.

Can I cherry-pick commits from another remote branch?
Yes. Fetch the remote branch first, then cherry-pick the commit hash you want. You can inspect the incoming history with git log or review the file changes with git diff before applying anything.

Conclusion #

git cherry-pick is the tool to reach for when one commit matters more than the branch it came from. Use it for targeted fixes, keep -x in mind for backports, and fall back to merge or rebase when the change depends on broader branch context.

If your server is open to the public network, it needs a firewall. On Ubuntu and Debian, the easiest way to set one up is with ufw. This tool sits on top of iptables (or nftables on newer systems) and replaces complex rules with simple, easy-to-read commands.

This guide walks through the ufw command, from enabling the firewall and setting default policies to writing rules for ports, services, and specific addresses.

ufw Syntax #

The general form of the command is:

sudo ufw [OPTIONS] COMMAND [ARGS]

• OPTIONS - Flags such as --dry-run to preview what a rule would do.
• COMMAND - The action, for example enable, allow, deny, delete, or status.
• ARGS - The rule body, such as a port number, a service name, or a full rule specification.

ufw changes firewall rules, so almost every invocation needs sudo.

Checking the Firewall Status #

Before you touch the rules, check whether the firewall is running and what is already in place:

sudo ufw status

If ufw is inactive, you will see:

Status: inactive

This confirms that ufw is installed but not currently enforcing any firewall rules.

Once active, the same command lists the rules:

Status: active
To Action From
-- ------ ----
22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)

For a numbered view that is easier to reference when deleting rules, use:

sudo ufw status numbered

And for a more detailed output that shows default policies and logging level:

sudo ufw status verbose

Enabling and Disabling the Firewall #

The first time you enable ufw, make sure you have already allowed SSH. Enabling the firewall over an SSH session without an allow ssh rule will lock you out of the server.

Allow SSH first:

sudo ufw allow ssh

Then turn the firewall on:

sudo ufw enable

Firewall is active and enabled on system startup

At this point, ufw starts enforcing the rules immediately and will come back automatically after a reboot.

To stop the firewall and clear it from the startup sequence:

sudo ufw disable

A disabled ufw keeps the rules you defined. When you re-enable it, the same rules come back.

Default Policies #

Default policies decide what happens to traffic that does not match any rule. The usual hardening is to deny incoming traffic and allow outgoing traffic:

sudo ufw default deny incoming
sudo ufw default allow outgoing

After running these two commands, you only need to open the specific inbound ports your server should expose. Outbound traffic still flows freely, which is what most servers need.

You can also set the default for forwarded traffic, which matters if the host acts as a router or runs containers:

sudo ufw default deny routed

Allowing Connections #

The allow command is the one you will use most often. It accepts a service name, a port, a protocol, or a full rule.

Allow a Service by Name #

ufw reads /etc/services and understands common service names:

sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https

Each command opens the matching port (22, 80, and 443) for both TCP and UDP where applicable.

Allow a Specific Port #

To open a port directly, pass the port number:

sudo ufw allow 8080

By default, this opens the port for both TCP and UDP. To limit it to one protocol, add /tcp or /udp:

sudo ufw allow 8080/tcp
sudo ufw allow 53/udp

Allow a Port Range #

Port ranges require an explicit protocol:

sudo ufw allow 6000:6007/tcp
sudo ufw allow 6000:6007/udp

The colon separates the start and the end of the range, both inclusive.

Allow Traffic From a Specific Address #

To accept connections from a single IP address, use from:

sudo ufw allow from 203.0.113.25

To restrict that to a single service, add to any port:

sudo ufw allow from 203.0.113.25 to any port 22

Allow Traffic From a Subnet #

CIDR notation works the same way for whole networks:

sudo ufw allow from 192.168.1.0/24 to any port 3306

This is a common pattern for databases: the port stays closed to the internet and is only reachable from your internal network.

Allow Traffic on a Specific Interface #

To tie a rule to a network interface, add on INTERFACE:

sudo ufw allow in on eth1 to any port 3306

The in keyword applies the rule to inbound traffic on eth1. Use out for outbound traffic.

Denying Connections #

The deny command is the mirror of allow and takes the same arguments:

sudo ufw deny 23
sudo ufw deny from 198.51.100.77

When the default incoming policy is already deny, you usually do not need to write explicit deny rules for closed ports. Explicit denies are useful when you want to block a specific address while keeping a port open to everyone else.

To log the denied packets instead of silently dropping them, use reject:

sudo ufw reject 23

A reject sends an ICMP message back to the sender, while a deny drops the packet with no response.

Rate Limiting SSH #

ufw can throttle repeated connections from the same IP, which is handy for SSH brute-force protection:

sudo ufw limit ssh

The limit rule denies a connection if the source address attempts six or more connections in 30 seconds. This is a quick way to slow down password-guessing bots without installing a full intrusion-prevention tool.

Deleting Rules #

There are two common ways to remove a rule. The first is to repeat the rule with delete in front:

sudo ufw delete allow 8080/tcp

The second is to delete by rule number:

sudo ufw status numbered

 To Action From
-- ------ ----
[ 1] 22/tcp ALLOW IN Anywhere
[ 2] 80/tcp ALLOW IN Anywhere
[ 3] 8080/tcp ALLOW IN Anywhere

sudo ufw delete 3

ufw asks for confirmation before removing the rule. Keep in mind that after a deletion, the numbering shifts for the remaining rules, so always check the numbered status again before deleting another rule.

For a deeper walkthrough, see how to list and delete UFW firewall rules .

Application Profiles #

Services that come with their own ufw profile can be referenced by name. List them with:

sudo ufw app list

Available applications:
Nginx Full
Nginx HTTP
Nginx HTTPS
OpenSSH

To open the ports that a profile covers, pass its name to allow:

sudo ufw allow 'Nginx Full'

Quote profile names that contain spaces. To see what ports a profile includes, use:

sudo ufw app info 'Nginx Full'

Dry Run #

Before you commit to a change, you can preview the iptables rules ufw would add with --dry-run:

sudo ufw --dry-run allow 8080/tcp

No rule is created. The output shows the exact lines ufw would write, which is useful when you are writing rules over SSH and want to double-check them first.

Logging #

ufw can log packets that match rules, which helps when troubleshooting. The log level can be adjusted:

sudo ufw logging on
sudo ufw logging medium

Valid levels are off, low, medium, high, and full. ufw logs through the kernel log facility, so the exact destination depends on your system logging setup. On many Ubuntu systems with rsyslog, you will see entries in /var/log/ufw.log, and you can often inspect them with journalctl as well.

Reset the Firewall #

To clear every rule and set ufw back to its fresh state, run:

sudo ufw reset

IPv6 Support #

On most modern systems, ufw can manage IPv6 rules as well as IPv4 rules. Check the setting in /etc/default/ufw:

IPV6=yes

When IPV6=yes, generic rules such as sudo ufw allow 22/tcp are created for both IPv4 and IPv6. Rules that include an explicit address stay specific to that address family. In the status output, the IPv6 rules appear with (v6) next to them.

Quick Reference #

For a printable quick reference, see the ufw cheatsheet .

Troubleshooting #

ufw: command not found
Install the ufw package with sudo apt install ufw on Ubuntu or Debian. On Fedora, RHEL, and derivatives, firewalld is the default and ufw is rarely used.

Locked out after enabling the firewall over SSH
The default deny policy blocked your SSH session. You will need console access to the server. Once in, run sudo ufw allow ssh and sudo ufw reload to restore access. The usual safeguard is to allow SSH before the first enable.

Rule added but traffic still blocked
Confirm the rule is in the right direction (inbound vs outbound) and on the right interface. Check with sudo ufw status verbose. If Docker is running, it writes its own iptables rules that can bypass ufw.

Changes do not take effect
After manual edits to /etc/ufw/ files, reload the firewall with sudo ufw reload. Commands issued through ufw apply immediately and do not need a reload.

FAQ #

Is ufw the same as iptables?
No. ufw is a front end that generates iptables (or nftables) rules for you. The kernel still enforces the rules through its packet filter, but you do not need to edit the raw tables yourself.

Does ufw start automatically after reboot?
Yes, once you run sudo ufw enable, the service is registered with systemd and starts on boot. You can confirm with systemctl status ufw.

How do I allow a port for a single IP address?
Use the from and to any port form: sudo ufw allow from 203.0.113.25 to any port 22. This keeps the port closed to the rest of the internet and only opens it for that one address.

What is the difference between deny and reject?
deny drops the packet without any reply. reject sends an ICMP message back to the sender telling them the connection was refused. Reject is slightly friendlier to well-behaved clients but makes the server more visible to scans.

How do I undo everything and start over?
Run sudo ufw reset. It disables the firewall and removes every rule. Remember to re-add the SSH rule before re-enabling, especially on a remote server.

Conclusion #

ufw keeps firewall management readable: allow what you need, deny what you do not, and lean on the default policies to cover the rest. If you want step-by-step instructions for setting it up on a new server, see how to set up a firewall with UFW on Ubuntu 24.04 .

When a website does not load or email stops arriving, the first thing to check is whether the domain resolves to the correct address. The nslookup command is a quick way to query DNS servers and inspect the records behind a domain name.

nslookup ships with most Linux distributions and works on macOS and Windows as well. It supports both one-off queries from the command line and an interactive mode for running multiple lookups in a row.

This guide explains how to use nslookup with practical examples covering record types, reverse lookups, and troubleshooting.

Syntax #

nslookup [OPTIONS] [NAME] [SERVER]

• NAME — The domain name or IP address to look up.
• SERVER — The DNS server to query. If omitted, nslookup uses the server configured in /etc/resolv.conf.
• OPTIONS — Query options such as -type=MX or -debug.

When called without arguments, nslookup starts in interactive mode.

Installing nslookup #

On most distributions nslookup is already installed. To check, run:

nslookup -version

If the command is not found, install it using your distribution’s package manager.

Install nslookup on Ubuntu, Debian, and Derivatives #

sudo apt update && sudo apt install dnsutils

Install nslookup on Fedora, RHEL, and Derivatives #

sudo dnf install bind-utils

Install nslookup on Arch Linux #

sudo pacman -S bind

The nslookup command is bundled with the same packages that provide dig .

Look Up a Domain Name #

The simplest use is passing a domain name as an argument:

nslookup linux.org

Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: linux.org
Address: 104.26.14.72
Name: linux.org
Address: 104.26.15.72
Name: linux.org
Address: 172.67.73.26

The first two lines show the DNS server that answered the query. Everything under “Non-authoritative answer” is the actual result. In this case, linux.org resolves to three IPv4 addresses.

“Non-authoritative” means the answer came from a resolver’s cache rather than directly from the domain’s authoritative name server.

Query a Specific DNS Server #

By default, nslookup queries the resolver configured in /etc/resolv.conf. To query a different server, add it as the last argument.

For example, to query Google’s public DNS:

nslookup linux.org 8.8.8.8

Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: linux.org
Address: 104.26.14.72
Name: linux.org
Address: 104.26.15.72
Name: linux.org
Address: 172.67.73.26

This is useful when you want to compare results across different resolvers or verify whether a DNS change has propagated to public servers.

Query Record Types #

By default, nslookup returns A (IPv4 address) records. Use the -type option to query other record types.

MX Records (Mail Servers) #

MX records identify the mail servers responsible for receiving email for a domain:

nslookup -type=mx google.com

Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
google.com mail exchanger = 10 smtp.google.com.

The number before the mail server hostname is the priority. A lower number means higher priority.

NS Records (Name Servers) #

NS records show which name servers are authoritative for a domain:

nslookup -type=ns google.com

Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
google.com nameserver = ns1.google.com.
google.com nameserver = ns2.google.com.
google.com nameserver = ns3.google.com.
google.com nameserver = ns4.google.com.

TXT Records #

TXT records store arbitrary text data, commonly used for SPF, DKIM, and domain ownership verification:

nslookup -type=txt google.com

Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
google.com text = "v=spf1 include:_spf.google.com ~all"
google.com text = "facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95"
google.com text = "docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e"

The output may include many entries. The example above shows a subset of the TXT records returned for google.com.

AAAA Records (IPv6) #

AAAA records return the IPv6 address of a domain:

nslookup -type=aaaa google.com

Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: google.com
Address: 2a00:1450:4017:818::200e

SOA Record (Start of Authority) #

The SOA record contains administrative information about the domain, including the primary name server, the responsible email address, and timing parameters for zone transfers:

nslookup -type=soa google.com

Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
google.com
origin = ns1.google.com
mail addr = dns-admin.google.com
serial = 897592583
refresh = 900
retry = 900
expire = 1800
minimum = 60

The serial number increments each time the zone is updated. DNS secondaries use it to decide whether they need a zone transfer.

CNAME Records #

CNAME records point one domain name to another:

nslookup -type=cname www.github.com

If a CNAME record exists, the output shows the canonical name the alias points to. If the domain does not have a CNAME record, nslookup returns No answer.

Run an ANY Query #

To ask the DNS server for an ANY response, use -type=any:

nslookup -type=any google.com

ANY queries do not reliably return every record type for a domain. Many DNS servers return only a subset of records or refuse the query entirely.

Reverse DNS Lookup #

A reverse lookup finds the hostname associated with an IP address. Pass an IP address instead of a domain name:

nslookup 208.118.235.148

148.235.118.208.in-addr.arpa name = ip-208-118-235-148.twdx.net.

Reverse lookups query PTR records. They are useful for verifying that an IP address maps back to the expected hostname, which matters for mail server configuration and security checks.

Interactive Mode #

Running nslookup without arguments starts an interactive session where you can run multiple queries without retyping the command:

nslookup

>

At the > prompt, type a domain name to look it up:

> linux.org
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: linux.org
Address: 104.26.14.72
Name: linux.org
Address: 104.26.15.72

You can change query settings during the session with the set command. For example, to switch to MX record lookups and then query a domain:

> set type=mx
> google.com
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
google.com mail exchanger = 10 smtp.google.com.

To change the DNS server:

> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53

Type exit to leave interactive mode.

Interactive mode is convenient when you need to test several domains or record types in a row without running separate commands each time.

Debugging DNS Issues #

The -debug option shows the full query and response details, including TTL values and additional sections that nslookup normally hides:

nslookup -debug linux.org

The debug output is verbose, but it is helpful when you need to see TTL values, check whether answers are authoritative, or trace unexpected behavior.

nslookup vs dig #

Both nslookup and dig query DNS servers, but they differ in output and capabilities:

• nslookup produces simpler, more readable output. It also has an interactive mode that is convenient for quick checks.
• dig provides detailed, structured output with sections (QUESTION, ANSWER, AUTHORITY, ADDITIONAL) and supports advanced options like +trace for tracing the full resolution path and +dnssec for verifying DNSSEC signatures.

For quick lookups and basic troubleshooting, nslookup is often faster to type and read. For in-depth DNS debugging, dig gives you more control and detail.

Troubleshooting #

nslookup returns NXDOMAIN
The domain does not exist or is misspelled. Verify the domain name and check that it is registered.

nslookup returns SERVFAIL
The DNS server could not process the query. Try a different resolver to isolate the problem:

nslookup linux.org 1.1.1.1

If public resolvers return the correct answer, the issue is with your configured resolver.

Connection timed out; no servers could be reached
This means nslookup could not contact the DNS server. Check your network connection and verify that /etc/resolv.conf contains a reachable name server. A firewall may also be blocking outbound DNS traffic on port 53.

Non-authoritative answer appears on every query
This is normal. It means the answer came from a resolver’s cache, not directly from the domain’s authoritative server. The result is still valid.

Quick Reference #

For a printable quick reference, see the nslookup cheatsheet .

FAQ #

Can I use nslookup to check DNS propagation?
Yes. Query the same domain against several public DNS servers and compare the results. For example, run nslookup example.com 8.8.8.8, nslookup example.com 1.1.1.1, and nslookup example.com 9.9.9.9. If the answers differ, the change has not fully propagated.

Is nslookup deprecated?
The ISC (the organization behind BIND) once marked nslookup as deprecated in favor of dig, but later reversed that decision. nslookup is actively maintained and included in current BIND releases. It remains a practical tool for quick DNS lookups.

What does “Non-authoritative answer” mean?
It means the response came from a caching resolver, not from one of the domain’s authoritative name servers. The data is still accurate, but it may be slightly behind if a DNS change was made very recently and the cache has not expired yet.

Conclusion #

The nslookup command is a quick way to query DNS records from the command line. Use -type to look up MX, NS, TXT, AAAA, and other record types, and pass a server argument to test against a specific resolver. For deeper DNS debugging, pair it with dig .

If you are setting up a new Linux server, Debian and Ubuntu are usually the two options that come up first. Both are mature, well-supported, and used across everything from small VPS deployments to large production environments. They also share the same package format and package manager, so the day-to-day administration feels familiar on both.

The decision usually comes down to tradeoffs: Debian gives you a leaner and more conservative base, while Ubuntu gives you newer defaults, a broader support ecosystem, and easier onboarding. This guide shows where those differences matter in practice.

Shared Foundation #

Ubuntu is built on top of Debian. Canonical (the company behind Ubuntu) takes a snapshot of Debian’s unstable branch every six months, applies its own patches and defaults, and publishes a new Ubuntu release.

Because of this shared lineage, the two distributions have a lot in common:

• Both use apt and dpkg for package management.
• Both use systemd as the init system.
• Both use .deb packages, and many third-party vendors ship a single .deb that works on either distribution.
• Configuration file locations, service management commands, and filesystem layout follow the same conventions.

If you already know one, you can work comfortably on the other with very little adjustment.

Release Cycle and Support #

The biggest practical difference between Debian and Ubuntu is how often they release and how long each release is supported.

Debian does not follow a fixed release schedule. A new stable version ships roughly every two years, but only when the release team considers it ready. Each stable release receives approximately three years of full security support from the Debian Security Team, followed by about two more years of extended support through the Debian LTS project. Debian 13 (Trixie), released in August 2025, is the current stable version as of this writing. Debian 12 (Bookworm), released in June 2023, is now oldstable.

Ubuntu follows a predictable time-based schedule. A new version ships every six months (April and October), and every two years the April release is designated a Long-Term Support (LTS) version. LTS releases receive five years of free security updates, extendable to ten years through Ubuntu Pro (free for up to five machines for personal use). Ubuntu 24.04 LTS (Noble Numbat) is the current LTS release.

If you want a release calendar you can plan around years in advance, Ubuntu is easier to work with. If you prefer a slower release model that puts stability first, Debian is usually the better choice.

Package Freshness vs Stability #

Debian Stable freezes all package versions at release time. Once Bookworm shipped, its packages only receive security patches and critical bug fixes, never feature updates. This means you will not encounter unexpected behavior changes after a routine apt upgrade, but it also means you may be running older versions of languages, databases, or runtimes for the life of the release.

Ubuntu LTS takes a similar approach to stability, but because it pulls from a more recent Debian snapshot and applies its own patches, LTS packages tend to be slightly newer at release time. Ubuntu also offers PPAs (Personal Package Archives) as an official mechanism for installing newer software outside the main repository, though mixing PPAs with production servers carries its own risks.

Both distributions offer backports repositories for users who need specific newer packages without upgrading the entire system.

For server workloads where you install most software through containers or version managers (for example, nvm for Node.js or pyenv for Python), base package age matters less. The distribution becomes a stable foundation, and you manage application-level versions separately.

Default Installation and Setup #

Ubuntu Server ships with a guided installer (Subiquity) that walks you through disk layout, networking, user creation, and optional snap-based packages like Docker. It installs a small but functional set of tools by default and can import your SSH keys from GitHub or Launchpad during setup.

Debian’s installer is more traditional. It offers the same configuration options, but the interface is text-based and expects you to make more decisions yourself. The resulting system is leaner; Debian installs very little beyond the base system unless you explicitly select additional task groups during installation.

If you provision servers with tools like Ansible, Terraform, or cloud-init, the installer matters less because you will not spend much time in it after the first boot. It matters more for quick manual deployments and local VMs, where Ubuntu usually gets you to a usable system faster.

Commercial Support and Cloud Ecosystem #

Canonical offers paid support contracts, compliance certifications (FIPS, CIS benchmarks), and a managed services tier for Ubuntu. Ubuntu Pro extends security patching beyond the main repository and adds kernel livepatch for rebootless security updates. That matters most for teams with uptime targets, compliance requirements, or formal support needs.

Debian is entirely community-driven. There is no single company behind it, and there is no commercial support offering from the project itself. Third-party consultancies provide Debian support, but the ecosystem around it is smaller.

In the cloud, Ubuntu has a strong lead in first-party image availability. Every major provider (AWS, Google Cloud, Azure, DigitalOcean, Hetzner) offers official Ubuntu images, and many default to Ubuntu when launching a new instance. Debian images are also available on all major platforms, but Ubuntu tends to receive new platform features and optimized images first.

For container base images, both are widely used. Debian slim images are a popular choice for minimal Docker containers, while Ubuntu images are common when teams want closer parity between their server OS and their container environment.

Security #

Both distributions have strong security track records. The Debian Security Team and the Ubuntu Security Team publish advisories and patches regularly, and both maintain clear processes for reporting and fixing vulnerabilities.

The key difference is scope. Ubuntu LTS includes five years of standard security maintenance for packages in the Main repository. Ubuntu Pro extends coverage to Main and Universe, effectively the full Ubuntu archive. Debian’s security team focuses on the main repository, and Debian’s LTS team covers only a subset of packages during the extended support period.

For kernel security, Ubuntu offers kernel livepatch through Ubuntu Pro, which applies critical kernel fixes without a reboot. Debian does not have an equivalent service built into the project, though third-party solutions exist.

In practice, both distributions are secure when properly maintained. The difference is in how much of the maintenance is handled for you and for how long.

When to Choose Debian #

Choose Debian when you want:

• Maximum stability with few surprises after upgrades. Debian Stable is one of the most conservative general-purpose distributions available.
• A minimal base system that you build up yourself. Debian installs very little by default, which keeps the system lean and gives you tighter control over what runs on the server.
• No vendor dependency. Debian is maintained by a community of volunteers and governed by a social contract. There is no single company setting the direction of the project.
• A lightweight container base. Debian slim images are a common choice when image size matters.

Debian is often the better fit for long-running infrastructure, self-managed servers, and setups where predictability matters more than convenience.

When to Choose Ubuntu #

Choose Ubuntu when you want:

• Faster time to a working server. The installer and default configuration get you to a usable system quickly, especially on cloud platforms where Ubuntu images are often the default.
• Longer official support. Five years of free LTS support (ten with Ubuntu Pro) gives you a wider upgrade window than Debian’s default support period.
• Commercial backing. If your organization requires vendor support contracts, compliance certifications, or managed services, Canonical provides them.
• Broader documentation and community. Ubuntu’s larger user base means you will usually find more tutorials, examples, and third-party guides written for it.
• Cloud-heavy workflows. First-party cloud images and strong cloud-init support make Ubuntu an easy default for many hosted deployments.

Ubuntu is often the easier choice for cloud deployments, teams that need commercial support, and environments where onboarding speed matters.

Side-by-Side Summary #

FAQ #

Can I migrate a server from Ubuntu to Debian or vice versa?
It is technically possible but not straightforward. The distributions share the same package format, but they differ in package versions, configuration defaults, and init scripts. A clean reinstall with configuration management (Ansible, Puppet, or similar) is the safer path. Plan the migration as a new deployment rather than an in-place conversion.

Do Debian and Ubuntu run the same software?
For the most part, yes. Most common server software is available on both Debian and Ubuntu, whether through the official repositories, vendor-provided .deb packages, containers, or upstream binaries. That said, package versions, repository availability, and vendor support can differ between the two distributions and between releases.

Which is better for Docker and containers?
Both work well as Docker hosts. Installing Docker follows nearly the same steps on either distribution. For base images inside containers, Debian slim images are slightly smaller, while Ubuntu images offer closer parity with Ubuntu-based host systems. The difference is marginal for most workloads.

Which is more secure?
Neither is inherently more secure than the other. Both have dedicated security teams and fast patch turnaround. Ubuntu Pro extends patching to a wider package set and adds kernel livepatch, which can matter in environments with strict uptime or compliance requirements. On a properly maintained server, both are equally secure.

Conclusion #

Debian and Ubuntu are close enough that you can run the same kinds of workloads on either one. If you want the more conservative and self-managed option, pick Debian. If you want faster onboarding, broader vendor support, and a smoother cloud path, pick Ubuntu.

When you need to run a program with a different set of variables, test a script in a clean environment, or write a shebang line that works across systems, the env command is the right tool. It prints the current environment, sets or removes variables for a single command, and can even start a process with no inherited variables at all.

This guide covers how to use the env command with practical examples for everyday tasks.

env Syntax #

env [OPTIONS] [NAME=VALUE]... [COMMAND [ARGS]]

When called without arguments, env prints every environment variable in the current session, one per line. When followed by NAME=VALUE pairs and a command, it runs that command with the specified variables added or changed without affecting the current shell.

Print All Environment Variables #

The simplest use of env is printing the full environment:

env

SHELL=/bin/bash
USER=john
HOME=/home/john
LANG=en_US.UTF-8
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
TERM=xterm-256color
XDG_SESSION_TYPE=tty
EDITOR=vim

Each line is a KEY=value pair. This is identical to what printenv shows with no arguments. The difference between the two commands becomes clear when you start passing options: printenv is designed for inspecting variables, while env is designed for modifying the environment before launching a program.

Print Variables with NUL Separator #

By default, env separates each variable with a newline character. If variable values contain newlines themselves, the output becomes ambiguous. The -0 (or --null) option ends each entry with a NUL byte instead:

env -0 | tr '\0' '\n' | head -5

This is useful when piping environment data into tools that expect NUL-delimited input, such as xargs with its -0 flag.

Run a Command with Modified Variables #

The most practical feature of env is launching a command with variables changed for that command only. Place NAME=VALUE pairs before the command:

env LANG=C sort unsorted.txt

This runs sort with LANG set to C, which forces byte-order sorting regardless of the system locale. The current shell’s LANG value stays unchanged after the command finishes.

You can set multiple variables at once:

env DB_HOST=localhost DB_PORT=5432 python3 app.py

The application sees DB_HOST and DB_PORT in its environment, but those variables do not persist in your shell session after the process exits.

Run a Command in a Clean Environment #

The -i (or --ignore-environment) option clears the entire inherited environment before running the command. Only the variables you explicitly set on the command line will be present:

env -i bash -c 'env'

PWD=/home/john
SHLVL=1
_=/usr/bin/env

The output shows almost nothing. The shell itself sets a few internal variables (PWD, SHLVL, _), but everything the parent shell normally passes along (PATH, HOME, LANG, USER) is gone.

This is useful for testing whether a script depends on variables it does not set itself. You can combine -i with explicit variables to create a minimal, controlled environment:

env -i HOME=/home/john PATH=/usr/bin:/bin bash -c 'echo $HOME; echo $PATH'

/home/john
/usr/bin:/bin

A bare - (hyphen) works as a shorthand for -i:

env - PATH=/usr/bin bash -c 'echo $PATH'

Unset a Variable for a Command #

The -u (or --unset) option removes a specific variable from the environment before running the command:

env -u EDITOR vim

This launches vim without the EDITOR variable in its environment. Other variables remain untouched. You can unset multiple variables by repeating -u:

env -u LANG -u LC_ALL python3 script.py

The difference from -i is that -u is surgical: it removes only the named variables and leaves everything else in place.

Change Directory Before Running a Command #

The -C (or --chdir) option changes the working directory before executing the command:

env -C /var/log cat syslog | head -3

This is equivalent to running cd /var/log && cat syslog, but without affecting the current shell’s working directory. It is a convenient way to run a command in another directory from within a script or one-liner.

Using env in Shebangs #

One of the most common uses of env is in shebang lines at the top of scripts:

#!/usr/bin/env bash
echo "Hello from Bash"

When the kernel encounters #!/usr/bin/env bash, it runs /usr/bin/env with bash as its argument. env then searches the PATH for the bash executable and runs it. This is more portable than hardcoding #!/bin/bash, because bash is not always located in /bin on every system (for example, on FreeBSD it is typically at /usr/local/bin/bash).

The same pattern works for other interpreters:

#!/usr/bin/env python3

#!/usr/bin/env node

On systems with GNU coreutils 8.30 or later, you can pass arguments to the interpreter using the -S (split string) option:

#!/usr/bin/env -S python3 -u

Without -S, the kernel treats python3 -u as a single argument. The -S option tells env to split the string into separate arguments before executing.

env Options #

• -i, --ignore-environment - Start with an empty environment
• -u NAME, --unset=NAME - Remove NAME from the environment
• -C DIR, --chdir=DIR - Change working directory to DIR before running the command
• -0, --null - End each output line with a NUL byte instead of a newline
• -S STRING, --split-string=STRING - Split STRING into separate arguments (useful in shebangs)
• -v, --debug - Print verbose information for each processing step
• --block-signal=SIG - Block delivery of the specified signal to the command
• --default-signal=SIG - Reset signal handling to the default for the command
• --ignore-signal=SIG - Set signal handling to ignore for the command

Quick Reference #

For a printable quick reference, see the env cheatsheet .

FAQ #

What is the difference between env and printenv?
Both commands print environment variables when called without arguments. The difference is in their purpose: printenv is a read-only inspection tool that can print individual variables by name (printenv HOME). env is designed to modify the environment and run commands. Use printenv when you need to check a value, and env when you need to change the environment for a process.

What is the difference between env and export?
export is a shell built-in that adds a variable to the current shell’s environment permanently (until the session ends or you unset it). env sets variables only for the duration of a single command and does not affect the current shell. If you need a variable to persist for all subsequent commands in your session, use export. If you need a variable set for one command only, use env or the shell’s VAR=value command syntax.

When should I use env -i?
Use env -i when you want to verify that a script or program works without relying on inherited environment variables. It is also useful in security-sensitive contexts where you want to prevent a child process from seeing variables like AWS_SECRET_ACCESS_KEY or database credentials that exist in the parent shell.

Why use #!/usr/bin/env bash instead of #!/bin/bash?
The env-based shebang is more portable. On most Linux distributions, bash lives at /bin/bash, but on other Unix systems (FreeBSD, macOS with Homebrew, NixOS) it may be installed elsewhere. Using #!/usr/bin/env bash searches the PATH for the interpreter, so the script works regardless of where bash is installed.

Conclusion #

The env command gives you fine-grained control over the environment a process sees without touching your current shell session. For a broader look at how environment and shell variables work in Linux, including persistent configuration and the PATH variable, see the guide on how to set and list environment variables .

When a server starts responding slowly or a desktop session feels sluggish, you need to figure out which process is consuming the most CPU or memory. The top command can do this, but its interface is minimal and navigation takes some getting used to. htop is an interactive process viewer that improves on top with color-coded meters, mouse support, and the ability to scroll, search, filter, and kill processes without leaving the viewer.

This guide explains how to install and use htop to monitor system resources and manage processes on Linux.

Installing htop #

htop is available in the default repositories of most Linux distributions but is not always pre-installed.

On Ubuntu, Debian, and Derivatives:

sudo apt install htop

On Fedora, RHEL, and Derivatives:

sudo dnf install htop

Verify the installation by checking the version:

htop --version

htop 3.4.1

htop Syntax #

htop [OPTIONS]

Running htop without arguments opens the interactive process viewer with default settings:

htop

Understanding the Interface #

The htop screen is divided into three areas: a header with system meters, a process list in the center, and a footer with function key shortcuts.

Header Area #

The top section shows system-wide resource usage at a glance:

• CPU bars: one bar per CPU core, color-coded by usage type. Green is normal user processes, red is kernel (system) activity, blue is low-priority (nice) processes, and cyan is virtualization overhead (steal time)
• Memory bar: shows used, buffered, and cached memory as a proportion of total RAM. Green is memory in use by applications, blue is buffers, and yellow is file cache
• Swap bar: shows swap usage. If this bar is consistently full, the system does not have enough physical memory for its workload
• Tasks: total number of processes and threads, with a count of how many are currently running
• Load average: the 1-minute, 5-minute, and 15-minute system load averages
• Uptime: how long the system has been running since the last boot

Process List #

Below the header, each row represents one process. The default columns are:

• PID - process ID
• USER - the owner of the process
• PRI - kernel scheduling priority
• NI - nice value (user-space priority, ranges from -20 to 19)
• VIRT - total virtual memory the process has allocated
• RES - resident memory, the portion of physical RAM the process is actually using
• SHR - shared memory, the portion of RES that is shared with other processes (such as shared libraries)
• S - process state (R running, S sleeping, D uninterruptible sleep, Z zombie, T stopped)
• CPU% - percentage of CPU time the process is using
• MEM% - percentage of physical memory the process is using
• TIME+ - total CPU time consumed since the process started
• Command - the full command line that launched the process

Function Keys #

The bottom bar shows the available actions:

• F1 - open the help screen
• F2 - open the setup menu to customize meters and columns
• F3 - search for a process by name
• F4 - filter the process list to show only matching entries
• F5 - toggle tree view
• F6 - choose a column to sort by
• F7 - decrease the nice value (higher priority) of the selected process
• F8 - increase the nice value (lower priority) of the selected process
• F9 - send a signal to the selected process
• F10 - quit htop

Sorting Processes #

By default, htop sorts processes by CPU usage, so the heaviest processes float to the top. To change the sort column, press F6 and select a column from the list using the arrow keys.

For quick sorting without opening the menu, use these shortcut keys:

• P - sort by CPU%
• M - sort by MEM%
• T - sort by TIME+

Press the same key again to reverse the sort order. This is useful when you want to find the least active processes or the ones that started most recently.

You can also set the initial sort column from the command line:

htop -s PERCENT_MEM

This starts htop with the process list sorted by memory usage, which is handy when you are investigating high memory consumption on a server.

Searching for a Process #

Press F3 (or /) to open the search bar at the bottom of the screen. Type part of the process name and htop will highlight the first matching entry in the process list. Press F3 again to jump to the next match.

The search is incremental, so the highlight updates as you type each character. Press Esc to close the search bar and return to normal navigation.

Filtering Processes #

Press F4 to activate the filter. Unlike search, which jumps between matches, filtering hides all processes that do not match the text you type. Only matching entries remain visible in the list.

This is especially useful on busy systems with hundreds of running processes. For example, typing postgres after pressing F4 reduces the list to only PostgreSQL worker processes and the postmaster, making it much easier to see their combined resource usage.

Press Esc to clear the filter and restore the full process list.

Tree View #

Press F5 to toggle tree view. In this mode, htop groups child processes under their parent and displays the process hierarchy as an indented tree. This makes it straightforward to see which processes were spawned by a service manager, a shell session, or a container runtime.

To start htop in tree view directly from the command line:

htop -t

Tree view combines well with filtering. Press F4, type a service name, and the tree shows only that service and its child processes. For a dedicated look at process hierarchies outside of htop, see the pstree command .

Killing a Process #

To stop a process from within htop, use the arrow keys to highlight it (or search with F3), then press F9. This opens a signal selection menu on the left side of the screen.

The most commonly used signals are:

• 15 SIGTERM - asks the process to shut down gracefully. This is the default and the safest first choice
• 9 SIGKILL - forces the process to terminate immediately. Use this only when SIGTERM does not work, because the process gets no chance to clean up
• 2 SIGINT - the same signal sent by pressing Ctrl+C in a terminal
• 1 SIGHUP - often used to tell a daemon to reload its configuration without restarting

Select the signal with the arrow keys and press Enter to send it. For more detail on process signals and how to send them from the command line, see the kill command guide .

You can also tag multiple processes with Space and then press F9 to send a signal to all of them at once. Press U to untag all processes when you are done.

Changing Process Priority #

You can adjust the scheduling priority (nice value) of a process directly from htop. Select the process and press:

• F7 - decrease the nice value (give the process higher priority)
• F8 - increase the nice value (give the process lower priority)

Nice values range from -20 (highest priority) to 19 (lowest priority). Only root can set negative nice values, so you will need to run htop with sudo to raise a process above normal priority.

This is useful when a background task like a large compilation is consuming too much CPU and you want to lower its priority so that interactive services remain responsive.

Showing Only One User’s Processes #

To limit the process list to a single user, start htop with the -u option:

htop -u www-data

This shows only processes owned by www-data, which is useful when you are debugging a web server or an application service and do not want system processes cluttering the view.

Monitoring Specific Processes #

To watch a known set of processes by their PIDs, use the -p option:

htop -p 1234,5678

The display is restricted to those two processes, but the header meters still show system-wide resource usage. This gives you a focused view while keeping overall load visible at the top.

Customizing the Display #

Press F2 to open the setup screen. From here you can:

• Rearrange the header meters (move CPU bars, swap positions, switch between bar, text, graph, or LED display styles)
• Add or remove columns in the process list
• Change the color scheme
• Toggle display options like showing kernel threads or custom thread names

Changes are saved to ~/.config/htop/htoprc and persist across sessions.

Command-Line Options #

• -d N - set the update interval to N tenths of a second. For example, -d 20 updates every 2 seconds instead of the default 1.5 seconds
• -u USER - show only processes belonging to USER
• -p PID[,PID...] - show only the specified process IDs
• -t - start in tree view
• -s COLUMN - sort by the given column name (use names like PERCENT_CPU, PERCENT_MEM, TIME)
• -C - use monochrome mode (no colors), useful on terminals with limited color support
• -H - highlight new and old processes

Quick Reference #

For a printable quick reference, see the htop cheatsheet .

Troubleshooting #

htop: command not found
htop is not installed by default on every distribution. Install it with your package manager: sudo apt install htop on Debian-based systems or sudo dnf install htop on Fedora and RHEL.

Cannot change process priority (permission denied)
Setting a nice value below 0 requires root privileges. Run htop with sudo to adjust priority for processes owned by other users or to set negative nice values.

CPU bars show unexpected colors
Each color represents a different type of CPU usage. Green is normal user processes, red is kernel activity, blue is low-priority (nice) processes, and cyan is virtualization steal time. Press F1 inside htop to see the full color legend for your version.

Memory bar looks full but the system is responsive
Linux uses free memory for disk cache and buffers. The memory bar in htop distinguishes between application memory (green), buffers (blue), and cache (yellow). Cached memory is released to applications when they need it, so a full-looking bar does not mean the system is out of memory.

Processes appear and disappear quickly
Short-lived processes can start and exit between screen refreshes. Lower the update interval with -d 5 (half a second) to catch fast processes. Keep in mind that a very short interval increases the CPU usage of htop itself.

FAQ #

What is the difference between htop and top?
Both show running processes and system metrics in real time. htop adds color-coded CPU and memory meters, mouse support, horizontal and vertical scrolling, built-in search and filtering, and the ability to kill or renice processes without typing a PID. The top command is pre-installed on virtually every Linux system, while htop may need to be installed separately.

Does htop use more resources than top?
Slightly. htop reads additional process details from /proc, so it uses a bit more CPU and memory than top. On modern hardware the difference is negligible, even on systems with thousands of processes.

What do VIRT, RES, and SHR mean?
VIRT is the total virtual memory the process has mapped, including memory it has allocated but may not be using yet. RES (Resident) is the portion actually held in physical RAM. SHR (Shared) is the subset of RES that is shared with other processes, such as shared libraries loaded by multiple programs.

How do I save my htop configuration?
Press F2 to open the setup screen, make your changes, and press F10 to exit. htop saves the configuration automatically to ~/.config/htop/htoprc.

Can I run htop over SSH?
Yes. htop works in any terminal emulator, including SSH sessions. If you are monitoring a remote server over a long session, consider running htop inside screen or tmux so the session persists if the connection drops.

Conclusion #

htop gives you a clear, interactive view of what is running on your system and the resources each process is consuming. For related tools, see the ps command for snapshot process listings, kill for sending signals from the command line, and pstree for visualizing the process hierarchy.

Debian 13, codenamed “Trixie”, was released on August 9, 2025. It ships with Linux kernel 6.12 LTS, GNOME 48, KDE Plasma 6, GCC 14.2, Python 3.13, and over 14,100 new packages. Debian 13 will receive full support until August 2028, with Long Term Support (LTS) extending to June 2030.

This guide walks you through upgrading Debian 12 “Bookworm” to Debian 13 “Trixie” via the command line.

Prerequisites #

You need to be logged in as root or a user with sudo privileges to perform the upgrade. You can only upgrade to Debian 13 from Debian 12. If you are running an older Debian version, upgrade to Debian 12 first.

Back Up Your Data #

Before starting a major version upgrade, make sure you have a complete backup of your data. If you are running Debian on a virtual machine, take a full system snapshot so you can restore quickly if anything goes wrong.

Update Currently Installed Packages #

Before changing the source repositories, bring your existing Debian 12 system fully up to date.

Check whether any packages are marked as held back, which could interfere with the upgrade:

sudo apt-mark showhold

If there are held packages, either unhold them with sudo apt-mark unhold package_name or make sure they will not cause issues during the upgrade.

Refresh the package index and upgrade all installed packages:

sudo apt update
sudo apt upgrade

Perform a major version upgrade of the installed packages:

sudo apt full-upgrade

Remove automatically installed dependencies that are no longer needed:

sudo apt autoremove

Update the Sources List #

The upgrade works by pointing your APT repositories from bookworm to trixie.

Open /etc/apt/sources.list with your text editor and replace every instance of bookworm with trixie. You can also do this with a single sed command:

sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

If you have third-party repository files under /etc/apt/sources.list.d/, disable them before the upgrade. They may not be compatible with Debian 13 and can cause errors.

After editing, your /etc/apt/sources.list should look similar to this:

deb https://deb.debian.org/debian/ trixie main contrib non-free non-free-firmware
# deb-src https://deb.debian.org/debian/ trixie main contrib non-free non-free-firmware

deb https://deb.debian.org/debian/ trixie-updates main contrib non-free non-free-firmware
# deb-src https://deb.debian.org/debian/ trixie-updates main contrib non-free non-free-firmware

deb https://security.debian.org/debian-security/ trixie-security main contrib non-free non-free-firmware
# deb-src https://security.debian.org/debian-security/ trixie-security main contrib non-free non-free-firmware

You can find a full list of Debian mirror addresses on the official mirrors page .

Upgrade to Debian 13 Trixie #

Set the terminal output to English to make it easier to follow any prompts:

export LC_ALL=C

Update the package index with the new Trixie repositories:

sudo apt update

If you see errors related to third-party repositories, fix or disable them before continuing.

Run the initial upgrade. This upgrades packages that do not require installing or removing other packages:

sudo apt upgrade --without-new-pkgs

During the upgrade, you may be asked whether services should be automatically restarted:

Restart services during package upgrades without asking?

You may also see prompts about configuration files. If you have not made custom changes to a file, it is safe to accept the package maintainer’s version. If you have made changes, keep the current version to avoid losing your customizations.

Once the initial upgrade finishes, run the full upgrade. This installs new packages, removes obsolete ones, and resolves any remaining dependency changes between Debian 12 and 13:

sudo apt full-upgrade

The upgrade may take some time depending on the number of packages, your hardware, and your internet speed.

When it completes, clean up packages that are no longer needed:

sudo apt autoremove

Reboot your system to load the new kernel:

sudo systemctl reboot

Verify the Upgrade #

After the system boots, log in and check the Debian version :

lsb_release -a