Re: Re: RHEL9 and "ifcfg" network config

"[email protected]" <[email protected]> Thu, 14 Sep 2023 07:39:29 -0700 (PDT)
Newsgroups gmane.comp.sysutils.cfengine.general
Message-ID <[email protected]>
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.