Replies: 4 comments 1 reply
-
Correct.
Correct.
Good point.
Yes. The operator will create deployments that in turn create pods that use the samba server image from the samba-container project. We also use the samba-client image and the samba-ad-server image in the integration tests.
Interesting. I don't know a lot about freeradius, but it sounds like it would make use of samba's winbind (maybe NSS too), correct? Currently, the operator is designed to set up Samba member servers but to act as file servers. If you can run freeradius as a seperate pod that communicates with the fileserver that should work no problem. But I suspect that freeradius will need more than that and might require being part of the same pod to function. I'll read up more on freeradius to make a more educated response to this point later.
Understood. We've speculated a bit about having the operator also support DCs, but my focus has been file serving over SMB. It would be interesting to see a design proposal about how we could support DCs. However, I'm personally spread a bit thin at this time and so it would have to come from someone else.
Great questions. Currently we use an emptydir for the Samba state directory. IIRC this is where the tdb file containing the machine account password and join related metadata will be. If the pod moves hosts this data will be lost and will automatically re-run the join process like a new host. However, k8s doesn't wipe out the empyDir in some cases and so I think a restart will reuse the existing state file. However, I haven't tested this yet so test it yourself or filing an issue. Longer term we could create an additional persistent volume to hold state data like this. We already do something similar when the experimental CTDB clustering is enabled. I ask that you could maybe try it out and if you do see issues with this - file and issue and we can make updates to the operator. FWIW, we've tried to make the join process for pods automatic and idempotent. However, this is a relatively young project :-) |
Beta Was this translation helpful? Give feedback.
-
|
One other thought, on the samba mailing list thread where I mentioned this project I noted that the direct use of samba-continer images without the operator was under-documented. One thing you can do is to use the operator as "documentation" by letting it deploy some resources and then studying the resulting deployments/etc. You could then "discard" the operator and create deployments manually, based on what the operator created, tweaking the deployment and other resources for your needs. Note - this is not an excuse for me to skip documenting the samba-container (and sambacc) project. That work is already underway. |
Beta Was this translation helpful? Give feedback.
-
|
Spending some more thoughts on this question.. Afaik, automatic/idem-potent join/re-join can only be achieved by providing domain administrator credentials via K8S. My gut feeling is, that should be avoided, but you may want to get other´s opinion. But then K8S would have to transfer the local persistence of the member between cluster nodes and (for DCs) ensure at most one copy is active. W.r.t. freeradius: afaik there is no dependency to any file server code, only to authentication, and that requires membership (or ldap, but that is kind of limiting authentication options). I suspect freeradius and authentication can be different containers within the same pod, but existing documentation is vague. |
Beta Was this translation helpful? Give feedback.
-
Not necessarily administrator but yes credentials with the rights to join. These creds would be stored in a secret. In production I would encourage people to use a secrets store like vault
Yeah, I'm sure that there are people who wouldn't even want to use secret+vault. In the future we'd like to build automation around the Offline Domain Join (ODJ) feature... but that's a very long outstanding todo.
Unfortunately, I'm not sure what you mean here.
Understood. Regardless, I'd like to read up on it more myself before I go speculating about how it might work in theory. :-D |
Beta Was this translation helpful? Give feedback.
-
|
I’m interested in sponsoring this project if support for DCs is
implemented and maintained.
On Tue, Dec 6, 2022 at 11:42 John Mulligan ***@***.***> wrote:
Spending some more thoughts on this question.. Afaik,
automatic/idem-potent join/re-join can only be achieved by providing domain
administrator credentials via K8S.
Not necessarily administrator but yes credentials with the rights to join.
These creds would be stored in a secret. In production I would encourage
people to use a secrets store like vault
<https://www.hashicorp.com/products/vault>
My gut feeling is, that should be avoided, but you may want to get other´s
opinion
Yeah, I'm sure that there are people who wouldn't even want to use
secret+vault.
It's under-documented but it is optional, of course, then you lose the
automation. If you don't provide the creds you can wait until the pod is
running the must-join container, and then kubectl exec into the container
and run the samba-container join command (which is a wrapper around net ads
join).
In the future we'd like to build automation around the Offline Domain Join
(ODJ) feature... but that's a very long outstanding todo.
But then K8S would have to transfer the local persistence of the member
between cluster nodes and (for DCs) ensure at most one copy is active.
Unfortunately, I'm not sure what you mean here.
W.r.t. freeradius: afaik there is no dependency to any file server code,
only to authentication, and that requires membership (or ldap, but that is
kind of limiting authentication options). I suspect freeradius and
authentication can be different containers within the same pod, but
existing documentation is vague.
Understood. Regardless, I'd like to read up on it more myself before I go
speculating about how it might work in theory. :-D
—
Reply to this email directly, view it on GitHub
<#269 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGE4RB4NAFJGFLAHWGGNWD3WL53HZANCNFSM6AAAAAASVI7SEE>
.
You are receiving this because you are subscribed to this thread.Message
ID:
<samba-in-kubernetes/samba-operator/repo-discussions/269/comments/4325507@
github.com>
--
--
Juan Carrillo
|
Beta Was this translation helpful? Give feedback.
-
I am a newbie interested to try this out.
When I read the readme...
... would be nice to point to a glossary of terms used.
samba-operator is based on samba-container?
I have two use cases in mind, that are not addressed or documented so far:
In both cases I am wondering about what an adequate lifecycle of container vs. membership / DC could look like. Would one join/leave on every spin-up/-down? Then what in case of crashes? Or would one have to manually join/leave?
Joachim
Beta Was this translation helpful? Give feedback.
All reactions