I think you don't really understand what Samba is for: OEMs. There are several very large companies selling rock solid enterprise NAS devices that need a rock solid implementation of CIFS on top of the seamless ability to join an AD domain. When large companies want to setup Windows file servers, they don't exactly want to stick a bunch of hard drives in a server and pray it doesn't go down - even clustered Windows file servers are extremely complex and have all kinds of failure modes that can cause hours or even days of downtime. Large companies simply want to buy a NetApp or some other enterprise class NAS storage device and have it integrate seamlessly with their Windows AD infrastructure. Samba now offers that. Storage companies that are experts at building highly redundant no single point of failure systems can now use open source software to deliver technology to the enterprise.

Hmm, you're arguing against a point I didn't make... my concerns are around replacing AD Domain Controllers with Samba. I think Samba's core bits do a fine job as a SMB/CIFS server along with krb5/PAM and Winbind.

> my concerns are around replacing AD Domain Controllers with Samba.

Here for us (not OEM) the whole AD stack you mentioned is completely overkill, and the stuff implemented by this Samba release looks terribly like covering 99% of what we use and need in our half windows (customer TSE access, networked file store), half linux (web hosting + many services) infrastructure.

In my tech environment, 3 cost-driven retailer clients with ~1000 branches have some 3rd party software which requires some AD to be present. Samba 4.x will be a nice option. They will start by migrating some branches from Windows Servers to Linux based AD services and move ahead as they see success.

Most people try to measure the cost benefit of free software, with TCOs, CALs, admin salaries etc. That is fine, but the true benefit of free and open source software in my experience:

1) The absence of license considerations in designing and developing systems; this frees the designer's mind in planning, and building. Now the system components can be planned without fear of a multitude of diverse, artificial license schemes.

2) The absence of a license-selling company; this frees the management's mind in estimating and revising the costs moving ahead. License-sellers like Oracle, Microsoft are well known for figuring out diverse sets of confusing licensing schemes. They spend their money in hiring the best sales people which are famous for hunting and then farming clients in the span of 5-10 years ahead by first locking them down.

Sounds like you were arguing against a use case which the other fellow doesn't believe is a target use of the product.

I counted 21 references to "Active Directory" in the release announcement (out of 26 paragraphs). Judging from this, AD may actually be a primary target use.

It's not the cost of a few domain controllers...it's the $50-60/user cost of client access license (CALS). I have 2500 users...that's quite a pricey (approx. $62K) system for directory services.

I personally am going to give Samba 4 a look.

If getting AD Domain Services off of Windows will actually avoid the need to buy any Windows Server CALs, then it certainly makes the proposition more interesting. But, this presumes that nearly all the other services (file sharing, http, etc.) are also not Windows.

We use Windows Server for three things:

1. Directory services/DC

2. Windows file shares

3. Exchange

I have to buy user CALs for #1 and #2. One CAL gives me the right to connect that user to any of our file shares and to AD. IIRC, that cost when we last purchased was around $50/user.

We also have to buy a separate CAL for Exchange.

I would love to replace AD and our Windows file shares with Samba 4, provided that it was a stable, viable replacement which didn't add a lot of overhead for our admins. Exchange is a separate issue, and one we're currently exploring Zimbra as a possibility. It's early days yet there.

Almost everything else in our environment is Linux.

For 3. you should take a look at OpenChange. It implements Exchange using Samba 4.0 libraries.

Do you know of any success stories with OpenChange? Thanks for the info.

I have to say that Microsoft convincing businesses that they need to pay to connect to servers that they've already paid for is a shear piece of economic genius. Morally abject, but still brilliant financially none the less.

$62k sounds like a pretty good deal when you consider:

1) It's probably not enough money to hire even one extra IT person to deal with new issues that will arise with Samba 4

2) Linux sysadmins are more expensive than Windows sysadmins.

3) Cost of retraining existing IT staff.

4) Potential loss of productivity of your 2500 users

5) Lack of commercial support options.

6) Uncertainty about the future of Samba in general (release time tables, feature support, etc)

1. I wouldn't need to hire an extra IT person. I already have very capable Linux admins.

2. Bad Windows sysadmins are less expensive than good Linux sysadmins. I agree with you there. Good Windows admins, however, are just as expensive. Trust me...I've hired quite a few.

