Cloudron Forum

It's also not always about the number of users as it is plugins and search and any maintenance scripts that can use more memory.

I was able to fix this by deactivating all the plugins after the yarn remove from above and then restarting. So I guess its an upstream issue.

Restarting the app via Cloudron will essentially re-run this start script https://git.cloudron.io/cloudron/nodebb-app/-/blob/master/start.sh?ref_type=heads

It does a bit more than what the internal rebuild does, so rebuilding and restarting from within nodebb if it asks for is preferred. Also it will put a nicer placeholder page with the forum style instead of the generic Cloudron one.

@saikarthik no worries 🙂

I will remove that line altogether. This closed issue list was maintained 5-6 years ago but it's not anymore.

@saikarthik ah ok, thanks. I guess you have to ask upstream why it's this way.

@saikarthik said in What plugins do you use?:

What plugins does the Cloudron forum use?

We generally avoid plugins in any software and not just NodeBB. I don't want to go on a rant but plugins are probably one of the main reasons selfhosting is such a challenge. Oh well... I recommend sticking to the bare essentials.

nodebb-plugin-composer-default nodebb-plugin-dbsearch nodebb-plugin-emoji nodebb-plugin-emoji-android nodebb-plugin-markdown nodebb-plugin-mentions nodebb-plugin-ns-embed nodebb-plugin-question-and-answer nodebb-plugin-sso-github nodebb-plugin-youtube-embed nodebb-rewards-essentials nodebb-theme-harmony nodebb-widget-essentials

Not sure if you guys did something, but yes it is running now. It was stuck in a loop showing the error message above. Thanks!

@saikarthik FWIW, I've used and really like the Wordpress plugin, Pressbooks, for such a task. It's handy to have the breakdown of the book handy, it has version control, you can control User access, and by installing some of the backend stuff, you can output a finished book straight to PDF or ebook.
https://www.wpexplorer.com/create-books-wordpress/ is a site talking about it, but the link above goes to the .org version. WP also has to be setup for multi-site, too. Not a huge pain, but a step you can't skip.

@saikarthik said in Incoming email not being received:

I had to re-add the entry for netlify load balancer in my DNS.

Maybe next time lead with that. The use of „netlify load balancer“ seems to be some vital information while people are trying to guess-troubleshoot your DNS problems….

We don't really have public stats for this. Internally we track this very loosely. When you install an app, your Cloudron sends a request to our appstore service to register the installation, on uninstallation the same happens. This is required to check the 2 app limit on the free tier with the validity and state of the subscription. Since uninstallation may or may not call us back (like a server just goes offline or gets deleted) those stats are rather inaccurate for actual app install stats.

@girish yes.

@saikarthik That seems like a no brainer for WordPress, especially if you're going to have the customer do menu updates themselves.

There are a plethora of WP resources and ways to get help too, depending on your support model.

EspoCRM could be set-up to handle that and taking online orders, etc. with additional compelxity.

On the other hand, if it's not something with online orders, any menu can be made into a super simple static site/page with the menu being a few images or an embeded PDF.

Depends on how fancy do you want to go.

Please ignore this issue, there was some error with the underlying instance I guess. I started a new instance and everything is good.

That took a while but we are back in business - https://aws.amazon.com/marketplace/pp/prodview-aep3gt5elubci

BTW, 3.1.0 is the most recent image now - https://forum.cloudron.io/topic/6178/new-base-image-3-1-0

Followed this guide and everything is back to normal. Thanks guys!
https://docs.cloudron.io/guides/import-postgresql/

This is covered to some extent in this video presentation by @girish

https://videos.cloudron.io/videos/watch/206fc4b7-9641-4453-8be0-67450f2574b1

Here are the relevant parts of my notes on that:

@jdaviescoates said in How does Cloudron work? What does it do? etc 🙂:

== App Lifecycle ==

Install
-- Configure DNS
-- Downloads docker image and manifest file from the Cloudron app store
-- Sets up addons
-- Logrotate, Collect (stats about the app, how much CPU, memory it using etc), Firewall
-- Runs the docker container
--- Dynamic configuration (giving the app db credentials, SMTP credentials to send email, e.g. for WordPress it creates the wp-config.php file with all the relevant credentials)
-- Gets SSL certificates from LetsEncrypt (and set-up reverse proxy, i.e. when blog.domain.com is visited forward to this container)

Updates
-- Read only and stateless app containers (all apps are read only - apps cannot write to their file system, if they could then users could add all sorts of random files and it wouldn't be possible to update smoothly, the code cannot be modified. This means when there is an update we can just throw away the old container and get in the new container. So where does the app write stuff it needs to? We let the app write in 3 locations 1) /tmp for temporary files 2) /run which contains runtime files which an app needs to communication across various processes, 3) app/data/ where the app will put images, files uploaded etc - everything in app data is part of the backup, /tmp and /run is not backed up)
-- Rolling updates
-- Signed releases
-- Selenium based tests (test that everything actually still works)

Note: It took me a minute to put this together while @nebulon was responding and I got pulled onto something else for a minute, but I think the detailed writeup is worth having for posterity, so I'll post it anyway.

So what's going on here is that the app in question isn't reading the "right" headers to find the remote address. Basically, the inbound requests come in and hit the box-level nginx reverse proxy, which forwards the request on with the original inbound IP in the X-Forwarded-For header. Since from the sound of it, you're just routing straight to your app in the container, you'll want to either reconfigure your logging library to use the forwarded IP header as the client IP or drop nginx or similar as a reverse proxy in front of your app and configure it to rearrange the incoming headers as your app needs.

Sounds like you can just adjust a configuration so that this (your existing flow) works nicely:
container-sans-rp.png
Basically, here, the headers are adjusted in the "Step 1" processing as they reach the Cloudron so when they reach your app, the proxied headers have already gone into place. Again, this configuration should be fine with the configuration that @nebulon mentioned going in, since that should reconfigure your framework to read these adjusted headers correctly.

Failing that, or for apps with more complex setup or which aren't able to read those headers on their own by configuration, the solution is to further proxy those requests, by adding nginx or similar to take over the "Step 3" handoff and smooth out any specific details (like re-adjusting headers) for the app, and having it proxy those requests down to your app, all in-container, so that the logging and such in your app will all match up with expectations/reality. The whole point of the second reverse proxy when it's added it to make the world appear as it needs to for the app and/or its components inside the container.
container-rp.png