About Nextcloud issues and RedHat philosophy

Let’s be honest, Nethserver is great as a local SMB server but when it the web applications have a lot of lacks.
While it might be because of the RedHat/CentOS philosophy of keeping the same version over their life cycle (10 years) and/or others reasons the reality is web application don’t last that long and are more rolling version aka Lean development than the OS. Only for the security perspective side, it is unacceptable to keep running application PHP5 simply because RedHat say so.

Let’s be a little bit more tangible, let’s talk about Nextcloud

Nextcloud is a great example, the Nextcloud team pushed periodically new release with improvement such as they abandon support of older version and push harder configuration.

Nextcloud 21

Again Nethserver face a wall partially because of what I describe earlier, it have to upgrade MySQL from 5 to 10 but this goes against RedHat philosophy.

Why not taking this opportunity to move forward and to offer Nextcloud as a container ?

If not, how Nethserver team will figure/fix these issue ?

  • MySQL is used as database but does not support 4-byte characters. To be able to handle 4-byte characters (like emojis) without issues in filenames or comments for example it is recommended to enable the 4-byte support in MySQL. For further details read the documentation page about this.
  • The database is missing some indexes. Due to the fact that adding indexes on big tables could take some time they were not added automatically. By running “occ db:add-missing-indices” those missing indexes could be added manually while the instance keeps running. Once the indexes are added queries to those tables are usually much faster.
  • Missing index “cards_abiduri” in table “oc_cards”.
  • MariaDB version “5.5.68-MariaDB” is used. Nextcloud 21 will no longer support this version and requires MariaDB 10.2 or higher.

Or Nethserver Teams will simply hope people will move to Nethserver 8 before the end of the support of Nextcloud 20 which means a little less than a year (based on the release cycle)

Switching to rh-mariadb103 ?


Do not get me wrong, do understand your point.
Just want to point out RHEL/CentOS releases the software collections exactly for these scenarios.

don’t worry, I don’t get you wrong to have a so easy answer, I just taught, those 3rd parties repos was just available via/with Stephdl-repo and not officially supported by Nethserver. :slight_smile:

Do you think Nethserver Team will fix those errors also ?

1 Like

I can just guess… Time will tell

Nethserver already makes use of some SCL’s. Nextcloud runs on rh-php73 (nethserver-rh-php73-php-fpm) and some modules make use of rh-postgresql12 (nethserver-postgresql12)

They aren’t third-party repos, they’re from RedHat themselves. And as Mark notes, Neth’s implementation of Nextcloud has been using SCLs for a long time now for PHP, so it certainly wouldn’t be much of a departure to start using them for MariaDB. They’re available, they work well, the devs know how they work, and to some extent the users know how they work. I don’t believe we’re going to be on NS8 within a year, and I don’t see the devs moving any apps to containers in NS7.


IMHO NethServer 7 is still not ready for containers.
Current docker implementation is not mature enough to support all usage scenarios.

We can’t overcome this limitation without changing the current MariaDB configuration.
But such can affect other applications.
Honestly, I’m more than happy to leave with current limitation and avoid possible regressions :slight_smile:

Such indexes are not required for all installations. It really depends on the instance usage.
The admin is free to execute the suggested operations.
How could we improve it?

We are already using a not-recommended MariaDB version :slight_smile: It seems that MariaDB 10.2 is the recommended one, but should work even with older releases.
If new releases of NC will not be compatible at all, we will try to switch to a new DB version using SCL.
Just like we did for Mattermost. :wink:


For now containers are viable solution for sysadmin or distributed solution with kubernetees and a lot of skilled people to make them accessible. It will be probably the way for ns8 but for now the goal is to provide a workable solution in one clic, no matter if you know how to build a rpm or not. The complexity must be owned by the developer, never by the end user

I provide some scl rpm that rely on redhat scl, I mean python, mariadb, postgresql, php, some are integrated from time to time in the project. Mattermost is the good example, it was running with postgrsql 9.4 and lastly we migrated to the version 12 IIRC, obviously this has been done without you know what is running under the hood.