[Freeipa-users] Re: Error issuing cert with IP address in SAN
On 5/12/21 4:06 PM, Ian Pilcher wrote: I am getting an odd error when trying to issue a certificate with an IP address in its SAN. I am using IPA 4.6.8 on RHEL 7.9, so it's a bit old, but it should work, AFAIK. This was a user error. I had the wrong object type for the IP address in the SAN in the CSR. Certificate Request: Data: Version: 0 (0x0) Subject: CN=node01-idrac.pemlab.rdu2.redhat.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: ⋮ Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Subject Alternative Name: DNS:node01-idrac.pemlab.rdu2.redhat.com, DNS:node01-idrac, DNS:10.11.173.11 ^^^ It needs to be IP:10.11.173.11. -- Ian Pilcher arequip...@gmail.com "I grew up before Mark Zuckerberg invented friendship" ___ 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] Error issuing cert with IP address in SAN
I am getting an odd error when trying to issue a certificate with an IP address in its SAN. I am using IPA 4.6.8 on RHEL 7.9, so it's a bit old, but it should work, AFAIK. Here is the host for which I want to issue the certificate: $ ipa host-show node01-idrac.pemlab.rdu2.redhat.com Host name: node01-idrac.pemlab.rdu2.redhat.com Principal name: host/node01-idrac.pemlab.rdu2.redhat@pemlab.rdu2.redhat.com Principal alias: host/node01-idrac.pemlab.rdu2.redhat@pemlab.rdu2.redhat.com Password: False Keytab: False Managed by: node01-idrac.pemlab.rdu2.redhat.com Here is the CSR: $ openssl req -noout -text -in node01-idrac.csr Certificate Request: Data: Version: 0 (0x0) Subject: CN=node01-idrac.pemlab.rdu2.redhat.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: ⋮ Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Subject Alternative Name: DNS:node01-idrac.pemlab.rdu2.redhat.com, DNS:node01-idrac, DNS:10.11.173.11 Signature Algorithm: sha256WithRSAEncryption ⋮ The DNS records: $ ipa dnsrecord-show pemlab.rdu2.redhat.com node01-idrac Record name: node01-idrac A record: 10.11.173.11 $ ipa dnsrecord-show 173.11.10.in-addr.arpa 11 Record name: 11 PTR record: node01-idrac.pemlab.rdu2.redhat.com. $ ipa cert-request node01-idrac.csr --certificate-out node01-idrac.crt \ --principal host/node01-idrac.pemlab.rdu2.redhat@pemlab.rdu2.redhat.com ipa: ERROR: The service principal for subject alt name 10.11.173.11 in certificate request does not exist From my examination of ipaserver/plugins/cert.py, I don't think that this has anything to do with validation of the IP address, as the exception seem to be raised before _validate_san_ips ever gets called. Beyond that, however, I really don't know what's going on. I've filed this as https://bugzilla.redhat.com/show_bug.cgi?id=1960041, but I was wondering if anyone on this list has seen this behavior or can spot an error that I'm making. Thanks! -- In Soviet Russia, Google searches you! ___ 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: dirsrv hangs soon after reboot
On 12-05-2021 19:44, Thierry Bordaz wrote:
On 5/12/21 4:55 PM, Kees Bakker wrote:
Hi Thierry,
Just to be clear, changelogmaxage was changed to -1 by me after the
upgrade and I've
confirmed it is now set to -1.
The reason for me to change the value was because of the deadlock.
Apparently, it did not make much of a difference. It still gets into a
deadlock
with the value -1.
Did you set nsslapd-changelogmaxage=-1 in the retroCL config entry ?
I've used this input file for ldapmodify
[root@linge ~]# cat change-nsslapd-changelogmaxage.txt
dn: cn=Retro Changelog Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-changelogmaxage
nsslapd-changelogmaxage: -1
After that
[root@linge ~]# ldapsearch -H ldapi://%2fvar%2frun%2fslapd-GHS-NL.socket -LLL
-o ldif-wrap=no -b 'cn=Retro Changelog Plugin,cn=plugins,cn=config'
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=Retro Changelog Plugin,cn=plugins,cn=config
cn: Retro Changelog Plugin
nsslapd-attribute: nsuniqueid:targetUniqueId
nsslapd-changelogmaxage: -1
nsslapd-include-suffix: cn=dns,dc=ghs,dc=nl
nsslapd-plugin-depends-on-named: Class of Service
nsslapd-plugin-depends-on-type: database
nsslapd-pluginDescription: Retrocl Plugin
nsslapd-pluginEnabled: on
nsslapd-pluginId: retrocl
nsslapd-pluginInitfunc: retrocl_plugin_init
nsslapd-pluginPath: libretrocl-plugin
nsslapd-pluginType: object
nsslapd-pluginVendor: 389 Project
nsslapd-pluginVersion: 1.3.10.2
nsslapd-pluginbetxn: on
nsslapd-pluginprecedence: 25
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
BTW. I've sent the whole stacktrace directly to you to avoid the 4000+
lines to
this mailing list.
Here is the stack trace of one of the threads. The one that hangs in
trim_changelog
Something weird is that the same hang occurs
https://bugzilla.redhat.com/show_bug.cgi?id=1751295.
If I am correct it is between thread 14th and 2nd.
As you are running with a fixed version (> slapi-nis-0.56.5), that means
the fix is incomplete. It would require to debug a dump core to know why
the fix fails.
[root@linge ~]# rpm -qa slapi\*
slapi-nis-0.56.5-3.el7_9.x86_64
So, that is not > 0.56.5, but it is the newest available for CentOS7. No?
At the moment I killed it and restarted. No deadlock yet, but the system is
extreemly
slow. And there is just ns-slapd using CPU cycles.
regards
thierry
Thread 2 (Thread 0x7f96ede68700 (LWP 2151)):
#0 0x7f96eaf3939e in pthread_rwlock_wrlock () at
/lib64/libpthread.so.0
#1 0x7f96da9d281f in map_wrlock () at
/usr/lib64/dirsrv/plugins/schemacompat-plugin.so
#2 0x7f96da9c1e58 in backend_shr_delete_cb.part.5 () at
/usr/lib64/dirsrv/plugins/schemacompat-plugin.so
#3 0x7f96da9c1fd1 in backend_shr_betxn_post_delete_cb () at
/usr/lib64/dirsrv/plugins/schemacompat-plugin.so
#4 0x7f96ed7ec688 in plugin_call_func (list=0x55cb03cdd8c0,
operation=operation@entry=563, pb=pb@entry=0x55cb4c670fc0,
call_one=call_one@entry=0) at ldap/servers/slapd/plugin.c:2028
n =
func = 0x7f96da9c1f70
rc =
return_value = 0
count = 2
#5 0x7f96ed7ec943 in plugin_call_list (pb=0x55cb4c670fc0,
operation=563, list=) at ldap/servers/slapd/plugin.c:1972
p = 0x55cb03cb
locked =
plugin_list_number = 21
rc = 0
do_op =
#6 0x7f96ed7ec943 in plugin_call_plugins
(pb=pb@entry=0x55cb4c670fc0, whichfunction=whichfunction@entry=563) at
ldap/servers/slapd/plugin.c:442
p = 0x55cb03cb
locked =
plugin_list_number = 21
rc = 0
do_op =
#7 0x7f96dc990def in ldbm_back_delete (pb=0x55cb4c670fc0) at
ldap/servers/slapd/back-ldbm/ldbm_delete.c:1267
be = 0x55cb03c31040
inst = 0x55cb03a8c680
li = 0x55cb03a017c0
e = 0x55cb15499a40
tombstone = 0x0
original_tombstone = 0x0
tmptombstone = 0x0
dn = 0x55cb1742a600 "changenumber=891343,cn=changelog"
txn = {back_txn_txn = 0x55cb2b7b6dc0}
parent_txn = 0x0
retval = 0
msg =
errbuf = 0x0
retry_count =
disk_full = 0
parent_found =
ruv_c_init = 0
parent_modify_c = {old_entry = 0x55cb159982a0, new_entry =
0x55cb19e03030, smods = 0x55cb47da1ae0, attr_encrypt = 1}
ruv_c = {old_entry = 0x0, new_entry = 0x0, smods = 0x0,
attr_encrypt = 0}
rc = 0
ldap_result_code = 0
ldap_result_message = 0x0
sdnp = 0x55cb5fd93bc0
e_uniqueid = 0x0
nscpEntrySDN = {flag = 0 '\000', udn = 0x0, dn = 0x0, ndn =
0x0, ndn_len = 0}
operation = 0x55cb5ef86000
opcsn = 0x0
is_fixup_operation = 0
is_ruv = 0
is_replicated_operation = 0
is_tombstone_entry =
delete_tombstone_entry = 0
create_tombstone_entry = 0
addr = 0x55cb5ef86100
addordel_flags = 38
[Freeipa-users] Re: dirsrv hangs soon after reboot
On 5/12/21 4:55 PM, Kees Bakker wrote:
Hi Thierry,
Just to be clear, changelogmaxage was changed to -1 by me after the
upgrade and I've
confirmed it is now set to -1.
The reason for me to change the value was because of the deadlock.
Apparently, it did not make much of a difference. It still gets into a
deadlock
with the value -1.
Did you set nsslapd-changelogmaxage=-1 in the retroCL config entry ?
BTW. I've sent the whole stacktrace directly to you to avoid the 4000+
lines to
this mailing list.
Here is the stack trace of one of the threads. The one that hangs in
trim_changelog
Something weird is that the same hang occurs
https://bugzilla.redhat.com/show_bug.cgi?id=1751295.
If I am correct it is between thread 14th and 2nd.
As you are running with a fixed version (> slapi-nis-0.56.5), that means
the fix is incomplete. It would require to debug a dump core to know why
the fix fails.
regards
thierry
Thread 2 (Thread 0x7f96ede68700 (LWP 2151)):
#0 0x7f96eaf3939e in pthread_rwlock_wrlock () at
/lib64/libpthread.so.0
#1 0x7f96da9d281f in map_wrlock () at
/usr/lib64/dirsrv/plugins/schemacompat-plugin.so
#2 0x7f96da9c1e58 in backend_shr_delete_cb.part.5 () at
/usr/lib64/dirsrv/plugins/schemacompat-plugin.so
#3 0x7f96da9c1fd1 in backend_shr_betxn_post_delete_cb () at
/usr/lib64/dirsrv/plugins/schemacompat-plugin.so
#4 0x7f96ed7ec688 in plugin_call_func (list=0x55cb03cdd8c0,
operation=operation@entry=563, pb=pb@entry=0x55cb4c670fc0,
call_one=call_one@entry=0) at ldap/servers/slapd/plugin.c:2028
n =
func = 0x7f96da9c1f70
rc =
return_value = 0
count = 2
#5 0x7f96ed7ec943 in plugin_call_list (pb=0x55cb4c670fc0,
operation=563, list=) at ldap/servers/slapd/plugin.c:1972
p = 0x55cb03cb
locked =
plugin_list_number = 21
rc = 0
do_op =
#6 0x7f96ed7ec943 in plugin_call_plugins
(pb=pb@entry=0x55cb4c670fc0, whichfunction=whichfunction@entry=563) at
ldap/servers/slapd/plugin.c:442
p = 0x55cb03cb
locked =
plugin_list_number = 21
rc = 0
do_op =
#7 0x7f96dc990def in ldbm_back_delete (pb=0x55cb4c670fc0) at
ldap/servers/slapd/back-ldbm/ldbm_delete.c:1267
be = 0x55cb03c31040
inst = 0x55cb03a8c680
li = 0x55cb03a017c0
e = 0x55cb15499a40
tombstone = 0x0
original_tombstone = 0x0
tmptombstone = 0x0
dn = 0x55cb1742a600 "changenumber=891343,cn=changelog"
txn = {back_txn_txn = 0x55cb2b7b6dc0}
parent_txn = 0x0
retval = 0
msg =
errbuf = 0x0
retry_count =
disk_full = 0
parent_found =
ruv_c_init = 0
parent_modify_c = {old_entry = 0x55cb159982a0, new_entry =
0x55cb19e03030, smods = 0x55cb47da1ae0, attr_encrypt = 1}
ruv_c = {old_entry = 0x0, new_entry = 0x0, smods = 0x0,
attr_encrypt = 0}
rc = 0
ldap_result_code = 0
ldap_result_message = 0x0
sdnp = 0x55cb5fd93bc0
e_uniqueid = 0x0
nscpEntrySDN = {flag = 0 '\000', udn = 0x0, dn = 0x0, ndn =
0x0, ndn_len = 0}
operation = 0x55cb5ef86000
opcsn = 0x0
is_fixup_operation = 0
is_ruv = 0
is_replicated_operation = 0
is_tombstone_entry =
delete_tombstone_entry = 0
create_tombstone_entry = 0
addr = 0x55cb5ef86100
addordel_flags = 38
entryusn_str = 0x0
orig_entry = 0x0
parentsdn = {flag = 2 '\002', udn = 0x0, dn = 0x55cb516c3580
"cn=changelog", ndn = 0x0, ndn_len = 12}
opreturn = 0
free_delete_existing_entry = 1
not_an_error = 0
parent_switched = 0
myrc = 0
conn_id = 0
tombstone_csn =
deletion_csn_str =
"\247\001\000\000\000\000\000\000\000T\334YHi\365\357\300\017g",
op_id = 0
ep_id =
tomb_ep_id = 0
result_sent = 0
pb_conn = 0x0
parent_op = 1
parent_time = {tv_sec = 183860, tv_nsec = 41743941}
#8 0x7f96ed79d3bb in op_shared_delete
(pb=pb@entry=0x55cb4c670fc0) at ldap/servers/slapd/delete.c:324
rc = 0
rawdn = 0x55cb5b28de00 "changenumber=891343, cn=changelog"
dn =
be = 0x55cb03c31040
internal_op = 32
sdn = 0x55cb5fd93bc0
operation = 0x55cb5ef86000
referral = 0x0
ecopy = 0x0
errorbuf = "\000\066\062\062Z\nmodifyTime", '\000' times>, "\071\063\066\062\062Z\nnsUniqueI", '\000' ,
[Freeipa-users] Re: kinit: Cannot find KDC for realm "mgmt-062-ad.internal2.example....@nternal2.example.com" while getting initial credentials
Am Wed, May 12, 2021 at 02:18:07PM - schrieb pxg51214 r via FreeIPA-users: > - thank you very much. I will provide your feedback to our devops team. > - to answer your question: we have a legacy AD to FreeIPA (identity > synchronization tool) which runs automatically on daily basis and uses > a keytab file for authN. the developer of the tool is no longer with Hi, ok, then a principal like 'l...@internal2.example.com' (same as the mapped user name) should work. bye, Sumit > the company and our management wants the synchronization to be > reconstituted using this tool. > Regards, > -Chris > ___ > 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 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: dirsrv hangs soon after reboot
Hi Thierry,
Just to be clear, changelogmaxage was changed to -1 by me after the upgrade and
I've
confirmed it is now set to -1.
The reason for me to change the value was because of the deadlock.
Apparently, it did not make much of a difference. It still gets into a deadlock
with the value -1.
BTW. I've sent the whole stacktrace directly to you to avoid the 4000+ lines to
this mailing list.
Here is the stack trace of one of the threads. The one that hangs in
trim_changelog
Thread 2 (Thread 0x7f96ede68700 (LWP 2151)):
#0 0x7f96eaf3939e in pthread_rwlock_wrlock () at /lib64/libpthread.so.0
#1 0x7f96da9d281f in map_wrlock () at
/usr/lib64/dirsrv/plugins/schemacompat-plugin.so
#2 0x7f96da9c1e58 in backend_shr_delete_cb.part.5 () at
/usr/lib64/dirsrv/plugins/schemacompat-plugin.so
#3 0x7f96da9c1fd1 in backend_shr_betxn_post_delete_cb () at
/usr/lib64/dirsrv/plugins/schemacompat-plugin.so
#4 0x7f96ed7ec688 in plugin_call_func (list=0x55cb03cdd8c0,
operation=operation@entry=563, pb=pb@entry=0x55cb4c670fc0,
call_one=call_one@entry=0) at ldap/servers/slapd/plugin.c:2028
n =
func = 0x7f96da9c1f70
rc =
return_value = 0
count = 2
#5 0x7f96ed7ec943 in plugin_call_list (pb=0x55cb4c670fc0, operation=563,
list=) at ldap/servers/slapd/plugin.c:1972
p = 0x55cb03cb
locked =
plugin_list_number = 21
rc = 0
do_op =
#6 0x7f96ed7ec943 in plugin_call_plugins (pb=pb@entry=0x55cb4c670fc0,
whichfunction=whichfunction@entry=563) at ldap/servers/slapd/plugin.c:442
p = 0x55cb03cb
locked =
plugin_list_number = 21
rc = 0
do_op =
#7 0x7f96dc990def in ldbm_back_delete (pb=0x55cb4c670fc0) at
ldap/servers/slapd/back-ldbm/ldbm_delete.c:1267
be = 0x55cb03c31040
inst = 0x55cb03a8c680
li = 0x55cb03a017c0
e = 0x55cb15499a40
tombstone = 0x0
original_tombstone = 0x0
tmptombstone = 0x0
dn = 0x55cb1742a600 "changenumber=891343,cn=changelog"
txn = {back_txn_txn = 0x55cb2b7b6dc0}
parent_txn = 0x0
retval = 0
msg =
errbuf = 0x0
retry_count =
disk_full = 0
parent_found =
ruv_c_init = 0
parent_modify_c = {old_entry = 0x55cb159982a0, new_entry =
0x55cb19e03030, smods = 0x55cb47da1ae0, attr_encrypt = 1}
ruv_c = {old_entry = 0x0, new_entry = 0x0, smods = 0x0, attr_encrypt =
0}
rc = 0
ldap_result_code = 0
ldap_result_message = 0x0
sdnp = 0x55cb5fd93bc0
e_uniqueid = 0x0
nscpEntrySDN = {flag = 0 '\000', udn = 0x0, dn = 0x0, ndn = 0x0,
ndn_len = 0}
operation = 0x55cb5ef86000
opcsn = 0x0
is_fixup_operation = 0
is_ruv = 0
is_replicated_operation = 0
is_tombstone_entry =
delete_tombstone_entry = 0
create_tombstone_entry = 0
addr = 0x55cb5ef86100
addordel_flags = 38
entryusn_str = 0x0
orig_entry = 0x0
parentsdn = {flag = 2 '\002', udn = 0x0, dn = 0x55cb516c3580
"cn=changelog", ndn = 0x0, ndn_len = 12}
opreturn = 0
free_delete_existing_entry = 1
not_an_error = 0
parent_switched = 0
myrc = 0
conn_id = 0
tombstone_csn =
deletion_csn_str =
"\247\001\000\000\000\000\000\000\000T\334YHi\365\357\300\017g",
op_id = 0
ep_id =
tomb_ep_id = 0
result_sent = 0
pb_conn = 0x0
parent_op = 1
parent_time = {tv_sec = 183860, tv_nsec = 41743941}
#8 0x7f96ed79d3bb in op_shared_delete (pb=pb@entry=0x55cb4c670fc0) at
ldap/servers/slapd/delete.c:324
rc = 0
rawdn = 0x55cb5b28de00 "changenumber=891343, cn=changelog"
dn =
be = 0x55cb03c31040
internal_op = 32
sdn = 0x55cb5fd93bc0
operation = 0x55cb5ef86000
referral = 0x0
ecopy = 0x0
errorbuf = "\000\066\062\062Z\nmodifyTime", '\000' ,
"\071\063\066\062\062Z\nnsUniqueI", '\000' ,
"\327\320~\003ڇ\316c!\f=\037$z\215\301;\215\006\065\341\n\310V\300\006\365I\344|x\210\216\f\215\060e\243S\350\000T\334YHi\365\357\016\237V\202\332PG\347\300\070\314\003\313U\000\000\300\070\314\003\313U\000\000\000T\334YHi\365\357\000\000\000\000\000\000\000\000\300\070\314\003\313U\000\000\300\070\314\003\313U\000\000\240<\250\355\226\177\000\000\000\243\002\000\000\000\000\000p|\346\355\226\177\000\000ϙ\r\000\000\000\000\000\312\360"...
err =
proxydn = 0x0
proxystr = 0x0
proxy_err =
errtext = 0x0
#9 0x7f96ed79d598 in delete_internal_pb (pb=pb@entry=0x55cb4c670fc0) at
ldap/servers/slapd/delete.c:208
controls = 0x0
op = 0x55cb5ef86000
opresult = 0
#10 0x7f96ed79d813 in slapi_delete_internal_pb (pb=pb@entry=0x55cb4c670fc0)
at ldap/servers/slapd/delete.c:151
#11 0x7f96daff731e in
[Freeipa-users] Re: kinit: Cannot find KDC for realm "mgmt-062-ad.internal2.example....@nternal2.example.com" while getting initial credentials
- thank you very much. I will provide your feedback to our devops team. - to answer your question: we have a legacy AD to FreeIPA (identity synchronization tool) which runs automatically on daily basis and uses a keytab file for authN. the developer of the tool is no longer with the company and our management wants the synchronization to be reconstituted using this tool. Regards, -Chris ___ 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: dirsrv hangs soon after reboot
Hi Kees, Is changelogmaxage=-1 after the upgrade ? would you send a full pstack when it hangs ? If pthread_rwlock_wrlock is trim_changelog then you may hit another flavor of [1] (without known reason). regards thierry On 5/12/21 2:40 PM, Kees Bakker wrote: Sorry to revive an old thread. I'm getting deadlocks again. See below On 20-04-2020 15:16, thierry bordaz wrote: [...]This is a known bug [1]. With the same bug there are two deadlock scenario but only one is fixed (for example in slapi-nis-0.56.4-1 [2]). A fix for the second one is under tests. At the moment I would recommend the workaround [3]. The drawback is a growth of the retroCL database but unless you have a very high rate of update it should not be a concern. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1751295 [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1457771 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1751295#c5 best regards thierry I followed the recommendation to set nsslapd-changelogmaxage to -1. The system has been running successfully for a year. Recently I upgraded all packages in this CentOS7 system. Ever since that moment the server is quite unusable. [root@linge ~]# gdb -ex 'set confirm off' -ex 'set pagination off' -ex 'thread apply all bt full' -ex 'quit' /usr/sbin/ns-slapd `pidof ns-slapd` |& grep '^#0.*lock' #0 0x7f96eaf3939e in pthread_rwlock_wrlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf3939e in pthread_rwlock_wrlock () at /lib64/libpthread.so.0 [root@linge ~]# rpm -qa 389\* 389-ds-base-libs-1.3.10.2-10.el7_9.x86_64 389-ds-base-1.3.10.2-10.el7_9.x86_64 389-ds-base-debuginfo-1.3.10.2-10.el7_9.x86_64 [root@linge ~]# rpm -qa slapi\* slapi-nis-0.56.5-3.el7_9.x86_64 [root@linge ~]# rpm -qa centos-release centos-release-7-9.2009.1.el7.centos.x86_64 Are there any new hints to avoid the deadlock? ___ 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: dirsrv hangs soon after reboot
Sorry to revive an old thread. I'm getting deadlocks again. See below On 20-04-2020 15:16, thierry bordaz wrote: [...]This is a known bug [1]. With the same bug there are two deadlock scenario but only one is fixed (for example in slapi-nis-0.56.4-1 [2]). A fix for the second one is under tests. At the moment I would recommend the workaround [3]. The drawback is a growth of the retroCL database but unless you have a very high rate of update it should not be a concern. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1751295 [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1457771 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1751295#c5 best regards thierry I followed the recommendation to set nsslapd-changelogmaxage to -1. The system has been running successfully for a year. Recently I upgraded all packages in this CentOS7 system. Ever since that moment the server is quite unusable. [root@linge ~]# gdb -ex 'set confirm off' -ex 'set pagination off' -ex 'thread apply all bt full' -ex 'quit' /usr/sbin/ns-slapd `pidof ns-slapd` |& grep '^#0.*lock' #0 0x7f96eaf3939e in pthread_rwlock_wrlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf39184 in pthread_rwlock_rdlock () at /lib64/libpthread.so.0 #0 0x7f96eaf3939e in pthread_rwlock_wrlock () at /lib64/libpthread.so.0 [root@linge ~]# rpm -qa 389\* 389-ds-base-libs-1.3.10.2-10.el7_9.x86_64 389-ds-base-1.3.10.2-10.el7_9.x86_64 389-ds-base-debuginfo-1.3.10.2-10.el7_9.x86_64 [root@linge ~]# rpm -qa slapi\* slapi-nis-0.56.5-3.el7_9.x86_64 [root@linge ~]# rpm -qa centos-release centos-release-7-9.2009.1.el7.centos.x86_64 Are there any new hints to avoid the deadlock? -- Kees ___ 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] sudorule not working for external user
Using freeipa from RHEL8.1, I try to create sudo rules (from the GUI). * "foo" and "bar" are ipa users * "ext" is a local user present on all machines The rule allow user "foo" to run "/bin/bash" on any host as user "bar" works fine, i.e. I can log in as "foo" and run # su - foo $ sudo -u bar /bin/bash -> OK However, if I create a similar rule for the external user it does not work allow external user "ext" to run "/bin/bash" on any host as user "bar" => # su - ext $ sudo -u bar /bin/bash -> denied -- $ ipa sudorule-show test Rule name: test Enabled: TRUE Host category: all External User: ext Sudo Allow Commands: /bin/bash RuaAs Users: bar What am I doing wrong? Ciao Dominik ^_^ ^_^ -- Dominik Vogt ___ 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: ID views/override issues for AD trust
> Am Wed, May 12, 2021 at 06:46:29AM - schrieb iulian roman via > FreeIPA-users: > > Hi, > > did you use the IPA 'unix_users' group as primary group for those users > and given the GID of 'unix_users' in the id-overrides for the users? Or > did you you a different group as primary group? > No, unix_users is not primary group. The primary group is the one from AD (gidNumber) which is overridden in the view. > bye, > Sumit ___ 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: ID views/override issues for AD trust
Am Wed, May 12, 2021 at 06:46:29AM - schrieb iulian roman via FreeIPA-users: > > Am Tue, May 11, 2021 at 03:09:54PM - schrieb iulian roman via > > FreeIPA-users: > > > > Hi, > > > > can you give some more details about the group, where it comes from IPA > > or AD, and the GID, it is the original GID of the group or coming from > > an id-override as well? > > > Hi, > > There is trust between IPA and AD (non-posix trust) . All AD users > which have a uidNumber and gidNumber configured in AD have been added > in 'Default Trust View' and idoverride configured for them (the uid > and gid override is the same like the one in AD). > The same AD users which are configured above are as well part of IPA > posix groups via group membership (ex. ad_unix_users is member of ipa > unix_users group) in order to configure sudo rules for them. > On the ipa servers and replicas i can query/list attributes for all > users, on ipa clients i can list users (via id command) > for which uid/gid is overridden _only_ after i manually run getent > group . For the users which do not have uid and gid > overriden it works correctly. > > I do not know if explanation is clear, but if you need more > information, please let me know. Hi, did you use the IPA 'unix_users' group as primary group for those users and given the GID of 'unix_users' in the id-overrides for the users? Or did you you a different group as primary group? bye, Sumit > > > bye, > > Sumit > ___ > 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 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 Upgrade F31 -> F32: usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock
Hi, this is a known selinux-policy issue, tracked at https://bugzilla.redhat.com/show_bug.cgi?id=1894132 flo On Mon, May 10, 2021 at 9:42 PM Harry G. Coin via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote: > > On 5/10/21 10:58 AM, Harry Coin via FreeIPA-users wrote: > > In a completely fresh install of freeipa-server, f34, my logs are filled > with > > > > certmonger[5754]: usr/lib/api/apiutil.c Could not open > /run/lock/opencryptoki/LCK..APIlock > > I get similar messages from certutil, certmonger and pk12util > > May 10 14:31:21 registry1.1.quietfountain.com certutil[18672]: > usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock > May 10 14:31:22 registry1.1.quietfountain.com certutil[18674]: > usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock > May 10 14:31:23 registry1.1.quietfountain.com certutil[18676]: > usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock > May 10 14:31:25 registry1.1.quietfountain.com certutil[18678]: > usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock > May 10 14:31:25 registry1.1.quietfountain.com certutil[18680]: > usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock > May 10 14:31:26 registry1.1.quietfountain.com certutil[18682]: > usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock > May 10 14:31:27 registry1.1.quietfountain.com certutil[18684]: > usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock > May 10 14:31:28 registry1.1.quietfountain.com pk12util[18686]: > usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock > May 10 14:31:32 registry1.1.quietfountain.com certutil[18688]: > usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock > May 10 14:31:35 registry1.1.quietfountain.com pk12util[18700]: > usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock > ___ > 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 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: ID views/override issues for AD trust
> Am Tue, May 11, 2021 at 03:09:54PM - schrieb iulian roman via > FreeIPA-users: > > Hi, > > can you give some more details about the group, where it comes from IPA > or AD, and the GID, it is the original GID of the group or coming from > an id-override as well? > Hi, There is trust between IPA and AD (non-posix trust) . All AD users which have a uidNumber and gidNumber configured in AD have been added in 'Default Trust View' and idoverride configured for them (the uid and gid override is the same like the one in AD). The same AD users which are configured above are as well part of IPA posix groups via group membership (ex. ad_unix_users is member of ipa unix_users group) in order to configure sudo rules for them. On the ipa servers and replicas i can query/list attributes for all users, on ipa clients i can list users (via id command) for which uid/gid is overridden _only_ after i manually run getent group . For the users which do not have uid and gid overriden it works correctly. I do not know if explanation is clear, but if you need more information, please let me know. > bye, > Sumit ___ 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
