Re: [Puppet Users] Hostname fact doesn't handle hostnames with periods
I think you missed the point I was trying to convey. Anyway you want to try to flip it, you are still going against the grain with using a period in the hostname. Even libc it states what a hostname is and what a fqdn is, see below. So if libc defines a hostname like below, then facter will be the least of your issues down the road. In DNS, the full host name is properly called the FQDN (Fully Qualified Domain Name) and consists of the hostname, then a period, then the domain name. The domain name itself usually has multiple components separated by periods. So for example, a system's hostname may be ‘chicken’ and its domain name might be ‘ai.mit.edu’, so its FQDN (which is its host name) is ‘chicken.ai.mit.edu’. http://www.gnu.org/s/hello/manual/libc/Host-Identification.html On Oct 3, 2011, at 6:59 PM, Doug Balmer wrote: > about. In fact, I think if you were to use periods it would confuse > DNS resolve because it follows the same convention as stated in the > RFC. If I were external trying to look up host.server.domain.com, my > DNS would try to look for a nameserver for server.domain.com. You > would still be forced to use a new zone file for server.domain.com. > > man resolv.conf > See options ndots > > If I have a host with FQDN foo.bar.example.com and I have "options > ndots:2\nsearch example.com" in /etc/resolv.conf then I can resolve "foo.bar". > > -- > 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. -- 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] Hostname fact doesn't handle hostnames with periods
Hi Matthew, So just to be clear - I don't think we'll want to change the 'hostname' fact from its current behaviour. I think this is agreed from all angles. So the special case here that Doug is describing is when someone uses a shorter name as the hostname on a box. For example 'mybox.mylocation' and the domain name has the trailing part 'mydomain.com'. What I'm really curious about and need help understanding ... is to find out who else is doing this on the list to figure out the value of adding handling for this case. ken. On Wed, Oct 5, 2011 at 8:54 AM, Matthew Black wrote: > If facter switched to using uname on unix/linux, it would be a problem. If I > type uname -n it will spit out the fqdn to me. If I type hostname -s, it > gives me the short, the actual hostname. I don't think a switch like that > will solve the original issue provided. > > On Oct 4, 2011, at 6:20 AM, Ken Barber wrote: > >> So again quoting Dexter (who should really be participating in this >> discussion himself :-P). Perhaps a more POSIX purist set of facts >> based around the posix/opengroup standards would be desirable: >> >> http://pubs.opengroup.org/onlinepubs/009604599/basedefs/sys/utsname.h.html >> http://pubs.opengroup.org/onlinepubs/009695399/utilities/uname.html >> >> For example ... >> >> uname_nodename: is uname -n only and isn't contrived >> uname_release: is uname -r >> uname_version: is uname -v >> ...etc... >> >> This duplicates a lot of facts in behaviour - but sticks to the posix >> compliance interpretation only. I'm not 100% on weither this is the >> correct approach but the idea sounds sane enough - the question is >> really if it is core worthy or not. If this is implemented how many >> people would prefer or use this directly (besides Doug of course - who >> has made his sentiments clear :-P)? >> >> My main concern here is that this implementation is not truly >> cross-platform - only POSIX specific (which is pretty good coverage >> anyway - but not complete). The point and vision of facter (and most >> puppet resources) is to provide cross-os compatibility where possible >> if anything providing a later that binds POSIX and other non-posix OS >> to one type of data ... so I see these facts as binding puppet content >> to POSIX only machines. So while the interface may be there ... we >> would want to be careful to avoid using it directly in cross-os >> resources and puppet code. Having said that, this would not be the >> first time we have had to provide OS specific facts :-). >> >> IMO - If implemented I can envision providing this interface and on >> POSIX machines just using these facts to glean things like >> 'kernelversion' on compatible machines instead of duplicating the >> uname -v call again. >> >> ken. >> >> On Mon, Oct 3, 2011 at 11:59 PM, Doug Balmer wrote: about. In fact, I think if you were to use periods it would confuse DNS resolve because it follows the same convention as stated in the RFC. If I were external trying to look up host.server.domain.com, my DNS would try to look for a nameserver for server.domain.com. You would still be forced to use a new zone file for server.domain.com. >>> >>> man resolv.conf >>> See options ndots >>> If I have a host with FQDN foo.bar.example.com and I have "options >>> ndots:2\nsearch example.com" in /etc/resolv.conf then I can resolve >>> "foo.bar". >>> >>> -- >>> 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. >>> >> >> -- >> 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. >> > > -- > 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. > > -- 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] Re: How best to monitor puppet?
On Oct 5, 4:36 am, Scott Smith wrote: > It doesn't matter if puppetmasterd or puppetd are running and working if > your clients are failing catalog runs. > > Send reports, write a check that alerts on N hosts with failed reports over > X timeframe or something. I favor monitoring each node rather than try to figure out if the master works or not as this is ultimately the outcome you care for - can my nodes do puppet runs. Puppet now saves its last run status in the libdir: /var/lib/puppet/state/last_run_summary.yaml: --- time: group: 0.001692 last_run: 1317804488 class: 0.003929 yumrepo: 0.020103 service: 9.017434 schedule: 0.004151 cron: 0.010546 config_retrieval: 15.0572321414948 total: 34.9742621414947 package: 0.588751 filebucket: 0.000687 file: 8.895422 exec: 1.361625 user: 0.01269 resources: total: 414 events: total: 0 changes: total: 0 I wrote a nagios check to check this and report on any problems: When last did puppet run: # check_puppet.rb -c 3600 -w 1800 OK: Puppet is currently enabled, last run 712 seconds ago with 0 failures how many resources failed: # check_puppet.rb -c 5 -w 2 --check-failures OK: Puppet is currently enabled, last run 742 seconds ago with 0 failures and you can also add --only-enabled to have machines undergoing maintenance not show up as critical. I run this under nrpe etc. The last run summary yaml file is a bit odd in that it doesn't always contain all the information for instance a syntax error in catalogs will have it only include 1 piece of data and other differences during execution, hopefully this will improve in time (I should probably file tickets) The code for the check is @ https://github.com/ripienaar/monitoring-scripts/blob/master/puppet/check_puppet.rb and it is compatible with all the current odd behaviors of the file as of 2.6.9 -- 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] Re: facter variables empty
hmm.. I'm new too puppet and I don't understand "compile the manifest
for the node".
I write my manifests on the puppetmaster node.
And I test on the client node with :
puppetd --test --debug --trace
there is no error in the debug trace :
debug: [.. many auotorequiring File[/var/puppet/... ]
info: Caching catalog for puppetmaster.domain.fr
debug: Creating default schedules
debug: Loaded state in 0.00 seconds
info: Applying configuration version '1317710581'
debug: /Schedule[never]: Skipping device resources because running on
a host
...
debug: /Stage[main]/Resolver/File[resolv.conf]/content: Executing
'diff -u /etc/resolv.conf /tmp/puppet-file20111005-54594-14mbicj-0'
--- /etc/resolv.conf2011-10-05 13:36:43.866046102 +0200
+++ /tmp/puppet-file20111005-54594-14mbicj-02011-10-05
13:37:01.470405023 +0200
@@ -1,3 +1,3 @@
-domain mydomain.fr
+domain
nameserver 1.1.1.1
nameserver 2.2.2.2
debug: Finishing transaction 17215353320
info: FileBucket got a duplicate file {md5}
84490558380d7e3f5e2475700843ced1
info: /Stage[main]/Resolver/File[resolv.conf]: Filebucketed /etc/
resolv.conf to puppet with sum 84490558380d7e3f5e2475700843ced1
notice: /Stage[main]/Resolver/File[resolv.conf]/content: content
changed '{md5}84490558380d7e3f5e2475700843ced1' to '{md5}
8f6a1d5e20142e3b879651ecaf67d91a'
debug: /Stage[main]/Resolver/File[resolv.conf]: The container
resolv.conf will propagate my refresh event
debug: resolv.conf: The container Class[Resolver] will propagate my
refresh event
debug: Class[Resolver]: The container Stage[main] will propagate my
refresh event
debug: Finishing transaction 17215842100
debug: Storing state
debug: Stored state in 0.01 seconds
notice: Finished catalog run in 0.14 seconds
debug: Value of 'preferred_serialization_format' (pson) is invalid for
report, using default (b64_zlib_yaml)
debug: report supports formats: b64_zlib_yaml marshal raw yaml; using
b64_zlib_yaml
debug: Using cached certificate for ca
debug: Using cached certificate for puppetmaster.mydomain.fr
debug: Using cached certificate_revocation_list for ca
But, I know, with the new generated resolv.conf, that facter variables
like $domain an $ipadresse6 are empty.
puppet --version : 2.7.3
facter --version : 1.6.0
client node, puppet.conf :
[main]
server=puppetmaster.mydomain.fr
pluginsync=false
master node, puppet.conf is empty because all default variable are
good
OS: FreeBSD 8.2
puppet + mongrel + nginx
--
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] Opsview puppet module - purging hosts from opsview
Hi all,
I'm using the opsview module and the Opsviewmonitored type and it's working
just fine, I'm now trying to purge unused hosts from the Opsview monitoring
(I have several hosts that dynamically go up and down). The problem is that
it seems like the destroy function for opsview was not really implemented
and therefore I can't really delete hosts from there..
For example:
# puppet apply -e "opsviewmonitored{ 'icap15': ensure => absent }"
err: /Stage[main]//Opsviewmonitored[icap15]/ensure: change from present to
absent failed: Could not set 'absent on ensure: undefined method `destroy'
for # at line 1
Did anybody ever dealt with purging Opsviewmonitored hosts? Maybe there is
an implementation of this somewhere? I couldn't find one on the net and I
wanted to know if anybody has done it before I'm writing one myself...
Thanks,
Galed.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/g_nw7i12Y4QJ.
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] Re: Hostname fact doesn't handle hostnames with periods
Hi Ken,
I've posted earlier using "easybeats". This is me "Dex".
I've been reading C source code, plus RHEL documentation to shed some
more light
If you run the hostname command with an invalid character, IE...
hostname invalid\#hostname
hostname: the specified hostname is invalid
It filters out what it believes to be invalid characters and prints a
warning but sets the hostname. Looking at the source code for the
"hostname" command (which is the entry point for setting the systems
hostname) for Debian, it filters out for alphanumeric, dash (-) and
period (.). At the top there is a comment stating it uses the rules
from RFC 1034 http://tools.ietf.org/html/rfc1034. (See snippet below)
To mean this means that at least for Linux Systems the period (.) is
allowed when setting the hostname of the box . IE entries
configuration files use the "hostname" command to set the name of the
system.
/etc/hostname - (Debian)
/etc/sysconfig/networking - (Red Hat)
Heres the clincher for me, having looked at Red Hats documentation, it
was intended "hostname" either the short form (to the first period) or
the fqdn (both of which is allowed as the hostname).
from
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/sn-Netconfig-x86.html
"Setup prompts you to supply a host name for this computer, either as
a fully-qualified domain name (FQDN) in the format hostname.domainname
or as a short host name in the format hostname.", notice the period at
the end.
So my conclusions
1. hostname on Linux was intended as either the FQDN or SHORT FORM (To
first period). Periods are allowed in Linux hostname
2. While the hostname fact does not reflect the actual hostname value
as held in the Linux kernel (which can contain periods), it does
present the correct intepretation of RFC 952.
So the "hostname" and "fqdn" facts are strict and correct
interpretations of RFC 952, however as stated in a previous post I
still maintain that facter should represent the hostname (using a
different fact) held as a Linux Kernel C struct value "sysctl -n
kernel.hostname" even if it is only part of the fqdn, The example I
used was SMTP servers enabling/disabling filtering based on strict RFC
interpretations, also the hostname command in Debian doesn't restrict
setting of invalid hostnames but warns the user.
-Dex
-snippet from the hostname command-
/*
* Check the format of a user-specified hostname. Uses the rules from
RFC 1035,
* section 2.3.1.
*/
int
check_name(char *name)
{
int i, len = strlen(name);
/* Handle leading and trailing hyphen now. */
if (!len || !isalnum(name[0]) || !isalnum(name[len-1]))
return 0;
for (i = 0; i < len; i++) {
if (!isalnum(name[i]) && name[i] != '-' && name[i] !=
'.')
return 0;
if (name[i] == '-' && (name[i - 1] == '.' || name[i +
1] == '.'))
return 0;
if (name[i] == '.' && name[i - 1] == '.')
return 0;
}
return 1;
}
--
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] "Could not find a default provider for ..." should not fail the agent run?
Hi all,
I have repeatedly encountered the problem that I would like Puppet to install a
particular piece of software, for example git, and then use a provider like
https://github.com/puppetlabs/puppet-vcsrepo to check out a repository.
This fails with a message like "Could not run Puppet configuration client:
Could not find a default provider for ..." unless the tool (git, to stick with
my example) is already installed. This chicken and egg problem applies to some
other install-stuff-and-do-more-stuff-with-it situations as well.
I understand that it would be way too complicated for puppet to be able to
handle all this in a single run. But isn't failing due to the lack of a
particular (default) provider too hard?
If Puppet would carry on and just fail on the vcsrepo {} (or whatever type of
resource), things would probably sort out after two or three agent runs.
In IRC they pointed me to either using environments, which I think is too
complicated (having to maintain "bootstrap" and "production" manifests).
Another tip was to have a look at the way the pip package provider
(https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/package/pip.rb)
works, see lazy_pip at the end. But to me it seems as if that would be out of
line with the rest of providers and working against the API provided by Puppet.
Suggestions?
-mp.
--
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] Re: "Could not find a default provider for ..." should not fail the agent run?
Matthias,
I had a similar problem recently with libvirt Ruby bindings being
required for a provider. Due to a few other requirements I opted for
creating a "second pass" approach by using a custom fact to describe
whether my provider was "ready to be used" on a node and wrap my
resources in a conditional based on this fact. The fact tests certain
files exist which are installed by packages managed in other Puppet
modules. It's pretty hacky but I didn't have time to invest in a nicer
solution such as handling the error inside the provider.
-Luke
On Oct 5, 3:25 pm, Matthias Pigulla wrote:
> Hi all,
>
> I have repeatedly encountered the problem that I would like Puppet to install
> a particular piece of software, for example git, and then use a provider
> likehttps://github.com/puppetlabs/puppet-vcsrepoto check out a repository.
>
> This fails with a message like "Could not run Puppet configuration client:
> Could not find a default provider for ..." unless the tool (git, to stick
> with my example) is already installed. This chicken and egg problem applies
> to some other install-stuff-and-do-more-stuff-with-it situations as well.
>
> I understand that it would be way too complicated for puppet to be able to
> handle all this in a single run. But isn't failing due to the lack of a
> particular (default) provider too hard?
>
> If Puppet would carry on and just fail on the vcsrepo {} (or whatever type of
> resource), things would probably sort out after two or three agent runs.
>
> In IRC they pointed me to either using environments, which I think is too
> complicated (having to maintain "bootstrap" and "production" manifests).
>
> Another tip was to have a look at the way the pip package provider
> (https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/...)
> works, see lazy_pip at the end. But to me it seems as if that would be out of
> line with the rest of providers and working against the API provided by
> Puppet.
>
> Suggestions?
>
> -mp.
--
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: "Could not find a default provider for ..." should not fail the agent run?
Without waving my ignorance around too much... does Matthias' issue fit run
stages? This sounds like exactly what they were designed to solve: ensure
certain things definitely happen before certain other things.
On Wed, Oct 05, 2011 at 07:33:29AM -0700, Luke Bigum wrote:
> Matthias,
>
> I had a similar problem recently with libvirt Ruby bindings being
> required for a provider. Due to a few other requirements I opted for
> creating a "second pass" approach by using a custom fact to describe
> whether my provider was "ready to be used" on a node and wrap my
> resources in a conditional based on this fact. The fact tests certain
> files exist which are installed by packages managed in other Puppet
> modules. It's pretty hacky but I didn't have time to invest in a nicer
> solution such as handling the error inside the provider.
>
> -Luke
>
> On Oct 5, 3:25 pm, Matthias Pigulla wrote:
> > Hi all,
> >
> > I have repeatedly encountered the problem that I would like Puppet to
> > install a particular piece of software, for example git, and then use a
> > provider likehttps://github.com/puppetlabs/puppet-vcsrepoto check out a
> > repository.
> >
> > This fails with a message like "Could not run Puppet configuration client:
> > Could not find a default provider for ..." unless the tool (git, to stick
> > with my example) is already installed. This chicken and egg problem applies
> > to some other install-stuff-and-do-more-stuff-with-it situations as well.
> >
> > I understand that it would be way too complicated for puppet to be able to
> > handle all this in a single run. But isn't failing due to the lack of a
> > particular (default) provider too hard?
> >
> > If Puppet would carry on and just fail on the vcsrepo {} (or whatever type
> > of resource), things would probably sort out after two or three agent runs.
> >
> > In IRC they pointed me to either using environments, which I think is too
> > complicated (having to maintain "bootstrap" and "production" manifests).
> >
> > Another tip was to have a look at the way the pip package provider
> > (https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/...)
> > works, see lazy_pip at the end. But to me it seems as if that would be out
> > of line with the rest of providers and working against the API provided by
> > Puppet.
> >
> > Suggestions?
> >
> > -mp.
>
> --
> 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.
>
>
--
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] Re: "Could not find a default provider for ..." should not fail the agent run?
Not exactly. If we could both get our resources to fail individually
(like a File's "source" parameter not existing and throwing an error
for that resource) it would work, but because we're using custom
types, the Puppet agent loads all those in (and Facts) and dies before
it gets to it's catalog, so run levels won't help. It's the same error
as if you went to use a native Augeas resource and didn't have the
Augeas Ruby bindings installed.
On Oct 5, 3:36 pm, Christopher Wood
wrote:
> Without waving my ignorance around too much... does Matthias' issue fit run
> stages? This sounds like exactly what they were designed to solve: ensure
> certain things definitely happen before certain other things.
>
>
>
>
>
>
>
> On Wed, Oct 05, 2011 at 07:33:29AM -0700, Luke Bigum wrote:
> > Matthias,
>
> > I had a similar problem recently with libvirt Ruby bindings being
> > required for a provider. Due to a few other requirements I opted for
> > creating a "second pass" approach by using a custom fact to describe
> > whether my provider was "ready to be used" on a node and wrap my
> > resources in a conditional based on this fact. The fact tests certain
> > files exist which are installed by packages managed in other Puppet
> > modules. It's pretty hacky but I didn't have time to invest in a nicer
> > solution such as handling the error inside the provider.
>
> > -Luke
>
> > On Oct 5, 3:25 pm, Matthias Pigulla wrote:
> > > Hi all,
>
> > > I have repeatedly encountered the problem that I would like Puppet to
> > > install a particular piece of software, for example git, and then use a
> > > provider likehttps://github.com/puppetlabs/puppet-vcsrepotocheck out a
> > > repository.
>
> > > This fails with a message like "Could not run Puppet configuration
> > > client: Could not find a default provider for ..." unless the tool (git,
> > > to stick with my example) is already installed. This chicken and egg
> > > problem applies to some other install-stuff-and-do-more-stuff-with-it
> > > situations as well.
>
> > > I understand that it would be way too complicated for puppet to be able
> > > to handle all this in a single run. But isn't failing due to the lack of
> > > a particular (default) provider too hard?
>
> > > If Puppet would carry on and just fail on the vcsrepo {} (or whatever
> > > type of resource), things would probably sort out after two or three
> > > agent runs.
>
> > > In IRC they pointed me to either using environments, which I think is too
> > > complicated (having to maintain "bootstrap" and "production" manifests).
>
> > > Another tip was to have a look at the way the pip package provider
> > > (https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/...)
> > > works, see lazy_pip at the end. But to me it seems as if that would be
> > > out of line with the rest of providers and working against the API
> > > provided by Puppet.
>
> > > Suggestions?
>
> > > -mp.
>
> > --
> > 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
> > athttp://groups.google.com/group/puppet-users?hl=en.
--
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] Re: "Could not find a default provider for ..." should not fail the agent run?
My explanation's not the best so went looking to see if the Internals
wiki page specifically mentions what I'm talking about, I'm pretty
sure the problem is in the Parsing phase:
http://docs.puppetlabs.com/guides/puppet_internals.html
On Oct 5, 3:42 pm, Luke Bigum wrote:
> Not exactly. If we could both get our resources to fail individually
> (like a File's "source" parameter not existing and throwing an error
> for that resource) it would work, but because we're using custom
> types, the Puppet agent loads all those in (and Facts) and dies before
> it gets to it's catalog, so run levels won't help. It's the same error
> as if you went to use a native Augeas resource and didn't have the
> Augeas Ruby bindings installed.
>
> On Oct 5, 3:36 pm, Christopher Wood
> wrote:
>
>
>
>
>
>
>
> > Without waving my ignorance around too much... does Matthias' issue fit run
> > stages? This sounds like exactly what they were designed to solve: ensure
> > certain things definitely happen before certain other things.
>
> > On Wed, Oct 05, 2011 at 07:33:29AM -0700, Luke Bigum wrote:
> > > Matthias,
>
> > > I had a similar problem recently with libvirt Ruby bindings being
> > > required for a provider. Due to a few other requirements I opted for
> > > creating a "second pass" approach by using a custom fact to describe
> > > whether my provider was "ready to be used" on a node and wrap my
> > > resources in a conditional based on this fact. The fact tests certain
> > > files exist which are installed by packages managed in other Puppet
> > > modules. It's pretty hacky but I didn't have time to invest in a nicer
> > > solution such as handling the error inside the provider.
>
> > > -Luke
>
> > > On Oct 5, 3:25 pm, Matthias Pigulla wrote:
> > > > Hi all,
>
> > > > I have repeatedly encountered the problem that I would like Puppet to
> > > > install a particular piece of software, for example git, and then use a
> > > > provider likehttps://github.com/puppetlabs/puppet-vcsrepotocheckout a
> > > > repository.
>
> > > > This fails with a message like "Could not run Puppet configuration
> > > > client: Could not find a default provider for ..." unless the tool
> > > > (git, to stick with my example) is already installed. This chicken and
> > > > egg problem applies to some other
> > > > install-stuff-and-do-more-stuff-with-it situations as well.
>
> > > > I understand that it would be way too complicated for puppet to be able
> > > > to handle all this in a single run. But isn't failing due to the lack
> > > > of a particular (default) provider too hard?
>
> > > > If Puppet would carry on and just fail on the vcsrepo {} (or whatever
> > > > type of resource), things would probably sort out after two or three
> > > > agent runs.
>
> > > > In IRC they pointed me to either using environments, which I think is
> > > > too complicated (having to maintain "bootstrap" and "production"
> > > > manifests).
>
> > > > Another tip was to have a look at the way the pip package provider
> > > > (https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/...)
> > > > works, see lazy_pip at the end. But to me it seems as if that would be
> > > > out of line with the rest of providers and working against the API
> > > > provided by Puppet.
>
> > > > Suggestions?
>
> > > > -mp.
>
> > > --
> > > 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
> > > athttp://groups.google.com/group/puppet-users?hl=en.
--
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: "Could not find a default provider for ..." should not fail the agent run?
On Wed, Oct 05, 2011 at 07:50:48AM -0700, Luke Bigum wrote:
> My explanation's not the best so went looking to see if the Internals
> wiki page specifically mentions what I'm talking about, I'm pretty
> sure the problem is in the Parsing phase:
>
> http://docs.puppetlabs.com/guides/puppet_internals.html
>
> On Oct 5, 3:42 pm, Luke Bigum wrote:
> > Not exactly. If we could both get our resources to fail individually
> > (like a File's "source" parameter not existing and throwing an error
> > for that resource) it would work, but because we're using custom
> > types, the Puppet agent loads all those in (and Facts) and dies before
> > it gets to it's catalog, so run levels won't help. It's the same error
> > as if you went to use a native Augeas resource and didn't have the
> > Augeas Ruby bindings installed.
I decidedly hadn't thought this through -- custom types/facts aren't part of
the catalog, and run stages are only for catalog items. I certainly appreciate
the explanation!
> > On Oct 5, 3:36 pm, Christopher Wood
> > wrote:
> >
> >
> >
> >
> >
> >
> >
> > > Without waving my ignorance around too much... does Matthias' issue fit
> > > run stages? This sounds like exactly what they were designed to solve:
> > > ensure certain things definitely happen before certain other things.
> >
> > > On Wed, Oct 05, 2011 at 07:33:29AM -0700, Luke Bigum wrote:
> > > > Matthias,
> >
> > > > I had a similar problem recently with libvirt Ruby bindings being
> > > > required for a provider. Due to a few other requirements I opted for
> > > > creating a "second pass" approach by using a custom fact to describe
> > > > whether my provider was "ready to be used" on a node and wrap my
> > > > resources in a conditional based on this fact. The fact tests certain
> > > > files exist which are installed by packages managed in other Puppet
> > > > modules. It's pretty hacky but I didn't have time to invest in a nicer
> > > > solution such as handling the error inside the provider.
> >
> > > > -Luke
> >
> > > > On Oct 5, 3:25 pm, Matthias Pigulla wrote:
> > > > > Hi all,
> >
> > > > > I have repeatedly encountered the problem that I would like Puppet to
> > > > > install a particular piece of software, for example git, and then use
> > > > > a provider likehttps://github.com/puppetlabs/puppet-vcsrepotocheckout
> > > > > a repository.
> >
> > > > > This fails with a message like "Could not run Puppet configuration
> > > > > client: Could not find a default provider for ..." unless the tool
> > > > > (git, to stick with my example) is already installed. This chicken
> > > > > and egg problem applies to some other
> > > > > install-stuff-and-do-more-stuff-with-it situations as well.
> >
> > > > > I understand that it would be way too complicated for puppet to be
> > > > > able to handle all this in a single run. But isn't failing due to the
> > > > > lack of a particular (default) provider too hard?
> >
> > > > > If Puppet would carry on and just fail on the vcsrepo {} (or whatever
> > > > > type of resource), things would probably sort out after two or three
> > > > > agent runs.
> >
> > > > > In IRC they pointed me to either using environments, which I think is
> > > > > too complicated (having to maintain "bootstrap" and "production"
> > > > > manifests).
> >
> > > > > Another tip was to have a look at the way the pip package provider
> > > > > (https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/...)
> > > > > works, see lazy_pip at the end. But to me it seems as if that would
> > > > > be out of line with the rest of providers and working against the API
> > > > > provided by Puppet.
> >
> > > > > Suggestions?
> >
> > > > > -mp.
> >
> > > > --
> > > > 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
> > > > athttp://groups.google.com/group/puppet-users?hl=en.
>
> --
> 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.
>
>
--
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] Concat::Fragment collection broken in 2.7.5
Almost a "me-too" post, I should try to avoid that... This sounds like the mail I sent on Monday - I can certainly confirm Bruno's findings for collecting exported custom defines. I get the same error message, and I'm also using a remote MySQL database (no queueing agent, just direct access). I'd love to help with the debugging but I'm on a training course this week, and the connection is waaay too slow for database debugging. If you've not solved it by Monday, I'll dive in and provide some debug logs and db traces. Watching this thread with interest :) Greg -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/1mwaNRX2OX0J. 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] "Could not find a default provider for ..." should not fail the agent run?
On Oct 5, 2011, at 7:25 AM, Matthias Pigulla wrote:
> Hi all,
>
> I have repeatedly encountered the problem that I would like Puppet to install
> a particular piece of software, for example git, and then use a provider like
> https://github.com/puppetlabs/puppet-vcsrepo to check out a repository.
>
> This fails with a message like "Could not run Puppet configuration client:
> Could not find a default provider for ..." unless the tool (git, to stick
> with my example) is already installed. This chicken and egg problem applies
> to some other install-stuff-and-do-more-stuff-with-it situations as well.
>
> I understand that it would be way too complicated for puppet to be able to
> handle all this in a single run. But isn't failing due to the lack of a
> particular (default) provider too hard?
>
> If Puppet would carry on and just fail on the vcsrepo {} (or whatever type of
> resource), things would probably sort out after two or three agent runs.
>
> In IRC they pointed me to either using environments, which I think is too
> complicated (having to maintain "bootstrap" and "production" manifests).
>
> Another tip was to have a look at the way the pip package provider
> (https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/package/pip.rb)
> works, see lazy_pip at the end. But to me it seems as if that would be out
> of line with the rest of providers and working against the API provided by
> Puppet.
>
> Suggestions?
I suspect that I must be missing something here but it seems rather obvious to
me that in this specific example...
require => Package["git"]
would mean that git is installed first and then it should just work.
As for 'fail' and continue on, that's clearly not the puppet way and any
tolerance of failures seems inappropriate on just about any level.
Craig
--
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] Re: Design Goals of Puppet
On Oct 4, 2:13 am, brighton marekera wrote: > Hi everyone. I am Looking for a any information on the Design goals of > Puppet and its History from its inception,i have been looking around > the internet and i cant seem to find good info on tht When I think of design goals for open source projects I always first check if there is a chapter in The Architecture of Open Source Applications by Amy Brown and Greg Wilson. In this case, it looks like there is a chapter on Puppet coming in Volume 2: "2011-06-14: We've added chapters on PostgreSQL (written by Selena Deckelmann) and Puppet (written by Luke Kanies, Nigel Kersten, and James Turnbull) to Volume 2." -- http://www.aosabook.org/en/index.html#news Phil p.s. There's a great discussion with Greg Wilson about this book at http://blog.stackoverflow.com/2011/06/se-podcast-09/ -- 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] Re: problem with generate function in template
> It sounds like your running into Bug
> #4549:http://projects.puppetlabs.com/issues/4549
>
Thanks for the tip.
For a work around it looks like I can do the following in the
template where generate is called (or any other function)
<% Puppet::Parser::Functions.function('generate') -%>
genvar=<%= scope.function_generate(["/var/tmp/gen-test/gencom"]) %>
Or set a variable in the manifest via generate and then just refer
to it in the template
gen.pp:
$var = generate('/var/tmp/gen-test/gencom')
file { "/var/tmp/gen-test/genout":
content => template("/var/tmp/gen-test/templ.erb"),
}
templ.erb:
genvar=<%= var %>
> There is a workaround given in the comments.
>
> --
> Peter M. Bukowinski
> Sr. Systems Engineer
> Janelia Farm Research Campus, HHMI
--
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] Re: RFC: Being able to exclude resources from reporting.
My tagmail.conf contains "all, !noreport: em...@example.com," so if I want to ignore a resource I just tag it with "noreport." Of course, that only applies to tagmail reporting. -- 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] "Could not find a default provider for ..." should not fail the agent run?
On Wed, Oct 5, 2011 at 8:40 AM, Craig White wrote:
>
> On Oct 5, 2011, at 7:25 AM, Matthias Pigulla wrote:
>
>> Hi all,
>>
>> I have repeatedly encountered the problem that I would like Puppet to
>> install a particular piece of software, for example git, and then use a
>> provider like https://github.com/puppetlabs/puppet-vcsrepo to check out a
>> repository.
>>
>> This fails with a message like "Could not run Puppet configuration client:
>> Could not find a default provider for ..." unless the tool (git, to stick
>> with my example) is already installed. This chicken and egg problem applies
>> to some other install-stuff-and-do-more-stuff-with-it situations as well.
>>
>> I understand that it would be way too complicated for puppet to be able to
>> handle all this in a single run. But isn't failing due to the lack of a
>> particular (default) provider too hard?
>>
>> If Puppet would carry on and just fail on the vcsrepo {} (or whatever type
>> of resource), things would probably sort out after two or three agent runs.
>>
>> In IRC they pointed me to either using environments, which I think is too
>> complicated (having to maintain "bootstrap" and "production" manifests).
>>
>> Another tip was to have a look at the way the pip package provider
>> (https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/package/pip.rb)
>> works, see lazy_pip at the end. But to me it seems as if that would be out
>> of line with the rest of providers and working against the API provided by
>> Puppet.
>>
>> Suggestions?
>
> I suspect that I must be missing something here but it seems rather obvious
> to me that in this specific example...
>
> require => Package["git"]
>
> would mean that git is installed first and then it should just work.
You can't use a provider if it depends on a package that has yet to be
installed. At least not in a single puppet run. Here's the issue:
http://projects.puppetlabs.com/issues/6907
Thanks,
Nan
--
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] Re: "Could not find a default provider for ..." should not fail the agent run?
On Oct 5, 4:40 pm, Craig White wrote: > I suspect that I must be missing something here but it seems rather obvious > to me that in this specific example... > > require => Package["git"] That would work if Puppet was attempting to use Git (in Matthias' example) and LibVirt (in my example) during the evaluation of it's catalog, but it's not. Puppet is essentially failing with a Parse error. It's the same as trying to "include" a CPAN module in Perl when it's not installed, or link against a C library that doesn't exist. The Agent has a catalog with containing a native type of Git and there's no Git installed on the Agent. We've got providers that use underlying system functionality (Git/ LibVirt) but that functionality gets installed by Puppet - bit of a chicken and egg. Personally I don't want Git/LibVirt installed on every machine in my estate just in case my nodes might use one of these user defined types. > would mean that git is installed first and then it should just work. > > As for 'fail' and continue on, that's clearly not the puppet way and any > tolerance of failures seems inappropriate on just about any level. I agree it's not perfect, for this problem there's a number of less than perfect solutions, but failing in the catalog evaluation would at least give you a full report on the first Puppet run and simplify your manifests from strange conditional logic (like mine have at the moment). I'd be very interested in other people's approaches for user defined types based on Puppet installed prerequisites. -Luke -- 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] RFC: Being able to exclude resources from reporting.
So, my essential point is that if that file did change – and it genuinely did – we should report that back, and provide better tools to filter it on the server side. The advantage of filtering on the client rather than the server is minimal, given we compress the data transmitted, so you are talking about a few bytes of network traffic, total. Would you be equally satisfied if we allowed you to annotate that the resource was expected to change every time, and then alerted you only if it *didn't* change on a given run? (...or just never displayed that change to you?) Daniel On Tue, Oct 4, 2011 at 23:28, Matthew Black wrote: > I could see a use case for it. When generating the facts.yaml for use with > mcollective, the reports are showing always at 1 change because of that even > if I set the log level to debug. That file will always change every run > because the information stored in facter is changes with each run. > > I can't think of another use case but I'm sure there might be others. > > On Oct 4, 2011, at 1:30 PM, Daniel Pittman wrote: > >> On Tue, Oct 4, 2011 at 10:16, Nigel Kersten wrote: >> >>> As per: https://projects.puppetlabs.com/issues/7555 >>> it looks like we've got some use cases around excluding some resources from >>> being reported on to reduce noise. >> >> This feels like solving the problem on the wrong side to me. >> >>> Should we implement a metaparameter like this? Do the use cases justify >>> breaking the consistency of the model (report on everything) ? >> >> This is worse than that: it bakes in the assumption that the reports >> are *not* a graph, or that we can just discard structural elements in >> that graph, by allowing us to ditch what would otherwise be a vertex. >> >> One of the proposed enhancements to the report - which I think is >> hugely valuable - is that we return the augmented graph from the >> client side, where things like file recursion, or autorequires, can >> change the catalog we sent down. Excluding something from that may be >> a huge structural change, and it is certainly going to make >> correlation between that graph and the original catalog extremely >> difficult to discover. >> >> So, no, I do not believe we should support this. Better, I think, to >> support that feature in our reporting tools, or make it easier for >> people to build that in their tools. >> >> Daniel >> -- >> ⎋ Puppet Labs Developer – http://puppetlabs.com >> ♲ Made with 100 percent post-consumer electrons >> >> -- >> 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. >> > > -- > 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 Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- 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] RFC: Being able to exclude resources from reporting.
- Original Message - > So, my essential point is that if that file did change – and it > genuinely did – we should report that back, and provide better tools > to filter it on the server side. The advantage of filtering on the > client rather than the server is minimal, given we compress the data > transmitted, so you are talking about a few bytes of network traffic, > total. yes, the main concern isnt that it is or isnt in the report its that its being reported on, mailed out, shown as red on dashboard etc ditto for output on --test though that we can shut up generally with the loglevel meta parameter > > Would you be equally satisfied if we allowed you to annotate that the > resource was expected to change every time, and then alerted you only > if it *didn't* change on a given run? (...or just never displayed > that change to you?) I think there's a lot of files that changes frequently but not always and it would be worth excluding those so more flexibility would be useful -- 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] Deprecation notice: must now include '$' in prototype
Can some explain to me how to fix the following warning: warning: Deprecation notice: must now include '$' in prototype I am receiving in on one of my functions define config_file(owner = named, group = named, mode = 644,source, ensure = file, replace = no, source = "puppet://$servername/ configmodule/scripts" ) -- 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] Re: Opsview puppet module - purging hosts from opsview
The short answer is that this functionality has not yet been
implemented.
* If you're using the module provided by Opsview, then posting a
feature request on their forums *might* get some attention...
* If you're using the cparedes fork of the module (http://
forge.puppetlabs.com/cparedes/puppet_opsview) then submitting an issue
(or a pull request) to the github page will likely get some attention.
* If you're using the module that I posted to the Opsview forums a
while back, then you should really look at switching over to cparedes'
fork - it's much nicer.
Fwiw, implementing "ensure => absent" for the providers is something
I've been wanting to do, but I haven't had enough justification to
spend the time doing it yet.
-devon
On Oct 5, 4:48 am, Galed Friedmann wrote:
> Hi all,
>
> I'm using the opsview module and the Opsviewmonitored type and it's working
> just fine, I'm now trying to purge unused hosts from the Opsview monitoring
> (I have several hosts that dynamically go up and down). The problem is that
> it seems like the destroy function for opsview was not really implemented
> and therefore I can't really delete hosts from there..
>
> For example:
> # puppet apply -e "opsviewmonitored{ 'icap15': ensure => absent }"
> err: /Stage[main]//Opsviewmonitored[icap15]/ensure: change from present to
> absent failed: Could not set 'absent on ensure: undefined method `destroy'
> for # at line 1
>
> Did anybody ever dealt with purging Opsviewmonitored hosts? Maybe there is
> an implementation of this somewhere? I couldn't find one on the net and I
> wanted to know if anybody has done it before I'm writing one myself...
>
> Thanks,
> Galed.
--
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] Re: Problem: Puppet under Passenger.
> - Installed Puppet and Facter from the latest tarballs.
> - Installed Ruby 1.9.2 and rack/passenger gems from RVM.
If you installed puppet via tarball, and ruby/rack/passenger via RVM
it could be that puppet isn't in the RUBYLIB. You may need to edit
the config.ru to specify where puppet is - the config.ru has a
commented section with the following, which you may need to uncomment:
# if puppet is not in your RUBYLIB:
# $:.unshift('/opt/puppet/lib')
--
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] Re: Deprecation notice: must now include '$' in prototype
You just need to include a $ in front of those parameter variables: define config_file($owner = named, $group = named, ... On Oct 5, 12:19 pm, "liam.j.bennett" wrote: > Can some explain to me how to fix the following warning: > > warning: Deprecation notice: must now include '$' in prototype > > I am receiving in on one of my functions > > define config_file(owner = named, group = named, mode = 644,source, > ensure = file, replace = no, source = "puppet://$servername/ > configmodule/scripts" ) -- 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] Puppet 2.7 allows dash in variable names: bug or feature?
While testing puppet 2.7, I found that one of my manifests broke
because of the following quoted string:
"http://$yumserver/repos/vmware-$esxversion-rhel6-64";
Everything in the resulting string after "vmware-" was blank. After
some experiments I found that puppet 2.7 allows dashes in variable
names, and was interpreting "$esxversion-rhel6-64" as one big
variable. Of course adding curly braces fixes the problem, but that
seems like a significant change. Was it intended?
Results of applying a simple test manifest:
notice("Dashtest: $fqdn-is-my-hostname")
Puppet 2.6.11:
notice: Scope(Class[main]): Dashtest: foobar.example.com-is-my-
hostname
Puppet 2.7.5:
notice: Scope(Class[main]): Dashtest:
-Steve
--
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] Re: per host/node ssl key cert info
Hi Matt,
How to accomplish what you describe is going to be highly dependent on
the site's security policy, since you are dealing with sensitive
information. I didn't want to put this info in the main git repo that
controls my puppet masters, since it is available to lots of people.
What I ended up doing was setting up an additional "private" repo that
contains a directory matching each hostname that needs private data,
and setting up a private per-host mount point in puppet's
fileserver.conf:
# Define a "private" mount point unique to each host
[private]
path /etc/puppet/private/%H
allow *
Then my module manifests can contain things like:
file { '/etc/pki/tls/private/example.key':
source => 'puppet:///private/example.key'
}
This is just one way of handling this, I'd be interested in hearing
what others are doing.
-Steve
On Oct 4, 3:34 pm, Matt Zagrabelny wrote:
> Hi,
>
> Are people using puppet to store/deploy SSL key/cert info?
>
> My scenario is that I've got a bunch of nodes/hosts that are using
> Shibboleth with each host having its own SSL cert and key. I know I
> can ensure the relevant packages are installed and that the configs
> are consistent across said nodes, but I don't know:
>
> A) If people are using puppet to store the certs/keys for various
> applications (apache, shib, syslog w/ TLS, etc.) within specific hosts
> B) If so, how best to do it with having puppet deploy those certs and
> keys to said hosts
>
> Thanks for any hints or info!
>
> -matt zagrabelny
--
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] database server and port settings for puppet-dashboard
I'm trying to install puppet-dashboard v1.2.1. In database.yml.example there aren't any settings for the database server and port; neither are there any documented at http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html Does puppet dashboard require that its database be running on the local host on the default port? -- Dan Urist dur...@ucar.edu 303-497-2459 -- 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] sshkey resource type in Ubuntu 10.04
Thanks, Craig, very helpful. For anyone searching for this, the answer was to use the unhashed key. To find the unhashed key, use this command: ssh-keyscan -t rsa hostname On Mon, Oct 3, 2011 at 1:36 PM, Craig White wrote: > > On Oct 3, 2011, at 7:39 AM, Evan Stachowiak wrote: > > > Hi, > > > > I'm attempting to distribute a known host ssh key (for github) to an > > Ubuntu 10.04 host. Puppet is distributing the key into /etc/ssh/ > > ssh_known_hosts as: > > > > github.com ssh-rsa [really long ssh-rsa key] > > > > However, Ubuntu seems to expect the key in this format: > > > > |1|[really long ssh-rsa key] > > > > (note all the keys in my known_hosts and ssh_known_hosts not managed > > by puppet are prepended with '|1|' on my Ubuntu boxes). > > > > Am i missing something here? Or does Ubuntu just handle these files > > differently and I have to come up with a workaround? > > I think you are missing something and actually Ubuntu handles ssh - > authorized_keys/known_hosts/public keys, etc. just the same as every other > type of Linux/Macintosh/Windows OpenSSH implementation. > > Start with the man page... > > man authorized_keys > > |1| is actually a hashed format. > > Craig > > -- > 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. > > -- 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] database server and port settings for puppet-dashboard
On Wed, Oct 5, 2011 at 2:01 PM, Dan Urist wrote: > I'm trying to install puppet-dashboard v1.2.1. In database.yml.example > there aren't any settings for the database server and port; neither are > there any documented at > http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html > > Does puppet dashboard require that its database be running on the local > host on the default port? Dashboard uses activerecord for the database connections. It's a matter of editing the database.yml file correctly. A quick glance looks like this URL might help.. http://www.ruby-forum.com/topic/156018 > -- > Dan Urist > dur...@ucar.edu > 303-497-2459 > > -- > 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. > > -- 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: facter variables empty
Hi,
sounds like it could be a similar issue of puppet with mongrel. This was raised
recently on the list. Have a look at those.
Also paste the code you are trying to apply so we can see what you're
attempting to do.
Here is a link that you can use to see some tips on debugging issues.
http://www.devco.net/archives/2009/08/19/tips_and_tricks_for_puppet_debugging.php
Cheers,
Den
On 05/10/2011, at 22:44, joffrey wrote:
> hmm.. I'm new too puppet and I don't understand "compile the manifest
> for the node".
> I write my manifests on the puppetmaster node.
> And I test on the client node with :
> puppetd --test --debug --trace
> there is no error in the debug trace :
>
> debug: [.. many auotorequiring File[/var/puppet/... ]
> info: Caching catalog for puppetmaster.domain.fr
> debug: Creating default schedules
> debug: Loaded state in 0.00 seconds
> info: Applying configuration version '1317710581'
> debug: /Schedule[never]: Skipping device resources because running on
> a host
> ...
> debug: /Stage[main]/Resolver/File[resolv.conf]/content: Executing
> 'diff -u /etc/resolv.conf /tmp/puppet-file20111005-54594-14mbicj-0'
> --- /etc/resolv.conf2011-10-05 13:36:43.866046102 +0200
> +++ /tmp/puppet-file20111005-54594-14mbicj-02011-10-05
> 13:37:01.470405023 +0200
> @@ -1,3 +1,3 @@
> -domain mydomain.fr
> +domain
> nameserver 1.1.1.1
> nameserver 2.2.2.2
> debug: Finishing transaction 17215353320
> info: FileBucket got a duplicate file {md5}
> 84490558380d7e3f5e2475700843ced1
> info: /Stage[main]/Resolver/File[resolv.conf]: Filebucketed /etc/
> resolv.conf to puppet with sum 84490558380d7e3f5e2475700843ced1
> notice: /Stage[main]/Resolver/File[resolv.conf]/content: content
> changed '{md5}84490558380d7e3f5e2475700843ced1' to '{md5}
> 8f6a1d5e20142e3b879651ecaf67d91a'
> debug: /Stage[main]/Resolver/File[resolv.conf]: The container
> resolv.conf will propagate my refresh event
> debug: resolv.conf: The container Class[Resolver] will propagate my
> refresh event
> debug: Class[Resolver]: The container Stage[main] will propagate my
> refresh event
> debug: Finishing transaction 17215842100
> debug: Storing state
> debug: Stored state in 0.01 seconds
> notice: Finished catalog run in 0.14 seconds
> debug: Value of 'preferred_serialization_format' (pson) is invalid for
> report, using default (b64_zlib_yaml)
> debug: report supports formats: b64_zlib_yaml marshal raw yaml; using
> b64_zlib_yaml
> debug: Using cached certificate for ca
> debug: Using cached certificate for puppetmaster.mydomain.fr
> debug: Using cached certificate_revocation_list for ca
>
>
> But, I know, with the new generated resolv.conf, that facter variables
> like $domain an $ipadresse6 are empty.
>
> puppet --version : 2.7.3
> facter --version : 1.6.0
>
> client node, puppet.conf :
> [main]
> server=puppetmaster.mydomain.fr
> pluginsync=false
>
> master node, puppet.conf is empty because all default variable are
> good
>
> OS: FreeBSD 8.2
>
> puppet + mongrel + nginx
>
> --
> 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.
>
--
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.
