@tom-elliott
Thanks. For the record the option is --no-check-certificate
🙂

@trex said in Database Install blank page:

With the Ubuntu servers, Veeam Backup and Replication wouldn’t do a VeeamZIP job on the server, only on its replica (which made backups on the host with the replicas much longer than the host to the FOG servers. But the Debian servers can have a VeeamZIP job done on them,

That’s a great reason for Veeam users to install FOG on Debian.

I’ve used davido38’s suggestion re: cctk. I can even remove the pxe boot from the boot order. Now, any boot other than the HDD requires the BIOS password, but I can use psexec to set the next boot to pxe and then use psshutdown to reboot so the PCs can be imaged. Great work-around.

@george1421 said:

We do have a list of required ports that JBob put together.

Those are in the forums, but I’ve added them to the Wiki a while back, here:
https://wiki.fogproject.org/wiki/index.php?title=FOG_security

While I said multicasting would not work, I should clarify that multicasting will only work on one interface of your consolidated FOG server.

I’m thinking that if he maintains separate Storage Groups per interface, and make each one a master, it would work. images can be shared across storage groups. But all replication only happens from the original storage group to the others, and not the other way around.

I still don’t understand why the OP is even doing what he’s doing though. Albeit I’ve not given this thread hardly any thought.

Thanks all. That is an easy solution! 😃

@TRex You might not be permanently up though.

There’s a known issue with FOG 1.2.0 on Ubuntu 14 and higher - and you just experienced it.

This issue is solved in FOG Trunk.