bower asking for allow-root option
bretmette opened this issue · 14 comments
src elvis$ bower install featherlight --save
bower ESUDO Cannot be run with sudo
Additional error details:
Since bower is a user command, there is no need to execute it with superuser permissions.
If you're having permission errors when using bower without sudo, please spend a few minutes learning more about how your system should work and make any necessary repairs.
http://www.joyent.com/blog/installing-node-and-npm
https://gist.github.com/isaacs/579814
You can however run a command with sudo using --allow-root option
Not sure if I accidentally modified something or if this is a known issue. Have you seen this before? For now I am just executing with --allow-root and it is not effecting the permissions on the host. What are your thoughts @mkenney ?
Interesting, I haven't seen that before. I'm guessing you're using the script from the bin directory, that executes a script in the container that uses sudo to run as someone other than root. Based on this thread I'm guessing it's a relatively recent change.
I'll take a look but I may just add --allow-root to the bower script since it's not actually running as root at that point.
@mkenney I'll try it out on a few different environments / operating systems. I do not recall this happening every time, in-fact I believe it only happened once. I'll see what I can find. But yeah maybe adding the --allow-root might be a viable option. Can you think of any side-effects from that?
$ ~/bin/bower install --save lightslider
bower lightslider#* not-cached https://github.com/sachinchoolur/lightslider.git#*
bower lightslider#* resolve https://github.com/sachinchoolur/lightslider.git#*
bower lightslider#* checkout 1.1.5
bower lightslider#* invalid-meta The "main" field cannot contain minified files
bower lightslider#* invalid-meta The "main" field cannot contain minified files
bower lightslider#* invalid-meta The "main" field cannot contain font, image, audio, or video files
bower lightslider#* resolved https://github.com/sachinchoolur/lightslider.git#1.1.5
bower lightslider#^1.1.5 install lightslider#1.1.5
$ ~/bin/bower -v
1.7.9
$ cat /etc/issue
Ubuntu 16.04.1 LTS \n \l
$ uname -a
Linux pure 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ docker -v
Docker version 1.12.1, build 23cf638
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
gulp latest d7200703265c 4 days ago 465.4 MB
monostream/nodejs-gulp-bower latest 2ee6e3fca96a 6 days ago 320.6 MB
mkenney/npm latest 8b2c6e4ec27d 13 days ago 772.9 MB
ubuntu 16.04 f8d79ba03c00 2 weeks ago 126.4 MB
3bdigital/bower-grunt-gulp latest 82657bc89477 8 weeks ago 295.7 MB
$ docker history 8b2c6e4ec27d
IMAGE CREATED CREATED BY SIZE COMMENT
8b2c6e4ec27d 13 days ago /bin/sh -c #(nop) CMD ["/run-as-user" "/usr/ 0 B
<missing> 13 days ago /bin/sh -c #(nop) WORKDIR /src 0 B
<missing> 13 days ago /bin/sh -c #(nop) VOLUME [/src] 0 B
<missing> 13 days ago /bin/sh -c set -x && apt-get -qq update 121.6 MB
<missing> 13 days ago /bin/sh -c #(nop) ENV TIMEZONE=America/Denve 0 B
<missing> 13 days ago /bin/sh -c #(nop) ENV LC_ALL=C.UTF-8 0 B
<missing> 13 days ago /bin/sh -c #(nop) ENV LANGUAGE=C.UTF-8 0 B
<missing> 13 days ago /bin/sh -c #(nop) ENV LANG=C.UTF-8 0 B
<missing> 13 days ago /bin/sh -c #(nop) ENV NLS_LANG=American_Amer 0 B
<missing> 13 days ago /bin/sh -c #(nop) ENV PATH=/root/bin:/usr/lo 0 B
<missing> 13 days ago /bin/sh -c #(nop) MAINTAINER Michael Kenney 0 B
<missing> 2 weeks ago /bin/sh -c #(nop) CMD ["node"] 0 B
<missing> 2 weeks ago /bin/sh -c curl -SLO "https://nodejs.org/dist 41.21 MB
<missing> 2 weeks ago /bin/sh -c #(nop) ENV NODE_VERSION=6.4.0 0 B
<missing> 4 weeks ago /bin/sh -c #(nop) ENV NPM_CONFIG_LOGLEVEL=inf 0 B
<missing> 4 weeks ago /bin/sh -c set -ex && for key in 9554F0 80.83 kB
<missing> 4 weeks ago /bin/sh -c apt-get update && apt-get install 318.1 MB
<missing> 4 weeks ago /bin/sh -c apt-get update && apt-get install 122.6 MB
<missing> 4 weeks ago /bin/sh -c apt-get update && apt-get install 44.28 MB
<missing> 4 weeks ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0 B
<missing> 4 weeks ago /bin/sh -c #(nop) ADD file:0e0565652aa852f620 125.1 MB
Worked without asking for the --allow-root. This was on a web server hosted at DigitalOcean. Pretty fresh setup of Ubuntu 16.04. Let me know if any other information is needed to be helpful. I am still pretty new to docker.
Here is that same info from my OS X install (which is still complaining about --allow-root, just tested again, same output).
bmette$ ~/bin/bower -v
1.7.9
bmette$ uname -a
Darwin Bret-Mettes-MacBook-Pro.local 14.5.0 Darwin Kernel Version 14.5.0: Thu Jun 16 19:58:21 PDT 2016; root:xnu-2782.50.4~1/RELEASE_X86_64 x86_64
bmette$ docker -v
Docker version 1.12.0, build 8eab29e
bmette$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
theplan_php latest 5bcb63a8906b 14 hours ago 387.1 MB
theplan_nginx latest 33a13b87b7af 14 hours ago 183.4 MB
<none> <none> 8a404b837a4d 14 hours ago 382.3 MB
src_nginx latest 085d8a5e40c7 24 hours ago 183.4 MB
mkenney/npm latest 042cccdb8987 3 days ago 790.7 MB
mkenney/php-base latest c19ee2aacaeb 5 days ago 783.4 MB
mkenney/composer php7 b2c1eb6397b2 5 days ago 93.93 MB
php 5.6-fpm 97534366f528 6 days ago 363.6 MB
src_php latest 97534366f528 6 days ago 363.6 MB
nginx latest 4efb2fcdb1ab 7 days ago 183.4 MB
mariadb 10.0.19 033147d313e2 14 months ago 257.7 MB
bmette$ docker history 042cccdb8987
IMAGE CREATED CREATED BY SIZE COMMENT
042cccdb8987 3 days ago /bin/sh -c #(nop) CMD ["/run-as-user" "/usr/ 0 B
<missing> 3 days ago /bin/sh -c #(nop) WORKDIR /src 0 B
<missing> 3 days ago /bin/sh -c #(nop) VOLUME [/src] 0 B
<missing> 3 days ago /bin/sh -c set -x && apt-get -qq update 138.3 MB
<missing> 3 days ago /bin/sh -c #(nop) ENV TIMEZONE=America/Denve 0 B
<missing> 3 days ago /bin/sh -c #(nop) ENV LC_ALL=C.UTF-8 0 B
<missing> 3 days ago /bin/sh -c #(nop) ENV LANGUAGE=C.UTF-8 0 B
<missing> 3 days ago /bin/sh -c #(nop) ENV LANG=C.UTF-8 0 B
<missing> 3 days ago /bin/sh -c #(nop) ENV NLS_LANG=American_Amer 0 B
<missing> 3 days ago /bin/sh -c #(nop) ENV PATH=/root/bin:/usr/lo 0 B
<missing> 3 days ago /bin/sh -c #(nop) MAINTAINER Michael Kenney 0 B
<missing> 4 days ago /bin/sh -c #(nop) CMD ["node"] 0 B
<missing> 4 days ago /bin/sh -c curl -SLO "https://nodejs.org/dist 41.21 MB
<missing> 4 days ago /bin/sh -c #(nop) ENV NODE_VERSION=6.4.0 0 B
<missing> 4 days ago /bin/sh -c #(nop) ENV NPM_CONFIG_LOGLEVEL=inf 0 B
<missing> 4 days ago /bin/sh -c set -ex && for key in 9554F0 80.83 kB
<missing> 6 days ago /bin/sh -c apt-get update && apt-get install 319.1 MB
<missing> 4 weeks ago /bin/sh -c apt-get update && apt-get install 122.6 MB
<missing> 4 weeks ago /bin/sh -c apt-get update && apt-get install 44.3 MB
<missing> 4 weeks ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0 B
<missing> 4 weeks ago /bin/sh -c #(nop) ADD file:0e0565652aa852f620 125.1 MB
Just touching base, I haven't had a chance to dig in yet (I broke my wrist pretty badly so everything I type is with one hand) but I did try to replicate it on my CentOS dev server and it seemed to work fine, and I triggered a successful build in TravisCI (debian). The TravisCI build was for the master (debian) version, not the alpine version so that may be related.
The alpine build stopped working recently (can't find the shadow package) so I either need to fix that or re-work the /run-as-user script to work with simpler tools.
Ahh, sorry to hear about your wrist. That sounds like a major road block in production all around.
Yeah, on my ubuntu droplet it worked without a problem. I am only seeing an issue on OS X currently. Applying the --allow-root is obviously no big deal to do and I haven't seen any side-effects from it but I'm not entirely sure how the container works so I can't really comment intelligently.
Did you have anything in-mind for how to rework the /run-as-user script?
Docker is a pain on my Mac but I'm testing it now. So far it has worked for me with the current hub image
$ bower install featherlight --save
bower featherlight#* not-cached https://github.com/noelboss/featherlight.git#*
bower featherlight#* resolve https://github.com/noelboss/featherlight.git#*
bower featherlight#^1.5.0 not-cached https://github.com/noelboss/featherlight.git#^1.5.0
bower featherlight#^1.5.0 resolve https://github.com/noelboss/featherlight.git#^1.5.0
bower jquery#^3.0.0 not-cached https://github.com/jquery/jquery-dist.git#^3.0.0
bower jquery#^3.0.0 resolve https://github.com/jquery/jquery-dist.git#^3.0.0
bower featherlight#^1.5.0 checkout 1.5.0
bower featherlight#* checkout 1.5.0
bower jquery#^3.0.0 checkout 3.1.0
bower jquery#^3.0.0 resolved https://github.com/jquery/jquery-dist.git#3.1.0
bower featherlight#* invalid-meta The "main" field cannot contain minified files
bower featherlight#* invalid-meta The "main" field cannot contain minified files
bower featherlight#^1.5.0 invalid-meta The "main" field cannot contain minified files
bower featherlight#^1.5.0 invalid-meta The "main" field cannot contain minified files
bower featherlight#* resolved https://github.com/noelboss/featherlight.git#1.5.0
bower featherlight#^1.5.0 resolved https://github.com/noelboss/featherlight.git#1.5.0
bower jquery#^3.0.0 install jquery#3.1.0
bower featherlight#^1.5.0 install featherlight#1.5.0
So I'm at a loss. The way the container works is it mounts the current directory into the container when the bower script executes docker run and inside the container /run-as-user bower <cmd> is executed (/run-as-user bower install featherlight --save for example). The /run-as-user script modifies the user dev to force it to use the uid and gid of the current directory (or your ~/.ssh directory if one exists on the host for your user) and then uses sudo to execute the command as that user (just sudo -u dev $@). That way the files are written out with the right owner and group. So, I don't see how it could be dependent on the host OS.
I've tested on these environments:
- OS X v10.9.5 / Docker v1.9.0
- CentOS v7.2 / Docker v1.8.2-el7.centos
- CentOS v7.2 / Docker v1.10.3
- Debian v3.16.7-ckt25-2 / Docker v1.11.2
- Whatever versions of debian and docker TravisCI is running, I'll have to check
Anyway, because it's using sudo to switch away from root to the dev user, I can't think of any negative side-effects to the --allow-root option since that's really just allowing sudo, not root, but since it's running out of the container it should be OS agnostic. Can you try pulling down the latest image from the hub (if you haven't already) and see if that makes any difference?
bmette$ docker pull mkenney/npm
Using default tag: latest
latest: Pulling from mkenney/npm
8ad8b3f87b37: Pull complete
751fe39c4d34: Pull complete
ae3b77eefc06: Pull complete
7783aac582ec: Pull complete
393ad8a32e58: Pull complete
2d923dade19b: Pull complete
69e1413bc6d8: Pull complete
23f95aba79f0: Pull complete
Digest: sha256:1a600941d3c8181709dc9b9184dcdc76855ebbe5c8963f649b6b552f18d75d34
Status: Downloaded newer image for mkenney/npm:latest
bmette$ which bower
/Users/bmette/bin/bower
bmette$ bower -v
1.7.9
bmette$ bower install --save featherlight
bower ESUDO Cannot be run with sudo
Additional error details:
Since bower is a user command, there is no need to execute it with superuser permissions.
If you're having permission errors when using bower without sudo, please spend a few minutes learning more about how your system should work and make any necessary repairs.
http://www.joyent.com/blog/installing-node-and-npm
https://gist.github.com/isaacs/579814
You can however run a command with sudo using --allow-root option
OS X 10.10.5
Docker Version 1.12.0-a (build: 11213)
ad6ab836187e4111082447b7c0a6a74d01929a5c
mkenney/npm latest 7a4f18d6ccb1 41 hours ago 799 MB
Well... I am at a loss as well. Do you know how an we verify that our containers are the same?
cat ~/bin/bower
#!/usr/bin/env sh
TAG=latest
BRANCH=master
if [ "self-update" = "$1" ]; then
docker pull mkenney/npm:$TAG
wget -nv --no-check-certificate -O $0 https://raw.githubusercontent.com/mkenney/docker-npm/$BRANCH/bin/bower && exit 0
else
docker run --rm -t -i -v $(pwd):/src:rw -v $HOME/.ssh:/home/dev/.ssh:ro mkenney/npm:$TAG /run-as-user /usr/local/bin/bower $@
fi
Here is my script as well.
I haven't forgotten about this. I'm going to try look some more this weekend. I've also solved the alpine build issues but I haven't committed them just yet, I'd like to do some more testing. If that works out, I'm going to tag the alpine build as latest because its less than 1/5 the size.
@bretmette So I went ahead and added the --allow-root option in cf3ef60 I don't see any reason not to have it, but I wasn't able to reproduce the issue either.
I made a few other changes too, but the biggest was switching the latest image from Debian to Alpine so it should be much smaller (328MB to 68MB).
Let me know if it gives you any trouble!
@mkenney Been swamped these past few days. Also regarding the switch to Debian. Did you mean to say you switched from Ubuntu to Debian? Looks like the two options now are Alpine and Debian, correct? I will pull down the Debian one and give it a go and provide feedback as needed.
Hey @bretmette,
No, the Debian image hasn't changed. I just pointed the latest tag on docker hub to the alpine image (it was the debian image) and updated the master branch here to use the alpine Dockerfile. The Debian stuff is in the debian branch here.
Mainly because the alpine image is ~68MB and the debian image is ~300MB.