Linux-Based X Terminals with XDMCP
The display manager login screen and chooser interface are fully customizable. If you are running gdm, you may use the graphical setup utility gdmsetup or modify the text file /etc/X11/gdm/gdm.conf. If you are running kdm, modify /etc/X11/xdm/kdmrc. If you are running xdm, start with modifying /etc/X11/xdm/Xresources. If you don't find everything you want to customize in these files, look at the other files in /etc/X11/xdm/, for example, XSetup_0 or xdm-config. I expect most people choose to use gdm or kdm, so I won't go into details on xdm customization. Also, because gdm offers a graphical customization tool, I scratch only the surface of customizations, focusing on kdm customization under Red Hat only.
Regardless of which display manager you run, you may want to consider customizing a few things. For example, you may want your own background image and your own welcome message to appear on the login screen, and you definitely want to prevent users from shutting down the server through the login window. For kdm users, the background image is presented on the login screen by an auxiliary program called xsri. Under Red Hat, the script /etc/X11/xdm/XSetup_0 checks for the existence of the program and the associated file /etc/X11/xsrirc. If both exist, xsri is run and the graphic indicated in /etc/X11/xsrirc is displayed on the login screen. So, if you want to change the background image, simply change the graphic file listed in /etc/X11/xsrirc. To change the welcome message, find the GreetString option under the [X-*-Greeter] section of the file kdmrc. You may set this string equal to anything you like, but long messages may not display fully or may distort the appearance of the login window. Macros may be used in the GreetString too. For example, the default greeting is "Welcome to %s at %n" where %s is expanded into the operating system and %n is expanded into the node name (usually the hostname without domain name). Other macros are available and are listed above the GreetString line in kdmrc.
Finally, and most importantly, you need to keep regular users from shutting down the server. Allowing them to shut down is dangerous because they may shut it down while other users are working on the same machine. Again, inside the file kdmrc, find the AllowShutdown option under both the [X-*-Core] section and the [X-:*-Core] section and set them both to Root. This change requires the root password in order to shut down the machine from the login window. Additionally, when a user logs out of a session, the shutdown option does not appear in the ensuing dialog box. However, you may prefer to set these options to None, in which case the shutdown button will not appear at all in the login window.
Multiple servers may be set up in exactly the manner described in the section on configuring a server, and they can be accessed by X terminals in exactly the manner described in the section on configuring an X terminal. However, this requires the user to pick a server to login to and to know its name or IP address. A more effective method of managing multiple servers is to run a chooser and have users of X terminals submit indirect queries.
To begin, configure each server as described previously. Then, pick one machine to run a chooser. On this machine, modify the file /etc/X11/xdm/Xaccess in one of two ways. The easiest way is to uncomment the line * CHOOSER BROADCAST. When an indirect query is received, the chooser sends out a broadcast query and displays a list of machines that responded to the query. The X terminal user then may select to log in to one of these machines. This setup does not work in all environments, however, and you may not want to give users access to all servers on your network.
To be selective as to which servers are reported by the chooser, comment out the line * CHOOSER BROADCAST by putting a # at the beginning and uncomment the lines #%hostlist host-a host-b and #* CHOOSER %hostlist. Then, replace host-a host-b with a space-separated list of all hosts that you wish to appear in the chooser. This way, the chooser can send direct queries to each machine in the list and report the results to the chooser.
Finally, to see the chooser from an X terminal, run X with the option -indirect my.XDMCP.chooser, where my.XDMCP.chooser is the name of the machine configured to supply a chooser. Under UNIX, remember the command to run X is X and under Cygwin it is XWin.exe.
Advantages: the main advantages of running XDMCP are clear from the goal you wish to meet by running it. However, there are some disadvantages, one big one being the lack of security. Additionally, access to the X terminal's sound card, floppy drive, CD-ROM drive, scanner and any other local hardware besides the keyboard, mouse and monitor is difficult at best. I do not have a reasonable solution to offer on this issue. Perhaps someone can offer one in a future article.
Security: as stated earlier, XDMCP is an insecure protocol. However, if you require X terminal services over an insecure network, there is at least one option. Instead of setting up your server to run XDMCP, configure it as an SSH (secure shell) server. Then, from the X terminal, start an X session running nothing but an xterm, not even a window manager. From this xterm, issue the command ssh -X firstname.lastname@example.org, where ssh.server is the name or IP address of the ssh server and loginname is your login on the server. The -X enables X11 forwarding over the secure connection. After logging in, issue startkde to begin a KDE session or gnome-session to begin a GNOME session. Alternatively, you may run a full blown desktop environment on the X terminal, run an xterm there and issue the command ssh -X email@example.com command where command is the command/program you wish to run. This allows you to run a single program at a time on the remote machine rather than on a desktop environment.
Installing and running an SSH server and client should be straightforward. For example, Red Hat ships with an optional sshd (server) package and the client is installed by default. For Cygwin, an OpenSSH client is an optional package. For more information than you probably care to know about SSH, see www.openssh.org or read the man pages on SSH and sshd.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SourceClear Open
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide