So I've finished sssd-ldap man page review. The attached patch reflects all changes previously discussed here.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/25/2010 09:36 AM, Jan Zelený wrote:
IPA
Do we want to explicitly document this outside using provider=ipa?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/25/2010 01:20 PM, Jakub Hrozek wrote:
Do we want to explicitly document this outside using provider=ipa?
Correcting myself, the schema seems to be the way to set up IPAv1 clients. Sorry for the fuss.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/25/2010 09:36 AM, Jan Zelený wrote:
The main difference between these two schema types ishow group memberships are recorded in the server.
I would personally prefer not to delete the above sentence altogether, just rephrase it. Sorry for nitpicking, but I know that the schema differences have been a cause of confusion among users, so I think we should keep the documentation as descriptive as possible.
<varlistentry>
<term>ldap_user_modify_timestamp (string)</term><listitem><para>The LDAP attribute that contains timestamp of thelast modification of the parental object.
This would better be answered by a native English speaker, but "parental object" does not sound right to me, is just "parent object" better?
Also, In description of most of the added ldap_user_* attributes, I think that "this parameter" would sound better than just "this".
<varlistentry><term>entry_cache_timeout (integer)</term><listitem><para>This represents how long the record (either user orgroup) will be valid in cache after it is loaded.Every record has the same timeout. The value is inseconds.</para><para>Default: 5400 (1.5 hours)
This option is already described in sssd.conf since it is used by the proxy backend, too.
<varlistentry>
<term>account_cache_expiration (integer)</term><listitem><para>Specifies how many days have to pass without userlogged in before he can be deleted from cacheduring cleanup. Zero disables account cleanup.</para><para>Default: 0</para></listitem></varlistentry><varlistentry>
I'm wondering whether this should be considered a generic option, similar to entry_cache_timeout and documented in sssd.conf. I think any future back ends might implement a cleanup task, too, controlled by the same parameter, even though LDAP is the only implemented ID provider so far.
Otherwise, looks good to me. Good work!
Jakub
I'm sending updated patch:
I would personally prefer not to delete the above sentence altogether, just rephrase it. Sorry for nitpicking, but I know that the schema differences have been a cause of confusion among users, so I think we should keep the documentation as descriptive as possible.
You're probably right. Done.
This would better be answered by a native English speaker, but "parental object" does not sound right to me, is just "parent object" better?
I think it is correct this way. As you said, native English speaker should probably decide this.
Also, In description of most of the added ldap_user_* attributes, I think that "this parameter" would sound better than just "this".
Done
This option is already described in sssd.conf since it is used by the proxy backend, too.
Removed
I'm wondering whether this should be considered a generic option, similar to entry_cache_timeout and documented in sssd.conf. I think any future back ends might implement a cleanup task, too, controlled by the same parameter, even though LDAP is the only implemented ID provider so far.
Removed
-- Jan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/01/2010 09:04 AM, Jan Zelený wrote:
This would better be answered by a native English speaker, but "parental object" does not sound right to me, is just "parent object" better?
I think it is correct this way. As you said, native English speaker should probably decide this.
"Parental" in English means "related to the parent". In this usage, you want "parent" as an adjective describing that the object IS the parent.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Stephen Gallagher sgallagh@redhat.com wrote:
On 09/01/2010 09:04 AM, Jan Zelený wrote:
This would better be answered by a native English speaker, but "parental object" does not sound right to me, is just "parent object" better?
I think it is correct this way. As you said, native English speaker should probably decide this.
"Parental" in English means "related to the parent". In this usage, you want "parent" as an adjective describing that the object IS the parent.
Updated patch attached.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/03/2010 09:42 AM, Jan Zelený wrote:
Stephen Gallagher sgallagh@redhat.com wrote:
On 09/01/2010 09:04 AM, Jan Zelený wrote:
This would better be answered by a native English speaker, but "parental object" does not sound right to me, is just "parent object" better?
I think it is correct this way. As you said, native English speaker should probably decide this.
"Parental" in English means "related to the parent". In this usage, you want "parent" as an adjective describing that the object IS the parent.
Updated patch attached.
Ack
(verified with interdiff that the only change is s/parental/parent/)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/06/2010 09:15 AM, Jakub Hrozek wrote:
On 09/03/2010 09:42 AM, Jan Zelený wrote:
Stephen Gallagher sgallagh@redhat.com wrote:
On 09/01/2010 09:04 AM, Jan Zelený wrote:
This would better be answered by a native English speaker, but "parental object" does not sound right to me, is just "parent object" better?
I think it is correct this way. As you said, native English speaker should probably decide this.
"Parental" in English means "related to the parent". In this usage, you want "parent" as an adjective describing that the object IS the parent.
Updated patch attached.
Ack
(verified with interdiff that the only change is s/parental/parent/)
Pushed to master.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Jan Zelený -
Stephen Gallagher