eigenen RSS Server

[QTip]

Installiere dir doch mal cronjobs von itari oder den Cronjob editor übers Paket-Zentrum. Die haben unter anderem ein Log in dem man Fehlermeldungen des crond erkennen kann.

Du kannst den crond aber auch selbst mit einem Log starten

/usr/syno/etc/rc.d/S04crond stop
/usr/sbin/crond -l 8 -L /var/log/cron.log

nun existiert im Verzeichnis /var/log eine Datei cron.log in der alle Meldungen des crond eingetragen werden.

 

[nuw8order]

Ich habe cronjob Editor installiert. Die Logs lauten folgendermaßen:

May 15 19:15:01 crond: USER root pid 12297 cmd wget --no-check-certificate --quiet --delete-after https://myurl.com/selfoss/update
May 15 19:30:01 crond: USER root pid 13456 cmd wget --no-check-certificate --quiet --delete-after https://myurl.com/selfoss2/update

Ich habe zwei Instanzen von selfoss laufen, da selfoss reine Single-User-Anwendung ist.

EDIT: Mehr wird vom Log nicht angezeigt. Der cronjob zeigt keine Wirkung. Es werden weiterhin keine Artikel geladen.

 

[QTip]

schon mal das Kommando manuell ausgeführt und geschaut was da passiert?

 

[gueschmid]

Hallo,

was TTRSS läuft auf einer DS1512+ unbefriedigend langsam? Dann brauch ich es auf meiner ARM-NAS wohl gar nicht erst testen, oder?

 

[nuw8order]

schon mal das Kommando manuell ausgeführt und geschaut was da passiert?

AUf der Konsole das Kommando eingegeben. Ergebnis ist leider das gleiche wie bei cron.

Würde sich denn mit curl was ändern?

@gueschmid

Bei meiner 1512+ lief es zwar ganz gut, aber meiner Meinung nach immer noch nicht so wie ich es gerne hätte. Daher mein Umstieg auf selfoss. Selfoss wiederum läuft wie geschmiert, nur das automatische Update ist nicht ganz einfach.

 

[QTip]

naja, wenn das Update auf der Konsole schon nicht funktioniert, dann liegt es nicht am cron Eintrag.
Also erstmal solltest probieren das Update per Url aufzurufen, denn nichts anderes macht das Kommando. Ausserdem benötigst du von deinem eigenen Server glaube kein https.

Browser starten
http://<ip_deiner_ds>/selfoss/update.php

Statt wget funktioniert evtl. auch "php /var/services/web/selfoss/update.php"

 

[Erebus]

Ich hatte auch das problem mit dem automatischen update von tiny rss, hier meine lösung.
In der config.php suchen:

define('SIMPLE_UPDATE_MODE', false);

ändern in:

define('SIMPLE_UPDATE_MODE', true);

script mit folgenden inhalt erstellen:

curl -L -s http://MEINE URL/backend.php?op=globalUpdateFeeds&daemon=1

Und das im Aufgabenplaner in der syno anlegen.

 

[Klanda]

Hallo,

so langsam dreh ich durch. Ich versuche nun schon seit Stunden den Deamon bzw. Cronjob für TTRSS zum Laufen zu bekommen.
Habe wie im Wiki beschrieben unter den PHP-Einstellungen der Syno das open_basedir eingegeben und PHP safe_mode_exec_dir-Zugriffsbeschränkung deaktiviert.
Wenn ich nun su -m nobody -c "(trap '' SIGHUP && /usr/bin/php /var/services/web/ttrss/update.php --daemon > /dev/null 2>&1) &" eingebe, erhalte ich die Meldung "su: can't chdir to home directory '/home'" (das selbe beim Cronjob Befehl vom Wiki).
Übrigens, wenn ich ln -s /usr/bin/php /usr/syno/bin/php kommt "ln: /usr/syno/bin/php: File exists"
Kann mir bitte jemand einen Tipp geben?
-------------

Update: Mittlerweile habe ich entdeckt, dass der Daemon trotz Meldung doch läuft (mit ps|grep php).
Obwohl es anscheinend funktioniert, würde mich schon noch interessieren, warum die home directory Meldung angezeigt wird und ob es dadurch zu "Problemen" kommen kann
Weiters scheint der Daemon trotz aktivierten "PHP safe_mode_exec_dir-Zugriffsbeschränkung" (auch keine ln -s /usr/bin/php /usr/syno/bin/php) zu funktionieren. Laut Wiki (und anderen Quellen), sollte das doch nicht möglich sein?!

 

[narades]

