389-devel June 2016

389-devel@lists.fedoraproject.org

10 participants
55 discussions

Please review: [389 Project] #48848: modrdn deleteoldrdn can fail to find old attribute value, perhaps due to case folding
by Noriko Hosoi 07 Jun '16

07 Jun '16

https://fedorahosted.org/389/ticket/48848 https://fedorahosted.org/389/attachment/ticket/48848/0001-Ticket-48848-modr…

1 0

Q. on RDN with CES type
by Noriko Hosoi 07 Jun '16

07 Jun '16

Hello, I'm working on this ticket 48848. Fixing the ticket itself is easy (please see the proposed patch). https://fedorahosted.org/389/ticket/48848 Ticket #48848 <https://fedorahosted.org/389/ticket/48848> - modrdn deleteoldrdn can fail to find old attribute value, perhaps due to case folding Fix proposal: https://fedorahosted.org/389/attachment/ticket/48848/0001-Ticket-48848-modr… But I'm afraid it might have revealed another tricky issue... If a DN contains CES type RDN, is it ok to return the entry if a given basedn does not match the case? *Example*: Existing DN: dn: labeledURI=testURI,ou=People,dc=example,dc=com Please note that labeledURI is caseExactMatch type. $ ldapsearch [...] -b "labeleduri=testuri,ou=People,dc=example,dc=com" dn dn: labeleduri=testURI,ou=People,dc=example,dc=com Our dn normalization code does not care the type of rdn but just lower the case to normalize a dn. I'm trying to check it with the openldap server, but somehow it is not happy on my Fedoras... :( Although I continue trying to make it work, but if someone has the openldap server handy, could you please add the attached entry, run the command line and check if it returns the entry or not? $ ldapsearch [...] -b "labeleduri=testuri,ou=People,dc=example,dc=com" dn Thanks! --noriko

1 1

Clarification on docs
by William Brown 06 Jun '16

06 Jun '16

Hi, Reading our docs, I see something ambiguous: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/h… ver_Configuration_Reference.html#cnchangelog5 ⁠ 3.1.2.2. nsslapd-changelogmaxage (Max Changelog Age) In the scenario where we have a replica that is offline, how does the changelog handle this? Do we: A) Trim the changelog, and expect the offline master to be re-initialised B) Do we keep the event in the changelog even though it's expired maxage. I think it would be good to clarify this behaviour in our documentation, but I wanted to know how it behaves first. Thanks, -- Sincerely, William Brown Software Engineer Red Hat, Brisbane

1 0

Please review: [389 Project] #47911: split out snmp agent into a subpackage
by Noriko Hosoi 03 Jun '16

03 Jun '16

https://fedorahosted.org/389/ticket/47911 https://fedorahosted.org/389/attachment/ticket/47911/0001-Ticket-47911-spli…

1 0

Please review/comment: [389 Project] #48833: 389 showing inconsistent values for shadowMax and shadowWarning in 1.3.5.1
by Noriko Hosoi 01 Jun '16

01 Jun '16

https://fedorahosted.org/389/ticket/48833 There are 2 proposals. I'd like to have your thoughts which one would be preferable. https://fedorahosted.org/389/attachment/ticket/48833/0001-Ticket-48833-389-… git patch file (master) -- second proposal -- this patch allows the password policy values and shadow account values in sync. If we choose this option, DS Console Password Policy panel needs to be modified to support the larger value than INT_MAX. https://fedorahosted.org/389/attachment/ticket/48833/0001-Ticket-48833-389-… git patch file (master) -- first proposal -- shadow account values won't be touched if they already exist in an entry. Restrictions: 1. If objectclass: shadowaccount is set and there is no shadow account values in an entry, the shadowmax, min, and warning are filled by calculating them from the password policy values. The maximum value of calculated shadowMax is 24855 (== 2^31-1 / (24 * 60 * 60)). 2. Even if the values of the password policy are updated, shadow account values are not effected.

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel June 2016