Linux packages status

[koalillo]

@bb77

Why not just setup a LAMP or LEMP Stack and using the zip or tarball from here?

Because that is a more complex installation and update process. The RPM installs and updates dependencies automatically.

Also, I already have RPM updates automated (and there’s very nice tooling around RPM updates available, if needed- such as setting RPM repositories for testing and production with staggered updates).

Or if it needs to be pre-packaged you could use Docker, Nextcloud AIO or the Snap Package.

The Nextcloud official Docker AIO image has a bit of unconventional behavior, which for example, makes it hard to run with Podman. I also run Nextcloud currently on LXC, and running Docker nested inside LXC is still not friction-free. A VM is heavier on resources than LXC. Snaps, I’m not fond of those.

Distro-specific packages of the Nextcloud server, whether created by third parties or by official maintainers of the distro, in my experience always cause some kind of problems sooner or later, and then you have exactly the hassle you have now

Well, I’ve used Nextcloud and ownCloud from RPMs for a long time, and it’s been great. For some time, ownCloud RPMs were official, and for a while there were nice EPEL RPMs. With the .tar.gz install, I always had to find a way to monitor updates and apply them, while with RPMs, I had it all automated very easily.

When you run Nextcloud using LAMP on a RPM distro, you already need to configure and update RPMs- if Nextcloud is an RPM, things are more uniform and simple.

I’m a bit “sad” because Nextcloud is a hugely popular self-hosted service, and having well-supported packages (even if it was not for EL) would make things easier for a significant set of users.

I actually even contacted the Nextcloud company asking about their enterprise offering, because I suspect they have packages for that…

[bb77]

@koalillo

Because that is a more complex installation and update process.

Yes, as long as everything works as expected.

I’m from the Debian / Ubuntu side, so I don’t really know EPEL and REMI. But afaik you should be able to install any PHP version on any RHEL version from these repos, similar to the Sury repos on Debian / Ubuntu, Also, Postgres and MariaDB offer repos for all supported RHEL versions. After installing that you can use the Nextcloud docs that provides all the relevant configuration parameters for small to medium sized installation.

This will make you independent from the package maintainers of your distribution regarding the application itself and all relevant dependencies.

@koalillo

The Nextcloud official Docker AIO image has a bit of unconventional behavior, which for example, makes it hard to run with Podman

Well, install Docker then, and use a VM instead of LXC. Nested containerization is another one of those things that screams trouble.

And again, why not spend the time to build your own LAMP stack, e.g. in a LXC container, and actualy learn something about the actual software you are running, instead of fighting with infarstructure services, to get it deployed…

[koalillo]

@bb77

@koalillo

Because that is a more complex installation and update process.

Yes, as long as everything works as expected.

Well, my experience has been positive, esp. when the RPMs were officially supported. But even maintaining the packages myself was good.

I’m from the Debian / Ubuntu side, so I don’t really know EPEL and REMI. But afaik you should be able to install any PHP version on any RHEL version similar to the Sury repos on Debian / Ubuntu with these repos. Also, Postgres and MariaDB offer repos for all supported RHEL versions. After installing all of that you can use the Nextcloud docs that has all the relevant configuration parameters for small to medium sized installation.

Yes, I already have this running. But then, installing the packages is dnf install, that replaces many steps in the Nextcloud installation steps.

This will make you independent from the package maintainers of your distribution regarding the application itself and all relevant dependencies.

But that is subjective. Do you install your database and web server from source to “make yourself independent from the package maintainers”? Likely not, because it is damn convenient to install the database and the web server from the distribution packages. Ideally, Nextcloud should be installed in the same quay.

@koalillo

The Nextcloud official Docker AIO image has a bit of unconventional behavior, which for example, makes it hard to run with Podman

Well, install Docker then, and use a VM instead of LXC. Nested containerization is another one of those things that screams trouble.

Yes, that is an option. But VMs are heavier, harder to manage, etc. than LXC containers.

