LinuxAdmin::NetworkInterface.new("name") assumes there a conf file and fails

[abonas]

LinuxAdmin::NetworkInterface.new("interface_name") assumes there is a conf file in
/etc/sysconfig/network-scripts, but this is not always the case.
So it fails with

Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/sysconfig/network-scripts/ifcfg-eth2

I'm running rhel 6.5, and I have an interface named eth2, and it doesn't have a conf file for it (but the network works ok)

[abonas]

cc @moolitayer @simon3z

[Fryguy]

@carbonin the code sounds like it needs to switch on rhel 6 v 7

[abonas]

@Fryguy @carbonin consider also centos, fedora, and other linux distros?
(btw even on rhel, I think you could have either existing conf file or not, both are normal)

[carbonin]

As far as I know this is the only (and most accepted) way to set persistent static IP addresses on RHEL, CentOS, and Fedora. Including RHEL6

What file or configuration tool are you using if you don't have a file in /etc/sysconfig/network-scripts/ that maps to the interface you are using? Are you by any chance attempting to use this tool for wireless networking? I believe there are some additional values we are not currently keeping track of for that.

[abonas]

no, I'm not using wireless.
afaik, the NetworkManager is used on this env.
nmcli dev status outputs that it controls eth2, for example

[carbonin]

In a server environment it is typically recommended to not use NetworkManager specifically because of its difficulty with scripting. This class was designed with the intention of only interfacing with static network configuration files.
Maybe if someone uses this class we can create the file for them? What do you think @bdunne @Fryguy I'm not sure how NetworkManager would respond to us grabbing an interface that it was previously managing, but that was the intention behind this line anyway right?

Adding a NetworkManager class in case someone specifically wants to be using it may also not be a bad idea.

[abonas]

In a server environment it is typically recommended to not use NetworkManager specifically because of its difficulty with scripting.

Can you refer to documentation of this please?

This class was designed with the intention of only interfacing with static network configuration files.
Maybe if someone uses this class we can create the file for them?

I'm concerned it's not ManageIQ job to change the network configuration of the machine that it runs on.
Plus, no one promised miq has the permissions to do so :)

What do you think @bdunne @Fryguy I'm not sure how NetworkManager would respond to us grabbing an interface that it was previously managing, but that was the intention behind this line anyway right?

Adding a NetworkManager class in case someone specifically wants to be using it may also not be a bad idea.

[bdunne]

@abonas Can you give more detail about the use case? The initial pass that @carbonin did was to extract a lot of this logic from an old shell script in the ManageIQ code base.

We have always avoided NetworkManager since our use case is the virtual appliance which usually has one NIC named eth0 and we haven't needed (or wanted) the additional overhead of interfacing with NetworkManager when the network service can do everything we need.

Since we ship a virtual appliance, we have always provided a small console application that would assist users with initial configuration of their appliance. Many of our users are not very familiar with linux and find this very helpful. Having this code written in ruby is a much more maintainable approach for our team than the shell script that used to use.

This code is brand new to LinuxAdmin, but it's just extracted from an old shell script in the ManageIQ code base. We are open to extending and improving LinuxAdmin and the network interface management features that it provides if there are use cases for it.

[abonas]

@bdunne this code runs not only in the appliance, but also on developer environments (manageiq developers). hence there are several different setups of rhel, fedora, etc.

[carbonin]

So I think the solution here is to detect if the file we need is present and not attempt to instantiate a NetworkInterfaceRH instance if it is not, that way queries for network information will still succeed without the presence of the interface file via the NetworkInterfaceGeneric class (i.e. methods defined in network_interface.rb).