meza
meza copied to clipboard
enterprisemediawiki
Add public config flag that keeps meza from touching httpd.conf config
Would like a property to set in /opt/conf-meza/public/public.yml that keeps "meza deploy" from changing anything in the systems current apache/httpd configuration.
This is needed for sites that have an httpd.conf config that is significantly different from the one meza deploys. The goal is to be able to run "meza deploy
If someone can show me an example of such a parameter for something else, I'll tailor it for this function and submit the pull request for it. I just need someone to show me an example of a similar function in conf-meza/public/public.yml
Wouldn't it be better to make the things you want to add/subtract from httpd.conf configurable, versus just not allowing Meza to manage httpd.conf? If Meza doesn't manage it you risk breaking thing anytime you upgrade.
Being able to say that the Meza the application can be configured to not alter the Apache configuration is one of my required security controls.. it's okay if Meza evaluates Apache to determine its suitability for Meza, but I need to be able to configure Meza to avoid making changes to Apache in order to check the box on an application security control. In my production environment, I'm allowed to make changes in /opt but not /Etc. .. I'm striving to create an sbu/cui certified public facing web application.
Two things.. 1) if my Apache configuration changes.. the application security folks in my organization will be notified and it will be treated as an "incident" and 2) if I give the application security team a parameter to validate in the application configuration that they can periodically run a check for to verify that it's been set properly then it meets an additional automated security benchmark
In this particular environment that Meza is installed in.. meza's ability to control haproxy and Apache is a liability
For these reasons, would you endorse this as a reasonable improvement to meza?
Meza is an application. One component of that application is a web server. One of Meza's main goals is to make it possible for people to stay on the latest versions of MediaWiki. By making Meza unable to control a huge aspect of itself you're making it impossible to upgrade without you manually determining what changed between versions and then applying those changes. Your security people can review what is different about Meza's httpd.conf template before upgrading. Why not just do that?
Does SharePoint not control its web server? What about Confluence? I don't know the answer to this question, but it seems oddly restrictive.