[BlueOnyx:25831] Re: 5211R: network problem after first reboot before initial setup

[Michael Stauber]

Hi Juerg,

(By the way: Is this short for Jürgen?)

> I don't have the exact reason for this. Debug misc files shows me
> /usr/sausalito/runonce/initServices.sh with this line
>    HAVETH=$(nmcli -t d |grep ethernet|cut -d : -f1|grep 
> ":connected"|grep eth0|wc -l)
> That looks crazy,
> nmcli -t d |grep ethernet
> gives this output
> eth0:ethernet:connected:eth0
> cutting with "cut -d" can not get two more successful greps for 
> conntected and eth0.

Indeed. I just checked that and the "cut -d : -f1" is unnecessary. Am 
not sure what kind of brain fart I had there. :p

It doesn't hurt, but it's unneeded. I just removed it from the code in 
SVN and the next time base-blueonyx gets published that change will be 
part of it. As it doesn't hurt, I'll leave the version that still has it 
in the repos.

> But this isn't the cause for my problem, but maybe you want to check 
> this line/block anyway.

Very well.

> The problem seems to be
> /usr/sausalito/handlers/base/network/rewrite-ifcfg.pl
> 
> This will create an incomplete ifcfg-eth0

Correct.

> /etc/sysconfig/network-scripts/ifcfg-eth0 does not exists in server 
> install and also not after initServices.sh.

When CODB is populated with the network settings (via the 
network_settings.sh script, cceclient or the GUI) the handler 
rewrite-ifcfg.pl runs. The function edit_ifcfg() in it will create or 
edit (actually: re-create from scratch) network config files for the 
various network devices that we configure.

So that's when the file gets created or "updated".

> But in el9 this file is not longer required. 

True. But we have so much baggage regarding the network settings that 
ripping it all out and replacing it with "nmcli" calls is a major 
effort. So I left that part in and just tacked on the "nmcli" calls 
wherever appropriate and required. This isn't ideal, I know. But a 
complete overhaul of base-network.mod is quite a massive job.

Also in rewrite-ifcfg.pl
> you will shutdown eth0 interface (and maybe it can't be started again).

I looked over that code and it's pretty convoluted. They way it's 
*supposed* to work? If we *change* a network device, the old one should 
be shut down and the new brought up. There are also various places where 
a "rollback" is performed in case the configuration errored out. In that 
case changes ought to be undone and that might require bringing an 
interface down and perhaps another one up - depending on what the 
changes were.

Like said: It's a convoluted mess. This still follows the design 
principles of the initial Cobalt Networks developers:

You create/modify/destroy a "Network" Object in CODB? The handler runs 
and writes/modifies/removes the network configs and restarts the network 
as needed.

Over time this has become counter-productive as far as the network is 
concerned. I'm considering dropping the CODB dependent storage of 
Network settings entirely. CODB might still have the info so that we can 
quickly fetch it for the GUI to display. But actual changes to then 
network settings should directly be done via "nmcli".

The only thing we then loose is the ability to perform an automated 
rollback in case that doesn't work. Sausalito already has the toolbox 
for such rollbacks and a separately scripted and entirely "nmcli" based 
network configuration handling would need that replicated in another 
way. But that's some food for thought for another day.

> Adding
> `/usr/bin/nmcli con down eth0 && /usr/bin/nmcli con up eth0`;
> and the end of rewrite-ifcfg.pl to force another network restart with 
> NetworkManager seems to be a valid workaround.

Very well. I just added that to the handler and published new 
base-network RPMs to YUM. I'll roll up another ISO and do a test install 
from it to see if that also fixes the busted network I encountered after 
the initial config. It sounds like it might solve that as well.

> PS: I use the BlueOnyx system for years. Before I discovered this 
> mailing list with active developer support I don't reported every bug 
> and was happy to find a workaround and patched local files (and checked 
> them after every update). I hope reporting such small bugs isn't 
> annoying to you. If you think a reported bug is to special interest and 
> you don't wan't to analyze and fix it feel free to ignore it. I usually 
> find a workaround that is quite sufficient for me.

Juerg, I *really* appreciate your input. You've got the skills and 
dedication and you deliver solutions that are just picture perfect. 
That's exactly what we need. Join the team, or we might have to abduct 
you! :o)

You're more than welcome!

-- 
With best regards

Michael Stauber