Alpine-Linux on ¬ just serendipity 🍀

Alpine Linux: update timezone

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 20 Feb 2026 12:32:19 +0100

♠ Once upon a time, my alpine linux VPS was located in Toronto (Canada). For a while now it’s been in Frankfurt (Germany).

Linode makes changing the location of your VPS a breeze. Recently though I realized I forgot to update the system timezone.

In the systemd world, we would do this:

timedatectl set-timezone Europe/Berlin

And verify it with:

timedatectl show --property=Timezone --value

I appreciate the simplicity of timedatectl.

However, this is Alpine Linux, wherein we don’t say the s* word.

First, identify your desired timezone:

ls /usr/share/zoneinfo

We’ll go with Europe/Berlin. Symlink /etc/localtime to it:

doas ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime

In addition, update /etc/timezone:

echo 'Europe/Berlin' | doas tee /etc/timezone

That’s all.

For completeness you may want to reboot afterwards, but it’s not strictly necessary.

— § —

Reply via email

#alpine-linux #dev #selfhosted

★ New APKBUILD: LLM edition

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 18 Feb 2026 11:23:05 +0100

♠ Problem statement: package prek for Alpine Linux.

prek is a modern replacement for pre-commit, covered (many times) in this blog¹.

Previously.

It’s already a breeze to create APKBUILDs. I’ve been doing so for ages.

Now, in 2026, with agentic LLMs, it’s even more so!

I can be more useful to the Alpine Linux community by increasing my efficiency as a package maintainer.

Yesterday I used Amp Free in smart mode (Opus 4.6) to scaffold the APKBUILD for prek, using the AUR PKGBUILD as a baseline. Prompt:

write an APKBUILD for prek, inspired by https://aur.archlinux.org/packages/prek

once written, copy it to knol (ssh knol)
aports dir: ~/workspace/aports (in knol)

The result:

# Maintainer: Thiago Perrotta <{redacted}>
pkgname=pre
pkgver=0.3.3
pkgrel=0
pkgdesc="Better pre-commit, re-engineered in Rust"
url="https://github.com/j178/prek"
arch="all"
license="MIT"
makedepends="cargo cargo-auditable"
subpackages="
	$pkgname-bash-completion
	$pkgname-fish-completion
	$pkgname-zsh-completion
	$pkgname-doc
	"
source="$pkgname-$pkgver.tar.gz::https://github.com/j178/prek/archive/v$pkgver.tar.gz"
options="net" # fetch dependencies

prepare() {
	default_prepare
	cargo fetch --target="$CTARGET" --locked
}

build() {
	cargo auditable build --release --frozen

	target/release/prek util generate-shell-completion bash > $pkgname.bash
	target/release/prek util generate-shell-completion fish > $pkgname.fish
	target/release/prek util generate-shell-completion zsh > $pkgname.zsh
}

check() {
	cargo test --frozen
	cargo test --frozen -- --skip cache_gc_keeps_local_hook_env --skip cache_gc_removes_unreferenced_entries
}

package() {
	install -Dm755 target/release/$pkgname -t "$pkgdir"/usr/bin/

	install -Dm644 $pkgname.bash "$pkgdir"/usr/share/bash-completion/completions/$pkgname
	install -Dm644 $pkgname.fish "$pkgdir"/usr/share/fish/vendor_completions.d/$pkgname.fish
	install -Dm644 $pkgname.zsh "$pkgdir"/usr/share/zsh/site-functions/_$pkgname

	install -Dm644 LICENSE -t "$pkgdir"/usr/share/licenses/$pkgname/
	install -Dm644 README.md -t "$pkgdir"/usr/share/doc/$pkgname/
}

sha512sums="
87f5b5905d0c95b7f55a789eb00b463bb987c5fc981d83500f34a41b8e9ea2e4a0ac9d45a0c3a029a7957de33f5ade866c396c399252eb4a7a9e09e32e270b99  prek-0.3.3.tar.gz
"

This was a great initial attempt, but tests failed:

Stopped on the first failure. Run `cargo insta test` to run all snapshots.
thread 'cache_gc_removes_unreferenced_entries' (15179) panicked at /builds/thiagowfx/aports/testing/prek/tmp/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/insta-1.46.3/src/runtime.rs:719:13:
snapshot assertion for 'cache_gc_removes_unreferenced_entries-2' failed in line 234
failures:
    cache_gc_keeps_local_hook_env
    cache_gc_removes_unreferenced_entries

A follow-up edit yielded this diff:

@@ -30,7 +30,7 @@ build() {
}

check() {
-	cargo test --frozen
+	cargo test --frozen -- --skip cache_gc_keeps_local_hook_env --skip cache_gc_removes_unreferenced_entries
}

package() {

…but that caused more failures. Then I got interrupted and the night ended.

Today, I continued with Claude Code.

Original prompt to claudey² using Opus 4.6:

we’re packaging prek for alpine linux (APKBUILD)

we’re using https://aur.archlinux.org/packages/prek as reference

we have access to an alpine system in knol (ssh knol)

the aports tree lives in ~/workspace/aports in knol

we’re already in the right branch, the prek APKBUILD lives in testing/prek within knol

the problem is that the test is failing in our MR pipeline: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/97666

sample job: https://gitlab.alpinelinux.org/thiagowfx/aports/-/jobs/2223963 (raw log: https://gitlab.alpinelinux.org/thiagowfx/aports/-/jobs/2223963/raw)

fix the APKBUILD!

I think it’s a missing checkdep

A couple of burned tokens later:

APKBUILD updated. Here’s what changed:

Added checkdepends=“bash python3”:

python3 — prek’s pygrep language handler uses uv to find a Python interpreter. Without system Python, uv python find fails, causing all 11 pygrep tests to fail. Also needed for the windows_script_run test which uses a #!/usr/bin/env python3 shebang.

bash — the script tests use #!/usr/bin/env bash shebangs, and Alpine doesn’t ship bash by default (only busybox ash).

Added –skip for language integration tests needing unavailable runtimes:

docker — needs Docker daemon (also covers docker_image via substring match)

julia — Julia not available in Alpine

lua:: — Lua interpreter not available

haskell — GHC/cabal not available

node:: — Node.js/npm not available

ruby:: — Ruby not available

rust:: — Rust toolchain tests (rustup) not available

swift:: — Swift not available

bun:: — Bun not available

The unit tests (282) plus other integration suites (auto_update, builtin_hooks, cache, hook_impl, identify, install) still run fully. You can commit and push to re-trigger the pipeline.

That’s spot on. Here’s the diff:

🧙 thiago@knol ~/workspace/aports/testing/prek git:prek
❯ git --no-pager show
commit 8f702c5f1ee1b6d153a4f957c309f2badd452d31 (HEAD -> prek)
Author: Thiago Perrotta <{redacted}>
Date:   Wed Feb 18 05:30:14 2026 -0500

    skip language integration tests

diff --git testing/prek/APKBUILD testing/prek/APKBUILD
index 5e134457bc..d6080fa977 100644
--- testing/prek/APKBUILD
+++ testing/prek/APKBUILD
@@ -7,6 +7,7 @@ url="https://github.com/j178/prek"
 arch="all"
 license="MIT"
 makedepends="cargo cargo-auditable"
+checkdepends="bash python3"
 subpackages="
 	$pkgname-bash-completion
 	$pkgname-fish-completion
@@ -30,7 +31,18 @@ build() {
 }

 check() {
-	cargo test --frozen -- --skip cache_gc_keeps_local_hook_env --skip cache_gc_removes_unreferenced_entries
+	cargo test --frozen -- \
+		--skip cache_gc_keeps_local_hook_env \
+		--skip cache_gc_removes_unreferenced_entries \
+		--skip "docker" \
+		--skip "julia" \
+		--skip "lua::" \
+		--skip "haskell" \
+		--skip "node::" \
+		--skip "ruby::" \
+		--skip "rust::" \
+		--skip "swift::" \
+		--skip "bun::"
 }

 package() {

I had to continue with a few more follow-ups though. Eventually, that led to Merge Request (MR) !97666:

# Maintainer: Thiago Perrotta <{redacted}>
pkgname=prek
pkgver=0.3.3
pkgrel=0
pkgdesc="Better pre-commit, re-engineered in Rust"
url="https://github.com/j178/prek"
arch="all"
license="MIT"
makedepends="cargo cargo-auditable"
subpackages="
	$pkgname-bash-completion
	$pkgname-fish-completion
	$pkgname-zsh-completion
	$pkgname-doc
	"
source="$pkgname-$pkgver.tar.gz::https://github.com/j178/prek/archive/v$pkgver.tar.gz"
options="net" # fetch dependencies

prepare() {
	default_prepare
	cargo fetch --target="$CTARGET" --locked
}

build() {
	cargo auditable build --release --frozen

	target/release/prek util generate-shell-completion bash > $pkgname.bash
	target/release/prek util generate-shell-completion fish > $pkgname.fish
	target/release/prek util generate-shell-completion zsh > $pkgname.zsh
}

check() {
	cargo test --frozen --lib
}

package() {
	install -Dm755 target/release/$pkgname -t "$pkgdir"/usr/bin/

	install -Dm644 $pkgname.bash "$pkgdir"/usr/share/bash-completion/completions/$pkgname
	install -Dm644 $pkgname.fish "$pkgdir"/usr/share/fish/vendor_completions.d/$pkgname.fish
	install -Dm644 $pkgname.zsh "$pkgdir"/usr/share/zsh/site-functions/_$pkgname

	install -Dm644 LICENSE -t "$pkgdir"/usr/share/licenses/$pkgname/
	install -Dm644 README.md -t "$pkgdir"/usr/share/doc/$pkgname/
}

sha512sums="
87f5b5905d0c95b7f55a789eb00b463bb987c5fc981d83500f34a41b8e9ea2e4a0ac9d45a0c3a029a7957de33f5ade866c396c399252eb4a7a9e09e32e270b99  prek-0.3.3.tar.gz
"

…wherein all tests pass.

I can’t compile prek on my little alpine linux VPS (1GB RAM). Apparently Rust is a monster that requires a lot of RAM for compiling and linking software with hundreds of dependencies.

I tested it by grabbing the built .apk package from the GitLab pipeline from my MR:

⏺ x86_64 passed. Let's grab the artifact and install it:

⏺ Bash(ssh knol "curl -L -o /tmp/prek-x86_64.zip
      'https://gitlab.alpinelinux.org/api/v4/projects/3998/jobs/2224483/artifacts' && cd /tmp && unzip -o
      prek-x86_64.zip &&…)
  ⎿    % Total    % Received % Xferd  Average Speed  Time    Time    Time   Current
                                      Dload  Upload  Total   Spent   Left   Speed
       0      0   0      0   0      0      0      0                              0100  3.51M 100  3.
     … +19 lines (ctrl+o to expand)

⏺ Bash(ssh knol "sudo apk add --allow-untrusted /tmp/packages/testing/x86_64/prek-0.3.3-r0.apk && prek
      --version")
  ⎿  (1/1) Installing prek (0.3.3-r0)
     Executing busybox-1.37.0-r31.trigger
     OK: 1257.5 MiB in 579 packages
     prek 0.3.3

⏺ Installed and working. prek 0.3.3 on knol. All 8 completed architectures passed (riscv64 is still
  building).

The LLM tries to use sudo instead of doas, which is not correct on Alpine Linux.

It works anyway because I have the doas-sudo-shim package installed:

% sudo -h
Usage:
  sudo (-i | -s) [-n] [-u <user>] [<command> [--] [<args>...]]
  sudo [-ins] [-u <user>] <command> [--] [<args>...]
  sudo [-h]

Execute a command as another user using doas(1).

This is not the original sudo, but the doas shim for sudo. It supports only
a subset of the sudo options (both short and long) that have an equivalent in
doas, plus option -i (--login). Refer to sudo(1) for more information.

If you need some sudo features that are not supported in doas, replace
package 'doas-sudo-shim' with 'sudo': apk add sudo !doas-sudo-shim.

Please report bugs at <https://github.com/jirutka/doas-sudo-shim/issues>.

Expect a post about prek soon. ↩︎
alias claudey=claude --dangerously-skip-permissions, with no annoying confirmation prompts ↩︎

— § —

Reply via email

#ai #alpine-linux #bestof #dev

Alpine Linux: clear /tmp upon reboot

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 05 Feb 2026 18:02:12 +0100

♠ Clear /tmp at reboot on Alpine Linux via Chimo:

By default, Alpine Linux doesn’t (completely) clear the /tmp directory on reboot (unless you mount it as tmpfs). If you would like to enable this feature, change “wipe_tmp” to “YES”

[…]

My current config:

# List of /tmp directories we should clean up
clean_tmp_dirs="/tmp"

# Should we wipe the tmp paths completely or just selectively remove known
# locks / files / etc... ?
wipe_tmp="NO"

# Write the initial dmesg log into /var/log/dmesg after boot
# This may be useful if you need the kernel boot log afterwards
log_dmesg="YES"

# Save the previous dmesg log to dmesg.old
# This may be useful if you need to compare the current boot to the
# previous one.
#previous_dmesg=no

I find that to be a sensible change indeed:

% doasedit /etc/conf.d/bootmisc
# [...]
# update from NO:
# wipe_tmp="YES"

I left my config like this:

[...]
# Should we wipe the tmp paths completely or just selectively remove known
# locks / files / etc... ?
# wipe_tmp="NO"
wipe_tmp="YES"
[...]

I like to leave the previous / default value commented out, it is a good paper trail¹ for my future self.

tombstone, in software engineering parlance ↩︎

— § —

Reply via email

#alpine-linux #dev

'New' series: Raspberry Pi fun with DevOps, redux

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 17 Jan 2026 23:14:21 -0300

♠ Once upon a time, a few mistakes ago, I wanted to start a blog series about doing projects with my two Raspberry Pi units at home.

The initial post described my vision, but it was never followed upon. There was a mix of reasons for that:

lack of time and proper prioritization
being overwhelmed by choice
a desire to stay digitally disconnected¹
lack of structure in this blog²

Needless to say, my motivation is still well alive, and I have an itch to move forward with this project this year. Let’s see how it will flow.

I want to start by commenting on my ideas from 15 months ago. New Thiago reviews old Thiago.

For a long time I’ve been wanting to do something useful with them, while increasing my DevOps toolkit knowledge.

And trying out new tools and workflows that I am not able to try at work – either because they don’t make sense there, or due to lack of prioritization.

The roadblock to do so was the most classic excuse: lack of non-interrupted time.

There’s plenty of motivation, and ideas. These will likely never run out, any time soon.

Still true! Hah!

There’s no guarantee I will follow up on all of these ideas but,

I can foresee the future! 🔮

Guiding principles

a.k.a. rules of engagement

My revised goals:

It must run unix → unchanged.
It must be vanilla / upstream → unchanged.
Every software installation must come from a package → packages are still OK, but I am opening up the possibility for container images as well (e.g. via docker or podman). Ad-hoc installations are still explicitly ruled out, UNLESS they are scripted in an idempotent manner e.g. via Ansible or pyinfra, but only as a last resort.
It must have no X11 nor Wayland nor a graphical system → unchanged. Web server management interfaces are acceptable though.
Software updates must happen with a single command → unchanged. These days I have sd_world. A custom Justfile recipe would also be acceptable: just update or just upgrade or just world.
It should be reasonably popular and well-supported → unchanged. No abandonware.
It should support Raspberry Pi (the ARM architecture, for that matter) as a first-class citizen → unchanged.

Revised distributions / operating systems:

Debian — RaspberryPi OS
Fedora
Alpine Linux
Arch Linux (Arch Linux ARM)
Gentoo Linux
NixOS
FreeBSD
OpenBSD
~~openSUSE~~: I decided that, if I invest in the .rpm world, Fedora is the way to go.
~~Ubuntu~~: I decided that, if I invest in the .deb world, Debian is the way to go. Ubuntu remains solid for commercial / enterprise usage, but this is a personal project.
~~Void Linux~~: too niche, no enthusiasm for Void Linux in my circle these days. If I ever tried it, I feel it would be used as a Desktop distro.
~~Slackware Linux~~: updated on 2025-09-11. Too niche, no enthusiasm for it in my circle these days.

This list is still quite large. I will need to trim it down further in the following days. Stay tuned.

Now it’s shorter: 4 less distros. Progress!

One big question is whether I’ll treat my Raspberries as pets or as cattle.

To be continued ■³.

Life is short. ↩︎
More specifically: linking related posts to each other, and having an easy way to go from the previous to the next post in a series. ↩︎
Wishful thinking. ↩︎

— § —

Reply via email

#alpine-linux #dev

PostgreSQL major version upgrade on Alpine Linux, redux

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 15 Jan 2026 22:25:09 -0300

♠ Previously.

Problem statement #

Given Alpine Linux 3.23 running PostgreSQL 17, upgrade to PostgreSQL 18. For this specific example, consider a miniflux database.

The previous post still applies, with only one exception:

PostgreSQL 18 enables data‑checksums by default:

Version 18 enables data‑checksums by default. In earlier versions, initdb required the --data‑checksums flag. The new release notes explicitly list the change in the incompatibilities section: “Change initdb default to enable data checksums… Checksums can be disabled with the new --no‑data‑checksums option”.

This is a better sensible default, but it breaks the normal upgrade flow:

~/18/tmp $ pg_upgrade -b /usr/libexec/postgresql17/ -B /usr/libexec/postgresql18/ -d /var/lib/postgresql/17
/olddata/ -D /var/lib/postgresql/18/data
Performing Consistency Checks
-----------------------------
Checking cluster versions                                     ok

old cluster does not use data checksums but the new one does
Failure, exiting

The stable upgrade path is to initialize the new cluster database (v18) with --no-data-checksums:

~/18/tmp $ initdb --no-data-checksums -D /var/lib/postgresql/18/data --locale=en_US.UTF-8 --encoding=UTF8
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /var/lib/postgresql/18/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default "max_connections" ... 100
selecting default "shared_buffers" ... 128MB
selecting default time zone ... America/Toronto
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

initdb: warning: enabling "trust" authentication for local connections
initdb: hint: You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb.

Success.

Then perform the migration as usual. Once the migration is complete, for the sake of improving the reliability of the database, enable checksums:

~/18/tmp $ pg_checksums --enable -D /var/lib/postgresql/18/data
Checksum operation completed
Files scanned:   1380
Blocks scanned:  89609
Files written:  1151
Blocks written: 89605
pg_checksums: syncing data directory
pg_checksums: updating control file
Checksums enabled in cluster

Note: You must run pg_checksums while the cluster is off-line, otherwise:

~/18/tmp $ pg_checksums --enable -D /var/lib/postgresql/18/data
pg_checksums: error: cluster must be shut down

Remember to delete the previous package once the upgrade is fully complete:

/var/lib/postgresql # doas apk del postgresql17
(1/3) Purging postgresql17-openrc (17.7-r1)
(2/3) Purging postgresql17 (17.7-r1)
  Executing postgresql17-17.7-r1.pre-deinstall
(3/3) Purging postgresql17-client (17.7-r1)
Executing busybox-1.37.0-r31.trigger
Executing postgresql-common-1.3-r0.trigger
OK: 1271.3 MiB in 577 packages

That’s all!

— § —

Reply via email

#alpine-linux #dev

★ .apk-new

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 22 Dec 2025 01:00:02 -0300

♠ After running an Alpine Linux server for a couple of months (or years), you’ll inevitably find a couple of .apk-new files scattered in your filesystem within /etc:

% doas find / -name "*.apk-new"
/etc/rc.conf.apk-new
/etc/inittab.apk-new
/etc/fstab.apk-new
/etc/ssh/sshd_config.apk-new
/etc/passwd.apk-new
/etc/crontabs/root.apk-new
/etc/group.apk-new
/etc/ufw/ufw.conf.apk-new
/etc/ufw/user6.rules.apk-new
/etc/ufw/user.rules.apk-new
/etc/abuild.conf.apk-new
/etc/default/grub.apk-new
/etc/shadow.apk-new
/etc/network/interfaces.apk-new
/etc/profile.d/locale.sh.apk-new
/etc/doas.conf.apk-new

As per the alpine user handbook:

Installing a package means that the package itself will be downloaded from a repository (specified in /etc/apk/repositories) and unpacked to the system. Existing files will be overwritten. An exception are configuration files in /etc, which will be preserved. The configuration files (which comes from the package) will be renamed to *.apk-new.

It’s very similar to what happens in Arch Linux with .pacnew files. Arch Linux has an utility called pacdiff:

It will search for .pacnew, .pacsave and .pacorig files, and will then prompt to take action upon them.

…and also in Gentoo Linux with etc-update or dispatch-conf.

Alpine Linux lacks such an utility, to the best of my knowledge.

As such, I vibe coded one in pancake.

I hereby introduce apknew:

Reconcile .apk-new configuration files on Alpine Linux, similar to pacdiff on Arch Linux.

By default, it operates on /etc only.

A sample run looks like the following, prompting a pair of files at a time:

==============================================
File: /etc/crontabs/root.apk-new
Original: /etc/crontabs/root
==============================================

[v]iew diff  [k]eep original  [r]eplace with new  [m]erge  [s]kip
Action:

You’ll want to hit v first to inspect the diff, and then decide whether to:

keep the original file
replace it with the newer package file
interactively merge them (e.g. with vimdiff)
do nothing (skip)

It’s much easier than diffing each file manually.

Another example:

% apknew/apknew.sh
Searching for .apk-new files in /etc...
Found 14 file(s) to process.

==============================================
File: /etc/passwd.apk-new
Original: /etc/passwd
==============================================

[v]iew diff  [k]eep original  [r]eplace with new  [m]erge  [s]kip
Action: s
Skipping /etc/passwd.apk-new...

==============================================
File: /etc/shells.apk-new
Original: /etc/shells
==============================================

[v]iew diff  [k]eep original  [r]eplace with new  [m]erge  [s]kip
Action: v
--- /etc/shells	2025-12-21 11:07:42.531531775 -0500
+++ /etc/shells.apk-new	2025-12-15 09:00:47.000000000 -0500
@@ -1,5 +1,3 @@
 # valid login shells
 /bin/sh
 /bin/ash
-/bin/zsh
-/bin/bash

[v]iew diff  [k]eep original  [r]eplace with new  [m]erge  [s]kip
Action: k
Removing /etc/shells.apk-new...
Done. Kept original file.

— § —

Reply via email

#alpine-linux #bestof #dev

Alpine Linux: usr-merge

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 15 Oct 2025 11:16:36 +0200

♠ Alpine Linux:

The Alpine Linux Technical Steering Committee (TSC) has decided to change the base filesystem hierarchy. In the future, /lib, /bin, and /sbin will be symbolic links to their /usr counterparts, and every package shall be installed under the /usr paths. For now, /usr/bin and /usr/sbin will continue to be independent paths, but that might change if the Filesystem Hierarchy Standard (FHS) gets updated.

Just like Arch Linux has been doing for ages (2013).

Fedora also did a similar move this year.

I’ve been running Alpine Linux since 3.15 (2021), its current version is 3.22. The migration process has been quite straightforward.

% doas apk upgrade -aU     # perform a full system upgrade
% doas apk add merge-usr   # install the migration script
% doas merge-usr --dryrun  # exec the migration script in dry-run mode

If the dry-run succeeds:

% doas merge-usr           # exec the migration script
$ doas apk del merge-usr   # clean up

Fin.

— § —

Reply via email

#alpine-linux #dev

★ zizmor

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 03 Oct 2025 12:44:21 +0200

♠ I originally heard of zizmor at FOSDEM 2025:

zizmor is a static analysis tool for GitHub Actions. It can find and fix many common security issues in typical GitHub Actions CI/CD setups.

One month later, I adopted it in the most important repos of our company.

A few months later, I added it to the Alpine Linux repositories, and am happily maintaining it there.

Now I use it everywhere, via a git pre-commit hook:

repos:
  - repo: https://github.com/woodruffw/zizmor-pre-commit
    rev: b933184438555436e38621f46ceb0c417cbed400 # frozen: v1.13.0
    hooks:
      - id: zizmor

The project has recently reached a milestone: it has turned one year old. Its adoption, community and feature set have all significantly increased during that time, in a good way.

The goal, impact and spirit of the project are all really great. And I’m sure this is mainly thanks to the initiative and dedication of its author, William Woodruff.

— § —

Reply via email

#alpine-linux #bestof #dev #fosdem #security

Alpine Linux: remove broken packages

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 20 Jul 2025 10:52:11 +0200

♠ In a sunny Sunday morning:

% doas apk upgrade
WARNING: The indexes contain broken packages which might not function properly.
[...]

What?! Out of nowhere?

I tried a couple of basic troubleshooting commands:

% doas apk update --force-refresh
% doas apk fix
% doas apk cache clean

…to no avail.

Next idea: search engines. Virtually no results on Kagi. No relevant results on Google either¹.

Next idea: LLMs. Nothing useful either.

This is novel territory! That’s what makes it fun to self-host Alpine Linux².

My intuition tells me to start by searching their Gitlab. Eventually I got linked to this:

test/solver/error11.test:

@ARGS add invalid
@REPO error.repo
@EXPECT
WARNING: The indexes contain broken packages which are not installable.
ERROR: unable to select packages:
  invalid-1:
    error: uninstallable
    satisfies: world[invalid]

From this test file, it seems possible that there’s an invalid package in my /etc/apk/world. The error message is not quite the same, but it is similar:

% wc -l /etc/apk/world
293

There are too many packages there to hunt each of them by hand. And I didn’t install any new packages recently.

So I looked into apk fix --help and discovered there is a --verbose flag. I did not save its output, but there were five packages there:

- busybox-initscripts
- kmod-openrc
- libacl
- py3-pep517
- sensible-utils

I ran doas apk del to remove all of them. That was a sensible cleanup, but it still has not resolved the issue.

If I want to dive deeper into this, I’ll have to add some debugging logging to src/database.c in apk-tools:

if (db->compat_depversions) {
    apk_warn(out,
        "The indexes contain broken packages which %s.",
        db->compat_notinstallable ? "are not installable" : "might not function properly");
}

Then one last thought occurred to me:

% apk --version
apk-tools 3.0.0_rc5_git20250715-r0, compiled for x86_64.

Aha! I am running a release candidate version of apk, because I am using Alpine Linux edge repositories:

http://dl-cdn.alpinelinux.org/alpine/edge/main
http://dl-cdn.alpinelinux.org/alpine/edge/community
http://dl-cdn.alpinelinux.org/alpine/edge/testing

From the Wiki:

After 5 years of development in the master branch of apk-tools, apk v3 is now ready for Alpine v3.23.0. This should be a safe and seamless upgrade from apk v2, but might has some breaking changes if you use libapk.

No wonder this is bleeding edge territory!

I would say that there’s nothing to do here, other than waiting for the next release of Alpine Linux (3.23) with apk-tools v3, and ignoring the warning in the meantime.

Their AI overview insists on spitting out useless information about Ubuntu, which is completely unrelated in this case. ↩︎
It is fun. Right? Right?! ↩︎

— § —

Reply via email

#alpine-linux #dev

Alpine Linux: Dockerfile: install package from edge

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 04 Jun 2025 12:37:47 +0200

♠ Problem statement: Given a Dockerfile based on a fixed release of Alpine Linux (e.g. FROM alpine:3.22), install a package from edge (i.e. a package that did not yet make it to a fixed release).

The approach is similar to package pinning, by providing a custom --repository to apk add:

RUN apk add --no-cache --repository=https://dl-cdn.alpinelinux.org/alpine/edge/testing gliderlabs-sigil vals

Replace “testing” with “community” or “main” as needed.

— § —

Reply via email

#alpine-linux #dev #docker

Alpine Linux: package is gone?!

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 04 Jun 2025 11:43:05 +0200

♠ Upon upgrading one of our Dockerfiles from Alpine Linux 3.21 to 3.22, we noticed that the ruby-json package no longer exists:

% docker build -t myproject -f Dockerfile .
[...]
 > [ 2/10] RUN apk add --update --no-cache ruby-json=~"3.4" [...]
[...]
2.371 ERROR: unable to select packages:
2.371   ruby-json (no such package):
2.371     required by: world[ruby-json~3.4]

Why??

First, look into Alpine Linux Packages: query. Ensure to set branch to v3.22 and architecture to All. And it’s indeed not there anymore:

No matching packages found…

Next, do a bit of digging in the aports repository on the Alpine Linux GitLab: query. Search for ruby-json in “All” Merge requests.

That leads to !80599:

community/ruby-json: remove

ruby-json is already bundled with main/ruby. The community/ruby-json could never be installed due to conflicts.

Aha, then there’s nothing to do here. Installing the base ruby package should be enough from now on.

#16938:

I think it’s safe to say community/ruby-json does literally nothing, has never been installed, and does not work.

Oh well.

— § —

Reply via email

#alpine-linux #dev

★ Alpine Linux packaging: track new software releases

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 03 Jun 2025 01:36:53 +0200

♠ Problem statement: You maintain packages for a Linux distribution, for example, Alpine Linux. Find a way to keep track of new software releases, to ensure your packages are kept up-to-date.

The Release Monitoring project (codename Anitya), part of the Fedora Linux distro, can accomplish that:

Watch for releases of your favorite projects

We all have our favorite projects and we all like to use their latest versions with their latest features. However, it is hard to keep in touch with all of them and be informed when they release a new version. Anitya can help!

We monitor upstream releases and broadcast them on Fedora messaging bus.

The underlying project:

Anitya is a release monitoring project.

Its goal is to regularly check if a project has made a new release. When Anitya discovers a new release for a project, it publishes a RabbitMQ message via fedora messaging. This makes it easy to integrate with Anitya and perform actions when a new release is created for a project. For example, the Fedora project runs a service called the-new-hotness which files a Bugzilla bug against a package when the upstream project makes a new release.

Anitya provides a user-friendly interface to add, edit, or browse projects.

Even though it is part of Fedora, we can use it for Alpine Linux just fine!

Recently I packaged zizmor. I noticed there was no entry for it in Anitya. I added one. It’s very straightforward:

head to https://release-monitoring.org/
ensure the project you want to monitor isn’t already present there
log in (e.g. via GitHub)
click add project

Fill in the form:

Project name: zizmor
Homepage: https://docs.zizmor.sh
BackEnd: GitHub
Version scheme: Semantic
Github owner/project: zizmorcore/zizmor
Version prefix: v
Pre-release filter: rc
Version filter: rc (excludes 1.8.0-rc0) and the like
Check off “check releases instead of tags”

Once the project is created, add a new distribution mapping:

Distribution: Alpine
Package name: zizmor

And we’re done!

As per https://pkgs.alpinelinux.org/flagging:

Package flagging

Manual package flagging has been disabled in favour of automatic flagging based on Anitya.

If you want a package to be up-to-date or to inform the maintainer about the package status, please feel free to create a package mapping on Anitya. Once the mapping is made, it should automatically send an email to the maintainer whenever a new version is available.

For details on how to create a project mapping for Alpine Linux, please refer to the release monitoring documentation.

— § —

Reply via email

#alpine-linux #bestof #dev

★ PostgreSQL major version upgrade on Alpine Linux

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 24 May 2025 16:00:23 +0200

Problem statement #

Given Alpine Linux 3.22 running PostgreSQL 16, upgrade to PostgreSQL 17. For this specific example, consider a miniflux database.

Procedure #

Install PostgreSQL 17:

% doas apk add postgres

It can coexist with postgres16.

Stop the PostgreSQL daemon:

% doas service postgresql stop

If you navigate to the Miniflux server with your browser, it will fail, as expected:

store: unable to create app session: dial tcp [::1]:5432: connect: connection refused

Change the PostgreSQL system version to the desired one:

% doas pg_versions set-default 17

Change to the root user, for convenience, then change to the existing postgresql directory:

% doas su
% cd /var/lib/postgresql/

Prepare files and directories for the upgrade:

% cd 16/
% mv data olddata
% cd ../
% mkdir 17/
% cd 17/
% mkdir data tmp
% chown postgres:postgres data tmp

Change to the postgres user:

% su postgres
% cd tmp/

Initialize the new cluster:

% initdb -D /var/lib/postgresql/17/data --locale=en_US.UTF-8 --encoding=UTF8 [--data-checksums]
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /var/lib/postgresql/17/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default "max_connections" ... 100
selecting default "shared_buffers" ... 128MB
selecting default time zone ... America/Toronto
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

initdb: warning: enabling "trust" authentication for local connections
initdb: hint: You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb.

Success.

In the previous command I chose to omit --data-checksums, otherwise I get the following error:

old cluster does not use data checksums but the new one does
Failure, exiting

Upgrade the new cluster:

% pg_upgrade -b /usr/libexec/postgresql16/ -B /usr/libexec/postgresql17/ -d /var/lib/postgresql/16/olddata/ -D /var/lib/postgresql/17/data/
Performing Consistency Checks
-----------------------------
Checking cluster versions                                     ok
Checking database user is the install user                    ok
Checking database connection settings                         ok
Checking for prepared transactions                            ok
Checking for contrib/isn with bigint-passing mismatch         ok
Checking data type usage                                      ok
Creating dump of global objects                               ok
Creating dump of database schemas
                                                              ok
Checking for presence of required libraries                   ok
Checking database user is the install user                    ok
Checking for prepared transactions                            ok
Checking for new cluster tablespace directories               ok

If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.

Performing Upgrade
------------------
Setting locale and encoding for new cluster                   ok
Analyzing all rows in the new cluster                         ok
Freezing all rows in the new cluster                          ok
Deleting files from new pg_xact                               ok
Copying old pg_xact to new server                             ok
Setting oldest XID for new cluster                            ok
Setting next transaction ID and epoch for new cluster         ok
Deleting files from new pg_multixact/offsets                  ok
Copying old pg_multixact/offsets to new server                ok
Deleting files from new pg_multixact/members                  ok
Copying old pg_multixact/members to new server                ok
Setting next multixact ID and offset for new cluster          ok
Resetting WAL archives                                        ok
Setting frozenxid and minmxid counters in new cluster         ok
Restoring global objects in the new cluster                   ok
Restoring database schemas in the new cluster
                                                              ok
Copying user relation files
                                                              ok
Setting next OID for new cluster                              ok
Sync data directory to disk                                   ok
Creating script to delete old cluster                         ok
Checking for extension updates                                ok

Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade.
Once you start the new server, consider running:
    /usr/libexec/postgresql17/vacuumdb --all --analyze-in-stages
Running this script will delete the old cluster's data files:
    ./delete_old_cluster.sh

Now clean up:

% ^D  # go back to the root user
% /var/lib/postgresql/17/tmp/delete_old_cluster.sh
% rmdir /var/lib/postgresql/16/  # it should be empty by now

If you’re curious about this script, it’s a simple one-liner:

#!/bin/sh

rm -rf '/var/lib/postgresql/16/olddata'

Finally, let’s get the cluster back up and vacuum it:

% ^D  # go back to your main user
% doas service postgresql start
% doas su - postgres -c '/usr/libexec/postgresql17/vacuumdb --all --analyze-in-stages'
vacuumdb: processing database "miniflux": Generating minimal optimizer statistics (1 target)
vacuumdb: processing database "postgres": Generating minimal optimizer statistics (1 target)
vacuumdb: processing database "template1": Generating minimal optimizer statistics (1 target)
vacuumdb: processing database "miniflux": Generating medium optimizer statistics (10 targets)
vacuumdb: processing database "postgres": Generating medium optimizer statistics (10 targets)
vacuumdb: processing database "template1": Generating medium optimizer statistics (10 targets)
vacuumdb: processing database "miniflux": Generating default (full) optimizer statistics
vacuumdb: processing database "postgres": Generating default (full) optimizer statistics
vacuumdb: processing database "template1": Generating default (full) optimizer statistics

At this point, Miniflux should be working again. Navigate to /about and verify its database version: Postgres version: 17.5.

Last step, delete the previous package:

% doas apk del postgresql16 postgres16-contrib

Double-check the newer version is still installed:

% apk list -I | grep postgres
libpq-17.5-r0 x86_64 {postgresql17} (PostgreSQL) [installed]
postgresql-common-1.2-r1 x86_64 {postgresql-common} (MIT) [installed]
postgresql-common-openrc-1.2-r1 x86_64 {postgresql-common} (MIT) [installed]
postgresql-zsh-completion-5.9-r5 x86_64 {zsh} (MIT-Modern-Variant AND GPL-2.0-only) [installed]
postgresql17-17.5-r0 x86_64 {postgresql17} (PostgreSQL) [installed]
postgresql17-client-17.5-r0 x86_64 {postgresql17} (PostgreSQL) [installed]
postgresql17-contrib-17.5-r0 x86_64 {postgresql17} (PostgreSQL) [installed]
postgresql17-openrc-17.5-r0 x86_64 {postgresql17} (PostgreSQL) [installed]

And we’re done!

References #

— § —

Reply via email

#alpine-linux #bestof #dev

★ Alpine Linux: the maintainer workflow

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 20 Apr 2025 15:12:09 +0200

♠ I maintain a couple of packages on Alpine Linux.

Every now and then, a new software version is released, and it’s my duty¹ as an active package maintainer to update my packages.

The typical workflow looks like the following.

First I get an email notification from “Alpine Package DB”:

Dear Thiago Perrotta

This is an automatic message send from pkgs.alpinelinux.org One or more of your aports have been flagged out of date based on Anitya monitoring system https://release-monitoring.org/

argocd current: 2.14.2-r1 new: 2.14.9

To update the package you can use our helper script:

abump aport-version

If the provided information is incorrect, please let us know on IRC or alpine-infra@alpinelinux.org. Thanks!

It’s important not to burn oneself out.

I treat these notifications as an FYI. They are not prompts to make me immediately go and update the packages². For packages with frequent updates, like argocd, I’ll let a few patch versions accumulate before I take action. Other times it is handy to batch package upgrades together so to do them all at once. I use my personal judgment here. At the very least, this email will trigger a TODO in my task list, so that it will not be forgotten. At some point it will be taken care of.

Once I am ready to update the package, I ssh to my Alpine Linux server. There is absolutely no requirement to update alpine linux packages from alpine linux, but it’s the most convenient to do, and I already have an alpine linux system anyway.

Then cd aports/. This is a local git clone of the aports tree (wiki).

git pull. I tend to clean up after myself, so the last branch is likely already master. But, if not, then git reset --hard && git checkout master && git pull. Amen.

Now the real fun starts. And it’s surprisingly quick and simple, it feels like cheating:

% abump argocd-2.14.9

This will update the version and checksums in the corresponding APKBUILD and trigger a package build.

It’s sensible to check the package release notes or changelog to find potential incompatibilities and/or updates to the build process. It’s also sensible to look at the package diffs to inspect for potential malware, which is becoming increasingly more common these days in open source packages. “Secure your supply chain”, as they say it.

If the build completes successfully, create a new branch (git nb argocd), commit, push it (git pushm), then create a merge request (MR) on GitLab. I normally use the Web UI to do so, but it’s also possible to do it with the CLI. A link to create the MR is printed to stdout upon pushing the branch, which makes the process even easier.

It could happen that the MR fails CI for some architectures (even if it works locally on my machine™). These errors need to be dealt with.

The commit message must follow a certain style. I have a pre-commit script set up that does it for me. It is typically in this form:

testing/argocd: upgrade to 2.14.9

There’s a rule: only one package per merge request.

If there are more packages to upgrade, I run git bd (“branch delete”) and then restart this process. It’s quite manageable, as I don’t maintain a lot of packages. Perhaps it could be further automated if there were more packages and/or if the package upgrades were more frequent.

The final MR looks like the following: !83026.

Now I sit tight and wait for approval.

On a best-effort basis. ↩︎
Unless it’s a security risk or incident (e.g. whenever there’s a CVE associated with it). ↩︎

— § —

Reply via email

#alpine-linux #bestof #dev

★ First Alpine Linux package in Community

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 01 Apr 2025 14:27:41 +0200

♠ How wholesome: someone sent a MR (Merge Request) !82047 in alpine/aports with the yamlfmt package I maintain, moving it from testing/ to community/¹.

This means the package will be included in the next release of Alpine (3.22) as part of its official repositories (unlike “testing”, which is only included in “edge”).

In other words: This is the first time a package I maintain will make it to the official repositories of a Linux distro I like!

Next milestone: Follow suit with a project I maintain.

I did not initiate this: it has just happened organically / spontaneously. ↩︎

— § —

Reply via email

#alpine-linux #bestof #dev #serenity

Alpine Linux: install / pin old packages

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 08 Jan 2025 15:54:44 -0300

♠ Let’s say you want to install an older version of jq in Alpine Linux.

For example:

Alpine v3.18 has jq 1.6
Alpine v3.19 has jq 1.7

You’re probably using Alpine v3.21 or edge today, which has an even newer version of jq. Hence doas apk add jq will not do.

Let’s assume you do not want to edit your /etc/apk/repositories, as this is an one-off, for a single package. What can you do then?

Use the --repository flag from apk!

% doas apk add --no-cache --repository=http://dl-cdn.alpinelinux.org/alpine/v3.18/main jq=~1.6

It’s also important to pin the package version (~1.6), otherwise the latest one available gets installed.

Replace “main” with “community” or “testing” as needed.

— § —

Reply via email

#alpine-linux #dev

Alpine Linux 3.21

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 10 Dec 2024 19:52:33 -0300

♠ Alpine Linux 3.21.0 got released last Thursday.

So what? I am credited as an aports commit contributor! :-)

Alpine package search: a list of all the packages I currently maintain, excluding dependencies:

argocd
autotrash
bkt
fpp
gliderlabs-sigil
kubeseal
tfupdate
typos
urlwatch
yamlfmt

…a total of 10 packages.

— § —

Reply via email

#alpine-linux #dev

★ New series: Raspberry Pi fun with DevOps

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 13 Oct 2024 11:31:13 +0200

Intro #

I have two raspberry pi¹ units sitting idle at home, a 3B and a 4.

For a long time I’ve been wanting to do something useful with them, while increasing my DevOps toolkit knowledge.

The roadblock to do so was the most classic excuse: lack of non-interrupted time.

There’s plenty of motivation, and ideas. These will likely never run out, any time soon.

That said: It’s very easy to get distracted and lose focus. There is so much information today, in the form of YouTube videos, blog posts, forums and communities (e.g. the likes of Hacker News and Reddit), podcasts, books…the list goes on, and it does not end.

Therefore, for the sake of fixing a North Star path, I wanted to make an initial blog post with some of the ideas that are currently in my head.

There’s no guarantee I will follow up on all of these ideas but, as long as their spirit is ingrained in semi-permanent written form, I figured that shall be enough to make me accountable to myself.

Guiding principles #

a.k.a. rules of engagement

It must run Unix

No Windows. No macOS. Anything else is fair game. Corollary: It must run either Linux or BSD.

It must be vanilla / upstream

No spin-offs. For example: for Ubuntu, no Xubuntu. For Arch Linux, no Manjaro. For Gentoo, no Funtoo. And so on. Stick to the core / base Linux distributions. For BSD, this is a non-issue.

Every software installation must come from a package

If there is no package, I will create one myself. This is easier if I use Arch Linux or Alpine Linux, but I am willing to contribute to other distributions as well.

It must have no X11 nor Wayland nor a graphical system

It should be a pure server. In the past I ran RaspberryPi OS (neé Raspbian) and it wasn’t very useful, besides being super slow and sluggish.

Software updates must happen with a single command

There is no need for auto-updates (these are often not well-supported anyways), but a human operator should be able to upgrade everything in a single shot. It doesn’t have to be a single command (e.g. apt update + apt upgrade is acceptable), but it should be contained within a short script.

It should be reasonably popular and well-supported

No obscure distributions. I don’t particularly care about a sizeable community (I won’t join their Discord server nor Reddit community anyway), but there should be at least one official support channel, and it would be preferred that it is old-school (BBS / Discourse / forums, mailing lists, IRC / Matrix). Stack Exchange is also acceptable to an extent. The problem with the modern stuff (Discord, Reddit) is that it is too proprietary, can / will disappear at any moment, and will be heavily used to train LLMs with no scrutiny. Commercial support is fine. For example, Red Hat backing Fedora, Canonical backing Ubuntu, and SUSE backing openSUSE is a non-issue. I would just avoid commercial enterprises that suffocate their open counterparts.

It should support Raspberry Pi (the ARM architecture, for that matter) as a first-class citizen

If Raspberry Pi support is considered experimental, I would avoid the trouble at this time.

Stopping briefly here for a moment, the following list comes to mind, using DistroWatch and Linux Distribution timeline as an aid:

Debian — RaspberryPi OS
Ubuntu
Fedora
openSUSE
Alpine Linux
Arch Linux (Arch Linux ARM)
Void Linux
Gentoo
NixOS
FreeBSD
OpenBSD
~~Slackware Linux~~ (Updated on 2025-09-11)

This list is still quite large. I will need to trim it down further in the following days. Stay tuned.

Some observations before I make a final decision:

I have two units, so one decision to make is whether to choose the same distribution for both or distinct distributions for each. One Linux and one BSD, for example.
I never used the following distros: Void Linux, NixOS, OpenBSD, Slackware Linux. There’s always an appeal to trying out something new, even if just ephemerally.
I am heavily experienced in Debian / Ubuntu, Arch and Alpine (with a tad of Gentoo as well). There’s an appeal to using something I am already familiar with to get the OS out of the way, and thus focus more on DevOps.
NixOS is very tempting for the purposes of reproducibility, but every time I look at it I feel lost in its sea of complexity. And it oftentimes feels bloated. Reproducibility comes with a non-trivial upfront cost.
OpenBSD feels very tempting as a self-contained, “do one thing and do it well”, KISS & secure system. It lacks on integration with third-party software, but perhaps that’s a feature.
Let’s be honest, as much as Slackware has its charm, realistically I am not choosing it. Its ecosystem is too small today. It doesn’t provide any value when compared to the rest of the list. Between Slack and Alpine, I’d easily pick Alpine with no effort.

Hence we can already eliminate one: ~~Slackware Linux~~.

To be continued ■

Two units is a safer choice than “raspberry pies” or “raspberry pis”. ↩︎

— § —

Reply via email

#alpine-linux #bestof #dev

New APKBUILD: argocd

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 09 Oct 2024 23:03:32 +0200

♠ ArgoCD is a widely used GitOps software for Kubernetes Continuous Delivery (see USERS.md).

I am quite surprised no one bothered to create an Alpine Linux package for it.

Until…now, by yours truly.

This APKBUILD took a bit longer to create than the usual. There were a couple of issues with -buildmode=pie, addressed with export CGO_ENABLED=1 (via make CGO_FLAG=1).

Also, not every architecture is compatible with it. The following error message appears in ARM builds:

cannot use math.MaxInt64 (untyped int constant 9223372036854775807) as int value in argument to env.ParseNumFromEnv (overflows)

Anyway, once it is merged upstream, enjoy!

% doas apk add argocd

— § —

Reply via email

#alpine-linux #dev #kubernetes

End of life package info

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 06 Sep 2024 17:41:30 +0200

♠ https://endoflife.date/ is like Repology but, instead of package versions, it tracks the end of life of various packages, linux distributions, frameworks, etc.

For example, Alpine Linux: https://endoflife.date/alpine

— § —

Reply via email

#alpine-linux #dev

apk autoupdate on alpine linux

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 18 Aug 2024 17:32:48 +0200

♠ Problem statement: Upon running doas apk upgrade on Alpine Linux, select packages with binaries backed by system services should be automatically restarted.

Deb-based systems have checkrestart(8).

On Alpine, the best available approach as of today is https://github.com/jirutka/apk-autoupdate/:

doas apk add apk-autoupdate
$EDITOR /etc/apk/autoupdate.conf

Then make the two following changes¹:

# Because the default is '*', which will prevent all services from restarting.
services_blacklist=""

# List of services that should be restarted upon package upgrades.
services_whitelist="miniflux tailscale"

From this point on, whenever there are system upgrades for the aforementioned services (doas apk upgrade), they will be automatically restarted. There’s no need for doas /etc/init.d/miniflux restart.

h/t to @fossdd for replying to my https://github.com/jirutka/apk-autoupdate/issues/8 thread. ↩︎

— § —

Reply via email

#alpine-linux #dev

Docker on Alpine Linux

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 30 Jul 2024 22:56:58 +0200

♠ In this post: how to properly start docker on an Alpine Linux server.

First, install docker and friends:

doas apk add docker docker-cli docker-compose

Then start the docker service:

doas service docker start

Check if it started successfully:

service docker status

If not, then look at the logs:

less /var/log/docker.log

I got an error:

failed to start daemon: error initializing graphdriver: driver not supported

The suggestion was to change the driver to overlay2:

% $EDITOR /etc/docker/daemon.json
{
  "storage-driver": "overlay2"
}

Then restart docker.

I got another error:

level=error msg="failed to mount overlay: no such device" storage-driver=overlay2

The suggestion was to reboot:

doas reboot

Then start docker again:

doas service docker start

And now everything works!

— § —

Reply via email

#alpine-linux #dev #docker

Alpine Linux: How to install all manpages (idiomatically)

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 20 Jul 2024 16:19:53 +0200

♠ This post is a reply to https://tilde.town/~kzimmermann/articles/installing_alpine_manpages.html.

The author describes their experience while attempting to install all man pages for all the packages in use in their system.

The breakdown progression has some valuable insights on how a typical Unix sysadmin addresses a problem. I tend to adopt a similar approach when entering unknown territory.

However, in Alpine Linux, there is a better way.

Solution #

There is a docs metapackage:

% apk info docs
docs-0.2-r6 description:
Meta package for pulling in all documentation

docs-0.2-r6 webpage:
https://alpinelinux.org

docs-0.2-r6 installed size:
4096 B

All you have to do is:

% doas apk add docs
(1/125) Installing mandoc-doc (1.14.6-r13)
(2/125) Installing docs (0.2-r6)
(3/125) Installing libseccomp-doc (2.5.5-r1)
(4/125) Installing busybox-doc (1.36.1-r31)
[...]

Likewise, it is trivial to get rid of all man pages:

% doas apk del docs

I would like to give a few other suggestions to the author, if we were to assume there is no docs metapackage:

Step 2: You could also cat /etc/apk/world (reference).
Step 4: combine from moreutils is more user-friendly than comm. I need to look up how to use comm every single time, whereas combine is much easier to remember.

Appendix #

This was also a typical xyproblem example:

What is the attempt? “I want to install, via apk add, all foo-doc packages for every foo package on my system”.
What is the end goal? “I want to install all man pages for the installed packages on my system”.

— § —

Reply via email

#alpine-linux #dev

★ Terraforming a Linode: hello world

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 23 Jan 2024 23:27:04 -0300

♠ I host my own Miniflux instance, which happens to be my favorite RSS reader. Currently it is hosted on Linode (Akamai Cloud) running Alpine Linux.

My current setup was performed manually. I was thinking that, for fun, it would be cool to fully automate it under the principles of IaC.

The current setup does not use any containers. I had proudly made it as KISS as possible at the time:

Linode is a very beginner-friendly (and cheap) VPS
Alpine Linux is a first-class citizen on Linode
There’s an apk package for miniflux
There’s an OpenRC¹ script for miniflux (so that it can be controlled via service)

For the first part of this automation we will look into provisioning a Linode with an Alpine Linux installation. In order to do so we will use HashiCorp Terraform.

Requirements #

Provision a new Linode
Deploy it in Europe
Use the smallest shape (a so-called Nanode)
Run Alpine Linux
Set it up with my public ssh key, which is hosted on Github

Terraform setup #

Install a provider for Linode: https://registry.terraform.io/providers/linode/linode/latest/docs

Scaffold it like this, in a main.tf file:

terraform {
  required_providers {
    linode = {
      source = "linode/linode"
    }
  }
}

Then run:

% terraform init

Generate a Linode API token

Go to https://cloud.linode.com/profile/tokens, create a new token called terraform. with the “Linodes” scope set to “Read/Write”.

Append this API token to main.tf:

provider "linode" {
  token = "<your token here>"
}

Add a linode_instance with the appropriate fields set according to the documentation:

resource "linode_instance" "coruscant" {
  label  = "coruscant"
  image  = "linode/alpine3.19"
  region = "eu-central"
  type   = "g6-nanode-1"
  authorized_keys  = ["<your ssh public key here>"]
  backups_enabled  = "false"
  watchdog_enabled = "true"
  booted           = "true"
}

Then run:

% terraform plan

“Plan” is basically a dry-run. Terraform will output what it intends to do, but nothing will be done yet.

Analyze the output and double check that it looks correct.

To actually perform the provisioning, run:

% terraform apply

Then confirm the prompt.

Within a few seconds (or maybe minutes), you should see your new Linode in the Linode Console.

We can test our deployment by ssh’ing to our new machine:

% ssh root@<public IP address> -i ~/.ssh/my_ssh_key
Welcome to Alpine!

The Alpine Wiki contains a large amount of how-to guides and general
information about administrating Alpine systems.
See <https://wiki.alpinelinux.org/>.

You can setup the system with the command: setup-alpine

You may change this message by editing /etc/motd.

Let’s take a pause to appreciate how lightweight it is:

localhost:~# df -h
Filesystem                Size      Used Available Use% Mounted on
devtmpfs                 10.0M         0     10.0M   0% /dev
shm                     487.8M         0    487.8M   0% /dev/shm
/dev/sda                 24.1G    238.1M     22.6G   1% /
tmpfs                   195.1M    268.0K    194.8M   0% /run

Only 238 MiB!

To deprovision it, run:

% terraform plan -destroy

If everything looks correct, run:

% terraform destroy

Warning: It turns out the “Linodes” scope was not enough to do the deprovisioning. I needed to create a new scope, with more permissions, in order to do so.

As you can see, terraform makes it very trivial to deprovision systems.

Bonus points: run terraform fmt to format your file. Never go out of style.

Tip: At any point you can run terraform validate to verify your main.tf file is syntactically correct.

Two things could be improved in the previous setup:

We could use authorized_users to pass in our linode username. If we add an SSH key to our linode account, then that key would be automatically deployed to the system, thereby removing the need to specify authorized_keys.
Alternatively, we could fetch our key from an URL endpoint with the use of the hashicorp/http provider, like so:

terraform {
  required_providers {
    http = {
      source = "hashicorp/http"
    }
  }
}

data "http" "thiagowfx_ssh_keys" {
  url = "https://github.com/thiagowfx.keys"
}

resource "linode_instance" "coruscant" {
  # ...
  authorized_keys  = compact([for line in split("\n", data.http.thiagowfx_ssh_keys.response_body) : chomp(line)])
  # ...
}

The “list comprehension” above does line splitting magic to convert them to a list of string, and the compact removes the empty new line at the end.

We could improve the example above even further.

For starters, let’s parameterize out the username to a variable:

variable "github_username" {
  type    = string
  default = "thiagowfx"
}

data "http" "user_ssh_keys" {
  url = "https://github.com/${var.github_username}.keys"
}

resource "linode_instance" "coruscant" {
  # ...
  authorized_keys  = compact([for line in split("\n", data.http.user_ssh_keys.response_body) : chomp(line)])
  # ...
}

We could then easily supply another username with -var:

% terraform plan -var github_username=torvalds

Note that the above example leverages string interpolation.

We could also extract the SSH keys list to its own “variable” (locals):

locals {
  ssh_keys = compact([for line in split("\n", data.http.user_ssh_keys.response_body) : chomp(line)])
}

resource "linode_instance" "coruscant" {
  # ...
  authorized_keys  = local.ssh_keys
  # ...
}

A more robust (and stable) way to query the key though is through the Github API:

data "http" "github_keys" {
  url = "https://api.github.com/users/${var.github_username}/keys"
}

locals {
  ssh_keys = jsondecode(data.http.github_keys.response_body)[*].key
}

Note that a typical response body looks like the following:

[
  {
    "id": "<id>",
    "key": "<ssh key>"
  }
]

API endpoint documentation: https://docs.github.com/en/rest/users/keys?apiVersion=2022-11-28#list-public-keys-for-a-user

If we use output instead of locals, then we can debug (inspect) it with terraform output.

And that’s it for today! In a future post, we will continue from here by using Ansible to install and set up Miniflux in our new Linode.

Alpine Linux does not use systemd. ↩︎

— § —

Reply via email

#alpine-linux #bestof #dev #terraform

★ Alpine Linux: New APKBUILD Workflow

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 23 Jan 2022 19:15:02 -0500

♠ This document describes my workflow to manage APKBUILDs for the aports repository in Alpine Linux.

Disclaimer #

First of all, this post is not a substitute to the AlpineWiki and it will likely get outdated at some point. In particular, refer to the following articles for up-to-date documentation that will outlive this blog:

This article is not a tutorial, as such it assumes you already know what an APKBUILD is and how to use abuild. In particular, you should have the alpine-sdk, atools and spdx-licenses-list packages installed in your system.

Structure #

I manage my packages with git. Create a GitLab account on https://gitlab.alpinelinux.org/, fork the aports tree, and git clone your fork.

The structure follows Alpine Linux repositories:

$ git clone https://gitlab.alpinelinux.org/alpine/aports.git && tree -L 1 aports
aports
├── CODINGSTYLE.md
├── COMMITSTYLE.md
├── README.md
├── community
├── main
├── non-free
├── scripts
├── testing
└── unmaintained

Bootstrapping #

I am going to illustrate with a package I added recently, sensible-utils:

Before you even begin, check if the package already exists, do a quick search in the Alpine Repositories¹.
Start by scaffolding a new APKBUILD from the base template:

$ cd aports/testing  # Always add new packages in testing/ first.
$ newapkbuild sensible-utils
$ cd sensible-utils
$ $EDITOR APKBUILD

Note: If you have a language-specific package (e.g. perl, python, rust), use the language-specific template instead of the base one. Run newapkbuild -h to list available templates. There are also some apkbuild-* helpers such as apkbuild-pypi and apkbuild-cpan.

Fill in APKBUILD metadata like pkgname=, url=, etc. Refer to the AlpineWiki for up-to-date best practices.
By doing so, I produced the following APKBUILD:

pkgname=sensible-utils
pkgver=0.0.14
pkgrel=0
pkgdesc="Utilities for sensible alternative selection"
url="https://packages.debian.org/source/sensible-utils"
arch="all"
license="GPL-2.0-or-later"
makedepends="po4a"
subpackages="$pkgname-doc"
source="http://ftp.debian.org/debian/pool/main/s/$pkgname/${pkgname}_$pkgver.tar.xz"
builddir="$srcdir/$pkgname.git"

build() {
	./configure --prefix=/usr
	make
}

check() {
	make -k check
}

package() {
	make DESTDIR="$pkgdir/" install

	# only works with update-alternatives, specific to debian
	rm "$pkgdir/usr/bin/select-editor"
}

sha512sums="
15ba996f811ab3a9c1f5726f35766d74aafdf925c5c2392b33c6643d6c439796a742f9d0f4625c79de640e6b5e4a6a032b768eb1bc4ac31b448f9767b0ceed44  sensible-utils_0.0.14.tar.xz
"

Note: $srcdir refers to the src/ directory within sensible-utils. $pkgdir refers to the pkg/ directory within sensible-utils.

If you’re used to Arch Linux PKGBUILDs you’ll notice a striking similarity to APKBUILDs. I highlighted a few notable differences in a previous post, My First APKBUILD.

Adjustments #

Generate the checksums with abuild checksum. It will automatically update the APKBUILD inplace.
Download and extract package files with abuild unpack.
ls src/ and check the directory structure. Update $builddir in your APKBUILD to match it. Usually it will be $srcdir/$pkgname-$pkgver, but sometimes tiny adjustments are necessary. In this case, it was $srcdir/$pkgname.git.
Then run abuild -r. If everything goes well, your package (and subpackages, if any) will be successfully built² in an isolated environment and placed in ~/packages (sensible-utils-0.0.14-r0.apk and sensible-utils-doc-0.0.14-r0.apk), however that doesn’t mean it is a decent package yet.
Run apkbuild-lint APKBUILD and abuild validate³ to lint your package and catch common errors. Fix the errors, if any.

Request feedback if needed #

If the package is only relevant to you, stop here. git commit, git push, and then you’re done. Install the package with doas apk add <pkg>.

Otherwise, if the package might be potentially useful to other Alpine users, you could consider uploading it to the aports repository.

Before you do so, stop for a moment and make an honest judgment whether this is a high quality package and whether you’re confident it is clean and polished enough, following the best practices documented in the Wiki. The answer doesn’t need to be positive, it’s perfectly OK to commit mistakes and everyone is a newbie at some point.

If the answer is negative, or if you’re new to this process and would like some help, fear no more! There are at least two decent community resources wherein to ask for help:

#alpine-devel on OFTC IRC Drew DeVault wrote a good post about IRC etiquette.
alpine-devel mailing list.

If you’re part of any other community (e.g. Reddit, Discord) feel free to ask therein as well. Avoid posting everywhere though, pick one community, draft your post and then patiently wait.

Publish your package #

If all is well, it’s time to publish your APKBUILD. Follow the up-to-date steps at https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Code_review. There are basically two options:

Send a gitlab merge request (MR). This follows the standard git forge workflow (GitHub / BitBucket / GitLab) wherein you fork the main repository, create a branch in your own clone, push it and then initiate a pull request⁴.
Alternatively, send an email with your patch to the aports mailing list with git send-email:

$ git config sendemail.to "alpine-aports@lists.alpinelinux.org"
$ git send-email -1  # Implicitly uses --to=alpine-linux@lists.alpinelinux.org as set above

Tip: The second approach has a steep learning curve, however once you figure it out it’s actually faster, simpler and more streamlined. Whenever a new email is sent to the aports mailing list, a MR is automatically created on GitLab.

Note: If you adopt the email workflow and need to send a follow-up to your initial patch, do not use --in-reply-to. Instead, create a new email thread. This is needed because as of this post new GitLab MRs are only created when new email threads are created. Replies to existing email threads do not update the MR patch.

And that’s all! Other useful tips:

Use repology to look for preexisting packages in other Linux (or even BSD) distributions, it’s very handy as a starting point if you have no idea how to package a given package. In particular, Arch Linux PKGBUILDs are very similar to APKBUILDs. Gentoo EBUILDs and FreeBSD Makefiles are also reasonable approximations.
Use abump to bump pkgver in APKBUILD files if the package gets an update to a newer upstream release.
Use apkgrel to bump or reset the pkgrel value of your APKBUILD.
Use urlwatch to track upstream updates.

If you use https://duckduckgo.com/, query for !alpine sensible-utils. ↩︎
Package debugging is out of scope of this post. ↩︎
Update(2025-05-10): Previously: abuild sanitycheck. ↩︎
In GitLab it’s called Merge Request (MR). The list of all aports MRs is available on GitLab. ↩︎

— § —

Reply via email

#alpine-linux #bestof #dev

Alpine / Arch Linux: .apk-new and .pacnew files

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 18 Jan 2022 14:25:20 -0500

♠ As packages are upgraded over time, updated configs files under /etc may arise. Different package managers treat this issue differently.

Alpine Linux #

apk creates .apk-new files, which can be located and merged by running doas update-conf. Here is a recent example:

% doas update-conf
--- //etc/securetty
+++ //etc/securetty.apk-new
@@ -12,3 +12,6 @@
 tty11
 hvc0
 ttyS0
+ttyS1
+ttyAMA0
+ttyAMA1
New //etc/securetty available:
Quit, Next, Show diff, Edit new, Zap new, Use new (q/n/s/e/z/u) [s] u

Arch Linux #

pacman creates .pacnew files, which can be located and merged by running sudo pacdiff. Here is a recent example:

% sudo pacdiff
==> pacnew file found for /etc/sudoers
:: (V)iew, (S)kip, (R)emove pacnew, (O)verwrite with pacnew, (Q)uit: [v/s/r/o/q]

Tip: The pacdiff-pacman-hook-git package helpfully adds a pacman hook that automatically checks whether there are any due .pacnew files upon upgrading the system (pacman -Syu), being a simple and effective way to automate this maintenance task. It looks like this:

: Running post-transaction hooks...
(1/5) Reloading system manager configuration...
(2/5) Creating temporary files...
(3/5) Arming ConditionNeedsUpdate...
(4/5) Registering Haskell modules...
(5/5) Reviewing .pacnew files...

/etc/sudoers.pacnew ⟶   /etc/sudoers
────────────────────────────────────────────────────────────────────────────────

────┐
76: │
────┘
 ##
 ## User privilege specification
 ##
-root ALL=(ALL:ALL) ALL
+root ALL=(ALL) ALL

 ## Uncomment to allow members of group wheel to execute any command
-# %wheel ALL=(ALL:ALL) ALL
+# %wheel ALL=(ALL) ALL

 ## Same thing without a password
-# %wheel ALL=(ALL:ALL) NOPASSWD: ALL
+# %wheel ALL=(ALL) NOPASSWD: ALL

 ## Uncomment to allow members of group sudo to execute any command
-# %sudo    ALL=(ALL:ALL) ALL
+# %sudo    ALL=(ALL) ALL

 ## Uncomment to allow any user to run sudo if they know the password
 ## of the user they are running the command as (root by default).
 # Defaults targetpw  # Ask for the password of the target user
-# ALL ALL=(ALL:ALL) ALL  # WARNING: only use this together with 'Defaults targetpw'
+# ALL ALL=(ALL) ALL  # WARNING: only use this together with 'Defaults targetpw'

 ## Read drop-in files from /etc/sudoers.d
 @includedir /etc/sudoers.d
 :: Searching databases for updates...
 :: Searching AUR for updates...
  there is nothing to do

— § —

Reply via email

#alpine-linux #dev

★ Alpine Linux on Raspberry Pi: Diskless Mode with persistent storage

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 15 Jan 2022 23:18:56 -0500

♠ Use case: Given an Alpine Linux diskless¹ installation meant for a Raspberry Pi setup, we would like to add a persistent storage component to it to make it survive across reboots.

Goal #

The Alpine Linux Wiki covers most of the installation process, hence I will only document the bits that were lacking and/or confusing therein.

My use case is the following:

Given a Raspberry Pi 3B with an old 4GiB SD Card as CF storage², install Alpine Linux in diskless mode. Find a way to preserve modifications in /etc and /var, as well as any installed packages through its apk package manager.

Let’s follow the steps outlined in the wiki.

Copy Alpine to the SD Card #

Grab the SD card and install Alpine Linux in it.

Alpine provides officially supported images designed for the Raspberry Pi.

Most Linux distributions provide an .iso or .img file to be installed with a tool like Balena Etcher, Rufus, Raspberry Pi Imager or plain dd³.

Alpine is not like most Linux distributions: Instead, it provides a .tar.gz archive with files that should be copied directly to the SD card. Grab the latest version (3.15 at the time of this post) from https://alpinelinux.org/downloads/. There are 3 options:

armhf: Works with all Pis, but may perform less optimally on recent versions.
armv7: Works with the Pi 3B, 32-bit.
aarch64: Works with the Pi 3B, 64-bit.

I opted for aarch64 to make it 64-bit, but armv7 would also have worked well for my setup. In fact, Raspberry Pi OS (Debian) uses armv7 (32-bit) at the time of this writing.

Before copying files over, format the SD Card. As I was doing this from a Windows machine because it was the only one I had readily available with a SD card slot, I just used the native Windows Disk Management tool to do so. I decided to allocate a 100MB⁴ FAT32 partition. The rest of the SD card would be blank for now. Alpine is surprisingly small, 100MB was more than enough for the kernel and other needed files.

Once the SD card is formatted, copy the files over to it. It turns out Windows cannot extract tarballs (.tar.gz); a tool like 7-zip should do the job. Copy the files over to the root of the newly allocated FAT32 partition, and then safely eject the SD card.

Boot Alpine from the SD Card #

The next step is to insert the SD Card into the Pi and then boot. I had some trouble in this step and eventually figured out I didn’t mark the primary FAT32 partition as bootable. Unfortunately it’s not straightforward to mark the partition as bootable from Windows. On a Linux machine there’s a wide array of tools to do so: fdisk, cfdisk (TUI), sfdisk (scriptable fdisk), parted, gparted (GUI) are some of them. I worked around that by installing Raspberry Pi OS on the SD card with the Raspberry Pi imager, and then overwriting it with the Alpine files. This works because the Raspberry PI OS installation marks the FAT32 partition as bootable.

Install Alpine #

Installing Alpine is well documented in the wiki thus it won’t be covered here. It basically comes down to invoking setup-alpine, which then invokes other setup-* scripts.

Keep in mind we’re not really “installing” Alpine as this is a diskless installation. A more accurate term here would be “configuring”.

Before invoking the installation script, I created a second primary partition in the SD card, set to ext4:

# Configure networking to get working internet access.
% setup-interfaces

# Install some partitioning tools.
% apk add cfdisk e2fsprogs

# Create a second partition (mmcblk0p2) and write it.
% cfdisk /dev/mmcblk0

# Format the partition as ext4.
% mkfs.ext4 /dev/mmcblk0p2

# Mount the partition under /media.
% mount /dev/mmcblk0p2 /media/mmcblk0p2

The installation is straightforward, we just need to pay attention to a few select steps:

setup-disk: Select none to ensure a diskless installation⁵.
setup-apkcache: Select /media/mmcblk0p2/cache to persist downloaded apk packages.
setup-lbu: Edit /etc/lbu/lbu.conf and set LBU_MEDIA="mmcblk0p2". Note: Do not add /media as it is implicit.

Once the installation is complete, run lbu commit to persist the changes in the second partition. Once you do so, a <hostname>.apkovl.tar.gz⁶ file should materialize on /media/mmcblk0p2/.

This is a good moment to reboot. Before we do so, let’s cache the packages we had previously downloaded.

# Cache packages.
% apk cache download

% reboot

After the first reboot #

If everything worked as expected, once you reboot all your previously installed packages should have been preserved and automatically restored / reinstalled, as well as your modifications done to /etc.

From this point on, whenever you install a new package that you want to be preserved for subsequent reboots, run lbu commit afterwards. For example:

% apk add vim
% lbu commit

If you would like to see what is going to be committed, run lbu status or lbu diff before doing the actual commit. Whenever you commit, /media/mmcblk0p2/<hostname>.apkovl.tar.gz gets overwritten with your most recent modifications.

It’s possible to keep more than one backup file by changing BACKUP_LIMIT= in /etc/lbu/lbu.conf. This is specially handy if you decide to revert to an earlier system snapshot / state later on. The stock config looks like this:

# what cipher to use with -e option
DEFAULT_CIPHER=aes-256-cbc

# Uncomment the row below to encrypt config by default
# ENCRYPTION=$DEFAULT_CIPHER

# Uncomment below to avoid <media> option to 'lbu commit'
# Can also be set to 'floppy'
# LBU_MEDIA=usb

# Set the LBU_BACKUPDIR variable in case you prefer to save the apkovls
# in a normal directory instead of mounting an external media.
# LBU_BACKUPDIR=/root/config-backups

# Uncomment below to let lbu make up to 3 backups
# BACKUP_LIMIT=3

Tip: You can find the list of all explicitly installed packages in /etc/apk/world.

The last piece: make /var persistent #

There are three natural ways that come to mind to make /var persistent:

A) Separate partition (or file) #

Instead of two partitions (FAT32 and ext4), create 3 partitions: FAT32, ext4 and ext4. Use the latter one to mount /var on, saving this information in /etc/fstab. The main disadvantage of this setup is that you’ll need to allocate a fixed amount of space of each of the ext4 partitions and it may be difficult to figure out how to split the space between them.

A variant of this approach is to just create the third partition as a file:

# 500MB file
% dd if=/dev/zero of=/media/mmcblk0p2/var.img bs=1M count=500 status=progress
% mkfs.ext4 /media/mmcblk0p2/var.img
% mount /media/mmcblk0p2/var.img /var

This works because the Linux kernel supports mounting files as if they were device blocks, treating them as loop devices (pseudo-devices).

I don’t like these approaches because they shadow the preexisting /var from the boot media, which in turn messes up with existing services that use it such as cron: % crontab -l would fail. One workaround would be to mount a /var subdirectory instead: for example, /var/lib/docker for docker.

B) Bind mount #

