DICE development projects - 3_Implementation

Prometheus: multiple identities

toby — Tue, 06 May 2014 07:34:17 +0000

Project ID:

305

Current stage:

3_Implementation

Assigned Priority:

Manager:

toby

Unit:

inf-unit

Summary:

Add support and tools to Prometheus for managing multiple identities

What:

Prometheus was designed to support the management of multiple identities for users, e.g. in the KDC case somebody/admin, somebody/cron. The various parts need to be tied together to implement this. It should be possible to support:

Creation of additional identities for any entity
Creation of account objects (e.g. AFS pts) for identities
Users creating additional identities (of form 'user/something' themselves)
Distribution of keytabs

Why:

Multiple identities gives a way of separating a user's privileges. Also it allows for automation of authenticated access to resources (e.g. an identity with an AFS account and keytab allows authenticated file system access to be automated).

When:

This work has already been started, as part of prometheus development. This project ties all the loose ends together.

How:

Adding multiple identities support to prometheus involves the following work:

Ensure multiple identity and account objects are supported as planned in prometheus
Add support to AFS PTS conduit to create new accounts (with uid automatically allocated from range)
Add support to command-line 'theogony' tool to allow sysadmins to create identities and accounts
Add support to prometheus remctl interface for identity/account creation
Adapt password setting CGI or write a new one to use remctl interface for users to manage identities (create, set password)
Configure wallet to support distribution of keytabs for additional identities

Effort estimate:

4 weeks

Other:

Dependencies:

Risks:

AT 6/7/8 decant to somewhere

gdmr — Thu, 13 Mar 2014 10:32:26 +0000

Project ID:

304

Current stage:

3_Implementation

Manager:

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:

gdmr

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:

Local Forum Service

alisond — Fri, 17 Jan 2014 14:16:35 +0000

Project ID:

299

Current stage:

3_Implementation

Manager:

alisond

Unit:

us-unit

Summary:

To run a lightweight Forum to replace the Forum software which will be deprecated by IS.

What:

Paul is looking into the IS-provided alternatives (Learn & Confluence). His impression at the moment is that Learn (for example) might technically meet the functional requirements, but it comes surrounded by a lot of Learn baggage, and is sufficiently clunky that it would be a significant drop in usability which would discourage the student use that he is attempting to encourage. Paul currently hosts his IJP course pages on our ease.homepages service.

His requirements for this would be:
- clean and simple to use
- authenticates to EASE and available to anyone with an EASE account
- simple api for adding/removing users from groups
- ability to register for email notifications

Still to gather requirements from Austin Tate.

Why:

Proposed by Paul Anderson but Austin Tate also has an interest. Should be of wider interest too.

When:

in production before July 2014 (for use with pre-arrival students)

How:

DIscuss requirements with Paul Anderson
Discuss requirements with Austin Tate
Produce interim report outlining possible solutions
Select most viable solution
Provide a test installation
- Install a DICE virtual machine
- Include authentication mechanism (EASE?). Some content will be restricted and some may be suitable for public view.
- Mirror the service - similar to computing.help
- Standard backup using TiBS
- Obtain SSL certificate

Effort estimate:

4 weeks

Other:

Dependencies:

Risks:

LCFG SL7 port (inf level)

ascobie — Wed, 27 Nov 2013 10:15:43 +0000

Project ID:

296

Current stage:

3_Implementation

Assigned Priority:

Manager:

ascobie

Unit:

mp-unit

Summary:

Develop LCFG inf level support for Scientific Linux 7 (SL7)

What:

Develop Inf level support for Scientific Linux 7 (SL7) targetting the desktop and server environments the x86_64 cpu architecture. This work will form the basis for the next DICE desktop and server platforms.

This will utilise DICE authentication/authorization and name services in client mode (no local services). AFS home directories will be supported. This will also create an SL7 platform at the LCFG level which can be utilised by groups which are external to Informatics.

Why:

The current DICE platform, Scientific Linux 6, was released in 2011 and is showing its age in terms of software component versions. It is important, from both teaching and research perspectives, that we keep the platform up-to-date so that recent versions of software can be used.

When:

We are dependent on RHEL released RHEL 7. As soon as RHEL 7 beta is released (expected early 2014 Q1) we should start work. Experience has shown that we need at least 4-5 months to port the DICE desktop to a new platform. If RHEL 7 beta does not ship by early March, it is unlikely that we will be able to complete the DICE desktop in time for deployment before start of academic year 2014/2015.

How:

See SL7 port home

Effort estimate:

10w

IGS Misc Development

timc — Tue, 03 Sep 2013 08:15:39 +0000

Project ID:

293

Current stage:

3_Implementation

Manager:

timc

Unit:

rat-unit

Summary:

Process the operational tasks requiring small development effort arising out of the live Theon deployment. Tasks are individually identified in Trac.

Why:

Live use of Theon continuously identifies issues and enhancements for the IGS that are generally queued due to other work. Completing these assist the IGS in using the administrative processes now driven from Theon. Each issue is however always assessed for cost/benefit on a case by case basis.

When:

Due to the Trac being a live system with new tickets going in all the time there can be no explicit effort calculated, instead an effort budget should be allocated and tickets addressed one by one until the budget is used up.

How:

