$Cambridge: hermes/doc/cyrus_mailstore/remapping,v 1.8 2004/05/10 12:22:15 dpc22 Exp $

Objective: NFS spool which can be shared between old and new systems
====================================================================

Users with home directories on NFS
==================================

dump:x:63:63:Dump Account:/home_0/dump:/bin/bash
spam:x:66:66:Spam:/home_0/spam:/bin/bash
system:x:67:15:System:/home_0/system:/bin/bash
msupport:x:850:1:Mail Support:/home_0/msupport:/bin/bash

Propose:
--------

Remove dump, spam, system from NFS:
  move to /opt on prism, orange, yellow (disable spam entirely?)
  All three accounts have entries in quota.master which we should blat.
   - DONE

Leave msupport where it is for the time being:
  850 is safe and can be quitely remapped when everything on hermes-[12]
   - just leave this one alone. 850 allocated on all systems, should be safe.

Home directories != group other:
================================

/home_0:
drwxr-x---   5 dump     dump        4096 Dec 30  2002 dump       DONE
drwxr-x---   8 spam     spam        4096 Mar 17 16:36 spam       DONE
drwxr-x---   4 system   system      4096 Feb  5  2002 system     DONE
drwxr-x---  15 dpc22    staff       4096 Apr 23 12:51 dpc22      DONE
drwxr-x---  14 msupport staff       4096 Oct  3  2003 msupport   DONE

/home_1:
drwxrwx---   6 oper     staff       4096 Aug 15  2003 oper       DONE

/home_51:
drwxr-x---  10 sp253    staff       4096 Apr 15 13:31 sp253      DONE

Groups that we will have to remap
=================================

reset:  Canvas only, not a problem

exim:   No NFS files are group exim: already in fixed state
spam:   /home_0/spam  --> /opt/spam. No other files group spam on NFS?
dump:   /home_0/dump  --> /opt/dump. No other files group dump on NFS?
system: /home_0/system -> /opt/system. No other files group system on NFS?
staff:  Use newstaff group to map NFS files for dpc22, sp253, oper (others?)
          (newstaff on old systems, staff on new: bit of a hack).
  All DONE.

finger: need recursive chgrp on /shared/data/finger.
   Test case : doesn't matter if it breaks.
   Update finger in /etc/group on prism, clients
   chgrp
   Check g+s permissions : Solaris chgrp preserves!
   Fix setgid permission on finger, useradmin job.
   DONE

domains: need recursive chgrp on /shared/data/domains
   Lock out users, PPSW pushes
   Update domains in /etc/group on prism, clients
   chgrp
   Check g+s permissions.
   Fix /opt/MSshell/current/domains.validate
   Allow users back in for domain updates
   Test domain distribution _carefully_
   DONE

lists: need _serious_ recursive chgrp on /shared/data/lists
   Lock out users, PPSW pushes
   Update lists in /etc/group on prism, clients
   Nasty chgrp
   Check g+s permissions.
   Fix /opt/MSshell/current/lists.validate
   Allow users back in.
   Allow users back in for list updates
   Test list distribution _carefully_
   DONE

users: Largest single (but simple) job. Leave to last.
   NB: Choose to use "users" rather than renumbering "other" as "other"
   is a standard Solaris group, used frequently under e.g: /usr

   Add users (400) to /etc/group on prism, clients
     DONE

   Possible complication:
      Exim delivery checks for the last 17 users on old Hermes
      NOPE: all seems fine

   Change passwd map so that default group forall users is users
     - All new files will be group users
     - DONE

   Run CRS job a couple of times to make sure no internal sanity
   checks kick in: DONE

   Wait overnight so that all login processes have new group.

   Kill off persistent IMAP sessions etc
     DONE

   Recursive chgrp. Little Perl script which only changes gid 1 files.
     DONE

   chgrp CANCELLED users
     DONE

NB: switched to using group "hermes" as default group to avoid clash
with existing group "users" on SuSE (used by user "games" !?)

   Fix up Cyrus and PPSW to match.
      Should now be trivial groupadd without any conflicts.