Best posts made by scooke

You already have the option to install apps from others in a general sense because of Docker.

I pay for Cloudron not just because it is Docker-based, but because of how easy the devs and admins and owners have made it to use. I think adding unsupported apps to the mix even more will distract from the appeal of Cloudron. The extra apps that are available are there because the app is in the pipeline to being added to the official Cloudron store; they have been/are being worked on by people who like the Cloudron approach and want to add to that, and not to a Docker-experience in general.

The price jump from no-support to support with nethserver is a huge jump from 48€ to 250€! I think Cloudron has a good pricing structure because they have limited what they have to support. To address one of your first points, I left Yunohost exactly because of how many low level quality apps that they have, and all the hassles and problems that approach introduced. I wouldn't want to see Cloudron go that route. I like the line being thick! I am already receiving all that I hope for from Cloudron.

All that being said, I think we already have a pretty good 'community repository' of helpful users and super helpful admins. For anything that I want to do that is beyond what Cloudron offers, I just tinker away on my other VPS.

@nebulon If I understand the dynamics introduced by an open source licence like AGPL, someone having the access to the source code, and in fact having the source code, does not make them a "user" of Cloudron. They simply have the software and can install it and do whatever. But when they have problems, as they surely will because of Docker, where will they turn to? Most likely the original creators of the software... and when you and @girish can't help because of other time constraints, I can imagine the complaints and badmouthing that would follow. This would potentially have the effect of Cloudron (the subscription service) getting a bad name, losing customers, and eventually going out of business. So it makes sense to me that you've tightened up the licence so that the amazing user experience can remain intact and manageable.

I am not an open source purist, starting from the fact that I have no control over the VPS I rent on which I run Cloudron. It is, as someone in your chats said, a compromise for a purist. For the rest of us who don't want to pay an opaque behemoth company anything, Cloudron is simply the best. And it has the open source spirit, if not the correct licence on every bit of code. And importantly, the software actually works, a theme that I've repeated a few times on different threads. I applaud the Cloudron team for making decisions to enable them to keep the software open AND working.

Yes, and no. I followed Digital Ocean tutorials, and others from different sites, and conceptually there was a lot I didn't understand. This was challenging when something broke and I didn't even know what happened. But over time the tuts made more sense, the terminology was sticking, the concepts became clearer, but the amount of work and time needed to maintain and monitor the server didn't decrease much. The new Ghost works really really nice compared to how it started, and if that is all you will have running on the $5 server then you should be fine. Just always make backups of the Ghost app and assume at some point something will go wonky, or you will even get hacked, and learn from the experience. Restore from a backup and get back at it.

On top of the server though you have domain/DNS issues to understand and maintain. This can be tricky too, but over time it all gets clearer.

That said, using Cloudron is such a treat. Because I tinkered around on my own for awhile, I now better understand what Cloudron is doing, and how and why, and so it makes it that much nicer to use. But if you are starting from zero, then it is still a great way to get your Ghost site up and running. You could always familiarize yourself with webserver things locally while using MAMP or LAMP on Linux or...XAMPP (or whatever the windows version is called); and get used to servers locally with VirtualBox or VMWare and spin up an Ubuntu image and use it as a test server.

I will add that using Cloudron to run a Ghost app is advantageous in that you will also have the option for the built-in email server, and the option to install other apps that use Apache rather than nginx, or for that matter, php instead of nodejs; I still find it challenging to run php apps that would usually run well under Apache on an nginx server if the main app is a Ghost app, and vice versa, getting a Ghost app to run under Apache so that the other php apps can remain undisturbed. Cloudron makes this mixing of apps seamless.

I love Cloudron. I love the increasing number of apps offered. But will there eventually be too many for the Cloudron team to manage? I'd hate to see Support quality, or quality in general, decrease just for quantity. If there is to be a limit, how will it be determined? By install number? By usage? By active maintenance by the git repository/project owners (not Cloudron)?

@jdaviescoates I used https://wordpress.org/plugins/all-in-one-wp-migration/, moving a wordpress app from a regular LAMP stack install to my Cloudron, and it went very smoothly. Size of the *.wordpress file was over 500MB but it went well.

You can add as many domains as you need from your Dashboard. Under your username is a dropdown menu (1), and in that you will see an option for Domains & Certs (2), and from there you can enter in a new domain, sometimes using a handy API from a registrar. Of course, you have to have set an A record for the domain(s) you are adding (do this ahead of time for it to work seamlessly).

Or, in the App dashboard, you can simply add a subdomain if you want to keep just one domain. So, mastodon.example.com, or chat.example.com, etc.

Dashboard

Domains

Enter domain name here

@murgero said in "Searching toots by their content is not enabled on this Mastodon server.":

https://relay.mastodon.host/inbox

I've entered the url and was almost immediately listed in the "List of 286 registered and active instances:" Thank you!

My suggestion might be applicable to a few people: I like to try out the various apps available on the Cloudron App Store and often reuse a domain to do so. Currently I have to click on the installed app square, scroll down to Uninstall, which is the 11th option to the left of the info window, Uninstall, then go back to App Store, choose an app, then choose the install Location, and then wait for it to install, then either make a new login or am assigned a new login for that app.

What would be really nice is an 12th option called Switch (or Change, or whatever). While I am in the app window which displays the current domain/location, I could choose Switch, and a mini App Store appears in the box, and I can click on one, and click the blue Switch button. This then would start a process of uninstalling the current app, deleting caches or whatever the normal Uninstall process does, and then automatically installs the new app.

I have no idea how complicated it would be to then also preserve the user info, but if possible, then I could keep using the same email rather than having a new one, and this would also help me keep my password manager tidier - no more multiple copies of sign-in info for the same domain.

If it doesn't or can't happen, I understand. There are probably more pressing upgrades needing to done, and I am a happy Cloudron user anyway. But, this would be super handy for me since I often switch out apps using the same domain.

I have a VPS with 24Gb of RAM. I have 19 apps. When I look at the Graphs the RAM usage is no more than 5 GB. But when I went to add the 20th app (Monica) I received this popup warning:
This Cloudron is running low on resources. Please upgrade to a server instance with more memory. Alternately, free up resources by uninstalling unused applications.
But my Graphs show that I have 20 GB of RAM unused. Is the warning about spikes or something?

Is it taking into account the RAM requirements for each installed app which would total 29.5GB? Is this why I get this warning?

You could install LimeSurvey and give it a try for all of us!

@will I was looking for this actually 30 minutes ago! It is in the lower right of the browser window, the footer of the Cloudron admin window, where you can see the 2020 and Cloudron about centered.

© 2020   Cloudron       Forum                                v5.0.6

@fbartels Super! I'll be there!

@Felix One really nice aspect of the modern Ghost is that backups are done within the app but saved to a place you choose. Restoring from that is just as simple (as long as the domain is the same). I've moved three different Ghost apps from three different servers over the last few years and it always went smoothly. I also use the free tier of cloudinary to host most of the media, so the Ghost backups don't end up huge - there are just links to backup! And it is better than semi-decent, they are exactly what the last backup backed up.

@scooke Actually, what I meant by that first line was that, because of Docker in general, you can boot up another server and try out all the Docker-based apps you want already! I did that. It wasn't always successful. Cloudron appeared, I signed up early, and everything worked, always. It was wonderful. It still is. And my hope is for it to remain wonderful. Adding too much, too soon, too unsupported, will make it a mess like other attempts.

Who know if this is related, but I had backups start failing a little while ago. I turned off a few apps that seemed to be culprits, and narrowed it down by running backups. If it failed, I turned off another app until it succeeded. Then I turned back on those apps to see which would trigger the fail. Long story short, I tracked it down to some images in a Wordpress Uploads directory, deleted those images, added the app back onto the Backup list, and then it worked. If I remember correctly it had something to do with a corrupted jpeg/jpg/JPG/JPEG (the suffixes matter, sometimes). Anyways, it is a hassle but you might have to do similar sleuthing. This is one reason I use another 'cloud-' service, cloudinary.com. The free tier has been perfect.

@alejandrolengua Which service are you using at Mirhosting?

I'll be honest with you, that is one complicated looking Dashboard! I managed to figure out how to generate a plain old Ubuntu 18.04 environment, but on the free trial I can't have an IP4 address. So I will just continue and see how this goes.

Well, I was trying to install Cloudron on both Mirhosting, and Ultime Hosting (france), but both do not provide IP4 addresses for the free trials. And I don't really want to add funds to these either, sorry. But I can say that it is definitively getting stuck at

=> Installing software-properties-common

and tails tells me specifically:

Configuration file '/etc/resolvconf/resolv.conf.d/base'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** base (Y/I/N/O/D/Z) [default=N] ? Y

It just hangs here. EDIT: I spoke too soon, after about 20 minutes it resumed.

