On Tue, 2005-12-06 at 00:40 -0500, Ugo Bellavance wrote:
> I knew that, but this is the terms they use in the Samba doc, probably
> because Samba can't emulate all the features of a DC.
Actually, it's a good sign of legacy Samba documentation.
Samba has supported PDC/BDC functionality since 2.0, replication
compatibility with native NT 4.0 PDC/BDCs as of 2.2+ (i.e., be a BDC to
a native NT 4.0 PDC, or a PDC with native NT 4.0 BDCs).
It can _replace_ a native W2K ADS DC as of Samba 3.0, or be its "bitch"
-- i.e., a "member server" in a native W2K ADS domain. It can't,
however, be a peer DC to a native W2K ADS DC, and it probably never
will, at least completely.
In reality, the "controller" functionality of the ADS DC versus the NT
4.0 PDC/BDC is the same. It's still just a big, glorified, network-wide
System Account Manager (SAM) database -- really little different than
the one in the local registry of a system. In fact, that's the _sole_
"real difference" between a workgroup and a domain -- the SAM** is
network-wide for a domain, local for a workgroup**. The replication
changes from a master and slaves of the NT 4.0 PDC/BDCs is now peer-
replicated in ADS.
[ **NOTE: Ironically enough, this requirement actually has to do more
with the poor design assumptions and resulting, often deadly, flaws of
the NTFS filesystem. I won't bore you with the details. ;-]
ADS then offers MS-Kerberos for authentication and a sprawling set of
schema and, more incompatibly, arbitrary Win32 services integrated with
it. It's because of that latter fact that you will probably _never_ be
able to use Samba as a DC to various servers that require native Windows
W2K ADS (e.g., SQL Server, Exchange, etc...).
A common, and quite _in_correct assumption, is that you need a full ADS
domain for Samba to work with Windows XP clients. That is _only_ the
requirement when you A) already have a native W2K[3] server providing
such or B) you want to use a native Windows service that requires ADS'
LDAP store and services (e.g., SQL Server, Exchange, etc...). You can
use Samba as a DC without such if not and that includes _removing_ the
requirements of MS-Kerberos with the ADS-Samba 3.0 store in an LDAP
tree.
> Hmmm, and I don't know LDAP very well...
Although the Samba 3 By Example gives you a lot of "cookbook" and "step-
by-step" hand-holding to doing such with OpenLDAP, it's still highly
recommended that you understand how to administer LDAP.
Then again, if you deploy ADS in anything but a small network, you
really should know how to properly deploy ADS. UNIX LDAP and Samba are
much more forgiving and can be reconfigured if you make a mistake. ADS
and Windows servers need to be wiped and reloaded to make changes
sometimes**.
[ NOTE: Again, a lot of these limitations are due to how NTFS was
designed, and the resulting issues that places on the NT kernel itself,
especially for files from different systems. ]
> I have started reading the oreilly book about it, but couldn't figure
> out how it looked/felt/worked in practice :(.
That's why I always recommended Netscape Directory Server (NsDS) over
OpenLDAP, because it makes assumptions, has a GUI management tool
designed specifically for it, etc... Once peer replication was added a
few years ago, I really stopped looking at OpenLDAP altogether.
Make no mistake, OpenLDAP _is_ powerful. It's very, very flexible,
extensible, etc... And it's also a major learning curve if you don't
know the first thing about LDAP.
> Well, there will be a few programmers on this server, but also the
> direcor, the secretary, a project manager, so they'll obviously need
> network shares, and, of course, network printing. On question that I
> have about Samba and printing: Do the printers need to have drivers for
> linux, if only the windows clients will print, or having windows drivers
> is enough?
No, the shares can be "raw."
However, Samba-CUPS SMB-IPP integration can be very, very powerful,
including not only the ability to automatically install drivers, but set
_proper_ configurations of the printers from the centralized CUPS
interface. I.e., when all your printers are Postscript with their own,
rich PPD (Postscript Printer Definition) files (or CUPS provides a rich
Postscript PPD for a non-PS printer), you can pre-configure the printer
and set the defaults for print-queues and they will be set for your
Windows users -- all from the CUPS web interface.
E.g., you can configure the memory size, various tray options, etc...
just *1* time, then those configurations are set in the printer settings
on every Windows client. That way you don't have to go around and do it
manually on Windows clients or, worse yet, your users dork with the
settings.
The Samba-CUPS integration is a few extra steps the first time, but from
then on, you just run 1 command to export the printer driver and its
PPD, which is then automagically available and downloaded by the Windows
client whenever you setup that network printer. It's no more work than
publishing a printer in ActiveDirectory.
Furthermore, the NT (including 2000/XP) print spooler is one of the
major reasons why NT crashes. Using the CUPS IPP driver drastically
reduces this. Yes, a workaround is to just use the native IPP driver on
Windows clients -- but that's not a network printer, but setup as a
"local port," not ideal from a management standpoint.
> Hmm, I'll read a bit on it, but I wonder if it isn't overkill...
> Ok. I doubt that because I'm the only sysadmin, but it can happen...
The problem with ADS is the fact that some schmuck in your organization
will standardize on an application that requires it. So then your
network becomes ADS' bitch.
The key to avoiding that is to have a pre-existing directory service
that rules your network, one that can synchronize at least accounts with
ADS (if not portions of the LDAP tree, which may be the case for cross-
platform apps).
NsDS has always excelled at this over the last few years, and doing the
same in OpenLDAP is a major headache. In fact, most of the
documentation for OpenLDAP-ADS focuses on making Samba ADS' bitch,
instead of making OpenLDAP a peer to ADS. About the only half-way
decent tool I've seen for OpenLDAP is FIT's AcctSync.
> The drives will be used one week over 2.
What are you doing about long-term retention? Off-site?
> Number of servers: 1 for the moment.
Then you can just use local UNIX accounts. No directory server necessary.
> The prod server will be in colo.
> Types of users: see above. Amount of users: ~ 10 for now, may grow up
> to 20 max within 24 months. Reason for SMB : file/print sharing. CVS
> details? What do you need to know exactly? We are using CVS over SSH,
> Eclipse with ssh keys being the client. The developpers work sometimes
> in the office, sometimes from home, connected to a vpn (the endpoint is
> a m0n0wall firewall). The developpers have a Xampp setup on their
> laptops and develop there, then test on the staging server, then put it
> in prod. The staging server is also the development MySQL server. I'd
> like to use OpenXchange to have a mail/calendar/etc solution that can
> work with current tools (outlook :().
I'm very partial to OpenGroupware.ORG (OGo). OGo has a long way to go
to be "easily installable," but it's the most flexible and open and
_rich_ backend with _server_ side scheduling I've ever seen.
Those are the 2 keys there:
1) open and _rich_ backend
2) _server_ side scheduling
Most are simplistic iCal (little more than FTP/HTTP free/busy) with a
web interface, or they are proprietary, MAPI-only (i.e., Outlook-only)
interfaces with a web interface.
Both iCal and most "Exchange replacements" then rely 100% on the
_client_ to do both processing of the rich store as well as scheduling.
There is _little_ intelligence on the server-side. This includes
Exchange itself, it's little more than a MAPI and, in more recent
versions, a XML-RPC "store" that clients use.
OGo has a web interface and it will do iCal (Apple iCal, Mozilla
Calendar, etc...), but it also has Palm.NET (no host required, direct
Palm sync), a rich XML-RPC API and then a WebDAV (aka "ZideStore")
interface. The last is what its Evolution and Outlook connectors use
(Outlook requires an additional MAPI connector, aka "ZideLook",
Evolution has its own connector built-in). It then uses it's business
logic to _process_ those _different_ stores on the _server_, to both
share information between the _different_ stores as well as do things
like schedule processing.
E.g., if a Evolution or Outlook client uploads calendaring if via their
rich, WebDAV ZideStore, it then gets resolved with data from iCal
clients, as well Palm.NET, web users, etc..., and the server resolved
schedules are published to all. Same in reverse -- especially for iCal
clients. It's not simply a FTP/HTTP "dumping ground" that other clients
dumbly download/upload from/to and do their own logic -- that's how the
overwhelming majority of iCal servers work.
OpenGroupware.ORG (SKYRiX 4.1) architecture:
http://www.opengroupware.org/en/devs/docs/OGoArchitecture.html
It doesn't do the new WebDAV Calendar Access Protocol (CAP) yet, but no
systems I know of do -- especially since it's still a draft standard.
But CAP is just another WebDAV protocol/store that ZideStore could
handle.
BTW, OGo is _only_ the collaboration component. It is not a SMTP/IMAP
server.
> The server is a dual Athlon MP 1800, 1 gB RAM, 3 ware 7006-LP card in
> RAID 1 with 80 gB PATA HDDs + 1(X2) 200 GB removable hard drive (this
> server is also a backup server for a few servers for now, but this will
> probably change.
> Please let me know if you need more details.
> Thanks for your input ;).
Yeah, if you're 1 server, don't worry about a directory service just
yet. Just use local accounts to get up'n running for now, then look at
a directory service later -- especially when you have more time.
Don't read all the Kerberos/OpenLDAP info on ADS. It's not required to
run a Samba domain to XP clients, if you only have Samba servers.
--
Bryan J. Smith mailto:b.j.smith@xxxxxxxx
http://thebs413.blogspot.com
------------------------------------------
Some things (or athletes) money can't buy.
For everything else there's "ManningCard."
