Code to contribute

Hi there!

A while back, I took some code someone else wrote to perform regular upgrades to TT-RSS.

I’d quite like them to be considered as part of the core code base, so that I’m not nervous of them getting lost :slight_smile:

This would also mean that when the code is updated (for example, in the config file), the updater might be considered for being updated at the same time… :slight_smile:

tbh i never understood the need to write all these potentially buggy shell scripts to automate something that takes maybe a few seconds running git pull every now and then

for example you have this horrible script for what i assume is merging stuff in config.php (i’m especially enjoying how you decided to hardcode tunables instead of making a generalized solution, but i digress) and well let’s look at git history of this file shall we?

naboo:tt-rss-mysql:% git log config.php-dist| grep Date|head
Date:   Sat Jan 7 14:25:46 2017 +0300
Date:   Fri Aug 21 09:02:16 2015 +0300
Date:   Fri Jun 19 10:12:47 2015 +0300
Date:   Tue Feb 3 14:46:51 2015 +0300

2016 was a bit of a boring year for this script, wasn’t it. in general though totally worth it, imo.

I’d quite like them to be considered as part of the core code base, so that I’m not nervous of them getting lost :slight_smile:

as long as people understand that 1) they are actually NOT part of the official codebase and not supported (by me) and 2) i do not endorse running these scripts, be it yours specifically or others of similar function.

e: i’d also like to note that for people who absolutely can’t be assed to follow git trunk, a much better solution would be using whatever their distro of choice ships. if only because the package was supposedly tested by its maintainer and other people. as long they understand the implications WRT getting first party support from yours truly on this forum, of course.

jeeze, I “automated” changes to the config.php script “way back when”[tm] with a 14 line script that diffs my config.php and the new one, and alerts me if there’s any changes to the new file from git.

that suggested abomination… “shudder”

Running updates via cron… What could go wrong⸮

Yeah I’ve never understood automatic updates for things like this, its not like my TTRSS is a critical system or anything, it can wait.
I like to know exactly when I’ve updated incase something breaks so I run my Git pulls manually maybe every few weeks, and once I’m done I check if everything is working fine.

i think we scared op away Q_Q

Oh, I’ve got a script to update tt-rss it goes:

#!/bin/sh                                                                       
                                                                                
# Backup DB.                                                                    
DB="${HOME}/backups/"`date +'ttrss-pg-backup-%Y%m%d.sql'`                       
pg_dump ttrss > ${DB}                                                           
xz ${DB}                                                                        
                                                                                
# Backup TTRSS.                                                                  
TTRSS="${HOME}/html/www.example.org/public/tt-rss"                               
BAK="${HOME}/backups/"`date +'ttrss-src-backup-%Y%m%d.tar'`                     
tar -cf ${BAK} ${TTRSS}                                                         
xz ${BAK}                                                                       
                                                                                
## Update via git up:                                                           
# git config --global alias.up '!git remote update -p; git merge --ff-only @{u}'
cd ${TTRSS}                                                                     
git up                                                                          

But I run that manually when I have time to fix things up when they go wrong. The last thing I want is to wake up and find my ttrss is broken and I have to spend ages fixing it. That is no fun!

Hi thanks for the (um, mostly?) constructive feedback.

So, just to explain this - I like to keep all my stuff patched, on a server that I don’t really like logging into (my wife moans if she sees me in a shell… and I can’t really access stuff from work) and this seemed like a vaguely sensible idea, because unpatched software, on the site I run my blog from is not something I particularly want to encourage in myself.

I didn’t spot that you’d moved from something the updater would notify me about, to a rolling release, for two years. It’s fine, I’ve got no issues with the fact I wasn’t keeping an eye on it, but so I found someone else’s script to make sure I was keeping updated.

Regarding diffing the config.php, the code I took it from (which, I’m pretty sure I included the source) was missing some values, so hence I added what I did. Yes, it’s not pretty, but neither is trying to read a PHP config file from Bash, so … shrug

No, you didn’t scare me off, I’ve been knocking around the internet for quite long enough that what I’ve read above doesn’t worry me. I just don’t get a lot of time to read and respond to stuff.

Fine, I understand you not wanting it as part of core. I’ll leave it where it is. At least now, someone following on behind, who’s in a similar position to me might find this, much as I found the script I based mine on from the guy (or girl) before me.

Oh, and to the response about “I’ve never understood automatic updates for things like this”… is why “we” (the citizens of the Internet) have the problems we do with Wordpress. Automatic (or semi-automatic) updates on public facing scripts are something we should have by default, not something that is added in after the fact. The fact this comes in this form by a git-pull is… generally OK with me, but it would be useful if there was some kind of migration scripts… but again, it’s not here, so I’ve cludged my way around it. I appreciate this probably isn’t the way many of you would do it, and probably isn’t the way many of you feel about it, but, well, that’s just the way I am.

I’m not going to push for this if @fox doesn’t want it in the tree (and I respect his views, after all, I’ve not written anything like TT-RSS) but, there you go. It’s here if you want it, ignore it if you don’t.

All the best, etc. etc. etc.

I disagree here. Wordpress is badly written thus the many security advisories. That should be a clue to stay well clear of it not invent solutions to fix it…

Automated updates are fine if they work. If they fail, then you have a broken system for as long as it takes you to notice. Then you have to find the time in your already full schedule to fix it. This just adds stress for no good reason.