And again, why not spend the time to build your own LAMP stack, e.g. in a LXC container, and actualy learn something about the actual software you are running, instead of fighting with infarstructure services, in order to get them deployed

Or why not have a package and be able to focus on even more interesting things?

(I’ve actually also learned from maintaining my Nextcloud packages… Learning about packaging is more generic and useful, IMHO, than learning about the intricacies specific to Nextcloud.)

[koalillo]

Also, btw, I did run Nextcloud for a good while using the archive, decompressing it to htdocs, etc., so I already learned how to do that. As soon as I had a package, I switched.

This is mostly because I manage all my systems with infra as code- installing a package is much easier to automate than most other procedures.

[bb77]

@koalillo

Yes, I already have this running. But then, installing the packages is dnf install, that replaces many steps in the Nextcloud installation steps.

I don’t get it. There are no installation steps regarding nextcloud. You put it to your webroot and then there are PHP scripts that take care of the initial installation and of upgrades. All you have to to is to keep the dependencies up to date, (that’s where the EPEL / REMI repos and the vendor repos from Postgres or MariaDB come into play) and tune them a little (the Nextcloud Docs part).

@koalillo

But that is subjective. Do you install your database and web server from source to “make yourself

You don’t install it from source, you’re installing it from the EPEL / REMI repos and the respective vendor repos.

@koalillo

Yes, that is an option. But VMs are heavier, harder to manage, etc. than LXC containers.

That’s not necessarely true. Just use one VM for AIO and you can still use LXCs for other stuff… At the end, there will be as much HW resources used as needed by the application you’re running. So, unless you are e.g sharing a MaraiDB container with multiple apps you don’t have that much of an adavantage when you put all your apps in LXCs, especially if you deploy a complete Docker / Podman stack like AIO. that comes with its own dedictaed database, websever and a ton of other stuff…

[koalillo]

@bb77

I don’t get it. Thre are no installation steps regarding nextcloud. You put it in your webroot and then there are PHP scripts that take care of the initial installation and of upgrades. All you have to to ist to keep the dependencies up to date, and that’s where the EPEL / REMI repos and the vendor repos from Postgres or MariaDB come into play.

Yes, there are. You must download the archive, extract it, and run the install steps. These steps do not exist with a package.

You don’t install it from source, you’re installing it from the EPEL / REMI repos and the respective vendor repos.

Exactly. What’s the reason for doing this for your web server/database/etc., but not do it for Nextcloud?

@koalillo

Yes, that is an option. But VMs are heavier, harder to manage, etc. than LXC containers.

That’s not necessarely true. Just use one VM for AIO and you can still use LXCs for other stuff… At the end, there will be as much HW resources used as needed by the application you’re running. So, unless you are e.g sharing a MaraiDB container with multiple apps you don’t have that much of an adavantage when you put all your apps in LXCs, especially if you deploy a complete Docker / Podman stack like AIO. that comes with their own dedictaed database, websever and a ton of other stuff…

So yes, I’m running a VM, when I could be running a lighter LXC container.

[bb77]

@koalillo

Exactly. What’s the reason for doing this for your web server/database/etc., but not do it for Nextcloud?

Ask the maintainers of the respective repo.

[bb77]

@koalillo

So yes, I’m running a VM, when I could be running a lighter LXC container.

It’s not per se lighter (or let’s say it’s more complicated than that, or even better, let’s say, “it depends”

However, at the end of the day, if a process is running that wants to consume a certain amount of RAM or CPU time it will consume that (if you let it) regardles whether it is running in a VM or a container.

In contrast, hypervisors do not strictly use the amount RAM you allocate to them. They use as much as the processes in the VM need, within the maximum you have allocated to the VM. KVM/QEMU is very efficient and configurable these days…

[koalillo]

@bb77

@koalillo

Exactly. What’s the reason for doing this for your web server/database/etc., but not do it for Nextcloud?

Ask the maintainers of the respective repo.

Yes, this is why started talking again in this thread, and I’ve resumed my experiments with the Fedora package on EL (actually, I just bootstrapped an EL9 host, in a fully automated way, and got to the installation setup page using my COPR).

Unfortunately, due to EL9 not having a suitable PHP version (actually, EL9 has php 8.0, which should work- but it doesn’t, there’s an issue with a regex function), getting a package into even EPEL is impossible. But third-party repos are a thing. ownCloud used to provide one! However, at this point it’s either me, the Remi repo maintainers, or Nextcloud… and I think it’s going to be me.

It’s not per se lighter (or let’s say it’s more complicated than that, or even better, let’s say, “it depends”

However, at the end of the day, if a process is running that wants to consume a certain amount of RAM or CPU time it will consume that (if you let it) regardles whether it is running in a VM or a container.

In contrast, hypervisors do not strictly use the amount RAM you allocate to them. They use as much as the processes in the VM need, within the maximum you have allocated to the VM. KVM/QEMU is very efficient and configurable these days…

LXC is lighter, unequivocally. I’m aware of memory ballooning, and I have some knowledge about how the kernel manages memory. I even run a few VMs when I absolutely must (right now, I run two Kubernetes clusters too). But a VM must emulate the hardware, run a kernel… while LXC doesn’t, so it’s undeniable lighter.

But it’s not a matter of only being lighter (it’s perceivable, but I could live with it). It’s also I already have automation to bootstrap LXC hosts that works very well, and is pretty simple. Bootstrapping VMs, even with cloud-init, is IMHO more complex. Plus, using LXC under Proxmox, I can use a ZFS volume for the Nextcloud data directory. This means it’s nicer to backup using ZFS send/recv, and a few other niceties.

I’m not trying to convince everyone to jump ship to Proxmox/LXC/ZFS + EL + RPM packages to install Nextcloud. I’m just saying it has some very nice advantages, and advertise I’m working on an RPM (in hopes of getting some traction). Others might find other options more convenient for their purposes, of course. I just explained why I prefer this option, and how the advantages of Docker/AIO/etc. do not work well for my purposes- if they work for others, that’s great!

[bb77]

@koalillo

I’m not trying to convince everyone to jump ship to Proxmox/LXC/ZFS

I’m not trying to convince anyone of anything either, I just wanted to show alternatives, and btw. I use Proxmox (and Nextcloud on a classic LAMP Stack in a VM). But the whole discussion has gone quite offtopic and I don’t think it makes sense to continue it here

At the end of the day it’s relatively simple:

The following is released and maintained officially by the Nextcloud GmbH:

Server:

• Zip and Tarball (download.nextcloud.com)
• Nextcloud-AIO

Client:

• AppImage

Everything else is released and maintained by various community projects / repos and / or Linux distributions.

[koalillo]

The title of this thread is “Linux packages status”, and was started by a moderator, including references to (third party) packages to install the server. So I think discussing third party packages to install the server is likely on-topic- which is what I tried to discuss. Whether trying to convince people to not use third party packages to install the server is on-topic or not, really I don’t know (I’m not being sarcastic. I have acknowledged myself that other installation means might work better).

[bb77]

Sure we can discuss it here, and that’s what we did However, any issues that exist with these packages can only be solved by the maintainers of the respective packages.

Also, it will be quite difficult to find help here for these packages, because as far as I can see, most people here are using Docker or a manual installation on a LAMP/LEMP stack. The third most used is probably still NextcloudPi, which will likely be surpassed by AIO soon.

And sure, If RHEL, Fedora, Arch or any other Linux distro wants to package Nextcloud they can of course do so…

…however, if I do a dnf list nextcloud on my Fedora Laptop I get the following:

nextcloud.noarch                      25.0.3-1.fc38                       fedora

So if the package in RHEL is as outdated as in Fedora, I wouldn’t use it for that reason alone.

Also the thread is from March 2017 and last edited in 2020, so I’m not sure how relevant it is in 2023, where even Desktop Disributions start to package certain applications exclusively in container formats like Flatpak or Snap…