Multiheading Linux Systems
We used Red Hat 7.2 as the baseline because it has XFree86 4, which supports multiple displays (and input devices). Commercial X servers have supported this for a while, but XFree86 4 comes with new Linux distributions and it's free. Version 4 threw in a new configuration file and format to allow this flexibility. The key section is ServerLayout, which positions one screen relative to another. Here's an excerpt:
Section "ServerLayout" Identifier "XFree86 Configured" Screen 0 "Screen0" 0 0 Screen 1 "Screen1" LeftOf "Screen0" InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection
As you undoubtedly realize from this straightforward format, this setup will configure Screen0 (the screen associated with your primary video card) and then configure Screen1 and place it to the left of Screen0. In other words, you would move your mouse across Screen0, hit the left edge and then enter Screen1 from the right side (pretty confusing if you have the monitors backward). You can choose Right, Top, Bottom or even Relative positioning so the screens are diagonal. Do a man XFree86 to get the details. The screens don't have to be the same resolution or even the same color depth. Make one or both virtual if you want, though we didn't find this easy to use. Each screen in ServerLayout is composed of a Monitor reference and Device (video card) reference as shown below:
Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Depth 8 #Virtual 1024 768 EndSubSection EndSectionHere's the monitor and device sections to support Screen0:
Section "Monitor" Identifier "Monitor0" VendorName "GWY" ModelName "311" EndSection Section "Device" Identifier "Card0" Driver "mga" VendorName "Matrox" BoardName "MGA 2164W" BusID "PCI:0:14:0" EndSectionThe first key thing is to make sure everything is consistent, i.e., Screen0 has Monitor0 and Card0. What's important is that the names match, not what they are. We have developed a habit of making one set end in 0 and the next set end in 1, instead of keeping track of the card and monitor names. It's just easier to avoid mistakes.
The next key thing is the device driver. That gets identified by the XFree86 -configure step for both cards. Finally, it's critical to get the BusIDs straight. It's optional with only one card but mandatory for two or more. An AGP card will start with a 1, not a 0, and probably will be 1:0:0.
Now you have the basics and need to fine-tune /etc/X11/XFConfig-4 to get optimal performance. Edit this file and interleave the data identified in /root/XFConfig-4.new. Because we're using KDE's graphical login, you can tweak the file, log out, restart the X server from the KDE login window, do the login and see what happens. If you're not happy, tweak and repeat. It's much faster than manually restarting X. See Listing 1 [available at ftp.linuxjournal.com/pub/lj/listings/issue99/5958.tgz] for a full XFConfig-4 file.
At this point, you have a working multiheaded system utilizing the KDE graphical login and probably the KDE environment (Figure 1). It turns out that there are four different configurations that can be set up: GNOME or KDE login, and then the GNOME or KDE environment. We'll go through the advantages and disadvantages of each approach now.
The file /etc/sysconfig/desktop determines which login manager is used. It's a one-line file saying DESKTOP="GNOME" or DESKTOP="KDE". Edit as root, according to your requirements. Here are the four configuration options:
KDE login manager/KDE work environment (your system is set up this way if you followed the formula). This approach gives you two screens that can be identified by :0.0 for the primary and :0.1 for the secondary. The screens are separate, so you can't move windows from one screen to the other. You have a KDE menubar for each screen. The best use for this is to devote a screen to monitoring (error log, network activity, server room temperature, etc.) whatever you need to keep an eye on that takes up a lot of screen real estate. This is the original motivation for making this work—use some old hardware to monitor network activity and do other work without having another computer on the desk. Since we're working with Linux and have the X Window System, it's easy to control where the X applications appear. You could type DISPLAY=:0.1 (bash/ksh/sh syntax), and then your application will appear in screen :0.1. If you wanted to have just one well-behaved X application in the other screen, type xclock -display :0.0, for example.
KDE login manager/GNOME work environment (type switchdesk from a command prompt and select GNOME to change from the original setup). This gives you a window manager controlling one screen and raw X on the other. You could type /usr/X11R6/bin/mwm -display :0.1 & in an xterm (ignore the warning) and get a different window manager running in the other screen. The commands twm and fvwm2 also will work. This is useful for testing purposes because you can quickly see if there are any problems with an application by running it in the environments. As in configuration one, the screens are separate.
Configurations three and four take a different approach and use the Xinerama extensions in XFree86 4. The authors are grateful to Dennis Baker for his splendid HOWTO. Xinerama makes one big screen, so it's probably the easiest and most natural way to work. You just move the windows from one screen to another. There are two key steps for these configurations. First, change the /etc/sysconfig/desktop file as above. Second, in the file /etc/X11/gdm/gdm.conf, edit the line 0=/usr/bin/X11/X toward the end of the file by making it read 0=/usr/bin/X11/X +xinerama.
GNOME login/GNOME work environment with one large connected screen. When you maximize a window it will fill its screen.
GNOME login/KDE work environment. (Select KDE from the login window if you just want to try KDE once.) Again, it's one large connected screen. This time when you maximize a window it fills the complete screen (spanning between screens).
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Server Hardening
- BitTorrent Inc.'s Sync
- EnterpriseDB's EDB Postgres Advanced Server and EDB Postgres Enterprise Manager
- The Death of RoboVM
- The US Government and Open-Source Software
- The Humble Hacker?
- Open-Source Project Secretly Funded by CIA
- New Container Image Standard Promises More Portable Apps
- AdaCore's SPARK Pro
- ACI Worldwide's UP Retail Payments
In modern computer systems, privacy and security are mandatory. However, connections from the outside over public networks automatically imply risks. One easily available solution to avoid eavesdroppers’ attempts is SSH. But, its wide adoption during the past 21 years has made it a target for attackers, so hardening your system properly is a must.
Additionally, in highly regulated markets, you must comply with specific operational requirements, proving that you conform to standards and even that you have included new mandatory authentication methods, such as two-factor authentication. In this ebook, I discuss SSH and how to configure and manage it to guarantee that your network is safe, your data is secure and that you comply with relevant regulations.Get the Guide