I'm trying to use the librarian-puppet to fetch forge modules from an Artifactory repository.
In my Puppetfile I have something like:
forge "https://<artifactory_host>/artifactory/api/puppet/<repo_key>" #From artifactory docs
# PuppetLabs Modules
mod 'puppetlabs/stdlib', '4.24.0'
The command that I'm using is /usr/local/bin/pdk bundle -- exec librarian-puppet install --no-use-v1-api --verbose
The error that I get is:
[Librarian] Resolving puppetlabs-stdlib (= 4.24.0) <https://<artifactory_host>/artifactory/api/puppet/<repo_key>>
[Librarian] Checking manifests Unable to find module 'puppetlabs-stdlib' on https://<artifactory_host>/artifactory/api/puppet/<repo_key>
/tmp/tmp.BXyhBoNRiR/.pdk/cache/ruby/2.1.0/gems/librarian-puppet-3.0.0/lib/librarian/puppet/source/forge/repo_v3.rb:44:in `rescue in get_module'
/tmp/tmp.BXyhBoNRiR/.pdk/cache/ruby/2.1.0/gems/librarian-puppet-3.0.0/lib/librarian/puppet/source/forge/repo_v3.rb:41:in `get_module'
Versions:
puppet 3.8.7
pdk 1.5.0
ruby 2.1.9
According to the documentation at https://www.jfrog.com/confluence/display/RTF/Puppet+Repositories#PuppetRepositories-Usinglibrarian-puppet, it seems I'm trying to get the modules correctly using the librarian-puppet, but something most be missing.
Thanks for any help.
I think Artifacotry does not support Puppet 3.8.7 its documented in Wiki.
Puppet version support
Puppet does not support a context path up to version 4.9.1, we recommend using Artifactory with Puppet version 4.9.2 and above. Please see below if you are using Puppet 4.9.1 and below.
The official Artifactory documentation (not a wiki) recommends using Puppet 4.9.2 or later with Artifactory:
Puppet version support
Puppet does not support a context path up to version 4.9.1, we
recommend using Artifactory with Puppet version 4.9.2 and above.
Please see below if you are using Puppet 4.9.1 and below.
(Emphasis in the original.)
As that comment indicates, however, the docs do also suggest a workaround for use with earlier Puppet:
If you need to use Puppet 4.9.1 and below you can use a workaround
which uses NGINX or Apache to rewrite all requests from /v3/* to
/artifactory/api/puppet/<repo-name>/v3/*.
The docs go on to present some example configurations, which I will not repeat here.
Related
I am working on a nodejs project with typescript 2.2 that is using node 6.3.1 and I want to migrate from using typings to using #types. By doing so I ran into a set of questions related to whether there is a relationship between the version of the #types file and the corresponding npm package.
If I use jasmine as an example, the existing versions of the types definitions are
npm show #types/jasmine#* version
#types/jasmine#1.3.0 '1.3.0'
#types/jasmine#1.3.1 '1.3.1'
#types/jasmine#1.3.2 '1.3.2'
#types/jasmine#2.2.29 '2.2.29'
#types/jasmine#2.2.30 '2.2.30'
#types/jasmine#2.2.31 '2.2.31'
#types/jasmine#2.2.32 '2.2.32'
#types/jasmine#2.2.33 '2.2.33'
#types/jasmine#2.2.34 '2.2.34'
#types/jasmine#2.5.35 '2.5.35'
#types/jasmine#2.5.36 '2.5.36'
#types/jasmine#2.5.37 '2.5.37'
#types/jasmine#2.5.38 '2.5.38'
#types/jasmine#2.5.39 '2.5.39'
#types/jasmine#2.5.40 '2.5.40'
#types/jasmine#2.5.41 '2.5.41'
#types/jasmine#2.5.42 '2.5.42'
#types/jasmine#2.5.43 '2.5.43'
#types/jasmine#2.5.44 '2.5.44'
#types/jasmine#2.5.45 '2.5.45'
#types/jasmine#2.5.46 '2.5.46'
But if I examine the versions of the jasmine packages I have;
npm show jasmine#* version
jasmine#2.0.1 '2.0.1'
jasmine#2.1.0 '2.1.0'
jasmine#2.1.1 '2.1.1'
jasmine#2.2.0 '2.2.0'
jasmine#2.2.1 '2.2.1'
jasmine#2.3.0 '2.3.0'
jasmine#2.3.1 '2.3.1'
jasmine#2.3.2 '2.3.2'
jasmine#2.4.0 '2.4.0'
jasmine#2.4.1 '2.4.1'
jasmine#2.5.0 '2.5.0'
jasmine#2.5.1 '2.5.1'
jasmine#2.5.2 '2.5.2'
jasmine#2.5.3 '2.5.3'
Let’s say I am using version 2.4.0 of jasmine, which version of #types/jasmine should I pick? Because even if I use the latest of both, 2.5.46 does not match with 2.5.3.
Another example would be node itself, there are basically 6.0 or 7.0 versions in #types, and typings has only the ones shown below, being 6.0 reported as obsolete. So, what version of node are those typings actually tied to?
typings view dt~node --versions
TAG VERSION DESCRIPTION COMPILER LOCATION
UPDATED
7.0.0+20170322231424 7.0.0 github:DefinitelyTyped/DefinitelyTyped/node/index.d.ts#a4a912a0cd1849fa7df0e5d909c8625fba04e49d 2017-03-22T23:14:24.000Z
6.0.0+20161121110008 6.0.0 github:DefinitelyTyped/DefinitelyTyped/node/node.d.ts#fb7fbd28b477f5e239467e69397ed020d92817e7 2016-11-21T11:00:08.000Z
Thanks
The major and minor versions of the DefinitelyTyped packages are supposed to correspond to the major and minor versions of the package they are types for. The patch version increments whenever the .d.ts file changes for other reasons. Because the minor version shouldn't represent breaking changes, in theory, you can use the highest 2.x.y definition file available for a 2.a.b.c library.
But now the caveats begin.
The header in the definition file may not have changed at the right time
Library authors do not necessarily follow semver*
The definition file may not be 100% correct at any given point, in either direction (i.e. listing a 2.6 feature under a 2.5 version, or failing to list a 2.4 in function in the 2.5 file)
* In fact, no one does
A detailed explanation can be found in official docs FAQ: How do Definitely Typed package versions relate to versions of the corresponding library?
Basically, i need a working machine with node.js & npm installed.
I've configured a vagrant + berkshelf + chef enviroment, but i can't find a lastest version (>= 4.0.0) nodejs cookbook as source for my berksfile.
I've tried with this:
https://supermarket.chef.io/cookbooks/nodejs
from chef supermarket but install a old version of node + npm.
I am experiencing for the first time vagrant and chef so i can't understand how find it.
Can someone help me?
In your role or node settings you can specify default attributes for any cookbook you use. Cookbook nodejs allows you to set NodeJS version with the attribute version (check its attributes/default.rb file). But this attribute is taken into account only when NodeJS is installed from precompiled binaries or sources. So you need to specify install_method as well (default is package, i.e. installation via system package manager).
One more thing: you need to manually specify binary package checksum, which you can find in every release folder here: https://nodejs.org/download/release/
So, to install the latest version from official binaries use the following settings in role or node:
"nodejs": {
"install_method": "binary",
"binary": {
"checksum": "75b029b30d4a4147d67cf75bf6e034291fb5919c6935ec23f8365cee2d463f12"
},
"version": "5.3.0"
}
I'm on puppet 3.6.2, I have the source for our puppet repo. I want to do this:
irb> require 'rubygems'
irb> require 'puppet'
irb> Puppet[:confdir] = "/home/wwalker/git/puppet"
irb> node=Puppet::Node.new('localhost')
irb> compiler=Puppet::Parser::Compiler.new(node)
irb> scope=Puppet::Parser::Scope.new(compiler)
irb> scope.function_generate_mysql_url(...)
However, I can't get past the compiler:
irb(main):010:0> compiler=Puppet::Parser::Compiler.new(node) Puppet::Context::UndefinedBindingError:
no 'environments' in
{:current_environment=><Puppet::Node::Environment:17836720 #name="*root*" #manifest="no_manifest" #modulepath="" >,
:root_environment=><Puppet::Node::Environment:17836720 #name="*root*" #manifest="no_manifest" #modulepath="" >}
at top of [[0, nil, nil]]
I assume I need to set the "environment", or I've set confdir wrong.
Anyone else done any testing of puppet modules in irb?
I do not have direct access to the puppet server. I've tried this on my workstation (puppet-server 4.1 installed) and on a client (puppet 3.6.2 installed).
This seems so simple, but I'm clearly missing something.
Anyone know what step(s) I'm missing?
I am not really sure what you are trying to accomplish but there is a puppet debugger repl for the puppet language which is very similar to pry/irb but specific to puppet.
https://github.com/nwops/puppet-debugger
You can use the debugger to run any function currently available in your module path among many other features.
You can also set a breakpoint in your puppet code and have it load the debugger using the 'debug::break()' function.
Ruby Version: 2.0.0
Puppet Version: 4.9.4
Puppet Debugger Version: 0.6.0
Created by: NWOps
Type "exit", "functions", "vars", "krt", "whereami", "facts", "resources", "classes",
"play", "classification", "types", "datatypes", "reset", or "help" for more information.
1:>> md5('sdafsd')
=> "569ebc3d91672e7d3dce25de1684d0c9"
2:>>
This is going to be one of those times where someone points you to another tool. If you want to do Ruby debugging, you should really think about using pry (http://pryrepl.org/) instead.
It's what I use during Puppet / modules / Ruby development and it's super simple to use.
In your Gemfile:
gem 'pry'
gem 'pry-stack_explorer'
if RUBY_VERSION =~ /^2/
gem 'pry-byebug'
else
gem 'pry-debugger'
end
Bonus: it works on Windows as well as everywhere else (DevKit may need to be installed).
I've seen the following issue mentioned in another thread a few days ago amongst other problems, but the solution for this issue (to me) didn't seem to be addressed.
I recently ran a test on my Ruby 1.9.2-p290 environment and was presented with the following error when I ran a test script:
You are using an old or stdlib version of json gem
Please upgrade to the recent version by adding this to your Gemfile:
gem 'json', '~> 1.7.7'
This issue continued when I created a completely fresh Ruby 1.9.3-p392 environment, running on Windows XP (don't ask). What confuses me is that even when I have json 1.7.7 or 1.8.0 installed (gem list is pasted below), I still get this message when I run my test. It's not really affecting my test results, but the warning is just rather annoying to see each time.
Which Gemfile do I need to add this version into, and where would it be located?
gem list:
bigdecimal (1.1.0)
childprocess (0.3.9)
commonwatir (4.0.0)
ffi (1.8.1 x86-mingw32)
io-console (0.4.2, 0.3)
json (1.8.0, 1.7.7, 1.5.5)
mini_portile (0.5.0)
minitest (5.0.0, 2.5.1)
multi_json (1.7.3)
rake (10.1.0.beta.3, 10.0.4, 0.9.2.2)
rdoc (4.0.1, 3.9.5)
rubygems-update (2.0.3)
rubyzip (0.9.9)
selenium-webdriver (2.32.1)
watir-webdriver (0.6.4)
websocket (1.0.7)
win32-api (1.4.8 x86-mingw32)
win32-process (0.7.2)
windows-api (0.4.2)
windows-pr (1.2.2)
The message is coming from the multi_json gem, and it seems like it could be a bug. I suggest keeping an eye on this GitHub ticket.
If the message is too distressing, you can downgrade multi_json to version 1.6.1 to get rid of it. (At least this works for me.)
UPDATE:
It looks to me like the root of the problem is that while multi_json wants to limit its use of the json and json_pure gems to specific versions, the author of multi_json isn't using the gem method in his code to activate these versions. (It sounds like he thinks Bundler is the only way to specify versions of gems; it isn't.)
Since multi_json will try the oj and yajl-ruby gems before it tries json, using one of those may be the best workaround of all. So you can just install the latest multi_json and then install either oj or yajl-ruby along with it.
Try this:
gem update --system
gem update
Go to your Ruby installation path, for example,
C:\Ruby192\lib\ruby\1.9.1\json
Open version.rb file and update the version detail as shown bellow:
VERSION = '1.7.7'
Try running your tests with the bundle exec command. This will force your environment to use the gems in Gemfile.lock.
I'm a newbie in Puppet, so maybe you'll find my question a bit stupid...
So, I'm looking for puppet recipe that will install and run Mongodb 2.2 on my machine. By googling I found this module http://forge.puppetlabs.com/puppetlabs/mongodb But I didn't understand clear what should I do?
It said I have to install module on puppet node first. What does exactly it means?
Let's say, I have a set of machines those must be configured via puppet.
What do I have to add to puppet recipe to reach this aim?
In case someone might be interest on installing the last version of MongoDB this worked very well for me. At the moment of writing the latest stable version is MongoDB 3.0.3.
First of all update your OS repositories via the puppet apt module (in case you're using a Debian or Ubuntu distribution). Change the data below according to your distribution and version. Check here to get the MongoDB official repositories information: http://docs.mongodb.org/manual/administration/install-on-linux/#recommended
# $::lsbdistcodename should contain what you usually get
# with the `lsb_release -sc` command
$server_lsbdistcodename = downcase($::lsbdistcodename)
apt::source { 'mongodb-org-3.0':
location => 'http://repo.mongodb.org/apt/debian',
release => "${server_lsbdistcodename}/mongodb-org/3.0",
repos => 'main',
key => '7F0CEB10',
key_server => 'keyserver.ubuntu.com',
include_src => false
}
And then set the mongodb::globals class properly to make sure you get MongoDB 3. The MongoDB puppet module I'm using is this one.
class { 'mongodb::globals':
manage_package_repo => false, # disable the 10gen repository
server_package_name => 'mongodb-org',
service_name => 'mongod',
version => '3.0.3',
}->
class { '::mongodb::server': }
Getting mongodb installed with puppet isn't as easy as it seems. It's somewhat difficult to get official Puppet Labs module v0.8.0 to install mongodb 2.6.3. You end up getting an apt error about mongodb-10gen=2.6.3 not being found. There's an issue and a patch already but it hasn't been published yet.
So here's what you need to do:
git clone https://github.com/puppetlabs/puppetlabs-mongodb.git
Then use the following puppet config:
class { '::mongodb::globals':
manage_package_repo => true,
server_package_name => 'mongodb-org',
version => '2.6.3'
}->
class { '::mongodb::server': }
This Worked for me.
If you are running puppet standalone, you will have already installed the puppet gem and have the puppet executable. To intall the module, you run puppet module install puppetlabs/mongodb. After the module installation, you can simply include the mongodb module in your node definition
node 'myhost' {
include mongodb
}
If you want to run a number of nodes that need access to the module, you'll have to setup a puppetmaster and install the node. See [Basic Agent/Master setup][1] for more info. Make sure that pluginsync=true is enabled in puppet.conf so the module can make it's way to the remote agents.
The puppetmaster will then need a file, normally site.pp defined with the nodes it should configure. Finally, include the mongodb module on each node you want to run mongodb and you should be up and running.