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.'"
Big shoutout to Tridge and the whole Samba team (Score:5, Interesting)
Way to school Microsoft on their own technology!
Re: (Score:2, Funny)
Way to school Microsoft on their own technology!
Perhaps those are the fruits of the Novell/Microsoft collaboration dedicated to enhanced interoperability ...
Re: (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: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:Big shoutout to Tridge and the whole Samba team (Score:5, Interesting)
Re: (Score:3)
Absolutely true. It's a poorly kept secret - for several weeks there I couldn't get hold of anyone on the Samba team because they were all busy over at Microsoft.
I think Microsoft has finally realized, at some point, that linux is just not a real threat to their business model. By encouraging
Re: (Score:3)
Re: (Score:3)
It had more to do with the EU forcing Microsoft to do it.
http://www.reuters.com/article/2007/12/20/us-microsoft-samba-eu-idUSBRU00620820071220 [reuters.com]
The Commission ruled in 2004 that Microsoft (MSFT.O) must provide interconnection information letting rival server companies operate as smoothly with Microsoft Windows desktop machines as Microsoft's own server software.
The deal signed in the United States by the non-profit Protocol Freedom Information Foundation was focused on helping Samba, a non-profit maker of free, open source server software.
"The agreement allows us to keep Samba up to date with recent changes in Microsoft Windows, and also helps other Free Software projects that need to interoperate with Windows", said Andrew Tridgell, creator of Samba.
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:4, Informative)
Re: (Score:2)
Since a European Union antitrust ruling, Microsoft has been co-operating with the Samba team by providing them documentation.
Not everybody at Microsoft is evil. Spineless maybe, for sticking with an unethical employer even when possessing easily transportable skills and probably not even earning at top potential. Or maybe we even have some moles in there, little intrusions of morality only staying with Microsoft because of the good they can do in the face of rampant immorality. But I doubt it, that's just me trying to be nice. I'm not very good at it. I prefer to dwell on the truth.
Oh and I doubt that cooperating enthusiastically
Re: (Score:2)
Such co-operation would have to be decided pretty high up, and certainly no random employee would leak the specs and say so publicly.
Nah, GP is right. EU anti-trust stick really helps there. Microsoft racked up somewhere around $3B in fines in EU overall (though most of that is in IE case... but once you get fined for one thing, there's more scrutiny elsewhere as well; and if you get caught again, fines are bigger, too).
This isn't to say that there aren't people who are very willing to share docs and explai
Re:Big shoutout to Tridge and the whole Samba team (Score:4, Interesting)
Meh. Sun flushed itself down the toilet and Solaris is on life support. Do we care about Sun's substandard Samba clone?
Re: (Score:3)
Do we care about Sun's substandard Samba clone?
Not since it became Oracle's substandandard Samba clone. I wouldn't fuck them with a stolen dick.
Re: (Score:2)
Re:Big shoutout to Tridge and the whole Samba team (Score:4, Informative)
Meh. Sun had CIFS in the Solaris kernel 5 years ago.
Err, cifs has been around for years in the linux kernel (as a module), and smbfs before that has been around since at least June 96
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.
Re: (Score:2)
Does it fully replicate how halfbaked the printer GPOs are? That part is really important.
Re: (Score:2)
Hopefully they have a properly implemented Quirks Mode that lets me simulate the unending horror that is deploying printers with user/computer policy GPOs.
Re: (Score:2)
Use a batch script with "rundll32 printui.dll,PrintUIEntry". Youll save a ton of headache. Yes its klunky. Yes, it really is the best way to deploy printers programatically.
http://forums.ocsinventory-ng.org/viewtopic.php?id=10929 [ocsinventory-ng.org]
Youre welcome.
(and I know that those GPOs look like they should work much better but... just dont)
Re: (Score:2)
internals? in python? (Score:3)
really? god help us all.. I really hope this doesn't affect performance or memory footprint.
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: (Score:2)
Give me a break. Samba 4 is not implemented in Python. You're not serious are you? Please tell me you're not serious.
Re:internals? in python? (Score:5, Insightful)
Re: (Score:2)
It still increases dependency hell, and it eliminates efficient scripting of those now 1% as fast operations. then there's embedded systems...
Re: (Score:3)
Re: (Score:2)
Distributing a standalone app (python stack + application) is still doable but that would be impossible in .net or java
It's perfectly doable with Java - indeed, many Java apps come with their own private JVM so that they don't have to test all versions out there.
It is indeed impossible with .NET, because it is a system component on Windows (installs under %SystemRoot%). But it's quite possible with Mono, which can also be packaged privately.
Re:internals? in python? (Score:4, Insightful)
Re: (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
Re: (Score:2)
To determine if something is efficient or not you first need to decide what you are optimizing for. If electricity usage is your target no the move toward run time interpreters might not be great.
The thing is the more of the platform that is implemented as a collection of single use high performance machine code modules glued together with script code the more adaptable it is to my work flow. I don't have time to deal with all my information sources and various protocols I have to work with in C. Could I
Re: (Score:2)
Perhaps you misunderstand: I don't care about energy cost in terms of dollars: Energy, on the scale that I deal with, is damn-near monetarily free.
I care about two things: How efficiently a multi-user (or otherwise-loaded) machine can use the program, and how long I (as a single user) can operate between charges, or without the device overheating and slowing down or becoming unusable in other ways (dual 1.2GHz ARM cores and no meaningful heatsink == thermal dissipation issues, often to the extent that th
Re: (Score:2)
Perhaps you are content to wait another 5-10 years so everything can be rewritten and debugged in C?
If the tools which have been rewritten in python are so complex that they would take 5-10 years to rewrite and debug in C, then they damned sure should have been written in C in the first place, because clearly they contain enough complexity to where the performance will suffer in python.
Re: (Score:3)
the cool part about properly coded native programming is that it's suited for a variety of environments.. from big iron servers, to pocket computers with tiny amounts of ram.. the script you talk about is something you run once a day, probably mostly IO bound.. the functions in a system daemon can be called hundreds to thousands of times/second...even more for real low latency and/or high bandwidth stuff. switching to a high level language severely limits the footprint the program can run in usefully.
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: (Score:2)
The most valuable resource in computing is developer time
that's great for them. what about MY time? and my users' time? I agree that time is money, and senseless nth degree optimizations are pointless, but offloading developer time by dumping bloated turds onto user hardware is a big no no. Every time this comes up, people want me to assume that the time magically disappears! it doesn't. it's offloaded onto the customer! This attitude is probably THE reason why so much software today is bloated beyond reason for a task.. The problem is compounded when the use
Re: (Score:3)
Huh... so a lot of people are wrong.
How many? Hard to count how many people, but we can certainly look at applications.
Let's examine my Fedora 17 laptop. In /usr/bin, 139 programs are written in Python, including my music player (quodlibet), repo management, some of abrt (defect reporting), time tracking, and desktop wiki.
Another 194 are written in Perl, including parts of fvwm, foomatic and callgrind.
388 more are POSIX shell script and 45 bash scripts.
There are 381 symbolic links, 31 hard links (which I no
Re: (Score:2)
Developer time is spent once. User time is spent as often as the program is used. The difference is that businesses can externalize wasted user time.
Re: (Score:2)
Re: (Score:2)
Developers are just disposable meatsacks to PHBs. (Score:2)
Whoo, you might want to have that ego inflammation lanced. I think it's starting to interfere with your vision.
Re: (Score:2)
In other words, you don't have a reasonable response that is anything other than a personal preference that you wish you could force on everyone else.
Re: (Score:3)
Re:internals? in python? (Score:5, Informative)
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.
Re: (Score:2)
I am glad to hear that, and honestly I doubted it, but the summary made me wonder with its choice of vocabulary, and trends these days would make me unsurprised if it was true. there is talk that the admin tools are now python based.. that does have implications if already existing scripts depend on rapid calling/scraping of admin utils.
Interesting, to say the least (Score:3, Interesting)
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.
Re: (Score:3, Informative)
I have an active Samba4 testbed intergrated to a huge AD structure and until alpha17 I've had all sorts of issues. However I now have alpha19 and things have changed considerably - it's working to the point where I have put a Samba4 test controller into production and have seen this Just Work once installed correctly.
However the official Samba4 install docs are shit. I had to work out a HOWTO that with the help of a few searches to fine tune it, that after a lot of work Just Works as well. You have to insta
Re: (Score:2)
I'll be blunt.
You're an ass.
And secondly, yes, a W2K/W2K3/W2010 'DROP' in replacement should be clicktard ready. And no, I don't care if you happen to think thats a bad idea.
And you really need to comprehend what drop in actually means. Being totally unfit for purpose, and requiring a Panatir and a bucket load of black magic does not mean bonus points.
Its 2012, not 1998.
2002 (Score:2, Interesting)
luke howard implemented Active Directory, in XAD, and released a product in 2002 (bought recently by novell). he used samba, freedce, heimdal and openldap, providing patches for each that hooked in the services that he implemented.
what he *did not* do was implement an entire LDAP server from scratch, implement an entire DCE/RPC runtime from scratch, implement an entire kerberos server from scratch.
i spoke to someone who used to be a big supporter of samba and was a prominent and active member of the samba
Re:2002 (Score:4, Interesting)
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
Re: (Score:2)
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.
welcome to reverse-engineering. samba tng was "version 1" of the "three versions required to make a successful project". from not knowing anything, and not having access to the IDL files in any way shape or form it actually provided pretty stable functionality, and broke the ice for the entire CIFS industry. network appliances, sco/tarantella, luke howard's XAD project - all of them could not have been possible without having that code to look at and understand.
luke howard *did* do it [the equivalent of
Re: (Score:3)
luke howard *did* do it [the equivalent of a version 2.0]. he *did* release the product [in 2002]... and he had to hold out for 8 years for a decent offer of a buy-out. everyone kept offering him stupid-money ($100k or less).
Serious question - why did I never hear of this? Either it didn't really work, it was the worst marketing job of all time, or it wasn't really open source.
that's why luke howard's work was successful, so quickly, because he leveraged the best available work in the most efficient and le
Re: (Score:2)
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: (Score:2)
- 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.
you're not getting it. luke howard's patches to heimdal, samba and openldap were the order of like 100 to 200 lines of code, each. they "outsourced" the required network traffic to XAD's daemons or plugins. for example, to create the PAC, luke howard implemented a well-known DCE RFC which provides a service called "PAULAD" - plugin authentication something something you get the idea - and then plugged that in to both heimdal and openldap.
the differences are *not* big enough to go spending years writing a
Re:2002 (Score:4, Interesting)
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.
Current Samba3-as-domain-controller user here (Score:4, Interesting)
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!
Re: (Score:3)
re: manually mapping samba groups to certain local groups on the workstation
In our large MS 2003/2008r2 network, we are recommending/enforcing mapping Domain Groups to Computer Local Groups on the (XP/W7) workstations.
Harsh (Score:3, Interesting)
SAMBA-nice, has its uses.
But if you want to do AD, do it with MS. Don't pretend that it can be done with SAMBA (at least not without pain). At the very least, SAMBA trades its own mad ranting about being interoperable while setting everything internally so its not.
And bottom line, the squeeling, crying and whining about MS interoperability never struck a cord at all with me. SAMBA came about because open source and its structures offered nothing that came close. If Novell and MS can offer a client and a back end server, it seems to me that Linux and open source could have providided a best of breed method of its own.
Instead, all I ever saw was that MS was evil and Linux and open source had to be given access to it. To my mind this was nothing much more than legally enforced theft of technology and I never thought it was right.
Several years later - and having had access to all they wanted, this is where we are?
Given the fuss kicked up, and the legal demands, I think MS should turn round and issue a counter case and state 'where is the interoperable product people put us through a legal case for?' You said we were the case of the failure of this in the market place, we complied and where is the product?
And no, don't get me wrong, I really like open source, and I like Samba and so on, but I never liked or thought that legal case had any merit, and I never thought open source really got its shit together in providing anything, it just seemed to want to steal someone else's work in this particular area.
Re:Harsh (Score:4, Informative)
"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."
Re: (Score:2)
SAMBA predates Windows SMB server.
Uh what? Lan Manager was a SMB server.
Re: (Score:2)
Um..
Lan Manager 2.0 for Windows couldn't have been released before Windows NT 3.1 (https://en.wikipedia.org/wiki/Windows_NT_3.1) which was released in 1993.
SAMBA was first released in 1992 (http://www.rxn.com/services/faq/smb/samba.history.txt).
Lan Manager for OS/2 was available, but I did say Windows. Also, OS/2 was seriously impeded by the x86 platform. Servers were Unix boxes (Linux was released in 1991, and wasn't yet ready for prime-time).
Windows was "peer to peer" networking, or OS/2 server to Windows
Re: (Score:2)
SAMBA was the first product that allowed "real" servers to serve files to Windows clients.
On this we are in complete agreement.
Re: (Score:2)
LAN Manager was based on the OS/2 operating system co-developed by IBM and Microsoft. It originally used the Server Message Block protocol atop either the NetBIOS Frames protocol (NBF) or a specialized version of the Xerox Network Systems (XNS) protocol. These legacy protocols had been inherited from previous products such as MS-NET for MS-DOS, Xenix-NET for MS-Xenix, and the afore-mentioned 3+Share. A version of LAN Manager for Unix-based systems called LAN Manager/X was also available.
In 1990, Microsoft a
Re: (Score:2)
It may well predate anything.
They still went to court and made the ludicrous demand 'give us access to your API and code' whine whine whine.
And your early SAMBA must have been before the days it made claim to mimic an NT4 Server as 'drop in'.
And on your final point, if MS stole the work, now SAMBA has had clear insight into that, code and API, when shall I expect the lawsuit?
Re: (Score:2)
Who are "they"?
SAMBA didn't bring a lawsuit against Microsoft. SAMBA purchased the protocol description from Microsoft for 10,000 Euros. There was also a round of legal discussion needed to keep SAMBA as GPL software.
The European Commission investigated Microsoft. This was triggered by a request from SUN to Microsoft asking for interoperability documentation for AD. Microsoft refused, SUN entered the complaint -- SAMBA didn't get involved until Microsoft tried to use SAMBA as an example of why protocol doc
Re: (Score:2)
Read what I said. I claimed that it would be just as valid.
I don't think that SAMBA stole from Microsoft, and I don't think that Microsoft stole from SAMBA.
I just stated that the chronology made the original claim silly.
Re: (Score:2)
Instead, all I ever saw was that MS was evil and Linux and open source had to be given access to it. To my mind this was nothing much more than legally enforced theft of technology and I never thought it was right.
Would mod you up if I hadnt already posted-- This never settled well with me. Earlier in the thread someone was ranting about how closed and inoperable AD / MS was-- but it seems like it at the very least got its leg up on its own merits, because if there had been a superior offering from "Open Source" at the time it seems to me that businesses pursuing profit would have found it, used it, and had an advantage.
Insisting that MS help everyone else compete with them just seems lame. If their product is so b
Re: (Score:2)
Bollocks
The reason for SAMBA was simply that Windows (Windows 3.1 for Workgroups) came with SMB file sharing.
SAMBA helped integrate these workstations with larger networks and servers.
Re: (Score:2)
Actually, SMB was created by DEC for their Pathworks software suite to connect VAXen to other computers.
Windows' involvment came later, partly because Microsoft hired a lot of VAX people over to do NT and a lot of Windows' heritage tends to reflect that.
http://www.samba.org/samba/docs/using_samba/ch01.html [samba.org]
Re: (Score:2)
History
3Com 3+Share/MS Net/Xenix Net -> LanManager -> LanManager/X (portable) -> DEC Pathworks -> SAMBA
Re:Harsh (Score:4, Interesting)
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.
Re: (Score:2)
I nearly fell off my chair.
A poor copy of NFS.
You seem not to understand just how poor NFS (was) and just why so many people chose something else.
And - well, to be blunt, MS did not just make something that fixed up limits in NT. They created a de facto large scale directory service / server system that no one else really provided. And they made it relatively easy to install, maintain, and qualifiy people to use.
Note carefully the last part. Because some round here think that its clever, and a road to succe
Re: (Score:2)
SAMBA-nice, has its uses. But if you want to do AD, do it with MS. Don't pretend that it can be done with SAMBA (at least not without pain). At the very least, SAMBA trades its own mad ranting about being interoperable while setting everything internally so its not.
If you want all the latest features provided by Microsoft for the SMB/CIFS/AD implementation, then yes by all means use MS servers and pay lots of money for CAL licenses for each server so that you can host everyone, and be prepared to have keep all your workstations in sync with the version on the server because their backwards compatibility sucks.
If you want a version that works, continues to work through Windows upgrades, and provides login compatibility with Unix/Linux systems, then use SAMBA; or if yo
Re: (Score:2)
If you want all the latest features provided by Microsoft for the SMB/CIFS/AD implementation, then yes by all means use MS servers and pay lots of money for CAL licenses for each server so that you can host everyone, and be prepared to have keep all your workstations in sync with the version on the server because their backwards compatibility sucks.
You are kidding, right? I can probably hookup a W7 with an NT4 domain with less hassle than with samba.
If you want a version that works, continues to work through Windows upgrades, and provides login compatibility with Unix/Linux systems, then use SAMBA; or if you have Linux/Unix clients that you want to authenticate to a Microsoft server - use SAMBA.
This one is hilarious. Do you know that you _need_ to upgrade samba to work seamlessly with the latest Windows versions, right? Do you know that, at each release, you get new bugs and unexpected behaviour? Do you know that some releases are actually unusable (with show-stopper bugs in stuff like remote profiles), right? And that many many times, connectivity problems are "solved" by not using TCP/IP, but b
Re: (Score:2)
Many vendors shipped licensed versions, including:
3Com Corporation 3+Open
HP LAN Manager/X
IBM LAN Server
Tapestry Torus
Boom.
Thats your ship being blown out of the water.
What about LDAP (Score:3)
I've tested alpha 16 and 18 and they are quite functional. I just wish they took the external LDAP route. Running on top of LDAP is good but being restricted to their own internal LDAP server isn't.
Right now if you check their wiki they discourage the use of an external LDAP server. So while they offer scripts to migrate your Samba 3.x LDAP based directory what should I do about the other applications using my directory server? Can I extend the schema? Their default setup doesn't even have the Posix schema attributed to nis.schema.
Re: (Score:3)
I am not sure about the current status of the work of the Red Hat team behind FreeIPA, that integrate Samba 4 with other FreeIPA base technologies like 389 LDAP Server (I remember Simo Sorce was working in Samba integration), there is outdated documentation about using Samba 4 alphas with 389 LDAP server backed [freeipa.org], so there is interest in that kind of integration
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?
Re: (Score:3)
Official support for SMB2 exists since Samba 3.6. It was present in 3.5 but it was marked as experimental.
Re: (Score:3, Informative)
Re: (Score:3, Funny)
so yes, he is stupid
Re: (Score:3)
Apple doesn't ship Samba in Lion. Things worked better with Samba, but they wanted to avoid the GPLv3.
Re: (Score:2)
Are you stupid?
What's broken?
There has been no support for printing in Samba4 ever...
Same goes for a forest trust. These two are stoppers for many companies to switch to Samba4, everything else works fine.
Re: (Score:3)
Oddly enough, I have never had trouble making windows print to a Unix print queue. Of all the interoperability issues between Windows and Linux, printing has been the least of my problems.
Re: (Score:2)
Same. I ran a Windows client/Linux server environment for years with Samba 3 acting as a NT4 DC and the only real pain of managing printers was figuring out what parts I needed to strip out from HP's shitty installer to get driver auto-install working when a user first connected.
The two things I really missed from a native Windows server environment were WSUS and the ability to push software without resorting to silly hacks running in the login script. I can't wait for Samba 4 to get stable enough for pac
Re: (Score:2)
If you wanted to sell ad ons, you should sell them to Windows server users.
I can't see how GPL would get in the way of internal use, you never distribute anything.
Re: (Score:2)
How do you define "internal use" ? One subnet ? One building ? One department ? One company ? Multiple subsidiaries registered in different counties ? And what if someone not considered "internal" in one of the above ways sccesses (by mistake or unlawfuly) your software ?
How do you persuade a company legal team that GPLv3 is not poison and let the techies use GPLv3-licenced software ?
Re: (Score:2)
Re: (Score:2)
the legal they use in the is "convey":
To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
http://www.gnu.org/copyleft/gpl.html [gnu.org]
A company carrying out work on the code and keeping it for them selves (same party), does not convey the code and does not run into any GPL clauses. If they they are legally two parties then as long as the second party ca
Re: (Score:2)
GPLv3 is very restrictive with respect to developers. It's fairly open from the perspective of a user.
Re: (Score:2)
You have a funny definition of permissive that seems to include "has restrictions". The "most permissive license" would be one that imposed no use restrictions whatsoever-- which GPLv3 (and v2) does not qualify for.
You might say that its the "most free" or "most open" or "most consumer friendly", and possibly some might agree with you, but certainly not most permissive.
Re: (Score:2)
And this goes especially true for Samba - as GPL3 is worded, you are not allowed to use-it to serve protected files, or, if you do, it's fair game to anyone to steal your data as this whole "domain authentication" stuff is Digital Rights Management.
Im no lawyer, but that sounds like absolute nonsense. DMCA for example means that even if it is technically feasible to crack DRM, it is (or can be? not a lawyer) illegal to do so.
And if the files being served are company property, for another entity to gain access to them in an unauthorized fashion would certainly run afoul of several anti-hacking laws, at the very least.
Further, GPL says NOTHING about what you can or cannot do with compiled binary IIRC-- all of the scary restrictive stuff has to do with
Re: (Score:2)
> Your legal team is incompetent
Could be. And it seems it is contagious - i know a lot of other companies who have the same policies regarding GPL3 software :-(
Re: (Score:2)
Ive never heard of such a thing. I HAVE heard of companies which restrict the use of GPL TOOLS in a development process, because that (feasibly) could be seen to be "derivative". But if your business is selling widgets and you use linux, your internal memos arent somehow going to become public domain because you used GPL software. And if you use Samba to serve up files used in a development process, I dont think theres a judge in the world who would rule that your dev project is somehow derivative just b
Re: (Score:2)
And this goes especially true for Samba - as GPL3 is worded, you are not allowed to use-it to serve protected files, or, if you do, it's fair game to anyone to steal your data as this whole "domain authentication" stuff is Digital Rights Management. So the lawyers say, and management will listen to the lawyers and not the engineers.
This is complete nonsense and any sane reading of the GPLv3 will make that clear. Even if encrypted authentication were DRM, which I doubt to the extent that I believe no lawsuit attempting to prove it could succeed, it just doesn't matter because (1) the files are not themselves protected by this encryption, (2) even if the files are protected by this encryption the users of the fileserver do not have rights under the GPLv3 (AGPLv3, maybe, but not GPLv3) because they do not at any time receive a copy, (3)
Re: (Score:2)
Re: (Score:2)
It's called "corporate empoyment" and you can find in there magcal pieces of paper called "paychecks". Feel free to join the madness when you grow up.
Re: (Score:2)
Tridge is so super talented. Wish he had focused on rsync....
Why? It's perfectly well maintained by others, his talent is needed in other places. By the way, if you think rsync is cool, check out rzip.
Re: (Score:2)
You can just fire the Windows Remote Administration Tools from Microsoft and connect to the SAMBA4 server just as if you would with an AD server. There is also some work done on the SWAT interface but I didn't tested it yet.
If you want to move away from Exchange you can also check Zarafa, an open source implementation of MAPI with some commercial features. Their free version is 100% functional and offers a webmail interfaces pretty much identical to OWA with most of the Exchange groupware features like shar