Re: [Puppet Users] Re: Could not retrieve file metadata for puppet:///files/limits-conf: Error 500 on SERVER: Server Error: Not authorized to call find on /file_metadata/files/limits-conf
I thought the same and have tried that to no avail. I believe its because we
are storing the files outside of the standard modules directory ie
/etc/puppetlabs/code where as we are using /etc/puppetlabs/example/code.
Thanks,
Chris
> On May 28, 2019, at 6:03 AM, Alessandro Franceschi wrote:
>
> In the file resource which manages /etc/bashrc you have probably a parameter
> like:
> source => puppet:///files/etcbashrc
>
> that should be something like:
>
> source => puppet:///modules/$MODULENAME/etcbashrc
>
> this implies that your source etcbashrc file is in a module called
> $MODULENAME in the files/etcbashrc location (note that you don't have to
> specify "files" in the source param.
>
> For details:
> https://puppet.com/docs/puppet/6.4/modules_fundamentals.html#files-in-modules
> <https://puppet.com/docs/puppet/6.4/modules_fundamentals.html#files-in-modules>
>
> On Thursday, May 23, 2019 at 10:13:38 PM UTC+2, Chris Phillips wrote:
> I am using Puppet v5.5.13 and am receiving the following error. Any help
> would be appreciated.
>
> Error: /Stage[main]/Profiles::Base/File[/etc/bashrc]: Could not evaluate:
> Could not retrieve file metadata for puppet:///files/etcbashrc: Error 500 on
> SERVER: Server Error: Not authorized to call find on
> /file_metadata/files/etcbashrc with {:rest=>"files/etcbashrc",
> :links=>"manage", :checksum_type=>"md5", :source_permissions=>"ignore"}
>
>
>
> My auth.conf looks like:
>
>
>
> authorization: {
>
> version: 1
>
> allow-header-cert-info: false
>
> rules: [
>
> {
>
> # Allow file metadata
>
> match-request: {
>
> path: "^/file_(metadata|content)/files/"
>
> type: regex
>
> }
>
> allow: "*"
>
> sort-order: 400
>
> name: "access to all file metadata"
>
> },
>
> {
>
> # Allow any file access
>
> match-request: {
>
> path: "^/puppet/v3/file_(content|metadata)s?/files"
>
> type: regex
>
> method: [get, post]
>
> }
>
> allow: "*"
>
> sort-order: 400
>
> name: "access to all files"
>
> },
>
> {
>
> # Allow nodes to retrieve their own catalog
>
> match-request: {
>
> path: "^/puppet/v3/catalog/([^/]+)$"
>
> type: regex
>
> method: [get, post]
>
> }
>
> allow: ["$1"]
>
> sort-order: 500
>
> name: "puppetlabs catalog"
>
> },
>
> {
>
> # Allow nodes to retrieve the certificate they requested earlier
>
> match-request: {
>
> path: "/puppet-ca/v1/certificate/"
>
> type: path
>
> method: get
>
> }
>
> allow-unauthenticated: true
>
> sort-order: 500
>
> name: "puppetlabs certificate"
>
> },
>
> {
>
> # Allow all nodes to access the certificate revocation list
>
> match-request: {
>
> path: "/puppet-ca/v1/certificate_revocation_list/ca"
>
> type: path
>
> method: get
>
> }
>
> allow-unauthenticated: true
>
> sort-order: 500
>
> name: "puppetlabs crl"
>
> },
>
> {
>
> # Allow nodes to request a new certificate
>
> match-request: {
>
> path: "/puppet-ca/v1/certificate_request"
>
> type: path
>
> method: [get, put]
>
> }
>
> allow-unauthenticated: true
>
> sort-order: 500
>
> name: "puppetlabs csr"
>
> },
>
> {
>
> # Allow the CA CLI to access the certificate_status endpoint
>
> match-request: {
>
> path: "/puppet-ca/v1/certificate_status"
>
> type: path
>
> method: [get, put, delete]
>
> }
>
> allow: [
>
> "localhost",
>
> &
[Puppet Users] Could not retrieve file metadata for puppet:///files/limits-conf: Error 500 on SERVER: Server Error: Not authorized to call find on /file_metadata/files/limits-conf
I am using Puppet v5.5.13 and am receiving the following error. Any help
would be appreciated.
*Error: /Stage[main]/Profiles::Base/File[/etc/bashrc]: Could not evaluate:
Could not retrieve file metadata for puppet:///files/etcbashrc: Error 500
on SERVER: Server Error: Not authorized to call find on
/file_metadata/files/etcbashrc with {:rest=>"files/etcbashrc",
:links=>"manage", :checksum_type=>"md5", :source_permissions=>"ignore"}*
*My auth.conf looks like:*
authorization: {
version: 1
allow-header-cert-info: false
rules: [
{
# Allow file metadata
match-request: {
path: "^/file_(metadata|content)/files/"
type: regex
}
allow: "*"
sort-order: 400
name: "access to all file metadata"
},
{
# Allow any file access
match-request: {
path: "^/puppet/v3/file_(content|metadata)s?/files"
type: regex
method: [get, post]
}
allow: "*"
sort-order: 400
name: "access to all files"
},
{
# Allow nodes to retrieve their own catalog
match-request: {
path: "^/puppet/v3/catalog/([^/]+)$"
type: regex
method: [get, post]
}
allow: ["$1"]
sort-order: 500
name: "puppetlabs catalog"
},
{
# Allow nodes to retrieve the certificate they requested earlier
match-request: {
path: "/puppet-ca/v1/certificate/"
type: path
method: get
}
allow-unauthenticated: true
sort-order: 500
name: "puppetlabs certificate"
},
{
# Allow all nodes to access the certificate revocation list
match-request: {
path: "/puppet-ca/v1/certificate_revocation_list/ca"
type: path
method: get
}
allow-unauthenticated: true
sort-order: 500
name: "puppetlabs crl"
},
{
# Allow nodes to request a new certificate
match-request: {
path: "/puppet-ca/v1/certificate_request"
type: path
method: [get, put]
}
allow-unauthenticated: true
sort-order: 500
name: "puppetlabs csr"
},
{
# Allow the CA CLI to access the certificate_status endpoint
match-request: {
path: "/puppet-ca/v1/certificate_status"
type: path
method: [get, put, delete]
}
allow: [
"localhost",
"example.com",
{
extensions: {
pp_cli_auth: "true"
}
}
]
sort-order: 500
name: "puppetlabs cert status"
},
{
# Allow the CA CLI to access the certificate_statuses endpoint
match-request: {
path: "/puppet-ca/v1/certificate_statuses"
type: path
method: get
}
allow: [
"localhost",
"example.com",
{
extensions: {
pp_cli_auth: "true"
}
}
]
sort-order: 500
name: "puppetlabs cert statuses"
},
{
# Allow unauthenticated access to the status service endpoint
match-request: {
path: "/status/v1/services"
type: path
method: get
}
allow-unauthenticated: true
sort-order: 500
name: "puppetlabs status service - full"
},
{
match-request: {
path: "/status/v1/simple"
type: path
method: get
}
allow-unauthenticated: true
sort-order: 500
name: "puppetlabs status service - simple"
},
{
match-request: {
path: "/puppet-admin-api/v1/environment-cache"
type: path
method: delete
}
allow: [
"localhost",
"example.com",
]
sort-order: 200
name: "environment-cache"
},
{
match-request: {
path: "/puppet-admin-api/v1/jruby-pool"
type: path
method: delete
}
allow: [
"localhost",
"example.com",
]
sort-order: 200
name:
[Puppet Users] Validation failed: Host already has a report for time and kind
Howdy, I've been getting this issue for about a month in dashboard. All our nodes poll on a cronjob between 00:00 and 01:00 daily, but one node has been getting this as a failed task for a while, with the yaml files building up on the server. Outside of this one cronjob, other puppet runs on the same node are running just fine. The backtrace on dashboard is: Importing report report-1009-84.yaml at 2011-11-22 00:33 GMTValidation failed: Host already has a report for time and kind Backtrace /usr/share/puppet-dashboard/vendor/rails/activerecord/lib/active_record/validations.rb:1102:in `save_without_dirty!' /usr/share/puppet-dashboard/vendor/rails/activerecord/lib/active_record/dirty.rb:87:in `save_without_transactions!' /usr/share/puppet-dashboard/vendor/rails/activerecord/lib/active_record/transactions.rb:200:in `save!' /usr/share/puppet-dashboard/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:136:in `transaction' /usr/share/puppet-dashboard/vendor/rails/activerecord/lib/active_record/transactions.rb:182:in `transaction' /usr/share/puppet-dashboard/vendor/rails/activerecord/lib/active_record/transactions.rb:200:in `save!' /usr/share/puppet-dashboard/vendor/rails/activerecord/lib/active_record/transactions.rb:208:in `rollback_active_record_state!' /usr/share/puppet-dashboard/vendor/rails/activerecord/lib/active_record/transactions.rb:200:in `save!' /usr/share/puppet-dashboard/app/models/report.rb:113:in `create_from_yaml' /usr/share/puppet-dashboard/app/models/report.rb:86:in `create_from_yaml_file' Any pointers appreciated. Thanks Chris -- 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: Official puppetlabs position on cron vs puppet as a service?
On 10 October 2011 13:05, Jonathan Gazeley jonathan.gaze...@bristol.ac.ukwrote: On 08/10/11 21:22, Chris Phillips wrote: What better way to monitor the puppet runs than by executing that run as part of the check? I assume your Nagios plugin execution timeout must be insanely long? :) In the past I have considered using Nagios for things other than monitoring, and likewise using Puppet for things other than configuration. On both counts I decided it was probably best to set a boundary and not wilfully abuse these tools, since it's likely to go wrong sooner or later! In my organisation we use Nagios only to monitor, and Puppet only to configure. always done within 30 seconds, and it's not like if it took longer on an occasional rollout it would impact puppet at all, temporarily messy as the monitor results might be. fundamentally though, with cron or puppetd being trivial simple, i'm more than happy to be doing it this way. Chris -- 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: Official puppetlabs position on cron vs puppet as a service?
My take on it is to run it from our nagios server. What better way to monitor the puppet runs than by executing that run as part of the check? retry intervals also help push changes out much quicker if they could take multiple runs etc. We also run a single daily cron job. Chris On 8 October 2011 19:32, Matthew Nicholson matthew.a.nichol...@gmail.comwrote: We combine these. We run as a service, but have a daily cron, with random time spread among our hosts, to stop/start the service and clean up stale .pid files. This is more of a hold over from our early days more than anything, but it works, doesn't cause issues, and keeps the runs spread out. On Fri, Oct 7, 2011 at 9:27 PM, Larry Ludwig larry...@gmail.com wrote: Mostly stlll run as cron. Though for some instances we run as a daemon. -- 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/-/itTFPtfZLocJ. 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. -- Matthew Nicholson -- 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] AW: How best to monitor puppet?
Our approach is to combine the monitoring and the execution. Totally ditch the puppet client service and use nagios to run a check_puppet script which does the puppet run and reports the exit codes. This also covers things like having a defined retry interval, so if puppet runs and there are no changes, it'll come back and run again in an hour, but if there are changes, it will run in 10 minutes etc... works really well. On 5 October 2011 04:36, Scott Smith sc...@ohlol.net 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. On Tue, Oct 4, 2011 at 8:09 PM, Tim Connors tim.w.conn...@gmail.comwrote: On Tue, 4 Oct 2011, Bernd Adamowicz wrote: -Ursprüngliche Nachricht- Von: puppet-users@googlegroups.com [mailto:puppet- us...@googlegroups.com] Im Auftrag von Marcus, Allan B Gesendet: Dienstag, 4. Oktober 2011 15:47 An: puppet-users@googlegroups.com Betreff: [Puppet Users] How best to monitor puppet? We want to use Nagios to monitor out puppet server so we can be notified if it goes down. We are using Fusion Passenger and Apache on Red Hat. Any suggestion for what and how to monitor? We use the basic checks for any Unix machine along with special checks for running Puppet master and client process where appropriate. A service which uses NRPE and a check_procs call on the Puppet boxes like these two examples works fine for us: Command[check_puppetmaster]=/usr/lib64/nagios/plugins/check_procs -w 1:1 -c 1:1 -C puppetmasterd Command[check_puppetclient]=/usr/lib64/nagios/plugins/check_procs -w 1:1 -c 1:1 -C puppet Bernd What about checking the logfile on the master to make sure that everything is checking in? Theoretically, the client daemons could be running and accepting port 8140, but the daemon could be locked up: http://cafuego.net/2011/09/24/keeping-eye-puppet-updated -- Tim Connors -- 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.
Re: [Puppet Users] yum.puppetlabs.com re-do
This doesn't seem to have been done yet any progress? I'd like to look at a 2.7.2 upgrade fairly soon and there seems no properly consistent way to get the RPM's for this. Thanks Chris On 15 July 2011 21:35, Michael Stahnke stah...@puppetlabs.com wrote: I'd like to reorganize yum.puppetlabs.com. As it is, it's a little cluttered, and it's unclear what each folder and such are for. Here's what I'd like to do: yum.puppetlabs.com/ /el /4 /5 /6 /fedora /14 /15 /sles /11 Under each of those we'll have products -- stuff we actually create as puppet labs dependencies -- stuff that we use in order to maximize our usage of Puppet Labs products then i386, x86_64 and SRPMS under each of those I'd like to have puppetlabs-release rpm as well, that will let you install this. All RPMS will be signed by the Puppet Labs signing key. This work will take place next week. Mike -- 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] Puppet 2.7.x and Facter 1.6 packages for Redhat/CentOS 5
On 14 July 2011 15:00, Todd Zullinger t...@pobox.com wrote: rvlinden wrote: I used to download the Puppet and Facter RHEL5 rpm packages from http://people.fedoraproject.org/~tmz/repo/puppet/epel/ but the latest version on that site is puppet 2.6.9 and facter 1.5.9. Does anyone know if this site is the still maintained ? or if there are other locations where the rpm's are published Yes, it's still maintained. I need to get puppet 2.6.x pushed into Feodra and EPEL stable repos before I want to push 2.7.x into the fedorapeople.org repos. I haven't had enough time the past few weeks to make that happen, so I'm a little behind. How does this relate to yum.puppetlabs.com? That's where I installed 2.6.7 from. Thanks Chris -- 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] puppet terminating - continually forcing itself to stop
On 5 July 2011 16:26, Chris Phillips ch...@untrepid.com wrote:
On 5 July 2011 14:24, Martin Alfke tux...@gmail.com wrote:
On 07/05/2011 03:19 PM, Brian Gallew wrote:
I was seeing the behavior on my Solaris boxes when running Puppet under
SMF. The issue, in my case, was that I was trying to work around an SMF
bug. My workaround was to svcadm disable puppetd;svccfg import
/var/svc/manifest/network/puppetd.xml;svcadm enable puppet. The astute
viewer will notice that svcadm disable puppetd will cause SMF to send
SIGTERM to puppet, at which point it will stop (as instructed) the
current run, so the new manifest will not be imported and the service
will not be re-started. It was all very amusing, except for the bit
where I had to fix a bunch of systems that weren't running Puppet
anymore. Mea culpa.
I have seen a similar behavior on RHEL5.
/sbin/service puppet status gets information on actual running puppet run.
We fixed the puppet init script to verify whether the running puppet
process has parent pid 1 (init).
Yeah, so the stop will try a bunch of ways to find the process, and if the
pid file doesn't exist then it just uses pidof. Hmm, not great. So I can see
how this happens IF the stop is executed, however there still seems to be no
reason to get there in the first place. That said if I try to run a stop
during a run it doesn't work. I've cleared the issue as described, and I
wouldn't expect that what I did (commenting out the ensure / enable) would
actually do anything like clearing any old pid files or anything... And it's
by no means prevalent on any of the rhel5 systems we have.
Thanks
Hi,
Was there any view about this being a bug? There is talk in this thread
about solaris but I'm only using rhel boxes.
Coming into work this morning I've seen a bunch of func processes have
stopped and puppet is doing nothing at all about it, despite a manifest
advising something else:
Manifest says -
service { funcd:
ensure = running,
enable = true,
subscribe = File[/etc/func/minion.conf],
require = Package[func],
hasrestart = true,
hasstatus = true
}
Puppet run is not interested, thinks it's still running? -
debug: Service[funcd](provider=redhat): Executing '/sbin/service funcd
status'
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig
funcd'
However as per the puppet service being turned off when it already is, this
is being left off when it should be being turned on - i.e. in both
situations it is thinking it is running when it is not - and the init script
CONFIRMS that it is NOT running, just like it does with puppet.
Thanks
Chris
--
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] puppet terminating - continually forcing itself to stop
On 11 July 2011 14:54, Dominic Cleal dcl...@redhat.com wrote:
On 11/07/11 09:18, Chris Phillips wrote:
Coming into work this morning I've seen a bunch of func processes have
stopped and puppet is doing nothing at all about it, despite a manifest
advising something else:
Manifest says -
service { funcd:
ensure = running,
enable = true,
subscribe = File[/etc/func/minion.conf],
require = Package[func],
hasrestart = true,
hasstatus = true
}
Puppet run is not interested, thinks it's still running? -
debug: Service[funcd](provider=redhat): Executing '/sbin/service funcd
status'
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig
funcd'
However as per the puppet service being turned off when it already is,
this is being left off when it should be being turned on - i.e. in both
situations it is thinking it is running when it is not - and the init
script CONFIRMS that it is NOT running, just like it does with puppet.
Is the init.d 'status' script returning a non-zero exit code? I've seen
bugs before with scripts that report on stdout that the process isn't
running, but failed to return the correct exit code (e.g. 1 or 3 for LSB).
Yes in both cases the status is returned as a 3, which is correct for a
stopped service
Cheers
Chris
--
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] Dashboard resurrecting deleted nodes
Hi, I was just searching for all systems where selinux is true on Dashboard and firstly I got no results, despite there being some (any clues?) but that search also seems to have resurrected some nodes I deleted a few weeks ago. 7 systems instantly appeared under Never reported. I just deleted one, did the search again and POW! it's back again. Does this sound familiar or should I go open a bug (against 1.1.0) Thanks Chris -- 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 terminating - continually forcing itself to stop
Hi, I've a puppet module running which ensures the puppet service is not running and not starting on boot. A few times a few different nodes have become stuck, apparently always thinking that the service is running when it is not. The following below excerpt just goes round and round run after run until I commented out the ensure and enable for the puppet service. It then completes and the node works as expected after this when the #'s are removed again. info: Applying configuration version '1309852902' debug: file_metadata supports formats: b64_zlib_yaml marshal pson raw yaml; using pson debug: Service[puppet](provider=redhat): Executing '/sbin/service puppet status' debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig puppet' debug: Service[puppet](provider=redhat): Executing '/sbin/service puppet stop' notice: Caught TERM; calling stop [root@gibsvlin-erp2dst ~]# /etc/init.d/puppet status puppetd is stopped [root@gibsvlin-erp2dst ~]# /sbin/chkconfig puppet [root@gibsvlin-erp2dst ~]# echo $? 1 [root@gibsvlin-erp2dst ~]# ps -ef | grep puppet root 5548 4886 0 09:24 pts/000:00:00 grep puppet Everything is returning the right exit codes and such, so why after being very clearly told that puppet is NOT running does it stop it anyway, and terminate? 2.6.7 btw, eagerly awaiting 2.6.9 rpms in the yum repo. Thanks Chris -- 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] proposed syntax: order { }
I wasn't aware of that layout of the syntax, that's a really interesting way
of writing it. The OP would seem to want blocks added to this though. This
is all very reminiscent of Stages though, so surely if there IS a solution
that satisfies the original need it would be an adjustment to stages. Maybe
more dynamic substages... main.a, main.b or something as actually different
stages would cause all sorts of mess if treated this glibly. If it were
possible to run multiple stages within a single class (you can't, right?)
then that'd nearly be the solution already.
Chris
On 5 July 2011 09:35, Ken Barber k...@puppetlabs.com wrote:
Whats wrong with using chained resources?
class x {
file { a:
} -
exec { b:
} -
exec { c:
} -
exec { d:
}
}
ken.
On Tue, Jul 5, 2011 at 4:40 AM, vagn scott vagnsc...@gmail.com wrote:
Sometimes things just have to happen in sequence.
It is the simplest of relations, but puppet really
has no convenient, non-fiddly way to express it.
So, how about
class x {
order { z:
file { a:
...
}
exec {
b: ... ;
c: ... ;
d: ... ;
e: ... ;
}
}
}
Things inside order { } happen in the order
that they appear. They implicitly have before
dependency assigned according to their position.
--
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.
Re: [Puppet Users] puppet terminating - continually forcing itself to stop
Currently it's just like this:
service { puppet:
#ensure = running,
#enable = true,
ensure = stopped,
enable = false,
subscribe = File[/etc/puppet/puppet.conf],
hasrestart = true,
hasstatus = true,
}
And 99% of the time all 66 of my clients are totally fine with it. I'm
calling puppet via a nagios check, so I went from ensuring it was running to
ensuring it was stopped. I don't personally have any doubt that the config
is absolutely fine, it's just getting implemented wrong sometimes.
Thanks
Chris
On 5 July 2011 10:42, Ken Barber k...@puppetlabs.com wrote:
What does your service {} block look like? Are you using hasstatus =
true? For example:
service { puppet:
ensure = running,
enable = true,
hasstatus = true,
}
ken.
On Tue, Jul 5, 2011 at 9:53 AM, Chris Phillips ch...@untrepid.com wrote:
Hi,
I've a puppet module running which ensures the puppet service is not
running
and not starting on boot. A few times a few different nodes have become
stuck, apparently always thinking that the service is running when it is
not. The following below excerpt just goes round and round run after run
until I commented out the ensure and enable for the puppet service. It
then
completes and the node works as expected after this when the #'s are
removed
again.
info: Applying configuration version '1309852902'
debug: file_metadata supports formats: b64_zlib_yaml marshal pson raw
yaml;
using pson
debug: Service[puppet](provider=redhat): Executing '/sbin/service puppet
status'
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig
puppet'
debug: Service[puppet](provider=redhat): Executing '/sbin/service puppet
stop'
notice: Caught TERM; calling stop
[root@gibsvlin-erp2dst ~]# /etc/init.d/puppet status
puppetd is stopped
[root@gibsvlin-erp2dst ~]# /sbin/chkconfig puppet
[root@gibsvlin-erp2dst ~]# echo $?
1
[root@gibsvlin-erp2dst ~]# ps -ef | grep puppet
root 5548 4886 0 09:24 pts/000:00:00 grep puppet
Everything is returning the right exit codes and such, so why after being
very clearly told that puppet is NOT running does it stop it anyway, and
terminate?
2.6.7 btw, eagerly awaiting 2.6.9 rpms in the yum repo.
Thanks
Chris
--
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.
Re: [Puppet Users] puppet terminating - continually forcing itself to stop
On 5 July 2011 14:24, Martin Alfke tux...@gmail.com wrote: On 07/05/2011 03:19 PM, Brian Gallew wrote: I was seeing the behavior on my Solaris boxes when running Puppet under SMF. The issue, in my case, was that I was trying to work around an SMF bug. My workaround was to svcadm disable puppetd;svccfg import /var/svc/manifest/network/puppetd.xml;svcadm enable puppet. The astute viewer will notice that svcadm disable puppetd will cause SMF to send SIGTERM to puppet, at which point it will stop (as instructed) the current run, so the new manifest will not be imported and the service will not be re-started. It was all very amusing, except for the bit where I had to fix a bunch of systems that weren't running Puppet anymore. Mea culpa. I have seen a similar behavior on RHEL5. /sbin/service puppet status gets information on actual running puppet run. We fixed the puppet init script to verify whether the running puppet process has parent pid 1 (init). Yeah, so the stop will try a bunch of ways to find the process, and if the pid file doesn't exist then it just uses pidof. Hmm, not great. So I can see how this happens IF the stop is executed, however there still seems to be no reason to get there in the first place. That said if I try to run a stop during a run it doesn't work. I've cleared the issue as described, and I wouldn't expect that what I did (commenting out the ensure / enable) would actually do anything like clearing any old pid files or anything... And it's by no means prevalent on any of the rhel5 systems we have. Thanks Chris -- 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] using memorysize fact in manifests
Well that's odd, I was looking at the exact same issue this morning for
sysctl.conf / oracle stuff.
But why are people writing new facts?? Why not just take a copy of the
original function and simply not run the function that normalizes the
number? It seems very odd to make a more limited version of the function
when it's already there.
Is it not possible to copy the code directly from utils/memory.rb in
facter?
Chris
On 30 June 2011 13:00, Martijn Grendelman mart...@iphion.nl wrote:
On 30-06-11 11:20, Matthias Saou wrote:
Andreas Kuntzagk andreas.kuntz...@mdc-berlin.de wrote:
I want some config depending on memorysize.
What I tried was
if ($memorysize = 256 * 1024*1024) {
...
}
But this fails because $memorysize is a string (and contains a G)
and can't be compared to an int.
Are all facts strings? How do I work with numbers?
Typical problem. Not to mention that you happen to have G but that
could very easily be M. Here's my workaround for that, which I use
for calculations to then set some sysctl.conf values accordingly :
# This is ugly, but very useful to get a standard kiB total RAM
# to base further calculations upon. Note that we get a string
$mem = inline_template(%
mem,unit = scope.lookupvar('::memorysize').split
mem = mem.to_f
# Normalize mem to KiB
case unit
when nil: mem *= (10)
when 'kB': mem *= (110)
when 'MB': mem *= (120)
when 'GB': mem *= (130)
when 'TB': mem *= (140)
end
%%= mem.to_i %)
I use a custom fact, that returns the amount of system memory in
megabytes. This is, however, Linux-only, since it uses /proc/meminfo:
$ cat modules/common/lib/facter/memorysize_mb.rb
require 'facter'
Facter.add(memorysize_mb) do
confine :kernel = :Linux
ram = 0
# Steal linux's meminfo
File.open( /proc/meminfo , 'r' ) do |f|
f.grep( /^MemTotal:/ ) { |mem|
ram = mem.split( / +/ )[1].to_i / 1024
}
end
setcode do
ram
end
end
Here's an example of how I then use it :
# kernel.shmmax
if $shmmax {
$shmmax_final = $shmmax
} else {
if $oracle {
# For non-shm half the RAM for = 4G, 2G otherwise
if $mem = 4294967296 {
$shmmax_final = $mem / 2
} else {
$shmmax_final = $mem - 2147483648
}
} else {
$shmmax_final = $mem
}
}
Best regards,
Martijn Grendelman
--
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] using memorysize fact in manifests
Further to this, this is the normal memory code condensed with normalization
removed to give raw versions of the facts.
require 'facter'
{ :MemorySizeRaw = MemTotal,
:MemoryFreeRaw = MemFree,
:SwapSizeRaw = SwapTotal,
:SwapFreeRaw = SwapFree
}.each do |fact, name|
Facter.add(fact) do
confine :kernel = :linux
setcode do
memsize_raw =
Thread::exclusive do
File.readlines(/proc/meminfo).each do |l|
memsize_raw = $1.to_i if l =~ /^#{name}:\s+(\d+)\s+\S+/
# MemoryFree == memfree + cached + buffers
# (assume scales are all the same as memfree)
if name == MemFree
l =~ /^(?:Buffers|Cached):\s+(\d+)\s+\S+/
memsize_raw += $1.to_i
end
end
end
memsize_raw
end
end
end
Thanks
Chris
On 30 June 2011 13:29, Chris Phillips ch...@untrepid.com wrote:
Well that's odd, I was looking at the exact same issue this morning for
sysctl.conf / oracle stuff.
But why are people writing new facts?? Why not just take a copy of the
original function and simply not run the function that normalizes the
number? It seems very odd to make a more limited version of the function
when it's already there.
Is it not possible to copy the code directly from utils/memory.rb in
facter?
Chris
On 30 June 2011 13:00, Martijn Grendelman mart...@iphion.nl wrote:
On 30-06-11 11:20, Matthias Saou wrote:
Andreas Kuntzagk andreas.kuntz...@mdc-berlin.de wrote:
I want some config depending on memorysize.
What I tried was
if ($memorysize = 256 * 1024*1024) {
...
}
But this fails because $memorysize is a string (and contains a G)
and can't be compared to an int.
Are all facts strings? How do I work with numbers?
Typical problem. Not to mention that you happen to have G but that
could very easily be M. Here's my workaround for that, which I use
for calculations to then set some sysctl.conf values accordingly :
# This is ugly, but very useful to get a standard kiB total RAM
# to base further calculations upon. Note that we get a string
$mem = inline_template(%
mem,unit = scope.lookupvar('::memorysize').split
mem = mem.to_f
# Normalize mem to KiB
case unit
when nil: mem *= (10)
when 'kB': mem *= (110)
when 'MB': mem *= (120)
when 'GB': mem *= (130)
when 'TB': mem *= (140)
end
%%= mem.to_i %)
I use a custom fact, that returns the amount of system memory in
megabytes. This is, however, Linux-only, since it uses /proc/meminfo:
$ cat modules/common/lib/facter/memorysize_mb.rb
require 'facter'
Facter.add(memorysize_mb) do
confine :kernel = :Linux
ram = 0
# Steal linux's meminfo
File.open( /proc/meminfo , 'r' ) do |f|
f.grep( /^MemTotal:/ ) { |mem|
ram = mem.split( / +/ )[1].to_i / 1024
}
end
setcode do
ram
end
end
Here's an example of how I then use it :
# kernel.shmmax
if $shmmax {
$shmmax_final = $shmmax
} else {
if $oracle {
# For non-shm half the RAM for = 4G, 2G otherwise
if $mem = 4294967296 {
$shmmax_final = $mem / 2
} else {
$shmmax_final = $mem - 2147483648
}
} else {
$shmmax_final = $mem
}
}
Best regards,
Martijn Grendelman
--
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] Extlookup and stages
Hi, I've seen some weird behaviour using extlookup, and wondered if anyone has seen it too... Basically it seems that if the $extlookup_* variables are defined in site.pp then an early stage use of extlookup doesn't see these variables at all, yet main stage ones do. I added some debug statements to extlookup.rb and just printed the vars, and they didn't exist. moving the lines into my template.pp which site.pp just includes they then are there and extlookup works fine. If I leave both declarations in both files then they clash, so clearly they are being loaded, but not at the right time?? Currently i've just left the declarations in templates.pp however the docs explicitly state putting them in site.pp so something is awry... Any info appreciated. Thanks Chris -- 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] How to manage many nodes easily?
I would see a principle whereby nodes should not ever be defined within the manifest code at all. To me the manifests should be written to be very generic, and then use ENC's to modify their behaviour at a user level. There is still a lot of inconsistency within Puppet as to how device specific data can be obtained (extlookup is very useful but rides roughshod over other architectural principles) but I try to stick to keeping all manifests generic. I write manifests to manage a package, then create a group in dashboard to relate that function to a business need and then a node into that group. On 21 June 2011 14:48, Martin Willemsma mwillem...@gmail.com wrote: We use /etc/puppet/node-definitions/*.pp in site.pp similar to what Carles is saying. [node-definitions] is a git repo thats being synced on both puppermasters. This happens on every push to origin We use the 'default' node which does the baseline configuration based on a 'role' In a separate file $fqdn.pp I place the definitions for a node. Are there more people using this kind of approach? --- Martin 2011/6/21 Carles Amigó carles.am...@softonic.com We had the same problem and we just separated each node (or group of nodes) in one file and then we load them using the following syntax: import nodes/*.pp You could also organize those files in subdirectories if you like so: import nodes/*/*.pp The only problem we've found with this approach is when creating new files, puppetmaster takes a while to see them. El 20/06/2011 5:25, flex escribió: We have many modules and many nodes, every node may use different module, so it's very unpleasant to modify the nodes.pp Then i saw the external node, but seems it only support class and we have many defines called in node.pp So here is my question: Is there another way for us to manage so many nodes easily or should i change all the defines to classes and using external nodes? -- 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+unsubscribe@** googlegroups.com puppet-users%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/** group/puppet-users?hl=enhttp://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] unmanaging config data
Hi,
I'm happily aware of the way that there is no concept of unmanaging
something and when this is in the context of a file ownership or whatever,
then that makes sense. But when this is applied to things like nagios
configuration data the principle seems to come unstuck. Or at least, it
seems so to me.
Say I have a nagios_service which uses another template nagios_service. I am
about to rejig my existing configuration to permit some mechanism to
override the default settings, e.g. override the command value from the
default in the template service to some host specific setting, something
(probably syntactially wrong) like...
nagios_service { diskfree_myhost:
if (defined $diskfree_command) {
command = $diskfree_command
}
use = diskfree,
}
should work to make this happen.
Now the obvious issue here is that whilst I can add this parameter into the
mix (I intend to do this via puppet dashboard) if I then remove that
variable in the same way I added it, sweet fa will happen, yes? If so then
surely that's of concern? maybe an additional option, another ensure value
maybe, to allow existing values to be purged for this kind of data?
Will I have to have a mechanism where I somehow pull a default out of the
air if no specific value is found? I'm a little vague on scoping to be clear
quite how I could set this, but if that's the only way I expect it won't
take too long, but it doesn't feel nice at all, as you wouldn't do that if
you were managing the nagios config file directly in the first place.
Thanks
Chris
--
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: Adding implicit stages to Puppet
On 10 Jun 2011 07:52, Jacob Helwig ja...@puppetlabs.com wrote: Chris Phillips ch...@untrepid.com wrote: On 10 June 2011 02:50, Jacob Helwig ja...@puppetlabs.com wrote: On Thu, 09 Jun 2011 18:42:54 -0700, Nigel Kersten wrote: https://projects.puppetlabs.com/issues/7697 One problem people producing modules that make use of stages are hitting is that it's difficult to create something reusable that integrates seamlessly into existing setups. This feature request is to add several more implicit stages to Puppet so we have: bootstrap pre main post existing by default, making it easier for authors to specify stages in their modules. Thoughts? Seems like a very good idea to me. What about these stages relating to being able regenerate facts after a stage possibly? A thread the other day about nagios configs meant delivering a new fact file and then going back on the next run to retrieve the facts. I think this required two runs, can't swear to it right now though, but a formal re-evaluation of facts after a bootstrap could be good. You could be real confusing and have a proper POST section too, right at the start, BIOS style. Not to be confused with the post stage of course! ;-) The answer to question Which comes first, 'bootstrap' or 'pre'? seems awfully ambiguous from just the names. I would see that a bootstrap stage would be for modules fundamental to puppet itself, e.g. if puppet.conf is updated. And pre would be normal run stuff that just needs to happen early on in the run itself. What's the reason for separating it out? For the reasons he already described... Thanks Chris -- 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. The question was specifically about splitting out pre and bootstrap. All the rest made sense, especially with all the talk that's been going on about prerun and postrun commands. Sure, well I have an example where my manifests use the lsbmajdistrelease fact a lot. If the lsb-release rpm isn't installed the fact doesn't exist. So a boot stage can be used to deal with ensuring the rpm gets installed, facts could then be really evaluated and the fact I need then be ready in the pre stage. -- Sent from my phone. Please excuse my brevity. -- 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] RFC: Adding implicit stages to Puppet
On 10 June 2011 09:06, Brice Figureau brice-pup...@daysofwonder.com wrote: On Thu, 2011-06-09 at 18:50 -0700, Jacob Helwig wrote: On Thu, 09 Jun 2011 18:42:54 -0700, Nigel Kersten wrote: https://projects.puppetlabs.com/issues/7697 One problem people producing modules that make use of stages are hitting is that it's difficult to create something reusable that integrates seamlessly into existing setups. This feature request is to add several more implicit stages to Puppet so we have: bootstrap pre main post existing by default, making it easier for authors to specify stages in their modules. Thoughts? The answer to question Which comes first, 'bootstrap' or 'pre'? seems awfully ambiguous from just the names. What's the reason for separating it out? One of the reason would be for the bootstrap phase to happen in its own run instead of being part of the standard run. That would allow to pre-install stuff that plugins could use (like for instance mysqladmin for the mysql types). Then the 3 other stages would happen in the same run. It would also be great to have this stage being optional in subsequent runs, allowing you to use the bootstrap stage during provisioning (ie just after a pre-seed or kickstart), but never again. This would help bootstrap from bare-metal. Whilst it initially sounds useful, is that distinction not somewhat arbitrary? The standard logic conventions can deal with that already and you'd then also need to define what constitutes the provisioning run. I suppose a command line parameter on the call in the kickstart is easy enough, but then surely that model would need to be generic across all stages and not only targeted at one stage? -- 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: Adding implicit stages to Puppet
On 10 June 2011 02:50, Jacob Helwig ja...@puppetlabs.com wrote: On Thu, 09 Jun 2011 18:42:54 -0700, Nigel Kersten wrote: https://projects.puppetlabs.com/issues/7697 One problem people producing modules that make use of stages are hitting is that it's difficult to create something reusable that integrates seamlessly into existing setups. This feature request is to add several more implicit stages to Puppet so we have: bootstrap pre main post existing by default, making it easier for authors to specify stages in their modules. Thoughts? Seems like a very good idea to me. What about these stages relating to being able regenerate facts after a stage possibly? A thread the other day about nagios configs meant delivering a new fact file and then going back on the next run to retrieve the facts. I think this required two runs, can't swear to it right now though, but a formal re-evaluation of facts after a bootstrap could be good. You could be real confusing and have a proper POST section too, right at the start, BIOS style. Not to be confused with the post stage of course! ;-) The answer to question Which comes first, 'bootstrap' or 'pre'? seems awfully ambiguous from just the names. I would see that a bootstrap stage would be for modules fundamental to puppet itself, e.g. if puppet.conf is updated. And pre would be normal run stuff that just needs to happen early on in the run itself. What's the reason for separating it out? For the reasons he already described... Thanks Chris -- 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] Puppet managed hosts in multiple nagios hostgroups
On 8 June 2011 13:30, Martijn Grendelman mart...@iphion.nl wrote:
Hi,
i want to archive the following:
i define an exported ressource for HostX to be monitored in nagios:
@@nagios_host { $fqdn:
ensure = present,
alias = $hostname,
address= $ipadress,
use= generic-host,
hostgroups = ubuntu,
target = $icingahostfile,
}
That fine and works as expected and HostX is in hostgroup ubuntu.
HostX has included a class ssh which installs the ssh services and
configures them. Inside this class i want to define that HostX is also in
hostgroup ssh-server.
And another class, which puts the node in another environment = there i
want to define, that HostX is in hostgroup testing-server and so on.
How do i archive that? How must the definition inside all these classes
look like?
That's a lot more difficult than you might expect.
I recently solved it, by collecting all the necessary hostgroups for a
host in a file using 'concat', and creating a custom fact (hostgroups)
that joins all the lines in the hostgroups-file together, for use with
nagios_host's hostgroups parameter.
The biggest drawback is that it takes two puppet runs on the target (first
one for populating the hostgroups-file, so that the custom fact is set
properly on the second run) before the nagios server can collect the
exported hosts, so it takes a while.
Well that's mad... I literally just was about to ask the exact same question
after a month of wondering...
so where do you put this fact? Sounds like it is on the nagios client
side, which makes sense in terms of pulling it out, but how does it get in
there in the first place? Can you show how this file on each client is
managed? That seems to be the only bit I'm not clear on. Are you just
putting in a single word for each class? Are you at all able to manage the
class being removed from the client? Would you need to routinely purge the
file? have a initial stage class that wipes the file?
Thanks
Chris
--
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] Puppet managed hosts in multiple nagios hostgroups
Some more specifics on *exactly* how you manage this text file would be
appreciated.
On 8 June 2011 15:00, Brian Gallew g...@gallew.org wrote:
I solved this in a similar manner. I wrote a custom fact (which
essentially returned /var/lib/puppet/state/classes.txt) and then a custom
function that generated a list of hostgroups based on that.
On Wed, Jun 8, 2011 at 6:47 AM, Chris Phillips ch...@untrepid.com wrote:
On 8 June 2011 13:30, Martijn Grendelman mart...@iphion.nl wrote:
Hi,
i want to archive the following:
i define an exported ressource for HostX to be monitored in nagios:
@@nagios_host { $fqdn:
ensure = present,
alias = $hostname,
address= $ipadress,
use= generic-host,
hostgroups = ubuntu,
target = $icingahostfile,
}
That fine and works as expected and HostX is in hostgroup ubuntu.
HostX has included a class ssh which installs the ssh services and
configures them. Inside this class i want to define that HostX is also
in
hostgroup ssh-server.
And another class, which puts the node in another environment = there
i
want to define, that HostX is in hostgroup testing-server and so on.
How do i archive that? How must the definition inside all these classes
look like?
That's a lot more difficult than you might expect.
I recently solved it, by collecting all the necessary hostgroups for a
host in a file using 'concat', and creating a custom fact (hostgroups)
that joins all the lines in the hostgroups-file together, for use with
nagios_host's hostgroups parameter.
The biggest drawback is that it takes two puppet runs on the target
(first
one for populating the hostgroups-file, so that the custom fact is set
properly on the second run) before the nagios server can collect the
exported hosts, so it takes a while.
Well that's mad... I literally just was about to ask the exact same
question after a month of wondering...
so where do you put this fact? Sounds like it is on the nagios client
side, which makes sense in terms of pulling it out, but how does it get in
there in the first place? Can you show how this file on each client is
managed? That seems to be the only bit I'm not clear on. Are you just
putting in a single word for each class? Are you at all able to manage the
class being removed from the client? Would you need to routinely purge the
file? have a initial stage class that wipes the file?
Thanks
Chris
--
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.
Re: [Puppet Users] Puppet managed hosts in multiple nagios hostgroups
Actually, I think I see what you mean here, I have a custom fact mid write
which looks like this:
Facter.add(:nagios_hostgroups) do
setcode do
if FileTest.exists?(/var/lib/puppet/classes.txt)
nagios_hostgroups =
File.open(/var/lib/puppet/classes.txt) { |file|
file.each { |line|
if line =~ /(\S+)::nagios_client/
nagios_hostgroups $1 +
end
}
}
next nagios_hostgroups if nagios_hostgroups
end
nil
end
end
So once finished this fact will return a list of all class names which are
included with the nagios_client namespace. So there's actually hopefully
nothing else to do at all here, no temp files or anything, it just requires
a naming convention in the modules to be followed.
On 8 June 2011 15:00, Brian Gallew g...@gallew.org wrote:
I solved this in a similar manner. I wrote a custom fact (which
essentially returned /var/lib/puppet/state/classes.txt) and then a custom
function that generated a list of hostgroups based on that.
On Wed, Jun 8, 2011 at 6:47 AM, Chris Phillips ch...@untrepid.com wrote:
On 8 June 2011 13:30, Martijn Grendelman mart...@iphion.nl wrote:
Hi,
i want to archive the following:
i define an exported ressource for HostX to be monitored in nagios:
@@nagios_host { $fqdn:
ensure = present,
alias = $hostname,
address= $ipadress,
use= generic-host,
hostgroups = ubuntu,
target = $icingahostfile,
}
That fine and works as expected and HostX is in hostgroup ubuntu.
HostX has included a class ssh which installs the ssh services and
configures them. Inside this class i want to define that HostX is also
in
hostgroup ssh-server.
And another class, which puts the node in another environment = there
i
want to define, that HostX is in hostgroup testing-server and so on.
How do i archive that? How must the definition inside all these classes
look like?
That's a lot more difficult than you might expect.
I recently solved it, by collecting all the necessary hostgroups for a
host in a file using 'concat', and creating a custom fact (hostgroups)
that joins all the lines in the hostgroups-file together, for use with
nagios_host's hostgroups parameter.
The biggest drawback is that it takes two puppet runs on the target
(first
one for populating the hostgroups-file, so that the custom fact is set
properly on the second run) before the nagios server can collect the
exported hosts, so it takes a while.
Well that's mad... I literally just was about to ask the exact same
question after a month of wondering...
so where do you put this fact? Sounds like it is on the nagios client
side, which makes sense in terms of pulling it out, but how does it get in
there in the first place? Can you show how this file on each client is
managed? That seems to be the only bit I'm not clear on. Are you just
putting in a single word for each class? Are you at all able to manage the
class being removed from the client? Would you need to routinely purge the
file? have a initial stage class that wipes the file?
Thanks
Chris
--
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.
Re: [Puppet Users] Puppet managed hosts in multiple nagios hostgroups
updated, and hopefully finished:
Facter.add(:bp_nagios_hostgroups) do
setcode do
if FileTest.exists?(/var/lib/puppet/classes.txt)
bp_nagios_hostgroups =
File.open(/var/lib/puppet/classes.txt) { |file|
file.each { |line|
if line =~ /^(.+)::nagios-client/
bp_nagios_hostgroups $1 +
end
}
}
next bp_nagios_hostgroups if bp_nagios_hostgroups
end
nil
end
end
On 8 June 2011 15:18, Chris Phillips ch...@untrepid.com wrote:
Actually, I think I see what you mean here, I have a custom fact mid write
which looks like this:
Facter.add(:nagios_hostgroups) do
setcode do
if FileTest.exists?(/var/lib/puppet/classes.txt)
nagios_hostgroups =
File.open(/var/lib/puppet/classes.txt) { |file|
file.each { |line|
if line =~ /(\S+)::nagios_client/
nagios_hostgroups $1 +
end
}
}
next nagios_hostgroups if nagios_hostgroups
end
nil
end
end
So once finished this fact will return a list of all class names which are
included with the nagios_client namespace. So there's actually hopefully
nothing else to do at all here, no temp files or anything, it just requires
a naming convention in the modules to be followed.
On 8 June 2011 15:00, Brian Gallew g...@gallew.org wrote:
I solved this in a similar manner. I wrote a custom fact (which
essentially returned /var/lib/puppet/state/classes.txt) and then a custom
function that generated a list of hostgroups based on that.
On Wed, Jun 8, 2011 at 6:47 AM, Chris Phillips ch...@untrepid.comwrote:
On 8 June 2011 13:30, Martijn Grendelman mart...@iphion.nl wrote:
Hi,
i want to archive the following:
i define an exported ressource for HostX to be monitored in nagios:
@@nagios_host { $fqdn:
ensure = present,
alias = $hostname,
address= $ipadress,
use= generic-host,
hostgroups = ubuntu,
target = $icingahostfile,
}
That fine and works as expected and HostX is in hostgroup ubuntu.
HostX has included a class ssh which installs the ssh services and
configures them. Inside this class i want to define that HostX is also
in
hostgroup ssh-server.
And another class, which puts the node in another environment = there
i
want to define, that HostX is in hostgroup testing-server and so on.
How do i archive that? How must the definition inside all these
classes
look like?
That's a lot more difficult than you might expect.
I recently solved it, by collecting all the necessary hostgroups for a
host in a file using 'concat', and creating a custom fact (hostgroups)
that joins all the lines in the hostgroups-file together, for use with
nagios_host's hostgroups parameter.
The biggest drawback is that it takes two puppet runs on the target
(first
one for populating the hostgroups-file, so that the custom fact is set
properly on the second run) before the nagios server can collect the
exported hosts, so it takes a while.
Well that's mad... I literally just was about to ask the exact same
question after a month of wondering...
so where do you put this fact? Sounds like it is on the nagios client
side, which makes sense in terms of pulling it out, but how does it get in
there in the first place? Can you show how this file on each client is
managed? That seems to be the only bit I'm not clear on. Are you just
putting in a single word for each class? Are you at all able to manage the
class being removed from the client? Would you need to routinely purge the
file? have a initial stage class that wipes the file?
Thanks
Chris
--
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
Re: [Puppet Users] Name or service not known
Sounds like it can't resolve puppet from your DNS. On 27 May 2011 09:14, Sumith Sudhakaran sumit...@gmail.com wrote: Hi, When I am trying update from puppet client, getting error like blow err: Could not request certificate: getaddrinfo: Name or service not known Please help to solve the same.. -- 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] mode on private_keys file for nagios / func integration
Hi, I've successfully hooked up func to use the puppet certs, mostly nicely. I'm now looking at using func to perform nagios checks (instead of installing nrpe, which is more pants than func). Here the nagios service runs as the nagios user, and so func also runs as that user, I thought I was sorted but making the private key mode 640 so func could read the private as the nagios user, but the puppet private key is always changed to mdoe 600 then puppet runs. How can a non root / puppet user access the private key for func? I can't see any way to disable to rights and chattr-ing it makes puppet choke. Is there a better way I could be approaching this overall? sudoing as part of the check doesn't sound like fun to me. Thanks Chris -- 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] Negative checkin time
On 19 May 2011 18:48, Gabriel Filion lelu...@gmail.com wrote: Hi, I'm using puppet 0.25.5 and a puppetlast script [1]. [1] : http://humangenomeinfo.com.ar/1.txt/usr/share/puppet/ext/puppetlast I get a negative checkin time from one node.. UNKNOWN: somenode.fqdn checked in -16 minutes ago how is that possible? The timestamp for the checkin time is taken from node.values[:_timestamp]. Is this timestamp based on the remote node's clock? I raised a bug for the report date being based on the clients clock, which doesn't seem right in my book: https://projects.puppetlabs.com/issues/7520 Cheers Chris -- 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] Should puppet manage its own client configs?
On 16 May 2011 21:05, Chris Phillips ch...@untrepid.com wrote: On 16 May 2011 20:14, Jonathan Gazeley jonathan.gaze...@bristol.ac.ukwrote: Hi Chris, We have configured puppet to manage its own puppet.conf on clients, and to ensure that puppetd is running on all hosts. However it does not manage puppet.conf on the puppetmaster, so if we accidentally mess up the config, we won't break the puppetmaster. This seems a logical thing to do to me, I'll want to be able to turn on archive_files sometimes, that's one angle I'm keen on. Would be useful to separate the server and client config files though really, then it wouldn't be irresponsible to manage the client side of the master server separately. Following on from this, if I do change puppet.conf and have a service subscription against it, should I be able to abort the rest of the run as puppet needs to reload? Or preferably restart and being the run again automatically? I'd like to ensure all clients report and all files are archived for a few months to be safe, and would like to be able to get this happening by pulling down the puppet.conf (so obviously not archive that specific file, but that's no problem) and restarting (or whatever is technically required to activate the changes. I see a restat become scheduled not actually restaring the service. Thanks Chris -- 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] Going to publish custom modules : Request for comments
On 15 May 2011 20:27, Matthias Saou
th...@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net wrote:
Dan Bode d...@puppetlabs.com wrote:
I have an implementation question:
1. Why are you doing the chkconfig exec:
exec { chkconfig ${title} on:
notify = Service[xinetd],
path = [ /sbin, /bin ],
onlyif = chkconfig --list ${title} | egrep -q 'off$',
}
why doesnt:
service { $title:
enable = 'true'
}
work for this?
Fair question. I'm guessing that I assumed initially that the xinetd
sub-services wouldn't work with the puppet provider. I'm now guessing
that I should do some testing again and simplify this accordingly.
Isn't the difference that IF the service doesn't exist then it won't fail,
whereas the standard service enable definition will need to service to
exist? Unless I'm missing something in the bigger picture, this is an area,
only doing stuff if the files are there to have stuff done upon them, where
puppet seems to fall short.
Thanks
Chris
--
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] Should puppet manage its own client configs?
On 16 May 2011 20:14, Jonathan Gazeley jonathan.gaze...@bristol.ac.ukwrote: Hi Chris, We have configured puppet to manage its own puppet.conf on clients, and to ensure that puppetd is running on all hosts. However it does not manage puppet.conf on the puppetmaster, so if we accidentally mess up the config, we won't break the puppetmaster. This seems a logical thing to do to me, I'll want to be able to turn on archive_files sometimes, that's one angle I'm keen on. Would be useful to separate the server and client config files though really, then it wouldn't be irresponsible to manage the client side of the master server separately. The hostname of the puppetmaster is hard-coded, in our case. Can anyone think of a better way of identifying the puppetmaster, so our manifests will run anywhere, if we decide to make a different machine the puppetmaster? Well yeah, just make puppet a cname and set the certificate name used on the master part of puppet.conf correctly. for this side of things, the client config is totally default, and it just goes to puppet via DNS, works perfectly, and I can easily rebuild a server an point the puppet cname to hit it. zero config on that side. Cheers Chris -- 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] report time determined by client not server?
Howdy, I've just built a VM where the system clock was 2 hours off. Part of the puppet manifest is to get NTP going, so the system itself takes care of itself OK. However I just noticed on Dashboard that the report listed for the build phase was also two hours off. As such I'm given to assume that the official report time is actually taken from the client and not the puppet master? To me, this makes no sense, and must surely be a bug. Why would you ever want to trust a time stamp from the client instead of just using your own time as you receive the report? Now the new VM has the correct time, the new reports are listed as older as the build phase ones etc... Thanks Chris -- 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] report time determined by client not server?
On 13 May 2011 18:46, Patrick kc7...@gmail.com wrote: On May 13, 2011, at 8:36 AM, Chris Phillips wrote: Why would you ever want to trust a time stamp from the client instead of just using your own time as you receive the report? In my case, when I run the import rake task, it imports stored reports that might be old. This means that the time the report is imported into the server is wrong and the time inside the report is correct. I also hope that someday puppet will have a system that can automatically queue reports that can't be sent and automatically send them later, though I'll admit I haven't even cared enough to file a bug report. If this happens, you'd again want to trust the client's time instead of the server's time. If the system clock was wrong, I'm surprised SSL worked. well the certs already existed, so there was no chance of a Valid Before issue. If the timezone was different, I'd suggest filing a bug report related to puppet not using the timezone properly. The root cause... well... root reason... is timezone related, utc vs system clock on the ESX host, however whilst there is wonky stuff, this is not a scenario where it could be said that that should be fixed and Puppet shouldn't be blamed. I had a report on Dashboard dated 2011-05-13 18:05 BST when it was actually run at 16:05 BST. Once NTP settles down it's a non issue. So Bug it is, just wanted a little feedback before I logged it. Thanks Chris -- 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 retrieve metadata - 2.6.7 / RHEL4 / remote site
Hi, I've got a 2.6.7 server and client setup running pretty nicely in a single site on a few rhel5 and 6 boxes, and today branched out with a RHEL4 node on a remote site. This was installing 2.6.7 (and facter 1.5.8) from source due to the lack of el4 rpms (el5's from yum.puppetlabs.com on all other RHEL boxes so far), with oldish official ruby 1.8.1 el4 rpms. On this new node I'm getting about a 30-40% failure rate in terms of runs, with errors in retrieving metadata: Mon May 09 22:16:12 +0100 2011 /Stage[main]/Nss-ldap/File[/etc/nsswitch.conf] (err): Could not evaluate: Could not retrieve file metadata for puppet:///modules/nss-ldap/nsswitch.conf: at /etc/puppet/modules/nss-ldap/manifests/init.pp:37 This happens on various different modules, but always the same error, trying to get a file for a source reference. I'm aware there are a few new variables I've thrown in, but the WAN connectivity seems to be fine, no packet loss or anything, and also as these errors are reported on the server and client, it's not like it's actually losing connection with the puppet server. Does this intermittent error ring any bells? With tagmail reports telling us about this, it's not really ignorable for us. Thanks Chris -- 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: Disable class by exception (not disable service in a class)
On 5 May 2011 14:04, jcbollinger john.bollin...@stjude.org wrote:
On May 3, 3:56 pm, Chris Phillips ch...@untrepid.com wrote:
Hi,
I don't know if I'm just not getting it, but I'm struggling to find
the way to elegantly disable a class in its entirety. I am aware of
the foo::disabled conventions, but these are about the disabling of
the end service defined by the class, not the class itself.
[...]
So again, I just want to wipe out the impact of the class, unmanage as
it were, replace the contents with a nice simple { } regardless of
what it was written to do maybe, not force disabling of the end
result, and I'm assuming there is a great and painfully simple way to
do this with style, but it's missing me right now.
There is no way to achieve precisely what you ask. Instead, you must
avoid including the class in the node's catalog in the first place.
Use conditional statements in your manifests (if / case) to select
based on nodes' facts whether to include it, or include it only for
certain nodes (which amounts to the same thing).
From the perspective of designing an ENC, you should be looking to add
classes to a common base rather than subtract classes from an omnibus
configuration. For what it's worth, I think that would still be a
better design paradigm even if Puppet could provide the alternative.
John
Thanks John, appreciated. Whilst I totally see the logic in adding to a
base, if 99% of machines want all these classes, and only a
real exception would this be deviated from (indeed I currently have no
deviations, but don't want to be caught by it when it's sure to come along)
the base is going to be irrelevant if some of the 99% modules aren't in
it.
I've come up with this methodology which seems to technically work...
===
class baseclass {
$classes = [aaa, access, banner, func, hosts, munin, ntp,
resolv, rhn, rsyslog, ssh, sudo]
define include_class() {
if ($exclude_classes == undef) or ! ($name in $exclude_classes) {
include $name
}
}
include_class{ $classes: }
}
node default {
include baseclass
}
===
So under puppet dashboard I can create a variable called exclude_classes
and give it in array of class names, and while iterating through a list of
defaults, if the candidate class is in the exclude_classes list it won't be
included.
Any thoughts / style tips would be very much appreciated, as this still
feels wrong, but I'd love it if it wasn't! Is it good to have a baseclass
there when that code could all be direct within the default node?
Thanks
Chris
--
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: Disable class by exception (not disable service in a class)
On 5 May 2011 14:52, Felix Frank felix.fr...@alumni.tu-berlin.de wrote:
Sort of funky, I like it!
First and last time for everything!
It may work, but $exclude_classes should not be a vairable, but a
parameter to your define instead.
This way, you can override the include_class in a subclass of baseclass
to set exclude_class to the name of the class.
You can have it easier by making this a boolean:
baseclass {
define include_class($exclude = false) {
if !$exclude { include $name }
}
}
class baseclass::no_rsyslog {
Include_class[rsyslog] { exclude = true }
}
Let me know if this works, because it would rule ;-)
I don't really understand the usage here. One key thing I want to do is to
be able to do all customization within dashboard, and never need to go back
to manifests for per system personalization. As I understand this take on
it, I would need to override the baseclass in a different way for every
permutation that I want to use? baseclass::no_rsyslog_or_func_or_aaa?
Whilst I would probably feel more comfortable configuring classes as
classes, not arbitrary strings which are used as classes later, I don't see
a way to have the flexibility I'd really like any other way. I'm *very* new
to this next level of puppet though, and picking up things so fast I seem
to spend most of my time replacing the previous thing I did that morning.
Does the association of these overridden classes via an external node
replace the inclusion of the original baseclass in the default node? I would
expect both to be included in parallel, meaning, in this example, rsyslog
would be included and excluded seperately, so still ultimately be included.
Thanks
Chris
--
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: Disable class by exception (not disable service in a class)
On 5 May 2011 17:22, Nan Liu n...@puppetlabs.com wrote:
On Thu, May 5, 2011 at 9:14 AM, Chris Phillips ch...@untrepid.com wrote:
On 5 May 2011 14:04, jcbollinger john.bollin...@stjude.org wrote:
On May 3, 3:56 pm, Chris Phillips ch...@untrepid.com wrote:
Hi,
I don't know if I'm just not getting it, but I'm struggling to find
the way to elegantly disable a class in its entirety. I am aware of
the foo::disabled conventions, but these are about the disabling of
the end service defined by the class, not the class itself.
[...]
So again, I just want to wipe out the impact of the class, unmanage as
it were, replace the contents with a nice simple { } regardless of
what it was written to do maybe, not force disabling of the end
result, and I'm assuming there is a great and painfully simple way to
do this with style, but it's missing me right now.
There is no way to achieve precisely what you ask. Instead, you must
avoid including the class in the node's catalog in the first place.
Use conditional statements in your manifests (if / case) to select
based on nodes' facts whether to include it, or include it only for
certain nodes (which amounts to the same thing).
From the perspective of designing an ENC, you should be looking to add
classes to a common base rather than subtract classes from an omnibus
configuration. For what it's worth, I think that would still be a
better design paradigm even if Puppet could provide the alternative.
John
Thanks John, appreciated. Whilst I totally see the logic in adding to a
base, if 99% of machines want all these classes, and only a
real exception would this be deviated from (indeed I currently have no
deviations, but don't want to be caught by it when it's sure to come
along)
the base is going to be irrelevant if some of the 99% modules aren't in
it.
I've come up with this methodology which seems to technically work...
===
class baseclass {
$classes = [aaa, access, banner, func, hosts, munin,
ntp,
resolv, rhn, rsyslog, ssh, sudo]
define include_class() {
if ($exclude_classes == undef) or ! ($name in $exclude_classes) {
include $name
}
}
include_class{ $classes: }
}
node default {
include baseclass
}
Do not follow by my bad example of abusing inline_templates (write a
puppet function instead), but this should work for your use case:
$class = inline_template(% [classes].flatten - [exclude_classes].flatten
%)
class { [$class]: }
Thanks,
Nan
Ahh, that's nice. I was looking for intersections and things, but not
knowing ruby originally I'm still really unsure how the puppet and template
codes relate to what's possible in ruby. Seems just as confusing as
interlinking python and cheetah in cobbler. Not dared to write a function
yet, but may well be worthwhile having a look.
What is the need for the flatten? Is that just for completeness, as I'm not
planning on dealing with multi-dimensional arrays at all. I can certainly
imagine it might be best practices etc. Could this relate to dealing with a
possibly non-existent exclude_classes variable?
Thanks
Chris
--
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] Disabling optional services
Howdy, Can someone enlighten me as to how I can disable a service *IF* it is installed? I want to ensure rsyslog is installed and running, which requires syslogd to not be running, but the only way I can see to enforce this in Puppet is to remove the sysklogd package, which I'd rather not do, I'd rather just disable the service if it's there, but can't see how. Pointers appreciated Thanks Chris -- 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] Disable class by exception (not disable service in a class)
Hi,
I don't know if I'm just not getting it, but I'm struggling to find
the way to elegantly disable a class in its entirety. I am aware of
the foo::disabled conventions, but these are about the disabling of
the end service defined by the class, not the class itself. I'm
looking to have an most encompassing default node class and by
exception provide overrides by ENC's with dashboard. Whilst I'm fine
with the concept of adding a class to a node in dashboard to use, for
example, sshd::disabled, but what if I want to just remove all trace
of the class, so a very simple example is a class I've written to
manage /etc/hosts. So it just sticks a templated file there, nothing
worth pasting, but how do I, by exception, ignore the file totally?
I've seen a few interesting things using variables in the class name
(e.g. include foo::$operatingsystem) (from here -
http://m0dlx.com/blog/Puppet_manifests__a_multi_OS_style_guide.html )
and I can see how that variable (not that one obviously, but something
new) could be used to include an empty class instead, but this feels
hacky for the way I would think I could use it here - not least
because I'd have to call include foo::enable or such like for every
module, which can't be good style. My initial thought would be to put
a conditional to bypass a resource, but again assume that's pretty
ugly too.
So again, I just want to wipe out the impact of the class, unmanage as
it were, replace the contents with a nice simple { } regardless of
what it was written to do maybe, not force disabling of the end
result, and I'm assuming there is a great and painfully simple way to
do this with style, but it's missing me right now.
Thanks
Chris
--
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.
