From 08bae91acc07695021d51f78946363d41fcef62c Mon Sep 17 00:00:00 2001 From: Jules Date: Thu, 14 May 2026 17:00:58 -0400 Subject: [PATCH] Improve Chapter 01 software installation lesson --- .../1.10_ways_to_find_and_install_software.md | 326 +++++++++++++++--- 1 file changed, 285 insertions(+), 41 deletions(-) diff --git a/docs/lessons/01_where_to_start/1.10_ways_to_find_and_install_software.md b/docs/lessons/01_where_to_start/1.10_ways_to_find_and_install_software.md index 6aa95c4..503dde8 100644 --- a/docs/lessons/01_where_to_start/1.10_ways_to_find_and_install_software.md +++ b/docs/lessons/01_where_to_start/1.10_ways_to_find_and_install_software.md @@ -1,80 +1,324 @@ ## 1.10 Ways to Find and Install Software - +Installing software is one of the first Linux tasks that feels simple until it +goes wrong. The command may be short, but the decision behind it matters: where +did the package come from, what dependencies will it add, what service will it +start, and how will you prove the machine is better afterward? !!! abstract "What you will learn" - - Explain where **1.10 Ways to Find and Install Software** fits in day-to-day Linux operations. - - Use current Linux tooling to inspect, change, and verify the relevant system behavior. - - Connect the concept to a real operational scenario: a first-week junior admin onboarding into a small cloud team. - -!!! example "Field story" - Imagine a first-week junior admin onboarding into a small cloud team. Your job is not to memorize a command; it is to build a short evidence trail, choose a low-risk change, and prove whether the system improved. + - Explain the safest order for finding Linux software. + - Compare distribution repositories, upstream releases, vendor packages, + language package managers, and containers. + - Inspect a package before installing it. + - Verify and, when needed, remove software cleanly. !!! success "Operator principle" - Identify the OS, distribution, support window, and package source before changing anything. + Prefer the package source your operating system already trusts. Reach for + outside repositories only when you can explain the owner, update path, + rollback plan, and operational risk. -## Hands-on practice +## Start with the distribution -Run these on a disposable VM, container, or lab machine unless the lesson explicitly says otherwise. +Most Linux systems install software through a distribution package manager. +That package manager knows which repositories are enabled, which packages are +installed, which dependencies are required, and which files belong to each +package. -1. Inspect the current state with a read-only command related to this topic. -2. Save the command and output in a short lab note. -3. Make one reversible change or simulate the change in a sandbox. -4. Re-run the inspection and explain what changed. +Common families include: -## Check your understanding +- Debian and Ubuntu: `apt`, `apt-cache`, `dpkg`. +- Red Hat Enterprise Linux, CentOS Stream, Rocky Linux, AlmaLinux, and Fedora: + `dnf`, `rpm`. +- SUSE and openSUSE: `zypper`, `rpm`. +- Arch Linux: `pacman`. +- FreeBSD: `pkg`. + +On an unfamiliar system, identify the OS before choosing commands: + +```bash +cat /etc/os-release +``` + +Then use the native package manager first unless you have a specific reason not +to. + +## Search before installing + +Package names are not always obvious. Search the repositories before installing +anything. + +Debian and Ubuntu: + +```bash +apt search nginx +apt-cache search "web server" +``` -- What evidence would tell you that this system is healthy? -- What is the riskiest command in this lesson, and how would you make it safer? -- How would you explain section 1.10 to a teammate during an incident handoff? +Fedora and RHEL-family systems: +```bash +dnf search nginx +dnf list nginx +``` -A distinguishing feature of Linux is its vast, diverse pool of software applications. Finding and installing these applications is as central to Linux as a roadmap is to a journey. This sub-chapter will gently guide you through the process. 🗺️🐧 +FreeBSD: -### Understanding Linux Software Repositories +```bash +pkg search nginx +``` -Most Linux distributions maintain software repositories—online databases storing a plethora of software packages ready for download and installation. Think of repositories as your one-stop digital shops for finding and downloading applications. 🛒📦 +Search results are leads, not approval to install. Pick the package that +matches the service you actually intend to run. -You can access these repositories through "package managers". These work much like app stores, but with command-line interfaces. `apt` (Debian-based distros), `dnf` (Fedora), and `pacman` (Arch) are examples of package managers. They manage software installations, updates, and removals. 🧰💪 +## Inspect the candidate -### Installing Software +Before installation, inspect metadata when the package manager supports it. -The simplest way to install software is by using your distribution's package manager. For instance, if you're on a Debian-based system like Ubuntu, you can install a package using the `apt` command: +Debian and Ubuntu: ```bash -sudo apt install [package-name] +apt show nginx +apt-cache policy nginx ``` -Remember to replace `[package-name]` with the actual name of the software you want to install. 🔧💾 -The `apt` command retrieves the software from your distribution’s repository and installs it on your system. The `sudo` keyword is used because software installation requires administrator privileges. 🛡️🔑 +Fedora and RHEL-family systems: -### Finding Software +```bash +dnf info nginx +dnf repoquery --requires nginx +``` -On Linux, you can browse available software in your distribution's repositories: +FreeBSD: ```bash -apt-cache search [keyword] +pkg info nginx ``` -This command lists all packages that contain the `[keyword]` in their names or descriptions. 🕵️‍♂️🔍 -For example, if you're looking for a text editor, use the command `apt-cache search text editor` to produce a list of related applications. 📝🎯 +Look for: + +- Repository or vendor. +- Version. +- Architecture. +- Dependencies. +- Package size. +- Description. +- Homepage or project source. +- Whether the package is already installed. -### Uninstalling Software +If the package comes from an unexpected repository, pause and inspect the +enabled repositories before proceeding. -Uninstalling software on Linux is as simple as installing it. You can use the `apt` command like this: +## Install with a narrow change window + +On a lab machine, installing a package may be routine. On a production host, it +is a change. + +Debian and Ubuntu: ```bash -sudo apt remove [package-name] +sudo apt update +sudo apt install nginx ``` -This command uninstalls a package but leaves its configuration files intact. To remove these as well, you can use: + +Fedora and RHEL-family systems: ```bash -sudo apt purge [package-name] +sudo dnf install nginx ``` -Voilà! You've uninstalled the software and cleared its remnants—like a pro! 💪🗑️ ---- +FreeBSD: -Remember, each journey begins at a single spot. This is yours. Don't be daunted by Linux's vastness—embrace it! Linux’s power welcomes questions, rewards courage, and equips you with knowledge pivotal to the new-age digital world. Keep exploring, keep experimenting. Through this, you’ll learn Linux with ease. +```bash +sudo pkg install nginx +``` + +Before confirming an install on a real system, read the transaction summary. +Notice new packages, removed packages, upgraded packages, and service-related +post-install scripts. + +## Verify after installation + +Installation is not the same as success. Verify the result. + +Common checks: + +```bash +command -v nginx +nginx -v +systemctl status nginx --no-pager +systemctl is-enabled nginx +ss -ltnp +``` + +Not every package starts a service. Some install only libraries, command-line +tools, documentation, or development headers. Choose verification that matches +the package. + +For a command-line utility, run: + +```bash +command -v jq +jq --version +``` + +For a library, inspect the package contents: + +```bash +dpkg -L libssl3 +rpm -ql openssl-libs +``` + +## Remove software carefully + +Removing a package can remove dependencies or stop services. Inspect before +confirming. + +Debian and Ubuntu: + +```bash +sudo apt remove nginx +sudo apt purge nginx +sudo apt autoremove +``` + +`remove` keeps most configuration. `purge` removes package-managed +configuration files. `autoremove` removes dependencies that are no longer +needed, which can be helpful or dangerous depending on the host. + +Fedora and RHEL-family systems: + +```bash +sudo dnf remove nginx +``` + +FreeBSD: + +```bash +sudo pkg delete nginx +``` + +After removal, verify that the command, service, listener, and package record +match the intended state. + +## Outside package sources + +Sometimes the distribution repository is not enough. You may need a newer +version, a vendor-supported build, or a tool that is not packaged by the +distribution. + +Common alternatives: + +- Vendor repositories, such as Docker, HashiCorp, Google, Microsoft, or + PostgreSQL repositories. +- Upstream release archives, such as `.tar.gz` or binary release bundles. +- Language package managers, such as `pip`, `npm`, `gem`, `cargo`, or `go + install`. +- Container images. +- Flatpak, Snap, or AppImage for desktop applications. +- Source builds. + +Each alternative shifts trust and maintenance. Ask: + +- Who signs or publishes the package? +- How are updates delivered? +- Does it bypass the distribution security-update path? +- Does it install files under `/usr`, `/usr/local`, `/opt`, or a user home + directory? +- Does it create services, users, sockets, timers, or scheduled tasks? +- How do you uninstall or roll back it? + +For servers, a distribution package or vendor repository is usually easier to +operate than a manual binary copied into place without ownership metadata. + +## Language package managers + +Language package managers are useful for developer tooling and application +dependencies, but they are not a substitute for operating-system package +management. + +Avoid casually running global installs on shared servers: + +```bash +sudo pip install something +sudo npm install -g something +``` + +Prefer isolated environments when possible: + +- Python: virtual environments. +- Node.js: project-local dependencies. +- Ruby: Bundler-managed project dependencies. +- Go: pinned module versions. +- Rust: `cargo install` into a known user path for CLI tools. + +The goal is to keep application dependencies from silently replacing system +libraries or tools. + +## Containers as software delivery + +Containers can be a good way to run software without installing every +dependency on the host. They are still software from a source you must trust. + +Inspect: + +- Image publisher. +- Image tag. +- Digest, if pinning matters. +- Exposed ports. +- Mounted volumes. +- Required environment variables and secrets. +- Update and rollback process. + +Avoid treating `latest` as a stable version in production. Use explicit tags or +digests when repeatability matters. + +## Keep an install note + +For nontrivial installs, leave a short record: + +```text +Package: nginx +System: Ubuntu 24.04 +Source: Ubuntu noble-updates repository +Reason: reverse proxy for internal dashboard +Pre-checks: apt show nginx; apt-cache policy nginx +Installed with: sudo apt install nginx +Verification: nginx -v; systemctl status nginx; ss -ltnp +Rollback: sudo apt remove nginx; restore previous firewall rule set +Owner: platform team +Date: 2026-05-14 +``` + +This note gives the next operator a starting point. + +## Lab: install and verify a small tool + +Use a disposable VM, container, or lab machine. + +1. Identify the OS: + + ```bash + cat /etc/os-release + ``` + +2. Search for `jq` with the native package manager. +3. Inspect the candidate package metadata. +4. Install `jq`. +5. Verify the command path and version: + + ```bash + command -v jq + jq --version + ``` + +6. Record the package source, install command, and verification output. +7. Remove the package only if the lab machine does not need it afterward. + +## Check your understanding -Onward, to the next sub-chapter! 🚀🛠️ +- Why is the distribution repository usually the safest first source? +- What should you inspect before confirming a package transaction? +- What is the difference between removing and purging a package on + Debian-family systems? +- Why can global language-package installs be risky on shared servers? +- When might a container image be a better delivery path than a host package?