Pluggable Authentication Modules (PAM) |
 |
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 is 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.20
are generic HP-UX (/etc/passwd), Commercial Security, and DCE.
For 10.20, 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.20, 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.
Known Problems |
|
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.20.
The 10.20 CDE desktop does not contain updated versions of SharedPrint or
VUE. Therefore, when updating from the VUE desktop to the CDE desktop,
existing operating system versions of SharedPrint or VUE remain on the
system. This results in SharedPrint and VUE errors appearing in
swagent.log and possibly swverify.log.
The following filesets will produce a failed verify error message:
SharedPrint.SHP-ENG-A-MAN
SharedPrint.SHPRNT-CLI
SharedPrint.SHPRNT-PCL
SharedPrint.SHPRNT-SRV
VUE.VUE-RUN
VUE.VUE-HELP-INFO
VUE.VUE-MAN
VUE.VUE-RUN-AUX
|
(Non-English systems will see the localized fileset names.)
These error messages can be ignored. To ensure binary compatibility,
your 10.01 and 10.10 files will work on HP-UX 10.20.
HP CDE and Single Logical Screen (SLS) Server |
|
For 10.20, HP CDE will have 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:
dtgreet - login screen and sub-windows
dtwm - initial front panel placement, move feedback window,
other dialogs
dthello - placement of copyright text
dtsession - logout confirmation dialog, screen lock
libDtSvc - action dialogs, errors, prompts
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:
void
parseXnScreensFile(slsRows, slsColumns)
int *slsRows;
int *slsColumns;
|
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:
singleLogicalScreenX:
singleLogicalScreenY:
|
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
*singleLogicalScreenX: 2
*singleLogicalScreenY: 1
|
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:
/etc/dt/config/<LANG>/Xresources
/usr/dt/app-defaults/<LANG>/Dt
|
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:
dtgreet
dthello
dtwm
dtsession
|
Printable version
