Good morning
This is a technical issue, not a political post.

I have become stuck in UK and unable to return to family in Ukraine.
Flight pre-planned for Day2 of invasion obviously cancelled.
Internet in Kharkiv breaking down now.

I am doing research on 'offline' comms, maybe some kind of relay or mesh. But time is short and frankly brain is not as clear as it usually is.

So any advice appreciated.

Scenario is I stay here in UK for now, but also interested in scenario of going to Poland and waiting it out there. So maybe no internet there other than mobile phone.

As I said, tech query not political, but please forgive me a quick 'Slava Ukraini'.

@girish : it will for sure be impossible to persuade others to do it the Cloudron way, so the problem has to be addressed.

Personally I feel the Cloudron stability and reliability is SO IMPORTANT that it must be preserved and it is the priority. If it is impossible to find a solution, we have to accept a situation like "sorry, this XXX app is such a mess, it is not possible to make it comply with Cloudron standards, and even though it is good functionality, and we could possibly package it, we're not going to. Because it's a mess."

While I don't have a technical solution approach to the problem, I think it's almost inevitable that we end up with another status of apps :

• OFFICIAL (package tested, released, maintained, conforms to Cloudron standards)
• UNSTABLE (although I don't like this word : should be Beta or not-yet-officially-released)
• MESS or "Pig's Breakfast" (packaged, works, use it, but maintained as best endeavours, esp ref backups, because upstream dev does not conform to Cloudron standards)

Not ideal, but better than lowering Cloudron standards. Would rather accept not having XXX app in the store.

https://ntfy.sh

ntfy (pronounce: notify) is a simple HTTP-based pub-sub notification service. It allows you to send notifications to your phone or desktop via scripts from any computer, entirely without signup, cost or setup. It's also open source if you want to run your own.

Really simple notifications for scripts, server status etc.

curl -d "Backup successful 😀" ntfy.sh/mytopic

If self-hosted, obviously change the ntfy.sh to your own domain.

While trying to resolve some backup issues, I wondered if it might be possible in future Cloudron release to have backup policies per app.

Some apps need backing up daily but some might only need weekly or monthly. Currently backup configuration is set globally for the instance.

Just to add context to my comment :
I have 45 apps running on my Cloudron (I am sure others have even more).
<5 minute installs vs 2-3 hours 'conventionally' : 45 times. That's a lot of time and grey hair saved.
Normally I would need multiple servers to run that for segregation, so the Cloudron monthly-equiv fee is off-set by saving on multiple VPS.

I totally get that non-profits have a duty and a need to keep costs down.
But that's exactly what Cloudron does.

Cloudron is truly cost-effective and cost-minimising.
Cloudron is the only tech cost that I'm genuinely happy to carry.
And they stand out a mile vs the rest of the industry in terms of quality, kind and constructive support.

But @girish and @nebulon : that doesn't mean you can increase the price !!

http://raneto.com/
Markdown powered Knowledgebase for Nodejs
Raneto is an open source Knowledgebase platform that uses static Markdown files to power your Knowledgebase.

Nice little app

@luckow the cloudron community is special, because of all the varied contributions.

Have a good Christmas !

Minus 12c in Kharkiv

Thanks to all who responded with advice here, and also by private message.

You may wish to know that eventually after difficult journey, my wife + step-son + sister-in-law managed to get to Poland. I am here in Warsaw with them, waiting for UK visa, and hopefully they will to get to a stable home, temporary or longer-term soon (whatever that means, few days, few weeks). Parents-in-law are stuck there, currently in occupied territory so evacuation difficult, and we just have to pray for their safety.

My intention is that we return to Ukraine when it is possible to do so.

Thanks again for all the advice.

@marcusquinn : definitely +1

I struggle to get my head around using it, but it seems to me this is much needed to further decentralisation and "returning the internet to its roots", reducing dependency on BigTech.

https://github.com/dgtlmoon/changedetection.io

Self-Hosted, Open Source, Change Monitoring of Web Pages
Know when web pages change! Stay ontop of new information!
Live your data-life pro-actively instead of re-actively.

I use this app on CapRover and it works nicely.
Would be nice to have on Cloudron, although I accept not life-changing.
And I think there are various systems like this : I don't how this ChangeDetection.io compares. I just like the ease of use and UI.

Dockerfile available in their repo.

I made an attempt at self-packaging, but getting some errors, which I am investigating.

@plusone-nick nice list !

I tried Saltcorn and while it is attractive in many ways, I would not recommend it as it is easy to 'hack' the url to view data of another user/client/transaction that should not be available.
Unless they have fixed this in terms of url exposure.

@ruihildt indeed very cool
Just deployed languagetool on a Coolify instance, and it's very nice.

Dockerfile doesn't seem too complex, but some pieces I am not sure how to handle for custom package.

@girish yay !
Despite the hour I couldn't resist trying it.
I changed the location of the api from minio-api.domain.tld to minioapi.domain.tld (just removed the hyphen) and saved the change.
Renewed certs and logs now show the api domain in there.
Tested with Minio mc CLI and Forklift : they both list buckets and contents.
Will check MountainDuck and others later.

Thanks for your patience and support.
Marking it solved !

@girish yep, seems to be a cert issue
The cert for minio.domain.tld is shown in the logs, but there is no entry in the logs for minio-api.domain.tld.
I'm using wildcard DNS (cloudns.net).
The DNS entries are fine for domain.tld (I have a number of apps on the domain).
I will try to force it by changing the Location in the morning.
If necessary, I will download the data content and recreate the app.
I think we're close to a solution.
Will confirm in the morning.

I've began looking into Cloudron alternatives like YunoHost

I tried Yunohost a while back and found it flakey.
Caprover is better than Yunohost, but that also has a fair number of apps that don't install correctly.
Neither of them are a patch on Cloudron, which is rock-solid. Having spent many hours on alternatives, I would strongly recommend spending less total time on making Cloudron work for you.

As @girish says, FreshRSS and TinyRSS work well.
I don't know the advantages of Miniflux, but maybe it could be packaged.

I would like to have database access which can be quite limited in Cloudron

A little surprised by this. I was of the opinion database access in Cloudron is good. What functionality are you wanting that you don't feel is available?

@girish I've tried various approaches based on using minio-api.domain.tld and the standard 443 port :

• Forklift
• MountainDuck
• Transmit
• S3FS

None of them connect properly.
I haven't tried Expandrive but don't expect any different.

Even the "official" Minio mc CLI app (https://docs.min.io/docs/minio-client-complete-guide.html) fails with this message.

$ mc ls minio
mc: <ERROR> Unable to list folder. Get "https://minio-api.domain.tld/": x509: certificate 
is not valid for any names, but wanted to match minio-api.domain.tld

I'm no expert but I'm starting to think there is an issue with Cloudron's minio implementation. Maybe simply that the certificate for the installed app is valid for the console url, e.g. minio.domain.tld but not for minio-api.domain.tld

I'm not sure how to properly test the certificate for minio-api.domain.tld, but a clumsy attempt to visit https://minio-api.domain.tld (without expecting it to render a page) gives the standard certificate problem response :

Your connection is not private
Attackers might be trying to steal your information from minio-api.domain.tld (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
This server could not prove that it is minio-api.domain.tld; its security certificate does not specify Subject Alternative Names. This may be caused by a misconfiguration or an attacker intercepting your connection.

Is it dumb to question whether minio-api.domain.tld can actually be verified by connecting apps ?
Why else would Minio's mc app fail to connect ?

@girish I was guessing about 9000 / 9001 based on some internet references. Thanks for clarification.

Getting a connection but still unable to list bucket contents.

Close to giving up on Minio.
Used to work for me in Forklift.
That no longer works, I'm guessing for same reasons that MountainDuck is struggling.

well it seems that I can get a connection using the minio-api.domain.tld and 443
Doesn't compute given earlier messages.
But I then get listing directory xxxxx failed org.xml.sax saxnotsupportedexception
So maybe this is a MountainDuck issue, which of course is not a Cloudron issue.

Trying minio-api.domain.tld in the browser (for debug purposes) generates a certificate not trusted error.
Certificate problem ??
Or more likely E30 (error 30cm away from keyboard)

I'm trying to access my minio app using Mountain Duck to mount it as a drive on local machine (MacBook).
Using recommended profile : S3 HTTPS
Have :

• an admin user in Minio
• a user created in console
• that user has a service account
• the service account has an access policy

Trying with port 443 says I must use API port for S3 requests.
OK, so trying with 9000 and 9001 I get a timeout.
Tried on minio.domain.tld and also minio-api.domain.tld

Dumb question : what port should I be trying ?