Blog

Chapter 6 – Security, Updating, and Package Management

  • Checking package versions
  • Checking the OS version
  • Checking for updates
  • Automating updates
  • Checking mailing lists and errata pages
  • Using snaps
  • Using Flatpak
  • Using Pip, RubyGems, and other package managers
  • Dependency hell (a quick word)
  • Compiling from sources
  • Adding additional repositories

1. Checking package versions

  • Check installed packages 
  • Get version number of packages

Install aptitude package manager:

# apt install aptitude

CentOS

  • CentOS and RedHat have two package managers 
  • RPM Package manager 
  • RPM does following things: select, query, verify, install

List all installed packages

# rpm -qa

List specific package by name

# rpm -q dmidecode
  • Output shows only package version

List specific package by name

# rpm -qi dmidecode
  • Output shows package details and information

Yellowdog Updater Modified (YUM)

  • Newer version of package manager.
  • Developed by Yellow Dog Linux
  • Generally used because handles automatic downloading and installing of packages

List all installed packages

# yum list installed

List specific package by name

# yum info dmidecode
  • DNF (Did not finish) is newest package manager that will go live in Red Hat and CentOS versions. 

Debian

  • Debian uses dpkg package manager to install and manage packages.
  • Other manager are apt and aptitude which make management more user friendly.

List all installed packages with dpkg

# dpkg-query -W
# dpkg-query -W --showformat=’${Package} - ${Version}\n’
  • To remove the TAB spacing

List all installed packages with apt

# apt list --installed
# aptitude search ~i --display-format ‘%p%v’

Use aptitude to navigate through package manager GUI

# aptitude

Under Security Updates (15) tab, we find the following information:

  • Two kernels installed (4.9.0-6 and 4.9.0-7)

List kernels with command line

# aptitude search ‘~i linux-image’ --display-format ‘%p%v’

How it works

  • In both cases we are querying the package database on our system.
  • RPM and YUM are both looking inside /var/lib/rpm in order to find out state of the system.
  • On Debian systems, package state is within /var/lib/dpkg.
  • Advisable to not mess with these folders.

2. Checking the OS version

  • List version of our OS
  • List kernel version

CentOS

Find OS release

# cat /etc/centos-release
# cat /etc/system-release
  • Symbolic link to centos-release file
  • Shows same output
# cat /etc/os-release
  • Detailed information 
# yum install redhat-lsb-core
  • Now, we can use # lsb_release command to see OS version
  • # lsb_release -s -d

Find kernel release

# dmesg | grep “Linux version”
# uname -a
# uname -r
# yum -q info installed kernel

Debian

Find OS release

# cat /etc/debian_version
# cat /etc/os-release
# dmesg | grep “Linux version”
# uname -r
# uname -a
# dpkg-query -W linux-image*
# lsb_release -s -d

How it works

  • Linux Standard Base (LSB) is standard that multiple distros sign up to. It specifies a Filesystem Hierarchy Standard (FHS) and other components of a Linux system.
  • LSB works on RPM package format, although Debian and Ubuntu dont use this by default. To get around this, Debian has alien package used to transform .rpm to .deb prior to installation. 

3. Checking for updates

  • Check for available updates
  • Install available updates
  • Check for specific package update
  • Check for all package updates.

CentOS

Check for specific package updates (in this case, updates for kernel)

# yum -q info kernel

To upgrade our kernel

# yum upgrade -y kernel

To upgrade all packages

# yum upgrade 
# yum update
  • upgrade and update are the same on newer distributions.
  • Using upgrade should technically be different. Upgrade uses logic to replace old programs. Inside yum.conf file, obsolete=1 is set by default, making update and upgrade functionally the same by default.

y/d/N

y – yes, download and upgrade all packages

d – just download packages.

N – abort 

  • Only kernel and systemd (init system) require reboot to complete the update, as they are the soul of the system. With the update, we are killing the old program to make our way for new.

Debian

  • We will use apt (newest package manager)

To update “updates list” and check for upgradable packages

# apt update

To list all upgradable packages that begin with linux-image (regex)

# apt list --upgradable linux-image*

To list all upgradable packages

# apt list --upgradable 

To upgrade single package

# apt install linux-image-amd64

To upgrade all packages:

# apt full-upgrade
# apt upgrade
  • full-upgrade and upgrade are equivalent. 

How it works

  • When we run package manager commands, we query servers they are configured to talk to, and asking them if there is any newer versions of the installed packages available.
  • Configured repositories are inside:
    • /etc/yum.repos.d/ directory (CentOS)
    • /etc/apt/sources.list.d (Debian)
    • /etc/apt/sources.list.conf (Debian)
  • If there are newer version of software available, then we can install or download them. 
  • Generally, good idea is to keep all software up to date, especially public-facing services (SSH, httpd and others)

4. Automating updates

  • Ways to automate updates 
  • Not recommended to do in production environments
  • Rebuilding systems programmatically

CentOS

# yum install -y yum-cron 
  • The software comes with two configuration files inside /etc/yum/ directory
  • By default, /etc/yum/yum-cron.conf filewill be used. 
  • /etc/yum/yum-cron.conf file has random sleep value inside and it should be disabled.
# sed -i “s/random_sleep = 360/random_sleep = 0/g” /etc/yum/yum-cron.conf
  • With the value set to 0, when we call yum-cron software, it will automatically run.
# yum-cron
  • If there are no updates, yum-cron will not show any output!
  • If there are updates, notification will pop that updates are downloaded successfully.
  • If you want to download AND install updates using yum-cron, change the yum-cron.conf file with following command or using nano:
# sed -i “s/appy_updates = no/apply-updates = yes/g” /etc/yum/yum-cron.conf

To check if processes need restarting (not restart machine, but to restart service itself)

# needs-restarting
  • Shows processes that need to be restarted in order to apply changes!

To check if processes need system rebooting

# needs-restarting -r
  • Shows processes that need system reboot to apply changes!

To start/enable yum-cron service

# systemctl enable --now yum-cron
  • New configuration file will show inside /var/lock/subsys/yum-cron
  • This file enables two more cron jobs inside:
    • /etc/cron.daily/0yum-daily.cron
    • /etc/cron.hourly/0yum-hourly.cron

Debian/Ubuntu

  • We use package called unattended-upgrades
  • unattended-upgrades is used to automatically update Debian-based distros
# apt install unattended-upgrades
  • Configuration files are inside /etc/apt/apt.conf.d/
  • Files are called 20auto-upgrades and 50unattended-upgrades
  • Edit 50unattended-upgrades and uncomment stable, stable-updates, proposed-updates

To run and test configuration with debug mode

# unattended-upgrade -d
  • Upgrades should be installed 

To list timers

# systemctl list-timers
  •     apt-daily.timer and apt-daily-upgrade.timer should show up

5. Checking mailing lists and errata pages

  • Where we go for news on how your OS are performing, are they healthy, do they need space…

Package changelogs

  • changelog provides information about specific package.

CentOS

To show most recently installed package

# rpm -q kernel --last
# rpm -q --changelog kernel-1.1.1-9… | less
  • Use less as the output is more than one screen

Debian/Ubuntu

# apt changelog linux-image-amd64

Official sources and mailing lists

Official sources:

Mailing lists:

Mailing lists are used to notify you (send you an email) for each thread you subscribe for. Good idea is to subscribe to newsletter for only packages you use in your environment. Following mailing lists are for each distribution:

Other resources:

6. Using snaps

  • Snaps work like any other package manager. It installs and manages a package brought from a repository to your system.
  • snapd is daemon that powers snaps. It is the environment that manages installed snaps, deals with installs, updates, deletes old versions…
  • When we install snap, we download read-only squashfs file that lives in /var/lib/snapd/snaps
  • Snap is a software that packages software in a universal fashion, and then that package can be deployed to any OS that supports snaps.

Search for snaps

# snap search foo

Install snaps

# snap install foo
  • Once finished, we will have foo installed from a snap.

List installed snaps

# snap list

Activate snap

# snap services
  • Shows active/inactive state of our services

To start snap

# snap start foo
Started.

Remove snaps

# snap remove foo

Show snap informations

# snap info foo

Also, it is available to search for snaps through Cannonical website.

7. Using Flatpak

  • Second package manager used. 
  • Same as snaps, packages software so that can be deployed to other systems that support Flatpak
  • Just another holy war
  • Flatpak emphasize desktop applications over server applications.
  • Mostly graphical tools used to manage Flatpak apps
  • When we install package using Flatpak, it is stored in:
    • System packages: /var/lib/flatpak
    • User packages: ~/.local/share/flatpak/ 
  • User packages stored inside ~/.local/share/flatpak/app/ are stored in files.
  • There are 585+ packages available to install from flathub repository

How many packages are available from flathub

# flatpak remote-ls flathub | wc -l

Update Flatpak applications

# flatpak update

Installing Flatpak

# apt install flatpak -y

Enable flathub repositoy from https://flathub.org

# flatpak remote-add --if-not-exists flathub

Search for a package

# flatpak search org.foo.foo
  • Package identifier or Application ID from the table above, is represented as follows:
  • org/com.<company or team name>.<application name>

Install a package

# flatpak install flathub org.foo.foo

Run a package

# flatpak run org.foo.foo

List installed packages

# flatpak list

Install package as a user

# flatpak --user remote-add --if-not-exists flathub
# flatpak --user install flathub org.foo.foo-y

Remove package

# flatpak uninstall org.foo.foo --user -y
  • Specifically removing user-installed version. The system one will remain.

8. Using Pip, RubyGems, and other package managers

  • Aside from YUM, Flatpak, snaps, apt, there are other package management systems.
  • Pip and RubyGems are programming-language related ways to distribute package to a system.

Pip installs package (Pip) – included in Python installations.

Gem is used to package Ruby elements (included in Python installations, too)

Install pip and RubyGems

# apt install libgmp3-dev make gcc ruby ruby-dev python3-setuptools -y

Install pip with easy_install3 script

# python 3 /usr/lib/python3/dist-packages/easy_install.py pip

Pip

Check pip version

# pip3 --version

List installed packages and their versions

# pip3 list

Search for installed packages

# pip3 search foo

Install a package

# pip3 install foo --user
  • Install package as a user (will be stored in user’s home directory)

Install a package (specify version)

# pip3 install foo==2.5.1 --user

Upgrade a package to latest version:

# pip3 install foo --upgrade --user

RubyGems

Check gem version

# gem --version

List installed gems

# gem list

List specific package

# gem search -e foo
  • -e for exact option. Pip lacks this function

Install a package as a user

# gem install foo --user-install

Run the package

# ~/.gem/ruby/2.5.0/bin/foo --version
  • Stored in home directory

Install other versions of packages

# gem install foo -v 14.2.0 --user-install
# ~/.gem/ruby/2.5.0/gems/chef-14.2.0/bin/chef-client --version

Uninstall the package

# gem uninstall foo
  • Choose to uninstall, press number to uninstall that package
  • Pip and RubyGems try to be self-contained.
  • They are just querying upstream repository for a package and then downloading it on your system.
  • When you update your PATH to update binary location new executables live in, only then you are able to run the packages that you installed.

9. Dependency hell

  • Dependency hell is the notion that a package can have dependencies on things that either conflict with other versions of dependent packages or libraries that you have installed, or can try to use incompatible versions.
Tags: , , , ,

Leave a Reply