Black

• initial document

Task:	File system issues
Group:	bill, johnb, lmb
Stage:	1

Description

Issues

Changes

• (For 02/4/02)Added section on DCS issues
• (For 02/4/02)Changed unresolved issues section
• (For 19/3/02) Added unresolved Issues Section
• (For 19/3/02) Added discussion of decisions made about shared read/write areas and secondary unix groups.
• (For 19/3/02) Added "Goals of this Task" Section
• (For 19/3/02) Added "Actions" Section

Unresolved Issues

There is still a need for more publicity. It's fairly obvious from questionnaire replies that users (particularly at BP and AI) are not as aware as they might be about how DICE will affect them, and are expecting the changeover to be more seamless that it will be.

Now we have a better idea what DICE will look like, we need to tell users about the decisions that have been made that will affect them.

Information is also needed about who gets a DICE machine when.

Secondary unix groups and shared read/write areas

There was a long discussion about this at the DICE meeting on 19th February. The decisions of this meeting were :-

• There will be a need for some shared read/write areas
• Secondary unix groups will be allowed to support this.
  • A small set of secondary groups can be defined automatically from roles information.
  • Additional secondary groups may be created as required.
  • We will need to define a set of secondary groups required by DICE.
  • ?Did we decide that we will allocate a new set of GIDs in DICE to avoid conflicts with existing GIDs in the 3 legacy domains?
  • We will need to decide where the group information is stored.LDAP?
• We may want to look at the user of ACLs
  • Paul stated that ACLs are implimented on the server side, so there should be no conflict between linux and legacy (Sun) implimentations.
  • Previous experience with Sun's ACL implimentation at BP and AI have not been positive.

This reduces the significance of this task, as it was initially thought that shared read/write areas and secondary unix groups would not be implimented in DICE. This would have meant a great deal of effort to change the working methods of a lot of users.

For completeness some of the reasons we thought we may need shared read/write areas are listed below :-

Reasons for allowing shared read/write areas under /legacy

• It's much less work for us if we don't have to get folk to change the way they work from day1 of DICE roll out.
• There may be projects that finish in the first year, where it is not considered worth changing working methods.
• Academics are always too busy to change right now.
• Moving to DICE is less of a barrier and it's easier for people in the same projects to work in both DICE and legacy worlds. i.e. it's more flexible for us and them.
• In AIAI the main way of working is via a shared /project area. They will NEED this after DICE

As a result of the user survey, we should be able to come up with a set of secondary groups that users think will be needed on DICE machines.

Some site Issues

There are issues at all three sites here. Bill Hewitt is coordinating this at Buccleuch Place, John Berry at Forrest Hill and South Bridge. Lyndsay Brown has now been added as the coordinator for DCS.

The aim of this task is to identify current filesystem use that isn't currently supported by DICE and to recommend how these can be supported under DICE.

The first thing that needs to be done is to talk to users and find out what the usage actually is.

Although most of this data can probably be supported by encouraging the use of cvs and software distribution by means of rpms, it does rely on users making major changes to the way they work. This will have to be handled sensitively.

It is unfortunate that the DICE "Charm offensive" has been so late in getting under way, as this makes the task more difficult.

This is far from a report yet, but below are some of the issues that will need to addressed at Buccleuch Place.

In general shared read/write areas are frowned upon by DICE. The expected workarounds include cvs, provision of larger user quotas, distributing binaries by rpm to install on workstations, and maybe encouraging more use of web pages to distribute data.

The main things we have at Buccleuch Place are

• /projects, with a special category of /projects/ltg, which is slightly different.
• /corpora
  • We will need read only access to corpora in DICE, in addition to the ability to download an individual corpus to a desktop machine for local processing.
  /usr/local
• /usr/contrib
• /opt

• A lot of the stuff from /usr/contrib and /usr/local is gnu tools that are part of linux anyway. Most of the rest can be made available as rpms.
• /corpora - Individual corpuses can be downloaded onto local disks as rpms. However there still may be a need to browse corpora. We could make folk log into a corpora server to do this, or maybe allow read only mounts of corpora for browsing.
• /opt - things are supplied as binaries and may not be rpms. There's also licensed software in there e.g. maple,xwaves,spss,bmdp,wordperfect We also have multiple versions of some things in opt (java) these are fiddly to support as rpms.
• /projects/ltg has non quota ltg homedirectory space in there. I suspect that in many cases this might be a valid choice as the preferred DICE homedirectory. LTG users have both regular home directory space and ltg home directory space. These may need to be merged and large quotas may be needed for ltg users ? Are quotas part of DICE ??
• /projects should mostly be covered by use of cvs and making rpms of software. We need to check exactly what people use projects for and what else may need different provision.

The main Issues in the DAI Domain:

• Admin purposes - most admin staff accessing this via samba, and forced masks used to ensure permissions are correct (ie group writable for that particular NIS group). This is probably the major area causing concern. it is unknown how admin/secretarial staff will react if the only solution posited is CVS. Indeed, those required to use CVS on a monthly basis generally end up 'phoning a member of the computing staff to do it for them, despite having detailed instructions on how to do it, and custom built tools to try to guide them through the process. This is after a year+.
• Web space - for Institutes mostly (a conference would be looked after by a single staff member/possibly PhD student). This varies between having everything group writable (users just newgrp, never bothered with setfacl) to some sort of pseudouser and either nsu, or a shared passwd. As it should be evident from the above this has all been done on an ad hoc basis without conformity - just depended who was doing it. I feel that CVS is not going to be easily accepted by admin staff, without considerable help.

Note as a stage two task there are issues with AIAI (and possibly ANC), but as they are highly computer literate CVS is a primary option at a minimum. AIAI in particular mount all their projects under a /project directory (via automounter). In general they ask for certain subdirectories to be writable by individual members.

The main Issues in the DCS Domain:

In some ways, since DCS have been running LCFG machines, the changes will cause less problems at DCS than the other sites, where there is little or no existing Linux based service.

However, *all* KB based users will be using solely DICE (apart from a very few exceptions) so DICE will have to have all the functionality of the existing DCS setup. They won't have the option of logging onto legacy machines for functionality that didn't make it into DICE.

The following shared data currently exists at DCS :-

• Student Shared Area
  • These are for students who, for various modules, have to work in groups and submit one copy per group of the fruits of their labours.
    • Compiler Techniques Groups
    • HCI Groups
    • Programming Methodology Groups
    • System Design Groups
    • Database Course Groups (not for last couple of years)
• Teaching and Coursework Shared Areas
  • aisubmit
    • Holding area where students submit their coursework into relevant directories and it is then harvested by the tutor for marking.
  • yeargroup accounts
    • All yeargroups (cs1, cs2, cs3, cs4 and msc) have accounts which are accessible by various relevant members of staff (lecturers, admin and syssies) for files relating to cousework. All (most) the relevant yeargroup teaching related web pages are hosted from these accounts and not /disk/public/users. courses Link to www. Some teaching pages including past papers.
• Syssies Shared Areas
  • support
    • Support is an account used by all members of the Support Team. Mail is read and stored here. It has its own web pages which although RCS controlled can be written to by all. Support related files are also created and stored here.
  • ladmin
    • Not sure if it is still used.
  • syssies
    • Lots of links to web directory.
• Admin Shared Areas
  • deptinfo
    • Not sure if this is still in active use. It was the main admin area in pre division days. Still some web pages.
• These are mounted on the windows machines.
  • ito
    • Shared between AI and DCS for files to be available to all admin staff in the ITO. Lives at AI.
  • room3421users
    • Shared between two admin staff at KB to do the accounts.
  • confregusers
    • Created for admin staff at KB for conference preparation. (check if still used.)
• Package Accounts.
  • Do these fall into the category of shared areas? We have lots, approx 400. Some of these will be obsolete but some are still in active use.
• Web Accounts
  • wwwdata Home of Computer Science homepage.
• /useful/risky
  • This is a partition where people can store files outside their home directory. As the name implies it is at their own risk as it is not backed up and files can be deleted if it fills up.
• log files
  • Software which creates log files in various locations? eg amanda.
• Directories on Havra
  • Do we still need directories on havra? Some people have separate directories on havra. This is a hangover from the days when havra was a fast compute server. Not much need for it now. I can't remember when I jast created a directory and there are only a few left now. Has netgroup entry also.

Working with Groups.

In the dcs group file we have only 34 groups. Some of them are obsolete, so I would estimate that we have 20-25 active groups.

Goals of this task

• Carry out a user survey to discover user needs for shared read/write areas and unix groups
• Publicise the changes that will be needed in working methods under DICE and encourage the user of CVS, web, rpms where appropriate.
• Produce a set of secondary groups that will be needed to share data under DICE.
• Produce a list of shared areas that will need to exist under DICE, both during transition phase and in DICE stage2

Actions

• Organise a meeting to discuss the implications of the decisions about secondary unix groups and shared read write areas and to schedule the user survey.
• For 19/3 - Analyse results of user survey.

Summary

Timescales

Dependencies

 : Deploy 

Please contact us with any comments or corrections. Unless explicitly stated otherwise, all material is copyright The University of Edinburgh