76af9ba53d
This implements a new debug/trace infrastructure based on a slightly
hacked up logger. Instead of the traditional "if debug { ... }" I've
rewritten the logger to have no-op Debugln and Debugf, unless debugging
has been enabled for a given "facility". The "facility" is just a
string, typically a package name.
This will be slightly slower than before; but not that much as it's
mostly a function call that returns immediately. For the cases where it
matters (the Debugln takes a hex.Dump() of something for example, and
it's not in a very occasional "if err != nil" branch) there is an
l.ShouldDebug(facility) that is fast enough to be used like the old "if
debug".
The point of all this is that we can now toggle debugging for the
various packages on and off at runtime. There's a new method
/rest/system/debug that can be POSTed a set of facilities to enable and
disable debug for, or GET from to get a list of facilities with
descriptions and their current debug status.
Similarly a /rest/system/log?since=... can grab the latest log entries,
up to 250 of them (hardcoded constant in main.go) plus the initial few.
Not implemented in this commit (but planned) is a simple debug GUI
available on /debug that shows the current log in an easily pasteable
format and has checkboxes to enable the various debug facilities.
The debug instructions to a user then becomes "visit this URL, check
these boxes, reproduce your problem, copy and paste the log". The actual
log viewer on the hypothetical /debug URL can poll regularly for new log
entries and this bypass the 250 line limit.
The existing STTRACE=foo variable is still obeyed and just sets the
start state of the system.
Syncthing
This is the Syncthing project which pursues the following goals:
-
Define a protocol for synchronization of a folder between a number of collaborating devices. This protocol should be well defined, unambiguous, easily understood, free to use, efficient, secure and language neutral. This is called the Block Exchange Protocol.
-
Provide the reference implementation to demonstrate the usability of said protocol. This is the
syncthingutility. We hope that alternative, compatible implementations of the protocol will arise.
The two are evolving together; the protocol is not to be considered stable until Syncthing 1.0 is released, at which point it is locked down for incompatible changes.
Getting Started
Take a look at the getting started guide.
There are a few examples for keeping Syncthing running in the background on your system in the etc directory.
There is an IRC channel, #syncthing on Freenode, for talking directly
to developers and users.
Building
Building Syncthing from source is easy, and there's a guide. that describes it for both Unix and Windows systems.
Signed Releases
As of v0.10.15 and onwards, git tags and release binaries are GPG signed with the key D26E6ED000654A3E (see https://syncthing.net/security.html). For release binaries, MD5 and SHA1 checksums are calculated and signed, available in the md5sum.txt.asc and sha1sum.txt.asc files.
Documentation
Please see the Syncthing documentation site.
All code is licensed under the MPLv2 License.