Re: Re: RHEL9 and "ifcfg" network config

Aleksey Tsalolikhin <[email protected]> Sun, 17 Sep 2023 19:36:56 +0000
Newsgroups gmane.comp.sysutils.cfengine.general
Message-ID <CANNWuVWrXxFyGOCar0CsqML9tr3ODoc2yXAbVBQpZsRDh+sffg@mail.gmail.com>
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


On Thu, Sep 14, 2023 at 2:39 PM [email protected] <
[email protected]> 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
>
> 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 [email protected]
> wrote:
>
>> 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
>>
>> On Thursday, 7 September 2023 at 17:37:46 UTC+1 [email protected]
>> wrote:
>>
>>> (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.
>>>
>> --
> 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 [email protected].
> 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 [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/CANNWuVWrXxFyGOCar0CsqML9tr3ODoc2yXAbVBQpZsRDh%2Bsffg%40mail.gmail.com.