Beiträge von ninguem

    Danke für eure Einschätzungen.

    Wenn ich die DNS-Einstellungen auf Standard zurücksetze, erhalte ich einen mail A-Record, der vermutlich auf meinen Webhostingserver verweist (IP mit 188.68.47), und einen webmail A-Record, der auf eine andere netcup IP (46.38.249.153) verweist. Dann lasse ich einfach beide drin.


    BTW sind meine grundsätzlichen DNS-Einstellungen zu lang gewählt?


    TTL 86400

    Expire 1209600

    Retry 7200

    Refresh 28800



    P.S. Welchem Zweck dient die db Subdomain nochmal? (auch IP mit 188.68.47)

    Und die autoconfig Subdomain kann ich rausnehmen, wenn ich entweder meine Emailkonto manuell konfiguriere oder die oben verlinkte Lösung versuche?

    Hallo.


    Bevor ich u.U. meine DNS-Einträge falsch setze bzw. ändere, wollte ich kurz nachfragen:


    - Kann ich bedenkenlos den MX-Eintrag für mail.meinedomain.de entfernen (d.h. der netcup.net MX-Eintrag genügt)? Falls ja, könnte ich doch auch den Subdomain-Eintrag für mail entfernen, oder nicht?


    - Und was ist mit dem autoconfig-CNAME-Eintrag, der auf autoconfig.netcup.net verweist? In diesem Thema wurde eine Alternative beschrieben, die auch gleich SSL aktiviert. (Allerdings für Android-Geräte, ich nutze Apple-Geräte.)


    - Wie lange dauert es im Durchschnitt, bis die DNS-Einträge unter "gültig" yes statt unknown zeigen? Dauert es am Wochenende einige Stunden länger?


    Vielen Dank für die Hilfe.

    Hab meine Maileinstellungen inzwischen schon auf verschiedenen Seiten testen lassen (s.o.) und eigentlich ist immer alles ok.

    So antwortete auch check-auth@verifier.port25.com für SPF, "iprev" und DKIM mit pass."iprev"  SPF check: pass
    "iprev" check: pas
    DKIM check: pass

    Eine Weiterleitung deiner Mail von einem fremden Account zu Google kann schon schwierig werden. Der fremde Mailserver, der ursprüngliche Empfänger, ist nicht legitimiert, für deine Domain Mails zu versenden. Je nachdem wie er es macht stimmt dann meist entweder der DKIM-Key oder SPF nicht. Und Google ist nun mal relativ kleinlich (oder halt korrekt) in solchen Fällen.

    Ist schon wieder passiert.

    Ich kann ja vorher nicht wissen, ob Empfänger ihre Mails zu Google Mail um-/weiterleiten oder eine eigene Domain z.B. zusammen mit Google Workspaces für ihre Emailabwicklung nutzen.


    Wenn ich möchte, dass meine Emails (auch bei Googleadressen) ankommen und nicht ungelesen im Spamordner landen - oder gleich zurückgewiesen werden-, habe ich dann überhaupt eine andere Wahl, als die policy auf p=none zu setzen? Doch würde das nicht dmarc als Schutz gegen Absenderfälschung aushebeln?


    Wenn ich ohnehin p=none einstelle(n muss), kann ich zumindest die report-Emailadresse rausnehmen, damit ich nicht andauernd solche Berichte erhalte.

    Kurze Nachfrage: Ist 209.XX.XX.XX die/eine der Domäne meinedomain.de
    zugeordnete IPv4-Adresse?

    Nach kurzer Recherche: die 209er IP scheint Google zugeordnet zu sein.

    Ist es möglich, dass die Fehlermeldung zustandekommt, wenn der Empfänger

    - entweder meine Email an empfaengerdomain.com an seine gmail.com Adresse weiterleitet

    - oder wenn er empfaengerdomain.com bei Google aufgeschaltet hat? (Man kann ja m.W.n. bei Google oder mailbox.org eigene Domains nutzen/aufschalten.)


    zum Testen habe ich die Seite https://mxtoolbox.com/ genutzt sowie https://www.mail-tester.com/

    Mit mxtoolbox hatte ich bereits getestet, keine Auffälligkeiten. Das Ergebnis von mail-tester scheint ja ok zu sein, oder nicht?


    [Blockierte Grafik: https://img.adminforge.de/rKx7E6px/B42Dw4oH.jpg]

    Hallo.


    Ich befürchte, dass Empfänger, mit denen ich zuvor noch nie gemailt habe, meine Emails evtl. nicht erhalten. Nachfragen kann ich auch nicht, weil ich nur deren Emailadresse habe.

    Hier zunächst einmal die aktuellen Mail-DNS-Einstellungen für meinedomain.de:

    Code
    @			TXT	    v=spf1 mx a include:_spf.webhosting.systems ~all
    @			MX    10    mx2f8c.netcup.net
    key1._domainkey		CNAME	    key1._domainkey.webhosting.systems
    key2._domainkey		CNAME	    key2._domainkey.webhosting.systems
    _dmarc 			TXT         v=DMARC1;p=none;rua=mailto:report.dmarc@meinedomain.de;fo=1;adkim=s;aspf=s


    Wenn ich nun eine Email verschicke - an eine gmail.com-Adresse oder wie in diesem Fall an adressteil@domaindesempfaengers.es, deren Domain möglicherweise mit Google Mail verwendet wird - erhalte ich nach einer gewissen Zeit (1 Tag oder mehr) folgenden DMARC report von Google zurück (persönliche Angaben des Empfängers etc. anonymisiert):



    Habe ich falsche Einstellungen? Etwas vergessen? Bin etwas ratlos...

    Danke.

    Die Hauptdomain hättest du m.E. nicht aus dem WCP löschen müssen, kannst du aber im CCP selbst wieder erneut deinem WCP/Hosting zuweisen, wenn ich mich recht erinnere.


    Doch ich bin recht sicher, dass wallabag noch nicht php 8.0 unterstützt. Shell php-Version (gilt für alle Verzeichnisse, egal ob / oder /wallabag) kann von der Webhosting-Version abweichen.

    Ändere mal in der Datei /conf/phpversion die 80 in 74 und warte einige Stunden, bis die Ausgabe von php -version im Terminal dir als Version 7.4.16 anzeigt. Die Shell php Version wird AFAIK jede Stunde(?) erneut verlinkt.

    Dann versuch noch mal eine Installation. Viel Glück.

    .htaccess und parameters scheinen i.O. zu sein.

    Bei mir läuft web/cli ne 7.4 Version.

    Überprüf mal mit cat /conf/phpversion, ob PHP CLI bei dir auch 7.4 ist.


    Auch wenn es als Ursache weniger wahrscheinlich ist: PHP open_basedir restrictions / disable_functions hast du auch keine gesetzt bzw. vom Support setzen lassen? Wallabag braucht sicher mal curl_exec() und curl_multi_exec()

    Und bei der DB hast du zunächst mal "Verbindungen von allen Remotehosts akzeptieren"? Oder sonstige Restriktionen bei Apache/Nginx Settings (Test ggf. mit neuer Subdomain)?


    Mehr Ideen habe ich i.M. leider auch nicht.

    Habe es heute für dich mal ausprobiert, von Null bis zum ersten Anmelden. Funktioniert ohne Probleme (shared webhosting):


    - eine neue MySQL-DB und gleich einen dazugehörigen DB-Benutzer im netcup-WCP anlegen, jeweils mit unterschiedlichem Namen und mit Passwörtern, die weder sehr lang sind noch problematische Sonderzeichen enthalten, evtl. auch die DB der Seite zuweisen.

    - Ordner erstellen für die Domain (z.B. wallabag.domain.de) und im WCP der Domain als Rootordner zuweisen

    - in den Ordner wechseln und wget https://static.wallabag.org/releases/wallabag-release-2.4.2.tar.gz

    - mit tar xvf wallabag-release-2.3.8.tar.gz --strip-components=1 entpacken, aber nicht in irgendeinen Unterordner, deshalb --strip-components=1

    - .htaccess (s.o.) erstellen und parameters.yml anpassen. Emaildaten sind mit Ausnahme von from_email (z.B. noreplay@domain.de) nicht zwingend notwendig, insbes. weil ja jetzt auch OTP als 2FA unterstützt wird.

    - im Ordner wallabag.domain.de php bin/console wallabag:install --env=prod aufrufen, dann Reset der erstellten DB, Admin anlegen usw.

    - php bin/console cache:warmup --env=prod funktioniert auch

    - noch rm -rf var/cache/*

    und dann wallabag.domain.de im Browser aufrufen


    Versuchs mal mit komplett neuer Datenbank und einfachen kurzen PW.

    Andere Ideen habe ich i.M. leider auch nicht.

    Viel Glück.

    Hey.


    Beim Überfliegen deiner parameters.yml fiel mir nur auf, dass


    database_driver_class: null


    fehlt. Ob es ein Problem gibt, wenn Datenbankname und Datenbankbenutzername identisch sind, kann ich nicht beurteilen.


    Außerdem nehme zum Löschen des Caches, und zwar nach jeder noch so kleinen Änderung an der Konfiguration, immer rm -rf var/cache/* und nicht den offiziell dokumentierten Befehl.

    Viel Glück.

    Hallo.


    Ich (Webhosting 2000) erhalte seit heute eine Fehlermeldung, wenn ich einen mysqldump einer Datenbank mit mysqldump -h 10.11.12.13 -u k12345_dbuser --password='db_password' db_name ausführe:


    Zitat

    mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces


    Es spielt keine Rolle, wo und wie ich den Befehle ausführe (shell, cron, Skript).


    Der Dump wird trotzdem (korrekt?) ausgeführt, soweit ich sehen konnte.

    Es ist nur nervig, weil mein cronjob dann immer eine Fehlermail schickt. Ganz deaktivieren wollte ich die Fehlermeldung für den cronjob auch nicht, damit ich immer noch benachrichtigt werde, falls mal etwas total schief läuft.


    Erhaltet ihr auch diese Fehlermeldung bei einem dump?

    Kann ich irgendwelche Parameter/flags setzen, um den Fehler zu vermeiden?


    Danke.

    Minor Updates

    (z.B. von 2.4.0 auf 2.4.1)


    Kleinere Updates laufen im Grunde wie größere ab, nur dass (meistens) keine SQL-Befehle benötigt werden.


    Dazu noch einige kurze Anmerkungen:


    1. Es gibt noch eine alternative Download-URL für das jeweils aktuellste Paket, so dass der Befehl im neu erstellten Rootverzeichnis dann entsprechend lautet:

    wget https://wllbg.org/latest-v2-package && tar xvf latest-v2-package --strip-components=1


    2. Es scheint wichtig zu sein, dass eure Datei parameters.yml alle(!) möglichen wallabag-Parameter enthält, ob ihr die nun verwendet oder nicht.

    Also vorher schnell einen Blick in die aktuelle Übersicht aller möglichen wallabag Parameter werfen und eure Datei ggf. entsprechend anpassen.

    Falls ihr dann nach dem Löschen des Caches immer noch einen weißen Bildschirm statt des Anmeldebildschirms erhaltet, einfach in den WCP PHP-Einstellungen mal temporär das Error Logging aktivieren. Dort wird der fehlende Parameter dann moniert/aufgeführt.


    3. Wen es interessiert... folgende Ordner sind für ein funktionierendes Wallabag m.E. nicht essentiell (ist eben ein fertiges Paket und kein github repo):


    Update von v2.3 auf v2.4


    unterstützt jetzt php 7.4 !!! (im WCP php auf v7.4 umstellen)

    + OTP als 2FA statt nur Mail


    So habe ich wallabag v2.3 auf v2.4 aktualisiert:


    Backup
    - eine Kopie der Dateien .htaccess und app/config/parameters.yml sichern

    - Backup der aktuellen Datenbank erstellen. Angaben im Beispiel durch eure ersetzen: mysqldump -h 10.11.12.133 -u k12345_BENUTZERNAME --password='Datenbank-BenutzerPasswort' k12345_DATENBANKNAME > pfadzurdatei/wallabag-datenbank-pre2.4update.sql

    - Ordner mit wallabag umbenennen (z.B. wallabag.domain.tld -> wallabag.domain.tld_ALT )


    - Ordner für wallabag 2.4 erstellen + in neuen Ordner wechslen: mkdir wallabag.domain.tld && cd wallabag.domain.tld

    - wallabag 2.4 herunterladen und entpacken: wget https://static.wallabag.org/releases/wallabag-release-2.4.0.tar.gz && tar xvf wallabag-release-2.4.0.tar.gz --strip-components=1


    - .htaccess in aktuellen Ordner und parameters.yml in apps/config/ kopieren

    - in parameters.yml Werte hinzufügen, die mit 2.4 neu hinzugekommen sind:

    Code
        mailer_port: 465
        mailer_encryption: ssl    mailer_auth_mode: login
        fos_oauth_server_access_token_lifetime: 3600    fos_oauth_server_refresh_token_lifetime: 1209600
        sentry_dsn: null

    ssl, weil tls nicht funktionierte bei mir.


    - im netup WCP unter Datenbanken bei der wallabag.Datenbank auf phpMyAdmin klicken

    - links gesamte wallabag-Datenbank auswählen und dann im rechten Fensterteil oben auf den Reiter SQL klicken

    - dort die nachfolgenden SQL-Befehle hineinkopieren und dann rechts weiter unten auf OK klicken


    Quelle



    - Die Befehle sollten ohne Fehler ausgeführt werden.

    - Jetzt noch im Rootverzeichnis (wallabag.domain.tld) den Cache manuell löschen mit rm -rf var/cache/*


    Das wars, glaube ich. IMHO ist der Updateprozess schon noch ein Krampf, der zuviel Zeit verschlingt, aber am Ende funktionierts...


    BTW falls ihr die php disable_functions eures Hostings angepasst habt: wallabag benötigt curl_exec() und curl_multi_exec()

    Viel Glück.

    Ok, das klingt sehr interessant. Find die Infos auf github auch sehr inspirierend. Ist vielleicht sogar mehr, als meine Bedürfnisse erfordern bzw. meine Fähigkeiten zulassen. :)

    Liegt dein NC data-Verzeichnis eigentlich außerhalb/oberhalb deines Nextcloud-Ordners? Falls ja, wie schaffst du es, dass NC trotz open_basedir darauf darauf zugreifen kann?

    Oder ist es wieder dein Wrapper, der das erlaubt?

    Ist für CLI (siehe php.ini aus dem Repo) und HTTP (über den Support) deaktiviert.

    Danke für die Antwort.

    Das wusste ich bis jetzt nicht: Mit deiner php.ini kannst du php CLI selbst konfigurieren? (http nur über Support)

    Und das bezieht sich auf einen Webhosting-Tarif?

    Wo genau legst du die php.ini denn ab (Pfad)?

    Bei mir im Webhosting kann ich z.B. die phpversion in /conf/phpversion ändern, der Link ändert sich leider nicht. Dachte daher immer, sowas hätte im Webhosting keinen Effekt und müsste immer über den Support laufen.

    Und kann ich für einzelne (Subdomain-)Ordner Ausnahmen für die php CLI Einstellungen erstellen? (Wie?)

    Vielen Dank. Hab ich wieder was gelernt.

    Ich glaub, jetzt isses soweit. Meine Nextcloud hat das gelesen und sich verabschiedet. Update auf 19.0.4 wie bisher immer mit dem Web-Updater. Jetzt hängt der bei Step 9, also beim Löschen der alten Dateien.

    Ja, das letzte Update war eines, das bei mir nach einigen Versionen ohne Probleme wieder schief gelaufen ist. Und dabei update nicht mal über den Webupdater, sondern mit einem Skript und occ. Hab jetzt vorsichtshalber mal einen Cronjob angelegt, der jede Nacht die config.php und die Datenbank sichert, mit Datum und NC-Version im Dateinamen. Dann ist die Wiederherstellung in Zukunft hoffentlich einfacher und vor allem schneller. Hab keine Lust, so viel Zeit in die Wartung und vor allem Fehlerbehebung zu investieren.

    Da zweifle ich nicht dran, denn ich habe es auf shared Webhostings zweier Mitbewerber gefunden.

    Support sagt nein nein nein. Doch es wurden ja auch hin und wieder, wenn auch selten neue aufgenommen. Ob das nun gerade passiert, weil ich Nextcloud cron job sich beschwert... Aber wer weiss...

    Das Script ist in genau diesem Repo enthalten. Ich verwende diesen Wrapper hauptsächlich für eine bestimmte PHP-Version und angepasste php.ini :)


    NC20 habe ich noch nicht getestet. Ich bin noch auf v18. Fürs Upgrade oder eine wenigstens Testinstallation werde ich vor Dezember auch keine Zeit haben.


    Bezüglich Cron-Problem, siehe Nachbarthread. Da habe ich gerade etwas dazu geschrieben.

    Vielen Dank. Hab gesehen, du hast auch eine php.ini-Vorlage. Also Nextcloud läuft ohne Probleme, wenn exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source deaktiviert sind?

    Hast du diese Funktionen nur für http oder auch für CLI deaktiviert?


    P.S. Ich glaube, die mit pcntl_ davor sind bereits deaktiviert.

    :) Stimmt. Bin heute nicht so in Form, hätte ich wirklich an den Kundensupport schicken sollen.

    Was ist das für ein Produkt ? Was passiert, wenn du awk und ps mit absoluten Pfaden angibst ?

    Nextcloud (nextcloud.com) halt. Die Aufrufe mit awk oder ps erfolgen irgendwo tiefer in Code, den cron.php dann aufruft.

    awk und ps sind im Webhosting nicht zu aufzurufen, auch nicht manuell.

    Hallo.


    Seit dem Update auf Nextcloud 20 erhalte ich andauernd Emails mit Fehlermeldungen, dass der Nextcloud cronjob (cron.php) die Befehle awk und ps nicht findet.

    Mit ist bekannt, dass im Webhosting nur eine sehr limitierte Auswahl an Befehlen unter /bin zur Verfügung gestellt wird.


    Doch ich wäre trotzdem sehr dankbar, falls Sie diese beiden Befehle (awk und ps) hinzufügen würden, damit Nextcloud problemlos funktioniert.

    Vielen Dank.