
----- Original Message -----
From: "Yedidyah Bar David" <didi@redhat.com> To: "Gianluca Cecchi" <gianluca.cecchi@gmail.com>, "Martin Perina" <mperina@redhat.com>, "Sandro Bonazzola" <sbonazzo@redhat.com> Cc: "Simone Tiraboschi" <stirabos@redhat.com>, "users" <users@ovirt.org> Sent: Sunday, December 20, 2015 10:50:43 AM Subject: Re: [ovirt-users] After update to 3.6.1 profile internal does not exist message
On Sun, Dec 20, 2015 at 12:45 AM, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Sat, Dec 19, 2015 at 9:14 PM, Gianluca Cecchi wrote:
I fear that the "yum update" command I executed after "engine-setuo" completed successfully, to update the OS to CentOS 7.2 has pulled in the package Dec 19 13:46:48 Updated: ovirt-engine-extension-aaa-jdbc-1.0.4-1.el7.noarch
and has created my problems... and create similar ones to other guys... what do you think?
Gianluca
It was indeed the main reason for not being able to authenticate in webadmin portal:
I reverted to the previous version of the package. After putting env in maintenance global I executed:
# systemctl stop ovirt-engine
Previous version: Nov 04 12:52:20 Installed: ovirt-engine-extension-aaa-jdbc-1.0.1-1.el7.noarch
# yum downgrade ovirt-engine-extension-aaa-jdbc ... Dependencies Resolved
==================================================================================================== Package Arch Version Repository Size ==================================================================================================== Downgrading: ovirt-engine-extension-aaa-jdbc noarch 1.0.1-1.el7 ovirt-3.6 165 k
# systemctl start ovirt-engine
and I'm able to connect again. In engine.log now
2015-12-19 23:38:31,352 INFO [org.ovirt.engine.core.uutils.config.ShellLikeConfd] (default task-1) [] Loaded file '/etc/ovirt-engine/engine.conf.d/50-ovirt-engine-extension-aaa-jdbc.conf'. ... 2015-12-19 23:38:31,357 INFO [org.ovirt.engine.core.uutils.config.ShellLikeConfd] (default task-1) [] Value of property 'ENGINE_JAVA_MODULEPATH' is '/usr/share/ovirt-engine-wildfly-overlay/modules:/usr/share/ovirt-engine/modules/common:/usr/share/ovirt-engine-extension-aaa-jdbc/modules'. ... 2015-12-19 23:38:34,355 INFO [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (ServerService Thread Pool -- 37) [] Instance name: 'internal-authn', Extension name: '"ovirt-engine-extension-aaa-jdbc".authn', Version: '"1.0.1"', Notes: 'Display name: "ovirt-engine-extension-aaa-jdbc"', License: 'ASL 2.0', Home: 'http://www.ovirt.org', Author 'The oVirt Project', Build interface Version: '0', File: '/etc/ovirt-engine/extensions.d/internal-authn.properties', Initialized: 'true' 2015-12-19 23:38:34,355 INFO [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (ServerService Thread Pool -- 37) [] Instance name: 'internal-authz', Extension name: '"ovirt-engine-extension-aaa-jdbc".authz', Version: '"1.0.1"', Notes: 'Display name: "ovirt-engine-extension-aaa-jdbc"', License: 'ASL 2.0', Home: 'http://www.ovirt.org', Author 'The oVirt Project', Build interface Version: '0', File: '/etc/ovirt-engine/extensions.d/internal-authz.properties', Initialized: 'true'
On Sat, Dec 19, 2015 at 10:14 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Sat, Dec 19, 2015 at 8:57 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
but I don't understand how this can influence the fact that inside the web ui login I don't see any selectable value for the profile field: the "internal" default domain is missing.... I didn't implement any other
https://drive.google.com/file/d/0BwoPbcrMv8mvNTV1S2M3MGdKNHM/view?usp=sharin...
Gianluca
the culprit could be related to these lines in engine.log
2015-12-19 13:57:22,403 INFO [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (ServerService Thread Pool -- 41) [] Extension 'internal-authn' loaded 2015-12-19 13:57:22,406 INFO [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (ServerService Thread Pool -- 41) [] Loading extension 'internal-authz' 2015-12-19 13:57:22,408 INFO [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (ServerService Thread Pool -- 41) [] Extension 'internal-authz' loaded 2015-12-19 13:57:22,409 INFO [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (ServerService Thread Pool -- 41) [] Initializing extension 'internal-authn' 2015-12-19 13:57:22,447 ERROR [org.ovirt.engine.extension.aaa.jdbc.binding.api.AuthnExtension] (ServerService Thread Pool -- 41) [] Unexpected Exception invoking: EXTENSION_INITIALIZE[e5ae1b7f-9104-4f23-a444-7b9175ff68d2] 2015-12-19 13:57:22,447 ERROR [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (ServerService Thread Pool -- 41) [] Error in activating extension 'internal-authn': Database schema is older than required by currently installed ovirt-engine-extension-aaa-jdbc package version. Please upgrade profile database schema before proceeding (for more info about upgrade please take a look at README.admin file contained in ovirt-engine-extension-aaa-jdbc package).
README.admin there [1] says, among other things: =================================================================== IV. Upgrading 'internal' profile
ATTENTION: aaa-jdbc extension is not upgraded automatically during oVirt engine upgrade and it needs to be upgraded manually! ... stop engine ... yum update extension package ... engine-setup ===================================================================
So you should run engine-setup after you update this package.
Martin - is this intentional? Why not update the package automatically during engine-setup?
Or even version-lock it? I do not think people should expect their engine to not allow logins after they run 'yum update'. Adding also Sandro.
Hi, there are several reasons for this: 1. aaa-jdbc is an engine 3.6 extension, engine requires its presence to provide 'internal' domain but it doesn't require any specific version, so users may update aaa-jdbc independently on engine if they need features provided provided by new version 2. engine-setup automatically configures/upgrades 'internal' domain, but users may define manually other domains (as described in README.admin) and those domains are not touched by engine-setup at all 3. Due to 1. and 2. we decided not to define version specific requirement between engine and aaa-jdbc in engine-setup (same behaviour as already exists for other engine extensions). So users may for example upgrade engine, but leave aaa-jdbc as is or leave engine as is and upgrade aaa-jdbc if they need it. Users just need to get used to read doc before doing upgrade. Martin
[1] https://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-jdbc.git;a=blob... -- Didi