In constant contact ISS to identify prioritisation of tasks. Work on each task in priority order until the allocated effort budget is expired.

Final report URL:

https://svn.theon.inf.ed.ac.uk/trac/milestone/Consolidation%20of%20Research%2...

Other:

Dependencies:

Risks:

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)

LCFG client - remove obsolete module dependencies

ascobie — Mon, 25 Mar 2013 14:10:58 +0000

Project ID:

274

Current stage:

3_Implementation

Unit:

mp-unit

Summary:

LCFG client - remove dependency on obsolete modules (eg W3C::SAX)

What:

The current LCFG client depends on a number of obsolete Perl modules (eg W3C::SAX). This project will replace these modules with more modern, supported equivalents (libxml2 based XML::LibXML).

The plan is to take the opportunity to create a new object-oriented API for accessing the profile/component/resource and packages information for an LCFG client profile. Initially the API will only be used for the rdxprof client process reading the XML profile but it will be designed in such a way that we can support multiple source file formats (e.g. the DBM file, a switch to SQLite or a new improved XML format). The aim is also that it should be possible to use this framework to store the information into multiple target file formats. In the longer term all the other LCFG client libraries could be converted to using this framework to avoid the current code duplication which prevents us from fully modernising the client-side code (particularly the components).

Why:

The W3C::SAX obsolete modules aren't in use anywhere else and we have to port them for each platform upgrade. There's a real risk that they won't port to the next platform upgrade, which may cause problematic delays.

How:

Work out the best way to parse the LCFG XML structure using the XML::LibXML Perl module (3 days)
Design an object-oriented API for the component/lcfg/packages data gathered when parsing the XML (4 days)
Create a test suite for the new API (2 days)
Document the new API (1 day)
Rework the LCFG client modules to use the new API when parsing the XML and generating the DBM and rpmcfg files (5 days)

Effort estimate:

2-3 weeks

Other:

Dependencies:

Risks:

Deploy Git and Gerrit as full services

cms — Tue, 05 Feb 2013 10:54:57 +0000

Project ID:

272

Current stage:

3_Implementation

Assigned Priority:

Manager:

cms

Unit:

services-unit

Summary:

The School has been running a Git and Gerrit not-a-service for several years now. This project will upgrade Git and Gerrit to full services

What:

Set up new virtual server for Git/Gerrit
produce header files to allow Git/Gerrit servers to be easily set up
ensure that service data is being backed up
update documentation and helper programs

Why:

Git and Gerrit have seen a reasonable take-up by the School since the introduction of the not-a-service. It is being used to manage the Prometheus project, and has also been used for coursework group practicals in the past. Given the need to update the server on which the service is running to SL6, It makes sense to promote the service to a full service now.

How:

build obtain necessary RPMS
create header file to install RPMS, generate certificates and configure gerrit web interface
Build new virtual server
Install latest versions of Git/Gerrit on new server
Move data from not-a-service to new server
Test compare data for discrepancies
port/update helper/support programs
Set up mirrors/database dumps
Determine best way of configuring gerrit automatically.
deploy new service

Effort estimate:

In total the project should take around 2 man-weeks

Other:

Dependencies:
postgresql, apacheconf, cosign infrastructure

Risks:

Software Download Portal/Repository: Stage 1

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

Project ID:

258

Current stage:

3_Implementation

Manager:

roger

Unit:

services-unit

What:

Description: Requirements gathering for the implementation of a new Software Download Management Platform that would enable the distribution of research software and applications more effectively than the existing Informatics Software Download Database (ISDD).

Deliverables: A report examining the current state of ISDD, and a list of the perceived short-comings (real or imaginary) of ISDD (and whether they could be fixed). A description of the functionality required by a new Software Download Management Platform.

Why:

Customer: Edinburgh Research & Innovation, and all Informatics Research Staff (especially David Richardson, Dave Robertson, Bob Fisher)

Case statement: The UK Research Council’s focus on impact is changing the way we think about our research output. Impact features heavily in the upcoming Research Excellence Framework (REF) and we need to ensure we are capturing as much supporting evidence as possible.

The Informatics Software Download Database (ISDD) has been in existence for many years and is currently home to a number of legacy projects, but is perceived as being rather long in the tooth.

There is a confirmed expectation from the Scottish Government that the University takes active steps to simplify the process for companies to take advantage of freely available intellectual property, in parallel with commercial licensing activities. The proposed portal for open source technology will allow the School to lead the way in this initiative, working with Edinburgh Research and Innovation (ERI) and the collaborative University Technology project.

When:

Status: Final Report available on the DICE wiki.

Timescales: estimated half a week.

Priority:

Time:

How:

Proposal: We need to know what users actually want, and whether the existing ISDD could be reasonably modified to provide that functionality - and if not, what would be required of a new Software Download Management Platform.

Resources:

Plan:

Establish current and prospective user base.
Investigate IS data share, and assess possible use/relevance.
Examine the current state of ISDD, and list any perceived short-comings (real or imaginary) reported by the user base.
Investigate whether any deficiencies (if found) could be be corrected, and viability/feasibility of same.
Assess additional requirements not provided by ISDD
Enumerate functional requirements of a new Software Download Management Platform (to include existing and requested functionality).
Solicit user feedback and refine requirements list.
Prepare final requirements list.

Other:

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description