This one is straightforward:

% mount --bind /media/mmcblk0p2/var/lib/docker /var/lib/docker

The actual partition lives in the SD card, however we make a bind mount under /var, which is like an alias. From Stack Exchange:

A bind mount is an alternate view of a directory tree. Classically, mounting creates a view of a storage device as a directory tree. A bind mount instead takes an existing directory tree and replicates it under a different point. The directories and files in the bind mount are the same as the original. Any modification on one side is immediately reflected on the other side, since the two views show the same data.

C) Overlay mount #

From ArchWiki:

Overlayfs allows one, usually read-write, directory tree to be overlaid onto another, read-only directory tree. All modifications go to the upper, writable layer. This type of mechanism is most often used for live CDs but there is a wide variety of other uses.

It’s perfect for our use case, which uses a live bootable SD card for Alpine. It blends the preexisting, ephemeral, in-memory /var with the persistent in-disk /var.

I wanted to mount /var directly but found it to be problematic for the same reasons mentioned earlier, therefore I just went with /var/lib/docker instead:

# Create overlay upper and work directories.
% mkdir -p /media/mmcblk0p2/var/lib/docker /media/mmcblk0p2/var/lib/docker-work

# Add mountpoint entry to fstab. Note: The work dir must be an empty directory in the same filesystem mount as the upper directory.
% echo "overlay /var/lib/docker overlay lowerdir=/var/lib/docker,upperdir=/media/mmcblk0p2/var/lib/docker,workdir=/media/mmcblk0p2/var/lib/docker-work 0 0" >> /etc/fstab

