Software Installation and Management

Managing Packages

Packages can run scripts at various points during the installation, so they can do much more than just transfer files.

• add new users and groups
• run sanity checks
• customize settings according to the environment

Package management systems

• low-level: install, uninstall and query packages
• top-level: find and download packages, analyze package dependencies and upgrade all packages on the system

Low-level package management

rpm

RHEL package manager

rpm -i  # install
rpm -U  # upgrade
rpm -e  # erase
rpm -qa # query all install on the system

dpkg

dpkg - Debian package manager

dpkg --install ./xyz.deb # install a package manually
dpkg -l xyz              # verify install
dpkg --remove
dpkg -l                  # list all packages installed
dpkg -l | grep -i python # search installed packages
dpkg -L bat | grep bin   # find where a package is installed

High-level package management

When you run apt upgrade, what you actually get depends on following variables:

• Repository the server your package manager points to
• Release a snapshot of packages; slow-moving (RHEL) or fast-moving (betas)
• Component a subset of a release; official vs community, or free vs proprietary
• Architecture hardware target (e.g. x86_64)
• Package individual installable unit, versioned independently

Repository configuration

Apt stores a list of repositories: /etc/apt/sources.list and any file with the suffix .list in /etc/apt/sources.list.
These files tell APT where to get its packages each line specifies the following:

• type of package deb or deb-src
• a url that points to a file, http server or ftp server to pull packages
• a “distribution” (release name)
• a potential list of categories of packages

After updating the packages in the list ensure you run apt-get update

Ubuntu repo docs

#/etc/apt/sources.list
# repository type → server → folder → subfolder
deb http://security.debian.org/debian-security trixie-security main

# Breakbreak
deb                                        # type = .deb (deb-src provides source packages)
http://security.debian.org/debian-security # url of repo
trixie-security                            # distribution which section/release to look into
main                                       # component/catergory (non-free, contrib)

End to end full flow of looking up a package:

• search for a package
• apt checks /etc/apt/sources.list
• loops over each line:
  • look for the repository type
  • on this server
  • under this release folder
  • then inside this component subfolder

TODO: Creation of a local repository mirror

APT

APT - advanced package tool

Commands

The man pages for apt are terse and clear, use them.

apt update # download package info from all configured sources, other commands use this data (upgrade or search)
apt upgrade

apt list --upgradable        # check which packages can be updated
apt list --installed | vim - # all installed packages
apt search ssh               # full text search

apt install
apt reinstall # useful for corrupt packages, reinstall binaries but keeps config
apt remove # removes all packaged data but leaves small modified user config files
apt purge  # same as remove but gets rid of the leftovers

apt vs apt-get/apt-cache

Pithy

apt supplanted apt-get and apt-cache, it exactly the same functionality with improvements and collates their functionality into one binary.

• apt 2014 is a newer version of apt-get 1998
• apt has better dependency resolution
• apt upgrade removes old versions of installed or upgradable packages when are no longer needed, apt-get upgrade does not`
• apt has a better ui when installing (progress bar)

APT Automation

Setup with a cron job to handle automatic updates, if you do this on a bunch of different machines it’s a good idea to randomize the time they pull

apt update && apt upgrade -y

TODO: look into the diff between apt-get and apt TODO: create a package using fpm

Apt’s daemon for unattended upgrades

systemctl status unattended-upgrades                     # check if it's running
vim /etc/apt/apt.conf.d/20auto-upgrades                  # view config contains rules for which packages 
vim /var/log/unattended-upgrades/unattended-upgrades.log # view log

APT Package Signing (/etc/apt/keyring)

Pithy

/etc/apt/keyring stores pgp public keys to ensure packages installed via a mirror are signed by the publisher. apt just reads the keys when it needs to verify a package from a source.

Example for Docker’s apt source:

# /etc/apt/sources.list.d/docker.sources 
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: trixie
Components: stable
Architectures: amd64
Signed-By: /etc/apt/keyrings/docker.asc
# Any package installed from this source is then verified with this key 'docker.asc'

# /etc/apt/keyrings/docker.asc
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBFit2ioBEADhWpZ8/w
.........[cont].......
-----END PGP PUBLIC KEY BLOCK-----

Note

keyring is analogy for a physical ring of keys, it just means the folder contains more than one key

apt is stuck with pgp (gnu privacy guard) (the implementation of the pgp (pretty good privacy) spec). So keys in this folder will be .asc (ASCII) or .gpg binary encoded.

TODO - What exactly happens on apt update

Ubuntu docs are excellent on this: https://ubuntu.com/server/docs/how-to/software/automatic-updates/#where-to-pick-updates-from