BIRCH currently has a fairly simple method
for logging usage. If the environment varialbe $BIRCH_LOGGING is set to
1, messages listing the userid and a date stamp will be written to
local/admin/logins.log every time a BIRCH user logs in, and to gde.log
each time a BIRCH user starts GDE. If $BIRCH_LOGGING=0, messages are
not written. This is the default.
To log or not to log
Logging will not work
if the BIRCH filesystem is mounted read-only. If the filesystem
containing BIRCH mounted read-only to other workstations, logging will
not work, and setting BIRCH_LOGGING to 1 may prevent users from logging
in! logins.log and gde.log have the permissions rw-rw-rw-, meaning that
they are world-writeable. However, on a read-only filesystem,
Privacy/security
considerations. Since logins.log and gde.log must be
world-readable, anyone with login access to the system could read these
files. In practice, they reveal no information other than the userid
and time of login for users, so their potential usefulness for illicit
purposes is dubious.
Turning on logging
Once again: do
not turn on logging unless the BIRCH filesystem is mounted read-write
to all workstations/servers!
That being said, uncomment the following lines
local.cshrc.source
local.profile.source
#
setenv BIRCH_LOGGING 1
#BIRCH_LOGGING=1 #export
BIRCH_LOGGING
Collating the logging data
So far, there is only a crude method for collating the data. To find
out the number of BIRCH users recorded in logins.log, go to the
local/admin directory and type:
{mira:/home/psgendb/local/admin}birchstats
logins.log Number of
logins: 18128 logins.log Number of
users: 109
The number of logins is the total number of times anyone has logged in.
The number of users is the number of unique userids found in logins.log.
Similarly, to find the number of users of GDE,
{mira:/home/psgendb/local/admin}birchstats
gde.log Number of
logins: 3816 gde.log Number of
users: 65
Obviously, this mechanism could be a bit more sophisticated.
The right way to do this
There are a number of remote method protocols that would provide
a more secure logging mechanism, and that would probably get around the
need to mount the BIRCH filesystem read-write. The big problem with
these approaches, aside from their complexity, is that they place more
demands upon the BIRCH Administrator to know how to implement them, and
make more assumptions about the system being used. For now, this
mechanism will have to suffice.
