Project

General

Profile

Grant redmine write access on the db/ folder

Added by Quentin Aymard 5 days ago

Hi,

I am running a custom Docker image packaging a production-ready Redmine. It is designed to run in root-less, read-only mode, so I pay extra attention to required permissions on various folders.

Right now, the application is started with user redmine, which have read access to the entire app, but write access only to three bind-mounted folders : files/, log/ and plugins/, as required by the installation documentation. I am now trying to integrate Redmine DB migrations and plugin migrations to this image. Several questions arose in this context, for which I can't find definitive answers in the available documentation :

User performing rake tasks

  • Without any modification, running migrations with the redmine user fails, because rake cannot write in the db/ folder. This is perfectly expected in the current state of this image.
  • Without any modification, running migrations with the root user succeeds, because rake is now able to write the db/ folder. This is also perfectly fine.

The first question is the following : is it better to run migrations with the redmine user, or the root user ? Does this makes any difference at all ?

Migrations periodicity

Running rake migrations as redmine would allow me to very easily run them each time the container starts (adding the commands to the entrypoint). This eliminate the risk of forgetting migrations on upgrade, but would require giving redmine write access on the db/ folder.

On the other hand, running rake migrations as root would allow me to NOT give redmine write access to db/, but consequently would require some adaptations to run migrations from the entrypoint. I don't really want the entrypoint to be able to run anything as root, to be honest, so I could also give up with the idea of auto-migrations on startup, and maintain this as a manual-only, root-only task the admin need to perform after upgrading.

The second question is consequently : is it relevant to run rake db:migrate / rake redmine:plugins:migrate / rake tmp:cache:clear with each startup ? Or is it considered bad practice ?

Mount-bind the db/ folder

As of now, the db/ folder is pretty much empty. Calling rake migrations populate it with various .rb files which, I guess, are used to update the database. I am still quite the beginner regarding Rails, Rake and overall the Ruby ecosystem, so the third and last question arise :

Should I keep the content of db/ persistent over container's reboots ?

I can easily add a bint-mount to this folder so the content is persisted, and I guess future rake calls will update it without problems. Is doing this useful ? I imagine keeping previous migration files can slightly improve startup time by somehow preventing the next migration to re-create everything from scratch (especially if I'm running migrations from the container's entrypoint), but I am not sure of how these migrations are computed. If rake have to reprocess everything each time, sparing only the disk-writing time, adding a bind-mount to this folder might not be very useful.

Let me know if any other bit of context is required to make myself clear