And ttrss does tell you when there is a new version in git. There’s a little green arrow on the top right!

I’m not going to agree nor disagree with you on this, I was citing an example, not comparing code (neither of which I’ve particularly looked into).

So, this way, I get updates automatically for 99.99% of the updates, which means I don’t need to perform any updates manually, and then in, let’s say, two years, when it breaks, I get to go and fix whatever it was that broke and still get an updated system at the end of it. I think I’m OK with that.

That would require me to be using the TT-RSS website? I generally access TT-RSS from one of two phone apps (depending on which account I’m viewing - work or personal).

So, you see, I’m not saying it’s the use case for everyone, but it is a useful use case for me, and it might be for someone else.

Oh, and to the response about “I’ve never understood automatic updates for things like this”… is why “we” (the citizens of the Internet) have the problems we do with Wordpress.

lol

i mean, poor (plural) you, citizens of the internet

So, you see, I’m not saying it’s the use case for everyone, but it is a useful use case for me, and it might be for someone else.

whatever your intentions are you’re not really making the case based on the irredeemably horrible quality of the code presented itt

however, i could easily imagine someone running something like that on that server also using wordpress or whatever other random garbage, a match made in heaven really

Fine. OK. Point made.

In that case, please consider this a feature request: Please write for us a half-decent (seen as I clearly can’t steal someone else’s code and fix it up enough to do what I wanted it to do) upgrading tool so that I can keep TT-RSS up to date, without needing to SSH into my server every [unspecified, but it’s OK because instead I can HTTPS to my web server to find out when I need to upgrade it] number of days.

No rush though… seriously. I’ll keep on limping along with my horrible code until something sensible arrives from someone better at coding than I.

if you’re really worried about security use proper methods like service isolation and containers, updating to latest trunk changeset, especially automatically, is largely useless in this regard. either that or trust your distro maintainer of tt-rss which should supposedly deal with this sort of thing for you.

No rush though… seriously. I’ll keep on limping along with my horrible code until something sensible arrives from someone better at coding than I.

as long as you understand that your ideas are of largely questionable benefit and may be actually considered harfmul - as doing something without thinking is in general - sure, use your shellscripts or w/e, nobody here is going to stop you

tbh there’s nothing going on with tt-rss that requires anyone to automatically git pull for any reason whatsoever. the thing is 12 years at this point, it’s mostly, you know, done. that’s why i’ve stopped doing formal releases two years ago, it’s not worth the effort.

Thank you for that pointer, I wasn’t aware that any distro was packaging tt-rss. I’ll take a look for that.

That makes sense. Thank you for sticking with it!

I posted one which you are free to run either manually or via crontab.

Good point. I missed that.

TT-RSS isn’t exactly a mission application but what I do is simply run a cron daily that checks if updates are available, if they are I get an email with the changes. I have a moderate amount of custom plugins and sometimes the changes break my code so I don’t automate the update.

I also don’t want to wake up and find it broken because I like reading and it’s important to me (even if not a critical service). As fox mentioned I run TT-RSS in a container so it’s isolated.

TT-RSS is a mature product. There’s been one security update in the years I’ve been using it. And even that was limited to registered users.

(FWIW WordPress is also a mature product but the constant, huge feature additions naturally lend it to needing more patches. It runs more than a quarter of web sites on the internet so it’s not like it’s horrible, though I think it needs a lot of improvement, personally. I think a lot of WordPress plugins and themes have vulnerabilities that make it easy to compromise. The core without any additions is not so bad even if some of the code is really ugly.)

OP, honestly you might be best using a TT-RSS that’s handled by a package manager. Even if you don’t get support here. Updates will be more seamless and it will save you from all this custom stuff which almost certainly introduces more problems than it fixes.

It runs more than a quarter of web sites on the internet so it’s not like it’s horrible,

well, being popular doesn’t mean its (internally) any good.

that said, i actually have little idea how terrible wordpress codebase is (my guess would be bad but idk) but it certainly doesn’t help things that its entire - very entrenched - plugin ecosystem is a post-holocaust burning wasteland of terrible decisions and drooling idiots shitting out absolutely, mindblowingly terrible php code.

I think a lot of WordPress plugins and themes have vulnerabilities that make it easy to compromise.

exactly

unfortunately it’s impossible to do any sort of security sandboxing for third party code in php which is why technically tt-rss or whatever else is similarly vulnerable to plugin exploits. the only saving grace of my stuff is that statistically speaking nobody uses it or cares about it. thank god for that.

I think you’ve nailed it. For the same reasons I would never run Windows. It’s a larger target because it’s so commonplace (and of course I just don’t like the UI).

I’ve spent a great deal of time working with WordPress. The code base seems better now than a few years ago but not by much; it carries so much legacy code for backwards compatibility and there are a lot of inconsistencies in the coding (I guess that’s to be expected when so many different people work on a single project).

At the end of the day, I can do just about anything with a web site running WordPress because their plugin system is really quite strong with hooks practically everywhere. And this is probably the single, biggest reason for its success.

I can’t even begin to share just how much garbage code I’ve discovered in plugins and themes. Stupid things like not escaping HTML on output and more serious things l Ike running eval() on variables.

For straight blogging I’ve recently starting playing with Ghost, and it seems nice but it’s still too young in development for me to use. (I also wonder if nodejs is just another fad.)