Can I fix the schema in my current version 2.0.0? If so how do I do this?

On Wed, Jan 20, 2016 at 7:04 PM, Emmanuel Lécharny <elecha...@gmail.com>
wrote:

> Le 20/01/16 23:16, Stefan Seelmann a écrit :
> > On 01/19/2016 02:46 PM, Sherman Lilly wrote:
> >> I have got my schemas installed and working and the directory server is
> >> working properly. I am trying to add a value to "dhcpOption" and it will
> >> only accept a binary value. I figured out the value has to be utf8
> encoded
> >> value. How do I use Directory Studio to insert this value? Let say the
> >> string is "broadcast 192.168.255.255". Not really sure how to convert
> that
> >> to utf8 encoded binary and insert it into "dhcpOption" thorugh Directory
> >> Studio.
> >>
> >> Any help is appreciated.
> > First I have to tell you that the DHCP (and also DNS) servers are not
> > maintained since years, I not even can find any server-side integration
> > test that tests the functionality. So very likely those won't work at
> > all or include major bugs. Help to test, fix, and document is however
> > appreciated :)
>
> indeed...
> >
> > I just tried to add a "dhcpOption" value with Studio. As this attribute
> > is of syntax octet string the Hex Editor opens. I then choosed the "Edit
> > as Text" option. The resulting binary is a proper UTF-8 encoded value.
> > But when saving that there is an error on server side, I think that is a
> > bug in the LDAP API.
>
> No, it's a bug in the schema definition. I think we took it from
> https://www.ietf.org/proceedings/53/I-D/draft-ietf-dhc-ldap-schema-00.txt,
> where it says :
>
> ( 2.16.840.1.113719.1.203.4.7
>   NAME 'dhcpOption'
>   DESC 'Encoded optio values to be sent to clients.  Each value represents
> a single option and contains (OptionTag, Length, OptionValue) encoded in
> the format used by DHCP.'
>   SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
>
> Our definition is slightly different :
>
> attributetype ( 2.16.840.1.113719.1.203.4.7
>         NAME 'dhcpOption'
>         DESC 'Encoded option values to be sent to clients. Each value
> represents a single option and contains (OptionTag, Length, OptionValue)
> encoded in the format used by DHCP.'
>         EQUALITY caseIgnoreIA5Match
>         SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
>  )
>
> The pb is that using a caseIgnoreIA5Match matching rule for a OCTET STRING
> syntax is simply not working, and leads to an error when we try to inject a
> dhcpOption in the server.
>
>
> The only way to get this fixed would be to fix the schema, and use a
> 1.3.6.1.4.1.1466.115.121.1.26 Syntax (IA5String).
>
> We can do that...
>
>

Reply via email to