help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Cluster / Groups under cfengine


From: Harish Chauhan
Subject: Cluster / Groups under cfengine
Date: Thu, 19 Feb 2004 13:57:02 -0500


Hi ,

We have a setup that has existing groups and we don't want to disturb the existing groups. Different groups get different files, updates, configuration files, etc

How can I use cfengine to retain the same groups and functionality ?

Looking forward to your reply.....

Thanks
Regards, Harish Chauhan



address@hidden
Sent by: address@hidden

02/19/2004 11:42 AM

Please respond to
help-cfengine

To
address@hidden
cc
Subject
Help-cfengine Digest, Vol 15, Issue 16





Send Help-cfengine mailing list submissions to
                address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
                http://mail.gnu.org/mailman/listinfo/help-cfengine
or, via email, send a message with subject or body 'help' to
                address@hidden

You can reach the person managing the list at
                address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Help-cfengine digest..."


Today's Topics:

  1. Re: Bootstrapping (Luke A. Kanies)
  2. Re: Bootstrapping (Luke A. Kanies)
  3. Re: Bootstrapping (address@hidden)
  4. Re: Bootstrapping  (John Sechrest)
  5. Re: Bootstrapping (Chip Seraphine)
  6. Re: mln (was: Re: Bootstrapping)  (John Sechrest)
  7. Re: Bootstrapping (Luke A. Kanies)
  8. Re: Bootstrapping  (John Sechrest)
  9. Re: Bootstrapping  (John Sechrest)


----------------------------------------------------------------------

Message: 1
Date: Thu, 19 Feb 2004 09:17:56 -0600 (CST)
From: "Luke A. Kanies" <address@hidden>
Subject: Re: Bootstrapping
To: Nate Campi <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 18 Feb 2004, Nate Campi wrote:

> Well I know what I plan to do once I'm done writing a book (unrelated to
> cfengine) - come up with some cfengine best practices and system
> administration best practices all wrapped around debian linux.

If things go well, I may try to write a cfengine book this year.  If you
want one, email O'Reilly. :)

> I want to bootstrap an entire small network, DNS, DHCP,
> routing/gateway/firewalling, web site under CVS control with staging
> site, mail server (postfix/courier or postfix/cyrus), fileserver (NFS
> and samba I guess, maybe AFS if I get around to learning it), directory
> services (LDAP for accounts, probably kerberos for auth and win2k domain
> trusts), automated installation as well.

I've been half-heartedly working on this for a while, and this is one of
the main goals of my consultancy.  I'm trying to get to the point where I
can walk into a company with a CD or an appliance and quickly bootstrap
an automated infrastructure.  A single processor system can do most of
this stuff for most companies, and for those who need more power, it's
pretty easy to bootstrap bigger boxes off the smaller one.

> There's no reason setting up new a network needs to include reinventing
> everything. More small networks could be standardized, and benefit from
> the collective wisdom of the cfengine community (at least the ones
> contributing to this effort) for all the small things that make a system
> run better (like automatically syncing /etc/hosts and /etc/resolv.conf
> to a postfix chroot, which is easy to forget when you move a host to a
> new subnet).
>
> A surprising amount of configuration could be shared across sites,
> enabling networks to get up quickly, and run better. Consultants could
> come into networks they've never been on before, but quickly solve
> problems and roll out new services, since he/she already understands the
> cfengine setup.
>
> This is what I'd want the community-contributed cfengine configs to come
> from - actual use, practices proven on real networks. It would need to
> be it's own project, with active contributers. I plan on starting it on
> my own, then seeing if people want to join in once I have something
> working to get at least a small network up from scratch. It would
> probably need to be a custom debian distro on a CD, to bootstrap the
> whole process from a gold server.

I think it's on topic.  I'd be glad to work with you on it, as that's what
I'll be doing this year anyway (along with a couple other time-consuming
initiatives, like doing enough consulting to continue eating until I get
the bootstrapper done).

Luke

--
"I think that's how Chicago got started.  A bunch of people in New York
said, 'Gee, I'm enjoying the crime and the poverty, but it just isn't
cold enough. Let's go west.' "
    --Richard Jeni



------------------------------

Message: 2
Date: Thu, 19 Feb 2004 09:24:11 -0600 (CST)
From: "Luke A. Kanies" <address@hidden>
Subject: Re: Bootstrapping
To: John Sechrest <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 18 Feb 2004, John Sechrest wrote:

> Nate Campi <address@hidden> writes:
>
>  % A surprising amount of configuration could be shared across sites,
>  % enabling networks to get up quickly, and run better. Consultants could
>  % come into networks they've never been on before, but quickly solve
>  % problems and roll out new services, since he/she already understands the
>  % cfengine setup.
>
>  Yes, but to do this, the cfengine community needs to start abstracting
>  the (global practices) from the (local issues).

That's a really good idea, but I'm not totally convinced this will be very
easy with cfengine.  Mark and I have had long discussions about this, but
my opinion has not changed:  It is very difficult to use cfengine for
abstraction, which means it's very difficult to create
location-independent cfengine configurations.

>  % This is what I'd want the community-contributed cfengine configs to come
>  % from - actual use, practices proven on real networks. It would need to
>  % be it's own project, with active contributers. I plan on starting it on
>  % my own, then seeing if people want to join in once I have something
>  % working to get at least a small network up from scratch. It would
>  % probably need to be a custom debian distro on a CD, to bootstrap the
>  % whole process from a gold server.
>
>  This brings up many questions for me...
>
>  A) Why would this not work as a component of the CFengine work that
>     is already going on?

Because it's essentially separate from cfengine itself.  It's a lot more
than just cfengine.

>  B) Why would it need to be a seperate project?

Because it involves about 15 other packages and all of their
configurations.

>  C) Do you care that there already is an ongoing project working
>     on the same issue? (We got our sourceforge project approved recently)

Heh. :)  When it rains it pours.

I'm certainly willing to work with others, and I bet Nate is also.

Luke

--
I never think of the future.  It comes soon enough.  --Albert Einstein



------------------------------

Message: 3
Date: Thu, 19 Feb 2004 16:40:42 +0100 (MET)
From: address@hidden
Subject: Re: Bootstrapping
To: address@hidden
Cc: address@hidden, address@hidden
Message-ID: <address@hidden>
Content-Type: TEXT/plain; charset=us-ascii



On 19 Feb, Luke A. Kanies wrote:
> On Wed, 18 Feb 2004, John Sechrest wrote:
>
>> Nate Campi <address@hidden> writes:
>>
>>  % A surprising amount of configuration could be shared across sites,
>>  % enabling networks to get up quickly, and run better. Consultants could
>>  % come into networks they've never been on before, but quickly solve
>>  % problems and roll out new services, since he/she already understands the
>>  % cfengine setup.
>>
>>  Yes, but to do this, the cfengine community needs to start abstracting
>>  the (global practices) from the (local issues).
>
> That's a really good idea, but I'm not totally convinced this will be very
> easy with cfengine.  Mark and I have had long discussions about this, but
> my opinion has not changed:  It is very difficult to use cfengine for
> abstraction, which means it's very difficult to create
> location-independent cfengine configurations.

I do not fully agree with this. We now have "methods" that allow
considerable abstraction potential. Also, the other wish list
items are gradually being added... Don't write this off. One reason
why this has taken a long time is that there has been little feedback
from users on this. If these features are to be absorbed and made known
then everyone has to  be supportive.

M

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work: +47 22453272            Email:  address@hidden
Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




------------------------------

Message: 4
Date: Thu, 19 Feb 2004 07:47:02 -0800
From: John Sechrest <address@hidden>
Subject: Re: Bootstrapping
To: address@hidden
Cc: address@hidden, address@hidden
Message-ID: <address@hidden>



address@hidden writes:


% There *has* to be a buffer between any network service and
% cfengine so that it can fail gracefully. Cfengine's running
% should not depend on whether there is an active network
% connection or not.

The caching of data from the network does not have to be external
to cfengine. You can in fact look at ldap and then if ldap does
not work, use an alternative. It does not have to be between
CFengine and the network. CFengine just has to have a plan
for what to do when the network process fails.

And that failure is in itself information that CFengine should
work with as data.





-----
John Sechrest          .         Helping people use
                       .           computers and the Internet
                         .            more effectively
                            .                      
                                .       Internet: address@hidden
                                     .  
                                             . http://www.peak.org/~sechrest



------------------------------

Message: 5
Date: Thu, 19 Feb 2004 09:56:44 -0600
From: Chip Seraphine <address@hidden>
Subject: Re: Bootstrapping
To: "Luke A. Kanies" <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain;  charset="iso-8859-1"

On Wednesday 18 February 2004 16:56, Luke A. Kanies wrote:
> So, as to 'correctly updating':  If a client can successfully copy
> _anything_ is it working?  What about if it's just running cfagent at all?
> What if it has some errors, such as being incapable of starting a process?

I have my cfagents dump their $(allclasses) variable, suitably reformatted,
into a file at the very end of each run.  This is useful for seeing 'what
happened' and such.

Consider maintaining (in LDAP, another script, or cfengine itself) a list of
classes that should and should not be defined, and check those off against
the above-described list.  Discrepancies generate notifications in your NMS
or whatever....






------------------------------

Message: 6
Date: Thu, 19 Feb 2004 08:14:59 -0800
From: John Sechrest <address@hidden>
Subject: Re: mln (was: Re: Bootstrapping)
To: Roy MARANTZ <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>


Can you name the variants that you have used?

And can you outline what the "rules" in an abstract sense
are for those variants (IE, OS independent descriptions of what is needed)

Like:
                mysql => port 3306 is open
                mysql => mysql-server package is installed
                mysql => database owners/names/permissions derived from ldap


               

Roy MARANTZ <address@hidden> writes:

% I've developed a "system" which I use here for solaris boxes that has
% something like the roles talked about earlier and also variants for selecting
% amount different "implementations" of the role.  For instance, a machine can
% be a imap server and choose to use courier or uwash to implement it and use
% inetd or xinetd for the listener...  Turns out, I didn't need too many of
% these variants selectors, but they are real helpful when needed.  I've also
% used this to help role out new software.
%
% Roy
%
% On Thu, 19 Feb 2004, Tim Nelson wrote:
%
%  > Date: Thu, 19 Feb 2004 11:50:16 +1100 (EST)
%  > From: Tim Nelson <address@hidden>
%  > To: John Sechrest <address@hidden>
%  > Cc: Nate Campi <address@hidden>, address@hidden
%  > Subject: Re: mln (was: Re: Bootstrapping)
%  > X-Virus-Scanned: by NBCS
%  > X-Virus-Scanned: by NBCS
%  > X-Virus-Scanned: Using ClamAV and McAfee on jla.rutgers.edu
%  > X-Spam-Status: No, hits=0.0 tagged_above=-10.0 required=6.3 tests=
%  > X-Spam-Level:
%  >
%  > On Wed, 18 Feb 2004, John Sechrest wrote:
%  >
%  > >
%  > >
%  > > Tim Nelson <address@hidden> writes:
%  > >
%  > >
%  > >  %                  Hmm.  I think at least one separate list is a good idea -- that
%  > >  % gives people the choice as to whether they want to be in it or not.
%  > >
%  > >  Should we push to have the list as a side list of cfengine?
%  > >  Or should we set it up as part of the mln discussion?
%  >
%  >                  mln, yes?
%  >
%  > >  % > gw....[snip]
%  > >
%  > >  %                  Backup?  PostgreSQL?
%  > >
%  > >  Ok. Added to the list. I am sure there are more.
%  >
%  >                  We also need variant configs.  For example, many people will want
%  > a simple syslog setup.  But some will want what I have, which is syslog-ng
%  > tunneled over stunnel :).
%  >
%  >
%  > --
%  > Tim Nelson
%  > Systems Administrator
%  > Sunet Internet
%  > Tel: +61 3 5241 1155
%  > Fax: +61 3 5241 6187
%  > Web: http://www.sunet.com.au/
%  > Email: address@hidden
%  >
%  >
%  >
%  >
%  > _______________________________________________
%  > Help-cfengine mailing list
%  > address@hidden
%  > http://mail.gnu.org/mailman/listinfo/help-cfengine
%  >

-----
John Sechrest          .         Helping people use
                       .           computers and the Internet
                         .            more effectively
                            .                      
                                .       Internet: address@hidden
                                     .  
                                             . http://www.peak.org/~sechrest



------------------------------

Message: 7
Date: Thu, 19 Feb 2004 10:06:03 -0600 (CST)
From: "Luke A. Kanies" <address@hidden>
Subject: Re: Bootstrapping
To: Chip Seraphine <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 19 Feb 2004, Chip Seraphine wrote:

> I have my cfagents dump their $(allclasses) variable, suitably reformatted,
> into a file at the very end of each run.  This is useful for seeing 'what
> happened' and such.
>
> Consider maintaining (in LDAP, another script, or cfengine itself) a list of
> classes that should and should not be defined, and check those off against
> the above-described list.  Discrepancies generate notifications in your NMS
> or whatever....

That's definitely a good idea where it can work, but it won't work for
most of my cases.  One of the things I like the most about cfengine is how
easy it is to use it to classify my hosts; I definitely don't want to move
that classification outside of cfengine.

We need to begin adding error checking and/or error counting into
cfengine.  Without that, we're kind of stuck doing post-processing outside
of cfengine, which is a lot of extra work.

Luke

--
Westheimer's Discovery:
       A couple of months in the laboratory can frequently save a
       couple of hours in the library.



------------------------------

Message: 8
Date: Thu, 19 Feb 2004 08:33:41 -0800
From: John Sechrest <address@hidden>
Subject: Re: Bootstrapping
To: "Luke A. Kanies" <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>



"Luke A. Kanies" <address@hidden> writes:



% That's definitely a good idea where it can work, but it won't work for
% most of my cases.  One of the things I like the most about cfengine is how
% easy it is to use it to classify my hosts; I definitely don't want to move
% that classification outside of cfengine.

Can you outline for me how you use cfengine to classify hosts where
it is more appropriate to define it inside cfengine
instead of as an external declaration?

IE, some kind of derived class membership?



% We need to begin adding error checking and/or error counting into
% cfengine.  Without that, we're kind of stuck doing post-processing outside
% of cfengine, which is a lot of extra work.


Can you give an example of how you would like this to work?





-----
John Sechrest          .         Helping people use
                       .           computers and the Internet
                         .            more effectively
                            .                      
                                .       Internet: address@hidden
                                     .  
                                             . http://www.peak.org/~sechrest



------------------------------

Message: 9
Date: Thu, 19 Feb 2004 08:27:42 -0800
From: John Sechrest <address@hidden>
Subject: Re: Bootstrapping
To: "Luke A. Kanies" <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>



"Luke A. Kanies" <address@hidden> writes:


% >  Yes, but to do this, the cfengine community needs to start abstracting
% >  the (global practices) from the (local issues).

% That's a really good idea, but I'm not totally convinced this will be very
% easy with cfengine.  Mark and I have had long discussions about this, but
% my opinion has not changed:  It is very difficult to use cfengine for
% abstraction, which means it's very difficult to create
% location-independent cfengine configurations.

I am finding that if I can seperate the "rules" from the "data"
about which domain it is or which service I want to run,
Then I can get pretty close.

That is why I have been looking at reading the data that is
normally written as constants/Classes in the Cfengine
rules into datafiles as a base experiment.

And it seems to be working fine.

I can specify in a file what the "role" of a system is, and it
works to do it.

And I can move that role around, without rebuilding the machines.

The simple experiments work.

So if we can articulate the rules, and abstract the data in those,
then I think it is possible to use cfengine to represent
the details of a set of rules.



% >  A) Why would this not work as a component of the CFengine work that
% >     is already going on?

% Because it's essentially separate from cfengine itself.  It's a lot more
% than just cfengine.

  Right now, I am writing many little tiny cfengine scripts.
  Other than the infrastructure to name the roles and set the
  base system, everything else seems to be cfengine.

  So It seems like it could fit into the cfengine discussion
  easily.



% >  B) Why would it need to be a seperate project?

% Because it involves about 15 other packages and all of their
% configurations.

Interesting. Can you help me understand those other packages and
configurations you are working with?


% >  C) Do you care that there already is an ongoing project working
% >     on the same issue? (We got our sourceforge project approved recently)

% Heh. :)  When it rains it pours.
% I'm certainly willing to work with others, and I bet Nate is also.

I am glad to hear that. Right now, I think one of the good things
to work on would be to abstract the definitions of roles
and what those mean.

Our UML configuration tool (MLN) is proving to be valuable in
my process of doing that. I hope we will get the source forge
site up with the .7 version soon.

Can you help us take a role of that list that went around
and convert it into an abstract set of rules
in english (or at least predicate calculus), so that we can
talk about it before we implement it in cfengine?




-----
John Sechrest          .         Helping people use
                       .           computers and the Internet
                         .            more effectively
                            .                      
                                .       Internet: address@hidden
                                     .  
                                             . http://www.peak.org/~sechrest



------------------------------

_______________________________________________
Help-cfengine mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/help-cfengine


End of Help-cfengine Digest, Vol 15, Issue 16
*********************************************


reply via email to

[Prev in Thread] Current Thread [Next in Thread]