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 together with GLPI 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 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 10.0.2.0. > > > 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 expectations. 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.
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente