[BlueOnyx:25706] Re: BlueOnyx 5211R Released (How to chase errors)

[Michael Stauber]

Hi Ernie,

 > Never mind, it only gets stuck when I try and access the server via
 > the FQDN, if I just use the IP the wizard proceeds.

That GUI page is supposed to reload every 10 seconds and during that 
reload it checks if CCEd is done doing setup tasks. So if it seems 
stuck, reloading the page might help. But I'll keep an eye on this.

> one problem I have encountered, is when I go to Network Service -> Shell & FTP,
> I am getting an Internal Server Error message.

I just published a YUM update that fixes it. Many thanks for letting me 
know!

> I have a look in the admserv adm_error log and there is no error message as to the cause.
> Same goes for the normal httpd error_log.
> 
> Any ideas?
Debugging of GUI errors? Oh, you'll love this and will be in for a treat:

1.) CI4 debugging via CI4 Env:
===============================

Open /usr/sausalito/ui/chorizo/ci4/.env in an editor.

At the top it shows this:

#--------------------------------------------------------------------
# ENVIRONMENT
#--------------------------------------------------------------------

#CI_ENVIRONMENT = development

CI_ENVIRONMENT = production
#--------------------------------------------------------------------

Uncomment the 'development' line and instead put the hash-sign in front 
of the 'production' line and save the changes.

Now all errors will show a very detailed GUI page with the exact module, 
code line and error message, with the code in question displayed, 
variable status and what not. VERY useful and neat.

Enabling 'developer' mode in CI4 this way also will show the CI4 status 
bar at the bottom of the browser (or right side lower corner if 
minimized) that has some useful run-time information.

But please note: There are 3-4 GUI pages will not display right if 
development mode is enabled. Such as the integrated Webalizer 
statistics, where the status bar code is automatically injected into the 
display of the GUI page in a disruptive way. But most work just fine 
with development mode enabled.

Just don't use 'development' mode in production as it could reveal 
environment variables to users that you might not want them to see.


2.) /var/log/gui-debug.log & /etc/DEBUG
=========================================

The new logfile /var/log/gui-debug.log logs accesses to the GUI 
interface. So you can see which logged in user went where. Nice to have, 
but not essential. It's more or less useless for debugging.

Now run this command: "touch /etc/DEBUG" (this creates the empty file 
/etc/DEBUG) and then run a "tail -f /var/log/gui-debug.log" while you do 
something in the GUI. :o)

It can't get more detailed that that - right down to the exact CCEd 
transactions that each GUI page performed. With all data being show.

Be sure to run "rm /etc/DEBUG" once you're done, though. Otherwise that 
logfile will grow like a bodybuilder on steroids.

-- 
With best regards

Michael Stauber