headers
HARRIS Jimmy (AXA-Tech-AU | 1 May 2007 01:46

Re: Installing puppetmasterd, puppetd as services under Red Hat, CentOS

> What I need is a spec file that does
> 
>   tar xf ruby-1.8.x.tar.gz
>   cd ruby-1.8.x
>   ./configure && make && make install
> 
> and absolutely nothing else (unit tests would be nice but I won't
> quibble.) No X11, no emacs mode, no tcl/Tk bindings(!), no 
> docs collected from hither and yon, just the  <at> #$%! 
> interpreter and the standard  <at> #$%! utilities that come with it.

Have you tried using CheckInstall
(http://asic-linux.com.mx/~izto/checkinstall/)?  I discovered it last
week when I was installing FastCGI for a Rails installation.

It runs "make install" for you and creates an rpm of the resulting
files.  Seemed to work well with FastCGI but I haven't tried it on
anything more complex yet.

James

*********************************************************************************
Important Note
This email (including any attachments) contains information which is 
confidential and may be subject to legal privilege.  If you are not 
the intended recipient you must not use, distribute or copy this 
email.  If you have received this email in error please notify the 
sender immediately and delete this email. Any views expressed in this 
email are not necessarily the views of AXA-Tech Australia.   Thank you.
**********************************************************************************
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dustin Kanske | 1 May 2007 03:26
Picon

Custom functions and facts

Hello!

I've been trying to use facts from Facter in a custom function. I've
been following Matthew's entry in the wiki
(http://www.reductivelabs.com/trac/puppet/wiki/WritingYourOwnFunctions).

What i'm seeing is that Facter['fqdn'].value is always returning the
fqdn of the puppetmaster host. I was expecting the fqdn of the client
host.

Here's the code that is exhibiting this behavior:

require 'md5'
module Puppet::Parser::Functions
  newfunction(:hour_from_fqdn, :type => :rvalue) do |args|
    MD5.new(Facter['fqdn'].value).to_s.hex % 4
  end
end

I've managed to get this working by using $fqdn inside my node
definition and passing it through to my custom definition like this:

node 'somenode.domain.com' {
  custom_definition { name: address => $fqdn }
}

define custom_definition ($address){ "custom_name":
  $random_hour = hour_from_fqdn($address)
  file { "/path/to/file":
    content => template("my_template")
(Continue reading)

Permalink | Reply | 8 comments |
headers
Matt Moor | 1 May 2007 04:15

Re: Custom functions and facts

Dustin Kanske wrote:
> Hello!
>
> I've been trying to use facts from Facter in a custom function. I've
> been following Matthew's entry in the wiki
> (http://www.reductivelabs.com/trac/puppet/wiki/WritingYourOwnFunctions).
>
> What i'm seeing is that Facter['fqdn'].value is always returning the
> fqdn of the puppetmaster host. I was expecting the fqdn of the client
> host.
That seems to be working as designed, based on what Matt's got on the wiki:

"Your function will be executed on the server. This means that any files 
or other resources you reference must be available on the server, and 
you can't do anything that requires direct access to the client machine."

Perhaps a better question is whether or not (and how) it's possible to 
write a custom function that's executed on the client?

Cheers,

Matt

--

-- 
Matt Moor
Infrastructure Manager
Vquence - Making Video Clickable
W: http://www.vquence.com
E: matt.moor <at> vquence.com
P: +61 2 8215 0574
(Continue reading)

Permalink | Reply | 6 comments |
headers
Luke Kanies | 1 May 2007 04:17
Gravatar

Re: Custom functions and facts

On Apr 30, 2007, at 8:26 PM, Dustin Kanske wrote:

> Hello!
>
> I've been trying to use facts from Facter in a custom function. I've
> been following Matthew's entry in the wiki
> (http://www.reductivelabs.com/trac/puppet/wiki/ 
> WritingYourOwnFunctions).
>
> What i'm seeing is that Facter['fqdn'].value is always returning the
> fqdn of the puppetmaster host. I was expecting the fqdn of the client
> host.

Nope, that's the local library, on the server.

If you want a variable from the parser, use 'lookupvar(varname)'.  By  
default it will return "" on undefined varables, but if you add  
'false' as a second argument, it will return :missing instead.

  --
  To get back my youth I would do anything in the world, except take
  exercise, get up early, or be respectable.  -- Oscar Wilde

  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com
Permalink | Reply | 0 comments |
headers
Luke Kanies | 1 May 2007 05:09
Gravatar

Re: Custom functions and facts

On Apr 30, 2007, at 9:15 PM, Matt Moor wrote:
> That seems to be working as designed, based on what Matt's got on  
> the wiki:

That's actually Jeff McCune's document, FWIW.

> Perhaps a better question is whether or not (and how) it's possible to
> write a custom function that's executed on the client?

Yes, as long as it doesn't need to accept any arguments; it's called  
a "fact". :)

In other words, no, not in the way you're thinking -- the client does  
a clean hand-off of everything it knows, the parser compiles the  
configuration with no more interaction with the client, and the  
complete configuration is sent back to the client.

  --
  Morgan's Second Law:
     To a first approximation all appointments are canceled.
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com
Permalink | Reply | 5 comments |
headers
Dustin Kanske | 1 May 2007 05:38
Picon

Re: Custom functions and facts

On 4/30/07, Luke Kanies <luke <at> madstop.com> wrote:
> On Apr 30, 2007, at 9:15 PM, Matt Moor wrote:
> > That seems to be working as designed, based on what Matt's got on
> > the wiki:
>
> That's actually Jeff McCune's document, FWIW.
>
> > Perhaps a better question is whether or not (and how) it's possible to
> > write a custom function that's executed on the client?
>
> Yes, as long as it doesn't need to accept any arguments; it's called
> a "fact". :)
>
> In other words, no, not in the way you're thinking -- the client does
> a clean hand-off of everything it knows, the parser compiles the
> configuration with no more interaction with the client, and the
> complete configuration is sent back to the client.
>

So the root of all of this is, how do you get a fact about the client
in a custom function on the server?

The answer seems to be lookupvar('ipaddress') and not
Facter['ipaddress'].value (as described in
WritingYourOwnFunctions). lookupvar('ipaddress') gives me the right
answer on my setup.

The article specifically says that you can use facts about the client
in functions on the server but the way it said to get the fact didn't
work for me :)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jason Rojas | 1 May 2007 05:49

Regex for Nodes?

Forgive me if this has been discussed already (and please point me i the
correct direction)
But I have been trying to find a way to classify nodes in site.pp via
webserver*.domain.com.
Any hints?
-Jason
Permalink | Reply | 2 comments |
headers
Luke Kanies | 1 May 2007 06:00
Gravatar

ANNOUNCE: 0.22.4

I've just put it out; hopefully the packagers will get it in place  
soon.  Here's the changelog:

     Execs now autorequire the user they run as, as long as the user
     is specified by name. (#430)

     Files on the local machine but not on the remote server during
     a source copy are now purged if purge => true. (#594)

     Providers can now specify that some commands are optional (#585).
     Also, the 'command' method returns nil on missing commands,
     rather than throwing an error, so the presence of commands
     be tested.

     The 'useradd' provider for Users can now manage passwords.
     No other providers can, at this point.

     Parameters can now declare a dependency on specific
     features, and parameters that require missing features
     will not be instantiated.  This is most useful for
     properties.

     FileParsing classes can now use instance_eval to add
     many methods at once to a record type.

     Modules no longer return directories in the list of found
     manifests (#588).

     The crontab provider now defaults to root when there is no
     USER set in the environment.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Matt Palmer | 1 May 2007 07:08
Favicon
Gravatar

Re: Custom functions and facts

On Mon, Apr 30, 2007 at 05:38:48PM -1000, Dustin Kanske wrote:
> On 4/30/07, Luke Kanies <luke <at> madstop.com> wrote:
> > On Apr 30, 2007, at 9:15 PM, Matt Moor wrote:
> > > That seems to be working as designed, based on what Matt's got on
> > > the wiki:
> >
> > That's actually Jeff McCune's document, FWIW.
> >
> > > Perhaps a better question is whether or not (and how) it's possible to
> > > write a custom function that's executed on the client?
> >
> > Yes, as long as it doesn't need to accept any arguments; it's called
> > a "fact". :)
> >
> > In other words, no, not in the way you're thinking -- the client does
> > a clean hand-off of everything it knows, the parser compiles the
> > configuration with no more interaction with the client, and the
> > complete configuration is sent back to the client.
> >
> 
> So the root of all of this is, how do you get a fact about the client
> in a custom function on the server?
> 
> The answer seems to be lookupvar('ipaddress') and not
> Facter['ipaddress'].value (as described in
> WritingYourOwnFunctions). lookupvar('ipaddress') gives me the right
> answer on my setup.
> 
> The article specifically says that you can use facts about the client
> in functions on the server but the way it said to get the fact didn't
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dustin Kanske | 1 May 2007 07:28
Picon

Re: Custom functions and facts

Thanks for writing up the article, Matt. I was surprised to see that
you had written up exactly what I was looking for :)

> I suspect my testing method for the code in that article[1] may not have
> been entirely sufficient.  I *thought* Facter['varname'] worked, but when
> all is said and done, it does seem a bit stupid to do client fact lookups on
> the server via Facter[].
>
> On the upside, it's a wiki, so feel free to fix up the code to do the right
> thing... <grin>
>

Heh. I didn't want to update it if it was working for other people
though. I'll drop in my example soon into the wiki.

Thanks for your reply,
-Dustin

> - Matt
>
> [1] I don't know which page Luke was saying that Jeff wrote, but
> WritingYourOwnFunctions is entirely my fault, as the page history will
> attest.
>
>
> --
> English is about as pure as a cribhouse whore. We don't just borrow
> words; on occasion, English has pursued other languages down alleyways
> to beat them unconscious and rifle their pockets for new vocabulary."
>         -- James D. Nicoll, resident of rec.arts.sf.written
(Continue reading)

Permalink | Reply | 0 comments |

Gmane