home *** CD-ROM | disk | FTP | other *** search
- Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.kodak.com!news-nysernet-16.sprintlink.net!news-east.sprintlink.net!news-peer.sprintlink.net!news-backup-west.sprintlink.net!news.sprintlink.net!199.72.1.44!interpath.net!tophat!mauney
- From: mauney@mauney.com (Jon Mauney)
- Newsgroups: comp.soft-sys.dce,comp.answers,news.answers
- Subject: OSF Distributed Computing Environment Frequently-asked questions
- Supersedes: <dce-faq-1-895664954@mauney.com>
- Followup-To: comp.soft-sys.dce
- Date: 28 Oct 1998 02:41:09 GMT
- Organization: Mauney Computer Consulting
- Lines: 2009
- Approved: news-answers-request@MIT.EDU
- Distribution: world
- Expires: 01 Dec 98 22:36:26 EDT
- Message-ID: <dce-faq-1-909542186@mauney.com>
- Reply-To: jon@mauney.com (Jon Mauney)
- NNTP-Posting-Host: jtec.mauney.com
- Summary: Answers to frequently asked questions about
- the Open Software Foundation's Distributed Computing Environment (DCE).
- It provides a brief overview of what DCE is, pointers to sources of
- more information on DCE, and answers to common technical questions.
- Keywords: DCE Distributed Computing FAQ
- Originator: mauney@tophat
- Xref: senator-bedfellow.mit.edu comp.soft-sys.dce:7941 comp.answers:33589 news.answers:143033
-
- Posted-By: auto-faq 3.1.1.2
- Archive-name: dce/faq
- Revision: 1.36 1998/10/28 02:36:18
- Posting-frequency: monthly
-
- DCE Frequently Asked Questions
-
- This document answers some Frequently Asked Questions concerning
- the OSF Distributed Computing Environment.
- It is posted monthly to comp.soft-sys.dce, as well as
- comp.answers, and news.answers.
-
- The questions (and answers) in this FAQ have been divided
- into 3 tiers, for convenience, scalability, and because its
- just the cool thing to do.
-
- (*) Tier 1, User support, contains general questions about DCE
- (*) Tier 2, Application support, contains technical questions about DCE
- (*) Tier 3, Data Management, contains pointers to further information
- about DCE
-
-
- --------------------------------------------------------------
- Tier 0 -- Header files
-
- The document is maintained by Jon Mauney, mauney@ivc.com
-
- Suggestions, corrections, and updates are actively sought.
-
- This FAQ is available for browsing on the web
- http://www.ivc.com/~mauney/dce-faq.html
-
- This FAQ is posted on Usenet to comp.answers and comp.soft-sys.dce
- and is available for anonymous ftp from sites that archive those
- newsgroups, such as rtfm.mit.edu and fine mirror sites worldwide.
-
- Last modified on 23 October 1998
-
-
- Changes since it was last posted on May 22, 1998
-
- Q 1.07 : updated link to Transarc solutions page.
-
- Q 2p-02: remove link to Lexis-Nexis whitepaper on cell size.
-
- Q 3.05: update information about Linux DCE
-
- Q 3.01: add pointer to Transarc's online documentation
-
- Q 3.02: add mention of Campbell's AFS book
-
- Changes since it was posted on March 12, 1998
-
-
- Q 1.03 : updated info on NT, OS/390
-
- Q 2cc-05,3.01,3.07: updated the URLs for Transarc's web site
-
- Q 2r-07, 2p-06, 2s-01, 2r-14, 2cc-02: Added URLs for examples at
- Transarc's web site.
-
- Added Q2p-07: Should I choose UDP or TCP for my RPC?
-
-
- Changes since it was last posted on January 17, 1998
-
-
- 3.01 Add link to IBM's AIX DCE web page
-
- Changes since it was last posted on November 6, 1997
-
-
- 2p02 Add information on IBM enhancements to security server to permit
- large number of DCE principals to be created.
-
- 2cc06 Add clarification that cross-cell delegation is possible in
- restricted circumstances.
-
- 3.01 Add link to Keys Botzum's DCE&Encina question and answer page
-
- 3.05 Add links to Linux DCE web pages by Andrew Sandoval and by Jim Doyle.
-
- --------------------------------------------------------------
- Tier 1 -- Front-end, user support
-
- Q 1.01: What is DCE?
- Q 1.02: What are the advantages of DCE?
- Q 1.03: What platforms support DCE?
- Q 1.04: What products use DCE?
- Q 1.05: Is DCE an official standard?
- Q 1.06: The DCE threads uses draft 4 of the standard, but
- Posix threads standard has moved beyond draft 4.
- Will DCE change to the most recent standard?
- Q 1.07: Is anyone using DCE for real-life mission-critical systems?
- Q 1.08: What is the relationship between DCE and CORBA?
- Q 1.09: Is DCE IDL the same as all the other IDL's in the world?
- Q 1.10: Now that OSF is the Open Group, should we talk about OG DCE?
-
-
- Tier 2 -- Application support
-
- Sub-interfaces:
- RPC and IDL
- Compatibility
- Performance
- Cell Configuration
- Security
-
- Sub-interface: RPC and IDL
- Q 2r-01: Several of the other questions concern "interfaces".
- What is meant by an interface in DCE RPC?
- Q 2r-02: Can a DCE client import multiple interfaces?
- Q 2r-03: Can a DCE client connect to multiple servers?
- Q 2r-04: Can a DCE server export multiple interfaces?
- Q 2r-05: Can a process be both a server and a client?
- Q 2r-06: How do I perform asynchronous RPC?
- Q 2r-07: How can a server keep track of multiple clients?
- Q 2r-08: How can a server detect that a client as exited or crashed?
- Q 2r-09: How can a server identify the client that has called it?
- Q 2r-10: Can I move idl-compiled stubs from one platform to another and
- rebuild the object files locally?
- Q 2r-11: How are UUIDs generated?
- Q 2r-12: How can I pass a UUID as a parameter in an RPC?
- What is the format of a uuid_t structure?
- Q 2r-13: How can I pass a binding handle as an ordinary parameter in an RPC?
- Q 2r-14: How do I keep my server from
- advertising all the host machine's network addresses with CDS?
- Q2r-15: How do I share type declarations between two
- or more IDL files?
- Q 2r-16: How can I control the timeout of a context handle?
- Q 2r-17: A server has moved or otherwise changed its binding information.
- How do I make the client obtain the new binding ?
-
- Sub-Interface: Performance
- Q 2p-01: How efficient is DCE RPC?
- Q 2p-02: What is the practical limit on the size of a DCE cell?
- Q 2p-03: How much memory and disk space is required for DCE services?
- Q 2p-04: How can I control the number of concurrent client connections
- and the size of the request queue on a server?
- Q 2p-05: My server gets a stack error when sending large objects. How
- can I avoid this?
- Q 2p-06: How do I get clients to connect to the nearest server?
- Q 2p-07: Should I choose UDP or TCP for my RPC?
-
- Sub-Interface: Compatibility
- Q 2c-01: Will Windows NT communicate with DCE?
- Q 2c-02: Can I use DCE from C++?
- Q 2c-03: Can I write an application that uses DCE and X11/Motif?
- Q 2c-04: Is DCE RPC compatible with ONC RPC?
- Q 2c-05: Is XDR compatible with NDR?
-
- Sub-Interface: Cell Configuration
- Q 2cc-01: Is it possible for a machine to be a member of more than one DCE cell?
- Q 2cc-02: How do I configure cells to find each other using DNS?
- Q 2cc-03: Is it possible for a user in one cell to use secure services
- in another cell?
- Q 2cc-04:: How do I change the name of my cell?
- Q 2cc-05:: How do I change the IP address of
- a host in my cell?
- Q 2cc-06:: How do I do inter-cell delegation?
- Q 2cc-07:: How can I find out who is currently logged in to a DCE cell?
-
-
- Sub-Interface: Security
- Q 2s-01: Where can I find an ACL manager to include in my application?
- Q 2s-02: Does DCE Security interoperate with other Kerberos systems?
- Q 2s-03: Can I allow DCE clients and servers to communicate
- across a firewall?
- Can I control the endpoints assigned to DCE servers?
- Q 2s-04: Do DCE servers automatically update their long term secret keys?
- Q 2s-05: What problems might I cause by changing the expiration time
- or password lifespan in a running cell?
- Q2s-06: How do I begin to force password changes,
- without getting into the trouble described in the previous question?
- Q 2s_07: Do all versions of DCE support the sec_key_mgmt_manage_key()
- functionality in the same way?
- Q 2s_08: How can I work around the key_mgmt problem if I have older client
- machines, but DCE 1.1+ based servers?
-
-
-
- Tier 3 -- Data management
-
- Q 3.01: Where can I get online information about DCE?
- Q 3.02: What books are published on DCE?
- Q 3.03: Where can I get more information about DCE and DCE-related products?
- Q 3.04: What are DCE RFCs, and how can I get them?
- Q 3.05: Where can I get the Public Domain version of DCE?
- Q 3.06: Is there a DCE Users Group I can join?
- Q 3.07: Are there any example programs available on-line?
-
-
- --------------------------------------------------------------
- The answers please:
- --------------------------------------------------------------
- Tier 1 -- Front-end User Support
- --------------------------------------------------------------
-
- Q 1.01: What is DCE?
-
- A:
- DCE is the Distributed Computing Environment, from the
- Open Software Foundation. (It is called "the DCE" by sticklers
- for grammatical consistency.) (The Open Software Foundation
- is now called the Open Group.)
-
- DCE consists of multiple components which have been integrated
- to work closely together. They are the Remote Procedure Call
- (RPC), the Cell and Global Directory Services (CDS and GDS), the
- Security Service, DCE Threads, Distributed Time Service
- (DTS),and Distributed File Service (DFS). The Threads, RPC, CDS,
- Security, and DTS components are commonly referred to as the
- "secure core" and are the required components of any DCE installation.
- DFS is an optional component. DCE also includes administration tools
- to manage these components.
-
- DCE is called "middleware" or "enabling technology." It is not
- intended to exist alone, but instead should be bundled into a
- vendor's operating system offering, or integrated in by a third-party
- vendor. DCE's security and distributed filesystem, for example,
- can completely replace their current, non-network, analogs.
- DCE is not an application in itself, but is used to build custom
- applications or to support purchased applications.
-
- --------------------------------------------------------------
- Q 1.02: What are the advantages of DCE?
-
- A:
-
- First, DCE provides services that can be found in other computer
- networking environments, but packages them so as to make them
- much easier to use. For example, the DCE Remote Procedure Call
- (RPC) facility provides a way of communicating between software
- modules running on different systems that is much simpler to code
- than older methods, such as using socket calls.
-
- Second, DCE provides new capabilities that go beyond what was
- available previously. The DCE Security Service provides a
- reliable way of determining if a user of a distributed system
- should be allowed to perform a certain action, for example. This
- is very useful for most distributed applications, yet the design
- and implementation effort entailed in providing such a capability
- would be prohibitive for an individual developer.
-
- Third, DCE integrates components in a manner that makes them more
- valuable together than separately. For example, the DCE RPC uses
- threads in such a way that a developer can implement a
- multi-threaded server without ever explicitly creating or
- destroying a thread.
-
- Finally, DCE supports both portability and interoperability by
- providing the developer with capabilities that hide differences
- among the various hardware, software and networking elements an
- application will deal with in a large network. For example, the
- RPC automatically converts data from the format used by one
- computer to that used by another.
-
- Portability is a measure of the ease with which a piece of
- software that executes on one type of computer can be made to
- execute on a different type of computer. Interoperability is a
- measure of the ability of computers of different types to
- participate in the same distributed system.
- --------------------------------------------------------------
- Q 1.03: What platforms support DCE?
-
- A:
-
- DCE is fully supported on most major platforms, including all major
- Unix platforms and many non-Unix platforms.
- Most vendors support at least the "secure core" which means all of the
- DCE services except the Distributed File Service and X.500 interface
- to the Global Directory Service.
-
- Some products are client-only, which means that the actual servers
- for the DCE services are not provided: Directory Service, Security
- Service, Time Service. Client machines can use these services,
- they simply cannot run the server programs; another machine
- in the cell must run the server programs. Application programs
- can be built and run the application servers on these "client-only"
- systems.
-
- The status of DCE implementations changes frequently; check with the
- specific vendors for the latest details, or see the DCE product
- list (see the next question). Updates to this FAQ
- are solicited.
- This table summarizes the DCE implementations currently available:
-
-
- -------------------------------------------------------------
- Platform Comments
- -------------------------------------------------------------
- Unix platforms:
- Digital UNIX: Secure core, DFS, and X.500
- Ultrix had a "Starter kit", but of course Ultrix is
- no longer supported...
- HP-UX: Secure Core, DFS , and X.500
- DG/UX Secure Core and X.500
- AIX: Secure core, DFS, and X.500
- SunOS, Secure Core
- Solaris: Secure core and DFS
- Implementation by Transarc, also re-sold by Sun
- Irix Secure Core, DFS, X.500
- SCO Secure Core was expected by August 1994
- AT&T GIS, SVR4 on Intel Secure Core
- Sinix (Mips and Intel) Secure Core, DFS, and X.500
- Cray Unicos Secure Core Client, and DFS server
- Pyramid DC/OSx (SVR4) Secure Core
- Hitachi HI-OSF/1-MJ (osf/1) Secure Core, with Japanese on-line doc
- Hitachi HI-UX/WE2 Secure Core
- Sony NEWS (SVR4) Secure Core
- Fujitsu DS/90 (SVR4) Secure Core
- System V on Intel: Secure Core, from Gradient Technologies
- Unixware, Sequent Dynix, NCR MP-RAS, Unisys
- Dascom AD V1.1 (OSF/1 on Intel) Secure Core Client
-
- Non-Unix platforms:
- Tandem NonStop Kernel Secure core
- OpenVms (Vax, and Alpha AXP) Secure core, X.500 support
- Microsoft Windows: Client-only, available from Gradient Technologies
- Gradient's port is also sold by Siemens,
- and IBM.
- Unimetrics has announced DFS client products
- for Windows
- Transarc has a "DFS-Light" client for Windows
- Macintosh Client only, from Gradient Technologies
- Open Environment Corporation has a Macintosh
- client that allows access to DCE servers by
- way of an OEC server on another machine.
- Windows NT: out-of-the-box, NT contains a subset of
- DCE RPC. See Q 2c-01 for further discussion.
- Gradient has full secure core DCE+DFS for NT
- Digital has secure core
- IBM has secure core
- Transarc has DFS client and server and a
- "DFS-Light" client for WinNT
- Windows 95 Client only, from Gradient
- Client only, from Digital
- Transarc has a "DFS-Light" client for Win95
- OS/2: Secure core
- HP 3000 with MPE/iX Secure Core
- VM Kapsch AG supports DCE client and the
- security server on IBM's VM and VM/ESA
- VM/ESA IBM has announced intent to support
- "selected components" of DCE on VM/ESA.
- These components boil down to secure client
- without DTS
- Kapsch AG supports DCE client and the
- security server on IBM's VM and VM/ESA
- IBM OS/390 (MVS) secure core + DFS
- IBM AS/400 client only
- BS2000 Client Only
- Bull DPX/20 Secure Core, X.500, DFS
- GCOS on Bull DPS 9xxx/7xxx threadless client only
-
-
- --------------------------------------------------------------
- Q 1.04: What products use DCE?
-
- A:
-
- The Open Group maintains an Open Software Registry, which contains
- information about DCE products, among others. Access is free, but
- you must register.
- The registry is available on-line at http://www.opensoftware.com/
- Once you get in, you can search for DCE, and your favorite platform
- or other criteria.
- Hint: A search using "DCE" as the product name will find only
- those products whose listed name starts with DCE. If you want
- to find products like "PC-DCE", "Nonstop DCE", and "Kapsch-DCE/VM", search
- for "*DCE" instead. If you want to find DCE-related products like Encina
- or Dazel, go to the advanced search and choose the Keyword DCE.
- Note to vendors, not all DCE implementations show up under a keyword
- search for DCE, so check your listings.
-
- --------------------------------------------------------------
- Q 1.05: Is DCE an official standard?
-
- A:
-
- The OSF calls the specification an Application Environment Specification,
- or AES. The AES documents both the software programming interfaces and
- also the communications protocols employed by DCE. Thus it would be
- possible, in theory, for someone to build a compatible
- implementation without using the code from the Open Group.
- The AES for RPC, Time, and Directory services have been accepted as
- standards by X/Open. The AES for Security is currently undergoing
- review.
-
- DCE Threads follow the Posix Threads draft standard 1003.4a draft
- 4. DCE Access Control Lists (ACLs) are based on POSIX.6 Draft
- 12. The Distributed Time Service (DTS) uses time formats defined
- by international standards and in POSIX.4. The Global Directory
- Service (GDS) complies with the X.500 international standard.
- (Although DCE complies with the 1988 version of X.500, not
- the 1992 version.)
-
- ISO is considering an RPC standard based on the X/Open document.
-
- DCE's status as a de facto standard is even stronger. Almost
- every major hardware and software vendor has committed to
- providing DCE on its platform. These vendors include not only
- Open Group stalwarts such as IBM, DEC and HP, but also other key vendors
- such as Novell, Inc. See Q 1.03 for a list of DCE vendors. In addition,
- a number of major user organizations (e.g., the European Economic
- Community) have already embraced DCE as their standard for
- distributed applications.
-
- --------------------------------------------------------------
- Q 1.06: The DCE threads uses draft 4 of the standard, but
- Posix threads standard has moved beyond draft 4.
- Will DCE change to the most recent standard?
-
- A:
-
- It is hard to predict exactly what will happen.
- But Open Group prefers to follow standards rather then invent them.
- Now that Posix has settled on the standard, we can expect
- the DCE to migrate to it.
-
- --------------------------------------------------------------
- Q 1.07: Is anyone using DCE for real-life mission-critical systems?
-
- A:
-
- Yes, and more every day. Tokio Marine and Fire Insurance,
- Co., Lehman Brothers, and Charles Schwab have all publically
- described their ongoing rollout of DCE based applications.
-
- The Open Group's Web server has a section that includes some reports on
- 'real-world' experiences from companies using DCE in production.
-
- Intellisoft published a 48-page "advutorial" (that
- means advertisement and tutorial) with the help of
- many DCE vendors, totally devoted to the above. There are storeis about
- DCE in production, technical essays, etc.
- The supplement is on-line and available via Intellisoft's web site
- (http://www.isoft.com/publications.html -- click on "DCE and The Enterprise" ).
-
- Transarc's web server includes a page in which they describe solutions
- used by some of their customers.
-
- http://www.transarc.com/dfs/public/www/htdocs/.hosts/external/Solutions/index.html
-
- --------------------------------------------------------------
- Q 1.08: What is the relationship between DCE and CORBA?
-
- A:
-
- The short answer:
-
- There is not a lot of direct relationship. DCE and CORBA
- are tools to help you build distributed systems. Each has
- its advantages and disadvantages. Use of one will not
- hinder future use of the other.
-
- DCE provides a lower-level programming model than does CORBA.
- DCE is not fully "Object-Oriented". DCE has far better
- inter-operability than (current) CORBA products.
- DCE is an optional interoperability mechanism in the
- CORBA 2.0 specification.
-
- The long answer:
- In order to understand the relationship between DCE and the Common
- Object Request Broker Architecture (CORBA) of the Object Management
- Group (OMG), it is necessary to consider the past, the present and the
- future.
-
- Past - Historically, the object paradigm has been viewed as a break
- with procedural styles of the past. Objects, which encapsulate data
- and procedures behind an external interface, are often contrasted with
- other approaches where procedures and data are treated separately.
-
- In this context, DCE is a descendant of the procedural school which
- emphasizes the decomposition of programs into procedures and achieves
- distribution by locating some of those procedures remotely. Thus there
- was a tendency for the object community, including the OMG, to view DCE
- as technology which was obsolete before it was available.
-
- However this view ignored the fact that designers of distributed
- systems had for a long time recognized that the most successful
- approach to developing distributed systems was to created encapsulated
- objects that can only be accessed via well defined interfaces. Thus
- the cornerstone of DCE RPC is the interface definition language (IDL)
- which allows the external attributes of a set of server operations to
- be specified.
-
- Furthermore, the name-based binding mechanisms of DCE were extended to
- include the ability to bind to a server based on the object instances
- which it supports. These object binding mechanisms also allow the
- transparent selection among multiple implementations of the same server
- operations based on the type of the specified object. In object
- terminology this is called polymorphism.
-
- The DCE notion of a server supporting interfaces consisting of one or
- more operations is so close to the notion of an object which provides
- one or more methods, that it should be no surprise that CORBA defines
- an IDL which differs from DCE IDL in only a few significant respects.
-
- Principal among these is that in CORBA IDL every call must specify an
- object, which is used in determining the server to use. DCE can do
- this as well, but there is more work involved and it is optional.
- Another difference is that CORBA IDL allows an interface to be defined
- as a extension of one or more other interfaces, this is called
- interface inheritance. DCE does not permit interface inheritance, but
- may in the future. Implementation inheritance is not specified by
- either DCE or CORBA.
-
- The use of object oriented techniques and principles should not be
- confused with using an object oriented language. Object oriented
- designs can be expressed in procedural languages, and in fact most of
- the current object environments supported C before supporting C++ or
- Smalltalk. Therefore, the fact that the DCE API is implemented in C is
- no barrier to using it to create a distributed object system. In fact,
- CORBA specified C language bindings first.
-
- Present - CORBA should not be viewed in isolation, but in the context
- of all of the OMG's standardization efforts. OMG has defined a
- reference architecture (OMA) and has defined or is defining standards
- in a broad range of areas, including: databases, events, lifecycle,
- transactions, persistence, security, naming and relationships. Viewed
- in this way, OMG's activities are much more ambitious and broader in
- scope than DCE.
-
- A recent addition to CORBA, as a part of the CORBA 2.0 work was the
- definition of the means of interoperability between ORBs. CORBA 2.0
- defines one mandatory and two optional mechanisms. The mandatory means
- is a new, lightweight protocol called UNO. The optional means are 1)
- via a gateway and 2) via an alternative protocol definition. At the
- present the only alternative protocol that has been defined is DCE
- RPC.
-
- Many people who had hoped that DCE would be selected as the mandatory
- protocol were disappointed at this result. However, it should be
- observed that DCE is endorsed as alternative protocol and that several
- vendors have committed to providing ORBs that interoperate via DCE.
-
- Another difference between DCE and the OMG standards is one of general
- philosophy. DCE has been defined quite rigorously in a series of
- documents published by X/Open. There is a set of conformance tests
- that are available to anyone. Any product passing these rigorous tests
- can be branded as DCE, without necessarily being based on the OpenGroup
- code. Several vendors, including Microsoft and Tandem have reverse
- engineered significant portions of DCE.
-
- OMG standards vary considerably in their level of detail, but in
- general, aim at a much looser level of standardization. In some cases,
- the standard merely specifies an object interface and some general
- semantics. This approach is a deliberate attempt to encourage diverse
- solutions which may be applicable in different environments. Even
- where specifications are relatively tight, for example in the area of
- CORBA portability, there is still room for considerable interpretation,
- as witness the fact that there is at least one company that provides
- consulting services on how to make CORBA applications compliant in
- practice.
-
- At the present time, CORBA-compliant products and products that work
- with them do not provide a scaleable infrastructure suitable for large
- environments. Key features such as concurrency mechanisms, security
- and distributed transactions are not currently available. In contrast,
- DCE provides proven heterogeneous interoperability and most of the
- capabilities required by robust, production applications. Additional
- capabilities can be obtained by means of third products, such as
- transaction monitors built upon DCE. This situation will change over
- the next 2-3 years from a combination of standardization work by OMG
- and new product development by vendors.
-
- Future - Most authorities agree that in the long term object technology
- will be the basis for building large scale distributed systems. In
- addition to the principle of encapsulation, object- based systems allow
- systems to be built up, evolve and be reconfigured as needed because of
- their ability to dynamically bind requesters to objects that provide
- services.
-
- There are many specific issues concerning the properties of distributed
- object systems that are the subject of research and debate. It is also
- clear that there are some features of existing local object
- environments and languages that will not scale effectively to large
- scale distributed systems -- dynamic inheritance is one. Never the
- less, the general direction of the future is clear.
-
- Clearly, the high level of interest in OMG defined standards comes not
- from current products, but from their exciting future potential. There
- is a natural tendency to compare DCE's current capabilities with the
- promise of CORBA's future. However, DCE is also evolving and will
- likely add additional object oriented features in the future. For
- example, HP is offering a DCE C++ class library which is expected to
- eventually become a standard part of DCE.
-
- Where DCE was built by integrating existing software, OMG has chosen by
- and large to start with a clean sheet of paper. The idea is to be
- better able to implement object oriented constructs without the baggage
- of features carried over from previous systems. However, OMG faces
- great challenges. Object theory is currently in a great state of
- flux. Experts disagree on very fundamental issues about what features
- are necessary, useful or harmful.
-
- Developing standards under these conditions is extremely challenging.
- OMG's approach to date has been to compromise and allow multiple
- alternatives. It is unclear whether this will succeed in the long
- run.
-
- Does the conclusion that future distributed systems will be object-
- based mean that it is a mistake to build distributed systems today
- using DCE? The answer is no for several reasons. First, many
- organizations cannot afford to do nothing for several years. End users
- have pressing needs for robust, scaleable systems today. For many
- organizations, waiting would mean attempting to catch up with
- competitors who will have a tremendous head start.
-
- Second, as this brief discussion has shown, it is possible to employ
- object techniques when developing distributed applications using DCE.
- Carefully designed systems will be able to take advantage DCE features
- such as dynamic binding and polymorphism and converge with
- CORBA-compliant systems as they mature.
-
- Third, if object environments are to be successful in supporting
- industrial-strength distributed systems, they will have to address the
- problems that DCE addresses. The skills and techniques developed in
- working with DCE will be directly applicable to distributed systems
- environments of the future. This applies not only software developers,
- but also to operations personnel, planners, even business managers.
-
- Further, the likelihood that DCE will be at least one technology for
- CORBA interoperability, implies that the eventually migration of
- applications which use DCE directly to an object environment should not
- present any insurmountable difficulties.
-
- Finally, your direct experience in developing and operating robust
- distributed systems will provide you with great insight into the
- important characteristics of distributed systems environments as they
- apply to your organization's applications. This knowledge is vital to
- the shaping of successful tools of the future. History has shown that
- vendors and standards bodies, left to their own devices, will often
- miss the mark.
-
- --------------------------------------------------------------
- Q 1.09: Is DCE IDL the same as all the other IDL's in the world?
-
- A:
-
- No.
-
- IDL stands for "Interface Definition Language," and the idea
- of using a special language to define the interface between
- entities is not unique to DCE. In particular, OMG's IDL for CORBA
- is used for the same purpose as DCE's, but the two languages
- are not identical; see Q 1.08 for more information. There are
- other Interface Definition Languages as well.
- IDL also stands for "Interactive Data Language", which
- is a completely unrelated product.
-
- When asking or answering a question about IDL, one should be
- careful about specifying which IDL is involved.
-
- --------------------------------------------------------------
-
- Q 1.10: Now that OSF is the Open Group, should we talk about OG DCE?
-
- A:
- No. "OSF DCE" is the registered trademark, and will apparently remain the
- name of the product.
-
- --------------------------------------------------------------
- --------------------------------------------------------------
- Tier 2 -- Application Support
-
- RPC and IDL
- --------------------------------------------------------------
- Q 2r-01: Several of the other questions concern "interfaces".
- What is meant by an interface in DCE RPC?
-
- A:
-
- An interface is a set of remote procedure call operations and
- associated data. Every interface contains one or more
- operations. An operation is an actual remote procedure. Each
- operation may have input and output parameters associated with
- it, just like any procedure call.
-
- --------------------------------------------------------------
- Q 2r-02: Can a DCE client import multiple interfaces?
-
- A:
-
- Yes. A client can use as many different services as it needs.
- To code such a client, simply include the header files for
- all the RPC interfaces used, and code each call the same way
- you would if using that interface in isolation.
-
- --------------------------------------------------------------
- Q 2r-03: Can a DCE client connect to multiple servers?
-
- A:
-
- Yes. A client can connect to multiple servers providing different
- services, and/or multiple servers providing the same service.
-
- To use multiple servers with the same interface, the client must
- obtain a binding handle for each server and use explicit handles
- in the RPC.
-
- --------------------------------------------------------------
- Q 2r-04: Can a DCE server export multiple interfaces?
-
- A:
-
- Yes. A server can provide service on multiple interfaces
- simultaneously. A common example is a server that exports an
- application interface and a management interface.
-
- To code such an application, repeat the calls to rpc_server_register_if(),
- rpc_ep_register(), (and rpc_ns_binding_export() if you do that sort
- of thing in your server) for each interface, before calling
- rpc_server_listen().
-
- --------------------------------------------------------------
- Q 2r-05: Can a process be both a server and a client?
-
- A:
-
- Yes. There are two scenarios.
-
- 1) A program might act as a server for interface A,
- and also as a client for interface B. This is easy.
- The program merely imports interface B like a normal
- client and exports interface A like a normal server.
- 2) A program might want to provide a service, and also
- act as a client to other servers that provide the same
- service. In this case, the programmer must expend more
- effort. The problem is that the names of the server-side
- functions (manager routines) clash with the names of the
- client stubs. The solution is to manually build an
- entry point vector for the server, and use different names
- for the manager routines. For details on using entry point
- vectors, see the Lockhart book (Q 3.02).
-
- Note that most server programs also act as clients, since they
- usually access the endpoint mapper (rpcd), and the security
- service; these actions use RPCs, though it may not
- be obvious in the code.
-
- --------------------------------------------------------------
- Q 2r-06: How do I perform asynchronous RPC?
-
- A:
-
- DCE-RPC is synchronous. The way to make an asynchronous call is
- to create a thread for each RPC call. You should be able to have
- dozens, if not hundreds, of threads with no problem.
-
- --------------------------------------------------------------
- Q 2r-07: How can a server keep track of multiple clients?
- For example, to know what information has already been
- provided to a client, and thus vary subsequent responses.
-
- A:
-
- The DCE RPC mechanism includes a "context handle" which can be
- created by a server and returned to a client. The handle is used
- on subsequent RPCs to identify the client.
-
- http://www.transarc.com/Public/Support/dce/prog_examples/rpc/context_handles/context_handles.html
- includes sample code for a greet-type client/server
- that uses context handles.
-
-
- --------------------------------------------------------------
- Q 2r-08: How can a server detect that a client has exited or crashed?
-
- A:
-
- The context handle provides this ability. When a context handle
- is created and passed to the client, the DCE runtime library
- keeps track of the connection between client and server;
- this may be done in the network code as in the case of TCP,
- or by DCE-specific ping messages if a connectionless protocol is used.
- When the client dies, the server is notified and executes a "rundown"
- function to clean up its data structures.
-
- --------------------------------------------------------------
- Q 2r-09: How can a server identify the client that has called it?
-
- A:
-
- The details vary, depending on exactly what you want to
- identify about the client, but it all comes down to handles.
- The server must receive a binding handle in order receive
- information about the client. If there is not a binding
- handle in the parameter list as defined in the IDL file, then
- use the [explicit_handle] attribute in the ACF file to add
- one when building the server.
-
- If you want to identify the host machine on which the client
- is executing, simply convert the binding handle to a string
- binding using rpc_binding_to_string_binding() and then
- extract the address using rpc_string_binding_parse().
- When the server receives the handle, it contains the client
- address.
-
- If you want to identify the human user who is running the client program,
- you can get that from the authentication information in the handle.
- rpc_binding_inq_auth_client() will give you the caller's PAC,
- which contains, among other things, the principal's uuid
- and name.
-
- If you want to identify the particular client process so your
- server can keep data specific to each client, then you need
- to look into context handles as described in Q 2r-07.
-
- --------------------------------------------------------------
- Q 2r-10: Can I move idl-compiled stubs from one platform to another and
- rebuild the object files locally?
-
- A:
-
- No. You must run the IDL compiler separately on each platform.
-
- The IDL compiler builds the client and server stubs to handle
- network communication and data marshalling, which are
- platform-specific activities. Therefore the stub code is not
- portable and must be re-created on each platform. Likewise, while
- the task of the stub does not change, the set of service routines
- called from the stub may be changed by the vendor for any given
- platform. Therefore stubs for the same RPC may look very different
- on different platforms.
-
- --------------------------------------------------------------
- Q 2r-11: How are UUIDs generated?
-
- A:
-
- The DCE AES specifies the method for generating UUIDs, in case
- you want the gory details. In short, the UUID is a combination
- of the network address and current time at the moment and place
- it was generated. Assuming that network addresses are unique
- and that time never runs backwards, this guarantees that UUIDs
- really are unique.
-
- Some implementations of uuidgen use the hardware address of the
- ethernet adapter, some use the IP address of the host.
-
- It is possible to run uuidgen on machines without any network
- connection. In this case, the host must be assigned an address.
- The AES specifies a file that can hold the network address.
-
- The code for generating UUIDs is part of the publically available
- DCE source code. See Q 3.05: for information
- on obtaining the code.
-
- --------------------------------------------------------------
- Q 2r-12: How can I pass a UUID as a parameter in an RPC?
- What is the format of a uuid_t structure?
-
- A:
-
- The uuid_t structure is defined in <dce/nbase.idl>
- All you have to do is import this into your .idl file
- and pass parameters of that type all day long.
-
- Note that uuid's passed as parameters are just ordinary data.
- If you want the uuid to affect the interface or object
- in the rpc, they must be attached to the binding handle.
-
-
- --------------------------------------------------------------
- Q 2r-13: How can I pass a binding handle as an ordinary parameter in an RPC?
-
- A:
-
- The binding handle is an opaque type and cannot be marshalled
- as data. A parameter of type handle_t must be the first parameter
- and will serve to specify the binding of the RPC; an attempt
- to use a handle_t as other than the first parameter will be flagged
- as an error by the IDL compiler.
-
- To send a handle from one process to another, convert it to
- a string binding and pass the string as a parameter.
-
-
- --------------------------------------------------------------
- Q 2r-14: How do I keep my server from
- advertising all the host machine's network addresses with CDS?
-
- A:
- If a server machine has two (or more) network interfaces, it will
- have at least that many network addresses. A typical server program
- will export binding handles to CDS for every protocol sequence
- on every network interface. If some of these interfaces are unreachable
- from some clients, binding may be delayed while the client cycles
- through the useless handles.
-
- To limit a particular server,
- set the environment variables RPC_UNSUPPORTED_NETIFS and/or
- RPC_UNSUPPORTED_NETADDRS to exclude the interface or specific addresses
- that you don't want your server to use. On HP, set RPC_SUPPORTED_NETADDRS
- instead, to give a list of addresses you do want to use. Look in your
- vendor's documentation for syntax and to verify that they support this
- feature; it is not standardized by Open Group.
- You must set the environment before starting the server, of course,
- and you may have to manually remove CDS entries that are already present.
-
- --------------------------------------------------------------
- Q2r-15: How do I share type declarations between two or more IDL files?
-
- A:
- Imagine a program that uses two interfaces, in two idl files, and
- these two interfaces share many of the same structures
- which must be typedef'ed in the idl file. A C-programmer's first
- instinct would be to #include a header file in both idl files, and
- this would appear to work, because the IDL compile generally runs
- the C preprocessor. But when the application code is compiled and
- #includes both of the generated *.h files, the C compiler will
- complain about duplicated declarations of these structures.
-
- You should instead put the shared declarations in a separate .idl file,
- compile it separately with the idl compiler, and "import"
- the .idl file into all the other idl files that need it.
-
- This way, each definition will appear in exactly 1 generated .h file,
- where it will be protected by the usual #ifdef to prevent multiple
- declarations.
-
- Some shops have an explicit style guideline that says an idl file
- should contain either type definitions or function declarations,
- but not both. You might want to try it.
-
- --------------------------------------------------------------
-
- Q 2r-16: How can I control the timeout of a context handle?
- Sometimes, the context-rundown routine gets called immediately when the
- client is killed, and sometimes it takes a (relatively) long time. Why?
-
- A:
- The DCE runtime calls the context rundown routine as soon as it notices
- that the connection with the client has been lost. Exactly when the runtime
- will notice depends on the communications protocol.
-
- If the conversation is using a connection-oriented protocol like TCP,
- then the runtime depends on the protocol to notify it of a lost connection;
- if the client crashes or exits, the speed with which the server is
- notified depends on the TCP implementation and may be quick or very slow.
- If the socket is shut down gracefully, the rundown may be called
- immediately; otherwise it all depends on the timeout parameters in TCP.
- You may be able to adjust the timing by changing parameters in your
- network stack, but it will affect the whole system, not just DCE.
-
- With a connectionless protocol like UDP, the runtime generates its own
- keepalive messages to test the "connection". (Actually, they are
- "I'm Not Dead Yet" messages from the client.) If the client exits, the
- server will assume the connection is down after a number of missed
- messages.
-
- Thus the speed with which your server is notified after a client crashes
- may vary from platform to platform due to differences in TCP implementation,
- and from minute to minute on the same platform depending on whether the
- client happens to use a TCP or UDP binding handle.
-
- Moral: context rundown allows the server to clean up, but is not
- a real-time monitoring tool.
-
- --------------------------------------------------------------
- Q 2r-17: A server has moved or otherwise changed its binding information.
- How do I make the client obtain the new binding ?
- A:
- First, remember that a client must always be prepared to deal with
- stale binding handles. Before starting to make RPCs, call
- rpc_mgmt_is_server_listening() to verify the handle, and continue
- importing bindings until you get one that works.
-
- If the server information has changed recently, the information in
- the client's cache may need updating. Call rpc_ns_mgmt_set_exp_age()
- with an expiration_age value of 0 to force an update.
-
- --------------------------------------------------------------
- Performance
- --------------------------------------------------------------
- Q 2p-01: How efficient is DCE RPC?
-
- A:
-
- Performance testing at several user organizations has shown that
- DCE RPC performance is similiar to other RPC implementations when
- doing the same things. The throughput and response times for a
- series of remote procedure calls is similiar.
-
- The use of features in DCE not present in other implementations
- may consume additional time and resources. For example,
- name-based binding may required additional time, depending on the
- number of directories traversed. Using the packet integrity and
- packet privacy features of the security service can increase
- processing times as a linear function of message sizes.
-
- There are three papers providing preliminary performance data
- published in:
-
- DCE--The OSF Distributed Computing Environment,
- Lecture Notes in Computer Science #731, Springer-Verlag,
- (see Q 3.02 for ISBN)
-
-
- IBM has done quite a bit of performance testing of DCE. Many
- of the reports are available on line; go to IBM's corporate
- Web page, http://www.ibm.com, and choose the search feature to
- search for something like "dce performance". To summarize a few
- of the results in these reports:
-
- (*) RPC time increases linearly with the size of the data.
- (*) Passing a large array in one RPC call is about the same speed
- as using a pipe
- (*) Passing a large array in several RPC calls is slower than
- a single call using a pipe
- (*) The "packet integrity" security level slows the RPC, nearly
- doubling the total time for calls.
- (*) The "packet privacy" level incurs a several-fold increase in time.
- (*) RPC is slower than simply making socket calls directly.
- (*) The time spent on RPC overhead was a small fraction of the total
- processing time in a realistic business scenario.
- (*) RPC is pretty fast on Intel procesors (running OS/2).
-
-
- --------------------------------------------------------------
- Q 2p-02: What is the practical limit on the size of a DCE cell?
-
- A:
-
- Good question. There are no hard and fast answers, but there are
- some large-ish cells in operation.
-
- Certainly it is reasonable to plan on cells with thousands of
- nodes and perhaps tens of thousands of users.
-
- The University of Michigan Center for Information Technology
- Integration has done a study in which they added 50,000 entries
- to the Cell Directory and to the security registry. Their results
- are reported in technical reports 93-12 and 94-1. See Q 3.01 for
- the ftp site for CITI tech reports.
-
- Lexis-Nexis has a more recent study in which they added 400,000 accounts
- to the DCE registry. The write-up was available at their web site
- http://www.lexis-nexis.com/
- but if it is still there, you apparently must be a subscriber to see it.
-
- Several years ago
- IBM's DCE performance testing (see Q 2p-01 above for citation)
- includes load testing to simulate the environment of a large cell.
- A short, oversimplified, summary is that server machines based
- on 486/66 and P90 (running OS/2) could support the projected needs
- of a cell with 10,000 users. An informal post on Usenet claimed that
- a test on an AIX platform had reached over 700,000 users created in the
- security server.
-
- IBM's OS/390 DCE server includes modifications to the security server to
- use a better backing store so that the entire set of principals need not
- be keep in-core.
-
-
- --------------------------------------------------------------
- Q 2p-03: How much memory and disk space is required for DCE services?
-
- A:
-
- This depends on the size of the cell, the number of users,
- number of services, etc.
-
- According to a paper present by Dan Hamel of Transarc, at the
- Decorum conference in February 1994, the following can be used
- as rough guidelines:
-
- (*) Security server: 2k per principal/account
- same at replicated sites
- (*) Directory server: 10k per directory, 1k per object
- same at replicated sites
- (*) end-user machines: Each dce_login creates new credential files,
- which can build up. Space usage can range
- from less than 1k to over 100k.
-
- The security server as shipped by the Open Group keeps all security registry
- information resident in main memory, which means that the security
- host machine needs memory as well as disk.
-
- --------------------------------------------------------------
- Q 2p-04: How can I control the number of concurrent client connections
- and the size of the request queue on a server?
-
- A:
-
- The rpc_server_listen() call creates a pool of threads to
- handle incoming RPCs. The server can be actively working on
- at most this many RPCs simultaneously. The size of the pool
- is controlled by a parameter to rpc_server_listen. This is
- the primary place where you are expected to control the number
- of simultaneous connections.
-
- If you want to go deeper, into the question of what happens
- when all the server-listen threads are busy, things become
- tricky, because there are so many factors affecting the answer.
-
- If all the server threads are currently busy, incoming requests
- will be queued by the RPC runtime. There is not an explicit
- API for controlling the size of this queue. The rpc_use_protseq*()
- calls have a "max calls" parameter, but its effect is murky and
- it may be ignored completely by the implementation.
-
- If the RPC queue is full, the runtime will not accept any more
- network messages. Incoming requests will therefore be held at
- the network protocol layer, which maintains a queue of its own.
- If the network layer's queue is full then the incoming message will
- be rejected and the client will be told that it is unable to connect
- to the server.
-
-
- --------------------------------------------------------------
- Q 2p-05: My server gets a stack error when sending large objects. How
- can I avoid this?
-
- A:
-
- Each thread in a process is assigned a fixed area for its
- procedure-call stack.
- The stubs normally marshall and unmarshall parameters in space
- allocated on the thread's stack. If the parameters are large,
- the stack size may be exceeded. In most thread implementations,
- the stack size cannot be increased after the thread is created.
- For threads created explicitly by your application, you can adjust
- the size of the thread stack by setting an attribute before calling
- pthread_create().
- However, server threads are created automatically, so that method
- won't work; instead, call rpc_mgmt_set_server_stack_size() before
- starting the threads with rpc_server_listen().
-
- Another possibility is to use the [heap] attribute to have
- some parameter types marshalled on the heap instead of the stack.
-
- You should know that current implementations of the IDL compiler
- generate recursive code to marshall linked lists. Therefore, passing
- a long linked list may cause stack overflow due to all the
- recursive calls.
-
- --------------------------------------------------------------
- Q 2p-06: How do I get clients to connect to the nearest server?
-
- A:
-
- It's not easy. Currently, vanilla DCE gives essentially no help.
-
- For clients for which you have source code, you can use the
- rpc_ns_binding_lookup*() routines to search through the binding
- handles and apply some custom logic to finding a nearby server.
-
- For standard DCE services, such as CDS and security queries,
- you get a random server, which could be anywhere in the cell.
- For the security service, you might be tempted to set the
- BIND_PE_SITE environment variable and the file
- /opt/dcelocal/etc/security/pe_site to hardwire each client host
- to its nearest security replica, but this is a hack with serious
- administrative downside: if the replica goes down or is moved,
- all the associated clients must be manually updated.
-
- Individual products may provide additional help. For example
- Transarc's DCE now includes a feature that lets clients connect to the
- closest CDS server. Details at
- http://www.transarc.com/Public/Support/dce/admin_examples/directory/pref.html.
-
- --------------------------------------------------------------
- Q 2p-07: Should I choose UDP or TCP for my RPC?
-
- A:
-
- First have you considered the advantages of using all protocol sequences?
- RPCs work the same either way. DCE's implementation provides the same
- security and reliability over all communication protocols. In most cases
- the performance is about the same as well.
-
- For some applications and some platforms, there may be reasons to prefer
- one protocol over another. For instance, if your platform has a poor
- implementation of UDP, that could be a reason to prefer TCP, or vice-versa.
-
- For heavily-loaded servers, UDP is often recommended over TCP.
- In low-bandwidth networks, or when running servers under a debugger,
- TCP may be preferred.
-
- Transarc has a web page providing more information on the relative
- merits of UDP and TCP, at
-
- http://www.transarc.com/Public/Support/dce/prog_examples/rpc/tcp_and_udp.html
-
-
- --------------------------------------------------------------
- Cell Configuration
- --------------------------------------------------------------
-
- --------------------------------------------------------------
- Q 2cc-01: Is it possible for a machine to be a member of more than one DCE cell?
-
- A:
-
- No. A machine can only be in a single cell. However, it is
- possible for cells to cooperate. See the next question.
-
- DCE v1.1 will allow for "hierarchical cells", which may
- solve the problem, depending on why you want to have a machine
- in two cells.
-
- --------------------------------------------------------------
- Q 2cc-02: How do I configure cells to find each other using DNS?
-
- A:
-
- In order for a client program in cell A to find a server in cell B,
- it must be able to find the CDS server in cell B; once communication
- with CDS is established, everything else in the cell can be found.
- One of the ways to make the location of of the cell known is to
- create the proper entries in the Internet Domain Name Service (DNS).
-
- Suppose we want to make a cell available, and that the name
- of the cell is "/.../cell.mauney.com". We must create
- two DNS entries. One entry will provide the IP address of
- the machine that runs the CDS server within the cell.
- The other entry gives other details about the cell.
-
- The first entry, which advertises the location of the CDS server,
- can be either an MX or an AFSDB record type. The DCE code
- will be happy to use either one, but you as a system administrator
- have to make a choice; both possibilities have drawbacks.
- The MX record type is intended for mail exchange, so using it
- for DCE is a bit of a kludge; and if you already
- have a machine in your name with the same hostname as your cell
- name and it ever participates in e-mail, then you'll have a conflict.
- On the other hand, the AFSDB record is new and not supported by
- all nameservers; you'll need Bind version 4.9.2 or later.
-
- The MX or AFSDB record relates the cell name to a host name.
- DCE ignores the "preference" value of an MX record. With AFSDB,
- you should use sub-type 2. E.g.,
-
- cell.mauney.com. IN MX 200 tophat
-
- or
-
- cell.mauney.com. IN AFSDB 2 tophat
-
- where "tophat" is the hostname of the machine that runs the CDS master
- server.
-
- The second piece of information in DNS is a TXT record giving
- UUIDs for the CDS master replica and clearinghouse. You obtain
- the information with the command "cdscp show cell as dns", and
- copy the information verbatim into DNS. E.g.
-
- cell.mauney.com. IN TXT "1
- 44007e75-08b4-11ce-9055-08002b32b23b Master /.../cell.mauney.com/tophat_ch 43373550-08b4-11ce-9055-08002b32b23b tophat.mauney.com"
-
-
- See
- http://www.transarc.com/Public/Support/dce/admin_examples/misc/cross_cell.html
- for a description of how it works, and some troubleshooting
- hints in case it doesn't.
-
- --------------------------------------------------------------
- Q 2cc-03: Is it possible for a user in one cell to use secure services
- in another cell?
-
- A:
-
- Yes. The Access Control List (ACL) permits three entry types --
- foreign_user, foreign_group and foreign_other -- which specify the
- permissions available to users on other cells. All that is
- required for intercell access, other than physical connectivity,
- is for the two cell's security services to be configured to know
- about each other.
-
- There is a command, the rgy_edit "cell" command, that must be run, once,
- by the cell admin of the two cells that wish to communicate. After
- that, it's all transparent.
-
-
- --------------------------------------------------------------
- Q2cc-04:: How do I change the name of my cell?
-
- A:
- You don't.
-
- The cell name in embedded into too many hidden places. Live with
- the old cell name, or create a new cell and configure it to look
- like the old cell.
-
- If you haven't created your cell yet, learn this lesson and
- choose a cell name you can live with.
-
- --------------------------------------------------------------
- Q2cc-05:: How do I change the IP address of
- a host in my cell?
-
- A:
- Very Carefully.
- You need start this before changing the address of the machine.
-
- Transarc has several files of tips on the subject.
- See. http://www.transarc.com/Public/Support/dce/admin_examples/misc/ip.html.
-
-
- --------------------------------------------------------------
- Q2cc-05:: How do I do inter-cell delegation?
-
- A:
-
- Our initial answer to that question was:
- Inter-cell delegation is a poor idea from a security standpoint.
- Therefore, DCE does not implement it. That answer may have been too
- absolute. It may be better to say that DCE severely restricts delegation
- because of the security problems.
-
- Keys Botzum's Q&A
- http://www.transarc.com/~keys/encina/dce-enc-questions.htm
- says the following:
- The delegation chain of RPCs may cross only one cell boundary. This means
- that with two cells you can not cross back into the originating cell,
- and any delegation involving 3 cells will not work at all.
-
-
-
- --------------------------------------------------------------
- Q 2cc-07:: How can I find out who is currently logged in to a DCE cell?
-
- A:
- You can't.
-
- DCE does not track this information,
- does not supply any tools to help collect this information,
- does not provide any hooks in the security server to allow you
- to collect this information.
-
- Answering the question of "who is logged in" is difficult,
- in part because in the DCE architecture it is hard to decide exactly
- what the question means.
- For example, if a person is logged in to a DCE client machine,
- but his DCE tickets have expired, does that person count as logged in
- or not?
-
- If you must track who is logged in, you'll need to build
- your own service to maintain the information.
- An obvious approach is to capture login and logout events and
- report them to some central location; this requires that you be able
- to instrument all login/logout commands on hosts within your cell.
- Another approach would be a daemon that runs on each host and
- periodically notices ticket files; there are security concerns with this
- approach.
- Or you could just run "rwho" :-)
-
-
-
- --------------------------------------------------------------
- Security
-
- --------------------------------------------------------------
- Q 2s-01: Where can I find an ACL manager to include in my application?
-
- A:
-
- DCE version 1.1 includes a basic ACL manager library.
-
- HP's OODCE (DCE C++ class library) provides you with a default,
- built-in ACL Manager with the server class.
-
- Transarc's Encina (transaction monitor) product includes
- an ACL manager.
-
- Lockhart's book contains a sample ACL manager. (see Q 3.02)
-
- Hu's book on DCE Security Programming contains a sample ACL manager.
- (see Q.3.02)
-
- The code from both the Lockhart and Hu books is available on-line.
- See Q 3.07 for URLs.
-
- http://www.transarc.com/Public/Support/dce/prog_examples/security/acl_stuff/acl_stuff.html
- includes sample code for a greet-derived client/server pair where the
- server uses the DCE 1.1 ACL manager library
-
-
- --------------------------------------------------------------
- Q 2s-02: Does DCE Security interoperate with other Kerberos systems?
-
- A:
-
- Basically, no, or maybe yes, depending on what you want to do.
-
- To use authenticated DCE services, you must have credentials from
- the DCE security service; vanilla Kerberos v5 tickets aren't sufficient.
- But then, to use DCE services you must be using DCE RPC, so this
- is not really a problem.
-
- Going the other way, it is expected that a DCE security server
- can issue tickets that can be used by vanilla Kerberos applications.
- The Open Group was wary of promising this until the Kerberos v5 specs were
- published, but now that the Kerberos RFC has been published, Open Group
- anticipates guaranteeing interoperability sometime "soon".
-
- In a little more detail, the way to think about this is as follows:
-
- Kerberos offers 2 services (Authentication Service, Ticket
- Granting Service) over 1 communication mechanism (UDP port 88).
-
- DCE security offers 3 services (AS, TGS, Privilege Service) over
- 2 communication mechanisms (UDP port 88, RPC).
-
- Where Kerberos and DCE security intersect (AS, TGS over UDP port
- 88), the services are identical.
-
- DCE V1.1 supports the GSSAPI, so non-DCE services that use GSSAPI
- can be integrated with DCE security server.
-
-
- --------------------------------------------------------------
- Q 2s-03: Can I control the endpoints assigned to DCE servers?
- For example, to allow DCE clients and servers to communicate
- across a firewall?
-
- A:
-
- Yes.
-
- You can, of course, assign well-known endpoints to all your servers,
- but that is a truly bad idea, and won't work for services that you
- don't have source code for (such as CDS and the security registry).
-
- The endpoint mapper will examine the environment variable
- RPC_RESTRICTED_PORTS and choose endpoints only in that range.
- You can make the range as small as necessary, and configure your
- firewall to pass traffic only to those ports.
-
- The format of RPC_RESTRICTED_PORTS is a list of settings, separated by
- colons. Each setting is of the form protocol[lo-hi]. E.g.
-
- export RPC_RESTRICTED_PORTS=ncacn_ip_tcp[5000-6000]:ncadg_ip_udp[5000-6000]
-
-
- --------------------------------------------------------------
- Q 2s-04: Do DCE servers automatically update their long term secret keys?
-
- A:
- No.
-
- Except for exceptional circumstances, all DCE servers should
- periodically change their long-term key. However, neither the
- servers provided by DCE nor those written by you or third
- parties will do this out-of-the-box.
-
- The way to have a server update its key is by spawning a
- thread that calls sec_key_mgmt_manage_key() (which never returns under
- normal circumstances). As distributed by Open Group, DCE has no password
- expirations set, so sec_key_mgmt_manage_key() won't actually do anything.
- You may set the password expiration time or lifespan using an admin
- tool such as rgy_edit or dcecp.
-
- In 1.0.x releases, DCE only enforced passwd expiration in the clients
- (such as printing a warning in dce_login). As of DCE 1.1, however,
- the security server will no longer grant a TGT for an account who's
- password/key has expired, so servers that aren't correctly running the
- manage key code before their password expires will require
- administrative intervention to become operational again.
-
- The following table shows what the Open Group-provided servers do:
-
- cdsd -- yes; uses FILE:/krb5/v5srvtab
- dced -- yes (uses FILE:/krb5/v5srvtab and manages hosts/<machine>/self)
- dtsd -- not applicable; runs as the machine principal
- pwd_strengthd -- yes; uses FILE:/krb5/pwd_strength_tab
- secd (maintains three keys) -- not applicable
-
-
- --------------------------------------------------------------
- Q 2s-05:
- What problems might I cause by changing the expiration time
- or password lifespan in a running cell?
-
-
- A:
- DCE v1.1 will not let you authenticate (acquire a TGT) with an expired
- password. As such, if you change the "password lifespan" policy from
- "never" or a period longer than 30 days, to days, then every host
- principal, user and server account that has not (by coincidence) updated
- their password/key within the last 30 days, will be locked out. Users
- would not be able to log in, server applications would no longer be able
- to obtain credentials and the dceds would no longer be able to
- obtain/refresh their machine credentials.
-
- --------------------------------------------------------------
-
- Q2s-06: How do I begin to force password changes,
- without getting into the trouble described in the previous question?
-
- A: Set an explicit "expiration date" policy, some time in the near future.
- (Make sure it's at least 30 minutes from the current time, to give
- the key management threads time to catch the change and a couple of
- chances to make the change.) At that specified date/time, all users,
- server apps and machines should have updated their passwords/keys.
- Recover from any problems that occurred (machines down during that
- time, users forgetting...), then set the "password lifespan" policy
- field to the desired limit.
-
- --------------------------------------------------------------
- Q 2s_07: Do all versions of DCE support the sec_key_mgmt_manage_key()
- functionality in the same way?
-
- A: Unfortunately not. DCE 1.0.x releases had a limitation in
- this key mgmt call, in that it would not wake up until shortly before
- the key was due to expire (based on the expiration data that it obtained
- when the call was started or the last time through the loop after a
- change). DCE 1.1 should no longer have this problem, as the call
- wakes up every 10 minutes to see whether the expiration time has
- changed.
-
- --------------------------------------------------------------
- Q 2s_08: How can I work around the key_mgmt problem if I have older
- client machines, but DCE 1.1+ based servers?
-
- A: Preferably, upgrade them all to an DCE 1.1 or later. If this is not possible,
- manually change the keys for each older client:
- rgy_edit-> kta -p hosts/<hostname>/self -a -r
- (on each DCE 1.0.x-based client machine). Do this for any accounts in the
- default keytable, and any servers running on older versions that also use
- the sec_key_mgmt_manage_key() call.
-
-
- --------------------------------------------------------------
- Compatibility
- --------------------------------------------------------------
- Q 2c-01: Will Windows NT communicate with DCE?
-
- A:
-
- Windows NT comes with an RPC which interoperates with DCE RPC.
- Windows 95 apparently provides this interface as well.
- However, it is not quite the same as DCE.
-
- The wire-level protocol is the same as DCE RPC, so applications
- running on NT can communicate with DCE applications on other
- platforms. However, the application source code is not instantly
- portable. Microsoft changed the format of procedure names
- and moved the status result from a parameter to the function value.
- This kind of change can be covered up by a set of preprocessor
- macros, but it is a change to be dealt with.
-
- A more serious consideration is that Microsoft's RPC does not
- use the standard DCE services, such as directory service and security.
- Thus applications that cross between Microsoft RPC and DCE will have
- to make unauthenticated calls and use string bindings.
- Digital bundles a Name Service Interface Daemon (nsid) into its
- DCE products. The nsid fills in the gap and allows an NT client to
- get bindings from CDS.
-
- See the book "Distributing Applications Across DCE and Windows NT"
- for more details (see Q 3.02).
-
- The good news is that DEC and Gradient both have DCE
- products for NT. Digital has a DCE client product available
- for both Intel and Alpha architectures. Gradient has a full
- secure core product.
-
- Information on Digital's DCE on NT product is available at
- http://www.digital.com/info/Customer-Update/940412019.txt.html
- Information from Gradient can be obtained by sending email to
- info@gradient.com
- or at their Web site:
- http://www.gradient.com/products/products.htm
-
-
- --------------------------------------------------------------
-
- Q 2c-02: Can I use DCE from C++?
-
- A:
-
- Yes. First of all, since you can call C functions from C++
- you can access all the DCE services from a C++ program. But
- that will not give you the benefits of C++.
-
- There are several packages that provide a C++ interface to DCE.
- They different quite a bit in style and approach, so you'll
- need to consider them carefully in light of your own needs and
- preferences.
-
- Objtran was produced by Citibank, and is available by anonymous
- ftp at ftp://wilma.cs.brown.edu/pub/Objtran.tar.Z
-
- Hal Computer Systems developed a set of classes called DCE++.
- That part of the company was spun off into Chisholm Technologies.
- For information on DCE++, see their web page:
- http://www.chistech.com/products/dce++.html
-
- Hewlett-Packard has a product called OODCE. It is for sale,
- and currently supported only on HP-UX. For technical information
- retrieve the OSF RFC #49 (see Q 3.05); for sales
- information contact your HP sales office.
-
- DCE version 1.2.1 will include IDL support for C++. The OSF (oops,
- the Open Group) recently announced that OODCE will be adopted as
- part of DCE in a future version.
-
- Transarc's Encina v2.0 includes Encina++, C++ support for Encina and DCE.
-
-
- --------------------------------------------------------------
-
- Q 2c-03: Can I write an application that uses DCE and X11/Motif?
-
- A:
-
- Yes but there are several serious pitfalls.
-
- The X11/Xt/Motif libraries may not be thread-safe. For example,
- suppose one thread calls a function in Xt, which calls a nonthreadsafe
- malloc(), which then gets preempted. The next thread may call
- a threadsafe malloc() that comes with DCE. When control returns to
- the first malloc(), any assumptions about the state of the heap are
- invalid.
-
- Also, Motif/Xt/Xlib are not currently reentrant wrt/themselves. You can't
- have multiple threads concurrently manipulating any Motif/Xt/Xlib
- global state. Fortunately this issue is under you control when
- designing the application. X11R6 includes a thread-safe version of
- Xlib, but it will be a while yet before the vendors are all delivering
- thread-safe Motif.
-
- A related issue is that XtAppMainLoop() waits in a select() for activity,
- coupled with the fact that DCE also waits in a select() for activity.
- Unless the two are select()s are cooperating, one or the other will be
- starved. This is a platform-specific issue, you should check with your
- DCE vendor for full details.
- If it is a problem in your environment, the standard solution is to
- encapsulate the GUI in one process, the DCE client code in another process,
- and connect them with a simple IPC such as a Unix pipe.
-
- --------------------------------------------------------------
- Q 2c-04: Is DCE RPC compatible with ONC RPC?
-
- A:
-
- No. DCE and ONC both use the concept of the Remote Procedure Call,
- but the wire protocols that they use are not compatible. You will
- need to use either DCE for both client and server, or ONC for
- both client and server; both products are available for most platforms.
-
- It is possible for a single program to use both DCE and ONC.
- Thus a server could be built to server both DCE and ONC clients,
- or a gateway could be built to accept one kind of RPC and forward
- to a server of another kind.
-
-
- --------------------------------------------------------------
- Q 2c-05: Is XDR the same as, or compatible with, NDR?
- If not, how do I convert from one to the other?
-
- A:
- No
-
- (For those of you not fluent in three-letter abbreviations,
- XDR is eXternal Data Representation, the data format used on the wire
- by ONC, and NDR is Network Data Representation, used on the wire by DCE.)
- XDR and NDR use different methods for tagging data items.
-
- --------------------------------------------------------------
- --------------------------------------------------------------
-
-
- Tier 3 -- Data Management
-
-
- --------------------------------------------------------------
- Q 3.01: Where can I get online information about DCE
-
- A:
-
- First of all, the official documentation for DCE is not available
- for anonymous ftp. But there are several sites providing
- lots of other information. Here are some of the most useful:
-
- The Open Software Foundation maintains a WWW server with information
- about all the Open Group products, including DCE.
- http://www.opengroup.org/tech/dce/
- takes you directly to the DCE index.
- Highlights of the Open Group's web server include a complete list of DCE
- products, the DCE Request for Comments documents (RFCs), the
- DCE product catalog (see Q 1.04) and a
- hypertext version of the Frequently Asked Questions list.
-
- Project Pilgrim at the University of Massachussetts has a DCE homepage at
- http://info.pilgrim.umass.edu/pub/osf_dce/osf.html
- Their server provides a complete set of RFCS, searchable by http
- and also by gopher, at
- gopher://info.pilgrim.umass.edu/77/lib/.wais-sources/osf-dce-rfc.txt
- and a directory of contributed software, currently consisting of
- performance measurement utilities from Pilgrim, and book examples from
- O'Reilly&Associates.
-
- The Center for Information Technology Integration at the
- University of Michigan has several pieces of DCE information
- on their servers. The big attraction here is the set of
- CITI Technical Reports related to DCE.
- You can get to the tech-reports from the CITI web server,
- http://www.citi.umich.edu/techreports
-
- Transarc has some hints and examples available on the web.
- http://www.transarc.com/Public/Support/dce/dceIndex.html
- These are informal, practical discussions of how to handle real-world
- problems such as changing the IP address of the CDS server,
- implementing peer-to-peer RPC, handling key management, etc.
-
- Also at Transarc's Web Site, there is on-line documentation for the
- Solaris 2.5.1 DCE 1.1 product. This is the complete set of OSF DCE and DFS
- documentation with some additions for the Solaris port.
-
- Keys Botzum maintains an information page at
- http://www.transarc.com/~keys/encina/dce-enc-questions.htm
- Look for the link to his personal question and answer page, which contains
- DCE and Encina information.
-
- Intellisoft's advutorial "DCE and The Enterprise"
- is on-line and available via Intellisoft's web site
- http://www.isoft.com
-
- The PC Webopaedia http://www.sandybay.com/pc-web
- contains pointers to number of DCE-related web pages (including this FAQ),
- including magazine articles. Use the search feature to find DCE links.
-
- IBM has a support web page for DCE on AIX at
- http://service.boulder.ibm.com/dssdce
-
- --------------------------------------------------------------
- Q 3.02: What books are published on DCE?
-
- A:
-
- Documentation on DCE should be suppiled with vendor products. The
- Open Group sells complete sets of documentation. The DCE set consists of
- 14 volumes and costs $525. Documentation for version 1.1 is
- available.
- The three volumes of specifications (AES) can be purchased separately
- for $100 (plus shipping).
-
- Order documentation in the US by contacting:
-
- OSF??? Direct Channels
- Phone: 617-621-7300
- E-mail: direct@osf.org
-
-
- Contact OSF Direct in Europe, East Asia, and Africa
- at OSF's Brussels Office
-
- Open Software Foundation
- Avenue des Pleiades-laan 15
- 1200 Brussels
- BELGIUM
- Phone: +32 2 772 8888, fax: +32 2 772 9228
-
-
- Contact OSF Direct in the Pacific region at
-
- Open Software Foundation
- 11-10, Kita-Aoyama 2-chrome
- Minato-ku, Tokyo 107
- JAPAN
- Phone +813-3479-4740; fax: +813-3479-4760
-
-
-
- The DCE documentation is also published by Prentice-Hall. These
- books contain about the same material as the Open Group manuals, but
- are edited to improve the presentation.
-
-
- Introduction to DCE ISBN 0-13-490624-1
- DCE Administration Reference ISBN 0-13-643818-0
- DCE User's Guide and Reference ISBN 0-13-643842-3
- DCE Application Development Guide ISBN 0-13-643826-1
- DCE Application Development Reference ISBN 0-13-643834-2
- DCE Administration Guide
- Vol. 1, Introduction ISBN 0-13-176546-9
- Vol. 2, Core Components ISBN 0-13-176553-1
- Vol. 3, Extended Services ISBN 0-13-176561-2
- Application Environment Specification/Distributed Computing
- RPC Volume ISBN 0-13-043688-7
-
-
- Other books on DCE:
-
- Practical DCE Programming
- by Charles Knouse (Hewlett Packard)
- Prentice Hall ISBN 0-13-324419-9
- Understanding OSF DCE 1.1 for AIX and OS/2
- by Rolf Lendenmann.
- Prentice Hall, ISBN: 0-13-493750-3 (paper)
- Understanding DCE, by Rosenberry, Kenney, and Fisher
- O'Reilly, ISBN 1-56592-005-8
- Guide to writing DCE Appplications,2nd edition
- by Shirley, Hu, and Magid
- O'Reilly, ISBN 1-56592-045-7
- Distributing Applications Across DCE and Windows NT,
- by Rosenberry and Teague
- O'Reilly, ISBN 1-56592-047-3
- DCE Security
- by Wei Hu
- O'Reilly, ISBN 1-56592-134-8
- DCE: A Guide to Developing Portable Applications
- Michael T. Peterson
- McGraw/Hill (Ranade Workstation Series)
- ISBN 0079118003 (hard)
- ISBN 0079118011 (paper)
- OSF DCE: Guide to Developing Distributed Applications,
- by H. W. Lockhart, Jr,
- McGraw-Hill,(Ranade Workstation Series)
- ISBN 0-07-911481-4
- DCE--The OSF Distributed Computing Environment, Client/Server Model
- and Beyond; Proceedings of the International Workshop on DCE, 1993
- Lecture Notes in Computer Science #731, Springer-Verlag,
- ISBN 3-540-57306-2
-
- And for you German-speaking DCE-ers:
-
- DCE--Das OSF Distributed Computing Environment, Einfuerhrung und Grundlagen,
- by Alexander Schill, Springer-Verlag, ISBN 3-540-55335-5
-
-
- There are currently no books on DFS, but there
- is a recently published book on AFS, the predecessor to DFS. AFS has
- very much the same architecture and goals of DFS, though DFS uses DCE
- services throughout and most of the actual command names have been changed.
- However, the concepts of cells, filesets, and the DFS database replication
- mechanisms are practically equivalent. The book is
-
- Managing AFS: The Andrew File System,
- by Richard Campbell, Prentice-Hall, ISBN 0-13-802729-3.
-
-
- --------------------------------------------------------------
- Q 3.03: Where can I get more information about DCE and DCE-related products?
-
- A:
-
- With WWW, access the URL: "http://www.opengroup.org/tech/dce/
-
- The general response to any query of the form "Where can I get a _____ for
- DCE?" is "Contact
- direct@osf.org" (phone +1 617 621-7300).
-
- This mail list will reach the people at Open Group that maintain contacts with
- just about everbody that has a DCE product to sell. You can get a listing
- of the vendors and their products. These include DCE RPC debugging
- environments, C++ toolkits, Visual-BASIC development environments, etc.
-
- This mail list also reaches the people at Open Group that maintain the
- lists of documentation available, both from OSF, and from outside OSF,
- about DCE (and about Motif, DME, and OSF/1).
-
- Transarc maintains a mail alias,
- info-dce@transarc.com, which carries
- discussions about DCE. Send to info-dce-request@transarc.com to join the list.
- (Transarc also has a list for Encina:
- info-encina@transarc.com.)
- For information on Transarc products, send
- mail to tsg@transarc.com.
-
- For Users of DCE on MVS, there is a mailing list:
-
- mvsdce-l@psuvm.psu.edu
-
- and a Web page (under construction):
- http://dcewww.citi.umich.edu:8080/mvsdce
-
-
- --------------------------------------------------------------
- Q 3.04: What are DCE RFCs, and how can I get them?
-
- A:
-
- DCE RFCs are requests for comments for ongoing DCE development. They
- are similar in concept to the Internet RFCs. Nothing in there is
- promised from by Open Group. They are a formal way to pass ideas among DCE
- development partners.
-
- You can access them by WWW (or gopher) by:
- http://www.pilgrim.umass.edu/pub/osf_dce/RFC/rfc-index.html
-
- gopher://info.pilgrim.umass.edu/77/lib/.wais-sources/osf-dce-rfc.txt
-
-
- --------------------------------------------------------------
-
- Q 3.05: Where can I get the Public Domain version of DCE?
-
- A:
-
- In October 1994, Digital Equipment Corporation and Hewlett-Packard
- released into the public domain the RPC implementation used by DCE.
- This code includes the IDL compiler and the RPC runtime. It does
- not include any of the other services: DTS, CDS, Security, DFS.
- In fact, it is not a sufficient base for a client machine, as it
- does not include the CDS, DTS, and security clerk processes that
- are normally required.
-
- The code is available on the Internet from several servers:
-
- ftp://ftp.digital.com/pub/DEC/DCE/PD-DCE-RPC.tar.Z
-
- http://www.pilgrim.umass.edu/pub/osf_dce/contrib/PD-DCE-RPC.tar.Z
-
- http://www.osf.org/mall/dce/
-
- Be sure also to read the licensing information found in the
- same directories.
-
- Be warned that building anything from this release is not a simple
- matter. DCE uses an older draft of the Posix threads standard,
- the IDL compiler does some odd things with YACC, and there is no
- simple configuration mechanism.
-
- Jim Doyle has a DCE client package for RedHat Linux, and is working on
- porting all of DCE to Linux/FreeBSD. See:
- http://www.bu.edu/~jrd/FreeDCE/
-
- Andrew Sandoval has made a Linux port available. See:
- http://www.netwaysglobal.com/DCE/
-
- Michael Peterson's work on DCE and Pthreads for Linux is available at:
- http://www.aa.net/~mtp
-
-
- --------------------------------------------------------------
-
- Q 3.06: Is there a DCE Users Group I can join?
-
- A:
-
- Yes. Besides the Open Group itself,
- there are local DCE users groups in several areas.
- Changes in the set of users groups have proven difficult
- to track in this FAQ, so contact the Open Group to find the
- user group nearest you.
-
-
- --------------------------------------------------------------
-
- Q 3.07: Are there any example programs available on-line?
-
- A:
- Yes.
-
- The Open Group's web site includes the
- Open Software Mall, and the Mall includes a list of
-
- DCE-related free software. This is a good starting point for
- a search. All of the following links are to be found in
- the Mall.
-
- The examples from Hal Lockhart's book are available at the OG Software
- Mall. Note that you must start at the Mall homepage
- and register before you can retrieve software for the first time.
-
- The examples from the O'Reilly books (Shirley-Hu-Magid, Rosenberry-Teague,
- Hu) are available at
- ftp://ftp.ora.com/pub/examples/dce
-
- Gradient Technologies has
-
- sample PC-DCE code available at their ftp site.
-
- Transarc's Web site has several code samples.
- http://www.transarc.com/Public/Support/dce/prog_examples/progIndex.html
-
- --------------------------------------------------------------
- Tier 4 -- Acknowledgements
-
- ACK: Thanks to the following, who provided netnews and email messages
- from which this information is gleaned. All errors should be
- blamed on Jon Mauney. (Corrections are actively solicited.)
-
-
- Hal Lichtin, Open Software Foundation
- Rich Salz, Open Software Foundation
- Courtney Mark Grey, Open Software Foundation
- Walt Tuvell Open Software Foundation
- David Weisman Open Software Foundation
- Matt Thomas, Digital Equipment Corporation
- Jonathon Chinitz Intellisoft
- Nat Mishkin Atria Software
- Mark Hickey OpenVision
- Keys Botzum Transarc
- numerous others who have been accidentally omitted but
- whose contributions are highly valued.
-
-
- And special thanks to:
-
- Harold Lockhart, Jr. Locus Computing Corporation
-
- who wrote several of the answers in this FAQ.
-
-
-
- <img src="http://www.sandybay.com/pc-web/images/awards/selected.gif"
- width="68" height="63" border="0" alt="Selected by PC Webopaedia">
-
-
-
-
-
-