モダンオペレーティングシステム 第1章・第2章メモ

モダンオペレーティングシステム 第5版 上 読んでる。 読み進めた記事というよりは範囲の中でわからんとこを生成AIと相談しながら文章課題とか出してもらいつつ進めたものをまとめた記事。 第1章 序論 OSの2つの役割 OSには2つの顔がある。 1. 拡張マシン(Extended Machine) ハードウェアの複雑さを隠蔽する。アプリ開発者はディスクの物理構造を知らなくてもファイルを読み書きできる。Docker APIがLinuxの複雑さを隠すのと同じ発想。 2. リソースマネージャー(Resource Manager) CPU・メモリ・ディスク・ネットワークを複数プロセスに割り当てる。k3s schedulerがNodeのリソースをPodに割り当てるのと同じ役割。 k3s scheduler → OSのリソースマネージャーと同じ役割 Docker API → OSの拡張マシンと同じ役割 OSがやってることをk3sやDockerが上位レイヤーで再現している。 ユーザー空間とカーネル空間 ┌─────────────────────────────┐ │ ユーザー空間 │ │ Docker、アプリ、k3s、etc... │ │ → 直接ハードウェアは触れない │ └──────────┬──────────────────┘ │ システムコール(唯一の通路) ┌──────────▼──────────────────┐ │ カーネル空間 │ │ スケジューラ │ │ メモリ管理 │ │ ファイルシステム │ │ デバイスドライバ │ │ → ハードウェアを直接触れる │ └─────────────────────────────┘ アプリが直接ハードウェアを触れたら危険。カーネルが仲介することで安全性を保証する。 システムコール docker runした時の実際の流れ: docker run ubuntu ↓ Dockerデーモン ↓ clone() ← プロセス生成 unshare() ← namespaceを作る mount() ← ファイルシステムをマウント ↓ Linuxカーネル Dockerはシステムコールの集合体。魔法じゃなくてLinuxのシステムコールをうまく組み合わせてるだけ。 ...

April 26, 2026 · 3 min

Emacs 30.2 で *-ts-mode が壊れる問題と対処

結論 Mike Olson - Fixing typescript-ts-mode in Emacs 30.2 上記のブログで解説と対応スクリプトが公開されてる。 Emacs 30.2 + libtree-sitter 0.26 の組み合わせで go-ts-mode や typescript-ts-mode などの *-ts-mode が動作しない場合、現時点(2026年4月)では以下のワークアラウンドで動作させることができる。 現時点ではこれが最適解と思う。おそらくEmacs 31 安定版がリリースされるまでこのスクリプトを使い続けることになる。 mkdir -p ~/.emacs.d/init curl -o ~/.emacs.d/init/treesit-predicate-rewrite.el \ https://raw.githubusercontent.com/mwolson/emacs-shared/master/init/treesit-predicate-rewrite.el init.el の早い段階(他の *-ts-mode の設定より前)に追加する。 (load "~/.emacs.d/init/treesit-predicate-rewrite" nil nil nil t) 経緯 go-ts-mode を開いたとき *Messages* バッファに treesit-query-error が出てシンタックスハイライトが死んだ。 最初はグラマーの .so ファイルが原因だと思い、treesit-install-language-grammar で入れ直したり、~/.emacs.d/tree-sitter/ 以下のファイルを削除して再インストールしたりと試行錯誤した。しかし何をやっても症状が変わらず、グラマー側の問題ではないと判断した。 調べたところ Emacs bug#79687 に行き着いた。グラマーの問題ではなく、Emacs 30.2 と libtree-sitter 0.26 の組み合わせ自体が壊れていた。 症状 Emacs 30.2 で Go や TypeScript などのファイルを開くと、*Messages* バッファに以下のようなエラーが表示され、シンタックスハイライトが一切効かなくなる。 Error during redisplay: (jit-lock-function 35) signaled (treesit-query-error "Syntax error at" 73 "(call_expression function: ((identifier) @font-lock-builtin-face (#match \"...\" @font-lock-builtin-face)))" "Debug the query with `treesit-query-validate'") go-ts-mode だけでなく typescript-ts-mode、python-ts-mode、rust-ts-mode など、tree-sitter ベースの全モードで同様の問題が発生する。 ...

April 23, 2026 · 2 min

自宅NWをKeepalivedとdnsmasqで作り直した話

背景 自宅のネットワーク構成が辛かった。 具体的には以下の問題があった。 ルータが1台構成で、死んだら自宅NW全滅 メンテナンスで定期的に落としたいとかあっても、コストが大きい DNS/DHCPがルータに同居していて、役割が混在している WireGuardで外部接続していたが、外部からの入り方がだるい。 特に「冗長化したい」という気持ちは何年も前からあったが、DNSとDHCPの同期という難問の前に何度も挫折してきた。 結論からいえば、DNS,DHCPの冗長化は諦めた。 諦めた上で出口のルータとDNS、DHCPは役割を分けた上で出口のルータとWIFIルータのみ冗長化を実施した。 設計方針 過去の失敗から学んだ一番の教訓はやはり「DNS/DHCPの冗長化は難しい」ということだ。 理論上可能ではあるが、私は万年初級自宅インフラエンジニアでいつまで経ってもできる目処が立たない。 それでいて、生成AIという過ぎた兵器を持ってしても、この問題は解決しなかったので、難しいというよりは不可能とした。 2台のサーバでDHCPを冗長化しようとすると、リースの同期問題が必ず発生する。同期ツールを使ったりしたが、どうしても同期しきれなかった。 そこで今回は思い切って諦めた上で役割を分離する方針にした。 ルータ(冗長化) → GWとTailscaleだけ担当 AP → hostapdのみ DNS/DHCP → 専用機1台に集約(冗長化しない) DNSとDHCPは単一障害点になるが、自宅ラボであれば許容範囲だと判断した。 てかどうしようもない。 構成 使用機材はすべてRaspberry Pi。封印していたタワーからも引っ張り出した。 ホスト 役割 ルータA (MASTER) Keepalived + Tailscale ルータB (BACKUP) Keepalived + Tailscale DNS/DHCP機 dnsmasq専用 AP x2 WIFI冗長化 ネットワークセグメントはひとつ。VIPをデフォルトゲートウェイ兼DNSとして各クライアントに配布する。 Keepalivedの設定 まずルータ2台にKeepalivedを入れる。 sudo apt install -y keepalived MASTER側の設定: vrrp_instance VI_1 { state MASTER interface lan-if virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass xxxxxxxx } virtual_ipaddress { 192.168.xx.1/24 } } BACKUP側は state BACKUP と priority 90 に変えるだけ。シンプルだ。 ...

April 18, 2026 · 2 min

ドメイン購入後のやり残し作業 - メールとDNS設定編

wasutech.dev を公開したはいいが、メール周りを何もしていなかった。放置するとなりすましに悪用される可能性があるので、Cloudflare Email Routing・SPF・DMARCを設定した。 Cloudflare Email Routing 自前のメールサーバーを建てるのはコストがかかる。Cloudflareには Email Routing という機能があり、@wasutech.dev 宛のメールを既存のGmailなどに転送できる。無料。 仕組みとしては、Cloudflareが自動でMXレコードを追加し、受信したメールを指定のアドレスへ転送する。 dig MX wasutech.dev # → isaac.mx.cloudflare.net 等が返ってくる MXレコードはドメインレベルの情報なので、転送先のメールアドレスは外部に公開されない。dig で見えるのはCloudflareのサーバーだけで、「どこに転送しているか」は誰にもわからない。 設定はCloudflareのダッシュボードから数クリックで完了する。 転送先のアクションは3種類から選べる。 アクション 動作 Forward to email 指定のメールアドレスへ転送 Drop 受信して即破棄。転送しない Send to Worker Cloudflare Workersで独自処理 今回はメールを受け取る必要がないため Drop に設定した。スパム対策にもなるし、転送先アドレスを管理する必要もない。Workers連携は受信メールをSlackに流したり、自動返信を実装したりする場合に使う。 SPF - 送信元を証明するレコード SPFとは SPF(Sender Policy Framework) は、「このドメインからメールを送信していいサーバーはどこか」を定義するDNSレコード。 なぜ必要か。メールのプロトコル(SMTP)は設計上、送信元アドレスを自由に詐称できる。つまり誰でも [email protected] を名乗ってメールを送れる。SPFはこれを受信側が検証できるようにする仕組み。 受信側のメールサーバーは、届いたメールの送信元IPアドレスを確認し、そのドメインのSPFレコードに記載されたIPと照合する。一致しなければ怪しいメールとして処理できる。 設定したレコード v=spf1 include:_spf.mx.cloudflare.net ~all 各要素の意味: 要素 意味 v=spf1 SPFバージョン1 include:_spf.mx.cloudflare.net CloudflareのメールサーバーからのSMTPを許可 ~all 上記以外は「疑わしい」扱い(ソフトフェイル) ~all は疑わしいメールを迷惑メール扱いにする。-all にすると完全拒否になるが、DMARCと組み合わせて制御するのが一般的。 確認: dig TXT wasutech.dev # v=spf1 include:_spf.mx.cloudflare.net ~all DMARC - SPFの結果を使って何をするか決めるレコード DMARCとは DMARC(Domain-based Message Authentication, Reporting, and Conformance) は、SPF(やDKIM)の検証結果に基づいて、受信側が「そのメールをどう扱うか」を指示するレコード。 ...

April 14, 2026 · 1 min

Cloudflare Workers でサイト監視 + Discord通知を作った

外形監視をどこに任せるか迷った。ラズパイでやるか、Cloudflareに任せるか。 外から見えるサービスの監視なら せっかくなのでCloudflare Workersにする。 自宅NWそこそこ落ちたりするので・・・。 ラズパイと比較した Cloudflare Workers ラズパイ 向いてる監視 外形監視(外からの死活確認) 内部NW監視 コスト 無料 電気代のみ メンテ ほぼゼロ たまに落ちる ローカルNW確認 ❌ ✅ 最小間隔 1分 自由 今回は wasutech.dev と blog.wasutech.dev、techblog.wasutech.dev の3つを監視したい。 Cloudflare Workers 無料枠で十分な理由 公式ドキュメント - Limits によると、無料プランは以下のとおり。 Cron Triggers: 5個まで リクエスト: 1日10万回まで CPU時間: 10ms/invocation 今回のユースケースは「HTTPリクエスト投げてステータスコード確認して Discord Webhook 叩く」だけなので、CPU時間は 2〜3ms で収まる。5分間隔で3ドメイン監視しても 1日864リクエストなので余裕。 コード全文 // src/index.ts const TARGETS = [ { name: "wasutech.dev", url: "https://wasutech.dev" }, { name: "blog.wasutech.dev", url: "https://blog.wasutech.dev" }, { name: "techblog.wasutech.dev", url: "https://techblog.wasutech.dev" }, ]; export default { async scheduled(_event: ScheduledEvent, env: Env, _ctx: ExecutionContext) { const results = await Promise.allSettled( TARGETS.map((t) => check(t.name, t.url)) ); const failures = results .map((r, i) => ({ result: r, target: TARGETS[i] })) .filter(({ result }) => result.status === "rejected" || (result.status === "fulfilled" && !result.value.ok) ); if (failures.length > 0) { const lines = failures.map(({ result, target }) => { const detail = result.status === "rejected" ? (result.reason as Error).message : `HTTP ${(result.value as Response).status}`; return `🔴 ${target.name} | ${detail}`; }); await notify(env.DISCORD_WEBHOOK, lines.join("\n")); } }, }; async function check(name: string, url: string): Promise<Response> { const res = await fetch(url, { method: "HEAD", signal: AbortSignal.timeout(10000), }); if (!res.ok) throw new Error(`HTTP ${res.status}`); return res; } async function notify(webhookUrl: string, msg: string) { await fetch(webhookUrl, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ content: msg }), }); } interface Env { DISCORD_WEBHOOK: string; } # wrangler.toml name = "wasutech-monitor" main = "src/index.ts" compatibility_date = "2025-01-01" [triggers] crons = ["*/5 * * * *"] Promise.allSettled を使った理由 Promise.all だと1つが失敗した時点で残りを待たずに throw する。 Promise.allSettled なら3つ並列でチェックして、全部の結果を集めてからまとめて通知できる。 1メッセージにまとめることでDiscordがスパムにならない。 ...

