I am VERY happy to see this discussion. I literally cringe every time someone
asks a sssd question because of the hostility toward sssd they are about to at
least perceive.
I have never understood why sssd seems to be singled out for
"hands-off" treatment by the SAMBA crew. Is accommodating sssd really
any different than working with bind9 or time or ntp? How about integrations
with things like pfsense, where the ability to install the ideal software on a
stand-alone hardware system may be more constrained?
I think it is also very important to note that when people are asking questions
about sssd and SAMBA, it is very often the case that other considerations
required sssd AND the integration with SAMBA is for the environment of concern
very difficult. This sounds exactly like the the type of issue that this list
should address. It is clear that there is a wealth of knowledge here about the
problems that arise ... any why. If not this list to help solve or work around
those problems, to help make SAMBA work with sssd to solve the user's real
problem (usually one of preserving existing and difficult or expensive to change
environments), then WHO SHOULD? Perhaps it is the case that BOTH this list and
lists for sssd (as well as other products, as the case may be) should be worked
with concurrently, but I cannot fathom why the user with a (urgent, critical,
real world ...) problem should be forced to solve it without also being able to
freely and with welcome arms tap the knowledge of the people who know SAMBA
best.
I think it is fine, if the user desires, to discuss alternatives that may be
more suitable. I do not think that should be the starting point, or worse the
default position, which should be to help find a way to make a system run or,
more critically, get a broken system back up and running.
Easy problems, although often important, are a bit boring. We should embrace the
hard problems, and take pride in a job well done making the
"impossible" possible.
Just my take, as an otherwise fly on the wall but daily observer if this list.
On Thursday, September 23, 2021, 04:04:47 AM CDT, Andrew Bartlett via samba
<samba at lists.samba.org> wrote:
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
On Thu, Sep 23, 2021 at 2:36 PM Billy Bob via samba <samba at lists.samba.org> wrote:> I am VERY happy to see this discussion. I literally cringe every time > someone asks a sssd question because of the hostility toward sssd they are > about to at least perceive. >+1> I have never understood why sssd seems to be singled out for "hands-off" > treatment by the SAMBA crew. Is accommodating sssd really any different > than working with bind9 or time or ntp? How about integrations with things > like pfsense, where the ability to install the ideal software on a > stand-alone hardware system may be more constrained? > I think it is also very important to note that when people are asking > questions about sssd and SAMBA, it is very often the case that other > considerations required sssd AND the integration with SAMBA is for the > environment of concern very difficult.Yes, this was the point I was trying to make (perhaps doing a poor job of it!) early on in this discussion. I do understand that the easiest, most straight-forward way to get Samba talking to AD is to use Winbind, and that as of recent releases Winbind must be running for smbd to work with AD. That doesn't mean that sssd is completely useless, and doesn't mean there aren't situations where it may be required. I have 1-2 of them myself that either will not work with just winbind or would require extensive re-tooling and multi-company impact to change the configuration.> This sounds exactly like the the type of issue that this list should > address. It is clear that there is a wealth of knowledge here about the > problems that arise ... any why. If not this list to help solve or work > around those problems, to help make SAMBA work with sssd to solve the > user's real problem (usually one of preserving existing and difficult or > expensive to change environments), then WHO SHOULD? Perhaps it is the case > that BOTH this list and lists for sssd (as well as other products, as the > case may be) should be worked with concurrently, but I cannot fathom why > the user with a (urgent, critical, real world ...) problem should be forced > to solve it without also being able to freely and with welcome arms tap the > knowledge of the people who know SAMBA best. > I think it is fine, if the user desires, to discuss alternatives that may > be more suitable. I do not think that should be the starting point, or > worse the default position, which should be to help find a way to make a > system run or, more critically, get a broken system back up and running. > Easy problems, although often important, are a bit boring. We should > embrace the hard problems, and take pride in a job well done making the > "impossible" possible. >Well-said. One of the things that I very much value about the open source software community at large is the flexibility to make things work in all sorts of different environments. Should there be recommended configurations? Yes. Should users who are clearly struggling with the basics of getting things working be (gently) pointed in the direction of these recommendations? Absolutely. Should a community refuse to discuss or help users who have more "creative" or "interesting" configurations or requirements? No - that (to me) is the value of a community versus a commercial support contract. -Nick
On Thu, 2021-09-23 at 18:35 +0000, Billy Bob via samba wrote:> I am VERY happy to see this discussion. I literally cringe every > time someone asks a sssd question because of the hostility toward > sssd they are about to at least perceive. > I have never understood why sssd seems to be singled out for "hands- > off" treatment by the SAMBA crew. Is accommodating sssd really any > different than working with bind9 or time or ntp? How about > integrations with things like pfsense, where the ability to install > the ideal software on a stand-alone hardware system may be more > constrained? > I think it is also very important to note that when people are asking > questions about sssd and SAMBA, it is very often the case that other > considerations required sssd AND the integration with SAMBA is for > the environment of concern very difficult. This sounds exactly like > the the type of issue that this list should address. It is clear that > there is a wealth of knowledge here about the problems that arise ... > any why. If not this list to help solve or work around those > problems, to help make SAMBA work with sssd to solve the user's real > problem (usually one of preserving existing and difficult or > expensive to change environments), then WHO SHOULD? Perhaps it is the > case that BOTH this list and lists for sssd (as well as other > products, as the case may be) should be worked with concurrently, but > I cannot fathom why the user with a (urgent, critical, real world > ...) problem should be forced to solve it without also being able to > freely and with welcome arms tap the knowledge of the people who know > SAMBA best. > I think it is fine, if the user desires, to discuss alternatives that > may be more suitable. I do not think that should be the starting > point, or worse the default position, which should be to help find a > way to make a system run or, more critically, get a broken system > back up and running. > Easy problems, although often important, are a bit boring. We should > embrace the hard problems, and take pride in a job well done making > the "impossible" possible. > Just my take, as an otherwise fly on the wall but daily observer if > this list. > >All of this is my opinion. Lets get this out in the open, I have no hostility towards sssd, I just do not see the point of using it with Samba, Samba can do everything that sssd can do. My concerns about using sssd with Samba is that Samba does not produce it and cannot therefore support it in a reasonable way, the place to get support for sssd is the sssd-users mailing list. Samba can support Bind9 and ntp by describing how to set them up to work with a Samba AD DC. Anything else would have to be triaged and what Samba can fix, would be fixed, anything else would need to be sent to the relevant upstream supplier, which is what should happen with sssd. If anyone wants to use sssd with Samba, then that is their decision, but they should not expect to get help with it from Samba, there is enough to support on Samba already without supporting another suppliers product. To put this in context, it is like taking a Ford car to a Volvo dealer and asking them to fix, they will do their best, but you would get better service from a Ford dealer. Seeing has how I seem to be upsetting people by pointing out that sssd isn't a Samba product, I will ignore such posts in future and let others try to help. Rowland