Mixing Linux & Windows Server in a SMB
-
@cggart said in Mixing Linux & Windows Server in a SMB:
@Dashrender Thanks for the reply. So how does this affect a simple Linux file server?
It isn't a domain controller just present on the domain and using active directory for authentication. Are there any "features" that 2012+ active directory has that will cause issues?
Scott said it was fine, but I just want to understand exactly why.
I'm hesitant to deploy a Linux server into production without knowing for sure that server 2016 has changed something in a protocol or schema that is going to cause major issues...
It doesn't affect member systems.
-
@scottalanmiller said in Mixing Linux & Windows Server in a SMB:
It doesn't affect member systems.
Right, AD has all kinds of extra stuff in it. A member server is just authentication. As long as Linux Samba supports the same authentication protocols you'll be good to go.
-
Thanks guys
I understand the outstanding SAMBA bug doesn't' affect member systems, just replication between DCs.I guess what i'm struggling with, being my first time setting this up and all, is the lack of an official list of supported clients/hosts from either from Microsoft or from the dev teams responsible for the Linux implementation of LDAP, Kerberos, Winbind, SAMBA....
Microsoft does list some supported operating systems for Server 2012 and "later". From which XP was recently removed.
However, I can't find anything on the Linux side other than that SAMBA bug with replication between DCs. I'm just trying to establish why Scott and others are so confident in Linux client support for ALL Windows DC functional levels.
I'm guessing that its either:
-
A ) Client/member support just isn't, and wont be, an issue because the protocols used ( Kerberos, LDAP, and so on) havn't/wont change from version to version of Windows.
-
B ) The devs behind the Linux integration always keep these protocols up to date.
I'm also assuming that you guys, and others, have tested this in production and in the lab and confirmed for yourselves there aren't any issues.
I'm in the process of doing that myself at my home lab. I've just been out of the loop, and am just now catching up. I haven't seen how client support has/hasn't changed over there years which makes me a little wary.
Your two cents would be much appreciated. Sorry for not be more articulate in the first place.
-
-
@cggart said in Mixing Linux & Windows Server in a SMB:
Thanks guys
I understand the outstanding SAMBA bug doesn't' affect member systems, just replication between DCs.Which bug is that?
-
@cggart said in Mixing Linux & Windows Server in a SMB:
However, I can't find anything on the Linux side other than that SAMBA bug with replication between DCs. I'm just trying to establish why Scott and others are so confident in Linux client support for ALL Windows DC functional levels.
Why do you assume a problem? This is how Linux works all day, every day. Literally millions of installations do this constantly. It's not just Linux, it's every non-Windows OS except for Mac (which doesn't work well) uses Samba. There is no "Linux side" here, first of all, it is an application question about Samba, nothing to do with Linux itself. You have no reason to question this, Samba has worked for 17 years without an issue.
And what bug are you referring to?
This is one of those "I've assumed a problem that doesn't exist, now can't find documentation proving that it doesn't." Of course you can't, there is no problem to even be looking for. Why would someone have documentation that says otherwise?
-
@cggart said in Mixing Linux & Windows Server in a SMB:
I'm guessing that its either:
-
A ) Client/member support just isn't, and wont be, an issue because the protocols used ( Kerberos, LDAP, and so on) havn't/wont change from version to version of Windows.
-
B ) The devs behind the Linux integration always keep these protocols up to date.
These are both true.
-
-
@cggart said in Mixing Linux & Windows Server in a SMB:
I'm also assuming that you guys, and others, have tested this in production and in the lab and confirmed for yourselves there aren't any issues.
The entire NAS market depends on this, the degree of testing is pretty extreme.
-
Which bug is that?
I believe it is #11204
"Samba fails to replicate the Windows Server 2012 R2 directory schema (69) from a Windows 2008 R2 DC."
Why do you assume a problem?
I think this is rooted in my inexperience with SAMBA, and not having put in the work to gain confidence first hand. I have a little PTSD from working with open source projects in the past that were poorly tested/supported and issues never appeared until we were well into production. The community was in decline, and we ended up writing our own fixes at great expense, time and money.
However, not all software is created equal and the more research I do I see that SAMBA development has been pretty consistent and adoption/use has been as well. I know M$ has its own share of problems and you are at their mercy to fix the issues.
-
@cggart said in Mixing Linux & Windows Server in a SMB:
Which bug is that?
I believe it is #11204
"Samba fails to replicate the Windows Server 2012 R2 directory schema (69) from a Windows 2008 R2 DC."
There is no replication of Active Directory in a member server. You are ready DC functionality bugs and applying them to something very different. And it is already known that 2012 R2 schema is not an option on Samba, so even if you were doing AD, this bug doesn't exist for Samba today (it's a bug but not for a version that is available yet.)
So nothing to see here.
-
@cggart said in Mixing Linux & Windows Server in a SMB:
I think this is rooted in my inexperience with SAMBA, and not having put in the work to gain confidence first hand.
Inexperience should not make you react negatively to Samba. Samba has a nearly twenty year track record, much of that time beating Windows at its own game. Pre-AD Samba was faster and more stable than Windows for the same tasks. Samba has been the leading file server for Windows for a very long time (until SMB 3 was released.) Samba powers so much enterprise file serving. Feeling like Samba cannot be trusted is like wondering if that new fangled Ford company has ever actually made a working car - ignoring the hundreds of thousands of them on the road every day.
-
@cggart said in Mixing Linux & Windows Server in a SMB:
I have a little PTSD from working with open source projects in the past that were poorly tested/supported and issues never appeared until we were well into production. The community was in decline, and we ended up writing our own fixes at great expense, time and money.
We all have that from closed source projects, too. You should not apply experience from one company or project to another based on source licensing. To make an example, that's like reading one bad book and being wary of all printed literature since all literature is copyrighted. It's just a license, it has nothing to do with the value of the final project. You have to evaluate each project individually and not apply experience from one to another.
Same with closed source. Think of all the crappy closed source, often full of malware, that doesn't work and you have to pay for it. You don't take one little application written by a guy in his basement and then wonder if Microsoft can pull off making Windows just because the two are both closed source, right? They aren't related to each other.
-
@cggart said in Mixing Linux & Windows Server in a SMB:
However, not all software is created equal and the more research I do I see that SAMBA development has been pretty consistent and adoption/use has been as well. I know M$ has its own share of problems and you are at their mercy to fix the issues.
Yes, top enterprise market leaders with decades of experience and track records are generally the best bets that you can make.
-
@scottalanmiller said in Mixing Linux & Windows Server in a SMB:
@cggart said in Mixing Linux & Windows Server in a SMB:
I think this is rooted in my inexperience with SAMBA, and not having put in the work to gain confidence first hand.
Inexperience should not make you react negatively to Samba. Samba has a nearly twenty year track record, much of that time beating Windows at its own game. Pre-AD Samba was faster and more stable than Windows for the same tasks. Samba has been the leading file server for Windows for a very long time (until SMB 3 was released.) Samba powers so much enterprise file serving. Feeling like Samba cannot be trusted is like wondering if that new fangled Ford company has ever actually made a working car - ignoring the hundreds of thousands of them on the road every day.
Sure, but you can't just look out into the world and see millions of servers running Samba like you can walk down a road and see dozen's of Fords. Someone new to the Linux game - how are they suppose to know Samba is what it is other than people like you just telling them, and then over time seeing it more and more, and getting personal experience.
-
I agree, but also understood Scott's point. I should have said "ignorant" instead of "inexperienced". I am both but one doesn't necessarily imply the other. Semantics!
I'm in a better place with this now, and want to say thank you both for being patient and giving the straight dope.
-
Now that 2016 is (finally) out, I have to decide if I want to upgrade my 2003 domain to 2016, or perhaps give Samba a try.
I need a 2016 server anyway, so I might just go with that, but maybe not!
-
@Dashrender said in Mixing Linux & Windows Server in a SMB:
@scottalanmiller said in Mixing Linux & Windows Server in a SMB:
@cggart said in Mixing Linux & Windows Server in a SMB:
I think this is rooted in my inexperience with SAMBA, and not having put in the work to gain confidence first hand.
Inexperience should not make you react negatively to Samba. Samba has a nearly twenty year track record, much of that time beating Windows at its own game. Pre-AD Samba was faster and more stable than Windows for the same tasks. Samba has been the leading file server for Windows for a very long time (until SMB 3 was released.) Samba powers so much enterprise file serving. Feeling like Samba cannot be trusted is like wondering if that new fangled Ford company has ever actually made a working car - ignoring the hundreds of thousands of them on the road every day.
Sure, but you can't just look out into the world and see millions of servers running Samba like you can walk down a road and see dozen's of Fords. Someone new to the Linux game - how are they suppose to know Samba is what it is other than people like you just telling them, and then over time seeing it more and more, and getting personal experience.
Well it should not be new, though. It's been the reference standard for SMB for over a decade. It's not just Linux, but BSD and almost every major NAS device. It was what was used on Mac OSX as well. Samba is everywhere. How do you know to question it? There should not be a reaction of "Windows SMB is good and Samba should be questioned." They should be treated equally until there is a reason not to. Nothing makes the Windows implementation automatically trusted any more than the Samba one, lessso actually as it's on a platform and from a vendor with a worse track record.
Questioning Samba implies questioning the companies that stand behind it like Red Hat and IBM. It's fine to question them, but what makes you question them and not Microsoft when they have the better track record?
-
@Dashrender said in Mixing Linux & Windows Server in a SMB:
how are they suppose to know Samba is what it is other than people like you just telling them.....
So this is an important question. And I think something that I see from time to time is a lack of trusting "the world." And by that, because you know that I think that "what the public does" is normally bad, is that when the world relies on something, you know that it at least works.
Example: NTG had a CEO (who was also a Windows Engineer, bad mix) who was so convinced that Microsoft would screw things up that he fought and fought that the time zones on Windows were just wrong (for major ones, like London.) This is, of course, insane. Windows isn't perfect, but millions and millions of people depend on Windows to have their time together, especially for the world's most important time zone. It's impossible for the whole world to have their clocks wrong and just ignore it and for MS to not have fixed it like in the 1980s. Of course, he was just wrong and it turned out he didn't know timezones. But the underlying problem was that he assumed that the whole world was just ignoring broken time and no computer had the right time and no one was fixing it or talking about it.
Totally unreasonable. Sure, Windows is missing Falkland Island Time, which is ridiculous enough, but it effects like 100 people
Not the entire planet. It was a situation where we should say "hmmm.... this is one of the most important, heavily used applications or systems on the planet with every Fortune 1000 depending on it, every NAS vendor relying on it, almost every business using it... chances are it works. It might not be the best, but it must work or it couldn't drive the world." -
I don't think they are questioning Samba, per se, but the concept that Samba works like Microsoft does.
Right, wrong, or indifferent, people think the gold standard is what Microsoft presents.
-
@BRRABill said in Mixing Linux & Windows Server in a SMB:
Right, wrong, or indifferent, people think the gold standard is what Microsoft presents.
And that's something we need to fix conceptually. Like @dashrender and I were discussing offline... it's like Intel and AMD.
At the end of the day, AMD made the best ever Intel IA32 processors. And then Intel ended up making the best AMD64 processors. They both made the best of the competitor's technology.
The idea that "original" is related to "better" doesn't work in general and especially not in IT. Samba, for most of its history, has been on top. And AD itself is a copy of "Linux originals" if you look at it that way. So you can think of AD as being the copy if you want.