April 13, 2026 · 2 min

CloudflareアラートをWorker + Gemini APIでDiscordに要約通知する

Cloudflareの通知をDiscord Webhookに流していたら、通知が大量に届くようになってしまった。重要なアラートが埋もれるので、Cloudflare Workers + Gemini APIで要約してから投稿するようにした。 方針 Cloudflareの通知設定で追加できるアラートはとりあえず全部有効にしている。各アラートが実際に役立つかは様子を見ながら判断する予定。 ただしセキュリティアラートはだいたい30分に数回届いたため、現時点では通知をスキップするようにした。それ以外のアラートは引き続き通知して様子見中。 構成 Cloudflare Alert → Worker受信 → フィルタリング(スキップ対象なら早期リターン) → Gemini API で日本語要約 → Discord Webhook に送信 前提 Cloudflare WorkersにDiscord Webhook通知のWorkerが既にある Google AI StudioのAPIキーを持っている モデル選定 Geminiのモデルは料金帯がいくつかある。 gemini-2.5-pro > gemini-2.5-flash > gemini-2.5-flash-lite Cloudflareアラートの要約程度であれば gemini-2.5-flash-lite で十分。一番安い。 最新のモデル名は公式ドキュメントで確認すること。 https://ai.google.dev/gemini-api/docs/models 実装 フィルタリングの考え方 頻度の高いアラートはWorker側でスキップできるようにしている。SKIP_ALERT_TYPES に列挙したタイプが一致した場合、Gemini APIを呼ばずに早期リターンする。不要なAPI呼び出しも減るのでコスト面でも良い。 どのアラートがどの alert_type を持つかはCloudflareの公式ドキュメントで確認できる。 https://developers.cloudflare.com/notifications/notification-available/ Worker コード // スキップしたいアラートタイプ(頻度が高くて邪魔なものを列挙) const SKIP_ALERT_TYPES = [ "security_alerts", // セキュリティアラート:30分に数回来るので無効化中 ]; async function summarizeWithGemini(apiKey, input) { const prompt = `以下のCloudflareアラートを日本語で3行以内に要約してください。重要度(🔴高/🟡中/🟢低)も判定してください。\n\n${input}`; const res = await fetch( `https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash-lite-preview-06-17:generateContent?key=${apiKey}`, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ contents: [{ parts: [{ text: prompt }] }] }) } ); const data = await res.json(); console.log("Gemini response:", JSON.stringify(data)); return data.candidates?.[0]?.content?.parts?.[0]?.text || "要約失敗"; } export default { async fetch(request, env) { if (request.method !== "POST") { return new Response("ok"); } let body; try { body = await request.json(); } catch { return new Response("invalid json", { status: 400 }); } // アラートタイプによるフィルタリング const alertType = body.text?.alert_type || body.alert_type || ""; if (SKIP_ALERT_TYPES.some(t => alertType.includes(t))) { console.log(`Skipped alert type: ${alertType}`); return new Response("skipped"); } // Geminiには常にbody全体を渡す const input = JSON.stringify(body).slice(0, 500); const summary = await summarizeWithGemini(env.GEMINI_API_KEY, input); const message = { username: "Cloudflare", embeds: [{ title: body.text?.title || body.text?.description || "Cloudflare Notification", description: summary, color: 0xF6821F, timestamp: new Date().toISOString() }] }; await fetch(env.DISCORD_WEBHOOK, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify(message) }); return new Response("ok"); } } シークレット登録 wrangler secret put GEMINI_API_KEY wrangler secret put DISCORD_WEBHOOK 動作確認 curl -X POST https://<your-worker>.workers.dev \ -H "Content-Type: application/json" \ -d '{"text": {"title": "テスト通知", "description": "これはテストです"}}' スキップ確認: ...

