|
|
United States-English | |
|
|
 |
|
Release Notes for HP-UX 10.30: HP 9000 Computers > Chapter 2 Major Changes for HP-UX 10.30
HP Common Desktop Runtime Environment (CDE 1.0) |
|
|
This section discusses CDE topics that are relevant for 10.30. As of 10.30, CDE, the new industry standard UNIX desktop, replaces HP VUE. CDE provides these standard desktop applications:
The design of the CDE desktop incorporates and enhances many HP VUE features. Although the CDE desktop has a similar appearance to HP VUE, there are important differences. The differences include:
The CDE development environment provides an application programming interface for many of the desktop components. The user's LANG environment variable must match the locale specified for a given help volume to print or build the volume correctly. The locale associated with a help volume is set using the LanguageElementDefaultLocale entity declaration, or using a combination of the LanguageElementDefaultLocale and LanguageElementDefaultCharset entity declarations. If the locale is not specified for a help volume, the value of the LANG environment variable is used. For more information, refer to the CDE Help System Author's and Programmer's Guide (part number B1171-90109). The VUEtoCDE application provides a way to migrate personal and system-wide HP VUE customizations to the CDE desktop. VUEtoCDE is included with the HP-UX 10.10 operating system. When upgrading your HP VUE environment to CDE, install CDE and the VUEtoCDE product from the operating system media. The VUEtoCDE application is installed in the /opt/Migration directory. Refer to HP CDE Getting Started Guide (part number B1171-90104) for instructions for migrating HP VUE customizations to CDE using VUEtoCDE. Your CDE session must have access to CDE font aliases to run properly. Typically, these aliases are installed with the fonts provided with your X server. However, when running CDE as a remote session using the command
or running CDE from an X terminal, it is possible that the font aliases may not be available to the X server. This can happen when the fonts on the server are from a prior release of HP-UX or from another vendor. In this situation, you may see fonts that do not work correctly with the local language you have selected. Fortunately, CDE provides "backup" CDE font aliases that your X server can use. These are located in the directory
This location must also contain a fonts.dir file. This file is required by the X server to use the font aliases mechanism. If you are running CDE remotely, your system administrator can cause the CDE font aliases to be used by setting up a font server to run on the system hosting CDE, making that font server use the CDE font aliases for the language you choose. For example, if you want to work in Japanese EUC (locale name ja_JP.eucJP), a font server should be started on the CDE system using this command:
In the font server's configuration file (the default configuration file is /etc/X11/fs/config), make sure the CDE font alias directory is contained in the catalogue definition. For example, to support a user running CDE in Japanese EUC, the font server's configuration file might contain the following:
Alternatively, your system administrator can copy the fonts.alias files from the CDE host system to your local system and incorporate them into your X server's fonts.alias file. When you log into the CDE desktop, you can select the language (or locale) that you want to use for your session. A list of languages is displayed when you click the Option button in the login screen. If you change the language you are using between CDE sessions, previously saved local language customizations may conflict with your new language session. For example, suppose you log in with language ja_JP.eucJP and create Japanese workspace names. You then save the session when you exit the desktop. Suppose the next time you log in, instead of choosing ja_JP.eucJP, you select German, de_DE.iso88591. The desktop will attempt to display the Japanese workspace names using fonts appropriate for the German language. The workspace names will be unreadable. This conflict results only if you change between two languages that use different coded character sets. You can change from either C or English locale without difficulty. Likewise, you can switch between similar locales, such as French and German, which are both Western European locales. Any personal customizations that contain local language characters can cause similar symptoms as that described above. Personal session customizations are saved in your $HOME/.dt directory. If you want to select a language that is different from your previously saved session, you should first start CDE in a fail safe session. From the terminal window provided, remove the files that contain local language text. Files that might contain local language characters include:
If you are not sure what files contain local language characters, remove the directory $HOME/.dt/session using this command:
This causes a default session to be invoked when you log in with the new language. In addition, you should remove any help files accessed with the prior local language by executing:
Labels and comments in action definitions can also include localized data. If so, the action labels need to be modified to be readable in the new language selected for your CDE session. User-defined actions are located in $HOME/.dt/types/*.
The CDE limitation is as follows:
"Creating an Action that Runs as a Different User" in Chapter 10 has this addition: When invoking an action that runs as a different user, make sure that the specified user has access to all resources required to complete the action. This includes, but is not limited to, the following:
In Chapter 5, the topic "Configuring the ToolTalk Database Server" includes the following information: The tooltalk database/naming service ttdbserver relies on a special undocumented inetd state called swait, which is specified in the inetd.conf file. This state is not subject to the usual HP security file checks. System administrators should not place entries referring to the ttdbserver service in the /var/adm/inetd.sec file because they will be ignored. This addendum clarifies CDE's support of NFS mounts, as described in HP CDE Getting Started Guide - Addendum for HP-UX 10.30 and related HP CDE manuals. CDE fully supports all persistent mounts created by mount(1M) as long as they conform to the already documented "file-name consistency" guidelines. CDE only supports temporary mounts created by automount(1M) when created using the special map mode -hosts, again with the "file-name consistency" guidelines applied. CDE will not reliably work with any of the other automount(1M) map modes because the CDE file name mapping code cannot reliably parse or cache the combination of temporary symbolic links and temporary NFS mounts created by automount(1M). When using the -hosts mode of automount(1M) for a mount point other than /net, the DTMOUNTPOINT environment variable must be set. In Chapter 2, the topic "To Execute Additional Commands at Logout", contains an incorrect pathname. The task should read:
Chapter 4, "Maintaining Application Information" of the CDE ToolTalk Programmer's Guide (part number B1171-90126) contains a table with an incorrect path name. The system database location specified in Table 4-1 should read:
PAM is the new industry standard integrated login framework. The PAM framework is used by system entry components, such as dtlogin, to authenticate users logging into the system. In HP-UX 10.20, PAM was introduced to be used only by CDE authenticating components. Currently, non-CDE authenticating components, such as login and ftp, continue to use the HP proprietary integrated login framework. These authenticating components will be gradually modified to use PAM in future releases, thus obsoleting HP ILOGIN framework. The PAM framework is used for easy integration of additional security technologies into HP-UX system entry commands, such as dtlogin. The security technologies being integrated for HP-UX 10.30 are generic HP-UX (/etc/passwd), Commercial Security, and DCE. For 10.30, CDE components (dtlogin, dtsession, and dtaction) will use PAM to authenticate users, as well as to establish user credentials (for example, for DCE). For 10.30, CDE components are also capable of authenticating users using the commercial security databases. The CDE users on systems belonging to DCE cells will be able to authenticate themselves with the DCE registry and obtain DCE credentials at the login time. System administrators can require CDE users to conform to the security policies enforced in the trusted system databases. A new configuration file /etc/pam.conf is used to determine usage of security mechanisms to authenticate users. The presence of PAM and its configuration file will not be noticed on systems configured to use generic HP-UX-based user authentication (/etc/passwd) or commercial-security based user authentication. For those systems intending to use DCE integrated login functionality within CDE, the auth.adm utility will create the desired configuration file that is functionally equivalent to the corresponding ILOGIN auth.conf file created for HP-proprietary integrated login framework. Refer to the pam.conf(4) and pam(3) manpages for additional information. The HP-UX vacation program does not support the $SUBJECT macro. Vacation mail functionality is described in Chapter 8 of the CDE User's Guide under the topic "To Send an Automatic Message (Vacation Mail)". The known problem in 10.10 of changing word wrap mode is not applicable to 10.30. For 10.30, HP CDE has built-in support for the Single Logical Screen (SLS) server. The implication of this change is that on an SLS-enabled server, dialogs displayed by CDE clients that center themselves on the screen will instead center themselves on a particular monitor as opposed to the center of the "screen". The CDE clients have been changed to understand SLS configuration. How clients respond to x,y resources also changed. By default, the clients will put the windows on one physical screen. If this is not desired, the resources are available to change this behavior. Changed CDE clients are:
To determine whether a display is an SLS display, the same method used by the server to determine whether a display was set up for SLS is used. That is, examine the property for SLS on the root window to see if it is configured. An API call is set up in DtSvc which passes back the number of rows and columns supported in the SLS configuration. If these values return 0, the display is not an SLS display. The function definition is:
Now that there is a function that determines whether a display is in SLS mode, the correct clients are changed to use this function and perform the appropriate action if running on an SLS display. The best way to determine which monitor to center on was by way of resources. What was done for each client that needed to 'center' dialogs was to define two new resources for each client:
The clients that had these resources added to are:
The logic for these two resources follows the 'X' standard mechanism for assigning its' coordinates (that is, x,y where 0,0 is the Upper Left hand corner of the screen). For example, if an SLS display is configured with four monitors such that it is layed out 2 by 2 and the user specifies
the clients would center its dialogs on the upper right-hand monitor. The layout for the 2 by 2 setup would be:
To center the Front Panel, the logic used is to center on the '*singleLogicalScreenX:' location at the bottom of all the monitors. Because the Login Manager uses Xresources to define its' resources, to set up a CDE session for SLS, you must modify these two files:
Now there is a mechanism to determine whether a display is an SLS display (parseXnScreensFile()) and has resources to support placement of centering of dialog, code changes were made in clients to force the dialogs to the correct location. The clients modified are:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
