The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Интерактивная система просмотра системных руководств (man-ов)

 [Cписок руководств | Печать]

xdm (1)
  • >> xdm (1) ( Solaris man: Команды и прикладные программы пользовательского уровня )
  • Ключ xdm обнаружен в базе ключевых слов.
         xdm - X Display Manager with support for XDMCP, host chooser
         xdm [ -config configuration_file ] [ -nodaemon  ]  [  -debug
         debug_level   ]  [  -error  error_log_file  ]  [  -resources
         resource_file  ]  [  -server  server_entry  ]   [   -session
         session_program ]
         Xdm manages a collection of X displays, which may be on  the
         local  host or remote servers.  The design of xdm was guided
         by the needs of X terminals as  well  as  the  X  Consortium
         standard XDMCP, the X Display Manager Control Protocol.  Xdm
         provides services similar to those provided by  init,  getty
         and  login  on character terminals: prompting for login name
         and password, authenticating the user, and running a  ``ses-
         A ``session'' is defined by the  lifetime  of  a  particular
         process;  in the traditional character-based terminal world,
         it is the user's login shell.  In the xdm context, it is  an
         arbitrary  session  manager.  This is because in a windowing
         environment, a user's login shell process  does  not  neces-
         sarily  have  any terminal-like interface with which to con-
         nect.  When a real session manager is not available, a  win-
         dow  manager  or  terminal emulator is typically used as the
         ``session manager,'' meaning that termination of  this  pro-
         cess terminates the user's session.
         When the session is terminated, xdm resets the X server  and
         (optionally) restarts the whole process.
         When xdm receives an Indirect query via XDMCP, it can run  a
         chooser  process  to  perform an XDMCP BroadcastQuery (or an
         XDMCP Query to specified hosts) on behalf of the display and
         offer  a  menu  of  possible  hosts that offer XDMCP display
         management.  This feature is useful with X terminals that do
         not offer a host menu themselves.
         Because xdm provides the first  interface  that  users  will
         see,  it is designed to be simple to use and easy to custom-
         ize to the  needs  of  a  particular  site.   Xdm  has  many
         options,  most  of  which  have reasonable defaults.  Browse
         through the various sections of  this  manual,  picking  and
         choosing  the  things  you  want  to change.  Pay particular
         attention  to  the  Session  Program  section,  which   will
         describe how to set up the style of session desired.
         xdm is highly configurable, and most of its behavior can  be
         controlled  by  resource files and shell scripts.  The names
         of these files themselves are resources read from  the  file
         xdm-config or the file named by the -config option.
         xdm offers display management two different  ways.   It  can
         manage  X servers running on the local machine and specified
         in Xservers, and it can manage remote X servers (typically X
         terminals)  using XDMCP (the XDM Control Protocol) as speci-
         fied in the Xaccess file.
         The resources of the X clients run by xdm outside the user's
         session,  including  xdm's own login window, can be affected
         by setting resources in the Xresources file.
         For X terminals that do not offer a menu  of  hosts  to  get
         display  management  from, xdm can collect willing hosts and
         run the chooser program to offer the user  a  menu.   For  X
         displays  attached  to  a  host,  this step is typically not
         used, as the local host does the display management.
         After resetting the X server, xdm runs the Xsetup script  to
         assist in setting up the screen the user sees along with the
         xlogin widget.
         When the user logs in, xdm runs the Xstartup script as root.
         Then xdm runs the Xsession script as the user.  This  system
         session  file  may  do some additional startup and typically
         runs a script in the user's home directory.  When the  Xses-
         sion script exits, the session is over.
         At the end of the session, the Xreset script is run to clean
         up, the X server is reset, and the cycle starts over.
         The file  /usr/openwin/lib/X11/xdm/xdm-errors  will  contain
         error  messages  from  xdm  and anything output to stderr by
         Xsetup, Xstartup, Xsession or Xreset.  When you have trouble
         getting  xdm  working, check this file to see if xdm has any
         clues to the trouble.
         All of these options, except -config itself, specify  values
         that  can  also  be  specified  in the configuration file as
         -config configuration_file
              Names the configuration file, which specifies resources
              to      control      the      behavior      of     xdm.
              /usr/openwin/lib/X11/xdm/xdm-config  is  the   default.
              See the section Configuration File.
              Specifies   ``false''   as   the    value    for    the
              DisplayManager.daemonMode  resource.   This  suppresses
              the normal daemon behavior, which is for xdm  to  close
              all file descriptors, disassociate itself from the con-
              trolling terminal, and put  itself  in  the  background
              when it first starts up.
         -debug debug_level
              Specifies     the     numeric     value     for     the
              DisplayManager.debugLevel  resource.   A non-zero value
              causes xdm to print lots of debugging statements to the
              terminal;        it       also       disables       the
              DisplayManager.daemonMode resource, forcing xdm to  run
              synchronously.   To interpret these debugging messages,
              a copy of the source code for xdm is  almost  a  neces-
              sity.   No  attempt  has  been  made  to rationalize or
              standardize the output.
         -error error_log_file
              Specifies the value for the DisplayManager.errorLogFile
              resource.   This  file contains errors from xdm as well
              as anything written to stderr by  the  various  scripts
              and programs run during the progress of the session.
         -resources resource_file
              Specifies the value  for  the  DisplayManager*resources
              resource.   This  file  is loaded using xrdb to specify
              configuration parameters for the authentication widget.
         -server server_entry
              Specifies  the  value  for  the  DisplayManager.servers
              resource.   See  the section Local Server Specification
              for a description of this resource.
         -udpPort port_number
              Specifies the value for the  DisplayManager.requestPort
              resource.   This  sets  the  port-number which xdm will
              monitor  for  XDMCP  requests.   As  XDMCP   uses   the
              registered  well-known  UDP  port  177,  this  resource
              should not be changed except for debugging.
         -session session_program
              Specifies  the  value  for  the  DisplayManager*session
              resource.   This  indicates  the  program to run as the
              session after the user has logged in.
         -xrm resource_specification
              Allows an arbitrary resource to  be  specified,  as  in
              most X Toolkit applications.
         At many stages the actions of xdm can be controlled  through
         the  use  of  its  configuration  file,  which  is  in the X
         resource format.  Some resources modify the behavior of  xdm
         on  all displays, while others modify its behavior on a sin-
         gle display.  Where actions relate to  a  specific  display,
         the  display name is inserted into the resource name between
         ``DisplayManager'' and the final resource name segment.
         For local displays, the resource name and class are as  read
         from the Xservers file.
         For remote displays, the resource name is what  the  network
         address  of  the  display resolves to.  See the removeDomain
         resource.  The name must match exactly; xdm is not aware  of
         all  the  network  aliases that might reach a given display.
         If the  name  resolve  fails,  the  address  is  used.   The
         resource class is as sent by the display in the XDMCP Manage
         Because the resource manager uses  colons  to  separate  the
         name  of  the  resource  from its value and dots to separate
         resource name parts, xdm substitutes  underscores  for  both
         dots  and  colons  when  generating  the resource name.  For
         example, DisplayManager.expo_x_org_0.startup is the name  of
         the  resource  which  defines the startup shell file for the
         ``'' display.
              This resource either specifies  a  file  name  full  of
              server  entries, one per line (if the value starts with
              a slash), or a single server entry.   See  the  section
              Local Server Specification for the details.
              This indicates the UDP port number which  xdm  uses  to
              listen for incoming XDMCP requests.  Unless you need to
              debug the system, leave this with its default value  of
              Error output is normally directed at  the  system  con-
              sole.   To  redirect  it,  set  this resource to a file
              name.  A method to send these messages to syslog should
              be developed for systems which support it; however, the
              wide  variety  of  interfaces  precludes  any   system-
              independent  implementation.   This  file also contains
              any output directed to stderr by the Xsetup,  Xstartup,
              Xsession  and Xreset files, so it will contain descrip-
              tions of problems in those scripts as well.
              If the integer value of this resource is  greater  than
              zero,  reams  of debugging information will be printed.
              It also disables daemon mode, which would redirect  the
              information  into  the  bit-bucket, and allows non-root
              users to run xdm, which would normally not be useful.
              Normally, xdm attempts to make  itself  into  a  daemon
              process unassociated with any terminal.  This is accom-
              plished by forking and leaving the  parent  process  to
              exit,  then  closing file descriptors and releasing the
              controlling terminal.  In some environments this is not
              desired  (in particular, when debugging).  Setting this
              resource to ``false'' will disable this feature.
              The filename specified will be created  to  contain  an
              ASCII  representation of the process-id of the main xdm
              process.  Xdm also uses file locking on  this  file  to
              attempt  to  eliminate  multiple daemons running on the
              same machine, which would cause quite a bit of havoc.
              This is the resource which controls  whether  xdm  uses
              file  locking  to  keep  multiple display managers from
              running amok.  On System V, this uses the lockf library
              call, while on BSD it uses flock.
              This names a directory under which xdm stores  authori-
              zation  files  while  initializing  the  session.   The
              default  value  is  /usr/openwin/lib/X11/xdm.   Can  be
              overridden      for      specific      displays      by
              This boolean controls whether xdm  rescans  the  confi-
              guration,  servers,  access  control and authentication
              keys files after a session  terminates  and  the  files
              have  changed.   By  default  it  is ``true.''  You can
              force xdm to reread these files by sending a SIGHUP  to
              the main process.
              When computing the display name for XDMCP clients,  the
              name  resolver  will typically create a fully qualified
              host name for  the  terminal.   As  this  is  sometimes
              confusing,  xdm  will remove the domain name portion of
              the host name if it is the same as the domain  name  of
              the  local  host when this variable is set.  By default
              the value is ``true.''
              XDM-AUTHENTICATION-1   style    XDMCP    authentication
              requires  that  a private key be shared between xdm and
              the terminal.  This resource specifies  the  file  con-
              taining  those values.  Each entry in the file consists
              of a display name and the shared key.  By default,  xdm
              does  not  include support for XDM-AUTHENTICATION-1, as
              it requires DES which is  not  generally  distributable
              because of United States export restrictions.
              To prevent unauthorized XDMCP service and to allow for-
              warding of XDMCP IndirectQuery requests, this file con-
              tains a database of hostnames which are either  allowed
              direct  access to this machine, or have a list of hosts
              to which queries should be forwarded to.  The format of
              this file is described in the section XDMCP Access Con-
              A list of additional environment  variables,  separated
              by  white  space,  to  pass on to the Xsetup, Xstartup,
              Xsession, and Xreset programs.
              A file to checksum to generate the seed  of  authoriza-
              tion  keys.   This  should  be a file that changes fre-
              quently.  The default is /dev/mem.
              On systems that support a dynamically-loadable  greeter
              library,   the   name   of  the  library.   Default  is
              Number of seconds to wait for display to respond  after
              user  has  selected  a  host  from the chooser.  If the
              display sends an XDMCP IndirectQuery within this  time,
              the  request  is  forwarded to the chosen host.  Other-
              wise, it is assumed to be from a new  session  and  the
              chooser is offered again.  Default is 15.
              This resource specifies the name  of  the  file  to  be
              loaded  by  xrdb as the resource database onto the root
              window of screen 0 of the display.  The Xsetup program,
              the  Login  widget,  and chooser will use the resources
              set in this file.  This resource data  base  is  loaded
              just before the authentication procedure is started, so
              it can control the appearance of the login window.  See
              the  section Authentication Widget, which describes the
              various resources that are appropriate to place in this
              file.  There is no default value for this resource, but
              /usr/openwin/lib/X11/xdm/Xresources is the conventional
              Specifies the program run to  offer  a  host  menu  for
              Indirect  queries  redirected  to the special host name
              CHOOSER.    /usr/openwin/lib/X11/xdm/chooser   is   the
              default.   See  the  sections  XDMCP Access Control and
              Specifies the program used to load the  resources.   By
              default, xdm uses /usr/openwin/bin/xrdb.
              This specifies the name of the C preprocessor which  is
              used by xrdb.
              This specifies a program which is run (as root)  before
              offering  the Login window.  This may be used to change
              the appearance of the screen around the Login window or
              to  put  up  other  windows  (e.g., you may want to run
              xconsole here).  By default, no program  is  run.   The
              conventional  name for a file used here is Xsetup.  See
              the section Setup Program.
              This specifies a program which is run (as  root)  after
              the  authentication  process  succeeds.  By default, no
              program is run.  The conventional name for a file  used
              here is Xstartup.  See the section Startup Program.
              This specifies the session to be executed (not  running
              as  root).   By default, /usr/openwin/bin/xterm is run.
              The conventional name is  Xsession.   See  the  section
              Session Program.
              This specifies a program which is run (as  root)  after
              the session terminates.  By default, no program is run.
              The conventional name is Xreset.  See the section Reset
              These numeric resources control  the  behavior  of  xdm
              when  attempting to open intransigent servers.  openDe-
              lay is the length of the  pause  (in  seconds)  between
              successive   attempts,  openRepeat  is  the  number  of
              attempts to make, openTimeout is the amount of time  to
              wait while actually attempting the open (i.e., the max-
              imum time spent in  the  connect(2)  system  call)  and
              startAttempts  is  the number of times this entire pro-
              cess is done before giving up  on  the  server.   After
              openRepeat  attempts  have been made, or if openTimeout
              seconds elapse in  any  particular  attempt,  xdm  ter-
              minates  and restarts the server, attempting to connect
              again.  This process is repeated  startAttempts  times,
              at  which  point  the display is declared dead and dis-
              abled.  Although this behavior may seem  arbitrary,  it
              has  been empirically developed and works quite well on
              most systems.  The default values are 5 for  openDelay,
              5 for openRepeat, 30 for openTimeout and 4 for startAt-
              To discover when remote displays disappear,  xdm  occa-
              sionally  pings  them,  using an X connection and XSync
              calls.  pingInterval specifies the  time  (in  minutes)
              between  each  ping  attempt, pingTimeout specifies the
              maximum amount of time (in minutes)  to  wait  for  the
              terminal  to  respond  to the request.  If the terminal
              does not respond, the session is declared dead and ter-
              minated.   By  default,  both are set to 5 minutes.  If
              you frequently use X terminals which  can  become  iso-
              lated  from the managing host, you may wish to increase
              this value.  The only worry is that sessions will  con-
              tinue to exist after the terminal has been accidentally
              disabled.  xdm will not ping local displays.   Although
              it  would  seem  harmless,  it  is  unpleasant when the
              workstation session is terminated as a  result  of  the
              server  hanging  for  NFS service and not responding to
              the ping.
              This boolean resource specifies whether  the  X  server
              should be terminated when a session terminates (instead
              of resetting it).  This option can  be  used  when  the
              server  tends to grow without bound over time, in order
              to limit the amount of time the  server  is  run.   The
              default value is ``false.''
              Xdm sets the PATH environment variable for the  session
              to  this value.  It should be a colon separated list of
              directories;  see  sh(1)  for   a   full   description.
              ``:/bin:/usr/bin:/usr/openwin/bin:/usr/ucb''  is a com-
              mon setting.  The default value  can  be  specified  at
              build  time  in  the  X  system configuration file with
              Xdm sets the PATH environment variable for the  startup
              and  reset  scripts to the value of this resource.  The
              default for this resource is specified at build time by
              the DefaultSystemPath entry in the system configuration
              file;  ``/etc:/bin:/usr/bin:/usr/openwin/bin:/usr/ucb''
              is  a  common  choice.   Note the absence of ``.'' from
              this entry.  This is a  good  practice  to  follow  for
              root;  it  avoids many common Trojan Horse system pene-
              tration schemes.
              Xdm sets the SHELL environment variable for the startup
              and reset scripts to the value of this resource.  It is
              /bin/sh by default.
              If the default session fails to execute, xdm will  fall
              back to this program.  This program is executed with no
              arguments, but  executes  using  the  same  environment
              variables  as  the session would have had (see the sec-
              tion      Session      Program).       By      default,
              /usr/openwin/bin/xterm is used.
              To improve security, xdm grabs the server and  keyboard
              while  reading  the login name and password.  The grab-
              Server resource specifies if the server should be  held
              for  the  duration  of the name/password reading.  When
              ``false,'' the server is ungrabbed after  the  keyboard
              grab  succeeds,  otherwise  the server is grabbed until
              just  before  the  session  begins.   The  default   is
              ``false.''  The grabTimeout resource specifies the max-
              imum time xdm will wait for the grab to  succeed.   The
              grab  may  fail  if  some  other  client has the server
              grabbed, or possibly if the network latencies are  very
              high.   This resource has a default value of 3 seconds;
              you should be cautious when raising it, as a  user  can
              be  spoofed  by a look-alike window on the display.  If
              the grab fails, xdm kills and restarts the  server  (if
              possible) and the session.
              authorize is a boolean resource which controls  whether
              xdm  generates  and  uses  authorization  for the local
              server connections.  If authorization is used, authName
              is a list of authorization mechanisms to use, separated
              by white space.  XDMCP connections dynamically  specify
              which  authorization mechanisms are supported, so auth-
              Name is ignored in this case.  When  authorize  is  set
              for  a  display and authorization is not available, the
              user  is  informed  by  having  a   different   message
              displayed  in  the login widget.  By default, authorize
              is ``true.''  authName is  ``MIT-MAGIC-COOKIE-1,''  or,
              if    XDM-AUTHORIZATION-1    is    available,    ``XDM-
              This file is used to communicate the authorization data
              from  xdm to the server, using the -auth server command
              line option.  It should be kept in a directory which is
              not world-writable as it could easily be removed, disa-
              bling the authorization mechanism in  the  server.   If
              not    specified,    a    name    is   generated   from
              DisplayManager.authDir and the name of the display.
              If set to ``false,'' disables the use of the  unsecure-
              Greeting  in the login window.  See the section Authen-
              tication Widget.  The default is ``true.''
              The number of the signal xdm sends to reset the server.
              See the section Controlling the Server.  The default is
              1 (SIGHUP).
              The number of the signal xdm  sends  to  terminate  the
              server.   See  the section Controlling the Server.  The
              default is 15 (SIGTERM).
              The original implementation  of  authorization  in  the
              sample  server  reread the authorization file at server
              reset time, instead of when checking the  initial  con-
              nection.   As  xdm generates the authorization informa-
              tion just before connecting  to  the  display,  an  old
              server  would not get up-to-date authorization informa-
              tion.  This resource causes xdm to send SIGHUP  to  the
              server after setting up the file, causing an additional
              server reset  to  occur,  during  which  time  the  new
              authorization information will be read.  The default is
              ``false,'' which will work for all MIT servers.
              When xdm is unable to write to the usual user  authori-
              zation  file  ($HOME/.Xauthority),  it creates a unique
              file name in this directory and points the  environment
              variable  XAUTHORITY at the created file.  It uses /tmp
              by default.
         First, the xdm configuration file should be set up.  Make  a
         directory  (usually /usr/openwin/lib/X11/xdm) to contain all
         of the relevant files.
         Here is a reasonable  configuration  file,  which  could  be
         named xdm-config:
              DisplayManager.servers:            /usr/openwin/lib/X11/xdm/Xservers
              DisplayManager.errorLogFile:       /usr/openwin/lib/X11/xdm/xdm-errors
              DisplayManager*resources:          /usr/openwin/lib/X11/xdm/Xresources
              DisplayManager*startup:            /usr/openwin/lib/X11/xdm/Xstartup
              DisplayManager*session:            /usr/openwin/lib/X11/xdm/Xsession
              DisplayManager.pidFile:            /usr/openwin/lib/X11/xdm/xdm-pid
              DisplayManager._0.authorize:       true
              DisplayManager*authorize:          false
         Note that this file  mostly  contains  references  to  other
         files.   Note  also that some of the resources are specified
         with ``*'' separating the components.  These  resources  can
         be  made unique for each different display, by replacing the
         ``*'' with the display-name, but normally this is  not  very
         useful.   See  the  Resources section for a complete discus-
         The database file specified by the DisplayManager.accessFile
         provides  information  which xdm uses to control access from
         displays requesting XDMCP service.  This file contains three
         types  of  entries:   entries  which control the response to
         Direct and Broadcast  queries,  entries  which  control  the
         response to Indirect queries, and macro definitions.
         The format of the Direct entries is simple,  either  a  host
         name  or  a pattern, which is distinguished from a host name
         by the inclusion of one or more meta characters (`*' matches
         any  sequence  of  0 or more characters, and `?' matches any
         single character) which are compared against the  host  name
         of  the  display  device.   If the entry is a host name, all
         comparisons are done using network addresses,  so  any  name
         which  converts  to the correct network address may be used.
         For patterns, only canonical host names are used in the com-
         parison, so ensure that you do not attempt to match aliases.
         Preceding either a host name or a pattern with a `!' charac-
         ter causes hosts which match that entry to be excluded.
         An Indirect entry also contains a host name or pattern,  but
         follows  it  with  a  list  of host names or macros to which
         indirect queries should be sent.
         A macro definition contains a macro name and a list of  host
         names  and  other macros that the macro expands to.  To dis-
         tinguish macros from hostnames, macro names start with a `%'
         character.  Macros may be nested.
         Indirect entries may also specify to have xdm run chooser to
         offer  a  menu  of  hosts  to  connect  to.  See the section
         When checking access for a  particular  display  host,  each
         entry is scanned in turn and the first matching entry deter-
         mines  the  response.   Direct  and  Broadcast  entries  are
         ignored when scanning for an Indirect entry and vice-versa.
         Blank lines are ignored, `#' is treated as a comment  delim-
         iter causing the rest of that line to be ignored, and `\new-
         line' causes the newline to be  ignored,  allowing  indirect
         host lists to span multiple lines.
         Here is an example Xaccess file:
         # Xaccess - XDMCP access control file
         # Direct/Broadcast query entries
         !   # disallow direct/broadcast service for xtra       # allow access from this particular display
         *       # allow access from any display in LCS
         # Indirect query entries
         %HOSTS     \
       #force extract to contact xenon
         !   dummy               #disallow indirect access
         *       %HOSTS              #all others get to choose
         For X terminals that do not offer a host menu for  use  with
         Broadcast  or  Indirect  queries, the chooser program can do
         this for them.  In the Xaccess file, specify ``CHOOSER''  as
         the  first  entry  in  the Indirect host list.  Chooser will
         send a Query request to each of the remaining host names  in
         the list and offer a menu of all the hosts that respond.
         The list may consist of the  word  ``BROADCAST,''  in  which
         case chooser will send a Broadcast instead, again offering a
         menu of all hosts that respond.  Note that on some operating
         systems,  UDP  packets  cannot be broadcast, so this feature
         will not work.
         Example Xaccess file using chooser:
     CHOOSER %HOSTS      #offer a menu of these hosts    CHOOSER BROADCAST   #offer a menu of all hosts
         The  program  to  use  for  chooser  is  specified  by   the
         DisplayManager.DISPLAY.chooser resource.  For more flexibil-
         ity at this step, the  chooser  could  be  a  shell  script.
         Chooser  is the session manager here; it is run instead of a
         child xdm to manage the display.
         Resources for this program can be put into the file named by
         When the user  selects  a  host,  chooser  prints  the  host
         chosen,  which  is  read  by the parent xdm, and exits.  xdm
         closes its connection to the X server, and the server resets
         and sends another Indirect XDMCP request.  xdm remembers the
         user's choice (for DisplayManager.choiceTimeout seconds) and
         forwards the request to the chosen host, which starts a ses-
         sion on that display.
         The resource DisplayManager.servers gives a server  specifi-
         cation  or,  if the values starts with a slash (/), the name
         of a file containing server specifications, one per line.
         Each specification indicates a  display  which  should  con-
         stantly  be  managed  and  which  is  not using XDMCP.  This
         method is used typically for local  servers  only.   If  the
         resource  or  the  file  named by the resource is empty, xdm
         will offer XDMCP service only.
         Each specification consists of  at  least  three  parts:   a
         display  name,  a  display  class,  a display type, and (for
         local servers) a command line to start the server.  A  typi-
         cal entry for local display number 0 would be:
           :0 Digital-QV local /usr/openwin/bin/Xsun :0
         The display types are:
         local     local display: xdm must run the server
         foreign   remote display: xdm opens an X connection to a running server
         The display name must be something that can be passed in the
         -display  option  to  an  X program.  This string is used to
         generate the display-specific resource names, so be  careful
         to   match   the   names   (e.g.,  use  ``:0  Sun-CG3  local
         /usr/openwin/bin/Xsun :0'' instead of ``localhost:0  Sun-CG3
         local /usr/openwin/bin/Xsun :0'' if your other resources are
         specified as  ``DisplayManager._0.session'').   The  display
         class   portion   is   also  used  in  the  display-specific
         resources, as the class of the resource.  This is useful  if
         you  have  a large collection of similar displays (such as a
         corral of X terminals) and would like to set  resources  for
         groups  of  them.  When using XDMCP, the display is required
         to specify the display class, so the manual for your partic-
         ular X terminal should document the display class string for
         your device.  If it doesn't, you can run xdm in  debug  mode
         and look at the resource strings which it generates for that
         device, which will include the class string.
         When xdm starts a session, it sets up authorization data for
         the   server.    For   local  servers,  xdm  passes  ``-auth
         filename'' on the server's command line to point it  at  its
         authorization  data.   For  XDMCP  servers,  xdm  passes the
         authorization data  to  the  server  via  the  Accept  XDMCP
         The Xresources file is loaded onto the display as a resource
         database using xrdb. As the authentication widget reads this
         database before starting up, it usually contains  parameters
         for that widget:
              xlogin*login.translations: #override\
                   Ctrl<Key>R: abort-display()\n\
                   <Key>F1: set-session-argument(failsafe) finish-field()\n\
                   <Key>Return: set-session-argument() finish-field()
              xlogin*borderWidth: 3
              xlogin*greeting: CLIENTHOST
              #ifdef COLOR
              xlogin*greetColor: CadetBlue
              xlogin*failColor: red
         Please note the translations entry; it specifies a  few  new
         translations for the widget which allow users to escape from
         the default session (and avoid troubles that  may  occur  in
         it).   Note  that if #override is not specified, the default
         translations are removed and replaced by the new value,  not
         a very useful result as some of the default translations are
         quite  useful  (such  as  ``<Key>:  insert-char  ()''  which
         responds to normal typing).
         This file may also contain resources for the  setup  program
         and chooser.
         The Xsetup file is run after the server is reset, but before
         the  Login window is offered.  The file is typically a shell
         script.  It is run as root, so should be careful about secu-
         rity.   This  is  the place to change the root background or
         bring up other windows that  should  appear  on  the  screen
         along with the Login widget.
         In addition to any specified  by  DisplayManager.exportList,
         the following environment variables are passed:
              DISPLAY        the associated display name
              PATH           the value of DisplayManager.DISPLAY.systemPath
              SHELL          the value of DisplayManager.DISPLAY.systemShell
              XAUTHORITY     may be set to an authority file
         Note that since xdm grabs the keyboard,  any  other  windows
         will  not  be  able to receive keyboard input.  They will be
         able to interact with the mouse, however; beware  of  poten-
         tial         security         holes         here.         If
         DisplayManager.DISPLAY.grabServer is set, Xsetup will not be
         able  to  connect to the display at all.  Resources for this
         program   can   be   put   into   the    file    named    by
         Here is a sample Xsetup script:
              # Xsetup_0 - setup script for one workstation
              xcmsdb < /usr/openwin/lib/monitors/alex.0
              xconsole -geometry 480x130-0-0 -notify -verbose -exitOnFail &
         The authentication widget reads a  name/password  pair  from
         the keyboard.  Nearly every imaginable parameter can be con-
         trolled with a resource.  Resources for this  widget  should
         be       put      into      the      file      named      by
         DisplayManager.DISPLAY.resources.  All of these have reason-
         able  default  values, so it is not necessary to specify any
         of them.
         xlogin.Login.width,     xlogin.Login.height,      xlogin.Login.x,
              The  geometry  of the Login widget is normally computed
              automatically.  If you wish to position  it  elsewhere,
              specify each of these resources.
              The color used to display the typed-in user name.
              The font used to display the typed-in user name.
              A string which identifies this window.  The default  is
              ``X Window System.''
              When X authorization is requested in the  configuration
              file for this display and none is in use, this greeting
              replaces the standard greeting.  The default is  ``This
              is an unsecure session''
              The font used to display the greeting.
              The color used to display the greeting.
              The string displayed to prompt for a user  name.   Xrdb
              strips trailing white space from resource values, so to
              add spaces at the end of the  prompt  (usually  a  nice
              thing),  add  spaces  escaped  with  backslashes.   The
              default is ``Login:  ''
              The string displayed to prompt  for  a  password.   The
              default is ``Password:  ''
              The font used to display both prompts.
              The color used to display both prompts.
              A message which is displayed  when  the  authentication
              fails.  The default is ``Login incorrect''
              The font used to display the failure message.
              The color used to display the failure message.
              The number of  seconds  that  the  failure  message  is
              displayed.  The default is 30.
              This specifies the  translations  used  for  the  login
              widget.   Refer  to  the  X Toolkit documentation for a
              complete  discussion  on  translations.   The   default
              translation table is:
                   Ctrl<Key>H:    delete-previous-character() \n\
                   Ctrl<Key>D:    delete-character() \n\
                   Ctrl<Key>B:    move-backward-character() \n\
                   Ctrl<Key>F:    move-forward-character() \n\
                   Ctrl<Key>A:    move-to-begining() \n\
                   Ctrl<Key>E:    move-to-end() \n\
                   Ctrl<Key>K:    erase-to-end-of-line() \n\
                   Ctrl<Key>U:    erase-line() \n\
                   Ctrl<Key>X:    erase-line() \n\
                   Ctrl<Key>C:    restart-session() \n\
                   Ctrl<Key>\\:   abort-session() \n\
                   <Key>BackSpace:delete-previous-character() \n\
                   <Key>Delete:   delete-previous-character() \n\
                   <Key>Return:   finish-field() \n\
                   <Key>:         insert-char() \
         The actions which are supported by the widget are:
              Erases the character before the cursor.
              Erases the character after the cursor.
              Moves the cursor backward.
              Moves the cursor forward.
              (Apologies about the spelling error.)  Moves the cursor
              to the beginning of the editable text.
              Moves the cursor to the end of the editable text.
              Erases all text after the cursor.
              Erases the entire text.
              If the cursor is in the name  field,  proceeds  to  the
              password field; if the cursor is in the password field,
              checks  the  current  name/password   pair.    If   the
              name/password  pair  is  valid, xdm starts the session.
              Otherwise the failure message is displayed and the user
              is prompted again.
              Terminates and restarts the server.
              Terminates the server, disabling it.   This  action  is
              not accessible in the default configuration.  There are
              various reasons to stop xdm on a system  console,  such
              as  when shutting the system down, when using xdmshell,
              to start another type of server, or to generally access
              the  console.   Sending  xdm  a SIGHUP will restart the
              display.  See the section Controlling XDM.
              Resets the X server and starts a new session.  This can
              be  used  when  the resources have been changed and you
              want to test them or when the screen has been overwrit-
              ten with system messages.
              Inserts the character typed.
              Specifies a single word argument which is passed to the
              session at startup.  See the section Session Program.
              Disables access control in the  server.   This  can  be
              used  when  the  .Xauthority  file cannot be created by
              xdm. Be very careful using this; it might be better  to
              disconnect  the  machine  from the network before doing
         The Xstartup program is run as root when the user  logs  in.
         It  is  typically  a shell script.  Since it is run as root,
         Xstartup should be very careful about security.  This is the
         place  to  put  commands which add entries to /etc/utmp (the
         sessreg program may  be  useful  here),  mount  users'  home
         directories  from  file  servers,  or  abort  the session if
         logins are not allowed.
         In addition to any specified  by  DisplayManager.exportList,
         the following environment variables are passed:
              DISPLAY        the associated display name
              HOME           the initial working directory of the user
              USER           the user name
              PATH           the value of DisplayManager.DISPLAY.systemPath
              SHELL          the value of DisplayManager.DISPLAY.systemShell
              XAUTHORITY     may be set to an authority file
         No arguments are passed to the script.  Xdm waits until this
         script  exits before starting the user session.  If the exit
         value of this script is non-zero, xdm discontinues the  ses-
         sion and starts another authentication cycle.
         The sample Xstartup file shown here prevents login while the
         file  /etc/nologin exists. Thus this is not a complete exam-
         ple, but simply a demonstration of the available functional-
         Here is a sample Xstartup script:
              # Xstartup
              # This program is run as root after the user is verified
              if [ -f /etc/nologin ]; then
                   xmessage -file /etc/nologin -timeout 30 -center
                   exit 1
              sessreg -a -l $DISPLAY -x /usr/openwin/lib/xdm/Xservers $USER
              exit 0
         The Xsession program is the command  which  is  run  as  the
         user's  session.   It  is  run  with  the permissions of the
         authorized user.
         In addition to any specified  by  DisplayManager.exportList,
         the following environment variables are passed:
              DISPLAY        the associated display name
              HOME           the initial working directory of the user
              USER           the user name
              PATH           the value of DisplayManager.DISPLAY.userPath
              SHELL          the user's default shell (from getpwnam)
              XAUTHORITY     may be set to a non-standard authority file
              KRB5CCNAME     may be set to a Kerberos credentials cache name
         At most installations, Xsession should look in $HOME  for  a
         file .xsession, which contains commands that each user would
         like to use as a session.  Xsession should also implement  a
         system  default session if no user-specified session exists.
         See the section Typical Usage.
         An argument may be passed to this program from the authenti-
         cation widget using the `set-session-argument' action.  This
         can be used to select different styles of session.  One good
         use  of this feature is to allow the user to escape from the
         ordinary session when it fails.  This allows users to repair
         their  own .xsession if it fails, without requiring adminis-
         trative intervention.  The  example  following  demonstrates
         this feature.
         This  example  recognizes  the  special  ``failsafe''  mode,
         specified  in  the  translations  in the Xresources file, to
         provide an  escape  from  the  ordinary  session.   It  also
         requires  that  the .xsession file be executable so we don't
         have to guess what shell it wants to use.
              # Xsession
              # This is the program that is run as the client
              # for the display manager.
              case $# in
                   case $1 in
                        exec xterm -geometry 80x24-0-0
              if [ -f "$startup" ]; then
                   exec "$startup"
                   if [ -f "$resources" ]; then
                        xrdb -load "$resources"
                   twm &
                   xman -geometry +10-10 &
                   exec xterm -geometry 80x24+10+10 -ls
         The user's .xsession file might  look  something  like  this
         example.   Don't forget that the file must have execute per-
              #! /bin/csh
              # no -f in the previous line so .cshrc gets run to set $PATH
              twm &
              xrdb -merge "$HOME/.Xresources"
              emacs -geometry +0+50 &
              xbiff -geometry -430+5 &
              xterm -geometry -0+50 -ls
         Symmetrical with Xstartup, the Xreset script  is  run  after
         the  user  session  has  terminated.  Run as root, it should
         contain commands  that  undo  the  effects  of  commands  in
         Xstartup,  removing  entries  from  /etc/utmp  or unmounting
         directories from file servers.   The  environment  variables
         that were passed to Xstartup are also passed to Xreset.
         A sample Xreset script:
              # Xreset
              # This program is run as root after the session ends
              sessreg -d -l $DISPLAY -x /usr/openwin/lib/xdm/Xservers $USER
              exit 0
         Xdm controls local servers using POSIX signals.   SIGHUP  is
         expected to reset the server, closing all client connections
         and performing other cleanup duties.  SIGTERM is expected to
         terminate  the  server.  If these signals do not perform the
         expected          actions,           the           resources
         DisplayManager.DISPLAY.resetSignal                       and
         DisplayManager.DISPLAY.termSignal can specify alternate sig-
         To control remote terminals not using  XDMCP,  xdm  searches
         the  window  hierarchy  on the display and uses the protocol
         request KillClient in an attempt to clean  up  the  terminal
         for the next session.  This may not actually kill all of the
         clients, as only those which have created  windows  will  be
         noticed.   XDMCP  provides  a  more sure mechanism; when xdm
         closes its initial connection, the session is over  and  the
         terminal is required to close all other connections.
         Xdm responds to two signals: SIGHUP and SIGTERM.  When  sent
         a  SIGHUP,  xdm  rereads  the configuration file, the access
         control file, and the servers file.  For the  servers  file,
         it  notices if entries have been added or removed.  If a new
         entry has been added, xdm starts a session on the associated
         display.   Entries  which  have  been  removed  are disabled
         immediately, meaning that any session in  progress  will  be
         terminated  without  notice  and  no  new  session  will  be
         When sent a SIGTERM, xdm terminates all sessions in progress
         and exits.  This can be used when shutting down the system.
         Xdm attempts to mark its various sub-processes for ps(1)  by
         editing  the  command  line argument list in place.  Because
         xdm can't allocate additional space for  this  task,  it  is
         useful  to  start  xdm  with  a reasonably long command line
         (using the full path name should be enough).   Each  process
         which is servicing a display is marked -display.
         You can use xdm to run a single session at a time, using the
         4.3  init options or other suitable daemon by specifying the
         server on the command line:
              xdm -server ":0 SUN-3/60CG4 local /usr/openwin/bin/Xsun :0"
         Or, you might have a file server and a collection of X  ter-
         minals.  The configuration for this is identical to the sam-
         ple above, except the Xservers file would look like
              extol:0 VISUAL-19 foreign
              exalt:0 NCD-19 foreign
              explode:0 NCR-TOWERVIEW3000 foreign
         This directs xdm to manage sessions on all  three  of  these
         terminals.   See  the section Controlling Xdm for a descrip-
         tion of using signals to enable and disable these  terminals
         in a manner reminiscent of init(8).
         One thing that xdm isn't very good at  doing  is  coexisting
         with  other  window systems.  To use multiple window systems
         on the same hardware, you'll probably be more interested  in
         On the Solaris x86 platform, an attempt to type a login name
         into xdm will cause the keyboard to lock up.  The workaround
         is to use xdm -nodaemon instead.
                             the default configuration file
         $HOME/.Xauthority   user authorization file where xdm stores
                             keys for clients to read
                             the default chooser
                             the default resource database loader
         /usr/openwin/bin/X  the default server
                             the default session program and failsafe
                             the  default  place  for   authorization
         /tmp/K5C<display>   Kerberos credentials cache
         X11(1),  xinit(1),   xauth(1),   Xsecurity(7),   sessreg(1),
         X Display Manager Control Protocol
         Keith Packard, MIT X Consortium

    Поиск по тексту MAN-ов: 

    Inferno Solutions
    Hosting by

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру