Did it work? I see https feeds are not included in the update.

You said:

so the feed is downloaded and parsed, right? The update is not working.

g.

Hi @gabbo

Yes, you’re right.
So, everything works as expected for http-rss-feeds (adding, clicking on feed in ttrss updates the feed and also the auto update script is working). With auto update script I mean the script kicked off by task scheduler of my Synology: PSP56 update.php --feeds.

However, for httpS rss feeds everything is working except for the auto update script: failed to open stream: No such file or directory. So yes, I think the parsing works fine but it looks that somewhere there’s an security issue.

Thanks for your help, @gabbo, I really appreciate that :slight_smile:

guys whatever you’re doing please don’t run tt-rss as root

also wouldn’t it be easier to use docker? dsm supposedly supports it

Hi @fox,

Yup, that’s what it said alright. So, won’t do that a next time. Do you also mean not to run the scheduled task as root but as admin, in my case?

I have heard about Docker and would love to try it but I can’t seem to find it as as available package in the package center. I have understood that if it doesn’t show up in available packages, it won’t run on that Synology station. I have 4 Synology stations, one of them being quite new: DS1515. I can’t imagine that station is not fast enough or has not enough memory? I’ll dive into that too.

Would you have other suggestions maybe?

du you install it from git oder via a package manager?

did you see this folder? It’s owned by the user “http”. Can you do a ls -l /volume1/web/tt-rss/lock that we can be shure this user also owns the lock files in there.

You do not have to create the lock file. TT-RSS creates them and therefore the webserver user (http) has to have write access in this folder and all the files in there.

Those are very basic questions… are you sure you would identify yourself as

Sorry :wink:
If you type in just su you are asked for the root user password.
If you type in sudo su <whateverusername> you can change to this user, but your user has to have sudo rights and you have to type in your user password.
ash is a shell supposedly

You should schedule the update script with crontab as the http user. You can change to the http user via sudo su http --shell=/bin/sh

Like @fox said.

As far as I know from my experience some years ago you can use it just like every other linux system if you got shell access enabled (and you certainly have if you are able to do what you described). But every update of DSM can break whatever dependencies for your self compiled programs.

i have no idea how DSM admin user works but it probably be better to use a separate unprivileged user.

most importantly don’t run anything as root. you shouldn’t even be able too, it’s an instant fatal error.

oh, that sucks. i have an rs2416+ at work but it’s used as a file server. i didn’t even enable ssh. :slight_smile:

as a file server it’s pretty good i’d give it that

e: well mine has docker package so at least some stations have them

@conrad784 Hi Conrad,

Thanks for all the feedback.

du you install it from git oder via a package manager?
I installed it via DSM package manager.

did you see this folder? It’s owned by the user “http”. Can you do a ls -l /volume1/web/tt-rss/lock that we can be shure this user also owns the lock files in there.
/volume1/web/tt-rss/lock:
total 4
-rw-r–r-- 1 root root 0 Jan 5 12:52 update_daemon.lock
-rw-r–r-- 1 http http 11 Jan 5 13:59 update_daemon.stamp
-rw-r–r-- 1 http http 0 Jan 5 14:05 update.lock

Did you see my remark that HTTP is working but HTTPS isn’t? It puzzles me that updates are working fine for HTTP feeds but not for HTTPS.

Those are very basic questions… are you sure you would identify yourself as advanced.
I did not say advanced but ‘advanced beginner’, meaning I am not completely new to Linux, that is all. :slight_smile:

You should schedule the update script with crontab as the http user. You can change to the http user via sudo su http --shell=/bin/sh
Thanks, I’ll give that a shot.

It’s not SELinux by any chance…

Hi @fox,

I have found the Docker package and downloaded it but when I triied to manually install it, I got a message that it’s not suitable for this Sunology Station and won’t install… :frowning:

can you install or enable php-curl instead of php internal fopen? which might be somehow limited for whatever reason.

apparently php can be gimped so remote fopen() doesn’t work with SSL - php - How to get file_get_contents() to work with HTTPS? - Stack Overflow

e: see the answer about php-openssl

This means your http user is not allowed to write to this file. Please remove this file as the root user.

First we have to check if your installation is broken then we think about why https isn’t working…

Maybe it’s easier for you just to use an installation provided by another user here on this forum, there are some threads about this.

Hi @conrad784,

I could indeed do a fresh installation. I once couldn’t enable Rsync and even Synology didn’t know how to fix it. I did a fresh installation of DSM and voila it worked… :slight_smile:

I’ll remove the lock file.

You are no experienced user of any unix based system, please first read some stuff about Linux (or BSD) then do some more research what docker is and then you can think about how to install docker on SynologyDSM…
Docker is not “plug and play” like the SynologyDSM is made to be.

Then do an update as the http user.
If this still not works take the advice of @fox and install

(I don’t know exactly how you do this with SynologyDSM but Google it and you should be able to solve this :slight_smile: )

Hi @fox,

With DSM you do that in Webstation configuration. I am pretty sure I have enabled CURL but let me check once more and send the PHP -i information. If that doesn’t work, I will just do a fresh install of DSM and will use one of the threads in here. I have used this guide:

In my own personal experience, if http is working, but httpS isn’t, the system often just has a problem with SSL.

If the shell of the system has wget or curl, you can try just accessing an https url to make sure you get valid data.

Maybe just ‘wget https://google.com’ or ‘wget https://GitHub.com
If one site works, try accessing your https feed urls with it to make sure they also work.

By no means exhaustive, but the most common solutions for me have been:

  1. Make sure the date and time are set and correct, within a few hours at least.
  2. Update CA Certificates. This can sometimes be done with a package manager or normal update process, but some systems you have to update this manually.
  3. Most recently, a hard requirement of a CentOS5 system meant I also had to compile a new OpenSSL and wget, and update cacerts manually to access directly. Supporting extended LTS stuff sucks sometimes.

CentOS-5 has an End of Life date of March 31, 2017… Hope that was before that. :slight_smile:

Unfortunately not, though it is just the build environment at least. They moved the code from subversion to a very new version of git. CentOS5 does not ship with git, at all. The build environment normally doesn’t get touched, but we added git to it. :confused:

What could go right⸮

\stops highjacking the thread.

I had reached the maximum posts on one day so I couldn’t reply any longer yesterday. I did a clean install of DSM and TTRSS and everything is working fine now. I guess the DSM was corrupted.
Thank you everyone! :slight_smile:

For anyone else coming this way who doesn’t want to re-install their DSM, I found another solution that works (or did for me).

If you follow the steps in the previously linked guide (https://www.reddit.com/r/synology/comments/6a27sd/step_by_step_guide_to_installing_tiny_tiny_rss/) you’ll be using php56 for everything. What I found was that despite the php settings panel saying it was installing the openssl, curl, and sockets modules for php56, they were going in the base php modules directory and configuration. What I did to fix this:

sudo cp /usr/lib/php/modules/openssl.so /usr/local/lib/php56/modules/
sudo cp /usr/lib/php/modules/sockets.so /usr/local/lib/php56/modules/
sudo cp /usr/lib/php/modules/curl.so /usr/local/lib/php56/modules/

Then open up /usr/local/etc/php56/php.ini and add:

extension = openssl.so
extension = curl.so
extension = sockets.so

And that should hopefully fix it. Don’t know for sure that curl and sockets are needed, but seemed relevant so I added them.