Re: Fragen zu BSD in der Schule

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.

> 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 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 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? :-)

> 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.

-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message