Marcus, Allan B | 1 Jul 2010 01:08

Re: [Puppet Users] which is more efficient?

we are running at about 10-15% processor usage now, so it ain't even close to make or break. We run MySQL and
apache on the same box too, so we can split them off if we need to. I was just wondering if one way was
significantly more efficient than the other.

---
Thanks,

Allan Marcus
505-667-5666

"A carrot may work better than a stick, but only if the carrot is big enough and it doesn't break when you hit
people with it."

On Jun 30, 2010, at 2:28 PM, Patrick Mohr wrote:

> I'd say that "this way lies madness".  Just do whatever gives you maintainability.  The way that you source a
file isn't going to make or break your server.  (Unless you start embedding huge files in your manifest.)  If
small changes like this will break your server, your server will die the first time you run a backup or any
other maintenance.  
> 
> 
> On Jun 30, 2010, at 1:07 PM, Marcus, Allan B wrote:
> 
>> With over two thousand client hitting one server, and plans to grow to about 5000, efficiency is
important. 
>> 
>> On Jun 30, 2010, at 12:58 PM, Steven VanDevender wrote:
>> 
>>> Marcus, Allan B writes:
>>>> We need to put a script into /usr/local/bin. Which is more efficient,
(Continue reading)

R.I.Pienaar | 1 Jul 2010 01:21
Favicon
Gravatar

Re: [Puppet Users] ensure version ?


----- "CraftyTech" <hmmedina <at> gmail.com> wrote:

> Hello,
> 
>      This was supposed to be an easy one, but it's giving me a bit of
> a hard time.  I know that specify a version for a package, I'd say:
> ensure => "version-123", but how do I also add a second command for
> the same variable; for instance, how do it I tell it to ensure =>
> installed and also ensure => version?  so far I've tried separating
> it with commas, i.e, ensure => installed, "version".  I've also tried
> putting the version in brackets; i.e, ensure => installed["version"].
> So far it hasn't worked.  Any ideas?

you cannot have ensure => version without also implying installed.  there's no reason to tell it to install
it, if you're telling it to install version x

-- 
R.I.Pienaar

--

-- 
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 <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Douglas Garstang | 1 Jul 2010 01:32
Picon

[Puppet Users] Package requires....

If I have a package { "foo": ensure => installed; require => something
} in a module, AND I also have a Package { require =>
Class['yum::client']} in site.pp, what happens in the module? Does the
package in the module require both 'something' and the yum::client
class, or does the fact I specified a package{} with a require in the
module mean that only the yum::client class is required?

Doug.

--

-- 
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 <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

CraftyTech | 1 Jul 2010 04:20
Picon

[Puppet Users] Re: ensure version ?

Gotcha.. Thanks

On Jun 30, 7:21 pm, "R.I.Pienaar" <r... <at> devco.net> wrote:
> ----- "CraftyTech" <hmmed... <at> gmail.com> wrote:
> > Hello,
>
> >      This was supposed to be an easy one, but it's giving me a bit of
> > a hard time.  I know that specify a version for a package, I'd say:
> > ensure => "version-123", but how do I also add a second command for
> > the same variable; for instance, how do it I tell it to ensure =>
> > installed and also ensure => version?  so far I've tried separating
> > it with commas, i.e, ensure => installed, "version".  I've also tried
> > putting the version in brackets; i.e, ensure => installed["version"].
> > So far it hasn't worked.  Any ideas?
>
> you cannot have ensure => version without also implying installed.  there's no reason to tell it to
install it, if you're telling it to install version x
>
> --
> R.I.Pienaar

--

-- 
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 <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Klaus Ethgen | 1 Jul 2010 11:18
Picon

[Puppet Users] Debug output white on white background


Hello,

if I test my configuration by using puppet --debug it outputs the debug
messages in white colour. Colours are not per see bad but it is a great
challenge to read white text on white background.

Is there any way to configure the text color of debugging output?

Regards
   Klaus
--

-- 
Klaus Ethgen                            http://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus <at> Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
bowlby | 1 Jul 2010 14:33
Picon

[Puppet Users] Re: custom types not used by puppet

Hi Dan,

You're correct I'm running puppetd/master on the same server, no
client/server stuff yet. It was my un-educated guess that puppet isn't
able to find the libs; I do not get an error message when I run:
'puppetd --test --debug --trace --server="xxxx"', the db's just do not
get created (nor the users).

