@martinkbs it will be good to have documented the tested rclone setup as part of the documentation!

Ubuntu notice - https://ubuntu.com/security/notices/USN-4891-1

I've synced the expiration now to 7 days to keep changes low until we have a reason to change it Instead of making it configurable I would prefer a sensible default, since so far no-one else has complained.

Ok, thanks

@girish easy enough!

@brutalbirdie Thank you, I'll give that a shot!

@stoccafisso I think I am able to reproduce this in one of our managed Cloudrons. Looking into the fix.

how embarrassing. You're absolutely right. I was searching after ghosts.

I will mark this as solved for now but also ack that there is possibly some bug either on minio side or Cloudron side.

@vladimir Usually for LAMP app, we tend to create separate apps. i.e LAMP 7.3, 7.4 and in the future 8, are totally separate apps. So, your app won't update automatically. For addons which are shared across apps, we don't have a way to do this. I guess one idea is to have the app "pin" itself to a specific mysql version and that way we will have multiple mysql databases with different versions running in parallel. Doable but quite complicated! I think @luckow also reported that MySQL 8 broke his drupal app. Good news is that I don't expect such a big upgrade any time soon.

@girish I guess I'm wondering though why it'd say "Not available yet"... is that because I had restarted the server a few hours earlier? I don't normally notice that though when I restart, it usually still shows data. Is it possible there's a bug here? If the restarts are losing that data, then I'd think that's a bug, right, if it shows for some services but not all? To me that makes it seems like it's either not completing properly when it runs and that could maybe explain why it shows values for some but not all, or perhaps it's losing data when it should be remembering it. My gut tells me there's a bug here. Or am I way off? I guess it's okay since we have a workaround to run that command when it happens, my brain is just wondering why it happened in the first place and how it could be prevented.

I got hold of an iPhone temporarily to test this and I've fixed this now with https://git.cloudron.io/cloudron/dashboard/-/commit/ff5ad8b062414d8a972631a19b181c80d2adc15d Essentially we avoid rendering the native select dropdown button but style it ourselves so we can control also how the dark-mode rendering is done.

@girish yay, thanks for the explanation !

@girish That did the trick. Thanks!

@mastadamus yes https://git.cloudron.io/cloudron/box/-/commit/f3d9b8194264469152bc38d24d7080c611784b33

@girish On it. Neat! This fixed it. Big thanks for the uddate.

@fbartels awesome, thanks for testing. I am fixing the graphite issue, that error is something else. Fixed in https://git.cloudron.io/cloudron/box/-/commit/f7bd47888ac157fc5b86021f6458b6a7f0d3fba8

OK, this got sorted out by enabling basicAuth flag. Thanks for testing @mehdi

Okay... I may be on the side of this working properly again. lol. Maybe I've been wrong this whole time in thinking it wasn't working correctly. So coincidentally I was checking the mail server logs and saw another example of the same message go through to the same recipient from the same mail server, it was listed in the logs as "just now" so I quickly checked mxtoolbox and found that only 4 at that time had been listed, none of which were ones I was using. Here is how it looked at the very moment I checked when it was "just now" in the logs: [image: 1616004904806-69bc5a02-12ca-420e-958a-27405c21f7ed-image-resized.png] [image: 1616004923806-07b937c4-4840-4c14-887b-7513acc87251-image-resized.png] Edit: Checking about 6 minutes later, I see the blocklists have aleady been updated for more (Spamhaus Zen in this case would have caught it if it were about 5 minutes earlier): [image: 1616005021879-4522d168-dc21-498f-845b-885cfe0a73a1-image-resized.png] So I guess we can probably mark this as resolved, as I now see conclusive evidence that the various blocklists used just didn't have it listed until a few minutes after the message was received. I guess in order for it to adapt so quickly this spam attack on one of my users from those mail servers must be right at the beginning of a spam wave. Kind of neat actually to see how real-time these lists are. haha.

I think one idea is to patch the user ids to match the existing cloudron user ids (in the database directly). I don't know if this will work, but I am just trying this out with @yusf and will report back.