Cloudron Forum

Description

Since a recent Cloudron update (9.0?), an External Link of the form http://... will, when clicked, attempt to open https://http//...

Steps to reproduce

Create a new External Link. (Confused since 9.0? Me too: see here.) For "External URL", put http://192.168.0.2:8000. For "Name", put Test.

Go back to the Dashboard and click the app for Test.

Expected (and prior to a recent update): opens http://192.168.0.2:8000 in a browser tab.

Actual behavior (bug): opens https://http//192.168.0.2:8000 in a browser tab.

Cloudron Version

Cloudron version: 9.0.15

Ubuntu Version

Ubuntu 22.04.4 LTS Linux 6.8.0-87-generic

Other information

As you see from the example, I'm using external links for a number of computers and services on my home network, which is why I'm using http instead of https.

We're using Zulip and it's incredible. The organization of channels into sub-topics is perfect. The LaTeX integration is also huge for us. It has some nice quality of life features and just generally works really well for us. Cloudron integration would be great.

Disabled all my extensions. But when I download a fresh version of Firefox (136.0.2), I don't reproduce the issue. So it must be me...

Thank you! FWIW, my issue was caused by using ssh to navigate the app's data directory on my server, when I needed to be using the Web Terminal.

I added all three of these lines:

AppConfig.registeredOnlyTypes = AppConfig.availablePadTypes;
AppConfig.disableAnonymousPadCreation = true;
AppConfig.disableAnonymousStore = true;

I am running into the same error message mentioned here: https://github.com/advplyr/audiobookshelf/issues/2854

When I scan a library, the log gives:

FATAL

[Server] Unhandled rejection: ReferenceError: structuredClone is not defined, promise: Promise { <rejected> ReferenceError: structuredClone is not defined at LibraryItemScanData.checkLibraryItemData (/app/code/server/scanner/LibraryItemScanData.js:241:41) at LibraryScanner.scanLibrary (/app/code/server/scanner/LibraryScanner.js:188:60) at async LibraryScanner.scan (/app/code/server/scanner/LibraryScanner.js:82:22) }

Wow, thanks, that was fast! I'm not seeing the error any more.

Solved
This turned out to be easier than I expected, oops. I modified signin_inner.tmpl to only have the small OAuth2 portion of the signin page, i.e. I deleted lines 13-54 and 56-58 from that file (as it exists now), and put my version in gitea's folder custom/templates/user/auth/. As desired, it still displays "Login with cloudron", but not the main login option.

Edit: fixed. I found docker.service inside /etc/systemd/system/multi-user.target.wants/

I didn't get this to happen: "Then, systemctl start my-disk-mounter would automatically start docker and box." But that's ok. I run a manual startup script that prompts for the encryption password, mounts the disk, then starts all the systemd services. Instead of my-disk-mounter.service, I have check-that-all-disks-are-properly-mounted.service which is Required by box and docker. Thanks again.

Any advice on how to migrate repositories and access permissions from a Gitea instance that is not on Cloudron to a fresh Gitea instance on Cloudron?

My first choice would be to modify the steps in Gitea's Backup and Restore, though I'd have to sync the users and permissions correctly somehow.

But if I could access the gitea command line, I'd be okay with trying to take it from there manually. It's not a large instance at all. However, I think the cloudron doc about how to access the Gitea CLI is outdated. I guess it has to do with docker now, but I'm not sure how.

I have two different cloudrons. New this morning, trying to login to apps on either one is giving me a totally blank page on Linux Mint 21.2, Firefox 133.0.3.

After clearing all cookies and browser settings, when I go to my Cloudron homepage at my.example.com, I get redirected to a page of the form https://my.example.com/openid/interaction/<randomcode>, which appears totally blank.

Getting out chromium, the page still works there.

Awesome, thank you!