I'd like to help patch a bug in the vagrant-persistent-storage plugin which is caused by recent versions of VirtualBox (4.3.0r89960) and Vagrant (1.3.5).
Specifically, it seems that VirtualBox has deprecated the --sataportcount flag from the vboxmanage storagectl command, for the more succinct --portcount flag.
I'm not familiar with vagrant plugin development in general, but could easily enough fix the flag in question, if I was able to accurately determine the version of VirtualBox in use.
Is it possible, within a vagrant plugin, to compare the version of VirtualBox for the purposes of maintaining backwards compatibility with older VirtualBox versions?
If not, are there any other vagrant plugins which have to use the command line response from vboxmanage -v to make version-specific determinations? I'd prefer to not have to reinvent the wheel...
Thanks in advance for any tips!
Update: I've found that it's possible to get the version as a string within a VirtualBox provider plugin:
module VagrantPlugins
module ProviderVirtualBox
module Driver
class Base
#version
However this is just the string representation of the VirtualBox version number ('4.3.0') not a proper version number (4.3.0) which would allow strict comparison. I realize that I could do this comparison myself, but it seems like there should be a way (within Vagrant) to manage VirtualBox/provider dependencies.
Ruby can already compare versions as strings. Like so:
irb(main):001:0> '4.3.0' < '4.3.1'
=> true
irb(main):002:0> '1.2.3' < '4.3.0'
=> true
irb(main):003:0> '4.2.17' > '4.3.0'
=> false
If you need something more advanced, try the versionmy ruby gem: https://github.com/dazuma/versionomy
Related
I am experimenting with Puppet using Vagrant. I'm new to Puppet.
I'm installing modules in my Puppet manifest using the approach suggested at: Can I install puppet modules through puppet manifest?
My default.pp contains something like:
$dsesterojava = 'dsestero-java'
exec { 'dsestero-java':
command => "puppet module install ${dsesterojava}",
unless => "puppet module list | grep ${dsesterojava}",
path => ['/usr/bin', '/bin']
}
include java::java_7
I'm trying to import a module and then immediately use the classes defined in it.
Currently, I get:
Error: Could not find class java::java_7
If I comment out the include line and re-run it. The module installs. If I then removed the comment and run the provisioning again then it works.
There is some kind of "chicken and egg" situation here. Can I use a module in the same Puppet manifest that installs it?
How should I solve it?
No, you cannot do this. When your catalog is compiled, Puppet will search in the appropriate directories for all of the required code and data. Since the java module does not exist until catalog application, the compilation of a catalog (occurs prior to application) depending upon it will fail. You are absolutely dealing with a "chicken and egg" situation here. I highly recommend against using Puppet code to install Puppet code.
Alternatively, the recommended approach to install and manage your Puppet modules is to use one of these solutions:
librarian-puppet: http://librarian-puppet.com/
r10k: https://github.com/puppetlabs/r10k
code-manager (PE only): https://puppet.com/docs/pe/2017.3/code_management/code_mgr.html
These will also solve the problem for you within the Vagrant if you are using the agent provisioner and subscribing the Vagrant instance to a Puppet Master.
If you are using the apply provisioner inside of Vagrant, then you will need to go a different route. The simplest solution is to use the shell provisioner to install Puppet modules via module install after the Puppet installation (unless you are using a Vagrant box with Puppet baked in, in which case you are probably not installing Puppet on it). Alternatively, you could share a directory with the host where your modules are installed, or install the librarian-puppet or r10k gems onto the Vagrant box and then use them to install into the appropriate path. I can go into more detail on these upon request.
I would like to have a fully configured ruby unix development environment using Vagrant configuration and provisioning. Ideally it would refer to a simple base box (e.g., precise32) and build the environment up through provisioning in such a way thait it will easily be repeatable for other team members, can be posted to github, and can be upgraded as new versions of the different technologies are available by just changing the provisioning. I have not found any full examples of this searching the web although [Rails Dev Box][1] has some useful ideas. Most of the dev environment examples (like Rails Dev Box) do not set up the guest dev environment because they assume dev will be done on the host using a shared file strategy - or if they do the configuration by hand and then save the box rather than provisioning it.
This also needs to work both in behind a proxy as well as with no proxy.
Here are the steps I am thinking will be required:
On the host:
install virtualbox, vagrant, vagrant proxyconf
On the guest, via Vagrantfile/provisioning:
use a base unix box (e.g., precise32)
optionally set proxy variables (if proxyconf plugin is installed and http_proxy env var is set)
provision everything else (puppet, chef, or shell script)
install various unix tools (apt-get install git, etc.expo ...)
set up bash environment
set up vim environment (pathogen plugin, ruby plugins, etc.)
install rvm
install ruby 1.9, 2.0, JRuby, Rubinius
installs and configures tmux
Ideally I could push this into github, it could be cloned, then cd to new directoy, and vagrant up to have a fully configured dev environment ...
Does anyone have any examples of doing this?
My preference for doing a task like this would be to use puppet as the provisioning step in your Vagrantfile.
With something like this, you can always get something thrown together quick and dirty by just doing all the steps in a shell provisioner... but I prefer the puppet and modules approach as I've found it easier to maintain, extend and to share with the team.
I've experimented with a couple of different ways of doing the provisioning with Ruby and rvm as you mentioned;
Theres the rvm puppet module by maestrodev which allows you to configure many of rvms core features: ruby versions, gemsets, gems and rvm wrappers. Typically to manage which puppet modules are included with a project I use the librarian-puppet gem which allows you to use a Puppetfile to specify the module and the version you require, much like bundler. This handles dependencies such as the stdlib and concat modules. This scenario requires external internet access to have been configured before provisioning so as to be able to download ruby and rubygems.
Offline installation of rvm - I made the relevant files (rvm itself, ruby and rubygems) accessible to the vagrant machine using a shared folder and turned the offline rvm instructions into a (not very good) puppet module and used that. One particular gotcha to pay attention to here is the naming of the ruby source that gets installed; the extension has to be .tar.bz2, its described in the list.
Additionally for your other provisioning steps you can build up puppet modules yourself for your additional requirements: vim / tmux etc and keep this versioned separately in git. You can get pretty far with modules with just the 'puppet trifecta':
class vim {
package { 'vim':
ensure => installed,
}
file { '.vimrc':
ensure => file,
...
}
}
Additionally check out the puppet forge for modules which might have already been written to do what you want.
So heres an example of what you could check in:
/ Puppetfile
/ README.md
/ Vagrantfile
/ puppet
/manifests
site.pp
And the vagrant provisioner would be
Vagrant.configure("2") do |config|
config.vm.provision "puppet" do |puppet|
puppet.manifests_path = "puppet/manifests"
puppet.module_path = "puppet/modules"
puppet.manifest_file = "site.pp"
end
end
I've used a rake task before to use librarian-puppet to pull in puppet dependencies from git / puppet forge and any additional steps you might need to do before vagranting up. This way the code as configuration is all you check in.
Finally, with puppet you can use the facter and hiera tools which are very useful for keeping data out of your modules and worth having a look at as a means of refactoring once you have your initial setup working.
I know in OpsWorks, Ruby version can be changed using custom Chef JSON like one in this topic.
But the problem is, before the new Ruby is installed, the default one (1.8.7) is used to compiled cookbooks. And Ruby version 1.8.7 cannot understand this code style (see here):
name: 'value',
I think it only accepts this style:
:name => "value",
Any suggestion to solve this?
Thank you.
UPDATE #1:
A temporary workaround for this: I checked out an older version of the yum cookbook, where the code is still valid for old Ruby.
UPDATE #2:
If I could use Chef-embedded Ruby then problem will be solved. Could anyone show how to use that embedded Ruby version? Thank you.
I think the ruby version sethvargo references above is not the one that AWS uses for the Chef run. That is the ruby version that will be used for the Rails layer. According to this issue https://github.com/aws/opsworks-cookbooks/issues/50 AWS is apparently running Chef11 on Ruby 1.8.7
OpsWorks now supports Chef 11.10, Ruby 2.0, berkshelf, data bags, and search - this should solve your issue
http://aws.typepad.com/aws/2014/03/aws-opsworks-now-supports-chef-1110.html
According to the Amazon OpsWorks documentation, you can specify the version and OpsWorks will use:
node.set['ruby']['full_version'] = '1.9.3'
I have a rails application using the following environment:
CentOS release 5.7 (Final)
Rails 3.0.9
Rubygems 1.6.2
Ruby 1.9.2
Passenger
Apache2
The Development environment differs and is: Ubuntu 10.04, Ruby 1.8.7 which works like a charm. I can't change the production environment.
I use ruby-xslt, gem version 0.9.8, the problem is when I access the application I get an error:
/usr/local/lib/ruby/gems/1.9.1/gems/ruby-xslt-0.9.8/lib/xml/xslt_lib.so: undefined symbol: xsltLibxmlVersion - /usr/local/lib/ruby/gems/1.9.1/gems/ruby-xslt-0.9.8/lib/xml/xslt_lib.so
The only solution I can find about this is:
http://amitsolanki.com/2010/04/undefined-symbol-xsltlibxmlversion-ruby-xslt-and-centos/
Which does not work for me.
I am stumped and would like to hear your opinions on what to do:
My ideas are as follows:
1) Don't use ruby-xslt - However this is the only ruby based xslt lib I could get to compile in development, which is why I used it. (but am open to suggestions).
2) Hack the ruby-xslt lib to remove the reference to the symbol, recompile and install. (tried but the error still appears so I may not be doing it right, I run "ruby setup.rb" for the gem again after the change but this is pure guesswork.)
3) Change the Ruby Environment to 1.8.7 as in development - don't think this will work as the problem is between the gem ruby-xslt and a linux library libxslt2.so and not the ruby env. (so actually not going to do this)
4) Add the symbol to the libxslt2.so lib, rebuild and install (but not worked with C language for 15 Years)
Any thoughts on this?
Regards
Paul
I solved this by using option number 1 and managed to get an older version of xslt-ruby installed (1.0.1), this involved installing a few libs as well.
I'm trying to run ohai.bat os_version within cygwin on Windows Server 2003 R2, and it returns an empty array as output. If I instead run ohai os_version in cmd.exe, then it correctly returns:
[
"5.2.3790"
]
Given that ohai.bat os_version works on another one of my virtual machines, I'm inclined to believe that this is an environment misconfiguration of some form. Does anyone have any ideas on what to check?
It turns out that the problem is caused by systemu not properly quoting directory names. This commit fixes the problem, but is not currently available in any released gem. It will be in version 2.0.0 of systemu. To fix it in your own project for now, you'll need to clone systemu off github and build the gem yourself.