So, I''ve been doing something like this for applications that have a
client and server component...
node base_node {
include syslog_ng::client
}}
node app_node inherits base_node {
}
node syslog_server inherits base_node {
include syslog_ng::server
}
... because I want the client portion, syslog-ng in this case to be
installed on everything. However, the server node also has a server
running. When you do this, puppet complains because on the
syslog_server node, both are trying to manage the same files
(/etc/syslog-ng/syslog-ng.conf for example).
What''s the best approach for this? I could combine both the client and
server into one module and simple use case statements to serve out
files based on their hostname, but that seems ugly. Is there a better
idea? Can I "UN" include a class?
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@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.
Douglas Garstang wrote:> What''s the best approach for this? I could combine both the client and > server into one module and simple use case statements to serve out > files based on their hostname, but that seems ugly. Is there a better > idea? Can I "UN" include a class? >If you use external node lookup, you can specify that one node includes syslog_ng::server and the rest include syslog_ng::client. http://reductivelabs.com/trac/puppet/wiki/ExternalNodes -scott -- 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.
Douglas Garstang
2009-Dec-14 05:21 UTC
Re: [Puppet Users] Inherited Client and Server Apps
I don''t think you understood my question Scott. In any case, I''m avoiding external nodes because you lose all ability to version control. I found the solution anyway. It''s to include the client node further up the node hierarchy, since all nodes will have the client, and then further down the node hierarchy include the server. Then, make the server inherit from the client, and override those resources in the server that are defined in the client. Seems to work nicely (so far). Doug. On Sun, Dec 13, 2009 at 9:00 PM, Scott Smith <scott@ohlol.net> wrote:> Douglas Garstang wrote: >> What''s the best approach for this? I could combine both the client and >> server into one module and simple use case statements to serve out >> files based on their hostname, but that seems ugly. Is there a better >> idea? Can I "UN" include a class? >> > > If you use external node lookup, you can specify that one node includes syslog_ng::server and the > rest include syslog_ng::client. > > http://reductivelabs.com/trac/puppet/wiki/ExternalNodes > > -scott > > -- > > 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. > > >-- Regards, Douglas Garstang http://www.linkedin.com/in/garstang Email: doug.garstang@gmail.com Cell: +1-805-340-5627 -- 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.
2009/12/14 Douglas Garstang <doug.garstang@gmail.com>:> I don''t think you understood my question Scott. > > In any case, I''m avoiding external nodes because you lose all ability > to version control.How do you lose version control? You can easily version a whole variety of external node stores. You can even include the version in Puppet by specifying a variable in each node. Potentially you can even notify Puppet via logs by adding a "notice" function that outputs the variable with the version tag/number. With the rewrite of the event system (Rowlf I think) this will be even easier. Regards James Turnbull -- Author of: * Pro Linux System 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) -- 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.
Douglas Garstang
2009-Dec-14 05:42 UTC
Re: [Puppet Users] Inherited Client and Server Apps
On Sun, Dec 13, 2009 at 9:25 PM, James Turnbull <james@lovedthanlost.net> wrote:> 2009/12/14 Douglas Garstang <doug.garstang@gmail.com>: >> I don''t think you understood my question Scott. >> >> In any case, I''m avoiding external nodes because you lose all ability >> to version control. > > How do you lose version control? You can easily version a whole > variety of external node stores. You can even include the version in > Puppet by specifying a variable in each node. Potentially you can > even notify Puppet via logs by adding a "notice" function that outputs > the variable with the version tag/number. > > With the rewrite of the event system (Rowlf I think) this will be even easier.James, I''m no expert at external nodes, so I went and read: http://reductivelabs.com/trac/puppet/wiki/ExternalNodes That doc still really doesn''t say exactly what external nodes are. It''s a way of storing node info in an external source such as MySQL or LDAP, right? 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@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.
Douglas Garstang wrote:> I don''t think you understood my question Scott. >Ah, yes and no. I incorrectly assumed you had the syslog_ng::server class managing itself as a client as well. > That doc still really doesn''t say exactly what external nodes are. > It''s a way of storing node info in an external source such as MySQL or > LDAP, right? Who''s to say you can''t modify your access API to maintain a history of node changes? The back end doesn''t contain any manifests, just a list of classes and variables for a node. -scott -- 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> I''m no expert at external nodes, so I went and read: > http://reductivelabs.com/trac/puppet/wiki/ExternalNodes > > That doc still really doesn''t say exactly what external nodes are. > It''s a way of storing node info in an external source such as MySQL or > LDAP, right?or a yaml file, a csv file, <whatever you can imagine, can be read by a script and can be revision controlled> cheers pete -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksl6WMACgkQbwltcAfKi3+ZuQCcC4HhjqYRpOsI80JzCtnVE+yf NfwAoJbvin2B6sZ6s1GFS9gyqPQ7mQqb =RtKl -----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.
Douglas Garstang
2009-Dec-14 08:06 UTC
Re: [Puppet Users] Inherited Client and Server Apps
On Sun, Dec 13, 2009 at 11:29 PM, Peter Meier <peter.meier@immerda.ch> wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > >> I''m no expert at external nodes, so I went and read: >> http://reductivelabs.com/trac/puppet/wiki/ExternalNodes >> >> That doc still really doesn''t say exactly what external nodes are. >> It''s a way of storing node info in an external source such as MySQL or >> LDAP, right? > > or a yaml file, a csv file, <whatever you can imagine, can be read by a > script and can be revision controlled> > > cheers peteI don''t get it. What''s the benefit of putting your nodes in a yaml file or a csv file rather than a puppet node file? 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@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.
There are many reasons... e.g. if you dont want to allow other people access to your manifests, or you want a web gui to manage your nodes (e.g. foreman) etc maybe you nodes follow a name standards (which should define your host names etc) and probably I''ve missed many other good arguments. Ohad On Mon, Dec 14, 2009 at 4:06 PM, Douglas Garstang <doug.garstang@gmail.com>wrote:> On Sun, Dec 13, 2009 at 11:29 PM, Peter Meier <peter.meier@immerda.ch> > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > >> I''m no expert at external nodes, so I went and read: > >> http://reductivelabs.com/trac/puppet/wiki/ExternalNodes > >> > >> That doc still really doesn''t say exactly what external nodes are. > >> It''s a way of storing node info in an external source such as MySQL or > >> LDAP, right? > > > > or a yaml file, a csv file, <whatever you can imagine, can be read by a > > script and can be revision controlled> > > > > cheers pete > > I don''t get it. What''s the benefit of putting your nodes in a yaml > file or a csv file rather than a puppet node file? > > 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@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > >-- 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 Douglas Garstang wrote:> On Sun, Dec 13, 2009 at 11:29 PM, Peter Meier <peter.meier@immerda.ch> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >>> I''m no expert at external nodes, so I went and read: >>> http://reductivelabs.com/trac/puppet/wiki/ExternalNodes >>> >>> That doc still really doesn''t say exactly what external nodes are. >>> It''s a way of storing node info in an external source such as MySQL or >>> LDAP, right? >> or a yaml file, a csv file, <whatever you can imagine, can be read by a >> script and can be revision controlled> >> >> cheers pete > > I don''t get it. What''s the benefit of putting your nodes in a yaml > file or a csv file rather than a puppet node file? >That''s just one example. You can back-end it with any script or DB containing node information. When the Puppet client connects the master queries the external node script and says "Do you have a host called insertnamehere?". This allows you to: a) saves you defining each node in a Puppet manifest and allowing a greater flexibility of maintenance. b) potentially query external data sources (such as LDAP or asset management stores) that already know about your hosts meaning you only maintain said information in one place. Regards James Turnbull - -- Author of: * Pro Linux System 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) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEVAwUBSyXzCCFa/lDkFHAyAQJTywf/X5NhpGUjjQhH6a2/c110cC3EMJ2fK/PW XTfba3ld2D8iy+5DAHLU3IZt0rPZYLmD56+puHBqUQUQx3jLJctCVJF4sjqbZ9Py VFgOSSnqq++sNkHbwVowSmyEjykRIlNrW1Rrc0+e4FXUdx5LP07sbCwa3x/VdNGE +HnZTZQegcWAbbJ6O3Dp66n8KsYnMwNzFscNHP4boYc1WjyCohokmhk5JReC+ctp Y4Bca8ZzhF2jgcjhEFQwO7unYlIAhxeINger8SsevOYsBbXsrGqXTbco6mxotSJl aFb225j+w9MTYCzOPquslVQICHrXvLpnpoS7tlg3QI8oQHi0HiXC+Q==0K1i -----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 Mon, Dec 14, 2009 at 2:10 AM, James Turnbull <james@lovedthanlost.net> wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Douglas Garstang wrote: >> On Sun, Dec 13, 2009 at 11:29 PM, Peter Meier <peter.meier@immerda.ch> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>>> I''m no expert at external nodes, so I went and read: >>>> http://reductivelabs.com/trac/puppet/wiki/ExternalNodes >>>> >>>> That doc still really doesn''t say exactly what external nodes are. >>>> It''s a way of storing node info in an external source such as MySQL or >>>> LDAP, right? >>> or a yaml file, a csv file, <whatever you can imagine, can be read by a >>> script and can be revision controlled> >>> >>> cheers pete >> >> I don''t get it. What''s the benefit of putting your nodes in a yaml >> file or a csv file rather than a puppet node file? >> > > That''s just one example. You can back-end it with any script or DB > containing node information. When the Puppet client connects the > master queries the external node script and says "Do you have a host > called insertnamehere?". > > This allows you to: > > a) saves you defining each node in a Puppet manifest and allowing a > greater flexibility of maintenance. > b) potentially query external data sources (such as LDAP or asset > management stores) that already know about your hosts meaning you > only maintain said information in one place. > > Regards >A subtle advantage of using a external nodes tool is that parameters assigned to nodes in a an external node tool are set a top scope not in the scope created by the node assignment in language. This leaves you free to set default parameters for a base node assignment and define whatever inheritance model you wish for parameters set in the children. In the end, Puppet accepts a list of parameters for the node and those parameters when set using an External Node tool are set at top scope. That being said, Doug, I don''t think external nodes are really the answer to your problem. Commonly, when modeling client server applications you need to manage the same file resource. I generally use class inheritance to model these situations. I would inside of my syslog_ng module create a base class that models the client configuration. class syslog_ng { .... file {''/etc/syslog-ng/syslog-ng.conf'': ... } } Next I would create a child class for modeling the server configuration. Instead of managing the same file resource twice, override the relevant parameters for the file resource in your child class. class syslog_ng::server inherits syslog_ng { File[''/etc/syslog-ng/syslog-ng.conf''] { #overide parameters in here. ... } } Now your node assignment that you described will work because you have eliminated the duplicate resource definition. http://reductivelabs.com/trac/puppet/wiki/PuppetIntroduction#inheritance Cheers, Teyo -- Teyo Tyree :: www.reductivelabs.com :: +1.615.275.5066 -- 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 Teyo If you have a chance do you want to throw your email and my email into the External nodes page? It really needs some more explanation. Or I can if you''re busy. Cheers James Turnbull - -- Author of: * Pro Linux System 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) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEVAwUBSya0GyFa/lDkFHAyAQIh1wgAtu4EMAg83s4F0JOfA0VqzFvCbngs7I0F Hb9xrMooD5oOa8HJclfaUqMH9pcD4w5Lv8zcF+w2KMWBDaNQTXMOaNeU/n2gPEzZ R6wc6dTxKmWbyShnWHE6v4OofiOFMQzHJ3ibIwJWyOguoWM46LH+ANYLauugFVmj eWhRG0oegiyzbD1eXaUxhDl7ZgCTUmr+OF5aaik+X3BOYkSY4tJVK5HAFU/O8vUS udaBQ1v/KFJRHQYmFbT1tDOgvaDEyM42BKYvqXt8YK7+2XBDLJqbXM7DTjsUvb1m heVjvBFbEK0cGtCbmrV7TX50ABbItV6jre4PKoiY1qltoQU+UEyK0w==IMem -----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.
Yeah, I can update the external nodes page no problem. On Mon, Dec 14, 2009 at 3:54 PM, James Turnbull <james@lovedthanlost.net> wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Teyo > > If you have a chance do you want to throw your email and my email > into the External nodes page? It really needs some more explanation. > > Or I can if you''re busy. > > Cheers > > James Turnbull > > - -- > Author of: > * Pro Linux System 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) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEVAwUBSya0GyFa/lDkFHAyAQIh1wgAtu4EMAg83s4F0JOfA0VqzFvCbngs7I0F > Hb9xrMooD5oOa8HJclfaUqMH9pcD4w5Lv8zcF+w2KMWBDaNQTXMOaNeU/n2gPEzZ > R6wc6dTxKmWbyShnWHE6v4OofiOFMQzHJ3ibIwJWyOguoWM46LH+ANYLauugFVmj > eWhRG0oegiyzbD1eXaUxhDl7ZgCTUmr+OF5aaik+X3BOYkSY4tJVK5HAFU/O8vUS > udaBQ1v/KFJRHQYmFbT1tDOgvaDEyM42BKYvqXt8YK7+2XBDLJqbXM7DTjsUvb1m > heVjvBFbEK0cGtCbmrV7TX50ABbItV6jre4PKoiY1qltoQU+UEyK0w=> =IMem > -----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. > > >-- Teyo Tyree :: www.reductivelabs.com :: +1.615.275.5066 -- 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 13.12.2009 23:09, Douglas Garstang wrote:> So, I''ve been doing something like this for applications that have a > client and server component... > > node base_node { > include syslog_ng::client > }} > > node app_node inherits base_node { > } > > node syslog_server inherits base_node { > include syslog_ng::server > } > > ... because I want the client portion, syslog-ng in this case to be > installed on everything. However, the server node also has a server > running. When you do this, puppet complains because on the > syslog_server node, both are trying to manage the same files > (/etc/syslog-ng/syslog-ng.conf for example). > > What''s the best approach for this? I could combine both the client and > server into one module and simple use case statements to serve out > files based on their hostname, but that seems ugly. Is there a better > idea? Can I "UN" include a class?If the syslog_ng::client and syslog_ng::server classes are expected to be included on the same node, they should be designed to cooperate. This is achieved most efficiently by either using a common base class (e.g. syslog_ng::base) or inheriting one from the other, depending on the functional relationships (e.g. I have ssh on all servers, but sshd only on a few, thus ssh::server inherits ssh::client and uses the basic setup from there). Regards, DavidS -- 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.