# Mount all fstab entries, including our newly added one.
% mount -a

Conclusion #

I opted for the third approach, using an overlay mount, it was the most seamless one. A bind mount would have been fine as well.

The final setup works surprisingly well:

Alpine Linux is very lightweight and runs mostly from RAM
apk cache is persistent to the ext4 partition
/var/ is persistent to the ext4 partition
lbu commit persists changes in /etc/ and /home/ in the ext4 partition
Every reboot fully resets the system sans persistent components above

References #

Running (almost) fully from RAM. ↩︎
CF = Compact disk. ↩︎
On Linux I’d usually opt for dd, on Windows the Raspberry Pi Imager is a sensible choice. ↩︎
100MB is overly conservative, but keep in mind I had a very small SD Card, with only 4GiB storage. 250MB or even 500MB should be a more sensible default if you have a bigger SD Card (e.g. 32GiB). ↩︎
An alternative is to select data disk mode, but it didn’t work for me. ↩︎
ovl is short for overlay. Not to be confused with vol for volume. ↩︎

— § —

Reply via email

#alpine-linux #bestof #dev

Alpine Linux: apk logs with etckeeper

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 10 Jan 2022 23:14:43 -0500

♠ apk(8) is the Alpine Linux package manager. Surprisingly, it lacks native logs. In this post we will learn how to work around this limitation.

