Admin Notes for Log Cabin

The log cabin service is configured via the dice/options/cabin.h header, to allow testing and use of the software without the need to install and configure all the apache stuff the packages and dependencies are added via the dice/options/cabin-packages.h header.

The cabin service is currently hosted on the VM named beaver.

SSL Certificates

If the DICE_OPTIONS_CABIN_COMODO CPP macro is enabled then this site uses an SSL certificate provided by comodo which is manually installed. The various files for the certificate are stored in the /etc/pki/tls/certs/cabin-certs directory. If reinstalling the machine we will need to copy them over. If the machine is lost then speak to Inf Unit about retrieving copies.

Local subnet Information

Information on the Informatics subnets is gathered from the live/subnets.h header which is maintained by the Inf Unit.

Information on the edlan subnets is hardwired in the dice/options/cabin-packages.h header. This information will need to be updated occasionally. The list was taken from the IS Network Section of IT Infrastructure Division Useful Information page

Host Alias Information

The cabin web interface uses a local file to hold a mapping between hostname and alias. In the web interface the user will then see their login as going to the alias not the real hostname. Rather than using DNS, it is done in this manner to control which aliases we do (or do not) display. It also helps to avoid a dependency on DNS (and thus a need to frequently do lots of expensive lookups). An alias can be any string, it doesn't have to be what we have configured in DNS. There can be multiple aliases listed for each host (e.g. kubelik is both ssh.inf.ed.ac.uk and student.ssh.inf.ed.ac.uk). Since we don't know through which route a user has accessed the machine we need to display them all, they will be shown as a comma-separated list in the login events listings.

This information is store in a file (/etc/cabin/host_aliases.txt) on the host. It is managed using the file component in the dice/options/cabin-packages.h header. Note that when changes are made to this file they will not take effect until apache has been restarted.

When updating host information it is a good idea to keep the information for the old host until it is no longer relevant (e.g. it is 120 days since that machine was in service). For instance, when ssh.inf was moved from dunlin to kubelik we still wanted login entries for the old host to appear as ssh.inf.

Note that this is only really relevant for SSH logins. Cosign logins already have the web service name stored rather than the name of the physical host. This means that it is most appropriate for services such as login, compute, CVS, SVN, git.

Geo-Location Information

To show location information for each login source address we use the freely available geo-location data from maxmind.com. The data is updated on the first Tuesday of each month. We use the "GeoLite City" gzipped binary data (GeoLiteCity.dat.gz), this is packaged in a local RPM named GeoIP-LiteCity which is restricted to distribution within UoE. The version number should be based on the date of release (e.g. the first Tuesday of June 2013 is 20130604). When a new package is installed on the cabin server the apache daemon will have to be restarted for the changes to take effect.

Checking user data

If a user reports unusual activity for their account you can find out more by querying the database directly, for example:

ssh loghost
psql96 -d buzzsaw -h copernicus -U logfiles_reader

psql96 (9.6.15, server 9.6.12)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

buzzsaw=> select * from event where userid = 'squinney' order by logtime desc;

The raw message might give enough extra information to make it clear what happened. For web services you can also check the logs on the local machine (the message would contain something like cosign-www.inf.ed.ac.uk), that can tell you what pages were accessed, what browser/OS were used, might be enough to jog the user's memory.

-- StephenQuinney - 13 Jun 2013