The Other Side of the Coin: Samba as a Server

Remember how little configuring we needed to do to get the Samba client tools working? Well, those days are over, my friend. We'll have to change a lot of options now, but we'll explain each one. Without further ado, here's the updated smb.conf.

  ; /etc/smb.conf

  [global]

  workgroup = CURTIS

  guest account = nobody

  keep alive = 30

  os level = 2

  security = user

  encrypt passwords = yes

  socket options = TCP_NODELAY

  map to guest = Bad User

  interfaces = 192.168.2.102/255.255.255.0

  wins support = no

  [cdrom]

  comment = Linux CD-ROM

  path = /cdrom

  read only = yes

  public = yes

  locking = no

  [music]

  comment = My Music Files

  browseable = yes

  public = no

  writeable = no

   create mode = 755

 path = /MyMusic

· workgroup: All my Windows machines belong to the CURTIS workgroup, so it only makes sense that the Samba installations would be members as well.

· guest account: Is set to nobody. This is fairly irrelevant, since you should never grant write access to anything without a username and password.

· keep alive: Sets the number of seconds between "keepalive" packets, which are used to determine if clients are alive and responding. And 30 seems to be a good generic number for this ”often enough to notice pretty quickly if a client hangs , but not often enough to swamp the network with "keepalive" packets.

· os level: Sets the importance of the samba server for the purposes of master browser elections . Windows NT workstations and servers hold regular battles to see who is in charge of things (who becomes the master browser, that is), and the higher this value is, the more likely the server is to win. I've set this rather low, since I've got another Samba server on the network, and that one has the os level set to 65 ”which means it will win every election.

· security: The valid options here are user, share, server, and domain. I set it up for user-based security, because that's how I think and because I specify the same username for both my windows machines and for my Unix accounts. If your usernames aren't the same between the two, you should set up share-based security. Share-based security is also good for password-free shares, such as for printers. The security setting is the single most important aspect of your configuration file, and therefore of your Samba setup. At the very least, read the section of the man page and see what will work the best for you. At the very most, go out and read a detailed book on installing Samba.

· encrypt passwords: If you use windows 98 or NT 4.0 SP3, set this to yes . Otherwise, set to no . If you've got a mix of Windows flavors on your network, God help you. Seriously, though, there are known issues with mixing Windows 9x, NT, and 2000 on a single network. Again, the Samba documentation is king.

· socket options: TCP_NODELAY is a major performance gain. Set it.

· map to guest: This isn't used if your security level is set to share. Basically, this determines who becomes the guest user. Bad User means that if someone enters a username that does not exist in the smbpasswd file, that individual will be treated as the guest user. Other options include Bad Password, Never, and Bad Andy. Bad Password means that users who enter their passwords incorrectly will be treated as the guest account. Never is self-explanatory, and Bad Andy is a special case for dealing with evil sock monkeys .

· interfaces: This line describes IP address and netmask to use when doing broadcast queries. If these options aren't set, Samba will determine the values automatically.

· wins support: You shouldn't set this to true unless you have a multisubnetted network and want a different machine to be your WINS server.

Per-Share Options

· [whatever]: Every share must have an internal label. How else would Samba tell the difference between them?

· comment: Put anything you feel is appropriate in here. It will be visible if you're looking at your Network Neighborhood in Detail mode.

· path: Is the full path to the share on the Linux system.

· read-only: Sets whether or not users can write to the share.

· locking: This might be useful for read-only file systems (like CD-ROMs). According to the man page, I should never need to set this. SuSE sets it out of the box, and they're usually pretty clever, so I'm following their lead on this.

· browseable: Determines whether or not this share will show up in the Network Neighborhood browse window. If set to no or false, then the share will not appear.

· public: This is a synonym for "guest ok."

· writable: Determines whether or not users can write to the share. Rather the opposite of read-only, eh?

· create mode: The default permission for files created on this share. The format is the same as the numeric permissions argument to chmod.

Obviously, there are a lot more options. You could spend weeks learning them all, but they aren't all necessary to get you up and running right now, so we're not going to cover them. The point is: You can really, really customize Samba. It's a full-featured replacement for Windows NT server ”and the price is certainly right.

smbpasswd

smbpasswd allows you to add and remove user accounts from Samba's local database as well as to change passwords. These functions are useful only if you have the security = user option set. This means that Samba should "roll its own" authentication rather than using an external provider like a domain controller. When someone on a Windows machine tries to connect to a share on the Samba machine, they'll need to provide one of these usernames and a valid password.

