Failure on Mastodon

[criky]

Hi j12t.
Good morning
Now I am using Mastodon on my box without any problems except one tiny thing.

Whenever I invoke the command

Code: Select all

systemctl is-system-running

, then answer always remains "degraded" rather "running" due to the site running Mastodon.
(Take a note that this does not mean I have any operational problems in my normal use.)
I am quite sure Mastodon site causes this situation because when I undeploy only Mastodon site with others keeping, system status goes back to normal(running).

Are you already aware of this issue, and still working on it?
If so, I would like to know if you have any plan for it.

[j12t]

You seem to have two unrelated issues:

1. I don't know what's going on with your private key. If you can reproduce it, it would be useful to know how you got into this state because I have not seen that since the latest update.

2. The mastodon issue indeed is a known issue and can be found on Github. [1]


[1] https://github.com/uboslinux/ubos-app-m ... /issues/26

[criky]

You seem to have two unrelated issues:

1. I don't know what's going on with your private key. If you can reproduce it, it would be useful to know how you got into this state because I have not seen that since the latest update.

2. The mastodon issue indeed is a known issue and can be found on Github. [1]


[1] https://github.com/uboslinux/ubos-app-m ... /issues/26

Thanks for your information.

As for the first topic, if reproducing the private key would be useful enough for me to investigate, then could you tell me how to do that?
Currently what I know for the key is that it would be created every time I re-install my UBOS.

And I just wonder why only one of my sites(I have multiple sites on my box including Mastodon) has private key-related problems.
FYI this site has only one app, that is "redirect".(it routes the traffic referring www.xxx.com(with www) to xxx.com(without www))
And still this site with redirect app is now working quite well with no problem. That's why I think it's odd.

This issue might be related to the "letsencrypt" though, for I can see the folder name of "etc/letsencrype/live/..."
Could you explain me how my private key is related to the letsencrypt SSL certificate of my site?

[j12t]

If you regularly reinstall UBOS, as you seem to say, I would simply do it step by step, and check the file sizes after each step. The private key is being generated for an https site as soon as the site is first created, and right before the LetsEncrypt cert is issued. (If you read up on how TLS certs work, that may become clearer)

P.S. If you restore Mastodon from backup, rather than creating fresh, make sure that you don't restore the (invalid) private key from backup.

[criky]

1. To be clear, let me clarify one thing.
Do you mean "private key" as a pair of the "public key" which is being used for ssh connection?
Or one that being used only for the SSL certification by Letsencrypt?

2. As I said private key(for ssh connection) seems to be regenerated automatically, so that is not my intention.
How can I evade making a new key when I re-install the UBOS? Rather I'd like to keep the old key for a while.

3. As you pointed out, I do think "old" private key(ssh or ssl) from the backup is being used, rather than "new" one,
and that appears to be the root-cause of result of my configtest(privkey.pen does not exist or is empty)
When I checked again, all of my sites have same private key-relevant issue, not only one of them.(since they are all restored from the same multi-site backup)
So I have a plan to undeploy all of my sites and restore it from each of json files to prevent any Letsencrypt-related issues, which means a new creation of all sites.

I don't know what will happen(Maybe renewal of Letsencrypt certi will have some problems due to the absence of private key) if I do nothing on this issue.(private key issue still remains).
And if I use this method of recovery, I may lose all of my data except site and app configurations, so I doubt that what should I do when I want to backup and restore my TLS sites to prevent this situation again.
From my perspective, for the moment, not changing the key is one of the best way I have.

[j12t]

SSH keys and TLS keys are different. Both use public key cryptography, so there is a public key and a private key in every pair. But you cannot use one for the other.

Check the options for backup and restore. There are some options related to TLS keys.

You probably also can back up all your sites, undeploy all, and then create simple (or empty) TLS/Letsencrypt sites. And then restore the previously backed-up appconfigs (check restore options) to the existing sites. I would use an approach like this if other approaches don't work. But: this is just a guess as I don't know what exactly is going on on your box.

[criky]

You probably also can back up all your sites, undeploy all, and then create simple (or empty) TLS/Letsencrypt sites. And then restore the previously backed-up appconfigs (check restore options) to the existing sites. I would use an approach like this if other approaches don't work.

It can be a good practice! Quite similar with mine.
But the problem is both method can not restore the data(Nextcloud's data, Website contents etc) of the site I think.
So, all the contents and data need to be backed-up from the apps somewhere else before this method being implemented.

[j12t]

You can restore an AppConfiguration (such as your Nextcloud) from a site in an backup, to an already-deployed site with this version of "ubos-admin restore":

Code: Select all

ubos-admin restore --appconfigid <appconfigid> --tositeid <tositeid> [--newcontext <context>] --in <backupfile>