23.1. Introduction

Samba is used for providing file and print sharing and authentication services for Windows LANs, and for networking Windows with Linux/Unix. Samba functions much like a Windows NT domain controller, if you prefer a domain-style LAN, or an ordinary Windows peer network, where all the hosts can directly share files and printers with each other. It also functions nicely as a standalone file or print server, as part of a domain or workgroup.

You can mix Linux hosts into any of these scenarios: peer network, domain, or central file server. Files are easily shared between Linux and Windows. Sharing printers is a little trickier, but the combination of CUPS and Samba makes it much less painful.

As Windows NT4 Server nears the end of its support cycle (December 31, 2004), wise admins are migrating to Samba. It's a perfect drop-in replacement for an NT4 domain controller.

Samba server runs on every Unix variant, including Mac OS X. Any platform that supports the Common Internet System/Server Message Block (CIFS/SMB) protocol, such as VMS, AmigaOS, and NetWare, can be a Samba client.

Samba is now on version 3.x. If you're still using 2.x, you really need to upgrade. Outwardly, 3.x looks the same—the configuration options are the same, and it installs the same way. But under the hood, it's a beefier, much-improved engine.

Samba has another useful application that hardly anyone talks about: file sharing between Linux hosts. The Network File System (NFS) is the old standby for file sharing on Unix. It still does the job, but you ought to give Samba a try. It's more secure, and easier to set up and use. It's also quite a bit more flexible—users can update shares and log on and off without giving Samba fits.

Samba's configuration options are legion. The secret to Samba happiness is keep it simple. Start small and slowly, and add configuration options only as you really need them. Yes, the world is full of Samba geeks who love to show off their elaborate configurations. You're welcome to do the same, if that's what you enjoy. But for simply running nice, stable, reliable servers, complex configurations aren't necessary.

Samba 3 is a big improvement over Samba 2. Some of the improvements in Samba 3 are:

• Faster performance, especially on a 2.6 Linux kernel

• Native integration with Active Directory

• Support for Unicode character sets

Samba 3 cannot replace Active Directory; it does not have all the user, network, monitoring, and resource management tools that AD has. However, it can fit nicely into an Active Directory domain as a file server and be managed just like any other Active Directory member. It's a bit tricky to make it work, so I recommend practicing on a test network first. AD relies on Kerberos for authentication, so you'll need a good understanding of Kerberos (refer to Chapter 6 in the excellent and thorough The Official Samba-3 HOWTO and Reference Guide—available for free on http://www.samba.org, or you can purchase a printed book).

Unicode support is a big deal, because it means users can store documents in languages that don't use the ASCII character set and retain filenames in their own languages (Hebrew, Arabic, Russian, and so forth).

23.1.1 System Requirements

Samba doesn't need the latest, greatest CPU. It does like a lot of RAM and fast disk I/O. How much you should invest in the hardware depends on how many users will be hitting it, how much space you need for file storage, and how critical it is to keep it running. Since you wisely will not be running X on your Samba server, for a small LAN—say, 50 users or less—an old Pentium 300 running a three-disk IDE RAID 5 array, with 256 MB of RAM, makes a good, robust central file/print server. With RAID 5, you get striping for speed and a parity check for data integrity. Of course, you can always use a nice SCSI array, if you want to spend the money. Linux supports SCSI well, and you'll get better performance and longer life.

The quick-and-dirty way to check your Samba server's performance is with ping. If you get ping times over 100 milliseconds, your server is getting too busy.

23.1.2 A Brief History of Protocols

It all started way back in the olden days at IBM and Sytec, with NetBIOS (Network Basic Input Output System). This provided the interface between applications and network hardware. Then Microsoft tweaked it to allow file sharing over a LAN, producing the direct ancestor of CIFS/SMB. The original name was CIFS, then it became SMB.

Then IBM made more improvements, and came out with NetBEUI (NetBIOS Enhanced User Interface), which allowed packets to be passed over Ethernet and Token Ring. Remember, in those days no one knew that Ethernet would become queen, so all these new network protocols were being invented and tested. NetBIOS and TCP/IP turned out to be a particularly effective team: NetBIOS shoveled LAN packets, and TCP/IP made packets routable, which meant they could travel over wide-area networks.

Somewhere along the way Microsoft added user authentication and service announcements, so that connected hosts would announce their presence to each other. "Yo! I'm here!" may not be the most elegant solution, but it's practical.

Computer lore tells us that in the early 1990s, Andrew Tridgell, the primary author of Samba, needed to network his own DOS and Unix boxes. Unsatisfied with the available tools, he invented Samba. And the rest is history.