Alpine Linux 3.15 | Hacker News Reader

Alpine Linux 3.15

alpinelinux.org

168 pointsprotecto90 comments

Cool that they switched to `doas` from `sudo`. Another great OpenBSD tool gaining more adoption.

What's the 2 minute summary of why doas is better?

Smaller, less features, ideally less vulnerabilities.

Although it is annoyingly and quite critically missing a replacement for `sudo -e` / sudoedit (or was last time I checked).

alias suedit=‘doas …’

That is not at all what sudoedit does.

Not at all? Might wanna brush up on the manpage. The temp file is a feature but not essential to getting work done.

> The temp file is a feature but not essential to getting work done.

The entire point of sudoedit is to reduce the attack surface, without that it's absolutely useless since you can just `sudo` whatever editor you prefer.

Exactly. And could be trivially implemented.

What is wrong with `sudo vim /etc/foo`? I feel that it's better than `sudo -e`, but would love to see an example where `sudo -e` is better.

`sudo vim` will not load your user's vimrc, sudoedit will

It will also run your entire editor as root, which may not be something you want.

I actually would prefer the editor binary to run as root, rather than have my VIM config available. Any malware that could replace my system VIM would already have access to do whatever it wants to anyway. But malware to alter my own VIM configuration has a much lower barrier to entry.

Which is arguable an attack vector. Depending on how careless the user is, there is far more likely a chance that malicious code is found in .vimrc than is found in the VIM executable.

sudoedit runs your editor as you, not root, so unless I'm misunderstanding you, no such attack surface exists.

They’re probably referring to the attack surfaces of the extensions you have loaded in your normal configuration, as opposed to the probably empty environment of root.

> What is wrong with `sudo vim /etc/foo`?

Aside from forcing vim onto innocent users?

> I feel that it's better than `sudo -e`, but would love to see an example where `sudo -e` is better.

It is way worse than `sudo -e`, because it runs the entire editor as root, whereas `sudo -e` runs a few file copies / move as root. So `sudo -e` has a significantly lower amount of stuff in the "secure zone", and thus, much in the same way `doas` is more secure than `sudo`, `sudo -e` is a lot more secure than running the entire editor.

It also works with anything you can set as $EDITOR.

Some editors (like vscode) will outright refuse to run as root by default.

  > Aside from forcing vim onto innocent users?

Actually, `sudo -e` forces VIM onto innocent users. You are free to `sudo nano` if that's your preference.

  > `sudo -e` runs a few file copies / move as root.

Interesting, thank you, I did not know that the editor is not run as root with -e. So presumably that means that it will have my environment, e.g. will run my .vimrc? Though that could be an attack vector too.

> Actually, `sudo -e` forces VIM onto innocent users

No, it does not. It runs whatever EDITOR is set to (technically the first set of SUDO_EDITOR, VISUAL, and EDITOR).

> So presumably that means that it will have my environment, e.g. will run my .vimrc?

That is correct.

> Though that could be an attack vector too.

Only on the specific file, which would usually be a lot more noticeable unless the attack specifically manages to recognise and target sudoedited files while closing the buffer.

  > Only on the specific file, which would usually be a lot more
  > noticeable unless the attack specifically manages to recognise
 > and target sudoedited files while closing the buffer.

I've seen far more sophisticated attacks than that. Though vimscript itself is kind of a barrier to entry ))

"sudo -e" prevents you committing a file with a syntax error, because that instantly locks you out of all sudo access.

The replies about security are interesting, but I think they are over-complicating this!

On the one hand, I get that not everybody needs all the features of sudo, but on the other.... Sudo is way more useful than doas. If you really go through all its functionality, you start using it in ways you didn't think to before.

You can have a custom AuthZ solution and automatically inherit sudo permissions based on groups. It supports a configurable askpass. You can background jobs, change working directory, selectively pass or set environment variables, set $HOME, use a login shell, preserve origin groups, use a chroot, read a password from STDIN, override the shell, set a timeout. And of course the sudoedit features.

I know we all like programs that "do one thing well", but sometimes the best way to support all the use cases we want is a big honking program.

     >cat /etc/doas.conf

     permit persist :wheel

Now all the users belonging to wheel can run stuff as root. Done.

Sure this is a nice and concise (yet somewhat trite) example, but this can be done easily with 1 line in sudoers as well (and is usually configured like this by default anyway).

Not that doas isn't great, but this particular reason isn't that compelling (to me).

That's the entire configuration. It does not need documentation that starts with a quick introduction to EBNF, the whole thing it's about as simple as you could possibly make it. Granted, if you're just doing small edits to existing sudo config it might not matter too much, but I find it appealing to be able to read and understand the entire configuration file and add new configuration easily.

Configuring sudo is such a footgun that it was deemed necessary to fork a text editor purpose-built for only modifying sudo configurations (visudo).

