Re: [ceph-users] Re: Call for Interest: Managed SMB Protocol Support

On Friday, March 22, 2024 2:56:22 PM EDT Alexander E. Patrakov wrote: In the immediate future the plan is to have a very simple, fairly "opinionated" idmapping scheme based on the autorid backend. Sharing the same directories over both NFS and SMB at the same time, also known as "multi-protocol", is not planned for now, however we're all aware that there's often a demand for this feature and we're aware of the complexity it brings. I expect we'll work on that at some point but not initially. Similarly, sharing the same directories over a SMB share and directly on a cephfs mount won't be blocked but we won't recommend it. I agree - our initial use case is something along the lines: Users of a Ceph Cluster that have Windows systems, Mac systems, or appliances that are joined to an existing AD but are not currently interoperating with the Ceph cluster. I expect to add some idpapping configuration and agility down the line, especially supporting some form of rfc2307 idmapping (where unix IDs are stored in AD). But those who already have idmapping schemes and samba accessing ceph will probably need to just continue using the existing setups as we don't have an immediate plan for migrating those users. This is pretty close to our initial plan but I'm not clear why you'd think that "workstations get different UIDs and GIDs". For all systems acessing the (same) ceph cluster the id mapping should be consistent. You did make me consider multi-cluster use cases with something like cephfs volume mirroring - that's something that I hadn't thought of before *but* using an algorithmic mapping backend like autorid (and testing) I think we're mostly OK there. Unfortunately, I don't really understand this item. Fortunately, you say it was only considered not implemented. :-) Some times known as the "drop-box" use case I think (not to be confused with the cloud app of a similar name). We could probably implement something like that as an option but I had not considered it before. This is oh so similar to a project I worked on prior to working with Ceph. I think we'll need to do this one eventually but maybe not this year. One nice side-effect of running in containers is that the low-id number is less of an issue because the ids only matter within the container context (and only then if using the kernel file system access methods). We have much more flexibility with IDs in a container. See above. For now, we're only planning to do idmapping with winbind and AD. We'd probably only consider non-AD ldap and/or ssd if there was strong and loud demand for it. I hope I covered the above with some inline replies. This was great food for thought and at just the right level of technical detail. So thank you very much for replying, this is exactly the kind of discussion I want to have now where the design is still young and flexible. One other cool thing I plan on doing is supporting multiple samba containers running on the same cluster (even the same node if I can wrangle the network properly). So one could in fact have completely different domain joins and/or configurations. While I wouldn't suggest anyone run a whole lot of different configurations on the same cluster - this idea already allows for some level of agility between schemes. Later on we might be able to use that as a building block for migration tools, either from an existing samba setup or between configurations. Also, I plan on adding `global_custom_options` and `share_custom_options` for special overrides for development, qa, and experimentation but those are strongly within the "you break it, you bought it" realm. But these could be used for experimenting with idmapping schemes without having them all baked into the smb mgr module code. Thanks for the discussion! --John M.