It seemed to fail again starting Docker.

storage_driver=$(docker info | grep "Storage Driver" | sed 's/.*: //')
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

I suspect that, according to the Dashboard, the environment I picked was Docker, and then I chose Ubuntu 18, whatever this jelastic is it already installed Docker in this service. Anyway, I ran systemctl start docker and systemctl daemon-reload, in one Terminal window, then reran the cloudron install script, and this time it resumed downloading all the various docker images. So, progress maybe?

EDIT: FINAL UPDATE
There was another fail, during the openjdk install. I wonder, I had to choose 8 "cloudlets" in order to get 1GB of ram for Cloudron, so I wonder if this is affecting the install. It doesn't sound like it is a physical instance, like a KVM VPS, so I suspect it is having trouble connecting everything and making it work. Maybe you should consider a plain old KVM? Good luck.
(The setup before openjdk was nginx, which completed, but there was a warning :

cat: /home/yellowtent/box/VERSION: No such file or directory
==> installer: Updating from  to 5.4.1 <==
==> installer: updating docker
nginx version: nginx/1.18.0
==> installer: installing nginx 1.18

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.):

The final errors:

Setting up openjdk-11-jre-headless:amd64 (11.0.8+10-0ubuntu1~18.04.1) ...
update-alternatives: using /usr/lib/jvm/java-11-openjdk-amd64/bin/rmid to provide /usr/bin/rmid (rmid) in auto mode
update-alternatives: error: error creating symbolic link '/usr/share/man/man1/rmid.1.gz.dpkg-tmp': No such file or directory
dpkg: error processing package openjdk-11-jre-headless:amd64 (--configure):
 installed openjdk-11-jre-headless:amd64 package post-installation script subprocess returned error exit status 2
dpkg: dependency problems prevent configuration of default-jre-headless:
 default-jre-headless depends on openjdk-11-jre-headless; however:
  Package openjdk-11-jre-headless:amd64 is not configured yet.

dpkg: error processing package default-jre-headless (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of ca-certificates-java:
 ca-certificates-java depends on openjdk-11-jre-headless | java8-runtime-headless; however:
  Package openjdk-11-jre-headless:amd64 is not configured yet.
  Package java8-runtime-headless is not installed.
  Package default-jre-headless which provides java8-runtime-headless is not configured yet.
  Package openjdk-11-jre-headless:amd64 which provides java8-runtime-headless is not configured yet.

dpkg: error processing package ca-certificates-java (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 openjdk-11-jre-headless:amd64
 default-jre-headless
 ca-certificates-java
W: --force-yes is deprecated, use one of the options starting with --allow instead.

E: Sub-process /usr/bin/dpkg returned an error code (1)

You can add me too! @scooke@lenote.eu.

I had the same experience but was told I was "wrong"... glad more people are bringing this to attention.

I like this feature of 5.3.1 - Do not count stopped apps for memory use!

@avatar1024 Hi @avatar1024 , I just went through the install process for Jitsi Meet, thinking it would be different/better than Zoom or Kopano. However, I am not convinced it is. A few things: 1) The other users STILL need to download the Jitsi app to connect. I tried on an iPhone 6, an iPad, a Pixel phone, and Chrome on my Mac and every one needed to download the Jitsi app to connect. 1A) the Jitsi app is not intuitive. The user has to enter the full url of the chat not just the room name. 2) The install (self-installed using https://jitsi.org/news/new-tutorial-installing-jitsi-meet-on-your-own-linux-server/) leaves you with a Jitsi server that is wide open to the internet. ANYONE who finds the url can start their own chat. Switching this to a authentication approach is long and convulated and requires installing Proxody and some other apps and making another virtual host using yet another subdomain... reading https://community.jitsi.org/t/easiest-way-to-secure-jitsi-meet/21330/43 led me to think it was "easy" but I did not find it so. 3) the pixel, iPad (2018) and Mac connected fine... the iPhone 6 couldn't maintain a connection and the app crashed every time, so somehow only newer mobiles seem to work.

The only good thing I can say was the base install went fine, using a OpenVZ VPS with 2.5 GB ram. I wish I could say it is easier or better than Zoom or Kopano, but I haven't not found it so. Assuming that Kopano can allow guests to join with just a browser (and not an app like Zoom or Jitsi), and isn't wide open like Jitsi Meet is (without extra extra extra steps), then Kopano might be the dark horse of self-hosted group video chats.