Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #103474 > unrolled thread

Help: /home-Verzeichnisse auf NAS -> FAIL

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  Help: /home-Verzeichnisse auf NAS -> FAIL wolfgang sch <see@sig.nature> - 2019-05-19 06:31 +0000
    Re: Help: /home-Verzeichnisse auf NAS -> FAIL Ralph Aichinger <ra@pi.h5.or.at> - 2019-05-19 10:09 +0200
      Re: Help: /home-Verzeichnisse auf NAS -> FAIL wolfgang sch <see@sig.nature> - 2019-05-19 08:51 +0000
        Re: Help: /home-Verzeichnisse auf NAS -> FAIL Ralph Aichinger <ra@pi.h5.or.at> - 2019-05-19 11:12 +0200
          Re: Help: /home-Verzeichnisse auf NAS -> FAIL wolfgang sch <see@sig.nature> - 2019-05-19 09:54 +0000
            Re: Help: /home-Verzeichnisse auf NAS -> FAIL Ralph Aichinger <ra@pi.h5.or.at> - 2019-05-19 12:03 +0200
              Re: Help: /home-Verzeichnisse auf NAS -> FAIL wolfgang sch <see@sig.nature> - 2019-05-19 11:32 +0000
                Re: Help: /home-Verzeichnisse auf NAS -> FAIL Bernd Mayer <beam.bam.boom@knuut.de> - 2019-05-19 14:56 +0200
                  Re: Help: /home-Verzeichnisse auf NAS -> FAIL wolfgang sch <see@sig.nature> - 2019-05-19 14:48 +0000
                    Re: Help: /home-Verzeichnisse auf NAS -> FAIL Bernd Mayer <beam.bam.boom@knuut.de> - 2019-05-19 20:46 +0200
            Re: Help: /home-Verzeichnisse auf NAS -> FAIL Gregor Szaktilla <spam.sz@ktilla.de> - 2019-05-22 00:11 +0200
              Re: Help: /home-Verzeichnisse auf NAS -> FAIL wolfgang sch <see@sig.nature> - 2019-05-22 05:09 +0000
                Re: Help: /home-Verzeichnisse auf NAS -> FAIL Gregor Szaktilla <spam.sz@ktilla.de> - 2019-05-22 08:27 +0200
    Re: Help: /home-Verzeichnisse auf NAS -> FAIL Alexander Goetzenstein <alexander_goetzenstein@web.de> - 2019-05-20 12:29 +0200

#103474 — Help: /home-Verzeichnisse auf NAS -> FAIL

Hallo Welt,

es geht um den Rechner im Haushalt von Bekannten, dort läuft bisher ein 
von einem Verwandten vor Jahren installiertes und administriertes 
openSUSE 13.1 mit KDE. Der Verwandte ist vor einiger Zeit verstorben, 
Backup und Administration finden seitdem nicht mehr statt weil die 
Benutzer keine Ahnung davon haben. Ich soll helfen.

Ich selbst benutze und administriere Linux privat und im Job als File- 
und Webserver, habe aber von Desktop-Themen null Ahnung und das auch 
deutlich gesagt. Um automatisierte Backups zu ermöglichen und Austausch 
mit anderen Rechnern zu ermöglichen, habe ich vorgeschlagen die 
User-Dateien auf einen NAS-Server zu verschieben.

In meiner Naivität(?) habe ich nun dieses Werk gestern umgesetzt, indem 
sämtliche Verzeichnise unter /home auf den NAS verschoben, dann unter 
/mnt/servername gemountet, und die alten User-Verzeichnisse als 
Symlinks dorthin wiederhergestellt wurden.

Beim nächsten Boot fiel der KDE auf die Nase, er kam nur bis zum 
"openSUSE" Gecko-Logo und hing da. Keine Login-Auswahl wie bisher 
üblich. Die Recherche ergab dann, dass der NAS nicht automatisch 
gemountet wurde, was mir die wahrscheinlichste Ursache erschien warum 
KDE sich aufhängt: Er sieht die Konfigurationsdateien in den 
/home-Verzeichnissen ja nicht.

Warum der NAS nicht gemountet wurde ist mir im Moment egal, weil andere 
Probleme entstanden: Nach dem Scheitern wollte ich zunächst den 
Vorzustand wiederherstellen damit sie weiter am Rechner arbeiten 
können, habe also den Mountpoint und die Symlinks wieder entfernt, und 
die originalen /home- Verzeichnisse aus dem Backup wiederhergestellt. 
Nach meinem Verständnis hatte ich also die Maschine exakt in den 
Vorzustand vor den Experimenten zurückverstetzt. Der KDE hing beim 
nächsten Boot aber wieder an der gleichen Stelle. WTF?

Statt jetzt diese alte, von einer nicht mehr befragbaren Person 
administrierte Kiste weiter künstlich zu beatmen, möchte ich lieber ein 
neueres OpenSUSE installieren. Der Plan, die /home-Verzeichnisse auf 
ein NAS zu verschieben, besteht aber weiterhin.

Jetzt meine Fragen an die Community, ehe ich wieder in die gleichen 
Hindernisse renne:

1. Gibt es irgendeinen grundsätzlichen Hinderungsgrund, die /home-
Directories von einem NAS zu mounten? (Banalitäten wie dass Eigentümer 
und Permissions verlorengehen sind bekannt und akzeptiert). Es geht nur 
um die Frage, ob es ein technisches Hindernis gibt.

2. Gleiche Frage für KDE: Gibt es irgendeinen grundsätzlichen 
Hinderungsgrund, KDE die User-Verzeichnisse von einem gemounteten NAS 
anzubieten?

3. Ist meine Vorgehensweise (NAS als cifs oder smbfs mounten, Symlinks 
setzen) grundsätzlich OK oder ist da was absolut Falsches dran?

4. Zusatzfrage zum Verständnis: Warum wurde der NAS nicht zur Bootzeit 
gemountet? Händisch ging es problemlos. Habe auch auf meinen privaten 
Maschinen bisher nie ein Problem damit gehabt: Wenn ein Samba-Share in 
der fstab steht und verfügbar ist, wird es zur Bootzeit eingehängt. Was 
anderes kenne ich gar nicht.

5. Zusatzfrage zum Verständnis: Was kann KDE zerschossen haben und wo 
kann ich den Fehler suchen?

Gruß & schönen Restsonntag!

-- 
Currently listening: https://www.youtube.com/watch?v=V5AztWseIdU

http://www.wschwanke.de/              http://www.fotos-aus-der-luft.de/

                usenet_20031215 (AT) wschwanke (DOT) de

[toc] | [next] | [standalone]

#103481

wolfgang sch <see@sig.nature> wrote:
> Warum der NAS nicht gemountet wurde ist mir im Moment egal, weil andere 
> Probleme entstanden: Nach dem Scheitern wollte ich zunächst den 
> Vorzustand wiederherstellen damit sie weiter am Rechner arbeiten 
> können, habe also den Mountpoint und die Symlinks wieder entfernt, und 
> die originalen /home- Verzeichnisse aus dem Backup wiederhergestellt. 

Dann war es vermutlich ein schlecht gemachtes Backup. Bei
alten Kisten fragwürdiger Herkunft und fragwürdigen Zustands
ist meisten ein bitgenauer Festplattenabzug sinnvoll. 

> Nach meinem Verständnis hatte ich also die Maschine exakt in den 
> Vorzustand vor den Experimenten zurückverstetzt. Der KDE hing beim 
> nächsten Boot aber wieder an der gleichen Stelle. WTF?

Wahrscheinlich hast du nicht wirklich in den Zustand davor restored.

> Statt jetzt diese alte, von einer nicht mehr befragbaren Person 
> administrierte Kiste weiter künstlich zu beatmen, möchte ich lieber ein 
> neueres OpenSUSE installieren. Der Plan, die /home-Verzeichnisse auf 
> ein NAS zu verschieben, besteht aber weiterhin.

Rein interessehalber: Warum? Das klingt für mich nach einem Szenario
für Desaster aller Art.

> 1. Gibt es irgendeinen grundsätzlichen Hinderungsgrund, die /home-
> Directories von einem NAS zu mounten? (Banalitäten wie dass Eigentümer 
> und Permissions verlorengehen sind bekannt und akzeptiert). Es geht nur 
> um die Frage, ob es ein technisches Hindernis gibt.

Viele: Die Init-Skripten müssen das Verzeichnis in der richtigen
Reihenfolge mounten, d.h. man benötigt für NFS-Mounts schon ein
funktionierendes Netzwerk, und kann erst nachher mounten.

> 2. Gleiche Frage für KDE: Gibt es irgendeinen grundsätzlichen 
> Hinderungsgrund, KDE die User-Verzeichnisse von einem gemounteten NAS 
> anzubieten?

Z.B. Permission-Probleme, Szenarien wenn das Netzwerk nicht verfügbar
ist.

> 3. Ist meine Vorgehensweise (NAS als cifs oder smbfs mounten, Symlinks 
> setzen) grundsätzlich OK oder ist da was absolut Falsches dran?

Grundsätzlich OK, ich halte sie bloß in der Praxis für extrem
fragil.

> 4. Zusatzfrage zum Verständnis: Warum wurde der NAS nicht zur Bootzeit 
> gemountet? Händisch ging es problemlos. Habe auch auf meinen privaten 
> Maschinen bisher nie ein Problem damit gehabt: Wenn ein Samba-Share in 
> der fstab steht und verfügbar ist, wird es zur Bootzeit eingehängt. Was 
> anderes kenne ich gar nicht.

Weil es zur Bootzeit u.U. noch kein Netzwerk gegeben hat, wie das
/home gemountet werden sollte.

> 5. Zusatzfrage zum Verständnis: Was kann KDE zerschossen haben und wo 
> kann ich den Fehler suchen?

Permission-Probleme? Unvollständig zurückgespielte Backups, z.B.
fehlende Verzeichnisse mit Punkt davor.

Funktioniert ein neu angelegter leerer Testaccount mit KDE?

/ralph
-- 
-----------------------------------------------------------------------------
                                                              https://aisg.at
                                                   ausserirdische sind gesund

[toc] | [prev] | [next] | [standalone]

#103488

Ralph Aichinger <ra@pi.h5.or.at> wrote in news:qbr30b$c7f$1@pi.h5.or.at:

>> habe also den Mountpoint und die Symlinks wieder entfernt, und 
>> die originalen /home- Verzeichnisse aus dem Backup wiederhergestellt. 
> 
> Dann war es vermutlich ein schlecht gemachtes Backup.

s.u.

> Bei alten Kisten fragwürdiger Herkunft und fragwürdigen Zustands
> ist meisten ein bitgenauer Festplattenabzug sinnvoll.

Das wäre dann ein physischer Abzug des gesamten OS, dass das nötig 
werden würde war vorab nicht abzusehen :).

> Wahrscheinlich hast du nicht wirklich in den Zustand davor restored.

Ich habe vorher als root alle Userverzeichnisse unter /home vollständig 
per tar auf ein externes Laufwerk archiviert und hinterher an der 
gleichen Stelle wieder ausgepackt. Das sollte doch nach Adam Riese alle 
User-Homes samt Unterverzeichnissen und Dateien incl. Dotfiles mit 
korrektem Owner und Permissions wiederherstellen. Abgesehen von der 
fstab habe ich im System sonst nichts geändert.

>> Der Plan, die /home-Verzeichnisse auf 
>> ein NAS zu verschieben, besteht aber weiterhin.
> 
> Rein interessehalber: Warum?

Aus den Gründen warum man sowas allgemein will:

1. Zugriff auf die gleichen Dokumente von verschiedenen Workstations 
aus (Im Haus befinden sich noch ein Dual Boot Laptop und ein Windows 
PC, die in einem zweiten Schritt ebenfalls die NAS einbinden sollen)

2. Zentralisiertes und automatisiertes Backup der relevanten Daten, was 
die NAS ja von Haus aus mitbringt. Eine externe USB-Platte ist für den 
Zweck vorhanden.

> Viele: Die Init-Skripten müssen das Verzeichnis in der richtigen
> Reihenfolge mounten, d.h. man benötigt für NFS-Mounts schon ein
> funktionierendes Netzwerk, und kann erst nachher mounten.

Klar, aber ich war davon ausgegangen dass das standardmäßig in der 
sinnvollen Reihenfolge geschieht. Genauso habe ich es bei mir immer 
erlebt. Andernfalls wäre es ja  unsinnig, dass man überhaupt Netzwerk-
Shares in die fstab schreiben kann.

> Z.B. Permission-Probleme, Szenarien wenn das Netzwerk nicht verfügbar
> ist.

Ich hab mir KDE wohl robuster vorgestellt als er ist.

Naiv wahr wahrscheinlich die Umlenkung des gesamten /home. Vielleicht 
sollte ich das lokal belassen und nur einen Ordner pro User von der NAS 
einbinden, und den Usern einbleuen dass sie nur dort Dokumente ablegen 
sollen.

Das Problem ist, sie arbeiten gewohnheitsmäßig auf dem Desktop. Das 
bedeutet, ihre wichtigen Dokumente befinden sich in den von KDE 
verwalteten Ordnern ~/Schreibtisch, ~/Musik, ~/Dokumente usw. Ich werd 
im nächsten Schritt mal experimentieren, ob man die umlenken kann. Wenn 
nicht, werd ich ihnen andere Arbeitsweisen angewöhnen :).

> Funktioniert ein neu angelegter leerer Testaccount mit KDE?

Das kann ich nicht mehr testen, danke erstmal für deine Antwort.

-- 
Currently listening: https://www.youtube.com/watch?v=V5AztWseIdU

http://www.wschwanke.de/              http://www.fotos-aus-der-luft.de/

                usenet_20031215 (AT) wschwanke (DOT) de

[toc] | [prev] | [next] | [standalone]

#103489

wolfgang sch <see@sig.nature> wrote:
>> Bei alten Kisten fragwürdiger Herkunft und fragwürdigen Zustands
>> ist meisten ein bitgenauer Festplattenabzug sinnvoll.
> 
> Das wäre dann ein physischer Abzug des gesamten OS, dass das nötig 
> werden würde war vorab nicht abzusehen :).

Du hast in deinem Vorposting den Rechner so beschrieben, als würdest
du der bestehenden Installation unbekannter Herkunft nicht ganz
trauen. Wenn ich auf sowas stoße, dann mach ich erstmal einen 
Abzug mit dd, soweit es irgendwie möglich ist. 

> Ich habe vorher als root alle Userverzeichnisse unter /home vollständig 
> per tar auf ein externes Laufwerk archiviert und hinterher an der 
> gleichen Stelle wieder ausgepackt. Das sollte doch nach Adam Riese alle 
> User-Homes samt Unterverzeichnissen und Dateien incl. Dotfiles mit 
> korrektem Owner und Permissions wiederherstellen. Abgesehen von der 
> fstab habe ich im System sonst nichts geändert.

Eventuell ist KDE noch beleidigt, weil beim Start ohne /home 
irgendwas kaputtgemacht wurde, z.B. in /var oder so?

> Aus den Gründen warum man sowas allgemein will:
> 
> 1. Zugriff auf die gleichen Dokumente von verschiedenen Workstations 
> aus (Im Haus befinden sich noch ein Dual Boot Laptop und ein Windows 
> PC, die in einem zweiten Schritt ebenfalls die NAS einbinden sollen)

Für 100 Mitarbeiter oder so kann man sowas überlegen. Bei drei 
Computern würd ich mir den Aufwand nicht antun. Das muß ja auch
gewartet werden. Jedes mal wenn das Netzwerk spinnt hast du damit
in Zukunft viel Spaß und einen vertanen Nachmittag. Jeder wie er will.

> 2. Zentralisiertes und automatisiertes Backup der relevanten Daten, was 
> die NAS ja von Haus aus mitbringt. Eine externe USB-Platte ist für den 
> Zweck vorhanden.

Zentrales Backup kann man auch ohne /home auf einem Fileserver lösen.

> Klar, aber ich war davon ausgegangen dass das standardmäßig in der 
> sinnvollen Reihenfolge geschieht. Genauso habe ich es bei mir immer 
> erlebt. Andernfalls wäre es ja  unsinnig, dass man überhaupt Netzwerk-
> Shares in die fstab schreiben kann.

Ich hab das noch nie so erlebt, daß das problemlos geht. Ich kenn das
bis jetzt nur mit manueller Nacharbeit und u.U. wackligen Timing-
Problemen (je nachdem was grade schneller da ist, gehts mal, mal nicht).
Zugegeben, nicht unter KDE sondern unter Gnome, wobei ich nicht glaube,
daß sich das in dem Punkt groß unterscheidet.

Was du auch bedenken mußt: In den 90er-Jahren des letzten Jahrhunderts
waren solche Setups noch gängig, heute verwenden nur mehr sehr sehr
wenige Leute sowas produktiv, d.h. sowas fällt auch viel leichter
Bit-Rot zum Opfer.

> Naiv wahr wahrscheinlich die Umlenkung des gesamten /home. Vielleicht 
> sollte ich das lokal belassen und nur einen Ordner pro User von der NAS 
> einbinden, und den Usern einbleuen dass sie nur dort Dokumente ablegen 
> sollen.
> 
> Das Problem ist, sie arbeiten gewohnheitsmäßig auf dem Desktop. Das 
> bedeutet, ihre wichtigen Dokumente befinden sich in den von KDE 
> verwalteten Ordnern ~/Schreibtisch, ~/Musik, ~/Dokumente usw. Ich werd 
> im nächsten Schritt mal experimentieren, ob man die umlenken kann. Wenn 
> nicht, werd ich ihnen andere Arbeitsweisen angewöhnen :).

Ich würde das nicht tun. YMMV. Ein derartiges Setup ist zwar aus
Admin-Sicht spannend, ich bin mir aber nicht sicher ob es die User
genügend zu würdigen wissen, als daß man sich die Komplexität antun
will. Vor allem wenn man nicht ständig dort sitzt. Stöpselt einer
das NAS aus, dann hast du vielleicht wieder einen halben Tag gut zu
tun. Willst du sowas langfristig haben, womöglich unbezahlt? Haben
die User deine Handynummer?

Verglichen damit: Wenn die Dateien auf einem Rechner sind, dann gehen
sie halt immer zu dem, und schicken sich notfalls was sie vermissen
per Mail aufs Notebook oder den dritten Rechner. So what? 
Die meisten User stört das nicht mal.

>> Funktioniert ein neu angelegter leerer Testaccount mit KDE?
> 
> Das kann ich nicht mehr testen, danke erstmal für deine Antwort.

Du solltest auch schauen was passiert wenn du auf die Konsole umschaltest
und dich auf der Konsole einloggst. Eventuell scheitert auch das schon,
dann brauchst du bei KDE nicht groß weitersuchen. Bzw. umgekehrt, dann
kannst du eventuell die scheiternde KDE-Session besser debuggen, indem
du dich mal auf der Konsole umschaust ob du was siehst was klemmt.

/ralph
-- 
-----------------------------------------------------------------------------
                                                              https://aisg.at
                                                   ausserirdische sind gesund

[toc] | [prev] | [next] | [standalone]

#103492

Ralph Aichinger <ra@pi.h5.or.at> wrote in news:qbr6m3$f97$1@pi.h5.or.at:

> Du hast in deinem Vorposting den Rechner so beschrieben, als würdest
> du der bestehenden Installation unbekannter Herkunft nicht ganz
> trauen.

Nicht in dem Sinne dass sie instabil sei, sondern dass ich nicht alles 
verstehe was warum wie eingerichtet ist.

> Wenn ich auf sowas stoße, dann mach ich erstmal einen 
> Abzug mit dd, soweit es irgendwie möglich ist. 

Ist auch ne Zeitfrage. Wenn man in einem fremden Haushalt ein paar 
Stunden lang was erledigen soll, wählt man den zeitsparendsten Weg: Das 
gesamte OS sichern dauern länger und ist auch ein Risiko, im Zweifel 
kann das eigentliche Betriebssystem ja auch per Neuinstallation 
wiederhergestellt werden. Die Userfiles nicht, deswegen werden 
vorrangig die gesichert.

> Eventuell ist KDE noch beleidigt, weil beim Start ohne /home 
> irgendwas kaputtgemacht wurde, z.B. in /var oder so?

Das ist genau auch meine Schlussfolgerung. Die Preisfrage lautet: Woran 
genau liegt es, wenn KDE "beleidigt" ist? Ich hab nicht den geringsten 
Ansatz wo ich suchen sollte, welcher Zustand normal und welcher falsch 
ist.

Wir haben aber inzwischen schon mehr oder weniger entschieden, das OS 
neu drüberzubügeln, insofern ist es jetzt nicht mehr sooo wichtig die 
Antwort zu finden. Falls das Gleiche wieder auftritt, wäre es aber 
hilfreich zu wissen.

>> 1. Zugriff auf die gleichen Dokumente von verschiedenen Workstations 
>> aus (Im Haus befinden sich noch ein Dual Boot Laptop und ein Windows 
>> PC, die in einem zweiten Schritt ebenfalls die NAS einbinden sollen)
> 
> Für 100 Mitarbeiter oder so kann man sowas überlegen. Bei drei 
> Computern würd ich mir den Aufwand nicht antun.

Das geht jetzt ins Philosophische :). Ich arbeite bei mir privat so und 
möchte es nicht mehr missen.

[samba share in fstab]

> Ich hab das noch nie so erlebt, daß das problemlos geht. Ich kenn das
> bis jetzt nur mit manueller Nacharbeit und u.U. wackligen Timing-
> Problemen (je nachdem was grade schneller da ist, gehts mal, mal nicht).

Aha? Gut vielleicht liegt da mein Fehler.

Ich hab auch nochmal auf meiner privaten Maschine nachgesehen, die 
ihrerseits ein NAS per fstab einbindet: Dort gibt es ein Startskript 
/etc/init.d/smbfs, das in der Sorgenkind-Maschine nicht vorhanden war. 
Vielleicht ist es das was man braucht?

> Was du auch bedenken mußt: In den 90er-Jahren des letzten Jahrhunderts
> waren solche Setups noch gängig, heute verwenden nur mehr sehr sehr
> wenige Leute sowas produktiv, d.h. sowas fällt auch viel leichter
> Bit-Rot zum Opfer.

Ich bin gern altmodisch, stört mich nicht. Wie linkt man denn heute 
mehrere Server zusammen, oder meinst du man macht das gar nicht mehr?

> Stöpselt einer
> das NAS aus, dann hast du vielleicht wieder einen halben Tag gut zu
> tun. Willst du sowas langfristig haben, womöglich unbezahlt? Haben
> die User deine Handynummer?

Natürlich will ich keinen chronisch instabilen Zustand.

Meine Erwartung ist ja dass das gar kein Schaden entsteht wenn da mal 
beim Boot ein Share fehlt. Dass die Maschine sich dann mutwillig in 
einen merkwürdigen Zustand versetzt hätte ich bei Windows noch 
verärgert hingenommen, aber bei einem Linux eigentlich ausgeschlossen. 
Dass die Realität nicht meiner Erwartung entspricht, überrascht mich 
jetzt etwas.

> Du solltest auch schauen was passiert wenn du auf die Konsole
> umschaltest und dich auf der Konsole einloggst. 

Das hat in allen Zuständen einwandfrei funktioniert, sowohl als die 
/home- Verzeichnisse über Samba eingebunden waren als auch nach der 
Wiederherstellung als lokale Verzeichnisse. Es ist nur der KDE der 
rumzickt.

-- 
Currently listening: https://www.youtube.com/watch?v=V5AztWseIdU

http://www.wschwanke.de/              http://www.fotos-aus-der-luft.de/

                usenet_20031215 (AT) wschwanke (DOT) de

[toc] | [prev] | [next] | [standalone]

#103493

wolfgang sch <see@sig.nature> wrote:
>> Eventuell ist KDE noch beleidigt, weil beim Start ohne /home 
>> irgendwas kaputtgemacht wurde, z.B. in /var oder so?
> 
> Das ist genau auch meine Schlussfolgerung. Die Preisfrage lautet: Woran 
> genau liegt es, wenn KDE "beleidigt" ist? Ich hab nicht den geringsten 
> Ansatz wo ich suchen sollte, welcher Zustand normal und welcher falsch 
> ist.

Schwer zu sagen. Logs lesen. Was immer sein kann ist ein Starten von
Prozessen mit den falschen Permissions, die dann z.B. als root Files
anlegen, die ihnen bei einem Lauf mit repariertem Setup nachher in
die Quere kommen. 

> Das geht jetzt ins Philosophische :). Ich arbeite bei mir privat so und 
> möchte es nicht mehr missen.

Ja, es geht eindeutig ins Philosophische. Ich sag auch nicht, daß 
so ein Setup "falsch" wäre, bloß ich würde es nicht mehr machen (heute).

> Ich hab auch nochmal auf meiner privaten Maschine nachgesehen, die 
> ihrerseits ein NAS per fstab einbindet: Dort gibt es ein Startskript 
> /etc/init.d/smbfs, das in der Sorgenkind-Maschine nicht vorhanden war. 
> Vielleicht ist es das was man braucht?

Ja, evenutell. Zumindest ist es eine Stelle an der man anfangen zu
suchen kann.

> Ich bin gern altmodisch, stört mich nicht. Wie linkt man denn heute 
> mehrere Server zusammen, oder meinst du man macht das gar nicht mehr?

Bei Servern alles kein Ding. Für mich hört sich dein Setup aber
nicht nach "3 Server greifen aufeinander zu" an, sondern nach einem
Desktop-Setup.  Unix am Desktop war nie wirklich populär, allenfalls
zu Zeiten von Character-Terminals wie dem vt220. Danach war das 
eher eine Nische für Unis und technischere Unternehmen, und auch da
sind dann mindestens 3 Sachen passiert:

* Remote Desktops auch über langsamere Leitungen (wie VNC)
* Notebooks
* Die Cloud bzw. Abwandern von Applikationen auf Webserver

Ein User-Verzeichnis auf einem Fileserver ist heute alleine
schon deswegen nicht mehr praktikabel, weil die meisten Leute
ihren Computer zusammenklappen und auch außer Haus betreiben wollen.

Auf einer VAX hat ein Homedirectory auf einem Fileserver Sinn
ergeben und Spaß gemacht, auf einem Notebook weniger. Wo sind
meine Dateien wenn ich dann im Zug fahre, und wie komme ich zu
ihnen?

> Meine Erwartung ist ja dass das gar kein Schaden entsteht wenn da mal 
> beim Boot ein Share fehlt. Dass die Maschine sich dann mutwillig in 
> einen merkwürdigen Zustand versetzt hätte ich bei Windows noch 
> verärgert hingenommen, aber bei einem Linux eigentlich ausgeschlossen. 

Die Maschine geht ja anscheinend, nur KDE hat scheinbar ein Problem.

> Das hat in allen Zuständen einwandfrei funktioniert, sowohl als die 
> /home- Verzeichnisse über Samba eingebunden waren als auch nach der 
> Wiederherstellung als lokale Verzeichnisse. Es ist nur der KDE der 
> rumzickt.

Vielleicht ist es nix großartiges. Was sagen die Logs, was passiert
genau?

/ralph
-- 
-----------------------------------------------------------------------------
                                                              https://aisg.at
                                                   ausserirdische sind gesund

[toc] | [prev] | [next] | [standalone]

#103495

Ralph Aichinger <ra@pi.h5.or.at> wrote in news:qbr9m9$hrg$1@pi.h5.or.at:

> Bei Servern alles kein Ding. Für mich hört sich dein Setup aber
> nicht nach "3 Server greifen aufeinander zu" an, sondern nach einem
> Desktop-Setup.

Ja

> Unix am Desktop war nie wirklich populär, allenfalls
> zu Zeiten von Character-Terminals wie dem vt220. Danach war das 
> eher eine Nische für Unis und technischere Unternehmen,

Der genannte Verwandte war wohl ein Linux-Purist und hat alle Leute in 
seinem Bekanntenkreis versucht dazu zu überzeugen, bei den betreffenden 
Leuten mit Erfolg. Dabei machen die nur Office und Fotos, haben keine 
Ahnung von der Shell, Dateien werden mit einem graphischen Filemanager 
bewegt wie in Windows. Ich hab deswegen mal nachgefragt, ob Windows 
nicht als Desktop mehr Sinn machen würde. Das ist aber ein Tabu. Es ist 
wohl auch ein religiöses Problem. :)

