@Sebastian-Roth I just realized I never responded to this. Ooops!

I would be happy to look at this if you are still up for it.

Thank you. I understand the complexity issue and removing the DB manually is easy enough.

I installed a Storage Node on Ubuntu 18.04 LTS and was surprised to see that it installed MySQL server (or rather, MariaDB). As near as I can tell, the nodes don’t actually use the local database, and instead use the FOG master server’s database.

Am I missing something? Does the Node need that local database, or can I just disabled the service?

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.

@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.

We run nightly backups that keep several weeks of history and restoration took only a few minutes. Only three clients got wedged to the point where they had to be rebooted.

But we were lucky because we only have three dozen or so clients in our lab. In my previous role, I was part of a team that supported roughly 20,000 clients. Imagine the havoc that gets wreaked when an exports file with a few hundred filesystems in it goes away. Batch jobs start hanging, user login sessions hang, and so on. In most cases, it’s just a stale NFS filehandle message, but not all applications are tolerant of an outage of minutes to hours (depending on how long it takes for the issue to get noticed).

I appreciate that it’s a small development team, but this stuff has real impact. Overwriting a file that is not owned by the software and is a critical, shared resource rubs me the wrong way, especially when it takes down infrastructure. And yes, I saw the help, but the use of inconsistent language makes it easy to make faulty assumptions about what the installer is actually doing:

	-E    --no-exportbuild		Skip building nfs file
	-P    --no-pxedefault		Do not overwrite pxe default file

One option speaks of building, another says overwrite. The latter sounds dangerous, the former does not. But, more to the point, sometimes I make mistakes because my life is not 100% error-free, even when I am paying close attention. Software can help stop me from doing something I shouldn’t.

Here is a simple solution for the installer that would mitigate this problem: grep the file for the lines you want to add, and if you don’t see them, use echo with an append:

if grep '^my line regex' /etc/exports > /dev/null 2>&1
then
   :
else
  echo "my line" >> /etc/exports
fi

Worst-case scenario is that someone modified the line you were going to add, and you end up adding a duplicate.

Folks, the FOG installer blindly overwrites /etc/exports with no warning, no chance to interrupt it, and without backing up the old one. This is bad, bad behavior. I can’t emphasize enough how bad this is.

I see now, after I got bit by this, that there are many complaints about this behavior. Well, there should be, because this is terrible. Just adding menu options to installfog.sh is not enough warning. You need to alert people when you are about to overwrite a file that has been customized and give them a chance to stop it, just like every Linux distribution’s package manager on the planet does. A simple checksum can tell you that you are about to do that.

This worked! Thank you so much for the debugging and the resolution.

FOG has been a huge boon to our lab, and getting this last, niggling issue resolved is very much appreciated.

Thanks, @Sebastian-Roth. I will try this out.

I am an experienced C# developer so .NET isn’t the hangup. I just prefer solutions that are natively supported by the environment they run in. There is less complexity, and less complexity means fewer problems such as this one.

That being said, I’d rather get this working on mono since that’s what’s currently distributed and supported. So, yes, any hints the client developer might have would be greatly appreciated.