Linux for Windows Administrators (Mark Minasi Windows Administrator Library)

60 Pages·2002·0.24 MB·English

by  Maureen Forys

SYBEX Sample Chapter
®
Linux for Windows
Administrators (Mark Minasi
Windows Administrator Library)
Mark Minasi; Dan York
Chapter 9: Linux/Microsoft OS Interoperability
Copyright © 2002 SYBEX Inc., 1151 Marina Village Parkway, Alameda, CA 94501. World rights reserved. No part of this
publication may be stored in a retrieval system, transmitted, or reproduced in any way, including but not limited to
photocopy, photograph, magnetic or other record, without the prior agreement and written permission of the publisher.
ISBN: 0-7821-4119-6
SYBEX and the SYBEX logo are either registered trademarks or trademarks of SYBEX Inc. in the USA and other
countries.
TRADEMARKS: Sybex has attempted throughout this book to distinguish proprietary trademarks from descriptive terms
by following the capitalization style used by the manufacturer. Copyrights and trademarks of all products and services
listed or described herein are property of their respective owners and companies. All rules and laws pertaining to said
copyrights and trademarks are inferred.
This document may contain images, text, trademarks, logos, and/or other material owned by third parties. All rights
reserved. Such material may not be copied, distributed, transmitted, or stored without the express, prior, written consent
of the owner.
The author and publisher have made their best efforts to prepare this book, and the content is based upon final release
software whenever possible. Portions of the manuscript may be based upon pre-release versions supplied by software
manufacturers. The author and the publisher make no representation or warranties of any kind with regard to the
completeness or accuracy of the contents herein and accept no liability of any kind including but not limited to
performance, merchantability, fitness for any particular purpose, or any losses or damages of any kind caused or alleged
to be caused directly or indirectly from this book.
Sybex Inc.
1151 Marina Village Parkway
Alameda, CA 94501
U.S.A.
Phone: [phone]
www.sybex.com
9
Linux/Microsoft OS
Interoperability
P
erhaps, after reading this book, you decide to incorporate a Linux box or
two into your existing Microsoft network. How hard would it be to make the Microsoft
NT, Windows 9x, 2000, and XP systems interoperate with the Linux computers? In
particular:
(cid:1) Can the Linux and Microsoft computers share data?
(cid:1) Can the Linux and Microsoft computers share programs?
(cid:1) Are there network services that will allow Linux and Microsoft systems to work
smoothly together?
It’s surprising how often the answers to those questions are “Yes.”
Microsoft and Linux computers both offer file sharing services. While there is no single pre-
ferred file server tool for Linux, I’d guess that Sun’s Network File System is the closest thing
to that, as NFS is the most commonly used file server in the Unix world. But Microsoft com-
puters can’t read or write NFS servers unless those Microsoft computers are equipped with
NFS client software—and they aren’t, by default. But we can work data sharing the other
way, from a Microsoft-centric approach. Linux has a set of tools called Samba that let a
Linux box exploit a Microsoft file server, and that let a Linux box appear to be a Microsoft
file server. Once installed and configured, the Samba tools make moving data between
414 Chapter 9 Linux/Microsoft OS Interoperability
Microsoft and Linux boxes as simple as moving data between NT machines. You’ll read
about Samba in this chapter. (Samba is so popular in the Linux world, in fact, that it might
be a more popular file server than NFS amongst the Penguinites, largely due to the fact that
many Linux-using networks also have Windows boxes on them, and NFS clients for Win-
dows cost money, where Samba clients for Linux are free.)
NT and 2000 can actually employ some Linux applications, to a limited extent. Both NT
and 2000 include a POSIX subsystem that will run a subset of standard Unix programs. (XP
does not have the POSIX subsystem, unfortunately, although Microsoft will sell it to you
as Services for Unix 3.0. Not cheap.) The Resource Kits for NT and 2000 include a POSIX-
compliant C compiler, so with the Resource Kit installed, you should be able to download,
compile, and use some Linux programs. Don’t get your hopes up—most stuff won’t work—
but some tools will work fine under NT and 2000, like grep for example. NT, Windows 9x,
and 2000 can also “use” Linux applications in another sense, in that you can run the built-
in Microsoft Telnet clients to run text-based programs on a Linux box remotely from any
network-capable Microsoft OS. Additionally, as you’ve already seen in Chapter 7, the X
Window emulators available for Windows let you run graphical Linux programs remotely.
Linux can run some Windows programs with a tool called Wine, which you’ll read about
in this chapter. It’s still an early project, but it’s a promising (and, of course, free) avenue
for running your favorite Windows programs on a Linux computer. And if you have older
DOS programs, there is a more mature Linux tool called dosemu (“DOS emulator”) that
lets your Linux computer directly run DOS programs. It’s extremely complex to get
working and, given that DOS programs are pretty sparse these days, I didn’t cover it in
this chapter in any detail. But if you’re interested, you can find source code, RPMs, and
documentation at www.dosemu.org.
Finally, Microsoft and Linux machines can interoperate very nicely when using standard
protocols: Linux boxes can happily work as clients to Microsoft web, FTP, Telnet, e-mail,
DHCP, DNS, or (with Samba) WINS servers. Similarly, Microsoft systems can work as
effective clients with Linux servers in those same roles.
In the rest of this chapter, I’ll look in more detail at the two interoperability tools that I’ve
not covered yet: Wine and Samba. But first, two quick Microsoft-to-Linux tips…
Converting Microsoft Text Files
to Linux Text Files
You may have tried, at some point, to cook up a Linux .conf file of some kind with some
version of the Windows Notepad. Presumably text is text no matter what OS you’re
using, right? So all you should have to do is to create the file in Notepad, copy it to a
Controlling Dual Boots: LILO 415
floppy, stick the floppy into the floppy drive on a Linux box, and then copy the file from
the floppy to /etc or wherever the .conf file is supposed to go.
As you know if you’ve tried it, it doesn’t always work. You see, in the Microsoft world,
text files end each line with a hexadecimal 0x0D or “carriage return,” followed by a
hexadecimal 0x0A or “line feed.” In Linux however, each line ends simply with 0x0A, a
line feed. Some Linux programs see Microsoft text files and can’t figure out why there’s
that spurious 0x0D at the end of each line, so they disregard the whole line. Other Linux
programs show you the text, but show a “^M” at the end of every line. Not a big deal,
but just visually annoying. To get around this issue, you can use a great little Linux tool
named dos2unix to take a DOS text file and create a Linux text file with the carriage
returns stripped out:
dos2unix -n dosfile linuxfile
For example, if I’ve worked up the XF86Config file to end all such files in Notepad, I’ll
save it to a floppy as XF86Config.txt. I get it onto a Linux system and then make it
Linux-ready with this command:
dos2unix -n XF86Config.txt XF86Config
Or the mcopy program in mtools has a cool -t option to “translate” between Linux text
format and DOS text format:
mcopy -t a: /myfiles
Controlling Dual Boots: LILO
The idea of interoperability includes being able to use a particular computer either as an
NT, Windows, 2000, or Linux workstation as needed. As you’ve seen, Linux will set itself
up to coexist with other operating systems using a tool called LILO, the LInux LOader.
Once your distribution’s setup program has gotten Linux on your system successfully,
here’s how to control what LILO does.
A Typical lilo.conf
LILO is controlled by an ASCII configuration file called lilo.conf, which is (as far as I
can see) always located in /etc. (You saw this back in Chapter 5, when we talked about
reconfiguring the kernel.) A typical lilo.conf follows.
prompt
timeout=50
default=linux
416 Chapter 9 Linux/Microsoft OS Interoperability
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
message=/boot/message
linear
image=/boot/vmlinuz-2.4.18-3
label=linux
initrd=/boot/initrd-2.4.18-3.img
read-only
root=/dev/hda3
append="hdc=ide-scsi"
other=/dev/hda1
optional
label=DOS
Notice that lilo.conf is broken into several sections. The first part is the “global”
portion, although it’s not set off with a header like [global] or anything like that. The
last two sections are called image sections. An image section either starts with image=,
which means it’s describing a Linux kernel, or other=, which means it’s pointing to some
other bootable item, most likely DOS, Windows, NT, 2000, XP, or some other operating
system. This lilo.conf has two image sections. The first boots a file named /boot/
vmlinuz-2.4.18-3, which is of course Red Hat 7.3’s kernel; the second boots a copy of
DOS (Windows 98 without the GUI, actually). The line label= obviously gives the image
a name; LILO uses that to let you choose which image to load.
When LILO boots, it shows a low-resolution graphic image of the Red Hat logo and
offers the two labels. You can alternatively press Ctrl+X to get the text LILO startup
screen, where you see boot:, and either press Enter for the default or press Tab to see your
boot options.
The image= or other= statement tells LILO exactly what to load. For example, in this
lilo.conf file, I have a line that says image=/boot/vmlinuz-2.4.18-3. If I choose that
image (the one labeled simply linux), then LILO goes to the /boot directory and looks
for a file named vmlinuz-2.4.18-3 to load. That file is the basic kernel program.
Controlling Dual Boots: LILO 417
In the case of a non-Linux image, the other= points to a partition, like /dev/hda1 (recall
that hda1 is the first partition—that’s the “1”—of the first EIDE drive—that’s the “a.”).
So when you choose the option labeled windows, then LILO just goes and gets the first sec-
tor of that partition, and then executes it. If you had yet another non-Linux image, you’d
really just need to add another other= line and give it a label.
Suppose you want to put Windows 95, 2000, and Linux on the same computer. How
would you do it? Your best strategy would be to first make the Microsoft operating sys-
tems work together, then add Linux. As Windows 95 doesn’t know anything about Win-
dows 2000, first put 95 on the computer, then install 2000. In the process, 2000 would
install NT’s operating system chooser, and as a result, when you turn your computer on,
you’d get a boot menu from 2000 offering to either run 95 or 2000. Then install Linux,
and the Linux setup routine will put LILO on your system. LILO will respect the 2000
boot information, which in turn will protect the 95 boot information. When you start
Linux, LILO gives you two options, linux or other. To run Windows 95, choose other,
which starts up the 2000 boot process, and that displays the operating system chooser.
Then you can choose Windows 95.
Is there a way to first install Linux on the computer, and then Windows, NT, and/or
2000, and get everything to boot nicely? I don’t know of such a way. The Windows, NT,
or 2000 setup programs will blow away the old LILO, so editing lilo.conf at that point
isn’t very valid. You could, however, create a Linux boot diskette when the setup pro-
gram offers; then you can always get to your Linux image by booting from that floppy.
Choosing a Default Image
You may have several images on your system—say, perhaps, a Linux image and a copy
of 2000—and LILO will usually start one or the other after some period of time, even if
you don’t press any keys. (I’ll tell you how to configure that in a moment.) But which
image does it load? It depends.
lilo.conf contains a line default=. You can just name an image with this command,
and after LILO times out, it’ll load that image. For example, my sample lilo.conf has
a line default=linux, which is the image that this Red Hat system will load if I just turn
the computer on and wait.
Controlling Timeouts
You control what LILO does in the absence of a keystroke with the prompt and timeout=
values. Just specify a timeout value as a number in tenths of seconds; for example,
timeout=50 tells LILO to wait five seconds before loading the default image.
418 Chapter 9 Linux/Microsoft OS Interoperability
The prompt command tells LILO not to load an image unless it gets some kind of key-
stroke. Press Enter and the default loads immediately; press Tab and LILO will show you
the image names; type in an image name and press Enter and LILO will load that one. But
timeout= beats prompt; if you have a prompt command and a timeout command (as is
usually the case), then once the timeout period has elapsed, LILO starts anyway. Using
prompt all by itself without a timeout guarantees that LILO just sits and waits forever for
your command. With no prompt command at all, LILO starts loading the default image—
probably the best option on a server with just one image, unless you want the boot:
prompt to let you type in a VGA mode setting or the like.
Offering Boot Messages
The global section includes a message= command. It points to a simple ASCII text file that
offers an informative boot message. It’s an optional command but might be helpful if
you’ve included a sort of simple “emergency boot kernel” as a boot option; you can use
message= to essentially document your images.
Making lilo.conf Changes Take Effect
LILO doesn’t read lilo.conf every time it boots. Instead, it loads and executes a boot
image file, typically a binary file named /boot/boot.b. But you needn’t worry about that,
as LILO creates boot.b every time you modify lilo.conf—as long as you remember to tell
LILO about it.
When you make a change to lilo.conf, save it; when you’re back at the command
prompt, type:
lilo
and you’ll see LILO rebuilding the boot image.
Run Your Windows Programs with Wine
Linux has many fine features (as I hope I’ve convinced you by now), but a wide availability
of polished, commercial-quality applications isn’t one of them. Suppose you have a Win-
dows program that does a particular job for you, a program that you know and love, but
that lacks a Linux version—what then? Wine to the rescue—as long as you don’t mind run-
ning some pretty early-release, pre-beta-stage software. Wine is an emulator for the Win32
programming subsystem, the foundation of Windows 9x, NT, and 2000 applications. One
day it’ll run just about anything, but right now you’ll find that more complex applications
probably won’t run. Nevertheless, it’s worth a try, given the following note.
Run Your Windows Programs with Wine 419
NOTE Wine may run, provided that you have a copy of Windows 98 or Me on
your system; Wine will not run with any kind of reliability on a system installed on
an NTFS directory, nor will it run very well in tandem with Windows 2000 or Win-
dows XP. That will probably change in time, but for now your best bet is to start
from a computer that has Windows 95, 98, or Me on it and load Linux alongside
that Windows 9x/Me install.
Red Hat 7.3 ships with Wine’s version 20020327, so if you installed “with everything,”
then you’ve already got it on your system. That said, given how young Wine is (I am
steadfastly avoiding “vintage” puns, but it’s a struggle), you might seriously consider get-
ting a newer copy before embarking on a serious Wine project. You can find Wine and
links to its download sites at www.winehq.org. At that site, you’ll find:
(cid:1) Links to places where people store the source code and where many have prebuilt
RPM files for the latest Wine build
(cid:1) Wine documentation
(cid:1) A database of Windows applications, listing how well (or badly) more than 2,000
Windows applications have run on Wine
NOTE Unfortunately there’s a bit of bad news with Wine: it’s actually much
harder to get to work, and it will refuse to work altogether in far more cases than
it did back in 2000. My guess is that Corel, who was very committed to making
Windows apps work on their Linux, took control of a big part of Wine. That would
have been a really good thing, except Corel bailed out of Linux in 2001 for various
reasons, money being the biggest. I suspect that they left a lot of things half-done,
putting the Wine volunteers in a tough spot. I’d recommend holding off on Wine
until early 2003—hit their website and see what they’ve got now. That’s not to say
that you can’t make Wine work, but your chances of succeeding are unfortunately
lower than they would have been in 2000.
Getting Your System Ready for Wine
Wine runs best on a system that includes both Windows and Linux on the same com-
puter, because a system like that already has some Windows applications loaded and
ready to try out.
Wine will work better if it has read/write access to your Windows drivers, suggesting that
systems on NTFS won’t work well—recall that the NTFS filesystem mounter is read-only.
420 Chapter 9 Linux/Microsoft OS Interoperability
Examine Wine’s config file
You configure Wine through its configuration file config.
Unlike other Linux programs you’ve met, Wine doesn’t have a single configuration file in
/etc; it did once, but now it creates a separate configuration file for every user. It puts
that in a hidden directory that it creates in the user’s home directory called .wine; the file
is called config. So, as I’m logged in as root, Wine creates a file named /root/.wine/
config. If Jane were logged in as jane and ran Wine, then Wine would create its config-
uration file for Jane in /home/jane/.wine/config.
Wine creates the config file the first time that a user runs Wine. You can announce your
presence, so to speak, to Wine by asking for its version with the –v option:
# wine –v
Wine version 20020310
I ran this on a computer running Windows 98 on /dev/hda1 formatted as FAT32. Now
I have a file in /root/.wine/config. It’s an ASCII text file that looks like a Windows INI
file. The first few lines look like this:
[Drive C]
"Path" = "/usr/share/wine-c"
"Type" = "hd"
"Label" = "MS-DOS"
"Filesystem" = "win95"
[Drive D]
"Path" = "/mnt/cdrom"
"Type" = "cdrom"
"Label" = "CD-Rom"
"Filesystem" = "win95"
"Device" = "/dev/cdrom"
This maps out the available drives in a style that Windows programs understand—C, D,
etc. Each lettered drive has a section named [Drive letter], followed by some descrip-
tive information about that drive.
Notice that it’s mapped the C drive as /usr/share/wine-c. I didn’t do that… Wine did.
If I do a “mount,” then I’ll see that /dev/hda1—C in Windows—is indeed mapped to
/usr/share-wine-c.
Run Your Windows Programs with Wine 421
The Path= statement is self-explanatory: it points to the Linux path corresponding to the
drive. So defining C for Wine is a two-step procedure: First, mount the device on a direc-
tory that serves as a mount point, then tell Wine about it via the Path= statement in a sec-
tion of wine.conf. The Type= tells Wine how the drive should look to Windows. Legal
values are floppy, hd, cdrom, and network. Understand that these labels have nothing to
do with the actual storage devices; instead, this describes how Windows will see it. So, for
example, I could replace hd with network and Windows would still see the device as drive
C, but Windows would think that my underlying network software was providing this
drive, instead of it being a partition of a locally attached physical hard disk. (It might be
useful for troubleshooting an application’s behavior when working with a mapped drive
versus a partition on a local physical hard disk.) The cdrom value is also self-explanatory.
The Filesystem= piece takes one of two values: win95 and msdos. win95 work for FAT32
or EXT2 drives; msdos is for older FAT16 drives.
If I look a bit further down, I see a section labeled [wine], containing these lines:
[wine]
"Windows" = "c:\\windows"
"System" = "c:\\windows\\system"
"Temp" = "e:\\"
"Path" = "c:\\windows;c:\\windows\\system;e:\\;e:\\test;f:\\"
"Profile" = "c:\\windows\\Profiles\\Administrator"
"GraphicsDriver" = "x11drv"
"ShellLinker" = "wineshelllink"
Let me take a minute and explain why the lines look so odd.
In Linux-ese, you use a backslash to warn Linux that you’re about to use a “strange”
character. For example, if you had a Linux directory with the name “My Pictures,” then
doing something like:
cd My Pictures
wouldn’t work; cd would think that you’d passed it the parameter “My” because Linux,
like Windows, sees spaces as separators. cd My Pictures looks like “Run the command
cd and feed it two parameters, My and Pictures,” instead of what you want, which is to
run the program cd and feed it one parameter, My Pictures. One way to tell a Linux com-
mand line that you’re feeding it a parameter with a space in it is to prefix the space with
a backslash, as in:
cd My\ Pictures