1 |
Hallo |
2 |
|
3 |
auf der Uni haben wir ein ähnliches System, wie du aufbauen möchtest. Wir benutzen NFS und damit kommen wir prima zurecht. |
4 |
|
5 |
Die HOMEs haben wir auf einem Server (der sich nur um die HOMEs kümmert) und die Clients mounten die HOMES per NFS. Das |
6 |
geschieht automatisch, wenn der Benutzer sich einloggt, wir benutzen net-fs/autofs und funktioniert echt zuverlässig. |
7 |
|
8 |
Root auf den Client kann nicht auf die gemountete HOMES zugreifen. Wenn der Benutzer ein chmod 700 ~ gemacht hat oder |
9 |
so, dann kann keiner außer der Benutzer selber auf seine Daten zugreifen. Weitere Schutzmechanismen haben wir nicht, |
10 |
weil man sie selber mittels chmod einstellen kann. |
11 |
|
12 |
Wir haben an sich keine Authentifizierung auf den NFS Server, aber nur Uni Rechner dürfen überhaupt etwas über NFS |
13 |
mounten. Dabei haben wir auf dem NFS Server folgendes: |
14 |
|
15 |
/etc/hosts.deny: |
16 |
cat /etc/hosts.deny |
17 |
ALL:ALL EXCEPT localhost:DENY |
18 |
|
19 |
und |
20 |
|
21 |
/etc/hosts.allow: |
22 |
sshd: .uni-freiburg.de |
23 |
mountd: informatik.uni-freiburg.de |
24 |
portmap: informatik.uni-freiburg.de |
25 |
|
26 |
damit können nur unsere Clients etwas über NFS mounten. |
27 |
|
28 |
Da wir sehr viele Clients (mind. 200 über die ganze Fakultät) die auf diese HOMES zugreifen, haben wir eine zentrale |
29 |
/etc/groups, /etc/passwd, /etc/shadow, die auf jedem Client gleich ist. Diese Dateien werden in 15 Minuten Takt überall |
30 |
verteilt und somit haben wir auch keine Probleme mit den Rechten auf den Clients. |
31 |
|
32 |
Somit ist es möglich verschiedene Systeme zur Userverwaltung benutzt werden. Momentan benutzen wir eine Eigenentwicklung |
33 |
(basiert auf Oracle Datenbanken, glaub ich), aber ein LDAP Einsatz ist nach wie vor möglich. Ich hatte vor letztes Jahr |
34 |
in LDAP umzusteigen, aber am Ende hat es sich nicht durchgesetzt. |
35 |
|
36 |
Im Rechenzentrum unser Uni haben wir LDAP für die Benutzerverwaltung und auch einen NFS + autofs Lösung und die scheint |
37 |
gut zu funktionieren (ich habe mit dem Rechenzentrum nichts zu tun, deswegen kenn ich keine weitere Details). |
38 |
|
39 |
Ich hoffe, ich konnte dir helfen, vielleicht ist ein Umstieg von NFS auf OpenAFS gar nicht nötig. |
40 |
|
41 |
Gruss |
42 |
Pablo |
43 |
|
44 |
Pablo Yánez Trujillo |
45 |
http://klingsor.informatik.uni-freiburg.de/ |
46 |
|
47 |
|
48 |
Fabian Steiner wrote: |
49 |
> Hallo! |
50 |
> |
51 |
> Erstmal einige Infos vorweg: |
52 |
> Ich administriere zusammen mit zwei weiteren Lehrern die rund 30 |
53 |
> Linux-Rechner an unserer Schule. Im Moment läuft die Benutzerverwaltung |
54 |
> auf einem eher unkonventionellen, aber gut funktionierendem Weg auf |
55 |
> Basis selbstgestrickter Skripte und Programme. Die Home-Verzeichnisse |
56 |
> der Benutzer werden dabei mittels NFS vom Server exportiert und bei den |
57 |
> Clients eingebunden. |
58 |
> Im Rahmen einiger Neuerungen wollen wir zukünftig eine mehr oder weniger |
59 |
> standardisierte Lösung einsetzen, wobei uns insbesondere OpenLDAP |
60 |
> anspricht. Nun suchen wir jedoch einen "sicheren" Ersatz für NFS und |
61 |
> dies ist der Punkt, wo ihr ins Spiel kommt ;-) |
62 |
> |
63 |
> Dabei sollen vor allem folgende Punkte sichergestellt werden: |
64 |
> -> es soll eine Authentifizierung der Maschine stattfinden, d.h. darf |
65 |
> der jeweilige Rechner sich überhaupt in das Schulnetz einhängen |
66 |
> -> wenn möglich, sollte nur bei Bedarf etwas gemountet werden, d.h. |
67 |
> meldet sich Schüler XYZ an, soll das Homeverzeichnis von XYZ gemountet |
68 |
> werden |
69 |
> -> lokaler root sollte keinen Zugriff bzw. kaum Rechte auf den Export |
70 |
> haben (ähnlich wie bei NFS: root_squash/no_root_squash) |
71 |
> |
72 |
> Wir haben uns natürlich schon etwas informiert, sind jedoch nur auf |
73 |
> OpenAFS gestoßen, was ansich zwar nett aussieht, aber auch viele |
74 |
> zusätzliche Baustellen mit ins Boot zieht (Kerberos, etc.), was wir |
75 |
> eigentlich vermeiden möchten. Zudem scheint es, als ob man in diesem |
76 |
> Fall um eine zweifach vorhandene Benutzerverwaltung nicht herumkommt, |
77 |
> was wir unter allen Umständen vermeiden möchte, da dies den |
78 |
> Administrationsaufwand erheblich steigert. |
79 |
> |
80 |
> Kennt jemand noch andere Alternativen, die sich für einen solchen Fall |
81 |
> anbieten würden? |
82 |
> |
83 |
> Vielen Dank schon mal für eure Antworten! |
84 |
> |
85 |
> Viele Grüße, |
86 |
> Fabian Steiner |
87 |
-- |
88 |
gentoo-user-de@g.o mailing list |