Posts by Twisterado

    Steini vielen Dank nochmal auch für deine Hilfe!

    Ich habe das Problem lösen können, zumindest sieht es so aus.

    Nachdem leider auch mit deinen Tipps aus dem letzten Beitrag keine Fehler in der error_log aufgetaucht sind, habe ich es mit der Datenbank einer anderen YOURLS-Installation versucht, indem ich diese in der config.php angegeben habe. Auf einmal funktionierte das weiterleiten und loggen problemlos.

    Nach weiterer Recherche war scheinbar die log-Tabelle in der Datenbank beschädigt, ich weiß es nicht, die beiden wichtigeren, url- und options-Tabellen konnte ich behalten, die log-Tabelle hab ich neu erstellt und damit ist das Problem gelöst und alles funktioniert!

    Vielen Dank für eure Vorschläge!

    Ich schaffe es leider es jetzt, mich wieder mit dem Thema auseinanderzusetzen.

    moritzh Ja, ich hab in beide reingeschaut, sind alle leer.


    Steini Ja, andere PHP-Skripte funktionieren.

    Die Console von Chrome sagt nichts.


    Ich hab das mit dem die('it works'); ausprobiert und habe tatsächlich etwas eingrenzen können, aber Sinn macht es in meinen Augen nicht.


    PHP: yourls-loader.php
    1. // Redirection:
    2. if( preg_match( "@^([$pattern]+)/?$@", $request, $matches ) ) {
    3. $keyword = isset( $matches[1] ) ? $matches[1] : '';
    4. $keyword = yourls_sanitize_keyword( $keyword );
    5. yourls_do_action( 'load_template_go', $keyword );
    6. require_once( YOURLS_ABSPATH.'/yourls-go.php' );
    7. exit;
    8. }

    Setze ich in der yourls-loader.php das die() vor die Zeile 37, wird es ausgegeben und kein 500er.

    Also weiter in der yourls-go.php

    PHP: yourls-go.php
    1. // URL found
    2. if( !empty( $url ) ) {
    3. yourls_redirect_shorturl($url, $keyword);
    4. // URL not found. Either reserved, or page, or doesn't exist
    5. } else {
    6. [...]
    7. }

    Setze ich hier das die() vor Zeile 21, wird es ausgegeben.

    Die Funktion yourls_redirect_shorturl() finde ich in der functions.php

    Hier funktioniert alles, wenn ich das die() vor Zeile 740 setze bzw. diese auskommentiere.

    Die Funktion yourls_log_redirected() finde ich weiter unten in der functions.php

    Hier tritt der Fehler in Zeile 897 auf. Wenn ich das Ergebnis der Zeile erst in eine Variable speichere und danach returne, funktioniert es trotzdem nicht, also muss der Fehler in der Funktion fetchAffected() liegen.

    Diese Funktion finde ich in der Datei ExtendedPdo.php

    PHP: ExtendedPdo.php
    1. public function fetchAffected($statement, array $values = array())
    2. {
    3. $sth = $this->perform($statement, $values);
    4. return $sth->rowCount();
    5. }

    Hier wird das die() ausgegeben, wenn ich es vor Zeile 307 setze. Wenn ich aber das Ergebnis der Zeile erst in eine Variable speichere, scheitert es erst beim return. Sprich ich kann rowCount() ausführen, ohne 500er, sobald das Ergebnis zurückgegeben wird, scheitert es.

    Eigentlich dürfte das ja nicht sein, denn es wird ja an die yourls_log_redirect() aus der functions.php zurückgegeben, die nur scheitert, wenn die Funktion fetchAffected ausgeführt wird, aber in der Funktion fetchAffected kann das Problem ja auch nicht liegen, wenn sie alles erfolgreich machen kann und es erst beim returnen scheitert.


    Ich hoffe es ist irgendwie nachvollziehbar, was ich gemacht habe!?

    Vielen Dank nochmal und schonmal für eure Unterstützung!

    nginx unterstützt keine .htaccess Dateien. Verstehe ich das richtig, dass du auf der einen Domain Apache nutzt und auf der anderen nginx?

    Quote

    Die Hosting- und PHP-Einstellungen sowie die Einstellungen für Apache & nginx sind ebenfalls identisch.

    error_log und proxy_error_log sind leer.


    .htaccess ist ebenfalls identisch, trotzdem:

    Auch wenn ich den oberen Teil rausnehme (der vorher auch funktioniert hat) und nur den YOURLS-Teil übrig lasse, ändert nichts.


    Die nginx-Proxy-Funktion kann ich deaktivieren und die 500er werden zu 404ern, weil die .htaccess nicht mehr abgefragt wird, wenn ich das richtig verstehe. Dann geben nämlich auch die /pages-Dateien einen 404er zurück, außer sie werden direkt aufgerufen.

    Yourls unterstützt von Haus aus nur eine Domain pro Installation. Könnte es vielleicht daran liegen? Hast du die config von yourls pro Domain angepasst? Ansonsten wäre z.B. das Plugin „Allow Aliases“ hilfreich: https://github.com/YOURLS/awes…rls/blob/master/README.md

    Die beiden Shortener sind unabhängig voneinander, keine Aliase, beide greifen auf unterschiedliche DBs zu.


    Beide Shortener haben vor 2 Wochen auch noch einwandfrei funktioniert, nun auf einmal der eine nicht mehr.

    Hast du zufällig unterschiedliche PHP Versionen eingestellt?

    Ansonsten ist da wohl der Support zuständig.


    Hast du eine error.log Datei im Log Verzeichnis? Schau da mal rein

    Ist dieselbe PHP-Version.


    error.log scheint es nicht zu geben.


    Was genau steht im Error Log? Ein kleiner Auszug, gerade bei Auftritt des 500er-Fehlermeldung(en) wäre definitiv Interessant.

    Hier mal die letzten Paar Einträge aus dem "SSL/TLS-Zugriff für Apache":

    Code
    1. 123.456.789.0 - - [05/Sep/2019:22:03:29 +0200] "GET / HTTP/1.0" 302 372 "-" "User Agent gekürzt"
    2. 123.456.789.0 - - [05/Sep/2019:22:03:30 +0200] "GET /admin/ HTTP/1.0" 200 6380 "-" "User Agent gekürzt"
    3. 123.456.789.0 - - [05/Sep/2019:22:03:33 +0200] "GET /admin/ HTTP/1.0" 200 6375 "-" "User Agent gekürzt"
    4. 123.456.789.0 - - [05/Sep/2019:22:03:35 +0200] "GET / HTTP/1.0" 302 372 "-" "User Agent gekürzt"
    5. 123.456.789.0 - - [05/Sep/2019:22:03:36 +0200] "GET /offline HTTP/1.0" 200 610 "-" "User Agent gekürzt"
    6. 123.456.789.0 - - [05/Sep/2019:22:03:46 +0200] "GET /chat HTTP/1.0" 500 340 "-" "User Agent gekürzt"
    7. 123.456.789.0 - - [05/Sep/2019:22:03:57 +0200] "GET /admin/ HTTP/1.0" 200 6377 "-" "User Agent gekürzt"

    Den User Agent hab ich der Übersicht halber mal rausgenommen und natürlich die IP verändert.

    Wie gesagt /admin und index.php funktionieren, genauso /offline, was eine Datei im /pages Ordner ist. /chat ist ein Keysord für eine Short-URL, die nicht funktioniert.

    Schönen Abend,


    ich habe ein überaus kurioses Problem, in meinen Augen: Ich habe zwei URL-Shortener hier bei Netcup unter zwei unterschiedlichen Domains: beispiel1.de und beispiel2.de

    Beide laufen mit YOURLS 1.7.3 (aktuellste) auf einem Webhosting Sommer 2019.


    Problem: bei beispiel2.de bekomme ich beim Aufruf jeglicher Short-URLs einen 500 Error, /admin und /pages sowie index.php funktionieren.

    Die Dateien von beispiel1.de und beispiel2.de sind identisch (abgesehen von den Datenbank-Infos in der config.php), ich habe auch schon alle Files gelöscht und von beispiel1.de rüber kopiert (und config.php wieder angepasst). Die Hosting- und PHP-Einstellungen sowie die Einstellungen für Apache & nginx sind ebenfalls identisch.

    Es gibt in meinen Augen absolut keinen Grund, warum bei einer Domain der Fehler auftritt, bei der anderen nicht. In den Protokollen, die man in Plesk abrufen kann, findet sich nur der 500er ohne jegliche Informationen, zumindest könnte ich keine finden.


    Alles, was die beiden Shortener unterscheidet, ist die Datenbank und dass beispiel1.de eine Inklusiv-Domain und beispiel2.de eine externe Domain ist, die aber vor einigen Tagen noch tadellos funktioniert hat. Ich habe überhaupt nichts verändert, seit es funktionierte das letzte mal, aber ein Blick in die Logs zeigt, dass schon seit etwas über einer Woche bei allen Short-URLs 500er auftreten.


    Vielleicht kann mir jemand helfen?

    Ich weiß es sind nicht viele Infos, aber fragt gerne, ich weiß nur wirklich nicht, was ich erzählen soll, weil ich gar nicht weiß, wo ich anfangen soll!


    Grüße,

    Twisterado

    Ich bin mir da zwar selbst gerade unsicher, aber ich würde sagen, durch die ID sind die Daten öffentlich zugänglich. Es ist ja schließlich möglich (unwahrscheinlich, aber möglich), dass zwei beinahe identische IDS generiert werden und der User sich vertippt und auf die "fremde" ID kommt. Oder durch ausprobieren (automatisiert, nicht händisch).


    Auf der anderen Seite denke ich mir dann aber auch, ob eine Seite, auf der ich mich einlogge, dann nicht auch öffentlich zugänglich ist, da ja theoretisch jemand meinen Username und Password erraten kann bzw. per Brüte Force herausfinden...


    Bin sehr gespannt, was andere hier dazu denken!

    Kürze Frage zu dem Tool. Habs nur kurz überflogen. So wie es aussieht, benötige ich dafür jeweils einen Backup Account, richtig? Also das Tool führt nur den Syn durch.


    Original (Account bei Anbieter A) - - > Backup (Account bei Anbieter B)


    Wobei man dafür ja auch nen eigenen IMAP Server verwenden kann.

    So verstehe ich es auch und das ist etwas viel Aufwand, verglichen mit einem einfachen dateibasierten Backup, zumindest in meinen Augen.

    Hätte mich echt mal interessiert, was so ein Restore kostet, also Danke für die Info!


    imapsync finde ich zwar auch interessant, habe bisher aber nur die Online-Variante getestet. Verstehe ich es außerdem richtig, dass ich die Software zwingend kaufen muss, um sie lokal laufen zu lassen? p4scal


    Ich benutze bisher Mailstore Home, das ist kostenlos und funktioniert super (macht die Backups auch gleich durchsuchbar), zudem speichert es die E-Mails als .eml Dateien, wodurch sie sich auch anders lesen lassen und über verschiedene Webmail-Clients (oder auch Thunderbird?) wieder hochladen lassen, sollte es mal Probleme mit Mailstore geben. Das läuft bei mir allerdings leider nicht automatisiert (gibt glaube ich auch keine CLI-Variante davon) und etwas nervig ist, dass Iman nur 3 IMAP-Postfächer auf einmal hinterlegen kann, d.h. wenn ich 3 Postfächer gesichert habe, muss ich eins rausnehmen (das Backup bleibt unberührt, nur die Zugangsdaten werden gelöscht), um ein neues hinzuzufügen. Das sorgt leider dafür, dass ich mein Backup nicht mit einem Klick auf alle Postfächer machen kann.


    Wenn also jemand eine kostenfreie Variante hat, die sich bestenfalls noch automatisieren lässt, wäre das super! Ich würde ein offline speichern als Datei bevorzugen gegenüber dem Backup-Postfach, wie es bei p4scal existiert.

    Also sieht ganz so aus, also hätte vmk recht.

    Offizielle Antwort des Hosters:

    Quote

    Bezüglich der Curl anfragen, sollte das nicht vorkommen aber es ist durchaus möglich das Firewall Updates / Webserver Neustarts miniatur Aussetzer verursachen.

    Mit dem offset, das ich eingetragen habe, läuft jetzt aber auch alles wie gewünscht.

    Danke euch!

    Nein, selbst nach einem Jahr bliebe die Inklusivdomain in deinem Webhosting registriert. Das ist an die Laufzeit des Webhostings gekoppelt und verlängert sich wohl automatisch, solange das Webhosting existiert. Loswerden kann man die also nur durch Kündigung des Webhostings :( oder durch Umzug zu einem anderen Registrar. Oder man nimmt halt einmalig die paar Euro in die Hand, die der Umzug durch den Support kostet.

    Wenn ich beispiel.de als Inklusiv registriere, kann ich die Domain nicht extra kündigen, ohne was drauf zu zahlen? Ich kann nicht sagen "verlängert die Domain einfach nicht und gebt mir meine Inklusiv-Domain zurück"?

    Das wird gehen, ist aber dann auch gebührenpflichtig. Ich würde ihn eher erst einmal mit einer Subdomain einer deiner eigenen Domains rumspielen lassen- Die kostet ja auch nichts und man hat später nicht das Problem, die Domain in das andere Paket transferieren (lassen) zu müssen.


    Edit: Die Daten wird man wohl so oder so selbst transferieren müssen, das ist aber auch kein großes Ding.

    Würde das nicht auch per regulärem Domain-Transfer gehen? Der wäre doch dann nicht kostenpflichtig, oder?

    Ist ein reines Webhosting-Paket ohne Zugriff auf SSH oder ähnliche Möglichkeiten, in der Vergangenheit war der Support aber idR sehr kooperativ, also werde ich mal abwarten, was die grundsätzlich zu der Sache sagen.


    Ich hatte in der Nacht auch zwei mal curl: (52) Empty reply from server und auch manchmal curl: (35) Unknown SSL protocol error in connection to domain.de:443

    Ein Muster kann ich da allerdings nicht ausmachen.

    Gäbe es irgendeinen logischen Grund, die Verbindungsaufnahme immer zur gleichen Zeit für wenige Sekunden zu verweigern? Denn schon 10s später läuft wieder alles, es ist immer nur von *:15:00 bis ca. *:15:10...

    Ok, also Entwarnung für meinen netcup Cronjob, der scheint alles korrekt zu machen, wenn der Cronjob zu genau der Zeit auf dem Pi läuft, bekomme ich den selben Fehler für die paar Sekunden.


    Jetzt bleiben natürlich zwei Fragen:

    1. Woran könnte das beim anderen Hoster liegen? Hast du da zufällig eine Idee? Ich werde wohl auch mal den Support kontaktieren und nachhaken.

    2. Falls sich beim anderen Hoster nichts machen lässt (oder als Übergangslösung bis dahin), wäre 1-59/15 * * * * doch eine Möglichkeit, den Cronjob mit einem offset von einer Minute laufen zu lassen, wenn ich das richtig verstehe.

    Ja, sorry, daran hab ich nicht gedacht.

    Alle 1.1.1.1 im Log sind von mir, da steht eigentlich die korrekte IP, es kam kein anderes mal eine andere IP vor.