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
--
ubuntu-server mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
