• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[geloest] MIT-MAGIC-COOKIE-1 Fehler -> gnome session mana

deepak

Member
Hallo.

Bin ueber eine Eigenart gestolpert, die ich mir bisher nicht erklaeren kann.
Lasse Gnome 2.12 laufen auf einem ASUS NB mit ATIx700 Grafikkarte.
Nun kann bekomme ich oefters, wenn ich Anwendungen starte als normaler user, folgende Fehlermeldung:

Xlib: connection to ":0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key,

und danach nichts mehr. War vorher nicht angemeldet als root, und kann auch nicht vorhersagen, wann diese Meldung kommt und wann nicht. Will heissen, in der einen Minute kann ich opera noch ganz normal starten in der Konsole, in der anderen kommt dann obige Fehlermeldung.
Desweiteren erscheint bei jedem graphischen Programm das ich starte (wenn es denn startet), eine Warnung in der Form:

GnomeUI-WARNING **: While connecting to session manager: Authentication Rejected, reason: None of the authentication protocols specified are supported and host-based authentication failed.

Die Anwendung startet zwar, werde jedoch nicht wirklich aus dieser Meldung schlau.
Diverse aeltere Forenbeitraege berichten von Modifikationen an der .Xauthority im home Verzeichnis, kann damit allerdings nicht viel anfangen.
Anderswo wird gesagt, man solle als root xhost + eingeben, funktioniert ebenfalls nicht, bricht ab mit obiger MIT-COOKIE-1 Fehlermeldung.
Ich frage mich auch, was denn das mit dem session manager zu tun hat, habe eigentlich im gnome control center das "automatically save changes to session" deaktiviert. Damit scheint allerdings irgendwas nicht so ganz zu klappen, da bei jedem Neustart trotzdem einige (beliebige in meinen Augen) Anwendung aus meiner letzten session automatisch gestartet werden.
Das macht bei mir alles im Moment nicht viel Sinn, vielleicht kann mir ja jemand helfen? Vielleicht ist mir dieses sesssion management auch nicht so ganz klar...

gruss, dp
 
OP
D

deepak

Member
Hallo nochmals.

Kann mir denn niemand einen Tipp geben?

Es schien ein aehnliches Problem schon mal hier gegeben zu haben, allerdings bringt mich das so gar nicht weiter. Bin weder vorher als root angemeldet, noch trifft die update Geschichte auf mich zu (habe suse10.0).

Und wieso startet Gnome dennoch Programme aus der letzten session, obwohl ich genau diese Option deaktiviert habe...ist das vielleicht mit einer der Gruende fuer diese "Authentication Rejected" Warnung des session managers? Hat jemand Erfahrungen gemacht mit diesen Warnungen / Fehlernachrichten?

Bin fuer jede Hilfe dankbar.

dp
 

tuxlin

Newbie
Hi
Kann Dir nicht wirklich helfen, da ich nicht mit Gnome arbeite.
Aber der von Dir beschriebene Fehler tritt auf, wenn ein anderer User auf das Display des eingeloggten Users zugreifen will.
d. h. wenn ich als User XYZ eingeloggt bin und dann zum Beispiel ein Programm mit root Rechten starte muß es root ja erlaubt sein auf das DIsplay von XYZ zu schreiben. Dies wird in der .Xauthority geregelt bzw. erlaubt. Bei mir war nach einem update v. Suse 9.2 auf Suse 10.0 diese nicht mehr in Ordnung. Die Datei .Xauthority im homverzeichnis muß so um 33kByte groß sein, überprüf das mal zuerst.
Es sieht aber alles nach einem Problem mit der .Xauthority aus plus eventuell eines Problems mit Gnome session manager. Irgend wie dürfen die Programme nicht auf das Display zugreifen und es wird von X-Server deren Start verweigert.

Gruß Uwe
 
OP
D

deepak

Member
hi uwe.
danke erstmal fuer deine Hilfe.
Hab mal nachgeschaut, die Datei .Xauthority ist bei mir nur etwa 230 Byte gross, also nachdem was du geschrieben hast eindeutig zu klein.

Was kann ich denn da machen, damit die Xserver Zugriffsrechte wieder stimmen?? Gibt es ein tool mit dem man die .Xauthority aendern kann??

Seltsam ist allerdings, dass ich nie versucht habe, nachdem ich mich als normaler user eingeloggt habe, als root auf den Xserver zurueck zu greifen...da ist anscheinend etwas grundsaetzliches schief gelaufen in der .Xauthority, oder?

Aus dem gnome session manager werde ich ohnehin nicht schlau, der startet obwohl deaktiviert, trotzdem noch Programme aus aelteren Sitzungen, und das auch noch absolut willkuerlich...wie hast du das Ding denn (de)aktiviert??

gruss dp
 

tuxlin

Newbie
Hi
Genau wie bei mir, war auch nur noch so 230 Byte groß, ich habe noch auf einer anderen Partion ein vorsichtig geflegtes 9.1 laufen.
Die 10.0 habe ich von einer 9.2 aus upgedatet, danach konnte ich aus dem Konquerror im System-modus (root) keinen Editor mehr öffnen.
die 9.2 u. jetzige 10.0 sind bei mir quasi nur Testsysteme, daher hatte ich auch kein Backup von den wichtigsten Verzeichnissen. Ich habe einfach die .Xauthority von meinem 9.1 System genommen. Da sie bei Dir auch so klein ist, (sonst über 30kByte) liegt hier vermutlich auch der Fehler. Die Fehlermeldunge sprechen jedenfalls dafür.
So, ich habe mir mal meine .Xautority mit
Code:
xauth list
angeschaut, das sieht bis auf die ersten drei Einträge aber auch nicht gut aus, sind haufenweise Einträge mit DTAG-IP´s drin. Ich werde sie mal umbenennen und "X" neu starten. Eigentlich sollte sie ja von xinit o. XDM (KDM) neu erstellt werden. So bis hierher erstmal Pause, ich werde mal selbst ein wenig experimentieren, scheint mir eher so, als das die Größe auf Grund der vielen Einträge so angewachsen ist und vielleicht doch die kleine Größe am Anfang v. 230 byte richtig ist. Warum das mit dem Start von X-Apps. aus einer Root X-App. heraus plötzlich nicht mehr ging muß ich jetzt erteinmal testen
bis denne Gruß Uwe
 

tuxlin

Newbie
Hi dp
Ich habe mal ein wenig probiert und die .Xauthority umbenannt, sie ist so 160 Byte groß und enthält unter 10.0 mit Xorg 6.8.2-100.2 nur drei Einträge, die beim Systemstart automatisch erstellt werden, wahrscheinlich aber erst von Loginmanager (bei mir KDM), da sie bei einem Start eines Dateimanagers mit Root-Rechten bei /root nicht vorhanden ist, bzw. sie ist 0Byte groß. Wenn man sich aber als Root einloggt ist sie genauso wie beim Userlogin 160Byte groß und enthält ebenfals drei Einträge. Wenn du in einem x-terminal folgendes eingibst
Code:
uwe@linux:~> xauth list
linux:0  MIT-MAGIC-COOKIE-1  a2cc95a3e12ce4b2e7bcd4633e4f2672
[fe80::240:f4ff:febf:7e9f]:0  MIT-MAGIC-COOKIE-1  a2cc95a3e12ce4b2e7bcd4633e4f2672
linux/unix:0  MIT-MAGIC-COOKIE-1  a2cc95a3e12ce4b2e7bcd4633e4f2672
siehst du die Einträge.
In einem Root-X-term müßtest Du dann den Schlüsseleintrag des eingeloggten Users sehen
Code:
Password:
linux:~ # xauth list
linux/unix:0  MIT-MAGIC-COOKIE-1  a2cc95a3e12ce4b2e7bcd4633e4f2672
linux:~ #
Ich habe leider kein Gnome Installiert um da mal was zu testen, Vielleicht brauchen die App´s oder der Sessionmanger die Umgebungsvariable XAUTHORITY Du kannst sie ja mal setzen, vielleicht versuchen manche Programme über diese Variable den Schlüssel zu bekommen.
Code:
uwe@linux:~> XAUTHORITY=$HOME/.Xauthority
export XAUTHORITY
DU müßtest mal mit Gnome Usern Posten, ich weiß hier so auch nicht weiter
Gruß Uwe
 
OP
D

deepak

Member
hi uwe.

Danke fuer deine ausfuehrliche Hilfe.

