 | Level: Introductory Daniel Robbins (drobbins@gentoo.org), President/CEO, Gentoo Technologies, Inc.
01 Apr 2001 In this article, Daniel Robbins explains how Samba 2.2 improves on the already-excellent Samba 2.0.8 to create an incredibly powerful enterprise-ready Unix/Windows integration solution. The new Samba 2.2 offers a host of new improvements, including Windows 2000 client and Windows NT domain controller support, to name just a few.
If you're like me, you're very familiar with the incredible importance of
a particular piece of free software called Samba. For years many of us have been using
Samba valiantly to integrate Unix and Windows systems into
a single, unified networking environment. We've successfully configured Samba
2.0.x to serve files and handle print jobs for Windows machines, even to
authenticate Windows logins. And some of us have even been fortunate enough to
get Samba 2.0.x to function as a Windows NT Primary Domain Controller, or PDC, allowing a Linux or Unix server to act as a central control point for an
entire Windows NT domain. Yes, for the last few years, the Samba 2.0.x series
has allowed us to do a lot of amazing things, which many once thought impossible.
Samba 2.0.x: almost perfect
Of course, if you're familiar with the Samba 2.0.x series, you also know that
Samba has its share of limitations. Samba 2.0.x veterans know that the key to
a successful Samba installation is to be keenly aware of these limitations and to work around them. As long as
Samba is used appropriately, it has proven to be a very reliable solution, often much
more reliable than Windows NT itself. However, if you've ever used one of Samba's
less-than-stable features, you may have easily created problems for yourself. Over
the past several years it has been these quirks that have made Samba 2.0.x an
almost perfect Windows/Unix integration solution.
Quirks in 2.0.x are numerous. For example, Samba 2.0.x has user-level security that
works well with Windows NT, but not so well with Windows 95. And there has always been an issue with Samba's oplock implementation. Oplocks are a fine-grained
locking mechanism that's part of the SMB protocol, used to dramatically improve
file-sharing performance.
However, in 2.0.x there is a problem with oplocks; they only work correctly if you
accessed files exclusively from the Windows "side", through a SMB share. Why?
Because Linux's and Samba's file locking and caching mechanisms were
independent of one another, meaning that if you modified a file from the
Linux console, it could take several minutes before your changes were reflected
on the Windows side. For many, this meant that oplocks had to be disabled to
avoid data corruption and file sharing issues. This is not a great solution.
NT PDC support, please!
Things were even worse if you're one of the unfortunate people
who struggled to use Samba as a Windows NT Primary Domain Controller. Over the
last four years, Samba has had at least some ability to function as a domain
controller for a Windows NT domain; the problem has been that the
functionality has always been buggy and incomplete. Unfortunately, Samba
2.0.x's PDC abilities have always been broken, and it's been only recently
(with the 2.0.7+ releases) that basic PDC functionality has been available to
Samba users, but again not without its quirks.
While domain logins and roaming profiles appear to work OK under 2.0.7+ , the
Windows NT administration tools tended to have lots of problems. Yes, you
could add a Samba domain user to a local group, but the next time you peeked in
User Manager, the user would be listed as an "Unknown user". And, nearly any
other Windows NT-based administration tool would flake out when it even looked
in Samba's direction. If you asked Samba developers when these features would
be implemented, you'd get answers like "I don't know", "maybe in a year", "stop
asking me" or "please go away". Not exactly encouraging.
The light at the end of the tunnel
Despite all this, Samba 2.0.x was an incredible software achievement. However,
only a subset of its functionality was ready for enterprise use; the rest was
fun to play with, but only made us yearn for the day when those
features actually worked and we could integrate Unix machines into nearly any
type of Windows network with the greatest ease. Samba 2.0.x has been an
excellent tool for those with time to tinker, test, and tweak things until they
worked. But, of course, the point of this article is not the bugs in Samba 2.0.x; it's about the fixes for all these problems in the new Samba 2.2.
Samba 2.2 overview
Samba 2.2.0 is a major milestone in Samba development, containing many
improvements and feature additions in almost every area of the program. The
Samba 2.2.0 release offers a number of benefits for Linux users in particular; there are a couple of new features that take advantage of new Linux 2.4
functionality, or use features that can be enabled via a kernel patch. Let's look at some of the major improvements and additions to be found in Samba 2.2.
Kernel oplocks
Samba 2.2 includes kernel oplocks support, allowing Linux 2.4 and IRIX systems
to present a consistent view of the filesystem to the outside world, whether
accessed locally, over a SMB share or even over NFS. As I mentioned earlier,
this was something that just wasn't possible with Samba 2.0.x. With 2.0.x, if
you wanted filesystem consistency from the Linux console as well as a SMB
share, you'd need to add these lines to your smb.conf file:
level2 oplocks=no
oplocks=no
|
This would fix the problem, but degrade performance. But now, if you use Linux
2.4 or IRIX along with Samba 2.2, this problem simply vanishes. So, whether
your users are accessing their data via the console, X, Samba, or NFS they will
always see the same data and will experience optimum Samba performance!
Windows NT/2000 integration
Samba 2.2 is now able to handle Windows 2000 clients without a problem. In
addition to that, Samba 2.2 can now emulate almost every aspect of a Windows NT
Server's Domain management responsibilities. Yes, this means it can do all the
important stuff, like become a Primary Domain Controller in a Windows NT
domain, authenticate Windows 95/98/NT/2000 users against its security database,
and support roaming profiles, login scripts, and system policies. All these
features now work reliably.
And, there's more. A lot of NT domain-related quirks are now fixed. For
example, my Samba 2.0.7-based Primary Domain Controller setup worked OK, but
pretty much any Windows-NT based administration program would choke if it even
looked in the direction of the Samba server.
Integrating Samba users into an existing NT security database was also a
nightmare. For example, I used to have a problem where if I used User Manager
to add a Samba domain user to a local group on a Windows NT Workstation, the
user would show up as an "unknown user" the next time I loaded up User Manager.
Quirks like these were enough to make Samba 2.0.x inappropriate as an
enterprise PDC. Now, thankfully, it appears that all these problems are fixed
in Samba 2.2. With 2.2, it's even possible to view all the Samba Domain
accounts and groups using User Manager for Domains, as you can see in this
snapshot:
Using User Manager for Domains to view a Samba 2.2 domain: A giant step forward!
Right now, all the data in User Manager is read-only, but read-write support is
in development and should appear at some point during the 2.2.x series.
Other major improvements
Samba 2.2 also performs much better than the 2.0.x series, thanks to its use of
an internal database structure rather than overly-relying on "flat" data
structures. Samba can now act as a Microsoft DFS (Distributed File System)
server. It has enhanced file locking code, and supports a special "profiling"
performance-analysis running mode.
Besides all this, Samba 2.2 sports full Windows printer support (for 95/98/NT
and 2000), and now even supports the automatic Windows driver download
feature. This means that you can use Samba as a print server for all your
Windows machines, without worrying about what versions of Windows are used in
your organization.
All in all, these improvements mean that Samba 2.2 is truly enterprise-ready --
for even the most challenging tasks. It's now definitely possible (and
desirable) to use Samba as a Primary Domain Controller for a network consisting
of Windows 95, 98, NT, and 2000 machines. And unlike 2.0.x, you won't have to
worry about Windows 95-, NT-, or 2000-specific Samba quirks. In general, you can
expect Samba 2.2 to simply work, and work well.
On the horizon
In addition to the new features I've already covered, there are a couple of
others that are in the process of being integrated into the Samba 2.2 source
tree as well as into Linux 2.4 itself. Let's take a look at them.
Winbind
Winbind is a special system that allows Windows NT domain users and groups to
automatically appear to exist under Linux, and also allows Linux services to
authenticate against Windows NT domains. Winbind is especially useful for
integrating Linux boxes into an existing Windows NT domains. This
functionality is going to be incredibly useful for Linux-based network
appliances that need to be integrated into an existing Windows NT security
infrastructure. Under Linux, NT usernames will appear as "DOMAIN\user", as
will all domain groups.
Winbind didn't quite make it into the Samba 2.2.0 release (it's currently
included in an experimental version of Samba), but it is working and will
hopefully show up in 2.2.1. For now, it's a Linux-only feature that works by
integrating with PAM (pluggable authentication modules) and NSS (name service
switch).
ACL support
The next incredibly cool Samba 2.2 feature is its new support for access
control lists, or ACLs. As many of you know, Windows NT and 2000 use ACLs to
set permissions on files and directories, and they offer a much finer-grained
control over permissions than the traditional "one user, one group" solution
that most Unix systems use. Up until now, Samba has had no way to store ACLs
directly on the filesystem, since there was no ACL support available for Linux.
But now, we're starting to see the beginnings of ACL support -- an ACL kernel patch for Linux kernel 2.4.3 is
currently available (see Resources below), as well as several user-space tools. ACL support is now
fully-supported in Samba 2.2.0.
Although Samba 2.2.0 supports ACLs, there are a lot of tricky steps currently
required to enable ACL support in the kernel and the filesystem. Since the
standard ext2 filesystem has no way of storing ACL information, you'll need a
special ACL-enabled version of ext2 installed first; this involves patching
and recompiling the kernel, as well as upgrading all the ext2 utilities on your
system.
However, once you've done all this, you will be able to use Samba's ACL
support under Linux. Once set up, Samba will preserve NTFS ACLs rather than
mapping ACL permissions to the less-flexible standard Unix permissions scheme.
This is a great thing. Think about it: ACL support in combination with
winbind will allow a Linux-based system to "assimilate" Windows NT users,
groups, and ACL permissions. Quite an amazing achievement!
But right now, ACL support under Linux is in its infancy. Nearly every backup
program will not back up the ACL information, meaning that ACLs can
easily be lost unless special measures are taken. Of course, the fact that ACL
support is almost non-existent at the filesystem level (with only a patched
version of ext2 and SGI's XFS currently
offering ACL support -- see Resources below) makes ACL-enabling a Linux system quite a difficult task.
However, you should expect this process to become easier as Linux distributions
eventually become ACL-enabled by default.
Resources
About the author | | |
Residing in Albuquerque, New Mexico, Daniel Robbins is the President/CEO of Gentoo Technologies,
Inc., the creator of Gentoo Linux, an advanced Linux for the
PC, and the Portage system, a next-generation ports system for Linux.
He has also served as a contributing author for the Macmillan books
Caldera OpenLinux Unleashed, SuSE Linux Unleashed, and Samba Unleashed.
Daniel has been involved with computers in some fashion since the
second grade, when he was first exposed to the Logo programming
language as well as a potentially dangerous dose of Pac Man. This
probably explains why he has since served as a Lead Graphic Artist at
SONY Electronic Publishing/Psygnosis. Daniel enjoys spending
time with his wife, Mary, and his new baby daughter, Hadassah. You can contact Daniel at drobbins@gentoo.org. |
Rate this page
| |
