Thanks, everyone. Didn't mean to start a big argument, but there is a
definite use case for having Samba (file server) work with idmap_sss.
Also pretty sure a Samba DC doesn't care if a bound computer is using
winbind or sssd, but someone can correct me if I'm wrong.
Lots of people these days are using sssd to bind linux machines to AD;
pretty sure redhat suggests this as well. So in say a typical
environment where most people are running windows bound to an AD they
don't control, your friendly neighborhood linux admin starts binding
linux machines to AD using sssd, since it's just for authentication.
I've been doing this in addition to having a Samba 4.7 file server, and
this is all working perfectly. The Samba 4.7 file server is of course
also bound to the domain by sssd.
But now I have a rather large investment (> 0.7 PB) in filesystems with
POSIX permissions based on sssd-generated UIDs and attempting to change
all those UIDs could be, as they say, "career limiting". Maintaining a
consistent UID mapping is essential.
Now take the above scenario in a group (research, engineers, etc.) where
to date everyone has a linux workstation. Oops, someone wrote a mission
critical program which only runs on Windows and requires 2-4 GPUs*, so
now you have to add a Windows workstation to your collection and a Samba
file server so the Windows machine can access your data (i.e. your NFS
server is now providing cifs service as well). The NFS server is bound
to the domain with sssd because you weren't even thinking about Windows
previously. In many (based on my experience, most) instances where you
have a PC controlling an instrument, the vendor's control software only
runs on windows. You need to be able to transfer data from the control
PC to your linux fileserver serving up this data to linux workstations
for processing and analysis. So again, the fileserver needs to be able
to run Samba while the workstations (and the fileserver) are bound to a
domain using sssd.
I can probably come up with additional examples, but you get the point.
Samba is a player in a ecosystem. Incompatibilities pop up all the time
and you work them out.** That's my life, unfortunately. I should have
stayed in math; the theorems never change, just the fonts used print
them. Huge headache to find out I'm going to have to jump through hoops
to get newer Samba versions to work with sssd on Ubuntu. Would be
awesome if Louis tackled this. If anyone needs to me lay out a bounty to
help facilitate this, just ask or point me to the web page.
There's no question that smbd works seamlessly with winbind and that
using sssd for id mapping is more of a headache; that's irrelevant in
most cases.
* Yes, you could do this using a VM with PCIe passthrough, but that's
still pretty bleeding edge for most people. Way simpler to set this up
bare metal and use Samba for data access. Also, performance.
** The sssd people are very nice and responsive; pretty sure they don't
bite. I talk to them all the time and haven't been bitten once.
On 9/23/21 04:18, L. van Belle via samba wrote:> ... And i trown away my own mail responce on this subject..
>
> Andrew, on this i 100% agree.
> I leave it to that, all im saying for now..
>
> And guys..
>
> Its ok if you, agree to disagree on things..
> but its never worth fighting over it.
>
>
> Greetz,
>
> Louis
>
>
>
>> -----Oorspronkelijk bericht-----
>> Van: samba [mailto:samba-bounces at lists.samba.org] Namens
>> Andrew Bartlett via samba
>> Verzonden: donderdag 23 september 2021 11:04
>> Aan: Ralph Boehme; Rowland Penny; sambalist
>> Onderwerp: [Samba] working well with sssd
>>
>> On Thu, 2021-09-23 at 10:53 +0200, Ralph Boehme via samba wrote:
>>>
>>> There is a real need.
>>>
>>> -slow
>>
>> There is also a real need for us to move past this 'we don't
even try
>> to work with sssd' thing. That is both in terms of working
>> in the code
>> to make this 'just work' as much as can be done, with clear
>> limitations
>> specified, and in the practice on the list when queries come up.
>>
>> sssd has become established in terms of being the AD connector for
>> Linux workstations and servers that don't run Samba. We should
>> congratulate their team for their achievements. We were in the race,
>> but didn't win this time.
>>
>> Shockingly we find that Samba isn't always the centre of the
universe,
>> and sometimes we will need to fit in with the organisational
>> arrangements where 'best for Samba' isn't the primary
criteria. (Just
>> as we exist to help linux systems fit into otherwise windows
>> networks).
>>
>> I would also really love Samba AD to be an even better server to sssd,
>> and while also a code question, moving past this mode of
>> interaction is
>> an important step also.
>>
>> Andrew Bartlett
>> --
>> Andrew Bartlett (he/him) https://samba.org/~abartlet/
>> Samba Team Member (since 2001) https://samba.org
>> Samba Team Lead, Catalyst IT https://catalyst.net.nz/services/samba
>>
>> Samba Development and Support, Catalyst IT - Expert Open Source
>> Solutions
>>
>>
>> --
>> To unsubscribe from this list go to the following URL and read the
>> instructions: https://lists.samba.org/mailman/options/samba
>>
>>
>
>