Re: Installing puppet and using ruby from RVM.

[jcbollinger]

On Friday, September 21, 2012 1:14:56 AM UTC-5, jdehnert wrote:

I'm setting up a pair of VM's to do some puppet testing on, and I am trying to figure out how to install puppet without having the the system also install ruby.

I already have ruby installed through RVM, and I'd like to get puppet to use that ruby.

For the record, I'm using CentOS 6.3 as the OS for the 2 VM's.  I have the puppet labs repo installed so I'm getting the latest version of puppet straight from puppet labs.
rvm version 1.15.9 is installed and I have ruby 1.9.2-p320 installed (system wide) and set to the default.  I also ran 'rvm system' so that ruby is found at /usr/local/rvm/bin/ruby.

Unfortunately every time I start 'yum install puppet-server puppet' yum wants to install ruby because rvm doesn't tell yum that ruby is already installed.

Does anyone know how to work around this?  in particular does anyone know how I can make puppet use the rvm ruby after I install everything?

You have a wrong concept: yum and rpm don't care whether any particular software is installed, they care only about what packages (RPMs) are installed.  That's why they don't care about the Ruby you've installed via rvm.

As a system administration principle, I think it's a rather poor idea to install software other than via the system's native package management system.  Among other things, that means I have no use for rvm (or gem), and also that I build a fair number of packages myself.  If you ignore that principle, then you need to be aware that you thereby start down a slippery slope; in fact, you are beginning to discover that on your own.

So what can you do?  Here are some of your options:

1) Use the system's Ruby packages.

2) Build and install your own Ruby packages (you can probably find some source RPMs to adapt)

3) Download the Puppet source and install it manually


John

[Stephen Price]

John's right. Yum and RVM will manage Rubies separately.

Is there a specific reason you want Puppet to use 1.9.2 instead of CentOS 6's version from yum repos (1.8.7)? I run CentOS on close to 100 hosts, all with 1.8.7 as the default install. A number of these also have RVM with various Rubies installed. What's nice about RVM is that it gets you away from having to overwrite the system's version of Ruby.

As long as we're talking about installing from source, there's a 4th option: use RVM's Ruby 1.9.2-p230 to install the Puppet gem. Instructions are here (though you'll need to adapt it to your specific environment): http://docs.puppetlabs.com/guides/installation.html#installing-from-gems-not-recommended

Please note that neither installing from source or gem is recommended. You're better off sticking with the native package management, as John suggests. Upgrading Puppet/RVM/Ruby could land you in hot water in the future.

On Thursday, September 20, 2012 11:14:56 PM UTC-7, jdehnert wrote:

I'm setting up a pair of VM's to do some puppet testing on, and I am trying to figure out how to install puppet without having the the system also install ruby.

I already have ruby installed through RVM, and I'd like to get puppet to use that ruby.

For the record, I'm using CentOS 6.3 as the OS for the 2 VM's.  I have the puppet labs repo installed so I'm getting the latest version of puppet straight from puppet labs.
rvm version 1.15.9 is installed and I have ruby 1.9.2-p320 installed (system wide) and set to the default.  I also ran 'rvm system' so that ruby is found at /usr/local/rvm/bin/ruby.

Unfortunately every time I start 'yum install puppet-server puppet' yum wants to install ruby because rvm doesn't tell yum that ruby is already installed.

Does anyone know how to work around this?  in particular does anyone know how I can make puppet use the rvm ruby after I install everything?

Thanks!
  James "Zeke' Dehnert

[Michael Stahnke]

On Fri, Sep 21, 2012 at 8:45 AM, Stephen Price <ste...@gmail.com> wrote:
> John's right. Yum and RVM will manage Rubies separately.
>
> Is there a specific reason you want Puppet to use 1.9.2 instead of CentOS
> 6's version from yum repos (1.8.7)? I run CentOS on close to 100 hosts, all
> with 1.8.7 as the default install. A number of these also have RVM with
> various Rubies installed. What's nice about RVM is that it gets you away
> from having to overwrite the system's version of Ruby.
>
> As long as we're talking about installing from source, there's a 4th option:
> use RVM's Ruby 1.9.2-p230 to install the Puppet gem. Instructions are here
> (though you'll need to adapt it to your specific environment):
> http://docs.puppetlabs.com/guides/installation.html#installing-from-gems-not-recommended

Also ruby 1.9.2 isn't very compatible with Puppet (at least 2.7.x).

>
> Please note that neither installing from source or gem is recommended.
> You're better off sticking with the native package management, as John
> suggests. Upgrading Puppet/RVM/Ruby could land you in hot water in the
> future.
>
>
> On Thursday, September 20, 2012 11:14:56 PM UTC-7, jdehnert wrote:
>>
>> I'm setting up a pair of VM's to do some puppet testing on, and I am
>> trying to figure out how to install puppet without having the the system
>> also install ruby.
>>
>> I already have ruby installed through RVM, and I'd like to get puppet to
>> use that ruby.
>>
>> For the record, I'm using CentOS 6.3 as the OS for the 2 VM's. I have the
>> puppet labs repo installed so I'm getting the latest version of puppet
>> straight from puppet labs.
>> rvm version 1.15.9 is installed and I have ruby 1.9.2-p320 installed
>> (system wide) and set to the default. I also ran 'rvm system' so that ruby
>> is found at /usr/local/rvm/bin/ruby.
>>
>> Unfortunately every time I start 'yum install puppet-server puppet' yum
>> wants to install ruby because rvm doesn't tell yum that ruby is already
>> installed.
>>
>> Does anyone know how to work around this? in particular does anyone know
>> how I can make puppet use the rvm ruby after I install everything?
>>
>> Thanks!
>> James "Zeke' Dehnert
>

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/v3iWa1GJDhgJ.
>
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.

[jdehnert]

On Friday, September 21, 2012 7:59:46 AM UTC-7, jcbollinger wrote:

You have a wrong concept: yum and rpm don't care whether any particular software is installed, they care only about what packages (RPMs) are installed.  That's why they don't care about the Ruby you've installed via rvm.

As a system administration principle, I think it's a rather poor idea to install software other than via the system's native package management system.  Among other things, that means I have no use for rvm (or gem), and also that I build a fair number of packages myself.  If you ignore that principle, then you need to be aware that you thereby start down a slippery slope; in fact, you are beginning to discover that on your own.

I'm aware of the issues of installing software through source vs. pkg management systems.  I should have mentioned that I've been in IT for over 20 years.  Its just puppet and ruby that are new to me, but I'm learning fast.  We are in agreement about sticking to one type of package management.  It much easier now that it was back when I was installing SunOS 4.1.4 on Sun 3's and Sparc 2's and compiling X11 from source.
 

So what can you do?  Here are some of your options:

1) Use the system's Ruby packages.

2) Build and install your own Ruby packages (you can probably find some source RPMs to adapt)

3) Download the Puppet source and install it manually


John

I've considered all of these.  Does anyone know of a CentOS/RH repo that has the latest versions of Ruby available?  I have done some searching, but not exhaustively so, for a repo with  the most recent versions of Ruby, but no luck so far.  The reason I want to use ruby-1.9.2-p320 on these test VM's is because in the production environment that these are mimicking the engineering folks are running that release, under RVM, and they want to avoid any installs of other versions to eliminate any chance of something getting pointed to an older version of Ruby accidentally.  The dev and production environments will both point to Ruby under RVM.

I ran into an issue like this once before where I needed to compile the latest version of Postfix to get access to a feature that was in the latest release.   Bit too soon after I ran into rpm prereq issues because the rpm system was saying that no mta was installed.  I eventually found a fake sendmail package, that installed nothing, but told rpm that sendmail was installed and that resolved the prereq issue without actually installing anything.

I was hoping someone might know some details about the rpm system that might allow me to tell it that ruby was installed without installing ruby, as with fake sendmail. Perhaps a lesser known tool that allows one to insert entries into the rpm database files.

[jdehnert]

On Friday, September 21, 2012 1:11:22 PM UTC-7, Michael Stanhke wrote:

> As long as we're talking about installing from source, there's a 4th option:
> use RVM's Ruby 1.9.2-p230 to install the Puppet gem. Instructions are here
> (though you'll need to adapt it to your specific environment):
> http://docs.puppetlabs.com/guides/installation.html#installing-from-gems-not-recommended

Also ruby 1.9.2 isn't very compatible with Puppet (at least 2.7.x).

I don't mind installing a few things with gem, but I want to just stick to what the development folks are going to install that way.  In reality, I have no need for passenger or the other gems that are using.  But from a system management POV, gem is just another step away from yum/rpm which is not the direction I want to go.  I haven't had time to read up on any puppet/ruby compatibility issues recently (another good reason for testing on VM's).  Sounds like I should just install whats available through yum which is ruby-1.8.7.

 

[Jakov Sosic]

On 09/22/2012 03:21 AM, jdehnert wrote:

> I'm aware of the issues of installing software through source vs. pkg
> management systems. I should have mentioned that I've been in IT for
> over 20 years. Its just puppet and ruby that are new to me, but I'm
> learning fast. We are in agreement about sticking to one type of
> package management. It much easier now that it was back when I was
> installing SunOS 4.1.4 on Sun 3's and Sparc 2's and compiling X11 from
> source.

If you were really aware, then you wouldn't do it...

> I've considered all of these. Does anyone know of a CentOS/RH repo that
> has the latest versions of Ruby available? I have done some searching,
> but not exhaustively so, for a repo with the most recent versions of
> Ruby, but no luck so far. The reason I want to use ruby-1.9.2-p320 on
> these test VM's is because in the production environment that these are
> mimicking the engineering folks are running that release, under RVM, and
> they want to avoid any installs of other versions to eliminate any
> chance of something getting pointed to an older version of Ruby
> accidentally. The dev and production environments will both point to
> Ruby under RVM.

This is wrong approach. Try to figure out why is RHEL/CentOS and Suse
Enterprise sticking to older version of ruby (or every other piece of
software they distribute), and what are the benefits...

> I was hoping someone might know some details about the rpm system that
> might allow me to tell it that ruby was installed without installing
> ruby, as with fake sendmail. Perhaps a lesser known tool that allows one
> to insert entries into the rpm database files.

You are mangling with the system in a way it shouldn't be mangled with.
Try to persuade your developers to use platform that is already used on
production, and not vice versa.

If that doesn't go quite right, then take src.rpm from RedHat/CentOS,
bump version to 1.9.x - or whatever do you want to use, drop in newer
sources, fix patches - and rebuild the RPM - or try to backport latest
feodra build:

http://fedora.aau.at/linux/releases/17/Fedora/source/SRPMS/r/ruby-1.9.3.194-10.1.fc17.src.rpm

but that could bring you back to trouble because that version probably
won't be 100% identical to the one that your dev team uses (if they
stick to sources). So we're back to square one - you *have to* convice
your team to use Ruby from RPM package - either fedora backport or
standard RHEL 1.8.x.

Everything else _*will*_ bit you in the ass in the long run.



--
Jakov Sosic
www.srce.unizg.hr

[Jakov Sosic]

On 09/22/2012 03:44 AM, jdehnert wrote:

> Sounds like I should just install whats available through yum which is
> ruby-1.8.7.

Sounds like a good idea.



--
Jakov Sosic
www.srce.unizg.hr

[jdehnert]

On Friday, September 21, 2012 7:11:18 PM UTC-7, Jakov Sosic wrote:

On 09/22/2012 03:21 AM, jdehnert wrote:

> I'm aware of the issues of installing software through source vs. pkg
> management systems.  I should have mentioned that I've been in IT for
> over 20 years.  Its just puppet and ruby that are new to me, but I'm
> learning fast.  We are in agreement about sticking to one type of
> package management.  It much easier now that it was back when I was
> installing SunOS 4.1.4 on Sun 3's and Sparc 2's and compiling X11 from
> source.

If you were really aware, then you wouldn't do it...

I haven't done anything yet, except appeal to the puppet community at large for some insight

> I've considered all of these.  Does anyone know of a CentOS/RH repo that
> has the latest versions of Ruby available?  I have done some searching,
> but not exhaustively so, for a repo with  the most recent versions of
> Ruby, but no luck so far.  The reason I want to use ruby-1.9.2-p320 on
> these test VM's is because in the production environment that these are
> mimicking the engineering folks are running that release, under RVM, and
> they want to avoid any installs of other versions to eliminate any
> chance of something getting pointed to an older version of Ruby
> accidentally.  The dev and production environments will both point to
> Ruby under RVM.

This is wrong approach. Try to figure out why is RHEL/CentOS and Suse
Enterprise sticking to older version of ruby (or every other piece of
software they distribute), and what are the benefits...

Considering that the developers have been working on this for over a year, and they have their reasons for selecting RVM and Ruby 1.9.2, it's not my call.  I'm here to bring as much consistency and reliability as I can to the systems that have been managed by the whims of the developers for quite some time.  I've made a huge amount of progress by basically giving them them some nice, clean, secure production systems that they aren't allowed to manage.  I have helped them get to the point where they can use Capistrano to deploy the application, and we have partitioned Neo4j and Mongodb onto their own separate systems.  Now I'm working on deploying puppet to keep the systems consistent and allow me to do all that puppet can do to keep things in order.
 

> I was hoping someone might know some details about the rpm system that
> might allow me to tell it that ruby was installed without installing
> ruby, as with fake sendmail. Perhaps a lesser known tool that allows one
> to insert entries into the rpm database files.

You are mangling with the system in a way it shouldn't be mangled with.
Try to persuade your developers to use platform that is already used on
production, and not vice versa.

Well, I suppose everyone has a different mandate at different companies.  My current gig is at yet another start up and the company is engineering driven.  Given that I need to make sure that I don't do anything that steps on engineering.  I'm not entirely under their thumb.  I insisted on certain conditions before I took this job, and that has allowed me to replace token security with real security.  Engineering and I have worked together very closely to help get them more compartmentalized to the application is now of a discrete unit, and not so much an electron cloud where they may have reached all over the OS.  I give them a reliable server, and they agree to keep the application contained.
 

If that doesn't go quite right, then take src.rpm from RedHat/CentOS,
bump version to 1.9.x - or whatever do you want to use, drop in newer
sources, fix patches - and rebuild the RPM - or try to backport latest
feodra build:

http://fedora.aau.at/linux/releases/17/Fedora/source/SRPMS/r/ruby-1.9.3.194-10.1.fc17.src.rpm

but that could bring you back to trouble because that version probably
won't be 100% identical to the one that your dev team uses (if they
stick to sources). So we're back to square one - you *have to* convice
your team to use Ruby from RPM package - either fedora backport or
standard RHEL 1.8.x.

Everything else _*will*_ bit you in the ass in the long run.

That’s why I'm here asking questions.  Its good to minimize all the future ass biting that one can, which is also why I'm testing on a pair of VM's to get puppet functional and worked out before it gets anywhere near a production system.
 

--
Jakov Sosic
www.srce.unizg.hr

[Marc Lucke]

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/OEPaTlAP2QIJ.

To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

rvm is handy but most production systems shouldn't  have internet access.  I managed to create a graylog2-web rpm with bundler - bundle install --standalone --deployment (but --standalone didn't work for some reason).  A +1 on consistency and sticking with one packaging system.  I have to admit I've been tempted to set up a ruby/rvm/gem et al. ubuntu or debian server that could just do whatever it wanted, but I decided against it because of the security questions that resulted.