FOG install overwrites /etc/exports with no warning

[Quazz]

To be fair, it’s been a longstanding recommendation that the FOG server should be running nothing but the FOG server for a reason.

[Wayne Workman]

@mechalas Please see the NFS section of the .fogsettings documentation, and set it to not overwrite your exports file:

https://wiki.fogproject.org/wiki/index.php?title=.fogsettings#NFS

@Sebastian-Roth there appears to be an /etc/exports.d functionality I’d suggest looking into. Maybe fogs config can be put into its own separate file:
https://serverfault.com/questions/910827/how-do-i-use-etc-export-d
Because this would be an improvement and not a break-fix, I’d suggest backlogging this until more pressing things are sorted.

[mechalas]

@Quazz

To be fair, it’s been a longstanding recommendation that the FOG server should be running nothing but the FOG server for a reason.

If I followed that advice for every service I stood up that suggested this, I’d have a pile of VM’s, Docker containers, or a slew of physical systems (or a combination of all three) that need to be managed. Each of those solutions brings their own administrative overhead and issues. It’s trading one problem for another.

In an ideal world, this is great. In the real world where resources are limited, I have to make decisions about what can go where, and what’s easiest to manage.

@Wayne-Workman

Please see the NFS section of the .fogsettings documentation, and set it to not overwrite your exports file:

I read that document. It says “rebuild” and “rebuilt”. When I have my engine in my car rebuilt, I expect to get back my old engine with new parts in it. I do not expect to get back just the new parts.

The language here matters.

[mechalas]

I like the /etc/exports.d approach the best.

My age is showing: I didn’t even know this functionality had been added to exportfs or I’d have been using it.

[Sebastian Roth]

@mechalas @Wayne-Workman I have done some first tests on Debian and CentOS just to make sure this actually works as expected. Seems like it does so far.

Meanwhile I was wondering about your ideas on how to move over from what we have now to /etc/exports.d schema. There are a couple different situations, some are easy and some are hard to come by.

• Fresh install: Just generate /etc/exports.d/fog.exports and we are good to go.
• Upgrade install with a clean /etc/exports file: either we use checksum or regex to make sure it is not modified and move the file to /etc/exports.d/fog.exports (and maybe create an empty /etc/exports)
• Upgrade install with a modified /etc/exports file: Not really sure what to do in this case. We could try to grep the existing entries, pipe those into a new /etc/exports.d/fog.exports and sed the main file to remove/comment the entries there. But I guess there are so many different files out there that chance is high we break things for some people again - last time though.

Any comments on this?

[george1421]

@Sebastian-Roth said in FOG install overwrites /etc/exports with no warning:

1. Fresh install: Just generate /etc/exports.d/fog.exports and we are good to go.
2. Upgrade install with a clean /etc/exports file: either we use checksum or regex to make sure it is not modified and move the file to /etc/exports.d/fog.exports (and maybe create an empty /etc/exports)
3. Upgrade install with a modified /etc/exports file: Not really sure what to do in this case. We could try to grep the existing entries, pipe those into a new /etc/exports.d/fog.exports and sed the main file to remove/comment the entries there. But I guess there are so many different files out there that chance is high we break things for some people again - last time though.

1. Test to see if /etc/exports.d directory exists, if not fall back to current way of managing exports.
2. (3. can be combined) test to see if /etc/exports.d exists. if so use sed or awk to remove the fog lines from /etc/exports and then move to the exports.d design.
3. Same process as 2.

Questions: what happens if we have 2 exports.d file that contains the same fsid? Will that break something? Do we move FOG’s nfs fsid to something unique like 1001? Does the fsid need to be unique or sequential?

[Sebastian Roth]

@george1421 said in FOG install overwrites /etc/exports with no warning:

1. Test to see if /etc/exports.d directory exists, if not fall back to current way of managing exports.

No good I suppose. Testing on Debian I noticed that /etc/exports.d did not exist on a clean fresh OS install with nfs-server package but it all worked perfectly well after I created it manually…

[Wayne Workman]

@george1421 said in FOG install overwrites /etc/exports with no warning:

Questions: what happens if we have 2 exports.d file that contains the same fsid? Will that break something?

In what scenarios do you see having two?

[Wayne Workman]

@Sebastian-Roth said in FOG install overwrites /etc/exports with no warning:

Upgrade install with a clean /etc/exports file: either we use checksum or regex to make sure it is not modified and move the file to /etc/exports.d/fog.exports (and maybe create an empty /etc/exports)

Just check if it exists.

if [[ ! -f "/etc/exports.d/fog.exports" ]]; then 
    echo "do stuff"
fi

I’d suggest asking the user to confirm the actions to be taken, with a default answer of “y”.
Maybe something like “it’s detected that fog configuration exists in /etc/exports. Would you like the installer to move this to the new location for you?”

Just kicking around ideas…

[george1421]

@Wayne-Workman said in FOG install overwrites /etc/exports with no warning:

In what scenarios do you see having two?

If you were to install fog side by side with another product that supports nfs. What is the likelihood of two installs creating an entry with fsid of 0 or 1? We see that issue today when someone wants to create a second nfs share on the fog server and clones what is currently there but updates the paths only.