Quadlets aren't what I'd personally use for local dev. They are good for running a local headless persistent service. So I wouldn't use it for your service-under-test but they can be a good fit for supporting dev tools like a local package registry, proxy or VPN gateway.
The one gotcha I can think of not mentioned there is that if you run it as a non-root user and want it to run without logging in as that user, you need to: `sudo loginctl enable-linger $USER`.
If you don't vibe with quadlets, it's equally fine to do a normal systemd .service file with `ExecStart=podman run ...`, which quadlets are just convenience sugar for. I'd start there and then return to quadlets if/when you find that becomes too messy. Don't add new abstraction layers just because you can if they don't help.
If you have a more complex service consisting of multiple containers you want to schedule as a single unit, it's also totally fine to combine systemd and compose by having `ExecStart=podman compose up ...`.
Do you want it to run silently in the background with control over autorestarts and log to system journal? Quadlets/systemd.
Do you want to have multiple containers scheduled together (or just prefer it)? Compose.
Do you want to manually invoke it and have the output in a terminal by default? CLI run or compose.
Hey, thanks for taking the time to share your learnings and engage. I'm sure there are HN readers out there who will be better off for it alongside you!
(And good to hear you're leaving the LLMs out of the writing next time <3)
Thanks! Would be cool to have it packaged for alpine since firewalld requires D-Bus. There is awall but that's still on iptables and IMO at bit clunky to set up.
You haven't confirmed this (at least from the contents of the article). You did some reasonable spot checks and confirmed/corrected your understanding of the setup. I'd agree that it looks likely that it did not escape or gain persistence on your host but in no way have you actually verified this. If it were me I'd still wipe the host and set up everything from scratch again[0].
Also your part about the container user not being root is still misinformed and/or misleading. The user inside the container, the container runtime user, and whether container is privileged are three different things that are being talked about as one.
[0]: Not necessarily drop-everything-you-do urgently but next time you get some downtime to do it calmly. Recovering like this is a good excercise anyway to make sure you can if you get a more critical situation in the future where you really need to. It will also be less time and work vs actually confirming that the host is uncontaminated.
Configuration is backed by xml files in /etc/firewalld and /usr/lib/firewalld instead of the brittle pile of sticks that is the ufw rules files. Use the nftables backend unless you have your own reasons for needing legacy iptables.
Specifically for docker it is a very common gotcha that the container runtime can and will bypass firewall rules and open ports anyway. Depending on your configuration, those firewall rules in OP may not actually do anything to prevent docker from opening incoming ports.
Newer versions of firewalld gives an easy way to configure this via StrictForwardPorts=yes in /etc/firewalld/firewalld.conf.
As sibling mentioned, unless you or the runtime explicitly mount the docker socket, this particular scenario shouldn't affect you.
You might still want to tighten things up. Just adding on the "rootless" part - running the container runtime as an unprivileged user on the host instead of root - you also want to run npm/node as unprivileged user inside the container. I still see many defaulting to running as root inside the container since that's the default of most images. OP touches on this.
For rootless podman, this will run as a user with your current uid and map ownership of mounts/volumes:
> Sorry, but you have to run an auth server (matrix-authentication-service) if you want Element X to work.
This is a bit outrageous IMO. Actually breaking and deprecating the classic auth and requiring a new server component to keep the only actively supported client (which still can't properly manage keys or sessions on its own, like classic Element can, even as non-verified sessions are being disabled) is a bit rich.
Great you found something that works for you and that you managed to dodge the parts of the community that somehow managed to turn this into identity politics.
Still, the gaps are there and don't seem to be filled anytime soon, despite the progress you mention.
...While I have your ear: IME ReThink DNS often runs into bootstrapping problems since 1) preconfigured DNS servers are referenced by hostname, not IP 2) I can't find a way to separately configure server address and TLS name (making it impossible to configure DoH/DoT servers via IP).
So users often run into "catch 22" where they need existing DNS to resolve their DNS server... When roaming it may work fine for a bit until the local cache drops it, and so on.
Allowing to separately configure TLS hostname for TLS-enabled protocols, and having a preseeded list of IPs for bundled provider endpoints, would mean ReThink DNS could work reliably even in absense of existing DNS.
The currently latest stable release of Debian (13.1) ships a broken version of systemd-networkd which may break networking completely for affected users. Maintainer response is less than encouraging: https://bugs.debian.org/1112535
> There was absolutely no need to disturb RT and waste your time, as you have much more important things to take care of, as this is just a minor issue with a particular corner case of a custom config of an optional component. Anybody who is unable to deal with that should just stick to the default Debian components. The next stable update in ~2 months will contain a fix.
"minor issue with a particular corner case of an optional component" my ass.
---
If you are currently on Bookworm using systemd-networkd with VLANs and bridges, you may want to hold off on the Trixie upgrade until fixed systemd 257.9 is available.
Wayland is great and ready for (idk) 95% of users/use-cases.
There is a long tail of more-or-less critical stuff that depend on X11 and do not have working Wayland substitutes. While the tail has been shrinking for every year, it will be decades if ever until all can be realistically migrated. Consider the Lindy Effect and that some of these systems have been running for >10y already. Consider shared but secured environments at universities and research institutes. Consider obscure hardware incompatibilities and hardware-specifix performance issues which might never be fixed.
On the software side, acessibility aside, there are a lot of VNC and other remote-X setups out there with no viable replacement in sight (yet).
Alsa, pulseaudio, pipewire and jack can all coexist and so can display servers.
I understand GNOME and RedHat will do things their way. I understand distro and GUI framework maintainers wanting to reduce their load. I understand people who like Wayland, want it to succeed, and want to evangelize. I do not appreciate when it turns into tribalism, forcing of monoculture and insisting "X11 is deprecated".
---
OP is from 2023 but as they note in their update, the situation is fundamentally not that different 2y later. Are maintainers and decision-makers really sincerely imagining that a supposed deprecation and removal of X11 can be forced onto the wider community over a couple of years from now?
You can read anything you want into those if you want to. To me they reek weeb culture (as opposed to furry like everyone else jumps to - there are overlaps but they are distinct), 4chan trolling and lemmy more than anything. We can not know the intentions behind those engravings and they say nothing about which, if any, affiliation the shooter had. Could be a Luigi wannabe, could be a false flag to induce civil war.
"Unafilliated" seems like the most plausible assumption right now. Everyone pushing theories about shooter affiliation right now either has their own political agenda behind it and are doing so incincerly or are useful idiots serving the aforementioned.
The docs you need for quadlets are basically here: https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
The one gotcha I can think of not mentioned there is that if you run it as a non-root user and want it to run without logging in as that user, you need to: `sudo loginctl enable-linger $USER`.
If you don't vibe with quadlets, it's equally fine to do a normal systemd .service file with `ExecStart=podman run ...`, which quadlets are just convenience sugar for. I'd start there and then return to quadlets if/when you find that becomes too messy. Don't add new abstraction layers just because you can if they don't help.
If you have a more complex service consisting of multiple containers you want to schedule as a single unit, it's also totally fine to combine systemd and compose by having `ExecStart=podman compose up ...`.
Do you want it to run silently in the background with control over autorestarts and log to system journal? Quadlets/systemd.
Do you want to have multiple containers scheduled together (or just prefer it)? Compose.
Do you want to manually invoke it and have the output in a terminal by default? CLI run or compose.