* relaysrv/master: (60 commits)
Add new dependencies
Add more logging in the case of relaypoolsrv internal server error
Dependency update
Update deps
Update packages, fix testutil. Goddamit godep.
Typo
Add signal handlers (fixes#15)
Update readme (fixes#16)
Limit number of connections (fixes#23)
Enable extra logging in pool.go even when -debug not specified
Add Antony Male to CONTRIBUTORS
Allow extAddress to be set from the command line
URLs should have Go units
Add CORS headers
Fix units
Expose provided by in status endpoint
Add ability to advertise provider
Change the URL
Rename relaysrv binary, see #11
Jail the whole thing a bit more
...
* discosrv/master: (64 commits)
Use atomics for statistics handling (fixes#45)
Lower case JSON fields are nicer
Change v13 to v2
Remove explicit relay handling
Update vendored github.com/cznic/ql (fixes#34)
Defer fd.Close() (fixes#37)
There is no "get dependencies" step
Add vendor/golang.org/x/net/context
Use Go 1.5 vendoring instead of Godeps
Add debug performance logging per request
Must close result sets
Set Retry-After header
Ignores
lru.Cache is not concurrency safe
We need a limit on the number of PostgreSQL connections
Correct example DSN (fixes#29)
Allow plain HTTP serving behind a proxy
Fix Query/Answer stats
Reduce our patience with slow clients somewhat
Discovery server should print device ID of certificate at startup
...
With the previous setup, browsers were free to use a local cache for any
length of time they pleased: we didn't set an 'Expires' header (or max-age
directive), and Cache-Control just said "you're free to cache this".
Therefore be more explicit: we don't mind if browsers cache things, but they
MUST revalidate everything on every request.
GitHub-Pull-Request: https://github.com/syncthing/syncthing/pull/3221
The intention for this package is to provide a combination of the
security of crypto/rand and the convenience of math/rand. It should be
the first choice of random data unless ultimate performance is required
and the usage is provably irrelevant from a security standpoint.
GitHub-Pull-Request: https://github.com/syncthing/syncthing/pull/3186
We need to set these properties *before* Angular starts making requests,
and doing that from the response to a request is too late. The obvious
choice (to me) would be to use the angular $cookies service, but that
service isn't available until after initialization so we can't use it.
Instead, add a special file that is loaded by index.html and includes
the info we need before the JS app even starts running.
GitHub-Pull-Request: https://github.com/syncthing/syncthing/pull/3152
Without this the summary service doesn't know to recalculate completion
percentage for remote devices when DownloadProgress messages come in.
That means that completion percentage isn't updated in the GUI while
transfers of large files are ongoing. With this change, it updates
correctly.
GitHub-Pull-Request: https://github.com/syncthing/syncthing/pull/3144
I think this better reflects what it means. Also tweaks the verbose
format to be more like our other things and lightly refactors the code
to not have the boolean and include the folder in the event.
GitHub-Pull-Request: https://github.com/syncthing/syncthing/pull/3121
Because json.NewDecoder(r).Decode(&v) doesn't necessarily consume all
data on the reader, that means an HTTP connection can't be reused. We
don't do a lot of HTTP traffic where we read JSON responses, but the
discovery is one such place. The other two are for POSTs from the GUI,
where it's not exactly critical but still nice if the connection still
can be keep-alive'd after the request as well.
Also ensure that we call req.Body.Close() for clarity, even though this
should by all accounts not really be necessary.
GitHub-Pull-Request: https://github.com/syncthing/syncthing/pull/3050
1. Removes separate relay lists and relay clients/services, just makes it a listen address
2. Easier plugging-in of other transports
3. Allows "hot" disabling and enabling NAT services
4. Allows "hot" listen address changes
5. Changes listen address list with a preferable "default" value just like for discovery
6. Debounces global discovery announcements as external addresses change (which it might alot upon starting)
7. Stops this whole "pick other peers relay by latency". This information is no longer available,
but I don't think it matters as most of the time other peer only has one relay.
8. Rename ListenAddress to ListenAddresses, as well as in javascript land.
9. Stop serializing deprecated values to JSON
GitHub-Pull-Request: https://github.com/syncthing/syncthing/pull/2982
This happens automatically in the background anyway, and it can take a
long time on low powered devices at an inconvenient time. We just want
to get up and running as quickly as possible.
GitHub-Pull-Request: https://github.com/syncthing/syncthing/pull/3000
A potential practical use is to encode a short version of the hostname
at the beginning of the device ID.
For example:
jb@syno:~/s/g/s/s/c/stvanity $ stvanity abc
Want 15 bits for prefix "ABC", about 3.3e+04 certs to test (statistically speaking)
Found ABCFPWS-JKDIFV3-E5IUAQW-DK53WVR-HY7XWBS-56H33GR-CJQI67Q-VGXRMAW
Saved to cert.pem, key.pem
jb@syno:~/s/g/s/s/c/stvanity $ stvanity $(hostname)
Want 20 bits for prefix "SYNO", about 1e+06 certs to test (statistically speaking)
Trying 554 certs/s, tested 8307 so far in 15s, expect ~32m total time to complete
Trying 543 certs/s, tested 16277 so far in 30s, expect ~32m total time to complete
...
The rest is just a matter of patience.
jb@syno:~/s/g/s/s/c/stvanity $ stvanity syncthing
Want 50 bits for prefix "SYNCTHI-NG", about 1.1e+15 certs to test (statistically speaking)
Trying 529 certs/s, tested 7941 so far in 15s, expect ~67443 years total time to complete
...
GitHub-Pull-Request: https://github.com/syncthing/syncthing/pull/2986
When run without parameters, attempts to listen for local discovery
announcements just like Syncthing, and prints them.
With -send, it also sends fake discovery packets. This can be used on
two or more computers simultaneously to verify that they can see each
other.
GitHub-Pull-Request: https://github.com/syncthing/syncthing/pull/2985
This fixes both a race condition where we could assign s.stop from one
goroutine and then read it from another without locking, and handles the
fact that listener may be nil at shutdown if we've had a bad
CommitConfiguration call in the meantime.
This updates the modified time of the config file before archiving it
during an update so that the clean up routine doesn't delete it if it's
too old, preventing the user from being able to rollback after an
upgrade.
This gets rid of redundant checks and centralizes the logic of loading
the config files so that we don't have to keep doing the same thing in
multiple places.
I'm not really sure under what circumstances MkdirAll returns a nil
error but a subsequent stat fails, but apparently it can happen and we
need to handle it. The "mode >= 0" was a no-op, and we never call
ensureDir anyway without the intention of ensuring the mode, so removed
that.
This avoids the double negative of having noConsole = false to represent
not hiding the console. It is also consistent with the action performed
by osutils.
This takes advantage of the newly created parseCommandLineOptions()
function and makes it work so that it now returns a nice struct of
options rather than relying on global variables.
There are a few global variables left, but they will take a bit more
refactoring in order to be removed, so it'll happen in later commits.
ensureDir() did not handle one last error case and there was some logic
in the main() function that belonged to ensureDir() as well. It was also
creating a directory with a hardcoded 0700 mode, regardless of what mode
was passed to it.
This refactors it a little to fix the broken behavior, avoid redundant
checks by taking advantage of the behavior of MkdirAll, and move the
extra logic from main() into ensureDir().
The main() function is growing too big (142 lines as of the date of this
commit), so this attempts to extract some functionality out of there and
into their own functions to make it easier to reason about them and keep
functions short and concise.
--browser-only assumes syncthing is already running and will open the
user's browser in the URL:port currently used in the configuration if
the GUI is enabled.
Every time a JSON object is returned in an HTTP response, the
appropriate header needs to be set and the object itself needs to be
encoded. Doing this in every function is repetitive and error prone
(getDBFile and postDBScan, for instance, never set any headers).
This adds a helper function to centralize the appropriate JSON response
handling.
With this change, the behavior is as follows:
- SIGTERM / SIGINT: Exit cleanly (exit code 0)
- SIGHUP: Restart
This is the case both when hitting the monitor process or the inner
process, or if running with NORESTART (but then we won't restart,
obviously, just exit with code exitRestarting).
It enables "pkill -HUP syncthing" to do the right thing to restart all
Syncthings on package upgrade, for example.
Also fixes what I think migh thave been a bug where we did not use the
proxy for usage reports. And removes the BuildEnv field that we don't
need any more.
This replaces the current 3072 bit RSA certificates with 384 bit ECDSA
certificates. The advantage is these certificates are smaller and
essentially instantaneous to generate. According to RFC4492 (ECC Cipher
Suites for TLS), Table 1: Comparable Key Sizes, ECC has comparable
strength to 3072 bit RSA at 283 bits - so we exceed that.
There is no compatibility issue with existing Syncthing code - this is
verified by the integration test ("h2" instance has the new
certificate).
There are browsers out there that don't understand ECC certificates yet,
although I think they're dying out. In the meantime, I've retained the
RSA code for the HTTPS certificate, but pulled it down to 2048 bits. I
don't think a higher security level there is motivated, is this matches
current industry standard for HTTPS certificates.
- Move to ipinfo.io for geoip, rather than Telize. Telize has been closed
down. ipinfo.io has apparently got decent availability, and allows
1,000 requests per day on the free tier. Since requests are made by the
client, this should be more than enough (and the total across all clients
should still be less than this).
- Fix issue where one nonresponsive relay would cause 'data unavailable'
to be shown for many relays. This was caused by the relay status
promise not being correctly added to the list of things being waited
for before the map was rendered. Any delayed relay status requests
would therefore occur after the map was rendered, which was too late.
