[Puppet Users] PuppetDB 2.1.0 final now available
** Final Release ** PuppetDB 2.1.0 final - July 8th, 2014. PuppetDB 2.1.0 Downloads Available in native package format in the release repositories at: http://yum.puppetlabs.com and http://apt.puppetlabs.com For information on how to enable the Puppet Labs repos, see: http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html#open-source-repositories Blog: http://puppetlabs.com/blog/introducing-puppetdb-2.1.0 Binary tarball: http://downloads.puppetlabs.com/puppetdb/ Source: http://github.com/puppetlabs/puppetdb Please report feedback via the Puppet Labs tickets site, using an affected PuppetDB version of 2.1.0: https://tickets.puppetlabs.com/browse/PDB Documentation: http://docs.puppetlabs.com/puppetdb/2.1/ Puppet module: http://forge.puppetlabs.com/puppetlabs/puppetdb PuppetDB 2.1.0 Release Notes PuppetDB 2.1.0 is a feature release focusing on new query capabilities, streaming JSON support on all endpoints and a new report status field for determining if a Puppet run has failed. Note that this release is backward compatible with 2.0.0, but users must upgrade PuppetDB terminus to 2.1.0 when upgrading the PuppetDB instance to 2.1.0. Things to take note of before upgrading: * There is a known issue in Puppet 3.4.0, 3.4.1 and 3.4.2 with duplicate failed events here: https://tickets.puppetlabs.com/browse/PUP-1524. We recommend upgrading to Puppet 3.4.3 or greater. * If you receive the error “Could not open /etc/puppet/log4j.properties”, this is because we have changed the packaged config.ini to point at a new logging configuration file: logback.xml. However during package installation some package managers will cowardly refuse to just update config.ini, this in particular affects RPM. After upgrading you should ensure any .rpmnew files are reviewed and that changes to our vendored version are now merged with your version of config.ini on disk. See this ticket for more information: https://tickets.puppetlabs.com/browse/PDB-656 * Make sure all your PuppetDB instances are shut down and only upgrade one at a time. * As usual, don’t forget to upgrade your puppetdb-terminus package also (on the host where your Puppet Master lives), and restart your master service. New Features: * (PDB-660) Switch all query endpoints to stream JSON results The following endpoints have been switched over to streaming: - event-counts - reports - nodes - environments - events Using 'event-query-limit' is now deprecated, use the normal paging/streaming functionality to achieve the same results. * (PDB-658, PDB-697) Implement new "query engine" for v4 This rewrite of the v4 API query infrastructure unifies query operators across all endpoints. Each endpoint now supports all operators appropriate for the given field of that type. As an example, any string field can now be searched by regular expression. All dates can be search with inequality operators like < or > for searching via date ranges. There are also many new queryable fields. Below summarizes the new features of the switch to this query engine events endpoint - Added configuration-version as a queryable field - Added containment-path as a queryable field (queryable in a way similar to tags) nodes endpoint - Added facts-timestamp, catalog-timestamp, report-timestamp as a queryable field reports endpoint - Added puppet-version, report-format, configuration-version, start-time, end-time, receive-time, transaction-uuid as queryable fields null? operator - new operator that checks for the presence or absence of a value Some endpoints previously returned NULL values when using a "not" query such as ["not", ["=", "line", 10]]. The query engine follows SQL semantics, so if you want NULL values, you should explicty ask for it like: ["or", ["not", ["=", "line", 10]] ["null?", "line" true]] * (PDB-162) Add regexp support to resource parameter queries The query engine supported this, but the existing "rewrite" rule, to go from the shorthand parameter syntax to the nested resource query didn't recognize ~. That is fixed with this commit, so regexps will now work on parameters. * (PDB-601) Do not require query operator on reports endpoint With this pull request, hitting the reports endpoint without a query argument will return the full reports collection. This behavior is consistent with that of the nodes, facts, and resources endpoints. * (PDB-651) Allow the web app URL prefix to be configurable Previously PuppetDB always used the context root "/", meaning all queries etc would be something like "http://localhost:8080/v4/version";. This change allows users to specify a different context root, like "http://localhost:8080/my-context-root/v4/version";. See the url-prefix configuration documentation for more info * (PDB-16) Add status to stored reports Previously there was no way to disti
Re: [Puppet Users] Re: Windows warning about source permissions
On Mon, Jul 7, 2014 at 3:37 PM, Rob Reynolds wrote:
>
> On Thu, Jul 3, 2014 at 4:44 PM, Michael Legleux wrote:
>
>> The directory already exists.
>> Puppet master and agent are both 3.6.2
>> This is in the debug from the run on the agent.
>>
>> Debug: Using settings: adding file resource 'pluginfactdest':
>> 'File[C:/ProgramData/PuppetLabs/puppet/var/facts.d]{:path=>"C:/ProgramData/PuppetLabs/puppet/var/facts.d",
>> :ensure=>:directory, :loglevel=>:debug, :links=>:follow, :backup=>false}'
>>
>>
>> On Tuesday, July 1, 2014 7:53:34 PM UTC-7, Michael Legleux wrote:
>>>
>>> This warning is haunting me:
>>>
>>> Copying owner/mode/group from the source file on Windows is deprecated;
>>> use source_permissions => ignore.
>>>
>>> It is referenced here:
>>> http://docs.puppetlabs.com/windows/writing.html#managing-
>>> file-permissions
>>>
>>> I am not copying ANY files or anything yet, the site.pp is otherwise
>>> blank. What files are PUPPET copying?
>>> This folder is empty:
>>> so I put this in site.pp
>>> if $osfamily == 'windows' {
>>> File { source_permissions => ignore } }
>>> to no avail.
>>>
>>
> Since this warning is coming from the puppet settings catalog[1] and not
> the regular catalog, I don't believe this would be applied to those items.
>
> [1]
> https://github.com/puppetlabs/puppet/blob/master/docs/catalogs.md#settings-catalog
>
>
>>> Must I just live with this warning? What gives?
>>> Immediately after the warning it says
>>> Debug: /File[C:/ProgramData/PuppetLabs/puppet/var/facts.d]: Copying
>>> owner from the source file on Windows is deprecated; user
>>> source_permissions => ignore.
>>> Debug: /File[C:/ProgramData/PuppetLabs/puppet/var/facts.d]: Copying
>>> mode from the source file on Windows is deprecated; user source_permissions
>>> => ignore.
>>> Debug: /File[C:/ProgramData/PuppetLabs/puppet/var/facts.d]: Copying
>>> group from the source file on Windows is deprecated; user
>>> source_permissions => ignore.
>>>
>>> C:/ProgramData/PuppetLabs/puppet/var/facts.d is empty!
>>>
>>
> I'm a bit surprised to see this issue, unless there is some sort of sync
> for external facts you are attempting from the master. With the directory
> being empty it doesn't make sense though. It could be this is just a spot
> where the setting wasn't applied in the settings catalog. It may be we need
> to address it.
>
We created PUP-2907[1] to address this issue.
[1] https://tickets.puppetlabs.com/browse/PUP-2907
>
>
>
>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-users/e4a17a27-bb72-4be1-b085-72e100d12f72%40googlegroups.com
>>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Rob Reynolds
> Developer, Puppet Labs
>
> *Join us at PuppetConf 2014 **--**save
> $249!*
>
--
Rob Reynolds
Developer, Puppet Labs
*Join us at PuppetConf 2014 **--**save $249!*
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAMJiBK7hCX%2BhAnooYxbEUUhw2xRM1xqMDKJXvw7mgyfYHynJjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Editing fstab with Augeas
Hmm. I don't believe mount will do what I want, as every server has
different NFS mounts I need to modify. Can I say "modify every NFS mount so
that it's nosuid" without actually specifying the mountpoints?
On Monday, July 7, 2014 9:13:44 PM UTC-5, Pete wrote:
>
> Is there a reason you aren't using the builtin mount type?
> I believe it can do everything you require.
>
> http://docs.puppetlabs.com/references/stable/type.html#mount
>
> On 8 July 2014 04:42, Kim Scarborough >
> wrote:
> > I'm trying to get Puppet to add "nosuid" to all my nfs or nfs4 mount
> entries
> > in /etc/fstab. I'm currently using this:
> >
> > augeas { "fstab-nosuid":
> >context => "/files/etc/fstab/*[vfstype = 'nfs' or vfstype =
> > 'nfs4'][count(opt[. = 'nosuid']) = 0]",
> >
> >changes => [
> >"ins opt after opt[last()]",
> >"set opt[last()] nosuid"
> >],
> >
> >onlyif => "match /files/etc/fstab/*[vfstype = 'nfs' or
> vfstype =
> > 'nfs4'][count(opt[. = 'nosuid']) = 0] size > 0",
> > }
> >
> >
> > This works, but it only edits a single line per run. How can I change it
> to
> > do all of the relevant lines at once?
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "Puppet Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an
> > email to puppet-users...@googlegroups.com .
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/puppet-users/a3163d8a-ed0c-4472-b201-54dfd4b68d95%40googlegroups.com.
>
>
> > For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/23570670-35b0-4e50-bd2d-57f8eca8b0c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: SSL error when after restarting httpd. CA information missing/or wrong?
OK, so this is a straight line version of how I debugged the issue. There were a couple more dead ends than described here. The first thing to notice is the error. I was getting: "certificate verify failed: [self signed certificate for /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ECM-RHL-001/emailAddress=root@ECM-RHL-001". This told me a couple of things: - The certificate verification was failing. - The identity given in the certificate was: "/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ECM-RHL-001/emailAddress=root@ECM-RHL-001". I checked the configuration of the Puppet virtual site. It all looked OK. I then turned to openssl (https://www.openssl.org/docs/apps/x509.html) to check the certificates. I used the following (substituting the certificate file for cert.pem) to print out the server and CA certificates used in the configuration: openssl x509 -in cert.pem -noout -text I decided to have a look at the certificates I got if I connected to the server. Again openssl is your friend ( http://stackoverflow.com/questions/7885785/using-openssl-to-get-the-certificate-from-a-server). I ran the following with output to separate files for the WEBrick and Apache servers. openssl s_client -showcerts -connect ecm-rhl-001:8140 WEBrick.certs openssl s_client -showcerts -connect ecm-rhl-001:8140 Apache.certs This gave me 2 files each with 2 certificates in it. The first certificate is the server certificate and the second is the CA certificate. A brief inspection of the files showed that the first certificate was different whilst the second the same: ie the server certificates differed but the CA certificates were the same. I confirmed this further by splitting each certificate out to a separate file and using openssl to print text representations as per check on configured certificates above. So where were the different certificates coming from? Openssl (again) lets me print out and md5 for a certificate and a private key. The md5 will match for matching certificates and keys. openssl x509 -noout -modulus -in signed/ecm-rhl-001.pem | openssl md5 openssl rsa -noout -modulus -in private_keys/ecm-rhl-001.pem | openssl md5 This allowed me to check that the certificate and private keys matched. It also gave me a quick way to check what keys the certificates that I retrieved from the servers matched. All checked out OK. I still could not locate the illusive certificate that was being returned by the Apache server. I checked a number of possible keys and So I went back to look at the Apache configuration and checked all of them for 'SSLCertificateFile' using grep. This showed the that "SSL Configuration" had a certificate defined in it by default. A quick check using the previous Openssl commands showed that it matched the one returned by the Apache server. A few comments to remove the unwanted site from the Apache configuration and everything was working again. I've installed ssl on a number of Apache servers (debian package, ubuntu package & compiled from source) over the last 15 years or so and this is the first time the ssl configuration has included a "live" ssl virtual host definition. Tom -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/0553fe0f-cfdd-4041-b6d3-2529b685544a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Execute commands on puppet master
On Monday, July 7, 2014 4:26:47 AM UTC-5, shashank sinha wrote: > > Hello, > > I am working on some project where I need to execute scp command on puppet > master to copy files from some external server to module/files/* each time > when puppet agent pull request received to master.I want something like to > copy a file and store it to puppet master /modules/files folder. > > Is it possible to execute scp commands on puppet master > (password/password-less environment). > > You can use the built-in generate() function to execute an arbitrary system command on the master during catalog compilation. You can write a custom function to do the same. You can run your command via Ruby code embedded in a template, via the template() or inline_template() function. Having said that, what you are describing sounds like a bad idea to me. If you want your Puppet clients to obtain files originating on some third server, then why not have them retrieve those files directly? Doing so would spread the load better, and would minimize the risk of accidentally trashing your Puppet master by copy the wrong file into the wrong place. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/4c175ecc-3204-4399-b765-940c5281c8ff%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Package install from a URL
On Monday, July 7, 2014 3:54:50 PM UTC-5, Jonathan Rose wrote:
>
> I tried fiddling around with a puppet module I am writing to install RPM's
> both from repository as well as local resources (e.g. http) and tried the
> advise noted by David Caro, but I'm still getting error messages:
>
> Skipping.
> Error: Nothing to do
> returned 1: Cannot open:
>
>
David's advice is unfortunately un-sound. You do not normally need to use
the "name" parameter with the 'yum' package provider, because yum normally
uses the package name as the desired RPM name. That is, simply:
package { 'my-package-name':
ensure => 'installed',
}
Note that that's normally just the *package* name as it will be recorded in
the RPM database, not the RPM filename. But that only works if the
specified package is in one of the yum package repositories that your
system is already configured to use. Your objective here appears to be to
configure a package repository that may not already be configured, and for
that you cannot use the 'yum' provider at all -- it's simply not the way
Yum works.
If you want to manage an RPM package from a specific local or http[s]
source that you specify, then you need to ensure that the 'rpm' provider be
used. On most systems that use RPMs, the default provider is something
more flexible, such as 'yum', so you need to declare the 'rpm' provider
specifically if you want to use it (i.e. what Mark wrote). Note also
Jonathan's comments about package dependencies, which are the reason other
providers are preferred to the plain 'rpm' provider for most purposes.
Dependencies should not be an issue for your particular case, so probably
this will work:
package { 'puppetlabs-release':
ensure => 'installed',
source => 'https://yum.puppetlabs.com/el/6/products/x86_64/puppetlabs-
release-6-5.noarch.rpm',
provider => 'rpm'
}
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/30ba3d18-9074-4523-a3b9-e4ab98c0a651%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Regarding Puppet Agent process on Agent Machine
On Tuesday, July 8, 2014 3:47:25 AM UTC-5, Satish Katuru wrote: > > Hi, > > I linked both Master and Agent machines.But I am unable to see the Agent > process on Agent machine. > Can we have the Agent process on the Agent machine? > > I used below command to get the latest code > > puppet agent -t --waitforcert=60 > > When I Execute it every time it would take the code from master and deploy > it on Agent machines.But how the agent machine looks for the latest code on > Master machine for every 30 minutes? > > Do we need to do any configuration settings? > > and > > How can i see the agent process on agent machine? > > You are running the agent with the -t (--test) option, which implies several other options including --no-daemonize (but *not* --noop). If you want to run the agent as a daemon then omit that option. Rather than launching it manually, though, it would be better to launch it via its service management script, which should have been installed as part of the package (supposing you used a package, rather than a source install). On many systems, the command would be "service puppet start". John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/058e900d-0805-4430-85db-80bab05128d1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: delete files from Master server
On Tuesday, July 8, 2014 4:05:48 AM UTC-5, Satish Katuru wrote: > > Hi , > > My intention is to deleted the files from Master server once the > deployment is over on agent machines. > > How can i achieve this? > > Once I execute *puppet agent -t *deployment will be done on agent > machine.After this I wanted to remove files from master server. > > Help me out on this? > > If that's your intention, then why are you storing the files on the master even transiently? Puppet is a configuration *management* system. Part of that is updating machine configuration as appropriate, but if you leave it there then you are missing half the picture. Puppet is designed to also maintain the state it sets. That's a long way of saying that Puppet has no mechanism for what you request, as it runs counter to the system's design objectives. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/53e80baf-2b03-4372-9774-7dc556414d15%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] vcsrepo module: Add option shared for GIT repository
Hello all,
I'd like to use the vcsrepo to manage multiple git repository on our "git
server", but while looking at the documentation (and code) of the vcsrepo
module I noticed that it doesn't manage the initialization of a repository
with the option --shared , an option that usually we set to be able to
easily work as group on a repository.
I'd like to define on my manifest something like this:
vcsrepo {
"/shared/myrepo":
ensure =>
bare,
provider =>
git,
shared =>
true,
owner=>
'myuser',
group=>
'sharedgroup',
}
To achieve this I've done a small change on the code (at the end of the
mail), it works but I wonder if there are better way to get my goal or if
you think that this could be useful to someone else and so I should send a
PR.
Thanks for the feedbacks.
---
Riccardo
diff --git a/common/vcsrepo/lib/puppet/provider/vcsrepo/git.rb
b/common/vcsrepo/lib/puppet/provider/vcsrepo/git.rb
index 5c878ed..bf30f57 100644
--- a/common/vcsrepo/lib/puppet/provider/vcsrepo/git.rb
+++ b/common/vcsrepo/lib/puppet/provider/vcsrepo/git.rb
@@ -181,6 +181,9 @@ Puppet::Type.type(:vcsrepo).provide(:git, :parent =>
Puppet::Provider::Vcsrepo)
if @resource.value(:ensure) == :bare
args << '--bare'
end
+ if @resource.value(:shared)
+args << '--shared'
+ end
at_path do
git_with_identity(*args)
end
diff --git a/common/vcsrepo/lib/puppet/type/vcsrepo.rb
b/common/vcsrepo/lib/puppet/type/vcsrepo.rb
index 3dd7bc6..a0ee991 100644
--- a/common/vcsrepo/lib/puppet/type/vcsrepo.rb
+++ b/common/vcsrepo/lib/puppet/type/vcsrepo.rb
@@ -204,6 +204,10 @@ Puppet::Type.newtype(:vcsrepo) do
desc "The value to be used to do a shallow clone."
end
+ newparam :shared do
+desc "Define if the repository is shared (git) "
+ end
+
autorequire(:package) do
['git', 'git-core']
end
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/014ef921-66f8-458b-bb69-0c80a45e07ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: SSL error when after restarting httpd. CA information missing/or wrong?
It took a bit of digging - but I did workout what the issue was. I'll give the solution first and then an overview of how I diagnosed the issue It may be useful to others with SSL issues. I was running Puppet on a Red Hat server. By default Red Hat installs an SSL configuration in /etc/httpd/conf.d. The Puppet server's default configuration is also installed in /etc/httpd/conf.d and loads before the SSL configuration. I'd moved the puppet configuration (a virtual host / site ) to /etc/httpd/sites-available so it now loads after the SSL configuration and is in the same location as other sites / virtual hosts. Unfortunately the default Red Hat SSL configuration includes a virtual host with a self signed certificate. Unlike other SSL configuration these are not commented out. SSL certificates are selected on a per IP basis. The first one loaded by Apache for an IP takes precedence. The Red Hat SSL certificate was therefore loading and the one in the Puppet configuration was being silently ignored. The solution was simple: comment out the unused virtual host configuration in the default Red Hat SSL configuration. I'll follow up later on how I debugged this issue. Tom -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/13c73ae2-a9b3-4f27-915d-a8190715ed3d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] delete files from Master server
Hi , My intention is to deleted the files from Master server once the deployment is over on agent machines. How can i achieve this? Once I execute *puppet agent -t *deployment will be done on agent machine.After this I wanted to remove files from master server. Help me out on this? Sathish. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/49ece2d1-5e89-4860-9101-dcbb22bc7e31%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Regarding Puppet Agent process on Agent Machine
Hi, I linked both Master and Agent machines.But I am unable to see the Agent process on Agent machine. Can we have the Agent process on the Agent machine? I used below command to get the latest code puppet agent -t --waitforcert=60 When I Execute it every time it would take the code from master and deploy it on Agent machines.But how the agent machine looks for the latest code on Master machine for every 30 minutes? Do we need to do any configuration settings? and How can i see the agent process on agent machine? satish.. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/2cc88375-3ec6-484a-9178-e700aa07c134%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Puppet, Vagrant and repos
Yanis, Doug, thank you very much.
Max
On 2014-07-07 17:49:44 +, Yanis Guenane said:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
To second Doug, I also uses a module for each repo I want to add.
This way you can probably have a base profile, like the following :
class profile::base {
resources { 'yumrepo' :
purge => true,
}
include ::epel
include ::nginx
include ::repoforge
}
And only the module you specify will be enabled. It will be clear for
whoever look at the code which repo are to be enabled.
- --
Yanis Guenane
On 07/07/2014 12:01 PM, Doug Forster wrote:
Max,
I do a single module for each repo that I want added. In some cases
I combine it with a repo to manage the service. IE mysql* repos
would be managed via the mysql module.
As for making sure they are all up to date I might just create an
exec {my_check_update: refreshonly => true, command => "yum
check-update", }
I might even try to setup a global dependency in your site.pp.
Someone else probably has a smarter idea though. Yumrepo { notify
=> Exec[my_check_update] }
In case you may have missed it on all my vagrant boxes I run a yum
check-update each time they are provisioned. Vagrant.configure("2")
do |config| config.vm.provision "shell", inline: "yum
check-update" end
Hope it helps. :) Doug
On Mon, Jul 7, 2014 at 9:35 AM, Andrei Maxim
wrote:
Hi,
I've been looking into Puppet recently and I'm trying to setup a
couple of virtual machines that should mimick what's in
production. I'm pretty much a developer trying to lean towards
DevOps :-)
Locally, I'm using Vagrant and the CentOS 6.5 64-bit box with
Puppet 3.4.3 that was published by Puppetlabs, which should
somewhat mirror what's on the servers (a custom AMI based on
CentOS 6.5).
What I'm trying to do right now -- and I've found a bunch of ways
to do this -- is to setup a couple of repositories (EPEL and
MySQL Community being the most important ones). I've noticed that
people do this in a number of ways, from grabbing the RPM package
to using the 'yumrepo' type to adding a custom module for each
repo or by using a general purpose Yum module (like the one from
example42) and specifying the repos there.
Normally, when I install those repos, I download the RPM locally
and install it using the command line, for example:
yum install http://dev.mysql.com/get/
mysql-community-release-el6-5.noarch.rpm
That RPM will create a number of entries in the
/etc/yum.repos.d/, which seems odd to add each one by hand using
the `yumrepo` type.
I've seen this example given a number of times (it's also the
correct answer to a similar question on SO):
node default { include base }
class base { yumrepo { "IUS": baseurl =>
"http://dl.iuscommunity.org/pub/ius/stable/$
operatingsystem/$operatingsystemrelease/$architecture", descr =>
"IUS Community repository", enabled => 1, gpgcheck => 0 } }
Then, for any node that extends base you can say class foo {
package { "bar": ensure => installed, require => Yumrepo["IUS"]
} }
Going back to the example with the MySQL Community RPM, I would
have to manually do this for three repos (the other two are
disabled):
* mysql-connectors-community * mysql-tools-community *
mysql56-community
Is this still the accepted solution in the Puppet community? If
so, how would you organize those repositories? Create a module
for each repository? Create a repository module with all the
sources?
And, somewhat related to this subject, I've noticed that I might
get some errors when provisioning my VMs because the base system
wasn't up to date. I was planning to add a `yum update` command
to my setup, but I realize that this might not be the best
solution because I might not want to update the base system
everytime I run puppet.
What's the best way to update the system only when running Puppet
for the first time?
Thanks, Max
-- You received this message because you are subscribed to the
Google Groups "Puppet Users" group. To unsubscribe from this
group and stop receiving emails from it, send an email to
puppet-users+unsubscr...@googlegroups.com. To view this
discussion on the web visit https://groups.google.com/d/
msgid/puppet-users/lpeenc%243ai%241%40ger.gmane.org. For more
options, visit https://groups.google.com/d/optout.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTut2vAAoJEPh7fjCNYlpntCIH/3nT5kw7XLesDyUkP7fiE17H
gTl77/7bOHeJxHWWHeeTyzh5X/EjRYzl+sA/BasyLTMQjrAUFJc9ZP/ARFbOn1My
wuEBTpaeLzeH+pTMT6fER0vD0GsJVSnA2jasn5czT88Ql6PLGXfGhKJnI9NvKCe3
Ic5Hjuj+IKpTFMUQ+/ZznRdIKBiaMJ2+RLb/6kIFc/yYYoAMXZbMJMyeLhOwH1jK
iyKLMZjI98Bh2rz6mIZGK4Ey2f0r1QjqK/3wDiDMoERj/O+qM5vBRazxgSLXYra3
ewG0r7LQx8LNKgxSuKUMwYdTruPsZNMIm6o76cpFB6l2CuKlAQ9R4dK5rstUsng=
=r7Zl
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppe
