Hetzner Cloud snapshoot can be an additional measure in case of total backup failover, but as @fbartels said, snapshoot could have inconsistent data and generate corrupted instance when recovery-restart.

Snapshotting an instance can be an extreme way to recovery data. Of course, cannot be the first and the right way to make a restore. If you use that feature to make it cheaper I think is not a good way to approach problem.

As @jdaviescoates said, you can purchase a Box from Hetzner and configure an extra backup, mounting CIFS directory. But also this procedure can have some risks in case of a total failover of Hetzner datacenter or connection. Best practice is to use a different provider or datacenter.

(Now I'm testing Wasabi and seems to be fast, stable and reliable, but I'm scared about privacy policy management: maybe for some configuration mistake data directory can be exposed).

Question is: @mikulabc why you want to use Snapshotting feature? To be cheap?

Fixed this for 6.1. https://git.cloudron.io/cloudron/box/-/commit/353369c1e9ffc70a53eeea0cb99019a1b5f98f27

@tamayers This would be nice to have, for sure.

For the most part though, the domain registrar will handle that part of forwarding a full domain to another if you use their own DNS servers, etc. I have done that for a couple of my own domains that I had registered a long time ago for 10 years, but no longer use them so wanted to just forward them to my current ones instead.

It would certainly be convenient for Cloudron admins if Cloudron did this too though. One example I can think of... I have two vanity URLs purchased by two different clients of mine where they want me hosting their email but for the website they want it going to their realtor agency website (for example) which is outside of my control, and would be convenient to set it all in the same space instead of a mix of domain registrar and Cloudron.

Also noted a request for a List view here: https://forum.cloudron.io/topic/3465/dashboard-customize-buttons-on-the-sides-of-apps/4?_=1608519749716

@Mario I actually ran into this myself and had to combine my two private registries into one to work with Cloudron.

@girish Oh, absolutely with a custom app, I mentioned in the original post that I'm going to build my own Wordpress Stack to simply and only add this. But I saw benefit to other user's being able to script something post-update as that's literally the only thing my stack will do differently than the default Wordpress app (I'll have to integrate your updates into my stack manually each time so I still wish there was a way to run an external custom sh script post-installation).

As you can see my custom script simply uses the CLI to upgrade all databases with any new required formatting if and only if any updated Wordpress core or updated plugin require it. When you update from the Cloudron interface, it simply updates all the files and Wordpress has this really annoying tendency to not upgrade the databases post-upgrade invisibly. The script above is the only way to make sure file versions and database versions stay in sync 100% of the time every update.

This becomes nearly unavoidable if you want to support multisite in the future since the problem becomes more convoluted in that installation type so my script detects multisite installations and runs database upgrades accordingly with WP CLI commands or single site only commands if it's a single site.

I actually think the script below should be an optional "automatic upgrade plugin and themes checkbox when updating Wordpress core" option for Wordpress installations as well, here's the WP CLI code for it:

# Plugin updates wp plugin update --all wp plugin update --all --skip-plugins --skip-themes # Theme updates wp theme update --all wp theme update --all --skip-plugins --skip-themes

Indeed this is on our roadmap.

I'd like to add to this. The ability to select the pass length and whether we want special characters. Or if it's easier to do, allow us to add our own passwords instead of them being generated for us.

Adding to this: Maybe it's possible to implement a backup browser via the file browser, at least for the rsync format and even for encrypted backups?

@robi @girish thanks, I figured it might be something like that as I think it was just after a reboot that I noticed they had disappeared.

@jdaviescoates nope, just regular domains, not sure why but will just wait and see I guess

Just to follow up, here's a sample of normal backups followed by a Cloudron upgrade, which itself triggered another backup run, and the corresponding relevant network and disk graphs:

Network Traffic.png Disk I_O.png

All in all, it's definitely fast-er but not insanely performant. CPU utilization vs load hints that it may in fact be down to inefficient utilization of cores to some extent, but there is definitely a fair bit more bottleneck coming from the network still.

CPU Utilization.png CPU Load.png

Nothing earth-shattering either way, and gains were more mild than I would have guessed, but all in all, not a bad outcome.

@robi Yes, more checks to keep the mounting "alive".

@fbartels We can always have a simple runner page preload indicating the rehydration of the app and how to avoid it.

Gamify it a bit..

Indeed, I have add a Media section now for next release.

+1 I often forget where Stop and Restart are found!

And it doesn't make sense to me that they are found in different places

Stop is hidden in Uninstall
Restart is in Repair

@nebulon Ahh okay that makes it clearer why this style was chosen.

I can live with that explanation. 👍

@nebulon Great guys! You're doing amazing !!!

@d19dotca said in UX Change for App Automatic Updates:

If "Updates are checked for everyday", then why would the text on the page read "If you disable automatic updates, be sure to manually check for updates."?

I changed this a bit to "Cloudron periodically checks the App Store for updates. If you disable automatic updates, be sure to manually apply the updates."

@jdaviescoates said in During restoring app: Cloudron page is showed:

Could we consider this a feature request to that effect?

Yes, that's what this feature request is 🙂 either make it customizable or merge it with the existing one.

@girish Great! @jdaviescoates 👍

@humptydumpty Not got a referral link and I tend to avoid using them on forums and tweets etc as I want to make sure my pointers are untainted but maybe an idea to load up the profile text with them for people that want to use them as a free beer sharing.

I have a few referral links on my website for those that might find but then I still need to do a bit more work on the declaration text part of that. The new Ghost snippets feature will make that and other common text a lot easier to do as time goes by.

I'm my own worst critic for writing though, so like to write and review several times over a long time period before I make something a standard text I'm happy with. Damn, this time-saving internet technology lark doesn't half take a lot of time! 😂

To add to what @subven said, there is also https://www.cloudron.io/appstatus.html which gives the latest version and update timeline.

Having this be a sticky default setting would be great..

@nebulon thought that might've been it, thanks 🙂

I believe @Lonk 's VPN project may be helpful here as VPNs track their packets much more so than general network interfaces which could provide for greater visibility for any app by simply adding it to the VPN profile & data path.

Until @girish gets a more general solution in for all of Cloudron and perhaps containers in general.

My wording isn't quite correct, it's not full VMs. See below.

https://blog.nestybox.com/2019/09/13/system-containers.html

A Nestybox system container is an enhanced Docker container, designed to package not just applications but also low-level system software.

What type of system software are we talking about? Currently Systemd and Docker, but in the near future software such as Kubernetes, graphical display servers, and others.

The following figure illustrates the difference.

But can’t you do this on a regular Docker container? No you can’t. Not properly.

For example, in order to run Docker inside a regular container (i.e., Docker-in-Docker) you need to run the container in “privileged” mode. This significantly weakens isolation between the container and the underlying host, posing a strong security risk (especially if you don’t trust the workloads running inside the container).

But in some cases even privileged mode is not sufficient. For example, some system level programs read resource consumption information from the kernel (e.g., via the Linux /proc directory). In order for the program to work properly inside a container, such information must be provided relative to the resources assigned to the container itself, not the resources of the underlying host. A regular container does not do this, even when running in privileged mode.

Nestybox system containers are designed to solve these problems.

We can summarize the key properties of a Nestybox system container as:

Runs low-level system workloads (as well as applications).

Provides strong isolation from the underlying host.

Presents a more complete abstraction of a virtual host to its workloads.

Typically runs multiple applications within it (rather than just one app).

One way to look at it is that a regular container packages applications. In contrast, a Nestybox system container packages virtual host environments capable of running applications as well as system-level workloads.
See it work!

Use Cases

But why would you want to run such system-level software inside a container in the first place? I.e., Why do we need system containers?

There are several use cases.

For example, by virtue of running Docker inside the container (securely), the system container can be used for:

CI/CD pipelines (where the need for a container to run another container arises).

Docker sandboxing (e.g., to run multiple Docker instances with total isolation between them).

Our blog site contains articles with practical examples of such use cases.

