Solved it! I removed /var/www/fog and /var/www/html/fog and re-ran the FOG installer. I am now able to create and edit snapins.

@george1421 Yeah I learned the hard way about trying to upgrade from v.31 to 1.x.x last week haha. But I’d rather ask to be sure than to waste a bunch of time one way or the other.

@Gary-Kulovics at the end of the day, you have a much better environment with 1.3.0-rcX series FOG.

@Darrin-Enerson I’ve added the warning and an example method to correct the issue, I think, in a more proper method. This warning will be available for the RC6 (Hopefully it can just be 1.3.0 at that point, but meh.)

Have you tried the troubleshooting steps on the wiki yet?

@ITCC You need to run installfog.sh again after updating .fogsettings

#wiki need to work on snapin pack article.

You would just follow the instructions in the fog wiki.
https://wiki.fogproject.org/wiki/index.php?title=CentOS_7

@adamk858 I can probably script a way to change the fog IP, without involving dnsmasq.

@Tom-Elliott

Okay. That fixed it. I had already modified what you told me to type. I just never did the /etc/exports. Once I did that it all worked. 🙂

Thank you!

Ok i have it working on my workstatons, on the vm servers that I am trying to image it does not show the fog screen and picks the tftp server and then reboots.

If i wish to create a image of a windows workstation Is that the upload option?, so upload to server.
Now if i am uploading a windows image from a workstation to a storage node does that storage node need to have a filesystem that windows will recognize like fat32? or will ext3 do?, as I thought it was only storing a iso so the format of the drive would not matter.

@ixll Just be aware I’m not a dnsmasq specialist. I did write my own tutorial on how I setup dnsmasq. This did work. Maybe you can merge what is in your ltsp.conf with this. https://forums.fogproject.org/topic/6376/install-dnsmasq-on-centos-7

In my example the fog server IP goes into two places.

The most important thing to attempt recovery of (other than images) is the ssl directory. If you have fog clients out in the field running, they will absolutely not trust nor obey any fog server that cannot authenticate. The directory is /opt/fog/snapins/ssl
There’s a walkthrough here:
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_Of_Hosts_When_Building_New_Server

If you can do that, and then re-use the old IP, then all the existing clients will report in to the server as pending.

You may start looking into Ansible, version 1.7 or greater comes with ability to control windows clients.
http://docs.ansible.com/ansible/intro_windows.html

And ansible is free (I think), but Ansible Tower costs.

@Tom-Elliott
OK.
Well, I think I figured it out. I may have missed updating the storage node info. The graphs/pie charts are back working now.

Setup capture and is working. Ugh. the one thing I didn’t double check after it all. Being that its the only storage node I didn’t think to check it again.

Thanks for all of y’alls time. sometimes it just needs more eyes and a better understanding of how this works. Y’all have a great day. I need a beverage.

thanks,
Jason

@alansopro There is indeed a new fog client, though the old one is there as a just in case but probably has its own set of issues. Besides, I HIGHLY encourage all people to use the new client. It’s much faster and less taxing on the FOG Server. While the old client wasn’t overly rough (after its initial load up) it still had it’s own issues to think/worry about.

@george1421 Ah this makes sense. My colleague notified me he uploaded an image and it didn’t seem to finish the task. That is when I noticed the disk was full. Got it.

Can you show us the logs verbatim then? You’re not seeing the exact same error if it’s not saying ‘ftp_login incorrect’

@george1421 It works ! Thanks for your support 🙂
edit : Yes I’m running dnsmasq.

Crosslinking related threads:
https://forums.fogproject.org/topic/8189/power-management-scheduled-shutdown-flakey