PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Benutzerverwaltung im heterogenen LAN



kaptn
26.11.10, 14:47
Hallo,
nach langer, sehr langer Zeit kann ich mich wieder mit meinen Rechnern und meinem LAN beschäftigen. Prompt treten wieder Fragen auf. Aktuell bitte ich Euch um Hilfe bei folgender Problemstellung:

Ich betreibe in meinem LAN z.Zt. Desktoprechner unter SuSE 11.3, einen Windows 7 - Rechner, alle kabelgebunden, sowie eine wechselnde Anzakl mobiler Rechner mit verschiedenen Betriebssystemen über WLAN. Er SuSE 11.3 - Rechner fungiert als Server für NIS, NFS, CUPS. Die home-Verzeichnisse n werden auf dem Server gehalten und von dort per NFS an die Linuxnutzer übertragen. Diese melden sich auch über NIS an.

Und hier liegt das Problem: Solange alle Rechner mit SuSE 11.3 arbeiten, gibt es kaum Schwierigkeiten. Sobald aber ein Rechner z.B. Mandriva o.a. nutzt, gibt es Kollisionen mit den Einstellungsdateien. Da ich keine Linuxdistribution kenne, die Einstellungsdateien und Daten sauber trennt, hilft es auch nichts, mit Links zu arbeiten. Zudem weiß ich nicht, wie ich verhindere, dass ein mobiler Rechner dann, wenn er nicht am Netz hängt, startet und dabei automatisch netzabhängige Anfragen auf lokale Verzeichnisse umleitet bzw. garnicht stellt (wie NTP z.B.).

Wißt Ihr da eine Lösung?

Gruß, kaptn

oziris
26.11.10, 20:08
Man könnte evtl. Rechnernamen oder MAC-Adressen benutzen, um einige Konfigurationsdateien im Heimatverzeichnis auszutauschen, aber das ist vermutlich zu viel Aufwand und funktioniert nur, wenn jeder Nutzer max. ein Mal gleichzeitig angemeldet ist.

Weiterhin könnte man einige Xclient-Applikationen auf dem Server starten und mit hohen Performance- und evtl. auch Sicherheitsschwächen (Wenn nicht über SSH getunnelt wird, was die Performance noch gravierender schwächt) über das X11-Protokoll auf den Xservern der Clients darstellen (dadurch würde gewährleistet, dass es die selbe Version eines bestimmten Programms ist und es gibt keine Versionskonflikte bei den Configs). Dies sollte gerade auch deshalb gehen, weil die Home-Verzeichnisse über NFS vom Server kommen und somit auch auf den Server mit den Xclients die selben Benutzer-Daten verfügbar sind, wie auf den Clients, abgesehen von Wechseldatenträgern und Verzeichnissen, wie /tmp usw., deren Inhalte aber i.d.R. auch nach /home/... kopiert werden können, wenn sie auch für den remote laufenden Xclient zur Verfügung stehen sollen.

kaptn
27.11.10, 12:13
Hallo, danke für Deine Hinweise.


Man könnte evtl. Rechnernamen oder MAC-Adressen benutzen, um einige Konfigurationsdateien im Heimatverzeichnis auszutauschen, aber das ist vermutlich zu viel Aufwand und funktioniert nur, wenn jeder Nutzer max. ein Mal gleichzeitig angemeldet ist.

Ein interessanter Ansatz. Den Aufwand halte ich nicht unbedingt für zu groß, zumal er nur einmal betrieben wird. Allerdings stehe ich dann wieder vor dem Problem, dass ich nicht mit Sicherheit weiß, welche Dateien betroffen sind, bzw. wozu gehören. Das halte ich für ein grundsätzliches Problem bei Linux.


Weiterhin könnte man einige Xclient-Applikationen auf dem Server starten und mit hohen Performance- und evtl. auch Sicherheitsschwächen (Wenn nicht über SSH getunnelt wird, was die Performance noch gravierender schwächt) über das X11-Protokoll auf den Xservern der Clients darstellen (dadurch würde gewährleistet, dass es die selbe Version eines bestimmten Programms ist und es gibt keine Versionskonflikte bei den Configs). Dies sollte gerade auch deshalb gehen, weil die Home-Verzeichnisse über NFS vom Server kommen und somit auch auf den Server mit den Xclients die selben Benutzer-Daten verfügbar sind, wie auf den Clients, abgesehen von Wechseldatenträgern und Verzeichnissen, wie /tmp usw., deren Inhalte aber i.d.R. auch nach /home/... kopiert werden können, wenn sie auch für den remote laufenden Xclient zur Verfügung stehen sollen.
Damit habe ich bereits experimentiert. Es führte regelmäßig zu Systemaufhängern, weil wieder das Problem beteiligt ist, dass ich nicht weiß, wo eine Applikation ihre Dateien unterbringt, welche Verzeichnisse also per NFS übertragen werden müssen.

Gruß, kaptn

oziris
27.11.10, 14:01
Damit habe ich bereits experimentiert. Es führte regelmäßig zu Systemaufhängern, weil wieder das Problem beteiligt ist, dass ich nicht weiß, wo eine Applikation ihre Dateien unterbringt, welche Verzeichnisse also per NFS übertragen werden müssen.
Das kann ich mir gar nicht vorstellen, dass das zu Aufhängern führt. Sicher, dass das keine andere Ursache hatte?

IMHO ist es auch recht einfach herauszufinden, wo ein Programm seine Daten her nimmt. Viele Programme erstellen auch Standard-Konfigurationsdateien on-demand, wenn diese Fehlen.

kaptn
28.11.10, 19:52
Das kann ich mir gar nicht vorstellen, dass das zu Aufhängern führt. Sicher, dass das keine andere Ursache hatte?

Das kann natürlich auch sein. Jedenfalls stellte ich verschiedentlich fest, dass ein Programm wartete und ich erst in Logs feststellen konnte, warum. Oder häufig bei Jave-Anwendungen, es erscheinen irgendwelche kryptischen Meldungen, dass eine Variable falsch ist, überläuft o.ä. Für Anwender völlig unbrauchbar.


IMHO ist es auch recht einfach herauszufinden, wo ein Programm seine Daten her nimmt. Viele Programme erstellen auch Standard-Konfigurationsdateien on-demand, wenn diese Fehlen.

Das mag sein, aber erstens möchte ich als Anwender anwenden und nicht entwickeln oder erwarte mindestens genaue Angaben, damit ich evtl. anpassen kann, zweitens nützt es nichts, wenn es in 90% wie erwartet funktioniert, in 10% aber nicht, Erfahrungsgemäß treffe ich immer die 10%, nie die 90%. :-((

Gruß, kaptn

oziris
28.11.10, 20:48
[...] erwarte mindestens genaue Angaben, damit ich evtl. anpassen kann, [...]Wo erwartest Du die denn?

Kannst Du Programme nennen, bei denen Dir diese Angaben fehlen?

kaptn
30.11.10, 18:52
Hallo Oziris,

die erwarte ich wenigstens in einer Art Readme.txt oder besser in einer Dokumentation, die m.E. zu jedem veröffntlichten Programm gehört. Schon deswegen, weil es sonst nur schwer möglich ist, dem Grundgedanken von OpenSource zu folgen, nämlich die Anwender an der Entwicklung zu beteiligen, entweder aktiv oder wenigstens durch Ihre Bereitschaft mit kritischen Beiträgen konstruktiv zuhelfen.

Frage lieber, wo sie nicht fehlen. Oder habe ich sie bisher fast immer übersehen?- Wenn ja, Asche auf mein Haupt und verrate mir bitte, wo die zu finden sind.

Gruß, kaptn

oziris
01.12.10, 01:23
Frage lieber, wo sie nicht fehlen. Oder habe ich sie bisher fast immer übersehen?- Wenn ja, Asche auf mein Haupt und verrate mir bitte, wo die zu finden sind.
Es gibt ein Paar Orte, deswegen Frage ich ja nach konkreten Beispielen, damit ich Dir ggf. den jeweiligen Ort nennen kann. Naja egal. Musst Du eben selber suchen.

Meistens sind es folgende Orte:
/usr/share/doc/
"man programmname"
"info programmname"
In GUI-Programmen im "Hilfe"- oder "?"-Menü
Website des Projekts
Im Programm-Paket in Readme-Dateien
Für die ersten drei Punkte muss man manchmal im Paketmanager extra Doku-Pakete auswählen, weil es Leute gibt, die keinen Platz für die Doku auf ihrem System haben.

Aqualung
01.12.10, 10:58
Es gibt ein Paar Orte, deswegen Frage ich ja nach konkreten Beispielen, damit ich Dir ggf. den jeweiligen Ort nennen kann. Naja egal. Musst Du eben selber suchen.


Nicht zu Vergessen: Häufig liefert "programm --help" bzw. "programm -h" eine Kurzhilfe zu den verfügbaren Kommandozeilen-Optionen.

kaptn
01.12.10, 14:24
Danke, das ist alles richtig. Diese Orte für Dokus kenne ich natürlich. Das Problem war ursprünglich jedoch ein ganz Anderes, Du erinnerst Dich?- Ich fragte nach den verschiedenen Speicherorten, wo Applikationen ihre Dateien ablegen und dazu habe ich bislang wenig erfahren. Tatsache ist nunmal, dass es wenig verlässliche Hinweise gibt, wo alles Programme ihre Spuren hinterkassen. Man könnte z.B., um mein Problem zu lösen, mit Links arbeiten. Aber dazu wäre es wichtig zu wissen, auf was man linken soll.

Vielleicht war meine Ausdrucksweise etwas schludrig. Mit "Systemaufhängern" bezeichnete ich alle unerwarteten Geschehnisse, wenn ich z.B. eine Applikation starte und diese nicht läuft oder stehen bleibt, weil sie z.B. Dateien braucht, die sie nicht findet o.ä.

Gruß, kaptn

Aqualung
01.12.10, 14:45
Wenn Du Dich nicht scheust, hunderte z.T. auch irreführende Meldungen zu durchforsten, dann wäre


strace programm

evtl. was für Dich.

oziris
01.12.10, 14:51
Solange Du der Menschheit Deine offenbar immernoch streng geheimen Programmnamen vorenthältst, wirst Du da kaum sachdienliche Hinweise von uns bekommen können.

Wie auch immer, zur Not gibt es noch folgende Möglichkeiten:
"strace programmname" müsste u.a. alle Dateioperationen des Programms zeigen (sehr viel Zeug auf STDERR, daher kann die Umleitung in eine Datei sehr hilfreich sein)
mit "lsof" bekommt man eine unspezifische Momentaufnahme des Systems
in /proc/PID/fd findet man eine spezifische Momentaufnahme eines Programms als Symlinks
#Beispiel:
$ ls -l /proc/$(pidof firefox-bin)/fd

kaptn
02.12.10, 23:15
Hallo Oziris


Solange Du der Menschheit Deine offenbar immernoch streng geheimen Programmnamen vorenthältst, wirst Du da kaum sachdienliche Hinweise von uns bekommen können.

Ich scheue mich gar nicht, auch ist da nichts geheim. Aber ich habe doch bereits alles gesagt. Es geht darum, dass ich zu fast a l l e n Programmen Hinweise vermisse, welche Dateien sie anlegen und wo. Es geht nicht darum, dass ich keine Dokumentationen finde, sondern nur um diese spezielle Frage,

Aber vielleicht helfen mir Deine und Aqualungs Hinweise auf strace, lsof u.s.w. ja weiter. Dafür jedenfalls vielen Dank. Ich werde einige Zeit brauchen, damit klar zu kommen.

Gruß, kaptn

oziris
03.12.10, 05:00
Dann nenne doch bitte einfach ein Beispiel, anhand dessen man Dir das vielleicht erklären kann oder Dir zumindest sagen kann, dass es eben einfach schlecht dokumentiert ist. Da kann man dann auch etwas unternehmen und z.B. einen Bug-Report verfassen. ... aber der kaptn ist sich natürlich zu gut dafür potentiellen Helfern konkrete Auskünfte zu geben. Wenn er den Notruf wählt wiederholt er auch immer nur "Es liegt ein Notfall vor!", egal was man ihn fragt.

Ich weiß nur eins: Auf meinem System stehen bei fast allen Programmen, die ich regelmäßig nutze, die Konfigurationsdateien in der man-Page erwähnt. Bei manchen in der FILES-Sektion und bei manchen auch nur in Klammern bei einem Parameter dabei, oder so, bei manchen wird ein Konfigurationsverzeichnis nur angedeutet und bei manchen gibt es sogar extra man-Pages für die jeweiligen Dateien. Beispiele sind z.B. firefox/iceweasel , gkrellm/gkrellm2 , ion/ion2 , xawtv , gentoo , bash , xterm , pidgin und feh . Die wenigen Ausnahmen wären z.B. keepassx , tvbrowser thunderbird/icedove und gv . (Bei gv stehen die Dateien nicht in der man-Page, sondern im info-Handbuch, aber in der man-Page ist "info gv" ausdrücklich erwähnt.)

Aqualung
03.12.10, 12:03
zu fast a l l e n Programmen Hinweise vermisse, welche Dateien sie anlegen

Das mag damit zu tun haben, dass hier beinahe jede Distribution ihr eigenes Süppchen kocht.

Als erste Anlaiufstelle hierzu würde ich den Abschnitt "FILES" (einfach zu finden mit "/^FILES") in der entsprechenden manpage nennen.

kaptn
03.12.10, 16:11
Hallo Oziris,
offensichtlich habe ich ein Verständnisproblem, dass Du derart mokierst. Es war und ist nicht beabsichtigt, Euch irgendwie zu provozieren. Verstehe ich auch nicht, was Dich zu diesen Äußerungen bringt. Aber ok, lass es gut sein. Bitte verzeih, wenn ich etwas falsch gemacht habe.

Beispiele sind KDE4, cups, emacs, gimp, openoffice und dann alle Programme, die ihre Dateien anlegen, oft versteckt und mit Namen, aus denen man noch nicht einmal ableiten kann, zu welchen Programmen sie gehören. Das führt zu völlig überfrachteten Home-Verzeichnissen, in denen hunderte von Dateien stehen, die teilweise entstanden sind, weil man irgendwelche Software ausprobiert, aber wieder gelöscht hat. Die Dateien im home-Verzeichnis stehen aber jahrelang. Anfangs habe ich versucht, dort aufzuräumen, mangels irgendwelcher Anhaltspunkte, wozu welche Dateien gehören, aber desöfteren unbeabsichtigt wichtige Systemrelevante Dateien gelöscht. Dieses Verhalten kenne ich eigentlich nur von Windows, einer der Hauptgründe, warum ich vor vielen Jahren zu Linux wechselte (angefangen habe ich mit SuSE 5.x).

Anfangs habe ich noch sehr viel versucht, in verschiedenen Foren mitzudiskutieren. Mit der Zeit habe ich mich da ziemlich zurückgezogen. Ich konnte leider immer weniger die Zeit aufbringen, mich an teilweise recht fruchtlosen Diskussionen unter "Fachleuten" zu beteiligen, die sich manchmal erst einmal episch über die Stellung eines Kommas in einer Frage aufregten, bevor dann die Frage behandelt wurde. Auch war es ab und zu recht unerfreulich, von macheinem "Oberleherer" wie ein Depp behandelt zu werden.

Ich habe mich dann weitgehendst auf das Mitlesen der verschiedenen Diskussionen beschränkt, dabei viel gelernt, die Beiträge oft bewundert, ob der dort rübergebrachten fundierten Kenntnisse und mich manches Mal über die Profilneurosen einiger Diskutanten gewundert.

Gruß, kaptn

kaptn
03.12.10, 16:18
Hallo Aqualung,


Das mag damit zu tun haben, dass hier beinahe jede Distribution sein eigenes Süppchen kocht.

Ja, das genau meine ich!-

Als erste Anlaiufstelle hierzu würde ich den Abschnitt "FILES" (einfach zu finden mit "/^FILES") in der entsprechenden manpage nennen.[/QUOTE]

Vielen Dank für den Tip, das habe ich noch nicht realisiert. Werde dort mal weitersuchen. Allerdings habe ich noch nicht immer die Zeit, mich derart intensiv in solche Probleme hineinzuarbeiten, weil ich in erster Linie Schiffe fahre. Mit Linux experimentiere ich nur in meiner Freizeit herum, allerdings bisher mit viel Freude!

Gruß, kaptn

spychodelics
03.12.10, 16:24
Den Frust kenne ich, vorallem GNOME und kDE spezifische Programme speichern ihre daten an zig verschiedenen Orten.

Das Aufräumen der Dateien ist manchesmal purer Stress.

oziris
03.12.10, 21:40
Bei gimp steht es bei mir z.B. in der man-Page in der FILES-Sektion. Es handelt sich hauptsächlich um "$HOME/.gimp-2.4". Ich meine mich aber zu erinnern, dass es evtl. auch ".xvpics" Verzeichnisse für Thumbnails erstellt oder mitbenutzt. Weiß nicht, ob das noch aktuell ist.

Bei openoffice habe ich einfach Mal in meinem Heimatverzeichnis nach Sachen geschaut, die mit ".o" beginnen und wie erwartet war da ".openoffice.org2/". openoffice ist ein Beispiel für eine sehr schlechte Dokumentation.

Die versteckten, also mit "." beginnenden Dateien oder Verzeichnisse im Heimatverzeichnis,sind die gewöhnliche Vorgehensweise (wenn sie nach der Applikation benannt sind) und es ist gut und richtig so, wenn eine Anwendung, sei es auch nur wegen eines Tests, solche Dateien erstellt.

Bei Desktop-Environments, wie Gnome oder KDE landen solche Dateien oft gesammelt in einem übergeordneten Verzeichnis. Ich finde das nicht besonders schlimm, aber nervig.

Was ich aber schlimm finde ist "gconf", weil es genau so ein Müll, wie die Windows-Registry ist. Ein versteckeltes Sammelsurium an Einstellungen das ständig wächst. Früher habe ich schonmal gconfd einfach durch einen Symlink zu /bin/fasle ersetzt, um dem Herr zu werden. Inzwischen habe ich aber resigniert.

Wenn Du Tests machen willst, ohne Dein Heimatverzeichnis zu gefährden, dann empfehle ich Dir einen Test-Benutzer-Account dafür anzulegen.

Auch Backups oder Versionierung des Heimatverzeichnisses können hilfreich sein, um dort aufzuräumen. Doch Versionierung erzeugt selbst wieder viele Dateien oder Verzeichnisse ... (z.B. ".svn" in alle versionierten Vereichnisse).

Bisher habe ich aber zum Aufräumen u.a. die versteckten Konfigurationsdateien, die ich nicht direkt zuordnen konnte, einfach in ein neues Unterverzeichnis verschoben. Stellte sich heraus, dass ich sie wirklich nicht brauchte, habe ich sie gelöscht, ansonsten habe ich sie zurück verschoben.

kaptn
04.12.10, 12:51
Hallo Oziris,
siehst Du, das meinte ich. Anscheinend bist Du da schon wesentlich weiter als ich und hast die Zusammenhänge wesentlich weiter untersucht. Genau diese Arbeit des Untersuchens aber ist es, die man, wenn man anwenderorientiert schreibt, vermeiden sollte.

.gconf ist wirklich ein Witz für ein Betriebssystem, was ständig als Ersatz für Windows dargestellt wird.



Wenn Du Tests machen willst, ohne Dein Heimatverzeichnis zu gefährden, dann empfehle ich Dir einen Test-Benutzer-Account dafür anzulegen.

Auch Backups ... des Heimatverzeichnisses können hilfreich sein, um dort aufzuräumen. ...

Bisher habe ich aber zum Aufräumen u.a. die versteckten Konfigurationsdateien, die ich nicht direkt zuordnen konnte, einfach in ein neues Unterverzeichnis verschoben. Stellte sich heraus, dass ich sie wirklich nicht brauchte, habe ich sie gelöscht, ansonsten habe ich sie zurück verschoben.

Genauso mache ich es auch. Allerdings halte ich das für nicht besonders anwenderfreundlich.

Bei openoffice ist es besonders schlimm. Mittlerweile existieren in meinem home-Verzeichnis mehrere verschiedene .oo-Verzeichnisse, die im Zuge neuer Versionen angelegt wurden. Einige sind scheinbar noch aktiv, so dass ich kaum erkennen kann, was ich löschen bzw. umkopieren kann.

Gruß, kaptn

kaptn
04.12.10, 12:53
... wenn überhaupt möglich!

oziris
04.12.10, 17:52
.gconf ist wirklich ein Witz für ein Betriebssystem, was ständig als Ersatz für Windows dargestellt wird.Also ich finde nicht, dass Linux ein Ersatz für Windows ist. Es ist einfach was ganz anderes. Ehrlich gesagt würde ich sogar sagen, dass Windows Linux nie ersetzen könnte, weil bei Windows zu viele wichtige Sachen im Grundsystem fehlen. (Schon allein das Fehlen eines Paket-Managers wäre IMHO ein K.O.-Kriterium.) ... umgekehrt geht es auch nicht, wegen vielen Treibern und Spezialsoftware, die immer nur für das aktuelle Windows hergestellt wird. Klar, jedes OS hat bestimmte Software, für die es auf anderen OS keine ordentliche Alternative gibt, aber bei Windows ist das sehr extrem.
Abgesehen von dieser Software- und Treiber-Sache wüsste ich aber keinen Fall, in dem man ein Windows einem Linux oder BSD vorziehen sollte. Denn obwohl z.B. der gconf-Kram blöd ist, ist er immernoch ein kleineres Übel als die Windows-Registry. ... und so ist es IMHO mit allen Schwächen von Linux: Sie sind vernachlässigbar.
Wichtig ist nur, dass man im Hinterkopf behält, dass Betriebssysteme nur Werkzeuge sind und man für einen bestimmten Zweck einfach nur das richtige Werkzeug auswählen muss ... und das kann sogar Mal FreeDOS sein, auch wenn es von vielen belächelt wird.

kaptn
05.12.10, 15:48
Ja Oziris,
das ist eine sehr richtige und vor allem faire Einschätzung. Aber jetzt verlassen wir das Thema endgültig.

Ich danke Dir und Aqualung für den Gedankenaustausch und die Tipps. Mal sehen, was und wann ich es umsetzen kann.

Gruße, kaptn

rudelgurke
06.12.10, 19:32
Zumindest OpenOffice und auch LibreOffice kann man Benehmen beibringen - sieht dazu die bootstrap.ini wo festgelegt wird in welchem Verzeichnis unter $HOME alles landen soll.
Zum Rest der "Dateileichen" - vielleicht hilft da ein find mit atime / mtime etc. weiter und einem geschickten "mv" anstatt "rm"

L00NIX
12.12.10, 10:52
Und hier liegt das Problem: Solange alle Rechner mit SuSE 11.3 arbeiten, gibt es kaum Schwierigkeiten. Sobald aber ein Rechner z.B. Mandriva o.a. nutzt, gibt es Kollisionen mit den Einstellungsdateien. Da ich keine Linuxdistribution kenne, die Einstellungsdateien und Daten sauber trennt, hilft es auch nichts, mit Links zu arbeiten. Zudem weiß ich nicht, wie ich verhindere, dass ein mobiler Rechner dann, wenn er nicht am Netz hängt, startet und dabei automatisch netzabhängige Anfragen auf lokale Verzeichnisse umleitet bzw. garnicht stellt (wie NTP z.B.).

Wißt Ihr da eine Lösung?


Für die nicht zu startenden Netzwerkdienste: In anderem Runlevel starten?

Diesen kann man dem Kernel mitgeben:
(Quelle: http://www2.geo.uni-bonn.de/members/kuepper/linux/boot.txt)


-root=/dev/hda1
Nach root= folgen Kernelparameter.
Man kann hier zum Beispiel den Runlevel als Parameter übergeben. Soll
zum Beispiel im Runlevel 1 gestertet werden:

root=/dev/hd0,0 1

Die 1 hintendran ist der Parameter für Runlevel 1.


Das Problem mit den unterschiedlichen Konfigurationsdateien in $HOME tritt nur bei unterschiedlichen Programmversionen auf. Du könntest dir überlegen, ob du die Nutzdaten als Unterverzeichnis von $HOME realisierst und dann darin eine weitere NFS-Freigabe einhängst. Die NFS-Freigabe $HOME müsste dann aber je nach System unterschiedlich sein, was ja kein Problem ist, denn der Client entscheidet ja, was er wie einhängt.

Ich finde das aber nicht so toll.

Bei uns in der Firma gibt es auch ein $HOME via NFS eingehängt. Bisher gab es dabei aber keine Probleme, weil auf den meisten Linuxrechnern nur Shellanwendungen und keine vollen Desktops zum Einsatz kommen. Mein Desktop läuft nur auf dem lokalen Client-PC, also gibt es hier auch keine Überschneidungen.

Bei KDE sind die Anwendungseinstellungen alle im Verzeichnis .kde bzw. .kde4 gekapselt. In Verbindung mit einem Initskript könnte ich mir vorstellen, dieses Verzeichnis über einen Symlink mit wechselndem Zielverzeichnis beim booten entsprechend anpassen zu lassen:


# D="$HOME/.kde4"
# [ -L "$D" ] && rm -f "$D"
# ln -s "$HOME/.kde4-mandriva" "$HOME/.kde4"
bzw.
# ln -s "$HOME/.kde4-suse" "$HOME/.kde4"


Nur so ein Gedanke, vielleicht ja auch zu kompliziert... ;)

Gruß
L00NIX

kaptn
12.12.10, 18:10
Danke, ich hatte nicht erwartet, dass hier noch jemand dran ist.- Deine Tipps wrede ich vielleicht auchmal testen. Klingt im Moment zwar kompliziert, bedarf aber wahrscheinlich nur einiger ruhiger Minuten, um es ganz zu verstehen.

Frohes Fest, kaptn