The README.md currently suggests these commands to install rvm:
curl -sSL https://rvm.io/mpapis.asc | gpg --import -
curl -sSL https://rvm.io/pkuczynski.asc | gpg --import -
curl -sSL https://get.rvm.io | bash -s stable
source $HOME/.rvm/scripts/rvm
echo 'source "$HOME/.rvm/scripts/rvm"' >> ~/.bashrc
rvm install 2.7.3 --disable-binary --with-jemalloc
Instead of downloading the https://get.rvm.io script, just put the
two keys in the repository and do the basic operations that are
required, rather than grabbing a shell script from a website and just
running it.
Also, run `rvm autolibs disable` so that the `rvm` command, which
does not run as root, will not seek to use sudo. I checked the
Debian system requirements that `rvm requirements` was looking for,
and added those to `script/build/debian/prebuild.sh`.
Hopefully, the semantics of `rvm requirements` is that it will exit
non-zero if some requirements are missing, which is the desired
behavior, since it flags that `script/build/debian/prebuild.sh` must
be updated.
Our goal in this document is to explain how to build virtually all
the dependencies for Houdini from source (in part to vet licenses and
easy AGPL compliance, but also to operate more securely). Initially,
it won't be possible to do that so begin documenting places where
items are not built from source.
As an additional security measure, don't use the network version of
setup_14.x. Instead, save nodesource and yarn keys locally and do
the operations in the Dockerfile to install the keys. Then, simply
do the apt install of the dependencies needed from both places.
Keep a copy of the setup_14.x in the data directory as well. In
future, it might be useful to have a script that compares the
versions of that script and keys on the nodesource and yarn websites
— mainly to semi-automatically verify if upstream details have
changed.
First step in rewriting the Dockerfile to match the current
setup/installation/configuration instructions as found in README.md.
First step it to comment out some of the later stuff, and begin setup
of installing everything into /houdini (instead of /myapp) and doing
everything under the houdini user.
These instructions are more detailed than what will ultimately appear
in `docker.md`, and focus on building from sources wherever possible.
They are specifically designed to include extra detail for users not
as familiar with docker, or for those who would like bootstrap
further from scratch to create a Houdini docker image.
