Bugs in FOG 0.33
-
Oh… Just noticed this thread. Not sure if i’ve found a bug or not, but I just updated to 1210 and now under Disk Information on the Dashboard, I have this error/link that says, “Failed to connect to DefaultMember”. When I click the link, it takes me to the Hardware Information screen and has a message saying, “[FONT=Ubuntu][COLOR=#555555]Unable to pull server information!” [/COLOR][/FONT]
-
That’s not really a bug, but a configuration issue on your FOG Server as far as I can tell.
-
Hmmm… I’m not sure how it was a config problem. I pretty much used the default settings, other than IP, subnet, etc…
-
Right,
How are you hosting your /images? Is it linked to another source or just the base /images?
Are there any messages in /var/log/{httpd,apache2}/{error_log,error.log}?
Maybe also check the access_log,access.log files.
-
Ok, I see what I did. I tried to modify default in /etc/apache2/sites-available/ to default to [url]http://(ip[/url] or host)/fog, so all I would need to do, is type [url]http://(ip[/url] or host) to get to the Fog login page. It was working, but I was getting the above error…
-
So it was a sort of configuration issue?
-
I guess so. I saw where the Fog install adds the index.php with a redirect to “./management/index.php”, but apache2 didn’t recognize it. It just kept showing the default apache “It Works!” page. But, once you remove the default “index.html” page, everything seems to work just fine. Perhaps a Fog installer oversight?
-
No it’s more an apache2 installation thing on Debian systems.
-
BigMan99211, You need to adjust apache to look for php before html, or remove the html file as you described above. This is not a bug.
That “This works!” page is a default created by apache as a courtesy to check on localhost to make sure your folder is accessible. I theory we could add a “remove index.html if exists” line, but for those of us that use our FOG servers as web servers (internal or external) this could cause a HUGE headache if your index.html went missing.
-
I can understand that. But, couldn’t you just put in a simple question during install, asking if you have any other websites or software that utilizes Apache? If yes, it skips. If no, it deletes the .html file. Seems pretty simple.
-
I’m sure it could, would be easier to attack the apache config file and add .php extension to the file so it looks for the php file first
Besides it tells you after you finish installation to navigate to the “[url]http://ipaddressofserver/fog/management[/url]”.
Hell, if I remember correctly the link is even clickable in the terminal window so you don’t actually HAVE to type or copy anything, just make a shortcut.
-
I’ve always been a proponent of making installations easier, or even more customizable through the installer. Ask a bunch of questions at first, and make the setup and configuration a lot more seamless.
-
I like your stance, but I feel differently about the said subject.
I could climb on a soapbox, but my final words to utter are “this is not a bug, and does not need to be addressed.” and that’s my two cents. If others feel the same way as you do, you need to twist Tom’s arm to get what you need
-
Could there be some kind of option during the installation wether to choose clamav and htmldocs or not? Installing these packages on Redhat/Centos needs editing in the config file as it will not work out of the box.
-
That is because FOG 0.32 is sorely outdated and was meant to run on the older versions of linux. Since then newer and updated packages are being used in the later distributions. Tom is working on FOG 0.33b and I’m sure when all is said and done he will iron out the issues with htmldocs and clamav by updating the repositories and versions it uses/installs.
In the mean time please use the work arounds found on the forum to install and configure the services.
Tom started working on FOG here recently he wasn’t always the maintainer so he doesn’t have access to edit the old FOG 0.32 files and NOR should he.
-
Sorry I forgot to mention I refer to 0.33 beta…
-
The deploy date in host management, as proposed/discussed here some days ago. Here is an example of how I think this could be (in red font): [url]http://awesomescreenshot.com/03a2cmvxc2[/url]
This way it is really easy to find “old” hosts which I have to get to my office for imaging.
-
This isn’t really a bug, but a request. That’s okay though. It will require a minor schema change, but I have to do so anyway to enable shutdown to work with iPXE.
-
Whilst I think it would be good for deploy date, that still leaves the issue of having to find what image version you deployed. Of course maybe each deploy date could have the image version with it.
For this (and other benefits) I have bginfo installed (connected to sql, and then MS Access for reporting) and have a reg key that bginfo picks up. The reg key gets updated to corresponde with the fog image it will become once uploaded -
Another missing feature is a date when an image was last uploaded: (red font) [url]http://awesomescreenshot.com/0682cwm8e6[/url]
