Thanks for the pointers, once again I realise I should really read the docs properly before posting!

Collabora and Nextcloud are working well, but one annoyance is the splash screen that appears every time I open a document:

This might be confusing for some of the people I share documents with, so it would be really great if there is a way to disable the splash screen.

Is this possible?

@mehdi That is true in the case of a malicious admin. But it also places the benevolent admin in the position where they have the unencrypted data in their possession (or if full disk encryption is used, they have the keys).

However for some admins, mailbox encryption could also have benefits in cases where third parties attempt to gain access to data through legal disclosure orders.

As a journalist, I would like to be able to offer email accounts on my Cloudron to my peers. However, I would be uncomfortable being in a position where I might one day have to make a call on the validity of a disclosure order (and/or fight it in court on my users' behalf if I thought it was wrong). For me it would be much better if this responsibility rested with the users themselves.

In short, encryption of stored emails would be an extremely interesting feature for me.

@marcusquinn I don't object to those aims in principle, but I think this particular splash screen fails to deliver.

For one thing the message about using a supported version is only relevant to admins - it will not make sense to users who have merely been sent a link to view a document.

Secondly, as there is no 'Don't show this message again' option, it is effectively a nag screen.

I guess I could make these points upstream and suggest an alternate wording that would speak to a wider audience (something like 'The document you are viewing is powered by Collabora, a free and open-source office software suite. To learn more about why this ia a good thing...' etc) along with the addition of a 'Don't show again' checkbox.

But in the interests of user freedom I still think we should be able to switch this off

@marcusquinn said in Encryption of stored emails:

there is no privacy from a determined spy

Very true. But for a lot of journalistic work, the adversary is not a determined spy.

Different security technologies are appropriate and useful in different circumstances.

@nebulon Thanks for the info! I hadn't realised that is how it is supposed to work.

I have Firefox set to clear cookies and site data on exit, so this explains why I see the message again even after logging in to NextCloud.

I will allow site data for my domain and that will solve the problem for me.

Update: We have successfully triggered emails with an @all to 46 people without errors, so the fix seems to have worked.

Ah, I just realised this only occurs when I have the Helpdesk Status set to Offline. The tooltip there does say

If the status is changed to Offline, the client interface will be disabled. Only Admins will be able to access the system.

So maybe this is my mistake, because a normal Agent is not an admin user. It still feels like there should be an error message rather than a redirect loop though. Maybe this is an issue for upstream?

I may have done something strange while configuring osTicket, but I'm having the following problem.

I can log in as root fine, and after creating a user as instructed in the Cloudron docs, I can also log in with a Cloudron username and password. Screenshot below.

However, if I untick that Administrator checkbox in the osTicket Manage Agent screen, the user account no longer works. I get the The page isn't redirecting properly error in Firefox. I can see from Developer Tools that it is bouncing between /scp/index.php and /scp/login.php:

Any ideas how I can fix this?

Thanks for the pointers, once again I realise I should really read the docs properly before posting!

I'm running out of space on my backup volume, and noticed that some apps are listing several old backups, even though my retention policy is set to 2 days. Here's an example:

And the retention policy:

Am I missing something? Shouldn't there be just two backups for each app?

Update: We have successfully triggered emails with an @all to 46 people without errors, so the fix seems to have worked.

@girish said in Too many concurrent SMTP connections:

Does that make things work?

Brilliant, thanks @girish! I have made the change and will report back next time someone sends an @all message.

Hi everyone,

I am using the Cloudron built-in SMTP server for the domain Mattermost sends email from and I just noticed in my logs that when sending a notification email to many users at once (e.g. resulting from an @all) , lots of them fail with an error like the following:

{"level":"error","ts":1614543114.932735,"caller":"app/notification_email.go:105","msg":"Error while sending the email","user_email":"[DELETED]","error":"SendMail: Failed to open TLS connection., 421 Too many concurrent connections"}

It looks like Mattermost tries to send all the emails at once and there is no retry logic, so the result of this is that only a fraction of the users will receive the notification emails that are expected. There is an upstream bug to add a configurable maximum number of connections that has been open since 2016.

I guess when using an external mail service, the large number of concurrent connections may not be a problem. For example, Sendgrid states that up to 10,000 concurrent connections from a single server are permitted.

However if possible I would like to stick with the built-in SMTP server so that it is not necessary to pass this data through a third party. In my case there are around 60 people in the Mattermost team, so that should be the theoretical maximum number of emails being sent simultaneously.

I am wondering if it would be practical to bump up the number of simultaneous connections allowed by the built-in SMTP server to 60 without causing problems? Or if anyone has any other ideas for a way around this problem?

Tom

Hello,

I have a question about the update schedule. My Cloudron is set to the default schedule of 11 PM,1 AM,3 AM,5 AM every night.

I am just wondering what is the advantage of scheduling updates four times every night? Is there something about the timing of updates that means multiple checks through the night are worthwhile? Or is there another reason for this?

It is not a problem for me, although I will probably disable the 11 PM update as there are quite often people still chatting on my Mattermost instance at that time.

Tom

@nebulon I experienced something similar. Currently graphite, mail, mongodb and mysql appear orange. Here's the response for graphite, for example:

{
  "service": {
    "name": "graphite",
    "status": "starting",
    "error": "Error waiting for graphite: ESOCKETTIMEDOUT",
    "healthcheck": null,
    "config": {
      "memoryLimit": 268435456
    }
  }
}

Each time I refresh the page, it seems to be a lucky dip which of those come back as green and which as orange. e.g. a second time everything was green except mail, a third time mysql is orange again.

Hello,

I noticed that adding the ldap add-on to my Cloudron manifest did not have any effect until I uninstalled and reinstalled the app (i.e. after doing a cloudron update, even with a new version number in the manifest, the ldap environment variables remained unset and the Cloudron UI also still stated that the app still did its own user management).

I'm not sure if this is the intended behaviour but thought maybe it would be good to note it in the documentation (apologies if it is already there, but I couldn't see it).

This is a bit of a 'My First App' so nothing that is worthy of consideration for the App Store at the moment, but I will let you know if that changes!

Tom