It depends on what does the word “server” mean here!
A single nethserver machine can run two different Samba servers simultaneously: one for file sharing (provided by the upstream RPM from RHEL), one for the DC operations (the ns-samba RPM I was talking about in the previous post).
Of course, the two roles can be splitted on two distinct machines.
[quote=“davidep, post:29, topic:4865, full:true”]
It depends on what does the word “server” mean here![/quote]
Sure but, joke aside, having to run, on the same hardware, 2 servers, one being VM hosted by the other is only a workaround, trick, call it the way you want.
You could run even 5 servers if needed
[quote]A single nethserver machine can run two different Samba servers simultaneously: one for file sharing (provided by the upstream RPM from RHEL), one for the DC operations (the ns-samba RPM I was talking about in the previous post).
Of course, the two roles can be splitted on two distinct machines.[/quote]
It looks like discussing pure Samba stuff is not enough. Looking at what RHEL provides has an impact too, if I understand well?
(I’m more Debian/Ubuntu aware than RedHat/CentOS)
I know this is not a trick. The trick, or workaround, if you don’t like the “trick” name, is to say "oh no, everything runs on one single server, look at…"
As I wrote, you may even have 5 different containers. At the end, this is (somewhat, I do know what CT is) like having 5 physical different servers, from design viewpoint (or at least mine).
[quote=“davidep, post:31, topic:4865, full:true”]
As said above, RHEL does not ship DC components.[/quote]
Could you explain why?
Is it because Samba4 is bound to Heimdall while Fedora promotes MIT as Kerberos engine?
BTW, I realize, unless I’m totally wrong that Linux platform choice does matter here. If you had to build Debian based NethServer, it would be more flexible because there is nothing like IPA tightly linked to OS.
To me, again feel free to tell me if I’m wrong here, Fedora is extending their “Operating System” scope to additional services. Identity management is part of these “non-OS” services and Fedora choice is clearly FreeIPA.
How do you perceive it?
Is FreeIPA conflicting against Samba4?
I’ve to admit that I’m a bit confused for the time being…
We can’t, this is a Red Hat choice we can only suppose this is due to compatibility issues with many software.
Exactly.
Again, you’re right. RHEL is not pushing Samba 4.
No, FreeIPA is not conflicting against Samba4: they are two different products with different targets.
(In my very personal opinion, I would like to stay away from any MS-related product as much as possible! So, bye bye Samba, FreeIPA you’re welcome!)
I think the response from Davide is very clear: Samba 4 can’t be shipped with CentOS 7 unless you recompile the full Kerberos stack.
Our main goal is to stick with upstream as much as possible.
But our customers ask for AD replacements for ages, and the only tricky, non-invasive way we found is a Samba 4 container. I would describe it as a necessary evil
Samba 4 from the upstream vendor has domain controller support shut off due to the lack of MIT Kerberos support in Samba 4. Details here: https://wiki.samba.org/index.php/MIT_Build
This support is shut off here in the RPM spec file:
%global with_mitkrb5 1
%global with_dc 0
We need to disable mitkrb5 support and enable with_dc. We will also need to tell the spec file to compile all binaries, as this package only compiles nmbd, smbd, and winbind.
I have another question: The container is running on the same subnet as the/a green interface of NethServer. It also needs to have this bridged. WHY?
I mean, if the container is on the same subnet, it is reachable anyway. So, why the need for a bridged connection?
[quote=“giacomo, post:15, topic:4878, full:true”]
No, FreeIPA is not conflicting against Samba4: they are two different products with different targets.[/quote]
I almost understand that Samba4 and FreeIPA are different products.
Well, to be honest, I even understand this pretty well
But if we launch another parallel topic, I’m very prone to discuss this further and explain why, even if from technical view point, these “products” (I would rather say “solutions”) are indeed very different, in term of scope and features, they are quite similar and because of this, Fedora choice is to promote FreeIPA and not implement Samba4 IMHO.
Too much overlap and conflicting services.
At least this is obvious to me but, of course, I might be wrong
Samba yes, but is it Samba4 ???
For sure Fedora is not going to invent yet another SMB emulation
Problem is that Samba wording is quite confusing:
Samba as smbd server: this work with Samba 3 since years
Samba as DC emulator: this implements, e.g. Kerberos. Which one should Fedora keep? MIT or Heimdall ??? Both can’t run in parallel
Same for accounts directory.
What is painful is not SMB/CIFS (although IMHO, SMB is far for being the perfect file access protocol) but account management, request from customers to manage Windows workstations and accounts in the “Microsoft like” way, meaning with Microsoft tools and consol, GPOs etc…
Current open source answer is Samba4. Too bad, it shares the same name.
Therefore, when I say "FreeIPA and Samba4 share conflict of interest, you tell me:
“look at, FreeIPA uses Samba too”…
Problem you currently face, as far as I understand, is not “Samba” but “Samba as DC”, AKA Samba4
Well, I’ll stop here, I definitely don’t know enough of NethServer to have any clever additional comment. Perhaps later…
But Samba AD was implemented beginning with Samba 4.
And everywhere is about AD. I don’t think they talk about AD and Samba with a version of Samba without AD.
Sure! And I think that @davidep and @giacomo have already given great answers here! Hope this will be enough for our curiosity
No distribution based on rhel/centos has already a Samba4 solution like our and we’re almost upstream!
I was wondering: are there any measurable performance penalties in running the Samba 4 container in a VM with promiscuous mode enabled? I mean, especially in comparison with running Samba 4 without a container, in a VM too, but with promiscuous mode disabled.
Thanks,
Salvo
Just for the record, I want to say that I thini discussions like this are extremely important. It gives a greater understanding about the sbject . Not only for simple cummunity members like me, but also to confirm the direction of the implementation of , in this case Samba4 user authentication.
It would be even more valuable if a wikipage is created with a wrapup of the discussion for future reference.
Anyway, all that participated in this discussion: a big thank you!
Btw, please do continue the discussion with new developmens and/or insights. It brings us all on a higher level of understanding and accepting design decissions.
Totally agree with you, I have to admit that Devs have done a great “explanation” work here.
Describing or simplifying complex things isn’t always easy and sometimes they’re already focused on code and solutions, so it’s really hard to find time to give some context to non-experts. Shoutout to you guys! @davidep and @giacomo