Currently if you want to automatically import bank transactions into Cloudron hosted Firefly III you need to run and manage an instance of Spectre importer.

There is a docker image for this application maintained by the application's developers which will hopefully make integrating this easier.

Having the ability to host Spectre importer and Firefly III self hosted on Cloudron would allow it to work as a replacement to services like Mint.

I have opened up a request to get Spectre importer added as an app, please up vote if your still interested in that feature.

I need to run a copy of some database engine where I can create custom tables, access the data from multiple tools like Excel, n8n, NocoDB, and Redash.

I would prefer Postgresql but MySQL would probably work fine for me as well.

In the past I would have run a Microsoft SQL Express instance but most everything else we use has now been standardized on Cloudron and I would rather use that platform instead of having to setup a separate self maintained system.

Cloudron hosts both of these databases along with MongoDB already internally accessible to specific apps that would like to use them but I would like to consume them as first class apps themselves that are not related to any other app or container running on cloudron.

I have a feeling I could probably make a very simple cloudron app that simply proxies the connection to the database exposed to that app but it would be really nice to have this as a directly supported scenario when, as in this case, the app I really want to use is the database itself.

I just watched the BayLISA presentation on Cloudron and saw it mentioned that they do Selenium tests of the applications on each release so I have updated my original post to include a link to Camunda's own maintained selenium based web application tests.

This may be something that I just need to learn better but I tried to manually update apps over the last few days by clicking the update button for the individual app tiles and each time it would start and then look like it finished but no update took place.

I eventually figured out today that this was due to the mount point where backups are sent not being available and after fixing that updates complete as expected but before this point they were failing silently when manually triggered.

I am not sure where I would look to see the reasons the update failed as the app's logs don't show anything and the Cloudron event log shows the update being triggered but doesn't show anything indicating that the update failed and subsequently why it failed.

Relevant links:

• Download page which includes docker image instructions
• Docker hub image maintained by Camunda
• Relevant documentation on configuring LDAP authentication for integrated user management
  • The LDAP Identity and Administrator Authorization plugins are already included in the Docker image
• Administrator Authorization plugin which would be used to make Cloudron Admin's Camunda admins
• Process engine configuration needed for the Comunda process engine to use the Cloudron email relay
  • Email configuration is also mentioned here but it is in the context of new user email notifications which wouldn't be relevant if identity management is handled by Cloudron
• No state information for Camunda is in containers
• Docker container has runtime parameters to configure either MySQL or PostgreSQL database connection information
  • Documentation on other database parameters that can be passed to the container and example configuration using PostgreSQL
• Selenium based tests for the various applications in the distribution

I have saved and then followed these steps for installing a certificate once it has been sent to a iOS 13.7 iPhone (in my case I used iCloud storage and the Files app to get the certificate onto the device.

After these steps have been completed you should be able enable trust for this certificate like this.

I have also used the iMazing profile editor to create a profile with the auto generated self signed wildcard certificate in case that made a difference.

In all cases the certificate doesn't show up under the "Enable full trust for root certificates" heading on the Settings > General > About > Certificate Trust Settings screen.

Apple published new requirements for certificates that can be trusted in iOS 13 and above.

All of the first set of requirements appear to be met but the last section's bullets appear to be where the problems are:

Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:

• TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.
• TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

At present it appears that it is not possible for an updated iOS device to trust the automatically generated self signed certificate created by Cloudron.

This blog article provides steps that work, part of the issue being the requirement to have a separate CA cert that is then used to generate the TLS Web Server Authentication cert that ultimately is used for the tls connections.

Beyond that it also appears that the 10 year life time on the certificate would have to be reduced to 825 days or less (~2.26 years).

The Custom Certificate's documentation mentions that

Intermediate Certs - You can upload a certificate chain by simply appending all the intermediate certs in the same cert file.

In my scenario I use a wild card certificate that was issued using our own root ca.

Appending its public key to the certificate chain works fine to allow me to use the wild card certificate in cloudron but there isn't a process in place to expose the public key of the custom root ca to each of the containers.

It would be really helpful if all the public keys contained in whatever custom certificate file is uploaded using the Custom Certificate feature were automatically added/linked/exposed in the right spot in each container so that those containers would automatically trust the wild card cert and anything else from the root ca that issued it.

Something like adding the following to the docker file:

ADD your_ca_root.crt /usr/local/share/ca-certificates/foo.crt
RUN chmod 644 /usr/local/share/ca-certificates/foo.crt && update-ca-certificates

Source

Currently I have to be aware of this whenever adding new apps as I may hit broken functionality and ambigous errors that in the end track back to this issue and require their own app specific work around.

Here are some examples:

• Redash
  • cloudron env set --app redash.cloudron.domain.com REDASH_ENFORCE_PRIVATE_IP_BLOCK=false
  • Add a file named cloudronwildcard.pem that contains the public key for the wildcard certificate to the /app/data directory
  • cloudron env set --app redash.cloudron.domain.com REQUESTS_CA_BUNDLE=/app/data/cloudronwildcard.pem
• N8N
  • cloudron env set --app n8n.cloudron.domain.com NODE_TLS_REJECT_UNAUTHORIZED=0
• Onlyoffice
  • services.CoAuthoring.requestDefaults.rejectUnauthorized=false in /etc/onlyoffice/documentserver/defaults.json Source

For these examples I believe if each of these containers was configured to trust all the public keys that were loaded when the custom certificate file was uploaded then N8N and Onlyoffice would work without anything extra, Redash may still require REDASH_ENFORCE_PRIVATE_IP_BLOCK=false but the other steps wouldn't be needed.

@girish Sorry for the late reply, I the default forum settings were to send me email notifications once a week, I have changed that to daily.

I was trying to use the self-signed certificate for all apps.

I have gone ahead and followed the steps in the blog article I linked to and was able to upload the full CA and web server cert chain to Cloudron and after getting the root certificate authority into all the devices accessing Cloudron everything is working well from Windows and iOS based devices.

It looks like Apple is going to be decreasing the certificate lifetime further down to 398 days so you may want to lower the lifetime down to a year to get ahead of that change.

@girish Definitely think the first option is the way to go, can have different versions, plugins, etc. and not have any negative impact on addons infrastructure which works great and I would hate to make that harder to maintain.

@girish Definitely think the first option is the way to go, can have different versions, plugins, etc. and not have any negative impact on addons infrastructure which works great and I would hate to make that harder to maintain.

@ChristopherMag PS, this would be perfectly fine/better if the "app" version had nothing to do with the version used behind the scenes for apps.

I would prefer that they really have nothing to do with each other and so that the app version could auto upgrade with new versions of the database being released just like any other app and such.

I need to run a copy of some database engine where I can create custom tables, access the data from multiple tools like Excel, n8n, NocoDB, and Redash.

I would prefer Postgresql but MySQL would probably work fine for me as well.

In the past I would have run a Microsoft SQL Express instance but most everything else we use has now been standardized on Cloudron and I would rather use that platform instead of having to setup a separate self maintained system.

Cloudron hosts both of these databases along with MongoDB already internally accessible to specific apps that would like to use them but I would like to consume them as first class apps themselves that are not related to any other app or container running on cloudron.

I have a feeling I could probably make a very simple cloudron app that simply proxies the connection to the database exposed to that app but it would be really nice to have this as a directly supported scenario when, as in this case, the app I really want to use is the database itself.

The Custom Certificate's documentation mentions that

Intermediate Certs - You can upload a certificate chain by simply appending all the intermediate certs in the same cert file.

In my scenario I use a wild card certificate that was issued using our own root ca.

Appending its public key to the certificate chain works fine to allow me to use the wild card certificate in cloudron but there isn't a process in place to expose the public key of the custom root ca to each of the containers.

It would be really helpful if all the public keys contained in whatever custom certificate file is uploaded using the Custom Certificate feature were automatically added/linked/exposed in the right spot in each container so that those containers would automatically trust the wild card cert and anything else from the root ca that issued it.

Something like adding the following to the docker file:

ADD your_ca_root.crt /usr/local/share/ca-certificates/foo.crt
RUN chmod 644 /usr/local/share/ca-certificates/foo.crt && update-ca-certificates

Source

Currently I have to be aware of this whenever adding new apps as I may hit broken functionality and ambigous errors that in the end track back to this issue and require their own app specific work around.

Here are some examples:

• Redash
  • cloudron env set --app redash.cloudron.domain.com REDASH_ENFORCE_PRIVATE_IP_BLOCK=false
  • Add a file named cloudronwildcard.pem that contains the public key for the wildcard certificate to the /app/data directory
  • cloudron env set --app redash.cloudron.domain.com REQUESTS_CA_BUNDLE=/app/data/cloudronwildcard.pem
• N8N
  • cloudron env set --app n8n.cloudron.domain.com NODE_TLS_REJECT_UNAUTHORIZED=0
• Onlyoffice
  • services.CoAuthoring.requestDefaults.rejectUnauthorized=false in /etc/onlyoffice/documentserver/defaults.json Source

For these examples I believe if each of these containers was configured to trust all the public keys that were loaded when the custom certificate file was uploaded then N8N and Onlyoffice would work without anything extra, Redash may still require REDASH_ENFORCE_PRIVATE_IP_BLOCK=false but the other steps wouldn't be needed.

@girish I have updated and been using everything for the last two days and it has been working as expected. Good to go from me, thank you!

@girish It doesn't look like Redash has been updated yet, just making sure this didn't fall of the list of things to do as I know it came in over the holidays.

@girish When I try to create an instance of Redash on that demo cloudron instance it gets stuck in a starting state and never progresses past that and I can see in the log that the workers keep restarting:

Not sure this is related to the problem at hand as I don't have this issue when install Redash on my own instance of cloudron.

@girish Package version shows 4.0.0:

I also see successful jobs count on that screen but those do not appear to be the queued jobs as we can also see that the queued jobs count only increases, started jobs never increases:

To reproduce this you can submit any query to any data source and confirm that it never completes.

Below is an example of submitting select "test" as the query to a CSV data source which may not even be valid but if it is not at least it should error instead of remaining indefinitely queued:

I have also tried this with a SQLite data source and get the same results, for each query I submit the queued count increases and the screen where the query was submitted just keeps counting up.

@girish I uninstalled and reinstalled, I made sure when I was installing it from the app store it said last updated 15 hours ago so I believe it pulled the updated version.

Unfortunately, same problem, queries get queued but never dequeued and run.

After installing redash, configuring a datasource, and submitting a query to be run, it remains in queue and is never executed by a worker.

I have uninstalled and reinstalled redash and reconfigured the data sources and such as I thought maybe I did something wrong to mess it up the first time but both times I get the same result, queries sit queued but never execute.

All the processes for the workers appear to be running: