On Thu, 2021-09-23 at 10:53 +0200, Ralph Boehme via samba wrote:> > There is a real need. > > -slowThere 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
Am 23.09.21 um 11:04 schrieb Andrew Bartlett:> 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.well said. Thanks! -slow -- Ralph Boehme, Samba Team https://samba.org/ SerNet Samba Team Lead https://sernet.de/en/team-samba -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20210923/1314e15e/OpenPGP_signature.sig>
... 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 > >
On Thu, 2021-09-23 at 21:04 +1200, Andrew Bartlett 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.Because we didn't try, you have been talking about doing a better idmapping for the last 10 years that I know off, but that has all it has been, talk.> > 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 BartlettI do not think we need sssd, we just need to make Samba easier to set up, something along the lines of a combination of the 'rid' and 'ad' backends, the 'rid' for idmapping and 'ad' for the rest of the rfc2307 attributes. I cannot write 'C' code so cannot help here. We either need to swallow sssd into Samba and alter it to our uses or ignore it. Rowland
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 5:05 AM 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.If we can get past the Kerberos version issues it will be much easier. Installing a bulky separate set of Kerberos libraries is awkward, and one of the reasons our friends over at RHEL and Fedora have been reluctant to support Samba as a domain controller. Working with sssd is... a distinct issue, I think. sssd has some genuinely horrible, horrible behavior that is difficult to collaborate with. Its insistence on managing a set of distinct daemons, each of them part of the sssd suite, from one central configuration file whose hand-tuned operations are wiped out by authconfig makes it very difficult indeed to manage. It's insistrnce on starting up, responding successfully toa few queries, then crashing and requiring a full manual restart due to its failure to pre-load bulky LDAP tables is very difficult to avoid in large environments. I have harsh words about such service breaking pre-optimization.> 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.If only I could get it to work at all, I would consider doing so. The bulky LDAP environment failure has forced me to reject sssd in 3 distinct companies, usually due to the the AD admin's insistence on preserving previous, purchased company's complex LDAP structures without sanitizing or simplifying it. Especially when sssd is deployed in the cloud and the AD or Samba server is not, and whether the upstream domain controller is AD or Samba, it's a problem.> 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.One thing we can do that might help sssd admins is to encourage Samba admins to organize their LDAP structures as distinct folders, rather than scattering them around an organization's structure, rather than plucking one group or user from one folder and one group or user from other folders scattered around the LDAP. That allows sssd to talk to only one much smaller space in LDAP, and avoid the pre-loading difficulties at sssd startup.