User lost after server migration

  • [ ] I’m using stock docker compose setup, unmodified.
  • [ ] I’m using docker compose setup, with modifications (modified .yml files, third party plugins/themes, etc.) - if so, describe your modifications in your post. Before reporting, see if your issue can be reproduced on the unmodified setup.
  • [ ] I’m not using docker on my primary instance, but my issue can be reproduced on the aforementioned docker setup and/or official demo.

I am using Ubuntu repos installation on Ubuntu Server 22.04 Apache2


  • Tiny Tiny RSS version (including git commit id): Tiny Tiny RSS vDebian 21~git20210204.b4cbc79+dfsg-1
  • Platform (i.e. Linux distro, Docker, PHP, PostgreSQL, etc) versions: Ubuntu Server 22.04, Apache 2, php7.4

My main user is not accessbile anymore after server migration.

I have migrated an existing tt-rss installation from an Ubuntu 18.04 to a new 22.04 installation.
Did a fresh install based on Ubunutu repos and imported the MySQL database backed-up before to MariDB.

All went very well and smooth. Database was recreated, and backup imported. Privileges have been granted to user ‘tt-rss’. SQL-scheme was well adjusted.

  • mysql --user tt-rss --password= ttrss < /usr/share/tt-rss/schema/ttrss_schema_mysql.sql
  • sudo -u www-data php /usr/share/tt-rss/www/update.php --update-schema

both worked perfectly

tt-rss runs smoothly and is accessible via the webinterface.
I can log-in with standard “admin” account and everything seems to be fully functional.

Except … the user “cve” that I was using before and all its data seem to be there anymore.
Cannot login as “cve”, and don’t see user “cve” in the users list when login in as “admin”.
Recreating user “cve” did not provide access.

Any suggestions on how I might be able to access the data? Would be happy about every hint I could get. (even provided I am using an unsupported version)

installing the schema resets the database entirely. i hope you have backups.

Thank you Fox.
Yes, sure I have … several actually :grinning:

OK, I realized that I accidentally reset’ed the db by replaying the standard schema. Shouldn’t do this stuff too late in the evening. My fault sorry!

Kindly forgive me if this might be a totally stupid question, but what would be the best approach for me …

  1. to do the schema format before replaying the backup?
    create blank db
    mysql --user tt-rss --password= ttrss < /usr/share/tt-rss/schema/ttrss_schema_mysql.sql
    replay backup

  2. do the “update-schema” (only) after replaying the backup?
    create blank db
    replay backup
    sudo -u www-data php /usr/share/tt-rss/www/update.php --update-schema
    (as far as I remember this might have given me a error message before, but will check)

  3. or not doing any schema update at all?

you shouldn’t install blank schema before restoring your backup. this can prevent the restore from completing.

  1. restore backup into empty database
  2. update schema manually via update.php (if needed)

Thank you! Already on the way …

Ok it has worked well. I hope it is OK that I document my steps to success allowing others with the same issue to follow …

MariaDB @Ubuntu Server 22.04 Apache2 php7.4
Tiny Tiny RSS from Ubuntu repository

stop service
service tt-rss stop

remove crap versions
mysql -u root -p
show databases;
DROP DATABASE ttrss;

create new database
CREATE DATABASE ttrss CHARACTER SET = utf8 COLLATE = utf8_general_ci;
FLUSH PRIVILEGES;
EXIT;

replay backup
mysql -u root -p ttrss < /media/Storage/mysqlbackups/allbackup_2022-10-22.sql

mysqlcheck -u root -p --all-databases --fix-db-names --fix-table-names
mysqlcheck -u root -p --all-databases --check-upgrade --auto-repair
mysql_upgrade -u root -p --force

restart and check services
systemctl restart mysql.service && systemctl status mysql.service
systemctl start tt-rss.service && systemctl status tt-rss.service
systemctl restart apache2.service && systemctl status apache2.service

update schema as suggested by fox
via loggin in as “admin” and fllowing the guidance for an update required (in my case)
where this should do the same: sudo -u www-data php /usr/share/tt-rss/www/update.php --update-schema

then I also had the issue described in https://discourse.tt-rss.org/t/upgrade-from-a-very-old-version-and-duplicate-entry/2761
so, I spotted and deleted the rows concerned
WITH cte AS
(
SELECT
*,
ROW_NUMBER() OVER (
PARTITION BY feed_url
ORDER BY feed_url
) AS Row_Number
FROM ttrss_feeds
)
SELECT * FROM cte WHERE Row_Number <> 1;

and finally it ran through and all is good!

Thank you again fox

:+1:

/20char-r-r-r-rrrr