DICE development projects - 4_Signoff

Options for two-factor authentication

gdmr — Thu, 04 Apr 2013 13:07:02 +0000

Project ID:

279

Current stage:

4_Signoff

Manager:

idurkacz

Unit:

inf-unit

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:

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

Other:

Dependencies:

Risks:

Display SAT info on AT foyer display screens

ascobie — Thu, 28 Mar 2013 10:46:04 +0000

Project ID:

278

Current stage:

4_Signoff

Manager:

iainr

Unit:

rat-unit

Summary:

Display SAT personal timetables on AT foyer display screens

What:

We are obliged to present an individual timetable for students from AY 2013/2014 onwards. Our plan is to present info from our RBS onto displays in the foyers in AT. This project will implement this info display

When:

Needs to be implemented for start of AY 2013/2014

How:

modify RBS:
Add course feed from theon
Add unique identifier to appropriate repeated bookings
Add scripts to import/export required data
add to theon
Incoming conduit to take feed from RBS
Marry groups assigned in theon with bookings in RBS
generate html to be published on AT Display screens

Final report URL:

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

Other:

Dependencies: I will have to lean heavily on Tim and Grahams Theonn knowledge and Neils knowledge of the RBS.

Risks: We may not get it done in time

Milestones

Proposed date	Achieved date	Name	Description
2009-06-18	2009-06-20	rbscourse	Add course feed to RBS development
2013-07-01	2013-06-14	rbskey	Add unique identifer to RBS entries
2013-07-14	2013-07-28	theonfeed	Add feed to import data from rbs into Theon
2013-08-07		theonsync	Sync data to active Theon tables
2013-08-14	2013-08-14	theoncode	Marry rbs bookings with Theon generated groups
2013-08-20		theonreport	Write report to generate html for AT screens and website
2013-08-24		test	Test deployment
2013-09-07		deploy	Final depolyment
2009-06-18	2013-06-20	rbscourse	Add course feed to RBS development

OpenLDAP: DICE client configuration

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

Project ID:

267

Current stage:

4_Signoff

Manager:

idurkacz

Unit:

inf-unit

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:

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

Other:

Dependencies:

Risks:

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

Milestones

Proposed date	Achieved date	Name	Description

Documentation update - services unit

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

Project ID:

247

Current stage:

4_Signoff

Manager:

cms

Unit:

services-unit

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:

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

Other:

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description

SL6 upgrade for Services Unit

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

Project ID:

219

Current stage:

4_Signoff

Manager:

cms

Unit:

services-unit

What:

Description: Upgrade all Services Unit servers and services to use the SL6 Operating system

Deliverables: All Services and Servers using SL6

Why:

Customer: School

Case statement:

When:

Status:

Timescales:

Priority:

Time: Estimate 10 weeks in total. This include 4 weeks for converting all websites using apache to use the apacheconf component

How:

Proposal:

Resources:

Plan:

Final report URL:

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

Other:

Dependencies:

Risks:

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

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