The Docker entrypoint scripts set values for the `upload_max_filesize`
and `post_max_size` directives in `php.ini` based on the value of the
`PHP_UPLOAD_LIMIT` environment variable, subject to the following
restrictions:
* Exactly one file matches `/etc/php/*/apache2/php.ini` (on Ubuntu) or
`/etc/php*/php.ini` (on Alpine) - if, for example, more than one PHP
package is installed in the base image, `PHP_UPLOAD_LIMIT` will not be
honoured.
* The `php.ini` file already sets a non-default value for the
`upload_max_filesize` or `post_max_size` directives - this is
currently the case for the configurations inherited from upstream, but
is not guaranteed. If the default values are relied upon,
`PHP_UPLOAD_LIMIT` will silently not be honoured (although the script
output will claim that it is).
Iterate over the lines outputted by `file(1)` so `PHP_UPLOAD_LIMIT` is
honoured in all available `php.ini` files, and set `upload_max_filesize`
and `post_max_size` regardless of whether they already have a value set.
FIXES: https://github.com/grokability/snipe-it/issues/12725
In some of our Docker startups, it was possible for the Laravel log file
to be created with root permissions, causing future errors when the
non-root webapp tries to write to it.
We'll now always chown (and create, if necessary) the log file to the proper
user after running any artisan commands (as root)
We _could_ run them as the proper user via su, but IMO not doing so keeps the
script easier to read, but I'm not married to the approach. I'd still
want to keep the chown command(s) in, because it will also fix the
permissions for anyone who already has this issue.
Chris Novakovic