Update from NC14 to NC15

🚧 Installation
1

I have been troubled with updates for a long time.

Update failed for each app.

I downloaded the source separately and copied the app data from there to deal with the problem.
What I care about is “user_external”. Including this will cause “occ upgrade” to fail.
I directly manipulated MySQL data and disable “user_external”, the updating process was completed.

After that I accessed Nextcloud 15 and confirmed the status of app. Some grayed out.
user_external, I think that this was an external storage configuration application. Although it is invalidated, it is connected to the storage of the external server. Was this function built into the standard function of NC15? Is the application being grayed out probably incompatible with NC15? Or are they graying out with problems?

Database repair

The verification function in the overview item of Nextcloud pointed out the repair of the following database table.

occ db:add-missing-indices
occ db:convert-filecache-bigint

Was this a problem with my DB? Or was it a process that should be carried out automatically by “occ upgrade”?

Manual update

I have been using Nextcloud from NC10, but never have been successfully updated automatically. I am constantly updating the manual. Please check the manual update procedure.

  1. Delete(move) from old NC except data and config directory.
  2. Move from the new NC data other than the config directory.
  3. Retrieve apps not in the new NC’s app directory from the old NC’s app directory.
  4. Adjust permissions.

I wrote simply, but I am unknown in the app directory.
Is this operation correct? Application data is stored in MySQL. Should I install the added applications from the NC application menu?

Nginx config

I have been warned from NC to set “Referrer-Policy”. But it was set from the time of NC14 and there was no warning. I confirmed nginx.conf again, but it is described. Did something change?

“no-referrer”, “no-referrer-when-downgrade”, “strict-origin”, “strict-origin-when-cross-origin” , “same-origin”
Even if I set one of these, the warning will not disappear.

Nextcloud 15.0.0 CentOS 7.5 PHP 7.1.24 Nginx 1.13.8

2

Hi,

Regarding the No-Referrer setting, could you run the test here and look for the header in the results? You can also post the results here.

The app user_external is not for external storages. It is for external authentication of users. I think ldap was handled by this app.
What makes the connection to external storages work is the app external_storage :wink:
And yes, external_user is not yet compatible with NC15, like some other apps are not yet, too unfortunately. Will come…

For the manual update, I would perform the exact same steps, so it seems correct to me. You could check the admin guide, if you want to be 100% sure. It describes the necessary steps for manual updates.

The database repair is rather a simple improvement. There was nothing wrong with your DB, with NC15 only came a slightly changed DB scheme to improve performance. And that are the new indices. The bigint is probably to avoid issues with caching. So no worries there :slight_smile:

I hope I covered all questions :slight_smile:

3

Thanks for reply.

About Refferer policy

I verify on that site, the raw value shows the value I set.

HTTP/1.1 200 OK
Server nginx
Date Wed, 12 Dec 2018 07:51:53 GMT
Content-Type text/html; charset=UTF-8
Content-Length 156
Last-Modified Mon, 10 Dec 2018 10:21:26 GMT
Connection keep-alive
ETag “XXXXXXX”
Referrer-Policy no-referrer
Strict-Transport-Security max-age=31536000; includeSubDomains; preload;
X-Content-Type-Options nosniff
X-XSS-Protection 1; mode=block
X-Robots-Tag none
X-Download-Options noopen
X-Permitted-Cross-Domain-Policies none
X-Frame-Options SAMEORIGIN
Accept-Ranges bytes

“Referrer-Policy” is included in the list with a green background.

User_external

I could not update it even if I replaced the source of this user_external with the latest source or old source. There was only MySQL’s way. Other apps were able to proceed with the update by replacing the files.

Is this a problem caused by manual update?
For example, if it is automatic update, is it temporarily invalidating all the apps and replacing the files? Since I was already updating this time, I can no longer operate NC’s UI.
Currently it is grayed out “Enable” button on NC’s UI. There is no delete button. Other incompatible app also grayed out, but there is a delete button.

Currently there are many incompatible apps, so careful attention is required for those who do manual updates.
Of course the data directory, but I understood that the app directory is also dangerous.

4

