On 10/02/2023 19:02, Andreas Schneider wrote:> On Friday, 10 February 2023 19:00:29 CET Rowland Penny via samba wrote:
>> On 10/02/2023 17:36, Jeremy Allison wrote:
>>> On Fri, Feb 10, 2023 at 08:33:10AM +0000, Rowland Penny via samba
wrote:
>>>> The problem with all this is, Samba does not write or provide
realmd
>>>> or sssd, so how can it fully provide support for them ?
>>>
>>> It's not a matter of providing support, we can (and should)
IMHO
>>> provide basic help on interop with these tools. At the very least,
>>> point people at the web pages where people can get deeper
information.
>>>
>>>> I know some of the Samba team work for red-hat (and have
possibly
>>>> worked on them), but they should be (in my opinion) supporting
Samba
>>>> by saying something like:
>>>>
>>>> Well, yes they will work with Samba, but Samba provides
'net ads join'
>>>> and winbind and that is what is supported here, if you want
support
>>>> for realmd and sssd, you should contact red-hat'.
>>>>
>>>> Or, do you not have faith in the code that is written for Samba
?
>>>
>>> Well as you know, Samba is *always* broken :-). Has been in the
>>> 30+ years I've worked on it, will be for the next 30+ years I
>>> work on it too :-) :-) :-).
>>>
>>> Of course, that's the same for all code, open source or
proprietary :-).
>>>
>>>> I personally will never support realmd or sssd, they appear to
be
>>>> problematical when used with Samba.
>>>
>>> That's fine, just don't answer realmd or sssd-related
questions.
>>>
>>> Let the Red Hat Samba Team members pick up the slack. You don't
>>> need to answer all questions or tell people why you're not
responding
>>> to a question. I ignore people on the list all the time :-).
>>>
>>> How about just ignoring realmd or sssd questions and only answer
>>> net and winbind ones ?
>>>
>>>> The other question that has to be asked is, why do people want
to use
>>>> them over the Samba tools ?
>>>
>>> Sometimes it's not a question of "want". It can come
down to corporate
>>> policy etc. etc.
>>
>> I had already decided that was what I was going to do, just ignore any
>> post that says realmd or sssd.
>>
>> However, It interested me, just what is realmd doing on top of 'net
ads
>> join' ?
>> So I found the source and I now have a question for Andrew Bartlett.
>>
>> A few years ago, I tried to add the ability to samba-tool user to store
>> the next Unix ID's in AD, Andrew shot this down in flames, amongst
the
>> reasons was the fact that I wanted to specify the domain range to use
in
>> AD and hence in smb.conf
>>
>> So Andrew, why do seem to be able to accept realmd, when it does
exactly
>> the same thing, it dictates the ranges that are set in smb.conf ?
>>
>> Having seen the code, I now understand where all those strange smb.conf
>> ranges are coming from and I think someone should tell red-hat that
>> 'idmap uid' and 'idmap gid' were deprecated at 3.6.0 ,
over 10 years ago.
>
> I don't see that realmd is doing anything incorrect,
I never said it was doing anything incorrect, I just said it is using,
in my opinion, strange ranges.
I've just checked the> smb.conf it creates. The maintainer and I work in the same team and we
adjust
> realmd to changes in Samba when needed. The last change was to switch from
-k
> to --use-kerberos for the net command.
Does that mean that it no longer works for Samba versions before the
'-k' change ?
>
> I use 'realm join' every time when I join a machine. It simply
saves a lot of
> time as it does not only join with 'net ads join' but also sets up
PAM, NSS,
> and KRB5.
My problem now is, after reading the realmd code, I realise I had a bash
script for Debian that did what realmd, but better, it actually asked
what idmap backend to use, what range to use etc. I abandoned this when
Andrew didn't like my samba-tool changes because he didn't like the
ranges being sort of set in the python code, something that realmd does.
>
> However realmd is not only used on Red Hat systems but also other
> distributions and if they don't keep it up to date, it isn't our
> responsibility.
Never said it was, but that doesn't really matter if the basic code is
doing things it shouldn't without asking.
>
> Our documentation also states that whatever you do changes you should run
> testparm [1] and I added a lot of checks to testparm that people don't
mess up
> their idmap configurations.
Those changes are very welcome, but it doesn't help when A) Users never
read the smb.conf manpage and B) have never heard of testparm (not
through any fault of Samba).
>
> I had so many bug reports in the past with incorrect idmapping ranges. The
> incorrect ranges didn't come from realmd but customers who did not read
the
> idmap manpages and messed up their configuration.
I am not saying that the ranges in the realmd code are wrong per se, it
is just that I think they are stupid, but that is probably just me.
>
> In the meantime we suggest to
>
> a) Join with 'realm join' (It creates a valid id mapping for the
domain)
Valid to who ?
> b) Always run testparm
> * When you change the config, run testparm.
> * When you update Samba to a newer version, run testparm.
I can heartily agree with all that.
>
> If you look through the documentation for RHEL you will find testparm very
> very often. So since we suggest realm join and running testparm, customer
> cases with incorrect idmapping dropped significantly.
As far as I can see, most of the RHEL documentation is behind a wall, so
I have given up looking.
>
>
> It doesn't help if we point fingers, it helps if we improve tools like
> testparm to detect invalid configurations.
I am not pointing fingers, I just trying to get my point of view across.
>
> I've also changed sosreport to collect `testparm -s`:
>
> https://github.com/sosreport/sos/blob/
> d4f56eeebb277a0c9eb0ef246121edcccb64a8ba/sos/report/plugins/samba.py
You see, there you go, what is 'sosreport', never heard of it before ?
Rowland