FOG's web interface doesn't work.

[JJ Fullmer]

@Wayne-Workman Well then what is that host 10.51.1.53? is it your server or a random client?

[Wayne Workman]

@JJ-Fullmer it’s the main fog server.

[Wayne Workman]

This post is deleted!

[Wayne Workman]

So after extensive troubleshooting I finally figured what was causing this.

A single storage node being totally offline and unreachable.

Via CLI through MySQL, I disabled that one node, and all was well.

I’ve told Tom this, and he’s working on what caused the web interface to simply not work due to a down storage node.

[Tom Elliott]

I believe your gui response time was horrible. I don’t know why, if that’s the only node that’s “enabled” persay.

The graph enabled plays little bounds in regards to the client count (yes I know).

If the graph is disabled, it doesn’t mean the slots aren’t available. So I have a more automated means of checking these things. When it comes to dashboard getting/setting specifics, we only care about the is graph enabled, (in regards to bandwidth and graph size).

Running through many different components, if you can try accessing a direct link as opposed to starting off in the “home” page, do things actually seem to work?.

I’ve, in regards to this, figured out a more appropriate way handle the successive connections. No a single item being down should not have any impact on page display and I’m completely unable to validate. I now have a much cleaner way to handle the url processing though.

This is what fixed the GUI unable to deploy issue for @JJ-Fullmer . I am only guessing here though.

The page loads tons faster now and the javascript will help prevent tons of access requests to the other nodes as well. (We still test the active count which still requires the checks though) so some connections will have to be made. If that isn’t “suitable” then maybe we should remove active count auto-updating? It is currently set to update at the same interval as bandwidth page.

[Wayne Workman]

@Tom-Elliott

The graph enabled plays little bounds in regards to the client count (yes I know).

The node that was totally in the real world offline - it’s graph was disabled but the node was enabled.

All I did was change the node from enabled to disabled. Immediately the web interface started functioning.

Later, I re-enable the node (not the nodes graph) and immediately tge web interface totally quit working again.

[Tom Elliott]

@Wayne-Workman im aware of this, but I have still yet to see this myself. The problem, as I stated earlier, is it still is checking all nodes and for what ever reason is hanging on the down node. Was it white screen or seeming to try loading? (Circling about) which was why I asked about going directly to a site such as node =host.

What are your URL timeouts set to?

[Wayne Workman]

@Tom-Elliott my url timeouts are whatever is the default. I messed with that earlier without any effect so I put it back as it was.

The page attempted to load for a while, quite a good while. Perhaps 20 or so seconds. Then it failed.

[Tom Elliott]

@Wayne-Workman maybe 30 seconds, without fail? Default execution time for php is typically 30 seconds. Then it will fatally die out. I’ll try working out the kinks a bit later, such as having JavaScript handing if the page is available or not.

[Tom Elliott]

RC-22 officially released.

Please update, though for your unable to use issue I don’t know fully a nice answer.

I still haven’t been able to replicate.

[Wayne Workman]

I’ve updated to RC-23. I can’t say if the issue is solved or not because all of our nodes are online right now.

[Tom Elliott]

If you get a chance, maybe try stopping the httpd/apache2 services on a couple of nodes to see if all just get’s hung back up?

[Tom Elliott]

Any word on this?

[Wayne Workman]

I think the issue is solved. At home, I just shutdown one of the nodes I have without adjusting any configuration and the web interface stayed operational.