Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Templating does not work if only /tmp is writable #88

Open
lioman opened this issue Apr 14, 2022 · 9 comments
Open

Templating does not work if only /tmp is writable #88

lioman opened this issue Apr 14, 2022 · 9 comments

Comments

@lioman
Copy link

lioman commented Apr 14, 2022

Describe the bug

If you use nginx templating function the filled template can not be saved if /etc/nginx/conf.d is not writable.

To reproduce

Steps to reproduce the behavior:

  1. Build a NGINX Unprivileged Docker image with an default.conf.template in /etc/nginx/templates
  2. Deploy the container in environment, where only /tmp is writable
  3. See error in log, that template can not be written to /etc/nginx/conf.d

Expected behavior

In a unprivileged environment, I expect, that templates ca be written and used.

@alessfg
Copy link
Collaborator

alessfg commented Apr 14, 2022

Let me look into this once I have some time and get back to you. It might be a little while (I have a hefty backlog atm) but I'll update the issue when I have had time to dig into this 😄

@asamofal
Copy link

asamofal commented May 16, 2022

@lioman Probable I've faced the same issue:

ERROR: /etc/nginx/templates exists, but /etc/nginx/conf.d is not writable

In my case the reason was in user property for nginx service in docker compose config. As I've changed the UID/GID of the user inside container, permissions of /etc/nginx/ dir (recursively) started mismatch for running user.
/etc/nginx/conf.d dir permissions is:

drwxrwxr-x 1 nginx root 4096 May 16 18:06 conf.d

By default nginx user resolves to 101 UID. So setting the UID to something else breaking the permissions and config can't be created from template.

In my case I've solved the problem by setting GID of the user to 0 (this is root). In this case script that creates a config file has write access to /etc/nginx/conf.d by group permissions.

So if you change UID/GID of the user (in docker compose config or create a new user in your Dockerfile) don't forget to update correspondent permissions for some paths:

  • /var/cache/nginx
  • /etc/nginx
  • /var/log/nginx

@alessfg
Copy link
Collaborator

alessfg commented May 23, 2022

Have you had a chance to try the above steps @lioman?

@JPeer264
Copy link

JPeer264 commented Aug 5, 2022

We actually still have the problem. Changing the UID/GID to 0 is not an option as we run on 65532. But to answer the question yes it does work with root.

@MatthiasWinzeler
Copy link

we're happy users of this docker image, but noticed that it is incompatible with kubernetes' readonlyRootFilesystem: true (which becomes more and more best practice these days) - the following warnings appear at startup.

/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: can not modify /etc/nginx/conf.d/default.conf (read-only file system?)
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
20-envsubst-on-templates.sh: ERROR: /etc/nginx/templates exists, but /etc/nginx/conf.d is not writable
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up

I'm not sure this can be easily fixed, since the entrypoint scripts relied on the config being writable, which is AFAIK against the philosophy of having readonlyRootFilesystem: true.

@alessfg
Copy link
Collaborator

alessfg commented Sep 19, 2022

You are correct in that the entrypoint script rely on the config being writable. The goal is to add some QoL config changes that are environment dependent. There might be room to host an image that doesn't do any of those changes but I'll have to think and talk to the maintainers of the upstream Docker NGINX image about it.

@alessfg
Copy link
Collaborator

alessfg commented Sep 19, 2022

To go back to the previous discussions, there is an option to change the default UID/GID by passing a new value as an ARG at build time(https://github.com/nginxinc/docker-nginx-unprivileged/blob/main/mainline/alpine/Dockerfile#L15-L16).

Setting a new value when the image is being built should change the NGINX UID, but you'll have to rebuild the image vs using the images on Docker hub.

@Meettya
Copy link

Meettya commented Mar 2, 2023

As work-around solution:

  1. Set in Dockerfile
ENV     NGINX_ENVSUBST_OUTPUT_DIR=/tmp/nginx/conf.d
RUN     mkdir -p        /tmp/nginx/conf.d
  1. Get processed file as
include /tmp/nginx/conf.d/*.conf;

@monosoul
Copy link

A message to passing by strugglers like me:

No need to rebuild the image, you can make it work with just the right mount points. See this docker compose example:
https://gist.github.com/monosoul/e462b03cba5542bfc52f135417a8209d

Kudos to @Meettya for the idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants