Luke Kanies | 1 Aug 01:53 2007

Re: Directory of symlinsk

On Jul 31, 2007, at 5:26 PM, Ian Burrell wrote:

> How would I make a file resource that produces a directory of symlinks
> pointing to all the files in another directory?  I know how to do it
> with "cp -s" or "ln -s" commands but doing it with file resource would
> be better.

You should be able to do recursive linking:

file { "/my/link": ensure => "/target", recurse => true }

  --
  Someday I want to be rich. Some people get so rich they lose all
  respect for humanity. That's how rich I want to be.  --Rita Rudner
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies | 1 Aug 03:54 2007

Re: fileserving a directory

On Jul 31, 2007, at 3:09 PM, johnny wrote:
> 1) It doesn't retain symbolic links. It simply follows the
> links to the original file, then fileserves that. I know I
> can use the "file" type along with link & target to properly
> do symlinks, but ideally, if I'm already serving out the
> parent directory, I'd like the symlinks contained therein to
> be left intact without having to do another "file" for each
> one of them.

Unfortunately, you cannot currently serve symlinks.

> 2) All the files underneath get owner/group "apache" and
> mode 755. I'd like them to stay as they are. If I remove
> "recurse", it doesn't seem to fileserve any files at all,
> just the directory (empty).

You'd have to remove the owner and mode.

You cannot currently only copy files from a remote source, which is  
probably what you're trying to do.

Is anyone willing to document this on the wiki?

  --
  Always read stuff that will make you look good if you die in the  
middle
  of it.       -- P. J. O'Rourke
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com
(Continue reading)

Ryan Dooley | 1 Aug 04:02 2007

chain reactions? ...

Had a thought and I don't think I see an obvious way to do this... so for
instance:

All hosts are tagged with "baremetal" (i.e. those packages that are deemed
necessary for proper running of a system)

host n1 is part of a group tagged as class foo.  Foo includes baremetal.

foo installs packages a, b, c and d

Now some time goes by and host n1 needs to be dedicated to another class
bar.  bar installs packages r, s and t and includes baremetal.

There are many package conflicts between the set for foo and the set for
bar.

(foo and bar are machine roles if you will).

Is this best to do with

class foo
  package {
    "A":
      ensure => installed;
    ...
    "D":
      ensure => installed;
    "R":
      ensure => purged;
    ...
(Continue reading)

ben | 1 Aug 09:34 2007
Picon

Re: noisy reports from cron {}

On 30/07/07, Luke Kanies <luke <at> madstop.com> wrote:
> Do I have to do something special to use Vixie cron on Freebsd?  The
> only FreeBSD image I have is 5.4, is it running vixie cron? How can I
> tell?

I was going by the AUTHOR section of the cron man pages on a FreeBSD 6.2 box.

> In one run?

Ya.

> Where is the header in relation to the path lines?  I guess both the
> main cron header and the per-job header.

It's all where it should be.

What's happening is it's producing usable crontabs, it just happens to
be inserting the environment lines into the file thousands of times
instead of 1 for all but the first entry.  On each subsequent run it
adds more lines. Eventually it kills puppetd.

I'll look into it more tomorrow, and see what I can do to reproduce it.
Pedro Simões | 1 Aug 14:54 2007
Picon

Puppet uses too much RAM memory

Hello,

I have two Vmware images, with 256MB of RAM memory each one, running
puppetmasterd for the server and puppetd for the client. It's normal
that my puppetmasterd and puppetd occupies almost 10% of RAM memory
each one? They aren't doing anything especial, just listening on the
ports.

Thanks.
Chaos Golubitsky | 1 Aug 15:03 2007

Re: chain reactions? ...

On Tue, 31 Jul, 2007 at 19:02:09 -0700, Ryan Dooley wrote:

> Had a thought and I don't think I see an obvious way to do this... so for
> instance:

I'm fairly early into experimenting with puppet, and i sort of have a
solution to this, but it's not a good one, so i'm going to chime in in
hopes that i can get some advice too.

I like to setup every machine so that it is either explicitly a foo
server or explicitly not a foo server.  The way i've been doing that is:

  node n1 {
    $foo_server = true
    $bar_server = false
    include all-services
  }

  class all-services {
    include foo-server
    include bar-server
  }

  class foo-server {
    Package {
      ensure => $foo_server ? {
        true => installed,
        false => purged,
      }
    }
(Continue reading)

Luke Kanies | 1 Aug 16:31 2007

Re: chain reactions? ...

On Aug 1, 2007, at 8:03 AM, Chaos Golubitsky wrote:
> [...]
> And so forth.  Then, if you wanted to change n1's definition, you'd  
> just
> change the node def so that $foo_server = false and $bar_server =  
> true,
> and it should Just Work (in theory).

This is basically the only way to provide this functionality right  
now, other than (of course) rebuilding the machine from scratch when  
you change its purpose, which is, frankly, the best way to do that.

> This is more elegant than anything else that immediately came to mind,
> but it's obviously not great, because it's complicated to maintain.
> In particular, the use of variables to indicate whether a machine is
> part of a class or not is kludgy and redundant, and i've run into  
> scoping
> issues even in simple lab examples.  Perhaps worse, if foo-server
> and bar-server had a package in common, there would be a conflict if
> a machine was one but not the other, and it seems like that situation
> would crop up eventually.

There's no good solution to this problem right now.

I'm hoping to have the development resources in the next few months  
to build the ability to do that on the client, but I have no idea if  
this will happen.

Basically, we need to start keeping track of client configuration  
state, so that we notice when a resource was previously managed and  
(Continue reading)

Jeff McCune | 1 Aug 18:36 2007
Picon

Re: Puppet uses too much RAM memory

Pedro Simões wrote:
> Hello,
> 
> I have two Vmware images, with 256MB of RAM memory each one, running
> puppetmasterd for the server and puppetd for the client. It's normal
> that my puppetmasterd and puppetd occupies almost 10% of RAM memory
> each one? They aren't doing anything especial, just listening on the
> ports.
> 
> Thanks.

I think it's normal.  My puppet master is 34m resident, which seems
great considering cfservd is 217m.

"too much" is certainly subjective.

Cheers,
--

-- 
Jeff McCune
The Ohio State University
Department of Mathematics
Systems Manager

Attachment (smime.p7s): application/x-pkcs7-signature, 4497 bytes
_______________________________________________
Puppet-users mailing list
Puppet-users <at> madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
(Continue reading)

Ryan Dooley | 1 Aug 18:46 2007

Re: Puppet uses too much RAM memory

On 8/1/07 9:36 AM, "Jeff McCune" <mccune <at> math.ohio-state.edu> wrote:

Pedro Simões wrote:
> Hello,
>
> I have two Vmware images, with 256MB of RAM memory each one, running
> puppetmasterd for the server and puppetd for the client. It's normal
> that my puppetmasterd and puppetd occupies almost 10% of RAM memory
> each one? They aren't doing anything especial, just listening on the
> ports.
>
> Thanks.

I think it's normal.  My puppet master is 34m resident, which seems
great considering cfservd is 217m.

"too much" is certainly subjective.

Indeed... I’ve 4 mongrel instances and one webrick running each consuming about ~70MB of resident memory.  And that is really light weight compared to a cfengine that I had in the past.

Cheers,
Ryan
_______________________________________________
Puppet-users mailing list
Puppet-users <at> madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
Luke Kanies | 1 Aug 21:05 2007

Re: Puppet uses too much RAM memory

On Aug 1, 2007, at 1:19 PM, Ian Burrell wrote:

> One thing I have noticed that causes large memory consumption with
> puppet is serving large files.  Puppet reads the whole file into
> memory, base64 encodes it, and then sends it as an XML-RPC message.
> This uses lots of RAM and CPU temporarily.  Depending on your OS, the
> process may not give back the RAM to the OS.

Note that this problem is the reason why we're moving to REST (see  
the archives of the dev list), so hopefully we'll be able to use  
straight http soon, meaning no encoding.

  --
  'Tis better to be silent and be thought a fool, than to speak and
  remove all doubt.              --Abraham Lincoln
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Gmane