Re: Bootstrapping

[John Sechrest]

"Luke A. Kanies" <luke@madstop.com> writes:

 % On Thu, 19 Feb 2004, John Sechrest wrote:
 % 
 % >  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.

 % Can you give me an example of what you're reading in vs. what you have in
 % the configurations?

 I am reading:

   My role
   my packages to install
   my domain
   my contact
   

 I configure 
   for each role I have a cf.XXX 
   file which implements that role. 
 
 I need to:
   pass in more information about if I am
   a web server, just what web domains am I service
 
   I am still working on how to pass disk space
   issues correctly between machines.
   I need to mount specific home directories and
   specific web directories. And so I am
   trying to find a disk service that I believe in.
   NFS can work in the short term, but fails
   outside of narrow constraints
   AFS seems too cranky/old. 
   I am starting to explore lustre

   
   
   

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

 % Well, what Nate and I are talking about building is an appliance-like
 % infrastructure bootstrap server:  You walk in with a box, and it's got
 % (for example) cfengine, Nagios, Cricket, OpenLDAP, Apache, a DNS service
 % (preferably based out of LDAP), CVS, and probably a few more packages.
 % You boot the machine up and set the basic host data, and you're off.  Now
 % you just check your cfengine configurations into CVS, add your hosts to
 % LDAP, and you're done:  You've got a self-maintaining, self-monitoring,
 % convertent infrastructure with version controlled configurations.

 Yes, that is the same tool that I am talking about. A knoppix+cfengine+mln
 CD which you put in the drive and poof after answering the basic
 questions, you have a small business infrastructure.

 But all the subpackages can be considered constants
 or at this point reasonable approximations of constants,
 so our discussion is for each of the services:

 ldap
 mysql
 ....
 
 What are the appropriate
 cf.ldap
 cf.mysql 
 
 files... or modules or packages 
 that are needed to make it possible to say:


 apt-get install moduleX
 cfagent -I -K -q
 
 and have cf.moduleX drive the system into service. 

 And this ends up looking like a cfengine confersation. But I am
 happy to take it to the mln conversation space if the cfengine
 list does not want to watch it. 

 % I don't think it's even that difficult; you just need configuration
 % generators for all of your applications.  We're not actually talking about
 % much unique information here -- it's all host-specific, except the users
 % who need to modify the host information.

 Right. I think we are on the same path. 




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

 % I am not sure what you mean when you say "roles".  Are you talking about
 % the definition of a web server, or something like that?

 I am trying to abstract out high level abstractions of what 
 people want to do. The operating assumption is that we have one
 role per server. This solves several interaction problems and 
 helps keep service uptime high. 
 
 So I have a mail server and  a web server and a dns server and
 a disk server... 

 These end up being roles.

 Not services. 

 When I say that a system is a web server then
 there are a few operational parametes: cgi + php + ...
 And there are some network assumptions about filtering
 And some disk assumptions about what to mount.

 So the client comes to a web page, says:
    click, I want a web server
           click, I want cgi
           click, I want php
           click, I don't want frontpage
     .....

 And hits the submit button, this defines a set of roles,
 which get mapped to UML host instances, which then get
 build and deployed.... Poof. Done.

 What are the high level abstractions that you want to talk
 to the client about. And what are the low level
 options that you want to expose. 

 Not at the system admin level, but at the client level?

 These are the roles that I am trying to define. 



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

 % I don't know what you mean.  Can you give some more detail?


 Suppose you want to configure a system so it has the role
 of a front end mail server?

 What are the steps that you would take to move a bare debian
 install into the role of being a mail server?

 You need to have some packages?
 You need to know some input data like domain name?
 You need to know some site assumptions like disk server and 
 security policy..

 What would the rules be to set up a front end mail server?
 (A front end takes email, fluffs it, makes sure it is legitimate,
 scraps off the RBL, and runs Spam assassin etc, and then 
 only passes local delivery back to the backend machines.
 It does not do imap or pop
 It does use ldap to read which backend machine to deliver which
 mail box to.

 This implies some state changes on other machines/roles like:
 the dns server needs to have mx records in place for it.
 the gateway machine needs to let packets thru for it.
 the load balancer needs to pass packets around to it.

 So... If you walk into a business, what roles would you let
 the client choose from on the clicky-poof web page that
 defined the site?


 



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