DICE development projects - gdmr

Unit:

compexec

Summary:

Pseudo-project to track effort going to the decant from AT 6/7/8 to somewhere

What:

We're going to be decanting out of AT 6/7/8 to somewhere as-yet-unspecified in 2015. This project is a procedural thing to allow us to track effort.

Why:

AT recladding will happen, which requires us to move out for the duration.

Other:

Dependencies:

Risks:

AT 3/4/5 decant to Forrest Hill

gdmr — Thu, 13 Mar 2014 10:30:41 +0000

Project ID:

303

Current stage:

3_Implementation

Manager:

Unit:

compexec

Summary:

Pseudo-project to track effort going to the decant from AT 3/4/5 to Forrest Hill

What:

We're going to be decanting out of AT 3/4/5 to Forrest Hill in 2015. This project is a procedural thing to allow us to track effort.

Why:

AT recladding will happen, which requires us to move out for the duration.

Other:

Dependencies:

Risks:

Investigate alternatives to our existing MIT kerberos authentication infrastruct

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

Project ID:

260

Current stage:

3_Implementation

Manager:

Unit:

What:

Description: Investigate the possibility of moving our KDC (and KCA) infrastructure from MIT kerberos to heimdal, and the implications thereof. Investigate the alternative possibility of outsourcing it to EASE.

Deliverables:

Produce a report on the pros and cons of sticking with MIT kerberos or migrating to heimdal, and on the pros and cons of outsourcing to EASE.

Make recommedations as to how we should proceed, and when we should next review the situation.

(Any actual migration would be done as a separate project.)

Why:

Customer: All

Case statement:

We adopted MIT kerberos by default when the DICE project started. heimdal is now definitely a viable alternative, and is being taken up by a number of large sites and distributions. We should take a proper look and make an informed decision rather than just carrying on blindly.

The alternative suggestion of outsourcing to EASE has also been made. On previous occasions we and IS have concluded that this wouldn't be a good idea, but as we haven't looked recently we should consider this option if we are reviewing our authentication infrastructure anyway.

When:

Status: To be added to the 2013T1 bundle.

Timescales: It should be possible to investigate and report within a T.

Priority:

Time: Estimate a couple of weeks to get sufficiently to grips with Heimdal and to work through the implications.

How:

Proposal: Investigate. Report.

Resources: If we migrated to heimdal we would expect to run on existing KDC hardware (or planned replacements). If we outsourced to EASE there might be resource implications which can't be specified at the outset but which would be reported on as part of the project.

Plan: Other large sites have migrated, so it should be possible to tap into existing tools and experience.

Other:

Dependencies:

Risks: Breaking authentication!

Milestones

Proposed date	Achieved date	Name	Description

Multicast routing

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

Project ID:

255

Current stage:

0_Pending

Manager:

Unit:

What:

Description: Investigate and possibly implement multicast routing on our edge routers.

Deliverables: A report in the first instance. Depending on what it finds, access to external multicast streams

Why:

Customer: All

Case statement: Although our core routers are (apparently) capable of multicast support, our edge routers currently don't implement any multicast routing. As a result, Informatics users have no access to external multicast streams.

When:

Status:

Timescales:

Priority:

Time: A week to work out what's possible. Another 2-3 weeks to implement it.

How:

Proposal:

Resources: Ideally this would be implemented on one or other of the inf-unit's existing network servers.

Plan:

Other:

Dependencies: May require us to upgrade the firmware in the core routers (though we should really be doing that anyway!).

Risks: It's important that anything which this project produces doesn't destabilise the existing production network.

Milestones

Proposed date	Achieved date	Name	Description

Documentation update - infrastructure unit

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

Project ID:

250

Current stage:

Manager:

Unit:

https://wiki.inf.ed.ac.uk/DICE/FinalProjectReport250

What:

Description: Review and update end-user documentation. Includes porting across any remaining documentation not already on new drupal based site.

Deliverables:

Why:

Customer:

Case statement:

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal:

Resources: 2 weeks effort

Plan:

Final report URL:

Other:

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description

KDC upgrade to 1.9

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

Project ID:

223

Current stage:

Manager:

Unit:

What:

Description: Test kerberos version 1.9.x KDCs. Add any additional configuration hooks required. Upgrade the INF and IFRIEND KDCs.

Deliverables: Version 1.9.x KDCs. Ideally add password strength checks.

Why:

Customer: All

Case statement: There are two drivers for this:

The version of kerberos that comes with SL6 is 1.9.something, so we would have to do this work anyway
We would like to use the additional "pwqual" plugin to enhance our password strength checks

When:

Status:

Timescales: Best to allow three weeks for thorough testing, master-side in particular.

Priority: Required as part of the inf-unit's SL6 upgrade path.

Time:

How:

Proposal:

Resources:

Plan: Slave-side should be reasonably straightforward. Master-side will require a test realm to be set up. Phasing into service should be done cautiously.

Other:

Dependencies: This project doesn't depend on anything else. Lots of things do depend on it.

