Hi Marc,
Thanks! Appreciate the quick response and all the links.
Cheers,
On 10/15/19 3:06 PM, Marc Sauton wrote:
The link provided is for an older version no longer maintained.
The current link is
I think I also need python3-lib389 = 1.4.1.8-4.fc30
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Only when the LDAP service is stopped:
With a manual edit of the dse.ldif configuration file after it is
saved/duplicated.
Look and "carefully" select entries with definitions for
objectClass: nsds5replicationagreement
similar to for example
dn:
Could be a system without enough available RAM to the ns-slapd process,
eventually hitting a previously fixed issue.
But cannot tell for sure without more details.
Try to review the system messages and the ns-slapd errors log file, not
just the systemd general status output.
Thanks,
M.
On Tue,
The link provided is for an older version no longer maintained.
The current link is
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/configuring_directory_databases#Creating_Suffixes-Creating_a_New_Root_Suffix_Using_the_Console
LDAP replication
Hi All
we are facing some critical decisions, we have 2 server in multimaster
replication , one of DS master is off-line/crashed
how can we removed the replication agreement for the online DS master to
the off-line DS master ?
thank you
Isabella
Hi Folks,
I have a multimaster replication running between two servers in the
site.edu domain. We now want to replicate this data (for user logins
to resources) to
a sister site with domain site1.edu.
I tried several things and nothing worked so I thought the best thing to
do would be to
We do not currently support it, but we just opened a ticket a few days
ago to add this feature:
https://pagure.io/389-ds-base/issue/50645
Sorry no time line yet on when we are going to add it, but we are going
to add it at some point.
Mark
On 10/15/19 2:52 PM, Keith Hazelton wrote:
Does
Does 389 Directory Server support the permissive modify request operation?
See https://ldap.com/ldapv3-wire-protocol-reference-modify/
and
https://docs.ldap.com/ldap-sdk/docs/javadoc/com/unboundid/ldap/sdk/controls/PermissiveModifyRequestControl.html
--Keith Hazelton
Thank you for reply, I believe this is a memory issue related see the last
line, we were been waiting patiently for last hours to recover db but no
progress so far .
One of the link you pointed is no working , unfortunately this is not RHEL7.7
is Scientific Linux can not open the a case.
If this build works please give it karma:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-6214f75764
Thanks,
Mark
On 10/15/19 11:27 AM, Ldap Tester wrote:
I don't know. It doesn't seem to be. There are no other packages obsoleting
389-admin. Adding --allowerasing to the dnf command does
The "recovering database" may take a few minutes to complete.
Check the errors log file again for any newer messages after the recovery.
For the crash, or if till not starting up, try to get a core file and stack
trace:
https://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
HI All
one of our multmaster DS crashed over the weekend and will not restart , ther
are no errors reported in DS errorlog here are details:
OS:
Linux .el7.x86_64 #1 SMP Tue Jun 26 16:32:21 UTC 2018 x86_64 x86_64 x86_64
GNU/Linux
389-DS
389-ds-base-1.3.7.5-24.el7_5.x86_64
and
systemctl
The admin and console packages are going away in F31 (fyi)
So I'm seeing the same problem though, and it's probably the perl
provide/requires filters we added to the spec file (ugh can't wait for
389-admin to go away). Anyway, I'll need to do a new build on F30 to
remove these perl
I don't know. It doesn't seem to be. There are no other packages obsoleting
389-admin. Adding --allowerasing to the dnf command does not remove it. If I
dnf remove 389-admin, it wants to also remove 389-ds, 389-admin-console,
389-admin-console-doc, 389-ds-base-legacy-tools, 389-ds-console,
15 matches
Mail list logo
