Samba—Unix Talking with PCs
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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide