: 22.38
Config retrieval: 7.82
My question is why is there such a big difference between the time the
whole catalog run took and the time shown in Total. The complete
run definitely takes the 72 seconds and I would like to debug why it takes
so long.
Any ideas?
Thanks,
Kai
--
You received
: keyserver timed out
gpg: keyserver receive failed: keyserver error
This is because the /usr/bin/apt-key command can't connect to the keyserver
without the proxy.
Am Donnerstag, 8. Januar 2015 14:41:21 UTC+1 schrieb jcbollinger:
On Wednesday, January 7, 2015 3:28:30 PM UTC-6, Kai Timmer wrote
because I configure apt to use the proxy and puppet just
calls apt-get).
How do I make the puppet agent use my environment variables?
Thanks,
Kai
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving
clean cert in agent
csv-agent:/etc/puppet # cd /var/lib/puppet/
csv-agent:/var/lib/puppet # ls
client_data client_yaml clientbucket facts lib ssl state
csv-agent:/var/lib/puppet # rm -rf ssl/
rm -rf /var/lib/puppet/ssl/
在 2014年12月22日星期一UTC+8下午2时00分55秒，App Win写道：
Hi All,
We are trying to
That was it, thanks!
On Wednesday, November 12, 2014 2:51:58 PM UTC-6, Christopher Wood wrote:
On Wed, Nov 12, 2014 at 12:43:43PM -0800, kai wrote:
Hi,
I have the following file definitions:
file { $haproxy_service_config_file:
ensure = 'present',
owner
.
Something like this:
package {['puppet', 'puppet-common'],
ensure = $puppetversion,
notify = 'puppet-agent',
}
I'm just curios if that would be a good Idea? Wouldn't this break my
current puppet run?
How do you upgrade your agents? Whats best practise here?
Thanks,
Kai
--
You received
Hello,
I'm using this snippet to build my icinga configuration out of my exported
facts
#Collect the nagios_host resources
Nagios_host || {
target = /etc/icinga/puppet.d/hosts.cfg,
require = File[/etc/icinga/puppet.d/hosts.cfg],
notify = Service[icinga],
}
If I now deactivate
to confusion around this :-).
The node doesn't show up with puppet node exports
But a puppet agent -t run on the icinga node still doesn't remove the node.
Maybe I should say that I am using foreman. But I also deactivated the node
in foreman. So my guess is that I'm good there.
Best regards,
Kai
happens if I manually add a (fake) host to my hosts.cfg file. The host
doesn't exist in the puppetdb, because it was never alive. On the next
puppet run, puppet should remove this false entry in my hosts.cfg, right?
Best Regards,
-- Kai Timmer / em...@kaitimmer.de
--
You received this message
:/
Best regards,
Kai
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https
2014-10-09 17:06 GMT+02:00 Ken Barber k...@puppetlabs.com:
So Kai, you can provide fake this with soft-links to the icigna dir
from the expected nagios configuration directory. Or soft-link the
files themselves, up to you.
Thank you both a lot.
Now the (fake-)host gets removed but for some
I have the following two resources defined in a class:
class openvz::install {
$openvz_repo_key = hiera('openvz_repo_key')
$openvz_repo = hiera('openvz_repo')
$openvz_kernel_image = hiera('openvz_kernel_image')
$openvz_kernel_headers = hiera('openvz_kernel_headers')
apt::source { openvz:
,
require = Apt::Source['openvz'],
}
On Tue, Mar 11, 2014 at 1:13 PM, kai kaiv...@gmail.com javascript:wrote:
I have the following two resources defined in a class:
class openvz::install {
$openvz_repo_key = hiera('openvz_repo_key')
$openvz_repo = hiera('openvz_repo')
$openvz_kernel_image
this problem.
On Wednesday, January 8, 2014 9:38:12 AM UTC-6, jcbollinger wrote:
On Tuesday, January 7, 2014 11:39:14 AM UTC-6, kai wrote:
What version of Puppet are you running?
*3.4.1 for both master and agent*
As what user is the master running? (Typically an unprivileged user
named
What version of Puppet are you running?
*3.4.1 for both master and agent*
As what user is the master running? (Typically an unprivileged user named
'puppet'.)
*The master is running as user puppet*
As what user are you running the agent in your tests?
*I am running the agent and the
.
On Tuesday, January 7, 2014 11:39:14 AM UTC-6, kai wrote:
What version of Puppet are you running?
*3.4.1 for both master and agent*
As what user is the master running? (Typically an unprivileged user
named 'puppet'.)
*The master is running as user puppet*
As what user are you running the agent
.
On Tuesday, January 7, 2014 11:39:14 AM UTC-6, kai wrote:
What version of Puppet are you running?
*3.4.1 for both master and agent*
As what user is the master running? (Typically an unprivileged user
named 'puppet'.)
*The master is running as user puppet*
As what user are you running the agent
, but I was not able to find this
in any of the documentation, so putting it here if someone else encounters
it.
On Monday, January 6, 2014 1:20:04 PM UTC-6, kai wrote:
I have the following hiera.yaml file:
---
:backends:
- yaml
- file
:hierarchy:
- defaults
- %{clientcert
I actually have both variables.
On Tuesday, January 7, 2014 11:54:38 AM UTC-6, Jose Luis Ledesma wrote:
Mmm the error is about ssh_package_name, but you have tried the puppet
apply with ssh_service_name. could be this the problem?
--
You received this message because you are subscribed to
---
:backends:
- yaml
- file
:hierarchy:
- defaults
- %{clientcert}
- %{::domain}/%{::environment}/%{::osfamily}/%{::lsbdistcodename}
- global
:yaml:
:datadir: /etc/puppet/data
On Tuesday, January 7, 2014 12:05:46 PM UTC-6, Andrew wrote:
Content of the yaml file - any quotes
I have the following hiera.yaml file:
---
:backends:
- yaml
- file
:hierarchy:
- defaults
- %{clientcert}
* - %{::domain}/%{::environment}/%{::osfamily}/%{::lsbdistcodename}*
- global
:yaml:
:datadir: /etc/puppet/data
and the following in /etc/puppet/data:
down until you find when it disappears.
Andrey
On 6 January 2014 19:20, kai kaiv...@gmail.com javascript: wrote:
I have the following hiera.yaml file:
---
:backends:
- yaml
- file
:hierarchy:
- defaults
- %{clientcert}
* - %{::domain}/%{::environment}/%{::osfamily
Hm nothing in the logs. It's worth mentioning that I run this on the puppet
master. Here's the config in case I missed something there:
[main]
pluginsync = true
factpath = /lib/facter
[agent]
environment = production
server = puppetmaster.loc.example.com
runinterval = 360
splay = true
I understand that only the CA cert needs to be copied on the LB and not the
private key, as the private key is just for signing the agents
certificates. Just wanted to note that the CA also needs
SSLCARevocationFile, for revocation to work it seems.
The only other concept that is not clear to
Jeff, thank you very much for taking the time to answer all my questions. I
really appreciate it. This thread had helped me a lot in my journey to
mastering Puppet.
Thank you again!
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this
Puppet book, but
on different servers. Now it all works!
On Thursday, June 14, 2012 12:19:20 PM UTC-5, kai wrote:
Puppet version: 2.7.14
Puppet master behind apache with mod_proxy load balancer.
I am able to authenticate with the cert as per these headers:
Accept: s
X-SSL-Subject: /CN
If the LB does not have all the signed agent's certificates, how will it
know which agent is valid. All the signed certs are stored on the CA which
is behind the LB.
I'll try and figure out how to just copy the signed certificate and the
private key associated with that certificate from the CA
I get it now! Since the CA signed the agents cert the LB knows that the
agent cert is valid because the LB has the CA cert and key to validate
with. So, what is the point of the CA storing all the signed agent certs?
--
You received this message because you are subscribed to the Google Groups
I have a single LB running Apache with mod_proxy in front of a Puppet
master. These are the LB and Puppet master configs:
Proxy balancer://puppetmaster
BalancerMember http://192.168.1.10:8140
/Proxy
Listen 8140
VirtualHost *:8140
SSLEngine on
SSLCipherSuite
Puppet version 2.7.14 on Ubuntu.
My puppet master config:
[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
templatedir=$confdir/templates
[master]
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header =
Puppet version: 2.7.14
Puppet master behind apache with mod_proxy load balancer.
I am able to authenticate with the cert as per these headers:
Accept: s
X-SSL-Subject: /CN=puppetagent1.example.com
X-Client-DN: /CN=puppetagent1.example.com
X-Client-Verify: SUCCESS
Any idea what this error means
Nobody an idea?
My actual solution is to send COMMIT; to the MySQL Server and then run
puppet agent --test what leads to Background Tasks - All systems go.
But that can't be The Solution.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To
[pid 4995]
delayed_job: running [pid 5019]
Regards Kai
--
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/-/pM59imDBUlAJ.
To post to this group, send email
Problem is a result of sql_mode = TRADITIONAL. Is there any workaround for
this problem?
--
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/-/icMIbxPhmZoJ.
To
modify the Varnish module I have to backport all the bugfixes and changes
made by the original author. So, how can I install the package from another
source without modifying the original module?
Thanks for your help,
Kai
--
You received this message because you are subscribed to the Google Groups
Hi,
I am looking for real world server setups to learn more from others. The ones
I know of are
The Repository of David Schmitt
http://projects.puppetlabs.com/projects/1/wiki/Complete_Configuration
The Wikimedia Server repository
-the-wikimedia-servers-are-configured/
Regards, Kai
--
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
Right™.
The new facter from git does work correctly. I'll just upgrade.
Sorry for the noise.
On Aug 7, 10:18 am, Kai hashe...@gmail.com wrote:
Hmm. Any nisdomain with a dot does the trick to fool facter it seems.
# domainname uncle.wrinkle.puppy.reductivelabs
# facter fqdn
buildbox2
configuring the box,
and enabling NIS, setting the domainname, it will create a new
certificate, now for mailpop.server.nl.
This is kind of strange I think, shouldn't puppet ignore the NIS
domain it is in?
I'm running puppet 0.24.5 on a debian lenny machine.
Regards,
Kai
, or will it again
formulate its own by putting the NIS domain in it again? :)
Kai
--~--~-~--~~~---~--~~
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
I'm afraid it does. :(
On Aug 6, 4:24 pm, Kai hashe...@gmail.com wrote:
to be safe, use the cert option in your puppet.conf
That will be interesting: that file is supplied by puppet. Will the
hostname in puppet reflect the real hostname, or will it again
formulate its own by putting
41 matches
Mail list logo
