Yes, in fact this is exactly what i have for the services -i want to
install or manage-. A base class with common stuff (eg mysql user,
group, pkg, test directories ... and service disabled by default), and
a child class ...::server with typically just include the service
specific config file and override Service[] to enable it
But this was not my original problem. Let's take an example :
1) i want to apply a general linux stripdown
2) i get a server, which had already stuff on it, maybe services
activated but not used, and on which sometimes people get on and
modify things (file permissions, start services, ...)
3) I want to apply the general stripdown to this server, without
having to know what is there and create a special stripdown just for
this server
4) I still want to install or activate services on this server, while
having the general stripdown still active
So far i can do 1), 2) and 3) with puppet, very simply. My problem is
4). All implementations of 4) i saw in this discussion say i have for
each node, specify exactly what i want to disable and enable, so that
if i have 100 nodes, i have to create 100 different stripdown.
While it is easy saying a node what it should include so that it
provides the needed services, it is big task and unmaintanable to
specify exhaustively what nodes should not include. Especially that
these nodes are used by some people that need some priviledges, but do
not always clean after work or are not sysadmins
On Dec 17, 4:51 pm, Peter Meier <peter.me...@immerda.ch> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > [...]
> > I think this is good general practice of sysadmin to ensure
> > everything on a linux system that is not needed should be removed,
> > restricted or disabled (services, users, dir permissions). As we see
> > here, it seems Puppet can not fullfill this need, except by listing
> > explicitely and exhaustively what needs to be or not be activated for
> > each node. So of course, one way or another, there is a place where i
> > need to tell what should be stripdowned. But i want it to be accepted
> > as the default -state- of the node, unless specified otherwise by
> > including a class which redefines some of the ressources that need to
> > be activated. I do not want my nodes.pp to be 1000000 lines and
> > unmaintanable.
>
> How about doing it the other way round? Generally include the
> stripped-down classes and then include additionally per node the mysql
> class which inherits the stripped down class but overwrites the
> resources to manage mysql:
>
> node default {
> include configsets
>
> }
>
> node mysqlserver {
> include configsets::mysqlserver
>
> }
>
> class configsets {
> include mysql::server
>
> }
>
> class configsets::mysqlserver {
> include config
> include mysql::server::present
>
> }
>
> class mysql::server {
> package{'mysql-server': ensure => absent }
> service{'mysql-server':
> ensure => stopped,
> enable => false,
> require => Package['mysql-server'],
> }
>
> }
>
> class mysql::server::present inherits mysql::server {
> Package['mysql-server']{ ensure => installed }
> Service['mysql-server']{
> ensure => running,
> enable => true,
> }
> file{'/etc/my.conf':
> source => "...."
> notify => Service['mysql-server'],
> }
>
> }
>
> Naming convention could be better, but I think this should generally
> work. You simply include every resource you manage in the general class
> configsets, which gets applied to every node (also due to inheritance,
> reinclusion) but include the "present" class in nodes that need it.
>
> > I do not want my nodes.pp to be 1000000 lines and unmaintanable.
>
> I would generally avoid putting too much into nodes. My nodes look like:
>
> node default {
> $some_var_1 = 'aaa'
> $some_var_2 = 'bbb'
> include configsets
>
> }
>
> node foobar {
> $some_var_1 = 'foo'
> $some_var_2 = 'bar'
> include configsets::foobar
>
> }
>
> And all the actual service includes are done in the module called
> configesets, which can have further abstraction like node-types, i.e.
> physical nodes (class is included depending on the virtual fact) etc.,
> inheritance and so on.
>
> Did I miss some circumstances why this shouldn't work?
>
> cheers pete.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org
>
> iEYEARECAAYFAksp8QQACgkQbwltcAfKi383ZwCdHOZO8yYdo6zooR07tgy5OE7/
> ZhgAoJzWrZoO2ikcrO/ZRJVLE/fPcufr
> =/lYm
> -----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-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
