The presentation shared experiences of implementing RAPTOR at Newcastle University as part of the JISC funded RAPID project. Discussions included:
- the areas of reporting we hoped to improve including Application and IT Cluster room usage
- how we approached these areas
- an overview of the technical implementation of RAPTOR
- the benefits that have been realised since the end of the RAPID project.
2. The problem with log analysis…
Use cases for better log analysis
The RAPTOR tool
Implementation @ Newcastle
Findings/outcomes of project
Recommendations for future work
Questions, and links to resources
3. Logs look weird!
Hard to establish patterns
Graphs provide a quick summary
Information not always available in one place
Management/decision makers often don’t have
access to logs…
6. Shibboleth
◦ Log files are kept but not utilised to produce
management info
◦ Previous work to try and produce this information was
laborious
◦ Number of unique authentications, grouped by school,
affiliation
EZProxy
◦ New service, to be able to justify the purchase and
implementation of the service
◦ Ensure that users are aware of service, may still use old
clunky methods to access
Grouper
◦ Guide the development of applications, measure the
growth of an application
7. RAPTOR - http://iam.cf.ac.uk/trac/RAPTOR/
Almost real-time graphing
Historical trends
Attribute association
Built in support for Shibboleth/EZProxy
Extendable
8.
9. MySQL over PostgreSQL – separate VM to MUA/web app
Fronted web application with Apache/SSL
Installed ICA on EZProxy, Shibboleth IdP and, now,
Shibboleth SP
10.
11.
12. Start off using small scale applications
Separate out the database component
Have an “attribute” database handy
Better documentation
Community driven -
http://iam.cf.ac.uk/trac/RAPTOR/wiki/TechnicalInfo/Community