Samba 4 Enters Beta 170
rayk_sland writes "Progress is being made on the long awaited Samba 4 release. On Tuesday the Samba 4 team announced their first beta. Those of us who refuse to have a closed-source server at the core of our networks will be encouraged to see this milestone. Here are a few of the new features: 'Samba 4.0 beta supports the server-side of the Active Directory logon environment used by Windows 2000 and later, so we can do full domain join and domain logon operations with these clients. ... Samba 4.0 beta ships with two distinct file servers. We now use the file server from the Samba 3.x series 'smbd' for all file serving by default. For pure file server work, the binaries users would expect from that series (nmbd, winbindd, smbpasswd) continue to be available. Samba 4.0 also ships with the 'NTVFS' file server. This file server is what was used in all previous alpha releases of Samba 4.0, and is tuned to match the requirements of an AD domain controller. We continue to support this, not only to provide continuity to installations that have deployed it as part of an AD DC, but also as a running example of the NT-FSA architecture we expect to move smbd to in the longer term. ... Finally, a new scripting interface has been added to Samba 4, allowing Python programs to interface to Samba's internals, and many tools and internal workings of the DC code is now implemented in python.'"
Re:internals? in python? (Score:4, Insightful)
Why not? It's a new major version which provides new functionality, and is written in python to make it easier for people to contribute.
Memory and CPU have never been cheaper, if you're still running your samba box on a PIII 450MHz then you'll probably want to stay on Samba 3.
Otherwise upgrade your hardware and move to Samba 4 when it becomes stable.
It *WILL* be slower and it *WILL* use more memory, since it's not stable and it's a major new version with new features.
Sheesh.
Re:Big shoutout to Tridge and the whole Samba team (Score:2, Insightful)
It is much more likely that these are the fruits of long years of dedicated and hard work. In my books, the collaboration you mentioned is just the icing of the cake that is samba. When you have a look at, for instance, .Net/Mono you can easilly see how one-sided that collaboration is.
Re:internals? in python? (Score:5, Insightful)
Re:Big shoutout to Tridge and the whole Samba team (Score:5, Insightful)
Microsoft fought interoperability in every way they could using fair means or foul, legal or illegal. And still it did not stop the Samba team. The fact that Microsoft managed to slow them down for years is a testament to... something. Not anything nice.
Domain controllers are really the last bastion of Microsoft's illegal barriers to interoperability. This is a big deal.
Re:Big shoutout to Tridge and the whole Samba team (Score:5, Insightful)
Uhh nope. More like the fruits of the Samba team sticking to their guns in the EU and microsoft being forced to open up their protocols.
Re:internals? in python? (Score:4, Insightful)
Re:internals? in python? (Score:5, Insightful)
Intentional (or even incidental) inefficiency is never a positive thing when it comes to computing.
You seem to be under the impression that the most valuable resource in computing is clock cycles.
It's not, not even close.
The most valuable resource in computing is developer time. If writing in Python makes it quicker to develop code (it does, by orders of magnitude), then that is "efficient". I've been writing C programs since the late 80's and even I can see that Python is a productivity win.
I get sick of people that rant about "inefficiency" in clock cycles when here, in the real world, the inefficiencies with the greatest business impact are the ones that cost dev time. Devs are freaking expensive. A dev spending 2 weeks squeezing an extra 0.1% of performance out of a non-critical part of an app is a complete waste of time and money.
By all means, don't make a slow heap of crap (I don't think Samba is). And by all means, for code which is profiling very poorly, impacting the users and hurting the business, look for lower level optimisations.
But please, for everybody's sake, get some perspective on this issue. Just because parts of it are not written in C doesn't mean it's not efficient, because "efficient" covers a heck of a lot more than clock cycles, at least to people who actually have to run a business.
Re:internals? in python? (Score:2, Insightful)
You're right: There won't be 100 users running an admin tool (though I view smbtree, in particular, as more of a user tool...at least on the networks I've been paid to use). But there could easily be 100 users running 100 different Python apps which could be more-efficiently coded in...almost anything else.
The problem I see (and I see it more and more, and not just with Python) is that things are becoming more runtime-interpreted and less efficient. Going back some decades, it is often explained that it doesn't matter "these days", but I submit that it does matter -- and always has.
Instead of battling execution time (the CPU in my cell phone is ridiculously faster than my first half-dozen computers even if they're all combined and quadrupled), we're now battling energy efficiency. But other than terminology it's exactly the same game: Interpreted languages may be fast to develop, but cost more for people to use.
Case in point: I, a single user, notice when I'm running inefficient programs on my phone. Things generally happen very fast, but they also cause the hardware to get (sometimes uncomfortably) hot and the battery voltage starts to dive.
smbtree in particular is such a light-duty single-shot thing that it really won't ever matter to me, by itself, but the confluence of that and every other inefficient program makes a real dent in my ability to use my pocket computer and stay away from a charger, which has a real and tabulable cost in terms human time.
And not to be too pessimistic, but to extrapolate: It ought to be possible for a sufficiently-motivated person to ascertain the cost of such inefficient programming techniques in terms of human lives lost.
(Ugh.)
Re:2002 (Score:5, Insightful)
"You're a fool if you're telling the truth"
I'm sure he's not. He probably isn't outright lying, as in just making something up from scratch, but rather just suffering from Smartest Motherfucker in the Universe Syndrome, as many programmers do.
I see it all too often, programmers who seem to think they are god's gift to programming. They think they are WAY better than all the stupid "normal" programmers. They can't see why people have so many bugs, can't understand why development takes so long, can't understand why programmers don't "just make this happen," and so on.
Hence he probably did look at this and say "That'll be easy," not understanding the full complexity of implementing a really good AD server. The Samba team perhaps does understand and wasn't interested in playing around with someone who doesn't.
Re:Big shoutout to Tridge and the whole Samba team (Score:5, Insightful)
This is about much more than just the filesystem. You can run a full-on AD controller now, complete with group policies, etc. It really is a drop-in replacement for most of Active Directory does.
Can Linux play too? (Score:4, Insightful)
The decade-long focus on playing nice with Microsoft Windows seems to be getting somewhere, but I haven't seen much about letting Linux play too.
Does CIFS implement SMB2 yet (or is there an "SMB2FS" module that I missed), or is Linux still excluded outside of "smbclient"?
Can SAMBA4's LDAP server also be used for standard basic LDAP authentication as well "e.g. for web servers, minimalistic *nix boxen, etc) or does it still only permit authentication by clients implementing a full "ActiveDirectory®" stack?