Open samip5 opened 2 months ago
It seems relevant:
k logs your-spotify-web-c854ddd8-skclb
cp: can't create '/app/apps/client/build/variables.js': File exists
Setting API Endpoint to 'https://s-api.skylab.fi'
sed: can't create temp file '/app/apps/client/build/variables.jsXXXXXX': Permission denied
sed: can't create temp file '/app/apps/client/build/index.htmlXXXXXX': Permission denied
sed: can't create temp file '/app/apps/client/build/index.htmlXXXXXX': Permission denied
sed: can't create temp file '/app/apps/client/scripts/run/serve.jsonXXXXXX': Permission denied
ls -al /app/apps/client/
total 4
drwxr-xr-x 1 root root 19 Mar 24 00:10 .
drwxr-xr-x 1 root root 20 Mar 24 00:10 ..
drwxr-xr-x 3 root root 4096 Mar 24 00:10 build
drwxr-xr-x 4 root root 30 Mar 24 00:07 scripts
I'm running it as unprivileged, so that's a problem.
Hello, before starting the client server, it overrides some of the built files according to your environment. It seems like it gets permission denied in your case, which is why the files stay untouched and the client gets the default value of localhost.
Hello, before starting the client server, it overrides some of the built files according to your environment. It seems like it gets permission denied in your case, which is why the files stay untouched and the client gets the default value of localhost.
Which should be a) documented and b) not require root permissions so it should probably use an unprivileged user instead of eg node aka uid 1000 which seems to exist in the container.
Using a non-root
user in the container images would be nice, I agree.
I assume if you submit a pull request implementing that, it would have a good chance of being merged.
However, I disagree with your notion that you expect a container image to work when you change the UID that is being used. In general, you will have trouble finding container images that still work after you change the UID from the outside like that. Many images (including typical web servers and "official" library images) rewrite configuration files in the entrypoint script when they start up. When you change the user ID from the outside, that will fail in almost all cases.
rewrite configuration files in the entrypoint script
Which is not really great, same goes for s6-overlay (as a lot of images use either of these things). I even tried to mount just that specific path properly but as the whole app lives there, it's not really workable.
I'm afraid if I change the UID of the user in the container now, all the current instances of YourSpotify will break. If you have any idea on how to proceed I would be more than happy to implement.
I'm afraid if I change the UID of the user in the container now, all the current instances of YourSpotify will break. If you have any idea on how to proceed I would be more than happy to implement.
It should be enough to just change the group of the files/folders so that root AND eg group users or node or something can write.
I'm afraid if I change the UID of the user in the container now, all the current instances of YourSpotify will break.
Neither the backend nor the frontend containers should have persistent data volumes in most deployments. The sample compose files don't define volumes for these containers, and I don't think any user has reason to define volumes for them, as the MongoDB handles all data persistence.
Can you elaborate on how changing the user in the Dockerfile
would break existing installations on update?
You're right. I was thinking about changing the UID of the mongo too but it is not needed so I think we could change the UID yeah. Might try that when I have a bit of time.
The mongodb container image starts as root
, but drops its permissions to a different user in the entrypoint script, so that's already handled by the MongoDB maintainers.
(Which, by the way, is great example why forcing a different UID onto a container in the compose file/kubernetes deployment breaks existing images in 99% of cases.)
The mongodb container image starts as
root
, but drops its permissions to a different user in the entrypoint script, so that's already handled by the MongoDB maintainers.(Which, by the way, is great example why forcing a different UID onto a container in the compose file/kubernetes deployment breaks existing images in 99% of cases.)
Which is an example of an s6-overlay when it does that.
Describe the bug
It seems that the API_ENDPOINT env variable is not being respected by the web client for unknown reasons?
Expected behavior
I would have expected it to be enough to set the API_ENDPOINT to the one the API is reacheable at without port, so eg
https://s-api.skylab.fi
but it still tries to use localhost instead.Additional context
Screenshots