[389-users] Re: One way supplier replication is failing on newly installed instance

[Marc Sauton]

try to review the access log for connection events related to those from
the errors log file mentioned earlier, and also verify on the remote
replica,  the errors and access log events corresponding to this
connection, as well as file descriptors and LDAP thread use, run some
netstat and dsconf monitor commands:

dsconf SOME-INSTANCE-NAME-HERE config get nsslapd-conntablesize
nsslapd-threadnumber nsslapd-maxdescriptors
dsconf SOME-INSTANCE-NAME-HERE monitor server
sysctl net.core.somaxconn net.ipv4.tcp_max_syn_backlog


On Thu, Apr 18, 2024 at 10:53 AM  wrote:

> Just to add:
>
> - I can manually make a connection from the old to new using the
> replication account and password, so connectivity is fine.
> - The old server is in 2-way replication with another server of the same
> version and that is all working perfectly.
> --
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] Re: Determining max CSN of running server

[Marc Sauton]

there was an old RHEL-7.4 and RHEL-7.5 issue and fix in
1.3.5.10-20 replication halt - pending list first CSN not committed,
pending list increasing
https://bugzilla.redhat.com/1460070
https://github.com/389ds/389-ds-base/issues/2346
but you have a (somehow) more recent version,
389-ds-base-1.3.10.2-10.el7_9.x86_64 ( and one
389-ds-base-1.3.11.1-1.el7_9.x86_6 ) , so this should be fixed.
the issue could have been related to sub operations.
the logs provided do show a replica with a large and growing pending list,
taking several seconds to parse (in double digits).
and in this particular replication agreement, the consumer's max CSN is
higher than the local supplier's one, so the remote replica/consumer is
flagged as "ignored"
then later in time some updates go through as the RUV in the R.A. have been
updated by a better knowledgeable replica.
but this seems to repeat (strange)
I want to suggest deleting the changelog, and re-init that replica, but
maybe Thierry or Pierre or William B. have a better suggestion.
M.



On Thu, Feb 29, 2024 at 2:21 PM William Faulk 
wrote:

> > FYI: There is a list of pending operations to ensure that the RUV is not
> > updated while an older operation is not yet completed. And I suspect that
> > you hit a bug about this list. I remember that we fixed something in that
> > area a few years ago ...
>
> I think I found it, or something closely related.
>
> https://github.com/389ds/389-ds-base/pull/4553
> --
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] Re: 389 DS 2.3.6 on RHEL 9 replication over TLS

[Marc Sauton]

"LDAP error: Can't contact LDAP server (connection error)" is kind of
generic, but often relates to PKI trust misconfiguration when TLS is used,
a common issue is the issuer / CA certificate(s) chain is not installed, or
not trusted.
There should be a message in the access log, for example "Peer does not
recognize and trust the CA that issued your certificate."

a typical scenario is when the default test /demo/self signed certs are
left over and used between 2 LDAP instances for replication, we have an
example in this article (subscription required)
  https://access.redhat.com/solutions/6449561
  How To test LDAPS with RHDS instances on 2 systems and default test CA
this happens as there is no shared configuration between instances.

in the links Thierry B. posted, also see this chapter:

1.8. Adding the CA certificate used by Directory Server to the trust store
of Red Hat Enterprise Linux
https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/securing_red_hat_directory_server/assembly_enabling-tls-encrypted-connections-to-directory-server_securing-rhds#proc_adding-the-ca-certificate-used-by-directory-server-to-the-trust-store-of-red-hat-enterprise-linux_assembly_enabling-tls-encrypted-connections-to-directory-server

I usually run a "trust anchor some.file.ca.crt" command, and add the
issuer(s) to the LDAP instance's NSS db.



On Fri, Jan 26, 2024 at 1:21 AM Thierry Bordaz  wrote:

> You may follow the doc to configure TLS on your both suppliers [1] and
> check the trusted CA on both side [2]. On troubleshooting side you may look
> at [3]
>
> [1]
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/securing_red_hat_directory_server/assembly_enabling-tls-encrypted-connections-to-directory-server_securing-rhds#doc-wrapper
> [2]
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/securing_red_hat_directory_server/assembly_changing-the-ca-trust-flagssecuring-rhds#doc-wrapper
> [3]
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/configuring_and_managing_replication/assembly_troubleshooting-replication-related-problems_configuring-and-managing-replication
>
>
> On 1/25/24 23:55, Ciara Gadsden wrote:
>
> Idk how to do that lol
>
> Sent from my Boost Samsung Galaxy A23 5G
> Get Outlook for Android 
> --
> *From:* Simon Pichugin  
> *Sent:* Thursday, January 25, 2024 5:44:57 PM
> *To:* General discussion list for the 389 Directory server project.
> <389-users@lists.fedoraproject.org> <389-users@lists.fedoraproject.org>
> *Cc:* alexander_nazare...@harvard.edu 
> 
> *Subject:* [389-users] Re: 389 DS 2.3.6 on RHEL 9 replication over TLS
>
> Hello Alex,
> I think we need a bit more information here.
>
> First of all, could you please run the "dsconf repl-agmt create" (LDAPS
> one) with "-v" flag? It will give a detailed verbose output.
> Also, I recommend checking the server's error and access log for more
> information why it fails (additionally, you may enable at least 16384+8192
> (Default + Replication debugging) in nsslapd-errorlog-level).
>
> As for possible issues and actions, at first glance, I recommend checking
> that the TLS certificates used are correctly installed and trusted on both
> the supplier and consumer instances. It's important that the instances
> trust each other; even though ldapsearch (OpenLDAP client) on the supplier
> already trusts the consumer machine, it's not enough.
>
> Sincerely,
> Simon
>
>
>
> On Thu, Jan 25, 2024 at 1:07 PM Nazarenko, Alexander <
> alexander_nazare...@harvard.edu> wrote:
>
> Hello colleagues,
>
>
>
> Lately we started looking into 389 DS 2.3.6 on RHEL 9 platform.
>
>
>
> We followed instructions Configuring and managing replication
> 
> on Red Hat site to establish replication between two remote instances,
>
> The instances where previously configured to support TLS channel on port
> 636 (Enabling TLS-encrypted connections to Directory Server
> 
> ) , and we made sure ldapsearch is working with LDAPS:// protocol with
> the certificate verification (TLS_REQCERT demand).
>
>
>
> The following issue with the replication over TLS was observed:
>
>
>
> After we ran the command below to configure secure replication:
>
> dsconf -D "cn=Directory Manager"  -w *** ldaps://server.example.edu
> repl-agmt create --suffix "dc=example,dc=com" --host "consumer.example.edu"
> --port 636 --conn-protocol=LDAPS --bind-dn "cn=replication
> manager,cn=config" --bind-passwd "***" --bind-method=SIMPLE --init
> consumer.example.edu-RO
>
>
>
> the error occurred:
>
> Error (-1) Problem connecting to replica - 

[389-users] Re: Solving naming conflicts in replicated environment

[Marc Sauton]

Hello William,
I am sorry to read you had a not so ideal support experience, I located a
case number that seems to match this thread, and we will look into what can
be improved, and maybe even we should try to discuss the situation with a
meeting.
I think it is important to ring an alarm in the support ticket system when
there is some sort of dissatisfaction in the resolution, timing, or
environment awareness that is related to the reported issue and particular
technology, so the case can be presented to a next level, or somebody with
a specific knowledge, or escalated if needed.
This would be a different topic, but being able to reach the creators and
developers of a software directly, those with the best knowledge of very
specific features, freely, is amazing, those developers are not support
engineers, but till spend time here, so I am very glad to see a thriving
community of users in this list, from newbies to what I call "power users"
with operational experience ( the "real world").
Thanks all for participating,
M.

On Thu, Jan 18, 2024 at 8:50 AM William Faulk 
wrote:

> I completed this last night. I found that deleting the active entry did
> not automatically promote the conflict entry. I still had to perform the
> modrdn operation.
>
> Also, in addition to deleting the "nsds5ReplConflict" attrbute, I also
> manually deleted the "ConflictCSN" attribute, and the "ldapsubentry" value
> from the "objectclass" attribute.
>
> And it didn't magically get added to the groups that the formerly active
> entry and the same entry in the other IdM replicas was in. I had to add
> them manually, using IdM utilities, on the replica where this change took
> place. (I actually only had to add one group; the other memberships were
> based on that one group, so adding it to that group added it to the others.)
>
> After that, though, the entry on this server matched the entries on the
> other replicas except for "entryusn", "entryid", and "modifyTimestamp",
> which I believe are all normal variances.
>
> Thanks for your help.
>
> By the way, Red Hat support spent four days failing to even understand the
> question that you answered for me in half an hour: that deleting the active
> entry here wouldn't delete it on the other replicas. I asked them three or
> four times, each time getting a response that either explained to me how to
> delete the conflict entry, or failing to address the idea that it might
> delete the entry on the replicas, until I was finally told that it was
> impossible to promote the conflict entry, despite the documentation
> providing a procedure exactly for that, and that I would have to
> reinitialize the data on that replica.
>
> If anyone has any suggestions for a vendor that can provide decent IdM
> support, I'd love to hear it.
>
> Again, many thanks to everyone here.
> --
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] Re: Documentation as to how replication works

[Marc Sauton]

several ways to access a changelog
dsconf IDM-EXAMPLE-TEST replication dump-changelog -o ~/changelog.ldif
or use dbscan -f
doc ref
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/exporting-up-the-replication-changelog
15.15. EXPORTING THE REPLICATION CHANGELOG

the retro changelog is different, for example used for IPA DNS, via a
dedicated plug-in, or can be used for migrations in a general purpose LDAP
use case.

about the RUV records and values in the replication agreements:
this is a local view of what each replica thinks the other replicas know at
a moment in time, a local private topology snapshot view, and those views
are supposed to be all very close, or converge. if not, there can be chaos.
and more replication agreements = more processing when many updates are
sent to various replicas.


On Thu, Nov 16, 2023 at 4:38 PM David Boreham  wrote:

>
> On Thu, Nov 16, 2023, at 5:17 PM, William Faulk wrote:
>
>
> Since asking the question, I've been doing some research and found that
> the "cn=changelog" tree is populated by the "Retro Changelog Plugin", and
> on my systems, that has a config that limits it to the "cn=dns" subtree in
> my domain. I
>
>
> Retro changelog is not the changelog you are looking for :)
>
>
> The cn=changelog5,cn=config entry contains the on-disk location of the
> changelog where its saved as a Berkeley DB. It's almost as easy to pull the
> same data out of there.
>
>
> You could do that. Also I noticed there is code to dump the changelog to a
> flat file, but it isn't clear to me how to call it :
>
> https://github.com/389ds/389-ds-base/blob/main/ldap/servers/plugins/replication/cl5_api.c#L4273
>
>
> --
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] Re: Documentation as to how replication works

[Marc Sauton]

Just wanted to add it is important to try updating the RHEL IdM servers to
the current RHEL version ( RHEL-9.x ), and that replication lag depends on
many variables, for example: how many replication agreements per replicas,
what is the topology ( meshed versus chains, clusters of replicas ),
traffic patterns for connections, updates and search filters, index use, ID
scan limits, how many RHEL IdM SSSD clients are hitting IPA replicas, if AD
trust is used, how many LDAP worker threads/CPU cores can handle
processing demand, memory and caches configurations, changelog size,
trimming events, etc..
Thanks,
M.

On Wed, Nov 15, 2023 at 9:45 AM Thierry Bordaz  wrote:

> Hi,
>
> The explanation below looks excellent to me. You may also have a look at
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/deployment_guide/designing_the_replication_process#doc-wrapper
>
> Regarding the initial concern "having regular problems with missed
> replications". A key element is that there is no synchronous replication,
> an update is not sync immediately to all replicas. A LDAP client req an
> update on one replica (original replica) that will propagate the update to
> others replicas (themselves will be able to propagate it to a next replica
> ("hops")). So there may be a delay (replication lag) between the original
> update and the time the last replica will receive it. Usually the delay is
> few seconds but may depend on may factors.
>
> As you noticed, updates are identified with CSN that are logged in access
> log. If you suspect that an update is missing, you need to check if the
> related CSN is present in the remote replicas access log files. note that
> access logs are buffered.
>
> best regards
> thierry
> On 11/15/23 18:12, David Boreham wrote:
>
> I'm not sure about doc, but the basic idea iirc is that a vector clock[1]
> (called replica update vector) is constructed from the sequence numbers
> from each node. Therefore it isn't necessary to keep track of a list of
> CSNs, only compare them to determine if another node is caught up with, or
> behind the state for the sending node. Using this scheme, each node
> connects to each other and by asking the other node for its current ruv can
> determine which if any of the changes it has need to be propagated to the
> peer. These are sent as (almost) regular LDAP operations: add, modify,
> delete. The consumer server then decides how to process each operation such
> that consistency is preserved (all nodes converge to the same state). e.g.
> it might skip an update because the current state for the entry is ahead of
> the update. It's what nowadays would be called a CDRT scheme, but that term
> didn't exist when the DS was devloped.
>
> [1] https://en.wikipedia.org/wiki/Vector_clock
>
> On Wed, Nov 15, 2023, at 9:59 AM, William Faulk wrote:
>
> I am running a RedHat IdM environment and am having regular problems with
> missed replications. I want to understand how it's supposed to work better
> so that I can make reasonable hypotheses to test, but I cannot seem to find
> any in-depth documentation for it. Every time I think I start to piece
> together an understanding, experimentation makes it fall apart. Can someone
> either point me to some documentation or help me understand how it works?
>
> In particular, IdM implements multimaster replication, and I'm initially
> trying to understand how changes are replicated in that environment. What I
> think I understand is that changes beget CSNs, which are comprised of a
> timestamp and a replica ID, and some sort of comparison is made between the
> most recent CSNs in order to determine what changes need to be sent to the
> remote side. Does each replica keep a list of CSNs that have been sent to
> each other replica? Just the replicas that it peers with? Can I see this
> data? (I thought it might be in the nsds5replicationagreement entries, but
> the nsds50ruv values there don't seem to change.) But it feels like it
> doesn't keep that data, because then what would be the point of comparing
> the CSN values be? Anyway, these are the types of questions I'm looking to
> understand. Can anyone help, please?
>
> --
> William Faulk
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
>
>
> ___
> 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: 
> 

[389-users] Re: Replication question

[Marc Sauton]

I think you are correct for a "no", from the admin guide:
"
What Directory Units Are Replicated
The smallest unit of of the directory which can be replicated is a database.
This means that one can replicate an entire database but not a subtree
within a database.
Therefore, when creating the directory tree, consider any replication plans
as part of determining how to distribute information.
Replication also requires that one database correspond to one suffix.
This means that a suffix (or namespace) that is distributed over two or
more databases using custom distribution logic cannot be replicated.
"


On Thu, Aug 24, 2023 at 4:04 PM  wrote:

> I've got two 389 multi-supplier replicated instances that I want to
> replicate to two new ones just temporarily for migration purposes. Since
> this is production, it would be ideal if it could be replicating right up
> to the second I make the new ones live. However, I simplified the
> configuration on the new one and now I'm wondering if this scheme will
> still work.
>
> On the old one, I have two replicated DBs, one mapped to
> ou=b,dc=a,dc=arizona,dc=edu and the other mapped to dc=a,dc=arizona,dc=edu.
> On the new one, I decided to have just one replicated DB, mapped to
> dc=arizona, dc=edu. Is it possible to replicate the old ones to the new
> instance? I'm thinking no, but I had to ask.
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] Re: Unable to establish replication with STARTTLS

[Marc Sauton]

The "unable to get issuer certificate" part really means it, and this has
been quite a common issue for either LDAPS or STARTTLS, about a missing
cert or missing trust flag in the PKI chain of trust of the issuer, and it
is usually solved by a "trust anchor" command for the system, or a certutil
-A in the LDAP NSS db directory, .
For the operating system point of view with a LDAP client,  a"-d 4" added
to ldapsearch, or a strace could show in which directory or key store the
issuer is not trusted.
Does a "trust anchor some.ca.cert.pem.txt" help?
Thanks,
M.

On Tue, May 23, 2023 at 3:30 AM Jakob Moser  wrote:

> A similar problem seems to have been posted on Server Fault:
>
>
> https://serverfault.com/questions/1131289/ldap-replication-to-server-with-lets-encrypt-certificate-fails-unable-to-get
>
> It uses Implict TLS instead of STARTTLS, but apart from that shows the
> same symptoms, I believe.
> Sadly, Server Fault has so far also been unable to figure out what the
> problem is.
>
> Regards
> Jakob
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] Re: Unable to establish replication with STARTTLS

[Marc Sauton]

the error message
NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=DS11-ancds10"
(ancds10:636) - Replication bind with SIMPLE auth failed: LDAP error -1
(Can't contact LDAP server) (error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed (unable
to get issuer certificate))

seems to indicate the LDAP service on the system trying to connect
to ancds10:636 does not trust the issuer of the SSL server certificate
installed for ancds10:636

a test command can be a LDAP search from DS11 trying to reach to ancds10:636
ldapsearch -LLLxD "cn=directory manager" -W -H ldaps://ancds10:636 -s base
-b "" vendorVersion

Thanks,
M.


On Fri, May 19, 2023 at 4:22 PM John Thurston 
wrote:

> Revisiting this problem of replication and certificates. Thank you Marc
> Sauton for pointing out the 'dsconf' command to spill the ca-cert list.
>
> The synopsis is: instance #1 can replicate with instance #3 when #3 has a
> GlobalSign cert, but not when #3 has a Let's Encrypt cert. Instance #2 has
> no such problem replicating.
>
> (All instances are running 1.4.4.17 B2021.280.1354 on CentOS)
>
> On instance #1 (and on instance #2), when we use dsconf to ask about the
> ca-certificate list, we get:
>
> Certificate Name: GlobalSign Root R3
> Subject DN: CN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3
> Issuer DN: CN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3
> Expires: 2029-03-18 10:00:00
> Trust Flags: CT,,
>
> Certificate Name: GlobalSign RSA Organization Validation CA - 2018
> Subject DN: CN=GlobalSign RSA OV SSL CA 2018,O=GlobalSign nv-sa,C=BE
> Issuer DN: CN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3
> Expires: 2028-11-21 00:00:00
> Trust Flags: CT,,
>
> Certificate Name: Lets Encrypt Top
> Subject DN: CN=ISRG Root X1,O=Internet Security Research Group,C=US
> Issuer DN: CN=DST Root CA X3,O=Digital Signature Trust Co.
> Expires: 2024-09-30 18:14:03
> Trust Flags: CT,,
>
> Certificate Name: Lets Encrypt Intermediate
> Subject DN: CN=R3,O=Let's Encrypt,C=US
> Issuer DN: CN=ISRG Root X1,O=Internet Security Research Group,C=US
> Expires: 2025-09-15 16:00:00
> Trust Flags: CT,,
>
>
> On instance #3, when a GlobalSign cert is installed and port 636 is
> queried with openssl s_client:
>
> CONNECTED(0003)
> depth=2 OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
> verify return:1
> depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
> verify return:1
> depth=0 C = US, ST = Alaska, L = Juneau, O = State of Alaska, CN =
> ancds10.state.ak.us
> verify return:1
> ---
> Certificate chain
>  0 s:C = US, ST = Alaska, L = Juneau, O = State of Alaska, CN =
> ancds10.state.ak.us
>i:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>v:NotBefore: Apr 26 18:06:15 2023 GMT; NotAfter: May 27 18:06:14 2024
> GMT
>  1 s:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>v:NotBefore: Nov 21 00:00:00 2018 GMT; NotAfter: Nov 21 00:00:00 2028
> GMT
>  2 s:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>v:NotBefore: Mar 18 10:00:00 2009 GMT; NotAfter: Mar 18 10:00:00 2029
> GMT
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MIIGijCCBXKgAwIBAgIMfqUEla3ttBPK/lvlMA0GCSqGSIb3DQEBCwUAMFAxCzAJ
> BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSYwJAYDVQQDEx1H
> bG9iYWxTaWduIFJTQSBPViBTU0wgQ0EgMjAxODAeFw0yMzA0MjYxODA2MTVaFw0y
> NDA1MjcxODA2MTRaMGcxCzAJBgNVBAYTAlVTMQ8wDQYDVQQIEwZBbGFza2ExDzAN
> BgNVBAcTBkp1bmVhdTEYMBYGA1UEChMPU3RhdGUgb2YgQWxhc2thMRwwGgYDVQQD
> ExNhbmNkczEwLnN0YXRlLmFrLnVzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
> CgKCAQEA12s9pW28BNfMPMUdV54DFGg7EmJv7pcmYhnOvq0vqQ845tEillOHptUj
> muwVOgj8Dcl+PPiDHXeggwKdMA9253Pov7eVGzKfmNN1IwSmOZYKaNLKy1CNQS13
> eD0Wov0+yq35CqRHWwsl8+7Og56IfPXSmmRQPp21VBC//qkcBezomtTaSSzeE1op
> 248cN8H0wjL0gsPdujzrJmr7xP1gNT4gZQVkNlEAo8hJ3IxvSPvJ+E24FJwMixVb
> ICUz/crjRXG9nSSudP/225GxaaG3QPOSzOIZD4sT+Pt7lxmQU1syTChd5SHVK1AS
> WW4I2z1j68/o/ujXiqeP4iiMysRzXQIDAQABo4IDSzCCA0cwDgYDVR0PAQH/BAQD
> AgWgMIGOBggrBgEFBQcBAQSBgTB/MEQGCCsGAQUFBzAChjhodHRwOi8vc2VjdXJl
> Lmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3JzYW92c3NsY2EyMDE4LmNydDA3Bggr
> BgEFBQcwAYYraHR0cDovL29jc3AuZ2xvYmFsc2lnbi5jb20vZ3Nyc2FvdnNzbGNh
> MjAxODBWBgNVHSAETzBNMEEGCSsGAQQBoDIBFDA0MDIGCCsGAQUFBwIBFiZodHRw
> czovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAIBgZngQwBAgIwCQYD
> VR0TBAIwADA/BgNVHR8EODA2MDSgMqAwhi5odHRwO

[389-users] Re: Unable to establish replication with STARTTLS

[Marc Sauton]

the hint for that error, may be at the end of the line, with:
certificate verify failed (unable to get issuer certificate)

the LDAP instances and systems need to trust the issuers of the newer
certificates of each other ( PKI trust chain ).

trust anchor ~/some.ca.crt
trust list | grep -i "some CA"

and
dsconf some-ldap-instance security ca-certificate add --file ~/some.ca.crt
--name testca

documentation reference:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/managing_the_nss_database_used_by_directory_server
9.3. MANAGING THE NSS DATABASE USED BY DIRECTORY SERVER

Thanks,
M.

On Wed, Apr 26, 2023 at 1:43 PM John Thurston 
wrote:

> I have two hosts with 389-Directory/1.4.4.17 B2021.280.1354 on CentOS
> Stream release 8 (4.18.0-448.el8.x86_64)
>
> On a.state.ak.us, there is one instance defined (call this instance #1)
>
> On b.state.ak.us, there are two instances defined (call them #2 and #3)
>
> Instances #1 and #3 have GlobalSign certificates installed. Instance #2
> currently has a Let's Encrypt certificate installed. All instances also
> have root and intermediate certs in their databases for GlobalSign, which
> are marked with Trust Flags "CT,,".
>
> I can define instance #2 as a supplier, and define a replication agreement
> which populates #3. This works with both LDAPS and STARTTLS.
>
> If I, instead, try to define the same replication agreement on instance
> #1, it fails with:
>
> slapi_ldap_bind - Error: could not send startTLS request: error -11
> (Connect error)
>
> NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=DS11-1to3" (b:389) -
> Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error)
> (error:1416F086:SSL routines:tls_process_server_certificate:certificate
> verify failed (unable to get issuer certificate))
>
> slapi_ldap_bind - Error: could not send startTLS request: error -11
> (Connect error)
>
>
> I am unable to figure out how instances #1 and #2 differ.
>
> Instance #1 has long-established supplier-agreements (using both LDAPS and
> STARTTLS) with other instances of 389-Directory. So I know instance #1 can
> function correctly as a supplier. Instance #3 demonstrates it can be a
> consumer when supplied by instance #2. I can perform LDAPS and STARTTLS
> queries from a.state.ak.us to instance #3, so I know it is listening on
> the network and not blocked by a host-based firewall.
>
> Any suggestions of where to look, or config-attributes to check, would be
> appreciated.
>
>
> --
> --
> Do things because you should, not just because you can.
>
> John Thurston907-465-8591john.thurs...@alaska.gov
> Department of Administration
> State of Alaska
>
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] Re: ACME certificate and NSS databases

[Marc Sauton]

The "dsconf some-instance-name security" and dsctl commands can be used to
manipulated the certs and keys used by the LDAP service:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/managing_the_nss_database_used_by_directory_server#importing-a-private-key-and-server-certifiate
9.3.3. Importing a Private Key and Server Certificate
9.3.4. Installing a Server Certificate
and
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/managing_the_nss_database_used_by_directory_server#installing_a_ca_certificate
9.3. Managing the NSS Database Used by Directory Server
Plus run the system's "trust anchor" command so a PKI chain of trust is
known by the local system.

Or, if the LDAP service is stopped, a new PEM cert can replace the existing
SSL server cert in the NSS db using a certutil -A command, or a PKCS #12
file can be exported or imported into the NSS db ( pk12util -h )

For ACME, as a reference from the PKI server side of things, there is an
example of an ACME responder from the upstream PKI project dogtag ( used
for the Red Hat Certificate System / general purpose PKI solution ), and
the suggested ACME clients are certbot and openshit-acme, in case it may
provide with some ideas:
https://github.com/dogtagpki/pki/blob/master/docs/user/acme/Using_PKI_ACME_Responder_with_Certbot.md
https://github.com/dogtagpki/pki/wiki/Using-PKI-ACME-Responder-with-openshift-acme
But of course any ACME compliant client should work just fine, it would
be interesting to know more if anybody is using ACME for the LDAP SSL
server certs, and what kind of validity dates are used.

Thanks,
Marc S.




On Wed, Apr 5, 2023 at 9:20 AM John Thurston 
wrote:

> We currently use publicly-signed, and manually renewed, certificates on
> our internal directory servers. On other internal and external systems, we
> use public and private certificates handled by ACME-compliant agents.
>
> I took a quick look, and was reminded that 389-Directory keeps its certs
> in an NSS database. Before I go hack together my own wrapper on certutil, I
> thought I'd ask:
>
> Does anyone have a working ACME/Let's Encrypt agent they want to share?
>
> --
> --
> Do things because you should, not just because you can.
>
> John Thurston907-465-8591john.thurs...@alaska.gov
> Department of Administration
> State of Alaska
>
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] Re: Replication Problem

[Marc Sauton]

that looks like the errors log from 1 / A doing an init of 2 / B

there should be some activity about "NOTICE - NSMMReplicationPlugin -
changelog program - _cl5ConstructRUV" between
[31/Jan/2022:13:01:38.997721794 +] - INFO - NSMMReplicationPlugin -
repl5_tot_run - Beginning total update of replica
"agmt="cn=ldapserver1-to-ldapserver2" (ldapserver2:389)".
and
[31/Jan/2022:13:04:38.633566100 +] - DEBUG - NSMMReplicationPlugin -
close_connection_internal - agmt="cn=ldapserver1-to-ldapserver2"
(ldapserver2:389) - Disconnected from the consumer
there is like a heartbeat every 30 seconds, but nothing during 3 minutes?

verify the errors log on the replica being initialized, 2 / B
it  should have matching events about
NOTICE - NSMMReplicationPlugin - multimaster_be_state_change
INFO - bdb_instance_start - Import
INFO - bdb_import_main - import
INFO - bdb_get_nonleaf_ids - import
...etc...
and with debug, some progress with a rate of entry per seconds

may eventually need to check and/or tune the cache and  import cache
parameters, and find out what is the amount of free RAM for ns-slapd:
either
grep "NOTICE - ldbm_back_start" /var/log/dirsrv/slapd-ldapserver2/errors
or
ldapsearch -xLLLD "cn=directory manager" -W -b "cn=bdb,cn=config,cn=ldbm
database,cn=plugins,cn=config" nsslapd-cache-autosize
nsslapd-cache-autosize-split nsslapd-import-cache-autosize
nsslapd-import-cachesize


On Mon, Jan 31, 2022 at 9:38 PM Mansoor Raeesi 
wrote:

> Server A is ldapserver1 & Server B is ldapserver2
>
>
> this is log of server B:
>
>
> https://pastebin.ubuntu.com/p/f8SRb6kYn9/
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] Re: Help to understand pre-hashed login

[Marc Sauton]

you can use the pwdhash command to generate some pre-hashed passwords, and
then add them to the configurations or into the user's entries:
man pwdhash
pwdhash -s SSHA512 pasword
{SSHA512}JnzerkmYXKEuMcv...snip...
Thanks,
M.

On Thu, Dec 30, 2021 at 4:05 AM Caderize Caderize 
wrote:

> Hello everyone,
> i am writing a small php application in order to manage D389 users.
> Currently, in order to connect to it, i saved the admin password in clear
> text in a config.php file, just for test.
>
> Now i would move these settings into mysql database and hash the password
> for secure reason, probably sha1 or sha256 with salt(will see).
> The application should retrieve credentials from mysql db(which will be a
> salted hashed password "{SHA}") and try to connect to D389.
>
> My question is: Does D389 can authenticate if i pass to it a pre-hashed
> password?
> Is there any documentation or example to follow?
>
> Hope this question will not be considered as stupid.
>
> Many Thanks
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] Re: LDIF imports

[Marc Sauton]

The path to the LDIF file is not hardcoded, it is usually a file and/or
directory permission and/or SELinux label problem to allow the uid running
the LDAP service to read that file.
It should be the same as in the default LDIF directory provided as an
example.
The errors log file should have a more precise indication.
dsctl some-instance ldif2db userroot some-path/some-file.ldif
Thanks,
M.

On Thu, Dec 30, 2021 at 11:58 AM Joe Fletcher  wrote:

> Hi,
>
>
>
> Is there something hard-coded into 389 v1.4 such that it can only import
> data from /var/lib/dirsrv//ldif  ?
>
>
>
> I’ve been trying to initialize a new setup with an export we’d been using
> for 389 v1.3  but every time it failed with a “file not found” error until
> the ldif was copied to /var/lib/….etc.
>
>
>
> Cheers
>
>
>
>
> This email with all information contained herein or attached hereto may
> contain confidential and/or privileged information intended for the
> addressee(s) only. If you have received this email in error, please contact
> the sender and immediately delete this email in its entirety and any
> attachments thereto.
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] Re: Default browsing index generation

[Marc Sauton]

in the web UI, it should be under "Database | Suffixes | dc=xx | VLV
Indexes"

to create a VLV index "Database | Suffixes | dc=xx | VLV Indexes | Create
VLV Index"

to re-index an existing VLV index "Database | Suffixes | dc=xx | VLV
Indexes |  select an existing VLV index | Action=Reindex VLV Index"
-> popup window "Are you sure you want to reindex this VLV index?
carlicense
NO YES
->
Successfully completed VLV indexing

using the command line, for example with an instance-name called m1:

create some "dummy-non-sense-example" VLV index:
dsconf m1 backend vlv-index add-search --name=test1
--search-base=ou=people,dc=example,dc=test
--search-filter=carlicense=6ZBC246 --search-scope=2 dc=example,dc=test
dsconf m1 backend vlv-index add-index --sort roomNumber --parent-name test1
--index-name indextest1  userroot

dsconf m1 backend vlv-index list userroot
( nothing )

dsconf m1 backend vlv-index reindex --index-name carlicense-index
--parent-name carlicense userroot
Index task index_vlv_12292021_162709 completed successfully
Successfully reindexed VLV indexes
[root@m1 ~]#

dsconf m1 backend vlv-index list userroot
dn: cn=test1,cn=userroot,cn=ldbm database,cn=plugins,cn=config
cn: test1
vlvbase: ou=people,dc=example,dc=test
vlvscope: 2
vlvfilter: (carlicense=1ABC123)
Sorts:
 - dn: cn=indextest1 ,cn=test1,cn=userroot,cn=ldbm
database,cn=plugins,cn=config
 - cn: indextest1
 - vlvsort: roomNumber
 - vlvenabled: 1
 - vlvuses: 0
Error: info() missing 1 required positional argument: 'msg'
[root@m1 ~]#



On Wed, Dec 29, 2021 at 2:56 PM Joe Fletcher  wrote:

> Hi,
>
>
>
> We’re looking at 389 DS v1.4. Is there an equivalent in the linux 8
> cockpit to the feature that used to exist in the v 1.3 management console
> such that it can create default browsing indexes?
>
> In the old GUI it was simply a case of right-click and go which did offer
> a certain level of convenience. So far I have not found an equivalent in
> cockpit.
>
>
>
> Currently most of my potential LDAP clients are unable to browse the
> directory with the usual “Unwilling to perform: search is not indexed”.
>
>
>
> TIA
>
>
>
> Joe
> This email with all information contained herein or attached hereto may
> contain confidential and/or privileged information intended for the
> addressee(s) only. If you have received this email in error, please contact
> the sender and immediately delete this email in its entirety and any
> attachments thereto.
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] Re: db2ldif unfolded output?

[Marc Sauton]

There is no equivalent of the db2ldif.pl -U option in dsctl db2ldif
But an export task can be configured with nsNoWrap: true
I opened this issue to track your request:
https://github.com/389ds/389-ds-base/issues/5081
Thanks,
M.

On Thu, Dec 23, 2021 at 12:26 PM John Thurston 
wrote:

> With 389 Directory 1.4.4.17, "dsctl db2ldif . ." gives me an ldif with
> its long lines folded to 78 characters. The old db2ldif tool had the -U
> option which was "Do not wrap long lines".
>
> My question is:
>Is there a way to get "dsctl db2ldif" to produce unfolded output?
>
> I know I can unfold these ldif lines later. I'm just trying to minimize
> the number of scripts I must modify.
>
>
> --
> --
> Do things because you should, not just because you can.
>
> John Thurston907-465-8591
> john.thurs...@alaska.gov
> Department of Administration
> State of Alaska
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] Re: 389 1.3 vs 1.4, CentOS 7

[Marc Sauton]

389ds 1.3 is not a product so there is no EOL date, but the 1.3.x branches
become less active over time, and eventually with zero activity, more like
an archive.
The Red Hat Directory Server 10 / RHDS-10 product based on 389ds 1.3.x has
been EOL on RHEL-7, and the current active version is RHDS-11 on RHEL-8,
based on 389ds 1.4.x
M.

On Wed, Nov 10, 2021 at 7:50 AM Morgan Jones  wrote:

> Thanks Thierry.  Does 389 1.3 have an end of life date?
>
> We are a large school district and aren’t yet running Redhat 8 and may not
> for a bit—another team makes that call.
>
> -morgan
>
>
> > On Nov 10, 2021, at 4:45 AM, Thierry Bordaz  wrote:
> >
> > Hi Morgan,
> >
> > 389 1.3 and 1.4 are both advisable in production. You may hit some
> dependencies difficulties building 1.4 on centos7, as 1.3 was released on
> centos7 and 1.4 on centos8.
> >
> > I would suggest that you upgrade to centos8 as 1.4 contains more
> features and improvements but if you target centos7 then 1.3 is the version
> to go.
> >
> > my 2cts
> >
> > regards
> > thierry
> >
> > On 11/10/21 4:18 AM, Morgan Jones wrote:
> >> Hello!
> >>
> >> Is it advisable to run 389 1.3 in production?
> >>
> >> If not is there a suggested way to install 1.4 in CentOS 7?  On first
> blush to install 389 from source  it’s looking like I’m going to need to
> install libicu from source, the version that ships is an older version:
> >>
> >>> checking for ICU... no
> >>> configure: error: Package requirements (icu-i18n >= 60.2) were not met:
> >>>
> >>> Requested 'icu-i18n >= 60.2' but version of icu-i18n is 50.2
> >>
> >> thank you,
> >>
> >> -morgan
> >> ___
> >> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> >> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> >
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] Re: anonymous binds

[Marc Sauton]

depending on the filters used, an error 11 / err=11 / ADMIN_LIMIT_EXCEEDED
/ "Administrative limit exceeded" could be returned, and depending on the
LDAP client, it could be an important error.
it may be a good idea to set a DN for nsslapd-anonlimitsdn , see
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/configuration_command_and_file_reference/core_server_configuration_reference#nsslapd-anonlimitsdn
with its associated/dedicated values different from the global settings,
for the attributes nsIdleTimeout ,  nsTimeLimit and nsSizeLimit
or set a special user entry for those BINDs , with the same 3 user
specified idletimeout, time and size limits to avoid tuning up the general
setting of the size limit.
M.


On Tue, Oct 19, 2021 at 10:44 AM Michael Starling 
wrote:

> Good afternoon.
>
> I have a few questions about anon binds.
>
> In theory if you have 3000 user objects in the directory and anonymous
> binds have a limit returning 2000 entries can you still use anonymous binds
> in LDAP client configurations without issues? Or does something else take
> place when a user logs in that only requires the LDAP clients (sssd or
> nscld) to parse that specific user dn and attributes?
>
> Typically, with OpenLDAP I have created a "bind" user that can read all
> user/group objects with limited attributes and turned off anon binds so I
> don't fully understand the behavior of anonymous binds.
>
> Mike
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] Re: Can't locate CSN - replica issue

[Marc Sauton]

does srv2 run 1.4.3.22 ?

you could try to delete the BDB region files, first stop the LDAP service,
then delete the files
/var/lib/dirsrv/slapd-xx/db/"__db.00*

or try a more recent 1.4.4.15 or 1.4.4.16

Thanks,
M.

On Tue, Jun 1, 2021 at 5:30 AM Marco Favero  wrote:

> Hello,
>
>   I'm dealing with the update from 389-ds 1.3.9.1 to 1.4.3.22 in three
> multimaster servers:
>
> - srv1
> - srv2
> - srv3
>
> srv1 replicates to srv2 and srv3.
> srv2 replicates to srv1 and srv3.
> srv3 replicates to srv1 and srv2.
>
> Let suppose I reinstall srv3 with 389ds 1.4.3.22, and I initialize it from
> srv1. This happens with success as expected. The replica is fine.
>
> Then, I reinstall srv2, and I initialize it from srv3. This happens with
> success as expected, but just at the initialization end, the agreement from
> srv3 to srv1 stops to works.
>
> In the console appears "Error (18) Can't acquire replica (Incremental
> update transient warning. Backing off, will retry update later.)" in the
> status of the agreements from srv3 to srv1. In the logs I see errors like
>
> repl_plugin_name_cl - agmt="srv3 to srv1" (srv1:389): CSN
> 596c68687532 not found, we aren't as up to date, or we purged
> clcache_load_buffer - Can't locate CSN 596c68687532 in the
> changelog (DB rc=-30988). If replication stops, the consumer may need to be
> reinitialized.
>
> The changelogdb Maximun Age is "7d", equals to the default
> nsDS5ReplicaPurgeDelay for the suffix.
>
> This happens always, for every suffix.
>
> To resolve the issue I have to re-initialize from srv3 to srv1 again and
> after the end of initialization from srv3 to srv2.
>
> Resuming:
>
> 1) install srv2 OK
> 2) initialize srv1 to srv3 OK
> 3) initialize srv2 to srv3: the agreement srv1 to srv3 stops to work
> 4) initialize srv1 to srv3 again
>
> I would like to know how to configure the Directory Server in order to
> avoid the above scenario.
> The problem is very similar to
>
>   https://access.redhat.com/solutions/2690611
>
> but that document says that the problem was already fixed in
> 389-ds-base-1.3.5.10-15.el7_3 or later.
>
> Could you help me?
>
> Thank you very much
> Marco
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] Re: 389 console on Windows - command logging

[Marc Sauton]

There isn't a console log, but there is all the activity from the HTTP
server, in  /var/log/dirsrv/admin-serv/access
The other possibility is to run the console in debug mode.
Note the Java console has been deprecated for more than a year, for a web
UI and Python command line tools.
( RHDS-11.0 was released for RHEL-8.1 in 20191106 )
In that case, the web browser debug console shows the actions translated in
the commands.

for the error "could not be restarted", you may want to review the LDAP
server errors log in for example /var/log/dirsrv/slapd-*/errors , not the
console actions log.
try to restart manually from the LDAP server's system, to verify this work
properly.
also verify there is indeed a task created by the DS console, in the LDAP
server's access log file, there may be an error code different from 0.
or verify the user used to log in the DS console has access to the restart
functionality, try to log in as "cn=directory manager"

Cordially,
Marc S.

On Mon, May 17, 2021 at 2:05 PM Joe Fletcher  wrote:

> Hi,
>
>
>
> Does the native windows version of 389 management console keep logs of
> commands executed and their results anywhere?
>
> If not is there a way to make it do so?
>
>
>
> I am working on a project to migrate to 389 and I have an instance whereby
> if I select “restart directory server” from the tasks page I get a message
>
> pop-up saying “Directory Server  could not be restarted”
> but no explanation as to why.
>
>
>
> I have other instances where this functionality works fine.
>
>
>
> There doesn’t appear to be anything in the access or error logs at the
> server end to signify the failed attempt.
>
>
>
> Any way to trace the issue?
>
>
>
> Regards
>
>
> This email with all information contained herein or attached hereto may
> contain confidential and/or privileged information intended for the
> addressee(s) only. If you have received this email in error, please contact
> the sender and immediately delete this email in its entirety and any
> attachments thereto.
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] Re: plugin naming

[Marc Sauton]

and that should have:
https://github.com/389ds/389-ds-base/blob/master/src/lib389/lib389/cli_conf/plugins/retrochangelog.py
def create_parser(subparsers):
retrochangelog = subparsers.add_parser('retro-changelog', help='Manage
and configure Retro Changelog plugin')

Thanks,
Marc S.


On Tue, May 11, 2021 at 12:51 AM Angel Bosch Mora 
wrote:

> > it was likely the right time to have this change.
> > and not subject to change anytime soon.
> >
> > is it possible a 389-ds-base-1.4.0 from before March 2019 till
> > lurking
> > around?
> >
>
> I'm using debian packages:
>
> dpkg -l | grep 389-ds-base
> ii  389-ds-base   1.4.4.11-1
>  amd64389 Directory Server suite - server
> ii  389-ds-base-libs:amd641.4.4.11-1
>  amd64389 Directory Server suite - libraries
>
>
> they seem pretty new to me.
>
> abosch
> -- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau,
> qualsevol fitxer annex, es dirigeix exclusivament a la persona que n'es
> destinataria i pot contenir informacio confidencial. En cap cas no heu de
> copiar aquest missatge ni lliurar-lo a terceres persones sense permis
> expres de l'IMAS. Si no sou la persona destinataria que s'hi indica (o la
> responsable de lliurar-l'hi) us demanam que ho notifiqueu immediatament a
> l'adreca electronica de la persona remitent. Abans d'imprimir aquest
> missatge, pensau si es realment necessari.
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] Re: plugin naming

[Marc Sauton]

the first is a more general plugin command, using the CN value of the
plugin name, should be consistent between releases, but can be easily
customized in the dse.ldif config file when an instance is deployed.
the second is dedicated to the "specific" plugins, it is a more recent
Python code, the class is called retrochangelog, but the sub command is
called retro-changelog, this should also stay consistent.
just 2 different ways to do the same thing, with more control in the second
form for those special plugins.
if this is about enabling or disabling a plugin, may be the first form is
better,
for managing particular features of the special plugins like memberof,
automember, referential-integrity, and some others, use the second form, or
the cockpit web UI.

there were a few changes in March 2019 , some cosmetic, to have the
"dedicated/special" plugins sub commands more consistent and more readable
using the same format with a dash when they have composed words:
Issue 50041 - Add CLI functionality for special plugins
https://github.com/389ds/389-ds-base/commit/46e28cb4229f590c225f2a52bc8169e6fcc2d65b
like
cmdName="retrochangelog"
cmdName="retro-changelog"

this is an active project, and the Python CLI was subject to more
disruptive changes in 2019 than today when it was really new, with version
1.4.0, before the RHEL-8 introduction in May 2019, not as stable as now,
it was likely the right time to have this change.
and not subject to change anytime soon.

is it possible a 389-ds-base-1.4.0 from before March 2019 till lurking
around?

Cordially,
Marc S.


On Mon, May 10, 2021 at 6:02 AM Angel Bosch Mora 
wrote:

> hi,
>
> I vaguely remember discussing this some time ago but I can't find it now.
>
>
> what's the difference between
>
> dsconf myinstance plugin set --enabled on "Retro Changelog Plugin"
>
> and
>
> dsconf myinstance plugin retro-changelog enable
>
> ?
>
>
> any of them is gonna be deprecated?
>
> I also noticed that short name is different between versions/distributions
> (retro-changelog vs retrochangelog), so I prefer to use "Retro Changelog
> Plugin" if possible for scripting purpouses.
> is that the right way to do it?
>
> best regards,
>
> abosch
>
>
> -- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau,
> qualsevol fitxer annex, es dirigeix exclusivament a la persona que n'es
> destinataria i pot contenir informacio confidencial. En cap cas no heu de
> copiar aquest missatge ni lliurar-lo a terceres persones sense permis
> expres de l'IMAS. Si no sou la persona destinataria que s'hi indica (o la
> responsable de lliurar-l'hi) us demanam que ho notifiqueu immediatament a
> l'adreca electronica de la persona remitent. Abans d'imprimir aquest
> missatge, pensau si es realment necessari.
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] Re: minssf and TLS cipher ordering

[Marc Sauton]

about ciphers order and TLS cipher suite discovery, NSS will pick the one
with highest strength from the available ciphers, and compatible with the
TLS client ( handshake)

you can check the configuration with for example (replace the string m1
with an instance name):
dsconf m1 security get
dsconf m1 security ciphers list
dsconf m1 security ciphers list --supported | less
dsconf m1 security ciphers list --enabled
ldapsearch -o ldif-wrap=no -LLLxD "cn=Directory Manager" -W  -b
cn=encryption,cn=config | less

and to set ciphers (can be "delicate"):
/usr/lib64/nss/unsupported-tools/listsuites | grep -B1 --no-group-separator
"Enabled" | less
dsconf m1 security ciphers set x

doc ref:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/enabling_tls#setting_encryption_ciphers

and NSS source:
./lib/ssl/ssl3con.c
./lib/ssl/sslenum.c


On Fri, Apr 23, 2021 at 4:57 PM Trevor Vaughan 
wrote:

> William,
>
> I do apologize! I'll keep that in mind in the future.
>
> Thanks again for your help,
>
> Trevor
>
> On Fri, Apr 23, 2021, 7:50 PM William Brown  wrote:
>
>> Sorry to call this out, but my name is "William" not "Bill". I have
>> personal reasons to dislike being called that name.
>>
>> Regardless, happy to help out :)
>>
>> > On 23 Apr 2021, at 22:11, Trevor Vaughan 
>> wrote:
>> >
>> > Bill and Pierre,
>> >
>> > Thanks for the responses!
>> >
>> > It sounds like I have to figure out how to configure the NSS library
>> for 389-DS specifically.
>> >
>> > In EL8+ I know that I can configure the global crypto policy but I'm
>> hoping that I can do it for the specific application. I haven't found
>> anything in the documentation so far but at least this gets me pointed in
>> the right direction.
>> >
>> > Thanks,
>> >
>> > Trevor
>> >
>> > On Fri, Apr 23, 2021 at 4:42 AM Pierre Rogier 
>> wrote:
>> > Hi Trevor,
>> >
>> > I do not think it is possible to specify the cypher order negotiation:
>> >  I am not sure whether TLS protocol allow to specify an order when
>> negotiating the cypher,
>> >  but at 389 level there is no way to specify an order:
>> > The NSS security layer provides the list of supported cypher and 389
>> use
>> > nsSSL3Ciphers config parameter to enable/disable theses cyphers in the
>> list (without changing the order)
>> >
>> > So my feeling is that if there is an order it is up to the
>> different
>> >  security layer implementations and may differs between the
>> applications,
>> >
>> > Regards,
>> >Pierre
>> >
>> > On Thu, Apr 22, 2021 at 7:28 PM Trevor Vaughan 
>> wrote:
>> > Hi William,
>> >
>> > In terms of the STARTTLS bits (in theory) properly configuring your
>> client software mitigates the password leak risk. But this also happens
>> with pure (non-RFC) LDAPS connections.
>> >
>> > The docs note that minssf applies to the crypto required bits as well
>> as the SASL layer.
>> >
>> > Ignoring most of that, my issue is that I don't understand why I have
>> to nail my client software to ciphers explicitly known by 389-DS instead of
>> the two negotiating the strongest things possible out of the gate.
>> >
>> > For instance, if I use AES256 with a minssf=256, everything works just
>> fine.
>> >
>> > But, if I use AES128:AES256:@STRENGTH (which should sort strongest to
>> weakest) then access is denied.
>> >
>> > How do I get 389-DS to negotiate the strongest ciphers first
>> (regardless of the method)?
>> >
>> > Thanks,
>> >
>> > Trevor
>> >
>> > On Wed, Apr 21, 2021 at 7:34 PM William Brown  wrote:
>> > Hi there,
>> >
>> > > On 22 Apr 2021, at 03:52, Trevor Vaughan 
>> wrote:
>> > >
>> > > Hi All,
>> > >
>> > > OS Version: CentOS 8
>> > > 389-DS Version: 1.4.3.22 from EPEL
>> > >
>> > > I have a server set up with minssf=256 and have been surprised that
>> either 389-DS, or openssl, does not appear to be doing what I would
>> consider a logical TLS negotiation.
>> > >
>> > > I had thought that the system would start with the strongest cipher
>> and then negotiate down to something that was acceptable.
>> > >
>> > > Instead, I'm finding that I have to nail up the ciphers to something
>> that the 389-DS server both recognizes and is within the expected SSF.
>> > >
>> > > Is this expected behavior or do I have something configured
>> incorrectly?
>> >
>> > That's not what minssf does.
>> >
>> > minssf says "during a bind operation, reject if the encryption strength
>> used is less than 256 bits or equivalent".
>> >
>> > The "bit strength" is arbitrary though, because it's a concept from
>> sasl, and generally is very broken.
>> >
>> > Remember, minssf does NOT do what you think though! Because bind is the
>> *first* message on the wire, the series of operations is
>> >
>> >
>> >client   server
>> > open plain text conn  ->
>> >   <-   accept connection
>> > send bind on conn ->
>> >   <-   reject due to minsff too weak.
>> >
>> >
>> > So you have already 

[389-users] Re: dsconf duplicate replica id

[Marc Sauton]

you can either run a "dsconf replication get-ruv" like tis example:
dsconf -j ldapi://%2fvar%2frun%2fslapd-m1.socket replication get-ruv
--suffix=dc=example,dc=test

or an ldapsearch to get the RUV records, similar to this example:
ldapsearch -o ldif-wrap=no -LLLH ldaps://m1.example.test:636 -D
"cn=directory manager" -W -b dc=example,dc=test
"(&(nsUniqueId=---)(objectClass=nstombstone))"
nsds50ruv

or review the dse.ldif configuration file, and search for a replication
agreement definition ( objectClass: nsds5replicationagreement ), and locate
the attributes nsds50ruv, DN example:
dn: cn=m1tom2exampleSSL,cn=replica,cn=dc\3Dexample\2Cdc\3Dtest,cn=mapping
tree,cn=config

Cordially,
Marc S.

On Mon, Apr 12, 2021 at 11:49 AM Gary Waters 
wrote:

> Hey Everyone,
>
> I love the new dsconf python tool. Its great, and big upgrade over the
> perl scripts that I think I have been using for decades.
> However I am having a problem using it when making new replication
> agreements between multiple masters.
>
> How do I find the duplicates and how do i run dsconf to avoid that
> duplicate?
>
> Error after agreements are made:
> Error (11) Replication error acquiring replica: Unable to acquire
> replica: the replica has the same Replica ID as this one. Replication is
> aborting. (duplicate replica ID detected)
> Error (11) Replication error acquiring replica: duplicate replica ID
> detected
>
> I know how to delete the newly made agreements no problem, but how do I
> recreate them to avoid the duplicates? when creating the agreements I
> didnt see a way to set an id.
> command for the individual agreement.. maybe I am doing something wrong.
>
> This is how I setup the agreement:
>  dsconf -D "cn=Directory Manager" -w $pass ldap://$supplier-
> repl-agmt \
>   create --suffix="ou=$suffix,o=school,c=us" --host=$consumer
> --port=389 \
>   --conn-protocol=StartTLS --bind-dn="cn=replication
> manager,cn=config" \
>   --bind-passwd="x" --bind-method=SIMPLE --init \
>   $agreement_name
>
> And this is how I setup the id and replication for the for the suffix:
>
> dsconf -D "cn=Directory Manager" -w $pass ldap://$consumer replication \
>   enable --suffix="ou=$suffix,o=school,c=us" --role="master"
> --replica-id=$repid \
>   --bind-dn="cn=replication manager,cn=config" --bind-passwd=XXX
>
>
> In my case I have 3 masters that I need to setup MMR between, and this
> error happens when I added the third. It says replication is already set
> for the suffix as mmr, which is correct, but I cant set a new repid for
> each aggreement via the first command.
>
>
> Thank you everyone,
> Gary
>
> Other info:
> rhel8.3
> 389-ds-base-libs-1.4.3.17-1.module_el8+10764+2b5f8656.x86_64
> 389-ds-base-1.4.3.17-1.module_el8+10764+2b5f8656.x86_64
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] Re: Newbie question: What does NS stand for?

[Marc Sauton]

and nsds50 stands for Netscape Directory Server 5.0 as it became
iPlanet Directory Server 5.0  in the 2001 time frame with major new
features, like: MMR / Multi Master Replication !
hence the famous nsds50ruv records and other replication agreement
attributes with the nsds50 prefix string.
probably having the version number was somehow important at that time.
https://web.archive.org/web/20010924091521/http://docs.iplanet.com/docs/manuals/directory/50/relnotes.html
another blast from the past:
https://web.archive.org/web/19980507023609/http://help.netscape.com/products/
the page at https://www.port389.org/docs/389ds/FAQ/history.html has some
information.
M.

On Tue, Jan 19, 2021 at 2:53 PM William Brown  wrote:

>
>
> > On 20 Jan 2021, at 08:42, Tom  wrote:
> >
> > A lot of config options, for example nsslapd-sizelimit, start with NS.
> What does NS stand for?
>
> NetScape! A lot of the directory server code originally was part of
> netscape and then had some adventures going through SUN, AOL and finally
> Red Hat and OpenSource.
>
> This is contrast to NS in macos (nextstep) and nsswitch (name-service
> switch) or ns (nanoseconds) or any of the other overloaded meanings that NS
> has in our world.
>
> >
> > Thanks in advance for tolerating a newbie with OCD!
>
> Absolutely - Happy to have you here, and if you have any more questions
> about 389-ds or related topics, please let us know!
>
> > ___
> > 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs, Australia
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: GSSAPI authentication w/ and w/o rDNS resolution

[Marc Sauton]

Try configuring nsslapd-localhost to the "alias" , with nsslapd-listenhost
and nsslapd-securelistenhost to the hostname of the system.
Thanks,
M.

On Tue, Jan 12, 2021 at 5:52 AM Julien Rische  wrote:

> Hello Wiliam,
>
> Thank you for you response, and sorry for my late one.
> Here are more logs regarding this issue:
>
> Kerberos client debugging:
> ```
> $ KRB5_TRACE=/dev/stderr ldapwhoami -QY GSSAPI -H ldap://ldap.example.net
> [743517] 1610373687.808962: ccselect module realm chose cache
> FILE:/tmp/krb5cc_0_jia7kOLl7r with client principal m...@example.net for
> server principal ldap/ldap.example@example.net
> [743517] 1610373687.808963: Getting credentials m...@example.net -> ldap/
> ldap.example@example.net using ccache FILE:/tmp/krb5cc_0_jia7kOLl7r
> [743517] 1610373687.808964: Retrieving m...@example.net -> ldap/
> ldap.example@example.net from FILE:/tmp/krb5cc_0_jia7kOLl7r with
> result: -1765328243/Matching credential not found (filename:
> /tmp/krb5cc_0_jia7kOLl7r)
> [743517] 1610373687.808965: Retrieving m...@example.net -> krbtgt/
> example@example.net from FILE:/tmp/krb5cc_0_jia7kOLl7r with result:
> 0/Success
> [743517] 1610373687.808966: Starting with TGT for client realm:
> m...@example.net -> krbtgt/example@example.net
> [743517] 1610373687.808967: Requesting tickets for ldap/
> ldap.example@example.net, referrals on
> [743517] 1610373687.808968: Generated subkey for TGS request:
> aes256-cts/2501
> [743517] 1610373687.808969: etypes requested in TGS request: aes256-cts,
> aes256-sha2, camellia256-cts, aes128-cts, aes128-sha2, camellia128-cts
> [743517] 1610373687.808971: Encoding request body and padata into FAST
> request
> [743517] 1610373687.808972: Sending request (1565 bytes) to EXAMPLE.NET
> [743517] 1610373687.808973: Resolving hostname krb5.example.net
> [743517] 1610373687.808974: Initiating TCP connection to stream
> :::::88
> [743517] 1610373687.808975: Sending TCP request to stream
> :::::88
> [743517] 1610373687.808976: Received answer (1524 bytes) from stream
> :::::88
> [743517] 1610373687.808977: Terminating TCP connection to stream
> :::::88
> [743517] 1610373687.808978: Response was not from master KDC
> [743517] 1610373687.808979: Decoding FAST response
> [743517] 1610373687.808980: FAST reply key: aes256-cts/47B8
> [743517] 1610373687.808981: TGS reply is for m...@example.net -> ldap/
> ldap.example@example.net with session key aes256-cts/1C40
> [743517] 1610373687.808982: TGS request result: 0/Success
> [743517] 1610373687.808983: Received creds for desired service ldap/
> ldap.example@example.net
> [743517] 1610373687.808984: Storing m...@example.net -> ldap/
> ldap.example@example.net in FILE:/tmp/krb5cc_0_jia7kOLl7r
> [743517] 1610373687.808986: Creating authenticator for m...@example.net ->
> ldap/ldap.example@example.net, seqnum 365654266, subkey
> aes256-cts/D659, session key aes256-cts/1C40
> ldap_sasl_interactive_bind_s: Invalid credentials (49)
> ```
>
> I really don't think the problem comes from the client side, as the
> provided ticket (me(a)EXAMPLE.NET to ldap/ldap.example.net(a)EXAMPLE.NET)
> is the expected one for a rDNS-disabled client.
>
> On the server side, I enabled the Kerberos trace and the following debug
> levels according to RHDS' documentation[1]:
> - Connection management (8)
> - Default (16384)
> - Plug-ins (65536)
>
> ```
> $ journalctl -o cat -fu dirsrv@EXAMPLE-NET
> [11/Jan/2021:15:01:27.803102542 +0100] - DEBUG - connection_reset - new
> connection on 109
> [11/Jan/2021:15:01:27.870901407 +0100] - DEBUG -
> connection_table_dump_activity_to_errors_log - activity on 109r
> [11/Jan/2021:15:01:27.872064228 +0100] - DEBUG - handle_pr_read_ready -
> read activity on 109
> [11/Jan/2021:15:01:27.876039477 +0100] - DEBUG - connection_read_operation
> - connection 60 read 512 bytes
> [11/Jan/2021:15:01:27.879751786 +0100] - DEBUG - connection_read_operation
> - connection 60 read 512 bytes
> [11/Jan/2021:15:01:27.883218161 +0100] - DEBUG - connection_read_operation
> - connection 60 read 221 bytes
> [11/Jan/2021:15:01:27.884108822 +0100] - DEBUG - connection_threadmain -
> conn 60 read operation successfully - thread_turbo_flag 0 more_data 0
> ops_initiated 1 refcnt 2 flags 0
> [11/Jan/2021:15:01:27.887552392 +0100] - DEBUG -
> connection_check_activity_level - conn 60 activity level = 0
> [11/Jan/2021:15:01:27.890966858 +0100] - DEBUG -
> connection_make_readable_nolock - making readable conn 60 fd=109
> GSSAPI server step 1
> [11/Jan/2021:15:01:27.915025014 +0100] - DEBUG - ipa-lockout-plugin -
> postop returning 0: success
> [11/Jan/2021:15:01:27.919556667 +0100] - DEBUG - connection_threadmain -
> conn 60 check more_data 0 thread_turbo_flag 0repl_conn_bef 0, repl_conn_now
> 0
> [11/Jan/2021:15:01:27.922600271 +0100] - DEBUG - clear_signal - Listener
> got signaled
> [11/Jan/2021:15:01:27.925681010 +0100] - DEBUG -
> 

[389-users] Re: Clarification - is this certmap.conf file correct?

[Marc Sauton]

and add a
default:DNCompscn
to match the DN components
?

On Tue, Nov 17, 2020 at 5:35 PM William Brown  wrote:

>
> >
> > Something missing from the documentation is the DN format expected by
> the nsCertSubjectDN attribute.
> >
> > Is the format CN=X,serialNumber=Y as reported by openssl x509, or is it
> serialNumber=Y,CN=X as reported by the log message above?
>
> I seem to recall a few years back, some changes to CmapLdapAttr related to
> normalisation of these DN's so that regardless of how they are stored in
> the cert, they normalise to a stable format for search to be able to use.
>
> So I think it may be the format in the log message above.
>
> You could see what's happening internally by changing
> nsslapd-accesslog-level from 256 to 260 (256 + 4) to log internal searches,
> which will show you what it's doing internally for the lookup.
>
> Hope that helps,
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs, Australia
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: CPU Scalability / Scaling

[Marc Sauton]

On Fri, Aug 14, 2020 at 1:31 PM Ben Spencer  wrote:

>
>
> On Fri, Aug 14, 2020, 10:53 AM David Boreham 
> wrote:
>
>>
>> On 8/14/2020 9:04 AM, Ben Spencer wrote:
>> > After a little investigation I didn't find any recent information on
>> > how well / linearly 389 scales from a CPU perspective. I also realize
>> > this is a more complicated topic with many factors which actually play
>> > into it.
>> >
>> > Throwing the basic question out there: Does 389 scale fairly
>> > linearly as the number of CPUs are increased? Is there a point where
>> > it drops off?
>>
>> Cached reads (cached anywhere : filesystem cache, db page pool, entry
>> cache) should scale quite well, at least to 4/6/8 CPU. I'm not sure
>> about today's 8+ CPU systems but would assume probably not great scaling
>> beyond 8 until proven otherwise.
>>
>
> Interesting since we are currently sitting with 10 CPU per server. Things
> organically grew over time without much thought given.
>

Having more CPUs may displace problems, to for example, more threads
contention and newer performance problems.

Related to CPU and configurations, the "autotuning"
for nsslapd-threadnumber is recommended.
http://www.port389.org/docs/389ds/design/autotuning.html
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/performance_tuning_guide/ds-threads
( "excessive" manual thread setting will have a counter effect )

There is another aspect, on the LDAP client side:
High CPU use is often the result of "poorly" designed applications that are
hammering an LDAP server with a constant flow of complex search filters
with pattern matching.
And very often all the long server side CPU processing is useless.
Analysing the LDAP server access log can help tune, change the filters
those applications are sending, and can have a high impact on the server
side.
So often, only the global settings are kept, and there is a server side
configuration that is overlooked, that can really help optimize the CPU and
I/O: the "fine grained" ID list scan limit.
http://www.port389.org/docs/389ds/design/fine-grained-id-list-size.html
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/configuration_command_and_file_reference/database_plug_in_attributes#nsIndexIDListScanLimit
And reduce or optimize index use on the system resources.

so there should be some investigation before adding more system resources,
logs, pstacks, or some gdb stack traces, index configurations.

Writes are going to be heavily serialized, assume no CPU scaling. Fast
>> I/O is what you need for write throughput.
>
> > Where am I going with this?
>> > We are faced with either adding more CPUs to the existing servers or
>> > adding more instances or a combination of the two. The current servers
>> > have 10 CPU with the entire database fitting in RAM but, there is a
>> > regular flow of writes. Sometimes somewhat heavy thanks to batch
>> > updates. Gut feeling tells me to have more servers than a few huge
>> > servers largely because of the writes/updates and lock contention.
>> > Needing to balance the server sprawl as well.
>>
>> I'd look at whether I/O throughput (Write IOPS particularly) can be
>> upgraded as a first step. Then perhaps look at system design to see if
>> the batch updates can be throttled/trickled to reduce the cross-traffic
>> interference. Usually the write load is the limiting factor scaling
>> because it has to be replayed on every server regardless of its read
>> workload.
>>
>
> Something to consider. Hard to resolve in the environment where the
> servers are.
>
large bulk updates always degrade LDAP servers performance.
Adding more replicas will create more contention for replication sessions.
LDAP replication can be tuned to accommodate replication sessions
competition, but there isn't a dynamic tuning to adapt to traffic pattern
changes, large bursts of modifications, so throttling scheduled updates
seems a good and easier approach.

>
> ___
>> 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:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>>
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To 

[389-users] Re: dbchangelog Question

[Marc Sauton]

A stop/start is required, there are detailed instructions in the online
admin guide at
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/moving_the_changelog_directory
15.16. MOVING THE REPLICATION CHANGELOG DIRECTORY
Thanks,
M.

On Wed, Jul 8, 2020 at 9:22 AM Ghiurea, Isabella <
isabella.ghiu...@nrc-cnrc.gc.ca> wrote:

> Morning Gurus
>
> I am running multimaster replication with
> 389-ds-base-1.3.7.5-24.el7_5.x86_64, I will like to know if I can update
>  dbchange log path while DS is online accepting transactions without
>
>  any implication for replication?
>
> Thank you
>
> Isabella
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: 389-DS Failed to get the default state of cipher

[Marc Sauton]

I will let others confirm, but the message "_conf_setallciphers - Failed to
get the default state of cipher" may not be an actual error, but more a
warning that could be ignored, as the the default ciphers are
configured later, per the log entries provided.
Could you add the nss package version, as well as the details from the entry
rpm -q nss nspr
ldapsearch -LLLxD 'cn=directory manager' -W -b cn=encryption,cn=config -s
base sslVersionMin sslVersionMax allowWeakCipher
nsSSL3Ciphers nsSSLSupportedCiphers nsSSLEnabledCiphers
?
Thanks,
M.

On Wed, Jun 24, 2020 at 9:57 AM Ghiurea, Isabella <
isabella.ghiu...@nrc-cnrc.gc.ca> wrote:

> Our  new DS env is  running:
>
> 389-ds-base-libs-1.3.9.1-10.el7.x86_64
>
> 389-ds-base-1.3.9.1-10.el7.x86_64
>
> After DS was upgrade to above version seeing this error when restarting
> the DS, we have another host with same version and suppose same cfg but
> never saw the error, please advise a fix for this issue in this version:
>
> Thank you
>
> ERR - Security Initialization - _conf_setallciphers - Failed to get the
> default state of cipher (null)
>
> [24/Jun/2020:09:22:54.686777541 -0700] - ERR - Security Initialization -
> _conf_setallciphers - Failed to get the default state of cipher (null)
>
> [24/Jun/2020:09:22:54.687024072 -0700] - ERR - Security Initialization -
> _conf_setallciphers - Failed to get the default state of cipher (null)
>
> [
>
> [24/Jun/2020:09:22:54.688953359 -0700] - INFO - Security Initialization -
> SSL info: Enabling default cipher set.
>
> [24/Jun/2020:09:22:54.689229153 -0700] - INFO - Security Initialization -
> SSL info: Configured NSS Ciphers
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: DNA plugin not working

[Marc Sauton]

verify there is an equality index for uidnumber and gidnumber, not just
presence, in the entries
dn: cn=gidnumber,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
dn: cn=uidnumber,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
which version of 389-ds-base is this about?
Thanks,
M.

On Mon, Apr 13, 2020 at 11:42 AM CHAMBERLAIN James <
james.chamberl...@3ds.com> wrote:

> Hi Mark,
>
> Thanks for getting back to me.  After adjusting nsslapd-errorlog-level,
> here’s what I’ve got.
>
> # grep dna-plugin /var/log/dirsrv/slapd-example/errors
> [13/Apr/2020:14:30:00.480608036 -0400] - DEBUG - dna-plugin -
> _dna_pre_op_add - dn does not match filter
> [13/Apr/2020:14:30:00.486700059 -0400] - DEBUG - dna-plugin -
> _dna_pre_op_add - adding uidNumber to
> uid=testuser1,ou=People,dc=example,dc=com as -2
> [13/Apr/2020:14:30:00.559245389 -0400] - DEBUG - dna-plugin -
> _dna_pre_op_add - retrieved value 0 ret 1
> [13/Apr/2020:14:30:00.561303217 -0400] - ERR - dna-plugin -
> _dna_pre_op_add - Failed to allocate a new ID!! 2
> [13/Apr/2020:14:30:00.571360868 -0400] - DEBUG - dna-plugin - dna_pre_op -
> Operation failure [1]
>
> And here’s the DNA config:
>
> dn: cn=UID numbers,cn=Distributed Numeric Assignment
> Plugin,cn=plugins,cn=config
> objectClass: top
> objectClass: extensibleObject
> cn: UID numbers
> dnaType: uidNumber
> dnamaxvalue: 10
> dnamagicregen: 0
> dnafilter: (objectclass=posixAccount)
> dnascope: dc=example,dc=com
> dnanextvalue: 25000
>
> dn: cn=GID numbers,cn=Distributed Numeric Assignment
> Plugin,cn=plugins,cn=config
> objectClass: top
> objectClass: extensibleObject
> cn: GID numbers
> dnaType: gidNumber
> dnamaxvalue: 10
> dnamagicregen: 0
> dnafilter: (objectclass=posixGroup)
> dnascope: dc=example,dc=com
> dnanextvalue: 25000
>
> Best regards,
>
> James
>
>
> > On Apr 13, 2020, at 2:25 PM, Mark Reynolds  wrote:
> >
> > Enabling plugin logging will provide a little more detail about what is
> going wrong:
> >
> > ldapmodify -D "cn=directory manager" -W
> > dn: cn=config
> > changetype: modify
> > replace: nsslapd-errorlog-level
> > nsslapd-errorlog-level: 65536
> >
> >
> > After running the test you can disable the debug plugin logging by
> setting the log level to zero.
> >
> > Then share what information is logging when you add a new user.   This
> is most likely a configuration error so hopefully we can find out what went
> wrong in your set up.  Can you also provide the DNA config entries?
> >
> > Thanks,
> >
> > Mark
> >
> > On 4/13/20 1:50 PM, CHAMBERLAIN James wrote:
> >> Hi all,
> >>
> >> I’m trying to use the DNA plugin to add uidNumbers on posixAccounts.
> Everything worked fine in testing, but now that it’s in production I’m
> seeing the following error:
> >>
> >> ERR - dna-plugin -_dna_pre_op_add - Failed to allocate a new ID!! 2
> >>
> >> I’ve followed the advice in the knowledge base (
> https://access.redhat.com/solutions/875133), about adding an equality
> index with an nsMatchingRule of integerOrderingMatch, but have not seen any
> difference in the server’s behavior.  Any ideas what I should try next?
> >>
> >> Thanks,
> >>
> >> James
> >> This email and any attachments are intended solely for the use of the
> individual or entity to whom it is addressed and may be confidential and/or
> privileged.
> >> If you are not one of the named recipients or have received this email
> in error,
> >> (i) you should not read, disclose, or copy it,
> >> (ii) please notify sender of your receipt by reply email and delete
> this email and all attachments,
> >> (iii) Dassault Systèmes does not accept or assume any liability or
> responsibility for any use of or reliance on this email.
> >>
> >> Please be informed that your personal data are processed according to
> our data privacy policy as described on our website. Should you have any
> questions related to personal data protection, please contact 3DS Data
> Protection Officer at 3ds.compliance-priv...@3ds.com
> >>
> >> For other languages, go to https://www.3ds.com/terms/email-disclaimer
> >>
> >>
> >> ___
> >> 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:
> >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >>
> >> List Guidelines:
> >> https://fedoraproject.org/wiki/Mailing_list_guidelines
> >>
> >> List Archives:
> >>
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> > --
> >
> > 389 Directory Server Development Team
> >
>
> This email and any attachments are intended solely for the use of the
> individual or entity to whom it is addressed and may be confidential and/or
> privileged.
>
> If you are not one of the named recipients or have received this email in
> error,
>
> (i) you should not read, disclose, or copy it,
>
> (ii) please notify sender of your receipt by reply 

[389-users] Re: Replication manager with expired password

[Marc Sauton]

The internal suffix cn=config is not really designed to have a global
password policy applied to it.
A replication manager usually does not have a password policy.
If it is required to have some special DNs with a password policy, they
should be in a different suffix.
Thanks,
M.

On Thu, Feb 27, 2020 at 6:11 PM William Brown  wrote:

>
>
> > On 27 Feb 2020, at 00:04, Eugen Lamers 
> wrote:
> >
> > Hi,
> > we have set up a multi master replication (two peers, SIMPLE
> authentication) and added a global password policy to cn=config. We
> included the passwordMustChange attribute to cn=config, which led to the
> fact that the server process could not authenticate to the replication
> manager of the peer host. We solved it by removing the generated attribute
> passwordExpirationTime.
> > How is it usually handled to include something like passwordExp in the
> global policy at cn=config without preventing something like replication
> from working:
> > 1. Apply a user based policy (w/o passwordExp) to the user-like object
> "replication manager", or
> > 2. Place the user-like objects like "replication manager" to the DIT
> (not cn=config) and apply a subtree based policy (w/o passwordExp) to the
> subtree containing the object, or
> > 3. avoid setting pwdExp and pwdMustChange to a global policy at
> cn=config, or
> > 4. something else?
>
> I've not seen or encountered this kind of issue before, so I'm not sure
> what is the correct course of action here. I think generally in my
> experience we see password policies only applied to subtrees or databases
> rather than globally.
>
> It also depends where your replication manager is - generally we see them
> as "cn=replication manager,cn=config" rather than being "in the database".
> Can you confirm the FQDN of your replication manager that was affected
> here?
>
>
>
> > Thanx,
> > Eugen
> > ___
> > 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: Connections Opened but No BIND Received

[Marc Sauton]

the build string
389-Directory/1.3.9.1 B2019.164.1418
corresponds to a RHEL-7.7 with RHDS-10.4
to verify:
cat /etc/redhat-release; rpm -q redhat-ds 389-ds-base

the access and errors log snippets are showing a "normal" timeout after
10mn, when there is no activity, and they do not really provide more
information.

for the system entropy, check with
cat /proc/sys/kernel/random/entropy_avail
systemctl status rngd

if for example, the system entropy is less than 1K, crypto operations may
be extremely slow, and rngd should be running, like for example:
mkdir -p /etc/systemd/system/rngd.service.d
cat > /etc/systemd/system/rngd.service.d/entropy-source.conf << EOF
[Service]
ExecStart=/sbin/rngd -f -r /dev/urandom -o /dev/random
EOF
systemctl daemon-reload
systemctl enable rngd
systemctl start rngd
systemctl status rngd
cat /proc/sys/kernel/random/entropy_avail

If the ns-slapd stops responding, try to set the attribute
nsslapd-ioblocktimeout under cn=config to a smaller value, like for
example, 15 seconds / 15000
ldapmodify -D "cn=directory manager" -W
dn: cn=config
changetype: modify
replace: nsslapd-ioblocktimeout
nsslapd-ioblocktimeout: 15000



Thanks,
M.

On Thu, Jan 2, 2020 at 11:28 AM Trevor Fong  wrote:

> Hi Steve,
>
> We see it happening with replication connections from other 389 DS servers
> in the cluster (but because it is multi-master, other replications masters'
> succeed, so its OK).
> However, we also see it with other clients - they will initiate a
> connection, but the connection will hang and the client will time it out.
>
> Thanks,
> Trev
>
> On Thu, 2 Jan 2020 at 09:43, Vandenburgh, Steve Y <
> steve.vandenbu...@centurylink.com> wrote:
>
>> Is it possible that that application is pro-actively creating LDAP
>> connections that it does not use?  This scenario might happen if the
>> application is using connection pooling.
>>
>>
>> -Original Message-
>> From: Trevor Fong 
>> Sent: Thursday, January 2, 2020 10:16 AM
>> To: 389-users@lists.fedoraproject.org
>> Subject: [389-users] Re: Connections Opened but No BIND Received
>>
>> Happy New Year, everyone!
>>
>> Further to this, I added connection management loglevel to the errorlog
>> level and managed to capture the output during one of the events when the
>> connection seems to stall.  Would anyone be able to help me make sense of
>> it?
>>
>> Thanks a lot,
>> Trevor Fong
>>
>> Access log:
>> [02/Jan/2020:08:21:00.925703124 -0800] conn=258144 fd=263 slot=263 SSL
>> connection from  to 
>> [02/Jan/2020:08:21:00.934435506 -0800] conn=258144 TLS1.2 256-bit AES-GCM
>> < expecting other transactions with conn=258144 but nothing happens until
>> the following, when the connection is eventually timed out (600 sec) and
>> broken by the client>
>> [02/Jan/2020:08:31:01.024762657 -0800] conn=258144 op=-1 fd=263 closed -
>> Encountered end of file.
>>
>> Error log:
>> [02/Jan/2020:08:21:00.924588379 -0800] - DEBUG - connection_reset - new
>> SSL connection on 263
>> [02/Jan/2020:08:21:00.927088611 -0800] - DEBUG -
>> connection_table_dump_activity_to_errors_log - activity on 263r
>> [02/Jan/2020:08:21:00.927961983 -0800] - DEBUG - handle_pr_read_ready -
>> read activity on 263
>> [02/Jan/2020:08:21:00.932285653 -0800] - DEBUG -
>> connection_read_operation - connection 258144 waited 1 times for read to be
>> ready
>> [02/Jan/2020:08:21:00.934724384 -0800] - DEBUG -
>> connection_read_operation - connection 258144 waited 2 times for read to be
>> ready
>> [02/Jan/2020:08:21:01.035814543 -0800] - DEBUG - connection_threadmain -
>> conn 258144 read not ready due to 4 - thread_turbo_flag 0 more_data 0
>> ops_initiated 1 refcnt 2 flags 17
>> [02/Jan/2020:08:21:01.036940723 -0800] - DEBUG -
>> connection_check_activity_level - conn 258144 activity level = 0
>> [02/Jan/2020:08:21:01.037824240 -0800] - DEBUG - connection_threadmain -
>> conn 258144 leaving turbo mode due to 4
>> [02/Jan/2020:08:21:01.038667951 -0800] - DEBUG - connection_threadmain -
>> conn 258144 check more_data 0 thread_turbo_flag 0repl_conn_bef 0,
>> repl_conn_now 0
>> [02/Jan/2020:08:21:01.039407337 -0800] - DEBUG -
>> connection_make_readable_nolock - making readable conn 258144 fd=263 …
>> [02/Jan/2020:08:31:01.018473459 -0800] - DEBUG -
>> connection_table_dump_activity_to_errors_log - activity on 263r
>> [02/Jan/2020:08:31:01.020162681 -0800] - DEBUG - handle_pr_read_ready -
>> read activity on 263
>> [02/Jan/2020:08:31:01.021136264 -0800] - DEBUG -
>> connection_read_operation - PR_Recv for connection 258144 returns -5938
>> (Encountered end of file.)
>> [02/Jan/2020:08:31:01.022435629 -0800] - DEBUG -
>> disconnect_server_nomutex_ext - Setting conn 258144 fd=263 to be
>> disconnected: reason -5938
>> [02/Jan/2020:08:31:01.024785254 -0800] - DEBUG - connection_threadmain -
>> conn 258144 read not ready due to 3 - thread_turbo_flag 0 more_data 0
>> ops_initiated 2 refcnt 2 flags 19
>> [02/Jan/2020:08:31:01.026135420 -0800] - DEBUG -
>> connection_check_activity_level - conn 

[389-users] Re: Connections Opened but No BIND Received

[Marc Sauton]

are the LDAP clients always the same?
or is it more like an LDAP server does not accept TLS or SSL connections at
all?
could it be a temporary situation while some large searches are processed?
are there load balancers in between?
check for LDAP server descriptors and system entropy.
check for nsslapd-enable-nunc-stans: off
ldapsearch -D "cn=directory manager" -W -b cn=config -s base
nsslapd-enable-nunc-stans
may be take a pstack
Thanks,
M.

On Mon, Dec 23, 2019 at 3:08 PM Trevor Fong  wrote:

> Hi Everyone,
>
> We're running a cluster of VM's running 389-Directory/1.3.9.1
> B2019.164.1418 on RHEL7.7.
> Some are providers, which replicate to a bunch of hubs (which provide
> authentication services), which replicate in turn to a bunch of consumers
> (which provide support for longer running queries).
> Of late, we've a few clients have noted timed out connections.
> When we look in our logs we see things like:
>
> [23/Dec/2019:00:21:50.760643645 -0800] conn=7827580 fd=469 slot=469 SSL
> connection from  to 
> [23/Dec/2019:00:21:50.764149645 -0800] conn=7827580 TLS1.2 256-bit AES-GCM
>  connection>
> [23/Dec/2019:00:22:05.763868515 -0800] conn=7827580 op=-1 fd=469 closed -
> Encountered end of file.
>
> Others connections are made and operate just fine between the opening and
> closing of the timed-out connection.
>
> Would anyone know what this could be/what we could check?
>
> Thanks,
> Trev
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: how to remove a replication agreement

[Marc Sauton]

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:
cn=meTods2.example.test,cn=replica,cn=dc\3Dexample\2Cdc\3Dtest,cn=mapping
tree,cn=config
and remove the corresponding paragraph.

Also review the entry similar to this example:
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dtest,cn=mapping tree,cn=config
with a definition for
objectClass: nsds5replica
remove the nsState
or eventually remove the whole paragraph if not longer needed

Also review the paragraph with definition for
nsslapd-backend: xx
similar to this example
dn: cn=dc\3Dexample\2Cdc\3Dtest,cn=mapping tree,cn=config
nsslapd-backend: userRoot
nsslapd-state: backend
and review the  nsslapd-referral: attribute value

If there are more than 2 servers, the corresponding nsds50ruv would need to
be cleaned up on the other systems.

it may be "easier" to run the DS console, and faster to create a new
replica from "scratch" (that seem urgent if this now a single point of
failure scenario)
and it may be interesting to collect a core file and stack trace if the
version is current on the crashed system.

Thanks,
Marc S.

On Tue, Oct 15, 2019 at 12:49 PM I M 
wrote:

> 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
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: DS multimaster replication host crashed, will not restart

[Marc Sauton]

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, Oct 15, 2019 at 11:39 AM I M 
wrote:

> 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.
>
> Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; disabled; vendor
> preset: disabled)
>Active: failed (Result: signal) since Tue 2019-10-15 10:51:19 PDT;
> 40min ago
>   Process: 12904 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i
> /var/run/dirsrv/slapd-%i.pid (code=killed, signal=BUS)
>   Process: 12898 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl
> /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS)
>  Main PID: 12904 (code=killed, signal=BUS)
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: How to use Master slave replication between two different domains

[Marc Sauton]

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 is designed for dedicated suffixes.
There is no such feature to replicate to a different suffix, see:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/deployment_guide/introduction_to_directory_services-introduction_to_ds#Overview_of_DS_Architecture-Overview_of_the_Basic_Directory_Tree
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/deployment_guide/designing_the_directory_tree-designing_directory_tree#Creating_Directory_Tree_Structure-Replication_Considerations
and
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/Configuring_Directory_Databases-Creating_and_Maintaining_Databases

But if needed as a one time action, it is possible to export, tune the
resulting LDIF data, and then import into a different environment that is
not connected to the original one.

Thanks,
M.

On Tue, Oct 15, 2019 at 12:34 PM Janet Houser  wrote:

> 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 ask if there's a way to populate the people, groups, etc via
> master-slave replication between two seperate domains.
>
> I tried creating a seperate root tree following the information here:
>
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.0/html/Administration_Guide/Configuring_Directory_Databases.html#Creating_Suffixes-Creating_a_New_Root_Suffix_Using_the_Console
>
> But replication fails because it'd not doing the translation between the
> domains.
>
> All suggestions (and links to info) are appreciated.
>
> Thanks,
>
> Janet
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: DS multimaster replication host crashed, will not restart

[Marc Sauton]

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
https://www.port389.org/docs/389ds/FAaQ/faq.html#debug-startup-crashes

Since the system is running with RHEL, a Red Hat ticket should be opened,
with valid credentials, at
https://access.redhat.com/solution-engine/#/productSelector/?product=Red%20Hat%20Directory%20Server

Extra note: the current version is with RHEL-7.7
/ 389-ds-base-1.3.9.1-10.el7.x86_64
( includes many fixes since 389-ds-base-1.3.7.5-24.el7_5 )

Thanks,
M.


On Tue, Oct 15, 2019 at 10:21 AM  wrote:

> 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 status dirsrv@pldapX.service
> ● dirsrv@pldapX.service - 389 Directory Server pldapX
>Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; disabled;
> vendor preset: disabled)
>Active: failed (Result: signal) since Tue 2019-10-15 09:51:26 PDT; 3min
> 10s ago
>   Process: 7193 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i
> /var/run/dirsrv/slapd-%i.pid (code=killed, signal=BUS)
>   Process: 7187 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl
> /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS)
>  Main PID: 7193 (code=killed, signal=BUS)
>
> and  last lines from errorlog :
> [15/Oct/2019:10:17:29.710924472 -0700] - INFO - Security Initialization -
> SSL info: TLS_AES_256_GCM_SHA384: enabled
> [15/Oct/2019:10:17:29.719454362 -0700] - WARN - Security Initialization -
> SSL alert: nsTLS1 is on, but the version range is lower than "TLS1.0";
> Configuring the version range as default min: TLS1.0, max: TLS1.2.
> [15/Oct/2019:10:17:29.719840129 -0700] - INFO - Security Initialization -
> slapd_ssl_init2 - Configured SSL version range: min: TLS1.0, max: TLS1.2
> [15/Oct/2019:10:17:29.721517717 -0700] - INFO - main - 389-Directory/
> 1.3.7.5 B2018.178.1311 starting up
> [15/Oct/2019:10:17:34.230509014 -0700] - INFO -
> ldbm_instance_config_cachememsize_set - force a minimal value 512000
> [15/Oct/2019:10:17:34.332786785 -0700] - INFO -
> ldbm_instance_config_cachememsize_set - force a minimal value 512000
> [15/Oct/2019:10:17:34.349651890 -0700] - NOTICE - ldbm_back_start - found
> 16262020k physical memory
> [15/Oct/2019:10:17:34.350079009 -0700] - NOTICE - ldbm_back_start - found
> 15225948k available
> [15/Oct/2019:10:17:34.350389153 -0700] - NOTICE - ldbm_back_start - total
> cache size: 10523508736 B;
> [15/Oct/2019:10:17:34.351750381 -0700] - NOTICE - dblayer_start - Detected
> Disorderly Shutdown last time Directory Server was running, recovering
> database.
>
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: urp_fixup_add_cenotaph errors

[Marc Sauton]

could you check the system has 389-ds-base-1.3.9.1-10.el7

or
above?
do the MODRDN fail with err=53?
is it in IPA context with memberof-plugin errors?
there was a bug fix in bz 1680245 that seem related to this, may be there
is till something going on, or may be it can be ignored.
we would likely need to privately review more logs to tell (open a RH case?)
Thanks,
M.

On Fri, Sep 6, 2019 at 10:38 AM Morgan, Iain (ARC-TN)[InuTeq, LLC] <
iain.mor...@nasa.gov> wrote:

>
>
> On 9/5/19, 18:11, "Iain Morgan"  wrote:
>
> Hello,
>
> While testing 389-ds 1.3.9.1 on RHEL 7.7, I noticed the the errors
> listed below. The actual LDAP operations all succeed, but I find the
> errors disconcerting.
>
>
> [28/Aug/2019:10:42:13.446609256 -0700] - ERR - conn=44 op=5 -
> urp_fixup_add_cenotaph - failed to add cenotaph, err= 21
> [28/Aug/2019:10:42:14.202854398 -0700] - ERR - conn=52 op=5 -
> urp_fixup_add_cenotaph - failed to add cenotaph, err= 21
> [28/Aug/2019:10:42:18.504412946 -0700] - ERR - conn=95 op=3 -
> urp_fixup_add_cenotaph - failed to add cenotaph, err= 21
> [28/Aug/2019:10:42:24.412896470 -0700] - ERR - conn=160 op=8 -
> urp_fixup_add_cenotaph - failed to add cenotaph, err= 21
>
> These all appear to be related to modrdn operations.
>
> --
> Iain Morgan
>
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: Replacing a default schema for only one instance?

[Marc Sauton]

the RHDS-10 custom schema is in /etc/dirsrv/slapd-*/schema/99user.ldif
while the "core" schema files have now been located in
/usr/share/dirsrv/schema/
you can till use the /etc/dirsrv/slapd-instance_name/schema/ directory ,
but see the caveat in the online doc at:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/extending_the_directory_schema#default-schema
12.1.5. Schema Replication
"
Schema files other than /etc/dirsrv/slapd-instance_name/schema/99user.ldif
are used.
Directory Server enables you to add additional schema files in the
/etc/dirsrv/slapd-instance_name/schema/ directory. However, only the CSN in
the 99user.ldif file is updated. For this reasons, other schema file are
only used locally and are not automatically transferred to replication
partners. Copy the updated schema file manually to the consumers and reload
the schema. For details, see Section 12.7, “Dynamically Reloading Schema”.
"

that may be confusing when used to the previous schema files and location,
and the reasons are documented in the upstream ticket:
https://pagure.io/389-ds-base/issue/48163 / If /etc/dirsrv/schema is
version-specific, it should not live in /etc


On Tue, Jun 18, 2019 at 11:42 AM Paul Engle  wrote:

>
> All,
>   Specifically, I'm referring to the two incompatible schemas for rfc2307
> vs rfc2307bis. In the past, it was possible to just delete 10rfc2307.ldif
> from /etc/dirsrv//schema and replace it with the file supplied
> from /usr/share/dirsrv/data/10rfc2307bis.ldif.
>
> Now, with the new directory layout in 1.3.8.4, there is nothing to delete
> in /etc/dirsrv//schema. And since the two schemas are
> incompatible, I can't load the other one by dropping it in there.
>
> It seems the only thing I'm able to do is remove
> /usr/share/dirsrv/schema/10rfc2307.ldif to get the other file to load.
> That's global for all instances on the server, though. Is there any way to
> make this change for just one instance?
>
> paul
>
> --
> Paul Engle
> Office of Information Technology
> pen...@rice.edu
> 713-348-4702
> ___
> 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:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>
___
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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: 389ds can't start after "db error (no disk space)" ... space problem has been resolved

[Marc Sauton]

Restore is one way t proceed.
A quick way to recover the LDAP service in this situation, is to remove the
changelog files and let 389-ds create new ones at start up.
Then check for consistency as much as possible.
Eventually re-init from another replica.
The recovery process may take "some time", depending on disk I/O latency ,
cache tuning and db size.
Thanks,
M.

On Mon, Dec 10, 2018 at 12:59 PM Zarko D  wrote:

> Hi there, we have four IPA servers 4.4.0 and 389-ds is 1.3.5.10-11, and
> there is multi master replication among some of them.
>
> There is daily backup via ipa-backup, and on one server it failed because
> of disk space. The /var/log/dirsrv/slapd-EXAMPLE-COM/errors read:
>
> - NSMMReplicationPlugin - changelog program - _cl5WriteEntryCount: failed
> to write count entry for file
> /var/lib/dirsrv/slapd-EXAMPLE-COM/cldb/2acb5f15-a8ef11e6-81cbc137-643887ad_57be0c5f0004.db;
> db error - 28 No space left on device
> - NSMMReplicationPlugin - changelog program - _cl5WriteRUV: failed to
> write purge RUV for file
> /var/lib/dirsrv/slapd-EXAMPLE-COM/cldb/2acb5f15-a8ef11e6-81cbc137-643887ad_57be0c5f0004.db;
> db error - 28 (No space left on device)
> - NSMMReplicationPlugin - changelog program - _cl5WriteRUV: failed to
> write upper bound RUV for file
> /var/lib/dirsrv/slapd-EXAMPLE-COM/cldb/2acb5f15-a8ef11e6-81cbc137-643887ad_57be0c5f0004.db;
> db error - 28 (No space left on device)
> - NSMMReplicationPlugin - changelog program - _cl5WriteEntryCount: failed
> to write count entry for file
> /var/lib/dirsrv/slapd-EXAMPLE-COM/cldb/6070479f-a8ef11e6-81cbc137-643887ad_57be0cb80060.db;
> db error - 28 No space left on device
>
> Disk space is resolved by growing logical volume, but 389ds fails to start
> with messages:
>
> - NSMMReplicationPlugin - changelog program - cl5Open: failed to open
> changelog
> - NSMMReplicationPlugin - changelog program - changelog5_init: failed to
> start changelog at /var/lib/dirsrv/slapd-EXAMPLE-COM/cldb
> - Failed to start object plugin Multimaster Replication Plugin
> - Error: Failed to resolve plugin dependencies
>
> Can you please advise about possible resolution. Thanks in advance, Zarko
> ___
> 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: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>
___
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: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: Enabling TLS in Directory Server Using the Console

[Marc Sauton]

Yes, check the errors log file liek mentioned, and/or the systemd 's dirsrv
status , and/or journalctl -r --unit=dirsrv@\*

Without logs, I will just speculate the ns-slapd daemon needed the key file
password at restart, and was waiting at a prompt, then eventually timed out.
if this is the case, check the admin guide at either
9.4.1.4. Starting Directory Server Without a Password File
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/enabling_tls#starting_directory_server_without_a_password_file
or
9.4.1.5. Creating a Password File for Directory Server
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/enabling_tls#creating_a_password_file_for_directory_server

Thanks,
M.

On Wed, Apr 18, 2018 at 10:23 AM, Paul Whitney  wrote:

> Hi Jeremy,
>
> I would look at the /var/log/dirsrv/admin-serv/error and
> /var/log/dirsrv/slapd-config/errors files to see what is preventing you
> from starting the services.
>
> Paul M. Whitney
> E-mail: paul.whit...@mac.com
> Sent from my browser.
>
>
>
> On Apr 17, 2018, at 10:28 PM, Jeremy Tourville <
> jeremy_tourvi...@hotmail.com> wrote:
>
> I am following the Red Hat Directory Server 10 Admin Guide under section 
> 9.4.1.2.
> So far I have been able to create the certificates and database and getting
> the certs imported to the proper locations.  My issue happens when I
> attempt to restart the services.  The service eventually just times out
> trying to restart and I get a message "the server could not be restarted".
> I end up losing the changes I had just made in the console.  I have tried
> to review my settings to be sure I didn't overlook something and everything
> seems to be ok.  What logs should I be reviewing to see why the service
> isn't restarting properly?
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
>
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: 389 DS Time Skew Error

[Marc Sauton]

this is the correct document for the full cleanup.
it may be possible to recover by just deleting the nsState on a master and
doing a reinit of all the replica, but there may be stale csn traces in the
ruv in each replication agreement.
M.


On Mon, Apr 9, 2018 at 5:49 AM, Paul Whitney  wrote:

> Hi guys,
>
> I have been reading up on a fix for this and only found one set of
> procedures to repair this issue. (http://directory.
> fedoraproject.org/docs/389ds/howto/howto-fix-and-reset-time-skew.html).
> Would removing/recreating the replication agreement resolve this issue
> instead of the steps in the above URL?
>
>
> Paul M. Whitney
> E-mail: paul.whit...@mac.com
> Sent from my browser.
>
>
>
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: monitoring

[Marc Sauton]

That should work.
Thanks,
M.

On Thu, Dec 21, 2017 at 1:49 PM, Sergei Gerasenko <gera...@gmail.com> wrote:

> Excellent info, Mark. Thank you. I’m using collectd for graphing the
> results and since the backend trees are not readable by everyone, I’m
> thinking of granting read access to the collectd account.
>
> Is an ldif like the one below the right way to do it:
>
> dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config
> changetype: modify
> add: aci
> aci: (target ="ldap:///cn=monitor,cn=ldbm 
> database,cn=plugins,cn=config")(targetattr
> != "aci || connection")(version 3.0; acl “collectd access"; allow( read,
> search, compare ) userdn = "ldap:///uid=collectd,cn=
> users,cn=accounts,dc=mydomain,dc=net”;)
>
> Thanks!
>   Sergei
>
> On Dec 21, 2017, at 3:20 PM, Marc Sauton <msau...@redhat.com> wrote:
>
> The SNMP counters are not always interesting, but they can provide the
> system memory use and some LDAP BIND info.
>
> Under
> cn=monitor , the most important are:
> the difference between opsinitiated and opscompleted
> and also
> threads
> currentconnections
> and
> backendmonitordn
>
> so under
> cn=monitor,cn=,cn=ldbm\ database,cn=plugins,cn=config
> objectclass=*
> like for example
> dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> the following are important:
> entrycachehitratio
> currententrycachesize
> maxentrycachesize
> dncachehitratio
> currentdncachesize
> maxdncachesize
> and the pagein and pageout values if too high
>
>
> under
> cn=monitor,cn=ldbm\ database,cn=plugins,cn=config
> nsslapd-db-current-locks
> nsslapd-db-configured-locks
> nsslapd-db-page-ro-evict-rate
> nsslapd-db-page-rw-evict-rate
>
>
> the dbmon.sh tool can provide some info/hints/details
>
> for replication, the attribute
> nsDS5ReplicaLastUpdateStatus
> nsDS5ReplConflict
> nsruvReplicaLastModified
>
> /usr/bin/ldapsearch -xLLL -h xx -p xx -D "cn=directory manager" -W -b
> "cn=mapping tree,cn=config" "(&(objectClass=nsDS5ReplicationAgreement)(
> nsDS5ReplicaHost=*)(nsDS5ReplicaPort=xx))" nsDS5ReplicaChangesSentSinceStartup
> nsDS5ReplicaLastUpdateStatus nsDS5ReplicaUpdateInProgress
> nsDS5ReplicaLastUpdateStart nsDS5ReplicaLastUpdateEnd
>
> /usr/bin/ldapsearch -LLLx -o ldif-wrap=no -D "cn=directory manager" -W -b
> dc=example,dc=com nsds5ReplConflict=* dn cn
>
> see
> https://access.redhat.com/documentation/en-us/red_hat_
> directory_server/10/html/administration_guide/managing_
> replication-monitoring_replication_status
> http://www.port389.org/docs/389ds/howto/howto-replicationmonitoring.html
>
> there is also an old tool called
> repl-monitor.pl
> from the "Admin Express" feature, HTML colored page:
> https://access.redhat.com/documentation/en-us/red_hat_
> directory_server/10/html/administration_guide/managing_
> replication-monitoring_replication_status#replication-monitoring
>
> I may have forgotten some attributes.
> Thanks,
> M.
>
> On Thu, Dec 21, 2017 at 11:50 AM, Sergei Gerasenko <gera...@gmail.com>
> wrote:
>
>> I’ve implemented the solution described in the thread. My question now
>> is: what should I really monitor?
>>
>> There are so many metrics to consider. The thread talks about
>> cn=snmp,cn=monitor. But there are also cn=monitor suffixes under each
>> backend for example. Is there a recommended mininum set of things to
>> monitor?
>>
>> On Dec 14, 2017, at 6:23 PM, Marc Sauton <msau...@redhat.com> wrote:
>>
>> There is no collectd 389-ds plug-in, but there was a post with an example:
>> https://lists.fedoraproject.org/archives/list/389-users@list
>> s.fedoraproject.org/thread/TTKWB7WA4NEHYM5GDPLDJVIMR34DKNT2/
>> May be other users already run some similar plug-in?
>> Should we have such plug-in?
>> Thanks,
>>
>>
>>
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>>
>>
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
>
>
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: monitoring

[Marc Sauton]

The SNMP counters are not always interesting, but they can provide the
system memory use and some LDAP BIND info.

Under
cn=monitor , the most important are:
the difference between opsinitiated and opscompleted
and also
threads
currentconnections
and
backendmonitordn

so under
cn=monitor,cn=,cn=ldbm\ database,cn=plugins,cn=config
objectclass=*
like for example
dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
the following are important:
entrycachehitratio
currententrycachesize
maxentrycachesize
dncachehitratio
currentdncachesize
maxdncachesize
and the pagein and pageout values if too high


under
cn=monitor,cn=ldbm\ database,cn=plugins,cn=config
nsslapd-db-current-locks
nsslapd-db-configured-locks
nsslapd-db-page-ro-evict-rate
nsslapd-db-page-rw-evict-rate


the dbmon.sh tool can provide some info/hints/details

for replication, the attribute
nsDS5ReplicaLastUpdateStatus
nsDS5ReplConflict
nsruvReplicaLastModified

/usr/bin/ldapsearch -xLLL -h xx -p xx -D "cn=directory manager" -W -b
"cn=mapping tree,cn=config"
"(&(objectClass=nsDS5ReplicationAgreement)(nsDS5ReplicaHost=*)(nsDS5ReplicaPort=xx))"
nsDS5ReplicaChangesSentSinceStartup nsDS5ReplicaLastUpdateStatus
nsDS5ReplicaUpdateInProgress nsDS5ReplicaLastUpdateStart
nsDS5ReplicaLastUpdateEnd

/usr/bin/ldapsearch -LLLx -o ldif-wrap=no -D "cn=directory manager" -W -b
dc=example,dc=com nsds5ReplConflict=* dn cn

see
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-monitoring_replication_status
http://www.port389.org/docs/389ds/howto/howto-replicationmonitoring.html

there is also an old tool called
repl-monitor.pl
from the "Admin Express" feature, HTML colored page:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-monitoring_replication_status#replication-monitoring

I may have forgotten some attributes.
Thanks,
M.

On Thu, Dec 21, 2017 at 11:50 AM, Sergei Gerasenko <gera...@gmail.com>
wrote:

> I’ve implemented the solution described in the thread. My question now is:
> what should I really monitor?
>
> There are so many metrics to consider. The thread talks about
> cn=snmp,cn=monitor. But there are also cn=monitor suffixes under each
> backend for example. Is there a recommended mininum set of things to
> monitor?
>
> On Dec 14, 2017, at 6:23 PM, Marc Sauton <msau...@redhat.com> wrote:
>
> There is no collectd 389-ds plug-in, but there was a post with an example:
> https://lists.fedoraproject.org/archives/list/389-users@
> lists.fedoraproject.org/thread/TTKWB7WA4NEHYM5GDPLDJVIMR34DKNT2/
> May be other users already run some similar plug-in?
> Should we have such plug-in?
> Thanks,
>
>
>
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: monitoring

[Marc Sauton]

There is no collectd 389-ds plug-in, but there was a post with an example:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/thread/TTKWB7WA4NEHYM5GDPLDJVIMR34DKNT2/
May be other users already run some similar plug-in?
Should we have such plug-in?
Thanks,
M.

On Thu, Dec 14, 2017 at 2:45 PM, Sergei Gerasenko  wrote:

> Hello,
>
> I’m trying to set up collectd to monitor 389-ds by using the values under
> cn=monitor. Is there something out there (e.g., a collectd plugin?) that
> could do this? I’ve seen this: http://directory.
> fedoraproject.org/docs/389ds/howto/howto-cn-equals-monitor-
> ldap-monitoring.html, but that requires MySQL or Postgres.
>
> Thanks,
>   Sergei
>
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Recovering a Hub

[Marc Sauton]

so there is a crash, but not a lot of information, a core file and a stack
trace would be needed to get more details, so I will direct to this doc:
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
also try to check for anything unexpected in the LDIF file.
also try to verify the cache configurations for the data used.
we should not see a crash.

On Wed, Oct 25, 2017 at 4:54 AM, Paul Whitney <paul.whit...@mac.com> wrote:

>
> We have multiple failed attempts to reinit the directory (groupRoot).  It
> seems that the servers that were upgraded to 1.3.6.1-19 are failing on
> reinit from servers running 1.3.5.10-21.
>
> About half way through the groupRoot import using the ldif2db
> commmand (service already stopped), we got the following error:
>
> ** stack smashing detected* ./usr/sbin/ns-slapd terminiated
> /usr/sbin/ldif2db: line 116: 22793 Segmentation fault
>
>
> Paul M. Whitney
> E-mail: paul.whit...@mac.com
> Sent from my browser.
>
>
>
> On Oct 20, 2017, at 04:38 PM, Marc Sauton <msau...@redhat.com> wrote:
>
> What were the exact errors when the re-init and off-line import failed?
> Thanks,
> M.
>
> On Fri, Oct 20, 2017 at 11:11 AM, Paul Whitney <paul.whit...@mac.com>
> wrote:
>
>> I took your advice and looked up the versions of 389-ds-base.
>>
>> On the servers we are having problems with, they are running version
>> 1.3.6.1-19 and the servers replicating to them are running an older version
>> of 389-ds-base: 1.3.5.10-21.
>>
>> Would this cause the service to go awry if they are not all on the same
>> version?
>>
>>
>> Paul M. Whitney
>> E-mail: paul.whit...@mac.com
>> Sent from my browser.
>>
>>
>>
>> On Oct 19, 2017, at 12:45 PM, Marc Sauton <msau...@redhat.com> wrote:
>>
>> Those 2 methods should work fine, and are the right way to proceed, but
>> you may need to review the exact errors on why the re-init and import
>> failed.
>> Also check for the 389-ds-base versions on each node.
>> M.
>>
>> On Thu, Oct 19, 2017 at 10:03 AM, Paul Whitney <paul.whit...@mac.com>
>> wrote:
>>
>>> Hi, not sure what happened to our DS server, but I need to clone the
>>> userRoot and groupRoot database from a working server to this one bad one.
>>> What is the preferred/recommended method for this:
>>>
>>> I tried simple reinit, that failed.
>>> I tried export/import from LDIF file and that failed.
>>>
>>> Will db2bak then bak2db work?
>>>
>>> Thanks,
>>>
>>>
>>> Paul M. Whitney
>>> E-mail: paul.whit...@mac.com
>>> Sent from my browser.
>>>
>>>
>>>
>>> ___
>>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>>>
>>>
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>>
>>
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>>
>>
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
>
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Recovering a Hub

[Marc Sauton]

What were the exact errors when the re-init and off-line import failed?
Thanks,
M.

On Fri, Oct 20, 2017 at 11:11 AM, Paul Whitney <paul.whit...@mac.com> wrote:

> I took your advice and looked up the versions of 389-ds-base.
>
> On the servers we are having problems with, they are running version
> 1.3.6.1-19 and the servers replicating to them are running an older version
> of 389-ds-base: 1.3.5.10-21.
>
> Would this cause the service to go awry if they are not all on the same
> version?
>
>
> Paul M. Whitney
> E-mail: paul.whit...@mac.com
> Sent from my browser.
>
>
>
> On Oct 19, 2017, at 12:45 PM, Marc Sauton <msau...@redhat.com> wrote:
>
> Those 2 methods should work fine, and are the right way to proceed, but
> you may need to review the exact errors on why the re-init and import
> failed.
> Also check for the 389-ds-base versions on each node.
> M.
>
> On Thu, Oct 19, 2017 at 10:03 AM, Paul Whitney <paul.whit...@mac.com>
> wrote:
>
>> Hi, not sure what happened to our DS server, but I need to clone the
>> userRoot and groupRoot database from a working server to this one bad one.
>> What is the preferred/recommended method for this:
>>
>> I tried simple reinit, that failed.
>> I tried export/import from LDIF file and that failed.
>>
>> Will db2bak then bak2db work?
>>
>> Thanks,
>>
>>
>> Paul M. Whitney
>> E-mail: paul.whit...@mac.com
>> Sent from my browser.
>>
>>
>>
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>>
>>
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
>
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Recovering a Hub

[Marc Sauton]

Those 2 methods should work fine, and are the right way to proceed, but you
may need to review the exact errors on why the re-init and import failed.
Also check for the 389-ds-base versions on each node.
M.

On Thu, Oct 19, 2017 at 10:03 AM, Paul Whitney  wrote:

> Hi, not sure what happened to our DS server, but I need to clone the
> userRoot and groupRoot database from a working server to this one bad one.
> What is the preferred/recommended method for this:
>
> I tried simple reinit, that failed.
> I tried export/import from LDIF file and that failed.
>
> Will db2bak then bak2db work?
>
> Thanks,
>
>
> Paul M. Whitney
> E-mail: paul.whit...@mac.com
> Sent from my browser.
>
>
>
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Odd issue with 389 and updating to Cent 6.8 with TLS/SSL

[Marc Sauton]

the error mentioned at the beginning was:
[26/Jan/2017:01:02:39 -0500] conn=97 op=-1 fd=64 closed - Unspecified
failure while processing SSL Client Key Exchange handshake.
And with "TLS_REQCERT demand", there is likely a failed SSL server
certificate verification, which may be related to either a cert chain not
fully trusted, or an incorrect cert usage, or incorrect validity dates, or
a non matching subject DN, or an issuer in the chain with a signature's
algorithm now considered weak.
if you have the luxury to try gain, collect a tcpdump trace to see the
details of the SSL handshake, and/or eventually try only as a test with
"TLS_REQCERT = allow" or "TLS_REQCERT = never"
Thanks,
M.

On Fri, Jan 27, 2017 at 9:34 AM, John McKee 
wrote:

> @Mark Reynolds
>
> I had no choice but to revert to my snapshot to get production back up and
> running, but I will experiment and will post the outcome. Thank you for
> your help thus far.
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Odd issue with 389 and updating to Cent 6.8 with TLS/SSL

[Marc Sauton]

This may happen if some LDAP clients are not up to date (what are they?
Java clients?)
A tcpdump could show the details of the ciphers negociated in the TLS or
SSL handshake for the failing LDAP clients.
Possible related article:
https://access.redhat.com/solutions/2332231
Thanks,
M.

On Thu, Jan 26, 2017 at 9:59 AM, John McKee 
wrote:

> We had to update our server from CentOS 6.7 to CentOS 6.8 due to security
> compliance. When doing so however, it caused 389 to be unstable for TLS/SSL
> port 636. It would be up for a minute or two, then fail with the following
> error when a server/script tried to connect. Non-TLS/SSL port 389 would
> work fine without any issues/errors. Before we patched, it would work
> without issues. Connection to port shows no issue with certificate.
>
> [26/Jan/2017:01:02:39 -0500] conn=97 fd=64 slot=64 SSL connection from
> X.X.X.X to X.X.X.X
> [26/Jan/2017:01:02:39 -0500] conn=97 op=-1 fd=64 closed - Unspecified
> failure while processing SSL Client Key Exchange handshake.
>
> From the client:
>
> TLS: loaded CA certificate file /etc/pki/tls/certs/bundle.crt.
> TLS: certificate [CN=XX.com,OU=PositiveSSL Multi-Domain,OU=Domain
> Control Validated] is valid
> TLS: error: tlsm_PR_Recv returned -1 - error 104:Connection reset by peer
> TLS: error: connect - force handshake failure: errno 104 - moznss error
> -5961
> TLS: can't connect: TLS error -5961:TCP connection reset by peer.
> ldap_err2string
> ldap_start_tls: Connect error (-11)
> additional info: TLS error -5961:TCP connection reset by peer
> ldap_sasl_bind
>
> Normal Connection:
>
> [26/Jan/2017:05:29:35 -0500] conn=904 fd=65 slot=65 SSL connection from
> X.X.X.X to X.X.X.X
> [26/Jan/2017:05:29:35 -0500] conn=904 TLS1.2 256-bit AES
>
> Current Version of 389:
>
> 389-adminutil-1.1.19-1.el6.x86_64
> 389-ds-base-libs-1.2.11.15-74.el6.x86_64
> 389-ds-console-doc-1.2.6-1.el6.noarch
> 389-admin-1.1.35-1.el6.x86_64
> 389-ds-console-1.2.6-1.el6.noarch
> 389-dsgw-1.1.11-1.el6.x86_64
> 389-ds-base-1.2.11.15-74.el6.x86_64
> 389-console-1.1.7-1.el6.noarch
>
> NSS:
>
> nss-3.21.0-8.el6.x86_64
> nss-softokn-3.14.3-23.el6_7.x86_64
> nss-softokn-freebl-3.14.3-23.el6_7.i686
> nss-softokn-freebl-3.14.3-23.el6_7.x86_64
> nss-sysinit-3.21.0-8.el6.x86_64
> nss-tools-3.21.0-8.el6.x86_64
> nss-util-3.21.0-2.el6.x86_64
>
> Port is open:
>
> tcp0  0 :::636  :::*
>   LISTEN
>
> Approx Strace:
>
> getpeername(8, 0x7ffe450d5980, [112])   = -1 ENOTCONN (Transport endpoint
> is not connected)
> poll([{fd=40, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}, {fd=-1}], 4, 250) = 1 ([{fd=8, revents=POLLIN}])
> accept(8, {sa_family=AF_INET6, sin6_port=htons(52890), inet_pton(AF_INET6,
> ":::X.X.X.X", _addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 36
> fcntl(36, F_GETFL)  = 0x2 (flags O_RDWR)
> fcntl(36, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
> fcntl(36, F_DUPFD, 64)  = 64
> close(36)   = 0
> setsockopt(64, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
> setsockopt(64, SOL_TCP, TCP_NODELAY, [0], 4) = 0
> getsockname(64, {sa_family=AF_INET6, sin6_port=htons(636),
> inet_pton(AF_INET6, ":::X.X.X.X", _addr), sin6_flowinfo=0,
> sin6_scope_id=0}, [28]) = 0
> getpeername(8, 0x7ffe450d5980, [112])   = -1 ENOTCONN (Transport endpoint
> is not connected)
> poll([{fd=40, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}, {fd=-1}, {fd=64, events=POLLIN}], 5, 250) = 1 ([{fd=64,
> revents=POLLIN}])
> futex(0x16ee83c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x16ee838, {FUTEX_OP_SET, 0,
> FUTEX_OP_CMP_GT, 1}) = 1
> getpeername(8, 0x7ffe450d5980, [112])   = -1 ENOTCONN (Transport endpoint
> is not connected)
> poll([{fd=40, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}, {fd=-1}], 4, 250) = 1 ([{fd=40, revents=POLLIN}])
> read(40, "\0", 200) = 1
> close(64)   = 0
> getpeername(8, 0x7ffe450d5980, [112])   = -1 ENOTCONN (Transport endpoint
> is not connected)
> poll([{fd=40, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}, {fd=-1}], 4, 250) = 0 (Timeout)
>
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: 389 DS - Choosing certificate to authenticate

[Marc Sauton]

set nsSSLClientAuth  to "required"
there are some details in:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#nsSSLClientAuth
and
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_SSL-Using_Certificate_Based_Authentication.html#clientauth


On Mon, Jan 9, 2017 at 6:40 AM,  wrote:

> How do you get certificates to populate in the authenticate section.
>
> At the moment i have my 389 DS to do optional certificate enforcement but
> i want to require it... Just not sure why my certificates are not showing
> up in the list.
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: 389 DS - Choosing certificate to authenticate

[Marc Sauton]

use nsSSLClientAuth under cn=encryption,cn=config to re

On Mon, Jan 9, 2017 at 6:40 AM,  wrote:

> How do you get certificates to populate in the authenticate section.
>
> At the moment i have my 389 DS to do optional certificate enforcement but
> i want to require it... Just not sure why my certificates are not showing
> up in the list.
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: performance degrades over time on CentOS 7

[Marc Sauton]

What is the test filter like?
Can we see a sanitized sample of the access log with the SRCH and RESULT?

If using SSL, review the output of
cat /proc/sys/kernel/random/entropy_avail

Do we have replication? (and large attribute values?)

You may want to run the "dbmon.sh" script to monitor cache usage for db
cache and entry cache, try to capture a few samples of line about
 dbcachefree and userroot:ent (if the db with the problems is
userroot), when the searches are becoming too long, like this example:
INCR=1 HOST=m2.example.com BINDDN="cn=directory manager" BINDPW="password"
VERBOSE=2 /usr/sbin/dbmon.sh

and review the ns-slapd errors and system messages log files for any
unusual activity.

what is the ns-slapd memory foot print from restart to slow responses?
any "too high" disk i/o? (or "bad" ssd?)

Thanks,
M.

On Tue, Nov 15, 2016 at 11:40 AM, Gordon Messmer 
wrote:

> I'm trying to track down a problem we are seeing on two relatively lightly
> used instances on CentOS 7 (and previously on CentOS 6, which is no longer
> in use).  Our servers have 3624 entries according to last night's export
> (we export userRoot daily).  There are currently just over 400 connections
> established to each server.
>
> We have a local cron job that runs every 5 minutes that performs a simple
> query.  If it takes more than 7 seconds to get an answer, the attempt is
> aborted and another query issued.  If three consecutive test fail, the
> directory server is restarted.
>
> The issue we're seeing is that the longer the system is up, the more often
> checks will fail.  Restarting the directory does not resolve the problem.
> Our servers have currently been up for 108 days, and are restarting the
> service several times a day, as a result of the checks.  Only if we reboot
> the systems does the problem subside.
>
> CPU utilization seems relatively high for such a small directory, but it's
> not constant.  I tried to manually capture a bit of data with strace during
> a period when CPU use was bursting high.  During a capture of maybe two
> seconds, I saw most of the CPU time was spent in futex.  usecs/call was
> fairly high for calls to futex and select, as detailed below.
>
> Since restarting the service doesn't fix the problem, it seems most likely
> that this is an OS bug, but I'm hoping that the list can help me identify
> other useful data to track down the problem.  Does anyone have any
> suggestions for what I can capture now, while I can sometimes observe the
> problem?  If I reboot, it'll take months before I can get any new data.
>
>
> % time seconds  usecs/call callserrors syscall
> -- --- --- - - 
>  74.614.5052513590  1255   340 futex
>  17.651.0655486660   160   select
>   4.410.266344   88781 3 2 restart_syscall
>   3.070.185566  50  3718   poll
>   0.100.006185   2  3610   sendto
>   0.090.0051895189 1   fsync
>   0.040.002134  3758   write
>   0.030.001618  2761   setsockopt
>   0.000.000111   336   recvfrom
>   0.000.78   157   read
>   0.000.14  14 1   fstat
>   0.000.03   2 2   accept
>   0.000.03   1 6   fcntl
>   0.000.02   1 2   getsockname
>   0.000.01   1 2   close
> -- --- --- - - 
> 100.006.038047  8972   342 total
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: 389 directory server console crash and core dump

[Marc Sauton]

try with  java-1.7.0-openjdk
I think it should be java-1.7.0-openjdk-1.7.0.99-2.6.5.0.el6_7
and to switch the JRE, use the command
alternatives --config java
quit and restart the Java DS console.
Thanks,
M.

On 03/25/2016 01:52 PM, xinhuan zheng wrote:

Today I installed the 389 Directory Server and Directory Console. However, the 
console keeps crashing and dumping core. However, it failed to write core dump, 
leaving a log file into root directory.

The first time when it dumps core:
1. Launch the 389-console
2. Login
3. Select Directory Server Instance, in my case, its userauth1, open it
4. Choose Configuration Tab, expand data
5. Right click on it, choose New Suffix
6. Type in New Suffix name: dc=test2,dc=com
7. Type in Database name: test2
8. Click OK.

Then it dumps core. I re-launch the console, but I cannot find the newly added 
suffix.

So I decide to add it again, but the console spit out error that "suffix already 
exists". Console does not display the newly added suffix, however, it thinks it does 
exist.

I repeated adding another new suffix with a different name. It works without 
core dump.

I repeated adding/deleting new suffix a few more times. It appears core dump 
happens either when adding or deleting root suffix, randomly.

I need help to figure out
1) How do I delete the root suffix that cannot be displayed by the console?
2) How do I make console stable.

The java package, java-1.6.0-openjdk-1.6.0.38-1.13.10.0.el6_7.x86_64, is 
installed and used on my CentOS 6.7 x86_64 machine.

Thanks,
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Question about re-indexing with db2index.pl

[Marc Sauton]

The original error was:

[02/Feb/2016:15:27:17 -0600] - import userRoot: WARNING: Skipping entry 
"uid=user1,ou=Users,ou=Place1,ou=Place2,ou=Groups,dc=mydomain,dc=net" 
which has no parent, ending at line 0 of file "(bulk import)"


which indicates there is "something wrong" in the definition of the 
container for uid=user1 and user2 and user3, in the imported LDIF file, 
it is likely missing a definition for ou=groups and/or ou=users.


if the goal is to overwrite the current db with a bulk import, I would 
say we can ignore the current mis-order of the ou=place2 and ou=place1 
and missing ou=users in the existing db as shown by the dbscan outputs for

ou=place2,ou=place1,dc=mydomain,dc=net
and
dn: uid=user1,ou=Place1,ou=Place2,ou=Groups,dc=mydomain,dc=net
parentid: 174
entryid: 366

and when after the bulk import succeeds, an on-line re-init to the other 
master will be needed to fully clear up things.


M.

On 02/05/2016 08:42 AM, Derek Belcher wrote:

Sorry, I see that I left out id 29

# dbscan -f /var/lib/dirsrv/slapd-INSTANCE/db/userRoot/id2entry.db4 -K 29
id 29
 rdn: ou=place3
 nsUniqueId: xxx-xxx-xxx-xxx
 modifyTimestamp: 20120707204926Z
 createTimestamp: 20120707204926Z
 modifiersName: cn=directory manager
 creatorsName: cn=directory manager
 ou: place2
 ou: place3
 objectClass: top
 objectClass: organizationalunit
 parentid: 22
 entryid: 29
 numSubordinates: 8
 tombstoneNumSubordinates: 1


On Fri, Feb 5, 2016 at 10:25 AM,  wrote:


# dbscan -f /var/lib/dirsrv/slapd-INSTANCE/db/userRoot/id2entry.db4 -K 22
id 22
 rdn: ou=place2
 nsUniqueId: xxx-xxx-xxx-xxx
 modifyTimestamp: 20120707204926Z
 createTimestamp: 20120707204926Z
 modifiersName: cn=directory manager
 creatorsName: cn=directory manager
 ou: place2
 objectClass: top
 objectClass: organizationalunit
 parentid: 5
 entryid: 22
 numSubordinates: 6
 tombstoneNumSubordinates: 0

# dbscan -f /var/lib/dirsrv/slapd-INSTANCE/db/userRoot/id2entry.db4 -K 5
id 5
 rdn: ou=place1
 nsUniqueId: xxx-xxx-xxx-xxx
 modifyTimestamp: 20130125000753Z
 modifiersName: cn=directory manager
 aci: (...omitted)
 aci: (...omitted)
 aci: (...omitted)
 createTimestamp: 20120707204925Z
 creatorsName: cn=directory manager
 ou: place1
 objectClass: top
 objectClass: organizationalunit
 parentid: 1
 entryid: 5
 numSubordinates: 17
 tombstoneNumSubordinates: 0

# dbscan -f /var/lib/dirsrv/slapd-INSTANCE/db/userRoot/id2entry.db4 -K 1
id 1
 rdn: dc=mydomain,dc=net
 nsUniqueId: xxx-xxx-xxx-xxx
 modifyTimestamp: 2014011617Z
 modifiersName: cn=directory manager
 aci: (...omitted)
 aci: (...omitted)
 aci: (...omitted)
 aci: (...omitted)
 aci: (...omitted)
 createTimestamp: 20120707203637Z
 creatorsName:
 dc: mydomain
 objectClass: top
 objectClass: domain
 entryid: 1
 numSubordinates: 14
--
389 users mailing list
389-users@%(host_name)s

http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org




--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

Re: [389-users] Searching for userCertificate - what encoding is used in the query filter?

[Marc Sauton]

On 01/27/2015 05:56 PM, Graham Leggett wrote:

Hi all,

I have a query filter that looks like this: (userCertificate={0}${1})

I am trying to search for an explicit certificate in a directory, based on the 
serial number and the issuer DN. Can anyone confirm what encoding these values 
need to be in, and hat java library might help provide that encoding?

Regards,
Graham
—

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

it is usually a base 64 of ASN.1 DER encoded.
if the the CA is either Red Hat Certificate System or Dogtag from 
http://pki.fedoraproject.org/

the LDAP search base could be
ou=certificateRepository, ou=ca,dc=ca1.example.com-pki-ca
and the filter like
serialno=0518300
(where the 05 is the number of digits of the serial itself)
and attributes: dn subjectName certStatus serialno userCertificate
the issuer would till have to be decoded from the based 64 ASN.1 blob of 
the attribute userCertificate;binary::

Thanks,
M.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] MMR Replication issues

[Marc Sauton]

The error message Unable to acquire replica: error: permission denied 
seem to point to a mis-configuration of replication agreement for the DN 
used to BIND, like a wrong password if basic authentication is used, or 
a typo in the DN of the attribute nsDS5ReplicaBindDN

From http://port389.org/ , the documentation is at
http://www.port389.org/docs/389ds/documentation.html
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/index.html
and more specifically
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Creating_the_Supplier_Bind_DN_Entry.html
Thanks,
M.

On 01/27/2015 10:37 AM, Louis Bohm wrote:

I used the following docs to setup MMR on my CentOS 6.5 server:


http://trialanderrorlinux.wordpress.com/2013/06/22/ldap-directory-server-on-centos-6-3-using-tls/

http://linuxrackers.com/doku.php?id=389_directory_server_setup_using_centos6_rhel6

http://directory.fedoraproject.org/docs/389ds/howto/howto-walkthroughmultimasterssl.html

http://admintweets.com/389-ds-directory-services-multi-master-replication-setup/

I am not doing TLS between the master just between the clients and 
servers.  Now i am looking at the error logs and I am seeing an error 
in the log:


[27/Jan/2015:13:31:25 -0500] NSMMReplicationPlugin -
agmt=cn=ldap01.userRoot (ldap02:389): State: wait_for_changes -
wait_for_changes
[27/Jan/2015:13:31:25 -0500] NSMMReplicationPlugin -
agmt=cn=ldap01.userRoot (ldap02:389): State: wait_for_changes -
start
[27/Jan/2015:13:31:25 -0500] NSMMReplicationPlugin -
agmt=cn=ldap01.userRoot (ldap02:389): No linger to cancel on the
connection
[27/Jan/2015:13:31:25 -0500] NSMMReplicationPlugin -
agmt=cn=ldap01.userRoot (ldap02:389): Disconnected from the consumer
[27/Jan/2015:13:31:25 -0500] NSMMReplicationPlugin -
agmt=cn=ldap01.userRoot (ldap02:389): State: start -
ready_to_acquire_replica
[27/Jan/2015:13:31:25 -0500] NSMMReplicationPlugin -
agmt=cn=ldap01.userRoot (ldap02:389): State:
ready_to_acquire_replica - wait_for_changes
[27/Jan/2015:13:32:02 -0500] NSMMReplicationPlugin - conn=2347
op=3 Acquired consumer connection extension
[27/Jan/2015:13:32:02 -0500] NSMMReplicationPlugin - conn=2347
op=3 repl=dc=us1,dc=site,dc=com: Begin incremental protocol
[27/Jan/2015:13:32:02 -0500] NSMMReplicationPlugin - conn=2347
op=3 replica=dc=us1,dc=site,dc=com: Unable to acquire replica:
error: permission denied
[27/Jan/2015:13:32:02 -0500] NSMMReplicationPlugin - conn=2347
op=3 repl=dc=us1,dc= site,dc=com: StartNSDS90ReplicationRequest:
response=3 rc=0
[27/Jan/2015:13:32:02 -0500] NSMMReplicationPlugin - conn=2347
op=3 Relinquishing consumer connection extension

Any idea what it could be?  When I first set this up I did remember to 
init the replica.


Louis


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] 389-Directory/1.3.1.6 cannot setup replica

[Marc Sauton]

On 11/05/2014 12:54 PM, Ivanov Andrey (M.) wrote:



* if the virtual machine has only one CPU. Adding a second
CPU increases the number of transferred entries before the
initialization gets stuck. So it may me some
thread/transaction contention or deadlock.
* if the replication agreement uses SSL(port 636) or
TLS(port389). Using port 389 with LDAP protocol instead of
TLS/SSL increases the number of transferred entries before
the initialization gets stuck. Sometimes the
initialization even ends successfully in this case.
* decreasing nsslapd-db-checkpoint-interval (say, to 5
seconds) also gets the problem worse

This indicates the issue is in the BDB?

Don't know. My hypotheses are :
* using plugin transactions compared to 1.2.10.x
* bdb version? but even with compat-db-47 and 1.2.10 the problem
still happens on CentOS7, though much less frequently. It never
happens with 1.2.10 with rpm bdb on CentOS5.
* change from  mozilla ldap libraries to openldap libraries?

seems to be some sort of thread or transaction contention that is
reduced when i add CPUs/increase checkpoint interval. It really
looks like the master server just does not send entries any more
at some moment... SSL/TLS slows the things down so less entries
are sent before everything gets stuck...

I'll get back with more information (stacktraces) tomorrrow.

Another version :
insufficient entropy generation speed for TLS/SSL total update 
(/dev/urandom vs blocking /dev/random), especially in VMs??



it is possible the VM system is running out of entropy, and apps to 
experience long delays, to verify:

cat /proc/sys/kernel/random/entropy_avail

one way to fix this is to use and run the haveged service on the KVM 
guest, that can be downloaded from EPEL


it can also depends on the VM configuration, for example if using KVM 
and libvirt (recent version), use the KVM host entropy is with a 
configuration similar to this:

  rng model='virtio'
 backend model='random'/dev/random/backend
 address type='pci' domain='0x' bus='0x00' slot='0x09' 
function='0x0'/

   /rng
/devices
without that config, my test RHEL 7 KVM guest has quite a low entropy.
and the entropy will depends on the cpu characteristics.




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] ns-inactivate.pl

[Marc Sauton]

On 08/13/2014 11:09 AM, Elizabeth Jones wrote:

I'm trying to use ns-inactivate.pl to deactivate user accounts, but I
don't know how to get it to use port 636.  It works fine on 389 but if I
use -p 636 no dice.  I dont see that there is a flag to tell it where to
find the cert that it needs to make the connection.

Elizabeth J


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

You may want to use the -P option
   -P Protocol
  The connection protocol to connect to the Directory 
Server.  Protocols are STARTTLS, LDAPS, LDAPI, and LDAP.  If this option 
is skipped, the most secure protocol that is available is used.  For 
LDAPI, AUTOBIND is also available for the root user.


M.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] slapd process is hang

[Marc Sauton]

On 06/01/2014 09:53 AM, G, Rajendra Babu (STSD campus) wrote:


Hi All,

I am using 389 directory server 1.2.11.21  and I have noticed 
following error message in the error log and slapd process is stop 
responding in the mulrtimaster environment. Kindly let me know this 
fix got fixed in any releases, if yes please provide me the bug /url .


Error log message:

repl5_tot_create_async_result_thread failed.Netscape Portable 
Runtime error -5974 (Insufficient system resources.)


  repl5_inc_run: repl5_tot_create_async_result_thread failed; error - -1

Thanks in Advance,

Regards,

Rajendra



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
Review the system memory usage, add some RAM if not enough free memory 
to hold your db depending on the entry cache setting with 
nsslapd-cachememsize, restart the Directory Server.

See
https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Performance_Tuning_Guide/memoryusage.html#tuning-entry-cache
7.1. Tuning the Entry Cache
or review the file descriptor use and configuration.
M.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Uniqueness Attribute for specific objects in a specific subtree

[Marc Sauton]

On 04/27/2012 02:35 PM, John A. Sullivan III wrote:

Hello, all.  We would like to enforce unique cn for groupofuniquenames
only and only under a specific part of the DIT.

I'll illustrate with:
O=Internal,DC=mycompany,DC=com
O=External,DC=mycompany,DC=com

So we want to enforce unique CNs on groups under Internal but not under
External and only CNs on groups (because our current DN based uniqueness
constraint on CN means we can't create multiple password policy
nscontainer objects under Internal).

If we configure set nsslapd-pluginarg1 to
O=Internal,DC=mycompany,DC=com, we enforce uniqueness in that
container but for all objects.

Although we haven't tried it (lest we create a bigger problem than we
already have!), I believe it we set nsslapd-pluginarg1 to
markerObjectClass=O and nsslapd-pluginarg2 to
requiredObjectClass=groupofuniquenames, it will enforce CN uniqueness on
groups but will do so both in Internal AND External.  Is that correct?

So is it possible to combine them somehow to achieve what we want?
Thanks - John

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


Unless I am incorrect, this could be a RFE, attribute uniqness is 
currently implemented for a specific attribute in either a suffix or 
subtree, or defined by objectclass in the whole tree, not both.


It depends how those groups are organized, the subtree or suffix 
definition could be enough, using something similar to:

nsslapd-pluginarg0: some-attribute
nsslapd-pluginarg1: some-suffix-or-subtree-dn

For example, in IPA, for a CN uniquess in a netgroup subtree 
cn=ng,cn=alt,dc=example,dc=com:


dn: cn=netgroup uniqueness,cn=plugins,cn=config
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
cn: netgroup uniqueness
nsslapd-pluginPath: libattr-unique-plugin
nsslapd-pluginInitfunc: NSUniqueAttr_Init
nsslapd-pluginType: preoperation
nsslapd-pluginEnabled: on
nsslapd-pluginarg0: cn
nsslapd-pluginarg1: cn=ng,cn=alt,dc=example,dc=com
nsslapd-plugin-depends-on-type: database
nsslapd-pluginId: NSUniqueAttr
nsslapd-pluginVersion: 1.2.9.14
nsslapd-pluginVendor: 389 Project
nsslapd-pluginDescription: Enforce unique attribute values

I believe the markerObjectClass and requiredObjectClass are not designed 
to be mixed with the suffix or subtree definitions of the attribute 
uniqueness plug-in, for markerObjectClass.
The subtree is defined by location of marker object class, or its parent 
entry, so if the scope is controlled with requiredObjectClass 
groupofuniquenames it may parse entries in both subtrees internal and 
external in your example.

It seem to me you cannot use both definitions, but I could be wrong.

Reference:
ldap/servers/plugins/uiduniq/uid.c
and
5.1.4.2. Specifying One Attribute and Multiple Subtrees
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/pdf/Administration_Guide/Red_Hat_Directory_Server-9.0-Administration_Guide-en-US.pdf

M.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] 389 on a Redhat VPS?

[Marc Sauton]

On 02/08/2012 06:41 PM, Craig T wrote:

hi,

Has anyone setup 389-ds on a OpenVZ VPS yet? I'm attempting to setup IPA 2.x on 
my VPS and it's giving odd errors when starting the 389 Directory Server.

Spec;
Centos 6.2 (x86-64)
model name  : Intel(R) Xeon(R) CPU   E5645  @ 2.40GHz


Linux mx1.example.com 2.6.18-274.7.1.el5.028stab095.1 #1 SMP Mon Oct 24 
20:49:24 MSD 2011 x86_64 x86_64 x86_64 GNU/Linux

389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64
389-ds-base-1.2.9.14-1.el6_2.2.x86_64


Errors:
--
2012-02-09 04:59:18,815 DEBUG calling setup-ds.pl
2012-02-09 05:09:24,460 DEBUG args=/usr/sbin/setup-ds.pl --silent --logfile - 
-f /tmp/tmpkU_Ram
2012-02-09 05:09:24,461 DEBUG stdout=Server failed to start !!! Please check 
errors log for problems
[12/02/09:05:09:24] - [Setup] Info Could not start the directory server using 
command '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'.  The last line from the 
error log was '[09/Feb/2012:04:59:24 +0300] - Failed to create semaphore for 
stats file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied)

selinux?
or see this post / thread, although it is not clear if the issue was solved:
https://www.redhat.com/archives/freeipa-users/2012-January/msg00117.html

'.  Error: Unknown error 256
Could not start the directory server using command 
'/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'.  The last line from the error 
log was '[09/Feb/2012:04:59:24 +0300] - Failed to create semaphore for stats 
file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied)
'.  Error: Unknown error 256
[12/02/09:05:09:24] - [Setup] Fatal Error: Could not create directory server 
instance 'PKI-IPA'.
Error: Could not create directory server instance 'PKI-IPA'.
[12/02/09:05:09:24] - [Setup] Fatal Exiting . . .
Log file is '-'
--

cya

Craig
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Performance tuning OS side

[Marc Sauton]

Disk I/O can be the most common bottleneck, make sure you have enough 
physical memory to fit id2entry may be one.

There are also a few recommendations at
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Performance_Tuning_Guide/system-tuning.html#system-memory
You can move the BDB transaction logs (*.log) in a separate filesystem, 
tune db cache, add indexes.

And more:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/index.html
M.

On 02/01/2012 03:08 PM, Mark Reynolds wrote:

Hi Marco,

This is isn't linux specific, but disabling the logs(access  error) 
can help.  If you need the logs, move them to a dedicated FS.  I don't 
know if Linux has a FS cache, but on Solaris I've seen it is sometimes 
more efficient to turn the DS cache settings all the way down, and 
allow the OS FS cache to do everything.


Best Regards,
Mark

On 02/01/2012 04:03 PM, Marco Pizzoli wrote:

Hi *,
I'm exploring 389 after few years with OpenLDAP and I'm curious to 
know if some perfomance tuning tricks on Linux are valid with this 
product too.


- having a db directory located in a dedicated filesystem mounted 
with the noatime option

- LD_PRELOAD=tcmalloc

Any other hints?

Thanks in advance
Marco

--
_
Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi.
Jim Morrison


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Replication issue

[Marc Sauton]

On 10/11/2011 01:22 PM, Reinhard Nappert wrote:

Hi,
I encountered the following logs in the errors:
[06/Oct/2011:10:11:57 +] NSMMReplicationPlugin - changelog program - 
agmt=cn=srvAtosrvB (srvB:389): CSN 4e8d804a000c not found, we aren't 
as up to date, or we purged
[06/Oct/2011:10:11:57 +] NSMMReplicationPlugin - agmt=cn=srvAtosrvB 
(srvB:389): Data required to update replica has been purged. The replica must be 
reinitialized.
[06/Oct/2011:10:11:57 +] NSMMReplicationPlugin - agmt=cn=srvAtosrvB 
(srvB:389): Incremental update failed and requires administrator action
  
Does anyone have  an idea, what could have caused this and more importantly, how to fix this?
  
Thanks

-Reinhard


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

On server A, read a changelog to manually run the changes on server B.
May be tune up nsds5ReplicaPurgeDelay if such errors somehow appears 
regularly.
Otherwise, like the errors log says, the change was purged/removed, and 
replica need a re-init.

M.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Recover Management Console Password

[Marc Sauton]

You should be able to log into the directory console using the 
directory manager credentials to change the uid=admin password.
Or also from the command line, bind as directory manager and try 
change the userpassword attribute value of the entry 
uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot

M.

On 08/22/2011 11:18 AM, Brant Hohnstein wrote:


Thanks for the suggestion.  I think the link you sent me was to reset 
the Directory Manager password.  Forgive me if I am mistaken.  Don't I 
need a procedure to change the admin-server password?


Best regards,

*Brant Hohnstein*

*System Administrator*

brant.hohnst...@returnpath.net

+1 303-999-3233

*From:*389-users-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@lists.fedoraproject.org] *On Behalf Of 
*Aaron Hagopian

*Sent:* 22 August 2011 11:59 AM
*To:* General discussion list for the 389 Directory server project.
*Subject:* Re: [389-users] Recover Management Console Password

http://directory.fedoraproject.org/wiki/Howto:ResetDirMgrPassword

2011/8/22 Brant Hohnstein brant.hohnst...@returnpath.net 
mailto:brant.hohnst...@returnpath.net


Is there a procedure (however cumbersome) to reset the Management 
Console (admin) password if the password is not currently known?


I changed the admin password in the Console GUI 
(domainName/ldapservername/ServerGroup/Administration Server/Configure 
Admin Server/Access(tab).  I must have typed the password wrong twice 
because it accepted it.  Now I can't seem to type the password wrong 
in the same way to get into the Management Console.


I have tried shutting down the Admin Server and copying in a 
/etc/dirsrv/admin-serv/admpw file from a different 389 server where I 
do know the password.  After restarting and typing in the known 
password, I get an error about not being able to contact the directory 
server.


I have also searched for a password recovery procedure without success.

Any helpful suggestions would be appreciated.

*Brant Hohnstein*

*System Administrator*

Return Path, Inc.

8001 Arista Place, Suite 300

Broomfield, CO 80021

brant.hohnst...@returnpath.net mailto:brant.hohnst...@returnpath.net

+1 303-999-3233 tel:%2B1%20303-999-3233


--
389 users mailing list
389-users@lists.fedoraproject.org 
mailto:389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Problem - Could not import LDIF file '/ tmp / ldifESlBSW.ldif'. Error: 65280

[Marc Sauton]

On 07/21/2011 06:25 PM, mic...@casa.co.cu wrote:
 Marc Sauton msau...@redhat.com escribió:

 On 07/21/2011 03:04 PM, Michel Bulgado wrote:
 Hello

 Recently I just installed 389-ds-1.2.1-1.el5.noarch from EPEL repo,
 because in my company we use Active Directory and want to migrate to 
 Linux

 I have installed CentOS 5.6 x86_64.

 The problem persists when trying to run setup-ds-admin.pl and at the
 very end I get an error message.
 [11/07/21, 17:08:27] - [Setup] Info Are you ready to set-up your 
 servers?
 [11/07/21, 17:08:28] - [Setup] Info yes
 [11/07/21, 17:08:28] - [Setup] Info Creating directory server. . .
 [11/07/21, 17:08:29] - [Setup] Info Could not import LDIF file '/ tmp /
 ldifESlBSW.ldif'. Error: 65280. Output: Importing data ...

 [11/07/21, 17:08:29] - [Setup] Fatal Error: Could not create directory
 server instance 'michel'.
 [11/07/21, 17:08:29] - [Setup] Fatal Exiting. . .
 Log file is '/ tmp/setup5jSSdH.log'

 Maybe you can help me, google searching for someone I saw the same
 problem happened to him and recommended him to move or delete the file
 10-presence.ldif directory schema, but that file does not exist in that
 directory.

 That I could be doing wrong?

 Thanks
 Michel
 -- 

 Review the file permissions for /tmp/ldifESlBSW.ldif, so that 
 ns-slapd can read it.
 And maybe review the output of /tmp/setup5jSSdH.log
 M.


 Hi

 The script  ran it as root, I do not understand how you may be unable 
 to import the file ldiff stored in /tmp as root who runs  the script 
 and also access any  system resource.

 It may be that you specify the user under which runs the 389-ds is 
 nobody?
Yes.
Try either
chown nobody:nobody /tmp/ldifESlBSW.ldif
or
chmod a+r /tmp/ldifESlBSW.ldif

If this is till a problem, what does the command
getenforce
returns?

and also:
id
ls -ldZ /tmp
ls -lZ /tmp/ldifESlBSW.ldif

M.

 I send you the log file generated by the script.

 Sorry for my english is very poor

 Michel

 --
 Webmail, servicio de correo electronico
 Casa de las Americas - La Habana, Cuba.

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] issues with 1.2.7.5

[Marc Sauton]

On Tue, 2010-12-21 at 16:50 -0500, Robert Viduya wrote:
 I'm having problems trying to get a clean install of 1.2.7.5 working.  We're 
 running RHEL5 and I have the EPEL5.4 repositories configured on it.  Yum 
 installed the following when I installed 389-ds:
 
 389-admin.x86_641.1.13-1.el5installed 
   
 389-admin-console.noarch1.1.5-1.el5 installed 
   
 389-admin-console-doc.noarch1.1.5-1.el5 installed 
   
 389-adminutil.x86_641.1.8-4.el5 installed 
   
 389-console.noarch  1.1.4-1.el5 installed 
   
 389-ds.noarch   1.2.1-1.el5 installed 
   
 389-ds-base.x86_64  1.2.7.5-1.el5   installed 
   
 389-ds-base-devel.x86_641.2.7.5-1.el5   installed 
   
 389-ds-console.noarch   1.2.3-1.el5 installed 
   
 389-ds-console-doc.noarch   1.2.3-1.el5 installed 
   
 389-dsgw.x86_64 1.1.5-1.el5 installed 
   
 idm-console-framework.noarch1.1.5-4.el5 installed 
   
 
 After installation, I ran /usr/sbin/setup-ds-admin.pl to set up the initial 
 configuration.  Immediately after that, if I run 389-console, login as 
 cn=Directory Manager, navigate to Directory Server window and then try to 
 open the Configuration tab, I get a dialog box that says: Insufficient 
 Permissions / The user cn=Directory Manager does not have permission to 
 perform this operation..  Clicking the OK button gets me a new login window, 
 but re-entering the Directory Manager credentials doesn't do anything.  All I 
 get is a blank page instead of what's supposed to be under the Configuration 
 tab.
 
 I've done the install a few times already to make sure I wasn't messing 
 things up.  There's nothing out of the ordinary in either the admin server 
 error log or the directory server error log.  The directory server access log 
 shows only a few err=32, all under ou=Global Preferences, which is probably 
 expected on a completely new install.
 
Check the access log file for the bind attempts, and
nsslapd-allow-anonymous-access in your dse.ldif
Try to click OK and provide pw if prompted again.
May be related to these reports:
https://bugzilla.redhat.com/show_bug.cgi?id=627906
https://bugzilla.redhat.com/show_bug.cgi?id=661116
If it the case, you may want to add a comment.

 The terminal window I ran 389-console shows a java stack trace, but only 
 after I click past the error dialog box:
 
 Exception in thread AWT-EventQueue-0 java.lang.NullPointerException
   at 
 com.netscape.admin.dirserv.panel.ServerSettingsPanel$ReferralText.show(Unknown
  Source)
   at com.netscape.admin.dirserv.panel.DSEntrySet.getAttributes(Unknown 
 Source)
   at com.netscape.admin.dirserv.panel.DSEntrySet.show(Unknown Source)
   at com.netscape.admin.dirserv.panel.BlankPanel.refresh(Unknown Source)
   at com.netscape.admin.dirserv.panel.BlankPanel.select(Unknown Source)
   at com.netscape.admin.dirserv.panel.ContainerPanel.stateChanged(Unknown 
 Source)
   at javax.swing.JTabbedPane.fireStateChanged(JTabbedPane.java:417)
   at 
 javax.swing.JTabbedPane$ModelListener.stateChanged(JTabbedPane.java:270)
   at 
 javax.swing.DefaultSingleSelectionModel.fireStateChanged(DefaultSingleSelectionModel.java:133)
   at 
 javax.swing.DefaultSingleSelectionModel.setSelectedIndex(DefaultSingleSelectionModel.java:67)
   at javax.swing.JTabbedPane.setSelectedIndexImpl(JTabbedPane.java:616)
   at javax.swing.JTabbedPane.setSelectedIndex(JTabbedPane.java:591)
   at javax.swing.JTabbedPane.insertTab(JTabbedPane.java:730)
   at javax.swing.JTabbedPane.addTab(JTabbedPane.java:797)
   at com.netscape.admin.dirserv.panel.DSTabbedPanel.addTab(Unknown Source)
   at com.netscape.admin.dirserv.panel.RootPanel.init(Unknown Source)
   at 
 com.netscape.admin.dirserv.node.RootResourceObject.getCustomPanel(Unknown 
 Source)
   at com.netscape.management.client.ResourceModel.getCustomPanel(Unknown 
 Source)
   at com.netscape.management.client.ResourcePage.valueChanged(Unknown 
 Source)
   at javax.swing.JTree.fireValueChanged(JTree.java:2826)
   at 
 javax.swing.JTree$TreeSelectionRedirector.valueChanged(JTree.java:3197)
   at 
 javax.swing.tree.DefaultTreeSelectionModel.fireValueChanged(DefaultTreeSelectionModel.java:646)
   at 
 javax.swing.tree.DefaultTreeSelectionModel.notifyPathChange(DefaultTreeSelectionModel.java:1095)
   at 
 javax.swing.tree.DefaultTreeSelectionModel.setSelectionPaths(DefaultTreeSelectionModel.java:304)
   at javax.swing.JTree.setSelectionPaths(JTree.java:1616)
   at javax.swing.JTree.setSelectionRows(JTree.java:1689)
   at