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
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... :-)
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...!
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:
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.
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.
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.
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...
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:
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 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:
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.
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:
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...
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...
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:
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:
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 = guestAnd 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:
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.
Fortunately, in the samba-1.9.16p11/docs directory there's another helpful file called DIAGNOSE.txtwhich, 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:
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 :-)
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... :-)
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:
He covers TCP/IP, Samba, and IP firewall setup to make all of this happen. I'd definitely have a look a this.
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
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:
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..."
If you want, you can head right on out to the GNU Emacs for Windows NT/95 FTP site
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.
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.
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.
If you "do perl" then this is your site!
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:
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:
Weekend Mechanic #1, November 1996
Weekend Mechanic #2, December 1996
Weekend Mechanic #3, February 1997
Weekend Mechanic #4, April 1997
Weekend Mechanic #5, June 1997