Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Welcher Menschenhasser hat sich resolvconf ausgedacht?
1,349 views
Skip to first unread message
Christian Brandt
Apr 1, 2012, 3:23:43 AM4/1/12
to
Welcher abgrundtief Menschenhasser hat sich resolvconf ausgedacht?
Was wollte ich machen: Ein Rechner mit statischer IP-Adresse sollte
selbst Slave-Nameserver für ein kleines Netz spielen. Unter uns, es
macht ja wenig Sinn sowas auf einer dynamischen IP-Adresse zu betreiben.
Also trägt man in /etc/network/interface eben wie seit 15 Jahren ein
iface eth0 inet static uswusf ein.
Hoppla, /etc/resolv.conf wird jetzt bei jedem Neustart mit einem leeren
Template überschrieben weil ja der dhcp wegen isnich nixda zurückliefert.
Ein paar Try&Error&Copy&Paste-Admins schlagen daher ernsthaft vor mit
chattr -i diese Datei vor Änderungen zu schützen. Wie die wohl einen
Prozeß vor unbefugtem Lesezugriff schützen? Mit chmod a-r /dev/kmem?
Naja, wie haben wir es früher gemacht? Eben, aptitude remove resolvconf.
Hoppla, Ubuntu 12.04 ist da der Meinung daß damit das Paket
ubuntu-minimal verschwinden muß. Achja und im gleichem Aufwasch auch
noch die nicht länger genutzten Pakete adduser, apt, apt-utils, bzip2,
console-setup, debconf, debconf-i18n, eject, gnupg, ifupdown uswusf...
nebenbei, Debian unstable war auch der Meinung daß der Verzicht auf
resolvconf auch gleich passwd entsorgen sollte aber immerhin bzip hätte
es mir weiter gegönnt.
Naja, bevor ich jetzt mit Paketpinning usw anfange, wirklich elegant
ist der Verzicht auf resolvconf ja dann doch nicht. Da gibts sicher
irgendwo einen Schalter "resolvconf=off" oder so.
Haha, weit gefehlt. Solange man nicht direkt "Do-not-Edit" Initscripte
editiert - und zwar sehr, sehr viele - kann man resolvconf praktisch
nicht bändigen. Ja, man könnte in /sbin/resolvconf in die zweite Zeile
"echo maultierkacke && exit 0" einbauen oder es auf /bin/true umbiegen.
Alles andere? Da kann ich gleich Bind9 auf Plan9 portieren.
Hm, also schauen wir mal in die Anleitung von resolvconf... es gibt ja noch:
/etc/resolvconf/resolv.conf.d/base
/etc/resolvconf/resolv.conf.d/head
Toll, Anleitung rät meine Nameserver in base einzutragen.
Nix.
Wird nicht ausgewertet.
Dann head.
Ja, jetzt wirkts. Aber doppelt, denn auf einmal übernimmt resolvconf von
irgendwoher uralte Einträge und hängt sie an die neuen an.
Ok, wieder raus aus head.
Hoppla, jetzt sind auch die alten weg.
Noch ein paarmal probiert, Verhalten bleibt.
Irgendwie ist das ganze Zeug unter /etc/resolvconf/resolv.conf.d/ eher
fürn Arsch. Also weiter.
Viele Anwender schlagen vor man solle mit superseeds in der dhcp.conf
arbeiten und noch mehr wundern sich warum das nicht geht. Ja, das könnte
daran liegen daß alle die das Vorschlagen und alle die das ausprobieren
ja mit statischen Adressen arbeiten, da läuft kein dhcp also wie soll
dhcp diese manuellen Adressen an resolvconf übergeben?
<karnevalstusch>tata-tata-tata</karnevalstusch>
Ok, lesen wir nochmal die spärliche resolvconf-Anleitung. Achja, da kann
man ja auch alles in die /etc/network/interfaces eintragen, das klingt
ja fast schon zu elegant um wahr zu sein. Isses aber nich... damit hat
man dann z.B. keine Nameserver in der resolv.conf wenn das entsprechende
Interface grade weg ist - aber wer will Nameserver wenn das Interface
weg ist? Tja, da man das Statement nur einmal effektiv in der Konfig
verwenden kann muß man mehrere Nameserver auf diesem Statement angeben,
auch für Nameserver auf anderen Interfaces. Und schalte ich jetzt mal
kurz eth1 aus ist auch die Nameserverdefinition für Nameserver an eth0
weg. tata-tata-tata
Aber ok, wollen wir mal nicht so sein. Dann darf halt keiner die
Interfaces runterfahren. Ich komm mir dann zwar vor wie anno tobak auf
AmiTCP (Ethernetdevice runterfahren während Nutzung: GURU MEDITATION)...
Tragen wir mal ein dns-nameservers 127.0.0.1 10.1.2.3
Nö.
Nach Reboot steht in der resolv.conf: nameserver 127.0.0.1
Die Werte noch ein wenig herumgespielt: Es bleibt immer bei der
127.0.0.1 - kann ja keiner mit rechnen daß jemand einen externen
Nameserver verwenden will, oder? tata-tata-tata
Am Rande der Verzweiflung greppe ich wild in /etc/ herum... und finde in
/etc/default/bind9: RESOLVCONF=yes
Hä?
Wieso kontrolliert bind9 den Aufruf von resolvconf? Kontrolliert Firefox
demnächst USB-Hotplugging?
Haha, da hätte mich der bind9-Packetmaintainer fast ranbekommen...
Natürlich kontrolliert bind9 NICHT resolvconf. Der Spaßvogel hat einfach
nur die Variable saudämmlich benannt. Die regelt nämlich - und das ist
fast noch besser, festhalten, jetzt kommst - die regelt nämlich daß
sämtliche anderweitig irgendwie ermittelten Nameserver mit 127.0.0.1 in
der /etc/init/bind9 mittels resolvconf überschrieben werden.
Ok, fassen wir das nochmal zusammen: Die Standardeinstellung dieses
Nameserver ist derart daß die Nutzung dieses Nameservers in seiner
eigentlichen Aufgabe konterkarriert wird indem andere Nameserver erstmal
ausgeblendet werden so daß man im Wartungsfall am lokalem Nameserver
erstmal garnichtsmehr mit Namen ansprechen kann. Nun, als optionale
Option für Katertage mag das sicher fürn Lacher gut sein aber als
Standardeinstellung ist das echt ein Brüllwitz über den ich noch in 20
Jahren lachen werde. tata-tata-tata
Also schalten wir diesen Dummfug mittels RESOLVCONF=no ab.
Und restarten.
Und habe immer noch als einzigen Nameserver die 127.0.0.1.
Ja, diesesmal wars meine Schuld. Ich hatte in der
/etc/network/interfaces echt einfach nur eine 127.0.0.1 angegeben. Also
10.0.12.1 rein. Neustart.
Und habe immer noch als einzigen Nameserver die 127.0.0.1.
Ok, was soll das jetzt? Ist das Drecksscheißinitscript etwas auch noch
so kaputt daß es die =no nicht korrekt auswertet? Debug-Breaks ins
Script, durchlauf, ne, eigentlich verzweigt alles richtig. resolvconf
bekommt alles so wie es das verlangt.
Oh mein Gott.
Das kann doch echt nicht sein.
Macht resolvconf etwa auch irgendwelche 127.0.0.1-Sondermaultierkacke?
grep 127 /sbin/resolvconf - ne.
vi /sbin/resolvconf und mal alles gaaaaaanz langsam durchlesen. Nach 60%
stolpere ich über eine Variable
TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS die bewirkt daß sie bei
nicht-"no" alles nach dem ersten 127er Wert abschneidet. Ooookay... Wir
haben also nicht nur ein bind-Init-Script was meint besser zu wissen was
ich will als ich selber, nein, das freche resolvconf-Script trifft genau
die gleiche total falsche Vermutung ins Blaue.
Also wo kann ich TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS setzen?
grep -r TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS /etc/
/usr/share/doc/resolvconf liefert: Nichts. Diese Variable wird zwar in
/sbin/resolvconf referenziert aber niemals irgendwo mit einer Silbe
erwähnt. Also schauen wir mal was die Jungs so alles includen und voila,
/etc/default/resolvconf wird included. Nochmal grep -r
default.resolvconf /... und: nichts. Die Datei existiert natürlich noch
nicht und ist auch nirgends referenziert. Kennen tut das nichtmal das
Internet und das Internet weis alles. Immerhin wäre jetzt belegt daß
Rule34 NICHT gilt, Pornobilder von /etc/default/resolvconf gibts nicht,
wirds nie geben und mal ehrlich, wer will das?
Sooo... jetzt schnell ein echo
"TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS=no"
>/etc/default/resolvconf und /etc/default/bind9 RESOLVCONF=no und die
manuellen Debuggingänderungen in /etc/init/bind9 und /sbin/resolvconf
raus und die korrekten Nameserver in /etc/network/interfaces eintragen
und voila:
Es geht.
Oder?
Doch, echt.
Es geht.
Ich glaube ich habe gerade Stoff für mindestens ein Dutzend Designfixes
gesammelt.
Wie lob ich mir da ein gutes altes BSD-Style-Startup, in /etc/rc einfach
ein ifconfig xy 1.2.3.4 up und gut isses... was ist daran bitte
komplizierter als an einem superbequemen Ubuntu?
Christian Brandt
Was wollte ich machen: Ein Rechner mit statischer IP-Adresse sollte
selbst Slave-Nameserver für ein kleines Netz spielen. Unter uns, es
macht ja wenig Sinn sowas auf einer dynamischen IP-Adresse zu betreiben.
Also trägt man in /etc/network/interface eben wie seit 15 Jahren ein
iface eth0 inet static uswusf ein.
Hoppla, /etc/resolv.conf wird jetzt bei jedem Neustart mit einem leeren
Template überschrieben weil ja der dhcp wegen isnich nixda zurückliefert.
Ein paar Try&Error&Copy&Paste-Admins schlagen daher ernsthaft vor mit
chattr -i diese Datei vor Änderungen zu schützen. Wie die wohl einen
Prozeß vor unbefugtem Lesezugriff schützen? Mit chmod a-r /dev/kmem?
Naja, wie haben wir es früher gemacht? Eben, aptitude remove resolvconf.
Hoppla, Ubuntu 12.04 ist da der Meinung daß damit das Paket
ubuntu-minimal verschwinden muß. Achja und im gleichem Aufwasch auch
noch die nicht länger genutzten Pakete adduser, apt, apt-utils, bzip2,
console-setup, debconf, debconf-i18n, eject, gnupg, ifupdown uswusf...
nebenbei, Debian unstable war auch der Meinung daß der Verzicht auf
resolvconf auch gleich passwd entsorgen sollte aber immerhin bzip hätte
es mir weiter gegönnt.
Naja, bevor ich jetzt mit Paketpinning usw anfange, wirklich elegant
ist der Verzicht auf resolvconf ja dann doch nicht. Da gibts sicher
irgendwo einen Schalter "resolvconf=off" oder so.
Haha, weit gefehlt. Solange man nicht direkt "Do-not-Edit" Initscripte
editiert - und zwar sehr, sehr viele - kann man resolvconf praktisch
nicht bändigen. Ja, man könnte in /sbin/resolvconf in die zweite Zeile
"echo maultierkacke && exit 0" einbauen oder es auf /bin/true umbiegen.
Alles andere? Da kann ich gleich Bind9 auf Plan9 portieren.
Hm, also schauen wir mal in die Anleitung von resolvconf... es gibt ja noch:
/etc/resolvconf/resolv.conf.d/base
/etc/resolvconf/resolv.conf.d/head
Toll, Anleitung rät meine Nameserver in base einzutragen.
Nix.
Wird nicht ausgewertet.
Dann head.
Ja, jetzt wirkts. Aber doppelt, denn auf einmal übernimmt resolvconf von
irgendwoher uralte Einträge und hängt sie an die neuen an.
Ok, wieder raus aus head.
Hoppla, jetzt sind auch die alten weg.
Noch ein paarmal probiert, Verhalten bleibt.
Irgendwie ist das ganze Zeug unter /etc/resolvconf/resolv.conf.d/ eher
fürn Arsch. Also weiter.
Viele Anwender schlagen vor man solle mit superseeds in der dhcp.conf
arbeiten und noch mehr wundern sich warum das nicht geht. Ja, das könnte
daran liegen daß alle die das Vorschlagen und alle die das ausprobieren
ja mit statischen Adressen arbeiten, da läuft kein dhcp also wie soll
dhcp diese manuellen Adressen an resolvconf übergeben?
<karnevalstusch>tata-tata-tata</karnevalstusch>
Ok, lesen wir nochmal die spärliche resolvconf-Anleitung. Achja, da kann
man ja auch alles in die /etc/network/interfaces eintragen, das klingt
ja fast schon zu elegant um wahr zu sein. Isses aber nich... damit hat
man dann z.B. keine Nameserver in der resolv.conf wenn das entsprechende
Interface grade weg ist - aber wer will Nameserver wenn das Interface
weg ist? Tja, da man das Statement nur einmal effektiv in der Konfig
verwenden kann muß man mehrere Nameserver auf diesem Statement angeben,
auch für Nameserver auf anderen Interfaces. Und schalte ich jetzt mal
kurz eth1 aus ist auch die Nameserverdefinition für Nameserver an eth0
weg. tata-tata-tata
Aber ok, wollen wir mal nicht so sein. Dann darf halt keiner die
Interfaces runterfahren. Ich komm mir dann zwar vor wie anno tobak auf
AmiTCP (Ethernetdevice runterfahren während Nutzung: GURU MEDITATION)...
Tragen wir mal ein dns-nameservers 127.0.0.1 10.1.2.3
Nö.
Nach Reboot steht in der resolv.conf: nameserver 127.0.0.1
Die Werte noch ein wenig herumgespielt: Es bleibt immer bei der
127.0.0.1 - kann ja keiner mit rechnen daß jemand einen externen
Nameserver verwenden will, oder? tata-tata-tata
Am Rande der Verzweiflung greppe ich wild in /etc/ herum... und finde in
/etc/default/bind9: RESOLVCONF=yes
Hä?
Wieso kontrolliert bind9 den Aufruf von resolvconf? Kontrolliert Firefox
demnächst USB-Hotplugging?
Haha, da hätte mich der bind9-Packetmaintainer fast ranbekommen...
Natürlich kontrolliert bind9 NICHT resolvconf. Der Spaßvogel hat einfach
nur die Variable saudämmlich benannt. Die regelt nämlich - und das ist
fast noch besser, festhalten, jetzt kommst - die regelt nämlich daß
sämtliche anderweitig irgendwie ermittelten Nameserver mit 127.0.0.1 in
der /etc/init/bind9 mittels resolvconf überschrieben werden.
Ok, fassen wir das nochmal zusammen: Die Standardeinstellung dieses
Nameserver ist derart daß die Nutzung dieses Nameservers in seiner
eigentlichen Aufgabe konterkarriert wird indem andere Nameserver erstmal
ausgeblendet werden so daß man im Wartungsfall am lokalem Nameserver
erstmal garnichtsmehr mit Namen ansprechen kann. Nun, als optionale
Option für Katertage mag das sicher fürn Lacher gut sein aber als
Standardeinstellung ist das echt ein Brüllwitz über den ich noch in 20
Jahren lachen werde. tata-tata-tata
Also schalten wir diesen Dummfug mittels RESOLVCONF=no ab.
Und restarten.
Und habe immer noch als einzigen Nameserver die 127.0.0.1.
Ja, diesesmal wars meine Schuld. Ich hatte in der
/etc/network/interfaces echt einfach nur eine 127.0.0.1 angegeben. Also
10.0.12.1 rein. Neustart.
Und habe immer noch als einzigen Nameserver die 127.0.0.1.
Ok, was soll das jetzt? Ist das Drecksscheißinitscript etwas auch noch
so kaputt daß es die =no nicht korrekt auswertet? Debug-Breaks ins
Script, durchlauf, ne, eigentlich verzweigt alles richtig. resolvconf
bekommt alles so wie es das verlangt.
Oh mein Gott.
Das kann doch echt nicht sein.
Macht resolvconf etwa auch irgendwelche 127.0.0.1-Sondermaultierkacke?
grep 127 /sbin/resolvconf - ne.
vi /sbin/resolvconf und mal alles gaaaaaanz langsam durchlesen. Nach 60%
stolpere ich über eine Variable
TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS die bewirkt daß sie bei
nicht-"no" alles nach dem ersten 127er Wert abschneidet. Ooookay... Wir
haben also nicht nur ein bind-Init-Script was meint besser zu wissen was
ich will als ich selber, nein, das freche resolvconf-Script trifft genau
die gleiche total falsche Vermutung ins Blaue.
Also wo kann ich TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS setzen?
grep -r TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS /etc/
/usr/share/doc/resolvconf liefert: Nichts. Diese Variable wird zwar in
/sbin/resolvconf referenziert aber niemals irgendwo mit einer Silbe
erwähnt. Also schauen wir mal was die Jungs so alles includen und voila,
/etc/default/resolvconf wird included. Nochmal grep -r
default.resolvconf /... und: nichts. Die Datei existiert natürlich noch
nicht und ist auch nirgends referenziert. Kennen tut das nichtmal das
Internet und das Internet weis alles. Immerhin wäre jetzt belegt daß
Rule34 NICHT gilt, Pornobilder von /etc/default/resolvconf gibts nicht,
wirds nie geben und mal ehrlich, wer will das?
Sooo... jetzt schnell ein echo
"TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS=no"
>/etc/default/resolvconf und /etc/default/bind9 RESOLVCONF=no und die
manuellen Debuggingänderungen in /etc/init/bind9 und /sbin/resolvconf
raus und die korrekten Nameserver in /etc/network/interfaces eintragen
und voila:
Es geht.
Oder?
Doch, echt.
Es geht.
Ich glaube ich habe gerade Stoff für mindestens ein Dutzend Designfixes
gesammelt.
Wie lob ich mir da ein gutes altes BSD-Style-Startup, in /etc/rc einfach
ein ifconfig xy 1.2.3.4 up und gut isses... was ist daran bitte
komplizierter als an einem superbequemen Ubuntu?
Christian Brandt
Ulrich M. Schwarz
Apr 1, 2012, 3:56:29 AM4/1/12
to
On Sun, 01 Apr 2012 09:23:43 +0200, Christian Brandt <bra...@psi5.com>
wrote:
> Kontrolliert Firefox demnächst USB-Hotplugging?
Ich wage mal, das "demnächst" zu bezweifeln. Genau wissen will ich's
aber nicht wirklich.
[Odyssee durch e-t-c]
Parallel-Start-System.
> Wie lob ich mir da ein gutes altes BSD-Style-Startup, in /etc/rc einfach
> ein ifconfig xy 1.2.3.4 up und gut isses... was ist daran bitte
> komplizierter als an einem superbequemen Ubuntu?
Ubuntu ist DWIM: "Doesn't Work If Modified".
Da gibt's bestimmt noch ein paar Buzzwords mehr, mit denen man das
garnieren
kann, und ein Pattern dafür. (Rückwirkende Konfigurations-Anpassung? Die
ganze
Geschichte wäre dann RKA-lich, das pläsiert.)
Ulrich
(Wer ist im Augenblick dran mit Leuten-ein-Alibi-geben?)
wrote:
> Kontrolliert Firefox demnächst USB-Hotplugging?
Ich wage mal, das "demnächst" zu bezweifeln. Genau wissen will ich's
aber nicht wirklich.
[Odyssee durch e-t-c]
> Ich glaube ich habe gerade Stoff für mindestens ein Dutzend Designfixes
> gesammelt.
Da fehlte eigentlich noch eine falsche Abhängigkeit im randomisierten
> gesammelt.
Parallel-Start-System.
> Wie lob ich mir da ein gutes altes BSD-Style-Startup, in /etc/rc einfach
> ein ifconfig xy 1.2.3.4 up und gut isses... was ist daran bitte
> komplizierter als an einem superbequemen Ubuntu?
Da gibt's bestimmt noch ein paar Buzzwords mehr, mit denen man das
garnieren
kann, und ein Pattern dafür. (Rückwirkende Konfigurations-Anpassung? Die
ganze
Geschichte wäre dann RKA-lich, das pläsiert.)
Ulrich
(Wer ist im Augenblick dran mit Leuten-ein-Alibi-geben?)
Paul Muster
Apr 1, 2012, 3:49:51 AM4/1/12
to
On 01.04.2012 09:23, Christian Brandt wrote:
> Ich glaube ich habe gerade Stoff für mindestens ein Dutzend Designfixes
> gesammelt.
Sieht so aus. Nun stellt sich nur noch die Frage, ob man die vor oder
> Ich glaube ich habe gerade Stoff für mindestens ein Dutzend Designfixes
> gesammelt.
nach einem Sonn(!)tagsspaziergang eintütet.
Danke für die ausführliche Erläuterung. Der nächste, der das Problem
hat, wird dir sehr dankbar sein.
mfG Paul
Volker Birk
Apr 1, 2012, 5:21:34 AM4/1/12
to
In de.alt.sysadmin.recovery Christian Brandt <bra...@psi5.com> wrote:
> Hoppla, /etc/resolv.conf wird jetzt bei jedem Neustart mit einem leeren
> Template überschrieben weil ja der dhcp wegen isnich nixda zurückliefert.
Wieso betreibst Du einen DHCP-Klienten, wenn Du keinen brauchst?
> Hoppla, /etc/resolv.conf wird jetzt bei jedem Neustart mit einem leeren
> Template überschrieben weil ja der dhcp wegen isnich nixda zurückliefert.
> Naja, wie haben wir es früher gemacht? Eben, aptitude remove resolvconf.
VB.
--
"If /dev/null is fast in web scale I will use it."
http://www.mongodb-is-web-scale.com/
Volker Birk
Apr 1, 2012, 5:24:05 AM4/1/12
to
In de.alt.sysadmin.recovery Paul Muster <exp-3...@news.muster.de1.cc> wrote:
> Danke für die ausführliche Erläuterung. Der nächste, der das Problem
> hat, wird dir sehr dankbar sein.
Hoffentlich fällt keiner, der das liest, auf diesen Schwachsinn rein.
> Danke für die ausführliche Erläuterung. Der nächste, der das Problem
> hat, wird dir sehr dankbar sein.
Oh, moment: in Deinem Falle ist das ja schon passiert.
Nochmal zum Mitmeisseln: was der lustige OP eigentlich hätte machen
sollen, wäre das Entfernen (oder wenigstens stoppen) des DHCP-Clients
gewesen.
Viele Grüsse,
Juergen Ilse
Apr 1, 2012, 8:01:45 AM4/1/12
to
Hallo,
In de.comp.os.unix.networking.misc Christian Brandt <bra...@psi5.com> wrote:
> Welcher abgrundtief Menschenhasser hat sich resolvconf ausgedacht?
Nicht resolv.conf ist das Problem, sondern Software, die diese Datei
zu ueberschreiben/ersetzen zu versucht (zumindest dann, wenn man vorhat
einen chache-only DNS auf dem lokalen Rechner laufen zu lassen ...).
> Was wollte ich machen: Ein Rechner mit statischer IP-Adresse sollte
> selbst Slave-Nameserver für ein kleines Netz spielen. Unter uns, es
> macht ja wenig Sinn sowas auf einer dynamischen IP-Adresse zu betreiben.
Wenn dieser Rechner im lokalen Netz DNS sein soll, warum laesst du dann
nicht seine Adresse per DHCP auch als DNS-Server verteilen? Dann waerst
du mit dem Thema durch ...
> Also trägt man in /etc/network/interface eben wie seit 15 Jahren ein
> iface eth0 inet static uswusf ein.
> Hoppla, /etc/resolv.conf wird jetzt bei jedem Neustart mit einem leeren
> Template überschrieben weil ja der dhcp wegen isnich nixda zurückliefert.
Warum laesst du deinen DHCP-Server nicht die Information verteilen,
welche IP-Adresse dein DNS im lokalen Netz hat?
> Ein paar Try&Error&Copy&Paste-Admins schlagen daher ernsthaft vor mit
> chattr -i diese Datei vor Änderungen zu schützen. Wie die wohl einen
> Prozeß vor unbefugtem Lesezugriff schützen? Mit chmod a-r /dev/kmem?
Wie waere es mit der Lektuere von "man resolvconf" (das AFAIK fuer die
Aenderung der resolvconf verantwortlich ist)?
> Naja, wie haben wir es früher gemacht? Eben, aptitude remove resolvconf.
... und dann wird die etliches weitere mitbeseitigt ... Kannst du auf
den Kram dann wirklich vollstaendig verzichten?
> Hoppla, Ubuntu 12.04 ist da der Meinung daß damit das Paket
> ubuntu-minimal verschwinden muß. Achja und im gleichem Aufwasch auch
> noch die nicht länger genutzten Pakete adduser, apt, apt-utils, bzip2,
> console-setup, debconf, debconf-i18n, eject, gnupg, ifupdown uswusf...
> nebenbei, Debian unstable war auch der Meinung daß der Verzicht auf
> resolvconf auch gleich passwd entsorgen sollte aber immerhin bzip hätte
> es mir weiter gegönnt.
Viel nerviger finde ich in aktuellen Versionen des Networkmanagers die
Zwangsbundelung mit dnsmasq, an der man auch nur schwer bis gar nicht
vorbei kommt (was fuer ein Schwachsinn) ... Gluecklicherweise laesst
sich dieser Unfug durch Anpassung der /etc/NetworkManager/NetworkManager.conf
mit anschliessendem Neustart des NetworkManagers abstellen ...
> Naja, bevor ich jetzt mit Paketpinning usw anfange, wirklich elegant
> ist der Verzicht auf resolvconf ja dann doch nicht. Da gibts sicher
> irgendwo einen Schalter "resolvconf=off" oder so.
... den du vermutlich mittels Lektuere der zugehoerigen man-page
gefunden haettest ... Warum nicht einfach das Problem umschiffen,
indem du deinen DHCP deinen DNS bekanntgeben laesst?
> Haha, weit gefehlt. Solange man nicht direkt "Do-not-Edit" Initscripte
> editiert - und zwar sehr, sehr viele - kann man resolvconf praktisch
> nicht bändigen.
Falsch. Nach einem "resolvconf --disable-updates" wird die resolv.conf
nicht mehr ueberschrieben, so dass manuelle Aenderungen auch erhalten
bleiben, wie man der man-page leicht entnehmen kann.
> Ja, man könnte in /sbin/resolvconf in die zweite Zeile
> "echo maultierkacke && exit 0" einbauen oder es auf /bin/true umbiegen.
> Alles andere? Da kann ich gleich Bind9 auf Plan9 portieren.
Was nicht unbedingt so schwierig sein muss ...
> Hm, also schauen wir mal in die Anleitung von resolvconf... es gibt ja noch:
> /etc/resolvconf/resolv.conf.d/base
> /etc/resolvconf/resolv.conf.d/head
Anleitung wie in "Hacker-Tips von Leuten, die keine manpages lesen"?
> Toll, Anleitung rät meine Nameserver in base einzutragen.
> Nach Reboot steht in der resolv.conf: nameserver 127.0.0.1
... und zwar weil ein dnsmasqd als lokaler DNS-Cache gestartet wird.
Hast du noch nicht einmal das bemerkt? Und dieser Unfug laesst sich
nach Lektuere von NetworkManager.conf aus der Konfigurationsdatei
ausbauen (was dann nach einem Neustart des network-managers auch
tatsaechlich wirkt). Man kann Ubuntu vorwerfen, dass sie diese
Aenderungen an der NetworkManager.conf nicht gut genug dokumentiert
haben (dieser dnsmasqd-Quatsch ist echt nervig, solange man noch
nicht weiss, wie man den Mist abstellt), aber sonst liegen deine
Fehler in erster Linie darin, herumzupfuschen statt *zuerst* die
zugehoerigen man-pages zu lesen.
> Die Werte noch ein wenig herumgespielt: Es bleibt immer bei der
> 127.0.0.1 - kann ja keiner mit rechnen daß jemand einen externen
> Nameserver verwenden will, oder? tata-tata-tata
Der vom lokalen DNS-Cache verwendete Forwarder wird dann umkonfiguriert.
Das geschieht durch das NetworkManager-Plugin, das durch "dns=dnsmasq"
in der Konfigurationsdatei aktiviert wird.
> Ok, fassen wir das nochmal zusammen:
Du hast keine Ahnung, wie die Pakete zusammenhaengen und hat dir noch
nicht einmal die Muehe gemacht, die man-pages zu lesen, stattdessen
hast du wild an irgendwelchen Dateien herumgepatched und deinen Unmut
darueber, dass dieses Vorgehen nicht funktionierte ins Usenet geblasen.
Trifft das in etwa den Sachverhalt? Ich denke ja.
> Ich glaube ich habe gerade Stoff für mindestens ein Dutzend Designfixes
> gesammelt.
Vor allem hat du dich (nicht nur einmal) zum Brot gemacht, weil du dich
lieber durch kilometerweise scripte wuehlst, statt einfach ein paar man-
pages zu lesen ("man resolvconf", "man NetworkManager.conf", ...).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
In de.comp.os.unix.networking.misc Christian Brandt <bra...@psi5.com> wrote:
> Welcher abgrundtief Menschenhasser hat sich resolvconf ausgedacht?
zu ueberschreiben/ersetzen zu versucht (zumindest dann, wenn man vorhat
einen chache-only DNS auf dem lokalen Rechner laufen zu lassen ...).
> Was wollte ich machen: Ein Rechner mit statischer IP-Adresse sollte
> selbst Slave-Nameserver für ein kleines Netz spielen. Unter uns, es
> macht ja wenig Sinn sowas auf einer dynamischen IP-Adresse zu betreiben.
nicht seine Adresse per DHCP auch als DNS-Server verteilen? Dann waerst
du mit dem Thema durch ...
> Also trägt man in /etc/network/interface eben wie seit 15 Jahren ein
> iface eth0 inet static uswusf ein.
> Hoppla, /etc/resolv.conf wird jetzt bei jedem Neustart mit einem leeren
> Template überschrieben weil ja der dhcp wegen isnich nixda zurückliefert.
welche IP-Adresse dein DNS im lokalen Netz hat?
> Ein paar Try&Error&Copy&Paste-Admins schlagen daher ernsthaft vor mit
> chattr -i diese Datei vor Änderungen zu schützen. Wie die wohl einen
> Prozeß vor unbefugtem Lesezugriff schützen? Mit chmod a-r /dev/kmem?
Aenderung der resolvconf verantwortlich ist)?
> Naja, wie haben wir es früher gemacht? Eben, aptitude remove resolvconf.
den Kram dann wirklich vollstaendig verzichten?
> Hoppla, Ubuntu 12.04 ist da der Meinung daß damit das Paket
> ubuntu-minimal verschwinden muß. Achja und im gleichem Aufwasch auch
> noch die nicht länger genutzten Pakete adduser, apt, apt-utils, bzip2,
> console-setup, debconf, debconf-i18n, eject, gnupg, ifupdown uswusf...
> nebenbei, Debian unstable war auch der Meinung daß der Verzicht auf
> resolvconf auch gleich passwd entsorgen sollte aber immerhin bzip hätte
> es mir weiter gegönnt.
Zwangsbundelung mit dnsmasq, an der man auch nur schwer bis gar nicht
vorbei kommt (was fuer ein Schwachsinn) ... Gluecklicherweise laesst
sich dieser Unfug durch Anpassung der /etc/NetworkManager/NetworkManager.conf
mit anschliessendem Neustart des NetworkManagers abstellen ...
> Naja, bevor ich jetzt mit Paketpinning usw anfange, wirklich elegant
> ist der Verzicht auf resolvconf ja dann doch nicht. Da gibts sicher
> irgendwo einen Schalter "resolvconf=off" oder so.
gefunden haettest ... Warum nicht einfach das Problem umschiffen,
indem du deinen DHCP deinen DNS bekanntgeben laesst?
> Haha, weit gefehlt. Solange man nicht direkt "Do-not-Edit" Initscripte
> editiert - und zwar sehr, sehr viele - kann man resolvconf praktisch
> nicht bändigen.
nicht mehr ueberschrieben, so dass manuelle Aenderungen auch erhalten
bleiben, wie man der man-page leicht entnehmen kann.
> Ja, man könnte in /sbin/resolvconf in die zweite Zeile
> "echo maultierkacke && exit 0" einbauen oder es auf /bin/true umbiegen.
> Alles andere? Da kann ich gleich Bind9 auf Plan9 portieren.
> Hm, also schauen wir mal in die Anleitung von resolvconf... es gibt ja noch:
> /etc/resolvconf/resolv.conf.d/base
> /etc/resolvconf/resolv.conf.d/head
> Toll, Anleitung rät meine Nameserver in base einzutragen.
> Ja, das könnte daran liegen daß alle die das Vorschlagen und alle die
> das ausprobieren ja mit statischen Adressen arbeiten, da läuft kein dhcp
> also wie soll dhcp diese manuellen Adressen an resolvconf übergeben?
> <karnevalstusch>tata-tata-tata</karnevalstusch>
Statische IP-Adressen und DHCP schliessen sich nicht aus.
> das ausprobieren ja mit statischen Adressen arbeiten, da läuft kein dhcp
> also wie soll dhcp diese manuellen Adressen an resolvconf übergeben?
> <karnevalstusch>tata-tata-tata</karnevalstusch>
> Nach Reboot steht in der resolv.conf: nameserver 127.0.0.1
Hast du noch nicht einmal das bemerkt? Und dieser Unfug laesst sich
nach Lektuere von NetworkManager.conf aus der Konfigurationsdatei
ausbauen (was dann nach einem Neustart des network-managers auch
tatsaechlich wirkt). Man kann Ubuntu vorwerfen, dass sie diese
Aenderungen an der NetworkManager.conf nicht gut genug dokumentiert
haben (dieser dnsmasqd-Quatsch ist echt nervig, solange man noch
nicht weiss, wie man den Mist abstellt), aber sonst liegen deine
Fehler in erster Linie darin, herumzupfuschen statt *zuerst* die
zugehoerigen man-pages zu lesen.
> Die Werte noch ein wenig herumgespielt: Es bleibt immer bei der
> 127.0.0.1 - kann ja keiner mit rechnen daß jemand einen externen
> Nameserver verwenden will, oder? tata-tata-tata
Das geschieht durch das NetworkManager-Plugin, das durch "dns=dnsmasq"
in der Konfigurationsdatei aktiviert wird.
> Ok, fassen wir das nochmal zusammen:
nicht einmal die Muehe gemacht, die man-pages zu lesen, stattdessen
hast du wild an irgendwelchen Dateien herumgepatched und deinen Unmut
darueber, dass dieses Vorgehen nicht funktionierte ins Usenet geblasen.
Trifft das in etwa den Sachverhalt? Ich denke ja.
> Ich glaube ich habe gerade Stoff für mindestens ein Dutzend Designfixes
> gesammelt.
lieber durch kilometerweise scripte wuehlst, statt einfach ein paar man-
pages zu lesen ("man resolvconf", "man NetworkManager.conf", ...).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Juergen Ilse
Apr 1, 2012, 8:07:06 AM4/1/12
to
Hallo,
In de.comp.os.unix.networking.misc Volker Birk <bum...@dingens.org> wrote:
> In de.alt.sysadmin.recovery Paul Muster <exp-3...@news.muster.de1.cc> wrote:
>> Danke für die ausführliche Erläuterung. Der nächste, der das Problem
>> hat, wird dir sehr dankbar sein.
> Hoffentlich fällt keiner, der das liest, auf diesen Schwachsinn rein.
> Oh, moment: in Deinem Falle ist das ja schon passiert.
> Nochmal zum Mitmeisseln: was der lustige OP eigentlich hätte machen
> sollen, wäre das Entfernen (oder wenigstens stoppen) des DHCP-Clients
> gewesen.
... oder die statische Adresse seines DNS von seinem DHCP verbreiten lassen,
oder das updaten der /etc/resolv.conf durch das Paketresolvconf abstellen
und den Support des lokalen DNS-Cache durch den Networkmanager abstellen,
oder ...
Ja, diese Massnahmen waeren alles dokumentierte Loesungen seines Problems
gewesen, haetten aber u.U. die Lektuere der entsprechenden man-pages er-
fordert. Aber man-page lesen ist offenbar aus der Mode gekommen ...
In de.comp.os.unix.networking.misc Volker Birk <bum...@dingens.org> wrote:
> In de.alt.sysadmin.recovery Paul Muster <exp-3...@news.muster.de1.cc> wrote:
>> Danke für die ausführliche Erläuterung. Der nächste, der das Problem
>> hat, wird dir sehr dankbar sein.
> Hoffentlich fällt keiner, der das liest, auf diesen Schwachsinn rein.
> Oh, moment: in Deinem Falle ist das ja schon passiert.
> Nochmal zum Mitmeisseln: was der lustige OP eigentlich hätte machen
> sollen, wäre das Entfernen (oder wenigstens stoppen) des DHCP-Clients
> gewesen.
oder das updaten der /etc/resolv.conf durch das Paketresolvconf abstellen
und den Support des lokalen DNS-Cache durch den Networkmanager abstellen,
oder ...
Ja, diese Massnahmen waeren alles dokumentierte Loesungen seines Problems
gewesen, haetten aber u.U. die Lektuere der entsprechenden man-pages er-
fordert. Aber man-page lesen ist offenbar aus der Mode gekommen ...
Bernd Petrovitsch
Apr 1, 2012, 8:34:43 AM4/1/12
to
On Sun, 01 Apr 2012 09:24:05 +0000, Volker Birk wrote:
[...]
Andererseits: Warum überschreibt der DHCP-Client überhaupt
/etc/resolv.conf (und weiß-der-Geier-sonstnochwas), wenn der nicht
mal eine positive Antwort vom DHCP-Server bekommen hat?
Oder hab ich was mißverstanden?
Bernd
--
- Wie erkennt man IYO die offensichtlich ungeeigneten, hinter denen sich
nicht das Genie verbirgt?
- Wie erkennt man das Offensichtliche?
Martina Diel und Volker Birk
[...]
> Nochmal zum Mitmeisseln: was der lustige OP eigentlich hätte machen
> sollen, wäre das Entfernen (oder wenigstens stoppen) des DHCP-Clients
> gewesen.
Yup.
> sollen, wäre das Entfernen (oder wenigstens stoppen) des DHCP-Clients
> gewesen.
Andererseits: Warum überschreibt der DHCP-Client überhaupt
/etc/resolv.conf (und weiß-der-Geier-sonstnochwas), wenn der nicht
mal eine positive Antwort vom DHCP-Server bekommen hat?
Oder hab ich was mißverstanden?
Bernd
--
- Wie erkennt man IYO die offensichtlich ungeeigneten, hinter denen sich
nicht das Genie verbirgt?
- Wie erkennt man das Offensichtliche?
Martina Diel und Volker Birk
Juergen Ilse
Apr 1, 2012, 8:44:22 AM4/1/12
to
Hallo,
Bernd Petrovitsch <be...@tuxoid.at> wrote:
> On Sun, 01 Apr 2012 09:24:05 +0000, Volker Birk wrote:
> [...]
>> Nochmal zum Mitmeisseln: was der lustige OP eigentlich hätte machen
>> sollen, wäre das Entfernen (oder wenigstens stoppen) des DHCP-Clients
>> gewesen.
> Yup.
> Andererseits: Warum überschreibt der DHCP-Client überhaupt
> /etc/resolv.conf (und weiß-der-Geier-sonstnochwas), wenn der nicht
> mal eine positive Antwort vom DHCP-Server bekommen hat?
> Oder hab ich was mißverstanden?
Ja, hast du anscheinend. So wie ich ihn verstanden habe, hat der DHCP
geantwortet, in seiner Antwort aber keine DNS-Server zurueckgeliefert.
Das wurde dann von seinem System nicht (wie von ihm erwartet) als
"lass die DNS-Einstellungen wie sie sind" interpretiert, sondern als
"verwende keine DNS-Server", was dann zum loeschen der Eintraege in
/etc/resolv.conf fuehren wuerde ...
Darueber hinaus hatte er offenbar noch Probleme darin, dass der
Network-Manager neuerdings ein "dns Plugin" unterstuetzt, mit dem
dann ein "Cache-only-DNS" beim start der Netzwerkverbindung dazwischen-
gehaekelt wird (per Default wohl dnsmasqd), was dann immer zu den
"nameserver 127.0.0.1" Einstellungen in der resolv.conf fuehrt ...
Bernd Petrovitsch <be...@tuxoid.at> wrote:
> On Sun, 01 Apr 2012 09:24:05 +0000, Volker Birk wrote:
> [...]
>> Nochmal zum Mitmeisseln: was der lustige OP eigentlich hätte machen
>> sollen, wäre das Entfernen (oder wenigstens stoppen) des DHCP-Clients
>> gewesen.
> Yup.
> Andererseits: Warum überschreibt der DHCP-Client überhaupt
> /etc/resolv.conf (und weiß-der-Geier-sonstnochwas), wenn der nicht
> mal eine positive Antwort vom DHCP-Server bekommen hat?
> Oder hab ich was mißverstanden?
geantwortet, in seiner Antwort aber keine DNS-Server zurueckgeliefert.
Das wurde dann von seinem System nicht (wie von ihm erwartet) als
"lass die DNS-Einstellungen wie sie sind" interpretiert, sondern als
"verwende keine DNS-Server", was dann zum loeschen der Eintraege in
/etc/resolv.conf fuehren wuerde ...
Darueber hinaus hatte er offenbar noch Probleme darin, dass der
Network-Manager neuerdings ein "dns Plugin" unterstuetzt, mit dem
dann ein "Cache-only-DNS" beim start der Netzwerkverbindung dazwischen-
gehaekelt wird (per Default wohl dnsmasqd), was dann immer zu den
"nameserver 127.0.0.1" Einstellungen in der resolv.conf fuehrt ...
Helmut Hullen
Apr 1, 2012, 8:45:00 AM4/1/12
to
Hallo, Juergen,
Du meintest am 01.04.12:
[...]
> Viel nerviger finde ich in aktuellen Versionen des Networkmanagers
> die Zwangsbundelung mit dnsmasq, an der man auch nur schwer bis gar
> nicht vorbei kommt (was fuer ein Schwachsinn) ...
Das dürfte dann lustig werden, wenn Samba 4 kommt. Diese Version ist so
konzipiert, dass sie zwar mit dem ISC-bind läuft, nicht aber mit
dnsmasq.
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Du meintest am 01.04.12:
[...]
> Viel nerviger finde ich in aktuellen Versionen des Networkmanagers
> die Zwangsbundelung mit dnsmasq, an der man auch nur schwer bis gar
> nicht vorbei kommt (was fuer ein Schwachsinn) ...
konzipiert, dass sie zwar mit dem ISC-bind läuft, nicht aber mit
dnsmasq.
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Frank Ursel
Apr 1, 2012, 1:04:43 PM4/1/12
to
Christian Brandt schrieb:
> Welcher abgrundtief Menschenhasser hat sich resolvconf ausgedacht?
;-)
> Naja, wie haben wir es früher gemacht? Eben, aptitude remove resolvconf.
>
> Hoppla, Ubuntu 12.04 ist da der Meinung daß damit das Paket
> ubuntu-minimal verschwinden muß. Achja und im gleichem Aufwasch auch
> noch die nicht länger genutzten Pakete adduser, apt, apt-utils, bzip2,
> console-setup, debconf, debconf-i18n, eject, gnupg, ifupdown uswusf...
> nebenbei, Debian unstable war auch der Meinung daß der Verzicht auf
> resolvconf auch gleich passwd entsorgen sollte aber immerhin bzip hätte
> es mir weiter gegönnt.
>
> Naja, bevor ich jetzt mit Paketpinning usw anfange, wirklich elegant
Dann schauen wir doch mal nach Debian unstable:
$ aptitude show resolvconf
Paket: resolvconf
Zustand: nicht installiert
aptitude show passwd
Paket: passwd
Zustand: Installiert
Geht also auch ohne resolvconf. :-) Bei dir wurde wahrscheinlich ein
Paket aus der Liste als Abhängigkeit von resolvconf installiert, dass
dann die anderen Pakete nachgezogen hat. Wenn du das richtige findest,
musst du das nur als manuell-installiert markieren (apt-mark manual
$PAKET) und das wars. Im schlimmsten Fall markierst du halt alle Pakete,
die er dir unter den Füßen wegziehen will, als manuell.
> ist der Verzicht auf resolvconf ja dann doch nicht. Da gibts sicher
Kommt drauf an. Hier brauch ich keinen zusätzlichen Dienst, der mir die
resolv.conf verwaltet - da kümmert sich ja schon mein dhcp client drum.
> irgendwo einen Schalter "resolvconf=off" oder so.
Aus /usr/share/doc/resolvconf/Readme.gz:
| The admin can of course disable resolv.conf automagic by deleting the
| /etc/resolv.conf symlink and putting a static file at that location.
Ansonsten würde zumindest ein
$ update-rc.d resolvconf disable && update-rc.d resolvconf defaults
verhindern, dass der Dienst automatisch gestartet wird - aber resolvconf
liefert das ein oder andere script für dhcp etc. mit, womit es wohl
wieder gestartet werden würde.
Frank
> Welcher abgrundtief Menschenhasser hat sich resolvconf ausgedacht?
> Naja, wie haben wir es früher gemacht? Eben, aptitude remove resolvconf.
>
> Hoppla, Ubuntu 12.04 ist da der Meinung daß damit das Paket
> ubuntu-minimal verschwinden muß. Achja und im gleichem Aufwasch auch
> noch die nicht länger genutzten Pakete adduser, apt, apt-utils, bzip2,
> console-setup, debconf, debconf-i18n, eject, gnupg, ifupdown uswusf...
> nebenbei, Debian unstable war auch der Meinung daß der Verzicht auf
> resolvconf auch gleich passwd entsorgen sollte aber immerhin bzip hätte
> es mir weiter gegönnt.
>
> Naja, bevor ich jetzt mit Paketpinning usw anfange, wirklich elegant
$ aptitude show resolvconf
Paket: resolvconf
Zustand: nicht installiert
aptitude show passwd
Paket: passwd
Zustand: Installiert
Geht also auch ohne resolvconf. :-) Bei dir wurde wahrscheinlich ein
Paket aus der Liste als Abhängigkeit von resolvconf installiert, dass
dann die anderen Pakete nachgezogen hat. Wenn du das richtige findest,
musst du das nur als manuell-installiert markieren (apt-mark manual
$PAKET) und das wars. Im schlimmsten Fall markierst du halt alle Pakete,
die er dir unter den Füßen wegziehen will, als manuell.
> ist der Verzicht auf resolvconf ja dann doch nicht. Da gibts sicher
resolv.conf verwaltet - da kümmert sich ja schon mein dhcp client drum.
> irgendwo einen Schalter "resolvconf=off" oder so.
| The admin can of course disable resolv.conf automagic by deleting the
| /etc/resolv.conf symlink and putting a static file at that location.
Ansonsten würde zumindest ein
$ update-rc.d resolvconf disable && update-rc.d resolvconf defaults
verhindern, dass der Dienst automatisch gestartet wird - aber resolvconf
liefert das ein oder andere script für dhcp etc. mit, womit es wohl
wieder gestartet werden würde.
Frank
Joseph Terner
Apr 1, 2012, 1:24:29 PM4/1/12
to
On Sun, 01 Apr 2012 09:23:43 +0200, Christian Brandt wrote:
> Also wo kann ich TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS setzen?
> grep -r TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS /etc/
> /usr/share/doc/resolvconf liefert: Nichts. Diese Variable wird zwar in
> /sbin/resolvconf referenziert aber niemals irgendwo mit einer Silbe
> erwähnt. Also schauen wir mal was die Jungs so alles includen und voila,
> /etc/default/resolvconf wird included. Nochmal grep -r
> default.resolvconf /... und: nichts. Die Datei existiert natürlich noch
> nicht und ist auch nirgends referenziert. Kennen tut das nichtmal das
> Internet und das Internet weis alles. Immerhin wäre jetzt belegt daß
> Rule34 NICHT gilt, Pornobilder von /etc/default/resolvconf gibts nicht,
> wirds nie geben und mal ehrlich, wer will das?
Vom 18. Januar dieses Jahres:
> Also wo kann ich TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS setzen?
> grep -r TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS /etc/
> /usr/share/doc/resolvconf liefert: Nichts. Diese Variable wird zwar in
> /sbin/resolvconf referenziert aber niemals irgendwo mit einer Silbe
> erwähnt. Also schauen wir mal was die Jungs so alles includen und voila,
> /etc/default/resolvconf wird included. Nochmal grep -r
> default.resolvconf /... und: nichts. Die Datei existiert natürlich noch
> nicht und ist auch nirgends referenziert. Kennen tut das nichtmal das
> Internet und das Internet weis alles. Immerhin wäre jetzt belegt daß
> Rule34 NICHT gilt, Pornobilder von /etc/default/resolvconf gibts nicht,
> wirds nie geben und mal ehrlich, wer will das?
<https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/917896/comments/1>
| A (caching) nameserver on the local machine is always available, so no
| fallback is needed.
Bestimmt weil der bei Debian im Kernel ist oder so. ;-)
ciao, Joseph
Christian Brandt
Apr 1, 2012, 3:14:18 PM4/1/12
to
Am 01.04.2012 11:24, schrieb Volker Birk:
> Nochmal zum Mitmeisseln: was der lustige OP eigentlich hätte machen
> sollen, wäre das Entfernen (oder wenigstens stoppen) des DHCP-Clients
> gewesen.
Der DHCP-Client wird nicht gestartet wenn in der
> Nochmal zum Mitmeisseln: was der lustige OP eigentlich hätte machen
> sollen, wäre das Entfernen (oder wenigstens stoppen) des DHCP-Clients
> gewesen.
/etc/network/interfaces kein DHCP Interface definiert wird.
Christian Brandt
Christian Brandt
Apr 1, 2012, 3:24:44 PM4/1/12
to
Am 01.04.2012 11:21, schrieb Volker Birk:
> In de.alt.sysadmin.recovery Christian Brandt <bra...@psi5.com> wrote:
>> Hoppla, /etc/resolv.conf wird jetzt bei jedem Neustart mit einem leeren
>> Template überschrieben weil ja der dhcp wegen isnich nixda zurückliefert.
>
> Wieso betreibst Du einen DHCP-Klienten, wenn Du keinen brauchst?
Der DHCP ist im Zustand "isnich" was für "läuft nicht" steht und daher
> In de.alt.sysadmin.recovery Christian Brandt <bra...@psi5.com> wrote:
>> Hoppla, /etc/resolv.conf wird jetzt bei jedem Neustart mit einem leeren
>> Template überschrieben weil ja der dhcp wegen isnich nixda zurückliefert.
>
> Wieso betreibst Du einen DHCP-Klienten, wenn Du keinen brauchst?
liefert er "nixda" zurück was für "garnichts" steht.
Und wer weiter liest erkennt auch daß es eigentlich nicht am
DHCP-Client sondern am Bind-Nameserver liegt der seinerseits meint
irgendwelche Sachen setzen zu müssen. Neben vielen anderen doofen
Programmen die auch meinen besser zu wissen was ich will als ich selber.
(Zur Erläuterung, wenn man in der /etc/network/interfaces nur static
und nie dhcp verwendet wird der dhcpclient auch nie gestartet).
Christian Brandt
Marc Haber
Apr 2, 2012, 6:44:12 AM4/2/12
to
Joseph Terner <jtusene...@gmx.de> wrote:
>Vom 18. Januar dieses Jahres:
>
><https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/917896/comments/1>
>
>| A (caching) nameserver on the local machine is always available, so no
>| fallback is needed.
>
>Bestimmt weil der bei Debian im Kernel ist oder so. ;-)
Warum wird Debian immer wieder für Dinge verantwortlich gemacht, die
>Vom 18. Januar dieses Jahres:
>
><https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/917896/comments/1>
>
>| A (caching) nameserver on the local machine is always available, so no
>| fallback is needed.
>
>Bestimmt weil der bei Debian im Kernel ist oder so. ;-)
in Debian heil und in Ubuntu mutwillig kaputt gemacht wurden?
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Helmut Hullen
Apr 2, 2012, 7:16:00 AM4/2/12
to
Hallo, Marc,
Du meintest am 02.04.12:
>> Bestimmt weil der bei Debian im Kernel ist oder so. ;-)
> Warum wird Debian immer wieder für Dinge verantwortlich gemacht, die
> in Debian heil und in Ubuntu mutwillig kaputt gemacht wurden?
Passiert dieser Rückschluss tatsächlich "immer"?
Oder übertreibst Du genauso wie Dein Vorredner?
Du meintest am 02.04.12:
>> Bestimmt weil der bei Debian im Kernel ist oder so. ;-)
> Warum wird Debian immer wieder für Dinge verantwortlich gemacht, die
> in Debian heil und in Ubuntu mutwillig kaputt gemacht wurden?
Oder übertreibst Du genauso wie Dein Vorredner?
Joseph Terner
Apr 2, 2012, 2:37:25 PM4/2/12
to
On Mon, 02 Apr 2012 12:44:12 +0200, Marc Haber wrote:
> Joseph Terner <jtusene...@gmx.de> wrote:
>>Vom 18. Januar dieses Jahres:
>>
>><https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/917896/comments/1>
>>
>>| A (caching) nameserver on the local machine is always available, so no
>>| fallback is needed.
>>
>>Bestimmt weil der bei Debian im Kernel ist oder so. ;-)
>
> Warum wird Debian immer wieder für Dinge verantwortlich gemacht, die
> in Debian heil und in Ubuntu mutwillig kaputt gemacht wurden?
Ich fand den Comment des "Debian resolvconf maintainers" sehr recovery.
> Joseph Terner <jtusene...@gmx.de> wrote:
>>Vom 18. Januar dieses Jahres:
>>
>><https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/917896/comments/1>
>>
>>| A (caching) nameserver on the local machine is always available, so no
>>| fallback is needed.
>>
>>Bestimmt weil der bei Debian im Kernel ist oder so. ;-)
>
> Warum wird Debian immer wieder für Dinge verantwortlich gemacht, die
> in Debian heil und in Ubuntu mutwillig kaputt gemacht wurden?
Ansonsten ist mir egal, wie die sich am liebsten in den Fuß schießen.
ciao, Joseph
Andreas Scherbaum
Apr 5, 2012, 10:18:47 AM4/5/12
to
Ubuntu ist das neue SuSE?
--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)
--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)
Juergen Ilse
Apr 5, 2012, 11:28:45 AM4/5/12
to
Hallo,
In de.comp.os.unix.networking.misc Andreas Scherbaum <ads-...@wars-nicht.de> wrote:
> Ulrich M. Schwarz <broth...@gmx.net> wrote:
>> Ubuntu ist DWIM: "Doesn't Work If Modified".
Das trifft nur zu, wenn man "modified" ohne wirklich zu wissen was man tut
("wissen was man tut" umfasst auch ein grundlegendes Verstaendnis, was denn
das System fuer Mechanismen fuer den jeweiligen Teil der Administration
verwendet).
> Ubuntu ist das neue SuSE?
SuSE kenne ich eigentlich nur bis zu den 7.x bzw. 8.x Versionen relativ gut,
und bei denen kann ich sagen, dass das selbe zutraf, was ich oben genannt
habe: Sofern man weiss was man tut und *mit* dem System statt *gegen* das
System administriert, sind auch manuelle Modifikationen nicht unbedingt
ein Problem gewesen. Der Ruf, man koenne nicht manuell dran herum aendern
ohne das System zu zerschiessen kam meiner Ansicht nach von Leuten, die
dran herumgefummelt haben, ohne (im oben genannten Sinne) zu wissen was
sie taten.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
PS: als ich noch SuSE auf eigenen Rechnern verwendet hatte, habe ich
nach manuellen Anpassungen *immer* auch noch einmal "SuSEConfig" auf-
gerufen, um nicht erst viel spaeter (nachdem ich dann evt. nicht mehr
wusste, was ich eigentlich genau geaendert hatte) auf die Nase zu fallen,
wenn dann mal wieder SuSEConfig lief. Und Nein, es war kein allzu grosses
Problem, die eigenen Aenderungen kompatibel zu SuSEConfig zu halten, da
die von SuSEConfig verwendeten Dateien sehr gut kommentiert waren (was
aber nur etwas nutzte, wenn man die Kommentare auch gelesen hat).
In de.comp.os.unix.networking.misc Andreas Scherbaum <ads-...@wars-nicht.de> wrote:
> Ulrich M. Schwarz <broth...@gmx.net> wrote:
>> Ubuntu ist DWIM: "Doesn't Work If Modified".
("wissen was man tut" umfasst auch ein grundlegendes Verstaendnis, was denn
das System fuer Mechanismen fuer den jeweiligen Teil der Administration
verwendet).
> Ubuntu ist das neue SuSE?
und bei denen kann ich sagen, dass das selbe zutraf, was ich oben genannt
habe: Sofern man weiss was man tut und *mit* dem System statt *gegen* das
System administriert, sind auch manuelle Modifikationen nicht unbedingt
ein Problem gewesen. Der Ruf, man koenne nicht manuell dran herum aendern
ohne das System zu zerschiessen kam meiner Ansicht nach von Leuten, die
dran herumgefummelt haben, ohne (im oben genannten Sinne) zu wissen was
sie taten.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
PS: als ich noch SuSE auf eigenen Rechnern verwendet hatte, habe ich
nach manuellen Anpassungen *immer* auch noch einmal "SuSEConfig" auf-
gerufen, um nicht erst viel spaeter (nachdem ich dann evt. nicht mehr
wusste, was ich eigentlich genau geaendert hatte) auf die Nase zu fallen,
wenn dann mal wieder SuSEConfig lief. Und Nein, es war kein allzu grosses
Problem, die eigenen Aenderungen kompatibel zu SuSEConfig zu halten, da
die von SuSEConfig verwendeten Dateien sehr gut kommentiert waren (was
aber nur etwas nutzte, wenn man die Kommentare auch gelesen hat).
Andreas Scherbaum
Apr 12, 2012, 8:56:41 AM4/12/12
to
Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
> In de.comp.os.unix.networking.misc Andreas Scherbaum <ads-...@wars-nicht.de> wrote:
>
>> Ubuntu ist das neue SuSE?
>
> SuSE kenne ich eigentlich nur bis zu den 7.x bzw. 8.x Versionen relativ gut,
> und bei denen kann ich sagen, dass das selbe zutraf, was ich oben genannt
> habe: Sofern man weiss was man tut und *mit* dem System statt *gegen* das
> System administriert, sind auch manuelle Modifikationen nicht unbedingt
> ein Problem gewesen. Der Ruf, man koenne nicht manuell dran herum aendern
> ohne das System zu zerschiessen kam meiner Ansicht nach von Leuten, die
> dran herumgefummelt haben, ohne (im oben genannten Sinne) zu wissen was
> sie taten.
Gerade bei Ubuntu will man aber nicht erst drei dicke Handbücher
> In de.comp.os.unix.networking.misc Andreas Scherbaum <ads-...@wars-nicht.de> wrote:
>
>> Ubuntu ist das neue SuSE?
>
> SuSE kenne ich eigentlich nur bis zu den 7.x bzw. 8.x Versionen relativ gut,
> und bei denen kann ich sagen, dass das selbe zutraf, was ich oben genannt
> habe: Sofern man weiss was man tut und *mit* dem System statt *gegen* das
> System administriert, sind auch manuelle Modifikationen nicht unbedingt
> ein Problem gewesen. Der Ruf, man koenne nicht manuell dran herum aendern
> ohne das System zu zerschiessen kam meiner Ansicht nach von Leuten, die
> dran herumgefummelt haben, ohne (im oben genannten Sinne) zu wissen was
> sie taten.
wälzen, bevor man mit dem System umgehen kann. Es soll ja intuitiv
sein.
Dietz Proepper
Apr 12, 2012, 9:58:14 AM4/12/12
to
Andreas Scherbaum wrote:
> Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>> SuSE kenne ich eigentlich nur bis zu den 7.x bzw. 8.x Versionen relativ
>> gut, und bei denen kann ich sagen, dass das selbe zutraf, was ich oben
>> genannt habe: Sofern man weiss was man tut und *mit* dem System statt
>> *gegen* das System administriert, sind auch manuelle Modifikationen nicht
>> unbedingt ein Problem gewesen. Der Ruf, man koenne nicht manuell dran herum
>> aendern ohne das System zu zerschiessen kam meiner Ansicht nach von Leuten,
>> die dran herumgefummelt haben, ohne (im oben genannten Sinne) zu wissen was
>> sie taten.
>
> Gerade bei Ubuntu will man aber nicht erst drei dicke Handbücher
> wälzen, bevor man mit dem System umgehen kann. Es soll ja intuitiv
> sein.
Sagte man das nicht immer über Windoze?
> Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>> SuSE kenne ich eigentlich nur bis zu den 7.x bzw. 8.x Versionen relativ
>> gut, und bei denen kann ich sagen, dass das selbe zutraf, was ich oben
>> genannt habe: Sofern man weiss was man tut und *mit* dem System statt
>> *gegen* das System administriert, sind auch manuelle Modifikationen nicht
>> unbedingt ein Problem gewesen. Der Ruf, man koenne nicht manuell dran herum
>> aendern ohne das System zu zerschiessen kam meiner Ansicht nach von Leuten,
>> die dran herumgefummelt haben, ohne (im oben genannten Sinne) zu wissen was
>> sie taten.
>
> Gerade bei Ubuntu will man aber nicht erst drei dicke Handbücher
> wälzen, bevor man mit dem System umgehen kann. Es soll ja intuitiv
> sein.
Arnim Sommer
Apr 12, 2012, 3:26:06 PM4/12/12
to
A°S
--
Persönliche Daten sind wie Plutonium.
Wenn zuviele davon auf einem Haufen liegen, wird es kritisch.
-- Dirk Engling, CCC
phoenix...@gmail.com
Jan 3, 2013, 4:37:43 PM1/3/13
to
hi christian ,
wie hast du damals das problem mit resolvconf genau gelöst?
habe bei mir genau das gleiche problem mit der scheiss resolvconf.
das kackding erzählt mir dauernd einen von wegen das der einizige nameserver den er kennt die 127.0.0.1 is . ich will aber das er nich nur den loopback device nimmt sondern auch die scheiss ip vom server. damit ich netzwerk intern meine eigene domain für meinen webserver hab.
bei nem ping sacht mir die kiste dauernd das er den host nich kennt bzw ping:unkown host.
resolvconf hab ich schon dank deines posts aus geschaltet .aber weit gefehlt .Die kiste will nich sowie ich will.
da ich mit linux bzw.debian squeeze noch nich so 100%ig vertraut bin .wäre hilfe von nem profi ganz gut ..
danke dir im vorraus
alex Michels
wie hast du damals das problem mit resolvconf genau gelöst?
habe bei mir genau das gleiche problem mit der scheiss resolvconf.
das kackding erzählt mir dauernd einen von wegen das der einizige nameserver den er kennt die 127.0.0.1 is . ich will aber das er nich nur den loopback device nimmt sondern auch die scheiss ip vom server. damit ich netzwerk intern meine eigene domain für meinen webserver hab.
bei nem ping sacht mir die kiste dauernd das er den host nich kennt bzw ping:unkown host.
resolvconf hab ich schon dank deines posts aus geschaltet .aber weit gefehlt .Die kiste will nich sowie ich will.
da ich mit linux bzw.debian squeeze noch nich so 100%ig vertraut bin .wäre hilfe von nem profi ganz gut ..
danke dir im vorraus
alex Michels
Juergen Ilse
Jan 3, 2013, 6:24:40 PM1/3/13
to
Hallo,
phoenix...@gmail.com wrote:
> hi christian ,
> wie hast du damals das problem mit resolvconf genau gelöst?
> habe bei mir genau das gleiche problem mit der scheiss resolvconf.
> das kackding erzählt mir dauernd einen von wegen das der einizige
> nameserver den er kennt die 127.0.0.1 is .
Das duerfte am "dns-plugin" des Networl-Manahers liegen. Bei mir sehen
die entsprechenden Zeilen in der NetworkManager.conf so aus:
[main]
plugins=ifupdown,keyfile
#dns=dnsmasq
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
phoenix...@gmail.com wrote:
> hi christian ,
> wie hast du damals das problem mit resolvconf genau gelöst?
> habe bei mir genau das gleiche problem mit der scheiss resolvconf.
> das kackding erzählt mir dauernd einen von wegen das der einizige
> nameserver den er kennt die 127.0.0.1 is .
die entsprechenden Zeilen in der NetworkManager.conf so aus:
[main]
plugins=ifupdown,keyfile
#dns=dnsmasq
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
phoenix...@gmail.com
Jan 5, 2013, 9:43:21 AM1/5/13
to
bei mir sieht die datei so aus:
[main]
plugins=ifupdown,keyfile
no-auto-default=00:0c:76:57:8f:28,
[ifupdown]
managed=false
interessanterweise is die mac adresse seine eigene.
gruss alex
0 new messages