Topics created by fbartels

@girish ok, sounds good to me.

@fbartels said in Webserver reload missing when using manual dns?:

I was just investigating an expired certificate on one of my Cloudron systems and wanted to leave a note here.

The app in question uses manual dns settings for reasons that are beyond my control, but port 80 is publicly available so that using lets encrypt should be no problem.

Looking at the logs below "Renew certificates" was sadly empty. I guess these have been rotated since the last certificate was issued.

Restarting the app had this bit in the apps logs, which means the certificate must have been successfully renewed back in december, and only the webserver has not been restarted since then.

Jan 25 12:02:44 => Start supervisor Jan 25 12:02:44 box:reverseproxy providerMatchesSync: subject=CN = lx.example.com domain=lx.example.com issuer=C = US, O = Let's Encrypt, CN = R3 wildcard=false/false prod=true/true issuerMismatch=false wildcardMismatch=false match=true Jan 25 12:02:44 box:reverseproxy expiryDate: notAfter=Mar 25 11:10:49 2023 GMT daysLeft=59.00561143518519 Jan 25 12:02:44 box:reverseproxy needsRenewal: false Jan 25 12:02:44 box:reverseproxy ensureCertificate: lx.example.com acme cert exists and is up to date Jan 25 12:02:44 box:reverseproxy writeAppLocationNginxConfig: writing config for "lx.example.com" to /home/yellowtent/platformdata/nginx/applications/fdda3359-5b81-4228-b4cb-1f5dfe8a3436/lx.example.com.conf with options {"sourceDir":"/home/yellowtent/box","vhost":"lx.example.com","hasIPv6":true,"ip":"172.18.17.213","port":8080,"endpoint":"app","redirectTo":null,"certFilePath":"/home/yellowtent/platformdata/nginx/cert/lx.example.com.cert","keyFilePath":"/home/yellowtent/platformdata/nginx/cert/lx.example.com.key","robotsTxtQuoted":null,"cspQuoted":null,"hideHeaders":[],"proxyAuth":{"enabled":false,"id":"fdda3359-5b81-4228-b4cb-1f5dfe8a3436","location":"/"},"upstreamUri":"","ocsp":true} Jan 25 12:02:44 box:shell reload spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/restartservice.sh nginx

thanks my issue has been fixed.

@fbartels deno should install in LAMP, but it sounds like you want to take a crack at packaging it.. will that include deno or not?

OK, the mystery remains then. Nothing has changed on our side to cause this issue as such 🤔 .

@shanelord01 (waves) it auto-approves after a few minutes assuming your side is set up cleanly - I see you and welcome!

Many people have tried to relay over the past few weeks. Some don't have SSL (hard pass), some are using fake FQDN (hard pass), and then of course, we had a few bad actors come along and I had to boot em.

Be mindful of your blocks and mutes - whole instance blocking is a big sledgehammer unless it's just a whole instance of bad. Also, if you see someone on my relay and you're like, ewe, Derek should know about that, please ping me (at)derek(at)toot.thedoodleproject.net - I am watching but it's a LOT to watch and any visibility on bad instances is appreciated - let me know and I'll block em at the relay.

Just to close this topic up. It seems one mayor factor seems to have been that the "worker" in authentik was stuck and therefore did not attempt to connect to process the ldap connection. After it started processing the connection it ran into some python tracebacks because of missing attributes. I could not get the sync to run, but then anyways decided to do it the other way around and use authentik as my primary source of users and connect my Cloudron to authentik instead.

The final switch is still pending however as Cloudron already has an ldap source configured, which I am going to decommission soon.

It certainly could. Alongside the docker registry app. Another bonus for using gitea for container storage is that you can use access tokens instead of the actual user password.

It seems @jimcavoli already got this working, see here:
https://forum.cloudron.io/topic/3678/build-deploy-to-cloudron-from-github-actions

@humptydumpty to reliably update i ended up always updating the docker tag to the desired version. With the tag updated you just need to run flyctl deploy again.

Hi @girish, ah that fully explains why I cannot interact with the processes running in the container. While your design idea is probably suitable for most cases it won't really work for this specific one.

But no harm done, then I will just add a cron service to my app container directly.

@fbartels said in Duplicate entry '172.18.17.187' for key 'apps.containerIp':

PS: the synapse documentation states that the well known settings are under advanced in the domain settings

Fixed!

@jdaviescoates in their repo they are calling it a "showcase" and also require a specific development branch of one of their dependencies. Overall the project does not look quite "ready" to me yet.

OK, so the issue was that the app thinks it's configured for LDAP, but it's not (since it's a public facing instance, we disabled LDAP). I have removed the LDAP panel entirely from the login page. Thanks for reporting @fbartels

This should be fixed with the next release. There were a couple of state issues which needed fixing.

more likely a browser hiccup..

@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.

@fbartels I can vouch for Siteground, they have a stellar customer support and very good service.

Would it be not for Cloudron, my WordPress websites would still be with them.

Small update. The long wait time when logging in seems to be related to LDAP users. At least when logging in with a user that has been created manually the login immediately succeeds.

But this seems unrelated to the long wait time for the request when submitting the shopping cart, as this also happens when the ldap plugin is deactivated.

thanks, I have made a new package now.

@nebulon thanks. works like a charm now.

@girish Thanks for looking at this. Just triggered another backup with all apps active and it succeeded. I guess then it's finally time to move to the new hardware (plus making sure that the new system is using the c locale by default)

How much of this will change with Multi-Cloudron?

@marcusquinn I tried to patch up this post and closed the other one.

how embarrassing. You're absolutely right. I was searching after ghosts.

@fbartels awesome, thanks for testing. I am fixing the graphite issue, that error is something else. Fixed in https://git.cloudron.io/cloudron/box/-/commit/f7bd47888ac157fc5b86021f6458b6a7f0d3fba8

Right, since you have the access token in this case in a new tab simply in the local storage, the session is refreshed and you see the files. I will fixup the login state/login button to show somethign like "Admin Dashboard" or so.

hm.. I can also not reproduce it. Yes, that login url I did get as well, but when then forwarded to the logged in view (the one with index.php?r=admin) it did fail before.

I have added cloudron update --appstore-id {id} for the next release.