Thanks guys, managed to get this working with the new package
tkd
Posts
-
Large JSON file upload getting nginx 413 error -
Large JSON file upload getting nginx 413 error@nebulon Appreciated. If there is any temporary command I can execute in the app's terminal for now that would make this setting would be fine until you have a full fix.
-
Large JSON file upload getting nginx 413 errorThanks. This is quite important to us to get this loaded into a Ghost instance. If anyone has any ideas or a temporary work around I'd be happy to know - or if Ghost has another method of importing content that would work with the Cloudron package.
-
Large JSON file upload getting nginx 413 error@nebulon Sure, it's non public so I will email to support address now thanks.
-
Large JSON file upload getting nginx 413 errorNo I'm not using Cloudflare, Cloudron is hosted at Digital Ocean using and I'm connecting direct to the server, as I mentioned above I'm not aware of any proxy or anything between the browser and Cloudron.
-
Large JSON file upload getting nginx 413 errorThere is no proxy anywhere on my connection or the server. Someone else has reported this problem to me and I have found the same problem. I can try later with a 4G mobile connection but as someone else has the same issue and my internet connection is gigabit fibre I do not think it has anything to do with the connection.
-
Large JSON file upload getting nginx 413 errorI'm trying to import JSON blog content into Ghost using the Ghost admin dashboard: Settings -> Labs -> Import Content
After a minute or so Ghost gives the error:
Import failed - Request is larger than the maximum file size the server allows.This seems to be down to a 413 Request Entity Too Large response from Nginx.
Is there a way to increase this limit on a per app basis or globally, temp or permanently?
The file is 137MB.
Ghost version 3.26.1 - package (v3.126.0)
-
Scaling / High Availability Cloudron SetupI use Cloudron as a solution to host multiple blogs for some customers. Given what a powerful solution Cloudron is, one thing I fell that is really missing from the whole package is some way of enabling a degree of high availability for the Cloudron server.
When I need to resize my server (for increasing CPU, disk space or RAM) or reboot for security updates there is downtime. Additionally, even while migration between Cloudron instances gets good feedback on the forum, an unexpected migration from backup after some sort of failure would incur significant downtime.
I really don't want any downtime and would like some immediate disaster recovery options if the active server was lost, disconnected or corrupted.
It would also be nice to know they system could handle increased strain if needed or have the ability to scale up over time rather than having a single server with ever increasing specs (RAM, CPU, Disk) to handle more applications / more traffic.
It would be amazing if Cloudron had some high availability features that could include:
- Ability to use floating IPs
- Load balancing
- Hot backup / stand by server
- Ability to connect to managed databases for backend data?
- Ability to scale based on the number of applications running / resources needed - adding additional Cloudron nodes?
I know these are all very complex features and I'm not even sure if its possible at all given the way Cloudron works but I was interested to know your thoughts if this had been discussed or touched on your roadmap?
I'm no expert on the above so apologies in advance, I know I'm covering quite a lot here!
-
Subscriber sign up mail issue for Ghost 3.0 instances on a sub domainSeems to be an issue with a Ghost 3.0 instance sending subscriber magic link emails to users when signing up on a Ghost instance on a Cloudron sub domain. Ghost assumes the domain it should be sending from should include the sub domain e.g. noreply@demo.mydomain.com, when the blog is at https://demo.mydomain.com.
The sign up form returns "Please enter a valid email address!" but the logs show the following:
"Failed to send email. Reason: Mail from command failed - 550 Authenticated user demo.app@mydomain.com cannot send mail as noreply@demo.mydomain.com."
Having Email Masquerading enabled for mydomain.com doesn't make any difference. Sending a test email from the Ghost UI works fine as the email comes from demo.app@mydomain.com and I'm guessing doesn't encounter the authentication error.
The Ghost UI doesn't offer the ability to alter the domain part of the sending email address. Is this something that can be modified within the Ghost package for updating / new installations? Also what would be the best temporary solution?
-
Ghost 3.0Awesome, many thanks for your quick work on this.
-
Ghost 3.0@girish sure I'm based in the UK so let me when would be convenient for you and I'll do my best.
-
Ghost 3.0We use Cloudron as an interface and system to manage Ghost blog installations. Given the release of a new version we are being chased by our customers as to when we will be upgrading them to v3. I appreciate any major upgrades need to be carefully planned & tested but just thought I would bump this thread as an update to have Ghost v3 (even as a separate app for now) is a priority for us. Thanks.