Schulnetzwerk

In den letz­ten bei­den Wochen habe ich mich ein wenig in unser Schul­netz­werk ein­ge­gra­ben – als medi­en­päd­ago­gi­scher Bera­ter kann man es ja nicht auf sich sit­zen las­sen, dass man anders­wo nichts vor­zu­stel­len hat – zudem haben wir hier mitt­ler­wei­le vor Ort so aus­ge­zeich­ne­te Bedin­gun­gen, dass sich bestimmt auch ein­mal eine Tagung orga­ni­sie­ren lässt. Weil unser Schul­trä­ger zur­zeit mas­siv in bau­li­che Maß­nah­men inves­tiert, ist man geneigt, sich bei der Bean­tra­gung von Mit­teln für den Ver­mö­gens­haus­halt eher zurück­zu­hal­ten oder eben noch etwas zu warten.

Bei uns man­gelt es nicht an Kup­fer, das im Gebäu­de ver­legt ist – es gibt sogar Glas­fa­ser­stre­cken zwi­schen den ein­zel­nen Gebäu­de­tei­len. Es gibt in den Natur­wis­sen­schaf­ten und in ein­zel­nen Gebäu­de­tei­len auch WLAN, jedoch längst nicht flä­chen­de­ckend. In den PC-Räu­men wer­keln noch P4‑2,8Mhz-Kisten mit 512MB RAM vor sich hin. Zur betreu­en­den Fir­ma kann ich noch nicht viel sagen – so rich­tig habe ich noch nicht mit ihr zusam­men­ge­ar­bei­tet. Gut wäre auf lan­ge Sicht sicher ein peri­odi­scher Ter­min zur Sich­tung und Bespre­chung der anfal­len­den Aufgaben.

Ein wenig möch­te ich das Netz­werk pla­nen und sei­nen Auf­bau koor­di­nie­ren, wer­de in der Anfangs­zeit aber etwas sel­ber zau­bern müs­sen. Immer wie­der mache ich die Erfah­rung, dass sich dabei viel Gehirn­schmalz und Arbeit am Anfang unge­mein posi­tiv für die lang­fris­ti­ge Aus­rich­tung aus­wir­ken. Fol­gen­de Grund­sät­ze hal­te ich für Schul­netz­wer­ke mitt­ler­wei­le für essentiell:

  1. Eine zen­tra­le Authen­ti­fi­zie­rung ist unbe­dingt not­wen­dig. Ich nut­ze für mei­ne Web­ser­vices dafür seit Jah­ren LDAP – kann auch ein AD (Win­dows) sein. Das ist qua­si das Backend für alles wei­te­re – am bes­ten mit zumin­dest peri­odi­scher, nicht-phy­si­ka­li­scher Anbin­dung (CSV, USB-Stick) an das Ver­wal­tungs­netz der Schu­le. Dann kann man auch das mit der Daten­spar­sam­keit realisieren.
  2. PC-Räu­me sind sowas von eight­ies. Die Zukunft liegt in der Cloud, die man sich ent­we­der selbst bas­telt oder ein­kauft. Fol­ge­rich­tig muss ein wesent­li­ches Augen­merk auf WLAN und Uplink lie­gen, um mit­tel­fris­tig vie­le mobi­le Gerä­te bedie­nen zu können.
  3. Soft­ware­de­ploy­ment ist der Schlüs­sel für Nach­hal­tig­keit. Soft­ware muss sich zwin­gend zen­tral ver­tei­len las­sen, am bes­ten per PXE. So hat z.B. eine Fir­ma einen zen­tra­len Punkt, an dem neue Soft­ware ein­ge­pflegt wird – das spart War­tunsg­kos­ten und öff­net gedank­li­che Räu­me für die Wei­ter­ent­wick­lung des Schul­netz­werks. Lösun­gen dafür gibt es vie­le, z.B. opsi, fog oder RIS.
  4.  Ohne didak­ti­sches Kon­zept ist jedes Schul­netz­werk wert­los. Die Tech­nik muss die Fre­ir­räu­me schaffen.
  5. Ohne Fort­bil­dung des päd­ago­gi­schen Per­so­nal ist jedes Schul­netz­werk wert­los. Die Tech­nik muss die Frei­räu­me schaffen.
  6. Das Sys­tem selbst muss didak­ti­sches Poten­ti­al und Par­ti­zi­pa­ti­ons­mög­lich­kei­ten schaf­fen – War­um nicht Schü­le­rin­nen und Schü­ler mit in die Arbeit inte­grie­ren? Da gibt es viel zu ler­nen und zu erfah­ren. Also Open­So­ur­ce. Zumin­dest auf dem Server.
  7. Das Netz­werk muss Band­brei­te lie­fern – Gbit ist Min­dest­stan­dard – vor allem bei den Switches.

Momen­tan habe wer­den unse­re Cli­ents mit dem schon nicht mehr erhält­li­chem Micro­soft Shared Com­pu­ter Tool­kit so ver­ram­melt, dass Ände­run­gen an der loka­len Instal­la­ti­on auch ohne Zusatz­hard­ware nicht mög­lich sind. Ein Schul­ser­ver regelt Frei­ga­ben via Sam­ba und fun­giert gleich­zei­tig als Netz­fil­ter – über den Ansatz lässt sich treff­lich strei­ten, aber er funk­tio­niert. Lei­der bringt er diver­se Nach­tei­le mit sich, die die Punk­te 4+5 mei­ner Lis­te betreffen. 

Eine Soft­ware auf allen unse­ren Cli­ents zu instal­lie­ren, dau­ert unge­fähr 20 Arbeits­stun­den, da nicht nur die Soft­ware ein­ge­spielt wer­den will, son­dern auch die Rech­ner immer wie­der aus der Domä­ne flie­gen usw.. Das geht so nicht. Des­we­gen Deploy­ment (Punkt 3) – image- (fog) oder sys­tem­dienst­ba­siert (opsi).  Das ist ein Muss – gera­de auch in hete­ro­ge­nen Sys­tem­land­schaf­ten mit ver­schie­de­nen Win­dows­ver­sio­nen. Es gibt schi­cke Win­dows­lö­sun­gen, z.B. RIS. Kos­tet. Summen.

Per­spek­ti­visch muss so oder so ein neu­er Ser­ver her, der z.B. einem even­tu­el­lem Dienst­leis­ter die Grund­la­ge für eine War­tungs­tä­tig­keit bie­tet. In Nie­der­sach­sen läuft das an vie­len Schu­len über iserv. Es ist die in mei­nen Augen zur Zeit aus­ge­reifs­tes­te Schul­ser­ver­lö­sung über­haupt (neben paedML aus BW) – kos­tet aber. Bezeich­nen­der­wei­se ist die Kis­te an einer Schu­le ent­stan­den, die Punkt 6 mei­ner Lis­te sehr ernst genom­men hat. Dum­mer­wei­se kann iserv von Hau­se aus kei­ne Ter­mi­nals bedie­nen – das hät­te ich aber soooo ger­ne. Die Vor­stel­lung, 0815-Hard­ware auch in öffent­li­chen Berei­chen der Schu­le zur Ver­fü­gung stel­len zu kön­nen, fin­de ich nett. Zudem kön­nen unse­re bestehen­den Cli­ents PXE. Fürs Ter­mi­nal reicht die Hard­ware dicke.

Wo will ich hin?

  1. Kol­le­ge XY hat den Wunsch nach einer Soft­ware, die idea­ler­wei­se frei ver­füg­bar ist (sonst muss er die Lizen­zen eben auf­trei­ben). Ich oder ein Schü­ler oder ein Dienst­leis­ter modi­fi­ziert Remo­te das Basis­image. Ein Sys­tem­dienst weckt nachts die Cli­ents via WOL auf und spielt das Image neu auf. Kol­le­ge XY kommt am nächs­ten Mor­gen und kann arbeiten.
  2. Die Fest­plat­te eines Note­books an einem SMART-Board ver­sagt. Der Tech­ni­ker der Hard­ware­fir­ma kommt mit einem Ersatz, boo­tet via PXE und das Image wird ohne Nut­zer­ein­griff restau­riert auf den letz­ten Stand.
  3. Das Note­book in der Che­mie ohne fes­ten Netz­zu­griff wird durch einen Kol­le­gen ver­kon­fi­gu­riert. Ich sage dem Schul­as­sis­ten­ten Bescheid, der es zu sich in die Werk­statt nimmt und per PXE über einen GBit-Uplink zum Deploy­ment­ser­ver das Image restau­riert und nach 30 Minu­ten wie­der in die Che­mie stellt.
  4. Ein Media­ser­ver im Schul­netz ver­sorgt nach Klä­rung von Lizenz­fra­gen das Schul­netz per DLNA mit Audio­files (Fremd­spra­chen-CDs) und Fil­men (z.B. Mer­lin). Jedes Android‑, iOS- oder Sonst­wie­ge­rät mit DLNA-Cli­ent spielt das im Klas­sen­raum z.B. über WLAN ab. DLNA-Cli­ents sind übri­gens oft sehr schi­cke Apps, mit denen jeder Maus­schub­ser zurechtkommt.

