[389-users] Automatically delete "linked" objects

[Julian Kippels]

Hi,

I am looking for a way to automatically delete certain objects when I 
delete a user object. For example:

* I have a user uid=user1,ou=users,dc=test,dc=tld
* I have a role cn=xyz,ou=roles,dc=test,dc=tld
* This role has the following atribute:
  roleOccupant: uid=user1,ou=users,dc=test,dc=tld

I would like to delete the cn=xyz-object automatically when the 
uid=user1-object is deleted. Is there a way to do this server side, or 
do I have to implement it client side?


Thanks
Julian


smime.p7s
Description: Kryptografische S/MIME-Signatur
--
___
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: Permission of log files

[Julian Kippels]

Welp, just call for help and you find a way to help yourself.

I was only looking in the cockpit-webinterface for an option. I just 
found out that there is a configuration parameter I can set with dsconf 
in the cli called nsslapd-{access,error,…}log-mode= where I can do the 
exact thing I want to do.


Julian

Am 15.04.24 um 09:50 schrieb Julian Kippels:

Hi,

I am looking for a way to configure the default permission of the log 
files in /var/log/dirsrv//*
All the files there belong to dirsrv:dirsrv with the permission of 0600. 
I would like to have the default permission to be 0644 so that my 
external log-monitoring can access the files.


Julian

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



--
-
| | Julian Kippels
| | M.Sc. Informatik
| |
| | Zentrum für Informations- und Medientechnologie
| | Heinrich-Heine-Universität Düsseldorf
| | Universitätsstr. 1
| | Raum 25.41.O1.32
| | 40225 Düsseldorf / Germany
| |
| | Tel: +49-211-81-14920
| | mail: kipp...@hhu.de
-


smime.p7s
Description: Kryptografische S/MIME-Signatur
--
___
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] Permission of log files

[Julian Kippels]

Hi,

I am looking for a way to configure the default permission of the log 
files in /var/log/dirsrv//*
All the files there belong to dirsrv:dirsrv with the permission of 0600. 
I would like to have the default permission to be 0644 so that my 
external log-monitoring can access the files.


Julian


smime.p7s
Description: Kryptografische S/MIME-Signatur
--
___
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 freezes with deadlock

[Julian Kippels]

Hi Thierry,

> First you may install debuginfo it would help to get a better
> understanding what happens.

I will try to do that the next time it breaks. Unfortunately this is a 
production machine and I can't always take the time to do forensics. 
Sometimes I just have to quickly get it up running again and just 
restart the service completely. I have not yet found a way to trigger 
this in my lab environment.


> Do you know if it recovers after that high CPU peak ?

So far it has never recovered. I have seen the high CPU peak 7 or 8 
times now and it is always like this:

1. CPU usage peaks on 2 threads
2. Admin from external server tells me that his system cannot do LDAP 
operations anymore.
3. I try to do some ldapmodify operations, which succeed and get 
replicated correctly.

4. At this point there are 2 options:
  a. Both the admin from the external server and I restart our services 
which temporarily fixes the issue
  b. I don't restart my system and after a few hours (where the CPU 
peak does not go away) dirsrv completely freezes up and does not accept 
any connections anymore.


> Regarding the unindexed search, you may check if 'changeNumber' is
> indexed (equality). It looks related to a sync_repl search with no
> cookie or old cookie. The search is on a different backend than Thread
> 62, so there is no conflict between the sync_repl unindexed search and
> update on thread62.

The equality index is set for changeNumber. I will assume that this is a 
different "problem" and has nothing to do with the high cpu load and 
freezes and not look further into it for the time.


Kind regards
Julian

Am 12.09.23 um 14:21 schrieb Thierry Bordaz:

Hi Julian,

Difficult to say. I do not recall specific issue but I know we fixed 
several bugs in sync_repl.


First you may install debuginfo it would help to get a better 
understanding what happens.


The two threads are likely Thread 62 and trickle thread (2 to 6) because 
of intensive db page update.

Do you know if it recovers after that high CPU peak ?
A possibility would be a large update to write back to the changelog. 
You may retrieve the problematic csn in access log (during high cpu) and 
dump the update from the changelog with dbscan (-k).


Regarding the unindexed search, you may check if 'changeNumber' is 
indexed (equality). It looks related to a sync_repl search with no 
cookie or old cookie. The search is on a different backend than Thread 
62, so there is no conflict between the sync_repl unindexed search and 
update on thread62.


best regards
thierry

On 9/12/23 13:52, Julian Kippels wrote:

Hi,

there are two threads that are at 100% CPU utilisation. I did not 
start any admin task myself, maybe it is some built-in task that is 
doing this? Or could an unindexed search on the changelog be causing 
this?


I have noticed this message:
NOTICE - ldbm_back_search - Unindexed search: search 
base="cn=changelog" scope=1 filter="(changeNumber>=1)" conn=35871 op=1


There is an external server that is reading the changelog and syncing 
some stuff depending on that. I don't know why they are starting at 
changeNumber>=1, they probably should start way higher. If it is 
possible that this is the cause I will kick them to stop that ;)


I am running version 2.3.1 on Debian 12, installed from the Debian 
repositories.


Kind regards
Julian

Am 08.09.23 um 13:23 schrieb Thierry Bordaz:

Hi Julian,

It looks that an update (Thread 62) is either eating CPU either is 
blocked while update the changelog.
When it occurs could you run 'top -H -p ' to see if some thread 
are eating CPU.
Else (no cpu consumption), you may take a pstack and dump DB lock 
info (db_stat -N -C A -h /var/lib/dirsrv/db)


Did you run admin task (import/export/index...) before it occurred ?
What version are you running ?

best regards
Thierry

On 9/8/23 09:28, Julian Kippels wrote:

Hi,

it happened again and now I ran the gdb-command like Mark suggested. 
The Stacktrace is attached. Again I got this error message:


[07/Sep/2023:15:22:43.410333038 +0200] - ERR - ldbm_back_seq - 
deadlock retry BAD 1601, err=0 Unexpected dbimpl error code


and the remote program that called also stopped working at that time.

Thanks
Julian Kippels

Am 28.08.23 um 14:28 schrieb Thierry Bordaz:

Hi Julian,

I agree with Mark suggestion. If new connections are failing a 
pstack + error logged msg would be helpful.


