[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

> 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 

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


*1 http://www.debian.org/doc/packaging-manuals/debconf_specification.html

Reply to: