Re: Macht euch bereit, ganz bald Debian Edu squeeze (beta1) zu testen...

[Klaus Knopper <skolelinux@knopper.net>]

Hi Mike,

On Sun, Sep 11, 2011 at 09:21:35AM +0200, Mike Gabriel wrote:
> Hi Klaus,
> 
> On So 11 Sep 2011 01:31:44 CEST Klaus Knopper wrote:
> 
> >>>Wir haben eigentlich auf den "in persona"-Treffen sowie auf der
> >>>Entwicklerliste ziemlich viele Vorschläge eingebracht, die leider nicht
> >>>auf größeres Interesse seitens des Skolelinux-Entwicklerkernteams
> >>>gestoßen sind. Ich persönlich war auch gelegentlich im IRC zu Gast.
> >>
> >>Das was in Debian Edu zählt ist, dass du am Code arbeitest und Dinge
> >>committest die dann (a) funktionieren (hier muss Mike hoffen, dass
> >
> >Da liegt wohl eines der Probleme, denn die Zahl derer, die etwas ohne
> >einen "Paten" in Skolelinux commiten können bzw. das in den letzten 2
> >Jahren tatsächlich getan haben liegt, dich eingeschlossen, nach meinen
> >letzten Hochrechnungen bei etwa ... 4?
> 
> Hier kurz mal die Liste derjenigen, die auf Debian Edu SVN
> Schreibzugriff haben (>=4 ;-) ), darunter bestimmt einige
> Karteileichen:

|> mike-gabriel-guest@vasks:~$ getent group debian-edu
|> debian-edu:x:40003:[...],knopper[...]

Cool, das sind über 100 Leute, die theoretisch was hätten committen können...
Dass ich auch dabei bin, ist mir neu, seid wann ist das so, ich habe gar
keine Mitteilung bekommen!?

Ich habe aber eigentlich nur von denen gesprochen, die tatsächlich in
den letzten 2 Jahren etwas committed haben (!). Du hattest mir für eine
interne Statistik mal die Webseite genannt, wo man die realen Commits im
SVN sieht. Und das sind halt nicht ganz so viele Leute, nicht mal 10%
von den oben angegebenen. (Ist das eigentlich gut, die Logins einfach so
auf die Liste zu posten? Ich habe die Ausgabe mal gekürzt...)

> >>(b) auch von den anderen als
> >>sinnvoll oder gewinnbringend erachtet werden und (c) nicht irgendwas
> >>kaputtspielen, was andere innerhalb von debian-edu aufgebaut haben.
> >
> >Da sind schon einige constraints, neben dem notwendigen Fachwissen (das
> >traue ich mir noch zu) das globalen Verständnis um die Philosophie von
> >Skolelinux sowie die Entwicklungsstrategie bezüglich "technisch möglich"
> >vs. "gewollt" - hier blicke ich selbst nicht ganz durch die Hierarchie
> >durch, zugegeben.
> 
> Dann besteht hier doch ein Forschungsraum, den wir ausfüllen können.
> Für wheezy sollten wir diese Diskussion unbedingt führen und
> konstruktiv gestalten!!!

Bin gerne dabei, wie immer. :-)

> >>Ich denke, wenn während der Entwicklungsphase von d-e squeeze
> >>funktionale Commits zum Thema gekommen wären, dann hätte das
> >>bestimmt viele erfreut.
> >
> >Wir haben darüber auf den Treffen schon gesprochen, und sind bei "Wie/wo
> >kann ich unseren Code sofort committen" steckengeblieben, weil wohl
> >einige Dependencies problematisch waren, die für das RLP-Projekt weniger
> >ein Problem waren als für Skolelinux allgemein.
> 
> Debian Edu ist ein Debian Blend, das heißt, es baut in der nativen

Heißt es nicht korrekterweise "Debian PURE Blend"?

> Form vollständig auf Debian auf. Da Debian Edu sich immer auf die
> aktuelle Stable Distro Version, baut es auf Paketen in Debian Stable
> (also aktuell squeeze) auf. Pakete, die nicht in Debian sind, müssen
> in Debian hochgeladen werden (nach Debianischem Procedere unter
> Berücksichtigung der Debian Policies), dann müssen sie in Debian den
> Zyklus bis in die Stable Version durchlaufen, dann können sie in
> Debian Edu verwendet werden.

Es baut auf Debian-Paketen auf, wie Knoppix, aber lässt sich aufgrund
einiger Eigenheiten in der Art der Konfiguration leider nicht
vollständig aus Debian upgraden, sonst wäre der Schritt von Lenny nach
Squeeze einfach ein "apt-get dist-upgrade" gewesen. Das wiederum geht
bei Knoppix schon, mit etwas apt-Hintergrundwissen, obwohl ich mir nie
anmaßen würde, Knoppix als Debian Blend zu kennzeichnen; es ist ein
Derivative und auch als solches gelistet.

> Für ein drei Jahres Projekt ist diese Timeline natürlich eng und es
> braucht dann im Projekt eigentlich direkt einen Debian Developer,
> der (a) als beratender Debian Policy Stratege mit der Projektleitung
> in einem Boot sitzt und (b) dann auch die Pakete, die ihr beifügt,
> in Debian direkt hochlädt und dann auch maintained.

Dafür haben wir z.B. Jonas Smedegaard und Philipp Hübner regelmäßig
konsultiert, aber die beiden hatten eben auch nur begrenzte Resourcen
zur Verfügung, und bei Skolelinux als Basis hätten wir sowieso immer auf
die nächste Beta der Basisdistribution warten müssen, um unsere Sachen
für die übernächste Release auszuprobieren, d.h. wir wären niemals mit
der Zeit hingekommen.

Eigentlich wollte ich das Ganze jetzt aber nicht nochmal durchkauen,
sondern nur die Feature-Liste haben... und die habe ich jetzt schon. ;-)

> >>Wichtig ist, dass solche Neuerungen (a) auf
> >>Paketen in Debian aufbauen und (b) von euch in Debian Edu SVN
> >>eingepflegt werden. Die Relevanz von Vorschlägen kann aber alleinig
> >>nur im Tun gemessen werden: nur ein Vorschlag auf den eine
> >>Umsetzung/Handlung (d.h. ein SVN Commit auf
> >>svn.debian.org/debian-edu) folgt hat in diesem Kontext Relevanz.
> >>Alles andere ist nett und inspirierend aber nicht nachhaltig
> >>zielführend aus Sicht des Debian Edu/Skolelinux Projekts.
> >
> >Siehst Du, da haben wir es wieder... Ich denke, da gibt's v.a.
> >Unterschiede in der Interpretation des Begriffes "nachhaltig". Wir
> >wollen, genau wie ihr, etwas haben, was in >= 10 Jahren immer noch
> >funktioniert und wartbar ist. Deswegen bauen wir mit relativ hohem
> >Aufwand Anleitungen sowie Pakete im Debian-Format, die sowohl unter
> >Skolelinux als auch vanilla Debian installationsfähig sind. Das reicht
> >aber nicht, um in Skolelinux aufgenommen zu werden, habe ich gelernt.
> 
> Ich war im letzten Jahr mal in Bremen und habe mir die Fa.
> Univention angeschaut. Die bauen unter großem Aufwand eine eigene
> Distribution auf, alles unter AGPL. Theoretisch könnte man die
> Management Software des Servers (ein Super-mächtiges Tool) auch auf
> Debian Portieren und forken und all so ein Zeugs.... Der Aufwand,
> sich in Fremd-Software einzuarbeiten, ist immens. Diesen Aufwand
> scheue ich persönlich und vielleicht auch andere, wenn nicht
> absehbar ist, ob der Nutzen hinterher angemessen hoch ist. Hmmm...
> Für die Community wäre es ein viel größerer Gewinn, wenn aus dem
> Projekt selbst jemand aktiv wäre und eine Software an die Community
> übergeben würde.

Das ist halt einer der Vor- und Nachteil von Debian: Man lässt sich von
keiner Firma oder Institution in die Arbeit hineinreden, dafür gehen
einige Dinge halt ziemlich langsam, so dass man gelegentlich von einem
hervorragend stabilen und gut gewarteten ... "Softwaremuseum" sprechen
kann, was "stable" angeht, wenn ich mal so frech sein darf. ;-)

Wobei Ubuntu mit seinen vielen Debian-Maintainern mich hier quasi
widerlegt. Aber wir wollten halt unbedingt Skolelinux als Basis, und
stehen dazu. :-)

> Meiner Ansicht nach muss in Projekten, die ein Überleben der
> Ergebnisse über das Projektende hinaus sichern wollen, dafür sorgen,
> dass die Ergebnisse an einem Ort landen, an dem evtl. andere die
> Ergebnisse weiterpflegen und so dort auch Paten gefunden werden für
> den erstellten Code. Debian liefert hierfür eine 1a Projektstruktur.

Wir haben in den 3 Jahren eine technische Infrastruktur aufgebaut, die
über Projektende hinaus weiter betrieben wird, mit einem gespiegelten
Websever, Buildserver mit Virtualisierung zum Testen, Backup-System und
unseren Projektergebnissen in einem Wiki sowie
Debian-Installationspakete, die sich sowohl unter Skolelinux/Lenny als
auch Debian/squeeze bauen und installieren lassen. Unser Wunsch ist es,
das Ganze auch irgendwann nach Debian zu bringen, aber wir haben leider
nur eingeschränkt die Möglichkeiten dazu.

> >>>werden, oder lieber gleich moodlen), dann war unser CipUX nicht gut
> >>>genug als LDAP-Middleware und sowas wie Quotas für Drucker oder
> >>>Festplattenplatz, Profile für Klassen und Fächern, Klassenversetzung
> >>>nach jedem Schuljahr zu "speziell". Na gut, vielleicht haben wir in RLP
> >>>halt einfach "zu hohe Ansprüche" an ein Schul-Linux gehabt, sei's drum.
> >>
> >>Nein, ihr bestimmt sehr sehr gute Ansprüche. Und ihr habt nicht in
> >>Debian Edu SVN committed.
> >
> >Ging leider nicht, deswegen haben wir eben ein eigenes Repository.
> 
> Für wheezy sollten wir diese Diskussion erneut führen!!!!! Hast du
> mal einen Link für eine Feature-Liste, die ihr in eurem RLP-Overlay
> drin habt. Einige habe ich im Kopf, aber einen aktuellen Stand zu
> bekommen, wäre gut.

Ich habe unsere Seite eben noch mal durchgeschaut und aktualisiert, hier
ist der aktuelle Stand:
https://rp.skolelinux.de/rlp-wiki/bin/view/RlpSkolelinuxPublic/FeatureListeSkolelinuxRLP

Früher haben wir auch virtualisierte Komplett-Images mit allen Features
vorinstalliert angeboten, die auch leicht installierbar waren, was wir
auf Anraten des Projektmanagers von Skolelinux-DE aber wieder revidieren
mussten, weil's dann nicht mehr "Original Skolelinux" war. Man
installiert Skolelinux-RLP also derzeit zunächst mit der aktuellen
Original Skolelinux-CD und installiert dann nach Anleitung unsere
Erweiterungen oben drauf.
Das hier ist IMHO die wichtigste URL dazu:
https://rp.skolelinux.de/rlp-wiki/bin/view/RlpSkolelinuxPublic/Handbuch

> >>That's it. Nur aus diesem Grund ist GOsa²
> >>jetzt in Debian Edu das Rundum-Tool für die LDAP-Verwaltung. Denn:
> >>die GOsa²-Implementierung wurde in Debian Edu SVN committed. Again:
> >>Do-Ocracy. Handlung liefert messbare Ergebnisse.
> >
> >Es ist wohl eher die Frage, wer näher am "Kern" sitzt und eine
> >entsprechende Entscheidungsgewalt hat, und da CipUX ja offiziell in
> >Debian/unstable ist, kann's eigentlich kein technischer Grund gewesen
> >sein. Unsere messbaren Ergebnisse liegen daher halt derzeit nur auf
> >unserem Server. :-)
> 
> CipUX ist in unstable, wir entwickeln aktuell an Debian Edu
> stable... So direkt hätten wir CipUX in Debian Edu (bei Beibehaltung
> der Debian Blend Policy) nicht verwenden können.

Das war eins der Dependencies, warum es halt nicht geklappt hat mit der
direkten Übernahme in die aktuelle Version von Skolelinux; Du erinnerst
dich vielleicht an die lebhafte Diskussion in Zweibrücken, auf der mir
Jonas beinahe an den Hals gegangen wäre... ;-)

> >Ich finde übrigens GOsa² als Webgui prinzipiell gut, kannte GOsa auch
> >schon vorher, es war vor vielen Jahren einmal auf der Knoppix-CD mit den
> >notwendigen LDAP-Datenstrukturen vorinstalliert mit dabei. Es macht halt
> >leider nicht alles, was wir damals für unsere Erweiterungen gebraucht
> >haben, und kam gut 2 Jahre zu spät in Skolelinux an.
> 
> Ein GOsa²/FusionDirectory Developer ist aktives Debian Edu Developer
> Mitglied (Alejandro Aescanero). Er hat auch das Netgroups Plugin für
> GOsa² auf unsere Anfrage beigesteuert. Was auch immer es braucht,
> ich denke, dass wir mit Alejandro Absprachen und Wege finden können,
> Features in GOsa² (bzw. evtl. später FusionDirectory) zu
> implementieren.

Wenn ich es richtig gelesen habe, ist es noch gar nicht sicher, dass
GOsa auch in Skolelinux/Wheezy das LDAP-Tool der Wahl sein wird. Aber
darüber können wir uns auch später Gedanken machen.

> >>Ein Overlay muss bei sowas wohl
> >>immer her. Aber die Frage ist, wie groß ist das Overlay (als die
> >>spez. Anpassungen) und wie groß der Beitrag zum Kernprojekt.
> >
> >Die Richtung ist wohl teilweise unterschiedlich. Wir haben in
> >Deutschland halt nun mal ziemlich umfangreiche Anforderungen an den
> >Datenschutz und halb-öffentliche Netzzugänge, und wollen auch
> >nachvollziehbar sichere Prüfungen am Rechner durchführen, das schreiben
> >die Prüfungsordnungen auch vor, ansonsten müssen wir bei Prüfungen auf
> >Papier bleiben und Skolelinux würde in dieser Richtung auch einfach
> >keinen rechtfertigbaren Mehrwert bieten.
> 
> Strenger Richtlinien in Deutschland widersprechen keiner Aufnahmen
> im Debian Edu Kernprojekt.

Keineswegs, aber es sind Features, die offenbar nicht für den
internationalen Zweig interessant oder gewünscht waren (s.o.).  Wir
haben darüber schon in Oslo mit Petter und Klaus Ade diskutiert, weiß
aber nicht mehr, ob Du dabei warst.

> Kann sein, dass dann andere Menschen aus
> anderen Ländern etwas wettern über das strenge, bürokratische
> Deutschland. ,,Deutsche'' Funktionen, die leichtens abschaltbar

Die Funktionen sind sicher nicht "typisch deutsch", oder sonderlich
paranoid, aber eben speziell für deutsche Schulen mit höheren
Datenschutzrichtlinien wichtig.

Wir müssen beispielsweise für den Schüler deutlich sichtbar eine Meldung
in genau dem Moment einblenden, wenn der Lehrer den Schüler-Desktop auf
seinem Bildschirm hat. italc macht das im Original nicht, aber es gehört
eben zu unseren Standards, das die Menschen informiert werden, wenn man
sie "beobachtet" (auch wenn dies eine ganz normale Hilfsfunktion im
Unterricht ist, und die Schüler eigentlich von vornherein informiert
sind, dass der Lehrer ihre Desktops sehen und bei Bedarf "übernehmen"
kann).

Das Argument, unser italc-Derivat nicht in Skolelinux aufzunehmen, war
damals hauptsächlich, dass es

1. schon ein "italc"-Paket gibt, und

2. dass ein "italc2" upstream in Arbeit ist, was ja "möglicherweise"
ähnliche Funktionen als Plugin bedienen kann.

Deswegen gibt es eben jetzt ein Extra-Paket "italc-rlp" mit korrekten
Depends, Conflicts und Provides-Tags, das das Original-italc sauber
durch unseres ersetzt, und die Infrastruktur mit Key Exchange für den
Klassenarbeitsmodus herstellt.

Man könnte manchmal glatt meinen, es passiert nichts, wenn man es nicht
selbst macht. ;-)

> (oder per default nicht eingeschaltet), können durchaus ein
> Bestandteil des Kernprojekts werden (solange sie nichts anderes
> kaputt machen, sich an Debian Policies halten, etc. pp.).

