@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.
It’s probably going to be two weeks or longer before I can adjust the daily tests - I’m super busy this weekend, next week, and vacation is the week after. But I’m pretty confident I can test upgrades. At least upgrading from the last release.
I’ve thought about testing upgrades, I don’t think it’d be too tough. Basically, I’d add 6 more instances - all the same OSs already being tested. But I’d install the last release of FOG on them - and then snapshot.
That way, the original 6 still have clean snapshots and would be labeled as ‘clean’, and the other 6 would have a fog installation on them and be labeled as ‘upgrade’. All the other commands remain the same I think.
@Sebastian-Roth you can use our slack project to test.
@george1421 said in FOG 1.5.6 Officially Released:
Why not setup both http and https in apache.
I’d say that’s a good idea.
I’ve added Fedora 30 to the daily installation tests, you can see results in my signature. Seems to be going good. After a couple days, I’m going to be removing Fedora 29 from the tests to keep costs down. Also, I’ve added some documentation on how to add a new OS to the daily tests. If anyone was curious, running the tests once per day for a full month costs about 20 USD.
It’s worth noting that FOG is open source and runs on Linux and Apache. There’s a thousand articles on the internet about applying SSL to Apache. Anyone can secure their FOG installation with a self signed cert, or an organization-trusted cert. One could even say that securing things with SSL is the admin’s job.
@george1421 said in FOG 1.5.6 Officially Released:
Now if fog could use one of those fee root traceable ssl certificates (like from lets encrypt) and then created the FOG SSL certificate using that then the IT admins would not get the browser nag messages.
using Let’s Encrypt for FOG installation wouldn’t work in >98% of cases because those fog servers are not open to inbound traffic from the internet. They couldn’t pass the DNS http challenge/response.
Mostly, FOG is used at universities and public school districts. While I can see a university maybe already having a self-signed cert installed in the OS’s trust store, it’s not my experience or observation that public schools do this. While I’m 100% fully on-board with end-to-end encryption all the time everywhere, I feel it’d only be an unwanted hurdle to jump for most FOG users that are just trying to get some computers imaged.
Perhaps it could be made easier to setup SSL, rather than forcing it? Perhaps make it optional, and defaulting to ‘no’.
At any rate, this is just my 2 cents.