Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Thu, Oct 01, 2020 at 12:08:19PM -0400, Paul Wouters wrote: > Clearly, there is a case for making systemd-resolved "default with > an option to opt-out". It makes no sense that these deployments > must install and ensure to then disable and keep disabled, the > systemd-resolved daemon. I fully agree that an opt-out should be possible. I don't think anyone suggested differently. On normal upgrades following the transition to F33, nothing special needs to be done. The only exception is the first upgrade to F33, where we reset systemd-resolved.service enablement and adjust resolv.conf symlink. Those changes are conditionalized on systemd-resolved.service being enabled in presets. To opt out, create a local preset which disables systemd-resolved. I now added a section about this to the Change page: https://fedoraproject.org/w/index.php?title=Changes%2Fsystemd-resolved=revision=589756=588639 (There's also the question of changes to /etc/nsswitch.conf. Those are currently done unconditionally based on the premise that nss-resolve has no effect if systemd-resolved.service is not running. We can adjust that too if needed.) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Thu, 1 Oct 2020, Neal Gompa wrote: Essentially, split-horizon DNS setups on Fedora systems become possible with this change. As reported by libreswan and openvpn developers already in the last two days, these are already possible without systemd-resolved and people have relied on that for years. We have also seen reports like one where servers in an Active Directory domain with systemd-resolved have broken DNS due to load issues. Clearly, there is a case for making systemd-resolved "default with an option to opt-out". It makes no sense that these deployments must install and ensure to then disable and keep disabled, the systemd-resolved daemon. The argument against this so far has been "it makes things more complicated". I have asked for specific details on this so we can talk about potentially addressing those complications and make everybody happy. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 10/1/20 8:20 AM, Peter Robinson wrote: >> Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > (rpm)ostree variants are Fedora variants - please don't using phrasing > implying otherwise. > IOW you just say: *all* Fedora variants use NetworkManager. They are not the same. Regular Fedora is considerably more customizable post-installation than OSTree-based variants. That's why I made that point. >>> >>> "All Fedora variants, both with ostree and without..." maybe? OSTree-based >>> variants are also "regular Fedora". >>> >> >> I would only even remotely consider agreeing with that premise for >> Silverblue. Neither Fedora CoreOS nor Fedora IoT qualify for that, in >> my view, since they completely sidestep the normal release engineering > > IoT is *NOT* side stepping the normal release engineering process, > we're using exactly the same process, it just runs independently, just > cloud cloud and container images do nightlies post release. Fedora CoreOS does differ here. We use a build pipeline that runs inside of Jenkins on top of OpenShift. All it's doing in the background is running coreos-assembler, which anyone can easily do on their laptop. One of the guiding principles when we first started was we wanted it to be dead simple for anyone to develop and build FCOS locally so we pursued this path. https://github.com/coreos/coreos-assembler > >> process, don't use the same repositories, and have the power to >> include and exclude packages from the total available package set at >> their leisure. > > Fedora IoT uses the same repositories, we don't have seprate, we do > have an overrides repo so we can get fixes quicker. Same for Fedora CoreOS. We use the exact same RPMs built by release engineering and we pull from the same repositories to seed our pipelines but we do have a different cadence for releases (i.e. bake time) and the flexibility to pin or fast-track packages based on needs. > > Matthew has expressed interest in *any* spin to be able to release > whenever they are ready to enable them to release on a schedule that > suits them, IoT is being uses as the proving ground for that. It > doesn't mean we can pull in whatever we want and have different > repositories. Please get your facts correct! > >> There is no expectation with those variants that anything you do will >> necessarily show up there. Heck, Fedora CoreOS is reverting a >> system-wide change in its variant (SQLite rpmdb), and had previously >> also reverted another one (cgroup v2). The merits of those changes >> aside, this makes the experience materially different than everything >> else we have. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 10/1/20 12:00 AM, Joe Doss wrote: > On 9/30/20 7:14 PM, Colin Walters wrote: >> That's not true, you can `rpm-ostree override remove`. It'd still be >> there in the ostree repository on disk, but you don't see it in the >> "deployment" (what you actually boot into). Few people care about >> disk space that much, and if you do you can do custom builds. > > ...but can we can do that and will updates to FCOS work after? I am > pretty sure currently the answer is no, unless I don't fully understand > the impacts of https://github.com/coreos/fedora-coreos-tracker/issues/400 You can `rpm-ostree override remove` without making upgrades less reliable, assuming you don't remove a core component. The less reliable part comes when you package layer a new package on top that wasn't in the base. We're fixing that issue very soon though. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Thu, Oct 1, 2020 at 9:06 AM Peter Robinson wrote: > > On Thu, Oct 1, 2020 at 1:53 PM Neal Gompa wrote: > > > > On Thu, Oct 1, 2020 at 8:34 AM Peter Robinson wrote: > > > > > > On Wed, Sep 30, 2020 at 9:27 PM Neal Gompa wrote: > > > > > > > > On Wed, Sep 30, 2020 at 3:42 PM Ian Pilcher > > > > wrote: > > > > > > > > > > On 9/30/20 2:19 PM, Michael Catanzaro wrote: > > > > > > On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher > > > > > > wrote: > > > > > >> And what about places where NetworkManager isn't used? (Just > > > > > >> because > > > > > >> it's the default, doesn't mean that it's used everywhere.) > > > > > > > > > > > > NetworkManager is used everywhere by default. If you want to > > > > > > disable it, > > > > > > you have to do manual work to do that. If you do manual work to > > > > > > disable > > > > > > NetworkManager, you can also do manual work to disable > > > > > > systemd-resolved. > > > > > > > > > > Indeed, but I was responding to this: > > > > > > > > > > On 9/30/20 1:35 PM, Neal Gompa wrote: > > > > > > Please, no more package splitting. And NetworkManager is used > > > > > across > > > > > > all variants of Fedora, so resolved should be installed in all > > > > > places > > > > > > where NetworkManager is used. > > > > > > > > > > Which (to my reading) says that because NetworkManager is the > > > > > *default* > > > > > everywhere (even though it can be uninstalled), systemd-resolved > > > > > should > > > > > be *installed* everywhere (and should not be uninstallable). I don't > > > > > follow that logic. > > > > > > > > There are not a ton of advantages for splitting it, since it's only a > > > > couple of binaries averaging 2MB with a few unit files. Given that we > > > > require it for default NetworkManager configurations now, there's not > > > > a lot of value in making that complicated. Splitting has a cost too, > > > > in the form of extra metadata, upgrade paths, etc. > > > > > > > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > > > > variants, as shipped today, *MUST* use NetworkManager. > > > > NetworkManager's configuration will use resolved as a local resolver. > > > > Anything baked into an OSTree cannot be removed anyway. > > > > > > > > And like it or not, all our legacy network configuration mechanisms > > > > are deprecated and *will be removed eventually*. > > > > > > > > Literally the only reason networkd was split out was because Fedora > > > > CoreOS was chainsawing it out at image build time and making it > > > > impossible for people to use it. To be frank, I do not want more > > > > permutations this low in the stack. It makes life incredibly difficult > > > > for figuring out working network setups. > > > > > > > > My reply was aimed at Peter saying he'd like to not ship resolved, and > > > > I'm saying that we should *not* do that, because it makes things even > > > > harder and more complicated. > > > > > > So you're saying that if this doesn't work for IoT and actively causes > > > deployment problems, potentially across millions of devices, we can't > > > turn it off, change the option and have to basically suck it up and > > > deal with all the problems? Well that makes Fedora completely > > > unappealing and I feel against the project of people being able to > > > choose. It will make people go elsewhere and frankly so will I! > > > > If there are problems with our configuration for your use-case, the > > idea is to actually report the issue and/or fix them. It's not like we > > don't have systemd engineers in Fedora. If there is some fatal flaw, > > then I would *love* to know, but so far, there doesn't seem to be one. > > > > And throwing around "millons of devices" as a reason for me to care > > about IoT more than anything else is not a good way for me to care > > more about you. You can't prove it to me, and it's easy to prove more > > devices *not* running it than running it. > > It's not a way "to care about IoT more than anything else" it's used > as an example to allow Spins/Editions to make the decisions that are > the best for the users even if it's different for the whole. There are > not millions of devices running Fedora IoT *now*, I never said that, > but there are companies looking at doing so. I'm not asking for anyone > to care more about IoT than anything else, I'm purely asking that the > IoT SIG can make their own decisions, which I believe we're actively > allowed to do, rather than having something rammed down our collective > throat if it doesn't work for us. > > > To be blunt, I expect IoT environments to be even worse off in terms > > of taking advantage of DNS security features, because they often rely > > on mobile networks (which don't have any DNS security features) and > > tunnels over those networks (which usually can't have DNS security > > features) to communicate. In that case, what we have here would > > improve that situation for you. > > A lot of those devices use VPN to
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Thu, Oct 1, 2020 at 1:53 PM Neal Gompa wrote: > > On Thu, Oct 1, 2020 at 8:34 AM Peter Robinson wrote: > > > > On Wed, Sep 30, 2020 at 9:27 PM Neal Gompa wrote: > > > > > > On Wed, Sep 30, 2020 at 3:42 PM Ian Pilcher wrote: > > > > > > > > On 9/30/20 2:19 PM, Michael Catanzaro wrote: > > > > > On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher > > > > > wrote: > > > > >> And what about places where NetworkManager isn't used? (Just because > > > > >> it's the default, doesn't mean that it's used everywhere.) > > > > > > > > > > NetworkManager is used everywhere by default. If you want to disable > > > > > it, > > > > > you have to do manual work to do that. If you do manual work to > > > > > disable > > > > > NetworkManager, you can also do manual work to disable > > > > > systemd-resolved. > > > > > > > > Indeed, but I was responding to this: > > > > > > > > On 9/30/20 1:35 PM, Neal Gompa wrote: > > > > > Please, no more package splitting. And NetworkManager is used across > > > > > all variants of Fedora, so resolved should be installed in all places > > > > > where NetworkManager is used. > > > > > > > > Which (to my reading) says that because NetworkManager is the *default* > > > > everywhere (even though it can be uninstalled), systemd-resolved should > > > > be *installed* everywhere (and should not be uninstallable). I don't > > > > follow that logic. > > > > > > There are not a ton of advantages for splitting it, since it's only a > > > couple of binaries averaging 2MB with a few unit files. Given that we > > > require it for default NetworkManager configurations now, there's not > > > a lot of value in making that complicated. Splitting has a cost too, > > > in the form of extra metadata, upgrade paths, etc. > > > > > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > > > variants, as shipped today, *MUST* use NetworkManager. > > > NetworkManager's configuration will use resolved as a local resolver. > > > Anything baked into an OSTree cannot be removed anyway. > > > > > > And like it or not, all our legacy network configuration mechanisms > > > are deprecated and *will be removed eventually*. > > > > > > Literally the only reason networkd was split out was because Fedora > > > CoreOS was chainsawing it out at image build time and making it > > > impossible for people to use it. To be frank, I do not want more > > > permutations this low in the stack. It makes life incredibly difficult > > > for figuring out working network setups. > > > > > > My reply was aimed at Peter saying he'd like to not ship resolved, and > > > I'm saying that we should *not* do that, because it makes things even > > > harder and more complicated. > > > > So you're saying that if this doesn't work for IoT and actively causes > > deployment problems, potentially across millions of devices, we can't > > turn it off, change the option and have to basically suck it up and > > deal with all the problems? Well that makes Fedora completely > > unappealing and I feel against the project of people being able to > > choose. It will make people go elsewhere and frankly so will I! > > If there are problems with our configuration for your use-case, the > idea is to actually report the issue and/or fix them. It's not like we > don't have systemd engineers in Fedora. If there is some fatal flaw, > then I would *love* to know, but so far, there doesn't seem to be one. > > And throwing around "millons of devices" as a reason for me to care > about IoT more than anything else is not a good way for me to care > more about you. You can't prove it to me, and it's easy to prove more > devices *not* running it than running it. It's not a way "to care about IoT more than anything else" it's used as an example to allow Spins/Editions to make the decisions that are the best for the users even if it's different for the whole. There are not millions of devices running Fedora IoT *now*, I never said that, but there are companies looking at doing so. I'm not asking for anyone to care more about IoT than anything else, I'm purely asking that the IoT SIG can make their own decisions, which I believe we're actively allowed to do, rather than having something rammed down our collective throat if it doesn't work for us. > To be blunt, I expect IoT environments to be even worse off in terms > of taking advantage of DNS security features, because they often rely > on mobile networks (which don't have any DNS security features) and > tunnels over those networks (which usually can't have DNS security > features) to communicate. In that case, what we have here would > improve that situation for you. A lot of those devices use VPN to communicate with some things, such as internal systems, messaging endpoints etc, and the direct internet for things like updates to make use of CDNs and other such technologies to push large data updates as close to the devices as possible, AFAICT from the thread in some/a lot, that use case alone is
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Thu, Oct 1, 2020 at 8:34 AM Peter Robinson wrote: > > On Wed, Sep 30, 2020 at 9:27 PM Neal Gompa wrote: > > > > On Wed, Sep 30, 2020 at 3:42 PM Ian Pilcher wrote: > > > > > > On 9/30/20 2:19 PM, Michael Catanzaro wrote: > > > > On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher > > > > wrote: > > > >> And what about places where NetworkManager isn't used? (Just because > > > >> it's the default, doesn't mean that it's used everywhere.) > > > > > > > > NetworkManager is used everywhere by default. If you want to disable it, > > > > you have to do manual work to do that. If you do manual work to disable > > > > NetworkManager, you can also do manual work to disable systemd-resolved. > > > > > > Indeed, but I was responding to this: > > > > > > On 9/30/20 1:35 PM, Neal Gompa wrote: > > > > Please, no more package splitting. And NetworkManager is used across > > > > all variants of Fedora, so resolved should be installed in all places > > > > where NetworkManager is used. > > > > > > Which (to my reading) says that because NetworkManager is the *default* > > > everywhere (even though it can be uninstalled), systemd-resolved should > > > be *installed* everywhere (and should not be uninstallable). I don't > > > follow that logic. > > > > There are not a ton of advantages for splitting it, since it's only a > > couple of binaries averaging 2MB with a few unit files. Given that we > > require it for default NetworkManager configurations now, there's not > > a lot of value in making that complicated. Splitting has a cost too, > > in the form of extra metadata, upgrade paths, etc. > > > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > > variants, as shipped today, *MUST* use NetworkManager. > > NetworkManager's configuration will use resolved as a local resolver. > > Anything baked into an OSTree cannot be removed anyway. > > > > And like it or not, all our legacy network configuration mechanisms > > are deprecated and *will be removed eventually*. > > > > Literally the only reason networkd was split out was because Fedora > > CoreOS was chainsawing it out at image build time and making it > > impossible for people to use it. To be frank, I do not want more > > permutations this low in the stack. It makes life incredibly difficult > > for figuring out working network setups. > > > > My reply was aimed at Peter saying he'd like to not ship resolved, and > > I'm saying that we should *not* do that, because it makes things even > > harder and more complicated. > > So you're saying that if this doesn't work for IoT and actively causes > deployment problems, potentially across millions of devices, we can't > turn it off, change the option and have to basically suck it up and > deal with all the problems? Well that makes Fedora completely > unappealing and I feel against the project of people being able to > choose. It will make people go elsewhere and frankly so will I! If there are problems with our configuration for your use-case, the idea is to actually report the issue and/or fix them. It's not like we don't have systemd engineers in Fedora. If there is some fatal flaw, then I would *love* to know, but so far, there doesn't seem to be one. And throwing around "millons of devices" as a reason for me to care about IoT more than anything else is not a good way for me to care more about you. You can't prove it to me, and it's easy to prove more devices *not* running it than running it. To be blunt, I expect IoT environments to be even worse off in terms of taking advantage of DNS security features, because they often rely on mobile networks (which don't have any DNS security features) and tunnels over those networks (which usually can't have DNS security features) to communicate. In that case, what we have here would improve that situation for you. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Thu, Oct 01, 2020 at 12:55:40PM +0200, Petr Pisar wrote: > On Wed, Sep 30, 2020 at 04:26:39PM +, Zbigniew Jędrzejewski-Szmek wrote: > > In addition, two more new subpackages are created: > > systemd-standalone-sysusers > > and systemd-standalone-tmpfiles, with custom-linked systemd-sysusers and > > systemd-tmpfiles binaries. > > root@fedora-34:~ # dnf --quiet repoquery --repo=f34-build --list systemd > |grep systemd-sysusers > /usr/bin/systemd-sysusers > /usr/lib/systemd/system/sysinit.target.wants/systemd-sysusers.service > /usr/lib/systemd/system/systemd-sysusers.service > /usr/share/man/man8/systemd-sysusers.8.gz > /usr/share/man/man8/systemd-sysusers.service.8.gz > root@fedora-34:~ # dnf --quiet repoquery --repo=f34-build --list > systemd-standalone-sysusers |grep systemd-sysusers > /usr/bin/systemd-sysusers > > I think systemd-standalone-sysusers package is missing the manual pages. I think that's ok. The -standalone- packages are supposed to be minimal. Also, people would use them in minimal images that are also missing man. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 9:27 PM Neal Gompa wrote: > > On Wed, Sep 30, 2020 at 3:42 PM Ian Pilcher wrote: > > > > On 9/30/20 2:19 PM, Michael Catanzaro wrote: > > > On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher wrote: > > >> And what about places where NetworkManager isn't used? (Just because > > >> it's the default, doesn't mean that it's used everywhere.) > > > > > > NetworkManager is used everywhere by default. If you want to disable it, > > > you have to do manual work to do that. If you do manual work to disable > > > NetworkManager, you can also do manual work to disable systemd-resolved. > > > > Indeed, but I was responding to this: > > > > On 9/30/20 1:35 PM, Neal Gompa wrote: > > > Please, no more package splitting. And NetworkManager is used across > > > all variants of Fedora, so resolved should be installed in all places > > > where NetworkManager is used. > > > > Which (to my reading) says that because NetworkManager is the *default* > > everywhere (even though it can be uninstalled), systemd-resolved should > > be *installed* everywhere (and should not be uninstallable). I don't > > follow that logic. > > There are not a ton of advantages for splitting it, since it's only a > couple of binaries averaging 2MB with a few unit files. Given that we > require it for default NetworkManager configurations now, there's not > a lot of value in making that complicated. Splitting has a cost too, > in the form of extra metadata, upgrade paths, etc. > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > variants, as shipped today, *MUST* use NetworkManager. > NetworkManager's configuration will use resolved as a local resolver. > Anything baked into an OSTree cannot be removed anyway. > > And like it or not, all our legacy network configuration mechanisms > are deprecated and *will be removed eventually*. > > Literally the only reason networkd was split out was because Fedora > CoreOS was chainsawing it out at image build time and making it > impossible for people to use it. To be frank, I do not want more > permutations this low in the stack. It makes life incredibly difficult > for figuring out working network setups. > > My reply was aimed at Peter saying he'd like to not ship resolved, and > I'm saying that we should *not* do that, because it makes things even > harder and more complicated. So you're saying that if this doesn't work for IoT and actively causes deployment problems, potentially across millions of devices, we can't turn it off, change the option and have to basically suck it up and deal with all the problems? Well that makes Fedora completely unappealing and I feel against the project of people being able to choose. It will make people go elsewhere and frankly so will I! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
> > > > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > > > > (rpm)ostree variants are Fedora variants - please don't using phrasing > > > > implying otherwise. > > > > IOW you just say: *all* Fedora variants use NetworkManager. > > > They are not the same. Regular Fedora is considerably more > > > customizable post-installation than OSTree-based variants. That's why > > > I made that point. > > > > "All Fedora variants, both with ostree and without..." maybe? OSTree-based > > variants are also "regular Fedora". > > > > I would only even remotely consider agreeing with that premise for > Silverblue. Neither Fedora CoreOS nor Fedora IoT qualify for that, in > my view, since they completely sidestep the normal release engineering IoT is *NOT* side stepping the normal release engineering process, we're using exactly the same process, it just runs independently, just cloud cloud and container images do nightlies post release. > process, don't use the same repositories, and have the power to > include and exclude packages from the total available package set at > their leisure. Fedora IoT uses the same repositories, we don't have seprate, we do have an overrides repo so we can get fixes quicker. Matthew has expressed interest in *any* spin to be able to release whenever they are ready to enable them to release on a schedule that suits them, IoT is being uses as the proving ground for that. It doesn't mean we can pull in whatever we want and have different repositories. Please get your facts correct! > There is no expectation with those variants that anything you do will > necessarily show up there. Heck, Fedora CoreOS is reverting a > system-wide change in its variant (SQLite rpmdb), and had previously > also reverted another one (cgroup v2). The merits of those changes > aside, this makes the experience materially different than everything > else we have. > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
> > > Hi Zbyszek, > > > Would it make sense to do the same for systemd-resolved ? > > > Sounds like it has similar impact/scope wrt coreos. > > > > Yes please, I would like this for Edge/IoT too (both network/resolved) > > as there are use cases there where we'd like not to ship these too. > > > > Please, no more package splitting. And NetworkManager is used across > all variants of Fedora, so resolved should be installed in all places > where NetworkManager is used. Both Editions and Spins are allowed to deviate from defaults, like Server uses XFS and Desktops now use btrfs for filesystems. ATM I intended to leave it as it is but I want the option to be able to exclude it, and if it's not in use and we don't ship it means if there's 1000s of systems we don't need to patch if there's a CVE in those components. I think the ability to shrink and not include things not in use is important, that is the whole point of the minimisation objective after all. Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 10:26 PM, Neal Gompa wrote: > > There are not a ton of advantages for splitting it, since it's only a > couple of binaries averaging 2MB with a few unit files. Given that we > require it for default NetworkManager configurations now, there's not > a lot of value in making that complicated. Splitting has a cost too, > in the form of extra metadata, upgrade paths, etc. I think one more subpackage can won't break anything. Metadata for it is quite small. Is extra metadata and upgrade path more than one time only? Can you specify what else would be required, but Recommends: systemd-networkd in NetworkManager package? As long as disabled resolved is considered supported variant, it should not really differ. Can you be more specific about requirements? > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > variants, as shipped today, *MUST* use NetworkManager. > NetworkManager's configuration will use resolved as a local resolver. > Anything baked into an OSTree cannot be removed anyway. All non-OSTree Fedora variants can uninstall NetworkManager just fine, they use *NetworkManager by default*. We would like systemd-resolved uninstallable the same way. Because it is not the best available resolver and has long standing bugs, some of them not properly addressed. Especially to ensure systemd-resolved would not become the only one supported variant, just a default one. Is dnsmasq or unbound support considered deprecated? NetworkManager != systemd-resolved. I think NetworkManager should just Recommend: systemd-resolved. As long as [main] dns=dnsmasq or dns=unbound is still supported by NetworkManager, I think alternatives must be uninstallable. Both support split-DNS, just have missing NetworkManager configuration layer. I am dnsmasq maintainer and unbound comaintainer and I am willing to help with its implementation. I just need to know way to push information from NM to them. > > And like it or not, all our legacy network configuration mechanisms > are deprecated and *will be removed eventually*. > > Literally the only reason networkd was split out was because Fedora > CoreOS was chainsawing it out at image build time and making it > impossible for people to use it. To be frank, I do not want more > permutations this low in the stack. It makes life incredibly difficult > for figuring out working network setups. > > My reply was aimed at Peter saying he'd like to not ship resolved, and > I'm saying that we should *not* do that, because it makes things even > harder and more complicated. Things are already hard with name resolution. They are not going better with systemd upstream ignoring research of DNS specialists and instead pushing its own 'correct' ideas. And that precisely what we demand. If disabling systemd-resolved should work and be tested, it should be the same with resolved not installed. We just fear waiving disabled resolved as unsupported a bit later. -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 04:26:39PM +, Zbigniew Jędrzejewski-Szmek wrote: > In addition, two more new subpackages are created: systemd-standalone-sysusers > and systemd-standalone-tmpfiles, with custom-linked systemd-sysusers and > systemd-tmpfiles binaries. root@fedora-34:~ # dnf --quiet repoquery --repo=f34-build --list systemd |grep systemd-sysusers /usr/bin/systemd-sysusers /usr/lib/systemd/system/sysinit.target.wants/systemd-sysusers.service /usr/lib/systemd/system/systemd-sysusers.service /usr/share/man/man8/systemd-sysusers.8.gz /usr/share/man/man8/systemd-sysusers.service.8.gz root@fedora-34:~ # dnf --quiet repoquery --repo=f34-build --list systemd-standalone-sysusers |grep systemd-sysusers /usr/bin/systemd-sysusers I think systemd-standalone-sysusers package is missing the manual pages. -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Thu, Oct 01, 2020 at 11:05:18AM +0200, Petr Menšík wrote: > > > On 9/30/20 10:36 PM, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Sep 30, 2020 at 02:21:19PM -0400, Paul Wouters wrote: > >> On Wed, 30 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote: > >> > >>> the systemd package is getting a systemd-networkd subpackage split out > >>> that will contain systemd-networkd, networkctl, and the associated data > >>> files. > >>> This was requested by coreos maintainers: NetworkManager is used and > >>> skipping > >>> systemd-networkd allows the installation footprint and potential user > >>> confusion > >>> to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.) > >> > >>> The main systemd systemd package Obsoletes the -standalone- packages, so > >>> it > >>> should smoothly replace them whenever it is pulled in. > >> > >> In which package will systemd-resolved be? > > > > Still in the main rpm. I don't see a good reason to split it out. It > > can be installed without being enabled (*). And with it being enabled by > > default > > in F33, there's even less reason to do so. networkd is a few times larger > > and > > likely to grow (we're adding support for new tunnel types, new protocols, > > and new features all the time. systemd-resolved shouldn't grow too much > > beyond current size.) > Why is it important to require resolved in main package? See the extensive replies from Neal Gompa in the other part of the thread. Each split brings a maintenance cost and cognitive overhead for users. So the question is always "why should we split this out", and not "why shouldn't we"? Even for the -networkd it's almost a wash. We split it out to undo a long-standing problem in coreos. Without that preexisting history [1], it wouldn't have been split out. Thankfully we don't have a similar situation with resolved. > It contains > both daemon and lookup tool, couple of bash completion scripts and > manual pages. Reason to split it out was stated already: some people > won't be using it. It is not so small, 650k deserves own package IMHO. It's a judgment call. Apart from the problems mentioned above, since it is a default in F33+ now, after splitting it out we'd need to make sure that it is almost always pulled in. Sorry, no, that's too much fragility to save <1MB. Zbyszek [1] https://github.com/coreos/fedora-coreos-config/pull/574 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 10:36 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Sep 30, 2020 at 02:21:19PM -0400, Paul Wouters wrote: >> On Wed, 30 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote: >> >>> the systemd package is getting a systemd-networkd subpackage split out >>> that will contain systemd-networkd, networkctl, and the associated data >>> files. >>> This was requested by coreos maintainers: NetworkManager is used and >>> skipping >>> systemd-networkd allows the installation footprint and potential user >>> confusion >>> to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.) >> >>> The main systemd systemd package Obsoletes the -standalone- packages, so it >>> should smoothly replace them whenever it is pulled in. >> >> In which package will systemd-resolved be? > > Still in the main rpm. I don't see a good reason to split it out. It > can be installed without being enabled (*). And with it being enabled by > default > in F33, there's even less reason to do so. networkd is a few times larger and > likely to grow (we're adding support for new tunnel types, new protocols, > and new features all the time. systemd-resolved shouldn't grow too much > beyond current size.) Why is it important to require resolved in main package? It contains both daemon and lookup tool, couple of bash completion scripts and manual pages. Reason to split it out was stated already: some people won't be using it. It is not so small, 650k deserves own package IMHO. I think only nss-resolve has reason to be kept in main package to prevent issues with nsswitch configuring. I think over half megabyte tool, which only says: not running, sorry!, is not useful. > > (*) In general, allowing packages to be installed without being active > is much more robust. If we are depending on a package not being > present, it is easy for things go south if something pulls it in as > dependency, and we have huge dependency trees, it's sometimes it's impossible > to uninstall something because of transitive dependencies. We don't talk about allowing it installed. We demand possibility to uninstall it. systemd itself should be installed everywhere for a good reason. There is no alternative for it in Fedora. That is not true for systemd-resolved. It must not be hardwired. There exist more alternative resolution paths. It has to be possible to switch between them. Just for that reason, it should be in separate and uninstallable package. To ensure it is not too hardwired into the distribution without a good reason. > > Package need to have a reliable way to preconfigure if they will > become active after installation. In fact we already built a system like this > presets. Weird postinstall snippets are good reason to move it into separate subpackage. It makes it clear which part is related to systemd-resolved, which part is related to systemd itself. > > But I see you point: it should be possible to opt out of systemd-resolved, > and right now that's not entirely functional, because presets only decide > whether systemd-resolved.service will be enabled, and the resolv.conf symlink > manipulation is not conditionalized on that. I'll make it conditional too. Please make. Are there bugs for it? Can we help? > > Zbyszek > Cheers, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 7:14 PM, Colin Walters wrote: That's not true, you can `rpm-ostree override remove`. It'd still be there in the ostree repository on disk, but you don't see it in the "deployment" (what you actually boot into). Few people care about disk space that much, and if you do you can do custom builds. ...but can we can do that and will updates to FCOS work after? I am pretty sure currently the answer is no, unless I don't fully understand the impacts of https://github.com/coreos/fedora-coreos-tracker/issues/400 I would be making tons of package changes to my deployment of FCOS but the chance of breaking updates isn't worth it. Even after this split happens and you can install systemd-networkd will I break my updates then too? About half the people on this thread are living the experience ofhttps://xkcd.com/386/ Ehh. There has been a lot of talking past each other in this thread and in https://github.com/coreos/fedora-coreos-config/pull/574 which is the reason for this thread in the first place. All of this grief and extra work could have be avoided if we added added the ~1M of hacked out systemd-networkd binaries back into FCOS and moved on with our lives... but here we are! Joe -- Joe Doss j...@solidadmin.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 4:36 PM, Neal Gompa wrote: On Wed, Sep 30, 2020 at 5:27 PM Matthew Miller wrote: "All Fedora variants, both with ostree and without..." maybe? OSTree-based variants are also "regular Fedora". I would only even remotely consider agreeing with that premise for Silverblue. Neither Fedora CoreOS nor Fedora IoT qualify for that, in my view, since they completely sidestep the normal release engineering process, don't use the same repositories, and have the power to include and exclude packages from the total available package set at their leisure. There is no expectation with those variants that anything you do will necessarily show up there. Heck, Fedora CoreOS is reverting a system-wide change in its variant (SQLite rpmdb), and had previously also reverted another one (cgroup v2). The merits of those changes aside, this makes the experience materially different than everything else we have. This is a pretty good point Neal. Let's take cgroups v2 for example. The expectation of Fedora 32 having cgroups v2 is pretty clear, but stable FCOS which is based off of Fedora 32 has cgroups v1 enabled instead. This is a pretty jarring experience when you are moving from say Fedora 32 Cloud to FCOS 32.20200907.3.0. Both say Fedora 32 in their versions, but have a totally different technical experience when it comes to cgroups. Same can be said with systemd-networkd, but I won't rehash what is already said in https://github.com/coreos/fedora-coreos-config/pull/574 FCOS and Fedora IOT carry the Fedora name but they break ranks with the rest of Fedora in terms of packages, release engineering, and Fedora wide changes. This leads to frustrating experiences as a Fedora user because the technical expectations of what should be Fedora wide technical stances are a moving target for these variants. Joe -- Joe Doss j...@solidadmin.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020, at 5:20 PM, Neal Gompa wrote: > Regular Fedora variants are installed via normal package management > actions and have full granularity. RPM-OSTree reduces the granularity > of the operating system to a singular image that you layer on top. But > you cannot pull out stuff from the image. That's not true, you can `rpm-ostree override remove`. It'd still be there in the ostree repository on disk, but you don't see it in the "deployment" (what you actually boot into). Few people care about disk space that much, and if you do you can do custom builds. About half the people on this thread are living the experience of https://xkcd.com/386/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 2:34 PM, Paul Wouters wrote: > And as I indicated earlier, most server installs have no use for > systemd-resolved. Yes it can be disabled, but we didn't go all the > way to virtual servers and containers to have to install things > we will never use. +1, & simply 'minimal' installs ... > The ask I have is very small. When I install and upgrade, no? > a server via kickstart, > I want to be able to do a minimum install, and that it should be > possible that this does not include systemd-resolved". it'd be nice-to-have to have that level of granularity/selection in an Anaconda minimal server install, as well. > I have explained my use case, and I believe it is _very_ common use case. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 5:27 PM Matthew Miller wrote: > > On Wed, Sep 30, 2020 at 04:32:07PM -0400, Neal Gompa wrote: > > > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > > > (rpm)ostree variants are Fedora variants - please don't using phrasing > > > implying otherwise. > > > IOW you just say: *all* Fedora variants use NetworkManager. > > They are not the same. Regular Fedora is considerably more > > customizable post-installation than OSTree-based variants. That's why > > I made that point. > > "All Fedora variants, both with ostree and without..." maybe? OSTree-based > variants are also "regular Fedora". > I would only even remotely consider agreeing with that premise for Silverblue. Neither Fedora CoreOS nor Fedora IoT qualify for that, in my view, since they completely sidestep the normal release engineering process, don't use the same repositories, and have the power to include and exclude packages from the total available package set at their leisure. There is no expectation with those variants that anything you do will necessarily show up there. Heck, Fedora CoreOS is reverting a system-wide change in its variant (SQLite rpmdb), and had previously also reverted another one (cgroup v2). The merits of those changes aside, this makes the experience materially different than everything else we have. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, 30 Sep 2020, Neal Gompa wrote: since it's only a couple of binaries averaging 2MB with a few unit files. My reply was aimed at Peter saying he'd like to not ship resolved, and I'm saying that we should *not* do that, because it makes things even harder and more complicated. These two statements cannot both we true. And as I indicated earlier, most server installs have no use for systemd-resolved. Yes it can be disabled, but we didn't go all the way to virtual servers and containers to have to install things we will never use. So I would like to know more about how this would "make things even harder and more complicated". The ask I have is very small. When I install a server via kickstart, I want to be able to do a minimum install, and that it should be possible that this does not include systemd-resolved". I have explained my use case, and I believe it is _very_ common use case. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 04:32:07PM -0400, Neal Gompa wrote: > > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > > (rpm)ostree variants are Fedora variants - please don't using phrasing > > implying otherwise. > > IOW you just say: *all* Fedora variants use NetworkManager. > They are not the same. Regular Fedora is considerably more > customizable post-installation than OSTree-based variants. That's why > I made that point. "All Fedora variants, both with ostree and without..." maybe? OSTree-based variants are also "regular Fedora". -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 4:45 PM PGNet Dev wrote: > > anyone else more confused? > > On 9/30/20 1:26 PM, Neal Gompa wrote: > > And like it or not, all our legacy network configuration mechanisms > > are deprecated and*will be removed eventually*. > > is plain-vanilla systemd-networkd -- no NM wrapper around it, no (in)direct > dependency on systemd-resolved -- considered 'legacy'? > NetworkManager never uses networkd. But when I refer to legacy setups, I'm referring to everything related to ifcfg and legacy network-scripts. Insofar as networkd goes, I wouldn't consider it legacy, but I would also not consider it contemporary, since nobody bothered to make it useful enough to support all the cases that Wicked and NetworkManager support. > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > variants, as shipped today, *MUST* use NetworkManager. > > how 'bout I turn the question around ... > > what specific steps must be done POST- F32->F32 upgrade to > > (1) not use NetworkManager > (2) not use systemd-resolved > > (3) return/preserve local configs for systemd-networkd & 'enterprise' > (own resolver) DNS configs? > > ? > > > Regular Fedora is considerably more > customizable post-installation than OSTree-based variants. > > For those of us that don't live the lingo, it's not exactly clear > what 'Regular Fedora' is. > Regular Fedora variants are installed via normal package management actions and have full granularity. RPM-OSTree reduces the granularity of the operating system to a singular image that you layer on top. But you cannot pull out stuff from the image. > Is there _any_ variant of Fedora that's immune now, and in the planned > future, from "use NetworkManger" and (therefore) systemd-resolved? > > Iiuc, the upgrades WILL install/enable systemd-resolved; that's post-upgrade > maintenance that apparently needs to be planned for -- as long as its still > doable. > > If/when does that no longer remain an option? If you want to deactivate resolved and use something else, you can. If you did so prior to upgrading to F33, that will persist. Only users who didn't do anything would get the change. One of my machines uses dnsmasq and I have NetworkManager configured with that. That does not break with the move to Fedora 33, since I set it up that way. I'm sure there are people running NetworkManager with unbound, and I expect that to stay working too. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 01:45:13PM -0700, PGNet Dev wrote: > anyone else more confused? > > On 9/30/20 1:26 PM, Neal Gompa wrote: > > And like it or not, all our legacy network configuration mechanisms > > are deprecated and*will be removed eventually*. > > is plain-vanilla systemd-networkd -- no NM wrapper around it, no (in)direct > dependency on systemd-resolved -- considered 'legacy'? NM does not wrap systemd-networkd. Both remain fully independent ways to configure networking. The future of systemd-networkd is unclear: it is being developed upstream, but is largely unused in Fedora. It does work well in certain scenarios, as you know. I don't think there's any plan to change this. > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > variants, as shipped today, *MUST* use NetworkManager. > > how 'bout I turn the question around ... > > what specific steps must be done POST- F32->F32 upgrade to > > (1) not use NetworkManager > (2) not use systemd-resolved > > (3) return/preserve local configs for systemd-networkd & 'enterprise' > (own resolver) DNS configs? I don't think there's anything special needed for (1) and (3). For (2), please create a preset to disable systemd-resolved. E.g.: echo 'disable systemd-resolved.service' >/etc/systemd/system-preset/20-resolved.preset This will start being enough with the next systemd build though. I just pushed a change to not create the symlink if resolved is disabled: https://src.fedoraproject.org/rpms/systemd/c/d3d43af8adf70974f5e52d31df0b46935ff2ded2?branch=f33. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 12:59:20PM -0400, Matthew Miller wrote: > On Wed, Sep 30, 2020 at 06:50:08PM +0200, Miro Hrončok wrote: > > >The main systemd systemd package Obsoletes the -standalone- packages, so it > > >should smoothly replace them whenever it is pulled in. > > > > I am confused by this bit. If systemd package Obsoletes the > > -standalone- packages, installing them is not possible unless you > > explicitly exclude systemd from the transaction and keep it excluded > > for upgrades. > > I expect so, if the use case is containers that will be replaced instead of > upgraded. The idea is that if you have an installation which does not need systemd, but want sysusers or tmpfiles, then you can pull in the -standalone- versions. They both have files that conflict with the main package, and declare Conflicts with it. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
anyone else more confused? On 9/30/20 1:26 PM, Neal Gompa wrote: > And like it or not, all our legacy network configuration mechanisms > are deprecated and*will be removed eventually*. is plain-vanilla systemd-networkd -- no NM wrapper around it, no (in)direct dependency on systemd-resolved -- considered 'legacy'? > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree variants, as shipped today, *MUST* use NetworkManager. how 'bout I turn the question around ... what specific steps must be done POST- F32->F32 upgrade to (1) not use NetworkManager (2) not use systemd-resolved (3) return/preserve local configs for systemd-networkd & 'enterprise' (own resolver) DNS configs? ? > Regular Fedora is considerably more customizable post-installation than OSTree-based variants. For those of us that don't live the lingo, it's not exactly clear what 'Regular Fedora' is. Is there _any_ variant of Fedora that's immune now, and in the planned future, from "use NetworkManger" and (therefore) systemd-resolved? Iiuc, the upgrades WILL install/enable systemd-resolved; that's post-upgrade maintenance that apparently needs to be planned for -- as long as its still doable. If/when does that no longer remain an option? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/2020 1:26 PM, Neal Gompa wrote: On Wed, Sep 30, 2020 at 3:42 PM Ian Pilcher wrote: On 9/30/20 2:19 PM, Michael Catanzaro wrote: On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher wrote: And what about places where NetworkManager isn't used? (Just because it's the default, doesn't mean that it's used everywhere.) NetworkManager is used everywhere by default. If you want to disable it, you have to do manual work to do that. If you do manual work to disable NetworkManager, you can also do manual work to disable systemd-resolved. Indeed, but I was responding to this: On 9/30/20 1:35 PM, Neal Gompa wrote: > Please, no more package splitting. And NetworkManager is used across > all variants of Fedora, so resolved should be installed in all places > where NetworkManager is used. Which (to my reading) says that because NetworkManager is the *default* everywhere (even though it can be uninstalled), systemd-resolved should be *installed* everywhere (and should not be uninstallable). I don't follow that logic. There are not a ton of advantages for splitting it, since it's only a couple of binaries averaging 2MB with a few unit files. Given that we require it for default NetworkManager configurations now, there's not a lot of value in making that complicated. Splitting has a cost too, in the form of extra metadata, upgrade paths, etc. Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree variants, as shipped today, *MUST* use NetworkManager. NetworkManager's configuration will use resolved as a local resolver. Anything baked into an OSTree cannot be removed anyway. And like it or not, all our legacy network configuration mechanisms are deprecated and *will be removed eventually*. Literally the only reason networkd was split out was because Fedora CoreOS was chainsawing it out at image build time and making it impossible for people to use it. To be frank, I do not want more permutations this low in the stack. It makes life incredibly difficult for figuring out working network setups. Splitting it out this low in the stack makes it easier to support (and create) cases where it's not used. What Fedora decides here still has knock-on effects downstream, including what EL users deal with. If there's a logical separation (and there is, and always has been), then discrete packages allow competent SA's to reduce on-system complexity. That really should be all the justification necessary IMHO. -jc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 02:21:19PM -0400, Paul Wouters wrote: > On Wed, 30 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote: > > >the systemd package is getting a systemd-networkd subpackage split out > >that will contain systemd-networkd, networkctl, and the associated data > >files. > >This was requested by coreos maintainers: NetworkManager is used and skipping > >systemd-networkd allows the installation footprint and potential user > >confusion > >to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.) > > >The main systemd systemd package Obsoletes the -standalone- packages, so it > >should smoothly replace them whenever it is pulled in. > > In which package will systemd-resolved be? Still in the main rpm. I don't see a good reason to split it out. It can be installed without being enabled (*). And with it being enabled by default in F33, there's even less reason to do so. networkd is a few times larger and likely to grow (we're adding support for new tunnel types, new protocols, and new features all the time. systemd-resolved shouldn't grow too much beyond current size.) (*) In general, allowing packages to be installed without being active is much more robust. If we are depending on a package not being present, it is easy for things go south if something pulls it in as dependency, and we have huge dependency trees, it's sometimes it's impossible to uninstall something because of transitive dependencies. Package need to have a reliable way to preconfigure if they will become active after installation. In fact we already built a system like this presets. But I see you point: it should be possible to opt out of systemd-resolved, and right now that's not entirely functional, because presets only decide whether systemd-resolved.service will be enabled, and the resolv.conf symlink manipulation is not conditionalized on that. I'll make it conditional too. Zbyszek > With enterprise server deployments, DNS will be managed by the network > via resolve.conf to enterprise DNS servers. These servers tend to have > "bind views" for different category of deployments. These deployments > will have no VPN, no mDNS requirements etc. They also do not need (and > most likely do not want) DNS caching. > > I believe it would be useful for kickstart installs to not install > systemd-resolved for these kind of typical server deployments. I think > this is an important use case to support. > > For Desktop systems, it could default to installing systemd-resolved. It > could even default to it for all installs including Server, as long as > the administrator has the option to not install it via a kickstart file. > > It also allows those Destop users that want to use their own validating > resolvers on the end node to uninstall systemd-resolved. > > If there are strong reasons not to split systemd-resolved in its own > package, I would like to better understand these reasons. > > Paul > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 4:29 PM Colin Walters wrote: > > > > On Wed, Sep 30, 2020, at 4:26 PM, Neal Gompa wrote: > > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > > (rpm)ostree variants are Fedora variants - please don't using phrasing > implying otherwise. > > IOW you just say: *all* Fedora variants use NetworkManager. > They are not the same. Regular Fedora is considerably more customizable post-installation than OSTree-based variants. That's why I made that point. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020, at 4:26 PM, Neal Gompa wrote: > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree (rpm)ostree variants are Fedora variants - please don't using phrasing implying otherwise. IOW you just say: *all* Fedora variants use NetworkManager. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 02:21:19PM -0400, Paul Wouters wrote: > With enterprise server deployments, DNS will be managed by the network > via resolve.conf to enterprise DNS servers. These servers tend to have > "bind views" for different category of deployments. These deployments > will have no VPN, no mDNS requirements etc. They also do not need (and > most likely do not want) DNS caching. I think all enterprise servers can benefit from having a local DNS server, whether that server caches or not, because that is the best way to fix/work around the broken C APIs for name resolution that doesn't handle DNS server failover very well. That doesn't mean I'm against splitting out systemd-resolved into a separate package, though. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 3:42 PM Ian Pilcher wrote: > > On 9/30/20 2:19 PM, Michael Catanzaro wrote: > > On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher wrote: > >> And what about places where NetworkManager isn't used? (Just because > >> it's the default, doesn't mean that it's used everywhere.) > > > > NetworkManager is used everywhere by default. If you want to disable it, > > you have to do manual work to do that. If you do manual work to disable > > NetworkManager, you can also do manual work to disable systemd-resolved. > > Indeed, but I was responding to this: > > On 9/30/20 1:35 PM, Neal Gompa wrote: > > Please, no more package splitting. And NetworkManager is used across > > all variants of Fedora, so resolved should be installed in all places > > where NetworkManager is used. > > Which (to my reading) says that because NetworkManager is the *default* > everywhere (even though it can be uninstalled), systemd-resolved should > be *installed* everywhere (and should not be uninstallable). I don't > follow that logic. There are not a ton of advantages for splitting it, since it's only a couple of binaries averaging 2MB with a few unit files. Given that we require it for default NetworkManager configurations now, there's not a lot of value in making that complicated. Splitting has a cost too, in the form of extra metadata, upgrade paths, etc. Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree variants, as shipped today, *MUST* use NetworkManager. NetworkManager's configuration will use resolved as a local resolver. Anything baked into an OSTree cannot be removed anyway. And like it or not, all our legacy network configuration mechanisms are deprecated and *will be removed eventually*. Literally the only reason networkd was split out was because Fedora CoreOS was chainsawing it out at image build time and making it impossible for people to use it. To be frank, I do not want more permutations this low in the stack. It makes life incredibly difficult for figuring out working network setups. My reply was aimed at Peter saying he'd like to not ship resolved, and I'm saying that we should *not* do that, because it makes things even harder and more complicated. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 2:19 PM, Michael Catanzaro wrote: On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher wrote: And what about places where NetworkManager isn't used? (Just because it's the default, doesn't mean that it's used everywhere.) NetworkManager is used everywhere by default. If you want to disable it, you have to do manual work to do that. If you do manual work to disable NetworkManager, you can also do manual work to disable systemd-resolved. Indeed, but I was responding to this: On 9/30/20 1:35 PM, Neal Gompa wrote: > Please, no more package splitting. And NetworkManager is used across > all variants of Fedora, so resolved should be installed in all places > where NetworkManager is used. Which (to my reading) says that because NetworkManager is the *default* everywhere (even though it can be uninstalled), systemd-resolved should be *installed* everywhere (and should not be uninstallable). I don't follow that logic. -- In Soviet Russia, Google searches you! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher wrote: And what about places where NetworkManager isn't used? (Just because it's the default, doesn't mean that it's used everywhere.) NetworkManager is used everywhere by default. If you want to disable it, you have to do manual work to do that. If you do manual work to disable NetworkManager, you can also do manual work to disable systemd-resolved. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 1:35 PM, Neal Gompa wrote: Please, no more package splitting. And NetworkManager is used across all variants of Fedora, so resolved should be installed in all places where NetworkManager is used. And what about places where NetworkManager isn't used? (Just because it's the default, doesn't mean that it's used everywhere.) -- In Soviet Russia, Google searches you! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 12:48 PM Peter Robinson wrote: > > > Hi Zbyszek, > > Would it make sense to do the same for systemd-resolved ? > > Sounds like it has similar impact/scope wrt coreos. > > Yes please, I would like this for Edge/IoT too (both network/resolved) > as there are use cases there where we'd like not to ship these too. > Please, no more package splitting. And NetworkManager is used across all variants of Fedora, so resolved should be installed in all places where NetworkManager is used. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 11:21 AM, Paul Wouters wrote: > It also allows those Destop users that want to use their own validating > resolvers on the end node to uninstall systemd-resolved. Would separating the package preserve existing setups across upgrades? It's not simply Enterprise/Server 'or' Desktops that use "own validating resolvers". Here, that's standard/default for both. Ideally, a mechanism to "leave existing configs as is", without exceptional intervention -- using kickstart, re-UNinstalling or re-DISabling after upgrade -- would be preferred. I'm all for new capabilities. What's concerning is the insistence on monkeying with (long) established, and perfectly viable/standard configurations. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, 30 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote: the systemd package is getting a systemd-networkd subpackage split out that will contain systemd-networkd, networkctl, and the associated data files. This was requested by coreos maintainers: NetworkManager is used and skipping systemd-networkd allows the installation footprint and potential user confusion to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.) The main systemd systemd package Obsoletes the -standalone- packages, so it should smoothly replace them whenever it is pulled in. In which package will systemd-resolved be? With enterprise server deployments, DNS will be managed by the network via resolve.conf to enterprise DNS servers. These servers tend to have "bind views" for different category of deployments. These deployments will have no VPN, no mDNS requirements etc. They also do not need (and most likely do not want) DNS caching. I believe it would be useful for kickstart installs to not install systemd-resolved for these kind of typical server deployments. I think this is an important use case to support. For Desktop systems, it could default to installing systemd-resolved. It could even default to it for all installs including Server, as long as the administrator has the option to not install it via a kickstart file. It also allows those Destop users that want to use their own validating resolvers on the end node to uninstall systemd-resolved. If there are strong reasons not to split systemd-resolved in its own package, I would like to better understand these reasons. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, Sep 30, 2020 at 06:50:08PM +0200, Miro Hrončok wrote: > >The main systemd systemd package Obsoletes the -standalone- packages, so it > >should smoothly replace them whenever it is pulled in. > > I am confused by this bit. If systemd package Obsoletes the > -standalone- packages, installing them is not possible unless you > explicitly exclude systemd from the transaction and keep it excluded > for upgrades. I expect so, if the use case is containers that will be replaced instead of upgraded. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 30. 09. 20 18:26, Zbigniew Jędrzejewski-Szmek wrote: The main systemd systemd package Obsoletes the -standalone- packages, so it should smoothly replace them whenever it is pulled in. I am confused by this bit. If systemd package Obsoletes the -standalone- packages, installing them is not possible unless you explicitly exclude systemd from the transaction and keep it excluded for upgrades. Is that the idea? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
> Hi Zbyszek, > Would it make sense to do the same for systemd-resolved ? > Sounds like it has similar impact/scope wrt coreos. Yes please, I would like this for Edge/IoT too (both network/resolved) as there are use cases there where we'd like not to ship these too. Peter > On Wed, 2020-09-30 at 16:26 +, Zbigniew Jędrzejewski-Szmek wrote: > > Hi, > > > > the systemd package is getting a systemd-networkd subpackage split out > > that will contain systemd-networkd, networkctl, and the associated data > > files. > > This was requested by coreos maintainers: NetworkManager is used and > > skipping > > systemd-networkd allows the installation footprint and potential user > > confusion > > to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.) > > > > Appropriate Obsoletes are added on both the main package and the new > > systemd-networkd subpackage, so the systemd-networkd subpackage should > > be installed on upgrades. In addition, the new subpackage has Recommends > > from > > the main package, so it will be installed in normal installations. The split > > affects installations with --setopt=install_weak_deps=False. Please make > > sure > > to pull in systemd-networkd.rpm independently if needed. Also note that > > systemd-networkd.service was preset as *disabled* in Fedora, which means > > that > > unless it was enabled by the user, the removal of systemd-networkd wouldn't > > have an effect. > > > > In addition, two more new subpackages are created: > > systemd-standalone-sysusers > > and systemd-standalone-tmpfiles, with custom-linked systemd-sysusers and > > systemd-tmpfiles binaries. They packages are 170kB and 260kB and pull in > > much > > less dependencies compared to the normal systemd package (only glibc, > > libselinux, > > and libacl). The goal here is to be able to use those packages in limited > > environments where systemd itself is not necessary. > > > > The main systemd systemd package Obsoletes the -standalone- packages, so it > > should smoothly replace them whenever it is pulled in. > > > > This change was done in systemd-246.6-2.fc34 in rawhide right now. (There > > are > > some cleanups to move more files to the -networkd subpackage in the works > > for > > 246.6-3.fc34). Please give this a spin and report any issues. > > > > The plan is to also do this split for F33 if no issues are noted in rawhide. > > > > Zbyszek > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > -- > Simo Sorce > RHEL Crypto Team > Red Hat, Inc > > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
Hi Zbyszek, Would it make sense to do the same for systemd-resolved ? Sounds like it has similar impact/scope wrt coreos. On Wed, 2020-09-30 at 16:26 +, Zbigniew Jędrzejewski-Szmek wrote: > Hi, > > the systemd package is getting a systemd-networkd subpackage split out > that will contain systemd-networkd, networkctl, and the associated data files. > This was requested by coreos maintainers: NetworkManager is used and skipping > systemd-networkd allows the installation footprint and potential user > confusion > to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.) > > Appropriate Obsoletes are added on both the main package and the new > systemd-networkd subpackage, so the systemd-networkd subpackage should > be installed on upgrades. In addition, the new subpackage has Recommends from > the main package, so it will be installed in normal installations. The split > affects installations with --setopt=install_weak_deps=False. Please make sure > to pull in systemd-networkd.rpm independently if needed. Also note that > systemd-networkd.service was preset as *disabled* in Fedora, which means that > unless it was enabled by the user, the removal of systemd-networkd wouldn't > have an effect. > > In addition, two more new subpackages are created: systemd-standalone-sysusers > and systemd-standalone-tmpfiles, with custom-linked systemd-sysusers and > systemd-tmpfiles binaries. They packages are 170kB and 260kB and pull in much > less dependencies compared to the normal systemd package (only glibc, > libselinux, > and libacl). The goal here is to be able to use those packages in limited > environments where systemd itself is not necessary. > > The main systemd systemd package Obsoletes the -standalone- packages, so it > should smoothly replace them whenever it is pulled in. > > This change was done in systemd-246.6-2.fc34 in rawhide right now. (There are > some cleanups to move more files to the -networkd subpackage in the works for > 246.6-3.fc34). Please give this a spin and report any issues. > > The plan is to also do this split for F33 if no issues are noted in rawhide. > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
Hi, the systemd package is getting a systemd-networkd subpackage split out that will contain systemd-networkd, networkctl, and the associated data files. This was requested by coreos maintainers: NetworkManager is used and skipping systemd-networkd allows the installation footprint and potential user confusion to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.) Appropriate Obsoletes are added on both the main package and the new systemd-networkd subpackage, so the systemd-networkd subpackage should be installed on upgrades. In addition, the new subpackage has Recommends from the main package, so it will be installed in normal installations. The split affects installations with --setopt=install_weak_deps=False. Please make sure to pull in systemd-networkd.rpm independently if needed. Also note that systemd-networkd.service was preset as *disabled* in Fedora, which means that unless it was enabled by the user, the removal of systemd-networkd wouldn't have an effect. In addition, two more new subpackages are created: systemd-standalone-sysusers and systemd-standalone-tmpfiles, with custom-linked systemd-sysusers and systemd-tmpfiles binaries. They packages are 170kB and 260kB and pull in much less dependencies compared to the normal systemd package (only glibc, libselinux, and libacl). The goal here is to be able to use those packages in limited environments where systemd itself is not necessary. The main systemd systemd package Obsoletes the -standalone- packages, so it should smoothly replace them whenever it is pulled in. This change was done in systemd-246.6-2.fc34 in rawhide right now. (There are some cleanups to move more files to the -networkd subpackage in the works for 246.6-3.fc34). Please give this a spin and report any issues. The plan is to also do this split for F33 if no issues are noted in rawhide. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
