DICE development projects - 4d_Dropped

A new project to check the migration

ascobie — Fri, 25 Jan 2013 16:46:16 +0000

Project ID:

271

Current stage:

4d_Dropped

Assigned Priority:

Manager:

ascobie

Unit:

mp-unit

Summary:

A proposal to create a new project

What:

what stuff

Why:

why stuff

When:

when stuff

How:

how stuff

Effort estimate:

5 weeks

Other:

Dependencies: just my time

Risks: Risk free

Review of Forum wireless installation

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

Project ID:

233

Current stage:

4d_Dropped

Manager:

idurkacz

Unit:

inf-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

Informatics chatroom service

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

Project ID:

222

Current stage:

4d_Dropped

Manager:

idurkacz

Unit:

inf-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

Migration of Mailing Lists to Central Service

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

Project ID:

193

Current stage:

4d_Dropped

Manager:

roger

Unit:

services-unit

What:

Description: This project will evaluate whether the new mailing list service provided by IS (http://www.ed.ac.uk/schools-departments/information-services/about/new/m...) is suitable for moving the School's mailing lists across to and if the evaluation is positive will carry out the move.

Deliverables: The transfer of the School's mailing lists to the central server

Why:

Customer: School.

Case statement: We have a requirement to move School services to Centrally provided equivalents where appropriate. This project will determine if the central mailing list server falls into this category and if it does will perform the move.

When:

Status: Shelved. Not currently required.

Timescales: Evaluating the central service should take less than a week. The time taken to migrate the lists will depend on any issues encountered. Three weeks seems like a reasonable estimate for this.

Priority: University policy requires us to do this if possible. Apart from that, there is no urgent need to move the data.

Time:

How:

Proposal:

Resources:

Plan:

Final report URL:

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

Other:

Dependencies: Knowledge of the School's Mailman service and the new central service based on Sympa

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Introduction/Integration of new event management system

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

Project ID:

195

Current stage:

4d_Dropped

Manager:

roger

Unit:

services-unit

What:

Description: This project will manage the introduction of the new event management system procured as a result of https://devproj.inf.ed.ac.uk/project/show/165 into the School and will handle its integration with existing School systems.

Deliverables: A fully integrated event management system fully meeting the School's needs

Why:

Customer: School

Case statement: It has long been realised that the current room booking system was insufficient for the School's needs. https://devproj.inf.ed.ac.uk/project/show/165 identified a suitable commercial produce to procure but this system will need configuration and integration with with School services such as recording of events. Much of this work will be carried out by the vendors but liaison witht he School's computing staff will be required

When:

Status: This project is no longer required.

Timescales: Two weeks have initially been allocated for this project.

Priority:

Time:

How:

Proposal:

Resources: Suitable hardware and software to run the new system

Plan:

Other:

Dependencies: Interaction with the new system's vendors.

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Port inf-unit components to F12

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

Project ID:

162

Current stage:

4d_Dropped

Manager:

gdmr

Unit:

inf-unit

What:

Description: Port the inf-unit components to F12. As a side-effect, port any that haven't been to the new buildtools and the svn repository.

Deliverables:

Why:

Customer:

Case statement: This is needed as part of the F12 work.

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal:

Resources:

Plan:

Other:

Dependencies: The F12 project depends on this one.

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Rewrite the LCFG syslog component

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

Project ID:

138

Current stage:

4d_Dropped

Manager:

squinney

Unit:

mp-unit

What:

Description: It has noted that the syslog component is in need of some attention. It suffers from a number of problems:

The paths to the syslogd and klogd programs are hardwired in the shell code - prevents use with any other compatible daemon.
All the log file paths are hardwired in the shell code.
It uses the old-style LCFG templating system to generate m4 files which are then processed to generate the final syslog configuration file. This also means that resources contain m4 statements rather than simple values.

Fedora now uses rsyslog as the default syslogd, and has done since November 2007. This means it is fairly likely to be in RHEL6. It is also used by Debian and Ubuntu so it looks like it is becoming the de facto standard choice for a modern syslogd. It supports the old config file but also has lots of other nice features which could be useful. It is also highly desirable to make the component generic enough to support multiple different syslogds. Alternatively it might be good to write a specific rsyslog component which makes it possible to enable the fancy features via LCFG. We might even want to do both of these.

See the rsyslog website for more details on rsyslog.

There is an rsyslog package available in SL5 but it's version 2.0 which is somewhat behind the current stable version.

Deliverables: A new LCFG syslog component.

Why:

Customer:

Case statement:

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal:

Resources:

Plan:

Other:

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Provision of new Networker server

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

Project ID:

136

Current stage:

4d_Dropped

Manager:

cms

Unit:

services-unit

What:

Description: The School has a considerable amount of data backed up using the Networker backup system. Though Networker is no longer used for backing up School file systems, there is still a requirement to be able to restore older data backed up with networker. With the demise of old networker server, this facility is not currently available. This project would manage the installation of a new networker server and the restoration of this facility.

Deliverables: A new server running Networker

Why:

Customer: School

Case statement: This is essential if we are to continue to be able to access older data

When:

Status: Moving this project to Linux proved significantly more difficult than had been anticipated. In view of this and the lack of requests for networker restores (in extremis, we can use the original Solaris server) it was agreed to drop this project.

Timescales:

Priority:

Time: Two weeks have been allocated for this project.

How:

Proposal:

Resources: Knowledge of Networker and probably Solaris.

Plan:

Determine best approach to take. Should we simply reuse an existing sun server (no initial costs but expensive in power and maintenance) or buy new Sun hardware for the service? Will networker work with Solaris 10 or will we have to stick with Solaris 9? Could we use Open Solaris and cheaper hardware? Could we buy a version of networker which isn't Solaris based and would our existing indexes etc work with it?
Install new server as determined above
Install Networker and tape drive on new server
reinstall backup indexes from ouroboros mirror
Perform test restores

Other:

Dependencies: None.

Risks:

Milestones

Achieved date	Name	Description
2010-03-08	Determine appro	Determine best approach to take (some possibilities are detailed in plan section)
2010-03-01	Mistake	Created in error. Ignore
2010-10-01	install server	Install the new server as eventually determined in step 1
2010-10-01	test	Install the networker indexes from mirror and perform test restores

Extend traffic monitoring to FibreChannel switches

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

Project ID:

128

Current stage:

4d_Dropped

Manager:

gdmr

Unit:

compexec

What:

Description: Extend the traffic monitoring, as found on the netmon.inf.ed.ac.uk pages, to cover the fibrechannel switches too.

Deliverables: More graphs!

Why:

Customer: COs

Case statement: The netmon traffic graphs have repeatedly shown their value. It would be very useful to have the same kind of window onto the FibreChannel traffic.

When:

Status:

Timescales: This is unlikely to take a lot of effort to implement. It's mostly just a case of adapting the ether-switch code to cover the FibreChannel case too

Priority:

Time:

How:

Proposal:

Resources: Nothing beyond what's on the network infrastructure machines already.

Plan:

Other:

Dependencies: None

Risks:

Milestones

Proposed date	Achieved date	Name	Description

LLDP for DICE

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

Project ID:

127

Current stage:

4d_Dropped

Manager:

gdmr

Unit:

inf-unit

What:

Description: There are a couple of viable LLDP implementations available for Linux now. lldpd looks pretty promising, while ladvd is worth another look. (OpenLLDP seems to have got stuck.)

Deliverables: LLDP on DICE

Why:

Customer: COs

Case statement: It would be very useful to have LLDP available on more than just the switches. Implementing LLDP on DICE would mean that machine names would show up in the netmon index pages, making it much easier to see what's what.

When:

Status:

Timescales: This is unlikely to take very much in the way of effort. Indeed, it's quite likely that it wouldn't even rise above the devproj threshold. It's here for prioritisation, as much as anything else.

Priority:

Time:

How:

Proposal:

Resources: Nothing out of the ordinary

Plan:

Other:

Dependencies: None

Risks:

Milestones

Proposed date	Achieved date	Name	Description