It’s not recommended to make changes to the DB yourself. If an app is not available for a specific NC version it usually has its reason and we have to wait for an update. Unsupported or problematic apps should rather be disabled instead of forcefully enabled :wink:
Right now “External user support” is still not supported for NC15, so I suggest to disable this app again.

Maybe due to the fact that the app was enabled in the DB?

For the referrer, maybe you can try to restart nginx (or run nginx -t to test the config first) and if that doesn’t solve the problem, post your nginx config here. I didn’t discovery any issues in this direction on my server. So it’s strange to me as well.

5

Current user_external seems to be in an abnormal state.

I changed “enable” to “no” in MySQL. I thought it was dangerous to operate and delete the table itself. I tried restoring “enable” to “yes”. Then user_external appears to be valid on NC15 on the application list. However, since the button is grayed out, it can not be changed to disable. I think that the item of user_external is not found in the setting item either.

I deleted the “user_external” directory from the app directory. Then delete the table containing “oc_user_external” from MySQL and the record related to user_external in oc_appconfig table. Is this correct?
It seems that it is misleading in DB just to delete the user_external directory from the app directory.

6

I thought it was dangerous to operate and delete the table itself.
Yes it is. Rather don’t. Once you start, you sometimes have to continue and mess things up. Just like now, after you enabled the app forcefully.

The deletion of the folder should have been enough, though. When the php code (the folder is missing) the app cannot load, no matter what the DB says.

Yes, that’s what I’m saying :slight_smile:

When you’re asking if this was correct, well, not really :stuck_out_tongue:
The main question is, however, did it resolve your problem?

7

I simply edited it in the nginx.conf example in the Nextcloud Official Manual. Of course, my server only items (eg certificate etc) are set for them. Then the items pointed out increased as follows.
*Nginx configuration — Nextcloud 15 Administration Manual 15 documentation (webroot~)

  • The “X-Content-Type-Options” HTTP header is not set to “nosniff”. This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.

  • The “X-Robots-Tag” HTTP header is not set to “none”. This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.

  • The “X-Download-Options” HTTP header is not set to “noopen”. This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.

  • The “X-Permitted-Cross-Domain-Policies” HTTP header is not set to “none”. This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.

  • The “Referrer-Policy” HTTP header is not set to “no-referrer”, “no-referrer-when-downgrade”, “strict-origin”, “strict-origin-when-cross-origin” or “same-origin”. This can leak referer information. See the W3C Recommendation :arrow_upper_right:.

*The top 4 items are orange characters.

In https://securityheaders.com verification, it fell to evaluation B, but no-refferer is recognized.

X-Content-Type-Options nosniff
X-XSS-Protection 1; mode=block
X-Robots-Tag none
X-Download-Options noopen
X-Permitted-Cross-Domain-Policies none
Referrer-Policy no-referrer
Strict-Transport-Security max-age=31536000; includeSubDomains; preload;

When I set the “add_header X-XSS-Protection “1; mode=block”;”, the Chromium type browser warns me with the Developper tool. Firefox does not give that warning. *This X-XSS-Protection continues from the old NC.

8

This is also strange. I removed referrer-policy and items starting with five “X-” from nginx.conf.
Then I passed the NC system check. I tested on the Securityheader site, of course, those security items are not set up.

Which is reliable on NC’s system check mechanism and securityheader site?

9

I updated to Nextcloud 15.0.1, but it seems that the header problem starting with X has not been resolved. They are recognized at external security check sites and point out abnormalities in NC’s verification mechanism. Which is right?

10

I updated to NC 15.0.2. And I changed the environment of the server, but there is no change in the verification result.

Nextcloud 15.0.2, CentOS 7.6, PHP 7.3, Nginx 1.14.1

11

I have upgraded to NC 15.0.5, but I still have not resolved the following error. I verify it at the verification site and they are reflected. Which one should I trust?

* The "X-Content-Type-Options" HTTP header is not set to "nosniff". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.
* The "X-Robots-Tag" HTTP header is not set to "none". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.
* The "X-Frame-Options" HTTP header is not set to "SAMEORIGIN". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.
* The "X-Download-Options" HTTP header is not set to "noopen". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.
* The "X-Permitted-Cross-Domain-Policies" HTTP header is not set to "none". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.