DNS Server on Pi Alpine Linux

Well, as of now, I’ve got my home DNS server running on a Pi Model B+ with Alpine Linux.

There were a few quirks in the process, but mostly it just went very very well. The little sucker is blindingly fast, with a tiny memory footprint, and has security and routing features built in from the get go. I’m happy.

Some background on the decision: I fretted far too long over this. Yet Another Package Manager to learn. Yet Another init process to sort out (it uses OpenRC instead of rc.d files as in BSD, or SystemV Init like most other sane things outside BSD, or the {bastard} systemD).

Just being way too lazy. Turns out that the “package manager” parts you need to “learn” are one name (apk) and so far one option (add). Oh, and an “update” to start it off right. As for OpenRC, so far all I’ve needed is one command to tell it to start services on boot up. “rc-update add packagename“. That’s it. Sigh. Maybe an hour all told reading web pages and looking for pain, and not finding any, and then thinking “Hell with it, just try it” and finding out they were NOT leaving things out…

I’d pondered BSD. I love it. It makes great routers and firewalls. It installs fairly easily up to the point of X-Windows (which mostly sucks everywhere but really really sucks when you have to do it yourself, as it is in BSD near as I can tell). It is also huge to build as it has every package in the universe available. But generally you can make a locked down ‘stripper’ from it and be fairly small and fast. But a lot of work as “the experienced systems admin” is expected to want to customize everything anyway, so why start with something they don’t want? Just more work for them to strip that out first…

I’d pondered Void. Small and using musl libraries and with security features like Alpine, but with a working out of the box GUI… Reading the pages on it, it is still a bit of a young port. Running it from SD on the laptop was a bit slower than I wanted (but that could just be the laptop not liking SD cards). It has it’s quirks too. It’s own design for several key parts, like package mangers and init processes.

For anyone wanting the canonical download set of all things void, visit:

https://repo.voidlinux.eu/live/current/

Unlike trillions of other existing distros, Void is not a modification of an existing distribution. Void’s package manager and build system have been written from scratch.
[…]
xbps

xbps is the native system package manager, written from scratch with a 2-clause BSD license.

xbps allows you to quickly install/update/remove software in your system and features detection of incompatible shared libraries and dependencies while updating or removing packages (among others). See the usage page for a brief introduction.

runit

We use runit as the init system and service supervisor.

runit is a simple and effective approach to initialize the system with reliable service supervision. See the usage page for a brief introduction.

xbps-src

xbps-src is the xbps package builder, written from scratch with a 2-clause BSD license.

This builds the software in containers through the use of Linux namespaces, providing isolation of processes and bind mounts (among others). No root required!

Additionally xbps-src can build natively or cross compile for the target machine, and supports multiple C libraries (glibc and musl currently).

So the same “learn new stuff” issues as Alpine. With the same musl (smaller, faster, and likely more secure libraries) security features

https://wiki.voidlinux.eu/Void_Linux

Security

Void was the first distribution to switch to LibreSSL by default, replacing OpenSSL. Due to the Heartbleed fiasco we believe that the OpenBSD project has qualified and pro-active developers to provide a more secure alternative.

So the major claims to fame were the build system (and I was not looking forward to learning a complex build system) and LibreSSL vs OpenSSL. Add in the usual expectations of a young port (missing packages, bugs not discovered so far, too much work and not enough hands to fix everything fast) and it was not exactly what I wanted on a dedicated, and ignored, appliance that Had To Work Always (or the family would be nagging me about maintenance issues when DNS was crappy…)

I decided it would be better as an experimental desktop platform, and a bit later.

Alpine

But what tipped me to Alpine was the heritage. It started life as a router project that fit on a floppy.

https://en.wikipedia.org/wiki/Alpine_Linux

History

Originally, Alpine Linux began as a fork of the LEAF project. The members of LEAF wanted to continue making a Linux distribution that could fit on a single floppy disk, whereas the Alpine Linux wished to include some more heavyweight packages such as Squid and Samba, as well as additional security features and a newer kernel. One of the original goals was to create a framework for larger systems; although usable for this purpose, this is no longer a primary goal.

The LEAF project being a follow-on from the Linux Router Project, that I loved way back when.

The LEAF – Linux Embedded Appliance Framework […] is a collection of Linux distributions that began as a fork from the Linux Router Project (LRP) “linux-on-a-floppy” distribution. Most users of these distributions are primarily interested in router and firewall functions, particularly as combined with the convenience of major features of general Linux distributions such as shells, packet filtering, SSH servers, DNS services, file servers, webmin and the like. LEAF is a common choice when commercial NAT routers are insufficiently flexible or secure, or are unattractively nonconformant to open source philosophy.

https://alpinelinux.org/about/

I’ve bolded some bits.

About

Alpine Linux is an independent, non-commercial, general purpose Linux distribution designed for power users who appreciate security, simplicity and resource efficiency.

Small

Alpine Linux is built around musl libc and busybox. This makes it smaller and more resource efficient than traditional GNU/Linux distributions. A container requires no more than 8 MB and a minimal installation to disk requires around 130 MB of storage. Not only do you get a fully-fledged Linux environment but a large selection of packages from the repository.

Binary packages are thinned out and split, giving you even more control over what you install, which in turn keeps your environment as small and efficient as possible.

Simple

Alpine Linux is a very simple distribution that will try to stay out of your way. It uses its own package manager called apk, the OpenRC init system, script driven set-ups and that’s it! This provides you with a simple, crystal-clear Linux environment without all the noise. You can then add on top of that just the packages you need for your project, so whether it’s building a home PVR, or an iSCSI storage controller, a wafer-thin mail server container, or a rock-solid embedded switch, nothing else will get in the way.

Secure

Alpine Linux was designed with security in mind. The kernel is patched with an unofficial port of grsecurity/PaX, and all userland binaries are compiled as Position Independent Executables (PIE) with stack smashing protection. These proactive security features prevent exploitation of entire classes of zero-day and other vulnerabilities.

This thing has been a small, fast, secure router and firewall from the very start. Generations of tuning and polishing, and enhancements. It is unlikely you will find mysterious networking bugs in something with that history behind it.

Sure, it’s grown up. A Lot. No longer fitting on a single floppy. But it fits Very Nicely on a 4 GB SD card AND runs entirely from memory. Things get real fast when you never take a pause for I/O to disks, SD cards, or whatever…

As a generally more “shaken out” heritage, with small fast footprint, and security features up front, it looked like my best choice.

My review of my first install of it as an initial survey is here:
https://chiefio.wordpress.com/2016/05/20/alpine-linux-small-fast/

Besides, on my DNS server I don’t need things like X and GUIs… It runs ‘headless’ with just power and network cable plugged in.

So I decided to ‘give it a go’ today. As of a few hours later, it is my running DNS server.

dnspi:~$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
devtmpfs                 10240         0     10240   0% /dev
shm                     223180         0    223180   0% /dev/shm
/dev/mmcblk0p1         3260176     87208   3172968   3% /media/mmcblk0p1
tmpfs                   223180     14132    209048   6% /
tmpfs                    44636       128     44508   0% /run
cgroup_root              10240         0     10240   0% /sys/fs/cgroup
/dev/loop0               19328     19328         0 100% /.modloop
dnspi:~$ 

The SD card is that mmcblk0p1 thingy. That’s 87 MB used. That’s it. The whole enchilada. I could put this thing on a 128 MB card and have too much room left over.

Mem: 45216K used, 401144K free, 14264K shrd, 744K buff, 25360K cached
CPU:   0% usr   0% sys   0% nic  99% idle   0% io   0% irq   0% sirq
Load average: 0.00 0.00 0.00 1/81 1395
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1395  1381 chiefio  R     1616   0%   0   0% top
 1380  1378 chiefio  S     5572   1%   0   0% sshd: chiefio@pts/0
 1378  1337 root     S     5556   1%   0   0% sshd: chiefio [priv]
 1337     1 root     S     2976   1%   0   0% /usr/sbin/sshd
 1308     1 root     S     1612   0%   0   0% /usr/sbin/crond -c /etc/crontabs
 1381  1380 chiefio  S     1612   0%   0   0% -ash

