Cloudron Forum

@jagadeesh-s2104 As far as I know these links are already a couple of clicks away at most in each app.

Have a look here:

Is this what you are looking for?

excellent - very much appreciated!

With default settings and current Cloudron app package, Koel does not scan periodically the media library for change.

Per Koel documentation, there are a few ways to do this manually via CLI and/or cron entries.
However Koel also provides a couple of options to do this automatically:

1. (Best) Watch the Media Directory
   This entails to include an additional linux package and the setup and the background run of a script
2. Command Scheduling
   Install (add to the cloudron package) and allow the Koel built-in scheduler to run.

Alternatively, it is still possible to add Cron commands to the Cloudron package, "manually" running specific Koel CLI commands. However, as mentioned in Koel's doc:

Though you can still manually set up cron jobs for individual commands, the scheduler is the recommended approach to do command scheduling in Koel, as it will automatically cover any commands that may be added in the future.

Maybe this could be considered to improve the Cloudron application package?

Meilisearch as an addon would make sense and I believe a fair number of already package cloudron apps could benefit from it, such as the following ones to start with:

• Linkwarden
• Freescout
• LibreChat
• Koel
• Ghost
• Wordpress
• Apache Answers
  Also OpenArchiver if it ever get packaged.

Would be great!

@james It is all working now. Many thanks!

@girish Thanks a lot - Much appreciated!

Ok - Here is the reply I got from deSEC:

This is caused by the fact that hundreds of clients send updates at xx:xx:x0 00:00. We only accept about 60 simultaneously processed updates, so most of them get this error.

To prevent this, we recommend randomizing the update time, or at least set it to some non-special time manually.

Looking more closely at the cloudron logs and despite the somewhat random nature of the change of public IP when not having a fixed IP address, it looks like Cloudron triggers DNS checks/update almost exclusively on xx:xx:x0

Could it be possible to randomize this further ?

@joseph Sure - Done here

Although I am struggling to find more information about what exactly happened with Booklore.
It seems that, at one point, the Github repo was pulled entirely, but it is now back online, with the latest commit and release just over 2 weeks ago at the time of writing.
So it still seems active, on the surface at least.

Grimmory - Self-Hosted Digital Library for eBooks, Comics & Audiobooks (Community Fork of Booklore)

• Main Page: https://grimmory.org
• Git: https://github.com/grimmory-tools/grimmory
• Licence: AGPL-3.0
• Dockerfile: Yes - Images on Docker Hub and GitHub Container Registry
• Docker-compose: Yes - Full setup with MariaDB via docker compose up -d; local at http://localhost:6060
• Demo: No public demo available

• Summary:
  • Self-hosted digital library and book manager (community fork of Booklore) supporting eBooks (EPUB, MOBI, AZW), PDFs, Comics (CBZ/CBR/CB7), and Audiobooks (M4B, MP3, OPUS)
  • Features Smart Shelves with rule-based filtering, built-in browser reader with annotations/highlights, metadata lookup (Google Books, Open Library, Amazon), and BookDrop for automated import
  • Multi-user support with local or OIDC authentication, device sync via Kobo/OPDS/KOReader, and one-click sharing to Kindle or email

• Notes:
  • This is a community fork of BookLore, which started after Booklore was pulled without notice.
  • Perfect for book lovers wanting a self-hosted Calibre-Web alternative with a modern UI, audiobook support, and seamless device sync
  • Requires MariaDB as a dependency (no SQLite option)

• Alternative to / Libhunt link: Booklore, https://selfhosted.libhunt.com/calibre-web-alternatives
• Screenshots:

Hi,

I have been testing this for the past few days and I think that I may have encountered a issue with the package config.

Consider this:

• Koel package setup on Cloudron Server with mounted volume storage
• Koel app > settings > media path pointing at the mounted volume

With the default configured streaming method (x-sendfile), no playback is possible (neither on the web nor on mobile app).

Could this be because the the Apache mod_xsendfile module XSendFilePath variable is not dynamically set and only points to "/app/data/library" (default config)?

Alternatively, is there a way to (persistently) configure/overwrite the Apache mod_xsendfile module conf file?

Thanks!

This seems to fix the issue indeed - At least from my side, there was a table collection charset mismatch.
The other question is how it came to be.

I have not had the chance/time to attempt to manually curl yet.

What is puzzling is there is no error when using the "sync DNS" function from Cloudron. AFAIK, this only happens with DynDNS update attempts.

Thanks @joseph.
This is weird because whatever the timing of the Cloudron Dyn DNS update, the pattern is always the same and only the dashboard (my.) record is failing. The other (app) domain record updates are successful and just fine.

is it because it is the first one in the list of the batch to be updated?
Is it because there is a en issue with the content of the record ("my")?

I have no idea.

I am attempting to contact deSEC to see if I can get more info from their end and will revert back/if when I do.

I can confirm I am seeing the same since yesterday and the package update from 1.24.4 to 1.25
The app then becomes "not Responding" with the error mentioned aboved by @d19dotca

Reverting to previous version restore functionalities/access indeed.

@james - I am afraid this is not solved at all from my side.

The server overloading from deSEC side is just a theory at this stage and without more tech info there is not much I feel I can do.

I see couple of non exclusive ways forward:

• inquire about this directly with deSEC, but it'll need some more tech info which I do not have or have access to as far as I know.
• implement helping measures on Cloudron as suggested by this deSEC thread - which, as far as I know, is something that only Cloudron can do.

Please would you consider this before marking the topic as solved?

At the moment, the issue happens every night and the pattern is clear:
It is failing on this single DNS record (because it is the firs one in the list?).
I find it rather odd that within the same seconds all other DNS records are updated just fine.

How often is the DynDNS check run?
What happen when an DNS update fails? is there a check and a alert/notification that can be triggered?
at what interval is this retried if at all?

Many questions still as you can see.

Many thanks again

@joseph Thanks for the pointers.
Upon further investigation on deSEC side, this might point to a temporary server overload with potential ways the help the issue.

How does the Dynamic DNS update work on Cloudron's side? What does the cron table entry look like for this?
(Is there a place where I should be looking for this info somewhere / additional tech info on cloudron's side?)

Also, do you think that some of these suggestions are implementable (if not already present)?

Many thanks again

@nebulon Thanks for this - I can confirm that this is an issue with the S3 endpoint and a faulty server app release not accepting upload and throwing HTTP/1.0 400 errors.

If I may: The error message about MD5/checksum from Cloudron throw me off for a bit, not directly pointing at a lack of communication with the remote server.

Reverting to an earlier release on the S3 endpoint fixed the issue.

Hi @joseph Thanks for this.
I can confirm that vector is now enabled.
Docmost is still complaining when I activate the option, but I see no "page_embeddings" tables at the moment so I will wait for a potential background creation and report.

Thanks again,

In passing, I noticed a few times in a recent past the cloudron demo server name and footer having been changed to some unpleasant (some might say offensive) wording.
Not sure how you want to approach this - just though I'd mention.

Hi @joseph - Thanks for this.

When I sync DNS via Cloudron dashboard, the logs indicate all updates are successful (no error).

How I know that the dashboard DNS record is not update:

• All other services are responding to DNS requests, only the dashboard is not
• I then check deSEC and note that all records have been updated but not the dashboard one.

There is no specific local DNS caching happening on site as far as I am aware.
Especially since it impacts only the "my." DNS record and not the others.

However, looking more closely to the historical logs (apologies for not finding this / adding this to the initial post), I noticed the following:

May 04 03:40:01 taskworker: Starting task 195. Logs are at /home/yellowtent/platformdata/logs/tasks/195.log
May 04 03:40:01 taskworker: Running task of type syncDyndns
May 04 03:40:01 tasks: updating task 195 with: {"percent":5,"message":"Updating dashboard location my.domain.name"}
May 04 03:40:01 dns: upsertDnsRecords: subdomain:my domain:domain.name type:A values:["aaa.bbb.ccc.ddd"]
May 04 03:40:02 dyndns: BoxError: deSEC DNS error [502] <html>

<head><title>502 Bad Gateway</title></head>

<body>

<center><h1>502 Bad Gateway</h1></center>

<hr><center>nginx</center>

</body>

</html>


    at del (file:///home/yellowtent/box/src/dns/desec.js:76:40)
    at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
    at async Object.upsert (file:///home/yellowtent/box/src/dns/desec.js:89:5)
    at async Object.upsertDnsRecords (file:///home/yellowtent/box/src/dns.js:146:5) {
  reason: 'External Error',
  details: {}
}
May 04 03:40:02 tasks: updating task 195 with: {"percent":15,"message":"Updating mail location my.domain.name"}
May 04 03:40:02 tasks: updating task 195 with: {"percent":36,"message":"Updating app sub1.domain.name"}
May 04 03:40:02 dns: upsertDnsRecords: subdomain:change domain:sub1.domain.name type:A values:["aaa.bbb.ccc.ddd"]
May 04 03:40:05 tasks: updating task 195 with: {"percent":57,"message":"Updating app sub2.domain.name"}
May 04 03:40:05 dns: upsertDnsRecords: subdomain:bookmarks domain:sub2.domain.name type:A values:["aaa.bbb.ccc.ddd"]
May 04 03:40:07 tasks: updating task 195 with: {"percent":78,"message":"Updating app sub3.domain.name"}
May 04 03:40:07 dns: upsertDnsRecords: subdomain:vpn domain:sub3.domain.name type:A values:["aaa.bbb.ccc.ddd"]
May 04 03:40:09 tasks: updating task 195 with: {"percent":99,"message":"Updating app sub4.domain.name"}
May 04 03:40:09 dns: upsertDnsRecords: subdomain:sync domain:sub4.domain.name type:A values:["aaa.bbb.ccc.ddd"]
May 04 03:40:11 tasks: updating task 195 with: {"percent":100,"message":"Done"}
May 04 03:40:11 tasks: setCompleted - 195: {"result":null,"error":null,"percent":100}
May 04 03:40:11 tasks: updating task 195 with: {"completed":true,"result":null,"error":null,"percent":100}
May 04 03:40:11 taskworker: Task took 10.021 seconds
May 04 03:40:11 Exiting with code 0

Where domain.name is my domain and aaa.bbb.ccc.ddd the new IP address.

No sure why this errors on the first record update but not the others.