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?
Regards,
Moses
2012/4/27 Noriko Hosoi <[email protected] <mailto:[email protected]>>
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="([email protected])"
<mailto:%[email protected]%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="([email protected])"
<mailto:%[email protected]%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
<[email protected] <mailto:[email protected]>> 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: [email protected] <mailto:[email protected]>
then this command line returns the expected result.
That is, not case sensitive.
ldapsearch [...] -b 'dc=example,dc=com'
"([email protected])"
<mailto:%[email protected]%29> mail
mail: [email protected] <mailto:[email protected]>
- 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
[email protected]
<mailto:[email protected]>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
[email protected]
<mailto:[email protected]>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
[email protected]
<mailto:[email protected]>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
[email protected]
<mailto:[email protected]>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
[email protected]
<mailto:[email protected]>
https://admin.fedoraproject.org/mailman/listinfo/389-users
