Idea for a spec

[Carl Karsten]

I think I understand the problem you are trying to solve, and you are well ahead
of me at how to solve it, but here are my thoughts:

terms: director and drones, queen and workers, king and pawns.  I'll use the
first - the rest are too silly.

Default configs that go beyond what any one package defaults to.  For instance,
bind and dhcpd can interoperate, but they don't by default.

GUI - as much as I love .conf files, I do see value in a GUI front end:  the
options are organized in a way that makes it easier to quickly understand what
options do and how some interact with others.  Options are grouped, more common
ones are 'up front' and the obscure ones are 'burried.'  relevant help can be
diplaied .5 seconds faster than /searching a man page (it isn't really the time,
it is the convenience and accuracy that makes it better.)

2 packages - one for the director, one for the drones.  Each has a GUI (like
Webmin which I have only looked at once a few years ago) and depends on a set of
packages considered common to any config.  The GUI can enable (install) other
packages.  The drone gui may only be a "define director" dialog that has a
button: "search for director" that does a port scan of the local subnet.  I am
guessing you want all config done via the 'master.'

plugin framework - Initially there will be just the 'core' packages but it
should be easy to add additional package management (both install and config)
later in time.

On the ubuntu-server CD, there could be options for Director and Drone, much
like there is currently a LAMP option.  Perhaps the Done config could be
supplied as part of the install process via a config file that is on local
removable media (floppy, usb) that is created by the Director installation process.

I sure have a lot to say for someone who doesn't know what I am talking about. ;)

Carl K


Etienne Goyer wrote:
> Whoa !  I must really have express wrong, this have absolutely nothing
> to do with FAI.  But the network in a box + domain controller is much
> closer to what I have in mind.  I'll try another shot at explaining it.
> 
> When you have a large numbers of host to manage, you usually have to
> setup a number of infrastructure services to help you do so.  These
> usually include setting up DNS, centralizing authentification with LDAP,
> setting up a monitoring system, etc.  All the tools to do these task
> exist already, you just have to set them up to your taste.  This can be
> time-consuming, and require some know-how.
> 
> However, I do not think junior admins, or those unexperienced with Linux
> coming from other platforms, have the skills to do a good and efficient
> job of setting up these infrastrucure services.  Building an LDAP
> directory is not rocket science, but it's not an afternoon project for
> someone inexperienced either.  So, often, it does'nt get done because
> nobody have the skills and/or time to do it.
> 
> So the problem I am looking to solve is to help busy or inexperienced
> admins benefit from having a good set of infrastructure services out of
> the box.  We would do so by auto-configuring most of these services for
> the common case.
> 
> More concretely, it would involve (on the "master" side) :
> 
> - Setting up an LDAP directory, mostly for user authentication and NSS
> - Setting up a DNS zone for the domain
> - Generate a root CA, and a certificate for the master
> - Generate a ssh authentication key pair
> - Setting up a monitoring system
>  ... etc
> 
> When a "client" is added to the "domain", it would involve :
> 
> - Adding the client in the domain's DNS zone
> - Generate a certificate for this client, and send it to the client
> - Make PAM and NSS on the client use the LDAP directory
> - Install root's ssh public key in the client's authorized_keys file
> - Install on the client any agent required by the monitoring service
>  ... and so on
> 
> 
> In other words, I would like to achieve a level of integration
> comparable to what other platforms provide.
> 
> Recently, I have been giving a lot of Linux trainings to Windows admins.
>  While they struggle to configure BIND and learn its backward zone file
> syntax, they never miss the opportunity to point out that this is being
> taken care when using an Active Directory.  It's even worse when it come
> to user authentication.  They are vaguely aware that Active Directory is
> based on LDAP and Kerberos, but they do not care as it "just work" out
> of the box.  To achieve similar results on Linux, they would have to
> learn a whole lot of LDAP concepts, how to build a DIT, probably some
> LDIF syntax, and the intricacies of the LDAP daemon they would use.
> That's just too much for most of them, and the reason why they will
> continue to run their infrastructure on Windows.
> 
> I believe it's possible to lower the barrier to entry and make Ubuntu an
> easier alternative.  That's what I am looking forward to.
> 
> 
> Scot McSweeney-Roberts a écrit :
>> Etienne Goyer wrote:
>>
>>> Setting up an "Ubuntu domain" would involve running a configuration
>>> scripts, a wizard, on what will become the reference server (hereafter
>>> called the "master").  This would configure the infrastructure services
>>> according to the spec.  Another setup tool is to be ran on machine that
>>> want to make use of these infrastructure services (hereafter called the
>>> "clients").  Ideally, you only have to provide the name or address of
>>> the master server to the clients to have them auto-configured to make
>>> use of pre-defined infrastructure services.
>>>  
>>>
>> Doesn't FAI provide this sort of thing? -
>> http://www.informatik.uni-koeln.de/fai/
>>
>> To be honest, I don't really understand what it is intended by the spec.
>> It seems to be some form of cross between a "network in a box" and a
>> domain controller. What problem is the spec supposed to solve?
>>
>> cheers
>>
>> Scot
>>
>>
>>
> 
>