Beiträge von porrier

    Die DNS-Records liegen auf den Nameservern von Netcup. Nach meinen Experimenten ist IPv6 mit den Nameservern nicht das Problem. Ich konnte es einkreisen auf die Kommunikation zwischen meiner Arbeitskiste und dem Speedportrouter der Telekom.

    Sobald ich auf meiner Arbeitsmaschine mit openSUSE 13.2 IPv6 deaktiviere, läuft die Namensauflösung problemlos. Ich habe für WLAN schon ausdrücklich den Nameserver des Speedport mit fe80::1 zuerst angegeben, dennoch habe ich die extreme Verzögerung beim ersten Aufruf einer Domaine. Beim zweiten Mal klappt es dann. Ich nehme daher an,
    dass es etwas mit dem Nameserver der Telekom zu tun hat, den der Speedport befragt.

    # ip route
    default via 192.168.3.1 dev wlp0s19f5u8
    192.168.2.0/24 dev enp1s0 proto kernel scope link src 192.168.2.2
    192.168.3.0/24 dev wlp0s19f5u8 proto kernel scope link src 192.168.3.2

    # ip -6 route
    2003:54:ef0a:9f00::/64 dev wlp0s19f5u8 proto kernel metric 256 expires 6605sec
    fe80::/64 dev enp1s0 proto kernel metric 256
    fe80::/64 dev wlp0s19f5u8 proto kernel metric 256
    default via fe80::1 dev wlp0s19f5u8 metric 1024

    # cat /etc/resolv.conf
    nameserver fe80::1
    nameserver 192.168.3.1

    Dieses Problem tritt erst seit zwei Tagen auf. Die Ausgabe von ifconfig bzgl. IPV6
    sieht meiner Meinung nach seltsam aus. Vor ein paar Wochen waren das noch mehr
    IPv6-Einträge für das WLAN:

    wlp0s19f5 Link encap:Ethernet Hardware Adresse 00:22:B0:E7:D9:9B
    inet Adresse:192.168.3.2 Bcast:192.168.3.255 Maske:255.255.255.0
    inet6 Adresse: fe80::222:b0ff:fee7:d99b/64 Gültigkeitsbereich:Verbindung
    inet6 Adresse: 2003:54:ef0a:9f00:222:b0ff:fee7:d99b/64 Gültigkeitsbereich:Global
    inet6 Adresse: 2003:54:ef0a:9f00:e1d6:2e88:53cb:24f9/64 Gültigkeitsbereich:Global
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

    Grüße

    Hallo!

    Seit gestern habe ich offenbar ein Problem mit dem DNS. Das Abholen von Email geht mit dem MUA nur sehr schleppend, extrem verzögert. Will ich per ssh auf den Server und sage ssh bitcorner.de, geht das auch sehr schleppend. Gebe ich stattdessen die IP-Adresse an, geht das ganz schnell. Ein Neustart hat nichts geändert, auch der des Routers der Telekom nicht.

    Ein traceroute zeigt keine Probleme. Ich weis nicht, wo ich noch ansetzten soll. Ich könnte auf dem Client mal ipv6 deaktivieren. Was könnte das Problem sein?

    Grüße

    Andreas

    Hallo!

    Ich habe vorhin nach einem Kernelupdate das System neu gestartet und jetzt minütlich folgende Warnung im log:

    ICMPv6: RA: ndisc_router_discovery failed to add default route

    Das VCP zeigt folgende Information zu ipv6:

    IP Prefix Gateway
    2a03:4000:6:4123:: 64 fe80::1

    route gibt folgendes aus:

    default gateway.netcup. 0.0.0.0 UG 0 0 0 ens3
    37.120.164.0 * 255.255.252.0 U 0 0 0 ens3

    Was läuft schief?

    Grüße

    Andreas

    Hallo!

    Hat jemand eine Erklärung dafür, dass eine Anfrage an das DNS ala ww.w.domain.de aufgelöst wird?
    Ich finde das absolut merkwürdig. Habe ich gerade durch den googlebot ausgelöst im logfile des
    apache gefunden, mit 200 als Statuscode.

    Grüße

    Nein, der A record für listen.bitcorner.de exitstiert für ipv4 schon seit Monaten, für ipv6 habe ich ihn heute hinzugefügt.

    Das muss etwas anderes sein. Wenn ich mich bei google umschaue, dann hat es etwas mit letsencrypt selbst zu
    tun. Gelesen habe ich etwas, dass deren DNS-Server eine Art Mix aus upper- und lowercase machen und das
    nicht jeder Nameserver mitmacht.

    Dabei fällt mir ein, mailbox.org hatte kürzlich auch Probleme, listen.bitcorner.de aufzulösen, obwohl der record
    seit Monaten existiert.

    Hallo!

    Mir fällt auf, das listen.bitcorner.de im DNS nicht immer auflösbar ist, obwohl ich es von hier aus problemlos auflösen kann.

    Gescheitert ist das z.B. eben beim Versuch über letsencrypt ein Zertifikat zu erneuern.

    Failed authorization procedure. listen.bitcorner.de (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: SERVFAIL looking up A for listen.bitcorner.de

    Der A-record ist bei netcup natürlich eingetragen. Was kann das sein?

    Grüße

    Habe einfach mal ::1 angehängt und das scheint zu funktionieren.

    Auf dem CCP habe ich in den DNS-Einstellungen AAAA records hinzugefügt, aber der Status sämtlicher records ist seit gestern abend immer noch unknown. Ein ping6 auf die IPv6 Adresse funktioniert von außerhalb, aber die einzelnen records offenbar nicht. Was kann ich tun?

    Grüße

    Andreas

    Ok, aber welche Adresse trage ich da jetzt ein?

    total IP addresses 18446744073709551616

    network range 2a03:4000:0006:d115:0000:0000:0000:0000-2a03:4000:0006:d115:ffff:ffff:ffff:ffff

    ha

    Grüße

    Zitat von »ThomasChr«



    ipv6 Adressen werden nicht automatisch vergeben. Du musst sie statosch konfigurieren. Im netcup Wiki steht wie: Zusätzliche IP Adresse konfigurieren – netcup Wiki
    Ok, aber welche Adresse trage ich da jetzt ein?

    total IP addresses 18446744073709551616

    network range 2a03:4000:0006:d115:0000:0000:0000:0000-2a03:4000:0006:d115:ffff:ffff:ffff:ffff

    ha

    Grüße

    Ok, aber welche Adresse trage ich da jetzt ein?

    total IP addresses 18446744073709551616

    network range 2a03:4000:0006:d115:0000:0000:0000:0000-2a03:4000:0006:d115:ffff:ffff:ffff:ffff

    Habe einfach mal ::1 angehängt und das scheint zu funktionieren.

    Hallo!

    Ich habe auf dem vserver IPv6 Adressen zuweisen lassen, ich bekomme mit ifconfig oder ip -6 addr nur eine fe80 Adresse angezeigt. Sollte ich da nicht zumindest zwei
    IPv6-Adressen angezeigt bekommen?

    und

    # ip -6 route show
    fe80::/64 dev ens3 proto kernel metric 256
    default via fe80::1 dev ens3 proto ra metric 1024 expires 1762sec


    Grüße

    Der Mechanismus wird dein Disk Image mounten und via chroot das Passwort ändern.

    Deswegen wird das auch nur gehen wenn der KVM Guest nicht läuft.

    Eine detaillierte Beschreibung dieses Vorgangs wäre wünschenswert. Ganz geheuer ist mir diese Sache nicht. Warum wird das vom System abgekoppelt gehandhabt und muss dann über ein Webinterface erfolgen? Über das chroot, in dem ich gestern mehrere Male war, war das änderen des root-Passworts jedenfalls nicht möglich. Wie soll es in einem gemounteten Disk Image möglich sein? Und warum so kompliziert, ein Vorgang über den man keine Kontrolle hat und das beim wichtigsten Ereignis in einem Betriebssystem, dem Ändern des Passworts von root.

    Andreas


    Neuinstallation?

    Also nachdem ich die Hoffnung schon aufgegegen hatte, habe ich im VCP einen Hinweis gesehen, dass das Root-Passwort nur bei ausgeschaltetem vserver geändert werden kann. Das habe ich sofort probiert und danach war mit dem neuen Passwort wieder ein Login als root möglich.

    Ich habe wieder ein funktionierendes System ohne Neuinstallation. Ich hatte auch schon in Erwägung gezogen, dass das System kompromiiert wurde (durch systemd womöglich ;) igitt)

    Was mir an dieser Sache Unbehagen bereitet, ist dass das Ändern des root-Passworts offensichtlich vom eigentlichen System abgekoppelt ist. Das finde ich nicht gut
    und der Mechanismus dahinter ist mir schleiherhaft.

    Ich danke euch allen für's Mitdenken und die vielen hilfreichen Tips!

    Andreas

    Moin


    Einfach den Symlink löschen, den Dir systemctl genannt hat. (vermutlich: /etc/systemd/system/systemd-journald.service)


    Wie auch, wenn du das Logging abschaltest?

    Mordor

    Moin


    Einfach den Symlink löschen, den Dir systemctl genannt hat. (vermutlich: /etc/systemd/system/systemd-journald.service)


    Wie auch, wenn du das Logging abschaltest?

    Mordor

    Das mit dem Löschen des symlink war der richtige Tip. Ich kann mich jetzt wieder als normaler Benutzer einloggen. Aber ich kann mich nicht mehr als root einloggen.

    Mehrere Versuche aus dem chroot über das rescue, das Passwort von root zu ändern (mit Yast oder auch auf der console) werden als erfolgreich quittiert. Der login als root nach einem normalen Neustart oder auch ein su zu root werden quittiert mit:

    ~> su
    Passwort:
    su: Fehler bei Authentifizierung

    Ein su zu root oder auch zu einem anderen Benuter im chroot funktioniert. Warum kann ich im chroot das root-Passwort nicht ändern oder besser gesagt, warum ist es nach einem Neustart nicht mehr gültig?

    Macht keinen Spaß. Hat noch jemand einen Tip?

    Grüße

    Andreas

    Bootet der vServer von einem eingelegten ISO? poweroff/reset im VCP versucht?

    Ist Grub noch im MBR installiert? Notfalls einmal neu dorthin installieren.


    MfG Christian

    Bootet der vServer von einem eingelegten ISO? poweroff/reset im VCP versucht?

    Ist Grub noch im MBR installiert? Notfalls einmal neu dorthin installieren.


    MfG Christian

    Den GRUB konnte ich reparieren, indem ich ihn mit YAST in den die rootpartition installiert haben. Danach ist das System wieder gestartet.

    Ich kann mich aber nicht mehr einloggen, egal mit welchem Benutzer. Ich bin ins chroot gewechselt und habe mit YAST einen neuen Benutzer angelegt.
    Auch mit dem kann ich mich nicht mehr einloggen.

    Ich vermute es hat etwas mit systemctl mask systemd-journald.service zu tun. Aus dem chroot lasst sich das nicht wieder rückgängig machen, das System ist kaputt. Wer denkt sich nur eine solche .....ße aus. Noch nicht mal ein vernünftiges logging hat man mehr mit diesem tollen systemd.

    Andreas

    Hallo!

    Ich habe heute meinen vserver mit openSUSE per at Kommando neu starten lassen, aber er startet nicht mehr und bleibt bei

    Booting from Hard Disk...
    GRUB

    hängen. Ich war bereits in eine chroot-Umgebung und habe ein grub2-mkconfig -o /boot/grub2/grub.cfg
    ausgeführt, ohne Erfolg. Der Server bleibt hängen.

    Hat jemand einen Tip!

    Grüße