GUMS Logs

GUMS is designed with 3 logs in mind: developer's log, administrator's log, site security log. This means that you won't find the same things in all of them, and you shouldn't. For example, say that GUMS connects to a VO server to retrieve a list of users, and the VO server replies with an empty list. From the developer's perspective the code has worked fine; but from an administrator's perspective it's probably the sign that something not going well.

The logs come with a predefined configuration, which is what we describe here. To know more of the details, especially how to change the configuration, refer to the logging implementation.

Administrator's log (gums-service-admin.log)

This log is meant for the maintainer of GUMS at a particular site. He is responsible of installing and configuring GUMS. To manage the mapping by keeping all the information up-to-date.

The log is placed under the Tomcat log directory and is called gums-service-admin.log. The log can also be configured to be forwarded by mail in case of error. This is particularly useful as the admins can be informed right away of any problem. Look at the log4j.properties configuration file.

The log includes every command that is being executed by any admins. This allow the administrator to keep full control of what is happening, together with a history of what has happened to be able to troubleshoot automatic procedures. The main features are:

  • All successful commands are logged as INFO with both input and output parameters
  • All unsuccessful commands (including failure do to authorization) are logged as ERROR

Developer's log

The developer log is meant for someone developing the code or fixing bugs.

The log is located under the service directory (/opt/gums-service/logs/gums-developer.log).

Site security log

The site security log is meant for the cybersecurity department of a lab. It includes all the information for auditing the GUMS service. This information will be limited to accesses to the service that are going to modify the state of the service. All the access to the information will be typically already be logged at the gatekeeper.

The log can be configured to be forwarded to the AUTHPRIV facility of syslogd. To enable logging to the syslogd deamon, you have to modify the log4j.properties and make sure it allows logging from the network. To enable logging from the network, you need to start syslogd with -r option.

[root@atlasgrid13 log]# cat /etc/sysconfig/syslog
# Options to syslogd
# -m 0 disables 'MARK' messages.
# -r enables logging from remote machines
# -x disables DNS lookups on messages recieved with -r
# See syslogd(8) for more details
SYSLOGD_OPTIONS="-r -m 0"
# Options to klogd
# -2 prints all kernel oops messages twice; once for klogd to decode, and
#    once for processing with 'ksymoops'
# -x disables all klogd processing of oops messages entirely
# See klogd(8) for more details
KLOGD_OPTIONS="-x"

The reason is that Apache log4j SyslogAdapter can only log through the network (to allow portability), even if you are logging to the localhost.

Another possibility is to log directly to a remote server: you can do that by modifying the log4j.properties configuration file in the service.