Regarding the error logged. LDAP server relies on a database that, 
under pressure by multiple threads, may end into a db_lock 
deadlock. In such situation the DB, selects one deadlocking thread, 
returns a DB_Deadlock error to that thread while the others threads 
continue to proceed. This is very normal error that is caught by 
the server that simply retries to access the DB. If the same thread 
fails to many time, it stops retry and return a fatal error to the 
request.


In your case it reports code 1601 that is transien

[389-users] Re: 389-ds freezes with deadlock

[Julian Kippels]

Hi,

there are two threads that are at 100% CPU utilisation. I did not start 
any admin task myself, maybe it is some built-in task that is doing 
this? Or could an unindexed search on the changelog be causing this?


I have noticed this message:
NOTICE - ldbm_back_search - Unindexed search: search base="cn=changelog" 
scope=1 filter="(changeNumber>=1)" conn=35871 op=1


There is an external server that is reading the changelog and syncing 
some stuff depending on that. I don't know why they are starting at 
changeNumber>=1, they probably should start way higher. If it is 
possible that this is the cause I will kick them to stop that ;)


I am running version 2.3.1 on Debian 12, installed from the Debian 
repositories.


Kind regards
Julian

Am 08.09.23 um 13:23 schrieb Thierry Bordaz:

Hi Julian,

It looks that an update (Thread 62) is either eating CPU either is 
blocked while update the changelog.
When it occurs could you run 'top -H -p ' to see if some thread are 
eating CPU.
Else (no cpu consumption), you may take a pstack and dump DB lock info 
(db_stat -N -C A -h /var/lib/dirsrv/db)


Did you run admin task (import/export/index...) before it occurred ?
What version are you running ?

best regards
Thierry

On 9/8/23 09:28, Julian Kippels wrote:

Hi,

it happened again and now I ran the gdb-command like Mark suggested. 
The Stacktrace is attached. Again I got this error message:


[07/Sep/2023:15:22:43.410333038 +0200] - ERR - ldbm_back_seq - 
deadlock retry BAD 1601, err=0 Unexpected dbimpl error code


and the remote program that called also stopped working at that time.

Thanks
Julian Kippels

Am 28.08.23 um 14:28 schrieb Thierry Bordaz:

Hi Julian,

I agree with Mark suggestion. If new connections are failing a pstack 
+ error logged msg would be helpful.


Regarding the error logged. LDAP server relies on a database that, 
under pressure by multiple threads, may end into a db_lock deadlock. 
In such situation the DB, selects one deadlocking thread, returns a 
DB_Deadlock error to that thread while the others threads continue to 
proceed. This is very normal error that is caught by the server that 
simply retries to access the DB. If the same thread fails to many 
time, it stops retry and return a fatal error to the request.


In your case it reports code 1601 that is transient deadlock with 
retry. So the impacted request just retried and likely succeeded.


best regards
thierry

On 8/24/23 14:46, Mark Reynolds wrote:

Hi Julian,

It would be helpful to get a pstack/stacktrace so we can see where 
DS is stuck:


https://www.port389.org/docs/389ds/FAQ/faq.html#sts=Debugging%C2%A0Hangs

Thanks,
Mark

On 8/24/23 4:13 AM, Julian Kippels wrote:

Hi,

I am using 389-ds Version 2.3.1 and have encountered the same error 
twice in three days now. There are some MOD operations and then I 
get a line like this in the errors-log:


[23/Aug/2023:13:27:17.971884067 +0200] - ERR - ldbm_back_seq - 
deadlock retry BAD 1601, err=0 Unexpected dbimpl error code


After this the server keeps running, systemctl status says 
everything is fine, but new incoming connections are failing with 
timeouts.


Any advice would be welcome.

Thanks in advance
Julian Kippels

___
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 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
Fedo

[389-users] 389-ds freezes with deadlock

[Julian Kippels]

Hi,

I am using 389-ds Version 2.3.1 and have encountered the same error 
twice in three days now. There are some MOD operations and then I get a 
line like this in the errors-log:


[23/Aug/2023:13:27:17.971884067 +0200] - ERR - ldbm_back_seq - deadlock 
retry BAD 1601, err=0 Unexpected dbimpl error code


After this the server keeps running, systemctl status says everything is 
fine, but new incoming connections are failing with timeouts.


Any advice would be welcome.

Thanks in advance
Julian Kippels
--
-
| | Julian Kippels
| | M.Sc. Informatik
| |
| | Zentrum für Informations- und Medientechnologie
| | Heinrich-Heine-Universität Düsseldorf
| | Universitätsstr. 1
| | Raum 25.41.O1.32
| | 40225 Düsseldorf / Germany
| |
| | Tel: +49-211-81-14920
| | mail: kipp...@hhu.de
-


smime.p7s
Description: S/MIME Cryptographic Signature
___
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] Use dsconf to set nsslapd-lookthroughlimit

[Julian Kippels]

Hi,

I am looking for a way to set nsslapd-lookthroughlimit from 
cn=config,cn=ldbm database,cn=plugins,cn=config using dsconf. So far I 
have only found the way to stop the server and edit dse.ldif or maybe 
using ldapmodify.


Is there a way to do this using dsconf?

Thanks
Julian
___
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: Wrong password hash algorithm returned

[Julian Kippels]

No, the default password policy is set to SSHA, but it also was set to 
this before and then the hash had been upgraded to PBKDF2_SHA256. I 
don't quite know what to make of this, because when I look at the source 
code for version 1.4.4 in 389-ds-base/ldap/servers/slapd/pw.c lines 3520 
and 3550 it would seem to me that the hash should never have been 
updated to the wrong setting. But it defenitly did, else the radius 
server would have continued working.


I install my servers with an Ansible Playbook that contains the 
following task:


command: dsconf -D "cn=Directory Manager" -w '{{ 
vault_dirsrv_directory_manager_password }}' ldap://localhost pwpolicy 
set --pwdscheme=SSHA


And when I checked using cockpit it was set to SSHA, but still some 
accounts were set to PBKDF2_SHA256.


Julian

Am 24.11.22 um 12:19 schrieb Thierry Bordaz:
That looks weird, it should update the user password. Is PBKDF2_SHA256 
the default password policy ?


thierry

On 11/24/22 11:48, Julian Kippels wrote:
What exactly are the requirements for the hash upgrade to trigger? I 
have set up a test server, nsslapd-enable-upgrade-hash is set to "on" 
but I cannot get the hashes to convert from SSHA to PBKDF2_SHA256.


I do a bind with directory manager and search for testuser, which 
gives me the SSHA-Hash. Ihen I bind as testuser and perform a search. 
Then I bind as directory manager again and search for testuser again. 
The hash still remains as SSHA.


Julian

Am 22.11.22 um 15:30 schrieb Thierry Bordaz:


On 11/22/22 10:28, Julian Kippels wrote:

Hi Thierry,

that's a nasty catch…

On the one hand I think this is a nice feature to improve security, 
but on the other hand PBKDF2_SHA256 is the one algorithm that 
freeradius cannot cope with.


I suppose there is no way to revert all changed hashes after I set 
"nsslapd-enable-upgrade-hash" to "off"? Other than to reinitialize 
all affected suffixes from the export of the old servers?



Indeed this is a bad side effect of the default value :(

If you need to urgently fix those new {PBKDF2_SHA256}, then reinit is 
the way to go. Else you could change the default password storage to 
SSHA and keep nsslapd-enable-upgrade-hash=on. So that it will revert, 
on bind, to the SSHA hash.


thierry



Julian

Am 22.11.22 um 09:56 schrieb Thierry Bordaz:

Hi Julian,

This is likely the impact of 
https://github.com/389ds/389-ds-base/issues/2480 that was 
introduced in 1.4.x.


On 1.4.4 default hash is PBKDF2, this ticket upgrade hash of user 
entries during the user bind (enabled with 
nsslapd-enable-upgrade-hash).


best regards
thierry

On 11/22/22 09:25, Julian Kippels wrote:

Hi,

We have a radius server that reads the userPassword-attribute from 
ldap to authenticate users. There is a strange phenomenon where 
sometimes the answer from the ldap-server gives the wrong password 
hash algorithm. Our global password policy storage scheme is set 
to SSHA. When I perform a ldapsearch as directory manager I see 
that the password hash for a given user is 
{SSHA}inserthashedpasswordhere. But when I run tcpdump to see what 
our radius is being served I see {PBKDF2_SHA256}someotherhash 
around 50% of the time. Sometime another request from radius a few 
seconds after the first one gives the correct {SSHA} response.


This happened right after we updated from 389ds 1.2.2 to 1.4.4.
I am a bit stumped.

Thanks in advance,
Julian
___
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








--
---------
| | Julian Kippels
| | M.Sc. Informatik
| |
| | Zentrum für Informations- und Medientechnologie
| | Heinrich-Heine-Universität Düsseldorf
| | Universitätsstr. 1
| | Raum 25.41.O1.32
| | 40225 Düsseldorf / Germany
| |
| | Tel: +49-211-81-14920
| | mail: kipp...@hhu.de
-
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To u

[389-users] Re: Wrong password hash algorithm returned

[Julian Kippels]

What exactly are the requirements for the hash upgrade to trigger? I 
have set up a test server, nsslapd-enable-upgrade-hash is set to "on" 
but I cannot get the hashes to convert from SSHA to PBKDF2_SHA256.


I do a bind with directory manager and search for testuser, which gives 
me the SSHA-Hash. Ihen I bind as testuser and perform a search. Then I 
bind as directory manager again and search for testuser again. The hash 
still remains as SSHA.


Julian

Am 22.11.22 um 15:30 schrieb Thierry Bordaz:


On 11/22/22 10:28, Julian Kippels wrote:

Hi Thierry,

that's a nasty catch…

On the one hand I think this is a nice feature to improve security, 
but on the other hand PBKDF2_SHA256 is the one algorithm that 
freeradius cannot cope with.


I suppose there is no way to revert all changed hashes after I set 
"nsslapd-enable-upgrade-hash" to "off"? Other than to reinitialize all 
affected suffixes from the export of the old servers?



Indeed this is a bad side effect of the default value :(

If you need to urgently fix those new {PBKDF2_SHA256}, then reinit is 
the way to go. Else you could change the default password storage to 
SSHA and keep nsslapd-enable-upgrade-hash=on. So that it will revert, on 
bind, to the SSHA hash.


thierry



Julian

Am 22.11.22 um 09:56 schrieb Thierry Bordaz:

Hi Julian,

This is likely the impact of 
https://github.com/389ds/389-ds-base/issues/2480 that was introduced 
in 1.4.x.


On 1.4.4 default hash is PBKDF2, this ticket upgrade hash of user 
entries during the user bind (enabled with nsslapd-enable-upgrade-hash).


best regards
thierry

On 11/22/22 09:25, Julian Kippels wrote:

Hi,

We have a radius server that reads the userPassword-attribute from 
ldap to authenticate users. There is a strange phenomenon where 
sometimes the answer from the ldap-server gives the wrong password 
hash algorithm. Our global password policy storage scheme is set to 
SSHA. When I perform a ldapsearch as directory manager I see that 
the password hash for a given user is 
{SSHA}inserthashedpasswordhere. But when I run tcpdump to see what 
our radius is being served I see {PBKDF2_SHA256}someotherhash around 
50% of the time. Sometime another request from radius a few seconds 
after the first one gives the correct {SSHA} response.


This happened right after we updated from 389ds 1.2.2 to 1.4.4.
I am a bit stumped.

Thanks in advance,
Julian
___
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




--
---------
| | Julian Kippels
| | M.Sc. Informatik
| |
| | Zentrum für Informations- und Medientechnologie
| | Heinrich-Heine-Universität Düsseldorf
| | Universitätsstr. 1
| | Raum 25.41.O1.32
| | 40225 Düsseldorf / Germany
| |
| | Tel: +49-211-81-14920
| | mail: kipp...@hhu.de
-
___
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: Wrong password hash algorithm returned

[Julian Kippels]

Hi Thierry,

that's a nasty catch…

On the one hand I think this is a nice feature to improve security, but 
on the other hand PBKDF2_SHA256 is the one algorithm that freeradius 
cannot cope with.


I suppose there is no way to revert all changed hashes after I set 
"nsslapd-enable-upgrade-hash" to "off"? Other than to reinitialize all 
affected suffixes from the export of the old servers?


Julian

Am 22.11.22 um 09:56 schrieb Thierry Bordaz:

Hi Julian,

This is likely the impact of 
https://github.com/389ds/389-ds-base/issues/2480 that was introduced in 
1.4.x.


On 1.4.4 default hash is PBKDF2, this ticket upgrade hash of user 
entries during the user bind (enabled with nsslapd-enable-upgrade-hash).


best regards
thierry

On 11/22/22 09:25, Julian Kippels wrote:

Hi,

We have a radius server that reads the userPassword-attribute from 
ldap to authenticate users. There is a strange phenomenon where 
sometimes the answer from the ldap-server gives the wrong password 
hash algorithm. Our global password policy storage scheme is set to 
SSHA. When I perform a ldapsearch as directory manager I see that the 
password hash for a given user is {SSHA}inserthashedpasswordhere. But 
when I run tcpdump to see what our radius is being served I see 
{PBKDF2_SHA256}someotherhash around 50% of the time. Sometime another 
request from radius a few seconds after the first one gives the 
correct {SSHA} response.


This happened right after we updated from 389ds 1.2.2 to 1.4.4.
I am a bit stumped.

Thanks in advance,
Julian
___
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] Wrong password hash algorithm returned

[Julian Kippels]

Hi,

We have a radius server that reads the userPassword-attribute from ldap 
to authenticate users. There is a strange phenomenon where sometimes the 
answer from the ldap-server gives the wrong password hash algorithm. Our 
global password policy storage scheme is set to SSHA. When I perform a 
ldapsearch as directory manager I see that the password hash for a given 
user is {SSHA}inserthashedpasswordhere. But when I run tcpdump to see 
what our radius is being served I see {PBKDF2_SHA256}someotherhash 
around 50% of the time. Sometime another request from radius a few 
seconds after the first one gives the correct {SSHA} response.


This happened right after we updated from 389ds 1.2.2 to 1.4.4.
I am a bit stumped.

Thanks in advance,
Julian
___
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: Upgrading from 1.2.2 to 1.4.4

[Julian Kippels]

Hi,

Am Tue, 8 Nov 2022 16:39:20 -0500
schrieb Mark Reynolds :

> How did you generate these ldifs?  Did you use db2ldif, or
> ldapsearch? If you used ldapsearch, then stop.  Please use
> db2ldif/db2ldif.pl

I created the ldifs using the Java 389-console, loggin in as directory
manager and using the "Export Databases"-Task on the master server.
What's weird about this is, I closed and reopened 398-console, did the
exact same steps to create the ldifs and now those attributes are gone
from the ldif. I will look into using db2ldif anyway. Thanks for the
suggestion.

Julian
___
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] Upgrading from 1.2.2 to 1.4.4

[Julian Kippels]

Hi,

I am currently in the process of moving our LDAP-Servers from old
CentOS 7 Servers to new Debian 11 Servers. In the process I am
exporting all databases from the old server to ldif files and importing
those files on the new server.

When I import such a file I get a lot (basically for every single entry)
of warnings and errors in the errors-log like the following:

[08/Nov/2022:21:01:52.272475719 +0100] - ERR - oc_check_allowed_sv - Entry 
"cn=219058,ou=accounts,o=demo" -- attribute "entrylevelrights" not allowed
[08/Nov/2022:21:01:52.273547001 +0100] - WARN - import_producer - import demo: 
Skipping entry "cn=219058,ou=accounts,o=demo" which violates schema, ending 
line 9232514 of file "/var/lib/dirsrv/slapd-ldap-master/ldif/demo.ldif"

I can't make heads or tails of this. I exported the ldif using the
389-console using "Export Databases" and I import them via Cockpit
using "Initialize Suffix" for the Suffix o=demo

I cannot find this attribute in any schema-file on either the old or
the new servers. Where does this come from, and how do I solve this
issue?

Thanks in advance
Julian

___
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: SizeLimit Exceeded although Limit should be much higher

[Julian Kippels]

Hi,

Am Thu, 13 Feb 2020 08:05:04 -0500
schrieb Mark Reynolds :

> On 2/13/20 5:37 AM, Julian Kippels wrote:
> > Hi,
> >
> > I am having a small problem with a slightly larger lookup. The
> > SizeLimit and LookthroughLimit are both set to 30, but when I
> > do a larger search, I still get:  
> 
> Did you restart the server after setting these limits?

Yes, the server was restarted several times after setting the limits.

> 
> What is the exact ldapsearch cpmmand you ran to reproduce this error?
> 
> >  
> >> # search result
> >> search: 2
> >> result: 4 Size limit exceeded
> >>
> >> # numResponses: 50001
> >> # numEntries: 5  

ldapsearch -x -D "cn=metauser,o=dept1" -W -H ldaps://ldaphost -b
"ou=person,o=dept1" '(modifytimestamp>=20200212094321Z)'

> 
> Can you run this search please:
> 
> ldapsearch -D "cn=directory manager" -W -b cn=config -s base 
> nsslapd-sizelimit

# extended LDIF
#
# LDAPv3
# base  with scope baseObject
# filter: (objectclass=*)
# requesting: nsslapd-sizelimit 
#

# config
dn: cn=config
nsslapd-sizelimit: 30

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

> 
> Who are you authenticating as to do the search?  Do you have any 
> resource limits set on that entry?  Is "nsSizeLimit" set in their
> entry?

The entry of the bind user looks like this:
cn=metauser,o=dept1
objectClass: top
objectClass: Person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: metauser
sn: metauser
uid: metauser
userPassword: xxx

> 
> Thanks,
> 
> Mark
> |//|||
> 
> ||
> 
> /||/
> > Where else could I look for limits, that could be applicable here?
> > I am using 389-ds version 1.2.2. The search in question is in a
> > base that has around 55000 Entries and the filter is something like
> > (modifytimestamp>$oldtimestamp). The modifytimestamp-attribute is  
> > indexed for presence and equality.
> >
> > Thanks
> > Julian
> > ___
> > 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
> >  
> 