In a distribution like Arch Linux that uses pacman(8), one would typically find logs in /var/log/pacman.log. You would expect Alpine Linux to follow suit and provide some /var/log/apk.log or similar, however that’s not the case.

Logs are nowhere to be found, even in the apk-* man pages. I double-checked by asking on the #alpine-linux IRC and someone confirmed this is indeed the case, and there’s an (unconfirmed) possibility the next generation of apk may add logging support.

Meanwhile, we will use etckeeper(8) to overcome this limitation.

etckeeper: set-up #

etckeeper is

a collection of tools to let /etc be stored in a git, mercurial, bazaar or darcs repository. This lets you use git to review or revert changes that were made to /etc. Or even push the repository elsewhere for backups or cherry-picking configuration changes.

by Joey Hess.

It is available in the Alpine Linux repositories, just install it:

% apk add etckeeper

No configuration is needed, it works out-of-the-box, thanks to a post-install hook to initialize the git repository, and an apk commit hook to update it upon apk package operations.

etckeeper: viewing logs #

Just run git log as root. Root privilege is necessary because the git repository is initialized under /etc/etckeeper. Pick your poison:

$ GIT_DIR=/etc/etckeeper doas git log

$ doas git -C /etc/etckeeper log

$ (cd /etc/etckeeper && doas git log)

