Posts by ninguem

    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:


    Quote

    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
    1. mailer_port: 465
    2. mailer_encryption: ssl mailer_auth_mode: login
    3. fos_oauth_server_access_token_lifetime: 3600 fos_oauth_server_refresh_token_lifetime: 1209600
    4. 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.

    Hey @Fa!


    Ich erhielt damals andere Fehlermeldungen, die aber nicht so wichtig waren und die Funktion von wallabag auf netcup nicht beeinträchtig haben.

    Ohne zu wissen, welchen netcup Webhosting-Tarif du nutzt, fällt mir zu den beschriebenen "Symptomen" i.M. Folgendes ein:


    Bei mir haben zu lange PW oder solche mit Sonderzeichen bei der ein oder anderen Webanwendung schon mal Probleme verursacht. Meist nehme ich dann zunächst ein 20 Zeichen langes PW ohne Sonderzeichen. Falls das funktioniert, kann man sich ja immer noch an längere/komplexere PW herantasten.


    Ich gehe mal davon aus, daß PHP 7.3 für die wallabag Domain in WCP aktiviert wurde und die .htaccess 644 Rechte hat.

    Dann könnte die leere Seite mit dem Cache zusammenhängen. Einfach nochmal im Ordner, in dem wallabag liegt, den Befehl rm -rf var/cache/* ausführen, nachdem alle Änderungen an der Konfiguration abgeschlossen wurden.


    Viel Glück!

    Grüße


    N.

    Ich wollte occ nutzen um NC in und aus dem Maintenancemode zu holen.

    Dazu habe ich auch eine und damit das funktioniert habe ich auch im Nextcloud config Verzeichnis die Datei datadirectory.config.php erstellt:

    PHP
    1. <?php
    2. if (\OC::$CLI) {
    3. $CONFIG['datadirectory'] = '/httpdocs/nextcloud/data';
    4. } else {
    5. $CONFIG['datadirectory'] = '/var/www/vhosts/hostingxxxxxx.axxxx.netcup.net/httpdocs/nextcloud/data';
    6. }

    Jetzt läuft cli occ ohne Probleme:

    Code
    1. php -d memory_limit=512M /httpdocs/nextcloud/occ status

    Ich bin mir nicht sicher, ob das alles notwendig ist.
    Wenn du OC::$SERVERROOT vor den Pfad des datadirectory setzt, funktionieren bei mir sowohl occ als auch cron:

    Code
    1. 'datadirectory' => OC::$SERVERROOT . '/data',

    Analog funktioniert das bei mir auch für den Ordner tmp oder einen Ordner für selbst installierte Apps.


    Konntest du bei dir denn messbare Performancevorteile o.ä. feststellen, wenn du occ mit der Erhöhung des memory_limits aufrufst?

    P.S. Damit beim Speichern der Artikel auch deren Bilder (lokal) gespeichert werden, in den Einstellungen des wallabag-Admin-Benutzers unter Internal Settings > Misc bei Download images locally eine 1 eintragen und die Änderung unten mit Save sichern.

    Hallo.

    Ich wollte nur kurz beschreiben, wie ich Wallabag auf dem netcup Webhosting (Shared Hosting) installiert habe. Es läuft bis jetzt ohne Probleme, soweit ich das sehen kann.

    Ich erstelle eine Subdomain (z.B. wallabag.mydomain.tld) und ein entsprechendes Let's Encrypt SSL-Zertifikat. Auf der Sudomain läuft i.M. PHP 7.3.15 (hab irgendwo gelesen, wallabag hätte noch Probleme mit PHP 7.4).

    Und im WCP noch eine mySQL-Datenbank für Wallabag erstellen.


    Im Shared Hosting sind Befehle wie make nicht verfügbar. Doch zum Glück bieten die Entwickler von Wallabag fertige binary Pakete an, die bereits alle ansonsten zusätzlich zu installierenden Abhängigkeiten beinhalten.
    Die normale URL zum aktuellen Paket https://wllbg.org/latest-v2-package scheint i.M. nicht zu funktionieren (SSL-Zertifikatsprobleme), aber es gibt noch eine andere:
    https://static.wallabag.org/releases

    Dort den Link zur aktuellsten Version (i.M. Version 2.3.8) kopieren und dann bei netcup :
    cd wallabag.mydomain.tld
    wget https://static.wallabag.org/releases/wallabag-release-2.3.8.tar.gz

    Entpacken mit --strip-components=1, um nicht in einen Unterordner zu entpacken.
    tar xvf wallabag-release-2.3.8.tar.gz --strip-components=1

    Dann z.B. mit nano eine .htaccess Datei erstellen (immer noch im Ordner wallabag.mydomain.tld) mit folgendem Inhalt:

    RewriteEngine On
    # Rewrite auf https
    RewriteCond %{HTTPS} !=on
    RewriteCond %{ENV:HTTPS} !=on
    RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

    # wallabag Regeln
    RewriteBase /
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.*)$ /web/$1 [QSA,L]

    # Schutz für .htaccess Datei
    <Files ~ "^.*\.([Hh][Tt][Aa])">
    order allow,deny
    deny from all
    satisfy all
    </Files>
    Options -Indexes


    Dann z.B. mit nano die

    Parameter in der Datei app/config/parameters.yml anpassen.

    Den Werten, die ihr anpassen müsst, habe ich mal ein > vorangestellt:


    parameters:
    database_driver: pdo_mysql
    database_driver_class: null
    > database_host: 10.11.12.133
    > database_port: 3811
    > database_name: k12345_DATENBANKNAME
    > database_user: k12345_BENUTZERNAME
    > database_password: Datenbank-BenutzerPasswort
    database_path: null
    database_table_prefix: wallabag_
    database_socket: null
    database_charset: utf8mb4
    > domain_name: https://wallabag.mydomain.tld
    mailer_transport: smtp
    > mailer_host: mx1a2b.netcup.net
    > mailer_user: Mailkonto-Benutzername
    > mailer_password: Mailkonto-BenutzerPasswort
    locale: en
    > secret: hier_30-Zeichen-langes-Secret-wählen
    twofactor_auth: true
    > twofactor_sender: no-reply@mydomain.tld
    > fosuser_registration: false
    fosuser_confirmation: true
    > from_email: no-reply@mydomain.tld
    ...

    Dann im Ordner der Subdomain (wallabag.domain.tld) den wallabag-Installationsdialog starten mit

    php bin/console wallabag:install -e=prod


    Die Frage nach einem Datenbank-RESET und dem Erstellen eines Adminstrator-Benutzers mit YES beantworten.
    Für den Admin-Benutzer neuen Benutzernamen, Passwort und Emailadresse angeben. Sind nicht identisch mit irgendwelchen vorherigen Angaben.

    Dann vielleicht noch diesen Befehl ausführen (auch wenn ich nicht sicher bin, dass er unbedingt notwendig ist):
    php bin/console cache:warmup -e=prod


    Und jetzt kommts:

    Immer wenn ihr Änderungen an der Konfiguration vornehmt (z.B. in der Datei app/config/parameters.yml), müsst ihr anschließend den Cache löschen.


    Dafür gibt es zwar einen eigenen Befehl php bin/console cache:clear -e=prod,

    ABER anscheinend löscht der Befehl nicht oder nicht zuverlässig den Cache.


    Wenn der Cache aber mit
    rm -rf var/cache/*

    (ausgeführt im Ordner der Subdomain) gelöscht wird, funktioniert Wallabag.

    Das wars. :)

    Aber in der Web-Version ist es wohl enthalten

    Stimmt, hatte ich übersehen. Und ebenso richtig: Scheitert wohl an der Installation, weil im Webhosting Paket kein make verfügbar ist.


    in der Konsole hast du jedenfalls sogar im Webhosting 2000 schon deutlich mehr als 512 MB RAM zur Verfügung

    Kann sein, aber wenn ich php cli commands z.B. wie occ bei Nextcloud nutze, beschwerts sich regelmässig über ein Limit von 128MB. Ich weiss, dass ich das Limit für so einen Befehl erhöhen kann, wenn ich den memory Parameter im Befehl mit angebe. Fühlt sich aber eher wie ein Hack oder eine Notlösung an.