4 ms·

Have you tried rvm? bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head ) rvm install 1.9.2 rvm use 1.9.2 --default which ruby EDIT

Have you tried rvm? bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head ) rvm install 1.9.2 rvm use 1.9.2 --default which ruby EDIT thanks telemachos, add this to either zshrc (if you're using zsh) or bash_profile or equivalent [[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"

beoba 16y ago
Not a good solution if you dislike stomping on your distro's package management.
- kajecounterhack 16y ago
  Hm well, I do use my distro's (ubuntu) default package manager if I'm not doing rails dev (sudo apt-get install ruby rake) but I need to easily switch between ruby versions and rails versions sometimes, so rvm makes my life easier. It lets me create "gemsets" -- it's not that I don't appreciate the package being in the repos or something :) Honestly I don't see the big deal. It's possible that a person might use the repo packages sometimes, and rvm other times. From a purely practical point of view, it seems okay. Though, if I was able to do that with the distro's packages that'd be cool too.
- telemachos 16y ago
  I understand the desire to stick with your distro's package management where you can (especially if you use Debian or a Debian-derived distro. APT rocks.) However "stomping on your distro's package management" is not a fair description of what rvm does nor how it works. rvm is very well crafted to stay completely out of the way of a package manager like APT. If you use rvm normally, nothing is installed at the system level (e.g. /usr/local), much less into /usr/bin (or somewhere APT expects to manage). Everything is sandboxed in $HOME/.rvm/ nice and clean. You can remove it at simply as `rm -rf $HOME/.rvm` and a quick edit of your shell's start-up files. APT is in no way "stomped".
  - steveklabnik 16y ago
    You can also rvm implode or rvm seppuku and it'll remove itself. Which I always found to be particularly funny.
telemachos 16y ago
Just in case someone uses this as installation instructions, there's a (small but important) missing step. After installing via bash and before installing any rubies, add this to your shell's startup file: [[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" Then open a new shell and check the output of `type rvm | head -1`. It should return "rvm is a function". Maybe more importantly, run `rvm notes` before installing any rubies. Many operating systems will need to install various development packages first. `rvm notes` will tell you what you are likely to need for your OS. http://rvm.beginrescueend.com/rvm/install/ http://rvm.beginrescueend.com/rvm/install/
- steveklabnik 16y ago
  One more small note: this isn't some magic you need to learn, it spits it out when you install it.
  - telemachos 16y ago
    Fair enough and a good point. I hang out in #rvm on irc though, and a reasonable number of people manage not to read the notes the installer spits out (or the docs online, which are excellent). But it's a good point, nonetheless.
    - steveklabnik 16y ago
      Yeah, there's a reason why RTFM became a saying... I wasn't trying to criticize, I just wanted to point it out before someone said 'good luck figuring that one out.'
joeyh 16y ago
Are you seriously suggesting using a a package system that is bootstrapped by downloading and running a shell script with no security protections whatsoever? Moreover, it's not just you giving a bad example, as the shell script then clones a git repository, again with no protections whatsover (over http by default to make it really easy to MITM attack), and runs code from it. So this was written by people who just don't care, or don't understand security. Not people I'd be trusting with package management on my system. This kind of thing might have been acceptible, barely, before 1995. Since then, we've developed package systems with gpg signed chains of trust.
- steveklabnik 16y ago
  I think you're being _just a bit_ reactionary. Besides if you git clone, literally _every commit_ is checksummed. I'm no security expert, but I don't think MITM-ing a 'git clone' sounds 'really easy.'
  - subway 16y ago
    No, you're clearly not a security expert. If you're doing a git clone over HTTP, you can't even be certain you're talking to the right git repository. Sure, each and every commit may be checksummed, but how exactly do you anticipate knowing what the correct checksums are?
    - steveklabnik 16y ago
      Fair enough. Like I said, I don't know enough about this. > how exactly do you anticipate knowing what the correct checksums are? Well, because the repo you're cloning knows what they are... I wasn't thinking about the repo itself being owned, but git's whole job is to make sure that chunks of text get from one place to the other in an identical state, so...
      - vietor 16y ago
        The target repo itself isn't owned, but your connection is. The point is that you only think that you are talking to the correct repo, when in fact you are cloning whatever git repository the attacker would like you to. It's obviously a focused attack as are all MITM attacks, so you can assume the attacker is familiar with the install script. So when the script then continues and performs it's next action on the contents of the repository, you will execute an arbitrary payload. Edit: It wasn't clear to me that the problem had become apparent in the parent post. Probably just pre-coffee thinking on my part, but hopefully this will help clarify it for anyone else reading along who also missed it.
masklinn 16y ago
Fantastic, he says he does not want to compile Ruby and modules himself and you give him a solution doing exactly that.
- steveklabnik 16y ago
  I mean, apt-get install will also compile from source, if you have the right repositories enabled. The complaint about 'compiling from source' is that you have to manage the compilation yourself, the paths, where it's installed, etc. rvm addresses this problem.
  - danieldk 16y ago
    I mean, apt-get install will also compile from source, if you have the right repositories enabled. No, it doesn't. It will install binary packages that are signed. That means that if I install a package on my local desktop and a server in New York, it will exactly be the same. No matter if there are differences in the environment or configuration. Besides that I want every system file tracked by one package management system (for ease of administration), and easy security updates. Another important benefit of using binary Debian packages is that you get the testing that preceded progressing of the package into Debian testing for free. Constrast that with a gem that happened to be updated just 30 minutes ago, with no testing in the particular configuration where it is used. We have been burnt badly in the past by out-of-distro 'package management' before (little testing, incompatible versions, failing builds, etc.), that I stopped using non-distribution packages mostly. Unless you are referring to kernel module packages that use DKMS (I guess not) or 'apt-get source' which retrieves the source of a package in conjunction with '--compile'. But that's not a very common use of APT.
    - steveklabnik 16y ago
      I was thinking of apt-get source, actually. It's been two years or so since I've used Debian, since our worldviews are incompatible. > Constrast that with a gem that happened to be updated just 30 minutes ago, with no testing in the particular configuration where it is used. This doesn't really happen, though. Bundler makes sure that you have the exact same versions of gems that you used everywhere else, and if anyone's got the automated testing thing down, it's Rubists. You won't get the 30 minute old version unless you want to.

beoba 16y ago

Not a good solution if you dislike stomping on your distro's package management.

kajecounterhack 16y ago
Hm well, I do use my distro's (ubuntu) default package manager if I'm not doing rails dev (sudo apt-get install ruby rake) but I need to easily switch between ruby versions and rails versions sometimes, so rvm makes my life easier. It lets me create "gemsets" -- it's not that I don't appreciate the package being in the repos or something :) Honestly I don't see the big deal. It's possible that a person might use the repo packages sometimes, and rvm other times. From a purely practical point of view, it seems okay. Though, if I was able to do that with the distro's packages that'd be cool too.
telemachos 16y ago
I understand the desire to stick with your distro's package management where you can (especially if you use Debian or a Debian-derived distro. APT rocks.) However "stomping on your distro's package management" is not a fair description of what rvm does nor how it works. rvm is very well crafted to stay completely out of the way of a package manager like APT. If you use rvm normally, nothing is installed at the system level (e.g. /usr/local), much less into /usr/bin (or somewhere APT expects to manage). Everything is sandboxed in $HOME/.rvm/ nice and clean. You can remove it at simply as `rm -rf $HOME/.rvm` and a quick edit of your shell's start-up files. APT is in no way "stomped".
- steveklabnik 16y ago
  You can also rvm implode or rvm seppuku and it'll remove itself. Which I always found to be particularly funny.

telemachos 16y ago

Just in case someone uses this as installation instructions, there's a (small but important) missing step. After installing via bash and before installing any rubies, add this to your shell's startup file: [[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" Then open a new shell and check the output of `type rvm | head -1`. It should return "rvm is a function". Maybe more importantly, run `rvm notes` before installing any rubies. Many operating systems will need to install various development packages first. `rvm notes` will tell you what you are likely to need for your OS. http://rvm.beginrescueend.com/rvm/install/ http://rvm.beginrescueend.com/rvm/install/

steveklabnik 16y ago
One more small note: this isn't some magic you need to learn, it spits it out when you install it.
- telemachos 16y ago
  Fair enough and a good point. I hang out in #rvm on irc though, and a reasonable number of people manage not to read the notes the installer spits out (or the docs online, which are excellent). But it's a good point, nonetheless.
  - steveklabnik 16y ago
    Yeah, there's a reason why RTFM became a saying... I wasn't trying to criticize, I just wanted to point it out before someone said 'good luck figuring that one out.'

joeyh 16y ago

Are you seriously suggesting using a a package system that is bootstrapped by downloading and running a shell script with no security protections whatsoever? Moreover, it's not just you giving a bad example, as the shell script then clones a git repository, again with no protections whatsover (over http by default to make it really easy to MITM attack), and runs code from it. So this was written by people who just don't care, or don't understand security. Not people I'd be trusting with package management on my system. This kind of thing might have been acceptible, barely, before 1995. Since then, we've developed package systems with gpg signed chains of trust.

steveklabnik 16y ago
I think you're being _just a bit_ reactionary. Besides if you git clone, literally _every commit_ is checksummed. I'm no security expert, but I don't think MITM-ing a 'git clone' sounds 'really easy.'
- subway 16y ago
  No, you're clearly not a security expert. If you're doing a git clone over HTTP, you can't even be certain you're talking to the right git repository. Sure, each and every commit may be checksummed, but how exactly do you anticipate knowing what the correct checksums are?
  - steveklabnik 16y ago
    Fair enough. Like I said, I don't know enough about this. > how exactly do you anticipate knowing what the correct checksums are? Well, because the repo you're cloning knows what they are... I wasn't thinking about the repo itself being owned, but git's whole job is to make sure that chunks of text get from one place to the other in an identical state, so...
    - vietor 16y ago
      The target repo itself isn't owned, but your connection is. The point is that you only think that you are talking to the correct repo, when in fact you are cloning whatever git repository the attacker would like you to. It's obviously a focused attack as are all MITM attacks, so you can assume the attacker is familiar with the install script. So when the script then continues and performs it's next action on the contents of the repository, you will execute an arbitrary payload. Edit: It wasn't clear to me that the problem had become apparent in the parent post. Probably just pre-coffee thinking on my part, but hopefully this will help clarify it for anyone else reading along who also missed it.

masklinn 16y ago

Fantastic, he says he does not want to compile Ruby and modules himself and you give him a solution doing exactly that.

steveklabnik 16y ago
I mean, apt-get install will also compile from source, if you have the right repositories enabled. The complaint about 'compiling from source' is that you have to manage the compilation yourself, the paths, where it's installed, etc. rvm addresses this problem.
- danieldk 16y ago
  I mean, apt-get install will also compile from source, if you have the right repositories enabled. No, it doesn't. It will install binary packages that are signed. That means that if I install a package on my local desktop and a server in New York, it will exactly be the same. No matter if there are differences in the environment or configuration. Besides that I want every system file tracked by one package management system (for ease of administration), and easy security updates. Another important benefit of using binary Debian packages is that you get the testing that preceded progressing of the package into Debian testing for free. Constrast that with a gem that happened to be updated just 30 minutes ago, with no testing in the particular configuration where it is used. We have been burnt badly in the past by out-of-distro 'package management' before (little testing, incompatible versions, failing builds, etc.), that I stopped using non-distribution packages mostly. Unless you are referring to kernel module packages that use DKMS (I guess not) or 'apt-get source' which retrieves the source of a package in conjunction with '--compile'. But that's not a very common use of APT.
  - steveklabnik 16y ago
    I was thinking of apt-get source, actually. It's been two years or so since I've used Debian, since our worldviews are incompatible. > Constrast that with a gem that happened to be updated just 30 minutes ago, with no testing in the particular configuration where it is used. This doesn't really happen, though. Bundler makes sure that you have the exact same versions of gems that you used everywhere else, and if anyone's got the automated testing thing down, it's Rubists. You won't get the 30 minute old version unless you want to.