> Auf einer VAX hat ein Homedirectory auf einem Fileserver Sinn
> ergeben und Spaß gemacht, auf einem Notebook weniger. Wo sind
> meine Dateien wenn ich dann im Zug fahre, und wie komme ich zu
> ihnen?

Das ist bei denen kein Thema, das Notebook wird nicht auf Reisen 
mitgenommen sondern nur zu Hause benutzt. Danach hatte ich im Vorfeld 
extra mehrmals gefragt, sonst hätte ich ihnen die Zentralisierung der 
Nutzerdaten in der Form nicht empfohlen.

> Die Maschine geht ja anscheinend, nur KDE hat scheinbar ein Problem.

Ja

> Vielleicht ist es nix großartiges. Was sagen die Logs, was passiert
> genau?

Ich denke auch es ist vermutlich ne Kleinigkeit. Kann jetzt nicht mehr 
zugreifen, gestern hab ich in /var/log/messages außer dem 
fehlgeschlagenen mount des NAS-Shares nichts Bemerkenswertes 
festgestellt.

Der nächste Schritt wird vorauss sein, openSuse neu zu installieren. 
Fragt sich noch welche Version für ältere Hardware Sinn macht, es ist 
eine 64Bit CPU mit BIOS, 8 GB RAM, 2 Festplatten mit AFAIR je 1000 GB. 
Werde erstmal LEAP 15 versuchen, und falls das scheitert Fallback 13.2. 
Dann mit dem "leeren" OS zunächst einige Optionen der NAS-Einbindung 
testen, und die günstigste davon dann umsetzen. 

-- 
Currently listening: https://www.youtube.com/watch?v=V5AztWseIdU

http://www.wschwanke.de/              http://www.fotos-aus-der-luft.de/

                usenet_20031215 (AT) wschwanke (DOT) de

[toc] | [prev] | [next] | [standalone]

#103496

Am 19.05.19 um 13:32 schrieb wolfgang sch:
> 
> Der nächste Schritt wird vorauss sein, openSuse neu zu installieren.
> Fragt sich noch welche Version für ältere Hardware Sinn macht, es ist
> eine 64Bit CPU mit BIOS, 8 GB RAM, 2 Festplatten mit AFAIR je 1000 GB.
> Werde erstmal LEAP 15 versuchen, und falls das scheitert Fallback 13.2.
> Dann mit dem "leeren" OS zunächst einige Optionen der NAS-Einbindung
> testen, und die günstigste davon dann umsetzen.
> 

Hallo,

OpenSUSE 13.2 wird schon lange nicht mehr mit updates versorgt.

Der support wurde am 18. Januar 2017 eingestellt!

https://lists.opensuse.org/opensuse-security-announce/2017-01/msg00033.html

Eine "64Bit CPU mit BIOS" habe ich noch nicht gesehen, was ist das denn 
genau für eine CPU?


Bernd Mayer

[toc] | [prev] | [next] | [standalone]

#103500

Bernd Mayer <beam.bam.boom@knuut.de> wrote
in news:qbrjq5$jde$1@news2.open-news-network.org: 

> Eine "64Bit CPU mit BIOS" habe ich noch nicht gesehen, was ist das denn
> genau für eine CPU?

Ich formuliere neu:

Der Rechner enthält eine 64Bit CPU unbekannter Bauart und hat im 
übrigen kein UEFI, sondern noch ein BIOS. Das sind mE für die Wahl der 
Distribution relevante Randbedingungen.

-- 
Currently listening: https://www.youtube.com/watch?v=V5AztWseIdU

http://www.wschwanke.de/              http://www.fotos-aus-der-luft.de/

                usenet_20031215 (AT) wschwanke (DOT) de

[toc] | [prev] | [next] | [standalone]

#103506

Am 19.05.19 um 16:48 schrieb wolfgang sch:
> Bernd Mayer <beam.bam.boom@knuut.de> wrote
> in news:qbrjq5$jde$1@news2.open-news-network.org:
> 
>> Eine "64Bit CPU mit BIOS" habe ich noch nicht gesehen, was ist das denn
>> genau für eine CPU?
> 
> Ich formuliere neu:
> 
> Der Rechner enthält eine 64Bit CPU unbekannter Bauart und hat im
> übrigen kein UEFI, sondern noch ein BIOS. Das sind mE für die Wahl der
> Distribution relevante Randbedingungen.

Hallo,

ein aktuelles OpenSUSE kommt auch auf Systemen mit UEFI klar.

Details zur CPU wären für mich auch wichtig. Single, Dual oder Quad. 
Intel oder AMD. Sempron oder celeron?

lscpu, cpuid, cat /proc/cpuinfo
inxi -F


Bernd Mayer

[toc] | [prev] | [next] | [standalone]

#103529

wolfgang sch schrieb:
> ... Das
> gesamte OS sichern dauern länger und ist auch ein Risiko, ..
Worin zur Hölle besteht das Risiko einer Datensicherung mittels dd?!

Gruß

Gregor


-- 
Googeln verblödet.

