How can I install just security updates from the command line?

Solution 1:

The package unattended-upgrades provides functionality to install security updates automatically.

You could use this, but instead of configuring the automatic part you could call it manually:

sudo unattended-upgrade -d --dry-run
sudo unattended-upgrade -d # Idem --debug

If you want to run it quietly instead:

sudo unattended-upgrade

Note: When you call unattended-upgrade you leave the "s" off the end (on newer versions there is a symlink to avoid this).

This assumes that the package is installed by default, which it probably is. If not, just do:

sudo apt install unattended-upgrades

See also /usr/share/doc/unattended-upgrades/README.md.

Solution 2:

A Few Tips On How To Manage Updates

This applies both to Debian and Ubuntu, but more specific instructions for Ubuntu follow.

  • Show security updates only :

    apt-get -s dist-upgrade |grep "^Inst" |grep -i securi 
    

    or

    sudo unattended-upgrade --dry-run -d
    

    or

    /usr/lib/update-notifier/apt-check -p
    
  • Show all upgradeable packages

    apt-get -s dist-upgrade | grep "^Inst"
    
  • Install security updates only

    apt-get -s dist-upgrade | grep "^Inst" | 
        grep -i securi | awk -F " " {'print $2'} | 
        xargs apt-get install
    

Notes:

  • Sometimes Ubuntu shows security updates as if they're coming from $release-updates repository. This is so, I'm told, because Ubuntu developers push security updates to $release-updates repository as well to expedite their availability.

    If that's the case, you can do the following to show security updates only:

    sudo sh -c 'grep ^deb /etc/apt/sources.list | 
        grep security > /etc/apt/sources.security.only.list'
    

    and

    apt-get -s dist-upgrade -o Dir::Etc::SourceList=/etc/apt/sources.security.only.list -o Dir::Etc::SourceParts=/dev/null  | 
        grep "^Inst" | awk -F " " {'print $2'}
    
  • Check what services need to be restarted after package upgrades. Figure out what packages you are going to upgrade beforehand and schedule your restarts/reboots. The problem here is that unless you restart a service it still may be using an older version of a library (most common reason) that's been loaded into memory before you installed new package which fixes a security vulnerability or whatever.

    checkrestart -v
    

    However, keep in mind that checkrestart may list processes that shouldn't necessarily be restarted. For example, PostgreSQL service may be keeping in its memory reference to an already deleted xlog file, which isn't a valid reason to restart the service.

    Therefore, another, more reliable, way to check this using standard utils is the following little bash script that I shamelessly stole from https://locallost.net/?p=233

    It checks if running processes on a system are still using deleted libraries by virtue of keeping copies of those in active memory.

    ps xh -o pid |
    while read PROCID; do
           grep 'so.* (deleted)$' /proc/$PROCID/maps 2> /dev/null
           if [ $? -eq 0 ]; then
                   CMDLINE=$(sed -e 's/\x00/ /g' < /proc/$PROCID/cmdline)
                   echo -e "\tPID $PROCID $CMDLINE\n"
           fi
    done
    

Solution 3:

replace /etc/apt/preferences with the following:

Package: *
Pin: release a=lucid-security
Pin-Priority: 500

Package: *
Pin: release o=Ubuntu
Pin-Priority: 50

now a simple apt-get upgrade will upgrade all security updates only.

Why (and how) this works: The preferences file will pin all packages from Ubuntu distribution to priority 50, which will make them less desirable than already installed packages. Files originating from security repository are given the default (500) priority so they are considered for installation. This means that only packages that are considered more desirable than currently installed ones are security updates. More information about pinning in the apt_preferences manpage.

You can temporarily promote a certain distribution for updates with the --target-release option that works with apt-get and aptitude (at least) which will allow you pin certain releases so that they are eligible for upgrade.

If you wish to use this for scripts only and not make it default for the system, you can place the rules in to some other location and use this instead:

apt-get -o Dir::Etc::Preferences=/path/to/preferences_file upgrade

This will make apt look for the preferences file from a non-default location.

The preferences file given as an example doesn't apply to third party repositories, if you wish to pin those too you can use apt-cache policy to easily determine the required keys for pinning.