Are you using 389-ds-base 1.2.4? 389-admin 1.1.9? PassSync 1.1.3?
by Rich Megginson
We are trying to get some feedback about the packages in testing before
we push them out to stable. The packages currently in testing are:
389-ds-base 1.2.4
389-admin 1.1.9
Windows PassSync 1.1.3
We would really like to know if you are using these and, if so, if they
are working for you (or not). These releases contain some bug fixes and
a couple of new features that the community at large has asked for and
would benefit from. But we don't want to push these releases to stable
until we get some more feedback.
Thanks
14 years, 5 months
more MMR issues
by Robert Viduya
I didn't get a response to my previous request for help and our
situation degenerated (we lost 3 of our 4 masters) to the point where
I felt we had to do a clean rebuild. We did that late last week into
the weekend and had set up a 2 masters and assorted hubs and slaves.
We used a clean ldif file to import into the first master, so no
previous replica IDs were carried over from the previous environment.
We are running directory version 1.2.2 on RHEL5.4, both 64-bit.
Things were running fine until this morning, when one of our masters
started reporting errors. We found this in it's errorlog:
[10/Nov/2009:08:56:27 -0500] NSMMReplicationPlugin -
multimaster_be_state_change: replica
ou=people,dc=gted,dc=gatech,dc=edu is going offline; disabling
replication
[10/Nov/2009:08:59:29 -0500] - WARNING: Import is running with nsslapd-
db-private-import-mem on; No other process is allowed to access the
database
[10/Nov/2009:08:59:33 -0500] - ERROR bulk import abandoned
[10/Nov/2009:08:59:34 -0500] - import people: Aborting all import
threads...
[10/Nov/2009:08:59:42 -0500] - import people: Import threads aborted.
[10/Nov/2009:08:59:43 -0500] - import people: Closing files...
[10/Nov/2009:08:59:43 -0500] - import people: Import failed.
[10/Nov/2009:09:01:51 -0500] NSMMReplicationPlugin -
replica_replace_ruv_tombstone: failed to update replication update
vector for replica ou=people,dc=gted,dc=gatech,dc=edu: LDAP error - 1
[10/Nov/2009:09:01:57 -0500] NSMMReplicationPlugin -
replica_replace_ruv_tombstone: failed to update replication update
vector for replica ou=people,dc=gted,dc=gatech,dc=edu: LDAP error - 1
[10/Nov/2009:09:02:01 -0500] NSMMReplicationPlugin -
replica_replace_ruv_tombstone: failed to update replication update
vector for replica ou=people,dc=gted,dc=gatech,dc=edu: LDAP error - 1
[10/Nov/2009:09:02:21 -0500] NSMMReplicationPlugin -
replica_replace_ruv_tombstone: failed to update replication update
vector for replica ou=people,dc=gted,dc=gatech,dc=edu: LDAP error - 1
[10/Nov/2009:09:02:26 -0500] NSMMReplicationPlugin -
replica_replace_ruv_tombstone: failed to update replication update
vector for replica ou=people,dc=gted,dc=gatech,dc=edu: LDAP error - 1
[10/Nov/2009:09:02:32 -0500] NSMMReplicationPlugin -
replica_replace_ruv_tombstone: failed to update replication update
vector for replica ou=people,dc=gted,dc=gatech,dc=edu: LDAP error - 1
That last line repeats until we brought the server down. The log
_looks_ like someone/something triggered an import operation, but no-
one did, on either master.
The errorlog on the other master shows the following:
[10/Nov/2009:08:39:29 -0500] - repl5_inc_waitfor_async_results timed
out waiting for responses: 38 46
[10/Nov/2009:08:39:54 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Warning: unable to receive
endReplication extended operation response (Bad parameter to an ldap
routine)
[10/Nov/2009:08:40:04 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Unable to receive the response for a
startReplication extended operation to consumer (Bad parameter to an
ldap routine). Will retry later.
[10/Nov/2009:08:40:08 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Unable to receive the response for a
startReplication extended operation to consumer (Bad parameter to an
ldap routine). Will retry later.
[10/Nov/2009:08:40:14 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Unable to receive the response for a
startReplication extended operation to consumer (Bad parameter to an
ldap routine). Will retry later.
[10/Nov/2009:08:40:38 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Unable to receive the response for a
startReplication extended operation to consumer (Bad parameter to an
ldap routine). Will retry later.
[10/Nov/2009:08:43:05 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Unable to receive the response for a
startReplication extended operation to consumer (Bad parameter to an
ldap routine). Will retry later.
[10/Nov/2009:08:44:50 -0500] - repl5_inc_waitfor_async_results timed
out waiting for responses: 6 8
[10/Nov/2009:08:47:08 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Unable to receive the response for a
startReplication extended operation to consumer (Bad parameter to an
ldap routine). Will retry later.
[10/Nov/2009:08:47:08 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Incremental protocol: event
backoff_timer_expired should not occur in state start_backoff
[10/Nov/2009:08:47:12 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Unable to receive the response for a
startReplication extended operation to consumer (Bad parameter to an
ldap routine). Will retry later.
[10/Nov/2009:08:47:18 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Incremental update failed and
requires administrator action
[10/Nov/2009:08:55:01 -0500] - repl5_inc_waitfor_async_results timed
out waiting for responses: 13 14
[10/Nov/2009:08:55:01 -0500] - repl5_inc_waitfor_async_results timed
out waiting for responses: 59 81
[10/Nov/2009:08:55:14 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Warning: unable to receive
endReplication extended operation response (Bad parameter to an ldap
routine)
[10/Nov/2009:08:55:24 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Unable to receive the response for a
startReplication extended operation to consumer (Bad parameter to an
ldap routine). Will retry later.
[10/Nov/2009:08:55:28 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Unable to receive the response for a
startReplication extended operation to consumer (Bad parameter to an
ldap routine). Will retry later.
[10/Nov/2009:08:55:34 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Unable to receive the response for a
startReplication extended operation to consumer (Bad parameter to an
ldap routine). Will retry later.
[10/Nov/2009:08:55:46 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Unable to receive the response for a
startReplication extended operation to consumer (Bad parameter to an
ldap routine). Will retry later.
[10/Nov/2009:08:56:10 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Unable to receive the response for a
startReplication extended operation to consumer (Bad parameter to an
ldap routine). Will retry later.
[10/Nov/2009:08:56:58 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Unable to receive the response for a
startReplication extended operation to consumer (Bad parameter to an
ldap routine). Will retry later.
[10/Nov/2009:08:58:34 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Replication bind with SIMPLE auth
resumed
[10/Nov/2009:09:01:47 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Consumer failed to replay change
(uniqueid 51dccc08-9efe11de-8efe8516-22c1043e, CSN
4af96f8a000200370000): Operations error. Will retry later.
[10/Nov/2009:09:01:47 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Consumer failed to replay change
(uniqueid 5ad5610c-1dd211b2-80b9be51-952a0000, CSN
4af96f8b000000370000): Operations error. Will retry later.
[10/Nov/2009:09:01:47 -0500] NSMMReplicationPlugin - agmt="cn=people
rewbell gertrude" (gertrude:636): Consumer failed to replay change
(uniqueid 213cd58e-cd7b11de-b535d108-950067b1, CSN
4af96fcf000000370000): Operations error. Will retry later.
Again, that last line repeats until we brought down the errant server.
We've seen this behavior a few times since upgrading. One of our
masters somehow thinks it's supposed to do an import and trashes it's
copy of the data. No person had triggered an import or a supplier-
>consumer initialization. Are there conditions where the directory
server itself would trigger such an operation autonomously?
14 years, 5 months
memberof entries not appearing in replica with memberof plugin
by John A. Sullivan III
Hello, all. I'm running CentOS Directory Server 8.1 on CentOS 5.4. For
some reason, the memberof plugin does not seem to be working on the
replica. My first suspicion is we have done something wrong but I
wonder if there is an error in the documentation. Here are the details.
We are single master setup with a single replica. We noticed some of
our LDAP queries were not correctly detecting group membership. We
double checked the memberofplugin configuration and, for some reason, it
seem to have reverted to looking at member instead of uniquemember. We
changed this on the master and our problem went away.
However, in the process of double-checking our steps, we read that the
memberof attribute should NOT be replicated. We had not excluded it.
So, we destroyed the replication agreement, created a new fractional
replication enabled one, and reinitialized the replica. All of the
memberof information was missing from all users on the replica. We then
tried to rebuild it by running the fixup-memberof.pl script. That
didn't work. We then simply tried deleting users from groups and adding
them to see if that would work. It worked fine on the master but not on
the replica.
Is the documentation in error and replication of memberof should be
excluded only in multimaster but should be propagated to consumers or
have we done something wrong? I compared the memberofplugin definitions
in dse.ldif on both and they look identical including being enabled.
Nothing is jumping out in the error or audit logs.
We eventually added memberof to the replication agreement and
resynchronized just to get the data across. We've pulled it back out
and, as expected, any changes are not replicating. What are we doing
wrong? Where do we look next to troubleshoot it? Thanks - John
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan(a)opensourcedevel.com
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society
14 years, 5 months
Replication errors with single master
by Terry Soucy
Hi Folks,
I have a weird issue that I can't find much information about.
We have a single-master replication setup, with the supplier replicating
to two consumers. The software is the same on all three systems
(fedora-ds-1.1.3-1) installed from packages. These are all new RHEL5.4
systems, i386 arch with 8G of RAM running the latest PAE kernel.
The error received is as follows ...
On the supplier ...
[10/Nov/2009:11:52:20 -0400] NSMMReplicationPlugin - agmt="cn=Gaia to
Nyx" (nyx:389): Replica has a different generation ID than the local data.
Lots of those, then the replication fails.
On the consumer ...
[10/Nov/2009:10:52:21 -0400] NSMMReplicationPlugin -
replica_replace_ruv_tombstone: failed to update replication update
vector for replica dc=unb,dc=ca: LDAP error - 1
Earlier attempts to create a replica have resulted in a File not found
error, as for some reason, all of the db4 files in the userRoot
(/var/lib/dirsrv/slapd-nyx/db) mysteriously disappeared.
Thoughts? We have beeen pouring over this for a bit now. Before we
went production, I was able to create replicas from the single supplier
to multiple consumers with no issues. We tested replication by updating
the supplier, and replication was spot on. Once we went production,
replication went to hell, and now even the simple task of creating a
replica is causing us no end of grief.
Thanks in advance.
Terry Soucy
--
Terry Soucy, Systems Analyst Integrated Technology Services
University of New Brunswick, Fredericton Campus http://www.unbf.ca/its
Voice: 506.447.3018 Fax: 506.453.3590 E-mail: tsoucy(a)unb.ca
** ITS is a scent-reduced workplace - www.unbf.ca/its/policies **
14 years, 5 months
Links for new passsync files
by James Roman
I am unable to download the 1.2.1 versions of the passsync msi files. I
could really use the x86_64 version.
14 years, 5 months
Administration URL
by Jesster Leight
Hello, How I can enter to the 389-console ?
I need correct port for Administration URL. (for example 0.0.0.0:9830
0.0.0.0:* LISTEN 8932/httpd.worker)
On my Fedora 11 i have RHN-Satellite and 389 Directory Server. Satellite
service stoped and /etc/init.d/dirsrv started.
Netstat show next stats:
$ netstat -ptan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address
State PID/Program name
tcp 0 0 0.0.0.0:57485 0.0.0.0:*
LISTEN 1223/rpc.statd
tcp 0 0 0.0.0.0:111 0.0.0.0:*
LISTEN 1205/rpcbind
tcp 0 0 192.168.122.1:53 0.0.0.0:*
LISTEN 2281/dnsmasq
tcp 0 0 0.0.0.0:22 0.0.0.0:*
LISTEN 1558/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:*
LISTEN 1294/cupsd
tcp 0 0 127.0.0.1:25 0.0.0.0:*
LISTEN 1722/sendmail: acce
tcp 0 0 10.1.10.211:35594 74.125.87.167:80
ESTABLISHED 7784/firefox
tcp 0 0 10.1.10.211:57888 74.125.87.189:80
ESTABLISHED 7784/firefox
tcp 0 0 10.1.10.211:36308 74.125.87.103:80
ESTABLISHED 7784/firefox
tcp 0 0 10.1.10.211:44402 74.125.87.132:80
ESTABLISHED 7784/firefox
tcp 0 0 10.1.10.211:41462 74.125.87.17:80
ESTABLISHED 7784/firefox
tcp 0 0 10.1.10.211:41463 74.125.87.17:80
TIME_WAIT -
tcp 0 0 :::111 :::*
LISTEN 1205/rpcbind
tcp 0 0 :::22 :::*
LISTEN 1558/sshd
tcp 0 0 ::1:631 :::*
LISTEN 1294/cupsd
tcp 0 0 :::389 :::*
LISTEN 9637/ns-slapd
$ /etc/init.d/dirsrv status
dirsrv satellite (pid 9637) is running...
Where is httpd.worker processes ?
14 years, 5 months
Re: Fedora EPEL 5 updates-testing report - 389 coming to EPEL.
by Orion Poplawski
On 11/06/2009 11:32 AM, updates(a)fedoraproject.org wrote:
> The following builds have been pushed to Fedora EPEL 5 updates-testing
>
> 389-admin-1.1.9-1.el5
> 389-admin-console-1.1.4-3.el5
> 389-adminutil-1.1.8-4.el5
> 389-ds-1.1.3-6.el5
> 389-ds-base-1.2.4-1.el5
> 389-ds-console-1.2.0-5.el5
> 389-dsgw-1.1.4-1.el5
> idm-console-framework-1.1.3-3.el5
> jss-4.2.5-1.el5
>
> Details about builds:
>
>
> ================================================================================
> 389-admin-1.1.9-1.el5 (FEDORA-EPEL-2009-0803)
> 389 Administration Server (admin)
> --------------------------------------------------------------------------------
> Update Information:
>
> 389 package suite now available in EPEL.
> --------------------------------------------------------------------------------
Looks like we're still waiting for 389-console too:
389-ds-1.1.3-6.el5.noarch from epel-testing has depsolving problems
--> Missing Dependency: 389-console is needed by package
389-ds-1.1.3-6.el5.noarch (epel-testing)
But more to the point, what are the gotchas upgrading from:
fedora-ds-admin-console-1.1.2-1.el5
fedora-ds-1.1.2-1.el5
fedora-ds-admin-1.1.6-1.el5
fedora-ds-dsgw-1.1.1-1.el5
fedora-ds-base-1.1.2-1.el5
fedora-ds-console-1.1.2-2.el5
I seem to recall a warning posted somewhere about things getting
shutdown/removed. Anything else?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
14 years, 5 months
