/var/log/study

つまり雑記

pipr,vcsim,govc,jqを組み合わせてクエリ構築を簡単にする

ESXi VMware govc

先日、piprというツールが紹介されていて、vSphere運用のワークフローを便利にする方法を思いついたので紹介

gihyo.jp

概要

vcsim + pipr + govc + jq を使うとインタラクティブにvCenter から情報を引き出す試行錯誤環境ができる。

pipr_vcsim_govc_jq

--no-isolation

piprはbubblewrapというツールを使って環境を保護するので、ファイルを書いたり消したりができないようになっているが、govcを使う際にsessionをファイルに書こうとするので、--noisolationオプションが必要。
ただ、自分が知らないだけで、何か--no-isolationオプションを使わない方法があるかもしれない。

govcに -persist-session=true Persist session to disk [GOVC_PERSIST_SESSION] があるのでそれを有効にすると pipr の --no-isolation は不要になる。上のgifもソレに合わせて作り直している

背景/改善ポイント

vSphereをそこそこの規模で運用していると、運用している全vCenter/ESXiからサッと情報を得て引き出して現状を確認したい、ということが多々ある。
大抵のケースではgovcとjqを組み合わせたら欲しい情報は引き出せて、普段は以下のようにしている。

  1. テスト用のvCから情報を引き出すgovcのコマンドを作る
  2. コマンドが作れたら、以降無駄にvCenterのAPIを叩かないように一旦jsonに書き出しておく
  3. 書き出したjsonを使って必要な情報に絞り込むjqのクエリを考える
  4. 1と3のコマンドを繋ぎ合わせてうまく動作するか確認する
  5. 組み立てたコマンドを複数vCenterに流す仕組みを作って実行する

ただ、vCenterから取得できる情報のjsonは人間が把握するには情報量が多く、jqのクエリを作り切るのにそこそこ試行錯誤が必要で、ステップ3をやっているうちにステップ1のコマンドがよくわからなくなり... みたいなことがよくあった。
そこでvcsimを用いてAPIを何度コールしても問題無い状況を作り、piprのインタラクティブな環境でjqのクエリを試行錯誤できるようにすると, 元々のステップ1,2,3,4を1つにまとめることができるのではないか？というのが今回の紹介でした。

proxy越しにpyvmomiを利用する

python VMware

レアケースだとは思いますが、pyvmomiを利用する際のclientとサーバーの間にproxyがいる場合意外と接続が面倒だったので備忘録

参考は以下

github.com

要点は以下

github.com

pyvmomi-community-samples などで使われている、pyvmomiのSmartConnect や、SmartConnectNoSLL を利用せず、 SmartStubAdapterにproxyの設定を渡し, そのAdapterをVimSessionOrientedStubに渡し、VimSessionOrientedStubをServiceIntence生成に使うという方法になっている。

pyvmomiでmoidをベースにオブジェクトを参照するメモ

vSphereのAPI経由でオブジェクトの情報を参照したいとき、かつ、moidはわかっているので
改めてAPI経由で検索する必要がない時のショートカット方法のメモです。

from pyVim.connect import SmartConnect
from pyVmomi import vim

if __name__ == "__main__":
    si = SmartConnect(
        host="ip or fqdn",
        user="username",
        pwd="password",
        port="443",
        disableSslCertValidation=True
    )
    vm = vim.VirtualMachine("moid", si._stub)
    print(vm.name)

年末なのでAPIを利用してNSX-Tをお掃除しよう

この記事は2021年の vExperts Advent Calendar の23日目の記事です。

前日は MT9276さんの VMware HOLで、Apache Log4j のワークアラウンド手順確認(PythonスクリプトをHOLへ持ち込み) でした。 スクリプトを持ち込めるのは自分も初めて知りました！ HOLでWAを試せるとなると、複数回試すことができて、実際のWA適用の際に安心できるな、と思いました。

ものすごいいまさらですが、2021年からvExpertになりました、@yaaamaaaguuu です。
ブログやTwitterではあまり言及しませんが、普段はNSXの運用や検証, NSXを利用するソフトウェアの開発などに取り組んでいます。
せっかくなのでNSX-Tに関する記事でvExpertアドベントカレンダーの1記事を担当させていただきます。よろしくお願いいたします。

年末も近いので、大掃除をしないといけない気持ちになってきますね？

この記事では、NSX-TのAPIを利用して、検証等などで作ってしまった不要なリソースを消していく方法を紹介し、年末の大掃除でUIをひたすらポチポチし続ける苦行を回避する方法を共有しようと思います。

目次

注意書き

NSX-T上のオブジェクトを削除するAPIを取り扱います。削除APIをコールすると当然対象のリソースは削除されますので、対象を誤らないように気を付けてください。誤ったAPIコールで、誤ったオブジェクトを削除してしまっても私は責任をとれません。

また本記事は NSX-T 3.1系とLinux上で動作するコマンド (zsh, curl, jq 等)を利用した記事となります。

さらにVMC上のNSX-Tについての差異は扱いません。

NSX-TのAPIについて

2021/12/22 時点での最新のNSX-Tのバージョンは3.2.0となり、APIドキュメントは こちら となります。(基本的にはAPIドキュメントに記載されている内容の抜粋となります。)

何はともあれ、NSX-TのAPIをコールできないことには話が始まりません。とりあえずAPIをコールするにしても、認証情報を付与する必要がありますが、NSX-T上のユーザー名/パスワードをBasic認証の情報として付与してあげるとよいだけです。以下のようなコマンドになると思います。

# 試しにNSXのClusterの情報を参照してみる
curl -k -u "${username}:${password}" https://${NSXMANAGER}/api/v1/cluster/status

JSON形式でNSXのClusterの情報が出力されたら成功です。以降のAPIコールが上手くいかない場合は、利用してるユーザーの権限を確認してみるとよいと思います。(clusterのステータスの表示が上手くいかなくても、消したいと考えているオブジェクトを消す権限などがある可能性もあると思いますし、その逆もあると思います。)

APIコールが上手くいったならば、次に削除対象のオブジェクトを指定する方法を探します。

Full text search API

NSX-T の各個別API (例えば、セグメントを参照する GET /policy/api/v1/infra/segments など) には、細かい条件 (例えば表示名が HOGE で始まるなど) を指定する方法がありません。その代わりに Full text search API が備わっていて、こちらのAPIを利用すると、参照するオブジェクトをある程度細かく指定することができます。

このFull text search APIを利用するパスは2個あります。これは、Policy Planeのオブジェクトか、Management Planeでのオブジェクトか、を意識して使い分ける必要があります。APIドキュメント内の Searchable types には両方が記載されていますが、パスによって参照可能なオブジェクトが異なったりします。(Management PlaneのオブジェクトとPolicy Planeオブジェクトに関する詳細は別途NSX-Tのリソースを参照してください。)

  • GET /policy/api/v1/search/query
    • Policy Planeのオブジェクト用APIパス
  • GET /api/v1/search/query
    • Management Planeのオブジェクト用のAPIパス

APIパスについてをなんとなく把握したら、次はFull text search APIで利用するQuery Syntaxについてです。とはいっても、こちらのSyntaxについてもあるドキュメント程度詳細に記載されているので要点だけ記載します。

  • Query Syntax 要点
    • URLパラメーターの query でクエリを指定する
    • APIレスポンス内のkey と keyのvalueとして想定されるものを : でつなぐ ( = で繋ぐようなサンプルがあった記憶があるが、誤り)
    • 検索のkeyとしたい値がネストしたjsonのkeyならば . で繋ぐことができる
      • {"hoge": {"fuga": 1}} の fuga をkeyで検索したければkeyは hoge.fuga をキーとする
    • valueには、 * のワイルドカード指定なども利用できる
    • AND, OR, NOT や、不等価演算子なども使える

ということで、簡単な例を記載しておきます。

# NSX-T上のグループ かつ 表示名の先頭がYAMAGUCHI_ となっているモノ
curl -k -u "${username}:${password}" -k -G --data-urlencode 'query=resource_type:Group AND display_name:YAMAGUCHI_*' 'https://${NSXMANAGER}/policy/api/v1/search'

あとは、上記の要領で、必要となるオブジェクトを検索するクエリを作り上げます。

オブジェクトを削除していく

ここまで来たらあとは、大した手間ではありません。 resource_typeで削除対象としたいオブジェクトを指定しつつ、各個別のオブジェクトの削除APIをたたいていくとよいです。 APIレスポンスからうまく削除対象のidを引き出すためにjqなどと合わせながら以下のようなスクリプトを組みます。(jqがよくわからなければ、 https://stedolan.github.io/jq/manual/ あたりのマニュアルを眺めるとよいです。)

# 例えばYAMAGUCHI_とPrefixのついたグループを片っ端から削除する
for groupId in `curl -k -u "${username}:${password}" -G --data-urlencode 'query=resource_type:Group AND display_name:YAMAGUCHI_*' 'https://${NSXMANAGER}/policy/api/v1/search' | jq '.results[].id' -r`;
do
    echo curl -k -X DELETE 'https://${NSXMANAGER}/policy/api/v1/infra/domains/default/groups/'$id;
    curl -u "${username}:${password}" -k -X DELETE 'https://${NSXMANAGER}/policy/api/v1/infra/domains/default/groups/'$id;
    sleep 1;
done

まとめ

NSX-T のAPI + jq + shell script で NSX-T上のオブジェクトを一括で削除する方法を記載しました。
NSX-T上のお掃除はAPIをうまく利用してサッとやって年末を迎えましょう。

この記事は2021年の vExperts Advent Calendar の23日目の記事でした。

明日は、Yuki Kawamitsuさんがストレージ関連で何かの記事を投稿するとのことです。お楽しみに！

備忘録: Kinesis AdvantageでF1~F10のふるまいを元に戻す

https://kinesis-ergo.com/wp-content/uploads/kb500-user_manual.pdf を見るとよいのだけども = + w を押すと元のF1~F12に戻る。

( = + m を押すと、マルチメディアグループ機能というやつが有効になって、F10とかF11あたりを押すとボリュームのアップダウンになる。)

マルチメディアグループが有効になっていると、IDEを使っているときのF1 ~ F12 を交えたショートカットが軒並みダメになってめちゃくちゃ不便。

ロードバランサー 入門準備

この記事は富士通クラウドテクノロジーズ Advent Calendar 2020の24日目の記事です。

23日目は id:foobaron さんの EVPN L2VPN All-Active MultihomingにおけるRoute Typeと経路迂回 でした。 データセンターのネットワーク運用者は要チェックです。

25日目は inasato さんの 「ESXi Arm Edition v1.1 で物理 NIC の追加してみた」 です。

アドベントカレンダー24日目の記事です。12/24といえばクリスマスイブです。どんなプレゼントがもらえるか？がワクワクする日ですね。インフラエンジニアならば誰しもがクリスマスにロードバランサーをプレゼントされるのを夢見たことがあるのではないかと思っています。

クリスマスとは関係ないですが、ロードバランサーを触る機会をいただくことが年々増えているため、一度ロードバランサーの入門前に知っておきたかった話 (もしくは一度知ってしまえばなるほどね。と思えるような話) をまとめておこうと思います。いろいろなことを書こうとは思いますが、LBに精通しているわけではないので抜け漏れはあると思います。

以下の文章でロードバランサーはLBと省略し、以下のようなことを記載します。

  • LBに期待されることの説明
  • LBの論理構成とその時に関わる用語や方式など
  • LBのよくある設定項目とその補足
  • LBを検証するに当たって用いると良い検証ツールの紹介
  • LBを知るに当たって参考となる資料

以下のようなことは本記事では記載しません。

  • 特定のLBが備える機能の詳細
  • LBを用いた負荷試験などの計画や実施方法
  • LBを運用する際に必要な考慮点
  • etc

LBに期待されること/LBで実現できること

基本的にはある1つの宛先に対する通信を受け取った際に、設定した複数の宛先に振り分けることがLBには期待されます。例えば1度目の192.0.2.1に対する通信を192.0.2.11に、2度目の192.0.2.1に対する通信を192.0.2.12に振り分ける、といった振る舞いを期待します。ユースケースとしては複数台用意した同一のwebアプリケーションサーバーに通信を振り分けること実現します。

1つの宛先を複数の宛先に振り分ける都合上、複数の宛先が宛先として機能するか？を確認し、宛先として機能しない場合は宛先としては見なさない様にすることもLBには期待されます。具体的な例を挙げると、LBから一定の間隔で振り分け先のIPに対してICMPでの通信を試みて、複数回の返信がなければ振り分け先のサーバーから除外する様な振る舞いを期待します。ICMPは具体例の一つで、試みる通信のプロトコルや試みる頻度が選択可能であることも期待されます。通信の振り分け先が全て不能の状態だと判定した際にはLBがエラーのページをレスポンスすることも期待されます。

また、LBはクライアントとコンテンツをレスポンスするサーバーの中間に位置する都合、複数の振り分け先で処理するよりも中間のLBで処理してしまった方が良いことを処理することも求められます。よく挙げられる例としては、SSL/TLSの通信の終端や、特定の通信を許可/拒否するフィルタリングですが、解釈するプロトコルがより高レベルなものだと、認証認可のための処理を挟むことができたりします。

最後に、LBは、ある宛先に対する通信を1度集約し、分散させる装置である都合上、LB自身に可用性が期待されます。具体的には, 2台以上の同様なLBでActive/Stanbyの構成や、Active/Activeの構成が取れることを期待されます。また1台のLBに障害が発生した際にも、既存の通信に与える影響を最小に通信の処理を継続できることが求められます。

LBとネットワーク構成など

ここではLBのネットワーク構成などについて言及しようと思います。 物理的な話や論理的な話での分類というよりは、対比しやすい話を記載していきます。

アイコンと図の説明

以降いくつかアイコンを用いた図を使いますが、以下のようなイメージで使い分けています。また黒い線はネットワーク的な繋がりを、オレンジ色の線は通信の経路を示すつもりで利用しています。

イメージをつかむ足がかりになることを目的としているので、正確な構成図は示しません。

また特にロードバランサーのアイコンは後述するLB装置/バーチャルサーバー/LBインスタンスとしてのアイコンを特に使い分けていません。話の文脈的にLB装置であるか、バーチャルサーバーであるか、LBインスタンスであるか？を識別するのが重要なときだけどのような役割でLBアイコンを使っているか記載します。

f:id:yaaamaaaguuu:20201224041936p:plain

バーチャルサーバー

LBと一口に言っても、物理的なハードウェアを利用して実現する方法や、仮想サーバー上のOSにソフトウェアをインストールして実現する方法などあります。

物理ハードウェアや仮想サーバーなど複数のLBのための装置を1セットのLBとみなした時、更にそのLBの中で複数のロードバランスの設定を持つことができるケースが多いです。LB装置内部に仮想的なサーバーを持つようなイメージでバーチャルサーバーと読んでいるようです。ここではバーチャルサーバーと書きましたが、この呼称はLB製品によってまちまちだと思います。

下記の図でLBのアイコンは、実際にパケットを処理しているプロセス的な何かだとイメージしてください。良い言葉が無いのでこの文章ではLBインスタンスと呼びます。

LB装置とバーチャルサーバーの設定と、LBインスタンスなどの組み合わせにより無限に考え方があると思うのでコレはあくまで一例です。

例えば、Active/Stanby構成のうち、片方のバーチャルサーバーの通信を処理するLBインスタンスのActive/Stanbyを入れ替えるとLB装置としてはActive/Active に見えたりすると思います。 (実際に通信を賄うのはどちらかになるので、バーチャルサーバーから見たらActive/Stanbyは変わらないですが。)

またLB装置が複数のケースでもそうで、バーチャルサーバーの設定の適用範囲や、その適用範囲のうちどのように通信を処理するLBインスタンスが稼働して通信をさばいたりは様々な組み合わせがあります。モノによって組める構成は異なると思うので要確認です。

f:id:yaaamaaaguuu:20201224093139p:plain

VIP

バーチャルサーバーは通信を受け付けるIPを設定する必要があります。その通信を待ち受けるIPをVIP (ビップもしくはブイアイピイ)と呼びます。バーチャルサーバーのIP で Virtual IPとのことです。

2台構成, 複数構成

前述したようにLBには可用性が求められます。2台のLB装置でActive/Stanbyの構成を作り、Activeが障害を起こすとStanbyに切り替える構成をよく聞きます。またソフトウェアで実現するロードバランサーでは3台以上のLB装置を連携させる方式も聞きます。

特にソフトウェアベースのLBで3台以上を連携させるときに見かける方式としては、代表のノードが一度通信を受取、L2の宛先を書き換えて他のLB装置に転送する方式と、上位のルーターとBGPで連携し上位ルータの段階で複数のLB装置に通信を分散させる多段なロードバランサーを構成する方式を見かけます。

以下の図では振り分け先サーバーを省略していますが、オレンジ色の先が届いているActiveと記載されているLBから振り分け先に通信を転送することになります。

f:id:yaaamaaaguuu:20201224042723p:plain

1arm, 2arm/インライン

続いてイメージしやすい話を記載すると、1arm, 2armインラインがあると思います。 1armは通信を受け付けたNICから振り分け先サーバーに通信を転送する構成で、2arm/インラインは通信を受け付けたNICとは異なるNICから振り分け先に通信を転送する構成になります。

f:id:yaaamaaaguuu:20201224042945p:plain

ロードバランサーを介した通信の送信元IP

クライアントとクライアントからのリクエストを処理する間にロードバランサーが存在することになります。クライアントからロードバランサーがVIPで通信を受け付けた際に、送信元IPアドレスをロードバランサーが書き換えずに振り分け先にパケットを転送するのが透過IP(P透過, 透過モード)、 送信元IPアドレスをロードバランサーが設定されたIPに書き換えるのがSNAT (透過IPと対比して、非透過と呼ばれることもあるらしい) です。

また送信元IPを書き換えてしまうと、振り分け先サーバーでは本来の送信元が不明になります。そのための対策としてHTTPの通信をロードバランスする際にX-Forwarded-Forヘッダーにもともとの送信元IPを記載する機能や、HTTPも含めその他のプロトコルの際にも送信元がわかるようにProxy Protocolに対応する機能があったりします。

フローティングIP

Active機が故障し、Stanby機がActive機に昇格するような際に、Active側で待ち受けていたIPをStanby側に引き継ぐ必要があります。所有者が変わる必要があるさまを指してFloating IP と読んでいるみたいです。

個人的にはStackoverflowのこの解答 を読んでわかった気分になりました。

ロードバランサーのよくある設定項目/確認ポイント

複数のロードバランサー製品を見て共通で備わっている機能には以下のような項目があります。 この項目と、前述のネットワーク構成の設定を組み合わせてロードバランサーを実現することになります。

具体的な要件が決まっている設定値は、要件が満たされているか？を確認すると良いと思いますが、そうでない値はどのような機能があるかを眺めながら動作確認することになると思います。

  • 振り分け可能なプロトコル
    • どのようなプロトコルが振り分け可能か？を確認すると良いです。
    • また振り分けたいプロトコルによって(特にL4とL7を境界として)できることが異なるので把握すると良いです。
      • 例
        • HTTPSをLBで受付SSL/TLSを終端し、振り分け先サーバーにはHTTPで通信を流すなど
        • HTTPを振り分ける際にX-Forwareded-For ヘッダーを挿入したり。
  • 振り分け先選定
    • どの様な振り分け先選定方法があるのか？を確認すると良いです。
    • round robin や least connection などがありますが、正確なことは利用するLBのドキュメントを読むのが良いです。
  • 振り分け先固定
    • HTTP通信のセッションの保持の都合などで、1度アクセスしたサーバーにしばらく接続され続けるのが好ましいケースがあります。
    • どのように振り分け先を固定することが可能かを把握すると良いと思います。
    • また振り分けの固定がどれだけ持続するか？も確認すると良いと思います。
  • ヘルスチェック
    • ヘルスチェックの試行方法
      • どのようなプロトコルでヘルスチェック可能か？
      • ヘルスチェックの試行間隔はどれくらいか?
    • ヘルスチェックの失敗判定の条件
      • 1つの振り分け先が振り分け不可と判定する条件は何か？
      • 1回の試行は何を満たすと失敗と判定されるか?
    • ヘルスチェック失敗からの復帰条件
      • 「ヘルスチェックが3回成功したら復帰と見なす」などの条件を見ると良いと思います。
  • エラーページについて
    • どの様にエラーページを設定可能か？
      • リダイレクト
      • 固定ページの表示
      • その他
  • フェイルオーバー時の挙動
    • 求める要件によっても変わってくるので一例となります。
    • ロードバランサー自体がどの様に障害を検知し、フェイルオーバーするか?
      • 確認すべきポイントは構成に依存するので詳細は追わないです
    • 障害検知までの時間, 障害検知から通信を処理する筐体の切り替わりまでの時間
      • 障害の検知は早ければ早い方が良いですが、誤検知しない程度が求められます
    • 既存の通信に対する影響
      • 障害を検知したLBを介していた通信が、LBの切り替わり後も問題なく通信可能か

ロードバランサーを検証するに当たって用いると便利な検証ツールの紹介

検証をする際に利用すると便利なツールを雑多にいくつか紹介しておきます。これらのツールを用いて、前述の設定項目/機能が意図通り動作しているか？を確認していくことになると思います。

ここで上げるツールは基本的にLinuxで使えるものを挙げます。

  • netcat
    • The GNU Netcat -- Official homepage
    • ncと呼ばれたりもします。
    • netcat1つでTCP/UDPの擬似的なクライアントとしても、擬似的なサーバーとしても活用することができます。
    • 例えば、shellとうまいこと組み合わせる事で擬似的なwebサーバーとしても動かすことが可能です。
  • curl
    • curl
    • 特に自分から説明することがないくらいには有名なツールだと思いますが、一応
  • nmap
  • tcpdump
  • Wireshark
  • NGINXとngx_http_perl_module
    • Module ngx_http_perl_module
    • webサーバーと、perlをもちいて動的なコンテンツを返すモジュールです。
    • ngx_http_perl_moduleを推す理由は、多くの場合NGINXをインストールすると利用可能だからです。
      • nginxと適当な言語のアプリケーションサーバーを組み合わせて… という様なことが得意であればそちらを使う方が良いと思います。
    • 例えば、以下の様なことを実現したいケースで便利です。
      • 振り分け先サーバーが認識した、送信元IPをレスポンスに記載する
      • 振り分け先のサーバーのホスト名をレスポンスに記載する
      • 振り分け先サーバーに届いたHTTP通信のX-Forwarded-Forのヘッダーの中身をレスポンスに記載する
  • Fabric
    • Welcome to Fabric! — Fabric documentation
    • 複数のサーバーに対して、コマンドを実行することができるpython製のツールです。
    • pythonのコードの中に、実行したいコマンドを記載する形式になります。
    • 手軽に複数の振り分け先サーバーのセットアップ/設定変更する際に便利です。
    • 使い慣れていればAnsibleなどでも良いと思います。
  • Locust
    • Locust - A modern load testing framework
    • 適当なHTTP/HTTPSリクエストを多数飛ばしてみるのに便利なツールです。
    • pythonでシナリオを書いてHTTPのリクエストを飛ばす順序などを設定できます。
    • WebのUIもあり便利ですが、CLIで完結することも良いポイントだと思います。
      • locustのcliから生成するリクエストするクライアントの数の上限や、クライアントの増やし方などを設定することができます。
    • 複数サーバー上で複数のlocustを稼働させ、大量の通信を飛ばすのも比較的容易です。
      • locustの1プロセスは1cpuしか使わないような作りになっていたと思うので、小さい複数のサーバーでlocustを動かすのが良いと思います。
  • Apache JMeter
    • Apache JMeter - Apache JMeter™
    • こちらもHTTP/HTTPSのリクエストを多数飛ばすツールとなります。
    • 先人たちがJMeterでパフォーマンス計測した結果が残っていたりするケースがあると思うので、使えて損がないと思います。

本記事の参考文献 もしくはLBを学習するに辺り参考になった文献

自分がLBを学ぶにあたっては、以下の資料が大変参考になりました。

書籍

  • サーバ負荷分散入門
    • 前半は負荷分散技術に関して書かれています。
    • 後半はF5社のBIG-IPのLTMの仮想アプライアンスを利用したものとなっています。
      • 書籍で扱っている内容はv11系列で、最新版はv16系のようです。
      • 学習時に触っただけなのでBIG-IPのLTMに関しては全く詳しくないのでv11とv16系でどれだけ違うのか？不明です。
      • 自分は後半を流し読みしてしまったので、BIG-IP v16系 でも書籍通り検証できるか？も不明です。

Web

まとめ

ロードバランサーの初歩的な話をまとめて記載しました。将来的に誰かの役に立てば幸いです。

この記事の図は https://app.diagrams.net/ と ニフクラ アイコン＆シンボル を利用して記載しました。

この記事は富士通クラウドテクノロジーズ Advent Calendar 2020の24日目の記事です。

23日目は id:foobaron さんの EVPN L2VPN All-Active MultihomingにおけるRoute Typeと経路迂回 でした。

25日目は inasato さんの 「ESXi Arm Edition v1.1 で物理 NIC の追加してみた」 です。 Raspberry Piで実現できるESXi Armの欠点を克服しそうなネタなので楽しみですね。

Emacsで手動でhexを入力してバイナリを編集するための備忘録

Emacsで手動でhexを入力してバイナリを編集するための備忘録

例えば30日OS自作本などだと最初にhexを入力しましょう。みたいなのが出てくるのだけども、そういうのこそ使い慣れたEmacsでさっとやってしまいたい。

Emacsの標準のhexlモードだと人間がhex値を入力することでバイナリを編集するのは可能(C-M-x を入力する) のだが、ちょっと長いバイナリを編集するのは辛い。

実現されてほしいこと

  • 0 を入力したら 0x00 の カーソルが当たっている桁が0になる
    • 該当カーソルの値が 0x30 にならない。
  • 末尾にhexが追記可能
  • 末尾のhexが削除可能

準備

nhexl-mode をインストールする

M-x package install

編集

M-x nhexl-mode
M-x nhexl-nibble-edit-mode