When you first start out, then, you'll need to add some users to the local database. Use the following command to do this:

 $ smbpasswd -a username

Note that the users must be valid users on your Linux machine, too. Samba certainly isn't going to give the Windows users remote root access just because they happened to know a password. Instead, the remote users get the privileges of the Linux user account with the corresponding name . The permissions on the Linux system will have an effect on what the users can do through the share.

Other flags to smbpasswd include -x to delete a user, -d to disable a user, and -n to set a user up without a password. Please, please, please don't use -n. It's just not wise.

Now that users and shares are set up, any Windows clients on my network should be able to connect to the music share by mapping a drive to \ \ SAMBASERVER\ MUSIC. If they're logged into the Windows network with the same username and password as one that I set up with smbpasswd, they'll be able to map it immediately. Otherwise, a new authentication box will pop up for them to enter a new username and password. I won't worry about Linux workstations, since we already know how to connect to shares with those.

Becoming a Server in an Existing Domain

Isn't it tedious to go setting up users on your Linux box that duplicate existing Window logons ? And just wait until you have to deal with password changes. If you already have a Windows domain with a Primary Domain Controller, it's probably easier to tell the Samba server to use domain authentication instead.

Simply set the security = domain option in the configuration file, and then use smbpasswd -j to tell the domain master that you'd like to be added to the domain. You'll also have to set password server = <myPDC>. Note that your PDC can be either another Samba machine or an NT box. No matter how good an idea it seems to be, do not point your Samba server at itself! Can you say infinite loop? I knew you could. Anyway, look up the password server and security options in the documentation and knock yourself silly.

Windows 2000 Issues

What were you thinking? You paid for another MS upgrade? Ugh. Okay, there are known issues. Samba 2.2.0 and higher can act as a Primary Domain Controller for W2K, with some limitations in functionality. File sharing is okay, as of Samba 2.0.7. Smarter people than I are currently working on this. They'll likely have it fixed by the time this book is published, but be sure to check out the Samba Web page for documentation of this. You can get some documentation on using Samba 2.2.0 as your PDC at http://us1.samba.org/samba/docs/samba-pdc-faq.html .

SWAT

SWAT is the Samba Web Administration Tool. It allows you to set up and configure your smb.conf file via your browser. Before I go any farther, I have to say: I hate GUI configuration tools. They annoy me. They never offer anything over the command line tools, and they rarely work. That said, I have this to say about SWAT: I love it. It's a pretty slick system, and it even has password authentication.

SWAT is started via inetd , and has only two flags: -a and -s. -s specifies the name of the proper config file (SWAT assumes it's at /usr/local/samba/lib/smb.conf ), and -a turns off authentication. You would never ever want to use -a. Ever. Really. I'm quite serious about this.

In order actually to run it, you'll need to add a line to /etc/services and one to /etc/inetd.conf. Add this line to /etc/services:

 swat 901/tcp

The number "901" can be any sub-1024 port, provided that it is not already in use. The SWAT man page warns of an obscure security hole that may be en countered when using port numbers larger than 1024. For safety's sake, keep it under 2e9.

Add this line to /etc/inetd.conf:

 swat stream tcp nowait.400 root /usr/local/samba/bin/swat swat -s /usr/samba/smb.conf

Notice the -s option. It specifies the location of the Samba configuration file on my Debian system. After both files are changed, tell inetd to refresh its configuration:

 # kill -HUP `pidof inetd`

 # /etc/rc.d/init.d/inetd reload

Now, fire up your browser, and type http://localhost:901/ in the address window. Away it goes!

Caveats

You should use SWAT only from localhost . Even though it's password authenticated, the password is sent over the network in clear text and is hence just as vulner able to sniffing as Telnet. If you consider the risks of disclosing this password, you'll decide very shortly to avoid taking the easy way out by connecting to SWAT remotely.

And for the white-space -obsessed, be warned : SWAT removes comment, copy, and include options from your Samba configuration file. It rearranges entries. If you have a really customized smb.conf file, either avoid SWAT or back up the config file first.

Figure 5-4 shows SWAT's start-up screen, viewing the network over at Mr. Anderson's place. Figure 5-5 is the selection screen for choosing which share to manipulate. Figure 5-6 presents some of the options you can set within the share manipulation screen.

Figure 5-4. SWAT Main.

Figure 5-5. SWAT Choose Share.

Figure 5-6. SWAT Share Manipulation.

I like SWAT. It has a nice link to the Help file right by each of the options. It's a nice, easy way for you to get started creating your own shares and to manage most everything about your Samba server.