Commit Graph
2150 Commits
Author SHA1 Message Date
Paul Bellamy 127cffba6f [proxy] add TLS to /status 2015-06-05 13:38:55 +01:00
Paul Bellamy b8595b9062 [proxy] cleaner default args 2015-06-05 13:23:15 +01:00
Paul Bellamy fa6707effa [docs] adding paragraph about docker listening on unix socket for proxy 2015-06-05 13:23:15 +01:00
Paul Bellamy a1ffbb528c adding documentation on using the proxy with tls 2015-06-05 13:23:14 +01:00
Paul Bellamy c0cf9e509c [proxy] Added proxy.Config struct for initialization 2015-06-05 13:23:14 +01:00
Paul Bellamy c31358259f [proxy] Add tls support
Caveats:
* TLS files must be present on the target server (and readable)
* TLS file paths cannot contain spaces
* TLS file paths must be absolute (i.e. cannot be relative)
* Bash argument parsing is terrible
2015-06-05 13:23:14 +01:00
Matthias Radestock 8514172e57 explain meaning of 'Encryption' line in weave status output 2015-06-05 11:27:38 +01:00
Matthias Radestock 3a0a8ba939 cosmetic 2015-06-05 10:31:34 +01:00
Matthias Radestock 16410d6014 refactor: make encryption status part of router status 2015-06-05 10:05:17 +01:00
Matthias Radestock 34e3f0ba3f refactor: simplify topology gossip gob decoder initialisation
Should be more efficient too due to less copying.
2015-06-05 07:39:34 +01:00
Bryan Boreham 62bbaf57a2 Merge pull request #839 from rade/837_tcp_accept_delay
LGTM. Closes #837
2015-06-04 14:29:58 +01:00
Bryan Boreham 7acb4be13f Merge pull request #844 from rade/641_recommend_strong_password
LGTM. Closes #641
2015-06-04 14:28:22 +01:00
Matthias Radestock 044992eea0 limit acceptance rate on peer connections
The main purpose of this is to set an upper bound on the rate at which
an attacker might execute a brute force attack on the weave password.

No need to get clever or precise here.

Closes #837.
2015-06-04 14:21:35 +01:00
Bryan Boreham 2a244e5699 Simplify paxos.Consensus() call 2015-06-04 13:30:15 +01:00
Matthias Radestock e31233c473 recommend strong password
Closes #641.
2015-06-03 18:15:32 +01:00
Matthias Radestock 720fdf714c excise reference to crypto implementation from main docs
It's too scary for the uninitiated.
2015-06-03 18:10:38 +01:00
Paul Bellamy 6f9c0d6cde Merge pull request #834 from weaveworks/docs_lookandfeel
Docs look and feel update
2015-06-03 17:29:29 +01:00
Paul Bellamy a7782359b1 Merge pull request #838 from paulbellamy/docs-capitals
Capitalizing and standardizing titles of pages in the docs.
2015-06-03 16:29:37 +01:00
Fintan Ryan e96a22bd6d Docs look and feel update 2015-06-03 16:04:01 +01:00
Paul Bellamy a957ed253c Capitalizing and standardizing titles of pages in the docs.
Also re-wording to make them match the page title.
2015-06-03 15:59:40 +01:00
Matthias Radestock dc8a82e913 cosmetic: consistency in launchers 2015-06-03 14:22:20 +01:00
Bryan Boreham c1f8b62e11 Merge pull request #832 from rade/412_min_backoff
LGTM. Fixes #412
2015-06-03 12:47:07 +01:00
Paul Bellamy c91e699a27 Merge pull request #831 from rade/192_kill_container_on_network_config_error
kill container on network config error
2015-06-03 12:45:23 +01:00
Adam Harrison 4a8850afb3 Fix comment 2015-06-03 12:08:13 +01:00
Matthias Radestock d1c41a97b1 encapsulate retry delay calculation 2015-06-03 12:04:33 +01:00
Matthias Radestock fe5102580d fix connection retry delay calculation logic
The delay d(n) for the nth retry was
d(1) = rand(initial_interval)
d(n+1) = d(n) + rand(d(n))

There are two problem with this:

1) The entire sequence is dominated by the random value for d(1). If
this is a small value, lots of retries at short interval ensue. In
extremis, if d(1) is 0, indefinite immediate retries would ensue.

2) The delay is not a true exponential backoff; the upper bound only
increases exponentially *probabilistically*.

The new algorithm calculates

d(n) = random_value in range [i-i/2,i+i/2],
       where i = initial_interval * 1.5^(n-1).

Thus d(1) is at least initial_interval/2, and successive values are
independent of previous values, forming a true exponential sequence of
intervals bounds between which the retry delay is chosen randomly.

Due to the change in algorithm we reduce...

- the initial interval from 5s to 2s. Recall that previously d(1) was
  in the range [0,initial_interval=5s]. It is now [2-2/2=1s,2+2/2=3s].

- the max interval from 10 minutes to 6. Previously, once that was
  reached, it would stay exactly there. It is now randomly chosen in
  the range [6-6/2=3m,6+6/2=9min].

Thus previously delays would range from 0 to 10 minutes, now they
range from 1s to 9 minutes.

Fixes #412.
2015-06-03 11:29:55 +01:00
Matthias Radestock d909a86fb0 Merge pull request #828 from rade/666_no_timeout_on_wait_for_status
no timeout on wait for status

Fixes #666.
2015-06-03 11:20:37 +01:00
Matthias Radestock 4e68bde7b5 don't time out waiting for weave infrastructure containers to start
instead keep trying, until we succeed or the container dies

Fixes #666.
2015-06-03 11:19:51 +01:00
Matthias Radestock 52f31f0596 Merge pull request #830 from rade/829_fix_container_death_check
kill -0 $CONTAINER_PID does not work inside weaveexec container

Fixes #829.
2015-06-03 11:17:23 +01:00
Matthias Radestock fa8b77b060 kill -0 $CONTAINER_PID does not work inside weaveexec container
since $CONTAINER_PID is in a different process namespace.

Fixes #829.
2015-06-03 11:16:08 +01:00
Matthias Radestock 83fe4e59f6 kill container on network config error
but only if we have just started it; killing other containers, e.g. on
`weave attach`, would be rather impolite.

Closes #192.
2015-06-02 20:26:20 +01:00
Matthias Radestock 8de1ddd255 cosmetic 2015-06-02 20:21:56 +01:00
Matthias Radestock 395aea28c6 cosmetic 2015-06-02 20:16:25 +01:00
Matthias Radestock 5e7d1cd0eb Merge remote-tracking branch 'upstream/master' 2015-06-02 18:46:30 +01:00
Michael Bridgen 3344e45a9f Merge pull request #825 from squaremo/discover_ipam_ip
Allow lookup of IPAM-allocated addresses
2015-06-02 18:04:11 +01:00
Matthias Radestock d020999e82 cosmetic: more sensible function order 2015-06-02 17:52:39 +01:00
Matthias Radestock d105d255ca Merge pull request #824 from paulbellamy/weavewait-race-condition
[proxy] We can only rely on receiving a signal when we are a container

This got broken in #820.
2015-06-02 17:39:28 +01:00
Michael Bridgen 791584d9f3 Allow lookup of IPAM-allocated addresses 2015-06-02 17:31:25 +01:00
Matthias Radestock 48b54ef722 cosmetic: consistency 2015-06-02 17:25:56 +01:00
Paul Bellamy e2447721eb [proxy] We can only rely on receiving a signal when we are a container
Due to https://github.com/docker/docker/issues/9098, there is no way to
signal an exec. Instead we'll have to just poll the interface and hope.

Adds `weavewait -s` which is the way to tell weavewait to skip waiting
for a signal, which we use on execs
2015-06-02 17:21:41 +01:00
Bryan Boreham 89074715bc Merge pull request #823 from bboreham/818-claim-no-trunc
Fixes #818
2015-06-02 16:12:47 +01:00
Bryan Boreham 4968f0f3c4 Merge pull request #822 from bboreham/802-test-race
Fix race condition in allocator fuzz-test - fixes #802
2015-06-02 16:12:22 +01:00
Bryan Boreham aa7c7a9a9d Add --no-trunc flag to docker ps for ipam_claim 2015-06-02 16:07:48 +01:00
Bryan Boreham 6a1b658f59 Fix race condition in allocator fuzz-test
It was possible to free an address between deciding to re-test it
and actually re-testing it.  So introduced a flag 'block' to prevent
an address from being freed during the re-test.
2015-06-02 16:04:35 +01:00
Matthias Radestock e2805c01f4 cosmetic: remove stray trailing whitespace 2015-06-02 15:57:50 +01:00
Matthias Radestock 04c10233f7 Merge pull request #820 from paulbellamy/weavewait-race-condition
Use USR2 signal to tell weavewait when to continue

Fixes #812.
2015-06-02 15:52:22 +01:00
Paul Bellamy 92444a75eb [proxy] Use USR2 signal to tell weavewait when to continue
There was a race condition with containers running and exiting before
`weave attach` was finished, which would cause an error.
2015-06-02 15:48:49 +01:00
Paul Bellamy cb92e6b0d2 Merge pull request #817 from rade/420_move_exe_image_to_subdir
move exe and docker image producing dirs to subdir
2015-06-02 14:18:49 +01:00
Matthias Radestock 5b04efac7c move weaver 2015-06-02 14:04:02 +01:00
Matthias Radestock 485db6e48b move weavedns 2015-06-02 13:51:19 +01:00