C
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 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.
We have a number of cards in Wekan that represent templates for various business processes we have.
These templates encompass all the edge cases we need to consider, the information we need to gather, and are continuously improved as we have issues that come up where we could have avoided the issue by addressing something earlier in a templated process.
Today I was told one of these templates with dozen's of checklists and 165 checklist items was missing.
It appears that someone instead of making a copy of the template they accidentally moved the template and used it, deleting the unneeded checklists.
This appears to have happened over a month ago as we just happened to go through a period where we hadn't be doing this activity and our backups do not go back that far.
We backup everything locally and then sync that directory to the cloud and have limited storage available in the cloud even though locally we have more than enough space (looking forward to the multiple backup location feature so we can have more backups retained locally with only a subset in the cloud).
I was able to find an old backup that was not visible in cloudron that contained a backup of wekan from 3 months ago.
The backup was from a previous cloudron server that I had migrated from and was encrypted.
The app version has changed significantly since then and I believe we have done at least one cloudron update since then on the new server.
I was able to clone the app and then go through the import backup process on the cloned app and was shocked that after giving it the path and encryption password everything just worked.
It downloaded an old container image for the pervious version of the app, restored the data, and gave me access so that I could recreate the template that had been lost.
I wanted to share the praise here for cloudron as I fully expected that at best I would need to manually decrypt the file, find the mongodb backup, restore it to another mongodb instance, and then start rummaging through the data in the database to recreate what we needed but cloudron restored the app perfectly from an encrypted backup, from a separate server, and 3 month old app version.
Maybe I have low expectations but this kind of seamless restore feature of platforms always seems to fail for one reason or another and then maybe work after lots of troubleshooting and work arounds but this just worked as expected with no fuss.
10/10, thank you so much for this working so well.
For anyone wanting to get this up and running quickly if you have docker running on another system you can run the following:
docker run -d --restart unless-stopped -p 3000:3000 gotenberg/gotenberg
docker run -d --restart unless-stopped -p 9998:9998 apache/tika
And then add the following to your paperless.conf:
# Tika
PAPERLESS_TIKA_ENABLED=true
PAPERLESS_TIKA_ENDPOINT=http://<DockerHostnameOrIPGoesHere>:9998
PAPERLESS_TIKA_GOTENBERG_ENDPOINT=http://<DockerHostnameOrIPGoesHere>:3000
After this you can upload xlsx, docx, etc. to paperless-ngx.
In my testing if the Docker host running the Tika and Gotenberg containers goes down paperless-ngx keeps working fine but you won't be able to upload additional xlsx/docx/etc. documents until you restart the containers which works out fine as the reliability of paperless-ngx being accessible is way more important than this one feature working for us.
I have opened up a request to get Spectre importer added as an app, please up vote if your still interested in that feature.
Fyi, what I have ended up doing is creating a custom cloudron app with the postgresql feature and then hosting a nodejs app that communicates directly with the database to alleviate the need for generic direct access to postgresql.
@Lanhild If you want direct access to a postgresql database for testing and DB analysis stuff then you can use a custom app with the postgresql feature enabled and girish's post here to connect pgadmin to that custom app's postgresql instance.
This is something I need as well, working on rolling out PaperlessNGX to replace an existing storage system and need to be able to store office documents as well so that all documents related to an entity are together.
It looks like Tika and Gotenberg both have docker containers available.
Do we need to have separate Tika and Gotenberg apps like we have OnlyOffice and Collabra Online as a separate apps though they are not usable on their own and are used by NextCloud for handling office documents?
The fix is to change REPO_INDEXER_PATH = indexers/repos.bleve to REPO_INDEXER_PATH = /app/data/appdata/indexers/repos.bleve.
Please go ahead and mark this as solved but I wanted to still post it in case it is useful for someone else.
Describing the problem led to the obvious solution :-).
For anyone else coming later, if you need to modify these files to test out for instance a code fix you would use the CLI tool to run cloudron debug --app app.domain.com, open a web terminal to the app, edit whatever files you need to in /app/code, and then run /app/pkg/start.sh from within that web terminal to manually start the app and test your change.
You can exit debug mode, which will delete your changes, by going to the app's settings in cloudron, Repair, and clicking the Disable Recovery Mode button.
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.
In case any one else is looking through this thread later, the best path forward in our case was to start using DigitalOcean's free DNS service and then change the domain configuration in cloudron from manual to DigitalOcean.
Our cloudron apps are hosted under a subdomain of the top level domain so we needed to setup both the top level domain and the subdomain in digital ocean with name server records for the subdomain defined at the top level domain. We also needed to change our domain registrar's setup so that they would point to DigitalOcean's name servers as authoritative for the domain.
All of this worked and has resulted in us being able to have a cloudron instance that is not reachable from the public internet in any way but is still able to use Let's Encrypt certificates for everything via cloudron's automatic certificate management.
If you go down this path please be sure to get things setup, change the domains configuration, sync dns, renew certificates, and reboot the cloudron server and if things are configured properly you should be able to see that the certificates being used switch from your manually loaded certificate to the Let's Encrypt certificate.
Ultimately this results in https connections between apps, like nextcloud and onlyoffice, working by default without work around needed to bypass certificate verification.
PS, anyone needing to do this, open the cloudron terminal for the app and then run the following:
cd src
python3 manage.py document_retagger -T
@girish I thought that you could run the command without first cd'ing into the src directory but when running it again today I found out that was incorrect.
I have edited my post above to first include cd src and then python3 manage.py document_retagger -T.
Could you please update the documentation as what I originally posted doesn't work for some reason, python throws an exception if you don't cd first?
@timconsidine It looks like Apache Tika supports the document formats from the iWork suite like pages.
I tried to upload a .pages file to paperless-ngx with Tika and gotenberg configured and paperless popped up a failure message with the the error File type application/zip not supported.
I believe this signals.py file in the paperless-ngx project would need to add support for the various iWork software suite formats to resolve this error and get this working assuming you already have Tika and gotenberg setup and working with paperless-ngx.
You could probably open a github issue in the paperless-ngx repository on Github and see if they can assist with adding support fort his.
I am in an environment where based on our compliance requirements I cannot publish images to docker hub.
I have the Cloudron Build Service and Docker Registry apps installed on my cloudron instance.
I am trying to follow this tutorial to build a node js app.
I have cloned the sample app but when I look at the Build steps if I follow the steps I believe it would push the image to docker's public registry.
It seemed like possibly using the cloudron build service would address this so I installed that app and walked through the article on the app but it is not clear how to configure this to use the private registry hosted on cloudron.
I have updated the docker.json file to be:
{
"cloudronbuildservice.cloudron.ourdomain.com: {
"username": "email@address.com",
"password": 'passwordthatcontians"character'
}
}
I have also tried cloudron build --set-repository https://dockerregistry.cloudron.ourdoma8in.com/ourappname and I get the following error:
Using build service https://cloudronbuildservice.cloudron.ourdomain.com/
Building https://dockerregistry.cloudron.ourdomain.com/magnusonfinancialwebservices:20230914-165206-408b2a393
Uploading source tarball...
Failed to build app (statusCode 404):
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Cannot POST //api/v1/builds</pre>
</body>
</html>
This seems to be looking at the repository as the source for the code to build and not as the destination for what is built so I think I must not be understanding how this is supposed to work.
Trying to do a build without using the cloudron build service I looked at @timconsidine 's example here and it seems like I should be to run the following from the directory where the code from the nodejs sample app was cloned, docker build -t https://dockerregistry.cloudron.ourdomain.com/ourappname:v1 .
This results in the error:
[+] Building 0.0s (0/0) docker:default
ERROR: invalid tag "https://dockerregistry.cloudron.ourdomain.com/ourappname:v1": invalid reference format
The source code for this app will be hosted in gitea also on our cloudron instance and my intent is to have a workflow that takes the dockerfile from the gitea repo, uses the cloudron build service to build the app, publishes it to the docker repository hosted on cloudron, and then I can us the cloudron cli tool to install it on the cloudron server.
I am happy to work up to this in stages but I seem to be missing something about how even the basics of the process should work using docker to build it locally if I don't want to user dockerhub.
What can I do to build the sample app without using dockerhub?
Thanks for your help,
Chris
Relevant links:
We have begun to use paperless-ngx and one of the most compatible ways for various scanners to integrate with that software is for the folder that paperless-ngx watches (they call it the consume folder) to import documents from gets exposed as an SMB share and then whatever scanner or scanner software is pointed at that share when documents are scanned.
In our case we use cloudron so the instructions online about exposing the consume folder as an SMB share I believe are not something that can be done in cloudron.
It would be really helpful for this app to be able to expose a path as an SMB share (preferably SMBv3 or higher with user account credentials being pulled from Cloudron) so that we could integrate paperless-ngx with our scanners, in our case various models of Fujitsu ScanSnap.
Doing some more digging it looks like you can define the state an adapter is required to be in for the systemd-networkd-wait-online.service to proceed by configuring the appropriate .network file.
On my system if I run cat /run/systemd/network/10-netplan-enp2s0.network I can see the following:
[Link]
RequiredForOnline=no
Per this suggestion I have run sudo nano /etc/systemd/network/20-enp2s0.network with the contents:
[Match]
Name=enp2s0
[Link]
RequiredForOnline=routable
I have run sudo systemctl revert systemd-networkd-wait-online.service to undo the override to systemd-networkd-wait-online done earlier and rebooted.
After reboot the mount points are not mounted and running cat /run/systemd/network/10-netplan-enp2s0.network I can see that the link is still set not to be required for online:
[Link]
RequiredForOnline=no
I think this is probably the right track and I am just missing something simple, will keep trying to find a way to override RequiredForOnline for a specific network link and then I think everything will work as expected.
@subven I didn't realize I could set it to run updates multiple hours of the day, I have made that change so that it will update every hour during non working hours, this will definitely resolve the situation where a app hasn't been started in a long time and has a bunch of updates to catch up on.