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
> You do have lm announce set to yes, for OS/2 support?
No, if you have OS/2 clients I would suggest setting it to yes but it's not required.
When set to yes, the Samba server should show up faster in the NET VIEW list.
Check out my homepage on this.
-------
Warning: Slashdot may contain traces of nuts.
Quoted:
"All this extra complexity is not good. Why not simply use unix filesystem for the unix machines, and NTFS for the Windows ones ? Any sharing can be done via NFS. There is no reason to use SAMBA. Also you are at the mercy of Microsoft changing the spec on you."
I guess then you've never had to interface multiple machines without a large budget. Or understand exactly what this product does. The native filesystems are the same, all it does is make a UNIX box look like SMB fileservers (a.k.a Win9X, NT).
Prime example of this is what I had to do a year ago to interface a new accounting system to the old one. The old system runs on SCO OSR5, and the new one is a client-server SQLserver based application. Problem was, some of the old system's modules were in use, and had to export to the new one. Dug around for usable tools, found samba, and *presto*, instant interface. Configuration took me all of twenty minutes (first time okay?) and I never have to monitor the thing.
I tend to be pretty cynical about software, and this is one of the few packages that I have respect for.
"All those tubes and wires and careful notes!"
"All those tubes and wires and careful notes!"
I fully agree.
However, it is not new users I have in mind, but rather experienced users. I think they would benefit just as much, if not more, than beginners.
You see, if you know a lot about how things generally work, and how things are supposed to fit together, 1 example will make a whole lot clear.
It surprises me that there are so few examples in the man pages for Linux.
On other flavours of unix it is very common to see examples at the end of nearly every man page.
That is truly helpful. And not much work for the writer of the manpage, since he has just written in great detail how things work, and thus must know about every option anyway!
We talk about Dave for Macintosh in the book, but barely mention OS/2 as a client.
You do have lm announce set to yes, for OS/2 support?
George
I thought LM ANNOUNCE was a Windows thing - it was a setting you need to have enabled (it's disabled by default) because OS/2 doesn't support the "Master Browser" concept.
I don't have Linux installed anywhere, let alone Samba. Are you saying that LM ANNOUNCE is also a Samba thing? I didn't see anything about LM ANNOUNCE in the DAVE documentation.
(getting off-topic)
Specifically, my problem is that my Mac can't see my OS/2 drives, but it can see my OS/2 printers.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
Is there any converage on intergrating OS/2 and Mactinosh clients (and servers) with machines running Samba? I'm trying to get my Mac (using DAVE) and my OS/2 machines to see each other, and it's not working well. I'm thinking I may need to set up a Linux box running Samba and use that as the primary shared resource.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
I had difficulty the firt time as well. But there is a trouble shooting guide in the Samba documentation which takes you step by step through some simple tests that can pinpoint where the problem actually lies. In nmhy case it was misunderstanding one of the samba.conf option lines.
Anomalous: inconsistent with or deviating from what is usual, normal, or expected
Anomalous: deviating from what is usual, normal, or expected
Canard: a false or unfounded repor
It seems that the drive to create PDC support was stalled by the desire to have Win2k compatable PDC support. They were almost there for NT4, but now you hear a lot about how Microsoft is maneuvering to cut off the Samba project from the ability to have Win2k PDC's.
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.