you need to adjust the hiera hierarchy. To adjust it you need a top scope
variable (e.g. "pod_prefix")
(https://docs.puppetlabs.com/puppet/latest/reference/lang_scope.html#top-scope
) to be used in hiera.yaml configuration file.
you could also make a custom fact
(https://docs.puppetlabs.com
>
> For this (and a few other reasons), the breaking change of removing the -p
> switch in Facter 3.0.0 is being reverted in 3.0.2, which will be released
> very soon.
>
When do you expect it to be released ?
I've found many bugs with facter 3 (and I've been using it only for a few
days),
I want to both install puppet 4 and some mcollective plugins on a CentOS 6
As the the mcollective plugins are not in the PC1 repository, I need the
products repository. But then :
yum install
https://yum.puppetlabs.com/el/6/products/x86_64/puppetlabs-release-6-11.noarch.rpm
https://yum.puppe
Figured it out! The issue was not with my Puppet code, but simply with my
Vagrantfile.
I had the following:
config.vm.provision :puppet do |puppet|
puppet.manifests_path = "manifests"
puppet.module_path = "modules"
puppet.working_directory = "/vagrant"
puppet.facter = {
}
end
I edited
On Tuesday, July 21, 2015 at 12:25:25 AM UTC-5, Thomas Müller wrote:
>
>
> Saz/ssh seems to use the standard sshkey type to export the host keys.
> Code: https://github.com/saz/puppet-ssh/blob/master/manifests/hostkeys.pp
>
> Seems you can export the non-puppet managed keys on a puppet managed n
Hi All,
I am getting following error while running "puppet agent"
puppet agent -tv
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Unable to add resolve nil for fact ks_memsql_nodeid: undefined method
`num_rows' for "Error: 2003":String
Unable to add resolve nil for fact
On Monday, July 20, 2015 at 9:45:12 PM UTC-5, Fabien Delpierre wrote:
>
> Peter, Felix,
> Thank you for your answers!
>
> I guess my improperly worded question was about figuring out whether
> Puppet has a concept similar to what Chef calls a wrapper cookbook.
>
>
I know nothing more about "wra
On Monday, July 20, 2015 at 6:28:09 PM UTC-5, Stack Kororā wrote:
>
> Greetings,
>
> First, a short intro. :-)
>
> Last year I invested quite a bit of time building out a puppet
> infrastructure. I have +150 Scientific Linux 6 and RHEL 6 servers running
> puppet 3.7.1. It has been working real
On Tuesday, July 21, 2015 at 9:46:56 AM UTC-4, jcbollinger wrote:
>
>
> I know nothing more about "wrapper cookbooks" than I can deduce from their
> name and your code, but they sound like they may have some similarity with
> the Puppet pattern called "Roles & Profiles", conceived by Craig Dunn
Op dinsdag 21 juli 2015 01:28:09 UTC+2 schreef Stack Kororā:
>
> If I am willing to take the time to migrate to puppet-forge modules anyway
> (plus hopefully fix any bad code I can't replace), wouldn't this be a good
> time to switch puppet versions too?
>
I would definitely think so, but one th
On Tue, Jul 21, 2015 at 1:27 AM, Fabrice Bacchella <
fabrice.bacche...@orange.fr> wrote:
>
>
> >
> > For this (and a few other reasons), the breaking change of removing the
> -p switch in Facter 3.0.0 is being reverted in 3.0.2, which will be
> released very soon.
> >
>
> When do you expect it to
On 07/21/2015 04:14 PM, jcbollinger wrote:
>
>
> 2)
> I read in the changelog that the older clients should work with
> the backward compatibility, but is it worth even trying? Or should
> I just push out the updated puppet client wherever I can before
> adding the server into m
> There have been a number of regression fixes including fixes to command
> execution, inclusion of the -p option, porting the xendomains fact, OS fact
> fixes, and the fqdn fact reporting incorrectly on some systems.
>
> If there's an issue you're running into that you don't see being addresse
On a linux, if I enumerate interfaces using standards tools I get :
~# ip link list
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: mtu 1500 qdisc mq master bond0
state UP qlen 1000
link/ether 00:1c:c4:74:83:80 brd ff:ff:ff:ff:
I thought I was doing those things. I set up a FACTER_ env var on one of
my nodes to test like so ...
[root@vii-osc4-mgmt-001 ~]# cat /etc/profile.d/POD_prefix.sh export
FACTER_pod_prefix=vii-osc4
I rebooted the node, vii-osc4-mgmt-001, and checked that env. var is being
set (maybe it's not)
[r
On Tue, Jul 21, 2015 at 9:50 AM, Fabrice Bacchella <
fabrice.bacche...@orange.fr> wrote:
> On a linux, if I enumerate interfaces using standards tools I get :
> ~# ip link list
> 1: lo: mtu 65536 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: eth0: m
Systemd services do not have access the normal environment variables that are
present in yor shell.
--
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
I am probably confused when it comes RHEL7. But systemd comes into play
here only when I restart my puppet master with "# systemctl restart
pe-httpd" right? I thought I had confirmed that fact pod_prefix is getting
set on the node when I execute:
[root@vii-osc4-mgmt-001 ~]# facter pod_prefix
vii-
> I agree that Facter could do a better job merging the secondary "interface"
> into the primary one here. It shares the networking fact code with a few
> other platforms (mainly OSX and the BSDs) and it currently doesn't do any
> specific logic for Linux to merge bonded interfaces together.
>
ah you mentioned it already ... fact.d
On Tue, Jul 21, 2015 at 11:03 AM, Russell Cecala wrote:
> I am probably confused when it comes RHEL7. But systemd comes into play
> here only when I restart my puppet master with "# systemctl restart
> pe-httpd" right? I thought I had confirmed that fact p
On Tue, Jul 21, 2015 at 11:06 AM, Fabrice Bacchella <
fabrice.bacche...@orange.fr> wrote:
> I agree that Facter could do a better job merging the secondary
> "interface" into the primary one here. It shares the networking fact code
> with a few other platforms (mainly OSX and the BSDs) and it cur
Are you saying that my test is no good because it is using the environment
> from the shell?
>
yes systemd does not send provide /etc/profile.d environment to its
services.
just don't use FACTER_ env variables. Use facter-dot-d or a custom fact in
a puppet module.
- Thomas
--
You rec
> Le 21 juil. 2015 à 20:33, Peter Huene a écrit :
>
> Thus there would be no "eth0:1" in the interfaces list; it would just show up
> as the first element in the secondary array. e.g. eth0:1 becomes
> eth0.secondary.0, eth0:2 becomes eth0.secondary.1, etc.
>
> Thoughts on this approach? It
Gotcha! Thanks
On Tue, Jul 21, 2015 at 11:33 AM, Thomas Müller
wrote:
>
>
>
> Are you saying that my test is no good because it is using the environment
>> from the shell?
>>
> yes systemd does not send provide /etc/profile.d environment to its
> services.
>
> just don't use FACTER_ env variabl
On Tue, Jul 21, 2015 at 11:47 AM, Fabrice Bacchella <
fabrice.bacche...@orange.fr> wrote:
>
> > Le 21 juil. 2015 à 20:33, Peter Huene a
> écrit :
>
> >
> > Thus there would be no "eth0:1" in the interfaces list; it would just
> show up as the first element in the secondary array. e.g. eth0:1 bec
>
>
> If you have access to Facter 2.x on this same system, I'd be curious to see
> if it would output the secondary interface / address information. If not, I
> think we could consider Facter's 3.x behavior to be a bug and fix it by
> moving the secondary interfaces to where they belong.
On
>
> Right. But with a caveat: the random number is not really random. In
> fact the random generator is seeded with the node fqdn. Since this is a
> constant, the generated random number won't change from run to run for a
> given node.
>
>
> Or if you want to manage cron resource directly:
>
>
OK I tried looking into the facter-dot-d way of setting a custom fact, but
it does not seem suitable for what I am trying to do.
I want some nodes to report the fact pod_prefix as 'vii-osc4' and I will
want other nodes to report pod_prefix as 'ix-xyz' so that my hiera.yaml
hierachy of ...
root@svl
On Tue, Jul 21, 2015 at 12:26 PM, Fabrice Bacchella <
fabrice.bacche...@orange.fr> wrote:
>
>
> If you have access to Facter 2.x on this same system, I'd be curious to
> see if it would output the secondary interface / address information. If
> not, I think we could consider Facter's 3.x behavior
I am using the VLAN resource type to manage VLANs on a Cisco 4500.
On every run puppet reports that it created the VLAN (even though it
exists).
Grabbing data from hiera:
network::layer3::vlans:
site:
name: 703
description: 'Site'
management:
name: 712
description: 'Managment
Doh! The /etc/facter/facts.d/pod_prefix.txt file goes on the nodes NOT the
puppet master. And it works!
On Tue, Jul 21, 2015 at 1:10 PM, Russell Cecala
wrote:
> OK I tried looking into the facter-dot-d way of setting a custom fact, but
> it does not seem suitable for what I am trying to do.
> I
How to get all puppet agent/master logs to rsyslog? intend to ship all
puppet agent/master messages to central loghost and parse with logstash and
ship to elasticsearch. Currently puppet logs some messages to
/var/log/messages via rsyslog while puppet daemons write directly to
/var/log/puppet/
For the puppet agent, you can always try tdis rsyslog syntax:
if $programname == 'puppet-agent' then /var/log/puppet.log
if $programname == 'puppet-agent' then ~
Same for the master process.
On Tue, Jul 21, 2015 at 11:29 PM, eric odell wrote:
> How to get all puppet agent/master logs to rsyslog
On Tuesday, July 21, 2015 at 9:14:04 AM UTC-5, jcbollinger wrote:
>
>
>
>> Questions!
>>
>> 1a)
>> I am debating as to whether I need to build multiple puppet masters or
>> not. Is the following documentation still valid for the 4.x series of
>> puppet?
>> https://docs.puppetlabs.com/guides/
On Tuesday, July 21, 2015 at 9:44:45 AM UTC-5, Martijn wrote:
>
> Op dinsdag 21 juli 2015 01:28:09 UTC+2 schreef Stack Kororā:
>>
>> If I am willing to take the time to migrate to puppet-forge modules
>> anyway (plus hopefully fix any bad code I can't replace), wouldn't this be
>> a good time t
On Tuesday, July 21, 2015 at 11:33:29 AM UTC-5, Felix.Frank wrote:
>
> On 07/21/2015 04:14 PM, jcbollinger wrote:
>
>
>> 2)
>> I read in the changelog that the older clients should work with the
>> backward compatibility, but is it worth even trying? Or should I just push
>> out the update
One last update on my progress.
I have 4 installed on Scientific Linux with the only client being itself at
the moment. The current plan is to either find replacement modules or move
over as many modules as I can. If I can get the bulk of the modules and a
few important ones, then I will be ver
Hi all,
Is there currently a preferred package provider for Mac? I'm trying to
determine whether pkgdmg or gem is the better option for a set of packages
I'm installing.
Thanks,
Mike Turner
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
T
38 matches
Mail list logo