Versuche mal alle laufenden update Prozesse zu killen.
Mit kill prozessnummer
Und danach mit
mkdir /home als root das Verzeichnis anzulegen wg. dem er meckert
Dann nochmal
su -m nobody -c "(trap '' SIGHUP && /usr/bin/php /var/services/web/ttrss/update.php --daemon >> /pfad/zu/logdatei.log 2>&1) &
ausführen (hinten den Pfad zur Logdatei anpassen)
Dann in der LOG-Datei nachschauen was genau er anmeckert. Vielleicht funktioniert es dann aber auch schon.

EDIT: Ok, habe erst jetzt gelesen, das es funktioniert. Hatte selbst Probleme damit, das der Daemon zwar lief, aber es wurde nichts geupdated.
Bei mir kam das mit dem /home auch und ich hab es einfach mal angelegt, schaden kann es ja nicht

 

[Klanda]

mkdir /home als root das Verzeichnis anzulegen wg. dem er meckert

Vielen Dank, das wars (war ja eh logisch) - jetzt funktioniert alles perfekt

 

[EL Duderino]

"su: can't chdir to home directory '/home'"

Als Autor des ttrss-Artikels kann ich bestätigen, dass das normal ist und keine Auswirkungen hat. Ich hatte es immer so verstanden, daß su mit dem Parameter -m nobody versucht, in das home-Verzeichnis von nobody zu wechseln, das irgendwo(?) auf /home gesetzt ist. Die bessere Lösung wäre wahrscheinlich, diese Konfiguration zu entfernen, oder su dazu zu bringen, nicht zu wechseln. Ist wie gesagt aber nur kosmetisch.

P.S. Habe im wiki jetzt noch jeweils "2> /dev/null" an die su's angefügt, dann sollten die Fehlermeldungen im Orkus landen.

Übrigens, wenn ich ln -s /usr/bin/php /usr/syno/bin/php kommt "ln: /usr/syno/bin/php: File exists"
[…]
Weiters scheint der Daemon trotz aktivierten "PHP safe_mode_exec_dir-Zugriffsbeschränkung" (auch keine ln -s /usr/bin/php /usr/syno/bin/php) zu funktionieren. Laut Wiki (und anderen Quellen), sollte das doch nicht möglich sein?!

Naja, wenn /usr/syno/bin/php schon existiert (und auf ein CLI-php verweist), kann update.php auch mit safe_mode_exec_dir-Zugriffsbeschränkung php ausführen, und für den --daemon-Modus muß es das. Das ist ja gerade der Grund, weshalb man den Link anlegen muß, wenn er nicht da ist, oder safe_mode_exec_dir abschalten muß.

Aber das ist ein interessanter Punkt: Kann jemand mit "jungfäulichem" /usr/syno/bin und einer frischen DSM-Version bestätigen, daß /usr/syno/bin/php existiert und auf /usr/bin/php verweist, oder weiß jemand, ab welcher DSM-Version das so ist?

 

[QTip]

Aber das ist ein interessanter Punkt: Kann jemand mit "jungfäulichem" /usr/syno/bin und einer frischen DSM-Version bestätigen, daß /usr/syno/bin/php existiert und auf /usr/bin/php verweist, oder weiß jemand, ab welcher DSM-Version das so ist?

Das Paket "Photo Station" legt beim ersten Starten des Paketes im Paket-Zentrum den besagten Symlink @php an.

 

[EL Duderino]

Das Paket "Photo Station" legt beim ersten Starten des Paketes im Paket-Zentrum den besagten Symlink @php an.

Danke, ist ins wiki übernommen.

 

[EL Duderino]

Ich hatte auch das problem mit dem automatischen update von tiny rss, hier meine lösung.

Ich möchte anmerken, daß diese Methode obsolet ist. Was hindert Dich daran, den update daemon auszuführen?

 

[Klanda]

Hallo,

ich habe leider Probleme von Version 1.7.9 auf die neue Version 1.8 upzudaten.
Wenn ich in TTRS als Admin auf "Tiny Tiny updaten" gehe und den Prozess starte, erhalte ich die Meldung "Checking for tar... / Could not run tar executable (RC=-1)".

Was soll das bedeuten. habe mir den Code in Github (https://github.com/gothfox/Tiny-Tiny-RSS/blob/master/plugins/updater/init.php) angeschaut, da ich aber diese Programmiersprache/Linux nicht wirklich behesche, hat es mich nicht weiter gebracht.

 

[EL Duderino]

ich habe leider Probleme von Version 1.7.9 auf die neue Version 1.8 upzudaten.
Wenn ich in TTRS als Admin auf "Tiny Tiny updaten" gehe und den Prozess starte, erhalte ich die Meldung "Checking for tar... / Could not run tar executable (RC=-1)".

Das ist ein Problem mit dem safe_mode, glaube ich. Entweder im DSM safe_mode_exec_dir abschalten, oder auf der Kommandozeile

ln -s /bin/tar /usr/syno/bin/tar

ausführen und dann noch mal probieren. Ich wollte etwas im wiki dazu schreiben, aber probiere es erst mal aus und sag Bescheid, ob es klappt oder nicht.

 

[Klanda]

Das war schon mal ein ein super Tipp. Danke!

Jedoch kommt jetzt leider eine andere Fehlermeldung:
Checking for tar...
Checking for gunzip...
Checking for latest version...
Target version: 1.8
Proceeding to download...
Downloading distribution tarball...
Could not download distribution tarball (https://github.com/gothfox/Tiny-Tiny-RSS/archive/1.8.tar.gz).

Wenn ich https://github.com/gothfox/Tiny-Tiny-RSS/archive/1.8.tar.gz in den Browser eingeben, wird die Datei ohne Probleme heruntergeladen

 

[EL Duderino]

Jedoch kommt jetzt leider eine andere Fehlermeldung:
[…]
Could not download distribution tarball (https://github.com/gothfox/Tiny-Tiny-RSS/archive/1.8.tar.gz).

Wenn ich […] in den Browser eingeben, wird die Datei ohne Probleme heruntergeladen

OK, das ist schwieriger. Ich habe den eingebauten Updater zuletzt vor einigen Monaten genutzt, bevor ich auf git umgestiegen bin, habe damit also keine Erfahrung. In der Datei wird fetch_file_contents aus https://github.com/gothfox/Tiny-Tiny-RSS/blob/master/include/functions.php aufgerufen, und da geht etwas schief. Liegt eventuell an curl, oder vielleicht hat sich irgendwas am Server getan.

Wenn es nicht funktioniert, ist es am besten von Hand abzudaten, da ich von dieser Fehlermeldung zum ersten Mal höre. Sorry…

P.S. evtl funktioniert es, wenn Du in include/functions.php die Zeile ~337 (kann bei Deiner älteren Version eine andere Zeile sein)

curl_setopt($ch, CURLOPT_FOLLOWLOCATION, !ini_get("safe_mode") && !ini_get("open_basedir"));

durch

curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);

ersetzt. Völlig ohne Garantie (habe es nicht getestet), vielleicht geht dann danach was schief, oder es funktioniert gar nicht…

P.P.S. vielleicht hilft es auch, safe_mode_exec_dir im DSM abzuschalten und es noch einmal zu probieren.

 

[Klanda]

safe_mode_exec_dir habe ich vorher schon abgeschaltet - erst dadurch wurde das "Could not run tar executable" gelöst

Da ich einige andere Sachen zu tun habe, ist mir dein Vorschlag mit curl... gerade etwas zu riskant (falls doch was schief gehen sollte). Daher würde ich nun doch lieber ein manuelles Update machen - ist ja nicht so aufwendig (hoffe ich).

Bin mir aber nicht 100% sicher, was der Entwickler genau meint:
"Replace your old tt-rss directory with a newer one, optionally copying config.php, contents feed-icons, and your other modified files - plugins, CSS files, etc.
After the files have been upgraded by newer versions, open tt-rss. It may complain about missing directives in config.php. If that happens, you will need to either merge new stuff from config.php-dist to your config.php or remove config.php and rerun the installer."
1. Den ersten Satz verstehe ich so, dass ein neues Verzeichnis mit den neuen Files erstellt werden soll. Im zweiten schreibt er aber "After the files have been upgraded by newer versions" - das klingt wieder danach, als ob im aktuellen verzeichnis die Files mit den Neuen überschrieben werden sollen?!?!
2. Sollte wirklich ein neues Verzeichnis erstellt werden,
a. müssen doch die Berechtigungen auch wieder angepasst werden (for dir in "lock" "cache" "feed-icons"; do chown -R nobody:nobody "$dir"; done), oder?
b. Warum schreibt er "optionally copying config.php, contents feed-icons, and your other modified files - plugins, CSS files, etc.". Ist die config.php z.B. nicht Plicht? Da wurden doch wichtige Daten eingegeben (MySQL Daten)?!?!

Kann du mir (natürlich auch andere ) sagen, wie man nun genau vorgehen muss?

 

[EL Duderino]

safe_mode_exec_dir habe ich vorher schon abgeschaltet - erst dadurch wurde das "Could not run tar executable" gelöst

Noch eine Möglichkeit: Setze open_basedir im DSM auf nichts, versuche das Update, und setze es wieder auf den alten Wert zurück (evtl. Copy & Paste). Haut das hin?

Wenn es hinhaut, kopiert er die config.php mit, Du musst nur eventuell die Variablen finden, die in config.php-dist definiert sind, aber nicht in config.php, und diese mit einem Texteditor eintragen. Da sagt er Dir aber im Browser Bescheid, welche das sind.

Und am besten ein Backup der Datenbank machen!