Hallo Jürgen,
> Am 19.04.2015 um 14:49 schrieb Juergen Engeland > <[email protected]>: > > Hallo Jesko, > > dass ipfire und der Schulrouter einsam und allein im Netzwerk > 10.0.2.0/23 wären und server seine 10.16.1.1/12 behalten könnte, > entspräche nicht mehr ganz den Hamburger Vorgaben … Die kenne ich ja nicht, aber wenn die Vorgabe ist, dass das, was bei dir ankommt, ein 10.0.2.0/23 Netz ist, … das hältst du ja ein :) > Ob dies jemand in der Schulbehörde stören würde oder ob es überhaupt > jemand dort bemerken würde, sei dahin gestellt. vermutlich nicht. Ich kann mir jedenfalls keinen vernünftigen Grund vorstellen. > Allerdings fände ich es schade, deswegen auf den bezahlten Support von > Time for Kids bei der Absicherung des Netzwerks auch nur teilweise zu > verzichten. > Warum müsstest du auf den verzichten? Der TfK-Router würde weiterhin filtern, nur, dass eben noch dein IPFire (wenn du es einstellst) mitfiltert. Vielleicht auch nur deine angepasste Blacklist. > Außerdem kann ich mir vorstellen, dass vorgelagerter Proxy die > Verbindungsgeschwindigkeit nach draußen beeinträchtigt. Ich würde mal sagen, das das kein Problem ist (das mache ich seit Jahren so.) > Unser Server ist > nur ein normales Asus-Mainboard mit einem 3,1 GHz Quadcore und 16 GB RAM > und 2 2TB-Festplatten in einem 19-Zoll-Gehäuse. Darauf ipfire oder alles > virtualisieren? Naja, alles virtualisieren. Mein IPFire hat 2 GB RAM und mein Server 8GB. Das macht zusammen weniger, als deine 16 :) Ich habe 24 GB Ram und einen Doppelprozessor-Server, aber da laufen - 1 IPFire - 1 lmnet 6.1 Server - 1 Coova-Chilli - 1 OPSI-Server - 1Verwaltungsserver (WinHomeServer) - 1 Administrationsrechner Performance-Probleme habe ich keine. Es ist alles schnell genug. > Lieber würde ich bei der augenblicklich überschaubaren > Netzwerkstruktur bleiben! > mein Gefühl sagt mir, dass meine Netzwerkstruktur überschaubar ist (weil alles Standard) und berechenbarer als bei dir, wo am Serverherzen offen operiert wurde, um sich komischen Netzwerkvorgaben anzupassen…. > Noch bin ich zuversichtlich, dass eine Kopplung mit dem Schulrouter > hinzubekommen ist. So wie ich die Sache sehe, fehlt eher auf unserer > Seite jemand, der die Skripte so anpasst, dass sie zur Schnittstelle von > Time for Kids passen. Wir waren mit TfK im Gespräch. Um solche Skripte zu programmieren, muss man die Schnittstellen kennen. Die Schnittstellen wollen sie aber nicht offen preisgeben. Dann hätte ich eine nondisclosure-Vereinbarung unterschreiben müssen. Daraufhin habe ich gefragt, wie ich das garantieren soll, wenn ich dann die Skripte im Github stehen habe (oder der der das macht… ) dann ist ja die Vereinbarung schon gebrochen, weil sich jeder, der einigermaßen Skripte lesen kann die Schnittstellen zusammenreimen kann. seither habe ich nichts mehr gehört. Was für mich halt nicht infrage kommt ist, Software zu entwickeln, die nicht OpenSource ist. Wenn also TfK eine Schnittstelle zu lmn.net haben möchte (wogegen ich nichts habe, dann muss das entweder mit absolut offenen Karten geschehen oder sie müssen es selbst tun. > Da ich wohl einer derjenigen bin, die diese > Schnittstelle haben wollen, könnte ich es mit Eurer Hilfe versuchen. > ich bin gespannt :) > Da dies für OpenML 5.1 bereits einmal gemacht wurde, sollte sich die > dort gefundene Lösung doch als backport in linuxmuster 6.1 integrieren > lassen, oder? Vermutlich schon, aber es hat sich keiner gefunden, der sich vertraglich einen Maulkorb umhängen lässt… > Hierfür sehe ich nicht die Notwendigkeit, eine neue Vereinbarung mit > Time for Kids zu treffen - tfk schon. > es müsste ja eine geben. nö. Wir haben keine. Und auch noch nie eine gehabt. Ich weiß nicht, wer die Anpassungen für openml5 gemacht hat, aber das müssen nachträgliche gewesen sein, die tfk bei ihren Kunden in die Server gepatcht hat. Offiziell ist mir da nichts bekannt. > Gilt diese für das > Skript nicht, wenn es auf einem linuxmuster 6.1 läuft oder wurde sie > aufgekündigt? > weder noch. Siehe oben. > Wenn es so nicht zu machen sein sollte, bleibt die Frage, weshalb > Clients, die nicht in workstations stehen, bei uns auch ohne ipfire > dazwischen keinen Internetzugang haben (weshalb kein Intranet, ist mir > klar!). schau mal nach, ob der dhcp für die Aufnahmeadressen überhaupt ein Gateway raus gibt. Wenn nicht, dann ist klar. Dann weiß der Client einfach nicht, an wen er sich wenden soll, um Google zu erreichen :) > Hierin sähe ich einen zweiten Ansatz, das raumweise Sperren mit der > internen Firewall zu realisieren. > ich denke nicht, dass die interne Firewall da mitredet. Viele Grüße, Jesko
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ linuxmuster-user mailing list [email protected] https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
