Slashdot Mirror
Samba Administrator's Handbook
The Scoop Imagine you're the administrator for a diverse network. A couple of engineers have Unix boxes, while some programmers work on NT machines. Managers have Windows laptops, and you've talked them into letting you install Samba domain and print servers. You've read the documentation and understand how it works. Now what?
That's the scenario Samba Administrator's Handbook wants to address. Designed for the busy administrator who needs quick answers in a convenient package, it takes the pragmatic approach, and gets most things right. Need to set up a print queue on Solaris? Turn to the detailed table of contents to find a complete walkthrough. It's not the kind of book you'd sit down and read from cover to cover (Trust me on this), but at least you'll know what kinds of things pop up more than once in smb.conf.
What's to Like? Samba is designed to work with a variety of operating systems and platforms, and the authors cover quite a few: Solaris, RedHat and Caldera Linux distributions, and Free and Net BSD. These are good choices, because they represent a cross section of Unix land. Clients include the Windows family, as well as DOS and Unix (where applicable). Also included are task options (different utilities or command line switches). For example, the Samba installation section describes compilation, package selection during installation, and RPM installs. Samaba's rapid development receives due mention, with advanced users pointed to anonymous CVS and the excellent mailing lists.SWAT receives the best coverage, reinforcing the notion that this book is meant to be used by administrators who don't have the luxury of looking up many pages on the server (or those who prefer to read printed versions). Additional configuration resources are also covered. These include SMBEdit, webmin and Linuxconf.
The handbook covers client-side issues very thoroughly, including a detailed section on troubleshooting under various operating systems. (The breadth of coverage surprised me, as there were commands I did not know even existed.) Also, the Best Practices chapter takes a server-level approach, with sections on backups and security.
What's to Consider? My one large gripe may only bother a few readers: The editing really seems half-hearted. This is annoying, as the layout is inconsistent in places and numerous typos mar the text. I did not notice any factual errors resulting from this, however.Occasionally, options are mentioned but not explained. Most of the time, these are the smb.conf options included for debugging purposes, deprecated in newer versions, or options which should never be changed. Some additional information would be interesting, if not immediately useful. Likewise, the benchmarking chapter suffers from a skimpy treatment, mentioning tools but not what to do with them.
In some spots, more information than necessary is presented. For example, the generous SWAT chapter repeats some information verbatim, as certain sections of the smb.conf file take similar options. Erring on the side of caution fits the organizational goal, though reprinting tar man pages may be a bit extreme.
The SummaryShort on theory but long on facts, until you have your smb.conf memorized and can keep six different versions of the same command straight in your head, you can find quick and correct information here.Buy this book at ThinkGeek.
Table of Contents- Installation and Basic Configuration
- Server Installation
- Client Installation
- Basic Configuration Using SWAT
- Basic Operating System Configuration
- Other GUI Configuration Tools
- Advanced Configuration
- Naming Services
- Best Practices, Browsing, and Domains
- Performance Tuning
- Troubleshooting
- Basic Network Connectivity
- Testing the Samba Configuration
- Accessing Samba
- Using Net Commands to Diagnose Problems
- Appendices
- Error Codes
- GNU General Public License
- Online Resources
The current plan is that 2.0.8 will be the answer to your prayers :-). This functionality is being added for ACL support, but I'll test it works for Win9x as well.
Regards,
Jeremy Allison,
Samba Team.
Have you ever worked in a heterogeneous environment? Windows users want to open up their "Network Neighborhood" double click on the machine and then double click on the file share.
I maintain several servers (IRIX and Linux - SGI has been a big supporter of samba) and I share the required directory or two on each box. It is easy - no NFS client software to worry about, easy for Windows users, and it works quickly and realiably. Samba also allows printer sharing.
I can see avoiding SMB and Samba if you are primarily a UNIX shop. However, we run about 70% NT and 30% UNIX so the interoperability that Samba provides is excellent.
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
One more annoyance I've noted is for Samba to try to communicate out the loopback port, 127.0.0.0.
/etc/rc.d/init.d/smb restart and you shoudl be golden.
Just add a line interfaces = 192.168.1.2 or whatever your network address in the global section of the smb.conf file.
Restart Samba
George
My usual Linux distro is RedHat, and I don't have problems getting Samba working.
/etc/rc.d/init.d/smb start
//hostname/homes
A few things to try.
Use testparm to check the validity of your smb.conf file.
Is samba running, use ps to find it.
If not, what happens when you start Samba, on RedHat this is:
#
Try to log in locally with smbclient
smbclient -L hostname -U username
Also try
smbclient -U username
I hope this helps,
George
I agree wholeheartedly. To be honest, these topics are not very well covered even w/r/t closed-source solutions. The open source projects, with few exceptions (mostly thanks to Oreilly) are fairly poorly documented, and most of the documentation that exists is in HOWTO's and such which rarely have much depth.
To get a full understanding, a person would have to read the HOWTO's, slashdot, newsgroups, FAQ's, and every text, PDF, and html file they could find, then experiment a lot. Even savvy users get sick of that.
The open source projects in general IMHO have grown to the point that they include feature sets comparable to or exceeding those of their closed source counterparts, mainly because there are a lot of people working on that stuff. Just think if even a small percentage of these coders worked on docs! And if they got published, they'd even get paid for their work, imagine that!
I guess the main problem is that programmers generally would rather program than write docs. Writing docs can be real boring for some people, and just as hard as writing efficient code.
Can anybody compare this one to the O'Reilly one? I like the O'Reilly 'cause its searchable online; but it could be more detailed.
I have a small LAN that I support containing mostly NT and Win9x boxes, but I use Linux as the main server (DHCP, http, ftp, and of course Samba). As it is now, every user (in order to use shares off of the NT boxes and the Samba box) must have their username and password registered with both all the NT boxes and the Samba server. Then when they need to change their password, they must go to each box and change it many times. Is making the Samba box a Domain controller the only way to have all NT and Win9x boxes validate against the Samba password database, or is there a different password sync method? Thanks!
-Shawn
To being with, I don't know why your modded to -1, this seems like an abuse of moderator privileges.
Domains are one option, the other is to have the Samba server reference another server for password verification with the password server parameter.
I don't have a lot of experience with Domain controllers (ed checked that part of the book), but that's the way I think you need to go, either make Samba a Domain Controller, or make one of your NT boxes a Domain Controller, and have Samba join the NT Domain.
Otherwise, you can have Samba reference another server for password verification, using the password server prompt. This only cuts down some of the password changes, the other NT boxes probably need to be changed individually.
I hope this helps,
George
Whats the best way to migrate to encrypted passwords? The way the samba docs tell you to do is fine... except in the real world where you have hundreds of users spread out over multiple servers that sync.
Does anyone have a pretty much fullproof way of doing it? I mean, all the way down to the H_KEY settings that needs to be changed via kix.
Are you running unencrypted passwords now? Then you could consider using the update encrypted parameter, to slowly build your encrypted password file.
Once all the users have encrypted passwords in the smbpassd file, you start encyrpting passwords.
Hope this helps,
George
Wow, I'm jazzed, I never shared a Slashdot topic before.
If anyone has any questions about writing the book, I'd be glad to answer them to the best of my ability.
If anyone has Samba questions, I'll do my best to answer them too, though my turnaround time may be greater.
I agree on the skimpiness of the benchmarking, we ran out of time, and it's hard to simulate real workd performance on a Pentium and 486 home network.
As far as the duplication of pages wrt to the smb.conf section, and others sections, the publisher said to go a little overboard there, to avoid needless page flipping. We might have taken that a little too far.
As far as including the GPL, it seems to be the thing to do, every book has it, it may be a publisher's requirement, but we included it anyway.
Thanks,
George
This is not intended as flamebait, but IMHO we need many more books like this for open source software. The problem is that the current open source / Linux documentation (manpages, the HOWTO's and mini-HOWTO's) require a LOT of time and reading on the part of the user, before they can even see any results. There aren't very many docs that guide you through, step-by-step, how to get some semblance of what you want up and running.
I'm not saying that that is a bad thing; after all, we do want to educate the masses and prevent (as much as possible) clueless people who wants to be spoon-fed and never RTFM, right? But we need to remember that people like to see results. Even a little result. Having to read through an entire HOWTO, and then perhaps still not quite understanding just what it is you have to do, is very discouraging for a new user.
We should have more walkthroughs -- pre-made "recipes", so to speak, that new users can follow and get at least some result. We need to at least get them started; then hopefully they will be more interested/inspired to actually tackle all the details in the HOWTO's or other docs that came with the software, and eventually learn what they should learn. You need to learn to walk before you can run. It's a bit harsh to stick to the "sink or swim" philosophy. Much better if we cater to those who want to learn but can't quite make it without extra help.
---
mikre he sophia he tou Mikrosophou.