Alpine Linux 3.9.2Alpine Linux is a distribution designed to be small (in terms of resource usage) and secure. The distribution is intended for use in environments where performance and security are the top priorities, such as servers, firewalls and single board computers. Alpine offers an unusual collection of features, including using the musl C library instead of the more popular GNU C library, using Busybox for command line tools instead of the GNU tools, and it manages services through OpenRC instead of systemd or SysV init. The distribution also provides some added security through position independent executables (PIE) which make some common avenues of attacking memory more difficult.
There are several builds and editions of Alpine. There are specific downloads for running the distribution on physical hardware and virtual environments. There are also different builds depending on whether we want a fully functioning server operating system or a more minimal base. Finally, there are several architecture options for x86 (32-bit and 64-bit), ARM, PPC64, and s390x processors. I decided to download the Extended edition for 64-bit (x86_64) machines. The Extended version offers the most tools out of the box (though it is still pretty minimal by most standards) and loads itself into RAM to offer better performance. The download is 398MB in size.
I want to mention right up front that all of Alpine's editions are fairly minimal and intended for use on servers and embedded devices rather than workstations. The distribution is more of a platform for building something than an out-of-the-box solution or appliance. I recommend having a project in mind, such as setting up a home web server or e-mail solution, before using Alpine.
The live media boots almost immediately and presents us with a text console. We can sign into the root account without a password. The console displays some helpful tips, such as where to find the Alpine documentation on-line and that we can start the system installer by running the setup-alpine command. There are not many tools included on the live media, so once I confirmed my hardware was detected, I launched the installer.
The Alpine installer presents us with a series of text prompts and asks us to type in answers. Some prompts have defaults to help us through. We are asked to select our keyboard layout from a list, set our computer's hostname and then either set up an IP address and Internet gateway or enable DHCP to get a dynamic network. We can then pick our preferred DNS server and create a password for the root account. Next we select a time zone from a list, select which NTP (network time protocol) implementation to use from a list and select which secure shell implementation to enable. We are also asked to select a package mirror from a list.
It was this last step, picking a package mirror, that gave me some trouble. The first time through the installer, I set up networking manually and when I was asked to pick a package server from the list, there we no mirrors shown. This appeared to be due to an error that occurred when trying to download a list of mirrors. At this point I discovered I could not go back to previous steps of the installer to adjust network settings, so I used Ctrl-C to drop out of the installer and started over. The second time through I opted for DHCP networking, confirmed the proper IP and gateway had been assigned and continued through. Again, no mirror list was downloaded, leaving me stuck.
I tried manually adding a mirror to the package manager, but this was not accepted. I eventually asked the installer to pick a random mirror (from a list of none) and that convinced it to proceed. The final steps the installer takes are to ask us whether we want a traditional installation (placing the operating system and data on the hard drive, an approach Alpine calls "sys") or use the local disk for just storing data files and run the operating system from removable media. I went with the traditional (sys) install. The installer asks us which disk to use, the selected disk is wiped and the distribution's files copied. We are then asked to reboot the computer to begin using Alpine in earnest.
The locally installed copy of Alpine boots to a text console where we can sign in as the root user. The userland tools are provided by Busybox and software is linked against the lightweight musl C library. The distribution uses OpenRC as the service manager and runs on version 4.19 of the Linux kernel. Apart from the OpenSSH service running in the background and the network time synchronization, not much runs on Alpine by default. There is no graphical display, no manual pages, and no compiler. We can turn on and off background services using the service command and get a list of available services by running "service -l". We can enable daemons to run at boot time by running "rc-update add servicename" and disable items with "rc-update del servicename"
Alpine Linux 3.9.2 -- Getting started with the Alpine text console (full image size: 6kB, resolution: 720x400 pixels)
I tried running Alpine Linux on a workstation and in VirtualBox. The distribution worked well in both environments, running very quickly and detecting all of my hardware. I was especially happy with how fast Alpine boots and shuts down, its start time is probably less than a quarter of most mainstream distributions. Alpine uses about 33MB of RAM with a default install of the Extended edition and consumes just 675MB of disk space. Another 2GB of disk space is taken over by the distribution's swap space.
Package management on Alpine is handled by a command line tool called apk. The apk tool uses a similar syntax to Debian's APT or Fedora's DNF, with a few minor differences. The command "apk add" installs new software, "apk del" removes packages. I found "apk update" grabbed fresh repository information and "apk upgrade" updated packages. Though "apk search" is not mentioned in the tool's command line help, this command helps us find new packages.
Since trying to set up a package mirror did not work during the install process, I checked the on-line documentation and found a mirror list. The wiki explains how to add new package mirrors and this gave me access to 5,690 packages. I checked for updates and found just one (the Linux kernel) available. This new package downloaded and installed without any problems. I also added manual pages to assist my memory by running "apk add man man-pages". I found a number of command tools I normally use and did not have in the default install could be added to the system through the util-linux package.
Setting up a project
Earlier I mentioned that Alpine is more of a platform for building projects than a pre-packaged solution; we need a project in mind to make the distribution useful for a particular task. With this in mind I decided I would try to set up a Nextcloud installation for on-line file storage and see if I could get a ZFS volume set up to act as a backup/NAS solution.
At first I thought the easiest approach would be to install a Nextcloud package, if it were available, but searches for Nextcloud (and its close relative ownCloud) returned no results from apk. Opting to then take the manual route, I installed Apache (and got the service running) then went looking for a PHP package and did not find one. According to the Alpine wiki, PHP is in a separate repository, which I enabled. I now had access to 9,754 packages in total. Had I been thinking clearly, I might have double-checked the extra Community repository for a Nextcloud package, but I didn't. Instead I went ahead with enabling PHP and followed the Nextcloud install guide. Trying to access the new Nextcloud install resulted in an internal server error.
This is where it occurred to me to check the Alpine Community repository for a Nextcloud package and not only found one, but also a corresponding tutorial for running Nextcloud on Alpine Linux. The tutorial worked beautifully and I was soon able to sign into Nextcloud, upload files and set up a calendar. My lesson was learned: make sure the Community repository is enabled before searching for add-on packages.
Alpine Linux 3.9.2 -- Browsing files stored on Nextcloud (full image size: 81kB, resolution: 1239x1024 pixels)
Enabling a ZFS volume was next on my to-do list. I found a ZFS module in the repositories and downloaded it. The ZFS kernel module was not loaded automatically, but could be enabled by running "modprobe zfs". I was then able to use the zpool and zfs command line tools to set up a new volume. this worked well until I rebooted and the ZFS volume did not get mounted.
With a little looking around I discovered there are a number of ZFS services which need to be enabled at boot time with the rc-update command in order for ZFS volumes to get mounted when the system restarts.
In the end, while there was a little more work involved in setting up extra services than I would usually expect on a Linux distribution, everything did eventually work. I was left with a very fast, lightweight distribution that was running a couple of services. The distribution, with all of my services running, only consumed 75MB of RAM and less than 1GB of disk space.
Alpine Linux is different in some important ways compared to most other distributions. It uses different libraries, it uses a different service manager (than most), it has different command line tools and a custom installer. All of this can, at first, make Alpine feel a bit unfamiliar, a bit alien. But what I found was that, after a little work had been done to get the system up and running (and after a few missteps on my part) I began to greatly appreciate the distribution.
Alpine is unusually small and requires few resources. Even the larger Extended edition I was running required less than 100MB of RAM and less than a gigabyte of disk space after all my services were enabled. I also appreciated that Alpine ships with some security features, like PIE, and does not enable any services it does not need to run.
I believe it is fair to say this distribution requires more work to set up. Installing Alpine is not a point-n-click experience, it's more manual and requires a bit of typing. Not as much as setting up Arch Linux, but still more work than average. Setting up services requires a little more work and, in some cases, reading too since Alpine works a little differently than mainstream Linux projects. I repeatedly found it was a good idea to refer to the project's wiki to learn which steps were different on Alpine.
What I came away thinking at the end of my trial, and I probably sound old (or at least old fashioned), is Alpine Linux reminds me of what got me into running Linux in the first place, about 20 years ago. Alpine is fast, light, and transparent. It offered very few surprises and does almost nothing automatically. This results in a little more effort on our parts, but it means that Alpine does not do things unless we ask it to perform an action. It is lean, efficient and does not go around changing things or trying to guess what we want to do. These are characteristics I sometimes miss these days in the Linux ecosystem.
In fact, while I was using Alpine I kept thinking it felt more like a member of the BSD family in its style. The project offers the same style of platform without extras, the same sort of calm predictability, the same "Do what I say and only what I say" approach to system administration. In fact, I feel the conclusion I wrote when reviewingFreeBSD 12.0 could equally apply to Alpine:
Something which stands out about FreeBSD, compared to most Linux distributions I run, is that FreeBSD rarely holds the user's hand, but also rarely surprises the user. This means there is more reading to do up front and new users may struggle to get used to editing configuration files in a text editor. But FreeBSD rarely does anything unless told to do it. Updates rarely change the system's behaviour, working technology rarely gets swapped out for something new, the system and its applications never crashed during my trial. Everything was rock solid. The operating system may seem like a minimal, blank slate to new users, but it's wonderfully dependable and predictable in my experience.
This might make Alpine less attractive to newcomers or to desktop users, but I think it is a strong argument for using Alpine Linux on servers and embedded devices where reliability is more important than convenience.
* * * * *
Hardware used in this review
My physical test equipment for this review was a desktop HP Pavilon p6 Series with the following specifications: