meza
meza copied to clipboard
enterprisemediawiki
Meza doesn't support the config I need
Meza should be as flexible as possible while not sacrificing the needs of providing cutting-edge MediaWiki to RedHat/CentOS users (and someday Debian). Anyone who can't use Meza because of some limitation, please use this issue to air your grievances.
Mirroring this on Phabricator: https://phabricator.wikimedia.org/T207797
MEZA should able to install without issues on enterprise servers that are configured to fully comply with NASA's Enterprise Technology Assessments and Digital Standards (ETADS) - https://etads.nasa.gov/
specifically, these: https://etads.nasa.gov/ascs/security-configuration-specifications/
(specific reference to the selection default UMASK settings on the system .. this causes known issues in the default permissions given to files and folders created during MEZA install)
I think i have resolved all these issues on my site, but this will no doubt be an issue for future enterprise organizations who require users to use boilerplate server images that meet strict NIST standards for MODERATE classification of information systems.
(Is this the kind of submission you were hoping to get?)
Would be great if the specific needs of an enterprise system using SiteMinder's CA Policy Agent was included in MEZA development and documentation. Specifically, the method of SSO using an Immutable Session Cookie from an external Identity Provider. My understanding is that the current implementation of Meza is only set up with SAML as the available SSO mechanism.
Another areas where this could become a significant problem is when we get the cross-wiki search capability mentioned in issue 1109 [1] added to meza .. if the test for which wiki the user has read access to is limited to SAML, that would possibly make that feature unusable to a SiteMinder based auth config.
[1] https://github.com/enterprisemediawiki/meza/issues/1109
(Is this the kind of submission you were hoping to get?)
It would be great to be able to say "Meza supports strict NIST standards for MODERATE classification" or something like that.
if the test for which wiki the user has read access to is limited to SAML
Such a test doesn't care how a user authenticated.
the current implementation of Meza is only set up with SAML as the available SSO mechanism
It's the only mechanism anyone has spent time to include into Meza. No one is going to take the time to build different mechanisms into Meza for no reason. It's on users of Meza to give back to the community by contributing the lessons they've learned.
"It's on users of Meza to give back to the community by contributing the lessons they've learned."
That's where I get confused.. Doesn't this information count as such a contribution? .. or do you mean that every user of MEZA (software that aims at making administration easy) is responsible for providing merge ready code solutions in github to the MEZA project before the lesson will be recognized?
"for no reason" .. the reason would be to make Meza "as flexible as possible while not sacrificing the needs of providing cutting-edge MediaWiki to RedHat/CentOS users (and someday Debian). [such that] anyone who can't use Meza because of some limitation, please use this issue to air your grievances."
I feel like I did exactly what you asked for here and was told it doesn't count. Please help me understand what you mean by "make Meza "as flexible as possible" if this doesn't count as a "reason" to "make MEZA more flexible."
Fair, I asked for airing of grievances and should be more understanding and thankful for the report. I guess what bothers me here is you've solved this problem in your personal case and have not shared the solution. You're not saying "it would be great if Meza did this". You're saying "I've made Meza do this, and I think you should implement it again on your own".
I appreciate you giving me some ground, but you make it sound like I've made all these merge-ready modifications to the MEZA deploy scripts that I simply need to share on github. I wish that were the case. It is not. Here are some clarifications:
[Re: making MEZA install correctly on an system that is compliant with the ETADS Security Policy] -- I really haven't solved the problem from a "meza code update" perspective.. it's been lots of little little incremental permissions and ownership hacks on my production system done here and there over time after the initial install (back in May 2018) done as I found issues with the way meza was (or was not) installed correctly.. logs.. scripts.. user accounts... etc.. There is no way I can trace my ad-hoc solutions of the symptoms back to the right ansible script which is the root case. My suspicion is simply that for this capability request that I am requesting of MEZA here, you would have have to be willing to adopt the ETADS compliant RHEL7 image I was forced to use and see these issues for yourself in your development in order to find which ansible scripts you need to make the changes to (or add altogether) .. I sure don't know this level of information. That said, if you'd like to get a copy of the NASA ETADS compliant RHEL7 image to adopt as your dev standard, let me know. That's how I can contribute to MEZA on this. You wouldn't need to validate an ETADS compliant RHEL7 image. It's verified and validated by the Agency's official experts on system security policies. If you can make MEZA instal properly on that, I'm sure MEZA would work well for any truly NIST secure system. I've seen other issues you've submitted where you mention the need to use sudo less, etc as a matter of "proper" coding.. My guess is that if you adopted the ETADS compliant RHEL7 image, it might be a great tool for you to see why those practices are proper. There's a reason for you I should think.
[Re: making MEZA use the Extension:Auth_RemoteUser for Authentication] -- my approach was simply to keep the MEZA SAML feature turned off (unused) and manually install (and configure) Extension:Auth_RemoteUser. How you would go about modifying the MEZA code to install and configure the Auth_RemoteUser extension conditionally from the public config files not something I have done.
[Re: making MEZA do SSL at the Apache Level] -- I will make a point to provide my haproxy and httpd cfg files for MEZA in the documentation and for you to consider how you would integrate that into the MEZA role based tasks as an Option.. I will show you where I have commented out the deploy script to NOT update haproxy and httpd. But I have not modified those .j2 tasks to "assert" this configuration, just to avoid messing with it.
Again, all my implementations are live production implementations. Nothing I can "contribute" to a "pull" on the project. I'm just sharing with you what my experiences were and what some of the notable challenges have been with using MEZA as it was at time (1.30, ~May 2018). in my network environment. I'm not at all expecting you to stop what you're doing and make these things your top priorities, but I do think you should be openly grateful for the feedback and insight that you have explicitly solicited. if nothing I've shared here is going to affect your development approach, then that's fine too. Much as I'd like it, the likelyhood of my becoming a active meza developer and deployment tester for future new installations is low. I can only tell you about the installation I'm actively maintaining.
Hopefully you can sympathize with my frustrations a little too. I'm grateful for all you do. I do love MEZA.
little incremental permissions and ownership hacks on my production system done here and there over time
Again, all my implementations are live production implementations. Nothing I can "contribute" to a "pull" on the project.
How then do you meza deploy? If you haven't modified the contents of /opt/meza then any meza deploy should undo changes you've made manually.
if you'd like to get a copy of the NASA ETADS compliant RHEL7 image to adopt as your dev standard, let me know
If you can provide this in a way that I can boot it locally then I can dev against it.
my approach was simply to ... manually install (and configure) Extension:Auth_RemoteUser
And you must have also setting up some agent
How you would go about modifying the MEZA code to install and configure the Auth_RemoteUser extension conditionally from the public config files not something I have done.
https://www.mediawiki.org/wiki/Meza/Installing_additional_extensions
I will show you where I have commented out the deploy script
I think you want to cd /opt/meza then git diff.
[How then do you meza deploy?] -- Yes, I have made some mods to Meza, and I will submit them as pull requests this week, but they don't relate to the problems I have been dealing with due to the UMASK from the original install (i think) .. the main issues for me are, after a Deploy, I have to manually set the ownership of some folders to apache:apache .. the temp folder that meza mediawiki uses to create thumbnails is one folder and then there are some pesky issues with the ownership of the vendor folder in mediawiki and various things involved in composer updates.. as a solution i have been running MW update and composer updates manually because they failed there on meza deploy (until recently, i think.. HexMode did something that might have solved that ) .. anyway.. I'm going to submit some "issues" to track that might translate into pull requests. let's work in that way.
[If you can provide this in a way that I can boot it locally then I can dev against it.] -- Will do.
[And you must have also setting up some agent [agent setup] -- yes.. sadly, i'm not privy to the set-up of the Siteminder CA Policy Agent.. that's the domain of the enterprise server admin. I will provide the Auth_RemoteUser config in the Meza documentation on MW.org.
Ok.. off to write some specific issues Hexmode and I are going to work on soon. I'll be in touch with the ETADS RHEL7 image. Stay tuned.
We would like to use Meza as an intranet wiki. The default installation is a litte over the top for our needs. Is there a way to not install all plugins bei default?
This would also enable us to run it on a weaker server (the user load would be <200 Users with probably ~20 actually editing)
@masgo Thank you for your input, and sorry for the extreme delay in responding. Please share your thoughts on this issue: #1264