So I was a user of the linuxserver tt-rss image, however it seems I’m going to have to switch over to this one as theirs was deprecated. Looking over the repo, it seems like the image is only compatible with postgresdb? I have an existing db on a mariadb host outside of my docker environment. What work would be required to use mariadb with your image? I’m not an expert but if someone wants to point me in the right direction I’m willing to try and test things out
linuxserver/ttrss image is a mess now, so today morning i moved to Awesome-TTRSS image by HenryQW, and in afternoon i saw @fox have his own “ttrss-docker-compose” and i quickly jumped on it because its has latest build.
to answer your question, follow /fox/ttrss-docker-compose its straight forward and it has postgres included, if you need mariadb just change pgsql to mariadb/user/pws/host in docker compose
love it, no more depending on third party images.
thank you @fox
Unfortunately it doesn’t seem that easy. I’m swapped the values out for MariaDB but the startup.sh script that runs with the container is only checking for PostgresDB, and since it can’t find it it never gets past the loop
it should be trivially easy to update the scripts to use mysql instead of postgres.
i’m only going to support postgresql on my docker scripts though. consider it a part of my evil plan to force as much people as possible to use a non-shit database server for once in their life.
there’s also this - https://git.tt-rss.org/fox/ttrss-data-migration 
I would move to pg. It’s straight forward and will save you much hassle.
oh boy where do i begin with this
- literally THREE fucking donation links
- simply abhorrent shit in compose[1]
- downloads .tar.gz but at least it’s not an ancient tag
- proprietary shit included (mercury api)
- nginx/fpm sharing container for some reason with s6 included (almost always a sign that author doesn’t understand how docker containers should work - it’s not a fucking VM)
- so much third party stuff bundled i couldn’t count it all, could be a plus i guess for someone
it’s better than linuxserver but i wouldn’t personally use it (or endorse it), ever.
volumes: - ~/postgres/data/:/var/lib/postgresql/data- doing stuff like this should get you fired into the sun, use actual volumes.
Sadly I’m not an expert in bash, so while I know enough to tell what it’s doing, I don’t know enough to be able to modify it to my needs
I would migrate, but I have several other services running off the same MariaDB host anyway and some don’t support pg. My MariaDB just works so I don’t see much reason to switch at this time.
It seems that I’m going to have to switch to something else anyway. While building from source is great, the docker-compose build directive isn’t supported in a docker swarm environment so I literally can’t use this without a lot of hassle.
If I might make a suggestion, it seems like the whole reason for building from source it to make sure users always have the latest code. How about using something like Drone for a pipeline? It would allow you to automatically publish an image to DockerHub whenever you push code to the repo. I would love to use an official TT-RSS image but I literally can’t at this time.
i’m entirely not interested in publishing anything on dockerhub, github, or really any other hubs. sorry.
As far as I understand Docker and Compose, you should use a different database for all your applicatons so that if one takes it down, nothing happens to the others. Thus, what ttrss uses should not impact what anything else is using… Not an expert so I could be wrong.
In any case, it should be easy to clone the repo and modify it to be able to get what you want out of it.
Or you know, get a cheap VPS.
yeah, a single host database with multiple containers is not a great combination even though it saves on resources i suppose.
you really should be using virtual networks with isolated databases and other stuff.
Indeed… it IS a superior product, and works better.
I’m following along to this and the discussions about the db, and the main thing I’m thinking of is what is so important In the db that it needs saving? I would have thought post would be transient.
some people like to archive things; not everything in RSS feeds is strictly transient news.
FYI, i was on container v19.12-76dd74e0d and on restart of the container, got error i guess it tried to update from git
restarted the container and
- git pull origin master
From https://git.tt-rss.org/fox/tt-rss
- branch master → FETCH_HEAD
Updating 76dd74e0d…1aeeed930
error: Your local changes to the following files would be overwritten by merge:
.gitlab-ci.yml
include/functions.php
include/version.php
tests/ApiTest.php
utils/gitlab-ci/check-schema.sh
utils/gitlab-ci/config-template.php
utils/gitlab-ci/nginx-default
utils/gitlab-ci/php-lint.sh
utils/gitlab-ci/phpmd-ruleset.xml
utils/gitlab-ci/phpmd.shPlease commit your changes or stash them before you merge.
Aborting
had to delete everything and created new container and restored from backup now am on v19.12-1aeeed930
it’s very likely that git config core.filemode false in the tt-rss directory on persistent volume would’ve been enough to fix everything.
i’ll take a look at this but in the future don’t just run and delete everything if you run into an issue, makes it impossible to debug anything until it happens again.
e: https://git.tt-rss.org/fox/ttrss-docker-compose/commit/7e9addf1a31499c60e4b7d3f6d9c8a6957e81939
e: https://git.tt-rss.org/fox/ttrss-docker-compose/commit/7e9addf1a31499c60e4b7d3f6d9c8a6957e81939
HTTP_PORT=127.0.0.1:8280 makes it unreachable, if i change it back to HTTP_PORT=8280 site is reachable
container binds to 127.0.0.1 by default in case you’re using a reverse proxy and don’t want origin port exposed (because docker would silently override your iptables rules in default configuration).
https://git.tt-rss.org/fox/ttrss-docker-compose/commit/28b0ad6ac9b72296ee699aa1cb3f64d3205ee56c
great, thanks.
also postgres keeps giving an error,
2019-12-09 05:29:39.492 UTC [27] FATAL: role “root” does not exist
it’s probably pg_isready trying to connect as root, not really a big deal.
e: https://git.tt-rss.org/fox/ttrss-docker-compose/commit/9adf705f704b6300b1be5dc912269a3b2cbcdb9f
Took some messing around but I eventually got the docker using your docker compose up and running.
Coming from an install from pulling git on an ubuntu server I’m running. Initially had some rights issues but I fixed that. For some reason even though passing a UID/GID in the .env file it still had issues. After I finally could reach it I exported my old DB (was running PG10 and I see this is PG12 so hopefully no issues) and imported into the new one. Copied my plugins etc and fired the container back up and for the most part, it’s working. I had to schedule the cron job via the host by running “docker exec ttrss-docker_app_1 /usr/bin/php /var/www/html/tt-rss/update.php --feeds” every 15 minutes. I tried using update_daemon2.php but it gave me an error “This script requires PHP compiled with PCNTL module.”. Occasionally I’ll get some php errors in the logs but nothing that seems to break operation.
Go figure when I check the version I get Unknown (Unsupported).
Also, for the db and the app I setup I did binds instead of docker volumes, mainly for ease of dealing with importing the original DB and editing of the config.php.