@ITCC Are those the absolute-exact logs on your system? If not, please post your logs.

@Wayne-Workman

Ubuntu 14.04

| version_compile_os | debian-linux-gnu | | wait_timeout | 28800

@Jbob Thanks for your detailed answer. I agree that string filtering the MACs on the client is not wise! Shouldn’t do that. Detecting physical devices only sounds like a way better approach. See what you can do if you find the time and let me know if I can give you a hand.

@Sebastian-Roth
this is quite a challenge ahaha I don’t have enough knowledge in lvm management but I can take a look at it definitely 😉

Anyway thank you for your time and effort.

@Wayne-Workman YUP.

@Sebastian-Roth said:

Removed from wiki as I don’t feel like anyone really cares about running FOG on a Mac OS X server…

And I feel free and open work should be run on a free and open operating system. Just my thoughts on the matter.

@Junkhacker What if a regular image was decompressed & then mounted on the FOG server, and then it’s raw data sent out via a torrent task ?

I still think that sticking the standard partition data at the end of the drive is perfectly acceptable. Torrent task type is made to overcome network issues, not HDD issues.

@Wayne-Workman
Yes, after open all ports, it works

@Tom-Elliott This could be needed for security purposes. A wipe will make sure the entire disk is over written before putting down an image. With just re-writing the image you can’t ensure that forensic tools won’t be able to recover old files. I can see what he is asking for, maybe if there was a way to modify the download task to do a normal or full wipe then download to give assurance that all data has been over written at least once. This should be able to be accomplished a couple of ways, either one have the fog inits run a normal wipe then run the download, or possibly with the a hooks you could have it auto create a deploy after the wipe finishes so when the client reboots it will pull the image automatically.

the firewalld configuration no longer works on Fedora 21.

The commands succeed, but at least http is blocked still.

@Jean-Jacques-Morda said:

In my case, i have severals DHCP on my network and this script (i suppose) make the ipxe boot taking the wrong dhcp server and trying to boot on it. You can see here the dhcp is swapping between 172.31.43.1 and 172.31.37.252. Each time i restart the fog isc dhcp server, it took the good one but each time i reboot the client, 1/2 chance the iPxe took the wrong one because my other dhcp is responding. Is that strange ?

If you already have another DHCP service, configure that one and turn fog’s DHCP off - or - turn off the other DHCP service, and just use FOG’s DHCP.

If you don’t have split-scope configured correctly, you cannot run two DHCP services on the same broadcast domain anyways. You’ll have IP conflicts like crazy.

@Arrowhead-IT It’s definitely worked for test VM’s that are used for image testing, but it’s also a more general comment for ESXi in general. Worth checking your server guests to ensure they’re all on vmxnet3.

@Wayne-Workman
thank you very much.

@Arrowhead-IT I figure that I should report that in my recent testing with the latest client I have not had any problems with the client being installed as part of the image. It works as it should. I intend to use the script I posted here as a gpo script to add all the active directory computers on my network to fog in one quick click.

@Wayne-Workman thaks.

Well, let’s hope that fdisk is not doing any unnecessary checks causing us issues then… 😉

The function itself looks pretty straight forward, I like it this way.

@Arrowhead-IT the size difference is the folder that stores the data for btsync. For git and svn you’re pulling the whole tree, including past revisions. In the case of btsync the initial pull is of the same size as the svn or git pulls but you’re only getting he changed files rather than a whole new revision.

@Tom-Elliott Will we be able to alpha/beta test FOG 2.0? I’d really be interested. 😄

@Tom-Elliott Confirmed, tasks are pulling down the boot files and image data from the correct node consistently, and updating nodes pulls from the newly set node as well. Awesome work, thanks!