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
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
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
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
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
For more information: Visit http://www.SysAdminDay.com
Unfortunately, Ted neglected to take into account one minor detail --
Shadowman's publication schedule. So by the time Shadowman's faithful
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
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
appreciate your help. Thanks a lot!!!
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:
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
- Shutdown your system
- 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.
- Once the system boots, you should see a "#" prompt.
- At the "#" prompt enter "passwd root" (again, without quotes). Follow the prompts to enter (and confirm) your new root 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
change a regular hub for a switch and I get no collisions and 10x more
I purchased 7.3 and I am very impressed with the speed and quality of
the software. I installed Samba and Postgresql with success.
Because Shadowman is a contrary sort of fellow, he'll answer your second
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
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
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
try again. (This "waiting a little while" also has an impressive name
-- "truncated binary exponential backoff" -- but that's another subject
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
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
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
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.
please send me the steps?
Shadowman can't be sure without a bit more information, but your problem
could be due to several different issues:
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
- Lack of hostname to IP address resolution
- Services not running on the Linux system
- Overly restrictive firewall in place
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
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
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
To such a question I would respond, "Fear not, there is an SSH
implementation even for the Window-laden! It is known as PuTTY (
http://www.chiark.greenend.org.uk/~sgtatham/putty/)." Shadowman has not
personally used it (the Shadow Lair being a Windows-free zone), but he
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
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
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
resolve this predicament that I have created for myself.
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
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
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:
$ rpm -qc tripwire
Seeing the word "sendmail" appearing in the file gave Shadowman an idea
-- Shadowman could be wrong, but spending some quality time with Google
terms "tripwire", "MAILMETHOD", and "MAILPROGRAM") should get you much
closer to your solution.
$ less /etc/tripwire/twcfg.txt
MAILPROGRAM =/usr/sbin/sendmail -oi -t
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
Shadowman accepts small, unmarked bills.
Before new software can be considered for addition into the actual Red
Linux distribution, there are a few requirements that must be met:
(Just kidding about #3.)
- The software must be made available under an appropriately open license
- 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
- 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
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
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.
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
semaphore. Unfortunately, the only letters that Shadowman learned were
N, R, and U. Of course, this choice of letters was somehow appropriate,
my best friend Pinky Carruthers found a copperhead in the latrine that
day. Scoutmaster Whorfin wasn't amused when Shadowman signaled "RUN" to
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
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
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
Surely Red Hat wouldn't want to send me worthless stuff, wouldn't they?
Shadowman agrees -- HTML mail is the spawn of evil. However Red Hat
needs to get the message (including Shadowman's words) out in whatever
reach people. And unfortunately, there are a lot of people out there
Fortunately, UTB can be received as plain text -- and there are two
to do it!
Soon you'll be receiving UTB in all its low-fat ASCII glory.
- If you login to www.redhat.com, 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
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.
What you're looking for is iBCS (Intel Binary Compatibility Standard)
support. Unfortunately, iBCS support has never seemed to get that much
(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
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
since the OS isn't loaded yet I can't run "import", "xwd", or any other
such capture programs. Can you help me?
Realizing that the Red Hat Linux Installation Guide includes screenshots
of an installation in progress, Shadowman strode purposefully over to
-- 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!"
Shadowman still had that "deer in the headlights" stare at this point,
so the Club Docs writers continued:
- 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.
When Shadowman still had a vacant stare, the writers sighed deeply, and
finally gave up their secret. This is how it's done:
- So what if you ran Anaconda on one box, and directed the displayto another box?
When booting the installation program on the system on which you are
going to install Red Hat Linux, simply enter the following at the
This option enables remote display forwarding. The "IP" should be
replaced with the actual IP address of the system on which you want the
Before doing this, however, you must execute this command on the system
that will be displaying the installation:
Where "remotehostname" is the name of the host you are running the
original display from. Sure, you could just use the command "xhost +"
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
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
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 apologizes for the glib answers, but urges you to check out
http://counter.li.org/estimates.php 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...
Ah, another two-part question requiring two answers. Here are
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:
WRITE (1,*) HELLO
This should print HELLO on the printer. Please advise.
Shadowman's first programming language was FORTRAN, punching cards on an
IBM 026 (or when he was lucky, an 029) keypunch machine. Yes, Shadowman
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
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,
./foo | lpr
Chin up! It could be worse: you could have to use punch cards. Or have
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
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
How-To, loaded all my Windows ttf files, but it still does not look
good. How can I overcome this problem?
Shadowman had this exact same problem, with some fonts looking so bad
they just made Shadowman's eyes bleed. Without looking at your system,
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
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
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
line in /etc/X11/gdm from 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
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
before shutdown. I can read-write to vfat partition without any problem.
But I have to delete this entry, using Linuxconf - which removes the
/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
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
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?
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
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
Shadowman has dabbled in GNOME menu hacking from time to time (usually
to put racy tooltips on Shadowwoman's system). If you look in
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
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
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
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
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
standard treats all serial devices as being one of two types:
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.
- 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)
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
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.
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
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
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.
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
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:
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
issue the command:
- Baud rate
- Number of stop bits
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,
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
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?
Your question caught Shadowman by surprise initially -- since moving
away from the do-I-have-enough-floppies world of Slackware "upgrades" in
'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
Thanks to Red Hat's packaging technology (RPM, which stands for --
recursively enough -- "RPM Package Manager"), the process is actually
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
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
just a matter of getting the installation booted, selecting the "Upgrade
Existing System" option on the Install Options screen, and responding to
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
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?
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
Furthermore you wanted to trick Shadowman into suggesting something as
Taking a desktop machine running Red Hat Linux...
...and making it emulate a Windows system...
...so 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
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
http://www.redhat.com/docs/manuals/linux/), 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
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
Guide. Although the printer configuration supports several different
ways of connecting to remote printers, Shadowman suggests that you use
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
At this point, you should be accessing files and printing remotely in
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
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
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!