Entries in /opt/fog/.fogsettings mangled? on First-time Install

[sudburr]

Server

• FOG Version: RC10 & RC11
• OS: CentOS 7.2.1511

Description

A first-time installation generates these extended … duplicate entries in /opt/fog/.fogsettings.

routeraddress=‘192.168.1.1
192.168.1.1’
plainrouter=‘192.168.1.1
192.168.1.1’

Unless, this is somewhy intended .

[sudburr]

To quote the Professor, good news everyone!

The problem is no longer a problem as of RC22.

Thank you again for all of your hard work.

[Tom Elliott]

I’ve gone and installed Fedora 24 on a vm at home. I’ve taken a snapshot immediately after install and updates ran (other than that everything is just base fresh install with all defaults set).

I installed using Fedora 24 Netinstall server. I know that doesn’t match the issue with CentOS 7.2, but it should come pretty close. I’m trying to work on the installation of Fedora 24 so as to fix the “does not exist” errors others are seeing as well and suspect I’ll see these issues here there as well meaning I should be able to get a fix relatively soon.

[Tom Elliott]

I’ve not been able to replicate this issue. I’m wondering if you have multiple NICs on the system receiving identical ranges and this is why you’re seeing this?

[sudburr]

Negatory on multiple NICs.

[Wayne Workman]

@sudburr Can you give us the output of ip addr show so we can see if there is anything that may be there that is causing this?

[Tom Elliott]

As a matter of chance I currently have a 7.2.1511 server (though it is my main db server) that has never had fog installed on it before. I will take a snapshot and give it a go to see if I see the same mangling type of entries as well as hopefully fix the installation on this distro.

[Wayne Workman]

@Tom-Elliott I have tested CentOS 7.2.1511 already and my .fogsettings file is perfectly fine. Of course, CentOS 7 has other issues with the latest RC at the moment.

[sudburr]

Interesting. This wasn’t a one off. I duplicated the results on both RC10 and RC11.

And of course you can see how I built the server in my tutorial posts.

I’m trying it again now with RC14v3 (svn5974).

[sudburr]

ip addr prior to installation of RC14v3

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:15:5d:f4:0d:2e brd ff:ff:ff:ff:ff:ff
    inet 172.19.244.32/24 brd 172.19.244.255 scope global dynamic eth0
       valid_lft 517660sec preferred_lft 517660sec
    inet6 fe80::215:5dff:fef4:d2e/64 scope link
       valid_lft forever preferred_lft forever

Entries in /opt/fog/.fogsettings immediately after installation

submask='255.255.255.0'
routeraddress='172.19.244.1
172.19.244.1'
plainrouter='172.19.244.1
172.19.244.1'

[Tom Elliott]

@sudburr Guessing this still happens? (Just keeping the unsolved bugs at the forefront so we don’t lose it)

[sudburr]

I haven’t had a chance to check against the latest builds. I’ll be looking at it this week.

[sudburr]

To quote the Professor, good news everyone!

The problem is no longer a problem as of RC22.

Thank you again for all of your hard work.

[Tom Elliott]

@sudburr But nothing changed.

[Quazz]

@Tom-Elliott The IT gods are more favorable this week.

[Tom Elliott]

@Quazz Must be. Just weird it was happening first, but with no changes to how it’s operating and suddenly being fixed seems even stranger to me.

[sudburr]

< https://youtu.be/If3SXJeZzMQ >