Re: Bug#947847: please install systemd-sysusers using update-alternatives
On 1/29/20 2:19 PM, Simon McVittie wrote: I think we have a fairly good picture of the costs that would be incurred from using alternatives: more interacting code paths to test, potentially more configurations that are technically possible but are not considered supported, and packages with "Depends: systemd (>= 321)" (or indeed systemd itself, in the case of systems using it to boot) not being able to rely on having access to all systemd 321 features, which doesn't seem like a least-astonishment situation to be in. However, Michael, or anyone else opposing this change: if you have anything to add to those, please do. There are some more that come to mind: * if we convert the exiting name to an alternative, there is the somewhat interesting work of actually changing a file over from an executable shipped in the package to an alternative, which would normally be set up by postinst. That could leave an uncomfortably large window during upgrade where the system would be broken (and possibly not boot) if interrupted. And, unlike the related dpkg-divert challenge, this would be on the vast majority of Debian systems, not only those where opensysusers is installed. * if we use a new, different name, then we've introduced a Debian-specific interface. One of the nice things about most of the Linux world standardizing on systemd is increased cross-distro compatibility; here we'd be breaking it. * regardless of which name (existing or new), alternatives can wind up pointing at nothing during the upgrade. Or if the upgrade is interrupted. I seem to recall that's one reason /bin/sh was never an alternative; seems like there is a cost in increased fragility (again, on all systems, not just ones with opensysusers).
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/29/20 8:19 PM, Simon McVittie wrote:
> - Linux systems not booted with systemd
> (either no init system at all, like a typical schroot or Docker
> container, or a non-systemd init system like sysvinit)
This is very much one type of systems I have in mind, yes, and
open{sysusers,tmpfiles} could help to make them smaller. Just pulling
the whole systemd stack to add system users seems too much for very
little benefits.
> I think we have a fairly good picture of the costs that would be
> incurred from using alternatives: more interacting code paths to test,
> potentially more configurations that are technically possible but are
> not considered supported, and packages with "Depends: systemd (>= 321)"
> (or indeed systemd itself, in the case of systems using it to boot)
> not being able to rely on having access to all systemd 321 features,
> which doesn't seem like a least-astonishment situation to be in. However,
> Michael, or anyone else opposing this change: if you have anything to
> add to those, please do.
We don't need to do "Depends: systemd (>= 321)", we could have a virtual
package provided by both implementations.
Cheers,
Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/29/20 4:49 PM, Didier 'OdyX' Raboud wrote: > Le mercredi, 29 janvier 2020, 16.07:21 h CET Thomas Goirand a écrit : >> This reasoning can make sense, if we agree that we should use something >> else than /bin/systemd-sysusers and standardize on something else like >> /bin/sysusers. Then we modify the Debian policy that /bin/sysusers is >> *the* way to do things, and using /bin/systemd-sysusers becomes a bug of >> severity "serious" (policy violation). > > We'd first have to agree that an alternative is actually _needed_. And so > far, > the only arguments I have read in favour of providing alternatives to > /bin/systemd-sysusers are: > * A) it is shipped in the systemd binary package; > * B) Having competing implementations is important; > * C) it comes from the systemd project; > * D) it has a systemd-* name; Very much, B for me... I don't want to see Debian stuck in a position where we are locked-in. This is my main motivation. C and B are distractions that I'm not at all diving into. A is annoying, because that imposes micro-packaging on systemd maintainers (a 200k+ package for just this simple feature? really?), and we try to avoid this project-wide. Thomas
Bug#947847: please install systemd-sysusers using update-alternatives
Hi Didier!
Thanks for taking the time to reply.
On 1/29/20 4:31 PM, Didier 'OdyX' Raboud wrote:
> Software installed as /bin/systemd-* , created within the systemd project, to
> fulfill systemd's view of the world, takes a reasonable hit on the binaries'
> namespace: "systemd-*". Really, we should be thankful that the systemd
> project
> actually started using /bin/systemd-sysusers and not just /bin/sysusers. To
> extend on this, I think it's obvious that what the "systemd-sysusers" binary
> name _says_ really is "this is a systemd-specific utility".
They probably should be thanks to save the namespace, however, they
shouldn't be for pushing for bundling many different things in a single
software.
Let's say I was proposing an alternative implementation of
/usr/sbin/adduser (note that it doesn't have a software name in its
path...), would you allow it? Hopefully yes, if it had the same
functionalities, plus some other properties and improvement (like not
being written in perl... :) (just trolling here... hopefully we can have
fun in this discussion? :)).
Why is it controversial here? Maybe because upstream decided to bundle
it together with many unrelated components, as I wrote above, and prefix
the binary file name with the "systemd-" name, to give the impression
that it feels "integrated". Hopefully, you'll be able to enlighten me if
I forgot something else! :)
Some of us have complained about the non-modularity of systemd. My idea
was to prove them wrong, and that we can replace some of the components
that aren't that tightly integrated. It feels like upstream also
declares systemd-sysusers as an independent component, and kind of agree
with me on this specific point.
> Let's see if I understand what you want correctly; you want Debian to allow
> replacing systemd-specific software with alternatives, right?
It only your own opinion that systemd-sysusers is systemd specific. My
view is that what it does isn't more specific to systemd than
/usr/sbin/useradd, and that in the first place, it should have *never*
been part of a single systemd project. That's truth for many other
components of systemd, but let's not discuss this (it's out of scope).
Now that some are proposing that sysusers becomes a accepted Debian
interface, it becomes increasingly important that it becomes independent
from any other component of the system, and that it can be replaced or
reimplemented in a different way. Otherwise, maintainers scripts will
increasingly use it, and we become effectively locked-in, married
forever with systemd.
> I'm sorry, but
> this does not make any sense to me: /bin/systemd-sysusers _is_ systemd-
> specific, and is used as such by systemd.
I am contesting this.
It's bundled with systemd, yes. It's pre-fixed with the word "systemd-"
in its binary name, yes. The idea of the static sysusers data file comes
from systemd, yes. But it stops here.
Its core functionality isn't systemd specific. We've been adding systemd
users in maintainer scripts for decades, a long time before we even knew
the word "systemd".
> If usages of it have appeared
> outside of the systemd repository, I think it's fair to say (because of the
> binary's name)
The binary name is precisely a distraction which you should try to
ignore, because it is very misleading.
> that they were knowingly using a systemd-specific piece of
> software (and hence, have correctly added a "{Pre-,}Depends: systemd".
That is exactly what I would like to avoid. Hopefully, we will be able
to have:
{Pre-,}Depends: systemd-sysusers | opensysusers
or even:
{Pre-,}Depends: sysusers
if we get into the virtual package thing... And probably we should!
(maybe we can discuss this after this first discussion is done)
> If I reformulate what it seems to me you're asking, it comes accross to me as
> "/bin/systemd-sysusers comes from systemd and it should be possible to have a
> system without systemd installed, therefore please force the systemd
> maintainers to allow hosts to have a non-systemd /bin/systemd-sysusers".
I don't like *at all* the way you are reformulating, and that's not
really what I'm asking for. So please allow me reject the way you are
putting things, and let me phrase it my way.
I'm simply asking *Debian* (not systemd maintainers) to allow multiple
implementations of the same functionality (ie: adding users using a data
file format, which happens to have been invented by the systemd project).
To be able to allow another implementation to exist in Debian (which
happen to work anywhere, even without systemd, that's truth, but that's
not the only property of opensysusers), and a way in Debian so we can
standardize on.
This goes beyond the "I want to use sysusers in non-systemd setups". I
also want to be able to use opensysusers when I run systemd. In fact,
that's how I would like *my* own laptop / servers to run.
Anyway, there's a few ways to make this work, and both things to cohexist.
1/ Having a systemd-sysuser
Bug#947847: please install systemd-sysusers using update-alternatives
On Wed, 2020-01-29 at 12:23 -0800, Moritz Mühlenhoff wrote: > Simon McVittie wrote: > > I think we have a fairly good picture of the costs that would be > > incurred from using alternatives: > > Plus in the case of opentmpfiles; a pile of security issues: systemd- > tmpfiles addresses a number of complex races using low level > primitives like openat() et al. or O_PATH, while opentmpfiles is > implemented in shell. Do you mean that shell scripts cannot cannot handle such issues?? So C- code is safe by construction, do you really believe in that?
Bug#947847: please install systemd-sysusers using update-alternatives
Simon McVittie wrote: > I think we have a fairly good picture of the costs that would be > incurred from using alternatives: Plus in the case of opentmpfiles; a pile of security issues: systemd-tmpfiles addresses a number of complex races using low level primitives like openat() et al. or O_PATH, while opentmpfiles is implemented in shell. Cheers, Moritz
Bug#947847: please install systemd-sysusers using update-alternatives
Am Mi., 29. Jan. 2020 um 20:39 Uhr schrieb Simon McVittie : > [...] > I think there are three categories of systems that it might make sense > to consider separately here. In ascending order of "amount of systemd": > > - non-Linux ports to which systemd does not intend to be portable (and > I think we can treat non-systemd-by-policy derivatives like Devuan as > basically equivalent to these), where the systemd implementation of > -sysusers simply does not exist > > - Linux systems not booted with systemd > (either no init system at all, like a typical schroot or Docker > container, or a non-systemd init system like sysvinit) > [...] For this particular case it's probably worthwhile to also consider Zbigniew Jędrzejewski-Szmek's comment on debian-devel a while back, where they extended systemd's interface stability and compatibility promise based on our discussions back then. Namely: > Independent operation of a bunch of > programs is now explicitly covered, and the stability promise > has been extended to more interfaces. >From >https://systemd.io/PORTABILITY_AND_STABILITY/#independent-operation-of-systemd-programs systemd-sysusers and tmpfiles are covered by this promise, as well as a few other utilities. So, especially for container usecases it may actually be reasonable for the systemd maintainers to make those utilities available in a separate package to be installed without the daemon components. That way they would be readily available and working even on systems where systemd isn't PID1 (of course, the daemons should also be inert until an alternative init system starts to parse systemd service files, so at the moment even installing the systemd package itself for these binaries is safe). Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
Bug#947847: please install systemd-sysusers using update-alternatives
Svante Signell dijo [Wed, Jan 29, 2020 at 08:15:36PM +0100]: > > It's not like having two competing implementations causes much > > harm here.we technically _can_ allow any /bin/systemd-* to be > > provided by another implementation, that we should (actually, I think > > we should clearly _not_). > > Of course the name should not be systemd-*. That would conflict with > systemd upstream, and a lot of other stuff too! Humh, where did you quote this snippet from? It includes bits from OdyX's mail, but it's wrapped over itself. It also shows as if it were my text (which is _not_). > > /usr/bin/systemd-* is clearly implementation-specific. Now, if we are > > to allow alternative implementations of /usr/bin/system-brewmycoffee, > > no way! Please keep on reading for the full paragraph... > > we should first push to an alternative /usr/bin/brewmycoffee, get the > > systemd maintainers to "subscribe" to it using our great alternatives > > system, and provide our /usr/bin/open-brewmycoffee. > > Why should they be subscribing? There are other people within Debian > who can provide alternatives. I tend to convey that, if Debian is to support more of one argument-compatible implementations of brewmycoffee (one of which is systemd-brewmycoffee), I feel the systemd maintainers should be sensible and allow its use, via the alternatives system, as /usr/bin/brewmycoffee. Of course, it is highly likely they will be seen as the reference implementation and others should attempt to adopt a compatible interface arguments-wise. > > And I think that now, that not so many packages have yet adopted > > systemd-derived facilities, is a great time to set this as a good > > practice. > > Is this your interpretation of the GR? It my impression, at least.
Bug#947847: please install systemd-sysusers using update-alternatives
On Mon, 27 Jan 2020 at 11:18:53 +0100, Thomas Goirand wrote: > you don't seem to agree that it'd be ok for one to use > opensysuser instead of the systemd implementation if systemd is running. > I do not agree with this, and I believe it is up to the users to decide > what to do, even if we, as an operating system, must provide sensible > defaults I hope everyone involved can agree that: - we should provide choices where their benefit exceeds their cost, because more choice results in a more widely applicable system; - we should not provide choices where their cost exceeds their benefit, because more guarantees result in a more robust system (By "cost" I mean developer time spent, avoidable bugs caused, etc. - not money.) To take some clear examples: at one end of the scale, we provide a way to configure per-system whether /usr/bin/editor is emacs or vi or whatever, because that's primarily about subjective, personal UI preference. At the other end of the scale, we *don't* provide a way to configure per-system whether /bin/tar is GNU or BSD tar: we want packages that run tar to be able to make the simplifying assumption that on any Debian system, it's going to be GNU tar, and we do not want to deal with bug reports from users who have switched to an unexpected tar implementation. So this is at least partially a question of whether making opensysusers vs. systemd-sysusers easily sysadmin-configurable has a cost greater or less than its benefit, or to put it another way, where it falls on a scale between /usr/bin/editor and /bin/tar. With that in mind: Thomas, or anyone else asking for this change, what benefits do you expect users of Debian to obtain from being able to install both opensysusers' implementation of the sysusers.d interface and systemd's, and choose which one is invoked from the boot procedure and packages' postinsts via configuration, as opposed to via package installation/removal? I think there are three categories of systems that it might make sense to consider separately here. In ascending order of "amount of systemd": - non-Linux ports to which systemd does not intend to be portable (and I think we can treat non-systemd-by-policy derivatives like Devuan as basically equivalent to these), where the systemd implementation of -sysusers simply does not exist - Linux systems not booted with systemd (either no init system at all, like a typical schroot or Docker container, or a non-systemd init system like sysvinit) - Linux systems booted using systemd It might be helpful to consider which benefits apply to which of these categories. For example, the first category certainly benefits from opensysusers *existing*, but does not directly benefit from co-installability or from having a choice, because there is no such choice: systemd's -sysusers is not available there, so using something non-systemd is the only option. I think we have a fairly good picture of the costs that would be incurred from using alternatives: more interacting code paths to test, potentially more configurations that are technically possible but are not considered supported, and packages with "Depends: systemd (>= 321)" (or indeed systemd itself, in the case of systems using it to boot) not being able to rely on having access to all systemd 321 features, which doesn't seem like a least-astonishment situation to be in. However, Michael, or anyone else opposing this change: if you have anything to add to those, please do. Thanks, smcv
Bug#947847: please install systemd-sysusers using update-alternatives
On Wed, 2020-01-29 at 12:24 -0600, Gunnar Wolf wrote: > It's not like having two competing implementations causes much > harm here.we technically _can_ allow any /bin/systemd-* to be > provided by another implementation, that we should (actually, I think > we should clearly _not_). Of course the name should not be systemd-*. That would conflict with systemd upstream, and a lot of other stuff too! > /usr/bin/systemd-* is clearly implementation-specific. Now, if we are > to allow alternative implementations of /usr/bin/system-brewmycoffee, no way! > we should first push to an alternative /usr/bin/brewmycoffee, get the > systemd maintainers to "subscribe" to it using our great alternatives > system, and provide our /usr/bin/open-brewmycoffee. Why should they be subscribing? There are other people within Debian who can provide alternatives. > And I think that now, that not so many packages have yet adopted > systemd-derived facilities, is a great time to set this as a good > practice. Is this your interpretation of the GR?
Bug#947847: please install systemd-sysusers using update-alternatives
Thomas Goirand dijo [Wed, Jan 29, 2020 at 04:07:21PM +0100]: > This reasoning can make sense, if we agree that we should use something > else than /bin/systemd-sysusers and standardize on something else like > /bin/sysusers. Then we modify the Debian policy that /bin/sysusers is > *the* way to do things, and using /bin/systemd-sysusers becomes a bug of > severity "serious" (policy violation). Yes for the general case, no for specifics. I mean - We should encourage people to use /bin/sysusers. Now, if systemd-sysusers grows a piece of functionality that open-sysusers is not willing to adopt (or vice versa), following past examples, I believe a package set to predepend on systemd-sysusers should be able to call /bin/systemd-sysusers — And a package set to predepend on open-sysusers can do likewise.
Bug#947847: please install systemd-sysusers using update-alternatives
I just want to subscribe with a very big +1 to what OdyX has said here: Didier 'OdyX' Raboud dijo [Wed, Jan 29, 2020 at 04:31:09PM +0100]: > (...) > > So I am in the opinion that "as long as it's properly hooked in the > > packaging system and boot sequence" simply doesn't work in this case, as > > systemd-sysusers could be called from virtually anywhere. > > That's exactly the point: if it's so good that it has become used in many > places, changing the binary behind the scenes is clearly premature at this > point. > > If I reformulate what it seems to me you're asking, it comes accross to me as > "/bin/systemd-sysusers comes from systemd and it should be possible to have a > system without systemd installed, therefore please force the systemd > maintainers to allow hosts to have a non-systemd /bin/systemd-sysusers". > > My answer to this is that /bin/systemd-sysusers _is_ a systemd interface, > with > a systemd-* name and I don't think it's reasonable to ask (or force) the > systemd maintainers to allow "their" interface to be implemented by other > software projects. Afterall, they came with the idea first, in their > namespace. > > That said, taking a step back and looking at the larger picture, if what you > wish is a Debian in which one can pick their preferred sysusers' > implementation, what about discussing the pertinence of a "parent" > /bin/sysusers; with alternatives' setup there? (I wouldn't be surprised if > the > systemd maintainers agreed to register /bin/systemd-sysusers as alternative > to > /bin/sysusers). > > With this in place, you could go to maintainers who _have_ already used > /bin/systemd-sysusers to try convince them to use the /bin/sysusers > "standard" > interface instead. We have this for 'httpd', 'default-mta', what about having > a virtual 'sysusers' ? > > All-in-all, I think the question you're asking is misguided: it's not because > we technically _can_ allow any /bin/systemd-* to be provided by another > implementation, that we should (actually, I think we should clearly _not_). > But not having a /bin/systemd-sysusers' implementation that can be toggled in- > place through alternatives doesn't hinder you from proving that the competing > implementation is better (faster, less systemd, etc); there are various ways > to do this; dpkg-divert, another non-"systemd-*" parent alternative, or > others. If /usr/bin/opensysusers-sysusers is really that good, have you tried > talking to maintainers using /bin/systemd-sysusers to see if they would like > to swap to it? It's not like having two competing implementations causes much > harm here. /usr/bin/systemd-* is clearly implementation-specific. Now, if we are to allow alternative implementations of /usr/bin/systemd-brewmycoffee, we should first push to an alternative /usr/bin/brewmycoffee, get the systemd maintainers to "subscribe" to it using our great alternatives system, and provide our /usr/bin/open-brewmycoffee. And I think that now, that not so many packages have yet adopted systemd-derived facilities, is a great time to set this as a good practice. signature.asc Description: PGP signature
Bug#947847: please install systemd-sysusers using update-alternatives
Le mercredi, 29 janvier 2020, 16.07:21 h CET Thomas Goirand a écrit : > This reasoning can make sense, if we agree that we should use something > else than /bin/systemd-sysusers and standardize on something else like > /bin/sysusers. Then we modify the Debian policy that /bin/sysusers is > *the* way to do things, and using /bin/systemd-sysusers becomes a bug of > severity "serious" (policy violation). We'd first have to agree that an alternative is actually _needed_. And so far, the only arguments I have read in favour of providing alternatives to /bin/systemd-sysusers are: * A) it is shipped in the systemd binary package; * B) Having competing implementations is important; * C) it comes from the systemd project; * D) it has a systemd-* name; Out of these, A is the most convincing, B is mildly so; C & D are absolutely irrelevant IMHO. If you're concerned by A, the request becomes: > Please ship systemd-sysusers in a separate package for finer granularity and > smaller installation size for non-systemd systems If you're concerned by B, I don't think you need anything from systemd; just convince enough maintainers that a non-systemd implementation is important, and get them to change their scripts and dependencies to opensysusers. If you really want a single sysusers implementation per system (what's the argument there?), then go the /usr/bin/sysusers alternatives' route, and convince maintainers to move to that virtual package. -- OdyX signature.asc Description: This is a digitally signed message part.
Bug#947847: please install systemd-sysusers using update-alternatives
Le mercredi, 29 janvier 2020, 12.41:52 h CET Thomas Goirand a écrit :
> I'm replying to you, but it goes also for Phillip Kern too, which had a
> similar answer.
Only words, I know, but let's try to answer technical points, not address
people. "Talk to the space, not to individuals"
> My idea is to have a single entry point for programs to call the
> sysusers binary. If we collectively decide that it's going to be called
> /bin/foo, then by all means, let's do that. But I don't think it's
> reasonable to say it's going to be called /bin/systemd-bar, and nobody
> can take over this path. This is the wrong answer to the problem.
Software installed as /bin/systemd-* , created within the systemd project, to
fulfill systemd's view of the world, takes a reasonable hit on the binaries'
namespace: "systemd-*". Really, we should be thankful that the systemd project
actually started using /bin/systemd-sysusers and not just /bin/sysusers. To
extend on this, I think it's obvious that what the "systemd-sysusers" binary
name _says_ really is "this is a systemd-specific utility".
I'm of the opinion that noone should be allowed to take over this
/usr/bin/systemd-sysusers path, indeed. Much like I don't think anyone should
be allowed to provide an alternative to /usr/sbin/cupsd.
Let's see if I understand what you want correctly; you want Debian to allow
replacing systemd-specific software with alternatives, right? I'm sorry, but
this does not make any sense to me: /bin/systemd-sysusers _is_ systemd-
specific, and is used as such by systemd. If usages of it have appeared
outside of the systemd repository, I think it's fair to say (because of the
binary's name) that they were knowingly using a systemd-specific piece of
software (and hence, have correctly added a "{Pre-,}Depends: systemd".
Note that I'm not saying that /bin/systemd-sysusers _cannot_ be used without
systemd, or on a host booted with a different init system; I'm only saying
that usages of systemd-sysusers must have appeared with full knowledge of
using the systemd-sysusers binary from the systemd project.
> So I am in the opinion that "as long as it's properly hooked in the
> packaging system and boot sequence" simply doesn't work in this case, as
> systemd-sysusers could be called from virtually anywhere.
That's exactly the point: if it's so good that it has become used in many
places, changing the binary behind the scenes is clearly premature at this
point.
If I reformulate what it seems to me you're asking, it comes accross to me as
"/bin/systemd-sysusers comes from systemd and it should be possible to have a
system without systemd installed, therefore please force the systemd
maintainers to allow hosts to have a non-systemd /bin/systemd-sysusers".
My answer to this is that /bin/systemd-sysusers _is_ a systemd interface, with
a systemd-* name and I don't think it's reasonable to ask (or force) the
systemd maintainers to allow "their" interface to be implemented by other
software projects. Afterall, they came with the idea first, in their
namespace.
That said, taking a step back and looking at the larger picture, if what you
wish is a Debian in which one can pick their preferred sysusers'
implementation, what about discussing the pertinence of a "parent"
/bin/sysusers; with alternatives' setup there? (I wouldn't be surprised if the
systemd maintainers agreed to register /bin/systemd-sysusers as alternative to
/bin/sysusers).
With this in place, you could go to maintainers who _have_ already used
/bin/systemd-sysusers to try convince them to use the /bin/sysusers "standard"
interface instead. We have this for 'httpd', 'default-mta', what about having
a virtual 'sysusers' ?
All-in-all, I think the question you're asking is misguided: it's not because
we technically _can_ allow any /bin/systemd-* to be provided by another
implementation, that we should (actually, I think we should clearly _not_).
But not having a /bin/systemd-sysusers' implementation that can be toggled in-
place through alternatives doesn't hinder you from proving that the competing
implementation is better (faster, less systemd, etc); there are various ways
to do this; dpkg-divert, another non-"systemd-*" parent alternative, or
others. If /usr/bin/opensysusers-sysusers is really that good, have you tried
talking to maintainers using /bin/systemd-sysusers to see if they would like
to swap to it? It's not like having two competing implementations causes much
harm here.
Cheers,
OdyX
signature.asc
Description: This is a digitally signed message part.
Bug#947847: please install systemd-sysusers using update-alternatives
On Tue, 28 Jan 2020, Thomas Goirand wrote: > This is exactly what should be avoided. It's perfectly fine to try to > use opensysusers with systemd if one wants. In fact, that's exactly the > best way we could do to be able to test it. Also, dpkg-divert is really > ugly, and something you use as the last resort, when all other options > have been exhausted. It's not that ugly if you consider that you are in an experimental phase where you want to test opensysusers. Also you seem to imply that the common interface is the systemd-sysusers binary. I don't think that this is necessarily the case. The common interface is the file format. The name of the program creating the users is not important as long as it's properly hooked in the packaging system and boot sequence. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
