@Faheem FOG 1.3.0 has no official API (Our 2.0 rewrite changes this, but it’s not ready for production). A quick look over that github repository seems to indicate that the api-wrapper simply crawled / interfaced the web portal, which has definitely changed in the past 3 years.

@Sebastian-Roth According to this discussion (http://serverfault.com/questions/806875/how-to-tell-isc-dhcp-correct-zone-for-reverse-zone-ddns-update) it has to do with reverse dns lookups

@Wayne-Workman Awesome. Works like a charm. Thank you very much!!!

@palloquin https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

That might help

@Tom-Elliott said in Setup Synology Diskstation as main storage for Fog Sever:

@george1421 this can be seen when imaging two hosts at the same time via unicast.

I guess I’ll have to take your word on this because I looked at the config files again and it looks like he is mounting 172.31.161.246:/volume1/images over /images in the fstab on the FOG server and then sharing out /images on the fog server in the /etc/exports file. The last time I tried that showmount -e 127.0.0.1 showed no shares. But that was a while a go. I was trying to work on a way to create a skinny fog server VM with all files stored on an external NAS. That didn’t work so well.

Thank you for your assistance. I did not realize at first that I had to have the FOG client installed on the endpoint, which makes a lot of sense in retrospect. I installed the client and everything is working properly. You can go ahead and close this thread.

This issue is resolved.

We had the credentials correctly stored in Storage Manager.

After a reboot the partition that had the images’ directory wasn’t mounting correctly and thus couldn’t reached via FTP. Once we made sure that was mounting correctly everything started working.

Thanks for your help!

@lazybeard In this case, you could extract the contents of the iso into a http path on the fog server (i.e. /var/www/html/iso/diskwipe

And then reference the files via http

linux http://<fog_server_ip>/iso/diskwipe/vmlinuz.x86_64 root=/dev/ram0 rw init=/init video=efifb loglevel=3 initrd http://<fog_server_ip>/iso/diskwipe/wipe-x86_64.lz http://<fog_server_ip>/iso/diskwipe/firmware.lz /bcwipe

Understand this is just a guess and it will need to be translated into what iPXE needs to boot the file (you can see that from the url I provided before).

thanks, it works

Hello,

Thanks for your help, i’'ve managed to get FOG working now on the 1.3.4 version.

@Tom-Elliott Hi Tom. I had the same problem when I wanted to deploy my last image (Dell OptiPlex 330/Windows 7 created with the last version of FOG: 1.3.4)
It works fine now thanks to the 1 value in the d1.fixed_size_partitions. Thank you 🙂

@kibade I don’t know if the donate option still works as it was compiled from long ago, but I did see the issue about the clearScreen. I’ve pushed a fix for the clearScreen issue.

I’m not planning to work on anything for the clamav tasking as the intention is to have it mount the clamav portion from an NFS (of which you would need to configure first. This way sigs would not have to be downloaded everytime from the internet.)

Please try :

wget -O /var/www/fog/service/ipxe/init.xz https://fogproject.org/inits/init.xz wget -O /var/www/fog/service/ipxe/init.xz https://fogproject.org/inits/init_32.xz

As I stated, I don’t know if it will still work, but the reboot and error message should be gone. (This is specific to the donate task.)

@Tom-Elliott 0_1485899730465_Firefox snapin.PNG

how long does the client takes to communicate with fog server?

@dbakerwardog
Just checking, the “FOG_AD_DEFAULT_USER” you have set, have you double checked it has permission to add and remove computers from the domain?
I would try moving that computer to a workgroup using the above user and see what happens.

Ok, I found the issue. The Geo IP filter on the firewall was preventing accessing the remi repository, which was keeping me from updating php. Disabled the Geo IP filter and ran a fresh install and everything is working like a charm.

Thanks again guys for the help!

@saablord no problem

yes, solved.

I moved this to “FOG Problems” rather than a “bug” report as there’s nothing I can do to fix this.

As @Wayne-Workman suggested, use the wiki link to help clean up the problems you were seeing.

@rstockham23 I meant reboot once the entire domain process is complete, and then check how long the service takes to startup. (This can be done by monitoring the fog.log by using get-content -wait C:\fog.log from powershell). If there’s an authentication issue again, please post the entire fog.log after you test the reboot.

If the readiness of the client would be sent to the server as unicast (TCP) … * sigh *