I've tried out HomelabOS and agree with @jdaviescoates assessment. Installation of apps on Cloudron is smoother, especially considering some features such as email and user/group management are ready for use. Installing apps, setting scheduled backups and mounting volumes from the UI is also a nice touch. For HomelabOS, I believe the installation of apps and other HomelabOS-specific functions are done through the command line, which may not appeal to everyone.

However, HomeLabOS has its advantages in the sense that there are some apps on HomeLabOS which are not available on Cloudron (e.g. Miniflux), so it also depends on your requirements - does HomelabOS or Cloudron have the app you want?.

Both are very active projects and have made lots of improvements over the past few months, and I made the decision to go with Cloudron.

@robi I'm installing this on Nexus Bytes' vDedi (Singapore location) and using their official Ubuntu 20.04 image.

I created the file using touch /var/log/journal/*/system.journal and ran ./cloudron-setup again and it's all good.

Thanks for the quick fix, and Merry Christmas.

Based on their roadmap, it appears that there are two new features in the works:

1. Integrating with self-hosted GitHub Actions runners,
2. Storing and managing personal/organisation secrets.

Looking forward to the 1.15 release!

I use RStudio for spatial data analysis, dashboard creation, and generating reports. Would be nice to see it on Cloudron.

Trying to install Cloudron on a fresh Ubuntu 20.04 server before migrating my existing Cloudron over.

Unfortunately, Cloudron failed to install.

Installing software-properties-common
=> Updating apt and installing script dependencies
=> Checking version
=> Downloading version 6.0.1 ...
=> Installing base dependencies and downloading docker images (this takes some time) ...
=> Installing version 6.0.1 (this takes some time) ...
Failed to install cloudron. See /var/log/cloudron-setup.log for details

The cloudron-setup.log shows the following:

==> Ensuring directories
==> Configuring journald
setfacl: /var/log/journal/*/system.journal: No such file or directory

@scooke Let's go through each question.

How in the world would someone find this domain, to begin with. And secondly, why would someone use/send my domain when they don't have access?

Email addresses are like addresses for physical mail; as long as you know what the address is, and the address is valid, the mail will be delivered.

The email was spam, so was some bot simply trawling for domains and then adding various names to it to make an email, hoping it gets to someone real?

Or, in another case, someone else signed up for some financial services, but used my domain??!! Why would they do that? So i'm getting their emails.

Depending on the content of the email, it can be either of the two cases you mentioned. Why would someone sign up for something using your domain? Maybe they thought of using yours as a "disposable email address" or they got blacklisted from using their own and had to use someone else's.

I've considered blocking them, or sending them to Junk, BUT, wouldn't this be hurting myself? If I say mail from my own domain, or to my own domain, is spam, won't my overall email deliverability get affected?

Overall email deliverability will be affected if you send spam, not receive it. So I don't think marking those emails sent to your domain will affect it.

Based on their roadmap, it appears that there are two new features in the works:

1. Integrating with self-hosted GitHub Actions runners,
2. Storing and managing personal/organisation secrets.

Looking forward to the 1.15 release!

@girish Thanks for the answer. Having one and only one environment per user is quite the inconvenience

@scooke Let's go through each question.

How in the world would someone find this domain, to begin with. And secondly, why would someone use/send my domain when they don't have access?

Email addresses are like addresses for physical mail; as long as you know what the address is, and the address is valid, the mail will be delivered.

The email was spam, so was some bot simply trawling for domains and then adding various names to it to make an email, hoping it gets to someone real?

Or, in another case, someone else signed up for some financial services, but used my domain??!! Why would they do that? So i'm getting their emails.

Depending on the content of the email, it can be either of the two cases you mentioned. Why would someone sign up for something using your domain? Maybe they thought of using yours as a "disposable email address" or they got blacklisted from using their own and had to use someone else's.

I've considered blocking them, or sending them to Junk, BUT, wouldn't this be hurting myself? If I say mail from my own domain, or to my own domain, is spam, won't my overall email deliverability get affected?

Overall email deliverability will be affected if you send spam, not receive it. So I don't think marking those emails sent to your domain will affect it.

@girish I see.

From what I understand, each user has a virtual environment of their own. Each user can install their own packages using the notebook itself, and not the terminal.

That means that if a user were to have multiple virtual environments, then I would need to set it up using ipykernel via the notebook too?

@robi I'm not able to install them because they still want to install it in the read-only directories for the base env. If I create an virtual environment using venv, I also won't be able to choose it as the kernel since there is no root system access.

Not sure if I'm missing something.

Is it possible to install external python libraries using pip via the terminal?

There seems to be an issue with installing Alltube v1.6.4. I get the following error:

An error occurred during the install operation: Nginx Error: Error reloading nginx: reload exited with code 1 signal null

I tried installing this on another Cloudron server and encountered the same error message, so it should be an app-specific issue, since other apps can still be installed successfully. Reloading nginx doesn't seem to help since it's a config issue.

Error logs for more info:

box:shell reload (stdout): nginx: [emerg] location "!/extractors" is outside location "/" in /etc/nginx/applications/<app-container>.conf:163

box:shell reload code: 1, signal: null

box:apptask <subdomain.domain.tld> error installing app: BoxError: Error reloading nginx: reload exited with code 1 signal null

box:apptask <subdomain.domain.tld> updating app with values: {"installationState":"error","error":{"message":"Error reloading nginx: reload exited with code 1 signal null","reason":"Nginx Error","taskId":"169","installationState":"pending_install"}}

@atrilahiji I might be wrong about this but I think port 53 needs to be used to resolve DNS, and since @robi mentioned that he installed it on a business VPS it has to be publicly accessible for it to function. If it were a homelab would this be less of an issue?

@nebulon Probably not anytime soon. Nexus Bytes' minimum billing period is monthly, and I usually wait to see if they offer discounts before getting one.

@robi I'm installing this on Nexus Bytes' vDedi (Singapore location) and using their official Ubuntu 20.04 image.

I created the file using touch /var/log/journal/*/system.journal and ran ./cloudron-setup again and it's all good.

Thanks for the quick fix, and Merry Christmas.