DCE and DFS for Linux Release Notes - Software Version 2.3 - Revised January, 2004
THIS DOCUMENT AND THE SOFTWARE DESCRIBED HEREIN ARE FURNISHED UNDER A SEPARATE LICENSE AGREEMENT, AND MAY BE USED AND COPIED ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE INCLUSION OF THE COPYRIGHT NOTICE BELOW. TITLE TO AND OWNERSHIP OF THE DOCUMENT AND SOFTWARE REMAIN WITH ENTEGRITY SOLUTIONS CORPORATION AND OR ITS LICENSORS.
The information contained in this document is subject to change without notice.
ENTEGRITY SOLUTIONS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THE SOFTWARE, DOCUMENTATION AND THIS MATERIAL, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Entegrity Solutions shall not be liable for errors contained herein, or for any direct or indirect, incidental, special or consequential damages in connection with the furnishing, performance, or use of this material.
Use, duplication or disclosure by the Government is subject to restrictions as set forth in Entegrity's standard commercial license agreement and is commercial computer software and documentation pursuant to Section 12.212 of the FAR and 227.7202 subparagraph (c) (1) (i) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013.
Entegrity and Entegrity Solutions are registered trademarks of Entegrity Solutions Corporation.
Kerberos is a trademark of Massachusetts Institute of Technology. Linux is a registered trademark of Linus Torvalds. UNIX is a registered trademark of The Open Group. The Open Group is a trademark of The Open Group. DCE is copyrighted by The Open Group and other parties. Red Hat, RPM, and all Red Hat-based trademarks and logos are trademarks or registered trademarks of Red Hat, Inc. Other products mentioned in the document are trademarks or registered trademarks of their respective holders.
Copyright © 2004 Entegrity Solutions Corporation & its subsidiaries. All Rights Reserved.
Entegrity Solutions Corporation, 410 Amherst Street, Suite 150, Nashua, NH 03063, USA
These Release Notes contain the following sections:
1. Introduction
2. New Features in v2.3
3. Prerequisites
4. Problems Fixed in this Release
5. Known Problems and Restrictions
6. Notes on Operation
7. Notes for DCE Application Developers
8. Product Documentation
9. Obtaining Technical Support
10. Contacting Entegrity Solutions
This document provides release information for Entegrity Solutions® DCE for Linux® and DFS for Linux software. It describes corrections to known problems, known problems and restrictions, and corrections to documentation. Entegrity Solutions recommends that you read this document before installing and using the software.
NOTE: If you have an evaluation copy, it will not run after a set period of time. If you want to continue to use the product after that time, contact our Sales department (DCESales@entegrity.com).
Please read the product licensing agreement contained in the License.txt file located at the same level as the readme file on the product CD, or in /opt/dce/License.txt after the product has been installed.
This release contains a DCE Client, DFS Client, DCE Server, DFS Server, and application development kit (ADK) only.
This version supports Red Hat Linux v9.0 and Red Hat Enterprise Linux v3.0.
This section lists the hardware and software prerequisites for using the product.
To perform the installation from media, you must have a CD-ROM drive for reading the distribution media
You must know how to mount the CD-ROM on the CD-ROM drive.
This version of DCE supports:
Entegrity DFS uses loadable kernel modules instead of software that requires modification and rebuilding of the kernel.
Entegrity DCE was built using the following packages. If you are using a newer version of any of these packages in which the library version numbers have been changed, you may need to install the older version before you install Entegrity DCE. After installing Entegrity DCE, install the newer package, if desired.
Packages needed for DCE Client only:
DCE ADK
DFS Client (dfsrts)
For the most current requirements you can also run rpm and note any installation errors.
If you are missing any packages:
A full installation of DCE and DFS for Linux consumes approximately 120MB of disk space.
A DCE client configuration (consisting of dced, cdsadv, one cdsclerk, and dtsd) consumes approximately 25 MB of swap space.
You must have superuser (root) privileges on the system on which you are installing DCE and DFS.
4. Problems Fixed in this Release
The following problems have been fixed in this release:
5. Known Problems and Restrictions
5.1 Known Problems with dcecp
The following problems with dcecp exist in this release.
5.1.1 Commands That are Inoperative
Due to a problem in the underlying OSF code, the following dcecp commands do not work in this release:
If you unconfigure a CDS replica, that machine cannot be re-configured as a replica immediately unless the master Security Server is restarted. This is only a problem while the old machine's cds-server credential is still valid on the master server, typically about 2 hours. The workaround is to restart the master Security Server, or wait the 2 hours for the ticket to expire.
This version of DCE supports:
This version does not support SuSE Linux.
For information on building a custom kernel module for other distributions, see the Entegrity DCE and DFS for Linux Installation and Configuration Guide, or the file /opt/dcelocal/lib/modules/README.
5.4 Filename Completion with bash
When using bash, filename completion does not work if there is a ":" (colon) in the path, as in /:/test or /.:/hosts. This is because the bash shell removes the ":" during the path resolve process.
The workaround is to escape the ":" with "\" (backslash), as in /\:/test.
5.5 Starting Servers with dcecp/dced
The current implementation of DCE for Linux has been ported to linuxThreads, which has several deficiencies due to the process-per-thread implementation. Asynchronous signals are not sent to the thread/process performing a sigwait, and when a thread forks, its parent process is not the main thread, but the thread which did the fork.
The former deficiency has been handled by wrapper code. The latter problem means that servers which are started by dced will end up being owned by the init process as their parent thread which created them dies. Thus stopping and starting servers via dcecp/dced will not work properly in this release of the product.
5.6 Known Problem with the passwd_export Command
When the execution of the passwd_export command is interrupted, this process leaves the /etc/passwd and the /etc/group in an unusable state.
5.7 Use STDERR Instead of STDOUT with dcesetup
The dcesetup utility uses output from dcecp commands to verify that certain interfaces are running. When Serviceability via the routing file is turned on, dcesetup can successfully bring up all the daemons only if STDERR is specified instead of STDOUT.
5.8 File Scanner Utility (updatedb) Incompatibility
The default Red Hat Linux installation includes a package called slocate. This package includes a file scanner updatedb, which, by default scans the DFS file system. It is adviseable to either disable this utility or modify the configuration file so that it does not scan your dcedfs file system.
5.9 Problem using KDE Screen Lock Applet
Starting with KDE version 3.0.5a, the permissions on /usr/bin/kcheckpass have been modified. They are not longer 4755 (setuid root). This causes problems in the use of PAM and PAM Modules by kcheckpass. The result is that if you are using the pam_dce package for integrated login to DCE, you cannot unlock a screen that has been locked using the KDE Screen Lock applet. You can either use the XFree86 utility xscreensaver in place of the KDE Screen Lock applet, or you can re-enable the functionality in KDE by modifying permissions on the file /usr/bin/kcheckpass to 4755. Note that this is a potential security hole, and you should do so only if you understand the ramifications.
6. Notes on Operation
6.1 Setting Environment Variables in setup_state
The setup_state file sets site parameters at configuration time. You can set certain site-specific parameters for DCE and DFS by setting environment variables before running DCE or DFS. These parameters fall into two general catagories: those that modify the behavior of the cell, and those that modify daemon runtime behavior. Those that affect the cell must be set before the cell is initially configured. Those controlling daemons must be set prior to starting the daemons each time.
All of these parameters are modified via environment variables, as set in the file /opt/dcelocal/etc/setup_state. The setup_state file and dfs daemon manpages explain requirements and syntax.
You may add other behavior-modifying variables as you need them, as long as DCE or DFS supports them. Currently, the set of parameters you can change in this way include the following.
Variables that Modify the Behavior of the Cell
These environment variables modify cell creation, and are only used when creating a new cell:
PERSON_LOW_UID="default" Sets lowest Unix ID for new principals at cell creation
GROUP_LOW_UID="default" Sets lowest Unix ID for new groups at cell creation
Variables that Modify Daemon Runtime Behavior
These environment variables modify runtime behavior, and are used each time DCE and DFS start.
RPC_SUPPORTED_NETADDRS="" Restricts supported network addresses for RPC operations.
RPC_UNSUPPORTED_NETIFS="" Prevents RPC from using listed network interfaces
RPC_RESTRICTED_PORTS="" Causes RPC to restrict use of communication ports to those listed
RPC_RESTRICTED_SERVER_PORTS="" Causes servers to only advertise on these ports
DFSD_OPTS="" Passes options to dfsd at startup. (see dfsd man page)
DFSBIND_OPTS="" Passes options to dfsbind at startup. (see dfsbind man page)
DFSFXD_OPTS="-mainprocs 7" Passes options to dfs fxd daemon at startup. (see fxd man page)
6.2 Using Shortened Forms of dcecp Directory Command
Some Linux machines include the DOS-compatibility command dir. If this command is in your path, dcecp will try to execute this command first when you use the shortened form dir of the dcecp directory command. This causes dcecp to appear to be failing and the "No such file or directory" error appears.
For example, the following command will fail if the DOS-compatibility dir command is in your path:
However, the following abbreviation of the command, or or any of the longer forms, up to and including directory, will work
dcecp -c dire show /.:/hosts
6.3 Configuring Networks Using Only UDP
The dcesetup utility defaults to using the TCP protocol. If your network uses only UDP, before running dcesetup, you must override this setting.
You can do this in one of two ways:
CONFIG_PROTSEQ="ncadg_ip_udp"
The following notes are for DCE application developers who want to use Linux threads in their applications.
LinuxThreads is an implementation of the Posix 1003.1c thread package for Linux, but it is missing many features of Posix threads, making it not yet robust enough to use exclusively in place of the existing DCE threads structure. Since glibc is made thread-safe through internal hooks to LinuxThreads, Entegrity DCE must co-exist with LinuxThreads. Using strictly CMA threads is not a viable solution.
NOTE: There have been several initiatives in the Linux community to solve this problem. NGPT recently gave way to NPTL in hopes of helping the standard along, and it appears that the functionality of the next (2.5 development, 2.6 production) kernel will have made many advances in enabling a Posix-conforming threads library to be successful. The solution is to map DCE pthread features onto LinuxThreads features as closely as possible. Unfortunately, some Posix and DCE pthread features do not map easily onto LinuxThreads features.
Specific problem areas in developing DCE applications that use Linux threads are as follows:
Process pid
To have a consistent pid, user programs should call pthread_getpid() which returns the pid of the main process. This requires that all getpid() calls be changed to pthread_getpid(). pthread_atfork() is attached to reassign this value in forked children as well as resetting any utility objects.
Multithread Test Problem
There is no given way for a process to tell whether it has become multithreaded in LinuxThreads. Therefore, you must always assume that a DCE threads process is multi-threaded.
Utility Signals
It was necessary to allocate some rt signals in order to implement some of the functionality. This was done by using the glibc internal __libc_allocate_rtsig() routine.
fork() Problem
When a fork() is done in a LinuxThreads thread, the parent process becomes the thread which did the fork() instead of the main thread. Any wait() call must be done in that same thread. Developers must reprogram any fork() calls for service threads to a special dce_pthread_clone_np() call which creates a monitor thread to be the parent, and any wait() calls must also be reprogrammed to call dce_pthread_wait_np() which execute in the context of the monitor thread.
This requires that all fork() calls which are to be monitored by wait() calls be re-programmed to use pthread_clone_np(), and that all corresponding wait() calls be translated to pthread_wait().
An rt signal is allocated if this functionality is activated.
Detach Problem
DCE threads specifies that there can be multiple pthread_join()ers to a thread and that the handle is released by pthread_detach(). LinuxThreads specifies that there can be only one pthread_join(), and the handle is released after pthread_join() or pthread_detach().
To provide the DCE pthread functionality, a data structure is allocated for each user-created DCE thread, kept in a list as well as a thread-specific pointer, and is only released when the pthread_detach is done. A hread-specific data key is allocated.
Signal Mask Problem
The LinuxThreads sigwait() is documented to work properly only when all the other threads have the associated signals blocked.
Termination signals are normally sent to the main thread. If the sigwait() for these signals is being done in a sub-thread, the signal must be caught in the main thread and resent to the sigwait thread.
This means that even though the sigmask for all threads except the sigwait() thread should block that signal, the sigmask for the main thread must have that signal unblocked to allow this signal forwarding to function. But that means that any sub-threads spawned off from the main thread will also have that signal unblocked.This cannot be solved without application cooperation.
At present, pthread_sigmask() does not set the mask for the main thread. See below for restrictions.
Signal Problem
Signals are delivered to the thread with the pid specified in the kill() instead of the sigwait() thread. Thus, we need to unblock the pertinent signals in the main thread and install handlers which will forward the signals to the appropriate pthread_sigwait() thread.
This requires the following of application developers:
Exceptions
To catch exceptions, it is necessary to attach to signal vectors and deliver the exception to the appropriate thread. All the important ones are synchronous, and so go to the thread which caused the signal.
This requires that application developers do not install signal handlers for these signals:
Cancel State/Type
DCE threads has states for synchronous and asynchronous cancels, whereas LinuxThreads has a cancel type of synchronous or asynchronous and a single cancel state.
To maintain things correctly, we return non-standard old states which can be used to restore the original combination. User programs must use a state push/pop regime, saving and restoring the old state on completion of activity.
glibc 2.3 Problem
With glibc 2.2, pthread services were accessed through dynamic binding of symbols to libpthread.so. In glibc 2.3, libpthread.so provides a call vector to glibc which re-routes calls bound to glibc through this vector to libpthread.so. As a result, one cannot depend on dynamic binding to intercept pthread calls. There is no legal way to know what is being done by direct calls to LinuxThreads.
Sigsetjump()
To get the proper definition for sigsetjump(), one of the following must be defined on the compile line:
The complete set of electronic installation, configuration, release notes, and other documentation is available on the Entegrity Technical Support web at:
The documentation is organized as follows:
For support of an evaluation copy of this product, you may contact Entegrity Technical Support by sending email to support@entegrity.com.
If you purchased your DCE product directly from Entegrity Solutions Corporation, you are entitled to 30 days of limited technical support beginning on the day the product is expected to arrive.
You may also purchase a support plan that entitles you to additional services. You must register prior to receiving this support. For details, refer to the customer support information package that accompanied your shipment or refer to the Technical Support area of http://support.entegrity.com. The web site also contains online forms for easy registration.
If you purchased DCE from a reseller, please contact the reseller for information on obtaining technical support.
The contact information in this table may change. For the most up-to-date information, see our contact page on the Entegrity Solutions web site: http://www2.entegrity.com/corporate/offices.shtml.
| Contact | Address | Phone/Fax/Email |
|---|---|---|
| Entegrity Product and Sales Information | Entegrity Solutions Corporation
410 Amherst Street, Suite 150 Nashua, NH 03063 USA |
Email: sales@entegrity.com
Web: www.entegrity.com Tel: +1-603-882-1306 ext.2700 Toll Free (US): 1-800-525-4343 ext. 2700 Fax: +1-603-882-6092 |
| Technical Support | Entegrity Solutions Corporation
410 Amherst Street, Suite 150 Nashua, NH 03063 USA |
Email: support@entegrity.com
Web: support.entegrity.com Tel: +1-603-882-1306 ext. 2702 Toll Free (US): 1-888-368-3555 ext. 2702 Fax: +1-603-882-6092 |
| Documentation Comments and Suggestions | Email: docs@entegrity.com
|
|
| Other Inquiries | Entegrity Solutions Corporation
410 Amherst Street, Suite 150 Nashua, NH 03063 USA |
Email: info@entegrity.com
Web: www.entegrity.com Tel: +1-603-882-1306 Toll Free (US): 1-800-525-4343 Fax: +1-603-882-6092 |
To make comments or ask for help, contact support@entegrity.com.
Copyright © 2001-2004 Entegrity Solutions Corporation &
its subsidiaries
All Rights Reserved.