[toc] | [prev] | [next] | [standalone]

#103530

Gregor Szaktilla <spam.sz@ktilla.de> wrote
in news:qc1t3b$hqe$1@news.albasani.net:

> wolfgang sch schrieb:
>> ... Das
>> gesamte OS sichern dauern länger und ist auch ein Risiko, ..
> Worin zur Hölle besteht das Risiko einer Datensicherung mittels dd?!

Das Risiko besteht mehr bei der Wiederherstellung, weil mir da die 
Erfahrung fehlt.

-- 
Currently listening: https://www.youtube.com/watch?v=V5AztWseIdU

http://www.wschwanke.de/              http://www.fotos-aus-der-luft.de/

                usenet_20031215 (AT) wschwanke (DOT) de

[toc] | [prev] | [next] | [standalone]

#103532

wolfgang sch schrieb:
> Gregor Szaktilla <spam.sz@ktilla.de> wrote
> in news:qc1t3b$hqe$1@news.albasani.net:
>> wolfgang sch schrieb:
>>> ... Das
>>> gesamte OS sichern dauern länger und ist auch ein Risiko, ..
>> Worin zur Hölle besteht das Risiko einer Datensicherung mittels dd?!
> Das Risiko besteht mehr bei der Wiederherstellung, weil mir da die 
> Erfahrung fehlt.

Dass man durch Fehler beim Zurückspielen eines Backups etwas zerschießen
kann, kann ich bestätigen. Aber deshalb erst gar keins zu machen ist ja
mal unglaublich dämlich.

Mach wenigstens jetzt eins.

Gruß

Gregor


-- 
Googeln verblödet.

[toc] | [prev] | [next] | [standalone]

#103520

Hallo,

Am 19.05.19 um 08:31 schrieb wolfgang sch:
> Um automatisierte Backups zu ermöglichen und Austausch 
> mit anderen Rechnern zu ermöglichen, habe ich vorgeschlagen die 
> User-Dateien auf einen NAS-Server zu verschieben.

läuft bei mir (ist sogar noch eine SuSE 12.2) auf meinem Server.


> In meiner Naivität(?) habe ich nun dieses Werk gestern umgesetzt, indem 
> sämtliche Verzeichnise unter /home auf den NAS verschoben, dann unter 
> /mnt/servername gemountet, und die alten User-Verzeichnisse als 
> Symlinks dorthin wiederhergestellt wurden.

Das habe ich anders gelöst: das NAS hat die Daten als iSCSI-Target
freigegeben, der Server holt sie sich entsprechend. Um Hakeligkeiten bei
Ausfall des NAS oder der Verbindung zu umgehen, habe ich das Target erst
einmal auf einen "neutralen" Mountpoint gebunden und im Nachgang mit

mount --rbind /srv/nas/home /home

das /home -Verzeichnis neu positioniert. So gehen auch keine
Rechteeinstellungen verloren. Da der Server normalerweise unangetastet
durchläuft, ist dieser notwendige manuelle Eingriff verschmerzbar.
Sicher kann man das auch noch automatisieren, aber da hat mich
angesichts eines geringen Aufwandes alle paar Jahre mal die Lust
verlassen, das näher zu untersuchen. Wenn Du das bei Clients brauchst,
die direkt auf das NAS zugreifen sollen, könntest Du einen passenden
Eintrag in die /etc/fstab schreiben, vielleicht in der Art
> /dev/disk/by-id/scsi-12345678901234567890-part1 /home	ext4	acl,user_xattr,nofail 1 2

oder vielleicht etwas in der Art
> /mnt/nas/home /home	none	bind	0 0



> 3. Ist meine Vorgehensweise (NAS als cifs oder smbfs mounten, Symlinks 
> setzen) grundsätzlich OK oder ist da was absolut Falsches dran?

Bei solchen Protokollen, zumal wenn es solche sind, die originär nicht
Unix oder Linux entspringen, sind Verluste eher die Regel als Ausnahme.
Daher setze ich in der Schichtenfolge so tief wie möglich an. So bin ich
auf iSCSI gekommen. Wie der Server das dann welchen Clients wie
weitergibt, ist davon dann ja vollkommen unabhängig.


> 4. Zusatzfrage zum Verständnis: Warum wurde der NAS nicht zur Bootzeit 
> gemountet? Händisch ging es problemlos.

Vermutlich waren zur Mountzeit noch nicht alle Netzwerkdienste
gestartet, oder so etwas in der Art. Das war der Punkt, bei dem ich bei
mir aufgehört hatte, weil der Aufwand den Erfolg nicht gerechtfertigt
hätte. Allerdings bin ich auch praktisch jederzeit vor Ort und habe
ausschließlichen Zugang zu Server und NAS. Wenn ich also irgendwann
einmal versterbe, stehen meine Nachfolger wohl vor einem ähnlichen
Problem wie Du... ;-)




-- 
Gruß
Alex

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web