Cloudron Forum

As per their blog post, is now possible to self host but they state it’s quite technical.

Would love the cloudron team to make it easy!

https://bsky.social/about/blog/02-22-2024-open-social-web

UPDATE: For the moment as the Cloudron team seems disinterested in supporting this (especially strange with the massive increase of people moving to Bluesky) I have put together a Linode StackScript that installs this with some prompts for key details. I don't have time to troubleshoot the script too much - but I believe it mostly works.

Linode link: https://cloud.linode.com/stackscripts/1536630
Blusky Discussion Post: https://github.com/bluesky-social/pds/discussions/141

—-
So how can I self-host and join the network?

It will become easier to host your own server over time, but at the moment you’ll need a bit of technical know-how to get up and running. If you’re excited to jump in, checkout the developer blog, the PDS repo on our Github, and the PDS Administrators Discord.

@shanelord01 OK - worked it out.

1. Open the web UI for LibreTranslate after setting it up.
2. In the "Request" box, there is a line with "const res = await fetch("https://translate.your.domain/translate", "
3. Copy the main domain URL (ie https://translate.your.domain" )without the /translate and without quotation marks.
4. Open your Cloudron Mastodon app, and open its file manager and edit "env.production"
5. At the bottom, add the "#translate section" below here:

# Optionally change default language
# DEFAULT_LOCALE=en

# translate
LIBRE_TRANSLATE_ENDPOINT=https://translate.your.domain
LIBRE_TRANSLATE_API_KEY=YOUR_API_KEY

Save this. Restart the Mastodon app.

API Key
If you don't have your API key, open the LibreTranslate Cloudron App Terminal, and issue:

su - cloudron -c 'ltmanage keys --api-keys-db-path /app/data/api_keys.db add 120'

You'll get a key like "f67d5afe-aa14-4d37-90f7-f7d9636b721e" in response - use the one you got in reponse.

Optional; set your default language:

# Optionally change default language
DEFAULT_LOCALE=en

Update:
After completing setup and ensuring everything works, if you want to stop people from using the Web UI to translate, you can disable it by editing the LibreTranslate "env.sh" file via its Cloudron File Manager, and adding this (then save env.sh and restart LT):

export LT_DISABLE_WEB_UI=true

Note: After doing this I've noted the app is stuck reporting as "Starting" in the Cloudron "My Apps" even though it is running fine. Not sure if this is a health check failing in the Cloudron app? @nebulon Any way to do this without causing this issue?

@nichu42 Compared to what I had (nothing) it's quite good. Speed hasn't been an issue so far - I guess because I over-spec'd the machine it's running on so it has extra CPU available.

@girish I've asked and they have no more information. My scans and checks were enough for them to consider the case closed and no mitigation from them required.

Thanks - I've done some further testing. You are right - it does work.

Seems the Debian host I was using on Linode (using "Secure Your Server" image) was blocking port 9200 by default so had to adjust iptables to allow external access. Had a hard time tracking that down.

Added:

iptables -I INPUT -p tcp --dport 9200 --syn -j ACCEPT

then saved it. Worked immediately.

OK I have LT setup and running, API key configured.

How do I now edit the Cloudron Mastodon config to use it?

Thanks,
Shane.

@subven Yep. I’m running mine in a Linode 8GB 4CPU (shared). That’s about the same cost.

@nebulon Yep - seems to be due to insufficient processes and threads in config.sh

I'm playing with:

#!/bin/bash

# Setup scaling related environment variables here - https://docs.joinmastodon.org/admin/scaling/

# Puma
export WEB_CONCURRENCY=10    # number of worker processes
export MAX_THREADS=20        # the number of threads per process

# Streaming API
export STREAMING_CLUSTER_NUM=2  # number of worker processes

# Sidekiq
export SIDEKIQ_THREADS=80
export DB_POOL=100               # must be at least the same as the number of threads

at the moment and it seems to be catching up.

I have it up and working with the new Cloudron LibreTranslate app. Running on the same Linode as my Mastodon.

https://forum.cloudron.io/topic/8527/libretranslate-with-cloudron-mastodon-server/1

@nichu42 Completely agree. Perhaps it’s time for a package including both (or at least instructions on hire to set it up).

Personally I’d prefer a one stop all in one install.

Hi team - found this request and is love to have this on Cloudron. Any chance this could be spun up?

@timconsidine Thanks. The only app I had actively running but I haven't used or paid attention to for a while was LibreTranslate. I've deleted that app for now and just running Mastodon. Will see if that placates the Linode security team.

Linode support have just contacted me reporting the following:

We have received a report of Brute Force attempts originating from your Linode. This is most likely the result of a system compromise. If we have not heard from you in 24 hours, we may need to place network restrictions on your Linode to prevent further attacks.

Abuse Report

Extracted Details
ip 194.195.127.xxx
send_date 2023-07-17T04:57:51Z
received_date 2023-07-17T04:58:28Z
format fail2ban
This report was generated by Abusix

I booted into Rescue Mode and run ClamAV and found no compromises. Any other ideas?

Thanks,
Shane.

@timconsidine They recommend using it in rescue mode. I had to install it (Linode provide an all-in-one script to update it and run the scan).

Minor issue with the GPG keys stopping apt from running that I had to fix (thanks ChatGPT for the assist).

Steps to fix
Here are the steps to fix the GPG error on Finnix Linux:

1. Open a terminal or SSH into your Finnix Linux system.

2. Run the following command to retrieve the missing public keys:

   gpg --keyserver keyserver.ubuntu.com --recv-keys 0E98404D386FA1D9
   gpg --keyserver keyserver.ubuntu.com --recv-keys 6ED0E7B82643E131
   

3. Once the keys are imported, run the following command to export the keys to a file:

   gpg --export 0E98404D386FA1D9 > pubkey1.asc
   gpg --export 6ED0E7B82643E131 > pubkey2.asc
   

4. Once the keys are imported, create a new file in the trusted.gpg.d directory using the touch command. For example:

   touch /etc/apt/trusted.gpg.d/debian-keys.gpg
   

5. Now, move the exported key files to the trusted.gpg.d directory:

   sudo mv pubkey1.asc /etc/apt/trusted.gpg.d/debian-keys.gpg
   sudo mv pubkey2.asc /etc/apt/trusted.gpg.d/debian-keys.gpg
   

6. Update your package lists by running:

   apt-get update
   

After following these modified steps, the missing GPG keys should be added to the trusted.gpg.d directory, and you should be able to update and install packages without encountering the GPG error.

@girish I only have the info provided and the attached image.

@jdaviescoates It doesn't seem possible to change the NGINX settings for this to work in Cloudron, unless I'm missing something?

Hi team,

Any chance we could get an option to enable LibeTranslate in our Mastodon App?

https://sleeplessbeastie.eu/2022/11/17/how-to-use-libretranslate-with-mastodon/

Thanks,
Shane.

@doodlemania2 I’d be interested in having Elastic Search enabled in some way for my Mastodon instance.

How would we do it?

@girish I've disabled backups for now as I try and work out why there is an issue with it. My Linode backs up daily at the moment so worst case I recover the whole system.

@nichu42 Brilliant stuff.

For me on Linode, all I did extra was to create a VLAN and connect eth1 on my Cloudron to it, as well as eth1 on my Elasticsearch server. Then used this private link to connect the two.

Edit : Actually damn while troublshooting why I was having an issue getting it to work, it seems Cloudron does not recognise multiple NIC/eth interfaces. So I can't have eth1 on a VLAN with a 10.0.0.x/24 address.

See Linode setup here: https://www.linode.com/docs/products/networking/vlans/get-started/

Cloudron via "ip link show" isn't showing the eth1 interface at all. @girish any way to fix this toi make it work?

Edit 2: Make sure to troubleshoot the network.host on the Elasticsearch server and port 9200 is open in iptables - mine was refusing connections for some reason. Working on VLAN now.