Hi!
Excuse me for the way I explain myself (obviously bad). I mean:
1.- I have apply the syntax modification for nsViewFilter like this:
ldapadd ... << EOF
dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 2.16.840.1.113730.3.1.3023 NAME 'nsViewFilter' DESC
'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN 'Netscape Directory Server' )
-
EOF
2.- I want to revert this change, that is, I wan to use the syntax in
the 02common.ldif (the original) for this attribute, and erase the
entry in 99user.ldif for this attribute. I can delete it because of
the MAY clause in objectClasses. I can't stop the DS and remove the
line in the file because of schema replication. Can I perform this???
How???
I don't know if this will work:
ldapadd ... << EOF
dn: cn=schema
changetype: modify
delete: attributeTypes
attributeTypes: ( 2.16.840.1.113730.3.1.3023 NAME 'nsViewFilter' DESC
'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN 'Netscape Directory Server' )
-
EOF
If not, then it looks like you're out of luck - please file a ticket
I need to know how to do this (if possible) due to conflicts with some
application or error which could appear.
Regards,
Moses.
2012/4/30 Rich Megginson <rmeggins(a)redhat.com
<mailto:rmeggins@redhat.com>>
On 04/30/2012 01:01 AM, Moisés Barba Pérez wrote:
> Hi,
>
> you are absolutely right and I can understand that behaviour with
> syntax. The thing is: I want to recover the original syntax, the
> 02common one, how can I do that? I can't use replace obviously,
> add will not recover the original, Is there some way to procced?
Recover from what? Where is the definition it is using now? How
did you change it?
>
> In the mail issue:
>
> The entry has the attribute -> mail:mBarbA.MaiL@xxxx
> The access log
>
> [30/Apr/2012:08:41:02 +0200] conn=6019 op=1 SRCH base="xxxx"
> scope=2
> filter="(&(objectClass=posixAccount)(mail=mbarba.mail@xxxx))"
> attrs=ALL
> [30/Apr/2012:08:41:02 +0200] conn=6019 op=1 RESULT err=0 tag=101
> nentries=0 etime=0
>
>
> [30/Apr/2012:08:51:52 +0200] conn=6040 op=1 SRCH base="xxxx"
> scope=2
> filter="(&(objectClass=posixAccount)(mail=mBarbA.MaiL@xxxx))"
> attrs=ALL
> [30/Apr/2012:08:51:52 +0200] conn=6040 op=1 RESULT err=0 tag=101
> nentries=1 etime=0
>
> I can't upgrade the version of DS by the moment, I have the
> upgrade in mind but not possible yet. Any idea about how to
> change this to case-insensitive???
The definition for the mail attribute comes from RFC 4524 -
http://www.ietf.org/rfc/rfc4524.txt
2.16. mail
The 'mail' (rfc822mailbox) attribute type holds Internet mail
addresses in Mailbox [RFC2821] form (e.g.,user(a)example.com
<mailto:user@example.com>).
( 0.9.2342.19200300.100.1.3 NAME 'mail'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules
are
described in [RFC4517].
In 389 (current version) this definition is in 05rfc4524.ldif
Note that if you change this to use DirectoryString (full utf-8
character range) instead of IA5String (7-bit ascii only) you will
leave yourself open to having interoperability issues with other
software that expect the standard behavior.
>
> Regards,
> Moses
>
>
> 2012/4/27 Noriko Hosoi <nhosoi(a)redhat.com
<mailto:nhosoi@redhat.com>>
>
> Hi Moisés,
>
> Moisés Barba Pérez wrote:
>> Hi,
>>
>> I have replaced the OID and now there is no syntax error.
>> The ticket is
https://fedorahosted.org/389/ticket/349.
> Thanks!
>
>>
>> I have perform this ldif:
>>
>> dn: cn=schema
>> changetype: modify
>> add: attributeTypes
>> attributeTypes: ( 2.16.840.1.113730.3.1.3023 NAME
>> 'nsViewFilter' DESC 'Netscape defined attribute type'
SYNTAX
>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Directory
>> Server' )
>> -
>>
>> How can I recover the initial configuration of the
>> attributeType???? I have in my schema files 2 lines for
>> nsViewFilter after apply the indicated ldif, one with the
>> old OID and in other file one with the new OID. I would like
>> to know how to delete the newer in case of problems with
>> this OID change.
> It's normal. Please run the next command line and check
> nsViewFilter. You should see just one that you added above.
> ldapsearch [...] -b "cn=schema" attributeTypes | grep
> nsViewFilter
>
> AttributeTypes nsViewFilter is originally defined in
> 02common.ldif which is overridden by your new definition
> which is stored in the user defined schema file 99user.ldif.
>
>>
>> ----
>>
>> In the another hand: in my DS the attribute mail is
>> case-sensitive. If I perform the same search as you I get
>> nothing for one of my mail attributes whit upper characters.
>> Maybe 389DS in 1.2.5 is case-sensitive???
> It cannot be... Could you give us a snippet of your access
> log (/var/log/dirsrv/slapd-ID/access), which includes the
> SRCH options and the result?
>
> [27/Apr/2012:10:05:14 -0700] conn=7 op=1 SRCH
> base="dc=example,dc=com" scope=2
> filter="(mail=NewUser100(a)Example.Com)"
> <mailto:%28mail=NewUser100@Example.Com%29> attrs="mail"
> [27/Apr/2012:10:05:14 -0700] conn=7 op=1 RESULT err=0 tag=101
> *nentries=1* etime=0
>
> [27/Apr/2012:10:05:36 -0700] conn=8 op=1 SRCH
> base="dc=example,dc=com" scope=2
> filter="(mail=newuser100(a)example.COM)"
> <mailto:%28mail=newuser100@example.COM%29> attrs="mail"
> [27/Apr/2012:10:05:36 -0700] conn=8 op=1 RESULT err=0 tag=101
> *nentries=1* etime=0
>
> Also, if you think the version 1.2.5 is not working well,
> could you upgrade 389-ds-base to the latest and try the same
> operation?
>
>
> 389 Directory Server 1.2.10.4 is now available (March
> 29, 2012)
>
> 389 Directory Server 1.2.10.4 is now available from the
> Stable repositories.
>
> * See the Release Notes
> <
http://directory.fedoraproject.org/wiki/Release_Notes>
> for more information
>
>
> Thanks,
> --noriko
>
>
>> How can I solve this???
>>
>> Regards,
>> Moses.
>>
>>
>> El 26 de abril de 2012 20:41, Noriko Hosoi
>> <nhosoi(a)redhat.com <mailto:nhosoi@redhat.com>> escribió:
>>
>> Moisés Barba Pérez wrote:
>>> Hi,
>>>
>>> I have several questions about syntax and attributes,
>>> hope you can help me.
>>>
>>> - Why the attribute mail in DS is case sensitive?? Is
>>> there any problem changing it to non case sensitive? If
>>> there is no problem, how can I modify it?
>> The syntax of mail is IA5 String.
>>
>> If you have
>>
>> mail: TUser0(a)Example.Com <mailto:TUser0@Example.Com>
>>
>> then this command line returns the expected result.
>> That is, not case sensitive.
>>
>> ldapsearch [...] -b 'dc=example,dc=com'
>> "(mail=tuser0(a)example.com)"
>> <mailto:%28mail=tuser0@example.com%29> mail
>> mail: TUser0(a)Example.Com <mailto:TUser0@Example.Com>
>>
>>>
>>> - I have a problem whit the syntax of the nsViewFilter
>>> attribute, the value of the attribute is: (ou=*ou=D.
>>> PERIÓDICO,o=xxxxx,dc=xxxx,dc=xxxx). I guess the problem
>>> is the character "Ó" but if it is possible to create
>>> the ou with special characters, should be possible
>>> create a nsViewFilter with special characters to???
>>> (389DS 1.2.5)
>> Currently, the syntax of nsViewFilter is IA5 String,
>> which does not allow non-ascii characters.
>> attributeTypes: ( 2.16.840.1.113730.3.1.3023 NAME
>> 'nsViewFilter' DESC 'Netscape defined attribute
type'
>> SYNTAX *1.3.6.1.4.1.1466.115.121.1.26* X-ORIGIN
>> 'Netscape Directory Server' )
>>
>> Indeed, it'd be a needless restriction for
>> nsViewFilter. Please open a ticket at
>>
https://fedorahosted.org/389/newticket.
>>
>> In the meantime, could you replace
>> *1.3.6.1.4.1.1466.115.121.1.26* with
>> 1.3.6.1.4.1.1466.115.121.1.15, and try?
>>
>>
>>>
>>> - I have read about the attribute
>>> nsslapd-allidsthreshold and its use in older versions.
>>> I have 389DS 1.2.5, have I to use it or it is
>>> deprecated??? I have search this parameters in my ldap
>>> servers and someones have it, and others don't, maybe
>>> this behaviour is because of actualizations of the DS
>>> but I would like to know if in 1.2.5 is needed or if i
>>> can delete it.
>> nsslapd-allidsthreshold is replaced with
>> nsslapd-idlistscanlimit in 389-ds-base. Not like
>> nsslapd-allidsthreshold, nsslapd-idlistscanlimit is used
>> just by the search operation and you can dynamically
>> change the value. If the IDlist length is larger than
>> the nsslapd-idlistscanlimit value, DS gives up
>> generating the IDlist and uses ALLID, which scans all
>> the entries in the primary database.
>>>
>>> Thank you in advance.
>>>
>>> Moses.
>>>
>>>
>>> --
>>> 389 users mailing list
>>> 389-users(a)lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>>
>> --
>> 389 users mailing list
>> 389-users(a)lists.fedoraproject.org
>> <mailto:389-users@lists.fedoraproject.org>
>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>>
>>
>>
>> --
>> 389 users mailing list
>> 389-users(a)lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
>
https://admin.fedoraproject.org/mailman/listinfo/389-users