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

resolv.conf wird immer auf die isp-nameserver zurückgesetzt

gelbeseiten

Newbie
hallo zusammen,

ich habe folgendes problem. ich habe in meinem kleinen home netztwerk 2 linux rechner. der eine, der als gw/dsl-router läuft, ist der secondary dns server und der zweite mein primary dns (fragt nicht warum, ist so gewachsen:)

bei jedem reconnect des servers wird die resolv.conf neu geschrieben und ich finde die dns server meines isp in der resolv.conf.
domain und search meinedomain.local, bleibt erhalten. nur meine lokalen dns servereinträge sind verschwunden. :x

gibt es möglichkeiten dieses zu unterbinden? :?:


besten dank

gruß

volkmar
 

PC-Ulf

Member
Code:
su root
cd /etc 
vi resolv.conf
Sichere die Datei mit
Code:
cp resolv.conf sich_resolv.conf
, da diese gelöscht wird beim runterfahren.
Code:
cd /etc/sysconfig/network 
vi dhcp
DHCLIENT_MODIFY_RESOLV_CONF="yes"
auf no setzen. Beim runterfahren wird nun noch einmalig resolv.conf gelöscht :!:

Neu hochfahren. Anschließend in /etc
Code:
mv sich_resolv.conf resolv.conf

Nun sollte die resolv.conf nicht mehr gelöscht werden.

Hoffe es hilft.
 
OP
gelbeseiten

gelbeseiten

Newbie
hallo,


also

leider stand da schon DHCLIENT_MODIFY_RESOLV_CONF="no"

ich habe trotzdem meine kiste mal durchgestartet, da diese schon ziemlich lange online war, aber leider nichts :cry:

hast du sonst noch eine idee? :?:

sonst muss ich mir einen cron job basteln, was ja aber nicht sinn der übung sein soll/kann. :evil:

gruß

volkmar :roll:
 
OP
gelbeseiten

gelbeseiten

Newbie
noch was, das kuriose ist ja, er behält alle auskommentierten, search und domain einträge bei !

merkwürdig sehr merkwürdig...


gruß

volkmar
 

PC-Ulf

Member
Verwundert mich :?

Die resolv.conf wird trotzdem zurückgesetzt. Keine Ahnung was darauf noch zugreift.

Vielleicht einfach mal mit der Hammer Methode vorgehen. Entferne mal den Schreibzugriff aller Nutzer auf die Datei, boote neu und achte auf Fehlermeldungen. Vielleicht kommst Du so den Dienst auf die Schliche.

Sende auf jeden Fall die Lösung, wenn Du sie findest. Interessiert mich sehr was noch auf die resolv.conf zugreift.
 
OP
gelbeseiten

gelbeseiten

Newbie
ja klar mache ich das, denn mich nervt es auch wenn ich einen forumeinragt mit dem problem finde und es steht unter jetzt funzt
es, aber wie die lösung war schreibt keiner.

was noch komisch ist, als erstes setzt er die t-online dns server, die ich als forwarder eingesetzt habe, ein und 2 min später sind die meines providers in der resolv.conf.
alles merkwürdig sehr merkwürdig.

gruß

volkmar
 
OP
gelbeseiten

gelbeseiten

Newbie
ICH HABE ES :)


war nicht weiter schwer, in den messages stand das der smpppd auf die datei zugreift, sichert und dann modifiziert.
ich habe mir dann die "manual" vom smpppd angeguckt und da fand ich einen pfad:

/etc/sysconfig/network/provider/provider0

in dieser datei nur
MODIFYDNS=`no`

und schon geht es :)

hätte ich auch selber drauf kommen können mal in die messages zu gucken, aber manchmal sieht man den wald vor lauter bäumen nicht :)


danke dir noch mal

cu

volkmar
 
Hallo,
habe auch mit diesem Phänomen zu tun.
Finde nach jedem Neustart in der resolv.conf den Eintrag:

nameserver 192.168.0.1

was mein Router ist (ich wusste gar nicht, dass er Namen auflösen kann...)
Immerhin schafft er es einen Großteil der Verbindungen herzustellen, wenn auch nur langsam.

Ich ändere das immer wieder manuell in

nameserver 192.109.42.4
nameserver 192.109.42.5

und dann läuft es viel schneller.

Jetzt ist es mir zu mühsam geworden und ich habe der Datei einfach alle Schreibrechte entzogen:

chmod -w /etc/resolv.conf

Wird das was Schlimmes anrichten?

Fremder

(Fedora Core 2)
 
OP
gelbeseiten

gelbeseiten

Newbie
hallo fremder,


das ist ja auch keine problemlösung, oder? wenn an deinem wagen was klappert, machst du das radio dann auch lauter?:)


ich würde erstmal in die logs gucken, was denn für fehlermeldungen kommen.

tail -f /var/log/messages
gleich nach dem neustart am besten.

dann nach der fehlermeldung hier oder bei google suchen.

hast du denn mal die dinge die hier schon gepostet wurden ausprobiert?

siehe den eintag von pc-ulf oder meinen letzten eintrag.

wenn du nicht weiterkommst melde dich


gruss


volkmar
 
OK, das ist natürlich keine saubere Lösung, außerdem hat Linux da auch was dagegen :oops:

Nach dem Neustart:

1. keine Fehlermeldung in /var/log/messages
2. die Datei /etc/resolv.conf hat wieder Schreibrechte für root
3. wieder der Eintrag "nameserver 192.168.0.1".....

So, werde jetzt doch der Ursache auf den Grund gehen müssen.....

Melde mich, mit dem Ergebnis

Fremder
 
Also, die /etc/resolv.conf enthält nach einem Neustart immer folgendes:
; generated by /sbin/dhclient-script
nameserver 192.168.0.1
search localdomain
Ich habe daraufhin nach dem dhclient-script hier im Forum und bei Google gesucht und herausgefunden, dass es wahrscheinlich bein Bug sein soll http://www.linuxquestions.org/questions/history/186104
(ganz unten)

Leider verstehe ich nicht, wie ich die Lösung umsetzen soll
So I installed unstable which gave me the dhcp3 version of things and everything is happy in debian land again.

Stranger

Fedora Core 2
 

na-cx

Hacker
Ganz einfach:

Code:
vi /etc/sysconfig/network/config

Bei Zeile 54 findet man folgenden Eintrag:
Code:
MODIFY_RESOLV_CONF_DYNAMICALLY="yes"
(Zeilenangabe SuSE 9.2 Professional)

Einfach das "yes" auf "no" setzen.
Alle Verbindungen trennen.

Code:
# rcnetwork restart
eingeben.

Fertig.
 
Hat leider nicht funktioniert.

Das scheint bei Fedora C2 doch ganz anders aufgebaut zu sein als bei SuSE (habe auch einen SuSE-Rechner und dort ließ sich Dein Vorschlag nachvollziehen)

Bei Fedora endet/verzweigt sich der Pfad /etc/sysconfig/ in die Ordner
- apm-scripts
- console
- networking
- networking-scripts
- rhn

u. a. findet sich in diesen Dateien der Text "resolv.conf" wieder:
file:/etc/sysconfig/network-scripts/ifdown-post
file:/etc/sysconfig/network-scripts/ifup
file:/etc/sysconfig/network-scripts/ifup-post
file:/etc/sysconfig/network-scripts/ifup-ppp
file:/etc/sysconfig/network-scripts/network-functions
Es sind allem Anschein nach alles Scripts, die auch schreibend auf die resol.conf zugreifen.

Eine Konfigurationsdatei mit einem Eintrag MODIFY_RESOLV_CONF_DYNAMICALLY="yes" oder so ähnlich konnte ich nicht finden.

Ich konnte aber eine Datei mit dem Namen /usr/share/doc/dhclient-3.0.1rc14/dhclient.conf.sample
finden. Sie enthält folgendes:
send host-name "andare.fugue.com";
send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
send dhcp-lease-time 3600;
supersede domain-name "fugue.com home.vix.com";
prepend domain-name-servers 127.0.0.1;
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name;
require subnet-mask, domain-name-servers;
timeout 60;
retry 60;
reboot 10;
select-timeout 5;
initial-interval 2;
script "/etc/dhclient-script";
media "-link0 -link1 -link2", "link0 link1";
reject 192.33.137.209;

alias {
interface "ep0";
fixed-address 192.5.5.213;
option subnet-mask 255.255.255.255;
}

lease {
interface "ep0";
fixed-address 192.33.137.200;
medium "link0 link1";
option host-name "andare.swiftmedia.com";
option subnet-mask 255.255.255.0;
option broadcast-address 192.33.137.255;
option routers 192.33.137.250;
option domain-name-servers 127.0.0.1;
renew 2 2000/1/12 00:00:01;
rebind 2 2000/1/12 00:00:01;
expire 2 2000/1/12 00:00:01;
}
Ist hier vielleicht etwas zu konfigurieren?? Ich kann leider mit den Einträgen nichts anfangen....
 
OK, das war´s, jetzt geht´s :p

Habe in der /sbin/dhclient-script alle Zeilen in der Funktion make_resolv_conf auskommentiert. nur die Zeile

make_resolv_conf{
und die schließende
}

nicht.

Dann habe ich meine nameserver in die /etc/resolv.conf eingetragen und getestet: Sind auch nach einem Reboot noch da

Danke für die Hilfe

Fremder
 
zu früh gefreut :-((

die resolv.conf blieb zwar OK, meine Netzwerkverbindung ist nun nicht mehr da. Das Booten dauert auch an der Stelle mit der Netzwerk-Karte recht lange und dann steht in der

/var/log/messages und auch /var/log/boot.log:
(....)
Dec 9 13:51:32 localhost network: Interface etho hochfahren: failed

Habe die Änderung in der /sbin/dhclient-script wieder rückgängig gemacht und neu gebootet, die Netzwerkverbindung startet trotzdem nicht mehr....

/sbin/ifconfig gibt mir zwar eine eth0 mit den Angaben zu
-Protokoll:Eternet...
- inet6 Adresse
- ...
aus,

aber keine "inet Adresse".

Ist der dhclient kaputt?
Was soll ich prüfen, um den Fehler einzugrenzen?

Bin nach wie vor für Hilfe dankbar

Fremder
 
Hier nun doch noch die Lösung:

1. Fehler: Ich hatte gestern(!) die Datei /etc/dhclient.conf erstellt, in der Hoffung, dass dies gegen mein Problem helfen würde - hat es aber nicht und ich habe vergessen, die Datei zu löschen.

2. Nachdem ich eben die /etc/dhclient.conf entfernt habe (die /sbin/dhclient-script hatte wieder den Originalzustand = nichts auskommentiert) startete die Netzwerkverbindung wieder.

3. Dann habe ich versuchsweise Zeilen in der /sbin/dhclient-script auskommentiert und jedesmal neu gebootet (regebootet oder ge-rebootet?). Jetzt startet das Netzwerk und die resolv.conf bleibt wie sie von mir erstellt ist. Meine /sbin/dhclient-script sieht nun so aus:
Code:
(...)
make_resolv_conf() {
  if [ "${PEERDNS}" == "no" ]; then
      return
  fi

  if [ x$reason == xRENEW ]; then
      if [ "$new_domain_name" == "$old_domain_name" ] && [ "$new_domain_servers" == "$old_domain_servers"
]; then
          return
      fi
  fi

#  if [ -n "$new_domain_name" ] || [ -n "$new_domain_name_servers" ]; then
#    save_previous /etc/resolv.conf
#    echo '; generated by /sbin/dhclient-script' > /etc/resolv.conf
#    if [ -n "$SEARCH" ]; then
#       echo search $SEARCH >> /etc/resolv.conf
#    else
#       if [ -n "$new_domain_name" ]; then
#           echo search $new_domain_name >> /etc/resolv.conf
#        fi
#    fi
#    chmod 644 /etc/resolv.conf
#    for nameserver in $new_domain_name_servers; do
#      echo nameserver $nameserver >>/etc/resolv.conf
#    done
#  fi
}
(...)

hoffe, dass ich nun von Spätwirkungen dieser Änderung verschont bleibe....
 
Oben