[Bug?] in RH134 8.2 Regarding External Interface Routing in Classroom VM (UCF ISO)

[benlimanto]

Hello, I'm facing some quite strange bug that doesn't happen on 8.0 image (2019 version). When we as instructor using local on-site lab by using UCF Image that build by @ralii, enable external interface to enable connection to outside world, the route external route only persist once, and after we reboot/shutdown the classroom vm, the route to outside world(0.0.0.0) isn't persistent, and and well cause the podman can't pull container image from registry.access.redhat.com registry when I want to demo to my student (well I'm saved with local registry[registry.lab.example.com] at least), also when I want to demo that podman is support(binary replaceable at least on development) docker by pulling docker alpine image, and so on..

so when I debug the route on classroom vm by running, I got this :

[instructor@classroom ~]$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.25.252.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
172.25.253.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
172.25.254.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0

only , but after re-run the rht-external --configure <my interface>, I got :

[instructor@classroom ~]$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.123.1 0.0.0.0 UG 101 0 0 eth1
172.25.252.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
172.25.253.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
172.25.254.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
192.168.123.0 0.0.0.0 255.255.255.0 U 101 0 0 eth1

The strange thing is I need to kept running rht-external --configure <my interface> to make the route to external network each time after I boot the server, which this never happen on 8.0 UCF image(well there're no container on 8.0 class, but some student sometimes browse web on workstation vm) one time run, persistent between boot of foundation0.

I know there're new 8.2 rhcsa published on 2021, but I download the one that contain RH294 (2020 version), that contain this problem. Is it because my image broken or I'm wrong in perceiving the new image and it's structure that lead me to mishandling or having wrong concept? or this is expected on new image and not a bug? for more information, this only affect the classroom VM, as the kiosk use different route and works fine to external world and persistent between boot. Any Help is really appreciated Thank you

[TudorRaduta]

Hi Ben - just a couple of thoughts here: have you tried setting the static route with "ip route add"?

Alternatively you could edit the hosts file for this config need and that should not change during the reboot process.

Best,
Tudor

[benlimanto]

Hello Mr. Tudor, I think we don't need to, as it should be by default to be work out of the box. I already got reply from the ISO builder, and I still try to check is there anything wrong with my conf and env.

I really appreciate your reply. Thank you!

[ralii]

Hi Ben,

Sorry for the delay in replying on this... I'll try to replicate.

The curiosity for me are the two outputs you quoted. In the first, there is no reference to eth1 on classroom at all. So, not only is the defroute missing, but so is the interface.

Since "foundation0" seems happy, you do not need to go back to running rht-external and we can focus on tools you have on classroom.

On classroom there is a utility called "rht-config-nat". In fact, that is what rht-external has been running for you each time you run it.

When you run "rht-config-nat --permanent" (on classroom) it is supposed to enable eth1 on classroom "permanently".... I am wondering if the curriculum folks have tweaked some startup process that is overwriting that each time it comes up. I must admit to not normally testing reboots....

As to versioning, can you look on your foundation0 under /content/manifests/ and let me know the full filename of both RHCIfoundation....icmf and RH134....icmf? I just want to see if I am trying to replicate on the same versions....

--Rob

[ralii]

Hi Ben,

So I have been unable to replicate.

I have tried rebooting foundation0, and just rebooting classroom. In every case, the classroom VM came back up and eth1 was active.

Is there any chance that the contents of /var/lib/libvirt/images/ are being manipulated?
Specifically, touching the ...classroom...ovl file?
Perhaps running "rht-vmctl reset classroom"?
Or is foundation0 being "reprovisioned"?
Or is foundation0 going back and forth between two courses (per ClassroomReset.txt)?

In any case, you should be able to use "rht-config-nat" on the classroom VM to easily turn on and off the upstream virtual eth1 NIC.

--Rob

[benlimanto]

Hello, I tried to replicated on same server, and I found the problem (to be exact, I still guessing, and testing). If my server has RHEL 8.0 and I use RHEL 8.2 Class module, it raise the problem in foundation0, and lead to the problem I mention above. But it only happened once and after rerun it won't raise the error anymore, but still I need to confirm this, I need more time to test it. But if I use the appropriate version, same version, well it's okay, and runs well, without error I mention above.

I really sorry that I don't reply your answer sooner, because I am really busy with lot of pile up work, but I will try to see if my hypothesis is right.

The question is, does installing different version of RHEL server and  classroom module is okay? or it doesn't?

Thank you so much!

[ralii · Accepted solution]

Hi!

So, in theory, the physical installation and the virtual course VMs do not need to be the same version of RHEL.

The more interesting thing would be about what specific versions you are running, because, honestly, the RHA DIY images tend to lag the commercial side that I work on. So capturing the contents of the /content/manifests/ directory on foundation0 and full filenames of the icmf files may lead me to realize that it is a bug/feature that I may forget I already fixed but you may not have yet....

--Rob