On 06/07/2016 05:05 AM, James Hogarth wrote:

On 7 Jun 2016 12:44, "Emmett Culley" lst_manage@webengineer.com wrote:

...

I have a number of machines (hardware and VMs) running CentOS 7. I all

cases firewall-config is not functional.

...

First, the service check boxes are not functional. When you click on

one, it don't change to "checked", and nothing changes on the firewall. However you do see a "Changes applied"

...

Sometimes, f you go to permanent mode and attempt to edit a zone, the

whole desktop locks up as soon as you click on the default target dropdown.

...

When I run firewall-config from the command line I see the following:

---

org.freedesktop.DBus.Error.ServiceUnknown: The name

org.freedesktop.NetworkManager was not provided by any .service files

...

(firewall-config:5079): Gtk-CRITICAL **: gtk_tree_view_get_path_at_pos:

assertion 'tree_view != NULL' failed

...

---

with the second line repeating many times and often while attempting to

interact with the GUI.

...

We don't use NetworkManager except on laptops, and so do not install it.

Though we do install NetworkManager-glib, if only because some packages require it.

...

After seeing a similar bug on the RHEL I also installed

NetworkManager-libnm, but that did not make a difference. That RHEL bug also mentioned this problem only occurs on KDE, and not Gnome. And we only install KDE when a GUI is required, or desired.

...

I'd suggest you install and test with NetworkManager

Do note that the EL7 NM is a far cry from the one that shipped with EL6 and unless you specifically need a facility not exposed by NM it is strongly recommended you use it.

Take a look at my article on nmcli - it's rather lovely to use now:

https://www.hogarthuk.com/?q=node/8

As for the firewall tool... don't use it ... it's horrible

Either use firewall-cmd to configure at the CLI or switch to iptables and configure that as you did EL6

I actually like the firewall config tool as it provides easy, out of the box, management of servers that don't require complicated iptables rules. At least it was easy when it worked. For more complicated servers, like gateways, we use shorewall.

I can see no use case for NetwortManager on our systems. All network connections are static.

The exception to that is a couple of laptops, and I agree that NetworkManager has gotten very handy in that single use case.

Making any application dependent on NetworkManager is just plain silly. Even requiring installation of the NetworkManager libs should not be required.

I suspect that this should probably be brought with the KDE group as it seems to be a problem with how some GTK apps are working within the KDE environment.

Emmett

On Jun 7, 2016, at 13:03, Emmett Culley lst_manage@webengineer.com wrote:

I can see no use case for NetwortManager on our systems. All network connections are static.

There are a couple reasons I still use NetworkManager on servers, but one big one is that the 'network' service runs once, on boot. If there is no network connection, your server's network connection will never come up until you log in at a console to fix it or reboot. With the speed of computers these days, our servers often boot up faster than the networking equipment after a power cut.

-- Jonathan Billings

On Tue, 7 Jun 2016 17:20:23 -0400 m.roth@5-cent.us wrote:

Um, huh? ssh server;service network restart is certainly faster than a reboot.

By what magical incantation will you ssh into a server with no current network connection?

On 06/07/2016 01:46 PM, Jonathan Billings wrote:

On Jun 7, 2016, at 13:03, Emmett Culley lst_manage@webengineer.com wrote:

...

I can see no use case for NetwortManager on our systems. All network connections are static.

There are a couple reasons I still use NetworkManager on servers, but one big one is that the 'network' service runs once, on boot. If there is no network connection, your server's network connection will never come up until you log in at a console to fix it or reboot. With the speed of computers these days, our servers often boot up faster than the networking equipment after a power cut.

-- Jonathan Billings

As far as I know the network service, in most cases started by systemd, will not fail simply because the network an interface is connected to is not up. Unless, of course, the interface is set up to use DHCP.

Emmett

On Jun 8, 2016, at 6:48 AM, Steve Clark steve.clark@netwolves.com wrote:

I must be missing something here, so the system comes up, ip(s) are assigned to the interface, routes, etc then sometime later the switch comes up and you ssh in. Never been a problem for me.

Even with static configurations, I’ve had this problem. At least in RHEL6, if the switch doesn’t indicate the interface is up during boot, the ‘network’ service detects the down interface and never starts the network service. full stop. I’ve also seen this happen when the switch has a broadcast storm or some other networking problem and doesn’t become active for more than a minute after boot. Often I’ll have to add a line to the ifcfg-* script to have it just sleep for 60 seconds before even trying to activate the interface, when I know the system is on a switch that takes a long time to perform its splay tree calculation. (Many of my systems are on networks I have no control over, so I have to just work around problems like this.)

I’ve always used NM in RHEL7 so I’m not aware if systemd is smart about dynamic interface activation of the ‘network’ service. NM in RHEL7 is so much better than in RHEL6 so I haven’t really needed anything else.

-- Jonathan Billings billings@negate.org