What happens? (writefreely db init)

As far as I’ve been able to gather, the command writefreely db init uses the configs in config.ini to initialize the database.
(mariadb/mysql in my case)

In trying to automate deployment of this server, would this be problematic to rerun?

I have started the server, made a user, imported some posts, then reboot the podman containers using a script, which is essentially outlined in the pull request of the docs I made (https://github.com/writefreely/documentation/pull/39).

I think that rerunning the script is causing problems I am seeing, but I do not know mysql/mariadb that well.

So what does the command writefreely db init do?
Any erasing? Just creation?
If just creation, would you know if mysql/mariadb overwrites tables or something?

The writefreely db init command:

  • creates the initial database tables
  • runs all database migrations

If you run it multiple times, it’ll just try to do that again, and will output errors (without failing) about database tables already existing. It will apply any missing migrations. But if a table was deleted, it’d simply re-create it (probably without later migration changes applied). If a table was otherwise modified, WriteFreely will have no way of knowing that.

Is there a reason in particular you’d need to re-run this? In most cases, admins only need to run this once. Then beyond that, they’d run: writefreely db migrate, which is safe to run multiple times, on each version upgrade, etc.

Short version: Yeah, I am wanting an automated startup script and I am doing it with podman. One that will set the server up if it is not already setup, as it is supposed to deploy on first boot.
This being said, if I run the current setup script with writefreely db init in it a second time (after having created a user and put in posts), and I can no longer login.
I was wondering what might be causing that.
Is there anything further you’d suggest I look at for troubleshooting?

Long version:
I’m making an ignition file for CoreOS, so I can deploy writefreely to the OS on first boot. This means using rootless podman containers using systemd units that get recreated every time the service is reset.
In order to make writefreely functional on first boot, I need to run the writefreely db init command. Doing this once has worked perfectly. Blog posts can be made, it is externally accessible, drafts, moving posts, etc… Running the script a second time (What would happen when restarting the systemd unit) results in the following:

2022/02/16 01:25:17 Loading config.ini configuration...
2022/02/16 01:25:17 Connecting to mysql database...
2022/02/16 01:25:17 Creating table accesstokens...
2022/02/16 01:25:17 Created.
2022/02/16 01:25:17 Creating table appcontent...
2022/02/16 01:25:17 Created.
2022/02/16 01:25:17 Creating table appmigrations...
ERROR: 2022/02/16 01:25:17 app.go:903: Error 1050: Table 'appmigrations' already exists
2022/02/16 01:25:17 Creating table collectionattributes...
2022/02/16 01:25:17 Created.
2022/02/16 01:25:17 Creating table collectionkeys...
2022/02/16 01:25:17 Created.
2022/02/16 01:25:17 Creating table collectionpasswords...
2022/02/16 01:25:17 Created.
2022/02/16 01:25:17 Creating table collectionredirects...
2022/02/16 01:25:17 Created.
2022/02/16 01:25:17 Creating table collections...
2022/02/16 01:25:17 Created.
2022/02/16 01:25:17 Creating table posts...
2022/02/16 01:25:17 Created.
2022/02/16 01:25:17 Creating table remotefollows...
2022/02/16 01:25:17 Created.
2022/02/16 01:25:17 Creating table remoteuserkeys...
2022/02/16 01:25:17 Created.
2022/02/16 01:25:17 Creating table remoteusers...
2022/02/16 01:25:17 Created.
2022/02/16 01:25:17 Creating table userattributes...
2022/02/16 01:25:17 Created.
2022/02/16 01:25:17 Creating table userinvites...
ERROR: 2022/02/16 01:25:17 app.go:903: Error 1050: Table 'userinvites' already exists
2022/02/16 01:25:17 Creating table users...
2022/02/16 01:25:17 Created.
2022/02/16 01:25:17 Creating table usersinvited...
ERROR: 2022/02/16 01:25:17 app.go:903: Error 1050: Table 'usersinvited' already exists
2022/02/16 01:25:17 Initializing appmigrations table...
2022/02/16 01:25:17 Closing database connection...
ERROR: 2022/02/16 01:25:17 main.go:120: Unable to set initial migrations: Error 1932: Table 'writefreely.appmigrations' doesn't exist in engine

Then log in attempts will appear to just refresh the page.
No errors show up. Not even in the developer console of firefox.

Attempting to sign up (in this case https://MY.BLOG.SITE/signup) again does, though. On the sign up page, I get error 500 (server error page) showing Referrer Policystrict-origin-when-cross-origin.

Lastly, Writefreely many logs, such as the following:

ERROR: 2022/02/16 01:41:15 database.go:808: Failed selecting from collections: Error 1932: Table 'writefreely.collections' doesn't exist in engine
ERROR: 2022/02/16 01:41:15 posts.go:373: Post loading err: Error 1932: Table 'writefreely.posts' doesn't exist in engine
2022/02/16 01:41:15 "GET /signuagain" 500 2.004157ms "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15"
2022/02/16 01:41:15 handleHTTPErorr internal error render

I don’t really know the affect of doing things in mariadb/mysql, so I was needing to ask to see if properly automating was possible, at the moment.

This being said, if writefreely shouldn’t know the difference, is there anything further you’d suggest I look at for further troubleshooting?