Das explizite Setzen des XAuthority keys auf die .XAuthority im home Verzeichnis fuehrt allerdings auch zu keinen neuen Ergebnissen.

Was ich halt im Moment mache ist, wenn es wieder zu derartigen Fehlermeldungen kommt und kein Programm die noetigen Xserver Zugriffsrechte zu haben scheint, Suse neu zu booten, dann klappts (manchmal).
Diese scheinbare Willkuerlichkeit irritiert mich dabei am meisten. Logge mich weder vorher als root an, sondern starte ganz normal (also kein init 3 und dann erst X) und manchmal gibt's Fehlermeldungen und manchmal nicht.

Sehr seltsam.

gruss,
dp
 
OP
D

deepak

Member
hi,

habe noch ein bisschen mehr herumexperimentiert.

Das Problem tritt nur dann auf, wenn ich ueber ein vpn script ins Internet gehe. Das muss ich als root ausfuehren, da module in den kernel geladen werden. Anschliessend kann ich als normaler user keine (!) graphische Anwendung mehr starten.

Wenn ich mich auslogge, und wieder erneut als root einlogge, funktioniert alles einwandfrei. Nur halt nicht mehr fuer den normalen user.
Was kann man denn da machen?? Ist schon ziemlich nervig, wenn das bedeuten wuerde, dass ich mich jetzt immer als root anmelden muesste...
 

tuxlin

Newbie
HI DP
Ich selbst arbeite ja noch auf einer 9.1 mit X.free 4.3.99.902, bei Suse
10.0 mit x.org 6.8.2. Da unterscheidet sich die Xauthority schon. Bei 9.1 sieht es folgendermaßen aus.
Eingeloggt als user:
Code:
uwe@linux:~> xauth list
linux:0  MIT-MAGIC-COOKIE-1  e7a497664eec1a42745cbce5d8bd15d0
linux/unix:0  MIT-MAGIC-COOKIE-1  e7a497664eec1a42745cbce5d8bd15d0
linux:0  XDM-AUTHORIZATION-1  2b4d04704f56c57500192264f3dd65ea
linux/unix:0  XDM-AUTHORIZATION-1  2b4d04704f56c57500192264f3dd65ea
Wenn ich jetzt ein root-x-term öffne erscheint nach Eingabe des Passwortes u. xauth list gar nichts
Code:
Password:
linux:~ # xauth list
linux:~ #
Bei 10.0 sieht es anders aus. Hier sind die XDM_AUTHORIZATION Einträge nicht vorhanden und ich bekomme als user eingeloggt folgendes:

Code:
uwe@linux:~> xauth list
linux:0  MIT-MAGIC-COOKIE-1  a2cc95a3e12ce4b2e7bcd4633e4f2672
[fe80::240:f4ff:febf:7e9f]:0  MIT-MAGIC-COOKIE-1  a2cc95a3e12ce4b2e7bcd4633e4f2672
linux/unix:0  MIT-MAGIC-COOKIE-1  a2cc95a3e12ce4b2e7bcd4633e4f2672
Öffne ich jetzt ein root X-Term wird mir allerdings der richtige Cookie angezeigt (der des eingeloggten users über das UNIX-Socket):
Code:
Password:
linux:~ # xauth list
linux/unix:0  MIT-MAGIC-COOKIE-1  a2cc95a3e12ce4b2e7bcd4633e4f2672
linux:~ #
Was passiert bei Dir denn wenn Du als normaler User eingeloggt bist?
Kannst DU ein X-term starten?
Was passiert wenn DU Dein VPN-Skript als Root ausgeführt hast, kannst Du dann noch ein normales x-term (User) starten? Wenn nicht gehört das DISPLAY eventuell plötzlich ROOT.
Führst DU das VPN-Skript als root aus oder mit SUID? Starte es doch mal als USER und setzes es vorher SUID, was passiert dann? Vielleicht klappt es ja schon wenn Du es SUID laufen läst.
Falls es mit dem Skript zusammen hängt könnte man es ja auch über SUDO starten, und vorher das sudoers file in etc/sudoers bearbeiten, da mußt DU als Root Dir als user die Erlaubnis erteilen das skript ausführen zu dürfen. Ist jedenfalls besser als es SUID laufen zu lassen.
Treten denn die Probleme grundsätzlich auf, wenn Du als User eingeloggt bist? also auch ohne Start des VPN_Skripts?
Könnte dann ja auch an der GDM config liegen (ist denke ich Dein login-manager), aber dann müßten ja auch grundsätzlich Probs. auftreten, auch unter root-login.
Im Grunde kann man Deine Fehlermeldung einfach nachvollziehen, in dem man die .Xauthority im home-Verzeichnis umbennent und danach ein Prog starten will. ES geht nicht mehr u. in der .xsession-errors kann man dann genau diese Fehlermeldung sehen.
Na ja versuch noch mal ein bisschen, Die enviremont Variable XAUTHORITY=$HOME/.Xauthority zu setzen klappt ja anscheinend nicht.
Hätte man dann vielleicht gleich mal in die profile in etc eintragen oder in die bashrc im home-Verz.
Bis denne Uwe
 
OP
D

deepak

Member
Hi Uwe,
zunaechst mal Danke fuer deine erneute Hilfe.
Hier sind die Ausgaben von xauth list als user:
Code:
#ffff##:0  MIT-MAGIC-COOKIE-1  5fd143e8423195d9f29a564c98dabef4
wlan016206/unix:0  MIT-MAGIC-COOKIE-1  5fd143e8423195d9f29a564c98dabef4
localhost.localdomain/unix:0  MIT-MAGIC-COOKIE-1  5fd143e8423195d9f29a564c98dabef4
und als root:
Code:
wlan016206/unix:0  MIT-MAGIC-COOKIE-1  5fd143e8423195d9f29a564c98dabef4
Was passiert bei Dir denn wenn Du als normaler User eingeloggt bist?
Kannst DU ein X-term starten?
Nachdem ich die vpn Verbindung hergestellt habe, kann ich im X window keine graphische Konsole mehr oeffnen.
Führst DU das VPN-Skript als root aus oder mit SUID? Starte es doch mal als USER und setzes es vorher SUID, was passiert dann? Vielleicht klappt es ja schon wenn Du es SUID laufen läst.
Das vpn script muss als root ausgefuehrt werden, da neue module in den kernel sgeladen werden. Einen Befehl SUID oder setuid hab ich gar nicht.
Treten denn die Probleme grundsätzlich auf, wenn Du als User eingeloggt bist? also auch ohne Start des VPN_Skripts?
Die Probleme treten in der Tat nur dann auf, wenn ich vorher das vpn script ausfuehrt habe. Habe mich, glaub ich, am Anfang missverstaendlich ausgedrueckt, da war mir allerdings noch nicht ganz klar, dass das MIT-COOKIE Problem mit diesem vpn script zusammenhaengt.

Nachtrag:
Das Problem scheint sich zu eruebrigen, wenn ich folgendes mache:
1. vpn script als root ausfuehren, user kann keine graphischen Programme starten
2. komplett ausloggen und als root einloggen
3. erneut ausloggen und wieder als user einloggen
4. es gibt keine Konflikte mehr, graphische Programme koennen wieder vom user gestartet werden.

Werde nochmal ein bisschen rumprobieren, danke auf jeden Fall fuer deine Bemuehungen,
gruss dp
 

tuxlin

Newbie
Mit SUID ist die Rechtevergabe gemeint. Sozusagend das s-Bit in der Rechtevergabe, und gehört zu "chmod", hätte es vielleich auch UID nennen sollen. Das kann man aber einfach über den Dateimanger einstellen. Falls es unter Nautilus auch geht: rechtsklick aufs skript -->Dateieigenschaften aufrufen --> Berechtigungen --> uid ankreuzen (eventuell auch unter Berechtigungen -->Erweitert)
Ansonsten in rootconsole
Code:
chmod +s <Skript-Datei>
oder auch komplett
Code:
chmod 4755 <skript-datei>
Das skript kann dann vom user aufgerufen werden läuft aber mit den rechten des Besitzers/Benutzers, also root. Würde dann wahrscheinlich die Rechte 4755 haben. Sonst siehe "man chmod" ist ein normales bash-comando.
Code:
sudo <Skript-Name>
würde auch gehen, wenn man es vermeiden will ein Programm o. Skript ständig mit Rootrechten laufen zu lassen(also das UID wieder entfernen Rechte 755). "sudo" ist so etwas wie "su", nur wird hierbei das Komando nur einmalig ausgeführt, dazu muß root aber in /etc/sudoers die Erlaubnis für einen User oder eine Gruppe erteilen. Sonst auch mal kurz Lektüre über "sudo u. sudoers-file"
Wenn Du Dir das sudoers-file in /etc anschaust siehst Du schon was gemeint ist. Das ist die etwas sichere/elegantere Lösung um eben ""NICHT"" das UID o. auch s-Bit gennant zu setzen. Du kannst das Skript dann halt als normaler User aufrufen.
Wenn ich davon ausgehe das localhost.localdomain Dein Rechner ist sieht es bis auf einen Eintrag wie bei mir aus. Dann müßte eigentlich noch ein
Code:
localhost.localdomain:0  MIT-MAGIC-COOKIE-1 5fd143e8423195d9f29a564c98dabef4
da stehen. Geht irgentwie über "xauth merge" Eine man für xauth finde ich bei mir nicht, gehört wohl irgendwie zum X-Server. Aber ob es überhaupt da rein muß??, bin ich überfragt ""LINUX non-Guru"" Vielleicht gehts auch einfach mit
Code:
echo "localhost.localdomain/unix:0  MIT-MAGIC-COOKIE-1  5fd143e8423195d9f29a564c98dabef4" >> ~/.Xautority
:shock: Aber wohl besser nicht,da die Datei ja leicht binär ist.
Hast Du die .Xauthority schon mal einfach umbenannt (z.b. .Xautority.save)und dann mit init 3 runter gefahren und gleich wieder mit init 5 hoch: Sie müßte dann neu erstellt sein. Mit
Code:
xauth list
anschauen ob sie wieder so aussieht wie vorher bzw. sich wieder dahin entwickelt, es müssen ja nicht gleich alle Einträge von Anfang an vorhanden sein. Könnenja auch noch welche nach VPN-Aufbau hinzu kommen. Ich würde auf alle Fälle mal die UID Methode versuchen, um das Skript als reiner User nach User-Login ausführen zu können. Das Skript nicht starten und mal "xauth list" in x-term und Root X-term aufrufen, Weiß auch nicht warum da ROOT über wlan kommt, hätte im Root-xterm eher sowas wie
Code:
localhost.localdomain/unix:0  MIT-MAGIC-COOKIE-1  5fd143e8423195d9f29a564c98dabef4
erwartet. Meldet sich aber auch keiner im Fred der sich mit diesem xauthority Kram auskennt, ist eigentlich oft ein Prob. bei Remote Zugriffen.
Also erstmal viel Glück bis denne Uwe
 
OP
D

deepak

Member
hi uwe.
wieder mal danke fuer deine ausfuehrliche Hilfe, werde diese (S)UID Methode ausprobieren, bin im Moment allerdings auf der Arbeit und da hab ich dank wlan keine Probleme.
Werd mal Bescheid sagen wie es aussieht heut abend,
gruss dp
 
OP
D

deepak

Member
hallo uwe.
ok, hab gestern abend die UID Methode ausprobiert, und es scheint zu klappen. Zumindest kann ich nun wieder als user graphische Anwendungen starten (ohne den Umweg ueber root).
Nur eine kleine Sache: Es erscheint jetzt jedesmal eine Nachricht
Code:
_IceTransSocketUNIXConnect: Cannot connect to non-local host Linux
Session manager error: Could not open network socket.
.
Also schon wieder irgendetwas mit dem session manager (der eigentlich immer noch deaktiviert ist, wenn es sich denn um den Gnome session manager handeln sollte...).
Naja, um ehrlich zu sein, bin schon froh, dass das alles so geklappt hat, und obwohl es sich wohl um irgendeinen error handelt, laeuft alles wie normal...
aber trotzdem...
egal, dank dir vielmals fuer deine ganze muehe,
gruss dp
 

tuxlin