So, that’s why not sudo. As for why doas, see:

* https://flak.tedunangst.com/post/doas

* https://flak.tedunangst.com/post/doas-mastery

visudo isn't a fork, it just locks the sudoers file against concurrent edits, runs whatever standard editor you want, waits for it to finish, and validate the new file before committing it to the real location.

I can agree that process is too complex, but they're not maintaining a fork of vi for that purpose.

> and validate the new file before committing it to the real location

Controversial take: i think that it'd be really good to have EVERY configuration file have something like that. For example, if i'm working on a long bit of configuration for fstab, cron, Apache2, Nginx, Tomcat or any other pieces of software, i'd want to see whether everything i've written will be considered valid ahead of time, e.g. a "dry run" of sorts. A bit like we have language servers for VS Code, we could have validation servers as well, for configuration.

That said, i don't think we'll ever have that, since it's easier to just write code in an ad-hoc manner, as opposed to extracting validation of configuration as a separate bit of code that can be called from some CLI, not just at runtime, especially since many configuration files allow nested includes.

Regardless, thinking more about models and validation methods would be nice, e.g. XSD. If we leverage type systems in programming languages, we might as well do that at an operating system level - something like shellcheck built in. A validation handler for every file type.

Nginx does have a "dry run" mode for checking configs (unless that something external - like unresponsive servers - is experiencing problems).

Thanks for this information, had to actually look it up and check, seems like that's indeed true: https://www.nginx.com/resources/wiki/start/topics/tutorials/...

Here's an example:

  $ docker run --rm nginx:1.20.2 nginx -t -g "daemon off;"
  
  /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
  /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
  /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
  10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
  10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
  /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
  /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
  /docker-entrypoint.sh: Configuration complete; ready for start up
  nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
  nginx: configuration file /etc/nginx/nginx.conf test is successful

Every piece of software should definitely have something like that! Ansible is another piece of software that i can recall with an explicit dry mode run like that: https://docs.ansible.com/ansible/latest/user_guide/playbooks...

I'm familiar with Alpine in container scenarios, but is there any mileage to using it as a day-to-day desktop distro?

Not really. It's not designed for that. It's designed to be as lightweight as possible.

also, instead of Glibc, it uses musl, which although is supposed to be binary-compatible, does have some gotchas, so the larger the system, with more apps and libraries running on it expecting glibc, will have issues.

musl really becomes a pain if you work a lot with Python. You can't use wheels, which means you will have to compile everything yourself, which sometimes takes ages, and you're not guaranteed that it won't have unnoticeable errors.

My biggest issue was with the 3.12 -> 3.13 transition, when musl got upgraded to 1.2 and with it "musl 1.2 uses new time64-compatible system calls". This broke so many things for me without me knowing, like nginx having as the datetime in the logs the unix epoch. All continued to work, but everything related to timestamps was completely messed up, on 32 bit OS due to running on Raspberry Pis.

This was the moment where I decided to stick to debian-slim, and only very specific containers will continue running on Alpine. Before that it was my default container OS.

Also there is no reliability in packages getting updated, sometimes they just disappear in the next version. But these things are rare occurrences, which only are then nerve wracking when you are confronted with them. For 90% of the cases Alpine is one of the most awesome container OSs.

> You can't use wheels

musl wheel support was added some time ago:

https://github.com/pypa/packaging/releases/tag/21.0

No idea how many packages actually build musl wheels though. From a quick glance at least cryptography and lxml has musl wheels.

Unfortunately, Alpine patched their version of Python in a way that is incompatible with musllinux wheels so we are back to where we started until Alpine Linux 3.16 in 2022[1].

EDIT: I spoke too soon. Apparently, they have decided to amend the patch in a way that is both backwards-compatible and compatible with musllinux wheels[2]. Hopefully, it will roll out soon.

[1]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13227 [2]: https://bugs.python.org/msg406939

thanks, I had been scouring the internet for something on this. Didn't expect to come across it on HN

This will be addressed though

The fix has now been pushed to the 3.15 branch.

This still works for me:

https://github.com/insightfulsystems/alpine-python/blob/5a34...

But I haven’t tested today’s version yet.

OpenBSD went through a similar transition, except they didn't even try to maintain ABI compatibility. See https://www.openbsd.org/55.html and https://www.openbsd.org/faq/upgrade55.html, the latter describing the rare "flag day" event. Long term this was good for OpenBSD as it saved a ton of unnecessary cruft and complexity that would have haunted OpenBSD for years if not decades, endlessly taxing developers' time, especially of core developers. And it was an inducement for all developers, those working on OpenBSD (core and ports teams) as well as those targeting OpenBSD, to carefully review code for 64-bit time_t safety. But it necessarily required that the broader community shoulder a large part of the transition burden.

