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

[FEATURE REQUEST] Add an exist_environment property #55

Open
adamretter opened this issue Apr 19, 2023 · 7 comments
Open

[FEATURE REQUEST] Add an exist_environment property #55

adamretter opened this issue Apr 19, 2023 · 7 comments

Comments

@adamretter
Copy link
Contributor

At the moment, some eXist-db options have been configured for secure operation but several others have not.

I think it would be sensible to add an exist_environment property that could be set to "Development" or "Production", when set to "Production" it would turn on all sensible config options for securing eXist-db in a production environment.

We might also want to choose to add individual options for the blanket option of "Production" to allow users more fine-grained control over their configuration.

@chakl
Copy link
Collaborator

chakl commented Apr 19, 2023

no. That would be a meta config option that creates unneeded complexity.

You could create Ansible host groups "my-dev-servers" and "my-prod-servers" and set group defaults to achieve the same. In your Ansible deployment, no need to mess with the role.

@adamretter
Copy link
Contributor Author

@chakl but the required options don't yet exist in the existdb-ansible-role, so unless I am mistaken, I would still not be able to configure it from the location you suggested

@chakl
Copy link
Collaborator

chakl commented Apr 19, 2023

@adamretter what are the "required options"?

@adamretter
Copy link
Contributor Author

I would yet need to create an exhaustive list... but they include disabling Mail and JNDI modules, adding parameters to the File, Cache, and SQL modules, and also enabling XXE mitigation

@chakl
Copy link
Collaborator

chakl commented Apr 19, 2023

I see.. We never felt a need for this, feel free to send a PR

@chakl
Copy link
Collaborator

chakl commented Apr 19, 2023

but don't over-engineer :)

and why are these not set to reasonable defaults upstream, so there's no need to turn knobs?

@adamretter
Copy link
Contributor Author

and why are these not set to reasonable defaults upstream

They are set to reasonable defaults upstream. However, there is of course a difference between running a piece of software for development purposes as opposed to for production purposes.

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