Re: [gentoo-soc] Weekly progress report [june 9-15/16] Gentoo Clustering CD

[Eric Thibodeau]

Well, as you point it out:
     "If the tool forces the user to do things a particular way, then 
the tool is working against, rather than for, the user."

    My experience with infrastructures and especially configuration 
management tools is that you can't have both automatic-easy-no-hands-on 
configuration and manual configuration of the same application 
simultaneously. If one attempts to make a "perfect" configuration tool, 
he will quickly realize the human being is unpredictable and sometimes, 
god forbid, stupid. Compensating for the human factor is a never ending 
quest which eventually force the choice between total control over the 
configuration by the tools or total configuration by the user/admin. If 
you don't believe me, look at a popular OS called Windows, made by 
Microsoft. Their attempt at providing a unified "interface" to all 
configuration and management aspects of the machines inadvertently fails 
as one almost always has to go into the "registry" to fix something a 
user (also called viruse) did or didn't do.

    Furthermore, totally interfaced control over a complex backend is 
also failure-proned. One of my IT colleagues experienced weird name 
resolution problems that were eventually resolved by deleting entries in 
an AD using OpenLDAP tools accessing the said AD through a translation 
backend (the interface to the AD failed to report the keys...even the 
search engine for the advanced management)

    Obviously, this view is a can-O-worms and I really don't want to 
start this philosophical debate. My point is actually that I want the 
project to adhere to the Gentoo philosophy as closely as possible and I 
can hardly see how this can be the case when I _impose _ some 
configuration decisions (ie: I'm not asking the user what ACL to put 
into slapd and how to construct system-auth).

    This said, my approach at modifying the configuration files is using 
a "general" .conf file (ie: we could call it either a domain-def.conf or 
local-machine-def.conf file) which (would/should) sources as much 
information form the gentoo-specific /etc/conf.d file and patch in where 
specifics aren't defined. If this can be accepted by the powers that my 
be in Gentoo as an approach to "guiding" the initial setup of a machine 
(as performed by src_install (or should it be pkg_setup) ) then fine!

    But, like I said when choosing to make the script, some of the steps 
need to be accomplished in an authoritative manner and in a specific 
sequence, which cannot be guaranteed by portage.

Now, following what Donnie pointed me to on the Seed Linux mailing list 
(http://groups.google.com/group/seed-linux-dev/browse_frm/thread/d5ab069f47de4b76? 
) and more specifically this post about global configuration management: 
http://groups.google.com/group/seed-linux-dev/browse_thread/thread/73cb8a4fef940903 
, I believe we have something interesting that may result from merging 
my script into proper Seed Linux Ebuilds and getting some consensus on 
the configuration definition.

Eric

PS: To answer the original e-mails question: yeah, I think the 
philosophy applies to the project. At the end, the user is supposed to 
end up with a working system that remains 100% a Gentoo system (with 
minimal overlay interaction) most of the hard work being 
auto-configuration to _get going_... The user is then free to go and 
break it all by modifying the config files, the I will painstakingly 
keep as close to the proposed ones from the original ebuilds ;)

Donnie Berkholz wrote:
> On 22:07 Mon 16 Jun     , Eric Thibodeau wrote:
>
>> _*LDAP:*_
>> I spent many hours (way over the 30 hours I had promised myself to
>> pass/week on SoC) creating an LDAP-as-auth-backend auto-install script.
>> It's not simple because Gentoo's philosophy is that ebuilds do as little as
>> possible and the admin does the work.
>>
>
> Hmmm ... you might want to read
> http://www.gentoo.org/main/en/philosophy.xml again and consider how it
> applies to this project.
>
> Thanks,
> Donnie
>