Here’s what a typical log looks like, courtesy of apk-autoupdate(1)¹:

commit f06255c4be4657481082406b2050ecd88e3da768
Author: root <root@localhost.localdomain>
Date:   Tue Jan 11 00:00:24 2022 -0500

    committing changes in /etc after apk run

    Package changes:
    -libeconf-0.4.2-r0
    -libeconf-doc-0.4.2-r0
    +libeconf-0.4.4-r0
    +libeconf-doc-0.4.4-r0
    -mtools-4.0.36-r0
    -mtools-doc-4.0.36-r0
    +mtools-4.0.37-r0
    +mtools-doc-4.0.37-r0
    -perl-io-socket-ssl-2.073-r0
    -perl-io-socket-ssl-doc-2.073-r0
    +perl-io-socket-ssl-2.074-r0
    +perl-io-socket-ssl-doc-2.074-r0
    -py3-idna-3.3-r1
    +py3-idna-3.3-r2
    -py3-jinja2-3.0.1-r1
    -py3-jinja2-doc-3.0.1-r1
    +py3-jinja2-3.0.3-r0
    +py3-jinja2-doc-3.0.3-r0

Which merely does apk upgrade, automatically. More details on the apk-autoupdate GitHub repository. ↩︎

— § —

Reply via email

#alpine-linux #dev

★ My First APKBUILD

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 07 Jan 2022 20:03:07 -0500

♠ In the same spirit of my first PKGBUILD and Ebuild, herein I will describe my first APKBUILD.

At a glance #

Alpine Linux package management is very similar to Arch Linux, with tiny differences:

PKGBUILD → APKBUILD: The filename is obviously different. Their format are very similar though, both of them are bash scripts with variables and functions. In particular, there’s check, patch, build and package.
cp /usr/share/pacman/PKGBUILD.proto → newapkbuild: Template versus scaffolding.
pacman → apk: The package manager is different.
makepkg -s → abuild -r: makepkg drives all things package building for pacman. abuild drives package building for apk.
makepkg -i → apk add <pkg>: makepkg can also drive package installations whereas abuild cannot, apk must be used.
namcap → apkbuild-lint (from atools) + abuild sanitycheck¹: Linters are different.
updpkgsums → abuild checksum: Generate hashes for package sources.

XKCD Courtesy of Randall Munroe

Other than that, the process of writing an APKBUILD is very similar to writing a PKGBUILD. In fact, the Arch repositories (especially the AUR) tend to be much more comprehensive than Alpine’s in terms of number of packages, so chances are if you want to write a new package for Alpine, check in Arch’s repos first, it’s a good starting point.

My first package: `fpp` #

fpp stands for ‘Facebook Path Picker’.

As of the time of this post, I maintain fpp-git in the AUR. It looks like this:

pkgname=fpp-git
pkgver=0.9.2.r130.ge0d5cfc
pkgrel=1
pkgdesc='TUI that lets you pick paths out of its stdin and run arbitrary commands on them'
url='https://facebook.github.io/PathPicker'
license=('MIT')
source=("${pkgname%-git}::git+https://github.com/facebook/PathPicker.git")
sha256sums=('SKIP')
arch=('any')
makedepends=('git')
depends=('python')
conflicts=("${pkgname%-git}")
provides=("${pkgname%-git}")

prepare() {
  cd "$srcdir/${pkgname%-git}"
  rm -r "src/tests"
}

pkgver() {
  cd "$srcdir/${pkgname%-git}"
  git describe --long --tags | sed 's/\([^-]*-g\)/r\1/;s/-/./g'
}

package() {
  cd "$srcdir/${pkgname%-git}"

  # library
  install -Dm755 "fpp" -t "$pkgdir/usr/share/fpp"
  cp -a src "$pkgdir/usr/share/fpp"

  # entrypoint
  install -dm755 "$pkgdir/usr/bin"
  ln -s "/usr/share/fpp/fpp" "$pkgdir/usr/bin"

  # documentation
  install -Dm644 LICENSE -t "$pkgdir/usr/share/licenses/$pkgname"
  install -Dm644 "debian/usr/share/man/man1/fpp.1" -t "$pkgdir/usr/share/man/man1"
}

PKGBUILD guidelines and instructions:

The equivalent APKBUILD I wrote looks like this:

pkgname=fpp
pkgver=0.9.2
pkgrel=0
pkgdesc="TUI that lets you pick paths out of its stdin and run arbitrary commands on them"
url="https://facebook.github.io/PathPicker"
arch="noarch"
license="MIT"
depends="bash python3"
subpackages="$pkgname-doc"
source="$pkgname-$pkgver.tar.gz::https://github.com/facebook/PathPicker/archive/$pkgver.tar.gz"
builddir="$srcdir/PathPicker-$pkgver"

check() {
	fpp --version
}

prepare() {
	default_prepare

	rm -r "src/__tests__"
}

package() {
	# library
	install -Dm755 "fpp" -t "$pkgdir/usr/share/fpp"
	cp -a src "$pkgdir/usr/share/fpp"

	# entrypoint
	install -dm755 "$pkgdir/usr/bin"
	ln -s "/usr/share/fpp/fpp" "$pkgdir/usr/bin"

	# documentation
	install -Dm644 LICENSE -t "$pkgdir/usr/share/licenses/$pkgname"
	install -Dm644 "debian/usr/share/man/man1/fpp.1" -t "$pkgdir/usr/share/man/man1"
}

sha512sums="
65b6b077f437bd642ebf94c55be901aabc73f7b9c89e4522c4f51970c4d63d744ad8fa29cac06816851f63bcb81d0480e61d405231c582e9aca0f4e650949a97  fpp-0.9.2.tar.gz
"

APKBUILD guidelines and instructions:

Build Comparison #

Let’s highlight a few similarities and differences in them, excluding the fact that one is fetched from git and the other one fetches a point release directly²:

package metadata, by the means of bash variables, are almost equivalent one-to-one — A notable difference is the architecture, Arch primarily supports x86_64 whereas Alpine has support for multiple architectures. When a package is architecture agnostic, Arch denotes it with any whereas alpine has both noarch and all, the latter is like any (=all architectures), the former means it’s agnostic (=e.g. a pure bash script or python package). — APKBUILDs use flat strings, whereas PKGBUILDs use bash arrays — Alpine encourages splitting larger packages into subpackages, as such APKBUILD has first-class support and syntactic sugar for that. -dev and -doc subpackages are very common. On the other hand, Arch tends to have monolithic packages in order to keep it simple, although it also supports subpackages. — Alpine supports setting $builddir whereas Arch doesn’t. As a consequence, it’s often unneeded to cd in build() and package() in Alpine, whereas in Arch one does need to manually change directories to $srcdir/$pkgname before building. — Alpine lacks optional dependencies, whereas Arch has optdepends.
Alpine enforces the use of check in test packages, otherwise it needs to be explicitly disabled and documented with !check in options=. That’s not the case in Arch.
check(), build() and package() are pretty much similar in both formats. $srcdir and $pkgdir are provided in both.
The ArchWiki is way more documented in terms of packaging guidelines and examples than Alpine’s. If you use DuckDuckGo, you can query for !aw <foo> as a bang shortcut to search directly in the ArchWiki.

