Implement the `oakd` and comanage configuration into the comanage puppet config

[mgregoro]

I talk more about this here: https://github.com/MI-OSiRIS/puppet/commit/20d53b37f2d9160e5a13fa5ad4e093f2fd1fdf37#commitcomment-22090466

[bmeekhof]

Here's an outline of how that might look. Some pieces of this are underway, particularly vhost and shibboleth config.

CoManage puppet module (public release) which depends on modules configuring apache, mysql, shibboleth. I am not aware of any pre-existing comanage puppet modules.

• calls mysql module provided resources to do initial database setup, and/or calls exec resources if scripts need to be run
  • calls apache module provided resource to configure a comanage vhost that assumes availability of shibboleth auth methods (see commit reference)
  • presumes user separately configured shibboleth, outside scope of this module (though we'll use another module to do shib config in the same 'profile' calling comanage module).
  • SSL certificate config by user preference, in our case we just include our profile::letsencrypt and point the apache vhost at the default cert location

Oakd puppet module (public release)which:

• installs an oakd package (?)
• configures oakd vhost using apache module provided resource (see commit reference for vhost config)
• provides resources for other oakd config as to be determined.

[mgregoro]

Ah that makes more sense then. oakd may never be a standalone package, it will come together with the rest of the aa_services, but where puppet's concerned only the oakd portion of it will start. I can see the need for that. As you saw in my comment, they don't need to be separate vhosts, only aliases. In fact, most users will only ever use the comanage vhost, even when accessing oakd via the /oak/ location. Ideally they would all be combined in one single default vhost as they are now.

Sorry for copypasta-ing my "code" as it were, but.. stuff something like this into the default single vhost...

# sorry this is my first puppet ever...

        servicealiases => ['comanage.osris.org', 'oakd.osris.org'],
        directories => [
            {
                path => '/var/www/html'
                custom_fragment =>
### BEGIN CUSTOM FRAGMENT ###
'
<Location /registry/auth/login>
  AuthType shibboleth
  ShibRequestSetting requireSession 1
  require valid-user
</Location>
<Location /oak/>
  AuthType shibboleth
  ShibRequestSetting requireSession 1
  Require valid-user
  ProxyPassInterpolateEnv On
  ProxyPass "http://127.0.0.1:3000/oak/" interpolate
  ProxyPassReverse "http://127.0.0.1:3000/oak/" interpolate
  RequestHeader set "X-Remote-User" %{REMOTE_USER}s
  RequestHeader set "X-Persistent-Id" %{persistent-id}e
  RequestHeader set "X-EPPN" %{eppn}e
  RequestHeader set "X-Display-Name" %{displayName}e
  RequestHeader set "X-Affiliation" %{affiliation}e
  RequestHeader set "X-Shib-Handler" %{Shib-Handler}e
  RequestHeader set "X-Shib-Session-Id" %{Shib-Session-ID}e
</Location>                
'
### END CUSTOM FRAGMENT ###
            },
            {
                path => '/var/www/html/registry',
                rewrites => [
                    {
                        rewrite_cond: [
                            '%{REQUEST_FILENAME} !-d',
                            '%{REQUEST_FILENAME} !-f'
                        ],
                        rewrite_rule: [
                            '^(.*)$ index.php?/$1 [QSA,L]'
                        ]
                    }
                ]
            }
        ],

[bmeekhof]

Regarding Vhosts...sure, they can just be one vhost. I'm thinking in terms of module re-usability and also how puppet-apache manages things (everything is a vhost). If we write a 'comanage' puppet module it should be able to configure apache/comanage for anyone who uses it (with appropriate parameters). That's the endpoint I'm aiming at.

On the other hand, since we at OSiRIS want oakd on the same vhost, we may choose to disable the comanage module's vhost management and manage it as our own definition that also includes the /oak location. It could also just end up with two name-based vhosts, configured by the respective modules, and they can use the same document root.

...and, I should add, I will almost certainly soon configure a vhost somewhat as noted already and apply it in our internal profile::comanage. A full comanage module would replace and incorporate that block as a configurable option but it's easy enough to manage that little bit now for ourselves.

Regarding letsencrypt: it doesn't parse out servicealiases but it accepts an array of SANs to configure. Since we wrap it in a 'profile' we pass that array to our profile via yaml automatic parameter lookup and the profile calls letsencrypt resources using that information. We could do some fancy things with puppet 'exported resources' and collect them in the letsencrypt profile but no.

See here for details: https://github.com/MI-OSiRIS/puppet/blob/20d53b37f2d9160e5a13fa5ad4e093f2fd1fdf37/hieradata/roles/comanage.yaml And here: https://github.com/MI-OSiRIS/puppet/blob/20d53b37f2d9160e5a13fa5ad4e093f2fd1fdf37/site/profile/manifests/letsencrypt.pp

[mgregoro]

I guess the question I have is do you foresee there ever being an OSiRIS-related COmanage instance without oakd running embedded in it? It doesn't hurt to roll a vanilla comanage puppet config on the way there, but it wouldn't likely be useful to us. Oakd without COmanage seems just as unlikely.

That said, I don't mind two vhosts so long as they both include the <Location /oak> config. It just seems redundant from a configuration perspective, but whatever works best.

[bmeekhof]

Whether we'll run CoManage with or without oakd doesn't effect the relevancy of a COmanage module. It only effects the relevancy of the webserver config part of that module. We'll flip that switch off and define our own vhost there.

I didn't realize both host aliases have to include the same Location config. In that case we'd probably just combine one vhost, and in fact that vhost might best belong to an oakd specific module since oakd without COmanage is unlikely. If there's nothing for that module to do besides define a vhost then maybe it will never be a standalone module, or maybe it will be a tiny part of some larger osiris aa module. I really have no idea at this point, it's just speculation.

[bmeekhof]

Puppet config running now on COmanage host similar to pasted code. If it looks ok to you @mgregoro I'll merge the branch into normal production and you can close this.

Latest two commits on this branch for details: https://github.com/MI-OSiRIS/puppet/commits/vhost_comanage