This is on the small Pi with ‘only’ 512 MB of memory. Notice that 401 MB of it are “free” and only 45 MB are used for running. (The rest goes to the GPU and / or the RAMdisk). Note, too, that with an SSH login to it, and a remote display of ‘top’ running, and doing DNS services and whatall, it is at load average 0.00 and 99% idle. The load is in a fraction of a percent somewhere.

Now that’s what a Linux is supposed to do. None of this 10% of your quad core CPU sucked up by SystemD playing with it’s bits…

Ok, on to the “how To” part…

Install and Configure

I covered the basics of this in the prior article, but I needed to do it all over again to get the newest copy and put it on the B+ (as I’d made the other one on the Pi-2 and that’s not going to run on the B+… different instruction sets). The “short form” is that you download a compressed tarball, extract it, stuff it onto a Fat-32 formatted SD card, stick it in the Pi and boot. That’s about it. Then you configure.

Their directions are here:

http://wiki.alpinelinux.org/wiki/Raspberry_Pi

Preparation

This section will help you format and partition your SD card:

Download Alpine for Raspberry Pi tarball which is named as alpine-rpi–armhf.rpi.tar.gz. You will need version 3.2.0 or greater if you have a Raspberry Pi 2.
Mount your SD card to your workstation
Use gnome-disks or fdisk to create a FAT32 partition. If you are using fdisk, the FAT32 partition type is called W95 FAT32 (LBA) and its ID is 0xC.
Mark the newly created partition as bootable and save
Mount the previously created partition
Extract the tarball contents to your FAT32 partition
Unmount the SD Card.

Now I used ‘gparted’ on Debian to do the formatting of the card, but in fact most cards come already Fat-32. For reasons that now seem silly, I chose to put a 512 MB ‘swap’ partition as the second partition on the card. Now that seems really silly as there is clearly no need to swap anything with 10 x the used memory as free memory… Oh Well… I used gunzip ( I think…) to uncompress it. (Why they bother to compress it is a mystery. 87 MB uncompressed, 84 MB compressed… ) then made a directory on my hard disk ( mkdir /{path_to}/Alpine, cd /{path_to}/Alpine, cp ~chiefio/saved_download_Alpine_stuff .) and then did a ‘tar xvf alpine-rpi-3.4.5-armhf.rpi.tar’ after which you can remove the tar file.

ls -l a*
-rw-r--r-- 1 root    root 86681600 Nov  5 13:43 alpine-rpi-3.4.5-armhf.rpi.tar
-rw-r--r-- 1 chiefio  500 84700261 Nov  5 13:41 alpine-rpi-3.4.5-armhf.rpi.tar.gz

and you are left with:

root@R_Pi_DebJ_DD:/SG2/ext/Alpine# ls
apks			bcm2708-rpi-cm.dtb   bcm2710-rpi-cm3.dtb  cmdline.txt  overlays
bcm2708-rpi-b.dtb	bcm2709-rpi-2-b.dtb  boot		  config.txt   start.elf
bcm2708-rpi-b-plus.dtb	bcm2710-rpi-3-b.dtb  bootcode.bin	  fixup.dat

That stuff gets copied onto the SD card and it’s ‘good to go’. I used “cp -r . /SD/mountpoint” wherever your SD card gets mounted…

This next bit is important. Alpine does NOT SAVE STATE OF CHANGES unless you tell it to do so. Anything you change evaporates at the next boot unless you do “lbu ci” or “lbu commit”.

So if you screw something up, just reboot and try again… and do the lbu ci at the end.

Installation

Alpine Linux will be installed as diskless mode, hence you need to use Alpine Local Backup (lbu) to save your modifications between reboots. Follow these steps to install Alpine Linux:

Insert the SD Card into the Raspberry Pi and turn it on
Login into the Alpine system as root. Leave the password empty.
Type setup-alpine
Once the installation is complete, commit the changes by typing lbu commit

Type reboot to verify that the installation was indeed successful.
Post Installation
Update the System

Upon installation, make sure that your system is up-to-date:

apk update
apk upgrade

Don’t forget to save the changes:

lbu commit

First login is as root, with NO password. You set the password later.

Pay close attention to the prompts in the ‘setup-alpine’. First time through I got distracted and hit ‘return’ to take the default on DNS servers, and then it could not find any of the mirrors as the default was no DNS servers… Sigh. Reboot…

Also note that the “apk update” is very important. I didn’t do it before trying to install dnsmasq and it turns out that the first time it is run, it builds the package index from the mirror, so do it FIRST, then ‘apk add’ something…

So what all did I do?

I gave “setup-alpine” my desired ip number and gateway, and DNS server. I told it to set my time zone and answered the other questions (that are all the usual things…) If you don’t know what the usual things are, just run it and note what it wants to know, then reboot without saving and you will be exactly where you started. Mostly things like what kind of keyboard and what clock daemon to run and similar. When in doubt, take the default. (But NOT for DNS… at least give it 8.8.8.8 if you have no other you like better)

I did:

apk update
apk add iptables
apk add iptables-doc
apk add iputils
apk add dnsmasq
rc-update add iptables
rc-update add dnsmasq
adduser {your username}
apk add sudo
lbu ci

That’s pretty much it. Reboot headless and ssh into it for any further configuration.

I still need to add my IP filter choices, and my DNS entries to nuke advertising and other annoyances. For that, I need to suck them out of the old config of the DNS server (or remake them from a current avoid list…)

For now, I’m happy with lightning fast DNS response from it, even if a bit wide open. I initially pointed it to my Telco boundary router for it’s DNS, so I also need to put a longer list of ‘upstream’ for it to try.

Future Stuff

At some point I will want to set up VPN on it, so I can VPN to my home spigot on the world from the coffee shop and have my traffic encrypted in the WiFi snoop zone there…

https://wiki.alpinelinux.org/wiki/Linux_Router_with_VPN_on_a_Raspberry_Pi

There is more on package management here:

http://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management

Overview

The apk tool has the following applets:
add 	Add new packages to the running system
del 	Delete packages from the running system
fix 	Attempt to repair or upgrade an installed package
update 	Update the index of available packages
info 	Prints information about installed or available packages
search 	Search for packages or descriptions with wildcard patterns
upgrade 	Upgrade the currently installed packages
cache 	Maintenance operations for locally cached package repository
version 	Compare version differences between installed and available packages
index 	create a repository index from a list of packages
fetch 	download (but not install) packages
audit 	List changes to the file system from pristine package install state
verify 	Verify a package signature 

To do more stuff with networking, see:

http://wiki.alpinelinux.org/wiki/Configure_Networking

It has a link to suggestions on how to set up iptables firewall rules, plus an example of restarting networking service:
/etc/inet.d/networking restart

They suggested a couple of more packages that I’m not familiar with, so I added them just to play with:

apk add iproute2
apk add drill

I’m sure there will be more things I try with it over time. The old server had a torrent server running on it, along with a small apache web server (so dead requests from DNS redirecting to self would hit it and get a ‘worked!’ light weight page in response). It also was a testbed for NFS file services. Over time I’ll need to decide if this card does those services, or if I move them further inside the perimeter.

In Conclusion

I feel a bit the fool for taking so long to ‘just do it!’ (as my old work-mate and skiing instructor, Walt, would say…).

Turns out the whole thing took less time than just typing it up here. What next? Well, just “to be sure”, I’m going to do one last lbu commit and then make a reserve copy of the card. I do that via a plain ‘dd’ of the whole bag of bits onto a patch of hard disk. So I’ll shut down the dnspi, take the card and mount it on my desktop PiM3, and do:

dd bs=1M if=/dev/sdx of=/CardArchives/DNSPI_Alpine_server

Where if=”in file” is the SD card device. So if, say, it is mounted at /SD/card you would do a ‘df’ and see that /SD/card was /dev/sdb1 and then just drop that digit (as we are taking the whole card, not just one partition) and do a ‘umount /SD/card’ first… So in this example it would be:

dd bs=1M if=/dev/sdb of=/wherever/you/like/File_Name

Well, not bad for a Saturday afternoon…

Subscribe to feed

Advertisement