Re: Preparation of Blends tasks
Hi all:
On Tuesday 17 August 2010 22:30:22 Andreas B. Mundt wrote:
[...]
>
> I have been working on the debian-edu project and I am planing to
> extend and generalize the ideas used there in the future. The basic
> idea has been written down here already:
>
> <URL: http://lists.debian.org/debian-edu/2010/08/msg00037.html>
Very interesting, both your points of view and the two replies:
1) Yes: there is a conflict between "out of the box" and "flexibility" and,
yes, it's unavoidable. The most a "for the purpose" system can do is making
as sure as possible that it won't be in the way (at least not too much) when
somebody tries to go out the railed road.
On one hand, a specialized unflexible environment has the rather unforeseen
advantage that people has no problems accepting things "all or nothing" (I
think good part of the Windows success comes from this: it is the Microsoft
way or no way -many people simply doesn't have the knowledge/implication to
make or want to decide, so they gladly will leave decisions to others). On
the other, specially on enterprisey environments, exception is the norm if
only for a short percentage of any given deployment (but a different
percentage each time!) and a properly engineered system must allow for that.
2) There's a point in the question "Would that be possible to setup debian-edu
[any "blend" I should add] from pure Debian installation?"
I found quite a lot of projects of the "out-of-the-box" style not quite fitted
in that they are too much "all or nothing": with the exception of absolutly
new deployments there will be an infrastructure already in place which can't
be changed overnight so the system being "nice" with what's already deployed
so you can start short and then grow as confidence and knowledge do is the
difference from a project even looked at or not.
With these previous points in sight is why I said I'd find
interesting "producing documentation in the form of howtos and best current
practices": ideally I'd want somebody starting with a "standard" Debian
install CD, understanding the BCP and reading the howtos to be able to deploy
a typical Debian-based "enterprise" environment at his own pace with his own
exceptions with specific tools, metapackages, etc. being solely or
mostly "just" facilitators (as a side effect this would mean that the
strictly for-the-blend effort is taken to a minimum, a need not only to be
able to take the most of the effort on the blend but to insure its long-term
success).
> The setup could be used for schools, small enterprises and work
> groups at university, depending which tasks are included after the
> setup of the common infrastructure. It would be great to join forces
> and work together, because there is one big task that should be
> solved: The upgradebility of the system.
The nearer to the "standard" Debian, the less difficult the upgrades should
be.
> We have this problem in
> debian-edu since quite some time, and up to now there does not really
> exist a solution. (see <URL:http://bugs.debian.org/311188>)
Regarding this AFAIK (but my knowledge is not so deep in this regard) the
proper solution within Debian framework to be able for a bunch of packages to
share a common view of a configuration is to share the same
debconf "configuration space"*1, whatever this means, or simply create new
packages for the purpose (maintenance nightmare).
But I'm not so interested on debconf: while it's a wonderful convenience it
only works for package installation (and upgrade), not for day-to-day system
administration: my interest is much more on configuration
automation/enforcement ala cfengine or puppet: it not only deals with the
day-to-day changes but when properly deployed with installation an upgrades
too (on an ideal world, all install-related issues should be reduced to "make
a minimal installation on a new node, declare it to belong to a certain class
within your config automation tool and there you go").
> I plan to start with some kind of "debian-edu from scratch", where I
> want to setup the debian-edu system manually to learn and understand
> better how it works and what modifications are necessary that cannot
> be dealt with package preseeding.
I'd say debian-edu and others can be divided in two:
1) Infrastructure definition/deployment/maintenance: that's what I think
should be as common as possible and probably better fitted within
an "enterprise" effort.
2) Package selection, specific configurations: that's the realm for each blend
by itself.
With proper abstractions, conventions and tools in place, say debian-edu vs
debian-med should be a matter of choosing the proper package bundles (and
this should make an eyebrow rise since that was what the "blends" were meant
to be to start with: your efforts on debian-edu for infrastructure definition
and management, "zeroconf-like", etc. "just" show a lack of general-purpose,
network-oriented tools within Debian so you were forced to "invent" them by
yourself within the realm of your project).
Cheers,
*1 http://www.debian.org/doc/packaging-manuals/debconf_specification.html
--
SALUD,
Jesús
***
jesus.navarro@undominio.net
***
Reply to: