@privsec I moved your thread here.

While this has STILL not been addressed by docker upstream, there is a proposed solution that works:
https://hub.docker.com/r/willfarrell/autoheal

Alternatively a simple cron script checking for unhealthy containers to restart them.

@staff what do you think?

@marcusquinn I had used that before but unfortunately didn’t seem to work for my Office365 migration, which I was surprised to see. Kept throwing me a generic error when I tried. It’s definitely a helpful tool otherwise though! 🙂

@skmgo Haraka feature requests have to go upstream - https://github.com/haraka/Haraka . This is a feature request for Cloudron (which uses Haraka internally).

This is in 7.4

@girish :dance-party:

Thank you.

@potemkin_ai agreed, that would make it all super simple to setup, without having to add anything special on cloudron side, perhaps different webhooks for different alerts and then leave to N8N/ntfy node the definition of how it has to be processed.

@mehdi my thoughts / use case exactly.

Doing so with ipchains is a pain (thanks Docker's intervention to firewall); and ufw just doesn't handle all of the use cases (thanks Docker again).

https://github.com/TheWorms/nodebb-plugin-embed doesn't work. I haven't found a working plugin for this.

@jdaviescoates I have apps restricted by groups, absolutely. I would just like to have responsive functionality for app labels such as Website-Cust. Name

@girish Thanks for looking into it and I tried again with the Amazon S3 backup option in my server, and it started working for me as well (after you said that you enabled it within your AWS Account.

I think that might have been the main issue as the error message called out that it couldn't object cloudron-testfile (which it might do through the Cloudron AWS Account if it exists*), so if the region wasn't enabled within that account, it wouldn't be able find the correct endpoint to use for that test file and hence wouldn't know where the correct endpoint is.

I say that with the typo that you identified in the backup config code and enabling the AWS Melbourne region within your AWS account, that managed to get it working. In any ways, thanks for looking into this and getting it working for me 🙂

@jayonrails Cool. I recommend sticking to Tarball. Faster and takes up less space overall.

@rossmaclean ah right for this the build service app works well, after setup you can just run cloudron build in the package repo without having to commit/push in the repo. If you have it installed on the same server as you are testing the app, then this has the benefit that the image is already there and thus speeding up the process.

@gobenizzle unfortunately, no. I was just re-reading this thread. What is your use case for this (sorry, if I missed this).

@tamayers you said use case is "A reason for this (such as my use case) is that you might have inboxes for employees using Google Workplace, Microsoft Exchange, or Cloudron email for user account and then support inboxes for customer inquires or sales that you do not want handled on the same system." I am not sure why this is done, is this to save money because exchange/workspace charges per mailbox?

@jdaviescoates said in Force logout after browser close and/or certain duration:

I guess is this is a real security concern for you, you could manually logout beforehand?

True.

My main reason for requesting this feature is that the administrative controls are only a few clicks away. I suppose I could create a separate non-admin user account for myself and run my apps under that account.

@privsec Thank you! I had overlapped these but have now fixed it, great catch!

@girish I have figured out a solution that doesn’t require admin permissions to ERPNext. It’s just that they use MariaDB specific commands here and there. That’s why MySQL addon is not useful at all.

Multiple databases works kinda fine but needs patching the source because ERPNext likes to use the same value for db-user and db-name; in fact there’s no way to give it the db-user. The name of the database is itself is considered username.

While building this addon, I would recommend setting the user’s name and database the same - ie. without prepending the same string with ‘db’ or ‘user’

Multiple databases isn’t required as ERPNext doesn’t work really well as a multi-site ERP anyway.