Docker deployment with custom site_settings.yml

SSO
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.

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
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.

1 Like
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?

1 Like
4

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

https://github.com/discourse/discourse/blob/master/config/site_settings.yml#L12-L14

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.

1 Like
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.

2 Likes
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:

1 Like
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 https://github.com/discourse/discourse/blob/master/app/models/site_setting.rb