XSERVER | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
NAME | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
SYNOPSIS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
DESCRIPTION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
STARTING THE SERVER | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Installations that run more than one window system may need to use the xinit(1) utility instead of a display manager. However, xinit is to be considered a tool for building startup scripts and is not intended for use by end users. Site administrators are strongly urged to use a display manager, or build other interfaces for novice users.
The X server may also be started directly by the user, though this method is usually reserved for testing and is not recommended for normal operation. On some platforms, the user must have special permission to start the X server, often because access to certain devices (e.g. /dev/mouse) is restricted.
When the X server starts up, it typically takes over the display. If you are running on a workstation whose console is the display, you may not be able to log into the console while the server is running.
OPTIONS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
All of the X servers accept the command line options described below. Some X servers may have alternative ways of providing the parameters described here, but the values provided via the command line options should override values specified via other mechanisms.
SERVER DEPENDENT OPTIONS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
XDMCP OPTIONS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
XKEYBOARD OPTIONS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
NETWORK CONNECTIONS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
GRANTING ACCESS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Authorization data required by the above protocols is passed to the server in a private file named with the -auth command line option. Each time the server is about to accept the first connection after a reset (or when the server is starting), it reads this file. If this file contains any authorization records, the local host is not automatically allowed access to the server, and only clients which send one of the authorization records contained in the file in the connection setup information will be allowed access. See the Xau manual page for a description of the binary format of this file. See xauth(1) for maintenance of this file, and distribution of its contents to remote hosts.
The X server also uses a host-based access control list for deciding whether or not to accept connections from clients on a particular machine. If no other authorization mechanism is being used, this list initially consists of the host on which the server is running as well as any machines listed in the file /etc/Xn.hosts, where n is the display number of the server. Each line of the file should contain either an Internet hostname (e.g. expo.lcs.mit.edu) or a DECnet hostname in double colon format (e.g. hydra::) or a complete name in the format family:name as described in the xhost(1) manual page. There should be no leading or trailing spaces on any lines. For example:
joesworkstation corporate.company.com star:: inet:bigcpu local:
Users can add or remove hosts from this list and enable or disable access control using the xhost command from the same machine as the server.
If the X FireWall Proxy (xfwp) is being used without a sitepolicy, host-based authorization must be turned on for clients to be able to connect to the X server via the xfwp. If xfwp is run without a configuration file and thus no sitepolicy is defined, if xfwp is using an X server where xhost + has been run to turn off host-based authorization checks, when a client tries to connect to this X server via xfwp, the X server will deny the connection. See xfwp(1) for more information about this proxy.
The X protocol intrinsically does not have any notion of window operation permissions or place any restrictions on what a client can do; if a program can connect to a display, it has full run of the screen. X servers that support the SECURITY extension fare better because clients can be designated untrusted via the authorization they use to connect; see the xauth(1) manual page for details. Restrictions are imposed on untrusted clients that curtail the mischief they can do. See the SECURITY extension specification for a complete list of these restrictions.
Sites that have better authentication and authorization systems might wish to make use of the hooks in the libraries and the server to provide additional security models.
SIGNALS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
FONTS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
The default font path is catalogue:/etc/X11/fontpath.d, built-ins .
A special kind of directory can be specified using the catalogue: prefix. Directories specified this way can contain symlinks pointing to the real font directories. See the FONTPATH.D section for details.
The font path can be set with the -fp option or by xset(1) after the server has started.
FONTPATH.D | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
The symlink can be suffixed by attributes such as 'unscaled', which will be passed through to the underlying fontfile FPE. The only exception is the newly introduced 'pri' attribute, which will be used for ordering the font paths specified by the symlinks.
An example configuration:
75dpi:unscaled:pri=20 -> /usr/share/X11/fonts/75dpi ghostscript:pri=60 -> /usr/share/fonts/default/ghostscript misc:unscaled:pri=10 -> /usr/share/X11/fonts/misc type1:pri=40 -> /usr/share/X11/fonts/Type1 type1:pri=50 -> /usr/share/fonts/default/Type1
This will add /usr/share/X11/fonts/misc as the first FPE with the attribute the attribute unscaled etc. This is functionally equivalent to setting the following font path:
/usr/share/X11/fonts/misc:unscaled, /usr/share/X11/fonts/75dpi:unscaled, /usr/share/X11/fonts/Type1, /usr/share/fonts/default/Type1, /usr/share/fonts/default/ghostscript
FILES | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
SEE ALSO | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Protocols: X Window System Protocol, The X Font Service Protocol, X Display Manager Control Protocol
Fonts: bdftopcf(1), mkfontdir(1), mkfontscale(1), xfs(1), xlsfonts(1), xfontsel(1), xfd(1), X Logical Font Description Conventions
Security: Xsecurity(7), xauth(1), Xau(1), xdm(1), xhost(1), xfwp(1), Security Extension Specification
Starting the server: xdm(1), xinit(1)
Controlling the server once started: xset(1), xsetroot(1), xhost(1)
Server-specific man pages: Xorg(1), Xdmx(1), Xnest(1), Xvfb(1), XDarwin(1), XWin(1).
Server internal documentation: Definition of the Porting Layer for the X v11 Sample Server
AUTHORS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Sommaire | Début | Suivant | Sommaire | Préc.page.lue | Accueil |
Table des mots clés | Début | Suivant | Sommaire | Préc.page.lue | Accueil |