Risks: We have to make this work if we are to be able to upgrade the KDCs to SL6. OTOH there's no reason to expect that there'll be any real problem. However, BEWARE of breaking AFS, as it still requires single-DES keys.

URL: http://www.dice.inf.ed.ac.uk/units/infrastructure/Projects/168-PWstrengt...

Milestones

Proposed date	Achieved date	Name	Description

Full-service jabber

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

Project ID:

221

Current stage:

0_Pending

Manager:

Unit:

What:

Description: Our current jabber not-a-service has a few rough edges. Bring it up to scratch.

Deliverables: A proper jabber service

Why:

Customer: COs at least; nagios

Case statement: Our existing jabber not-a-service has quite a few rough edges. The Operational meeting of 28th September 2011 decided that doing it properly would be well worth it. The IS-run not-really-a-service was felt to be not suitable.

When:

Status: The Operational meeting of 28th September liked the idea of doing jabber properly.

Timescales: Estimate a week to evaluate the options and produce a report; then probably another couple of weeks to implement it.

Priority:

Time:

How:

Proposal:

Resources: The existing non-service runs piggy-back on one of the nagios machines. This is unsatisfactory for several reasons, and would be unsustainable for a full jabber service. A new server will therefore be required.

Plan:

Evaluation: the existing code is in need of an upgrade, so before we do anything else we should look to see whether it's still the best codebase, and if so whether there's a newer version out.
Produce a report:
- Service must be production quality
- nagios messaging required
- Web access to logs highly desirable (note that this may interact with nagios, if co-hosted)
- Log access must track chatroom access
- Ideally controlled from a prometheus conduit??
- It would be good to get the web interface to jabber (see "iTalk" on the not-a-service page) working again
- Should be available to whole School in a way which can be easily managed
Implementation: assuming approval, implement a service based on the recommendations of the report.

Other:

Dependencies: The "cos" chatroom is well used. nagios notifications initially come via jabber; indeed, this was a motivation for the current not-a-service.

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Database-driven network configuration - feasibility study

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

Project ID:

212

Current stage:

0_Pending

Manager:

Unit:

What:

Description: It has been suggested that some of the network configuration could be driven from the database, so allowing the admin staff to set up ports indirectly for users as they move around the Forum. This project is to determine how feasible and cost-effective that would be.

Deliverables: Feasibility study, to include at least a description of methods by which the two things could be hooked together, anticipated problems, work to be done, ... This project will definitely not result in any changes to the existing network configuration.

Why:

Customer: Admin and computing staff

Case statement: Per CEG of 27th April 2011, it would be nice to have some of the network configuration stuff more integrated with other sources of data, and in particular the School database. However, at the moment it's not entirely clear what would be involved. This project is to find out!

When:

Status: Created following a CEG discussion.

Timescales: Estimate 3-4 weeks of thinking, discussion and writing time.

Priority:

Time:

How:

Proposal:

Resources: Someone who knows their way around the network configuration. Discussion time with a database expert, Support and the techs. DevProj#33 produced a report on the network management mechanisms in use which might provide useful input.

Plan:

Other:

Dependencies: Probably lots.

Risks: At the moment the network configuration is held in one place on one server per site in the form of flat files under RCS control, with extensive mirroring between the network servers. We don't want to break that without good reason, as anything which complicates things has the potential to make it harder to recover from disasters.

Milestones

Proposed date	Achieved date	Name	Description

inf-unit work for SL6 server platform

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

Project ID:

201

Current stage:

Manager:

Unit:

http://www.dice.inf.ed.ac.uk/units/infrastructure/Projects/201-SL6-server/Fin...

What:

Description: This is a followon from #200, and covers all the inf-unit work required for a SL6 server (as opposed to desktop/development) platform that isn't explicitly covered by other projects.

Deliverables: SL6 server platform. Specifically upgrade inf-unit servers and services, and
provide service items for other units, as follows:

Network services
- Switch configuration
- Routing
- Edge filters
- DNS
- DHCP
- NTP
- OpenVPN
Console services
Authentication services
- Kerberos
- wallet
- kx509
- iFriend
- cosign
Authorisation services
- Roles and entitlements framework
Directory services
- OpenLDAP
Account management framework (prometheus)
Host monitoring service (nagios)
Chat service

Why:

Customer: All

Case statement: #200 only covers what's needed to get SL6 DICE up and running for development and desktops. As it's intended as a server platform too, this project is needed for the additional work that's not explicitly covered by other projects.

When:

Status:

Timescales: Variable. Some work can be left until we (inf-unit) need it for our own purposes. Some has to be done before other units can proceed with their own SL6 server platform work.

Priority: Necessary.

Time:

How:

Proposal:

Resources: All unit members are likely to be involved in some aspect or other of this project.

Plan:

Final report URL:

Other:

Dependencies: DevProj #200 is now complete and signed off.

Risks: If we don't do this work there won't be a SL6 server platform.

Milestones

Proposed date	Achieved date	Name	Description

inf-unit work for SL6 development/desktop platform

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

Project ID:

200

Current stage:

Manager:

Unit: