Weekend Mechanic Issue 20

#### "Linux Gazette...making Linux just a little more fun!"

# Welcome to The Linux Weekend Mechanic!

## Published in the August, 1997 Edition of the Linux Gazette

Copyright © 1997 John M. Fisk <fiskjm@ctrvax.vanderbilt.edu>
The Linux Gazette (tm) is Copyright © 1997 Specialized Systems Consultants Inc.

Welcome to the August WM!
2 PC LAN: Adventures in Home Networking!
XEmacs Xtras!
Closing Up Shop...

Howdy! How y'all doing?

Thanks for droppin' in! The big news this month is that I finally got that old PC that bought a couple months ago up and running AND was able to get Ethernet set up between them. I've written about my experiences with TCP/IP, Ethernet setup, and Samba here in the hopes that they might either encourage or guide others in a similar endeavor. This is a whole lot of fun!

I've also been learning a bit about the venerable emacs editor. Actually, I've been learning on its worthy progeny, XEmacs 19.15. Along the way I've discovered that there's a wealth of elisp code out there to customize emacs in all sorts of ways. I've included some code snippets that I've recently culled from the comp.emacs and comp.emacs.xemacs groups.

Finally, in the "Closing Up Shop" section I've included some of the more useful UNIX-type resources that have been ported to the Windows NT/95 environment. I've come to the conclusion that there is no such thing as the "perfect OS", because there is always some feature, utility, or application that it lacks (sorry, even 'ol Linux can't do everything that I'd like it to do!). I've been having to use Windows NT 4.0 at work and have been sorely missing the tools that I've grown accustomed to under Linux. After a bit of 'Net searching I've put together a small collection of UNIX utilities and programs that have been ported to the Windows environment.

Anyway, my sincerest thanks and kudos to Marjorie and Amy at SSC who continue to do a great job of getting the Linux Gazette out each month. This is a lot of work and they are doing a fantastic job!

Hope y'all enjoy!

John

## 2 PC LAN: Adventures in Home Networking!

> ABSTRACT

> This is a brief recounting of my experiences setting up a small, 2 PC home LAN. The purpose was to to connect a computer running Linux kernel version 2.0.30 with another running Windows 95. Networking was accomplished via TCP/IP over Ethernet. Basic TCP/IP services (ping, telnet, SMTP) were setup. In addition, file, printer, and CD-ROM sharing was achieved using Samba v. 1.9.16p11.

> This is the story of an adventure...
> "A Horse And His Boy", by C.S. Lewis

CAVEAT: What follows is an account of my own experiences with setting up a small home LAN. I started out knowing a bit of networking theory, but had little practical experience with networking stuff. Along the way, I learned a bit and discovered a few things by trial and error. What I hope to do is encourage y'all to give this a try. It's definitely not as hard as it looks and it is SERIOUSLY COOL!

BUT...

This is NOT a HOWTO. There are numerous well written and informative sources of definitive information on setting up TCP/IP and Ethernet under Linux and Windows 95. The point of this is to share my own experiences. If you find something here that's helpful, that's great. Keep in mind, though, that you're on your own. Like all things with Linux, it's your responsibility to make sure you know what you're doing BEFORE you go messing with things. I've tried to ensure that the information here is as correct as possible, but I can't vouch for everything. Before you do anything to your system, make sure you know what you're doing! Like the old saying goes...

If it breaks, you get to keep both pieces...

Also, this is NOT intended for anyone who is setting up networking in a public or semi-public setting. What is described below is a small home setup: both boxes set on my desk in the office. I'm the only one that has physical access to them with the exception of my wife who does not use Linux at all and who uses Win95 only for email and a bit of word processing. Networking opens up potentially hazardous portals of entry into your system. I'll point out the few places where I've tried to include minor security measures. If you're setting up networking in a public or semi-public setting then this is definitely not what you need to be reading. There are plenty of good books on networking and security and you'd do well to peruse them if you're not completely sure of what you're doing.

The wise will heed this warning...

Anyway, now that I've got that off my chest... :-)

### How things got started...

One of the things that I've been wanting to do for some time now is learn a bit about networking. I'd taken a class in networking last Fall and had gotten quite a bit of theory, but precious little "hands on" experience. When I finally bought an old "as-is" PC a while ago I started entertaining hopes that I could somehow set up a small 2 PC LAN. The dream was born...

The reality of the situation, however, soon became quite evident. After a frustrating couple days of swapping out one board after another to isolate and replace the defective ones, I finally managed to get the 'ol PC to boot and installed a copy of WFW 3.11 on it. The old ISA I/O board was a serious dog and the ancient WD video card with 512K didn't help the situation any. But I was glad to see that it worked at least. I finally got tired of watching window redraws and, after finishing up school and starting work, did a major overhaul. My wife very kindly OK'd the investment after numerous assurances that the upgrade would be "her box" and that I'd make sure that it booted to Windows and that there'd be handy icons for the word processor and email stuff... my wife is a sweetheart! :-)

Anyway, the old box got transformed (thanks to a new MB, HD, EDO RAM, and a few other goodies) into a decent performer. When I bought it there was an Artisoft AE-2 NIC in it which I hoped was still working. When my brother-in-law gave me a WD 8003 NIC that he had lying around, I knew that I was on the verge of an adventure. After picking up the thin coax cable, T's, and terminators at Javanco's here in town, I was all set. The adventure was on...!

### Deja' News to the Rescue!

One of the first things I had to do was install the NIC cards, which turned out to be more of a chore than I had first anticipated. The cards, as it turned out, both worked fine. What was missing was documentation on all those funny little plastic jumpers that I'd need to set the IRQ and base I/O and such. In a stroke of good fortune I happened across one of those sites that belongs in EVERYONE's bookmark file:

Deja News <http://www.dejanews.com>

Deja News, for those who've not come across this place, provides a search engine for a database of Usenet postings. It's a fantastic source of information; granted, the signal to noise ration dips a bit now and then, but with some judicious searching you can find answers to all kinds of interesting problems. After searching for "Artisoft AE-2" and "WD 8003" I found myself in possession of several postings with complete descriptions of jumper settings that previous net pioneers had culled off of manufacturer's FTP sites and Web pages.

I was happy.

I initially set the cards up under Win95 since it was easy to find an unused IRQ and base IO offset. Once IRQ and IO conflicts had been settled for both boxes I decided to try Win95 -> Win95 peer-to-peer networking. This actually turned out to be the easiest part of the setup, owing in no small part to the fact that my "programmer/networking guru" brother-in-law came for the weekend. We managed to have one box talking to the other in no time.

I won't go into great detail as to how we did this: there are numerous excellent (and plenty of not-so-excellent...) references on setting up Win95 boxes. In brief, however, this is what we did:

1. Added TCP/IP support.

   If you right click on "Network Neighborhood" -> "Properties", a dialog box appears that should look something like this. Click on the Add -> Protocol -> Microsoft buttons to select TCP/IP. You'll likely need the setup disks or CDROM to install the drivers.

2. Configured TCP/IP settings

   Since there were just two boxes on the network all I set up was the IP address and netmask; all other default settings appeared to be correct. Since this wasn't a dial up connection I didn't define a DNS.

3. Defined Workgroup, Hostname, and Shares

   I found out the hard way that if you want to set up a workgroup to shared resources that everyone in the workgroup has to use the same workgroup name...

   Duh... :-)

   Anyway, I defined workgroup and hostnames after making sure that I had OK'd the "File and Print Sharing..." checkboxes from the main Network configuration dialog box. After doing this, I set up each share by right-clicking on the item (drive C, drive D, the CD-ROM, the printer, and so forth...), selecting the "Sharing..." menu item, and then configured share properties and passwords. Also, I selected the "Share Level Access Control" from the "Access Control" tab item.

4. Created a C:\Win95\hosts file

   This one would have completely stumped me had it not been for Bill, my brother-in-law. After we got all through with basic setup he had me set up a hosts file in C:\Win95 (being the non-conformist that I am this is where I put all the Windows stuff). Basically, this is just a file called "hosts" and is similar to the stock /etc/hosts file under Linux. At the moment, mine looks like:

       127.0.0.1       localhost
       192.168.1.1     Johnsbox
       192.168.1.2     Faithsbox
       192.168.1.3     Caduceus

At this point, I rebooted both boxes and was able to login and browse shares from either box. I doubt that this is the optimal setup; however, since everything seemed to work and I was able to browse through directories and share the printer, floppy drive, and CD-ROM, I figured I'd leave well enough alone. All in all, I was pretty pleased with this...

Seriously cool... :-)

So, at this point I knew that the NIC's and all the hardware were working and that I should be able to do something similar between Linux -> Win95. The real adventure was just beginning so it was...

### On to Linuxland...!

Setting up networking support under Linux was just a bit more work than under Win95 and while it wasn't excessively difficult I'll admit that I got bit more than once by a couple of gotcha's!. I'll try to mention these as I go. I also found a fair amount of helpful documentation along the way which I'll also try to give pointers to. In brief, I took the following steps to get networking up and going:

1. Compile new kernel and modules with networking support
2. Edited networking configuration files
3. Edited rc files to start appropriate networking services at bootup

One thing that I did that I'd encourage y'all to do: take lots of notes. There are all kinds of details that you need to attend to along the way and its easy to forget what you've done and what you haven't done. Also, things occasionally break along the way, it's nice to be able to "back out" of recent changes. Anyway, the first thing to do was...

### Building The New Kernel

Building a new kernel with the needed networking support was fairly straightforward, although there was one gotcha that I'll mention. The kernel options that I compiled in included Networking support, TCP/IP networking, Network device support, Ethernet support, and support for the Artisoft NIC. I also decided to compile as many of these options as modules as I could and use the kerneld to automatically load and unload them as needed. I also anticipated setting up Samba to fully realize Linux <-> Win95 networking, so I compiled these options in as well.

In summary, the kernel options I included were:

    Enable loadable module support (CONFIG_MODULES) [Y/n/?] Y
    Kernel daemon support (e.g. autoload of modules) (CONFIG_KERNELD) [Y/n/?] Y
    Networking support (CONFIG_NET) [Y/n/?] Y
    TCP/IP networking (CONFIG_INET) [Y/n/?] Y
    Network device support (CONFIG_NETDEVICES) [Y/n/?] Y
    Ethernet (10 or 100Mbit) (CONFIG_NET_ETHERNET) [Y/n/?] Y
    Other ISA cards (CONFIG_NET_ISA) [Y/n/?] Y
    NE2000/NE1000 support (CONFIG_NE2000) [M/n/y/?] M
    SMB filesystem support (to mount WfW shares etc..) (CONFIG_SMB_FS) [M/n/y/?] Y
    SMB Win95 bug work-around (CONFIG_SMB_WIN95) [Y/n/?] Y

After I did this, I updated /etc/lilo.conf, using an "append" line to pass it the base IO address and IRQ number for the network card. The global section of /etc/lilo.conf now looked like:

    # START LILO GLOBAL SECTION
    boot = /dev/fd0
    delay = 300
    vga = normal
    append = "ether=10,0x300,eth0"
    ...

An important README file that you'll want to have a look at is in the Documentation directory of the linux source (which is normally under /usr/src/linux/Documentation) in the networking subdirectory. It's the `net-modules.txt` file which describes how to use networking device driver modules. Specifically, it strongly recommends passing the network card base address and IRQ instead of auto-probing. Here's a short snippet from the file:

    In many cases it is highly preferred that insmod:ing is done
    ONLY with defining an explicit address for the card, AND BY
    NOT USING AUTO-PROBING!

    Now most cards have some explicitly defined base address, they
    are compiled with (to avoid auto-probing, among other things).
    If that compiled value does not match your actual configuration,
    do use  "io=0xXXX" -parameter for the  insmod, and give there
    a value matching your environment.

    If you are adventurous, you can ask the driver to autoprobe
    by using "io=0" parameter, however it is potentially dangerous
    thing to do in a live system.  (If you don't know where the
    card is located, you can try autoprobing, and after possible
    crash recovery, insmod with proper IO-address..)

The file had these additional comments about "NE2000" clone cards, like the one that I was using:

    	8390 based Network Modules		(Paul Gortmaker, Nov 12, 1995)
    	--------------------------

    (Includes: smc-ultra, ne, wd, 3c503, hp, hp-plus, e2100 and ac3200)

    The 8390 series of network drivers now support multiple card systems
    without reloading the same module multiple times (memory efficient!) This
    is done by specifying multiple comma separated values, such as:

    	insmod 3c503.o io=0x280,0x300,0x330,0x350  xcvr=0,1,0,1

    The above would have the one module controlling four 3c503 cards, with
    card 2 and 4 using external transceivers. The "insmod" manual
    describes the usage of comma separated value lists.

    It is *STRONGLY RECOMMENDED* that you supply "io=" instead
    of autoprobing.  If an "io=" argument is not supplied, then
    the ISA drivers will complain about autoprobing being not recommended,
    and begrudgingly autoprobe for a *SINGLE CARD ONLY* -- if you want to
    use multiple cards you *have* to supply an "io=0xNNN,0xQQQ,..."
    argument.

    The ne module is an exception to the above. A NE2000 is essentially an
    8390 chip, some bus glue and some RAM. Because of this, the ne probe is
    more invasive than the rest, and so at boot we make sure the ne probe is
    done last of all the 8390 cards (so that it won't trip over other 8390
    based cards) With modules we can't ensure that all other non-ne 8390
    cards have already been found. Because of this, the ne module REQUIRES
    an "io=0xNNN" argument passed in via insmod. It will refuse
    to autoprobe.

    It is also worth noting that auto-IRQ probably isn't as reliable during
    the flurry of interrupt activity on a running machine. Cards such as the
    ne2000 that can't get the IRQ setting from an EEPROM or configuration
    register are probably best supplied with an "irq=M" argument
    as well.

    [snip!...]

If you're planning on using modular device drivers I'd recommend having a look at this file as it contains additional helpful information.

The gotcha that I encountered occurred after successfully compiling and installing the new kernel. After I rebooted, there was no message indicating that it had found the network card. As I'm sure most of you know, you can review kernel boot messages using something like:

    	# dmesg | less

I went back and recompiled and installed yet another kernel, this time with everything compiled into the kernel and NOT as modules; this time, I got the following message:

    loading device 'eth0'...
    ne.c:v1.10 9/23/94 Donald Becker (becker@cesdis.gsfc.nasa.gov)
    NE*000 ethercard probe at 0x300: 00 00 6e 30 91 cf
    eth0: NE2000 found at 0x300, using IRQ 10.

I suspect that many of you have already guessed what I did wrong: I compiled the network device driver as a module but NEVER LOADED THE MODULE!

Duh!

The Slackware distribution includes an `rc.modules` file with the set of rc files. Among other things, this allows you to specify modules to load at boot up using `modprobe`. After uncommenting the line for the `ne.o` driver and specifying the base IO and IRQ values, it loaded without a hitch. Those of you using a Red Hat, or Red Hat derived system, will probably find a similar file under the /etc subdirectory. The invocation that I'm using is:

    # jmf -- this is for the Artisoft NE-2 which is jumpered to io=0x300, irq=10
    /sbin/modprobe ne io=0x300,irq=10

Anyway, that was a pretty minor gotcha, but I did manage to lose a bit of time messing around with repetitive kernel recompiles and such. Let me mention here that there are a couple helpful HOWTO's that you might be interested in looking over:

- Ethernet-HOWTO
- Kernel-HOWTO

The Ethernet-HOWTO contains a LOT of details with respect to setting up Ethernet support under Linux. Personally, I wished that the author had taken more of a step-by-step approach to doing this; still there's a good deal of very useful information here. The Kernel-HOWTO is a good reference to use if you're new to Linux or still don't feel comfortable yet with the notion of compiling and installing a new kernel. This is actually a pretty painless proposition now and with the advent of both an ncurses- (actually "dialog-based") and a tk-based configuration utility, kernel customization and compilation is definitely getting easier.

### Setting Up Networking Configuration Files

Once the kernel correctly recognized and initialize the network device, the next step was updating the necessary networking configuration files. There's an absolutely fantastic HOWTO file that goes through this process in an orderly and well-documented manner:

The NET-3 HOWTO

This is a must read document as it describes each of the files needed for networking configuration, gives working examples, and touches on various issues such as security. It is, however, as the author points out, not a networking security oriented document. If security is an issue then you'll probably want to read one of the several excellent reference works available through publishers such as O'Reilly & Assoc..

Since all of you can read, I'll not insult your intelligence by rehashing what is amply covered in this HOWTO. I would like to make a couple comments about certain files. To begin with, I'm using a Slackware 3.2 distribution, so the files on other distributions may be in different locations (or use a different filename) than the ones mentioned here. These are the files that I edited:

    /etc/rc.d/rc.inet1
    /etc/rc.d/rc.inet2
    /etc/hosts
    /etc/hosts.allow
    /etc/hosts.deny
    /etc/resolv.conf

Slackware uses `rc.inet1` to configure the network interfaces and update the kernel routing tables. I chose to assign the boxes IP addresses from the 192.168.xxx.xxx block. The NET-3 HOWTO covers the assignment of IP addresses in a private network (such as a home LAN like I was setting up). Basically, there are three blocks of addresses that are reserved for private networks (a Class A, Class B, and Class C block). If you're interested, `RFC-1597` describes this in detail.

And speaking of which, I should mention another very useful WWW resource that you should add to your bookmark file if you haven't already. Nexor Corporation has a web page that allows easy look up and retrieval of RFC documents. Their URL for this service is:

http://www.nexor.com/public/rfc/index/rfc.html

For the curious, my rc.inet1 now looks like:

    #! /bin/sh
    #
    # rc.inet1	This shell script boots up the base INET system.
    #
    # Version:	@(#)/etc/rc.d/rc.inet1	1.01	05/27/93

    HOSTNAME=$(cat /etc/HOSTNAME)

    # Attach the loopback device.
    /sbin/ifconfig lo 127.0.0.1
    /sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo

    # IF YOU HAVE AN ETHERNET CONNECTION, use these lines below to configure the
    # eth0 interface. If you're only using loopback or SLIP, don't include the
    # rest of the lines in this file.

    # IP addresses for TCP/IP Ethernet connection
    IPADDR="192.168.1.3"
    NETMASK="255.255.255.0"
    NETWORK="192.168.1.0"
    BROADCAST="192.168.1.255"
    GATEWAY="

    # Uncomment the line below to configure your Ethernet card.
    /sbin/ifconfig eth0 ${IPADDR} broadcast ${BROADCAST} netmask ${NETMASK}

    [...]

    # Set up IP routing table.
    /sbin/route add -net ${NETWORK} netmask ${NETMASK} eth0
    if [ -n $GATEWAY ]; then
    	/sbin/route add default gw ${GATEWAY} netmask 0.0.0.0 metric 1
    fi

    # End of rc.inet1

In addition, my /etc/hosts, /etc/hosts.allow, and /etc/hosts.deny files look like:

    #
    # hosts		This file describes a number of hostname-to-address
    #		mappings for the TCP/IP subsystem.  It is mostly
    #		used at boot time, when no name servers are running.
    #		On small systems, this file can be used instead of a
    #		"named" name server.  Just add the names, addresses
    #		and any aliases to this file...
    #
    # By the way, Arnt Gulbrandsen <agulbra@nvg.unit.no> says that 127.0.0.1
    # should NEVER be named with the name of the machine.  It causes problems
    # for some (stupid) programs, irc and reputedly talk. :^)
    #

    # For loopbacking.
    127.0.0.1	localhost

    192.168.1.1	Johnsbox.vanderbilt.edu		Johnsbox
    192.168.1.2	Faithsbox.vanderbilt.edu	Faithsbox
    192.168.1.3	Caduceus.vanderbilt.edu 	Caduceus

    # END /etc/hosts

    #
    # hosts.allow	This file describes the names of the hosts which are
    #		allowed to use the local INET services, as decided by
    #		the '/usr/sbin/tcpd' server.
    #
    # Version:	@(#)/etc/hosts.allow	1.00	05/28/93
    #
    # Author:	Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org>
    #
    #

    # allow all services ONLY to the local boxes
    ALL: 127.0.0.1
    ALL: 192.168.1.1
    ALL: 192.168.1.2
    ALL: 192.168.1.3

    # End of hosts.allow.

    #
    # hosts.deny	This file describes the names of the hosts which are
    #		*not* allowed to use the local INET services, as decided
    #		by the '/usr/sbin/tcpd' server.
    #
    # Version:	@(#)/etc/hosts.deny	1.00	05/28/93
    #
    # Author:	Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org>
    #
    #

    # deny all services to everyone unless specified in /etc/hosts.allow
    ALL: ALL

    # End of hosts.deny.

Finally, I updated /etc/resolv.conf to point to the DNS servers at Vanderbilt University and, secondarily, at MTSU:

    domain vanderbilt.edu
    nameserver 129.59.1.10
    nameserver 161.45.1.2

At this point, I rebooted both boxes and kept a watch out for boot up error messages...

So far, so good...

The seriously cool moment occurred when I was able to both ping and then telnet from my wife's Win95 box to Linux. Here's the screen shots of this glorious occasion ;-)

Pinging from Win95->Linux
Telnetting from Win95->Linux

You've probably noticed that I wasn't using the telnet client that comes with Win95. I've found several freeware sites recently and one of them had the venerable ewan 1.05 telnet client that I'd been using for the past couple years. This provides at least ANSI colors as you can see from screen dump of the XEmacs session I had running.

These alone were worth a bit of celebrating! Running console-based programs via telnet was surprisingly fast: there was little or no performance difference between the telnet session and running the programs natively under Linux. This was seriously cool!

I also found that I could ping from Linux->Win95 and that I could ping and telnet from Win95->Linux using both IP address and hostname!

I was a happy man :-)

Still, there was one final challenge left...

## The Big Kahuna: Setting Up Samba!

This is still, as the academe's would say, "a work in progress..."

(which is to say: "all the bugs ain't worked out yet...")

Still, I've got file and CD-ROM sharing working and am closing in on getting printer support working as well! At the moment, I can browse my Linux file system from under Win95, view and edit files, use the CD-ROM (and the floppy drive) as though they were local. This has been a serious pump! I've also discovered that I can do some other nifty things using TCP/IP, such as email, which I'll mention later. All in all, this has been huge! So, here are how things got started...

### Going to the Source...

The first thing I did, and if you're interested in setting up Samba what I'd suggest that you do first too, to head right on out to:

Official Samba Home Page

Samba was created by Andrew Tridgell, who has not only written a fantastic program, but has provided a wealth of information on Samba at the home page. This includes:

- update announcements
- manual pages
- FAQ's
- program documentation
- newsgroup digests
- source and binary distributions for a variety of platforms
- SMB client software
- security patches and information
- and so forth...

This is definitely Stop Number One.

Stop Number Two was the SMB-HOWTO which provided a good deal of useful information in compiling, installing, and configuring Samba. After messing around with this for the past couple weeks and starting to read the comp.protocols.smb newsgroup, I'm convinced that the biggest challenge to getting Samba up and doing what you want is getting the smb.conf configuration file correct. Hence, you'll probably want to spend a bit of time with the documentation.

The good news is, however, that getting basic file sharing up and working is pretty straightforward.

Anyway, the first thing I did was to get the current source, which as of July, 1997 was 1.9.16p11. Compiling and installing Samba was fairly easy. The first thing to do was edit the Makefile under samba-1.9.16p11/source and change the defaults to match my preferences. Specifically, the values I used were:

    BASEDIR = /usr/local/samba
    BINDIR = $(BASEDIR)/bin
    SBINDIR = $(BASEDIR)/bin
    LIBDIR = $(BASEDIR)/lib
    VARDIR = $(BASEDIR)/var

    FLAGS1 = -O -DSYSLOG

    SMBLOGFILE = $(VARDIR)/log.smb
    NMBLOGFILE = $(VARDIR)/log.nmb
    CONFIGFILE = $(LIBDIR)/smb.conf
    LMHOSTSFILE = $(LIBDIR)/lmhosts
    LOCKDIR = $(VARDIR)/locks

    WORKGROUP = FISK
    GUESTACCOUNT = guest

    FLAGSM = -DLINUX -DSHADOW_PWD
    LIBSM = -lshadow

Basically, I used the Samba default filesystem structure, which puts all the program and configuration files under /usr/local/samba. I added the `-DSYSLOG` flag since I'm basically nosy about what's going on and like to see log files to help diagnose problems. The log file and lock file locations, once again, are defaults. I made the default workgroup `FISK` which is what I used under Win95; I also made sure that I had a guest account and group to which login was barred. The reason for this is giving in the Makefile:

    # set this to the name of the default account, which is the one
    # to use when no username or password is specified.  This can be overridden
    # in the runtime configuration file (see smb.conf(5))
    # NOTE: The account "nobody" may not be a good one as
    # on many unixes it may not be able to print. Thus you
    # might have to create a separate guest account that can print.
    GUESTACCOUNT = guest

And finally, I compiled Samba with shadow password support. You'll find several configuration options for Linux with and without shadow passwords, quotas, and so forth so just pick whichever one is suitable and uncomment the appropriate lines. Hereafter, the compile and install were as simple as:

    	# make
    	# make install

At this point I should have mentioned that I was actually doing all this from two VT's (after logging in as root). From the first VT I was editing the Makefile and managing the compilation; from the other VT I had changed to the samba-1.9.16pll/docs/ subdirectory and was following the `INSTALL.txt` file directions. At the top of the file is the encouraging pronouncement `HOW TO INSTALL AND TEST SAMBA` and, in fact, the directions do a pretty good job of doing just that.

At this point, I'd done the first couple steps:

- STEP 0. Read the man pages
- STEP 1. Building the binaries
- STEP 2. The all important step...

If you're wondering what this "all important step" might be, here's Andrew in his own words:

> At this stage you must fetch yourself a coffee or other drink you find stimulating. Getting the rest of the install right can sometimes be tricky, so you will probably need it.

So, after grabbing a coke and a bag 'o nachos, I was ready to plunge ahead. I'd suggest you do the same...

The next step is to create the `smb.conf` file. Now, the good news is that it appears that it isn't too hard to get something working -- you should definitely see fruits of your labors! The bad news is that getting everything exactly right is quite a bit more challenging.

in the samba-1.9.16p11/examples/simple directory there's a well-commented sample smb.conf file that I used as a template when setting this up. As the documentation suggests, you'll probably want to be armed with this or an equivalent template and the `smb.conf` manual page, which goes into great detail with regard to each of the configuration options. Fortunately, the manual page is pretty well written although there is admittedly quite a bit of it... :-)

After making a few guesses about what I'd like to try I went back to the `INSTALL.txt` file and continued with the installation instructions. The next thing it suggests doing is testing the configuration file with the included `testparm` program. This is really handy as it will let you spot errors in the syntax of the configuration file. Here's a copy of my current smb.conf file:

    ; Configuration file for smbd.

    [global]
       workgroup = FISK
       Printing = bsd
       printcap name = /etc/printcap
       load printers = yes
       guest account = guest
       domain master = yes
       log file = /usr/local/samba/log.%m

    [homes]
       comment = Home Directories
       browseable = yes
       read only = no
       writable = yes
       create mode = 0744

    [printers]
       comment = All Printers
       browseable = no
       printable = yes
       public = no
       writable = no
       create mode = 0755
       path = /var/spool/public
       print command = echo Printing %s >> /tmp/smb_print.log; lpr -P %p %s

    [guest]
       comment = Toplevel Directory
       browseable = yes
       printable = no
       public = yes
       writable = no
       readonly = yes
       only guest = yes
       path = /

    [cdrom]
       comment = Mitsumi CD-ROM Drive
       browseable = yes
       writeable = no
       readonly = yes
       printable = no
       public = yes
       only guest = no
       path = /cdrom

    ; END smb.conf

When I run the `testparm` program on this file I get:

    Load smb config files from /usr/local/samba/lib/smb.conf
    Processing section "homes]"
    Processing section "printers]"
    Processing section "guest]"
    Processing section "cdrom]"
    Loaded services file OK.
    Press enter to see a dump of your service definitions

By hitting ENTER you get a LOT of detailed information about the current values of the configuration. Since this seemed to be OK I went ahead and started the smbd and nmbd daemons from the command line using:

    	# /usr/local/samba/bin/smbd -D -d1 -s/usr/local/samba/lib/smb.conf
    	# /usr/local/samba/bin/nmbd -D -d1 -s/usr/local/samba/lib/smb.conf \
    		-l/usr/local/samba/log

The `-D` option specifies that smbd and nmbd run as daemons; `-d1` sets the debug level; and `-s` and `-l` set the locations of the smb.conf and logging files respectively. After having a peek at `ps -x` to make sure that they had started OK, I ran the next test, which involves using the `smbclient` program to list the shares on the local server. Doing this I get:

    	# smbclient -L Caduceus

    Added interface ip=192.168.1.3 bcast=192.168.1.255 nmask=255.255.255.0
    Server time is Mon Jul 28 20:36:15 1997
    Timezone is UTC-5.0
    Domain=[FISK] OS=[Unix] Server=[Samba 1.9.16p11]

    Server=[caduceus] User=[fiskjm] Workgroup=[FISK] Domain=[FISK]

    	Sharename      Type      Comment
    	---------      ----      -------
    	ascii          Printer   ljet2p-letter-ascii-mono
    	cdrom          Disk      Mitsumi CD-ROM Drive
    	fiskjm         Disk      Home Directories
    	guest          Disk      Toplevel Directory
    	homes          Disk      Home Directories
    	IPC$           IPC       IPC Service (Samba 1.9.16p11)
    	lp2            Printer   ljet2p-letter-auto-mono
    	raw            Printer   ljet2p-letter-raw

    This machine has a browse list:

    	Server               Comment
    	---------            -------
    	CADUCEUS             Samba 1.9.16p11

    This machine has a workgroup list:

    	Workgroup            Master
    	---------            -------
    	FISK                 CADUCEUS

Again, there's a good deal of information (just keep telling yourself that this is the "Information Age" and there's supposed to be a lot of this around... :-). Anyway, I didn't spot any errors here and so tried to connect to the local server, again using `smbclient`:

    fiskjm@Caduceus [ttyp1] [docs] $ smbclient '\\Caduceus\fiskjm'

    Added interface ip=192.168.1.3 bcast=192.168.1.255 nmask=255.255.255.0
    Server time is Mon Jul 28 20:39:49 1997
    Timezone is UTC-5.0
    Password:
    Domain=[FISK] OS=[Unix] Server=[Samba 1.9.16p11]
    smb: \>

Excellent! So far, so good...

The last thing to do was head back to the Win95 box, and this is where the fun began...

Let me stress once again that all of the above steps are outlined in the `INSTALL.txt` file which really does a nice job of leading the uninitiated, like myself, through this potentially bewildering process. At this point, then, I was ready to try connecting from Win95.

The first thing I noticed was that when I clicked on the "Network Neighborhood" the Linux box did not immediately show up! So I did the next logical thing (logical, at least in my own mind, I guess...) I pinged Caduceus (my Linux box) from Win95 and, sure enough, it answered back. I then telnetted to it from Win95 and again, had no trouble! Now, when I clicked on "Network Neighborhood" Caduceus showed up!

I honestly haven't a good explanation of why this happens but I've found it to be the case from time to time: to get the SMB shares to "show up" I need to ping or telnet to the Linux box before trying to browse. Those of you who have more experience or insight might be able to offer an explanation...

Anyway, I was thrilled to see 'ol Caduceus show up. And just so that you don't think I was making this up, here's a screen dump of Network Neighborhood showing Caduceus. The next gotcha came when I clicked on the Caduceus icon: I got an error to the effect of "network not found..." which had me completely stymied.

### Diagnosing Those Network Blues...

Fortunately, in the samba-1.9.16p11/docs directory there's another helpful file called `DIAGNOSE.txt`which, as the name implies, is a useful checklist of things to run down when trying to pin-point the cause of a problem. As it turned out, the solution to the "network not found" error was adding the IP address of Caduceus to the WINS server configuration box in the Network options dialog box. Doing this and rebooting the Win95 box fixed the problem completely!

At this point, I was golden! I could now:

- See the Entire Network in Explorer
- See the Caduceus shares in Explorer
- Browse my /home/fiskjm directory
- Browse a CD that I had mounted under /cdrom

This was a serious pump! ;-)

I found that I could mount a CD under Linux and then browse the contents of that CD via Samba! I found that I could even install Win95 software via a CD mounted under Linux.

I was dancin'!! This rocks!

In addition to the above I also found that I could browse my entire Linux hierarchy as "guest". What was even MORE freaky was that I could mount my local Win95 partitions under Linux (to /dosC, for example) and then browse those files via Samba from the other networked Win95 box. This was getting better and better all the time... ;-)

I'm sure, having skimmed through most of the docs and reading a bit of the newsgroup digests, that there are all sorts of way too cool things that can be done with Samba...

This'll let you push the envelope, my friend...

...riding the Ragged Edge of Destruction and Howling in the Wind!

This is what makes Linux just rock!

Anyway, as I said before, this is still a work in progress. The one thing that I'm still working on is printing, both from Linux->Win95 and vice versa. I'm getting incrementally closer, but haven't quite gotten all the pieces together yet. Still, after a Dejanews search I'm armed with a host of old postings on the subject and have a plan of attack in figuring this out. One thing about Linux...

It hones your problem solving skills :-)

### So, Where to, Captain?

The next step in the Odyssey, after whipping printing into shape, is to set up modem sharing between the Linux box and Win95. Currently, I'm doing all my dialup networking (or realistically, the vast majority of it) under Linux. What I'm planning to have a go at next is IP masquerading that would allow the Win95 box to access the 'Net via the dialup line under Linux. I've already discovered that, using Eudora Lite for Windows 95/NT, an excellent, mature, and freely available SMTP/POP email client from the folks at Qualcomm Corporation, I can use the `in.pop3d` daemon to allow Eudora to pick up mail from the Linux box via POP3 and then send mail out using `sendmail` running under Linux! This is another Huge Blow For Freedom since it allows me to pick up mail under Linux, skim through the mail for stuff that's specifically mine, and then POP the rest to the Win95 box where my wife can read/reply to it. Outgoing mail is forwarded to sendmail under Linux where it's queued up and sent out the next time a connection is made.

It just gives me Willies!

So, I'm one Seriously Happy Linux Hombre Kinda Guy! I know that it's quite expensive setting up a single box, let alone two, but if you can find an old beater box somewhere: someone's upgrade "hand-me-down" or something like that, and a couple old NIC cards I'd really recommend this to you. You'll never be the same...

Trust me... :-)

### Resources Galore!

For those of you who've caught the bug, here are a few more resources that I came across in the nascent stages of The Quest. In addition to the HOWTO's and other documents already listed, have a look at:

J. Pollman's Mini-Home-Server document
  J. Pollman has written an excellent, concise guide to doing pretty much what I've just described above. In this case, he actually describes setting up three boxes: a Linux box, a Win95 box, and an old i386 box that he uses as a "server" for printer and modem sharing.

  He covers TCP/IP, Samba, and IP firewall setup to make all of this happen. I'd definitely have a look a this.

The Linux ipfwadm Home Page
  This excellent resource is brought to you by the kind folks at X/OS. The page has links to the most recent distribution of the ipfwadm package, update announcements, and a VERY comprehensive paper that details the installation, setup, and configuration of the ipfwadm package. If you're going to "do ipfwadm" then this is definitely a place to start.

The Linux IP Masquerade Resource Page
  This is yet another "must-bookmark" page that provides a tremendous amount of helpful information and documentation on configuring IP masquerading under Linux.

The Firewall and Proxy Server HOWTO
  Yet another good source of information on obtaining, compiling, installing, and configuring the ipfwadm package. This includes detailed descriptions of how to go about setting up both IP filtering firewalls and Proxy servers.

Olaf Kirch's classic "Linux Networking & Administrator's Guide"
  This is a foundational work that covers all aspects of networking under Linux. In its own words it is a "350-page book covering all major tasks of running Linux in a networked environment ranging from basic TCP/IP configuration to NFS, NIS, SLIP, PPP, inetd, etc."

the above list is far from comprehensive, although I trust that it at least provides a jumping off site for further exploration. I really can't stress how much fun this networking stuff has been. Being able to share resources between a Linux box and a Windows box has opened up all sorts of possibilities. My wife is actually talking about "her box" which is a major step forward in computer acceptance around the Fisk household after years of..., er... detente.

I'd also like to point out once again that this is a NETWORK NEWBIE's article: I'm way down low on that 'ol learning curve and have quite a ways to go before I can claim basic proficiency. Be warned once again that at least part of what I've mentioned here may well be wrong (the problem, of course, is that I don't know which part). Please don't hesitate to drop me a note and provide corrections or modifications.

Anyway, here's wishing y'all a VERY HAPPY LINUX'ing!

Best Wishes,

John M. Fisk
Nashville, TN
28 July, 1997

## XEmacs Xtras!

Since the end of the Spring semester, which can be loosely interpreted to mean, "since I had a bit more time...", I've been slowly learning my way around XEmacs. I've still not formed a solid opinion on it yet, but it's definitely growing on me. I love the speed of vi[m] and I still use this for all the day to day editing and such that needs to be done. But I've slowly grow quite attached to XEmacs and all the nifty things that this great editor is capable of doing.

And for those of you who are unfamiliar with it, XEmacs is...

Well, in their own words (from the XEmacs FAQ):

    What is XEmacs?
    ===============

       An alternative to GNU Emacs, originally based on an early alpha
    version of FSF's version 19, and has diverged quite a bit since then.
    XEmacs was known as Lucid Emacs through version 19.10.  Almost all
    features of GNU Emacs are supported in XEmacs The maintainers of XEmacs
    actively track changes to GNU Emacs while also working to add new
    features.

I guess, to my own conceits, XEmacs provides all of the power and sophistication of its worthy progenitor, GNU Emacs, with a goodly assortment of the amenities of a GUI. It seems to strike a nice balance between the "pretty, mouse-driven UI" and the speed of the keyboard. All in all, I'm having a great time messing around with this. Which reminds me, Dan Nicolaescu sent a very nice note pointing out something that I'd clearly missed:

> From done@ece.arizona.edu Tue Jul 22 22:09:23 1997
> Date: Sun, 29 Jun 1997 10:16:13 -0700
> From: Dan Nicolaescu <done@ece.arizona.edu>
> To: fiskjm@ctrvax.Vanderbilt.Edu
> Subject: article in Linux Gazette

> Hi!

> I have one comment about the screen captures of Emacs and XEmacs in your article in Linux Gazette at ../issue18/wkndmech.html

> To truly illustrate both emacsen syntax coloring capabilities you would better take a snapshot after you put in your .emacs (setq font-lock-maximum-decoration t) and restart [X]Emacs.

> Regards,
> Dan

Thanks Dan!

As the old academic saw goes, "this is left as an exercise for the reader". I appreciated his pointing this out.

This segues right into another point that I wanted to bring up: there is a HUGE amount of interesting and fun elisp code floating around out there that does all sorts of cool and groovy things.

Like what, you ask...?

Well, in issue 11 of the Linux Gazette, the prolific Larry Ayers had an article on adding a "kill ring menu" to the menu bar which allows you to select from a number of previously killed sections of text being held in the kill ring. I've added this to my ~/.emacs file and it works like a charm! Kudos to Larry!

Well guess what? If you hang around the `comp.emacs, comp.emacs.xemacs, or gnu.emacs.sources` newsgroups you'll find that code snippets like this are passed around all the time. To help entice you, here are two postings that I ran across a little while ago. The first, from David Hughes tells how to set up func-menu which provides a menu of the functions defined in the current buffer. This is similar to using etags or ctags for those of you who are familiar with these programs, but adds a clever bit of GUI:

    From: djh@videonetworks.com (David Hughes)
    Subject: Re: Is func-menu what I'm looking for?
    Newsgroups: comp.emacs.xemacs
    Sender: xemacs-request@xemacs.org
    Lines: 50
    Xref: news.vanderbilt.edu comp.emacs.xemacs:16055

    > Hi gurus,
    >
    > I remember, a while ago, I used to be have a menu that would
    > give me the name of the functions defined in the current buffer.
    > The menu would also allow me to point to one particular function.
    >
    > I'd like to be able to use that again, but I do not know
    > which package does it.
    > Is it func-menu?
    > If so, where can I find it? I have tried, but I could
    > not find it.

    Add the following (or something like it) to your .emacs

    ;;; func-menu is a package that scans your source file for function
    ;;; definitions and makes a menubar entry that lets you jump to any
    ;;; particular function definition by selecting it from the menu.  The
    ;;; following code turns this on for all of the recognized languages.
    ;;; Scanning the buffer takes some time, but not much.
    ;;;
    ;;; Send bug reports, enhancements etc to:
    ;;; David Hughes <d.hughes@videonetworks.com>
    ;;;
    (cond (running-xemacs
           (require 'func-menu)
           (define-key global-map 'f8 'function-menu)
           (add-hook 'find-file-hooks 'fume-add-menubar-entry)
           (define-key global-map "C-cl" 'fume-list-functions)
           (define-key global-map "C-cg" 'fume-prompt-function-goto)

           ;; The Hyperbole information manager package uses (shift button2) and
           ;; (shift button3) to provide context-sensitive mouse keys.  If you
           ;; use this next binding, it will conflict with Hyperbole's setup.
           ;; Choose another mouse key if you use Hyperbole.
           (define-key global-map '(shift button3) 'mouse-function-menu)

           ;; For descriptions of the following user-customizable variables,
           ;; type C-h v <variable>
           (setq fume-max-items 25
                 fume-fn-window-position 3
                 fume-auto-position-popup t
                 fume-display-in-modeline-p t
                 fume-menubar-menu-location "File"
                 fume-buffer-name "Function List*"
                 fume-no-prompt-on-valid-default nil)
           ))

    -- David Hughes

The second, by Tom Steger (who actually tips the hat to another fella...), tells how to do something that I really have gotten used to under vi[m], and that is hitting the percent "%" key when the cursor is positioned on top of a brace, bracket, parenthesis, etc. and have it move to the matching element. For those long-winded functions with lots of nesting this is a godsend when trying to untangle a mass of braces and brackets.

    Date: Mon, 23 Jun 1997 08:20:35 -0400
    From: steger@WILLEY.tautron.com (Tom Steger)
    Subject: Re: matching parenthesis
    Newsgroups: comp.emacs.xemacs

    > Hi,
    >
    > Is there a command in xemacs19.15 by which I can go to a matching
    >  parenthesis (like % in vi) ??
    >
    > I do have the parenthesis library working which highlights the
    > matching parenthesis but if the matching parenthesis is out
    > of the page how do I get to it without moving the cursor ??
    >
    > Thanks in advance,
    > Chetan

    I got the following from hall@grumpy.nl.nuwc.navy.mil in response to a similar
    question. I bound it to ALT %.

    (defun goto-matching-paren ()
           "Move cursor to matching paren."
                (interactive)
                (let* ((oldpos (point)) (blinkpos))
                  (condition-case ()
                    (setq blinkpos (scan-sexps oldpos 1))
                    (error nil))

                (if blinkpos
                  (setq blinkpos (1- blinkpos))
                  (condition-case ()
                    (setq blinkpos (scan-sexps (1+ oldpos) -1))
                    (error nil)))

                (setq mismatch
                    (/= (char-after oldpos)
                    (logand (lsh (aref (syntax-table)
                                           (char-after blinkpos))
                                      -8) 255)))

              (if mismatch
                  (progn
                    (setq blinkpos nil)
                    (message "Mismatched parentheses"
                   (if blinkpos
                    (goto-char blinkpos)))))

    (global-set-key "M-%" 'goto-matching-paren)

I know that trying to cut and paste from HTML isn't always the easiest so if you're interested in trying these things out I've taken the liberty of cat'ing these into a plain ASCII file. You can either save the following link to a file or else display it and then save it as a plain text file:

XEmacs Customization Code

Anyway, I've had a huge amount of fun playing with this, hope you do too.

Enjoy!

John M. Fisk
Nashville, TN
29 July, 1997

Say, thanks again for stopping in!

Thought I'd finish up with a quick list of UNIX resources for Win95/NT users. When I started work this summer they upgraded the workstation that I'd been using to a Pentium-based system running Windows NT version 4.0. This was the first time that I'd used NT and, although it's quite similar to Windows 95, found that it took a bit of getting used to.

One of the things that I really missed were the editors and file processing tools that I'd been using under Linux at home and at school. I soon discovered that there's quite a wealth of UNIX type tools that have been ported to the Win95/NT environment. I was quite impressed at what is currently available: vi, emacs, perl, tcl/tk, gcc, gs, ksh, bash, and so forth. Not all programs work as well in the Windows environment and often there are missing features. Still, overall I've been pretty pleased at what's out there.

So here's a short listing of some of the resources "out there..."

VI Improved (VIM) version 4.6
  This tops the list as one of favorite applications of all times: Bram Moolenaar's <mool@oce.nl> VIM editor. This is version 4.6 of this great program. You'll find information on documentation, version announcements, ports, binary distributions, and so forth here. You'll also find information on the (currently alpha) 5.0 version that adds color syntax highlighting in addition to all the other goodies! Run, don't walk, to get this one!

GNU Emacs version 19.34 for Windows NT/95
  As I gain experience with emacs this is quickly becoming my second most used app. This is a terrific port of GNU Emacs version 19.34 for the Windows NT/95 environment. Be forewarned, as with most things emacsen, it's HUGE!

  If you want, you can head right on out to the GNU Emacs for Windows NT/95 FTP site

GNU-Win32 Project at Cygnus Solutions
  Kudos to the folks at Cygnus!!

  These guys have provided a high quality, 32 bit, GNU-based development environment with an impressive number of utilities as well as the bash shell. I've been using these tools for the past couple months now and they are truly a godsend. If memory serves me correctly you'll find both development archives as well as an archive with basic file and disk utilities (grep, awk, sed, cat, rm, ls, and so forth). This is a definite bookmark site.

UWin (Unix to Windows) Tools from AT&T
  In addition to the tools and utilities from Cygnus, you can also find a full featured development environment complete with 160+ utilities at the UWin Project. Development tools include cc, yacc, lex, make, ksh, and much more.

  This is under the leadership of David Korn (of the Korn Shell fame...) who describes UWin as "a package [which] provides a mechanism for building and running UNIX applications on Windows NT and Windows 95..."

  Comparison shoppers will want to have a look at what's available here as well and make their own decisions.

DJGPP Development Suite
  Here's yet another excellent C/C++ development environment that is quite mature and full featured. DJGPP is now up to version 2.x and brings the native 32 bit GCC development tools to 16 or 32 bit DOS or Windows platforms. I've been using this for writing quick C++ programs that I need at work and have been VERY pleased with it.

  You'll find a host of tools and utilities including brand new DJGPP binaries from the Pentium Compiler Group! This is another must visit site.

HIP Communications' Win32 Perl
  For all you perl fans out there, here's a high quality port of Perl 5 which was commissioned for Windows NT by the folks from Redmond. I'm no perl jockey yet (it's on my short list of things to learn... :-) but I picked up the binaries for that rainy afternoon when I've got time to pick up another language...

  If you "do perl" then this is your site!

Unix to NT Resources from the New England NT User's Group
  This is an excellent compendium of annotated links to Unix to Windows NT resources (many of which are also applicable to the Windows 95 platform). If you bookmark only one page from your list, this should be it!

Windows NT Tools (again, from the N.E. NT User's Group)
  To help you get here quickly I've added this link: it's a nice list of tools and utilities for the Windows NT platform, many of which are UNIX based.

GNU tools for WinNT at the U. of Texas FTP site
  Here's another place to poke around for that GNU app you've been looking for. Unfortunately, this link will just dump you into an FTP directory, you'll need to have a look at the index.txt file to see what goodies are there.

Alladin Ghostscript v. 5.02
  The venerable ghostscript program from the kind folks at Alladin is available here at the U. of Wisconsin site. You'll find links to all sorts of information, binaries, sources, and other stuff.

Well, I'm running out of time here, but hopefully this will get you going. With a bit of poking around you'll easily find ports of several other excellent programs including:

- Samba
- Kermit
- Tcl/Tk
- Jed
- and so forth...

A Yahoo search will often get you going on the right track. Also, a couple of the pages above have a very nice set of links to help you on your search for Good Tools.

Anyway, thanks again for stopping by! Take care.

Best Wishes,

John M. Fisk
Nashville, TN
29 July, 1997

Got any comments, suggestions, criticisms or ideas?
Feel free to drop me a note at:

##### Copyright © 1997, John M. Fisk
Published in Issue 20 of the Linux Gazette, August 1997