Re: [Freeipa-users] Known issues with IPA on VM?
Running FreeIPA 4.1 on Fedora 21 on Xenserver 6.2 in HVM mode. No issues. Kind Regards, David 2015-05-06 11:15 GMT+02:00 Alexander Frolushkin alexander.frolush...@megafon.ru: Hello. We have periodically hanging and crashing dirsrv in our ipa servers. All of them running in VM on Vmware. WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 *From:* freeipa-users-boun...@redhat.com [mailto: freeipa-users-boun...@redhat.com] *On Behalf Of *Christoph Kaminski *Sent:* Wednesday, May 06, 2015 11:48 AM *To:* Freeipa-users *Subject:* [Freeipa-users] Known issues with IPA on VM? Hi we have some undefinably problems here with IPA inside a VM (rhev/kvm). We has often zombie processes (defunct) with certmonger and dirsrv and segfaults (dmesg)... We have 8 IPA servers, 4 Hardware and 4 VM's with same Install (rhel7.1). We see these problems only on the VM's. Is there something already known about such problems? (The VM's have ever 4 CPU's and 2GB RAM, we have circa 120 Users/Groups) Greetz Christoph Kaminski -- Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщение и любые возможные его копии и приложения. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Problem with replication
ldapsearch hangs. Dirsrv is not responding now. if the server is hanging, can you get a pstack Thread 45 (Thread 0x7fc6a562d700 (LWP 1868)): #0 0x7fc6b2f1aae3 in select () from /lib64/libc.so.6 #1 0x7fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 #2 0x7fc6a961f987 in deadlock_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x7fc6b3847cab in _pt_root () from /lib64/libnspr4.so #4 0x7fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #5 0x7fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 44 (Thread 0x7fc6a4e2c700 (LWP 1869)): #0 0x7fc6b2f1aae3 in select () from /lib64/libc.so.6 #1 0x7fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 #2 0x7fc6a9623a4e in checkpoint_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x7fc6b3847cab in _pt_root () from /lib64/libnspr4.so #4 0x7fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #5 0x7fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 43 (Thread 0x7fc6a462b700 (LWP 1870)): #0 0x7fc6b2f1aae3 in select () from /lib64/libc.so.6 #1 0x7fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 #2 0x7fc6a961fc0f in trickle_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x7fc6b3847cab in _pt_root () from /lib64/libnspr4.so #4 0x7fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #5 0x7fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 42 (Thread 0x7fc6a3e2a700 (LWP 1871)): #0 0x7fc6b2f1aae3 in select () from /lib64/libc.so.6 #1 0x7fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 #2 0x7fc6a961a667 in perf_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x7fc6b3847cab in _pt_root () from /lib64/libnspr4.so #4 0x7fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #5 0x7fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 41 (Thread 0x7fc6a3629700 (LWP 1900)): #0 0x7fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x7fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 #3 0x7fc6abd455be in cos_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libcos-plugin.so #4 0x7fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x7fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x7fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 40 (Thread 0x7fc6b5735700 (LWP 1901)): #0 0x7fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so #2 0x7fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so #3 0x7fc6a937be84 in _cl5TrimMain () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #4 0x7fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x7fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x7fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 39 (Thread 0x7fc6a2e28700 (LWP 1902)): #0 0x7fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x7fc6a93928d4 in protocol_sleep () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #3 0x7fc6a93949e5 in repl5_inc_run () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #4 0x7fc6a9399421 in prot_thread_main () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #5 0x7fc6b3847cab in _pt_root () from /lib64/libnspr4.so #6 0x7fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #7 0x7fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 38 (Thread 0x7fc6a2627700 (LWP 1903)): #0 0x7fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so #2 0x7fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so #3 0x7fc6a93928d4 in protocol_sleep () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #4 0x7fc6a9395158 in repl5_inc_run () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #5 0x7fc6a9399421 in prot_thread_main () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #6 0x7fc6b3847cab in _pt_root () from /lib64/libnspr4.so #7 0x7fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #8 0x7fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 37 (Thread 0x7fc6a1a04700 (LWP 1906)): #0 0x7fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x7fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 #3 0x7fc6a7cbef5d in roles_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libroles-plugin.so #4 0x7fc6b3847cab in _pt_root ()
Re: [Freeipa-users] Problem with replication
This is looking like thread 13 prevents thread 12 run (and all the others). Now thread 13 is likely waiting for db page? We may need output of db_stat (db_state -N -h /var/lib/dirsrv/slapd-xxx/db/ -CA) thanks thierry On 05/06/2015 11:31 AM, Łukasz Jaworski wrote: ldapsearch hangs. Dirsrv is not responding now. if the server is hanging, can you get a pstack Thread 45 (Thread 0x7fc6a562d700 (LWP 1868)): #0 0x7fc6b2f1aae3 in select () from /lib64/libc.so.6 #1 0x7fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 #2 0x7fc6a961f987 in deadlock_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x7fc6b3847cab in _pt_root () from /lib64/libnspr4.so #4 0x7fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #5 0x7fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 44 (Thread 0x7fc6a4e2c700 (LWP 1869)): #0 0x7fc6b2f1aae3 in select () from /lib64/libc.so.6 #1 0x7fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 #2 0x7fc6a9623a4e in checkpoint_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x7fc6b3847cab in _pt_root () from /lib64/libnspr4.so #4 0x7fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #5 0x7fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 43 (Thread 0x7fc6a462b700 (LWP 1870)): #0 0x7fc6b2f1aae3 in select () from /lib64/libc.so.6 #1 0x7fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 #2 0x7fc6a961fc0f in trickle_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x7fc6b3847cab in _pt_root () from /lib64/libnspr4.so #4 0x7fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #5 0x7fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 42 (Thread 0x7fc6a3e2a700 (LWP 1871)): #0 0x7fc6b2f1aae3 in select () from /lib64/libc.so.6 #1 0x7fc6b5492a99 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0 #2 0x7fc6a961a667 in perf_threadmain () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x7fc6b3847cab in _pt_root () from /lib64/libnspr4.so #4 0x7fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #5 0x7fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 41 (Thread 0x7fc6a3629700 (LWP 1900)): #0 0x7fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x7fc6b5482c68 in slapi_wait_condvar () from /usr/lib64/dirsrv/libslapd.so.0 #3 0x7fc6abd455be in cos_cache_wait_on_change () from /usr/lib64/dirsrv/plugins/libcos-plugin.so #4 0x7fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x7fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x7fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 40 (Thread 0x7fc6b5735700 (LWP 1901)): #0 0x7fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so #2 0x7fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so #3 0x7fc6a937be84 in _cl5TrimMain () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #4 0x7fc6b3847cab in _pt_root () from /lib64/libnspr4.so #5 0x7fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #6 0x7fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 39 (Thread 0x7fc6a2e28700 (LWP 1902)): #0 0x7fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fc6b3842440 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x7fc6a93928d4 in protocol_sleep () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #3 0x7fc6a93949e5 in repl5_inc_run () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #4 0x7fc6a9399421 in prot_thread_main () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #5 0x7fc6b3847cab in _pt_root () from /lib64/libnspr4.so #6 0x7fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #7 0x7fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 38 (Thread 0x7fc6a2627700 (LWP 1903)): #0 0x7fc6b31ed939 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fc6b3841ef8 in pt_TimedWait () from /lib64/libnspr4.so #2 0x7fc6b38423be in PR_WaitCondVar () from /lib64/libnspr4.so #3 0x7fc6a93928d4 in protocol_sleep () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #4 0x7fc6a9395158 in repl5_inc_run () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #5 0x7fc6a9399421 in prot_thread_main () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so #6 0x7fc6b3847cab in _pt_root () from /lib64/libnspr4.so #7 0x7fc6b31e852a in start_thread () from /lib64/libpthread.so.0 #8 0x7fc6b2f2422d in clone () from /lib64/libc.so.6 Thread 37 (Thread 0x7fc6a1a04700 (LWP 1906)): #0 0x7fc6b31ed590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fc6b3842440 in
Re: [Freeipa-users] Split Horizon DNS config
On 6.5.2015 10:06, Petr Spacek wrote: General advice about views is 'do not use them' :-) It is much cleaner to put internal names in a sub-domain like int.example.com. (while example.com. is the public-facing domain) and restrict access to this sub-domain using ACL. In long term it will make your life much easier when it comes to DNSSEC validation. Please see http://www.freeipa.org/page/Deployment_Recommendations#DNS for other related recommendations. I hope this helps. I tried to summarize this for future generations: http://www.freeipa.org/page/DNS#Caveats -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Problem with replication
Hi, ipactl stops working after dirsrv-stop/start. There are many changes in the changelog: from 39399 to 44397 (…) # 44393, changelog dn: changenumber=44393,cn=changelog # 44394, changelog dn: changenumber=44394,cn=changelog # 44395, changelog dn: changenumber=44395,cn=changelog # 44396, changelog dn: changenumber=44396,cn=changelog # 44397, changelog dn: changenumber=44397,cn=changelog # search result search: 2 result: 11 Administrative limit exceeded # numResponses: 5001 # numEntries: 5000 After some seconds dirsrv stops responding. In error log: [06/May/2015:11:00:04 +0200] agmt=cn=cloneAgreement1-replica09.local-pki-tomcat (replica08:389) - Can't locate CSN 55100d8c069f in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. [06/May/2015:11:00:04 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 ldapsearch hangs. Dirsrv is not responding now. This replica is on virtual machine (ganeti). We had problems with replication to vm, but after force-sync all was fine. On physical servers all works fine. Lukasz Jaworski 'Ender' Wiadomość napisana przez Ludwig Krispenz lkris...@redhat.com w dniu 6 maj 2015, o godz. 10:52: Hi, there seem to be different issues, - I don't know what the ipactl status is looking for when it generates the error message about no matching master, but I don't think it is related to the retro changelog. - the retro changelog errors for adding and deleting -- the add failures are about aborted transactions because a page cannot be accessed, this maybe caused by concurrent mods on different backends, which want to update teh shared retro cl database. the changenumber reprted seems to be increasing, one error is about changenumber 44975, the next about 45577, so it looks like changes into the changelog are written and teh changenumber increases -- i'm not sure about the delete errors, but normally trimming would go on after such an error message, the changenumber attempted to delete are increasing. Could you verify which changes are in the changelog, and if these are changing: ldapsearch -b cn=changelog dn On 05/06/2015 09:52 AM, Łukasz Jaworski wrote: Hi, One of our replica hanged up morning. Error log after dirsrv restart: [06/May/2015:09:28:15 +0200] - Retry count exceeded in delete [06/May/2015:09:28:15 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 38376 (rc: 51) [06/May/2015:09:28:15 +0200] - Operation error fetching Null DN (6368aeb7-f3c111e4-ae70ce39-9b469c1f), error -30993. [06/May/2015:09:28:15 +0200] - dn2entry_ext: Failed to get id for changenumber=44975,cn=changelog from entryrdn index (-30993) [06/May/2015:09:28:15 +0200] - Operation error fetching changenumber=44975,cn=changelog (null), error -30993. [06/May/2015:09:28:15 +0200] DSRetroclPlugin - replog: an error occured while adding change number 44975, dn = changenumber=44975,cn=changelog: Operations error. [06/May/2015:09:28:15 +0200] retrocl-plugin - retrocl_postob: operation failure [1] [06/May/2015:09:28:15 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 [06/May/2015:09:30:03 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 [06/May/2015:09:30:06 +0200] - Retry count exceeded in delete [06/May/2015:09:30:06 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39297 (rc: 51) I did re-initialize from other replica. Now ipactl doesn't work. Shows: Configured hostname 'replica09.local' does not match any master server in LDAP. On lists replica09 is exists (twice) # ipactl status Failed to get list of services to probe status! Configured hostname 'replica09.local' does not match any master server in LDAP: replica01.local replica02.local replica03.local replica04.local replica05.local replica06.local replica07.local replica08.local replica09.local replica10.local replica09.local After dirsrv stop/start: In error logs there are many: [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39290 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39291 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39292 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39293 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39294 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39295 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39296 (rc: 32) etc. [06/May/2015:09:51:08 +0200] - Operation error fetching
Re: [Freeipa-users] Known issues with IPA on VM?
Hello. We have periodically hanging and crashing dirsrv in our ipa servers. All of them running in VM on Vmware. WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Christoph Kaminski Sent: Wednesday, May 06, 2015 11:48 AM To: Freeipa-users Subject: [Freeipa-users] Known issues with IPA on VM? Hi we have some undefinably problems here with IPA inside a VM (rhev/kvm). We has often zombie processes (defunct) with certmonger and dirsrv and segfaults (dmesg)... We have 8 IPA servers, 4 Hardware and 4 VM's with same Install (rhel7.1). We see these problems only on the VM's. Is there something already known about such problems? (The VM's have ever 4 CPU's and 2GB RAM, we have circa 120 Users/Groups) Greetz Christoph Kaminski ?? ? ? ? ? ??? ?? ???, ??? ??? ??. ? ? ? ??? ??, ??? ?? ? ??? ???-, ? ?. ?? ?? ??? ? ?, ?? ?, ?, ??? ??? ??? ?? ? ??? ??? ? ? ? ?. ?? ??? ? , ??, ??? ??? ?? ? ??? ?? ?? ? ? ? ? ??? ? ? ??. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Problem with replication
On 05/06/2015 11:10 AM, Łukasz Jaworski wrote: Hi, ipactl stops working after dirsrv-stop/start. There are many changes in the changelog: from 39399 to 44397 (…) # 44393, changelog dn: changenumber=44393,cn=changelog # 44394, changelog dn: changenumber=44394,cn=changelog # 44395, changelog dn: changenumber=44395,cn=changelog # 44396, changelog dn: changenumber=44396,cn=changelog # 44397, changelog dn: changenumber=44397,cn=changelog # search result search: 2 result: 11 Administrative limit exceeded # numResponses: 5001 # numEntries: 5000 After some seconds dirsrv stops responding. In error log: [06/May/2015:11:00:04 +0200] agmt=cn=cloneAgreement1-replica09.local-pki-tomcat (replica08:389) - Can't locate CSN 55100d8c069f in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. [06/May/2015:11:00:04 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 ldapsearch hangs. Dirsrv is not responding now. if the server is hanging, can you get a pstack This replica is on virtual machine (ganeti). We had problems with replication to vm, but after force-sync all was fine. On physical servers all works fine. the messages indicate there could be many concurrent operations, because individual ops are not fast enough, could your VM have less/slower resources than the physical machines ? Lukasz Jaworski 'Ender' Wiadomość napisana przez Ludwig Krispenz lkris...@redhat.com w dniu 6 maj 2015, o godz. 10:52: Hi, there seem to be different issues, - I don't know what the ipactl status is looking for when it generates the error message about no matching master, but I don't think it is related to the retro changelog. - the retro changelog errors for adding and deleting -- the add failures are about aborted transactions because a page cannot be accessed, this maybe caused by concurrent mods on different backends, which want to update teh shared retro cl database. the changenumber reprted seems to be increasing, one error is about changenumber 44975, the next about 45577, so it looks like changes into the changelog are written and teh changenumber increases -- i'm not sure about the delete errors, but normally trimming would go on after such an error message, the changenumber attempted to delete are increasing. Could you verify which changes are in the changelog, and if these are changing: ldapsearch -b cn=changelog dn On 05/06/2015 09:52 AM, Łukasz Jaworski wrote: Hi, One of our replica hanged up morning. Error log after dirsrv restart: [06/May/2015:09:28:15 +0200] - Retry count exceeded in delete [06/May/2015:09:28:15 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 38376 (rc: 51) [06/May/2015:09:28:15 +0200] - Operation error fetching Null DN (6368aeb7-f3c111e4-ae70ce39-9b469c1f), error -30993. [06/May/2015:09:28:15 +0200] - dn2entry_ext: Failed to get id for changenumber=44975,cn=changelog from entryrdn index (-30993) [06/May/2015:09:28:15 +0200] - Operation error fetching changenumber=44975,cn=changelog (null), error -30993. [06/May/2015:09:28:15 +0200] DSRetroclPlugin - replog: an error occured while adding change number 44975, dn = changenumber=44975,cn=changelog: Operations error. [06/May/2015:09:28:15 +0200] retrocl-plugin - retrocl_postob: operation failure [1] [06/May/2015:09:28:15 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 [06/May/2015:09:30:03 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 [06/May/2015:09:30:06 +0200] - Retry count exceeded in delete [06/May/2015:09:30:06 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39297 (rc: 51) I did re-initialize from other replica. Now ipactl doesn't work. Shows: Configured hostname 'replica09.local' does not match any master server in LDAP. On lists replica09 is exists (twice) # ipactl status Failed to get list of services to probe status! Configured hostname 'replica09.local' does not match any master server in LDAP: replica01.local replica02.local replica03.local replica04.local replica05.local replica06.local replica07.local replica08.local replica09.local replica10.local replica09.local After dirsrv stop/start: In error logs there are many: [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39290 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39291 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39292 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39293 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39294 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record
Re: [Freeipa-users] Problem with replication
dbstat: MacBookPro-10DDB1EAF1CC-1522:~ ender$ cat FILE Default locking region information: 139 Last allocated locker ID 0x7fff Current maximum unused locker ID 9 Number of lock modes 200 Initial number of locks allocated 0 Initial number of lockers allocated 200 Initial number of lock objects allocated 1 Maximum number of locks possible 1 Maximum number of lockers possible 1 Maximum number of lock objects possible 312 Current number of locks allocated 151 Current number of lockers allocated 250 Current number of lock objects allocated 40 Number of lock object partitions 8191Size of object hash table 275 Number of current locks 303 Maximum number of locks at any one time 6 Maximum number of locks in any one bucket 174 Maximum number of locks stolen by for an empty partition 13 Maximum number of locks stolen for any one partition 124 Number of current lockers 124 Maximum number of lockers at any one time 223 Number of current lock objects 233 Maximum number of lock objects at any one time 3 Maximum number of lock objects in any one bucket 49 Maximum number of objects stolen by for an empty partition 5 Maximum number of objects stolen for any one partition 82905 Total number of locks requested 82018 Total number of locks released 0 Total number of locks upgraded 68 Total number of locks downgraded 8 Lock requests not available due to conflicts, for which we waited 12 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 2MB 304KB Region size 0 The number of partition locks that required waiting (0%) 0 The maximum number of times any partition lock was waited for (0%) 0 The number of object queue operations that required waiting (0%) 0 The number of locker allocations that required waiting (0%) 4 The number of region locks that required waiting (0%) 5 Maximum hash bucket length =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock REGINFO information: Environment Region type 1 Region ID /var/lib/dirsrv/slapd-/db/__db.001 Region name 0x7fd376ff3000 Region address 0x7fd376ff30a0 Region allocation head 0x7fd376ffb2b0 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 796 allocations, 0 failures, 539 frees, 3 longest Allocations by power-of-two sizes: 1KB 781 2KB 3 4KB 6 8KB 3 16KB 0 32KB 1 64KB 0 128KB 0 256KB 2 512KB 0 1024KB 1 REGION_SHARED Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock region parameters: 2 Lock region region mutex [4/3168 0% !Own] wakeups 0/2 16381 locker table size 8191object table size 34128 obj_off 889656 locker_off 0 need_dd =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock conflict matrix: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status - Object --- 1 dd=122 locks held 1write locks 0pid/thread 1863/140491426347008 flags 10 priority 100 1 READ 1 HELDuserRoot/id2entry.db handle0 2 dd=121 locks held 0write locks 0pid/thread 1863/140490519340800 flags 0priority 100 2 READ 1 WAITuserRoot/id2entry.db page 2495 3 dd=120 locks held 1write locks 0pid/thread 1863/140491426347008 flags 10 priority 100 3 READ 1 HELDipaca/id2entry.db handle0 4 dd=119 locks held 0write locks 0pid/thread 1863/140491426347008 flags 0priority 100 5 dd=118 locks held 1write locks 0pid/thread 1863/140491426347008 flags 10 priority 100 5 READ 1 HELDipaca/entryrdn.db handle0 6 dd=117 locks held 0write locks 0pid/thread 1863/140491426347008 flags 0priority 100 7 dd=116 locks held 0write locks 0pid/thread 1863/140491426347008 flags 0priority 100 8 dd=115 locks held 0write locks 0pid/thread 1863/140491426347008 flags 0priority 100 9 dd=114 locks held 1write locks 0pid/thread 1863/140491426347008 flags 10 priority 100 9 READ 1 HELDipaca/vlv#allcertspkitomcatindex.db handle 0 d dd=113 locks held 1write locks 0pid/thread 1863/140491426347008 flags 10 priority 100 d READ 1 HELDipaca/vlv#allnonrevokedcertspkitomcatindex.db handle0 f dd=112 locks held 1write locks 0pid/thread 1863/140491426347008 flags 10 priority 100 f READ
Re: [Freeipa-users] Problem with replication
please reply to the mailing list On 05/06/2015 11:00 AM, Łukasz Jaworski wrote: Hi, ipactl stops working after dirsrv-stop/start. There are many changes in the changelog: from 39399 to 44397 (…) # 44393, changelog dn: changenumber=44393,cn=changelog # 44394, changelog dn: changenumber=44394,cn=changelog # 44395, changelog dn: changenumber=44395,cn=changelog # 44396, changelog dn: changenumber=44396,cn=changelog # 44397, changelog dn: changenumber=44397,cn=changelog # search result search: 2 result: 11 Administrative limit exceeded # numResponses: 5001 # numEntries: 5000 Best regards, Lukasz Jaworski 'Ender' Wiadomość napisana przez Ludwig Krispenz lkris...@redhat.com w dniu 6 maj 2015, o godz. 10:52: Hi, there seem to be different issues, - I don't know what the ipactl status is looking for when it generates the error message about no matching master, but I don't think it is related to the retro changelog. - the retro changelog errors for adding and deleting -- the add failures are about aborted transactions because a page cannot be accessed, this maybe caused by concurrent mods on different backends, which want to update teh shared retro cl database. the changenumber reprted seems to be increasing, one error is about changenumber 44975, the next about 45577, so it looks like changes into the changelog are written and teh changenumber increases -- i'm not sure about the delete errors, but normally trimming would go on after such an error message, the changenumber attempted to delete are increasing. Could you verify which changes are in the changelog, and if these are changing: ldapsearch -b cn=changelog dn On 05/06/2015 09:52 AM, Łukasz Jaworski wrote: Hi, One of our replica hanged up morning. Error log after dirsrv restart: [06/May/2015:09:28:15 +0200] - Retry count exceeded in delete [06/May/2015:09:28:15 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 38376 (rc: 51) [06/May/2015:09:28:15 +0200] - Operation error fetching Null DN (6368aeb7-f3c111e4-ae70ce39-9b469c1f), error -30993. [06/May/2015:09:28:15 +0200] - dn2entry_ext: Failed to get id for changenumber=44975,cn=changelog from entryrdn index (-30993) [06/May/2015:09:28:15 +0200] - Operation error fetching changenumber=44975,cn=changelog (null), error -30993. [06/May/2015:09:28:15 +0200] DSRetroclPlugin - replog: an error occured while adding change number 44975, dn = changenumber=44975,cn=changelog: Operations error. [06/May/2015:09:28:15 +0200] retrocl-plugin - retrocl_postob: operation failure [1] [06/May/2015:09:28:15 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 [06/May/2015:09:30:03 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 [06/May/2015:09:30:06 +0200] - Retry count exceeded in delete [06/May/2015:09:30:06 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39297 (rc: 51) I did re-initialize from other replica. Now ipactl doesn't work. Shows: Configured hostname 'replica09.local' does not match any master server in LDAP. On lists replica09 is exists (twice) # ipactl status Failed to get list of services to probe status! Configured hostname 'replica09.local' does not match any master server in LDAP: replica01.local replica02.local replica03.local replica04.local replica05.local replica06.local replica07.local replica08.local replica09.local replica10.local replica09.local After dirsrv stop/start: In error logs there are many: [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39290 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39291 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39292 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39293 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39294 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39295 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39296 (rc: 32) etc. [06/May/2015:09:51:08 +0200] - Operation error fetching Null DN (9f51430a-f3c411e4-927ece39-9b469c1f), error -30993. [06/May/2015:09:51:08 +0200] - dn2entry_ext: Failed to get id for changenumber=45577,cn=changelog from entryrdn index (-30993) [06/May/2015:09:51:08 +0200] - Operation error fetching changenumber=45577,cn=changelog (null), error -30993. [06/May/2015:09:51:08 +0200] DSRetroclPlugin - replog: an error occured while adding change number 45577, dn = changenumber=45577,cn=changelog: Operations error. [06/May/2015:09:51:08 +0200] retrocl-plugin - retrocl_postob: operation failure [1] [06/May/2015:09:51:08 +0200] - ldbm_back_seq deadlock
Re: [Freeipa-users] Revocation of Issuing CA certificates
On 05/06/2015 08:24 AM, Kamal Perera wrote: Dear All, How is the revocation of issuing CA certificates are handled? We are using OCSP responders for revocation checking of certificates issued by the Issuing CAs. So do we have to setup another OCSP or CRL distribution point to let the applications to query for the revocation of issuing CA certificates? I think I do not understand the question. IPA CA does not issue CA certificates (at least via IPA API), what certificates did you want to check? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Cannot find KDC for realm MYDOMAIN.NET - AD trust and UPN issues
On Tue, May 05, 2015 at 09:14:52PM -0700, Nathan Peters wrote:
From this link :
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory-trust.html#comp-trust-krb
The diagram in that section shows the client communicating with FreeIPA and
FreeIPA contacting AD.
So why are you saying the client authenticates with the AD DC directly?
If you want to look up user data like e.g. the UID or the home
directory the IPA client will talk to the IPA server exclusively, if the
server does not know about the requested AD user it will try to get this
information from a AD DC.
For authentication this is different, because only the AD DC should know
the password of the user. Hence authentication ans password changes as
well are done directly with the AD DC.
Also this page here :
https://www.freeipa.org/page/Active_Directory_trust_setup
does not list having to add the AD domain in the krb5.conf. Is that not
necessary in the example because they are not using a different UPN for
their users like we are?
yes, it is because of the UPN in your case. As I said before this
special entry in krb5.conf would not be needed anymore if the IPA KDC
supports the Kerberos client referrals for the trusted domains. Adding
the entry to krb5.conf in only a work-around here.
bye,
Sumit
-Original Message- From: Jakub Hrozek
Sent: Tuesday, May 05, 2015 8:43 PM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Cannot find KDC for realm MYDOMAIN.NET - AD
trust and UPN issues
On Tue, May 05, 2015 at 02:21:40PM -0700, nat...@nathanpeters.com wrote:
I'm a little confused by that.
If I add the AD dc, will my client try to contact AD directly to get a
ticket?
Doesn't it have to do get the ticket through FreeIPA by proxy somehow?
No, authentication is always performed against an AD DC directly.
And to confirm what you meant by add the AD dc and realm, it would be like
this ?
SUB.ADDOMAIN.NET = {
kdc = dc1.addomain.net:88
}
I don't need the master_kdc, admin_server, default_domain entries?
With a recent version of libkrb5 I don't think you need to set
master_kdc, libkrb5 should be able to follow referrals itself.
admin_servre, if unset, defaults to KDC. default_domain doesn't need to
be set either.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA RUV unable to decode
On 05/05/2015 04:49 PM, Mark Reynolds wrote:
On 05/05/2015 07:49 AM, Ludwig Krispenz wrote:
On 05/05/2015 01:27 PM, Martin Kosek wrote:
On 05/05/2015 12:38 PM, Vaclav Adamec wrote:
Hi,
I tried migrate to newest version IPA, but result is quite unstable and
removing old replicas ends with RUV which cannot be decoded (it stucked in
queue forever):
ipa-replica-manage del ipa-master-dmz002.test.com -fc
Cleaning a master is irreversible.
This should not normally be require, so use cautiously.
Continue to clean master? [no]: yes
ipa-replica-manage list-ruv
unable to decode: {replica 8} 5509123900040008 5509123900040008
unable to decode: {replica 7} 552f84cd00030007 552f84cd00030007
unable to decode: {replica 11} 551a42f7000b 551aa3140001000b
unable to decode: {replica 15} 551e82e10001000f 551e82e10001000f
unable to decode: {replica 14} 551e82ec0001000e 551e82ec0001000e
unable to decode: {replica 20} 552f4b7200060014 552f4b7200060014
unable to decode: {replica 10} 551a25af0001000a 551a25af0001000a
unable to decode: {replica 3} 551e864c00030003 551e864c00030003
unable to decode: {replica 5} 55083ad200030005 55083ad200030005
unable to decode: {replica 9} 550913e70009 550913e70009
unable to decode: {replica 19} 5521019300030013 5521019300030013
unable to decode: {replica 12} 551a4829000c 551a48c5000c
ipa-master-dmz001.test.com:389: 25
ipa-master-dmz002.test.com:389: 21
it is possible to clear this queue and leave only valid servers ?
Thanks in advance
ipa-client-4.1.0-18.el7_1.3.x86_64
ipa-server-4.1.0-18.el7_1.3.x86_64
Ludwig or Thierry, do you know? The questions about RUV cleaning seems to be
recurring, I suspect there will be a pattern (bug) and not just
configuration
issue.
we have seen this in a recent thread, and it is clear that the RUV is
corrupted and cannot be decoded, but we don't have a scenario how this is
state is reached.
The cleaning task (cleanAllRUV) can remove these invalid replica RUVs (RUV's
missing the ldap URL). To reproduce these invalid RUV's it requires
replication being disabled and re-enabled with a different replica id.
To manually clean these invalid RUV elements, outside of using the IPA CLI,
you
can directly issue the cleanAllRUV task to the Directory Server using
ldapmodify:
# ldapmodify -D cn=directory manager -W -a
dn: cn=clean 8, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
replica-id: 8
cn: clean 8
Run these one at a time, as there is a current limit of running 4 concurrent
tasks. It is best to monitor the Directory Server errors log, or search on
the
task entry itself, to see when it has finished before firing off the next
task.
For more on using cleanAllRUV see:
http://www.port389.org/docs/389ds/howto/howto-cleanruv.html#cleanallruv
http://www.port389.org/docs/389ds/design/cleanallruv-design.html
Regards,
Mark
Just for the record, ipa-replica-manage has a CLI for the CleanAllRUV task
management:
# man ipa-replica-manage
...
list-ruv
- List the replication IDs on this server.
clean-ruv [REPLICATION_ID]
- Run the CLEANALLRUV task to remove a replication ID.
abort-clean-ruv [REPLICATION_ID]
- Abort a running CLEANALLRUV task.
list-clean-ruv
- List all running CLEANALLRUV and abort CLEANALLRUV tasks.
...
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
[Freeipa-users] Problem with replication
Hi, One of our replica hanged up morning. Error log after dirsrv restart: [06/May/2015:09:28:15 +0200] - Retry count exceeded in delete [06/May/2015:09:28:15 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 38376 (rc: 51) [06/May/2015:09:28:15 +0200] - Operation error fetching Null DN (6368aeb7-f3c111e4-ae70ce39-9b469c1f), error -30993. [06/May/2015:09:28:15 +0200] - dn2entry_ext: Failed to get id for changenumber=44975,cn=changelog from entryrdn index (-30993) [06/May/2015:09:28:15 +0200] - Operation error fetching changenumber=44975,cn=changelog (null), error -30993. [06/May/2015:09:28:15 +0200] DSRetroclPlugin - replog: an error occured while adding change number 44975, dn = changenumber=44975,cn=changelog: Operations error. [06/May/2015:09:28:15 +0200] retrocl-plugin - retrocl_postob: operation failure [1] [06/May/2015:09:28:15 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 [06/May/2015:09:30:03 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 [06/May/2015:09:30:06 +0200] - Retry count exceeded in delete [06/May/2015:09:30:06 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39297 (rc: 51) I did re-initialize from other replica. Now ipactl doesn't work. Shows: Configured hostname 'replica09.local' does not match any master server in LDAP. On lists replica09 is exists (twice) # ipactl status Failed to get list of services to probe status! Configured hostname 'replica09.local' does not match any master server in LDAP: replica01.local replica02.local replica03.local replica04.local replica05.local replica06.local replica07.local replica08.local replica09.local replica10.local replica09.local After dirsrv stop/start: In error logs there are many: [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39290 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39291 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39292 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39293 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39294 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39295 (rc: 32) [06/May/2015:09:50:30 +0200] DSRetroclPlugin - delete_changerecord: could not delete change record 39296 (rc: 32) etc. [06/May/2015:09:51:08 +0200] - Operation error fetching Null DN (9f51430a-f3c411e4-927ece39-9b469c1f), error -30993. [06/May/2015:09:51:08 +0200] - dn2entry_ext: Failed to get id for changenumber=45577,cn=changelog from entryrdn index (-30993) [06/May/2015:09:51:08 +0200] - Operation error fetching changenumber=45577,cn=changelog (null), error -30993. [06/May/2015:09:51:08 +0200] DSRetroclPlugin - replog: an error occured while adding change number 45577, dn = changenumber=45577,cn=changelog: Operations error. [06/May/2015:09:51:08 +0200] retrocl-plugin - retrocl_postob: operation failure [1] [06/May/2015:09:51:08 +0200] - ldbm_back_seq deadlock retry BAD 1601, err=0 BDB0062 Successful return: 0 Packages: freeipa-server-4.1.3-2.fc21.x86_64 389-ds-base-1.3.3.8-1.fc21.x86_64 389-ds-base-libs-1.3.3.8-1.fc21.x86_64 Best regards, Ender -- Lukasz Jaworski -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA RUV unable to decode
This tool cannot clear undecoded RUVs, I had sucess only with cleanallruv.pl
script. Btw anybody know about some IDM training in Europe (RedHat/FreeIPA)
?
Vasek
On Wed, May 6, 2015 at 8:22 AM, Martin Kosek mko...@redhat.com wrote:
On 05/05/2015 04:49 PM, Mark Reynolds wrote:
On 05/05/2015 07:49 AM, Ludwig Krispenz wrote:
On 05/05/2015 01:27 PM, Martin Kosek wrote:
On 05/05/2015 12:38 PM, Vaclav Adamec wrote:
Hi,
I tried migrate to newest version IPA, but result is quite unstable
and
removing old replicas ends with RUV which cannot be decoded (it
stucked in
queue forever):
ipa-replica-manage del ipa-master-dmz002.test.com -fc
Cleaning a master is irreversible.
This should not normally be require, so use cautiously.
Continue to clean master? [no]: yes
ipa-replica-manage list-ruv
unable to decode: {replica 8} 5509123900040008
5509123900040008
unable to decode: {replica 7} 552f84cd00030007
552f84cd00030007
unable to decode: {replica 11} 551a42f7000b
551aa3140001000b
unable to decode: {replica 15} 551e82e10001000f
551e82e10001000f
unable to decode: {replica 14} 551e82ec0001000e
551e82ec0001000e
unable to decode: {replica 20} 552f4b7200060014
552f4b7200060014
unable to decode: {replica 10} 551a25af0001000a
551a25af0001000a
unable to decode: {replica 3} 551e864c00030003
551e864c00030003
unable to decode: {replica 5} 55083ad200030005
55083ad200030005
unable to decode: {replica 9} 550913e70009
550913e70009
unable to decode: {replica 19} 5521019300030013
5521019300030013
unable to decode: {replica 12} 551a4829000c
551a48c5000c
ipa-master-dmz001.test.com:389: 25
ipa-master-dmz002.test.com:389: 21
it is possible to clear this queue and leave only valid servers ?
Thanks in advance
ipa-client-4.1.0-18.el7_1.3.x86_64
ipa-server-4.1.0-18.el7_1.3.x86_64
Ludwig or Thierry, do you know? The questions about RUV cleaning seems
to be
recurring, I suspect there will be a pattern (bug) and not just
configuration
issue.
we have seen this in a recent thread, and it is clear that the RUV is
corrupted and cannot be decoded, but we don't have a scenario how this
is
state is reached.
The cleaning task (cleanAllRUV) can remove these invalid replica RUVs
(RUV's
missing the ldap URL). To reproduce these invalid RUV's it requires
replication being disabled and re-enabled with a different replica id.
To manually clean these invalid RUV elements, outside of using the IPA
CLI, you
can directly issue the cleanAllRUV task to the Directory Server using
ldapmodify:
# ldapmodify -D cn=directory manager -W -a
dn: cn=clean 8, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
replica-id: 8
cn: clean 8
Run these one at a time, as there is a current limit of running 4
concurrent
tasks. It is best to monitor the Directory Server errors log, or search
on the
task entry itself, to see when it has finished before firing off the
next task.
For more on using cleanAllRUV see:
http://www.port389.org/docs/389ds/howto/howto-cleanruv.html#cleanallruv
http://www.port389.org/docs/389ds/design/cleanallruv-design.html
Regards,
Mark
Just for the record, ipa-replica-manage has a CLI for the CleanAllRUV task
management:
# man ipa-replica-manage
...
list-ruv
- List the replication IDs on this server.
clean-ruv [REPLICATION_ID]
- Run the CLEANALLRUV task to remove a replication ID.
abort-clean-ruv [REPLICATION_ID]
- Abort a running CLEANALLRUV task.
list-clean-ruv
- List all running CLEANALLRUV and abort CLEANALLRUV tasks.
...
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
--
-- May the fox be with you ...
/\
(~(
) ) /\_/\
(_=---_(@ @)
( \ /
/|/\|\ V
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
[Freeipa-users] Revocation of Issuing CA certificates
Dear All, How is the revocation of issuing CA certificates are handled? We are using OCSP responders for revocation checking of certificates issued by the Issuing CAs. So do we have to setup another OCSP or CRL distribution point to let the applications to query for the revocation of issuing CA certificates? Regards, Kamal -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Fwd: Re: IPA RUV unable to decode
let's keep the info on the list, more peple more ideas
Original Message
Subject:Re: [Freeipa-users] IPA RUV unable to decode
Date: Tue, 5 May 2015 18:32:15 +0200
From: Vaclav Adamec vaclav.ada...@suchy-zleb.cz
To: Ludwig Krispenz lkris...@redhat.com
master:
ipa-replica-manage del replica_server -fc
ipa-replica-prepare ... + copy gpg
replicas:
ipa-server-install --uninstall
ipa-replica-install ...
one by one on all replicas (1 CA master and 5 replicas which are also
set in DNS as SRV records). Plus whole the time there was script/job
which register clients (ipa-client-install --uninstall +
ipa-client-install ... --force-join different active replica
servers - via DNS). Seems that I have some issue with replica itself, it
seems to work, but when it's loaded with such heavy operation replica
servers goes down (dir process died) even master itself went down with
minor codes errs in log.
On Tue, May 5, 2015 at 3:25 PM, Ludwig Krispenz lkris...@redhat.com
mailto:lkris...@redhat.com wrote:
On 05/05/2015 02:24 PM, Vaclav Adamec wrote:
For me it was quite easy to reached this state, I just setup
replica on 6 servers (two datacenters, with ~15ms latency, same
stable ntp source), run test scripts which add/verify random
account, add/remove hosts (unregister seems to be heaviest
operation to replicas). During these tests I removed some remove
servers from replica and try to add them back,
what exactly did you do:
ipa-server-install --uninstall
ipa-server-install ?
any other commands ?
result is like this. Seems that with higher load it happens more
often (register/unregister multiple servers, with actual setup it
is about 10 new registration in same time to different replica
servers), also sometimes I got replication conflicts or dir
service complete failure (dirsrv down, started with gssapi minor
code error). But even If I stop tests queue is not freed, RUV
still there (old replicas).
On Tue, May 5, 2015 at 1:49 PM, Ludwig Krispenz
lkris...@redhat.com mailto:lkris...@redhat.com wrote:
On 05/05/2015 01:27 PM, Martin Kosek wrote:
On 05/05/2015 12:38 PM, Vaclav Adamec wrote:
Hi,
I tried migrate to newest version IPA, but result is
quite unstable and
removing old replicas ends with RUV which cannot be
decoded (it stucked in
queue forever):
ipa-replica-manage del ipa-master-dmz002.test.com
http://ipa-master-dmz002.test.com -fc
Cleaning a master is irreversible.
This should not normally be require, so use cautiously.
Continue to clean master? [no]: yes
ipa-replica-manage list-ruv
unable to decode: {replica 8} 5509123900040008
5509123900040008
unable to decode: {replica 7} 552f84cd00030007
552f84cd00030007
unable to decode: {replica 11} 551a42f7000b
551aa3140001000b
unable to decode: {replica 15} 551e82e10001000f
551e82e10001000f
unable to decode: {replica 14} 551e82ec0001000e
551e82ec0001000e
unable to decode: {replica 20} 552f4b7200060014
552f4b7200060014
unable to decode: {replica 10} 551a25af0001000a
551a25af0001000a
unable to decode: {replica 3} 551e864c00030003
551e864c00030003
unable to decode: {replica 5} 55083ad200030005
55083ad200030005
unable to decode: {replica 9} 550913e70009
550913e70009
unable to decode: {replica 19} 5521019300030013
5521019300030013
unable to decode: {replica 12} 551a4829000c
551a48c5000c
ipa-master-dmz001.test.com:389
http://ipa-master-dmz001.test.com:389: 25
ipa-master-dmz002.test.com:389
http://ipa-master-dmz002.test.com:389: 21
it is possible to clear this queue and leave only
valid servers ?
Thanks in advance
ipa-client-4.1.0-18.el7_1.3.x86_64
ipa-server-4.1.0-18.el7_1.3.x86_64
Ludwig or Thierry, do you know? The questions about RUV
cleaning seems to be
recurring, I suspect there will be a pattern (bug) and not
just configuration
issue.
we have seen this in a recent thread, and it is clear that the
RUV is corrupted and cannot be decoded, but we don't have a
scenario how this is state is reached.
--
Re: [Freeipa-users] Known issues with IPA on VM?
On 05/06/2015 07:48 AM, Christoph Kaminski wrote: Hi we have some undefinably problems here with IPA inside a VM (rhev/kvm). We has often zombie processes (defunct) with certmonger and dirsrv and segfaults (dmesg)... We have 8 IPA servers, 4 Hardware and 4 VM's with same Install (rhel7.1). We see these problems only on the VM's. Is there something already known about such problems? (The VM's have ever 4 CPU's and 2GB RAM, we have circa 120 Users/Groups) I do not recall any specific VM problems in particular (maybe except that NTPD does not work too well in VMs), so I would recommend checking for the real reasons of crash. Maybe there are some useful errors in the DS/certmonger log files. If not, seeing the stack trace of the crash would help us/dirsrv developers identify the problem: http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug_crashes -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] How to renew an expired admin certificate
Thanks I will check. On Tue, Apr 28, 2015 at 12:26 PM, Niranjan M.R mrniran...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/28/2015 11:20 AM, Kamal Perera wrote: Dear All, I'm in the process of regaining one of the old CA systems which was not being used for a long time. In the root CA, administrator certificate is expired and cannot access the agent interface. In order to renew it, i would need the access to the agent interface. Could you roll back the system date and try ? Please help me to proceed with the login in to the agent interface. Regards, Kamal - -- Niranjan irc: mrniranjan -BEGIN PGP SIGNATURE- Version: GnuPG v1 iKYEARECAGYFAlU/LxVfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEY3OTE3QTg3ODE0RkVCQ0YyNjgyOTRENjJF RURDNTVGNjA0N0M3QzcACgkQLu3FX2BHx8ef5wCfUP8ObZnJ6nO2gqqRnWU/VUWr u00AoMpIaGxdjEXm/7uAK0oUDsWq/Mn0 =2nS3 -END PGP SIGNATURE- -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to slaves
Hello! On 5.5.2015 00:24, nat...@nathanpeters.com wrote: bind.x86_6432:9.9.4-20.el7.centos.pkcs11 @mkosek-freeipa bind-dyndb-ldap.x86_64 6.1-1.el7.centos This version works for me (tested on Fedora 21). And for reference here are the relevant A and NS records from my domain @ NS dc1.mydomain.net. @ NS dc2.mydomain.net. @ NS dns1.mydomain.net. dns1 A 10.21.0.14 I would recommend you to double check if commands $ dig @IPA server dc1.mydomain.net. A $ dig @IPA server dc2.mydomain.net. A $ dig @IPA server dns1.mydomain.net. A actually return an IP addresses or not. Unfortunately BIND does not report an error if it is unable to resolve the name and silently ignores the name when notifications are sent. For testing purposes I use these commands (on server): $ tcpdump -i any 'port 53' $ rndc notify mydomain.net. Look for a line from tcpdump with note 'notify' in it. I can see the notify packet as soon as BIND prints 'sending notifies' message to the journal. I hope this helps. Petr^2 Spacek Hello! On 2.5.2015 17:12, Nathan Peters wrote: The last 3 sentences of my original post refer to me adding the NS records for the slave. Is that what you mean? I have also ensured that the slave hostname and IP are in FreeIPA DNS. I have also added an NS entry pointing to the slave. Which version of FreeIPA and bind-dyndb-ldap are you using? I will look into it. Petr^2 Spacek -Original Message- From: Baird, Josh Sent: Saturday, May 02, 2015 7:33 AM To: 'nat...@nathanpeters.com' ; freeipa-users@redhat.com Subject: RE: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to slaves Is the PowerDNS slave in the NS RRSet for the IPA domain? Unfortuantely, bind-dyndb-ldap does not support 'also-notify' which would allow us to send notifies each time a zone update occurs to slave servers that are not in the RRSet [1]. To compensate for this in my environment, I had to lower the 'refresh' timer on the IPA zone. [1] https://fedorahosted.org/bind-dyndb-ldap/ticket/152 -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of nat...@nathanpeters.com Sent: Friday, May 1, 2015 8:20 PM To: freeipa-users@redhat.com Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to slaves I have 2 FreeIPA 4.1.4 servers setup on CentOS 7 as replicas. I also have another host running PowerDNS serving as a slave. The FreeIPA servers are setup to allow transfers to the slave by IP. When adding the zone, the slave transfered it properly. However, when I update the zone in FreeIPA, although the serial number changes, in the /var/log/messages I only see an attempt to transfer to the second IPA server, and not the slave. This is the only log entry : May 2 01:06:56 dc1 named-pkcs11[5897]: zone mydomain.net/IN: sending notifies (serial 1430528817) May 2 01:06:57 dc1 named-pkcs11[5897]: client 10.178.0.99#29832: received notify for zone 'mydomain.net' I have restarted all services using ipactl restart several times. I have also ensured that the slave hostname and IP are in FreeIPA DNS. I have also added an NS entry pointing to the slave. According to the FreeIPA manual, once that NS entry is added, any zone updates should trigger a notify, but still the only notifications go out to FreeIPA servers and nothing else. Any idea how to fix this so FreeIPA notifies non IPA servers? I'm pretty sure I've followed all the instructions to the letter on this one... -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Revocation of Issuing CA certificates
Kamal Perera wrote: Dear All, How is the revocation of issuing CA certificates are handled? We are using OCSP responders for revocation checking of certificates issued by the Issuing CAs. So do we have to setup another OCSP or CRL distribution point to let the applications to query for the revocation of issuing CA certificates? Both points are encoded in the certificates that IPA issues: [ SNIP ] Name: Authority Information Access Method: PKIX Online Certificate Status Protocol Location: URI: http://ipa-ca.example.com/ca/ocsp; Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Data Encipherment Name: Extended Key Usage TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate Name: CRL Distribution Points Distribution point: URI: http://ipa-ca.example.com/ipa/crl/MasterCRL.bin; CRL issuer: Directory Name: CN=Certificate Authority,O=ipaca rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Credentials constantly revoked for admin user
I'm having this issue. I discovered when I would randomly get locked out of the admin account with the usual: kinit: Clients credentials have been revoked while getting initial credentials The scenario would go as follows: Sometimes I would try to issue kinit admin, with the correct credentials only to be met with the above results. Other times it would work fine, only to fail when running an 'ipa' command. Anyway, I discovered a bunch of failed auth entries for admin in the logs, coming from clients. This would be mixed with successful logins from the same machine. So what it looks like is happening is that these failed logins would lock me out, sometimes in the middle of a session. Just waiting 60 seconds for the lock out to time out would allow me to continue my work. Has anyone seen this issue before? I'm using ipa server 3.0 on a CentOS 6.6 server. Thanks, Drew -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Credentials constantly revoked for admin user
On Mon, 04 May 2015, Andrew Morone wrote: I'm having this issue. I discovered when I would randomly get locked out of the admin account with the usual: kinit: Clients credentials have been revoked while getting initial credentials The scenario would go as follows: Sometimes I would try to issue kinit admin, with the correct credentials only to be met with the above results. Other times it would work fine, only to fail when running an 'ipa' command. Anyway, I discovered a bunch of failed auth entries for admin in the logs, coming from clients. This would be mixed with successful logins from the same machine. So what it looks like is happening is that these failed logins would lock me out, sometimes in the middle of a session. Just waiting 60 seconds for the lock out to time out would allow me to continue my work. Has anyone seen this issue before? I'm using ipa server 3.0 on a CentOS 6.6 server. Are you using admin credentials as a bind DN from some application? Or some application which authenticates against LDAP is DoSed by someone. In any case you would need to look at /var/log/dirsrv/slapd-INSTANCE/access and /var/log/krb5kdc.log. Both logs have enough information to identify from which hosts these authentication attempts come and narrow down exploration of what happens on those hosts. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Logging into Samba shares from non-domain trust Win7 PCs using IPA for Samba password auth.
Hi, The goal is to have a common password to give users access to a Linux system via PuTTY/SSH and Samba file-shares where currently for historical reasons we have 2 passwords, which is a real PITA. The PuTTY logins work great but I need to get the logins for the Samba4 shares working from Win7 PCs that aren't part of a domain trust. I know it sounds wrong but it needs to be done this way for system segregation. I followed the instructions at http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA to get Samba4 set up to talk to IPA and it works great for Linux boxes on the domain using smbclient -k. However I'm stuck trying to get non-domain Win7 boxes access to the shares. I've tried different domain\username combinations but not struck the right one. I presume I need to get some sort of non-Kerberos login method worked out, but I'm stuck. The Samba4 box is running CentOS Linux release 7.1.1503 with samba 4.1.12-21, ipa 4.1.0-18 and sssd 1.12.2-58. smb.conf: [global] workgroup = UNIX realm = UNIX.EXAMPLE.COM dedicated keytab file = FILE:/etc/samba/samba.keytab kerberos method = dedicated keytab log level = 2 log file = /var/log/samba/log.%m security = ads [Test_Share] path = /export/Test_Share writeable = yes browsable = yes write list = @TestGroup force group = TestGroup If anyone's interested I can add logs. Thanks, Dylan. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Known issues with IPA on VM?
On 05/06/2015 12:25 AM, Martin Kosek wrote: On 05/06/2015 07:48 AM, Christoph Kaminski wrote: Hi we have some undefinably problems here with IPA inside a VM (rhev/kvm). We has often zombie processes (defunct) with certmonger and dirsrv and segfaults (dmesg)... We have 8 IPA servers, 4 Hardware and 4 VM's with same Install (rhel7.1). We see these problems only on the VM's. Is there something already known about such problems? (The VM's have ever 4 CPU's and 2GB RAM, we have circa 120 Users/Groups) I do not recall any specific VM problems in particular (maybe except that NTPD does not work too well in VMs), so I would recommend checking for the real reasons of crash. Maybe there are some useful errors in the DS/certmonger log files. If not, seeing the stack trace of the crash would help us/dirsrv developers identify the problem: http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug_crashes For IPA, to get full stacktraces, you will also need to do this: # debuginfo-install ipa-server slapi-nis -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Using CNAME to point to different domain name
Hello Team, We are hosting a few servers at Amazon and using their Elastic Load Balancing service that gives us a link to a load balancer in the following format: webserver-1234567890.us-east-1.elb.amazonaws.com I was looking for a ways to implement a shorter alias using CNAME like: webserver.mydomain.com pointing to longer link from the load balancer webserver-1234567890.us-west-2.elb.amazonaws.com Is there a way to do it in RHEL 7.1 with IPA server 4.1.0 using different domain names? Regards, Andrey -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Cannot find KDC for realm MYDOMAIN.NET - AD trust and UPN issues
Ok, I have attempted to set this up by adding the AD domain to my
configuration and it still isn't working.
I just want to confirm what I'm trying to accomplish here before I list
what I've done to troubleshoot this.
We have an AD domain called corp.addomain.net. We have UPNs set so AD
users login to the AD domain as adusern...@addomain.net when they login to
windows machines.
The linux clients in our network are currently just using straight up
kerberos authentication against the domain and can currently login as
'username' without entering any suffix.
Because this means we can't control sudo policies centrally by our current
direct kerberos connection, we want to switch to logging in through
FreeIPA.
I need to be clear that we want to maintain the current logins of just
'username' on Linux servers.
To accomplish this, I added the following line to the sssd.conf file:
default_domain_suffix = corp.addomain.net
I have tried 3 different combinations of kerberos config to try to get the
logins to work, but am running into errors in each case. I have tried to
follow the suggestions given earlier in this thread. Here are the 3
krb.conf configurations I tried and the errors given on each try.
-- configuration 1 ---
[realms]
IPADOMAIN.NET = {
kdc = dc1.ipadomain.net:88
master_kdc = dc1.ipadomain.net:88
admin_server = dc1.ipadomain.net:749
default_domain = ipadomain.net
pkinit_anchors = FILE:/etc/ipa/ca.crt
auth_to_local =
RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/
auth_to_local = DEFAULT
}
CORP.ADDOMAIN.NET = {
kdc = dc3.corp.addomain.net:88
master_kdc = dc3.corp.addomain.net:88
}
[domain_realm]
.ipadomain.net = IPADOMAIN.NET
ipadomain.net = IPADOMAIN.NET
.corp.addomain.net = CORP.ADDOMAIN.NET
corp.addomain.net = CORP.ADDOMAIN.NET
May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot
find KDC for realm ADDOMAIN.NET
May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot
find KDC for realm ADDOMAIN.NET
May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=adusername
May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth): received
for user adusername: 4 (System error)
May 06 16:43:55 dc1.ipadomain.net sshd[7508]: Failed password for
adusername from 10.5.5.57 port 1832 ssh2
--- configuration 2
Notes : since the above error seemed to imply that I needed to add the
'UPN realm' to the [realms] section I tried to add it.
[realms]
IPADOMAIN.NET = {
kdc = dc1.ipadomain.net:88
master_kdc = dc1.ipadomain.net:88
admin_server = dc1.ipadomain.net:749
default_domain = ipadomain.net
pkinit_anchors = FILE:/etc/ipa/ca.crt
auth_to_local =
RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/
auth_to_local = DEFAULT
}
ADDOMAIN.NET = {
kdc = dc3.corp.addomain.net:88
master_kdc = dc3.corp.addomain.net:88
}
[domain_realm]
.ipadomain.net = IPADOMAIN.NET
ipadomain.net = IPADOMAIN.NET
addomain.net = ADDOMAIN.NET
.addomain.net = ADDOMAIN.NET
May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm
not local to KDC
May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm
not local to KDC
May 06 16:48:32 dc1.ipadomain.net sshd[7542]: pam_sss(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=adusername
May 06 16:48:32 dc1.ipadomain.net sshd[7542]: pam_sss(sshd:auth): received
for user adusername: 4 (System error)
May 06 16:48:34 dc1.ipadomain.net sshd[7542]: Failed password for
adusername from 10.5.5.57 port 1870 ssh2
configuration 3 -
Notes : Since the eror message given in the second try indicated that the
realm wasn't local, I thought it might need both variations to recognize
it as local.
[realms]
IPADOMAIN.NET = {
kdc = dc1.ipadomain.net:88
master_kdc = dc1.ipadomain.net:88
admin_server = dc1.ipadomain.net:749
default_domain = ipadomain.net
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
ADDOMAIN.NET = {
kdc = dc3.corp.addomain.net:88
master_kdc = dc3.corp.addomain.net:88
}
CORP.ADDOMAIN.NET = {
kdc = dc3.corp.addomain.net:88
master_kdc = dc3.corp.addomain.net:88
}
[domain_realm]
.ipadomain.net = IPADOMAIN.NET
ipadomain.net = IPADOMAIN.NET
addomain.net = ADDOMAIN.NET
.addomain.net = ADDOMAIN.NET
corp.addomain.net = CORP.ADDOMAIN.NET
.corp.addomain.net = CORP.ADDOMAIN.NET
May 06 16:56:25 dc1.ipadomain.net [sssd[krb5_child[7664]]][7664]: Realm
not local to KDC
May 06 16:56:25 dc1.ipadomain.net [sssd[krb5_child[7664]]][7664]: Realm
not local to KDC
May 06 16:56:25 dc1.ipadomain.net sshd[7660]: pam_sss(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=adusername
May 06 16:56:25 dc1.ipadomain.net sshd[7660]: pam_sss(sshd:auth): received
for user adusername: 4 (System error)
May
Re: [Freeipa-users] more replication fun
Hi,
Mike Reynolds recommend cleanallruv script (IPA RUV unable to decode
thread), if you are sure that's not any live replica server behind
this id than just try cleanallruv.pl -w X -b dc= -r 9
Vasek
On Thu, May 7, 2015 at 2:25 AM, Janelle janellenicol...@gmail.com wrote:
Hi again..
Seems to be an ongoing theme (replication). How does one remove these?
unable to decode: {replica 9} 553ef80e00010009 55402c390009
I am hoping this is a stupid question with a really simple answer that I am
simply missing?
~J
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
--
-- May the fox be with you ...
/\
(~(
) ) /\_/\
(_=---_(@ @)
( \ /
/|/\|\ V
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Known issues with IPA on VM?
Just a guess, what is your deployment size? We have a two ipa domains, one have 3 servers (2 hw and 1 vm, no issues with dirsrv yet), another currently includes 16 vm servers, ant dirsrv hangs and crashes periodically… WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 From: David Dejaeghere [mailto:david.dejaegh...@gmail.com] Sent: Wednesday, May 06, 2015 3:26 PM To: Alexander Frolushkin (SIB) Cc: Christoph Kaminski; Freeipa-users Subject: Re: [Freeipa-users] Known issues with IPA on VM? Running FreeIPA 4.1 on Fedora 21 on Xenserver 6.2 in HVM mode. No issues. Kind Regards, David 2015-05-06 11:15 GMT+02:00 Alexander Frolushkin alexander.frolush...@megafon.rumailto:alexander.frolush...@megafon.ru: Hello. We have periodically hanging and crashing dirsrv in our ipa servers. All of them running in VM on Vmware. WBR, Alexander Frolushkin Cell +79232508764tel:%2B79232508764 Work +79232507764tel:%2B79232507764 From: freeipa-users-boun...@redhat.commailto:freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.commailto:freeipa-users-boun...@redhat.com] On Behalf Of Christoph Kaminski Sent: Wednesday, May 06, 2015 11:48 AM To: Freeipa-users Subject: [Freeipa-users] Known issues with IPA on VM? Hi we have some undefinably problems here with IPA inside a VM (rhev/kvm). We has often zombie processes (defunct) with certmonger and dirsrv and segfaults (dmesg)... We have 8 IPA servers, 4 Hardware and 4 VM's with same Install (rhel7.1). We see these problems only on the VM's. Is there something already known about such problems? (The VM's have ever 4 CPU's and 2GB RAM, we have circa 120 Users/Groups) Greetz Christoph Kaminski Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщение и любые возможные его копии и приложения. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщение и любые возможные его копии и приложения. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] more replication fun
On 5/6/15 8:12 PM, Vaclav Adamec wrote:
Hi,
Mike Reynolds recommend cleanallruv script (IPA RUV unable to decode
thread), if you are sure that's not any live replica server behind
this id than just try cleanallruv.pl -w X -b dc= -r 9
Vasek
On Thu, May 7, 2015 at 2:25 AM, Janelle janellenicol...@gmail.com wrote:
Hi again..
Seems to be an ongoing theme (replication). How does one remove these?
unable to decode: {replica 9} 553ef80e00010009 55402c390009
I am hoping this is a stupid question with a really simple answer that I am
simply missing?
~J
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Thank you Vasek,
I am curious however. I have been running OpenLDAP configs with 20 or
more servers in replication for over 5 years. In all that time, I think
I have had replication issues 5 times. In the 6 months of working with
FreeIPA, replication issues are constant. From reading the threads, I am
not the only one in this predicament. Is there any history on why
replication is so problematic in FreeIPA?
regards
~J
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Cannot find KDC for realm MYDOMAIN.NET - AD trust and UPN issues
On 05/06/2015 02:15 PM, nat...@nathanpeters.com wrote:
Ok, I have attempted to set this up by adding the AD domain to my
configuration and it still isn't working.
I just want to confirm what I'm trying to accomplish here before I list
what I've done to troubleshoot this.
We have an AD domain called corp.addomain.net. We have UPNs set so AD
users login to the AD domain as adusern...@addomain.net when they login to
windows machines.
The linux clients in our network are currently just using straight up
kerberos authentication against the domain and can currently login as
'username' without entering any suffix.
Because this means we can't control sudo policies centrally by our current
direct kerberos connection, we want to switch to logging in through
FreeIPA.
I need to be clear that we want to maintain the current logins of just
'username' on Linux servers.
To accomplish this, I added the following line to the sssd.conf file:
default_domain_suffix = corp.addomain.net
I am not by any mean a specialist here but shouldn't it be the actual
suffix that is appended to the user name, i.e.
default_domain_suffix = addomain.net
I have tried 3 different combinations of kerberos config to try to get the
logins to work, but am running into errors in each case. I have tried to
follow the suggestions given earlier in this thread. Here are the 3
krb.conf configurations I tried and the errors given on each try.
-- configuration 1 ---
[realms]
IPADOMAIN.NET = {
kdc = dc1.ipadomain.net:88
master_kdc = dc1.ipadomain.net:88
admin_server = dc1.ipadomain.net:749
default_domain = ipadomain.net
pkinit_anchors = FILE:/etc/ipa/ca.crt
auth_to_local =
RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/
auth_to_local = DEFAULT
}
CORP.ADDOMAIN.NET = {
kdc = dc3.corp.addomain.net:88
master_kdc = dc3.corp.addomain.net:88
}
[domain_realm]
.ipadomain.net = IPADOMAIN.NET
ipadomain.net = IPADOMAIN.NET
.corp.addomain.net = CORP.ADDOMAIN.NET
corp.addomain.net = CORP.ADDOMAIN.NET
May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot
find KDC for realm ADDOMAIN.NET
May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot
find KDC for realm ADDOMAIN.NET
May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=adusername
May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth): received
for user adusername: 4 (System error)
May 06 16:43:55 dc1.ipadomain.net sshd[7508]: Failed password for
adusername from 10.5.5.57 port 1832 ssh2
--- configuration 2
Notes : since the above error seemed to imply that I needed to add the
'UPN realm' to the [realms] section I tried to add it.
[realms]
IPADOMAIN.NET = {
kdc = dc1.ipadomain.net:88
master_kdc = dc1.ipadomain.net:88
admin_server = dc1.ipadomain.net:749
default_domain = ipadomain.net
pkinit_anchors = FILE:/etc/ipa/ca.crt
auth_to_local =
RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/
auth_to_local = DEFAULT
}
ADDOMAIN.NET = {
kdc = dc3.corp.addomain.net:88
master_kdc = dc3.corp.addomain.net:88
}
[domain_realm]
.ipadomain.net = IPADOMAIN.NET
ipadomain.net = IPADOMAIN.NET
addomain.net = ADDOMAIN.NET
.addomain.net = ADDOMAIN.NET
May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm
not local to KDC
May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm
not local to KDC
May 06 16:48:32 dc1.ipadomain.net sshd[7542]: pam_sss(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=adusername
May 06 16:48:32 dc1.ipadomain.net sshd[7542]: pam_sss(sshd:auth): received
for user adusername: 4 (System error)
May 06 16:48:34 dc1.ipadomain.net sshd[7542]: Failed password for
adusername from 10.5.5.57 port 1870 ssh2
configuration 3 -
Notes : Since the eror message given in the second try indicated that the
realm wasn't local, I thought it might need both variations to recognize
it as local.
[realms]
IPADOMAIN.NET = {
kdc = dc1.ipadomain.net:88
master_kdc = dc1.ipadomain.net:88
admin_server = dc1.ipadomain.net:749
default_domain = ipadomain.net
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
ADDOMAIN.NET = {
kdc = dc3.corp.addomain.net:88
master_kdc = dc3.corp.addomain.net:88
}
CORP.ADDOMAIN.NET = {
kdc = dc3.corp.addomain.net:88
master_kdc = dc3.corp.addomain.net:88
}
[domain_realm]
.ipadomain.net = IPADOMAIN.NET
ipadomain.net = IPADOMAIN.NET
addomain.net = ADDOMAIN.NET
.addomain.net = ADDOMAIN.NET
corp.addomain.net = CORP.ADDOMAIN.NET
.corp.addomain.net = CORP.ADDOMAIN.NET
May 06 16:56:25 dc1.ipadomain.net [sssd[krb5_child[7664]]][7664]: Realm
not local to KDC
May 06 16:56:25 dc1.ipadomain.net [sssd[krb5_child[7664]]][7664]: Realm
not local to KDC
May 06
[Freeipa-users] more replication fun
Hi again..
Seems to be an ongoing theme (replication). How does one remove these?
unable to decode: {replica 9} 553ef80e00010009 55402c390009
I am hoping this is a stupid question with a really simple answer that I
am simply missing?
~J
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa-samba integration and windows clients
Hi Yes, it's possible to operate freeIPA and Samba as you suggest, we have been doing so for some years now (with several freeIPA and Samba versions). Our end users use a mix of Windows and OSX laptops / workstations. These are not members of any kind of domain. They access our file servers via Samba shares authenticated by freeIPA. The samba server is a freeIPA client. The samba config on the freeIPA side looks like it was done along the lines in the link http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration/ The ldap config in our samba smb.conf looks like this: security = user passdb backend = ldapsam:ldap://ldap.my.example.com ldap suffix = dc=my,dc=example,dc=com ldap admin dn = cn=Directory Manager ldap ssl = off Cheers Chris From: box 31978 box31...@gmail.com To: freeipa-users@redhat.com Date: 06.05.2015 23:18 Subject:[Freeipa-users] freeipa-samba integration and windows clients Sent by:freeipa-users-boun...@redhat.com Hello everyone, These days I'm testing integration between FreeIPA4 and Samba4 at file sharing level. Everything seems to work fine except share access from a standalone Windows client. This is the setup (everything is up-to-date): - ipa-server: CentOS 7.1, ipa-server 4.1, ipa-server-trust-ad plugin - file-server: CentOS 7.1, ipa-client 4.1, samba 4.1 (sharing home dirs, not a DC) - win-client: Windows 7 Home Premium Config is done following the FreeIPA's Samba integration guide, and testing with samba-client from ipa-server (or any other ipa-joined machine) to file-server using kerberos after calling kinit is successful (file manipulation included). Attempts to connect to the same share from win-client ends up with a log in error. Analyzing logs: Samba can't find the user because it can't find any DC, and that's because Samba can't resolve workgroup name (note that's not a question of SSO: win-client asks to type username and password). It seems that maybe Samba is not handling new kerberos ticket requests. By now, my questions are: - Can this setup work or it is absolutely necessary that any Windows client expecting to access Samba shares have to be already joined to a trusted domain? - If this setup can't be done, I'll go for an LDAP config in file-server against ipa-server, but then, can I maintain the file-server joined with ipa-client? Will it work? Feel free to ask whatever you want, any suggestions will be welcome. Thanks! Regards, A.-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
