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

busybox #14

Open
yoshuawuyts opened this issue Nov 7, 2014 · 18 comments
Open

busybox #14

yoshuawuyts opened this issue Nov 7, 2014 · 18 comments

Comments

@yoshuawuyts
Copy link

I was wondering how much sense it would make to have an official nodesource™ busybox™ secure container system™. It would be pretty rad if Nodesource supplied some kind of hyper-minimal node-only environment. No cpp, no bash, just node.

The reason I'm asking this is because I read that the Google uses busybox to run single golang binaries, and as a result didn't have to worry about shellshock. Using minimalistic containers apparently reduces your attack surface. Also with you guys building noda we could actually have single node binaries someday.

Do you think this be possible / doable / actually useful ? Thanks!

@retrohacker
Copy link
Contributor

Hey @yoshuawuyts! I'm going to do some research into node&busybox before committing to this, but I like the idea!

@yoshuawuyts
Copy link
Author

@wblankenship Thanks! That's all I can ask for. Really glad you like the idea!

@retrohacker
Copy link
Contributor

So I've been looking into running node in busybox. I have gotten to the point of having a compiled excutable loaded into the box, but we are missing some shared libraries:

  • libdl.so.2
  • librt.so.1
  • libstdc++.so.6
  • libm.so.6
  • libc.so.6

Screenshot of current state.

snapshot1

If/when we get the libraries into busybox, we will still need to put node through a series of stress tests to make sure it is stable in this environment.

@yoshuawuyts
Copy link
Author

So cool!! Let me know if I can assist in anything concrete, I'd be happy to! 😄

@retrohacker
Copy link
Contributor

Sure thing! Will keep you posted.

Do you have any experience loading shared libraries into busybox?

@yoshuawuyts
Copy link
Author

@wblankenship Thanks! Haha, to be fair I have no experience with loading shared libs. Is there maybe another part where I can assist? You mentioned stress testing earlier, what did you have in mind for that?

@retrohacker
Copy link
Contributor

No worries! The stress tests will probably be running the new testing script for distributions repo. It currently has a few bugs to be worked out, could always take a look 😄

nodesource/distributions#25

This recommendation came from the referenced pull request. If you have a better approach, feel free to recommend it. Could also look at some of the tests being run for the io.js project.

@retrohacker
Copy link
Contributor

Current status: libraries are being linked, but there is something weird with the libstdc++ library I'm linking against. Will have to shave that yak on a future date though, calling it a night.

snapshot1

@yoshuawuyts
Copy link
Author

Nice progress!
I'd like to take a shot at implementing the tests for busybox. Can I find the wip branch anywhere?

@retrohacker
Copy link
Contributor

Awesomesauce, here is the current shell script I was working on: https://github.com/nodesource/distributions/blob/hardcore/test/hardcore

According to othiym we should:

  1. clone npm
  2. make install, which will install the devDependencies and build the docs
  3. npm run-script test-all, which will run both the legacy tests (which pretty heavily exercise npm all on their own) and the tap tests
  4. npm -g install yo generator-angular && mkdir angular-test-app && cd angular-test-app
  5. yo angular, filling out the prompts

"If it can install and build an entire Angular-scaffolded app, it's probably good to go."

@retrohacker
Copy link
Contributor

Current status: Even after getting the libraries into the container, I couldn't get them to load into memory. So it looks like we have to go the static route. I was able to get node v0.10.33 to compile as a static binary by manually implementing this pull request: nodejs/node-v0.x-archive#8274

node is now in the container and running. Going to work on moving everything around to the proper locations then will submit this as a pull request.

@retrohacker
Copy link
Contributor

snapshot2

for reference

@retrohacker
Copy link
Contributor

Just opened the https://github.com/nodesource/docker-node/tree/busybox branch.

Currently npm is having some problems connecting to the network, not sure what is going on. Also, the image size is now at 18.85MB.

snapshot2

@skozin
Copy link

skozin commented Jan 11, 2015

@wblankenship, have you checked this repo: https://github.com/hwestphal/docker-nodebox?

The resulting image is quite tiny and uses official node and npm binaries, which are fully functional in that environment. Also, it comes with useful tools like opkg package manager (inherited from progrium/busybox base image), bash, git and curl.

It is really easy to modify that Dockerfile to suit one's needs. For example, this is Node v0.11.14 with NPM v2.0.0 and without bash/git (27 MB total):

FROM progrium/busybox
MAINTAINER Your Name <[email protected]>

RUN \
  opkg-install curl libstdcpp && \
  rm -f /lib/libpthread.so.0 && \
  ln -s /lib/libpthread-2.18.so /lib/libpthread.so.0 && \
  curl -s http://nodejs.org/dist/v0.11.14/node-v0.11.14-linux-x64.tar.gz | gunzip | tar -xf - -C /

ENV PATH /node-v0.11.14-linux-x64/bin:$PATH

BTW, yo angular fails with EACCESS because Yeoman uses root-check to gowngrade the permissions of its process and loses access to the filesystem.

@retrohacker
Copy link
Contributor

@skozin

< ❤️ >

I love his use of opkg to install these dependencies. All of my problems with static linking are fixed in one fell swoop here.

Thanks for the tip on yo angular, you rock sir!

</ :heart: >

@ciekawy
Copy link

ciekawy commented Mar 30, 2015

@skozin actually changing from /lib64/libpthread-0.9.33.2.so to /lib64/libpthread-2.18.so breaks git executable. Actually it looks like some inconsistency in busybox openwrt repository since bothe libpthread packages are available there and after being installed one overrides another.

@skozin
Copy link

skozin commented Apr 2, 2015

@ciekawy, that was one of the reasons I ended up packaging it using Alpine Linux. It has some issues too, but really very few compared to progrium/busybox.

@wblankenship, glad it helped =)

@ciekawy
Copy link

ciekawy commented Apr 2, 2015

Unfortunately on Alpine Linux it is impossible to build phantomjs which is
another must have for me

W dniu czwartek, 2 kwietnia 2015 Семён [email protected]
napisał(a):

@ciekawy https://github.com/ciekawy, that was one of the reasons I
ended up packaging it using Alpine Linux
https://github.com/ficusio/docker-nodejs. It has some issues too, but
really few compared to busybox.


Reply to this email directly or view it on GitHub
#14 (comment)
.

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

4 participants