If user cleanly follow install instructions Setup app will create nginx
`default.conf` (and other files) with `644` permission owned by
`bitwarden:bitwarden`.
During Nginx entrypoint script it copies generated `default.conf` to
`/etc/nginx/conf.d/` but without `-p` flag new file permissions would be
`root:root 644`.
Then during startup Nginx will start as `bitwarden` user, which will not
cause any issues by itself as `default.conf` is still readable by the
world.
The issue is that for some reason some users have their Nginx config
file (or sometimes even entire `bwdata` recursively) have `600` or `700`
permissions. In this case Nginx will fail to start due to `default.conf`
not readable by `bitwarden` user.
I assume that root cause is that some users mistakenly run `sudo chmod
-R 700 /opt/bitwarden` from Linux installation guide after they have run
`./bitwarden.sh install`. Or maybe some older version of Setup app where
creating `default.conf` with `600` permissions and users are using very
legacy installations.
Whatever may be the case I do not see any harm with copying with `-p` it
even looks to me that this was the intended behavior. This will both fix
the issue for mentioned users and preserve permission structure aligned
with other files.
* Use user primary group if not root
* Do not run getent on MacOS
* Simplify UID/GID management
* Make uid.env backward compatible in run.sh
* Merge install.sh with run.sh to avoid duplicating code
Especially the UID/GID management one
* Generate correct OS name
* Be sure to keep old behavior for backward compatiblilty
* Get the colors back from install.sh
