@brakcounty said in Newly captured images are being owned by "root" instead of "fogproject":

Well all of my other images in /images are owned by fogproject:root. If this isn’t a problem then I’ll leave it alone.

That’s done when you re-run the FOG installer. Just don’t worry about it. They’ll work either way.

@pamadmax Its great that you have it solved. Intermittent communications would also cause this pattern.

Just to clarify the point a bit about dual dhcp servers. If your fog server is on the same imaging network and its “the dhcp server” for your imaging network, then you don’t need a dhcp-relay service listening on this subnet. Actually you should clearly not have it listening on this subnet. You can have the dhcp-relay service on your router, that’s fine, but not listening on the imaging network’s vlan.

The issue is this, if the dhcp-relay service IS listening on the imaging subnet, the relay service will relay the dhcp request to your main server. With the FOG dhcp server also listening there is a chance that your pxe booting computer will get two OFFERS. One from your FOG server and one from the dhcp-relay service as a proxy for your primary dhcp server, hence the comment about 2 dhcp servers.

You have it worked out, so that is all that really matter here. Good going on finding the problem. I’m sure that misconfiguration on the LAG trunk was causing other strange issues on your network too.

@Pilar Please post pictures of the configuration in the web UI.

@Pilar There is no place to check. Re-running the installer script should correct all the permissions for you. Though you seem to have modified your storage setup a lot now and I am not sure the installer script will take care of this.

Of which directories do you want to know the permissions?

Same here, please give this topic a proper headline!

@Pilar You probably want to add this to the other topic: https://forums.fogproject.org/topic/15911/without-master-node

Why several postings with seemingly the same question? As well you might change the heading of this topic to match it’s contents!

@sigit FOG is a one to many bare metal imaging solution. I don’t think that fits your requirements about updates and patches. PDQ Deploy and Inventory might be a good fit for that bit. FOG does have a snap in function (application deployment) that can be connected to image deployment, but its not really a stand alone solution.

With inventory it can scan for installed software and then you can create policies and have pdq deploy enforce those policies.

Also you could look into chocolatey https://chocolatey.org/ for patch/ application deployment if you wanted to stay in the FOSS user space.

In any case for a non-domain environment you will need to have a consistent admin user account across all non-domain computers for the above solutions.

@mikael1909 While I haven’t tried these specific boot disks. I don’t read russian at all, but it looks like these boot images are windows pe based. You should be able to get them to boot.

What have you tried so far?

What errors do you see? If you post a picture of the error it might help debug the problem.

@george1421 thanks for the quick answer.

I’m aware that the power of FOG is in the multicast deploy. But I have to say that I tested it with 25-30 capture tasks in parallel, and if you have the hardware+infrastucture, it works like a charm 🙂
I already have the registrations, image definitions, groups etc., but I won’t do it on scheduled basis, only on manual basis.
My only problem is the lot of clicks which I have to do, if I want to do it manually:) That’s why I asked this question here.

I will have a look at the Powershell API, it will probably/hopefully solve my problem 🙂

Thanks!

Yepp, I have the same problem, I see the status only after a few minutes, when the text gets “streched”. If there is a solution, it would be nice to know:)

We have an “easy” solution for this. We are using a NAS (a Syno in our case) to store the images, and we enabled the recycle bin. When the image is overwritten by FOG, the old one goes in to the recycle bin of the Syno (#recycle). Depending on the filestore size(we have around 32TB), number of hosts, size of the images and the size of the recycle bin, you can have the “history” for a few days.
The images are renamed in the #recycle of the Syno(e.g. d1p4_1.img or d1p4_5.img) and if you need an older image, you just copy it back, and rename it.(e.g. d1p4.img )
We can go back in this way, for 5-6 copies, in your case it would be 5-6 days.
I hope it helps.

@brakcounty Well done!!

Where I also see value in this is if someone wanted to hard drive boot into iPXE then from iPXE into the hard drive or FOG without using PXE booting. Instead of a usb drive, everything could happen off the efi partition on the local hard drive. It would not solve the secure boot part of it, but its an option.

Also lets say someone wanted to setup a preboot menu (such as for dual booting) using refind. Your idea could be tweaked slightly to boot into refind menu manager and then pick to boot windows, linux or something else from the refind menu. There are a number of options this method opens up. Again, well done!

Hi,

i have FOG 1.5.0 running on an ESX Host and a Storage Node on a bare metal machine.
Works like a charm since years.

Best Regards X23