I hereby claim:
- I am fedorg on github.
- I am fedorg (https://keybase.io/fedorg) on keybase.
- I have a public key ASDUg9HPjirf-iCDvb5GiUXL24VahT0GBQidFifBGBke5go
To claim this, I am signing this object:
meta: | |
id: cdx | |
file-extension: cdx | |
title: CambridgeSoft ChemDraw CDX | |
endian: le | |
ks-version: 0.8 | |
encoding: ascii | |
seq: | |
- id: header |
I hereby claim:
To claim this, I am signing this object:
#!/usr/bin/bash | |
set -Eeuxo pipefail | |
if [ true ]; then | |
if [ $(id -u) -eq 0 ] ; then | |
echo "Error: need to call this script as regular user!" | |
exit 1 | |
fi |
{ | |
"title": "Caddy v2 autogenerated JSON schema https://github.com/fedorg/caddy-json-schema", | |
"description": ": object\nhttps://pkg.go.dev/github.com/caddyserver/caddy/v2#Config\nConfig is the top (or beginning) of the Caddy configuration structure.\nCaddy config is expressed natively as a JSON document. If you prefer\nnot to work with JSON directly, there are [many config adapters](/docs/config-adapters)\navailable that can convert various inputs into Caddy JSON.\n\nMany parts of this config are extensible through the use of Caddy modules.\nFields which have a json.RawMessage type and which appear as dots (•••) in\nthe online docs can be fulfilled by modules in a certain module\nnamespace. The docs show which modules can be used in a given place.\n\nWhenever a module is used, its name must be given either inline as part of\nthe module, or as the key to the module's value. The docs will make it clear\nwhich to use.\n\nGenerally, all config settings are optional, as it is Caddy convention to\nhave good, doc |
node_env='development' | |
node_image='node' | |
function run_node() { | |
args=( "$@" ) | |
shift | |
binary="${args[0]}" | |
docker run --net=host --user $(id -u):$(id -g) -it --rm -e HOME=$HOME -e NODE_ENV=$node_env -v $HOME:$HOME -v $(pwd):/usr/app/ -w /usr/app --entrypoint $binary $node_image $@ | |
} | |
function npm() { run_node npm $@; } |
In this tutorial, we'll walk through the steps to share administrator access from one AWS account (Account A) to another AWS account (Account B). This will allow users in Account B to manage resources and perform administrative tasks on resources in Account A. We'll use AWS Identity and Access Management (IAM) roles and cross-account access to achieve this.
# Number of CPUs to be allocated to the virtual machine. | |
# Default: 2 | |
cpu: 8 | |
# Size of the disk in GiB to be allocated to the virtual machine. | |
# NOTE: changing this has no effect after the virtual machine has been created. | |
# Default: 60 | |
disk: 60 | |
# Size of the memory in GiB to be allocated to the virtual machine. |
#include <FastLED.h> | |
#define LED_PIN 13 | |
#define LED_BUILTIN 2 | |
// How many NeoPixels are attached to the Arduino? | |
#define NUMPIXELS 180 // Popular NeoPixel ring size | |
#define DELAYVAL 10 // Time (in milliseconds) to pause between frames | |
CRGB leds[NUMPIXELS]; | |
int iter_id = 0; |