Re: Fragen zu BSD in der Schule

Am 29.02.12 21:15, schrieb Polytropon:
> On Wed, 29 Feb 2012 20:38:53 +0100, Heiko Grill wrote:
>> Am 29.02.12 18:59, schrieb Polytropon:
>>> On Wed, 29 Feb 2012 18:34:36 +0100, Heiko Grill wrote:
>>>> Hallo an alle,
>>>>
>>>> wir haben an unserer Schule 8 PC's testweise auf PCBSD 9.0 umgestellt.
>>>> Wir wollen einfach testen,
>>>> ob wir hier besser mit fahren als mit den bisherigen Rechnern auf
>>>> Windows-Basis (XP, Vista und Windows 7).
>>> Sehr vernünftig, wenngleich zu prüfen ist, ob die
>>> verantwortlichen Kostenträger damit einverstanden
>>> sind, denn "was nix kost, des is au nix". :-)
>> Das ist zu Zeiten von Kostendruck schon lange nicht mehr haltbar.
> Wo Geld keine Rolle spielt (d. h. wo Steuermittel fließen),
> merkt man oft von Kostendruck noch nichts. Die Folge ist
> Geldverschwendung. Ich hoffe, daß in diesen Bereichen, von
> denen es meiner Ansicht nach noch viel zu viele gibt, die
> Realität auch bald an die Türe klopft. :-)
>
>
>
>> OpenSource hat schon lange an Schulen Einzug gehalten, gerade auch bei uns.
> Das ist begrüßenswert, sinnvoll und notwendig.
Und macht Geld für andere Dinge frei. Wir haben zum Beispiel jetzt
Gelder für eine Orchesterklasse und eine Laptopklasse, die eben über
freie Gelder und Elternzuschüsse machbar sind.
>
>
>
>> Also, wir haben als Schulträger die Kirche und sind von daher ziemlich
>> frei in unseren
>> Entscheidungen. Wir nutzen z. B. OpenOffice generell an der Schule, vlc,
>> Firefox usw.
>> Das meiste läuft hier auf OpenSource, nur das BS eben als Windows
>> (Client) und auf
>> Linux (kommerzieller Server "IServ", das ist eine recht brauchbare
>> Software für Schulen). Da das
>> unter Wartungvertrag steht, kann ich da nicht so viel dran rumfummeln.
> Externalisierung von Kosten (Wartungsvertrag, Berater usw.)
> scheint oft ein Mittel zu sein, "Kostendruck" zu senken,
> da es gilt: Sachkosten gut, Personalkosten schlecht. Damit
> geht natürlich über kurz oder lang das (unterbezahlte)
> qualifizierte Personal flöten. :-)
Wir haben schon einen Mitarbeiter für EDV, aber der ist sehr
Windowslastig und höchstens rudimentär fit in Linux. Aber wir haben
jedenfalls jemanden der z.B. die Hardware nach unseren Anweisungen
aufbaut und konfiguriert. Mit BSD ist er aber überfordert. Das ist mehr
mein Ding zusammen mit einer Gruppe interessierter Schüler.
>
>
>
>> Wir haben einige sehr interessierte Lehrer, die auch ein solides
>> Verständnis für EDV mitbringen, aber alles geht eben nicht so einfach
>> (für uns).
> Das sind Voraussetzungen, die, so kurz von Dir geschildert,
> schon um Größenordnungen besser sind als der Durchschnitt,
> der im Schulwesen anzutreffen ist. Daher finde ich Deine
> Idee, etwas auf BSD-Basis aufzubauen, sehr lobenswert - es
> ist ein gutes Projekt, das Kosten mindert und sowohl Komfort
> als auch Effizienz steigert, die Sicherheit natürlich auch.
>
>
>
>>>> 1. Es gibt einen Gastzugang, der nach dem Ausloggen immer in den Zustand
>>>> zurückkehren soll,
>>>> in dem er gestartet ist, d.h alle Änderungen sollen nach dem Ausloggen
>>>> verschwunden sein. Wie kann man das am besten hinbekommen?
>>> Sehr einfach: Sachen, die nicht geändert werden können
>>> sollen, werden z. B. auf root:<nutzer> mit rw/r-/-- gesetzt.
>>> Damit können sie vom Benutzer nicht mehr geändert werden.
>>>
>>> Sachen wie temporäre Dateien von Webbrowsern können per
>>> Skript entfernt werden: Die Ein- und Auslog-Vorgänge sind
>>> in ~/.login und ~/.logout entsprechend zu definieren.
>>> Während der Sitzung können sie gelesen und geschrieben
>>> werden, danach sind sie weg.
>> Ich möchte natürlich auch, dass die Schüler rumspielen dürfen. Sie
>> sollen ja gerade das "Neue" kennenlernen. Also Verzeichnisse anlegen,
>> Daten löschen hinzufügen, Bildschirmschoner, Hintergrund usw.. Das würde
>> ich ungern einschränken. Experimentieren ist erwünscht, aber hinterher
>> soll alles wieder "jungfräulich" sein. Das ist wohl mit Lese- und
>> Schreibeinschränkungen so nicht machbar.
> Das Entfernen des Schreibrechtes betrifft nur Sachen, die
> ausdrücklich _nicht_ geändert werden dürfen. Alles andere
> würde ich in einem "Vorlage-Archiv" organisieren, wobei
> dessen Inhalt, wie bereits jemand illustriert hat, durch
> den Displaymanager beim Anmelden der Sitzung entpackt wird.
> Bei jedem Start der X-Sitzung ist dann alles "wie neu",
> kann während der Sitzung bearbeitet werden, und hat darüber
> hinaus keinen Bestand.
Ich werde mal sehen, wie ich das aufbaue. Grundsätzlich finde ich die
Idee schon gut.
>
>
>> Ich hatte an so etwas wie mount_unionfs(8) gedacht, aber komme nicht so
>> richtig in Schwung ;-)
> Ich finde die Idee mit dem vorbereiteten tar-Archiv recht
> gut. Beispielsweise können davon auch mehrere in /home/templates
> angelegt werden, wo sonst niemand außer dem Systemadministrator
> drin rumbollwerken kann. Den Rest macht xdm oder kdm. Der
> Vorteil hier ist: Es ist weitgehend unabhängig vom verwendeten
> Desktopsystem, d. h. sollte man mal von KDE auf Gnome umstellen,
> gibt es wenige Migrationshindernisse.
>
>
>
>> NFS wäre toll, aber ist auf dem (kommerziellen) Server nicht am laufen.
> Schade. Kostendruck? :-)
Ich denke, das wir das durchkriegen würden, wenn wir die Argumente
haben. Unser Schulleiter ist schon ein EDV-Freak ;-) Mal sehen. wie wir
das machen- Ich habe ja root-Rechte auf dem Linuxserver, aber im Falle
eines Falles kann ich da Ärger bekommen, falls die ganze Schule
EDV-mässig ausfällt oder eingeschränkt ist.
>
>
>
>> Geht alles über Samba und leider nicht über LDAP, sondern blöderweise
>> password-Datei (schrecklich ca. 500 logins in passwd).
>> Muss also über samba und wohl mount_smbfs(8) laufen.
> Die Verteilung von Benutzerkonten kann man ggf. skripten,
> indem man sich eine CSV-Datendatei anlegt, ggf. mit einem
> Frontend-Dialogprogramm (zum Anlagen, Ändern und Löschen
> von Einträgen), die dann pw-Kommandos generiert und die
> erzeugten Paßwort-Dateien, also etwa
>
> /etc/passwd
> /etc/passwd.db
> /etc/master.passwd
> /etc/master.passwd.db
> /etc/pwd.db
> /etc/spwd.db
>
> auf die Systeme verteilt (es sei denn, sie stehen auch per
> SMB-Mount zur Verfügung). Bei 500 Benutzerkonten ist das
> durchaus noch überschaubar und sollte nicht allzu I/O-lastig
> werden.
Also Anmeldung an den Samba-Server wäre nicht so gut oder wie muss icg
das verstehen?
Grüße

Heiko

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 29 Feb 2012 - 22:43:08 CET