Step 2 is taken from the Quickstart guide (Fedora 18) @ http://www.ovirt.org/Download

The reason we require admin permissions is the multiple components ovirt-engine-setup is taking care of, such as postgres, NFS Export, JBoss and selinux configuration.

Any idea how to do that without Admin permissions?

(In reply to Ofer Schreiber from comment #2)
> The reason we require admin permissions is the multiple components
> ovirt-engine-setup is taking care of, such as postgres, NFS Export, JBoss
> and selinux configuration.
> 
> Any idea how to do that without Admin permissions?

-------------------------------------

When you do "sudo yum install ovirt-engine" it should:

a. be setup with defaults, similar to other software like Virtualbox

b. have an Icon for Ovirt, similar to how it is being done in Virtualbox

------------------------------------


Now after Option 1, a user would have to Click the Ovirt Icon and then the user will be provided with a Graphical User Interface that asks the questions.

Basically the GUI Interface will replace "sudo engine-setup".

If the GUI Interface Setup fails for some reason, ABRT will automatically kick in and ask the user to file a bug.

Right now ABRT does not kick in if the setup does not complete.

...to be continued

Well, IMHO oVirt engine is a server / enterprise product with a target really different from the one VirtualBox have.
On a server running oVirt engine you probably don't have a desktop at all.
You may argue that then the setup should be done through the admin web interface but I'm not really sure that it may be better than run engine-setup through ssh in a (maybe) remote server.

*** Bug 1116017 has been marked as a duplicate of this bug. ***

What about to have this:

- ovirt user for running apps
- ovirtadm for interactive administrations
- rpms would install files into /etc/sudoers.d/

1. sudo yum install ovirt-engine
2. the setup itself could be done by ovirtadm as all root privileges would be obtained via sudo (ovirt-engine related files in /etc/sudoers.d/)

This way where could be separation between root and ovirt related privileges. All files would need to have access/writes for ovirt and ovirtadm though.

In context of separate websocket proxy/reports, one could ssh/scp via ovirtadm and copy/sign crt/csr...

My current intentions re this bug:

1. Fix bug 1270719

2. Fix bug 1191995

3. Change the default of 'create iso domain?' to 'No'. bug 1110740 comment 10

4. TODO find other things that really require root and try to do them at yum install time (e.g. bug 1033043).

5. Hopefully, following 4, we do not need root anymore, at least not with the default answers.

6. Flow:

yum install ovirt-engine

service ovirt-engine start

If the service detects that it's not set up, it runs setup unattended and then restarts.

7. Need to think about security implications - perhaps something like comment 6.

8. Not sure admin password is a real issue. We might have a fixed/empty one, where first login requires changing, or allow using OS user (root password).

IMO engine-setup should ask a question if one would like to have engine-setup to do all its setup (check if running as root, if not sudo rule required) and if not running as root, engine-setup should inform the user that either sudo rule would be required or setup would do only stuff which it has permissions for (that manual prerequisite should be met before by the administrator).

Also please tak into the mind having separate chain for engine fw rules. This chain could be pre-setup by administrator. Unfortunately it seems iptables (loading) daemon does not support loading from multiple files (a RFE?) but a sudo rule can be configured to be able to populate only engine iptables chain with rules... (No idea how it works with firewalld, maybe they have better solution).

Doron, with the cockpit-ovirt web ui which provides graphical hosted engine setup using a web ui, can we consider this closed, current release?

(In reply to Sandro Bonazzola from comment #11)
> Doron, with the cockpit-ovirt web ui which provides graphical hosted engine
> setup using a web ui, can we consider this closed, current release?

IIRC we have an admin user which can be used in cockpit, is it correct?
If so, we will close this issue.

(In reply to Doron Fediuck from comment #12)
> (In reply to Sandro Bonazzola from comment #11)
> > Doron, with the cockpit-ovirt web ui which provides graphical hosted engine
> > setup using a web ui, can we consider this closed, current release?
> 
> IIRC we have an admin user which can be used in cockpit, is it correct?
> If so, we will close this issue.

Redirecting to Ryan. If we haven't an admin user we can add it.

We do have an admin user -- node.