Thank you for the information!
Sorry for taking so long to reply, and sorry in advanced for being unhelpful. If anyone else knows the answer, please take this over. I’m not sure I’m going to be qualified enough to help.
Can I first ask if these apps have worked for you in the past?
Secondly, are the apps that give you a 403 all hosted on the same m00s.domain.tld?
I have no idea why you’re getting 403s, but the above domain is the only place I could see them in your nginx log. 403 is a permissions error. Do you remember ever sudo chmod -R 700-ing a folder?
There could be a few causes of this issue, but I’m far too barbaric to think of a proper & safe way to fix it. My solution: don’t use that domain, and continue using subdomains like pool.m00s.domain.tld
That’s the important stuff, everything below is on an app-to-app basis, and doesn’t matter if the above advice was good enough.
Scrutiny looks fine in that log? P.S. the maintainer (ewilly) is an absolute god.
Geoquest says that you need to use --host to expose it to the network… Otherwise it should only be accessible from the host machine itself. Did it come configured like that? That’s really strange. Is NGINX supposed to be a workaround for that? Personally, I’ve never been able to get around exposing those. Literally adding --host to a line somewhere would fix this, but I have never used geoquest. I see that this app is on its first ever yunohost package with no revisions; has it ever worked? Let me spin up a VM to test my hypothesis.
Glances is also having issues with ports, or it’s having issues with the ports plugin. again, not a lot of info provided.
sudo journalctl -xeu glances.service
The opencloud log looks perfectly fine, what it’s reporting isn’t a problem as long as you don’t notice a problem. EOF is End Of File, which just means it’s done reading the data.
NGINX logs: I see a lot of OSCP errors, which is expected since OSCP is dead.
Not sure if this could cause an issue. If your SSL certificates aren’t renewing, this could be a cause.
I’m looking at my NGINX logs to compare to yours, and I have no OSCP warnings (I do have a guy trying to brute force me 154.83.103.115).
Is your issue connecting ever something like “This server uses HSTS, you can not connect”?
NFTables: unlikely the issue; it is a firewall, but it shouldn’t be filling the ports, just blocking them. Failing for more than 55 years is fine. That brings us to 1970, the unix epoch. Forgive me if you know this, but 1970 is when the unix clock starts, so this just means the date is corrupted/missing so it was reset to 0. The logs here also did not give me a lot to work with. sudo journalctl -xeu nftables.service
Honestly, all of these logs seemed to include journalCTL anyways, so I’m grasping at straws. Hoping that the -x changes the output really. Since the SSH commands are not censored like yunopastes are, if the outputs look largely the same, just let me know instead of sending them.
And I 100% agree that solving these issues is better than reinstalling. We get experience, knowledge, and satisfaction from working on these ourself… Even if it’s a ‘little’ contrarian to yunohost’s goal of becoming user-friendly. Maybe the real solutions are the friends you make along the way?
)
I had other priorities.
