wallabag auf shared hosting installieren

ninguem · Mar 8th 2020

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.

ninguem · Mar 11th 2020

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.

FaGo · Jul 9th 2020

Hey!

Erst mal danke für die Anleitung, das hat mir sehr geholfen.
Ich habe das den geschilderten Schritten entsprechend durchgeführt und die Werte in die parameters.yml geschrieben. Soweit, so gut.

Allerdings bekomme ich dann beim Eingeben des neuen Benutzerpassworts folgende Meldung: "stty: Kommando nicht gefunden."

Das Setup kann ich trotzdem erfolgreich abschließen. Jedoch bekomme ich beim Aufruf der entsprechenden Domain nur eine leere Seite. Auch die Umleitung wird nicht durchgeführt.

Gab es das Problem auch bei Ihnen und falls ja, was war denn die Lösung?

Danke und viele Grüße

Fa

ninguem · Jul 10th 2020

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.

FaGo · Jul 12th 2020

Habe festgestellt, dass beim Ausführen der php Befehle php in Version 7.2.x verwendet wird.
Jedoch kann man auch spezielle Versionen ausführen, daher habe ich den Befehl entsprechend angepasst:

Code

/usr/local/php73/bin/php bin/console wallabag:install -e=prod

Damit kam zwar immer noch der Fehler bei der Passwortabfrage, allerdings funktioniert es nun hinterher.

Danke für die Hilfe!

ninguem · Dec 18th 2020

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

Code

ALTER TABLE wallabag_entry ADD archived_at DATETIME DEFAULT NULL;
ALTER TABLE `wallabag_oauth2_access_tokens` CHANGE `token` `token` varchar(191) NOT NULL;
ALTER TABLE `wallabag_oauth2_access_tokens` CHANGE `scope` `scope` varchar(191);
ALTER TABLE `wallabag_oauth2_auth_codes` CHANGE `token` `token` varchar(191) NOT NULL;
ALTER TABLE `wallabag_oauth2_auth_codes` CHANGE `scope` `scope` varchar(191);
ALTER TABLE `wallabag_oauth2_refresh_tokens` CHANGE `token` `token` varchar(191) NOT NULL;
ALTER TABLE `wallabag_oauth2_refresh_tokens` CHANGE `scope` `scope` varchar(191);
ALTER TABLE `wallabag_craue_config_setting` CHANGE `name` `name` varchar(191);
ALTER TABLE `wallabag_craue_config_setting` CHANGE `section` `section` varchar(191);
ALTER TABLE `wallabag_craue_config_setting` CHANGE `value` `value` varchar(191);

ALTER TABLE `wallabag_user` ADD googleAuthenticatorSecret VARCHAR(191) DEFAULT NULL;
ALTER TABLE `wallabag_user` CHANGE twoFactorAuthentication emailTwoFactor BOOLEAN NOT NULL;
ALTER TABLE `wallabag_user` DROP trusted;
ALTER TABLE `wallabag_user` ADD backupCodes LONGTEXT DEFAULT NULL COMMENT '(DC2Type:json_array)';

ALTER TABLE wallabag_site_credential ADD updated_at DATETIME DEFAULT NULL;

ALTER TABLE wallabag_entry ADD hashed_url TINYTEXT DEFAULT NULL;

CREATE INDEX hashed_url_user_id ON wallabag_entry (user_id, hashed_url(40));

ALTER TABLE `wallabag_config` CHANGE rss_token feed_token VARCHAR(255) DEFAULT NULL;
ALTER TABLE `wallabag_config` CHANGE rss_limit feed_limit INT DEFAULT NULL;

ALTER TABLE `wallabag_oauth2_access_tokens` DROP FOREIGN KEY FK_368A4209A76ED395;
ALTER TABLE `wallabag_oauth2_access_tokens` ADD CONSTRAINT FK_368A4209A76ED395 FOREIGN KEY (user_id) REFERENCES `wallabag_user` (id) ON DELETE CASCADE;
ALTER TABLE `wallabag_oauth2_clients` DROP FOREIGN KEY IDX_user_oauth_client;
ALTER TABLE `wallabag_oauth2_clients` ADD CONSTRAINT FK_635D765EA76ED395 FOREIGN KEY (user_id) REFERENCES `wallabag_user` (id);
ALTER TABLE `wallabag_oauth2_refresh_tokens` DROP FOREIGN KEY FK_20C9FB24A76ED395;
ALTER TABLE `wallabag_oauth2_refresh_tokens` ADD CONSTRAINT FK_20C9FB24A76ED395 FOREIGN KEY (user_id) REFERENCES `wallabag_user` (id) ON DELETE CASCADE;
ALTER TABLE `wallabag_oauth2_auth_codes` DROP FOREIGN KEY FK_EE52E3FAA76ED395;
ALTER TABLE `wallabag_oauth2_auth_codes` ADD CONSTRAINT FK_EE52E3FAA76ED395 FOREIGN KEY (user_id) REFERENCES `wallabag_user` (id) ON DELETE CASCADE;

