I still don't get why Samba has to be run in a container

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 :sweat_smile:

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

It’s not virtualization, it’s a Linux container. It’s not a trick, it’s a feature provided by systemd.

As said above, RHEL does not ship DC components.

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

:wink:

[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 :blush: 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… :pensive:

We can’t, this is a Red Hat choice :wink: 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 :smiley:

4 Likes

:joy: and the “eradicate evil” command is

rm -rf /var/lib/machines/nsdc

DISCLAIMER: do not run that command on production server

5 Likes

ARGGGG
DISCLAIMER: do not run that command on production server
Fixed that for you… :stuck_out_tongue:

2 Likes

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.

(copied and pasted from another site)

1 Like

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?

It’s implemented by a systemd-nspawn option: --network-bridge=. The bridge device is required to allow connections

  • to/from the container
  • to/from the host
  • to/from the rest of the network

it is like sharing the physical network interface with the host.

1 Like

[quote=“giacomo, post:15, topic:4878, full:true”]
No, FreeIPA is not conflicting against Samba4: they are two different products with different targets.[/quote]

:joy:
I almost understand :stuck_out_tongue_winking_eye: that Samba4 and FreeIPA are different products.
Well, to be honest, I even understand this pretty well :sunglasses:

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 :blush:

“… Since version 3.0.0, FreeIPA also uses Samba to integrate with Microsoft’s Active Directory by way of Cross Forest Trusts.”

https://en.wikipedia.org/wiki/FreeIPA

================================

" Components
In the picture we can see 5 major components of Samba we are currently interested in:

SMBD
EPMD
The Netlogon/LSA/SAMR daemon(s)
IPASAM
libndr_krb5"

http://www.freeipa.org/page/IPAv3_Architecture

Samba yes, but is it Samba4 ??? :confused:
For sure Fedora is not going to invent yet another SMB emulation :wink:

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”… :sweat:

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…

1 Like

Good point!

EDIT:

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 :wink:
No distribution based on rhel/centos has already a Samba4 solution like our :slight_smile: and we’re almost upstream!
:thumbsup:

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

I don’t think there is a simple way to measure it.
By the way, KVM uses promiscuous mode by default when a VM is bridged to an existing bridge.

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.

7 Likes

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 :loudspeaker: :clap: :loudspeaker: :clap:

3 Likes