Replies: 8 comments 40 replies
-
then...
...you shouldn't. Use testing (it's actually rather stable): https://www.debian.org/doc/manuals/debian-faq/choosing.en.html#s3.1.5. |
Beta Was this translation helpful? Give feedback.
-
|
Hello random stranger from the internet. Debian maintainer and Red Hat developer here.
Well, that's a mandatory word of caution. You have several options when things break: roll back, apply a workaround, rely on commercial support, fix it yourself, etc. Strictly speaking, it can happen to Debian stable as well.
This is a very wild misconception, unfortunately. At least from anecdotal reports I would say that servers running Debian testing are much more common than servers running Debian stable.
Operating systems don't work like that, unfortunately. For example, out-of-distribution packages (I just checked the ones from docker.com) usually don't ship LSM policies (because it would be highly impractical). They might cause all sorts of havoc on one version and not on another one. Official Debian packages are tested (by e.g. autopkgtests) together with the matching distribution as a whole.
Right, no, don't do that, rather build from source.
Than this, sure, almost anything is better than that.
Yes, but I'm politely suggesting to them that maybe, just maybe, "I am using normal stable Debian 12 for my server." doesn't quite fit with "I want to use the latest podman". It's the same with Bash, the kernel, LibreOffice, KDE, or whatever other software a distribution might ship. Why should Podman be special in this regard? Debian maintainers of the Podman package are doing a big service to the community. Please use that as it was intended and designed. |
Beta Was this translation helpful? Give feedback.
-
Not should, but "if it would be possible to get new-ish podman without resorting to 3rd parties or compilation from source it'd be great". One major reason would be proper nftables support. Debian stable supports it, podman 5 supports it.
That's just ideological stuff. There are lots of server software that do exactly this. docker, nginx, grafana, whatever. "We have no resources to maintain our own repos for various distributions" is the valid reason, sure. But otherwise there's no reason to not use new packages in debian stable. That is unless glibc and kernel versions are compatible but since there are 3rd party packages compiled against bookworm, it doesn't look like an issue. |
Beta Was this translation helpful? Give feedback.
-
I'd still argue it's not "great" but better than the alternative of using whatever hack to make up for choosing the wrong version of a distribution. I don't think it's necessarily better than building from source, though.
So, again, you're talking to the Debian maintainer (as well as original author) of passt (provides pasta(1)) and also a (not very involved right now) netfilter/nftables developer, who is trying to make you realise that there are distributions just under your nose supporting all that. Just... use them please.
That's Debian philosophy. Call it what you want, but it's how Debian versions are designed. Fedora, RHEL and derivatives are slightly (but just slightly) different in this regard.
Things still rely on libc and use, you know... system calls.
Well, I just gave you a number of reasons. Please read. |
Beta Was this translation helpful? Give feedback.
-
That's irrelevant: https://en.wikipedia.org/wiki/Argument_from_authority
Try to understand what people are saying. Imagine that some dude (or dudesse) likes debian, likes apt, likes infrequent updates of their base system and overall stability. Please, stop this ridiculous debate.
That's covered in the next paragraph. |
Beta Was this translation helpful? Give feedback.
-
No, it has nothing to do with it. I'm doing, but you're talking. Call it what you want.
I'm not suggesting to nuke anything, or change distributions. You can just upgrade. It's done in minutes (seconds, if you go from, say, Alpine 3.21 to Alpine Edge). Infrequent updates is fundamentally incompatible with security. Please don't do that either because it has obvious, documented security implications. Even if you use Debian stable, please keep it updated.
Calling others' arguments ridiculous is not very professional or conducive to a productive discussion where participants feel comfortable.
I don't know exactly what's needed, but I know for sure that that's a lot. Just a quick example in terms of system calls: pasta(1) comes with a restrictive seccomp profile only allowing a given set of system calls, and different versions of glibc implement functions with different system calls. We recently had an example where glibc started allocating memory on plain strerror(), and pasta's seccomp profile doesn't like that. I can coordinate those changes with official distribution packages, but I clearly can't, without. I would need to compromise on security by making things less restrictive. Or look at this bug: https://bugs.launchpad.net/ubuntu/+source/passt/+bug/2077158 (by the way, the only open bug for any Debian or Debian-based package for passt). This comes from the fact that we overlooked an important AppArmor API detail as the API was changed. If we didn't stick to official packages, we would have a ton of those bugs. The only viable alternative, if I wanted to make out-of-distribution packages available, would be to avoid shipping AppArmor profiles altogether, which comes at the cost of security.
I can't write counter-arguments for every unproductive idea due to lack of time. |
Beta Was this translation helpful? Give feedback.
-
|
also see #17362 We have no resources to maintain our own repos for various distributions but you are welcome to step up and maintain them if that is important to you. |
Beta Was this translation helpful? Give feedback.
-
|
Just as a question. Is there a reason as to why the Debian and Ubuntu sources are so far behind? |
Beta Was this translation helpful? Give feedback.
-
|
They are not far behind: https://tracker.debian.org/pkg/podman. It's 5.3.2. Again, you should stop for a moment and read what Debian stable is: https://www.debian.org/doc/manuals/debian-faq/choosing.en.html#s3.1.3. |
Beta Was this translation helpful? Give feedback.
-
|
Yes I am wrong on that. Makes sense why the package on the stable repo is so old. |
Beta Was this translation helpful? Give feedback.
-
|
The reason why some software projects have their own repositories is usually compatibility (packages wouldn't be available otherwise) rather than encouraging users to divert from a distribution that is only tested as a whole. If you install packages from a different source, that's not Debian stable. And I think that this matters especially for Debian stable. Thanks to the valuable, hard work of package maintainers, Podman packages are properly integrated in Debian, instead. This is a big advantage because you have older packages in Debian stable, as they were meant to be, and updated packages in "testing" and "unstable". |
Beta Was this translation helpful? Give feedback.
-
|
Makes sense but e.g. docker does avoid it and therefore you get the latest version. this applies to ubuntu too. |
Beta Was this translation helpful? Give feedback.
-
Again, I don't think it's a good thing. People use Debian stable if they do not want to get the latest version. |
Beta Was this translation helpful? Give feedback.
-
|
makes sense. thats why i want to switch to. especially because of the shitty experience with ipv6 and nftables with docker. which seem 100x better with podman |
Beta Was this translation helpful? Give feedback.
-
Ubuntu also ships 5.3.2: https://packages.ubuntu.com/plucky/podman. |
Beta Was this translation helpful? Give feedback.
-
|
rpm based distro like alma linux ship 5.2.2. (makes sense ig as podman is by red hat and rpm based distro are based of rhel). and deb based distros like ubuntu or debian ship fairly old podman versions. even ubuntu 24.04 lts ships podman 4.9.3 and 22.04 lts ships 3.4.4 |
Beta Was this translation helpful? Give feedback.
-
I don't think there was a major difference in the dependencies needed for nerdctl (containerd/buildkit) or for podman... nerdctl-full-2.0.3-linux-amd64.tar.gz podman-full-5.3.1-linux-amd64.tar.gz There was no need to make a "full" distribution of docker, since it is already included in system and from the vendor. i.e. But I did not use static linking for podman. |
Beta Was this translation helpful? Give feedback.
-
Note that older releases ship older versions...
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
@afbjorklund I understand you're willing to help and I deeply appreciate it of course. What you do is simply great for this community and for the project, all across the board. But should we really encourage users to come up with "solutions" that will cause them continued troubles and everybody else unnecessary maintenance burden (see #25269 among dozens of examples) because they fundamentally misunderstand how Debian and Ubuntu versions work? I speak as a Debian maintainer rather than as a Red Hat developer here. |
Beta Was this translation helpful? Give feedback.
-
|
I think the users already know how to install the version that is supported by their release, they are explicitly asking if they can get a newer version from the vendor in the same way that they can get from docker. That is: switching from I don't think that changing distribution is the first solution that comes to mind, even though it is a valid path in some cases. Like when installing in a virtual machine (as in the Lima project), then it might be simple to go from Ubuntu to Fedora. But for many others, switching from "stable" to "unstable" might not be the desired outcome. For me it is perfectly fine to install newer software (normally applications) on top of an older operating system - but I understand it might be tricky for "system" software. But we can stop re-iterating the same topic and leave it as the FAQ it is. |
Beta Was this translation helpful? Give feedback.
-
Of course, they know. They couldn't have installed Podman in the first place. But from experience (including my own from many years ago, getting mad at Debian stable installed on a laptop), what a lot of users don't seem to realise, when dealing with Debian-based distributions, is that Debian stable (or equivalent) is really meant to ship (much) older packages for a reason, and installing newer packages on top isn't exactly a "stable" thing to do. For example, I had a look at Docker packages for Debian stable from docker.com and, unless I'm missing something, I can't find a trace of AppArmor profiles there. It would be impractical to ship them, of course. But the outcome doesn't quite fit what users would expect from Debian "stable", I suppose. And, on the other hand, Debian "testing" isn't Debian "crashing". Fedora Rawhide is perfectly usable as well. So, yeah, I think mentioning it might help at least in some cases. See #25269 (reply in thread).
It's not so much about "changing distributions". You can upgrade Debian from stable to testing, Fedora 41 to Rawhde, Alpine 3.18 to Alpine Edge in a matter of seconds or minutes.
Sure. Don't get me wrong, I think that that's immensely helpful as well. |
Beta Was this translation helpful? Give feedback.
-
|
Hello everyone! o) I just like to agree to the guys who vote for more flexibility. I run Debian stable to get an overall stable "experience", but there are specific applications, for which I want to run a more recent version, because it is kind of "natural"?! o) When it's time to upgrade your TV, nobody forces you to overhaul your whole living room at the same time. A generic hardware update is a nice example as well. If I want a faster, better hard drive, I plug that into the stable machine I am already running. If I want a more capable GPU, I put that in place instead of replacing PSU, RAM, Mainboard, Storage etc.. I don't really get (yet.. o), why updating parts is more easy with hardware, than it is with software packages on Linux. I admit, I do "Windows" for 20-30 years now, Windows comes in "stable", "rolling" and "testing" by default - it's all in one, because it keeps multiple versions of runtimes around for backward and forward compatibility, which allows to run Windows installations for 10 years no problem, no need to reinstall because you want to run very old or very new things. I had to start compiling things on my own and make use of AppImages to get around "package not available" problems, but compiling things is tough terrain at times. My current Podman setup is running on Debian "stable", mixed with alvistack repository, direct binary download of "pasta", some things pulled from "testing" and "backports" and oh boy, what a Frankenstein setup this is! o) I would love a simple download of "Podman" from a stable or development branch, put that in place and be fine. Getting a recent version of netavark is where I have to give in now and reinstall and reconfigure my VM template from scratch it seems. I cannot just pull the "netavark" package from testing, because it requires a unreasonable(?) high libc version. I regularly encounter problems related to libc version requirements, it is kind of a pain in the rear. o) Why does half the world compile against most "recent"? If I remember correctly, it was the "Pix" developer or a member of the "Linux Mint" team, who recently suggested to me to ditch my fully fletched Debian Desktop installation and "simply" reinstall Linux Mint if I want to make use of a more recent "Pix" version (which is an image viewer). My jaw kind of dropped when reading his suggestion, swapping the OS to run an image viewer. Well, I don't know, this can't be right!? o) Thank you for your attention and for doing what yo do! o) |
Beta Was this translation helpful? Give feedback.
-
|
@tbone2k-git thanks for the thoughtful, respectful message with examples and details. It helps the discussion a lot. A few comments from me:
I understand what you want to say, but opensource communities don't really work like that. You can vote for what you want, but in the end, what gets done is... what people do. Voting without doing is not really relevant. While I don't think it's a particularly good idea to provide out-of-tree, not distribution-tested packages of Podman, because they might jeopardise the whole security and stability of your system, if you want to build them and maintain them, nobody is going to stop you! Myself, I would simply appreciate the intention.
This is the big misunderstanding I'm trying to point out. I've been using Linux for about 25 years, and Debian for the most part of those. I'm also a Debian maintainer. From what you're writing below, Debian testing (or unstable) actually gives you the stable experience you want. Package only migrate from "unstable" to "testing" after 5 days (10 at the moment, soft freeze) without critical issues being reported. In my (quite informed) opinion, you should use Debian stable only if your application is well defined and you want the maximum stability, but not to play around with new software. Think of HTTP servers, or databases, routers, etc.
But if you install out-of-tree packages on Debian stable, things might very well break, and you're on your own. AppArmor policies won't match / work, for example, so you're compromising on security. Debian stable is "more stable" only as such.
Debian stable (or RHEL, for this matter) are similar to branded / certified servers in this regard. Yes, you can replace a component with something that's not certified as compatible, but you'll lose the warranty. And, besides, you don't just push PCIe cards into PCI slots (I hope...).
It's a single vendor, and things move slower. It doesn't offer containers or namespaces. :)
Ouch. :( But the "simple download" would make it even more Frankestein, not less. Again: Debian packages are tested in the distribution they belong to. I understand that Docker does it differently, but on the other hand Docker doesn't necessarily integrate with the distribution at hand, which is what you want for stability: somebody testing that package with your same distribution.
No, it doesn't feel right, but you can also upgrade a distribution, and that's what I would suggest you do. You don't need to wipe or "swap" the operating system: you just upgrade packages. Virtually all Linux distributions support that. Look:
|
Beta Was this translation helpful? Give feedback.
-
|
Hello sbrivio-rh, o) thank you for your kind response. In the last few hours I tinkered with a "testing" Debian and Podman, which I upgraded from a bare bones "stable" VM template I had kept for this exact kind of research scenario. Lifting that very minimal installation from "stable" to "testing" seems to have worked fine. It did not work on the Frankenstein-Podman installation though, some "dpgk error" occurred (which I had trouble with in the past already, but anyhow). If using "testing" is more reasonable from a perspective of someone who is not trying to run a "stable" nuclear reactor or something, than this information needs to be spread more broadly. I'm on Debian "stable" for some years now, and over the time I noticed, that "stable" is not enough. I always need the latest version of Thunar or task manager e.g.. I compiled pulse audio modules for xRDP and whatnot, because every little functionality added helps to get things done more easy on Linux. If I look at the versions in the "testing" channel now, I see that most of my efforts were not necessary. Whether it's desktop or Podman related packages, they seem to be veeeery more recent in "testing" and they are fine to use? You claim that at least, from my experience I would agree.. yes, the more recent versions also do the job, it's not that they have less bugs, they work differently - let's put it that way. o) If "testing" is the actual thing to use for people using Debian as a daily desktop or more capable server installation, it should be more common advice? We could have a banner here and there, telling people to go for "testing" directly. Maybe the name is bad? "Testing" does not really sound like it's meant to be used, hu? o) You have a lot of nice names for the stable releases, the "testing" one needs an appealing name too? The unstable has its own name already, it's called "sid", but that's not recommended I guess, I even discovered the "experimental" channel now - all this is quite confusing to be honest, even if you already looked at the different releases multiple times. So, yes, maybe I realized today, that I indeed use the wrong Debian channel. If this turns out to be true, I will go and start spreading this information from now on as well - unless of course you know, the reactor thing is going on. o) Thank you! o) ps: Even though I am on testing now, with a "recent enough" netavark, I still cannot run a container which uses DHCP to get an IP from the host network. I wonder if this is possible with Podman at all, but this is off topic for sure in this thread. Thanks again! o) |
Beta Was this translation helpful? Give feedback.
-
|
No, I meant the previous discussion was more about "if it is possible" versus "if it is recommended". |
Beta Was this translation helpful? Give feedback.
-
Thanks @afbjorklund for the summary. Two minor corrections:
|
Beta Was this translation helpful? Give feedback.
-
|
Hello everyone! o) I had planned to correct my questioning about Podman containers not being able to make use of a DHCP server on the LAN to get an IP address assigned. I will take the chance now.. o) I got this working with Podman running as root user at least (Debian "Testing"). Still trying to figure out if root-less is possible, technically it should, but some say it's not something you would run in a serious use case. The reason for that is what I still need to find out. My problems so far regarding mac-vlan and DHCP etc., were related to settings in the hypervisor (Microsoft Hyper-V). I had to enable MAC Address spoofing to get it working, so the container can reach out to the DHCP with it's custom MAC address. If that spoofing is not enabled, I assume packets with unknown MAC addresses coming out of the virtual machine / container will be dropped, so the DHCP request always timed out.
Regarding Debian "Bookworm" and Podman, it kind of works for simple container stuff, but the moment you start to try more advanced things you will run into articles and tickets, which make clear, running that old Podman is a one way street and upgrading to recent Podman components on "Bookworm" is barely possible, not recommended. On Debian "Trixie" or Debian "Testing" the Podman experience is much better, more recent components, updated AppArmor profile exists as well and I did not have to tinker and upgrade any part of Podman so far, it seems to work out of the box with all the current module versions and required bits and pieces. Thank you all, have a nice weekend! o) |
Beta Was this translation helpful? Give feedback.
-
The little problem you would have is that you need to forward UDP port 68 (which is used for DHCP replies) to the container, which means, in turn, that you'll probably prevent (other) DHCP clients from running on the host. Anyway, this is outside the scope of this discussion, I'd suggest you open another one if you're looking for hints about that. By the way, why would you do that, now that pasta gives you the same IP address and routes as a host interface? Is it because you want to handle the container as a "different host" or something resembling that? |
Beta Was this translation helpful? Give feedback.
-
|
@sbrivio-rh As mentioned, a DHCP assigned ip-address works fine when running the containers / macvlan network as root user with Podman, but when trying to use a non-privileged user and a macvlan network, this is not that easy anymore (and might be not sensible), because you need to make sure the regular user can access a pdoman network of the root user or allow the regular user to create macvlan networks somehow. I am still investigating.. o) My goal was to run all containers in unprivileged mode with a separate user account for each, which should give max security for production and outside world connectivity (meaning internet). These containers will be hard to manage from Portainer or something though, since there is no common socket anymore, but there is no other way for max security (if somebody with more insight likes to correct me, please do! o). |
Beta Was this translation helpful? Give feedback.
-
Well as someone who is part of that team I would say we really have no strong recommendation either way. Then logically there is the question of why one would duplicate such packing effort when each distro already has well working packages? As explained by @sbrivio-rh debian sid/testing is not far behind upstream but if "stable" streams of distros choose to not update packages (except security fixes) than that is how said distro is designed. Wondering why the packages there are not up to date is kind of unexpected to me and then expecting others to provide newer packages instead to make up for that is IMO the incorrect thing. From an upstream POV we have limited resources (like any project really) and our goal is to develop podman actively to improve it further. And since we are an quite active project that means that using an 1, 2 or 3 year old version can feel vastly different from the latest version. We don't have any LTS versions or such things upstream which means we only ever support the latest version which means if people file bug reports we expect them use (or at least verify) bugs with the latest version. Lastly, one thing I have been lastly keeping a close eye on is the testing part. @sbrivio-rh Already mentioned some of the benefits and that third party packages may not be tested properly in the target distro which is a big one but some distro packages go even further and are doing proper reverse dependency testing (I am aware of debian/fedora/opensuse). That means podman will not only betested once when the podman package is updated but instead it will be tested again for every other package (or only the podman dependencies) updates in said distro. That means if for example the kernel gets updated then podman tests will run on it and fail we know there is most likely a kernel regression. We then can then investigate and depending on what it is either report/fix the kernel problem or if it turns out to be a problem with podman then fix podman. These steps generally happen before the packages actually found its way into the normal repos consumed by most users so as end user you get the benefit of not receiving broken updates. A third party repo could not do that. So in short I don't think a third party repo would provide a "stable" experience and none of the upstream maintainers are interested in doing the work of actually providing such a repo. |
Beta Was this translation helpful? Give feedback.
-
|
It is cool guys. |
Beta Was this translation helpful? Give feedback.
-
|
I get what you mean, but adjectives such as "funny" to describe what's simply Debian's philosophy are what makes this vaguely a flame war. :( For new |
Beta Was this translation helpful? Give feedback.
-
In some way, this is how the Linux world is ticking. There is always a bunch of distros which provide an "out of the box" experience for specific features or software packages (like RDP with audio enabled being only available for recent Fedora and Ubuntu if I remember correctly or btrfs file system and working snapshots in Spiral and others). If you install Debian you don't get any of this, which might be exactly what you want. Specific distros work better for specific things. I would love this to be different, I would prefer installation procedures allowing to fine tune what "kind of Linux" I want to use (systemd vs. random-init is another example), but that's not how things are done right now. I kind of like the resilience this results in though - in theory at least.. o). If there is no 100% common base, then all Linux systems will not break at the same time? o) On the other hand, the various channels, distros, package repos and package maintainers seem to be a wasteful approach, because any packaging and testing work is done multiple times. There also is a huge amount of distro specific software (like file managers, system tools etc.) which is not necessary in this "variety", because there is no variety in most of these tools. There is basically no difference between Thunar or Nemo e.g., in reality there is some slight variation, but from a global perspective they are the same tool. The Linux world could have a file manager called "Thumo" which has twice the features if all efforts were merged, but nope! o) There are quite a lot of different philosophies on how things should be put together, delivered and tested in Linux land. This results in this non-uniform landscape, where you have to pick the right distro / channel for the job. This is not a flame post of any kind, just some kind of attempt to explain why Debian "Bookworm" is not the right choice for running the latest Podman. The regular Linux distribution and package management is not made to get you best of both worlds, you have to pick between stable and recent on Linux, unless you make use of NixOS or distrobox or other workarounds for the package management down-sides on Linux. The actual limitation is, that the regular Linux package management is not capable of keeping multiple versions of the same package around. So you cannot have stable and recent at the same time like on MS Windows, where the system is able to keep track of multiple versions of xmlparser.dlls, .Net-Frameworks or Powershells. Java is another example of handling stable and recent at the same time, it does so by using a global "java" executable, which branches out to a specific runtime if necessary. This allows to add an up to date java runtime to any system and be "recent", while keeping all the existing runtimes in place for backward compatibility (keep the "stable" part). Have a nice weekend everybody! o) |
Beta Was this translation helpful? Give feedback.
-
So yes: it was funny for me to find really long discussion about what is Debian stable philosophy of packaging applications - funny because not expected. Like Spanish inquisition.
I agree it is wasteful! But on the other hand this is the beauty of OSS. Even if 'Thumo' would happen someone would immediately fork it because they 'do not like default color scheme' or some similar. |
Beta Was this translation helpful? Give feedback.
-
|
@Luap99 excellent response, it should probably be a blog that we could point people at. Only thing I would add is that certain distributions like RHEL and OpenSUSE actually pay engineers to do the back ports to older distributions. Since a lot of the core developers work on Fedora, they also make sure the latest Podman is packaged for the supported versions of Fedora. Other companies and distributions are welcome to pay developers or get contributors to also do the same for their favorite distributions. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I am using normal stable Debian 12 for my server.
I want to use the latest podman and not ancient
4.3.1which doesn't even support quadlet.Is there an official mirror for this?
Beta Was this translation helpful? Give feedback.
All reactions