@jadudm so let me get this straight...because switching off IP address logging is not sufficient to protect against a determined nation-state actor, we're just going to leave it switched on?
Earlier on, @girish asked why one would want to turn off IP logging. I have given a very good reason.
Let's turn the question around: what business do I have logging the IP addresses of human rights activists on my server? Why do I need to collect this information?
@girish I hear what you're saying. At the same time, given that all requests to the various apps pass through nginx (if we just consider apps running on port 80/443 for now), isn't there an opportunity here to obfuscate the IP addresses with a fairly simple nginx config change?
VPN is certainly a good idea for these users too.
@girish I am helping a small group of exiled human rights activists here in the EU and would like to provide them with a Matrix/Synapse server on my Cloudron for their internal communications.
They work specifically on human rights abuses in their home country, which is an authoritarian regime outside the EU with a track record of attempting to identify exile activsts and punishing their families in the authoritarian country for their activities.
The activists are concerned that if the authoritarian regime gained access to the server, the stored IP addresses could be used to identify them.
Maybe this is all too hot for Cloudron to handle, but for this risk profile it would be really nice if I could disable IP logging, so that the activists could use the server without information that could lead back to their real world identities being stored there.
People here might be interested in Wagtail CRX (formerly CodeRed CMS). In the words of the developers, this is a set of extensions that "provides a large set of enhancements and pre-built components for Wagtail which are ready to use out-of-the box".
I've been playing around with it and it seems to be a nice option if you want to get a basic website up and running fast with basically no coding, but built on the solid framework of Wagtail/Django so you have a nice stack to build in when it's time to start writing code.
It does break the strict content/presentation separation of Wagtail, but I think the rationale for this makes sense and it's a good middle way.
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
@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.
@mehdi And protecting source material is literally my job 
I said mailbox encryption could be helpful against disclosure orders - not that it provides protection in all cases.
This is a fast-moving issue and the situation will be different in different jurisdictions and under different threat models.
But here's one data point to illustrate what I'm saying: in Germany, the email provider Tutanota was ordered to intercept future incoming and outgoing emails for a user account. But the previously received and encrypted emails were unaffected:
The Tutanota spokeswoman said the monitoring function will only apply to future emails this account receives — it will not affect emails previously received.
It won't always be like this in every situation. But just as there will be times when legal orders force admins to intercept encryption passwords, there will also be times when courts do not go that far and the encryption remains effective.
In my scenario, the owner of the mailbox would not be anonymous. The purpose of the encryption, for me, would be much more about shifting the burden of responding to a legal request onto the user, rather than attempting to provide a bulletproof technical solution.
@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.
@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.
@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 
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?