Configurable file storage locations #886
Conversation
It may be desirable to log to a more standard location (e.g. in /var/log/), or in some cases to turn logging to file off. To support these, use a custom config property to determine the location of the output log file, and default to the previous location if it is unset.
|
|
|
Hi! Thanks for your PR. I'll check it out now and work on getting it accepted :) |
|
Sorry for the question, do you have a sample configuration for saving files outside of the app folder? I also noticed that |
You'll probably want to tweak this some, and not all of these steps are strictly necessary, but this was my setup process:
Probably in your case the only bit that really matters is deploying the app to a directory and making the whole thing read-only, and then making some target directories elsewhere (parent directory would do fine). You won't need an additional user, or to put it under I've been running the app with the following to test:
That's a fair question. I thought about adding it to the config file, but to retain the old behavior when it's not set it needs to be... [Some investigating later...] Experimentally the value is |
|
Pushed a commit to add the temp-directory parameter to the custom-config file, and to add some package-lock file rejiggering npm wanted to do (should have gone in with the addition of the serve-static dep). I'll squash those before this gets merged, I didn't want to do a force-push if you were working with a checkout. |
|
Thanks for the answer! I understand now, you set the paths via Everything works correctly, so ready to merge. Feel free to force push if that's easier :) |
This involves a couple primary changes: 1) to make Sails' temporary file-upload directory a configurable location by using a common file-upload-receiving helper; 2) to create custom static routes for the file-upload locations, so they can be outside the application's public directory; and 3) to use the file-uploading handler everywhere that receives files, so config for the helper is applied to all file uploads consistently. This is sufficient to allow the application directory to be deployed read- only, with writable storage used for file uploads. The new config property for Sails' temporary upload directory, combined with the existing settings for user-avatar and background-image locations are sufficient to handle uploads; the new custom routes handle serving those files from external locations. The default behavior of the application should be unchanged, with files uploaded to, and served from, the public directory if the relevant config properties aren't set to other values.
mtstickney
force-pushed
the
configurable_file_locations
branch
from
6305bd8
to
13f0a68
Compare
|
Squashed and pushed. The sails custom-config env vars are kind of an awkward way to do config, but at this point I'm just going for something that works. |
|
Thanks! And a special thanks for the code quality and comments, it's a next-level for me.
It would be easy to add this to the file with env variables if someone else asks this feature. |
I wanted to package planka for deployment as a regular system service on linux (not in a container). Packaging standards and the filesystem conventions on linux require static code, configuration, and writable data directories to be separated.
Specifically, the directories for user-uploaded files (project backgrounds, user avatars), card attachments, and the server logfile need to be outside the main directory.
There are already custom-config properties to set the location of the upload directories, but they are served with the default static-file route in Sails, which means they can only be in subdirectories of the
public/directory (this contains the app code, so in a normal deploy this directory isn't going to be writable).To fix that, I've added two custom routes that will serve project backgrounds and user avatars from the configured directories (card attachments are already handled by a separate controller), which can now reside outside the app dir.
To make the file-upload directory configurable, I added a helper to receive files, which uses an optional custom config property to control that directory -- this gets us a configurable location for all uploaded files, including backgrounds, avatars, attachments and import files.
Finally, I added an environment variable to control the location the server tries to write logs (this doesn't seem to actually get used, but it will still try to create the file).
With those things in place, and with the right overrides of them, the app can be run from a write-only directory, with all the file-writing done elsewhere, as it would in a normal linux deployment. Without customizing any of the custom properties, the behavior should be the same as it was previously, so running it from a checkout in dev or in a container shouldn't be affected.