This guide is for homelab admins who understand IPv4s well but find setting up IPv6 hard or annoying because things work differently. In some ways, managing an IPv6 network can be simpler than IPv4, one just needs to learn some new concepts and discard some old ones.
Let’s begin.
First of all, there are some concepts that one must unlearn from ipv4:
Concept 1
| FROM quay.io/keycloak/keycloak:17.0.0 as builder | |
| ENV KC_METRICS_ENABLED=true | |
| ENV KC_FEATURES=preview | |
| ENV KC_DB=postgres | |
| ENV KC_HTTP_RELATIVE_PATH=/auth | |
| # specify the custom cache config file here | |
| ENV KC_CACHE_CONFIG_FILE=cache-ispn-jdbc-ping.xml | |
| # copy the custom cache config file into the keycloak conf dir |
| default['sshd']['sshd_config']['AuthenticationMethods'] = 'publickey,keyboard-interactive:pam' | |
| default['sshd']['sshd_config']['ChallengeResponseAuthentication'] = 'yes' | |
| default['sshd']['sshd_config']['PasswordAuthentication'] = 'no' |
(This is a translation of the original article in Japanese by moratorium08.)
(UPDATE (22/3/2019): Added some corrections provided by the original author.)
Writing your own OS to run on a handmade CPU is a pretty ambitious project, but I've managed to get it working pretty well so I'm going to write some notes about how I did it.
| version: '2.4' | |
| services: | |
| target: | |
| privileged: true | |
| network_mode: "host" | |
| ipc: "host" | |
| restart: always | |
| volumes: | |
| - '/etc/localtime:/etc/localtime:ro' | |
| - '/edgefs/var/run:/opt/nedge/var/run:z' |
Now that pkgin has refresh support and the macOS trunk builds have proven that a rolling trunk release works well, I am happy to make SmartOS/illumos trunk packages and images available again for testing.
These are rolling builds of pkgsrc trunk every day (or so), providing the latest packages without having to upgrade across quarterly releases. Just install once then pkgin full-upgrade to keep up-to-date.
This is primarily of interest to:
This is a work-in-progress, but aims to help navigate the murky waters
of setting _XOPEN_SOURCE in such a way that it is compatible across C
standards on SunOS systems.
A table is worth a thousand words. Defines used in a default compilation
environment (i.e. no -std=.. specified):
| # Start Envoy with RBAC filter, you need to use the latest upstream envoy with RBAC filter support. | |
| # Note: the static config include a RBAC rule that only allows access to path "/allow" | |
| $ envoy -l debug -c sample_rbac_config.yaml | |
| # Start a test server listening on 10001 | |
| $ while true; do echo -e "HTTP/1.1 200 OK\n\n Welcome" | nc -l 127.0.0.1 10001 -q 1; done | |
| # First let's try to access a path that is not included in the RBAC policy | |
| # Check the response is: "RBAC: access denied". This means the request was denied by RBAC filter and didn't access the test server | |
| $ curl http://127.0.0.1:9999/hello |
| # Copyright 2017 The TensorFlow Authors. All Rights Reserved. | |
| # | |
| # Licensed under the Apache License, Version 2.0 (the "License"); | |
| # you may not use this file except in compliance with the License. | |
| # You may obtain a copy of the License at | |
| # | |
| # http://www.apache.org/licenses/LICENSE-2.0 | |
| # | |
| # Unless required by applicable law or agreed to in writing, software | |
| # distributed under the License is distributed on an "AS IS" BASIS, |
| To support encryption, Message Format associated with messages now needs to store the encryption key. | |
| Since we need to encrypt/decrypt both the User Metadata and the Blob payload, we have two choices: | |
| a) Duplicate the key within both the User Metadata subrecord and Blob subrecord. This is the least | |
| invasive change and has some merits, but has the burden of duplication of keys. | |
| b) Create a new Blob Encryption Key record and store the key just once. | |
| We decided to go with the second approach that avoids duplication and lends itself better to potential | |
| use cases such as key replacements. |
