Cloudron Forum

You can test on the User agent string. See https://docs.cloudron.io/apps/lamp/#health-check for an example

Looks like some tmpfs corruption caused files to have incorrect permissions. The reboot cleared up tmp and the previous state was not there. Just redownloading 8.0.1 and updating again made it work.

Hi, and thanks so much for the replies - much appreciated

It seems the issue here may have been a lot of CPU steal on my VPS, my provider has moved my VPS to a different host server and now it seems to be no longer timing out. Still monitoring, but seems to be the situation.

@tomw Apologies; I wasn't trying to suggest you shouldn't do this. I was only trying to emphasize that there is an entire system/chain that leads to your server.

You might have:

The nation-state working in tandem with local (or, are they state-owned?) ISPs to implement man-in-the-middle cert attacks, so that attempts to securely connect to your server are actually plain-text. The nation state, working with ISPs to compromise/log all traffic through DNS servers. ...

https://www.cisa.gov/news-events/alerts/2015/04/30/securing-end-end-communications

is an article that speaks to some of the kinds of things that you might have to do to begin securing end-to-end communications.

Ultimately, I really don't know. I'm just suggesting---YMMV, etc.---that this sounds like something with high stakes.

I wish you and your colleagues all the best of luck.

PS. https://www.cjr.org/tow_center_reports/guide_to_securedrop.php looks interesting as well. Again, it doesn't apply directly to your case, but speaks to the broad spectrum of design considerations that go into architecting and delivering secure systems, where "systems" means "a combination of technology and people."

Once I didn't find it, I hypothesized that by dowloading the logs, I would get more info, but I couldn't download them.

Not sure if it would be useful, but I figure I'd mention it.

Ah I see, there is a stylesheet bug when a background image is used. Fixed with https://git.cloudron.io/cloudron/box/-/commit/ccb925be5d9c9280a34b2a6e506a02d211ca5e9f

Anyone curious about the issue, if filter properties are applied, all child nodes will be put on the same plane and thus multiple z-index values for that node tree does not apply.

This is fixed for the next version.

redis logs are of the format pid:role timestamp loglevel message . pid is container local.

Role is:

X sentinel C RDB/AOF writing child S slave M master

Unfortunately, there is no way to change the log format in redis (afaik). We just need the message really (others are not useful on Cloudron). See also https://github.com/redis/redis/issues/2545

@girish perfect thanks!

The rabbit hole is when you have to delete from backups too. Some people I'm sure try to weaponise GDPR to cost you time and the most inconvenience.

(Best not even say here if you think that's the case, they might even try to claim they are identified by implying.)

@nebulon perfect, thanks for confirming!

logrotate is run via the system cron. You can check these:

/etc/logrotate.conf should contain the line include /home/yellowtent/platformdata/logrotate.d in the very end.

The file /home/yellowtent/platformdata/logrotate.d/platform should contain /home/yellowtent/platformdata/logs/turn/*.log

As for cron configuration, systemctl status cron should say Active/running. There should also be a file /etc/cron.daily/logrotate .

Other than that, it can only mean that turn server generated a massive amount of logs in a single day (seems quite unlikely but who knows).

Does it rotate if you run logrotate manually? - Run /usr/sbin/logrotate /etc/logrotate.conf ?

@mastadamus thanks so much for investigating. I have removed it for next release (7.1) - https://git.cloudron.io/cloudron/box/-/commit/6492c9b71f80120413ff4ae7eefa2f03dc96ea0f

@vladimir-d The only other case an app is restarted without anyone triggering it is if an app using the tls addon had the certificate renewed. Unless this is a custom app, there is only the AdGuardHome app that uses the tls addon. So, is this app AdGuard Home?

I think you can get more insight by looking into the corresponding logs at the lines above those lines. What does it say above the lines you posted?

@girish lol, "Just do it!" 😉

Note: It took me a minute to put this together while @nebulon was responding and I got pulled onto something else for a minute, but I think the detailed writeup is worth having for posterity, so I'll post it anyway.

So what's going on here is that the app in question isn't reading the "right" headers to find the remote address. Basically, the inbound requests come in and hit the box-level nginx reverse proxy, which forwards the request on with the original inbound IP in the X-Forwarded-For header. Since from the sound of it, you're just routing straight to your app in the container, you'll want to either reconfigure your logging library to use the forwarded IP header as the client IP or drop nginx or similar as a reverse proxy in front of your app and configure it to rearrange the incoming headers as your app needs.

Sounds like you can just adjust a configuration so that this (your existing flow) works nicely:
container-sans-rp.png
Basically, here, the headers are adjusted in the "Step 1" processing as they reach the Cloudron so when they reach your app, the proxied headers have already gone into place. Again, this configuration should be fine with the configuration that @nebulon mentioned going in, since that should reconfigure your framework to read these adjusted headers correctly.

Failing that, or for apps with more complex setup or which aren't able to read those headers on their own by configuration, the solution is to further proxy those requests, by adding nginx or similar to take over the "Step 3" handoff and smooth out any specific details (like re-adjusting headers) for the app, and having it proxy those requests down to your app, all in-container, so that the logging and such in your app will all match up with expectations/reality. The whole point of the second reverse proxy when it's added it to make the world appear as it needs to for the app and/or its components inside the container.
container-rp.png

@robi for the first logviewer mismatch, this is because the first time shown is from the logservice itself and is translated into the local time of your browser, whereas the second comes from the app itself and is just treated as a plain string. Apps normally run in UTC.

For the winscp part, I am not sure how winSCP translates timestamps. The folder names are set from server time.

I don't think any of this will have anything to do with DB reconnection, if you have any issue there, please make a new entry in the TS forum section with some more info.