[Freeipa-users] Re: LDAP automatically restarted

[Mark Reynolds via FreeIPA-users]

On 7/19/24 8:26 AM, Rob Crittenden via FreeIPA-users wrote:

seojeong kim via FreeIPA-users wrote:

389 directory service automatically restarted.  I can't find specific error to 
trigger restart.   there is no PANIC error and deadlock detect error...

there is only just  'Incomming BER element was too long'
This error situation can trigger  LDAP restart automatically ?

I'd recommend checking your system logs. It could be an OOM killer.

There are ~30 seconds in between so it may not be directly related.


But when DS crashes there should be a "Detected disorderly shutdown" 
message in its error log when it starts back up - which I don't see in 
your log clip.  Perhaps the server ran out of memory, like Rob 
suggested, and it quietly shut itself down?  When malloc fails, or some 
other critical C library call fails the server will exit, or try to 
gracefully shutdown.  It's hard to say, but the server would normally 
log something if that type of failure occurred.  The only good news is 
that the database was not corrupted.  So it's a bit of mystery how it 
could just exit, but not log the reason or trigger a database recovery 
at the next startup.  But like I said the good news is that the database 
was not impacted by the crash/exit.


Mark



A 369-ish GB attribute is enormous. I'd look into that as well, if not
the culprit then as something that stands out on its own.

rob



[19/Jul/2024:06:22:59.279311026 +] - ERR - log_ber_too_big_error - 
conn=6079847 fd=396 Incoming BER Element was too long, max allowable is 
209715200 bytes. Change the nsslapd-maxbersize attribute in cn=config to 
increase.
[19/Jul/2024:06:23:01.700334149 +] - ERR - log_ber_too_big_error - 
conn=6079857 fd=1452 Incoming BER Element was too long, max allowable is 
209715200 bytes. Change the nsslapd-maxbersize attribute in cn=config to 
increase.
[19/Jul/2024:06:27:57.779058899 +] - ERR - NSMMReplicationPlugin - 
changelog program - _cl5WriteOperationTxn - retry (49) the transaction 
(csn=669a075e000900e9) failed (rc=-30993 (BDB0068 DB_LOCK_DEADLOCK: Locker 
killed to resolve a deadlock))
[19/Jul/2024:06:27:57.780583532 +] - ERR - NSMMReplicationPlugin - 
changelog program - _cl5WriteOperationTxn - Failed to write entry with csn 
(669a075e000900e9); db error - -30993 BDB0068 DB_LOCK_DEADLOCK: Locker 
killed to resolve a deadlock
[19/Jul/2024:06:27:57.781557073 +] - ERR - NSMMReplicationPlugin - 
write_changelog_and_ruv - Can't add a change for 
cn=penup-pre,cn=hostgroups,cn=accounts,dc=mydomain,dc=com (uniqid: 
000f3c05-70fc11eb-87e9f15a-5f2429bf, optype: 8) to changelog csn 
669a075e000900e9
[19/Jul/2024:06:27:58.125647535 +] - ERR - NSMMReplicationPlugin - 
process_postop - Failed to apply update (669a075e000900e9) error (1).  
Aborting replication session(conn=6075545 op=2978)
[19/Jul/2024:06:30:38.073674777 +] - ERR - log_ber_too_big_error - 
conn=6081159 fd=400 Incoming BER Element was 369736146107 bytes, max allowable 
is 209715200 bytes. Change the nsslapd-maxbersize attribute in cn=config to 
increase.
[19/Jul/2024:06:32:09.283886791 +] - ERR - connection_read_operation - 
conn=6081404 received a non-LDAP message (tag 0x18, expected 0x30)
[19/Jul/2024:06:33:29.585984549 +] - ERR - log_ber_too_big_error - 
conn=6081679 fd=311 Incoming BER Element was too long, max allowable is 
209715200 bytes. Change the nsslapd-maxbersize attribute in cn=config to 
increase.
[19/Jul/2024:06:34:04.617847679 +] - ERR - slapd_system_isFIPS - Can not 
access /proc/sys/crypto/fips_enabled - assuming FIPS is OFF
[19/Jul/2024:06:34:04.619891225 +] - ERR - slapd_system_isFIPS - Can not 
access /proc/sys/crypto/fips_enabled - assuming FIPS is OFF
[19/Jul/2024:06:34:04.931778931 +] - INFO - util_get_hardware_threads - 
Automatically configuring 16 threads
[19/Jul/2024:06:34:05.521184530 +] - WARN - Security Initialization - /tmp 
is not a private namespace. pem files not exported there
[19/Jul/2024:06:34:05.522737820 +] - INFO - slapd_extract_cert - CA CERT 
NAME: MYDOMAIN.COM IPA CA
[19/Jul/2024:06:34:05.524500653 +] - WARN - Security Initialization - SSL 
alert: Sending pin request to SVRCore. You may need to run 
systemd-tty-ask-password-agent to provide the password.
[19/Jul/2024:06:34:05.624809111 +] - INFO - slapd_extract_cert - SERVER 
CERT NAME: Server-Cert
[19/Jul/2024:06:34:05.626359141 +] - WARN - Security Initialization - /tmp 
is not a private namespace. pem files not exported there
[19/Jul/2024:06:34:05.627801709 +] - WARN - Security Initialization - /tmp 
is not a private namespace. pem files not exported there
[19/Jul/2024:06:34:05.854933657 +] - INFO - Security Initialization - SSL 
info: Enabling default cipher set.
[19/Jul/2024:06:34:05.856382522 +] - INFO - Security Initialization - SSL 
info: Configured NSS Ciphers
[19/Jul/2024:06:34:05.857556371 +] - INFO - Security Initialization - SSL 
info: TLS_AES_128_GCM_SHA256: enab

[Freeipa-users] Re: Possible to adjust generated salt size for CRYPT-SHA512 passwords?

[Mark Reynolds via FreeIPA-users]

Hi Jason,

Sorry, currently there is no way to adjust the salt size or "fine tune" 
any of the password storage schemes.


Regards,

Mark

On 5/29/24 12:05 PM, Jason Borden via FreeIPA-users wrote:

Greetings all,

I'm pretty new to FreeIPA and would like to know if I can adjust the salt size 
generated by FreeIPA when using CRYPT-SHA512 as the passwordStorageScheme.

After modifying the cn=config to use CRYPT-SHA512 passwords by default, new 
passwords are correctly generated using CRYPT-SHA512, however the size of the 
salt is tiny (only 2 base64 chars or about 12bits). I'd really like to 
configure FreeIPA to generate a larger salt, but I'm not sure if that's 
possible.

Just for background on why I've chosen to use CRYPT-SHA512 instead of the 
standard PBKDF2-SHA256 is because I intend to sync the password hashes in 
FreeIPA to a system we have that neither supports LDAP or Kerberos: 
postfixadmin. Postfixadmin supports CRYPT-SHA512 hashes but not PBKDF2-SHA256.

Thanks,
Jason
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


--
Identity Management Development Team
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: replication troubles

[Mark Reynolds via FreeIPA-users]

On 2/8/24 10:14 AM, Natxo Asenjo wrote:



On Thu, Feb 8, 2024 at 3:56 PM Mark Reynolds  wrote:

What version of 389-ds-base is installed?  There were bugs around
csn location that were fixed in the very latest version of the
LDAP server on RHEL 7.9.  So make sure you are running the latest
version of 389-ds-base.


this is 1.3.10.2-12.el7_9

so not the latest one. And I cannot update right now because of other 
issues. Does this version have this csn problem?


Yes it does.  It was fixed in:  1.3.10.2-17

Regards,

Mark




As for replication being broken, you can confirm this by making a
"dummy" change somewhere and checking if that change is present on
the other replicas (give it some time to replicate of course, but
it shouldn't take more than a few seconds).

As for re-initializing just make sure you are initing from the
most current/accurate replica.


yes, I saw we can use ipa topologysegent-reinitialize with just the 
domain suffix, so this should avoid overwriting the CA suffix (phew).


Thanks.



--
Identity Management Development Team
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: replication troubles

[Mark Reynolds via FreeIPA-users]

What version of 389-ds-base is installed?  There were bugs around csn 
location that were fixed in the very latest version of the LDAP server 
on RHEL 7.9.  So make sure you are running the latest version of 
389-ds-base.


As for replication being broken, you can confirm this by making a 
"dummy" change somewhere and checking if that change is present on the 
other replicas (give it some time to replicate of course, but it 
shouldn't take more than a few seconds).


As for re-initializing just make sure you are initing from the most 
current/accurate replica.


HTH,

Mark

On 2/8/24 9:06 AM, Natxo Asenjo via FreeIPA-users wrote:

hi,

we are having some trouble with our rhel 7 to rhel 8 migration and 
after checking some things, it became apparent the replication is 
mostly broken among the idm servers


I see in the errors:


|agmt=%s(%s:%d): Can't locate CSN %s in the changelog (DB
rc=%d). The consumer may need to be reinitialized|

According to this:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/managing_replication-troubleshooting_replication_related_problems

Reason: Most likely the changelog was recreated because of the disk is 
full or the server ungracefully shutdown.


/var/log on this hosts was full recently, so this could have caused 
this indeed.


I also see:

ERR - NSMMReplicationPlugin - send_updates -  : data required to 
update replica has been purged from the changelog, if the error 
persists the replica must be reinitialized.


This is pretty clear.

So this server is the ca master.

The domain level is 1.

The rhel version is right now 7.9.

If I reinitialize this server with the ca role (master), with other 
server, will it overwrite the CA?



--
Regards,
natxo

--
___
FreeIPA-users mailing list --freeipa-users@lists.fedorahosted.org
To unsubscribe send an email tofreeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue


--
Identity Management Development Team
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Time skew is 82 years off, with no replicas

[Mark Reynolds via FreeIPA-users]

On 8/24/23 11:46 AM, Rob Crittenden via FreeIPA-users wrote:

Kevin Konzem via FreeIPA-users wrote:

I did run the script to check the CSN generator states, this output is below:

./readNsState.py dse.ldif
nsState is HACdFOVkYBI+mwAEAA==
Little Endian
For replica cn=replica,cn=dc\3DDOMAIN\2Cdc\3DDOMAIN\2Cdc\3DDOMAIN,cn=mapping 
tree,cn=config
   fmtstr=[H6x3QH6x]
   size=40
   len of nsstate is 40
   CSN generator state:
 Replica ID: 28
 Sampled Time  : 1692734621
 Gen as csn: 64e5149d00040028
 Time as str   : Tue Aug 22 15:03:41 2023
 Local Offset  : 0
 Remote Offset : 2604536416
 Seq. num  : 4
 System time   : Tue Aug 22 15:04:27 2023
 Diff in sec.  : 46
 Day:sec diff  : 0:46

nsState is HQDJBuVk4hcBAA==
Little Endian
For replica cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
   fmtstr=[H6x3QH6x]
   size=40
   len of nsstate is 40
   CSN generator state:
 Replica ID: 29
 Sampled Time  : 1692731081
 Gen as csn: 64e506c900010029
 Time as str   : Tue Aug 22 14:04:41 2023
 Local Offset  : 0
 Remote Offset : 6114
 Seq. num  : 1
 System time   : Tue Aug 22 15:04:27 2023
 Diff in sec.  : 3586
 Day:sec diff  : 0:3586

Despite this being the only server left you still have replication
agreements remaining.

Try using ipa topology-segment or ipa-replica-manage to remove them.


Also, as long as replication is enabled on a database the CSN generation 
will still be generated.  As Rob said, these offsets are computed by 
remote replicas (through repl agreements).


Going back to the issue.  That is obviously a very high offset/skew.  We 
typically only see these "jumps" on AWS.  Was one of your replicas on 
AWS by any chance?  In the DS error log (on newer versions of 
389-ds-base) we log these jumps for debugging purposes.  Could you check 
your DS error log (/var/log/dirsrv/slapd-YOUR_INSTANCE/errors*) for 
"Detected large jump in CSN time", and please share that message if it 
exists.


Thanks,

Mark



rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


--
Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Errors in dirsrv log

[Mark Reynolds via FreeIPA-users]

On 8/15/23 7:08 AM, Alexander Bokovoy via FreeIPA-users wrote:

On Няд, 13 жні 2023, Ranbir via FreeIPA-users wrote:
I'm seeing errors like the ones below on my ipa servers (excuse the 
wrapping):


[11/Aug/2023:22:07:37.684144411 -0700] - ERR - get_value_from_string 
- type does not match: dsEntryDN != dsEntryDN;vucsn-64d5d55800040013
[11/Aug/2023:22:07:37.686865097 -0700] - ERR - get_value_from_string 
- type does not match: dsEntryDN != dsEntryDN;vucsn-64d5d8d4003e
[11/Aug/2023:22:07:37.689902756 -0700] - ERR - get_value_from_string 
- type does not match: dsEntryDN != dsEntryDN;vucsn-64d5dc5100070019
[11/Aug/2023:22:07:37.693576614 -0700] - ERR - get_value_from_string 
- type does not match: dsEntryDN != dsEntryDN;vucsn-64d5ff85002d
[11/Aug/2023:22:07:37.696088129 -0700] - ERR - get_value_from_string 
- type does not match: dsEntryDN != dsEntryDN;vucsn-64d6030100040038
[11/Aug/2023:22:07:37.698351038 -0700] - ERR - get_value_from_string 
- type does not match: dsEntryDN != dsEntryDN;vucsn-64d60687000d


What was happening at this time?  Is there anything before this message 
in the log?  Like an LDIF import?


Mark



I can't find anything about what they mean.

What do these errors mean? How do I resolve the problem?


This is from 389-ds backend database code.

I'd suggest you to open an issue with them directly
(https://github.com/389ds/389-ds-base/issues/)



--
Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: After "writeback to ldap failed" -- silent total freeipa failure / deadlock.

[Mark Reynolds via FreeIPA-users]

On 8/9/23 2:00 AM, Alexander Bokovoy wrote:

On Аўт, 08 жні 2023, Harry G Coin wrote:
Thanks for your help.  Details below.  The problem 'moved' in I hope 
a diagnositcally useful way, but the system remains broken.


On 8/8/23 08:54, Alexander Bokovoy wrote:

On Аўт, 08 жні 2023, Harry G Coin wrote:


On 8/8/23 02:43, Alexander Bokovoy wrote:

pstack $(pgrep ns-slapd)  > ns-slapd log
Tried an upgrade from 4.9.10 to 4.9.11, the "writeback to ldap 
failed" error moved from the primary instance (on which the dns 
records were being added) to the replica which hung in the same 
fashion.   Here's the log you asked for from attempting 'systemctl 
restart dirsrv@...'  it just hangs at 100% cpu for about 10 minutes.


Thank you. Are you using schema compat for some legacy clients?



This is a fresh install of 4.9.10 about a week ago, upgraded to 
4.9.11 yesterday, just two freeipa instances and no appreciable user 
load, using the install defaults.  The 'in house' system then starts 
loading lots of dns records via the python ldap2 interface on the 
first of two systems installed, the replica produced what you see in 
this post.   There is no 'private' information involved of any sort, 
it's supposed to field DNS calls from the public but was so 
unreliable I had to implement unbound on other servers, so all 
freeipa does is IXFR to unbound for the heavy load.  I suppose there 
may be <16 other in-house lab systems, maybe 2 or 3 with any 
activity, that use it for dns.   The only other clue is these are 
running on VMs in older servers and have no other software packages 
installed other than freeipa and what freeipa needs to run, and the 
in-house program that loads the dns.


Just to exclude potential problems with schema compat, it can be
disabled if you are not using it.

I don't think it is about named per se, it is a bit of an unfortunate
interop inside ns-slapd between different plugins. bind-dyndb-ldap
relies on the syncrepl extension which implementation in ns-slapd is
using the retro changelog content. Retro changelog plugin triggers some
updates that cause schema compatibility plugin to lock itself up
depending on the order of updates that retro changelog would capture. We
fixed that in slapi-nis package some time ago and it *should* be
ignoring the retro changelog changes but somehow they still propagate
into it. There are few places in ns-slapd which were addressed just
recently and those updates might help (out later this year in RHEL).
Disabling schema compat would be the best.

What's worse, every reboot attempt waits the full '9 min 29 secs' 
before systemd forcibly terminates ns-slapd to finish the 'stop job'.


That's why I'm so troubled by all this, it's not like there is any 
interference from anything other than what freeipa puts out there, 
and it just locks with a message that gives no indication of what to 
do about it, with nothing in any logs and 'systemctl 
is-system-running' reports 'running'.


You could easily replicate this:  imagine a simple validation test 
that sets up two freeipa nodes, turns on dnssec, creates some 
domains, then adds A  and *.arpa records using the ldap2 api on 
one of the nodes.  Maybe limit the net speed between the nodes to a 
1GB link typical, maybe at most 4 processor cores of some older 
vintage and 5GB memory.  It takes less than 2 minutes after dns load 
start to lock up.


What's really odd is bind9 / named keeps blasting out change 
notifications for some of the updated domains, then a few lines 
later, with no intervening activity in any log or by any program 
affecting the zone, will publish further change notifications with a 
new serial number for the same zone.  This happens for all the zones 
that get modifications.  I'm thinking 'rr' computations?  I wonder if 
those entries-- being auto-generated internally -- are creating a 
'flow control' issue between the primary and replica.


This is something that retro changelog is responsible for as it is the
data store used by the syncrepl protocol implementation. If these
'changes' appear again and again, it means retro changelog plugin marks
them as new for this particular syncrepl client (bind-dyndb-ldap).

All threads other than the thread 30 are normal ones (idle threads) but
this one blocks the database backend in the log flush sequence while
writing the retro changelog entry for this updated DNS record:


Thread 30 (Thread 0x7f0e583ff700 (LWP 1438)):
#0  0x7f0e9bf7d8af in fdatasync () at target:/lib64/libc.so.6
#1  0x7f0e91cbe6b5 in __os_fsync () at target:/lib64/libdb-5.3.so
#2  0x7f0e91ca598c in __log_flush_int () at 
target:/lib64/libdb-5.3.so

#3  0x7f0e91ca7dd0 in __log_flush () at target:/lib64/libdb-5.3.so
#4  0x7f0e91ca7f73 in __log_flush_pp () at 
target:/lib64/libdb-5.3.so
#5  0x7f0e8afe1304 in bdb_txn_commit (li=,  
txn=0x7f0e583fd028, use_lock=1) at 
ldap/servers/slapd/back-ldbm/db-bdb/bdb_layer.c:2772
#6  0x7f0e8af95515 in dblayer_txn_commit (be

[Freeipa-users] Re: AccountPolicy erroring for some users

[Mark Reynolds via FreeIPA-users]

Hi Lukas,

It's being worked on right now.

Thanks,

Mark :-)

On 7/12/23 7:38 AM, Lucas Diedrich via FreeIPA-users wrote:
Hey Marc, thanks for sending the link, opened a ticket here: 
https://github.com/389ds/389-ds-base/issues/5834


Thanks.

Em ter., 11 de jul. de 2023 às 15:37, Mark Reynolds 
 escreveu:



On 7/11/23 12:56 PM, LUCAS GUILHERME DIEDRICH via FreeIPA-users wrote:
> Hey,
>
> Since i updated to the lastest Freeipa version (IPA, version:
4.10.1), i started noticing some error in the 389 error.log.
>
> [11/Jul/2023:13:50:20.591388308 -0300] - ERR -
acct_update_login_history - Modify error 20 on entry
'uid=xyz,cn=users,cn=accounts,dc=unila,dc=intranet'
> [11/Jul/2023:13:51:52.993254666 -0300] - ERR - attrlist_replace
- attr_replace (lastLoginHistory, 20230710114037Z) failed.
> [11/Jul/2023:13:51:52.995079255 -0300] - ERR - attrlist_replace
- attr_replace (lastLoginHistory, 20230710114037Z) failed.
> [11/Jul/2023:13:51:53.014918310 -0300] - ERR -
acct_update_login_history - Modify error 20 on entry
'uid=abc,cn=users,cn=accounts,dc=unila,dc=intranet'
> [11/Jul/2023:13:52:12.898523693 -0300] - ERR - attrlist_replace
- attr_replace (lastLoginHistory, 20230711165203Z) failed.
> [11/Jul/2023:13:52:12.901073197 -0300] - ERR - attrlist_replace
- attr_replace (lastLoginHistory, 20230711165203Z) failed.
> [11/Jul/2023:13:52:12.914936792 -0300] - ERR -
acct_update_login_history - Modify error 20 on entry
'uid=abc,cn=users,cn=accounts,dc=unila,dc=intranet'
> [11/Jul/2023:13:52:21.897598474 -0300] - ERR - attrlist_replace
- attr_replace (lastLoginHistory, 20230711165144Z) failed.
> [11/Jul/2023:13:52:21.899560503 -0300] - ERR - attrlist_replace
- attr_replace (lastLoginHistory, 20230711165144Z) failed.
> [11/Jul/2023:13:52:21.913459796 -0300] - ERR -
acct_update_login_history - Modify error 20 on entry
'uid=xyz,cn=users,cn=accounts,dc=unila,dc=intranet'
> [11/Jul/2023:13:52:42.939623733 -0300] - ERR - attrlist_replace
- attr_replace (lastLoginHistory, 20230710221057Z) failed.
> [11/Jul/2023:13:52:42.942050331 -0300] - ERR - attrlist_replace
- attr_replace (lastLoginHistory, 20230710221057Z) failed.
> [11/Jul/2023:13:52:42.955004117 -0300] - ERR -
acct_update_login_history - Modify error 20 on entry
'fqdn=hostname.unila.intranet,cn=computers,cn=accounts,dc=unila,dc=intranet'
>
> I'm not sure why this is happening and how can i fix this,
unfortunetly i'm using the account_plugin to update the last auth
date via LDAP, but the field lastLoginHistory seems to be
something added in the lastest releases.

This is a new feature feature just added upstream.   Please file a
ticket for DS:

https://github.com/389ds/389-ds-base/issues/new

Thanks,
Mark

>
> I have 3 replicas, but the account_plugin is enabled only in the
machines which is currently erroring.
>
> Any ideas how to fix this?
>
> Thanks.
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to
freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue

-- 
Directory Server Development Team



___
FreeIPA-users mailing list --freeipa-users@lists.fedorahosted.org
To unsubscribe send an email tofreeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue


--
Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: AccountPolicy erroring for some users

[Mark Reynolds via FreeIPA-users]

On 7/11/23 12:56 PM, LUCAS GUILHERME DIEDRICH via FreeIPA-users wrote:

Hey,

Since i updated to the lastest Freeipa version (IPA, version: 4.10.1), i 
started noticing some error in the 389 error.log.

[11/Jul/2023:13:50:20.591388308 -0300] - ERR - acct_update_login_history - 
Modify error 20 on entry 'uid=xyz,cn=users,cn=accounts,dc=unila,dc=intranet'
[11/Jul/2023:13:51:52.993254666 -0300] - ERR - attrlist_replace - attr_replace 
(lastLoginHistory, 20230710114037Z) failed.
[11/Jul/2023:13:51:52.995079255 -0300] - ERR - attrlist_replace - attr_replace 
(lastLoginHistory, 20230710114037Z) failed.
[11/Jul/2023:13:51:53.014918310 -0300] - ERR - acct_update_login_history - 
Modify error 20 on entry 'uid=abc,cn=users,cn=accounts,dc=unila,dc=intranet'
[11/Jul/2023:13:52:12.898523693 -0300] - ERR - attrlist_replace - attr_replace 
(lastLoginHistory, 20230711165203Z) failed.
[11/Jul/2023:13:52:12.901073197 -0300] - ERR - attrlist_replace - attr_replace 
(lastLoginHistory, 20230711165203Z) failed.
[11/Jul/2023:13:52:12.914936792 -0300] - ERR - acct_update_login_history - 
Modify error 20 on entry 'uid=abc,cn=users,cn=accounts,dc=unila,dc=intranet'
[11/Jul/2023:13:52:21.897598474 -0300] - ERR - attrlist_replace - attr_replace 
(lastLoginHistory, 20230711165144Z) failed.
[11/Jul/2023:13:52:21.899560503 -0300] - ERR - attrlist_replace - attr_replace 
(lastLoginHistory, 20230711165144Z) failed.
[11/Jul/2023:13:52:21.913459796 -0300] - ERR - acct_update_login_history - 
Modify error 20 on entry 'uid=xyz,cn=users,cn=accounts,dc=unila,dc=intranet'
[11/Jul/2023:13:52:42.939623733 -0300] - ERR - attrlist_replace - attr_replace 
(lastLoginHistory, 20230710221057Z) failed.
[11/Jul/2023:13:52:42.942050331 -0300] - ERR - attrlist_replace - attr_replace 
(lastLoginHistory, 20230710221057Z) failed.
[11/Jul/2023:13:52:42.955004117 -0300] - ERR - acct_update_login_history - 
Modify error 20 on entry 
'fqdn=hostname.unila.intranet,cn=computers,cn=accounts,dc=unila,dc=intranet'

I'm not sure why this is happening and how can i fix this, unfortunetly i'm 
using the account_plugin to update the last auth date via LDAP, but the field 
lastLoginHistory seems to be something added in the lastest releases.


This is a new feature feature just added upstream.   Please file a 
ticket for DS:


https://github.com/389ds/389-ds-base/issues/new

Thanks,
Mark



I have 3 replicas, but the account_plugin is enabled only in the machines which 
is currently erroring.

Any ideas how to fix this?

Thanks.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


--
Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: ipa-healthcheck errors

[Mark Reynolds via FreeIPA-users]

On 11/20/22 3:39 PM, Rob Verduijn wrote:

thanx

any clues about the other errors?
Sorry I'm not that familiar with IPA - I'm just a Directory Server guy.  
I'm sure someone from the IPA team will respond tomorrow.


ipa-healthcheck
args=({'msgtype': 101, 'msgid': 3, 'result': 32, 'desc': 'No such 
object', 'ctrls': [], 'ldap_request': 
"search_ext_s(('cn=changelog5,cn=config', 0, 
'(objectClass=*)'),{'attrlist': ['nsslapd-changelogmaxentries'], 
'serverctrls': None, '
clientctrls': None, 'escapehatch': 'i am sure'}) on instance 
TJAKO-THUIS"},)

[
 {
   "source": "ipahealthcheck.ipa.certs",
   "check": "IPACertTracking",
   "result": "CRITICAL",
   "uuid": "6bab1187-3285-4059-9f92-a6e8fba54d2f",
   "when": "20221119105634Z",
   "duration": "0.721246",
   "kw": {
 "exception": "bus, object_path and dbus_interface must not be None."
   }
 },
 {
   "source": "ipahealthcheck.ipa.certs",
   "check": "IPACertDNSSAN",
   "result": "CRITICAL",
   "uuid": "b13b939b-9b8d-4893-ba31-da2dd203551a",
   "when": "20221119105635Z",
   "duration": "0.683679",
   "kw": {
 "exception": "bus, object_path and dbus_interface must not be None."
   }
 },
 {
   "source": "ipahealthcheck.ipa.certs",
   "check": "IPACertRevocation",
   "result": "CRITICAL",
   "uuid": "a235463c-85cd-4277-8ee8-a10a0fcc6e5c",
   "when": "20221119105638Z",
   "duration": "0.655251",
   "kw": {
 "exception": "bus, object_path and dbus_interface must not be None."
   }
 },
 {
   "source": "ipahealthcheck.ipa.files",
   "check": "IPAFileCheck",
   "result": "CRITICAL",
   "uuid": "85deeb45-7e32-4f00-b2ab-a9b0484242c7",
   "when": "20221119105639Z",
   "duration": "0.083885",
   "kw": {
 "exception": "bus, object_path and dbus_interface must not be None."
   }
 }
]



Op zo 20 nov. 2022 om 17:08 schreef Mark Reynolds :


On 11/20/22 10:51 AM, Rob Verduijn wrote:



Op zo 20 nov. 2022 15:57 schreef Mark Reynolds :


On 11/20/22 9:06 AM, Sam Morris via FreeIPA-users wrote:
> On Sat, 2022-11-19 at 11:57 +0100, Rob Verduijn via
FreeIPA-users
> wrote:
>> Hi all,
>>
>> I managed to get rid of another error but I still have
plenty erros
>> left.
>>
>> Any help would be apreciated.
>>
>> ipa-healthcheck errors remaining:
>>
>> ipa-healthcheck
>> args=({'msgtype': 101, 'msgid': 3, 'result': 32, 'desc':
'No such
>> object', 'ctrls': [], 'ldap_request':
>> "search_ext_s(('cn=changelog5,cn=config', 0,
>> '(objectClass=*)'),{'attrlist':
['nsslapd-changelogmaxentries'],
>> 'serverctrls': None,'
>> clientctrls': None, 'escapehatch': 'i am sure'}) on
instance TJAKO-
>> THUIS"},)
> Is this your server telling you that the entry
cn=changelog5,cn=config
> does not exist? That sounds pretty bad... try running this
(change IPA-
> EXAMPLE-COM to the name of your dirsrv instance):
>
> ldapsearch -H ldapi://%2frun%2fslapd-IPA-EXAMPLE-COM.socket
-Y EXTERNAL
> -b cn=changelog5,cn=config -s base

This is fine actually. This is a bug we are looking into.  It
should not
be outputting that exception.  It just checking if a backend
has a
changelog, not that it's expecting one.  This can be ignored.

Mark

Can you share a link to this bug?



https://bugzilla.redhat.com/show_bug.cgi?id=2115254






>
>>    {
>>  "source": "ipahealthcheck.ipa.certs",
>>  "check": "IPACertTracking",
>>  "result": "CRITICAL",
>>  "uuid": "6bab1187-3285-4059-9f92-a6e8fba54d2f",
>>  "when": "20221119105634Z",
>>  "duration": "0.721246",
>>  "kw": {
>>    "exception": "bus, object_path and dbus_interface
must not be
>> None."
>>  }
>>    },
> These look like D-Bus-related errors. Is certmonger
started, can you
> run 'getcert list'?
>
-- 
Directory Server Development Team


-- 
Directory Server Development Team



--
Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: ipa-healthcheck errors

[Mark Reynolds via FreeIPA-users]

On 11/20/22 10:51 AM, Rob Verduijn wrote:



Op zo 20 nov. 2022 15:57 schreef Mark Reynolds :


On 11/20/22 9:06 AM, Sam Morris via FreeIPA-users wrote:
> On Sat, 2022-11-19 at 11:57 +0100, Rob Verduijn via FreeIPA-users
> wrote:
>> Hi all,
>>
>> I managed to get rid of another error but I still have plenty erros
>> left.
>>
>> Any help would be apreciated.
>>
>> ipa-healthcheck errors remaining:
>>
>> ipa-healthcheck
>> args=({'msgtype': 101, 'msgid': 3, 'result': 32, 'desc': 'No such
>> object', 'ctrls': [], 'ldap_request':
>> "search_ext_s(('cn=changelog5,cn=config', 0,
>> '(objectClass=*)'),{'attrlist': ['nsslapd-changelogmaxentries'],
>> 'serverctrls': None,'
>> clientctrls': None, 'escapehatch': 'i am sure'}) on instance TJAKO-
>> THUIS"},)
> Is this your server telling you that the entry
cn=changelog5,cn=config
> does not exist? That sounds pretty bad... try running this
(change IPA-
> EXAMPLE-COM to the name of your dirsrv instance):
>
> ldapsearch -H ldapi://%2frun%2fslapd-IPA-EXAMPLE-COM.socket -Y
EXTERNAL
> -b cn=changelog5,cn=config -s base

This is fine actually. This is a bug we are looking into. It
should not
be outputting that exception.  It just checking if a backend has a
changelog, not that it's expecting one.  This can be ignored.

Mark

Can you share a link to this bug?



https://bugzilla.redhat.com/show_bug.cgi?id=2115254






>
>>    {
>>  "source": "ipahealthcheck.ipa.certs",
>>  "check": "IPACertTracking",
>>  "result": "CRITICAL",
>>  "uuid": "6bab1187-3285-4059-9f92-a6e8fba54d2f",
>>  "when": "20221119105634Z",
>>  "duration": "0.721246",
>>  "kw": {
>>    "exception": "bus, object_path and dbus_interface must
not be
>> None."
>>  }
>>    },
> These look like D-Bus-related errors. Is certmonger started, can you
> run 'getcert list'?
>
-- 
Directory Server Development Team



--
Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: ipa-healthcheck errors

[Mark Reynolds via FreeIPA-users]

On 11/20/22 9:06 AM, Sam Morris via FreeIPA-users wrote:

On Sat, 2022-11-19 at 11:57 +0100, Rob Verduijn via FreeIPA-users
wrote:

Hi all,

I managed to get rid of another error but I still have plenty erros
left.

Any help would be apreciated.

ipa-healthcheck errors remaining:

ipa-healthcheck
args=({'msgtype': 101, 'msgid': 3, 'result': 32, 'desc': 'No such
object', 'ctrls': [], 'ldap_request':
"search_ext_s(('cn=changelog5,cn=config', 0,
'(objectClass=*)'),{'attrlist': ['nsslapd-changelogmaxentries'],
'serverctrls': None,'
clientctrls': None, 'escapehatch': 'i am sure'}) on instance TJAKO-
THUIS"},)

Is this your server telling you that the entry cn=changelog5,cn=config
does not exist? That sounds pretty bad... try running this (change IPA-
EXAMPLE-COM to the name of your dirsrv instance):

ldapsearch -H ldapi://%2frun%2fslapd-IPA-EXAMPLE-COM.socket -Y EXTERNAL
-b cn=changelog5,cn=config -s base


This is fine actually. This is a bug we are looking into.  It should not 
be outputting that exception.  It just checking if a backend has a 
changelog, not that it's expecting one.  This can be ignored.


Mark




   {
 "source": "ipahealthcheck.ipa.certs",
 "check": "IPACertTracking",
 "result": "CRITICAL",
 "uuid": "6bab1187-3285-4059-9f92-a6e8fba54d2f",
 "when": "20221119105634Z",
 "duration": "0.721246",
 "kw": {
   "exception": "bus, object_path and dbus_interface must not be
None."
 }
   },

These look like D-Bus-related errors. Is certmonger started, can you
run 'getcert list'?


--
Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: dirsrv times out at startup

[Mark Reynolds via FreeIPA-users]

Hi Roberto,

On 11/17/22 11:36 AM, Roberto Cornacchia via FreeIPA-users wrote:
Yesterday I installed a replica on a clean Rocky 9 system. No issues 
at all. Everything

seemed to work fine.

Today the machine was rebooted (no dnf updates, no system changes) and 
ipa could not start anymore.


ipactl start -d says:

Starting Directory Service
ipa: DEBUG: Starting external process
ipa: DEBUG: args=['/bin/systemctl', 'start', 
'dirsrv@HQ-SPINQUE-COM.service']

ipa: DEBUG: Process finished, return code=0
ipa: DEBUG: Starting external process
ipa: DEBUG: args=['/bin/systemctl', 'is-active', 
'dirsrv@HQ-SPINQUE-COM.service']

ipa: DEBUG: Process finished, return code=0
ipa: DEBUG: stdout=active

ipa: DEBUG: stderr=
ipa: DEBUG: wait_for_open_ports: localhost [389] timeout 120
ipa: DEBUG: waiting for port: 389
ipa: DEBUG: Failed to connect to port 389 tcp on ::1
ipa: DEBUG:   File 
"/usr/lib/python3.9/site-packages/ipaserver/install/installutils.py", 
line 781, in run_script

    return_value = main_function()

  File "/usr/lib/python3.9/site-packages/ipaserver/install/ipactl.py", 
line 739, in main

    ipa_restart(options)

  File "/usr/lib/python3.9/site-packages/ipaserver/install/ipactl.py", 
line 499, in ipa_restart

    raise IpactlError("Failed to start Directory Service: " + str(e))

ipa: DEBUG: The ipactl command failed, exception: IpactlError: Failed 
to start Directory Service: Timeout exceeded

Failed to start Directory Service: Timeout exceeded

/var/log/dirsrv/slapd-HQ-SPINQUE-COM/errors says:

[17/Nov/2022:17:22:21.074990853 +0100] - INFO - slapd_extract_cert - 
CA CERT NAME: HQ.SPINQUE.COM  IPA CA
[17/Nov/2022:17:22:21.668775045 +0100] - WARN - Security 
Initialization - SSL alert: Sending pin request to SVRCore. You may 
need to run systemd-tty-ask-password-agent to provide the password if 
pin.txt does not exist.
[17/Nov/2022:17:22:22.295325169 +0100] - INFO - slapd_extract_cert - 
SERVER CERT NAME: Server-Cert
[17/Nov/2022:17:22:23.275812957 +0100] - INFO - Security 
Initialization - SSL info: Enabling default cipher set.
[17/Nov/2022:17:22:26.090728693 +0100] - INFO - Security 
Initialization - SSL info: Configured NSS Ciphers
[17/Nov/2022:17:22:26.771211814 +0100] - INFO - Security 
Initialization - SSL info: TLS_AES_128_GCM_SHA256: enabled
[17/Nov/2022:17:22:28.438124063 +0100] - INFO - Security 
Initialization - SSL info: TLS_CHACHA20_POLY1305_SHA256: enabled
[17/Nov/2022:17:22:28.928766931 +0100] - INFO - Security 
Initialization - SSL info: TLS_AES_256_GCM_SHA384: enabled
[17/Nov/2022:17:22:29.544178747 +0100] - INFO - Security 
Initialization - SSL info: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: 
enabled
[17/Nov/2022:17:22:30.099717701 +0100] - INFO - Security 
Initialization - SSL info: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[17/Nov/2022:17:22:30.657974763 +0100] - INFO - Security 
Initialization - SSL info: 
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256: enabled
[17/Nov/2022:17:22:31.245996850 +0100] - INFO - Security 
Initialization - SSL info: 
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256: enabled
[17/Nov/2022:17:22:31.790186166 +0100] - INFO - Security 
Initialization - SSL info: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: 
enabled
[17/Nov/2022:17:22:32.205374722 +0100] - INFO - Security 
Initialization - SSL info: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[17/Nov/2022:17:22:32.771492861 +0100] - INFO - Security 
Initialization - SSL info: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled
[17/Nov/2022:17:22:33.139528386 +0100] - INFO - Security 
Initialization - SSL info: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled
[17/Nov/2022:17:22:33.392948327 +0100] - INFO - Security 
Initialization - SSL info: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
[17/Nov/2022:17:22:33.420924018 +0100] - INFO - Security 
Initialization - SSL info: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: 
enabled
[17/Nov/2022:17:22:33.468560401 +0100] - INFO - Security 
Initialization - SSL info: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled
[17/Nov/2022:17:22:33.524578902 +0100] - INFO - Security 
Initialization - SSL info: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled
[17/Nov/2022:17:22:33.769874334 +0100] - INFO - Security 
Initialization - SSL info: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[17/Nov/2022:17:22:34.596047264 +0100] - INFO - Security 
Initialization - SSL info: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256: 
enabled
[17/Nov/2022:17:22:35.137255640 +0100] - INFO - Security 
Initialization - SSL info: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[17/Nov/2022:17:22:35.938316117 +0100] - INFO - Security 
Initialization - SSL info: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled
[17/Nov/2022:17:22:36.492933614 +0100] - INFO - Security 
Initialization - SSL info: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled
[17/Nov/2022:17:22:37.059388478 +0100] - INFO - Security 
Initialization - SSL info: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled
[17/Nov/2022:17:22:37.497954414 +0100] - INFO - Security 
I

[Freeipa-users] Re: LDAP not starting for IPA-Server

[Mark Reynolds via FreeIPA-users]

On 9/27/22 4:36 PM, Nick Polites via FreeIPA-users wrote:

I added the nsslapd-securePort: 636 but port 636 is not listening. 389 is 
working. Do I need to do something else to get 636 working?


nsslapd-security needs to be "on" for the secure port to be activated.  
This does require as server restart to take effect.


HTH,

Mark


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


--
Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Port 389 on IPA servers

[Mark Reynolds via FreeIPA-users]

On 7/15/22 8:15 AM, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

The official RedHat doumentation states


The TCP port 389 is not required to be open on IdM servers for trust,
but it is necessary for clients communicating with the IdM server.

Is this still true? Or could LDAPS/Port 636 be used as well?

Used for what? Are you still talking about trust?

Yes, port 636 can be used for LDAP traffic. It's been deprecated for
years in favor of startTLS
Really?  LDAPS deprecated?  In our opinion startTLS should deprecated in 
favor of LDAPS.  Interesting... :-)

but it's one of those things that isn't
likely to go away for a while.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


--
Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: After upgrade, only one direction replication while should be bi-directions replication

[Mark Reynolds via FreeIPA-users]

On 6/2/22 1:38 PM, Rob Crittenden wrote:

Kathy Zhu via FreeIPA-users wrote:

Hi Team,

We upgraded our Centos 7 IPA masters to the latest:

CentOS Linux release 7.9.2009 (Core)

*ipa*-server.x86_64                      4.6.8-5.el7.centos.10

*389-ds*-base.x86_64                     1.3.10.2-15.el7_9

*389-ds*-base-libs.x86_64                1.3.10.2-15.el7_9

*389-ds*-base-snmp.x86_64                1.3.10.2-15.el7_9

*slapi*-nis.x86_64                       0.56.5-3.el7_9


After that, 8 of 10 masters had replication issues. After
reinitializing, 2 of them are still having issues. They can accept
replication from other masters but their own changes can not be
replicated to others.


Here are the logs in /var/log/dirsrv/slapd-EXAMPLE-COM/errors:


[01/Jun/2022:21:53:02.324756398 -0700] - ERR - NSMMReplicationPlugin -
send_updates - agmt="cn=dc1-ipa1.example.com-to-dc2-ipa1.example.com
" (dc2-ipa1:389):
Data required to update replica has been purged from the changelog. If
the error persists the replica must be reinitialized.

[01/Jun/2022:21:53:03.396330801 -0700] - ERR -
agmt="cn=dc1-ipa1.example.com-to-dc3-ipa1.example.com
" (dc3-ipa1:389) -
clcache_load_buffer - Can't locate CSN 627e26a50005001d in the
changelog (DB rc=-30988). If replication stops, the consumer may need to
be reinitialized.

[01/Jun/2022:21:53:03.396502102 -0700] - ERR - NSMMReplicationPlugin -
changelog program - repl_plugin_name_cl -
agmt="cn=dc1-ipa1.example.com-to-dc3-ipa1.example.com
" (dc3-ipa1:389):
CSN 627e26a50005001d not found, we aren't as up to date, or we purged

[01/Jun/2022:21:53:03.396694568 -0700] - ERR - NSMMReplicationPlugin -
send_updates - agmt="cn=dc1-ipa1.example.com-to-dc3-ipa1.example.com
" (dc3-ipa1:389):
Data required to update replica has been purged from the changelog. If
the error persists the replica must be reinitialized.

[01/Jun/2022:21:53:04.411599251 -0700] - ERR -
agmt="cn=dc1-ipa1.example.com-to-ipa0.example.com
" (ipa0:389) -
clcache_load_buffer - Can't locate CSN 627e26a50005001d in the
changelog (DB rc=-30988). If replication stops, the consumer may need to
be reinitialized.

[01/Jun/2022:21:53:04.411753186 -0700] - ERR - NSMMReplicationPlugin -
changelog program - repl_plugin_name_cl -
agmt="cn=dc1-ipa1.example.com-to-ipa0.example.com
" (ipa0:389): CSN
627e26a50005001d not found, we aren't as up to date, or we purged

[01/Jun/2022:21:53:04.411893312 -0700] - ERR - NSMMReplicationPlugin -
send_updates - agmt="cn=dc1-ipa1.example.com-to-ipa0.example.com
" (ipa0:389): Data
required to update replica has been purged from the changelog. If the
error persists the replica must be reinitialized.

[01/Jun/2022:21:53:05.482898290 -0700] - ERR -
agmt="cn=dc1-ipa1.example.com-to-dc2-ipa1.example.com
" (dc2-ipa1:389) -
clcache_load_buffer - Can't locate CSN 627e26a50005001d in the
changelog (DB rc=-30988). If replication stops, the consumer may need to
be reinitialized.

[01/Jun/2022:21:53:05.483231727 -0700] - ERR - NSMMReplicationPlugin -
changelog program - repl_plugin_name_cl -
agmt="cn=dc1-ipa1.example.com-to-dc2-ipa1.example.com
" (dc2-ipa1:389):
CSN 627e26a50005001d not found, we aren't as up to date, or we purged

[01/Jun/2022:21:53:05.483483005 -0700] - ERR - NSMMReplicationPlugin -
send_updates - agmt="cn=dc1-ipa1.example.com-to-dc2-ipa1.example.com
" (dc2-ipa1:389):
Data required to update replica has been purged from the changelog. If
the error persists the replica must be reinitialized.


Note, those messages are after being reinitialized.


Any idea what's wrong here?

I'm not sure, cc'ing one of the 389ds developers.

Mark, any ideas?


Looks like https://github.com/389ds/389-ds-base/issues/5098

This was fixed fairly recently, and it has not been added to any RHEL 
7.9 builds yet.


Pierre worked on this, but I think the issue happens when the LDIF used 
to init replication has the RUV entry as the first entry in the LDIF 
file.  If it is moved to the end of the file I think it will fix the 
init issue.  So don't do an online init.  Export the database with 
replication data (-r) from a good supplier, edit the ldif file and make 
sure the RUV tombstone entry is the last entry in the file, then import 
it on the consumer.


HTH,
Mark



rob


--
Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahos

[Freeipa-users] Re: ERR - log_result - Internal unindexed search

[Mark Reynolds via FreeIPA-users]

On 3/28/22 4:35 PM, Kathy Zhu wrote:

Thank you, Mark!

Actually, since the typo, I read the manual page and googled 
db2index.pl  command. It is suggested to stop the 
dirsrv process before running the command. If there were no typo, I 
would run it without stopping. Thank you!


Yes that would be better, and faster, but the command line tool is 
"db2index" in that case, and not the perl script version "db2index.pl".


Thanks,
Mark



Kathy.

On Mon, Mar 28, 2022 at 1:03 PM Mark Reynolds  wrote:

Ugh, sorry had a typo, each attribute is specified with "-t".  So
replace the "-a" with a "-t":

db2index.pl  -D "cn=directory manager" -w
Nur09089 -n userroot -t changenumber:eq -t targetuniqueid:eq

Mark

On 3/28/22 3:44 PM, Kathy Zhu wrote:

Hi Mark,

Thank you! After modifying the DB, when tried to index, I ran into:

[root@ipa2 ~]# db2index.pl  -D "cn=directory
manager" -w Nur09089 -n userroot -t changenumber:eq -a
targetuniqueid:eq

ERROR - Unknown option: -a

Usage: db2index.pl  [-Z serverID] [-D rootdn]
{ -w password | -w - | -j filename } [-P protocol]

-n backendname [-t attributeName[:indextypes[:matchingrules]]]
[-T vlvTag] [-h]

Options:

-D rootdn - Directory Manager

-w password - Directory Manager's password

-w -- Prompt for Directory Manager's password

-j filename - Read Directory Manager's password from file

-Z serverID - Server instance identifer

-n backendname- Backend database name.Example: userRoot

-t attributeName[:indextypes[:matchingrules]]

- attributeName: name of the attribute to be indexed

If omitted, all the indexes defined for that instance are generated.

- indextypes: comma separated index types

- matchingrules: comma separated matrules

Example: -t foo:eq,pres

-T vlvTag - VLV index name

-P protocol - STARTTLS, LDAPS, LDAPI, LDAP (default: uses most
secure protocol available)

-h- Display usage

[root@ipa2 ~]#


I am not familar with 389 DB, worry about making mistake here.
Will you please help with the syntax? Thanks.

Kathy.

On Mon, Mar 28, 2022 at 11:44 AM Mark Reynolds
 wrote:

Kathy,

You need to make sure there are equality indexes for the
following attributes:

  * changenumber
  * targetuniqueid

Run these commands on all your servers:

# ldapmodify -D "cn=directory manager" -W
dn: cn=changenumber,cn=index,cn=userroot,cn=ldbm
database,cn=plugins,cn=config
changetype: add
objectClass: top
objectClass: nsIndex
cn: changenumber
nsSystemIndex: false
nsIndexType: eq


# ldapmodify -D "cn=directory manager" -W
dn: cn=targetuniqueid,cn=index,cn=userroot,cn=ldbm
database,cn=plugins,cn=config
changetype: add
objectClass: top
objectClass: nsIndex
cn: targetuniqueid
nsSystemIndex: false
nsIndexType: eq

You might already have one of these indexes already present,
so if you get an error 68 (already exists) it's ok.  I think
changenumber is already present, but targetuniqueid is the
one that is missing.

Then you need to index these attributes:

    # db2index.pl  -D "cn=directory
manager" -w - -n userroot -t changenumber:eq -a targetuniqueid:eq


That should do it.

HTH,

Mark


On 3/28/22 1:50 PM, Kathy Zhu via FreeIPA-users wrote:

Happy Monday, List!

On my IPA server, top shows dirsrv using lots of resources,
when checking, I found this:

[root@ipa2 ~]# systemctl status dirsrv@EXAMPLE-COM.service -l

...

Mar 28 09:29:56 ipa2.example.com 
ns-slapd[1945]: [28/Mar/2022:09:29:56.142846906 -0700] -
NOTICE - ldbm_back_search - Internal unindexed search:
source (cn=server,cn=plugins,cn=config) search
base="cn=changelog" scope=2

filter="(&(changenumber>=-1)(targetuniqueid=7315af86-7b1911e8-83e6fb86-bfdbf4a5))"
conn=0 op=0

Mar 28 09:31:14 ipa2.example.com 
ns-slapd[1945]: [28/Mar/2022:09:31:14.176933263 -0700] - ERR
- log_result - Internal unindexed search: source
(cn=server,cn=plugins,cn=config) search base="cn=changelog"

filter="(&(changenumber>=-1)(targetuniqueid=7315af86-7b1911e8-83e6fb86-bfdbf4a5))"
etime=78.977553767 nentries=459824notes=A

Mar 28 09:31:23 ipa2.example.com 
ns-slapd[1945]: [28/Mar/2022:09:31:23.311185621 -0700] -
NOTICE - ldbm_back_search - Internal unindexed search:
source (cn=server,cn=plugins,cn=config) search
base="cn=changelog" scope=2

filter="(&(changenumbe

[Freeipa-users] Re: ERR - log_result - Internal unindexed search

[Mark Reynolds via FreeIPA-users]

Ugh, sorry had a typo, each attribute is specified with "-t".  So 
replace the "-a" with a "-t":


db2index.pl  -D "cn=directory manager" -w Nur09089 
-n userroot -t changenumber:eq -t targetuniqueid:eq


Mark

On 3/28/22 3:44 PM, Kathy Zhu wrote:

Hi Mark,

Thank you! After modifying the DB, when tried to index, I ran into:

[root@ipa2 ~]# db2index.pl  -D "cn=directory 
manager" -w Nur09089 -n userroot -t changenumber:eq -a targetuniqueid:eq


ERROR - Unknown option: -a

Usage: db2index.pl  [-Z serverID] [-D rootdn] { -w 
password | -w - | -j filename } [-P protocol]


-n backendname [-t attributeName[:indextypes[:matchingrules]]] [-T 
vlvTag] [-h]


Options:

-D rootdn - Directory Manager

-w password - Directory Manager's password

-w -- Prompt for Directory Manager's password

-j filename - Read Directory Manager's password from file

-Z serverID - Server instance identifer

-n backendname- Backend database name.Example: userRoot

-t attributeName[:indextypes[:matchingrules]]

- attributeName: name of the attribute to be indexed

If omitted, all the indexes defined for that instance are generated.

- indextypes: comma separated index types

- matchingrules: comma separated matrules

Example: -t foo:eq,pres

-T vlvTag - VLV index name

-P protocol - STARTTLS, LDAPS, LDAPI, LDAP (default: uses most secure 
protocol available)


-h- Display usage

[root@ipa2 ~]#


I am not familar with 389 DB, worry about making mistake here. Will 
you please help with the syntax? Thanks.


Kathy.

On Mon, Mar 28, 2022 at 11:44 AM Mark Reynolds  
wrote:


Kathy,

You need to make sure there are equality indexes for the following
attributes:

  * changenumber
  * targetuniqueid

Run these commands on all your servers:

# ldapmodify -D "cn=directory manager" -W
dn: cn=changenumber,cn=index,cn=userroot,cn=ldbm
database,cn=plugins,cn=config
changetype: add
objectClass: top
objectClass: nsIndex
cn: changenumber
nsSystemIndex: false
nsIndexType: eq


# ldapmodify -D "cn=directory manager" -W
dn: cn=targetuniqueid,cn=index,cn=userroot,cn=ldbm
database,cn=plugins,cn=config
changetype: add
objectClass: top
objectClass: nsIndex
cn: targetuniqueid
nsSystemIndex: false
nsIndexType: eq

You might already have one of these indexes already present, so if
you get an error 68 (already exists) it's ok.  I think
changenumber is already present, but targetuniqueid is the one
that is missing.

Then you need to index these attributes:

    # db2index.pl  -D "cn=directory manager"
-w - -n userroot -t changenumber:eq -a targetuniqueid:eq


That should do it.

HTH,

Mark


On 3/28/22 1:50 PM, Kathy Zhu via FreeIPA-users wrote:

Happy Monday, List!

On my IPA server, top shows dirsrv using lots of resources, when
checking, I found this:

[root@ipa2 ~]# systemctl status dirsrv@EXAMPLE-COM.service -l

...

Mar 28 09:29:56 ipa2.example.com 
ns-slapd[1945]: [28/Mar/2022:09:29:56.142846906 -0700] - NOTICE -
ldbm_back_search - Internal unindexed search: source
(cn=server,cn=plugins,cn=config) search base="cn=changelog"
scope=2

filter="(&(changenumber>=-1)(targetuniqueid=7315af86-7b1911e8-83e6fb86-bfdbf4a5))"
conn=0 op=0

Mar 28 09:31:14 ipa2.example.com 
ns-slapd[1945]: [28/Mar/2022:09:31:14.176933263 -0700] - ERR -
log_result - Internal unindexed search: source
(cn=server,cn=plugins,cn=config) search base="cn=changelog"

filter="(&(changenumber>=-1)(targetuniqueid=7315af86-7b1911e8-83e6fb86-bfdbf4a5))"
etime=78.977553767 nentries=459824notes=A

Mar 28 09:31:23 ipa2.example.com 
ns-slapd[1945]: [28/Mar/2022:09:31:23.311185621 -0700] - NOTICE -
ldbm_back_search - Internal unindexed search: source
(cn=server,cn=plugins,cn=config) search base="cn=changelog"
scope=2

filter="(&(changenumber>=-1)(targetuniqueid=7315af86-7b1911e8-83e6fb86-bfdbf4a5))"
conn=0 op=0

...

Googled and found this bug -
https://bugzilla.redhat.com/show_bug.cgi?id=1951020


However, the bug is for Red Hat 8.3 while we are in Centos 7.9:


CentOS Linux release 7.9.2009 (Core)

ipa-*server*.x86_64 4.6.8-5.el7.centos.7

*slapi-nis*.x86_640.56.5-3.el7_9

*389*-ds-base.x86_641.3.10.2-12.el7_9

*389*-ds-base-libs.x86_64 1.3.10.2-12.el7_9


Any idea of what's going on and how to fix it?


Thanks!


Kathy.



___
FreeIPA-users mailing list --freeipa-users@lists.fedorahosted.org
To unsubscribe send an email tofreeipa-users-le...@lists.fedorahosted.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list

[Freeipa-users] Re: ERR - log_result - Internal unindexed search

[Mark Reynolds via FreeIPA-users]

Kathy,

You need to make sure there are equality indexes for the following 
attributes:


 * changenumber
 * targetuniqueid

Run these commands on all your servers:

# ldapmodify -D "cn=directory manager" -W
dn: cn=changenumber,cn=index,cn=userroot,cn=ldbm 
database,cn=plugins,cn=config

changetype: add
objectClass: top
objectClass: nsIndex
cn: changenumber
nsSystemIndex: false
nsIndexType: eq


# ldapmodify -D "cn=directory manager" -W
dn: cn=targetuniqueid,cn=index,cn=userroot,cn=ldbm 
database,cn=plugins,cn=config

changetype: add
objectClass: top
objectClass: nsIndex
cn: targetuniqueid
nsSystemIndex: false
nsIndexType: eq

You might already have one of these indexes already present, so if you 
get an error 68 (already exists) it's ok.  I think changenumber is 
already present, but targetuniqueid is the one that is missing.


Then you need to index these attributes:

    # db2index.pl -D "cn=directory manager" -w - -n userroot -t 
changenumber:eq -a targetuniqueid:eq



That should do it.

HTH,

Mark


On 3/28/22 1:50 PM, Kathy Zhu via FreeIPA-users wrote:

Happy Monday, List!

On my IPA server, top shows dirsrv using lots of resources, when 
checking, I found this:


[root@ipa2 ~]# systemctl status dirsrv@EXAMPLE-COM.service -l

...

Mar 28 09:29:56 ipa2.example.com  
ns-slapd[1945]: [28/Mar/2022:09:29:56.142846906 -0700] - NOTICE - 
ldbm_back_search - Internal unindexed search: source 
(cn=server,cn=plugins,cn=config) search base="cn=changelog" scope=2 
filter="(&(changenumber>=-1)(targetuniqueid=7315af86-7b1911e8-83e6fb86-bfdbf4a5))" 
conn=0 op=0


Mar 28 09:31:14 ipa2.example.com  
ns-slapd[1945]: [28/Mar/2022:09:31:14.176933263 -0700] - ERR - 
log_result - Internal unindexed search: source 
(cn=server,cn=plugins,cn=config) search base="cn=changelog" 
filter="(&(changenumber>=-1)(targetuniqueid=7315af86-7b1911e8-83e6fb86-bfdbf4a5))" 
etime=78.977553767 nentries=459824notes=A


Mar 28 09:31:23 ipa2.example.com  
ns-slapd[1945]: [28/Mar/2022:09:31:23.311185621 -0700] - NOTICE - 
ldbm_back_search - Internal unindexed search: source 
(cn=server,cn=plugins,cn=config) search base="cn=changelog" scope=2 
filter="(&(changenumber>=-1)(targetuniqueid=7315af86-7b1911e8-83e6fb86-bfdbf4a5))" 
conn=0 op=0


...

Googled and found this bug - 
https://bugzilla.redhat.com/show_bug.cgi?id=1951020



However, the bug is for Red Hat 8.3 while we are in Centos 7.9:


CentOS Linux release 7.9.2009 (Core)

ipa-*server*.x86_64 4.6.8-5.el7.centos.7

*slapi-nis*.x86_640.56.5-3.el7_9

*389*-ds-base.x86_641.3.10.2-12.el7_9

*389*-ds-base-libs.x86_64 1.3.10.2-12.el7_9


Any idea of what's going on and how to fix it?


Thanks!


Kathy.



___
FreeIPA-users mailing list --freeipa-users@lists.fedorahosted.org
To unsubscribe send an email tofreeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report 
it:https://pagure.io/fedora-infrastructure


--
Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: parse the audit logs

[Mark Reynolds via FreeIPA-users]

On 1/26/22 8:51 PM, Kathy Zhu via FreeIPA-users wrote:
Thanks both Rob and Mark for your replies! Take user creation as an 
example:


in /var/log/httpd/error_log:

via GUI -  what, when and who
via CLI - what, when and admin (since admin privilege is needed)

in /var/log/dirsrv/slapd-EXAMPLE-COM/audit:

via GUI - what, when and who (dn of creatorsName and modifiersName)
via CLI - what, when and admin (dn of creatorsName and modifiersName)

Above example shows that if the user is created via GUI, the audit 
information is good. If via CLI, "who" is admin instead.


Inside audit log, the values of modifiersname are "Directory Manager", 
admin, "krbprincipalname=ldap/..." and so on, while I am looking for a 
particular user.


in /var/log/dirsrv/slapd-EXAMPLE-COM/access log, there is a "conn" 
number associated with each line, I'd love to get the instruction how 
to enable "conn" number in audit log, I can use it find out "from where".


Sorry there is no way to do it yet.  It would be an RFE, and probably a 
new config attribute nsslapd-auditlog-level in Directory Server.  I can 
not promise how soon the feature will be implemented, but file the RFE 
here: https://github.com/389ds/389-ds-base/issues/new/choose


Thanks,

Mark



Thanks.

Kathy.

On Wed, Jan 26, 2022 at 12:10 PM Mark Reynolds  
wrote:



On 1/26/22 1:02 PM, Kathy Zhu via FreeIPA-users wrote:

Thanks Mark and Florence for your replies!

I will check directory389 list to see if there is any useful
information.

By turning on audit logging, we'd like to have a record of what
was changed, when and by whom. For example, we should be able to
answer when and who added the user XYZ.  Unfortunately, IPA's
audit logging isn't great to serve that purpose, it provides
information of what and when, not by whom (modifiersname field is
useless).


Why is modifiersname useless?  It would be the Bind DN that
performed the operation -> the "Who".  The LDAP server only knows
of "who" by it's LDAP DN and there is no other value it could
use.  The "What" is the "dn", and the "When" is the "time" stamp
in the audit log entry.

For the "Where", you would need to know the connection ID.  Then
the access log could be parsed to find the IP address of the
client.  Technically the conn ID could be added to the audit log,
but changing the logging format is problematic as people are
already parsing our logs and every time we change the format we
get complaints.

Sorry I guess I still don't understand what is missing.  From my
standpoint we already provide the Who, What, and When in the audit
log (from the DS perspective).  Perhaps the specific info you want
is not available in the LDAP server?

Mark



For others facing similar situations, I found filebeat does the
track, it can combine multiple lines of logs to a single line
before forwarding the logs, which is searchable.

Thanks.

Kathy.


On Wed, Jan 26, 2022 at 10:40 AM Rob Crittenden  
wrote:

Kathy Zhu via FreeIPA-users wrote:
> Thanks Mark and Florence for your replies!
>
> I will check directory389 list to see if there is any useful 
information.

>
> By turning on audit logging, we'd like to have a record of what was
> changed, when and by whom. For example, we should be able to answer when
> and who added the user XYZ.  Unfortunately, IPA's audit logging isn't
> great to serve that purpose, it provides information of what and when,
> not by whom (modifiersname field is useless).

The IPA audit log is the apache error log.

Adding a user you'll see something like:

[Wed Jan 26 13:38:57.762988 2022] [wsgi:error] [pid 1475984:tid 1476323]
[remote 192.168.166.203:46788 ] ipa: 
INFO: [jsonserver_session]

tu...@example.test: user_add/1('suser', givenname='some', sn='user',
version='2.245'): SUCCESS

So user tuser added user suser successfully today at 1:30pm.

rob
>
> For others facing similar situations, I found filebeat does the track,
> it can combine multiple lines of logs to a single line before forwarding
> the logs, which is searchable.
>
> Thanks.
>
> Kathy.
>



On Wed, Jan 26, 2022 at 8:21 AM Mark Reynolds
 wrote:

The audit log is essentially just a list of LDIF commands. 
If you remove the "time" and "result" lines you can redirect
the log straight to ldapmodify:


time: 20220126111500
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
result: 0
changetype: modify
replace: nsslapd-lookthroughlimit
nsslapd-lookthroughlimit: 5001
-
replace: modifiersname
modifiersname: cn=dm
-
replace: modifytimestamp
modifytimestamp: 20220126161500Z
-


I'm not sure this log is worth "parsing" since it's just
describing the exact changes made to the server, and I'm not
sure there are that many any useful "sta

[Freeipa-users] Re: parse the audit logs

[Mark Reynolds via FreeIPA-users]

On 1/26/22 1:02 PM, Kathy Zhu via FreeIPA-users wrote:

Thanks Mark and Florence for your replies!

I will check directory389 list to see if there is any useful information.

By turning on audit logging, we'd like to have a record of what was 
changed, when and by whom. For example, we should be able to answer 
when and who added the user XYZ.  Unfortunately, IPA's audit logging 
isn't great to serve that purpose, it provides information of what and 
when, not by whom (modifiersname field is useless).


Why is modifiersname useless?  It would be the Bind DN that performed 
the operation -> the "Who".  The LDAP server only knows of "who" by it's 
LDAP DN and there is no other value it could use.  The "What" is the 
"dn", and the "When" is the "time" stamp in the audit log entry.


For the "Where", you would need to know the connection ID.  Then the 
access log could be parsed to find the IP address of the client.  
Technically the conn ID could be added to the audit log, but changing 
the logging format is problematic as people are already parsing our logs 
and every time we change the format we get complaints.


Sorry I guess I still don't understand what is missing.  From my 
standpoint we already provide the Who, What, and When in the audit log 
(from the DS perspective).  Perhaps the specific info you want is not 
available in the LDAP server?


Mark



For others facing similar situations, I found filebeat does the track, 
it can combine multiple lines of logs to a single line before 
forwarding the logs, which is searchable.


Thanks.

Kathy.

On Wed, Jan 26, 2022 at 8:21 AM Mark Reynolds  wrote:

The audit log is essentially just a list of LDIF commands.  If you
remove the "time" and "result" lines you can redirect the log
straight to ldapmodify:


time: 20220126111500
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
result: 0
changetype: modify
replace: nsslapd-lookthroughlimit
nsslapd-lookthroughlimit: 5001
-
replace: modifiersname
modifiersname: cn=dm
-
replace: modifytimestamp
modifytimestamp: 20220126161500Z
-


I'm not sure this log is worth "parsing" since it's just
describing the exact changes made to the server, and I'm not sure
there are that many any useful "stats" that could be gained by
parsing it.  What exactly are you hoping to get out of it?

Mark

On 1/26/22 11:05 AM, Florence Blanc-Renaud via FreeIPA-users wrote:

Hi,
You should try with 389-us...@lists.fedoraproject.org

,
other users may have found a solution to your problem.
flo

On Fri, Jan 21, 2022 at 6:45 PM Kathy Zhu  wrote:

Yes, correct, Florence.

BTW, Florence, I'd like to take this opportunity to let you
know that I benefit from your blog, especially the one about
certificates.

Thanks!

Kathy.

On Fri, Jan 21, 2022 at 1:17 AM Florence Blanc-Renaud
 wrote:

Hi Kathy,
which log file are you referring to? 389-ds audit log in
/var/log/dirsrv/slapd-xxx/audit?

flo

On Thu, Jan 20, 2022 at 6:43 PM Kathy Zhu via
FreeIPA-users  wrote:

Hello list,

I had FreeIPA audit log on. I feed audit logs to
Graylog. Since there are multiple lines of logs for
each event, I could not find a suitable extractor to
parse the logs. Therefore, the logs are very hard to
read. Could anyone in the list share how you process
the logs if you are in a similar situation?

Thanks!

Kathy.



___
FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure


___
FreeIPA-users mailing list --freeipa-users@lists.fedorahosted.org
To unsubscribe send an email tofreeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not 

[Freeipa-users] Re: parse the audit logs

[Mark Reynolds via FreeIPA-users]

The audit log is essentially just a list of LDIF commands.  If you 
remove the "time" and "result" lines you can redirect the log straight 
to ldapmodify:



time: 20220126111500
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
result: 0
changetype: modify
replace: nsslapd-lookthroughlimit
nsslapd-lookthroughlimit: 5001
-
replace: modifiersname
modifiersname: cn=dm
-
replace: modifytimestamp
modifytimestamp: 20220126161500Z
-


I'm not sure this log is worth "parsing" since it's just describing the 
exact changes made to the server, and I'm not sure there are that many 
any useful "stats" that could be gained by parsing it.  What exactly are 
you hoping to get out of it?


Mark

On 1/26/22 11:05 AM, Florence Blanc-Renaud via FreeIPA-users wrote:

Hi,
You should try with 389-us...@lists.fedoraproject.org 
, 
other users may have found a solution to your problem.

flo

On Fri, Jan 21, 2022 at 6:45 PM Kathy Zhu  wrote:

Yes, correct, Florence.

BTW, Florence, I'd like to take this opportunity to let you know
that I benefit from your blog, especially the one about certificates.

Thanks!

Kathy.

On Fri, Jan 21, 2022 at 1:17 AM Florence Blanc-Renaud
 wrote:

Hi Kathy,
which log file are you referring to? 389-ds audit log in
/var/log/dirsrv/slapd-xxx/audit?

flo

On Thu, Jan 20, 2022 at 6:43 PM Kathy Zhu via FreeIPA-users
 wrote:

Hello list,

I had FreeIPA audit log on. I feed audit logs to Graylog.
Since there are multiple lines of logs for each event, I
could not find a suitable extractor to parse the logs.
Therefore, the logs are very hard to read. Could anyone in
the list share how you process the logs if you are in a
similar situation?

Thanks!

Kathy.



___
FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure


___
FreeIPA-users mailing list --freeipa-users@lists.fedorahosted.org
To unsubscribe send an email tofreeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report 
it:https://pagure.io/fedora-infrastructure


--
Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: IPA slapd parameter tuning

[Mark Reynolds via FreeIPA-users]

On 9/16/21 5:20 PM, Kathy Zhu via FreeIPA-users wrote:

Hi List,

One of my ipa server's database had issue and left many log entries 
like the following in messages and slapd errors log:


*Sep 16 08*:34:28 ipa0 ns-slapd: [16/Sep/2021:08:34:28.886632992 
-0700] - ERR - libdb - BDB0060 PANIC: fatal region error detected; run 
recovery


*Sep 16 08*:34:29 ipa0 ns-slapd: [16/Sep/2021:08:34:28.987593487 
-0700] - ERR - libdb - BDB0060 PANIC: fatal region error detected; run 
recovery


*Sep 16 08*:34:29 ipa0 ns-slapd: [16/Sep/2021:08:34:29.035181321 
-0700] - ERR - libdb - BDB0060 PANIC: fatal region error detected; run 
recovery


Is there anything else in the error log around these messages?  This is 
kind of a generic error, and increasing the DN cache is not a guarantee 
it will resolve this.


Restart ipa fixed the issue. I googled for root cause and found the 
verified solution - https://access.redhat.com/solutions/3098131 
, which is to increase 
nsslapd-dncachememsize to a reasonable value (>150MB). This sounds 
like easy, however, all slapd cache parameters are related. Red Hat 
Directory Server performance tuning guide explain a bit:


https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/performance_tuning_guide/memoryusage 



However, I wonder if there is a better guide.


Not really :-)  There is a RHDS 11 version, but I think the performance 
tuning part is the same as RHDS 10.



Mark



Thanks.

Kathy.

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


--
Directory Server Development Team

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: FreeIPA - Replica - Install

[Mark Reynolds via FreeIPA-users]

Yes this was a problem.  Schema replciation was failing because version 
of the entryuuid pugin added a new syntax plugin, which can not be 
replicated.  So it broke replication and would lead to errors like this.


The minimum version of 389-ds-base-2.x you need is:

    389-ds-base-2.0.8

This version will work with older versions of DS.

HTH,

Mark

On 9/9/21 10:00 AM, François Cami wrote:

Hi,

I think this is related to the DS versions being different in f33 and f34.
f33 has 389-ds-base-1.4 and f34 has 2.0.x.
It sounds like:
https://github.com/389ds/389-ds-base/issues/4498#issuecomment-744335466

Could you post the exact versions of DS you are using?

Thank you,
François


On Thu, Sep 9, 2021 at 3:47 PM Mathias Rumbold via FreeIPA-users
 wrote:

Hello Community!

I am trying to add a new Fedora 34 server as secondary master. The idm01 is 
still Fedora 33 but versions are the same as I can see.

The issue I am hitting is by installing the replication (Client works fine).

Configuring the web interface (httpd)
   [1/21]: stopping httpd
   [2/21]: backing up ssl.conf
   [3/21]: disabling nss.conf
   [4/21]: configuring mod_ssl certificate paths
   [5/21]: setting mod_ssl protocol list
   [6/21]: configuring mod_ssl log directory
   [7/21]: disabling mod_ssl OCSP
   [8/21]: adding URL rewriting rules
   [9/21]: configuring httpd
   [10/21]: setting up httpd keytab
   [11/21]: configuring Gssproxy
   [12/21]: setting up ssl
   [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE: Server at 
https://idm01.example.com/ipa/json failed request, will retry: 4205 (attribute 
"entryuuid" not allowed).)
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Certificate issuance failed (CA_UNREACHABLE: Server at https://idm01.example.com/ipa/json 
failed request, will retry: 4205 (attribute "entryuuid" not allowed).)
The ipa-replica-install command failed. See /var/log/ipareplica-install.log for 
more information


Log files:
2021-09-08T11:33:07Z DEBUG   -> Not backing up - '/etc/httpd/conf.d/ipa.conf' 
doesn't exist
2021-09-08T11:33:07Z DEBUG Backing up system configuration file 
'/etc/httpd/conf.d/ipa-rewrite.conf'
2021-09-08T11:33:07Z DEBUG   -> Not backing up - 
'/etc/httpd/conf.d/ipa-rewrite.conf' doesn't exist
2021-09-08T11:33:07Z DEBUG step duration: httpd __configure_http 0.26 sec
2021-09-08T11:33:07Z DEBUG   [10/21]: setting up httpd keytab
2021-09-08T11:33:07Z DEBUG raw: 
service_add('HTTP/idm02.example@example.com', force=True, version='2.242')
2021-09-08T11:33:07Z DEBUG 
service_add(ipapython.kerberos.Principal('HTTP/idm02.example@example.com'), 
force=True, skip_host_check=False, all=False, raw=False, version='2.242', 
no_members=False)
2021-09-08T11:33:07Z DEBUG flushing ldapi://%2Frun%2Fslapd-TALHEIM-IT-AT.socket 
from SchemaCache
2021-09-08T11:33:07Z DEBUG retrieving schema for SchemaCache 
url=ldapi://%2Frun%2Fslapd-TALHEIM-IT-AT.socket 
conn=
2021-09-08T11:33:08Z DEBUG raw: host_show('idm02.example.com', version='2.242')
2021-09-08T11:33:08Z DEBUG host_show('idm02.example.com', rights=False, 
all=False, raw=False, version='2.242', no_members=False)
2021-09-08T11:33:08Z DEBUG Backing up system configuration file 
'/var/lib/ipa/gssproxy/http.keytab'
2021-09-08T11:33:08Z DEBUG   -> Not backing up - 
'/var/lib/ipa/gssproxy/http.keytab' doesn't exist
2021-09-08T11:33:08Z DEBUG Starting external process
2021-09-08T11:33:08Z DEBUG args=['/usr/sbin/ipa-getkeytab', '-k', 
'/var/lib/ipa/gssproxy/http.keytab', '-p', 
'HTTP/idm02.example@example.com', '-H', 
'ldapi://%2Frun%2Fslapd-TALHEIM-IT-AT.socket', '-Y', 'EXTERNAL']
2021-09-08T11:33:08Z DEBUG Process finished, return code=0
2021-09-08T11:33:08Z DEBUG stdout=
2021-09-08T11:33:08Z DEBUG stderr=Keytab successfully retrieved and stored in: 
/var/lib/ipa/gssproxy/http.keytab

2021-09-08T11:33:08Z DEBUG Waiting up to 300 seconds for replication 
(ldap://idm01.example.com:389) 
krbprincipalname=HTTP/idm02.example@example.com,cn=services,cn=accounts,dc=talheim-it,dc=at
 (objectclass=*)
2021-09-08T11:33:09Z DEBUG Entry found 
[LDAPEntry(ipapython.dn.DN('krbprincipalname=HTTP/idm02.example@example.com,cn=services,cn=accounts,dc=talheim-it,dc=at'),
 {'krbLastPwdChange': [b'20210908113308Z'], 'krbCanonicalName': 
[b'HTTP/idm02.example@example.com'], 'objectClass': [b'krbprincipal', 
b'krbprincipalaux', b'krbticketpolicyaux', b'ipaobject', b'ipaservice', 
b'pkiuser', b'ipakrbprincipal', b'top'], 'managedBy': 
[b'fqdn=idm02.example.com,cn=computers,cn=accounts,dc=talheim-it,dc=at'], 
'ipaKrbPrincipalAlias': [b'HTTP/idm02.example@example.com'], 
'krbPrincipalName': [b'HTTP/idm02.example@example.com'], 'ipaUniqueID': 
[b'8a3a99ec-1098-11ec-b7a5-86d9fd13']})]
2021-09-08T11:33:09Z DEBUG step duration: httpd request_service_keytab 1.56 sec
2021-09-08T11:33:09Z DEBUG   [11/21]: configuring Gssproxy
2021-09-08T11:33:09Z DEBUG Starting external process
2021-09-08T11:33:09Z DEBUG args=[

[Freeipa-users] Re: Hard Crash of Server Corrupted IPA

[Mark Reynolds via FreeIPA-users]

On 8/10/21 10:41 AM, Rob Crittenden via FreeIPA-users wrote:

Auerbach, Steven wrote:

[10/Aug/2021:09:03:52.832686801 -0400] - NOTICE - dblayer_start - Detected 
Disorderly Shutdown last time Directory Server was running, recovering database.
[10/Aug/2021:09:03:53.307038716 -0400] - ERR - libdb - BDB2506 file 
/var/lib/dirsrv/slapd-FBOG-LOCAL/cldb/21741a1f-b31a11ea-ac83c7bf-de3c3622_5eded6dc0060.db
 has LSN 1859/5569522, past end of log at 1859/5527979
[10/Aug/2021:09:03:53.309248835 -0400] - ERR - libdb - BDB2507 Commonly caused 
by moving a database from one database environment
[10/Aug/2021:09:03:53.310844909 -0400] - ERR - libdb - BDB2508 to another 
without clearing the database LSNs, or by removing all of
[10/Aug/2021:09:03:53.312311253 -0400] - ERR - libdb - BDB2509 the log files 
from a database environment
[10/Aug/2021:09:03:53.313770893 -0400] - ERR - libdb - BDB1521 Recovery 
function for LSN 1859 5496332 failed
[10/Aug/2021:09:03:53.315181085 -0400] - ERR - libdb - BDB0061 PANIC: Invalid 
argument
[10/Aug/2021:09:03:53.327435763 -0400] - ERR - libdb - BDB1546 unable to join 
the environment
[10/Aug/2021:09:03:53.343830873 -0400] - CRIT - dblayer_start - Database 
Recovery Process FAILED. The database is not recoverable. err=-30973: BDB0087 
DB_RUNRECOVERY: Fatal error, run database recovery
[10/Aug/2021:09:03:53.345786469 -0400] - CRIT - dblayer_start - Please make 
sure there is enough disk space for dbcache (1610612736 bytes) and db region 
files
[10/Aug/2021:09:03:53.347245636 -0400] - ERR - ldbm_back_start - Failed to init 
database, err=-30973 BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
[10/Aug/2021:09:03:53.349104988 -0400] - ERR - plugin_dependency_startall - 
Failed to start database plugin ldbm database
[10/Aug/2021:09:03:53.350954638 -0400] - ERR - schema-compat-plugin - scheduled 
schema-compat-plugin tree scan in about 5 seconds after the server startup!
[10/Aug/2021:09:03:53.353877687 -0400] - WARN - 
ldbm_instance_add_instance_entry_callback - ldbm instance userRoot already 
exists
[10/Aug/2021:09:03:53.355345539 -0400] - ERR - 
ldbm_config_read_instance_entries - Failed to add instance entry 
cn=userRoot,cn=ldbm database,cn=plugins,cn=config
[10/Aug/2021:09:03:53.356791214 -0400] - ERR - ldbm_config_load_dse_info - 
failed to read instance entries
[10/Aug/2021:09:03:53.35806 -0400] - ERR - ldbm_back_start - Loading 
database configuration failed
[10/Aug/2021:09:03:53.359235194 -0400] - ERR - plugin_dependency_startall - 
Failed to start database plugin ldbm database
[10/Aug/2021:09:03:53.36476 -0400] - ERR - plugin_dependency_startall - 
Failed to resolve plugin dependencies
[10/Aug/2021:09:03:53.360703493 -0400] - ERR - plugin_dependency_startall - 
betxnpreoperation plugin 7-bit check is not started
[10/Aug/2021:09:03:53.361576474 -0400] - ERR - plugin_dependency_startall - 
preoperation plugin Account Usability Plugin is not started
[10/Aug/2021:09:03:53.362552803 -0400] - ERR - plugin_dependency_startall - 
accesscontrol plugin ACL Plugin is not started
[10/Aug/2021:09:03:53.363610744 -0400] - ERR - plugin_dependency_startall - 
preoperation plugin ACL preoperation is not started
[10/Aug/2021:09:03:53.364277146 -0400] - ERR - plugin_dependency_startall - 
betxnpreoperation plugin Auto Membership Plugin is not started
[10/Aug/2021:09:03:53.365004305 -0400] - ERR - plugin_dependency_startall - 
preoperation plugin caacl name uniqueness is not started
[10/Aug/2021:09:03:53.365741513 -0400] - ERR - plugin_dependency_startall - 
preoperation plugin certificate store issuer/serial uniqueness is not started
more things not started in the log.

There are 39 GB available on root filesystem so that should meet the " make sure 
there is enough disk space for dbcache (1610612736 bytes) and db region files" 
recommendation
If database recovery fails (Database Recovery Process FAILED. The database is 
not recoverable. err=-30973: BDB0087 DB_RUNRECOVERY: Fatal error, run database 
recovery), what do we do?

I'd try db_recover first. Change to the database directory in
/var/lib/dirsrv/slapd-FBOG-LOCAL/db

Then run:

# db_recover -c -f -v

-c catastrophic recovery
-f progress
-v verbose



You might need to remove the changelog database completely, and then 
reinit this server:


rm -rf /var/lib/dirsrv/slapd-FBOG-LOCAL/cldb/*

The server might even start after doing this, but it will need to be 
inited since the changelog was removed.


HTH,
Mark



rob



-Steven

-Original Message-
From: Rob Crittenden 
Sent: Tuesday, August 10, 2021 9:19 AM
To: FreeIPA users list 
Cc: Shirley Schaeffer ; Simpson, Brett 
; Auerbach, Steven 
Subject: Re: [Freeipa-users] Hard Crash of Server Corrupted IPA

Auerbach, Steven via FreeIPA-users wrote:

A storage subsystem failure below our virtualization layer caused a
hard crash of our 2^nd IPA Master.  It will not start back up.

$ Systemctl status –l ipa

● ipa.service - Identity, Policy, Audit

    Loaded: loaded 

[Freeipa-users] Re: Allowing LDAP only via SSL?

[Mark Reynolds via FreeIPA-users]

On 8/3/21 6:34 AM, Sam Morris via FreeIPA-users wrote:

But is it possible to completely disable port 389 if we don't want
any client to ever try non-SSL connections?

That will block communication between IPA servers, and from clients to servers.


Just for completeness, setting nsslapd-port to zero will disable it, but 
as mentioned above it will break IPA, etc.


Mark



--
Sam Morris 
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9s?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


--
Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: ipahealthcheck.ds.dse.DSECheck.DSSKEWLE0003: The time skew is over 24 hours.

[Mark Reynolds via FreeIPA-users]

Hi Louis,

So these time skew errors typically happen when the system clock is 
adjusted.  Technically nothing is broken and replication is working, but 
if the time skew continues to "increase" it will cause problems 
eventually...


Out of curiosity, were any of these systems running on AWS?

Anyway to reset the CSN generators/timeskew there is this doc:

https://www.port389.org/docs/389ds/howto/howto-fix-and-reset-time-skew.html

If your time skew is not growing, and you don't want to go through the 
painful process of fixing it as described in the link above, you could 
just disable time skew as mentioned in the healthcheck report, and 
ignore these healthcheck warnings (for now healthcheck will still report 
skew errors even if nsslapd-ignore-time-skew is off).


Mark

On 7/29/21 1:29 PM, Louis Lagendijk via FreeIPA-users wrote:

Some time ago I hosed my freeipa setup (RHEL8, 3 servers), probably by
starting yum update pretty much at the same time, without realizing
that it would be better to spread it out a bit. This was at the time I
got the RHEL 8.4 updates.

One server seemed pretty messed up, so I deleted it from the topology
and re-executed the ipa-replica-install.
I deleted some duplicates from the replication, manally fixed the
password issue from https://github.com/dogtagpki/pki/issues/3650
on the re-installed server.

ipa-healthcheck now reports:

[root@ipa1 ipa-tools]# ipa-healthcheck --failures-only --output-type
human
CRITICAL: ipahealthcheck.ds.dse.DSECheck.DSSKEWLE0003: The time skew is
over 24 hours.  Setting nsslapd-ignore-time-skew
to "on" on each replica will allow replication to continue, but if the
time skew continues to increase other serious replication problems can
occur.
ERROR: ipahealthcheck.ds.dse.DSECheck.DSSKEWLE0002: The time skew is
over 12 hours.  If this time skew continues to increase
to 24 hours then replication can potentially stop working.  Please
continue to
monitor the time skew offsets for increasing values.  Setting nsslapd-
ignore-time-skew
to "on" on each replica will allow replication to continue, but if the
time skew
continues to increase other more serious replication problems can
occur.

I got the following from ds389:
[root@ipa1 ipa-tools]# dsctl slapd-HOME-FAZANT-NET get-nsstate
Replica
DN:   cn=replica,cn=dc\3dhome\2cdc\3dfazant\2cdc\3dnet,cn=mappi
ng tree,cn=config
Replica Suffix:   dc=home,dc=fazant,dc=net
Replica ID:   21
Gen Time: 1627578955
Gen Time String:  Thu Jul 29 19:15:55 2021
Gen as CSN:   6102e24b00040021
Local Offset: 0
Local Offset String:  0 seconds
Remote Offset:591807
Remote Offset String: 6 days, 20 hours, 23 minutes, 27 seconds
Time Skew:591807
Time Skew String: 6 days, 20 hours, 23 minutes, 27 seconds
Seq Num:  4
System Time:  Thu Jul 29 19:17:08 2021
Diff in Seconds:  73
Diff in days/secs:0:73
Endian:   Little Endian

Replica DN:   cn=replica,cn=o\3dipaca,cn=mapping tree,cn=config
Replica Suffix:   o=ipaca
Replica ID:   22
Gen Time: 1627578483
Gen Time String:  Thu Jul 29 19:08:03 2021
Gen as CSN:   6102e0730022
Local Offset: 0
Local Offset String:  0 seconds
Remote Offset:81231
Remote Offset String: 22 hours, 33 minutes, 51 seconds
Time Skew:81231
Time Skew String: 22 hours, 33 minutes, 51 seconds
Seq Num:  0
System Time:  Thu Jul 29 19:17:08 2021
Diff in Seconds:  545
Diff in days/secs:0:545
Endian:   Little Endian




I have no idea how to solve this issue. Apparently my google-fu is not
strong enough to find a solution. Can you guys please give me some
hints?

Thanks. Louis
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


--
Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: Changing IPA AD Account sync to new AD domain

[Mark Reynolds via FreeIPA-users]

On 7/14/21 11:27 AM, Rob Crittenden wrote:

Jim Kilborn via FreeIPA-users wrote:

We have migrated our AD users to a new domain (ie example.com -> examplenew.com)
and I now need to change our IPA AD sync replication to use the new
domain. I can remove the old replication agreement and create the new
one, but my question is what happens to the users accounts. The AD
usernames didnt change during the migration, but the SID will be
different due to it being a new account in a new domain. Will IPA just
associated that username with the one already in IPA, or will it try
to create another account with a different UID/GID in ipa?

I'm honestly not sure what will happen. I suspect it will associate the
user with the existing on in IPA, but otherwise not change anything.

So it won't see the new SID, for example.

But I really don't know. This is not something that we on the IPA team
tested at all.

cc'ing a 389 developer to see what they think.


From a replication perspective, if the data source changed in such a 
fashion, then a reinit would be required with the new agreement.  
Replication would not detect a "difference" in an entry, it only 
replicates changes from the replication changelog. So if you did not 
reinit then I suspect replication would not even work, or if it did, you 
would be in an inconsistent state.


HTH,

Mark



rob


--
Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: Deletion of dse.ldif - why/when?

[Mark Reynolds via FreeIPA-users]

It is not IPA deleting the dse.ldif, but possibly a startup/shutdown 
issue with Directory Server (389-ds-base).  There was a known bug about 
this, but it was fixed a few years ago. What version of 389-ds-base are 
you running?  Do you see any "Disorderly shutdown" messages in the DS 
errors log? (/var/log/dirsrv/slapd-YOUR_INSTANCE/errors)


For now moving dse.ldif.startOK to dse.ldif should be fine.

Thanks,

Mark

On 7/14/21 3:42 AM, lejeczek via FreeIPA-users wrote:

Hi guys.


I'd find these:
-rw---. 1 dirsrv root   221792 Jul  9 11:53 
/etc/dirsrv/.../dse.ldif.ipa.e70ef09741825387
-rw-rw. 1 dirsrv root   221845 Jul  9 11:53 
/etc/dirsrv/.../dse.ldif.modified.out
-rw---. 1 dirsrv dirsrv 221650 Jul 13 18:26 
/etc/dirsrv/.../dse.ldif.startOK
-rw---. 1 dirsrv dirsrv  0 Jul 13 18:28 
/etc/dirsrv/.../dse.ldif.bak


and not 'ldif' so IPA would fail for 'dirsrv' fails to start.
Use 'dse.ldif.startOK' as a source for a 'ldif' copy and IPA starts 
seemingly okey.


In what circumstances - that is, if that should happen at all - 
'dse.ldif' would be deleted by IPA?


many thanks, L
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to 
freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


--
Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: ipa migrate failing

[Mark Reynolds via FreeIPA-users]

Please provide the Directory Server access log snippet from this failure 
as well.


Thanks,
Mark

On 10/26/20 7:59 AM, Per Qvindesland via FreeIPA-users wrote:

Hi

While running the command:   echo password123 | ipa migrate-ds 
--with-compat ldap://ipofldap:389 
--bind-dn="cn=admin,dc=company,dc=com" --base-dn=dc=company,dc=com 
--user-container=ou=people --group-container=ou=groups --scope=subtree 
then it's failing with ipa:
ERROR: group LDAP search did not return any result (search base: 
ou=groups,dc=company,dc=com, objectclass: groupofuniquenames, 
groupofnames)


No matter how i change the command to ipa migrate-ds 
ldap://ldapserver:389 --bind-dn="cn=admin,dc=example,dc=com" then it 
still fails with the same error


Does anyone know how I can resolve this? in the sladp errors logs I 
see this:


[26/Oct/2020:11:18:18.622956777 +0100] - ERR - attrcrypt_init - All 
prepared ciphers are not available. Please disable attribute encryption.
[26/Oct/2020:11:18:19.228133838 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=groups,cn=compat,dc=example,dc=com does 
not exist
[26/Oct/2020:11:18:19.229323016 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=computers,cn=compat,dc=example,dc=com 
does not exist
[26/Oct/2020:11:18:19.229952707 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=ng,cn=compat,dc=example,dc=com does not 
exist
[26/Oct/2020:11:18:19.230652382 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target ou=sudoers,dc=example,dc=com does not exist
[26/Oct/2020:11:18:19.231285195 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=users,cn=compat,dc=example,dc=com does 
not exist
[26/Oct/2020:11:18:19.231934733 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=vaults,cn=kra,dc=example,dc=com does not 
exist
[26/Oct/2020:11:18:19.232593780 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=vaults,cn=kra,dc=example,dc=com does not 
exist
[26/Oct/2020:11:18:19.233232479 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=vaults,cn=kra,dc=example,dc=com does not 
exist
[26/Oct/2020:11:18:19.233866104 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=vaults,cn=kra,dc=example,dc=com does not 
exist
[26/Oct/2020:11:18:19.234486443 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=vaults,cn=kra,dc=example,dc=com does not 
exist
[26/Oct/2020:11:18:19.235118913 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=vaults,cn=kra,dc=example,dc=com does not 
exist
[26/Oct/2020:11:18:19.235747974 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=vaults,cn=kra,dc=example,dc=com does not 
exist
[26/Oct/2020:11:18:19.236394872 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=vaults,cn=kra,dc=example,dc=com does not 
exist
[26/Oct/2020:11:18:19.237060940 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=vaults,cn=kra,dc=example,dc=com does not 
exist
[26/Oct/2020:11:18:19.237715214 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=vaults,cn=kra,dc=example,dc=com does not 
exist
[26/Oct/2020:11:18:19.238356425 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=vaults,cn=kra,dc=example,dc=com does not 
exist
[26/Oct/2020:11:18:19.244588134 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=ad,cn=etc,dc=example,dc=com does not exist
[26/Oct/2020:11:18:19.246571311 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=casigningcert 
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=com does not exist
[26/Oct/2020:11:18:19.247223136 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=casigningcert 
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=com does not exist
[26/Oct/2020:11:18:19.343344230 +0100] - WARN - NSACLPlugin - 
acl_parse - The ACL target cn=automember rebuild 
membership,cn=tasks,cn=config does not exist
[26/Oct/2020:11:18:19.348552041 +0100] - ERR - cos-plugin - 
cos_dn_defs_cb - Skipping CoS Definition cn=Password 
Policy,cn=accounts,dc=example,dc=com--no CoS Templates found, which 
should be added before the CoS Definition.
[26/Oct/2020:11:18:19.378667333 +0100] - INFO - slapd_daemon - slapd 
started.  Listening on All Interfaces port 389 for LDAP requests
[26/Oct/2020:11:18:19.381366608 +0100] - INFO - slapd_daemon - 
Listening on All Interfaces port 636 for LDAPS requests
[26/Oct/2020:11:18:19.383976582 +0100] - INFO - slapd_daemon - 
Listening on /var/run/slapd-PROXDYNAMICS-COM.socket for LDAPI requests
[26/Oct/2020:11:24:47.858883691 +0100] - INFO - op_thread_cleanup - 
slapd shutting down - signaling operation threads - op stack size 1 
max work q size 2 max work q stack size 2
[26/Oct/2020:11:24:47.958419078 +0100] - INFO - slapd_daemon - slapd 
shutting down - closing down internal subsystems and plugins
[26/Oct/2020:11:24:49.018815611 +0100] - INFO - bdb_pre_close - 
Waiting for 4 database threads to stop
[26/Oct/2020:11:24:50.544575094 +0100] - INFO - bdb_pre_close - All 
database threads now sto

[Freeipa-users] Re: Change password hash for LDAP

[Mark Reynolds via FreeIPA-users]

You can change the password storage scheme using dsconf or ldapmodify 
depending on what version of 389-ds-base you have.  On 389-ds-base-1.4.x 
you can use "dsconf", on older versions you will need to use ldapmodify:


# dsconf slapd-YOUR_INSTANCE config replace passwordStorageScheme=SSHA512

Or

# ldapmodify -D "cn=directory manager" -W
dn: cn=config
changetype: modify
replace: passwordStorageScheme
passwordStorageScheme: SSHA512


This will not change your existing user's passwords, it will only change 
how new passwords are set.  So if some users' passwords are already 
hashed with PBKDF2_SHA256, then you need to reset the password to pick 
up the new scheme.


HTH,

Mark


On 6/29/20 3:20 PM, Max Muller via FreeIPA-users wrote:

Hi all!
I want use FreeIPA with FreeRADIUS. As I can know, FreeIPA use PBKDF2_SHA256 
hashes. But actual FreeRADIUS not support PBKDF2_SHA256 hashes.
Is there way to change hash in FreeIPA?

About FreeRADIUS and dsconf slapd-YOUR_INSTANCE config replace 
passwordStorageScheme=SSHA512 
https://github.com/FreeRADIUS/freeradius-server/issues/2649
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org


--

389 Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: cipher support and nsSSL3Ciphers: +all

[Mark Reynolds via FreeIPA-users]

On 6/16/20 6:07 PM, Chris Herdt via FreeIPA-users wrote:



On Tue, Jun 16, 2020 at 12:58 PM Chris Herdt > wrote:


I have an appliance that I want to use with our FreeIPA-provided
LDAP servers. The appliance only supports the following ciphers:

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)

I tried changing the following in dse.ldif, based on
http://www.port389.org/docs/389ds/design/nss-cipher-design.html:
|
|
|nsSSL3Ciphers: +all|

|This should allow all the ciphers that the NSS supports.||Keep in mind 
you do need to restart the server after changing |||nsSSL3Ciphers.

||

|Run this ldapsearch:|

|# ldapsearch -D "cn=directory manager" -W -xLLL -b 
cn=encryption,cn=config nsSSLEnabledCiphers nsSSLSupportedCiphers|


|This will show what is available to the server, and what is enabled. 
|Do you see your ciphers in the available list and/or enabled list?||


So can try to do:
|
|

|    nsSSL3Ciphers: 
+all,+||TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,+||TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,+||TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,+||TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA|


|Restart the server, check that ldapsearch command to see if these 
ciphers are now enabled.|


|HTH,|

|Mark
|


|
|
However, this enabled only the following 7 ciphers (based on the
output of nmap --script ssl-enum-ciphers -p 636
freeipa-01.example.com ):
|
|
|TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_SEED_CBC_SHA
|

Here's the content of the dn: cn=encryption,cn=config section:

dn: cn=encryption,cn=config
CACertExtractFile:
/etc/dirsrv/slapd-EXAMPLE-COM/CN3dUSERTrust20RSA20Certif
 
ication20Authority2cO3dThe20USERTRUST20Network2cL3dJersey20City2cST3dNew20Jer
 sey2cC3dUS.pem
allowWeakCipher: off
cn: encryption
createTimestamp: 20181108213233Z
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config
modifyTimestamp: 20181108213359Z
nsSSL3Ciphers: +all
nsSSLClientAuth: allowed
nsSSLSessionTimeout: 0
objectClass: top
objectClass: nsEncryptionConfig
sslVersionMin: TLS1.2
numSubordinates: 1

Any ideas why this change isn't enabling the additional ciphers?
Thanks!


I should have mentioned, my FreeIPA servers are running ipa-server 
4.6.6 on CentOS 7.8.



___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org


--

389 Directory Server Development Team

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Still issues with member_of

[Mark Reynolds via FreeIPA-users]

On 6/3/20 8:42 AM, Mary Georgiou via FreeIPA-users wrote:

Hello,
Thanks a lot for the prompt answer.

Could you clarify a bit more this point please:
"but if you are using nested groups then you can not set this:"


Sorry, so nested groups are where groups are members of other groups.  
For example:



dn: cn=group1,dc=example,dc=com
member:  uid=mark,ou=people,dc=example,dc=com
member:  uid=david,ou=people,dc=example,dc=com
member:  cn=group2,ou=groups,dc=example,dc=com


dn: cn=group2,ou=groups,dc=example,dc=com
member:  uid=steve,ou=people,dc=example,dc=com
member:  uid=jack,ou=people,dc=example,dc=com


So group2 is a member of group1, which means all of group2 members are 
technically members of group1.  This is very expensive to 
process/maintain, and if you aren't using "nested groups" then you can 
turn it off and get a performance gain.


Hope that clears things up.  Let me know if you have any other questions.

Thanks,
Mark



Do you mean if we have already groups with 'objectClass=nestedgroup'?
We do use nested groups, but it would be ok to disable the option and update 
them ourselves if this would fix the issue.
Best Regards
Mary
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org


--

389 Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Still issues with member_of

[Mark Reynolds via FreeIPA-users]

On 6/3/20 6:10 AM, Mary Georgiou via FreeIPA-users wrote:

Dear all,
We are still experiencing issues with the memberOf plugin for which you may 
have some advice.

We are constantly synchronizing accounts and groups into freeipa from external 
resources.
At each time we have approx 60.000+ users and 60.000+ groups, where there are 
groups with
more than 10.000 memberships.

In order to do the full first synchronization, we disabled memberOf and run the 
fixup afterward.
The problem is that we are still experiencing issues with the plugin when we 
have an update on groups that
requires modifying more than a certain number of memberships (more specifically 
the LDAP server stops being responsive).
I read here [1] that this is because the plugin is doing lots of recomputations 
each time a group is updated.

We thought of disabling the plugin for the user and group containers, and 
manage the memberOf ourselves (for the group memberships only) but then there's 
the issue of netgroups, roles, HBAC Rules, and sudo rules memberships.

Is there any advice on how to approach this? Any part of the configuration we 
should tweak?


The only option that might help is to disable "nested groups" in 
MemberOf plugin, but if you are using nested groups then you can not set 
this:


https://www.port389.org/docs/389ds/design/memberof-skip-nested.html

HTH,
Mark


Thank you very much in advance,
Mary Georgiou

[1] https://www.freeipa.org/page/V4/Performance_Improvements#memberof_fixup
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org


--

389 Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Issue with memberOf plugin.

[Mark Reynolds via FreeIPA-users]

On 5/7/20 4:38 AM, Mary Georgiou via FreeIPA-users wrote:

Hello,

In our set-up, we have a DB with all the users and groups, which we use as 
ground truth for provisioning the forementioned objects in FreeIPA (2 master 
servers + replicas).
We are continuously synchronizing entries (~6 users and 6 groups, where 
groups might have 0 to 2 members) from the DB to FreeIPA. In each cycle of 
synch, we are figuring out the differences and add, delete, or change existing 
entries.

The first sync (through which we had to import all 12 objects) clogged the 
server totally, and after tweaking the 389DS we ended up disabling the memberOf 
plugin where it finally worked (we followed the FreeIPA documentation[1]).
One of the advice to follow is to do the sync and then run the fixup task in 
the server where the provisioning happened.
The fixup still clogs the server after some point and stops.
The errors we get in the log are the following:

```
[06/May/2020:18:16:59.862308719 +0200] - INFO - memberof-plugin - 
memberof_fixup_task_thread - Memberof task starts (filter: 
"(|(objectclass=inetuser)(objectclass=inetadmin)(objectclass=nsmemberof))") ...
[06/May/2020:20:07:49.545606214 +0200] - ERR - libdb - BDB2055 Lock table is 
out of available lock entries
[06/May/2020:20:07:49.547921580 +0200] - ERR - idl_new_delete_key - idl_new.c 
BAD 22, err=12 Cannot allocate memory
[06/May/2020:20:07:49.548930035 +0200] - ERR - addordel_values_sv - database 
index operation failed BAD 1130, err=12 Cannot allocate memory
[06/May/2020:20:07:49.549779631 +0200] - ERR - addordel_values_sv - database 
index operation failed BAD 1140, err=12 Cannot allocate memory
[06/May/2020:20:07:49.550612745 +0200] - ERR - index_addordel_values_ext_sv - 
database index operation failed BAD 1230, err=12 Cannot allocate memory
[06/May/2020:20:07:49.551444741 +0200] - ERR - index_add_mods - database index 
operation failed BAD 1041, err=12 Cannot allocate memory
[06/May/2020:20:07:49.552457769 +0200] - ERR - index_add_mods - database index 
operation failed BAD 1040, err=12 Cannot allocate memory
[06/May/2020:20:07:49.553305019 +0200] - ERR - ldbm_back_modify - 
index_add_mods failed, err=12 Cannot allocate memory


We just saw this in a different case.

First do a ldapsearch as follows:

# ldapsearch -D "cn=directory manager" -W -b "YOUR_DB SUFFIX" 
(|(objectclass=inetuser)(objectclass=inetadmin)(objectclass=nsmemberof))


How many entries are turned, save this value add 1 to it and use it below:

For now try setting this attribute under cn=config

ldapmodify -D "cn=directory manager" -W
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-idlistscanlimit
nsslapd-idlistscanlimit: YOUR_NUMBER_FROM_THE SEARCH


Then try the fixup task again.

HTH,
Mark


```

We increased the number of DB locks and set the `nsslapd-cache-autosize` to 50% 
(server has currently 13G of memory).
The only thing we saw was that one thread was using 100% of one of the CPUs.

Any advice on how to deal with this? We would really need to have memberOf 
attribute.
Thank you in advance!
Best Regards
Mary Georgiou

[1] https://www.freeipa.org/page/V4/Performance_Improvements
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org


--

389 Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: replica install fails

[Mark Reynolds via FreeIPA-users]

On 4/14/20 6:04 AM, Alexandru David via FreeIPA-users wrote:

Hi all

I have two centos 8 servers. One is installed and configured as master and AD 
trust controller. The second one, I'm trying to configure it as a replica, but 
what ever I do, the replica server fails to start.

Environment :
OS - CentOS Linux release 8.1.1911 (Core)
ipa-server: ipa-server-4.8.0-13.module_el8.1.0+265+e1e65be4.x86_64

Replica install is started with :
#ipa-replica-install -v --principal admin  -p X --domain 
ipamaster01.example.com  --server ipamaster01.example.com --setup-ca 
--setup-adtrust

The client install goes well, but the server stops at :

Starting replication, please wait until this has completed.
Update in progress, 15 seconds elapsed
[ldap://ipamaster01.example.com:389] reports: Update failed! Status: [Error 
(-2) - LDAP error: Local error - no response received]


Can you provide clips from the Directory Server access and errors logs 
from this time?  /var/log/dirsrv/slapd-YOUR_INSTANCE/


Start by looking in the access log for "err=82", this it the "local" 
error code.  Please provide an access log clip from this time.  Then 
provide a errors log clip from the exact same time. There should be a 
corresponding message in the errors log that explains the "local 
error".  I suspect it's coming from a bind (SSL client auth issue), but 
we'll see...


Thanks,

Mark

  
  On the ipareplica-install.log, last entries are:


2020-04-14T08:29:13Z DEBUG Created connection context.ldap2_139862275887680
2020-04-14T08:29:13Z DEBUG Fetching nsDS5ReplicaId from master [attempt 1/5]
2020-04-14T08:29:13Z DEBUG retrieving schema for SchemaCache 
url=ldap://ipamaster01.example.com:389 conn=
2020-04-14T08:29:13Z DEBUG Successfully updated nsDS5ReplicaId.
2020-04-14T08:29:13Z DEBUG Add or update replica config 
cn=replica,cn=dc\=ipamaster01\,dc\=example\,dc\=com,cn=mapping tree,cn=config
2020-04-14T08:29:13Z DEBUG Added replica config 
cn=replica,cn=dc\=ipamaster01\,dc\=example\,dc\=com,cn=mapping tree,cn=config
2020-04-14T08:29:13Z DEBUG Add or update replica config 
cn=replica,cn=dc\=ipamaster01\,dc\=example\,dc\=com,cn=mapping tree,cn=config
2020-04-14T08:29:13Z DEBUG No update to 
cn=replica,cn=dc\=ipamaster01\,dc\=example\,dc\=com,cn=mapping tree,cn=config 
necessary
2020-04-14T08:29:13Z DEBUG Waiting for replication 
(ldapi://%2Fvar%2Frun%2Fslapd-IPAMASTER01-EXAMPLE-COM.socket) 
cn=meToipamaster01.example.com,cn=replica,cn=dc\=ipamaster01\,dc\=example\,dc\=com,cn=mapping
 tree
,cn=config (objectclass=*)
2020-04-14T08:29:13Z DEBUG Entry found 
[LDAPEntry(ipapython.dn.DN('cn=meToipamaster01.example.com,cn=replica,cn=dc\=ipamaster01\,dc\=example\,dc\=com,cn=mapping
 tree,cn=config'), {'objectClass': [b'nsds5replicat
ionagreement', b'top'], 'cn': [b'meToipamaster01.example.com'], 
'nsDS5ReplicaHost': [b'ipamaster01.example.com'], 'nsDS5ReplicaPort': [b'389'], 
'nsds5replicaTimeout': [b'120'], 'nsDS5ReplicaRoot': [b'dc=ipamaste
r01,dc=example,dc=com'], 'description': [b'me to ipamaster01.example.com'], 
'nsDS5ReplicatedAttributeList': [b'(objectclass=*) $ EXCLUDE memberof 
idnssoaserial entryusn krblastsuccessfulauth krblastfailedauth kr
bloginfailedcount'], 'nsDS5ReplicaTransportInfo': [b'LDAP'], 
'nsDS5ReplicaBindMethod': [b'SASL/GSSAPI'], 'nsds5ReplicaStripAttrs': 
[b'modifiersName modifyTimestamp internalModifiersName internalModifyTimestamp']
, 'nsDS5ReplicatedAttributeListTotal': [b'(objectclass=*) $ EXCLUDE entryusn 
krblastsuccessfulauth krblastfailedauth krbloginfailedcount'], 
'nsds5replicareapactive': [b'0'], 'nsds5replicaLastUpdateStart': [b'197
0010100Z'], 'nsds5replicaLastUpdateEnd': [b'1970010100Z'], 
'nsds5replicaChangesSentSinceStartup': [b''], 'nsds5replicaLastUpdateStatus': 
[b'Error (0) No replication sessions started since server startup'
], 'nsds5replicaLastUpdateStatusJSON': [b'{"state": "green", "ldap_rc": "0", "ldap_rc_text": "success", "repl_rc": "0", 
"repl_rc_text": "replica acquired", "date": "2020-04-14T08:29:13Z", "message": "Error (0) N
o replication sessions started since server startup"}'], 
'nsds5replicaUpdateInProgress': [b'FALSE'], 'nsds5replicaLastInitStart': 
[b'1970010100Z'], 'nsds5replicaLastInitEnd': [b'1970010100Z']})]
2020-04-14T08:29:29Z DEBUG Traceback (most recent call last):
   File "/usr/lib/python3.6/site-packages/ipaserver/install/service.py", line 
603, in start_creation
 run_step(full_msg, method)
   File "/usr/lib/python3.6/site-packages/ipaserver/install/service.py", line 
589, in run_step
 method()
   File "/usr/lib/python3.6/site-packages/ipaserver/install/dsinstance.py", 
line 427, in __setup_replica
 cacert=self.ca_file
   File "/usr/lib/python3.6/site-packages/ipaserver/install/replication.py", 
line 1860, in setup_promote_replication
 raise RuntimeError("Failed to start replication")
RuntimeError: Failed to start replication

I can query both ldap servers on the master and replica with :

ldapsearch -h ldap://ipamaster01.example.co

[Freeipa-users] Fwd: Re: LDAP Server stop to response after a period of time

[Mark Reynolds via FreeIPA-users]

Thanks for help,I encounter the same problem again today.
There is stacktrace,it is really really helpful to get the more detail 
of server

looks like server always hangs after request
   op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
Please take a look of stacktrace.log  and access.log

Thanks,
   Lays

access.log
```
[10/Mar/2020:11:51:14.264988067 +0800] conn=10 op=8337 SRCH 
base="" scope=2 
filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/@)(krbPrincipalName:caseIgnoreIA5Match:=krbtgt/@)))" 
attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey 
krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration 
krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange 
krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth 
krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock 
krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge 
nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType 
ipatokenRadiusConfigLink krbAuthIndMaxTicke..."
[10/Mar/2020:11:51:14.265362689 +0800] conn=10 op=8337 RESULT err=0 
tag=101 nentries=1 etime=0.000487706
[10/Mar/2020:11:51:14.265475208 +0800] conn=10 op=8338 SRCH 
base="" scope=2 
filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/ipa1.@)(krbPrincipalName:caseIgnoreIA5Match:=ldap/ipa1.@)))" 
attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey 
krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration 
krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange 
krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth 
krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock 
krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge 
nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType 
ipatokenRadiusConfigLink krbAuthIndMaxTicke..."
[10/Mar/2020:11:51:14.265713946 +0800] conn=10 op=8338 RESULT err=0 
tag=101 nentries=1 etime=0.000385250
[10/Mar/2020:11:51:14.265799202 +0800] conn=10 op=8339 SRCH 
base="cn=,cn=kerberos," scope=0 
filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife 
krbMaxRenewableAge krbTicketFlags krbAuthIndMaxTicketLife 
krbAuthIndMaxRenewableAge"
[10/Mar/2020:11:51:14.265869305 +0800] conn=10 op=8339 RESULT err=0 
tag=101 nentries=1 etime=0.000182813
[10/Mar/2020:11:51:14.266027805 +0800] conn=10 op=8340 SRCH 
base="" scope=2 
filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=host/rancher1.@))" 
attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey 
krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration 
krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange 
krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth 
krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock 
krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge 
nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType 
ipatokenRadiusConfigLink krbAuthIndMaxTicke..."
[10/Mar/2020:11:51:14.266226284 +0800] conn=10 op=8340 RESULT err=0 
tag=101 nentries=1 etime=0.000251517
[10/Mar/2020:11:51:14.266284747 +0800] conn=10 op=8341 SRCH 
base="cn=,cn=kerberos," scope=0 
filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife 
krbMaxRenewableAge krbTicketFlags krbAuthIndMaxTicketLife 
krbAuthIndMaxRenewableAge"
[10/Mar/2020:11:51:14.266578962 +0800] conn=10 op=8341 RESULT err=0 
tag=101 nentries=1 etime=0.000326237
[10/Mar/2020:11:51:14.267100741 +0800] conn=5261 op=1 BIND dn="" 
method=sasl version=3 mech=GSSAPI
[10/Mar/2020:11:51:15.331791547 +0800] conn=5262 fd=170 slot=170 
connection from .154 to .165
[10/Mar/2020:11:51:20.009768876 +0800] conn=5263 fd=171 slot=171 
connection from .156 to .165
[10/Mar/2020:11:51:20.719915656 +0800] conn=5264 fd=172 slot=172 
connection from .151 to .165
[10/Mar/2020:11:51:21.334589697 +0800] conn=5265 fd=173 slot=173 
connection from .154 to .165
[10/Mar/2020:11:51:25.881631700 +0800] conn=5266 fd=174 slot=174 
connection from .153 to .165
[10/Mar/2020:11:51:26.028079666 +0800] conn=5267 fd=175 slot=175 
connection from .156 to .165
[10/Mar/2020:11:51:26.291901685 +0800] conn=5268 fd=176 slot=176 
connection from .152 to .165
[10/Mar/2020:11:51:27.275114819 +0800] conn=5269 fd=180 slot=180 
connection from .150 to .165
[10/Mar/2020:11:51:33.403472677 +0800] conn=5270 fd=181 slot=181 
connection from .154 to .165

```
stacktrace.1583832889.txt
```
GNU gdb (GDB) Fedora 8.3.50.20190824-30.fc31
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB w

[Freeipa-users] Re: LDAP Server stop to response after a period of time

[Mark Reynolds via FreeIPA-users]

A stack trace would be very useful in determining why the Directory 
Server is misbehaving.  You can grab stack traces following these steps:


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

Thanks,
Mark


On 3/7/20 11:48 PM, Lays Dragon via FreeIPA-users wrote:

I deployed a two replica FreeIPA Servers,it woks well until this month,it start 
at the service report the LDAP is Timeout,I try to restart the server,even 
reinstall two IPA server and maintain the data via replica from another server. 
And it still happen after several days. The 389ds server just simply stop to 
response to any connection ,the wierd thing is the connection is established 
but no response after the connection.
LDAP server seems to blocked on something,even replica is dead because the ldap 
is blocked.simply restart not slove the problem,the ldap server will blocked 
really soon caused other service like IPA Web service or kinit dead too.
I guess the blocked is caused via replica function somehow,since I figure out I 
have to close the ldap port on blocked server firewall to make it isolate,and 
restart the server,waiting for about 10 min after the server is start,reopen 
the ldap port on firewall to let replica recover,and everything will be 
fine...And I notice there some connection stuck at CLOSE_WAIT of ns-slapd may 
be related.
Need some help . I not so familiar with of freeipa,and trying to deal this 
problem over the week but nothing works.

FreeIPA server version:4.8.4
Server System: Fedora 31 (Cloud Edition)

server1 access log
```
krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData 
krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife 
krbMaxRenewableAge nsAccountLock passwordHistory
ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink krbAuthIndMaxTicke..."
[08/Mar/2020:10:01:23.390837315 +0800] conn=4 op=6091 RESULT err=0 tag=101 
nentries=1 etime=0.000276689
[08/Mar/2020:10:01:23.390906790 +0800] conn=4 op=6092 SRCH 
base="cn=ENMD.NET,cn=kerberos,dc=enmd,dc=net" scope=0 
filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge 
krbTicketFlags krbAuthIndMaxTicketLife krbAuthIndMaxRenewableAge"
[08/Mar/2020:10:01:23.391302403 +0800] conn=4 op=6092 RESULT err=0 tag=101 
nentries=1 etime=0.000432879
[08/Mar/2020:10:01:23.392418974 +0800] conn=3351 op=1 BIND dn="" method=sasl 
version=3 mech=GSSAPI
[08/Mar/2020:10:01:25.953517485 +0800] conn=3352 fd=161 slot=161 connection from 
.152 to .165
[08/Mar/2020:10:01:27.007620375 +0800] conn=3353 fd=162 slot=162 connection from 
.154 to .165
[08/Mar/2020:10:01:27.151656148 +0800] conn=3354 fd=163 slot=163 connection from 
.150 to .165
[08/Mar/2020:10:01:27.559750675 +0800] conn=3355 fd=164 slot=164 connection from 
.153 to .165
[08/Mar/2020:10:01:39.015400434 +0800] conn=3356 fd=165 slot=165 connection from 
.154 to .165
[08/Mar/2020:10:01:51.582586229 +0800] conn=3357 fd=166 slot=166 connection from 
.153 to .165
[08/Mar/2020:10:01:52.513047687 +0800] conn=3358 fd=167 slot=167 connection from 
.150 to .165
[08/Mar/2020:10:01:53.573811317 +0800] conn=3359 fd=168 slot=168 connection from 
.152 to .165
[08/Mar/2020:10:02:44.012371005 +0800] conn=3360 fd=169 slot=169 connection from 
.160 to .165
[08/Mar/2020:10:02:44.419580574 +0800] conn=3361 fd=170 slot=170 connection from 
.151 to .165
[08/Mar/2020:10:02:45.548493596 +0800] conn=3362 fd=171 slot=171 connection from 
.153 to .165
[08/Mar/2020:10:02:50.018712852 +0800] conn=3363 fd=172 slot=172 connection from 
.160 to .165
[08/Mar/2020:10:02:51.081867407 +0800] conn=3364 fd=173 slot=173 connection from 
.152 to .165
[08/Mar/2020:10:03:04.062925765 +0800] conn=3365 fd=174 slot=174 connection from 
.154 to .165
[08/Mar/2020:10:03:06.223438080 +0800] conn=3366 fd=175 slot=175 connection from 
.150 to .165
[08/Mar/2020:10:03:10.063982993 +0800] conn=3367 fd=176 slot=176 connection from 
.154 to .165
[08/Mar/2020:10:03:52.027006125 +0800] conn=3368 fd=177 slot=177 connection from 
.153 to .165
[08/Mar/2020:10:03:57.005297121 +0800] conn=3369 fd=178 slot=178 connection from 
.152 to .165
[08/Mar/2020:10:04:01.001767909 +0800] conn=3370 fd=179 slot=179 connection from 
.150 to .165
[08/Mar/2020:10:04:08.003082421 +0800] conn=3371 fd=180 slot=180 connection from 
.154 to .165
[08/Mar/2020:10:04:12.014090964 +0800] conn=3372 fd=181 slot=181 connection from 
.151 to .165
[08/Mar/2020:10:04:18.140192092 +0800] conn=3373 fd=182 slot=182 connection from 
.166 to .165
[08/Mar/2020:10:04:20.007046774 +0800] conn=3374 fd=183 slot=183 connection from 
.154 to .165
[08/Mar/2020:10:04:24.040348027 +0800] conn=3375 fd=184 slot=184 connection from 
.160 to .165
[08/Mar/2020:10:04:30.139898749 +0800] conn=3376 fd=185 slot=185 connection from 
.160 to .165
[08/Mar/2020:10:05:22.043556910 +0800] conn=3377 fd=186 slot=186 connection from 
.160 to .165
[08/Mar/2020:10:05:34.140357676 +0800] conn=3378 fd=187 slot=187 connection from 
.160 to .165
[08/Mar/2020:10:

[Freeipa-users] Re: Directory server on a dedicated filesystem?

[Mark Reynolds via FreeIPA-users]

Directory Server also comes with a "Disk Monitoring" feature that will 
gracefully stop a server if any disk the server uses becomes full.  It 
can also attempt to free disk space by optionally removing rotated logs, 
and adjusting log levels.


https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/diskmonitoring

HTH,

Mark

On 3/4/20 5:38 PM, Rob Crittenden via FreeIPA-users wrote:

Daniel PC via FreeIPA-users wrote:

The goal is avoid a directory server fault due to filesystem full.
The /var FS hosts logs and backup, does not seem a good idea left all these 
services on the same filesystem.

Any filesystem can fill up. I had to give a wishy-washy answer because
you asked specifically about /var.

If you want to ensure the db has space for itself make /var/lib/dirsrv
its own disk (virtual or otherwise).

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org


--

389 Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-replica-install latest failure attempt:

[Mark Reynolds via FreeIPA-users]

On 12/2/19 1:10 PM, Auerbach, Steven via FreeIPA-users wrote:

A couple of follow-up questions and some results of an ldap search...

In your suggested ldapmodify statement:
ldapmodify -h  -p 389 -D "cn=directory manager" -W
dn:  cn=replica,cn=, cn=mapping tree,cn=config
changetype: modify
replace: nsds5ReplicaBindDNGroupCheckInterval
nsds5ReplicaBindDNGroupCheckInterval: 3

1: Is the command only the first line and the remaining lines responses to 
interactive prompts?


At the command prompt run the ldapmodify command, then you will be in a 
editor mode:


# ldapmodify -D "cn=directory manager" -W   

< You are now in the editor mode, enter these lines below, followed by 
two blank lines to initiate the operation.  Then press Contorl-D to exit>


dn:  cn=replica,cn="dc=fbog,dc=local", cn=mapping tree,cn=config
changetype: modify
replace: nsds5ReplicaBindDNGroupCheckInterval
nsds5ReplicaBindDNGroupCheckInterval: 3






HTH,
Mark


2: I know that  is my host fqdn.  What is supposed to replace   
in the dn= declaration?

I did an ldapsearch on this ipa master. I was trying to determine the current 
settings on this option before I modify it.  Looking specifically for 
ReplicaBindDN section I found the following:
# System: Read Replication Information, permissions, pbac, fbog.local
dn: cn=System: Read Replication Information,cn=permissions,cn=pbac,dc=fbog,dc= 
local
ipaPermTargetFilter: (objectclass=nsds5replica)
ipaPermRight: read
ipaPermRight: compare
ipaPermRight: search
ipaPermBindRuleType: all
ipaPermissionType: SYSTEM
ipaPermissionType: V2
ipaPermissionType: MANAGED
cn: System: Read Replication Information
objectClass: top
objectClass: groupofnames
objectClass: ipapermission
objectClass: ipapermissionv2
ipaPermDefaultAttr: nsds5replicatombstonepurgeinterval
ipaPermDefaultAttr: nsds5replicareferral
ipaPermDefaultAttr: nsstate
ipaPermDefaultAttr: cn
ipaPermDefaultAttr: nsds5flags
ipaPermDefaultAttr: nsds5replicacleanruv
ipaPermDefaultAttr: nsds5replicabinddn
ipaPermDefaultAttr: nsds5replicaprotocoltimeout
ipaPermDefaultAttr: nsds5replicatype
ipaPermDefaultAttr: nsds5replicachangecount
ipaPermDefaultAttr: nsds5replicaroot
ipaPermDefaultAttr: nsds5replicabackoffmin
ipaPermDefaultAttr: nsds5replicaname
ipaPermDefaultAttr: objectclass
ipaPermDefaultAttr: nsds5replicalegacyconsumer
ipaPermDefaultAttr: nsds5replicapurgedelay
ipaPermDefaultAttr: nsds5replicaid
ipaPermDefaultAttr: nsds5replicaautoreferral
ipaPermDefaultAttr: nsds5replicabackoffmax
ipaPermDefaultAttr: nsds5replicaabortcleanruv
ipaPermDefaultAttr: nsds5task
ipaPermLocation: cn=replication,cn=etc,dc=fbog,dc=local

There is not telling me what the current values are.  I could not locate 
declarations for nsds5ReplicaBindDNGroupCheckInterval.  Does that even exist in 
ipa v3.0?

-Steven Auerbach

-Original Message-
From: thierry bordaz 
Sent: Tuesday, November 19, 2019 3:31 AM
To: Rob Crittenden ; FreeIPA users list 

Cc: Auerbach, Steven 
Subject: Re: [Freeipa-users] ipa-replica-install latest failure attempt:



On 11/18/19 11:24 PM, Rob Crittenden wrote:

Auerbach, Steven via FreeIPA-users wrote:

Executed ipa-replica-prepare on an RHEL 6.9 server running ipa-server
3.0.0.1_51  (name : ipa01)

Yum installed ipa-server, ipa-server-dns, bind-dyndb-ldap on the
target Linux 7.6 server (name: ipa04)

Copied the file to the target server to which ipa-server 4.6.5-11.0.1
is installed (ipa04)

Copied the file :/usr/share/ipa/copy-schema-to-ca.py from ipa v4.6
server to the ipa v3.0 server and executed it successfully.

Edited the /etc/resolv.con on ipa04 to include ipa01. Did not reboot.

Executed ipa-replica-install --setup-dns --forwarder=8.8.8.8
--setup-ca /var/lib/ipa/replica-info-ipa04.fbog.local.gpg (on ipa04)


2019-11-16T16:23:24Z DEBUG The ipa-replica-install command failed,
exception: NotFound: wait_for_entry timeout on
ldap://ipa01.fbog.local:389 for
krbprincipalname=HTTP/ipa04.fbog.local@FBOG.LOCAL,cn=services,cn=acco
unts,dc=fbog,dc=local

2019-11-16T16:23:24Z ERROR wait_for_entry timeout on
ldap://ipa01.fbog.local:389 for
krbprincipalname=HTTP/ipa04.fbog.local@FBOG.LOCAL,cn=services,cn=acco
unts,dc=fbog,dc=local

   


Not sure where to go from here.  Did I leave out some declaration or
specification on the initial command?

The problem isn't in the command invocation, replication is just slow
enough for some reason that the new principal(s) weren't replicated to
the existing master.

I seem to recall a 389-ds option to mitigate this but I can't remember
it off the to of my head (or maybe it isn't applicable for RHEL 6
master). cc'ing someone who would know.

rob

It is difficult to be sure without  all logs (ipa-replica-install, DS
logs) and config.
  From the top of my head I recall an old bug where the replica agreement
replica->master was failing to bind because master did not lookup the
updated bind group.

Rob, is it the bug you were thinking of ?

If it is this bug, you may try to set nsds5ReplicaBindDNGroupCheckInterval

l

[Freeipa-users] Re: IPA-Backup fails

[Mark Reynolds via FreeIPA-users]

On 5/31/19 8:44 AM, Mark Reynolds via FreeIPA-users wrote:


On 5/31/19 8:20 AM, Rob Crittenden wrote:

Dirk Streubel via FreeIPA-users wrote:

Hello,

have a little Problem with a full backup of my IPA Server.
The command : ipa-backup -d, doesn't work, the output is this:

papython.ipautil: DEBUG: stderr=ipa: INFO: The ipactl command was 
successful
ipaserver.install.ipa_backup: INFO: Backing up ipaca in 
LINUXTEST-INTRANET-FRITZ-DE to LDIF

ipapython.ipautil: DEBUG: Starting external process
ipapython.ipautil: DEBUG: args=['/usr/sbin/db2ldif', '-Z', 
'LINUXTEST-INTRANET-FRITZ-DE', '-r', '-n', 'ipaca', '-a', 
'/var/lib/dirsrv/slapd-LINUXTEST-INTRANET-FRITZ-DE/ldif/LINUXTEST-INTRANET-FRITZ-DE-ipaca.ldif']

ipapython.ipautil: DEBUG: Process finished, return code=1
ipapython.ipautil: DEBUG: stdout=Usage: db2ldif [-Z serverID] {-n 
backend_instance}* | {-s includesuffix}* [{-x excludesuffix}*] [-a 
outputfile]

    [-E] [-r] [-u] [-U] [-m] [-1] [-q] [-V] [-v] [-h]
Note: either "-n backend" or "-s includesuffix" is required.
Options:
 -Z serverID   - Server instance identifier
 -n backend    - Backend database name.  Example: userRoot
 -s inclduesuffix  - Suffix to include
 -x    - Suffix to exclude
 -a outputfile - Name of the exported LDIF file
 -r    - Include replication data
 -E    - Decrypt attributes
 -u    - Do not export the nsUniqueId attribute
 -U    - Do not wrap long lines
 -m    - Do not base64 encode values
 -1    - Do not include version text
 -q    - Quiet mode - suppresses output
 -V    - Verbose output
 -v    - Display version
 -h    - Display usage
You must supply a valid server instance identifier.  Use -Z to 
specify instance name

Available instances: 
ipapython.ipautil: DEBUG: stderr=
ipaserver.install.ipa_backup: CRITICAL: db2ldif failed:
ipapython.admintool: DEBUG:   File 
"/usr/lib/python3.7/site-packages/ipapython/admintool.py", line 179, 
in execute

 return_value = self.run()
   File 
"/usr/lib/python3.7/site-packages/ipaserver/install/ipa_backup.py", 
line 329, in run

 self.db2ldif(instance, 'ipaca', online=options.online)
   File 
"/usr/lib/python3.7/site-packages/ipaserver/install/ipa_backup.py", 
line 461, in db2ldif

 shutil.move(ldiffile, os.path.join(self.dir, ldifname))
   File "/usr/lib64/python3.7/shutil.py", line 577, in move
 copy_function(src, real_dst)
   File "/usr/lib64/python3.7/shutil.py", line 263, in copy2
 copyfile(src, dst, follow_symlinks=follow_symlinks)
   File "/usr/lib64/python3.7/shutil.py", line 120, in copyfile
 with open(src, 'rb') as fsrc:
ipapython.admintool: DEBUG: The ipa-backup command failed, 
exception: FileNotFoundError: [Errno 2] No such file or directory: 
'/var/lib/dirsrv/slapd-LINUXTEST-INTRANET-FRITZ-DE/ldif/LINUXTEST-INTRANET-FRITZ-DE-ipaca.ldif'
ipapython.admintool: ERROR: [Errno 2] No such file or directory: 
'/var/lib/dirsrv/slapd-LINUXTEST-INTRANET-FRITZ-DE/ldif/LINUXTEST-INTRANET-FRITZ-DE-ipaca.ldif'
ipapython.admintool: ERROR: The ipa-backup command failed. See 
/var/log/ipabackup.log for more information

[root@ipaserver1 ipa-data-2019-05-31-10-23-30]# man ipa-backup

I have tested the command in two different machines, the result and 
the error log is the same, ipa-backup --data --online works fine.

Did i miss a subcommand for an fully backup or where is my fault?

My OS is Fedora Rawhide with the last IPA Version.

Knowing the exact versions makes reproduction easier.

What are the versions of freeipa-server and 389-ds-base installed?

The usage looks ok to me. I wonder if db2ldif changed recently. Mark,
Thierry, what do you think?


db2ldif has not changed in a long time, but what version of 
389-ds-base is this?

Dirk confirmed he is on:

389-ds-base-libs-1.4.1.3-1

I am currently working on a fix and I will do a new Fedora builds as soon as 
its fixed/merged.

Regards,
Mark




According to the output the script is not finding any server instances:

/usr/sbin/db2ldif -Z LINUXTEST-INTRANET-FRITZ-DE
...
You must supply a valid server instance identifier.  Use -Z to specify 
instance name

Available instances: 


It finds the local instances by looking under /etc/sysconfig for 
dirsrv-INSTANCE.  In newer versions of DS (1.4.x) I believe we stopped 
writing instance information to /etc/sysconfig so that would break the 
legacy tools  - and I just verified that the legacy tools no longer 
work in Master branch (I get the same errors).  If they are using 
1.4.x  then "dsctl db2ldif"

[Freeipa-users] Re: IPA-Backup fails

[Mark Reynolds via FreeIPA-users]

On 5/31/19 8:20 AM, Rob Crittenden wrote:

Dirk Streubel via FreeIPA-users wrote:

Hello,

have a little Problem with a full backup of my IPA Server.
The command : ipa-backup -d, doesn't work, the output is this:

papython.ipautil: DEBUG: stderr=ipa: INFO: The ipactl command was successful
   
ipaserver.install.ipa_backup: INFO: Backing up ipaca in LINUXTEST-INTRANET-FRITZ-DE to LDIF

ipapython.ipautil: DEBUG: Starting external process
ipapython.ipautil: DEBUG: args=['/usr/sbin/db2ldif', '-Z', 
'LINUXTEST-INTRANET-FRITZ-DE', '-r', '-n', 'ipaca', '-a', 
'/var/lib/dirsrv/slapd-LINUXTEST-INTRANET-FRITZ-DE/ldif/LINUXTEST-INTRANET-FRITZ-DE-ipaca.ldif']
ipapython.ipautil: DEBUG: Process finished, return code=1
ipapython.ipautil: DEBUG: stdout=Usage: db2ldif [-Z serverID] {-n 
backend_instance}* | {-s includesuffix}* [{-x excludesuffix}*] [-a outputfile]
[-E] [-r] [-u] [-U] [-m] [-1] [-q] [-V] [-v] [-h]
Note: either "-n backend" or "-s includesuffix" is required.
Options:
 -Z serverID   - Server instance identifier
 -n backend- Backend database name.  Example: userRoot
 -s inclduesuffix  - Suffix to include
 -x- Suffix to exclude
 -a outputfile - Name of the exported LDIF file
 -r- Include replication data
 -E- Decrypt attributes
 -u- Do not export the nsUniqueId attribute
 -U- Do not wrap long lines
 -m- Do not base64 encode values
 -1- Do not include version text
 -q- Quiet mode - suppresses output
 -V- Verbose output
 -v- Display version
 -h- Display usage
You must supply a valid server instance identifier.  Use -Z to specify instance 
name
Available instances: 
   
ipapython.ipautil: DEBUG: stderr=

ipaserver.install.ipa_backup: CRITICAL: db2ldif failed:
ipapython.admintool: DEBUG:   File 
"/usr/lib/python3.7/site-packages/ipapython/admintool.py", line 179, in execute
 return_value = self.run()
   File "/usr/lib/python3.7/site-packages/ipaserver/install/ipa_backup.py", 
line 329, in run
 self.db2ldif(instance, 'ipaca', online=options.online)
   File "/usr/lib/python3.7/site-packages/ipaserver/install/ipa_backup.py", 
line 461, in db2ldif
 shutil.move(ldiffile, os.path.join(self.dir, ldifname))
   File "/usr/lib64/python3.7/shutil.py", line 577, in move
 copy_function(src, real_dst)
   File "/usr/lib64/python3.7/shutil.py", line 263, in copy2
 copyfile(src, dst, follow_symlinks=follow_symlinks)
   File "/usr/lib64/python3.7/shutil.py", line 120, in copyfile
 with open(src, 'rb') as fsrc:
   
ipapython.admintool: DEBUG: The ipa-backup command failed, exception: FileNotFoundError: [Errno 2] No such file or directory: '/var/lib/dirsrv/slapd-LINUXTEST-INTRANET-FRITZ-DE/ldif/LINUXTEST-INTRANET-FRITZ-DE-ipaca.ldif'

ipapython.admintool: ERROR: [Errno 2] No such file or directory: 
'/var/lib/dirsrv/slapd-LINUXTEST-INTRANET-FRITZ-DE/ldif/LINUXTEST-INTRANET-FRITZ-DE-ipaca.ldif'
ipapython.admintool: ERROR: The ipa-backup command failed. See 
/var/log/ipabackup.log for more information
[root@ipaserver1 ipa-data-2019-05-31-10-23-30]# man ipa-backup

I have tested the command in two different machines, the result and the error 
log is the same, ipa-backup --data --online works fine.
Did i miss a subcommand for an fully backup or where is my fault?

My OS is Fedora Rawhide with the last IPA Version.

Knowing the exact versions makes reproduction easier.

What are the versions of freeipa-server and 389-ds-base installed?

The usage looks ok to me. I wonder if db2ldif changed recently. Mark,
Thierry, what do you think?


db2ldif has not changed in a long time, but what version of 389-ds-base 
is this?



According to the output the script is not finding any server instances:

/usr/sbin/db2ldif -Z LINUXTEST-INTRANET-FRITZ-DE
...
You must supply a valid server instance identifier.  Use -Z to specify instance 
name
Available instances: 


It finds the local 

[Freeipa-users] Fwd: [389-users] How to invalidate local cache after user changed their password

[Mark Reynolds via FreeIPA-users]

Forwarding to freeipa-users who have more knowledge on SSSD



 Forwarded Message 
Subject: 	[389-users] How to invalidate local cache after user changed 
their password

Date:   Wed, 27 Feb 2019 19:22:19 + (UTC)
From:   xinhuan zheng 
Reply-To: 	General discussion list for the 389 Directory server project. 
<389-us...@lists.fedoraproject.org>

To: 389-us...@lists.fedoraproject.org



Hello,

I have been struggling with this problem for a while. When a user 
changed their password, our 389 directory servers received new password 
and saved into directory server. However, when user tries to login to a 
server whose authentication is using 389 directory server, their new 
password won't work for the first few minutes. There is a local cache 
process, sssd, running on the server the user tries to login. Apparently 
sssd is still using old password information, and does not know password 
has changed on directory servers. I have set sssd to keep cache 
information for 5 minutes only, and do pre-fetch prior to cache 
information expiring. But I don't know how to tell sssd to ignore cache 
completely when information has changed on 389 directory server side.


Is there a way to completely disable sssd local cache, and only use it 
when 389 directory servers are not available?


Thank you,

- Xinhuan
___
389-users mailing list -- 389-us...@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-us...@lists.fedoraproject.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Limits exceeded for this query

[Mark Reynolds via FreeIPA-users]

On 12/20/18 10:13 AM, lune voo via FreeIPA-users wrote:

Re Florence.

I performed the following command :

ipa config-mod --searchtimelimit=5


It solved this "problem".

May I ask what can be the impacts on increasing searchtimelimit please ?


Hi Lune,

The purpose of setting these kinds of limits is to prevent clients from 
abusing the Directory Server/IDM and causing potential DOS attacks.  If 
you increase the search time limit it just means that any client can run 
"longer" searches and tie up Directory Server/IDM resources longer.  
That being said, 5 seconds or 10 seconds are very reasonable limits, but 
for example setting it to an hour would not be.


HTH,

Mark



Best regards.


Lune




Le jeu. 20 déc. 2018 à 12:37, Florence Blanc-Renaud > a écrit :


Hi,

based on the err code err=3 I can see that I was wrong, it's not a
size
limit but rather a time limit issue. It looks like the LDAP server is
busy after the modification on the cn= entry and takes
more
than 33sec to answer.

The default search time limit is 2 seconds at IPA level:
dn: cn=ipaConfig,cn=etc,$BASEDN
ipaSearchTimeLimit: 2

There is also a search time limit set at 389-ds level:
dn: cn=config
nsslapd-timelimit: 3600

and another one can be set per-user:
dn: uid=,cn=users,cn=accounts,$BASEDN
nsTimeLimit: 

Is there anything in the error log of 389-ds at the same time?

Note that IPA 3.0.0 is quite old and we did improvements related to
group management in more recent versions (for instance [1] or [2]).
The failing search may simply be an internal search in order to
get the
size and time limits, needed to create the search that will check the
content of the entry after the MOD has been done.

flo

[1] https://pagure.io/freeipa/issue/4965
[2] https://pagure.io/freeipa/issue/4947

On 12/20/18 11:38 AM, lune voo via FreeIPA-users wrote:
> I tried to perform an ldapsearch using the same kind of command :
>
> ldapsearch -x -D "cn=Directory Manager" \
>>   -h  \
>>   -p 389 \
>>   -W \
>>   -b "cn=ipaconfig,cn=etc,dc=" \
>>   -s sub \
>> objectclass=*
> Enter LDAP Password:
>
>
> I got this result immediately :
> # extended LDIF
> #
> # LDAPv3
> # base > with scope subtree
> # filter: objectclass=*
> # requesting: ALL
> #
>
> # ipaConfig, etc, 
> dn: cn=ipaConfig,cn=etc,dc=
> objectClass: nsContainer
> objectClass: top
> objectClass: ipaGuiConfig
> objectClass: ipaConfigObject
> ipaUserSearchFields: uid,givenname,sn,telephonenumber,ou,title
> ipaGroupSearchFields: cn,description
> ipaSearchTimeLimit: 2
> ipaSearchRecordsLimit: 100
> ipaHomesRootDir: /home
> ipaDefaultLoginShell: /bin/sh
> ipaDefaultPrimaryGroup: users
> ipaMaxUsernameLength: 64
> ipaPwdExpAdvNotify: 4
> ipaGroupObjectClasses: top
> ipaGroupObjectClasses: groupofnames
> ipaGroupObjectClasses: nestedgroup
> ipaGroupObjectClasses: ipausergroup
> ipaGroupObjectClasses: ipaobject
> ipaUserObjectClasses: top
> ipaUserObjectClasses: person
> ipaUserObjectClasses: organizationalperson
> ipaUserObjectClasses: inetorgperson
> ipaUserObjectClasses: inetuser
> ipaUserObjectClasses: posixaccount
> ipaUserObjectClasses: krbprincipalaux
> ipaUserObjectClasses: krbticketpolicyaux
> ipaUserObjectClasses: ipaobject
> ipaUserObjectClasses: ipasshuser
> ipaDefaultEmailDomain: 
> ipaMigrationEnabled: FALSE
> ipaConfigString: AllowNThash
> ipaSELinuxUserMapOrder:
> guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c102
>   3$unconfined_u:s0-s0:c0.c1023
> ipaSELinuxUserMapDefault: unconfined_u:s0-s0:c0.c1023
> cn: ipaConfig
> ipaCertificateSubjectBase: O=
> ipaKrbAuthzData: MS-PAC
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
> This query is fine and fast.
>
> Best regards.
>
> Lune
>
>
> Le jeu. 20 déc. 2018 à 11:25, lune voo mailto:lune.voo1...@gmail.com>
> >>
a écrit :
>
>     Here is the value of nsslapd-sizelimit
>
>     nsslapd-sizelimit: 2000
>
>     For the anonymous queries, we disabled them long time ago.
>
>     If I understand well, the problem comes from this search :
>     SRCH base="cn=ipaconfig,cn=etc,dc=" scope=0
>     filter="(objectClass=*)" attrs=ALL
>
>     Do you know why this search is performed once the member
user has
>     been removed from the group ?
>
>     Lune
>
>     Le jeu. 20 déc. 2018 à 11:08, lune voo
mailto:lune.voo1...@gmail.com>
>     >> a écrit :
>
>     

[Freeipa-users] Re: Force TLS connection

[Mark Reynolds via FreeIPA-users]

On 11/27/18 10:14 AM, Peter Tselios via FreeIPA-users wrote:

Hello,
My understanding is that FreeIPA is configured to accept connections on port 
389 and the StartTLS is configured.
I managed to connect to the IPA server by using ldapsearch -x and without -ZZ 
so, I suppose the TLS is not enforced.

Is there any option force TLS connections only? Obviously, I would prefer 
something that can be replicated and not to manually edit the configuration 
files, but I can live with that :)


On the DS side you can set "nsslapd-require-secure-binds" to "on" under 
cn=config.  Attributes under cn=config do not replicate so this would 
have to be done manually to all your instances:


https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/configuring-special-binds#requiring-secure-binds


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: replication sync issues

[Mark Reynolds via FreeIPA-users]

On 11/2/18 12:21 PM, Grant Janssen via FreeIPA-users wrote:

I’ve tried both force-sync AND re-initialize on both hosts.
I do have a question about the error in the log.
though the error posts on the “master”, it appears to indicate an issue with 
the slave.
the slave syslog is clean.

when the log indicates “The replica must be reinitialized” is it meant to be 
the localhost - or the remote replica?


The remote replica.  The replica that the replication agreement points 
to:  idm02.production.efilm.com


Regards,

Mark



Nov  2 09:14:12 ef-idm01 ns-slapd: [02/Nov/2018:09:14:12.421134348 -0700] 
agmt="cn=masterAgreement1-ef-idm02.production.efilm.com-pki-tomcat" 
(ef-idm02:389) - Can't locate CSN 5afd965100020060 in the changelog (DB rc=-30988). 
If replication stops, the consumer may need to be reinitialized.
Nov  2 09:14:12 ef-idm01 ns-slapd: [02/Nov/2018:09:14:12.422583035 -0700] 
NSMMReplicationPlugin - changelog program - 
agmt="cn=masterAgreement1-ef-idm02.production.efilm.com-pki-tomcat" 
(ef-idm02:389): CSN 5afd965100020060 not found, we aren't as up to date, or we purged
Nov  2 09:14:12 ef-idm01 ns-slapd: [02/Nov/2018:09:14:12.423155007 -0700] 
NSMMReplicationPlugin - 
agmt="cn=masterAgreement1-ef-idm02.production.efilm.com-pki-tomcat" 
(ef-idm02:389): Data required to update replica has been purged from the changelog. The 
replica must be reinitialized.

thanx

- grant

On Nov 2, 2018, at 08:26, Christophe TREFOIS  wrote:


Hi,

Have you look at the reinitialize option rather than force-sync?

At least, it is the option we always use.

Best,




This e-mail and any attachments are intended only for use by the addressee(s) 
named herein and may contain confidential information. If you are not the 
intended recipient of this e-mail, you are hereby notified any dissemination, 
distribution or copying of this email and any attachments is strictly 
prohibited. If you receive this email in error, please immediately notify the 
sender by return email and permanently delete the original, any copy and any 
printout thereof. The integrity and security of e-mail cannot be guaranteed.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-replica-manage --force replica.server fails

[Mark Reynolds via FreeIPA-users]

On 10/23/18 12:54 PM, Ralph Crongeyer via FreeIPA-users wrote:
Can this be manually removed? W currently can't login to the web 
portal due to this issue.


http://www.port389.org/docs/389ds/howto/howto-cleanruv.html#cleanallruv

Or you can run:   cleanallruv.pl -h

HTH,

Mark



On Fri, Oct 19, 2018 at 8:42 AM Ralph Crongeyer > wrote:


The goal is to remove the replica server from the master. No split
brain. I need to remove this as we can't login to the portal
because of this.


On Thu, Oct 18, 2018 at 5:23 PM Rob Crittenden
mailto:rcrit...@redhat.com>> wrote:

Ralph Crongeyer via FreeIPA-users wrote:
> Hi List,
> I have a master server that had a replica installed. The
replica has
> been uninstalled. When I try to run "ipa-replica-manage del
--force
> replica.server" it fails with:
> invalid 'PKINIT enabled server': all masters must have IPA
master role
> enabled
>
> How can I delete this replica?

What is your ultimate goal here? In your previous post it
sounded like
you are trying to create a split-brain. IPA doesn't like those
and does
what it can to prevent them.

rob


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Diagnose cause of Directory Services failure

[Mark Reynolds via FreeIPA-users]

On 10/17/18 11:03 AM, Mike Conner via FreeIPA-users wrote:

I've configured FreeIPA with an AD trust that is handling workstation logins at 
my organization. Things have been going well, but I've noticed a couple of 
times that the Directory Services process is consuming a lot of CPU. This 
morning, after receiving reports of users not being able to log in, I ran 
`ipactl status` which reported Directory Services as STOPPED. I'm looking for 
help on where to begin with a root cause analysis.

Here is a snippet from /var/log/dirsrv/error that seems to me to indicate a 
critical error; I just can't decipher what is happening.

*
[16/Oct/2018:22:25:43.562185858 -0500] - ERR - accept_and_configure - 
PR_Accept() failed, Netscape Portable Runtime error -5971 (Process open FD 
table is full.)
[16/Oct/2018:22:25:43.563825169 -0500] - ERR - ns_handle_new_connection - 
PR_PROC_DESC_TABLE_FULL_ERROR: File Descriptor exhaustion has occured! 
Connections will be silently dropped!
[16/Oct/2018:22:25:43.565434972 -0500] - ERR - accept_and_configure - 
PR_Accept() failed, Netscape Portable Runtime error -5971 (Process open FD 
table is full.)
[16/Oct/2018:22:25:43.567125116 -0500] - ERR - ns_handle_new_connection - 
PR_PROC_DESC_TABLE_FULL_ERROR: File Descriptor exhaustion has occured! 
Connections will be silently dropped!
[16/Oct/2018:22:25:43.568974177 -0500] - ERR - libdb - BDB0060 PANIC: fatal 
region error detected; run recovery
[16/Oct/2018:22:25:43.580095520 -0500] - CRIT - deadlock_threadmain - Serious 
Error---Failed in deadlock detect (aborted at 0x0), err=-30973 (BDB0087 
DB_RUNRECOVERY: Fatal error, run database recovery)
*


What version of DS?  rpm -qa | grep 389-ds-base

This looks like a known issue, and you can try disabling nunc-stans, and 
then restart the server:


# ldapmodify -D "cn=directory manager" -W
dn: cn=config
changetype: modify
replace: nsslapd-enable-nunc-stans
nsslapd-enable-nunc-stans: off


Thanks!
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ERR - attrlist_replace - attr_replace (nsslapd-referral,

[Mark Reynolds via FreeIPA-users]

https://pagure.io/389-ds-base/c/6f585fa9adaa83efa98b72aa112e162f180b0ad1


On 08/01/2018 09:55 PM, James Harrison via FreeIPA-users wrote:

Any ideas, anyone?
This is a known "issue".  The message itself is harmless, and it has 
been "fixed" in 389-ds-base-1.3.6.1-22


On Tue, 31 Jul 2018 at 13:22, James Harrison via FreeIPA-users
 wrote:
Hello,

We have a machine with the following set up:
CentOS Linux release 7.4.1708 (Core)
ipa-server-4.5.0-21.el7.centos.2.2.x86_64
CA-less setup

We're getting a lot of errors on one of our FreeIPA servers. Hope
you can help.

Many thanks
James Harrison

[31/Jul/2018:12:19:05.542401358 +0100] - ERR - cos-plugin -
cos_dn_defs_cb - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=int,dc=DOMAIN,dc=com--no CoS Templates
found, which should be added before the CoS Definition.
[31/Jul/2018:12:19:05.611267011 +0100] - ERR - attrlist_replace -
attr_replace (nsslapd-referral,
ldap://cro-system-02.DOMAINNAME:389/dc%3Dint%2Cdc%3DDOMAIN%2Cdc%3Dcom)
failed.
[31/Jul/2018:12:19:05.613868420 +0100] - ERR - attrlist_replace -
attr_replace (nsslapd-referral,
ldap://cro-system-02.DOMAINNAME:389/dc%3Dint%2Cdc%3DDOMAIN%2Cdc%3Dcom)
failed.
[31/Jul/2018:12:19:05.634974836 +0100] - ERR -
schema-compat-plugin - schema-compat-plugin tree scan will start
in about 5 seconds!
[31/Jul/2018:12:19:05.646685174 +0100] - ERR - set_krb5_creds -
Could not get initial credentials for principal
[ldap/pul-system-01.DOMAINNAME@DOMAINNAME] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text))
[31/Jul/2018:12:19:05.657290290 +0100] - INFO - slapd_daemon -
slapd started.  Listening on All Interfaces port 389 for LDAP requests
[31/Jul/2018:12:19:05.660478907 +0100] - INFO - slapd_daemon -
Listening on All Interfaces port 636 for LDAPS requests
[31/Jul/2018:12:19:05.664268080 +0100] - INFO - slapd_daemon -
Listening on /var/run/slapd-INT-DOMAIN-COM.socket for LDAPI requests
[31/Jul/2018:12:19:05.712942138 +0100] - ERR -
NSMMReplicationPlugin - bind_and_check_pwp -
agmt="cn=pul-system-01.DOMAINNAME-to-pul-system-02.DOMAINNAME"
(pul-system-02:389) - Replication bind with GSSAPI auth failed:
LDAP error -6 (Unknown authentication method) (SASL(-4): no
mechanism available: No worthy mechs found)
[31/Jul/2018:12:19:08.916600270 +0100] - INFO -
NSMMReplicationPlugin - bind_and_check_pwp -
agmt="cn=pul-system-01.DOMAINNAME-to-pul-system-02.DOMAINNAME"
(pul-system-02:389): Replication bind with GSSAPI auth resumed
[31/Jul/2018:12:19:11.139026788 +0100] - ERR -
schema-compat-plugin - warning: no entries set up under
cn=computers, cn=compat,dc=int,dc=DOMAIN,dc=com
[31/Jul/2018:12:19:11.143128988 +0100] - ERR -
schema-compat-plugin - Finished plugin initialization.
[31/Jul/2018:12:19:26.258468102 +0100] - ERR - ipa-topology-plugin
- ipa_topo_util_get_replica_conf: server configuration missing
[31/Jul/2018:12:19:26.261488755 +0100] - ERR - ipa-topology-plugin
- ipa_topo_util_get_replica_conf: cannot create replica
[31/Jul/2018:12:19:41.405312942 +0100] - ERR - attrlist_replace -
attr_replace (nsslapd-referral,
ldap://cro-system-02.DOMAINNAME:389/dc%3Dint%2Cdc%3DDOMAIN%2Cdc%3Dcom)
failed.
[31/Jul/2018:12:19:41.407352984 +0100] - ERR - attrlist_replace -
attr_replace (nsslapd-referral,
ldap://cro-system-02.DOMAINNAME:389/dc%3Dint%2Cdc%3DDOMAIN%2Cdc%3Dcom)
failed.
[31/Jul/2018:12:19:41.409312145 +0100] - ERR - attrlist_replace -
attr_replace (nsslapd-referral,
ldap://cro-system-02.DOMAINNAME:389/dc%3Dint%2Cdc%3DDOMAIN%2Cdc%3Dcom)
failed.
[31/Jul/2018:12:19:44.484329977 +0100] - ERR - attrlist_replace -
attr_replace (nsslapd-referral,
ldap://hk-system-02.DOMAINNAME:389/dc%3Dint%2Cdc%3DDOMAIN%2Cdc%3Dcom)
failed.
[31/Jul/2018:12:19:44.489032389 +0100] - ERR - attrlist_replace -
attr_replace (nsslapd-referral,
ldap://hk-system-02.DOMAINNAME:389/dc%3Dint%2Cdc%3DDOMAIN%2Cdc%3Dcom)
failed.
[31/Jul/2018:12:19:44.490775486 +0100] - ERR - attrlist_replace -
attr_replace (nsslapd-referral,
ldap://hk-system-02.DOMAINNAME:389/dc%3Dint%2Cdc%3DDOMAIN%2Cdc%3Dcom)
failed.
[31/Jul/2018:12:19:46.882743610 +0100] - ERR - attrlist_replace -
attr_replace (nsslapd-referral,
ldap://hk-system-02.DOMAINNAME:389/dc%3Dint%2Cdc%3DDOMAIN%2Cdc%3Dcom)
failed.
[31/Jul/2018:12:19:46.887246145 +0100] - ERR - attrlist_replace -
attr_replace (nsslapd-referral,
ldap://hk-system-02.DOMAINNAME:389/dc%3Dint%2Cdc%3DDOMAIN%2Cdc%3Dcom)
failed.
[31/Jul/2018:12:19:46.889667896 +0100] - ERR - attrlist_replace -
attr_replace (nsslapd-referral,
ldap://hk-system-02.DOMAINNAME:389/dc%3Dint%2Cdc%3DDOMAIN%2Cdc%3Dcom)
failed.


___
FreeIPA

[Freeipa-users] Re: Problems setting up replica on Raspberry Pi 3B (ARM)

[Mark Reynolds via FreeIPA-users]

I was right I did fix all the ARM issues, but not in 1.3.8, only in 
1.4.0.  It was a large change though that required a few patches.  I'll 
see what I can do about backporting the changes...



On 06/01/2018 05:38 PM, Jonathan Vaughn wrote:

Created https://pagure.io/389-ds-base/issue/49746

I'll get you the build log once it's done building without the patch.

On Fri, Jun 1, 2018 at 3:54 PM, Mark Reynolds > wrote:




On 06/01/2018 04:32 PM, Jonathan Vaughn wrote:

Alright, I think I've got everything* working. (* Not running the
CA server on the Arm device, not tested, but from what I've read
before I would need to adjust the startup timeout since OpenJDK
is so slow).

1) I removed the Arm replica from the cluster and reimaged the
device entirely and started over.

2) Rebuilt 389-ds-base using the patch by Mark Reynolds, and
replica install succeeded (just as it did with the patch before).
I did use the next version (1.3.8) of 389-ds-base because the
package installed version bumped up to 1.3.8.1 - patch worked
same as on 1.3.7

3) I also had to apply the fix to /etc/httpd/conf.d/ipa.conf from
https://pagure.io/freeipa/issue/7337
 so that Web UI login could
work (I did this previously on the Arm device but still couldn't
login - likely just too many things were tried and something else
was busted elsewhere).

As far as I can tell everything seems to be working now.

I'm not sure if the patch provided would work as-is or if it
would break on non-Arm architectures.

The patch :

diff --git a/ldap/servers/plugins/replication/repl5_agmt.c
b/ldap/servers/plugins/replication/repl5_agmt.c
index d71d3f38b..e0f1f41bd 100644
--- a/ldap/servers/plugins/replication/repl5_agmt.c
+++ b/ldap/servers/plugins/replication/repl5_agmt.c
@@ -3035,7 +3035,7 @@ agmt_update_maxcsn(Replica *r, Slapi_DN
*sdn, int op, LDAPMod **mods, CSN *csn)
 slapi_ch_free_string(&agmt->maxcsn);
                 agmt->maxcsn =
slapi_ch_smprintf("%s;%s;%s;%ld;%d;%s",
slapi_sdn_get_dn(agmt->replarea),
    slapi_rdn_get_value_by_ref(slapi_rdn_get_rdn(agmt->rdn)),
agmt->hostname,
-      agmt->port, agmt->consumerRID, maxcsn);
+      (long)agmt->port, (int)agmt->consumerRID, maxcsn);
             }
             PR_Unlock(agmt->lock);
         }

To get this fixed properly (to avoid building from source),
should I open an issue in Pagure.io ? Or will someone else handle
that?


Please file ticket:

https://pagure.io/389-ds-base/new_issue


Can you also do me a favor please?  Please build the server again,
but without my patch, and send the build output to me.  I want to
see if there are any compiler errors/warnings.  The issue is that
I fixed all the issues on ARM, including this exact issue you ran
into.  Its working for others without issue.  I was wondering if
it was perhaps Raspberry's version of ARM  that was causing
issues.  Anyway the build output (without my fix) would be very
interesting to look at.

Thanks,
Mark



On Wed, May 23, 2018 at 4:04 PM, Jonathan Vaughn
mailto:jonat...@creatuity.com>> wrote:

Anyone have any further suggestions for troubleshooting this
issue with the web UI?

On Fri, May 18, 2018 at 4:01 PM, Jonathan Vaughn
mailto:jonat...@creatuity.com>> wrote:

httpd error_log

[Fri May 18 15:58:29.546255 2018] [wsgi:error] [pid
14004:tid 2903716672] [remote 10.10.11.3:59284
] ipa: DEBUG: WSGI
wsgi_dispatch.__call__:
[Fri May 18 15:58:29.547217 2018] [wsgi:error] [pid
14004:tid 2903716672] [remote 10.10.11.3:59284
] ipa: DEBUG: WSGI
login_password.__call__:
[Fri May 18 15:58:29.549799 2018] [wsgi:error] [pid
14004:tid 2903716672] [remote 10.10.11.3:59284
] ipa: DEBUG: Obtaining armor in
ccache /var/run/ipa/ccaches/armor_14004
[Fri May 18 15:58:29.550812 2018] [wsgi:error] [pid
14004:tid 2903716672] [remote 10.10.11.3:59284
] ipa: DEBUG: Initializing
anonymous ccache
[Fri May 18 15:58:29.552268 2018] [wsgi:error] [pid
14004:tid 2903716672] [remote 10.10.11.3:59284
] ipa: DEBUG: Starting external
process
[Fri May 18 15:58:29.553377 2018] [wsgi:error] [pid
14004:tid 2903716672] [remote 10.10.11.3:59284
] ipa: DEBUG:
args=/usr/bin/kinit -n -c
/var/run/ipa/ccaches/armor_14004 -X
X509_anchors=FILE:/var/k

[Freeipa-users] Re: Problems setting up replica on Raspberry Pi 3B (ARM)

[Mark Reynolds via FreeIPA-users]

On 06/01/2018 04:32 PM, Jonathan Vaughn wrote:
Alright, I think I've got everything* working. (* Not running the CA 
server on the Arm device, not tested, but from what I've read before I 
would need to adjust the startup timeout since OpenJDK is so slow).


1) I removed the Arm replica from the cluster and reimaged the device 
entirely and started over.


2) Rebuilt 389-ds-base using the patch by Mark Reynolds, and replica 
install succeeded (just as it did with the patch before). I did use 
the next version (1.3.8) of 389-ds-base because the package installed 
version bumped up to 1.3.8.1 - patch worked same as on 1.3.7


3) I also had to apply the fix to /etc/httpd/conf.d/ipa.conf from 
https://pagure.io/freeipa/issue/7337 so that Web UI login could work 
(I did this previously on the Arm device but still couldn't login - 
likely just too many things were tried and something else was busted 
elsewhere).


As far as I can tell everything seems to be working now.

I'm not sure if the patch provided would work as-is or if it would 
break on non-Arm architectures.


The patch :

diff --git a/ldap/servers/plugins/replication/repl5_agmt.c 
b/ldap/servers/plugins/replication/repl5_agmt.c

index d71d3f38b..e0f1f41bd 100644
--- a/ldap/servers/plugins/replication/repl5_agmt.c
+++ b/ldap/servers/plugins/replication/repl5_agmt.c
@@ -3035,7 +3035,7 @@ agmt_update_maxcsn(Replica *r, Slapi_DN *sdn, 
int op, LDAPMod **mods, CSN *csn)

 slapi_ch_free_string(&agmt->maxcsn);
                 agmt->maxcsn = 
slapi_ch_smprintf("%s;%s;%s;%ld;%d;%s", slapi_sdn_get_dn(agmt->replarea),

slapi_rdn_get_value_by_ref(slapi_rdn_get_rdn(agmt->rdn)), agmt->hostname,
-  agmt->port, agmt->consumerRID, maxcsn);
+  (long)agmt->port, (int)agmt->consumerRID, maxcsn);
             }
             PR_Unlock(agmt->lock);
         }

To get this fixed properly (to avoid building from source), should I 
open an issue in Pagure.io ? Or will someone else handle that?


Please file ticket:

https://pagure.io/389-ds-base/new_issue

Can you also do me a favor please?  Please build the server again, but 
without my patch, and send the build output to me.  I want to see if 
there are any compiler errors/warnings.  The issue is that I fixed all 
the issues on ARM, including this exact issue you ran into.  Its working 
for others without issue.  I was wondering if it was perhaps Raspberry's 
version of ARM  that was causing issues. Anyway the build output 
(without my fix) would be very interesting to look at.


Thanks,
Mark


On Wed, May 23, 2018 at 4:04 PM, Jonathan Vaughn 
mailto:jonat...@creatuity.com>> wrote:


Anyone have any further suggestions for troubleshooting this issue
with the web UI?

On Fri, May 18, 2018 at 4:01 PM, Jonathan Vaughn
mailto:jonat...@creatuity.com>> wrote:

httpd error_log

[Fri May 18 15:58:29.546255 2018] [wsgi:error] [pid 14004:tid
2903716672] [remote 10.10.11.3:59284
] ipa: DEBUG: WSGI
wsgi_dispatch.__call__:
[Fri May 18 15:58:29.547217 2018] [wsgi:error] [pid 14004:tid
2903716672] [remote 10.10.11.3:59284
] ipa: DEBUG: WSGI
login_password.__call__:
[Fri May 18 15:58:29.549799 2018] [wsgi:error] [pid 14004:tid
2903716672] [remote 10.10.11.3:59284
] ipa: DEBUG: Obtaining armor in
ccache /var/run/ipa/ccaches/armor_14004
[Fri May 18 15:58:29.550812 2018] [wsgi:error] [pid 14004:tid
2903716672] [remote 10.10.11.3:59284
] ipa: DEBUG: Initializing anonymous
ccache
[Fri May 18 15:58:29.552268 2018] [wsgi:error] [pid 14004:tid
2903716672] [remote 10.10.11.3:59284
] ipa: DEBUG: Starting external process
[Fri May 18 15:58:29.553377 2018] [wsgi:error] [pid 14004:tid
2903716672] [remote 10.10.11.3:59284
] ipa: DEBUG: args=/usr/bin/kinit -n
-c /var/run/ipa/ccaches/armor_14004 -X
X509_anchors=FILE:/var/kerberos/krb5kdc/kdc.crt -X
X509_anchors=FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
[Fri May 18 15:58:30.486537 2018] [wsgi:error] [pid 14004:tid
2903716672] [remote 10.10.11.3:59284
] ipa: DEBUG: Process finished,
return code=0
[Fri May 18 15:58:30.488137 2018] [wsgi:error] [pid 14004:tid
2903716672] [remote 10.10.11.3:59284
] ipa: DEBUG: stdout=
[Fri May 18 15:58:30.489128 2018] [wsgi:error] [pid 14004:tid
2903716672] [remote 10.10.11.3:59284
] ipa: DEBUG: stderr=
[Fri May 18 15:58:30.490955 2018] [wsgi:error] [pid 14004:tid
2903716672] [remote 10.10.11.3:59284
] ipa: DEBUG: Initializing principal
admin using password
[Fri May 18 15:58:30.492060 

[Freeipa-users] Re: Major Server Failure

[Mark Reynolds via FreeIPA-users]

On 05/23/2018 10:57 AM, Michael Rainey (Contractor, Code 7320) via
FreeIPA-users wrote:
>> But of course I have to ask, is sump actually running?
> Yes, sump is running.  I thought about mentoning this right after
> hitting the send button.  I only wish my problem was that simple.
>
> Anyway, back to my problem at hand.  I reviewed the logs and found two
> reoccuring entries in the access and error logs.  They are listed below.
>
>> On Sump:
>> /var/log/dirsrv/slapd-/errors
>> [21/May/2018:11:50:45.730639109 -0500] - ERR -
>> agmt="cn=meTotierod." (tierod:389) - clcache_load_buffer
>> - Can't locate CSN 5af9efa80002000f in the changelog (DB
>> rc=-30988). If replication stops, the consumer may need to be
>> reinitialized.
>>
>> /var/log/dirsrv/slapd-/access
>> [22/May/2018:22:40:47.308660133 -0500] conn=4574 op=1 SRCH
>> base="cn=sump.,cn=masters,cn=ipa,cn=etc,"
>> scope=2 filter="(ipaConfigString=enabledService)"
>> attrs="ipaConfigString cn"
Need more "logging" than that :-)  Can you provide a snippet from just
the access log (~50 lines) during the time the replication
initialization was attempted?  

Thanks
> I found a reference to the CSN on the mailing list, but came up empty.
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-users-le...@lists.fedorahosted.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/freeipa-users@lists.fedorahosted.org/message/FZY46P6NIHCIF5T6H6DF5UHDT4OXS72B/
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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/freeipa-users@lists.fedorahosted.org/message/RN6WGCQQL63RHVCTUJ7XHX7LFLDZJ5OX/

[Freeipa-users] Re: Major Server Failure

[Mark Reynolds via FreeIPA-users]

On 05/22/2018 05:32 PM, Michael Rainey (Contractor, Code 7320) via
FreeIPA-users wrote:
> The mystery continues.  It seems might be working but in reality it's
> not.  The replica has stopped updating from the master and is unable
> to talk to the LDAP server.  I'm fairly certain this is a certificate
> issue.  However, my certs appear to be valid.
>
> So far, the ipa-replica-manage command using the re-initialize or
> force-sync is not fixing the problem.  Copying the LDAP database from
> the master to the replica has not worked.  Where do I go from here?
>> # ipa-replica-manage list tierod. -v
>> fitch.: replica
>>   last init status: None
>>   last init ended: 1970-01-01 00:00:00+00:00
>>   last update status: Error (0) Replica acquired successfully:
>> Incremental update succeeded
>>   last update ended: 2018-05-22 21:19:06+00:00
>> sump.: replica
The directory server access log on (sump) should confirm your theory

But of course I have to ask, is sump actually running?
>>   last init status: -1  - LDAP error: Can't contact LDAP server
>>   last init ended: 1970-01-01 00:00:00+00:00
>>   last update status: Error (-1) Problem connecting to replica - LDAP
>> error: Can't contact LDAP server (connection error)
>>   last update ended: 1970-01-01 00:00:00+00:00
>
>
>> # ipa-replica-manage list sump. -v
>> Directory Manager password:
>>
>> tierod.: replica
>>   last init status: None
>>   last init ended: 1970-01-01 00:00:00+00:00
>>   last update status: Error (0) Replica acquired successfully:
>> Incremental update succeeded
>>   last update ended: 2018-05-22 21:09:22+00:00
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-users-le...@lists.fedorahosted.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/freeipa-users@lists.fedorahosted.org/message/FYJVSCJVEWU46GDMEBNAZCZCH3UBYBTW/
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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/freeipa-users@lists.fedorahosted.org/message/VSED3CZFBGVYMIPJ3ASJDFTUGJCAXMNF/

[Freeipa-users] Re: Major Server Failure

[Mark Reynolds via FreeIPA-users]

On 05/22/2018 11:24 AM, Michael Rainey (Contractor, Code 7320) via
FreeIPA-users wrote:
> Well I'm sure how this happened.  It looks like I have an Identity
> server that has a replication agreement with itself.  Is there a
> method to help clean this up?
>
>> # ipa-replica-manage list sump. -v
>> Directory Manager password:
>>
>> sump.: replica
>>   last init status: None
>>   last init ended: 1970-01-01 00:00:00+00:00
>>   last update status: Error (0) Replica acquired successfully: Unable
>> to aquire replica: the replica has the same Replica ID as this one.
>> Replication is aborting.
This means you have two replicas that are using the same replica id
(nsds5replicaid).  Perhaps this agreement is old and needs to be removed?
>>   last update ended: 1970-01-01 00:00:00+00:00
>> tierod.: replica
>>   last init status: None
>>   last init ended: 1970-01-01 00:00:00+00:00
>>   last update status: Error (0) Replica acquired successfully:
>> Incremental update succeeded
>>   last update ended: 2018-05-22 15:07:23+00:00
>
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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/freeipa-users@lists.fedorahosted.org/message/AXI2QXJOYQVAJBQRO54EFAE5B6UL6RKS/

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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/freeipa-users@lists.fedorahosted.org/message/EEZPRIRMFS2BK6GBKPZUWMIW2SWQRBFW/

[Freeipa-users] Re: Dir Mgr passwd won't change?

[Mark Reynolds via FreeIPA-users]

On 05/21/2018 02:02 PM, Kat via FreeIPA-users wrote:
> Stopping 389-ds was the first step for sure - I would not fall for
> that one! :-)
>
> No access to Dir Manager,
I don't know what this means either, but please try this:

ldapsearch -D "cn=directory manager" -W -s base -b "" objectclass=top

If this fails please share the access log output (there is 30 second
buffering on the log fyi):

    /var/log/dirsrv/slapd-YOUR_HOST/access

I'm looking for something like this:

[18/May/2018:12:28:46.334365436 -0400] conn=1 op=0 BIND dn="cn=Directory
Manager" method=128 version=3
[18/May/2018:12:28:46.418295813 -0400] conn=1 op=0 RESULT err=0 tag=97
nentries=0 etime=0.0084017134 dn="cn=directory manager"


So either you have not replaced the password correctly, or the
"cn=directory manger" account is not actually "cn=directory manager". 
The access log will tell us more...


> and perhaps this is where I went wrong - I skipped the ldapsearch and
> went straight to just trying to add a CA to my replicate with
> ipa-ca-install on an existing NON-CA replica and it asks for directory
> Manager Password, and I give the new one an sadly, no joy in mudville.
>
> BUT - maybe that is part of what I am doing wrong to test it?
>
> Kat
>
>
> On 5/21/18 12:31, Rob Crittenden wrote:
>> Kat via FreeIPA-users wrote:
>>> My bad - I thought the link I shared would indicate that is the process
>>> I followed. However, here are more details:
>>>
>>> ipa-server-4.5.4-10.el7_5.1.x86_64 on RHEL 7.5
>>>
>>> Steps:
>>>
>>> 1. Backup dse.ldif out of /etc/dirsrv/slapd-DOMAIN...
>>>
>>> 2. ipactl stop
>>>
>>> 3. vim dse.ldif and replace rootpw with newly hashed pw from pwdhash
>>> command
>>>
>>> 4. ipactl start
>> It is amazing how many people fail to stop 389-ds before applying the
>> change and wonder why it doesn't work. This is why I asked for the exact
>> steps.
>>
>>> I tried this on the first CA, and was unable to gain access to dirmgr.
>>> Tried it on secondary (replicas) and still no luck. So perhaps I am
>>> just
>>> not understanding that you can change Directory Manager PW by following
>>> 389-ds docs?
>> It depends on version. With older versions changing the password was
>> more complex.
>>
>> What do you mean by no access to DM? What did you do to check this?
>>
>> rob
>>
>>> thank you
>>> Kat
>>>
>>>
>>> On 5/21/18 10:49, Rob Crittenden wrote:
 Kat via FreeIPA-users wrote:
> No suggestions at all?
 https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password

 If would help if you included the version and distro and more
 details on
 how you tried to change the password.

 rob

> :-(
>
>
> On 5/16/18 09:08, Kat wrote:
>> Hi -
>>
>> Have a replica I did not install CA on. Want to add it. I had
>> lost the
>> Directory Manager password, so I followed procedure to change it by
>> editing dse.ldif and replacing the rootpw, but no matter what I do I
>> keep getting:
>>
>> [root@ipa-rep2 ~]# ipa-ca-install
>> Directory Manager (existing master) password:
>>
>> Directory Manager password is invalid
>>
>> Scratching my head - has the procedure for changing the Dir Mgr
>> password changed? I used:
>>
>> http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html
>>
>>
>>
>>
>> Any ideas?
>> -K
>>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-users-le...@lists.fedorahosted.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/freeipa-users@lists.fedorahosted.org/message/BUEPY6TBYRLMDYCT7BA65OLFOUQCRJ5R/
>
>
>
>>> ___
>>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>> To unsubscribe send an email to
>>> freeipa-users-le...@lists.fedorahosted.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/freeipa-users@lists.fedorahosted.org/message/FYGIVS2CS3SDYOQNL2BCVDEWJWQCATLE/
>>>
>>>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-users-le...@lists.fedorahosted.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/freeipa-users@lists.fedorahosted.org/message/HSEN43BFTKBTOEFR72SVFV5P5FMDXG6A/
___
Fr

[Freeipa-users] Re: replication test

[Mark Reynolds via FreeIPA-users]

On 05/21/2018 10:32 AM, i...@tecnoaccion.com.ar wrote:
> El 21/05/18 a las 11:20, Mark Reynolds escribió:
>>
>> On 05/21/2018 10:16 AM, i...@tecnoaccion.com.ar wrote:
>>> El 18/05/18 a las 20:02, Mark Reynolds escribió:
 On 05/18/2018 04:07 PM, None via FreeIPA-users wrote:
> El 18/05/18 a las 16:52, Mark Reynolds escribió:
>> On 05/18/2018 03:13 PM, i...@tecnoaccion.com.ar wrote:
>>> El 18/05/18 a las 16:09, Mark Reynolds escribió:
 On 05/18/2018 03:01 PM, None via FreeIPA-users wrote:
> hi!
>
> I'm new to FreeIPA, I inherited a FreeIPA infrastructure, and I'm
> trying to have a Nagios check for the replication status (without
> indicating a password). I found this article:
> .
>
>
>
>
> It's exactly what I want to do
>
> but, when I try to do the ldapmodify thing with
> grant_anonymous_replication_view.ldif (only changing
> cn="dc=example,dc=com" according to my installation), I get:
>
> $ ldapmodify -x -D "cn=directory manager" -W -f
> grant_anonymous_replication_view.ldif -h ipa.mydomain.com.ar
> Enter LDAP Password:
>
>
> and it doesn't accept admin or directory manager password (?)
 Do you get an invalid credentials error (49), or?
>>> that's right, I get:
>>> ldap_bind: Invalid credentials (49)
>>>
>>>
>>>
> do I have to make other changes to the ldif?
 No
> or, what is the password I need?
 Only you would know, if you don't know it then you can always
 reset
 the
 directory manager password:

 http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html


>>> I do have admin and directory manager password, I tried with both,
>>> and
>>> I got the same result (?)
>> Sounds like you don't have the correct password if you are getting
>> error
>> 49.  The only other thing it could be is that the "cn=directory
>> manager"
>> account is not setup as "cn=directory manager" in your setup. 
>> You can
>> confirm by grepping for "nsslapd-rootdn" from
>> /etc/dirsrv/slapd-YOUR_INSTANCE/dse.ldif.  If it is set to
>> "cn=directory
>> manager', then you have the wrong password and you should reset it.
>> Otherwise you have the wrong DN.  It's one or the other.
> great!
>
> it was the wrong password... Now I get this:
>
> ldapmodify: wrong attributeType at line 5, entry
> "cn="dc=example,dc=com",cn=mapping tree,cn=config"
>
>
> the full ldif is:
>
> dn: cn="dc=example,dc=com",cn=mapping tree,cn=config
> changetype: modify
> add: aci
> aci:
> (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement))")(version
>
>
> 3.0; aci "permission:Read Replication Agreements"; allow (read,
> search, compare) groupdn = "ldap:///anyone";;)
 I think the problem is the aci value.  Its multiple lines, maybe its
 wrapped weird.  There s a few ways to fix it.  In LDAP you would
 precede
 a line break with a space.  So something like this:

 dn: cn="dc=example,dc=com",cn=mapping tree,cn=config
 changetype: modify
 add: aci
 aci:
 (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)
    (objectclass=nsDSWindowsReplicationAgreement))")(version
    3.0; aci "permission:Read Replication Agreements"; allow
    (read, search, compare) groupdn = "ldap:///anyone";;)

 Or, it has to be one long line.  I am attaching a ldif with two
 examples
 you can pick from.
>>>
>>> hi!
>>>
>>> I tried both ldifs, they report the same:
>>>
>>> # ldapmodify -x -D "cn=Directory Manager" -W -f 1.ldif -h
>>> ipa.example.com.ar
>>> Enter LDAP Password:
>>> modifying entry "cn="dc=example,dc=com",cn=mapping tree,cn=config"
>>> ldap_modify: No such object (32)
>>>
>>> # ldapmodify -x -D "cn=Directory Manager" -W -f 2.ldif -h
>>> example.tecnoaccion.com.ar
>>> Enter LDAP Password:
>>> modifying entry "cn="dc=example,dc=com",cn=mapping tree,cn=config"
>>> ldap_modify: No such object (32)
>> Its probably the quotes around dc=example,dc=com
>>
>> Try replacing it with;
>>
>> cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
So the problem is that you really don't have a backend suffix
"dc=example,dc=com"

Try this:

ldapsearch -xLLL -D "cn=Directory Manager" -W -b cn=config nsslapd-backend=*

This will dump your backends, find DN from the entry for your database
and put that in the LDIF file

Mark
>
>
> hi Mark!
>
> thank you very much for your help
>
> the result in both ldifs continues to be:
>
> ldap_modify: No such object (32)
>
> I'm attaching the sanitized ldifs just

[Freeipa-users] Re: replication test

[Mark Reynolds via FreeIPA-users]

On 05/21/2018 10:16 AM, i...@tecnoaccion.com.ar wrote:
> El 18/05/18 a las 20:02, Mark Reynolds escribió:
>>
>> On 05/18/2018 04:07 PM, None via FreeIPA-users wrote:
>>> El 18/05/18 a las 16:52, Mark Reynolds escribió:
 On 05/18/2018 03:13 PM, i...@tecnoaccion.com.ar wrote:
> El 18/05/18 a las 16:09, Mark Reynolds escribió:
>> On 05/18/2018 03:01 PM, None via FreeIPA-users wrote:
>>> hi!
>>>
>>> I'm new to FreeIPA, I inherited a FreeIPA infrastructure, and I'm
>>> trying to have a Nagios check for the replication status (without
>>> indicating a password). I found this article:
>>> .
>>>
>>>
>>>
>>> It's exactly what I want to do
>>>
>>> but, when I try to do the ldapmodify thing with
>>> grant_anonymous_replication_view.ldif (only changing
>>> cn="dc=example,dc=com" according to my installation), I get:
>>>
>>> $ ldapmodify -x -D "cn=directory manager" -W -f
>>> grant_anonymous_replication_view.ldif -h ipa.mydomain.com.ar
>>> Enter LDAP Password:
>>>
>>>
>>> and it doesn't accept admin or directory manager password (?)
>> Do you get an invalid credentials error (49), or?
> that's right, I get:
> ldap_bind: Invalid credentials (49)
>
>
>
>>> do I have to make other changes to the ldif?
>> No
>>> or, what is the password I need?
>> Only you would know, if you don't know it then you can always reset
>> the
>> directory manager password:
>>
>> http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html
>>
> I do have admin and directory manager password, I tried with both,
> and
> I got the same result (?)
 Sounds like you don't have the correct password if you are getting
 error
 49.  The only other thing it could be is that the "cn=directory
 manager"
 account is not setup as "cn=directory manager" in your setup.  You can
 confirm by grepping for "nsslapd-rootdn" from
 /etc/dirsrv/slapd-YOUR_INSTANCE/dse.ldif.  If it is set to
 "cn=directory
 manager', then you have the wrong password and you should reset it.
 Otherwise you have the wrong DN.  It's one or the other.
>>>
>>> great!
>>>
>>> it was the wrong password... Now I get this:
>>>
>>> ldapmodify: wrong attributeType at line 5, entry
>>> "cn="dc=example,dc=com",cn=mapping tree,cn=config"
>>>
>>>
>>> the full ldif is:
>>>
>>> dn: cn="dc=example,dc=com",cn=mapping tree,cn=config
>>> changetype: modify
>>> add: aci
>>> aci:
>>> (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement))")(version
>>>
>>> 3.0; aci "permission:Read Replication Agreements"; allow (read,
>>> search, compare) groupdn = "ldap:///anyone";;)
>> I think the problem is the aci value.  Its multiple lines, maybe its
>> wrapped weird.  There s a few ways to fix it.  In LDAP you would precede
>> a line break with a space.  So something like this:
>>
>> dn: cn="dc=example,dc=com",cn=mapping tree,cn=config
>> changetype: modify
>> add: aci
>> aci:
>> (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)
>>   (objectclass=nsDSWindowsReplicationAgreement))")(version
>>   3.0; aci "permission:Read Replication Agreements"; allow
>>   (read, search, compare) groupdn = "ldap:///anyone";;)
>>
>> Or, it has to be one long line.  I am attaching a ldif with two examples
>> you can pick from.
>
>
> hi!
>
> I tried both ldifs, they report the same:
>
> # ldapmodify -x -D "cn=Directory Manager" -W -f 1.ldif -h
> ipa.example.com.ar
> Enter LDAP Password:
> modifying entry "cn="dc=example,dc=com",cn=mapping tree,cn=config"
> ldap_modify: No such object (32)
>
> # ldapmodify -x -D "cn=Directory Manager" -W -f 2.ldif -h
> example.tecnoaccion.com.ar
> Enter LDAP Password:
> modifying entry "cn="dc=example,dc=com",cn=mapping tree,cn=config"
> ldap_modify: No such object (32)

Its probably the quotes around dc=example,dc=com

Try replacing it with;

cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config


>
>
> best regards,
> René
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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/freeipa-users@lists.fedorahosted.org/message/NA4P4YPD2GFHPXV4TOILQ3ABODKBWPQ5/

[Freeipa-users] Re: replication test

[Mark Reynolds via FreeIPA-users]

On 05/18/2018 04:07 PM, None via FreeIPA-users wrote:
> El 18/05/18 a las 16:52, Mark Reynolds escribió:
>>
>> On 05/18/2018 03:13 PM, i...@tecnoaccion.com.ar wrote:
>>> El 18/05/18 a las 16:09, Mark Reynolds escribió:
 On 05/18/2018 03:01 PM, None via FreeIPA-users wrote:
> hi!
>
> I'm new to FreeIPA, I inherited a FreeIPA infrastructure, and I'm
> trying to have a Nagios check for the replication status (without
> indicating a password). I found this article:
> .
>
>
> It's exactly what I want to do
>
> but, when I try to do the ldapmodify thing with
> grant_anonymous_replication_view.ldif (only changing
> cn="dc=example,dc=com" according to my installation), I get:
>
> $ ldapmodify -x -D "cn=directory manager" -W -f
> grant_anonymous_replication_view.ldif -h ipa.mydomain.com.ar
> Enter LDAP Password:
>
>
> and it doesn't accept admin or directory manager password (?)
 Do you get an invalid credentials error (49), or?
>>>
>>> that's right, I get:
>>> ldap_bind: Invalid credentials (49)
>>>
>>>
>>>
> do I have to make other changes to the ldif?
 No
> or, what is the password I need?
 Only you would know, if you don't know it then you can always reset
 the
 directory manager password:

 http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html
>>>
>>> I do have admin and directory manager password, I tried with both, and
>>> I got the same result (?)
>> Sounds like you don't have the correct password if you are getting error
>> 49.  The only other thing it could be is that the "cn=directory manager"
>> account is not setup as "cn=directory manager" in your setup.  You can
>> confirm by grepping for "nsslapd-rootdn" from
>> /etc/dirsrv/slapd-YOUR_INSTANCE/dse.ldif.  If it is set to "cn=directory
>> manager', then you have the wrong password and you should reset it.
>> Otherwise you have the wrong DN.  It's one or the other.
>
>
> great!
>
> it was the wrong password... Now I get this:
>
> ldapmodify: wrong attributeType at line 5, entry
> "cn="dc=example,dc=com",cn=mapping tree,cn=config"
>
>
> the full ldif is:
>
> dn: cn="dc=example,dc=com",cn=mapping tree,cn=config
> changetype: modify
> add: aci
> aci:
> (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement))")(version
> 3.0; aci "permission:Read Replication Agreements"; allow (read,
> search, compare) groupdn = "ldap:///anyone";;)

I think the problem is the aci value.  Its multiple lines, maybe its
wrapped weird.  There s a few ways to fix it.  In LDAP you would precede
a line break with a space.  So something like this:

dn: cn="dc=example,dc=com",cn=mapping tree,cn=config
changetype: modify
add: aci
aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)
 (objectclass=nsDSWindowsReplicationAgreement))")(version
 3.0; aci "permission:Read Replication Agreements"; allow
 (read, search, compare) groupdn = "ldap:///anyone";;)

Or, it has to be one long line.  I am attaching a ldif with two examples
you can pick from.
>
>
>
> where "example" is the name of my domain without tld
>
>
> do I need to change another thing in the ldif?
>
>
> thanks in advance,
> René
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-users-le...@lists.fedorahosted.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/freeipa-users@lists.fedorahosted.org/message/DWRVK75TX74VYQR5CBLSWJQRMSCX6NSG/

dn: cn="dc=example,dc=com",cn=mapping tree,cn=config
changetype: modify
add: aci
aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)
 (objectclass=nsDSWindowsReplicationAgreement))")(version 3.0; 
 aci "permission:Read Replication Agreements"; allow (read, search, compare) groupdn = "ldap:///anyone";;)



Or

dn: cn="dc=example,dc=com",cn=mapping tree,cn=config
changetype: modify
add: aci
aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement))")(version 3.0;aci "permission:Read Replication Agreements"; allow (read, search, compare) groupdn = "ldap:///anyone";;)
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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/freeipa-users@lists.fedorahosted.org/message/2B4IMZ6NQBCCVNAVPBPPDP5PJITMPIFJ/

[Freeipa-users] Re: replication test

[Mark Reynolds via FreeIPA-users]

On 05/18/2018 03:13 PM, i...@tecnoaccion.com.ar wrote:
> El 18/05/18 a las 16:09, Mark Reynolds escribió:
>>
>> On 05/18/2018 03:01 PM, None via FreeIPA-users wrote:
>>> hi!
>>>
>>> I'm new to FreeIPA, I inherited a FreeIPA infrastructure, and I'm
>>> trying to have a Nagios check for the replication status (without
>>> indicating a password). I found this article:
>>> .
>>>
>>> It's exactly what I want to do
>>>
>>> but, when I try to do the ldapmodify thing with
>>> grant_anonymous_replication_view.ldif (only changing
>>> cn="dc=example,dc=com" according to my installation), I get:
>>>
>>> $ ldapmodify -x -D "cn=directory manager" -W -f
>>> grant_anonymous_replication_view.ldif -h ipa.mydomain.com.ar
>>> Enter LDAP Password:
>>>
>>>
>>> and it doesn't accept admin or directory manager password (?)
>> Do you get an invalid credentials error (49), or?
>
>
> that's right, I get:
> ldap_bind: Invalid credentials (49)
>
>
>
>>> do I have to make other changes to the ldif?
>> No
>>> or, what is the password I need?
>> Only you would know, if you don't know it then you can always reset the
>> directory manager password:
>>
>> http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html
>
>
> I do have admin and directory manager password, I tried with both, and
> I got the same result (?)
Sounds like you don't have the correct password if you are getting error
49.  The only other thing it could be is that the "cn=directory manager"
account is not setup as "cn=directory manager" in your setup.  You can
confirm by grepping for "nsslapd-rootdn" from
/etc/dirsrv/slapd-YOUR_INSTANCE/dse.ldif.  If it is set to "cn=directory
manager', then you have the wrong password and you should reset it. 
Otherwise you have the wrong DN.  It's one or the other.

Regards,
Mark
>
>
> thanks,
> René
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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/freeipa-users@lists.fedorahosted.org/message/4Z2BH3I53PAGFF6XFSVWHKUU7A467PLF/

[Freeipa-users] Re: replication test

[Mark Reynolds via FreeIPA-users]

On 05/18/2018 03:01 PM, None via FreeIPA-users wrote:
> hi!
>
> I'm new to FreeIPA, I inherited a FreeIPA infrastructure, and I'm
> trying to have a Nagios check for the replication status (without
> indicating a password). I found this article:
> .
> It's exactly what I want to do
>
> but, when I try to do the ldapmodify thing with
> grant_anonymous_replication_view.ldif (only changing
> cn="dc=example,dc=com" according to my installation), I get:
>
> $ ldapmodify -x -D "cn=directory manager" -W -f
> grant_anonymous_replication_view.ldif -h ipa.mydomain.com.ar
> Enter LDAP Password:
>
>
> and it doesn't accept admin or directory manager password (?)
Do you get an invalid credentials error (49), or? 
>
> do I have to make other changes to the ldif?
No
>
> or, what is the password I need?
Only you would know, if you don't know it then you can always reset the
directory manager password:

http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html

HTH,
Mark
>
> or, is it another way of making this test without indicating passwords
> in plaintext?
>
>
> thanks in advance,
> René
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-users-le...@lists.fedorahosted.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/freeipa-users@lists.fedorahosted.org/message/2ZMZNWNSSFWXESC4GZNAZRVCVW3ZHLZM/
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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/freeipa-users@lists.fedorahosted.org/message/EAZSQ6GGBJ5ZQ4BW2ZBGIEQOHR2UAFJL/

[Freeipa-users] Re: Problems setting up replica on Raspberry Pi 3B (ARM)

[Mark Reynolds via FreeIPA-users]

On 05/16/2018 03:43 PM, Jonathan Vaughn wrote:
> The installed version of 389* is 1.3.7.10-1.fc27 for armv7hl, which
> appears to be the latest available version.

Perhaps something is off with the inttypes on Raspberry.  Are you
building this yourself on Raspberry?  Can we make code changes and
compile/install them?

Before we do that though, in gdb can you run these commands in the same
gdb frame:

(gdb) p *agmt->replarea
(gdb) p *agmt->rdn


Then do:

# grep -r PRId64 /usr/include/*
# grep -r PRIu16 /usr/include/*


So if you can compile the source, then change this line in
ldap/servers/plugins/replication/repl5_agmt.c:3036, but don't do this
yet until you get me the info I just requested.

From:

    agmt->maxcsn = slapi_ch_smprintf("%s;%s;%s;%" PRId64
";%" PRIu16 ";%s", slapi_sdn_get_dn(agmt->replarea),

slapi_rdn_get_value_by_ref(slapi_rdn_get_rdn(agmt->rdn)), agmt->hostname,
 agmt->port,
agmt->consumerRID, maxcsn);

To:

    agmt->maxcsn = slapi_ch_smprintf("%s;%s;%s;%ld;%d;%s",
slapi_sdn_get_dn(agmt->replarea),

slapi_rdn_get_value_by_ref(slapi_rdn_get_rdn(agmt->rdn)), agmt->hostname,
 (long)agmt->port,
(int)agmt->consumerRID, maxcsn);


Thanks,
Mark
>
> On Wed, May 16, 2018 at 2:38 PM, Jonathan Vaughn
> mailto:jonat...@creatuity.com>> wrote:
>
> (gdb) up
> #1  0xb6926b40 in cvt_s (flags=0, prec=, width=0,
> str=0x4 ,
> ss=)
>     at ../../.././nspr/pr/src/io/prprf.c:374
> 374             slen = strlen(str);
> (gdb) up
> #2  dosprintf (ss=ss@entry=0x9e06e4bc, fmt=0xb34b0df2 "",
> fmt@entry=0xb34da770  "\360\317p\002", ap=...) at
> ../../.././nspr/pr/src/io/prprf.c:1018
> 1018                rv = cvt_s(ss, u.s, width, prec, flags);
> (gdb) up
> #3  0xb6926c8c in PR_vsmprintf (fmt=fmt@entry=0xb34da770
>  "\360\317p\002", ap=..., ap@entry=...) at
> ../../.././nspr/pr/src/io/prprf.c:1184
> 1184        rv = dosprintf(&ss, fmt, ap);
> (gdb) up
> #4  0xb6de9d18 in slapi_ch_smprintf (fmt=0xb34b0de0
> "%s;%s;%s;%ld;%d;%s") at ldap/servers/slapd/ch_malloc.c:331
> 331         p = PR_vsmprintf(fmt, ap);
> (gdb) up
> #5  0xb34625a4 in agmt_update_maxcsn (r=r@entry=0x2737810,
> sdn=0x38d9a40, sdn@entry=0x10, op=, mods=0x10,
> mods@entry=0x27d0100, csn=csn@entry=0x38de350)
>     at ldap/servers/plugins/replication/repl5_agmt.c:3036
> 3036                    agmt->maxcsn =
> slapi_ch_smprintf("%s;%s;%s;%ld;%d;%s",
> slapi_sdn_get_dn(agmt->replarea),
> (gdb) p *agmt
> $1 = {hostname = 0x2757be0 "ipa-12.company.internal", port = 389,
> transport_flags = 0, binddn = 0x26ed650 "", creds = 0x26ed7a0,
> bindmethod = 3, replarea = 0x2757480,
>   frac_attrs = 0x27579c0, frac_attrs_total = 0x2757a40,
> frac_attr_total_defined = 1, schedule = 0x22dd0c0, auto_initialize
> = 502, dn = 0x2756d00, rdn = 0x2756c20,
>   long_name = 0x22dd100 "agmt=\"cn=meToipa-12.company.internal\"
> (ipa-12:5)", protocol = 0x2220930, changecounters = 0x20cb180,
> num_changecounters = 0,
>   max_changecounters = 256, last_update_start_time = 1526499214,
> last_update_end_time = 1526499214,
>   last_update_status = "Error (0) Replica acquired successfully:
> Incremental update succeeded", '\000' ,
> update_in_progress = 0, is_enabled = 1,
>   last_init_start_time = 0, last_init_end_time = 0,
> last_init_status = '\000' , lock = 0x2741740,
> consumerRUV = 0x2772e50,
>   consumerSchemaCSN = 0x39da520, consumerRID = 4, tmpConsumerRID =
> 0, timeout = 120, stop_in_progress = 0, busywaittime = 0,
> pausetime = 0, priv = 0x0,
>   attrs_to_strip = 0x2757ba0, agreement_type = 0, protocol_timeout
> = 0x26ed5f0, maxcsn = 0x0, flowControlWindow = 1000,
> flowControlPause = 2000, ignoreMissingChange = 0,
>   attr_lock = 0x2757c20, WaitForAsyncResults = 100}
>
>
> On Tue, May 15, 2018 at 5:36 PM, Mark Reynolds
> mailto:mreyno...@redhat.com>> wrote:
>
> This looks really familiar and I thought it was fixed.  It
> should have been fixed in 1.3.7.10-1
> (https://pagure.io/389-ds-base/issue/49618
> ).   In your debug
> session go "up" into agmt_maxcsn_update() and do:
>
> (gdb) p *agmt
>
> Then send us that output please.
>
> Thanks,
> Mark
>
>
> On 05/15/2018 05:29 PM, Jonathan Vaughn via FreeIPA-users wrote:
>> Here is a backtrace from live gdb after the segfault. Looks
>> like things went wrong somewhere during in the replication
>> code ?
>>
>> Thread 36 "ns-slapd" received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0x9e0bc280 (LWP 4662)]
>> strl

[Freeipa-users] Re: Problems setting up replica on Raspberry Pi 3B (ARM)

[Mark Reynolds via FreeIPA-users]

This looks really familiar and I thought it was fixed.  It should have
been fixed in 1.3.7.10-1 (https://pagure.io/389-ds-base/issue/49618).  
In your debug session go "up" into agmt_maxcsn_update() and do:

(gdb) p *agmt

Then send us that output please.

Thanks,
Mark

On 05/15/2018 05:29 PM, Jonathan Vaughn via FreeIPA-users wrote:
> Here is a backtrace from live gdb after the segfault. Looks like
> things went wrong somewhere during in the replication code ?
>
> Thread 36 "ns-slapd" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x9e0bc280 (LWP 4662)]
> strlen () at ../sysdeps/arm/armv6t2/strlen.S:142
> 142             ldrd    data1a, data1b, [src]
> (gdb) bt
> #0  0xb6728f2e in strlen () at ../sysdeps/arm/armv6t2/strlen.S:142
> #1  0xb6973b40 in cvt_s (flags=0, prec=, width=0,
> str=0x4 , ss=)
>     at ../../.././nspr/pr/src/io/prprf.c:374
> #2  0xb6973b40 in dosprintf (ss=ss@entry=0x9e0bb4bc, fmt=0xb34fddf2
> "", fmt@entry=0xb3527770  "\360\357\305\002", ap=...)
>     at ../../.././nspr/pr/src/io/prprf.c:1018
> #3  0xb6973c8c in PR_vsmprintf (fmt=fmt@entry=0xb3527770 
> "\360\357\305\002", ap=..., ap@entry=...) at
> ../../.././nspr/pr/src/io/prprf.c:1184
> #4  0xb6e36d18 in slapi_ch_smprintf (fmt=0xb34fdde0
> "%s;%s;%s;%ld;%d;%s") at ldap/servers/slapd/ch_malloc.c:331
> #5  0xb34af5a4 in agmt_update_maxcsn (r=r@entry=0x2c89810,
> sdn=0x3e2bac0, sdn@entry=0x10, op=, mods=0x10,
> mods@entry=0x3eec100, csn=csn@entry=0x3e30220)
>     at ldap/servers/plugins/replication/repl5_agmt.c:3036
> #6  0xb34bd424 in write_changelog_and_ruv (pb=pb@entry=0x2cb54a0) at
> ldap/servers/plugins/replication/repl5_plugins.c:1124
> #7  0xb34be7ec in multimaster_be_betxnpostop_add (pb=0x2cb54a0) at
> ldap/servers/plugins/replication/repl5_plugins.c:855
> #8  0xb34be880 in multimaster_mmr_postop (pb=,
> flags=560) at ldap/servers/plugins/replication/repl5_plugins.c:616
> #9  0xb6e8fcf0 in plugin_call_mmr_plugin_postop
> (pb=pb@entry=0x2cb54a0, e=e@entry=0x0, flags=flags@entry=560) at
> ldap/servers/slapd/plugin_mmr.c:65
> #10 0xb35ba870 in ldbm_back_add (pb=0x2cb54a0) at
> ldap/servers/slapd/back-ldbm/ldbm_add.c:1218
> #11 0xb6e2ce4c in op_shared_add (pb=pb@entry=0x2cb54a0) at
> ldap/servers/slapd/add.c:679
> #12 0xb6e2d35c in add_internal_pb (pb=pb@entry=0x2cb54a0) at
> ldap/servers/slapd/add.c:407
> #13 0xb6e2e0f8 in slapi_add_internal_pb (pb=pb@entry=0x2cb54a0) at
> ldap/servers/slapd/add.c:332
> #14 0xb368db50 in ipa_topo_util_segment_write
> (tconf=tconf@entry=0x2cb5860, tsegm=tsegm@entry=0x3f2d9a0) at
> topology_util.c:1251
> #15 0xb368e01c in ipa_topo_util_update_agmt_list (conf=0x2cb5860,
> repl_segments=) at topology_util.c:696
> #16 0xb368891c in ipa_topo_apply_shared_config () at topology_init.c:165
> #17 0xb6e4e65c in eq_call_all () at ldap/servers/slapd/eventq.c:278
> #18 0xb6e4e65c in eq_loop (arg=) at
> ldap/servers/slapd/eventq.c:323
> #19 0xb6982d68 in _pt_root (arg=0x2c8da40) at
> ../../.././nspr/pr/src/pthreads/ptthread.c:201
> #20 0xb6906ee8 in start_thread (arg=0x9e0bc280) at pthread_create.c:465
> #21 0xb6785da8 in None () at ../sysdeps/unix/sysv/linux/arm/clone.S:73
>
>
> On Tue, May 15, 2018 at 3:01 AM, thierry bordaz  > wrote:
>
> Hi Jonathan,
>
> This problem looks new to me and has something specific to your
> environment.
> I think the best approach is to continue to debug on your system
> if you have the possibility to do so.
>
> From strace we can see that DS started smoothly (created its pid
> file then notified systemd it was running fine). According to the
> pstack nunc-stans was running and was able to accept network
> events even if it appears it detected no incoming connection.
> So the server should be ready to serve for some seconds (more than
> a minute), then it crashed with one thread dereferencing likely a
> wrong pointer.
>
> Could you attach a debugger when the server is started and wait
> for the sigsegv to occur. Then confirm the crashing thread backstack.
> If it is confirmed, I am afraid this is a stack corruption and
> valgrind could help
> 
> (http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-memory-growthinvalid-access-with-valgrind
> 
> ).
>
> best regards
> thierry
>
>
> On 05/14/2018 10:20 PM, Jonathan Vaughn wrote:
>> Here's a strace from before it dies. Most of the elapsed time is
>> it waiting on some futex call it looks like near the end, when it
>> finally "returns" (from lack of strace output for duration of
>> call I assume it didn't actually return but SIGSEGV in that call)
>> and strace prints ' = ?' on the futex it then immediately reports
>> SIGSEGV after. So maybe the problem is that futex call, which may
>> mean the problem is not directly in 389DS / FreeIPA itself?
>>
>>
>>
>> 15:13:31.626587 

[Freeipa-users] Re: Major Server Failure

[Mark Reynolds via FreeIPA-users]

On 05/10/2018 03:30 PM, Rob Crittenden wrote:
> Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
>> Sigh... My replication agreements really do seem to be completely
>> jacked up.  I would have expected the hostname replica agreements and
>> the hostname csreplica agreements to match.
>
> This is fairly typical. You don't really need a full CA on every
> master you just want > 1 CAs in your installation.
>
> Maybe Mark can provide some insight into the replication issues.
replication is not working because the master can not bind to the
consumer to initialize it.  Another option is to do an offline
initialization so that the consumer gets the usercertificate it needs
for incremental replication to work.

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-initializing_consumers#Initializing_Consumers-Manual_Consumer_Initialization_Using_the_Command_Line
>
> I think that once we work that out the the other CA master will get
> its updated certificate via standard means and things will hopefully
> just work at that point.
>
> rob
>
>>
>>> # ipa-replica-manage list fitch. -v
>>> Directory Manager password:
>>>
>>> kodiak.: replica
>>>   last init status: None
>>>   last init ended: 1970-01-01 00:00:00+00:00
>>>   last update status: Error (18) Replication error acquiring
>>> replica: Incremental update transient error.  Backing off, will
>>> retry update later. (transient error)
>>>   last update ended: 1970-01-01 00:00:00+00:00
>>> piston.: replica
>>>   last init status: None
>>>   last init ended: 1970-01-01 00:00:00+00:00
>>>   last update status: Error (0) Replica acquired successfully:
>>> Incremental update succeeded
>>>   last update ended: 2018-05-10 19:11:56+00:00
>>> tierod.: replica
>>>   last init status: None
>>>   last init ended: 1970-01-01 00:00:00+00:00
>>>   last update status: Error (18) Replication error acquiring
>>> replica: Incremental update transient error.  Backing off, will
>>> retry update later. (transient error)
>>>   last update ended: 1970-01-01 00:00:00+00:00
>>
>>> # ipa-csreplica-manage list fitch. -v
>>> Directory Manager password:
>>>
>>> voge.
>>>   last init status: None
>>>   last init ended: 1970-01-01 00:00:00+00:00
>>>   last update status: Error (0) No replication sessions started
>>> since server startup
>>>   last update ended: 1970-01-01 00:00:00+00:00
>>
>>
>> *Michael Rainey*
>> Network Representative
>> Naval Research Laboratory, Code 7320
>> Building 1009, Room C156
>> Stennis Space Center, MS 39529
>>
>> On 05/10/2018 01:02 PM, Michael Rainey (Contractor, Code 7320) via
>> FreeIPA-users wrote:
 Sigh. This is what I get when I type too fast. 
>>> No worries.  You're helping me to make some headway on this problem.
>>>
>>> This is more of what you are wanting to see, and for me it doesn't
>>> look good.  Does this mean I'll be using the re-initialize option or
>>> some variation?
>>>
 ipa-csreplica-manage list fitch. -v
 Directory Manager password:

 voge.
   last init status: None
   last init ended: 1970-01-01 00:00:00+00:00
   last update status: Error (0) No replication sessions started
 since server startup
   last update ended: 1970-01-01 00:00:00+00:00
>>>
>>>
>>> *Michael Rainey*
>>> Network Representative
>>> Naval Research Laboratory, Code 7320
>>> Building 1009, Room C156
>>> Stennis Space Center, MS 39529
>>>
>>> On 05/10/2018 12:09 PM, Rob Crittenden wrote:
 Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
>> Use ipa-cacert-manage -v `hostname` to see what the status is. 
> Is this correct usage for this command?  It throws out debug
> messages.

 Sigh. This is what I get when I type too fast.

 ipa-csreplica-manage ...

 rob

>> ipa-cacert-manage -v 'fitch'
>> ipa: DEBUG: Loading Index file from
>> '/var/lib/ipa/sysrestore/sysrestore.index'
>> Usage: ipa-cacert-manage renew [options]
>>    ipa-cacert-manage install [options] CERTFILE
>>
>> ipa-cacert-manage: error: unknown command "fitch"
>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File
>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line
>> 169, in execute
>>     self.validate_options()
>>   File
>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py",
>> line 105, in validate_options
>>     parser.error("unknown command \"%s\"" % command)
>>   File "/usr/lib64/python2.7/optparse.py", line 1583, in error
>>     self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg))
>>   File "/usr/lib64/python2.7/optparse.py", line 1573, in exit
>>     sys.exit(status)
>>
>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The
>> ipa-cacert-manage command failed, exception: SystemExit: 2
>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: The
>> i

[Freeipa-users] Re: Major Server Failure

[Mark Reynolds via FreeIPA-users]

On 05/10/2018 10:48 AM, Michael Rainey (Contractor, Code 7320) wrote:
>> So there are two possibilities here.  One, "cn=Replication Manager
>> cloneAgreement1-fitch.-pki-tomcat,ou=csusers,cn=config" does
>> not exist on the server, or two, you are using the wrong password for
>> this entry in the replication agreement.
>
> Perhaps the password has been corrupted.  The agreements appear to be
> there when I run the command listed below.  These systems have been
> running well for the past few years before this problem started
> appearing.  I have run the "ipa-replica-manage re-initialize" command,
> but the pki-tomcatd service still continues to fail when trying to
> start the service.  Are there any additional steps you recommend?

Try resetting the password for "cn=Replication Manager
cloneAgreement1-fitch.-pki-tomcat,ou=csusers,cn=config" to the
password you used in the agreement

# ldapmodify -D "cn=directory manager" -W
dn: cn=Replication Manager
cloneAgreement1-fitch.-pki-tomcat,ou=csusers,cn=config
changetype: modify
replace: userpassword
userpassword: YOUR_PASSWORD
>
>> [root@fitch ~]# ipa-replica-manage list fitch.
>> Directory Manager password:
>>
>> kodiak.: replica
>> piston.: replica
>> tierod.: replica
>
>
> *Michael Rainey*
> Network Representative
> Naval Research Laboratory, Code 7320
> Building 1009, Room C156
> Stennis Space Center, MS 39529
>
> On 05/09/2018 05:01 PM, Mark Reynolds via FreeIPA-users wrote:
>> So there are two possibilities here.  One, "cn=Replication Manager
>> cloneAgreement1-fitch.-pki-tomcat,ou=csusers,cn=config" does
>> not exist on the server, or two, you are using the wrong password for
>> this entry in the replication agreement.
>

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Major Server Failure

[Mark Reynolds via FreeIPA-users]

On 05/09/2018 05:54 PM, Michael Rainey (Contractor, Code 7320) via
FreeIPA-users wrote:
> Along with the logs listed below, searching through the certificates
> is not possible.  A message is returned:
>
>> Certificate operation cannot be completed: Unable to communicate with
>> CMS (Internal Server Error)
>
> Certmonger is running and pki-tomcatd is not.  "journalctl -u
> pki-tomcatd@pki-tomcat.service" shows certificates are not being
> matched.  What am I missing?
>
> Server Logs:

What version of 389-ds-base are you using?  rpm -qa | grep 389-ds-base

>> conn=23 fd=85 slot=85 SSL connection from XXX.XXX.XXX.91 to
>> XXX.XXX.XXX.91
>> conn=23 TLS1.2 256-bit AES; client CN=CA Subsystem,O=; issuer
>> CN=Certificate Authority,O=
>> conn=23 TLS1.2 failed to map client certificate to LDAP DN (Could not
>> matching certificate in User's LDAP entry)
>> conn=23 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL
>> conn=23 op=0 RESULT err=49 tag=97 nentries=0 etime=0.0022754084 -
>> Client certificate mapping failed
>
>> conn=73 fd=123 slot=123 connection from XXX.XXX.XXX.241 to XXX.XXX.XXX.91
>> [09/May/2018:08:18:50.038802503 -0500] conn=73 op=0 EXT
>> oid="1.3.6.1.4.1.1466.20037" name="start_tls_plugin"
>> [09/May/2018:08:18:50.038845419 -0500] conn=73 op=0 RESULT err=0
>> tag=120 nentries=0 etime=0.382164
>> [09/May/2018:08:18:50.046139659 -0500] conn=73 TLS1.2 256-bit AES-GCM
>> [09/May/2018:08:18:50.046531729 -0500] conn=73 op=1 BIND
>> dn="cn=Replication Manager
>> cloneAgreement1-fitch.-pki-tomcat,ou=csusers,cn=config"
>> method=128 version=3
>> [09/May/2018:08:18:50.046882326 -0500] conn=73 op=1 RESULT err=49
>> tag=97 nentries=0 etime=0.0007732885
>> [09/May/2018:08:18:50.085596219 -0500] conn=73 op=2 UNBIND
>> [09/May/2018:08:18:50.085625301 -0500] conn=73 op=2 fd=123 closed - U1

So there are two possibilities here.  One, "cn=Replication Manager
cloneAgreement1-fitch.-pki-tomcat,ou=csusers,cn=config" does not
exist on the server, or two, you are using the wrong password for this
entry in the replication agreement.



>
>
>
> *Michael Rainey*
> Network Representative
> Naval Research Laboratory, Code 7320
> Building 1009, Room C156
> Stennis Space Center, MS 39529
>
> On 05/09/2018 03:46 PM, Mark Reynolds via FreeIPA-users wrote:
>>
>>
>> On 05/09/2018 04:23 PM, Michael Rainey (Contractor, Code 7320) via
>> FreeIPA-users wrote:
>>> Rob,
>>>
>>> A big thank you for showing me howto bringthe service back.  You are
>>> correct the doesn't resolve the cause.  I suspect I'm in a bit of
>>> certificate hades.  The first sign of problems start with
>>> pki-tomcatd failing to start.  Testing of the https:
>>> url says the connection is refused.  I haven't been able to track
>>> down the cause.  However, I do have other systems exibiting the same
>>> problem.
>>>
>>>> Could not connect to LDAP server host fitch. port 636 Error
>>>> netscape.ldap.LDAPException: Authentication failed (49)
>>> From here, I'm not certain where to look.  Is this an issue with
>>> certmonger, pki-tomcatd, or something else?
>> You need to look at the Directory Server access log to find what BIND
>> DN is having problems:
>>
>> /var/log/dirsrv/slapd-YOUR_INSTANCE/access
>>
>> Then grep for "err=49".  It should say if it's a bad password or if
>> the bind dn is missing (no such object)
>>>
>>> Any suggestions?
>>>
>>>
>>> *Michael Rainey*
>>> Network Representative
>>> Naval Research Laboratory, Code 7320
>>> Building 1009, Room C156
>>> Stennis Space Center, MS 39529
>>>
>>> On 05/09/2018 02:41 PM, Rob Crittenden via FreeIPA-users wrote:
>>>> Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
>>>>> Greetings community,
>>>>>
>>>>> I'm having some major issues with my IPA servers and myself
>>>>> activating the bat signal seeking some help.  We recently upgraded
>>>>> this system to SL7.5 and ran the ipa-server-upgrade command. 
>>>>> During the upgrade the process failed and access to the LDAP
>>>>> service is nolonger possible. Running the "ipactl restart" command
>>>>> results in:
>>>>>
>>>>>> Failed to get service list from file: Unknown error when
>>>>>> retrieving list of services from file: [Errno 2] No such fil

[Freeipa-users] Re: attrlist_replace - attr_replace failed

[Mark Reynolds via FreeIPA-users]

On 05/09/2018 08:25 AM, Sandor Juhasz via FreeIPA-users wrote:
> Hello,
>
> we have a 4 way master master replication. Which is finnaly
> working, but we still see one error:
>
> [09/May/2018:14:21:27.882261986 +0200] attrlist_replace - attr_replace
> (nsslapd-referral, ldap://ipa34.bph.cxn:389/o%3Dipaca) failed.
> [09/May/2018:14:21:31.827746424 +0200] attrlist_replace - attr_replace
> (nsslapd-referral, ldap://ipa35.bph.cxn:389/o%3Dipaca) failed.
>
> How can we fix these?
These are harmless messages and can be ignored, and they have been
removed in newer releases of 389-ds-base
>
> --
> *Sándor Juhász*
> System Administrator
> *ChemAxon* *Ltd*.
> Building Hx, GraphiSoft Park, Záhony utca 7, Budapest, Hungary, H-1031
> Cell: +36704258964
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Major Server Failure

[Mark Reynolds via FreeIPA-users]

On 05/09/2018 04:23 PM, Michael Rainey (Contractor, Code 7320) via
FreeIPA-users wrote:
> Rob,
>
> A big thank you for showing me howto bringthe service back.  You are
> correct the doesn't resolve the cause.  I suspect I'm in a bit of
> certificate hades.  The first sign of problems start with pki-tomcatd
> failing to start.  Testing of the https: url says the
> connection is refused.  I haven't been able to track down the cause. 
> However, I do have other systems exibiting the same problem.
>
>> Could not connect to LDAP server host fitch. port 636 Error
>> netscape.ldap.LDAPException: Authentication failed (49)
> From here, I'm not certain where to look.  Is this an issue with
> certmonger, pki-tomcatd, or something else?
You need to look at the Directory Server access log to find what BIND DN
is having problems:

/var/log/dirsrv/slapd-YOUR_INSTANCE/access

Then grep for "err=49".  It should say if it's a bad password or if the
bind dn is missing (no such object)
>
> Any suggestions?
>
>
> *Michael Rainey*
> Network Representative
> Naval Research Laboratory, Code 7320
> Building 1009, Room C156
> Stennis Space Center, MS 39529
>
> On 05/09/2018 02:41 PM, Rob Crittenden via FreeIPA-users wrote:
>> Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
>>> Greetings community,
>>>
>>> I'm having some major issues with my IPA servers and myself
>>> activating the bat signal seeking some help.  We recently upgraded
>>> this system to SL7.5 and ran the ipa-server-upgrade command.  During
>>> the upgrade the process failed and access to the LDAP service is
>>> nolonger possible. Running the "ipactl restart" command results in:
>>>
 Failed to get service list from file: Unknown error when retrieving
 list of services from file: [Errno 2] No such file or directory:
 '/var/run/ipa/services.list'
>>>
>>> I have tried running the "ipa-replica-manage re-initialize" command
>>> in an attempt resync the servers to noavail.  I have also been
>>> reviewing certificates and no certificates appear to be expired.  I
>>> believe the main cause of this problem has been the pki-tomcatd
>>> service would not start.
>>>
>>> I'm guessing the first step in this process is to get the LDAP
>>> server running again.  Are there any steps that someone could
>>> recommend to revive LDAP?  I'm able to start and stop the service
>>> mainually, but the listening port 636 is not active.
>>
>> Shut down dirsrv then edit dse.ldif and set:
>>
>> nsslapd-port = 389
>> nsslapd-security = on
>>
>> That should get things running but doesn't address the cause of the
>> upgarde failure.
>>
>> rob
>>
>>>
 ERR - slapi_ldap_bind - Error: could not send startTLS request:
 error -1 (Can't contact LDAP server) errno 107 (Transport endpoint
 is not connected)
>>>
>>> Your help is greatly appreciated.
>>>
>>> -- 
>>> *Michael Rainey*
>>> Network Representative
>>> Naval Research Laboratory, Code 7320
>>> Building 1009, Room C156
>>> Stennis Space Center, MS 39529
>>>
>>>
>>>
>>> ___
>>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>> To unsubscribe send an email to
>>> freeipa-users-le...@lists.fedorahosted.org
>>>
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to
>> freeipa-users-le...@lists.fedorahosted.org
>
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: FreeIPA server: Replication issues

[Mark Reynolds via FreeIPA-users]

Hi James,

On 11/15/2017 10:11 AM, James Harrison via FreeIPA-users wrote:
> Hello,
> I am using Centos to host our FreeIPA servers. We have a CA-less setup.
>
> I have upgraded to Centos 7.4 and FreeIPA version : VERSION: 4.5.0,
> API_VERSION: 2.228
>
> The upgrade of both went off without any seen errors.
>
> However, now I am getting the following messages on each server (12 in
> total):
> "ERR - attrlist_replace - attr_replace (nsslapd-referral" messages
This is a known issue which has been fixed: 

https://pagure.io/389-ds-base/issue/49180
https://bugzilla.redhat.com/show_bug.cgi?id=1499668

These messages can be ignored until you upgrade to a newer version of
389-ds-base that has this fix.

Regards,
Mark
>
> Firstly, are these messages real problems I need to deal with?
> Secondly, if they are problems, how do I fix them? I have searched the
> internet and found lots of confusing mail threads, but no howto style
> document.
>
> Thanks for any help.
>
> Regards,
> James Harrison
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: IPA crashed and after restarting services seeing "Replica has a different generation ID than the local data." in log

[Mark Reynolds via FreeIPA-users]

On 10/18/2017 09:06 AM, john.bowman--- via FreeIPA-users wrote:
> Howdy!  Looks like the IPA application crashed on one of our servers (RHEL 6) 
> early this morning and after restarting it I saw the following in 
> /var/log/dirsrv/slapd-TLD/errors log:
>
> [18/Oct/2017:07:35:49 -0500] - slapd started.  Listening on All Interfaces 
> port 389 for LDAP requests
> [18/Oct/2017:07:35:49 -0500] - Listening on All Interfaces port 636 for LDAPS 
> requests
> [18/Oct/2017:07:35:49 -0500] - Listening on /var/run/slapd-TLD.socket for 
> LDAPI requests
> [18/Oct/2017:07:35:59 -0500] NSMMReplicationPlugin - agmt="cn=meToidm1.tld 
> (idm1:389): Replica has a different generation ID than the local data.
> [18/Oct/2017:07:36:03 -0500] NSMMReplicationPlugin - agmt="cn=meToidm2..tld" 
> (idm2:389): Replica has a different generation ID than the local data.
> [18/Oct/2017:07:36:03 -0500] NSMMReplicationPlugin - agmt="cn=meToidm1.tld" 
> (idm1:389): Replica has a different generation ID than the local data.
These errors indicate that the database on the server and remote replica
do not have the same origin.  Which means either the replica was not
initialized from this server, or the local db or the remote was
overwritten from a different import.  Or perhaps the database got
corrupted if the Directory Server crashed.  Either way they are now out
of sync, and you need to reinitialize the replication agreements.  The
issue is which direction to initialize replication:  idm1 -> idm2 or
idm2 to idm1?  You have to figure out which one has the correct/current
data set, then use that server to initialize the other.  Once you
initialize the agreements these errors should go away and replication
should work. 
>
> And that same message appears in the error log on the hosts that have a 
> replication agreement with this node.   And it does not appear to be 
> replicating with the other nodes as well.
>
> I searched for that message and found:
>
> https://access.redhat.com/solutions/136993
>
> But that implies that this is from a failed install and that is not the same 
> situation.   
>
> Any ideas on the best method to clean this up would be appreciated.
>
> Thanks!
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Can't install ipa-server-4.5.0 on RHEL 7.4: Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 768.

[Mark Reynolds via FreeIPA-users]

On 10/04/2017 04:03 PM, Mark Reynolds via FreeIPA-users wrote:
>
> On 10/04/2017 01:30 PM, Rob Crittenden via FreeIPA-users wrote:
>> Markovich via FreeIPA-users wrote:
>>> Hello freeipa-users!
>>>
>>> I'm trying to install ipa-server-4.5.0-21.0.1.el7_4.1.2.x86_64 on Red Hat 
>>> Enterprise Linux Server release 7.4 (Maipo) but getting error:
>>>
>>> [Setup] Info Could not import LDIF file '/var/lib/dirsrv/boot.ldif'.  
>>> Error: 768.  Output: importing data ...
>>> [04/Oct/2017:11:55:53.798978140 -0400] - ERR - spal_meminfo_get - Unable to 
>>> retrieve /proc/meminfo : MemAvailable:
>>> ...
>>>
>> Hmm, very strange that MemAvailable is not in /proc/meminfo. Is this
>> bare metal, a VM (what type), what architecture?
> That value is hardcoded:
>
>     char *f_meminfo = "/proc/meminfo";
>     char *p_memtotal = "MemTotal:";
>     char *p_memavail = "MemAvailable:";
>     ...
>     ...
>     if (_spal_uint64_t_file_get(f_meminfo, p_memavail, &memavail)) {
>     slapi_log_err(SLAPI_LOG_ERR, "spal_meminfo_get", "Unable to
> retrieve %s : %s\n", f_meminfo, p_memavail);
>     }
>
> However, these "errors" probably have nothing to do with the import
> failure.  Are there any more messages in the Directory Server's errors log?
Sorry I missed the logging below...  Now this is a problem:

[04/Oct/2017:11:55:53.963334442 -0400] - INFO - check_and_set_import_cache - 
pagesize: 4096, available bytes 9223372030878334975, process usage 13570048
[04/Oct/2017:11:55:53.964858651 -0400] - INFO - check_and_set_import_cache - 
Import allocates 144115185741308KB import cache.

Those values are NOT correct, and they are coming from spal_meminfo_get().  It 
looks like spal_meminfo_get() might not be properly handling this error 
condition (as Rob previously noted). 

Please file a ticket so we can investigate this:

https://pagure.io/389-ds-base/new_issue

Thanks,
Mark

 

>> There is some error handling around not retrieving this but it seems to
>> not be working. Sure seems like it is picking some rather humongous
>> values, or it is considering a bad memory pointer to be an int or something.
>>
>> rob
>>
>>
>>> cat /proc/meminfo
>>> MemTotal:   16170720 kB
>>> MemFree: 9051152 kB
>>> Buffers:   11280 kB
>>> Cached:  3490240 kB
>>> SwapCached:0 kB
>>> Active:  5041772 kB
>>> Inactive:1337116 kB
>>> Active(anon):2878404 kB
>>> Inactive(anon): 8128 kB
>>> Active(file):2163368 kB
>>> Inactive(file):  1328988 kB
>>> Unevictable:   0 kB
>>> Mlocked:   0 kB
>>> SwapTotal:   2097148 kB
>>> SwapFree:2097148 kB
>>> Dirty:   400 kB
>>> Writeback: 0 kB
>>> AnonPages:   2877664 kB
>>> Mapped:66880 kB
>>> Shmem:  8876 kB
>>> Slab: 562760 kB
>>> SReclaimable: 519908 kB
>>> SUnreclaim:42852 kB
>>> KernelStack:7408 kB
>>> PageTables:12624 kB
>>> NFS_Unstable:  0 kB
>>> Bounce:0 kB
>>> WritebackTmp:  0 kB
>>> CommitLimit:10182508 kB
>>> Committed_AS:5700160 kB
>>> VmallocTotal:   34359738367 kB
>>> VmallocUsed:   31364 kB
>>> VmallocChunk:   34359694544 kB
>>> HardwareCorrupted: 0 kB
>>> HugePages_Total:   0
>>> HugePages_Free:0
>>> HugePages_Rsvd:0
>>> HugePages_Surp:0
>>> Hugepagesize:   2048 kB
>>> DirectMap4k:8192 kB
>>> DirectMap2M: 2088960 kB
>>> DirectMap1G:14680064 kB
>>>
>>>  My command:
>>>
>>> ipa-server-install --hostname=myhostname --domain=mydomain.com 
>>> --realm=MYDOMAIN.COM 
>>> --ds-password=password--master-password=password--admin-password=password--unattended
>>>  --debug
>>>
>>> And on the second step:
>>>
>>> Done configuring NTP daemon (ntpd).
>>> Configuring directory server (dirsrv). Estimated time: 30 seconds
>>>   [1/45]: creating directory server instance
>>>   [error] RuntimeError: failed to create DS instance Command 
>>> '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmpPQPUX_' returned 
>>> non-zero exit status 1
>>>
>>>
>>> More debug info is here:
>>>
>>

[Freeipa-users] Re: Can't install ipa-server-4.5.0 on RHEL 7.4: Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 768.

[Mark Reynolds via FreeIPA-users]

On 10/04/2017 01:30 PM, Rob Crittenden via FreeIPA-users wrote:
> Markovich via FreeIPA-users wrote:
>> Hello freeipa-users!
>>
>> I'm trying to install ipa-server-4.5.0-21.0.1.el7_4.1.2.x86_64 on Red Hat 
>> Enterprise Linux Server release 7.4 (Maipo) but getting error:
>>
>> [Setup] Info Could not import LDIF file '/var/lib/dirsrv/boot.ldif'.  Error: 
>> 768.  Output: importing data ...
>> [04/Oct/2017:11:55:53.798978140 -0400] - ERR - spal_meminfo_get - Unable to 
>> retrieve /proc/meminfo : MemAvailable:
>> ...
>>
> Hmm, very strange that MemAvailable is not in /proc/meminfo. Is this
> bare metal, a VM (what type), what architecture?
That value is hardcoded:

    char *f_meminfo = "/proc/meminfo";
    char *p_memtotal = "MemTotal:";
    char *p_memavail = "MemAvailable:";
    ...
    ...
    if (_spal_uint64_t_file_get(f_meminfo, p_memavail, &memavail)) {
    slapi_log_err(SLAPI_LOG_ERR, "spal_meminfo_get", "Unable to
retrieve %s : %s\n", f_meminfo, p_memavail);
    }

However, these "errors" probably have nothing to do with the import
failure.  Are there any more messages in the Directory Server's errors log?
>
> There is some error handling around not retrieving this but it seems to
> not be working. Sure seems like it is picking some rather humongous
> values, or it is considering a bad memory pointer to be an int or something.
>
> rob
>
>
>> cat /proc/meminfo
>> MemTotal:   16170720 kB
>> MemFree: 9051152 kB
>> Buffers:   11280 kB
>> Cached:  3490240 kB
>> SwapCached:0 kB
>> Active:  5041772 kB
>> Inactive:1337116 kB
>> Active(anon):2878404 kB
>> Inactive(anon): 8128 kB
>> Active(file):2163368 kB
>> Inactive(file):  1328988 kB
>> Unevictable:   0 kB
>> Mlocked:   0 kB
>> SwapTotal:   2097148 kB
>> SwapFree:2097148 kB
>> Dirty:   400 kB
>> Writeback: 0 kB
>> AnonPages:   2877664 kB
>> Mapped:66880 kB
>> Shmem:  8876 kB
>> Slab: 562760 kB
>> SReclaimable: 519908 kB
>> SUnreclaim:42852 kB
>> KernelStack:7408 kB
>> PageTables:12624 kB
>> NFS_Unstable:  0 kB
>> Bounce:0 kB
>> WritebackTmp:  0 kB
>> CommitLimit:10182508 kB
>> Committed_AS:5700160 kB
>> VmallocTotal:   34359738367 kB
>> VmallocUsed:   31364 kB
>> VmallocChunk:   34359694544 kB
>> HardwareCorrupted: 0 kB
>> HugePages_Total:   0
>> HugePages_Free:0
>> HugePages_Rsvd:0
>> HugePages_Surp:0
>> Hugepagesize:   2048 kB
>> DirectMap4k:8192 kB
>> DirectMap2M: 2088960 kB
>> DirectMap1G:14680064 kB
>>
>>  My command:
>>
>> ipa-server-install --hostname=myhostname --domain=mydomain.com 
>> --realm=MYDOMAIN.COM 
>> --ds-password=password--master-password=password--admin-password=password--unattended
>>  --debug
>>
>> And on the second step:
>>
>> Done configuring NTP daemon (ntpd).
>> Configuring directory server (dirsrv). Estimated time: 30 seconds
>>   [1/45]: creating directory server instance
>>   [error] RuntimeError: failed to create DS instance Command 
>> '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmpPQPUX_' returned 
>> non-zero exit status 1
>>
>>
>> More debug info is here:
>>
>> 2017-10-04T15:55:52Z DEBUG calling setup-ds.pl
>> 2017-10-04T15:55:52Z DEBUG Starting external process
>> 2017-10-04T15:55:52Z DEBUG args=/usr/sbin/setup-ds.pl --silent --logfile - 
>> -f /tmp/tmpPQPUX_
>> 2017-10-04T15:55:56Z DEBUG Process finished, return code=1
>> 2017-10-04T15:55:56Z DEBUG stdout=[17/10/04:11:55:56] - [Setup] Info Could 
>> not import LDIF file '/var/lib/dirsrv/boot.ldif'.  Error: 768.  Output: 
>> importing data ...
>> [04/Oct/2017:11:55:53.798978140 -0400] - ERR - spal_meminfo_get - Unable to 
>> retrieve /proc/meminfo : MemAvailable:
>> [04/Oct/2017:11:55:53.900526100 -0400] - INFO - 
>> ldbm_instance_config_cachememsize_set - force a minimal value 512000
>> [04/Oct/2017:11:55:53.902864577 -0400] - ERR - spal_meminfo_get - Unable to 
>> retrieve /proc/meminfo : MemAvailable:
>> [04/Oct/2017:11:55:53.923965959 -0400] - ERR - spal_meminfo_get - Unable to 
>> retrieve /proc/meminfo : MemAvailable:
>> [04/Oct/2017:11:55:53.945262395 -0400] - ERR - spal_meminfo_get - Unable to 
>> retrieve /proc/meminfo : MemAvailable:
>> [04/Oct/2017:11:55:53.953918605 -0400] - INFO - dblayer_instance_start - 
>> Import is running with nsslapd-db-private-import-mem on; No other process is 
>> allowed to access
>>   the database
>> [04/Oct/2017:11:55:53.961341875 -0400] - ERR - spal_meminfo_get - Unable to 
>> retrieve /proc/meminfo : MemAvailable:
>> [04/Oct/2017:11:55:53.963334442 -0400] - INFO - check_and_set_import_cache - 
>> pagesize: 4096, available bytes 9223372030878334975, process usage 13570048
>> [04/Oct/2017:11:55:53.964858651 -0400] - INFO - check_and_set_import_cache - 
>> Import allo

[Freeipa-users] Re: replication problem

[Mark Reynolds via FreeIPA-users]

On 06/13/2017 10:34 AM, Eric Renfro via FreeIPA-users wrote:
> Huh.. Well, who'da thunk it. I just literally reported the same kind of
> trouble I was having, which looks like it matches this same situation,
> with the ipa-replica-install failing to initiate replication because of
> Invalid password, because the password for some reason does not seem to
> be being set.
Sorry, replication does not use the Directory Manager account. 
Typically some type of "replication manager" entry is used, and in IPA
I'm pretty sure this account uses kerberos credentials (not a password).

Going back to the Directory Manager   To confirm if the password is
set, look in /etc/dirsv/slapd-INSTANCE/dse.ldif, and under cn=config
look for "nsslapd-rootpw" if this attribute is missing then it truly is
not set.  If your directory manager account does not have a password, or
there is a password but you don't know what it is, then you can reset it
following this doc:

http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html


>
> Eric
>
>
> -Original Message-
>
> Date: Tue, 13 Jun 2017 09:49:40 -0400
> Subject: [Freeipa-users] Re: replication problem
> Cc: FreeIPA users list , Adrian
> HY 
> To: Mark Reynolds 
> Reply-to: FreeIPA users list 
> From: Adrian HY via FreeIPA-users  Hi Mark, my problem is during the replica installation. I can't use
> ldapmodify because cn=directory manager  does not have the password
> assigned.
>
> Regards.
>
> On Mon, Jun 12, 2017 at 1:38 PM, Mark Reynolds 
> wrote:
>> On 06/11/2017 01:49 PM, Adrian HY via FreeIPA-users wrote:
>>> I think I detected the problem. The error log in the replica
>>> writes:
>>>
>>> [11/Jun/2017:13:36:06.360241021 -0400] SASL encrypted packet length
>>> exceeds maximum allowed limit (length=2483849, limit=2097152). 
>>> Change the nsslapd-maxsasliosize attribute in cn=config to increase
>>> limit.
>>> [11/Jun/2017:13:36:06.361177815 -0400] ERROR bulk import abandoned
>>>
>>> According this: (https://access.redhat.com/documentation/en-US/Red_
>>> Hat_Directory_Server/8.2/pdf/Configuration_and_Command-
>>> Line_Tool_Reference/Red_Hat_Directory_Server-8.2-
>>> Configuration_and_Command-Line_Tool_Reference-en-US.pdf)
>>>
>>> "When an incoming SASL IO packet is larger than the nsslapd-
>>> maxsasliosize limit, the server  immediately disconnects the client
>>> and logs a message to the error log, so that an administrator can
>>> adjust the setting if necessary"
>>>
>>> The problem now is how can I change the value of the attribute
>>> during replication.
>>  You just use ldapmodify to change the value on each replica:
>>
>> # ldapmodify -D "cn=directory manager" -W
>> dn: cn=config
>> changetype: modify
>> replace: nsslapd-maxsasliosize
>> nsslapd-maxsasliosize:  YOUR_NEW_VALUE
>>
>>> Regards.
>>>
>>> On Sun, Jun 11, 2017 at 2:20 AM, Adrian HY 
>>> wrote:
 Hi folks, I had a problem with replication and I tried to add the
 slave back to the replica. The process stops in the initial
 replication phase.

 The firewall and selinux are down and both servers are
 synchronized with the time.

 Centos 7.3
 Freeipa 4.4.0-14

 Master error log:

 11/Jun/2017:01:11:45.690402715 -0400] NSMMReplicationPlugin -
 agmt="cn=meTousuarios-replica.ipa.server.com" (usuarios-
 replica:389): Replication bind with GSSAPI auth failed: LDAP
 error 49 (Invalid credentials) ()
 [11/Jun/2017:01:11:45.690877649 -0400] NSMMReplicationPlugin -
 Warning: unable to acquire replica for total update, error: 49,
 retrying in 1 seconds.
 [11/Jun/2017:01:11:46.966060891 -0400] NSMMReplicationPlugin -
 agmt="cn=meTousuarios-replica.ipa.server.com" (usuarios-
 replica:389): Replication bind with GSSAPI auth resumed
 [11/Jun/2017:01:11:47.095800971 -0400] NSMMReplicationPlugin -
 Beginning total update of replica "agmt="cn=meTousuarios-
 replica.ipa.server.com" (usuarios-replica:389)".
 [11/Jun/2017:01:12:06.873713837 -0400] NSMMReplicationPlugin -
 agmt="cn=meTousuarios-replica.ipa.server.com" (usuarios-
 replica:389): Failed to send extended operation: LDAP error -1
 (Can't contact LDAP server)
 [11/Jun/2017:01:12:06.874590112 -0400] NSMMReplicationPlugin -
 agmt="cn=meTousuarios-replica.ipa.server.com" (usuarios-
 replica:389): Received error -1 (Can't contact LDAP server):  for
 total updat
 e operation
 [11/Jun/2017:01:12:06.874950648 -0400] NSMMReplicationPlugin -
 agmt="cn=meTousuarios-replica.ipa.server.com" (usuarios-
 replica:389): Warning: unable to send endReplication extended
 operation (Can'
 t contact LDAP server)
 [11/Jun/2017:01:12:06.875217640 -0400] NSMMReplicationPlugin -
 Total update failed for replica "agmt="cn=meTousuarios-
 replica.ipa.server.com" (usuarios-replica:389)", error (-11)
 [11/Jun/2017:01:12:06.894882383 -0400] NSMM

[Freeipa-users] Re: replication problem

[Mark Reynolds via FreeIPA-users]

On 06/13/2017 09:49 AM, Adrian HY wrote:
> Hi Mark, my problem is during the replica installation. I can't use
> ldapmodify because *cn=directory manager * does not have the password
> assigned.
Did you remove the password from the config?  There is always a password
set during the install.  Anyway, to reset it use this doc:

http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html
>
> Regards.
>
> On Mon, Jun 12, 2017 at 1:38 PM, Mark Reynolds  > wrote:
>
>
>
> On 06/11/2017 01:49 PM, Adrian HY via FreeIPA-users wrote:
>> I think I detected the problem. The error log in the replica writes:
>>
>> *[11/Jun/2017:13:36:06.360241021 -0400] SASL encrypted packet
>> length exceeds maximum allowed limit (length=2483849,
>> limit=2097152).  Change the nsslapd-maxsasliosize attribute in
>> cn=config to increase limit.*
>> *
>> [11/Jun/2017:13:36:06.361177815 -0400] ERROR bulk import abandoned
>>
>> *
>> According this:
>> 
>> (https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/pdf/Configuration_and_Command-Line_Tool_Reference/Red_Hat_Directory_Server-8.2-Configuration_and_Command-Line_Tool_Reference-en-US.pdf
>> 
>> )
>>
>> "When an incoming SASL IO packet is larger than the
>> nsslapd-maxsasliosize limit, the server  immediately disconnects
>> the client and logs a message to the error log, so that an
>> administrator can adjust the setting if necessary"
>>
>> The problem now is how can I change the value of the attribute
>> during replication.
> You just use ldapmodify to change the value on each replica:
>
> # ldapmodify -D "cn=directory manager" -W
> dn: cn=config
> changetype: modify
> replace: nsslapd-maxsasliosize
> nsslapd-maxsasliosize:  YOUR_NEW_VALUE
>
>>
>> Regards.
>>
>> On Sun, Jun 11, 2017 at 2:20 AM, Adrian HY > > wrote:
>>
>> Hi folks, I had a problem with replication and I tried to add
>> the slave back to the replica. The process stops in the
>> initial replication phase.
>>
>> The firewall and selinux are down and both servers are
>> synchronized with the time.
>>
>> Centos 7.3
>> Freeipa 4.4.0-14
>>
>> *Master error log:*
>>
>> 11/Jun/2017:01:11:45.690402715 -0400] NSMMReplicationPlugin -
>> agmt="cn=meTousuarios-replica.ipa.server.com
>> "
>> (usuarios-replica:389): Replication bind with GSSAPI auth
>> failed: LDAP error 49 (Invalid credentials) ()
>> [11/Jun/2017:01:11:45.690877649 -0400] NSMMReplicationPlugin
>> - Warning: unable to acquire replica for total update, error:
>> 49, retrying in 1 seconds.
>> [11/Jun/2017:01:11:46.966060891 -0400] NSMMReplicationPlugin
>> - agmt="cn=meTousuarios-replica.ipa.server.com
>> "
>> (usuarios-replica:389): Replication bind with GSSAPI auth resumed
>> [11/Jun/2017:01:11:47.095800971 -0400] NSMMReplicationPlugin
>> - Beginning total update of replica
>> "agmt="cn=meTousuarios-replica.ipa.server.com
>> "
>> (usuarios-replica:389)".
>> [11/Jun/2017:01:12:06.873713837 -0400] NSMMReplicationPlugin
>> - agmt="cn=meTousuarios-replica.ipa.server.com
>> "
>> (usuarios-replica:389): Failed to send extended operation:
>> LDAP error -1 (Can't contact LDAP server)
>> [11/Jun/2017:01:12:06.874590112 -0400] NSMMReplicationPlugin
>> - agmt="cn=meTousuarios-replica.ipa.server.com
>> "
>> (usuarios-replica:389): Received error -1 (Can't contact LDAP
>> server):  for total updat
>> e operation
>> [11/Jun/2017:01:12:06.874950648 -0400] NSMMReplicationPlugin
>> - agmt="cn=meTousuarios-replica.ipa.server.com
>> "
>> (usuarios-replica:389): Warning: unable to send
>> endReplication extended operation (Can'
>> t contact LDAP server)
>> [11/Jun/2017:01:12:06.875217640 -0400] NSMMReplicationPlugin
>> - Total update failed for replica
>> "agmt="cn=meTousuarios-replica.ipa.server.com
>> "
>> (usuarios-replica:389)", error (-11)
>> [11/Jun/2017:01:12:06.894882383 -0400] NSMMReplicationPlugin
>> - agmt="cn=meTousuarios-replica.ipa.server.com
>> 

[Freeipa-users] Re: replication problem

[Mark Reynolds via FreeIPA-users]

On 06/11/2017 01:49 PM, Adrian HY via FreeIPA-users wrote:
> I think I detected the problem. The error log in the replica writes:
>
> *[11/Jun/2017:13:36:06.360241021 -0400] SASL encrypted packet length
> exceeds maximum allowed limit (length=2483849, limit=2097152).  Change
> the nsslapd-maxsasliosize attribute in cn=config to increase limit.*
> *
> [11/Jun/2017:13:36:06.361177815 -0400] ERROR bulk import abandoned
>
> *
> According this:
> (https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/pdf/Configuration_and_Command-Line_Tool_Reference/Red_Hat_Directory_Server-8.2-Configuration_and_Command-Line_Tool_Reference-en-US.pdf)
>
> "When an incoming SASL IO packet is larger than the
> nsslapd-maxsasliosize limit, the server  immediately disconnects the
> client and logs a message to the error log, so that an administrator
> can adjust the setting if necessary"
>
> The problem now is how can I change the value of the attribute during
> replication.
You just use ldapmodify to change the value on each replica:

# ldapmodify -D "cn=directory manager" -W
dn: cn=config
changetype: modify
replace: nsslapd-maxsasliosize
nsslapd-maxsasliosize:  YOUR_NEW_VALUE

>
> Regards.
>
> On Sun, Jun 11, 2017 at 2:20 AM, Adrian HY  > wrote:
>
> Hi folks, I had a problem with replication and I tried to add the
> slave back to the replica. The process stops in the initial
> replication phase.
>
> The firewall and selinux are down and both servers are
> synchronized with the time.
>
> Centos 7.3
> Freeipa 4.4.0-14
>
> *Master error log:*
>
> 11/Jun/2017:01:11:45.690402715 -0400] NSMMReplicationPlugin -
> agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389): Replication bind with GSSAPI auth failed:
> LDAP error 49 (Invalid credentials) ()
> [11/Jun/2017:01:11:45.690877649 -0400] NSMMReplicationPlugin -
> Warning: unable to acquire replica for total update, error: 49,
> retrying in 1 seconds.
> [11/Jun/2017:01:11:46.966060891 -0400] NSMMReplicationPlugin -
> agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389): Replication bind with GSSAPI auth resumed
> [11/Jun/2017:01:11:47.095800971 -0400] NSMMReplicationPlugin -
> Beginning total update of replica
> "agmt="cn=meTousuarios-replica.ipa.server.com
> " (usuarios-replica:389)".
> [11/Jun/2017:01:12:06.873713837 -0400] NSMMReplicationPlugin -
> agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389): Failed to send extended operation: LDAP
> error -1 (Can't contact LDAP server)
> [11/Jun/2017:01:12:06.874590112 -0400] NSMMReplicationPlugin -
> agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389): Received error -1 (Can't contact LDAP
> server):  for total updat
> e operation
> [11/Jun/2017:01:12:06.874950648 -0400] NSMMReplicationPlugin -
> agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389): Warning: unable to send endReplication
> extended operation (Can'
> t contact LDAP server)
> [11/Jun/2017:01:12:06.875217640 -0400] NSMMReplicationPlugin -
> Total update failed for replica
> "agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389)", error (-11)
> [11/Jun/2017:01:12:06.894882383 -0400] NSMMReplicationPlugin -
> agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389): Replication bind with GSSAPI auth resumed
> [11/Jun/2017:01:12:06.905304992 -0400] NSMMReplicationPlugin -
> agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389): The remote replica has a different
> database generation ID than
> the local database.  You may have to reinitialize the remote
> replica, or the local replica.
> [11/Jun/2017:01:12:09.912282245 -0400] NSMMReplicationPlugin -
> agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389): The remote replica has a different
> database generation ID than
> the local database.  You may have to reinitialize the remote
> replica, or the local replica.
>
> *Client ipareplica-install.log:*
>
> 2017-06-11T05:24:24Z DEBUG stderr=
> 2017-06-11T05:24:24Z DEBUG wait_for_open_ports: localhost [389]
> timeout 300
> 2017-06-11T05:24:24Z DEBUG Fetching nsDS5ReplicaId from master
> [attempt 1/5]
> 2017-06-11T05:24:24Z DEBUG flushing
> lda

[Freeipa-users] Re: Replication failing on some records

[Mark Reynolds via FreeIPA-users]

On 06/12/2017 07:32 AM, Nick Campion via FreeIPA-users wrote:
>
> Thanks Mark,
>
> So this example is a user password change using kinit, the password
> has been changed on freeipa02 but not then replicated to the others.
> This happens for other records, but I don't have examples of these at
> the moment.
>
> As far as I'm aware, there is no fractal replication set up.
>
IPA uses fractional replication, and it's possible these attributes are
ignored/skipped.  To confirm you can run this search on freeipa02:

ldapsearch -D "cn=directory manager" -W -b cn=config -xLLL
objectclass=nsds5ReplicationAgreement

Then please share these entries so we can see how they are configured. 
Perhaps do this on freeipa01 as well for comparison.
>
> Freeipa01:
>
> # dynamic-kepler, users, accounts, ipa.example.com
> dn: uid=dynamic-kepler,cn=users,cn=accounts,dc=ipa,dc=example,dc=com
> uid: dynamic-kepler
> krbLastPwdChange: 20170608170011Z
> krbPasswordExpiration: 20170608170011Z
>
> Freeipa02:
>
> # dynamic-kepler, users, accounts, ipa.example.com
> dn: uid=dynamic-kepler,cn=users,cn=accounts,dc=ipa,dc=example,dc=com
> uid: dynamic-kepler
> krbLastPwdChange: 20170608170021Z
> krbPasswordExpiration: 20170906170021Z
>
> Freeipa03:
>
> # dynamic-kepler, users, accounts, ipa.example.com
> dn: uid=dynamic-kepler,cn=users,cn=accounts,dc=ipa,dc=example,dc=com
> uid: dynamic-kepler
> krbLastPwdChange: 20170608170011Z
> krbPasswordExpiration: 20170608170011Z
>
> Errors on Freeipa02:
>
> [08/Jun/2017:01:46:50.635529447 +] replica_generate_next_csn:
> opcsn=5938ac8b00050003 <= basecsn=5938ac8b00050004, adjusted
> opcsn=5938ac8b00060003
> [08/Jun/2017:12:16:46.497249649 +] replica_generate_next_csn:
> opcsn=5939402f00050003 <= basecsn=5939402f00080004, adjusted
> opcsn=5939402f00090003
> [08/Jun/2017:23:38:48.197750001 +] replica_generate_next_csn:
> opcsn=5939e00900010003 <= basecsn=5939e009000f0004, adjusted
> opcsn=5939e0090013
>
> The other nodes have no errors from this data.
>
> Access logs:
>
> Freeipa01:
>
> [08/Jun/2017:01:46:50.635529447 +] replica_generate_next_csn:
> opcsn=5938ac8b00050003 <= basecsn=5938ac8b00050004, adjusted
> opcsn=5938ac8b00060003
> [08/Jun/2017:12:16:46.497249649 +] replica_generate_next_csn:
> opcsn=5939402f00050003 <= basecsn=5939402f00080004, adjusted
> opcsn=5939402f00090003
> [08/Jun/2017:23:38:48.197750001 +] replica_generate_next_csn:
> opcsn=5939e00900010003 <= basecsn=5939e009000f0004, adjusted
> opcsn=5939e0090013
>
This is from an error log :-)
>
> Freeipa02:
>
> Shows no logs "to" the other 2 nodes.
>
Well it would only show incoming connections, not outgoing. 
>
> Freeipa03:
>
> [08/Jun/2017:17:10:06.343697044 +] conn=9237 fd=70 slot=70
> connection from 192.168.0.12 to 192.168.0.13
> [08/Jun/2017:19:54:05.025713675 +] conn=9665 fd=70 slot=70
> connection from 192.168.0.12 to 192.168.0.13
>
> Freeipa02 replication logging:
>
> [09/Jun/2017:11:24:58.827281135 +] NSMMReplicationPlugin -
> csnplCommitALL: processing data csn 593964af00090003
>
> Repeats 800 - 900 time per second with a different csn.
>
It looks like its replicating to other replicas, but some updates are
skipped.  This again could be fractional replication "working".  

If you look through freeipa01's access log what operation is this csn
from:   5937cccd000f0003 ?   Could this be one of the password
updates that is not replicated?  This update is not sent to the other
replicas that's why I'm asking.

Thanks,
Mark
>
> On 08/06/17 15:45, Mark Reynolds wrote:
>>
>>
>> On 06/07/2017 10:58 AM, Nick Campion via FreeIPA-users wrote:
>>>
>>> Hi all,
>>>
>>>  
>>>
>>> We have a 3 master setup that is failing to replicate changes from a
>>> particular node to the other IPA instances. The replication status
>>> says it's all fine, however the record hasn't been changed on the
>>> other servers. We've seen this on user password changes, adding
>>> hosts and services. The only thing we've found that seems to fix
>>> this temporarily is to re-initialize from the master with the
>>> changed record. A force-sync doesn't pick up the changed record.
>>>
>> What is the change you making, what attribute are you updating? 
>> Could it be possible that its being excluded by fractional
>> replication?  Or is it all changes?
>>
>> Any errors in the logs on the nodes(good and bad): 
>> /var/log/dirsrv/slapd-INSTANCE/errors
>>
>> Do you see replication sessions starting between the bad node and
>> good ones?  Are they talking?  Check the access log (
>> /var/log/dirsrv/slapd-INSTANCE/access) on a good node and look for
>> "connection from "
>>
>> Next would be to enable replication logging on the bad node and
>> reproduce the problem (then disable repl logging right away), then
>> send us the logs to look at.  See 
>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing

[Freeipa-users] Re: Replication failing on some records

[Mark Reynolds via FreeIPA-users]

On 06/07/2017 10:58 AM, Nick Campion via FreeIPA-users wrote:
>
> Hi all,
>
>  
>
> We have a 3 master setup that is failing to replicate changes from a
> particular node to the other IPA instances. The replication status
> says it's all fine, however the record hasn't been changed on the
> other servers. We've seen this on user password changes, adding hosts
> and services. The only thing we've found that seems to fix this
> temporarily is to re-initialize from the master with the changed
> record. A force-sync doesn't pick up the changed record.
>
What is the change you making, what attribute are you updating?  Could
it be possible that its being excluded by fractional replication?  Or is
it all changes?

Any errors in the logs on the nodes(good and bad): 
/var/log/dirsrv/slapd-INSTANCE/errors

Do you see replication sessions starting between the bad node and good
ones?  Are they talking?  Check the access log (
/var/log/dirsrv/slapd-INSTANCE/access) on a good node and look for
"connection from "

Next would be to enable replication logging on the bad node and
reproduce the problem (then disable repl logging right away), then send
us the logs to look at.  See 
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-troubleshooting_replication_related_problems

Regards,
Mark

> Not sure what logs would be helpful to diagnose what is happening in
> this setup. 
>
> # ipa-replica-manage -v list `hostname`
> freeipa03.mgmt.example.com: replica
> last init status: None
> last init ended: 1970-01-01 00:00:00+00:00
> last update status: Error (0) Replica acquired successfully:
> Incremental update succeeded
> last update ended: 2017-06-07 14:43:53+00:00
> freeipa02.mgmt.example.com: replica
> last init status: None
> last init ended: 1970-01-01 00:00:00+00:00
> last update status: Error (0) Replica acquired successfully:
> Incremental update succeeded
> last update ended: 2017-06-07 14:43:53+00:00
>
> # ldapsearch -W -x -D "cn=directory manager" -b
> "cn=users,cn=accounts,dc=ipa,dc=example,dc=com" "nsds5ReplConflict=*"
> \* nsds5ReplConflict
> Enter LDAP Password:
> # extended LDIF
> #
> # LDAPv3
> # base  with scope subtree
> # filter: nsds5ReplConflict=*
> # requesting: * nsds5ReplConflict
> #
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 1
>
> Any help in what else can be checked or what logs would be helpful
> would be appreciated.
>
> Thanks
>
> Nick
>
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org