Cloudron Forum

@SansGuidon I guess I should have completely reread your initial post before dropping the link

Maybe he meant https://docs.cloudron.io/networking/#blocklist instead

@humptydumpty said in At home self-hosted Cloudron - migrate to larger main disk. Advice and sanity check my thoughts.:

Having a GUI is preferable.

I would also have recommended dd

Something I havent used in ages, but i think would satisfy the gui criteria is https://clonezilla.org/

@ei8fdb said in At home self-hosted Cloudron - migrate to larger main disk. Advice and sanity check my thoughts.:

Install same <?> Ubuntu OS and Cloudron version?

If you clone the disk from your old nvme to the new one (and afterwards extend your partitions) they you can spare yourself the work with the fresh install and redoing your mount configuration.

If i remember correctly in the past the json response from the app store included the total install count of the app, but that has been removed meanwhile as it seems.

But total numbers probably expose too much behind the scenes knowledge anyways.

Another manufacturer with an app store concept used to publish their "top 10 app" once per quarter before they abandoned their market place. maybe that could be an interesting (and hopefully not too repetitive) marketing piece?

@girish said in Solr and Adding a New Mail Domain:

When the mail service is restart [..] the email apps [..] are also restarted

Without having explicitly tested this, but I think there is a possibility for clients getting confused when clients briefly see:

This app is currently not responding. Please try refreshing the page in a few minutes.

While still a http return of 200 is given (which does seem to be the case here). But on the other hand I also don't think that this specifically could trigger password prompt, since whatever the client sends as basic auth here would just be accepted by the server and not rejected.

@crazybrad said in Solr and Adding a New Mail Domain:

Any advice based on your Kopano knowledge with EAS?

I'm not overly familiar with Sogo, but you mentioned desktop so I am guessing you are referring to Microsoft Outlook on the desktop. ActiveSync was never really made for desktop applications and therefore potentially syncing gigabytes from many folders (coupled with very large request/response sizes) can put quite some load on the server and in my experience also leads to issues on the client sooner or later. That is why we have abandoned that approach and switched to an implementation of mapi over http for this client in our latest product. The sogo documentation already lists some of the limitations of that approach as well.

On point that is made here is problematic from an implementation standpoint:

ActiveSync clients keep connections open for a while. Each connection will grab a hold on a sogod process so you will need a lot of processes to handle many clients. Make sure you tune your SOGo server when having lots of ActiveSync clients.

Blocking a worker for an idling open request will waste a lot of resources. We had the same issue in the past, but for us it was just a php connection being held open. For better scalability we are now parking these connections in a separate "proxy" to free resources in our actual server. But this is something that Sogo would need to implement (as in develop such a proxy and hand the connections off) and nothing that you as the user can influence. Generally speaking as long as you have set your client to use "push" there is nothing you can do to lessen the load on the server.

while looking up something else I noticed that my Nextcloud app install is already more than six years old.

I tried looking up which oidc plugin for Nextcloud I last gave a try, but I was unable to find which one it was.

In the end I needed to disable the plugin as Nextcloud kept constantly logging me out of all my sessions. So before you roll the update out I would recommend to make a long term test with all the apps that are part of the Nextcloud eco system (Desktop apps, apps on mobile for Nextcloud itself, but also Talk, etc).

An interesting discussion and it confirms my expectation that Cloudron is following modern and good security practices.

in case others are coming back to this discussion later, gitlab also offers permalinks to code files and lines, so that will always work: https://git.cloudron.io/platform/box/-/blob/e536c94028b3ce56f468011af8ca656abb78b37f/src/users.js#L800 (only exception would be if this commit somehow gets completely removed from the repo).

The database is not exposed anywhere so setting a password as such does not add any extra security, which is why it is password to make that clear and avoid obfuscation.

You could switch to https://mariadb.com/kb/en/authentication-plugin-unix-socket/ to get rid of the password completely. this would also strengthen security further by limiting which local users have access.

Edit: does Cloudron have some internal logic like complexity rules apart from the "Password must be at least 8 and at most 265 characters" check of the ui?

yes, that sounds good to me. For the moment I have increased the limit on my server by simply adding another zero.

I have a testing mailbox called "many-folders", which on its own already exceeds this limit:

find /home/yellowtent/boxdata/mail -type d -empty | grep many-folders | wc -l
23811

The total line count when not grepping for my test mailbox is 31099.

Depending on the amount of users and if these users are folder hoarders 20.000 may be a bit too low in my opinion. Every folder in the mailbox is represented with three folders in the maildir (cur, new and tmp) and most of the time new and tmp will be empty.

Hi,

this morning I noticed that since the 31st (and the update to 8.2.1 from 8.1.0) my backups keep failing with the same error message:

Too many empty directories. Run "find /home/yellowtent/boxdata/mail -type d -empty" to investigate

In the log this can be found for such a task:

2025-01-03T07:15:34.868Z box:shell backupformat/rsync: find /home/yellowtent/boxdata/mail -type d -empty
2025-01-03T07:15:41.125Z box:shell backupformat/rsync: find /home/yellowtent/boxdata/mail -type d -empty errored BoxError: find exited with code null signal SIGKILL
    at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:72:23)
    at ChildProcess.emit (node:events:519:28)
    at maybeClose (node:internal/child_process:1105:16)
    at Socket.<anonymous> (node:internal/child_process:457:11)
    at Socket.emit (node:events:519:28)
    at Pipe.<anonymous> (node:net:339:12) {
  reason: 'Shell Error',
  details: {},
  stdout: '/home/yellowtent/boxdata/mail/solr\n' +
[..]
    '/home/yellowtent/boxdata'... 2599152 more characters,
  stdoutLineCount: 20073,
  stderr: '',
  stderrLineCount: 0,
  code: null,
  signal: 'SIGKILL'
}
2025-01-03T07:15:41.205Z box:backupupload upload completed. error: BoxError: Too many empty directories. Run "find /home/yellowtent/boxdata/mail -type d -empty" to investigate at saveFsMetadata (/home/yellowtent/box/src/backupformat/rsync.js:131:82) at async Object.upload (/home/yellowtent/box/src/backupformat/rsync.js:270:5) at async Object.upload (/home/yellowtent/box/src/backuptask.js:92:5) { reason: 'FileSystem Error', details: {} }
2025-01-03T07:15:41.373Z box:backuptask runBackupUpload: result - {"result":"Too many empty directories. Run \"find /home/yellowtent/boxdata/mail -type d -empty\" to investigate"}
2025-01-03T07:15:41.533Z box:shell backuptask: /usr/bin/sudo -S -E --close-from=4 /home/yellowtent/box/src/scripts/backupupload.js snapshot/mail rsync {"localRoot":"/home/yellowtent/boxdata/mail","layout":[]} errored BoxError: backuptask exited with code 50 signal null
    at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:137:19)
    at ChildProcess.emit (node:events:519:28)
    at ChildProcess._handle.onexit (node:internal/child_process:294:12) {
  reason: 'Shell Error',
  details: {},
  code: 50,
  signal: null
}
2025-01-03T07:15:41.612Z box:taskworker Task took 415.137 seconds
2025-01-03T07:15:41.614Z box:tasks setCompleted - 19010: {"result":null,"error":{"stack":"BoxError: Too many empty directories. Run \"find /home/yellowtent/boxdata/mail -type d -empty\" to investigate\n    at runBackupUpload (/home/yellowtent/box/src/backuptask.js:172:15)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at async uploadMailSnapshot (/home/yellowtent/box/src/backuptask.js:413:5)\n    at async backupMailWithTag (/home/yellowtent/box/src/backuptask.js:462:5)\n    at async fullBackup (/home/yellowtent/box/src/backuptask.js:523:26)","name":"BoxError","reason":"External Error","details":{},"message":"Too many empty directories. Run \"find /home/yellowtent/boxdata/mail -type d -empty\" to investigate"}}
2025-01-03T07:15:41.615Z box:tasks update 19010: {"percent":100,"result":null,"error":{"stack":"BoxError: Too many empty directories. Run \"find /home/yellowtent/boxdata/mail -type d -empty\" to investigate\n    at runBackupUpload (/home/yellowtent/box/src/backuptask.js:172:15)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at async uploadMailSnapshot (/home/yellowtent/box/src/backuptask.js:413:5)\n    at async backupMailWithTag (/home/yellowtent/box/src/backuptask.js:462:5)\n    at async fullBackup (/home/yellowtent/box/src/backuptask.js:523:26)","name":"BoxError","reason":"External Error","details":{},"message":"Too many empty directories. Run \"find /home/yellowtent/boxdata/mail -type d -empty\" to investigate"}}
BoxError: Too many empty directories. Run "find /home/yellowtent/boxdata/mail -type d -empty" to investigate
    at runBackupUpload (/home/yellowtent/box/src/backuptask.js:172:15)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async uploadMailSnapshot (/home/yellowtent/box/src/backuptask.js:413:5)
    at async backupMailWithTag (/home/yellowtent/box/src/backuptask.js:462:5)
    at async fullBackup (/home/yellowtent/box/src/backuptask.js:523:26)

What I am wondering about is the find exited with code null signal SIGKILL part. null seems a weird exit code and also running the find command manually finishes with exit code 0. As far as I can see the server should not be running out of resources during this and no related error seems to be in dmesg.

Do other solutions, like for example guacamole suffer from the same issue?

I think i am personally leaning towards using the cloudron cli, as this way I can use tmux for persistence and can even share the session. I had tabs crashing because too much memory was used and a reload will always start a new session.

I wanted to give the new VPN app a try to see how easy it is to get Wireguard going with it. Since i am not planning on using OpenVPN i just disabled both the tcp and udp options for "vpn" (maybe this could be renamed to OpenVPN to make it clearer). In the settings this was not an issue, but when then starting the app it is stuck in "Starting.." and the following is logged repeatedly

2024-12-28T16:38:09Z 2024-12-28 16:38:09,577 INFO spawned: 'openvpn' with pid 201
2024-12-28T16:38:09Z 2024-12-28 16:38:09,593 INFO exited: openvpn (exit status 1; not expected)
2024-12-28T16:38:10.000Z => Healtheck error: Error: connect ECONNREFUSED 172.18.19.53:3000
2024-12-28T16:38:10Z 
2024-12-28T16:38:10Z 
2024-12-28T16:38:10Z 2024-12-28 16:38:10,633 INFO reaped unknown pid 188 (exit status 1)
2024-12-28T16:38:10Z 2024-12-28 16:38:10,642 INFO exited: admin (exit status 1; not expected)
2024-12-28T16:38:10Z Error: Could not restart OpenVPN: Command failed: sudo /app/code/src/restart.sh
2024-12-28T16:38:10Z Node.js v22.11.0
2024-12-28T16:38:10Z ^
2024-12-28T16:38:10Z at async Object.init (file:///app/code/src/vpn.js:760:5)
2024-12-28T16:38:10Z at async main (file:///app/code/server.js:190:5)
2024-12-28T16:38:10Z at async ovInit (file:///app/code/src/vpn.js:660:5)
2024-12-28T16:38:10Z at ovSyncSettings (file:///app/code/src/vpn.js:193:27)
2024-12-28T16:38:10Z file:///app/code/src/vpn.js:193
2024-12-28T16:38:10Z if (safe.error) throw new Error(`Could not restart OpenVPN: ${safe.error.message}`);
2024-12-28T16:38:10Z openvpn: ERROR (not running)
2024-12-28T16:38:10Z openvpn: ERROR (spawn error)
2024-12-28T16:38:11Z 2024-12-28 16:38:11 --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2024-12-28T16:38:11Z 2024-12-28 16:38:11 CRL: loaded 1 CRLs from file /app/data/pki/crl.pem
2024-12-28T16:38:11Z 2024-12-28 16:38:11 Diffie-Hellman initialized with 2048 bit key
2024-12-28T16:38:11Z 2024-12-28 16:38:11 Exiting due to fatal error

The solution is to go back into the location settings and enable at least one of the two.

When we have a Cloudron meetup at Fosdem I may have to come as well.

I was still debating with me if I wanted to go. Another plus is that with the recent change in train schedule there is now a direct train from my next bigger city to Brussels once per hour.

Not sure if this is by design or a bug. Today I noticed (on a system running Cloudron 8.1.0) that regular users (not an admin, not an operator) can see the update notifications on the app tiles. When clicking on these notifications the error "user is not an operator" is given.

My expectation would have been:

• normal users should not see update notifications (the green dot with the up arrow)
• if that dot is show, i don't think it should even be clickable

Yes, every server that the mail passes through gets documented with a received header in the message.

https://www.thesslstore.com/blog/how-to-read-an-email-header/

The client can not influence this, but the mail server could remove this information. https://serverfault.com/questions/413533/remove-hide-client-sender-ip-from-postfix

You may want to replace ssh with autossh, so that the connection is restored in case it stops working. This howto looks quite complete: https://m0agx.eu/yet-another-autossh-tutorial.html

@jdaviescoates said in Has anyone got the Element X App working with Cloudron Matrix?:

unless that's just me?

I tried the element x app on ipad os and when selecting my Cloudron homeserver I am getting a message "Server not supported" and "The selected homeserver doens't support password or oidc login.". Also the QR code login is shown as "not supported" within Element. Is it that what you mean?

@andreasdueren i don't know if this is the only way, but when I encountered this error message i manually created a user with the same username as my cloudron user. Afterwards i could use oidc for login.