Hallo Ich habe am Haupt-PC "nur" ein CDR eingebaut (also kein Brenner), dafür aber in meinem Neben-PC. Dieses würde ich gerne komplett via NFS an meinen Hauptrechner einbinden, aber das ganze klappt nur bedingt. Ich habe schon gegoogelt, aber zu dem Fall gab es nicht viele Infos, die mir weitergeholfen haben. Situation: CPU2 startet, muss mich erst als Benutzer einloggen und dann die CD einlegen, damit diese via NFS exportiert wird. Mache ich das vorher -> cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram mount: cpu2.linuxcobra.lan:/media/dvdram failed, reason given by server: Permission denied Mounte ich "korrekt" (Benuzerlogin auf cpu2, CD rein, mounten) klappt das ganze - für eine gewisse Zeit. Kommt das LW zu einer Zwangspause (zb weil ich mir eine Datei auf der CD anschaue) schaltet sich das ganze ab (exportierte CD ist leer), eine andere CD kann nicht mehr gemountet werden. Irgendwie ist das nervig und störend - vor allem da ja das ganze so halbwegs funktioniert. auf cpu2 läuft OSS 10.0, auf cpu1 OSS 10.2 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Mon, 21 Jul 2008 06:40:41 +0200 Marco Jäger
Ich habe am Haupt-PC "nur" ein CDR eingebaut (also kein Brenner), dafür aber in meinem Neben-PC. Dieses würde ich gerne komplett via NFS an meinen Hauptrechner einbinden, aber das ganze klappt nur bedingt.
Ohne Dir in allen Details folgen zu können, ein paar Hinweise: Bei NFS-Problemen sollte man immer parallel (!) eine Konsole vom nfs-Server mit "tail -F /var/log/messages" mitlaufen lassen. nfs ist eigentlich sehr auskunftsfreudig und insbesondere "permission"-Probleme kann man so viel einfacher eingrenzen. Um die Unterschiede zwischen "mount an der Konsole" und "mounten per Desktop" festzustellen, solltest Du nach dem jeweiligen mounting an der Konsole "mount" aufrufen und die jeweiligen Parameter vergleichen. Es hängt letztlich davon ab, ob und was in der /etc/fstab drinsteht, aber bei mir sieht der Unterschied wie folgt aus: mount per KDE: /dev/sr1 on /media/IX04 type iso9660 (ro,nosuid,nodev,noatime,uid=500,utf8) "mount /dev/sr1 /media/dvd" ohne fstab-Eintrag: /dev/sr1 on /media/dvd type iso9660 (ro) Daraus kann man schon leicht erkennen, dass die Rechte auf das Laufwerk von der Mount-Methode abhängen. Nachdem die meisten nfs-Installationen mit root_squash arbeiten, wird z.B. ein CD-mount, der root gehört, mitunter nicht per nfs verwendbar sein. Oder die UIDs sind inkonsistent. Bei einem Server würde ich das Mounten per Desktop deaktivieren und stattdessen "automount" benutzen. Alternativ befasst man sich mit der Konfiguration von hal. Außerdem sollte man den nfs-Export davon abhängig machen, dass der Mount erfolgreich war. BTW: Eine Ursache für erfolglose umount-Versuche kann KDE sein. Das hat gelegentlich die Eigenart, ein Fenster zu schließen, ohne den Lock aufs Verzeichnis freizugeben. Man findet dann meist irgendwelche kio-Prozesse im "ps axf", deren gewaltsames Ende auch den Lock wieder freigibt. Was bei mir nie wirklich stabil funktionierte: Wenn am "Server" parallel zum nfs-Service mit Schreibwerkzeugen gearbeitet wird, also cdrecord, k3b, usw.. -- Gruß, Tobias. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Montag 21 Juli 2008 um 11:31:29 schrieb Tobias Crefeld:
On Mon, 21 Jul 2008 06:40:41 +0200 Marco Jäger
wrote:
Ich habe am Haupt-PC "nur" ein CDR eingebaut (also kein Brenner), dafür aber in meinem Neben-PC. Dieses würde ich gerne komplett via NFS an meinen Hauptrechner einbinden, aber das ganze klappt nur bedingt.
Ohne Dir in allen Details folgen zu können, ein paar Hinweise:
Bei NFS-Problemen sollte man immer parallel (!) eine Konsole vom nfs-Server mit "tail -F /var/log/messages" mitlaufen lassen. nfs ist eigentlich sehr auskunftsfreudig und insbesondere "permission"-Probleme kann man so viel einfacher eingrenzen.
Anmerkung : cpu2 (NFS-Server) ist immer nebenbei via ssh-Konsole "griffbereit" ;) # << kommentarzeichen für den nächsten "logbereich" - da ich am besten beide Konsolen, bzw Tätigkeiten zeitnah angebe Versuch 1: NFS-Server frisch rebootet, kein User eingeloggt, CD eingelegt cpu2:~ # tail -F /var/log/messages Jul 21 13:04:53 cpu2 kernel: eth0: no IPv6 routers present Jul 21 13:04:53 cpu2 SuSEfirewall2: batch committing... Jul 21 13:04:53 cpu2 SuSEfirewall2: Firewall rules successfully set Jul 21 13:04:53 cpu2 kernel: bootsplash: status on console 0 changed to on Jul 21 13:04:54 cpu2 kernel: ra0: no IPv6 routers present Jul 21 13:06:18 cpu2 sshd[5254]: Accepted keyboard-interactive/pam for root from 192.168.2.21 port 28636 ssh2 # cpu1.root -> manueller mount (NFS ist ohne automount eingestellt) cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram mount: cpu2.linuxcobra.lan:/media/cdram failed, reason given by server: Permission denied # tail auf ssh-konsole cpu2: Jul 21 13:06:18 cpu2 sshd[5254]: Accepted keyboard-interactive/pam for root from 192.168.2.21 port 28636 ssh2 Jul 21 13:08:13 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:900 for /media/cdram (/media/cdram) # mehr Infos kamen nicht hmhh also auskunftsfreudig ? *hust* laut meinem "Verständnis" sagt auf cpu2 der rpc.mountd das die Anfrage ok geht - oder seh ich das falsch??? -warum bekommt also cpu1.root die verweigerung ? *kopfkratz* Versuch 2: auf CPU2 hab ich mich als User unter KDE eingeloggt, cd raus und wieder rein (KDE-Erkennung für CD-Medien staret (das nette fenster wo gefragt wird was man mit der CD machen will)), aber nichts !!! ausgewählt # cpu1.root -> manueller mount cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram cpu1:~ # # tail auf ssh-konsole cpu2: Jul 21 13:21:37 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:983 for /media/cdram (/media/cdram) Jul 21 13:21:46 cpu2 hal-subfs-mount[5521]: SYMLINKS:: disk/by-id/ata-HL-DT-ST_CDRAM_GSA-H10N_2AFEB00ED410 disk/by-path/pci-0000:00:07.1-ide-1:0 cdram cdrom cd Jul 21 13:21:46 cpu2 hal-subfs-mount[5521]: MOUNT_POINT:: /media/cdram Jul 21 13:21:46 cpu2 hal-subfs-mount[5521]: MOUNTPOINT:: /media/cdram Jul 21 13:21:46 cpu2 hal-subfs-mount[5521]: Collected mount options and Called(0) /bin/mount -t subfs -o fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=iso8859-15 /dev/hdc "/media/cdram" Jul 21 13:21:46 cpu2 kernel: ISO 9660 Extensions: Microsoft Joliet Level 1 Jul 21 13:21:46 cpu2 udevd[1927]: get_netlink_msg: no ACTION in payload found, skip event 'mount' Jul 21 13:21:46 cpu2 kernel: ISO 9660 Extensions: IEEE_P1282 Jul 21 13:21:49 cpu2 udevd[1927]: get_netlink_msg: no ACTION in payload found, skip event 'umount' Jul 21 13:21:49 cpu2 kernel: ISO 9660 Extensions: Microsoft Joliet Level 1 Jul 21 13:21:49 cpu2 udevd[1927]: get_netlink_msg: no ACTION in payload found, skip event 'mount' Jul 21 13:21:49 cpu2 kernel: ISO 9660 Extensions: IEEE_P1282 Jul 21 13:21:52 cpu2 udevd[1927]: get_netlink_msg: no ACTION in payload found, skip event 'umount' # Inhaltsverzeichnis der CD ist kurzzeitig lesbar - wenn man via konqueror dort einen reload macht / eine Datei öffnet : Datei/Verzeichnis nicht gefunden Manchmal dauert die Zeitspanne bis die CD "zumacht" etwa 2-3 min , in dieser zeit kann man dann Dateien von der CD abrufen - sobald ma naber eine Pause länger wie 5 Min hat -> 100% stille danach kommt, sebst wenn man die CD wechselt, nur eine verweigerung beim erneuten mount # cpu1.root cpu1:~ # umount cpu2.linuxcobra.lan:/media/dvdram cpu1:~ # mount cpu2.linuxcobra.lan:/media/dvdram mount: cpu2.linuxcobra.lan:/media/dvdram failed, reason given by server: Permission denied cpu1:~ # # tail auf ssh-konsole cpu2: Jul 21 13:21:52 cpu2 udevd[1927]: get_netlink_msg: no ACTION in payload found, skip event 'umount' Jul 21 13:25:45 cpu2 rpc.mountd: authenticated unmount request from cpu1.linuxcobra.lan:607 for /media/dvdram (/media/dvdram) Jul 21 13:25:47 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:611 for /media/dvdram (/media/dvdram) Also das einzige was richtung "Auskunft" gehen könnte, wäre der Teil wenn der NFS-Server die CD exportiert hat und das LW kommt zur Ruhe - beim großen Rest... hmhh nichts an weiterführenden Infos :((
Um die Unterschiede zwischen "mount an der Konsole" und "mounten per Desktop" festzustellen, solltest Du nach dem jeweiligen mounting an der Konsole "mount" aufrufen und die jeweiligen Parameter vergleichen. Es hängt letztlich davon ab, ob und was in der /etc/fstab drinsteht, aber bei mir sieht der Unterschied wie folgt aus:
mount per KDE: /dev/sr1 on /media/IX04 type iso9660 (ro,nosuid,nodev,noatime,uid=500,utf8)
"mount /dev/sr1 /media/cd" ohne fstab-Eintrag: /dev/sr1 on /media/cd type iso9660 (ro)
Daraus kann man schon leicht erkennen, dass die Rechte auf das Laufwerk von der Mount-Methode abhängen. Nachdem die meisten nfs-Installationen mit root_squash arbeiten, wird z.B. ein CD-mount, der root gehört, mitunter nicht per nfs verwendbar sein. Oder die UIDs sind inkonsistent. Bei einem Server würde ich das Mounten per Desktop deaktivieren und stattdessen "automount" benutzen. Alternativ befasst man sich mit der Konfiguration von hal. Außerdem sollte man den nfs-Export davon abhängig machen, dass der Mount erfolgreich war.
BTW: Eine Ursache für erfolglose umount-Versuche kann KDE sein. Das hat gelegentlich die Eigenart, ein Fenster zu schließen, ohne den Lock aufs Verzeichnis freizugeben. Man findet dann meist irgendwelche kio-Prozesse im "ps axf", deren gewaltsames Ende auch den Lock wieder freigibt.
Was bei mir nie wirklich stabil funktionierte: Wenn am "Server" parallel zum nfs-Service mit Schreibwerkzeugen gearbeitet wird, also cdrecord, k3b, usw..
-- Gruß, Tobias.
Per KDE mounte ich nix freiwillig - immo eher Zwangsweise, da das exportieren vom Server nicht 100%ig klappt - aber im "Normalfall" ist der Server ohne Userlogin (höchstens via SSH-Konsole) aber alle NFS -Verzeichnisse die vom Server (cpu2) exportiert werden (sollen), muss ich auf cpu1 manuell mounten/umounten Einträge zu dem ganzen in der jeweilligen fstab, Original Yast-Einträge: cpu2: /dev/cdram /media/cdram subfs noauto,fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0 cpu1: cpu2.linuxcobra.lan:/media/cdram /home/jmarco/HD/cpu2:cdr nfs defaults 0 0 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Marco Jäger schrieb:
Am Montag 21 Juli 2008 um 11:31:29 schrieb Tobias Crefeld:
On Mon, 21 Jul 2008 06:40:41 +0200 Marco Jäger
wrote:
Ich habe am Haupt-PC "nur" ein CDR eingebaut (also kein Brenner), dafür aber in meinem Neben-PC. Dieses würde ich gerne komplett via NFS an meinen Hauptrechner einbinden, aber das ganze klappt nur bedingt. Ohne Dir in allen Details folgen zu können, ein paar Hinweise:
Bei NFS-Problemen sollte man immer parallel (!) eine Konsole vom nfs-Server mit "tail -F /var/log/messages" mitlaufen lassen. nfs ist eigentlich sehr auskunftsfreudig und insbesondere "permission"-Probleme kann man so viel einfacher eingrenzen.
Anmerkung : cpu2 (NFS-Server) ist immer nebenbei via ssh-Konsole "griffbereit" ;) # << kommentarzeichen für den nächsten "logbereich" - da ich am besten beide Konsolen, bzw Tätigkeiten zeitnah angebe
Versuch 1: NFS-Server frisch rebootet, kein User eingeloggt, CD eingelegt
sch... Sprachregelung Du meinest nun den NFS-Server ( der kann nicht booten )oder eher den U*X-Rechner
cpu2:~ # tail -F /var/log/messages Jul 21 13:04:53 cpu2 kernel: eth0: no IPv6 routers present Jul 21 13:04:53 cpu2 SuSEfirewall2: batch committing... Jul 21 13:04:53 cpu2 SuSEfirewall2: Firewall rules successfully set Jul 21 13:04:53 cpu2 kernel: bootsplash: status on console 0 changed to on Jul 21 13:04:54 cpu2 kernel: ra0: no IPv6 routers present Jul 21 13:06:18 cpu2 sshd[5254]: Accepted keyboard-interactive/pam for root from 192.168.2.21 port 28636 ssh2
# cpu1.root -> manueller mount (NFS ist ohne automount eingestellt) ?? wie jetzt NFS ohne automount ?
der NFS-Server (als Systemteilkomponente) kann nur einen definiertes Verzeichnisbaum zur Verfügung stellen (in dem Baum darf nicht weiter gemounted sein!)
cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram mount: cpu2.linuxcobra.lan:/media/cdram failed, reason given by server: Permission denied
weil: falscher User, noch nix exportiert ...
# tail auf ssh-konsole cpu2: Jul 21 13:06:18 cpu2 sshd[5254]: Accepted keyboard-interactive/pam for root from 192.168.2.21 port 28636 ssh2 Jul 21 13:08:13 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:900 for /media/cdram (/media/cdram)
mounten darf nicht jeder...
# mehr Infos kamen nicht
hmhh also auskunftsfreudig ? *hust* laut meinem "Verständnis" sagt auf cpu2 der rpc.mountd das die Anfrage ok geht - oder seh ich das falsch??? -warum bekommt also cpu1.root die verweigerung ? *kopfkratz*
sagt dir das Log dieses Systems.... /var/log/messages vermute ich
Versuch 2: auf CPU2 hab ich mich als User unter KDE eingeloggt, cd raus und wieder rein (KDE-Erkennung für CD-Medien staret (das nette fenster wo gefragt wird was man mit der CD machen will)), aber nichts !!! ausgewählt
# cpu1.root -> manueller mount cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram cpu1:~ #
# tail auf ssh-konsole cpu2:
als root ? alternativ: sudoers eingerichtet ?
Jul 21 13:21:37 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:983 for /media/cdram (/media/cdram) Jul 21 13:21:46 cpu2 hal-subfs-mount[5521]: SYMLINKS:: disk/by-id/ata-HL-DT-ST_CDRAM_GSA-H10N_2AFEB00ED410 disk/by-path/pci-0000:00:07.1-ide-1:0 cdram cdrom cd Jul 21 13:21:46 cpu2 hal-subfs-mount[5521]: MOUNT_POINT:: /media/cdram Jul 21 13:21:46 cpu2 hal-subfs-mount[5521]: MOUNTPOINT:: /media/cdram Jul 21 13:21:46 cpu2 hal-subfs-mount[5521]: Collected mount options and Called(0) /bin/mount -t subfs -o fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=iso8859-15 /dev/hdc "/media/cdram" Jul 21 13:21:46 cpu2 kernel: ISO 9660 Extensions: Microsoft Joliet Level 1
Jul 21 13:21:46 cpu2 udevd[1927]: get_netlink_msg: no ACTION in payload found, skip event 'mount' Jul 21 13:21:46 cpu2 kernel: ISO 9660 Extensions: IEEE_P1282 Jul 21 13:21:49 cpu2 udevd[1927]: get_netlink_msg: no ACTION in payload found, skip event 'umount' Jul 21 13:21:49 cpu2 kernel: ISO 9660 Extensions: Microsoft Joliet Level 1 Jul 21 13:21:49 cpu2 udevd[1927]: get_netlink_msg: no ACTION in payload found, skip event 'mount' Jul 21 13:21:49 cpu2 kernel: ISO 9660 Extensions: IEEE_P1282 Jul 21 13:21:52 cpu2 udevd[1927]: get_netlink_msg: no ACTION in payload found, skip event 'umount'
# Inhaltsverzeichnis der CD ist kurzzeitig lesbar - wenn man via konqueror dort einen reload macht / eine Datei öffnet : Datei/Verzeichnis nicht gefunden Manchmal dauert die Zeitspanne bis die CD "zumacht" etwa 2-3 min , in dieser zeit kann man dann Dateien von der CD abrufen - sobald ma naber eine Pause länger wie 5 Min hat -> 100% stille
ach ja... mach eine (wie auch immer) Terminalsession einfach so -> mount ...und es kommt eine Liste alle gemounteten Devices ( da sollte dein CD/DVD bei sein) spätestens dann ein -> rcnfsserver restart -> dann setht das in der exportierten Liste drin
danach kommt, sebst wenn man die CD wechselt, nur eine verweigerung beim erneuten mount
# cpu1.root cpu1:~ # umount cpu2.linuxcobra.lan:/media/dvdram cpu1:~ # mount cpu2.linuxcobra.lan:/media/dvdram mount: cpu2.linuxcobra.lan:/media/dvdram failed, reason given by server: Permission denied
dieses mount -Kommando braucht root Rechte ( root sein oder über sudoers zuteilen) dann aber: sudo mount -> eintippen...
cpu1:~ #
# tail auf ssh-konsole cpu2: Jul 21 13:21:52 cpu2 udevd[1927]: get_netlink_msg: no ACTION in payload found, skip event 'umount' Jul 21 13:25:45 cpu2 rpc.mountd: authenticated unmount request from cpu1.linuxcobra.lan:607 for /media/dvdram (/media/dvdram) Jul 21 13:25:47 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:611 for /media/dvdram (/media/dvdram)
Also das einzige was richtung "Auskunft" gehen könnte, wäre der Teil wenn der NFS-Server die CD exportiert hat und das LW kommt zur Ruhe - beim großen Rest... hmhh nichts an weiterführenden Infos :((
Um die Unterschiede zwischen "mount an der Konsole" und "mounten per Desktop" festzustellen, solltest Du nach dem jeweiligen mounting an der Konsole "mount" aufrufen und die jeweiligen Parameter vergleichen. Es hängt letztlich davon ab, ob und was in der /etc/fstab drinsteht, aber bei mir sieht der Unterschied wie folgt aus:
wenn oben geht dann auf dem Zielsystem im Terminalfenster mount -t nfs cpu2:/mountname /mountziel wenn das auch geht, dann erst miot diesem ganzen Grafikzeugs anfangen!!! du kriegst eben im Terminalfenster eine ganze Menge von Meldungen mehr angezeigt...
mount per KDE: /dev/sr1 on /media/IX04 type iso9660 (ro,nosuid,nodev,noatime,uid=500,utf8)
"mount /dev/sr1 /media/cd" ohne fstab-Eintrag: /dev/sr1 on /media/cd type iso9660 (ro)
Daraus kann man schon leicht erkennen, dass die Rechte auf das Laufwerk von der Mount-Methode abhängen. Nachdem die meisten nfs-Installationen mit root_squash arbeiten, wird z.B. ein CD-mount, der root gehört, mitunter nicht per nfs verwendbar sein. Oder die UIDs sind inkonsistent. Bei einem Server würde ich das Mounten per Desktop deaktivieren und stattdessen "automount" benutzen. Alternativ befasst man sich mit der Konfiguration von hal. Außerdem sollte man den nfs-Export davon abhängig machen, dass der Mount erfolgreich war.
BTW: Eine Ursache für erfolglose umount-Versuche kann KDE sein. Das hat gelegentlich die Eigenart, ein Fenster zu schließen, ohne den Lock aufs Verzeichnis freizugeben. Man findet dann meist irgendwelche kio-Prozesse im "ps axf", deren gewaltsames Ende auch den Lock wieder freigibt.
aller andere Kram ... gut gedacht, aber ..in der fstab mounten setzt zwingend voraus, dass es mountbat (vorhanden) ist. das Handicap -> es finden keine weiteren Versuche statt, wenn es schiefgegangen ist. Wenn das so erst mal geht, kann man schauen wegen Schreiben (richtige Rechte dem richtigen User geben usw.)... und wozu in der fstab beim Systemstart ????? ich mach sowas immer Userbezogen in der ~/.profile Datei. -> siehe U*X/Linux Startverhalten... evtl kann man das schon ind die /etc/profile (einbmal für alles) schieben...aber ich möchte sicher sein, dass der Rest gelaufen ist Gruss Fred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Donnerstag 24 Juli 2008 um 15:34:10 schrieb Fred Ockert:
Marco Jäger schrieb:
sch... Sprachregelung Du meinest nun den NFS-Server ( der kann nicht booten )oder eher den U*X-Rechner
:D stimmt - bei manchen Sachen kanns leicht verwirrend werden Gemeint war : PC, auf dem der Server rennt, also cpu2, bekam kommando reboot
?? wie jetzt NFS ohne automount ?
joa - Die NFS Daten benötige ich nicht immer, und manchmal ist auch nur cpu1 am laufen, oder aber cpu2 läuft, aber ich benötige die Daten aktuell nicht. von daher ist "mount on demand" in meinen Augen das sinnigste
der NFS-Server (als Systemteilkomponente) kann nur einen definiertes Verzeichnisbaum zur Verfügung stellen (in dem Baum darf nicht weiter gemounted sein!)
;) ich weiß - mountpoints sind "nur" cpu2:/home, cpu2:/root (also dessen home) cpu2:/hdd (backup-Platte für wichtige daten)
cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram mount: cpu2.linuxcobra.lan:/media/cdram failed, reason given by server: Permission denied
weil: falscher User, noch nix exportiert ...
soweit ich NFS verstehe, brauch NFS keinen User um ein verzeichnis zu exportieren zumindest geht das bei den normalen HD's ohne einen eingeloggten User.
# tail auf ssh-konsole cpu2: Jul 21 13:06:18 cpu2 sshd[5254]: Accepted keyboard-interactive/pam for root from 192.168.2.21 port 28636 ssh2 Jul 21 13:08:13 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:900 for /media/cdram (/media/cdram)
mounten darf nicht jeder...
da der mountbefehl von cpu1 via root kam .... wenn der nicht darf, dann garantiert auch kein normaler user, oder ? zudem: normale HD's von cpu2 gehen ja ohne probleme zu mounten !!
# mehr Infos kamen nicht
hmhh also auskunftsfreudig ? *hust* laut meinem "Verständnis" sagt auf cpu2 der rpc.mountd das die Anfrage ok geht - oder seh ich das falsch??? -warum bekommt also cpu1.root die verweigerung ? *kopfkratz*
sagt dir das Log dieses Systems.... /var/log/messages vermute ich
richtig
Versuch 2: auf CPU2 hab ich mich als User unter KDE eingeloggt, cd raus und wieder rein (KDE-Erkennung für CD-Medien staret (das nette fenster wo gefragt wird was man mit der CD machen will)), aber nichts !!! ausgewählt
# cpu1.root -> manueller mount cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram cpu1:~ #
# tail auf ssh-konsole cpu2:
als root ? alternativ: sudoers eingerichtet ?
als root - sudoers habe ich noch nicht probiert - im normalfall benötige ich die ssh-verbindung als root nur alle 2 Monate mal.
[....]
ach ja... mach eine (wie auch immer) Terminalsession einfach so -> mount ...und es kommt eine Liste alle gemounteten Devices ( da sollte dein CD/cd bei sein) spätestens dann ein -> rcnfsserver restart -> dann setht das in der exportierten Liste drin
danach kommt, sebst wenn man die CD wechselt, nur eine verweigerung beim erneuten mount
# cpu1.root cpu1:~ # umount cpu2.linuxcobra.lan:/media/cdram cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram mount: cpu2.linuxcobra.lan:/media/cdram failed, reason given by server: Permission denied
dieses mount -Kommando braucht root Rechte ( root sein oder über sudoers zuteilen) dann aber: sudo mount -> eintippen...
Versuch cpu2 (NFS-Server) rebootet (alle Befehle via root, sowohl cpu1 als auch cpu2) ## SSH.1 (tail -F /var/log/messages) cpu2:~ # tail -F /var/log/messages Jul 26 08:58:32 cpu2 SuSEfirewall2: batch committing... Jul 26 08:58:32 cpu2 SuSEfirewall2: Firewall rules successfully set Jul 26 08:58:32 cpu2 kernel: bootsplash: status on console 0 changed to on Jul 26 08:58:33 cpu2 kernel: ra0: no IPv6 routers present Jul 26 09:00:43 cpu2 sshd[5280]: Accepted keyboard-interactive/pam for root from 192.168.2.21 port 9743 ssh2 Jul 26 09:00:52 cpu2 sshd[5303]: Accepted keyboard-interactive/pam for root from 192.168.2.21 port 9755 ssh2 # CD eingelegt Jul 26 09:02:42 cpu2 hal-subfs-mount[5330]: SYMLINKS:: disk/by-id/ata-HL-DT-ST_CDRAM_GSA-H10N_2AFEB00ED410 disk/by-path/pci-0000:00:07.1-ide-1:0 cdram cdrom cd Jul 26 09:02:42 cpu2 hal-subfs-mount[5330]: MOUNT_POINT:: /media/cdram Jul 26 09:02:42 cpu2 hal-subfs-mount[5330]: MOUNTPOINT:: /media/cdram Jul 26 09:02:42 cpu2 kernel: subfs 0.9 Jul 26 09:02:42 cpu2 hal-subfs-mount[5330]: Collected mount options and Called(0) /bin/mount -t subfs -o fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=iso8859-15 /dev/hdc "/media/cdram" Jul 26 09:02:42 cpu2 kernel: ISO 9660 Extensions: Microsoft Joliet Level 1 Jul 26 09:02:42 cpu2 udevd[1924]: get_netlink_msg: no ACTION in payload found, skip event 'mount' Jul 26 09:02:42 cpu2 kernel: ISO 9660 Extensions: IEEE_P1282 Jul 26 09:02:45 cpu2 udevd[1924]: get_netlink_msg: no ACTION in payload found, skip event 'umount' ## SSH.2 cpu2:~ # mount /dev/hda1 on / type ext2 (rw,acl,user_xattr) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) tmpfs on /dev/shm type tmpfs (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/hda3 on /home type ext2 (rw,acl,user_xattr) usbfs on /proc/bus/usb type usbfs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) /dev/hdc on /media/cdram type subfs (ro,nosuid,nodev,fs=cdfss,procuid,iocharset=iso8859-15) cpu2:~ # ** Ok die CD ist per Automount anwesend - wie es sein sollte ## cpu1 (Root) cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram mount: cpu2.linuxcobra.lan:/media/cdram failed, reason given by server: Permission denied cpu1:~ # ## SSH.1 (tail -F /var/log/messages) Jul 26 09:02:45 cpu2 udevd[1924]: get_netlink_msg: no ACTION in payload found, skip event 'umount' Jul 26 09:08:17 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:848 for /media/cdram (/media/cdram) ## SSH.2 cpu2:~ # rcnfsserver restart Shutting down kernel based NFS server done Starting kernel based NFS server done cpu2:~ # ## SSH.1 (tail -F /var/log/messages) Jul 26 09:08:17 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:848 for /media/cdram (/media/cdram) Jul 26 09:09:22 cpu2 kernel: nfsd: last server has exited Jul 26 09:09:22 cpu2 kernel: nfsd: unexporting all filesystems Jul 26 09:09:22 cpu2 rpc.mountd: Caught signal 15, un-registering and exiting. Jul 26 09:09:22 cpu2 kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory Jul 26 09:09:22 cpu2 kernel: NFSD: recovery directory /var/lib/nfs/v4recovery doesn't exist Jul 26 09:09:22 cpu2 kernel: NFSD: starting 90-second grace period ## cpu1 (Root) cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram mount: cpu2.linuxcobra.lan:/media/cdram failed, reason given by server: Permission denied cpu1:~ # ## SSH.1 (tail -F /var/log/messages) Jul 26 09:09:22 cpu2 kernel: NFSD: starting 90-second grace period Jul 26 09:10:57 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:853 for /media/cdram (/media/cdram) ** keine wirklichen Fehlerangaben - versuch mit "normalem" Verzeichnis: cpu1:~ # mount cpu2.linuxcobra.lan:/home/jmarco cpu1:~ # ** klappte tadellos - wie erwartet ## SSH.1 (tail -F /var/log/messages) Jul 26 09:10:57 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:853 for /media/cdram (/media/cdram) Jul 26 09:14:13 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:866 for /home/jmarco (/home/jmarco) ** also soweit ich das sehe: von seiten des NFS-Servers müsste alles ok gehen ?¿? -> die meldungen für CD und das home sind identisch - nur beim wechselmedium "zickt" nfs dennoch :((((( [...]
mount -t nfs cpu2:/mountname /mountziel wenn das auch geht, dann erst miot diesem ganzen Grafikzeugs anfangen!!! du kriegst eben im Terminalfenster eine ganze Menge von Meldungen mehr angezeigt...
[....] Glaub da wurde ich etwas falsch verstanden :D alle "normalen" verzeichnisse kann ich ohne probleme vom NFS-Server auf cpu1 mounten - nur das CD weigert sich zu 100%, solange auf cpu2 (NFS-Server) kde nicht läuft - trotz automount des laufwerks Und selbst wenn cpu2.kde nun die cd "mountet", habe ich ein Zeitfenster von ca 30 Sec - 1 Min um die cd auf cpu1 zu importieren und eine datei zu öffnen - danach stellt sich der NFS-Server "quer" und die CD ist für cpu1 unerrreichbar geworden. Nur wenn ich neue Zugriffe auf die CD (datei öffnen, verzeichnis auf der cd wechseln oder neu einlesen) innerhalb diesem Zeitfenster mache, bleibt die verbindung stabil. -> irgendetwas stimmt also devinitiv nicht - und das die NFS-Verzeichnisse in der fstab liegen, dürfte da keine rolle spielen meines wissens. Gruß Marco -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Marco, es kann sein, dass ich damit voellig danebenliege, aber das erinnert mich ein bisschen an meine Versuche, unter 10.1 einen USB-Scanner an einem anderen Rechner ueber ssh anzusprechen.
## SSH.2
cpu2:~ # mount /dev/hda1 on / type ext2 (rw,acl,user_xattr) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) tmpfs on /dev/shm type tmpfs (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/hda3 on /home type ext2 (rw,acl,user_xattr) usbfs on /proc/bus/usb type usbfs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) /dev/hdc on /media/cdram type subfs (ro,nosuid,nodev,fs=cdfss,procuid,iocharset=iso8859-15) cpu2:~ #
** Ok die CD ist per Automount anwesend - wie es sein sollte
## cpu1 (Root)
cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram mount: cpu2.linuxcobra.lan:/media/cdram failed, reason given by server: Permission denied
Das war bei dem Scanner genauso: Man konnte ihn nur ansprechen, wenn man lokal (nicht ueber ssh) angemeldet war. Die Loesung habe ich damals in der Beschreibung http://de.opensuse.org/SDB:Scanner_einrichten_ab_SUSE_LINUX_9.2 gefunden -- die bezieht sich zwar auf 9.2, aber vielleicht trifft das ja immer noch auf Deinen Fall zu. Die Rechte, die PAM beim Einloggen vergibt, wurden (werden?) in den folgenden Dateien festgelegt: * Fuer Login via Textconsole in /etc/pam.d/login * Fuer Login via XDM/KDM in /etc/pam.d/xdm und /etc/pam.d/xdm-np * Optional fuer Login via ssh in /etc/pam.d/sshd Vielleicht ist da voreingestellt, dass nur lokal angemeldete Benutzer Zugriff haben.
Glaub da wurde ich etwas falsch verstanden :D alle "normalen" verzeichnisse kann ich ohne probleme vom NFS-Server auf cpu1 mounten - nur das CD weigert sich zu 100%, solange auf cpu2 (NFS-Server) kde nicht läuft - trotz automount des laufwerks Und selbst wenn cpu2.kde nun die cd "mountet", habe ich ein Zeitfenster von ca 30 Sec - 1 Min um die cd auf cpu1 zu importieren und eine datei zu öffnen - danach stellt sich der NFS-Server "quer" und die CD ist für cpu1 unerrreichbar geworden.
Das koennte etwas mit dem resmgr zu tun haben. Aber ich habe mich damit schon zu lange nicht mehr beschaeftigt, um das so diagnostizieren zu koennen. Viel Glueck, Kurt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Marco Jäger schrieb:
Am Donnerstag 24 Juli 2008 um 15:34:10 schrieb Fred Ockert:
Marco Jäger schrieb:
sch... Sprachregelung Du meinest nun den NFS-Server ( der kann nicht booten )oder eher den U*X-Rechner
:D stimmt - bei manchen Sachen kanns leicht verwirrend werden Gemeint war : PC, auf dem der Server rennt, also cpu2, bekam kommando reboot
?? wie jetzt NFS ohne automount ?
joa - Die NFS Daten benötige ich nicht immer, und manchmal ist auch nur cpu1 am laufen, oder aber cpu2 läuft, aber ich benötige die Daten aktuell nicht. von daher ist "mount on demand" in meinen Augen das sinnigste
der NFS-Server (als Systemteilkomponente) kann nur einen definiertes Verzeichnisbaum zur Verfügung stellen (in dem Baum darf nicht weiter gemounted sein!)
;) ich weiß - mountpoints sind "nur" cpu2:/home, cpu2:/root (also dessen home) cpu2:/hdd (backup-Platte für wichtige daten)
cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram mount: cpu2.linuxcobra.lan:/media/cdram failed, reason given by server: Permission denied
weil: falscher User, noch nix exportiert ...
soweit ich NFS verstehe, brauch NFS keinen User um ein verzeichnis zu exportieren zumindest geht das bei den normalen HD's ohne einen eingeloggten User.
doch.... du musst schon irgendwo definieren, wer das lesen soll... ( -> root_squash)
# tail auf ssh-konsole cpu2: Jul 21 13:06:18 cpu2 sshd[5254]: Accepted keyboard-interactive/pam for root from 192.168.2.21 port 28636 ssh2 Jul 21 13:08:13 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:900 for /media/cdram (/media/cdram)
mounten darf nicht jeder...
da der mountbefehl von cpu1 via root kam .... wenn der nicht darf, dann garantiert auch kein normaler user, oder ? zudem: normale HD's von cpu2 gehen ja ohne probleme zu mounten !!
na ja Harddisks vollständig mounten ?? so a la mount /dev/dsik1 /iregndwohin ?
# mehr Infos kamen nicht
hmhh also auskunftsfreudig ? *hust* laut meinem "Verständnis" sagt auf cpu2 der rpc.mountd das die Anfrage ok geht - oder seh ich das falsch??? -warum bekommt also cpu1.root die verweigerung ? *kopfkratz*
sagt dir das Log dieses Systems.... /var/log/messages vermute ich
richtig
Versuch 2: auf CPU2 hab ich mich als User unter KDE eingeloggt, cd raus und wieder rein (KDE-Erkennung für CD-Medien staret (das nette fenster wo gefragt wird was man mit der CD machen will)), aber nichts !!! ausgewählt
# cpu1.root -> manueller mount cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram cpu1:~ #
# tail auf ssh-konsole cpu2:
als root ? alternativ: sudoers eingerichtet ?
als root - sudoers habe ich noch nicht probiert - im normalfall benötige ich die ssh-verbindung als root nur alle 2 Monate mal.
[....]
was hat ssh mit sudoers zu tun? zum anderen -> einfach mount ...tss... na gut, vielleicht hatte ich immer das Problem der Wahl! in meinem Hinterkopf steht immer noch "... immer das Dateisystem mit angeben.." das erspart ab und an mal Ärgerleins und Wundern.
ach ja... mach eine (wie auch immer) Terminalsession einfach so -> mount ...und es kommt eine Liste alle gemounteten Devices ( da sollte dein CD/cd bei sein) spätestens dann ein -> rcnfsserver restart -> dann setht das in der exportierten Liste drin
übrigens -> wie sieht die Eportliste aus ? für NFS ...
danach kommt, sebst wenn man die CD wechselt, nur eine verweigerung beim erneuten mount
# cpu1.root cpu1:~ # umount cpu2.linuxcobra.lan:/media/cdram cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram mount: cpu2.linuxcobra.lan:/media/cdram failed, reason given by server: Permission denied
dieses mount -Kommando braucht root Rechte ( root sein oder über sudoers zuteilen) dann aber: sudo mount -> eintippen...
Versuch cpu2 (NFS-Server) rebootet (alle Befehle via root, sowohl cpu1 als auch cpu2)
## SSH.1 (tail -F /var/log/messages) cpu2:~ # tail -F /var/log/messages Jul 26 08:58:32 cpu2 SuSEfirewall2: batch committing... Jul 26 08:58:32 cpu2 SuSEfirewall2: Firewall rules successfully set Jul 26 08:58:32 cpu2 kernel: bootsplash: status on console 0 changed to on Jul 26 08:58:33 cpu2 kernel: ra0: no IPv6 routers present Jul 26 09:00:43 cpu2 sshd[5280]: Accepted keyboard-interactive/pam for root from 192.168.2.21 port 9743 ssh2 Jul 26 09:00:52 cpu2 sshd[5303]: Accepted keyboard-interactive/pam for root from 192.168.2.21 port 9755 ssh2
# CD eingelegt
Jul 26 09:02:42 cpu2 hal-subfs-mount[5330]: SYMLINKS:: disk/by-id/ata-HL-DT-ST_CDRAM_GSA-H10N_2AFEB00ED410 disk/by-path/pci-0000:00:07.1-ide-1:0 cdram cdrom cd Jul 26 09:02:42 cpu2 hal-subfs-mount[5330]: MOUNT_POINT:: /media/cdram Jul 26 09:02:42 cpu2 hal-subfs-mount[5330]: MOUNTPOINT:: /media/cdram Jul 26 09:02:42 cpu2 kernel: subfs 0.9 Jul 26 09:02:42 cpu2 hal-subfs-mount[5330]: Collected mount options and Called(0) /bin/mount -t subfs -o fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=iso8859-15 /dev/hdc "/media/cdram" Jul 26 09:02:42 cpu2 kernel: ISO 9660 Extensions: Microsoft Joliet Level 1 Jul 26 09:02:42 cpu2 udevd[1924]: get_netlink_msg: no ACTION in payload found, skip event 'mount' Jul 26 09:02:42 cpu2 kernel: ISO 9660 Extensions: IEEE_P1282 Jul 26 09:02:45 cpu2 udevd[1924]: get_netlink_msg: no ACTION in payload found, skip event 'umount'
## SSH.2
cpu2:~ # mount /dev/hda1 on / type ext2 (rw,acl,user_xattr) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) tmpfs on /dev/shm type tmpfs (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/hda3 on /home type ext2 (rw,acl,user_xattr) usbfs on /proc/bus/usb type usbfs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) /dev/hdc on /media/cdram type subfs (ro,nosuid,nodev,fs=cdfss,procuid,iocharset=iso8859-15) cpu2:~ #
** Ok die CD ist per Automount anwesend - wie es sein sollte
hier wäre eine neugieriges Nachschauen dran ls -Al /media/cdram von wegen -> wem "gehört" das...
## cpu1 (Root)
cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram mount: cpu2.linuxcobra.lan:/media/cdram failed, reason given by server: Permission denied cpu1:~ #
## SSH.1 (tail -F /var/log/messages)
Jul 26 09:02:45 cpu2 udevd[1924]: get_netlink_msg: no ACTION in payload found, skip event 'umount' Jul 26 09:08:17 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:848 for /media/cdram (/media/cdram)
## SSH.2
cpu2:~ # rcnfsserver restart Shutting down kernel based NFS server done Starting kernel based NFS server done cpu2:~ #
## SSH.1 (tail -F /var/log/messages)
Jul 26 09:08:17 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:848 for /media/cdram (/media/cdram) Jul 26 09:09:22 cpu2 kernel: nfsd: last server has exited Jul 26 09:09:22 cpu2 kernel: nfsd: unexporting all filesystems
hat er scheinbar nicht exportiert...
Jul 26 09:09:22 cpu2 rpc.mountd: Caught signal 15, un-registering and exiting. Jul 26 09:09:22 cpu2 kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory Jul 26 09:09:22 cpu2 kernel: NFSD: recovery directory /var/lib/nfs/v4recovery doesn't exist Jul 26 09:09:22 cpu2 kernel: NFSD: starting 90-second grace period
## cpu1 (Root)
cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram mount: cpu2.linuxcobra.lan:/media/cdram failed, reason given by server: Permission denied cpu1:~ #
entweder du darfst nicht ... oder gibt es nicht...
## SSH.1 (tail -F /var/log/messages)
Jul 26 09:09:22 cpu2 kernel: NFSD: starting 90-second grace period Jul 26 09:10:57 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:853 for /media/cdram (/media/cdram)
** keine wirklichen Fehlerangaben - versuch mit "normalem" Verzeichnis: cpu1:~ # mount cpu2.linuxcobra.lan:/home/jmarco cpu1:~ #
vermutlich exportiert +Rechte (= User) passen...
** klappte tadellos - wie erwartet
## SSH.1 (tail -F /var/log/messages)
Jul 26 09:10:57 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:853 for /media/cdram (/media/cdram) Jul 26 09:14:13 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:866 for /home/jmarco (/home/jmarco)
** also soweit ich das sehe: von seiten des NFS-Servers müsste alles ok gehen ?¿? -> die meldungen für CD und das home sind identisch - nur beim wechselmedium "zickt" nfs dennoch :(((((
[...]
hm... da gab es NFS-Testtools...wo man schauen kann, wer (Server) was exportiert hatte...
mount -t nfs cpu2:/mountname /mountziel wenn das auch geht, dann erst miot diesem ganzen Grafikzeugs anfangen!!! du kriegst eben im Terminalfenster eine ganze Menge von Meldungen mehr angezeigt...
[....]
Glaub da wurde ich etwas falsch verstanden :D alle "normalen" verzeichnisse kann ich ohne probleme vom NFS-Server auf cpu1 mounten - nur das CD weigert sich zu 100%, solange auf cpu2 (NFS-Server) kde nicht läuft - trotz automount des laufwerks Und selbst wenn cpu2.kde nun die cd "mountet", habe ich ein Zeitfenster von ca 30 Sec - 1 Min um die cd auf cpu1 zu importieren und eine datei zu öffnen - danach stellt sich der NFS-Server "quer" und die CD ist für cpu1 unerrreichbar geworden. Nur wenn ich neue Zugriffe auf die CD (datei öffnen, verzeichnis auf der cd wechseln oder neu einlesen) innerhalb diesem Zeitfenster mache, bleibt die verbindung stabil. -> irgendetwas stimmt also devinitiv nicht - und das die NFS-Verzeichnisse in der fstab liegen, dürfte da keine rolle spielen meines wissens.
also ..was hat KDE mit mounten zu tun ? ...wobei - ich habe keine Ahnung,, was du da von KDE machen lässt eigentlich hat der Automounter nix mit KDE zu tun ... und geht auch im Textmode
Gruß Marco
kann aber sein, dass ich zu gewohnheitsmässig denke - alles sollte immer gehen und nicht von irgendwelchen Applikationen abhängig sein ! Also egal ob KDE Gnome oder XFCE oder Fvwm2...entweder er tut immer ..oder "..es läuft ein Rad im Dreck..." Gruss Fred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sonntag 27 Juli 2008 um 10:07:36 schrieb Fred Ockert: [...]
doch.... du musst schon irgendwo definieren, wer das lesen soll... ( -> root_squash)
hmh ok - nur da ja das lokale lesen der CD's ja ohne Probleme sogar für einen User geht (und auch ab und zu das bruzzeln einer Silberscheibe), dachte ich das das ja dann völlig normal exportiert werden kann. und dazu habe ich die gleichen Rechte genommen wie für die "normalen" Exports - da diese ja schon fehlerfrei liefen, als der Brenner dazukam cpu2:~ # cat /etc/exports / cpu1.linuxcobra.lan(rw,no_root_squash,sync) /home/jpetra/ cpu1.linuxcobra.lan(rw,no_root_squash,sync) /home/jmarco/ cpu1.linuxcobra.lan(rw,no_root_squash,sync) /media/cdram/ cpu1.linuxcobra.lan(rw,no_root_squash,sync) cpu2:~ # und das nicht ganz ohne Hintergedanken - no_root_squash = root hat in dem NFS-Verzeichnis dieselben rechte wie der lokale root - bei root_squah wird er zu "Nobody" = nicht gerade ideal, wenn man zb an einem config-file schrauben muss/will
na ja Harddisks vollständig mounten ?? so a la mount /dev/dsik1 /iregndwohin ?
Nicht ganz - in cpu2 "schlummern" 3xIDE und der Brenner Aufbau: 1. Platte Bootpart + Swappart (wird nix exportiert) 2.platte : Linux-root (also das /) (wird exportiert) 3.Platte : /home (da wird der user exportiert - siehe oben) und was wohin importiert werden soll, habe ich in der fstab von cpu1 definiert. cpu1:~ # cat /etc/fstab [....] cpu2.linuxcobra.lan:/home/jmarco /home/jmarco/HD/cpu2:jmarco nfs defaults 0 0 cpu2.linuxcobra.lan:/home/jpetra /home/jmarco/HD/cpu2:jpetra nfs defaults 0 0 cpu2.linuxcobra.lan:/media/cdram /home/jmarco/HD/cpu2:cdr nfs defaults 0 0 cpu2.linuxcobra.lan:/ /root/cpu2:System nfs defaults 0 0
was hat ssh mit sudoers zu tun?
auf cpu2 arbeite ich seltenst direkt - 95% mache ich durch diverse remote-zugriffe - sei es krdc für kde-steuerung oder per ssh terminal und eine config-datei ändern ? via NFS-Zugriff
zum anderen -> einfach mount ...tss... na gut, vielleicht hatte ich immer das Problem der Wahl! in meinem Hinterkopf steht immer noch "... immer das Dateisystem mit angeben.." das erspart ab und an mal Ärgerleins und Wundern.
nur: wenn man mount "nur" sagt "verzeichnis xy einbinden" guggt dieser befehl nach, ob dieses verzeichnis in der /etc/fstab ist - wenn ja wird es automatisch an das zielverzeichnis verbunden - mit den Parameterangaben von fstab - erspart einen Userfehler wenn man zb einen parameter vergisst oder sich beim zielverzeichnis vertippt
übrigens -> wie sieht die Eportliste aus ? für NFS ... hab ich da oben bereits gepostet
[...]
hier wäre eine neugieriges Nachschauen dran ls -Al /media/cdram von wegen -> wem "gehört" das... cpu2:~ # ls -Al /media/cdram insgesamt 14 dr-xr-xr-x 1 root root 2048 2007-08-05 12:24 . drwxr-xr-x 6 root root 4096 2008-07-26 09:02 .. dr-xr-xr-x 1 root root 2048 2007-08-05 12:24 Texte dr-xr-xr-x 1 root root 2048 2007-08-05 12:24 gif dr-xr-xr-x 1 root root 2048 2007-08-05 12:24 jpg dr-xr-xr-x 1 root root 2048 2007-08-05 12:24 s.Bilder cpu2:~ #
Wie auf jedem "Wechselmedium" das ich kenne - die einträge sind root zugeordnet [...]
hat er scheinbar nicht exportiert...
ja - nur ist die frage nach dem Warum ja der knackpunkt - theoretisch müsste der export klappen - da die "festen" exports ja keine Probleme machen - nur die dämliche Silberscheibe [...]
entweder du darfst nicht ... oder gibt es nicht... das dürfen müsste gehen - laut meinem verständniss des ganzen ist eine CD ja auch nicht so viel anders als zb /home/user und geben tut das ganze ja - sonst würde es ja auch nicht gehen, wenn kde gestartet ist und das ganze beeinflusst (wenn das "gehen" in dem fall ja auch nicht wirklich 100%ig ist)
vermutlich exportiert +Rechte (= User) passen...
s.o. : alle Rechte sind identisch gesetzt
hm... da gab es NFS-Testtools...wo man schauen kann, wer (Server) was exportiert hatte...
hmhh mal sehen ob Onkel Google da was brauchbares ausspuckt :D - die angaben von /var/log/messages sind da leider unbrauchbar :(
also ..was hat KDE mit mounten zu tun ? ...wobei - ich habe keine Ahnung,, was du da von KDE machen lässt eigentlich hat der Automounter nix mit KDE zu tun ... und geht auch im Textmode
der Brenner steht ja auf automount - generell nur habe ich halt einen unterschied festgestellt, ob nun KDE läuft und die CD "erkennt" oder nicht ohne KDE geht garnix, mit KDE gehts teilweise (timeout?) und mich verwundert ja dieses "Verhalten" von NFS ebenso - da ja NFS mit KDE eigendlich garnix zu tun hat
kann aber sein, dass ich zu gewohnheitsmässig denke - alles sollte immer gehen und nicht von irgendwelchen Applikationen abhängig sein ! Also egal ob KDE Gnome oder XFCE oder Fvwm2...entweder er tut immer ..oder "..es läuft ein Rad im Dreck..."
:D ich sehe das ja genauso - nur ist Google bei dieser "Fehlerbeschreibung" nicht sehr hilfreich - irgendetwas ist auf cpu2 noch falsch - aber laut google und etwa 80 besuchten seiten zur fehlersuche müsste alles klappen - sogar wenn auf cpu2 niemand eingeloggt ist. Und irgendwann kommt der Zeitpunkt, wo man dann nicht mehr wirklich weiterweiß, weil alles stimmen müsste (Aktuell komm ich mir vor als wenn ich der einzigste user bin und war, der per NFS was importieren will und der Brenner als einzigstes zicken macht dabei, ohne das eine Meldung kommt die bei der Fehlermeldung weiterhelfen könnte) Gruß & einen schönen Sonntag Marco -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Marco Jäger schrieb:
Am Sonntag 27 Juli 2008 um 10:07:36 schrieb Fred Ockert:
[...]
doch.... du musst schon irgendwo definieren, wer das lesen soll... ( -> root_squash)
hmh ok - nur da ja das lokale lesen der CD's ja ohne Probleme sogar für einen User geht (und auch ab und zu das bruzzeln einer Silberscheibe), dachte ich das das ja dann völlig normal exportiert werden kann. und dazu habe ich die gleichen Rechte genommen wie für die "normalen" Exports - da diese ja schon fehlerfrei liefen, als der Brenner dazukam
cpu2:~ # cat /etc/exports / cpu1.linuxcobra.lan(rw,no_root_squash,sync) /home/jpetra/ cpu1.linuxcobra.lan(rw,no_root_squash,sync) /home/jmarco/ cpu1.linuxcobra.lan(rw,no_root_squash,sync) /media/cdram/ cpu1.linuxcobra.lan(rw,no_root_squash,sync) cpu2:~ #
das CD/DVD-ROm kann man als nobody laufen lassen (hat den Vorteil, dass nobody überall die gleiche User-ID hat)
und das nicht ganz ohne Hintergedanken - no_root_squash = root hat in dem NFS-Verzeichnis dieselben rechte wie der lokale root - bei root_squah wird er zu "Nobody" = nicht gerade ideal, wenn man zb an einem config-file schrauben muss/will
na ja Harddisks vollständig mounten ?? so a la mount /dev/dsik1 /iregndwohin ?
Nicht ganz - in cpu2 "schlummern" 3xIDE und der Brenner
Aufbau: 1. Platte Bootpart + Swappart (wird nix exportiert) 2.platte : Linux-root (also das /) (wird exportiert) 3.Platte : /home (da wird der user exportiert - siehe oben)
funktionier eigentlich gut, wenn alle User auf allen Maschinen IMMER die gleiche UID haben... :-( ... wenn nicht -> böse Falle
und was wohin importiert werden soll, habe ich in der fstab von cpu1 definiert.
cpu1:~ # cat /etc/fstab [....] cpu2.linuxcobra.lan:/home/jmarco /home/jmarco/HD/cpu2:jmarco nfs defaults 0 0 cpu2.linuxcobra.lan:/home/jpetra /home/jmarco/HD/cpu2:jpetra nfs defaults 0 0 cpu2.linuxcobra.lan:/media/cdram /home/jmarco/HD/cpu2:cdr nfs defaults 0 0 cpu2.linuxcobra.lan:/ /root/cpu2:System nfs defaults 0 0
was hat ssh mit sudoers zu tun?
auf cpu2 arbeite ich seltenst direkt - 95% mache ich durch diverse remote-zugriffe - sei es krdc für kde-steuerung oder per ssh terminal und eine config-datei ändern ? via NFS-Zugriff
oha .. trau ich mich nicht... config-Files per NFS zu ändern... nicht alle config-Files gehören immer root ...
zum anderen -> einfach mount ...tss... na gut, vielleicht hatte ich immer das Problem der Wahl! in meinem Hinterkopf steht immer noch "... immer das Dateisystem mit angeben.." das erspart ab und an mal Ärgerleins und Wundern.
nur: wenn man mount "nur" sagt "verzeichnis xy einbinden" guggt dieser befehl nach, ob dieses verzeichnis in der /etc/fstab ist - wenn ja wird es automatisch an das zielverzeichnis verbunden - mit den Parameterangaben von fstab - erspart einen Userfehler wenn man zb einen parameter vergisst oder sich beim zielverzeichnis vertippt
übrigens -> wie sieht die Eportliste aus ? für NFS ... hab ich da oben bereits gepostet
[...]
hier wäre eine neugieriges Nachschauen dran ls -Al /media/cdram von wegen -> wem "gehört" das... cpu2:~ # ls -Al /media/cdram insgesamt 14 dr-xr-xr-x 1 root root 2048 2007-08-05 12:24 . drwxr-xr-x 6 root root 4096 2008-07-26 09:02 .. dr-xr-xr-x 1 root root 2048 2007-08-05 12:24 Texte dr-xr-xr-x 1 root root 2048 2007-08-05 12:24 gif dr-xr-xr-x 1 root root 2048 2007-08-05 12:24 jpg dr-xr-xr-x 1 root root 2048 2007-08-05 12:24 s.Bilder cpu2:~ #
Wie auf jedem "Wechselmedium" das ich kenne - die einträge sind root zugeordnet
auch das eigentlich exportierte /media/cdraom also ls -Al /media -> schauen
[...]
hat er scheinbar nicht exportiert...
ja - nur ist die frage nach dem Warum ja der knackpunkt - theoretisch müsste der export klappen - da die "festen" exports ja keine Probleme machen - nur die dämliche Silberscheibe
Erfahrung .. er exportiert, was er kennt ... jedem automount muesste ein nfsserver-restart/reload ? kommen...
[...]
entweder du darfst nicht ... oder gibt es nicht... das dürfen müsste gehen - laut meinem verständniss des ganzen ist eine CD ja auch nicht so viel anders als zb /home/user und geben tut das ganze ja - sonst würde es ja auch nicht gehen, wenn kde gestartet ist und das ganze beeinflusst (wenn das "gehen" in dem fall ja auch nicht wirklich 100%ig ist)
vermutlich exportiert +Rechte (= User) passen...
s.o. : alle Rechte sind identisch gesetzt
hm... da gab es NFS-Testtools...wo man schauen kann, wer (Server) was exportiert hatte...
hmhh mal sehen ob Onkel Google da was brauchbares ausspuckt :D - die angaben von /var/log/messages sind da leider unbrauchbar :(
was meint unbrauchbar ?.. auch wenn du nicht auf Anhieb eine Lösung hast, meckert er doch sehr sehr oft richtig...man muss fehlende Verbindungen dann im Kopf hinzufügen
also ..was hat KDE mit mounten zu tun ? ...wobei - ich habe keine Ahnung,, was du da von KDE machen lässt eigentlich hat der Automounter nix mit KDE zu tun ... und geht auch im Textmode
der Brenner steht ja auf automount - generell nur habe ich halt einen unterschied festgestellt, ob nun KDE läuft und die CD "erkennt" oder nicht ohne KDE geht garnix, mit KDE gehts teilweise (timeout?)
ohne KDE (?) .. also es gibt doch automount !... wozu ballert überhaupt auf einem unbenutzen Rechner ein KDE - "Speichervernichtung" ?? die Maschine sollte eh nur in den Runlevel 3 springen... X wird bei Bedarf gestartet... KDE (usw.) brauchts nicht...
und mich verwundert ja dieses "Verhalten" von NFS ebenso - da ja NFS mit KDE eigendlich garnix zu tun hat
kann aber sein, dass ich zu gewohnheitsmässig denke - alles sollte immer gehen und nicht von irgendwelchen Applikationen abhängig sein ! Also egal ob KDE Gnome oder XFCE oder Fvwm2...entweder er tut immer ..oder "..es läuft ein Rad im Dreck..."
:D ich sehe das ja genauso - nur ist Google bei dieser "Fehlerbeschreibung" nicht sehr hilfreich - irgendetwas ist auf cpu2 noch falsch - aber laut google und etwa 80 besuchten seiten zur fehlersuche müsste alles klappen - sogar wenn auf cpu2 niemand eingeloggt ist. Und irgendwann kommt der Zeitpunkt, wo man dann nicht mehr wirklich weiterweiß, weil alles stimmen müsste
na ja .. böse Erfahrung ...zum nur_lesen immmer auf nobody mappen (lassen) ... nfs kennt keine Wechselmedien .. also bei geändertem Mount ...immer alles von vorn. ( ggfs mit remount ..)
(Aktuell komm ich mir vor als wenn ich der einzigste user bin und war, der per NFS was importieren will und der Brenner als einzigstes zicken macht dabei, ohne das eine Meldung kommt die bei der Fehlermeldung weiterhelfen könnte)
viele tun es nicht....das mit den Abbrüchen ? hängt an sync/async ?
Gruß & einen schönen Sonntag Marco
geht es denn wenigstens immer im Handbetrieb ... mount - Export - Import ? Fred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Montag 28 Juli 2008 um 08:05:26 schrieb Fred Ockert:
das CD/DVD-ROm kann man als nobody laufen lassen (hat den Vorteil, dass nobody überall die gleiche User-ID hat)
hmh ok - wobei ich da etwas skeptisch bin, ob das dieses Verhalten erklärt :/ [...]
funktionier eigentlich gut, wenn alle User auf allen Maschinen IMMER die gleiche UID haben... :-( ... wenn nicht -> böse Falle
Also root und meiner einer = selbe UID - jpetra existiert nur auf der cpu2 - aber auch kein problem, da ich da sehr selten was machen muss - das letzte mal war vor ca 6 Monaten - und da war ein configfile, das jetzt auf ro ist, total kaputt :) [...]
oha .. trau ich mich nicht... config-Files per NFS zu ändern... nicht alle config-Files gehören immer root ...
nicht alle - aber doch der großteil - und so oft muss man an den "exoten" ja nicht rumbasteln - wenn dann so wie aktuell an /etc/exports & /etc/fstab :D [...]
auch das eigentlich exportierte /media/cdraom also ls -Al /media -> schauen
Dasselbe: root hat die Finger druff -> insgesamt 24 drwxr-xr-x 6 root root 4096 2008-07-27 12:09 . drwxr-xr-x 22 root root 4096 2008-07-27 13:50 .. drwxr-xr-x 2 root root 4096 2006-04-03 14:43 bmp_audio_cd drwxrwxrwx 1 root root 0 2008-07-27 12:09 cdram lrwxrwxrwx 1 root root 13 2008-07-27 12:09 Texte&Bilder -> /media/cdram drwxr-xr-x 2 root root 4096 2006-04-03 15:37 xmms_audio_cd [...]
was meint unbrauchbar ?.. auch wenn du nicht auf Anhieb eine Lösung hast, meckert er doch sehr sehr oft richtig...man muss fehlende Verbindungen dann im Kopf hinzufügen
na ja - unbrauchbar deshalb, weil zumindest aktuell dort noch keine Fehlermeldung erscheint - zumindest wenn man vergleicht was dort an meldung für CD bzw /home kommt -> bis auf den port identisch .... nur das das eine klappt, und das andere eben nicht
ohne KDE (?) .. also es gibt doch automount !... wozu ballert überhaupt auf einem unbenutzen Rechner ein KDE - "Speichervernichtung" ?? die Maschine sollte eh nur in den Runlevel 3 springen... X wird bei Bedarf gestartet... KDE (usw.) brauchts nicht...
Nicht ganz - RL 3 ist eh standardstart bei mir - nur will da auch eine bestimmte Userin ab und an an einen PC bzw ins Internet - und wenn man 2 Rechner hat ..... ich benutz den halt selber sehr selten :D ohne KDE / Userlogin lokal (nur root via SSH): CD wird automatisch gemountet - aber leider muss ich zum halbwegs exportieren zu können einen user auf cpu2 einloggen und kde starten - dann die CD neu erkennen lassen - dann habe ich zumindest ein paar Sekunden NFS-Zugriff von cpu1 aus
na ja .. böse Erfahrung ...zum nur_lesen immmer auf nobody mappen (lassen) ... nfs kennt keine Wechselmedien .. also bei geändertem Mount ...immer alles von vorn. ( ggfs mit remount ..)
ja das ist schon klar - aber immo haperts ja schon vorher ... bzw : kuriose beobachtung am rande: hab eben die CD entfernt - als leeres Laufwerk lässt sich der brenner problemlos importieren ... *gleich mal ne Großpackung Haarfärbemittel order - das ist ja zum graue Haare kriegen*
geht es denn wenigstens immer im Handbetrieb ... mount - Export - Import ? Fred
nein - nur wenn sich KDE "einmischt" wird die CD zumindest kurzzeitig exportiert - ansonsten hilft auch kein erneutes mount/umount bzw restart NFS-Server - alternativ: mit leerem Laufwerk geht der export auch - sogar stundenlang aktiv aber mit CD - entweder gar nicht - oder mit KDE für kurze Zeit. Pure Vermutung: automount setzt ja den link von /media/cdram auf /media/CD-Name -> ev die Ursache das NFS "streikt" ? -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Marco Jäger schrieb:
Am Montag 28 Juli 2008 um 08:05:26 schrieb Fred Ockert:
das CD/DVD-ROm kann man als nobody laufen lassen (hat den Vorteil, dass nobody überall die gleiche User-ID hat)
hmh ok - wobei ich da etwas skeptisch bin, ob das dieses Verhalten erklärt :/
nöö sicher nicht
[...]
funktionier eigentlich gut, wenn alle User auf allen Maschinen IMMER die gleiche UID haben... :-( ... wenn nicht -> böse Falle
Also root und meiner einer = selbe UID - jpetra existiert nur auf der cpu2 - aber auch kein problem, da ich da sehr selten was machen muss - das letzte mal war vor ca 6 Monaten - und da war ein configfile, das jetzt auf ro ist, total kaputt :)
[...]
oha .. trau ich mich nicht... config-Files per NFS zu ändern... nicht alle config-Files gehören immer root ...
nicht alle - aber doch der großteil - und so oft muss man an den "exoten" ja nicht rumbasteln - wenn dann so wie aktuell an /etc/exports & /etc/fstab :D [...]
auch das eigentlich exportierte /media/cdraom also ls -Al /media -> schauen
Dasselbe: root hat die Finger druff ->
insgesamt 24 drwxr-xr-x 6 root root 4096 2008-07-27 12:09 . drwxr-xr-x 22 root root 4096 2008-07-27 13:50 .. drwxr-xr-x 2 root root 4096 2006-04-03 14:43 bmp_audio_cd drwxrwxrwx 1 root root 0 2008-07-27 12:09 cdram lrwxrwxrwx 1 root root 13 2008-07-27 12:09 Texte&Bilder -> /media/cdram drwxr-xr-x 2 root root 4096 2006-04-03 15:37 xmms_audio_cd
[...]
was meint unbrauchbar ?.. auch wenn du nicht auf Anhieb eine Lösung hast, meckert er doch sehr sehr oft richtig...man muss fehlende Verbindungen dann im Kopf hinzufügen
na ja - unbrauchbar deshalb, weil zumindest aktuell dort noch keine Fehlermeldung erscheint - zumindest wenn man vergleicht was dort an meldung für CD bzw /home kommt -> bis auf den port identisch .... nur das das eine klappt, und das andere eben nicht
ohne KDE (?) .. also es gibt doch automount !... wozu ballert überhaupt auf einem unbenutzen Rechner ein KDE - "Speichervernichtung" ?? die Maschine sollte eh nur in den Runlevel 3 springen... X wird bei Bedarf gestartet... KDE (usw.) brauchts nicht...
Nicht ganz - RL 3 ist eh standardstart bei mir - nur will da auch eine bestimmte Userin ab und an an einen PC bzw ins Internet - und wenn man 2 Rechner hat ..... ich benutz den halt selber sehr selten :D ohne KDE / Userlogin lokal (nur root via SSH): CD wird automatisch gemountet - aber leider muss ich zum halbwegs exportieren zu können einen user auf cpu2 einloggen und kde starten - dann die CD neu erkennen lassen - dann habe ich zumindest ein paar Sekunden NFS-Zugriff von cpu1 aus
genau DAS verstehe ich nicht! der Automounter tut es im Hintergrund , musst nur dafür sorgen, dass der NFS-Server "nachlädt" ..also alles neu einliest und (neu) exportiert..
na ja .. böse Erfahrung ...zum nur_lesen immmer auf nobody mappen (lassen) ... nfs kennt keine Wechselmedien .. also bei geändertem Mount ...immer alles von vorn. ( ggfs mit remount ..)
ja das ist schon klar - aber immo haperts ja schon vorher ... bzw : kuriose beobachtung am rande:
hab eben die CD entfernt - als leeres Laufwerk lässt sich der brenner problemlos importieren ... *gleich mal ne Großpackung Haarfärbemittel order - das ist ja zum graue Haare kriegen*
wie jetzt Brenner importiert ? ein leeres Verzeichnis.. ehm ... showmount sagt dir was ?? oder meinetwegen dann showmount --directories ?
geht es denn wenigstens immer im Handbetrieb ... mount - Export - Import ? Fred nein - nur wenn sich KDE "einmischt" wird die CD zumindest kurzzeitig exportiert - ansonsten hilft auch kein erneutes mount/umount bzw restart NFS-Server - alternativ: mit leerem Laufwerk geht der export auch - sogar stundenlang aktiv
man ... hört sich an wie Parteipolitik ... NULL export oder so.. :-)
aber mit CD - entweder gar nicht - oder mit KDE für kurze Zeit.
Pure Vermutung: automount setzt ja den link von /media/cdram auf /media/CD-Name -> ev die Ursache das NFS "streikt" ?
nööö hannst auch auf ein Verezichnis umlenken! ...wenn du aber den Datenträgernamen verwenden willst ...jibbet et Aerger! ..woher soll der NFS-Server den zum Export kennen ? Und... was sagen deine auto.* Files dazu ? .... manchmal denke ich, du solltest ein Script schreiben.... ssh 'mit Hinterlegtem Key (also ohne Paswwort).. und im Scipt so etwa ssh -e " script" (war doch -e ..ausführen von Scripten ?) eject mount /dev/bla /blabla nfs-server restart oder eben 2 Scripte auswerfen + einlesen **************** ist eben keine Windoof-Kiste... da werden mounts bei Bedarf immer wieder neu aufgebaut... Fred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Montag 28 Juli 2008 um 13:01:10 schrieb Fred Ockert: [...]
Nicht ganz - RL 3 ist eh standardstart bei mir - nur will da auch eine bestimmte Userin ab und an an einen PC bzw ins Internet - und wenn man 2 Rechner hat ..... ich benutz den halt selber sehr selten :D ohne KDE / Userlogin lokal (nur root via SSH): CD wird automatisch gemountet - aber leider muss ich zum halbwegs exportieren zu können einen user auf cpu2 einloggen und kde starten - dann die CD neu erkennen lassen - dann habe ich zumindest ein paar Sekunden NFS-Zugriff von cpu1 aus
genau DAS verstehe ich nicht! der Automounter tut es im Hintergrund , musst nur dafür sorgen, dass der NFS-Server "nachlädt" ..also alles neu einliest und (neu) exportiert..
;) ich kapier diesen fehler auch nicht - irgendwie hab ich das gefühl, der nfs-server sagt ok export - und ein programm danach entscheidet per zufallszahl obs klappt oder nicht. [...]
wie jetzt Brenner importiert ? ein leeres Verzeichnis..
ehm ... showmount sagt dir was ??
oder meinetwegen dann showmount --directories ?
hier die Ausgabe: ** vor dem mount des NFS-Eintrages: cpu2:~ # showmount Hosts on cpu2: cpu2:~ # showmount --directories Directories on cpu2: cpu2:~ # ** nachdem cpu1 den NFS-Eintrag eingebunden hat cpu2:~ # showmount Hosts on cpu2: cpu1.linuxcobra.lan cpu2:~ # showmount --directories Directories on cpu2: /media/cdram cpu2:~ # ** Ausgabe dieses NFS-Witzes auf cpu1: cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram cpu1:~ # mount /dev/hdb1 on / type ext2 (rw,acl,user_xattr) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) udev on /dev type tmpfs (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/hda1 on /boot type ext2 (rw,acl,user_xattr) /dev/sda1 on /media/HD2 type ext3 (rw) securityfs on /sys/kernel/security type securityfs (rw) cpu2.linuxcobra.lan:/media/cdram on /home/jmarco/HD/cpu2:dvd type nfs (rw,addr=192.168.2.22) cpu1:~ # und das ganze via cpu2:~ # tail -F /var/log/messages cpu2:~ # tail -F /var/log/messages Jul 28 13:42:07 cpu2 SuSEfirewall2: batch committing... Jul 28 13:42:07 cpu2 kernel: ra0: no IPv6 routers present Jul 28 13:42:07 cpu2 SuSEfirewall2: Firewall rules successfully set Jul 28 13:42:07 cpu2 kernel: bootsplash: status on console 0 changed to on Jul 28 13:42:53 cpu2 sshd[5227]: Accepted keyboard-interactive/pam for root from 192.168.2.21 port 20157 ssh2 Jul 28 13:43:13 cpu2 sshd[5267]: Accepted keyboard-interactive/pam for root from 192.168.2.21 port 12494 ssh2 Jul 28 13:43:28 cpu2 mountd[5262]: NFS mount of /media/cdram attempted from 192.168.2.21 Jul 28 13:43:28 cpu2 mountd[5262]: /media/cdram has been mounted by 192.168.2.21 und nun mal das ganze nochmal mit einer CD als Vergleich: cpu1:~ # umount cpu2.linuxcobra.lan:/media/cdram cpu1:~ # -*- (CD eingelegt, ca 1 Min extra gewartet) cpu2:~ # rcnfsserver try-restart Shutting down NFS server done Starting NFS server done cpu2:~ # -*- cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram mount: cpu2.linuxcobra.lan:/media/cdram failed, reason given by server: Permission denied cpu1:~ # mount cpu2.linuxcobra.lan:/home/jmarco cpu1:~ # -*- Jul 28 13:43:28 cpu2 mountd[5262]: NFS mount of /media/cdram attempted from 192.168.2.21 Jul 28 13:43:28 cpu2 mountd[5262]: /media/cdram has been mounted by 192.168.2.21 Jul 28 13:45:34 cpu2 hal-subfs-mount[5315]: SYMLINKS:: disk/by-id/ata-HL-DT-ST_cdram_GSA-H10N_2AFEB00ED410 disk/by-path/pci-0000:00:07.1-ide-1:0 cdram cdrom cd Jul 28 13:45:34 cpu2 hal-subfs-mount[5315]: MOUNT_POINT:: /media/cdram Jul 28 13:45:34 cpu2 hal-subfs-mount[5315]: MOUNTPOINT:: /media/cdram Jul 28 13:45:34 cpu2 kernel: subfs 0.9 Jul 28 13:45:34 cpu2 hal-subfs-mount[5315]: Collected mount options and Called(0) /bin/mount -t subfs -o fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=iso8859-15 /dev/hdc "/media/cdram" Jul 28 13:45:34 cpu2 kernel: ISO 9660 Extensions: Microsoft Joliet Level 1 Jul 28 13:45:34 cpu2 udevd[1943]: get_netlink_msg: no ACTION in payload found, skip event 'mount' Jul 28 13:45:34 cpu2 kernel: ISO 9660 Extensions: IEEE_P1282 Jul 28 13:45:37 cpu2 udevd[1943]: get_netlink_msg: no ACTION in payload found, skip event 'umount' Jul 28 13:47:02 cpu2 mountd[5370]: NFS mount of /media/cdram attempted from 192.168.2.21 Jul 28 13:48:55 cpu2 mountd[5370]: NFS mount of /home/jmarco attempted from 192.168.2.21 Jul 28 13:48:55 cpu2 mountd[5370]: /home/jmarco has been mounted by 192.168.2.21 den einzigen unterschied von "normalem" HD-Verzeichnis und der CD : das das mounten erfolgreich war fehlt - aber das warum ebenso :((( nicht einmal das der NFS neu gestartet wurde, wird "vermerkt" *fluch* Anmerkung: das einzige was ich zu dem Thema nfs + helferprogrammen finden konnte war nfs-utils - und die waren ebenso schweigsam. [....]
man ... hört sich an wie Parteipolitik ... NULL export oder so.. :-)
hmh - Politik ? Neues aus Absurdistan ?
Pure Vermutung: automount setzt ja den link von /media/cdram auf /media/CD-Name -> ev die Ursache das NFS "streikt" ?
nööö hannst auch auf ein Verezichnis umlenken! ...wenn du aber den Datenträgernamen verwenden willst ...jibbet et Aerger! ..woher soll der NFS-Server den zum Export kennen ?
klar - war ja auch nur eine dumme Vermutung, da ja der NFS auf das eigendliche Verzeichnis zugreift - aber bei diesen Merkwürdigkeiten ? - aktuell die einzige erklärung wenn nfs das verzeichis ohne weiterverlinkung mag, und mit weiterverlinkung dann nicht mehr.
Und... was sagen deine auto.* Files dazu ? .... manchmal denke ich, du solltest ein Script schreiben....
ssh 'mit Hinterlegtem Key (also ohne Paswwort).. und im Scipt
so etwa
ssh -e " script"
(war doch -e ..ausführen von Scripten ?)
eject mount /dev/bla /blabla nfs-server restart
oder eben 2 Scripte auswerfen + einlesen
****************
ist eben keine Windoof-Kiste... da werden mounts bei Bedarf immer wieder neu aufgebaut...
Fred
*Versteck* auto.* ? Files - falls du da auf scripte anspielst : aktuell ist da noch keines geschrieben - bei den normalen verzeichnissen (also zb /home/user) brauchte ich dieses ja nicht - und solange ich das mit dem Scheibengriller nicht lauffähig habe, (er)spar ich mir da das hin und herscripten (wenn ich das ganze dann lauffähig bekommen sollte, ist ein Script ja schnell gebaut) :D Marco -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Montag 21 Juli 2008 schrieb Marco Jäger:
Hallo Ich habe am Haupt-PC "nur" ein CDR eingebaut (also kein Brenner), dafür aber in meinem Neben-PC. Dieses würde ich gerne komplett via NFS an meinen Hauptrechner einbinden, aber das ganze klappt nur bedingt.
Ein fertiges Kochrezept kann ich dir leider nicht geben, ich würde versuchen, das Automounten der CD von ivman machen zu lassen, ist in der Distribution enthalten. Dem müsste man auch beibringen können, mit exportfs das Dateisystem der CD zu veröffentlichen und beim Entfernen der CD auch wieder wegzunehmen. Wie sich das mit den Automount-Funktionen von KDE oder gnome verträgt, weiß ich nicht, die benutze ich nicht. (Und was das Automount überhaupt im Desktop Environment verloren hat, habe ich nie verstanden.) -- Viele Grüße ------------------------------------------------------------------------ Michael Behrens ________________________________________________________________________ PROSTEP AG, Dolivostraße 11, D-64293 Darmstadt HR: Amtsgericht Darmstadt, HRB 8383 Vorstand: Dr. Bernd Pätzold (Vorsitz), Reinhard Betz Aufsichtsrat: Dr. Heinz-Gerd Lehnhoff (Vorsitz) ________________________________________________________________________ -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Michael Behrens schrieb:
Am Montag 21 Juli 2008 schrieb Marco Jäger:
Hallo Ich habe am Haupt-PC "nur" ein CDR eingebaut (also kein Brenner), dafür aber in meinem Neben-PC. Dieses würde ich gerne komplett via NFS an meinen Hauptrechner einbinden, aber das ganze klappt nur bedingt.
Ein fertiges Kochrezept kann ich dir leider nicht geben, ich würde versuchen, das Automounten der CD von ivman machen zu lassen, ist in der Distribution enthalten. Dem müsste man auch beibringen können, mit exportfs das Dateisystem der CD zu veröffentlichen und beim Entfernen der CD auch wieder wegzunehmen.
Wie sich das mit den Automount-Funktionen von KDE oder gnome verträgt, weiß ich nicht, die benutze ich nicht. (Und was das Automount überhaupt im Desktop Environment verloren hat, habe ich nie verstanden.)
Es gab mal eine Webanwendung die einen Brenner im Netzwerk verfügbar machte. Ist aber schon lange her. Ggf. ist das ja ein Ansatz. Gruß www.comline.de Vorstand Stephan Schilling, Erwin Leonhardi Aufsichtsrat Dr. Franz Schoser (Vorsitzender) HR Dortmund B 14570 USt.-ID-Nr. DE 124727422 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (6)
-
curdy＠congster.de -
Fred Ockert -
Marco Jäger -
Michael Behrens -
Ralf Prengel -
Tobias Crefeld