On Tue, 2018-09-25 at 08:40 +0200, Jakub Hrozek wrote:
> > On 24 Sep 2018, at 20:25, Simo Sorce wrote:
> >
> > On Mon, 2018-09-24 at 19:59 +0200, Jakub Hrozek wrote:
> > > On Mon, Sep 24, 2018 at 10:22:35AM -0400, Simo Sorce wrote:
> > > > > btw it’s a good question to ask why isn’t the check
On 9/25/18 8:40 AM, Jakub Hrozek wrote:
> This is honestly something where I don’t know what is the right thing
> to do. If we detect that a group with some GID already exists, then
> how do we distinguish between “err, there are duplicates on the LDAP
> side” and “look, the group was renamed”
> On 24 Sep 2018, at 20:25, Simo Sorce wrote:
>
> On Mon, 2018-09-24 at 19:59 +0200, Jakub Hrozek wrote:
>> On Mon, Sep 24, 2018 at 10:22:35AM -0400, Simo Sorce wrote:
btw it’s a good question to ask why isn’t the check done on saving
the group. I thought it was and I see code that
, this can be happening simultaneously for multiple
> groups.
>
> Gareth
>
>
> -----Original Message-----
> From: Jakub Hrozek [mailto:jhro...@redhat.com]
> Sent: Monday, September 24, 2018 10:59 AM
> To: sssd-users@lists.fedorahosted.org
> Subject: [SSSD-users
efore too long. Since we have multiple split
groups, this can be happening simultaneously for multiple groups.
Gareth
-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Monday, September 24, 2018 10:59 AM
To: sssd-users@lists.fedorahosted.org
Subject: [SSSD-users] Re: I
On Mon, 2018-09-24 at 19:59 +0200, Jakub Hrozek wrote:
> On Mon, Sep 24, 2018 at 10:22:35AM -0400, Simo Sorce wrote:
> > > btw it’s a good question to ask why isn’t the check done on saving
> > > the group. I thought it was and I see code that checks for ID
> > > uniqueness and even a test..
> >
On Mon, Sep 24, 2018 at 04:40:34PM +0200, Michael Ströder wrote:
> On 9/24/18 4:12 PM, Beale (US), Gareth wrote:
> >> I’m not so sure it would be a good idea to support this, honestly.
> >
> > Well that rather depends on what you mean by "this". I was reporting
> > a problem that seemed an
On Mon, Sep 24, 2018 at 10:22:35AM -0400, Simo Sorce wrote:
> > btw it’s a good question to ask why isn’t the check done on saving
> > the group. I thought it was and I see code that checks for ID
> > uniqueness and even a test..
>
> In current code, saving would override data as if the group was
, 2018 8:46 AM
To: End-user discussions about the System Security Services Daemon
Subject: [SSSD-users] Re: Issues with SSSD cache on version 1.13.4
On Mon, 2018-09-24 at 16:44 +0200, Michael Ströder wrote:
> On 9/24/18 4:22 PM, Simo Sorce wrote:
> > For groups I would expect us
On Mon, 2018-09-24 at 16:44 +0200, Michael Ströder wrote:
> On 9/24/18 4:22 PM, Simo Sorce wrote:
> > For groups I would expect us to merge memberships in rfc2307 mode,
>
> If you really want to implement such merging then please disable
> it by default. So that it must be explicitly enabled
On 9/24/18 4:22 PM, Simo Sorce wrote:
> For groups I would expect us to merge memberships in rfc2307 mode,
If you really want to implement such merging then please disable
it by default. So that it must be explicitly enabled after careful
consideration.
Ciao, Michael.
smime.p7s
Description:
On 9/24/18 4:12 PM, Beale (US), Gareth wrote:
>> I’m not so sure it would be a good idea to support this, honestly.
>
> Well that rather depends on what you mean by "this". I was reporting
> a problem that seemed an inconsistency to me. Either multiple groups
> with the same GID are supported, or
On Mon, 2018-09-24 at 11:38 +0200, Jakub Hrozek wrote:
> > On 21 Sep 2018, at 20:36, gfb...@yahoo.com wrote:
> >
> > For our case, say we have a set of groups abcd..1, abcd..2 etc, all
> > with the same GID. I would expect the first lookup (e.g. abcd..1)
> > to put an entry in the cache. If there
essage-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Monday, September 24, 2018 2:38 AM
To: End-user discussions about the System Security Services Daemon
Subject: [SSSD-users] Re: Issues with SSSD cache on version 1.13.4
> On 21 Sep 2018, at 20:36, gfb...@yahoo.com wrote:
>
> For
> On 21 Sep 2018, at 20:36, gfb...@yahoo.com wrote:
>
> For our case, say we have a set of groups abcd..1, abcd..2 etc, all with the
> same GID. I would expect the first lookup (e.g. abcd..1) to put an entry in
> the cache. If there is then a lookup by GID, (getent group ) it would
> return
On 9/21/18 7:53 PM, Beale (US), Gareth wrote:
> Due to the large number of users and groups in our LDAP directory, and
> the limitations of some legacy Unix systems, we have some large groups
> that have been broken into “sub-groups” with the same GID but an
> incremental suffix.
I'd consider
So how does one determine if there is an issue open or not? And how do they get
prioritized?
This issue makes SSSD unusable in our production environment. We may have to
look at running without SSSD in the short term, if that is possible on SLES 12.
I'm not quite understanding why this error
I am probably guilty of introducing this behavior in the original
implementation, and although I believe it is the correct behavior for
UIDs, it is probably suboptimal for GIDs.
I think we should open an issue to deal with this in a better way if
one is not open yet.
Simo.
On Fri, 2018-09-21 at
18 matches
Mail list logo