In the near future, as we add support for more system-level workloads inside the system container, more use cases will open up.

In general, if you have a need for a virtual host that runs many of the same workloads that you could run on a VM, yet is faster and more efficient, then a Nestybox system container is a good fit.

Key Features and Benefits

Deployment with Docker (and Kubernetes)

This allows you to leverage the power of these amazing tools to build, deploy, and manage system containers. No need to learn new tools.

Fast & Efficient

Just like regular application containers.

Strong Container Isolation

Nestybox system containers always use the Linux user namespace.

This means the root user in the system container has full capabilities inside the system container, but none outside of it.

In addition, Nestybox system containers use exclusive Linux user namespace user-ID and group-ID mappings for each system container.

If a process inside the container escapes the container sandbox, it will find itself without privileges to access resources of the host or of other containers.
Image Flexibility

A Nestybox system container image can be created with Docker, just like any Docker container.

However, it typically is configured with an environment resembling a virtual host (e.g., process manager, multiple apps, docker, app containers, graphical display server, etc), although you can also configure it with a single system-level application (e.g., Docker) if you wish. It’s up to you to choose what’s in the image and the entry-point.
Portability

You can deploy Nestybox system containers on any Linux machine, whether it’s bare-metal, a local VM, or a cloud VM, in a data-center, your laptop, an edge device, or even an IoT device.

And as with any Docker container you have the flexibility to move the system container around as you wish. Just upload it to your repo and deploy it on the target machine with Docker.
Partially virtualized procfs

In Nestybox system containers, portions of the Linux procfs (/proc) are virtualized. The goal is to make the system container more closely resemble a real host or VM. For example, the /proc/uptime file returns the container’s uptime, not the underlying host’s uptime.

How does it work?

Nestybox system containers are made possible by Sysbox, our system container runtime.

Sysbox is software that installs on the Linux host machine, integrates with Docker (and soon Kubernetes), and works under the covers.

Users interact with Docker to create the system container image and deploy it, just as with application containers. The difference is that this image can now include system-level software such as Docker itself (for Docker-in-Docker), etc.

The following figure illustrates this.

Running the system container is simple, it only requires passing the --runtime=sysbox-runc flag to Docker:

$ docker run --runtime=sysbox-runc -it my-syscont-image

Under the covers, Sysbox takes care of setting up the system container abstraction so that it can properly run system level workloads.

It’s easy. And you avoid the need for unsecure privileged containers or complex container configurations.

Is it a VM?

No, it’s not. It’s an enhanced container. As with all containers, it uses OS-level virtualization and shares the Linux kernel with the rest of the system. In contrast, VMs use hardware-level virtualization (i.e., emulate hardware in software) and have a dedicated OS per VM.

The following figure illustrates the differences.

This gives system containers and VMs different properties. In particular system containers are faster, more efficient, and more portable (see above) but offer a lesser degree of isolation from the underlying host.

From a workload perspective however, Nestybox is working to make our system containers support as many workloads as VMs can run such that they can present a viable alternative to VMs in some scenarios.

@mehdi said in Ability to modify server name used for SFTP access to avoid use of Cloudron's my.<domain>.<tld>:

the prompt that everybody confirms without even reading

haha, so true. Yeah I got a pop-up that was like "This is a new key" or something and just accepted it. Basically the same kind of message that happens with SSH. I just have certificate-based SSH though where it needs my key to even connect (i.e. you couldn't connect to my server over SSH without it), so I was surprised I didn't need that on my SFTP connection, thought I'd maybe need something similar. But I guess this makes sense then the more I think about it. Just caught me off guard. haha.

@ianhyzy I registered a new domain just for this purpose. It's not ideal but I don't have to use a relay so it works out in the end. I'm hosting with DigitalOcean so the PTR record is set by changing the server (droplet) name to match the mail server domain. Last I checked my headers, all were good and pointing to the new domain setup.

Edit: BTW, I've used Amazon SES for my newsletters in the past and they're pretty cheap. IIRC, I sent like 9k emails for under $1 USD.