My node-specs are these:

I have class which installs myapp, in that class I create the db and
users:

class myapp::install {
    Exec { path => "/usr/bin:/usr/sbin" }
    file { "/var/www/$domain":
          source => "puppet:///myapp",
          recurse => "true",
          owner => "$user",
          group => "$user",
          ignore    => ".svn",
    }
    group { myapp:
           gid => 601 }

    user { myapp:
          comment => "myapp",
          require => Group["myapp"],
          uid => 601,
          gid => 601,
(Continue reading)

Peter Meier | 1 Jul 2010 16:42
Picon
Gravatar

Re: [Puppet Users] Debug output white on white background


> if I test my configuration by using puppet --debug it outputs the debug
> messages in white colour. Colours are not per see bad but it is a great
> challenge to read white text on white background.
> 
> Is there any way to configure the text color of debugging output?

http://docs.reductivelabs.com/references/stable/configuration.html?version=30#color

cheers pete
Robert Scheer | 1 Jul 2010 17:11

[Puppet Users] Managing some (but not all) user files

Hi,

I have set up a module that realizes (groups of) users from a set of
virtual users, and this works well.

What I'd like to do now, is to build in some system where user files
are distributed as well, but with the following features:

- this should work for previously unspecified files and directories.
- users should be able to maintain their own 'master' files.
- existing files on nodes should remain untouched.

In practice if user "foobar" wants his .bashrc distributed, he logs
into the puppetmaster server, finds his personal 'master' directory
in /etc/puppet/modules/users/files/foobar (which I made sure is
writable for him), and copies his .bashrc into it. An hour later
it exists on all nodes where he has access to. This should also work
for .ssh/authorized_keys, bin/myscript, lib/fortunes/discworld and
any other files or directories he copies here, without the need to
specify them in advance. And if he changes a file in this personal
'master' directory, then the changes should propagate as well.

I tried this with file{ "/home/$user": ensure => directory, recursive =>
true, ... } but this also modifies ownership and permissions of already
existing files in /home/$user.

Is what I want possible at all in puppet? And if so, how should I proceed?

Robert Scheer

(Continue reading)

jb | 1 Jul 2010 19:17
Picon

[Puppet Users] Re: ERB / Tagging...

This also vexes me, I also would love to use 'all_tags', but it's not
consistent.  The issues is best described in the following bug, I
believe:

http://projects.puppetlabs.com/issues/3049

On Jun 30, 10:59 am, Dan Carley <dan.car... <at> gmail.com> wrote:
> On 30 June 2010 18:40, CraftyTech <hmmed... <at> gmail.com> wrote:
>
> > Hello All,
>
> >     Can someone point me in the right direction here.  I'm trying to
> > create an erb template for my /etc/hosts file, so that when executed,
> > it populates the /etc/hosts file only with entries that are tag
> > relevant.  For instance, if a server is tagged apache, only the apache
> > tagged entries would be populated into the /etc/hosts file.  Thanks in
> > advance for you help.
>
> This is possible with `if all_tags.include?("<sometag>")`.
>
> But, and a big but, it is highly dependent on the order which your modules
> are compiled[0]. It will prove unreliable if your Apache module happens to
> be `included` after the module which is creating the templated hosts file.
> For this reason it will introduce extra use complexity into your modules and
> most people will probably recommend that you use facts instead.
>
> It happens to be a bit of a bug bear of mine because it is otherwise quite a
> useful feature that precludes the mess of populating additional facts. The
> conundrum is similar to a recent thread[1] entitled "do X if package Y is
> installed".
(Continue reading)

Dan Carley | 1 Jul 2010 20:10
Picon
Gravatar

Re: [Puppet Users] Re: ERB / Tagging...

On 1 July 2010 18:17, jb <jeffbehl <at> gmail.com> wrote:
This also vexes me, I also would love to use 'all_tags', but it's not
consistent.  The issues is best described in the following bug, I
believe:

http://projects.puppetlabs.com/issues/3049

Good call. I wasn't aware there was an existing ticket for it.

For what it's worth, I have conceded to using all_tags in some cases, by writing and documenting the execution order into my manifests. I've had a number of instances whereby I want module X to behave differently if module Y is present, without having to put additional cross-dependencies into module Y. It's not something that I'm thrilled about though because the principle of least surprise is out the window if you pick up a module and use it in a slightly different way.

--
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 <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Gmane