Re: (ITS#8935) slapo-ppolicy requires rewrite
by quanah＠symas.com
--On Saturday, November 17, 2018 11:27 AM +0000 michael(a)stroeder.com wrote:
> With such a layout the standard schema shipped with the software is not
> part of cn=config but can still be dynamically changed (by directly
> modifying subschema subentry). But there's always a way out of trouble
> because you can manually fix the separate LDIF schema file(s).
You can manually fix the ones stored in cn=config with OpenLDAP now, and
you can also change it dynamically. I'm not sure how either of those
statements address the problem discussed in this ITS.
Quite frankly, I wrote a tool to automatically update the schema stored
with cn=config so that it matched whatever was shipped in a given release
on upgrade when I worked @ Zimbra:
<https://github.com/Zimbra/zm-core-utils/blob/develop/src/libexec/zmldapsc...>
I.e., I don't really see what in the above is different from what you can
do now, nor do I see how it resolves the issue of a binary compiled file
that must have references to valid schema compiled into it.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 10 months
Re: (ITS#8935) slapo-ppolicy requires rewrite
by quanah＠symas.com
--On Saturday, November 17, 2018 9:49 AM +0000 michael(a)stroeder.com wrote:
> Your conclusion is to hard-code the ppolicy schema into the C code.
> If you think this to the end you have to move *all* standard schema
> installed to schema_prep.c.
The above statement is simply not true. The difference here is the fact
that the ppolicy binary has direct references to the schema in its code,
which requires it to have matching schema prior to slapd being able to
start. You can still start slapd when any schema (outside of the few items
hard coded in schema_prep for the same reason) is different. You have the
ability at that point to modify slapd via online operations post-upgrade.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 10 months
Re: (ITS#8935) slapo-ppolicy requires rewrite
by michael＠stroeder.com
On 11/17/18 11:35 AM, hyc(a)symas.com wrote:
> We could instead ship an update.ldif containing the mods between
> different schema versions, that must be applied with slapmodify
> during the update process...
IMO too many prerequisites must be perfectly full-filled and thus is too
fragile.
That's one of the things where e.g. OpenDS/OpenDJ does a much better job
with its cn=config:
The schema shipped with the server is stored in various LDIF files in a
config directory along with file rootdse.ldif holding cn=config. Schema
directly added by modifying cn=schema is sent to a separate user schema
file.
With such a layout the standard schema shipped with the software is not
part of cn=config but can still be dynamically changed (by directly
modifying subschema subentry). But there's always a way out of trouble
because you can manually fix the separate LDIF schema file(s).
Ciao, Michael.
4 years, 10 months
Re: (ITS#8935) slapo-ppolicy requires rewrite
by hyc＠symas.com
michael(a)stroeder.com wrote:
> The root cause is that updating slapd with its default schema installed
> does not update existing content of cn=schema,cn=config.
>
> You have to tackle this root cause and not only solve it for a
> particular overlay.
We could instead ship an update.ldif containing the mods between
different schema versions, that must be applied with slapmodify
during the update process...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4 years, 10 months
Re: (ITS#8935) slapo-ppolicy requires rewrite
by michael＠stroeder.com
The root cause is that updating slapd with its default schema installed
does not update existing content of cn=schema,cn=config.
You have to tackle this root cause and not only solve it for a
particular overlay.
Your conclusion is to hard-code the ppolicy schema into the C code.
If you think this to the end you have to move *all* standard schema
installed to schema_prep.c.
IMO this is bad design. But I'm not the one to decide on that. :-/
Ciao, Michael.
4 years, 10 months
Re: (ITS#8893) New LDAP option to support binding to specific IPv4/IPv6 address at client side
by quanah＠symas.com
--On Saturday, November 17, 2018 12:14 AM +0000 quanah(a)symas.com wrote:
> --On Tuesday, August 07, 2018 5:33 AM +0000 sudhir.singam(a)gmail.com wrote:
>
>> Full_Name: sudhir reddy singam
>> Version: master branch
>> OS: fedora
>> URL:
>> Submission from: (NULL) (131.228.66.13)
Never mind, I see this is a duplicate of ITS#8847. Please do not file
duplicate ITSes for the same issue.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 10 months
Re: (ITS#8893) New LDAP option to support binding to specific IPv4/IPv6 address at client side
by quanah＠symas.com
--On Tuesday, August 07, 2018 5:33 AM +0000 sudhir.singam(a)gmail.com wrote:
> Full_Name: sudhir reddy singam
> Version: master branch
> OS: fedora
> URL:
> Submission from: (NULL) (131.228.66.13)
>
>
>
> The attached file is derived from OpenLDAP Software. All of the
> modifications to
> OpenLDAP Software represented in the following patch(es) were developed by
> NOKIA. NOKIA has not assigned rights and/or interest in this work to any
> party. I, SINGAM SUDHIR REDDY authorized by NOKIA, my employer, to
> release this work under the following terms.
>
> NOKIA hereby place the following modifications to OpenLDAP Software (and
> only these modifications) into the public domain. Hence, these
> modifications may be freely used and/or redistributed for any purpose
> with or without attribution and/or other notice.
>
> ****
Hello,
There is no patch associated with this ITS. Can you please respond to this
email and attach it?
Thanks,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 10 months
(ITS#8935) slapo-ppolicy requires rewrite
by quanah＠openldap.org
Full_Name: Quanah Gibson-Mount
Version: OpenLDAP 2.4
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)
In OpenLDAP 2.4.43, a new attribute was added to the external ppolicy schema
(ITS#8185). While this worked fine with older slapd.conf based configurations
where the ppolicy schema file was replaced on upgrade, it was a complete and
utter disaster for deployments using cn=config, as the ppolicy overlay
references all the attributes defined in external ppolicy schema file. To be
able to upgrade without failure, one would have export cn=config, update the
binaries, update the ppolicy schema information in the exported cn=config
database, re-import cn=config, and then start slapd. This broke the usual
ability to do in-place upgrades with cn=config.
Instead, the entire contents of the ppolicy.schema file should be internalized
to the ppolicy overlay, similar to how the accesslog overlay is written, and the
external ppolicy.schema file deleted. This will allow non-breaking upgrades for
both slapd.conf and cn=config based configurations.
4 years, 10 months
Re: (ITS#7578) delta-sync multimaster replication issue
by quanah＠symas.com
--On Friday, April 26, 2013 8:07 PM +0000 afrunning(a)gmail.com wrote:
> Full_Name: Al F
> Version: 2.4.35
> OS: Redhat 6.4 - x64
> URL: https://dl.dropboxusercontent.com/u/982376/its/al-f-130426.zip
> Submission from: (NULL) (74.123.146.10)
>
>
> Hi, I have a multimaster system utilizing delta-sync for replication. The
> system is utilizing mdb for both the user and the accesslog data. I have
> ppolicy & memberof overlays enabled as well. all of my writes are
> directed at a single server using a load balancer. I have found that
> when a user has a pwdFailureTime attribute set on their entry, if an
> administrator resets the password, "null_callback : error code 0x10" is
> produced in the log on the secondary system and the secondary system goes
> into refresh mode.
Hello,
I believe this is the same as ITS#8927, which has been fixed for the
upcoming OpenLDAP 2.4.47 release.
Warm regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 10 months
Re: (ITS#8928) Reproducibility: Remove user, hostname, pwd from version string
by hyc＠symas.com
douglas.royds(a)taitradio.com wrote:
> URL: ftp://ftp.openldap.org/incoming/douglas-royds-181026.patch
>
> This updated patch also sets the date and time strings to the
> SOURCE_DATE_EPOCH.
Are you intending a SOURCE_DATE_EPOCH to be a Unix time value? I.e., an integer?
This value format needs to be documented.
Unfortunately, your use of date -d is nonportable, it appears that only the GNU tools
understand this option. It will fail on other platforms like *BSD, Solaris, that aren't
using a GNU userland.
Why can't you simply provide an already formatted date & time that can be used
directly, instead of needing to be reformatted here?
> The WHOWHERE string will now be set to simply "openldap" in the case
> that a SOURCE_DATE_EPOCH is set.
>
> Tait Communications Ltd hereby place the following modifications to
> OpenLDAP Software (and only these modifications) into the public domain.
> Hence, these modifications may be freely used and/or redistributed for
> any purpose with or without attribution and/or other notice.
>
>
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4 years, 10 months
