Beiträge von DerRené

Guter Tipp frank_m! Ich vergesse immer, dass man an einer Fritzbox auch tcpdumps erstellen kann.

Ergebnis: Mit der DDNS-Methode scheint der VPN-Aufbau die Fritzbox gar nicht erst zu erreichen, was meine Vermutung, dass das Problem beim Pixel irgendwo liegt, weiter verstärkt.

Nagut, dann klemme ich mich doch mal per adb ans Pixel, mal sehen ob dort mehr zu erkennen ist.

Gesagt, getan.

Logcat mit erfolgreichem VPN-Aufbau per IP:

08-06 19:47:44.552  1733  3671 I Vpn     : Switched from [Legacy VPN] to [Legacy VPN]
08-06 19:47:44.552  1733  3671 D Vpn     : setting state=IDLE, reason=prepare
08-06 19:47:44.552  1733  3671 D Vpn     : setting state=CONNECTING, reason=startLegacyVpn
08-06 19:47:44.556  1733 29057 D Vpn     : setting state=CONNECTING, reason=execute
08-06 19:47:45.603  1733 29057 D Vpn     : setting state=CONNECTED, reason=agentConnect
08-06 19:47:51.532  1733  3716 D Vpn     : setting state=DISCONNECTED, reason=agentDisconnect
08-06 19:47:51.547  1733  3716 I Vpn     : Switched from [Legacy VPN] to [Legacy VPN]
08-06 19:47:51.548  1733  3716 D Vpn     : setting state=IDLE, reason=prepare

Logcat mit erfolglosem VPN-Aufbau per Hostname:

08-06 19:48:25.112  1733  6297 I Vpn     : Switched from [Legacy VPN] to [Legacy VPN]
08-06 19:48:25.113  1733  6297 D Vpn     : setting state=IDLE, reason=prepare
08-06 19:48:25.113  1733  6297 D Vpn     : setting state=CONNECTING, reason=startLegacyVpn
08-06 19:48:25.179  1733 29396 D Vpn     : setting state=CONNECTING, reason=execute
08-06 19:48:25.653  1733 29396 D Vpn     : setting state=FAILED, reason=racoon is dead

Erste kurze Recherche (racoon is dead ... lese ich btw zum ersten mal) ergibt, dass das auf Zertifikatsfehler hindeutet. Natürlich gibt's da kein Zertifikat, ist nur ein DynDNS A-Record.. ich recherchiere mal weiter.

Nun benötige ich auch mal Unterstützung durch die Schwarmintelligenz.

Von unterwegs aus soll per VPN auf das Heimnetz zugegriffen werden - klappte bisher auch wunderbar.

Ausgangssituation: Fritzbox 7590 hinter einem FTTH-Modem an einem vollwertigen DualStack-Anschluss der Telekom + Pixel 4a (Android 11). Home-IP über DDNS abrufbar. (nutze sehr zufrieden dynv6.com - myfritz wird nicht genutzt, da der Android-VPN Dienst Probleme mit der IPv6-Adresse hat - also wurde mit dynv6 ein eigener A-Record erzeugt, der nur die IPv4 ausliefert - das klappt auch einwandfrei)

Problem: das lief eine ganze Weile sehr zuverlässig, neuerdings quittiert das Pixel den Verbindungsaufbau einfach mit "Nicht erfolgreich", was natürlich mega aussagekräftig ist und der Lösungsfindung enorm dienlich ist...

Das Kuriose dabei ist:

- Teste ich es mit denselben Credentials an einem anderen Handy (Nokia 7.1, Android 10) klappt es einwandfrei.

- Gebe ich dem Pixel statt der DDNS-Adresse die direkte IPv4 mit, klappt es auch!

Gut dachte ich mir, dann kann das Pixel, aus welchen Gründen auch immer, den Hostnamen nicht auflösen. Aber teste ich es auf dem Pixel in einer termux-Sitzung mit "dig +short ipv4.domain.de" gegen, erhalte ich die korrekte IPv4-Adresse, mit der die Verbindung bei Direkteingabe aufgebaut werden konnte.

Irgendwelche Ideen woran es liegen könnte? Private DNS ist ebenfalls abgeschaltet auf dem Pixel.

Es muss ja an irgendeinem Android-Update liegen, schließlich lief das Setup eine ganze Weile so.

Hab auch schon überlegt mich per logcat ans Pixel zu hängen, aber von den Logs wird man ja auch nur erschlagen.

Wenn alles nichts nutzt, wirds wohl auf ein Wireguard-Setup hinauslaufen. Bevorzuge aber eigentlich die Fritzbox Lösung, da es ein Setup weniger wäre, um das ich mich selbst kümmern müsste und die VPN-Verbindung nur selten benötigt wird - und hier zuhause laufen schon ohnehin viel zu viele Dienste auf meiner Spielwiese.

Bin dankbar für jeden Input.

PS: Hmm... gibt aber auch nicht wirklich ein geeignetes Unterforum für solche netcup-fremden Themen, oder? Naja was solls, dafür haben wir ja das längste Thema. Ach doch, unter sonstiges hätte ich schreiben können... egal, hier im Thema versammeln sich ja alle Geeks.

Zitat von Dirk67

der netcup support hat mir gerade geschrieben, dass ich die Schritte aus dem verlinkten Artikel machen soll: https://docs.joomla.org/Joomla_and_MySQL_8

Ich wüsste nicht, wie man die im Joomla-Artikel beschriebenen Änderungen als Kunde in einem Shared Webhosting durchführen sollte - so ohne Root Zugriff. Ich denke dass es hier zu einem Missverständnis kam.

Da Lars aber schreibt, dass mysql_native_password seitens Netcup gesetzt wird, kannst du dich diesbezüglich entspannt zurücklehnen.

Zitat von Valkyrie

Was nutzt ihr denn so als täglichen Browser?

Firefox, sowohl mobil (Android) als auch am Desktop (Win 10, Debian).

Aber das ist ohnehin ein interessantes Thema, ich weiß nicht wie lange sich Mozilla mit dem Firefox noch über Wasser halten kann. Die Marktanteile sinken immer weiter. Ich versuche Google zu meiden wo es geht (und es die Bequemlichkeit zulässt ohne zu große Opfer), aber wenn das so weitergeht, muss ich mir wohl irgendwann wirklich einen Chromium basierten Browser als Hauptbrowser festlegen.

Damit ist es offiziell, das Längste Thema bekommt einen eigenen Index und ist quasi als eigenes Unterforum anzusehen. Genial.

Coole Idee. Prima fänd ich ja, wenn es keinen Seitenbruch gäbe, die Lesezeichen also quasi direkt im Wotlab als Plugin zur Verfügung stünden. Aber gut, solche Spielereien muss man sich dann für's eigene Forum aufheben. Der Ansatz gefällt mir aber sehr. In den 37k Beiträgen ist defintiv der eine oder andere Schatz vergraben.

Da bin ich dann leider auch raus - mehr gibt die Anleitung diesbezüglich nicht her.

Könntest dich aber stattdessen mal im TT-RSS Forum melden und dein Problem schildern. Dort kennt man das Produkt einfach besser.

Zitat von androidin

Wie hast du das entdeckt, dass man das klein schreiben muss?

