| package safebuffer | |
| import ( | |
| "bytes" | |
| "sync" | |
| ) | |
| // Buffer is a goroutine safe bytes.Buffer | |
| type Buffer struct { | |
| buffer bytes.Buffer |
| #!/bin/bash | |
| # vpnc-script wrapper for use with openconnect that routes all AWS IP ranges over the VPN. | |
| # Pass any additional IP ranges to be routed as args to the script. | |
| # | |
| # Requirements: bash, curl and jq. | |
| # | |
| # Example usage: | |
| # openconnect https://vpn.example.com/profile --script '/path/to/vpnc-script-aws' | |
| # |
On the 14th of October HAProxy 1.6 was released! Among all features announced I am particularly interested in the ability to log the body of a request.
It wasn't straightforward for me to understand how to do that, which is why I'm blogging it.
The relevant part could be found in the "Captures" section of the announcement, this is how I changed it to suit my needs:
# you need this so that HAProxy can access the request body
Especially starting with Windows 10, it isn't all that bad to work on day to day. It just requires a bit of setup out of the box to make it behave better just like those other platforms, and is sufficiently different so as to be non obvious to experienced Linux or macOS users.
Pick and choose what to do from below that fits your needs.
Note: I use emacs, like emacs keybindings and do a bit of Chef development,
| input { stdin { } } | |
| filter { | |
| grok { | |
| match => ["message", "%{HAPROXYHTTP}"] | |
| remove_field => ["message"] | |
| } | |
| mutate { | |
| convert => { "actconn" => "integer" | |
| "backend_queue" => "integer" | |
| "beconn" => "integer" |
Currently, there is an explosion of tools that aim to manage secrets for automated, cloud native infrastructure management. Daniel Somerfield did some work classifying the various approaches, but (as far as I know) no one has made a recent effort to summarize the various tools.
This is an attempt to give a quick overview of what can be found out there. The list is alphabetical. There will be tools that are missing, and some of the facts might be wrong--I welcome your corrections. For the purpose, I can be reached via @maxvt on Twitter, or just leave me a comment here.
There is a companion feature matrix of various tools. Comments are welcome in the same manner.
| export PROFILE=XXXX | |
| for USER in `aws --profile $PROFILE iam list-users --query 'Users[].UserName' --output text` | |
| do | |
| for KEY in `aws --profile $PROFILE iam list-access-keys --user-name "$USER" --query 'AccessKeyMetadata[].AccessKeyId' --output text` | |
| do | |
| echo $USER $KEY | |
| done | |
| done |
This is a copy/paste from an internal wiki on how we should use docker
This guide is to serve as an outline of internal best practices to using Docker. The idea is to give enough information to allow engineers to create containers for new stack components while minimizing the cleanup required to make them production ready.
Before we get to the practices, it's important to understand WHY we are doing this. The key concepts we're concerned about with broad Docker usage are provenance, determinism, repeatability and auditability.
Provenance refers to knowing WHERE something comes from. Generally with the end use of software, this is easy:
| #!/bin/bash | |
| #no PATH, no way to accidently run any programs | |
| PATH='' | |
| #useful variables | |
| term_height=0 | |
| term_width=0 | |
| term_scroll_height=0 | |
| status_line_row=0 |
| ### | |
| ### | |
| ### UPDATE: For Win 11, I recommend using this tool in place of this script: | |
| ### https://christitus.com/windows-tool/ | |
| ### https://github.com/ChrisTitusTech/winutil | |
| ### https://www.youtube.com/watch?v=6UQZ5oQg8XA | |
| ### iwr -useb https://christitus.com/win | iex | |
| ### | |
| ### |
