Bug 931912 - [yast2-firewall] is confused by /etc/sysconfig/network/ifcfg-xxx files not present (NM)
[yast2-firewall] is confused by /etc/sysconfig/network/ifcfg-xxx files not pr...
Status: RESOLVED DUPLICATE of bug 899330
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
Current
x86-64 All
: P5 - None : Major (vote)
: ---
Assigned To: YaST Team
Jiri Srain
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-05-21 20:46 UTC by Robert Munteanu
Modified: 2021-01-22 13:28 UTC (History)
12 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Munteanu 2015-05-21 20:46:37 UTC
On two TW installs, both managed by NetworkManager, the YAST firewall module does not list any interfaces. Karol Mroz has pointed out that YAST relies on the /etc/sysconfig/network/ifcfg-X files being present.

I have verified that these files are not present:

$ ls -1 /etc/sysconfig/network/ifcfg*
/etc/sysconfig/network/ifcfg-lo
/etc/sysconfig/network/ifcfg.template

Also see discussion at http://lists.opensuse.org/opensuse-factory/2015-05/msg00613.html
Comment 1 Dr. Werner Fink 2015-05-22 07:39:39 UTC
The question rises if YaST2-firewall may use a tool from NetworkManager (if any) to determine the interfaces managed by NetworkManager.
Comment 2 Frederic Crozat 2015-05-22 08:01:53 UTC
if networks are configured by user in NM and not set system-wide (this is the default behaviour), /etc/sysconfig/network/* won't be written (the configuration will be stored in user home directory).

I guess this information could be queried through D-Bus NM API.
Comment 3 Dominique Leuenberger 2015-05-22 09:27:07 UTC
(In reply to Frederic Crozat from comment #2)
> if networks are configured by user in NM and not set system-wide (this is
> the default behaviour), /etc/sysconfig/network/* won't be written (the
> configuration will be stored in user home directory).
> 
> I guess this information could be queried through D-Bus NM API.

The right thing would be to query dbus, not relying on the output of a tool provided by NM (there is nmcli devices, that would give output, but parsing this is just wrong).

You can get a list of known devices by means of:

gdbus call --system --dest org.freedesktop.NetworkManager --object-path /org/freedesktop/NetworkManager --method org.freedesktop.NetworkManager.GetDevices

which returns an array of known devices
([objectpath '/org/freedesktop/NetworkManager/Devices/0', '/org/freedesktop/NetworkManager/Devices/1', '/org/freedesktop/NetworkManager/Devices/2', '/org/freedesktop/NetworkManager/Devices/4'],)

Then iterating over them, you can get the status information of each of them (example on device 0)

> gdbus introspect --system --dest org.freedesktop.NetworkManager --object-path /org/freedesktop/NetworkManager/Devices/0
node /org/freedesktop/NetworkManager/Devices/0 {
  interface org.freedesktop.DBus.Introspectable {
    methods:
      Introspect(out s data);
    signals:
    properties:
  };
  interface org.freedesktop.DBus.Properties {
    methods:
      Get(in  s interface,
          in  s propname,
          out v value);
      Set(in  s interface,
          in  s propname,
          in  v value);
      GetAll(in  s interface,
             out a{sv} props);
    signals:
    properties:
  };
  interface org.freedesktop.NetworkManager.Device {
    methods:
      Delete();
      Disconnect();
    signals:
      StateChanged(u arg_0,
                   u arg_1,
                   u arg_2);
    properties:
      readonly u Mtu = 65536;
      readonly s PhysicalPortId = '';
      readonly ao AvailableConnections = [];
      readonly u DeviceType = 14;
      readonly b FirmwareMissing = false;
      readwrite b Autoconnect = false;
      readonly b Managed = false;
      readonly o Dhcp6Config = '/';
      readonly o Ip6Config = '/org/freedesktop/NetworkManager/IP6Config/2';
      readonly o Dhcp4Config = '/';
      readonly o Ip4Config = '/org/freedesktop/NetworkManager/IP4Config/2';
      readonly o ActiveConnection = '/';
      readonly (uu) StateReason = (10, 0);
      readonly u State = 10;
      readonly u Ip4Address = 16777343;
      readonly u Capabilities = 7;
      readonly s FirmwareVersion = '';
      readonly s DriverVersion = '';
      readonly s Driver = 'unknown';
      readonly s IpInterface = 'lo';
      readonly s Interface = 'lo';
      readonly s Udi = '/sys/devices/virtual/net/lo';
  };
  interface org.freedesktop.NetworkManager.Device.Generic {
    methods:
    signals:
      PropertiesChanged(a{sv} arg_0);
    properties:
      readonly s TypeDescription = 'loopback';
      readonly s HwAddress = '00:00:00:00:00:00';
  };
};

The fields Managed and Interface are likely the most interesting ones
Comment 4 Arvin Schnell 2015-06-30 13:23:54 UTC
Unfortunately the YaST team does not have the time to maintain the
yast2-firewall module. Contributions from the community are welcomed,
see http://yastgithubio.readthedocs.org/en/latest/yast_is_open/.
Comment 5 Imobach Gonzalez Sosa 2021-01-22 13:28:13 UTC
Thanks for reporting. I am marking the bug as a duplicate.

Regards,
Imo

*** This bug has been marked as a duplicate of bug 899330 ***