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., u...@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 <nho...@redhat.com <mailto:nho...@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=newuser...@example.com)"
<mailto:%28mail=newuser...@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=newuser...@example.com)"
<mailto:%28mail=newuser...@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 <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
<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
