fallback_node self.clean_location failure results in no clusterURL valu

RESOLVED DUPLICATE of bug 721558

Status

Cloud Services
Server: Registration
RESOLVED DUPLICATE of bug 721558
6 years ago
6 years ago

People

(Reporter: Jethro Carr, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
Created attachment 597342 [details]
Example Firefox log showing error.sync.reason.no_node_found error

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 Iceweasel/9.0.1
Build ID: 20120106041658

Steps to reproduce:

I have configured a Mozilla Sync Server from checked out trunk sources (not using the sync server build utilities) as part of distribution packaging.

The components I have built and installed are: server-core, server-reg, server-storage and server-sync, using a SQLite backend.

server-core trunk changeset da979263448c
server-reg trunk changeset 2814b6167114
server-full trunk changeset 14a5c37fbfc2
server-storage trunk changeset 689923bdefff



Actual results:

When testing with various clients (Firefox 10 for Windows, Firefox 9 for Linux, and Firefox 9 for Android) I found that the sync setup process would complete and successfully register a user on the sync server, however the initial sync would fail and never take place, repeatedly failing and reporting that the server is busy.

The issue occurs with the following call after registration before sync:
GET /mozilla-sync/user/1.0/USERID/node/weave HTTP/1.1" 200

The call returns success, but never returns the value of nodes.fallback_node despite being configured correctly and expected as per the API specification.

Example of configuration (full server configuration attached to bug report)
[nodes]
fallback_node = http://example.com/mozilla-sync/

To work around, I had to manually set the service.sync.clusterURL value in the Firefox client in order to get sync to occur. This was determined by digging through the mailing list which revealed a few similar faults had been fixed in this manner.


Expected results:

The services.sync.clusterURL value should have been set when the sync registration completed. 

Mozilla server-reg should be sending back the configured nodes.fallback_node value when the API call is executed so that the Firefox browser can configure accordingly.

According the to the documented API at http://docs.services.mozilla.com/reg/apis.html, the call that is failing should return the node that the client is located on, the return of a null value indicates a server performance issue.

Confirmed with packet dump that no clusterURL value was being returned.

Annoyingly Firefox did not log an error because it considers the API call to still be a success, even if no clusterURL is returned. To figure out what is going on, you need to set services.sync.log.appender.file.logOnSuccess to True, attempt a sync, and then review the success logs at about:sync-log to see:

29298300464	Sync.Resource	DEBUG	GET success 200 http://example.com/mozilla-sync/user/1.0/bd2ytnv422t273fwunxsvdiduauv776o/node/weave
1329298300464	Sync.Service	DEBUG	Cluster value = null
1329298300464	Sync.Status	DEBUG	Status.sync: success.sync => error.sync.reason.no_node_found

This full error file example from a Mozilla browser has been attached to this bug report for your reference.
(Reporter)

Comment 1

6 years ago
Created attachment 597343 [details]
Example of server configuration used.
(Reporter)

Comment 2

6 years ago
Created attachment 597345 [details] [diff] [review]
Patch to resolve issue - needs further work to ensure secure

I have attached a patch created which disables the URL validation in syncreg/controllers/user.py, the validation here seems to break the fallback_nodes return.

This patch may cause security issues, I have only taken a brief look at the code base at this stage.
Updating to server-reg tip (or the rpm-1.0-2 tag) should make this problem go away
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 721558
You need to log in before you can comment on or make changes to this bug.