Install system packages and apply updates

There are two kinds of packages on a SrvYard server. System packages come from Ubuntu (apt): security fixes, libraries and tools. Application packages come from Composer and npm, and sometimes live in private repositories that need a login. SrvYard handles each differently, and this article explains both so you know what happens by itself and what you do yourself.

SrvYard does not have a button that runs apt upgrade for you. It shows you how many updates are waiting and gives you recipes, saved Bash scripts you can run on one or many servers, to apply them in a controlled way. The Packages tab of a server is about the second kind: credentials for private Composer and npm packages.

Before you begin#

• A ready server. Everything here needs a Ready server SrvYard can log in to.
• A role that can run recipes to apply updates, and one that can manage the server to change package credentials.
• A backup, for big upgrades. Security updates are routine. Upgrading a database server, PHP or a kernel can interrupt services, so choose a quiet time and have a recent backup (see Schedule database backups).

1. What updates itself#

When SrvYard provisions a server it turns on Ubuntu's unattended upgrades: the package lists are refreshed daily and pending upgrades are applied by the system's automatic upgrade job, which by default installs security updates. It does not reboot the machine for you, and it does not jump major versions of PHP or databases. A kernel or library update can still need a restart to take effect; when that happens, the server shows an amber Reboot required badge in its header and the Monitoring tab says "A reboot is required".

2. See how many updates are waiting#

Open the server's Monitoring tab. SrvYard samples the server once a minute, and two of the tiles are about updates.

1. Uptime. How long since the last boot. The line under it changes to "A reboot is required" when installed updates need one.
2. Updates. The number of packages that can be upgraded. A dash means SrvYard has no sample yet.

The dashboard widget Pending updates shows the same across all servers: how many have updates waiting and how many need a reboot.

3. Apply updates with a recipe#

Recipes live under Recipes in the sidebar. An example recipe, Check pending OS updates, is a two-line script that refreshes the package lists and lists what is upgradable.

1. Run. Opens a dialog to pick the servers (step below).
2. Script. Bash, run as the user shown ("Bash, run as root."). The script here is apt-get update -qq followed by apt list --upgradable.
3. Recent runs. Each run on each server, with its status, exit code, who started it and how long it took. Open a row to read the output.

To apply updates, create your own recipe with New recipe: give it a name, choose Runs as root (apt needs it), and write the script, for example:

export DEBIAN_FRONTEND=noninteractive
apt-get update -qq
apt-get upgrade -y
[ -f /var/run/reboot-required ] && echo "A reboot is required"

The editor also accepts placeholders such as {{server_name}} and {{ip_address}}, filled in for each server. A recipe can be run on several servers at once, and a server must have the recipe's user or it is refused.

Run it#

1. Select all servers. Ticks every server that can run it. Servers that are installing or disconnected are listed as not ready and cannot be selected.
2. Tag filter. Narrow the list by tag, for example run on staging first and production later.
3. Send report via email. You get the result and the end of the output for each server.
4. Review. Shows the selection before anything runs. The number in brackets is how many servers you chose.

4. Install an extra system package#

To install a system package that is not a managed service, use a recipe with apt-get install -y package-name, run as root. For software SrvYard manages, use Services instead: Nginx, MySQL, MariaDB, PostgreSQL, Redis, Memcached, Meilisearch and Supervisor (see Manage services and restarts), and PHP versions and extensions under Runtimes (see Choose and switch PHP versions).

5. Credentials for private Composer and npm packages#

Open the server's Packages tab. It is titled Package authentication: credentials for private Composer repositories and npm registries, written to the files of a user on this server. They apply to every site that runs as that user, and a site's own credentials win for the same repository.

1. Package authentication. The page and its two cards, Composer (the http-basic part of auth.json) and npm (the user's .npmrc). Secrets are encrypted in SrvYard and never shown again.
2. Add credential. Opens the dialog for that tool. An empty card says "No Composer credentials yet" or "No npm credentials yet".

1. User. Whose file receives the credential: srvyard, or the user of a site if it runs under its own user. Sites that run as their own user only see their own credentials.
2. Repository. The host, for example repo.packagist.com.
3. Username. Your account on that repository.
4. Password or token. Use a token with read access only. The eye icon shows or hides what you type.
5. Add credential. Writes the file with mode 0600 and encrypts the secret in SrvYard.

The npm dialog asks for a Registry (for example https://npm.pkg.github.com), an optional Scope such as @acme, and an Auth token; it writes the user's ~/.npmrc. Removing a credential deletes it from SrvYard and from the file on the server, and deployments that need it fail until you add it again. A site can also store credentials in its own advanced settings (see Create a site on your server).

6. A simple routine#

A routine that works for most teams: glance at the Updates tile or the Pending updates dashboard widget once a week, run your update recipe on staging, check a site or two, then run it on production. If Reboot required appears, reboot at a quiet time from the Actions menu and check that the server returns to Ready and your sites answer. Keep the recipe in SrvYard so everyone on the team applies updates the same way and the run history shows who did what.

Troubleshooting#

• The Updates tile shows a dash. No sample has arrived yet. The first one comes within a minute of the server becoming ready.
• Updates keep reappearing. Some updates are held back by the system (kept-back packages). Run apt-get dist-upgrade in a recipe once you have checked what it will do.
• A recipe fails with "dpkg was interrupted" or a lock error. Another apt process is running, often the automatic upgrade. Wait a few minutes and run it again.
• Composer still asks for a login during a deploy. The credential is for another user than the one the site runs as, or the repository host does not match exactly. Add it again for the site's user.
• npm install returns 401. Check the registry URL, that the token has read access to the package, and the scope.
• I cannot add a credential. The server must be ready, and your role must allow managing the server.

Related#

• Manage services and restarts: restart services after an upgrade.
• Hardening checklist: firewall, SSH, updates: a regular update routine.
• Read the server overview: the Reboot required badge and actions.
• Create a site on your server: per-site Composer and npm authentication.