Linux packages status

Because itā€™s the only package that is currently maintained by Nextcloud. Most of the other, distro-specific packages and repositories were always built and maintained by third parties. They were just mentioned more prominently on the old website, a few of them even with direct links to the respective repos, while the new website only links to this forum post.

Probably not as much the development itself, but building packages and maintaining repos for every possible distribution would be a huge amount of work.

This is entirely up to you.

The advantage of the PPA over the packages in the Ubuntu repositories is, that you always get the latest version, at least if you are on the latest LTS release of Ubuntu, while the package in the Ubuntu repos never changes during the life time of a specific Ubuntu release.

The advantage of the AppImage is that it is completely independent from the underlying distro, and therefore also from the distroā€™s release-cycles. You can always use the latest version even if you are still on Ubuntu 18.04. But it also has a few disadvantages, which you have already mentioned, like e.g. limited integration with Nautilusā€¦

1 Like

About the appimage ā€œlimited integration with Nautilus,ā€ is that the reason the appimage silently quits shortly after starting and never restarts? And if youā€™re familiar with this issue, is there any way to fix this? When the appimage stops running and syncing changes, It completely obviates the whole reason I use Nextcloud, which is to provide cloud access to files. When it isnā€™t running, I cannot remotely access my most recent files and changes.

By ā€œNautilus integrationā€, I mean the context menu for file sharing and the sync status icons in the file manager. Using the Synchronization Client ā€” Nextcloud Client Manual 3.11.0 documentation AFAIK, these are not included in the AppImage.

I donā€™t think so. The actual file synchronization should still work, even without the ā€œNautilus integrationā€.

Unfortunately, Iā€™m not, since I never used it myself. Also, I donā€™t have much experience with AppImages in general.

1 Like

Thank you for the reply! I posted about the issue Iā€™m having, but so far I have not received any response. I noticed other posts about appimage issues have also been left languishing. Iā€™m worried that Iā€™m just stuck with something that prevents me from using Nextcloud as intended, which makes me wonder why Iā€™m paying for hosted space that is just sitting there without being used (since the defective appimage renders Nextcloud useless to me).

Donā€™t use the appimage , use the nextcloud from your distro package manager

2 Likes

:arrow_up: This! :arrow_up:

Respectively, there is a PPA for Ubuntu:

https://help.nextcloud.com/t/updated-more-detail-linux-appimage-quits-after-sync-and-must-be-restarted-manually-to-sync-any-changes-how-to-fix/153711/2

2 Likes

Thanks , but setting a PPA needs command line or complex copy paste , not acceptable for professional. We need a click and install way

Youā€™re kidding, right? :wink:

Btw, you can add PPAs via GUI: How to Add or Remove PPA in Ubuntu Using GUI and Terminal

I wouldnā€™t say this process is easier, though :wink:

Tell a client he needs to do that to use your nextcloud hosting and you will see his reaction.

Then you do it for the customer, or you could write a guide.

Sure, you could also use the package from the Ubuntu repos, which I would not recommend, especially if you are using Ubuntu LTS. The package nextcloud-desktop is in the Universe repos and these packages never get any updates. Neither security nor bug fixes and certainly no feature updates.

This solved the problem! Thank you so much!

2 Likes

In case anyone wanders here and Iā€™m luckyā€¦

Iā€™m looking to migrate my NextCloud from EL8 to EL9. I just did an experiment rebuilding the NextCloud Fedora RPM directly on COPRā€¦ and it worked OOB! However, NextCloud requires newer versions of PHP than what EL8 and EL9 haveā€¦ but! It works with the Remi newer PHP packages (php:remi-8.2 works on EL9, and Iā€™ve been doing a similar build with php:remi-8.0 on EL8 that also works).

Hereā€™s the COPR:

https://copr.fedorainfracloud.org/coprs/koalillo/nextcloud-test/

Iā€™ve posted in the Remi forum to see if thereā€™s any possibility to add them to the Remi repos themselves (I think itā€™s impossible to get them into EPEL, due to depending on Remi):

ā€¦

Is anyone interested in working on this? I think itā€™s pretty interesting because the Fedora packages seem to be well-maintained, with frequent updatesā€¦ And itā€™s quite nice to run NextCloud on EL as a package.

Cheers,

Ɓlex

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

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

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 :wink:

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).

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.

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ā€¦

Yes, as long as everything works as expected. :wink:

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.

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ā€¦ :wink:

1 Like

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

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

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.

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

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.)

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.

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).

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

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ā€¦

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

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

So yes, Iā€™m running a VM, when I could be running a lighter LXC container.

Ask the maintainers of the respective repo.