3. Again, I have well-trained Linux guys on staff.

4. This is a very valid possibility we'll need to consider.

5. Not worried about that at all. We use a lot of open source without commercial support options, and our experience with Microsoft support is four hours of scripted troubleshooting on average, with about a 60% success rate of resolution.

6. Not concerned with this at all. Samba has been here for a long while and I don't think it's going anywhere.

1) FUD

2) You need an IT dept., not a monkey dept.

3) If your IT staff doesn't understand Linux already, see 2.

4) FUD

5) FUD

6) FUD

But IT departments are expensive, why can't we just hire kids without college degrees to work minimum wage and make millions of dollars of hardware sing in harmonious chorus? The kids are good with the computers right?

So samba 4.0 Samaba would be worth it, even if it required an entry level position (most likely part time)

If it costs 1 more sysadmin to support it, then it isn't worth it.

If it potentially could save licensing costs of about one sysadmin it is worth looking at. It is unlikely (but possible) an entire additional sysadmin will need to be employed just to support Samba.

Agreed. We currently have to keep a Windows admin on staff (who actually costs a lot more than the CALs) just to manage our shares, Exchange, and file servers. It'd be nice to get these final pieces of the Windows puzzle out of our environment and staff solely Linux admins.

But I do agree with the dbrain's sentiment. If it was going to have a significantly higher TCO, I wouldn't do it.

There's definitely a benefit for having those "one off" admins around. I'm the one Linux guy surrounded by 4 Windows admins. The services I'm responsible for can easily be pushed on to Windows servers... but I'm kept around for the off chance that some software will only run on Redhat or Citrix or whatever. But I'm also useful in how I approach tasks. My coworkers are quick to search Google for an answer, download a tool and have it do the dirty work. I'd rather look at the documentation, source code or API, raw log files, or even write my own tool to do whatever's necessary. Neither philosophies are wrong. But some are definitely better.

All that being said, I'm also underpaid (80% regional average). Maybe that's the real reason they keep me around.

... and if you have enough control over your environment to replace Windows Server as a domain controller, why would you be using the AD stack to begin with?

Aye, if one has that much motivation to chuck Windows for AD, then it's only logical that Windows on the desktop, Exchange, etc., are not on the scene.

I've done a lot of work with other directory servers too, and AD does the best job of any when it comes to multimaster replication and a few other things. However, using it purely for LDAP for an environment full of Linux and OS X machines is a tough call...

Why? I have such motivation, yet I have no intent on eliminating Windows from our desktops. That would be very disruptive to our 2.5K users, and Windows does a pretty decent job there. However, AD is very pricey due to CALs, and what it gives me is IMO not worth the price if I can replace it with Samba 4. That said, we're only beginning to explore this option, so it may not be viable or wise.

Just like many existing development companies have Windows-based infrastructure with both Windows and Linux on end-user systems, it makes sense to have Linux-based infrastructure while still supporting Windows end-user systems.

Linux support for AD also allows incremental migration of this infrastructure.

Rsyslog is way beyond Windows Event Logger. Audit trails should still work but I don't know if your GPO maps to server configuration automatically. It's easy to test, though. If you want to get started with Samba quickly, you can use Zentyal.

I didn't mean to say that the Windows Event Log is better than syslog or Rsyslog, but it has a particular structure that is really dissimilar, as well as access patterns (WMI, WinRM) that lack an analog.

That's MSFT and their NIH syndrome for you. Fortunately, there are several projects which allow you to map Event Log to syslog such as the aptly named "Eventlog To Syslog" ( http://code.google.com/p/eventlog-to-syslog/ ). This allows you to replace WMI with actual SQL (as Event Log can't use an SQL backend itself), and leverage all of the functionality of an RDBMS.

Similarly, my employer offers a product[1], which I have worked on, that can subscribe to Event Logs, syslog, ZMQ, etc., and do whatever you like with them. The inspiration to write this was the near-impossibility of getting the interesting, mostly AD-related stuff before all the super-chatty, useless crap pushes it out of the circular logs.

[1] http://zetetic.net/software-combine-index

Imagine the revenue if you were actually selling it on that website.