b0bu

monkey patch

from pytest import MonkeyPatch
import boto3

@mock_codebuild
def test_start_project(monkeypatch: MonkeyPatch) -> None:
    client = boto3.client("codebuild")

     def account_id(self) -> str:

b0bu

fork() causes the current process to reun itself again and these lines of execution run concurrently from the point at which fork() is called.

A process is a program in execution. The main process has a line of execution. For each call to fork() that line of execution splits. The main process continues but there is now a child process which continues from the same point. If fork() is called once, then a new branch of exection spins off and each branch exectes the same code from the same point forward, even another call to fork()

For every subsequent fork() each current line of execution must branch. For 1 call it's 2 branches, for 2 it's 4, for 3 it's 8 and so on. total_pids = 2^number_of_forks.

b0bu

c, m, e, n and d

Once you have a mathematically linked key pair understanding the relationship doesn't start with CAs or root trust trees or ascii armoured blobs, that's essential and usually a person's first and only experience with certificates. It starts by understanding that a key pair's purpose is primarily for one to reverse the other. PKI specifically uses this property of asymmetric behaviour (typically rsa) to generate and establish a secure symmetrically encrypted session (typically aes). The key pair such as they are are wrapped up a notion of standards of trust, issuance and revocation but it's the numbers within that are the vehicle to achieve a symmetrically encrypted session. And it starts with the letters c, m, e, n and d.

enciphering

Cipher text c is generated from a function f(x) that takes m the message data to be enciphered and the public key or (modulus, exponent) which we'll call (n, e) from here on out. n and e are what's called "public numbers". Key pairs are ma

b0bu

Hello, world. v1.15.11 is indeed deprecated by azure kubernetes service, let's not try to build that. This policy can stop you building or for that matter destroying a cluster that's fell off the bottom of azure's N-2 version's sla unintentionally. There's enough in here that you could probably do some pretty cool things with external dependency calls, regardless of aks or azure. We use opa quite a bit, with gatekeeper as a mutating admission controller within our cluster and external in our build and deploy pipelines. You can use this or the concept in general to stop anything crazy from going down when no one is watching. I can't imagine living without it.

Here's a mock cluster tf file

// 1.15.11.tf
resource "azurerm_kubernetes_cluster" "cluster" {
  name                = "cluster"
  resource_group_name = "cluster"
  location            = "uksouth"

b0bu

I'd like to talk about custom acme protocol clients this time. I'm just showing some dummy implementation code here with the threading removed and auth removed, to show how you might go about setting up core interface that can obtain certificates from an le environment endpoint. This is part of a client that I may open source in the next few weeks as it's widely deployed at my company and solved an automation and provisioning problem.

The usecase for writing your own is to have more granular programmatic control over dns record creation and to speed up the io bound process of obtain a certificate by threading it and batching the threads based on rate limits.

from providers.mycustomdns import client as dns
from acme import client as acme

class EmptyDomainListError(Exception):

b0bu

I have 2 member servers on an L2 network

I have some post deploy sanity checks to do on proxy pairs using keepalived where after initial deployment or changing the vip configuration the 'network' subset of ansible_facts is too slow in regathering. I.e. if a service is broken, I'm not going to sit there for 3 minutes or longer waiting for ansible to crawl my servers. The solution is to just pull the information you need, and test it.

requirements

Where vip can be vips and states can be:

vip server1 - proceed
vip server2 - proceed
vip no servers - error

b0bu

Fact gathering can take a long time, especially on centos/rhel boxes and especially on proxies where your open file limit might be high. 2-3 minutes or longer. If I have a play that's only supposed to run some of the time based on a combination or when: or tag: statements but I need that play to gather facts it can slow down / gather facts at the wrong play. This if anything, gives the illusion that that play is actually doing something when it's not even supposed to be running. When your automation runs in a pipelines and no ones watching it you want to make sure that the feedback and logging is as clean as possible. I.e. what ran was all that was supposed to run in the way it was supposed to be ran.

You can gather facts on a certain play based on whether the tag that runs that plays tasks was provided to the ansible engine. Now this play won't gather facts and won't log as having done anything unless keepalived is explicitly provided on the command line. Gathering of facts will fall through to subseq

b0bu

tldr; Don't just test a whitelist based on an initial pass/fail. An update to that whitelist or addition of a parameter to a use_backend statement alone can cause a routing mess.

I don't normally say things like "the right way" but in this case attention to detail is usually always the right way. We had two use_backend statements in haproxy shown below where when an IP address wasn’t in the whitelist it would be routed straight to production. The proposed fix for this meant that traffic in the whitelist would always be routed to production. Which is the opposite of what I believe was intended in both cases.

  use_backend b1 if host-site worldpay_callback worldpay_whitelist worldpay_env_dev worldpay_auth
  use_backend b2 if host-site worldpay_callback worldpay_whitelist worldpay_env_prd worldpay_auth

This works, you can put whitelist evaluation in a use_backend statement but if it's nested inside a larger scope and the logic falls through it's going to bite you. Troubleshooting this par

b0bu

Something I thought was super interesting

# %%
from array import array

list_of_1_million_signed_ints = list(range(0, 10**6))
array_of_1_million_signed_ints = array("I", list_of_1_million_signed_ints)

print(f"size of list in mb {list_of_1_million_signed_ints.__sizeof__() / 2**20:.2f}MiB")
print(f"size of array in mb {array_of_1_million_signed_ints.__sizeof__() / 2**20:.2f}MiB")

b0bu

Quick only the fly without having to change the playbook (you won't have groups though)

 ansible-playbook playbook.yml --connection=local --inventory 127.0.0.1, --tags whatever