[Puppet Users] Re: Could not run Puppet configuration client: SIGQUIT
Ah ok I see, I thought as a test to manage the puppet client first
would be a good thing,
thank your for your answer, then I will go with something like ntp for
a test.
cu
stefanero
On 24 Mrz., 04:16, Denmat tu2bg...@gmail.com wrote:
Hi,
If you try to restart the client during the update, won't that confuse puppet
a bit?
Dont subscribe puppet.conf to the service. I'm not sure whether puppet
re-reads changes to it's config files before it does a run (I think it does),
but I'm sure what you're trying to do won't work.
Cheers
On 24/03/2011, at 3:46, stefanero stefan...@gmail.com wrote:
Hello,
I am farly new to puppet and wanted to start configure a couple of my
servers.
I started to write a little test manifest and tryed to update the
puppet client configuration as a test.
This is my site.pp
---
--
#set fileserver to get files from
$fileserver = puppet.hugoboss.com
#import different manifets / modules get loaded by default
import puppetclient.pp
# all hosts get these actions
node default {
include puppetclient
}
---
--
and this is the included puppetclient.pp
cat puppetclient.pp
---
--
#create puppet directory for loggin etc, this is default for all
clients
#also copy our puppet config files first, when done restart service
and continoue
class puppetclient {
package {
facter:
ensure = installed;
puppet:
ensure = installed;
}
file {
/var/lib/puppet:
ensure = directory,
owner = puppet,
group = puppet,
mode = 0644;
puppet.conf:
owner = root,
path = /etc/puppet/puppet.conf,
source = puppet://$fileserver/files/puppet-agent.conf;
auth.conf:
owner = root,
path = /etc/puppet/auth.conf,
source = puppet://$fileserver/files/auth-agent.conf;
namespaceauth.conf:
owner = root,
path = /etc/puppet/namespaceauth.conf,
source = puppet://$fileserver/files/namespaceauth-agent.conf;
}
service {
puppet:
ensure = true,
enable = true,
subscribe = [File[puppet.conf], File[auth.conf],
File[namespaceauth.conf], Package[puppet] ]
}
}
---
--
As you can tell, I guess nothing special.
All files get transfered to the client, but when I change a file for
example the puppet.conf I get in the syslog a msg
Mar 23 17:35:26 test-box puppet-agent[32527]: Could not run Puppet
configuration client: SIGQUIT
Also the new configuration is not applied. I changed the runinterval
value from 180 sec to 20 sec, but still only every 30min I see a
connect.
This only works if I manually do a
/etc/init.d/puppet restart
I am running a opensuse 11.3 x86 and build the RPM myself using the
puppet specfile present in the tarbal.
Can anyone help me out what I am missing?
Thank you very much
stefanero
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Foreman 0.2 Release Candidate
On Tue, Mar 22, 2011 at 10:40 PM, Cody Robertson c...@hawkhost.com wrote: On 03/22/2011 04:32 PM, Ohad Levy wrote: On Tue, Mar 22, 2011 at 10:28 PM, Cody Robertson c...@hawkhost.comwrote: On 03/22/2011 04:23 PM, Ohad Levy wrote: On Tue, Mar 22, 2011 at 10:04 PM, Eduardo S. Scarpellini scarpell...@gmail.com wrote: Super cool, Ohad. Is there a RPM for this RC? http://yum.theforeman.org/test/RPMS/foreman-0.2-rc1.1.noarch.rpm The version of rubygem-rest-client in EPEL is 1.3.1 however the the new version requires 1.4.0. Maybe update the spec file / RPM to reflect this? Thanks for the reminder :-) I guess I was not sure what would be better, a failure to install foreman on RHEL5 (as the package is missing) or a failure when starting foreman. I know (and its in the release notes), I've asked the upstream maintainer in EPEL to update the package, but if that won't be provided, I guess we could try to provide a newer version in foreman's repo. The current behavior isn't nice at all assuming people are using the init script provided - it just doesn't start up but provides no logs / output that I can tell. I only noticed when manually starting up WEBrick. The current client is 1.6.1 so hopefully upstream just updates it :). thanks.. it will be pushed to EPEL within 24 hours - https://admin.fedoraproject.org/updates/rubygem-rest-client-1.6.1-2.el5 -- Cody Robertson 1-800-859-8803 ext. 5 -- 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] Adding existing users to groups
Hi,
On 03/23/2011 07:13 PM, Peter Gillard-Moss wrote:
Hi,
I have an interesting problem with groups and users.
Our puppet configuration is nice and modular so each application we wish
to install has its own class. For some applications we want to add
existing users, created in another class to a new group. Here's an example:
class App1 {
package { App1 ... }
user { app1user : ... }
}
class App2 {
package { app2
requires = Package[app1]
}
group { app2users :
ensure = present
}
user { name = app1user
groups = app2users
}
}
In class App2, do
User| title == app1user | { groups = [ app2users ] }
Plusignment may work even better for you
User| title == app1user | { groups + [ app2users ] }
However puppet seems to balk doing this (even the first app) with:
Cannot alias User[app1inapp3] to app1user; resource User[app1user]
already exist
Just to add some extra complexity we also need to have two apps that
extend the first one, like so:
class App3 {
package { app3
requires = Package[app1]
}
group { app3users :
ensure = present
}
user { app1inapp3 name = app1user
groups = app3users
}
}
It's not at all clear to me what this is supposed to do. Perhaps you want to
class App3 {
include App1::with_app3_support
}
and
class App3::with_app3_support inherits App3 {
User[app1user] { groups + [ app3users ] }
}
BTW, does this manifest even work? I believe uppercasing class names
breaks puppet. (But you're probably just over-paraphrasing?)
HTH,
Felix
--
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] Upgrade guide?
On 03/23/2011 11:49 PM, Michel wrote: Hello; Is there any documentation on how to perform a puppet upgrade? I download the tarball and extracted it to my copied puppetmaster server. Right now I have all the node definitions working, but any modules are not working. (not even a simply touch foo.txt exec command) Some errors I am getting are related to tests Parametr onlyif failed: 'test -f /etc/puppet/puppet.conf` is not a qualified and no path was specified. We are upgrading from 2.5-1 to 2.6.6-1 Er, what? Is that 0.25.0? Anyway, have you upgraded your clients as well? (Not doing that should be quite OK.) Is the master serving catalogs? Are those errors reported by client or master? Have you run the master with debug output yet? Cheers, Felix -- 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] Adding existing users to groups
It's not at all clear to me what this is supposed to do. Perhaps you want to
class App3 {
include App1::with_app3_support
}
and
class App3::with_app3_support inherits App3 {
User[app1user] { groups + [ app3users ] }
}
Grr. That's what you get for over-paraphrasing ;-p
Of course, that should be App1::with_app3_support inherits App1. Silly me.
Regards,
Felix
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Could not run Puppet configuration client: SIGQUIT
I need to adjust the runinterval for example, because 30min is way to
often when you change something once a month.
Therefor I would have to update the puppet.conf file , and then give
the client a restart to take its new config.
Well I did another test,
took out puppet.conf from the service definition, and changed
puppet.conf.
The client received an update, but it did not restart itself, so the
old configuration was still active. So the client did not check if its
config changed or not.
Of course I could write a little script, to check when the puppet.conf
changed and restart the puppet agent.
But this seams to me just a workaround :-/
maybe someone knows a way to accomplish this.
Thnx
Stefanero
On 24 Mrz., 09:37, stefanero stefan...@gmail.com wrote:
Ah ok I see, I thought as a test to manage the puppet client first
would be a good thing,
thank your for your answer, then I will go with something like ntp for
a test.
cu
stefanero
On 24 Mrz., 04:16, Denmat tu2bg...@gmail.com wrote:
Hi,
If you try to restart the client during the update, won't that confuse
puppet a bit?
Dont subscribe puppet.conf to the service. I'm not sure whether puppet
re-reads changes to it's config files before it does a run (I think it
does), but I'm sure what you're trying to do won't work.
Cheers
On 24/03/2011, at 3:46, stefanero stefan...@gmail.com wrote:
Hello,
I am farly new to puppet and wanted to start configure a couple of my
servers.
I started to write a little test manifest and tryed to update the
puppet client configuration as a test.
This is my site.pp
---
--
#set fileserver to get files from
$fileserver = puppet.hugoboss.com
#import different manifets / modules get loaded by default
import puppetclient.pp
# all hosts get these actions
node default {
include puppetclient
}
---
--
and this is the included puppetclient.pp
cat puppetclient.pp
---
--
#create puppet directory for loggin etc, this is default for all
clients
#also copy our puppet config files first, when done restart service
and continoue
class puppetclient {
package {
facter:
ensure = installed;
puppet:
ensure = installed;
}
file {
/var/lib/puppet:
ensure = directory,
owner = puppet,
group = puppet,
mode = 0644;
puppet.conf:
owner = root,
path = /etc/puppet/puppet.conf,
source = puppet://$fileserver/files/puppet-agent.conf;
auth.conf:
owner = root,
path = /etc/puppet/auth.conf,
source = puppet://$fileserver/files/auth-agent.conf;
namespaceauth.conf:
owner = root,
path = /etc/puppet/namespaceauth.conf,
source =
puppet://$fileserver/files/namespaceauth-agent.conf;
}
service {
puppet:
ensure = true,
enable = true,
subscribe = [File[puppet.conf], File[auth.conf],
File[namespaceauth.conf], Package[puppet] ]
}
}
---
--
As you can tell, I guess nothing special.
All files get transfered to the client, but when I change a file for
example the puppet.conf I get in the syslog a msg
Mar 23 17:35:26 test-box puppet-agent[32527]: Could not run Puppet
configuration client: SIGQUIT
Also the new configuration is not applied. I changed the runinterval
value from 180 sec to 20 sec, but still only every 30min I see a
connect.
This only works if I manually do a
/etc/init.d/puppet restart
I am running a opensuse 11.3 x86 and build the RPM myself using the
puppet specfile present in the tarbal.
Can anyone help me out what I am missing?
Thank you very much
stefanero
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Could not run Puppet configuration client: SIGQUIT
On Mar 24, 6:33 am, stefanero stefan...@gmail.com wrote: I need to adjust the runinterval for example, because 30min is way to often when you change something once a month. Naturally you do need to choose a run interval that is appropriate for your situation. Do remember, however, that Puppet is about more than pushing out intentional configuration changes. It is also about *maintaining* your systems' configurations in the state you have declared, in the face of possible alterations arising from other sources. It is also about monitoring, if you so choose. None of that makes 30 minutes any kind of magic interval, but I do encourage you to take the whole picture into account when you choose an interval. Therefor I would have to update the puppet.conf file , and then give the client a restart to take its new config. Well I did another test, took out puppet.conf from the service definition, and changed puppet.conf. The client received an update, but it did not restart itself, so the old configuration was still active. So the client did not check if its config changed or not. Of course I could write a little script, to check when the puppet.conf changed and restart the puppet agent. But this seams to me just a workaround :-/ maybe someone knows a way to accomplish this. Some people trigger regular puppetd runs via cron instead of running puppetd in daemon mode. I think most choose that route for other reasons, but it certainly avoids problems with puppetd recognizing changes to its own configuration. John -- 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] err: Could not retrieve catalog from remote server: certificate verify failed
So set up new node, ran on the client puppetd --server puppetmaster --waitforcert 60 --test on the puppetmaster itself I ran puppetca --list saw the hostname and then ran: puppetca --sign hostname.domain.com and on the puppet node itself I went back and ran puppetd -tv and get the following error: err: Could not retrieve catalog from remote server: certificate verify failed warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run If I do a puppetca --list --all on the puppetmaster, the server is registered with a mac address. Just curious has anyone seen this and how to resolve? Thanks -- 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] pupet dashboard taking more than 10 minutes to destroy a node
Hi all, I've noticed that puppet-dashboard takes a lot of time to refresh some webs, but today, I've started to remove some old nodes and it takes more than 10 minutes to remove one. The host hasn't a really high load: [root@puppet01 ~]# uptime 16:54:31 up 14 days, 5:17, 1 user, load average: 1.67, 1.48, 1.08 [root@puppet01 ~]# free -m total used free sharedbuffers cached Mem: 2026 1890136 0 4266 # grep -c ^proc /proc/cpuinfo 2 and, obviously, ruby mysql are eating all the cpu: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 31770 mysql 22 0 138m 28m 4616 S 117.2 1.4 18:42.69 mysqld 5111 root 16 0 861m 839m 2492 S 1.0 41.4 931:05.87 ruby Anyone notices this behaviour? any advice for solving this? puppet-dashboard-1.0.4.tgz TIA, Arnau -- 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] pupet dashboard taking more than 10 minutes to destroy a node
On 24 Mar 2011, at 16:57, Arnau Bria wrote: Hi all, I've noticed that puppet-dashboard takes a lot of time to refresh some webs, but today, I've started to remove some old nodes and it takes more than 10 minutes to remove one. The host hasn't a really high load: [root@puppet01 ~]# uptime 16:54:31 up 14 days, 5:17, 1 user, load average: 1.67, 1.48, 1.08 [root@puppet01 ~]# free -m total used free sharedbuffers cached Mem: 2026 1890136 0 4266 # grep -c ^proc /proc/cpuinfo 2 and, obviously, ruby mysql are eating all the cpu: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 31770 mysql 22 0 138m 28m 4616 S 117.2 1.4 18:42.69 mysqld 5111 root 16 0 861m 839m 2492 S 1.0 41.4 931:05.87 ruby Anyone notices this behaviour? any advice for solving this? Dashboard removes the reports for nodes one by one... This can take a long time with many reports. Solutions : - Delete reports in the db with a delete statement. - run the cleanup rake task for reports as explained on the github page. Regards, Stefan - Zipkid - Goethals puppet-dashboard-1.0.4.tgz TIA, Arnau -- 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] pupet dashboard taking more than 10 minutes to destroy a node
On Thu, 24 Mar 2011 17:06:33 +0100 Stefan Goethals wrote: Dashboard removes the reports for nodes one by one... This can take a long time with many reports. Solutions : - Delete reports in the db with a delete statement. - run the cleanup rake task for reports as explained on the github page. thanks. 'll take a look. Regards, Stefan - Zipkid - Goethals Cheers, Arnau -- 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] err: Could not retrieve catalog from remote server: certificate verify failed
Thanks, Do you mean on the puppetmaster? On Thu, Mar 24, 2011 at 11:22 AM, Sergey Zhuga sergey.zh...@gmail.com wrote: I was fighting with this issue today. Try to use FQDN in 'server' directive. On 24.03.2011 16:50, Mike Franon wrote: So set up new node, ran on the client puppetd --server puppetmaster --waitforcert 60 --test on the puppetmaster itself I ran puppetca --list saw the hostname and then ran: puppetca --sign hostname.domain.com and on the puppet node itself I went back and ran puppetd -tv and get the following error: err: Could not retrieve catalog from remote server: certificate verify failed warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run If I do a puppetca --list --all on the puppetmaster, the server is registered with a mac address. Just curious has anyone seen this and how to resolve? Thanks -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Could not run Puppet configuration client: SIGQUIT
Hi John, thnx you for an answer. I think cron might be a good option. Stefanero On 24 Mrz., 14:03, jcbollinger john.bollin...@stjude.org wrote: On Mar 24, 6:33 am, stefanero stefan...@gmail.com wrote: I need to adjust the runinterval for example, because 30min is way to often when you change something once a month. Naturally you do need to choose a run interval that is appropriate for your situation. Do remember, however, that Puppet is about more than pushing out intentional configuration changes. It is also about *maintaining* your systems' configurations in the state you have declared, in the face of possible alterations arising from other sources. It is also about monitoring, if you so choose. None of that makes 30 minutes any kind of magic interval, but I do encourage you to take the whole picture into account when you choose an interval. Therefor I would have to update the puppet.conf file , and then give the client a restart to take its new config. Well I did another test, took out puppet.conf from the service definition, and changed puppet.conf. The client received an update, but it did not restart itself, so the old configuration was still active. So the client did not check if its config changed or not. Of course I could write a little script, to check when the puppet.conf changed and restart the puppet agent. But this seams to me just a workaround :-/ maybe someone knows a way to accomplish this. Some people trigger regular puppetd runs via cron instead of running puppetd in daemon mode. I think most choose that route for other reasons, but it certainly avoids problems with puppetd recognizing changes to its own configuration. John -- 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] pupet dashboard taking more than 10 minutes to destroy a node
On Mar 24, 2011, at 9:06 AM, Stefan Goethals wrote: Dashboard removes the reports for nodes one by one... This can take a long time with many reports. If this is true (and I have no reason to doubt it), it's Very Bad. I've filed it as a bug: http://projects.puppetlabs.com/issues/6828 If this affects you, please watch the bug. r -- 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] pupet dashboard taking more than 10 minutes to destroy a node
Yes, I'm experiencing the exact same problem when hitting the destroy button. Mysql and ruby1.8 are eating all resources. In my test env I had the agent runinterval set to 600 seconds to get lots of reports and stress the server a little. When I tried to take the node out of service by hitting 'DESTROY' it took ages and I eventually killed the process myself. I keep a close eye on the bug. -- Kind regards Martin Willemsma 2011/3/24 Randall Hansen rand...@puppetlabs.com On Mar 24, 2011, at 9:06 AM, Stefan Goethals wrote: Dashboard removes the reports for nodes one by one... This can take a long time with many reports. If this is true (and I have no reason to doubt it), it's Very Bad. I've filed it as a bug: http://projects.puppetlabs.com/issues/6828 If this affects you, please watch the bug. r -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: [Puppet-dev] ANNOUNCE: Puppet Dashboard 1.1.0 - Release Candidate 1 available!
There were a few very important changes we forgot to highlight in the Dashboard v1.1.0rc1 release notes. 1. Reports will need to be converted to a new schematized format when upgrading (#5459). Rather than just storing reports as serialized YAML in the database as is currently done in v1.0.4, they are now in a set of tables that allows them to be queried more easily and faster. This conversion can be a slow process if you have a long history of reports, so it's not done as part of `rake db:migrate`. Instead, there is a rake task (#5535) that will do the conversion for you, converting newer reports first and able to be resumed if it's interrupted just by rerunning it. `rake reports:schematize` Also worth noting is the `rake reports:prune` task that can prune older reports that you don't care about, which will make this conversion much faster. Run the rake task without arguments to see documentation for how to specify how far back to prune. 2. The new inventory service portion of Dashboard only works if you're running the newest version of Puppet (2.6.7 which is releasing today). On Wed, Mar 16, 2011 at 5:38 PM, Nick Lewis n...@puppetlabs.com wrote: This release addresses a large number of issues and adds lots of new functionality, including: Inventory Service Lookup - The node view page will now retrieve and display the node's facts from the inventory service. - There is a Custom Query page which will search the inventory service for nodes meeting particular conditions. Preliminary documentation for this feature will be available at: https://github.com/puppetlabs/puppet-docs/blob/master/source/guides/inventory_service.markdown Finalized documentation will be available at release time on the main documentation site: http://docs.puppetlabs.com Settings - Many settings may now be specified in config/settings.yml. Copy the config/settings.yml.example (which provides fallback defaults) to get started. - Changing a setting will currently require a server restart to take effect. Inspect Report Handling - Dashboard can now consume and display inspect reports. Filebucket integration - Dashboard can now display file contents and diffs from a specified Puppet filebucket. Lots of UI and speed improvements Better support for reports - Now supports 2.6 reports and inspect reports Preliminary support for user-made plugins Improved Class/Group/Parameter dependency reporting and handling Log rotation This release is available for download at: http://puppetlabs.com/downloads/dashboard/puppet-dashboard-1.1.0rc1.tar.gz See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet#Verifying+Puppet+Downloads Please report feedback via the Puppet Labs Redmine site, using an affected version of 1.1.0rc1: http://projects.puppetlabs.com/projects/dashboard/ v1.1.0rc1 = 1fcfc01 (#6736) Provide Mutex, avoid an error. 95f97fb maint: Move inventory section lower on the node page 8629962 (#4403) Do timezone arithmetic outside of the DB in the Status model 614655c Remove dead code from Status model 849f2de Validate the user supplied daily_run_history_length 118962b (#6656) Inventory service is no longer experimental. 90e0624 (#6601) Inventory search uses the new inventory URL fb55499 (#5711) Change license from GPLv3 to GPLv2 68b335e (#5234) Source of silk icons attributed, per author's license d3d1528 Maint: Moved logic for identifying inspect reports into a callback. c2fe255 Maint: removed bogus comments from _report.html.haml 81b8a04 Maint: Moved elements of the report show view into callbacks. 2b91838 Maint: Moved elements of the node show view into callbacks. cc95431 Maint: Forbid uninstalled plugins from adding themselves to hooks. 169d275 Maint: Add plug-in install and uninstall rake tasks d4d0b00 Maint: removed db/schema.rb 5f6614d Maint: Removed some private methods in the report model that are part of baseline functionality. db663a5 Maint: remove code that belongs in the baseline module. 5be1f0f maint: Added log dir to version control 93857f0 Maint: Add puppet plugins to .gitignore 1197e8a Bug fix: renamed each_hook and find_first_hook to *_callback cbfde3d Remove some forgotten baseline code 2b4f9eb Add some basic hooks for use by future Dashboard plug-ins. c9ff13e Add a registry for creating hooks and callbacks. a40e6c9 Oops: Remove report baseline functionality fd7f799 Rename baseline-diff-report CSS classes and IDs to be expandable-list 161e0da (#6090) Improved auto-selection of specific baseline. 035aa17 (#6072) Moved baseline inspection link underneath Recent Inspections 613a465 (#6095) Render proper error messages when diffing against a baseline that can't be found ea2368f (#6069) Fixed unique ids in the report group diff view. 3426763 maint: Use new factory_girl syntax to improve a test 1862966 maint: Refresh the vendored gem specifications 79a23c9
[Puppet Users] ANNOUNCE: Puppet Dashboard 1.1.0rc3
This rc addresses an issue when using Dashboard 1.1.0rc1 with Puppet 2.6.7rc1 when the Puppet master would have both storedconfigs, and the inventory service enabled. Bug #6791 - Fact lookup for a single node from Dashboard fails when using storeconfigs This is because the active_record terminus that storeconfigs sets as the cache for facts does not properly return the facts' timestamp. Dashboard then tries to parse this missing field and fails with can't dup NilClass. Facts search is unaffected by this. Also, as noted with the rc1 announcement, there were a couple of very important notes we forgot to mention: 1. Reports will need to be converted to a new schematized format when upgrading (#5459). Rather than just storing reports as serialized YAML in the database as is currently done in v1.0.4, they are now in a set of tables that allows them to be queried more easily and faster. This conversion can be a slow process if you have a long history of reports, so it's not done as part of `rake db:migrate`. Instead, there is a rake task (#5535) that will do the conversion for you, converting newer reports first and able to be resumed if it's interrupted just by rerunning it. `rake reports:schematize` Also worth noting is the `rake reports:prune` task that can prune older reports that you don't care about, which will make this conversion much faster. Run the rake task without arguments to see documentation for how to specify how far back to prune. 2. The new inventory service portion of Dashboard only works if you're running the newest version of Puppet (2.6.7 which is releasing today). This release is available for download at: http://puppetlabs.com/downloads/dashboard/puppet-dashboard-1.1.0rc3.tar.gz See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet#Verifying+Puppet+Downloads Please report feedback via the Puppet Labs Redmine site, using an affected version of 1.1.0rc3: http://projects.puppetlabs.com/projects/dashboard/ v1.1.0rc3 = 2d4d3da Updated VERSION for 1.1.0rc3 v1.1.0rc2 = af1a006 (#6835) Handle malformed facts from Puppet 2.6.7 storedconfigs -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] pupet dashboard taking more than 10 minutes to destroy a node
Hi again, I'm cleaning my DB (which was 15GB) following: https://github.com/puppetlabs/puppet-dashboard I did: rake RAILS_ENV=production reports:prune upto=1 unit=wk rake RAILS_ENV=development reports:prune upto=1 unit=wk (It has been running for about 3 months) and after: rake RAILS_ENV=production db:raw:optimize rake RAILS_ENV=development db:raw:optimize It has removed lots of entries, but it's still 15GB. Am I doing something wrong? why is it not decreasing its size? TIA, Arnau -- 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] run stages in puppet 2.6
hello guys,
I am trying to incorporate run stages into my puppet setup. I've been
working with this for a few days and I haven't quite got the hang of
it yet...
When I attempt my puppet run this is the error I see:
[root@chromews21 ~]# puppetd -t
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Duplicate definition: Class[Centos] is already defined; cannot
redefine at /etc/puppet/manifests/nodes.pp:28 on node
chromews21.example.net
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
Which is confusing because I was under the impression that under 2.6
the class / stage relationship basically takes the place of 'include
foo' where foo is a class you want to use.
--
Just to step you through my logic, I define my stages in site.pp (so
that they will be applied everywhere):
import template
import nodes
import classes/*
import groups/*
import users/*
import os/*
# site.pp
file { /etc/sudoers:
owner = root, group = root, mode = 440
}
filebucket { main: server = puppet }
File { backup = main }
stage {os: before = Stage[main]}
stage {repos: before = Stage[main]}
stage {last: require = Stage[main]}
--
This is the relationship I setup in template.pp
node basenode {
case $operatingsystem {
centos: { include centos }
ubuntu: { include ubuntu }
default: { include centos }
}
include baseapps, sshd
}
node default inherits basenode {}
node webserver inherits basenode {
## -- I used to define 'include apache' here
}
node dbserver inherits basenode {
include mysql
}
node mailserver inherits basenode {
include postfix
}
-
And then this is how I define my client that I am working with:
-
node 'chromews21.acadaca.net' inherits webserver { ## -- instead
what I attempt to do is setup the stage relationships here
class {centos: stage = os}
class {yumrepos: stage = repos}
class {baseapps: stage = main}
class {basefiles: stage = main}
class {apache: stage = last}
}
---
So obviously I am not trying to redefine the centos class. I am merely
trying to setup a precedence in terms of how the software is
installed.
Thanks in advance for your help!
--
GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
--
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] ANNOUNCE: Puppet 2.6.7 final!
This release addresses issues with the Puppet 2.6.x series and adds the Inventory Service. Inventory Service: The inventory service is a way to track facts for all nodes. Preliminary documentation can be found here[1], which will be finalized by the time 2.6.7 is released. [1] https://github.com/puppetlabs/puppet-docs/blob/master/source/guides/inventory_service.markdown Bug #5073: Plugin sync works when using tags This fixes a regression from 0.25.x Bug #4922: Now 404s just cause a normal failure without affecting the file Bug #5428: Upgrading from 0.25.x caused problems with the data format that storeconfigs used, and previously you had to delete your old storeconfigs data to work with 2.6.x. 2.6.7 can now work with the old storeconfigs data. You can find the full release notes for Puppet at: https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes This release is available for download at: http://puppetlabs.com/downloads/puppet/puppet-2.6.7.tar.gz See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet Please report feedback via the Puppet Labs Redmine site, using an affected version of 2.6.7: http://projects.puppetlabs.com/projects/puppet/ CHANGELOG: 2.6.7 = 17f673d Updated CHANGELOG for 2.6.7rc1 852fb97 (#5073) Download plugins even if you're filtering on tags 4f34dbf Fix #5610: Prevent unnecessary RAL lookups 9781032 Revert Merge branch 'ticket/2.6.x/5605' of git://github.com/stschulte/puppet into 2.6.next 25926d1 (#6723) Fix withenv environment restoration bug 093f162 (#6689) Remove extraneous include of Puppet::Util in InventoryActiveRecord 4c19299 Remove extra trailing whitespace from lib/puppet/resource.rb ff9e242 (#5428) More fully stub Puppet::Resource::Reference for use with storedconfigs 0262633 (#6707) Fix typo in rest_authconfig.rb 8858e40 (#6689) Make inventory_active_record terminus search quickly 285c4cc (#5392) Give a better error when realizing a non-existant resource cd5deda (#2645) Adding a less-stubby test to verify the system attribute's behavior 531e258 maint: Remove serialization of InventoryFact values 3489412 maint: Rename InventoryHost to InventoryNode 4bd5493 Fixed #2645 - Added support for creating system users a3f2357 maint: Remove spec run noise 7764412 maint:Refactor of mount provider integration tests 880d0c6 (#6338) Support searching on metadata in InventoryActiveRecord terminus f836366 (#6338) Implement search for InventoryActiveRecord facts terminus 8ce30c8 (#6338) Add an InventoryActiveRecord terminus for Facts 1ef83cb Added integration tests for the mount provider 64440e5 (#6513) Propagate the environment when doing variable lookup in settings 92dffb2 (#6513) Adjust P::U::Settings test name to reflect what it tests 5ef1031 (#6632) Adding a new mount no longer causes error with umount bd5517d Adjust Darwin mount provider tests to pass on Linux 9d2fceb Maint: Begin adding integration tests for the mount provider 23d1c03 Maint: Added the ability to replace the behavior of Puppet::Util.execute with an arbitrary code block for ease in spec testing. 455a891 (#5794) create reports directory when creating host specific directory 1b1e803 (5724) Prep for deprecation of DESTDIR f4a0af1 Refactoring duplicate code and logic in prep for DESTDIR deprecation. 7a00d6b (#6606) Inline docs: Document all autorequire relationships e3aec14 (#5148) Fix failing spec due to timezone 8bd80a9 (#5148) Add support for PSON to facts c3baa28 (#6338) Remove inventory indirection, and move to facts indirection 6c53eb3 (#6445) Fix inline docs: puppet agent does not accept --mkusers 4e29f43 (#6541) maint: whitespace cleanup on the file integration spec b907ba3 (#6541) Fix content with checksum truncation bug 422399b (#5466) Write specs for output of puppet resource 8cc390c (#5466) Monkey patch Symbol so that you can sort them 24eacb7 (#5466) Fixed puppet resource bug with trailing , 743e039 (#4922) Don't truncate remotely-sourced files on 404 bb69011 (#6338) Remove unused version control tags e2a5085 Maint: Align tabs in a code block in the Augeas type. 65a5496 (#6509) Inline docs: Fix erroneous code block in directoryservice provider for computer type ea9f1f0 Maint: Rewrite comments about symlinks to reflect best practice. 94f8ead (#6509) Inline docs: Fix broken lists in Launchd provider. c80a77d (#6509) Inline docs: Fix broken code blocks in zpool type 27863c3 (#6509) Inline docs: Fix code blocks in service type. f4034f7 (#6509) Inline docs: fix broken code blocks in schedule.rb. 6f6c4b5 (#6509) Inline docs: Fix broken code block in file type (content attribute) a949a83 Revert (#6309) Ensure the correct device is mounted when managing mounts 23a510a (#4914) Improved stubbing in mount/parsed_spec tests. ac2262d (#3999) Allow disabling of default SELinux context detection for files 23eb77d (#6322) --noop should not suppress error codes 439115e (#6499) Make puppet respond
Re: [Puppet Users] pupet dashboard taking more than 10 minutes to destroy a node
On 03/24/2011 06:32 PM, Arnau Bria wrote: Hi again, I'm cleaning my DB (which was 15GB) following: https://github.com/puppetlabs/puppet-dashboard I did: rake RAILS_ENV=production reports:prune upto=1 unit=wk rake RAILS_ENV=development reports:prune upto=1 unit=wk (It has been running for about 3 months) and after: rake RAILS_ENV=production db:raw:optimize rake RAILS_ENV=development db:raw:optimize It has removed lots of entries, but it's still 15GB. Am I doing something wrong? why is it not decreasing its size? TIA, Arnau This is because the dashboard uses InnoDB tables. You'll probably have a huge `ibdata` file in /var/lib/mysql/ somewhere. It's a known bug but the `ibdata` file grows but doesn't shrink. http://bugs.mysql.com/bug.php?id=1341 I'd suggest making MySQL use a different file per *.ibd file as it makes it easier to see which table is the culprit. From there you should be able to figure out a way to have the files re-created once you've pruned them (albeit no good way that I know of). http://dev.mysql.com/doc/refman/5.0/en/innodb-multiple-tablespaces.html -- Cody Robertson 1-800-859-8803 ext. 5 -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: puppet-dashboard 1.1.0rc1 - how to enable facts and inventory?
disregard, didn't know I needed 2.6.7rc1 cheers -- 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] Looking for a Linux sysadmin in Chicago
Hello all, Backstop Solutions Group is looking for a Linux System Administrator to work in our downtown Chicago office running our production environment along with some dev and QA space. We're buzzword compliant (SaaS products, some Ruby on Rails, etc), pretty DevOps-y (getting more so all the time) and won't make you do Windows unless you want to. We run Puppet for our automation, Oracle for our databases, and CentOS/RHEL for our servers. We're small enough that you can know everyone by name, even the sales people, but large enough that you don't have to buy your own furniture. I'll save you the full pitch. If you're interested, come take a look at http://www.backstopsolutions.com/company/jobs/sys_admin.shtml . We've got a big-HR system to apply to, but don't let that scare you off: I'll personally read your resume if it comes through there. I'm the manager of the position so please email me any questions you have. Thanks! Feel free, of course, to forward this to any of your friends who could use something new to do. I'll buy you a beer or two if you refer someone good :) (Our friendly hosts said this was ok to post here. Thanks guys!) -- Bill Weiss Backstop Solutions Group -- 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] run stages in puppet 2.6
On Fri, Mar 25, 2011 at 9:36 AM, Tim Dunphy bluethu...@gmail.com wrote:
hello guys,
I am trying to incorporate run stages into my puppet setup. I've been
working with this for a few days and I haven't quite got the hang of
it yet...
When I attempt my puppet run this is the error I see:
[root@chromews21 ~]# puppetd -t
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Duplicate definition: Class[Centos] is already defined; cannot
redefine at /etc/puppet/manifests/nodes.pp:28 on node
chromews21.example.net
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
Which is confusing because I was under the impression that under 2.6
the class / stage relationship basically takes the place of 'include
foo' where foo is a class you want to use.
--
Just to step you through my logic, I define my stages in site.pp (so
that they will be applied everywhere):
import template
import nodes
import classes/*
import groups/*
import users/*
import os/*
# site.pp
file { /etc/sudoers:
owner = root, group = root, mode = 440
}
filebucket { main: server = puppet }
File { backup = main }
stage {os: before = Stage[main]}
stage {repos: before = Stage[main]}
stage {last: require = Stage[main]}
--
This is the relationship I setup in template.pp
node basenode {
case $operatingsystem {
centos: { include centos }
ubuntu: { include ubuntu }
default: { include centos }
}
include baseapps, sshd
}
node default inherits basenode {}
node webserver inherits basenode {
## -- I used to define 'include apache' here
}
node dbserver inherits basenode {
include mysql
}
node mailserver inherits basenode {
include postfix
}
-
And then this is how I define my client that I am working with:
-
node 'chromews21.acadaca.net' inherits webserver { ## -- instead
what I attempt to do is setup the stage relationships here
class {centos: stage = os}
class {yumrepos: stage = repos}
class {baseapps: stage = main}
class {basefiles: stage = main}
class {apache: stage = last}
}
class is not a resource, you can not inherit and override the stage
attribute after you declared include centos. You need to define the
stage on declaration. so specify class {centos: stage = 'os'} in
basenode, or do not inherit webserver for the test node.
Thanks,
Nan
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: WEBrick, Passenger or Mongrel
I would suggest using Passenger. I am using CentOS 5.5 and the setup is as follows: Configure EPEL yum repository http://dev.antoinesolutions.com/epel-repository for the RPM installer, or you can manually create an epel.repo file in /etc/yum.repos.d After the EPEL yum repo is set up run: yum -y install rubygems ruby-devel httpd-devel curl-devel zlib-devel gcc-devel openssl-devel mod_ssl (This should also install any dependencies you need) Install facter, puppet, rack and passenger: gem install facter gem install puppet gem install rack gem install passenger My versions of each are: facter 1.5.8 puppet 2.6.6 rack 1.0.0 passenger 3.0.5 After you have installed your gems run: passenger-install-apache2-module and follow the instructions on screen After this step you can just finish following the instructions found here: http://projects.puppetlabs.com/projects/1/wiki/Using_Passenger Hope this helps. On Mar 23, 11:25 am, hyzhang hyzh...@jcvi.org wrote: Hi, My organization is going to set up puppet soon. We have thousands servers and desktops. Would WEBrick work well for this? Or should we use Passenger? Thanks, Haiyan -- 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] pupet dashboard taking more than 10 minutes to destroy a node
On 03/24/2011 06:49 PM, Cody Robertson wrote: On 03/24/2011 06:32 PM, Arnau Bria wrote: Hi again, I'm cleaning my DB (which was 15GB) following: https://github.com/puppetlabs/puppet-dashboard I did: rake RAILS_ENV=production reports:prune upto=1 unit=wk rake RAILS_ENV=development reports:prune upto=1 unit=wk (It has been running for about 3 months) and after: rake RAILS_ENV=production db:raw:optimize rake RAILS_ENV=development db:raw:optimize It has removed lots of entries, but it's still 15GB. Am I doing something wrong? why is it not decreasing its size? TIA, Arnau This is because the dashboard uses InnoDB tables. You'll probably have a huge `ibdata` file in /var/lib/mysql/ somewhere. It's a known bug but the `ibdata` file grows but doesn't shrink. http://bugs.mysql.com/bug.php?id=1341 I'd suggest making MySQL use a different file per *.ibd file as it makes it easier to see which table is the culprit. From there you should be able to figure out a way to have the files re-created once you've pruned them (albeit no good way that I know of). http://dev.mysql.com/doc/refman/5.0/en/innodb-multiple-tablespaces.html Just to clarify - InnoDB should re-use that space in the ibdata file until it needs more at which point it'll increase the size. This is why it's important to run the cleanup jobs fairly frequently. You can also set the max size of the files I believe. Here's some information (it looks like they mention a procedure to shrink existing ibdata files that aren't fully used as well): http://dev.mysql.com/doc/refman/5.0/en/innodb-data-log-reconfiguration.html -- Cody Robertson 1-800-859-8803 ext. 5 -- 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] pupet dashboard taking more than 10 minutes to destroy a node
Hi Cody, Thanks for both replies! tomorrow morning I'll take a look to links. Cheers, Arnau -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: [Puppet-dev] ANNOUNCE: Puppet 2.6.7 final!
On Thu, Mar 24, 2011 at 5:10 PM, Thomas S Hatch thatc...@gmail.com wrote: These accelerated releases are going to keep us on our toes! This is the downside of monthly releases, particularly when we have an extra, out of cycle release like we did for 2.6.6. If there's anything we can do in the Puppet community to make it easier for the package maintainers, please let us know. We love our Linux distro folks, as Puppet being easy to get installed on distros is This includes help with automating the packaging itself or anything associated. If it would be useful for us to implement a generic system like Debian watch[1] that all the maintainers can use to automatically kick off the package building process, please let us know and we can all brainstorm on something. http://wiki.debian.org/debian/watch/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: [Puppet-dev] ANNOUNCE: Puppet 2.6.7 final!
Jacob Helwig wrote: This release addresses issues with the Puppet 2.6.x series and adds the Inventory Service. For those using Fedora or RHEL/CentOS, I've updated the yum repos at: http://tmz.fedorapeople.org/repo/puppet/ Packages for EL 4 - 6 and Fedora 13 - 15 are available for testing. Add the puppet.repo file from either the epel or fedora directories to /etc/yum.repos.d to enable. If you find problems with the packaging, please let me know. If you find other bugs, please file them in redmine: http://projects.puppetlabs.com/projects/puppet/issues Please note that 2.6.6 is in Fedora and EPEL testing repositories. I don't plan to update puppet there until 2.6.6 is pushed to the stable updates repos in a few weeks. Any help testing the 2.6.6 packages is most welcome. Once that update is stable, we'll be better able to more closely track the 2.6.x updates in the official repos. Also worth noting is that I have no plans to update the official EL-4 repos with 2.6. EL-4 is nearing its EOL and such an update seems more likely to cause unneeded pain for little gain. I will keep updating the EL-4 packages in my fedorapeople repos though, for anyone using EL-4 _and_ wanting the latest packages (you poor, confused souls ;). -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ The urge to save humanity is almost always a false front for the urge to rule. -- H. L. Mencken pgp2nnFy5tzKw.pgp Description: PGP signature
Re: [Puppet Users] Re: [Puppet-dev] ANNOUNCE: Puppet 2.6.7 final!
On 25 March 2011 11:42, Nigel Kersten ni...@puppetlabs.com wrote: On Thu, Mar 24, 2011 at 5:10 PM, Thomas S Hatch thatc...@gmail.comwrote: These accelerated releases are going to keep us on our toes! This is the downside of monthly releases, particularly when we have an extra, out of cycle release like we did for 2.6.6. Also an issue for those of us that don't run mainstream (Solaris :-) systems where edge case changes may not be tested. I haven't had time in th epast weeks to test the release candidates, but downloaded 2.6.7 just now and found massive changes in the mount provider failing on /tmp. Bug to be filed John -- 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] Testing changes before deployment
* hai wu [2011-03-20]: I am interested in the details using cucumber-puppet to verify catalog compilation. Could you please elaborate on it? I setup a catalog policy that applies to all catalogs, by specifying a scenario for each of our servers like so: @node Given a node specified by $nodefact When I compile its catalog Then compilation should succeed And all resource dependencies should resolve And all files should require their owner And all services should have a nagios check And all websites should have a nagios check ... As the scenarios are almost identical, I generate the policy from a script. When someone pushes a change, our CI server runs the complete test suite to verify all server catalogs. We use tagged scenarios, so that I can run a single relevant scenario (aka verify a specific node's catalog) when making changes to a node specific module. If you have many identical servers, you probably just want to verify the catalog for each kind of server. cheers, Nikolay -- 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] mount tmpfs on Solaris fail with 2.6.7
Apologies - I haven't had time to test the release candidates. This is a kicker for us, as I want to start using the new features from the dashboard inventory in 2.6.7 https://projects.puppetlabs.com/issues/6845 John -- 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.
