hallo, ich benötige mal ein paar tipps von euch.
ich habe hier gerade ein projekt in arbeit,
-an fünf standorten werden büroserver (amd64,1.8ghz standardkernel 2.6.17.13) eingerichtet, diese machen internetzugang/webproxy, email, firewall, .... das übliche.
-jeder server bedient 5-8 diskless-clients (linux), die zum browsen, office, und ein paar andere nicht unbedingt spektakuläre anwendungen laufen lassen
-alle standorte sind durch ein vpn vernetzt, normale dsl-zugänge, einmal isdn (keiner will dort dsl anbieten
-nis-server


nun meine fragen
1. muss ich mit problemen mit der anzahl der verfügbaren file-handles und prozessanzahlen (viele nfs-kontakte, dazu internet etc) auf dem server rechnen, da alles von einer maschine erledigt wird. sollte ich den kernel entsprechend verändern, was wäre dabei zu tun/beachten?
2. in allen standorten sollen die user ihr homeverzeichnis vorfinden, die mindestens einmal am tag abgeglichen werden sollen. da die internetanbindung nicht immer zuverlässig ist, soll das homeverzeichnis also auf allen standorten gecacht werden und bei ausreichender datenrate auf dem internetzugang (zb nachts) abgeglichen werden. bevor ich was mit rsync oä bastel, welche unter linux verfügbaren filesysteme unterstützen soetwas mit entsprechend sinnvollem adminaufwand. hat jemand soetwas schon gemacht und kann mir einen tipp geben?

noch eine frage:

ich habe jetzt in die root-verzeichnisse für die diskless-stationen die verzeichnisse bin, sbin, lib mit hardlinks gelegt. ich wollte diese eigentlich mit mount --bind mounten und zwar
mount --bind /bin /tftpboot/diskless/bin
in der exports steht dann

aber der nfs gibt die nicht frei. lässt sich nfs evtl doch dazu bewegen?

noch eine eigenartige sache.

im server ist eine gigabit-ethernetkarte und in den clienten eine rtl8139d. wenn die disklessclienten über einen 100mbit router verbunden sind, läuft das booten absolut reibungelos. ersetze ich den 100m-router duch einen gigabit-switch longshine lcs-gs7 108a, dann läuft die dhcp abwicklung manchmal reibungslos, manchmal erst nach 20-30sekunden.
die dhcp-anfrage kommt beim server an undder schickt eine bestätigung raus. der client empfängt aber nichts.
hat jemand eine idee, woran das liegen könnte?

alle karten laufen mit autonegotiation, mit voller geschwindigkeit und full-duplex (nach ethtool)

Zitat

der server
root@athlon64:~# ethtool eth1
Settings for eth1:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: external
Auto-negotiation: on
Supports Wake-on: g
Wake-on: d
Link detected: yes
root@athlon64:~#

ein client
root@diskless1:~# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes
root@diskless1:~#

nachdem der client seine ip dann endlich hat, läuft alles wie am schnürchen.
nur die ip-zuweisung funktioniert unsicher. bau ich den 100mb-router wieder ein, klappt wieder alles wunderbar.

was ist hier los?
gigabitswitch defekt oder müll?

so, nachdem die diskless nun tadellos funktionieren und das x durchkonfiguriert ist ( ausser das problem mit dem gigabit-switch, der sperrt sich noch immer) nehme ich nun punkt2 meiner problemliste in angriff.
ich versuche das jetzt mit afs (openafs) in den griff zu bekommen. hat jemand einen guten link mit einer deutschen dokumentation/anleitung/howto für mich?

hallo michael,
vielen dank für deine antwort, endlich redet mal jemand mit mir

Zitat

Original von Michael
http://www.openafs.org/ Documentation Quickstart for Unix[/qote]
ja, da habe ich mich schon umgesehen und die docs auch runtergeladen und mit installiert. aber in deutsch habe ich noch nichts gutes gefunden, da meine eigene übersetzung aus dem englischen manchmal etwas missverständlich und zweideutig ist

Zitat

Ich bin mir aber nicht sicher, ob AFS das richtige für Dich ist, gerade auch wegen dünner WAN-Leitungen.
AFS hat die Replikationsstrategie "ROWA", d.h. "read one, write all" ...
Lesend kann der jeweilige Client immer recht schnell zugreifen, der Schreibvorgang wird auf allen AFS-Servern gleichzeitig ausgeführt ("write all = langsam") und ist erst abgeschlossen, wenn der letzte Server fertig ist (ISDN?!)

tja sicher bin ich mir auch noch nicht, hab die doku aber bis jetzt soweit verstanden, dass ein durchschreiben nicht undbedingt notwendig und sinnvoll ist, sondern auch cron-artig in bestimmten zyklen durchgeführt werden kann und das filesystem vorort gecachet wird.

der administrationsaufwand scheint mir im moment jedoch recht hoch zu sein

Zitat

Evtl. fährst Du mit einem Cluster-FS (ocfs, gfs) besser, schau Dir aber unbedingt die Implementierung an und teste ...

Ein weiteres verteiltes FS im Linux-Kernel ist Coda ( http://www.coda.cs.cmu.edu ), das ist - wenn ich mich recht erinnere - eine Neuentwicklung nach den Erfahrungen die man mit AFS gemacht hat, kann z.B. auch unverbunden (disconnected) weiter funktionieren und repliziert bei Wiederaufnahme der Verbindung, etc.

schau ich mir auf jeden fall an, bevor ich (vielleicht) unnötige arbeit in afs stecke.

danke

also ich habe mich letzendlich doch für eine rsync lösung entschieden. der administrationsaufwand für diese dateisysteme ist einfach zu hoch und die doppelte authorisierung ist für diese anwendung absolut inakzeptabel. ich habe die scripte soweit, dass im prinzip keinerlei zusätzlicher konfigurationsaufwand entsteht, wenn ein weiterer büroserver eingebunden werden soll (ist im prinzip eine komplette kopie eines default-abzugs), da die geräte sich untereinander informieren. der abgleich der verzeichnisse erfolgt 2 mal am tag und user die sich auf einer maschine einloggen, werden in den anderen büros bis zum nächsten abgleich gesperrt (datenkonsistenz). den abgleich der homeverzeichnisse habe ich jetzt so geregelt, dass jeder büroserver, der ein abgeglichenes homeverzeichnis besitzt, seinerseits andere büroserver im vpnnetz sucht, die noch nicht abgeglichen sind und einen datentransfer auslöst. damit dürften die homedaten in kürzester zeit abgeglichen sein und wenn ein rechner mal keinen internetkontakt hat (telekom-dsl-router :böse dann ist das auch nicht weiter tragisch für den rest des netzes.

nebenbei:
ich hatte auf den diskless klienten zuerst firefox und thunderbird installiert, musste dann aber feststellen, das der seamonkey-browser merklich schneller startet und die option splash bietet, damit der user nicht 10mal aufs icon klickt

also meine wahl: seamonkey

mal sehen, wie das flashplugin auf den rechnern läuft (bei mir zu hause sorgt es ständig für abstürze des browsers, also deaktivierung)

jetzt brauch ich nur noch einen schicken und stabilen pdf-reader für den xfce.

und wieder ein problem für das ich einen tipp benötige

auf den diskless-clienten startet linux mit über nfs-eingebundenem-rootfilesystem (dhcp/tftp). die uid/gid-verwaltung läuft über einen nis-server, in /etc/passwd und /etc/group sind nur die wichtigsten systemuser eingetragen.

am ende der /etc/passwd der clients ist das + eingetragen und die zuordnung der namen/uids der user funktioniert ausgezeichnet.

nun mein problem
wenn ich das selbe für die gruppen möchte, also an das ende der datei /etc/group das + eintrage und/oder in /etc/nsswitch ein group file nis eintrage, dann bleiben die clientrechner beim starten von rpc.statd stecken. es wird gemeldet, das kein kontakt zum localen portmapper besteht (der aber vorher anstandslos gestartet wurde). das starten von rpc.statd dauert nun mehrere minuten lang und dann bootet der client problemlos..., auch die auflösung der gruppen über nis funktioniert anstandslos.

nehme ich das + aus der /etc/group der clienten heraus, dann bootet der client flott durch, aber die gruppenauflösung funktioniertt nicht.

hat jemand einen tipp, was hier los sein könnte?
her damit

das nis funktioniert generell sehr eigenartig, vielleicht hat ja doch jemand einen tipp.

das problem ist nun, das ps aux nicht den usernamen, sondern die uid ausgibt, der name wird nicht zugeordnet. ein ls -al gibt den besitzer einer datei aber mit dem richtigen namen an?
wie kann ich das problem lösen?
hat jemand einen tipp?