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

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

El vie, 18-01-2008 a las 11:16 +0100, Petter Reinholdtsen escribió:
> [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
> installation.
> > 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.

Thanks for your answers, I must confess they have exceeded all my
Working this way I'm sure the project will be a success (and Andreas
will not have much moderation work ;-). Now, we have to get the man
power to do all these work and tests. I'll work on a document to discuss
possible implementation of these topics and a more detailed roadmap.

Best Regards
José L.

Attachment: signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente

Reply to: