RHEL9 and "ifcfg" network config

[t.d...@servicemusic.org.uk]

We're at the early stages of exploring RHEL9.  (My earlier thread "RHEL9?" was simply about the earliest stages of getting CFE started on RHEL9 at all.  This is now reasonably in hand.  This new thread is different: it is about a particular detail in a running RHEL9/CFE.)

RHEL systems up to and including RHEL8 have used "KEY=value" "ifcfg" files in "/etc/sysconfig/network-scripts/".  We could cleanly and easily apply minor adjustments to the existing files via CFEngine, from CFE "slist"/"data".

But at RHEL9 that directory is now empty, and the replacement mechanism seems to be similar files in "/etc/NetworkManager/system-connections/".   But these are different.  For example:

• The file is now in "INI" format with several sections
• So different "KEY=value" need to be in different sections
• It looks as though some "KEY" names have changed, probably also some values; for instance "ONBOOT={yes,no}" seems to be "{autoconnect={true,false}"
• "KEY" capitalisation seems to have changed from upper-case to lower-case

This means that local policy now needs to be able to handle two very different ways of working.  Imagine, for instance, gradually upgrading a set of machines from (old) RHEL{6,7,8} to (new RHEL9) while wishing to keep the same logical configuration.  Do we local sysadmins really need to have to maintain the same CFE data in two different formats?

So...

Is there a CFE library that might be able to take a single set of data entries (imagine these as abstracted, relatively high-level)  and automatically apply it (on the ground, low-level) the old way to old RHEL{6,7,8} machines and the new way to new RHEL9 machines?

-- David Lee

-- Diamond

[t.d...@servicemusic.org.uk]

Here's a document from Red Hat about the differences: https://www.redhat.com/en/blog/rhel-9-networking-say-goodbye-ifcfg-files-and-hello-keyfiles

The data we store in CFE to configure those machines that need adjustment is, at heart, an "slist" of old-style "KEY=value" ("ifcfg" format) items.  Then a couple of bundles simply maintain (edit) the pre-existing "ifcfg" files.

Part of our daily "business as usual" includes re-installing machines and VMs (total estate a little under 20,000) with a new OS, e.g. from RHEL7 to RHEL8.  Because 7 and 8 both used "ifcfg", that part of such "business as usual" change is usually fine.  (And other parts of our CFE config use classes such as"redhat_7" and "redhat_8" where needed.)   But we're now beginning with RHEL9, which requires this same logical data to be applied in a different format (and to a different file).

Ideally this should be transparent: the CFE on the new machine knows the OS release, so would automatically apply the appropriate format to the appropriate file.  (If pure CFE, then automatic decision-making based on classes such as "redhat_8" and "redhat_9" would probably be in the mix.)

I guess we won't be alone in this.

So is there (or are there plans for) something library-like (e.g. MPF masterfiles or modules) that can take some form of abstract net-interface data (a representation of those "key=value" items +/- the new INI-style section names), then apply and maintain them in an OS-appropriate manner?

(Nick Anderson had a brief email chat, which was accidentally not on this list, but haven't yet come to any significant conclusions.)

-- David Lee

-- Diamond Light Source 

[Nick Anderson]

(Nick Anderson had a brief email chat, which was accidentally not on this list, but haven't yet come to any significant conclusions.)

The gist of what I said was to map the source data structure to the target data structures. Meaning one of:

• Create a generic data structure, munge the data as necessary for redhat_8 or redhat_9 so that the keys and values are convenient for rendering the file content
• Model on the structure needed for redhat_8, munge for redhat_9 so that the keys and values are convenient for rendering the file content
• Model on the structure needed for redhat_9, munge for redhat_8 so that the keys and values are convenient for rendering the file content

This munging may be achievable directly in policy, or it might make sense to hand the source data off to a module and do the necessary munging using a higher level language.

With respect to the INI format, I believe that there still exists an issue with respect to being able to select the last section using edit_line (should have been resolved with https://northerntech.atlassian.net/browse/CFE-452, but some issue remains https://northerntech.atlassian.net/browse/CFE-3428, https://northerntech.atlassian.net/browse/CFE-2663) so that will complicate doing partial file management, but if you are managing the full file content and know everything you want, then you should be able to render the INI via mustache.

[t.d...@servicemusic.org.uk]

Nick,

Many thanks for your summary.  It's far better than would have been any attempt of mine to summarise!

I think that gives me a decent way to explore forward.  Our existing data is close to "redhat_8" (and earlier, because it's good old-fashioned "ifcfg").   As I begin to consider the practicalities, then because of fair amount of data munging involved, using an external module looks (at this stage at least) to be the way to attempt.

Thanks for the note, including references, about the bugs when editing the last section of an INI file.  Based on a sample size so far of just a single RHEL9 machine (we're right at the start of this RHEL9 journey), the last section doesn't seem to come into play.  Naturally, I realise that full file replacement (templates) is generally better than editing.  But these particular files are usually initialised at installation time with several lines of data, not least a UUID, so that is why we have generally handled this instance with editing.

-- David Lee

[t.d...@servicemusic.org.uk]

Update:

The "module" idea has hit a further snag, because of what seems to be a bug: https://groups.google.com/g/help-cfengine/c/70qc5E83BMA

All the Red Hat documentation about interface configuration seems to be about using the "nmcli" command rather than about managing the file.  It seems they want to steer away from directly touching those files.  But how is one supposed to manage/promise an interface attribute using nmcli?   (I suppose one could run a command to try to dig out the attribute, edit the output to obtain it; conditionally set a class then (conditionally) apply the corrective command.  But that seems rather more tortuous (and thus more fragile or error-prone) that the CFE file-line bundles such as "set_variable_values_ini".)

So there seems no clear way forward, unless I've missed something obvious.

-- David Lee

[Aleksey Tsalolikhin]

Hi David,

Are you using the Enterprise version of RHEL?  As in, with tech support?

I asked Shell-GPT about how nmcli stores the settings -- to sum, it can vary based on distro and version -- so my idea was, you could ask tech support about it, see how far down this rabbit hole goes (i.e., identify the underlying files, if you haven't already). (You could also identify them with "strace" or similar.)  If it were me, I'd manage using the underlying text config files as long as I could (as long as I could do so reliably).

>>> where is the nmcli backend database stored?
The `nmcli` tool does not have its own backend database. Instead, it interacts with NetworkManager, which is responsible for managing network connections and storing network-related information.

NetworkManager stores its configuration and connection details in various files and directories on the system. The specific location of these files can vary depending on the Linux distribution and version you are using. However, in most cases, the configuration files for NetworkManager are stored in the `/etc/NetworkManager/` directory.

Some of the important files related to NetworkManager's configuration include:

- `/etc/NetworkManager/NetworkManager.conf`: This file contains the main configuration settings for NetworkManager.
- `/etc/NetworkManager/system-connections/`: This directory contains individual connection profiles for different network connections. Each connection profile is stored as a separate file within this directory.

It's worth noting that the backend storage for NetworkManager can also be influenced by additional plugins or modules that are installed on the system. These plugins can provide alternative storage mechanisms, such as using a database backend like SQLite or storing connection details in other formats.

To get more specific information about the backend database or storage being used by NetworkManager on your system, you can refer to the NetworkManager documentation or consult the documentation specific to your Linux distribution.
>>>

Best,

Aleksey

--
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/9cdee544-012f-4dca-94de-74c6a16a1074n%40googlegroups.com.

[Bas van der Vlies]

Just as reference and inspiration, there is ansible playbook for this
(build.cfengine.con had a module to run ansible playbooks)
* https://galaxy.ansible.com/linux-system-roles/network

> <mailto:t.d...@servicemusic.org.uk> <t.d...@servicemusic.org.uk

> <mailto:t.d...@servicemusic.org.uk>> wrote:
>
> Update:
>
> The "module" idea has hit a further snag, because of what seems to
> be a bug: https://groups.google.com/g/help-cfengine/c/70qc5E83BMA
> <https://groups.google.com/g/help-cfengine/c/70qc5E83BMA>
>
> All the Red Hat documentation about interface configuration seems to
> be about using the "nmcli" command rather than about managing the
> file.  It seems they want to steer away from directly touching those
> files.  But how is one supposed to manage/promise an interface
> attribute using nmcli?   (I suppose one could run a command to try
> to dig out the attribute, edit the output to obtain it;
> conditionally set a class then (conditionally) apply the corrective
> command.  But that seems rather more tortuous (and thus more fragile
> or error-prone) that the CFE file-line bundles such as
> "set_variable_values_ini".)
>
> So there seems no clear way forward, unless I've missed something
> obvious.
>
> -- David Lee
>
> On Thursday, 7 September 2023 at 18:21:52 UTC+1

> * Create a generic data structure, munge the data as

> necessary for |redhat_8| or |redhat_9| so that the keys
> and values are convenient for rendering the file content

> * Model on the structure needed for |redhat_8|, munge for

> |redhat_9| so that the keys and values are convenient
> for rendering the file content

> * Model on the structure needed for |redhat_9|, munge for

> |redhat_8| so that the keys and values are convenient
> for rendering the file content
>
> This munging may be achievable directly in policy, or it
> might make sense to hand the source data off to a module and
> do the necessary munging using a higher level language.
>
> With respect to the INI format, I believe that there still
> exists an issue with respect to being able to select the

> /last/ section using |edit_line| (should have been resolved
> with https://northerntech.atlassian.net/browse/CFE-452
> <https://northerntech.atlassian.net/browse/CFE-452>, but

> some issue remains
> https://northerntech.atlassian.net/browse/CFE-3428

> <https://northerntech.atlassian.net/browse/CFE-3428>,
> https://northerntech.atlassian.net/browse/CFE-2663
> <https://northerntech.atlassian.net/browse/CFE-2663>) so

> that will complicate doing partial file management, but if
> you are managing the full file content and know everything
> you want, then you should be able to render the INI via
> mustache.
>
> --
> You received this message because you are subscribed to the Google
> Groups "help-cfengine" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to help-cfengin...@googlegroups.com

> <mailto:help-cfengin...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/help-cfengine/9cdee544-012f-4dca-94de-74c6a16a1074n%40googlegroups.com <https://groups.google.com/d/msgid/help-cfengine/9cdee544-012f-4dca-94de-74c6a16a1074n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "help-cfengine" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to help-cfengin...@googlegroups.com

> <mailto:help-cfengin...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/help-cfengine/CANNWuVWrXxFyGOCar0CsqML9tr3ODoc2yXAbVBQpZsRDh%2Bsffg%40mail.gmail.com <https://groups.google.com/d/msgid/help-cfengine/CANNWuVWrXxFyGOCar0CsqML9tr3ODoc2yXAbVBQpZsRDh%2Bsffg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
--
Bas van der Vlies
| High Performance Computing & Visualization | SURF| Science Park 140 |
1098 XG Amsterdam
| T +31 (0) 20 800 1300 | bas.van...@surf.nl | www.surf.nl |