[Puppet Users] Problem installing kernel from backports
Hi,
I am having problems installing a kernel from backports on Debian Wheezy with
Puppet 3.7.4
I am using puppetlabs/apt to manage Debian repositories and have the following
code for my note
notice(getting kernel from backports...)
apt::force { 'linux-image-amd64':
release = 'wheezy-backports',
cfg_files = 'unchanged',
cfg_missing = true,
require = Apt::Source['Debian_Backports'],
} -
package { 'linux-image-amd64':
ensure = 'latest',
}
The notice is reached, but the kernel-package is not touched and stays at the
main Debian version
The Apt repositoriy is declared elsewhere as
apt::source { 'Debian_Backports':
comment = 'This is the Debian Backports mirror',
location = 'http://ftp.de.debian.org/debian',
release = 'wheezy-backports',
repos = 'main contrib non-free',
pin = '200',
include_src = false,
include_deb = true,
}
The source file is present and apt-show-versions gives me the kernel from
backports I want to get. apt-get update is executed.
I do not see the problem. Could anypne pls help me out???
Thanks in advance
Jochen
--
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/F070CF8B-1A71-43FC-B9FC-2440B5AF88B7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Bug #15326] (Accepted) Scheduled_task does not accept domain user accounts
Hi,
When i add the user attribute to Scheduled_task, the scheduled task is not
created, but if i comment out the user attribute the scheduled task is
created running as system.
This doesn't seem to work
scheduled_task { 'CopyCF11ReposFromDR':
ensure = present,
enabled= true,
command = 'D:\bin\Schedules\CopyCF11ReposFromDR.bat',
working_dir = 'D:\bin\Schedules',
user = 'MYDOMAIN\puppet-user',
arguments= ' D:\bin\Schedules\CopyCF11ReposFromDR_LOG.txt',
require = File['D:\bin\Schedules\CopyCF11ReposFromDR.bat']
}
I am using puppet master version 3.7.4 and windows agent version 3.7.4 on
Windows server 2012 R2.
I see this bug has been reported as
fixed https://projects.puppetlabs.com/issues/15326
--
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/17b6bf14-5a4a-4122-96fa-40703ab7c916%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] multiple Puppet masters with Foreman -- 'sproke
What it looks like to me is going on is the YML file for the host ends up
on the Remote Master (which I can verify by looking for it) and the node.rb
is running on the Grand Master. Since the YML files isn't on the Grand
Master the lookup (of course) fails. So the real question is can we make
the YML file go to the Grand Master.
To that end I played with a couple of settings
Here is a partial dump of what I have in the puppet.conf file for the
Remote Master:
[master]
storeconfigs = true
storeconfigs_backend = puppetdb
inventory_server =Grand Master FQDN
autosign = $confdir/autosign.conf { mode = 664 }
reports= foreman
external_nodes = /etc/puppet/node.rb
node_terminus = exec
I found a reference to an inventory server in the Puppet docs but that
seems to have had no effect on the problem. What I'm wondering about is
the external_node and node_terminus settings. Are those correct for
what I'm trying to do or should that be something else?
On Tue Feb 24 2015 at 9:04:45 AM David Schmitt da...@dasz.at wrote:
Hi Peter,
you might be running into http://projects.theforeman.org/issues/5925 .
I'm wondering whether subsequent runs work.
Also, the node.rb will run on the remote client's puppet master, so,
probably your Remote Master. Since the default node.rb from foreman
requires this yaml file, it'll not work on your Grand Master unless
the agent has tried to contact that one too.
Regards, David
On 2015-02-24 14:45, Peter Berghold wrote:
Using crude ascii art, here is what I have set up so far in my lab..
[Foreman/Puppet Grand Master] -- foreman-proxy
here
^
|
V
[Puppet Remote Master] -- foreman-proxy
running here.
^
|
V
[Simulated Remote Client]
The Foreman/Puppet Grand Master seem to be working swimmingly so far.
The Remote Master is getting its directions from the Grand Master. So
far so good.
Add the client and things start getting sideways. When I run the Puppet
agent on the remote client I get an error such that:
Error: Could not retrieve catalog from remote server: Error 400 on
SERVER: Failed when searching for node FQDN: Failed to find FQDN via
exec: Execution of '/etc/puppet/node.rb FQDN' returned 1:
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
I went over to the Grand Master and ran the /etc/puppet/node.rb from the
command line and it complains that it cannot find the yaml file in its
proper place. OK so I went over to the remote master and sure enough it
was there.
Needless to say Foreman has no idea the host is there.
What's the right electric acid Kool Aid foo to make this work
correctly? It would seem the YAML file needs to be on the Grand Master
and not the remote master... or does it? Is there a way the
foreman-proxy can help here?
--
Peter L. Berghold salty.cowd...@gmail.com mailto:Salty.Cowdawg@gmail.
com
h http://blog.berghold.netttp://science-fiction.berghold.net
http://science-fiction.berghold.net
--
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
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAArvnv2Hnia87teGgq8Wt%
3DpzSJOvUTgesHH1F7mkvFy1WTsGFA%40mail.gmail.com
https://groups.google.com/d/msgid/puppet-users/CAArvnv2Hnia87teGgq8Wt%
3DpzSJOvUTgesHH1F7mkvFy1WTsGFA%40mail.gmail.com?utm_medium=
emailutm_source=footer.
For more options, visit https://groups.google.com/d/optout.
--
* Always looking for people I can help with awesome projects *
Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt
--
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/54EC84DD.8090400%40dasz.at.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
Re: [Puppet Users] Update package (latest) only if installed in Debian
On 2015-02-24 16:28, Ximena Cardinali wrote:
Hello There,
I'm trying to write a module to update certain vulnerable packages in
Debian Systems.
My idea is to update them only and only if they are *installed*. Is
there any exec command or any other tricks that you may know to do that?
So far, I've got the basics: :$
package { '$package_update':
name= $package_update,
ensure = latest,
}
Can anyone throw me an idea? I will really appreciate it!
What about aptitude full-upgrade?
Regards, David
--
* Always looking for people I can help with awesome projects *
Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt
--
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/54EC9BF2.4090703%40dasz.at.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Bug #15326] (Accepted) Scheduled_task does not accept domain user accounts
On Tuesday, February 24, 2015, Helen Paterson helen.pater...@gmail.com
wrote:
Hi,
When i add the user attribute to Scheduled_task, the scheduled task is not
created, but if i comment out the user attribute the scheduled task is
created running as system.
This doesn't seem to work
scheduled_task { 'CopyCF11ReposFromDR':
ensure = present,
enabled= true,
command = 'D:\bin\Schedules\CopyCF11ReposFromDR.bat',
working_dir = 'D:\bin\Schedules',
user = 'MYDOMAIN\puppet-user',
arguments= ' D:\bin\Schedules\CopyCF11ReposFromDR_LOG.txt',
require = File['D:\bin\Schedules\CopyCF11ReposFromDR.bat']
}
You'll need to specify the puppet-user's password if you don't use
the LocalSystem account.
I am using puppet master version 3.7.4 and windows agent version 3.7.4 on
Windows server 2012 R2.
I see this bug has been reported as fixed
https://projects.puppetlabs.com/issues/15326
--
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
javascript:_e(%7B%7D,'cvml','puppet-users%2bunsubscr...@googlegroups.com');
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/17b6bf14-5a4a-4122-96fa-40703ab7c916%40googlegroups.com
https://groups.google.com/d/msgid/puppet-users/17b6bf14-5a4a-4122-96fa-40703ab7c916%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
Josh Cooper
Developer, Puppet Labs
*Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *
http://2015.puppetconf.com.
*Register early to save 40%!*
--
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/CA%2Bu97um8k%3DjFEfZZ9GD2krteqrsMy%3DcBOV6EuVG3nrbxQWbMtw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Bug #15326] (Accepted) Scheduled_task does not accept domain user accounts
thank you, completely missed it.
On Tuesday, February 24, 2015 at 3:06:34 PM UTC, Josh Cooper wrote:
On Tuesday, February 24, 2015, Helen Paterson helen.p...@gmail.com
javascript: wrote:
Hi,
When i add the user attribute to Scheduled_task, the scheduled task is
not created, but if i comment out the user attribute the scheduled task is
created running as system.
This doesn't seem to work
scheduled_task { 'CopyCF11ReposFromDR':
ensure = present,
enabled= true,
command = 'D:\bin\Schedules\CopyCF11ReposFromDR.bat',
working_dir = 'D:\bin\Schedules',
user = 'MYDOMAIN\puppet-user',
arguments= ' D:\bin\Schedules\CopyCF11ReposFromDR_LOG.txt',
require = File['D:\bin\Schedules\CopyCF11ReposFromDR.bat']
}
You'll need to specify the puppet-user's password if you don't use
the LocalSystem account.
I am using puppet master version 3.7.4 and windows agent version 3.7.4 on
Windows server 2012 R2.
I see this bug has been reported as fixed
https://projects.puppetlabs.com/issues/15326
--
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/17b6bf14-5a4a-4122-96fa-40703ab7c916%40googlegroups.com
https://groups.google.com/d/msgid/puppet-users/17b6bf14-5a4a-4122-96fa-40703ab7c916%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
Josh Cooper
Developer, Puppet Labs
*Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *
http://2015.puppetconf.com.
*Register early to save 40%!*
--
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/3b0f1ac1-e6d0-4ea6-a26a-cb661590e83c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Update package (latest) only if installed in Debian
Hello There,
I'm trying to write a module to update certain vulnerable packages in
Debian Systems.
My idea is to update them only and only if they are *installed*. Is there
any exec command or any other tricks that you may know to do that?
So far, I've got the basics: :$
package { '$package_update':
name= $package_update,
ensure = latest,
}
Can anyone throw me an idea? I will really appreciate it!
Cheers,
Ximena.
--
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/d31b5644-478e-4d83-8606-6086479da507%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] multiple Puppet masters with Foreman -- 'sproke
On 2015-02-24 16:09, Peter Berghold wrote:
What it looks like to me is going on is the YML file for the host ends
up on the Remote Master (which I can verify by looking for it) and the
node.rb is running on the Grand Master. Since the YML files isn't on the
Grand Master the lookup (of course) fails. So the real question is can
we make the YML file go to the Grand Master.
To that end I played with a couple of settings
Here is a partial dump of what I have in the puppet.conf file for the
Remote Master:
[master]
storeconfigs = true
storeconfigs_backend = puppetdb
inventory_server =Grand Master FQDN
autosign = $confdir/autosign.conf { mode = 664 }
reports= foreman
external_nodes = /etc/puppet/node.rb
node_terminus = exec
I found a reference to an inventory server in the Puppet docs but that
seems to have had no effect on the problem. What I'm wondering about is
the external_node and node_terminus settings. Are those correct for
what I'm trying to do or should that be something else?
Those are correct and will cause this process to locally (on the master)
execute the node.rb to receive ENC information.
Please re-test whether running node.rb on the master having the right
YML file still fails.
Regards, David
On Tue Feb 24 2015 at 9:04:45 AM David Schmitt da...@dasz.at
mailto:da...@dasz.at wrote:
Hi Peter,
you might be running into
http://projects.theforeman.__org/issues/5925
http://projects.theforeman.org/issues/5925 .
I'm wondering whether subsequent runs work.
Also, the node.rb will run on the remote client's puppet master, so,
probably your Remote Master. Since the default node.rb from foreman
requires this yaml file, it'll not work on your Grand Master unless
the agent has tried to contact that one too.
Regards, David
On 2015-02-24 14:45, Peter Berghold wrote:
Using crude ascii art, here is what I have set up so far in my lab..
[Foreman/Puppet Grand Master] --
foreman-proxy here
^
|
V
[Puppet Remote Master] -- foreman-proxy
running here.
^
|
V
[Simulated Remote Client]
The Foreman/Puppet Grand Master seem to be working swimmingly so far.
The Remote Master is getting its directions from the Grand
Master. So
far so good.
Add the client and things start getting sideways. When I run the
Puppet
agent on the remote client I get an error such that:
Error: Could not retrieve catalog from remote server: Error 400 on
SERVER: Failed when searching for node FQDN: Failed to find FQDN via
exec: Execution of '/etc/puppet/node.rb FQDN' returned 1:
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
I went over to the Grand Master and ran the /etc/puppet/node.rb
from the
command line and it complains that it cannot find the yaml file
in its
proper place. OK so I went over to the remote master and sure
enough it
was there.
Needless to say Foreman has no idea the host is there.
What's the right electric acid Kool Aid foo to make this work
correctly? It would seem the YAML file needs to be on the Grand
Master
and not the remote master... or does it? Is there a way the
foreman-proxy can help here?
--
Peter L. Berghold salty.cowd...@gmail.com
mailto:salty.cowd...@gmail.com mailto:Salty.Cowdawg@gmail.__com
mailto:salty.cowd...@gmail.com
h http://blog.berghold.netttp:__//science-fiction.berghold.net
http://science-fiction.berghold.net
http://science-fiction.__berghold.net
http://science-fiction.berghold.net
--
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+unsubscribe@__googlegroups.com
mailto:puppet-users%2bunsubscr...@googlegroups.com
mailto:puppet-users+__unsubscr...@googlegroups.com
mailto:puppet-users%2bunsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/__msgid/puppet-users/__CAArvnv2Hnia87teGgq8Wt%__3DpzSJOvUTgesHH1F7mkvFy1WTsGFA__%40mail.gmail.com
https://groups.google.com/d/msgid/puppet-users/CAArvnv2Hnia87teGgq8Wt%3DpzSJOvUTgesHH1F7mkvFy1WTsGFA%40mail.gmail.com
Re: [Puppet Users] Update package (latest) only if installed in Debian
I just want to upgrade specific Packages.
The idea is something like : ensure=latest, onlyif=present
Cheers,
Ximena.
On Tuesday, 24 February 2015 16:43:06 UTC+1, David Schmitt wrote:
On 2015-02-24 16:28, Ximena Cardinali wrote:
Hello There,
I'm trying to write a module to update certain vulnerable packages in
Debian Systems.
My idea is to update them only and only if they are *installed*. Is
there any exec command or any other tricks that you may know to do that?
So far, I've got the basics: :$
package { '$package_update':
name= $package_update,
ensure = latest,
}
Can anyone throw me an idea? I will really appreciate it!
What about aptitude full-upgrade?
Regards, David
--
* Always looking for people I can help with awesome projects *
Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt
--
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/72682c9d-5194-4cf9-9b65-729eebd77645%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Creating the user account on puppet agent
On Tuesday, February 24, 2015 at 1:08:17 AM UTC-6, Raj Raju wrote:
Hi,
I am tried to creating the user account on puppet agent.puppet agent is
not reflecting my changes.
Edited */etc/puppetlabs/puppet*/*manifests/site.pp* file as follows:
node 'puppet.client.net' {
include user
}
Edited */etc/puppetlabs/puppet/**manifests/**init.pp* file as follows:
class user {
user { 'hellboy':
ensure = present,
comment = 'user',
home = '/home/hellboy',
managehome = true
}
}
First off, it's unclear on which machine you made those changes. Since you
are using the agent, the manifests that are effective are those on the
machine that serves as master. That can be the same machine on which you
are running the agent, but typically it is not.
Secondly, a class named user should be defined in a manifest file puppet
base/modules/user/manifests/init.pp. It appear that you are attempting to
put yours in puppet base/manifests/init.pp. Under some circumstances
that might nevertheless work, but you should get started on the right foot
to avoid making a mess that you will later need to clean up.
Note: I'm assuming that /etc/puppetlabs/puppet is the correct Puppet base
directory (confdir) for your installation. That's one of the usual
choices, but not the default.
After that I have run below command on puppet agent
[root@puppet ~]# puppet agent --test
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Caching catalog for puppet.client.net
Info: Applying configuration version '1424761232'
Notice: Finished catalog run in 3.44 seconds
I suppose you are trying to point out that the log does not mention the
specified user, but is the user in fact present? At default verbosity, the
agent does not report about resources that are already in the correct state.
If the agent is running in daemon mode, then it might have applied your
config change between when you saved your manifest changes on the master,
and when you ran the agent manually. Alternatively, if you created the
user by some other means, or if you previously ran the agent manually, then
that user may have been created. The agent will emit information about
*all* managed resources if you add the --debug option to your command.
If the debug output does not mention your user resource then it follows
that you're not working with the manifests that the master is relying on.
In that case, you might be editing manifests on the agent (and the master
is a different machine).
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/6c9e2918-6595-480f-a3b8-d1d104182260%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] multiple Puppet masters with Foreman -- 'sproke
Using crude ascii art, here is what I have set up so far in my lab.. [Foreman/Puppet Grand Master] -- foreman-proxy here ^ | V [Puppet Remote Master] -- foreman-proxy running here. ^ | V [Simulated Remote Client] The Foreman/Puppet Grand Master seem to be working swimmingly so far. The Remote Master is getting its directions from the Grand Master. So far so good. Add the client and things start getting sideways. When I run the Puppet agent on the remote client I get an error such that: Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed when searching for node FQDN: Failed to find FQDN via exec: Execution of '/etc/puppet/node.rb FQDN' returned 1: Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run I went over to the Grand Master and ran the /etc/puppet/node.rb from the command line and it complains that it cannot find the yaml file in its proper place. OK so I went over to the remote master and sure enough it was there. Needless to say Foreman has no idea the host is there. What's the right electric acid Kool Aid foo to make this work correctly? It would seem the YAML file needs to be on the Grand Master and not the remote master... or does it? Is there a way the foreman-proxy can help here? -- Peter L. Berghold salty.cowd...@gmail.com h http://blog.berghold.netttp://science-fiction.berghold.net -- 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/CAArvnv2Hnia87teGgq8Wt%3DpzSJOvUTgesHH1F7mkvFy1WTsGFA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] multiple Puppet masters with Foreman -- 'sproke
Hi Peter, you might be running into http://projects.theforeman.org/issues/5925 . I'm wondering whether subsequent runs work. Also, the node.rb will run on the remote client's puppet master, so, probably your Remote Master. Since the default node.rb from foreman requires this yaml file, it'll not work on your Grand Master unless the agent has tried to contact that one too. Regards, David On 2015-02-24 14:45, Peter Berghold wrote: Using crude ascii art, here is what I have set up so far in my lab.. [Foreman/Puppet Grand Master] -- foreman-proxy here ^ | V [Puppet Remote Master] -- foreman-proxy running here. ^ | V [Simulated Remote Client] The Foreman/Puppet Grand Master seem to be working swimmingly so far. The Remote Master is getting its directions from the Grand Master. So far so good. Add the client and things start getting sideways. When I run the Puppet agent on the remote client I get an error such that: Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed when searching for node FQDN: Failed to find FQDN via exec: Execution of '/etc/puppet/node.rb FQDN' returned 1: Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run I went over to the Grand Master and ran the /etc/puppet/node.rb from the command line and it complains that it cannot find the yaml file in its proper place. OK so I went over to the remote master and sure enough it was there. Needless to say Foreman has no idea the host is there. What's the right electric acid Kool Aid foo to make this work correctly? It would seem the YAML file needs to be on the Grand Master and not the remote master... or does it? Is there a way the foreman-proxy can help here? -- Peter L. Berghold salty.cowd...@gmail.com mailto:salty.cowd...@gmail.com h http://blog.berghold.netttp://science-fiction.berghold.net http://science-fiction.berghold.net -- 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 mailto:puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAArvnv2Hnia87teGgq8Wt%3DpzSJOvUTgesHH1F7mkvFy1WTsGFA%40mail.gmail.com https://groups.google.com/d/msgid/puppet-users/CAArvnv2Hnia87teGgq8Wt%3DpzSJOvUTgesHH1F7mkvFy1WTsGFA%40mail.gmail.com?utm_medium=emailutm_source=footer. For more options, visit https://groups.google.com/d/optout. -- * Always looking for people I can help with awesome projects * Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt Blog: http://club.black.co.at/log/ LinkedIn: http://at.linkedin.com/in/davidschmitt -- 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/54EC84DD.8090400%40dasz.at. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Update package (latest) only if installed in Debian
Probably the simplest approach would be to write an exec resource using the
command
/usr/bin/apt-get install --only-upgrade package-name
for apt packages.
Charles Yeomans
On Feb 24, 2015, at 10:47 AM, Ximena Cardinali ximenacardin...@gmail.com
wrote:
I just want to upgrade specific Packages.
The idea is something like : ensure=latest, onlyif=present
Cheers,
Ximena.
On Tuesday, 24 February 2015 16:43:06 UTC+1, David Schmitt wrote:
On 2015-02-24 16:28, Ximena Cardinali wrote:
Hello There,
I'm trying to write a module to update certain vulnerable packages in
Debian Systems.
My idea is to update them only and only if they are *installed*. Is
there any exec command or any other tricks that you may know to do that?
So far, I've got the basics: :$
package { '$package_update':
name= $package_update,
ensure = latest,
}
Can anyone throw me an idea? I will really appreciate it!
What about aptitude full-upgrade?
Regards, David
--
* Always looking for people I can help with awesome projects *
Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt
--
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/72682c9d-5194-4cf9-9b65-729eebd77645%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/1CA1A652-88A5-454C-AB34-F5245DC96A85%40dakim.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Puppet Labs will be dropping support for Puppet 2.7 and Puppet Enterprise 2.8
Hello All, Puppet Labs will be dropping support for Puppet 2.7 and Puppet Enterprise 2.8, in the next major release of Puppet Labs modules. Puppet Enterprise 2.8 being the last PE release that included Puppet 2.7. New releases of Puppet Labs modules will drop support for 2.7. While this will happen on a rolling basis, we encourage you to upgrade to a newer version as soon as you are able. The best way to assess what versions a module is compatible with can be found under the Latest version is compatible with section. Apache module example, https://forge.puppetlabs.com/puppetlabs/apache/compatibility. Thank you, Beth Cornils Beth Cornils beth.corn...@puppetlabs.com Product Owner -- 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/61920004-8fbf-43c5-b79e-6de6d7d16c02%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] multiple Puppet masters with Foreman -- 'sproke
FOUND IT!
It was a comedy of errors. The perms on the node.rb script were wrong (not
sure how they got that way, but...) and not only that there was some
residual configuration issues from an experiment I did two weeks ago that
was pointing to the hostname pocforman.domain instead of the FQDN of the
Foreman host which caused a mismatch on the cert names.
Once I got those two things corrected (found out through running the remote
server in debug mode) it all started to work correctly.
on to the next thing... I'm working towards a demo of the
infrastructure second week in March. Will be the go/no go for putting
this in production.
On Tue Feb 24 2015 at 10:41:57 AM David Schmitt da...@dasz.at wrote:
On 2015-02-24 16:09, Peter Berghold wrote:
What it looks like to me is going on is the YML file for the host ends
up on the Remote Master (which I can verify by looking for it) and the
node.rb is running on the Grand Master. Since the YML files isn't on the
Grand Master the lookup (of course) fails. So the real question is can
we make the YML file go to the Grand Master.
To that end I played with a couple of settings
Here is a partial dump of what I have in the puppet.conf file for the
Remote Master:
[master]
storeconfigs = true
storeconfigs_backend = puppetdb
inventory_server =Grand Master FQDN
autosign = $confdir/autosign.conf { mode = 664 }
reports= foreman
external_nodes = /etc/puppet/node.rb
node_terminus = exec
I found a reference to an inventory server in the Puppet docs but that
seems to have had no effect on the problem. What I'm wondering about is
the external_node and node_terminus settings. Are those correct for
what I'm trying to do or should that be something else?
Those are correct and will cause this process to locally (on the master)
execute the node.rb to receive ENC information.
Please re-test whether running node.rb on the master having the right
YML file still fails.
Regards, David
On Tue Feb 24 2015 at 9:04:45 AM David Schmitt da...@dasz.at
mailto:da...@dasz.at wrote:
Hi Peter,
you might be running into
http://projects.theforeman.__org/issues/5925
http://projects.theforeman.org/issues/5925 .
I'm wondering whether subsequent runs work.
Also, the node.rb will run on the remote client's puppet master, so,
probably your Remote Master. Since the default node.rb from foreman
requires this yaml file, it'll not work on your Grand Master unless
the agent has tried to contact that one too.
Regards, David
On 2015-02-24 14:45, Peter Berghold wrote:
Using crude ascii art, here is what I have set up so far in my
lab..
[Foreman/Puppet Grand Master] --
foreman-proxy here
^
|
V
[Puppet Remote Master] -- foreman-proxy
running here.
^
|
V
[Simulated Remote Client]
The Foreman/Puppet Grand Master seem to be working swimmingly so
far.
The Remote Master is getting its directions from the Grand
Master. So
far so good.
Add the client and things start getting sideways. When I run the
Puppet
agent on the remote client I get an error such that:
Error: Could not retrieve catalog from remote server: Error 400 on
SERVER: Failed when searching for node FQDN: Failed to find FQDN
via
exec: Execution of '/etc/puppet/node.rb FQDN' returned 1:
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
I went over to the Grand Master and ran the /etc/puppet/node.rb
from the
command line and it complains that it cannot find the yaml file
in its
proper place. OK so I went over to the remote master and sure
enough it
was there.
Needless to say Foreman has no idea the host is there.
What's the right electric acid Kool Aid foo to make this work
correctly? It would seem the YAML file needs to be on the Grand
Master
and not the remote master... or does it? Is there a way the
foreman-proxy can help here?
--
Peter L. Berghold salty.cowd...@gmail.com
mailto:salty.cowd...@gmail.com mailto:Salty.Cowdawg@gmail.__com
mailto:salty.cowd...@gmail.com
h http://blog.berghold.netttp:__//science-fiction.berghold.net
http://science-fiction.berghold.net
