Fog 0.32 overwrites /etc/exports
-
In the following files:
[QUOTE]
fog_0.32/lib/ubuntu/functions.sh
fog_0.32/lib/redhat/functions.sh
[/QUOTE]Your code should be changed from:
[CODE]/images/dev *(rw,sync,no_wdelay,no_root_squash,insecure)" > “$nfsconfig”;[/CODE]to
[CODE]/images/dev *(rw,sync,no_wdelay,no_root_squash,insecure)" >> “$nfsconfig”;[/CODE]
This will append and not overwrite.
That blew away my servers NFS shares, thankfully I had my “/etc/exports” in git.
— EDIT —
I would also propose that it not be hard coded to “/images”. It is way more common for the OS partition to be smaller and then have a second drive or an iSCSI/SAN mounted on another partition.
Maybe you could make that a question in the installer, then use the reply to set DB values that are used to build “/etc/exports”. -
This is not a bug, but rather the intended behavior for 0.32 version of FOG. The next version of FOG (0.33) is focusing on making the code base object oriented and cleaning out some legacy items that are no longer used. Also adding support for Windows 8, trying to get more filesystems supported, and fixing as many things as we can. All that being said, at this stage it’s still expected to be installed on its own server and not play nice with existing configurations. Being open source though, we encourage you to edit the scripts to meet your needs, inform the community of your mods and tweaks, and petition to get those things added in future releases.
I like the concept, so I think you should post it as a proposal in the feature request forums.
-
In 1.x.x and below, this is still the case, though I suppose I could make a backup if the file exists. I’ll take a look into it. This way we don’t lose any information on install. Even if temporarily it breaks it, at the very least it would be a simple copy original back and run exportfs -a I think or just service nfsd restart/service nfs-kernel-server restart.
-
Still an issue in version 1.3.0-RC-13
Just clobbered my /etc/exports on a box that had other stuff running, being setup as a fog storage only server.
at this stage it’s still expected to be installed on its own server and not play nice with existing configurations
This basic assumption isn’t any of the Fog docs, as a prior warning.
-
@davemc All of our installation tutorials start you with a from-scratch installation of Linux.
-
@davemc also look at the installer arguments. There is an argument you can use to not overwrite the exports file anymore.
-
And the way that would work now:
./installfog.sh -Ey -
@Wayne-Workman @Tom-Elliott Thanks for tips.
My use case was fog server as a vm, to keep things tidy, flexible & efficient. Then images on a tier 2 storage node that has lots of cheaper sata disk.
Based on your comments, re-read the storage node model, and see that images only replicate outwards from the master to the storage nodes, so my plan wasn’t going to work anyway.
I’ve reconfigured the vm to mount /images on cheap storage as block device, same result, and simpler organisation anyway.
Now on to more fine fog tuning & fog fine tuning.
-
@davemc said in Fog 0.32 overwrites /etc/exports:
Based on your comments, re-read the storage node model, and see that images only replicate outwards from the master to the storage nodes, so my plan wasn’t going to work anyway.
Sure it can. You can have a master controlling FOG server and not have any images on it. A storage node elsewhere can be the master node that holds images. FOG is highly flexible, and you can move it’s larger components (db, storage, web server) around as you like with minimal effort.
