For now the logging is as basic it could get, it contains info that one is used to to get from a web server. tlwebaccess is a service and we should have a more proper logging which resembles more to vsmserver/agent logfiles than a webserver. 2014-03-10 09:31:58 INFO tlwebaccess[21955]: "GET /styles/menu_style.css HTTP/1.1" 200 - 2014-03-10 09:31:58 INFO tlwebaccess[21956]: "GET /styles/main_style.css HTTP/1.1" 200 - 2014-03-10 09:31:58 INFO tlwebaccess[21957]: "GET /favicon.ico HTTP/1.1" 200 - 2014-03-10 09:31:58 INFO tlwebaccess[21954]: "GET /images/cendio_logo.png HTTP/1.1" 200 -
Looking at the code of tlwebaccess:442 it should log authentication failure to logfile but I cant see any entries in the logfile.
(In reply to comment #1) > Looking at the code of tlwebaccess:442 it should log authentication failure to > logfile but I cant see any entries in the logfile. This is unrelated, i never trigged this code path.
Session start/reconnect, authentication success/failure logging and some generic error logs committed as r28839. Spent a lot of time getting familiar with the framework and investigating/reporting related bugs.
- POST/ GET log messages appears after an error which is raised with the handling of the request. #grep 15129 /var/log/tlwebaccess.log 2014-04-15 07:52:30 ERROR tlwebaccess[15129]: valid_username: Username u'b\xe5sse' can't be encoded in the system locale (ANSI_X3.4-1968) 2014-04-15 07:52:30 INFO tlwebaccess[15129]: 'POST /main/ HTTP/1.1' 200 - - There is no logging of which agent the user get a session on, this makes it hard to know were to follow up the logging trail of a login in a cluster. - If agent is down there is two error message presented to the end user: [ Failed to create new session:... [ Internal error. If this problem persists... - There is no way to follow a login session trail in the log file, maybe we could use a session id hash which is generated on main page which follows the whole login process, even when redirected to agent. With this we could prefix log entries with '[sessid] ...' and administrator could easily grep this on both master and agent to get all relevant logs for a login session....
(In reply to comment #6) > - There is no way to follow a login session trail in the log file, maybe we > could > use a session id hash which is generated on main page which follows the whole > login process, even when redirected to agent. With this we could prefix log > entries with '[sessid] ...' and administrator could easily grep this on both > master and agent to get all relevant logs for a login session.... Created Bug #5092 for this issue.
(In reply to comment #6) > - POST/ GET log messages appears after an error which is raised with the > handling > of the request. > > #grep 15129 /var/log/tlwebaccess.log > 2014-04-15 07:52:30 ERROR tlwebaccess[15129]: valid_username: Username > u'b\xe5sse' can't be encoded in the system locale (ANSI_X3.4-1968) > 2014-04-15 07:52:30 INFO tlwebaccess[15129]: 'POST /main/ HTTP/1.1' 200 - Moved to bug 5097.
(In reply to comment #6) > - There is no logging of which agent the user get a session on, this makes it > hard to know were to follow up the logging trail of a login in a cluster. r28873 > - If agent is down there is two error message presented to the end user: > [ Failed to create new session:... > [ Internal error. If this problem persists... r28874 Additional fixes within the scope of this bug: r28875 makes the non-generic error messages match those of tlclient. r28876 fixes a traceback and logs more info about reconnection failures
(In reply to comment #9) > r28875 makes the non-generic error messages match those of tlclient. Updated in 28877, <br /> -> <br>.
(In reply to comment #9) > (In reply to comment #6) > > > - There is no logging of which agent the user get a session on, this makes it > > hard to know were to follow up the logging trail of a login in a cluster. > > r28873 > Works as expected. > > - If agent is down there is two error message presented to the end user: > > [ Failed to create new session:... > > [ Internal error. If this problem persists... > > r28874 > Works as expected. > Additional fixes within the scope of this bug: > > r28875 makes the non-generic error messages match those of tlclient. > > r28876 fixes a traceback and logs more info about reconnection failures Looks good to me.
