Configuring the X Windows System

Table of Contents


Security Issues: xf86(4)

Unix/BSDs provide a great sturdy platform for running services that just need to be "going and going and ..." For this type of environment the Windowing Graphical User Interface is mostly unnecessary (or maybe totally unnecessary.) But a Win GUI augments the tough exterior of the sturdy server with a more approachable look for those new to Unix/BSDs who are used to a desktop environment (aka MS Windows.) OpenBSD is as adept as other *NIX systems in displaying a nice gui and a flexible GUI provides a platform for non-*NIX people to be introduced to, operate and maintain the general configurations of a a secure OpenBSD box.

Installing needed X-Files

files: included as part of base files (2.x/ARCH)

If you did not include the X Windows during the system installation, you can manually extract the files. The distribution files are xbase[26|27].tgz, xserv[26|27].tgz, and xshare[26|27].tgz. From the root directory / untar the files and then configure ld to look for the X libraries that you have newly installed.

# cd /
# tar -zxf /[path-to-x]/xbase##.tgz
# tar -zxf /[path-to-x]/xfont##.tgz
# tar -zxf /[path-to-x]/xlink ##.tgz
# tar -zxf /[path-to-x]/xserv##.tgz
# tar -zxf /[path-to-x]/xshare##.tgz
# ldconfig -m /usr/X11R6/lib

You may also wish to include the new X, bin directory into your path /usr/X11R6/bin.

Allowing X to run (kernel config)

[ref: xf86(4)]
File: /etc/sysctl.conf

To allow the X11 server to start, the following option needs to be allowed. This option will have been set for you if you answered yes during installation that you intend to install X.

File: /etc/sysctl.conf


To read:


If you need to make the changes above, you will need to restart the computer for the kernel configuration to take effect.

Determining your System Configuration

Utility: SuperProbe
[Ref: /dev/MAKEDEV]
[Ref: /usr/X11R6/lib/X11/doc/README.* (various files on configuration the mouse,and videochips)]

To configure, initialise X for your system you will need to know a few details about the hardware on which you are installing X. The basic information is regarding the display devices (video card, monitor) and the mouse (pointing device.)

Video Card:

/usr/X11R6/bin/SuperProbe will interrogate your video card to give you details required during configuration. The output from the program will include the following items you should write down.

First video: **
Chipset: **
Memory:  **

Example 1: Micron Millenia Pro2 with a Diamond Stealth 3D 2000 the output is:

# /usr/X11R6/bin/SuperProbe

[ SuperProbe displays the following ...]


[ ... stuff cut out ... ]

First video: Super-VGA
Chipset: S3 ViRGE (PCI Probed)
Memory:  4096 Kbytes
RAMDAC:  Generic 8-bit pseudo-color DAC
         (with 6-bit wide lookup tables (or in 6-bit mode))

Additional documentation on configuring this card (chipset) can be found in /usr/X11R6/lib/X11/doc/README.S3V

Example 2: Compaq Prolinea 575e with built-in video (?)

# /usr/X11R6/bin/SuperProbe

[ SuperProbe displays the following ...]


[ ... stuff cut out ... ]

First video: Super-VGA
Chipset: Cirrus CL-GD5434 (PCI Probed)
Memory:  1024 Kbytes
RAMDAC:  Cirrus Logic Built-in 15/16/24-bit DAC
         (with 6-bit wide lookup tables (or in 6-bit mode))

Additional documentation on configuring this card (chipset) can be found in /usr/X11R6/lib/X11/doc/README.cirrus


The standard i386 configuration uses the following devices for your pointing device (mouse) [ref: /dev/MAKEDEV]. The device definitions below use an asterix (*) to designate where the unit number should be placed (eg. mms* would be replaced by mms0 or mms1 etc.)

/dev/mms* Microsoft bus mouse
/dev/lms* Logitech bus mouse
/dev/pms* PS/2 Mouse
/dev/tty* Serial Port where serial mice could be placed.
/dev/mouse (A link you create to whichever device above actually holds your mouse.)

Example 1, Micron Millenia Pro2 using a serial mouse plugged into the DOS labelled Serial Port A, this means that the Serial Mouse is connected to /dev/tty00 so I use the following command to link /dev/mouse to /dev/tty00. Note: A ps/2 mouse port exists but I only had a serial mouse, which was plugged into the serial port.

# ln -fs /dev/tty00 /dev/mouse

Example 2: Compaq Prolinea 575e where I use a PS/2 mouse on the motherboard ps/2 mouse slot, this means that the mouse is connected to /dev/pms0 so I use the following command to link /dev/mouse to /dev/pms0

# ln -fs /dev/pms0 /dev/mouse

Now, when configuring X I can just say that the mouse is /dev/mouse, regardless of what options it gives.

Is there any advantage to creating the /dev/mouse link ? In my limited experience using the /dev/mouse link lets me use the mouse with the XF86Setup program. Without the /dev/mouse link the auto-detect routines in XF86Setup often do not find the mouse and using the keyboard to navigate XF86Setup is not an easy task.

Configuring the base X environment

[Ref: /usr/X11R6/lib/X11/doc/QuickStart.doc]
Utility: XF86Setup, xf86config

When X Windows starts it is going to look for its configuration file at: /etc/XF86Config. We create the file through using one of two programs XF86Setup or xf86config.  Either program will be asking questions that include a request for the information collected above (Video, Mouse).

XF86Setup uses a windowing environment for configuring X.

xf86config is a very terse installation process, but is readily accessible from the keyboard with no need for the mouse.

Both programs cover a step-by-step process of asking you to verify/specify the devices you have on your computer that X will use. More details on this process is covered in the QuickStart.doc (see above for location of the file.)

If the graphical XF86Setup doesn't work well for you, then use the xf86config and open up QuickStart.doc in one screen while you work in another screen. You can then use the QuickStart as an active step-by-step guide to creating the XF86Config file.

Both setup programs should create a workable server, and you can test it by using the startx script.

# /usr/X11R6/bin/startx

Quick Troubleshoot - mouse not working

[ref: /usr/X11R6/lib/X11/doc/README.mouse]

[ref: /dev/MAKEDEV]

If starting X there is no mouse, you may find it easier to edit the /etc/XF86Config file directly instead of re-running the configuration programs. The /etc/XF86Config file is separated into different sections relating to providing information for X on the hardware and file locations.

Section "Pointer" specifies the details of what X is to search for to find about your mouse (pointing device) and it's hardware location. The important parameters here are:-

Protocol "Microsoft"
Device "/dev/mouse"

If you are not using a Microsoft Mouse compatible mouse, then you can make the change here if you know what 'protocol' your mouse is using [ref: README.mouse]. The Device section is where I've had previous problems with the mouse and changing it here to:  Device "/dev/pms0" or which ever port the device is connected is faster than having to re-run xf86config (where a mistake in the menus can cause other problems.)

Booting OpenBSD straight into X

To automatically start the machine with the X environment, configuration changes are made in the rc.conf file

Enable the X manager to begin on startup

File: /etc/rc.conf

Change the line that reads as:


To read:

xdm_flags=""  # note the use of two double-quotes

Restart the machine and xdm will prompt you for password authentication in a graphical environment.

KDE X window manager and OpenBSD 2.7 location for latest release website to find mirrors to the folder.

Unfortunately I couldn't get the packaged version of kde-1.1.2 to work, so I went with the tar release from the KDE ftp sites.

Doing the non-package version.

[Ref: i386_openbsd27-README, i386_openbsd25-README]

Get the tar release of kde-1.1.2 for OpenBSD from the KDE site (or mirrors) and store it somewhere on your system (eg: /home/user/tmp)









The kde binaries were compiled with /opt/kde as their expected base directory. Extract the files into their expected location (/opt/kde) by moving to the /opt directory, or mkdir /opt and then cd into it.

# mkdir /opt
# cd /opt

# tar zxf /[path-to-files]/i386_OpenBSD27-kdeadmin-1.1.2.tgz

#  ...

#  ...

# tar -zxf /[path-to-files/i386_OpenBSD27-kdeutils-1.1.2.tgz

# tar -zxf /[path-to-files/i386_OpenBSD27-qt144.tgz

Side Note: If the files are downloaded onto another machine within your LAN (or your Internet link is fast) then you can try using the ftp redirection commands:

ftp> bi

ftp> get i386_OpenBSD27-kdeadmin-1.1.2.tgz "| tar -zxf -"

ftp>  ...

ftp>  ...

ftp> get i386_OpenBSD27-kdeutils-1.1.2.tgz "| tar -zxf -"

ftp> get i386_OpenBSD27-qt144.tgz "| tar -zxf -"

Configure ld so it looks in the kde/lib directory for dynamically loadable libraries

# /usr/sbin/ldconfig -m /opt/kde/lib

To configure KDE as your windows manager, we will grab a copy of the startkde file into ~/.xinitrc where startx will initially check which windowing system to use.

# cp /opt/kde/bin/startkde ~/.xinitrc

The ~/.xinitrc file should now contain something similar to the below.


