On 22/09/2012, at 4:23 PM, jdehnert <jdehn...@gmail.com> wrote: > > > 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 > > -- > 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-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@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. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