ALTER TABLE `wallabag_tag` CHANGE `label` `label` longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
ALTER TABLE `wallabag_tag` CHANGE `slug` `slug` VARCHAR(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

ALTER TABLE wallabag_entry ADD given_url LONGTEXT DEFAULT NULL, ADD hashed_given_url TINYTEXT DEFAULT NULL;
CREATE INDEX hashed_given_url_user_id ON wallabag_entry (user_id, hashed_given_url(40));
UPDATE wallabag_config SET reading_speed = reading_speed*200;

ALTER TABLE `wallabag_entry` MODIFY language VARCHAR(20) DEFAULT NULL;
CREATE INDEX user_language ON `wallabag_entry` (language, user_id);
CREATE INDEX user_archived ON `wallabag_entry` (user_id, is_archived, archived_at);
CREATE INDEX user_created ON `wallabag_entry` (user_id, created_at);
CREATE INDEX user_starred ON `wallabag_entry` (user_id, is_starred, starred_at);
CREATE INDEX tag_label ON `wallabag_tag` (label (255));
CREATE INDEX config_feed_token ON `wallabag_config` (feed_token (255));
ALTER TABLE `wallabag_craue_config_setting` RENAME `wallabag_internal_setting`;

CREATE TABLE wallabag_ignore_origin_user_rule (id INT AUTO_INCREMENT NOT NULL, config_id INT NOT NULL, rule VARCHAR(255) NOT NULL, INDEX idx_config (config_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8mb4 COLLATE `utf8mb4_unicode_ci` ENGINE = InnoDB;
CREATE TABLE wallabag_ignore_origin_instance_rule (id INT AUTO_INCREMENT NOT NULL, rule VARCHAR(255) NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8mb4 COLLATE `utf8mb4_unicode_ci` ENGINE = InnoDB;
ALTER TABLE wallabag_ignore_origin_user_rule ADD CONSTRAINT fk_config FOREIGN KEY (config_id) REFERENCES `wallabag_config` (id);

UPDATE wallabag_internal_setting SET name = 'matomo_enabled' where name = 'piwik_enabled';
UPDATE wallabag_internal_setting SET name = 'matomo_host' where name = 'piwik_host';
UPDATE wallabag_internal_setting SET name = 'matomo_site_id' where name = 'piwik_site_id';

Display More

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.

ninguem · Jan 7th 2021

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):

nicht essentielle Dateien/Ordner

scharmach · Mar 15th 2021

Quote from ninguem

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.

Display More

Danke für die super Anleitung! Konnte damit Wallabag auch bei mir und in relativer Windeseile installieren

Einzig php bin/console wallabag:install -e=prod hatte so bei mir nicht funktioniert.

Habe dann in der Wallabag-Dokumentation gesehen, dass sich da scheinbar was geändert hat:

php bin/console wallabag:install --env=prod (von hier: https://doc.wallabag.org/en/ad…llation/installation.html)

Damit ging's dann, vielleicht hilft es zukünftig ja noch wem

sargeras · Apr 18th 2021

Hallöchen. danke erst mal für die Anleitung.

Bis ich deine Anleitung enteckt habe, habe ich zunächst composer installiert, ich weiß nicht ob das falsch war...

Beim Installieren, als auch beim Cache leeren mit (laut Wallabag - Doc)

Code

php bin/console cache:clear --env=prod

erhalte ich folgende Fehlermeldung:

Quote

Deprecated: Required parameter $ip follows optional parameter $verb in /wallabag/vendor/wallabag/php-mobi/MOBIClass/Http.php on line 16

Fatal error: Declaration of Doctrine\DBAL\Driver\PDOConnection::query() must be compatible with PDO::query(string $query, ?int $fetchMode = null, mixed ...$fetchModeArgs) in /wallabag/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php on line 81

In PDOConnection.php line 81:

Compile Error: Declaration of Doctrine\DBAL\Driver\PDOConnection::query() m

ust be compatible with PDO::query(string $query, ?int $fetchMode = null, mi

xed ...$fetchModeArgs)

Display More

PHP-Version: 7.4.16

Wallabag-Version: 2.4.2

Ordner (falls interessant): /wallabag (hier liegt auch alles direkt entpackt drin + .htaccess)

Im Ordner /wallabag

Code

nano app/config/parameters.yml

Quote

# This file is auto-generated during the composer install

parameters:

database_driver: pdo_mysql

database_host: 10.35.******

database_port: 3306

database_name: k******_wallabag

database_user: k******_wallabag

database_password: geheim

database_path: null

database_table_prefix: wallabag_

database_socket: null

database_charset: utf8mb4

domain_name: 'https://wallabag.MEINEDOMAIN.de'

server_name: 'Your wallabag instance'

mailer_transport: smtp

mailer_user: wallabag@MEINEDOMAIN.de

mailer_password: auchgeheim

mailer_host: mail.MEINEDOMAIN.de #das müsste doch gehen?

mailer_port: 465

mailer_encryption: ssl

mailer_auth_mode: login

locale: en

secret: nochvielgeheimer

twofactor_auth: true

twofactor_sender: no-reply@MEINEDOMAIN.de

fosuser_registration: true

fosuser_confirmation: true

fos_oauth_server_access_token_lifetime: 3600

fos_oauth_server_refresh_token_lifetime: 1209600

from_email: no-reply@MEINEDOMAIN.de

rss_limit: 50

rabbitmq_host: localhost

rabbitmq_port: 5672

rabbitmq_user: guest

rabbitmq_password: guest

rabbitmq_prefetch_count: 10

redis_scheme: tcp

redis_host: localhost

redis_port: 6379

redis_path: null

redis_password: null

sentry_dsn: null

Display More

Die .htaccess (liegt wie gesagt in /wallabag)

Quote

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

Display More

Habt ihr eine Idee und könnt mir helfen? Vielen Dank schon mal!!!

ninguem · Apr 19th 2021

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.

sargeras · Apr 19th 2021

Danke für die Anregung.

Habe das Verzeichnis /wallabag komplett gelöscht und neu erstellt + wallabag neu runtergeladen.

Config wie oben + database_driver_class: null ergänzt und auch noch einen zweiten db-Nutzer angelegt und hinterlegt.

Leider kommt dennoch noch der gleiche Fehler. Auch deinen Cache-Löschen-Befehl habe ich ausprobiert ... da kommmt keine Rückmeldung, aber beim Versuch des Installierens bleibt die Fehlermeldung.

sargeras · Apr 19th 2021

Habe es jetzt auch nochmal mit der 2.4.1 versucht, gleicher Fehler

ninguem · Apr 19th 2021

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.

sargeras · Apr 20th 2021

Wow vielen Dank, ich versuche es heute Abend gleich nochmal.

sargeras · Apr 20th 2021

Alles nachvollzogen, leider ohne Erfolg.

Habe alles bis zur Anpassung der parameter nachvollzogen und beim php bin/console wallabag:install --env=prod kommt wieder oben beschriebener Fehler.

Welche PHP-Version nutzt du?

Habe mal meine Einstellungen mal als Bilder beigefügt (die Dateien wurden via SSH mit nano bearbeitet).

Das DB-PW habe ich mal bewusst nicht unkenntlich gemacht.

.htaccess --> rw- r-- r--

die parameters --> dito

Btw: die erste Meldung "Deprecated: Required ...." hatte ich gestern sogar gefixt, indem ich in der http.php die beiden Parameter getauscht hatte in der Reihenfolge. Jetzt nach Neuinstallation kommt es wieder. Ich denke, das ist eher nur eine Warnung.

Problematisch dürfte der Teil ab Fatal error sein.

ninguem · Apr 20th 2021

.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.

sargeras · Apr 20th 2021

Bei mir kommt bei eine cat /conf/phpversion 80 (in / als auch in /wallabag)

Aber bei sämtlichen Domains steht (v.7.4.16)...

Bei der Fehlersuche habe ich nun meine (Haupt-)Domain aus WCP gelöscht. Da muss ich wohl jetzt auf den Support warten.

Aber weder hatte ich etwas bei disable_functions ändern lassen (da stand Standard dahinter), noch habe ich selbst etwas bei open_basedir geändert.

Aber das mit PHP 80 ist seltsam. Bei der Webrecherche bzgl. des Fehlers, bin ich irgendwo auf eine Git-Seite gestoßen (könnte sogar wallabag gewesen sein), da war auch die Rede von PHP 8 in Zusammenhang mit symfony. Sehr seltsam. Kann ich irgendwo mein Konto auf "Werkseinstellung" zurücksetzen? *lach*

Edit:

Ja Verbindungen von allen Hosts zulassen hatte ich auch gesetzt und auch keien Restriktionen bei Nginx/Apache. Neue Subdomain kann ich auch nochmal versuchen, aber da muss ich noch auf meine Domain im WCP warten

ninguem · Apr 21st 2021

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.

sargeras · Apr 21st 2021

Danke! Das wars! Da wäre ich niemals alleine drauf gekommen.

Noch eine Ergänzung:

Beim ersten Versuch nach der php-Änderung kam eine Fehlermeldung, dass ich nicht auf die DB connecten kann. Ich hatte dann das DB-Passwort in Hochkommas also database_password: 'Password' geschrieben + Cache gelöscht, dann ging es.

Und die Fehler bei Passwort-Vergabe und Username-Vergabe

bash: stty: command not found

kam auch bei mir. Ist wohl mehr oder minder egal.

Xorg · Apr 21st 2021

Ich habe wallabag gerade auch mal auf meinem Webspace installiert. Es hat alles wunderbar funktioniert. Allerdings musste ich auch bei mir die php-Version in der cli erst einmal von 80 auf 74 umstellen. Der Fehler bei der Passwort-Vergabe kam bei mir auch. Das Passwort konnte ich aber trotzdem vergeben.

Vielen Dank für die gute Anleitung und die hilfreichen Beiträge!

Nutzt ihr eigentlich ein Browser-Addon, um die Seiten zu speichern oder macht ihr das manuell per copy+paste?

Tags