Ah, my luck. My last pull must have been during that 40 minutes. And actually the detected value was incorrect (only said “http:” without the actual address) so it probably isn’t the same thing.
Every night starting “sudo git pull origin master” over cron and yesterday (+ many years) it was working. The SELF_URL_PATH I set correctly.
explain the problem you’re having coherently and in detail
Why would think that is remotely a good idea?
First, installing tt-rss as root using sudo is not a good idea™. Second, updating via cron is a terrible idea as you have no idea what has potentially gone wrong or needs a manual intervention. Third, you should always backup data before doing an upgrade.
…
Thanks for the smart ideas, but TT-RSS worked for me for a few years. I have bought an Android license.
My problem is describe in two pictures in the first post.
Can not connect via https protocol and via http can not connect as well. SELF_URL_PATH is set correctly: just change it for https or http in config.php. Https certificate I use Let’s Encrypt.
This has happened after today’s (or yesterday) update.
Even clean installation does not help, it’s the same.
I’m going to try FreshRSS.
You’ve redacted enough information in your pictures to make it difficult for us to help. Mind you, I understand why you don’t want to post your domain but if you really can’t resolve this by following fox’s instructions then maybe private message someone here with more details.
You can short-circuit the check by adding this to your config.php file:
define('_SKIP_SELF_URL_PATH_CHECKS', true);
But I would like to stress that I really do not recommend this as the sanity checks are there to alert you to issues and bypassing them is not a long-term solution.
e: Actually, re-reading your original post, I think I’m going to agree that the self URL constant is not actually defined properly. Look at the URL in your browser’s address bar when you visit TT-RSS and then compare that to the setting in the config file.
WOW
Finally somebody helped me, thank you very much.
if wishes were horses etc :facepalm:
sudo does not change owner:group that are set to www-data:www-data
It does if a new file or directory is created. But that’s not why @Kierun is saying that. He’s trying to point out that any process running as root has full privileges to the entire system; that’s a bad practice. Period.
yeah well at least they have some as opposed to our half-assed wiki pages lol
e: just look how posh that looks, sidebar and stuff
the idea for mandatory checking is having this set incorrectly may introduce subtle problems which are very hard to diagnose. if you specifically need to have this set to an arbitrary value there’s a tunable in config.php which disables this check.
My fault.
Sanity check works correct with http_host with frontend+backend.
was
define('SELF_URL_PATH', 'https://rss.domain.org');
mustbe
define('SELF_URL_PATH', 'https://rss.domain.org/');
I got this error as well when I did the pull today. I had been running with the same value for SELF_URL_PATH for perhaps 2 years(??) What I found was that the sanity check required a trailing slash in the URL and in my case I didn’t have a trailing slash. The actual code couldn’t have required a trailing slash since everything worked fine right before the pull, and the only thing that was fetched was the new sanity check code.
Checked the example in the sample config file (config.php-dist) and it does have a trailing URL but the comment doesn’t say this is required and it has worked without this. Not sure if it is worth it but adding a “The url must end with a slash” to the comment might be helpful.
well tbf the test literally gives you the exact string to copy there
anyway i don’t think trailing slash is actually needed anywhere (and yes it can be confusing and hard to notice) so i’ll update the check to accept both variants
e: done
In my setup the ttrss-server is behind an apache reverse-proxy.
So I have the message about wrong SELF_URL_PATH, too.
Sanity check (and ttrss) actually fail with the correct url (proxied url) and only accepts the “local” server url.
I have no idea, how a server can check, if it is behind a reverse proxy.
So in my case I think the only solution is to deactivate the check.
Am I right or do you have an idea, how to solve this?
greetings,
Martin
You’re probably not preserving the original Host header in your proxy. The easy solution is for you to turn on ProxyPreserveHost, but this won’t work if your backend server uses virtual hosts (i.e. has more than one domain).
Maybe tt-rss could look at the X-Forwarded-Host header if one exists, which apache mod_proxy sets automatically. But apparently it can have more than one (comma-separated) value, so it’d be a bit of a pain. And I bet there aren’t many people using apache httpd as a reverse proxy(?!)…
As a side note, Nginx also doesn’t preserve the Host header by default, but most guides (including the example in the docs) do include a directive that does so.
[quote=“BobVul, post:24, topic:353, full:true”]
…, but this won’t work if your backend server uses virtual hosts (i.e. has more than one domain).[/quote]
That actually does work AFAIK.
Oh yea, it would work if you set up the proxied/upstream/backend virtual hosts to expect the external hostname.