QUESTION
How can I find information logged by BYOD Gateway.
Information
BYOD Gateway logs information about the general health of the gateway as well as requests made from registered users. All the log files are stored in the BYOD Gateway Data Directory.
See the About tab for the location of the Data Directory on your BYOD Gateway or https://helpdesk.kaseya.com/hc/en-gb/articles/229040488-Why-can-t-I-find-my-gateway-data-directory for more information.
If you are reporting any issues with your BYOD Gateway you should include copies of these logs as well as any errors shown in the BYOD Gateway Control Panel
ANSWER
The following information is logged to the files described below.
Gateway.log - This file logs information every time the BYOD Gateway starts or stops. The log file is archived once a week. Any errors encountered by the BYOD Gateway is also logged to this file.
Examples of information logged to gateway.log file:
BYOD Gateway Start:
[05/Oct/2011:22:42:45] BYOD Gateway 2.1.0.30 STARTUP
[05/Oct/2011:22:42:45] Site database: sqlite:///C:\ProgramData\BYOD Gateway\byodgateway.db
[05/Oct/2011:22:42:45] Trace log level: INFO
[05/Oct/2011:22:42:45] Session is <sqlalchemy.orm.scoping.ScopedSession object at 0x01C3C2F0>
[05/Oct/2011:22:42:45] Gateway configuration READY
[05/Oct/2011:22:42:45] Gateway security certificate READY
[05/Oct/2011:22:42:45] Control panel access via https ENABLED on port 1456
[05/Oct/2011:22:42:45] Panel SSL certificate 'C:\\ProgramData\\BYOD Gateway\\byodgateway-ssl.cer'
[05/Oct/2011:22:42:45] Direct portal access DISABLED by configuration
[05/Oct/2011:22:42:45] ENGINE Bus STARTING
If the BYOD Gateway has any issues at startup the gateway log file will show the details. The above information shows a successful startup. More or less detailed information can be logged by adding the following information to the BYODGateway.ini file.
Each logger can be assigned a particular log level. Messages at or above that level in importance appear in the log; messages below that level are discarded. The levels are, in descending order of importance:
- CRITICAL - ERROR - WARNING - INFO - DEBUG
By default, all loggers are set to the INFO log level. These settings can be overridden in *byodgateway.ini* as in this example:
service_loglevel = WARNING
Note: Be careful making any changes to the BYODGateway.ini file. The information included in this file is used to connect to the relay service. It is recommended to make a copy of the file before making any changes in case you need to reset to default values. The changes take effect when you restart the BYOD Gateway.
Portal-access.log - This file logs information every time a user requests data from the BYOD Gateway. The log file is archived once a week.
The static codes used in the portal-access.log file conform to http status codes,http://en.wikipedia.org/wiki/List_of_HTTP_status_codes.
Common status codes:
401 Unauthorized. Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. You will commonly see a 401 followed by the same request with a 200 or 304. See detailed "Client requesting access to the BYOD Gateway" for more information about this interaction.
403 Forbidden. The request was a valid request, but the server is refusing to respond to it.Unlike a 401 Unauthorized response, authenticating will make no difference. On servers where authentication is required, this commonly means that the provided credentials were successfully authenticated but that the credentials still do not grant the client permission to access the resource (e.g. a recognized user attempting to access restricted content). If you are seeing 403 errors that you do not expect check the Access restrictions set on the Site tab to ensure you have not restricted access for this user.
200 OK. Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request the response will contain an entity describing or containing the result of the action.
301 Moved Permanently. This and all future requests should be directed to the given URI.
302 Found. This is an example of industry practice contradicting the standard. The HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect (the original describing phrase was "Moved Temporarily"), but popular browsers implemented 302 with the functionality of a 303 See Other. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours. However, some Web applications and frameworks use the 302 status code as if it were the 303.
303 See Other. (since HTTP/1.1) The response to the request can be found under another URI using a GET method. When received in response to a POST (or PUT/DELETE), it should be assumed that the server has received the data and the redirect should be issued with a separate GET message.
304 Not Modified. Indicates that the resource has not been modified since the version specified by the request headers If-Modified-Since or If-Match. This means that there is no need to retransmit the resource, since the client still has a previously-downloaded copy.
Examples of information logged to portal-access.log file:
Client requesting access to the BYOD Gateway:
Type of connection | Time/Date of request | Type of request | HTTP Status Code | Type of client
IP address/relay - - [05/Oct/2011:13:03:04] "GET /siteinfo/ HTTP/1.0" 401 - "-" "Chromis/1.9.2 (CL 3; iPhone 4.2)"
In this example the client is requesting site info for the BYOD Gateway by providing the Access Code and username/password for the BYOD Gateway. The first request for the site info is answered with a 401 HTTP status code indicating the need for user credentials for this information.
Type of connection | User | Time/Date of request | Type of request | HTTP Status Code - Size of response | Type of client
IP address/relay - username [05/Oct/2011:13:03:05] "GET /siteinfo/ HTTP/1.0" 200 945 "" "Chromis/1.9.2 (CL 3; iPhone 4.2)"
The client answers the 401 challenge by sending the request for siteinfo along with the username and password. If the credentials are validated by the BYOD Gateway a 200 status code indicating success is returned. The second number, 945, indicates the size of the information returned in answer to the request. If the credentials are not valid a 401 status code is returned. If the credentials are valid but not approved a 403 status is returned.
If you do not see the request for siteinfo in your portal-access.log then make sure the user has the correct access code for your BYOD Gateway.
If you do not see a 200 status returned for /siteinfo/ then make sure the username and password are correct and that the device being used is approved in the "Devices" tab of the BYOD Gateway Control Panel.
Client requesting a menu item from the BYOD Gateway:
Type of connection | User | Time/Date of request | Type of request | HTTP Status Code - size of response | Type of client
IP address/relay - username [05/Oct/2011:22:43:37] "GET /node/1/ HTTP/1.0" 200 175 "" "Chromis/1.9.2 (CL 3; iPhone 4.2)"
In this example the client is requesting the root menu defined on the BYOD Gateway. The root menu is located at node/1. The node # for each menu defined on the BYOD Gateway is shown in the address bar when you select the item in the BYOD Gateway Console. Each request for a BYOD Gateway menu item will be shown by its node #.
Panel-access.log - This file logs information every time an admin uses the BYOD Gateway Management Console. The log file is archived once a week.
Proxy-access.log - This file logs information retrieved from Intranet sites accessed through the Intranet Tunnel connector. The log file is archived once a week.
If you are having any problems accessing a site using the Intranet Tunnel add the following line to the BYODGateway.ini file to log the most informaiton about the problem.
[logging]
byod.proxy = DEBUG
Note: Be careful making any changes to the BYODGateway.ini file. The information included in this file is used to connect to the relay service. It is recommended to make a copy of the file before making any changes in case you need to reset to default values. The changes take effect when you restart the BYOD Gateway.
APPLIES TO
Kaseya BYOD Suite