Sometimes it's better to power through with a massive labor effort than to try to use fancy hacks to shield people from latent problems. All things considered, it doesn't sound like the Alpine transition was that bad. But it's the type of thing that most Linux users and developers are not accustomed to, at least those who don't remember the very early years. Ironically, musl libc might not exist if glibc hadn't accumulated so much complexity trying to maintain strong ABI compatibility.

IMO, small prices to pay for free software and Free Software.

There is a lot of affinity between Alpine and OpenBSD. That's a good thing in my book.

I build my entire development stack from source and don't rely on OS packages for it, and I absolutely refuse to use binary compiled Python wheels, so Alpine's lack of them is actually a feature as far as I am concerned. I dealt with the musl quirks.

Actually, you can run most wheels just fine if you do this: https://github.com/insightfulsystems/alpine-python/blob/5a34...

You just need to know how :)

I did know this, but it wasn't 100% reliable, see https://github.com/grpc/grpc/issues/18150

Regarding the "runs just fine", this is not guaranteed. I certainly do check if it is working, and if it is, and it is a small service or just a containerized tool, then I'll use it. Like using GDAL to perform some reprojections and renderings where a throwaway container is called from a shell script, if it works once, I'll keep using it, but I won't use it to run a Python server which also makes use of Matplotlib and other big dependencies.

It is designed for desktop use, actually. Many of Alpine's developers use it as their primary PC distro :)

I never read anywhere that it was designed for desktop, but they've always included the packages. Firefox was pretty much the only browser available and was unusable for years because of some math issues with font rendering if I remember correctly. ( I have attempted to daily drive it from time to time). In this regards it's pretty obvious Void Linux is more desktop focused.

Alpine is supposed to be a small, stable and secure general purpose base.

I use it as a bare metal OS on my blog server and it's great in that scenario too. I've personally found the libc stuff makes it really inconvenient to use as a desktop OS, unfortunately. You have to jump through hoops to get something like VSCode to "just work".

Software like VS code is in direct conflict with the way alpine does things. Alpine on the desktop is certainly not for everyone, but for some use cases it works great.

I use it as my primary OS. You have to do more setup work, there’s much less documentation/help online than more popular distros, and running proprietary software (which usually links to glibc) is probably not worth the effort. This is mostly fine for me, as I don’t do much on my computer aside from code and use a web browser — the only difficulty is most streaming video unfortunately requires Widevine. Given those limitations, I’m very happy with it: it’s very simple and I have a much better understanding of what is installed/running and why.

Yeah, coding (in terminal windows only) and Web browser is what I'm thinking of using it for. I might just have to plunge in and give it a go, thanks! :)

postmarketOS is based on it. I tried it on my PinePhone, it works, but in the end I went with Arch Linux ARM.

I use it as a daily driver on my Raspberry Pi. Since the community is small the package repositories are a bit small as well, and I occasionally have to build stuff by hand (painful on the Pi). Add musl to the ARM platform and most binaries in the wild won't run. However, musl and apk means the Alpine is a lot faster than, say, Raspbian or Arch.

I love Alpine on the Raspberry Pi Zero family. Not only does this create a durable and speedy ramdisk appliance, but experience configuring and minimizing the build size translates to containers as well.

I use it on a headless thin client serving as a NAS/ printer server / media box etc. Works very well. Keep in mind that Alpine actually predates containers by many years. It originally started as a light-weight distro targeted at embedded stuff. And the roots are still there. https://heap.ovh/alpine-linux-on-fujitsu-futro-s520s720.html

Powers my router, running on an APU2. The run-from-ram-with-overlays configuration makes upgrades relatively painless.

I use it on my desktop:) It's a nice experience after a slight learning curve; I'm particularly fond of it supporting ZFS well without being Ubuntu. Musl libc is a potential pain point; I get most software from official repos or build from source, but ex. to run Steam I resorted to flatpak (which just shoves glibc in the container with the application).

For an average user, I'd guess they'd hit more issues with busybox than musl.

I hate how many incredibly useful and sane options and most of the time missing from busybox binutils... drivers me crazy.

Are there any (lightweight?) desktop distros built atop Alpine as a base?

If you care, just install the `coreutils` package and it'll overwrite the default symlinks and you'll get GNU coreutils by default.

Oh thanks, that's good to know they're available.

Yep:) If you found that useful, I'd suggest looking over all of https://wiki.alpinelinux.org/wiki/How_to_get_regular_stuff_w...

I use it as a daily driver. Here is my setup. Coreutils is included.

https://lamda-chops.bearblog.dev/alpine-linux/

I can't recommend it for desktop use, but it is possible to use it as such.

IMHO it really shines on dedicated, small VMs or for headless SBC use cases.

There's only 5 daemons running after the installation (provider in brackets, the installer asks which one for ssh and ntp): - init (OpenRC) - ssh (dropbear or OpenSSH) - ntp (chrony or busybox) - crond (busybox) - syslog (busybox)

The diskless mode it offers is ideal for SBC's or other use cases with SD-cards or such.

So it's niche seems to be with very lightweight or hardened servers.

I haven't used it as a desktop, but as a minimal VM for bastion SSH servers.

As long as you're OK with the limitations imposed by using musl, I think it's great on the desktop. I recently switched from Void Linux (glibc variant) and it's working very well. I run proprietary applications like Spotify, Steam, and Discord in Flatpak, and most of the rest from Alpine's repos.

One thing that surprised me is that KDE's software center gives package update notifications for Alpine packages OOTB, and the GUI Just Works(tm) for installing and upgrading.

I am using it as desktop, it does not do things i did not ask for, which i really appreciate. I get away with it easily because i only use xterm and Firefox for the graphical part.

I use Alpine as my server OS, with Alpine, Ubuntu and CentOS containers running on it. It works great this way too.

Not as a desktop but I use it on bare metal as my primary server. The main advantage is the absence of bloat, e.g. components like DBus or systemd that increase the attack surface. The use of musl vs. glibc does make some things more complicated, however.

> The main advantage is the absence of bloat, e.g. components like DBus

? Like most distros that start you off but nothing but a minimal base, you can choose whether to install DBus or not. Almost everyone using Alpine as a daily driver on their PC probably has DBus installed and enabled.

I use it as a daily driver. Here is my setup. Feel free to leave feedback for improvements!

https://lamda-chops.bearblog.dev/alpine-linux/

I'm using it on my laptop (Thinkpad X270) and it's great.

I don't think there's much credibility to saying it's not "meant to be used" as a desktop; since the packages available suggest to me there's clearly a bunch of people doing just that.

What you can expect is more manual setup (compared to say, OpenBSD, where things work really well out-of-the-box on this hardware). But I took this opportunity to set up an encrypted disk. This is with no "desktop environment", just a window manager and X.

I thought BusyBox would be a pain, but the GNU tools can be automatically installed. Same with musl, which was much less of a big deal than I thought. I can even suggest things feel faster with it, but it does mean staying within packages from the Alpine ecosystem.

I'd be interested if anyone is doing a glibc fork of Alpine (or a way to run the 'full fat' glibc seamlessly, like it does with the GNU tools). Also worth experimenting with Alpine's glibc emulation; I was amazed how good it was, as it runs almost all of a closed-source music production tool that I use.

I've just upgraded from 3.14 and everything seems to be running well. I'm always amazed how incredibly fast the package manager is (apk). If you think Arch's pacman is fast, this is still on another level.

Does anyone know where there are screenshots of this on the website? I like to see how a desktop looks before I try a new distro. Seems absent on the site

You can install any Desktop Environment you want.

You can do that in any distro. I think the OP refers to the fact that, usually the distro supplies some default config files for the DE which makes it look distro specific.

... except that it's command-line by default, so the DEs has whatever Gnome/KDE decided them to look (rather than adding wallpapers and such).

Alpine is a bare bones / DIY distro (like Arch); it'll look like whatever DE you install.

From what I understand of alpine, it's commonly used for Docker images to provide a lightweight distro for your apps vs using something like ubuntu or debian which may include more than what's required.

I don't believe it's intended to be used in a desktop environment, but I could be wrong.

This is false; you can install a variety of DEs from the repos.

Got it. Thanks for correcting me!

Yes, it's defintely used for Dockerizing apps. I've Dockerized several Ruby, Node and Elixir apps using Alpine at work.

Alpine is more of a command-line distro. It's compact design and lack of many dependencies make it ideal for virtual servers and containers. Personally I've been eyeing it for an install on a small ARM board as a music streaming server, which it seems quite suitable for. In this case I would still connect to it over the network, still with no GUI or desktop.

Did they break all things again ? (3.14 breaks lots of things for containers.)

Is Python totally DIY? Can't find it in the package search.

Try 'python3' or 'python2'.

The packages are either python3 or python2 for the language, and prefixed py2- or py3- for any of the packaged modules. https://pkgs.alpinelinux.org/ does support wildcards so you should find the packages using "python?" or "py?-*".

There is a pretty good set of maintainers/packagers that compile Python libs for Alpine, but if you stumble across one that doesn't have a binary built, you're going to have to install the whole build toolchain and get all the headers yourself. The pre-compiled manylinux* binary packages on PyPI aren't compatible with Alpine.

Try this:

https://github.com/insightfulsystems/alpine-python/blob/5a34...

Ah, so. Python2 is past the "pining for the fjords" stage, I should think.

    apk add python3

Reply on news.ycombinator.com