While we are all busy scrounging around the Internet for the latest and greatest to make our lives easier, it's easy to forget that what we're looking for may be right here. Sounds a bit like your columnist is busy misquoting Dorothy at the end of The Wizard of Oz (the movie, not the book). Well, pay no attention to the man writing that last paragraph, and follow me for a tour of your Linux home.

Later this week, I will be visiting a client who is considering deploying Linux on the desktop. Personally, I think this is a great idea whose time has definitely come. While I won't know his real reasons for considering Linux (at least until after you have read this column), Windows 2000 is probably part of his reason. That, and Office 2000, and the hardware to support it all; need I go on? The real question we might ask ourselves, though, is this: "Why isn't Linux on every desktop already?" The great fear of too-complex administration is a likely answer.

KDE and GNOME have forever changed the world's view of Linux. When I boot up my old notebook to show people, they see KDE running as my desktop. Actually, what they see is a nice, friendly GUI that looks a little like what they are used to. When they ask me about the difficulty of running and administering their Linux system, I generally don't point them to the web tools I described in the last two columns (well, not immediately, especially if they are coming from a very Windows background). I point them to their desktops. Then, armed with The Power of X (sounds like a comic book hero), I show them how they (or I) can remotely administer all the desktops in their office from a single workstation.

Let's take a tour of what your desktop offers, then I'll talk about remote administration with KDE or GNOME. In this week's little journey, I'll show how you can run your X applications remotely. To illustrate that point, we'll look under the hood of your Linux initialization and see how all those daemons and services get started. If you are ready, it's desktop tool time.

You can access these tools from the respective "start" buttons. On your GNOME desktop, that's the big foot on the left. KDE has a large "K". Both GNOME and KDE offer a variety of great tools, but at this time, I am still more impressed with the collection of tools the standard KDE install offers. In the world of open-source development, things change quickly. In three months, I may feel differently.

To control the basics of your environment, use GNOME's sessions manager, gnomecc. You can find it under the Utilities menu as "system info". On the GNOME panel, it is likely under that toolbox icon. KDE, on the other hand, has its control center (kcontrol). On the KDE panel, it looks like a computer screen with a circuit board superimposed on it. One of nice things here is that you can get a snapshot of what your machine looks like. Now, you might think that something that bills itself as a "control center" would contain everything having anything to do with your system. Not entirely true. The GNOME and KDE control centers give you some control (desktop themes and looks, colors, styles, etc.), but for other functions, you'll need to pull in other tools.

In the KDE bundle, you will find kdat, a tar-based backup system. Then, try out kuser, a nice graphical user and group manager. Ksysv, which we will cover later, is a system run-level editor. For RPM and DEB package management, try out kpackage. In the print queue management department, check out klpq. With this tool, you can select print jobs by printer, reorganize the print order, or remove jobs entirely.

GNOME has its own crop of tools. Need to reset your system's clock? Try timetool. For RPM package management, there's gnorpm. For most system administration tasks, GNOME has incorporated the linuxconf tool (discussed here last week).

One of the great things about X and Linux is that you can run those tools you've grown to love on remote systems (assuming they are installed, of course). While writing this article, I had a chance to try out some of these things under an interesting environment. My notebook's hard disk crashed, forcing me into a quick reinstall. On a lark, I decided to load Caldera 2.3 instead of my usual Red Hat install. Then, I proceeded to do remote administration on my Red Hat development machine. To illustrate, we are going to do a little remote administration on another machine's run levels--KDE-style. That's the example I promised you earlier on.

Before I tell you about the KDE SysV Init Editor, let me cover just a tiny bit of background. When your system boots up, it starts a number of services. These can be a web server, an X window font server, sendmail, or any number of other things. Which services get started are decided by the run level at which your system boots. Take a look at the file called /etc/inittab for the run level. The line you are looking for is right at the bottom of the following listing (initdefault), but on your system, it is most likely at the top of the file itself. I included the comment lines so you could see what the levels mean on my Linux system (Red Hat 6.0). Yep, that's right. The one with the blown-up disk drive!

   #   0 - halt (Do NOT set initdefault to this)
   #   1 - Single user mode
   #   2 - Multiuser, without NFS (The same as 3, if you 
           do not have networking)
   #   3 - Full multiuser mode
   #   4 - unused
   #   5 - X11
   #   6 - reboot (Do NOT set initdefault to this)
   #
   id:5:initdefault: 

So, my system starts at run level five. To find out what gets started, I do a long listing (ls -l) of /etc/rc.d/rc5.d.

   # ls -l /etc/rc.d/rc5.d

Here is a partial listing of what I see there.

lrwxrwxrwx   1 root   root  17 Jul 18 13:48 S10network -> ../init.d/network
lrwxrwxrwx   1 root   root  17 Jul 18 13:48 S11portmap -> ../init.d/portmap
lrwxrwxrwx   1 root   root  15 Jul 18 13:48 S15netfs -> ../init.d/netfs
lrwxrwxrwx   1 root   root  16 Jul 18 13:48 S20random -> ../init.d/random
lrwxrwxrwx   1 root   root  16 Jul 18 13:48 S30syslog -> ../init.d/syslog

Notice the arrows pointing to other files in the /etc/rc.d/init.d directory. These are simply symbolic links to the actual files that start and stop the various services. If a link to the file exists, that service is started. Rather than doing things the command-line way, let's try the KDE SysV init editor.

To administer the run levels on marvin (a host on my network) from my own system, I would open up an Xterm session and run xhost to allow client access to my system from marvin.

   # xhost +marvin
   marvin being added to access control list

An explanation of what happens here from an X window perspective would take a whole column (or two) on its own, so I won't go into a great deal of detail (not today anyway). I will simply work on the premise that you are running Linux from some kind of graphical desktop environment (KDE or GNOME), and all this should work as described.

From my system, I now telnet to marvin. I log in as myself, and switch to the root user in order to do root-level administration.

   [mgagne@marvin mgagne] su - root
   Password: *********
   # 

From here, I set my DISPLAY variable so that X sessions that run on marvin know how to find me.

   DISPLAY=myhostname:0 ; export DISPLAY

That's it. I can now run any of these graphical administration programs (or anything) from the command-line shell prompt.

   # ksysv

This runs the KDE system V run-level editor. You add or remove services from the various run levels by dragging daemons (or services) from the list on the left-hand side to the various columns (one for each run level). Notice, as well, that there is a start and a stop for each run level: start for boot time, stop for shutdown. To remove a service, simply grab it from the startup or shutdown list and drag it into the trashcan on the left.

Warning! Warning! Danger! We won't do this today, but be careful with this one. Some of these services are required for your machine to run. You don't want to simply delete things because it sounds cool or looks scary. If you ever get yourself into trouble and need to re-add something (albeit not through X), you can always reboot into single-user mode by typing linux single at the LILO: prompt.

In the same way, if I typed kpm I could run the KDE visual process manager, a cool and powerful graphical version of the top or ps command. Typing gtop would run the GNOME system monitor (somewhat more colorful than kpm).

If, like me, you just can't wait to get your hands on the latest and greatest system administration tool for your favorite desktop environment, then you might want to scroll down the list of available packages on the appropriate desktop web sites. Before I give you those URLs, keep in mind that the software listed can sometimes be in the very early stages of development and may still have the odd bug to swat. For those of you who don't really enjoy compiling and installing your programs from distribution tarballs, this may not be for you, since some of this software might not be in standard distribution formats like RPMs or DEBs.

With those warnings firmly in place, here are those promised links. Starting with the GNOME crowd, check out the GNOME Software Map at http://www.gnome.org/applist/list-martin.phtml. Once there, click on "System Utilities" for sys admin tools and utilities.

Today, I downloaded and compiled the gnome-admin package from the web site. It comes with a nice logfile viewer (logview) and a printer management tool (gulp) like the klpq program I mentioned above. Now, for the KDE users out there, you can surf on over to the address below. What you are looking for is likely in the ADMIN portion of the page.

   http://www.kde.org/applications.html

Once again, I am far too long-winded and my time (and space) has run out for the week. So, until next time, remember the KISS rule. Keep It Simple, Sysadmin.