Re: [Puppet Users] Puppetmaster best practice for multiple zones
On 20 April 2011 01:49, James Bailey paradoxbo...@gmail.com wrote: Hello, sorry if this is a stupid question but I currently have inherited three security zones LAN, DMZ and PROD. I currently have Puppet and Foreman running in the LAN zone on a host called puppet-lan and I am starting to manage the LAN based systems with them. I am bit stuck however for how best I can managed the remaining two zones. Do create another two puppetmasters and configure them to use the existing storeconfigs DB I am currents. Or do I have two additional standalone puppetmasters? If do the later how will I be able to unify my view of the three zones? All answers welcome, including links to docs I may have missed. It all depends on your security model. This thread may give you some food for thought - http://groups.google.com/group/puppet-users/browse_thread/thread/a1b84a67ee712f93 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] Re: RFC: Refactoring the mount provider.
+1 for using one resource type with different parameters. On 04/19/2011 10:22 PM, Forrie wrote: +1 here for this. Having said that, I think mingling the setting in there with the two basic types would be essential to keep this simple. All the heavy lifting should go on automatically in the background. A sysadmin should only have to change the mount to rw or ro and have Puppet do the right thing. As difficult as that may be to implement :-) On Mar 22, 4:19 pm, Thomas Bellman bell...@nsc.liu.se wrote: Nigel Kersten wrote: TL;DR Themountprovider has used a mish-mash of checkingfstaband actualmountstate to determine state. A possible solution we're looking at is splitting into two types, one that manages /etc/fstab (or /etc/filesystem on other OSes), and one that manages actualmount state. [Details elided] Two separate types is the obviously correct way. Just like we have two separate types for specifying whether a service should be started at boot and for whether it should be running right now. And just like we have nine separate types for specifying file type, owner, group, mode, content and SElinux parameters. ... Hey wait, we don't! We only have one service type and one file type, with multiple properties. Maybe there is some good reason for having it like that. Perhaps like not requiring users to repeat the same things (service name; file path;mount-point and device) for things that very, very often go together. So, no, I think splitting themounttype into two types would be a bad choice. Splitting the 'ensure' parameter of themounttype into two, on the other hand, I think is a very good idea. The nice way to transition would be to have two entirely new parameters, let's provisionally call them 'mount_state' and 'fstab_state', and in 2.7 have the 'ensure' parameter translated into those two new parameters with a warning about that syntax being deprecated, and then in 2.8 remove the 'ensure' parameter entirely. (I actually dislike the names I propose above; they are just examples for the sake of discussing the principle.) /Bellman -- 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] svn update on puppetmaster via commit hook on another server
The puppetlabs wiki page uses a simple svn update /etc/puppet in the post-commit hook script, but that implies that the SVN server is on the same machine as the puppetmaster, which is not the case in my environment. Hi, you could fall back to something less elegant like svn update + rsync push to master etc. 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.
Re: [Puppet Users] How do you implement revert changes'
On 04/19/2011 08:55 PM, Mohamed Lrhazi wrote: Thanks Felix But how is Filebucket currently used? Is there a puppet agent --restore functionality that I missed? No, as a matter of fact, you missed the whole filebucket binary ;-) What I do interactively a lot is filebucket -l get md5 and occasionally filebucket -l restore /some/file md5 I get the md5sums from my agent log. The -l has filebucket use the local clientbucket (which requires a puppet.conf entry to use the correct location). 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] Re: Installing port on FreeBSD
On 04/19/2011 11:52 PM, fafaforza wrote: One last somewhat unrelated question, but one that might help someone with a similar setup: How do I ensure that nss_ldap is installed only after 'sudo', as otherwise, installing nss_ldap from ports would trigger the openldap and sudo packages, which I don't want. require = Package['port-sudo'] wouldn't work, and I don't see an 'onlyif' or similar parameter under package Yes it does. What semantics are you gunning for? Only install X on boxes where Y is getting installed is a tough call. You could use custom facts to find out about your Y. Otherwise, the require is a nice choice, because your catalog should fail where Y is not in the catalog. 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] is there a definition of the abstract service type
On 04/20/2011 03:17 AM, Ben Hughes wrote:
On Tue, Apr 19, 2011 at 04:24:18AM -0700, Tim Coote wrote:
Is there a canonical definition of the service type abstraction, or is
the definition just how the implementation behaves?
What happens when you do:
$ puppet resource service xinetd
That should hopefully give you the output for that.
Resource isn't, say, a system profiling tool. It's more an interface to
resources you have. And while some will give you all the information you
may want ('user' for example), not all of them can.
Also note that under the puppet paradigm, a service is not something
reachable via network (as in services provided through xinetd), but
can be any process that is maintained by use of an init-script.
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.
Re: [Puppet Users] Listing the keys in a hash as an array
module Puppet::Parser::Functions newfunction(:hash_keys, :type = :rvalue) do |args| unless args[0].is_a?(Hash) Puppet.warning hash_keys takes one argument, the input hash nil else args[0].keys end end end save to lib/puppet/parser/functions/ in a module. I think this should be mainline *hint, hint* ;-) 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] does puppet allow to a client specify a value in a configuration file?
On 04/19/2011 11:34 PM, rowan holmes wrote: hi everybody, In the server side we define a template for a configuration file. Our client pulls configuration file from the server without knowing any template is used or not, it just takes the catalog and puts the changes to the file. However, if a client wants to add an extra value to its configuration file that does not exist in the template, does puppet allow that? In other words, puppet forces a configuration file to a bunch of nodes but a node in this bunch wants to add an extra value by itself, it wont take that value from the server. The canonical way would be to extend the template such that the extra value will be added at the manifest's discretion. The best way to integrate this really depends on the structure of you manifest. If this is 2.6, you may be able to add a parameter to the class declaring your file that controls wether the option is present. If you want an extra-versatile solution (or in fact need the client to control the contents), you can use a custom fact for use in your template. 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.
[Puppet Users] Re: svn update on puppetmaster via commit hook on another server
That would, in the worst case, delay the visibility of the changes for 5 minutes. Even running that cronjob every minute would dictate the admin to wait 1 minute before kicking the puppet clients. Otherwise we can't be sure if the client would use the latest config. -- 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] svn update on puppetmaster via commit hook on another server
Do you suggest calling that rsync in the post commit hook? That is not possible as the svn hook script is run by a httpd user without any permissions and granting him any permission just for that hook script would be hard to justify. -- 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] svn update on puppetmaster via commit hook on another server
On 04/20/2011 09:55 AM, Andreas Paul wrote: Do you suggest calling that rsync in the post commit hook? That is not possible as the svn hook script is run by a httpd user without any permissions and granting him any permission just for that hook script would be hard to justify. Hi, doesn't compute: You want your post-hook script to take action towards your puppet master, but giving the user the post-hook runs as any permissions towards that is not allowable? Sounds like you can either chase your own tail for a while ;-) or go for the pull semantics via cronjob as suggested by Prateep or MCollective as per RI's comment. 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.
Re: [Puppet Users] Logging configuration
On Tue, Apr 19, 2011 at 6:30 AM, Ben Hughes b...@puppetlabs.com wrote: On Mon, Apr 18, 2011 at 09:16:13AM -0700, Kal McFate wrote: How do I tell puppet to log somewhere other than /var/log/messages. None of the logging configuration options seem to do anything any more. Specifically puppetdlog. /var/log/messages, will, I presume, be your syslog daemon's logging. It logs at syslogfacility daemon by default. Set syslogfacility to a different level in your puppet.conf and adjust your syslog accordingly. Or you may use --logdest /path/to/file on the command line if you wish. As an additional option, you can use rsyslog, which is the default in recent Redhat-ish distributions and has been available since RH5.2. It's also available for many other Linux and non-Linux platforms. On RHEL5, the following works (put this in /etc/rsyslog.conf): :programname, isequal, puppet-agent /var/log/puppet/agent.log :programname, isequal, puppet-agent ~ This might also work for later releases of rsyslog, nevertheless, on Fedora = 10 and RHEL6 we use: if $programname == 'puppet-agent' and $syslogseverity = '6' then /var/log/puppet/agent.log if $programname == 'puppet-agent' and $syslogseverity = '6' then ~ HTH, Gerald -- 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] is it possible to take definition parameters from a database?
-Original Message-
From: puppet-users@googlegroups.com
[mailto:puppet-users@googlegroups.com] On Behalf Of rowan holmes
Sent: 19 April 2011 22:22
To: Puppet Users
Subject: [Puppet Users] is it possible to take definition
parameters from a database?
There may be thousands of lines like above. so is it possible
to store val1, val2 values in a database and do our job only
calling a line like this:
for every $p1 and $p2 in valueTable in mypuppetDB:
apache:addvhost {abc: param1=$p1, param2=$p2}
I don't know about doing it via puppet - I suspect not without custom
Functions and/or outside help.
I assume you know about this:
http://httpd.apache.org/docs/2.0/vhosts/mass.html
and deem it not suitable.
--
Russell Howe
rh...@moonfruit.com
--
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] Certificate Issues.... again
On 2011-04-18 05:48, James Turnbull wrote: Lance Reed wrote: Not sure if the book has been closed on this, but I had this problem recently on new installs. The problem was fixed by keeping the hosts in time sync. They were 5 hours out of sync. Not sure why this caused an issue unless there is some sort of SSL computation issue? SSL relies on the time on the different hosts being in sync otherwise it assumes certificates are invalid or bogus. It's a security feature of SSL. More specifically, a certificate is only valid within a certain period of time. If you look at the certificate using $ openssl x509 -in /var/lib/puppet/ssl/certs/HOSTNAME.pem -noout -text you will find some lines saying something like: Validity Not Before: Apr 8 10:02:43 2011 GMT Not After : Apr 6 10:02:43 2016 GMT When the server validates the client, it compare its own clock against those two times from the client's certificate, and if it is before the not before or after the not after, it will reject the client. Likewise, when the client validates the server, it checks that the server's certificate is valid according to the client's own clock. Thus, the client and server doesn't actually need to have their clocks in sync. But if you are going to use a certificate that was issued just a couple of seconds ago, it certainly helps... In principle, a CA can antedate or postdate certificates it issues, i.e. write a date earlier or later than the issuing date in the Not valid before field, and thus say it started being valid X days before I signed it or it doesn't become valid until Y days after I signed it, but usually they just write the exact timepoint at which they signed it. The CA built into Puppet does that. /Bellman -- 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] Listing the keys in a hash as an array
On 2011-04-20 03:28, Miki Shapiro wrote:
As suggested by Felix:
Manifest says:
$keys = split(,, inline_template(%= netifcfg.keys.join(',')
%))
exec { /bin/echo keys are $keys and netifcfg is $netifcfg:
logoutput = true }
Output says:
notice: /Stage[main]/Base::Network-common/Exec[/bin/echo keys are , and
netifcfg is
bond0ipaddress10.15.69.177netmask255.255.254.0defaultgatewayyesgateway10.15.68.1bond1ipadderss1.2.3.4netmask255.255.254.0gateway1.2.3.1]/returns:
keys are , and netifcfg is
bond0ipaddress10.15.69.177netmask255.255.254.0defaultgatewayyesgateway10.15.68.1bond1ipadderss1.2.3.4netmask255.255.254.0gateway1.2.3.1
(Split doesn't seem to work).
You have two errors. The first is that the split() function takes its
parameters in the other order from what Felix wrote. The string to
split on goes second, so you should do:
$keys = split(inline_template(%= netifcfg.keys.join(',') %), ,)
The second error is that when you expand $keys within a string literal,
the elements of the array will be joined with nothing inbetween. Try
this instead:
notify {
$keys: ;
}
Or perhaps:
notify {
netifcfg-keys:
message = shellquote(Keys, are:, $keys);
}
Those will show you better the real value of $keys.
/Bellman
--
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] ERB strangness, or ruby/puppet internals I don't understand
On 2011-04-15 21:10, Clay Caviness wrote:
Let's say I have a very simple template
template.erb:
% if not has_variable?(foobar) then foobar = undefined end -%
foobar: %= foobar %
class: %= foobar.class %
And a basic manifest:
template.pp:
$mytemp = template('template.erb')
notice($mytemp)
And then I apply the manifest, with an undefined foobar (no foobar fact):
$ puppet apply ~/template.pp
notice: Scope(Class[main]): foobar: undefined
class: String
notice: Finished catalog run in 0.01 seconds
Looking good. So now I apply the manifest, but with a defined value
for foobar (via the FACTER_FOOBAR environment variable):
$ FACTER_FOOBAR='foo' puppet apply ~/template.pp
notice: Scope(Class[main]): foobar:
class: NilClass
notice: Finished catalog run in 0.01 seconds
Er, what? How on earth did foobar go from a String to NilClass? I
can't fathom how this is expected, or correct...
This happens because the Puppet variables are not exposed to ERB
as real Ruby variables. Instead, Puppet uses some magic to catch
references to non-existing variables. When the Ruby compiler sees
that you are assigning to foobar in your code, *anywhere* in your
code, it will create that variable for you, regardless of whether
the assignment is actually executed or not. Since the variable now
exists, that will shadow Puppet's magic.
That was at least what I found out when I investigated this when
running 0.24.something, and I don't *think* they have changed how
Puppet variables are exposed to ERB since then.
The reason I was doing this sort of thing is to give a possibly
missing fact a default value. I ended up using a second variable, like
this:
% foo = has_variable?(foobar) ? foobar.to_s : false -%
That is probably the best workaround.
/Bellman
--
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: What to do if something is not required on the clients?
On Apr 19, 10:04 am, Nan Liu n...@puppetlabs.com wrote: On Tue, Apr 19, 2011 at 7:46 AM, jcbollinger john.bollin...@stjude.org wrote [...] Oddly enough, I found bug 1739, closed on 0.24.x, that makes exactly the change from rpm -e to yum -y remove. That would make the yum provider work like the apt provider. I didn't find anything suggesting that it was reverted, yet the change is not present in the released code. The commit is still present, it's implemented as the purge action for yum provider. Check: git show d5e19f git blame lib/puppet/provider/package/yum.rb My bad: I missed that the feature was implemented as purge instead of ordinary remove. That does provide a useful insight on the underlying request: if you want to instruct the yum provider to ensure a package removed along with any other packages that depend on it, then setting ensure = purged on the package ought to do the trick. Not that I think it's a good idea, except possibly in the case to which bug 1739 was addressed, cyclic dependencies. Thanks for the clarification. 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] Re: What to do if something is not required on the clients?
On Apr 19, 4:37 pm, Sans r.santanu@gmail.com wrote: On Apr 19, 2:48 pm, jcbollinger john.bollin...@stjude.org wrote: If I understand you correctly, how do one know about the packages that depend on a certain package? Well that's part of a deeper problem, isn't it? If you don't know what packages you might end up removing or why they're installed in the first place, then are you really comfortable with blindly removing them? I certainly wouldn't be. I don't think that's the way you do it. You don't install packages at random or without having known why you installing that package for - do you? I don't, and you are making my case for me. If a package I think I want absent has a dependent package present, then (in my case) that dependency is there on purpose. If I have done my provisioning correctly, then either the dependency is something I want on substantially all nodes, or it is something that I installed afterward, via Puppet. As Ian points out, however, that installation may have been implicit and incidental to installation or upgrade of a different package. The possibilities can be divided among a few cases: 1) The dependent package is explicitly managed by Puppet. In this case you *must* ensure it absent for those nodes where its dependency must be absent, otherwise your configuration is inconsistent and unachievable. 2) The dependent package is provisioned and wanted, or at least accepted, on all nodes, but it is not Puppet-managed by default. Inasmuchas a requirement that this package be absent is exceptional, it is reasonable and even wise to explicitly ensure its absence via Puppet when that is needed. 3) The dependent package is not intentionally provisioned, not Puppet- managed, and by default unwanted. If the package is in fact present, then I want to know it so I can figure out why. Either there is some system requirement that is not captured in the node's Puppet configuration (and which I do not want to break), or the configuration is inconsistent, or there has been a provisioning or administration failure. Any of these alternatives require my attention, so I want the puppet client to make noise. And if you know the packages you installing, you already know the dependences and the related packages. At least that's the case here. In this example, if I know that I definitely don't want httpd to be installed on the system at the first place, then why should I care about all the packages (maybe installed by default) that need httpd - isn't it? You continue to make my case. If you definitely don't want httpd (for example) installed, then you should not provision your systems with it, right? If you don't provision your systems with it, and you're certain you don't want it, but later it gets installed anyway, then don't you think that situation would require some investigation? Especially if httpd gets installed because something you do want depends on it? I think so. If none of that persuades you then it looks like you can ensure = purged instead of ensure = absent to get the behavior you want. I would not be comfortable with doing that, but perhaps it makes sense to you. 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] Listing the keys in a hash as an array
On Wed, Apr 20, 2011 at 12:17 AM, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: module Puppet::Parser::Functions newfunction(:hash_keys, :type = :rvalue) do |args| unless args[0].is_a?(Hash) Puppet.warning hash_keys takes one argument, the input hash nil else args[0].keys end end end save to lib/puppet/parser/functions/ in a module. I think this should be mainline *hint, hint* ;-) I might take this as the first step towards collecting a bunch of these in a module, and if there's enough interest in it during the life of 2.7.x, we'll merge some of them into Telly, the next feature release. -- 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] how to fix symbolic links
Dear all, Say for example, this is the package, already installed on the system: # rpm -qa | grep lfc-libs lfc-libs-1.8.0-1sec.sl5 lfc-libs-1.8.0-1sec.sl5 and I want a symbolic: liblfc.so - libdpm.so.1.8.0 in /opt/lfc/ lib, for example. Is it possible? 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] Re: What to do if something is not required on the clients?
Thanks John and others.
For my case, I definitely know I don't need httpd and any packages
(or updates) that depend on httpd, so ensure = purged should work
for me, in this particular occasion.
However, I also tried this (I posted this before in this thread abut
can't see that anymore):
package {
'httpd': notify = Exec[ 'remove-httpd' ];
}
exec { 'remove-httpd':
command = '/usr/bin/yum remove -y httpd',
refreshonly = true,
}
but doesn't work either. What am I doing anything wrong here? 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.
Re: [Puppet Users] how to fix symbolic links
On Apr 20, 2011, at 6:07 PM, Sans wrote:
Dear all,
Say for example, this is the package, already installed on the
system:
# rpm -qa | grep lfc-libs
lfc-libs-1.8.0-1sec.sl5
lfc-libs-1.8.0-1sec.sl5
and I want a symbolic: liblfc.so - libdpm.so.1.8.0 in /opt/lfc/
lib, for example. Is it possible? Cheers!!
Setting symlinks is standard job for file resource type:
file { 'source':
ensure = 'destination'
}
Example.:
file {'/etc/inetd.conf':
ensure = 'etc/inet/inetd.conf'
}
This creates a symlink /etc/inetd.conf pointing to /etc/inet/inetd.conf
hth
Martin
--
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: is there a definition of the abstract service type
Hi Ben
[I'm using the training machine from puppetlabs]
puppet resource service xinetd
returns info about xinetd.
But
puppet resource service
does not include anything about xinetd, which sounds like a bug to me.
I understand the limitations of what can be recovered, but that's an
implementation constraint. The documentation talks about an
Abstraction Layer. From a design perspective, I'd expect such an
interface to explicitly tell me what it cannot recover, rather than
silently not returning it, as I've no way of knowing that there's a
constraint on the o/s / distro vs a bug in puppet.
Tim
On Apr 20, 2:17 am, Ben Hughes b...@puppetlabs.com wrote:
On Tue, Apr 19, 2011 at 04:24:18AM -0700, Tim Coote wrote:
Is there a canonical definition of the service type abstraction, or is
the definition just how the implementation behaves?
What happens when you do:
$ puppet resource service xinetd
That should hopefully give you the output for that.
Resource isn't, say, a system profiling tool. It's more an interface to
resources you have. And while some will give you all the information you
may want ('user' for example), not all of them can.
--
Ben Hughes ||http://www.puppetlabs.com/
--
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] how to fix symbolic links
Hello,
On 11-04-20 01:02 PM, Martin Alfke wrote:
On Apr 20, 2011, at 6:07 PM, Sans wrote:
Say for example, this is the package, already installed on the
system:
# rpm -qa | grep lfc-libs
lfc-libs-1.8.0-1sec.sl5
lfc-libs-1.8.0-1sec.sl5
and I want a symbolic: liblfc.so - libdpm.so.1.8.0 in /opt/lfc/
lib, for example. Is it possible? Cheers!!
Setting symlinks is standard job for file resource type:
file { 'source':
ensure = 'destination'
}
Example.:
file {'/etc/inetd.conf':
ensure = 'etc/inet/inetd.conf'
}
This creates a symlink /etc/inetd.conf pointing to /etc/inet/inetd.conf
the above will work fine, but using the ensure parameter to specify
the target path was deemed misleading and so an alternative was added.
I suggest checking out this page for more info on the file resource type:
http://docs.puppetlabs.com/references/stable/type.html#file
However, from what I can see, the documentation about its ensure
parameter could use a little fine-tuning. Even though the first
parameter doesn't mention link as a valid value for ensure, there is
an example of the alternative I'm describing in the first code box.
Here's an example using the alternative method, which in my opinion
makes things clearer:
# this should theroetically make a symlink relative to the current
# directory. You can also use absolute paths for the target.
file { '/opt/lfc/lib/liblfc.so':
ensure = link,
target = 'libdpm.so.1.8.0',
}
--
Gabriel Filion
--
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] how to fix symbolic links
On Wed, Apr 20, 2011 at 10:51 AM, Gabriel Filion lelu...@gmail.com wrote:
Hello,
On 11-04-20 01:02 PM, Martin Alfke wrote:
On Apr 20, 2011, at 6:07 PM, Sans wrote:
Say for example, this is the package, already installed on the
system:
# rpm -qa | grep lfc-libs
lfc-libs-1.8.0-1sec.sl5
lfc-libs-1.8.0-1sec.sl5
and I want a symbolic: liblfc.so - libdpm.so.1.8.0 in /opt/lfc/
lib, for example. Is it possible? Cheers!!
Setting symlinks is standard job for file resource type:
file { 'source':
ensure = 'destination'
}
Example.:
file {'/etc/inetd.conf':
ensure = 'etc/inet/inetd.conf'
}
This creates a symlink /etc/inetd.conf pointing to /etc/inet/inetd.conf
the above will work fine, but using the ensure parameter to specify
the target path was deemed misleading and so an alternative was added.
I suggest checking out this page for more info on the file resource type:
http://docs.puppetlabs.com/references/stable/type.html#file
However, from what I can see, the documentation about its ensure
parameter could use a little fine-tuning. Even though the first
parameter doesn't mention link as a valid value for ensure, there is
an example of the alternative I'm describing in the first code box.
Here's an example using the alternative method, which in my opinion
makes things clearer:
# this should theroetically make a symlink relative to the current
# directory. You can also use absolute paths for the target.
file { '/opt/lfc/lib/liblfc.so':
ensure = link,
target = 'libdpm.so.1.8.0',
}
Gah. You just reminded me of a deprecation we planned to do for
Statler but didn't get done.
http://projects.puppetlabs.com/issues/4938
I always push the alternative syntax you've hinted at:
file { /tmp/foo:
ensure = symlink,
target = /tmp/bar,
}
--
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: is there a definition of the abstract service type
On Apr 20, 8:13 am, Felix Frank felix.fr...@alumni.tu-berlin.de
wrote:
On 04/20/2011 03:17 AM, Ben Hughes wrote:
On Tue, Apr 19, 2011 at 04:24:18AM -0700, Tim Coote wrote:
Is there a canonical definition of the service type abstraction, or is
the definition just how the implementation behaves?
What happens when you do:
$ puppet resource service xinetd
That should hopefully give you the output for that.
Resource isn't, say, a system profiling tool. It's more an interface to
resources you have. And while some will give you all the information you
may want ('user' for example), not all of them can.
Also note that under the puppet paradigm, a service is not something
reachable via network (as in services provided through xinetd), but
can be any process that is maintained by use of an init-script.
Regards,
Felix
Hi Felix
Any service must surely have an access point (either listening on a
port on some IP address, even if it's just localhost), or some other
IPC mechanism, otherwise it cannot provide a technical service to any
consumer.
Surely the abstraction cannot relate to init-scripts, otherwise there
would be no mapping to a Windows machine (or even BSD), and I'd need a
totally parallel set of manifests for wintel. That's not abstraction.
The problem with there not being a description of how the software
should behave (either documentation or a set of tests), is that if
something changes behaviour between releases, there's a large
migration problem for the user.
Tim
--
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: Installing port on FreeBSD
On Apr 20, 3:11 am, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: require = Package['port-sudo'] wouldn't work, and I don't see an 'onlyif' or similar parameter under package Yes it does. What semantics are you gunning for? Only install X on boxes where Y is getting installed is a tough call. You could use custom facts to find out about your Y. Otherwise, the require is a nice choice, because your catalog should fail where Y is not in the catalog. I'll give require a try. I wasn't sure whether Package[] referenced a definition within the class (which wouldn't work for me since I used exec), or whether it queried the system's packaging system to check whether it was installed. Also, sorry for the multiple posts. Google kept throwing an error, and I retried posting a few time before seeing that some of them went through. -- Darek -- 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] Re: is there a definition of the abstract service type
On 20.4.2011 20:30, Tim Coote wrote: On Apr 20, 8:13 am, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: Also note that under the puppet paradigm, a service is not something reachable via network (as in services provided through xinetd), but can be any process that is maintained by use of an init-script. Any service must surely have an access point (either listening on a port on some IP address, even if it's just localhost), or some other IPC mechanism, otherwise it cannot provide a technical service to any consumer. Setting sysctls or starting firewalls are coming to me mind. -- Kind Regards, Markus Falb signature.asc Description: OpenPGP digital signature
[Puppet Users] Re: is there a definition of the abstract service type
Intriguingly, on a fedora 13 host, using puppet-0.25.5-1.fc13.noarch,
information about xinetd *is* returned by
puppet resource service.
the version on the learning machine is:
pe-puppet-2.6.4-7.el5
Is the change in behaviour a bug? how can I tell?
On Apr 20, 6:42 pm, Tim Coote tim.coo...@googlemail.com wrote:
Hi Ben
[I'm using the training machine from puppetlabs]
puppet resource service xinetd
returns info about xinetd.
But
puppet resource service
does not include anything about xinetd, which sounds like a bug to me.
I understand the limitations of what can be recovered, but that's an
implementation constraint. The documentation talks about an
Abstraction Layer. From a design perspective, I'd expect such an
interface to explicitly tell me what it cannot recover, rather than
silently not returning it, as I've no way of knowing that there's a
constraint on the o/s / distro vs a bug in puppet.
Tim
On Apr 20, 2:17 am, Ben Hughes b...@puppetlabs.com wrote:
On Tue, Apr 19, 2011 at 04:24:18AM -0700, Tim Coote wrote:
Is there a canonical definition of the service type abstraction, or is
the definition just how the implementation behaves?
What happens when you do:
$ puppet resource service xinetd
That should hopefully give you the output for that.
Resource isn't, say, a system profiling tool. It's more an interface to
resources you have. And while some will give you all the information you
may want ('user' for example), not all of them can.
--
Ben Hughes ||http://www.puppetlabs.com/
--
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: how to fix symbolic links
Thank you guys!! So many possibilities, I love that. BTW, can it be protected against the current version number, so that if the future version breaks the link it'll be automatically created? 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] how to catch errors
Hello! Even if puppet rule sets are OK, sometimes errors occur on puppet clients upon processing puppet rules. What are the best practices to catch/analyze them? signature.asc Description: This is a digitally signed message part.
Re: [Puppet Users] how to catch errors
On Wed, Apr 20, 2011 at 13:46, Pavel Piatruk piatru...@gmail.com wrote: Even if puppet rule sets are OK, sometimes errors occur on puppet clients upon processing puppet rules. What are the best practices to catch/analyze them? Puppet logs to syslog out of the box; we used a combination of our regular log collection and analysis tools, and a nagios check that puppet had run recently, to monitor the situation at my last job. Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman dan...@puppetlabs.com ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- 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] Installing port on FreeBSD
On Fri, Apr 15, 2011 at 3:26 PM, fafaforza fafafo...@gmail.com wrote:
New user trying to get a port to compile: I tried searching but all I
get are links to the FreeBSD port of puppet. Easier to find a needle
in a haystack.
A class has:
exec { port-sudo:
cwd = /usr/ports/security/sudo,
environment = BATCH=yes,
command = '/bin/sh -c /usr/bin/make install',
path = [/bin/, /usr/bin/, /usr/local/bin/, /sbin/, /
usr/sbin/, /usr/local/sbin/],
returns = 1,
}
Shouldn't you be using the ports package provider instead?
package { sudo:
provider = ports,
ensure = installed,
}
I haven't touched Puppet on FreeBSD personally, it may auto-detect the
provider automatically for you correctly.
--
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] Re: is there a definition of the abstract service type
On Wed, Apr 20, 2011 at 10:42:21AM -0700, Tim Coote wrote:
[I'm using the training machine from puppetlabs]
puppet resource service xinetd
Which one? Not all of them use xinetd. Certainly the CentOS 5 machine I
have doesn't have xinetd. So it won't report it as a service. Querying it
directly will say not to run it as it doesn't exist.
[ben@centos56:~]% puppet resource package xinetd
package { 'xinetd':
ensure = 'absent',
}
[ben@centos56:~]% puppet resource service xinetd
service { 'xinetd':
ensure = 'running',
enable = 'false',
}
I don't know if Fedora uses xinetd by default as I don't have a Fedora
machine here to test with I'm afraid.
From a design perspective, I'd expect such an
interface to explicitly tell me what it cannot recover, rather than
silently not returning it, as I've no way of knowing that there's a
constraint on the o/s / distro vs a bug in puppet.
I think this may, to a degree, be a case of not being able to know the
unknown. Certainly resource can improve in some areas though.
If it is a bug then I'd like to get it fixed too.
--
Ben Hughes || http://www.puppetlabs.com/
--
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: is it possible to take definition parameters from a database?
I don't know about doing it via puppet - I suspect not without custom Functions and/or outside help. I assume you know about this: http://httpd.apache.org/docs/2.0/vhosts/mass.html and deem it not suitable. Thanks Russell, I know about that but I asked in general -- 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] is it possible to take definition parameters from a database?
On Tue, Apr 19, 2011 at 02:21:39PM -0700, rowan holmes wrote: I really wonder that can we use a database for our definition calls. assume that we have a definition which is used for adding virtual hosts to apache configuration file like below: You can, quite happily, but you have to write it yourself I'm afraid. You could use an ENC (External Node Classifier), and have that output all your node and thus parameter data from your database. See http://docs.puppetlabs.com/guides/external_nodes.html Or write a parser function, such as extlookup but talking to a database back end. http://www.devco.net/archives/2009/08/31/complex_data_and_puppet.php -- Ben Hughes || http://www.puppetlabs.com/ -- 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.
