Submitted by “File-sharing between Windows and Sun’s OpenSolaris Unix platform is being bolstered through two projects at Sun. The OpenSolaris project: CIFS Server features server software source code that implements the CIFS protocol also known as Server Message Block, the standard for Windows file-sharing services, Sun said. The internal CIFS server enables Microsoft users to store and retrieve files on an OpenSolaris system, Sun said. This project and a related effort, CIFS client, improve the usefulness of OpenSolaris in data environments that serve NFS and CIFS clients, Sun said. Sun recently donated server source code that implements CIFS to the OpenSolaris Project.”
Being the New York Times, the article is a little short on technical details, so how is this different from Samba? If it’s better, what are the chances we’ll see it trickle down to other open source operating systems.
> so how is this different from Samba?
I’ve read a bit about it, and as far as the administrator is concerned, it is quite different. The service is managed in totally different ways, and it affects OpenSolaris systems in different ways.
Basically it is managed with existing generic opensolaris tools and is compatible and inter-operates with existing opensolaris systems. So you use a “share” command with a couple options to share your ZFS file system. That configuration might even be portable with the zfs pool… I haven’t been able to nail that down yet.
This stuff is really new so there isn’t much documentation or discussion out there. As of today:
A preliminary draft of System Administration Guide: Windows Interoperability for the Solaris OS will be available in the near future on the Solaris CIFS server project page at OpenSolaris.org (available soon)
Yes, ZFS supports the ‘sharesmb’ option. So you can say ‘zfs set sharesmb=name=FOO pool/my/filesystem’ and have the filesystem shared as ‘FOO’ under windows. This is basically the same as the ‘sharenfs’ property today, and can be inherited within the ZFS filesystem hierarchy.
What are the advantages/differences of sun’s CIFS implementation over Samba ?
What are the advantages/differences of sun’s CIFS implementation over Samba ?
One difference is that it is in kernel. Samba is all userland. The blog post above promises better integration with the rest of the OS and I would expect it to be faster once it matures (or now, who knows).
Now, why the NYT picked up on this, I have no idea.
Yes, the Samba package is purely userspace, but it requires native kernel support at the VFS and FS levels.
Additionally, it’s unclear that an in-kernel implementation of a network filesystem and transfer protocol is a great idea in the long-run. The trend these days tends to be toward pushing unnecessary functionality into userspace.
It’s an IDG thing. There are probably contractual obligations. Media collusion is a Good Thing(TM)…
Notice that all three sentences in the second paragraph end with “Sun said”. Outstanding journalism…
NFS is and has been in-kernel in almost every OS its been implemented on. In-kernel network file systems is certainly not a new thing.
> Samba is all userland.
Not all.
CIFS is all kernellang.
much more info on the blog:
http://blogs.sun.com/amw/entry/cifs_in_solaris
“We already had the basic CIFS service building on Solaris but it took another 8 months, 22 more ARC cases, a lot of helping hands and many late nights to deliver the project. On October 25th, 2007, the CIFS service project putback over 800 files, approximately 370,000 lines of code (including 180,000 lines of new code) to the Solaris operating system. ”
Edited 2007-11-21 14:26
What I am not so sure about here, though, is whether this is a good idea. Is in-kernel CIFS by adding hundreds of thousands of lines of code to the kernel worth the risk? My first instinct is no, but I guess we have to wait and see.
The comments section of the blog posted above:
http://blogs.sun.com/amw/entry/cifs_in_solaris
contains comments from a Samba contributor, and while some of it is the usual open source sour grapes, some of it is a reasonable questioning of this. If the throughput is much better, that will be great, but this had better not break stuff…CIFS just isn’t that compelling a feature.
Edited 2007-11-21 14:47
Blog comment:
Hi Alan,
Of course, as you well know (because we’ve spoken to Sun and asked for this many, many times in the past) that all of the advantages of being “a first-class citizen of the Solaris operating system” could also trivially be available to Samba, and I hope that you’ll expose the user-space API’s in order to allow us to take advantage of them.
Linux has already done this – exposing the file lease API for oplocks, inotify for change notify etc. Solaris could expand on this by giving us access to atomic NT-ACL create, NTFS stream support, the ability to push SID credentials into the system from winbindd and attach to a process etc. We already support case-insensitive filesystems of course.
In fact you could have helped us put these things trivially into Samba, and thus shared the implementation burden, rather than re-inventing everything and pushing a rather large and dangerous protocol into your kernel – something I think you might come to regret later on.
I’m looking forward to seeing the docs for all the user-space API’s that will allow Samba to take advantage of these cool new features in Solaris – in fact if you want to work with us on adding this code into Samba I’d be happy to help.
Cheers,
Jeremy Allison,
Samba Team.
Essentially, Linux exposes richer APIs that allow Samba to implement a much more seamless SMB/CIFS experience on Linux than on Solaris. The functional problem isn’t that Samba is limited so much as that Samba on Solaris is limited. The business problem is that Samba is too close to Red Hat and IBM.
Is that really an issue? Jeremy Allison works for Google, who is close to Sun. If anything, I’d suspect that Jeremy’s aggressive GPL support may be more of a concern, no? I realize userspace licensing is irrelevant to the kernel licensing, but I always felt that Jeremy’s near-immediate transition to v3 following his “dramatic” departure from Novell might cause hiccups in support from commercial organizations, given samba’s ubiquitousness in servers and network appliances.
Anyways, not looking for a licensing debate, I’m just not sure I see the competitive concern with RH and IBM?
Is that really an issue? Jeremy Allison works for Google, who is close to Sun. If anything, I’d suspect that Jeremy’s aggressive GPL support may be more of a concern, no? I realize userspace licensing is irrelevant to the kernel licensing, but I always felt that Jeremy’s near-immediate transition to v3 following his “dramatic” departure from Novell might cause hiccups in support from commercial organizations, given samba’s ubiquitousness in servers and network appliances.
Anyways, not looking for a licensing debate, I’m just not sure I see the competitive concern with RH and IBM?
I don’t really know, and while I am tempted to not let that get in the way of some good opining (this being the internet and all), I’ll show restraint.
However, to me, this move does make sense in the specific context of Sun’s Fishworks, which seems kind of amorphous so far but (as far as I can tell) seems to be a project to make Solaris “as good” a NAS platform as NetApp’s Data ONTAP. ONTAP, of course, does pretty much all of its NAS protocols in kernel. Of course that does not mean it is the best or only way, but it is one reasonable way.
Fishworks predates the famous lawsuit by quite a bit but couldn’t have helped the two companies’ relations. I for one would be thrilled to see something that has many NetApp qualities but conveniently omits the ridiculous pricing and IBM mainframe style proprietary-ness.
I think you’re absolutely right on the money.
My first reaction to this was to ask why they just didn’t add code to samba, and then to speculated that they only did this to avoid using GPL code.
After reading you’re post it only makes sense for them to add CIF support so they can position Solaris to be used in a network appliance context. First they have ZFS which is designed to manage large disk arrays, and now they add CIF to the list of network filesystem protocols Solaris supports. This just allows them to integrate CIF more closely with their current offerings by just having an API to call rather then a different program.
Ideological Silicon Valley is a small place. The worst of enemies are frequently seen leaving the club arm-in-arm. The super-complex IBM/Sun relationship is the premier example.
I don’t think that licensing is an issue here. Sun isn’t anti-GPL. They use it whenever they want the Linux community to adopt their technology (OpenJDK), and they don’t use it when they don’t want the Linux community to adopt their technology but want to avoid this perception (ZFS and DTrace). They couldn’t care less how Samba is licensed because it isn’t their technology.
Which brings me to the underlying issue here, which is Sun’s NIH syndrome. If they wanted to work with Samba to reach feature parity with Linux, the Samba team would probably propose that Sun closely replicate the APIs they use on Linux. Sun doesn’t want a third-party userspace project dictating their core kernel architecture, and understandably so.
If their kernel isn’t providing the necessary hooks for such projects to meet customer requirements, then they need to bring the responsibility for these requirements in-house. This was a simple matter of deciding that developing a homegrown solution on their own terms was preferable to the compromising their design to fully leverage existing free software projects.
It is, like everything in software development, a trade-off. I think that the key will be the relative degrees of success of the two projects in reaching the ultimate goal of Active Directory Domain Controller functionality. Now it’s a race between Sun and Samba/Linux to provide a fully-capable *nix server solution optimized for Microsoft environments.
The licencing issue would have less to do with Sun than it does with companies they do business with. In the case of Sun, they have a licencing and technology sharing agreement with Microsoft. Part of that agreement might have required Sun to implement the CIFS/SMD protocol (and Microsoft changes) under a non-GPL licence.
At the end of the day, I assume that 8 months worth of talking, they’ve come to the conclusion that inclusion into the base system is a good move. Btw, lets remember that IIRC it uses a large amount of code from Apple’s down CIFS implementation, so it isn’t going to cause problems, as the letter someone quoted in the earlier post.
Could this have anything to do with Patent claim avoidance? Or are they just taking a different approach; one that affords more far reaching compatibility gains?
What I am not so sure about here, though, is whether this is a good idea. Is in-kernel CIFS by adding hundreds of thousands of lines of code to the kernel worth the risk? My first instinct is no, but I guess we have to wait and see.
It’s worth noting that not all of the CIFS code lives in the kernel. The performance sensitive pieces and those need to interact directly with the underlying FS is in the kernel, while the annoying complicated parts (MLRPC, identity mapping, etc) is implemented in userland with door calls between the two.
What I am not so sure about here, though, is whether this is a good idea. Is in-kernel CIFS by adding hundreds of thousands of lines of code to the kernel worth the risk? My first instinct is no, but I guess we have to wait and see.
It’s worth noting that not all of the CIFS code lives in the kernel. The performance sensitive pieces and those need to interact directly with the underlying FS is in the kernel, while the annoying complicated parts (MLRPC, identity mapping, etc) is implemented in userland with door calls between the two.
You are right. A reading comprehension slip up on my part.
I am amazed a developer like Jeremy would pretty much troll Sun’s workers’ blogs like that. Afterall, what a business does with it’s own damned money is, of course, it’s own damned business.
Jeremy’s actions are akin to Theo de Raadt going onto Linus’ blog about Linux development and telling him he should stop Linux work and begin working with OpenBSD so that they can, “cooperate and share in the creation of this rather than trying to build everything themselves.” It’s a matter of Sun not thinking Samba is doing the job Sun wants done.
I am amazed a developer like Jeremy would pretty much troll Sun’s workers’ blogs like that. Afterall, what a business does with it’s own damned money is, of course, it’s own damned business.
Let’s get real about this. People using Solaris, and every one I have ever known, has been using Samba for Windows file and print sharing, even if they’ve compiled and installed it themselves.
What Sun are doing is simply going on their own merry little way of making things just as hard for people using Solaris by not reusing existing work. This will have repercussions in terms of replicating all the associated technology around CIFS, and that’s something Samba is already doing. Yer, Sun: The company that gets open source development!
> Yer, Sun: The company that gets open source development!
Samba is designed by dissembling the CIFS protocol – you can never use that product knowing that Microsoft could sue you.
Sun is using published CIFS specs and relying on their settlement with MS and also MS opening up protocols per the EU settlement – that IMHO is a cleaner solution.
Plus, anything in kernel space works 1000x faster and better than user space. If you think user space is good for filesystems I dare you to trust putting your datacenter on userspace ZFS developed for Linux
Edited 2007-11-21 19:09
Samba is designed by dissembling the CIFS protocol – you can never use that product knowing that Microsoft could sue you.
On the contrary. That’s what protects Samba in a whole lot of ways. If someone can say “Oh, you’re adhering to this so you are subject to this agreement” then that’s different.
Sun is using published CIFS specs and relying on their settlement with MS and also MS opening up protocols per the EU settlement – that IMHO is a cleaner solution.
Samba has always been the cleaner solution because they’ve had to understand how it all works from scratch. There’s a lot of layers of crap in windows networking. I’m also not aware of MS opening any protocols that have anything but onerous licensing.
Plus, anything in kernel space works 1000x faster and better than user space
As Jeremy Allison said, Linux has the right kernel APIs for Samba to use. Also, saying that kernel space is faster than user space is extremely simplistic.
If you think user space is good for filesystems I dare you to trust putting your datacenter on userspace ZFS developed for Linux
Well, I’m not going to, am I? Not until Sun comes up with a compatible license, or relinquishes its patents that makes an implementation in Linux possible.
Not everyone is willing to accept the GPL just to save a few grand, especially when the intent is to make many more grand. Were Samba a MIT codebase, the bits which the Solaris codebase could use would be nice for Sun, but since Sun intends to integrate the code into their kernel, it’s not possible. The choice is between using Samba and being forced to GPL their kernel, or making their own CIFS implementation and keeping their kernel the way they want it.
Since Sun chose not to GPL Solaris already, it’s easy to see a reason for their not selecting integrating Samba into their kernel.
Sun likes integrated solutions in it’s products, Samba doesn’t do that – a part of this is it’s portability, a part of that is it’s userland basis, and a part of that is it’s licence. C’est la vie.
Were Samba a MIT codebase, the bits which the Solaris codebase could use would be nice for Sun, but since Sun intends to integrate the code into their kernel, it’s not possible.
You have heard of userspace and kernelspace separation, right, as Jeremy Allison has talked about getting APIs into Solaris’ kernel for Samba?
Sun likes integrated solutions in it’s products
I’m trying to contain my laughter as I read that, but I can’t.
It doesn’t matter what I’ve heard of, the fact is Jeremy has nothing to do with what Sun is actually doing. The integrated CIFS implementation is what Sun is doing, they like cramming shit into their kernel, that’s their call. You don’t get a say in the matter.
It doesn’t matter what I’ve heard of, the fact is Jeremy has nothing to do with what Sun is actually doing.
Hang on sweetheart. You’re telling me Sun is doing this because they want to integrate code into their own kernel, as well as the usual, well worked licensing arguments, and I’ve pointed out that those are simply bogus. That’s all.
The integrated CIFS implementation is what Sun is doing, they like cramming shit into their kernel, that’s their call. You don’t get a say in the matter.
I don’t care. However, I do get to point out that Sun are stupid and wrong, and I don’t see anything around here that convinces me otherwise. There is no possible reason for not reusing Samba, but whatever, it’s their funeral.
You’re ignoring the previously made statements, there are reasons to ignore the previous implementation, but only one need be said. Samba’s code is not usable. It doesn’t get any clearer. The code Samba has cannot be used for what Sun wants, so Sun isn’t using it. Must I add, “doy,” in this post to attempt a strong suggestion that this should be obvious?
You’re ignoring the previously made statements, there are reasons to ignore the previous implementation, but only one need be said. Samba’s code is not usable.
Why? You’re not answering the counter arguments. Saying it doesn’t justify it in any way – it doesn’t get clearer than that.
1. There are no licensing concerns at all with respect to the kernel. This is why kernel/user space separation works, and Samba/Linux have done it. Most existing Solaris customers use Samba, with or without Sun’s help, and have done for years. SMB and CIFS on non-Windows platforms is nothing new.
2. The kernel arguments don’t stand up. Linux has managed to come up with many kernel extensions that Samba uses very successfully today. Sun have never managed to do that, even after all these years.
3. Putting CIFS, and not only that, but the entire stack of interoperability stuff such as NTLM, Kerberos and Active Directory support into your kernel is pretty unwise. Sun will simply be dragged into doing this, because one thing leads on to another – and Samba is already doing it. It’s an awful and sometimes dangerous protocol stack, and the only reason we have anything to do with it is because of Windows interoperability. There’s an awful lot more to it than CIFS. In fact, adding this lot to a kernel is downright insane.
The code Samba has cannot be used for what Sun wants
Why? Folding your arms and sulking and saying “Sun’s doing this regardless” does not justify saying that Samba cannot be used.
Must I add, “doy,” in this post to attempt a strong suggestion that this should be obvious?
Because it isn’t obvious, and saying that it is doesn’t make it true without some justification.
I mean, I have absolutely no problem at all with Sun going off, doing their own thing and making their own choices and implementation. None whatsoever. That’s their choice.
However, let’s not pretend for a second that there are any real, legitimate reasons whatsoever for doing this. It’s just a pointless waste of effort to come up with yet another implementation of, not a standard, but a reverse engineered proprietary set of protocols that sets the open source world back in terms of interoperability.
Sun are doing this because it’s all about control. That’s why.
I mean, I have absolutely no problem at all with Sun going off, doing their own thing and making their own choices and implementation. None whatsoever. That’s their choice.
However, let’s not pretend for a second that there are any real, legitimate reasons whatsoever for doing this. It’s just a pointless waste of effort to come up with yet another implementation of, not a standard, but a reverse engineered proprietary set of protocols that sets the open source world back in terms of interoperability.
Sun are doing this because it’s all about control. That’s why.
Reverse engineered–do you know this for a fact, or are you just speculating? Sun does have the luxury of licensing agreements that Samba does not, and there are non-MS written but MS licensed implementations out there (NetApp, one that ships–or used to–with HP-UX, etc).
Also, why is control not a legitimate reason? From a certain point of view, the Allison “protest” departure from Novell, the Tridgell BitKeeper fiasco, the quick GPL3 turnaround, etc might make one wonder if “control” by cooler heads wouldn’t be desirable, after all.
Reverse engineered–do you know this for a fact, or are you just speculating?
I’m not entirely sure where you’re quoting this from, but Samba is reverse engineered largely.
Sun does have the luxury of licensing agreements that Samba does not, and there are non-MS written but MS licensed implementations out there (NetApp, one that ships–or used to–with HP-UX, etc).
Just because they’re licensed it doesn’t mean they’re any good. Besides, most of them reuse Samba anyway.
Also, why is control not a legitimate reason? From a certain point of view, the Allison “protest” departure from Novell, the Tridgell BitKeeper fiasco, the quick GPL3 turnaround, etc might make one wonder if “control” by cooler heads wouldn’t be desirable, after all.
Sorry, but based on past history I wouldn’t call Sun a cooler head. Samba has been around for a very, very, very long time, and its ability to do what it does hasn’t been changed by other events.
I’m not entirely sure where you’re quoting this from, but Samba is reverse engineered largely.
I am quoting it from the third line I posted above it, in which you seem to say that the Sun implementation is reverse engineered. That’s why I bothered to quote it, so that you would not be confused. My question was, how do you know the Sun implementation is all reverse engineered?
Just because they’re licensed it doesn’t mean they’re any good. Besides, most of them reuse Samba anyway.
Yes, but it may mean they are not reverse engineered. And do you have proof that the implementations I mentioned are based on Samba? Neither of them are GPL, as far as I know.
Sorry, but based on past history I wouldn’t call Sun a cooler head. Samba has been around for a very, very, very long time, and its ability to do what it does hasn’t been changed by other events.
Irrelevant to my question. I asked you to explain why control is not “a legitimate reason” for Sun to do this; previously you stated that it was not.
Edit: grammar.
Edited 2007-11-23 15:53
There might be one very nice advantage from implementing SMB/Cifs in the way that Sun does, that is by not using Samba, with this advantage being SMB/Cifs single sign-on in a pure Unix environment, which is not possible with Samba (v.3.0.xx), since it requires a Windows Kerberos KDC as found as part of Microsoft’s Active Directory to function. Since it’s essentially just another protocol, any existing authentication method supported by Open Solaris should work like a charm once it’s compiled against the gssapi libs!
Basically, I find this issue to be a drawback in respect to Samba, since it really makes you dependent on Microsoft server software in order to achieve true Kerberos based single sign-on.
To me, this is what Samba should be all about – seamless integration (no matter the server platform) to give the best possible client experience! I understand that Samba 4 will be a complete reimplementation of Samba to contain these functionalities, which is great!
There might be one very nice advantage from implementing SMB/Cifs in the way that Sun does, that is by not using Samba, with this advantage being SMB/Cifs single sign-on in a pure Unix environment, which is not possible with Samba (v.3.0.xx), since it requires a Windows Kerberos KDC as found as part of Microsoft’s Active Directory to function.
What on Earth do you think Samba is doing now? I fail to see how reproducing that work is going to help. Oh, and if you’ve got Unix on the server and Unix on the client then there are umpteen better ways you can implement single sign-on than using Windows technology, without Windows even being involved.
I know this is true, but if you deploy a Unix based server setup with mixed clients (Unix/Linux + Windows), single sign-on in respect to Samba 3 based SMB/Cifs is not possible!
I agree that there are better ways to implement a single sign-on environment in a true Unix/Linux, however, this leaves out SMB/Cifs on Windows clients, which is a shame … And that might change with Sun’s efforts to bring SMB/Cifs to Solaris and Open Solaris, whether or not this somewhat redundant work might seem odd to many.
Btw, I guess a lot of people would argue that had an effort like this provided e.g. Linux with better SMB/Cifs support, it’d be worth it every step of the way …
I know this is true, but if you deploy a Unix based server setup with mixed clients (Unix/Linux + Windows), single sign-on in respect to Samba 3 based SMB/Cifs is not possible!
Why would this not be possible if you’re running Unix based servers running Samba?
Samba 3 doesn’t do true gssapi but instead it uses a sort of pass through method of authentication based on the server being bound to an Active Directory domain controller for Kerberos to work. Because of this, a Unix only ticket based setup will not work for Samba.
I don’t get why Sun would put CIFS in the kernel? Is NFS in the kernel too? I don’t really care about the SAMBA versus Sun thing. To me, it is just why would Sun do that?
Yes, NFS and many other filesystems are in the kernel. But this is Solaris we’re talking about; it already has SSL and a Web cache (NL7C) in the kernel.