Naja... Man müsste als erstes mal einen aktuellen Kernel installieren,
um mit Hardware neuer als 2 Jahre zurechtzukommen, und die Filesystem-
und Netzwerkfeatures, die man für Prüfungsmodus braucht, verfügbar zu
haben. Mit dem "Debian-Kernel" alleine geht das einfach nicht. Da gibts
dann schon einen Konflikt mit der Debian-Basis, die auch bezüglich
fehlender Hardwareunterstützung mit "proprietärer" Firmware andere
Prioritäten setzt - was ich von der Philosophie her gut finde, mir aber
selbst nicht leisten kann.

> >>>Das Grundproblem, dass, wie bei Skolelinux auch, der Server komplett neu
> >>>installiert werden muss, wenn ein neues Major-Release ansteht, haben wir
> >>>leider auch weiter, daher tendiere ich persönlich dazu, in Zukunft eher
> >>
> >>Das Problem ist in der Tat ein Problem.
> >
> >Wie wir uns wieder einig sind. :-)
> 
> :-)
> 
> >>Beim letzten Entwickler-Treffen in HH haben Andreas Mundt und ich
> >>davon gesponnen, das Hauptpaket von Debian Edu: debian-edu-config
> >>komplett auseinanderzunehmen von from-scratch neu aufzubauen.
> >>Sollten sich wirklich Freiwillige an solch ein Mammut-Projekt
> >>heranmachen, dann könnte eine Policy sein, Upgrade-Fähigkeit in den
> >>meisten Bereichen/Teilpaketen zu definieren und zu forcieren. Aber
> >>für solcherlei Visionen ist das noch zu früh.
> >
> >Da liegt ein weiteres Problem: Wir hatten in unserem Projekt nur 3 Jahre
> >Zeit und feste Deadlines für die Ergebnisse. Das ist mit reiner
> >Community-Arbeit schier unmöglich einzuhalten. Daher sehe ich unsere
> >Ergebnisse im schlimmsten Falle als ein Motivationsprojekt für die
> >Community, es anders noch besser hinzubekommen, als wir es mit unseren
> >strengen Vorgaben in der kurzen Zeit geschafft haben. :-)
> 
> Die Kundenprojekt vs. Freies Projekt Problematik begegnet mir
> täglich im X2go Projekt. Den Punkt kriege ich komplett und da muss
> man Wege finden und meistens duale Wege. Acknowlegded!

Der Status von X2Go ist mir im Moment auch nicht richtig klar. Ich habe
lange keine unter Skolelinux/Lenny und/oder Debian/squeeze vollständig
funktionierende Version mehr gesehen. Work in Progress, vermutlich. Wir
verwenden einen älteren Backport.

> >Ein neuer Ansatz könnte tatsächlich ein "normales" Debian from scratch
> >mit entsprechendem Preseeding sein, auf das die neuen Funktionen als
> >Pakete oder Upgrades (wir brauchen für den Prüfungsmodus beispielsweise
> >eine andere Kernel-Konfiguration für Poly-Instanzierung) upgradefähig
> >aufgepflanzt werden. Das wird aber eher ein neues Projekt sein.
> 
> Da ihr da ähnliche Pläne hegt, sollten wir uns für Debian Edu wheezy
> unbedingt zusammen finden!!! (Zum Kernel: ist der Poly-Instance
> Kernel nicht auf dem Speiseplan für Debian wheezy? Ich meine
> schon...)

Evtl. hab ich das unklar formuliert. Das, was wir auf Filesystem-Ebene
brauchen, um die User gegensetig "unsichtbar" zu machen, sind vorwiegend
eingeschaltete Namespaces, d.h. jeder User (Prüfungsaccounts) sieht
unter $HOME und den verschiedenen global erreichbaren TMP-Verzeichnissen
nur noch seine eigenen Daten, der Lehrer hingegen sieht alles. Das
Feature ist im Kernel schon lange drin, aber bei den
Debian-Kernelpaketen standardmäßig nicht eingeschaltet, und es muss auch
bei den Clients (Workstations sowie Terminalserver) entsprechend per
mount-Option aktiviert werden. Näheres dazu kann dir Martin Öhler sagen,
der hat den Klassenarbeitsmodus inkl. QT-GUI gebaut.

Viele Grüße
-Klaus