<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hallo!<br>
<br>
Am 2016-04-21 um 11:52 schrieb Adi Kriegisch:<br>
</div>
<blockquote cite="mid:20160421095231.GR15138@kriegisch.at"
type="cite">
<pre wrap="">Hallo!
</pre>
<blockquote type="cite">
<pre wrap="">Für wissenschaftliche Zwecke ist auch § 2 2. d gedacht: "Errichtung von
Archiven, Datenbanken mit Hintergrundinformationen". Letztere sind für §
2 2. h "wissenschaftliche Publikationen" die Voraussetzung.
In diesem Bereich ist daher besonders Bedacht darauf zu nehmen, diese
Datensammlungen - und das sind hier historische Dokumentationen, die die
Erforschung und Weiterentwicklung gerade erst ermöglichen, möglichst
unverfälscht erhalten bleiben.
</pre>
</blockquote>
<pre wrap="">Wir reden hier aber schon von einem Wiki das Einsteigern dabei helfen soll,
an unserem Netz teilnehmen zu können.</pre>
</blockquote>
Eigentlich nicht: Das Wiki ist meines Erachtens dafür der falsche
Ort, siehe voriges Mail.<br>
<blockquote cite="mid:20160421095231.GR15138@kriegisch.at"
type="cite">
<pre wrap=""> Dazu sollte man weder Wissenschaftler
sein müssen noch Publikationen wälzen müssen.</pre>
</blockquote>
Das Wiki war bisher stets Sammelpunkt für Informationen aus der
Community und für neue Konzepte. Wo sonst sollen neue Konzepte
erarbeitet und dokumentiert werden? Google Drive? Office Cloud?
Owncloud?<br>
<blockquote cite="mid:20160421095231.GR15138@kriegisch.at"
type="cite">
<pre wrap="">
Bei den Informationen im gegenständlichen Wiki handelt es sich um
'Dokumentation' und nicht 'Publikation' und das ganz im Sinne von 'Wiki':
schnell und im Fluß. Nur weil beides die letzten paar Jahre nicht so
geklappt hat, ändert das am Prinzip nichts.</pre>
</blockquote>
Ist unscharfe und volatile Dokumentation das, was Du Neueinsteigern
zumuten wollen würdest?<br>
<br>
<br>
Dokumentation (Best Practices) gehören nicht ins Wiki, sondern auf
die jeweilige Community-Website (wer ist die Zielgruppe?); am Besten
als PDF zum Download. Eine gute Anleitung ist sowieso die beste
Werbung und wirkt dem entgegen, was Clemens laut seinem Mail am
Montagstreffen so sehr stört.<br>
<blockquote cite="mid:20160421095231.GR15138@kriegisch.at"
type="cite">
<blockquote type="cite">
<pre wrap="">Zum Thema LDAP für die Authentifizierung der Nutzer aus
unterschiedlichen Communities, gebe ich zu Bedenken, dass LDAP (Zitat:)
"ein Netzwerkprotokoll zur Abfrage und Änderung von Informationen
verteilter Verzeichnisdienste"¹ ist. Also gerade für den Use-Case
gedacht ist, der zur Diskussion steht. Also einer Funktionalität, die
laut Aaron auch dem Wesen der Common Node DB entspricht, wie er sie mir
erklärt hat.
</pre>
</blockquote>
<pre wrap="">Grob gesprochen 'besteht' unser LDAP aus drei Teilen: dem LDAP-Server, dem
LDAP-Protokoll (wie von Dir oben erklärt) und der LDAP-Datenbank.
Unsere LDAP-Datenbank enthält die Benutzerdaten aus dem Redeemer vom Marvin
-- also Benutzerdaten der wiener Netzteilnehmer. (Auf die Common Node DB
ist so gedacht und gemacht, daß sie jeweils einer Gruppe vorbehalten ist)
Was Du Dir -- so wie ich Deine Worte verstehe -- darunter vorstellst, ist
wohl mehr sowas wie das von Matthias schon angesprochen Shibboleth[1]. Wäre
bestimmt super, nett, toll und sowieso alles, allerdings fehlt uns für die
Umsetzung des ganzen die notwendige (Wo)Manpower und andere Gruppen, die
Interesse daran haben, sich mit uns auf der Ebene zu 'verbünden'.</pre>
</blockquote>
Ganz allgemein:<br>
Wenn es ohnedies an Manpower fehlt, warum sich dann in der erneuten
Erfindung des Rades versuchen? Wäre es nicht sinnvoller, die
Ressourcen der Communities synergetisch zu nutzen und das Gemeinsame
herauszuarbeiten? Außer man verfolgt eigene, unkoordinierte
Interessen im Rahmen der Vereinsarbeit: das ist auch OK, aber dann
bitte nicht über fehlende Manpower klagen.<br>
<br>
Wenn es nur um Authentifzierung geht, spricht vielleicht auch
Einiges für Radius, da solcherart unterschiedliche Backends und
Realms genützt werden können und eine gewisse Abstraktion für den
Zweck vorherrscht. (php-radius?).<br>
<br>
LDAP hätte demgegenüber den Vorteil, dass es sich eben um die
vollständigen Directories mit ACLs handelt, was dem Zweck
kooperierender Communites entgegen käme.<br>
Radius wiederum könnte sich zugleich auch für richtlinienkonforme
und Community-übergreifende Hotspots (nach dem Vorbild von eduroam)
auch gegenüber Endnutzern als Vorteil erweisen.<br>
<br>
In der Praxis steht "slapd" den "drei Teilen" als Einheit gegenüber,
da es als Server das Protokoll implementiert und auf das jeweilige
Backend zugreift.<br>
<br>
<blockquote cite="mid:20160421095231.GR15138@kriegisch.at"
type="cite">
<pre wrap="">Die Entscheidung -- so wie es im Moment steht -- ist wohl, dem Wiki eine
eigene, getrennte Authentifizierungsdatenbank zu lassen; kann man bestimmt
anders machen, allerdings 'brauchen' wir nicht gleich Shibboleth nur weil
ein Plugin im Mediawiki grad nicht geht.</pre>
</blockquote>
Das nicht funktionierende Plugin habe nicht ich thematisiert.<br>
<br>
Meine Kritik bezog sich auf den von einer Minderheit geübten den
Umgang mit Beiträgen (Einstufung als relevant oder irrelevant), die
Mitglieder zusammengetragen haben, worin ich eine im Detail
dargelegte Unvereinbarkeit mit dem Statut zu erkennen glaube.<br>
<br>
Erst im Zuge dieser Diskussion habe ich angemerkt, dass eine
vollständige Migration inklusive der bestehenden Accounts für mich
mehr Sinn ergeben hätte, und, dass wenn schon daran gearbeitet
würde, die Implementierung irgendeines SSO-Verfahrens sinnvoll wäre.<br>
<blockquote cite="mid:20160421095231.GR15138@kriegisch.at"
type="cite">
<pre wrap="">
lg Adi
[1] <a class="moz-txt-link-freetext" href="http://shibboleth.net/">http://shibboleth.net/</a>
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
LG<br>
Erich<br>
<br>
</body>
</html>