Ask Shadowman: LinuxWorld Edition

August 2002

He's bold. He's beautiful. He's got only one name like Sting or Shaft. And every month Shadowman answers the toughest technical questions anyone has ever dared ask a two-dimensional logo. This month's mission: To ask Shadowman that one question you'd love to ask if you saw him at LinuxWorld. A remarkable feat considering Shadowman's mouth was lost in a tragic logo designing accident.

Join us again in September when Shadowman crosses the chasm and thinks outside the box as he answers your questions about web serving (or, like always, anything else you've got on your mind).

End the silence.

Got a question that you'd like Shadowman to answer? Ask him.

Before Shadowman starts this month's festivities, he has some unfinished business that needs attention.

Shadowman's answer to Rich B's question in the July column neglected to mention another interesting technology that could be used to deploy thin clients under Linux.

What is Shadowman talking about? The Linux Terminal Server Project, along with its more educationally-oriented cousin, the K-12 Linux Terminal Server Project.

Many of Shadowman's readers reminded Shadowman of LTSP (and questioned Shadowman's intellectual capacity for forgetting LTSP).

So to all those readers, Shadowman agrees that LTSP is "da bomb", and that Shadowman's forehead does slope precipitously.

Ted (with no last name) stepped up and said:
I am writing to you to announce System Administrator Appreciation Day.

System Administrator Appreciation Day: A special day, once a year, to acknowledge the worthiness and appreciation of the person occupying the role, especially as it is often this person who really keeps the wheels of your company turning.

On this special international holiday, give your System Administrator something that shows that you truly appreciate their hard work and dedication. Let's face it, System Administrators get no respect 364 days a year.

Consider all the daunting tasks and long hours (weekends too.) Let's be honest, sometimes we don't know our System Administrators as well as we should. Remember this is one day to recognize your System Administrator for their workplace contributions and to promote professional excellence. Thank them for all the things they do for you and your business.

System Administrator Appreciation Day

Friday - July 26th, 2002 - Celebrated annually on the last Friday of July.

For more information: Visit

Shadowman says:
Unfortunately, Ted neglected to take into account one minor detail -- Shadowman's publication schedule. So by the time Shadowman's faithful readers see this, they will have missed the festive occasion.

But all is not lost! You can arrange a belated celebration for this year, and mark your calendars for July 25th, 2003. As a former sysadmin, Shadowman says this is a "must-attend" event!

Amie Y. traipsed over and asked:
I am new to to Linux and I really need your help, I lost my root password on my machine running on Linux 6.2. How can I recover it? I would really appreciate your help. Thanks a lot!!!

Shadowman says:
Shadowman has been in a similar situation with the Shadowcar -- there's nothing like the sinking feeling of seeing the car keys sitting on the dash of a '63 Studebaker a millisecond before the locked car door slams shut.

Fortunately, unlike Shadowman, you won't need a slim jim -- here's all you need to do:

  1. Shutdown your system
  2. Boot into single-user mode by entering "linux single" (without the quotes) at the "boot:" prompt. Note that depending on how LILO is configured on our system, you might have to press Control-X as soon as LILO's graphical interface comes up, in order to exit the LILO graphical boot screen to see the "boot:" prompt.
  3. Once the system boots, you should see a "#" prompt.
  4. At the "#" prompt enter "passwd root" (again, without quotes). Follow the prompts to enter (and confirm) your new root password.
Once this is done, you can shutdown (shutdown -r now) and reboot Linux into its normal multi-user mode. You should then be able to login as root with the new password.

All without getting tapped on the shoulder by a police officer asking, "Is this your car, sir?"

Juan E. strolled over and whispered:
I come from NOVELL and IPX world. I am having some problems with TCPIP. Please recommend some books or online documentation, specially setting a server with 2 ethernet cards.

Also why under TCPIP you get collisions (led always on during traffic) in your hub, and the same hardware with Novell and IPX you don't have collisions. I change a regular hub for a switch and I get no collisions and 10x more speed.

I purchased 7.3 and I am very impressed with the speed and quality of the software. I installed Samba and Postgresql with success.

Shadowman says:
Because Shadowman is a contrary sort of fellow, he'll answer your second question first.

I assume you're running IPX and TCP/IP on some flavor of Ethernet. In that case, there's a long and impressive-looking term you should know:

Carrier Sense Multiple Access/Collision Detect
(This is often abbreviated as CSMA/CD -- just the thing to put on the ol' resume!)

Although the term looks impressive, it's really quite simple, once you start breaking all those words apart.

What CSMA/CD means is that the actual wires that make up your Ethernet network are a shared resource (that's the "Multiple Access" part), and that when more than one system attempts to use this shared resource, it "listens" (the "Carrier Sense" part) before attempting to use the shared resource.

So far so good?

However, there can be times when this "listen before you speak" approach fails, and two or more systems attempt to "speak" at the same time. This is known as a collision.

Although it sounds like a disaster, it really isn't -- it's a natural aspect of any network that utilizes a shared communications medium. That's where the last part of CSMA/CD (Collision Detect) comes into play. By detecting collisions, the systems involved in the collision can wait for a little while and try again. (This "waiting a little while" also has an impressive name -- "truncated binary exponential backoff" -- but that's another subject for another day.)

Since CSMA/CD is an integral part of Ethernet hardware design, Shadowman would expect that you'd see collisions with IPX as well, assuming a sufficiently high network load.

As far as your observations when swapping your hub for a switch, Shadowman feels that this is not so unusual. After all, the purpose of a switch is to direct packets only to their intended destination (unlike a hub, which simply retransmits a packet received on one port to all the other ports). Using a switch, you would normally see no collisions (and possibly an increase in speed, if the network is heavily loaded with traffic not directed at either of the two systems communicating over the switched connection).

Now, for your first question -- Shadowman suggests starting with the Red Hat Linux documentation; specifically the Red Hat Linux Customization Guide, as it discusses the tools necessary to configure ethernet cards. This will give you basic connectivity; after that, there are many different directions in which you can go (packet forwarding, firewalling, etc), so Shadowman can't suggest much beyond that without having more information.

However, Shadowman notes that it would also be helpful to have a good reference on TCP/IP. Shadowman personally uses O'Reilly's _TCP/IP Network Administration_ and has found it quite helpful, though it's by no means the only TCP/IP reference.

Enjoy your Red Hat Linux 7.3 system!

Michael C. slogged by and whined:
I cannot FTP or telnet from or to Linux from my XP box. I know that the FTP and Telnet are on Linux and I can Ping both computer IP address. Could you please send me the steps?

Shadowman says:
Shadowman can't be sure without a bit more information, but your problem could be due to several different issues:

  • Lack of hostname to IP address resolution
  • Services not running on the Linux system
  • Overly restrictive firewall in place
If the failure is due to problems resolving IP addresses, you should be able to FTP/telnet using IP addresses. In that case, you should check /etc/resolv.conf to make sure that there's at least one "nameserver" line there, and that its IP address actually points to a running (and accessible) name server.

On the other hand, if you can ping by hostname and not just by IP address, then the second issue (services not running) is more likely. This is a pretty common situation, as the default settings at installation time are to *not* start any of these services. It's more secure, particularly for new Linux users that might not be aware of the security implications of leaving unneeded services running. However, it's easy to start these services if you need them. Just issue these commands (while logged in as root, of course):

/sbin/chkconfig wu-ftpd on
/sbin/chkconfig telnet on

(As one would imagine, changing the "on" to "off" would reverse the process, should one be so inclined.)

That said, Shadowman would feel remiss if he didn't mention that it would be far better from a security standpoint to use a more secure method of remote login and file transfer. Otherwise, you know those passwords you type in when telnet'ing or FTP'ing? A cracker that was packet sniffing your network would see them as plain as day.

That's why Shadowman uses OpenSSH -- by using the "ssh" command to perform remote logins, and "scp" to copy files to/from remote systems. That way, all information sent between the two machines is encrypted

Ah, but you are no doubt saying, "Shadowman, you son of a hamster, how can I possibly use OpenSSH when I'm communicating with a system running Windows XP?"

To such a question I would respond, "Fear not, there is an SSH implementation even for the Window-laden! It is known as PuTTY (" Shadowman has not personally used it (the Shadow Lair being a Windows-free zone), but he hears that it is, in fact "all that".

And no, Shadowman is not the son of a hamster (nor did Shadowman's father smell of elderberries). Ni!

Aaron P. pranced by and shouted:
Recently, I installed Domino on RH 7.2 and it works wonderfully, however I had to uninstall sendmail due to the conflict over port 25 (two mail agents fighting over who gets SMTP, imagine!). I believe that when Tripwire is installed with this dist it was configured to use sendmail to alert root or whoever of any file changes, but since sendmail is gone I need it to send its alerts to a designated Domino user. Do you know of any documentation that would resolve this predicament that I have created for myself.

Shadowman says:
Although he's afraid that this answer will dishearten his loyal followers, Shadowman doesn't have a clue (about the answer to this question, that is).

However, Shadowman is going to take a stab at this problem, and illustrate how one can often find the necessary information with a bit of searching and contemplation.

Shadowman used the following command to locate the configuration files for tripwire on his Red Hat Linux 7.3 system (the results on your 7.2 system should be identical):

$ rpm -qc tripwire
Using Shadowman's years of computer experience, he picked twcfg.txt (mainly because the "cfg" part of the filename made it look like it might mean that this file actually contained configuration information of some sort), and looked at it using less:
$ less /etc/tripwire/twcfg.txt 
ROOT =/usr/sbin
POLFILE =/etc/tripwire/tw.pol
DBFILE =/var/lib/tripwire/$(HOSTNAME).twd
REPORTFILE =/var/lib/tripwire/report/$(HOSTNAME)-$(DATE).twr
SITEKEYFILE =/etc/tripwire/site.key
LOCALKEYFILE =/etc/tripwire/$(HOSTNAME)-local.key
EDITOR =/bin/vi
MAILPROGRAM =/usr/sbin/sendmail -oi -t
Seeing the word "sendmail" appearing in the file gave Shadowman an idea -- Shadowman could be wrong, but spending some quality time with Google (using the terms "tripwire", "MAILMETHOD", and "MAILPROGRAM") should get you much closer to your solution.

However, you will need to figure out how to use Domino to send mail from the command-line -- Shadowman doesn't play with dominoes, so to speak...

Jason L. hiked up and mumbled:
How would I go about getting a new utility put on the next version of Red Hat?

Shadowman says:
Shadowman accepts small, unmarked bills.

(Just kidding.)

Before new software can be considered for addition into the actual Red Hat Linux distribution, there are a few requirements that must be met:

  1. The software must be made available under an appropriately open license
  2. The software must either address a strategic need for our customers that has as yet gone unmet, or is obviously superior to other software that is already in the distribution
  3. The unmarked bills must be placed in one of those really nice ZERO Halliburton aluminum attache cases (black anodized, preferably), and left in locker #42 in the Cary, North Carolina train station
(Just kidding about #3.)

Then it's a matter of the Red Hat engineers taking the software, building it, packaging it, beating on it, and using it themselves on a daily basis. If, after all this, they think the software has what it takes, then it'll be considered for inclusion.

Of course, if the key to locker #42 was left hanging off the cleat of the flagpole holding the Red Hat flag in front of Red Hat HQ, and if Shadowman received an email containing the words, "The aardvark has powerful claws, but squinty little eyes.", you never know...

(Just kidding. Really.)

Paul K wandered over, and stated:
I always wanted to know more about semaphores and how they are used in the linux kernel.

Shadowman says:
Whenever the word "semaphore" is mentioned, Shadowman thinks back to the time when he was but a Shadowlad, trying to earn a merit badge by learning semaphore. Unfortunately, the only letters that Shadowman learned were N, R, and U. Of course, this choice of letters was somehow appropriate, given that my best friend Pinky Carruthers found a copperhead in the latrine that day. Scoutmaster Whorfin wasn't amused when Shadowman signaled "RUN" to Pinky; he thought "PULL UP YOUR PANTS" would have been more helpful.

But Shadowman digresses.

If you look in /usr/src/linux-2.4/Documentation/DocBook on your Red Hat Linux system system, you'll find a discussion on how locking is done within the Linux kernel. This document includes some good information on semaphores; it's in a file named "kernel-locking.tmpl", and is a DocBook/SGML file. Use db2html to turn it into something more Mozilla-friendly.

And watch out for those copperheads!

Craig M. tiptoed up and screamed:
Why can't UTB be sent as plain text?

Having gone Linux-all-the-way, I'm using Sylpheed as my email client and the links in the HTML UTB are worthless -- which means UTB is only little more than worthless.

Surely Red Hat wouldn't want to send me worthless stuff, wouldn't they?

Shadowman says:
Shadowman agrees -- HTML mail is the spawn of evil. However Red Hat needs to get the message (including Shadowman's words) out in whatever format will reach people. And unfortunately, there are a lot of people out there that like their email chock full of HTML, and dripping with Javascript.

Fortunately, UTB can be received as plain text -- and there are two ways to do it!

  • If you login to, under "General Preferences", you'll see that you can set your preferred email formail to "text only"
  • If you can dig through all the HTML in your last UTB, you'll find a link near the bottom entitled "Update Subscription Options" -- click that link and do what comes naturally
Soon you'll be receiving UTB in all its low-fat ASCII glory.

Thabang H. ran by, panting:
I have a problem executing binary files which were migrated from SCO Unix 5.0.5.e to Red Hat Linux 7.2. Do I need some sort of patch or kernel in order to fully migrate from SCO to Red Hat 7.2.

These files were transported from SCO to Red Hat via ftp in Binary mode.

Shadowman says:
What you're looking for is iBCS (Intel Binary Compatibility Standard) support. Unfortunately, iBCS support has never seemed to get that much attention (probably because of the relative dearth of individuals actually in possession of iBCS-compliant binaries and unable to recompile).

It appears that the project to maintain iBCS support under Linux has had a rocky time over the years. Shadowman is not sure of the viability of the project as it currently exists, though he notes that you can visit the project homepage to learn more:
That said, Shadowman notes that iBCS support is still present in the 2.4 kernel. However, it has never been tested (and is therefore unsupported) by Red Hat. As the kernel guru that Shadowman asked put it, "if it breaks you get to keep both pieces."

Best of luck!

Marty P. legged it over, and stated clearly:
I want to capture screen shots of loading Linux but can't figure out how to do so. I see a lot of documents that have screen shots of loading Linux but since the OS isn't loaded yet I can't run "import", "xwd", or any other such capture programs. Can you help me?

Shadowman says:
Realizing that the Red Hat Linux Installation Guide includes screenshots of an installation in progress, Shadowman strode purposefully over to "Club Docs" -- the home of the Red Hat Linux Documentation group. Once the writers there mentioned a few key points to Shadowman, it all became clear.

Let's see how long it takes you to smack your forehead with your hand, and shout, "Of course!"

  • The Red Hat Linux graphical installation program (known asAnaconda to its friends), uses the X Window System.
  • The X Window System can use local or remote displays.
Shadowman still had that "deer in the headlights" stare at this point, so the Club Docs writers continued:
  • So what if you ran Anaconda on one box, and directed the displayto another box?
When Shadowman still had a vacant stare, the writers sighed deeply, and finally gave up their secret. This is how it's done:

When booting the installation program on the system on which you are going to install Red Hat Linux, simply enter the following at the "boot:" prompt:


This option enables remote display forwarding. The "IP" should be replaced with the actual IP address of the system on which you want the display to appear.

Before doing this, however, you must execute this command on the system that will be displaying the installation:

xhost +remotehostname

Where "remotehostname" is the name of the host you are running the original display from. Sure, you could just use the command "xhost +" to completely open access to your system, but that would make it easy for not-so-nice people to do things like grab your keyboard and mouse, display anything they like on your screen, and other antisocial behaviors.

When the Anaconda screen appears on your "display" system, simply proceed with the installation as you normally would, taking the necessary screeenshots as you go.

Hope you caught on faster than Shadowman!

Adriana C. hoofed it over, and sang:
How many people in the world know Linux and how many people will know it in the next five years.

Shadowman says:
Ah, another two-part question requiring two answers. Here are Shadowman's answers:

  • A lot.
  • A lot more.
Shadowman apologizes for the glib answers, but urges you to check out for some good links as to why a better answer is difficult. Oh, and don't worry about Linux Journal 404'ing the "Sizing the Linux Market" paper -- Google is your friend...

GONZO (no last name) staggered over, and cried:
Hi I'm learning fortran (g77), but I'm failing to get the command to send output to the printer within the code. I know that in Microsoft fortran you can do the following:


This should print HELLO on the printer. Please advise.

Shadowman says:
Shadowman's first programming language was FORTRAN, punching cards on an IBM 026 (or when he was lucky, an 029) keypunch machine. Yes, Shadowman is that old. But Shadowman did have the benefit of learning FORTRAN from the coolest programming book ever:

FORTRAN For Humans
Any programming book brave enough to discuss the heartbreak of eye odor in an adult manner is tops in Shadowman's book.

In any case, though it's been many years, Shadowman notes that you should quote HELLO; otherwise, you won't get the literal string "HELLO" as output. But Shadowman won't be a pedantic slob, at least as long as being a simple slob is easier.

The PRN device is an old DOS construct giving direct access to the printer; under Linux, the printer normally is accessed via a spooler such as lpd (which itself necessitates the use of the lpr command to submit print jobs). Therefore, without explicit support from g77 for such features as "print on close", the best you can do is to direct all output to be printed to unit 6 (no OPEN statement is necessary), and then pipe the program's standard output to lpr, like so:

./foo | lpr

Chin up! It could be worse: you could have to use punch cards. Or have eye odor...

Lindsay L. danced by, reciting:
I am battling to make my Web Browsing an enjoyable experience under Red Hat 7.2. Simply put, Web Pages with either of these browsers (Mozilla and Netscape) look terrible. It makes them hard to read and as a result I go back to WIndows for Web browsing. I tried following the instructions in the Deuglification How-To, loaded all my Windows ttf files, but it still does not look good. How can I overcome this problem?

Shadowman says:
Shadowman had this exact same problem, with some fonts looking so bad they just made Shadowman's eyes bleed. Without looking at your system, Shadowman can't be sure, but here is a possible cause for the ugly fonts.

Depending on the system configuration, the X server sometimes uses screen resolutions with DPI (Dots Per Inch) values that are different in the vertical and horizontal directions. This can cause scalable fonts to scale in unnatural (and visually unappealing) ways.

You can see if this is your system's problem by issuing this command (while in an active X session):

$ xdpyinfo | grep resolution
    resolution: 71x86 dots per inch

If (like above) the numbers are different, you can force a consistent DPI setting by passing the -dpi option to the X server. This is done in different ways, depending on how X is started on your system. For example, if you use the GNOME Display Manager (gdm), you can do this by changing the following line in /etc/X11/gdm from this:


to this:

0=/usr/bin/X11/X -dpi 75

Shadowman hopes this will prevent ocular hematoma for you, too.

Girish S. stepped on Shadowman's toe, and muttered:
I installed Redhat Linux 7.2 using CD's in Linux Bible by Neggus. I have a dual boot system with Windows ME and Redhat Linux 7.2. The booting is controlled by LILO.

If I have an entry of vfat type in the file /etc/fstab the system refuses to boot saying "Fat32 support is only alpha". This happens, for example, if I boot the system and using Linuxconf add a vfat partition through Access Local Drive menu, read-write to this partition and then forget to delete the entry before shutdown. I can read-write to vfat partition without any problem. But I have to delete this entry, using Linuxconf - which removes the line from /etc/fstab - , before I shutdown. If I do not do this, and the /etc/fstab file retains a line for a vfat type partition, then I am unable to boot next time! Moreover, this happens irrespective of whether the vfat partition added in Linuxconf/Access Local Drives is made user mountable or mountable at boot time.

There does not seem to be any problem if I use a mount vfat drive - work with it - umount vfat drive sequence. The hitch seems to be only with a vfat line in /etc/fstab at the time of booting. Is it that mount-...-umount does not add such a line whereas adding the vfat partition using Linuxconf does? Or is the problem something different?

How do I solve the problem?

Shadowman says:
Sometimes Shadowman wonders about computer error messages. Some messages are completely accurate, but totally useless (at least in terms of figuring out the problem). This error message is a good example.

Here's the problem. Shadowman guesses that you have an fstab entry that looks something like this:

/dev/hda2 /foo vfat defaults 1 1

when it should look something like this:

/dev/hda2 /foo vfat defaults 1 0

Did you catch the difference? It's that last number, on the end of the line. According to the fstab man page, that number is used by fsck to determine the order in which the filesystems are checked at boot time.

The problem is that fsck does not fully support vfat filesystems (remember, "Fat32 support is only alpha"). By having a non-zero number in fstab, fsck attempts to do what it is not yet capable of doing.

If you set this number to zero, Shadowman is confident your system will display at least one less error message.

Bob H. held up his goodie bag and hollered:
I run RedHat Linux 7.2 as my home firewall, and have also set up separate accounts for all my kids to login and use applications, play games, or web browse. When I install a new application, how do I add it to everyone's Gnome menus?

Shadowman says:
Shadowman has dabbled in GNOME menu hacking from time to time (usually to put racy tooltips on Shadowwoman's system). If you look in /etc/X11/applnk, you'll find a hierarchy of directories and files that mirror the GNOME menus. Simply use the .desktop files you find there as templates (they are text files with an easy-to-understand format) and create your own file for your new applications.

Shadowman wouldn't recommend racy tooltips for your kids, but perhaps something like "Have you finished your homework?" would be more appropriate.

Rene F. waltzed by, and exclaimed:
I need help understanding how to hook up a serial cable to devices like routers and switches using Linux 7.2. I was told than Minicom is the app to use. I'm not sure as to how it connects to a Com port. I'm trying to connect to /dev/sda0? Or something similar? I'm not sure I'm using the correct terms.

Shadowman says:
In days long past, Shadowman administered computers that were known by the now-quaint name of "timesharing systems." These systems consisted of a single computer surrounded by scads of serially-attached dumb terminals. It was during this time that Shadowman came to loath the Electronic Industries Association's Revised Standard number 232, also known as RS-232.

And now you will, too.

Because the RS-232 standard was originally developed as a means to interface computers with things such as modems, multiplexers, and line drivers, the standard treats all serial devices as being one of two types:

  • Devices that move bits from point A to point B (known as Data Communications Equipment, or DCE)
  • Everything else (known as Data Terminal Equipment, or DTE)
In the happy, sing-song, fantasy land of RS-232, these two types of devices are only ever connected to their opposite kind -- DTE to DCE, and DCE to DTE.

Unfortunately, the real world is not so simple.

As Shadowman found out, quite often one needs to connect, say, a computer (DTE) to a dumb terminal (also DTE). This is the sort of thing that is just not done in polite company. However, it's pretty darn common everywhere else.

So common, in fact, that a there's a special term for the cable that is used to perform such an "unnatural act":
A null modem cable
A null modem cable gets its name from the fact that modems are DCE devices. Since only DCE devices should connect to DTE devices, a null modem cable is wired in the same way as a modem. However, because the cable is, well, just a cable, it doesn't really do anything -- it's function is null. Therefore, it's a "null modem" cable.

Shadowman is not normally a betting person, but he would be quite surprised indeed if the console port on your routers and switches are DCE. No, Shadowman is pretty sure that they are DTE, as is the serial port on your computer.

So you'll need a null modem cable.

Of course, you can't just get any old null modem cable. No, you have to make sure that it will fit -- after all, RS-232 connectors come in 9-pin and 25-pin flavors. And once you have the number of pins straight, you'll then need to make sure you have the proper gender for each connector. Shadowman would explain this point further, but feels that this is a subject best discussed with your mommy and daddy.

Are you loathing RS-232 yet?

Are we done yet? Not nearly! Next, you'll need to determine whether the port on your routers and switches require modem control signals.

Then you'll need to determine how flow control will take place -- will it be hardware (using the CTS and RTS pins) or software (transmitting XON and XOFF ASCII characters)?

All this can affect the type of cable you will need.

Feeling a bit of animosity toward RS-232 yet?

No? Ok, then you'll need to make sure that you have the right "comm parameters" for your routers and switches. These parameters include:
  • Baud rate
  • Parity
  • Number of stop bits
At this point, you can finally start to think about the Linux side of things. First, you'll need to configure minicom. To do this, login as root, and issue the command:

minicom -s

You will then see a menu; use the cursor keys to select the "Serial port setup" menu entry. Here you can set the comm parameters, flow control, and the serial device (which will likely be either /dev/ttyS0 or /dev/ttyS1). When you've finished, select the "Save setup as dfl" menu entry to make this the default. Finally, select the "Exit from minicom" menu entry.

You're now ready to give it a try. Start minicom (without the -s this time), and hopefully you'll be connected to your switches and routers.

If, after all this, you'd like to borrow Shadowman's RS-232 voodoo doll, just let Shadowman know.

Jim B. bent over to tie his shoelace, and grunted:
My question to the Shadowman; How do I go about upgrading my version of rhl 7.2 to 7.3?

Shadowman says:
Your question caught Shadowman by surprise initially -- since moving away from the do-I-have-enough-floppies world of Slackware "upgrades" in the early '90s, over the years Shadowman has started to take the idea of easy operating system upgrades for granted.

But if one person is asking this question, that means there are others out there that have the same question in mind. So for you -- and everyone else out there that might wonder about this -- Shadowman will give you the answer.

Thanks to Red Hat's packaging technology (RPM, which stands for -- recursively enough -- "RPM Package Manager"), the process is actually rather straightforward, and is nicely documented in the Red Hat Linux 7.3 Installation Guide. You can find an online copy here:
Shadowman recommends that you read the introduction, along with chapters 1 and 2. This should give you sufficient background for the actual upgrade, which is discussed in Appendix A (which you should read, as well).

Before actually starting the upgrade, it's always a good idea to make backup copies of any critical data on the system -- just in case. After that, it's just a matter of getting the installation booted, selecting the "Upgrade Existing System" option on the Install Options screen, and responding to the various prompts along the way.

Best of luck with your upgrade!

Noel L. trudged slowly past, groaning:
I'd like to be able to run RHL at the desktop and access my Samba server for file and print services. Is there any other way other then using smb client to do this? Is there a way to use my "Home" browser icon running under KDE to browse to my Samba server to locate files?

Shadowman says:
At first, Shadowman almost fell for your subtle ploy, but he has seen through your nefarious scheme. Oh, don't act so innocent -- you know what you were trying to do. You wanted Shadowman to overlook the fact that a server running Samba is either running Linux (or a Linux-like operating system). Furthermore you wanted to trick Shadowman into suggesting something as ludicrous as:

        Taking a desktop machine running Red Hat Linux...

        ...and making it emulate a Windows system...
 it can access file and print services...

        ...which are provided by the Samba emulation software...

       ...that is running on a Linux system!

Ah, but Shadowman won't play your little game. Instead, he will bravely submit to you that it would make far more sense for a Linux desktop system to access file as print services on a Linux (or Linux-like) server using the native Linux tools and protocols.

Therefore, for file services Shadowman suggests you use NFS. This is described very well in the Red Hat Linux Customization Guide (available at, so Shadowman isn't going to repeat all the information here.

However, the short version is that you must configure your server to export the desired filesystem(s), and then configure your desktop system to mount the exported filesystem(s).

Once this is done, the remote filesystem will appear just as if it was local to your client system. This would make it possible for your browser to browse the remote files.

As for accessing remote printers, Shadowman recommends that you read -- wait for it -- the printer configuration chapter in the Red Hat Linux Customization Guide. Although the printer configuration supports several different ways of connecting to remote printers, Shadowman suggests that you use the Unix standard LPD remote printer setting.

Make sure you configure your server to allow your desktop system to access to the printer! (This is also covered in the Customization Guide.)

At this point, you should be accessing files and printing remotely in fine style.

Of course, if there is some reason that you *must* access the remote file and print services as Redmond intended, Shadowman will doff the red fedora to honor your sacrifice, and note that Linux does support the direct mounting of SMB-served files. The mount and smbmount man pages should give you the necessary information, if an "all in the family" solution would not work for you.

Likewise, the printconf printer configuration tool supports the configuration of SMB-attached printers, should that be the only available way of accessing the remote printer.

Shadowman wishes you well with your remote file and print access!