Hi, there was bug in time zone handling in aaa-jdbc which was affecting only installation of hosts in time zones west of Greenwich (negative time zone offset). The fix is already merged [1] and will be provided in new oVirt release probably next week. At the moment you can fix the issue by: 1. Install ovirt-engine-extension-aaa-jdbc 1.0.0-2 package for your platform [2], [3], [4] 2. Fix admin account valid from date: ovirt-aaa-jdbc-tool user edit admin --account-valid-from="2015-10-01 00:00:00Z" Let me know if there are any other issues. Thanks Martin Perina [1] https://gerrit.ovirt.org/47022 [2] http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-jdbc_3.6_create-rpms... [3] http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-jdbc_3.6_create-rpms... [4] http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-jdbc_3.6_create-rpms... ----- Original Message -----
From: "Christopher Miersma" <miersma@ualberta.ca> To: "Ondra Machacek" <omachace@redhat.com>, users@ovirt.org Sent: Thursday, October 8, 2015 6:51:27 PM Subject: Re: [ovirt-users] Admin <at> internal inlog problems with clean install 3.6RC
I had to rebuild to test something else, and I ran into the same issue again. I successfully ran ovirt-aaa-jdbc-tool user edit admin --account-valid-to="2100-01-01 00:00:00Z", but id didn't resolve the issue. Here is the out put from the database:
engine=# select id,name,valid_to,password_valid_to from aaa_jdbc.users; id | name | valid_to | password_valid_to ----+-------+------------------------+------------------------ 1 | admin | 2100-01-01 00:00:00-07 | 2215-08-21 16:31:18-06 (1 row)
engine=# select * from aaa_jdbc.users; id | uuid | name | password | password_valid_to | login_allowed | nopassw d | disabled | unlock_time | last_successful_login | last_unsuccessful_login | consecutive_failures | valid_from | valid_to ----+--------------------------------------+-------+---------------------------------------------------------------------------------------------------------------------+------------------------+---------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------- --+----------+---------------------+------------------------+----------------------------+----------------------+----------------------------+------------------------
1 | 300abd4f-28d3-41a0-b235-61182be68f94 | admin | 1|PBKDF2WithHmacSHA1|VwFtVvQ/9XJNiPOSRF5f8fKaXvCFpFHTUjfrAt5g=|2000|BVWhUlrd8fjec8nmbL3zVawCZ3+fsS1wjyllWyro= | 2215-08-21 16:31:18-06 | 111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 | 0 | 0 | 1970-01-01 00:00:00 | 1970-01-01 00:00:00-07 | 2015-10-08 16:36:40.279-06 | 2 | 2015-10-08 16:31:17.267-06 | 2100-01-01 00:00:00-07 (1 row)
engine=#
I also tired setting the field full of ones to just 1 and 0, but without success.
On 10/05/2015 12:52 PM, Christopher Miersma wrote:
Hi,
Thanks for the suggestion. I had used this command already: $ ovirt-aaa-jdbc-tool user edit admin --account-valid-to="2100-01-01 00:00:00Z
Unfortunately, it did not solve my problem. I had started poking around in the database, but didn't find the field you mention.
I have just rebuilt my setup again, and this time it suddenly worked. The only difference I noticed this time was that I got the message "[ ERROR ] Failed to execute stage 'Closing up': Failed to stop service 'ovirt-vmconsole-proxy-sshd'" So, while I've got it working, I still don't have a good explanation of why it didn't work before and does again now. I rebuild a few more times and see if I can get it to happen again.
Christopher
On 10/05/2015 11:00 AM, Ondra Machacek wrote:
Hi,
I believe this should solve your problem:
$ ovirt-aaa-jdbc-tool user edit admin --account-valid-to="2100-01-01 00:00:00Z"
(feel free change the date to whatever suites you)
If it won't help, can you please send output of this psql command?
# select valid_to from aaa_jdbc.users where name = 'admin';
Username and password to connect to database can be found here: /etc/ovirt-engine/aaa/internal.properties
Thanks, Ondra
On 10/05/2015 06:43 PM, Christopher Miersma wrote:
I'm having the same problem with the latest packages for 3.6 RC. I've tried reinstalling a number of times, setting up with and without an answer file, and I always get a login denied error.
Log entries: (from trying ovirt-shell) 2015-10-05 09:30:48,361 ERROR [org.ovirt.engine.core.aaa.filters.BasicAuthenticationFilter] (default task-1) [] User admin authentication failed. profile is internal. Invocation Result code is 0. Authn result code is ACCOUNT_EXPIRED
(from web interface) 2015-10-05 10:32:25,034 INFO [org.ovirt.engine.core.bll.aaa.LoginBaseCommand] (default task-19) [] Can't login user 'admin' with authentication profile 'internal' because the authentication failed. 2015-10-05 10:32:25,040 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-19) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: The account for admin got expired. Please contact the system administrator. 2015-10-05 10:32:25,043 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-19) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: User admin@internal failed to log in. 2015-10-05 10:32:25,044 WARN [org.ovirt.engine.core.bll.aaa.LoginAdminUserCommand] (default task-19) [] CanDoAction of action 'LoginAdminUser' failed for user admin@internal. Reasons: USER_ACCOUNT_EXPIRED
I have tried using the ovirt-aaa-jdbc-tool tool, with "user edit --account-valid-to," "user password-reset --password-valid-to," and "user unlock" options with multiple different dates, passwords of varying complexity, etc. and nothing seems to work. This is all happening during the middle of a hosted-engine setup, which throws everything off. I've also done clean re-installs a number of times.
Early last week, when the release candidate first came out, I did not have this issue. I was able to complete the install without any problems.
Has anyone found a way to get around this if it starts happening?
Christopher _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Christopher Miersma Unix System Administrator University of Alberta Libraries 4-30 Cameron Library 780-492-4718
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users