Sorry to hear that happened. Cockpit depends on Network manager to

provide it's network functionality. Network manager is pretty standard part of many linux distros. Having the cockpit-networking package depend on it is not a mistake, it needs to be there to ensure that cockpit has what it needs to run.

I'm not sure how removing cockpit would bork a server though. I've been

able to install and uninstall cockpit-networking on lots of systems without issues. Do you have any more details you can provide us? What Version/OS was this on? which commands did you run? A way for us to reproduce the errors you had would be helpful.

It was simple. Dnf remove Cockpit -> removed network manager, which I did not notice for several months. Server reboot -> all DNS related things have suddenly failed.

It was either Fedora server 25, or cloud base 25 images. Essentially anything that ships with Cockpit should have NM "installed first" (marked, etc..) so DNF knows that we actually want it there, regardless of Cockpit. Or whatever other solution that would prevent it be uninstalled while maintaining the rest of the usual functionality of dnf. Changing dnf configuration is not exactly the best solution...

Radka

------------------------------ *Radka Janeková* .NET & OpenShift Engineer, Red Hat *radka.janek@redhat.com radka.janek@redhat.com* IRC: radka | Freenode: Rhea

On Tue, Oct 17, 2017 at 3:59 AM, Peter petervo@redhat.com wrote:

Sorry to hear that happened. Cockpit depends on Network manager to provide it's network functionality. Network manager is pretty standard part of many linux distros. Having the cockpit-networking package depend on it is not a mistake, it needs to be there to ensure that cockpit has what it needs to run.

I'm not sure how removing cockpit would bork a server though. I've been able to install and uninstall cockpit-networking on lots of systems without issues. Do you have any more details you can provide us? What Version/OS was this on? which commands did you run? A way for us to reproduce the errors you had would be helpful.

On 10/16/2017 06:20 PM, Radka Janekova wrote:

...

Hi,

so recently I managed to destroy[1] two production servers by removing what I saw as useless web-config utility. Apparently Cockpit depends on NetworkManager, which nobody would expect and is easily overlooked.

PLEASE FIX

[1] https://cloud.rhea-ayase.eu/s/eH6JX43kYErHJ3s

Cheers, Radka

---

*Radka Janeková* .NET & OpenShift Engineer, Red Hat *radka.janek@redhat.com mailto:radka.janek@redhat.com* IRC: radka | Freenode: Rhea

---

cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedo rahosted.org

---

cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org

Just upgraded to 26. I believe that this is an issue with every Fedora type that ships Cockpit though...

NAME=Fedora VERSION="26 (Cloud Edition)" ID=fedora VERSION_ID=26 PRETTY_NAME="Fedora 26 (Cloud Edition)" ANSI_COLOR="0;34" CPE_NAME="cpe:/o:fedoraproject:fedora:26" HOME_URL="https://fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=26 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=26 PRIVACY_POLICY_URL=https://fedoraproject.org/wiki/Legal:PrivacyPolicy VARIANT="Cloud Edition" VARIANT_ID=cloud

Radka

------------------------------ *Radka Janeková* .NET & OpenShift Engineer, Red Hat *radka.janek@redhat.com radka.janek@redhat.com* IRC: radka | Freenode: Rhea

On Tue, Oct 17, 2017 at 11:48 AM, Stef Walter stefw@redhat.com wrote:

On 17.10.2017 11:24, Radka Janekova wrote:

...

...

Sorry to hear that happened. Cockpit depends on Network manager to

provide it's network functionality. Network manager is pretty standard part of many linux distros. Having the cockpit-networking package depend on it is not a mistake, it needs to be there to ensure that cockpit has what it needs to run.

...

I'm not sure how removing cockpit would bork a server though. I've

been able to install and uninstall cockpit-networking on lots of systems without issues. Do you have any more details you can provide us? What Version/OS was this on? which commands did you run? A way for us to reproduce the errors you had would be helpful.

It was simple. Dnf remove Cockpit -> removed network manager, which I did not notice for several months. Server reboot -> all DNS related things have suddenly failed.

It was either Fedora server 25, or cloud base 25 images. Essentially anything that ships with Cockpit should have NM "installed first" (marked, etc..) so DNF knows that we actually want it there, regardless of Cockpit. Or whatever other solution that would prevent it be uninstalled while maintaining the rest of the usual functionality of dnf. Changing dnf configuration is not exactly the best solution...

If this happens, then this is a bug in Fedora Server (or Cloud). Can you post /etc/os-release?

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?

Cheers,

Stef

...

---

*Radka Janeková* .NET & OpenShift Engineer, Red Hat *radka.janek@redhat.com mailto:radka.janek@redhat.com* IRC: radka | Freenode: Rhea

On Tue, Oct 17, 2017 at 3:59 AM, Peter <petervo@redhat.com mailto:petervo@redhat.com> wrote:

Sorry to hear that happened. Cockpit depends on Network manager to
provide it's network functionality. Network manager is pretty
standard part of many linux distros. Having the cockpit-networking
package depend on it is not a mistake, it needs to be there to
ensure that cockpit has what it needs to run.

I'm not sure how removing cockpit would bork a server though. I've
been able to install and uninstall cockpit-networking on lots of
systems without issues. Do you have any more details you can provide
us? What Version/OS was this on? which commands did you run? A way
for us to reproduce the errors you had would be helpful.

On 10/16/2017 06:20 PM, Radka Janekova wrote:

    Hi,

    so recently I managed to destroy[1] two production servers by
    removing what I saw as useless web-config utility. Apparently
    Cockpit depends on NetworkManager, which nobody would expect and
    is easily overlooked.

    PLEASE FIX

    [1] https://cloud.rhea-ayase.eu/s/eH6JX43kYErHJ3s
    <https://cloud.rhea-ayase.eu/s/eH6JX43kYErHJ3s>

    Cheers,
    Radka
    ------------------------------------------------------------

---

...

    *Radka Janeková*
    .NET & OpenShift Engineer, Red Hat
    *radka.janek@redhat.com <mailto:radka.janek@redhat.com>
    <mailto:radka.janek@redhat.com <mailto:radka.janek@redhat.com>>*
    IRC: radka | Freenode: Rhea



    _______________________________________________
    cockpit-devel mailing list --
    cockpit-devel@lists.fedorahosted.org
    <mailto:cockpit-devel@lists.fedorahosted.org>
    To unsubscribe send an email to
    cockpit-devel-leave@lists.fedorahosted.org
    <mailto:cockpit-devel-leave@lists.fedorahosted.org>

_______________________________________________
cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org
<mailto:cockpit-devel@lists.fedorahosted.org>
To unsubscribe send an email to
cockpit-devel-leave@lists.fedorahosted.org
<mailto:cockpit-devel-leave@lists.fedorahosted.org>

---

cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.

fedorahosted.org

...

---

cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org

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.

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").

(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:.

Martin

On Tue, Oct 17, 2017 at 9:19 AM Martin Pitt martin@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.

On Tue, Oct 17, 2017 at 10:17 AM Radka Janekova radka.janek@redhat.com wrote:

...

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.

Hmm, I wonder if this might actually be a bug in the way that Digital Ocean creates those images, then. It definitely adds Cockpit above and beyond what we normally ship in the cloud image. So probably their image-creation script should be updated to mark NetworkManager appropriately, if it's going to end up actually using it. That's not really something we have control over though.