#    comments taken out

kcontrol -init
sleep 1 ; kaudioserver
(sleep 1 && exec kwmsound) & 
(sleep 1 && exec kfm) &
(sleep 1 && exec krootwm) &
(sleep 1 && exec kpanel) &
(sleep 3 && exec kbgndwm) &
# finally, give the session control to the window manager
sleep 2 ; exec kwm

KDE is ready to run. Start X (startx) and the KDE windowing environment should greet you.

Setting KDE as default desktop (system wide)

When xdm starts a user session, it follows its own rules on how to setup that client. The information/configurations are set in the file /usr/X11R6/lib/X11/xdm/Xsession

File: /usr/X11R6/lib/X11/xdm/Xsession

To have xdm launch KDE as the default user environment, then make the following modifications to the file: Change the section in the Xsession file that reads:

if [ -f "$startup" ]; then
        exec "$startup"
        if [ -f "$resources" ]; then
                xrdb -load "$resources"
        xterm &
        exec fvwm

To read as follows

if [ -f "$startup" ]; then
        exec "$startup"
        if [ -f "$resources" ]; then
                xrdb -load "$resources"
        #xterm &
        #exec fvwm
        export PATH=$PATH:/opt/kde/bin:/usr/X11R6/bin
        kcontrol -init
        sleep 1 ; kaudioserver
         (sleep 1 && exec kwmsound) &
         (sleep 1 && exec kfm) &
         (sleep 1 && exec krootwm) &
         (sleep 1 && exec kpanel) &
         (sleep 3 && exec kbgndwm) &
        sleep 2 ; exec kwm

The above is a really ugly hack because I can't figure out how to get KDE's kdm to run as the default xdm. (I do want kdm don't I?)

Further notes: I should have been able to just replace Xsession with startkde (?)

vnc Remote Administration - in X11

package: vnc-3.3.2r3.tar.gz (available as package)
Windows Binaries: vnc-3.3.3r2_x86_win32.tgz
[ref: /usr/local/share/docs/vnc/*.html]

VNC is a neat set of programs to allow remote access to the GUI environment from either a separate X box, or a Windows box. If you're like me and have too many monitors giving off heat, it is nice to work from one keyboard and minimise the number of powered-on monitors. Of course, it is also helpful if the system is in another location and you need a GUI environment to do some work.

Install the package

# pkg_add /[path-to-package/vnc-3.3.2r3.tgz

The installation will create a ~/.vnc folder which will hold the pid files indicating which pid different VNC servers may be running on the machine serving up X enquiries. The directory will contain *.pid, *.log files for running vncs. The xstartup file is the x initialisation file.  The simplest solution is to copy the existing ~/.xinitrc as the new xstartup file.

# cp ~/.vnc/xstartup ~/.vnc/xstartup-
# cp ~/.xinitrc ~/.vnc/xstartup

Start the X vnc server (vncserver) at the command line and you will be prompted to enter a server password. There is a critical security issue with maintaining this password since it automatically logs the user in as the client running the server.  Which will be required when using a client to access the machine. 

After the server has started it will notify at the terminal which 'display' the X will be serving on. For example, localhost:0 is the physically connected screen and server:1 is the 1st available outside X client.


You will require a password to access your desktops.

Password:<-- password is not echoed
Verify:  <-- not echoed

New 'X' desktop is iwill:2

Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/iwill:2.log

I now have vncserver running at desktop [ iwill:2 ] and session information logging to iwill:2.log. The desktop is at "iwill" since that is my machine hostname, and it is giving me the vncserver on display 2.

The password is stored as an encrypted file in ~/.vnc/passwd so don't let anyone else get at it. The password will be used for all vncserver sessions (including new vncserver configurations) until I delete the file.

From my Windows 2000 machine I can now use vncViewer to connect to my OpenBSD box. After installing the vnc programs on the Win2000 box I start "Run vnc Viewer" and answer the dialog boxes:

VNC server -        [ iwill:2           ]
Session Password -  [                   ]

Now I'm browsing the OpenBSD box using KDE on Windows 2000.

For further information on stopping vncserver (vncserver -kill :2) and other options, browse the documentation (no man or info pages) supplied as html in the /usr/local/share/doc directory.

Author and Copyright

Copyright (c) 2000 Samiuela LV Taufa. All Rights Reserved.

You are permitted and encouraged to use this guide for fun or for profit as you see fit. If you republish this work in what-ever form, it would be nice (though not enforceable) to be credited.

 X a pretty face on OpenBSD

Copyright  © 2000 Tonga on the 'NET All rights reserved.