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 at ieee.org http://thebs413.blogspot.com ------------------------------------------ Some things (or athletes) money can't buy. For everything else there's "ManningCard."