Die Fehlermeldung ist hier etwas schwach. Habe mir daher den Quellcode im tt-git angesehen und die Stelle rausgesucht, wo der Wert abgefragt wird (hab ich sogar extra verlinkt zum selber nachschlagen --> https://git.tt-rss.org/fox/tt-rss/src…config.php#L558). Daraufhin genau so geschrieben, wie es im Quellcode steht und es funzte auf Anhieb.

Zitat von androidin

Running under systemd

Auf systemd hast du im Webhosting keinen Zugriff, das wird also nichts.

Die anderen beiden Punkte dürften aber sehr wohl zum Erfolg führen:

"Periodical updating from crontab, using update script"

Dafür könntest du im WCP einen Cronjob anlegen, ähnliche Syntax wie beim Install-Script.

Siehe Netcup-Wiki: https://www.netcup-wiki.de/wiki/Plesk_Ony…hinzuf.C3.BCgen

Oder du aktivierst

"Simple background updates"

Dann wird es offenbar mit jedem Aufruf der Webseite getriggert. Besuchst du die Webseite länger nicht, gibts dann natürlich auch keine Updates. Ich würde die Cronjob-Variante wählen und z.B. alle 15 Minuten oder so updaten lassen.

Der einfachste Weg dürfte sein:

WCP -> Datenbanken -> phpmyadmin und dort den Befehl dann entsprechend anpassen und abfeuern:

pasted-from-clipboard.png

Edit: gnarr.... zu spät gesehen, dass du die Lösung bereits hattest.

Zitat von androidin

bash-4.4$ /usr/local/php73/bin/php reader.mydomain.de/tt-rss/update.php --update-schema
<pre>Exception while creating PDO object:could not find driver</pre>bash-4.4$

Ich habe das eben mal nachgestellt und siehe an, die Werte in der Config sind case sensitive (siehe hier). Statt MYSQL musst du mysql eintragen, dann findet er auch den korrekten pdo-Treiber und legt das DB-Schema an.

in der config.php muss es also konkret so heißen:

putenv('TTRSS_DB_TYPE=mysql');

Hier mein Test mit MYSQL:

bash-4.4$ /usr/local/php74/bin/php ./update.php --update-schema
<pre>Exception while creating PDO object:could not find driver</pre>bash-4.4$ ^C

Und danach mit mysql:

bash-4.4$ /usr/local/php74/bin/php ./update.php --update-schema
[15:44:32/11112] Lock: update.lock
[15:44:32/11112] Type 'yes' to continue.
yes
[15:44:35/11112] Loading base database schema...
[15:44:36/11112] Migration finished, current version: 145

Ist schon blöd, wenn selbst die offizielle ANleitung, trotz deprecated, hier zu ungenau ist.

Der Rest sollte ja dann durchlaufen. Ansonsten nochmal Bescheid geben, noch hab ich die Testinstallation nicht gelöscht.

Ich lehne mich mal weit aus dem Fenster und behaupte: wer dazu imstande ist, hosted den Kram auch einfach auf dem eigenen Server.

Ich verstehe schon warum die Entwickler offiziell nur noch die docker-Variante supporten (die auf einem Webhosting natürlich nicht läuft). Mit docker ist das Thema Abhängigkeiten natürlich viel leichter zu lösen - auch wenn ich selbst kein großer docker Fan bin.

Die hiesige Installationsmethode wird ja offiziell gar nicht mehr länger unterstützt:

Zitat von tt-rss wiki

Host installations are not supported starting 2021. Consider using Docker when planning new tt-rss installations.

Ggf. wäre eine alternative RSS-Software hier zielführender (kenne mich da aber nicht aus um eine Empfehlung geben zu können).

Zitat von androidin

Welchen Port muss ich denn eingeben?

Bei putty für ssh? Den Standardport 22.

Mich wundert in dem Fall halt wirklich, dass ich mit demselben Testszenario und derselben Domain keine Probleme beim Zugriff hatte - du aber selbst mit mobilen Daten das Problem nachstellen konntest. Sehr kurios...

Auch der Zugriff klappt von mir aus problemlos.

Wir versuchen es auch gerade etwas einzugrenzen. Ich habe es von meinem FireTV aus ebenfalls getestet seine Webseite aufzurufen und das klappte problemlos*.

* zunächst gab es einen Fehler wegen des Plesk Defaultzertifikats, da ludt er bei mir auch ewig (also exakt wie er beschrieb). Direkter http-Aufruf klappte auf Anhieb. Ein LE-Zertifikat wurde nun aber von ihm gesetzt und von mir aus klappt nun auch der https-Zugriff auf seine Webseite. Bei ihm offenbar immer noch nicht.

Könnte ggf. noch ein Cache querschießen - am besten mal wo möglich löschen/neustarten usw.

Zumindest kann ich von meiner Warte aus keinen Serverfehler nachvollziehen.

Habe den Test eben gemacht, die Downloader-App auf dem Firetv-Stick konnte problemlos die Webseite öffnen. (meine Webseiten waren übrigens heute morgen auch von den Wartungsarbeiten betroffen).

Vielleicht magst du mal die Webseite konkret benennen? (hier oder per PM)

Ansonsten wie gesagt mal die Logs prüfen, da sollte ja irgendwas auftauchen.

Ich sehe eigentlich keinen großen Unterschied, ob man nun per Browser oder anderen HTTP Client auf den Webspace zugreift.

Hier würde ich an deiner Stelle mal die Logs prüfen. Zum einen die Webserver Logs und zum anderen die Kodi Logs (hier ggf auf Debug umstellen für mehr Output).

Zitat von m_ueberall

allerdings nicht in Verbindung mit einem Webhosting

Das war für mich der ausschlaggebende Punkt, nicht von einem gewollten Round Robin auszugehen. Aber du hast völlig Recht, es gibt durchaus Szenarien in denen diese DNS-Records so Sinn machen würden - hätte ich etwas neutraler formulieren sollen. Dennoch habe ich hier meine Zweifel.

Nabend.

Was mir sofort auffällt ist, dass du die Records für Domain (@) und Wildcard (*) doppelt vergeben hast jeweils mit einer anderen IP, siehe Markierung:

pasted-from-clipboard.png

Das sollte tunlichst vermieden werden - entscheide dich jeweils für EINEN @-Eintrag und EINEN *-Eintrag.

Dann weiter:

Was meinst du genau mit:

Zitat von Nimream

wenn ich mich bei meiner Email anmelden möchte

Wo genau? Webmail? Mailprogramm (falls ja, welches mit welchen hinterlegten Servereinstellungen)?

Es handelt sich hier übrigens um ein Forum, nicht um einen Chat. Aber das nur als Randbemerkung.

Die automatische URL-Umwandlung kannst du hier umgehen, indem du beispielsweise die Inlinecode-Funktion pasted-from-clipboard.png nutzt: google.de, netcup.de, www.example.de. Die Autokorrektur hat hier schon öfter für Verwirrung gesorgt.

Zurück zum Thema: https wird von immer mehr Browsern forciert und irgendwann die Standardanfrage eines Browsers sein (siehe Chrome, Firefox verfolgt glaube ich ähnliche Ziele). Ist also nicht verkehrt diesen Seitenaufruf fehlerfrei anzubieten.