Production channel removal

TrinityDan · November 21, 2019, 11:42pm

I agree. It’s not a good look at all. Just more bait and switch from Nextcloud.

From the Nextcloud website:
“Enjoy constant improvements from a thriving and transparent, entirely open-source community development model, free of lockins or paywalls.”

Kind of seems like a joke in light of recent changes.

KarlF12 · November 22, 2019, 2:46am

@kesselb Show me someone who runs WSUS for one other Windows server. That isn’t a reasonable solution.

alfred · November 22, 2019, 7:15am

If you can do it, help is always appreciated I think.

gary-kim · November 23, 2019, 3:43pm

@jospoortvliet Any update on this? I think it’d put a lot of people, including me, at ease.
The change of the production channel to an enterprise channel does have some people worried and the ability to basically do the same thing that the production channel allowed would be great.
Also, if this is done, it’d make my planned change to the updater useless so…

Well, it would be nice… Nah, if someone wants it, it’s not a hard patch to write. Would rather at least keep the notification.

tessus · November 24, 2019, 12:01pm

Not necessarily. Being able to specify a version on the command line is a great addition and solves other problems. At one point I was thinking about implementing it myself, but as always I got sucked into other projects.
I’d be happy to collaborate on this. Or did you have something else in mind? e.g. specifying the major version and the updater retrieves the most recent minor update? That would have been my next step (cmdline option)…

kesselb · November 24, 2019, 2:16pm

I think that’s the right place. If you want some flag “dont_send_me_major_updates” thats probably a bit more work to do. The update_server will always return one version. I see two ways:

Pass &dont_send_me_major_updates=1 and only return updates for the same version.
A more generic approach: Return all available updates for this version. This also requires a new parameter &give_me_multi_version_response=1 because old clients don’t know how to parse responses with more than one version.

For 1 and 2 nextcloud/server and nextcloud/updater need some changes to support the new flag properly. At least 3 pull requests to different repositories is probably a tough start

./updater.phar --patchFile=nc17.zip --signatureFile=nc17.sig

As start I would extend the updater to accept a specific patch file and the signature via arguments. So people have full control which version is installed.

I identified url, signature, version and versionstring as mandatory information from the updater_server response (probably they are more).

github.com

nextcloud/updater/blob/96234eb99dd5b887350e63d1b0815a978395bf65/lib/Updater.php#L119-L124


      
          		$response = $this->getUpdateServerResponse();
          
          		$this->silentLog('[info] checkForUpdate() ' . print_r($response, true));
          
          		$version = isset($response['version']) ? $response['version'] : '';
          		$versionString = isset($response['versionstring']) ? $response['versionstring'] : '';

If --patchFile and --signatureFile not empty ~~don’t call $this->getUpdaterServerResponse~~ modify $this->getUpdaterServerResponse to return some information from patchFile. For the version check we need version and versionstring.

github.com

nextcloud/server/blob/cd7af395d7d0442fbe9b87a28345fb70ddd9b7a4/version.php#L32-L35


      
          $OC_Version = array(18, 0, 0, 1);
          
          // The human readable string
          $OC_VersionString = '18.0.0 Alpha';

Use https://www.php.net/manual/en/ziparchive.extractto.php to extract version.php from the patch file and $version = implode('.', $OC_Version); and $versionString = 'Nextcloud ' . $OC_VersionString;

github.com

nextcloud/updater/blob/96234eb99dd5b887350e63d1b0815a978395bf65/lib/Updater.php#L519-L520


      
          		$fp = fopen($storageLocation . basename($response['url']), 'w+');
          		$ch = curl_init($response['url']);

Probably curl will accept something like ‘file://local/path/to/nc17.zip’ or check is $response[‘url’] a path to a local file and copy it to $fp and skip all the curl rest.

github.com

nextcloud/updater/blob/96234eb99dd5b887350e63d1b0815a978395bf65/lib/Updater.php#L601-L602


      
          		$response = $this->getUpdateServerResponse();
          		if(!isset($response['signature'])) {

Paste the content of --signatureFile here.

github.com

nextcloud/updater/blob/master/lib/Updater.php#L440


      
          			// If it is a file copy it
          			if ($fileInfo->isFile()) {
          				$state = copy($fileInfo->getRealPath(), $backupFolderLocation . $fileName);
          				if ($state === false) {
          					$message = sprintf(
          						'Could not copy "%s" to "%s"',
          						$fileInfo->getRealPath(),
          						$backupFolderLocation . $fileName
          					);
          
          					if (is_readable($fileInfo->getRealPath()) === false) {
          						$message = sprintf(
          							'%s. Source %s is not readable',
          							$message,
          							$fileInfo->getRealPath()
          						);
          					}
          
          					if (is_writable($backupFolderLocation . $fileName) === false) {
          						$message = sprintf(
          							'%s. Destination %s is not writable',

This method is probably a good place to add all this --patchFile and --signatureFile logic. If these two arguements are present do something different but also return a array with url, signature, version and versionString.

github.com

nextcloud/updater/blob/master/lib/Updater.php#L140


      
          		$version = isset($response['version']) ? (string)$response['version'] : '';
          		$versionString = isset($response['versionstring']) ? (string)$response['versionstring'] : '';
          
          		if ($version !== '' && $version !== $this->currentVersion) {
          			$this->updateAvailable = true;
          			$releaseChannel = $this->getCurrentReleaseChannel();
          			$updateText = 'Update to ' . htmlentities($versionString) . ' available. (channel: "' . htmlentities($releaseChannel) . '")<br /><span class="light">Following file will be downloaded automatically:</span> <code class="light">' . (string)$response['url'] . '</code>';
          
          			// only show changelog link for stable releases (non-RC & non-beta)
          			if (!preg_match('!(rc|beta)!i', $versionString)) {
          				$changelogURL = $this->getChangelogURL(substr($version, 0, strrpos($version, '.') ?: 0));
          				$updateText .= '<br /><a class="external_link" href="' . $changelogURL . '" target="_blank" rel="noreferrer noopener">Open changelog ↗</a>';
          			}
          		} else {
          			$updateText = 'No update available.';
          		}
          
          		if ($this->updateAvailable && isset($response['autoupdater']) && !($response['autoupdater'] === 1 || $response['autoupdater'] === '1')) {
          			$this->updateAvailable = false;
          
          			$updateText .= '<br />The updater is disabled for this update - please update manually.';

I’m not sure but sometimes autoupdate = false. These seems to be related to outdated php versions: updater_server/config/config.php at 03037e2413dcd4e389652f5dfd571991574733dd · nextcloud-releases/updater_server · GitHub

If people are using the updater with a custom patch file I would ignore this flag for now assuming they know what they are doing

Claude · January 22, 2020, 8:28am

@jospoortvliet I’ve read this tread and I must agree that loosing the Production channel is a bad move.
That’s particularly the case for us, small businesses (5 clients running):

too small to afford your Entreprise plan starting at 50 users
still big enough to not be able to support outages due to unstable updates for the supposed Stable branch.
We are now blocked and without options

This problem is for the server and also for clients. Releases are silent and changelog is hidden and not manageable by admin for client.
(At each update you rolling out several nasty notification and confusing elements making update after updates more and more Nextcloud an adware.
(Seriously what the point advertising on the client connected to a dedicated server for a paid hosted server.))
In the last months I’ve lost a lot of time reverting client updates problems.

Yesterday expecting to fix the HTTP/2 pending issue I’ve updated from Production 16.x to supposed tested and Stable 17.0.2 ( 3,5 months old now)
Result => server down for 3h :

Web Update failed ( back to old times) => needed to move to command line occ:… ( Outage => 1 h)
Unable to access the main page => Check Log => Found the Error source [Undefined variable] (https://github.com/nextcloud/server/issues/19030)
somebody validate an app Metadata for this version without testing it properly since September 30th
=> Disable app ( Outage => 2h and system impaired up to this morning)
Still no solution for HTTP/2 error leaving critical files not synchronised

With the production channel lost, I’m now in fear to be in the first, second or three 10% test random batch in Stable channel.
I hope that your are not going to release silently, on top of that, an automagic update.

It’s seems for some reason NC developers want their product to be a geeky tool for non paying customers.
Even if we are happy to support with the [bounty program] (https://www.bountysource.com/teams/nextcloud) and patches and bug reports

Please just stop making our support difficult by creating new difficulties by removing keys features.

Please also find us a solution to keep a production channel both for server AND clients AND if paid is a requirement an affordable solution for small businesses.

In this last case, we will move both our bounties contribution and support hours to a paid plan. Moving from willing contributors to paying clients is not the same relationship it’s less supportive more requiring. Not sure NC will earn more.

kesselb · January 22, 2020, 10:46am

I see your point and understand the concerns but 1, 2 and 3 would happen with the production channel as well. I don’t see the relation to be honest.

That is just wrong. The faulty version was released at 2020-01-20 and fixed a day later. Bad timing of course.

Claude · January 23, 2020, 2:47pm

I must disagree on these very specific points.

A stable or production version should not create error 500 on update like it was three to four majors version before. Betatest is here for that.
An App validation need to be organised too before being released in the Stable/Production world
That not a bad timing, just a bad process !

kesselb · January 23, 2020, 3:14pm

As said: I understand your concerns. But the issues are not related to production or stable channel. Please don’t hijack this discussion for other things.

An App validation need to be organised too before being released in the Stable/Production world

https://docs.nextcloud.com/server/latest/admin_manual/installation/apps_supported.html

Please create a new topic to share your updater nightmare. Probably there are already threads about that around. But this thread is the wrong place

bpcurse · January 23, 2020, 3:35pm

As this thread is quite long, I hope not to have overlooked something.

@jospoortvliet [As @nachoparker already said] Thank you for keeping cool and handling the discussion professionally.

What about instances running 16.x and still being set to “production”?

We have 16.0.7 running still set to production and as of now no update is offered to 17, although 18 has been released some days ago.

Of course I probably could and will solve this by changing to stable sometime, but does the policy change mean that 16.x set to production will stay on that level indefinitely, or is the update really still pending?

The average user not following the forum threads, github issues or the website will probably not be aware of the change. This might lead to the paradox situation of (many?) instances falling back to an old version level, although their admins wanted a stable and secure system by choosing production and relying on this channel.

EDIT: At least minor version updates are still delivered to “old” production users on 16.x. We have received an update to 16.0.8 (from 16.0.7).

EDIT2: And finally the update to 17.0.3 was offered, too.

amazing-stories-4evr · February 13, 2020, 6:21am

My big objection was the silent push of the production channel into the stable channel without warning.

I agree that there is a need for the production channel.
N+1 beta
N stable
N-1 production

Makes a lot of sense for those of us that can’t afford the 50 user license. Red Hat has a production version (LTS) as well as a stable. So does Fedora.

With production users pushed into stable, we are now at risk without warning. While the enterprise users that have paid for 50+ users licensing have retained the so-called advantages of a production environment.

At the end of the day, either Nextcloud wants to gain paying subscribers by doing the right thing or not.

To me, the minimum right thing is to at least have warned customers that they need to do a manual upgrade to stay on the production/enterprise channel.

You don’t own my installation. So you can’t push me into a different channel without my choosing to do so.

At the very least there should have been a warning. Given the update, there is no way to revert back to 16.0.8 now.

I am now going to remove the update notification because it no longer serves a purpose.

I feel as violated as I did when ownCloud claimed that the WebRTC tech (open source and GPL) would only work in the enterprise version. It’s the DAY I moved to Nextcloud.

How does the guy at the top feel about this reduction of the non-enterprise users to the stable channel? I’d like to hear his opinion. He left ownCloud for the same kind of shenanigans.

amazing-stories-4evr · February 13, 2020, 6:24am

16.0.6 had only one real bug that was back ported in 16.0.7 - the external storage via SMB because a flag was missing.

Production has historically been a lot more stable and doesn’t change as often. That’s the whole point of production. WIth Stable - you constantly have to read the change log. Now that production is gone, I will manually update to the N-1.

Your ruse has not changed the behavior of those that wanted the production channel. You’ve just created friction and a reason for us to NOT purchase a license. It’s not created an impetus for us to get into an enterprise license.

The best way to sell the enterprise license would have been to simply start providing the smaller plans. That would have eased the friction. And would have made us want to buy the license.

kesselb · February 13, 2020, 9:10am

Got a notification because you replied to something I wrote earlier. I’m not able to match anything you wrote to something I wrote. Manual update sounds like a good alternative. Probably even automatable by some shell scripts or a configuration management tool.

tessus · February 13, 2020, 9:22am

That’s hilarious. That’s why there’s an updater app. Brilliant.

JimmyKater · February 13, 2020, 9:40am

@kesselb

just im case you didn’t realize what s/he was referring to just click on your name in the posting…

chrisnc · February 13, 2020, 10:04am

Just my two cents as an admin of a “Family NC instance” on a rather limited shared hosting server with one heavy (DAVx5, Win Thunderbird 60.9.1, NC Win+Android client), one regular (DAVx5, NC Android client) and 2 minor (DAVx5) users: I do not care much about “new” features as long as my FOSS ecosystem regarding Adresses/Contacts, Calendars and file/gallery sync/sharing is working in a reliable and stable way so to avoid closed ecosystems like Google, Apple, Microsoft, etc.
In the frequent updates of at least one of the FOSS ecosystem components I’m now “expecting” that sometimes per year things break and need hours of troubleshooting and fixing (see Tb 60 to 68 disabling Add-Ons I need).
I have to say NC updater worked much finer then previously in OC but still being on production the updates (especially major version) are not a carefree act - I had some issues.
All this said I must say I do not feel very comfortable with the Production channel removal or in other words I will trust update suggestions less now and feel like “non paying” users have less choice/control. Having a FOSS product steered by company employed experts on the one hand is giving confidence but on the other hand often takes away at least the impression the community can influence main strategies and core features.
I know a lot of personal subjective feelings, but as we have seen with OC they matter.

Semjel · February 13, 2020, 3:41pm

Yes, I think the writing is on the wall for the disadvantaging of non-enterprise users, going forward.

One thing that might be worth considering for home users, is using Keycloak Gatekeeper to provide an added layer of security, and make it less critical to update quickly, if the update system is to be made inconvenient. This essentially takes over the job of authentication, and puts your application behind a secure proxy. This makes it far less likely that your private Nextcloud instance could be attacked from the open net.

amazing-stories-4evr · February 13, 2020, 6:23pm

For what it’s worth, my last NC instance only got updated to 16.0.8. I refrained from doing the 17.0.3 because I now know the NC team doesn’t care that I only want production code and it if I want production level code, I have to manage/upgrade it myself. It’s not that big a deal. But still. Kinda sad.

amazing-stories-4evr · February 13, 2020, 7:16pm

Have you considered adding encryption? What does keycloak get me? Why would I want a proxy for home users? I don’t get it.