Running a private instance of JBoss AS7 in Fedora

Mon Apr 23 11:57:40 UTC 2012

On 04/23/2012 01:57 PM, Juan Hernandez wrote:
> On 04/23/2012 12:40 PM, Yair Zaslavsky wrote:
>> On 04/23/2012 01:25 PM, Juan Hernandez wrote:
>>> Hello,
>>>
>>> It has been discussed before how to run ovirt-engine side by side with
>>> other JBoss AS7 applications. This is my suggestion:
>>>
>>> 1. Create an ovirt user and ovirt group to run the application server
>>> (we already do that for the notification service, so this is not new).
>>>
>>> 2. Replicate the directories used by JBoss AS7 putting them in the
>>> locations suggested by the file system standards:
>>>
>>> /usr/share/ovirt-engine/deployments root:ovirt rwxrwxr-t
>>>   engine.ear root:root rw-rw-r--
>>>   engine.ear.dodeploy ovirt:ovirt rw-rw-r--
>>>   engine.ear.deployed ovirt:ovirt rw-rw-r--
>>>   ROOT.war root:root rw-rw-r--
>>>   ROOT.war.dodeploy ovirt:ovirt rw-rw-r--
>>>   ROOT.war.deployed ovirt:ovirt rw-rw-r--
>>>
>>> (I would suggest to move ROOT.war to the .ear to reduce the number of
>>> files in this directory)
>>>
>>> Note that the deployments should be owned by root:root so that the
>>> ovirt:ovirt user can't write them. Also the directory needs write
>>> permission for the ovirt:ovirt user because that user it is going to
>>> create/remove the .dodeploy and .deployed files. The sticky bit can be
>>> used to avoid that user removing the deployment units (it would be
>>> better to have the .dodeploy and .deployed files in a different
>>> directory, but that is not possible at the moment).
>>>
>>> /usr/share/ovirt-engine/modules root:root rwxr-xr-x
>>>
>>> We should use this directory to place the jboss modules that are missing
>>> in JBoss AS itself (the PostgreSQL JDBC driver, for example) or that
>>> need to be overridden. Later we should start the engine using
>>> /usr/share/ovirt-engine/modules:/usr/share/jboss-as/modules as the
>>> module path.
>>>
>>> /etc/ovirt-engine root:root rwxr-xr-x
>>>   ovirt-engine-users.properties root:root rw-r--r--
>>>   ovirt-engine-logging.properties root:root rw-r--r--
>>>   ovirt-engine.xml ovirt:ovirt rw-r--r--
>>>
>>> These files should be based on the mngt-users.properties,
>>> logging.properties and standalone-web.xml files provided by the
>>> application server.
>>>
>>> (I think it can be easier to maintain those files than to maintain the
>>> python code that adjusts them during setup)
>>>
>>> /var/lib/ovirt-engine ovirt:ovirt rwxr-xr-x
>>>
>>> This is the directory where the application server will place the
>>> content of the additional deployments. Will not be used by the engine,
>>> but is needed anyway.
>>>
>>> /var/cache/ovirt-engine ovirt:ovirt rwxr-xr-x
>>>
>>> The application server will create here temporary auth, vfs and work
>>> directories.
>>>
>>> 3. Start the application server using the ovirt:ovirt user with the
>>> following system properties (in addition to the typical jboss-as ones):
>>>
>>> -Djboss.server.default.config=ovirt-engine.xml
>>> -Dlogging.configuration=file:///etc/ovirt-engine/ovirt-engine-logging.properties
>>> -mp /usr/share/ovirt-engine/modules:/usr/share/jboss-as/modules
>>> -Djboss.home.dir=/usr/share/jboss-as
>>> -Djboss.server.base.dir=/usr/share/ovirt-engine
>>> -Djboss.server.config.dir=/etc/ovirt-engine
>>> -Djboss.server.temp.dir=/var/cache/ovirt-engine
>>> -Djboss.controller.temp.dir=/var/cache/ovirt-engine
>>> -c ovirt-engine.xml
>>>
>>> These options should go in a /usr/share/ovirt-engine/bin/ovirt-engine.sh
>>> script.
>>>
>>> 4. Create a systemd unit file to start the application server using the
>>> ovirt-engine.sh script:
>>>
>>> [Unit]
>>> Description=oVirt Engine
>>> After=network.service
>>>
>>> [Service]
>>> ExecStart=/usr/share/ovirt-engine/bin/ovirt-engine.sh
>>> User=ovirt
>>>
>>> [Install]
>>> WantedBy=multi-user.target
>>>
>>> With this the engine will run independently of the application server
>>> from the filesystem point of view.
>>>
>>> 5 In order to make it independent also from the ports point of view I
>>> would suggest to add a /etc/sysconfig/ovirt-engine containing variables
>>> like these:
>>>
>>> ENGINE_HOST=host.example.com
>>> ENGINE_HTTP_PORT=8080
>>> ENGINE_HTTP_PORT=8443
>>
>> Are these the only ports we need?
>> What about jnp/rmi  and stuff like that?
>> Even if not using, won't we have collisions? I'm asking based on my
>> experience of doing the same with JBoss AS 4.2.x versions
> 
> Those are all the ports that ovirt-engine uses/needs. But not all the
> ports that JBoss AS uses, so we could have collisions. Those collisions
> can be avoided using the same mechanism. For example:
> 
> ENGINE_REMOTING_PORT=4447
> -Dovirt.remoting.port=${ENGINE_REMOTING_PORT}
> <socket-binding name="remoting" port="${ovirt.remoting.port}"/>

Sure, I just wanted to be sure about this.
In addition, I have a feeling jboss added some ports since my 4.2.x days
:) Correct me if I'm wrong here (back at the company we did that, we had
a document with all the relevant ports and this process in general,
maybe this is something worth doing - i.e using ovirt wiki - when there
is a conclusion about the process)

> 
> I am not trying to be exhaustive at the moment, only sharing the
> approach with you.
> 
>>> These options can then be used in the start script to generate
>>> corresponding system properties:
>>>
>>> -Dengine.host=${ENGINE_HOST}
>>> -Dhttp.port=${ENGINE_HTTP_PORT}
>>> -Dhttps.port=${ENGINE_HTTPS_PORT}
>>>
>>> And these system properties can then be used in the ovirt-engine.xml
>>> configuration file:
>>>
>>> <interfaces>
>>>   <interface name="public">
>>>      <inet-address value=${ovirt.host}/>
>>>   </interface>
>>> </interfaces>
>>>
>>> <socket-binding-group name="standard-sockets" default-interface="public">
>>>   <socket-binding name="http" port="${ovirt.http.port}"/>
>>>   <socket-binding name="https" port="${ovirt.https.port}"/>
>>>   ...
>>> </socket-binding-group>
>>>
>>> Let me know what you think.
>>>
>>> Regards,
>>> Juan Hernandez
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>
> 