Inherited Client and Server Apps

[Douglas Garstang]

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.

[Scott Smith]

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

[Douglas Garstang]

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.

> --
>
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@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.g...@gmail.com
Cell: +1-805-340-5627

[James Turnbull]

2009/12/14 Douglas Garstang <doug.g...@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)

[Douglas Garstang]

On Sun, Dec 13, 2009 at 9:25 PM, James Turnbull <ja...@lovedthanlost.net> wrote:
> 2009/12/14 Douglas Garstang <doug.g...@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.

[Scott Smith]

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

[Peter Meier]

-----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-----

[Douglas Garstang]

On Sun, Dec 13, 2009 at 11:29 PM, Peter Meier <peter...@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.

[Ohad Levy]

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

[James Turnbull]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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-----

[Teyo Tyree]

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

[James Turnbull]

-----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-----

[Teyo Tyree]

Yeah, I can update the external nodes page no problem.

> --
>
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>
>
>

[David Schmitt]

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