Slashdot Mirror
Samba 4 Enters Beta
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.'"
Way to school Microsoft on their own technology!
When all you have is a hammer, every problem starts to look like a thumb.
He's a Mac user. Samba/Cups keeps falling over on OSX.
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.
I've first tested Samba 4 around alpha 11. It was certainly an interesting learning experience and it was also surprisingly stable for an alpha product. I'd love to play around with it again after 2 years of development.
$(echo cm0gLXJmIC8= | base64 --decode)
so yes, he is stupid
While I'm certainly not a fan of Python, it's clear that they are leaving the high performance parts in C, and just using Python for scripting. Samba comes with a lot of tools that are not performance critical. For example, the smbtree utility needs to print a pretty tree of the current network from the results of a scan. If the scan is done by the core C code, there's no reason why you can't write the part that parses command-line options, prompts for passwords, and displays the output in an interpreted scripting language: even if it runs at 1% of the speed of C code, users won't notice the difference because almost all of the time will be spent in the code doing the I/O.
I am TheRaven on Soylent News
So, I guess our organisation is one of those strange ones that persists with Samba as a domain controller.
To date, we have around 400 machines (desktops and laptops) running mainly XP (but some with Windows 7 and with a full migration in progress to Windows 7). We run two separate Samba 3 DCs to service out two domains. This setup has served us well for almost 10 years now.
The main challenge presented to someone trying to run Windows Vista or above on computers attached to a Samba3 domain controller is the lack of group policy options. With XP and below, you can use the 'ntconfig.pol' method to deploy policies to workstations on the domain. With Vista (and Windows 7) this method is no longer supported (and I don't just mean 'not officially supported, but works with some hacks'- it actually does.not.work.at.all). There are ways around this, and I have managed to find a workable solution that will allow us to run Windows 7 exclusively on a Samba3 domain and still have basically the same policy options available to us (this is achieved by working on the local computer policy for non-administrator users on the master image of our standard operating environment, combined with manually mapping samba groups to certain local groups on the workstation). This obviously isn't perfect, but it works for us and saves us a heck of a lot of money compared to the alternative, but I appreciate that what works for us won't work for everyone.
So for me, the major feature that Samba4 brings to the table is the group policy side of things (I know there's obviously a lot more to it than that, but at present that is the major thing that feels 'missing' from Samba3). Given that I see no reason why we won't end up sticking with Windows 7 until it ends extended support (in 8 years time) I see no reason why we won't be using Samba for quite some time.
Oh, and other than congratulate the Samba4 team in general, I have to give a personal congrats to Andrew Bartlett- a fellow Aussie and someone I have met personally. Thanks for all your hard work guys!
Programming is about picking the right tool for the job (which is never Python, but I digress). There are not going to be 100 users running an admin tool at once. Even that tool is not going to be loading the CPU, because it is going to be spending almost all of its time calling into C libraries. If the choice is writing it in a language that makes it easy to get bug-free and which does not impose any user-visible cost, or writing it in a language that makes what you want to do (e.g. string processing) error prone, likely to be buggy, and does not run detectably faster, then you are an idiot if you pick option 2.
I am TheRaven on Soylent News
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.
I'm sorry, but if you could have done it ten years ago, maybe you should have. And released the product, and get bought out, and made lots of money, and proved everyone wrong. Hell, you still have a lot of time because Samba still has a LONG way to do yet.
Samba's AD implementation has been a long time coming but personally EVERY prior attempt I've seen, including quite a lot of samba-tng, was horrendously hacky. Having to install and configure perfectly 5-6 entirely independent dependencies is not a good recipe to test or debug code on (one tweak to one config file and samba would stop working for a user and it could take hours to spot that difference and massive amounts of reinstalling, reconfiguring and sending logs and configs back and forth). I took several looks at solutions over the intervening years but nothing was even close to risking the time to install them, let alone test the results. And believe me, I looked at anything and everything that came up.
From what I saw, most of the patching to get things like samba-tng etc. working code-wise was horrendously hacky and basically the equivalent of rewriting the spec - while Kerberos might be paid lip-service by MS, their variants are quite different and not the kind of thing you want polluting an otherwise independent codebase.
Trying to get patches to 5+ different projects in order to fix your non-standards-compliant implementation of a protocol sounds like a political nightmare from the start, let alone doing it for the sake of purely Windows hangers-on. At no point did anybody just fork those projects and create their own versions, either, except to rewrite independent implementations. Not reinventing the wheel does not take a genius, and I have no doubt that EVERY step possible to avoid that was taken.
Without even looking into the details, I would consider it Plan B to have to push massive amounts of patches to five other HUGE projects just to get something close to beginning working so you can start testing, in terms of actually getting something out to others for them to use in stable systems (for testing, debugging, sure, use whatever hacky solutions you like) .
Fact is that over the last ten years NOBODY else has actually stepped forward and done this work, except for proprietary, closed-source solutions (all of which have problems - hell, even Apple's implementation is basically borked) and Samba.
Projects forks are ten-a-penny on large OS projects but yet nobody stood up and said "Damn, he's right, let's fork samba-tng to get this stuff going and worry about the politics later!". And at any point, you could suck in the Samba4 work for yourself to help you diagnose, test against, etc.
I hear a lot of "I could have", but never much "I did". I'm not saying I could do the work at all, but the vast majority of the people who actually stepped up to the plate were in the Samba team. And nobody else, on any other open-source project, "beat" them to it - even with the help of the EU courts and Microsoft itself. That suggests that maybe the task was slightly more tricky than just slapping things together.
AD implementations are also not the kind of thing you take chances with. If one machine dies because of a dodgy kernel, who cares, you can do something about it. If your AD structure trashes itself mid-day because of a bad failover to a Samba DC, or a long, slow, push of faulty and subtlely-broken packets makes things irrecoverable, you have a lot more to answer for. That means that even the post-Samba-3 solutions to AD's that I tried would have required YEARS of personal testing before I actually trusted them (and would most probably only see deployment on their own isolated network and AD and then slowly, over years, creep to the point where I was confident on just replacing everything with them).
If alternatives existed, and the work was possible, it takes literally MINUTES to set up a code mirror and post your patches and then you can spam it to hell and let people choose their own prefer
You are basically completely wrong about what the Samba team has done. All the daemons and such are still written in C (and/or C++). Did you really think that they would rewrite Samba from the ground up in an interpreted language?
All they have done is provide a scripting interface with bindings for Python. I don't know if the interface is generic enough to be used by other scripting languages, but that's irrelevant. The point is that you can script Samba, not that Samba is a script.
"it (open source) just seemed to want to steal someone else's work in this particular area."
What a baddass comment. Completely wrong, of course, but badass.
SAMBA predates Windows SMB server.
It would be just as accurate to say Microsoft "just seemed to want to steal someone else's work in this particular area."
Just another "Cubible(sic) Joe" 2 17 3061
"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.
I've got to admit that the length of time Samba 4 has taken has left a bit of a bad taste in my mouth. Re-implementing all the required services in one package at a cost of many man-years never struck me as the greatest of brainwaves. Yes, there are a huge number of corner cases regarding exact compatibility but Samba 4 could have happened much faster and the drudgery of hard compatibility testing could have happened much, much sooner by reusing existing software.
As it is, Microsoft got Samba doing exactly what they wanted for the last ten plus years - pointless fire and motion, duck and covering - and the project has now become all but completely irrelevant. Samba 4 really needed to come out not long after the release of Windows XP. Those needing a Windows 2000 DC system gave up on waiting for Samba a long time ago. It might be moderately useful for those who have to use Linux systems in some fashion with Windows, although they will have found ways around that long ago, but the window of opportunity for Linux to replace Windows Server in a lot of places continuing the momentum of Samba 3 has been completely lost.
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?
Hacker Public Radio is our Friend
When SAMBA came about, smb was a poor copy of NFS. SAMBA came about because pointy-haired bosses started bypassing the Unix wizards and building Windows for Workgroups based networks in the office and insisting that all the important stuff be stored there because getting a decent TCP/IP stack running on their PCs was too much expense and hassle. Active Directory came much later, when Microsoft decided to patch up the deficiencies in smb in Windows 2000 so it could move beyond the small-medium size offices and into the enterprise. Up until that point, SAMBA was a good, up to date implementation.