Newbie
Na ja
Bei Dir ist (von Anfang an) irgendwie ein zweiter Host im Spiel, daher auch die Probleme.
Code:
_IceTransSocketUNIXConnect: Cannot connect to non-local host Linux 
Session_IceTransSocketUNIXConnect: Cannot connect to non-local host Linux 
Session manager error: Could not open network socket. manager error: Could not open network socket.
"non-local host Linux" sagt das jedenfals aus. Wenn man keinen Hostnamen vergeben hat ist bei Suse der HOSTNAME per default "Linux" also der eigene Rechner. Das sieht man auch an Deiner .Xauthority, da kommen wie bei mir die "Linux" (linux:0 , linux/unix:0) Einträge nicht vor
Code:
uwe@linux:~> xauth list 
linux:0  MIT-MAGIC-COOKIE-1  a2cc95a3e12ce4b2e7bcd4633e4f2672 
[fe80::240:f4ff:febf:7e9f]:0  MIT-MAGIC-COOKIE-1  a2cc95a3e12ce4b2e7bcd4633e4f2672 
linux/unix:0  MIT-MAGIC-COOKIE-1  a2cc95a3e12ce4b2e7bcd4633e4f2672

Wer bist DU eigentlich selbst? Gib mal
Code:
echo $HOST
und
Code:
echo $HOSTNAME
auf dem x-term ein. Wenn man bei Suse keinen anderen Hostnamen o. FQDN setzt ist der eigene Host-Hostname "Linux".
Vielleicht wird bei Dir auch der Hostname über DHCP geändert. Wenn Du unter Yast --> Netzwerkdienste --> DNS u. Hostname schaust, ist Hostname über DHCP ändern normaler weise "NICHT" aktiviert.
Ich weiß ja nicht was dieses VPN-Skript eigentlich alles macht. Wenn es nur Kernelmodule laden soll, geht das ja auch auf anderem Wege.
Der Session manager error bezieht sich wohl eher auf die X-Session, und hat mit Gnome nichts zu tun.
Mußt Du wieder rumprobieren was da so als Host bzw. Hostname so rauskommt mal mit u. mal ohne VPN-Skript oder eventuell auch mit der DHCP Vergabe (ist aber nur so eine Idee von mir). Deine X-Session läuft jedenfals nicht für "linux:0 oder über ein Unix-socket "linux/unix:0
Aber wenn alles mit dem UID (s-bit) läuft ist es ja auch schon gut, könnte man dann höchstens noch auf sudo umstellen.
Von Xsession errors bin ich auch nicht frei. Wenn ich sie nicht verstehe aber alles läuft tangieren sie mich auch nicht weiter. :? :idea: :arrow: :wink:
 
OP
D

deepak

Member
Code:
echo $HOST
gibt mir meine IP Adresse (wenn ich ueber's vpn script ins Netz gehe), und ansonsten wlanxyz (mit xyz = irgendeine Zahl), wenn wlan benutzt wird. echo $HOSTNAME liefert das gleiche.
Vielleicht wird bei Dir auch der Hostname über DHCP geändert.
Ja, das wird er. Es ist genauso wie du es beschreibst, allerdings ist die Option "Change Host Name via DHCP" aktiviert. Und was bedeutet das nun?
Uebrigens, wenn ich unter yast auf "DNS u. Hostname" gehe, bekomme ich erstmal eine Meldung
The resolver configuration file (/etc/resolv.conf) has been temporarily modified by dhcpcd. You have two options:
1. Modify the current (changed) version of the file.
2. Accept now and continue editing other (nonresolver) data.
Egal ob modify oder accept, meine Internetverbindung funktioniert danach nicht mehr und ich muss den Rechner neu starten, damit ich wieder ins Netz kann.
Beim DNS u. Hostname Menu steht im Uebrigen
"hostname"=linux und
"domain name"=site .
Also, mir sagt das alles nichts mehr...

gruss, dp
 

tuxlin

Newbie
Ja, das wird er. Es ist genauso wie du es beschreibst, allerdings ist die Option "Change Host Name via DHCP" aktiviert. Und was bedeutet das nun?
Uebrigens, wenn ich unter yast auf "DNS u. Hostname" gehe, bekomme ich erstmal eine Meldung

The resolver configuration file (/etc/resolv.conf) has been temporarily modified by dhcpcd. You have two options:
1. Modify the current (changed) version of the file.
2. Accept now and continue editing other (nonresolver) data.

Ich meinte "Change Host Name via DHCP" solltest Du mal deaktivieren, damit der Hostname nicht geändert wird.
Die Meldung zur resolver.conf ist richtig, da ja die DNS-Servereinträge über DHCP geändert wurden sind. (o. worden :?: )

Dann gibt es Unten noch "Nameserver u. Suchliste über DHCP aktualiesieren" das bleibt "AKTIV" damit Du die DNS-Server uber DHCP aktualiesierst bekommst. Dies führt eben zu obiger Meldung "The resolver configuration file (/etc/resolv.conf) has been temporarily modified by dhcpcd...usw. Ist so genau richtig.
Wenn die resolver.conf nicht modifiziert werden soll müßtest Du die Namserver (DNS-Server) hier in der Netzwerkkarten configuration von Hand eintragen u. am besten noch in der "etc/sysconfig/network/dhcp" den Eintrag DHCLIENT_MODIFY_RESOLV_CONF="yes" auf "no" setzen.
in der "etc/sysconfig/network/config" den Eintrag MODIFY_RESOLV_CONF_DYNAMICALLY="yes" auch auf "no" aber das wollen wir jetzt mal nicht. Dazu brauchst Du aber die IP´s der Nameserver (DNS) Deines Providers (am besten zwei bis drei)


Egal ob modify oder accept, meine Internetverbindung funktioniert danach nicht mehr und ich muss den Rechner neu starten, damit ich wieder ins Netz kann.
Beim DNS u. Hostname Menu steht im Uebrigen
"hostname"=linux und Domainname "site" das ist hier also richtig.

"domain name"=site .
Also, mir sagt das alles nichts mehr...
genau das meinte ich, bei Suse ist der HOSTNAME bzw. HOST = Linux
u. Domain-Name = "site"
Also die Modifizierung des Hostnamens via DHCP mal deaktivieren, aber "NICHT" die Modifizierung der Nameserver u. Suchlisten.
Bevor Du das machst sichere Dir mal die resolver.conf in /etc/resolver.conf und zwar nachdem Du ins Intenet gegangen bist. In /etc sollten eigentlich zwei Einträge für die resolver.conf sein, einmal die aktive (u. eigentliche resolver.conf) und eimal eine resolver.conf.saved.by.dhcpd.<Dein Netzwerkdevice> oder so ähnlich. Die werden immer gegeneinander ausgetauscht. d.h. Du bekommst via DHCP die Nameserver IP´s und die werden in die resolver.conf eingetragen, die bestehende resolver.conf wird dann vorher als resolver.conf.save.by. irgendwas gesichert und wenn du die Netzwerkverbindung bzw. Internetverbindung beendest, wird die gesicherte resolver.conf wieder eingetragen und die eben temporäre gelöscht.

Habe mich eben nur ein wenig gewundert, daß bei Dir in der .Xauthority nicht der eigentliche HOSTNAME "linux" auftaucht.
Also mal probieren was passiert wenn Du nur dieses eine Kreuzchen in der Netwerkarten Configuration weg machst.
Den Rechner am besten danach einmal neu booten.
greets Uwe
 
OP
D

deepak

Member
Hi Uwe.
ok, es scheint alles mit deinen Vorschlaegen zu funktionieren.

"Change Host Name via DHCP" ist deaktiviert.
"Nameserver u. Suchliste über DHCP aktualisieren" ist aktiviert.

echo $HOST gibt jetzt "linux" aus, dito fuer echo $HOSTNAME

Der MIT-MAGIC-COOKIE Fehler ist bisher noch nicht aufgetreten, auch von gnome session errors keine Spur bisher.
Werde die Sache weiter beobachten, ansonsten bleibt mit nur noch Danke zu sagen fuer deine ganze Muehe.

dp
 

tuxlin

Newbie
Nichts zu Danken, dafür sind ja Foren da!!
Ich hoffe es klappt jetzt alles etwas besser, ob es das genau war weiß ich ja auch nicht sicher, da es immer sehr schwer ist etwas aus der Ferne zu beurteilen. Gnome habe ich ja nicht am laufen, aber als Du dann das VPN-Skript ins Spiel gebracht hast u. Du mir Deine .Xauthority gezeigt hast bin ich ja auch in eine ganz andere, (aber warscheinlichere) Richtung gegangen. Da hat das Ganze mit GNOME auch nichts mehr zu tun.
Viel Spass noch mit LINUX
bye Uwe
 
Oben