Hi,
I have replaced the OID and now there is no syntax error. The ticket is
.
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.
----
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??? How can I
solve this???
Regards,
Moses.
El 26 de abril de 2012 20:41, Noriko Hosoi <nhosoi(a)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
then this command line returns the expected result. That is, not case
sensitive.
ldapsearch [...] -b 'dc=example,dc=com'
"(mail=tuser0@example.com)"<%28mail=tuser0(a)example.com%29>mail
mail: TUser0(a)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
list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users