Found the issue and was able to fix. Fix will be available for RC-6.

Thank you for reporting.

@Wayne-Workman Thanks, yes I may move to 64 bit. However it’s good that my issue has highlighted the inconsistency in the code which sounds like it only shows up in 32 bit OS’s. I’m guessing there mustn’t be too many others with my setup out there, otherwise this would have been reported a while ago. Glad its a relatively easy fix, I’ve rebuilt these boxes a few times recently and didn’t wish to have to do it again. Regards, Mark

I feel I should add, the reference error isn’t the cause of the issue, not directly at least.

@Wayne-Workman Fixed issue will be available in RC 6.

Issue would only occur in the case a user made a change, then hit the “back” button.

I’ve corrected the action of this for all elements that have these same type of actions. Will be good for RC-6.

@ablohowiak As a side note here, if you’re 100% new client in your environment, remove the legacy password in fog, just blank it out in the fog config defaults, and on hosts via groups. The legacy pass has security vulnerabilities.

Great! Compliments for the super quick response and fix. That’s what makes Fog stand out!

This is already fixed for rc 6.

Group snapins should properly deploy. Will be available for RC-5.

Issue confirmed. I was tryign to fix a bad status update in the repo earlier and apparently one of my links ended up in the mix.

I deleted the entire repo and readded what was requried back.

This should be fixed now.

Please re-pull your repo (this only affected git users).

One node crashed this morning. I was rebuilding it. The node was still enabled in fog - and because it wasn’t responding it caused the above error and a chainloading issue on hosts. The node that was not working was not the node that technicians were trying to deploy from.

Great! Thank you!

Already fixed in RC-3

Already fixed in RC-3

@Wayne-Workman Tom posted a hot fix (i.e. you fix-it) for RC-2 here: https://forums.fogproject.org/topic/8172/if-email-when-complete-is-enabled-the-database-is-unable-to-clear-the-task/2

Already been corrected for. Fix will be in the RC-3 release.

For those that use the email functionality, please edit the file:

/var/www/fog/lib/reg-task/taskqueue.class.php

Go to line number 58 and replace the ‘sanpinjob’ with ‘snapinjob’.

Save the file and all should be well.

@george1421 and if I recall the access control is already built for 2.0.

While I agree plain removing it seems a bit harsh, it can still be side loaded. Remember, I maintain a backup of the version being installed. So the backup of the original web structure is still available, with the only exception being when one goes to install rc-3. The rc-3 backup will remove the accesscontrol. If you go to the rc-2 backup (from when you installed rc-2) you can still get a copy of the access control plugin. While not perfect and does require a little extra work, it is still relatively easy.

For now I’m solving this. I realize the issue at hand is likely still there, but this (at this point) is not a problem of FOG or the FOG Client in a “bug” form. This seems much more likely to be a problem simply with disk space. Of course feel free to post info as we find more info out.

@JJ-Fullmer no it would not. The idea is to get a good working list of issues that will then be addressed for RC 2

@Wayne-Workman I suspect all is already fixed in the working area. You can create the log, and if you can see when/where/how the change happened, it certainly will help. I’m 98% sure it’s a specific set of actions necessary though, which is why I can’t seem to replicate it.

I’m certain it has nothing to do with the location plugin, just in case you were going to try with and without the plugin installed.