Okay, below the copy of the directory:

admin@Gercoext4:/$ ls -alt /volume1/web/tt-rss/
total 304
drwxrwxrwx 2 http root 4096 Jan 5 12:11 lock
drwxrwxrwx 2 http root 4096 Jan 5 03:00 feed-icons
drwxr-xr-x 21 root root 4096 Jan 4 23:45 .
-rw-r–r-- 1 root root 8048 Jan 4 23:45 config.php
-rw-r–r-- 1 root root 52 Jan 4 22:50 manualupdate.sh
-rw-r–r-- 1 root root 25 Jan 4 22:31 manualupdate.php
-rw-r–r-- 1 root root 367 Jan 4 22:26 test.php
drwxrwxrwx+ 6 root root 4096 Jan 4 14:28 …
-rw-r–r-- 1 root root 9229 Jan 4 10:55 sanity1.php
-rw-r–r-- 1 root root 7045 Jan 4 10:51 sanity.php
-rwxr-xr-x 1 root root 10946 Jan 4 10:34 update.php
-rwxr-xr-x 1 root root 10938 Jan 3 18:21 update1.php
-rw-r–r-- 1 root root 8040 Jan 3 18:21 confio1.php
drwxr-xr-x 2 root root 4096 Jan 3 2016 api
-rw-r–r-- 1 root root 1272 Jan 3 2016 atom-to-html.xsl
-rw-r–r-- 1 root root 3455 Jan 3 2016 backend.php
drwxrwxrwx 7 http root 4096 Jan 3 2016 cache
drwxr-xr-x 8 root root 4096 Jan 3 2016 classes
-rw-r–r-- 1 root root 8045 Jan 3 2016 config.php-dist
drwxr-xr-x 2 root root 4096 Jan 3 2016 css
-rw-r–r-- 1 root root 1622 Jan 3 2016 errors.php
-rw-r–r-- 1 root root 260 Jan 3 2016 .htaccess
drwxr-xr-x 2 root root 4096 Jan 3 2016 images
drwxr-xr-x 2 root root 4096 Jan 3 2016 include
-rw-r–r-- 1 root root 9871 Jan 3 2016 index.php
drwxr-xr-x 2 root root 4096 Jan 3 2016 install
drwxr-xr-x 2 root root 4096 Jan 3 2016 js
drwxr-xr-x 14 root root 4096 Jan 3 2016 lib
drwxr-xr-x 28 root root 4096 Jan 3 2016 locale
-rw-r–r-- 1 root root 68801 Jan 3 2016 messages.pot
-rw-r–r-- 1 root root 805 Jan 3 2016 opml.php
drwxr-xr-x 36 root root 4096 Jan 3 2016 plugins
drwxr-xr-x 2 root root 4096 Jan 3 2016 plugins.local
-rw-r–r-- 1 root root 4701 Jan 3 2016 prefs.php
-rw-r–r-- 1 root root 1474 Jan 3 2016 public.php
-rw-r–r-- 1 root root 960 Jan 3 2016 README.md
-rw-r–r-- 1 root root 10225 Jan 3 2016 register.php
drwxr-xr-x 3 root root 4096 Jan 3 2016 schema
drwxr-xr-x 2 root root 4096 Jan 3 2016 templates
drwxr-xr-x 2 root root 4096 Jan 3 2016 themes
drwxr-xr-x 2 root root 4096 Jan 3 2016 themes.local
-rwxr-xr-x 1 root root 6255 Jan 3 2016 update_daemon2.php
drwxr-xr-x 2 root root 4096 Jan 3 2016 utils

So ROOT is the user I need to use for running the script. It strikes me that HTTP ROOT is mentioned in the listing, but there is no HTTPS ROOT entry. Could that be the issue?
I changed the user for running the script:

afbeelding

The output of running this script is as follows:
[11:20:05] Lock: update.lock
[11:20:06] Scheduled 0 feeds to update…
[11:20:06] Sending digests, batch of max 15 users, headline limit = 1000
[11:20:06] All done.
[11:20:06] cache/simplepie: removed 0 files.
[11:20:06] cache/images: removed 0 files.
[11:20:06] cache/export: removed 0 files.
[11:20:06] cache/upload: removed 0 files.
[11:20:06] Removed 0 old lock files.
[11:20:06] Removing old error log entries…
[11:20:06] Feedbrowser updated, 3 feeds processed.
[11:20:06] Purged 0 orphaned posts.
[11:20:06] Removed 0 (feeds) 0 (cats) orphaned counter cache entries.
[11:20:06] Cleaned 0 cached tags.

The 3 feeds are the feeds that have no SSL (http). These are working fine.

I tried to SU ROOT but after entering the password (hoping I am using the right one) gives me ‘permission denied’.

ANything else I could trie, @gabbo?

Update: I managed to change to root user using ‘sudo su root’. I would expect a prompt with root$ but is says ash-4.3#.
I ran the manual update script. Same result though…

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.