DICE development projects - idurkacz

Unit:

https://wiki.inf.ed.ac.uk/DICE/FinalProjectReport-279

Summary:

Examine the options for two-factor authentication.

What:

Stephen says: "It occurs to me that we should have project to examine the options for two-factor authentication. This could compare the methods of solving the problem (X509 versus OTP), and look at the various hardware devices available. It seems that some are very expensive but are likely to be much better supported, others will be really cheap but we would have to run extra services and potentially hack applications ourselves. I mentioned this to Alastair and he reckons this fits best as something led by the Inf Unit."

How:

Invite interested parties to specify more exactly what is required (and whether or not they have specific ideas on how any such things might be implemented.)
Synthesize possible requirements.
Depending on requirements, attempt to prototype something reasonable.

Final report URL:

Other:

Dependencies:

Risks:

OpenLDAP: DICE client configuration

boss — Fri, 25 Jan 2013 15:46:28 +0000

Project ID:

267

Current stage:

4_Signoff

Manager:

Unit:

https://wiki.inf.ed.ac.uk/DICE/FinalProjectReport-267

Summary:

Review of OpenLDAP DICE client configuration

What:

Description: Investigate the various options for the use of LDAP on our DICE client machines.

Deliverables: Report, with recommendations. Subsequent implementation if required.

Why:

Customer: All

Case statement:

The current configuration of OpenLDAP on our DICE client machines generally works well, but changes in OpenLDAP mean that it should now be reviewed:

Every DICE client runs its own LDAP server. There are historical reasons for that, but is it still necessary? Could we move to a more standard client-server model?
DICE clients use a locally developed pull synchronisation technology - slaprepl - for replication. It would probably be better to use more standard software for replication, if such exists and is reliable.
All clients replicate from the single LDAP master, and we sometimes see client-side replication failures. Replication could probably made more reliable by configuring client replication from our LDAP slaves rather than from the single master. In any case, such a change seems sensible for reasons of load-balancing and redundancy.
The current replication system has a latency of up to one hour on any client. It would be good to reduce that time.
Our possible use of features such as nslcd, nssov overlay, sssd, proxycaching, etc. should be investigated.

This project follows on from the stalled project 79.

When:

Status:

Timescales:

Priority:

Time: Four weeks

How:

Proposal:

Resources: OpenLDAP knowledge

Plan

Document the current state of OpenLDAP configuration on DICE clients, highlighting any problem areas.
Find out what alternative options are available to us.
Investigate options.
Produce report with recommendations.
Implement whatever is agreed as a result of the above.

Final report URL:

Other:

Dependencies:

Risks:

Changes implemented incorrectly have the potential to break every DICE client machine.

Milestones

Proposed date	Achieved date	Name	Description

Monitoring System: Passive reporting scripts

boss — Fri, 25 Jan 2013 15:46:24 +0000

Project ID:

244

Current stage:

Manager:

Unit:

What:

Description:

[Forked from Project 230 - Monitoring system enhancements]

The existing Nagios monitoring system provides an interface for passive monitoring, but the implementation of any such monitoring is a distinct matter from the Nagios monitoring system software itself.

Some passive monitoring has been implemented already, but it might benefit from being standardised (for example, with respect to the Kerberos principals used.) In addition, there is a need for passive monitoring of disk space usage.

This project will:

review the existing passive monitoring implementations;
standardise them as necessary; and
implement a disk space passive monitor.

Deliverables: As described above.

Why:

Customer: Informatics COs

Case statement: We need to monitor disk space usage, and we need to provide an agreed reference implementation for any future passive monitoring efforts.

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal:

Resources: Two weeks of CO effort

Plan:

Other:

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Monitoring System: Jabber and email interface development

boss — Fri, 25 Jan 2013 15:46:23 +0000

Project ID:

242

Current stage:

Manager:

Unit:

What:

Description:

[Forked from Project 230 - Monitoring system enhancements]

The existing Nagios monitoring system sends alerts via Jabber and email. The Jabber interface uses code which probably isn't 'production-standard', and which ought to be cleaned up, if possible, in order to avoid future problems.

Beyond that, it would be very convenient if Nagios alerts could be responded to via Jabber and email. Whether that's even possible, and how to actually achieve it if, requires investigation.

Deliverables:

A report describing what seems possible.
Implementation of something - depending on the conclusions of the report.

Why:

Customer: Informatics COs

Case statement:

