Browse Prior Art Database

Method for Synchronizing Distributed Computing Environment Registry with LAN Server Database

IP.com Disclosure Number: IPCOM000117719D
Original Publication Date: 1996-May-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 2 page(s) / 72K

Publishing Venue

IBM

Related People

Casco-Arias, L: AUTHOR [+5]

Abstract

Disclosed is a method for synchronizing the Distributed Computing Environment (DCE**) registry with the IBM* OS/2* LAN Server* database.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Method for Synchronizing Distributed Computing Environment Registry
with LAN Server Database

      Disclosed is a method for synchronizing the Distributed
Computing Environment (DCE**) registry with the IBM* OS/2* LAN
Server* database.

      The IBM OS/2 LAN Server 4.0 enterprise server takes advantage
of the Distributed Computing Environment (DCE**) security
architecture by storing LAN Server user and group information in the
DCE registry.  Since LAN Server legacy clients (LS 4.0 base and
below) should be able to directly access the resources on a
enterprise server, the user and group definitions will also be stored
in the LAN Server database in the legacy format.

      Since administration from a LAN Server 4.0 enterprise
workstation will only update the user and group attributes stored in
the DCE registry, the LAN Server user and group information stored in
the DCE registry will not be consistent with the LAN Server database.
A method for keeping the DCE registry and the LAN Server database
synchronized is needed.

      Developed a Registry Synchronization Process (RSP) as a
"pseudo" slave security daemon which will simulate DCE's slave
security server.  The simulated "pseudo" slave process receives
updates from the master replica and applies them to the LAN Server
database.  The synchronization process will not export its binding
information to the Cell Directory Service (CDS) namespace.  It will
register itself in the "replica list" of the master server for the
sole purpose of receiving updates from the master replica.

      Since the RSP registers itself as a slave replica, the
propagation of registry information from the master replica to RSP is
the same as the propagation between the master and any other slave
replica.  The registry information is propagated from the master
security server to RSP through a set of Remote Procedure Call (RPC)
propagation interfaces.  During the data transf...