Docker: Fix etherpad user home dir for npm install

[m3adow]

I tried using sqlite with etherpad-lite, but npm install sqlite3 can't run because npm can't create its .npm directory as it's trying mkdir $HOME/.npm which currently evaluates to /.npm

etherpad@f717076dc742:/opt/etherpad-lite$ npm install sqlite3
npm ERR! code EACCES
npm ERR! syscall mkdir
npm ERR! path /.npm
npm ERR! errno -13
npm ERR! 
npm ERR! Your cache folder contains root-owned files, due to a bug in
npm ERR! previous versions of npm which has since been addressed.
npm ERR! 
npm ERR! To permanently fix this problem, please run:
npm ERR!   sudo chown -R 65534:65534 "/.npm"

This small change properly configures the home directory to /opt/etherpad-lite.

[muxator]

Thanks for finding the bug, @m3adow.

Isn't there a way to explicitly tell npm to put its .npm dir under /opt/etherpad-lite without changing the home directory of the etherpad user? I would prefer that.

I'll have a look at the npm documentation in the meantime.

[muxator]

Looking closer, I see that eea99fe seemingly set etherpad user's home directory to "/". @pierreprinetti, is there a specific reason for that?

[m3adow]

For my workaround build I added ENV HOME=/opt/etherpad-lite which has basically the same effect (see here: https://github.com/m3adow/dockerfiles/blob/master/etherpad-lite-sqlite/Dockerfile).

There is a npm command to set the cache: npm config set cache /tmp/npm, but this also fails due to the fact that .npmrc has to be created for that. And guess what, it's created in "$HOME", so effectively the same error.

From my point of view it's either change the home dir of the etherpad user to /opt/etherpad-lite like in this PR or create a specific home directory where the user has write permissions in, e.g. /home/etherpad. After some thinking I prefer the second method, as I don't think npm related stuff should be located in the /opt/etherpad-lite folder which may be volumized, especially not a cache.

[pierreprinetti]

I see that eea99fe seemingly set etherpad user's home directory to "/". @pierreprinetti, is there a specific reason for that?

Nope, that was an oversight. Thanks @m3adow for finding this!

[muxator]

What about replacing:

https://github.com/ether/etherpad-lite/blob/695c2d2e84b3f0046b8aaa715db21867465466db/Dockerfile#L43-L45

With a useradd + groupadd + nologin shell for the etherpad user inside the Dockerfile?

Maybe this could solve both problems in a non-surprising way.

[pierreprinetti]

A call to useradd (and groupadd) might be equivalent indeed. I'd just set an explicit -u (and -g) to make sure UID (and GID) don't change across builds, thus messing with volume permissions.

However, changing the home user to /opt/etherpad-lite works in my tests.

If I may ask, @m3adow , what is your use case for installing a npm package on a built container, versus something like this?

docker build --build-arg ETHERPAD_PLUGINS=sqlite3 -t etherpad:sqlite3 .

[muxator]

A call to useradd (and groupadd) might be equivalent indeed. I'd just set an explicit -u (and -g) to make sure UID (and GID) don't change across builds, thus messing with volume permissions.

Nice! I'd like that.

However, changing the home user to /opt/etherpad-lite works in my tests.

I am sure it works, my itch is then we would violate FHS (not that anyone cares, nowadays, but...).

If I may ask, @m3adow , what is your use case for installing a npm package on a built container, versus something like this?

I had the same curiosity, but then decided to back off: if a user wants to do something unexpected, let him be free and let's try to be as robust as possible :)

Do you think useradd/groupadd with explicit uid/gid be ok for fixing this problem?

[m3adow]

If I may ask, @m3adow , what is your use case for installing a npm package on a built container, versus something like this?

Twofold:

• I simply followed the output of the container when setting DB_TYPE=sqlite. I assumed it was an output from etherpad, but I understand now, that its most likely origin was ueberDB2.
• I build upon the existing image instead of forking the Dockerfile. This has the nice advantages of never lacking behind upstream as well as triggering auto builds on Docker Hub when the original image is rebuilt. I linked my Dockerfile earlier, but here it is again: https://github.com/m3adow/dockerfiles/blob/master/etherpad-lite-sqlite/Dockerfile

A call to useradd (and groupadd) might be equivalent indeed. I'd just set an explicit -u (and -g) to make sure UID (and GID) don't change across builds, thus messing with volume permissions.

That would've been my first proposal, but I assumed the user and group were created this way to minimize binary use, so it's easier to port the image to slim images like alpine in the future.

[pierreprinetti]

We have a double problem.

1. the etherpad user's $HOME does not exist
2. running npm install in /opt/etherpad-lite wil fail because the previous npm install was run by root and the current user has no permissions against node_modules.

Thus, if we want to enable installing further modules, here's my proposal:

1. create a home directory for letting npm create its cache
2. change permissions on /opt/etherpad-lite

The most straightforward way to 2. might be to create etherpad:etherpad before the first npm install, and use that one. That way, everything will be owned by the unprivileged user.

Here's my stab at it: #3676

Note that I have found out that 65534 is taken already in the base image (brutally appending to /etc/passwd was masking the conflict). I am using 5001 this time (totally made up). Unfortunately, this means that we again introduce annoyance to volume users.

[muxator]

Here's my stab at it: #3676

Let's go with that.

Unfortunately, this means that we again introduce annoyance to volume users.

Don't worry: we released beta1 for ironing out these problems.

[m3adow]

Well, I think #3676 deprectates my CR.

[pierreprinetti]

@m3adow sorry for taking over, that was not my initial intention. I ended up writing a possible solution while investigating the issue.

Thank you for finding and reporting the error I have introduced to the codebase!

[muxator]

Queued #3676. Thanks @m3adow for finding the issue!

Aside: due to our conversation, and various considerations I was doing recently, I've opened #3675 to bring the database access layer into the code base. The work on that will take place after 1.8.0 is finally released, but I would like to start the discussion in the meantime.