Solved trunk 3775 issues
When updating to the newest beta release of fog, some issues have come up that I haven’t been able to resolve.
1 - The configuration page within Fog no longer loads. It loads for a blink of an eye and then it redirects to: http://192.168.142.72/static/index.html
with the error: Not Found. The requested URL /static/index.html was not found on this server.
2 - When installing updates for the trunk release, it now is hanging up at “Updating Packages as needed.” I have let it sit on that screen for over 12 hours. If you press Ctrl+C it bypasses it and continues the installation/upgrade.
3 - When pushing a new image out to the server, it created the image in the /images/dev/0800272e575e folder. However, the image was not copied down to the /images/(new_image) folder. A Folder was never created. I had to create the folder and copy those files to it. Fog console then recognized the image and was able to push it out for deployment. Any ideas?
Any help with these issues would be greatly appreciated.
I teamviewered in. Found that the redirect to static/index.html was not something FOG Was causing.
The NAS was NFS Mounted to the FOG Server. But as they had found out, the NFS From FOG Couldn’t redistribute the share as NFS. Because of this, Storage Node was pointed directly at the NAS and volume of the NAS to allow imaging to occur. However, when going to FOGConfigurationPage it was attempting to go to the NAS’s management portal, and because it was invalid, it was being redirected per the NAS’s settings.
Changed the Node to the FOG Server proper information and FOG Configuration Page loaded with no issues.
@tom-elliott Hi Tom,
As my previous message stated, would you know what may cause the configuration page at: http://192.168.142.72/fog/management/index.php?node=about redirect to:
This happens every time and I can’t get into the configuration.
If you need further info, let me know. I appreciate all of your help.
@cmcleod How can I help?
@Wayne-Workman @tom-elliott Here is an update:
The upgrade installations for trunk are now working. Maybe it was related to sourceforge being down?
Anyways, the remaining issue is when I click on the configuration page. If I hover my mouse over the configuration link, it shows the link:
If I click on that link, it takes me there for a brief second and then it goes to:
That page is even outside of the fog site. I’ve looked at the php file. I’ve tried backing up and reinstalling to put the fog pages back in place. None of that seems to fix the issue.
I really need to get to the configuration site to make changes and I can’t do anything right now. Any help would be greatly appreciated.
@Wayne-Workman I’m running CentOS 6.6. I ran yum update and then rebooted the system. There were only a few minor updates.
I then went to ~/trunk/bin/ and re-ran ./installfog.sh
Updating packages as needed still hung up at “Updating Packages as needed”. I had to ctrl+c to cancel and then the rest of the install went fine.
The configuration page is still not loading with the same error.
Wayne Workman last edited by
Can you update your os first and then run the installer?
Thanks for your response @tom-elliott
1 - the webroot should be http://192.168.142.72/fog
All of the other pages seem to load fine except for the configuration page.
2 - I have not edited any files with regards to the installer.
3 - I’ve had FTP issues in the past and had them resolved. However, I can’t get to the configuration page to confirm the username and password entered for FTP.
Thanks for your help.
Is your webroot supposed to be called as: http://192.168.142.72/fog/ or http://192.168.142.72/ ?? the difference being the fog at the end.
Have you edited any files on your own dealing with the installer? Many times, people edit their own files but when a new upgrade happens the edited files do not get updated.
This sounds like an FTP issue. When an image finishes uploading, it moves to /images from /images/dev/MACADDRESSHERE using FTP. This is a kind of security effort to ensure not just random people can write/overwrite your /images files. If this fails, it’s most usually directed because of FTP user and pass not matching properly. This could also be a portion due to the webroot issue described in #1.