On 04/25/14 16:14, jcbollinger wrote:
> On Thursday, April 24, 2014 7:35:10 PM UTC-5, Joachim Schrod wrote:
>
> I have a service where there is one server in my net and many
> clients (actually, all systems are clients): CUPS. In client
> setups, one file has to be changed (client.conf), in server setup
> several (cupsd.conf with policy, several printers are installed).
> On the server, client.conf must not be changed.
>
> Is it better to create 2 clases (cupsclient, cupsserver) or one
> class (cups)?
>
> It is better to have two classes, as there is essentially no
> commonality between the resource to be managed in the one case and
> those to be managed in the other.
As became hopefully clear in the rest of my post, I saw that, too;
but didn't know how to realize it. You showed me the hint at the
end of your email; nevertheless I'd like to answer to a few remarks
of you.
> Furthermore, what if you ever
> wanted the same machine to be both the server and one of its own
> clients?
That would be easy, then I'd have a client configuration that would
be applied everywhere and a server configuration just at one node.
The situation with CUPS is that a server MUST NOT be configured as
a client. (As I wrote above.) When a client configuration is
established, the server configuration is ignored. Client and server
configurations are exclusive.
> When I use two classes I have the problem how to specify when the
> right class should be declared: What I would like to have is a
> method to declare cupsclient for all nodes, and override that
> declaration for the one node/role that's the server where it
> should
> be cupsserver. I can't see how I do that properly. (Most class
> declarations are in role files, roles are assigned to nodes via
> Hiera. I don't want to add cupsclient declaration to any and all
> roles except that server role, that repetition is the reason
> that I
> don't like this approach.)
>
> Why /shouldn't/ you add cups::client to every role that needs it,
> and avoid adding it to those roles that don't need it? Although
> you currently want all nodes to be either CUPS clients or a (the)
> CUPS server, it is conceivable that you may someday want to manage
> machines that are neither (e.g. Windows or Mac clients). And where
> else do you have in mind to put the needed declaration anyway?
I want to put the declaration in commons service block that is
declared for all profiles. Every profile needs CUPS printing, there
is just a different module/resource variant for one role.
This is not an installation where a role is installed on many nodes
at the same time; most roles are installed once, maybe twice or at
most on three systems. Since I have many roles, having to repeat
something basic like "printing is activated" in all of them looks
clumsy to me.
When I will have the case that Windows system configuration must be
also supported by that Puppet installation; I'll reconsider. (Mac
uses CUPS as well... ;-)) Until then, I withgo premature
abstractions that I don't need.
>
> Can I specify the class name to be declared as a parameter in
> Hiera?
>
> Sure you can, and that's a fine way to proceed.
Thanks for your example; it was exactly what I needed to go
further. It works now.
> (And isn't that
> what you are doing already to assign role classes to nodes via
> Hiera?)
I assign role classes by listing them as an element in a classes
list attribute in Hiera files. (I've got hiera_include('classes')
in site.pp.) Don't know if that's good or bad for maintenance; as I
wrote, I'm just starting to use Puppet.
I don't even know yet if a pure node/role/profile/module pattern is
really appropriate for me, as most node/role relationships are 1:1
and not n:1. The role abstraction layer has maintenance costs
associated where the gains in an environment like mine is not
really clear. Maybe skipping the role abstraction, and associating
profiles to nodes via Hiera is a better way to go; I'll have to
experiment and find out. (My intent for using Puppet is not
maintenance of many systems. It is configuration of a few systems
that is documented, version controlled, and where installation of
replacement systems is fast and repeatable.)
Best, and thanks for the hint that brought me a working config,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod, Roedermark, Germany
Email: jsch...@acm.org
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/ljgnr0%24mbl%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
