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

Howto FAQ
1

[quote=“salvois, post:12, topic:4865, full:true”]
As a side note, I still don’t get why Samba has to be run in a container. [/quote]

I fully share. I’m discovering Nethserver I can’t yet figure out why such constraint, design choice or whatever reason behind this.
However I’m very far from having read lot of documentation or forum yet.

Nevertheless, it looks very strange too me :open_mouth:

I even don’t understand what could be the added value :blush: Well, I do understand that POSIX ACL won’t work. OK, fine, what does it really mean? I mean in real deployment scenario?

It doesn’t mean DC as a container but means two Samba deployments, one acting as DC and the other as files sharing server, joining domain exposed by DC. Is it what NS provides? (I didn’t work back, hands on, on my broken NS server yet, trying for the time being to understand the logic behind its general design)

Comment from Samba team on this specific topic:

[quote]The default file server in Samba 4.0 is our smbd file server from Samba
3.x, simply updated with the latest work from that line of
development.

No matter if you are running an AD DC, or a file server as a member
server, we use the same code for file server operations. However, some
support infrastructure varies between the operating modes, and some
options are forced on in the AD DC, so as to emulate NT ACLs in the way
we must for the SYSVOL share. We also use a different winbind
implementation.

For smaller sites, where there is just one server, using the AD DC as
the file server is perfectly fine and supported. It will work well.

For other (generally larger) sites, the knowledge that the file server
and DC can be configured, upgraded and replicated independently will be
far more important, and so follow our advise to separate these roles.
Andrew Bartlett[/quote]

4 Likes
2

For other (generally larger) sites, the knowledge that the file server
and DC can be configured, upgraded and replicated independently will be
far more important, and so follow our advise to separate these roles.
Andrew Bartlett

For such a scenario, my personal preference would be installing a very separate machine as a file server, then.

1 Like
3

And 2 different DC isn’t? :sunglasses:

(meaning 3 servers)

4

And 2 different DC isn’t?

Uh? No, I meant that my choice would be: for “small sites”, single instance of Samba running both the DC and file server on the same machine (it just works to me); for “larger sites”, single instance of Samba running the DC, or perhaps a file server too, on a machine, and -if needed- a separate machine acting only as a file server joined to that domain -this, too, if needed-.

What I meant is that I found (and still find, with the information I currently have) surprising that the distribution creates a second Samba instance without giving me choice.

Anyway, I’m writing this because provisioning the DC was, in my mind, the easiest part in my previous tests, before trying Nethserver! :blush:

5

Same here.
NS is the very first platform I discover with such approach.

What I meant is that for large® sites, one single DC is perhaps not the best choice.
Once you have configured all your clients to authenticate against Windows domain (of even Kerberos realm), providing one single source (server) for such authentication will become an nightmare the day your authentication server is not up and running. That’s the reason why backup DC is more than suitable, I would say mandatory :wink:

2 Likes
6

We read above the statements from Microsoft and Samba. Another point is RHEL does not ship the DC components with samba RPMs.

Sernet RPMs were no longer available for free, since this spring.

The container solution (systemd-nspawn, a “chroot with steroids”) was the simplest way to install a third-party RPM that depends on Heimdal Kerberos without modifying the existing file server configuration too much. Indeed it reduced the size of our code a lot!

The third-party RPM actually is a vanilla compilation of Samba sources.

6 Likes
7

Maybe it would be an idea to give some more background information on the choice of running Samba in a container. And what kind of container this is.
Also some information what options and/or restraints this give compared to a situation where Samba is installed on the server itself.
I think for most members introducing Samba4 is a complete different ballgame and a clear explanation would change the level of questions towards a more technical level.
I think there is a need to know what is possible and what is not possible. For now it just looks (anyways to me it does) like an extremely complex scenario to introduce Samba4.

3 Likes
8

I tried to summarize the main points in the previous post. I would be happy to help on more specific questions!

I think the most important point is authentication on smb shares and has been discussed here:

We’re still working on provisioning a DC from an existing AD domain, and upgrading an old NT-PDC.

I agree with @robb, we need a clear documentation to help newcomers!

1 Like
9

From a end-user perspective, this “Samba vs. OpenLDAP” should not be a debate.
I do understand (quite well :wink:) that under the hood, this is not transparent and implementation does matter but challenge here is to find a way to deploy services on top of core server without having to deal with complex choices and specific deployment like container to support additional box in the box.

Furthermore, although this statement is correct, I don’t fully share the view:

Samba 3 does offer file sharing :wink: I would even go one step further: as already discussed, Samba 4 focuses on DC, not on file sharing itself. If I understand well (I’m still not 100% sure about this), NS implementation requires 2 different Samba servers if you want both file sharing and DC.

Which means that trigger is not “file sharing” but DC and this leads me to this point:
debate is, before deployment, to understand whether Windows domain emulation is required or not.
And Windows domain emulation brings Kerberos (yes KRB can be deployed without Windows :stuck_out_tongue_winking_eye:) thus workstations authenticating against Windows domain (Windows pro) thus benefit from SSO thus can easily access Samba 4 LDAP.

Other design are achievable:

  • Samba 4 AD with anonymous bind allowed
  • Samba 4 AD with file sharing + OpenLDAP running on same server

From my perspective, the real challenge is to define flexible strategy for the core server. I understand this is not easy for NethServer because it looks like everything can be installed as a module but such approach seems to have side effect, if I understand well.

10

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.

11

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

12

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.

13

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:

14

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

15

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
16

… :joy: and the “eradicate evil” command is

rm -rf /var/lib/machines/nsdc

DISCLAIMER: do not run that command on production server

5 Likes
17

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

2 Likes
18

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
19

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?

20

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