An error occurred fetching the project authors.
  1. 20 Dec, 2023 1 commit
    • Titouan Soulard's avatar
      software/rapid-cdn: avoid RegExp to validate hostnames · 11336190
      Titouan Soulard authored
      Using RegExp to validate hostnames is a bad practice, and has a lot of reasons to be wrong.
      On top of that, the JSON Schema specification allows, since draft 7, to validate hostnames
      against an IDN hostname, by using the `idn-hostname` format.
      
      With these changes, IDN are now supported (.рф and .中國 for instance), and long TLD
      should not be a problem anymore.
      11336190
  2. 17 Apr, 2023 1 commit
  3. 09 Jan, 2023 3 commits
    • Łukasz Nowak's avatar
      rapid-cdn: c->h: Implement ciphers · 102cfd02
      Łukasz Nowak authored
      Cipher translation is implented on the node, so that old style and new style
      nodes can co-exists in the same cluster, thus making partial upgrade possible.
      102cfd02
    • Łukasz Nowak's avatar
      rapid-cdn: c->h: Start switch from Caddy to Haproxy · 44d9483c
      Łukasz Nowak authored
      mpm-graceful-shutdown-timeout is dropped, as it's historical leftover and never
      really useful in the caddy-frontend CDN usage context - stopping the server is
      the most rare situation, and any grace period is solved eventually outside of
      the running process (like redirecting traffic elsewhere before stopping).
      44d9483c
    • Łukasz Nowak's avatar
      rapid-cdn: Introduce · 643457a3
      Łukasz Nowak authored
      It's based on phased out caddy-frontend, especially as next step is to drop
      Caddy software from the software release.
      643457a3
  4. 19 Oct, 2022 1 commit
  5. 17 Oct, 2022 2 commits
  6. 07 Mar, 2022 1 commit
    • Łukasz Nowak's avatar
      caddy-frontend: Switch to full CSR analysis · 615bfd3e
      Łukasz Nowak authored
      Instead of trusting CSR id published by the node which tries to join the
      cluster add a tool which is able to compare exposed CSR with one in caucase
      and then decide to accept node in the cluster. This tool does what usual user
      would do, and it's logic implemented as a script leads to much simpler profiles.
      
      For sake of clean profiles csr_id has been removed, except when it's used for
      self joining of the user to the cluster.
      615bfd3e
  7. 25 Feb, 2021 2 commits
  8. 27 Jan, 2021 1 commit
  9. 26 Jan, 2021 2 commits
  10. 17 Jul, 2020 2 commits
    • Łukasz Nowak's avatar
      caddy-frontend: Setup backend client auth · 3be5f4ce
      Ł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.
      3be5f4ce
    • Łukasz Nowak's avatar
      caddy-frontend: Put haproxy just before the backend · ec3d4ae9
      Łukasz Nowak authored
      This is needed in order to provide future support for client certificates
      to the backend.
      
      Also it means that haproxy is used in all cases, with or without cache, and as
      a result the "cached" version of caddy is dropped.
      
      Let haproxy setup maxconn by itself, as it's wise enough.
      
      Also trust that it'll detect and use proper limits, instead enforcing them in
      the shell with ulimit trick (ulimit -n $(ulimit -Hn)).
      
      As empty server alias can impact the configuration, add proper test for
      checking it.
      ec3d4ae9
  11. 22 Jun, 2020 2 commits
  12. 30 Aug, 2019 1 commit
  13. 18 Jul, 2019 1 commit
  14. 19 Jun, 2019 1 commit
  15. 14 Jun, 2019 1 commit
  16. 28 May, 2019 1 commit
  17. 23 Apr, 2019 1 commit
  18. 13 Mar, 2019 3 commits
    • Łukasz Nowak's avatar
      caddy-frontend: Switch AIKC to default true · a198be7f
      Łukasz Nowak authored
      It is better to have automation similar to previous implementation by
      default.
      a198be7f
    • Łukasz Nowak's avatar
      caddy-frontend: Implement AIKC · 28a1283d
      Ł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.
      28a1283d
    • Łukasz Nowak's avatar
      caddy-frontend: Implement KeDiFa SSL information · bc2b1742
      Ł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.
      bc2b1742
  19. 08 Feb, 2019 1 commit
    • Łukasz Nowak's avatar
      caddy-frontend: Fix random 502 EOFs by adding try_duration · 4f168972
      Łukasz Nowak authored
      try_duration and try_interval are Caddy proxy's switches which allow to deal
      with non working backend (https://caddyserver.com/docs/proxy)
      
      The non working backend is the one, to which connection is lost or was not
      possible to make, without sending any data.
      
      The default try_duration=5s and try_interval=250ms are chosen, so that in
      normal network conditions (with all possible problems in the network, like
      lost packets) the browser will have to wait up to 5 seconds to be informed
      that backend is inaccessible or for the request to start being processed,
      but only a bit more than 250ms if Caddy would have to reestablish connection
      to faulty backend.
      
      In order to check it out it is advisable to setup a system, with real backend,
      like apache one, and configure iptables to randomly reject packets to it:
      
        iptables -A INPUT -m statistic --mode random -p tcp --dport <backend_port> \
        --probability 0.05 -j REJECT --reject-with tcp-reset
      
      Using ab or any other tool will results with lot of 502 EOF in the Caddy error
      log and also reported by ab. With this configuration there are no more
      errors visible to the client, which come from the problems on the network
      between Caddy and the backend.
      4f168972
  20. 17 Jan, 2019 1 commit
  21. 20 Nov, 2018 1 commit
  22. 03 Sep, 2018 1 commit
  23. 06 Aug, 2018 1 commit
  24. 28 Jun, 2018 1 commit