[Freeipa-users] problems with ipa server no longer responding to ldap
Hello there.
My setup is that i have five ipa servers. 2 in one location (alder,
auth-syd2), 2 in anouther location (auth-wlg, auth-wlg2), and one in yet
anouther location (waffle) which is reached over a long,
mostly-but-possibly-notably-not-entirely reliable vpn connection.
I'm having an issue with an IPA server falling over. By 'falling over' what
i mean is that it no longer responds to ldap queries (although the tcp port
389 is still open via nmap). When i run 'systemctl ipa stop' the command
never seems to return, so up to now the only fix i have it to reboot that
server.
All machines are centos 7. All are using
ipa-server-4.2.0-15.0.1.el7.centos.18.x86_64. Replication occurs between:
alder<->auth-wlg, alder<->syd2, auth-wlg<->auth-wlg2, and
auth-wlg<->waffle, possibly notably *not* between alder and waffle directly.
The problem of ldap being unavailable occurs on alder only; the other ipa
servers seem to be reliable. Unfortunately, alder is also our most used
server.
The error logs off alder look like this: http://pastebin.com/TxCVjWTe
with reboot done at around 19:55
I did notice upon investigating / googling the errors in this log -
starting with the attr_replace (nsslapd-referral) one, that on my servers
this ldap query:
ldapsearch -ZZ -h alder.blah.com -D "cn=Directory Manager" -W -b "o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
returns results similar to this:
nsDS5ReplicaId: 96
nsds50ruv: {replicageneration} 5733d4280060
nsds50ruv: {replica 96 ldap://alder.blah.com:389} 5733d4740060 57
nsds50ruv: {replica 91 ldap://auth-syd2.blah.com:389} 576337b90004005b000
nsds50ruv: {replica 97 ldap://auth-wlg.blah.com:389} 5733d49a0061
nsds50ruv: {replica 1095 ldap://auth-wlg2.blah.com:389} 574fa5b004470
nsds50ruv: {replica 1090 ldap://waffle.bsh.blah.com:389} 576b1add0442
nsds50ruv: {replica 1085 ldap://waffle.bsh.blah.com:389} 576b22f1043d
i.e: waffle is listed twice. If i run that ldap query on waffle though, i
get no results at all (but the command does at least return). - so i dont
know waffle's nsDS5ReplicaId at the moment. I understand once i know that i
can clean-ruv the other id off the other ipa servers? I don't *think* any
of this is related to my original issue above though, but it might be a
smoking gun, i don't know - just mentioning it in case.
At the moment i've not got a lot to go on. Has anyone else seen errors like
those in the paste bin, or might know where to look for more useful info ?
Possibly also worth noting that alder, and auth-syd2 are AWS ec2 instances.
The rest are vm's on site(s).
--
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-users Digest, Vol 97, Issue 97
> > > Date: Tue, 23 Aug 2016 10:20:32 -0400 > From: Rob Crittenden <rcrit...@redhat.com> > To: "siology.io" <siology...@gmail.com>,freeipa-users > <freeipa-users@redhat.com> > Subject: Re: [Freeipa-users] private user groups for existing users > Message-ID: <57bc5bb0.7090...@redhat.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > siology.io wrote: > > i've noticed that some of my users (imported from openldap) don't have > > personal user groups, but the new ones that i make within freeipa do. > > > > Is there a way of marking the existing accounts such that they get user > > groups made for them ? I couldn't seem to see the groups that IPA is > > making in the LDAP output so it must be creating them via some other > means. > > > > Is there some sort of 'ipa user create-private-group ' command ? > > > > The only work around i have is to make hundreds of fake private groups > > by making normal user groups each with one user, which'll clutter the UI > > up with pointless groups. > > Yeah, there is a ticket open to allow UPG creation in migration but as > you see, it isn't done yet. > > There is no documented way to do it but it should be possible with > ldapmodify. I forget the exact ordering but I'd probably do the group > first, then the user. In theory you can convert a group to be managed by > adding: > > objectclass: mepmanagedentry > mepmanagedby: uid=,cn=users,cn=accounts,$SUFFIX > > And removing: > > objectclass: groupofnames > objectclass: nestedgroup > > You also need to update the user with: > > objectclass: meporiginentry > mepmanagedentry: cn=,cn=groups,cn=accounts,$SUFFIX > > Just don't do this with any groups that have members. > > Definitely worth experimenting on a non-production installation. > > rob > I'm not too hot with ldapmodify at all. So far i've got: http://pastebin.com/MDE1SN0F but i dont think that's working for me. -- 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] private user groups for existing users
i've noticed that some of my users (imported from openldap) don't have personal user groups, but the new ones that i make within freeipa do. Is there a way of marking the existing accounts such that they get user groups made for them ? I couldn't seem to see the groups that IPA is making in the LDAP output so it must be creating them via some other means. Is there some sort of 'ipa user create-private-group ' command ? The only work around i have is to make hundreds of fake private groups by making normal user groups each with one user, which'll clutter the UI up with pointless groups. -- 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] migration user passwords from openldap to freeipa
ok, after looking again at this, i've found that even with the admin users it's not working how i'd like. With the admin user what seems to be happening is that the users after import *must* go to the /ipa/migration/ url and then enter their password. Although it does now let them login unlike before (so i guess before i hadnt used the admin ldap user to import from and hence didnt have permissions as you suggested) However, i'd really like to avoid that because we've got hundreds of users, mostly external to the company in different timezones, and coordinating getting people to go to the portal (and making it available to the internet!) sounds like a nightmare. These users don't need kerberos credentials (afaik) as i just want them to be able to bind against the freeipa ldap server. I'm happy for users that need kerberos to have to go to the migration page. Is there any way to avoid a user needing to go to the migration page after importing the user ? On 27 April 2016 at 19:45, David Kreitschmann <da...@kreitschmann.de> wrote: > Are you sure that your bind dn has read access userPassword? A default > OpenLDAP installation usually has a admin user. > Gosa ACLs are only applied when using the web interface, they are not used > for direct access via LDAP. > > > > Am 27.04.2016 um 03:43 schrieb siology.io <siology...@gmail.com>: > > > > I'm having issues migrating from an openldap directory (which has gosa > schema) to freeipa. > > > > To migrate i'm doing (and yes, i know); > > > > ipa migrate-ds ldap://old.server.com:389 --bind-dn > "cn=my_user,ou=people,dc=domain,dc=com" --group-objectclass=posixGroup > --user-objectclass=inetOrgPerson --group-overwrite-gid > --user-ignore-objectclass=gosaAccount > --user-ignore-objectclass=gosaMailAccount > --user-ignore-attribute=gosaMailDeliveryMode > --user-ignore-attribute=gosaMailServer > --user-ignore-attribute=gosaSpamSortLevel > --user-ignore-attribute=gosaSpamMailbox > --user-ignore-objectclass=sshaccount --user-ignore-objectclass=gosaacl > --user-ignore-attribute=sshpublickey > --user-ignore-attribute=sambaLMPassword > --user-ignore-attribute=sambaBadPasswordTime > --user-ignore-attribute=gosaaclentry > --user-ignore-attribute=sambaBadPasswordCount > --user-ignore-attribute=sambaNTPassword > --user-ignore-attribute=sambaPwdLastSet > > > > Which seems to work to import all those users which have posix settings > set, however i have two problems: > > > > - Am i right in thinking there's no way to auto-assign a gid/uid/home > dir for the non-posix users at migration time ? That's not a deal breaker > per se, but i'd need to spin up a new copy of the old ldap and then add > those attributes to every user, then migrate to ipa from that source, which > is a real pain. > > > > - The migration seems to be successful for the users that do have posix > attributes, and ends with: > > > > Passwords have been migrated in pre-hashed format. > > IPA is unable to generate Kerberos keys unless provided > > with clear text passwords. All migrated users need to > > login at https://your.domain/ipa/migration/ before they > > can use their Kerberos accounts. > > > > ...but i'm unable to login to that page as any of my migrated users, or > bind as them with ldapsearch. It seems like the passwords were not migrated > ? > > > > Because 90% of my ~350 users are only going to be using freeipa insomuch > as using services which are making use of the ipa server's ldap i was > hoping that i wouldn't need to make kerberos tickets for those users, and > hence avoid needing every user to login to the migration page. At the > moment however i'm not able to get any migrated users at all to be able to > bind to ldap or login to that page. > > > > Any tips or gotchas i should know ? I've no idea how to begin debugging > this. > > -- > > 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-client password authentication failed
That plugins.py file does exist, but it's totally empty. And yes, all i get on the browser is an empty white screen window, On 30 April 2016 at 02:20, Petr Vobornik <pvobo...@redhat.com> wrote: > On 04/29/2016 12:44 AM, siology.io wrote: > > On a clean centos 7 VM, after installation of ipa-server browsing to the > ipa web > > UI gets me in the httpd error_logs: > > > > [Thu Apr 28 18:41:11.826134 2016] [:error] [pid 10162] [remote > 10.0.4.10:244 > > <http://10.0.4.10:244>] mod_wsgi (pid=10162): Target WSGI script > > '/usr/share/ipa/wsgi/plugins.py' does not contain WSGI application > 'application'. > > > > Is this a known issue ? I didn't get much out of google. > > > > I don't see this issue on RHEL 7.2 nor FreeIPA 4.3.x on F23. Could you > paste here content of your /usr/share/ipa/wsgi/plugins.py file? > > Does it prevent to load Web UI? > -- > Petr Vobornik > -- 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-client password authentication failed
On a clean centos 7 VM, after installation of ipa-server browsing to the ipa web UI gets me in the httpd error_logs: [Thu Apr 28 18:41:11.826134 2016] [:error] [pid 10162] [remote 10.0.4.10:244] mod_wsgi (pid=10162): Target WSGI script '/usr/share/ipa/wsgi/plugins.py' does not contain WSGI application 'application'. Is this a known issue ? I didn't get much out of google. -- 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] migration user passwords from openldap to freeipa
I'm having issues migrating from an openldap directory (which has gosa schema) to freeipa. To migrate i'm doing (and yes, i know); ipa migrate-ds ldap://old.server.com:389 --bind-dn "cn=my_user,ou=people,dc=domain,dc=com" --group-objectclass=posixGroup --user-objectclass=inetOrgPerson --group-overwrite-gid --user-ignore-objectclass=gosaAccount --user-ignore-objectclass=gosaMailAccount --user-ignore-attribute=gosaMailDeliveryMode --user-ignore-attribute=gosaMailServer --user-ignore-attribute=gosaSpamSortLevel --user-ignore-attribute=gosaSpamMailbox --user-ignore-objectclass=sshaccount --user-ignore-objectclass=gosaacl --user-ignore-attribute=sshpublickey --user-ignore-attribute=sambaLMPassword --user-ignore-attribute=sambaBadPasswordTime --user-ignore-attribute=gosaaclentry --user-ignore-attribute=sambaBadPasswordCount --user-ignore-attribute=sambaNTPassword --user-ignore-attribute=sambaPwdLastSet Which seems to work to import all those users which have posix settings set, however i have two problems: - Am i right in thinking there's no way to auto-assign a gid/uid/home dir for the non-posix users at migration time ? That's not a deal breaker per se, but i'd need to spin up a new copy of the old ldap and then add those attributes to every user, then migrate to ipa from that source, which is a real pain. - The migration seems to be successful for the users that do have posix attributes, and ends with: Passwords have been migrated in pre-hashed format. IPA is unable to generate Kerberos keys unless provided with clear text passwords. All migrated users need to login at https://your.domain/ipa/migration/ before they can use their Kerberos accounts. ...but i'm unable to login to that page as any of my migrated users, or bind as them with ldapsearch. It seems like the passwords were not migrated ? Because 90% of my ~350 users are only going to be using freeipa insomuch as using services which are making use of the ipa server's ldap i was hoping that i wouldn't need to make kerberos tickets for those users, and hence avoid needing every user to login to the migration page. At the moment however i'm not able to get any migrated users at all to be able to bind to ldap or login to that page. Any tips or gotchas i should know ? I've no idea how to begin debugging this. -- 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] ui timeout
On 11/27/2013 12:51 AM, Dmitri Pal wrote: On 11/26/2013 05:15 PM, siology.io wrote: for what it's worth, kinit on the command line of the ipa server works just fine, and detects the realm ok. OK then let us rule out DNS for a moment. Have you checked the KDC log to see whether the authentication actually occurred? If kinit works, I suspect it works too but worth checking. May be there are some problems with memcached after the form based authentication to cache the authentication. KDC log would show whether the kinit and follow up service ticket request for LDAP access actually occurred.This is a good suggestion. Please see if ipa_memcached daemon is running, therewas a glitch in one of the upgrades in the past which did not configure itcorrectly. If it is not, I can advise how to fix it.Martin ok. this problem is like a zombie. it just keeps coming ! I *think* i got this working back in november, but i'm not 100% sure because on discovering the issue is still there now on at least one of my replicas and then going to turn on debugging mode, i found it was already on ! To answer your query from back then though; yes memcached is running and seems to be ok. i tried restarting it (as part of an ipa restart) and i still see timeouts on login after entering my authentication details. Oddly though, going back to the head of this thread i claimed i was having the issues on my master and replica IPA servers. That isn't the case now at least - its just on the replica, so i must have fixed it somehow ?! or it disappeared ? Annoying as hell though, either way. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] ui timeout issue
I'm seeing an issue with logging into the web UI of ipa. I've been using IPA for 6 months or so in production, and all has been well so far. The last thing i did in terms of IPA was run ipa-dns-install, which completed successfully, but i suspect this issue occured before that i never noticed as it's been a few weeks since i used the UI. I typically check the login page works and ldapsearch works after upgrades, but in this instance the login box is presented, and after entering the credentials it sits doing nothing for a while, then times out with 'internal server error' The only useful log i've managed to find is in /var/log/httpd/error_log [Wed Nov 27 08:41:47 2013] [error] [client (redacted)] Script timed out before returning headers: wsgi.py, referer: https://(redacted)/ipa/ui/ I'm seeing this behaviour on both my master and replica, but they are both identical in terms of package versions and such, so it may not be significant. My system versions: Centos 6.4 x64 ipa-python-3.0.0-26.el6_4.4.x86_64 ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-1.9.2-82.10.el6_4.x86_64 libipa_hbac-python-1.9.2-82.10.el6_4.x86_64 ipa-client-3.0.0-26.el6_4.4.x86_64 ipa-server-3.0.0-26.el6_4.4.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-26.el6_4.4.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch bind-dyndb-ldap-2.3-2.el6_4.1.x86_64 bind-9.8.2-0.17.rc1.el6_4.6.x86_64 which are (afaik) all latest for centos 6.4 Oddly, i'm not seeing this behaviour in my virtualbox / vagrant IPA testbed, which has identical version numbers, and wsgi.py in /usr/share/ipa has identical md5sum. Not really sure how to approach debugging this further. Any ideas ? Has anyone else seen this happen ? The ldapsearch, bind dns and everything else seem operational - just the GUI is out of action. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ui timeout issue
On 27 November 2013 10:21, Dmitri Pal d...@redhat.com wrote: On 11/26/2013 03:37 PM, siology.io wrote: I'm seeing an issue with logging into the web UI of ipa. I've been using IPA for 6 months or so in production, and all has been well so far. The last thing i did in terms of IPA was run ipa-dns-install, which completed successfully, but i suspect this issue occured before that i never noticed as it's been a few weeks since i used the UI. I typically check the login page works and ldapsearch works after upgrades, but in this instance the login box is presented, and after entering the credentials it sits doing nothing for a while, then times out with 'internal server error' The only useful log i've managed to find is in /var/log/httpd/error_log [Wed Nov 27 08:41:47 2013] [error] [client (redacted)] Script timed out before returning headers: wsgi.py, referer: https://(redacted)/ipa/ui/ What happens before that in the log? Any DNS lookup or some other lookup? doesn't appear so, no. what makes you suspect that ? I never got as far as doing the ipa-dns-install on the replica. I did it on the master, then went to login and got this issue. It may well be that it (the UI) was broken previously. I couldn't work out how to remove the ipa-dns-install to find out if it magically resumes working though. I'm seeing this behaviour on both my master and replica, but they are both identical in terms of package versions and such, so it may not be significant. My system versions: Centos 6.4 x64 ipa-python-3.0.0-26.el6_4.4.x86_64 ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-1.9.2-82.10.el6_4.x86_64 libipa_hbac-python-1.9.2-82.10.el6_4.x86_64 ipa-client-3.0.0-26.el6_4.4.x86_64 ipa-server-3.0.0-26.el6_4.4.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-26.el6_4.4.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch bind-dyndb-ldap-2.3-2.el6_4.1.x86_64 bind-9.8.2-0.17.rc1.el6_4.6.x86_64 which are (afaik) all latest for centos 6.4 Oddly, i'm not seeing this behaviour in my virtualbox / vagrant IPA testbed, which has identical version numbers, and wsgi.py in /usr/share/ipa has identical md5sum. Not really sure how to approach debugging this further. Any ideas ? Has anyone else seen this happen ? The ldapsearch, bind dns and everything else seem operational - just the GUI is out of action. ___ Freeipa-users mailing listFreeipa-users@redhat.comhttps://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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ui timeout issue
yeah maybe. I do see from the install log of the ipa-dns-install that it changed the /etc/resolv.conf to point to its own ip - which seems a little odd (and unwanted, more importantly). I've changed that back to how it should be and restarted ipa but still nothing. There's no other KDC in the environment that i'm aware of. Certainly, the dns i was using only have the one set of SRV records for ldap and kdc. The bit that puzzles me is how/why that would have affected the replica server also. I asume it's copied the ldap dns data to the replica, but i never installed bind there or bind-dyndb-ldap, or anything else - so i'd expect that to be unaffected but it's also broken now. :-( On 27 November 2013 10:47, Dmitri Pal d...@redhat.com wrote: On 11/26/2013 04:32 PM, siology.io wrote: On 27 November 2013 10:21, Dmitri Pal d...@redhat.com wrote: On 11/26/2013 03:37 PM, siology.io wrote: I'm seeing an issue with logging into the web UI of ipa. I've been using IPA for 6 months or so in production, and all has been well so far. The last thing i did in terms of IPA was run ipa-dns-install, which completed successfully, but i suspect this issue occured before that i never noticed as it's been a few weeks since i used the UI. I typically check the login page works and ldapsearch works after upgrades, but in this instance the login box is presented, and after entering the credentials it sits doing nothing for a while, then times out with 'internal server error' The only useful log i've managed to find is in /var/log/httpd/error_log [Wed Nov 27 08:41:47 2013] [error] [client (redacted)] Script timed out before returning headers: wsgi.py, referer: https://(redacted)/ipa/ui/ What happens before that in the log? Any DNS lookup or some other lookup? doesn't appear so, no. what makes you suspect that ? I never got as far as doing the ipa-dns-install on the replica. I did it on the master, then went to login and got this issue. It may well be that it (the UI) was broken previously. I couldn't work out how to remove the ipa-dns-install to find out if it magically resumes working though. A pure speculation: If the UI presents you the form and you fill it then you are definitely talking to the server. When you submit the form the server tries to do kinit on your behalf. It might not be able to determine where its KDC because the DNS configuration is broken in some way and it is now looking at the wrong KDC (may be AD KDC or there is a lack of the server records at all for some reason). I'm seeing this behaviour on both my master and replica, but they are both identical in terms of package versions and such, so it may not be significant. My system versions: Centos 6.4 x64 ipa-python-3.0.0-26.el6_4.4.x86_64 ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-1.9.2-82.10.el6_4.x86_64 libipa_hbac-python-1.9.2-82.10.el6_4.x86_64 ipa-client-3.0.0-26.el6_4.4.x86_64 ipa-server-3.0.0-26.el6_4.4.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-26.el6_4.4.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch bind-dyndb-ldap-2.3-2.el6_4.1.x86_64 bind-9.8.2-0.17.rc1.el6_4.6.x86_64 which are (afaik) all latest for centos 6.4 Oddly, i'm not seeing this behaviour in my virtualbox / vagrant IPA testbed, which has identical version numbers, and wsgi.py in /usr/share/ipa has identical md5sum. Not really sure how to approach debugging this further. Any ideas ? Has anyone else seen this happen ? The ldapsearch, bind dns and everything else seem operational - just the GUI is out of action. ___ Freeipa-users mailing listFreeipa-users@redhat.comhttps://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 ___ Freeipa-users mailing listFreeipa-users@redhat.comhttps://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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ui timeout issue
for what it's worth, kinit on the command line of the ipa server works just fine, and detects the realm ok. On 27 November 2013 11:00, siology.io siology...@gmail.com wrote: yeah maybe. I do see from the install log of the ipa-dns-install that it changed the /etc/resolv.conf to point to its own ip - which seems a little odd (and unwanted, more importantly). I've changed that back to how it should be and restarted ipa but still nothing. There's no other KDC in the environment that i'm aware of. Certainly, the dns i was using only have the one set of SRV records for ldap and kdc. The bit that puzzles me is how/why that would have affected the replica server also. I asume it's copied the ldap dns data to the replica, but i never installed bind there or bind-dyndb-ldap, or anything else - so i'd expect that to be unaffected but it's also broken now. :-( On 27 November 2013 10:47, Dmitri Pal d...@redhat.com wrote: On 11/26/2013 04:32 PM, siology.io wrote: On 27 November 2013 10:21, Dmitri Pal d...@redhat.com wrote: On 11/26/2013 03:37 PM, siology.io wrote: I'm seeing an issue with logging into the web UI of ipa. I've been using IPA for 6 months or so in production, and all has been well so far. The last thing i did in terms of IPA was run ipa-dns-install, which completed successfully, but i suspect this issue occured before that i never noticed as it's been a few weeks since i used the UI. I typically check the login page works and ldapsearch works after upgrades, but in this instance the login box is presented, and after entering the credentials it sits doing nothing for a while, then times out with 'internal server error' The only useful log i've managed to find is in /var/log/httpd/error_log [Wed Nov 27 08:41:47 2013] [error] [client (redacted)] Script timed out before returning headers: wsgi.py, referer: https://(redacted)/ipa/ui/ What happens before that in the log? Any DNS lookup or some other lookup? doesn't appear so, no. what makes you suspect that ? I never got as far as doing the ipa-dns-install on the replica. I did it on the master, then went to login and got this issue. It may well be that it (the UI) was broken previously. I couldn't work out how to remove the ipa-dns-install to find out if it magically resumes working though. A pure speculation: If the UI presents you the form and you fill it then you are definitely talking to the server. When you submit the form the server tries to do kinit on your behalf. It might not be able to determine where its KDC because the DNS configuration is broken in some way and it is now looking at the wrong KDC (may be AD KDC or there is a lack of the server records at all for some reason). I'm seeing this behaviour on both my master and replica, but they are both identical in terms of package versions and such, so it may not be significant. My system versions: Centos 6.4 x64 ipa-python-3.0.0-26.el6_4.4.x86_64 ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-1.9.2-82.10.el6_4.x86_64 libipa_hbac-python-1.9.2-82.10.el6_4.x86_64 ipa-client-3.0.0-26.el6_4.4.x86_64 ipa-server-3.0.0-26.el6_4.4.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-26.el6_4.4.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch bind-dyndb-ldap-2.3-2.el6_4.1.x86_64 bind-9.8.2-0.17.rc1.el6_4.6.x86_64 which are (afaik) all latest for centos 6.4 Oddly, i'm not seeing this behaviour in my virtualbox / vagrant IPA testbed, which has identical version numbers, and wsgi.py in /usr/share/ipa has identical md5sum. Not really sure how to approach debugging this further. Any ideas ? Has anyone else seen this happen ? The ldapsearch, bind dns and everything else seem operational - just the GUI is out of action. ___ Freeipa-users mailing listFreeipa-users@redhat.comhttps://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 ___ Freeipa-users mailing listFreeipa-users@redhat.comhttps://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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com
