Task:	Sun DICE integration
Group:	roger,neilb,cms
Stage:	1

Notice:

The following document is of historical interest only.

Description

    "The existing Sun systems will be expected to live in the old
     domains but use the same user base as inf.ed.ac.uk, via LDAP." 

The existing systems, at FH/SB, BP, & KB, all have separate user bases, separate file-systems, and different (separate) directory/naming services. Changes to these local (non-DICE) configurations will be minimal (as dictated by the non-unified legacy/DICE "model C").

The Sun environment will be put into cold storage. but will not actually be frozen. We want to be able to take advantage of the directory services being offered within DICE to make sure that the core user information is available in both environments. Home directories (both new and existing) will still be hosted on Sun NFS servers (extracting mount information from LDAP), although new accounts will be created within the DICE name-space.

...and the assumptions made

It is assumed here that:

1. we are concerned primarily with directory services - user & host info, authentication, password info etc.
   (Note: it is possible to extract all information except the encrypted/kerberised password string from LDAP).

2. we need access to (non-local) home directories using mounting information from LDAP.

Other concerns will rely on work elsewhere, or changes to be made at a later stage. Assumptions made with reference to this document are that:

• data flow is in one direction only. All data will be fed from LDAP in the .inf domain to locally existing sites/domains.
  (Note: no data will be fed back from local sites/domains.)

  Non-DICE hosts are passive directory service clients.

• Informatics home directory location and contents are already known/established.
  As stated, all home directories will conform to DICE expectations (they will be "tweaked" to assume they inhabit a DICE world). This should NOT prevent them functioning in their previous environment.

• printing mechanism between local & informatics domains is already known/established.

• start-up (dot) files for configuring environments across both (local & divisional) domains are already established. DICE configuration information will be accessible by global default files. Local configuration files will be unaffected (DICE per-user configuration files use non-standard names - such as .benv & .brc).

• automounting & filesystem access within both local & divisional environments is already established (although different automounters are currently in use at different sites. For example, amd vs automountd).

  Automount maps for legacy systems will be generated from info in the LDAP Directory, and so the info held there must be compatible with automount (to allow generation of legacy automount maps).

• mail delivery and generation on a division-wide basis is already established.

How things currently work...

The three sites currently use different methods to maintain host & user data (directory services).

Given the migration from existing computing environments to the new division-wide environment, we need to preserve this data, but in a unified form, and accessible to existing SUNs as well as DICE (Linux) machines. This would effectively move the authoritative servers to DICE-based hosts.

All user & host info is held differently at each site (for various historical reasons)... CS, FH and SB use NIS, while BP uses NIS+. Consequently updates, etc, are managed differently (manually by files with YP "make" at CS and FH/SB, and manually via nistbladm at BP).

... and how we want them to work

Ideally, legacy Suns should integrate seamlessly into the DICE world, but this isn't going to happen. Keeping the systems separate (the approved and adopted "model C") until all legacy Suns disappear means that:

• users will have separate accounts & passwords (although these may start out being the same, there won't necessarily be any mechanism to keep them in sync).

• mail integration may need additional tweaks (forwarding & filtering on a per-user basis).

• there will be an overhead of maintaining (at least) two environments (but we'll be doing this anyway).

• all new accounts would be created in the DICE domain only, and will require a back-propagation mechanism.

What We Need To Do

Extraction Mechanism

Determine method of extracting data from LDAP repository (which requires knowing what & how information is stored in said LDAP repository, and what information needs to be extracted).

Reconstruction Policy

Co-ordinate reconstruction of relevant maps (presumably automount map for home directories, plus some passwd info) at BP & FH/SB, and legacy info at KB, so that invocation (usage) & functionality are the same, even if the underlying method is different.

Reconstruction Method

This is purely a per-site issue, but it is assumed that it will be required on legacy machines (and so needs to be monitored centrally).

Do extraction procedures need to be automated or formalised? Or could any changes or updates be done on an ad-hoc basis? (How many changes would there be? Enough to warrant the effort of automation?)

It was decided not to convert local sites to query division LDAP server(s) directly because of doubts about the robustness of LDAP implementations for SunOS2.7, and the amount of effort involved to produce a satisfactory working solution.

Additional stages of any data extraction/re-construction using DICE LDAP Directory are:

• find out what information is (or will be) held centrally via LDAP - we need to confirm that the information needed to create any legacy tables/maps is actually in there...

• decide on what information needs to be extracted (all current maps/files at each site?)

• decide on an extraction & distribution method(s). As stated earlier, it isnot possible to extract (use) the encrypted/kerberised password string from LDAP - so passwords in old and new domains would be distinct (and possibly different).

• decide on per-site incorporation method(s)

  Each site has the flexibility to use the LDAP-derived information to support the DICE structures at each site in any way it sees fit, but should implement a minimum level of non-local user access.

• decide on frequency & method of updates (how are changes to LDAP info fed-down to non-DICE structures?)

• decide whether any changes are necessary at any site to accommodate an easier implementation. For example:
  • problem of private hostnames (such as site-specific <host><subnet> name for networking admin, etc, as at BP).

  • conversion to uniform directory service (BP to NIS instead of NIS+?)

• how is data incorporated into the LDAP structure? Can we usefully copy data off at this point?

As we have agreed to keep the Sun environment separate, we have data extraction & distribution as the top-level goals, with integration into current name services at each site.

Issues

• The integration and mounting of home directories between old & new systems will need to be addressed.

• If there is to be minimal crossover, are there additional uses that can be made of a unified directory service?

• As we're not feeding information back, do we care about changes to legacy passwd info?

Dependencies

• LDAP Directory information structure needs to be defined before extraction details are finalised.

Further Info

Given that the operating model for the DICE world is "Model C", and hence cross-over and integration of legacy systems is much reduced, this task (Sun-DICE integration) becomes less important. However, there are still a few loose ends that need to be managed centrally.

 : Deploy 

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