Bug 1184938

Created attachment 984557 [details]
openssh-lpk-openldap.ldif

Thank you for suggestion. I tried to create ldif file from schema, but I can't say if it works correctly. Can you have a look at attached file?

That loaded fine for me in my test OpenLDAP server.

My only suggestion is perhaps the "-openldap" in the dn/cn is unnecessary? So instead of it being "cn=openssh-lpk-openldap" it's just "cn=openssh-lpk"

In current version, there are two versions of .schema files, one for openldap, second for Sun/Oracle. I'm not knowledgeable about differences in .ldif files between these systems, but if you can confirm that there is no such difference in .ldif syntax like in .schema syntax, we can drop "-openldap" substring, I guess.

Hi Jan,
please take a look at #c3 and #c4. What do you think would be appropriate cn? I would be rather careful and keep the openldap suffix in place.

My point was that having the name of the directory server in the schema DN/CN is a bit redundant when none of the other schemas have the name of the directory server in them, at least for OpenLDAP anyway so it just looks a bit odd.

But by all means have 2 (or 4) schema files in the package named openssh-lpk-{openldap,sun}.{schema,ldif} if separate files are needed. I've just checked the schema in the FreeRadius package and for iPlanet/Sun, there's no schema-specific DN at all, it looks to be imported directly on the cn=schema object so I don't think there would be in any harm in doing this.

You are right Matt, thanks for clarifying it.

(In reply to Karel Srot from comment #6)
> Hi Jan,
> please take a look at #c3 and #c4. What do you think would be appropriate
> cn? I would be rather careful and keep the openldap suffix in place.

From the openldap's point of view, the suffix doesn't really matter. However, if the file's name is "openssh-lpk-openldap.ldif", I would leave it there, unless you want to also rename the file. But that's just a matter of personal preference.

The thing is, that *.schema files have different syntax for sun/openldap and the CN was not in schema files.
If I got it right, "Sun ONE Directory Server is compliant with this standard." [1]. So if *.ldif files have the same syntax for both, we can create only one file and remove suffix to make it easy and clear. If not, we should provide two files. Jan, what do you think?

[1] https://docs.oracle.com/cd/E19199-01/816-6699-10/ax_ldif.html#14301

LDIF is a standard (RFC 2849), so if the Sun DS implements it, it should be ok to have only one ldif for both. The only problem I can see is that the Sun DS doesn't have to necessarily recognize that distinguished names ending with ",cn=schema,cn=config" are schema definitions. I *think* that it depends on the server's implementation and is not specified anywhere. But that can be pretty easily tested.

Look at what the FreeRadius package does. There are two LDIF files, one each for both OpenLDAP and iPlanet/Sun. The OpenLDAP version installs the schema at cn=radius,cn=schema,cn=config, iPlanet/Sun installs the schema at cn=schema.

So I think there still needs to be two LDIF files. LDIF is a standard but it doesn't standardise what the content is or how it is organised in the DIT, just how it is formatted.

When I compare FreeRadius LDIF files, there are again some differences including:
 * above mentioned dn/cn
 * attributeTypes x olcAttributeTypes
 * objectClasses x olcObjectClasses
 * different syntax (sun is missing {n}

I tried to incorporate it into these ldif files and I would if somebody could tell if it works as supposed:

$ cat openssh-6.6p1/openssh-lpk-sun.ldif
dn: cn=schema
attributeTypes: ( 1.3.6.1.4.1.24552.500.1.1.1.13
 NAME 'sshPublicKey' DESC 'MANDATORY: OpenSSH Public key'
 EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
objectClasses: ( 1.3.6.1.4.1.24552.500.1.1.2.0
 NAME 'ldapPublicKey' DESC 'MANDATORY: OpenSSH LPK objectclass'
 SUP top AUXILIARY MUST ( sshPublicKey $ uid ) )


$ cat openssh-6.6p1/openssh-lpk-openldap.ldif
dn: cn=openssh-lpk,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: openssh-lpk
olcAttributeTypes: {0}( 1.3.6.1.4.1.24552.500.1.1.1.13
 NAME 'sshPublicKey' DESC 'MANDATORY: OpenSSH Public key'
 EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
olcObjectClasses: {0}( 1.3.6.1.4.1.24552.500.1.1.2.0
 NAME 'ldapPublicKey' DESC 'MANDATORY: OpenSSH LPK objectclass'
 SUP top AUXILIARY MUST ( sshPublicKey $ uid ) )

Watch out for leading spaces in the LDIF file. Any line indented by a single space is joined to the previous line without that space so for example the OID and name are joined on import like so "...1.3.6.1.4.1.24552.500.1.1.1.13NAME 'ssh...".

When I dump the schema from my test instance it looks like this:

# {4}openssh-lpk, schema, config
dn: cn={4}openssh-lpk,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: {3}openssh-lpk
olcAttributeTypes: {0}( 1.3.6.1.4.1.24552.500.1.1.1.13 NAME 'sshPublicKey' DES
 C 'MANDATORY: OpenSSH Public key' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.
 1.1466.115.121.1.40 )
olcObjectClasses: {0}( 1.3.6.1.4.1.24552.500.1.1.2.0 NAME 'ldapPublicKey' DESC
  'MANDATORY: OpenSSH LPK objectclass' SUP top AUXILIARY MUST ( sshPublicKey $
  uid ) )

So if you indent the indented lines with a further space that should preserve the literal spaces.

Unfortunately I can't test the Sun schema.

Ignore the {3/4} mixup, that was a copy & paste error. My schema isn't that broken ;-)

Your LDIF schema file is correct in that it shouldn't specify a position for the actual schema object, OpenLDAP will add that automatically on import.

Thanks for comments. I will fix that. Adding additional space should do it.
I also got similar result from some conversion tool, but I wanted to have it more readable (newlines in the middle of words just does not feel right for me :)).

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-2088.html