DICE development projects - neilb

Securing web servers

neilb — Thu, 22 Aug 2013 10:22:31 +0000

Project ID:

287

Current stage:

3_Implementation

Manager:

neilb

Unit:

services-unit

Summary:

See what we can do to limit the possibility of a web server being compromised, and if compromised, limit the damage that could be done.

What:

The MPU have taken steps to secure/harden the external facing ssh servers. Web servers are equally external facing and we should make sure they are as secure as they could be. And should they be compromised, limit what could be done from them.

Why:

A compromised web server could lead to:

reputational damage
theft of personal/private/restricted data
the possibility of hosting illegal material
our equipment being used in a crime, eg phishing/fraud.

When:

These possible threats are not new, but it's percived that there's a growing risk of damage being done. So sooner rather than later.

How:

Possible options

Making sure software is up-to-date with latest security fixes/patches
Separate web instances so if one is exploited, damage can be limited.
Tighter control over who can publish web content, CGIs or web apps
Remove superfluous software from servers
Limit what can be done from a web server, eg no SSH outbound. Local DNS only, block outbound DNS, close outbound firewall holes
Better monitoring, eg monitor network traffic

A longer list of possible options is listed on the "Report" wiki page.

In the first instance, we only need to be more secure than the next guy, so we'll probably look at the low hanging fruit (ie the easy to do) first.

It would be nice if we could come up with simple header files people could include to implement simple fixes. Unfortunately some fixes will depend greatly on the web service you are trying to harden.

Plan:

List possible steps to harden/secure sites - done
Prioritise list (probably do the easiest ones first) - draft order added to wiki page
Work through the list:
Either implement as a simple header and/or document what's required to
achieve an generic solution. Site owners will need to decide how to
implement/configure more specific solution for their site.
Inform site managers of new header/docs.
Move onto next in priority list.
Repeat until out of time.
Document project.

Effort estimate:

4 weeks

Final report URL:

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

Other:

Dependencies: network, security knowledge

Risks: see Why? section

The effort includes implementing any changes across the various managed web servers, there are 5 main ones: www.inf, groups.inf, wcms.inf, homepages/wiki.inf, aiai.ed. each may/will have different "superfluous" software.

What about other web (app) sites, eg rbs.inf, computing.help, ifile.inf, webprint.inf, pp.inf, lcfg.org etc

If we're going to limit the software on web servers hosting user generated content/CGIs, then how will users develop their content? Logon to the live service? (undesirable) Or will we need to maintain a second development version of the service which users can log into, but is not accessible outside of inf? (sounds more likely, at the expensive of maintaining more servers)

Use Central Lists Service to host Informatics Database Generated Mailing Lists

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

Project ID:

263

Current stage:

0_Pending

Manager:

neilb

Unit:

services-unit

What:

Description: The Informatics Database currently generates the list memberships for about 860 locally run mailman lists (out of a total of 1560 lists).
This project would implement hosting of those lists on the central IS, Sympa based lists service.

http://www.ed.ac.uk/schools-departments/information-services/services/computing/comms-and-collab/email/lists/sympa

Deliverables: A service similar to what we currently have, but hosted on the IS service.

Why:

Customer: Primarily Student Services, as they have the most DB generated lists, but also the School in general. Also the members of those lists.

Case statement: We have a requirement to move School services to Centrally provided equivalents where appropriate. It should also save us resources.

When:

Status: pending

Timescales: I suspect most time would be spend familiarising ourselves with Sympa's synchronising facilities, and whatever mechanism IS implement to allow automated list creation. Also on figuring out the criteria to produce the required list memberships in Prometheu

Priority:

Time: I would estimate it might only take 1 to 2 weeks to sort out the technical aspects of driving list creation and synchronising of list memberships.

A bigger unknown would be how long it would take to migrate the current conduit logic into Prometheus - if we decided to do it that way. There would be the basic "how we do it in Prometheus" - say 1 week for those with experience of Prometheus conduits. And then another week to actually migrate the logic for the lists?

So in all it could be 2 to 4 weeks work.

How:

Proposal:

Resources: Access to Prometheus and/or Informatics DB.

Plan:

Other:

Dependencies:

Currently there is no way to automate the creation of mailing lists on the sympa service at our end. IS are currently looking at providing this facility, but it is not there yet. Other Schools are requesting this, and it is something they are planning on providing, but it isn't there yet. Whatever they provide, we will have to produce the XML file that Sympa requires to create a list from the command line.
Once a list is created, sympa can currently manage a list membership from an external MySQL DB, web page, LDAP.
Conduit knowledge may be required if we were to use the DB to generate web pages, or other files containing lists of users to be synced to the lists.
Prometheus knowledge, as Sympa can sync lists directly from LDAP, then this would seem an obvious place to source the data.

Risks:

The address for all Sympa mailing lists is a flat mail space @mlist.is.ed.ac.uk. They have no plans to support virtual domains, eg @lists.inf.ed.ac.uk. It's a first come, first served policy for list names. So our lists could actually be called something like informatics-staff@mlist.is.ed.ac.uk, or inf-it-t02@mlist.is.ed.ac.uk. We'd have to setup forwards so that staff@inf or it-t02@inf are forwarded appropriately.
We'd want to check that the Sympa lists are aware of these aliases, and will accept the forward, they should. But are we bothered about the "clunky" real list names?
As I mentioned the lists names are allocated on a first come, first served basis, so there's nothing stopping someone else creating a list called inf-students-jobs@mlist.is and potentially being nothing to do with Informatics. And any list creation mechanism we create would need to take into account that list names it wants to create, may already be taken.
There isn't apparently a way to automatically add new members as a one time event. eg as we do for the seminars@inf list. We'd need to investigate if this is indeed true, or decide if we can live without it and have some work around.
Does sympa provide the functionality users are used to, if not (would seem unlikely), is it a show stopper?
If this goes ahead, what do we do with the remaining manually managed lists?

Milestones

Proposed date	Achieved date	Name	Description

Streaming Media Server

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

Project ID:

227

Current stage:

0_Pending

Manager:

neilb

Unit:

compexec

What:

Description: We already have media.inf.ed.ac.uk which is used to serve larger binary files (via HTTP). They are mostly images and videos that would otherwise go on www.inf.ed.ac.uk, but aren't really suited to CVS. The idea would be to extend this to provide an actual media streaming service.

Deliverables:

Media streaming via rstp:// at "a medium scale"
Large amount of storage for the media
Provide video at various standard formats, bit rates, etc from low bandwidth mobile to high bandwidth HD
A stable URL for HTTP downloads
Support for "real time event streaming at modest (workshop and on-line class) scale
(say 50 streams) using sdp announcements from live feeds from authorised users"

Why:

Customer: Informatics staff, students and visitors.

Case statement: Though there is a central, IS, provided service, which would continue to be used for larger scale events. Something smaller and simpler for use in-house would be useful.

When:

Status: Proposal

Timescales: estimate 3 weeks

Priority: unknown - low? there is the existing central service

Time:

How:

Proposal: Do a quick investigation to find out what streaming server software there is and the cost. If there's only a prohibitively expensive commercial solution, then this project probably won't get off the ground.

Resources:

Good network connectivity
Potentially large amount of storage
Person with expertise in streaming (and media preparation?)
Streaming server software
Hardware to capture/convert/stream live feeds?
Possibly server hardware if it can't co-exist on existing hardware, or can't be virtualised, for performance reasons.

Plan:

Investigate what streaming software is available, free and commercial
Investigate if pre-processing of video files is required, if so who's responsibility is it to do that. The author of the video or the manager of the service?
Produce test version of service and see how it performs with multiple streams etc.
Depending on the performance testing, scope if extra hardware is required to host service.
Should storage be SAN, networked, or local? Purchase as necessary.
Speak to people to see how they envisaging "live" feeds working. Would extra hardware be required?
Possibly limit the deliverables depending on costs.
Implement service as dictated by costs.

Other:

Dependencies: Storage, suitable streaming software.

Risks:

We end up spending time and effort on something that isn't used.
We produce something that is too popular and it doesn't scale to cope with demand.
On going support cost of ever increasing storage (and backups?)
Do we have the expertise in producing/converting media so it suitable to be streamed

Milestones

Proposed date	Achieved date	Name	Description

Course in a Box 2

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

Project ID:

209

Current stage:

4_Signoff

Manager:

neilb

Unit:

rat-unit

What:

Description: Auto generate course information from the database that we can do easily in advance of potentially using a VLE to do this.

Deliverables: A report from the School Database containing the information as itemised on the requirements document on a per-course basis. This can be used for further evaluation.

Why:

Customer: ITO

Case statement: The existing course information is sporadic and inconsistent. The database can produce most of what is required. In fact it does already but the existing presentation is incomplete and far from ideal. Even a cleaned up presentation of loosely the same information generated for each course would be an improvement and lightweight to implement.

When:

Status: Jumping straight to implementation. Need to get it done before term starts. Is a continuation of the work done in project 178.

Changed project leader from Roger to myself.

Submitted for sign off 5/1/2011 FinalProjectReport209

Timescales: Needed well before start of 2011 session.

Priority: It would be better than what we have but would not be a disaster to not have it.

Time: 2 FTE Weeks. This is an over-estimate but includes potential expertise learning curve and includes adding extra data not on currently generated reports.

Currently spent about 40 hours.

How:

Proposal:

Resources:

Plan: Get up to speed with what was actually requested agreed.
Knock up a draft web page for approval.
Write conduit to produce web pages.

Other:

Dependencies: Data in Theon. Move of data structures from 2G to 3G is supposed to happen in the same time frame and would need to be taken into consideration.

Risks:

URL: https://wiki.inf.ed.ac.uk/DICE/CourseInABoxTwoProject209

Milestones

Proposed date	Achieved date	Name	Description

Move of www.inf to new technology

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

Project ID:

158

Current stage:

5_Completed

Manager:

neilb

Unit:

services-unit

What:

Description: Project 93 – "Future Direction for the main Informatics web..." has gone beyond its original remit, which was to investigate possible routes we could go down to improve the current web site. This project retrospectively covers what actual steps have now already been taken following that initial investigation, and what still needs to be done.

Deliverables: * Robust infrastructure for content remaining within Informatics.

* For content on Polopoly we will need to maintain local technical documentation on what we are providing in the way of DB content that is being proxied to Polopoly.

* Assuming we make the switch of the first batch of content to Polopoly, we will provide information on the (no doubt) complicated redirects forwarding old URLs to new Polopoly content.

* For Polopoly content authors, local guidance on the basics of how it works (IS run proper training, and provide documentation and support).

* For Plone, local guides/training on how best to use the Institute In A Box web site template.

Why:

Customer: The School of Informatics.

Case statement: At the time project 93 was started (2008), the University Website
Project (to move all University pages to a new content management
system called Polopoly) was in its early stages, and was not (at that
time) suitable for our needs. There were a few technical things we
needed that it did not support. Project 8 had resulted in a commodity
Plone service for research groups, and project 97 had identified a
need for an Informatics "skin" to use in Plone. This skin was
developed as part of project 93 with a view to migrating www.inf to
it. Before we got to this point, project 93 should have been re-scoped
or stopped and new project(s) started to track the progress of the new
WCMS and any migration to Polopoly, this didn't happen.

What happened was that we continued developing the Institute In A
Box Theme for Plone, and recently (due to improvements in the Polopoly
system) have migrated about 100 pages of content (not yet live) to
Polopoly.

All this implementation has been recorded against project 93, which
has never officially gone past the "evaluation" stage. Hence the
decision to windup project 93, and instead track the actual work being
done again this new project, which would almost go straight to the
"implementation" stage.

When:

Status: Work that is already being done and assigned to project 93, would better be assigned to this project.

Timescales: Hope to have initial Informatics content in Polopoly within a few weeks to a month.

For the other parts - unknown at this time.

Priority: High.

Time: 4 weeks FTE (as a rough estimate)

How:

Proposal:

Resources: We already have one new web server hardware for the local WCMS. We may need another machine for off site redundancy.

Some amount of CO effort.

There has already been PhD effort used to migrating the initial www.inf content to Polopoly. Once that's complete it is expected that affected stake holders, eg Gradschool, will maintain/develop their content.

Plan: In this project we plan to record the work already done in transitioning Informatics web content to the new technology (both Plone and Polopoly). And what still needs to be done. For example we need help from the RAT unit to aid with generation of some new DB feeds that we can proxy into Polopoly.

As so much time has passed since we originally looked at moving to Polopoly (and ruling it out), the Polopoly service now meets some of our original requirements, and is more flexible that it once was. The UWP team are willing, and encourage, external collaboration to keep improving the service. Once we do go live with our initial content we’ll want to review how that went and if we (to make more use of central services), should continue to migrate more content.

Again going back to our choice of Plone, as so much time has passed, I think we should at least consider the option of supporting another WCMS. Last year I did a quick survey of what other schools around the University were using, there is a small clustering of Drupal and MySource Matrix users (which there wasn’t previously) and we are the only people using Plone. Within Informatics ourselves, some research people (AIAI) are running their own Drupal sites. For these reasons (and the steep learning curve that we’ve still to climbed for Plone), I think we should at least consider supporting another WCMS.

For ww.inf content that doesn’t move to Polopoly, we need to state where it will stay, and how that data will be managed, served, and made resilient against hardware failure. We have an outstanding action to detail our plans on off site duplication. This project would detail those plans.

Other:

Dependencies: Access to Informatics DB to produce the data we want to proxy into Polopoly, or give RAT unit details of what we need, and ask them to produce the conduits/data.

Support from UWP to give required access to Polopoly content providers

Risks: Currently we have started moving some www.inf content in to Plone, mainly ISS/IGS content. Should we decide that Polopoly is now suitable for this content, we will have to reimplement that content. There would not be a practical migration path to do things automatically from Plone (or probably any other WCMS) into Polopoly.

URL:https://wiki.inf.ed.ac.uk/DICE/Project158NewWwwInf

Milestones

Proposed date	Achieved date	Name	Description
2012-03-06	2010-12-30	gen 1.0	produce plan of action for the www.inf service, backups, off-site resilience. DR plan, live mirror produced and Dev. meeting informed. https://wiki.inf.ed.ac.uk/DICE/ServiceUnitWwwOffsiteDrPlan
2012-03-06	2011-01-30	gen 2.0	start to implement agreed www.inf resilience plans, and add further milestones to enumerate the various steps to complete. Not sure if things were "agreed", but DR plan published and implemented.
2010-09-21	2010-09-09	gen 3.0	check/discuss if we should reconsider Drupal/MySource Matrix to leverage local knowledge. Meeting arranged to make a final decision on the 9th of sept. Had this meeting and an subsquent one. Drupal looks likely, but we'll try it out on the Documentation web site/project before finally committing.
2012-03-27	2011-03-30	gen 4.0	Plone performance improvements. Not going to happen unless it becomes an issue, concentrate on Drupal.
2010-09-15	2010-06-30	gen 5.0	Investigate intermittent HTTPS mis-caching problems. This has started, and we believe it is an apache problem. An updated apache has been installed. Won't resolve this until we know if its made a difference. The new apache hasn't solved the problem. A new milestone, gen 5.1 to track the next attempt to solve.
2010-04-05	2010-03-19	pol 1.0	Decide on the final content for first phase of move to Polopoly
2010-04-29	2010-03-19	pol 2.0	Get that final content ready for previewing by stake holders.
2010-05-17	2010-03-19	pol 3.0	Any final tweaks/changes as a result of that preview.
2012-05-30	2010-12-19	pol 4.0	Stake holders need to agree their responsibilities for keeping their content up to date. Restart this process. Too much time has passed. We want to produce a list of fairly coarse top level-ish polopoly URLs and a have a name/unit against each one to indicate who's responsible for it. This is now listed on the project web page on the wiki.
2012-05-08	2010-12-30	plone 1.0	setup plone instance on current www.inf hardware (wafer). Proper headers and factored out plone-server.h. Will be live after next stable release.
2010-12-07	2010-12-30	plone 2.0	move iss, pgrguide, and probably institute sites to plone on wafer. Done, see http://www.inf.ed.ac.uk/student-services/
2012-03-26	2010-12-30	plone 3.0	Upgrade plone to latest version, improved Help Center and collage products. This is not likely to happen. Concentrating on Drupal. If it does, it will be part of the SL6 upgrade.
2012-05-07	2011-02-28	gen 2.8	complete agreed www.inf resilience plans
2010-06-01	2010-06-15	pol 4.5	Produce documention of what we've done for polop and how it works. At URL www.inf.ed.ac.uk/polop/, covers the technical stuff.
2010-05-27	2010-05-26	pol 5.0	First phase goes live, with redirects from www.inf to new location/content
2011-03-21	2010-12-01	gen 5.1	New apache didn't solve HTTPS miscaches. Some anecdotal evidence that the HTTPS wcms.inf.ed.ac.uk/zope/ URLs are not affected by the problem. Do some further investigation to try and pin point the cause. Turned out to be a bug in Zope, which they now know about https://bugs.launchpad.net/zope2/+bug/740831 the patch hasn't been applied, but setting threads=1 in the zope.conf also seems to have stopped the problem.
2010-11-24	2010-11-30	era 1.0	Add link to staff individual page with link to ERA, Publications Repository, publications. Probably do via a CGI to start with as proof of concept. Done, see http://www.inf.ed.ac.uk/people/staff/Alan_Bundy.html as an example.

Informatics Commercialisation Website

boss — Fri, 25 Jan 2013 15:45:49 +0000

Project ID:

Current stage:

5_Completed

Manager:

neilb

Unit:

services-unit

What:

Description: Zope/Plone development work for the Informatics Commercialization and Ventures web sites. Create/extend a number of Plone modules and page templates to support these web sites. Includes integration of the new skin from the Informatics Branding exercise. While this work is initially directed at the Informatics Commercialization and Ventures web sites only, it is intended to provide suitably re-branded page templates and supporting functionality for Informatics Institute and Research Project web sites.

Deliverables:

Integration of new Informatics skin into the WCMS Plone.
Provision of CSS page templates using the new Informatics skin for the Home page, Portfolio pages (for projects, spin-outs and start-ups), Technology Areas page, Calendar page, News page, Events page, Projects pages, Licesning pages and a general custom content page.
Support for Commercialisation staff who will be adding the content onto each page.
Cosign authenticated access control. Support for users with EASE accounts.
Provision of some kind of site search mechanism to search on keywords.
Plone News module appropriately integrated into the new Informatics skin and News web page template. The news module will be driven from a database which can be updated on a regular basis by the commercialization staff. The news module should allow administrative staff to add/edit/remove articles and publish them to the website. There should be an RSS feed so viewers can subscribe to our news releases. A list of most recent news summaries will be displayed along with a list of archived months. Viewers should be able to select an individual news article which will take them to a page displaying that individual news article.
Plone events calendar and registration module integrated into the new Informatics skin and Events web page template. The events module allows users to view all internal and external events that are of interest to Informatics Commercialization and Knowledge Transfer (with ICAL and VCAL support). The events page will enable administrative staff to post new types of events which are of interest to Informatics commercialization. Events may be internal or external. Provide an event subscription based system so that site visitors can register for events and also have the option of being notified of new events that are added to the calendar.
Plone Blog module appropriately integrated.
Plone Wiki module appropriately integrated.
Plone Forum module appropriately integrated. This module will provide an online forum system for discussions.
Plone Photo Gallery module appropriately integrated. This module will allow a user to create a photo or picture gallery on a page.
Plone Multimedia module appropriately integrated. This will provide the ability to embed video on a page with viewer, like YouTube.
Plone module to generate random content for the main page (eg. profile of a technology spin-out, recent news or event) appropriately integrated.
Plone module to display the technology licensing database from ERI appropriately integrated. This would require a feed of data from ERI that is cached in a Plone accessable database as a separate process. This will highlight all technology available for license. If we cannot get an ERI feed then we would have to maintain the local database manually - hence the module would need to allow administrative staff to manipulate licensed technology content.
Plone form for newsletter signup appropriately integrated. This allows a user to register name, company, address etc and to sign up for any newsletters.
Ability for viewer to email web page to another person. Provide a link on page templates for user to click on to do this.
Provide a "page not found" page when a URL is requested that does not exist - should include a link to click on to mail report about the missing page or bad link.

Why:

Customer:

Colin Adams - Director of Commercialisation
David Richardson - Senior Business Development Executive (Commercialisation)
Andrew Mitchell - Senior Business Development Executive (Ventures)

Case statement: The University rebranding will not roll down to Institute level in any reasonable timescale. External consultation has shown that the different individual Institute branding creates a confused image of Informatics to the external world. A new content management system is deemed necessary to replace the existing Informatics web site technology. The templates and functionality implemented in this project will go a long way towards the goal of providing a new Informatics web site and technology supporting Institutes, Research Projects and any Spin-Out or Start-up.

When:

Status: There's a lot of overlap with this and project 93, Future direction for the main Informatics web service, we will concentrate in making progress in project 93, and then come back to this as something more concrete has been produced for 93.

After checking with the customers, they were happy to draw a line under this project, and finish it as is. So the project is moving to sign off Feb 2010. The final report is available at https://wiki.inf.ed.ac.uk/DICE/FinalProjectReport-97

Timescales: While much work can proceed in parallel with the re-branding exercise, cannot be completed until integration with the new skin. Provisional completion date will be end of 2008 but is dependent on the timescales provided by the chosen re-branding company.

Priority: High.

Time: Not easy to estimate given our current lack of expertise in Plone module development. However, we will say 6 FTE weeks over 12 FTE weeks.

How:

Proposal: Roughly - setup a parallel Zope/Plone installation so work on modules and skins can be carried out without risk to the production WCMS. Try and find Plone modules that meet or almost meet required functionality and extend and integrate as necessary. Create suitable draft page templates in liaison with commercialization staff and skins provided from the re-branding company.

Resources: Work will largely be carried out by Iain under the Research & Teaching Unit. A machine to run a development Zope/Plone installation on.

Plan: See Proposal.

Other:

Dependencies: None of note.

Risks: A lot more Plone module devlopment is required than anticipated.
Zope/Plone may not be the right CMS for us (now or in the future).

Milestones

Proposed date	Achieved date	Name	Description
2008-10-23	2008-10-15	1 SetupDevServe	Setup a development server to test commercialisation plone site work.
	2009-10-01	2 ClarifyBuilti	See which builtins already meet the requirements for a deliverable.
	2009-10-01	3 EffortEstimat	Give an estimate to the effort required for each deliverable. Also state which deliverables, aren't, eg the EASE auth.
	2009-10-01	4 Prioritise	Prioritise the deliverables with customer.
	2009-10-01	5 Implementatio	Start implementing deliverables in agreed priority.
2009-04-07	2009-03-06	handoverdocs	Iain will produce relevant docs on progress so far for the next person to pickup from. Docs received and put on wiki at https://wiki.inf.ed.ac.uk/DICE/CommercialisationWebProject97
	2009-10-01	1.1 ReviewMiles	There is quite a bit of overlap with this project and the needs of project 93. So we will be concentrating on the web review/tech (proj 93), and once that is done/more progressed, will revise the milestones for this project. Milestones reviewed 1/9/09, later ones but back 3 months. Will need to revisit hist milestone again. This mileston is just a placeholder to remind us to see how proj 93 is doing.
	2010-02-24	signoff	Get this project accepted as done.

FC5 services

boss — Fri, 25 Jan 2013 15:45:31 +0000

Project ID:

Current stage:

5_Completed

Manager:

neilb

Unit:

services-unit

What:

Description: Coordinate and monitor the transition of all DICE FC3 based services to FC5. The actual responsibility of transitioning the services will lie with the Unit responsible for that service.

This is a subproject of the FC5Upgrade, see the bugzilla diagram for a break down of how the services are assigned to the Units.

Deliverables: Production quality services running on DICE FC5 servers.

Why:

Customer: All DICE users in some way or another.

Case statement: We need to upgrade to FC5 as part of the annual upgrade program which is needed to support new hardware. We also ease the management burden if all machines are running the same level of OS.

When:

Status: The transition of services to FC5 has begun, though little time has been spent

Updated FC5Upgrade Wiki page with links to outstanding FC5 Unit Bugs

We are down to our last two FC5 Services bugs. I believe they are probably done, but need the RAT unit to confirm this.

The project report is now online at https://wiki.inf.ed.ac.uk/view/DICE/FC5ServicesProjectReport

Timescales: Needs to be complete by EOL FC3, which is December 2006. However, for those services where the underlying OS is exposed to the users, they should be transitioned to FC5 as close to the beginning of the new semester, 18th September 2006.

Priority: High

Time: Guestimate 1 man year of effort.

How:

Proposal: Migrate all current services running on FC3 to FC5. With priority given to those where the users are exposed to the underlying OS, eg multiuser login machines, web servers. Not things like print or LDAP servers.

Resources: This is a large scale project and will require wide cross Unit resources. Mostly the Unit leader will be expected to progress their Unit's responsibilities, with the project manager recording their progress. Project manager requires good project management skills.

Plan:

Produce bugzilla list of services that need transitioned. Done, see Bug #2040, this produced some 60 services to be transitioned.
Produce list of machines that the existing services are running on, and a date for when it will be FC5'd. Possibly try to track progress automatically from LCFG resources.
Set a date by which if you are assigned an FC5 transition bug, you may not reassign it, ie it it becomes the owners responsibility to transition that service.
Request regular (weekly/fortnightly) reports from Unit leaders asking for progress, but more importantly, blockers that are out-with that Unit's control. Remind people to close their bugs as services transitioned.
Repeat 4 until to all services are FC5 and date

Other:

Dependencies: Base FC5 DICE platform, Bug #1943. Each service may/will have its own dependencies, these should be tracked in bugzilla.

Risks:

URL:https://wiki.inf.ed.ac.uk/DICE/FC5ServicesProject

Disruption to services while they are transitioned.
Loss of data.
Reputation of School due to prolonged disruption to externally available services, eg web services, repository services.

Milestones

Proposed date	Achieved date	Name	Description
2006-11-01	2006-09-13	Server List	Generate a list of DICE server hardware, and the OS they are currently running. This list is to be updated daily.
2006-11-16	2006-11-10	Fix transition	Get agreement that FC5 transition bugs my no longer be reassigned (outwith a Unit) beyond 10/11/2006. Had a Unit Heads meeting on 16th Nov, and this was agreed.
2006-11-16	2006-11-15	Unit Goals	A realistic statement from the Units about which services and servers will be FC5 by the end of the year, and conversely which will not. At a meeting of Unit Heads on the 16th, Nov. The a list of machines which would not be FC5'd by the year end was agreed. See https://wiki.inf.ed.ac.uk/DICE/FC5ProgressMeeting16112006
2007-06-05	2007-02-28	Stage3Complete	Stage 3 (implementation) should be complete by the end of the year. ie all services FC5'd
2007-09-03	2007-08-31	ProjectReport	Produce a report covering the experience gained/lessons learned during the transition of the services from FC3 to FC5. As agreed at the last dev meeting, just a brief couple of paras will do. Report now on line at https://wiki.inf.ed.ac.uk/view/DICE/FC5ServicesProjectReport