On Thu, Oct 1, 2020 at 9:06 AM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > On Thu, Oct 1, 2020 at 1:53 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > On Thu, Oct 1, 2020 at 8:34 AM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > > > > > On Wed, Sep 30, 2020 at 9:27 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > > > > > On Wed, Sep 30, 2020 at 3:42 PM Ian Pilcher <arequipeno@xxxxxxxxx> wrote: > > > > > > > > > > On 9/30/20 2:19 PM, Michael Catanzaro wrote: > > > > > > On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher <arequipeno@xxxxxxxxx> 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 > broken. That particular use-case is why we're making this change, so I don't understand how it would be broken. This change makes it so that when network traffic is being made to systems that are available through the tunnel, you can successfully configure things so that everything goes through that tunnel, including DNS queries. Essentially, split-horizon DNS setups on Fedora systems become possible with this change. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
