fedorg

meta:
  id: cdx
  file-extension: cdx
  title: CambridgeSoft ChemDraw CDX
  endian: le
  ks-version: 0.8
  encoding: ascii

seq:
  - id: header

fedorg

Keybase proof

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:

fedorg

#!/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

fedorg

{
  "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

fedorg

<style> @font-face { font-family: 'Daytona'; /* src: url("../fonts/NotoSans-Regular.ttf") format("truetype"); */ src: url("../fonts/BCDFEE_Daytona.ttf") format("truetype"); } body { font-family: 'Daytona' !important; font-size: 14px; margin: -0em 0px;

fedorg

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 $@; }

fedorg

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.

Prerequisites:

1. You must have administrative access to both AWS accounts (Account A and Account B).
2. Familiarity with AWS IAM and its concepts.

Step 1: Create a Role in Account A

1. Log in to the AWS Management Console for Account A.

fedorg

# 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.