I am using puppet to configure EC2 instances at Amazon. After each restart, the hostname can change and I don''t always have a public DNS name. I''d like to have the client specify their own node names. Actually, what I really want is for clients to specify a node "type". In other words, I don''t care what the machine or domain name is... I just want to know the purpose of the node. Is a "compute" node or a "database" node, each of which could be on many machines. Is there a clean way to do this with puppet? I see the --fqdn option to puppetd. Will there be problems if multiple machines use the same value with this option? --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
schickb wrote:> I''d like to have the client specify their own node names. Actually, > what I really want is for clients to specify a node "type". In other > words, I don''t care what the machine or domain name is... I just want > to know the purpose of the node. Is a "compute" node or a "database" > node, each of which could be on many machines.I would probably do it with something like this: class node::compute { ... } class node::database { ... } node default { include "node::$nodetype" } and get myself a custom fact ''nodetype'' that gets set in some suitable way. (One quick way to make a custom fact is by setting an environment variable FACTER_NODETYPE when running puppet/puppetd. However, a "real" custom fact is probably cleaner.) /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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Jun 4, 4:26 pm, Thomas Bellman <bell...@nsc.liu.se> wrote:> I would probably do it with something like this: > > class node::compute { ... } > class node::database { ... } > > node default > { > include "node::$nodetype" > } > > and get myself a custom fact ''nodetype'' that gets set in some suitable > way.Thanks for the suggestion. I wish there was a simpler approach, like specifying the "type" on the puppetd command-line. In large server farms it seems like it would be a really common need to specify nodes by purpose rather than machine name. -Brad --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Jun 4, 4:26 pm, Thomas Bellman <bell...@nsc.liu.se> wrote:> However, a "real" > custom fact is probably cleaner.) >I''m working on a "real" fact by following these steps: http://reductivelabs.com/trac/puppet/wiki/AddingFacts I verified that the custom fact works when run locally on the server. On the client when I run: puppetd --server hostname --test --factsync I see the custom fact being retrieved and stored in /var/lib/puppet/ facts on the client. But the custom fact does not seem to run and the value is not sent to the server. I never see the "info: Loading fact nodetype" message on the client, and the $nodetype substitution fails on the server. I am running 0.24.5 on client and server. Both client and server are Ubuntu. Here is the custom fact: #!/usr/bin/ruby -w Facter.add("nodetype") do setcode do f = File.open(''/var/ec2/nodetype'') f.gets.chomp end end Any ideas? --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brad wrote:> On Jun 4, 4:26 pm, Thomas Bellman <bell...@nsc.liu.se> wrote: >> I would probably do it with something like this: >> >> class node::compute { ... } >> class node::database { ... } >> >> node default >> { >> include "node::$nodetype" >> } >> >> and get myself a custom fact ''nodetype'' that gets set in some suitable >> way. > > Thanks for the suggestion. I wish there was a simpler approach, like > specifying the "type" on the puppetd command-line. In large server > farms it seems like it would be a really common need to specify nodes > by purpose rather than machine name.What about tags? http://reductivelabs.com/trac/puppet/wiki/UsingTags Also Facter 1.5.5+ has some dedicated EC2 facts much like those at: http://reductivelabs.com/trac/puppet/wiki/Recipes/AmazonEC2 Regards James Turnbull - -- Author of: * Pro Linux Systems Administration (http://www.amazon.com/gp/product/1430219122/) * Pulling Strings with Puppet (http://www.amazon.com/gp/product/1590599780/) * Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) * Hardening Linux (http://www.amazon.com/gp/product/1590594444/) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoopl8ACgkQ9hTGvAxC30Dc9QCginKEpoDmIj1On6AOriOp/MRZ ke0An3e2tzP8Vo8CrI4d3wbj46RIaUc2 =AUIw -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Jun 4, 8:27 pm, Brad <schi...@gmail.com> wrote:> I''m working on a "real" fact by following these steps: > http://reductivelabs.com/trac/puppet/wiki/AddingFacts > > I verified that the custom fact works when run locally on the server. > On the client when I run: > puppetd --server hostname --test --factsync > > I see the custom fact being retrieved and stored in /var/lib/puppet/ > facts on the client. But the custom fact does not seem to run and the > value is not sent to the server.Ok, it looks like that link above is old information. It would be nice if that was mentioned at the *top* of that text rather than the bottom. I followed this instead: http://reductivelabs.com/trac/puppet/wiki/PluginsInModules And everything is works as expected. -Brad --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Brad wrote:> On Jun 4, 8:27 pm, Brad <schi...@gmail.com> wrote: >> I''m working on a "real" fact by following these steps: >> http://reductivelabs.com/trac/puppet/wiki/AddingFacts >> >> I verified that the custom fact works when run locally on the server. >> On the client when I run: >> puppetd --server hostname --test --factsync >> >> I see the custom fact being retrieved and stored in /var/lib/puppet/ >> facts on the client. But the custom fact does not seem to run and the >> value is not sent to the server. > > Ok, it looks like that link above is old information. It would be nice > if that was mentioned at the *top* of that text rather than the > bottom. I followed this instead: http://reductivelabs.com/trac/puppet/wiki/PluginsInModules > > And everything is works as expected.The page does say - three lines down from the top: "You can add new facts by writing a snippet of ruby code. Puppet uses the Plugins InModules approach to distribute these facts to your hosts." But yes it was a little confusing. I''ve edited the page to make it easier to understand. Please let me know if that has helped. The wiki is also open to be edited. Please feel free to create a login and update the documentation if you would prefer. Regards James Turnbull -- Author of: * Pro Linux Systems Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux)
On Jun 5, 12:39 am, James Turnbull <ja...@lovedthanlost.net> wrote:> > But yes it was a little confusing. I''ve edited the page to make it > easier to understand. Please let me know if that has helped.Thanks but it still didn''t seem very clear to me. Might as well just explain the situation right at the top. I just made a page edit. -Brad --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Brad wrote:> On Jun 5, 12:39 am, James Turnbull <ja...@lovedthanlost.net> wrote: >> But yes it was a little confusing. I''ve edited the page to make it >> easier to understand. Please let me know if that has helped. > > Thanks but it still didn''t seem very clear to me. Might as well just > explain the situation right at the top. I just made a page edit. >But your edit is, in fact, not correct. The last section in the page is the legacy section. All other sections are correct. You still create, test and run facts as described. The only change is the use of the plugins in modules approach rather than factsync. Regards James Turnbull -- Author of: * Pro Linux Systems Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux)
James Turnbull wrote:> Brad wrote: >> On Jun 5, 12:39 am, James Turnbull <ja...@lovedthanlost.net> wrote: >>> But yes it was a little confusing. I''ve edited the page to make it >>> easier to understand. Please let me know if that has helped. >> Thanks but it still didn''t seem very clear to me. Might as well just >> explain the situation right at the top. I just made a page edit. >> > But your edit is, in fact, not correct. The last section in the page is > the legacy section. All other sections are correct. You still create, > test and run facts as described. The only change is the use of the > plugins in modules approach rather than factsync.Though perhaps I should not say - not correct - rather calling out the legacy distribution method at the top of the page is likely to make people confused. I''ve made the legacy section title clearer and explained and expanded several sections of the page to very clearly point to the pluginsinmodules page. Regards James Turnbull -- Author of: * Pro Linux Systems Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux)
I find it difficult to work out how best to document all this given that plugins in modules are still not particularly well supported with environments, and most people I''ve come across using environments heavily are still using factsync, no matter how "legacy" it seems. --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nigel Kersten wrote:> I find it difficult to work out how best to document all this given > that plugins in modules are still not particularly well supported with > environments, and most people I''ve come across using environments > heavily are still using factsync, no matter how "legacy" it seems.I guess it is the opposite for me - I don''t heavily use environments so I find myself using plugins in modules for everything. The fix for this is #1175 which is currently scheduled for 0.26.0. I wonder if it''s feasible to move this up? Regards James Turnbull - -- Author of: * Pro Linux Systems Administration (http://www.amazon.com/gp/product/1430219122/) * Pulling Strings with Puppet (http://www.amazon.com/gp/product/1590599780/) * Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) * Hardening Linux (http://www.amazon.com/gp/product/1590594444/) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKLGrp9hTGvAxC30ARAoSMAJsFcWil/v/GzuHdY7kIi0bT8V+powCeO/2o v8ZgXKKam4pTb4+O5laVkok=PdZs -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Sun, Jun 7, 2009 at 6:35 PM, James Turnbull<james@lovedthanlost.net> wrote:> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Nigel Kersten wrote: >> I find it difficult to work out how best to document all this given >> that plugins in modules are still not particularly well supported with >> environments, and most people I''ve come across using environments >> heavily are still using factsync, no matter how "legacy" it seems. > > I guess it is the opposite for me - I don''t heavily use environments so > I find myself using plugins in modules for everything. > > The fix for this is #1175 which is currently scheduled for 0.26.0. I > wonder if it''s feasible to move this up?I would have attempted to sort this out myself, but it looks like a hell of a lot of plumbing work in areas that I''ve yet to grok completely. http://projects.reductivelabs.com/issues/1175 voted appropriately... We simply couldn''t use Puppet without environments. -- Nigel Kersten nigelk@google.com System Administrator Google, Inc. --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---