Created attachment 1161525 [details] Settings continue to show 'database' after saving LDAP settings in the UI Description of problem: When selecting LDAP as the authentication method the setting is not saved and 'database' remains. Version-Release number of selected component (if applicable): 5.6.0.7-beta2.6.20160516171555_b1be31f How reproducible: All the time Steps to Reproduce: 1. Select LDAP from the Configuration->Authentication Mode drop down. 2. Populate fields with valid details and click the Save button. 3. Navigate to the advanced tab and verify none of the LDAP settings are displayed. Actual results: LDAP verification from the UI appears to work, but none of the settings are actually saved. Expected results: The mode should go to ldap, and the ldap settings should be stored. Additional info: See attached screenshots.
Created attachment 1161526 [details] Logs reflect nil LDAP values
Created attachment 1161527 [details] LDAP validation "appears" to work
David La Motta , I changed the auth mode to ldap and settings saved correctly. screenshot# ldap_advanced_saved appears to be UI glitch on your environment? Can you try to refresh and save the ldap settings again in the UI?
Created attachment 1161546 [details] ldap_advanced_saved
David, I was successfully able to save LDAP settings locally. Can you please provide an access to your appliance where i can recreate this issue, Also let me know which browser/version are using. Thanks, ~Harpreet
Created attachment 1162174 [details] Bug shown with FF
Chrome is 50.0.2661.94 (64-bit) and Firefox is 46.0.1 You can reach the appliance at https://172.74.102.229:8443/ (admin/smartvm) but please let me know when you are done so I can remove access.
Jason, Do you know if issue reported above could have been fixed by https://github.com/ManageIQ/manageiq/pull/8908. Looks like LDAP authentication settings are getting saved but not being displayed on Advanced settings tab. ~Harpreet
Possibly? David, can you try with the RC release?
David, Yes that link is correct, Beta3 & RC 1 are same. Can you please give that a try with RC release. I tired to access your appliance using FF & Chrome from my machine, Chrome Version 51.0.2704.63 and FF 42.0, the only issue i notice is that Advanced tab screen is not reflecting the recent changes that were made on Authentication tab. I was successfully able to save LDAP authentication settings, even tho validation failed when i pressed validate button on both browsers respectively but save button worked from both browsers. Let me know if re-testing this with rc release fixes the issue. Thanks, ~Harpreet
Harpreet- I don't know what version you are using, but I continue to see the same behavior in RC1--please see the CF41RC1. It is more than cosmetic; the logs indicate no ldap hostname, no bind dn, no base dn, or anything when trying to connect to LDAP. The UI "thinks" validation succeeded, which is really throwing me off. I would expect that to fail as well. Regardless, as you can see in the CF41RC1 video, getting the groups fails because it can't establish a connection to the server. I tried another ldapsearch test from the appliance's CLI, so I know AD is responding correctly to the bind user.
Sorry, the video was too big to attach. Please use the following link: https://drive.google.com/a/redhat.com/file/d/0B8nt6xXM19TfYW5tOWFzUHVyQ2M/view?usp=sharing Also, here is the ldapsearch output: [root@cf41 ~]# ldapsearch -x -LLL -h dc.davidlamotta.com -D bind -w RedHat123 -b "cn=CloudForms Admin,cn=Users,dc=davidlamotta,dc=com" -s sub "(objectClass=user)" dn: CN=CloudForms Admin,CN=Users,DC=davidlamotta,DC=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: CloudForms Admin sn: Admin givenName: CloudForms distinguishedName: CN=CloudForms Admin,CN=Users,DC=davidlamotta,DC=com instanceType: 4 whenCreated: 20160525070306.0Z whenChanged: 20160525173126.0Z displayName: CloudForms Admin uSNCreated: 24709 memberOf: CN=Domain Users,CN=Users,DC=davidlamotta,DC=com memberOf: CN=Administrators,CN=Builtin,DC=davidlamotta,DC=com uSNChanged: 24788 name: CloudForms Admin objectGUID:: 7mLr6YztRke+4jE0vXbV5A== userAccountControl: 66048 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 131086675463614679 pwdLastSet: 131086695647928846 primaryGroupID: 1116 objectSid:: AQUAAAAAAAUVAAAAMnoV7YiFT9Wv4+NPZQQAAA== adminCount: 1 accountExpires: 9223372036854775807 logonCount: 4 sAMAccountName: cf-admin sAMAccountType: 805306368 userPrincipalName: cf-admin objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=davidlamotta,DC=com dSCorePropagationData: 20160525173126.0Z dSCorePropagationData: 20160525070306.0Z dSCorePropagationData: 16010101000000.0Z lastLogonTimestamp: 131086667981396447
David, Can you upload your production & evm logs. Thanks, ~Harpreet
Created attachment 1162539 [details] evm.log
Created attachment 1162540 [details] production.log
Martin, I am seeing some csp_report transactions in the production.log, any idea what could be causing those, not sure if those are causing the weird behavior on David's appliance. [----] I, [2016-05-27T15:22:59.759735 #15042:de4144] INFO -- : Started POST "/dashboard/csp_report" for 127.0.0.1 at 2016-05-27 15:22:59 -0400 [----] I, [2016-05-27T15:22:59.761166 #15042:de4144] INFO -- : Processing by DashboardController#csp_report as HTML [----] I, [2016-05-27T15:22:59.761294 #15042:de4144] INFO -- : Parameters: {"csp-report"=>{"blocked-uri"=>"data", "document-uri"=>"https://cf41.davidlamotta.com/ops/explorer", "original-policy"=>"default-src https://cf41.davidlamotta.com; connect-src https://cf41.davidlamotta.com; frame-src https://cf41.davidlamotta.com; script-src 'unsafe-eval' 'unsafe-inline' https://cf41.davidlamotta.com; style-src 'unsafe-inline' https://cf41.davidlamotta.com; report-uri https://cf41.davidlamotta.com/dashboard/csp_report", "referrer"=>"https://cf41.davidlamotta.com/support?support_tab=about", "violated-directive"=>"default-src https://cf41.davidlamotta.com"}, "dashboard"=>{"csp-report"=>{"blocked-uri"=>"data", "document-uri"=>"https://cf41.davidlamotta.com/ops/explorer", "original-policy"=>"default-src https://cf41.davidlamotta.com; connect-src https://cf41.davidlamotta.com; frame-src https://cf41.davidlamotta.com; script-src 'unsafe-eval' 'unsafe-inline' https://cf41.davidlamotta.com; style-src 'unsafe-inline' https://cf41.davidlamotta.com; report-uri https://cf41.davidlamotta.com/dashboard/csp_report", "referrer"=>"https://cf41.davidlamotta.com/support?support_tab=about", "violated-directive"=>"default-src https://cf41.davidlamotta.com"}}} Thanks, ~Harpreet
The CSP report seems to be related to 'About' page so it does not seem related to the issue. I cannot reach the appliance at https://172.74.102.229:8443/ -- is it running somewhere? Can you run it for me, please? Trying to reproduce the problem elsewhere w/o success so far.
(In reply to Martin Povolny from comment #20) > The CSP report seems to be related to 'About' page so it does not seem > related to the issue. > > I cannot reach the appliance at https://172.74.102.229:8443/ -- is it > running somewhere? Can you run it for me, please? > > Trying to reproduce the problem elsewhere w/o success so far. Martin, the appliance is running in my home lab so I don't leave access open. Please check now and let me know when you are done so I can remove access.
https://github.com/ManageIQ/manageiq/pull/9041
Sounds like the issue is that the evm_server.rb caches the configuration, and since we fork workers, when the child process is spawned it gets an "old" configuration. The likely fix is to just clear the cache before spawning a worker.
I cannot reproduce this locally. I tried with all three of the following. - rails s - MIQ_SPARTAN=minimal rake evm:start - rake evm:start At no time do I ever get a bad value. It always saves to the database, and I always see the right value reflected in Advanced Settings immediately. Note that there is a bit of a trick on the eyes. If you switch back to "database", the values for ldaphost and ldapport are still present, but that is not necessarily a bug. mode *is* changed to "database", and technically that is all that matters. I am going to try with an appliance.
Milan said this is no longer happening in 5.6.0.8 (that's RC1, or beta3...same thing). David, can you verify again with the latest?
I reproduced on the 5.6.0.8 appliance. Can't understand why...looking into it.
Jason, it really seems to only happen the first time I run a fresh appliance. I have a script to download and deploy nightly on KVM : https://github.com/martinpovolny/manageiq-utils/blob/master/github-fetch-pullrequest With this I got the issue every time. But never was I able to reproduce the issue any other way in any other environment and I did try.
Btw Milan was wrong or the thing did not happen in his env. But the video David created shows that he uses 5.6.0.8 and so did I.
> Jason, it really seems to only happen the first time I run a fresh appliance. Yes that is exactly what I'm seeing. Specifically the first time evm_server starts. As soon as you restart it, it's completely fine, and the UI reacts perfectly. Note that I can't seem to set level to debug either, so it's not just the LDAP settings.
(In reply to Jason Frey from comment #30) > Milan said this is no longer happening in 5.6.0.8 (that's RC1, or > beta3...same thing). David, can you verify again with the latest? Hi Jason, just to close on the question addressed to me--I did try the latest (it's in the video in the Google Drive) as Milan points out in comment 33.
Jason, Not sure if this is also caused by same issue, looks like that to me: https://bugzilla.redhat.com/show_bug.cgi?id=1341290 ~Harpreet
https://github.com/ManageIQ/manageiq/pull/9068
Harpreet. Yes it looks like this may fix that one as well. I can double check if it's not merged by then.
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/769336d310893dd4bf39ad1c76c415da7716d77c commit 769336d310893dd4bf39ad1c76c415da7716d77c Author: Jason Frey <jfrey> AuthorDate: Tue May 31 18:28:06 2016 -0400 Commit: Jason Frey <jfrey> CommitDate: Tue May 31 18:28:06 2016 -0400 Reset the Settings after we seed MiqServer Upon boot on a fresh database, the Settings object contains a DatabaseSource that refers to a nil MiqServer. This is intentional as it allows accessing the Settings before a MiqServer has been created, in particular during intializers and in some rake tasks that need the Rails environment. However, when the server starts and creates the MiqServer record during .seed, the Settings is still pointing to the nil MiqServer record. This creates an inconsistency where the server (and thus all workers forked from it) do not know about changes to the MiqServer object. Changing settings in the UI will write the SettingsChange records to the database attached to the correct MiqServer object, but since the Settings object can't see them, it doesn't know to update. This commit fixes all problems where config changes are made on the very first server boot. One particular problem that is strange is if an MiqServer is moved into another Zone. The zone value is normally written into the settings. However, since the server doesn't see the change reflected in the Settings, it thinks the user modified the Advanced Settings to put the original server back, so after about 20 seconds, the server moves back to the original zone. This problem is fixed by this commit https://bugzilla.redhat.com/show_bug.cgi?id=1339702 https://bugzilla.redhat.com/show_bug.cgi?id=1328201 app/models/miq_server.rb | 1 + 1 file changed, 1 insertion(+)
*** Bug 1341290 has been marked as a duplicate of this bug. ***
Will be in the next build.
verified and looks good in 5.6.0.10-rc2.1.20160607103248_d06c141. refer the screenshot: ldap_advanced_settings
https://github.com/ManageIQ/manageiq/pull/9133
*** Bug 1342661 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:1348