docs
docs copied to clipboard
Request for Documentation: Document implications of `AutomaticPrepackagedPlugins` to firewalled, high-security environments
Mattermost user stu.doherty
from https://community-daily.mattermost.com has requested the following be documented:
Need to ensure this is highlighted in a few places:
* Enterprise roll-out guide
* Mattermost COnfiguration Settings
I haven't had a chance to think deeply about all the angle. A customer ran into an issue with `saveConfig` (they have >40 plugins, and heavy use of `autolink`, and they were unable to save config, blocking upgrade from `5.31` to `5.37`.
More to come.
See the original post here.
This issue was generated from Mattermost using the Doc Up plugin.
@sadohert - Can I get your help to clarify what's needed for this documentation request, please?
@aaronrothschild wondering if you can help here, or loop someone in from integrations/Apps.
From looking at the old customer thread, we ran into an issue where having AutomaticPrepackedPlugins == true
was driving Mattermost to reach out to find updated plugins versions for our prepackaged ones, for installation when a configuration change was triggered on Mattermost. If the customer is running in a heavily locked down network that doesn't allow servers to reach out to any internet endpoint it wants (without whitelisting) this was causing the API call for new plugins to timeout, which added to the time taken to propagate configuration in the HA cluster, which caused issues with the configuration persisting.
SOO, I THINK the note on this configuration property should clearly explain that Mattermost needs access to the Mattermost Marketplace APIs... and additional notes on the Security/HA pages making note that "If internet access from the Mattermost host is controlled through a proxy administrators need to white list the XYZ endpoitn on their proxy, or set AutomaticPrepackedPlugins == false
@levb do you know the details as to what sort of network access we expect when this flag is set?
AutomaticPrepackagedPlugins
managed if prepackged plugins are installed/updated. I doesn't change the fact that the server loads the full list of prepackged plugins from the file store on startup. This procedure might indeed a a while. But it only happens once.
Could it be that the customer has .PluginSettings.EnableRemoteMarketplace
enabled?
@aaronrothschild @sadohert @levb - Would you be open to assisting with this documentation update, please? I'm unclear about what's needed here.
Okay, finally getting back to this and digging up the history. Here's what I think we need to change:
- Configuration Settings Page - https://docs.mattermost.com/configure/configuration-settings.html#enable-remote-marketplace
We should explicitly tell admins about the endpoint that must be whitelisted for the "Remote Marketplace" to function. It should normally be https://api.integrations.mattermost.com
, however if the customer happens to configure the MarketplaceUrl
setting then that url needs to be whitelisted (I'm not sure this 2nd case would happen much/at all with customers... @aaronrothschild ?)
-
EnableMarketplace
Configuration - https://docs.mattermost.com/configure/configuration-settings.html#enable-marketplace
I'm not sure if there's anything to do here. Does the Marketplace function if its not "Remote"?? @aaronrothschild ?
- Enterprise Rollout Checklist
Need to put a pointer under https://docs.mattermost.com/getting-started/enterprise-roll-out-checklist.html?highlight=security#validate-essential-security-and-compliance-requirements that references the "Marketplace". Maybe we share a link to the Marketplace, and a link to the EnableMarketplace
docs, and then that configuration doc informs the admin about the whitelisting.
Other Notes:
- This Jira describes a UI configuration issue that was causing admin confusion when they were trying to set the
EnableRemoteMarketplace
setting tofalse
to avoid config changes failing the https://mattermost.atlassian.net/browse/MM-39602