[SSSD] [PATCH] MAN: Clarify the ldap_access_filter option further
Jakub Hrozek
jhrozek at redhat.com
Wed Feb 26 16:30:55 UTC 2014
On Wed, Feb 26, 2014 at 05:22:51PM +0100, Jakub Hrozek wrote:
> On Wed, Feb 26, 2014 at 11:14:33AM -0500, Stephen Gallagher wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 02/26/2014 10:08 AM, Jakub Hrozek wrote:
> > > On Mon, Feb 24, 2014 at 07:47:08PM +0100, Jakub Hrozek wrote:
> > >> The attached patch addresses:
> > >> https://fedorahosted.org/sssd/ticket/2235
> > >>
> > >> The memberof example was misleading and was making aministrators
> > >> think that the ldap_access_filter can resolve nested group
> > >> memberships.
> > >>
> > >> The alternative I was considering was changing the example to use
> > >> a different attribute altogether, but I was struggling to come up
> > >> with an example that wouldn't be too artificial (like
> > >> ldap_access_filter=/bin/bash).
> > >
> > > Stephen's review seems to be stuck in mailman queue, so I'm sending
> > > a patch that contains his suggestion as a reply to myself.
> > >
> > > The employeeType attribute Stephen suggested is a good choice, I
> > > think.
> > >
> >
> > If we're changing the cited example, I'm not sure we need to call out
> > the memberOf example anymore.
>
> Hmm, initially I wanted to keep it in, because memberOf is what I see
> used mostly in the field but you're right that when I don't think about
> the context of the change and just read the man page text, it is
> confusing to start talking about memberOf.
>
> Another iteration of the patch is attached.
Yet another version that retains a part of the paragraph (.."applied on
the LDAP entry only..") and changes description of the example.
-------------- next part --------------
>From e164ed61b32907e06795103d899bc52188450ff8 Mon Sep 17 00:00:00 2001
From: Jakub Hrozek <jhrozek at redhat.com>
Date: Tue, 25 Feb 2014 17:09:00 +0100
Subject: [PATCH] MAN: Clarify that changing ID mapping options might require
purging the cache
https://fedorahosted.org/sssd/ticket/2252
Currently SSSD chokes when IDs of users change, we don't support ID
changes yet. Because some users were confused about the failures, this
patch adds additional clarification.
---
src/man/include/ldap_id_mapping.xml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/src/man/include/ldap_id_mapping.xml b/src/man/include/ldap_id_mapping.xml
index 9dda399243bfd1725509c239d3358f2ef7501014..a10dcd52a1687c4d97211ebdabc77095bbfccf5a 100644
--- a/src/man/include/ldap_id_mapping.xml
+++ b/src/man/include/ldap_id_mapping.xml
@@ -12,6 +12,17 @@
need to use manually-assigned values, ALL values must be
manually-assigned.
</para>
+ <para>
+ Please note that changing the ID mapping related configuration
+ options will cause user and group IDs to change. At the moment,
+ SSSD does not support changing IDs, so the SSSD database must be
+ removed. Because cached passwords are also stored in the database,
+ removing the database should only be performed while the SSSD
+ is online, otherwise users might get locked out. Moreover, the
+ change of IDs might neccessitate to adjust other system properties
+ such as file and directory ownership, so it's advisable to plan
+ ahead and test the ID mapping configuration thoroughly.
+ </para>
<refsect2 id='idmap_algorithm'>
<title>Mapping Algorithm</title>
--
1.8.5.3
More information about the sssd-devel
mailing list