Handle LocalSettings.php better #1

New Issue

3wordchant · 2020-09-05T00:28:22Z

3wordchant commented

2020-09-05 00:28:22 +00:00

We could generate LocalSettings.php ourselves instead of using the web installer.

Pros:

No need to keep track of MySQL passwords
Can set sensible defaults (like allowing file uploads & enabling Visual Editor)
Smoother eEventual route to app- or file-based deployment

Cons:

We have to add env vars for all the options Mediawiki exposes in its installer UI

In the mean-time, we could at least provide instructions on how to copy the generated LocalSettings.php into the container.

We could generate `LocalSettings.php` ourselves instead of using the web installer. Pros: - No need to keep track of MySQL passwords - Can set sensible defaults (like allowing file uploads & enabling Visual Editor) - Smoother eEventual route to app- or file-based deployment Cons: - We have to add env vars for all the options Mediawiki exposes in its installer UI In the mean-time, we could at least provide instructions on how to copy the generated `LocalSettings.php` into the container.

3wordchant referenced this issue

2020-09-05 00:28:38 +00:00

Add LocalSettings.php customisations for VisualEditor #2

3wordchant commented

2020-09-06 17:56:37 +00:00

I experimented with this in a new localsettings branch.

It works OK, but we'd need to run install.php after with correct options to initialise the database.

I experimented with this in a new [`localsettings` branch](https://git.autonomic.zone/compose-stacks/mediawiki/src/branch/localsettings). It works OK, but we'd need to run `install.php` after with correct options to initialise the database.

decentral1se commented

2020-09-06 23:14:36 +00:00

One "integrated" way to run initialisation stuff is to override the entrypoint with your own script, do your custom stuff and then call the original entrypoint script. See 9db9eca2cb/sbin/entrypoint.sh for this approach with the Alerta app. It doesn't always work because $docker. Another approach is to override the command but this often has an even less chance of success in my experience. See https://docs.docker.com/compose/compose-file/#command.

One "integrated" way to run initialisation stuff is to override the entrypoint with your own script, do your custom stuff and then call the original entrypoint script. See https://git.autonomic.zone/autonomic-cooperative/alerta.autonomic.zone/src/commit/9db9eca2cb0bdb451cc5d66d800b92f182db42ca/sbin/entrypoint.sh for this approach with the Alerta app. It doesn't always work because $docker. Another approach is to override the `command` but this often has an even less chance of success in my experience. See https://docs.docker.com/compose/compose-file/#command.

3wordchant commented

2020-09-07 11:55:30 +00:00

Both of those look awesome, thank you for the reminder - I was sure I'd seen a way of overriding the entrypoint script from the compose file, but couldn't find examples.

Am I right in thinking the entrypoint / command are run every time the stack is deployed? That's making me wonder if I should be customising the image instead so it's part of the build, but I was really hopeful to be able to use 3rd-party images unchanged :/

Both of those look awesome, thank you for the reminder - I was sure I'd seen a way of overriding the entrypoint script from the compose file, but couldn't find examples. Am I right in thinking the entrypoint / `command` are run every time the stack is deployed? That's making me wonder if I should be customising the image instead so it's part of the build, but I was *really* hopeful to be able to use 3rd-party images unchanged :/

decentral1se commented

2020-09-07 12:16:42 +00:00

Am I right in thinking the entrypoint / command are run every time the stack is deployed

Yes. So, you need to make sure your scripting handles the case where it is run after the first time. Depends on what you need to do. Sometimes it is easy. Like, you can just touch a file or something in the volume (if you have one) for a simple "did I run this already" check.

I was really hopeful to be able to use 3rd-party images unchanged :/

Yeah totally on board with not wanting to change those images, that is kind of the main promise of this approach.

> Am I right in thinking the entrypoint / command are run every time the stack is deployed Yes. So, you need to make sure your scripting handles the case where it is run after the first time. Depends on what you need to do. Sometimes it is easy. Like, you can just `touch` a file or something in the volume (if you have one) for a simple "did I run this already" check. > I was really hopeful to be able to use 3rd-party images unchanged :/ Yeah totally on board with not wanting to change those images, that is kind of the main promise of this approach.

👍 1

decentral1se commented

2020-09-07 12:18:13 +00:00

See 703b18ac0f/sbin/entrypoint.sh for a fairly hairy example of doing this overriding in the entrypoint and having checks for idempotent operation (this actually worked out quite well but is not very maintainable!).

See https://git.autonomic.zone/autonomic-cooperative/git.autonomic.zone/src/commit/703b18ac0f4e76052d6a3befc2124b22e44cabbe/sbin/entrypoint.sh for a fairly hairy example of doing this overriding in the entrypoint and having checks for idempotent operation (this actually worked out quite well but is not very maintainable!).

❤️ 1

3wordchant closed this issue

2020-09-07 21:23:49 +00:00

3wordchant commented

2020-09-07 21:24:02 +00:00

Thanks so much for all the tips!

I managed to hack my way through this (via truly heinous hack of putting the custom entrypoint in a Docker config) - it runs either mysql ... < maintenance/tables.sql or php maintenance/update.php depending on whether any tables exist.

The only outstanding issue is that, because we don't run install.php, it doesn't create an initial user. I'll open a separate task for that.

I'd also like to add a MEDIAWIKI_IS_PRIVATE (or something) setting, to toggle the $wgGroupPermissions section.

Thanks so much for all the tips! I managed to hack my way through this (via truly heinous hack of putting the custom entrypoint in a Docker `config`) - it runs either `mysql ... < maintenance/tables.sql` or `php maintenance/update.php` depending on whether any tables exist. The only outstanding issue is that, because we don't run `install.php`, it doesn't create an initial user. I'll open a separate task for that. I'd also like to add a `MEDIAWIKI_IS_PRIVATE` (or something) setting, to toggle the `$wgGroupPermissions` section.

3wordchant referenced this issue

2020-09-07 21:30:58 +00:00

Document or script adding an initial user #6

This repo is archived. You cannot comment on issues.

No Label

No Milestone

No Assignees

2 Participants

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/mediawiki#1