389-users January 2013

389-users@lists.fedoraproject.org

38 participants
50 discussions

Problem browsing LDAP with Outlook
by Chris Bryant 26 Aug '20

26 Aug '20

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 2

389 Master - Master Replication
by Santos Ramirez 03 Oct '14

03 Oct '14

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.

3 9

errors log - NSACLPlugin - acllas__client_match_URL:
by Picture Book 11 Feb '13

11 Feb '13

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

2 3

Re: [389-users] Rolling upgrade of multiple servers
by Rich Megginson 31 Jan '13

31 Jan '13

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.0…>. > > > > 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. > ------------------------------------------------------------------------

2 2

notes=U, unindex search? really
by Picture Book 31 Jan '13

31 Jan '13

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.

3 5

Re: [389-users] Rolling upgrade of multiple servers
by Rich Megginson 31 Jan '13

31 Jan '13

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.0…>. > > 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.0… > 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. > ------------------------------------------------------------------------

1 0

ACL Question
by rayane karim 31 Jan '13

31 Jan '13

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

2 1

Rolling upgrade of multiple servers
by Bright, Daniel 31 Jan '13

31 Jan '13

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. ------------------------

2 1

Filtered replication from AD?
by Colin Panisset 30 Jan '13

30 Jan '13

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

1 2

Re: [389-users] setup-ds-admin.pl failure
by Carsten Grzemba 30 Jan '13

30 Jan '13

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: > >  > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users January 2013