Problem browsing LDAP with Outlook
by Chris Bryant
When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS.
When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well.
I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also.
Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration.
Thanks,
Chris
USA.NET
You Run Your Business. We'll Run Your Email.
This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.
3 years, 8 months
389 Master - Master Replication
by Santos Ramirez
Good Morning,
We have a master - master replication agreement. When we initialize the replication it works perfectly we can see changes to a test user we have set up go up and down from the two servers. However at some point the replication stops and we cannot get replication to start once again. The only way we can get replication to start once again is to recreate the replication agreement and then it fails again. Can anyone please point us in a direction. I am relatively new to 389 so any help would be greatly appreciated.
Santos U. Ramirez
Linux Systems Administrator
National DCP, LLC
150 Depot Street
Bellingham, Ma. 02019
Phone: 508-422-3089
Fax: 508-422-3866
Santos.Ramirez(a)natdcp.com<mailto:Santos.Ramirez@natdcp.com>
This email and any attachments are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, do not copy or forward to any unauthorized persons, permanently delete the original and notify the sender by replying to this email.
9 years, 6 months
errors log - NSACLPlugin - acllas__client_match_URL:
by Picture Book
After using dynamic group in ACL, I see the following messages in errors log
1
ldapsearch -h localhost -p 389 -D "uid=ttest,ou=people,ou=Test,dc=example,dc=com" -w sp -b "ou=people,ou=Test,dc=example,dc=com"
[31/Jan/2013:10:53:36 -0500] NSACLPlugin - acllas__client_match_URL: url [ldap:///ou=special,ou=test,dc=example,dc=com??one?(&(objectclass=inetorgperson)(cn=*))] scope is onelevel but dn [ou=special,ou=test,dc=example,dc=com] is not a direct child of [ou=people,ou=test,dc=example,dc=com]
2.
ldapsearch -h localhost -p 389 -D "uid=test11,ou=Test,dc=example,dc=com" -w sp -b "ou=people,ou=Test,dc=example,dc=com"
[31/Jan/2013:10:58:12 -0500] NSACLPlugin - acllas__client_match_URL: url [ldap:///ou=special,ou=test,dc=example,dc=com??one?(&(objectclass=inetorgperson)(cn=*))] scope is onelevel but dn [ou=special,ou=test,dc=example,dc=com] is not a direct child of [ou=test,dc=example,dc=com]
repeat search 1 & 2, acllas__client_match_URL error message doen't repeat.
3.
ldapsearch -h localhost -p 389 -D "uid=aclp,ou=special,ou=Test,dc=example,dc=com" -w sp -b "ou=people,ou=Test,dc=example,dc=com"
no message in errors log
This is the dynamic group:
dn: cn=all special users,ou=special,ou=Test,dc=example,dc=com
objectClass: groupofurls
objectClass: groupofuniquenames
objectClass: top
cn: all special users
memberURL: ldap:///ou=special,ou=test,dc=example,dc=com??one?(&(objectclass=
inetorgperson)(cn=*))
This is the ACL
dn: ou=people,ou=Test,dc=example,dc=com
objectClass: organizationalunit
objectClass: top
ou: people
aci: (targetattr = "*") (version 3.0;acl "special users";allow (all)(groupdn
= "ldap:///cn=all special users,ou=special,ou=Test,dc=example,dc=com");)
createTimestamp: 20130131152507Z
The following is the ldif export of the test setup
version: 1
dn: ou=Test,dc=example,dc=com
objectClass: organizationalunit
objectClass: top
ou: Test
createTimestamp: 20130123175104Z
creatorsName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRo
ot
entrydn: ou=test,dc=example,dc=com
entryid: 10
hasSubordinates: TRUE
modifiersName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeR
oot
modifyTimestamp: 20130123175104Z
nsUniqueId: 6428fe79-658511e2-9283c9b9-f4c01566
numSubordinates: 5
parentid: 1
subschemaSubentry: cn=schema
dn: cn=mygroup,ou=Test,dc=example,dc=com
objectClass: groupofuniquenames
objectClass: top
cn: mygroup
uniqueMember: uid=test11,ou=test,dc=example,dc=com
createTimestamp: 20130123175116Z
creatorsName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRo
ot
entrydn: cn=mygroup,ou=test,dc=example,dc=com
entryid: 11
hasSubordinates: FALSE
modifiersName: cn=referential integrity postoperation,cn=plugins,cn=config
modifyTimestamp: 20130123182725Z
nsUniqueId: 6428fe7a-658511e2-9283c9b9-f4c01566
numSubordinates: 0
parentid: 10
subschemaSubentry: cn=schema
dn: uid=test11,ou=Test,dc=example,dc=com
objectClass: inetorgperson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: test 1
sn: 1
givenName: test
uid: test11
userPassword:: e1NTSEF9QUNkS1NiOFVkOFJQSy9TeklGN2pCN2trblQvYWpkZjBwZy84c0E9P
Q==
createTimestamp: 20130123175131Z
creatorsName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRo
ot
entrydn: uid=test11,ou=test,dc=example,dc=com
entryid: 12
hasSubordinates: FALSE
modifiersName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeR
oot
modifyTimestamp: 20130131155727Z
nsUniqueId: 6428fe7b-658511e2-9283c9b9-f4c01566
numSubordinates: 0
parentid: 10
passwordGraceUserTime: 0
subschemaSubentry: cn=schema
dn: ou=people,ou=Test,dc=example,dc=com
objectClass: organizationalunit
objectClass: top
ou: people
aci: (targetattr = "*") (version 3.0;acl "special users";allow (all)(groupdn
= "ldap:///cn=all special users,ou=special,ou=Test,dc=example,dc=com");)
createTimestamp: 20130131152507Z
creatorsName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRo
ot
entrydn: ou=people,ou=test,dc=example,dc=com
entryid: 13
hasSubordinates: TRUE
modifiersName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeR
oot
modifyTimestamp: 20130131155032Z
nsUniqueId: 55ac9901-6bba11e2-9283c9b9-f4c01566
numSubordinates: 1
parentid: 10
subschemaSubentry: cn=schema
dn: ou=groups,ou=Test,dc=example,dc=com
objectClass: organizationalunit
objectClass: top
ou: groups
createTimestamp: 20130131152521Z
creatorsName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRo
ot
entrydn: ou=groups,ou=test,dc=example,dc=com
entryid: 14
hasSubordinates: FALSE
modifiersName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeR
oot
modifyTimestamp: 20130131152521Z
nsUniqueId: 55ac9902-6bba11e2-9283c9b9-f4c01566
numSubordinates: 0
parentid: 10
subschemaSubentry: cn=schema
dn: ou=special,ou=Test,dc=example,dc=com
objectClass: organizationalunit
objectClass: top
ou: special
createTimestamp: 20130131152543Z
creatorsName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRo
ot
entrydn: ou=special,ou=test,dc=example,dc=com
entryid: 15
hasSubordinates: TRUE
modifiersName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeR
oot
modifyTimestamp: 20130131152543Z
nsUniqueId: 796fdf01-6bba11e2-9283c9b9-f4c01566
numSubordinates: 2
parentid: 10
subschemaSubentry: cn=schema
dn: uid=aclp,ou=special,ou=Test,dc=example,dc=com
objectClass: inetorgperson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: acl problem
sn: problem
givenName: acl
uid: aclp
userPassword:: e1NTSEF9dE1MR0F6bzhjcDJMb2JTN2FoMkZTcnE1RS9PTXg2S0FEUEtjMnc9P
Q==
createTimestamp: 20130131152618Z
creatorsName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRo
ot
entrydn: uid=aclp,ou=special,ou=test,dc=example,dc=com
entryid: 16
hasSubordinates: FALSE
modifiersName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeR
oot
modifyTimestamp: 20130131152854Z
nsUniqueId: 796fdf02-6bba11e2-9283c9b9-f4c01566
numSubordinates: 0
parentid: 15
passwordGraceUserTime: 0
subschemaSubentry: cn=schema
dn: cn=all special users,ou=special,ou=Test,dc=example,dc=com
objectClass: groupofurls
objectClass: groupofuniquenames
objectClass: top
cn: all special users
memberURL: ldap:///ou=special,ou=test,dc=example,dc=com??one?(&(objectclass=
inetorgperson)(cn=*))
createTimestamp: 20130131152806Z
creatorsName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRo
ot
entrydn: cn=all special users,ou=special,ou=test,dc=example,dc=com
entryid: 17
hasSubordinates: FALSE
modifiersName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeR
oot
modifyTimestamp: 20130131155311Z
nsUniqueId: c0f66b01-6bba11e2-9283c9b9-f4c01566
numSubordinates: 0
parentid: 15
subschemaSubentry: cn=schema
dn: uid=ttest,ou=people,ou=Test,dc=example,dc=com
objectClass: inetorgperson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: test test
sn: test
givenName: test
uid: ttest
userPassword:: e1NTSEF9VktyMVRzbHgxbVRJbGJJQlRnTXlRamVmREpHVE1nQk8yNnNucVE9P
Q==
createTimestamp: 20130131152911Z
creatorsName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRo
ot
entrydn: uid=ttest,ou=people,ou=test,dc=example,dc=com
entryid: 18
hasSubordinates: FALSE
modifiersName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeR
oot
modifyTimestamp: 20130131154252Z
nsUniqueId: e4b9b101-6bba11e2-9283c9b9-f4c01566
numSubordinates: 0
parentid: 13
passwordGraceUserTime: 0
subschemaSubentry: cn=schema
11 years, 2 months
Re: [389-users] Rolling upgrade of multiple servers
by Rich Megginson
On 01/31/2013 09:14 AM, Bright, Daniel wrote:
>
> When you say schema replication is tricky because it is a “single”
> master, I am using an MMR environment where in effect every member is
> a master. Is this a setting that is controlled elsewhere, and does
> this mean that any custom changes to the schema need to be made on
> this single master server?
>
>
> Yes. That's the best way to do it. If you make schema changes to one
> master, then make sure that all of those schema changes have been
> replicated to all servers throughout your topology, then you can make
> schema changes to another master. Schema replication is not
> multi-master in the sense that you can make simultaneous changes to to
> the schema on more than one master. You just have to be careful.
> That's why using a single master is easier - if you always make
> changes on that one master, it should work.
>
> OK thanks, that is the way I am planning on doing this. Just for
> clarification, the master schema server in an MMR environment is
> whatever one I make changes to, it is however prudent to make schema
> changes only to one server as normal replication rules do not apply to
> schema and conflicts could arise if changes are made to more than one
> master.
>
Right.
> *Custom Schema*
>
> If the standard 99user.ldiffile is used for custom schema, these
> changes are replicated to all consumers.
>
> Custom schema files must be copied to each server in order to maintain
> the information in the same schema file on all servers. Custom schema
> files, and changes to those files, are not replicated, even if they
> are made through the Directory Server Console or ldapmodify.
>
> If there are custom schema files, ensure that these files are copied
> to all servers after making changes on the supplier. After all of the
> files have been copied, restart the server.
>
> For more information on custom schema files, see Section 3.4.7,
> “Creating Custom Schema Files”
> <https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9...>.
>
>
>
> That's a little bit misleading. In order for schema changes to be
> replicated, they _must_ be changed using ldapmodify (which is what the
> console uses). Schema changes made over ldap are stored in
> 99user.ldif. However, if you manually edit 99user.ldif, schema
> changes will _not_ be replicated.
>
> That is of course unless you restart the directory services on this
> server, in the past when I’ve made changes to 99user.ldif they go into
> effect when I restart the service, is this not true anymore? I haven’t
> done this for a few years so perhaps I am remembering incorrectly.
>
When you make changes to 99user.ldif by editing the file, and then
restart the server (or use the schema-reload.pl script), yes, the schema
changes do go into effect immediately, but they are not replicated.
> CONFIDENTIALITY NOTICE
> This e-mail and any attachments contain information which may be
> confidential or privileged and exempt from disclosure under applicable
> law. If you are not the intended recipient, be aware that any
> disclosure, copying, distribution, or use of the contents of this
> information is without authorization and is prohibited. If you have
> received this email in error, please immediately notify us by
> returning it to the sender and delete this copy from your computer
> system. Thank you.
> ------------------------------------------------------------------------
11 years, 2 months
notes=U, unindex search? really
by Picture Book
filter="(&(AllowAccess=Y)(uid=bill))"
AllowAccess is unindexed attribute
uid is indexed attribute
access log search result: notes=U
I imagine that directory server will do an indexed search by uid=bill, get the entry and then verify if AllowAccess=Y. To me this kind of search is indexed search.
example:
[18/Jan/2013:10:17:24 -0500] conn=124757 op=1 SRCH base="ou=people,dc=?" scope=1 filter="(&(AllowAccess=Y)(uid=bill))" attrs=ALL
[18/Jan/2013:10:17:24 -0500] conn=124757 op=1 RESULT err=0 tag=101 nentries=1 etime=0 notes=U
etime=0 confirms that this search is fast.
11 years, 2 months
Re: [389-users] Rolling upgrade of multiple servers
by Rich Megginson
On 01/31/2013 08:19 AM, Bright, Daniel wrote:
>
> |schema changes made over LDAP? Yes, schema replication is tricky
> because it is "single" master.
>
> When you say schema replication is tricky because it is a “single”
> master, I am using an MMR environment where in effect every member is
> a master. Is this a setting that is controlled elsewhere, and does
> this mean that any custom changes to the schema need to be made on
> this single master server?
>
Yes. That's the best way to do it. If you make schema changes to one
master, then make sure that all of those schema changes have been
replicated to all servers throughout your topology, then you can make
schema changes to another master. Schema replication is not
multi-master in the sense that you can make simultaneous changes to to
the schema on more than one master. You just have to be careful.
That's why using a single master is easier - if you always make changes
on that one master, it should work.
>
> |User defined attributes are attributes that have been added via LDAP
> (or the console which uses LDAP).
>
> I think I just answered my own question regarding this issue,
> according to the official documentation I will need to make custom
> schema changes to the 99user.ldif file rather than using ldapmodify or
> the 389-console:
>
> *Custom Schema*
>
> If the standard 99user.ldiffile is used for custom schema, these
> changes are replicated to all consumers.
>
> Custom schema files must be copied to each server in order to maintain
> the information in the same schema file on all servers. Custom schema
> files, and changes to those files, are not replicated, even if they
> are made through the Directory Server Console or ldapmodify.
>
> If there are custom schema files, ensure that these files are copied
> to all servers after making changes on the supplier. After all of the
> files have been copied, restart the server.
>
> For more information on custom schema files, see Section 3.4.7,
> “Creating Custom Schema Files”
> <https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9...>.
>
>
That's a little bit misleading. In order for schema changes to be
replicated, they _must_ be changed using ldapmodify (which is what the
console uses). Schema changes made over ldap are stored in
99user.ldif. However, if you manually edit 99user.ldif, schema changes
will _not_ be replicated.
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9...
> CONFIDENTIALITY NOTICE
> This e-mail and any attachments contain information which may be
> confidential or privileged and exempt from disclosure under applicable
> law. If you are not the intended recipient, be aware that any
> disclosure, copying, distribution, or use of the contents of this
> information is without authorization and is prohibited. If you have
> received this email in error, please immediately notify us by
> returning it to the sender and delete this copy from your computer
> system. Thank you.
> ------------------------------------------------------------------------
11 years, 2 months
ACL Question
by rayane karim
Hi
need to setup an acl restriction based on targetfilter like
(targetattr = "*") (targetfilter= "(!(Affectation=testaff))") (version
3.0;acl "Student restriction Acl";allow (write)(groupdn =
"ldap:///cn=Students Manager,ou=Groups,dc=example,dc=com");)
this rule hide all the student branch
ou=Students,ou=People,dc=lagh-univ,dc=dz
on witch it is applied
need to hide only certain people form student banch for cn=Students Manage
pepole that havn't (Affectation=testaff) attribute
thank's
11 years, 2 months
Rolling upgrade of multiple servers
by Bright, Daniel
Hello,
I am performing a rolling upgrade of my 389-ds servers in my environment. Currently they are running version 1.2.5 of directory server, and 1.1.10 of administration server on 32-bit hardware. Currently I have 6 servers using MMR replication and I am planning on replacing the servers one at a time, upgrading from OEL5 32-bit to OEL6 64-bit and to version 1. 2.10.2 of directory server. Until the upgrades are completed, there will be a period of time where I have mixed servers, some 32-bit 1.2.5 and some 64-bit 1.2.10.2. I have done this in a test environment with 4 vm's, and was able to detach a server from the MMR group, and then re-attach and initialize the new server successfully, with replication of the userRoot working seemingly fine. However, there are two issues I have noticed:
1 - any schema changes made on either the new servers or the old ones will not replicate over.
2 - When I view the attributes tab on 389-console on the new 64-bit server, all attributes appear under "Standard Attributes", however when I view the attributes tab on the 32-bit servers, about half of these are under the "User Defined Attributes" section. I have an idea of why this is but I want to hear someone else's opinion on it first.
Also, if anyone has done this before and would like to share any issues they ran into I would be grateful. I'm wondering if the schema replication issue will go away once all servers are using 1.2.10.2.
Thanks in advance.
------------------------
CONFIDENTIALITY NOTICE
This e-mail and any attachments contain information which may be confidential or privileged and exempt from disclosure under applicable law. If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this information is without authorization and is prohibited. If you have received this email in error, please immediately notify us by returning it to the sender and delete this copy from your computer system. Thank you.
------------------------
11 years, 2 months
Filtered replication from AD?
by Colin Panisset
We have two separate directory environments at present, one 389-ds
(389-ds-base-1.2.10.2-20.el6_3.x86_64) and one AD based on W2k8.
We would like to be able to replicate user entries, password changes,
and employee terminations from AD to 389-ds but, because the 389-ds
environment is a restricted subset, we don't want all new users in the
AD domain to automatically appear in 389-ds.
I've seen https://fedorahosted.org/389/ticket/460 which looks like it
would do the job, but the milestone is 1.3.2 which is a ways off.
The suffixes in use by the different directory servers are different --
one is dc=example,dc=com and the other is dc=otherplace,dc=com
Complicating the matter is that the two directories are managed by
different OUs in the same company.
Other than referrals, is there some way to copy/replicate attributes
from one suffix to another, or to change the suffix during a replication?
Fractional replication uses the filter '(objectclass=*)' prior to the $
EXCLUDE but would it be possible to extend that to cover a smaller
subset of entries? We're not interested in replicating from 389-ds back
to AD at this point.
--
Colin Panisset
Senior Systems Engineer, REA Group
Ph: +61 (0)3 8456 4636 Mb: +61 (0) 457 788 259
11 years, 2 months
Re: [389-users] setup-ds-admin.pl failure
by Carsten Grzemba
Am 29.01.13 schrieb Rich Megginson <rmeggins(a)redhat.com>:
>
>
>
>
> On 01/29/2013 09:39 AM, Carsten Grzemba wrote:
>
> > The problem is that the scripts use a env variable USER which is commonly not set in Solaris (there is LOGNAME common). It try to work arround this by setting this in:
> >
> > /etc/opt/csw/default/dirsrv
> >
> >
> > So I guess if USER not set will the perl function (DSutil.pm)
> >
> > sub getLogin {
> > return (getpwuid($>))[0] || $ENV{USER} || confess "Error: could not determine the current user ID: $!";
> > }
> >
>
> Looks like we have two bugs here:
> 1) getpwuid does not return the expected value
> 2) should look for $ENV{LOGNAME} on Solaris in addition to USER
>
> Do we have tickets for these issues?
>
>
>
>
So far I know: No.
At least the error message should be fixed.
For the LOGNAME vs. USER environment problem I do not know a simple solution:
Should we really evaluate both?
Carsten
>
>
>
>
>
>
> >
> > not work and than the function (DSCreate.pm)
> >
> > sub get_initconfigdir {
> > # determine initconfig_dir
> > if (getLogin eq 'root') {
> > return "/etc/opt/csw/default";
> > } else {
> > return "$ENV{HOME}/.dirsrv";
> > }
> > }
> > also not return the correct value. I will fix this tomorrow.
> >
> > ~Carsten
> >
> > Am 29.01.13 schrieb Jovan.VUKOTIC(a)sungard.com:
> > <!--
> > /* Font Definitions */
> > @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;}
> > @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;}
> > /* Style Definitions */
> > p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";}
> > a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;}
> > a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;}
> > p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman","serif";}
> > span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;}
> > .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";}
> > @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;}
> > div.WordSection1 {page:WordSection1;}
> > -->
> >
> >
> >
> >
> > I have attempted to install1.2.10.7 version of the server:
> >
> > % pkgutil -c CSW389-ds-base
> >
> > package installed catalog
> >
> > CSW389-ds-base 1.2.10.7,REV=2012.05.02 SAME
> >
> >
> >
> > On Solaris, configuration directory for opencsw packages are at
> >
> > /etc/opt/csw
> >
> > In particular, for DS, all instances are at
> >
> > /etc/opt/csw/dirsrv/
> >
> >
> >
> > The strange thing is that for the given instance, the setup script did create
> >
> > /etc/opt/csw/dirsrv/slapd-instance-name
> >
> > directory even after the failure I described,
> >
> > as well as all the directories under
> >
> > /var/opt/csw/lib
> >
> > /var/opt/csw/lock
> >
> > /var/opt/csw/log
> >
> >
> >
> > I really do not know why it is looking in root’s home for dirsrv-instance-name
> >
> >
> >
> > Thanks,
> > Jovan
> >
> >
> >
> >
> >
> > From: 389-users-bounces(a)lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org <389-users-bounces(a)lists.fedoraproject.org>] On Behalf Of Carsten Grzemba
> > Sent: Tuesday, January 29, 2013 5:06 PM
> > To: General discussion list for the 389 Directory server project.
> > Subject: Re: [389-users] setup-ds-admin.pl failure
> >
> >
> >
> > Hi,
> >
> > I see you use my packages from www.opencsw.org(http://www.opencsw.org). Which package version you have installed?
> > Please sent the output of:
> > # pkgutil -c CSW389-ds-base
> >
> > ~Carsten
> >
> > Am 29.01.13 schrieb Jovan.VUKOTIC(a)sungard.com:
> >
> >
> >
> > Hi,
> >
> >
> >
> > It is not the first instance of 389DS I have attempted to install on Solaris, but the first one that failed and the reason is
> >
> >
> >
> > Could not open the script template file '//.dirsrv/dirsrv-instance_name
> >
> >
> >
> > I was running the script as root, but have never read or heard of any template file required. The only template files I have seen so far were at
> >
> > /opt/csw/share/dirsrv/script-templates.
> >
> >
> >
> > I have also turned on debugging with (–dd ) to try to pick up more information, but have not found anything that could help me out (krian-inst is an instance_name of 389DS instance):
> >
> >
> >
> > Entry cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config is added
> >
> > +Entry cn=uid mapping,cn=mapping,cn=sasl,cn=config is added
> >
> > +Processing /opt/csw/share/dirsrv/data/template-pampta.ldif ...
> >
> > +Entry cn=PAM Pass Through Auth,cn=plugins,cn=config is added
> >
> > +Processing /opt/csw/share/dirsrv/data/template-bitwise.ldif ...
> >
> > +Entry cn=Bitwise Plugin,cn=plugins,cn=config is added
> >
> > +Processing /opt/csw/share/dirsrv/data/template-dnaplugin.ldif ...
> >
> > +Entry cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config is added
> >
> > +Processing /opt/csw/share/dirsrv/updates/50replication-plugins.ldif ...
> >
> > +Entry cn=Legacy Replication Plugin,cn=plugins,cn=config is added
> >
> > +Entry cn=Multimaster Replication Plugin,cn=plugins,cn=config is added
> >
> > +changeOwnerMode: changed mode of /etc/opt/csw/dirsrv/slapd-krian-inst/dse.ldif to 660
> >
> > +changeOwnerMode: changed ownership of /etc/opt/csw/dirsrv/slapd-krian-inst/dse.ldif to user 60001 group 60001
> >
> > +changeOwnerMode: changed mode of /etc/opt/csw/dirsrv/slapd-krian-inst/dse_original.ldif to 440
> >
> > +changeOwnerMode: changed ownership of /etc/opt/csw/dirsrv/slapd-krian-inst/dse_original.ldif to user 60001 group 60001
> >
> > +changeOwnerMode: changed mode of /etc/opt/csw/dirsrv/slapd-krian-inst/certmap.conf to 440
> >
> > +changeOwnerMode: changed ownership of /etc/opt/csw/dirsrv/slapd-krian-inst/certmap.conf to user 60001 group 60001
> >
> > +changeOwnerMode: changed mode of /etc/opt/csw/dirsrv/slapd-krian-inst/slapd-collations.conf to 440
> >
> > +changeOwnerMode: changed ownership of /etc/opt/csw/dirsrv/slapd-krian-inst/slapd-collations.conf to user 60001 group 60001
> >
> > Could not open the script template file '//.dirsrv/dirsrv-krian-inst'. Error: No such file or directory
> >
> > Error: Could not create directory server instance 'krian-inst'.
> >
> > Exiting . . .
> >
> > Log file is '/tmp/setupdlCUbY.log
> >
> >
> >
> > Jovan Vukotić • Senior Software Engineer • Ambit Treasury Management • SunGard • Banking • Bulevar Milutina Milankovića 136b, Belgrade, Serbia • tel: +381.11.6555-66-1 • jovan.vukotic(a)sungard.com
> >
> >
> >
> >
> >
> > Join the online conversation with SunGard’s customers, partners and Industry experts and find an event near you at: www.sungard.com/ten.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
11 years, 2 months
