Bug 49821

Summary: univentionUDMPropertyCopyable added to LDAP index in 10univention-ldap-server.inst (first slapindex after LDAP replication)
Product: UCS Reporter: Felix Botner <botner>
Component: LDAPAssignee: UCS maintainers <ucs-maintainers>
Status: NEW --- QA Contact: UCS maintainers <ucs-maintainers>
Severity: normal    
Priority: P5 CC: best, hahn
Version: UCS 4.4   
Target Milestone: ---   
Hardware: Other   
OS: Linux   
See Also: https://forge.univention.org/bugzilla/show_bug.cgi?id=47609
https://forge.univention.org/bugzilla/show_bug.cgi?id=50673
What kind of report is it?: Bug Report What type of bug is this?: 2: Improvement: Would be a product improvement
Who will be affected by this bug?: 5: Will affect all installed domains How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.114 Enterprise Customer affected?:
School Customer affected?: ISV affected?:
Waiting Support: Flags outvoted (downgraded) after PO Review:
Ticket number: Bug group (optional):
Max CVSS v3 score:

Description Felix Botner univentionstaff 2019-07-05 15:06:35 CEST 
Seems that univentionUDMPropertyCopyable is added to the LDAP index in 10univention-ldap-server.inst with:

/usr/share/univention-ldap/ldap_setup_index --add-eq univentionUDMPropertyCopyable

which runs slapindex.

On Backup and Slaves that means we copy the LDAP database (during which the index is generated) and subsequently call slapindex (again).

The correct way seems to me:

* Adding univentionUDMPropertyCopyable to the default index in ldap_setup_index
* Removing ldap_setup_index --add-eq univentionUDMPropertyCopyable from
  10univention-ldap-server.inst
* The default index is configured during 01univention-ldap-server-init.inst 
* During the LDAP replication the index is generated correctly (including
  univentionUDMPropertyCopyable)
Comment 1 Philipp Hahn univentionstaff 2019-07-05 15:25:18 CEST 
Yes, as 'univentionUDMPropertyCopyable' is part of a default UCS schema. (You must not do that when the schema is only later registered using the UDM schema extension mechanism.)

PS: You might also look at <https://hutten.knut.univention.de/blog/unix-108-ldapsearch/> and change
 univention-ldapsearch -LLL -o ldif-wrap=no -b cn=Subschema -s base attributeTypes | grep -Fq "NAME 'univentionUDMPropertyCopyable'"
to
 univention-ldapsearch -LLL -o ldif-wrap=no -b cn=Subschema -s base -E mv='(attributeTypes=univentionUDMPropertyCopyable)' attributeTypes | grep -q ^attributeTypes:
Comment 2 Florian Best univentionstaff 2019-08-02 20:05:09 CEST 
The reason why it was added to the joinscript is that this was the only way to add it, because the attribute has been added in a erratum update Bug #1567.
Comment 3 Felix Botner univentionstaff 2019-08-26 11:00:47 CEST 
(In reply to Florian Best from comment #2)
> The reason why it was added to the joinscript is that this was the only way
> to add it, because the attribute has been added in a erratum update Bug
> #1567.

ok,
but i want a join process without an extra slapindex, is that to much to ask for?
Comment 4 Florian Best univentionstaff 2019-08-26 11:14:50 CEST 
(In reply to Felix Botner from comment #3)
> (In reply to Florian Best from comment #2)
> > The reason why it was added to the joinscript is that this was the only way
> > to add it, because the attribute has been added in a erratum update Bug
> > #1567.
> 
> ok,
> but i want a join process without an extra slapindex, is that to much to ask
> for?
No, it's not. But it was not possible when releasing/introducing new attributes: slapd raised error messages about schema validation.
As the attribute now exists we can change the code now.