Looking at moving to an ansible deployed instance. I could restore from backup, but I’m interested to know if I could deploy from scratch and just import an opml.
But first I’d prefer a user to install to.
Doesn’t look like there’s an api call for that, can I just hack around in the db to create a new user with a known password salt value? then run the opml import from disk?
Any gotchas with doing this?
TLDR: i kinda misread your post and thought you were interested in deploying new tt-rss instances via ansible in a generic way. if you just want to restore your backup, by all means just create an entry in ttrss_users and import the OPML.
you won’t be able to do this through the stock API (it’s focused around rss reader clients, although you can extend it via plugins i guess). i wouldn’t do it through sql either, schema and stuff changes sometimes, you might run into hard to diagnose issues.
i think the easiest approach would be using built-in container support for php snippets sourced from config.php, this way you’ll be able to execute arbitrary code on application startup.
this is where i wanted to suggest you call a UserHelper method to create a user but apparently none exists and user preferences pane deals with that instead. oops. i suppose this could be added, but for the time being you could copy-paste relevant method from classes/pref/users.php and use it instead.
it’s not optimal but i think it’s less prone to breakage than just trying to deal with the db directly.
overall creating a custom user on container startup is not a bad idea, although i’m not sure of the exact features required (i.e. login, password, non/admin status). adding more users would probably be too much, because at this point i would suggest using some kind of SSO setup.
adding a way to manipulate users to update.php would also be a good idea so it would be CLI-exposed, this also depends on moving user manipulation code from preferences into user helper or w/e.
Thanks for the big answer.
Though now I think about it, I used to expose my server to the internet, but don’t now (wfh basically). And if need it when out, then vpn home. So technically I guess I could go userless.
Inwjdnetnif there could be a way of building in a default user via the container deployment. With enc variables for their password maybe. Similar to how the self url and port are set.
Again, I could just use the admin user, and poke an opml at that user.
if you’re the only user on your instance, you could go with tt-rss SINGLE_USER_MODE protected by external HTTP auth, this would auto-login you as built-in admin user (which you could import your data under) and would be essentially userless.
yes, i’ll put this on my tt-rss TODO list. if it didn’t require application code changes i’d add it already because it’s an obvious thing to have (Epube docker deployment has this, for example).
the bare minimum would be, via .env:
since there’s user interest i’ll try to fit this in when i have some time to kill.
Sounds great.
Managed to get my deploy working. I’m pulling the whole repository, but unsure if I only need the docker compose only. Then adding an override to set the backups folder to a server bind mount.
you just need the .yml, the repo simply makes everything easier to update. compose setup has changed a few times.
Ok. I wasn’t sure if the build used source files referenced from the repo
if you don’t use docker hub images, you’ll need those, sure.
Oh right, I was trying to figure out why mine was doing a build. I missed the switch to static branch.
https://dev.tt-rss.org/fox/tt-rss/commit/cf1eaeedf3026948cf2210af1c747bdc3522d6ff
update: i’ve added CLI user manipulation, the only thing that’s left is invoking it on container startup based on envvars. maybe tomorrow.
user creation stuff is available for testing here: * add environment variable to add initial users on startup · e472670de7 - ttrss-docker-compose - Tiny Tiny RSS
e: docker hub branch - * merge enhancements from the master branch (user auto creation, etc.) · 5a41bb1850 - ttrss-docker-compose - Tiny Tiny RSS
so it’s now possible to deploy with a custom user/password combination and, optionally, internal admin user entirely disabled:
# .env
# disable admin
ADMIN_USER_ACCESS_LEVEL=-2
# make a custom admin user instead
AUTO_CREATE_USER=myuser
AUTO_CREATE_USER_PASS=mycustompass
AUTO_CREATE_USER_ACCESS_LEVEL=10
next step is removing default admin/password combination, maybe generating a random admin password on first startup if its not set via environment.
update:
https://dev.tt-rss.org/fox/ttrss-docker-compose/commit/959e07700ffe28fbfac8b780c8fa6d2ad67a2d6d
unless ADMIN_USER_PASS is set via .env, a random password will be assigned (and output to app container log) to internal admin user if it is using default password (password).
note that this would not be limited to first launch only (i guess i screwed up commit title there a bit), so if you kept your admin/password combination the default all these years, consider this a heads up.
https://dev.tt-rss.org/fox/ttrss-docker-compose/commit/c8b2b664028cc3d4edb1f47cd1abfde3b6cc4c35 - docker hub branch.
Great work.
Looks like you’ve added setting admin password and creations of a default user with password?
So if I wanted to pull this to use it, is it part of the dockerhub-static branch ir a dev branch?
both branches now (and baked into docker hub image) so you should be able to just use it with whatever method.
Ooh. I did a deploy today. And then as part of importing checked for the existence of the user. Woot.
Hey if I import an opml for a user that already has feeds. Will it do nothing, or duplicate the feeds? Saves me having to check if it does nothing
you won’t get duplicate feeds, however filters (if any) would get duplicated on every import so this might not be the best idea.