Re: [Puppet Users] puppetserver puppetdb and storeconfigs=true
Ken, Kevin, good evening. On Thu, 23 Jul 2015 17:58:20 +0100 Ken Barber wrote: > The problem is, that if you're contacting PuppetDB in this case for > your fact information, something is wrong. The 'bug' is that if PDB is > referenced for this information it tries to clobber trusted_facts, but > you should never get this far under a compilation workflow. > > This can sometimes be caused by a timing issue, due to the cache > looking like its expired (even though it was just written) so it > reaches out to the PDB terminus for its answer. Kevin also suggested skew could cause this but I can rule that out as the master was failing on itself. > The other cause can be a misconfigured routes.yaml, or some other > workflow problem. What does your routes.yaml look like? This can be > misconfigured to always use PDB for that information, which is bad. > Facts should come from agents, not from a cache inside PDB during > compilation :-). BINGO I had no routes.yaml (the 3.8.1 yaml was in the wrong place in the move not only in software but to environments too). Putting that back into $confdir and with a puppetserver restart all is well again. Thanks both for your time and help. Cheers, Steph -- Steph Gosling -- 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/20150723231132.085da2c69cbbf44cf9b75385%40chuci.org. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] puppetserver puppetdb and storeconfigs=true
Hi all, I'm attempting a migration from a PuppetDB 2.x and rack Puppet 3.8.1 install over to the all new 'pc1' puppetserver puppet-agent PuppetDB v3 stack[0]. On the two nodes I've tried so far (the master itself and a test node) I'm getting the following error: Error 400 on SERVER: Attempt to assign to a reserved variable name: 'trusted' on node This is broadly the same error as PDB-949[1] and at least one other user [2] has had this issue with the same setup. If I disable storeconfigs then my manifests run with both agents just fine. With storeconfigs enabled (and even if the environment is completely empty) this is what puppetserver logs /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/network/http/handler.rb:58:in `process' file:/opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/puppet-server-lib/puppet/server/master.rb:39:in `handleRequest' Puppet$$Server$$Master_35370687.gen:13:in `handleRequest' request_handler_core.clj:274:in `invoke' request_handler_service.clj:14:in `handle_request' request_handler.clj:3:in `invoke' request_handler.clj:3:in `invoke' core.clj:626:in `invoke' core.clj:2468:in `doInvoke' master_core.clj:47:in `invoke' ring.clj:22:in `invoke' ring.clj:13:in `invoke' comidi.clj:267:in `invoke' ringutils.clj:106:in `invoke' ringutils.clj:62:in `invoke' ringutils.clj:68:in `invoke' ringutils.clj:118:in `invoke' jetty9_core.clj:408:in `invoke' 2015-07-23 17:09:45,728 ERROR [puppet-server] Puppet Attempt to assign to a reserved variable name: 'trusted' on node 2015-07-23 17:09:45,737 ERROR [puppet-server] Puppet Attempt to assign to a reserved variable name: 'trusted' on node PuppetDB logs only successful updating of facts and the report: 2015-07-23 17:09:45,224 INFO [p.p.command] [64604053-f1cb-4588-8c09-e7fc95c6b348] [replace facts] 2015-07-23 17:09:45,833 INFO [p.p.command] [4f7df7c3-715a-4b97-8eff-917329667a9f] [store report] puppet v4.2.1 - The above URLs both allude to trusted facts clobbering other facts and/or timing issues. I definitely don't have timing issues (given one of the agents is colocated with its master). I've completely purge all of the old Puppet installations and even dropped the Postgres DB so I think my stack reall should work. Does anyone have any pointers as to how I should debug this further? Cheers, Steph [0] Master and agent nodes are all Ubuntu 14.04, packages are all the official puppetlabs-release-pc1 packages, specifically puppetdb-3.0.1-1puppetlabs1 puppetdb-termini-3.0.1-1puppetlabs1 puppetserver-2.1.1-1puppetlabs1 puppet-agent-1.2.2-1trusty [1] https://tickets.puppetlabs.com/browse/PDB-949 [2] http://ask.puppetlabs.com/question/17184/attempt-to-assign-to-a-reserved-variable-name-trusted/ -- Steph Gosling -- 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/20150723172504.d014d8b7983f5974cb98ac40%40chuci.org. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Provider must have features 'manages_symlinks' to set 'ensure' to 'link' shouldn't happen on Linux?
Hi, On Tuesday, December 31, 2013 1:33:25 PM UTC, jmslagle wrote: > > > > > Out of curiosity, do you have both a package and the gem installed? > I've seen this behavior when the package got updated, but the gem was > still an older version. Also make sure you bounce the master if the > package got upgraded. > > Jason > Jason you're a star. Gem said I had the puppet 3.2.1 gem installed as well and on removal that sorted the issue. As to why that was there I'm not sure but at this stage I'd put money on it being PEBKAC thing rather than a packaging issue. Thank you again for the suggestion. Cheers, Steph -- 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/cc109a80-d77a-4b6c-92eb-6c27aeaa68e9%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Provider must have features 'manages_symlinks' to set 'ensure' to 'link' shouldn't happen on Linux?
Isn't it!
Applying that resource fails in the same way: as requested here's the
output though debugging doesn't seem to add anything, which is a bit odd.
[root@nodename steph]# puppet apply --debug --verbose -e 'file {
"/tmp/test": ensure => link, target =>
"/tmp/test-target" }'
Info: Loading facts in /var/lib/puppet/lib/facter/hostname.rb
Info: Loading facts in /var/lib/puppet/lib/facter/memory.rb
Info: Loading facts in /var/lib/puppet/lib/facter/enumerate_xen_disks.rb
Error: Parameter ensure failed on File[/tmp/test]: Provider must have
features 'manages_symlinks' to set 'ensure' to 'link' at line 2
Wrapped exception:
Provider must have features 'manages_symlinks' to set 'ensure' to 'link'
[root@nodename steph]#
Running that on one of the functioning nodes and I get reams of debugging
output as I'd expect so it looks like there's something curious with the
environment, I just don't know what.
On Monday, December 30, 2013 11:54:36 PM UTC, Felix.Frank wrote:
>
> Hi,
>
> that's weird. Does this work?
>
> puppet apply -e 'file { "/tmp/test": ensure => link, target =>
> "/tmp/test-target" }'
>
> If it yields the same error, please add -dv and share the debug output.
>
> Thanks,
> Felix
>
> On 12/30/2013 01:21 PM, Steph Gosling wrote:
> >
> > Error: Failed to apply catalog: Parameter ensure failed on
> > File[/etc/localtime]: Provider must have features 'manages_symlinks' to
> > set 'ensure' to 'link' at /etc/puppet/manifests/nodes/basenode.pp:198
> > Wrapped exception:
> > Provider must have features 'manages_symlinks' to set 'ensure' to 'link'
>
--
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/b4941941-36d0-4be6-816b-becb461d8ffc%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Provider must have features 'manages_symlinks' to set 'ensure' to 'link' shouldn't happen on Linux?
Hey all,
Done a bit of googling for this and haven't seen it yet.
I have one of about 120 nodes running the puppetlabs repo version 3.4.1 on
CentOS 6 that has inexplicably started throwing this:
Error: Failed to apply catalog: Parameter ensure failed on
File[/etc/localtime]: Provider must have features 'manages_symlinks' to set
'ensure' to 'link' at /etc/puppet/manifests/nodes/basenode.pp:198
Wrapped exception:
Provider must have features 'manages_symlinks' to set 'ensure' to 'link'
There are four nodes in totality that have the same node definition as this
one, and the other 3 briefly had the same error but upgrading from 3.4.0 to
3.4.1 resolved it. Nevertheless the resource in question is inherited by
every node so I'm at a loss what would break.
The resource is innocuous:
file { "/etc/localtime":
ensure => link,
target => "/usr/share/zoneinfo/Europe/London",
}
FWIW SELinux is disabled and if I comment this resource out it merely fails
on the next ensure => link it comes across.
Debugging offers no clues either that I can see. These manifests haven't
changed in several months and first broke on the following update (enforced
by puppet):
Dec 20 04:36:53 nodename puppet-agent[22052]:
(/Stage[main]/Puppet::Agent/Package[puppet]/ensure) ensure changed
'3.3.2-1.el6' to '0:3.4.0-1.el6'
but as I say even with the official 3.4.1 it's falling flat on its face.
Stopping the daemon, blowing away /var/lib/puppet and reassociating it with
the master and the problem still persists.
Any suggested next steps? Thoughts gratefully appreciated!
Cheers,
Steph
--
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/c34f3a38-4e02-4c1e-96e2-b5294be4fc11%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] can nodes be grouped with IP address?
Hi, On Thu, 5 Jul 2012 11:34:39 -0700 Hai Tao wrote: > instead of using hostname wildcard, is there a way to define nodes by their > IP addresses? for example, I want to put all nodes with 10.0.2.x and > 10.0.3.0 to a nodes group called "testing". how can I do this? > > thanks. Seems a bit backwards to me (you're the ones assigning the IP addresses afterall) but I don't see why you couldn't do this with a custom fact and a class that reads it. Cheers, Steph -- Steph Gosling -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: error after upgrading from 2.7.14-2puppetlabs1 to 2.7.17-1puppetlabs1
Hi, On Thu, 28 Jun 2012 10:42:43 +0200 Erik Dalén wrote: > We unfortunately still have some classes with dashes in the names but > no variables, so I want to know if it is safe to upgrade to 2.7.17? For us at least classes like this still work with .17. I should say though that these are all very simple classes (describing packages typically), most aren't even parameterized. Cheers, Steph -- Steph Gosling -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Custom facts and hyphens
Hi,
On Wed, 20 Jun 2012 15:02:43 -0700 (PDT)
Nick Fagerlund wrote:
> What R.I. said. Hyphens in variable names and class names are a no-no,
> although they kinda work in some versions of Puppet. Use underscores
> instead.
>
> (Why are hyphens a problem? Well, partly because you can subtract variables
> in expressions. The ambiguity turned out to be a problem.)
For me the workaround in this case then was just a string.gsub( '-',
'_') in the custom fact and corresponding changes in my modules. If
need be then I can always regsubst('_', '-', G) back again, though in my
case, I didn't have to.
I've not given it too much thought but I do have sympathy for argument
that divergence of (some of) Puppet's logical representations and their
labels from what's extant on the system reduces clarity and could
introduce error. I'm not talking about class names nor packages
really (there are already restrictions there for things like camelCase
IIRC) but lower down it gets more murky. Service names (i.e. init
scripts et al.) are *almost* an example as they're vendor controlled
but ultimately I can't think of a case where you'd use them as
variables.
It was because of OS idiocy that I had to follow the symlinks
for /dev/disk/by-path/xen-vbd-* in a custom fact, but I have no
control over what those files are called. Having to munge the result
of that file lookup with underscores and then call it as $::xen_vbd_2049 (or
whatever) does feel icky because it's a mental hoop to jump through:
the fact no-longer absolutely matches the name of the symlink. The more
I think about it having to do the rename in facter doesn't seem great
to me either as it seems to me it puts the logic in the wrong place.
The style guide does explicitly say to not use dashes but if hyphens in
variables are a no-no it may be worth explicitly saying so in the
Variables section of language guide, and putting it in big red letters
in the Reserved Words section so that idiots like don't miss it first time ;)
Cheers,
Steph
--
Steph Gosling
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Custom facts and hyphens
Hi all,
Possibly related to http://projects.puppetlabs.com/issues/10146 but I
wanted to get a second opinion.
I have a custom fact that iteratse through the disks on a
given EC2 node and creates facts for block devices based on
their /dev/disk/by-path/ links. I had to come up with this as a
work-around for an existing RH bug in which a kernel upgrade can
magically move block device names and terminally break an awful lot.
Anyway, the fact is simple, produces output like this:
xen-vbd-2049 => /dev/xvda1
xen-vbd-2050 => /dev/xvda2
xen-vbd-2051 => /dev/xvda3
Those facts in conjunction with a virtual resource like this:
@disks::virtual::setlabel { "root":
devicename => "$::xen-vbd-2049",
devicelabel=> "root",
}
lets me work around the problem on first run regardless whether that
block device is called /dev/xvda1, /dev/xvdf1, /dev/foobarbaz1 or whatever
after a reboot.
Anyway, this worked certainly in Puppet <= 2.7.14 but now breaks in .16
and .17. It does appear to be variable related as the exec that is
called by the realize is this:
debug: Exec[e2label -vbd-2049 root](provider=posix): Executing check 'test -e
-vbd-2049'
so clearly the variable isn't being treated correctly. I tried $::
{xen-vbd-2049} but no dice there.
Are hyphens now officially bad practice? I have a nagging half-memory
that I read that they're not good in facts, indeed all of the normal
facts are underscore'd but I can't remember where I read it.
Any thoughts or comments would be appreciated!
Cheers,
Steph
--
Steph Gosling
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Anyone seeing odd agent behaviour with 2.7.10?
Is the puppet agent daemon running when you run the agent by hand? On Thu, 26 Jan 2012 13:07:16 + (GMT) "R.I.Pienaar" wrote: > On a fresh 2.7.10 install with official RPMs on CentOS 6.2 I can't reproduce > this: > > [root@dev1]# puppet agent --onetime --verbose --no-daemonize > info: Caching catalog for dev1.devco.net > info: Applying configuration version '1327583153' > notice: Finished catalog run in 0.28 seconds > [root@dev1]# > > and if i run it without the --no-daemonize it creates its pid and removes > it when its done - didnt do that before > > > > - Original Message - > > Looks like the code paths in Puppet::Agent changed a lot and the > > patch > > that was applied and worked for 2.6.x would need to be different for > > 2.7.x > > > > Will set up a 2.7 master and see if i can reproduce/fix > > > > - Original Message - > > > Yeah everything does work, I just really don't like seeing pink :) > > > > > > Cheers, > > > > > > Steph > > > > > > On Thu, 26 Jan 2012 12:26:14 + > > > Jonathan Gazeley wrote: > > > > > > > I am seeing the same message printed on each run, on CentOS 6.2. > > > > Puppet > > > > still works, so it's not critical. Just waiting for a fix :) > > > > > > > > Jonathan > > > > > > > > > > > > On 26/01/12 12:00, Steph Gosling wrote: > > > > > Hi all, > > > > > > > > > > Upgraded a master and a couple of clients to 2.7.10 and now see > > > > > the > > > > > following when running an agent if the daemon is also running: > > > > > > > > > > [steph@somehost ~]$ sudo puppet agent --onetime --verbose > > > > > --no-daemonize > > > > > info: Caching catalog for somehost.example.com > > > > > info: Applying configuration version '1327578407' > > > > > notice: /Stage[main]/Mysql-server/Package[mysql-server]/ensure: > > > > > created > > > > > notice: /Stage[main]/Mysql-server/Service[mysqld]/ensure: > > > > > ensure > > > > > changed 'stopped' to 'running' > > > > > notice: Finished catalog run in 20.11 seconds > > > > > err: Could not remove PID file /var/run/puppet/agent.pid > > > > > [steph@somehost ~]$ > > > > > > > > > > I see that 2.7.10 fixed a bug > > > > > http://projects.puppetlabs.com/issues/5246 and wonder if > > > > > they're > > > > > related? > > > > > > > > > > in 2.7.9 this would run without throwing the error, indeed in > > > > > .10 > > > > > the > > > > > onetime run completes and the agent daemon is happy too: It's > > > > > just > > > > > unnerving to see pink messages :) Environment is CentOS > > > > > 6.2 fwiw. > > > > > > > > > > > > > > > > > > > > > > > -- > > > > You received this message because you are subscribed to the > > > > Google > > > > Groups "Puppet Users" group. > > > > To post to this group, send email to > > > > puppet-users@googlegroups.com. > > > > To unsubscribe from this group, send email to > > > > puppet-users+unsubscr...@googlegroups.com. > > > > For more options, visit this group at > > > > http://groups.google.com/group/puppet-users?hl=en. > > > > > > > > > > > > > -- > > > Steph Gosling > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Puppet Users" group. > > > To post to this group, send email to puppet-users@googlegroups.com. > > > To unsubscribe from this group, send email to > > > puppet-users+unsubscr...@googlegroups.com. > > > For more options, visit this group at > > > http://groups.google.com/group/puppet-users?hl=en. > > > > > > > > > > -- > > R.I.Pienaar > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Puppet Users" group. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscr...@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/puppet-users?hl=en. > > > > > > -- > R.I.Pienaar > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- Steph Gosling -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Anyone seeing odd agent behaviour with 2.7.10?
Yeah everything does work, I just really don't like seeing pink :) Cheers, Steph On Thu, 26 Jan 2012 12:26:14 + Jonathan Gazeley wrote: > I am seeing the same message printed on each run, on CentOS 6.2. Puppet > still works, so it's not critical. Just waiting for a fix :) > > Jonathan > > > On 26/01/12 12:00, Steph Gosling wrote: > > Hi all, > > > > Upgraded a master and a couple of clients to 2.7.10 and now see the > > following when running an agent if the daemon is also running: > > > > [steph@somehost ~]$ sudo puppet agent --onetime --verbose --no-daemonize > > info: Caching catalog for somehost.example.com > > info: Applying configuration version '1327578407' > > notice: /Stage[main]/Mysql-server/Package[mysql-server]/ensure: created > > notice: /Stage[main]/Mysql-server/Service[mysqld]/ensure: ensure changed > > 'stopped' to 'running' > > notice: Finished catalog run in 20.11 seconds > > err: Could not remove PID file /var/run/puppet/agent.pid > > [steph@somehost ~]$ > > > > I see that 2.7.10 fixed a bug > > http://projects.puppetlabs.com/issues/5246 and wonder if they're > > related? > > > > in 2.7.9 this would run without throwing the error, indeed in .10 the > > onetime run completes and the agent daemon is happy too: It's just > > unnerving to see pink messages :) Environment is CentOS > > 6.2 fwiw. > > > > > > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- Steph Gosling -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Anyone seeing odd agent behaviour with 2.7.10?
Hi all, Upgraded a master and a couple of clients to 2.7.10 and now see the following when running an agent if the daemon is also running: [steph@somehost ~]$ sudo puppet agent --onetime --verbose --no-daemonize info: Caching catalog for somehost.example.com info: Applying configuration version '1327578407' notice: /Stage[main]/Mysql-server/Package[mysql-server]/ensure: created notice: /Stage[main]/Mysql-server/Service[mysqld]/ensure: ensure changed 'stopped' to 'running' notice: Finished catalog run in 20.11 seconds err: Could not remove PID file /var/run/puppet/agent.pid [steph@somehost ~]$ I see that 2.7.10 fixed a bug http://projects.puppetlabs.com/issues/5246 and wonder if they're related? in 2.7.9 this would run without throwing the error, indeed in .10 the onetime run completes and the agent daemon is happy too: It's just unnerving to see pink messages :) Environment is CentOS 6.2 fwiw. -- Steph Gosling -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Another hostnames best-practice question
Hi all,
In the process of converting a largish installation (around 150 hosts,
mixed cloud and physical) to Puppet and I have a question about how
folks manage hostnames.
The TL; DR version:
On first run, I can't use $hostname from facter as it's 'wrong'; for
things like doing host { $certname: ...} that's fine as it gets
corrected but for other things it's not. What's the best way to
have a client set it's hostname correctly, first time?
The long version:
My plan has been to base all node names on $certname as provided on
the clients by puppet.conf. Ideally, puppet will manage everything
beyond initially being told where the puppetmaster is, then it's just
cert, sign, let the agent do it's thing and life is all good.
Some of our configurations rely on having the short hostname explicitly
specified on the client and I initially was setting this via $hostname
from facter. These are RH style boxes so I'm
setting /etc/sysconfig/network via a template, /etc/hosts via the host
resource and the hostname in the kernel either by hostname(1) or
echo'ing to /proc/sys/kernel/hostname.
That's all well and good but facter runs before the first puppet run so
even if I set the FQDN everywhere $hostname is still the original one
at boot. For most things this is OK as puppet corrects them on the
second run but other things then end up with obsoleted names kicking
around or incorrect configs for the length of the run interval.
How is everyone else managing this? as so far I can't think of
an elegant solution:
* Set the hostname by hand/whatever sets certname in puppet.conf (seems
ugly to me and potentially error-prone)
* split() $certname and use $certname[0] (seems like a kludge, and I
think also will have scoping issues)
* Create a custom fact that basically does the split() on the client?
* Would stages help? is there anyway to force facter to re-evaluate its
variables (overriding them also seems kludgey)?
Is there anything else I've missed? how do you all manage it? I've seen
folks talking about Kickstart/Cobbler but that's not going to work for
my environment.
Thoughts, pointer and discussion welcome.
--
Steph Gosling
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
