[Puppet Users] exec resource long runtime
Hi,
If I run the following command manually (time /usr/sbin/rhnreg_ks -v
--serverUrl=http://spacewalk.example.com/XMLRPC
--activationkey=1-aab07306b6f673c367ebecae2aa55f22 --force --nohardware
--nopackages --novirtinfo --norhnsd -v), the runtime is 15 seconds.
However, if the command is performed via the exe resource the runtime is
~48 seconds.
Why is the runtime via the exe resource longer?
Is it possible shorten the runtime?
class spacewalk::config inherits spacewalk {
file { '/etc/yum/pluginconf.d/rhnplugin.conf':
ensure => present,
source => 'puppet:///modules/spacewalk/rhnplugin.conf',
owner=> root,
group=> root,
mode => '0644',
before => Exec['register-client'],
}
exec { 'register-client':
command => "/usr/sbin/rhnreg_ks -v
--serverUrl=http://${::spacewalk::spacewalk_server_fqdn}/XMLRPC
--activationkey=${::spacewalk::activation_key} --force --nohardware
--nopackages --novirtinfo --norhnsd -v",
require => Class['spacewalk::install'],
unless => '/usr/sbin/spacewalk-channel -l',
}
}
Info: /Stage[main]/Spacewalk/Spacewalk::Config/Exec[register-client]:
Starting to evaluate the resource
Debug: Exec[register-client](provider=posix): Executing check
'/usr/sbin/spacewalk-channel -l'
Debug: Executing '/usr/sbin/spacewalk-channel -l'
Debug:
/Stage[main]/Spacewalk/Spacewalk::Config/Exec[register-client]/unless:
Unable to locate SystemId file. Is this system registered?
Debug: Exec[register-client](provider=posix): Executing
'/usr/sbin/rhnreg_ks --serverUrl=http://spacewalk.example.com/XMLRPC
--activationkey=1-aab07306b6f673c367ebecae2aa55f22 --force --nohardware
--nopackages --novirtinfo --norhnsd'
Debug: Executing '/usr/sbin/rhnreg_ks
--serverUrl=http://spacewalk.example.com/XMLRPC
--activationkey=1-aab07306b6f673c367ebecae2aa55f22 --force --nohardware
--nopackages --novirtinfo --norhnsd'
Notice:
/Stage[main]/Spacewalk/Spacewalk::Config/Exec[register-client]/returns:
executed successfully
Debug: /Stage[main]/Spacewalk/Spacewalk::Config/Exec[register-client]: The
container Class[Spacewalk::Config] will propagate my refresh event
Info: /Stage[main]/Spacewalk/Spacewalk::Config/Exec[register-client]:
Evaluated in 47.20 seconds
Thank you in advance,
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/e7aa4d1b-3086-4705-ab83-65f2acf85714%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: camptocamp/grundics accounts module
If you still want to use *ssh_authorized_key_title*, you have some examples
in unit tests.
Le vendredi 16 janvier 2015 18:40:06 UTC+1, guymatz a écrit :
>
> Is anyone using camptocamp or grundic's accounts module? I can't it
> working and am at my wit's end!
>
> my problem is with the ssh_authorized_key_title . . . I'm getting the
> error:
> Error 400 on SERVER: stack level too deep at
> /etc/puppet/modules/accounts/manifests/authorized_key.pp:35
>
> But I think I have everything set up correctly:
> In my modules/profiles/manifests/base.pp I have:
> class { 'accounts':
> groups => hiera_hash('accounts::groups', {}),
> ssh_keys => hiera_hash('accounts::ssh_keys', {}),
> users=> hiera_hash('accounts::users', {}),
> usergroups => hiera_hash('accounts::usergroups', {}),
> accounts => hiera_hash('accounts::accounts', {}),
> *ssh_authorized_key_title => '%{ssh_keys[\'%{ssh_key}\'][\'comment\']
> on %{user}',*
> dotfiles => hiera_hash('accounts::dotfiles', {}),
> }
>
> So that should put all of that info into my run, yes? Is there a better
> place to put that?
>
> Then in hiera I have:
> $ more hieradata/common_users.eyaml
> accounts::ssh_keys:
> iambot:
> comment: iambot@somewhere
> type: ssh-dss
> public: public_key
>
> accounts::users:
> iambot:
> uid: 10079
> gid: 10022
> comment: I am a Bot
>
> accounts::groups:
> Staff:
> gid: 10022
>
> It seems that with camptocamp's implementation you then need to call
> accounts::account like this to get the user created:
> accounts::account { 'iambot': }
>
> But with Grundic's it seems you have to add an accounts::account block to
> the yaml above:
> accounts::account:
> iambot:
> groups:
> - Staff
> authorized_keys:
> - iambot
>
> Is that right?
>
> Anyway, I can get around the stack level error by replacing the contents
> of the *ssh_authorized_key_title* with something "static", but would
> prefer to have it as is.
>
> Any ideas? ;-/
>
> Thanks a lot,
> Guy
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/47654e48-2065-4788-a4eb-213711c2fdb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: camptocamp/grundics accounts module
Hi,
There is a missing right brace at the end of the format string:
ssh_authorized_key_title => '%{ssh_keys[\'%{ssh_key}\'][\'comment\'] on
%{user}*}*',
BTW this param is not really useful anymore, we added it so that we can set
the resource title to not have duplicate keys in the .ssh/authorized_keys.
But since puppet 3.6 (IIRC) you can purge unmanaged authorized_keys, so
resource titles does not really matter anymore.
Mickaël
Le vendredi 16 janvier 2015 18:40:06 UTC+1, guymatz a écrit :
>
> Is anyone using camptocamp or grundic's accounts module? I can't it
> working and am at my wit's end!
>
> my problem is with the ssh_authorized_key_title . . . I'm getting the
> error:
> Error 400 on SERVER: stack level too deep at
> /etc/puppet/modules/accounts/manifests/authorized_key.pp:35
>
> But I think I have everything set up correctly:
> In my modules/profiles/manifests/base.pp I have:
> class { 'accounts':
> groups => hiera_hash('accounts::groups', {}),
> ssh_keys => hiera_hash('accounts::ssh_keys', {}),
> users=> hiera_hash('accounts::users', {}),
> usergroups => hiera_hash('accounts::usergroups', {}),
> accounts => hiera_hash('accounts::accounts', {}),
> *ssh_authorized_key_title => '%{ssh_keys[\'%{ssh_key}\'][\'comment\']
> on %{user}',*
> dotfiles => hiera_hash('accounts::dotfiles', {}),
> }
>
> So that should put all of that info into my run, yes? Is there a better
> place to put that?
>
> Then in hiera I have:
> $ more hieradata/common_users.eyaml
> accounts::ssh_keys:
> iambot:
> comment: iambot@somewhere
> type: ssh-dss
> public: public_key
>
> accounts::users:
> iambot:
> uid: 10079
> gid: 10022
> comment: I am a Bot
>
> accounts::groups:
> Staff:
> gid: 10022
>
> It seems that with camptocamp's implementation you then need to call
> accounts::account like this to get the user created:
> accounts::account { 'iambot': }
>
> But with Grundic's it seems you have to add an accounts::account block to
> the yaml above:
> accounts::account:
> iambot:
> groups:
> - Staff
> authorized_keys:
> - iambot
>
> Is that right?
>
> Anyway, I can get around the stack level error by replacing the contents
> of the *ssh_authorized_key_title* with something "static", but would
> prefer to have it as is.
>
> Any ideas? ;-/
>
> Thanks a lot,
> Guy
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/ba92a7f7-6e11-474e-8376-7d4a92673aa2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Resource ordering syntax
Hi,
I have a syntax query, I hope that the group can help with.
When using resource ordering parameters, such as 'before' or 'require', I
can specify the resource on which to act the ordering around. For instance:
exec { 'wget-docker-key':
command => '/usr/bin/wget -qO- https://get.docker.io/gpg |
/usr/bin/apt-key add -',
before => Exec['echo-docker-deb-apt-sources'],
}
exec { 'echo-docker-deb-apt-sources':
command => '/bin/echo deb http://get.docker.io/ubuntu docker main >
/etc/apt/sources.list.d/docker.list',
creates => '/etc/apt/sources.list.d/docker.list',
}
This will ensure that the Docker key is installed on the machine before
create a list of Docker sources for Apt.
In situations where I'm using an array as the resource title, such as this:
package { [
"linux-image-extra-${::kernelrelease}",
'lxc',
'lxc-docker-1.0.0',
]:
ensure => present,
}
How do I reference the resource when using resource ordering? Do I just use
Package['linux-image-extra-${::kernelrelease}",'lxc','lxc-docker-1.0.0']?
Thanks in advance!
--
Andrew Langhorn
Web Operations
Government Digital Service
e: andrew.langh...@digital.cabinet-office.gov.uk
a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CANCa_WZ2Mp7A8PrAEvkK3DuuCks_3ptp1rCByhxxs1r%3DZ31iqQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Node classifiers in PE 3.7
Hi,
Check out this thread in the pe-users group :
https://groups.google.com/a/puppetlabs.com/forum/#!topic/pe-users/k9oEsDEoSqc
I will post a blog soon, but was distracted by other things about this
topic. You can always check johan.koewacht.net.
Grts
Johan
On 17/01/15 00:11, warpig wrote:
Hi All,
I've recently set up a PE 3.7.0 deployment, with the idea of setting
up a basic ENC using Hiera. In order for the environment-specific
manifests to be applied to each agent, I set the environment within
the agent's puppet.conf. Unfortunately, when I run an agent against
the puppetmaster, I get the following warning:
# puppet agent -t --environment=development
Warning: Local environment: "development" doesn't match server
specified node environment "production", switching agent to "production".
Obviously, the classes defined in the "development" environment aren't
applied. My site.pp is a stock, with the exception of the line
"hiera_include('classes')".
It seems from all the documentation that PE would prefer users to do a
lot of pointing and clicking in the dashboard to assign nodes to node
groups. Is there a more automated method without using the dashboard?
It seems the "agent-specified" environment is on it's way out. My
question then is: what is the preferred method of assigning nodes to
environments without using the dashboard?
Cheers!
--
You received this message because you are subscribed to the Google
Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to puppet-users+unsubscr...@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/1bb8aa59-f630-489d-8b6c-7c4a28dbcc33%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
Johan De Wit
Open Source Consultant
Red Hat Certified Engineer (805008667232363)
Puppet Certified Professional 2013/2014 (PCP006)
blog : http://johan.koewacht.net/
_
Open-Future Phone +32 (0)2/255 70 70
Zavelstraat 72 Fax +32 (0)2/255 70 71
3071 KORTENBERG Mobile+32 (0)474/42 40 73
BELGIUM http://www.open-future.be
_
Next Events:
Bacula Administrator 1 |
http://www.open-future.be/bacula-administrator-i-training-13th-till-15th-january
Puppet Fundamentals |
http://www.open-future.be/puppet-fundamentals-training-26th-till-28th-january
Puppet Architect |
http://www.open-future.be/puppet-architect-training-29th-till-30th-january
Linux Training | http://www.open-future.be/linux-training-9th-till-13th-february
Puppet Practitioner |
http://www.open-future.be/puppet-practitioner-training-17th-till-19th-february
Bacula Administrator 1 |
http://www.open-future.be/bacula-administrator-i-training-24th-till-26th-february
Subscribe to our newsletter | http://eepurl.com/BUG8H
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/54BA6318.9000508%40open-future.be.
For more options, visit https://groups.google.com/d/optout.
