winds.from.oz 技術メモ

Tag: Ansible

Coding Agent向けにソースコード構造解析を試す：Call Graph、CFG/DFG/PDG、Ansible、Provenanceの使い分け

Posted:   |   Categories: ai   |   Tags: ai, ansible, codex, coding-agent, graph, local-llm, python, sre, static-analysis

Coding Agent向けにソースコード構造解析を試す：Call Graph、CFG/DFG/PDG、Ansible、Provenanceの使い分け

Coding Agentに大きなrepositoryを読ませるとき、単純にsource fileを大量にcontextへ投入する方法には限界がある。

大きなmodelならかなり読めるが、それでも「どのfileから読むべきか」「どのfunctionが中心なのか」「値がどこから来ているのか」「複数repositoryをまたぐ処理は何なのか」を毎回sourceから探索するのは高コストである。特に小型のlocal LLMでは、repository全体をcontextへ入れる方法は現実的ではない。

そこで、sourceから決定論的に構造情報を抽出し、

  • Coding Agentが読むべきsourceを絞る
  • 人間がarchitectureを理解する材料にする
  • refactoring前後の構造差を確認する
  • 小型LLMにはboundedなcontextだけを渡す

という用途に使えないか、homeclusterのPython / Ansible中心のcodebaseでいくつかの解析方法を試した。

今回試したものは次の通り。

  • Symbol Index
  • Call Graph
  • module / type / provenance
  • receiver method resolution
  • Control Flow Graph（CFG）
  • Data Flow Graph（DFG）
  • Program Dependence Graph（PDG）
  • Ansible domain graph
  • inventory provenance graph
  • cross-repository contract graph
  • bounded structural slice

結論から言うと、どれか1つが勝者というより、それぞれ違う層で有用だった。

さらに実際に作ってみると、すべてを同じ頻度で更新するより、

普段は軽量なstructural indexを継続的に最新化し、難しい調査やarchitecture reviewのときだけDeep解析を実行する

という二層構成が良さそうだと分かった。

この記事では、解析手法の一般論から入り、実際に試して分かったメリット・デメリット、Coding Agentへ任せる場合の設計、自動化で気を付ける点、他言語へ広げるときの考え方まで整理する。

ソースコード解析にはいくつかの「深さ」がある

「source codeを解析する」と言っても、何を知りたいかによって必要な解析は違う。

最も単純なのは、fileやsymbolを探すindexである。

repository
  |
  +-- module A
  |     +-- function foo
  |     +-- class Bar
  |
  +-- module B
        +-- function baz

ここから一段進むと、function同士の呼び出し関係を調べるCall Graphになる。

Read more...

DHCP Option 224でPXE boot後のrole情報を渡す

Posted:   |   Tags: ansible, dhcp, openwrt, pxe

DHCP Option 224でPXE boot後のrole情報を渡す

目的

PXE boot では、firmware、initramfs、rootfs 上の network manager がそれぞれ DHCP を使うことがある。

このうち、OS 起動後の automation に必要な metadata を DHCP Option 224 で渡すと、同じ rootfs から起動する client でも role や stage を切り替えやすい。

ここでは Option 224 を overlay_id / role / roles / stage のような runtime config 伝播に使う設計をまとめる。

使い方

Option 224 の値は、単純な key-value 文字列にする。

overlay_id=pi-node-1,role=base,roles=base,worker,stage=staging

client 側では DHCP hook がこの値を受け取り、runtime env file を作る。

/run/dhcp/role.env

systemd unit や wrapper はこの env file を読み、対象 role でなければ skip する。

Read more...

Raspberry Pi PXEのTFTP artifactとNFS rootfsを同じrelease境界で扱う

Posted:   |   Tags: ansible, gentoo, pxe, raspberry-pi

Raspberry Pi PXEのTFTP artifactとNFS rootfsを同じrelease境界で扱う

目的

Raspberry Pi を PXE / network boot で運用すると、boot firmware が読む TFTP artifact と、Linux が mount する NFS rootfs が別々の場所に置かれる。

この 2 つの対応がずれると、kernel / DTB / initramfs / module set / rootfs のどこで壊れたかを追いにくい。

