Re: [389-users] setup-ds-admin.pl failure
by Carsten Grzemba
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: $!";
}
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]
> 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. 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.
>
>
>
>
>
>
>
>
>
>
>
>
>
--
Carsten Grzemba
Tel.: +49 3677 64740
Mobil: +49 171 9749479
Fax: +49 3677 6474111
Email: carsten.grzemba(a)contac-dt.de
contac Datentechnik GmbH
11 years, 2 months
Re: [389-users] setup-ds-admin.pl failure
by Carsten Grzemba
Hi,
I see you use my packages from 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:
>
>
>
> <!--
> /* 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:11.0pt; font-family:"Calibri","sans-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.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";}
> span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;}
> span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";}
> .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;}
> -->
>
>
>
>
> 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
setup-ds-admin.pl failure
by Jovan.VUKOTIC＠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<mailto:jovan.vukotic@sungard.com>
[Description: Description: Description: Description: Description: coc-signature-03-2012]<http://www.capitalize-on-change.com/?email=70150000000Y1Et>
Join the online conversation with SunGard's customers, partners and Industry experts and find an event near you at: www.sungard.com/ten<http://www.capitalize-on-change.com/?email=70150000000Y1Et>.
11 years, 2 months
AD and 389ds synchronization of shadowLastChange
by vladimir Safoo
Greetings all,
I need help from the experts, so I thank you ahead of time for any help
that you are able to assist me with.
Problem - Password set to expire in 90 days. Linux users password
expiration is not sync'ing with Windows users password expiration. So I am
getting people that are getting locked out of the environment do to their
passwords expiring.
I have AD 2008 r2 bidirectionally sync'ing with one 389ds master server.
Everything so far has been working fine. I have set up a password policy on
the AD server and have mirrored the same policy on the 389ds servers.
Passwords are set to expire in 90 days. I have multimaster replication set
up on 8 servers and have other read-only consumers.
Resetting a password on a Windows desktop or linux server does not modify
the shadowLastChange value on the Linux 389ds servers. It does, however,
update the passwordexpirationtime on the linux 389ds servers. But the linux
servers don't know what the passwordexpirationtime is so they seem to
ignore it. Though the passwordexpirationtime value is correct and does
reflect the password to expire in 90 days from the initial password setup
or change.
Now since users accounts are created normally before a users starts their
new job, the passwords get out of sync do to linux users resetting their
initial password on the linux servers once they login for the first time.
Our internal chat server authenticates via the AD server, so they are not
always notified when their Windows password has expired on the AD side.
How can I get AD to update the Linux side value for the shadowLastChange
attribute?
I can pull the passwordexpirationtime value, if there is no "normal"
solution for this, I could write a perl script to check for this time and
update the shadowLastChange value I guess. But I need to know if I am just
setting this up wrong and what is the solution or if it is not possible.
Please let me know if more information is needed.
# cat /etc/issue
CentOS release 6.2 (Final)
# rpm -qa 389*
389-ds-console-1.2.6-1.el6.noarch
389-ds-1.2.2-1.el6.noarch
389-ds-base-1.2.9.14-1.el6_2.2.x86_64
389-admin-console-1.1.8-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-dsgw-1.1.9-1.el6.x86_64
389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64
389-adminutil-1.1.15-1.el6.x86_64
389-console-1.1.7-1.el6.noarch
389-admin-1.1.29-1.el6.x86_64
389-admin-console-doc-1.1.8-1.el6.noarch
# slaps uid=tuser
dn: uid=tuser,ou=testOU,ou=Groups,dc=company,dc=net
ntUserLastLogon: 130035596619212394
userPassword::
e1NTSEF9cTlTNmxTc01uRVFHMjU4WVhIUVhLQWRPNU5ndVZMUDZZV3ZYSGc9PQ=
=
shadowLastChange: 15729
mail: tuser(a)company.net
loginShell: /bin/bash
uidNumber: 20288
gidNumber: 61000
homeDirectory: /home/tuser
ntUserLastLogoff: 0
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetOrgPerson
objectClass: ntUser
objectClass: posixAccount
objectClass: shadowAccount
ntUserDeleteAccount: true
uid: tuser
sn: user
givenName: test
cn: test user
ntUserCodePage: 0
ntUserAcctExpires: 9223372036854775807
ntUserDomainId: tuser
ntUniqueId: d19af18ff098044db4afb2e59f0ea25b
# slaps uid=tuser passwordexpirationtime
dn: uid=tuser,ou=testOU,ou=Groups,dc=company,dc=net
passwordexpirationtime: 20130425035421Z
Thank you,
389ds admin
11 years, 2 months
AD and 389ds synchronization of password attributes
by vladimir Safoo
Greetings all,
I need help from the experts, so I thank you ahead of time for any help
that you are able to assist me with.
Problem - Password set to expire in 90 days. Linux users password
expiration is not sync'ing with Windows users password expiration. So I am
getting people that are getting locked out of the environment do to their
passwords expiring.
I have AD 2008 r2 bidirectionally sync'ing with one 389ds master server.
Everything so far has been working fine. I have set up a password policy on
the AD server and have mirrored the same policy on the 389ds servers.
Passwords are set to expire in 90 days. I have multimaster replication set
up on 8 servers and have other read-only consumers.
Resetting a password on a Windows desktop or linux server does not modify
the shadowLastChange value on the Linux 389ds servers. It does, however,
update the passwordexpirationtime on the linux 389ds servers. But the linux
servers don't know what the passwordexpirationtime is so they seem to
ignore it. Though the passwordexpirationtime value is correct and does
reflect the password to expire in 90 days from the initial password setup
or change.
Now since users accounts are created normally before a users starts their
new job, the passwords get out of sync do to linux users resetting their
initial password on the linux servers once they login for the first time.
Our internal chat server authenticates via the AD server, so they are not
always notified when their Windows password has expired on the AD side.
How can I get AD to update the Linux side value for the shadowLastChange
attribute?
I can pull the passwordexpirationtime value, if there is no "normal"
solution for this, I could write a perl script to check for this time and
update the shadowLastChange value I guess. But I need to know if I am just
setting this up wrong and what is the solution or if it is not possible.
Please let me know if more information is needed.
# cat /etc/issue
CentOS release 6.2 (Final)
# rpm -qa 389*
389-ds-console-1.2.6-1.el6.noarch
389-ds-1.2.2-1.el6.noarch
389-ds-base-1.2.9.14-1.el6_2.2.x86_64
389-admin-console-1.1.8-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-dsgw-1.1.9-1.el6.x86_64
389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64
389-adminutil-1.1.15-1.el6.x86_64
389-console-1.1.7-1.el6.noarch
389-admin-1.1.29-1.el6.x86_64
389-admin-console-doc-1.1.8-1.el6.noarch
# slaps uid=tuser
dn: uid=tuser,ou=testOU,ou=Groups,dc=company,dc=net
ntUserLastLogon: 130035596619212394
userPassword::
e1NTSEF9cTlTNmxTc01uRVFHMjU4WVhIUVhLQWRPNU5ndVZMUDZZV3ZYSGc9PQ=
=
shadowLastChange: 15729
mail: tuser(a)company.net
loginShell: /bin/bash
uidNumber: 20288
gidNumber: 61000
homeDirectory: /home/tuser
ntUserLastLogoff: 0
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetOrgPerson
objectClass: ntUser
objectClass: posixAccount
objectClass: shadowAccount
ntUserDeleteAccount: true
uid: tuser
sn: user
givenName: test
cn: test user
ntUserCodePage: 0
ntUserAcctExpires: 9223372036854775807
ntUserDomainId: tuser
ntUniqueId: d19af18ff098044db4afb2e59f0ea25b
# slaps uid=tuser passwordexpirationtime
dn: uid=tuser,ou=testOU,ou=Groups,dc=company,dc=net
passwordexpirationtime: 20130425035421Z
Thank you,
389ds admin
11 years, 2 months
Migrating from ApacheDS
by Andrew Carr
Hello,
I am working on migrating from ApacheDS 1.5.7 to the newest 389-ds offered
in the centos repos (I believe at this time it is 1.2.10.2-10.el6_3.)
Everytime I try to import there are errors. Most of the errors are "No
Such Object," while the majority of users are imported successfully. I am
hard pressed to find notes and suggestions on migrating from ApacheDS to
389, any help will be appreciated.
The server I am migrating to is running 389-base yum package on CentOS 6.3.
If you require information to assist me I will be happy to provide.
Thanks!
--
With Regards,
Andrew Carr
e. andrewlanecarr(a)gmail.com
w. andrew.carr(a)openlogic.com
h. 4235254941
c. 4235526193
a. 100 Heritage Hills Drive, Greeneville, TN, 37745
11 years, 2 months
attribute uniqneness plugin error: Another entry with the same attribute value already exists
by Picture Book
This is another bug exists in 1.2.10.12, but not exists in 1.2.11.14
enable cn=attribute uniqueness,cn=plugins,cn=config
with the default attribute: uid
copy and create cn=attribute test uniqueness,cn=plugins,cn=config
with another attribute, for example: sn, just for testing purpose.
After restart, try to change a user's rdn: uid, you will get the following error:
Another entry with the same attribute value already exists (attribute: "sn")
dn: cn=attribute test uniqueness,cn=plugins,cn=config
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
cn: attribute test uniqueness
nsslapd-pluginPath: libattr-unique-plugin
nsslapd-pluginInitfunc: NSUniqueAttr_Init
nsslapd-pluginType: preoperation
nsslapd-pluginEnabled: on
nsslapd-pluginarg0: sn
nsslapd-pluginarg1: dc=example,dc=com
nsslapd-plugin-depends-on-type: database
nsslapd-pluginId: NSUniqueAttr
nsslapd-pluginVersion: 1.2.10.12
nsslapd-pluginVendor: 389 Project
nsslapd-pluginDescription: Enforce unique attribute values
modifiersName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoo
t
modifyTimestamp: 20130123180354Z
dn: cn=attribute uniqueness,cn=plugins,cn=config
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
cn: attribute uniqueness
nsslapd-pluginPath: libattr-unique-plugin
nsslapd-pluginInitfunc: NSUniqueAttr_Init
nsslapd-pluginType: preoperation
nsslapd-pluginEnabled: on
nsslapd-pluginarg0: uid
nsslapd-pluginarg1: dc=example,dc=com
nsslapd-plugin-depends-on-type: database
nsslapd-pluginId: NSUniqueAttr
nsslapd-pluginVersion: 1.2.10.12
nsslapd-pluginVendor: 389 Project
nsslapd-pluginDescription: Enforce unique attribute values
modifiersName: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoo
t
modifyTimestamp: 20130123180354Z
11 years, 2 months
referential integrity postoperation plugin 1.10.12
by Picture Book
After enabling the refertial integrity postoperation plugin, I created a user and a group with the user as member. When I changed the user's rdn: uid. I got the following error, and the uniquememeber of the group didn't change.
Is this a known problem?
[23/Jan/2013:11:01:34 -0500] - 389-Directory/1.2.10.12 B2012.180.1623 starting up
[23/Jan/2013:11:01:34 -0500] - slapd started. Listening on All Interfaces port 6389 for LDAP requests
[23/Jan/2013:11:03:08 -0500] - slapi_modify_internal_set_pb: NULL parameter
[23/Jan/2013:11:03:08 -0500] - allow_operation: component identity is NULL
11 years, 2 months
389-console is pointing to the wrong instance
by Elizabeth Jones
I had a strange thing start up yesterday with my 389-console.
I have 4 directory servers in 2 data centers. I have been using
389-console to manage them. Yesterday, I opened 389-console for server 1
in datacenter 2 (DC2_1) and it ended up showing me server 1 in DC1
(DC1_1). Then I opened 389-console for DC2_2 and it was pointing at DC2_1.
I had a VM snapshot of DC2_1, so I rolled back to that snapshot and then
it was fine. But no snapshot of DC2_1 and I can't seem to get it to point
to it's own directory server. None of the files on the servers were
changed (no one has access to these files except me). I had been doing
some testing trying to set up a Solaris client to point to DC2_1 earlier
in the day, using ldapclient init and modify commands. Replication between
these servers is -
DC1_1 replicates to DC1_2 and DC2_1
DC1_2 replicates to DC1_1
DC2_1 replicates to DC2_2 and DC1_1
DC2_2 replictes to DC2_1
I don't have netscaperoot replicating, only userRoot data.
Any thoughts as to why those two servers got borked or how to fix?
thanks -
EJ
11 years, 2 months
Fedora-ds + freeradius + chap
by m4rr3nt0 m4r
I have a structure where my clients ADSL internet, authenticate using the LDAP basis fedora-Ds. via freeradius + pap + ldap
I tried to implement the same feature with CHAP however unsuccessfully.
As I read several tutorials on the item checkItem Cleartext-Password userPassword the ldap.attrmap should be changed.
Yet when consultants
radtest-t chap jonas.isaias 102 030 0 localhost testing123 results in Access-Reject
if
radtest-t chap jonas.isaias 102 030 0 localhost testing123 results in Access-Reject results in Access-Accept
Could you help me
11 years, 3 months
