Du bist nicht angemeldet.
Hallo,
wenn ich mein Arch Linux mit
$ trizen -Syu
aktualisieren will, bekommen ich folgende Meldung
:: Unable to GET https://aur.archlinux.org/rpc.php?v=<hier habe zwecks Übersichtlichkeit gekürzt> ==> 500 Can't connect to aur.archlinux.org:443 (Der Name oder der Dienst ist nicht bekannt)
:: Unable to get info for AUR packages...
Auch kann ich die Seite https://aur.archlinux.org nicht über Firefox aufrufen - allerdings schon von einem anderen Rechner!
Dachte es hängt irgendwie mit dem httpS zusammen, da ich gefühlt sehr viele httpS-Seite nicht über Firefox aufrufen kann - andererseits die von Google-New dann doch wieder (https://news.google.com).
Offline
Wann hast du das letzte Mal ein Update gefahren?
Offline
Wann hast du das letzte Mal ein Update gefahren?
Aus Gewohnheit führe ich fast täglich ein "$ trizen -Syu" durch.
Allerdings habe ich obiges Problem schon seit mehreren Wochen. Habe mich aber nie so richtig darum gekümmert, auch da die Pakete aus den anderen Repositories wohl aktualisiert werden.
Offline
Ich hänge nun mal doch den gesamten Verlauf einer Aktualisierung an, auch da mir gerade aufgefallen ist, dass ganz am Anfang bei der Paketdatenbanksyncronisation AUR fehlt:
$ trizen -Syu
:: Pacman command: /usr/bin/sudo /usr/bin/pacman -Syu
[sudo] Passwort für alex:
:: Synchronisiere Paketdatenbanken...
core ist aktuell
extra ist aktuell
community 4,9 MiB 1156K/s 00:04 [##############################################] 100%
:: Starte vollständige Systemaktualisierung...
Löse Abhängigkeiten auf...
Suche nach in Konflikt stehenden Paketen...
Fehler: Konnte den Vorgang nicht vorbereiten (Kann Abhängigkeiten nicht erfüllen)
:: Installation vonx265 (3.1.2-1) verletzt Abhängigkeit 'libx265.so=169-64', benötigt von ffmpeg-full-nvenc
=>> Try again? [y/N]:
:: Unable to GET https://aur.archlinux.org/rpc.php?v=5&type=multiinfo&arg[]=aften&arg[]=blackmagic-decklink-sdk&arg[]=chromaprint-fftw&arg[]=dav1d-git&arg[]=davs2&arg[]=ffmpeg-full-nvenc&arg[]=flite1-patched&arg[]=hm&arg[]=libilbc&arg[]=libklvanc-git&arg[]=libmysofa&arg[]=libopenmpt-svn&arg[]=ogmrip&arg[]=ogmrip-ac3&arg[]=openh264&arg[]=phonon-qt4&arg[]=pocketsphinx&arg[]=pyqt4-common&arg[]=python-pyqt4&arg[]=python-qscintilla-qt4&arg[]=python-qscintilla-qt4-common&arg[]=python-sip-pyqt4&arg[]=qscintilla-qt4&arg[]=qt4&arg[]=rockchip-mpp&arg[]=shine&arg[]=sphinxbase&arg[]=trizen&arg[]=upycraft-git&arg[]=vmaf&arg[]=vo-amrwbenc&arg[]=xavs&arg[]=xavs2-git ==> 500 Can't connect to aur.archlinux.org:443 (Der Name oder der Dienst ist nicht bekannt)
:: Unable to get info for AUR packages...
Offline
Vielleicht solltest du’s mal auf althergebrachte und offiziell vorgesehene Weise via pacman machen, außerdem solltest du dich um das (dokumentierte, auch hier im Forum) Problem mit libx265 kümmern. Anschließend sollte™ zumindest mal das Update durchlaufen, und dann könnte© das andere Problem auch schon behoben sein.
Edit: sehe gerade, dass dein eines AUR-Paket das Problem mit libx265 erzeugt → das Ding mal wegmachen, kann später in aktueller Version wieder drauf, wenn’s dann wieder läuft.
Beitrag geändert von niemand (01.09.2019 08:51:55)
Offline
Kann es sein, dass dein Rechner ein Problem mit Let's-Encrypt-Zertifikaten hat? Kannst du 2-3 andere Beispiele angeben von Seiten, die nicht funktionieren? Welche Meldung zeigt Firefox dann an?
Und der andere Rechner, bei dem es funktioniert, hängt im gleichen Netzwerk?
Das nahm ich nun an, blub. Deswegen die Frage nach dem Zeitpunkt des letzten (erfolgreichen) Updates – die CA-Certs kommen nämlich auf diesem Weg auf das System.
Offline
Leider konnte ich das Problem nicht beheben.
Habe mich durch tonnenweise Threads gequält und am Schluss nur noch wild rumprobiert. Irgendwann hatte ich dann mal über Pacman mein halbes System zerschossen ... und wie auch immer aber wieder zum laufen gebracht .. und das Problem war auch zeitweise weg .. kam aber zurück :-(
Irgendwie glaube ich ja auch, dass es mit den Zertifikaten zusammenhänge. Wie kann man das prüfen?
Seiten, die ich bspw. nicht aufrufen kann:
https://bbs.archlinux.org/viewtopic.php?id=237522
www.cpan.org
https://www.archlinux.org/news/ca-certificates-update/
Ein "pacman -Syu" geht problemlos (alles aktuell)
Ein "trizen -Syu":
$ trizen -Syu
:: Pacman command: /usr/bin/sudo /usr/bin/pacman -Syu
:: Synchronisiere Paketdatenbanken...
core ist aktuell
extra ist aktuell
community ist aktuell
:: Starte vollständige Systemaktualisierung...
Es gibt nichts zu tun
:: Unable to GET https://aur.archlinux.org/rpc.php?v=5&type=multiinfo&arg[]=fcitx-qt4&arg[]=trizen ==> 500 Can't connect to aur.archlinux.org:443 (Der Name oder der Dienst ist nicht bekannt)
:: Unable to get info for AUR packages...
$
Beitrag geändert von BigMan200 (12.10.2019 11:48:35)
Offline
Lösch doch mal alles, was trizen so in dein Homeverzeichnis gebracht hat. Dürfte eigentlich nur die Datei ~/.config/trizen/trizen.conf sein.
Offline
Lösch doch mal alles, was trizen so in dein Homeverzeichnis gebracht hat. Dürfte eigentlich nur die Datei ~/.config/trizen/trizen.conf sein.
Im Verzeichnis ~/.config/trizen, lag tatsächlich nur eine Datei trizen.conf. Die habe ich mit rm gelöscht, und dann "trizen -Syu" durchgeführt.
Hat aber nichts gebracht (selbe Fehlermeldung und bestimmte Websites lassen sich nicht aufrufen). Danach lag übrigens wieder eine trizen.conf im Verzeichnis.
Beitrag geändert von BigMan200 (12.10.2019 12:29:30)
Offline
Welchen Mirror benutzt du denn? Nicht dass du dich an einen verbindest der zur Zeit hängt https://www.archlinux.org/mirrors/status/#outofsync
Und von wann sind die Zertifikate? Aktuell ist https://www.archlinux.de/packages/core/ … rtificates
Welchen Mirror benutzt du denn? Nicht dass du dich an einen verbindest der zur Zeit hängt https://www.archlinux.org/mirrors/status/#outofsync
Und von wann sind die Zertifikate? Aktuell ist https://www.archlinux.de/packages/core/ … rtificates
Den Link https://www.archlinux.org/mirrors/status/#outofsync kann ich nicht öffnen --> ein weiterer Link also, der bei mir nicht geht.
Bezüglich der Zertifikate:
$ trizen -Ss ca-certificates
:: Unable to GET https://aur.archlinux.org/rpc.php?v=5&type=search&arg=ca-certificates ==> 500 Can't connect to aur.archlinux.org:443 (Der Name oder der Dienst ist nicht bekannt)
core/ca-certificates 20181109-1 [Installiert]
Common CA certificates (default providers)
core/ca-certificates-mozilla 3.46.1-1 [Installiert]
Mozilla's set of trusted CA certificates
core/ca-certificates-utils 20181109-1 [Installiert]
Common CA certificates (utilities)
--> Basierend auf dem Link https://www.archlinux.de/packages/core/ … rtificates sieht das aber aktuell aus.
Offline
Poste dich bitte auch mal Deine pacman.conf. Und was fummelst Du die ganze Zeit mit trizen rum. Verwende zunächst pacman.
Offline
Das Problem scheint ja mit dem https-Zugriff zu tun zu habe und nicht mit trizen. Auch im Browser geht ja nicht alles. Hast du irgendeine Firewall am Start?
nmap -P0 -p443 aur.archlinux.org
Offline
Das Problem scheint ja mit dem https-Zugriff zu tun zu habe und nicht mit trizen. Auch im Browser geht ja nicht alles. Hast du irgendeine Firewall am Start?
nmap -P0 -p443 aur.archlinux.org
Okay, heute ist mal wieder so ein Tag wo es nicht funktionert:
$ nmap -P0 -p443 aur.archlinux.org
Starting Nmap 7.80 ( https://nmap.org ) at 2019-10-19 17:59 CEST
Failed to resolve "aur.archlinux.org".
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 1.24 seconds
Bzgl. Firewall: da musste ich mal an meinen dd-wrt-Routern schauen. An einem ist SPI eingeschaltet. Aber auch nachdem ich dieses auf deaktiv gesetzt hatte, hat es nicht geklappt.
Offline
Heute liefert:
$ nmap -P0 -p443 aur.archlinux.org
Starting Nmap 7.80 ( https://nmap.org ) at 2019-10-20 09:04 CEST
Nmap scan report for aur.archlinux.org (5.9.250.164)
Host is up (0.23s latency).
rDNS record for 5.9.250.164: luna.archlinux.org
PORT STATE SERVICE
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 0.31 seconds
Aber dennoch kann ich nicht obige Beispielwebsites öffnen (Firefox-Meldung: "Server nicht gefunden.")
Zu dem Hinweis, dass es ein DNS-Problem sein könnte. Wie kann ich das prüfen?
Hier mal Einträge von denen ich denke, diese könnten relevant sein:
$cat /etc/resolv.conf
nameserver 10.0.0.20
options edns0
$cat /etc/systemd/resolved.conf
[Resolve]
DNS=10.0.0.20
Hinter der 10.0.0.20 verbirgt sich mein dd-wrt-Router, der wiederrum mit einer UnityMedia-Combibox verbunden ist.
Beitrag geändert von BigMan200 (20.10.2019 09:21:06)
Offline
Zu dem Hinweis, dass es ein DNS-Problem sein könnte. Wie kann ich das prüfen?
ping, nslookup, dig... jedes Tool das dir in irgend einer Form den Namen auflöst kannst du nehmen. Am besten in beide Richtungen prüfen, also Name-->IP und IP-->Name. DNS-Server mal umsetzen auf einen öffentlichen oder z.B. dig mitgeben.
Ich halte das auch für ein DNS Problem bei dir.
Offline
Vermutlich solltest Du deinen DD-WRT-Router gegen einen tauschen, der zuverlässig IPv6 kann, solange Du einen Vodafone/Unitymedia-Kabelanschluss nutzt.
Wenn du einen IPv6-Anschluss hast, gibt es schlicht keine Portweiterleitung mehr, da musst du entsprechende IPv6-Freigaben im Router einrichten. UM kann nicht mehr jedem Kunden einen IPv4-Anschluss schalten, da schlicht keine IPv4-Adressen mehr erhältlich sind. Um aber jedem Kunden den Zugriff auf IPv4-Dienste und -Inhalte möglich zu machen, wurde die "Brückentechnologie" DS lite geschaltet. Nur sind damit (weil es keine öffentlich erreichbare IPv4-Adresse an deinem Anschluss gibt) keine Portweiterleitungen möglich, denn dein Anschluss ist komplett per IPv6 angebunden. Der IPv4-Verkehr wird per IPv6 über einen Tunnel an das AFTR geleitet und dort quasi wieder in IPv4 "übersetzt", genauso geht das zurück.
Und selbst wenn der Bridge-Mode für die ConnectBox kommt, kannst du trotzdem an einem IPv6-Anschluss auch am eigenen Router keine Ports weiterleiten. Und wenn dein Router dann kein DS lite kann, hast du nichtmal Zugriff auf alles, was IPv4 only spricht!
DS lite wird rein über den Router gemanaged, wenn man also keine Ahnung davon hat, wie der Router zu konfigurieren ist, so ist das das Problem des Kunden. Das wäre übrigens beim Bridge Mode der Connect Box genauso, nur um direkt allen Wind aus den Segeln zu nehmen! Ein Kabelmodem stellt lediglich eine Verbindung zum CMTS her, nicht mehr und nicht weniger. Kann der Router dann kein DS lite, so gibt es halt keine IPv4-Verbindungen an diesem Anschluss.
Such support is not an hardware limitation, it's a software choice. DD-WRT devs have decided not to include any IPv6 (and any of the transitioning technologies such as Dual Stack) support in routers with just 4 MB of flash.
https://forum.dd-wrt.com/phpBB2/viewtop … 38#1045238
Nachtrag: Zwei Beiträge weiter wird OpenWRT empfohlen.
Beitrag geändert von k.osmo (20.10.2019 20:07:36)
Offline
Ich hab bei mir das gleiche Problem mit trizen.
Auf meinem eigenen Rechner, den ich vor 2 Jahren installiert hab, funktioniert alles ohne Probleme.
Auf dem Laptop eines Kollegen, den ich gestern neu installiert habe, kann ich keine Programme mit trizen installieren, da bekomm ich die gleichen Meldungen wie BigMan200.
Und bevor jetzt die Frage kommt, wieso man da mit trizen rumspielt ...qelectrotech gibt es leider nur im AUR
Am Router kann es eigentlich nicht liegen, beide Rechner hängen am selben.
Offline
Olli, mach bitte einen eigenen Thead auf. Der OP hat ein Problem mit DNS, nicht mit trizen.
Offline
Aber genau dieses Problem mit trizen spricht BigMan200 in seinem Eingangspost doch an.
Bei mir hat sich das Problem übrigens erledigt, vielleicht hilft dir das ja auch weiter:
Systemzeit und Datum hat nicht gestimmt. Ist mir auch erst aufgefallen, als ich Firefox auf diesem Laptop zum ersten Fall benutzt hab.
Nachdem ich Datum und Zeit korrigiert hab, läuft alles ohne Probleme.
Offline
Im Eingangspost wird trizen erwähnt, ja, aber aus dem Rest des Threads geht hervor, dass es sich um ein ganz anderes Problem gehandelt hat.
Und wenn es sich bei dir durch Anpassung der Systemzeit erledigt hat (schön), ist es nochmal ein anderes Problem, und hat wieder nichts mit trizen zu tun.
Offline
Im Eingangspost wird trizen erwähnt, ja, aber aus dem Rest des Threads geht hervor, dass es sich um ein ganz anderes Problem gehandelt hat.
Und wenn es sich bei dir durch Anpassung der Systemzeit erledigt hat (schön), ist es nochmal ein anderes Problem, und hat wieder nichts mit trizen zu tun.
Der Schwerpunkt liegt NICHT auf Trizen!
Oben ist ja auch geschildert, dass bestimmte Websites sich über einen Browser nicht öffnen lassen. Es gibt lediglich die VERMUTUNG, dass der Trizen Error und das Website-Problem die selbe Ursache haben (da beide etwas mit URL Zugriff zu tun haben - anscheinend zumindest.)
Offline
Konntest du deine Vermutung nicht verifizieren? Hier nochmals die Schritte, die chepaz empfiehlt:
$ drill archlinux.org
$ drill -x 138.201.81.199
$ drill archlinux.org @8.8.8.8
$ drill -x 138.201.81.199 @8.8.8.8
Wenn die zweiten zwei Befehl funktioniert, aber die ersten beiden nicht, dann hat der Nameserver unter 10.0.0.20 ein Problem und du musst entweder diesen debuggen oder die Empfehlung von k.osmo berücksichtigen.
Offline
Konntest du deine Vermutung nicht verifizieren? Hier nochmals die Schritte, die chepaz empfiehlt:
$ drill archlinux.org $ drill -x 138.201.81.199 $ drill archlinux.org @8.8.8.8 $ drill -x 138.201.81.199 @8.8.8.8
Wenn die zweiten zwei Befehl funktioniert, aber die ersten beiden nicht, dann hat der Nameserver unter 10.0.0.20 ein Problem und du musst entweder diesen debuggen oder die Empfehlung von k.osmo berücksichtigen.
Also, zunächst mal getestet, ob mein Problem noch da ist, und versucht folgende Websites aufzurufen:
https://www.archlinux.org/news/ca-certificates-update/
http://www.cpan.org/
https://bbs.archlinux.org/viewtopic.php?id=237522
Bei allen dreien steht im Firefox-Browser: "Seite wurde nicht gefunden".
Dann obige "drill" Befehle ausgeführt.
$ drill archlinux.org
;; ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 47728
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; archlinux.org. IN A
;; ANSWER SECTION:
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 1097 msec
;; SERVER: 127.0.0.53
;; WHEN: Fri Nov 1 16:32:11 2019
;; MSG SIZE rcvd: 31
$ drill -x 138.201.81.199
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 26350
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; 199.81.201.138.in-addr.arpa. IN PTR
;; ANSWER SECTION:
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 997 msec
;; SERVER: 127.0.0.53
;; WHEN: Fri Nov 1 16:32:42 2019
;; MSG SIZE rcvd: 45
$ drill archlinux.org @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 64951
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; archlinux.org. IN A
;; ANSWER SECTION:
archlinux.org. 1348 IN A 138.201.81.199
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 19 msec
;; SERVER: 8.8.8.8
;; WHEN: Fri Nov 1 16:34:43 2019
;; MSG SIZE rcvd: 47
$ drill -x 138.201.81.199 @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 32045
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; 199.81.201.138.in-addr.arpa. IN PTR
;; ANSWER SECTION:
199.81.201.138.in-addr.arpa. 16932 IN PTR apollo.archlinux.org.
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 18 msec
;; SERVER: 8.8.8.8
;; WHEN: Fri Nov 1 16:33:29 2019
;; MSG SIZE rcvd: 79
Offline