Agate+ (dual protocol server to serve gemini/http from one source)

[LoudLemur]

Hey, Tim, I like the new update and now I can see we can use it to one click install FacilMaps - nice!
Very, very nice, actually! We wanted to serve our own maps like this for ages. Now we can!

Also, very cool, we can even use ccai to install ccai - on our own server!

CCAI deserves a thread/discussion all of its own, I think.

[timconsidine]

@LoudLemur thank you
I wanted to get CCAI to a point where it would be worth making an App Wishlist for it.
Just a few more tweaks to do.

And need to find more custom apps to flesh out the catalogue with known/tested cases.

[robi]

@timconsidine said in Agate+ (dual protocol server to serve gemini/http from one source):

Hmm <scratching head>
I've been trying to diagnose @robi report that app installs but gets stuck in "Starting..."

Same here, tried to use my.demo.cloudron.io but it fails to log in at all:
Failed to check login status: Unexpected token '<', "<!DOCTYPE "... is not valid JSON

I'll see if I can find another Cloudron to test with in case something is off with mine.

UPDATE:
Seems to be a combo with an specific browser version and my Cloudron is having issues with all apps that install/upgrade.. waiting for healthcheck.
Sorry for the wild goose chase. CCAI install on Demo server worked just fine after using another browser.

[robi]

This post is deleted!

[timconsidine]

@robi weird - good investigative work !

[robi]

@timconsidine Thanks, less than obvious with two things going wrong at the same time.

Have you thought about how to rapidly grow the installable App list?

[timconsidine]

@robi well, I started to think about it.

I was thinking about making a search of git.cloudron.io

Then I thought maybe some/many would be old and packager should be consulted.

And we need a pre-built docker image, so next question is who should build that, I could but not sure about time available, depends on how many.
and maybe packager should do it.

Bottom-line, I ended up in a spiral of indecision !!

Any ideas gratefully received.

[robi]

@timconsidine How about this..

A checkbox for others to choose to submit a custom app, then check if the install is successful, if so then check if it's already in your CCAI DB/list/json, if not then add it as a new addition with an installed count, plus notification if you want.

It would also be nice to keep the CCAI login active for 15m or so, allowing multiple apps to be installed without constantly logging in.

[timconsidine]

@robi thank you
Will get on to that, working on packaging Sync-in at the moment

[LoudLemur]

Small bug in agate+ start.sh, tmpfs wipes /tmp/proxy/ on restart

---

TL;DR: /tmp is tmpfs on Cloudron, so /tmp/proxy/*.sh vanishes on every restart. Line 52 cp fails, set -e kills start.sh before supervisord launches, nothing binds :8000, healthcheck loops forever. Wrap the cp block in if [ -f /tmp/proxy/restart-proxy.sh ]; then ... fi.

---

Hi @timconsidine! We ran into a restart loop on agate+ today and wanted to flag the cause in case others hit it too.

Symptoms in the app logs:

cp: cannot stat '/tmp/proxy/restart-proxy.sh': No such file or directory
=> Healthcheck error: Error: connect EHOSTUNREACH 172.18.x.x:8000

What's happening

In normal run mode on Cloudron, /tmp is backed by a fresh tmpfs on every container start, which shadows the /tmp/proxy/ files baked into the image. So the cp on line 52 of start.sh fails, set -e aborts the script, and exec supervisord on line 154 never runs. healthcheck.js never binds port 8000, Cloudron healthcheck fails, container gets restarted — and round it goes forever.

The copied files already exist in /app/data/ from the first install anyway, so the cp is really only needed on fresh installs.

(In debug mode the tmpfs overlay isn't applied, so the files are visible and the app starts fine, which made it a bit confusing to diagnose at first.)

Suggested fix

Guard the proxy-file copy block so it's a no-op when the source isn't there:

if [ -f /tmp/proxy/restart-proxy.sh ]; then
  cp /tmp/proxy/restart-proxy.sh /app/data/restart-proxy.sh
  cp /tmp/proxy/register-new-instance.sh /app/data/register-new-instance.sh
  cp /tmp/proxy/deregister-instance.sh /app/data/deregister-instance.sh
  chmod +x /app/data/register-new-instance.sh /app/data/deregister-instance.sh /app/data/restart-proxy.sh
fi

Alternatively, stage those helpers somewhere persistent (e.g. ship them in /app/code/proxy/ and copy from there) so they survive the tmpfs reset on every restart, not just on fresh installs.

Tested the guarded version on our instance and it's back up and running cleanly. Happy to open an MR if useful.