Docker deployment with custom site_settings.yml

Support SSO

AI-generated summary

Customizing site_settings.yml with Docker Deployment

The discussion revolves around customizing site_settings.yml when deploying Discourse using Docker. zingbats initially asked if there’s a way to customize site_settings.yml without breaking the Docker deployment method.

rking suggested setting site settings through the UI, which saves to the database, and sam mentioned that settings flagged with shadowed_by_global can be passed in via environment variables. However, for settings not flagged as such, a custom plugin or server API can be used.

captainmisterhagan needed to modify the constraints of the password length, which is not globally shadowed. rking suggested creating a custom plugin with a site_settings.yml file to replace the setting definition.

The discussion concluded with captainmisterhagan successfully implementing the custom plugin, and rking recommending the migrated password plugin to handle legacy passwords. Additionally, captainmisterhagan corrected the file name to settings.yml based on the Discourse code.

1

Hello,

I’m trying to follow the SSO instructions, which requires a site_settings.yml customization. I’m currently deploying to production using docker using GitHub - discourse/discourse_docker: A Docker image for Discourse · GitHub.

Is there a supported way to customize site_settings.yml without breaking the whole docker deployment method?

Also, in pursuit of SSO goodness I found this plugin GitHub - mikamai/discourse-doorkeeper-sso: authentication plugin for discourse to be used with a doorkeeper oauth provider · GitHub
which requires a secret key to be installed into the plugins directory.

The only way I can see to achieve this is to add a volume to the docker container so that the discourse app lives on the host, not in the docker image. So I think that would mean /var/www/discourse needs to live on the host.

Also, is anyone doing discourse development/deployment with Docker? Anyone have a Docker-compose file they’d share?

2

What? No, just set the site settings through the ui, which gets saved to the database. The yml file lists the defaults and type info.

3

Resurrecting this topic because it’s exactly on point for my question.

The UI lets us modify within the constraints built in the settings file.

I have a need to be able to modify those constraints, enabling me to set a value in the UI outside of the current min:max. Has anyone constructed a preferred mechanism for this? The one that springs to mind is to modify containers/app.yml and overwrite a file copy of site_settings.yml in the guest. Can anyone improve on that?

4

for all the settings flagged with shadowed_by_global can be passed in via env:

Any settings that are not can be amended either via server api or you could include a script to change them. If you must amend the defaults you would need to create a custom plugin.

5

Thanks, Sam.

In this particular instance I’m looking to change some of the constraints around password length. That’s not globally shadowed (which is, by the way, a nice and readable solution to the problem).

If I were to use a custom plugin, I guess I’d go about that by setting the SiteSettings value during the initialisation of the plugin in Rubyland? I’ll give that a shot.

6

Even simpler, I believe you can simply provide a site_settings.yml in your plugin that replaces the setting definition.

(I do worry about the fact that you’re changing min password length, though - the common passwords protection doesn’t take into account lengths under 10.)

7

Where do I provide the site settings in the plugin?

I totally agree with the whole security concern. I really do. There are legacy passwords in there that must be respected and this is a particular client group that has issues with changing their passwords. It’s… A whole complicated story, and it has a hostile party who might have access to their email as part of it.

I’m drawing the line for the admins and moderators, they have to change to a secure, generated credential. But these old members aren’t contactable safely and if we dont respect their old credentials we lose them. And if we lose them from this therapeutic context they slip through the cracks.

8

Ah. Also take a look at the migrated password plugin: Migrated password hashes support

The file is config/site_settings.yml in the plugin, just like in the main part of Discourse.

9

Yep, got that working except for the ones which are too short. Thanks!

In fact we patched it a tiny bit to increase its scope to phpbb3 in standard configuration :grinning_face:

10

I think, perhaps, it is settings.yml, based on

unless Rails.env.test? && ENV['LOAD_PLUGINS'] != "1"
  Dir[File.join(Rails.root, "plugins", "*", "config", "settings.yml")].each do |file|
    load_settings(file)
  end
end

from discourse/app/models/site_setting.rb at main · discourse/discourse · GitHub