We just got this email:
We've been working with Jetstack, the authors of cert-manager, on a
series of fixes to the client. Cert-manager sometimes falls into a
traffic pattern where it sends really excessive traffic to Let's
Encrypt's servers, continuously. To mitigate this, we plan to start
blocking all traffic from cert-manager versions less than 0.8.0 (the
current semver minor release), as of November 1, 2019. Please upgrade
all of your cert-manager instances before then.
We're sending this email because this is the contact address of your
cert-manager instance at:
185.236.240.37 .
Version 0.8.0 is much better but we still observe excessive traffic in
some cases. We're working with Jetstack to improve these cases. As new
versions of cert-manager are released, we will add the non-current
versions to our block list after 3 months. We strongly encourage
cert-manager users to stay up-to-date with new versions.
Also, there is an opportunity to help both Jetstack and Let's Encrypt.
Once you've upgraded, please check the logs for your cert-manager
instances from time to time. Are they making excessive requests to Let's
Encrypt (more than, say, 10 per day over multiple days)? If so, please
share details at https://github.com/jetstack/cert-manager/issues/1948 .
Thanks,
Let's Encrypt Team
Change-Id: Ic7152150ac1c96941423878c6d4b6209e07429cf
We seem to be hitting a bug where the encryptor doesn't initialize
because of a lacking gpg binary, and then crashes on .Close().
This should fix the issue, but is untested.
goroutine 70 [running]:
code.hackerspace.pl/hscloud/bgpwtf/cccampix/pgpencryptor/gpg.(*CLIEncryptor).Close(0x0)
bgpwtf/cccampix/pgpencryptor/gpg/gpg.go:144 +0x22
main.(*service).Encrypt(0xc000345e00, 0x16d13a0, 0xc00047f260, 0x1688400, 0xc00003d4a0)
bgpwtf/cccampix/pgpencryptor/main.go:132 +0x6f9
code.hackerspace.pl/hscloud/bgpwtf/cccampix/proto._PGPEncryptor_Encrypt_Handler(0x133bf00, 0xc000345e00, 0x16c6300, 0xc0000d6000, 0x2247b78, 0xc0001f8000)
bazel-out/k8-fastbuild/bin/bgpwtf/cccampix/proto/linux_amd64_stripped/ix_go_proto%/code.hackerspace.pl/hscloud/bgpwtf/cccampix/proto/ix.pb.go:1816 +0xad
google.golang.org/grpc.(*Server).processStreamingRPC(0xc000160c00, 0x16d6ce0, 0xc000161500, 0xc0001f8000, 0xc0004244e0, 0x21b00e0, 0xc0000c6ff0, 0x0, 0x0)
external/org_golang_google_grpc/server.go:1175 +0xacd
google.golang.org/grpc.(*Server).handleStream(0xc000160c00, 0x16d6ce0, 0xc000161500, 0xc0001f8000, 0xc0000c6ff0)
external/org_golang_google_grpc/server.go:1254 +0xcbe
google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc000404770, 0xc000160c00, 0x16d6ce0, 0xc000161500, 0xc0001f8000)
external/org_golang_google_grpc/server.go:690 +0x9f
created by google.golang.org/grpc.(*Server).serveStreams.func1
external/org_golang_google_grpc/server.go:688 +0xa1
created by google.golang.org/grpc.(*Server).serveStreams.func1
external/org_golang_google_grpc/server.go:688 +0xa1
Change-Id: Idd167a120e157005f44d255a61ef13dc80e8eeed
We accidentally created crdb-waw2 in
https://gerrit.hackerspace.pl/c/hscloud/+/2.
We remove it now and also backport a manual change that makes the
crdb-waw1 service public via a LoadBalancer.
Change-Id: I3bbd6f01b82c6efa458cc44776f086ba36e9f20c
This uses github.com/golang-migrate/migrate and adds a Source that
allows using go_embed data files.
We also provide a test/example.
Change-Id: Icd2b6c7f7d0f728073b3fdf39b432b33ce61a3cd
We add a small IRR service for getting a parsed RPSL from IRRs. For now,
we only support RIPE and ARIN, and only the following attributes:
- remarks
- import
- export
Since RPSL/RFC2622 is fucking insane, there is no guarantee that the
parser, especially the import/export parser, is correct. But it should
be good enough for our use. We even throw in some tests for good
measure.
$ grpcurl -format text -plaintext -d 'as: "26625"' 127.0.0.1:4200 ix.IRR.Query
source: SOURCE_ARIN
attributes: <
import: <
expressions: <
peering: "AS6083"
actions: "pref=10"
>
filter: "ANY"
>
>
attributes: <
import: <
expressions: <
peering: "AS12491"
actions: "pref=10"
>
filter: "ANY"
>
>
Change-Id: I8b240ffe2cd3553a25ce33dbd3917c0aef64e804
We start having the need to have our own production image instead ofjust
a bare Ubuntu image. For instance, octorpki will need rync and TLS CA
bundles.
Change-Id: Ia8d9604ae8c320f858cfe8a2dc21ddcc321017ff
Nixops requires nix_rules, which in turn requires a working nix
installation.
When we split tools/install.sh into tools/install.sh and
cluster/tools/install.sh [1], we accidentally made the latter always install
all cluster tools, including nixops - even if the install.sh script
detected that the system does not have Nix installed.
[1] - https://gerrit.hackerspace.pl/c/hscloud/+/81
Change-Id: Ib5357cfe125f1393b395b28062787f3f0091f549
This makes a registry be automatically part of the cluster
infrastructure.
Tested by running kubecfg diff, no diffs (apart from out-of-date ACLs)
found.
Change-Id: Ic0635e789cf3fb851f410bcf2865326f1fa87545