Tech­nisch ist das alles mög­lich – heu­te, kom­plett mit Open­So­ur­ce. Müss­te das für unse­re Schu­le umge­setzt wer­den, wür­de ich inkl. Migra­ti­on bei einer fähi­gen Fir­ma dafür drei Wochen mit ca. 120 Mann­stun­den ( 80,- Euro Stun­den­satz – soll ja eine fähi­ge Fir­ma sein) anset­zen. Dann wäre mit einem Kapi­tal­ein­satz von ca. 20.000 Euro inkl. Hard­ware aber für eini­ge Zeit Ruhe. Und: Man spart auf mitt­le­re Sicht erheb­lich bei den War­tungs­kos­ten. Außer­dem habe ich eigent­lich das Unter­rich­ten gelernt und soll­te mich dar­auf kon­zen­trie­ren. So – und jetzt Fundraising.

Das Märchen von der Softwarefirewall

Mitt­ler­wei­le kann man sich kaum noch ret­ten vor einer Viel­zahl von Pro­gram­men, die die Sicher­heit eines Com­pu­ter­sys­tems erhö­hen sol­len. Ganz all­ge­mein fasst man der­ar­ti­ge Pro­gram­me unter dem Begriff „Fire­wall“ zusam­men. Was macht nun eine sol­che „Fire­wall“ genau?

Erst­mal ist eine in Soft­ware­fire­wall ein Pro­gramm, das den ein­ge­hen­den Daten­ver­kehr zu einem Com­pu­ter­sys­tem über­wacht, regle­men­tiert und ana­ly­siert. Gleich­zei­tig sorgt es dafür, dass auf dem PC nicht Pro­gram­me auf Ver­bin­dun­gen aus dem Inter­net lau­schen, die even­tu­ell schäd­lich sein könn­ten. Eine gute Soft­ware­fire­wall ana­ly­siert zudem den Inhalt von ein­tref­fen­den Daten­pa­ke­ten nach schäd­li­chem Inhalt, etwa Virensignaturen.

Ein Soft­ware­fire­wall ver­hin­dert jedoch nicht, dass Pro­gram­me mit dem Inter­net Kon­takt auf­neh­men, die man für die nor­ma­le Arbeit dort benö­tigt, etwa einen Inter­net­brow­ser. Tat­säch­lich kom­men vie­le Viren aber genau auf die­sem Weg auf den Rech­ner: Es wer­den Sicher­heits­lü­cken von Brow­sern, E‑Mailclients usw. aus­ge­nutzt. Des­halb bleibt es nach wie vor wich­tig, dass man die Soft­ware, die man zur Arbeit im Inter­net benö­tigt, auf aktu­el­lem Stand hält – die­se Arbeit nimmt einem die Soft­ware­fire­wall lei­der nicht ab.

Womit wir beim einem wich­ti­gen Punkt wären: Vie­le Nut­zer den­ken, dass die Instal­la­ti­on einer Fire­wall für den per­sön­li­chen Schutz aus­reicht. Dabei sind die meis­ten Soft­ware­fire­walls völ­lig macht­los gegen­über den klas­si­schen Ein­falls­to­ren für Viren (Brow­ser­lü­cken, E‑Mailanhänge).

Zudem lau­fen Soft­ware­fire­walls in der Regel mit erwei­ter­ter­ten Rech­ten auf einem Sys­tem und sind als Pro­gram­me selbst prin­zi­pi­ell anfäl­lig gegen­über Angrif­fen, etwa durch mani­pu­lier­te Daten­pa­ke­te, die z.B. einen klas­si­sche Buf­fero­ver­flow aus­lö­sen. Damit wird eine Soft­ware­fire­wall selbst zu einer Kom­po­nen­te, die eine poten­ti­el­le Gefaht dar­stel­len kann. Daher sind pro­fes­sio­nel­le Fire­walls als Appli­ance (= Kom­bi­na­ti­on aus Hard- und Soft­ware) rea­li­siert. Bei Ihrem Ver­sa­gen fällt die Aplli­ance, nicht jedoch auto­ma­tisch das von ihr zu schüt­zen­de Netzwerk.

Es geht doch viel einfacher:

Alle Pro­gram­me, die ins Inter­net Ver­bin­dun­gen auf­bau­en, wer­den ein­fach auf aktu­el­lem Patch­le­vel gehal­ten. Alle Pro­gram­me, die nicht benö­tigt wer­den, sind schlicht und ergrei­fend zu deak­ti­vie­ren. Wel­chen Sinn hat dann noch eine Soft­ware­fire­wall außer das Gewis­sen des Anwen­ders zu beruhigen?

Lei­der kann man nicht von jedem erwar­ten, dass er weiß, wie man unnö­ti­ge Diens­te auf sei­nem Sys­tem deak­ti­viert. Lei­der kann man nicht von jedem erwar­ten, dass er sich im Aktua­li­sie­ren von Stan­dard­soft­ware aus­kennt. Lei­der wie­gen gera­de sol­che Anwen­der sich durch das Instal­lie­ren einer Fire­wall in fal­scher Sicherheit…