Schlagwort: IServ

Owncloud an bestehende Authentifizierungsysteme anbinden

Kommentar hinterlassen

Own­cloud bie­tet ab der Ver­si­on 6 neben den übli­chen inter­es­san­ten Fea­tures eine kol­la­bo­ra­ti­ve Text­ver­ar­bei­tung an, d.h. meh­re­re Benut­zer kön­nen genau wie bei Ether­pad oder Ether­pad lite gleich­zei­tig an einem Doku­ment arbei­ten. Die For­ma­tie­rungs­mög­lich­kei­ten sind dabei umfang­rei­cher als bei der Ether­pad­de­ri­va­ten, jedoch gegen­über Lösun­gen wir Goo­g­le­Docs noch recht rudi­men­tär. Für vie­le Anwen­dungs­fäl­le reicht es jedoch voll­auf. Wer möch­te, darf das hier nach Ein­ga­be eines Spitz­na­mens ger­ne ein­mal aus­pro­bie­ren. Own­cloud nutzt ODT als nati­ves Format.

Vie­le Schu­len möch­ten ger­ne Own­cloud nut­zen und ver­fü­gen oft schon über eine Schul­ser­ver­lö­sung. Idea­ler­wei­se bie­tet die­se bereits E‑Mailadressen für alle Schul­an­ge­hö­ri­gen über das IMAP-Pro­to­koll an. Das ist z.B. bei IServ der Fall – einer in Nie­der­sach­sen sehr ver­brei­te­ten Lösung. Durch zwei klei­ne Ände­run­gen muss kei­ne sepa­ra­te Nut­zer­ver­wal­tung in Own­cloud mehr betrie­ben wer­den, wenn bereits ein IMAP-Ser­ver im Schul­netz vor­han­den ist.

Es kann eine Grund­in­stal­la­ti­on von Own­cloud als Basis genom­men wer­den. Bei den Apps muss „Exter­nal user sup­port“ zuvor akti­viert wer­den. Eine Datei ist danach zu ändern, eine hinzuzufügen.

Zu ändern­de Datei

Name: config/config.php

Quell­code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<?php
require_once(dirname(__FILE__).'/../apps/user_external/lib/imap_new.php');
 
$CONFIG = array (
  'instanceid' => '<hier_steht_schon_etwas>',
  'passwordsalt' => '<hier_steht_schon_etwas>',
  'datadirectory' => '<hier_steht_schon_etwas>',
  'dbtype' => 'mysql',
  'version' => '6.0.0.14',
  'dbname' => '<hier_steht_schon_etwas>',
  'dbhost' => 'localhost',
  'dbtableprefix' => 'oc_',
  'dbuser' => '<hier_steht_schon_etwas>',
  'dbpassword' => '<hier_steht_schon_etwas>',
  'installed' => true,
  'forcessl' => true,
  'user_backends'=>array(
   array(
      'class'=>'OC_User_IMAP',
      'arguments'=>array('{<server>:<port>/imap/ssl/novalidate-cert}')
   )
  ),
);

Kom­men­tar:
In Zei­le 2 wird der neu zu erstel­len­de Code (s.u.) ein­ge­bun­den, ab Zei­le 17 wird es inter­es­sant, vor allem in der Zei­le, die mit „argu­ments“ beginnt. Die Anga­ben für Ser­ver und Port sind mit den eige­nen Anga­ben zu fül­len. Ich brau­che für den IServ die Anga­be „nova­li­da­te-cert“, da es sich um ein selbst­si­gnier­tes Cert han­delt – daher zicken auch Apple­ge­rä­te ger­ne mit dem IServ, weil sie sich in der Feh­ler­mel­dung nicht klar aus­drü­cken. Nutzt man eine unver­schlüs­sel­te Ver­bin­dung, was allen­falls zu Test­zwe­cken dien­lich ist, sieht das z.B. so aus:

      'arguments'=>array('{meinserver.xy:143/imap}')

Hin­zu­zu­fü­gen­de Datei:

Name: apps/user_external/lib/imap_new.php

Quell­code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

<?php
/**
 * Copyright (c) 2012 Robin Appelman <icewind@owncloud.com>
 * This file is licensed under the Affero General Public License version 3 or
 * later.
 * See the COPYING-README file.
 */
 
class OC_User_IMAP extends OC_User_Backend{
        private $mailbox;
 
        public function __construct($mailbox) {
                $this->mailbox=$mailbox;
        }
 
        /**
         * @brief Check if the password is correct
         * @param $uid The username
         * @param $password The password
         * @returns true/false
         *
         * Check if the password is correct without logging in the user
         */
        public function checkPassword($uid, $password) {
 
                $mbox = @imap_open($this->mailbox, $uid, $password);
                imap_errors();
                imap_alerts();
 
 
                if($mbox) {
                        imap_close($mbox);
 
                        if(OC_User::userExists($uid)) {
                                  OC_User::setPassword($uid, $password);
                        } else {
                                  OC_User::createUser($uid, $password);
                                  $uida=explode('@',$uid,2);
                                  if(($uida[1] || '') !== '') {
                                        OC_Group::createGroup($uida[1]);
                                        OC_Group::addToGroup($uid, $uida[1]);
                       }
 
                }
                        return $uid;
                } else {
                        return false;
                }
        }
 
}

Kommentar: 
Die­ses Code­stück sorgt dafür, dass beim ers­ten Log­in eines Benut­zers ein Ein­trag in die User-Daten­bank von Own­cloud erfolgt. Dabei wird auch das Pass­wort ver­schlüs­selt gespei­chert, da ansons­ten kei­ne Nut­zung über die Apps von Own­cloud mög­lich ist. Der Nut­zer muss sich mit den glei­chen Daten wie am E‑Mailserver anmel­den. Ändert der Nut­zer sein Pass­wort im IServ oder auf dem E‑Mailserver, wird die­se Ände­rung bei bestehen­dem Log­in in Own­cloud übernommen. 

Update:
Mit dem Hack funk­tio­niert auch die Nut­zung mit der Own­cloud-App problemlos.

Methoden, Tech-Talk Anbindung, Authentifizierung, extern, imap, IServ, Owncloud

Netzwerkumbau an der Schule

Ein Kommentar

All­mäh­lich ist hier wie­der Land in Sicht. Wir sind als Schu­le von einer hoff­nungs­los ver­al­te­ten Open­So­ur­ce-Schul­ser­ver­lö­sung auf eine voll­kom­men ande­re tech­ni­sche Basis umge­stie­gen und das im lau­fen­den Schul­be­trieb. Wir nut­zen jetzt IServ – hier ein­mal eine klei­ne Tour durch Möglichkeiten:

Die IServ basiert auf einem nor­ma­len Debi­an-Trä­ger­sys­tem, wel­ches durch ein pass­wort­ge­schütz­tes deb-Repo­si­to­ry durch nicht frei­en Code ergänzt wird, der ent­spre­chend der GPL sau­ber getrennt vom übri­gen Sys­tem­code abge­legt ist. Das macht das Sys­tem so frei, dass nach wie vor Raum für eige­ne Bas­te­lei­en bleibt – z.B. IServ-Modu­le mit Schü­lern ent­wi­ckeln. Gleich­zei­tig ermög­licht die Geschlos­sen­heit des Codes in Ver­bin­dung mit einem Remo­te-War­tungs­ver­trag die exter­ne Pfle­ge des Sys­tems – obwohl es sich weit­ge­hend selbst durch auto­ma­ti­sier­te Scrip­ten pflegt…

