Forem: Scott

Important thing to remember about recovering panic'ed code in Go

Scott — Mon, 13 Sep 2021 13:12:29 +0000

When recovering from panic in golang, I have often found myself troubled by potentially not knowing where the error originated...

This was because the stack doesn't get passed along with the message when you recover... or so I thought.

Go's runtime actually handles recovery from panic in an interesting way. Stack trace wise, it allows deferred functions the ability to call debug.Stack() as if from the location of the panic.

for example:

package main

import (
    "log"
    "runtime/debug"
)

func main() {
    defer func() {
        if e := recover(); e != nil {
            log.Printf("%s: %s", e, debug.Stack())
        }
    }()

    f1()
}

func f1() {
    f2()
}

func f2() {
    f3()
}

func f3() {
    panic("some error")
}

the stack trace output from the above code produces the following.

2021/09/13 22:00:07 some error: goroutine 1 [running]:
runtime/debug.Stack(0xc00009bdb8, 0x4acd60, 0x4e5168)
        /home/rustysysdev/go/src/runtime/debug/stack.go:24 +0x9f
main.main.func1()
        /home/rustysysdev/Documents/panic-test/cmd/panic/main.go:11 +0x5b
panic(0x4acd60, 0x4e5168)
        /home/rustysysdev/go/src/runtime/panic.go:965 +0x1b9
main.f3(...)
        /home/rustysysdev/Documents/panic-test/cmd/panic/main.go:27
main.f2(...)
        /home/rustysysdev/Documents/panic-test/cmd/panic/main.go:23
main.f1(...)
        /home/rustysysdev/Documents/panic-test/cmd/panic/main.go:19
main.main()
        /home/rustysysdev/Documents/panic-test/cmd/panic/main.go:15 +0x5e

this is very useful for troubleshooting and I feel stupid only figuring this out now. XD

source: https://groups.google.com/g/golang-nuts/c/MB8GyW5j2UY

Setup Recent Xiaomi Phones on Rakuten Mobile

Scott — Sun, 12 Sep 2021 07:31:19 +0000

Warning: Before you bring a phone into japan you should check whether it is supported by your carrier's network bands at the below link.

注意：携帯を日本に輸入する前にちゃんと自分が使いたいネットワークの周波数を対応していることを下記のリンクから確認してください。

https://gajeota.com/search

So it took me some work to get my new Redmi K40 Gaming working with Rakuten Mobile here in Japan. It was a pain so I want to share the procedure that worked for me.

最近買った Xiaomi Redmi K40 Gaming を楽天モバイルに使えるように設定するのが苦労した。面倒だったなので使った手順を共有したい。

The procedure itself is rather simple, and is comprised of hidden settings.

Manually specify network protocols
Unlock VoLTE (Voice over LTE)

手順自体はかなりシンプルで、二つの隠し設定を開かないといけない。

ネットワークプロとコールを手動設定
VoLTE を解放

Step 1 / 隠し設定1

The first step of the solution I stumbled across, and was pretty lucky, otherwise it might have been much more difficult. That being said, if your phone happens to properly connect to the network after inserting the sim card you can skip this step.

最初の隠し設定を混乱のなかで偶然に見つけちゃった。。そうではなければ今までも解決してないだろう。。ところでシムを本体にさしてネットワークは最初から動くのならこの設定はしなくても良いとおもう。

First open your settings and click on My Device
先ず設定を開いて My Device をクリック

Next open your device's All Specs page
次は `All Specs のページを開く

This is where our hidden setting is located. Click on the Internal Storage field 5 to 10 times.. or until you move to the Testing page
ここで隠し設定はある、Internal Storage を Testing ページに移動するまで連続クリック（5〜10かい程度）

Click on the Phone Information1 button.
ここでは Phone Information1 をクリック

Set Prefered Network Type to NR/LTE If the phone doesn't connect in 10 seconds try some other protocol combinations until it does.

NOTE: this may lock your phone to certain protocols so just know that NR = 5G and LTE = 4G. Everything else is typically 3G and below!

注目：NR は 5G と LTE は 4G のネットワークをしめしているその他のは3Gとその以下

ここでは Set Prefered Network Type を NR/LTE に設定、10秒程度で携帯が接続するはずが、接続できなかった場合、上記の注目を認識したの上で他の組み合わせを試すといい

Step 2 / 隠し設定2

The second step is pretty simple, and I found on a youtube video, and seems to be the universal way of locking and unlocking VoLTE on phones.

隠し設定2のも大した難しくはないけどしらないと。。youtube で答えを見つけたところにどんな Xiaomi 機種でも VoLTE を有無の一般的な設定方法らしい。

Simply open your the phone app and input the following phone code.
電話アプリを開いて下記のコードを入力

*#*#86583#*#*

As soon as you input the code you should see a message similar to VoLTE has been enabled or possibly VoLTE has been disabled. This message is apparently buggy... so don't worry about it quite yet.
入力だけで VoLTE は有効になった または VoLTE は有効になった のようなメッセージは表示される。無効になったと言っても取り敢えず進んでください。

First we need to find the VoLTE setting which should now be available in your sim card's settings menu. Open your settings.
先ず上記の手順で現れた VoLTE 設定をみつけよう。携帯の設定を開く

Select your Rakuten sim card.
Rakuten のシムを選択

Check that you have a VoLTE Setting here, and that it is enabled. If the setting doesn't exist then go back and enter the code again.
この辺で VoLTE 設定は存在すると有効になっていることを確認してください。存在しなかった場合先ほどのコードをもう一度入力してみるがよい

Conclusion / 最後に

From here you should be able to install Rakuten Link and perform the necessary setup.

上記が終わったら、SMS と電話は両方使用可能になったはずので Rakuten Link のダウンロードと設定は可能なはす。。。

Understanding Yew Part 1

Scott — Thu, 07 Jan 2021 14:05:15 +0000

Hello! I am learning Yew for writing SPA's in Rust! I found some of the concepts difficult to understand at first and decided to take notes (simplifying the concepts for my stupid brain)..

I am planning on making this a series with the following.

1. Yew component and lifecycle overview
2. Yew router overview
3. Yew fetch service overview
4. Yew agents overview
5. Debugging (maybe)

Without further ado, lets get into part 1!

Overview

Components

Are semi-arbitrary Rust structures that~

Represent pecies of reusable HTML
Utilized by name in HTML
Have a defined lifecycle
Contain their own state
Recieve props from parent component

Components can contain many child components, but logically speaking have only one parent.

<!-- Parent Component -->
<div>
    <div>Main Component Text</div>
    <!-- Child Component with 2 properties -->
    <ChildComponent1 cc1prop1=1 cc1prop2=2 />
    <!-- Another Child Component with 1 property -->
    <ChildComponent2 cc2prop1=3 />
<div>

Data relationships between parent and child are as follows:

Parents may pass data as Props to Child Components
Parents may pass callbacks as Props
Child may update parent state using callback

With the above said, as an example if you have many child components that need to manage a common state, that state should be stored in a parent element.

Common Component Structure Properties

The struct created to define your component tends to have a couple of important and common parameters. For example~

struct MyComponent {
    // This is another arbitrary struct containing data
    // that YOU require for your application's state. 
    // You need to create this State struct, or whatever
    // you want to call it.
    state: State,
    // You will need to add this property if you intend
    // to interact with the Component API, i.e. adding 
    // callbacks to modify this component's state, or
    // sending update messages to call update() actions
    // on the component.
    link: ComponentLink<Self>,
    // Used in relation to calling external API's
    // I will follow up on this in a new article.
    task: None,
    // This is yet another arbitrary struct that you will
    // need to create in order to define properties sent
    // by a parent component.
    props: Props,
}

Component Implemetation

A components are implemented suprisingly enough by impl yew::Component for YOUR_COMPONENT {} required methods and types to implement are as follows:

Kind	Name	Description
Type	Properties	Properties to the component during lifecycle events. If none are to be passed this should be `()`. Otherwise you will need to define your `Props` struct.
Type	Message	An `enum` containing actions to process during a component lifecycle `update()`. `enum` members may contain parameters.
Method	create()	Initializes state and stores props from the parent
Method	update()	Called for whenever an update message is sent. `update()` should take appropriate action depending on the message sent.
Method	change()	This method conditionally re-renders the child component if props have changed during re-rendering of the parent.
Method	rendered()	This method is called after `view()` and performs functions that require the component to already be rendered. I.E. shift screen focus to element. (NOT REQUIRED)
Method	destroy()	Performs cleanup operations for a component (NOT REQUIRED)
Method	veiw()	Creates the HTML to render for the component.

Component Lifecycle

A components life begins when it its create() method is called. This typically happens in an html!() macro.

TODO: I feel I should give an example of this

Next its view() method is called and the component is rendered as HTML.

A component will be re-rendered on the following conditions.

A re-render is requested by the change() method.
A re-render is requested by the update() method.

A component will be destroyed when simply enough, its destroy() method is called.

Conclusion

I will revisit this for to update any errors or missing information, but for now I feel I have summed up yew components to my satisfaction. If anyone has any questions or notices any mistakes please let me know in the comments!

Creating service account IAM roles on EKS

Scott — Thu, 17 Dec 2020 14:22:32 +0000

As of the time of this writing AWS still seems to be working on their not so streamlined IAM for Service Accounts feature.

Its not difficult to get running but you have to jump through quite a few hoops especially when it comes to the command line.

If you do everything with eksctl or the AWS Console, then its really easy. If you didn't use eksctl to build your cluster and would like to make things simple and script it... well that's a different story.

What needs to happen

Create an OpenIDConnect Provider in IAM based off your EKS cluster's issuer URL. This requires the following.
- EKS cluster's issuer URL
- ClientID string: "sts.amazonaws.com"
- EKS cluster's domain footprint
Role for attaching to a service account. This requires the following.
- IAM Policy(s)
- trust relationship document
Create/Annotate your pod's service account

Whats the problem

Some of the requirements listed above are not so straightforward to obtain or setup. In particular two of them come to mind.

EKS cluster's domain footprint
Role trust relationship document

lets take a look at these.

Domain Footprint

This was the biggest issue I faced... and purely because the documentation for obtaining this in anyway other than the AWS Console is incorrect. In particular (2) in the linked document returns the following error.

{"message":"Missing Authentication Token"}

I tried for sometime to accomplish (2) but I eventually gave up and searched for another way. In my search I came across an issue in terraforms-provider-aws That gave me the clue I needed and I was finally able to move on after writing a function to not only grab the footprint but create the IAM provider if not exists.

function create_provider_if_not_exists() {
    local PROVIDER_LIST PROVIDER_ARN THUMBPRINT
    PROVIDER_LIST=$(aws iam list-open-id-connect-providers --query OpenIDConnectProviderList --output text)
    PROVIDER_ARN=$(for PROVIDER in ${PROVIDER_LIST}; do
        if [[ "${PROVIDER}" == *"${2}"* ]]; then
            echo "${PROVIDER}"
            return
        fi
    done)
    if ! [ "${PROVIDER_ARN}" ]; then
        FOOTPRINT=$(echo | openssl s_client -servername "${3}" -showcerts -connect "${3}":443 2>&- \
            | tac | sed -n '/-----END CERTIFICATE-----/,/-----BEGIN CERTIFICATE-----/p; /-----BEGIN CERTIFICATE-----/q' \
            | tac | openssl x509 -fingerprint -sha1 -noout \
            | sed 's/://g' | awk -F= '{print tolower($2)}')
        aws iam create-open-id-connect-provider \
            --url "${1}" \
            --client-id-list "sts.amazonaws.com" \
            --thumbprint-list "${FOOTPRINT}" \
            --query OpenIDConnectProviderArn
    fi
}

Role Trust Relationship

This wasn't particularly hard, just annoying if not automated. I used AWS documentation here and created a function to create and destroy the required document.

function create_trust_relationship_file() {
    local TRUST_RELATIONSHIP
    read -r -d '' TRUST_RELATIONSHIP <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "${1}"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "${1#*/}:sub": "system:serviceaccount:${3}:${2}"
        }
      }
    }
  ]
}
EOF
    echo "${TRUST_RELATIONSHIP}" > trust.json
}

function delete_trust_relationship_file() {
    rm -f trust.json
}

Complete Script

With that finished I just needed to fill in the blanks and got the following which creates required resources and gives you the service annotation to add to your service account.

function create_eks_pod_role() {
    local CLUSTER_NAME ROLE_NAME ROLE_DESCRIPTION CONTAINER_POLICY_ARN SERVICE_ACCOUNT_NAME
    local ISSUER_ADDRESS ISSUER_ID ISSUER_DOMAIN PROVIDER_ARN ROLE_ARN NAMESPACE
    function usage() {
        echo "Outputs rendered files for specified chart into current directory.
           ${FUNCNAME[0]} -
                   [-h] print this help
                   -c   Name of the EKS Cluster
                   -r   Name of the IAM role to create
                   -d   Description for IAM role
                   -p   IAM policy ARN of to attach to the role
                   -s   Name of the service account
                   -n   Namespace of the service account";
    }

    function check_policy_exists() {
        local POLICY_LIST POLICY
        POLICY_LIST="$(aws iam list-policies --query Policies[].Arn --output text)"
        for POLICY in ${POLICY_LIST}; do
            if [[ "${POLICY}" == "${1}" ]]; then
                return 0
            fi
        done
        echo "INVALID: your policy arn seems to be invalid please verify"
        return 1
    }

    function create_provider_if_not_exists() {
        local PROVIDER_LIST PROVIDER_ARN THUMBPRINT
        PROVIDER_LIST=$(aws iam list-open-id-connect-providers --query OpenIDConnectProviderList --output text)
        PROVIDER_ARN=$(for PROVIDER in ${PROVIDER_LIST}; do
            if [[ "${PROVIDER}" == *"${2}"* ]]; then
                echo "${PROVIDER}"
                return
            fi
        done)
        if ! [ "${PROVIDER_ARN}" ]; then
            FOOTPRINT=$(echo | openssl s_client -servername "${3}" -showcerts -connect "${3}":443 2>&- \
                | tac | sed -n '/-----END CERTIFICATE-----/,/-----BEGIN CERTIFICATE-----/p; /-----BEGIN CERTIFICATE-----/q' \
                | tac | openssl x509 -fingerprint -sha1 -noout \
                | sed 's/://g' | awk -F= '{print tolower($2)}')
            aws iam create-open-id-connect-provider \
                --url "${1}" \
                --client-id-list "sts.amazonaws.com" \
                --thumbprint-list "${FOOTPRINT}" \
                --query OpenIDConnectProviderArn
        else
            echo "${PROVIDER_ARN}"
        fi
    }

    function create_trust_relationship_file() {
        local TRUST_RELATIONSHIP
        read -r -d '' TRUST_RELATIONSHIP <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "${1}"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "${1#*/}:sub": "system:serviceaccount:${3}:${2}"
        }
      }
    }
  ]
}
EOF
        echo "${TRUST_RELATIONSHIP}" > trust.json
    }

    function delete_trust_relationship_file() {
        rm -f trust.json
    }

    # Set options
    while getopts ':c:r:d:p:s:n:' OPTION; do
        case "$OPTION" in
            c)
                CLUSTER_NAME="${OPTARG}"
            ;;
            r)
                ROLE_NAME="${OPTARG}"
            ;;
            d)
                ROLE_DESCRIPTION="${OPTARG}"
            ;;
            p)
                CONTAINER_POLICY_ARN="${OPTARG}"
            ;;
            s)
                SERVICE_ACCOUNT_NAME="${OPTARG}"
            ;;
            n)
                NAMESPACE="${OPTARG}"
            ;;
            *)
                usage;
                return 1;
            ;;
        esac;
    done;

    [ "${CLUSTER_NAME}" ] && \
    [ "${ROLE_NAME}" ] && \
    [ "${ROLE_DESCRIPTION}" ] && \
    [ "${CONTAINER_POLICY_ARN}" ] && \
    [ "${SERVICE_ACCOUNT_NAME}" ] && \
    [ "${NAMESPACE}" ] \
    || { usage; return 1; }

    if ! check_policy_exists "${CONTAINER_POLICY_ARN}"; then
        return 1
    fi

    ISSUER_ADDRESS=$(aws eks describe-cluster --name "${CLUSTER_NAME}" --query "cluster.identity.oidc.issuer" --output text)
    ISSUER_ID="${ISSUER_ADDRESS#https://}"
    ISSUER_DOMAIN="${ISSUER_ID%%/*}"
    PROVIDER_ARN=$(create_provider_if_not_exists "${ISSUER_ADDRESS}" "${ISSUER_ID}" "${ISSUER_DOMAIN}")
    create_trust_relationship_file "${PROVIDER_ARN}" "${SERVICE_ACCOUNT_NAME}" "${NAMESPACE}"
    ROLE_ARN="$(aws iam create-role --role-name "${ROLE_NAME}" \
                        --assume-role-policy-document file://trust.json \
                        --description "${ROLE_DESCRIPTION}" \
                        --output text --query Role.Arn)"
    delete_trust_relationship_file
    aws iam attach-role-policy --role-name "${ROLE_NAME}" --policy-arn="${CONTAINER_POLICY_ARN}"
    echo "コンテナーのサービスアカウントの annotations に下記を追加"
    echo "    eks.amazonaws.com/role-arn: ${ROLE_ARN}"
}

Some example output:

$ AWS_DEFAULT_REGION=us-east-1 create_eks_pod_role -c TestCluster -r loki-s3-role-test-2 -d "test role for loki s3 integration" -p arn:aws:iam::aws:policy/AmazonS3FullAccess -s a9t-loki -n monitoring-system
コンテナーのサービスアカウントの annotations に下記を追加
    eks.amazonaws.com/role-arn: arn:aws:iam::636082426924:role/loki-s3-role-test-2

Don't mind the Japanese it just states that the below is to be added to the annotations of your pods service account.

Conclusion

In conclusion, it was kind of a pain to create this script.. but its definitely simplifies my work-flow when creating roles for my pods. Feel free to use it if you like, and don't hesitate to let me know if you have any questions or concerns!

Using KinD with Podman (kinp)

Scott — Sat, 12 Dec 2020 12:07:37 +0000

I've been using kind on ec2 for a while now because I was too lazy to work around issues I was having locally. I finally go around to writing a shell wrapper for kind today and would like to share.

If you have any issues please let me know!

Disclaimer: This has been tested to work on Fedora 33 only but should work on other systems (provided you have podman installed.

Install kinp

git clone https://github.com/rustysys-dev/kinp.git
cd kinp

# install main script to /usr/bin/kinp
# installs library script to /usr/lib/kinp/libkinp
sudo bash install

Using kinp

kinp is used exactly as you would kind. That being said, kinp will download all dependencies before running (provided they do not already exist).

Dependencies include:

kubectl
kind
awscli (if AWS_ACCOUNT_ID env_var is set)

Create cluster

kinp create cluster

Check cluster

kubectl get nodes

Destroy cluster

kinp delete cluster

Conclusion

There you have it Kubernetes in Podman! If you have any questions or comments please let me know!

Create/Expose Test Kubernetes Cluster on EC2 with kind

Scott — Sat, 05 Sep 2020 08:53:37 +0000

WHY???! 😂

Well first off, there may have been better solutions for standing up a test cluster cheaply on EC2, but my thought process didn't lead me there. What was my thought process?

Need to test grafana dashboard on a test cluster..
Install Kind locally..
Kind doesn't work with experimental backend podman
Lets install kind on EC2.. Install Kind on EC2..
I want to work seamlessly from my workstation..

At this point in the thought process I was too focused on how to force Kind to meet my expectations than "Maybe there is a better way"... in anycase I got it to work, and wanted to record my process so that I wouldn't forget what I learned.

How I did it?

Install Kind
Configure EC2
Configure Local Environment

I had to run through a couple of hoops when configuring the local environment, but other than that it was pretty straight forward.

Install Kind

In order to install Kind with exposed ports (for connecting with kubectl from local pc) a Kind configuration file is necessary to override the default settings during the deployment.

Create Kind Configuration File

The following configuration file kind.yaml changes the bind address:port for the Kubernetes API server.

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  apiServerAddress: "0.0.0.0"
  apiServerPort: 7443

As a foot-note, you should never use a setup like this in production. Aside from the fact that Kind shouldn't ever be used in production.

Deploy Kind

Deploying the cluster is as easy as:

kind create cluster --config kind.yaml

Configure EC2

Now that we have Kind deployed and bound to 0.0.0.0:7433 we need to open that port on the node's security group.

Configure Security Group

Create an ingress rule similar to the screenshot below.

I have taken this screenshot using the IP 0.0.0.0 to hide my actual IP. In practice this Ingress rule should be limited to the IP from which you will be accessing the cluster.

Configure Local Environment

We now that we have our cluster created, and enabled access through our security groups we can configure our local environment to connect to the API.

The API certificates generated by Kind will not support your EC2 instance's domain name or IP so we will need to define a hostname supported by the certificate in your /etc/hosts file to be used for connecting to the API. Additionally unless you have used an Elastic-IP you will need to take some precautions to make connecting to the API easy between each stop / start of the EC2 Instance.

To help with this, we will define two functions to assign/update the current IP of your EC2 instance to the name kind-control-plane (which is supported by the certificates generated by Kind) in your /etc/hosts file.

Create Helper Aliases

Adds current public IP of your EC2 instance to the name kind-control-plane

add-dev-machine-ip () { 
    sudo bash -c "echo $(aws ec2 describe-instances --instance-ids <your-instance-id> --query Reservations[0].Instances[0].PublicIpAddress) kind-control-plane >> /etc/hosts"
}

Updates current public IP of your EC2 instance to the entry made by the previous command.

update-dev-machine-ip () { 
    sudo sed -i "s/^.* kind-control-plane.*$/$(aws ec2 describe-instances --instance-ids <your-instance-id> --query Reservations[0].Instances[0].PublicIpAddress) kind-control-plane/" /etc/hosts
}

Realistically you will probably only run the first command once and then never need it... but I felt the need to make it a function anyway.

Update `/etc/hosts`

Add IP to /etc/hosts

add-dev-machine-ip

Verify

sudo cat /etc/hosts

[rustysysdev@localhost ~]$ sudo cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
54.99.142.93 kind-control-plane

Configure Kubectl

Lastly, with our networking fixed we can configure kubectl to connect to our API server.

We will need to splice the ~/.kube/config generated by Kind on the EC2 instance with our local ~/.kube/config.

EC2 Instance

Output the ~/.kube/config generated by Kind.

cat ~/.kube/config

The output will look similar to the following.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: XXXXXXXXXXXXXX
    server: https://0.0.0.0:7443
  name: kind-kind
contexts:
- context:
    cluster: kind-kind
    user: kind-kind
  name: kind-kind
current-context: kind-kind
kind: Config
preferences: {}
users:
- name: kind-kind
  user:
    client-certificate-data: XXXXXXXXXXXXXX
    client-key-data: XXXXXXXXXXXXXX

Local PC

If you already have a local ~/.kube/config you will need to splice the above configuration into your local file.

In this example you would need to modify the following elements.

clusters:
contexts:
users:

Add to the clusters: element in your local file.

- cluster:
    certificate-authority-data: XXXXXXXXXXXXXX
    server: https://kind-control-plane:7443
  name: kind-kind

be mindful to change the 0.0.0.0 portion of the server address to the kind-control-plane hostname we defined earlier.

Add to the context: element in your local file.

- context:
    cluster: kind-kind
    user: kind-kind
  name: kind-kind

Add to the users: element in your local file.

- name: kind-kind
  user:
    client-certificate-data: XXXXXXXXXXXXXX
    client-key-data: XXXXXXXXXXXXXX

If you do not have a local ~/.kube/config file you can create one and copy/paste the file from your EC2 instance. Mindful of course that you change the https://0.0.0.0:7443 to https://kind-control-plane:7443.

Testing your setup

Switch to your kind-kind context.

kubectl config use-context kind-kind

Get node information.

kubectl get node

If everything is configured properly you should see output similar to the following.

NAME                 STATUS   ROLES    AGE   VERSION
kind-control-plane   Ready    master   26h   v1.18.2

Conclusion

And there you have it, your own Kind cluster running in EC2 with local access. If anyone has any questions, please let me know!!

Deploy Zulip messaging using podman play

Scott — Thu, 03 Sep 2020 11:39:42 +0000

What is Zulip?

Zulip is like Slack or Mattermost, a messaging server for teams to communicate on a project. Overview of Zulip features is out of scope for this article, but for those interested you can find more information here.

My reasons for writing this article

My reasons for writing this article are two-fold.

Dissatisfaction with the Mattermost interface.. particularly threads being hard to read.
My daily driver being Fedora 32, which utilizies cgroups version 2 doesn't support Docker out of the box.

The Mattermost interface has many great things and its integrations are amazing, but it handles threads in a dis-satisfactory manner.

Without Docker I have to translate projects to podman as I go my local environment. I use various tools to do this podman-compose, Kompose, podman generate, etc.

Deploying Zulip with podman

This morning with a lot of work translating docker-zulip, I was able to create the zulip-deployment.yaml file here to deploy Zulip.

Presumptions

You have an email server supporting TLS and user login.
You have a GitLab account / Server

Configuration

Defaults are fairly secure but for a production environment there are still some things that require tightening. With that warning out of the way to get zulip-deployment.yaml up and running the following substitutions are required.

Substitution Value	Description
__POSTGRE_SECURE_PASSWORD	The password for the integrated postgresql database
__MEMCACHED_SECURE_PASSWORD	The password for the integrated memcached cache
__RABBITMQ_SECURE_PASSWORD	The password for the integrated rabbitmq server
__REDIS_SECURE_PASSWORD	The password for the integrated redis server
__EXTERNAL_HOST_URL	Zulip externally accessible URL e.g. message.myproject_zulip.com, Can also be set to IP or localhost, and port may be included as desired.
__ZULIP_SECRET	random string of characters (used internally) preferably 50 characters long.
__EMAIL_SERVER_URL	URL of your email server
__EMAIL_USER_NAME	User for authenticating your email server
__EMAIL_USER_PASSWORD	Password for above username
__GITLAB_URL	Url of your GitLab instance, or of Gitlab.com
__GITLAB_APPLICATION_KEY	Application key generated as described here
__GITLAB_APPLICATION_SECRET	Application secret generated as described here
__ADMIN_ERROR_EMAIL	Email at which to recieve errors from Zulip

Deploy

Deployment should be as easy as running the following command.

podman play kube zulip-deployment.yaml

[rustysysdev@localhost zulip-podman-play]$ podman play kube zulip-deployment.yaml 
Pod:
4c475bb55f6f05828d5cb7efe499b8e84722138f16df263320e541722003fe9b
Containers:
bd8762327b8ab970d6a0c7bc8e6f0ff9ea217751e42225ad207d21e82ae834cc
5567fccbadf943a744264deec4a1b2dfd53ec8e49239660ffaf0a2b0008ba8ee
d503c0b9944428a1849e400315ffdff49b2249de9340387e30e089c20f0a9d58
c06c4ea471de0cc72388fdbf69d6ebbceaddcb4535303a3e293cd6e21afe960f
39cdccdcb981802c3f7e6a1168d590452502aa7097857f8136b18ea5b96079d0

Verify the deployment is complete.

podman logs zulip-pod-0-zulip

...
2020-09-03 07:05:21,303 INFO success: zulip_events_embed_links entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-09-03 07:05:21,303 INFO success: zulip_events_missedmessage_mobile_notifications entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-09-03 07:05:21,303 INFO success: zulip_events_error_reports entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-09-03 07:05:21,304 INFO success: zulip_events_digest_emails entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-09-03 07:05:21,304 INFO success: zulip_events_email_senders entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-09-03 07:05:21,305 INFO success: zulip_deliver_scheduled_messages entered RUNNING state, process has stayed up for > than 1 seconds (startsec

Post deploy setup

After deploying the Zulip server and before using it, you will need to create a new organization. This can be accomplished using the following commands.

exec into your container.

podman exec -ti zulip-pod-0-zulip bash

output:

[rustysysdev@localhost zulip-podman-play]$ podman exec -ti zulip-pod-0-zulip bash
root@zulip-pod-0:/#

run the following commands to get a realm creation link.

su zulip && cd /home/zulip/
$(find ./ -name manage.py) generate_realm_creation_link

output:

root@zulip-pod-0:/# su zulip && cd /home/zulip/
zulip@zulip-pod-0:~$ $(find ./ -name manage.py) generate_realm_creation_link
Please visit the following secure single-use link to register your 
new Zulip organization:

    https://localhost.localdomain:8443/new/4t1f3r0qet4eu0z0phyork8a

Open the resultant link in your browser and follow the steps to setup your administrator account and organization.

Conclusion

Creating the zulip server is easy, once finished you can invite users, who can then login using GitLab OAuth!

If you have any questions do not hesitate to ask!

Keep DDD in mind when designing systems (ver1)

Scott — Sat, 09 May 2020 02:43:38 +0000

I created and will keep updating this mind map as I learn more.

Please let me know in the comments if there are any relations that are incorrect or missing.

Switching to KeePass and Syncthing for password management

Scott — Sun, 12 Apr 2020 11:55:15 +0000

I have wanted to become more secure with how I have handled my password management for a while now. Before now, I had been using Firefox Lockwise, which is an amazing free service, by a similarly amazing company dedicated to OSS... That being said, I wanted a solution that I owned, where my passwords are only ever stored on my devices.

When it comes to password security and open source. KeePass tends to be the name you hear, and so I decided on that. Using KeePass means that I own the db. It also means that I had to find a way of syncing that db between devices...

My requirements:

Wholly self owned solution to sync my KeePass db file between multiple machines
Sync/Recieve from anywhere
Little to no maintenance
Secure

Research/Thought Process:

A quick online search recommends using a service like Dropbox, or Google Drive.
- I dismissed this, because it was a centralized service out of my control. If I was ok with that I might as well have stayed with Firefox Lockwise.
I thought about a cron based rsync solution...
- I dismissed this pretty quickly as there were too many logistical dependencies, and I couldn't find a way to make it work with a locked Android device.
I considered setting up my own NextCloud (or similar) service...
- I dismissed this because it was too much work from a security/maintenance standpoint, and would cost money to deploy
Decided on Syncthing!

Syncthing

I found Syncthing while searching for Nextcloud/alternatives and initially dismissed it, but came back to it after dissatisfaction with NextCloud/alternatives.

Syncthing in a nutshell

Encrypts all traffic by default
Monitors folders registered to Syncthing
Notifies relay when changes occur
Registers remote devices by device-id
Assigns devices to folders
Detects changes via relay
Connects directly to devices via a relay
Uploads or downloads directly to remote devices

Installation on Fedora

sudo dnf install syncthing

Start the Fedora Instance

systemctl --user enable syncthing
systemctl --user start syncthing

Installation Android

Install via the Google Play Store, link available here.

Get your Device IDs

Android

Open the app
Click on the ≡ and click Show Device ID record the ID

Fedora

Open localhost:8384 in your browser
Click Actions, then Show ID, record the ID

Configure Devices

Android

From the main screen click on the Devices tab, then on the ＋ in the top right
Input the Fedora system's Device ID and add a Name, tap ✔ to save

Fedora

Click the Add Remote Device button under the Remote Devices heading.
Input the Android Device ID and add a Name, then click Save

Adding Shared Folders

Android

From the main screen click on the Folders tab, then on the ＋ in the top right
Fill in the 🏷️ Folder Label, 🔑 Folder ID, and 📁 Directory. Remember your 🔑 Folder ID.
Tap to enable the slider for your Fedora device name.
Tap ✔ to save

Fedora

Under the Folders section, select Add Folder
Fill in Folder Label, Folder ID, and Folder Path, where Folder ID is the same as the 🔑 Folder ID on Android.
Click the Sharing tab, and add a ✔ to your Android device name.
Click Save

Once both devices configurations have been saved, I placed my kdb file in the Folder Path on my Fedora installation, and watched it synced to the opposite device within short order.

Notable Issues

The .stfolder directory on my phone tends to be be deleted on restart causing an error. Creating an empty .stfolder in your sync directory seems to fix this.
Modifying the same file from two different devices at the same time will result in conflicts. Conflicts result in a loss of the oldest of the two changes. ( the conflicting version still exists but is not automatically merged )

Conclusion

By switching to Keepass, and Syncthing I am able to securely sync my password database between my devices without ever storing it on a third-party server. If I could just figure out the issue with the .stfolder on android mysteriously disappearing I would be completely satisfied.

Please feel free to leave any questions or concerns in the comments!

Using Cap'n Proto on Rust

Scott — Mon, 23 Mar 2020 10:16:20 +0000

Introduction

Recently at work, I have been working a lot with gRPC and Golang, and I felt enjoy using gRPC as an application interface. It is simple to implement and works well.. Anyway about 2 weeks ago while reading about various technologies related to my work. I came across Cap'n Proto and was interested to learn that it was created by one of the primary authors of Protocol Buffers v2. Since I was already using Protocol Buffers with gRPC at work, I decided to try out Cap'n Proto + Cap'n Proto RPC with Rust.

What is Cap'n Proto?

Cap'n Proto is a incredibly fast data serialization format. If you want to know more about Cap'n Proto in general, please visit their website!. If you are familiar with Protocol buffers, then a majority of the following concepts will be familiar to you.

My Goal

My goal here is to create a simple API that accepts a list of parameters, and a source directory then return a job ID, or accepts a job ID and returns the results. See the following diagrams.

NOTE: The example built in this article will be split into the following files. main.rs, server.rs, client.rs, build.rs, service.capnp

Cap'n Proto Interface Definition

With a goal in mind, I set out and defined my service.capnp as follows:

@0xeb1bbbd418f18514;

interface Job {
    register @0 Request -> RegistryItem;
    getResult @1 RegistryItem -> Result;
    struct Request {
        parms @0 :List(Text);
        source @1 :Text;
    }
    struct Result {
        union {
            link @0 :Text;
            error @1 :Text;
        }
    }
    struct RegistryItem {
        # Single Job Identity
        id @0 :Text;
    }
}

NOTE: You can write your methods in a more verbose format, however this is not recommended as you will have to pry! multiple times in your server implementation.

Right away you can see we have defined a Job interface with two methods register and getResults, and three data structures Request, Result, and RegistryItem.

To actually use the defined RPC interface, we will need to generate Rust code from the above service.capnp file.

Generate the Code

In order to generate the code, you will need to create a build.rs file as follows.

extern crate capnpc;

fn main() {
    ::capnpc::CompilerCommand::new().file("service.capnp").run().unwrap();
}

This will generate the RPC code from the service.capnp file defined in the previous section, it roughly translates into the following:

interface Job {...}
- Creates pub mod job for client/server communications
register @0 Request -> RegistryItem
- Adds register method to job::Server trait
- Implements register_request for the job::Client struct to generating a Cap'nProto Request object for the register method.
- Creates type job::RegisterParams which controls access to incoming data on the server side.
- creates type job::RegisterResults which controls access to outgoing data on the server side.
getResult @1 RegistryItem -> Result
- Adds get_result method to job::Server trait
- Implements get_result_request for the job::Client struct to generating a Cap'nProto Request object for the get_result method.
- Creates type job::GetResultParams which controls access to incoming data on the server side.
- creates type job::GetResultResults which controls access to outgoing data on the server side.
struct Request {...}
- Creates a pub mod request (job::request) submodule
- Creates type job::request::Reader containing getters for each capnp parameter
- Creates type job::request::Builder containing setters for each capnp parameter
struct Result {...}
- Creates a pub mod result (job::result) submodule
- Creates type job::result::Reader containing getters for each capnp parameter
- Creates type job::result::Builder containing setters for each capnp parameter
struct RegistryItem {...}
- Creates a pub mod registry_item (job::registry_item) submodule
- Creates type job::registry_item::Reader containing getters for each capnp parameter
- Creates type job::registry_item::Builder containing setters for each capnp parameter

Importing the Generated Code

To use the code we just generated, we must import into our source as follows.

use crate::service_capnp::{job};

To build our service we still need to create an RPC client and server.

Creating the Server

The requires implementing 2 things.

Create the local implementation of your interface
Create your interface methods

Implement the local interface

First things first, we need to create a local struct upon which we can implement our interface methods. This is easy.

struct Job;

Once this is finished we get to the interesting part. The implementation of our methods.

Implement the methods

Cap'nProto methods will always follow the below signature.

impl <imported_rpc_interface>::Server for <local_struct> {
    fn <rpc_method_name>(&mut self, params: <imported_rpc_interface>::<sentence_case_rpc_method_name>Params, mut results: <imported_rpc_interface>::<sentence_case_rpc_method_name>Results)
    -> Promise<(), capnp::Error> {
        // Do Something
    }
}

or in our case, the following..

impl job::Server for Job {
    fn register(&mut self, params: job::RegisterParams, mut results: job::RegisterResults)
    -> Promise<(), capnp::Error> {
        // Do Something
    }

    fn get_result(&mut self, params: job::GetResultParams, mut results: job::GetResultResults)
    -> Promise<(), capnp::Error> {
        // Do Something
    }
}

For the purposes of this article the business logic for the methods is scaled back to printing out received values, and sending back static responses.

impl job::Server for Job {
    fn register(&mut self, params: job::RegisterParams, mut results: job::RegisterResults)
    -> Promise<(), capnp::Error> {
        println!("Processing Register")
        // get a reader object for the sent request
        let request_reader = pry!(params.get());
        // get the value for the sent parms parameter
        let parms = request_reader.get_parms().unwrap();
        // get the value for the sent source parameter
        let source = request_reader.get_source().unwrap();
        for item in parms.iter() {
            // print each parms value
            println!("Parameter: {}", item);
        }
        // print the source value
        println!("DataSource: {}", source);
        // set return value for id
        results.get().set_id("01E3S4Q9SN3VHVXB2KCAGD9P62");
        Promise::ok(())
    }

    fn get_result(&mut self, params: job::GetResultParams, mut results: job::GetResultResults)
    -> Promise<(), capnp::Error> {
        println!("Processing Get Result");
        // get a reader object for the sent request
        let request_reader = pry!(params.get());
        // get the send ID
        let id = request_reader.get_id();
        // print the sent ID
        println!("ID: {}", id);
        // set return value for link
        results.get().set_link("https://link.to.your/output.csv");
        Promise::ok(())
    }
}

NOTE: pry! is a macro from the capnp_rpc crate that acts like try!(), but for functions that return a Promise rather than a Result.

We wrap it all together and build our server::main() with the following.

use capnp::capability::Promise;
use capnp_rpc::{pry, RpcSystem};
use capnp_rpc::twoparty::{VatNetwork};
use capnp_rpc::rpc_twoparty_capnp::{Side};
use async_std::net::{TcpListener};
use futures::{AsyncReadExt, FutureExt, StreamExt};
use futures::task::LocalSpawn;
use crate::service_capnp::{job};

struct Job;

impl job::Server for Job {
    fn register(&mut self, params: job::RegisterParams, mut results: job::RegisterResults)
    -> Promise<(), capnp::Error> {
        println!("Processing Register")
        // get a reader object for the sent request
        let request_reader = pry!(params.get());
        // get the value for the sent parms parameter
        let parms = request_reader.get_parms().unwrap();
        // get the value for the sent source parameter
        let source = request_reader.get_source().unwrap();
        for item in parms.iter() {
            // print each parms value
            println!("Parameter: {}", item);
        }
        // print the source value
        println!("DataSource: {}", source);
        // set return value for id
        results.get().set_id("01E3S4Q9SN3VHVXB2KCAGD9P62");
        Promise::ok(())
    }

    fn get_result(&mut self, params: job::GetResultParams, mut results: job::GetResultResults)
    -> Promise<(), capnp::Error> {
        println!("Processing Get Result");
        // get a reader object for the sent request
        let request_reader = pry!(params.get());
        // get the send ID
        let id = request_reader.get_id();
        // print the sent ID
        println!("ID: {}", id);
        // set return value for link
        results.get().set_link("https://link.to.your/output.csv");
        Promise::ok(())
    }
}

pub fn main(arg_addr: &String) {
    use std::net::ToSocketAddrs;
    // parse input address..
    let addr = arg_addr.to_socket_addrs().unwrap().next().expect("Invalid Address");
    let mut exec = futures::executor::LocalPool::new();
    let spawner = exec.spawner();

    // Start Server
    let _server: Result<(), Box<dyn std::error::Error>> = exec.run_until(async move {
        // Initialize TCP listener @ addr
        let listener = TcpListener::bind(&addr).await?;

        // Initialize local interface defined above
        let job_client = job::ToClient::new(Job).into_client::<capnp_rpc::Server>();

        // Initialize and execute async handler
        let mut incoming = listener.incoming();
        let handle_incoming = async move {
            while let Some(socket_result) = incoming.next().await {
                let sock = socket_result?;
                println!("Accepted connection from {:?}", sock.peer_addr());
                sock.set_nodelay(true)?;
                let (reader, writer) = sock.split();
                let network = VatNetwork::new(reader, writer, Side::Server, Default::default());
                let rpc_system = RpcSystem::new(Box::new(network), Some(job_client.clone().client));
                spawner.spawn_local_obj(Box::pin(rpc_system.map(|_| ())).into())?;
            }
            Ok::<(), Box<dyn std::error::Error>>(())
        };
        handle_incoming.await?;
        Ok(())
    });
}

Creating the Client

Creating the client only requires creating the main loop for sending our requests as follows.

use capnp_rpc::RpcSystem;
use capnp_rpc::twoparty::VatNetwork;
use capnp_rpc::rpc_twoparty_capnp::Side;
use async_std::net::TcpStream;
use futures::{AsyncReadExt, FutureExt};
use futures::task::LocalSpawn;
use crate::service_capnp::{job};

pub fn main(arg_addr: &String) {
    use std::net::ToSocketAddrs;

    // Resolve input server address
    let addr = arg_addr.to_socket_addrs().unwrap().next().expect("Invalid Address");

    // Create a pool for executing async requests
    let mut exec = futures::executor::LocalPool::new();
    let spawner = exec.spawner();

    // Execute the client
    let _client: Result<(), Box<dyn std::error::Error>> = exec.run_until(async move {
        // Create RPC connection to the server
        let stream = TcpStream::connect(&addr).await?;
        stream.set_nodelay(true)?;
        let (reader, writer) = stream.split();
        let network = Box::new(
            VatNetwork::new(reader, writer, Side::Client, Default::default())
        );
        let mut rpc_system = RpcSystem::new(network, None);

        // Setup the client interface
        let job_client: job::Client = rpc_system.bootstrap(Side::Server);
        spawner.spawn_local_obj(Box::pin(rpc_system.map(|_|())).into())?;

        {
            println!("Sending Register Job Request...");

            // Create a register request object
            let mut request = job_client.register_request();

            // Set parms - list parameters require initialization
            let mut parms_setter = request.get().init_parms(2);
            parms_setter.set(0, "dark");
            parms_setter.set(1, "world");

            // Set source - strings do not require prior initialization
            request.get().set_source("/link/to/the/path");

            // Send request, and await response
            let response = request.send().promise.await?;
            println!("Received JobID: {}", response.get().unwrap().get_id().unwrap())
        }

        {
            println!("Sending Get Result Request...");

            // Create get_result request object
            let mut request = job_client.get_result_request();

            // Set JobID
            request.get().set_id("01E3S4Q9SN3VHVXB2KCAGD9P62");

            // Send request, and await response
            let response = request.send().promise.await?;

            // The result is of the union type, so we must determine which type it is
            match response.get()?.which()? {
                job::result::Link(t) => {
                   println!("Received Link: {}", t?);
                }
                job::result::Error(t) =>  {
                   println!("Received Error: {}", t?);
                }
            }
        }
        Ok(())
    });
}

Creating The main()

For the purposes of this article, both the client and server will be part of the same binary. As such, we have a dedicated main.rs which looks as follows.

// Include capnp generated code
pub mod source_capnp {
    include!(concat!(env!("OUT_DIR"), "/source_capnp.rs"));
}

pub mod client;
pub mod server;

fn main() {
    let args: Vec<String> = ::std::env::args().collect();
    if args.len() >= 2 {
        match &args[1][..] {
            "client" => return client::main(&args[2]),
            "server" => return server::main(&args[2]),
            _ => ()
        }
    }
    println!("usage: {} [client | server] ADDRESS", args[0]);
}

Running the server

We will run our server on localhost:2020, and should receive the following output (pre-client)

16:46:22 🖎 export-rust master* ± cargo run server localhost:2020
   Compiling export-rust v0.1.0 (/home/procyclinsur/test/export-rust)
    Finished dev [unoptimized + debuginfo] target(s) in 2.90s
     Running `target/debug/export-rust server 'localhost:2020'`

Running the client

Similarly the client will run against the server running at localhost:2020. When the client is run however there should be output in both the server terminal and the client terminal as follows.

Client

16:50:53 🖎 export-rust master* ± cargo run client localhost:2020
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s
     Running `target/debug/export-rust client 'localhost:2020'`
Sending Register Job Request...
Received JobID: 01E3S4Q9SN3VHVXB2KCAGD9P62
Sending Get Result Request...
https://link.to.your/output.csv

Server

16:46:22 🖎 export-rust master* ± cargo run server localhost:2020
   Compiling export-rust v0.1.0 (/home/procyclinsur/test/export-rust)
    Finished dev [unoptimized + debuginfo] target(s) in 2.90s
     Running `target/debug/export-rust server 'localhost:2020'`
Accepted connection from Ok(V6([::1]:36374))
Processing Register
Parameter: dark
Parameter: world
DataSource: /link/to/the/path
Processing Get Result
ID: 01E3S4Q9SN3VHVXB2KCAGD9P62

As you can see, we are able to send and receive data via our API powered by Cap'n Proto RPC. If you love it, hate it, have any questions, or suggestions for improvement please let me know!

Golang Dynamic Logging for Microservices

Scott — Fri, 23 Aug 2019 10:51:03 +0000

Dynamic logging is something I believe should be implemented in any micro-service environment. I suppose I should start with I mean by dynamic logging.. Simply put the following point should be covered.

Maintainer should be able to change the log level of the application mid-execution.

Sample Application

Using the go.uber.org/zap library LevelEnablerFunc you should be able to implement the interface using any protocol you want? (Haven't tested this).. That being said, for my sample application I will be using an HTTP interface and so I will use the zap built-in ServeHttp method.

First we need to define our logger and build and build an http router to accept log level changes. This is completed by utilizing the above mentioned ServeHttp function built into the zap.AtomicLevel object.

Setup Logger

config := zap.NewProductionEncoderConfig()
...
encoder := zapcore.NewJSONEncoder(config)
atom := zap.NewAtomicLevel()
    logr := zap.New(zapcore.NewCore(encoder, zapcore.Lock(os.Stdout), atom))

Dynamic log level interface

mux := http.NewServeMux()
mux.Handle("/log_level", atom)
go http.ListenAndServe(":1065", mux)

I am running a simple loop that repeats various logging messages to allow us to see the expected output. After building and running the application we can interact with it via curl.

Change logging levels

curl -X PUT -d '{"level":"debug"}' localhost:1065/log_level
curl -X PUT -d '{"level":"info"}' localhost:1065/log_level
curl -X PUT -d '{"level":"info"}' localhost:1065/  # EXPECTED 404
curl -X GET localhost:1065/log_level

NOTE: GIF seems to be broken again... but clicking the link should show you... ill fix it later 😂

Sample Application Code

package main

import (
    "net/http"
    "os"
    "time"

    "go.uber.org/zap"
    "go.uber.org/zap/zapcore"
)

func main() {
    undo := initLogger()
    defer undo()

    for {
        zap.S().Info("test_logs")
        zap.S().Debug("test_logs_debug")
        time.Sleep(1000 * time.Millisecond)
    }
}

func initLogger() func() {
    config := zap.NewProductionEncoderConfig()
    config.EncodeTime = func(t time.Time, enc zapcore.PrimitiveArrayEncoder) {
        nanos := t.UnixNano()
        millis := nanos / int64(time.Millisecond)
        enc.AppendInt64(millis)
    }
    encoder := zapcore.NewJSONEncoder(config)
    atom := zap.NewAtomicLevel()
    logr := zap.New(zapcore.NewCore(encoder, zapcore.Lock(os.Stdout), atom))

    mux := http.NewServeMux()
    mux.Handle("/log_level", atom)
    go http.ListenAndServe(":1065", mux)

    return zap.ReplaceGlobals(logr)
}

Forem: Scott

Important thing to remember about recovering panic'ed code in Go

Setup Recent Xiaomi Phones on Rakuten Mobile

Step 1 / 隠し設定1

Step 2 / 隠し設定2

Conclusion / 最後に

Understanding Yew Part 1

Overview

Components

Common Component Structure Properties

Component Implemetation

Component Lifecycle

Conclusion

Creating service account IAM roles on EKS

What needs to happen

Whats the problem

Domain Footprint

Role Trust Relationship

Complete Script

Conclusion

Using KinD with Podman (kinp)

Install kinp

Using kinp

Create cluster

Check cluster

Destroy cluster

Conclusion

Create/Expose Test Kubernetes Cluster on EC2 with kind

WHY???! 😂

How I did it?

Install Kind

Create Kind Configuration File

Deploy Kind

Configure EC2

Configure Security Group

Configure Local Environment

Create Helper Aliases

Update /etc/hosts

Configure Kubectl

EC2 Instance

Local PC

Testing your setup

Conclusion

Deploy Zulip messaging using podman play

What is Zulip?

My reasons for writing this article

Deploying Zulip with podman

Presumptions

Configuration

Deploy

Post deploy setup

Conclusion

Keep DDD in mind when designing systems (ver1)

Switching to KeePass and Syncthing for password management

My requirements:

Research/Thought Process:

Syncthing

Syncthing in a nutshell

Installation on Fedora

Start the Fedora Instance

Installation Android

Get your Device IDs

Android

Fedora

Configure Devices

Android

Fedora

Adding Shared Folders

Android

Fedora

Notable Issues

Conclusion

Using Cap'n Proto on Rust

Introduction

What is Cap'n Proto?

My Goal

Cap'n Proto Interface Definition

Generate the Code

Importing the Generated Code

Creating the Server

Update `/etc/hosts`