April 12, 2026 · 2 min

Cloudflareの全通知をDiscord Webhookに飛ばす

CloudflareのNotificationsはUIから1個ずつ設定するのがとにかくだるい。 種別も多いし、手動でDiscord Webhookを登録していくのは非現実的。 Cloudflare APIとWorkersを組み合わせて全通知を一括登録する。 構成 Cloudflare Notifications ↓ Cloudflare Worker (受け口) ↓ Discord Webhook Cloudflare NotificationsはWebhook送信に対応しているので、Workerを受け口にしてDiscordに転送する。 1. Discord Webhookを作成 通知を飛ばしたいDiscordチャンネルの設定から作成する。 チャンネル設定 → Integrations → Webhooks → New Webhook → Copy Webhook URL 2. Cloudflare Workerを作成 Cloudflareダッシュボードから Workers & Pages → Create → Hello World で作成する。 名前は cf-notify-discord など適当につけてDeploy。 エディタ画面で以下のコードに置き換える。 export default { async fetch(request, env) { if (request.method !== "POST") { return new Response("ok"); } let body; try { body = await request.json(); } catch { return new Response("invalid json", { status: 400 }); } const message = { username: "Cloudflare", embeds: [{ title: body.text?.title || "Cloudflare Notification", description: body.text?.description || JSON.stringify(body, null, 2), color: 0xF6821F, timestamp: new Date().toISOString() }] }; await fetch(env.DISCORD_WEBHOOK, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify(message) }); return new Response("ok"); } } Discord WebhookのURLはWorkerのSettings → Variables and Secretsでシークレットとして登録する。 ...

April 12, 2026 · 3 min

WaylandでモニターがマイクとスピーカーとしてOSに認識される問題をWirePlumberで無効化する

問題 ふとDesktopの画面を見るとモニターがマイクとスピーカーとしてOSに認識されていた。 誤って爆音で音が再生されるリスクが気になったため無効化することにした。 ついでにマイクも有効にする意味がない環境だったので止めた。 純粋な開発PCで動画とかも見ないそこそこ特殊?な環境なので最悪読み込まないなら何でもいい状態。 環境 OS: ArchLinux サウンドサーバー: PipeWire + WirePlumber 0.5.14 GPU: AMD Ryzen(APU) 問題のデバイス: AMD/ATI Raven/Raven2/Fenghuang HDMI/DP Audio Controller 原因 HDMI/DisplayPortには映像だけでなく音声も伝送できる仕様(Audio over HDMI)がある。 LinuxはこれをALSAレベルで別サウンドカードとして認識するため、 PipeWireがそのまま拾ってオーディオデバイスとして公開してしまう。 調査 認識されているカードを確認 pactl list cards short 49 alsa_card.pci-0000_04_00.1 alsa 50 alsa_card.pci-0000_04_00.6 alsa 2枚のサウンドカードが認識されている。詳細を確認する。 pactl list cards | grep -A 30 "alsa_card.pci-0000_04_00" 結果を整理すると: PCI アドレス ベンダー 説明 用途 0000:04:00.1 AMD/ATI Raven HDMI/DP Audio Controller モニター側(不要) 0000:04:00.6 AMD + Realtek ALC269VB Ryzen HD Audio Controller 本物のオンボードサウンド 0000:04:00.1 の alsa_mixer_name が ATI R6xx HDMI であることからも、 これがHDMI経由のオーディオデバイスだと確定できる。 ...

April 11, 2026 · 1 min

AdGuard HomeをProxmox LXCに立ててTailscale経由でDNSブロックする

