- 16 Jan, 2019 4 commits
-
-
Łukasz Nowak authored
The IP used by frontend can be different than the real endpoint, and unknown for the frontend itself, so make it catch-all to allow access. /reviewed-on nexedi/slapos!497
-
Łukasz Nowak authored
Because of misleading tests (Accept-Encoding with gzip was always set by requests, fixed in "caddy-frontend/test: Workaround requests issue with Accept-Encoding") the original commit "Fix/caddy frontend prefer gzip type zope" did not really fixed the issue for type:zope backend.
-
Łukasz Nowak authored
requests set Accept-Encoding header, but in the testr environment we want to have full control over its behaviour, thus not setting any header if not really wanted. As there is not known way to avoid setting the header (skip_accept_encoding is internal to httplib) set dummy Accept-Encoding header, which is enough for our environment.
-
Jérome Perrin authored
Hopefully fix the random failure with: ``` test_connect (test.TestSSHServer) ... /srv/slapgrid/slappart3/srv/testnode/byx/soft/a452c8ac557f7eaea3c20f6cc373c390/eggs/paramiko-2.4.2-py2.7.egg/paramiko/client.py:822: UserWarning: Unknown ecdsa-sha2-nistp521 host key for [2001:67c:1254:e:4a::7bd5]:22222: 22c41f5090433152d1e5395a85d6cb4f key.get_name(), hostname, hexlify(key.get_fingerprint()) FAIL ====================================================================== FAIL: test_connect (test.TestSSHServer) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/slapgrid/slappart3/srv/testnode/byx/soft/a452c8ac557f7eaea3c20f6cc373c390/parts/slapos-repository/software/seleniumserver/test/test.py", line 357, in test_connect self.assertIn("Welcome to SlapOS Selenium Server.", channel.recv(100)) AssertionError: 'Welcome to SlapOS Selenium Server.' not found in 'Attempt to write login records by non-root user (aborting)\r\r\n' ---------------------------------------------------------------------- ``` Also publish the fingerprint of the server ssh key, which addresses this warning in the correct way (I feel) and since we can publish the fingerprint, why not. /reviewed-on nexedi/slapos!492
-
- 14 Jan, 2019 1 commit
-
-
Łukasz Nowak authored
Since "stack/monitor: Add auto-restart on certificate-authority section" certificate authority is correctly exposed in supervisor with its hash.
-
- 11 Jan, 2019 7 commits
-
-
Alain Takoudjou authored
-
Guillaume Hervier authored
/reviewed-on !500
-
Guillaume Hervier authored
/reviewed-on !499
-
Alain Takoudjou authored
-
Alain Takoudjou authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
- 10 Jan, 2019 7 commits
-
-
Alain Takoudjou authored
-
Thomas Gambier authored
-
Thomas Gambier authored
Remove all references to deprecated directories. The promises inside monitor-directory:promises directory are not run anymore by slapgrid. The scripts inside monitor-directory:reports are not run either. In this PR, we just update the directory location: * promise directory is now etc/promise (${directory:promise}) * reports directory is now bin (${directory:bin}) /cc @alain.takoudjou @rafael /reviewed-on nexedi/slapos!490
-
Thomas Gambier authored
-
Thomas Gambier authored
-
Thomas Gambier authored
-
Thomas Gambier authored
-
- 09 Jan, 2019 3 commits
-
-
Thomas Gambier authored
-
Rafael Monnerat authored
-
Jérome Perrin authored
so that on first connection clients can check the fingerprint key instead of blindly accepting it.
-
- 08 Jan, 2019 2 commits
-
-
Jérome Perrin authored
This seem to be needed "sometimes", apparently on the first connection after server is started, but this was not investigated much.
-
Jérome Perrin authored
In "direct zope access" ports, the shared frontend is not used, so the argument that long timeout consume resources on shared server does not apply here. A timeout of one hour was choosen arbitrarily, a value that should be large enough for normal requests and more than the default 60s timeout that we hit in the "wait for activities" step when running zelenium tests.
-
- 07 Jan, 2019 2 commits
-
-
Jérome Perrin authored
In 51740961 we "started testing new version of setuptools" and `BUILDOUT-NEXT` test suite was set to use this `software/buildout-testing/software-next.cfg`. In nexedi/slapos!425 we started to depend on very recent setuptools and updated to 40.4.3 . This `software/buildout-testing/software-next.cfg` kept using this old setuptools and `BUILDOUT-NEXT` test suite failed to build in a loop. The test suite was already changed to use `software/buildout-testing/software.cfg` (ie. it's same as `BUILDOUT` but testing slapos.buildout's `next` branch instead of `master` ), so I think this profile is not needed currently. /reviewed-on nexedi/slapos!488
-
Jérome Perrin authored
Using `software11` breaks now that the version of the database was increased in slapos.core!76 /reviewed-on !483
-
- 04 Jan, 2019 1 commit
-
-
Łukasz Nowak authored
/reviewed-on !489
-
- 03 Jan, 2019 1 commit
-
-
Thomas Gambier authored
/reviewed-on !469
-
- 02 Jan, 2019 3 commits
-
-
Rafael Monnerat authored
Before call uninstall, the pin is verified and it can cause error if picked version is mandatory.
-
Bryton Lacquement authored
-
Łukasz Nowak authored
Just asserting Location header is not enough, as http status code value is important for the implementation, so assert for its value. Also fix https-only redirect status code value, which supposed to be FOUND, not default MOVED_PERMANENTLY. /reviewed-on !485
-
- 30 Dec, 2018 2 commits
-
-
Łukasz Nowak authored
/reviewed-on !487
-
Łukasz Nowak authored
/reviewed-on !486
-
- 28 Dec, 2018 4 commits
-
-
Rafael Monnerat authored
The version 1.0.84 was used by an existing tag on the version control, so it would be inconsistent to use this version number.
-
Rafael Monnerat authored
-
Łukasz Nowak authored
It is known problem of Caddy regarding QUIC non functional after sending it SIGUSR1: https://github.com/mholt/caddy/issues/2394
-
Łukasz Nowak authored
/reviewed-on !481
-
- 27 Dec, 2018 3 commits
-
-
Łukasz Nowak authored
/reviewed-on !480
-
Jérome Perrin authored
Installing from master is problematic because when master does not build we don't have test results and we don't see that it's broken. /reviewed-on !474
-
Vincent Pelletier authored
The query present in the sql dump sets gtid_slave_pos, which is used by slave_pos. current_pos relies on gtid_current_pos, which is not set here and hence fails to initiate replication. Another (unintended) effect of using slave_pos is that queries run on the slave will not break replication. There should be no reason to run queries on slave (at least, data & schema modification queries while replication is active), so it would seem better to fail the replication immediately in order to detect this. So this may not be the best solution - but at least this fixes this script.
-