icingaweb2 role: How to handle apache modules and the apache2 service?

[johanneskastl]

ansible-collection-icinga/roles/icingaweb2/tasks/main.yml

Line 24 in fc5062b

- name: Manage Icinga Web 2 config

I started adding Suse support for the roles and came across one thing:

On openSUSE, unlike on Debian, the apache2 service is not running/enabled after installation. So the role prepares everything required for icingaweb2, but the page is not available, as the webserver is not running.

Should the role enable and start the apache2 service? Or is it intentionally left out?

On a related note, the standard apache2 configuration on openSUSE Leap 15.5 spits out an error on the website due to the rewrite module not being enabled. Should this also be handled by the role?

Thanks in advance!
Johannes

[mocdaniel]

As Icinga Web pulls in Apache2 as a direct dependency anyways if not already installed, we could go one step further and configure it to our needs within the scope of the Icinga Web role, in my opinion. So, yes to both questions from my side, let's wait for feedback from @mkayontour and maybe @martialblog

[mkayontour]

This is a tough question, on one side I want to say sure why not, lets manage some Apache2 configuration. Cause we are already making sure apache2 is properly configured, not too much, but we install libapache2-mod-php.

In the case we create a own apache2 management, a few issues will arise.

1. Role needs to manage everything and should be supported on all platforms. (A lot of work)
2. If the role won't manage everything we cannot ensure is compatible to other roles. (Annoying)
3. Will be backlogged because we need to ensure other icinga related content is available at the collection. (Needs a WR till available :D)

I would like to promote a working example on how to properly use the collection in combination with other roles.

Regarding the issue, I guess that if the geerlingguy.apache2 role was used before the icingaweb2 role, it would make sure the service is enabled and running. It also has the capabilities to ensure certain mods are enabled.

Got support for those OSs: Role that installs Apache 2.x on RHEL/CentOS, Debian/Ubuntu, SLES and Solaris

apache_mods_enabled:
  - rewrite

Or add SSL Values to your vhosts as requested in #227

apache_vhosts_ssl:
  - servername: "local.dev"
    documentroot: "/var/www/html"
    certificate_file: "/home/vagrant/example.crt"
    certificate_key_file: "/home/vagrant/example.key"
    certificate_chain_file: "/path/to/certificate_chain.crt"

All in all, I think using the geerlingguy role and teach how to use it in combination with the collection, is the best way to go.
We will be faster, doesn't require a workaround till it's available and upholds compatibility with other roles.

[johanneskastl]

All in all, I think using the geerlingguy role and teach how to use it in combination with the collection, is the best way to go.
We will be faster, doesn't require a workaround till it's available and upholds compatibility with other roles.

I am fine either way, but it should be documented that there is a missing piece (just like with the database creation that is not handled by the roles, but it is stated that you need to use another role to do that).

[widhalmt]

I'm all for keeping it a dependency and having that in the docs. The geerlingguy apache role works great in most cases so we can suggest using it.