Abge­se­hen von unzäh­li­gen durch­dach­ten Funk­tio­nen – z.B. die fern­ge­steu­er­te Rech­ner­war­tung – fas­zi­niert der IServ durch sein Bedie­nungs­kon­zept, das sich auch uner­fah­re­nen Nut­zern intui­tiv erschließt. Der IServ deckt etwa 90% der Funk­tio­nen (Forum, inte­grier­tes und voll­wer­ti­ges Mail­sys­tem, Datei­aus­tausch, Grup­pen­ord­ner etc.) von einer Lern­platt­form ab, wie sie zur­zeit an den meis­ten Schu­len tat­säch­lich(!) genutzt wer­den dürf­ten, so dass ich hof­fe, unser bestehen­des Schul­mood­le (V.2.1+) außer­halb von grö­ße­ren Pro­jek­ten bald nie­man­dem mehr zumu­ten zu müs­sen – am bes­ten gleich Maha­ra oder so ein­füh­ren. Nach vier Tagen Betrieb sind 2/3 der Lehr­kräf­te dort zumin­dest ein­mal ange­mel­det gewe­sen und bereits 15 Mobil­ge­rä­te für den Inter­net­zu­griff frei­ge­schal­tet. Die bis­he­ri­gen „Ahs“ und „Ohs“ sind natür­lich auch zu einem guten Teil unse­rer vor­her bestehen­den Struk­tur geschul­det, aber zuneh­mend auch als „Dif­fe­renz­re­ak­ti­on“ zum Bedien­kon­zept von Mood­le zu sehen.

Die Bedien­bar­keit im Hin­blick auf die Bedürf­nis­se von Schu­len ist natür­lich kein Zufall: Das Sys­tem ist an einer Schu­le als Pro­jekt ent­stan­den und ernährt jetzt immer­hin eini­ge Mit­ar­bei­ter. Der Spaß kos­tet natür­lich etwas – aber weit weni­ger, als es an War­tungs­kos­ten vor Ort ein­spart. Die Migra­ti­on von 1500 Nut­zern (Schü­ler und Leh­rer) auf IServ dau­ert zwar noch an, aber schon jetzt ste­hen wir fast schon bes­ser als vor­her da – nach nur vier Tagen Arbeit (…und kei­ner Stun­de Unter­richts­aus­fall bei mir.).

Unge­wohnt ist dabei mei­ne ver­än­der­te Rol­le: Ich bespre­che und pla­ne not­wen­di­ge Tätig­kei­ten mit den Mit­ar­bei­tern der betreu­en­den Fir­ma und span­ne auch ande­re Betei­lig­te mit ein, obwohl ich eigent­lich lie­ber selbst auf der Lei­ter stün­de und den Acces­s­point anschrau­ben… (aber dann hät­te ich frei­ge­stellt wer­den müssen).

Ach ja – noch­was ist neu: Daten­schutz und Nut­zungs­ord­nun­gen. Bei­des braucht man sehr drin­gend als Schu­le. Mei­ne zustän­di­ges Lan­des­in­sti­tut für Daten­schutz hat mir dabei die Ent­wür­fe von Leh­rer-Online emp­foh­len. Durch ein Tele­fo­nat mit einem Freund aus alten Tagen, der beim ULD arbei­tet, habe ich die Anre­gung bekom­men, zusätz­lich eine Ver­fah­rens­be­schrei­bung zur Gewin­nung per­so­nen­be­zo­ge­ner Daten aus dem Schul­netz zu erstel­len. Ob man bei der gel­ten­den, ver­wor­re­nen Rechts­la­ge damit auf der 100%-sicheren Sei­te ist, darf bezwei­felt wer­den, aber man hat zumin­dest das „Lai­en­mög­li­che“ getan. Zumin­dest dürf­te es ein Anwalt ein wenig schwe­rer haben, Ver­fah­ren auf­grund von Form­feh­lern erfolg­reich anzufechten.

Jetzt kommt noch viel Klein­kram (zicken­de WLAN-Ver­bin­dun­gen, Dru­cker­ein­bin­dung usw.), aber das Wesent­li­che ist geschafft und ich kann die ers­ten Qua­li­fi­zie­rungs­maß­nah­men jen­seits vom Peer­coa­ching zum neu­en Schul­netz andenken.

Aus der Schule, Tech-Talk Datenschutz, IServ, Nutzungsordnung, PC-Raum, Schulnetz, Server, Verfahrensbeschreibung