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=newuser...@example.com)" 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=newuser...@example.com)" 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 <nho...@redhat.com
<mailto:nho...@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: tus...@example.com <mailto:tus...@example.com>
then this command line returns the expected result. That is, not
case sensitive.
ldapsearch [...] -b 'dc=example,dc=com'
"(mail=tus...@example.com)"
<mailto:%28mail=tus...@example.com%29> mail
mail: tus...@example.com <mailto:tus...@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-us...@lists.fedoraproject.org
<mailto:389-us...@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-us...@lists.fedoraproject.org
<mailto:389-us...@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
