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

Reduce number of pi.cfg templates #1831

Open
plettich opened this issue Sep 2, 2019 · 3 comments

Comments

@plettich
Copy link
Member

commented Sep 2, 2019

There are several pi.cfg templates scattered across code, documentation and repositories.
We should have only one master templates (i.e. in privacyidea/config.py from which tool, documentation and deployment derive there code.

@plettich

This comment has been minimized.

Copy link
Member Author

commented Sep 2, 2019

In #1090 there is a little discussion about the handling of pi.cfg

@cornelinux

This comment has been minimized.

Copy link
Member

commented Sep 2, 2019

Why do you always open up new pandora boxes?
Please provide more information about which files are superfluous in your opinion and should be removed.
The privacyidea/config.py in my opinion is too limited and never productively used. It is used in development and test environment. I would very much like not to derive anything in production from it. There is no sense in overcomplicating things.

I think it is very rational to keep the config with the packaging, since it could be packaging-dependent.

@plettich

This comment has been minimized.

Copy link
Member Author

commented Sep 3, 2019

Please provide more information about which files are superfluous in your opinion and should be removed.

We have (different) config templates in

  • privacyidea
    • docs
      • inifile.rst
      • debian.rst
      • upgrade.rst
      • centos.rst (brand new :-))
    • deploy (is this still needed anyway?)
    • tools
      • privacyidea-standalone
  • privacyidea-appliance
  • centos deploy
  • debian deploy

The privacyidea/config.py in my opinion is too limited and never productively used. It is used in development and test environment. I would very much like not to derive anything in production from it. There is no sense in overcomplicating things.

sure thing, i try to reduce complexity. If we have a base configuration with a sensible set of (current) settings, we can derive from this config in all the other places. That way, if we add/change a setting it will be propagated to the docs/deployment/scripts etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.