[Freeipa-users] (no subject)
Good afternoon. In each region, I have a couple of controllers (windows and ipa). With the authorization server in the logs ipa (sssd log) I find that the request is not for the neighbor by location windows server, and randomly throughout the forest. Tell me is there a way to explicitly specify the IPA server on windows DC. Logs attached. there somewhere documentation about? next to the IPA server pk529ad-dc01.sys.local IPA server and knocks pk429ad-dc01.sys.local to another region [sssd[be[ipa.sys.local]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=vccs] [sssd[be[ipa.sys.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'sys.local' [sssd[be[ipa.sys.local]]] [resolve_srv_send] (0x0200): The status of SRV lookup is neutral [sssd[be[ipa.sys.local]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.sys.local' [sssd[be[ipa.sys.local]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'pk429ad-dc01.sys.local' in files [sssd[be[ipa.sys.local]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve record of 'pk429ad-dc01.sys.local' in files [sssd[be[ipa.sys.local]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry [sssd[be[ipa.sys.local]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'pk429ad-dc01.sys.local' in DNS [sssd[be[ipa.sys.local]]] [fo_resolve_service_timeout] (0x0080): Service resolving timeout reached [sssd[be[ipa.sys.local]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error]) [sssd[be[ipa.sys.local]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. [sssd[be[ipa.sys.local]]] [ipa_get_ad_acct_ad_part_done] (0x0040): AD lookup failed: 11 [sssd[be[ipa.sys.local]]] [ipa_account_info_error_text] (0x0020): Bug: dp_error is OK on failed request [sssd[be[ipa.sys.local]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,11,Account info lookup failed [sssd[be[ipa.sys.local]]] [remove_krb5_info_files] (0x0200): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.IPA.SYS.LOCAL], [2][No such file or directory] WINDOWS [root@pk529ipa01 ~]# dig SRV _ldap._tcp.sys.local ; DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-5.P2.fc19 SRV _ldap._tcp.sys.l ocal ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 30812 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 15 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;_ldap._tcp.sys.local. IN SRV ;; ANSWER SECTION: _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk529ad-dc02.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk329ad-dc02.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 p0029ad-dc02.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk529ad-dc01.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk229ad-dc01.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk429ad-dc02.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk329ad-dc01.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk629ad-dc01.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 p0029ad-dc01.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk729ad-dc01.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk729ad-dc02.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk629ad-dc02.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk429ad-dc01.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk229ad-dc02.sys.local . ;; ADDITIONAL SECTION: pk529ad-dc02.sys.local. 3600IN A 172.21.167.135 pk329ad-dc02.sys.local. 1200IN A 172.21.71.135 p0029ad-dc02.sys.local. 3600IN A 192.168.226.61 pk529ad-dc01.sys.local. 3600IN A 172.21.167.134 pk229ad-dc01.sys.local. 3600IN A 172.21.7.134 pk429ad-dc02.sys.local. 3600IN A 172.21.135.135 pk329ad-dc01.sys.local. 3600IN A 172.21.71.134 pk629ad-dc01.sys.local. 3600IN A 172.21.39.134 p0029ad-dc01.sys.local. 3600IN A 192.168.226.60 pk729ad-dc01.sys.local. 3600IN A 172.21.103.134 pk729ad-dc02.sys.local. 3600IN A 172.21.103.135 pk629ad-dc02.sys.local. 3600IN A 172.21.39.135 pk429ad-dc01.sys.local. 3600IN A 172.21.135.134 pk229ad-dc02.sys.local. 3600IN A 172.21.7.135 ;; Query time: 8 msec ;; SERVER:
Re: [Freeipa-users] (no subject)
On 10/11/2013 05:22 AM, ?? ? wrote: Good afternoon. In each region, I have a couple of controllers (windows and ipa). With the authorization server in the logs ipa (sssd log) I find that the request is not for the neighbor by location windows server, and randomly throughout the forest. Tell me is there a way to explicitly specify the IPA server on windows DC. Logs attached. there somewhere documentation about? I am not quite sure I understand you setup but I will try to give you some hints. If you want SSSD to access a specific IPA server or servers you can define primary and secondary servers explicitly in the SSSD configuration. See SSSD man pages. This can also be done via ipa-client-install command line starting IPA client 3.0 and SSSD 1.9 But that would sort of override the information coming from DNS. If you are looking for SSSD to support DNS sites then this functionality is available in SSSD in 1.11 if SSSD is joined directly to AD via AD provider. If you are looking for the same functionality when SSSD connects to IPA then it is still on the roadmap because IPA does not support sites. https://fedorahosted.org/freeipa/ticket/2008 next to the IPA server pk529ad-dc01.sys.local IPA server and knocks pk429ad-dc01.sys.local to another region ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Required services are not started after reboot
On 10/10/2013 04:57 PM, Nathan Kinder wrote: On 10/10/2013 04:11 PM, Nathan Kinder wrote: On 10/10/2013 03:50 PM, Nathan Kinder wrote: On 10/10/2013 06:48 AM, Rob Crittenden wrote: Mateusz Marzantowicz wrote: On 08.10.2013 18:43, Tamas Papp wrote: On 10/08/2013 06:33 PM, Mateusz Marzantowicz wrote: Finally, I've managed to install FreeIPA on Fedora 20 without any errors. I was even able to log in through web UI and make some changes. Sadly after system reboot, non of IPA related services were started and now nothing works as expected. What services need to be enabled (I need to enable manually) to make ipa server operational again? I'd be thankful for any links to official documentation that covers this topic. See: https://bugzilla.redhat.com/show_bug.cgi?id=1008306 t Thanks, It looks like this bug is fixed in fc19 [1] but it's not in fc20 [2] (please compare 'Bugs Fixed' sections (I haven't tested it on fc19)). How is it possible that same release of freeipa (3.3.2-1) fixes bug 996716 in fc19 and not in fc20? I'm currently testing newest available rpm on fc20 and this bug still occurs. I've found that bug 1008306 [3] is more relevant in this case than one in FreeIPA. I also have newest 389-ds-base (389-ds-base-1.3.2.0-1.fc20.x86_64) package released for fc20 and nothing has changed as I mentioned above. I'm trying to make sens out of this bug rpm # spaghetti but it's not so easy. [1] https://admin.fedoraproject.org/updates/FEDORA-2013-18371/freeipa-3.3.2-1.fc19 [2] https://admin.fedoraproject.org/updates/FEDORA-2013-18542/freeipa-3.3.2-1.fc20 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1008306 I think this is because the fixed 389-ds package hasn't been built yet for F-20. The fix for BZ 1008306 is in the 389-ds-base-1.3.2.0-1.fc20.x86_64 build. Are we sure that the issue that is occuring here is related to tmpfiles.d not creating /var/lock/dirsrv before dirsrv is started? I just fired up a F20 VM, and there is definitely still a problem here in 389-ds-base. I see the following in my tmpfiles.d config for dirsrv: -- d /var/run/dirsrv 0770 nobody nobody d /var/lock/dirsrv 0770 nobody nobody d /var/lock/dirsrv/slapd-example 0770 nobody nobody -- We'll figure out what's going on and get a respin of 389-ds-base out. This appears to be a simple issue in 389-ds-base. We will get a new builds in Koji on F19 and F20 tomorrow. Here's a new build for F20 that should resolve this: https://admin.fedoraproject.org/updates/389-ds-base-1.3.2.2-1.fc20 Please test it and provide karma. Thanks, -NGK https://fedorahosted.org/389/ticket/47513 Thanks, -NGK I think the difference in bugs fixed in bohdi was an oversight. The F-19 bugs fixed upstream should have been included in the F-20 bohdi (and probably the other way around too). The changes made to IPA for BZ 996716 are basically just cosmetic, to be in compliance with packaging guidelines. rog ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