ここでは、TFTP artifact と NFS rootfs を同じ release 境界で promote する設計をまとめる。

前提

構成は次のように分ける。

DHCP / TFTP server
  -> TFTP root
       dates/<release>/
       <board-or-host-prefix>/

NFS server
  -> rootfs/<release>/

Raspberry Pi firmware は board 固有の prefix directory を読める。host directory には config.txt、cmdline.txt、symlink などを置き、cmdline.txt で NFS rootfs release を切り替える。

Read more...

UbuntuでAndroid + Rust/Slint開発環境をAnsible管理する

Posted:   |   Categories: ubuntu   |   Tags: android, ansible, rust, slint, ubuntu

UbuntuでAndroid + Rust/Slint開発環境をAnsible管理する

Ubuntu workstation に Android Studio、Android SDK、Emulator、Rust Android build 環境を入れる場合、GUI installer 任せにすると再構築時の差分が見えにくい。

Ansible では、OS 側の依存、SDK directory、Rust toolchain、Emulator 用 group、確認用 AVD を分けて管理すると扱いやすい。

管理するもの

  • Android Studio
  • Android SDK command-line tools
  • platform-tools
  • emulator
  • Android platform / build-tools
  • NDK
  • x86_64 emulator image
  • Rust toolchain
  • x86_64-linux-android target
  • cargo-apk
  • KVM / libvirt / plugdev group

Android Studio 本体は公式 tarball を固定 path に展開し、SDK は /opt/android-sdk のような system-wide path に置くと、複数 shell や editor から参照しやすい。

directory方針

例:

Read more...

Ansible関連のメモ

Posted:   |   Categories: ansible   |   Tags: ansible

ansibleユーザを作成する

一旦、ansible-playbook実行サーバからssh鍵をコピーするためパスワードを設定するが、ssh-copy-id後、パスワードを削除する手順。

※ 下記のようにアカウントを作成するとデフォルトシェルとして/bin/bashが設定されるが、できれば消したい。 ただAnsibleの一部のモジュールやプラグインは、ターゲットシステム上でフルシェル環境を想定している可能性があるためデフォルトシェルの設定をしている。 既存のプレイブックを調整しつつ最終的にはデフォルトシェルをなくしたい。

useradd --system -m -G users,wheel ansible
passwd ansible

Gentooでsudoが入ってない場合、sudoインストール

emerge -a app-admin/sudo

/etc/sudoers.d/ansible に書き込む(mkdir /etc/sudoers.d/がなければ作る) 編集時は visudo -f を使い、権限は 0440 にする。

mkdir -p /etc/sudoers.d
echo "ansible ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/ansible
chmod 0440 /etc/sudoers.d/ansible

ansible-playbook実行サーバから

ssh-copy-id ansible@<対象ホストのIPアドレス>

パスワードログインを禁止していく(ansibleのcopyで確実に存在するようにした方が良い)

/etc/ssh/sshd_config.d/ansible_no_password.conf を追加

Match User ansible
  PubkeyAuthentication yes
  PasswordAuthentication no
  ChallengeResponseAuthentication no

上記のファイルはインデントしているが、可読性のためでsshdの挙動には関係がない。

sshdを再起動

sudo systemctl restart sshd

sshdの制限については下記が参考になった。

INIファイルとYAMLファイルの比較

ディレクトリを作成する

- name: Create a new directory
  file:
    path: /path/to/new/directory
    state: directory

ファイルが存在するかwhenで確認する

findで検索

- name: Check if file exists
  find:
    paths: /path/to/directory
    patterns: myfile.txt
  register: result

- name: Perform task if file exists
  debug:
    msg: "File exists"
  when: result.matched > 0

パス決め打ち

- name: ファイルの存在確認
  stat:
    path: /path/to/your/file.txt
  register: file_stat

- name: ファイルが存在する場合に実行されるタスク
  command: echo "ファイルが存在します"
  when: file_stat.stat.exists

- name: ファイルが存在しない場合に実行されるタスク
  command: echo "ファイルは存在しません"
  when: not file_stat.stat.exists

loopの説明