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

Re: Doubts and question about the merging of LinEx in Debian Edu

[José L. Redrejo Rodríguez]
> In some cases the problem is only a matter of changing what package
> provides the same service. An example of it would be dns & dhcpd
> daemons: we use  dnsmasq and Debian Edu uses bind & dhcpd3. In those
> cases, we can perfectly assume changing to Debian Edu configs, as it can
> make things easier for the integration and also can free us of some work
> in the future.

If possible, I suggest we switch to using LDAP as the source of this
information, and figure out which daemons can provide that.

> Some other services are not as easier to change, as an example we use
> OCS inventory[1] together with GLPI[2] for our inventory and call
> center, and Debian Edu uses site-summary. In this case we can not switch
> as the integration between the inventory and the call center is
> something we can not loose.

Here, I propose we switch everyone to OCS inventory, and extend it to
be able to generate munin (and hopefully also nagios) configuration
from it.  I wrote sitesummary as a hack to get something working while
we looked at better alternatives.  OCS Invetory was (still is?)
missing the server part in Debian Etch, so it was not really an option
for Debian Edu Etch.

> There are also some services Debian Edu uses and LinEx doesn't need
> them (samba as an example) and the opposite (puppet[3] as an
> example).

Moving to puppet might be an alternative for Debian Edu.  The cfengine
plans never crystalized, and puppet might be a easier option for
day-to-day maintainence.

> Another problem is debian-edu-config: even using same services and
> packages, there are some configurations that are very skolelinux
> related and we can not assume. That will take most of this mail.

The best approach here to figure out what is changed, is to install a
main-server profile and use debian-edu-etc-svk to check out the
configuration changes done related to .intern and

> And the final problem is the desktop: Our students and teachers have
> been trained and using GNOME for the last 5 years, so we can not
> discuss if GNOME is better or worse than KDE: It just something that
> can not be changed and both desktops have to live together. Happily,
> freedesktop.org initiative has made thing easier in this field, but
> there still some configurations very kde-related in a Debian Edu
> installation.

There is basic support for switching desktop from kde to gnome in
debian-edu (the desktop-kde and desktop-gnome subtasks), but it need
more work, and we need to figure out a way to select which one during

> c) All the configurations in the debian-edu-install and
> debian-edu-config will depend on variables that will be filled using the
> installer udebs: If the user types expert, it will ask for the ip,
> hostname, ldap base suffix, and Desktop to be used, if the user types
> linex it will be like b) but without hardcoding the preseeds or answers
> and if the user just press intro it will be like the current
> installation.

This option has been a long term plan, so I suggest we try to
implement it and fall back to option b) when we run out of time.  It
is what we have been doing all along, and the system is getting easier
and easier to customize. :)

Another idea I have is to use machine netgroups more actively.  Say,
to enable exam mode on a machine it is inserted into the exam-hosts
netgroup and rebooted (or perhaps it dynamically take effect), and
then the machine is locked down for exams.  There is a lot we can do
with grouping of machines in netgroups that would make administration
easier.  At the moment it is only used for NFS access, but that is
just the start.

Happy hacking,
Petter Reinholdtsen

Reply to: