That being said, elsewhere in the thread it was reported that the
original poster was using Cloud Edition, not Server Edition. This
environment group does NOT pull in NetworkManager or Cockpit by default. So
if Cockpit was installed manually it would have pulled NM in as a
dependency solely of Cockpit.
The case I posted is digital ocean standard fedora, and it comes with
cockpit (or did back then...) Even if it was manually installed, shouldn't
it revert configuration back when it's uninstalled? It left behind a
/etc/resolv.conf simlink to nonexistent NetworkManager file.
Radka
------------------------------
*Radka Janeková*
.NET & OpenShift Engineer, Red Hat
*radka.janek(a)redhat.com <radka.janek(a)redhat.com>*
IRC: radka | Freenode: Rhea
On Tue, Oct 17, 2017 at 3:34 PM, Stephen Gallagher <sgallagh(a)redhat.com>
wrote:
On Tue, Oct 17, 2017 at 9:19 AM Martin Pitt <martin(a)piware.de> wrote:
> Hello all,
>
> Stef Walter [2017-10-17 11:48 +0200]:
> > This is a distro specific packaging/dependency bug and not a bug in
> Cockpit.
> >
> > Stephen, should we file a Fedora bug about this? Any ideas which
> component?
>
> There is a (slightly political) decision to make first. Based on that,
> there
> are different solutions:
>
> (1) If the *intention* is that Fedora Server should have NM by default,
> then
> this should be added do the explicit list of "top-level packages"
> that the
> OS installer image is built from.
>
This is already done. The Fedora Server Edition environment group includes
both the @headless-management and @networkmanager-submodules package
groups. Additionally, the fedora-release-server package explicitly
Requires: NetworkManager. (So if you remove it, the system stops reporting
itself as being Server Edition and becomes unbranded Fedora).
>
> After installing all packages, the installer should mark all these
> "top-level" packages as manually installed (dnf mark install), so
> that
> they don't suffer from this automatic cleanup. (This is what the
> Debian/Ubuntu installer does, with "apt-mark").
>
Perhaps.
>
> (2) If the intention is that Fedora Server should by default manage its
> networking with something else (networkd, or the old sysconfig
> scripts
> or whatnot), as many people don't like NM on their server, then it
> shouldn't install cockpit-networkmanager by default either. In that
> case
> we should lower the recommends from the "cockpit" metapackage to
> Suggests:.
>
>
Server Edition very explicitly considers Network Manager to be the
official network stack.
That being said, elsewhere in the thread it was reported that the original
poster was using Cloud Edition, not Server Edition. This environment group
does NOT pull in NetworkManager or Cockpit by default. So if Cockpit was
installed manually it would have pulled NM in as a dependency solely of
Cockpit.
So it's probably *correct* that NM wasn't marked as separately installed
in this case. The bug then is that NM apparently became promoted to the
main network stack somehow, such that its removal caused problems. I saw
something about "DNS not working", but not with enough context to go on.
I think things are probably functioning as *designed* here, but the design
doesn't account for unknowing actions on the part of the end-user. I have
always been (and continue to be) opposed to the setting of
clean_requirements_on_remove by default.
_______________________________________________
cockpit-devel mailing list -- cockpit-devel(a)lists.fedorahosted.org
To unsubscribe send an email to cockpit-devel-leave(a)lists.fedorahosted.org