diff options
| author | Javier Jardón <jjardon@gnome.org> | 2012-08-11 00:00:11 +0900 |
|---|---|---|
| committer | Ray Strode <rstrode@redhat.com> | 2012-09-04 16:48:44 -0400 |
| commit | db048b2f38d19e5b965c8feb931a75a1c3384ff3 (patch) | |
| tree | a1e2f003e2256dff2c1cb3ddf136b0733aaa14aa | |
| parent | 0f2caf80bfab50ce4632e9f7944de780a9341cc0 (diff) | |
| download | gdm-db048b2f38d19e5b965c8feb931a75a1c3384ff3.tar.gz | |
Use new documentation infrastructure
Use yelp-tools instead gnome-doc-utils
https://bugzilla.gnome.org/show_bug.cgi?id=681604
| -rw-r--r-- | .gitignore | 17 | ||||
| -rw-r--r-- | Makefile.am | 11 | ||||
| -rw-r--r-- | configure.ac | 11 | ||||
| -rw-r--r-- | docs/C/gdm.xml | 2287 | ||||
| -rw-r--r-- | docs/Makefile.am | 16 | ||||
| -rw-r--r-- | docs/gdm.omf.in | 11 | ||||
| -rw-r--r-- | omf.make | 61 | ||||
| -rw-r--r-- | xmldocs.make | 95 |
8 files changed, 15 insertions, 2494 deletions
@@ -11,7 +11,6 @@ *.pox *.tab.c .*.swp -gdm.xml at-spi-registryd-wrapper.desktop.in ./autom4te.cache .deps @@ -62,7 +61,6 @@ gdm-xdmcp-chooser-slave-glue.c gdm-xdmcp-greeter-display-glue.h gdm-greeter-glue.h gdm-greeter-glue.c -gnome-doc-utils.make GNOME_FastUserSwitchApplet.server GNOME_FastUserSwitchApplet.server.in gnome-power-manager.desktop.in @@ -84,17 +82,14 @@ Makefile.in Makefile.in.in na-marshal.c na-marshal.h -oc/gdm.xml PostSession POTFILES PreSession so_locations stamp-h1 stamp-it -sv/gdm.xml tags TAGS -uk/gdm.xml Xsession INSTALL aclocal.m4 @@ -127,17 +122,6 @@ data/applications/orca-screen-reader.desktop data/applications/polkit-gnome-authentication-agent-1.desktop data/applications/polkit-gnome-authentication-agent-1.desktop.in depcomp -docs/gdm-C.omf -docs/gdm-de.omf -docs/gdm-en_GB.omf -docs/gdm-es.omf -docs/gdm-fr.omf -docs/gdm-it.omf -docs/gdm-ko.omf -docs/gdm-oc.omf -docs/gdm-ru.omf -docs/gdm-sv.omf -docs/gdm-uk.omf gui/libgdm/gdm-client-glue.h gui/libgdm/gdm-client-glue.c gui/libgdm/gdm-manager-glue.h @@ -177,7 +161,6 @@ utils/gdmflexiserver *.pc *.gir *.typelib -*.omf *.tar.* gdm-smartcard-worker dconf-override-db diff --git a/Makefile.am b/Makefile.am index c1808548..7dd8bc22 100644 --- a/Makefile.am +++ b/Makefile.am @@ -13,22 +13,13 @@ if ENABLE_DOCUMENTATION SUBDIRS += docs endif -# add these when help gets added back -# omf-install - EXTRA_DIST = \ MAINTAINERS \ ChangeLog \ README \ - gnome-doc-utils.make \ - xmldocs.make \ - omf.make \ $(NULL) DISTCLEANFILES = \ - gnome-doc-utils.make \ $(NULL) -DISTCHECK_CONFIGURE_FLAGS = --disable-scrollkeeper --enable-split-authentication --enable-introspection --enable-documentation - -distuninstallcheck_listfiles = find . -type f -print | grep -v '^\./var/scrollkeeper' +DISTCHECK_CONFIGURE_FLAGS = --enable-split-authentication --enable-introspection diff --git a/configure.ac b/configure.ac index 40774e50..8458b827 100644 --- a/configure.ac +++ b/configure.ac @@ -41,10 +41,12 @@ AC_SUBST(VERSION) AM_CONFIG_HEADER(config.h) AC_CONFIG_MACRO_DIR([m4]) -GNOME_DOC_INIT -AC_ARG_ENABLE([documentation], - AS_HELP_STRING([--enable-documentation], [enable man pages and HTML documentation]), - [], [enable_documentation=yes]) +# Documentation +enable_documentation=no +m4_ifdef([YELP_HELP_INIT],[ +YELP_HELP_INIT +enable_documentation=yes +]) AM_CONDITIONAL(ENABLE_DOCUMENTATION, test x$enable_documentation = xyes) # i18n stuff @@ -1598,4 +1600,5 @@ echo \ UPower support: ${have_upower} Build with RBAC: ${msg_rbac_shutdown} Initial VT: ${GDM_INITIAL_VT} + Enable documentation: ${enable_documentation} " diff --git a/docs/C/gdm.xml b/docs/C/gdm.xml deleted file mode 100644 index ca6c6ee4..00000000 --- a/docs/C/gdm.xml +++ /dev/null @@ -1,2287 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" - "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ - <!ENTITY legal SYSTEM "legal.xml"> - <!ENTITY version "2.26.0"> - <!ENTITY date "02/10/2009"> - <!ENTITY mdash "—"> - <!ENTITY percnt "%"> -]> - -<article id="index" lang="en"> - <articleinfo> - <title>GNOME Display Manager Reference Manual</title> - - <revhistory> - <revision> - <revnumber>0.0</revnumber> - <date>2008-09</date> - </revision> - </revhistory> - - <abstract role="description"> - <para> - GDM is the GNOME Display Manager, a graphical login program. - </para> - </abstract> - - <authorgroup> - <author> - <firstname>Martin</firstname><othername>K.</othername> - <surname>Petersen</surname> - <affiliation> - <address><email>mkp@mkp.net</email></address> - </affiliation> - </author> - <author> - <firstname>George</firstname><surname>Lebl</surname> - <affiliation> - <address><email>jirka@5z.com</email></address> - </affiliation> - </author> - <author> - <firstname>Jon</firstname><surname>McCann</surname> - <affiliation> - <address><email>mccann@jhu.edu</email></address> - </affiliation> - </author> - <author> - <firstname>Ray</firstname><surname>Strode</surname> - <affiliation> - <address><email>rstrode@redhat.com</email></address> - </affiliation> - </author> - <author role="maintainer"> - <firstname>Brian</firstname><surname>Cameron</surname> - <affiliation> - <address><email>Brian.Cameron@Oracle.COM</email></address> - </affiliation> - </author> - </authorgroup> - <copyright> - <year>1998</year> - <year>1999</year> - <holder>Martin K. Petersen</holder> - </copyright> - <copyright> - <year>2001</year> - <year>2003</year> - <year>2004</year> - <holder>George Lebl</holder> - </copyright> - <copyright> - <year>2003</year> - <year>2007</year> - <year>2008</year> - <holder>Red Hat, Inc.</holder> - </copyright> - <copyright> - <year>2003</year> - <year>2011</year> - <holder>Oracle and/or its affiliates. All rights reserved.</holder> - </copyright> - - &legal; - - <releaseinfo> - This manual describes version &version; of the GNOME Display Manager. - It was last updated on &date;. - </releaseinfo> - </articleinfo> - - <!-- ============= Preface ================================== --> - - <sect1 id="preface"> - <title>Terms and Conventions Used in This Manual</title> - - <para> - This manual describes version &version; of the GNOME Display Manager. - It was last updated on &date;. - </para> - - <para> - Chooser - A program used to select a remote host for managing a - display remotely on the attached display (<command>gdm-host-chooser</command>). - </para> - - <para> - FreeDesktop - The organization providing desktop standards, such as the - Desktop Entry Specification used by GDM. - <ulink type="http" url="http://www.freedesktop.org/"> - http://www.freedesktop.org</ulink>. - </para> - <para> - GDM - GNOME Display Manager. Used to describe the software package as a - whole. - </para> - - <para> - Greeter - The graphical login window (<command>gdm-simple-greeter</command>). - </para> - - <para> - PAM - Pluggable Authentication Mechanism - </para> - - <para> - XDMCP - X Display Manage Protocol - </para> - - <para> - Xserver - An implementation of the X Window System. For example the - Xorg Xserver provided by the X.org Foundation - <ulink type="http" url="http://www.x.org/">http://www.x.org</ulink>. - </para> - - <para> - Paths that start with a word in angle brackets are relative to the - installation prefix. I.e. <filename><share>/pixmaps/</filename> - refers to <filename>/usr/share/pixmaps</filename> if GDM was - configured with <command>--prefix=/usr</command>. - </para> - </sect1> - - <!-- ============= Overview ================================= --> - - <sect1 id="overview"> - <title>Overview</title> - - <sect2 id="introduction"> - <title>Introduction</title> - - <para> - The GNOME Display Manager (GDM) is a display manager that implements - all significant features required for managing attached and remote - displays. GDM was written from scratch and does not contain any XDM or - X Consortium code. - </para> - - <para> - Note that GDM is configurable, and many configuration settings have - an impact on security. Issues to be aware of are highlighted in this - document. - </para> - - <para> - Please note that some Operating Systems configure GDM to behave - differently than the default values as described in this document. If - GDM does not seem to behave as documented, then check to see if any - related configuration may be different than described here. - </para> - - <para> - For further information about GDM, refer to the project website at - <ulink type="http" url="http://www.gnome.org/projects/gdm/"> - http://www.gnome.org/projects/gdm</ulink> and the project - Wiki <ulink type="http" url="http://live.gnome.org/GDM"> - http://live.gnome.org/GDM</ulink>. - </para> - - <para> - For discussion or queries about GDM, refer to the - <address><email>gdm-list@gnome.org</email></address> mail list. This - list is archived, and is a good resource to check to seek answers to - common questions. This list is archived at - <ulink type="http" url="http://mail.gnome.org/archives/gdm-list/"> - http://mail.gnome.org/archives/gdm-list/</ulink> and has a search - facility to look for messages with keywords. - </para> - - <para> - Please submit any bug reports or enhancement requests to the - "gdm" category in - <ulink type="http" url="http://bugzilla.gnome.org/"> - http://bugzilla.gnome.org</ulink>. - </para> - </sect2> - - <sect2 id="stability"> - <title>Interface Stability</title> - - <para> - GDM 2.20 and earlier supported stable configuration interfaces. - However, the codebase was completely rewritten for GDM 2.22, and - is not completely backward compatible with older releases. This is - in part because things work differently, so some options just don't - make sense, in part because some options never made sense, and in - part because some functionality has not been reimplemented yet. - </para> - - <para> - Interfaces which continue to be supported in a stable fashion include - the Init, PreSession, PostSession, PostLogin, and Xsession scripts. - Some daemon configuration options in the - <filename><etc>/gdm/custom.conf</filename> file continue to be - supported. Also, the <filename>~/.dmrc</filename>, and face browser - image locations are still supported. - </para> - - <para> - GDM 2.20 and earlier supported the ability to manage multiple displays - with separate graphics cards, such as used in terminal server - environments, login in a window via a program like Xnest or Xephyr, the - gdmsetup program, XML-based greeter themes, and the ability to run the - XDMCP chooser from the login screen. These features were not - added back during the 2.22 rewrite. - </para> - - </sect2> - - <sect2 id="functionaldesc"> - <title>Functional Description</title> - -<!-- -<para> - TODO - Would be good to discuss D-Bus, perhaps the new GObject model, - and to explain the reasons why the rewrite made GDM better. - From a high-level overview perspective, rather than the - technical aspects. -</para> ---> - - <para> - GDM is responsible for managing displays on the system. This includes - authenticating users, starting the user session, and terminating the - user session. GDM is configurable and the ways it can be configured - are described in the "Configuring GDM" section of this - document. GDM is also accessible for users with disabilities. - </para> - - <para> - GDM provides the ability to manage the main console display, and - displays launched via VT. It is integrated with other programs, - such as the Fast User Switch Applet (FUSA) and gnome-screensaver - to manage multiple displays on the console via the Xserver Virtual - Terminal (VT) interface. It also can manage XDMCP displays. - </para> - - <para> - Regardless of the display type, GDM will do the following when it - manages the display. It will start an Xserver process, then run the - <filename>Init</filename> script as the root user, and start the - greeter program on the display. - </para> - - <para> - The greeter program is run as the unprivileged "gdm" - user/group. This user and group are described in the - "Security" section of this document. The main functions of - the greeter program are to provide a mechanism for selecting - an account for log in and to drive the dialogue between - the user and system when authenticating that account. The authentication - process is driven by Pluggable Authentication Modules (PAM). The PAM - modules determine what prompts (if any) are shown to the user to - authenticate. On the average system, the greeter program will request - a username and password for authentication. However some systems may - be configured to use supplemental mechanisms such as a fingerprint or - SmartCard readers. GDM can be configured to support these - alternatives in parallel with greeter login extensions and the - <command>--enable-split-authentication</command> - <filename>./configure</filename> option, or one at a - time via system PAM configuration. - </para> - - <para> - The smartcard extension can be enabled or disabled via the - <filename>org.gnome.display-manager.extensions.smartcard.active</filename> - gsettings key. - </para> - - <para> - Likewise, the fingerprint extension can be enabled or disabled via the - <filename>org.gnome.display-manager.extensions.fingerprint.active</filename> - gsettings key. - </para> - - <para> - GDM and PAM can be configured to not require any - input, which will cause GDM to automatically log in and simply - start a session, which can be useful for some environments, such as - single user systems or kiosks. - </para> - - <para> - In addition to authentication, the greeter program allows the user to - select which session to start and which language to use. Sessions are - defined by files that end in the .desktop suffix and more information - about these files can be found in the "GDM User Session and Language - Configuration" section of this document. By default, GDM is configured - to display a face browser so the user can select their user account by - clicking on an image instead of having to type their username. GDM - keeps track of the user's default session and language in the user's - <filename>~/.dmrc</filename> and will use these defaults if the user - did not pick a session or language in the login GUI. - </para> - - <para> - After authenticating a user, the daemon runs the - <filename>PostLogin</filename> script as root, then runs the - <filename>PreSession</filename> script as root. After running these - scripts, the user session is started. When the user exits their - session, the <filename>PostSession</filename> script is run as root. - These scripts are provided as hooks for distributions and end-users - to customize how sessions are managed. For example, using these - hooks you could set up a machine which creates the user's $HOME - directory on the fly, and erases it on logout. The difference - between the <filename>PostLogin</filename> and - <filename>PreSession</filename> scripts is that - <filename>PostLogin</filename> is run before the pam_open_session call - so is the right place to do anything which should be run before the - user session is initialized. The <filename>PreSession</filename> - script is called after session initialization. - </para> - </sect2> - - <sect2 id="greeterpanel"> - <title>Greeter Panel</title> - <para> - The GDM greeter program displays a panel docked at the bottom of the - screen which provides additional functionality. When a user is - selected, the panel allows the user to select which session, language, - and keyboard layout to use after logging in. The keyboard layout - selector also changes the keyboard layout used when typing your - password. The panel also contains an area for login services to leave - status icons. Some example status icons include a battery icon for - current battery usage, and an icon for enabling accessibility features. - The greeter program also provides buttons which allow the user to - shutdown or restart the system. It is possible to configure GDM to not - provide the shutdown and restart buttons, if desired. GDM can also be - configured via PolicyKit (or via RBAC on Oracle Solaris) to require the - user have appropriate authorization before accepting the shutdown or - restart request. - </para> - - <para> - Note that keyboard layout features are only available on systems that - support libxklavier. - </para> - </sect2> - - <sect2 id="accessibility"> - <title>Accessibility</title> - - <para> - GDM supports "Accessible Login", allowing users to log into - their desktop session even if they cannot easily use the screen, - mouse, or keyboard in the usual way. Accessible Technology (AT) - features such as an on-screen keyboard, screen reader, screen - magnifier, and Xserver AccessX keyboard accessibility are available. - It is also possible to enable large text or high contrast icons and - controls, if needed. Refer to the "Accessibility - Configuration" section of the document for more information - how various accessibility features can be configured. - </para> - - <para> - On some Operating Systems, it is necessary to make sure that the GDM - user is a member of the "audio" group for AT programs that - require audio output (such as text-to-speech) to be functional. - </para> - </sect2> - - <sect2 id="facebrowser"> - <title>The GDM Face Browser</title> - - <para> - The Face Browser is the interface which allows users to select their - username by clicking on an image. This feature can be enabled or - disabled via the /apps/gdm/simple-greeter/disable_user_list GConf - key and is on by default. When disabled, users must type their - complete username by hand. When enabled, it displays all local users - which are available for login on the system (all user accounts defined - in the /etc/passwd file that have a valid shell and sufficiently high - UID) and remote users that have recently logged in. - The face browser in GDM 2.20 and earlier would attempt to display all - remote users, which caused performance problems in large, - enterprise deployments. - </para> - - <para> - The Face Browser is configured to display the users who log in most - frequently at the top of the list. This helps to ensure that users - who log in frequently can quickly find their login image. - </para> - - <para> - The Face Browser supports "type-ahead search" which dynamically - moves the face selection as the user types to the corresponding username - in the list. This means that a user with a long username will only - have to type the first few characters of the username before the correct - item in the list gets selected. - </para> - - <para> - The icons used by GDM can be installed globally by the sysadmin or can - be located in the user's home directories. If installed globally - they should be in the <filename><share>/pixmaps/faces/</filename> - directory and the filename should be the name of the user. Face image - files should be a standard image that GTK+ can read, such as PNG or - JPEG. Face icons placed in the global face directory must be readable - to the GDM user. - </para> - -<!-- -<para> - TODO - In the old GDM the ~/gnome2/gdm file is used, but the new code - seems to use ~/.gnome/gdm. Error? -</para> ---> - <para> - If there is no global icon for the user, GDM will look in the user's - $HOME directory for the image file. GDM will first look for the user's - face image in <filename>~/.face</filename>. If not found, it will try - <filename>~/.face.icon</filename>. If still not found, it will use the - value defined for "face/picture=" in the - <filename>~/.gnome2/gdm</filename> file. - </para> - - <para> - If a user has no defined face image, GDM will use the - "stock_person" icon defined in the current GTK+ theme. If no - such image is defined, it will fallback to a generic face image. - </para> - - <para> - Please note that loading and scaling face icons located in remote user - home directories can be a very time-consuming task. Since it not - practical to load images over NIS or NFS, GDM does not attempt to load - face images from remote home directories. - </para> - - <para> - When the browser is turned on, valid usernames on the computer are - exposed for everyone to see. If XDMCP is enabled, then the usernames - are exposed to remote users. This, of course, limits security - somewhat since a malicious user does not need to guess valid usernames. - In some very restrictive environments the face browser may not be - appropriate. - </para> - - </sect2> - - <sect2 id="xdmcp"> - <title>XDMCP</title> - -<!-- -<para> - TODO - What XDMCP features actually work? I know that the - chooser is missing. -</para> ---> - - <para> - The GDM daemon can be configured to listen for and manage X Display - Manage Protocol (XDMCP) requests from remote displays. By default - XDMCP support is turned off, but can be enabled if desired. If GDM is - built with TCP Wrapper support, then the daemon will only grant access - to hosts specified in the GDM service section in the TCP Wrappers - configuration file. - </para> - - <para> - GDM includes several measures making it more resistant to denial of - service attacks on the XDMCP service. A lot of the protocol - parameters, handshaking timeouts, etc. can be fine tuned. The default - configuration should work reasonably on most systems. - </para> - - <para> - GDM by default listens for XDMCP requests on the normal UDP port used - for XDMCP, port 177, and will respond to QUERY and BROADCAST_QUERY - requests by sending a WILLING packet to the originator. - </para> - - <para> - GDM can also be configured to honor INDIRECT queries and present a - host chooser to the remote display. GDM will remember the user's - choice and forward subsequent requests to the chosen manager. GDM - also supports an extension to the protocol which will make it forget - the redirection once the user's connection succeeds. This extension - is only supported if both daemons are GDM. It is transparent and - will be ignored by XDM or other daemons that implement XDMCP. - </para> - - <para> - If XDMCP seems to not be working, make sure that all machines are - specified in <filename>/etc/hosts</filename>. - </para> - - <para> - Refer to the "Security" section for information about - security concerns when using XDMCP. - </para> - </sect2> - - <sect2 id="logging"> - <title>Logging</title> - - <para> - GDM uses syslog to log errors and status. It can also log debugging - information, which can be useful for tracking down problems if GDM is - not working properly. Debug output can be enabled by setting the - debug/Enable key to "true" in the - <filename><etc>/gdm/custom.conf</filename> file. - </para> - - <para> - Output from the various Xservers is stored in the GDM log directory, - which is normally <filename><var>/log/gdm/</filename>. Any - Xserver messages are saved to a file associated with the display value, - <filename><display>.log</filename>. - </para> - - <para> - The session output is piped through the GDM daemon to the - <filename>~/.xsession-errors</filename> file. The file is overwritten - on each login, so logging out and logging back into the same user via - GDM will cause any messages from the previous session to be lost. - </para> - - <para> - Note that if GDM can not create this file for some reason, then a - fallback file will be created named <filename>~/.xsession-errors.XXXXXXXX</filename> - where the <filename>XXXXXXXX</filename> are some random characters. - </para> - </sect2> - - <sect2 id="fusa"> - <title>Fast User Switching</title> - - <para> - GDM allows multiple users to be logged in at the same time. After one - user is logged in, additional users can log in via the User Switcher - on the GNOME Panel, or from the "Switch User" button in Lock Screen dialog - of GNOME Screensaver. The active session can be changed back and forth using - the same mechanism. Note that some distributions may not add the User Switcher - to the default panel configuration. It can be added using the panel context - menu. - </para> - <para> - Note this feature is available on systems that support Virtual - Terminals. This feature will not function if Virtual Terminals is not - available. - </para> - </sect2> - </sect1> - - <!-- ============= Security ================================= --> - - <sect1 id="security"> - <title>Security</title> - - <sect2 id="gdmuser"> - <title>The GDM User And Group</title> - - <para> - For security reasons a dedicated user and group id are recommended for - proper operation. This user and group are normally "gdm" on - most systems, but can be configured to any user or group. All GDM - GUI programs are run as this user, so that the programs which interact - with the user are run in a sandbox. This user and group should have - limited privilege. - </para> - - <para> - The only special privilege the "gdm" user requires is the - ability to read and write Xauth files to the - <filename><var>/run/gdm</filename> directory. The - <filename><var>/run/gdm</filename> directory should have - root:gdm ownership and 1777 permissions. - </para> - - <para> - You should not, under any circumstances, configure the GDM user/group - to a user which a user could easily gain access to, such as the user - <filename>nobody</filename>. Any user who gains access to an Xauth - key can snoop on and control running GUI programs running in the - associated session or perform a denial-of-service attack on it. It - is important to ensure that the system is configured properly so that - only the "gdm" user has access to these files and that it - is not easy to login to this account. For example, the account should - be setup to not have a password or allow non-root users to login to the - account. - </para> - - <para> - The GDM greeter configuration is stored in GConf. To allow the GDM - user to be able to write configuration, it is necessary for the - "gdm" user to have a writable $HOME directory. Users may - configure the default GConf configuration as desired to avoid the - need to provide the "gdm" user with a writable $HOME - directory. However, some features of GDM may be disabled if it is - unable to write state information to GConf configuration. - </para> - </sect2> - - <sect2 id="PAM"> - <title>PAM</title> - - <para> - GDM uses PAM for login authentication. PAM stands for Pluggable - Authentication Module, and is used by most programs that request - authentication on your computer. It allows the administrator to - configure specific authentication behavior for different login programs - (such as ssh, login GUI, screensaver, etc.) - </para> - - <para> - PAM is complicated and highly configurable, and this documentation does - not intend to explain this in detail. Instead, it is intended to give - an overview of how PAM configuration relates with GDM, how PAM is - commonly configured with GDM, and known issues. It is expected that - a person needing to do PAM configuration would need to do further - reading of PAM documentation to understand how to configure PAM and - to understand terms used in this section. - </para> - - <para> - PAM configuration has different, but similar, interfaces on different - Operating Systems, so check the - <ulink type="help" url="man:pam.d">pam.d</ulink> or - <ulink type="help" url="man:pam.conf">pam.conf</ulink> man page for - details. Be sure you read the PAM documentation and are comfortable - with the security implications of any changes you intend to make to - your configuration. - </para> - - <para> - Note that, by default, GDM uses the "gdm" PAM service name - for normal login and the "gdm-autologin" PAM service name for - automatic login. These services may not be defined in your pam.d or - pam.conf configured file. If there is no entry, then GDM will use the - default PAM behavior. On most systems this should work fine. - However, the automatic login feature may not work if the gdm-autologin - service is not defined. - </para> - - <para> - The <filename>PostLogin</filename> script is run before - pam_open_session is called, and the <filename>PreSession</filename> - script is called after. This allows the system administrator to add - any scripting to the login process either before or after PAM - initializes the session. - </para> - - <para> - If you wish to make GDM work with other types of authentication - mechanisms (such as a fingerprint or SmartCard reader), then you should - implement this by using a PAM service module for the desired - authentication type rather than by trying to modify the GDM code - directly. Refer to the PAM documentation on your system. How to do - this is frequently discussed on the - <address><email>gdm-list@gnome.org</email></address> mail list, - so you can refer to the list archives for more information. - </para> - - <para> - PAM does have some limitations regarding being able to work with - multiple types of authentication at the same time, like supporting - the ability to accept either SmartCard and the ability to type the - username and password into the login program. There are techniques - that are used to make this work, and it is best to research how this - problem is commonly solved when setting up such a configuration. - </para> - - <para> - If automatic login does not work on a system, check to see if the - "gdm-autologin" PAM stack is defined in the PAM configuration. For - this to work, it is necessary to use a PAM module that simply does no - authentication, or which simply returns PAM_SUCCESS from all of its - public interfaces. Assuming your system has a pam_allow.so PAM module - which does this, a PAM configuration to enable "gdm-autologin" would - look like this: - </para> - -<screen> - gdm-autologin auth required pam_unix_cred.so.1 - gdm-autologin auth sufficient pam_allow.so.1 - gdm-autologin account sufficient pam_allow.so.1 - gdm-autologin session sufficient pam_allow.so.1 - gdm-autologin password sufficient pam_allow.so.1 -</screen> - - <para> - The above setup will cause no lastlog entry to be generated. If a - lastlog entry is desired, then use the following for the session: - </para> - -<screen> - gdm-autologin session required pam_unix_session.so.1 -</screen> - - <para> - If the computer is used by several people, which makes automatic login - unsuitable, you may want to allow some users to log in without entering - their password. This feature can be enabled as a per-user option in - the users-admin tool from the gnome-system-tools; it is achieved by - checking that the user is member a Unix group called - "nopasswdlogin" before asking for a password. For this to work, - the PAM configuration file for the "gdm" service must include - a line such as: - </para> - -<screen> - gdm auth sufficient pam_succeed_if.so user ingroup nopasswdlogin -</screen> - - </sect2> - - <sect2 id="utmpwtmp"> - <title>utmp and wtmp</title> - - <para> - GDM generates utmp and wtmp User Accounting Database entries upon - session login and logout. The utmp database contains user access - and accounting information that is accessed by commands such as - <command>finger</command>, <command>last</command>, - <command>login</command>, and <command>who</command>. The wtmp - database contains the history of user access and accounting - information for the utmp database. Refer to the - <ulink type="help" url="man:utmp">utmp</ulink> and - <ulink type="help" url="man:wtmp">wtmp</ulink> - man pages on your system for more information. - </para> - </sect2> - - <sect2 id="xauth"> - <title>Xserver Authentication Scheme</title> - - <para> - Xserver authorization files are stored in a newly created subdirectory - of <filename><var>/run/gdm</filename> at start up. These files - are used to store and share a "password" between X clients - and the Xserver. This "password" is unique for each session - logged in, so users from one session can't snoop on users from another. - </para> - - <para> - GDM only supports the MIT-MAGIC-COOKIE-1 Xserver authentication - scheme. Normally little is gained from the other schemes, and no - effort has been made to implement them so far. Be especially - careful about using XDMCP because the Xserver authentication cookie - goes over the wire as clear text. If snooping is possible, then an - attacker could simply snoop your authentication password as you log in, - regardless of the authentication scheme being used. If snooping is - possible and undesirable, then you should use ssh for tunneling an X - connection rather then using XDMCP. You could think of XDMCP as a sort - of graphical telnet, having the same security issues. In most cases, - ssh -Y should be preferred over GDM's XDMCP features. - </para> - - </sect2> - - <sect2 id="xdmcpsecurity"> - <title>XDMCP Security</title> - - <para> - Even though your display is protected by cookies, XEvents and thus - keystrokes typed when entering passwords will still go over the wire in - clear text. It is trivial to capture these. - </para> - - <para> - XDMCP is primarily useful for running thin clients such as in terminal - labs. Those thin clients will only ever need the network to access - the server, and so it seems like the best security policy to have - those thin clients on a separate network that cannot be accessed by - the outside world, and can only connect to the server. The only point - from which you need to access outside is the server. This type of set up - should never use an unmanaged hub or other sniffable network. - </para> - - </sect2> - - <sect2 id="xdmcpaccess"> - <title>XDMCP Access Control</title> - - <para> - XDMCP access control is done using TCP wrappers. It is possible to - compile GDM without TCP wrapper support, so this feature may not be - supported on some Operating Systems. - </para> - - <para> - You should use the daemon name <command>gdm</command> in the - <filename><etc>/hosts.allow</filename> and - <filename><etc>/hosts.deny</filename> files. For example to - deny computers from <filename>.evil.domain</filename> from logging in, - then add - </para> -<screen> -gdm: .evil.domain -</screen> - <para> - to <filename><etc>/hosts.deny</filename>. You may also need - to add - </para> -<screen> -gdm: .your.domain -</screen> - <para> - to your <filename><etc>/hosts.allow</filename> if you normally - disallow all services from all hosts. See the - <ulink type="help" url="man:hosts.allow">hosts.allow(5)</ulink> man - page for details. - </para> - </sect2> - - <sect2 id="firewall"> - <title>Firewall Security</title> - - <para> - Even though GDM tries to outsmart potential attackers trying to take - advantage of XDMCP, it is still advised that you block the XDMCP port - (normally UDP port 177) on your firewall unless really needed. GDM - guards against denial of service attacks, but the X protocol is still - inherently insecure and should only be used in controlled environments. - Also each remote connection takes up lots of resources, so it is much - easier to do a denial of service attack via XDMCP than attacking a - webserver. - </para> - - <para> - It is also wise to block all of the Xserver ports. These are TCP - ports 6000+ (one for each display number) on your firewall. Note that - GDM will use display numbers 20 and higher for flexible on-demand - servers. - </para> - - <para> - X is not a very safe protocol when using it over the Internet, and - XDMCP is even less safe. - </para> - </sect2> - - <sect2 id="policykit"> - <title>PolicyKit</title> - -<!-- -<para> - TODO - Should we say more? -</para> ---> - - <para> - GDM may be configured to use PolicyKit to allow the system - administrator to control whether the login screen should provide - the shutdown and restart buttons on the greeter screen. - </para> - - <para> - These buttons are controlled by the - <filename>org.freedesktop.consolekit.system.stop-multiple-users</filename> - and - <filename>org.freedesktop.consolekit.system.restart-multiple-users</filename> - actions respectively. Policy for these actions can be set up using the - polkit-gnome-authorization tool, or the polkit-auth command line program. - </para> - - </sect2> - - <sect2 id="rbac"> - <title>RBAC (Role Based Access Control)</title> - - <para> - GDM may be configured to use RBAC instead of PolicyKit. In this - case the RBAC configuration is used to control whether the login screen - should provide the shutdown and restart buttons on the greeter screen. - </para> - - <para> - For example, on Oracle Solaris, the "solaris.system.shutdown" - authorization is used to control this. Simply modify the - <filename>/etc/user_attr</filename> file so that the "gdm" - user has this authorization. - </para> - </sect2> - - </sect1> - - <!-- ============= ConsoleKit ================================ --> - - <sect1 id="consolekit"> - <title>Support for ConsoleKit</title> - -<!-- -<para> - TODO - Should we update these docs? Probably should mention any - configuration that users may want to do for using it with GDM? - If so, perhaps this section should be moved to a subsection of - the "Configure" section? -</para> ---> - - <para> - GDM includes support for publishing user login information with the user - and login session accounting framework known as ConsoleKit. ConsoleKit - is able to keep track of all the users currently logged in. In this - respect, it can be used as a replacement for the utmp or utmpx files that - are available on most Unix-like Operating Systems. - </para> - - <para> - When GDM is about to create a new login process for a user it will call - a privileged method of ConsoleKit in order to open a new session for this - user. At this time GDM also provides ConsoleKit with information about - this user session such as: the user ID, the X11 Display name that will be - associated with the session, the host-name from which the session - originates (useful in the case of an XDMCP session), whether or not this - session is attached, etc. As the entity that initiates the user process, - GDM is in a unique position to know about the user session and to be - trusted to provide these bits of information. The use of this privileged - method is restricted by the use of the D-Bus system message bus security - policy. - </para> - - <para> - In case a user with an existing session has authenticated - at GDM and requests to resume that existing session, GDM calls a - privileged method of ConsoleKit to unlock that session. The exact - details of what happens when the session receives this unlock signal are - undefined and session-specific. However, most sessions will unlock a - screensaver in response. - </para> - - <para> - When the user chooses to log out, or if GDM or the session quit - unexpectedly the user session will be unregistered from ConsoleKit. - </para> - </sect1> - - <!-- ============= Configuration ============================= --> - - <sect1 id="configuration"> - <title>Configuration</title> - - <para> - GDM has a number of configuration interfaces. These include scripting - integration points, daemon configuration, greeter configuration, - general session settings, integration with gnome-settings-daemon - configuration, and session configuration. These types of integration are - described in detail below. - </para> - - <sect2 id="scripting"> - <title>Scripting Integration Points</title> - - <para> - The GDM script integration points can be found in the - <filename><etc>/gdm/</filename> directory: - </para> - -<screen> -Xsession -Init/ -PostLogin/ -PreSession/ -PostSession/ -</screen> - - <para> - The <filename>Init</filename>, <filename>PostLogin</filename>, - <filename>PreSession</filename>, and <filename>PostSession</filename> - scripts all work as described below. - </para> - - <para> - For each type of script, the default one which will be executed is - called "Default" and is stored in a directory associated with - the script type. So the default <filename>Init</filename> script is - <filename><etc>/gdm/Init/Default</filename>. A per-display - script can be provided, and if it exists it will be run instead of the - default script. Such scripts are stored in the same directory as the - default script and have the same name as the Xserver DISPLAY value for - that display. For example, if the <filename><Init>/:0</filename> - script exists, it will be run for DISPLAY ":0". - </para> - - <para> - All of these scripts are run with root privilege and return 0 if run - successfully, and a non-zero return code if there was any failure that - should cause the login session to be aborted. Also note that GDM will - block until the scripts finish, so if any of these scripts hang, this - will cause the login process to also hang. - </para> - - <para> - When the Xserver for the login GUI has been successfully started, but - before the login GUI is actually displayed, GDM will run the - <filename>Init</filename> script. This script is useful for starting - programs that should be run while the login screen is showing, or for - doing any special initialization if required. - </para> - - <para> - After the user has been successfully authenticated GDM will run the - <filename>PostLogin</filename> script. This is done before any session - setup has been done, including before the pam_open_session call. This - script is useful for doing any session initialization that needs to - happen before the session starts. For example, you might setup the - user's $HOME directory if needed. - </para> - - <para> - After the user session has been initialized, GDM will run the - <filename>PreSession</filename> script. This script is useful for - doing any session initialization that needs to happen after the - session has been initialized. It can be used for session management or - accounting, for example. - </para> - - <para> - When a user terminates their session, GDM will run the - <filename>PostSession</filename> script. Note that the Xserver will - have been stopped by the time this script is run, so it should not be - accessed. - </para> - - <para> - Note that the <filename>PostSession</filename> script will be run - even when the display fails to respond due to an I/O error or - similar. Thus, there is no guarantee that X applications will work - during script execution. - </para> - - <para> - All of the above scripts will set the - <filename>$RUNNING_UNDER_GDM</filename> environment variable to - <filename>yes</filename>. If the scripts are also shared with other - display managers, this allows you to identify when GDM is calling these - scripts, so you can run specific code when GDM is used. - </para> - </sect2> - - <sect2 id="autostart"> - <title>Autostart Configuration</title> - - <para> - The <filename><share>/gdm/autostart/LoginWindow</filename> - directory contains files in the format specified by the - "FreeDesktop.org Desktop Application Autostart - Specification". Standard features in the specification may be - used to specify programs that should auto-restart or only be launched - if a GConf configuration value is set, etc. - </para> - - <para> - Any <filename>.desktop</filename> files in this directory will cause - the associated program to automatically start with the login GUI - greeter. By default, GDM is shipped with files which will autostart - the gdm-simple-greeter login GUI greeter itself, the - gnome-power-manager application, the gnome-settings-daemon, and the - metacity window manager. These programs are needed for the greeter - program to work. In addition, desktop files are provided for starting - various AT programs if the configuration values specified in the - Accessibility Configuration section below are set. - </para> - </sect2> - - <sect2 id="xsessionscript"> - <title>Xsession Script</title> - - <para> - There is also an <filename>Xsession</filename> script located at - <filename><etc>/gdm/Xsession</filename> which is called between - the <filename>PreSession</filename> and the - <filename>PostSession</filename> scripts. This script does not - support per-display like the other scripts. This script is used for - actually starting the user session. This script is run as the user, - and it will run whatever session was specified by the Desktop session - file the user selected to start. - </para> - </sect2> - - <sect2 id="daemonconfig"> - <title>Daemon Configuration</title> - - <para> - The GDM daemon is configured using the - <filename><etc>/gdm/custom.conf</filename> file. Default - values are stored in GConf in the <filename>gdm.schemas</filename> - file. It is recommended that end-users modify the - <filename><etc>/gdm/custom.conf</filename> file because the - schemas file may be overwritten when the user updates their system to - have a newer version of GDM. - </para> - - <para> - Note that older versions of GDM supported additional configuration - options which are no longer supported in the latest versions of GDM. - </para> - - <para> - The <filename><etc>/gdm/custom.conf</filename> file is in the - <filename>keyfile</filename> format. Keywords in brackets - define group sections, strings before an equal sign (=) are keys and - the data after equal sign represents their value. Empty lines or - lines starting with the hash mark (#) are ignored. - </para> - - <para> - The file <filename><etc>/gdm/custom.conf</filename> supports the - "[daemon]", "[security]", and "[xdmcp]" - group sections. Within each group, there are particular key/value - pairs that can be specified to modify how GDM behaves. For example, - to enable timed login and specify the timed login user to be a user - named "you", you would modify the file so it contains the - following lines: - </para> - -<screen> -[daemon] -TimedLoginEnable=true -TimedLogin=you -</screen> - - <para> - A full list of supported configuration keys follow: - </para> - - <sect3 id="choosersection"> - <title>[chooser]</title> - <variablelist> - - <varlistentry> - <term>Multicast</term> - <listitem> - <synopsis>Multicast=false</synopsis> - <para> - If true and IPv6 is enabled, the chooser will send a multicast - query to the local network and collect responses from the hosts - who have joined multicast group. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>MulticastAddr</term> - <listitem> - <synopsis>MulticastAddr=ff02::1</synopsis> - <para> - This is the Link-local multicast address. - </para> - </listitem> - </varlistentry> - </variablelist> - </sect3> - - <sect3 id="daemonsection"> - <title>[daemon]</title> - <variablelist> - <varlistentry> - <term>TimedLoginEnable</term> - <listitem> - <synopsis>TimedLoginEnable=false</synopsis> - <para> - If the user given in <filename>TimedLogin</filename> should be - logged in after a number of seconds (set with - <filename>TimedLoginDelay</filename>) of inactivity on the - login screen. This is useful for public access terminals or - perhaps even home use. If the user uses the keyboard or - browses the menus, the timeout will be reset to - <filename>TimedLoginDelay</filename> or 30 seconds, whichever - is higher. If the user does not enter a username but just - hits the ENTER key while the login program is requesting the - username, then GDM will assume the user wants to login - immediately as the timed user. Note that no password will be - asked for this user so you should be careful, although if using - PAM it can be configured to require password entry before - allowing login. Refer to the "Security->PAM" - section of the manual for more information, or for help if this - feature does not seem to work. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>TimedLogin</term> - <listitem> - <synopsis>TimedLogin=</synopsis> - <para> - This is the user that should be logged in after a specified - number of seconds of inactivity. - </para> - <para> - If the value ends with a vertical bar | (the pipe symbol), - then GDM will execute the program specified and use whatever - value is returned on standard out from the program as the user. - The program is run with the DISPLAY environment variable set so - that it is possible to specify the user in a per-display - fashion. For example if the value is "/usr/bin/getloginuser|", - then the program "/usr/bin/getloginuser" will be run to get the - user value. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>TimedLoginDelay</term> - <listitem> - <synopsis>TimedLoginDelay=30</synopsis> - <para> - Delay in seconds before the <filename>TimedLogin</filename> - user will be logged in. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>AutomaticLoginEnable</term> - <listitem> - <synopsis>AutomaticLoginEnable=false</synopsis> - <para> - If true, the user given in <filename>AutomaticLogin</filename> - should be logged in immediately. This feature is like timed - login with a delay of 0 seconds. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>AutomaticLogin</term> - <listitem> - <synopsis>AutomaticLogin=</synopsis> - <para> - This is the user that should be logged in immediately if - <filename>AutomaticLoginEnable</filename> is true. - </para> - <para> - If the value ends with a vertical bar | (the pipe symbol), - then GDM will execute the program specified and use whatever - value is returned on standard out from the program as the user. - The program is run with the DISPLAY environment variable set so - that it is possible to specify the user in a per-display - fashion. For example if the value is "/usr/bin/getloginuser|", - then the program "/usr/bin/getloginuser" will be run to get the - user value. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>User</term> - <listitem> - <synopsis>User=gdm</synopsis> - <para> - The username under which the greeter and other GUI programs - are run. Refer to the <filename>Group</filename> - configuration key and to the "Security->GDM User And - Group" section of this document for more information. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Group</term> - <listitem> - <synopsis>Group=gdm</synopsis> - <para> - The group name under which the greeter and other GUI programs - are run. Refer to the <filename>User</filename> - configuration key and to the "Security->GDM User And - Group" section of this document for more information. - </para> - </listitem> - </varlistentry> - </variablelist> - </sect3> - - <sect3 id="debugsection"> - <title>Debug Options</title> - - <variablelist> - <title>[debug]</title> - - <varlistentry> - <term>Enable</term> - <listitem> - <synopsis>Enable=false</synopsis> - <para> - To enable debugging, set the debug/Enable key to - "true" in the - <filename><etc>/gdm/custom.conf</filename> - file and restart GDM. Then debug output will be sent to the - system log file (<filename><var>/log/messages</filename> - or <filename><var>/adm/messages</filename> depending on - your Operating System). - </para> - </listitem> - </varlistentry> - </variablelist> - </sect3> - - <sect3 id="greetersection"> - <title>Greeter Options</title> - - <variablelist> - <title>[greeter]</title> - - <varlistentry> - <term>IncludeAll</term> - <listitem> - <synopsis>IncludeAll=true</synopsis> - <para> - If true, then the face browser will show all users on the local - machine. If false, the face browser will only show users who - have recently logged in. - </para> - - <para> - When this key is true, GDM will call fgetpwent() to get a list - of local users on the system. Any users with a user id less - than 500 (or 100 if running on Oracle Solaris) are filtered - out. The Face Browser also will display any users that have - previously logged in on the system (for example NIS/LDAP - users). It gets this list via calling the - <command>ck-history</command> ConsoleKit interface. It will - also filter out any users which do not have a valid shell - (valid shells are any shell that getusershell() returns - - /sbin/nologin or /bin/false are considered invalid shells even - if getusershell() returns them). - </para> - - <para> - If false, then GDM more simply only displays users that have - previously logged in on the system (local or NIS/LDAP users) by - calling the <command>ck-history</command> ConsoleKit interface. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Include</term> - <listitem> - <synopsis>Include=</synopsis> - <para> - Set to a list of users to always include in the Face Browser. - This value is set to a list of users separated by commas. By - default, the value is empty. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Exclude</term> - <listitem> - <synopsis>Exclude=bin,root,daemon,adm,lp,sync,shutdown,halt,mail,news,uucp,operator,nobody,nobody4,noaccess,postgres,pvm,rpm,nfsnobody,pcap</synopsis> - <para> - Set to a list of users to always exclude in the Face Browser. - This value is set to a list of users separated by commas. Note - that the setting in the <filename>custom.conf</filename> - overrides the default value, so if you wish to add additional - users to the list, then you need to set the value to the - default value with additional users appended to the list. - </para> - </listitem> - </varlistentry> - </variablelist> - </sect3> - - <sect3 id="securitysection"> - <title>Security Options</title> - - <variablelist> - <title>[security]</title> - - <varlistentry> - <term>DisallowTCP</term> - <listitem> - <synopsis>DisallowTCP=true</synopsis> - <para> - If true, then always append <filename>-nolisten tcp</filename> - to the command line when starting attached Xservers, thus - disallowing TCP connection. This is a more secure - configuration if you are not using remote connections. - </para> - </listitem> - </varlistentry> - </variablelist> - </sect3> - - <sect3 id="xdmcpsection"> - <title>XDCMP Support</title> - - <variablelist> - <title>[xdmcp]</title> - - <varlistentry> - <term>DisplaysPerHost</term> - <listitem> - <synopsis>DisplaysPerHost=1</synopsis> - <para> - To prevent attackers from filling up the pending queue, GDM - will only allow one connection for each remote computer. If - you want to provide display services to computers with more - than one screen, you should increase this value. - </para> - - <para> - Note that the number of attached DISPLAYS allowed is not - limited. Only remote connections via XDMCP are limited by - this configuration option. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Enable</term> - <listitem> - <synopsis>Enable=false</synopsis> - <para> - Setting this to true enables XDMCP support allowing remote - displays/X terminals to be managed by GDM. - </para> - - <para> - <filename>gdm</filename> listens for requests on UDP port 177. - See the Port option for more information. - </para> - - <para> - If GDM is compiled to support it, access from remote displays - can be controlled using the TCP Wrappers library. The service - name is <filename>gdm</filename> - </para> - - <para> - You should add -<screen> -gdm:.my.domain -</screen> - to your <filename><etc>/hosts.allow</filename>, depending - on your TCP Wrappers configuration. See the - <ulink type="help" url="man:hosts.allow">hosts.allow</ulink> - man page for details. - </para> - - <para> - Please note that XDMCP is not a particularly secure protocol - and that it is a good idea to block UDP port 177 on your - firewall unless you really need it. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>HonorIndirect</term> - <listitem> - <synopsis>HonorIndirect=true</synopsis> - <para> - Enables XDMCP INDIRECT choosing (i.e. remote execution of - <filename>gdmchooser</filename>) for X-terminals which do not - supply their own display browser. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>MaxPending</term> - <listitem> - <synopsis>MaxPending=4</synopsis> - <para> - To avoid denial of service attacks, GDM has fixed size queue - of pending connections. Only MaxPending displays can start at - the same time. - </para> - - <para> - Please note that this parameter does not limit the number of - remote displays which can be managed. It only limits the number - of displays initiating a connection simultaneously. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>MaxSessions</term> - <listitem> - <synopsis>MaxSessions=16</synopsis> - <para> - Determines the maximum number of remote display connections - which will be managed simultaneously. I.e. the total number of - remote displays that can use your host. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>MaxWait</term> - <listitem> - <synopsis>MaxWait=30</synopsis> - <para> - When GDM is ready to manage a display an ACCEPT packet is sent - to it containing a unique session id which will be used in - future XDMCP conversations. - </para> - - <para> - GDM will then place the session id in the pending queue - waiting for the display to respond with a MANAGE request. - </para> - - <para> - If no response is received within MaxWait seconds, GDM will - declare the display dead and erase it from the pending queue - freeing up the slot for other displays. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>MaxWaitIndirect</term> - <listitem> - <synopsis>MaxWaitIndirect=30</synopsis> - <para> - The MaxWaitIndirect parameter determines the maximum number of - seconds between the time where a user chooses a host and the - subsequent indirect query where the user is connected to the - host. When the timeout is exceeded, the information about the - chosen host is forgotten and the indirect slot freed up for - other displays. The information may be forgotten earlier if - there are more hosts trying to send indirect queries then - <filename>MaxPendingIndirect</filename>. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>PingIntervalSeconds</term> - <listitem> - <synopsis>PingIntervalSeconds=60</synopsis> - <para> - If the Xserver does not respond in the specified number of - seconds, then the connection is stopped and the session ended. - When this happens the slave daemon dies with an ALARM signal. - Note that GDM 2.20 and earlier multiplied this setting by 2, - so it may be necessary to increase the timeout if upgrading - from GDM 2.20 and earlier to a newer version. - </para> - - <para> - Note that GDM in the past used to have a - <filename>PingInterval</filename> configuration key which was - also in minutes. For most purposes you'd want this setting - to be lower than one minute. However since in most cases where - XDMCP would be used (such as terminal labs), a lag of more - than 15 or so seconds would really mean that the terminal was - turned off or restarted and you would want to end the session. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Port</term> - <listitem> - <synopsis>Port=177</synopsis> - <para> - The UDP port number <filename>gdm</filename> should listen to - for XDMCP requests. Do not change this unless you know what - you are doing. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Willing</term> - <listitem> - <synopsis>Willing=<etc>/gdm/Xwilling</synopsis> - <para> - When the machine sends a WILLING packet back after a QUERY it - sends a string that gives the current status of this server. - The default message is the system ID, but it is possible to - create a script that displays customized message. If this - script does not exist or this key is empty the default message - is sent. If this script succeeds and produces some output, - the first line of it's output is sent (and only the first - line). It runs at most once every 3 seconds to prevent - possible denial of service by flooding the machine with QUERY - packets. - </para> - </listitem> - </varlistentry> - </variablelist> - </sect3> - </sect2> - - <sect2 id="greeterconfiguration"> - <title>Simple Greeter Configuration</title> - - <para> - The GDM default greeter is called the simple Greeter and is - configured via GConf. Default values are stored in GConf in the - <filename>gdm-simple-greeter.schemas</filename> file. These defaults - can be overridden if the "gdm" user has a writable $HOME - directory to store GConf settings. These values can be edited using - the <command>gconftool-2</command> or <command>gconf-editor</command> - programs. The following configuration options are supported: - </para> - - <variablelist> - <title>Greeter Configuration Keys</title> - - <varlistentry> - <term>/apps/gdm/simple-greeter/banner_message_enable</term> - <listitem> - <synopsis>false (boolean)</synopsis> - <para> - Controls whether the banner message text is displayed. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>/apps/gdm/simple-greeter/banner_message_text</term> - <listitem> - <synopsis>NULL (string)</synopsis> - <para> - Specifies the text banner message to show on the greeter - window. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>/apps/gdm/simple-greeter/disable_restart_buttons</term> - <listitem> - <synopsis>false (boolean)</synopsis> - <para> - Controls whether to show the restart buttons in the login - window. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>/apps/gdm/simple-greeter/disable_user_list</term> - <listitem> - <synopsis>false (boolean)</synopsis> - <para> - If true, then the face browser with known users is not shown - in the login window. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>/apps/gdm/simple-greeter/logo_icon_name</term> - <listitem> - <synopsis>computer (string)</synopsis> - <para> - Set to the themed icon name to use for the greeter logo. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>/apps/gdm/simple-greeter/recent-languages</term> - <listitem> - <synopsis>[] (string list)</synopsis> - <para> - Set to a list of languages to be shown by default in the login - window. Default value is "[]". With the default setting only - the system default language is shown and the option "Other..." - which pops-up a dialog box showing a full list of available - languages which the user can select. - </para> - - <para> - Users are not intended to change this setting by hand. Instead - GDM keeps track of any languages selected in this configuration - key, and will show them in the language combo box along with - the "Other..." choice. This way, commonly selected languages - are easier to select. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>/apps/gdm/simple-greeter/recent-layouts</term> - <listitem> - <synopsis>[] (string list)</synopsis> - <para> - Set to a list of keyboard layouts to be shown by default in the - login panel. Default value is "[]". With the default setting - only the system default keyboard layout is shown and the option - "Other..." which pops-up a dialog box showing a full list of - available keyboard layouts which the user can select. - </para> - - <para> - Users are not intended to change this setting by hand. Instead - GDM keeps track of any keyboard layouts selected in this - configuration key, and will show them in the keyboard layout - combo box along with the "Other..." choice. This way, commonly - selected keyboard layouts are easier to select. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>/apps/gdm/simple-greeter/wm_use_compiz</term> - <listitem> - <synopsis>false (boolean)</synopsis> - <para> - Controls whether compiz is used as the window manager instead - of metacity. - </para> - </listitem> - </varlistentry> - </variablelist> - </sect2> - - <sect2 id="accessibilityconfiguration"> - <title>Accessibility Configuration</title> - - <para> - This section describes the accessibility configuration options available - in GDM. - </para> - - <sect3 id="accessibilitydialog"> - <title>GDM Accessibility Dialog And GConf Keys</title> - - <para> - The GDM greeter panel at the login screen displays an accessibility - icon. Clicking on that icon opens the GDM Accessibility Dialog. In - the GDM Accessibility Dialog, there is a list of checkboxes, so the - user can enable or disable the associated assistive tools. - </para> - - <para> - The checkboxes that correspond to the on-screen keyboard, screen - magnifier and screen reader assistive tools act on the three GConf - keys that are described in the next section of this document. By - enabling or disabling these checkboxes, the associated GConf key is - set to "true" or "false". When the GConf key is set to true, the - assistive tools linked to this GConf key are launched. When the - GConf key is set to "false", any running assistive tool linked to - this GConf key are terminated. These GConf keys are not automatically - reset to a default state after the user has logged in. Consequently, - the assistive tools that were running during the last GDM login - session will automatically be launched at the next GDM login session. - </para> - - <para> - The other checkboxes in the GDM Accessibility Dialog do not have - corresponding GConf keys because no additional program is launched to - provide the accessibility features that they offer. These other - options correspond to accessibility features that are provided by the - Xserver, which is always running during the GDM session. - </para> - </sect3> - - <sect3 id="accessibilitygconfconfiguration"> - <title>Accessibility GConf Keys</title> - - <para> - GDM offers the following GConf keys to control its accessibility - features: - </para> - - <variablelist> - <title>GDM Configuration Keys</title> - - <varlistentry> - <term>/desktop/gnome/interface/accessibility</term> - <listitem> - <synopsis>false (boolean)</synopsis> - <para> - Controls whether the Accessibility infrastructure will be - started with the GDM GUI. This is needed for many - accessibility technology programs to work. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term>/desktop/gnome/applications/at/screen_magnifier_enabled</term> - <listitem> - <synopsis>false (boolean)</synopsis> - <para> - If set, then the assistive tools linked to this GConf key will - be started with the GDM GUI program. By default this is a - screen magnifier application. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term>/desktop/gnome/applications/at/screen_keyboard_enabled</term> - <listitem> - <synopsis>false (boolean)</synopsis> - <para> - If set, then the assistive tools linked to this GConf key will - be started with the GDM GUI program. By default this is an - on-screen keyboard application. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term>/desktop/gnome/applications/at/screen_reader_enabled</term> - <listitem> - <synopsis>false (boolean)</synopsis> - <para> - If set, then the assistive tools linked to this GConf key will - be started with the GDM GUI program. By default this is a - screen reader application. - </para> - </listitem> - </varlistentry> - </variablelist> - </sect3> - - <sect3 id="accessibilitytoolsconfiguration"> - <title>Linking GConf Keys to Accessbility Tools</title> - - <para> - For the screen_magnifier_enabled, the screen_keyboard_enabled, and the - screen_reader_enabled GConf keys, the assistive tool which gets - launched depends on the desktop files located in the GDM autostart - directory as described in the "Autostart Configuration" section of - this manual. Any desktop file in the GDM autostart directory can be - linked to these GConf key via specifying that GConf key in the - AutostartCondition value in the desktop file. So the exact - AutostartCondition line in the desktop file could be one of the - following: - </para> - -<screen> -AutostartCondition=GNOME /desktop/gnome/applications/at/screen_keyboard_enabled -AutostartCondition=GNOME /desktop/gnome/applications/at/screen_magnifier_enabled -AutostartCondition=GNOME /desktop/gnome/applications/at/screen_reader_enabled -</screen> - - <para> - When an accessibility key is true, then any program which is linked to - that key in a GDM autostart desktop file will be launched (unless the - Hidden key is set to true in that desktop file). A single GConf key - can even start multiple assistive tools if there are multiple desktop - files with this AutostartCondition in the GDM autostart directory. - </para> - </sect3> - - <sect3 id="accessibilitytoolexample"> - <title>Example Of Modifying Accessibility Tool Configuration</title> - - <para> - For example, if GNOME is distributed with GOK as the default on-screen - keyboard, then this could be replaced with a different program if - desired. To replace GOK with the on-screen keyboard application - "onboard" and additionally activate the assistive tool "mousetweaks" - for dwelling support, then the following configuration is needed. - </para> - - <para> - Create a desktop file for onboard and a second one for mousetweaks; - for example, onboard.desktop and mousetweaks.desktop. These files - must be placed in the GDM autostart directory and be in the format - as explained in the "Autostart Configuration" section of this - document. - </para> - - <para> - The following is an example <filename>onboard.desktop</filename> file: - </para> - -<screen> -[Desktop Entry] -Encoding=UTF-8 -Name=Onboard Onscreen Keyboard -Comment=Use an on-screen keyboard -TryExec=onboard -Exec=onboard --size 500x180 -x 20 -y 10 -Terminal=false -Type=Application -StartupNotify=true -Categories=GNOME;GTK;Accessibility; -AutostartCondition=GNOME /desktop/gnome/applications/at/screen_keyboard_enabled -</screen> - - <para> - The following is an example <filename>mousetweaks.desktop</filename> - file: - </para> - -<screen> -[Desktop Entry] -Encoding=UTF-8 -Name=Software Mouse-Clicks -Comment=Perform clicks by dwelling with the pointer -TryExec=mousetweaks -Exec=mousetweaks --enable-dwell -m window -c -x 20 -y 240 -Terminal=false -Type=Application -StartupNotify=true -Categories=GNOME;GTK;Accessibility; -AutostartCondition=GNOME /desktop/gnome/applications/at/screen_keyboard_enabled -</screen> - - <para> - Note the line with the AutostartCondition that links both desktop - files to the GConf key for the on-screen keyboard. - </para> - - <para> - To disable GOK from starting, the desktop file for the GOK on-screen - keyboard must be removed or deactivated. Otherwise onboard and GOK - would simultaneously be started. This can be done by removing the - gok.desktop file from the GDM autostart directory, or by adding the - "Hidden=true" key setting to the gok.desktop file. - </para> - - <para> - After making these changes, GOK will no longer be started when the - user activates the on-screen keyboard in the GDM session; but onboard - and mousetweaks will instead be launched. - </para> - </sect3> - </sect2> - - <sect2 id="generalsessionconfig"> - <title>General Session Settings</title> -<!-- -<para> - TODO - I think this section should be expanded upon. What specific - keys are of interest, or would some users be likely to want - to configure? Also, would be good to be more specific about - how lock down management is handled. -</para> ---> - <para> - The GDM Greeter uses some of the same framework that your desktop - session will use. And so, it is influenced by a number of the same - GConf settings. For each of these settings the Greeter will use the - default value unless it is specifically overridden by a) GDM's - installed mandatory policy b) system mandatory policy. GDM installs - its own mandatory policy to lock down some settings for security. - </para> - </sect2> - - <sect2 id="gnomesettingsdaemon"> - <title>GNOME Settings Daemon</title> -<!-- -<para> - TODO - I think this section should be expanded upon. What specific - keys are of interest, or would some users be likely to want - to configure? Also, would be good to give a more complete - list of plugins that users might want to consider disabling. - Also, shouldn't we list the sound/active key in the Greeter - configuration setting? Oddly I do not find this key used - in anything but the chooser in SVN. -</para> ---> - - <para> - GDM enables the following gnome-settings-daemon plugins: - a11y-keyboard, background, sound, xsettings. - </para> - - <para> - These are responsible for things like the background image, font and - theme settings, sound events, etc. - </para> - - <para> - Plugins can also be disabled using GConf. For example, if you want to - disable the sound plugin then unset the following key: - <filename>/apps/gdm/simple-greeter/settings-manager-plugins/sound/active</filename>. - </para> - </sect2> - - <sect2 id="sessionconfig"> - <title>GDM Session Configuration</title> - - <para> - GDM sessions are specified using the FreeDesktop.org Desktop Entry - Specification, which can be referenced at the following URL: - <ulink url="http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec"> - http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec</ulink>. - </para> - - <para> - By default, GDM will install desktop files in the - <filename><share>/xsessions</filename> directory. GDM will - search the following directories in this order to find desktop files: - <filename><etc>/X11/sessions/</filename>, - <filename><dmconfdir>/Sessions</filename>, - <filename><share>/xsessions</filename>, and - <filename><share>/gdm/BuiltInSessions</filename>. By default the - <filename><dmconfdir></filename> is set to - <filename><etc>/dm/</filename> unless GDM is configured to use - a different directory via the "--with-dmconfdir" option. - </para> - - <para> - A session can be disabled by editing the desktop file and adding a line - as follows: <filename>Hidden=true</filename>. - </para> - - <para> - GDM desktop files support a GDM-specific extension, a key named - "X-GDM-BypassXsession". If the key is not specified in a - desktop file, the value defaults to "false". If this key is - specified to be "true" in a desktop file, then GDM will - launch the program specified by the desktop file "Exec" key - directly when starting the user session. It will not run the program - via the <filename><etc>/gdm/Xsession</filename> script, which is - the normal behavior. Since bypassing the - <filename><etc>/gdm/Xsession</filename> script avoids setting up - the user session with the normal system and user settings, sessions - started this way can be useful for debugging problems in the system or - user scripts that might be preventing a user from being able to start - a session. - </para> - - </sect2> - - <sect2 id="userconfig"> - <title>GDM User Session and Language Configuration</title> - <para> - The user's default session and language choices are stored in the - <filename>~/.dmrc</filename> file. When a user logs in for the first - time, this file is created with the user's initial choices. The user - can change these default values by simply changing to a different value - when logging in. GDM will remember this change for subsequent logins. - </para> - - <para> - The <filename>~/.dmrc</filename> file is in the standard - <filename>INI</filename> format. It has one section called - <filename>[Desktop]</filename> which has two keys: - <filename>Session</filename> and <filename>Language</filename>. - </para> - - <para> - The <filename>Session</filename> key specifies the basename of the - session <filename>.desktop</filename> file that the user wishes to - normally use without the <filename>.desktop</filename> extension. - The <filename>Language</filename> key specifies the language that the - user wishes to use by default. If either of these keys is missing, the - system default is used. The file would normally look as follows: - </para> - -<screen> -[Desktop] -Session=gnome -Language=cs_CZ.UTF-8 -</screen> - </sect2> - - </sect1> - - <!-- ============= GDM Commands ============================= --> - - <sect1 id="binaries"> - <title>GDM Commands</title> - - <sect2 id="sbindir_binaries"> - <title>GDM Root User Commands</title> - - <para> - The GDM package provides the following commands in - <filename>sbindir</filename> intended to be run by the root user: - </para> - - <sect3 id="gdmcommandline"> - <title><command>gdm</command> and <command>gdm-binary</command> - Command Line Options</title> - - <para> - The <command>gdm</command> command is really just a script which - runs the <command>gdm-binary</command>, passing along any options. - Before launching <command>gdm-binary</command>, the gdm wrapper - script will source the <filename><etc>/profile</filename> file - to set the standard system environment variables. In order to better - support internationalization, it will also set the LC_MESSAGES - environment variable to LANG if neither LC_MESSAGES or LC_ALL are - set. The <command>gdm-binary</command> is the actual GDM daemon. - </para> - - <variablelist> - <title><command>gdm</command> and <command>gdm-binary</command> - Command Line Options</title> - - <varlistentry> - <term>-?, --help</term> - <listitem> - <para> - Gives a brief overview of the command line options. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>--fatal-warnings</term> - <listitem> - <para> - Make all warnings cause GDM to exit. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>--timed-exit</term> - <listitem> - <para> - Exit after 30 seconds. Useful for debugging. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>--version</term> - <listitem> - <para> - Print the version of the GDM daemon. - </para> - </listitem> - </varlistentry> - </variablelist> - </sect3> - - <sect3 id="gdmrestartcommandline"> - <title><command>gdm-restart</command> Command Line Options</title> - - <para> - <command>gdm-restart</command> stops and restarts GDM by sending - the GDM daemon a HUP signal. This command will immediately terminate - all sessions and log out users currently logged in with GDM. - </para> - </sect3> - - <sect3 id="gdmsaferestartcommandline"> - <title><command>gdm-safe-restart</command> Command Line Options</title> - - <para> - <command>gdm-safe-restart</command> stops and restarts GDM by - sending the GDM daemon a USR1 signal. GDM will be restarted as soon - as all users log out. - </para> - </sect3> - - <sect3 id="gdmstopcommandline"> - <title><command>gdm-stop</command> Command Line Options</title> - - <para> - <command>gdm-stop</command> stops GDM by sending the GDM daemon - a TERM signal. - </para> - </sect3> - </sect2> - </sect1> - - <!-- ============= Troubleshooting =========================== --> - - <sect1 id="troubleshooting"> - <title>Troubleshooting</title> -<!-- -<para> - TODO - any other tips we should add? Might be useful to highlight any - common D-Bus configuration issues? -</para> ---> - - <para> - This section discusses helpful tips for getting GDM working. In general, - if you have a problem using GDM, you can submit a bug or send an email - to the gdm-list mailing list. Information about how to do this is in - the Introduction section of the document. - </para> - - <para> - If GDM is failing to work properly, it is always a good idea to include - debug information. To enable debugging, set the debug/Enable key to - "true" in the <filename><etc>/gdm/custom.conf</filename> - file and restart GDM. Then use GDM to the point where it fails, and - debug output will be sent to the system log file - (<filename><var>/log/messages</filename> or - <filename><var>/adm/messages</filename> depending on your Operating - System). If you share this output with the GDM community via a bug - report or email, please only include the GDM related debug information - and not the entire file since it can be large. If you do not see any - GDM syslog output, you may need to configure syslog (refer to the - <ulink type="help" url="man:syslog">syslog</ulink> man page). - </para> - - <sect2 id="wontstart"> - <title>GDM Will Not Start</title> - - <para> - There are a many problems that can cause GDM to fail to start, but - this section will discuss a few common problems and how to approach - tracking down a problem with GDM starting. Some problems will - cause GDM to respond with an error message or dialog when it tries - to start, but it can be difficult to track down problems when GDM - fails silently. - </para> - - <para> - First make sure that the Xserver is configured properly. The - GDM configuration file contains a command in the [server-Standard] - section that is used for starting the Xserver. Verify that this - command works on your system. Running this command from the - console should start the Xserver. If it fails, then the problem - is likely with your Xserver configuration. Refer to your Xserver - error log for an idea of what the problem may be. The problem may - also be that your Xserver requires different command-line options. - If so, then modify the Xserver command in the GDM configuration file - so that it is correct for your system. - </para> - - <para> - Also make sure that the <filename>/tmp</filename> directory has - reasonable ownership and permissions, and that the machine's file - system is not full. These problems will cause GDM to fail to start. - </para> - </sect2> - </sect1> - - <!-- ============= Application License ============================= --> - - <sect1 id="license"> - <title>License</title> - <para> - This program is free software; you can redistribute it and/or - modify it under the terms of the <ulink type="help" url="gnome-help:gpl"> - <citetitle>GNU General Public License</citetitle></ulink> as - published by the Free Software Foundation; - either version 2 of the License, or (at your option) any later - version. - </para> - <para> - This program is distributed in the hope that it will be useful, but - WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - <citetitle>GNU General Public License</citetitle> for more details. - </para> - <para> - A copy of the <citetitle>GNU General Public License</citetitle> is - included as an appendix to the <citetitle>GNOME Users - Guide</citetitle>. You may also obtain a copy of the - <citetitle>GNU General Public License</citetitle> from the Free - Software Foundation by visiting - <ulink type="http" url="http://www.fsf.org">their Web site</ulink> or by - writing to - <address> - Free Software Foundation, Inc. - <street>51 Franklin Street, Fifth Floor</street> - <city>Boston</city>, <state>MA</state> <postcode>02110-1301</postcode> - <country>USA</country> - </address> - </para> - </sect1> -</article> - -<!-- Keep this comment at the end of the file -Local variables: -mode: sgml -sgml-omittag:t -sgml-shorttag:t -sgml-minimize-attributes:nil -sgml-always-quote-attributes:t -sgml-indent-step:2 -sgml-indent-data:t -sgml-parent-document:nil -sgml-exposed-tags:nil -sgml-local-catalogs:nil -sgml-local-ecat-files:nil -End: ---> diff --git a/docs/Makefile.am b/docs/Makefile.am index 94b682c5..9b2ef6ae 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -1,11 +1,9 @@ -include $(top_srcdir)/gnome-doc-utils.make -dist-hook: doc-dist-hook +@YELP_HELP_RULES@ -DOC_MODULE = gdm -DOC_ENTITIES = legal.xml -DOC_INCLUDES = -DOC_LINGUAS = ca de el en_GB es fr gl id it ko oc ru sl sv te uk zh_CN -# ja zh_HK zh_TW need to be transitioned to gnome-doc-utils +HELP_ID = gdm -#man_MANS = gdm.1 -#EXTRA_DIST = gdm.1 +HELP_FILES = \ + index.docbook \ + legal.xml + +HELP_LINGUAS = ca de el en_GB es fr gl id it ko oc ru sl sv te uk zh_CN diff --git a/docs/gdm.omf.in b/docs/gdm.omf.in deleted file mode 100644 index 106f669b..00000000 --- a/docs/gdm.omf.in +++ /dev/null @@ -1,11 +0,0 @@ -<?xml version="1.0" standalone="no"?> -<omf> - <resource> - <subject category="GNOME|Applications|System Tools"/> - <type> - user's guide - </type> - <relation seriesid="04d4eadb-48ec-0cc0-6cfb-b23c6efee183f0"/> - <rights type="GNU FDL" license.version="1.1" holder="Sun Microsystems, Inc."/> - </resource> -</omf> diff --git a/omf.make b/omf.make deleted file mode 100644 index 734f6d97..00000000 --- a/omf.make +++ /dev/null @@ -1,61 +0,0 @@ -# -# No modifications of this Makefile should be necessary. -# -# This file contains the build instructions for installing OMF files. It is -# generally called from the makefiles for particular formats of documentation. -# -# Note that you must configure your package with --localstatedir=/var -# so that the scrollkeeper-update command below will update the database -# in the standard scrollkeeper directory. -# -# If it is impossible to configure with --localstatedir=/var, then -# modify the definition of scrollkeeper_localstate_dir so that -# it points to the correct location. Note that you must still use -# $(localstatedir) in this or when people build RPMs it will update -# the real database on their system instead of the one under RPM_BUILD_ROOT. -# -# Note: This make file is not incorporated into xmldocs.make because, in -# general, there will be other documents install besides XML documents -# and the makefiles for these formats should also include this file. -# -# About this file: -# This file was derived from scrollkeeper_example2, a package -# illustrating how to install documentation and OMF files for use with -# ScrollKeeper 0.3.x and 0.4.x. For more information, see: -# http://scrollkeeper.sourceforge.net/ -# Version: 0.1.3 (last updated: March 20, 2002) -# - -omf_dest_dir=$(datadir)/omf/@PACKAGE@ -scrollkeeper_localstate_dir = $(localstatedir)/scrollkeeper - -# At some point, it may be wise to change to something like this: -# scrollkeeper_localstate_dir = @SCROLLKEEPER_STATEDIR@ - -omf: omf_timestamp - -omf_timestamp: $(omffile) - -for file in $(omffile); do \ - scrollkeeper-preinstall $(docdir)/$(docname).xml $(srcdir)/$$file $$file.out; \ - done; \ - touch omf_timestamp - -install-data-hook-omf: - $(mkinstalldirs) $(DESTDIR)$(omf_dest_dir) - for file in $(omffile); do \ - $(INSTALL_DATA) $$file.out $(DESTDIR)$(omf_dest_dir)/$$file; \ - done - -scrollkeeper-update -p $(scrollkeeper_localstate_dir) -o $(DESTDIR)$(omf_dest_dir) - -uninstall-local-omf: - -for file in $(srcdir)/*.omf; do \ - basefile=`basename $$file`; \ - rm -f $(DESTDIR)$(omf_dest_dir)/$$basefile; \ - done - -rmdir $(DESTDIR)$(omf_dest_dir) - -scrollkeeper-update -p $(scrollkeeper_localstate_dir) - -clean-local-omf: - -for file in $(omffile); do \ - rm -f $$file.out; \ - done diff --git a/xmldocs.make b/xmldocs.make deleted file mode 100644 index 84d0f2bc..00000000 --- a/xmldocs.make +++ /dev/null @@ -1,95 +0,0 @@ -# -# No modifications of this Makefile should be necessary. -# -# To use this template: -# 1) Define: figdir, docname, lang, omffile, and entities in -# your Makefile.am file for each document directory, -# although figdir, omffile, and entities may be empty -# 2) Make sure the Makefile in (1) also includes -# "include $(top_srcdir)/xmldocs.make" and -# "dist-hook: app-dist-hook". -# 3) Optionally define 'entities' to hold xml entities which -# you would also like installed -# 4) Figures must go under $(figdir)/ and be in PNG format -# 5) You should only have one document per directory -# 6) Note that the figure directory, $(figdir)/, should not have its -# own Makefile since this Makefile installs those figures. -# -# example Makefile.am: -# figdir = figures -# docname = scrollkeeper-manual -# lang = C -# omffile=scrollkeeper-manual-C.omf -# entities = fdl.xml -# include $(top_srcdir)/xmldocs.make -# dist-hook: app-dist-hook -# -# About this file: -# This file was taken from scrollkeeper_example2, a package illustrating -# how to install documentation and OMF files for use with ScrollKeeper -# 0.3.x and 0.4.x. For more information, see: -# http://scrollkeeper.sourceforge.net/ -# Version: 0.1.2 (last updated: March 20, 2002) -# - - -# ********** Begin of section some packagers may need to modify ********** -# This variable (docdir) specifies where the documents should be installed. -# This default value should work for most packages. -docdir = $(datadir)/gnome/help/$(docname)/$(lang) - -# ********** You should not have to edit below this line ********** -xml_files = $(entities) $(docname).xml - -EXTRA_DIST = $(xml_files) $(omffile) -CLEANFILES = omf_timestamp - -include $(top_srcdir)/omf.make - -all: omf - -$(docname).xml: $(entities) - -ourdir=`pwd`; \ - cd $(srcdir); \ - cp $(entities) $$ourdir - -app-dist-hook: - if test "$(figdir)"; then \ - $(mkinstalldirs) $(distdir)/$(figdir); \ - for file in $(srcdir)/$(figdir)/*.png; do \ - basefile=`echo $$file | sed -e 's,^.*/,,'`; \ - $(INSTALL_DATA) $$file $(distdir)/$(figdir)/$$basefile; \ - done \ - fi - -install-data-local: omf - $(mkinstalldirs) $(DESTDIR)$(docdir) - for file in $(xml_files); do \ - cp $(srcdir)/$$file $(DESTDIR)$(docdir); \ - done - if test "$(figdir)"; then \ - $(mkinstalldirs) $(DESTDIR)$(docdir)/$(figdir); \ - for file in $(srcdir)/$(figdir)/*.png; do \ - basefile=`echo $$file | sed -e 's,^.*/,,'`; \ - $(INSTALL_DATA) $$file $(DESTDIR)$(docdir)/$(figdir)/$$basefile; \ - done \ - fi - -install-data-hook: install-data-hook-omf - -uninstall-local: uninstall-local-doc uninstall-local-omf - -uninstall-local-doc: - -if test "$(figdir)"; then \ - for file in $(srcdir)/$(figdir)/*.png; do \ - basefile=`echo $$file | sed -e 's,^.*/,,'`; \ - rm -f $(DESTDIR)$(docdir)/$(figdir)/$$basefile; \ - done; \ - rmdir $(DESTDIR)$(docdir)/$(figdir); \ - fi - -for file in $(xml_files); do \ - rm -f $(DESTDIR)$(docdir)/$$file; \ - done - -rmdir $(DESTDIR)$(docdir) - -clean-local: clean-local-omf |