Re: [Puppet Users] Re: validate_re() does not correctly match numbers in some cases
On 05/20/2014 07:16 PM, Brian Mathis wrote: This is a bug in validate_re(), even though there is a workaround. Arguably so. One could also argue, on the other hand, that regular expressions are matched by *strings* and nothing else. Sure, we've been spoiled by bash and perl which don't give damn and implicitly convert to string every chance they get. But that isn't a universal truth. Point in fact irb(main):001:0 puts it works! if 5 =~ /[0-9]+/ = nil I agree that it *is* inconvenient to check for two cases is numeric or contains a number when logically the former implies the latter. I also think that implicit string conversion would be a beneficial feature for validate_re. But it is not necessarily a bug. Cheers, Felix -- 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/537C63ED.2060109%40alumni.tu-berlin.de. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Facts can override variables set by puppet master
On 20.5.2014, 17:05, jcbollinger wrote: On Tuesday, May 20, 2014 7:36:31 AM UTC-5, Henrik Lindberg wrote: This suggests a design that is somewhat inside-out, the idea is that what is *in* the environment defines what you want, not that you inside the environment make decisions based on the name of the environment. Agreed, and therein may be the workaround that I couldn't come up with. Nevertheless, the observed value of $::environment differs from what the docs say it should be in the OP's case. The only plausible reason for Puppet to provide the $::environment variable at all is so that its value can influence catalog building, whether directly in manifests or by interpolation into hiera hierarchy definitions, or whatever. It's not reasonable to say the variable shouldn't be used according to its docs for its apparent intended purpose. Exactly. As suggested, I'll open a bug report and see what opinions will there be. signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Module for lsyncd - multiple syncs to be configured, but only one config file
I have finally been able to get what I wanted. I open a issue ( https://github.com/axkibe/lsyncd/issues/275) on the github project website and the main developper of lsyncd gave me a few lines of code to put in my main config file to have any file in a given directory to be imported in the main config file. Then I created a module, based on a simple apache vhost module that was given as a sample in the Pro Puppet book. It works for now, I have to test it more and implement it. If someone would like to have the module I can provide the code, but it may not be good-looking or fully compliant with the highest standards... Thanks for all your help. By the way, I'd like to say that this community is fantastic. The support has been provided by many different persons around the clock, no matter the version I use or my knowledge level about puppet. I don't think that there is even one of our vendors (that we pay $) that matches that. Even though I did help a lot in the past, I don't have much time right now, but I'm glad to see that this kind of support exists in the open-source software. -- 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/7bd9e8d1-52dc-432c-8ad1-d8b0d9139c51%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] failed to submit 'replace facts' command for puppetmaster.domain.com to puppetDB
Hello, I have a separate 1. master running apache+passenger, 2. puppetDB on a separate server running postgresql 3. dashboard on a separate server. Total of 3 servers - Master, puppetdb. dashboard. This is the error message I get when I run puppet agent from any of the servers. ## I have changed the hostnames in the output below ## Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to submit 'replace facts' command for puppetmaster.domain.com to PuppetDB at puppetDB.domain.com:8081: [400 Bad Request] Missing required query parameter 'payload' Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run [server ~]# nc -v puppetdb.domain.com 8081 Connection to puppetdb.domain.com 8081 port [tcp/tproxy] succeeded! From the messages file on the master (after I've run puppet agent -t --noop --debug) I see this : May 21 10:55:23 3.3 puppetmaster.domain.com puppet-agent[8158]: (/File[/var/lib/puppet/lib]) Failed to generate additional resources using 'eval_generate': Connection refused - connect(2) May 21 10:55:23 3.3 puppetmaster.domain.com puppet-agent[8158]: (/File[/var/lib/puppet/lib]) Could not evaluate: Could not retrieve file metadata for puppet://puppetdb.domain.com/plugins: Connection refused - connect(2) May 21 10:55:23 3.3 puppetmaster.domain.com puppet-agent[8158]: (/File[/var/lib/puppet/lib]) Wrapped exception: May 21 10:55:23 3.3 puppetmaster.domain.com puppet-agent[8158]: (/File[/var/lib/puppet/lib]) Connection refused - connect(2) May 21 10:55:23 3.3 puppetmaster.domain.com puppet-agent[8158]: Could not retrieve catalog from remote server: Connection refused - connect(2) May 21 10:55:23 3.5 puppetmaster.domain.com puppet-agent[8158]: Using cached catalog May 21 10:55:23 3.6 puppetmaster.domain.com puppet-agent[8158]: Applying configuration version '1399548635' May 21 10:55:23 3.5 puppetmaster.domain.com puppet-agent[8158]: Finished catalog run in 0.02 seconds May 21 10:55:23 3.3 puppetmaster.domain.com puppet-agent[8158]: Could not send report: Connection refused - connect(2) the /var/lib/puppet/lib directory is empty on both the master and the puppetdb server. Please let me know what configurational files you require to help me solve this issue. Thank you. -- 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/869f0625-b870-4f5f-bfb8-85560c244fa8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] puppetdb 2 : Idle timeout expired: 30000/30000 ms
Catalogue size might be a factor, as templates get stored in the catalogue.
On Wed, May 21, 2014 at 2:45 PM, Phil Fenstermacher
phillip.fenstermac...@gmail.com wrote:
I encountered this same issue yesterday, and unfortunately haven't found a
fix either.
The error seems to be happening whenever I use the php::fpm::conf resource
(with ensure = present) from https://forge.puppetlabs.com/thias/php.
Removing that resource, or setting ensure to abset makes everything work
fine. That resource is essentially only creating a file resource from a
large template
(https://github.com/thias/puppet-php/blob/master/manifests/fpm/conf.pp).
I tried setting max-threads to 200 as well without any luck.
On Tuesday, May 20, 2014 11:27:05 AM UTC-4, Sergey Arlashin wrote:
Unfortunately setting max-threads to 200 did not help.
# java -version
java version 1.7.0_55
OpenJDK Runtime Environment (IcedTea 2.4.7)
(7u55-2.4.7-1ubuntu1~0.12.04.2)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
# dpkg -l |grep -i java
ii ca-certificates-java 20110912ubuntu6
Common CA certificates (JKS keystore)
ii java-common 0.43ubuntu2
Base of all Java packages
ii libjs-jquery 1.7.1-1ubuntu1
JavaScript library for dynamic web applications
ii openjdk-7-jre-headless 7u55-2.4.7-1ubuntu1~0.12.04.2
OpenJDK Java runtime, using Hotspot JIT (headless)
ii tzdata-java 2014c-0ubuntu0.12.04
time zone and daylight-saving time data for use by java runtimes
This is a fresh output in logs:
2014-05-20 15:21:52,331 INFO [p.t.s.w.jetty9-service] Initializing web
server.
2014-05-20 15:21:52,403 INFO [p.t.s.w.jetty9-service] Starting web
server.
2014-05-20 15:21:52,406 INFO [o.e.j.s.Server] jetty-9.1.z-SNAPSHOT
2014-05-20 15:21:52,436 INFO [o.e.j.s.ServerConnector] Started
ServerConnector@2557ce03{HTTP/1.1}{localhost:8080}
2014-05-20 15:21:52,504 INFO [o.e.j.s.ServerConnector] Started
ServerConnector@253e73c6{SSL-HTTP/1.1}{puppet.site:8081}
2014-05-20 15:21:52,563 INFO [c.p.p.c.services] PuppetDB version 2.0.0
2014-05-20 15:21:52,704 INFO [c.p.p.c.services] Starting broker
2014-05-20 15:21:53,581 WARN [o.a.a.b.BrokerService] Store limit is
10 mb, whilst the data directory: /var/lib/puppetdb/mq/localhost/KahaDB
only has 63697 mb of usable space
2014-05-20 15:21:53,582 INFO [c.p.p.c.services] Starting 4 command
processor threads
2014-05-20 15:21:53,602 INFO [c.p.p.c.services] Starting query server
2014-05-20 15:21:53,605 WARN [o.e.j.s.h.ContextHandler] Empty contextPath
2014-05-20 15:21:53,617 INFO [o.e.j.s.h.ContextHandler] Started
o.e.j.s.h.ContextHandler@31771aa1{/,null,AVAILABLE}
2014-05-20 15:21:53,643 INFO [c.p.p.c.services] Starting sweep of stale
reports (threshold: 14 days)
2014-05-20 15:21:53,667 INFO [c.p.p.c.services] Finished sweep of stale
reports (threshold: 14 days)
2014-05-20 15:21:53,667 INFO [c.p.p.c.services] Starting database garbage
collection
2014-05-20 15:21:53,698 INFO [c.p.p.c.services] Finished database garbage
collection
2014-05-20 15:22:05,832 INFO [c.p.p.command]
[ce2e1e6e-5bc8-4f0a-bb20-e1edd153038d] [replace facts] prod1.site
2014-05-20 15:22:36,859 WARN [o.e.j.s.HttpChannel]
/v3/commands?checksum=7b886250b6f4ff03643ca1a82ff38476b015ec02
java.io.IOException: java.util.concurrent.TimeoutException: Idle timeout
expired: 3/3 ms
at
org.eclipse.jetty.util.BlockingCallback.block(BlockingCallback.java:101)
~[puppetdb.jar:na]
at
org.eclipse.jetty.server.HttpInputOverHTTP.blockForContent(HttpInputOverHTTP.java:62)
~[puppetdb.jar:na]
at
org.eclipse.jetty.server.HttpInput$1.waitForContent(HttpInput.java:392)
~[puppetdb.jar:na]
at org.eclipse.jetty.server.HttpInput.read(HttpInput.java:161)
~[puppetdb.jar:na]
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283)
~[na:1.7.0_55]
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325)
~[na:1.7.0_55]
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177)
~[na:1.7.0_55]
at java.io.InputStreamReader.read(InputStreamReader.java:184)
~[na:1.7.0_55]
at java.io.BufferedReader.fill(BufferedReader.java:154)
~[na:1.7.0_55]
at java.io.BufferedReader.read(BufferedReader.java:175)
~[na:1.7.0_55]
at clojure.core$slurp.doInvoke(core.clj:6396) ~[puppetdb.jar:na]
at clojure.lang.RestFn.invoke(RestFn.java:410) ~[puppetdb.jar:na]
at ring.util.request$eval10113$fn__10114.invoke(request.clj:30)
~[na:na]
at clojure.lang.MultiFn.invoke(MultiFn.java:227)
~[puppetdb.jar:na]
at
com.puppetlabs.middleware$payload_to_body_string$fn__10429.invoke(middleware.clj:273)
~[na:na]
at
com.puppetlabs.middleware$verify_content_type$fn__10379.invoke(middleware.clj:128)
~[na:na]
at
com.puppetlabs.puppetdb.http.v3$v3_app$fn__11827.invoke(v3.clj:23) ~[na:na]
at
[Puppet Users] Re: Craig Dunn's Roles/Profiles/Components Conflicts
On Tuesday, May 20, 2014 12:54:15 PM UTC-5, Jesse Cotton wrote:
Understood. However without creating a custom fact, I am not aware of a
way to say 'apache::keepalive = 1' only applies when a node has the profile
'profile::apache_phpfpm'.
There is no good way to say that to Puppet. It reflects a non-idiomatic
thought process. Moreover, it's unlikely to be what you really want to say
-- you might in the future want other nodes to have keepalive enabled,
too. You should instead consider how to assign apache::keepalive: 1 to
exactly those nodes that get profile::apache_phpfpm.
There are at least two ways you could approach that problem:
1. If you are using hiera to assign roles and/or profiles to nodes then
it should be entirely straightforward to override apache::keepalive at the
same hierarchy level where you assign profile::apache_phpfpm.
2. You can perform a resource parameter override in
profile::apache_phpfpm.
If it is viable, the former is preferable to the latter. A resource
parameter override is a bit messy because it relies on implementation
details of module 'apache'. (It does not work to override class
parameters; you must instead override one or more parameters of a bona fide
resource, which can be of either defined or native type.)
And the foregoing is based on using only the built-in YAML back end.
Hiera supports pluggable back ends, usable together or separately. A
custom back end can employ whatever lookup or computation you want to serve
whichever data you choose.
We're really trying to avoid this.
I don't blame you. A custom back-end should certainly be a last resort.
As you keep that alternative in reserve, however, don't forget that such a
custom component does not necessarily need to replace the YAML back-end;
hiera can use two (or more) at the same time.
class profile::drupal (
$apache_listen = ['80'],
$apache_name_virtual_hosts = ['*:80'],
$apache_modules = ['fastcgi'],
$apache_fastcgi_servers = {
'www' = {
host = '127.0.0.1:9000',
faux_path = '/var/www/php.fcgi',
alias = '/php.fcgi',
file_type = 'application/x-httpd-php'
}
},
$phpfpm_pools = {
'www' = {
listen = '127.0.0.1:9000',
user = 'apache',
pm_max_requests = 500,
catch_workers_output = 'no',
php_admin_value = {},
php_value = {}
}
},
$php_modules = [],
$firewall_rules = {},
$backup_jobs = {},
$cron_jobs = {}
) {
include ::apache
::apache::listen { $apache_listen: }
::apache::namevirtualhost { $apache_name_virtual_hosts: }
::apache::mod { $apache_modules: }
create_resources(::apache::fastcgi::server, $apache_fastcgi_servers)
include ::php::fpm::daemon
create_resources(::php::fpm::conf, $phpfpm_pools)
::php::module { $php_modules: } ~ Service['php-fpm']
# So the apache user is created before
# php-fpm starts
Class['::apache'] - Class['::php::fpm::daemon']
create_resources(firewall, $firewall_rules)
create_resources(::duplicity::job, $backup_jobs)
create_resources(::cron::job, $cron_jobs)
}
Either you're missing something or I am. I see nothing in that class
that would inherently preclude it being composed. In particular, the two
class declarations it contains both use 'include', not the resource-like
class declaration syntax. If there is a barrier to composition it would be
related to composition with another class that declares some of the same
resources. That problem has a solution, however: factor out the
multiply-declared resources into their own class or classes, which the
then-composable classes declare instead of declaring the resources directly.
Duplicate declaration: Apache::Listen[80] is already declared in file ...
As I said, a duplicate resource. As I said, factor it (and the others)
out. I think it's excellent practice to avoid resource declarations
directly in profile classes, unless possibly of resources that are
assuredly specific to the profile in which they appear.
Yes, the class could be broken into separate classes but this only
exacerbates the issue of assigning variables based on the profile.
But that's just it: you don't *want* to assign data based (strictly) on
profile. Or if you do, then understand that it is inherently inconsistent
with composable profiles. Since the node characteristic that determines
the combination of profiles in use is its role, it is on that basis that
you want to assign data. Indeed, that's what you already said with respect
to apache::keepalive. Note that with hiera, that doesn't mean you must
avoid assigning data based on profile; it just means you must (also) be
able to assign data based on role, with the role-based data having higher
priority.
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this
Re: [Puppet Users] Re: Yumrepo resource flapping
On Tuesday, May 20, 2014 12:45:45 PM UTC-5, DjE wrote: I agree with you about this potential conflict, but it's a default RedHat configuration with rhsm, and it does not manage exactly the same thing. Puppet enable the rhel-6-server-optional-rpms which is not by enabled default, and we never said rhsm to enable it (redhat subscription side), so rhsm respect the local decision made via Puppet with the Yumrepo, so it's just a syntax conflict, No, it's not. rhsm is modifying the repository configuration file, even if it is modifying it to a form that is equivalent from Yum's perspective. If rhsm may change the file in any way, then it's managing the file. it could be a nice thing that Puppet use the same syntax. That might solve your particular issue, but Puppet cannot match the syntax details of every piece of software that might conceivably manage Yum repository files. And it's not worthwhile to try, because the underlying problem is not a syntax conflict, it's that you have established overlapping management responsibilities on your system. Puppet manage the rhsm.conf file so i tried to disable the manage_repos option, but the redhat.repo file has been destroyed by the rhsmcertd service, and disabled all RedHat repositories. Then Puppet creates the /etc/yum.repos.d/rhel-6-server-optional-rpms.repo file with just the enabled=1 parameter currently define by the Yumrepo resource. We don't want to (re)define all the redhat repository urls one by one with the YumRepo resource, maybe there is a better solution. You have the alternative of managing repo configuration files via a File resource instead of via a Yumrepo resource. You can control every detail of the file's puppet-asserted content that way. If you want to do that for multiple repo config files then you could consider creating a defined type for the purpose. That's a little more limited than the Yumrepo resource type, however, because Yumrepo can manage existing repository definitions in whatever file they appear, whereas a File resource must manage a specific file. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/cf31517f-f377-402b-94ef-e093d068a4e0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Problem using Vagrant + Puppet
On Tue, May 20, 2014 at 07:06:20AM -0700, Rafaella Keury wrote:
Hello,
I'm using Vagrant and i'm trying to use Puppet as a tool for provisioning
one of my virtual machines.
I created a folder named 'manifests' in the same directory of my
VagrantFile. Inside the 'manifests' folder I created a file named db.pp
with the following content:
exec { apt-update:
command = /usr/bin/apt-get update
}
package { mysql-server:
ensure = installed,
require = Exec[apt-update],
}
You will need to wrap that in
node default {
}
The file that you give as manifest_file to vagrant should be a
manifest with node definitions
My VagrantFile looks like this:
VAGRANTFILE_API_VERSION = 2
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.vm.box = hashicorp/precise32
config.vm.define :db do |db_config|
db_config.vm.network :private_network, :ip = 192.168.33.10
db_config.vm.provision puppet do |puppet|
puppet.manifest_file = db.pp
end
end
But when I type vagrant up db on command line, I receive the following
error message:
The configured puppet manifest is missing. Please specify a path to an
existing manifest
Does anyone know what is it?
My OS is Windows 7.
Thanks a lot!
--
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/40e0040c-7634-4f6c-865c-f31357ff8cb3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/20140521144229.GB26275%40nikolavp-desktop.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Craig Dunn's Roles/Profiles/Components Conflicts
But that's just it: you don't *want* to assign data based (strictly) on
profile. Or if you do, then understand that it is inherently inconsistent
with composable profiles. Since the node characteristic that determines
the combination of profiles in use is its role, it is on that basis that
you want to assign data. Indeed, that's what you already said with respect
to apache::keepalive. Note that with hiera, that doesn't mean you must
avoid assigning data based on profile; it just means you must (also) be
able to assign data based on role, with the role-based data having higher
priority.
I understand this better now however the problem we were really struggling
with was how to assign variables based on role or profile. Ie, how do you
incorporate the the role or profile into the hierarchy so a variable only
applies to nodes that have a particular role or profile. Your first
suggestion is good although thats not how we're currently assigning classes.
On Wednesday, May 21, 2014 10:03:33 AM UTC-4, jcbollinger wrote:
On Tuesday, May 20, 2014 12:54:15 PM UTC-5, Jesse Cotton wrote:
Understood. However without creating a custom fact, I am not aware of a
way to say 'apache::keepalive = 1' only applies when a node has the profile
'profile::apache_phpfpm'.
There is no good way to say that to Puppet. It reflects a non-idiomatic
thought process. Moreover, it's unlikely to be what you really want to say
-- you might in the future want other nodes to have keepalive enabled,
too. You should instead consider how to assign apache::keepalive: 1 to
exactly those nodes that get profile::apache_phpfpm.
There are at least two ways you could approach that problem:
1. If you are using hiera to assign roles and/or profiles to nodes
then it should be entirely straightforward to override apache::keepalive
at
the same hierarchy level where you assign profile::apache_phpfpm.
2. You can perform a resource parameter override in
profile::apache_phpfpm.
If it is viable, the former is preferable to the latter. A resource
parameter override is a bit messy because it relies on implementation
details of module 'apache'. (It does not work to override class
parameters; you must instead override one or more parameters of a bona fide
resource, which can be of either defined or native type.)
And the foregoing is based on using only the built-in YAML back end.
Hiera supports pluggable back ends, usable together or separately. A
custom back end can employ whatever lookup or computation you want to serve
whichever data you choose.
We're really trying to avoid this.
I don't blame you. A custom back-end should certainly be a last resort.
As you keep that alternative in reserve, however, don't forget that such a
custom component does not necessarily need to replace the YAML back-end;
hiera can use two (or more) at the same time.
class profile::drupal (
$apache_listen = ['80'],
$apache_name_virtual_hosts = ['*:80'],
$apache_modules = ['fastcgi'],
$apache_fastcgi_servers = {
'www' = {
host = '127.0.0.1:9000',
faux_path = '/var/www/php.fcgi',
alias = '/php.fcgi',
file_type = 'application/x-httpd-php'
}
},
$phpfpm_pools = {
'www' = {
listen = '127.0.0.1:9000',
user = 'apache',
pm_max_requests = 500,
catch_workers_output = 'no',
php_admin_value = {},
php_value = {}
}
},
$php_modules = [],
$firewall_rules = {},
$backup_jobs = {},
$cron_jobs = {}
) {
include ::apache
::apache::listen { $apache_listen: }
::apache::namevirtualhost { $apache_name_virtual_hosts: }
::apache::mod { $apache_modules: }
create_resources(::apache::fastcgi::server, $apache_fastcgi_servers)
include ::php::fpm::daemon
create_resources(::php::fpm::conf, $phpfpm_pools)
::php::module { $php_modules: } ~ Service['php-fpm']
# So the apache user is created before
# php-fpm starts
Class['::apache'] - Class['::php::fpm::daemon']
create_resources(firewall, $firewall_rules)
create_resources(::duplicity::job, $backup_jobs)
create_resources(::cron::job, $cron_jobs)
}
Either you're missing something or I am. I see nothing in that class
that would inherently preclude it being composed. In particular, the two
class declarations it contains both use 'include', not the resource-like
class declaration syntax. If there is a barrier to composition it would be
related to composition with another class that declares some of the same
resources. That problem has a solution, however: factor out the
multiply-declared resources into their own class or classes, which the
then-composable classes declare instead of declaring the resources directly.
Duplicate declaration: Apache::Listen[80] is already declared in file ...
As I said, a duplicate resource. As I said, factor it (and the
Re: [Puppet Users] Re: Yumrepo resource flapping
On Tuesday, May 20, 2014 4:24:01 PM UTC-5, Johan De Wit wrote: the yumrepo resource creates a *.repo file for every resource. Yes, if the repo definition does not already exist. If it does exist then Puppet manages it in whatever file contains it. Or it should do, and used to do. I thought I had seen a ticket about a regression in that area, but I'm having trouble finding it now. The redhat thing just puts all repos in one big file. and if you remove the redhat.repo, on a subscribed system, this file will be recreated depending on the subscribed channel. One file or several should not be a problem for Puppet. If the file continues to flap, however, instead of just flapping once, then something very strange is going on. Puppet should not be modifying the file if all the managed properties are already in the correct target state, even if the location or formatting details are not what Puppet would use. That would indeed be a bug that should be reported. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9e0648f1-aa50-4b1c-8bc6-e09d0051886a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] could not retrieve information from environment development source(s) file:/etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh
Hi,
I am having an error could not retrieve information development source
*file:/etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh*
Please help me
I have a code in
*/etc/puppetlabs/puppet/modules/java_versions/manifests/init.pp*
*class java_versions {# $::var_java_ver = '1.7.0_42' file
{'/usr/local/sbin/java_path.sh': source =
'/etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh',
owner = root, group = root, mode = '0700',}*
*if versioncmp($::var_java_ver, $java_version) 0 { notify {using
concatenated files, java version ${java_version}:; }} else { # work with
java notify {using java, java version ${java_version}:; }}# file
{'/usr/local/sbin/java.sh': # source =
'/etc/puppetlabs/puppet/modules/java_versions/scripts/java.sh', #owner =
root, #group = root, #mode = '700',#} if $java_version == 'notexit' {*
*warning('java versions are not available ($java_version)')}}*
And script in /
*etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh*
*$cat java_path.shrunuser -l oracle -c
'/u01/app/oracle/product/jdk1.7.0_25/bin/java -version'*
*Ruby code
:/etc/puppetlabs/puppet/modules/java_versions/lib/facter/java_path.rb*
*$vi java_path.rbrequire 'facter'*
*Facter.add(:java_path) do setcode do
Facter::Util::Resolution.exec('/etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh')
endend*
--
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/dfa17004-6c33-4fe0-b7a1-88ffaab40362%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: could not retrieve information from environment development source(s) file:/etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh
On Wednesday, May 21, 2014 11:05:25 AM UTC-4, Supriya Uppalapati wrote:
Hi,
I am having an error could not retrieve information development source
*file:/etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh*
Please help me
I have a code in
*/etc/puppetlabs/puppet/modules/java_versions/manifests/init.pp*
*class java_versions {# $::var_java_ver = '1.7.0_42' file
{'/usr/local/sbin/java_path.sh': source =
'/etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh',
owner = root, group = root, mode = '0700',}*
*if versioncmp($::var_java_ver, $java_version) 0 { notify {using
concatenated files, java version ${java_version}:; }} else { # work with
java notify {using java, java version ${java_version}:; }}# file
{'/usr/local/sbin/java.sh': # source =
'/etc/puppetlabs/puppet/modules/java_versions/scripts/java.sh', #owner =
root, #group = root, #mode = '700',#} if $java_version == 'notexit' {*
*warning('java versions are not available ($java_version)')}}*
And script in /
*etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh*
*$cat java_path.shrunuser -l oracle -c
'/u01/app/oracle/product/jdk1.7.0_25/bin/java -version'*
*Ruby code
:/etc/puppetlabs/puppet/modules/java_versions/lib/facter/java_path.rb*
*$vi java_path.rbrequire 'facter'*
*Facter.add(:java_path) do setcode do
Facter::Util::Resolution.exec('/etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh')
endend*
--
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/0ef933e4-050f-423a-9d83-ececc9c385a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] puppet dashboard Pending statistics always 0
Hi, I've set up puppet dashboard and my puppet master 3.6.0 is sending its reports. However, when i run an agent in noop mode, the Pending column on the dashboard for that node remains 0. While it should not be 0. The nodes pending stats on the left side are always 0 too. Any ideas how to troubleshoot this? Thanks, Rudy -- 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/2d29c7c4-a9b3-433b-b8a4-35fc64f363f8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] First time using template... Is this correct?
Hello everyone and thank you for taking the time to ready this.
I have been creating my first puppet module for a chatserver we run. The
chatserver is basically just a perl script its' not too hard to setup.
Our previous setup was with CFEngine so I'm porting everything over.
Setting the files in place was easy but we are moving from inittab to
Upstart (/etc/init instead of /etc/inittab).
Each server runs 7 instances of the chatserver on 7 different ports for 2
different sites.
Before I had two separate scripts that kept everything writing.
First chat_server_start.conf calls chat_server with the following:
start on runlevel [345]
task
script
start chat_server PORT=5000 SITE=ffadult
start chat_server PORT=5001 SITE=ffadult
start chat_server PORT=5002 SITE=ffadult
start chat_server PORT=5003 SITE=ffadult
start chat_server PORT=5004 SITE=ffadult
start chat_server PORT=6600 SITE=getiton
start chat_server PORT=6601 SITE=getiton
end script
Then chat_server.conf runs...
# Respawn and start rules for chat_server.pl
stop on runlevel [06]
respawn
instance $PORT
exec /site/bin/chat/chat_server.pl $SITE $PORT
/var/log/chat_server/chat_server_${SITE}_${PORT}.log 21
Simple enough... So here's where I'm unsure if I've done it right. In my
git repo for puppet my modules is in /home/user/puppet/modules/chatserver
In files I have chat_server.conf ffadult_chatserver_start.conf (we have
multiple clusters it's running on it's called via a variable in the other
file to call specific roles)
So now, I have created a template called chatserver_start.conf.erb and it
looks like the following:
start on runlevel [345]
task
script
% @chats.each do |site_port| -%
start chat_server PORT=%= port % SITE=%= site %
% end -%
end script
I haven't put the contents of all related files here... So if you see are
wondering about something being called just let me know. I then put the
different port-site variations in hiera.
---
classes:
- ffn_logrotate::chat_server
- ffn_cron::cron_clean_chat_tmp
- ffn_cron::cron_chat_server_cleanup
- ffn::chatserver
- chatserver::chats:
ffadult: '5000'
ffadult: '5001'
ffadult: '5002'
ffadult: '5003'
ffadult: '5004'
getiton: '6000'
getiton: '6001'
Did I do this correctly? Any help would be appreciated. Even just pointing
to the proper documentation would be much appreciated. Our resident puppet
expert is out for the week and I'm trying to get this done before then.
Thanks again!
--
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/e330f72e-6b8a-4548-a44d-c06a9ccbec1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] On code organization and the deprecation of include
Hello I have a fairly large repository (~100 modules, ~50 classes, ~200 nodes). It is currently organized like this: modules/ apache2/ manifests/ files/ templates/ iptables/ manifests/ files/ templates/ postfix/ manifests/ files/ templates/ ... manifests/ classes/ webserver.pp webserver/ apache2.pp iptables.pp mta/ postfix.pp iptables.pp ... nodes/ webserver.pp webserver/ web1.pp web2.pp ... mta.pp mta/ mta1.pp mta2.pp ... Subclasses in the modules directory are found via the autoloader, and as long as I follow the file naming conventions, that works fine. For classes and nodes, I have to use import. For example, in classes/webserver.pp I have import webserver/*.pp so that I can access classes webserver::apache2, webserver::iptables and so on. The same is done for nodes. I usually have a generic node where I set variables that are common for that class of nodes, and then the nodes themselves which inherit the generic node and set their own variables. To make that work, I use import in the same way as described above. I understand that with the deprecation of include, this will not work anymore. I can work around this for my classes by adding a new directory to the modulepath and then converting the directory structure to the manifests/files/templates structure with an init.pp file. However, what can I do about the nodes? The new feature of setting the manifest to a directory does not support subdirectories. Will I be forced to have all my nodes in the same directory and then rely on file names for organization? This is far from optimal in my opinion. What other alternatives do I have? If at all possible, I'd like to avoid using ENCs and keep using puppet files for node definitions. Thanks in advance, Andre -- 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/7eabce0e-edf6-488a-8182-41ba41e09f0e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] On code organization and the deprecation of include
On 5/21/14, 11:45 AM, Andre Nathan wrote: Hello I have a fairly large repository (~100 modules, ~50 classes, ~200 nodes). It is currently organized like this: modules/ apache2/ manifests/ files/ templates/ iptables/ manifests/ files/ templates/ postfix/ manifests/ files/ templates/ ... manifests/ classes/ webserver.pp webserver/ apache2.pp iptables.pp mta/ postfix.pp iptables.pp ... nodes/ webserver.pp webserver/ web1.pp web2.pp ... mta.pp mta/ mta1.pp mta2.pp ... Subclasses in the modules directory are found via the autoloader, and as long as I follow the file naming conventions, that works fine. For classes and nodes, I have to use import. For example, in classes/webserver.pp I have import webserver/*.pp so that I can access classes webserver::apache2, webserver::iptables and so on. The same is done for nodes. I usually have a generic node where I set variables that are common for that class of nodes, and then the nodes themselves which inherit the generic node and set their own variables. To make that work, I use import in the same way as described above. I understand that with the deprecation of include, this will not work anymore. I can work around this for my classes by adding a new directory to the modulepath and then converting the directory structure to the manifests/files/templates structure with an init.pp file. However, what can I do about the nodes? The new feature of setting the manifest to a directory does not support subdirectories. Will I be forced to have all my nodes in the same directory and then rely on file names for organization? This is far from optimal in my opinion. What other alternatives do I have? If at all possible, I'd like to avoid using ENCs and keep using puppet files for node definitions. Thanks in advance, Andre Hi Andre, I believe you mean the deprecation of 'import'. The easiest way to fix this is to cat all of your files together into one site.pp file. Your usage of a base node that other nodes inherit is an anti-pattern though and will cause you grief as you grow. Recommend reading about Craig Dunn's roles and profiles pattern and hiera_include for classifying nodes. Best regards, -g -- Garrett Honeycutt @learnpuppet Puppet Training with LearnPuppet.com Mobile: +1.206.414.8658 -- 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/537CD0E7.5050206%40garretthoneycutt.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] puppetdb 2 : Idle timeout expired: 30000/30000 ms
So one thing I'm sure about - is that there was no idle timeout
defined in 1.6.3 at all. I can connect idle for quite some time for
example. Its quite possible that there is another delay/lag somewhere
causing the connection to be idle in the first place - but with 1.6.3
this would not have surfaced for example as a server error, because
there was no idle handling.
ken.
On Wed, May 21, 2014 at 5:01 PM, Phil Fenstermacher
phillip.fenstermac...@gmail.com wrote:
Running tcpdump filtering on port 8081 renders a pcap file of about ~350K.
The template is only 20K, so large here is probably somewhat relative.
Any other thoughts?
Just for reference, I'm running the same version of Java as Sergey:
java version 1.7.0_55
OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1~0.12.04.2)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
On Wednesday, May 21, 2014 9:53:42 AM UTC-4, Ken Barber wrote:
Catalogue size might be a factor, as templates get stored in the
catalogue.
On Wed, May 21, 2014 at 2:45 PM, Phil Fenstermacher
phillip.fe...@gmail.com wrote:
I encountered this same issue yesterday, and unfortunately haven't found
a
fix either.
The error seems to be happening whenever I use the php::fpm::conf
resource
(with ensure = present) from https://forge.puppetlabs.com/thias/php.
Removing that resource, or setting ensure to abset makes everything work
fine. That resource is essentially only creating a file resource from a
large template
(https://github.com/thias/puppet-php/blob/master/manifests/fpm/conf.pp).
I tried setting max-threads to 200 as well without any luck.
On Tuesday, May 20, 2014 11:27:05 AM UTC-4, Sergey Arlashin wrote:
Unfortunately setting max-threads to 200 did not help.
# java -version
java version 1.7.0_55
OpenJDK Runtime Environment (IcedTea 2.4.7)
(7u55-2.4.7-1ubuntu1~0.12.04.2)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
# dpkg -l |grep -i java
ii ca-certificates-java 20110912ubuntu6
Common CA certificates (JKS keystore)
ii java-common 0.43ubuntu2
Base of all Java packages
ii libjs-jquery 1.7.1-1ubuntu1
JavaScript library for dynamic web applications
ii openjdk-7-jre-headless 7u55-2.4.7-1ubuntu1~0.12.04.2
OpenJDK Java runtime, using Hotspot JIT (headless)
ii tzdata-java 2014c-0ubuntu0.12.04
time zone and daylight-saving time data for use by java runtimes
This is a fresh output in logs:
2014-05-20 15:21:52,331 INFO [p.t.s.w.jetty9-service] Initializing web
server.
2014-05-20 15:21:52,403 INFO [p.t.s.w.jetty9-service] Starting web
server.
2014-05-20 15:21:52,406 INFO [o.e.j.s.Server] jetty-9.1.z-SNAPSHOT
2014-05-20 15:21:52,436 INFO [o.e.j.s.ServerConnector] Started
ServerConnector@2557ce03{HTTP/1.1}{localhost:8080}
2014-05-20 15:21:52,504 INFO [o.e.j.s.ServerConnector] Started
ServerConnector@253e73c6{SSL-HTTP/1.1}{puppet.site:8081}
2014-05-20 15:21:52,563 INFO [c.p.p.c.services] PuppetDB version 2.0.0
2014-05-20 15:21:52,704 INFO [c.p.p.c.services] Starting broker
2014-05-20 15:21:53,581 WARN [o.a.a.b.BrokerService] Store limit is
10 mb, whilst the data directory:
/var/lib/puppetdb/mq/localhost/KahaDB
only has 63697 mb of usable space
2014-05-20 15:21:53,582 INFO [c.p.p.c.services] Starting 4 command
processor threads
2014-05-20 15:21:53,602 INFO [c.p.p.c.services] Starting query server
2014-05-20 15:21:53,605 WARN [o.e.j.s.h.ContextHandler] Empty
contextPath
2014-05-20 15:21:53,617 INFO [o.e.j.s.h.ContextHandler] Started
o.e.j.s.h.ContextHandler@31771aa1{/,null,AVAILABLE}
2014-05-20 15:21:53,643 INFO [c.p.p.c.services] Starting sweep of
stale
reports (threshold: 14 days)
2014-05-20 15:21:53,667 INFO [c.p.p.c.services] Finished sweep of
stale
reports (threshold: 14 days)
2014-05-20 15:21:53,667 INFO [c.p.p.c.services] Starting database
garbage
collection
2014-05-20 15:21:53,698 INFO [c.p.p.c.services] Finished database
garbage
collection
2014-05-20 15:22:05,832 INFO [c.p.p.command]
[ce2e1e6e-5bc8-4f0a-bb20-e1edd153038d] [replace facts] prod1.site
2014-05-20 15:22:36,859 WARN [o.e.j.s.HttpChannel]
/v3/commands?checksum=7b886250b6f4ff03643ca1a82ff38476b015ec02
java.io.IOException: java.util.concurrent.TimeoutException: Idle
timeout
expired: 3/3 ms
at
org.eclipse.jetty.util.BlockingCallback.block(BlockingCallback.java:101)
~[puppetdb.jar:na]
at
org.eclipse.jetty.server.HttpInputOverHTTP.blockForContent(HttpInputOverHTTP.java:62)
~[puppetdb.jar:na]
at
org.eclipse.jetty.server.HttpInput$1.waitForContent(HttpInput.java:392)
~[puppetdb.jar:na]
at org.eclipse.jetty.server.HttpInput.read(HttpInput.java:161)
~[puppetdb.jar:na]
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283)
~[na:1.7.0_55]
at
Re: [Puppet Users] On code organization and the deprecation of include
On Wednesday, May 21, 2014 1:14:31 PM UTC-3, Garrett Honeycutt wrote: I believe you mean the deprecation of 'import'. Woops, indeed. The easiest way to fix this is to cat all of your files together into one site.pp file. Now that's even worse than having all node files in a single directory. Your usage of a base node that other nodes inherit is an anti-pattern though and will cause you grief as you grow. Why is it an anti-pattern? Isn't variable inheritance supported? Why can't I organize my nodes in sub-directories? It's something simple that greatly enhances code organization. Best, Andre -- 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/3be8fcd1-0626-4947-bf2b-d9d63475f470%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] On code organization and the deprecation of include
It may be worth it to look more at hiera and adjust your codebase there.
For example my site.pp has one line: hiera_include('classes').
I organize my setup so that hiera looks for my nodes under
hieradata/nodes/certname.yaml I see no reason not to allow further nesting
if needed.
That being said it may be a good time to look into an ENC (External Node
Classifier) like Foreman. I haven't done this yet as I work on a team and
have to take baby steps so everyone keeps up.
On Wed, May 21, 2014 at 10:44 AM, Andre Nathan andre...@gmail.com wrote:
On Wednesday, May 21, 2014 1:14:31 PM UTC-3, Garrett Honeycutt wrote:
I believe you mean the deprecation of 'import'.
Woops, indeed.
The easiest way to fix
this is to cat all of your files together into one site.pp file.
Now that's even worse than having all node files in a single directory.
Your usage of a base node that other nodes inherit is an anti-pattern
though and will cause you grief as you grow.
Why is it an anti-pattern? Isn't variable inheritance supported? Why can't
I organize my nodes in sub-directories? It's something simple that greatly
enhances code organization.
Best,
Andre
--
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/3be8fcd1-0626-4947-bf2b-d9d63475f470%40googlegroups.comhttps://groups.google.com/d/msgid/puppet-users/3be8fcd1-0626-4947-bf2b-d9d63475f470%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAOwhAcq4oYFwk_%3DStwBcftk%2BOMTVWXYrjWLiZUp8%3D5hCwO8saQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] On code organization and the deprecation of include
On Wednesday, May 21, 2014 1:59:09 PM UTC-3, Doug_F wrote: I organize my setup so that hiera looks for my nodes under hieradata/nodes/certname.yaml I see no reason not to allow further nesting if needed. It may be the only solution for me, but I'd rather not use YAML files as the risk of someone doing an edit and messing up with the indentation is high. That being said it may be a good time to look into an ENC (External Node Classifier) like Foreman. I haven't done this yet as I work on a team and have to take baby steps so everyone keeps up. This would remove the nodes from version control, which I'd rather not do either... Thanks, Andre -- 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/a0e9c129-5867-4931-95e1-653a5d8c8835%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: validate_re() does not correctly match numbers in some cases
On Wed, May 21, 2014 at 4:29 AM, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: On 05/20/2014 07:16 PM, Brian Mathis wrote: This is a bug in validate_re(), even though there is a workaround. Arguably so. One could also argue, on the other hand, that regular expressions are matched by *strings* and nothing else. Sure, we've been spoiled by bash and perl which don't give damn and implicitly convert to string every chance they get. But that isn't a universal truth. Point in fact irb(main):001:0 puts it works! if 5 =~ /[0-9]+/ = nil I agree that it *is* inconvenient to check for two cases is numeric or contains a number when logically the former implies the latter. I also think that implicit string conversion would be a beneficial feature for validate_re. But it is not necessarily a bug. Cheers, Felix If validate_re() is only effective on strings, then, in a dynamically typed language such as ruby/puppet, it better make sure it's casting to a string inside the function. Forcing the use of quotes is a workaround for something that it should be doing and creates inconsistency in the interface. Forcing the user to be aware of the internals of the function in order to use it defeats the point of using functions. One of the big problems here is that sometimes it works and sometimes it doesn't for the same data, depending on where you got it and what you did with it, which is clearly a bug. I'm not sure how else you can define a bug other than actual behavior does not match expected behavior, when the expectation is merely that the function performs in a predictable way. ❧ Brian Mathis @orev -- 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/CALKwpEwaUwoCQGDTeN6ztLJKUXoTMfgnFpK%3D7xZbifjb5sk_nw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Puppet Resources overridden using Hiera
I currently have a custom module that applies our companies' standard
server config across all servers using Hiera. This includes a class called
company::sshkeys that has various 'user' resource types (the standard
puppet type) defined for all of our admins, for example:
class company::sshkeys {
user { jane.doe:
ensure = present,
gid = company,
home= /home/jane.doe,
managehome = true,
shell = /bin/bash,
require = Group[company]
}
}
This is a slight simplification as the same class also includes our SSH
public keys hence the name.
I now find myself in the situation where I need to deny access to certain
admins on a single server. We use Hiera in our set-up as much as possible
and I would like to use Hiera to in the case of a single server tell Puppet
to not create certain user accounts. I have tried many ways to do this but
I am unsure on how to call the base resource types even though they are
embedded in a custom class or even if such a thing is possible.
Any thoughts on the cleanest way to exclude certain users from getting an
account?
--
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/5d0c1ae8-4c26-4135-b7b0-1146d97c9e53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] puppetdb 2 : Idle timeout expired: 30000/30000 ms
Phil,
Do you happen to have a tcpdump I can look at, one where this problem
is replicated? I know its SSL - but I'm primarily interested in seeing
when (and _IF_) the network connection goes idle - so packet timing is
more important to me then content. I'm trying to prove/disprove that
idletimeout is doing the correct thing here or not. It could be that
the idling is caused by something else, and the timeout is valid - or
it could be that the idletimeout is not actually paying attention to
traffic (which I can't prove locally at least for cleartext - it seems
fine).
There is also a chance the idling could be after traffic is submitted,
which would make things even more interesting. Either way I'd like
some external confirmation of this reported 'idling' and the best way
is probably via tcpdump's. If we can prove the idle timeout is correct
in its behaviour, we can stop looking at Jetty as the cause, which
helps us a lot.
If you want to chat I'm on Freenode in #puppet (ken_barber).
My colleague in the meantime is trying to upgrade us to Jetty 9.1.5
(from 9.1.0), its a non-trivial upgrade though, which sucks when under
duress. We're also looking at introducing the idle-timeout setting so
we can play with that also, potentially as a work-around for now.
ken.
On Wed, May 21, 2014 at 5:29 PM, Ken Barber k...@puppetlabs.com wrote:
So one thing I'm sure about - is that there was no idle timeout
defined in 1.6.3 at all. I can connect idle for quite some time for
example. Its quite possible that there is another delay/lag somewhere
causing the connection to be idle in the first place - but with 1.6.3
this would not have surfaced for example as a server error, because
there was no idle handling.
ken.
On Wed, May 21, 2014 at 5:01 PM, Phil Fenstermacher
phillip.fenstermac...@gmail.com wrote:
Running tcpdump filtering on port 8081 renders a pcap file of about ~350K.
The template is only 20K, so large here is probably somewhat relative.
Any other thoughts?
Just for reference, I'm running the same version of Java as Sergey:
java version 1.7.0_55
OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1~0.12.04.2)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
On Wednesday, May 21, 2014 9:53:42 AM UTC-4, Ken Barber wrote:
Catalogue size might be a factor, as templates get stored in the
catalogue.
On Wed, May 21, 2014 at 2:45 PM, Phil Fenstermacher
phillip.fe...@gmail.com wrote:
I encountered this same issue yesterday, and unfortunately haven't found
a
fix either.
The error seems to be happening whenever I use the php::fpm::conf
resource
(with ensure = present) from https://forge.puppetlabs.com/thias/php.
Removing that resource, or setting ensure to abset makes everything work
fine. That resource is essentially only creating a file resource from a
large template
(https://github.com/thias/puppet-php/blob/master/manifests/fpm/conf.pp).
I tried setting max-threads to 200 as well without any luck.
On Tuesday, May 20, 2014 11:27:05 AM UTC-4, Sergey Arlashin wrote:
Unfortunately setting max-threads to 200 did not help.
# java -version
java version 1.7.0_55
OpenJDK Runtime Environment (IcedTea 2.4.7)
(7u55-2.4.7-1ubuntu1~0.12.04.2)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
# dpkg -l |grep -i java
ii ca-certificates-java 20110912ubuntu6
Common CA certificates (JKS keystore)
ii java-common 0.43ubuntu2
Base of all Java packages
ii libjs-jquery 1.7.1-1ubuntu1
JavaScript library for dynamic web applications
ii openjdk-7-jre-headless 7u55-2.4.7-1ubuntu1~0.12.04.2
OpenJDK Java runtime, using Hotspot JIT (headless)
ii tzdata-java 2014c-0ubuntu0.12.04
time zone and daylight-saving time data for use by java runtimes
This is a fresh output in logs:
2014-05-20 15:21:52,331 INFO [p.t.s.w.jetty9-service] Initializing web
server.
2014-05-20 15:21:52,403 INFO [p.t.s.w.jetty9-service] Starting web
server.
2014-05-20 15:21:52,406 INFO [o.e.j.s.Server] jetty-9.1.z-SNAPSHOT
2014-05-20 15:21:52,436 INFO [o.e.j.s.ServerConnector] Started
ServerConnector@2557ce03{HTTP/1.1}{localhost:8080}
2014-05-20 15:21:52,504 INFO [o.e.j.s.ServerConnector] Started
ServerConnector@253e73c6{SSL-HTTP/1.1}{puppet.site:8081}
2014-05-20 15:21:52,563 INFO [c.p.p.c.services] PuppetDB version 2.0.0
2014-05-20 15:21:52,704 INFO [c.p.p.c.services] Starting broker
2014-05-20 15:21:53,581 WARN [o.a.a.b.BrokerService] Store limit is
10 mb, whilst the data directory:
/var/lib/puppetdb/mq/localhost/KahaDB
only has 63697 mb of usable space
2014-05-20 15:21:53,582 INFO [c.p.p.c.services] Starting 4 command
processor threads
2014-05-20 15:21:53,602 INFO [c.p.p.c.services] Starting query server
2014-05-20 15:21:53,605 WARN [o.e.j.s.h.ContextHandler] Empty
contextPath
2014-05-20 15:21:53,617 INFO
Re: [Puppet Users] Puppet Resources overridden using Hiera
Try getting your user list from hiera. Then it will easily be overridden on
a server basis.
class company::sshkeys ( users, ) {
users.each |$my_user| {
user { $my_user:
ensure = present,
gid = company,
home= /home/${my_user},
managehome = true,
shell = /bin/bash,
require = Group[company]
}
}
}
On Wed, May 21, 2014 at 11:21 AM, Danny Roberts
dannyroberts.perso...@googlemail.com wrote:
I currently have a custom module that applies our companies' standard
server config across all servers using Hiera. This includes a class called
company::sshkeys that has various 'user' resource types (the standard
puppet type) defined for all of our admins, for example:
class company::sshkeys {
user { jane.doe:
ensure = present,
gid = company,
home= /home/jane.doe,
managehome = true,
shell = /bin/bash,
require = Group[company]
}
}
This is a slight simplification as the same class also includes our SSH
public keys hence the name.
I now find myself in the situation where I need to deny access to certain
admins on a single server. We use Hiera in our set-up as much as possible
and I would like to use Hiera to in the case of a single server tell Puppet
to not create certain user accounts. I have tried many ways to do this but
I am unsure on how to call the base resource types even though they are
embedded in a custom class or even if such a thing is possible.
Any thoughts on the cleanest way to exclude certain users from getting an
account?
--
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/5d0c1ae8-4c26-4135-b7b0-1146d97c9e53%40googlegroups.comhttps://groups.google.com/d/msgid/puppet-users/5d0c1ae8-4c26-4135-b7b0-1146d97c9e53%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAOwhAcpHVbBHBB6N_rzCo3GFBed6kY6%2BBsUJt8xv4nWhiwSqog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Puppet Resources overridden using Hiera
For some reason my Puppet install doesn't like that:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Syntax error at 'users'; expected ')' at
/etc/puppet/modules/company/manifests/sshkeys.pp:1 on node puppetmaster
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
On Wednesday, 21 May 2014 18:44:00 UTC+1, Doug_F wrote:
Try getting your user list from hiera. Then it will easily be overridden
on a server basis.
class company::sshkeys ( users, ) {
users.each |$my_user| {
user { $my_user:
ensure = present,
gid = company,
home= /home/${my_user},
managehome = true,
shell = /bin/bash,
require = Group[company]
}
}
}
On Wed, May 21, 2014 at 11:21 AM, Danny Roberts
dannyrober...@googlemail.com javascript: wrote:
I currently have a custom module that applies our companies' standard
server config across all servers using Hiera. This includes a class called
company::sshkeys that has various 'user' resource types (the standard
puppet type) defined for all of our admins, for example:
class company::sshkeys {
user { jane.doe:
ensure = present,
gid = company,
home= /home/jane.doe,
managehome = true,
shell = /bin/bash,
require = Group[company]
}
}
This is a slight simplification as the same class also includes our SSH
public keys hence the name.
I now find myself in the situation where I need to deny access to certain
admins on a single server. We use Hiera in our set-up as much as possible
and I would like to use Hiera to in the case of a single server tell Puppet
to not create certain user accounts. I have tried many ways to do this but
I am unsure on how to call the base resource types even though they are
embedded in a custom class or even if such a thing is possible.
Any thoughts on the cleanest way to exclude certain users from getting an
account?
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to puppet-users...@googlegroups.com javascript:.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/5d0c1ae8-4c26-4135-b7b0-1146d97c9e53%40googlegroups.comhttps://groups.google.com/d/msgid/puppet-users/5d0c1ae8-4c26-4135-b7b0-1146d97c9e53%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/2cd3f157-32d3-453e-9a5c-66a1c0ed5a86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: validate_re() does not correctly match numbers in some cases
I thought hiera always returns strings? ie. $myvar = hiera('testvalue')
should return a string, and validate_re( $myvar, '[0-9]+' ) should work
just fine?
Regardless, this is inconsistent:
OK:
$var = 1000
validate_re( $var, '[0-9+]' )
FAIL:
$var2 = 2000 + 1
validate_re( $var2, '[0-9+]' )
In the first case, the number is cast as a string. In the second, it is not.
The inconsistency makes this a bug, IMHO.
R.
On 21 May 2014 18:19, Brian Mathis brian.mat...@betteradmin.com wrote:
On Wed, May 21, 2014 at 4:29 AM, Felix Frank
felix.fr...@alumni.tu-berlin.de wrote:
On 05/20/2014 07:16 PM, Brian Mathis wrote:
This is a bug in validate_re(), even though there is a workaround.
Arguably so.
One could also argue, on the other hand, that regular expressions are
matched by *strings* and nothing else. Sure, we've been spoiled by bash
and perl which don't give damn and implicitly convert to string every
chance they get. But that isn't a universal truth. Point in fact
irb(main):001:0 puts it works! if 5 =~ /[0-9]+/
= nil
I agree that it *is* inconvenient to check for two cases is numeric or
contains a number when logically the former implies the latter. I also
think that implicit string conversion would be a beneficial feature for
validate_re. But it is not necessarily a bug.
Cheers,
Felix
If validate_re() is only effective on strings, then, in a dynamically
typed language such as ruby/puppet, it better make sure it's casting to a
string inside the function. Forcing the use of quotes is a workaround for
something that it should be doing and creates inconsistency in the
interface. Forcing the user to be aware of the internals of the function
in order to use it defeats the point of using functions.
One of the big problems here is that sometimes it works and sometimes it
doesn't for the same data, depending on where you got it and what you did
with it, which is clearly a bug. I'm not sure how else you can define a
bug other than actual behavior does not match expected behavior, when the
expectation is merely that the function performs in a predictable way.
❧ Brian Mathis
@orev
--
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/CALKwpEwaUwoCQGDTeN6ztLJKUXoTMfgnFpK%3D7xZbifjb5sk_nw%40mail.gmail.comhttps://groups.google.com/d/msgid/puppet-users/CALKwpEwaUwoCQGDTeN6ztLJKUXoTMfgnFpK%3D7xZbifjb5sk_nw%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAJGKfwCBtVtBtUezvzy42vuXas%2BWFs1W9jkC_VeLXo3GSZoY1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Puppet Resources overridden using Hiera
My apology the .each functionality is only available if parser=future.
http://docs.puppetlabs.com/puppet/latest/reference/experiments_future.html
On Wed, May 21, 2014 at 12:58 PM, Danny Roberts
dannyroberts.perso...@googlemail.com wrote:
For some reason my Puppet install doesn't like that:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Syntax error at 'users'; expected ')' at
/etc/puppet/modules/company/manifests/sshkeys.pp:1 on node puppetmaster
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
On Wednesday, 21 May 2014 18:44:00 UTC+1, Doug_F wrote:
Try getting your user list from hiera. Then it will easily be overridden
on a server basis.
class company::sshkeys ( users, ) {
users.each |$my_user| {
user { $my_user:
ensure = present,
gid = company,
home= /home/${my_user},
managehome = true,
shell = /bin/bash,
require = Group[company]
}
}
}
On Wed, May 21, 2014 at 11:21 AM, Danny Roberts dannyrober...@
googlemail.com wrote:
I currently have a custom module that applies our companies' standard
server config across all servers using Hiera. This includes a class called
company::sshkeys that has various 'user' resource types (the standard
puppet type) defined for all of our admins, for example:
class company::sshkeys {
user { jane.doe:
ensure = present,
gid = company,
home= /home/jane.doe,
managehome = true,
shell = /bin/bash,
require = Group[company]
}
}
This is a slight simplification as the same class also includes our SSH
public keys hence the name.
I now find myself in the situation where I need to deny access to
certain admins on a single server. We use Hiera in our set-up as much as
possible and I would like to use Hiera to in the case of a single server
tell Puppet to not create certain user accounts. I have tried many ways to
do this but I am unsure on how to call the base resource types even though
they are embedded in a custom class or even if such a thing is possible.
Any thoughts on the cleanest way to exclude certain users from getting
an account?
--
You received this message because you are subscribed to the Google
Groups Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send
an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/puppet-users/5d0c1ae8-4c26-4135-b7b0-1146d97c9e53%
40googlegroups.comhttps://groups.google.com/d/msgid/puppet-users/5d0c1ae8-4c26-4135-b7b0-1146d97c9e53%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/2cd3f157-32d3-453e-9a5c-66a1c0ed5a86%40googlegroups.comhttps://groups.google.com/d/msgid/puppet-users/2cd3f157-32d3-453e-9a5c-66a1c0ed5a86%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAOwhAcrTVZGeQA_HuzxW6MHrxJdVk82ES0Jmwt-X%2BGzdRjBTYg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] puppetdb 2 : Idle timeout expired: 30000/30000 ms
Phil and I have been conversing offline ... we found that downgrading
the terminus to 1.6.3 (not PuppetDB) fixes the issue. So far we can
see that a submission occurs but the server does not respond. This is
synonymous with a bad Content-Length, and certainly I'm able to
replicate this with some basic tests ... but we're still looking for
the ultimate cause of this.
For now can everyone who is seeing this issue, try downgrading their
puppetdb-terminus package to 1.6.3, and see if it solves it?
ken.
On Wed, May 21, 2014 at 6:41 PM, Ken Barber k...@puppetlabs.com wrote:
Phil,
Do you happen to have a tcpdump I can look at, one where this problem
is replicated? I know its SSL - but I'm primarily interested in seeing
when (and _IF_) the network connection goes idle - so packet timing is
more important to me then content. I'm trying to prove/disprove that
idletimeout is doing the correct thing here or not. It could be that
the idling is caused by something else, and the timeout is valid - or
it could be that the idletimeout is not actually paying attention to
traffic (which I can't prove locally at least for cleartext - it seems
fine).
There is also a chance the idling could be after traffic is submitted,
which would make things even more interesting. Either way I'd like
some external confirmation of this reported 'idling' and the best way
is probably via tcpdump's. If we can prove the idle timeout is correct
in its behaviour, we can stop looking at Jetty as the cause, which
helps us a lot.
If you want to chat I'm on Freenode in #puppet (ken_barber).
My colleague in the meantime is trying to upgrade us to Jetty 9.1.5
(from 9.1.0), its a non-trivial upgrade though, which sucks when under
duress. We're also looking at introducing the idle-timeout setting so
we can play with that also, potentially as a work-around for now.
ken.
On Wed, May 21, 2014 at 5:29 PM, Ken Barber k...@puppetlabs.com wrote:
So one thing I'm sure about - is that there was no idle timeout
defined in 1.6.3 at all. I can connect idle for quite some time for
example. Its quite possible that there is another delay/lag somewhere
causing the connection to be idle in the first place - but with 1.6.3
this would not have surfaced for example as a server error, because
there was no idle handling.
ken.
On Wed, May 21, 2014 at 5:01 PM, Phil Fenstermacher
phillip.fenstermac...@gmail.com wrote:
Running tcpdump filtering on port 8081 renders a pcap file of about ~350K.
The template is only 20K, so large here is probably somewhat relative.
Any other thoughts?
Just for reference, I'm running the same version of Java as Sergey:
java version 1.7.0_55
OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1~0.12.04.2)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
On Wednesday, May 21, 2014 9:53:42 AM UTC-4, Ken Barber wrote:
Catalogue size might be a factor, as templates get stored in the
catalogue.
On Wed, May 21, 2014 at 2:45 PM, Phil Fenstermacher
phillip.fe...@gmail.com wrote:
I encountered this same issue yesterday, and unfortunately haven't found
a
fix either.
The error seems to be happening whenever I use the php::fpm::conf
resource
(with ensure = present) from https://forge.puppetlabs.com/thias/php.
Removing that resource, or setting ensure to abset makes everything work
fine. That resource is essentially only creating a file resource from a
large template
(https://github.com/thias/puppet-php/blob/master/manifests/fpm/conf.pp).
I tried setting max-threads to 200 as well without any luck.
On Tuesday, May 20, 2014 11:27:05 AM UTC-4, Sergey Arlashin wrote:
Unfortunately setting max-threads to 200 did not help.
# java -version
java version 1.7.0_55
OpenJDK Runtime Environment (IcedTea 2.4.7)
(7u55-2.4.7-1ubuntu1~0.12.04.2)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
# dpkg -l |grep -i java
ii ca-certificates-java 20110912ubuntu6
Common CA certificates (JKS keystore)
ii java-common 0.43ubuntu2
Base of all Java packages
ii libjs-jquery 1.7.1-1ubuntu1
JavaScript library for dynamic web applications
ii openjdk-7-jre-headless 7u55-2.4.7-1ubuntu1~0.12.04.2
OpenJDK Java runtime, using Hotspot JIT (headless)
ii tzdata-java 2014c-0ubuntu0.12.04
time zone and daylight-saving time data for use by java runtimes
This is a fresh output in logs:
2014-05-20 15:21:52,331 INFO [p.t.s.w.jetty9-service] Initializing web
server.
2014-05-20 15:21:52,403 INFO [p.t.s.w.jetty9-service] Starting web
server.
2014-05-20 15:21:52,406 INFO [o.e.j.s.Server] jetty-9.1.z-SNAPSHOT
2014-05-20 15:21:52,436 INFO [o.e.j.s.ServerConnector] Started
ServerConnector@2557ce03{HTTP/1.1}{localhost:8080}
2014-05-20 15:21:52,504 INFO [o.e.j.s.ServerConnector] Started
ServerConnector@253e73c6{SSL-HTTP/1.1}{puppet.site:8081}
Re: [Puppet Users] Puppet Resources overridden using Hiera
On Wednesday, May 21, 2014 1:58:22 PM UTC-5, Danny Roberts wrote:
For some reason my Puppet install doesn't like that:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Syntax error at 'users'; expected ')' at
/etc/puppet/modules/company/manifests/sshkeys.pp:1 on node puppetmaster
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
As Doug acknowledged, that requires turning on the future parser, which PL
does not recommend for production systems. But no sweat, you can do this
with the conventional parser almost as easily. You need to grease the
wheels with a defined type:
define company::user ($ensure = 'present') {
user { $title:
ensure = $ensure,
gid = company,
home= /home/${title},
managehome = true,
shell = /bin/bash,
require = Group[company]
}
}
Then you can do this:
class company::sshkeys ( users, ) {
company::user { $users: }
}
That's as far as your example suggested you wanted to go, but do note that
it does nothing to remove previously configured users that you no longer
want. If that's a concern to you then you could consider purging unmanaged
users via a Resources meta-resource.
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/5f9a945a-8473-490c-9166-38163c561e17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] using storeconfigs and exported resources
Hello , I am designing a multi-node deployment env with Puppet. Scenario i have is once one machine is created it will have its hostname allocated dynamically , that hostname has to be used by another machine when it runs it manifest on it . I can get that fqdn of that machine save it in puppetdb and ask another machine to get that hostname using exported resource Is that correct? Another scenerio in case simultaneously two users runs that module , first machine save its hostname , same time again that module is intiated by another user , now the latest machine would overwrite the entry in puppetdb. What would be the better way of doing that. Regards, Ritesh -- 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/9cbc3680-06bf-4975-ace6-8cacd8add57a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: On code organization and the deprecation of include
On Wednesday, May 21, 2014 10:45:03 AM UTC-5, Andre Nathan wrote: what can I do about the nodes? The new feature of setting the manifest to a directory does not support subdirectories. Will I be forced to have all my nodes in the same directory and then rely on file names for organization? This is far from optimal in my opinion. What other alternatives do I have? If at all possible, I'd like to avoid using ENCs and keep using puppet files for node definitions. You can continue to use import for the time being, as deprecation is not the same as deletion. Meanwhile, you can file a feature request for recursive traversal of the manifest directory, or for Puppet to support multiple manifest directories for a single environment. Alternatively, you can coalesce each of your nodes/ subdirectories into a single file in the main manifest directory (e.g. webserver.pp containing your webserver base node plus all of your webN nodes). That will leave you with a logical organization pretty similar to what you have now, and it won't clash with your local classes because you'll be moving those to modules (where really they should have been already). Or you could move away from node blocks toward node classes, which would then be organized in a module instead of in your manifest directory. There would be no particular reason to have any node blocks at all in that case; you could instead assign node classes via a top-level case statement or via hiera (or, indeed, via a simple ENC). John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/33d46124-8b19-457a-9191-1097d58e616a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] On code organization and the deprecation of include
On Wednesday, May 21, 2014 11:44:43 AM UTC-5, Andre Nathan wrote: On Wednesday, May 21, 2014 1:14:31 PM UTC-3, Garrett Honeycutt wrote: Your usage of a base node that other nodes inherit is an anti-pattern though and will cause you grief as you grow. Why is it an anti-pattern? Isn't variable inheritance supported? Why can't I organize my nodes in sub-directories? It's something simple that greatly enhances code organization. Limited node inheritance is OK if you really understand what you're doing. Most people don't: node inheritance doesn't work the way they expect. The OO meaning of inheritance leads them in the wrong direction. Multiple levels of node inheritance are a particularly precarious: in addition to inheritance likely not working as you expect or want, a node inheritance hierarchy locks you into a single principle node taxonomy. Few real sites are well modeled by such a regime. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/14d69a52-b2dc-40cf-b291-5a3b90adae75%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] puppetdb 2 : Idle timeout expired: 30000/30000 ms
Yesterday I downgraded both puppet to 3.5.1 and pupetdb to 1.6.3, and the problem disappeared. Unfortunately this is production infrastructure and I don't have an ability to test it further :( On May 21, 2014, at 11:54 PM, Ken Barber k...@puppetlabs.com wrote: Phil and I have been conversing offline ... we found that downgrading the terminus to 1.6.3 (not PuppetDB) fixes the issue. So far we can see that a submission occurs but the server does not respond. This is synonymous with a bad Content-Length, and certainly I'm able to replicate this with some basic tests ... but we're still looking for the ultimate cause of this. For now can everyone who is seeing this issue, try downgrading their puppetdb-terminus package to 1.6.3, and see if it solves it? ken. On Wed, May 21, 2014 at 6:41 PM, Ken Barber k...@puppetlabs.com wrote: Phil, Do you happen to have a tcpdump I can look at, one where this problem is replicated? I know its SSL - but I'm primarily interested in seeing when (and _IF_) the network connection goes idle - so packet timing is more important to me then content. I'm trying to prove/disprove that idletimeout is doing the correct thing here or not. It could be that the idling is caused by something else, and the timeout is valid - or it could be that the idletimeout is not actually paying attention to traffic (which I can't prove locally at least for cleartext - it seems fine). There is also a chance the idling could be after traffic is submitted, which would make things even more interesting. Either way I'd like some external confirmation of this reported 'idling' and the best way is probably via tcpdump's. If we can prove the idle timeout is correct in its behaviour, we can stop looking at Jetty as the cause, which helps us a lot. If you want to chat I'm on Freenode in #puppet (ken_barber). My colleague in the meantime is trying to upgrade us to Jetty 9.1.5 (from 9.1.0), its a non-trivial upgrade though, which sucks when under duress. We're also looking at introducing the idle-timeout setting so we can play with that also, potentially as a work-around for now. ken. On Wed, May 21, 2014 at 5:29 PM, Ken Barber k...@puppetlabs.com wrote: So one thing I'm sure about - is that there was no idle timeout defined in 1.6.3 at all. I can connect idle for quite some time for example. Its quite possible that there is another delay/lag somewhere causing the connection to be idle in the first place - but with 1.6.3 this would not have surfaced for example as a server error, because there was no idle handling. ken. On Wed, May 21, 2014 at 5:01 PM, Phil Fenstermacher phillip.fenstermac...@gmail.com wrote: Running tcpdump filtering on port 8081 renders a pcap file of about ~350K. The template is only 20K, so large here is probably somewhat relative. Any other thoughts? Just for reference, I'm running the same version of Java as Sergey: java version 1.7.0_55 OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1~0.12.04.2) OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode) On Wednesday, May 21, 2014 9:53:42 AM UTC-4, Ken Barber wrote: Catalogue size might be a factor, as templates get stored in the catalogue. On Wed, May 21, 2014 at 2:45 PM, Phil Fenstermacher phillip.fe...@gmail.com wrote: I encountered this same issue yesterday, and unfortunately haven't found a fix either. The error seems to be happening whenever I use the php::fpm::conf resource (with ensure = present) from https://forge.puppetlabs.com/thias/php. Removing that resource, or setting ensure to abset makes everything work fine. That resource is essentially only creating a file resource from a large template (https://github.com/thias/puppet-php/blob/master/manifests/fpm/conf.pp). I tried setting max-threads to 200 as well without any luck. On Tuesday, May 20, 2014 11:27:05 AM UTC-4, Sergey Arlashin wrote: Unfortunately setting max-threads to 200 did not help. # java -version java version 1.7.0_55 OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1~0.12.04.2) OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode) # dpkg -l |grep -i java ii ca-certificates-java 20110912ubuntu6 Common CA certificates (JKS keystore) ii java-common 0.43ubuntu2 Base of all Java packages ii libjs-jquery 1.7.1-1ubuntu1 JavaScript library for dynamic web applications ii openjdk-7-jre-headless 7u55-2.4.7-1ubuntu1~0.12.04.2 OpenJDK Java runtime, using Hotspot JIT (headless) ii tzdata-java 2014c-0ubuntu0.12.04 time zone and daylight-saving time data for use by java runtimes This is a fresh output in logs: 2014-05-20 15:21:52,331 INFO [p.t.s.w.jetty9-service] Initializing web server. 2014-05-20 15:21:52,403 INFO [p.t.s.w.jetty9-service] Starting web server. 2014-05-20 15:21:52,406 INFO [o.e.j.s.Server]
