Recently I played arround, to improve e-mail security with MTA-STS. I was able to simply use surfer app to publish the mta-sts.txt file and set up the necessary DNS entries. But the solution is somewhat clunky, so may be it might be an easy win @girish , to make this directly possible through cloudron ui, until we implement DANE into cloudron.

Steps to reproduce working MTA-STS setup in cloudron useing surfer app

1. setup surfer app at the following subdomain mta-sts.<DOMAIN.TLD>

2. make folder .well-known inside folder public

3. create mta-sts.txt

version: STSv1
mode: enforce
max_age: 86400
mx: mail.<DOMAIN.TLD>

(where any mail server which it should belong should have an entry. I'am not quite shure wethere we need mx: my.<DOMAIN.TLD> as well, but for the tests the above has been sufficient.)

4. set up following DNS records

_mta-sts in TXT v=STSv1; id=20221123132400Z

(where the id is a simple Timestamp or a uniq number to identify the entry)

_smtp._tls in TXT v=TLSRPTv1; rua=mailto:<USERNAME>@<DOMAIN.TLD> 

(where the rua-Mail-Adress is an Address one want's to get the reports)

EDIT:
We can easily check if the setup is correct via check tls.

I'm in a struggle to make cloudron.mail even more secure and tried to set up DANE. I don't know whether this is Hosting-Provider specific (currently on Netcup). So I do have difficulties to set up a valid TLSA.

steps to reproduce:

1. Download public key via browser (store it as .pm)
2. Generate TLSA entry for let's say port 25 via ssl-tools with

• Usage: DANE-EE
• Selector: Use subject public key
• Matching Type: SHA-256 Hash
• Certificate: Content of .pem file
• Port: 25
• Protocol: tcp
• Domain: mail.<DOMAIN.TLD>

3. setup entries at netcup with the following entries

_25._tcp.mail    in  TLSA    3 1 1 <FINGERPRINT>

If I check the entries via internet.nl I'm able to get one check for DANE Existance...but it seems to be not valid...

But it seems to be even more difficult to setup DANE with the short living Let's encrypt certificates. According to internet.nl we have to republish the entry every time the certificate is renewed and the cloudron generated certificate seems to have no trust anchor TA. So we are not able to use the TA certificate in the "DANE Rollover sceme" (Current + Issuer CA "3 1 1" + "2 1 1") as second TLSA entry...

Maybe @girish or anybody else has experience in pinning the let's encrypt certificate of cloudron with a sufficient workaround?

I would realy love to see this happening as HPB is a gamechanger for bigger nextclouds. @doodlemania2 do you think that looking into https://github.com/deeztek/deeztek-docker/tree/master/Linux/nextcloud-spreed-signaling might help you with your packageing?

I'am doing this first time, so foregive me mistakes I do. I went into the folder structure of the collabara_code install. To me it' obviously picking up fonts at both locations:

• at /opt/collaboraoffice/share/fonts/truetype and
• at /usr/share/fonts/

as it is disirable for some users to get rid of the preinstalled fonts we need to:

RUN mv /opt/collaboraoffice/share/fonts/ /app/data/fonts/ && ln -s /app/data/fonts /opt/collaboraoffice/share/fonts/

right after...

ARG CODE_BRAND_VERSION=21.11-17

in the dockerfile. So users can adjust the fonts to their needs...

I would absolutly love to see penpot here. It's going to be the perfect figma alternative.
+1

Update:

Steps to reproduce:

1. go to cloudron app store install peertube
2. wait untill peertube reaches state running.
3. stop peertube
4. go to section repair in cloudron peertube app
5. select "restart app" and restart app.
6. try visit your youtube instance

After step 5. redis is stopped as well (without manual restart ist produces a ton of errors like:

2022-08-20T04:53:25.000Z [...:443] 2022-08-20 04:53:25.979 info: Connecting to redis...
2022-08-20T04:53:26.000Z [...:443] 2022-08-20 04:53:26.007 error: Error in job queue activitypub-http-fetcher. {
2022-08-20T04:53:26.000Z "err": {
2022-08-20T04:53:26.000Z "stack": "Error: getaddrinfo ENOTFOUND redis-876aae5e-572c-45d1-b48e-5176ba2e62fe\n    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:71:26)",
2022-08-20T04:53:26.000Z "message": "getaddrinfo ENOTFOUND redis-876aae5e-572c-45d1-b48e-5176ba2e62fe",
2022-08-20T04:53:26.000Z "errno": -3008,
2022-08-20T04:53:26.000Z "code": "ENOTFOUND",
2022-08-20T04:53:26.000Z "syscall": "getaddrinfo",
2022-08-20T04:53:26.000Z "hostname": "redis-876aae5e-572c-45d1-b48e-5176ba2e62fe"
2022-08-20T04:53:26.000Z }

and after step 6 one will see the following message:

You are seeing this page because the DNS record of ... is set to this server's IP but Cloudron has no app configured for this domain.

the message persists even after manually turning redis on and repeat steps 3. to 6.

I'm in a struggle to make cloudron.mail even more secure and tried to set up DANE. I don't know whether this is Hosting-Provider specific (currently on Netcup). So I do have difficulties to set up a valid TLSA.

steps to reproduce:

1. Download public key via browser (store it as .pm)
2. Generate TLSA entry for let's say port 25 via ssl-tools with

• Usage: DANE-EE
• Selector: Use subject public key
• Matching Type: SHA-256 Hash
• Certificate: Content of .pem file
• Port: 25
• Protocol: tcp
• Domain: mail.<DOMAIN.TLD>

3. setup entries at netcup with the following entries

_25._tcp.mail    in  TLSA    3 1 1 <FINGERPRINT>

If I check the entries via internet.nl I'm able to get one check for DANE Existance...but it seems to be not valid...

But it seems to be even more difficult to setup DANE with the short living Let's encrypt certificates. According to internet.nl we have to republish the entry every time the certificate is renewed and the cloudron generated certificate seems to have no trust anchor TA. So we are not able to use the TA certificate in the "DANE Rollover sceme" (Current + Issuer CA "3 1 1" + "2 1 1") as second TLSA entry...

Maybe @girish or anybody else has experience in pinning the let's encrypt certificate of cloudron with a sufficient workaround?

Recently I played arround, to improve e-mail security with MTA-STS. I was able to simply use surfer app to publish the mta-sts.txt file and set up the necessary DNS entries. But the solution is somewhat clunky, so may be it might be an easy win @girish , to make this directly possible through cloudron ui, until we implement DANE into cloudron.

Steps to reproduce working MTA-STS setup in cloudron useing surfer app

1. setup surfer app at the following subdomain mta-sts.<DOMAIN.TLD>

2. make folder .well-known inside folder public

3. create mta-sts.txt

version: STSv1
mode: enforce
max_age: 86400
mx: mail.<DOMAIN.TLD>

(where any mail server which it should belong should have an entry. I'am not quite shure wethere we need mx: my.<DOMAIN.TLD> as well, but for the tests the above has been sufficient.)

4. set up following DNS records

_mta-sts in TXT v=STSv1; id=20221123132400Z

(where the id is a simple Timestamp or a uniq number to identify the entry)

_smtp._tls in TXT v=TLSRPTv1; rua=mailto:<USERNAME>@<DOMAIN.TLD> 

(where the rua-Mail-Adress is an Address one want's to get the reports)

EDIT:
We can easily check if the setup is correct via check tls.

Update:

Steps to reproduce:

1. go to cloudron app store install peertube
2. wait untill peertube reaches state running.
3. stop peertube
4. go to section repair in cloudron peertube app
5. select "restart app" and restart app.
6. try visit your youtube instance

After step 5. redis is stopped as well (without manual restart ist produces a ton of errors like:

2022-08-20T04:53:25.000Z [...:443] 2022-08-20 04:53:25.979 info: Connecting to redis...
2022-08-20T04:53:26.000Z [...:443] 2022-08-20 04:53:26.007 error: Error in job queue activitypub-http-fetcher. {
2022-08-20T04:53:26.000Z "err": {
2022-08-20T04:53:26.000Z "stack": "Error: getaddrinfo ENOTFOUND redis-876aae5e-572c-45d1-b48e-5176ba2e62fe\n    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:71:26)",
2022-08-20T04:53:26.000Z "message": "getaddrinfo ENOTFOUND redis-876aae5e-572c-45d1-b48e-5176ba2e62fe",
2022-08-20T04:53:26.000Z "errno": -3008,
2022-08-20T04:53:26.000Z "code": "ENOTFOUND",
2022-08-20T04:53:26.000Z "syscall": "getaddrinfo",
2022-08-20T04:53:26.000Z "hostname": "redis-876aae5e-572c-45d1-b48e-5176ba2e62fe"
2022-08-20T04:53:26.000Z }

and after step 6 one will see the following message:

You are seeing this page because the DNS record of ... is set to this server's IP but Cloudron has no app configured for this domain.

the message persists even after manually turning redis on and repeat steps 3. to 6.

@nebulon I see there is always a lot to do, so maybe it's an idea to mention it again. Do you think we might have a chance to add fonts like that…?

RUN ln -s /app/data/fonts /opt/collaboraoffice/share/fonts/truetype/local

After a bug in my peertube-instance I stopped the App and tried to restart the app via repair menu section (PeerTube 4.2.2, v7.2.5 (Ubuntu 20.04.3 LTS)). The app stop stopped the redis as well, therefore the restart of the app failed (after manually restarting redis) the app is no more “found” by my cloudron instance even though it is successfully running:

"You are seeing this page because the DNS record of ... is set to this server's IP but Cloudron has no app configured for this domain."

After complete uninstalling and reinstalling the app under the same subdomain the error persists. How am I able to "cleanup" the subdomains at least...?

After the app stop i found the following in the logs:

 npm ERR! path /app/code/server
Aug 19 18:54:24 npm ERR! command failed
Aug 19 18:54:24 npm ERR! signal SIGTERM
Aug 19 18:54:24 npm ERR! command sh -c node dist/server
Aug 19 18:54:24
Aug 19 18:53:25 Starting supervisor
Aug 19 18:53:26 2022-08-19 16:53:26,108 CRIT Supervisor is running as root. Privileges were not dropped because no user is specified in the config file. If you intend to run as root, you can set user=root in the config file to avoid this message.
Aug 19 18:53:26 2022-08-19 16:53:26,108 INFO Included extra file "/etc/supervisor/conf.d/redis-service.conf" during parsing
Aug 19 18:53:26 2022-08-19 16:53:26,108 INFO Included extra file "/etc/supervisor/conf.d/redis.conf" during parsing
Aug 19 18:53:26 2022-08-19 16:53:26,113 INFO RPC interface 'supervisor' initialized
Aug 19 18:53:26 2022-08-19 16:53:26,113 CRIT Server 'inet_http_server' running without any HTTP authentication checking
Aug 19 18:53:26 2022-08-19 16:53:26,113 INFO RPC interface 'supervisor' initialized
Aug 19 18:53:26 2022-08-19 16:53:26,113 CRIT Server 'unix_http_server' running without any HTTP authentication checking
Aug 19 18:53:26 2022-08-19 16:53:26,113 INFO supervisord started with pid 1
Aug 19 18:53:27 2022-08-19 16:53:27,117 INFO spawned: 'redis' with pid 13
Aug 19 18:53:27 2022-08-19 16:53:27,120 INFO spawned: 'redis-service' with pid 14
Aug 19 18:53:27 13:C 19 Aug 2022 16:53:27.124 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
Aug 19 18:53:27 13:C 19 Aug 2022 16:53:27.124 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=13, just started
Aug 19 18:53:27 13:C 19 Aug 2022 16:53:27.124 # Configuration loaded
Aug 19 18:53:27 13:M 19 Aug 2022 16:53:27.125 * Running mode=standalone, port=6379.
Aug 19 18:53:27 13:M 19 Aug 2022 16:53:27.125 # Server initialized
Aug 19 18:53:27 13:M 19 Aug 2022 16:53:27.125 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
Aug 19 18:53:27 13:M 19 Aug 2022 16:53:27.125 * Ready to accept connections
Aug 19 18:53:27 Redis service endpoint listening on http://:::3000
Aug 19 18:53:28 2022-08-19 16:53:28,255 INFO success: redis entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
Aug 19 18:53:28 2022-08-19 16:53:28,255 INFO success: redis-service entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
Aug 19 18:53:40 [GET] /healthcheck
Aug 19 18:54:25 2022-08-19 16:54:25,223 WARN received SIGTERM indicating exit request
Aug 19 18:54:25 2022-08-19 16:54:25,224 INFO waiting for redis, redis-service to die
Aug 19 18:54:25 2022-08-19 16:54:25,226 INFO stopped: redis-service (terminated by SIGTERM)
Aug 19 18:54:25 13:signal-handler (1660928065) Received SIGTERM scheduling shutdown...
Aug 19 18:54:25 13:M 19 Aug 2022 16:54:25.314 # User requested shutdown...
Aug 19 18:54:25 13:M 19 Aug 2022 16:54:25.314 * Saving the final RDB snapshot before exiting.
Aug 19 18:54:25 13:M 19 Aug 2022 16:54:25.316 * DB saved on disk
Aug 19 18:54:25 13:M 19 Aug 2022 16:54:25.316 * Removing the pid file.
Aug 19 18:54:25 13:M 19 Aug 2022 16:54:25.316 # Redis is now ready to exit, bye bye...
Aug 19 18:54:25 2022-08-19 16:54:25,317 INFO stopped: redis (exit status 0)

As you can see, the redis seems to abnormally stops after the npm SIGTERM (or does this work as designed?)…the restart seems to be not successful in restarting the redis service after that...

@nebulon Another try hopefully less hackish... According to the solution of rLoutrel found here ... maybe it is sufficient to simply:

RUN ln -s /app/data/fonts /opt/collaboraoffice/share/fonts/truetype/local

This one won't add /usr/share/fonts/ as extra volume to collabora and we won' have the ability to get rid of the intially installed fonts but should make it at least possible to add custom fonts via /app/data/fonts. So this might be a solution to the initial Question of SirFiChi...

@nebulon no this is prevented by the --existing flag...that's the reason why I initially suggest to move the whole thing and afterwords only update the (still) existing... to get a whole copy of the primary folder one has to delete the font folder in app/data... then there will be again the full copy/move...

I played around and maybe this is a solution to @nebulon at least for the "merge"-situation with new upstream font releases...so what about:

RUN if [ -d /app/data/fonts/ ]; then \
      rsync -a --update --existing /opt/collaboraoffice/share/fonts/ /app/data/fonts/  \
      && rm -r /opt/collaboraoffice/share/fonts/ \
    else \
      mv /opt/collaboraoffice/share/fonts/ /app/data/fonts/ \
    fi \
    && ln -s /app/data/fonts /opt/collaboraoffice/share/fonts/

With that it checks initaly wether /app/data/fonts/ exists (if not simply moves and symlinks back) and if folder already exits updates only the files that are newer and persists the deletion of font files in /app/data/fonts/ and keep changes of files from upstream (until they are deleted)...

I would realy love to see this happening as HPB is a gamechanger for bigger nextclouds. @doodlemania2 do you think that looking into https://github.com/deeztek/deeztek-docker/tree/master/Linux/nextcloud-spreed-signaling might help you with your packageing?

@nebulon That's definitly true...so my second best guess would be to:

RUN mv /usr/share/fonts/ /app/data/fonts/ && ln -s /app/data/fonts /usr/share/fonts/

As it seems that coolwsd is looking up there and at

etc/fonts

as well according to my understanding of https://github.com/pree/collabora-online/blob/master/coolwsd-systemplate-setup

isn't it that what usr fonts are meant to be? And we won't interfere with the collabra ones. Of course the user added fonts would be part of backup, but this shouldn't be that much of a deal (in my opinion)... But with that approach we can't get rid of the initally installed noto fonts for instance...

Edit: I see that that is exactly what murgero wrote at the very beginning so +1 for @murgero