-- 
-
| | Julian Kippels
| | M.Sc. Informatik
| |
| | Zentrum für Informations- und Medientechnologie
| | Heinrich-Heine-Universität Düsseldorf
| | Universitätsstr. 1
| | Raum 25.41.O1.32
| | 40225 Düsseldorf / Germany
| |
| | Tel: +49-211-81-14920
| | mail: kipp...@hhu.de
-
___
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] SizeLimit Exceeded although Limit should be much higher

[Julian Kippels]

Hi,

I am having a small problem with a slightly larger lookup. The
SizeLimit and LookthroughLimit are both set to 30, but when I do a
larger search, I still get:

> # search result
> search: 2
> result: 4 Size limit exceeded
>
> # numResponses: 50001
> # numEntries: 5

Where else could I look for limits, that could be applicable here? I am
using 389-ds version 1.2.2. The search in question is in a base that
has around 55000 Entries and the filter is something like
(modifytimestamp>$oldtimestamp). The modifytimestamp-attribute is
indexed for presence and equality.

Thanks
Julian
___
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: When 389ds will be available on CentOS 8

[Julian Kippels]

Am Mon, 7 Oct 2019 12:06:59 +0100
schrieb wodel youchi :

> Hi,
> 
> Is there any news about the availability of 389DS on CentOS8?
> 
> Regards.

It should be already available, you just need to subscribe to the
389-ds-stream.

-- 
---------
| | Julian Kippels
| | M.Sc. Informatik
| |
| | Zentrum für Informations- und Medientechnologie
| | Heinrich-Heine-Universität Düsseldorf
| | Universitätsstr. 1
| | Raum 25.41.O1.32
| | 40225 Düsseldorf / Germany
| |
| | Tel: +49-211-81-14920
| | mail: kipp...@hhu.de
-
___
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: Cannot login to admin server after last update

[Julian Kippels]

Am Thu, 15 Mar 2018 16:25:41 -0400
schrieb Mark Reynolds <mreyno...@redhat.com>:

> On 03/15/2018 04:11 PM, Julian Kippels wrote:
> > Am Thu, 15 Mar 2018 12:00:06 -0400
> > schrieb Mark Reynolds <mreyno...@redhat.com>:
> >  
> >> On 03/15/2018 11:36 AM, Julian Kippels wrote:  
> >>> Hi,
> >>>
> >>> since the last update (using RHEL 7, updated from
> >>> 389-ds-1.3.6.1-21 to 389-ds-1.3.6.1-28) I cannot login as user
> >>> admin in the administration console anymore.
> >>>
> >>> Looking at the logs I see this error message popping up every
> >>> time I try to log in since then:
> >>>
> >>> [Thu Mar 15 13:09:35.046721 2018] [:crit] [pid 12027:tid
> >>> 140250663868160] buildUGInfo(): unable to initialize TLS
> >>> connection to LDAP host ldap-master.rz.uni-duesseldorf.de port
> >>> 389: 4
> >>>
> >>> What I find confusing, nowhere have I ever configured any
> >>> encrypted connections, because the whole setup is tucked away in
> >>> a private vlan with no access to the internet. How come the admin
> >>> server suddenly wants to use TLS? And how can I disable this and
> >>> get back the old behaviour?
> >> This is odd since you did not update the admin server (in fact
> >> there have not been any admin server updates in some time).
> >>
> >> What error is the console login page reporting?  
> > "Cannot connect to the directory server:
> > netscape.ldap.LDAPException: error result (49): Invalid
> > credentials"  
> Okay, so the problem appears that you are not providing a bind DN in
> the console login page.  What user ID are you using to log into the
> console? 
> 
> [15/Mar/2018:13:09:35.051526124 +0100] conn=286293 op=0 BIND
> dn="(anon)" method=128 version=3 [15/Mar/2018:13:09:35.051658717
> +0100] conn=286293 op=0 RESULT err=49 tag=97 nentries=0 etime=0 - No
> suffix for bind dn found
> 
> 
> Or you might be using a "user" name, like "admin", and not a DN
> (uid=admin,...,o=netscaperoot) and it's not finding the user.  You did
> not provide enough of the access log to confirm.
> 

I am using the username "admin". This has worked before. I had to
heavily truncate the access log, because it is my main production
machine. The setup in my test lab did not break in this way and there I
can login using "admin".
However, those three lines of access log are the only ones I can
identify belonging to the admin-server login procedure. What else
should I look for?

> What if you try to log in as "cn=directory manager", does it work?

No, this doesn't work either. I get another error message from the
console:
"Cannot logon because of an incorrect User ID.
Incorrect password or Directory problem.

HttpException:
Response: HTTP/1.1 401 Unauthorized
Status: 401
URL: http://ldap-master.rz.uni-duesseldorf.de:9830/admin-serv/authenticate;

Directory access log gives the same output as before, again with 
dn="(anon)"

Directory error log remains empty

Admin Server access log says:
192.168.25.114 - cn=directory manager [16/Mar/2018:10:23:33 +0100] "GET 
/admin-serv/authenticate HTTP/1.0" 401 470

Admin Server error log says:
[Fri Mar 16 10:23:33.977051 2018] [:error] [pid 11147:tid 139866994099968] 
Could not bind as [cn=directory manager]: ldap error -1: Can't contact LDAP 
server
[Fri Mar 16 10:23:33.977908 2018] [:error] [pid 11147:tid 139866994099968] 
Could not bind as [cn=directory manager]: ldap error -1: Can't contact LDAP 
server
[Fri Mar 16 10:23:33.979140 2018] [:crit] [pid 11147:tid 139866994099968] 
buildUGInfo(): unable to initialize TLS connection to LDAP host 
ldap-master.rz.uni-duesseldorf.de port 389: 4
[Fri Mar 16 10:23:33.979205 2018] [auth_basic:error] [pid 11147:tid
139866994099968] [client 192.168.25.114:34904] AH01618: user
cn=directory manager not found: /admin-serv/authenticate

Output from 389-console -D 9 with user "cn=directory manager":
java.util.prefs.userRoot=/home/julkip/.389-console
java.runtime.name=OpenJDK Runtime Environment
sun.boot.library.path=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.151-1.b12.el7_4.x86_64/jre/lib/amd64
java.vm.version=25.151-b12
java.vm.vendor=Oracle Corporation
java.vendor.url=http://java.oracle.com/
path.separator=:
java.vm.name=OpenJDK 64-Bit Server VM
file.encoding.pkg=sun.io
user.country=DE
sun.java.launcher=SUN_STANDARD
sun.os.patch.level=unknown
java.vm.specification.name=Java Virtual Machine Specification
user.dir=/home/julkip
java.runtime.version=1.8.0_151-b12
java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment
java.endorsed.dirs=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.151-1.b12.el7_4.x86_64

[389-users] Cannot login to admin server after last update

[Julian Kippels]

Hi,

since the last update (using RHEL 7, updated from 389-ds-1.3.6.1-21 to
389-ds-1.3.6.1-28) I cannot login as user admin in the administration
console anymore.

Looking at the logs I see this error message popping up every time I
try to log in since then:

[Thu Mar 15 13:09:35.046721 2018] [:crit] [pid 12027:tid 140250663868160] 
buildUGInfo(): unable to initialize TLS connection to LDAP host 
ldap-master.rz.uni-duesseldorf.de port 389: 4

What I find confusing, nowhere have I ever configured any encrypted
connections, because the whole setup is tucked away in a private vlan with
no access to the internet. How come the admin server suddenly wants
to use TLS? And how can I disable this and get back the old behaviour?

Thanks in advance
Julian
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Configuring single-master replication from the cli

[Julian Kippels]

Am Fri, 09 Mar 2018 17:23:39 +0100
schrieb Ludwig Krispenz :

> did you look into chapter 15.2:  Configuring Replication from the 
> Command Line ?
> 

Somehow I feel incredibly stupid right now…
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Configuring single-master replication from the cli

[Julian Kippels]

Hi

Is it possible to configure single master replication from the cli? In
the documentation it is only described using the admin-server interface:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/Managing_Replication-Configuring_Single_Master_Replication

I would like to be able to automate this step, hence I need a way to do
this in a scriptable way.

Thanks,
Julian
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Possible bug? - Silent install behaves differently from interactive

[Julian Kippels]

Hi Morgan,

your mail arrived one day late for me, it seems that the
fedora mailman-server held it for some time before releasing it.

You seem to have found the solution. When I ran the setup interactively
with --keepcache the SlapdConfigForMC option was not set at all for the
slave. If I manually set it in the inf-file to "no" it all works as
intended. I'm just curious as to why the --keepcache-option would
produce an output that does not reproduce my input…

In the meantime I had it working with an except-script. If anyone for
any reason would like to use this over a silent install I'm going to
add my ansible template for it here:

#!/usr/bin/expect -f
spawn setup-ds-admin.pl
expect "continue with set up"
send "yes\r"
expect "Would you like to continue"
send "yes\r"
expect "Choose a setup type"
send "2\r"
expect "Computer name"
send "\r"
expect "System User"
send "\r"
expect "System Group"
send "\r"
expect "configuration directory server"
{% if dirsrv_mode == "master" %}
send "no\r"
expect "administrator ID"
send "\r"
expect "Password"
send "{{ vault_dirsrv_admin_server_password }}\r"
expect "Password (confirm)"
send "{{ vault_dirsrv_admin_server_password }}\r"
expect "Administration Domain"
send "\r"
{% else %}
send "yes\r"
expect "Configuration directory server URL"
send "ldap://{{ dirsrv_config_host }}:389/o=NetscapeRoot\r"
expect "Configuration directory server admin ID"
send "\r"
expect "Configuration directory server admin password"
send "{{ vault_dirsrv_admin_server_password }}\r"
expect "Configuration directory server admin domain"
send "\r"
{% endif %}
expect "Directory server network port"
send "389\r"
expect "Directory server identifier"
send "\r"
expect "Suffix"
send "\r"
expect "Directory Manager DN"
send "\r"
expect "Password"
send "{{ vault_dirsrv_directory_manager_password }}\r"
expect "Password (confirm)"
send "{{ vault_dirsrv_directory_manager_password }}\r"
expect "Administration port"
send "\r"
expect "Are you ready to set up your servers"
send "\r"
expect "Log file is"
send_user "$expect_out(buffer)"
exit 0

Julian

Am Mon, 18 Sep 2017 16:41:46 -0400
schrieb Morgan Jones <mor...@morganjones.org>:

> Hello Julian et al,
> 
> I’ve resolved my unrelated issues and now I'm pretty sure the process
> to install several servers with a common config host using inf files
> is this.  I’d love some feedback from others if you feel this is
> wrong, this is just from trial and error on my part and it’s not
> particularly intuitive:
> 
> Do an install with setup-ds-admin.pl —keepcache
> 
> Take the resulting .inf and change:
> SlapdConfigForMC = yes on the server you want to install the config
> tree, SlapdConfigForMC = no on the rest, and
> UseExistingMC = 0 on the server you want to install the config tree,
> and UseExistingMC = 1 on the rest and
> 
> Also put adm.conf at /etc/dirsrv/admin-serv/adm.conf.
> 
> Here’s an update to the links below, I renamed the .inf template.
> These should be immutable:
> https://github.com/morganllj/ansible-playbooks/blob/3bf0fa9ee5c69c10940eaa2163b6d69155767475/templates/389_install.inf.j2
> https://github.com/morganllj/ansible-playbooks/blob/3bf0fa9ee5c69c10940eaa2163b6d69155767475/templates/adm.conf.j2
> https://github.com/morganllj/ansible-playbooks/blob/3bf0fa9ee5c69c10940eaa2163b6d69155767475/install_389.yml
> 
> -morgan
> 
> 
> 
> 
> > On Sep 15, 2017, at 12:56 PM, Morgan Jones <mor...@morganjones.org>
> > wrote:
> > 
> > Hello Julia,
> > 
> > I’m troubleshooting this exact behavior.  So far I’ve found if you
> > create an /etc/dirsrv/admin-serv/adm.conf before the silent install
> > it works.  However we just went through a host domain name change
> > (long story) and I’m having I think unrelated problems.  I hope to
> > resolve that shortly and then I might have a more definitive answer.
> > 
> > In the mean time this may be helpful to you:
> > https://github.com/morganllj/ansible-playbooks/blob/develop/templates/389_primary_master_setup.inf.j2
> > https://github.com/morganllj/ansible-playbooks/blob/develop/templates/adm.conf.j2
> > 
> > Here’s where they’re used if you are familiar with ansible:
> > https://github.com/morganllj/ansible-playbooks/blob/develop/install_389.yml
> > 
> > -morgan
> > 
> >   
> >> On Sep 15, 