概要 はてな匿名ダイアリーとウーバーイーツをインフラレベルで封鎖したかった。 AdGuard HomeをProxmox LXCに立てて、Tailscale経由でDNSブロックする構成を作った。 環境 Proxmox VE Tailscale導入済み AdGuard Home v0.108.0 手順 1. AdGuard Home LXCをスクリプト一発で作成 Proxmoxのノードシェルで以下を実行する。 bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/adguard.sh)" community-scripts/ProxmoxVEが提供するスクリプト。 LXCのコンテナ作成からAdGuard Homeのインストールまで全自動でやってくれる。 デフォルト構成はDebian 13、CPU 1コア、RAM 512MB、HDD 2GB。DNS用途なら十分。 2. LXCにTUNデバイスを追加する TailscaleはWireGuardベースのVPNで、動作に/dev/net/tunが必要。 /dev/net/tunはLinuxの仮想ネットワークデバイス(TUNデバイス)。通常のネットワークデバイス(eth0等)は物理NICに紐づいているが、TUNはソフトウェアで作った仮想NIC。 Tailscaleは以下の流れで通信を処理する。 通信をTailscaleプロセスが横取り WireGuardで暗号化 暗号化したパケットを相手に送る この「横取り」の実装に/dev/net/tunを使う。TUNデバイスを通してカーネルのネットワークスタックとTailscaleプロセスがやり取りする仕組みになっている。 unprivileged LXCはセキュリティ上の理由でホストのデバイスに触れないようになっているため、明示的に/dev/net/tunをコンテナに見せてあげる必要がある。 Proxmoxのノードシェルで以下を実行してTUNを有効化する。 pct stop 106 echo "lxc.cgroup2.devices.allow: c 10:200 rwm" >> /etc/pve/lxc/106.conf echo "lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file" >> /etc/pve/lxc/106.conf pct start 106 106の部分は自分のLXCのIDに置き換える。IDはpct listで確認できる。 3. LXCにTailscaleを入れる LXCのシェルに入って以下を実行する。 curl -fsSL https://tailscale.com/install.sh | sh tailscale up 認証URLが表示されるのでブラウザで開いてログインする。 認証後、TailscaleのMachines画面からAdGuard HomeのTailscale IPを確認しておく。 ...

April 6, 2026 · 1 min

ArchLinuxのThunarでWalkmanのFSを開く

背景 手持ちのWalkmanをLinux(Arch Linux)環境で活用したいと考えた。 単に音楽を聴くだけでなく、PCのファイルを転送したり、時にはPCの音を高音質で鳴らすオーディオインターフェースとして使いこなすのが目的だ。 ドキュメントを読む限り、最近のデバイスはMTP(Media Transfer Protocol)に対応しており、Linuxでも標準的なツールで扱えるはずだ。 環境 OS: Arch Linux File Manager: Thunar Device: Walkman (MTP/USB DAC対応モデル) Tools: usbutils, gvfs-mtp, libmtp, jmtpfs ThunarでWalkmanのFSが見えない WalkmanをUSBケーブルでPCに接続し、Thunarを開いたがサイドバーには何も表示されない。 まず物理的な接続を確認しようと lsusb を叩いたところ、コマンド自体が入っていなかった。 sudo pacman -S usbutils 改めて確認する。 $ lsusb Bus 001 Device 008: ID 054c:0c2f Sony Corp. Walkman デバイス自体はUSBレベルでは認識されている。fdisk -l にブロックデバイスとして出てこないのはMTPなので当然だ。 原因:MTP用ライブラリが未インストール gvfs-mtp と libmtp が入っていないのが原因だった。 sudo pacman -S gvfs-mtp libmtp # Thunarを再起動して反映 thunar -q これでThunarのサイドバーにWalkmanが表示され、GUIでファイルをコピーできるようになった。 補足:USB DACモードとは 調査中に「DACモードでなければ動かないのか?」と気になって調べたのでここにまとめておく。 USB DACモードとは、デバイスを「ストレージ」としてではなく、**「USBオーディオデバイス」**としてPCに認識させるモードだ。ファイル転送には使えない。 モード PCからの見え方 用途 MTP / MSC ストレージ ファイル転送 USB DAC オーディオデバイス PC音声出力 Walkman側の設定でどちらのモードになっているかは確認しておく必要がある。 ...

April 4, 2026 · 1 min