Pulp

This should be done at the same time as other related secret-generation, like the RSA key. Jeff did some work to separate that stuff out from the install process, because when building an image that you expect to re-use (container or VM), you don't necessarily want a secret re-used.

@jortel, can you elaborate on what you did and how this might fit in?

Mainly moved the key generation to a separate script[0] users run during installation.

The django documentation calls this a SECRET_KEY but it really seems to be a secret (str) not an actual key. Unlike this secret, the RSA keys can be (and often are) shared between pulp installations. Not sure a script is a good fit for this. Perhaps just generate SECRET_KEY when the settings.py is imported?

[0] https://github.com/pulp/pulp/blob/master/server/bin/pulp-gen-key-pair

I'm wondering if this issue should be about doing this at pip install time instead of rpm install time. The rpm install calls the pip install so if we put it there we would have the secret generated for both install types. What do you all think?

jortel@redhat.com wrote:

The django documentation calls this a SECRET_KEY but it really seems to be a secret (str) not an actual key. Unlike this secret, the RSA keys can be (and often are) shared between pulp installations. Not sure a script is a good fit for this. Perhaps just generate SECRET_KEY when the settings.py is imported?

I believe the SECRET_KEY needs to be shared across all machines accessing the same Django db, so that would be all Pulp boxes in the cluster. Since pip is run on each box, we need to ensure that all machines get the same string value for that. This is like all the Pulp settings in server.yaml so we probably should read the value of SECRET_KEY out of server.yaml which also holds other shared secrets.

I'm not exactly sure how or when we should set the value of that field in server.yaml.

As an aside, maybe server.yaml should be on the clustered filesystem so that users don't have to propagate settings across so many machines?

mhrivnak Is the idea that it's part of the documentation for the user to create and set this string in the conf file?

We don't have an installation page currently, maybe this would create one? That would be good overall I think.

I think I understand this story better now. I think what this story would do would be to delete this line from here[0] and have it added as a config section here[1] right? The settings from[1] are automatically overlaid onto the Django settings[0] already.

[0]: https://github.com/pulp/pulp/blob/253ae59c9d80a4698c47a0608f96e5d81a62f0d7/platform/pulpcore/app/settings.py#L25
[1]: https://github.com/pulp/pulp/blob/b86677f069c03643380d98bc51cd1291fdfa3289/platform/etc/pulp/server.yaml

As an aside, is the SECRET_KEY field required for dev installs? If so, we should also add a step to Ansible for the dev setup to randomly generate this field. This is also related to if vagrant is symlinking or copying the server.yaml file for dev installs. If every time the Ansible dev setup runs it modifies the installed server.yaml it can't be under version control.

Thanks for the help!

bmbouter wrote:

mhrivnak Is the idea that it's part of the documentation for the user to create and set this string in the conf file?

That seems reasonable. I'll add a checklist item about it.

We don't have an installation page currently, maybe this would create one? That would be good overall I think.

Agreed. Those steps are currently captured here:

http://docs.pulpproject.org/user-guide/installation/f23-.html#server

But breaking that out to a dedicated section or page would be a good idea. Although that doesn't necessarily need to happen with this task.

I think I understand this story better now. I think what this story would do would be to delete this line from here[0] and have it added as a config section here[1] right? The settings from[1] are automatically overlaid onto the Django settings[0] already.

[0]: https://github.com/pulp/pulp/blob/253ae59c9d80a4698c47a0608f96e5d81a62f0d7/platform/pulpcore/app/settings.py#L25
[1]: https://github.com/pulp/pulp/blob/b86677f069c03643380d98bc51cd1291fdfa3289/platform/etc/pulp/server.yaml

Something like that. Deleting it may or may not be the best thing. It's behaviorally just like database settings. The user needs to provide them in the config file, and we need to load them into django's settings.

As an aside, is the SECRET_KEY field required for dev installs? If so, we should also add a step to Ansible for the dev setup to randomly generate this field. This is also related to if vagrant is symlinking or copying the server.yaml file for dev installs. If every time the Ansible dev setup runs it modifies the installed server.yaml it can't be under version control.

django documents it as required, so yes this is a great point. I'll add it as a checklist item.

Being able to modify the settings file in your dev env without modifying the checked-in copy is a general need we have. Devs want to change log levels, try out a different DB, try a different message broker, reproduce bugs with specific config values, etc. We should figure that out, but not necessarily as part of this work.