Re: [Puppet Users] install vmware tools through puppet
I've done something similar using the open-vm package on debian hosts. On Saturday, September 22, 2012 3:06:10 PM UTC-5, Alan Evans wrote: I believe the open-vm-tools at http://packages.vmware.com/tools are ESX host version agnostic. We pull the rhel 4-6 repos into RHN satellite and just use puppet ensure the latest is installed. If you do t use satellite you could just clone the repo and configure yum on the clients. Packages are available for RHEL, SuSE and deb at least. -Alan On Sep 22, 2012 3:25 PM, Hai Tao eha...@gmail.com javascript: wrote: It is a useful tool. However, the difficulty is that our ENV has multiple versions of ESX hosts, 3.5, 4.1 and 5.0. The guest OS has no clue what version of ESX it is running on, so how can puppet server push a correct version of vmware tools to a client? On Sat, Sep 22, 2012 at 11:20 AM, Michael Stahnke sta...@puppetlabs.com javascript: wrote: On Fri, Sep 21, 2012 at 6:48 PM, Jakov Sosic jso...@srce.hrjavascript: wrote: On 09/19/2012 11:55 PM, Hai Tao wrote: There seems to be a few vmware tools installation modules. Has someone used these modules to install VMware tools? Searching http://forge.puppetlabs.com ... NAMEDESCRIPTION AUTHORKEYWORDS vchoi-vmwarePuppet module to handle installation, upgrade and reconfiguration of vmware tools on vmware virtual nodes. @vchoivirtualization vmware vmware-tools vmware_tools vmtools razorsedge-vmwaretools Puppet VMware Tools OSP Module @razorsedge vmware vmware-tools vmware_tools vmtools rhel CentOS SuSE OEL puppetlabs-vcenter VMware vCenter installation and management @puppetlabs windows vmware vcenter vsphere 5UbZ3r0-vmwaretools This module handles the installation the VMware Tools Operating System Specific @5UbZ3r0 debian virtualization rhel CentOS vmware vmware-tools vmwaretools puppetlabs-appdirector # VMware vFabric Application Directorâ ¢ Puppet Service @puppetlabs vmware How well does it work? It seems that nobody tried this already. I'm interested too... -- Jakov Sosic www.srce.unizg.hr -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet...@googlegroups.comjavascript: . To unsubscribe from this group, send email to puppet-users...@googlegroups.com javascript:. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. I don't know that I would endorse one over another, but Puppet Labs did a module of the week post about one of them. http://puppetlabs.com/blog/module-of-the-week-razorsedge-vmwaretools/ That might be a good starting point. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet...@googlegroups.comjavascript: . To unsubscribe from this group, send email to puppet-users...@googlegroups.com javascript:. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Hai Tao -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet...@googlegroups.comjavascript: . To unsubscribe from this group, send email to puppet-users...@googlegroups.com javascript:. 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 view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/FTYloCumctkJ. 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: hiera scope and hiera-foreman
Okay. I figured out my issue.
I'm not a developer so this is probably ugly, but came up with:
begin
fqdn = scope.catalog.tags[4]
rescue
fqdn = scope['fqdn'] if scope.has_key?('fqdn')
Hiera.debug(trying mcollective)
end
Hiera.debug(got fqdn #{fqdn})
That fqdn with both:
puppet master --debug --compile FQDN
and
hiera -d -c /etc/puppet/hiera.yaml -m FQDN
--
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/-/m6nAWXboqQIJ.
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] hiera scope and hiera-foreman
Hey all, I've been messing around with the hiera-foreman backend to see if it would let me migrate to hiera and use foreman and an ENC. https://github.com/torrancew/hiera-foreman It works by querying each node's yaml file from foreman. Currently this code works when called from the hiera command line with the -m (mcollective option). It uses the mcollective facts to pull the fqdn variable to know which node to grab the yaml for. So far so good. However, this breaks when you attempt to use it as a hiera backend in a puppet module, since it no longer has the mcollective facts, and fqdn available to it. So my question is, what is the recommended way of querying the current hostname(s) in a hiera backend for it to know what host it should lookup the needed yaml? Thanks! -- 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/-/Yhe1cfLjofAJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppetlabs-firewall stages and persistence
I have this working in our environment as a module, which I will attempt to
describe.
module: casfirewall
init.pp
class casfirewall {
include casfirewall::default, casfirewall::fwpre, casfirewall::fwpost
file {/etc/iptables:
ensure = directory,
owner = root,
group = root,
mode = 700,
}
# Always persist firewall rules
exec { persist-firewall:
command = $operatingsystem ? {
debian = /sbin/iptables-save /etc/iptables/rules.v4,
/(RedHat|CentOS)/ = /sbin/iptables-save /etc/sysconfig/iptables,
},
refreshonly = true,
require = File[/etc/iptables],
}
Firewall {
notify = Exec[persist-firewall],
before = Class[casfirewall::fwpost],
require = Class[casfirewall::fwpre],
}
# Setup firewall resource
resources { firewall: purge = true }
}
As you can see, this holds the meat and potatoes by including the Firewall
notify, before, and require bits.
The fwpre class contains the initial firewall settings (abbreviated here)
class casfirewall::fwpre {
Firewall {
require = undef,
}
firewall { 000 allow outbound:
proto = all,
chain = OUTPUT,
action = accept,
}...
The fwpost class contains the drop everything else rule. Because of the
before ordering in init.pp this rule gets applied last (and was the reason
for starting this thread in the first place)
class casfirewall::fwpost {
firewall {999 drop all:
proto = all,
action = drop,
before = undef,
}
}
In our init.pp we also have defined a default class. This contains all the
rules to open ports to our monitoring servers or backup servers. These get
applied after the initial pre class, and before the post as you would
expect.
I hope that helps. The suggestions given in this thread about firewall
ordering very much helped us. I look forward to seeing the firewall module
get another release and more user uptake.
--
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/-/-B3-kjpoFvYJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppetlabs-firewall stages and persistence
Great! ... almost? The Firewall notify dependency check almost covers everything. I really like its elegance. The one problem I can still think of is that the firewall module is not the only one setting firewall rules. In the puppetlabs/apache module, for example, it attempts to open up port 80. Since there is no guarantee when a module is applied it is possible the firewall module will kick, followed by apache. Since the last rule in the firewall module is to drop all, it will match before the apache open port 80. It is a little bit difficult to test module ordering aside from restarting the puppet master and just trying it out on a test node for about an hour. So I haven't tested this today. You said: the numbers in the namevar are ultimately for how they get ordered in the file ruleset as you state - but not what order they are _inserted_. Which makes me still think that the order various modules kick can affect the firewall rules. Thus, a stage after main is still needed to guarantee that the drop happens last. I hope I'm wrong, is there any alternative? -- 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/-/8LCJU0uojjMJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppetlabs-firewall stages and persistence
Super, it all works great!
Since the whole fwpre class is run before everything else, is it necessary
to define each resource with dependencies with firewall {002 testing:
...}-firewall {... as in your gist?
Anyway, works great for us now. Thanks much!
All that remains is waiting for a new release to get firewall rules at boot
on debian, and then some magic work yet to be done for not stomping on
custom chains like fail2ban.
On Wednesday, March 14, 2012 11:53:31 AM UTC-5, Ken Barber wrote:
You said:
the numbers in the namevar are ultimately for how they get
ordered in the file ruleset as you state - but not what order
they are _inserted_.
Which makes me still think that the order various modules kick can affect
the firewall rules. Thus, a stage after main is still needed to guarantee
that the drop happens last. I hope I'm wrong, is there any alternative?
If you look at my example in the gist:
Firewall {
notify = Exec[persist-firewall],
before = Class[my_soe::fwpost],
require = Class[my_soe::fwpre],
}
I'm setting it so that by default, every rule firewall resource runs
'before' Class[my_soe::fwpost], and it requires
Class[my_soe::fwpre]. So in this example it doesn't need stages -
just put your pre post in those classes.
ken.
--
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/-/zzV3pegM5bUJ.
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: puppetlabs-firewall stages and persistence
I appreciate the interest but I don't understand how you can tell me you don't have any experience with the module but yet know that I'm doing it wrong. The puppetlabs firewall module does not have classes or anything else to base a dependency on. I agree, I would rather not use stages, which is why I originally posted this to see how folks were making it go. If you do find a way to order rules without stages I'd love to hear about it. On Monday, March 12, 2012 7:49:18 AM UTC-5, jcbollinger wrote: It is incorrect that you must use run stages to achieve your desired ordering. In fact, it is *never* the case that run stages are the only solution to ordering issues in Puppet, because there is nothing you can do with them that you cannot also do with ordinary resource relationships. In many cases, solving an ordering problem by use of run stages is like putting in a tack with a sledgehammer: not only is it overkill, it also doesn't afford much precision or finesse. I have no experience with the module in question, so I have no specific suggestions to offer, but if you find run stages too crude a tool for your task then I can advise you about how to achieve your ordering requirements otherwise. -- 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/-/t6rnTOXMrNgJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppetlabs-firewall stages and persistence
In the pre main stage I have defined rules to allow outbound and allow related and established. In the post main stage, it does a drop all. Before this was organized into stages, occasionally the drop all would get applied before keep established and allow outbound, and thus the client could lose its connection to the puppet master mid run. On Tuesday, March 13, 2012 4:16:07 PM UTC-5, Mohamed wrote: Just out of curiosity, what do you mean by: We ended up in situations where the drop rules would kick before the allow established rules, and thus kill the puppet run In my experience, what breaks is the reporting attempt puppet clients makes to the master, not the puppet run itself. -- 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/-/xBTznk59RKkJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppetlabs-firewall stages and persistence
Thus far I've only been able to get puppet to run without making the firewall persistent. In the case of running the exec save-rules in the post: it's no good if your hosts are at all dynamic since it only runs after the main stage. So if you have an existing host, add another normal firewall rule, that rule will get added on the next puppet run. But since the firewall drop rule that exists in the post stage has already been pushed out, the post bits never get called, and thus the firewall rules are not saved and your update will be lost at boot. I'm hoping something happens in development since there has not been a new revision in a little while and the github patches are stacking up. Cheers -- 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/-/GQeDShNZDRAJ. 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] puppetlabs-firewall stages and persistence
Hi all,
I'm attempting to use the puppetlabs-firewall module. In testing,
rules are enabled in a random order, so it seems necessary to utilize
puppet stages to guarantee proper ordering.
I created a module to organize my firewalling. It consists of
localfw::pre to open the INPUT chain for established and related
connections, localfw::default for most normal rules, and localfw::post
to block everything else.
I run localfw::pre before stage[main] and localfw::post after. This
has fixed my firewall rules ordering issue, yay. However, rules are
now not being saved :(
I tried adding include localfw::config to ::pre, ::post, and ::default
which consisted of the persistence definitions:
exec { persist-firewall:
command = /sbin/iptables-save /var/lib/iptables/rules.v4,
require = File [/var/lib/iptables],
refreshonly = true,
}
Firewall {
notify = Exec[persist-firewall]
}
and while I don't get any errors, I also don't get any firewall rules
saved. It appears that Firewall never kicks to run the exec. If I add
these bits to localfw::pre, then the pre rules get saved. If I add to
localfw::post then all get saved, as expected. But in that case,
normal firewall changes to a node don't cause localfw::post to run
again, and thus aren't saved.
What is the recommended way to save iptables rules for persistence
when using puppet stages? Has anyone made this work?
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] Re: puppetlabs-firewall stages and persistence
I've got slightly more info. In trying to figure this out I ran across
http://projects.puppetlabs.com/issues/10665 where it was suggested
that the persist-firewall bits (already shown in the previous message)
get placed into site.pp. This almost worked perfectly.
I've placed the following inside a node definition.
class { localfw::pre: stage = pre }
class { localfw::post: stage = post }
include localfw
If I keep localfw::post empty of firewall definitions, everything
works fine. However, once I place anything in there (such as an empty
test: firewall { 999 testing: ; } I get an error about cyclic
dependencies.
# puppet agent -v --no-daemonize --onetime
info: Retrieving plugin
info: Loading facts in iptables
info: Loading facts in sshkeys
info: Loading facts in etc_facts
info: Loading facts in iptables
info: Loading facts in sshkeys
info: Loading facts in etc_facts
info: Caching catalog for testhost
err: Could not apply complete catalog: Found dependency cycles in the
following relationships: Firewall[999 drop all] = Exec[persist-
firewall], Exec[persist-firewall] = Firewall[999 drop all]; try using
the '--graph' option and open the '.dot' files in OmniGraffle or
GraphViz
notice: Finished catalog run in 0.65 seconds
Is this a bug, or am I doing something wrong? In trying to figure that
out it looks like it may be related to puppet bug #5349? Any thoughts?
The puppetlabs firewall module seems so close to being usable. Saving
the firewall to enable on boot is the last missing bit in my
checklist. Thanks much!
--
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.
