Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proper system packaging of credmon #15

Open
7 tasks done
bbockelm opened this issue Feb 8, 2019 · 4 comments
Open
7 tasks done

Proper system packaging of credmon #15

bbockelm opened this issue Feb 8, 2019 · 4 comments
Milestone

Comments

@bbockelm
Copy link
Contributor

bbockelm commented Feb 8, 2019

We should really include proper packaging of the credmon itself in order to make this straightforward to install "alongside" a schedd.

Thoughts that come to mind:

  • RPM packages (see Add simple RPM package of the credmon. #14)
  • Drop condor config files necessary to enable the credmon. Only enable if admin specifies it in the config file
  • WSGI configuration necessary for integration in apache.
  • Generate new signing keys on first start of the credmon.
  • Export .well-known directory for OAuth2 auto-discovery.
  • Change Flask app to not function unless condor config changed by sysadmin.
  • Split configuration files to "must be edited" and "infrequently edited".

The end goal is that yum install scitokens-credmon - with very minimal config changes - should result in a working local issuer.

@jasoncpatton jasoncpatton added this to the 1.0 milestone May 2, 2019
@jasoncpatton
Copy link
Contributor

For the configs (condor and apache) there are now command line options to scitokens_credmon to install them. Some tweaking is needed to make the install script more configurable/universal, and this should probably be done before tagging 1.0. But this means configs aren't haphazardly added to condor and apache by pip/rpm/etc. until the admin is ready to enable the credmon.

The install script drops two condor configs, one that configures the credd and credmon ("infrequently edited") and another that contains a commented out example for adding a Box OAuth client ("must be edited").

@bbockelm
Copy link
Contributor Author

bbockelm commented May 9, 2019

Going the install/config script route is pretty nasty. Very difficult to manage via puppet, for example.

Instead, you want to drop the configs in place and let the admin flip the boolean from disabled to enabled.

@jasoncpatton
Copy link
Contributor

Would it be better to drop inert, commented-out configs in the right locations, and then have the script modify them in place? In addition to flipping everything on, it would be nice to have a single script to modify both condor and webserver configs simultaneously so that they are consistent (e.g. port number, web subdirectory).

@bbockelm
Copy link
Contributor Author

bbockelm commented May 9, 2019

Sure, that’s fine. Just be aware that admins will mostly care about what they need to put into Puppet. So, we want to make sure we explain the relevant config files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants