I'd like to weigh in on this discussion a little bit.
First of all, Alexandre, you might feel more at home with bcfg2. Bcfg2 by
default manages *everything*, and tells you if something appears that is
unmanaged, forcing you to either manage it or remove it. We looked at bcfg2,
and whereas I liked its model, the puppet community is better, and bcfg2 uses
XML files for configuration *shudder*.
That is a feature I'd love to see in puppet. If unknown and new things appear
on one of my systems, I'd love to know about it. That way I can either decide
to add it to a manifest, or remove it.
That, to me, is better than applying a general stripdown. A general stripdown
(other than "remove everything not explicitly managed") doesn't deal with the
unknowns, and the "remove everything not explicitly managed" doesn't allow for
emergency fixes.
tl;dr: I want to know when *anything* on my system changes, puppet doesn't let
me do that.
Cheers,
Eric
On Thu, Dec 17, 2009 at 07:08:51PM -0800, Alexandre wrote:
> 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.
>
>
--
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: egerl...@feds.uwaterloo.ca
--
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.
