An error occurred fetching the project authors.
- 20 Oct, 2020 7 commits
-
-
Łukasz Nowak authored
stop-on-error during instantiation can lead to endless instantiation in some cases, which disallows to create services required for given part to pass, and in the same time in many cases the called scripts are smart enough to continue and restart on error.
-
Łukasz Nowak authored
-
Łukasz Nowak authored
-
Łukasz Nowak authored
It's a dict, and in SlapOS usage of Jinja2 it's good to see the type of a variable immediately.
-
Łukasz Nowak authored
"parameter_dict" says nothing, whereas "software_parameter_dict" explains source and purpose of the information.
-
Łukasz Nowak authored
There is needless duplication of information.
-
Łukasz Nowak authored
That's true, that those are templates, but the important information which shall be in the name of the parameter is its purpose - a profile.
-
- 25 Sep, 2020 2 commits
-
-
Łukasz Nowak authored
Thanks to using check_execute_command with logrotate -d one can assure, that logrotate is for sure correctly configured.
-
Łukasz Nowak authored
By disabling delaycompress filenames are going to be stable, on delaying the compression is not needed.
-
- 24 Sep, 2020 1 commit
-
-
Łukasz Nowak authored
Because of escaping of slapos.cookbook:wrapper kedifa is never reloaded, so use instead jinja2 with template_wrapper for it. Also adapt to kill from dash (-HUP).
-
- 30 Jul, 2020 1 commit
-
-
Łukasz Nowak authored
Logs are critical for caddy-frontend, so let's configure rotate-num locally, as changes in the stack can come unattended, and can result with loosing logs.
-
- 24 Mar, 2020 1 commit
-
-
Łukasz Nowak authored
-
- 02 Mar, 2020 3 commits
-
-
Łukasz Nowak authored
This allows to use monitor-setup-url correctly.
-
Ł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.
-
Łukasz Nowak authored
-
- 19 Nov, 2019 2 commits
-
-
Łukasz Nowak authored
-
Ł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
-
- 01 Oct, 2019 2 commits
-
-
Łukasz Nowak authored
-
Łukasz Nowak authored
-
- 27 Sep, 2019 1 commit
-
-
Łukasz Nowak authored
Sorting will make dumped data "canonical", so it will limit amount of order based changes.
-
- 02 Aug, 2019 1 commit
-
-
Łukasz Nowak authored
This allows much better understanding for long running Kedifa processes.
-
- 10 Jul, 2019 1 commit
-
-
Łukasz Nowak authored
As Kedifa speaks HTTP check that it can reply with HTTP, not that just it is possible to connect to. /reviewed-on nexedi/slapos!591
-
- 28 May, 2019 1 commit
-
-
Łukasz Nowak authored
Kedifa partition was missing monitoring at all, so add it and monitor kedifa and exposer ip and port. Partition running caddy was missing monitoring for exposer, so add it.
-
- 08 May, 2019 1 commit
-
-
Łukasz Nowak authored
It is needed by users to check certificate of KeDiFa while uploading certificates.
-
- 16 Apr, 2019 1 commit
-
-
Łukasz Nowak authored
This also means that caddy source is fetched directly from upstream, as all required fixes has been incorporated into the upstream. Since https://github.com/mholt/caddy/releases/tag/v0.11.4 TLS-SNI challenge is replaced by ACME TLS-ALPN challenge, so switch has changed. Drop direct usage of gowork for now, in order to have caddy built using go module, support for gowork with go modules might come later. /reviewed-on nexedi/slapos!544
-
- 26 Mar, 2019 1 commit
-
-
Thomas Gambier authored
-
- 13 Mar, 2019 3 commits
-
-
Ł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.
-