|
|
|
|
|
|
|
|
Linux Journal mentioned to Andrew Tridgell that we wanted to interview him about his work with Samba, and he responded with this enlightening and entertaining account of the development of the Samba package, answering all the questions we had intended to ask before we could ask him.
by Andrew Tridgell
The need to get the mainstream PC operating systems to talk amicably with Unix has been around for a long time. Recently, yet another option has emerged which takes a different tack from previous methods. I'm talking about SMB for Unix.
The dominant file-sharing protocol in the Unix world is NFS. The dominant protocols in the DOS/Windows/NT worlds are Novell and SMB. SMB is also known as LanManager, although LanManager is really only one implementation among many.
If you want Unix to talk to DOS, so that they can share file and print resources, then there are basically two choices. The first is to make the PC look like a Unix box by getting it to talk NFS. The second is to make the Unix box talk one of the PC networking protocols.
The best choice for getting NFS on a PC is to run a PC Unix such as Linux. This, however, is not a realistic option just yet for many PC users. The alternative is to run an NFS client on the PC. The problem with this approach is that the NFS protocol was never designed with PCs in mind. The security, administration, and general utility of PC-based NFS clients is far from ideal.
Just realising that providing NFS service from a Unix box to a PC allows the PC to handle the authentication should make any sane system administrator "go off his lunch". The NFS protocol requires that the Unix box trust the PC completely. In some implementations this is hidden behind the appearance of a "login" procedure and password protection. Don't let it fool you. As I have demonstrated on several occasions, any half-wit with access to the PC's console can fool the Unix box into giving write access to just about anyone's files, without the need for any passwords.
If that isn't enough, just try to administer a large bunch of PCs running NFS clients. Nightmare!
So what about the other approach? Can you make a Unix box talk one of the PC networking protocols? The short answer is yes. Products have been around for some time for some Unix flavours to talk to PCs on their own terms. The problem is that software vendors realise that this is a very useful thing to be able to do, and charge accordingly. There must be a better way.
There is a better way. Samba is a free implementation of the SMB protocol for Unix. The SMB protocol is the native file- and printer-sharing protocol for Windows for Workgroups, LanManager, Windows NT and OS/2. The SMB protocol is an X/Open standard and is in use on millions of PCs worldwide.
Before I tell you all about the current version of Samba and what it can do for you, I'm going to indulge in a little history. There is probably a similar history behind many other free software packages. They all start somewhere.
The whole thing really started in December 1991. I was (and still am) a PhD student in the Computer Sciences Laboratory at the Australian National University, in Canberra, Australia. We had just acquired a beta copy of the PC X server eXcursion from Digital, and I was testing it on my PC. At this stage I was an MS-DOS user, dabbling in windows.
eXcursion ran (at the time) only with Dec's "Pathworks" network for DOS. I had until then been using PC-NFS to connect to our local Sun workstations, and was reasonably happy with it. In order to run Pathworks, I had to stop using PC-NFS and try using Pathworks to mount disk space. Unfortunately, Pathworks was only available for Digital workstations running VMS or Ultrix, so I couldn't mount disk space from the Suns anymore.
I had access to a DecStation 3100 running Ultrix that I used to administer, and I got the crazy notion that the protocol that Pathworks used to talk to Ultrix couldn't be that hard, and maybe I could work it out. I had never written a network program before, and certainly didn't know what a socket was.
In a few days, after looking at some example code for sockets, I discovered it was pretty easy to write a program to "spy" on the file sharing protocol. I wrote and installed this program (the sockspy.c program supplied with Samba) and captured everything that the Pathworks client said to the Pathworks server.
I then tried writing short C programs (using Turbo C under DOS) to do simple file operations on the network drive (open, read, cd, etc.) and looked at the packets that the server and client exchanged. From this I worked out what some of the bytes in the packets meant, and started to write my own program to do the same thing on a Sun.
After a day or so more I had my first successes and actually managed to get a connection and read a file. From there it was all downhill, and a week later I was happily (if a little unreliably) mounting disk space from a Sun to my PC running Pathworks. The server code had a lot of "magic" values in it, which seemed to be always present with the Ultrix server. It was not until two years later that I found out what all these values meant.
I thought other people might be interested in what
I had done, so I asked a few people at uni, and no one seemed much interested. I also spoke to a person at Digital in Canberra (the person who had organised a beta test of eXcursion) and asked if I could distribute what I'd done, or if it was illegal. It was then that I first heard the word "netbios", when he told me that he thought it was all covered by a spec of some sort (the netbios spec), and thus what I'd done was not only legal, but silly.
I found the netbios spec after asking around a bit (the RFC1001 and RFC1002 specs) and found that they looked nothing like what I'd written, so I thought maybe the Digital person was mistaken. I didn't realise that the RFCs referred to the name negotiation and packet encapsulation over TCP/IP, and what I'd written was really an SMB implementation.
Anyway, he encouraged me to release it, so I put out "Server 0.1" in January 1992. I got quite a good response from people wanting to use Pathworks with non-Digital Unix workstations, and I soon fixed a few bugs, and released "Server 0.5", closely followed by "Server 1.0".
All three releases came out within about a month of each other.
At this point I got an X-terminal on my desk, no longer needed eXcursion, and promptly forgot about the whole project, apart from a few people who e-mailed me occasionally about it.
A year passed with just occasional e-mail asking about new versions and bugs. I even added a note to the ftp site asking for a volunteer to take over the code as I no longer used it. No one volunteered.
During this time I did hear from a couple of people who said it should be possible to use my code with LanManager, but I never got any definite confirmation.
One e-mail message I got about the code did, however, make an impression. It was from Dan Shearer at the University of South Australia, and he said this:
I heard a hint about a free Pathworks server for Unix in the Net channel of the Linux list. After quite a bit of chasing (and lots of interested followups from other Linux people) I got hold of a release news article from you, posted in Jan 92, from someone in the UK.
Can you tell me what the latest status is? I think you might suddenly find a whole lot of interested hackers in the Linux world at least, which is a place where things tend to happen fast (and even some reliable code gets written, BION!).
I asked him what Linux was, and he told me it was a free Unix for PCs. This was in November 1992, and a few months later I was a Linux convert! I still didn't need a Pathworks server, though, so I didn't do the port, but I think Dan did.
At about this time I got e-mail from Digital, from a person working on the DEC-Alpha software distribution. He asked if I would mind if they included my server with the "contributed" CD-ROM. This was a bit of a shock to me, as I never expected DEC to ask me if they could use my code! I wrote back saying it was OK, but never heard from him again. I don't know if it went on the CD-ROM.
Anyway, the next big event was in December 1993, when Dan again sent me e-mail saying my server had "raised its ugly head" on comp.protocols.tcpip.ibmpc. I had a quick look on the group, and was surprised to see that there were people interested in this thing.
At this time a person from our computer center offered me a couple of cheap ethernet cards (3c505s for $15 each) and coincidentally someone announced on one of the Linux channels that he had written a 3c505 driver for Linux. I bought the cards, hacked the driver a little, and setup a home network between my wife's PC and my Linux box. I then needed some way to connect the two, and I didn't own PC-NFS at home, so I thought maybe my server could be useful. On the newsgroup, among the discussions of my server, someone had mentioned that there was a free client that might work with my server that Microsoft had put up for ftp. I downloaded it and found to my surprise that it worked first time with my Pathworks server!
Well, I then did a bit of hacking, asked around a bit and found (I think from Dan) that the spec I needed was for the "SMB" protocol, and that it was available via ftp. I grabbed it and started removing all those ugly constants from the code, now that all was explained. It was a shock seeing the real spec for SMB, and it made me realise how lucky I was that my original code worked at all.
On December 1, 1993, I announced the start of the "Netbios for Unix" project, seeding the mailing list with all the people who had e-mailed me over the years asking about the server.
At this stage I called the package smb-server. This changed quickly one weekend when I got e-mail from a company that makes a commercial Unix SMB-based server. Apparently they have trademarked that name. I needed a new name quickly, and Samba was born.
This list has now grown to over 600 people and a newsgroup (comp.protocols.smb) has just started, primarily because of peoples' interest in Samba. I get approximately 100 connections to the Samba ftp site each day, and dozens of dedicated hackers have contributed to the code. Samba is now being used as a production PC file server at many sites worldwide.
Almost all of the development for Samba was done on my home Linux box. Linux has been a fantastic development plaform. Without Linux, Samba would certainly not be where it is today.
Now that I've got that off my chest, I better tell you what Samba can do. Not that I expect anyone to still be reading after a tirade like that one.
Samba provides file and print services to SMB clients. These include LanManager, Windows for Workgroups, Windows NT and OS/2. There is also a free client for DOS put out by Microsoft, but it's a real memory hog.
Samba also provides a Netbios name server, so PCs can find the server, and a Unix SMB client program. The SMB client only has a primitive ftp-like interface, but a proper mountable SMB filesystem for Linux is in the works.
Samba uses quite a comprehensive configuration file mechanism written by Karl Auer. Karl also did all the documentation for Samba, which I think has been very important in its success.
Some features of the Samba server are:
There are a lot more bits and pieces. Samba has "suffered" from Karl's code that allows me to easily add new options. There are now more than 60 configurable options in the server, which can be applied in endless combinations for each exported file or print service. Thank god for Karl's man pages.
Samba is being improved all the time. It is now a distributed development effort with many active contributors. Upcoming versions are likely to include full long filename support for those clients that can handle it (such as Windows NT and Chicago), browsing support and a mountable SMB filesystem. Work is also proceeding on a more complete RFC1001/1002 netbios nameserver implementation.
Get it, use it. If it doesn't work for you, then remember how much it cost. Also remember to send me a bug report.
Now I think I'll go and have some lunch.
Andrew Tridgell is an associate lecturer in the department of computer science at the Australian National University in Canberra, Australia. He is also completing a PhD in automatic speech recognition in the computer sciences laboratory at the same university.
