Bug 5098 - Please Resolve Conflicts between MIT and Heimdal Kerberos Libraries
: Please Resolve Conflicts between MIT and Heimdal Kerberos Libraries
Status: VERIFIED FIXED
Product: Desktop Bugs
Classification: ROSA Desktop
Component: Main Packages
: Fresh
: All Linux
: Normal normal
: ---
Assigned To: Alexey Ivanov
: ROSA Linux Bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-02-26 10:52 MSK by Zombie Ryushu
Modified: 2015-04-27 13:22 MSD (History)
3 users (show)

See Also:
RPM Package: krb5
ISO-related:
Bad POT generating:
Upstream:
vladimir.potapov: qa_verified+
denis.silakov: published+


Attachments
urpmi Schema DIFF (472 bytes, patch)
2015-04-02 06:38 MSD, Zombie Ryushu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zombie Ryushu 2015-02-26 10:52:23 MSK
Heimdal and MIT Kerberos serve effectively the same function, but have conflicting Libaries and OpenLDAP schema files. It is possible to use Heimdal Kerberos Clients with MIT Kerberos KDCs and Servers and Vice Versa, but MIT Kerberos KDCs and Heimdal KDCs cannot function within the same domain or use the same Schema in OpenLDAP.

I initially thought that OpenLDAP was simply unsupported for MIT Kerberos. This has turned out to be false. MIT Kerberos CAN use LDAP as a backend for its database, but in a different manner and with a different Schema than Heimdal. Unfortunately, LDAP comes Pre-packaged with a kind of dummy schema called krb5-kdc.schema. This schema isn't used by either MIT Kerberos nor Heimdal Kerberos.

The Proper MIT Kerberos Schema is called kerberos.schema and is Packaged with MIT Kerberos releases. 

Heimdal has its own LDAP Schema and it is called hdb.schema. either Kerberos.schema or hdb.schema should be provided by the respective Kerberos KDC Implementations for OpenLDAP in /usr/share/openldap/schemas/ directory for use in slapd.conf

As for Kerberos workstation utilities, either Heimdal or MIT Kerberos workstation utilities should be installible in an either/or setup, each KDC should be installable via an either/or setup, but support Libraries for both should be installable for both in parallel for applications that link against them at build time such as OpenLDAP and KDE.
Comment 1 Alexey Ivanov 2015-02-26 11:02:20 MSK
Thank you for details provided. I'll be updating this topic periodically to reflect progress.
Comment 2 Alexey Ivanov 2015-03-02 15:01:27 MSK
I have dissected openldap-extra-schemas package. It hasn't been updated for long time. Collection of schema files it holds is outdated. Principles by which some files were picked are unclean to me.

To bring in a little bit of order we came up with another approach: schema files that ship with sources of projects we support will get packaged into small packages "openldap-schema-%{name}" and will get installed along with openldap-servers. This way we will always ship relevant schema files with fresh installations.
For rather unlikely situation of upstream changes in schema files we'll protect already installed instances from being overwritten by update process. Just in case of unforeseen consequences.

I have successfully altered several packages and shrunk openldap-extra-schemas package. OpenLDAP successfully installs, upgrades and runs. This part of packaging seems promising.

The next step is to work on Heimdal libraries and headers so that we could build OpenLDAP with both krb5 and heimdal.

We'll leave polishing of default configuration for final stage.
Comment 3 Zombie Ryushu 2015-03-02 15:12:36 MSK
This is actually a good idea, Some schemas however are "Core level" Like the core.schema, cosine.schema and such, but I've often wondered if we should break Schemas into its own config file, or use CN=config and embed schemas into OpenLDAP like Samba 4 does.
Comment 4 Vladimir Potapov 2015-03-17 13:09:59 MSK
Zombie Ryushu, please, check a update with fixes
http://bugs.rosalinux.ru/show_bug.cgi?id=5180
Comment 5 Alexey Ivanov 2015-03-18 16:24:19 MSK
Bug 5180 covers one of pre-requisites. It is required to solve this issue. It does not solve it alone.

Seems like I should opt to containers for now and do not bother QA till I compose them all together.
Comment 6 Alexey Ivanov 2015-03-24 11:33:10 MSK
Zombie Ryushu, check this build please:

https://abf.io/build_lists/2475148
https://abf.io/build_lists/2475149

It can be tested by adding these media (x86_64):

for i in 2475149 2475126 2475122 2475124 ; do urpmi.addmedia $i http://abf-downloads.rosalinux.ru/rosa2014.1/container/$i/x86_64/main/release/ ; done

or these (i586):

for i in 2475148 2475125 2475121 2475123 ; do urpmi.addmedia $i http://abf-downloads.rosalinux.ru/rosa2014.1/container/$i/i586/main/release/ ; done

It is built with heimdal support and it shows new approach to default configuration. The latter topic is of most interest to me. I'd like to know your suggestions on default config. If you see a way to improve it please feel free to add up to this mock-up:

https://gitlab.com/alexey.fqdn.co/openldap-default-config
Comment 7 Zombie Ryushu 2015-03-24 19:58:52 MSK
I looked it over. I see a conflict and need for Clarification. There is a Schema Conflict between nis.schema and misc.schema. (I think.) I used to have a custom Schema I made myself called nisMailHost that defined two Schema Attributes where nis.schema and misc.schema didn't get along. 

Here is the URL to nisMailHost.schema

http://pastebin.com/bc07uGWD

The idea was that there could be an emulation layer for workstations using OpenLDAP to have the same NIS, YP and NIS+ Features of Sun's Yellow Pages for LDAP Clients.
Comment 8 Zombie Ryushu 2015-03-24 22:23:46 MSK
There's a few more Schema's I'd like to mention.

printer.schema (CUPS, this should be treated like dhcp and other similar application level schemas)
evoldap.schema (Get Evolution Configuration from LDAP using gconftool, maybe defunct.)
urpmi.schema (Define a urpmi source in LDAP.)
Comment 9 Alexey Ivanov 2015-03-25 09:46:04 MSK
> There is a Schema Conflict between nis.schema and misc.schema. (I think.)

Doesn't seem to be easily reproduced. At least I wasn't able to get error just by enabling them both at the same time — slapd starts without complaint. And misc.schema is not enabled by default as it is stated as experimental by OpenLDAP developers themself.

> I used to have a custom Schema I made myself called nisMailHost that defined two Schema Attributes where nis.schema and misc.schema didn't get along … The idea was that there could be an emulation layer for workstations using OpenLDAP to have the same NIS, YP and NIS+ Features of Sun's Yellow Pages for LDAP Clients.

May be it is a special case? Should we aim to provide such functionality out-of the box or should we let a user decide which path he (she) will take? I'd prefer to offer options and not to press on some vision of "true" configuration. If you think it should absolutely be reached and will prove useful please explain in more details.

> There's a few more Schema's I'd like to mention.

Providing more schemas is not a difficult task. I'll see if we could add these.
Comment 10 Zombie Ryushu 2015-03-25 15:03:47 MSK
I think this was a Mis-configuration of the Schema on my part due to the specification of RFC 2037. The reason I bring it up, is because there should be no conflict between RFC 2037 and NIS/NIS+ Schemas. I'd like to know where the mistake I made was, but I want to ensure than the NIS data types remain supported.
Comment 11 Alexey Ivanov 2015-03-26 08:47:25 MSK
*** Bug 3108 has been marked as a duplicate of this bug. ***
Comment 12 Zombie Ryushu 2015-03-26 09:02:13 MSK
If everything is functioning as intended, what should happen is nisDomain, and similar NIS simulation Object Classes should still be usable and should not interfere. My understanding is that the purpose of nis.schema is to provide the functionality of NIS Nested Netgroups, NFS Automounts, and RPC to the Name Service Switch (nslcd) without the actual NIS and NIS+ protocols being used, only the functionality. This should not interfere with the RFC 2037 Standard.
Comment 13 Alexey Ivanov 2015-03-26 09:11:21 MSK
Could you suggest some kind of test sequence?
Comment 14 Zombie Ryushu 2015-03-26 10:08:16 MSK
(In reply to comment #13)
> Could you suggest some kind of test sequence?

There are two instances where this can show if there are problems:

1. OpenLDAP (slapd) or Samba 4 just won't start. This is usually diagnosed with slapd -d 3. A Schema error will show up at that point.

2. Replication stops working with OpenLDAP. This usually happens because two LDAP servers are Mismatched, but if there are is a Schema error on one and not the other. Or one Database calls on Attributes that don't exist in the same fashion as the second database.

3. Added new entries to the tree throw Schema Violations for no reason even when you enter something correctly.
Comment 15 Alexey Ivanov 2015-03-26 13:54:06 MSK
I took another look on default configuration considering your question.

File nis.schema has this statement: "Definitions from RFC2307 (Experimental). An Approach for Using LDAP as a Network Information Service". But Samba team uses and advertises use of nis extensions. I think it can be considered pretty stable. And if I get it's purpose right it should do more or less something you desire.

As for misc.schema, it states that it is highly experimental and is not recommended to be used in production environment.  Schema definitions are a kind of formalized intentions and process of implementation may stray away. Unfortunately I don't see a way to be of much help to you with this. I'd suggest consulting with upstream software developers.


Now to our default configuration.

I intend to enable "core", "cosine", "inetorgperson" and "nis" schemas by default. This seems to be solid basic set. Most of the rest «core» schemas are rarely required and will be left commented-out.

Individual schema definitions from other project's sources will install along with openldap-servers as suggested packages. Schema files will be unpacked into configfile directory tree. User will have an option to include files of interest manually.
Comment 16 Zombie Ryushu 2015-03-26 23:55:52 MSK
I've found an issue. Upon updating Heimdal in Rosa 2014, Heimdal KDC failed to start stating that hdb_ldap.so could not be found. It can be woked around by symlinking hdb_ldap.so to /usr/lib64/ Then Heimdal will start again.
Comment 17 Zombie Ryushu 2015-03-27 00:02:46 MSK
There is something else we need to test for. DNS SRV record use. We should have to configure nslcd, ldap.conf, and krb5.conf as little as possible in a Domain. Bind DNS Should provide all necessary SRV records. For Samba 4 it does, for OpenLDAP+Heimdal+Samba most of the SRV records still work, but I know that in Heimdal-workstation, SRV record look up can be switched on and off, while MIT krb5-workstation seems to have it always on.
Comment 18 Alexey Ivanov 2015-03-27 09:37:39 MSK
(In reply to comment #16)
> I've found an issue. Upon updating Heimdal in Rosa 2014, Heimdal KDC failed
> to start stating that hdb_ldap.so could not be found. It can be woked around
> by symlinking hdb_ldap.so to /usr/lib64/ Then Heimdal will start again.

I am unable to reproduce. In my tests it both installs and upgrades well — ld reads configuration file and locates libs as expected:

[root@taf01 ~]# cat /etc/ld.so.conf.d/heimdal.conf 
/usr/lib64/heimdal
Comment 19 Alexey Ivanov 2015-03-27 09:41:20 MSK
UPD. It survives reboot as well:

[root@taf01 ~]# systemctl status heimdal.service                                                                                                                                                                                              
heimdal.service - LSB: Starts and stops the Heimdal kdc, and optionally kadmin, kpasswdd, ipropd-slave/ipropd-master etc.
   Loaded: loaded (/etc/rc.d/init.d/heimdal)
   Active: active (running) since Fri 2015-03-27 05:39:37 UTC; 41s ago
  Process: 238 ExecStart=/etc/rc.d/init.d/heimdal start (code=exited, status=0/SUCCESS)
   CGroup: /user.slice/user-500.slice/session-c1.scope/system.slice/heimdal.service
           └─253 /usr/sbin/kdc --detach

Mar 27 05:39:37 taf01 systemd[1]: Starting LSB: Starts and stops the Heimdal kdc, and optionally kadmin, kpasswdd, ipropd-slave/ipropd-master etc....
Mar 27 05:39:37 taf01 heimdal[238]: Starting Heimdal Kerberos 5 Key Distribution Center:[  OK  ]
Mar 27 05:39:37 taf01 systemd[1]: Started LSB: Starts and stops the Heimdal kdc, and optionally kadmin, kpasswdd, ipropd-slave/ipropd-master etc..
[root@taf01 ~]#
Comment 20 Alexey Ivanov 2015-03-30 12:40:09 MSD
(In reply to comment #17)
> There is something else we need to test for. DNS SRV record use. We should
> have to configure nslcd, ldap.conf, and krb5.conf as little as possible in a
> Domain. Bind DNS Should provide all necessary SRV records. For Samba 4 it
> does, for OpenLDAP+Heimdal+Samba most of the SRV records still work, but I
> know that in Heimdal-workstation, SRV record look up can be switched on and
> off, while MIT krb5-workstation seems to have it always on.

Does it directly relate with library conflict or schema files shipped?
I'm afraid this issue is getting too complicated. If it's another default configuration suggestion I'd prefer to review it separately.
Comment 21 Alexey Ivanov 2015-03-30 13:07:22 MSD
This is what is done at the moment:

— Heimdal and krb5 KDC are installable via an either/or setup. Respective workstation utilities are installable via an either/or setup too.

— Support Libraries for both are installable simultaneously.

— OpenLDAP is being built with Heimdal support, smbk5pwd.so gets linked against Heimdal libs (see container below).

I haven't been able to reproduce the issue you mentioned with Heimdal KDC not starting due to library not being found. And OpenLDAP builds with Heimdal support successfully. Seems like you are having some uncommon issue.

— Both kerberos.schema and hdb.schema get shipped along with openldap-servers via 'openldap-schemas-krb5' and 'openldap-schemas-heimdal' packages. The packages are a part of respective projects and contain relevant versions of schema files directly out-of-the-source.

— I have added other schemas you suggested to be shipped this way. Adding even more is not a problem. The list can be broadened at any point later.

This should cover about everything you reported initially.
I suppose to take course on closing this particular bugreport. Or it's outcome will get too complicated and very difficult for QA team to test it.


This is the build I have come up with:

https://abf.io/build_lists/2486213
https://abf.io/build_lists/2486214

It can be tested by adding these media (x86_64):

for i in 2486214 2475122 2475124 2477349 ; do urpmi.addmedia $i http://abf-downloads.rosalinux.ru/rosa2014.1/container/$i/x86_64/main/release/ ; done

or these (i586):

for i in 2486213 2475121 2475123 2477348 ; do urpmi.addmedia $i http://abf-downloads.rosalinux.ru/rosa2014.1/container/$i/i586/main/release/ ; done

Configuration mock-up has been updated appropriately:

https://gitlab.com/alexey.fqdn.co/openldap-default-config

Zombie Ryushu, have a look please.
Comment 22 Zombie Ryushu 2015-03-30 19:45:36 MSD
I looked at your configuration, seems pretty Straight Forward, however the add of your repository failed urpmi. (the $i part.)
Comment 23 Zombie Ryushu 2015-03-30 19:48:12 MSD
(In reply to comment #20)
> (In reply to comment #17)
> > There is something else we need to test for. DNS SRV record use. We should
> > have to configure nslcd, ldap.conf, and krb5.conf as little as possible in a
> > Domain. Bind DNS Should provide all necessary SRV records. For Samba 4 it
> > does, for OpenLDAP+Heimdal+Samba most of the SRV records still work, but I
> > know that in Heimdal-workstation, SRV record look up can be switched on and
> > off, while MIT krb5-workstation seems to have it always on.
> 
> Does it directly relate with library conflict or schema files shipped?
> I'm afraid this issue is getting too complicated. If it's another default
> configuration suggestion I'd prefer to review it separately.

No it does not. It only affects krb5.conf and ldap.conf.
Comment 24 Alexey Ivanov 2015-03-30 20:45:57 MSD
(In reply to comment #22)
> I looked at your configuration, seems pretty Straight Forward, however the
> add of your repository failed urpmi. (the $i part.)

It should work under Bash. Not sure for other interpreters. Let's put it simple then:

These containers are for x86_64:

urpmi.addmedia 2486214 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2486214/x86_64/main/release/
urpmi.addmedia 2475122 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2475122/x86_64/main/release/
urpmi.addmedia 2475124 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2475124/x86_64/main/release/
urpmi.addmedia 2477349 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2477349/x86_64/main/release/

and these are for i586:

urpmi.addmedia 2486213 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2486213/i586/main/release/
urpmi.addmedia 2475121 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2475121/i586/main/release/
urpmi.addmedia 2475123 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2475123/i586/main/release/
urpmi.addmedia 2477348 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2477348/i586/main/release/

As for the configuration… well, yes, is simple and straight-forward.
It should be nice simple starting point for fresh installations.
Comment 25 Zombie Ryushu 2015-03-30 21:14:08 MSD
Downloading now.
Comment 26 Zombie Ryushu 2015-03-30 21:19:11 MSD
Certain dependencies are not downloading due to transient internet conditions.
Comment 27 Zombie Ryushu 2015-03-30 22:05:41 MSD
Installation failed:
        file /usr/share/openldap/schema/ldapns.schema from install of openldap-schemas-2.4.40-9.x86_64 conflicts with file from package openldap-extra-schemas-1.3-15.noarch
Comment 28 Zombie Ryushu 2015-03-30 22:15:54 MSD
could not stat config file "/usr/share/openldap/schema/evolutionperson.schema": No such file or directory (2)
could not stat config file "/usr/share/openldap/schema/calendar.schema"
Comment 29 Zombie Ryushu 2015-03-30 22:20:57 MSD
(In reply to comment #28)
> could not stat config file
> "/usr/share/openldap/schema/evolutionperson.schema": No such file or
> directory (2)
> could not stat config file "/usr/share/openldap/schema/calendar.schema"

could not stat config file "/usr/share/openldap/schema/sudo.schema": No such file or directory (2)
could not stat config file "/usr/share/openldap/schema/dnszone.schema": No such file or directory (2)
Comment 30 Zombie Ryushu 2015-03-30 22:25:52 MSD
5519950c backend_startup_one: starting "cn=config"
5519950c ldif_read_file: no entry file "/etc/openldap/slapd.d/cn=config.ldif"
5519950c send_ldap_result: conn=-1 op=0 p=0
Comment 31 Zombie Ryushu 2015-03-30 22:36:44 MSD
A Schema error exists in urpmi.schema. priority Object Class was missing.
Comment 32 Zombie Ryushu 2015-03-30 22:43:38 MSD
Certain Parameters are not being passed by the LDAP AStartup script.
 /usr/sbin/slapd -u ldap -g ldap -l local4 -s 0 -h ldap:/// ldaps:/// ldapi:///
is only passing /usr/sbin/slapd -u ldap -g ldap (/etc/sysconfig/ldap is not being read. No ldapi means no Kerberos!
Comment 33 Zombie Ryushu 2015-03-30 23:01:04 MSD
I can't get it to start up ldaps or ldapi mode. ldapi mode is required for Heimdal to work correctly. ldaps is what everything else uses.
Comment 34 Zombie Ryushu 2015-03-30 23:34:29 MSD
Okay. I had to add -h ldap:/// ldaps:/// ldapi:/// to get ldaps (required for EVERYTHING and ldapi required for Kerberos) to get ldap working right again. But it seems okay now.
Comment 35 Zombie Ryushu 2015-03-31 00:15:08 MSD
The problems seem to be that because the Posix LDAP Script isn't being executed at all, really, that /etc/sysconfig/ldap isn't being parsed. that file was parsed by /etc/init.d/ldap not slapd itself.

printer.schema seems to be different. My 2012.1 server seems to think that printer.schema is a generic Printer schema written by RFC. My 2014.1 printer.schema seems unique to define CUPS Printers.

evolutionperson.schema, sudo.schema, samba.schema, dnszone.schema, calendar.schema were unaccounted for.
Comment 36 Zombie Ryushu 2015-03-31 00:18:12 MSD
Samba.schema has been renamed to samba4.schema. Thats why that happened.
Comment 37 Zombie Ryushu 2015-03-31 00:31:55 MSD
sudo.schema is not owned by any package (Probably should be from sudo)
calendar.schema is not owned by any package
dnszone.schema is not owned by any package (should come from Bind.)
Comment 38 Zombie Ryushu 2015-03-31 02:40:07 MSD
Heimdal appears to be starting too early in the process. I had to change the startup script to start later during boot up. And like OpenLDAP, Heimdal has to launch multiple Daemons (kadnins, kdc, kpasswdd) determined by /etc/sysconfig/heimdal and if this migrates to systemd, that won't be supported.
Comment 39 Alexey Ivanov 2015-03-31 09:20:34 MSD
(In reply to comment #27)
> Installation failed:
>         file /usr/share/openldap/schema/ldapns.schema from install of
> openldap-schemas-2.4.40-9.x86_64 conflicts with file from package
> openldap-extra-schemas-1.3-15.noarch
> could not stat config file "/usr/share/openldap/schema/evolutionperson.schema":
> No such file or directory (2)
> could not stat config file "/usr/share/openldap/schema/calendar.schema"
> could not stat config file "/usr/share/openldap/schema/sudo.schema":
> No such file or directory (2)
> could not stat config file "/usr/share/openldap/schema/dnszone.schema":
> No such file or directory (2)

These are connected. I have missed file conflict problem and 'openldap-extra-schemas' package ended up being removed on your system. If it didn't all files should have stayed in place. My bad.

> 5519950c backend_startup_one: starting "cn=config"
> 5519950c ldif_read_file: no entry file "/etc/openldap/slapd.d/cn=config.ldif"
> 5519950c send_ldap_result: conn=-1 op=0 p=0
> Certain Parameters are not being passed by the LDAP AStartup script.
> /usr/sbin/slapd -u ldap -g ldap -l local4 -s 0 -h ldap:/// ldaps:/// ldapi:///
> is only passing /usr/sbin/slapd -u ldap -g ldap (/etc/sysconfig/ldap is not being read. No ldapi means no Kerberos!
> Okay. I had to add -h ldap:/// ldaps:/// ldapi:/// to get ldaps (required for EVERYTHING and ldapi required for Kerberos) to get ldap working right again. But it seems okay now.
> The problems seem to be that because the Posix LDAP Script isn't being executed at all, really, that /etc/sysconfig/ldap isn't being parsed. that file was parsed by /etc/init.d/ldap not slapd itself.

This is weird as there is 'EnvironmentFile=/etc/sysconfig/ldap' string in ldap.service file. I'll check this.

> printer.schema seems to be different. My 2012.1 server seems to think that printer.schema is a generic Printer schema written by RFC. My 2014.1 printer.schema seems unique to define CUPS Printers.

I could have mixed these up. They are both 'printer.schema' files. Point me on the one you find most relevant. And even better on where it originates from.

> A Schema error exists in urpmi.schema. priority Object Class was missing.

This means 'urpmi-ldap' package is outdated too. URI pointing on correct schema file is welcome.

> Samba.schema has been renamed to samba4.schema.

In an effort to aviod conflict with 'openldap-extra-schemas' files. We can't barge in replacing files on live servers. This means 'openldap-extra-schemas' must stay unchanged where it is already installed and no files in /etc/openldap/ can be overwritten.
Everything new we bring should be placed along with old config. A lot of trouble for us but we absolutely can not allow trouble to happen to our users. See my mistake with conflicting file — outcome is absolutely destructive :)

> sudo.schema is not owned by any package (Probably should be from sudo)
> calendar.schema is not owned by any package
> dnszone.schema is not owned by any package (should come from Bind.)

These are part of 'openldap-extra-schemas'. I guess we need them updated too. Am I right?

> Heimdal appears to be starting too early in the process. I had to change the startup script to start later during boot up. And like OpenLDAP, Heimdal has to launch multiple Daemons (kadnins, kdc, kpasswdd) determined by /etc/sysconfig/heimdal and if this migrates to systemd, that won't be supported.

This should be thought out.
Comment 40 Zombie Ryushu 2015-03-31 09:39:50 MSD
The correct Cups Printer Schema is the one that Cups provides (possibly needs to be renamed cups.schema?) Its possible nothing uses that other one like nothing uses krb5-kdc.schema.

urpmi.schema error seems to require an attribute types (priority) that no schema provides. I removed the attribute type and the schema started working.

sudo should provide sudo.schema 

openldap-extra-schemas should be updated to not create Packaging conflicts.
Comment 41 Alexey Ivanov 2015-03-31 09:47:47 MSD
(In reply to comment #40)
> openldap-extra-schemas should be updated to not create Packaging conflicts.

It's been out there for quite some time. God knows how many people rely on it. Most probably close to none as some of it's contents are outdated but we cannot be sure. If we change it then files that are part of live server configurations will get rewritten with new ones. Outcome of this could be destructive. I prefer we built around it leaving 'openldap-extra-schemas' in place without changing it.
Comment 42 Alexey Ivanov 2015-03-31 10:24:28 MSD
There is another problem with 'openldap-extra-schemas' and OpenLDAP configuration it was built for.

For some reason it was suggested that:
> ### Standard schemas should not be changed by users
and schema files got loaded into server configuration from /var/lib/openldap/schema

Don't know how this could stop user with root privileges from editing files, but it makes maintaining 'openldap-extra-schemas' dangerous. Package upgrades lead to changing live user configurations. On running servers. This leaves a feeling that years ago OpenLDAP was destined to serve distribution rather then users.

I don't want to say that it was badly configured. This old config surely is rich and could have been very convenient. But it's outdated. Dummy schema 'krb5-kdc.schema' you mentioned has an interesting string in it's header:
> # $Id: hdb.schema,v 1.3 2000/02/22 21:51:53 lukeh Exp $
Could it be a very old heimdal schema?

Our efforts are not going to be lost in vain. OpenLDAP must be refreshed.
But the path is painful. I don't see any other options other then leaving 'openldap-extra-schemas' as it is and building around. Even though it makes process a bit messy.
Comment 43 Zombie Ryushu 2015-03-31 12:02:05 MSD
Thats fine. If Cups' printer.schema becomes cups.schema, I'm fine with that. 
if the Bind provided DNS Schema needs to be called named.schema, thats fine.


As for the ldap systemctl service file, I fixed it by adding "-h ldap:/// ldaps:/// ldapi:///" on my system. But this way it won't launch if your LDAP TLS Config isn't setup right. Oh. Try and make sure that the TLS Certificates reflect Certificates that actually exists. They should be called ldap.pem)

urpmi.schema could just have an error in it. I found I had edited it on my 2012.1 DC as well. 

for sudo, check and see if they aren't the same file? samba.schema from Samba 3  and samba4.schema turned out to be the same file.
Comment 44 Alexey Ivanov 2015-03-31 12:27:38 MSD
(In reply to comment #43)

> As for the ldap systemctl service file, I fixed it by adding "-h ldap:///
> ldaps:/// ldapi:///" on my system. But this way it won't launch if your LDAP
> TLS Config isn't setup right.

Environment file gets loaded successfully. But as you noted before slapd does not rely on environment variables. Something should read them and form correct command-line parameters.

The move to systemd is inevitable so we have to pull out this transition.

I think to add SLAPDARGS variable to /etc/sysconfig/ldap and postinstall script that
1) reads the following variables:
 SLAPDSYSLOGLEVEL
 SLAPDSYSLOGLOCALUSER
 SLAPDURLLIST
 SLAPDCONF
 LDAPUSER
 LDAPGROUP (am I missing something?)
2) constructs SLAPDARGS out of them,
3) adds it to /etc/sysconfig/ldap and
4) announces listed vars as deprecated and dropped.

This single variable can then be passed to ldap.service like this:
ExecStart=/usr/sbin/slapd $SLAPDARGS

> Oh. Try and make sure that the TLS
> Certificates reflect Certificates that actually exists. They should be
> called ldap.pem)

This is what we have by default:

>ldap.conf:TLS_CACERT      /etc/pki/tls/certs/ldap.pem

It gets created by fresh installation process:

>Generating a 1024 bit RSA private key
>............++++++
>...............++++++
>writing new private key to '/etc/pki/tls/private/ldap.pem'
>-----

Is this path outdated too? Is there better default path?
Comment 45 Zombie Ryushu 2015-03-31 21:34:05 MSD
Yes. That certificate path is correct to the best of my knowledge. 

And other Arguments are:

SLAPDSYSLOGLEVEL
LDAPUSER
LDAPGROUP
FIXPERMS
AUTORECOVER
RUN_DB_BACKUP
KEEP_ARCHIVES_DAYS
MAXFILES

If we have to move back to an init script, thats fine.
Comment 46 Alexey Ivanov 2015-04-01 08:09:14 MSD
(In reply to comment #45)

We'll have to migrate from initscripts to systemd eventually. Why not doing it now?

> And other Arguments are:
> 
> SLAPDSYSLOGLEVEL
> LDAPUSER
> LDAPGROUP
> FIXPERMS
> AUTORECOVER
> RUN_DB_BACKUP
> KEEP_ARCHIVES_DAYS
> MAXFILES

Daemon-related arguments are:
 SLAPDSYSLOGLEVEL
 SLAPDSYSLOGLOCALUSER
 SLAPDURLLIST
 SLAPDCONF
 LDAPUSER
 LDAPGROUP

These should be packed in single variable so that we could call slapd like this:
ExecStart=/usr/sbin/slapd $SLAPDARGS

FIXPERMS, AUTORECOVER and MAXFILES are init-script specific.
If we keep corresponding functionality then we should use some ExecStartPre= script.

RUN_DB_BACKUP and KEEP_ARCHIVES_DAYS control cronjob behaviour.
These should be kept in place.
Comment 47 Alexey Ivanov 2015-04-01 15:51:59 MSD
OK, here goes another shot.

File conflict is resolved.
Old configuration requires that schema files get placed to /usr/share/openldap/schema/ and get included from there. This behaviour is not safe and not recommended by rpm. We'll drop it for new default config. Old schema files are being left intact where they are. New schema files get installed into /etc/openldap/slapd.d with %config(replace) macro to make sure nothing vital ever gets rewriten on live systems.
At the same time we solve file name collisions. This way we are not forced to rename schema files any more as they are placed into different directories. That's a relief!

I have added schema files you mentioned.
Urpmi.schema is problematic, it breaks whole configuration and prevents slapd from starting. But it is the latest version of the schema. Looks like it's just incomplete, work on ldap support for urpmi hasn't gotten finished for some reason. We have to either drop or fix it. Patches are welcome :)
All the rest schema files at least seem not to break slapd.

I have changed default environment file by introducing SLAPDARGS variable. Postinstall script for 'openldap-servers' now detects old-style env vars, constructs and adds SLAPDARGS so that it is generally equal to old configuration.
Variables RUN_DB_BACKUP and KEEP_ARCHIVES_DAYS are kept in place and do the same job they did before.
MAXFILES variable was converted into LimitNOFILE=4096 (see /lib/systemd/system/ldap.service).
As for FIXPERMS and AUTORECOVER I'm not sure we have to keep this functionality. Openldap 2.3.+ Seems not to require AUTORECOVER. FIXPERMS offers excess funtionality in my opinion.

Containers for x86_64:

urpmi.addmedia 2486835 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2486835/x86_64/main/release/
urpmi.addmedia 2486784 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2486784/x86_64/main/release/
urpmi.addmedia 2486782 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2486782/x86_64/main/release/
urpmi.addmedia 2486929 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2486929/x86_64/main/release/

Containers for i586:

urpmi.addmedia 2486834 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2486834/i586/main/release/
urpmi.addmedia 2486928 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2486928/i586/main/release/
urpmi.addmedia 2486783 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2486783/i586/main/release/
urpmi.addmedia 2486781 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2486781/i586/main/release/

Configuration mock-up has been updated once again:

https://gitlab.com/alexey.fqdn.co/openldap-default-config

Zombie Ryushu, have a look please.
Comment 48 Zombie Ryushu 2015-04-01 16:26:04 MSD
I find that urpmi.schema works if you remove that priority statement from the MAY section.
Comment 49 Alexey Ivanov 2015-04-01 16:28:58 MSD
I'd be grateful if you commit it here:

https://gitlab.com/alexey.fqdn.co/openldap-default-config
Comment 50 Zombie Ryushu 2015-04-02 00:06:22 MSD
urpmi just says the packages are up to date.
Comment 51 Zombie Ryushu 2015-04-02 06:37:51 MSD
Okay, I'm really starting to lose my mind with git. I managed to get ssh working. but it wouldn't let me upload with fatal: protocol error: bad line length character: No s.

So I'm including a diff for urpmi.schema
Comment 52 Zombie Ryushu 2015-04-02 06:38:53 MSD
Created attachment 3861 [details]
urpmi Schema DIFF

urpmi Schema DIFF
Comment 53 Alexey Ivanov 2015-04-02 08:19:26 MSD
(In reply to comment #50)

Thank you for the patch. It's been applied for new build (see below).

> urpmi just says the packages are up to date.

I have raised Release for all containers listed below. The packages should upgrade under any circumstances now.

x86_64:

urpmi.addmedia 2487123 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2487123/x86_64/main/release/
urpmi.addmedia 2487121 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2487121/x86_64/main/release/
urpmi.addmedia 2487119 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2487119/x86_64/main/release/
urpmi.addmedia 2487117 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2487117/x86_64/main/release/

i586:

urpmi.addmedia 2487122 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2487122/i586/main/release/
urpmi.addmedia 2487120 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2487120/i586/main/release/
urpmi.addmedia 2487118 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2487118/i586/main/release/
urpmi.addmedia 2487116 http://abf-downloads.rosalinux.ru/rosa2014.1/container/2487116/i586/main/release/
Comment 54 Zombie Ryushu 2015-04-02 23:12:27 MSD
Okay so we fixed one problem, slapd starts with all arguements. 

Heimdal still launches too early. So Heimdal gives the error:

kinit: krb5_get_init_creds: unable to reach any KDC in realm
0:00 /usr/sbin/kdc --detach

Even though the kdc process is running. Heimdal functions fine after a restart. Heimdal may need to be transferred to a systemctl service, but keep in mind that Heimdal is multiple Daemons.there is an /etc/sysconfig/heimdal config file that must be Parsed.

Now the biggest problem:

I think moving the core schemas out of /usr/share/openldap/schemas was a bad idea. LDAP won't start until I copy them back.
Comment 55 Alexey Ivanov 2015-04-03 07:00:52 MSD
(In reply to comment #54)
> Okay so we fixed one problem, slapd starts with all arguements. 
> 
> Heimdal still launches too early. So Heimdal gives the error:
> 
> kinit: krb5_get_init_creds: unable to reach any KDC in realm
> 0:00 /usr/sbin/kdc --detach
> 
> Even though the kdc process is running. Heimdal functions fine after a
> restart. Heimdal may need to be transferred to a systemctl service, but keep
> in mind that Heimdal is multiple Daemons.there is an /etc/sysconfig/heimdal
> config file that must be Parsed.

OK, I'm on it.

> Now the biggest problem:
> 
> I think moving the core schemas out of /usr/share/openldap/schemas was a bad
> idea. LDAP won't start until I copy them back.

This is really easy to fix. We'll put core schemas to both locations so that old configs do not break.
Comment 57 Zombie Ryushu 2015-04-04 03:23:05 MSD
kdc systemd service doesn't pass the --detach parameter. I have no idea what affect if any this has, I'm testing right now
Comment 58 Zombie Ryushu 2015-04-04 06:01:32 MSD
Two things. hdb.schema had to be copied to the legacy path of /usr/share/openldap/schemas

I'm not sure if kadmin is actually launching but kdc and kpasswdd start fine.
Comment 59 Alexey Ivanov 2015-04-04 09:17:11 MSD
(In reply to comment #57)
> kdc systemd service doesn't pass the --detach parameter. I have no idea what
> affect if any this has, I'm testing right now

Systemd supports non-detaching processes. And even kinda encourages. It is easy to manage — no need to detect forking and look after children. And if user adds --detach parameter manually it should still work as expected — systemd is able to detect this change in behaviour. Or at least it should.
Comment 60 Alexey Ivanov 2015-04-04 09:24:13 MSD
(In reply to comment #58)
> Two things. hdb.schema had to be copied to the legacy path of
> /usr/share/openldap/schemas

openldap-extra-schemas does not ship hdb.schema file:

> [alexey@melchior ~]$ urpmq openldap-extra-schemas -l | grep -ic hdb
> 0

You have got hdb.schema placed to the legacy path while testing one of previous containers. So this is our testing course issue.
New packages shouldn't really place there anything. There could be schema files placed manually. We don't want go replacing these.
Comment 61 Zombie Ryushu 2015-04-10 22:22:30 MSD
Based on my tests I believe I can be sure this configuration works as intended: I can kinit, ldapsearch, and control my Samba Classic Domain backended by OpenLDAP and Heimdal Kerberos. smbclient works against OpenLDAP and can use Heimdal Kerberos with GSSAPI. My Schemas are fully up-to-date and reflect accurately the state of the applications they are associated with.
Comment 62 Zombie Ryushu 2015-04-10 22:22:46 MSD
Please send to QA.
Comment 63 Alexey Ivanov 2015-04-14 11:59:21 MSD
This is a complex upgrade.
For the goal to be achieved several packages have been upgraded.

Heimdal is a contributed package. It does not require to be passed through QA procedures. So I have published it based on my and Zombie Ryushu's tests which seem OK.

All the rest packages get benefits from Heimdal upgrade and have been upgraded accordingly. These packages do require QA testing. See the list below.

====================================

OpenLDAP

Build lists:
https://abf.io/build_lists/2490162
https://abf.io/build_lists/2490163

Advisory:
************************************
Fix security vulnerability CVE-2015-1545
Built with Heimdal support, full smbk5passwd support restored.
Initialization processes completely migrated to systemd.
Cleaner default configuration for new installations.
Schema file definitions collection has been reworked. Old solid package 'openldap-extra-schemas' is generally outdated and is not a hard requirement any more. Schema files get shipped as a set of suggested 'openldap-schemas-%{name}' packages.
************************************

CVE-2015-1545 bugfix applied as requested in Bug 5373:
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=c32e74763f77675b9e144126e375977ed6dc562c

Some other issues have been addressed that are probably not big enough to be listed in advisory:

Default installation did not initialize database properly which led to slapd not being able to start — fixed.
Default installation missed requirement on openssl which caused postinstall script to fail with «cannot create rsa key» — fixed.

====================================

Samba

Build lists:
https://abf.io/build_lists/2487120
https://abf.io/build_lists/2487121

Advisory:
************************************
New package: openldap-schemas-samba. Schema files to be (optionally) included into default OpenLDAP configuration.
************************************

No changes made to existing samba packages. Just one new package with several files:

urpmq -l ./openldap-schemas-samba-4.1.17-9-rosa2014.1.noarch.rpm 
/etc/openldap/schema/README.samba
/etc/openldap/schema/samba.ldif
/etc/openldap/schema/samba.schema
/etc/openldap/slapd.d/samba.conf

====================================

krb5

Build lists:
https://abf.io/build_lists/2487118
https://abf.io/build_lists/2487119

Advisory:
************************************
New package: openldap-schemas-krb5. Schema files to be (optionally) included into default OpenLDAP configuration.
************************************

No changes made to existing krb5 packages. Just one new package with several files:

urpmq -l ./openldap-schemas-krb5-1.12.2-17-rosa2014.1.noarch.rpm 
/etc/openldap/schema/kerberos.ldif
/etc/openldap/schema/kerberos.schema
/etc/openldap/slapd.d/krb5.conf

====================================

dhcp

Build lists:
https://abf.io/build_lists/2487116
https://abf.io/build_lists/2487117

Advisory:
************************************
Upgrade dhcp to version 4.3.2.
Fix problem with starting dhcpd and dhcrelay after installation.
Fix warnings thrown by dhcpd due to error in default configuration.
New package: openldap-schemas-dhcp. Schema files to be (optionally) included into default OpenLDAP configuration.
************************************

DHCP version has been upgraded as requested in Bug 5190.
An a new package with several files added:

urpmq -l ./openldap-schemas-dhcp-4.3.2-7-rosa2014.1.noarch.rpm 
/etc/openldap/schema/README.dhcp
/etc/openldap/schema/dhcp.schema
/etc/openldap/slapd.d/dhcp.conf

====================================

Some more details.

Tests have failed for latter three projects. It is normal as 'openldap-schemas-%{name}' packages depend on 'openldap-config' which is being introduced just now. Dependencies should be OK when all four project's containers are available simultaneously.

There is one more aspect that is particularly important: existing configuration should not be altered under any circumstances.

Both fresh installation and upgrade processes should not conflict in any way with 'openldap-extra-schemas' package. The latter is outdated, deprecated and being dropped. It is not required any more. But it should stay in place if it is already installed as it is a part of old default configuration and it could still be depended on.

Config files under /etc/ should not be overwritten by upgrade process. I have replaced all %config macros with %config(noreplace). But it never hurts to pay additional attention. When upgrade process installs new files around existing ones is OK. But there must be no replaces.
Comment 64 Alexey Ivanov 2015-04-14 12:02:25 MSD
*** Bug 5373 has been marked as a duplicate of this bug. ***
Comment 65 Alexey Ivanov 2015-04-14 12:03:29 MSD
*** Bug 5190 has been marked as a duplicate of this bug. ***
Comment 66 Vladimir Potapov 2015-04-15 15:36:16 MSD
samba x64 testes not ok
Comment 67 Alexey Ivanov 2015-04-15 16:43:32 MSD
(In reply to comment #66)
> samba x64 testes not ok

I told about it in advance:

> Tests have failed for latter three projects. It is normal as
> 'openldap-schemas-%{name}' packages depend on 'openldap-config' which is
> being introduced just now. Dependencies should be OK when all four project's
> containers are available simultaneously.

Alright. I'll rebuild.
Comment 68 Alexey Ivanov 2015-04-15 17:11:28 MSD
I have rebuilt samba, dhcp and krb5 with new build of openldap attached as a container.

This solves test problems.

====================================

OpenLDAP

Build lists:
https://abf.io/build_lists/2490162
https://abf.io/build_lists/2490163

Advisory:
************************************
Fix security vulnerability CVE-2015-1545
Built with Heimdal support, full smbk5passwd support restored.
Initialization processes completely migrated to systemd.
Cleaner default configuration for new installations.
Schema file definitions collection has been reworked. Old solid package 'openldap-extra-schemas' is generally outdated and is not a hard requirement any more. Schema files get shipped as a set of suggested 'openldap-schemas-%{name}' packages.
************************************

CVE-2015-1545 bugfix applied as requested in Bug 5373:
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=c32e74763f77675b9e144126e375977ed6dc562c

Some other issues have been addressed that are probably not big enough to be listed in advisory:

Default installation did not initialize database properly which led to slapd not being able to start — fixed.
Default installation missed requirement on openssl which caused postinstall script to fail with «cannot create rsa key» — fixed.

====================================

Samba

Build lists:
https://abf.io/build_lists/2490936
https://abf.io/build_lists/2490937

Advisory:
************************************
New package: openldap-schemas-samba. Schema files to be (optionally) included into default OpenLDAP configuration.
************************************

No changes made to existing samba packages. Just one new package with several files:

urpmq -l ./openldap-schemas-samba-4.1.17-9-rosa2014.1.noarch.rpm 
/etc/openldap/schema/README.samba
/etc/openldap/schema/samba.ldif
/etc/openldap/schema/samba.schema
/etc/openldap/slapd.d/samba.conf

====================================

krb5

Build lists:
https://abf.io/build_lists/2490940
https://abf.io/build_lists/2490941

Advisory:
************************************
New package: openldap-schemas-krb5. Schema files to be (optionally) included into default OpenLDAP configuration.
************************************

No changes made to existing krb5 packages. Just one new package with several files:

urpmq -l ./openldap-schemas-krb5-1.12.2-17-rosa2014.1.noarch.rpm 
/etc/openldap/schema/kerberos.ldif
/etc/openldap/schema/kerberos.schema
/etc/openldap/slapd.d/krb5.conf

====================================

dhcp

Build lists:
https://abf.io/build_lists/2490938
https://abf.io/build_lists/2490939

Advisory:
************************************
Upgrade dhcp to version 4.3.2.
Fix problem with starting dhcpd and dhcrelay after installation.
Fix warnings thrown by dhcpd due to error in default configuration.
New package: openldap-schemas-dhcp. Schema files to be (optionally) included into default OpenLDAP configuration.
************************************

DHCP version has been upgraded as requested in Bug 5190.
An a new package with several files added:

urpmq -l ./openldap-schemas-dhcp-4.3.2-7-rosa2014.1.noarch.rpm 
/etc/openldap/schema/README.dhcp
/etc/openldap/schema/dhcp.schema
/etc/openldap/slapd.d/dhcp.conf

====================================

Some more details.

Tests have failed for latter three projects. It is normal as 'openldap-schemas-%{name}' packages depend on 'openldap-config' which is being introduced just now. Dependencies should be OK when all four project's containers are available simultaneously.

There is one more aspect that is particularly important: existing configuration should not be altered under any circumstances.

Both fresh installation and upgrade processes should not conflict in any way with 'openldap-extra-schemas' package. The latter is outdated, deprecated and being dropped. It is not required any more. But it should stay in place if it is already installed as it is a part of old default configuration and it could still be depended on.

Config files under /etc/ should not be overwritten by upgrade process. I have replaced all %config macros with %config(noreplace). But it never hurts to pay additional attention. When upgrade process installs new files around existing ones is OK. But there must be no replaces.
Comment 69 Vladimir Potapov 2015-04-22 14:17:14 MSD
The update is sent to expanded testing
**************************************
Comment 70 Vladimir Potapov 2015-04-27 10:02:32 MSD
openldap-2.4.40-12
https://abf.io/build_lists/2490162
https://abf.io/build_lists/2490163

samba-4.1.17-9
https://abf.io/build_lists/2487120
https://abf.io/build_lists/2487121

krb5-1.12.2-17
https://abf.io/build_lists/2490940
https://abf.io/build_lists/2490941

dhcp-4.3.2-7
https://abf.io/build_lists/2490938
https://abf.io/build_lists/2490939
************* Advisory ***********************
openLDAP: Fix security vulnerability CVE-2015-1545
Built with Heimdal support, full smbk5passwd support restored.
Initialization processes completely migrated to systemd.
Cleaner default configuration for new installations.
Schema file definitions collection has been reworked. Old solid package 'openldap-extra-schemas' is generally outdated and is not a hard requirement any more. Schema files get shipped as a set of suggested 'openldap-schemas-%{name}' packages.

samba: Fix security vulnerability CVE-2015-1545 Built with Heimdal support, full smbk5passwd support restored. Initialization processes completely migrated to systemd. Cleaner default configuration for new installations.
Schema file definitions collection has been reworked. Old solid package 'openldap-extra-schemas' is generally outdated and is not a hard requirement any more. Schema files get shipped as a set of suggested 'openldap-schemas-%{name}' packages.

krb5: New package: openldap-schemas-krb5. Schema files to be (optionally) included into default OpenLDAP configuration.

dhcp: Upgrade dhcp to version 4.3.2. Fix problem with starting dhcpd and dhcrelay after installation. Fix warnings thrown by dhcpd due to error in default configuration. New package: openldap-schemas-dhcp. Schema files to be (optionally) included into default OpenLDAP configuration.
**************************************************
QA Verified
Comment 71 Alexey Ivanov 2015-04-27 10:07:31 MSD
> ************* Advisory ***********************
... 
> samba: Fix security vulnerability CVE-2015-1545 Built with Heimdal support,
> full smbk5passwd support restored. Initialization processes completely
> migrated to systemd. Cleaner default configuration for new installations.
> Schema file definitions collection has been reworked. Old solid package
> 'openldap-extra-schemas' is generally outdated and is not a hard requirement
> any more. Schema files get shipped as a set of suggested
> 'openldap-schemas-%{name}' packages.
> 
> **************************************************

Oh, Samba advisory is shorter:

Advisory:
************************************
New package: openldap-schemas-samba. Schema files to be (optionally) included into default OpenLDAP configuration.
************************************

Your variant is a copy of OpenLDAP advisory.