An error occurred fetching the project authors.
- 17 Jul, 2020 4 commits
-
-
Łukasz Nowak authored
-
Łukasz Nowak authored
-
Łukasz Nowak authored
-
Łukasz Nowak authored
By default do not offer authentication certificate, the switch authenticate-to-backend can be used on cluster or slave level to control this feature.
-
- 14 Jul, 2020 1 commit
-
-
Łukasz Nowak authored
ssl_proxy_ca_crt can be just empty value, and that's not acceptable.
-
- 22 Jun, 2020 1 commit
-
-
Łukasz Nowak authored
Customized configuration support is not used since introduction of Caddy software, so there is no need to support it anymore.
-
- 06 Mar, 2020 1 commit
-
-
Łukasz Nowak authored
-
- 02 Mar, 2020 1 commit
-
-
Łukasz Nowak authored
Instead of forcing to set monitor port in some cases, just generate them, so it's possible to correctly instantiate caddy-frontend on one partition scenario like in webrunner or tests.
-
- 20 Feb, 2020 1 commit
-
-
Łukasz Nowak authored
/reviewed-on nexedi/slapos!633
-
- 19 Nov, 2019 1 commit
-
-
Łukasz Nowak authored
-
- 04 Oct, 2019 1 commit
-
-
Thomas Gambier authored
Prevent creating 2 wrapper for the same service if hash changed. Here, one service is exited because port is used by the firt to service to start: slappart6:runner-sshd-4248650e36a9a26a6481df1baffd9f58-on-watch RUNNING pid 27835, uptime 0:03:45 slappart6:runner-sshd-b3b68f4278ceb84691ec27521ea229eb-on-watch EXITED Mar 06 04:52 PM To achieve that, update slapos.cookbook and use hash-existing-files option of wrapper recipe hash-existing-files list all the files used for hash that are not handled by buildout. For those files, the hash is calculated as soon as the __init__ function so that if there is a change in those files, buildout will remove the existing wrapper (it will uninstall the section) and replace it with the new wrapper. /reviewed-on nexedi/slapos!525
-
- 27 Sep, 2019 4 commits
-
-
Łukasz Nowak authored
Sorting will make dumped data "canonical", so it will limit amount of order based changes.
-
Łukasz Nowak authored
Destroyed nodes shall be just destroyed, and there is no need to send whole configuration to them.
-
Łukasz Nowak authored
This will stabilise list of published slaves.
-
Łukasz Nowak authored
Server returns slave list with request and publish keys, but only request keys are important. In order to avoid needless updates and nonsense data remove those polluted keys before publishing information about each slave.
-
- 18 Jul, 2019 1 commit
-
-
Łukasz Nowak authored
/reviewed-on nexedi/slapos!597
-
- 10 Jul, 2019 1 commit
-
-
Łukasz Nowak authored
Due to missing monitor frontend in tests this change is not covered by tests. /reviewed-on nexedi/slapos!592
-
- 20 Jun, 2019 1 commit
-
-
Łukasz Nowak authored
Frontend operator shall have easy access to information about rejected slaves, possibly the best in the JSON file. Also the keys for the human readable information are slave's titles, not references. The information is published via hand crafted HTTPS endpoint. Note: The SSL certificate is generated manually. Existing caucase is special for KeDiFa, this is another step to move all generated certificates (or otherwise self-signed) to internal, full automatic caucase.
-
- 28 May, 2019 1 commit
-
-
Łukasz Nowak authored
-
- 23 Apr, 2019 2 commits
-
-
Łukasz Nowak authored
By default whole slave makes websocket connection to the backend. With websocket-path, only the path has websocket style connections, the rest is standard HTTP.
-
Łukasz Nowak authored
There is no need anymore to have two processes for normal and nginx slaves, as nginx ones are served by caddy anyway. Also inform the requester that type:eventsource is not implemented.
-
- 15 Apr, 2019 1 commit
-
-
Łukasz Nowak authored
This reverts commit 7993ff81. Custom configuration checks are hard to be trusted, as they can impact too many aspects of running frontend. Frontend administrator knows the risks of custom configuration, and shall take proper care. /reviewed-on nexedi/slapos!543
-
- 12 Apr, 2019 1 commit
-
-
Łukasz Nowak authored
This mostly useful during tests to have stable results, especially when some slaves are rejected. This change is expected to be no-op during normal run. Note: The slave rejection system does not guarantee any ordering, as the sort order can change, because of parameters can reorder slaves. Thus, even if slave A was requested before slave B, and they conflict each other, slave A can be rejected instead of "expected" slave B.
-
- 13 Mar, 2019 5 commits
-
-
Łukasz Nowak authored
It is better to have automation similar to previous implementation by default.
-
Łukasz Nowak authored
-
Łukasz Nowak authored
AIKC - Automatic Internal Kedifa's Caucase CSR signing, which can be triggered by option automatic-internal-kedifa-caucase-csr. It signs all CSR which match csr_id and certificate from the nodes which needs them.
-
Łukasz Nowak authored
csr_id is exposed over HTTPS with short living self signed certificate, which is transmitted via SlapOS Master. Thanks to this, it is possible to match csr_id with certificate of given partition and take decision if it shall be signed or not. This is "quite secure" apporach, a bit better than blidny trusting what CSR to sign in KeDiFa. The bootstrap information, which is short living (certificates are valid for 5 days), resides in SlapOS Master. The csr_id is not directly known to SlapOS Master, and shall be consumed as fast as possible by frontend cluster operator in order to sign CSR appearing in KeDiFa caucase. The known possible attack vector requires that attacker knows caucased HTTP listening port and can hijack HTTPS traffic to the csr_id-url to get the human approve his own csr_id. The second is hoped to be overcomed by publishing certificate of this endpoint via SlapOS Master. Unfortunately caucase-updater prefix is directly used to find real CSR, as the one generated is just a template for rerequest, thus csr_id would be different from really used by caucase-updater.
-
Łukasz Nowak authored
Use KeDiFa to store keys, and transmit the url to the requester for master and slave partitions. Download keys on the slave partitions level. Use caucase to fetch main caucase CA. kedifa-caucase-url is published in order to have access to it. Note: caucase is prepended with kedifa, as this is that one. Use kedifa-csr tool to generate CSR and use caucase-updater macro. Switch to KeDiFa with SSL Auth and updated goodies. KeDiFa endpoint URLs are randomised. Only one (first) user certificate is going to be automatically accepted. This one shall be operated by the cluster owner, the requester of frontend master partition. Then he will be able to sign certificates for other users and also for services - so each node in the cluster. Special trick from https://security.stackexchange.com/questions/74345/provide-subjectaltname-to-openssl-directly-on-command-line is used for one command generation of extensions in the certificate. Note: We could upgrade to openssl 1.1.1 in order to have it really simplified (see https://security.stackexchange.com/a/183973 ) Improve CSR readability by creating cluster-identification, which is master partition title, and use it as Organization of the CSR. Reserve slots for data exchange in KeDiFa.
-
- 08 Mar, 2019 1 commit
-
-
Łukasz Nowak authored
Unfortunately slave_title was put by mistake, it supposed to be slave_reference.
-
- 07 Mar, 2019 3 commits
-
-
Łukasz Nowak authored
Use safe JSON serialisation/deserialisation, as otherwise unusual slave_references can lead to issues and also character case is not kept. Also care about case of log access user, which was undetected since slave_reference in tests were always lowercase.
-
Łukasz Nowak authored
This reverts commit 1f91f19d. Unfortunately due to way how profiles are mangled by jinja2, in some cases the strings are becoming lowercased, so it just does not work. It was not caught by tests, as no test has uppercase slave.
-
Łukasz Nowak authored
slave_title is dangerous, as it can contain any characters; it supposed to be slave_reference.
-
- 01 Mar, 2019 1 commit
-
-
Łukasz Nowak authored
As some of the nodes can lag behind, the system can be in state, that those nodes will send inactive (also destroyed) slave publish information. Before publishing it to master, check if each of slaves is really present on master. Tasks: - [x] prove it really works on simulated environment - [x] check impact on massive simulated environment - [x] cover with a test (optionally) - [ ] check test results with this change /reviewed-on nexedi/slapos!519
-
- 10 Feb, 2019 1 commit
-
-
Łukasz Nowak authored
-
- 22 Nov, 2018 1 commit
-
-
Łukasz Nowak authored
-
- 21 Nov, 2018 1 commit
-
-
Łukasz Nowak authored
custom_domain and server-alias on given slave do not have to clash, and can be deduplicated during request parameter analysis. /reviewed-on nexedi/slapos!444
-
- 20 Nov, 2018 3 commits
-
-
Łukasz Nowak authored
server-alias and custom_domain can be wildcards, so support such case. /reviewed-on nexedi/slapos!446
-
Łukasz Nowak authored
authorised --> authorized
-
Łukasz Nowak authored
Because of checking slave id in a whole string, slaves which shall not be authorized has been put on authorized list. Example: -frontend-authorized-slave-string == "custom_http", slave_id = "custom" has been authorized.
-
- 17 Sep, 2018 1 commit
-
-
Łukasz Nowak authored
Each slave rejected by the frontend will report back detailed information to slave requester in key request-error-list being [json_list_of_found_errors]
-