[389-users] Re: Possible bug? - Silent install behaves differently from interactive

[Julian Kippels]

Hi,

I have tested this and have found that any entries
in /etc/dirsrv/admin-serv/adm.conf get overridden by the install
script. I have adapted your template to work with my own ansible
playbook and after setup-ds-admin.pl ran, the value for ldapurl has
changed to the local hostname instead of the hostname for the config
host. Additionaly the ConfigDirectoryLdapURL parameter from the
inf-File seems to be ignored. Even if I set it to the correct config
host hostname the local hostname is being used eventually.

My current plan is to ditch the silent install completely in favor of
an expect-script that would send the input to an interactive run of
setup-ds-admin.pl. However I think that this is a really clunky fix and
I would really like to get it working with the silent install.

Julian

Am Fri, 15 Sep 2017 12:56:07 -0400
schrieb Morgan Jones <mor...@morganjones.org>:

> Hello Julia,
> 
> I’m troubleshooting this exact behavior.  So far I’ve found if you
> create an /etc/dirsrv/admin-serv/adm.conf before the silent install
> it works.  However we just went through a host domain name change
> (long story) and I’m having I think unrelated problems.  I hope to
> resolve that shortly and then I might have a more definitive answer.
> 
> In the mean time this may be helpful to you:
> https://github.com/morganllj/ansible-playbooks/blob/develop/templates/389_primary_master_setup.inf.j2
> https://github.com/morganllj/ansible-playbooks/blob/develop/templates/adm.conf.j2
> 
> Here’s where they’re used if you are familiar with ansible:
> https://github.com/morganllj/ansible-playbooks/blob/develop/install_389.yml
> 
> -morgan
> 
> 
> > On Sep 15, 2017, at 11:49 AM, Julian Kippels <kipp...@hhu.de> wrote:
> > 
> > Hi,
> > 
> > I was playing around with silent installs and found out that the
> > final configuration differs from interactive installations. Here is
> > what I did:
> > 
> > I installed two servers on different machines ds-1.localdomain and
> > ds-2.localdomain. ds-1 is used as a master and ds-2 is supposed to
> > use it as its configuration server.
> > Both machines run RHEL 7.4 with the latest EPEL-builds of 389-ds.
> > 
> > First I used setup-ds-admin.pl --keepcache interactively first on
> > ds-1 and told it not to use an existing configuration server, then
> > on ds-2 and told it to use ds-1. When I connect to ds-1 using
> > 389-console I can see both ds-1 and ds-2.
> > Then I took the generated .inf-files, removed all traces from the
> > previous instances from both machines using remove-ds-admin.pl -a
> > -f -y and then ran setup-ds-admin.pl --silent --file=ds-1.inf and
> > --file=ds-2.inf respectively. When I connect to ds-1 now, I only see
> > ds-1, to see ds-2 I have to connect to ds-2 with 389-console.
> > 
> > The .inf-files look like this:
> > 
> > $ cat ds-1.inf
> > [General]
> > AdminDomain = localdomain
> > ConfigDirectoryAdminID = admin
> > ConfigDirectoryAdminPwd = XXX
> > ConfigDirectoryLdapURL = ldap://ds-1.localdomain:389/o=NetscapeRoot
> > FullMachineName = ds-1.localdomain
> > ServerRoot = /usr/lib64/dirsrv
> > StrictHostCheck = true
> > SuiteSpotGroup = dirsrv
> > SuiteSpotUserID = dirsrv
> > [admin]
> > Port = 9830
> > ServerAdminID = admin
> > ServerAdminPwd = XXX
> > ServerIpAddress = 0.0.0.0
> > SysUser = dirsrv
> > [slapd]
> > start_server = 0
> > AddOrgEntries = Yes
> > AddSampleEntries = No
> > HashedRootDNPwd = XXX
> > InstScriptsEnabled = true
> > InstallLdifFile = suggest
> > RootDN = cn=Directory Manager
> > RootDNPwd = XXX
> > ServerIdentifier = ds-1
> > ServerPort = 389
> > SlapdConfigForMC = yes
> > Suffix = dc=localdomain
> > UseExistingMC = 0
> > bak_dir = /var/lib/dirsrv/slapd-ds-1/bak
> > bindir = /usr/bin
> > cert_dir = /etc/dirsrv/slapd-ds-1
> > config_dir = /etc/dirsrv/slapd-ds-1
> > datadir = /usr/share
> > db_dir = /var/lib/dirsrv/slapd-ds-1/db
> > ds_bename = userRoot
> > inst_dir = /usr/lib64/dirsrv/slapd-ds-1
> > ldif_dir = /var/lib/dirsrv/slapd-ds-1/ldif
> > localstatedir = /var
> > lock_dir = /var/lock/dirsrv/slapd-ds-1
> > log_dir = /var/log/dirsrv/slapd-ds-1
> > naming_value = rz
> > run_dir = /var/run/dirsrv
> > sbindir = /usr/sbin
> > schema_dir = /etc/dirsrv/slapd-ds-1/schema
> > sysconfdir = /etc
> > tmp_dir = /tmp
> > 
> > $ cat ds-2.inf
> > [General]
> > AdminDomain = localdomain
> > ConfigDirectoryAdminID = admin
> > ConfigDirectoryAdminPwd = XXX
> > ConfigDirectoryLdapURL = ldap://d

[389-users] Possible bug? - Silent install behaves differently from interactive

[Julian Kippels]

Hi,

I was playing around with silent installs and found out that the final
configuration differs from interactive installations. Here is what I
did:

I installed two servers on different machines ds-1.localdomain and
ds-2.localdomain. ds-1 is used as a master and ds-2 is supposed to use
it as its configuration server.
Both machines run RHEL 7.4 with the latest EPEL-builds of 389-ds.

First I used setup-ds-admin.pl --keepcache interactively first on ds-1
and told it not to use an existing configuration server, then on ds-2
and told it to use ds-1. When I connect to ds-1 using 389-console I can
see both ds-1 and ds-2.
Then I took the generated .inf-files, removed all traces from the
previous instances from both machines using remove-ds-admin.pl -a -f -y
and then ran setup-ds-admin.pl --silent --file=ds-1.inf and
--file=ds-2.inf respectively. When I connect to ds-1 now, I only see
ds-1, to see ds-2 I have to connect to ds-2 with 389-console.

The .inf-files look like this:

$ cat ds-1.inf
[General]
AdminDomain = localdomain
ConfigDirectoryAdminID = admin
ConfigDirectoryAdminPwd = XXX
ConfigDirectoryLdapURL = ldap://ds-1.localdomain:389/o=NetscapeRoot
FullMachineName = ds-1.localdomain
ServerRoot = /usr/lib64/dirsrv
StrictHostCheck = true
SuiteSpotGroup = dirsrv
SuiteSpotUserID = dirsrv
[admin]
Port = 9830
ServerAdminID = admin
ServerAdminPwd = XXX
ServerIpAddress = 0.0.0.0
SysUser = dirsrv
[slapd]
start_server = 0
AddOrgEntries = Yes
AddSampleEntries = No
HashedRootDNPwd = XXX
InstScriptsEnabled = true
InstallLdifFile = suggest
RootDN = cn=Directory Manager
RootDNPwd = XXX
ServerIdentifier = ds-1
ServerPort = 389
SlapdConfigForMC = yes
Suffix = dc=localdomain
UseExistingMC = 0
bak_dir = /var/lib/dirsrv/slapd-ds-1/bak
bindir = /usr/bin
cert_dir = /etc/dirsrv/slapd-ds-1
config_dir = /etc/dirsrv/slapd-ds-1
datadir = /usr/share
db_dir = /var/lib/dirsrv/slapd-ds-1/db
ds_bename = userRoot
inst_dir = /usr/lib64/dirsrv/slapd-ds-1
ldif_dir = /var/lib/dirsrv/slapd-ds-1/ldif
localstatedir = /var
lock_dir = /var/lock/dirsrv/slapd-ds-1
log_dir = /var/log/dirsrv/slapd-ds-1
naming_value = rz
run_dir = /var/run/dirsrv
sbindir = /usr/sbin
schema_dir = /etc/dirsrv/slapd-ds-1/schema
sysconfdir = /etc
tmp_dir = /tmp

$ cat ds-2.inf
[General]
AdminDomain = localdomain
ConfigDirectoryAdminID = admin
ConfigDirectoryAdminPwd = XXX
ConfigDirectoryLdapURL = ldap://ds-1.localdomain:389/o=NetscapeRoot
FullMachineName = ds-2.localdomain
ServerRoot = /usr/lib64/dirsrv
StrictHostCheck = true
SuiteSpotGroup = dirsrv
SuiteSpotUserID = dirsrv
[admin]
Port = 9830
ServerAdminID = admin
ServerAdminPwd = XXX
ServerIpAddress = 0.0.0.0
SysUser = dirsrv
[slapd]
AddOrgEntries = Yes
AddSampleEntries = No
HashedRootDNPwd = XXX
InstScriptsEnabled = true
InstallLdifFile = suggest
RootDN = cn=Directory Manager
RootDNPwd = XXX
ServerIdentifier = ds-2
ServerPort = 389
Suffix = dc=localdomain
UseExistingMC = 1
bak_dir = /var/lib/dirsrv/slapd-ds-2/bak
bindir = /usr/bin
cert_dir = /etc/dirsrv/slapd-ds-2
config_dir = /etc/dirsrv/slapd-ds-2
datadir = /usr/share
db_dir = /var/lib/dirsrv/slapd-ds-2/db
ds_bename = userRoot
inst_dir = /usr/lib64/dirsrv/slapd-ds-2
ldif_dir = /var/lib/dirsrv/slapd-ds-2/ldif
localstatedir = /var
lock_dir = /var/lock/dirsrv/slapd-ds-2
log_dir = /var/log/dirsrv/slapd-ds-2
naming_value = rz
run_dir = /var/run/dirsrv
sbindir = /usr/sbin
schema_dir = /etc/dirsrv/slapd-ds-2/schema
sysconfdir = /etc
tmp_dir = /tmp

I think this unintended behaviour and should be fixed. Unless I did a
mistake somewhere, but I can't see where…

Julian
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Generating Performance Metrics

[Julian Kippels]

Hi,

does anyone have an idea what would be the best way to retroactivaley
generate performance metrics using the logfiles?
I would like to be able to check for example if in a certain time range
there were binds or searches that took longer than usual.

Thanks
Julian
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: 389ds gets killed for memory usage

[Julian Kippels]

Hi Mark,

thank you for your suggestion. This has helped reducing the memory usage
tremendously.

Julian

On Mon, Sep 26, 2016 at 11:03:43AM -0400, Mark Reynolds wrote:
> Hi Julian,
> 
> I suggest you an alternative memory allocator (tcmalloc).
> 
> Install the "gperftools-libs" package.  Then edit /etc/sysconfig/dirsrv
> and add this line at the bottom:
> 
> LD_PRELOAD=/usr/lib64/libtcmalloc.so.4
> 
> If you are _not_ using systemd (but you probably are), then also add:
> "export LD_PRELOAD"
> 
> Restart the server, and you should see a significant improvement in
> memory size and growth.
> 
> Regards,
> Mark
> 
> 
> On 09/26/2016 04:02 AM, Julian Kippels wrote:
> > Hi,
> >
> > I have a setup with 3 Servers running on rhel7, 1 master and 2 slaves,
> > as described in the documentation chapter 11.2.1. Once or twice a week
> > the master gets killed by the OS because the system is out of memory. I
> > could just throw more ram at it, but the system already has 16GB of ram
> > and i would like to try to fix the problem without using more ressources
> > first. Can you give me any suggestions where to start looking? What do
> > you need from me to be able to help?
> >
> > Thanks
> > Julian
> > ___
> > 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] 389ds gets killed for memory usage

[Julian Kippels]

Hi,

I have a setup with 3 Servers running on rhel7, 1 master and 2 slaves,
as described in the documentation chapter 11.2.1. Once or twice a week
the master gets killed by the OS because the system is out of memory. I
could just throw more ram at it, but the system already has 16GB of ram
and i would like to try to fix the problem without using more ressources
first. Can you give me any suggestions where to start looking? What do
you need from me to be able to help?

Thanks
Julian
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org