Puppet users - Mar 2007 - Refering to node name (or part of node name) in a class / function

Hi,

I was wondering if it is possible to gain access to the nodename as a
variable, in order to refer to the name or part of it inside a class.

Eg: I have a lot of sites that essentially have the same configuration,
except they are in different domains and have different requirements for
things like resolv.conf. I can manage this by creating a node definition
for each node and specifying some local variables which are then used to
populate the resolv.conf files, but it would be a lot nicer if I could
move this functionality into the resolvconf class and have it look up
the appropriate settings based on the nodename (actually, the domain
part of the nodename).


I could also create a site class, and get the nodes to inherit that, but
it still requires explicitally setting up the nodes, which I''d like to
avoid.

I''ve looked over the docs but I can''t see anything that looks
remotely
like what I''m after. Any thoughts?

> I was wondering if it is possible to gain access to the nodename as a
> variable, in order to refer to the name or part of it inside a class.
>   
<snip>
> I''ve looked over the docs but I can''t see anything that
looks remotely
> like what I''m after. Any thoughts?
>   
And of course, no sooner do I send this than I realise how to do it: use
the "fqdn" fact. 

If anyone has any feedback on my original problem, including any
problems they might have had doing similar things, I''d be interested

On Mar 29, 2007, at 6:03 PM, Daniel Lawson wrote:
>
> Hi,
>
> I was wondering if it is possible to gain access to the nodename as a
> variable, in order to refer to the name or part of it inside a class.
>
> Eg: I have a lot of sites that essentially have the same  
> configuration,
> except they are in different domains and have different  
> requirements for
> things like resolv.conf. I can manage this by creating a node  
> definition
> for each node and specifying some local variables which are then  
> used to
> populate the resolv.conf files, but it would be a lot nicer if I could
> move this functionality into the resolvconf class and have it look up
> the appropriate settings based on the nodename (actually, the domain
> part of the nodename).
You''ve said you already found the fqdn fact, but you can as easily  
use the domain and/or hostname fact.  Just run ''facter'' on the
command line on your client to get an idea of all of the facts  
available to you.

You can also create a custom function that can look up this  
information for you on the server based on any of these facts; see  
Jeff''s docs[1] on that for more info.

1 - https://reductivelabs.com/trac/puppet/wiki/WritingYourOwnFunctions

  --
  He played the king as if afraid someone else would play the ace.
  --John Mason Brown
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

> You''ve said you already found the fqdn fact, but you can as easily
> use the domain and/or hostname fact.  Just run ''facter''
on the
> command line on your client to get an idea of all of the facts  
> available to you.
>   
Yeah, I got that far. I was mostly wanting to do a wildcard match on the
nodename, then I thought about using the nodename as a variable but I
didn''t think of using facter.

I''ve already added some custom facts to present more detailed
information for Debian and Ubuntu, such as the codename (eg, sarge,
dapper, etc), so I can push out specific /etc/apt/sources.list files and
tweak package names accordingly (some packages change names between
debian and ubuntu etc):

http://reductivelabs.com/cgi-bin/puppet.cgi/wiki/DebianUbuntu_CodenameRecipe

Daniel Lawson a écrit :
>> You''ve said you already found the fqdn fact, but you can as
easily
>> use the domain and/or hostname fact.  Just run
''facter'' on the
>> command line on your client to get an idea of all of the facts  
>> available to you.
>>   
>>     
>
> Yeah, I got that far. I was mostly wanting to do a wildcard match on the
> nodename, then I thought about using the nodename as a variable but I
> didn''t think of using facter.
>
> I''ve already added some custom facts to present more detailed
> information for Debian and Ubuntu, such as the codename (eg, sarge,
> dapper, etc), so I can push out specific /etc/apt/sources.list files and
> tweak package names accordingly (some packages change names between
> debian and ubuntu etc):
>
>
http://reductivelabs.com/cgi-bin/puppet.cgi/wiki/DebianUbuntu_CodenameRecipe
>   

you can have those information with facter on debian too , just install  
the package lsb-release  and you will have this :


lsbdistcodename => sarge
lsbdistdescription => Debian GNU/Linux
lsbdistid => Debian
lsbdistrelease => 3.1
lsbrelease => n/a

and this work on redhat too :)

-- 
Cordialement,
Ghislain




_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

> you can have those information with facter on debian too , just
> install  the package lsb-release  and you will have this :
>
>
> lsbdistcodename => sarge
> lsbdistdescription => Debian GNU/Linux
> lsbdistid => Debian
> lsbdistrelease => 3.1
> lsbrelease => n/a
>
> and this work on redhat too :)
Well gee, that makes that a heap easier too.  I wish this was documented
better - I primarily use sarge everywhere, added in Ubuntu support to my
facter script because I could. I obviously didn''t read far enough into
facter.rb or I''d have seen this :)

I''ll see about writing better docs later

> Well gee, that makes that a heap easier too.  I wish this was documented
> better - I primarily use sarge everywhere, added in Ubuntu support to my
> facter script because I could. I obviously didn''t read far enough
into
> facter.rb or I''d have seen this :)
>
> I''ll see about writing better docs later
in fact i was searching how to have that information also

so i used my googlebrain on linux lsb and done an apt-cache search lsb. 
I found this package and when installed i just saw that facter popped up 
new facts !! :)

perhaps the docs could  have a note about this :)
i added the comment to your wiki page.



-- 
Cordialement,
Ghislain ADNET.
AQUEOS.

Attention !  Toute demande de support ou commande de domaine par email 
sera refusée, pour cela utilisez https://support.aqueos.net.  

Pour tout contact nos coordonnées :  
http://www.aqueos.com/aqueos-services-informatiques-societe.php
Fax: 01.72.70.32.66
 




_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

On Fri, Mar 30, 2007 at 12:16:22PM +0200, ADNET Ghislain wrote:
> 
> >Well gee, that makes that a heap easier too.  I wish this was
documented
> >better - I primarily use sarge everywhere, added in Ubuntu support to
my
> >facter script because I could. I obviously didn''t read far
enough into
> >facter.rb or I''d have seen this :)
> >
> >I''ll see about writing better docs later
> in fact i was searching how to have that information also
> 
> so i used my googlebrain on linux lsb and done an apt-cache search lsb. 
> I found this package and when installed i just saw that facter popped up 
> new facts !! :)
> 
> perhaps the docs could  have a note about this :)
> i added the comment to your wiki page.
The packages for each distribution can also pull in (or just suggest it in
the debian case) lsb_release if needed. The problem at least for redhat is
that lsb_release requires /usr/bin/lp(r) + some X11 libs so you end up with
a lot of extra packages and this could be a problem for minimal installs.

Cheers,
Kostas Georgiou