@Wayne-Workman, Well I could just copy the key from a backup and be ok then. But the issue then comes into why did my snapins directory get cleared out and recreated. I hadn’t had that happen before. It should have been left there and the key should have been present. Might be an issue for @Tom-Elliott to look at. Unless he feels that this could have been a fluke. I might be able to copy my server in a couple days and try the update again and see if I get the same results with the snapin folder being cleared. But if it shouldn’t be cleared I will just copy the file from a back up for now.

Although the new clients are working as is, even with the key missing.

I appreciate the help and all the effort everyone puts into FOG. I wish I had more time to contribute to the product. But unfortunately I am not able to much at the time. So I understand the dedication it takes to keep this awesome product moving forward.

I just discovered a few other oddities that I hadn’t paid attention to as they were not want I was looking at. But my Snapin folder was empty so all of my snapin had been removed. I do have backups that I take daily of my server and was able to recover the files. But it is slightly odd and could point to an issue in the script. maybe.

@Wayne-Workman, Yes, I did check and it is not there. I just checked again to make sure and no files are in that folder. but the folder does exist. Not sure where it is created. I did find there is a hidden file for the srvprivate key in the folder, that I didn’t see before. The permissions of the folder look like I would expect. But here is the output in case that is the issue.

ls -la /opt/fog/snapins/ssl
total 12
drwxr-xr-x 2 fog www-data 4096 Jan 11 13:00 .
drwxrwxr-x 4 fog www-data 4096 Jan 11 16:53 ..
-rw-r--r-- 1 fog www-data 3243 Jul 22 10:46 .srvprivate.key

BTW I do have a simple script I normally run that does a pull and update FOG. I hadn’t updated FOG in quite a while as I hadn’t been having issues and couldn’t affford the down time. But I had the time and wanted to get up to date so that is what started this. IDuring troubleshooting though I obviously did all commands manually. I can’t remember the version I went from but the commit number was 8927628 according to my git reflog if that helps.

I found what the issue is, looks like I am missing a file somehow.

/opt/fog/snapins/ssl/fog.csr: No such file or directory

I even tried re-downloading the latest and still have the error. I then downloaded the previous commit and got the same error. I was able to install with the commenting out the goto error in the install script and everything including the client seems to be working. But not sure why that file is missing and not getting replaced when I re-install.

So as it sits I am on 5927 with the system up and running. But still would like to figure out how to create the file and I guess report the bug of this file not being created to be used.

I am trying to update tot he latest GIT version as of 1/11/16 3:15pm EST and I get a failure on “Creating SSL Cert”. everything else gives an ok, but the the webpage is no longer available. I am on Ubuntu 14.04 and I am up to date on it. I tried reinstalling and have had no luck getting the server to come back up. Can someone please help?

When you set up the OS either Ubuntu or Cent are you creating a user named FOG? If so that could be the issue. FOG creates this user and it should not exist before hand. Try using a different username.

Is there any way to hard code the ip address into this key or would you have to type the IP every time?

No the host would not lose it’s group. Host can be a part of multiple groups. Just make sure you only change the service settings in the “all” group. A group is just a mass change to the hosts contained with in that group.

What does the task list on the server show? From scanning the log it appears the server is being contacted and it knows it should reboot if there is a task, but it isn’t finding a task. I wonder if the MAC address is wrong on the server, not sure who all has access to your FOG server but could be someone accidentally changed the MAC. I know it has happened to me especially when someone new gets access and starts poking around on the server. It will be great if more granular rights can be given in the future.

Also if you are on Trunk, as you indicate with SVN445 is there a reason why you are not wanting to use the new client? The new client works much better with Trunk as it each are being developed together. I assume the @Developers are not really focusing on maintaining the compatibility with the legacy client as it is being depreciated.

Is this a laptop? If so I know the legacy client had a few issues if the wireless was on and connected to Ethernet. Try turning off the wireless and see if that helps.

Windows 7 does have local Group policy settings that you can use without AD. You could also set a log in script that will remove all these files. you could use a simple script that will delete all files on the Desktop and Downloads file, and leave only public desktop icons. The script could be as simple as:

Del %systemdrive%\users\%username%\Downloads\*.*
Del %systemdrive%\users\%username%\Desktop\*.*

You would save that as a batch file, like logon.bat. This will remove all files in the users downloads and desktop folders, but will leave public folders as is. You can set this as a log in script in the local Group policy manager, by typing gpedit.msc in the search box in windows 7. and then go to User Configuration>Windows Settings>Scripts(Logon/Logoff), Double click log on and add the script there. You can build this into your images, so that it just works every time. If you ever need to change the script and add more things, simply create a snap in to copy a new file and over write this script and the new script will run.

There are other settings in Group policy that maybe able to accomplish this without scripts but not sure which ones work best for you. I would suggest looking around at it a little and see what is possible.

To understand better you are wanting to activate windows when imaging? Do you want FOG to do this? What version of FOG are you using? The new client and trunk version of FOG supports product key and activation. Are you using an MAK or VLM or is each PC going to have a different product key?

Can you please post what version of FOG and what OS you are using?

@Wayne-Workman I think you maybe right now that I look at his dhcpd.conf file a little closer I noticed option tftp-server-name line in his config. I have run into issues in the past with this. @stan6595 Can you try removing, or remarking this line out and restart your DHCP and see if that works for you? service dhcpd restart

Not a guarantee, but like I said I have seen where it can be an issue. The next-server should be fine for passing the option to the client.

Have you tried a different client, just rule out that variable?

I am using the latest trunk, 4900 and the new client 0.9.5. My server is an Ubuntu 14.04 build and windows 7 64 bit pro clients. I cannot say when this exactly started happening or if it has always been there, but I do know it was happening on 4684, I think that was the version I was on when I started paying attention the history. This has been a somewhat intermittent issue as I can deploy it and it says complete sometimes, but not others.

When I deploy a snapin, it will deploy correctly to the machine and everything is fine, except on the snapin history page it shows that it was cancelled instead of completed. I have checked the FOG.log and it shows a return code of 0, here is a snipit from one of the machines. fog.log . As you can see most of the snapins are batch files, they call software from elsewhere, but I also have am running a vbscript with cscript and still get the same result code. Which the result code is a clean error code, so it is a good exit code. Not sure if anyone else has encountered this or not, but can someone point me in the right direction as to why this might be?

As you can see the run times are across the board for the same snapin, but don’t seem to affect weather the complete status is complete or cancelled. Let me know where else to look at for a reasoning for this

If you formatted it as NTFS that is the start of your issues. It needs to be ext2, 3, or 4 in order to work correctly with FOG. Try reformatting and mounting it as ext 4 and see if that fixes your issue.

@ciprian you said that when you set it up that eth1 was what you were using as the dedicated imaging nic, but it is set to eth0. Can you try changing that setting to eth1 and let us know if that works?

I was going to suggest the same setup as I almost always set my servers up that way. I like the separation.

Once you answer the questions raised by @Wayne-Workman then you can actually proceed with the rebuild. It sounds like you have a physical server from your description, does it have just a single nic or multiple? Also make sure you have the IP of the server and/or name of the server. The clients will need it to stay the same, unless you want to updated with GP and new config file. On the legacy clients it is trivial to update the config file with GP if you choose to change IP’s or names.

Also given that you are rebuilding the server this may be a time to weigh the Pros and Cons of upgrading to trunk as it is rather stable and offers many new features.

I would run the back up script and also do the export as @Wayne-Workman mentioned and save all of this to an external location either usb HDD or network location. I would also include the .fogsettings file, usually in /opt/fog/ for Ubuntu, as it has the original install settings stored in it. As long as you want it back to how it worked on install this could save sometime.

** A side note that may help, backing up your fstab file under /etc/ maybe wise also as it most likely will have the mounting point for /dev/sdb1 as the /images dir. (If the second HDD is auto mounted as /images as you have indicated). I will often unplug the second drive as to ensure it will not overwrite any thing during OS re-install(saving time on coping images back). I have had bad experiences in the past on this.

Then I would reinstall your OS and if you are staying with 1.2 then definitely use 12.04. But if you choose to upgrade to trunk then 14.04 or higher maybe a better choice. Then set you IP if it is static on the server. Proceed with the reinstall of FOG, you can copy the .fogsettings file from backup to the install location, usually /opt/fog/ if I recall correctly. After it is set up and database is configured then you can restore the database from the web gui. You can copy the “snap in” back up directory to the “/opt/fog/snap in” directory. If you chose to back up your fstab file then restore that to /etc/ (make sure to backup the original fstab in case there is a conflict), shutdown the server, plug in the second drive and reboot. If all goes well FOG should be installed and images there and ready for deployment.

@Wayne-Workman if I am missing something please chime in, I think that pretty well covers it though.

A couple of questions and a few starting points. First is FOG serving DHCP or is that done by a different server? Second what version of FOG are you using?

Now to the high level thoughts on starting to rebuild the server. First you should run the FOGbackup script included in the installer directory. This will get you a backup of all your necessities, such as your DB, Snapins, and images. From there you could re-install and then reload the DB and snap ins.

But in order for us to better assist you we need to know the version of FOG as there are many different ways to approach things depending on your version and what version you are looking to go to.