The existing Nagios monitoring system (described in https://devproj.inf.ed.ac.uk/project/show/22, https://wiki.inf.ed.ac.uk/DICE/MonitoringProject, and http://www.dice.inf.ed.ac.uk/units/infrastructure/Documentation/Monitoring/) sends alerts to C(S)O's via email and Jabber.

It would be very convenient if these alerts could be responded to via the same mechanisms, rather than via the Nagios web interface.

This project is essentially independent of any other enhancements made to the Nagios system. It also requires separate expertise, and will require a significant effort. So it makes sense to fork it as a distinct project from
Project 250 - Monitoring system enhancements.

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal:

Resources: 8 weeks of CO effort

Plan:

Other:

Dependencies:

Without investigation, it isn't clear whether responses to Nagios via Jabber and email are actually possible. We need, for a start, to investigate how Nagios incidents and alerts are actually keyed within the Nagios system - if they are at all.

On the surface, responses via Jabber sound feasible, but responses via email raise the obvious problem of authentication.

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Monitoring System Rewrite

boss — Fri, 25 Jan 2013 15:46:23 +0000

Project ID:

241

Current stage:

Manager:

Unit:

What:

Description:

A rewrite of the existing Nagios monitoring system; the objective being a system which is easier to maintain and to extend.

Deliverables:

Why:

Customer: Informatics COs

Case statement:

This project proposes to reimplement the Nagios configuration part of the monitoring system in a lighter-weight and more standard way. The end objective is a system which is easier both to maintain, and to extend.

Some parts of the existing system - in particular the Jabber reporting interface, and the interface for passive Nagios reporting - will be retained.

When:

Status:

Timescales: 12 weeks of CO effort

Priority:

Time:

How:

Proposal: See https://wiki.inf.ed.ac.uk/DICE/ProposedNagiosRewrite for preliminary thoughts and ideas.

Resources:

Plan:

Other:

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Enhancement of wallet to support external X.509 certificates

boss — Fri, 25 Jan 2013 15:46:23 +0000

Project ID:

240

Current stage:

Manager:

Unit:

What:

Description:

Project 129 - Wallet Implementation provided a wallet system which supports SSH host keys and X.509 certificates.

Every DICE machine in Informatics now stores its SSH host keys in wallet, but X.509 certificates are not yet being stored there owing both to uncertainty about exactly what it is that we want to store, and the lack of easy-to-use documentation and interface software. This project aims to plug those gaps.

Deliverables:

Documentation which specifies exactly how X.509 certificates are to be handled in the Informatics wallet system.
Any interface s/w necessary as a result of point 1.
Any other corresponding enhancements to our wallet implementation as deemed necessary.

Why:

Customer: All COs, as well as anybody else within Informatics who has a requirement to safely store and restore X.509 certificates.

Case statement: As for the precursor Wallet Implementation project

When:

Status:

Timescales: Wallet itself is fairly well understood. There is effort required effort to get back up to speed with it, to figure out what our internal standards for X.509 certificates should be, and then to provide the necessary. Estimate 4 weeks.

Priority:

Time:

How:

Proposal:

Resources:

Plan:

Other:

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Review of Forum wireless installation

boss — Fri, 25 Jan 2013 15:46:22 +0000

Project ID:

233

Current stage:

4d_Dropped

Manager:

Unit:

What:

Description: We have a large deployment of Cisco wireless access points (WAPs) in the Forum, but we have had at least one complaint of unsatisfactory wireless service. For an 'optimal' - or at least an improved - service, it might be that we should move some of our existing WAPs, or else add to (or subtract from!) their number.

This isn't an easy thing to plan for or to test for but, now that we've had the existing installation running for a couple of years, now might be a good time for a review.

Deliverables: A report which provides definite suggestions for either changes to the deployment, or a recommendation to stick with the status quo.

Why:

Customer: All users of the Informatics Forum

Case statement: We have at least one report of bad wireless service; we know that power levels can vary from -60dBm just outside the door of an office to -80dBm at the rear of the same office; we know that many of our WAPs run at low power, having been throttled back by the controller on account of the measured signal strength of their neighbours; we know that Cisco recommends that the WAPs we're using should be ceiling-mounted rather than wall-mounted.

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal:

Resources:

Plan:

Other:

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Monitoring system enhancements

boss — Fri, 25 Jan 2013 15:46:21 +0000

Project ID:

230

Current stage:

Manager:

Unit:

What:

Description:

The School's existing Nagios framework was developed by Simon Wilkinson (see Project 22) and has now been in use for a couple of years. In the light of experience with the system, a number of enhancements are now desirable, including, for example:

The provision of generic passive monitoring scripts for things like disc space usage, RAID errors, etc.
More intelligent target IP address selection, (in the case of multi-homed targets.)
The provision of a dependancy/hierarchy mechanism to limit spurious alerts when, for example, a switch/router fails.
The provision of alerts via SMS text messaging.
Monitoring of the server room environments.

Deliverables:

Why:

Customer: The CO community

Case statement:

Any significant changes to the monitoring system will involve a considerable familiarisation effort; if that's to be done at all, then it makes good sense to do as much work as possible at the same time.

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal:

Resources:

Familiarisation: at least 2 weeks
Production of enhancements: at least 3 weeks, but the actual effort necessary will depend on both the results of initial evaluation of requirements, and the subsequent code familiarisation.

Plan:

Familiarisation with existing code base
Decide the set of desirable enhancements - and their relative priorities
Implement enhancements - to the degree that seems reasonable in the light of the code familiarisation

Other:

Dependencies:

This project follows on from the Monitoring system upgrade project: there would be no point now making enhancements to the Nagios v2 infrastructure.

The MPU is expected to provide a standard client-side facility to monitor RAID - see Project 134 - Server Hardware Interaction.

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Informatics chatroom service

boss — Fri, 25 Jan 2013 15:46:19 +0000

Project ID:

222

Current stage:

4d_Dropped

Manager:

Unit:

What:

Description:

THIS PROJECT RECORD WAS CREATED IN ERROR - SEE Devproj #221 INSTEAD

We currently provide the 'cos' chatroom, and other chatrooms, via an unofficial Jabber service described at https://www.not-a-service.inf.ed.ac.uk/services/jabber/dice-labs-jabber-service.

The COs operational meeting of 28th September 2011 concluded that the 'cos' chatroom service was too useful to give up, and that the central service provided by IS was not a suitable substitute - so we need to make the chatroom service official and permanent. In doing so, we should also cater for the requirements of all members of the School, where possible.

This project will investigate how to provide an official chatroom service. As a short-term aim it will also deal with the move of the current service to SL6.

Deliverables: A supported chatroom service.

Why:

Customer: The School of Informatics

Case statement:

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal:

Resources:

Plan:

Other:

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description

OpenLDAP 2.4 Upgrade

boss — Fri, 25 Jan 2013 15:46:11 +0000

Project ID:

181

Current stage:

5_Completed

Manager:

Unit: