2

I've got a few Ruby on Rails systems running Ubuntu 14.04LTS. The Ubuntu version of supported Ruby is 1.9.1 but the developers use a Gemfile and Bundler which (AFAIK) installs Ruby (and gems) out-of-band from the OS updates to allow differernt projects to use different Rails stacks.

I believe the actual Ruby version in use is 2.3.5, but you can't tell that from the Ubuntu package utilities. It's been like this for years, but recent security policies are pushing us in the direction of proving we are on top of these updates and I can't just check a box that says "web developers say it's OK".

I've tried bundle show and to get a list of Ruby gems in use in the current (directory) project, but any single server may have several branches of projects, with many different versioins of gems in use in each branch. I couldn't tell you for sure which systems/projects are up-to-date with current patch levels.

The developers don't really care to be involved with the security aspects but if I take some hard data to managmement and say "This system is running vulnerable version X.X. This is the CVE. We are not patched" my job is done.

Is there an easier way to get current Ruby/Bundler/Gems versions other than some ugly find /var/www -name Gemfile -exec ... shell-fu ?

4
  • That shell-fu really doesn't look bad at all. You might be a bit spoiled. Apr 6, 2018 at 16:07
  • Just checking if this is already a solved problem to save some time and headache. Sometimes parsing filenames and output can get rather miserable with bash :/ Apr 6, 2018 at 16:23
  • So don't use bash, then. If you actually want shell programming, I find zsh much nicer to use, and for all complex scripts I actually use "proper" languages like Python Apr 6, 2018 at 16:25
  • +1 for starting with something other than shell. especially when it involves parsing arbitrary filenames. Good recommendation. Apr 6, 2018 at 16:28

1 Answer 1

-1

What you describe is a security nightmare in itself - multiple environments at unknown (effectively thus undocumented) versions, with no central registry what to update if necessary.

So, that's in itself worthy of reporting.

Now, your job becomes making a map of all the installations; run your commands on each of these (automatedly), and make a report out of that as well as integrating it in whatever infrastructure for server management (vagrant? Ansible? Puppet?...) You guys use. Congrats!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .