Hi there,
I've used FOG at a past job pretty intensely. During that time I contributed a lot to the FOG forums and it's documentation, a handful of pull requests, and contributed to the fog-community-scripts repo. I built automated tests for FOG's installer which run daily against many operating systems, link is in my signature. My fog time has slowed down a lot in the last couple years, but I still try to help as I can. I've got a lot of knowledge about FogProject in general and I can help you gear up or contribute if you would like.
Happy Fogging!
@developers @moderators I was able to get the daily installation tests to test upgrading from FOG 1.5.5. Mostly this is going good, but 1.5.5 didn’t install correctly on Fedora 30 or RHEL7. Those two are totally jacked, but everything else seems to be working right.
I need to write some new scripts to make the setup more easy though.
@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 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?
@EduardoTSeoane It sounds like you’re using groups to deploy several snapins at once? If that’s the case, as a work-around, I might suggest deploying 1 snapin at a time with groups. That way they happen in the order needed. Not optimal, I know.
@EduardoTSeoane I think snapins have always executed in alpha-numeric order.
@george1421 said in Change the boot order automatically:
But we do it this way to make sure we don’t reimage the CFOs computer by accident (again) if everything was automatic.
That must have been a bad day.
@Sebastian-Roth said in TFTP won't start at the installation:
@Onirix I probably need to test with Debian 9.9 myself to figure this out. Not sure when I will get to this.
I see you’ve already tested it, but the daily install tests - in the case of Debian 9 - always are testing the very latest version of Debian 9 automatically every day. Arch is always the latest version. Centos 7 is always the latest centos7. Fedora 30 is always the latest 30. Ubuntu 18.04 is always the latest 18.04.xx.
@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.
@moderators @developers is there a curl or wget command he could run to attempt to manually download the latest init? Doing this manually may more directly reveal any potential problems.
Also, sometimes an organization’s web filter / web proxy / content firewall really messes with this step. Be sure that fogproject.org is whitelisted in any of those.