Last but not least, in Arch one can install package tarballs³ with makepkg -i or pacman -U. In Alpine that approach doesn’t seem to be directly supported. The workflow is to add a local repository directory in /etc/apk/repositories (notice the last two lines):

# http://dl-cdn.alpinelinux.org/alpine/v3.15/main
# http://dl-cdn.alpinelinux.org/alpine/v3.15/community
# http://dl-cdn.alpinelinux.org/alpine/latest-stable/main
# http://dl-cdn.alpinelinux.org/alpine/latest-stable/community
http://dl-cdn.alpinelinux.org/alpine/edge/main
http://dl-cdn.alpinelinux.org/alpine/edge/community
http://dl-cdn.alpinelinux.org/alpine/edge/testing
/home/$USER/packages/community
/home/$USER/packages/testing

abuild will place the resulting package tarball in ~/packages, in this case:

$ ls ~/packages/testing/x86_64/fpp*
/home/$USER/packages/testing/x86_64/fpp-0.9.2-r0.apk
/home/$USER/packages/testing/x86_64/fpp-doc-0.9.2-r0.apk

…and then apk add fpp will automagically recognize it’s in there and install it. The advantage of this approach is that it keeps a local package repository around and it’s well integrated with apk, way differently from pacman that has no integration with the AUR at all. One could also possibly set up a local repository in Arch, for example, with ccm, but it takes extra steps and it’s not officially supported.

Upstream Contributions #

On Arch, to contribute a PKGBUILD upstream one just needs to create an account in the AUR. Armed with a git + ssh infrastructure, all you need to do is git push. There are no ACLs involved, anyone can do that⁴.

On Alpine there’s a bit more of politics involved⁵: Anyone can send a patch(1), either via mailing list or via a Gitlab MR (merge request). Patch works well with git send-email -1, being automatically cross-posted to a Gitlab MR. On the other hand the MR workflow is easier to be followed up on feedback from developers and other contributors (git push --force), and it’s also cross-posted, to the mailing list. An Alpine developer with the appropriate permissions must approve your patch/MR before it becomes available to other Alpine users.

Sadly at the time of this writing my patch hasn’t yet been approved (2 weeks later), however we’re in holiday season. This wouldn’t have been a problem in the AUR, where I could have just pushed it immediately, without any review. On the other hand the Alpine approach at least gives me some hope that the submitted packages have slightly higher quality than the average ones in the AUR, since they need to be manually reviewed/approved/vetted by at least one Alpine developer.

Install spdx-licenses-list to lint the licenses, it’s used by abuild sanitycheck as an optional dependency. ↩︎
The AUR tends to have both non-vcs and vcs versions of a software, whereas Alpine is focused a bit more on stability and tends to have non-vcs only. This is not a hard rule though, exceptions may exist. ↩︎
.tar.xz or, more recently, .tar.zstd. ↩︎
And this is one of the reasons why you should always inspect every PKGBUILD you install from the Arch User Repository, as it could have been tampered with and/or contain malicious code. ↩︎
I’ll leave it open-ended whether that’s a bug or a feature. Depending on the lens you see through, it could be considered either gatekeeping (bureaucracy, control) or sanity (quality, stability). It has pros and cons, and even those are arguable. ↩︎

— § —

Reply via email

#alpine-linux #bestof #dev

★ Alpine Linux: apk command not found hook

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 04 Jan 2022 16:25:51 -0500

♠ In this post we will learn how to define a command-not-found hook to the apk(8) package manager in Alpine Linux.

Sneak peek #

Before:

$ podman
zsh: correct 'podman' to 'pod2man' [nyae]? n
zsh: command not found: podman

After:

$ podman
zsh: correct 'podman' to 'pod2man' [nyae]? n
podman may be found in the following packages:
  <cmd:podman> podman-3.4.4-r1 x86_64 {podman} (Apache-2.0)

Preamble #

Whenever you type a command that is not in your $PATH, usually your shell will yell at you that it wasn’t found.

The typical workflow in this scenario is to use the search functionality of your package manager in order to find which package provides the binary you’re interested in.

In Alpine Linux, one would do:

$ apk search podman
podman-doc-3.4.4-r1
podman-remote-3.4.4-r1
podman-docker-3.4.4-r1
openscap-1.3.5-r3
podman-3.4.4-r1
podman-compose-0.1.5-r4
podman-bash-completion-3.4.4-r1
podman-zsh-completion-3.4.4-r1
py3-podman-3.2.1-r1
podman-docker-doc-3.4.4-r1
podman-openrc-3.4.4-r1
podman-fish-completion-3.4.4-r1

The output is a bit noisy, but with a bit of experience you could easily figure out the package you’re looking for is simply called podman, given the output above.

Surely this was an easy example, what if we tried something less obvious?

$ vidir
zsh: correct 'vidir' to 'vdir' [nyae]? n
zsh: command not found: vidir

There’s no vidir binary, then surely there’s a vidir package, right?

$ doas apk add vidir
ERROR: unable to select packages:
  vidir (no such package):
    required by: world[vidir]

Er, no. You’ll need to use search again:

$ apk search vidir
moreutils-0.67-r0

There it is, moreutils. Great piece of software, by the way¹.

What if we could automate this?

Automating command-not-found: 1st try #

In bash, one can define a command_not_found_handle function. In zsh, one can define a command_not_found_handler function. I know, why can’t it be the same function, right? Just one r in the way. Regardless of whichever shell you use, the point is that the function is invoked whenever you run a command that is not in the $PATH (or that isn’t a shell built-in).

In principle, you could do:

command_not_found_handle() {
  local cmd="$1"
  apk search "$cmd"
}

It’s a good first try, and it surely works as expected, but it can be a bit noisy sometimes. Look at the podman output above, it outputs several unrelated packages, none of which provide the podman binary other than its homonym.

Automating command-not-found: 2nd try #

In Alpine, we can do slightly better. apk(8) has the concept of providers:

$ apk list -P | awk '{print $1}' | egrep '<\w+:' | cut -f 1 -d ':' | cut -c 2- | sort -u
cmd
dbus
pc
so

-P above stands for --providers. This roughly means one can search for a package that provides a given shared library (so), or a package that provides a given binary (cmd), and so on. We’re interested in the cmd: provider.

If we tried it with podman, we would get the following output:

$ apk list -P -- "cmd:podman"
<cmd:podman> podman-3.4.4-r1 x86_64 {podman} (Apache-2.0)

Look at how much shorter and direct it is, compared to the 1st approach!

Here’s what it looks like if we try it with a binary provided by multiple packages:

$ apk list -P -- "cmd:docker"
<cmd:docker> docker-cli-20.10.11-r0 x86_64 {docker} (Apache-2.0) [installed]
<cmd:docker> podman-docker-3.4.4-r1 x86_64 {podman} (Apache-2.0)

It’s very easy to see that both docker-cli and podman-docker provide docker. If you just did a simple search, you’d get a lot of noise:

$ apk search docker
docker-bash-completion-20.10.11-r0
docker-cli-20.10.11-r0
docker-machine-driver-kvm2-1.24.0-r0
x11docker-6.9.0-r2
docker-volume-local-persist-1.3.0-r5
podman-docker-3.4.4-r1
openvswitch-2.12.3-r4
docker-engine-20.10.11-r0
docker-openrc-20.10.11-r0
dockerize-0.6.1-r9
docker-fish-completion-20.10.11-r0
openscap-1.3.5-r3
docker-py-5.0.3-r1
openvswitch-ovn-2.12.3-r4
docker-registry-openrc-2.7.1-r5
docker-doc-20.10.11-r0
rsyslog-imdocker-8.2108.0-r0
lazydocker-0.12-r2
docker-compose-bash-completion-1.29.2-r2
docker-compose-1.29.2-r2
py3-dockerpty-0.4.1-r4
docker-compose-zsh-completion-1.29.2-r2
docker-registry-2.7.1-r5
docker-credential-ecr-login-0.5.0-r2
dockerpy-creds-0.4.0-r3
docker-cli-compose-2.1.1-r0
docker-credential-ecr-login-doc-0.5.0-r2
podman-docker-doc-3.4.4-r1
docker-20.10.11-r0
docker-compose-fish-completion-1.29.2-r2
flannel-contrib-cni-0.15.1-r0
docker-zsh-completion-20.10.11-r0
docker-volume-local-persist-openrc-1.3.0-r5
docker-cli-buildx-0.7.1-r0

Packaging² it all together #

I wrote the following scripts, which I source in my respective interactive shells, to achieve this behavior out-of-the-box:

#!/bin/bash
# apk(8) from Alpine Linux command not found hook for bash

command_not_found_handle () {
        local cmd="$1" pkgs
        mapfile -t pkgs < <(apk list -P -- "cmd:$cmd" 2>/dev/null)

        if (( ${#pkgs[*]} )); then
                echo "$cmd may be found in the following packages:"
                printf '  %s\n' "${pkgs[@]}"
        else
                echo "bash: command not found: $cmd"
        fi 1>&2

        return 127
}

#!/bin/zsh
# apk(8) from Alpine Linux command not found hook for zsh

command_not_found_handler() {
        local cmd="$1"
        local pkgs=(${(f)"$(apk list -P -- "cmd:$cmd" 2>/dev/null)"})

        if [[ -n "$pkgs" ]]; then
                echo "$cmd may be found in the following packages:"
                printf '  %s\n' "${pkgs[@]}"
        else
                echo "zsh: command not found: $cmd"
        fi 1>&2

        return 127
}

The snippets above are snapshots intended for this post. I keep up-to-date versions of these files in my dotfiles repository, try out this query in case I ever move them elsewhere.

https://joeyh.name/code/moreutils/: moreutils is a collection of the unix tools that nobody thought to write long ago when unix was young. ↩︎
pun intended ↩︎

— § —

Reply via email

#alpine-linux #bestof #dev

Alpine-Linux on ¬ just serendipity 🍀

Alpine Linux: update timezone

★ New APKBUILD: LLM edition

Alpine Linux: clear /tmp upon reboot

'New' series: Raspberry Pi fun with DevOps, redux

PostgreSQL major version upgrade on Alpine Linux, redux

Problem statement #

★ .apk-new

Alpine Linux: usr-merge

★ zizmor

Alpine Linux: remove broken packages

Alpine Linux: Dockerfile: install package from edge

Alpine Linux: package is gone?!

★ Alpine Linux packaging: track new software releases

★ PostgreSQL major version upgrade on Alpine Linux

Problem statement #

Procedure #

References #

★ Alpine Linux: the maintainer workflow

★ First Alpine Linux package in Community

Alpine Linux: install / pin old packages

Alpine Linux 3.21

★ New series: Raspberry Pi fun with DevOps

Intro #

Guiding principles #

New APKBUILD: argocd

End of life package info

apk autoupdate on alpine linux

Docker on Alpine Linux

Alpine Linux: How to install all manpages (idiomatically)

Solution #

Appendix #

★ Terraforming a Linode: hello world

Requirements #

Terraform setup #

★ Alpine Linux: New APKBUILD Workflow

Disclaimer #

Structure #

Bootstrapping #

Adjustments #

Request feedback if needed #

Publish your package #

Alpine / Arch Linux: .apk-new and .pacnew files

Alpine Linux #

Arch Linux #

★ Alpine Linux on Raspberry Pi: Diskless Mode with persistent storage

Goal #

Copy Alpine to the SD Card #

Boot Alpine from the SD Card #

Install Alpine #

After the first reboot #

The last piece: make /var persistent #

A) Separate partition (or file) #

B) Bind mount #

C) Overlay mount #

Conclusion #

References #

Alpine Linux: apk logs with etckeeper

etckeeper: set-up #

etckeeper: viewing logs #

★ My First APKBUILD

At a glance #

My first package: fpp #

Build Comparison #

Upstream Contributions #

★ Alpine Linux: apk command not found hook

Sneak peek #

Preamble #

Automating command-not-found: 1st try #

Automating command-not-found: 2nd try #

Packaging2 it all together #

My first package: `fpp` #

Packaging² it all together #