I'm trying to learn how to set up a virtual development environment using VirtualBox, Veewee, Vagrant and Chef-solo with Berkshelf.
Since I'm very new to this, I've read all I could find online, but I think I'm missing something crucial. Hopefully somebody here can help me understand.
The part I'm having problems with is provisioning the Veewee-generated Vagrant box using Chef-solo and Berkshelf.
From my point of view, the main advantage of using Vagrant and virtual environments is that they're reproducible and portable, so I do not understand why I have to install the Berkshelf gem and download recipes on my local host machine.
Why isn't all this done on the guest?
If I give my customized Vagrantfile to someone else, vagrant up will not work on their machine because the Vagrantfile references local recipes the other person will not have by default. Installing Berkshelf and recipes on their machine as well kinda defeats the purpose and so does referencing recipes available on the web somewhere.
Isn't it a better idea to just install the Berkshelf gem on the guest, download recipes locally there and tell Vagrant to use the recipes on the guest? I couldn't find any reference in the new Vagrant documentation on how to do this, but in the old version specifying cookbook folders within the virtual machine was an available option.
So basically what I'd like to know is:
Is my reasoning a valid option or am I missing either a useful tool or the general picture?
If my reasoning is valid, could you please point me in the right direction of how to do this? I was thinking of finding out how to customize the Veewee templates for building the Vagrant base box, using a post installation script to add Berkshelf and download recipes, but perhaps it's either overkill or the wrong way to go about this?
Thanks in advance!
Jepp one could think that managing the cookbooks outside the designation guests is against the principle of portibility but this gap can be filled with two simple plugins for Vagrant that integrate librarian-chef or berkshelf (which are doing merely the same in different ways) so that before every vagrant up run e.g. berkshelf is executed automatically - sure the dev has to install this plugins + Vagrant + Virtualbox + Veewee/some other baseboxes but this setup is a one-time effort.
For librarian-chef which I'm using such a plugin might be this.
HIH
Related
the question seems to be weird, but it's a part of long story to install Fluentd on sles11 sp4, actually.
I've seen success story of Fluentd on sles11 sp3 here, by #ab77
https://serverfault.com/questions/539307/installing-fluentd-kibana-elastic-search-on-suse-enterprise-linux-11/540521#540521
Unfortunately, I can't follow the way above because of my company security policy : git clone from github via https is disabled, so all dynamic deps via rbenv fail.
So I got an idea to install Ruby 2.1.0 (Fluentd requirements) from an isolated package on JBoss of my company, which should contain all the dependencies.
For the moment I'm struggling with numerous dependencies and not sure if this is possible at all or not (I'm completely new in Ruby).
If you were facing something similar, could you please share your experience?
Thank you for the help!
There is some tutorial for RVM (Ruby version manager) rvm.io/rvm/offline
I've seen companies putting gems to their own gem servers and installing them from there directly guides.rubygems.org/run-your-own-gem-server
We're using chef to manage Ruby versions in our vagrant setup using rbenv and ruby-build. One feature we'd like, even though rbenv pointedly refuses to implement it, is to have "fuzzy" version matching for ruby versions (e.g. converting 1.9.3 to 1.9.3-p123).
I'd like this to be handled transparently in a standalone recipe which can be placed between ruby-build and rbenv in the run_list. My code "works" (determines the latest matching ruby version based on the output of ruby-build --definitions), but changes are not persisted when running the rbenv cookbook, so I assume they are local to my cookbook. Is there any way to update an attribute globally for the duration of the run?
I should add that I'm not familiar with chef. This is outside of the domain that I usually work in. I know that this is probably a strange use case, and if what I'm trying to do is truly egregious, what would be a better way to accomplish what I want?
Here's the general outline of my current recipe:
original_rbenv_rubies = node[:rbenv][:rubies]
new_rbenv_rubies = determine_full_ruby_versions original_rbenv_rubies
node.force_override[:rbenv][:rubies] = new_rbenv_rubies
I've solved this by using my cookbook as a wrapper for the rbenv cookbook. I moved the logic above into the default attributes file, and used include_recipe to include the original recipes in my own. For some reason, the new attributes still weren't being picked up, so I moved the original values into node[:rbenv_wrapper][:rubies], and used override to set the new ones in node[:rbenv][:rubies], after which everything worked as expected.
I'm curious to find where exactly vagrant plugins are installed. I'm currently looking at a vagrant installation on Windows, and my example is the vagrant-timezone plugin. My best guess was in the C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.8.1\plugins, but I'm not seeing "timezone" anywhere around there?
From some more research, it appears that information for plugins is spread across a few locations:
%USERPROFILE%\.vagrant.d\plugins.json
lists all installed plugins
%USERPROFILE%\.vagrant.d\gems\gems\"plugin_name-version"
Directory (not sure what all the files do, but this looks like the bulk of it)
%USERPROFILE%\.vagrant.d\gems\specifications\"plugin_name-version".gemspec
For my use case, I was looking to manually extract and install a plugin, so these seemed to be all that I needed to account for.
I have puppet 3.4.2 and Vagrant 1.6.5. We configured our puphpet setup over a year ago.
This is all working fine on my environment, but a fresh install downloads a new version of the base box which has an updated version of puppet and so our old configurations don't work.
We are using this box: https://atlas.hashicorp.com/puphpet/boxes/ubuntu1204-x64. I must have v1 but for new instances it will download v2.1
I have tried updating the puphpet config.yaml, but when I upload this to puphpet.com I get the message "The config file provided was empty! Please recreate your manifest manually below.".
So I see a few solutions but I have blockers on each of them:
Use the old base box. Is there an archive copy of V1 of this server somewhere on the internet? https://atlas.hashicorp.com/puphpet/boxes/ubuntu1204-x64
Use the new base box but downgrade Puppet. How do you downgrade Puppet and all it's dependancies?
Figure out some way of importing my config.yaml in to puphpet.com and start using the new versions. Is there anything I need to do to get puphpet.com to recognise an old file?
Reconfigure the whole file from scratch. Do you know anyone that can help me?
Thanks for advice.
It's still there, but no longer supported or publically listed.
All boxes come pre-installed with Puppet 3.4.3, which is BC with 3.4.2.
Sorry, changes in the past month or two have broken BC with old config.yaml files. You'll need to manually select your options again.
Just do this. Honestly, it's textboxes, dropdowns and radio boxes, and will take you less than 10 minutes.
I'm new to running a Linux server and slowly getting up to speed with things.
I have already installed nginx via the apt-get function, although I'm following a tutorial which recommends installing it as a ruby gem instead.
Is there any difference in the functionality/limitations to installing it as a gem than by using apt-get? - I'm worried that it won't work for non-ruby applications if it is gem installed?
Is there any difference in the functionality/limitations to installing it as a gem than by using apt-get? - I'm worried that it won't work for non-ruby applications if it is gem installed?
There aren't any limitations on the version of Nginx that Passenger installs for you. You should be able to use it with other languages as you normally would (providing you know how to configure Nginx.) I was able to use it to connect to both Ruby and Node.js sites with no problems.
The people at Phusion have a nice page explaining why they are forced to provide their own version of Nginx (rather than using the standalone one) and it comes down to the fact that Nginx does not allow to be extended at runtime. Extensions like Passenger must be compiled into it. See this page for more information on it: https://github.com/phusion/passenger/wiki/Why-can%27t-Phusion-Passenger-extend-my-existing-Nginx%3F
(Note: When I tested this I used the installation instructions from the Phusion web site https://www.phusionpassenger.com/documentation/Users%20guide%20Nginx.html#install_on_debian_ubuntu , rather than the gem that is indicated in your tutorial, but I suspect they are both equivalent.)
I have run into this too. Where I am recommended to use one package manager over the other. I would question the age of the tutorial first, if it is not relatively recent you may want to consider if the information is no longer up to date. The libraries installed with that method may not be up to date.
However, if you intend to follow through with the tutorial you may end up needing it installed as the tutorial describes.
The difference is that one may not have all the libraries that are required or may not have the most up to date version. One tool could be buggy, I don't think this is the case in your situation but it is in Macports v.s Homebrew in my opinion. It might install to a different directory based on what install method you use, if you use a method off the web and then go back to the tutorial it could be installed to a different location then your tutorial expects.
If you have to follow the tutorial then I would all the way through, but if you don't need to use the preferred method that the program/library maintainers recommend. If the tutorial is out of date you could try to find an up to date tutorial.
good luck!