Linked by Thom Holwerda on Wed 21st Nov 2007 13:53 UTC, submitted by poundsmack
Sun Solaris, OpenSolaris "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."
Order by: Score:
Samba?
by bsharitt on Wed 21st Nov 2007 14:17 UTC
bsharitt
Member since:
2005-07-07

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.

Reply Score: 2

RE: Samba?
by Luminair on Thu 22nd Nov 2007 01:37 UTC in reply to "Samba?"
Luminair Member since:
2007-03-30

> 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)

Reply Score: 6

RE[2]: Samba?
by eschrock on Thu 22nd Nov 2007 06:26 UTC in reply to "RE: Samba?"
eschrock Member since:
2005-07-07

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.


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.

Reply Score: 5

Samba ?
by Rcoles on Wed 21st Nov 2007 14:21 UTC
Rcoles
Member since:
2006-01-18

What are the advantages/differences of sun's CIFS implementation over Samba ?

Reply Score: 2

RE: Samba ?
by jwwf on Wed 21st Nov 2007 14:34 UTC in reply to "Samba ? "
jwwf Member since:
2006-01-19

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.

Reply Score: 5

RE[2]: Samba ?
by butters on Wed 21st Nov 2007 14:55 UTC in reply to "RE: Samba ? "
butters Member since:
2005-07-08

Samba is all userland.


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.

Now, why the NYT picked up on this, I have no idea.


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...

Reply Score: 6

RE[3]: Samba ?
by Elektronkind on Mon 26th Nov 2007 22:36 UTC in reply to "RE[2]: Samba ? "
Elektronkind Member since:
2006-09-22

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


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.

Reply Score: 1

RE[2]: Samba ?
by superman on Wed 21st Nov 2007 17:57 UTC in reply to "RE: Samba ? "
superman Member since:
2006-08-01

> Samba is all userland.

Not all.
CIFS is all kernellang.

Reply Score: 5

More info
by Matzon on Wed 21st Nov 2007 14:26 UTC
Matzon
Member since:
2005-07-06

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

Reply Score: 4

Not so sure
by jwwf on Wed 21st Nov 2007 14:46 UTC
jwwf
Member since:
2006-01-19

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

Reply Score: 2

RE: Not so sure
by butters on Wed 21st Nov 2007 15:03 UTC in reply to "Not so sure"
butters Member since:
2005-07-08

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.

Reply Score: 4

RE[2]: Not so sure
by elsewhere on Wed 21st Nov 2007 16:11 UTC in reply to "RE: Not so sure"
elsewhere Member since:
2005-07-13

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?

Reply Score: 6

RE[3]: Not so sure
by jwwf on Wed 21st Nov 2007 16:36 UTC in reply to "RE[2]: Not so sure"
jwwf Member since:
2006-01-19

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.

Reply Score: 4

RE[4]: Not so sure
by Flatland_Spider on Thu 22nd Nov 2007 06:02 UTC in reply to "RE[3]: Not so sure"
Flatland_Spider Member since:
2006-09-01

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.

Reply Score: 1

RE[3]: Not so sure
by butters on Wed 21st Nov 2007 17:12 UTC in reply to "RE[2]: Not so sure"
butters Member since:
2005-07-08

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.

Reply Score: 8

RE[3]: Not so sure
by kaiwai on Thu 22nd Nov 2007 06:07 UTC in reply to "RE[2]: Not so sure"
kaiwai Member since:
2005-07-06

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.


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.

Reply Score: 1

RE[2]: Not so sure
by de_wizze on Thu 22nd Nov 2007 18:48 UTC in reply to "RE: Not so sure"
de_wizze Member since:
2005-10-31

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?

Reply Score: 2

RE: Not so sure
by eschrock on Wed 21st Nov 2007 17:45 UTC in reply to "Not so sure"
eschrock Member since:
2005-07-07

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.

Reply Score: 3

RE[2]: Not so sure
by jwwf on Wed 21st Nov 2007 18:07 UTC in reply to "RE: Not so sure"
jwwf Member since:
2006-01-19

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.

Reply Score: 1

X
by Janizary on Wed 21st Nov 2007 16:24 UTC
Janizary
Member since:
2006-03-12

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.

Reply Score: 7

RE: X
by segedunum on Wed 21st Nov 2007 17:43 UTC in reply to "X"
segedunum Member since:
2005-07-06

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!

Reply Score: 2

RE[2]: X
by stephanem on Wed 21st Nov 2007 19:09 UTC in reply to "RE: X"
stephanem Member since:
2006-01-11

> 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

Reply Score: 4

RE[3]: X
by segedunum on Wed 21st Nov 2007 23:51 UTC in reply to "RE[2]: X"
segedunum Member since:
2005-07-06

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.

Reply Score: 4

RE[2]: X
by Janizary on Wed 21st Nov 2007 21:58 UTC in reply to "X"
Janizary Member since:
2006-03-12

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.

Reply Score: 6

RE[3]: X
by segedunum on Wed 21st Nov 2007 23:54 UTC in reply to "RE[2]: X"
segedunum Member since:
2005-07-06

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.

Reply Score: 1

RE[4]: X
by Janizary on Thu 22nd Nov 2007 00:02 UTC in reply to "RE[3]: X"
Janizary Member since:
2006-03-12

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.

Reply Score: 4

v RE[5]: X
by segedunum on Thu 22nd Nov 2007 11:20 UTC in reply to "RE[4]: X"
RE[6]: X
by Janizary on Thu 22nd Nov 2007 12:09 UTC in reply to "RE[5]: X"
Janizary Member since:
2006-03-12

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?

Reply Score: 4

RE[7]: X
by segedunum on Thu 22nd Nov 2007 16:41 UTC in reply to "RE[6]: X"
segedunum Member since:
2005-07-06

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.

Reply Score: 4

RE[8]: X
by jwwf on Thu 22nd Nov 2007 21:34 UTC in reply to "RE[7]: X"
jwwf Member since:
2006-01-19

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.

Reply Score: 2

Kerberos support
by s_groening on Wed 21st Nov 2007 16:42 UTC
s_groening
Member since:
2005-12-13

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!

Reply Score: 4

RE: Kerberos support
by segedunum on Wed 21st Nov 2007 17:46 UTC in reply to "Kerberos support"
segedunum Member since:
2005-07-06

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.

Reply Score: 5

RE[2]: Kerberos support
by s_groening on Thu 22nd Nov 2007 14:13 UTC in reply to "RE: Kerberos support"
s_groening Member since:
2005-12-13

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 ...

Reply Score: 2

RE[3]: Kerberos support
by segedunum on Thu 22nd Nov 2007 15:26 UTC in reply to "RE[2]: Kerberos support"
segedunum Member since:
2005-07-06

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?

Reply Score: 3

RE[4]: Kerberos support
by s_groening on Sat 24th Nov 2007 16:48 UTC in reply to "RE[3]: Kerberos support"
s_groening Member since:
2005-12-13

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.

Reply Score: 1

Kernel???
by Don T. Bothers on Wed 21st Nov 2007 16:49 UTC
Don T. Bothers
Member since:
2006-03-15

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?

Reply Score: 1

RE: Kernel???
by Wes Felter on Wed 21st Nov 2007 19:20 UTC in reply to "Kernel???"
Wes Felter Member since:
2005-11-15

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.

Reply Score: 6