RVM installation fails on Linux with symlinks permissions problem

[ekortright]

I've been trying to install rvm (single user, non-root), but keep getting permissions problems (gtar complains about not being able to create symlinks in the scripts directory).

I also recently started getting gateway timeout (curl return status 22) errors, but the symlink permissions problems have been there from the start.

Please see this gist showing the OS version and the result of two different attempts using the --debug flag: https://gist.github.com/ekortright/6390877

[mpapis]

please try again with:

\curl -L https://get.rvm.io | bash -s head --debug

[ekortright]

Trying again with head--please see https://gist.github.com/ekortright/6416089

[mpapis]

hmm, can I see output from: mount?

[ekortright]

/dev/root on /lib type virtfs (defaults)
/dev/root on /sbin type virtfs (defaults)
/dev/root on /opt type virtfs (defaults)
/dev/root on /lib64 type virtfs (defaults)
/dev/root on /usr/lib type virtfs (defaults)
/dev/root on /usr/lib64 type virtfs (defaults)
/dev/root on /usr/sbin type virtfs (defaults)
/dev/root on /usr/share type virtfs (defaults)
/dev/root on /usr/bin type virtfs (defaults)
/dev/root on /usr/man type virtfs (defaults)
/dev/root on /usr/libexec type virtfs (defaults)
/dev/root on /usr/local/bin type virtfs (defaults)
/dev/root on /usr/local/share type virtfs (defaults)
/dev/root on /usr/local/Zend type virtfs (defaults)
/dev/root on /usr/local/IonCube type virtfs (defaults)
/dev/root on /usr/include type virtfs (defaults)
/dev/root on /usr/local/lib type virtfs (defaults)
/dev/root on /var/spool type virtfs (defaults)
/dev/root on /var/lib type virtfs (defaults)
/dev/root on /var/cpanel type virtfs (defaults)
/dev/root on /usr/local/cpanel/Cpanel type virtfs (defaults)
/dev/root on /usr/local/cpanel/3rdparty type virtfs (defaults)
/dev/root on /var/run type virtfs (defaults)
/dev/root on /var/log type virtfs (defaults)
/dev/root on /tmp type virtfs (defaults)
/dev/root on /dev type virtfs (defaults)
/dev/root on /bin type virtfs (defaults)
/dev/root on /usr/local/apache/domlogs type virtfs (defaults)
/dev/root on /etc/mail type virtfs (defaults)
/dev/root on /home/ekortright type virtfs (defaults)
none on /proc type proc (rw)

[mpapis]

please try this:

ln -s /home/regtick/.rvm/src/rvm /home/regtick/.rvm/src/rvm-link && echo working || echo failed-$?

[ekortright]

$ ln -s /home/regtick/.rvm/src/rvm /home/regtick/.rvm/src/rvm-link && echo working || echo failed
working
$ ls -l .rvm/src
total 12
drwxr-xr-x  3 regtick regtick 4096 Sep  5 10:07 ./
drwxr-xr-x  4 regtick regtick 4096 Sep  2 13:52 ../
drwxr-xr-x 17 regtick regtick 4096 Sep  2 13:52 rvm/
lrwxrwxrwx  1 regtick regtick   26 Sep  5 10:07 rvm-link -> /home/regtick/.rvm/src/rvm/

[mpapis]

aha! I do understand now, it fails for files that are links created before the targets they are linking to, so something like:

cd /home/regtick/.rvm/src
ln -s rvm-link rvm-missing && echo working || echo failed-$?

can you gist: man gtar

[ekortright]

$ ln -s rvm-link rvm-missing && echo working || echo failed-$?
working
$ ls -l .
total 12
drwxr-xr-x  3 regtick regtick 4096 Sep  5 11:09 ./
drwxr-xr-x  4 regtick regtick 4096 Sep  2 13:52 ../
drwxr-xr-x 17 regtick regtick 4096 Sep  2 13:52 rvm/
lrwxrwxrwx  1 regtick regtick   26 Sep  5 11:08 rvm-link -> /home/regtick/.rvm/src/rvm/
lrwxrwxrwx  1 regtick regtick    8 Sep  5 11:09 rvm-missing -> rvm-link/

Here's the man gtar output: https://gist.github.com/ekortright/6452737

[mpapis]

ah I reversed the target with name:

ln -s rvm-foo rvm-bar && echo working || echo failed-$?

this one should fail

[mpapis]

ok trying something new:

mkdir -p /home/regtick/.rvm/src/rvm_new
cd /home/regtick/.rvm/src/rvm_new
gtar xzf /home/regtick/.rvm/archives/wayneeseguin-rvm-master.tgz --no-same-owner --strip-components 1 --preserve-order && echo worked || echo failed-$?

[ekortright]

Yes, that reproduces the problem:

$ mkdir -p /home/regtick/.rvm/src/rvm_new
$ cd /home/regtick/.rvm/src/rvm_new
$ gtar xzf /home/regtick/.rvm/archives/wayneeseguin-rvm-master.tgz --no-same-owner --strip-components 1 --preserve-order && echo worked || echo failed-$?
gtar: install: Cannot create symlink to `scripts/install': Permission denied
gtar: scripts/functions/requirements/amazon: Cannot create symlink to `centos': Permission denied
gtar: scripts/functions/requirements/debian: Cannot create symlink to `ubuntu': Permission denied
gtar: scripts/functions/requirements/mint: Cannot create symlink to `ubuntu': Permission denied
gtar: Exiting with failure status due to previous errors
failed-2

[ekortright]

Also tried just creating a symbolic link when the target already exists:

$ ls
./  ../  rvm/  rvm-link@  rvm_new/
$ ln -s rvm_new rvm-link && echo working || echo failed-$?
ln: creating symbolic link `rvm-link/rvm_new': Permission denied
failed-1

[mpapis]

the default behavior seems to be:

$ cd ~/.rvm/src/
$ ln -s rvm-link rvm-missing && echo working || echo failed-$?
working
$ ls -ld rvm-link rvm-missing
ls: cannot access rvm-link: No such file or directory
lrwxrwxrwx 1 mpapis users 8 Sep  9 17:27 rvm-missing -> rvm-link

and man 1 ln does not specify behavior for symbolic links:

By default, each destination (name of new link) should not already exist. When creating hard links, each TARGET must exist. Symbolic links can hold arbitrary text; if later resolved, a relative link is interpreted in relation to its parent directory.

but man 2 symlink specifies:

A symbolic link (also known as a soft link) may point to an existing file or to a nonexistent one; the latter case is known as a dangling link.

so what your system does is not a proper behavior, symbolic links should not fail when target is missing, please contact your system provider for details how to fix it ... I would suggest updating it as Redhat 4.4 sounds very very old (8 years!) and acording to https://access.redhat.com/support/policy/updates/errata/#th-rhel4-phase3 is already End of Production 3 (End of Production Phase) since February 29, 2012.

[mpapis]

... and unless you can provide a reason why we should provide support for this old (and broken) system I'm closing this ticket - please let me know if there is anything more here to do.

[ekortright]

Sigh. No, there is nothing more to do. Thanks for your help.

[ekortright]

FYI, the problem is not RedHat 4.4 - the ln -s command is broken on purpose by the system provider to prevent users from installing things like RVM.

[mpapis]

how nice of them, I suggest you change provider to one that uses an up to date system and does not break it on purpose