fcitx5 で日本語・中国語・英語の3言語入力環境を構築する

2026-03-07T00:00:00+00:00

筆者が普段使っている日本語・中国語・英語の3言語入力環境を、fcitx5 でどう設定しているかをまとめました。

はじめに</h2>
複数の言語を日常的に使う場合、入力メソッドの切り替えがスムーズにできるかどうかは作業効率に直結します。
Linux の入力メソッドフレームワークは主に2つあります。
フレームワーク</th> 特徴</th></tr></thead>

fcitx5</td> 多言語対応に強く、複数の入力メソッドをグループ化して切り替えられる。多言語環境ではこちらが主流</td></tr>
ibus</td> GNOME のデフォルト。単一言語であれば十分だが、多言語の切り替えは fcitx5 の方がスムーズ</td></tr> </tbody></table>
この記事では、fcitx5 を使って以下の3言語を1つのキーで切り替えられる環境を構築します。
言語</th> 入力メソッド</th> 説明</th></tr></thead>

英語</td> keyboard-jp</code></td> JIS 配列キーボードでそのまま英数入力</td></tr>
日本語</td> mozc</code></td> Google 日本語入力の OSS 版。Linux 日本語入力のデファクトスタンダード</td></tr>
中国語</td> pinyin</code></td> fcitx5 内蔵のピンイン入力エンジン。簡体字・繁体字の両方に対応</td></tr> </tbody></table>
動作環境は Debian 13 (trixie) + Xfce4 ですが、他のディストリビューションやデスクトップ環境でも手順はほぼ同じです。

パッケージのインストール</h2>
必要なパッケージをインストールします。
sudo apt install fcitx5 fcitx5-mozc fcitx5-chinese-addons</code></pre>パッケージ</th> 用途</th></tr></thead> fcitx5</code></td> 入力メソッドフレームワーク本体</td></tr> fcitx5-mozc</code></td> 日本語入力エンジン（Mozc）</td></tr> fcitx5-chinese-addons</code></td> 中国語入力のメタパッケージ（pinyin、簡繁変換等を含む）</td></tr> </tbody></table> fcitx5-chinese-addons</code> をインストールすると、依存関係で fcitx5-pinyin</code>（ピンイン入力エンジン）や簡繁変換アドオンなども一緒にインストールされます。 環境変数の設定</h2> fcitx5 をすべてのアプリケーションで使えるようにするため、以下の環境変数が必要です。 export XMODIFIERS=@im=fcitx export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx</code></pre> Debian では im-config</code> コマンドで設定するのが標準的な方法です。 im-config -n fcitx5</code></pre> これにより ~/.xinputrc</code> に run_im fcitx5</code> が書き込まれ、X セッション開始時に /etc/X11/Xsession.d/70im-config_launch</code> 経由で環境変数が自動的に設定されます。手動で ~/.xprofile</code> 等に書く必要はありません。 設定後、ログインし直すと反映されます。 プロファイルの設定</h2> fcitx5 のプロファイル（~/.config/fcitx5/profile</code>）で、使用する入力メソッドを定義します。 [Groups/0] # Group Name Name=Default # Layout Default Layout=jp # Default Input Method DefaultIM=mozc [Groups/0/Items/0] # Name Name=keyboard-jp # Layout Layout= [Groups/0/Items/1] # Name Name=mozc # Layout Layout= [Groups/0/Items/2] # Name Name=pinyin # Layout Layout= [GroupOrder] 0=Default</code></pre> Default Layout=jp</code> — ベースのキーボードレイアウトを JIS 配列に設定</li> DefaultIM=mozc</code> — デフォルトの入力メソッドを Mozc に設定</li> Items/0</code>〜Items/2</code> — トリガーキーで順に切り替わる入力メソッドの一覧</li> </ul> GUI で設定する場合は fcitx5-configtool</code> を使って、Input Method の一覧に keyboard-jp、mozc、pinyin を追加します。 ホットキーの設定</h2> 入力メソッドの切り替えキーは ~/.config/fcitx5/config</code> で設定します。主要な設定項目を抜粋します。 [Hotkey] # Skip first input method while enumerating EnumerateSkipFirst=False [Hotkey/TriggerKeys] 0=Shift+space [Hotkey/EnumerateGroupForwardKeys] 0=Control+Shift+Shift_R [Behavior] # Share Input State ShareInputState=No # Show preedit in application PreeditEnabledByDefault=True</code></pre> TriggerKeys (Shift+Space</code>) — 入力メソッドを順に切り替えるキー。押すたびに keyboard-jp → mozc → pinyin → keyboard-jp ... と循環します</li> EnumerateSkipFirst (False</code>) — False</code> にすると keyboard-jp（英語直接入力）も切り替え対象に含まれます。True</code> にすると最初の入力メソッドをスキップします</li> EnumerateGroupForwardKeys (Control+Shift+Shift_R</code>) — 入力メソッドグループ全体を切り替えるキー。グループを1つしか使わない場合は不要ですが、将来グループを追加した場合（例: 別のキーボードレイアウト用グループ）に使えます</li> ShareInputState (No</code>) — ウィンドウごとに入力メソッドの状態を独立させます</li> </ul> 設定を変更したら fcitx5 を再起動します。-r</code> は既存プロセスの置き換え（replace）、-d</code> はデーモンとしてバックグラウンド実行です。 fcitx5 -r -d</code></pre> ピンインで繁体字を入力する</h2> fcitx5-chinese-addons に含まれる「簡繁変換」アドオン（chttrans</code>）を使うと、ピンイン入力のまま簡体字と繁体字を切り替えられます。別の入力メソッドを追加する必要はありません。 切り替え方法</h3> ピンイン入力中に Ctrl+Shift+F</code> を押すと、出力が簡体字から繁体字に切り替わります。もう一度押すと簡体字に戻ります。 設定の確認</h3> このアドオンは fcitx5-chinese-addons</code> に含まれているため、パッケージをインストールしていれば追加設定なしで使えます。fcitx5-configtool</code> の Addons タブで「Simplified and Traditional Chinese Translation」が有効になっていることを確認してください。 トラブルシューティング</h2> プロファイルがリセットされる</h3> まれに、リブート後に ~/.config/fcitx5/profile</code> がデフォルト（keyboard-jp</code> のみ）にリセットされることがあります。原因はクラッシュや異常終了時のプロファイル書き戻し失敗が考えられます。 対策として、正常動作時のプロファイルと設定のバックアップを取っておくことをお勧めします。 cp ~/.config/fcitx5/profile ~/.config/fcitx5/profile.bak cp ~/.config/fcitx5/config ~/.config/fcitx5/config.bak</code></pre>fcitx5 が起動しない・入力できない</h3> 環境変数が正しく設定されているか確認します。 echo $XMODIFIERS # @im=fcitx であること echo $GTK_IM_MODULE # fcitx であること echo $QT_IM_MODULE # fcitx であること</code></pre> fcitx5-diagnose</code> コマンドを実行すると、設定の問題を包括的に診断できます。 まとめ</h2> fcitx5 で日本語・中国語・英語の3言語入力環境を構築しました。 fcitx5 — 多言語切り替えに適した入力メソッドフレームワーク</li> mozc — 日本語入力のデファクトスタンダード</li> pinyin — 中国語ピンイン入力。Ctrl+Shift+F</code> で簡繁変換も可能</li> Shift+Space 一つで3言語を循環切り替え</li> </ul> 設定ファイルは ~/.config/fcitx5/profile</code>（入力メソッドの構成）と ~/.config/fcitx5/config</code>（ホットキーや動作設定）の2つだけなので、バックアップも容易です。 パスワードなしの認証を試す: oauth2-passkey ライブデモ 2026-03-02T00:00:00+00:00 English version</a> oauth2-passkey</a> は、OAuth2 と Passkey を組み合わせたパスワードレス認証を、少ないコードで Rust の Web アプリに組み込めるライブラリです。 デモサイト passkey-demo.ccmp.jp</a> を用意しました。実際の操作を2本の動画で紹介し、その後にコードの使い方を説明します。 デモ 1: Google で登録して Passkey を追加</h2> </video> まず新規ユーザーとしてログインする流れです。 ログインページには「Register / Sign in with Google」と「Sign in with Passkey」の2つのボタンがあります。</li> 「Register / Sign in with Google」を押すと、おなじみの Google アカウント選択画面が開きます。</li> Google 認証が終わると、すぐに「Passkey を作成しますか？」 というダイアログが出ます。これがこのライブラリの特徴の一つである「Passkey プロモーション」 です。OAuth2 でログインしたユーザーに Passkey の登録を自然に促します。</li> Passkey を作成するとダッシュボードに遷移し、My Account や Admin Panel にアクセスできます。</li> My Account ページでは、ユーザー情報・Passkey 資格情報・連携 OAuth2 アカウント・ログイン履歴を一覧で確認できます。</li> </ol> いつもの Google ログインで始めて、そのまま Passkey も登録できるのがこの仕組みのよいところです。 デモ 2: Passkey でサインイン</h2> </video> 続いて、同じユーザーが Passkey だけでログインする流れです。 ログインページで「Sign in with Passkey」を押すと、ブラウザの Passkey ダイアログが表示されます。</li> 指紋や顔認証で本人確認をすれば、それだけでログインが完了します。Google へのリダイレクトもパスワード入力も要りません。</li> ログイン履歴には Passkey と OAuth2 の両方のエントリーが残るので、いつ・どの方法でログインしたか確認できます。</li> </ol> Passkey を一度登録してしまえば、普段のログインはこれだけです。高速で、フィッシングにも強い認証が手に入ります。 試してみる</h2> デモサイトはこちらです: passkey-demo.ccmp.jp</a> Google でサインイン → Passkey を登録 → Passkey でサインイン、という一連の流れを試せます</li> デモでは全ユーザーに管理者権限が付与されるので、管理パネルも自由に操作できます</li> ログイン履歴ではデバイスや認証方法の詳細も確認できます</li> </ul> データはメモリ上に保存されていて、サーバー再起動時にリセットされます。気軽にどうぞ。 oauth2-passkey とは</h2> oauth2-passkey</a> は、Web アプリにパスワードレス認証を追加するための Rust ライブラリです。2種類の認証方式を一つのライブラリで扱えます。 OAuth2 (Google) -- ユーザーにとって馴染みのある、ワンクリックの登録・ログイン</li> Passkeys (WebAuthn/FIDO2) -- 指紋・顔・セキュリティキーによる、フィッシング耐性のあるログイン</li> </ul> 想定する運用フローは、まず Google で登録してもらい、その流れで Passkey も追加してもらう形です。デバイスを紛失した場合でも Google 経由でログインできるので、Passkey 一本に依存するリスクを回避できます。 クイックスタート</h2> Axum アプリへの組み込みは以下のようになります。 use axum::{Router, routing::get, response::IntoResponse}; use oauth2_passkey_axum::{AuthUser, oauth2_passkey_full_router}; #[tokio::main] async fn main() -> Result<(), Box<dyn std::error::Error>> { oauth2_passkey_axum::init().await?; let app = Router::new() .route("/", get(home)) .route("/protected", get(protected)) .merge(oauth2_passkey_full_router()); let listener = tokio::net::TcpListener::bind("0.0.0.0:3001").await?; axum::serve(listener, app).await?; Ok(()) } async fn home() -> &'static str { "Welcome! Visit /o2p/user/login to sign in" } async fn protected(user: AuthUser) -> impl IntoResponse { format!("Hello, {}!", user.account) }</code></pre> oauth2_passkey_full_router()</code> を呼ぶと、/o2p/*</code> 以下に、ログインページ・OAuth2 フロー・Passkey の登録／認証・ユーザーアカウント管理・管理パネルなど、一式のルートが追加されます。 あとは環境変数で Google OAuth2 のクレデンシャルとセッションシークレットを設定すれば動きます。詳しくは Getting Started ガイド</a>をご覧ください。 機能一覧</h2> 機能</th> 説明</th></tr></thead> デュアル認証</td> OAuth2 (Google) と Passkeys を一つのライブラリで提供</td></tr> 組み込み UI</td> ログインページ、ユーザーアカウント画面、管理パネル付き</td></tr> Passkey プロモーション</td> OAuth2 ユーザーに Passkey 登録を自然に提案</td></tr> ログイン履歴</td> IP・User-Agent・認証器の詳細を自動記録</td></tr> セッション管理</td> セキュアな Cookie、セッション競合ポリシー、強制ログアウト</td></tr> 管理パネル</td> ユーザー管理、監査ログ、管理者の誤操作防止</td></tr> テーマ</td> 9種の CSS テーマを同梱、カスタムテーマにも対応</td></tr> ストレージ</td> SQLite（開発用）／PostgreSQL（本番用）、キャッシュは Redis またはインメモリに対応</td></tr> </tbody></table> リンク</h2> ライブデモ: passkey-demo.ccmp.jp</a></li> GitHub: ktaka-ccmp/oauth2-passkey</a></li> crates.io: oauth2-passkey</a> / oauth2-passkey-axum</a></li> ドキュメント: ktaka-ccmp.github.io/oauth2-passkey</a></li> </ul> 背景</h2> このライブラリは、2025年初頭に Passkey 認証をスクラッチで実装した記事</a>がきっかけで生まれました。そのとき WebAuthn プロトコルを一から学んだ経験をもとに、OAuth2 連携・セッション管理・UI を備えた汎用ライブラリとして仕立て直しました。 Try Passwordless Auth: oauth2-passkey Live Demo 2026-03-02T00:00:00+00:00 日本語版</a> A live demo of oauth2-passkey</a>, a Rust library that adds OAuth2 and Passkey authentication to your web app with minimal code. Two short videos below walk through the demo at passkey-demo.ccmp.jp</a> — first registering via Google and adding a Passkey, then signing in using only the Passkey. Demo 1: Register with Google and Add a Passkey</h2> </video> Here's what happens in the video: The login page offers two options: "Register / Sign in with Google" and "Sign in with Passkey".</li> Clicking "Register / Sign in with Google" opens the standard Google account chooser and consent screen.</li> Immediately after Google authentication, the app prompts: "Create a passkey to sign in?" — this is the Passkey promotion feature, encouraging OAuth2 users to register a Passkey for faster future logins.</li> After creating the Passkey, the user lands on the Dashboard with links to My Account and Admin Panel.</li> The My Account page shows User Information, Passkey Credentials, linked OAuth2 Accounts, and Recent Login History.</li> </ol> The key idea: users start with the familiarity of Google sign-in, then immediately gain the speed and security of Passkeys. Demo 2: Sign in with Passkey</h2> </video> Now the same user signs in again, this time with their Passkey: On the login page, clicking "Sign in with Passkey" triggers the browser's built-in Passkey dialog.</li> After biometric verification (fingerprint, face, etc.), the user is logged in instantly —no redirect to Google, no password.</li> The Login History now shows both the Passkey login and the earlier OAuth2 login, so users can review their full authentication history.</li> </ol> This is the daily login experience: fast, phishing-resistant, and free of external dependencies once the Passkey is registered. Try It Yourself</h2> Try it now: passkey-demo.ccmp.jp</a> Sign in with Google, register a Passkey, then sign in with just the Passkey</li> Explore the admin panel (all demo users get admin access)</li> View login history with device and authenticator details</li> </ul> Data is stored in memory and resets on server restart, so feel free to experiment. What is oauth2-passkey?</h2> oauth2-passkey</a> is a Rust library for adding passwordless authentication to web applications. It combines: OAuth2 (Google) —One-click registration and login, familiar to users</li> Passkeys (WebAuthn/FIDO2) —Phishing-resistant, biometric login (fingerprint, face, security key)</li> </ul> Users sign up with Google, then optionally add a Passkey for faster daily logins. OAuth2 remains available as a fallback if a device is lost. Quick Start</h2> Add oauth2-passkey to your Axum application: use axum::{Router, routing::get, response::IntoResponse}; use oauth2_passkey_axum::{AuthUser, oauth2_passkey_full_router}; #[tokio::main] async fn main() -> Result<(), Box<dyn std::error::Error>> { oauth2_passkey_axum::init().await?; let app = Router::new() .route("/", get(home)) .route("/protected", get(protected)) .merge(oauth2_passkey_full_router()); let listener = tokio::net::TcpListener::bind("0.0.0.0:3001").await?; axum::serve(listener, app).await?; Ok(()) } async fn home() -> &'static str { "Welcome! Visit /o2p/user/login to sign in" } async fn protected(user: AuthUser) -> impl IntoResponse { format!("Hello, {}!", user.account) }</code></pre> The oauth2_passkey_full_router()</code> call adds all authentication routes under /o2p/*</code>, including the login page, OAuth2 flow, Passkey registration and authentication, user account management, and the admin panel. Set a few environment variables (Google OAuth2 credentials, session secret) and you're ready to go. See the Getting Started guide</a> for details. Features</h2> Feature</th> Description</th></tr></thead> Dual auth</td> OAuth2 (Google) + Passkeys in one library</td></tr> Built-in UI</td> Login page, user account, admin panel</td></tr> Passkey promotion</td> Prompts OAuth2 users to register a Passkey</td></tr> Login history</td> Records IP, User-Agent, authenticator details</td></tr> Session management</td> Secure cookies, conflict policies, force logout</td></tr> Admin panel</td> User management, audit trail, admin safeguards</td></tr> Theme system</td> 9 built-in CSS themes + custom theme support</td></tr> Storage</td> SQLite (development) or PostgreSQL (production), with Redis or in-memory caching</td></tr> </tbody></table> Links</h2> Live demo: passkey-demo.ccmp.jp</a></li> GitHub: ktaka-ccmp/oauth2-passkey</a></li> crates.io: oauth2-passkey</a> / oauth2-passkey-axum</a></li> Documentation: ktaka-ccmp.github.io/oauth2-passkey</a></li> </ul> Background</h2> This library grew out of a from-scratch Passkey implementation</a> I wrote in early 2025. That project gave me a deep understanding of the WebAuthn protocol, and I decided to package the result into a reusable library with OAuth2 integration, session management, and a complete UI. GNU Screen ユーザーのための tmux カスタマイズ 2026-03-01T00:00:00+00:00 長年 GNU Screen を使ってきたユーザーが tmux に移行する際に、違和感を減らすためのカスタマイズ記録です。 はじめに</h2> 20 年近く GNU Screen を使ってきました。ターミナルマルチプレクサとしては大きな不満もなく、乗り換える理由はありませんでした。 きっかけは Claude Code です。Claude Code はターミナル上で動作する AI コーディングアシスタントですが、Screen 上で使うと表示が崩れる問題がありました。具体的には、テキストの各単語に不正な背景色ブロックが付いて短冊状に表示されたり、起動時の ASCII アートロゴが白いブロックノイズに化けたりします。Screen が、Claude Code の TUI が使用するカラーエスケープシーケンスを正しく処理できていないようです。 tmux ではこの問題は起きませんでした。Claude Code を快適に使うために、tmux への移行を決めました。 Screen ユーザーが戸惑うポイント</h2> tmux に移行してまず戸惑ったのが、画面分割まわりの操作体系の違いです。 プレフィックスキー</h3> Screen のデフォルトプレフィックスは Ctrl+a</code>、tmux は Ctrl+b</code> です。これは ~/.tmux.conf</code> で簡単に変更できるので、すぐに解決しました。 画面分割の考え方が違う</h3> Screen の特徴として、「リージョン」と「ウィンドウ」が明確に分かれています。Ctrl+a</code> → S</code> で画面をリージョン分割し、各リージョンに既存のウィンドウを割り当てます。リージョンを閉じてもウィンドウ（シェル）は残ります。Ctrl+a</code> → Q</code> でリージョンを全解除して元の 1 画面に戻す、というのがよくある使い方でした。 tmux では「ペイン」がこれに相当しますが、ペインを作ると新しいシェルが自動起動します。Screen のように「画面を分割してから既存のウィンドウを割り当てる」という手順ではなく、「分割と同時に新しいシェルが生まれる」という動作です。 また、Screen の Ctrl+a</code> → Q</code>（リージョン全解除）に直接対応するキーがありません。tmux では Ctrl+a</code> → z</code> でペインをズーム（全画面化）するのが近い感覚ですが、他のペインを閉じるわけではないので挙動が異なります。 ペインを独立したウィンドウに戻したい場合は Ctrl+a</code> → !</code>（break-pane）で 1 つずつ分離する必要があります。複数ペインを一括で分離するコマンドはデフォルトにはありません。 こういった違いに戸惑うことが多かったので、Screen ユーザーが直感的に使えるキーバインドをカスタマイズしました。 ~/.tmux.conf</h2> 以下がカスタマイズした設定です。カスタムキーバインドに加えて、デフォルトのよく使うキーバインドもコメントでチートシートとして埋め込んでいます。設定ファイル自体がリファレンスになるようにしています。 設定を変更した後は、tmux 内で Ctrl+a</code> → :</code> を押してコマンドモードに入り、source-file ~/.tmux.conf</code> と入力するか、シェルから tmux source-file ~/.tmux.conf</code> を実行すると反映されます。 # ============================================= # Custom keybindings # ============================================= # Use Ctrl+a as prefix (same as GNU Screen) unbind C-b set -g prefix C-a # Ctrl+a -> a: Send literal Ctrl+a to the terminal bind a send-prefix # Enable mouse for pane resizing, selection, and scrolling set -g mouse on # Ctrl+a -> -: Split pane horizontally (top/bottom) bind - split-window -v # Ctrl+a -> |: Split pane vertically (left/right) bind | split-window -h # Ctrl+a -> @: Pull a pane from another window/session (interactive) bind @ choose-tree "join-pane -s '%%'" # Ctrl+a -> S: Send current pane to another window/session (interactive) bind S choose-tree "join-pane -t '%%'" # Ctrl+a -> Q: Break all panes into separate windows bind Q run-shell 'while [ $(tmux list-panes | wc -l) -gt 1 ]; do tmux break-pane -d; done' # ============================================= # Cheat sheet (default keybindings) # ============================================= # --- Pane navigation --- # Ctrl+a -> Arrow keys: Move between panes # Ctrl+a -> o: Move to next pane # Ctrl+a -> q: Display pane numbers (press number to jump) # Ctrl+a -> z: Toggle pane zoom (fullscreen) # --- Pane resizing --- # Ctrl+a -> Ctrl+Arrow keys: Resize pane by 1 cell # Ctrl+a -> Alt+Arrow keys: Resize pane by 5 cells # Mouse drag on pane border: Resize interactively # --- Pane arrangement --- # Ctrl+a -> {: Swap pane forward (up/left) # Ctrl+a -> }: Swap pane backward (down/right) # Ctrl+a -> Space: Cycle through layouts # --- Pane/window management --- # Ctrl+a -> !: Break current pane into a separate window # --- Window navigation --- # Ctrl+a -> c: Create new window # Ctrl+a -> n: Next window # Ctrl+a -> p: Previous window # Ctrl+a -> 0-9: Jump to window by number # Ctrl+a -> w: List all windows/sessions (interactive tree) # --- Session navigation --- # Ctrl+a -> s: List sessions (interactive selection) # Ctrl+a -> (: Previous session # Ctrl+a -> ): Next session # --- Cross-session window management (via command mode: Ctrl+a -> :) --- # move-window -t session_name: Move current window to another session # link-window -s session_name:N Share a window across sessions (same window, multiple sessions) # unlink-window Remove shared window from current session</code></pre> カスタムキーバインドの解説</h2> プレフィックスの変更（Ctrl+a</code>）</h3> Screen と同じ Ctrl+a</code> をプレフィックスにしています。bind a send-prefix</code> で、Ctrl+a</code> → a</code> と押せば端末に素の Ctrl+a</code>（行頭移動など）を送れます。これも Screen と同じ挙動です。 ペイン分割（-</code> と |</code>）</h3> tmux のデフォルトでは "</code> で横分割、%</code> で縦分割ですが、少し覚えにくいと感じました。-</code>（横線）で横分割、|</code>（縦線）で縦分割にしています。 ペインの取り込みと送り出し（@</code> と S</code>）</h3> @</code> は別のウィンドウやセッションからペインを現在のウィンドウに取り込みます。S</code> は現在のペインを別のウィンドウやセッションに送ります。いずれもインタラクティブなツリー表示から選択できます。 なお、Screen では Ctrl+a</code> → S</code> は横分割（リージョン分割）です。この設定ではその機能を -</code> に移しているため、S</code> を「ペイン送り出し」に再割り当てしています。 全ペイン分離（Q</code>）</h3> Screen の Ctrl+a</code> → Q</code>（リージョン全解除）に近い操作です。現在のウィンドウにある全ペインをそれぞれ独立したウィンドウに分離します。「分割して作業した後、元の 1 ペイン 1 ウィンドウの状態に戻したい」という Screen 的な使い方ができます。 キーバインド一覧</h2> カスタム設定</h3> キー</th> 操作</th></tr></thead> Ctrl+a</code></td> プレフィックス（Screen と同じ）</td></tr> Ctrl+a</code> → a</code></td> 端末に素の Ctrl+a を送る</td></tr> Ctrl+a</code> → -</code></td> 横分割（上下）</td></tr> Ctrl+a</code> → |</code></td> 縦分割（左右）</td></tr> Ctrl+a</code> → @</code></td> 別ウィンドウ/セッションからペインを取り込む</td></tr> Ctrl+a</code> → S</code></td> 現在のペインを別ウィンドウ/セッションに送る</td></tr> Ctrl+a</code> → !</code></td> 現在のペインを独立ウィンドウにする（デフォルト）</td></tr> Ctrl+a</code> → Q</code></td> 全ペインを独立ウィンドウにバラす</td></tr> マウス</td> ペイン境界ドラッグでリサイズ、選択、スクロール</td></tr> </tbody></table> デフォルトキーバインド（よく使うもの）</h3> ペイン操作 キー</th> 操作</th></tr></thead> Ctrl+a</code> → 矢印キー</td> ペイン間移動</td></tr> Ctrl+a</code> → o</code></td> 次のペインに移動</td></tr> Ctrl+a</code> → q</code></td> ペイン番号表示（番号押下でジャンプ）</td></tr> Ctrl+a</code> → z</code></td> ペインのズーム切替（全画面）</td></tr> Ctrl+a</code> → Space</code></td> レイアウト順次切替</td></tr> </tbody></table> ウィンドウ操作 キー</th> 操作</th></tr></thead> Ctrl+a</code> → c</code></td> 新規ウィンドウ</td></tr> Ctrl+a</code> → n</code> / p</code></td> 次/前のウィンドウ</td></tr> Ctrl+a</code> → 0-9</code></td> ウィンドウ番号でジャンプ</td></tr> Ctrl+a</code> → w</code></td> ウィンドウ/セッション一覧（ツリー表示）</td></tr> </tbody></table> セッション操作 キー</th> 操作</th></tr></thead> Ctrl+a</code> → s</code></td> セッション一覧</td></tr> Ctrl+a</code> → (</code> / )</code></td> 前/次のセッション</td></tr> Ctrl+a</code> → d</code></td> デタッチ（セッションを残して切断）</td></tr> </tbody></table> デタッチとアタッチ</h3> ターミナルマルチプレクサの最も基本的な機能であるデタッチ/アタッチは、Screen と tmux でほぼ同じです。 操作</th> Screen</th> tmux</th></tr></thead> デタッチ</td> Ctrl+a</code> → d</code></td> Ctrl+a</code> → d</code></td></tr> セッション一覧</td> screen -ls</code></td> tmux ls</code></td></tr> アタッチ</td> screen -r</code></td> tmux attach</code> (tmux a</code>)</td></tr> 名前付きセッション作成</td> screen -S name</code></td> tmux new -s name</code></td></tr> 名前指定でアタッチ</td> screen -r name</code></td> tmux attach -t name</code></td></tr> </tbody></table> Screen ユーザーにとって最も馴染みのある操作なので、ここは移行のハードルが低いポイントです。 Screen との概念の対応</h2> Screen</th> tmux</th> 備考</th></tr></thead> リージョン</td> ペイン</td> tmux はペイン作成時にシェルが自動起動する</td></tr> ウィンドウ</td> ウィンドウ</td> ほぼ同じ概念</td></tr> （なし）</td> セッション</td> Screen にもセッション概念はあるが、tmux の方がセッション管理が強力</td></tr> Ctrl+a</code> → Q</code> (リージョン全解除)</td> Ctrl+a</code> → Q</code> (全ペイン分離、カスタム)</td> デフォルトの z</code>（ズーム）は一時的な全画面化でペインが残る。カスタム Q</code> で Screen に近い挙動を再現</td></tr> Ctrl+a</code> → S</code> (横分割)</td> Ctrl+a</code> → -</code> (カスタム)</td> デフォルトは "</code></td></tr> </tbody></table> tmux 固有の便利な機能として、link-window</code> で同じウィンドウを複数セッションから共有できます。これは Screen にはない機能です。 コピー＆ペーストと OS クリップボード連携</h2> tmux のコピーバッファと OS のクリップボードは、デフォルトでは連携していないようです。tmux 内でコピーしても OS 側に反映されません。また、mouse on</code> にしていると tmux がマウスイベントを横取りするため、右クリックメニューからのコピペも効きません。 OSC 52 による解決</h3> OSC 52 はターミナルのエスケープシーケンスを使ってクリップボードにアクセスする仕組みです。xclip などの外部ツールは不要で、SSH 越しでも動作します。 ターミナルエミュレータ側（Alacritty の例）: [terminal] osc52 = "CopyPaste"</code></pre> tmux 側（~/.tmux.conf</code>）: set -g set-clipboard on set -g mode-keys vi set -g history-limit 10000</code></pre> set-clipboard on</code> は tmux 3.2 以降ではデフォルトで有効ですが、明示しておくと意図が明確になります。mode-keys vi</code> はコピーモードのキー操作を vi 式にします（hjkl 移動、/</code> で検索など）。vi に馴染みがなければこの行を省略すれば emacs 式（デフォルト）のままで、OSC 52 によるクリップボード連携は同様に動作します。history-limit</code> はスクロールバックの行数です（デフォルトは 2000 行）。 これだけで tmux のコピーが OS クリップボードに反映されます。 コピー操作</h3> Ctrl+a</code> → [</code> — コピーモードに入る</li> Space</code> — 選択開始</li> Enter</code> — コピー（OS クリップボードにも入る）</li> 通常の Ctrl+v</code> や中クリックで貼り付け</li> </ol> tmux 内で貼り付ける場合は Ctrl+a</code> → ]</code> です。 Shift キーで tmux をバイパス</h3> Shift</code> を押しながら操作すると tmux をバイパスしてターミナルエミュレータ側の操作になります。 Shift</code> + ドラッグ: ターミナル側の選択</li> Shift</code> + 右クリック: ターミナルのコンテキストメニュー</li> Shift</code> + 中クリック / Shift+Ctrl+V</code>: 貼り付け</li> </ul> Screen との比較</h3> 操作</th> Screen</th> tmux (この設定)</th></tr></thead> コピーモード開始</td> Ctrl+a</code> → [</code></td> Ctrl+a</code> → [</code></td></tr> 選択開始</td> Enter</code></td> Space</code></td></tr> コピー</td> Enter</code></td> Enter</code></td></tr> 貼り付け</td> Ctrl+a</code> → ]</code></td> Ctrl+a</code> → ]</code></td></tr> OS クリップボード連携</td> なし</td> OSC 52 で自動連携</td></tr> </tbody></table> コピーモードの基本操作は Screen とほぼ同じです。大きな違いは OS クリップボードとの連携で、Screen にはこの機能がありませんでした。tmux + OSC 52 対応ターミナルの組み合わせでは、コピーした内容がそのまま OS のクリップボードに入るため、ブラウザや他のアプリケーションにそのまま貼り付けられます。 なお、OSC 52 対応はターミナルエミュレータに依存します。Alacritty、Ghostty、WezTerm、iTerm2、Windows Terminal などは対応していますが、xfce4-terminal は未対応です。 完全な ~/.tmux.conf</h2> 記事中で紹介した設定をまとめた完全版です。コピー＆ペーストしてそのまま使えます。 # ============================================= # Prefix key (same as GNU Screen) # ============================================= unbind C-b set -g prefix C-a bind a send-prefix # ============================================= # General settings # ============================================= set -g mouse on set -g set-clipboard on set -g mode-keys vi set -g history-limit 10000 # ============================================= # Custom keybindings # ============================================= # Pane splitting: - for horizontal, | for vertical bind - split-window -v bind | split-window -h # Pull a pane from another window/session (interactive) bind @ choose-tree "join-pane -s '%%'" # Send current pane to another window/session (interactive) bind S choose-tree "join-pane -t '%%'" # Break all panes into separate windows (like Screen's Ctrl+a -> Q) bind Q run-shell 'while [ $(tmux list-panes | wc -l) -gt 1 ]; do tmux break-pane -d; done' # ============================================= # Cheat sheet (default keybindings) # ============================================= # --- Pane navigation --- # Ctrl+a -> Arrow keys: Move between panes # Ctrl+a -> o: Move to next pane # Ctrl+a -> q: Display pane numbers (press number to jump) # Ctrl+a -> z: Toggle pane zoom (fullscreen) # --- Pane resizing --- # Ctrl+a -> Ctrl+Arrow keys: Resize pane by 1 cell # Ctrl+a -> Alt+Arrow keys: Resize pane by 5 cells # Mouse drag on pane border: Resize interactively # --- Pane arrangement --- # Ctrl+a -> {: Swap pane forward (up/left) # Ctrl+a -> }: Swap pane backward (down/right) # Ctrl+a -> Space: Cycle through layouts # --- Pane/window management --- # Ctrl+a -> !: Break current pane into a separate window # --- Window navigation --- # Ctrl+a -> c: Create new window # Ctrl+a -> n: Next window # Ctrl+a -> p: Previous window # Ctrl+a -> 0-9: Jump to window by number # Ctrl+a -> w: List all windows/sessions (interactive tree) # --- Session --- # Ctrl+a -> d: Detach from session # Ctrl+a -> s: List sessions (interactive selection) # Ctrl+a -> (: Previous session # Ctrl+a -> ): Next session # --- Cross-session window management (via command mode: Ctrl+a -> :) --- # move-window -t session_name: Move current window to another session # link-window -s session_name:N Share a window across sessions # unlink-window Remove shared window from current session # --- Copy mode --- # Ctrl+a -> [: Enter copy mode # Space: Start selection (vi mode) / Ctrl+Space (emacs mode) # Enter: Copy selection (also copies to OS clipboard via OSC 52) # Ctrl+a -> ]: Paste from tmux buffer</code></pre> まとめ</h2> Screen から tmux への移行で最も戸惑ったのは、ペイン分割まわりの操作体系の違いでした。Screen の「リージョンを分割・解除する」という考え方と、tmux の「ペインを作る・ズームする」という考え方はアプローチが異なります。 今回のカスタマイズでは、プレフィックスの変更に加えて、Q</code>（全ペイン分離）や @</code>/S</code>（ペインの取り込み・送り出し）を追加することで、Screen 的なワークフローを tmux 上で再現できるようにしました。 移行のきっかけは Claude Code の表示崩れという消極的な理由でしたが、使ってみると tmux のセッション管理やペインの柔軟さは Screen より優れていると感じます。OSC 52 によるクリップボード連携など、tmux ならではの利点もあり、長年の慣れを差し引いても移行してよかったと感じています。Screen に慣れている方は、まずプレフィックスを Ctrl+a</code> に変えるだけでも移行のハードルはかなり下がると思います。 Blogspot の記事を Zola + GitHub Pages に移行した 2026-02-24T00:00:00+00:00 2008 年から書いてきた Blogspot の 107 記事を、Zola + GitHub Pages に一括移行した記録です。 はじめに</h2> 個人ブログを Google Blogspot から GitHub Pages に移行しました。 前回の記事</a>ではコーポレートサイト（ccmp.jp）の GCP → GitHub Pages 移行を紹介しましたが、今回はその続きとして、個人ブログ（ktaka.blog.ccmp.jp）の Blogspot → GitHub Pages 移行についてまとめます。 移行の全体像は次の通りです: GitHub Pages の立ち上げ — pandoc + GitHub Actions でまず公開</li> Zola 導入 — 静的サイトジェネレーターに切り替え</li> Blogspot 全記事の移行 — 107 記事を一括変換</li> ドメイン切替 — Blogspot と同じドメインで GitHub Pages を公開</li> </ol> 移行の背景</h2> Blogspot は手軽にブログを始められるサービスですが、技術ブログとして使い続けるにはいくつかの不満がありました。 Markdown で書けない: HTML エディタが基本で、シンタックスハイライトもない</li> 変更履歴が残らない: Git のような差分確認やロールバックができない</li> カスタマイズが面倒: テンプレートの自由度が低く、何か変えたいときに Blogger の作法を毎回調べ直す必要がある</li> </ul> そして何より、ブログを書こうと思っても、Blogger のエディタを開いて HTML を調整する作業が億劫で、記事を書くモチベーションが上がらないことが一番の問題でした。 一方で、GitHub Pages + Zola なら: Markdown でそのまま入稿</li> シンタックスハイライト標準搭載</li> テンプレートを完全に自作可能</li> コンテンツを Git で管理（変更履歴・ロールバック）</li> ローカルプレビューが zola serve</code> 一発</li> </ul> Phase 1: GitHub Pages の立ち上げ</h2> まず、既存の Markdown 記事を GitHub Pages で公開するところから始めました。 pandoc + GitHub Actions 構成</h3> GitHub Actions ワークフロー（.github/workflows/pages.yml</code>）を作成し、pandoc で Markdown → HTML 変換 + GitHub Pages デプロイを自動化しました。DNS CNAME レコードとカスタムドメイン設定で kt.blog.ccmp.jp</code> として暫定公開しました。 この構成の課題</h3> 動くことは動きましたが、運用面で問題がありました: 記事追加ごとに YAML 手動編集: mkdir</code>、pandoc</code> コマンド、index 更新を毎回ワークフローに追加する必要がある</li> ローカルプレビューが手動: pandoc を手で実行してブラウザで開く</li> TOC 生成が外部ツール依存: gh-md-toc</code> を別途実行</li> シンタックスハイライトなし: pandoc のデフォルトでは対応していない</li> RSS/サイトマップなし: 手動構成では現実的でない</li> </ul> 記事が 10 本程度のうちは何とかなりますが、Blogspot の 100 本以上の記事を移行するには、この構成では限界がありました。 Phase 2: Zola 導入</h2> pandoc 手動構成の限界を解消するため、静的サイトジェネレーター Zola を導入しました。 Zola を選んだ理由</h3> 項目</th> pandoc 手動構成</th> Zola 導入後</th></tr></thead> 記事追加</td> YAML 手動編集</td> MD ファイル作成のみ（自動検出）</td></tr> ローカルプレビュー</td> pandoc 手動実行</td> zola serve</code>（ライブリロード）</td></tr> TOC</td> 外部ツール</td> 標準搭載</td></tr> シンタックスハイライト</td> なし</td> 標準搭載（syntect）</td></tr> RSS/Atom</td> なし</td> 自動生成</td></tr> 多言語</td> 手動リンク管理</td> 標準搭載（index.en.md</code> で自動認識）</td></tr> </tbody></table> Zola は Rust 製の単一バイナリで、依存関係なしでインストールできます。Hugo や Jekyll と比べてエコシステムは小さいですが、必要な機能は揃っていました。 検証項目</h3> 導入前に以下を検証し、全項目をクリアしました: 検証項目</th> 結果</th></tr></thead> ビルド・ローカルプレビュー</td> OK（zola serve</code> でライブリロード対応）</td></tr> URL パス保持</td> OK（path</code> front matter で任意のパスを指定可能）</td></tr> 多言語対応</td> OK（index.en.md</code> で自動認識）</td></tr> 画像・動画の扱い</td> OK（content/</code> 内に同居、相対パス参照）</td></tr> シンタックスハイライト</td> OK（github-dark テーマ）</td></tr> Atom フィード</td> OK（自動生成）</td></tr> </tbody></table> テンプレート自作</h3> 既存のテーマは使わず、4 種のテンプレートを自作しました: base.html — 共通レイアウト（ナビゲーション、CSS）</li> index.html — トップページ（セクション一覧へリダイレクト）</li> section.html — 記事一覧（日付降順）</li> page.html — 記事本文（TOC、前後ナビ、ライトボックス）</li> </ul> CSS は github-markdown.css</code> をベースにしており、最小限のスタイルで十分な表示品質を実現しています。 移行の実施</h3> 既存の 11 記事を Zola 形式に変換（TOML front matter 追加、手動 TOC 削除）</li> GitHub Actions を pandoc → zola build</code> に更新</li> 旧ファイル（gh-md-toc</code>、ルート CSS、pandoc ワークフロー）を削除</li> </ul> Phase 3: Blogspot 全記事の移行</h2> Zola の基盤が整ったところで、Blogspot の全記事を移行しました。 エクスポートと変換</h3> Blogspot の記事データは Google Takeout でエクスポートしました。Blogger の管理画面からの XML エクスポートではなく、Google Takeout を使ったのは、HTML 形式で各記事が個別ファイルとして取得できるためです。 変換は Python スクリプトで自動化しました: Google Takeout (HTML) → Python スクリプト → Zola 用 Markdown + 画像</code></pre> スクリプトが行う処理: HTML ファイルの解析</li> TOML front matter の自動生成（title, date, path）</li> HTML → Markdown 変換</li> 画像ファイルのローカルコピーとパス書き換え</li> content/{year}/{slug}/index.md</code> として出力</li> </ol> 配置構造</h3> content/ 2008/ first-post/ index.md # 記事本文（Markdown + TOML front matter） image/ # 画像 photo.jpg second-post/ index.md 2009/ ... 2024/ ...</code></pre> 107 記事（うち 1 記事は draft = true</code>）を年別ディレクトリに配置しました。 品質検証</h3> 自動変換した記事の品質を確認するため、Claude Code を使って全 104 記事（draft 除く）を本番 Blogspot サイトと 1 記事ずつ比較しました。各記事について WebFetch で本番ページを取得し、ローカルの Markdown と突き合わせる作業を並列エージェントで実行しています。 結果: 100 記事: 問題なし</li> 4 記事を修正:</li> </ul> 記事</th> 問題</th> 対応</th></tr></thead> 2011/blog-post</code></td> 画像 2 枚が未取得</td> Blogger CDN からダウンロード（WebP）</td></tr> 2011/hhkb-pro2</code></td> 画像 1 枚が未取得</td> Blogger CDN からダウンロード（WebP）</td></tr> 2011/galaxy-blogger</code></td> 画像 1 枚が消失</td> Blogger CDN から消失、復元不可</td></tr> 2011/gnu-tar124ok</code></td> 変換アーティファクト</td> 空 blockquote・空コードブロックを除去</td></tr> </tbody></table> Blogger CDN から消失していた画像が 1 枚ありましたが、それ以外は全記事を正常に移行できました。 Phase 4: ドメイン切替</h2> コンテンツ移行の完了後、ドメインを切り替えました。 Blogspot で使っていたドメイン ktaka.blog.ccmp.jp</code> を、そのまま GitHub Pages に向け替えました: Blogspot 管理画面でカスタムドメイン（ktaka.blog.ccmp.jp</code>）を解除</li> DNS CNAME を ktaka-ccmp.github.io</code> に変更</li> GitHub Pages のカスタムドメイン設定を更新</li> Zola の config.toml</code>（base_url</code>）と static/CNAME</code> を更新</li> </ol> 暫定ドメイン kt.blog.ccmp.jp</code> は廃止しました。 まとめ</h2> 項目</th> 移行前（Blogspot）</th> 移行後（Zola + GitHub Pages）</th></tr></thead> 入稿形式</td> HTML エディタ</td> Markdown</td></tr> シンタックスハイライト</td> なし</td> あり（github-dark）</td></tr> プレビュー</td> Blogger のプレビュー機能</td> zola serve</code>（ローカルでライブリロード）</td></tr> バージョン管理</td> なし</td> Git</td></tr> 画像ホスト</td> Blogger CDN</td> リポジトリ内（Git 管理）</td></tr> カスタマイズ</td> テンプレート制約あり</td> 完全自作テンプレート</td></tr> RSS/Atom</td> Blogger 独自形式</td> Zola 自動生成</td></tr> ホスティングコスト</td> $0</td> $0</td></tr> </tbody></table> 大方の移行作業は 2 日間で完了しました。最も時間がかかったのは Blogspot 全記事の品質検証（104 記事の 1 対 1 比較）ですが、これは Claude Code の並列エージェントに任せたので、待ち時間が大半でした。 今まではブログを書こうと思っても、Blogger のエディタを開いて HTML を調整する作業が面倒で、かなり億劫に感じていました。Markdown なら文章を書くことに集中でき、それがそのままブログに変換されて CDN 配信されるので、記事を書くハードルがかなり下がりました。 9年前に Joomla + wget で静的化したサイトを GitHub Pages へ移行した 2026-02-15T00:00:00+00:00 Joomla CMS + wget による静的サイト生成パイプラインが、ホスティング移行をシンプルにしてくれた事例です。 はじめに</h2> 自社のコーポレートサイト（ccmp.jp）を、GCP 上の VM + Cloud Load Balancer + Cloud CDN 構成から GitHub Pages に移行しました。 もともと GitHub の有料プラン（Team）でリポジトリを管理していたため、GitHub Pages への移行で GCP 側の月額約 $23 のホスティングコストをまるごと削減できました。 移行がスムーズにいった最大の要因は、もともと Joomla CMS で入稿しつつ、配信は静的 HTML で行う構成を採っていたことでした。ホスティング先が変わっても、入稿ワークフローには一切手を入れる必要がありませんでした。 移行の背景</h2> 現在の GCP 構成は 9 年前に構築したものです。当時としては、将来的な拡張性も考慮した妥当な設計でした。 一方で、この 9 年の間に状況は変わりました。 VM の OS アップデート対応が地味に負担</li> Terraform で再構築できるとはいえ、「本当に今も動くのか」という心理的な不安</li> 静的サイト配信の選択肢が大きく増えた</li> </ul> 実際の運用では動的機能を追加することはなく、静的配信のみが続いていました。「この規模のサイトに VM は本当に必要だろうか？」と考えるようになったのが、今回の移行のきっかけです。 なお、CMS として Joomla を使っているのは歴史的経緯によるものです。非エンジニアによる入稿を目的として 20 年近く継続利用してきました。9 年前にはすでに、CMS の本番公開をやめて wget</code> による静的化へ移行していました。この「入稿と配信の分離」が、今回のホスティング移行を容易にしてくれました。 移行前の構成: Joomla CMS + GCP</h2> CMS 入稿 → 静的 HTML 生成というアーキテクチャ</h3> コーポレートサイトのコンテンツは Joomla CMS で管理しています。ただし、Joomla を本番サーバで動かしているわけではありません。入稿から配信までの流れは次のようになっています: [Joomla CMS] → wget でクローリング → 静的 HTML 生成 → GitHub リポジトリに push ↓ 本番サーバで git pull → nginx 配信</code></pre> 入稿: ローカル環境の Joomla CMS で記事を作成・編集</li> 静的化: wget</code> で CMS の出力をクローリングし、静的 HTML ファイルとして localhost/</code> ディレクトリに出力</li> デプロイ: 生成した HTML を GitHub リポジトリにマージし、GCP VM 上で git pull</code> → nginx で配信</li> </ol> 本番環境には PHP も MySQL も不要で、純粋な静的ファイル配信のみでした。前段に Cloud Load Balancer と Cloud CDN を配置し、キャッシュによるレスポンス高速化と VM への負荷軽減を行っていました。 このアーキテクチャのメリット</h3> この「CMS で入稿、配信は静的 HTML」というアーキテクチャには、当初から以下のメリットがありました: 入稿者にやさしい: 記事の作成・編集は Joomla の WYSIWYG エディタで行えます。Markdown や HTML を直接書く必要がなく、非エンジニアでも入稿できます。 CMS の便利さを維持しつつ脆弱性を排除: Joomla や WordPress などの CMS は頻繁に脆弱性が報告され、攻撃の標的になりがちです。しかしこの構成では CMS はローカル環境でのみ動作し、本番には PHP も MySQL も存在しません。入稿者は CMS の WYSIWYG エディタやテンプレート機能をそのまま使えますが、攻撃者から見える本番環境は単なる静的ファイルだけです。CMS の利便性とセキュリティを両立できます。 ホスティングの自由度が高い: 配信するのは単なる静的ファイルなので、ホスティング先を自由に選べます。今回の GCP → GitHub Pages の移行でも、入稿フロー側は一切変更なしで済みました。 バージョン管理: 静的 HTML を GitHub リポジトリで管理しているため、変更履歴の追跡やロールバックが容易です。 そして、今回このメリットが最大限に活きました。移行作業はホスティング先の変更だけで完結し、コンテンツのワークフローには一切手を入れずに済みました。 移行先の検討: GitHub Pages vs Netlify</h2> 候補の選定基準</h3> 移行先の条件は以下の通りです: 追加コスト $0: 既存の GitHub プランで利用できる静的ホスティングサービス</li> カスタムドメイン対応: ccmp.jp（apex ドメイン）で運用</li> HTTPS 対応: TLS 証明書の自動発行・更新</li> IPv6 対応: apex ドメインでも IPv6 到達可能</li> 自社 NS 維持: DNS のネームサーバは変更しない</li> </ul> Cloudflare Pages は NS 移管が原則必要なため不採用としました。自社 NS では ccmp.jp 以外のドメインやサービスの DNS も管理しており、NS を Cloudflare に移管すると他のサービスへの影響が避けられません。GitHub Pages と Netlify の 2 候補でステージング検証を行いました。 ステージング検証</h3> それぞれサブドメインでステージング環境を構築し、実際の動作を検証しました。 GitHub Pages（stg-g.ccmp.jp）: GitHub Actions ワークフローで localhost/</code> を Pages にデプロイしました。CNAME と .nojekyll</code> はワークフロー内で動的生成する構成としています（コンテンツ生成時に rm -rf localhost/</code> されるため、ファイルを直接置けません）。全項目問題ありませんでした。 Netlify（stg-n.ccmp.jp）: 今回のリポジトリは GitHub Organization 所有のプライベートリポジトリですが、Netlify Free プランではこの種のリポジトリの Git 連携が不可です（Pro $19/月が必要）。GitHub Actions から netlify deploy --prod</code> で CLI デプロイする方式で回避しました。また、wget</code> が生成するファイル名に ?</code> や #</code> が含まれており Netlify が拒否するため、デプロイ前にクリーンアップが必要でした。 比較結果</h3> 項目</th> GitHub Pages</th> Netlify Free</th></tr></thead> 追加コスト</td> $0</td> $0</td></tr> apex ドメイン A レコード</td> 4 IP</td> 1 IP のみ</td></tr> apex ドメイン IPv6</td> OK（AAAA 4 IP）</td> NG（AAAA 非公開）</td></tr> Git 連携</td> ネイティブ</td> CLI 回避策が必要</td></tr> ファイル名制約</td> なし</td> ?</code> #</code> 不可</td></tr> </tbody></table> GitHub Pages を採用しました。決め手は apex ドメインでの IPv6 対応、ネイティブ Git 連携、ファイル名制約がない点です。なお、CDN については GitHub Pages も Fastly ベースとされる CDN を内蔵しており、Cloud CDN を別途構築する必要がなくなりました。 本番移行の実施</h2> ステージング検証で問題がないことを確認した翌日に本番移行を実施しました。ステージング検証から GCP 撤去完了まで、作業期間は 2 日間でした。 GitHub Actions ワークフローの CNAME をステージング用からプロダクション用（ccmp.jp</code>）に変更</li> GitHub の Settings → Pages → Custom domain を ccmp.jp</code> に設定（DNS 切替前に実施し、TLS 証明書の発行を最速化）</li> 自社 NS で ccmp.jp の A/AAAA レコードを GitHub Pages の IP に切替</li> www.ccmp.jp</code> の CNAME を追加（GitHub Pages が www → apex の自動リダイレクトを提供）</li> 動作確認: HTTPS、Clean URL、リダイレクト、IPv4/IPv6 すべて OK</li> </ol> TLS 証明書について: GitHub Pages は DNS が向いた時点で自動的に Let's Encrypt 証明書を発行します</li> 旧 GCP VM の証明書との衝突はありません（Let's Encrypt は同一ドメインに複数証明書を許可）</li> GCP 側の証明書は自然に期限切れになるだけで、手動対応は不要です</li> </ul> GCP インフラの撤去</h2> 本番移行の完了後、旧 GCP インフラ（VM、VPC、ロードバランサー、固定 IP、SSL 証明書など計 20 リソース以上）を Terraform で一括撤去しました。再構築が必要になった場合に備え、Terraform コードと手順書はリポジトリに残してあります。 まとめ</h2> 項目</th> 移行前（GCP）</th> 移行後（GitHub Pages）</th></tr></thead> GCP ホスティングコスト</td> 約 $23/月</td> $0（GitHub Pages に移行）</td></tr> TLS 証明書</td> 自前で自動化（certbot）</td> GitHub にお任せ</td></tr> IPv6</td> 対応</td> 対応</td></tr> デプロイ</td> git pull + nginx</td> GitHub Actions 自動デプロイ</td></tr> インフラ運用</td> VM・LB・CDN の管理が必要</td> 不要</td></tr> </tbody></table> 年間 $276 削減、管理対象リソース 20 → 0。 ※ GitHub Pages をプライベートリポジトリで利用するには GitHub Pro 以上のプランが必要です。今回は既に GitHub Team プランを利用していたため、追加コストなしで移行できました。パブリックリポジトリであれば Free プランでも利用でき、GitHub Actions の無料枠（月 2,000 分）の範囲内であれば完全に $0 で運用可能です。 9 年前の設計は、当時の最適解でした。そしてその設計が、9 年後の移行コストを最小化してくれました。 今回の移行で改めて実感したのは、入稿と配信を分離するアーキテクチャの強さです。Joomla CMS による入稿ワークフローは一切変更せず、ホスティング先だけを差し替えることで移行が完了しました。コンテンツ管理と配信基盤を疎結合にしておくことで、将来また別のホスティングサービスに移る場合でも同様にスムーズな移行ができます。 もし「CMS は使いたいけど静的ホスティングのメリットも享受したい」という状況であれば、CMS + wget による静的サイト生成パイプラインは検討に値するアプローチだと思います。 OAuth2 and OpenID Connect (OIDC) Flow Testing: A Comprehensive Analysis of Response Types and Modes 2025-07-07T00:00:00+00:00 When implementing OAuth2 authorization and OpenID Connect (OIDC) authentication, developers face numerous configuration choices that significantly impact both security and user experience. While the OAuth2 and OIDC specifications provide guidance, understanding how different combinations of response types and response modes behave in practice requires empirical testing. This post presents a systematic analysis of OAuth2/OIDC flows using Google’s implementation, revealing key insights about token delivery patterns, security implications, and practical recommendations for production deployments. The</h2> Challenge: Too Many Options, Too Little Clarity OAuth2 and OpenID Connect (OIDC) offer multiple response types and response modes that serve different purposes: OAuth2 Response Types: - code</code> - Authorization Code Grant (for access tokens) - token</code> - Implicit Grant (direct access tokens) OIDC Response Types: - id_token</code> - Identity tokens for authentication - code token</code>, code id_token</code>, token id_token</code>, code token id_token</code> - Hybrid flows Response Modes (both OAuth2/OIDC): - query</code>, fragment</code>, form_post</code> - Different delivery methods This creates a matrix of possibilities: 7 response types × 3 response modes × various scope combinations = 42+ different flow configurations to understand. Rather than rely on documentation alone, I built an automated testing framework to examine how these flows actually behave. Methodology:</h2> Automated OAuth2/OIDC Flow Testing I created a Python script that systematically tests all OAuth2/OIDC flow combinations: # Core testing parameters RESPONSE_TYPES = ['code', 'token', 'id_token', 'code token', 'code id_token', 'token id_token', 'code token id_token'] RESPONSE_MODES = ['query', 'fragment', 'form_post'] SCOPES = ['profile email', 'openid profile email']</code></pre> The testing framework: Generates authorization URLs for each OAuth2/OIDC combination </li> Opens browser windows for user authentication </li> Captures responses across query parameters, form data, and URL fragments </li> Performs token exchange when authorization codes are present (OAuth2 code flow) </li> Validates ID tokens when present (OIDC authentication) </li> Logs comprehensive results for analysis </li> </ul> This approach provided empirical data on how Google’s OAuth2/OIDC implementation handles each flow configuration. Key Findings: Response</h2> Behavior Patterns Pattern 1: Location</h3> Predictability The testing revealed consistent patterns in where tokens are delivered: Query/Fragment Modes: - Single code</code> responses → Query parameters - Any token-containing responses → URL fragments - Multiple tokens → Always delivered together Form Post Mode: - All responses → Form parameters (consistent delivery) Pattern 2: Token Grouping</h3> When multiple tokens are requested (response_type=code token id_token</code>), they are always delivered together in the same location. You never see mixed delivery like code in query parameters while tokens appear in fragments. Pattern 3: OIDC Scope</h3> Normalization Regardless of requested scope, Google’s OIDC implementation consistently: - Adds openid</code> scope to all responses (making them OIDC flows) - Expands scopes to include full URL versions - Maintains identical behavior for profile email</code> vs openid profile email</code> - Always includes identity information when ID tokens are requested Detailed Test Results</h2> The comprehensive testing revealed distinct patterns across all response mode and type combinations: Query Response Mode Results</h3> Response Type</th> Scope</th> Response Location</th> Returned Tokens</th> Token Exchange</th></tr></thead> code</td> profile email</td> query params</td> code</td> access_token, id_token</td></tr> code</td> openid profile email</td> query params</td> code</td> access_token, id_token</td></tr> token</td> both scopes</td> fragment</td> access_token</td> none</td></tr> id_token</td> both scopes</td> fragment</td> id_token</td> none</td></tr> code token</td> both scopes</td> fragment</td> code, access_token</td> access_token, id_token</td></tr> code id_token</td> both scopes</td> fragment</td> code, id_token</td> access_token, id_token</td></tr> token id_token</td> both scopes</td> fragment</td> access_token, id_token</td> none</td></tr> code token id_token</td> both scopes</td> fragment</td> code, access_token, id_token</td> access_token, id_token</td></tr> </tbody></table> Fragment Response Mode</h3> Results Response Type</th> Scope</th> Response Location</th> Returned Tokens</th> Token Exchange</th></tr></thead> code</td> both scopes</td> query params</td> code</td> access_token, id_token</td></tr> token</td> both scopes</td> fragment</td> access_token</td> none</td></tr> id_token</td> both scopes</td> fragment</td> id_token</td> none</td></tr> code token</td> both scopes</td> fragment</td> code, access_token</td> access_token, id_token</td></tr> code id_token</td> both scopes</td> fragment</td> code, id_token</td> access_token, id_token</td></tr> token id_token</td> both scopes</td> fragment</td> access_token, id_token</td> none</td></tr> code token id_token</td> both scopes</td> fragment</td> code, access_token, id_token</td> access_token, id_token</td></tr> </tbody></table> Form Post Response Mode</h3> Results Response Type</th> Scope</th> Response Location</th> Returned Tokens</th> Token Exchange</th></tr></thead> code</td> both scopes</td> form params</td> code</td> access_token, id_token</td></tr> token</td> both scopes</td> form params</td> access_token</td> none</td></tr> id_token</td> both scopes</td> form params</td> id_token</td> none</td></tr> code token</td> both scopes</td> form params</td> code, access_token</td> access_token, id_token</td></tr> code id_token</td> both scopes</td> form params</td> code, id_token</td> access_token, id_token</td></tr> token id_token</td> both scopes</td> form params</td> access_token, id_token</td> none</td></tr> code token id_token</td> both scopes</td> form params</td> code, access_token, id_token</td> access_token, id_token</td></tr> </tbody></table> Key Observations from</h3> Results OAuth2 Code Exchange Pattern: Any flow that includes “code” triggers a token exchange, always returning both access_token and id_token (full OIDC response) </li> OIDC Response Location Consistency: Code-only responses go to query_params in query/fragment modes, while any responses containing tokens or ID tokens are delivered via URL fragments (regardless of whether response_mode is query or fragment). Only form_post mode consistently delivers all response types via the specified method. </li> Scope Independence: No difference in behavior between “profile email” and “openid profile email” - OpenID scope is always included, making all flows OIDC-compliant </li> </ul> Security</h2> Analysis: Most and Least Recommended OAuth2/OIDC Flows 🏆 Most</h3> Recommended: Authorization Code Flow with Form Post Configuration: response_type=code</code>, response_mode=form_post</code> Why it’s secure: - No tokens in URLs or browser history - Credentials don’t appear in server logs - Backend token exchange enables client authentication (OAuth2) - Authorization code is short-lived and single-use - Full OIDC compliance with secure ID token delivery Implementation benefits: - Simple to implement and debug - Reliable across all browsers - No client-side token handling required - Works for both OAuth2 authorization and OIDC authentication ⚠️ Least</h3> Recommended: Implicit and OIDC Implicit Flows Configuration: response_type=token</code> or response_type=id_token</code> Security concerns: - Tokens/ID tokens exposed in URL fragments - No client authentication possible - Higher risk of token leakage - ID tokens may be logged in browser history (OIDC security risk) Functional limitations: - No refresh tokens available - Shorter token lifetimes required - Limited error handling capabilities - Deprecated in OAuth 2.1 draft Practical Recommendations</h2> For Web Applications</h3> // Recommended: Authorization Code with Form Post + PKCE const authUrl = `https://accounts.google.com/o/oauth2/v2/auth?` + `response_type=code&` + `response_mode=form_post&` + `client_id=${clientId}&` + `redirect_uri=${redirectUri}&` + `scope=openid profile email&` + `code_challenge=${codeChallenge}&` + `code_challenge_method=S256&` + `state=${state}`;</code></pre>For Single Page Applications</h3> (SPAs) // Recommended: Use Backend-for-Frontend (BFF) Pattern // SPA communicates with your BFF, BFF handles OAuth2/OIDC with provider // BFF uses the secure web application flow: const authUrl = `https://accounts.google.com/o/oauth2/v2/auth?` + `response_type=code&` + `response_mode=form_post&` + `client_id=${clientId}&` + `redirect_uri=${bffRedirectUri}&` + // Points to BFF, not SPA `scope=openid profile email&` + `code_challenge=${codeChallenge}&` + `code_challenge_method=S256&` + `state=${state}`; // Alternative: If BFF not feasible, Authorization Code + PKCE directly in SPA const spaAuthUrl = `https://accounts.google.com/o/oauth2/v2/auth?` + `response_type=code&` + `response_mode=fragment&` + `client_id=${clientId}&` + `redirect_uri=${redirectUri}&` + `scope=openid profile email&` + `code_challenge=${codeChallenge}&` + `code_challenge_method=S256&` + `state=${state}`;</code></pre> Note: For SPAs, the Backend-for-Frontend (BFF) pattern is the recommended approach where your backend acts as the OAuth2/OIDC Relying Party. The BFF can safely store client secrets, handle token exchange, and manage session state. This avoids browser-based security limitations and provides the most secure implementation. If BFF is not feasible, use Authorization Code + PKCE directly in the SPA, though this may require workarounds for provider-specific limitations like Google’s client secret requirement. Security Enhancements</h3> Regardless of chosen flow, implement these security measures: Always use PKCE for code-based flows (OAuth2/OIDC) </li> Implement state parameter for CSRF protection </li> Use nonce parameter for OIDC ID token replay protection </li> Validate redirect URIs strictly </li> Keep authorization codes short-lived (< 10 minutes) </li> Verify ID token signatures and claims (OIDC) </li> Validate token audiences and issuers </li> </ul> Response Mode Comparison</h2> Response Mode</th> Security</th> Reliability</th> Use Case</th></tr></thead> form_post</code></td> ✅ Highest</td> ✅ Excellent</td> Web applications</td></tr> fragment</code></td> ⚠️ Medium</td> ✅ Good</td> SPAs, mobile apps</td></tr> query</code></td> ❌ Lowest</td> ✅ Good</td> Legacy systems only</td></tr> </tbody></table> Testing Your Own</h2> OAuth2/OIDC Implementation The testing framework can be adapted for other OAuth2/OIDC providers: # Configuration for different providers PROVIDERS = { 'google': { 'auth_endpoint': 'https://accounts.google.com/o/oauth2/v2/auth', 'token_endpoint': 'https://oauth2.googleapis.com/token' }, 'microsoft': { 'auth_endpoint': 'https://login.microsoftonline.com/common/oauth2/v2.0/authorize', 'token_endpoint': 'https://login.microsoftonline.com/common/oauth2/v2.0/token' } }</code></pre>Conclusion</h2> This systematic analysis reveals that OAuth2/OIDC flow selection significantly impacts both security and implementation complexity. Key takeaways: Form Post mode provides the best security profile for both OAuth2 and OIDC flows </li> Authorization code flows remain the gold standard for secure authentication and authorization </li> Implicit flows should be avoided in favor of code-based alternatives (deprecated in OAuth 2.1) </li> OIDC scope normalization means most flows become OpenID Connect flows automatically </li> Consistent testing is essential for understanding provider-specific behavior </li> </ul> The OAuth2/OIDC landscape continues evolving, with new security enhancements like PKCE and PAR (Pushed Authorization Requests) becoming standard. However, the fundamental principles revealed through this testing remain relevant: prioritize security, minimize token exposure, understand the difference between OAuth2 authorization and OIDC authentication, and thoroughly test your chosen configuration. For production deployments, always combine empirical testing with security best practices to ensure robust authentication and authorization flows that protect both your application and your users. The complete testing framework and detailed results are available in the Gist page</a>. Feel free to adapt the testing methodology for your own OAuth2 implementations. Google OAuth2/OIDC and PKCE: Understanding Client Secret Requirements 2025-07-07T00:00:00+00:00 A systematic test of Google’s OAuth2 PKCE implementation and its implications for different application types. Key Finding: Google’s OAuth2 implementation requires client_secret</code> even when using PKCE for Web Application client types, contrary to RFC 7636 standard expectations. This post documents systematic testing that confirms this behavior and provides architectural guidance for developers. Background: PKCE and Public</h2> Clients PKCE (Proof Key for Code Exchange) was introduced in RFC 7636 to address security concerns with public clients—applications that cannot securely store credentials, such as mobile apps and single-page applications (SPAs). The standard OAuth2 flow requires a client_secret</code>, but PKCE provides an alternative mechanism: Generate a random code_verifier</code> </li> Create a code_challenge</code> by hashing the verifier </li> Send the challenge with the authorization request </li> Exchange the authorization code using the verifier </li> </ul> According to RFC 7636, this should eliminate the need for client_secret</code> in public clients. Testing Google’s</h2> Implementation I conducted a systematic test to understand how Google’s OAuth2 endpoints handle PKCE requests using a Web Application client type. Test Setup</h3> #!/bin/bash # Generate PKCE parameters code_verifier=$(openssl rand -base64 32 | tr -d "=+/" | cut -c1-43) code_challenge=$(echo -n $code_verifier | openssl dgst -sha256 -binary | openssl base64 | tr -d '\n' | tr '+' '-' | tr '/' '_' | tr -d '=') echo "=== PKCE Parameters ===" echo "code_verifier: $code_verifier" echo "code_challenge: $code_challenge" echo "" # OAuth2 settings client_id='[REDACTED_CLIENT_ID]' redirect_uri='https://oauth2.example.com/result' # Generate authorization URL auth_url="https://accounts.google.com/o/oauth2/v2/auth?redirect_uri=${redirect_uri}&response_type=code&client_id=${client_id}&scope=openid+email+profile&access_type=online&code_challenge=${code_challenge}&code_challenge_method=S256&response_mode=fragment" echo "=== Authorization URL ===" echo "$auth_url" echo "" echo "=== Token Exchange Command ===" echo "curl -X POST \\" echo " --data-urlencode \"code=\$CODE\" \\" echo " --data-urlencode \"client_id=$client_id\" \\" echo " --data-urlencode \"redirect_uri=$redirect_uri\" \\" echo " --data-urlencode \"code_verifier=$code_verifier\" \\" echo " -d 'grant_type=authorization_code' \\" echo " https://oauth2.googleapis.com/token"</code></pre>Test Results</h3> Authorization Request: ✅ Successful Google accepted the PKCE parameters (code_challenge</code> and code_challenge_method=S256</code>) and returned an authorization code. Token Exchange with PKCE only: ❌ Failed curl -X POST \ --data-urlencode "code=$CODE" \ --data-urlencode "client_id=[REDACTED_CLIENT_ID]" \ --data-urlencode "redirect_uri=https://oauth2.example.com/result" \ --data-urlencode "code_verifier=[REDACTED_VERIFIER]" \ -d 'grant_type=authorization_code' \ https://oauth2.googleapis.com/token</code></pre> Response: { "error": "invalid_request", "error_description": "client_secret is missing." }</code></pre>Community Confirmation</h2> This limitation has been documented by the developer community: Stack Overflow Evidence: - Google OAuth 2.0 Authorization Code (with PKCE) requires a client secret</a> - Multiple developers confirm this requirement - Is a Client Secret Required for Google OAuth 2.0 using the PKCE Authorization Flow?</a> - Discussion of Google’s non-standard implementation Google Cloud Community: - Authorization Code Flow without client secret</a> - A Google representative acknowledges: “Google’s Identity Platform as of today does not support public applications under the ‘Web Application’ profile. Flows always require a client_secret.” GitHub Issues: - OAuth 2.0 with PKCE still requires client secret</a> - Tool developers encounter this limitation Understanding the</h2> Implications For Server-Side Applications</h3> Recommendation: Use the traditional OAuth2 flow with client_secret</code> stored securely on your server. curl -X POST \ --data-urlencode "code=$code" \ --data-urlencode "client_id=$client_id" \ --data-urlencode "redirect_uri=$redirect_uri" \ -d "client_secret=$client_secret" \ -d 'grant_type=authorization_code' \ https://oauth2.googleapis.com/token</code></pre> This is the intended use case where client_secret</code> can be stored securely. For Single-Page Applications</h3> (SPAs) Recommendation: Limit authentication to id_token</code> only and handle API access through your backend. Critical Security Warning: Embedding a client_secret</code> in browser code exposes it to anyone with access to the client, which is fundamentally insecure. This is why the OAuth2 standard forbids it for public clients. For SPAs that cannot securely store client_secret</code>: 1. Use the implicit flow or authorization code flow to obtain only id_token</code> for user authentication 2. Send the id_token</code> to your backend for verification 3. Handle Google API calls from your backend using server-stored credentials This approach separates authentication (client-side) from API access (server-side). Note: As of this writing, Google’s official documentation still directs SPAs toward the implicit flow</a>, which has been deprecated in OAuth 2.1 due to security concerns. This inconsistency in guidance contributes to confusion around best practices. For Mobile and Desktop</h3> Applications Current Reality: Google’s implementation requires embedding client_secret</code> in the application code. Google’s documentation acknowledges this: “The process results in a client ID and, in some cases, a client secret, which you embed in the source code of your application. (In this context, the client secret is obviously not treated as a secret.)” While not ideal from a security perspective, this is Google’s intended approach for native applications. Technical Implementation</h2> Notes PKCE Parameter Generation</h3> Google requires base64url encoding for the code challenge: # Correct base64url encoding for Google code_challenge=$(echo -n $code_verifier | openssl dgst -sha256 -binary | openssl base64 | tr -d '\n' | tr '+' '-' | tr '/' '_' | tr -d '=')</code></pre>Test Configuration</h3> This testing used: - Web Application client type in Google Cloud Console - Scopes: openid email profile</code> - Standard OAuth2 endpoints (https://accounts.google.com/o/oauth2/v2/auth</code> and https://oauth2.googleapis.com/token</code>) - PKCE method S256 Different Client Types</h3> Google offers various OAuth2 client types that may have different behaviors: - Web Application: In our testing, always required client_secret</code> - Android/iOS: May have different requirements (needs further testing) - Desktop: Reported to require secret but treat as non-confidential - TV/Limited Input: Similar behavior to desktop (based on community reports) Summary: Standard vs Reality</h2> According to OAuth2/PKCE standards, public clients should be able to authenticate without embedding secrets. Here’s how Google’s implementation compares: Client Type</th> Standard PKCE (No Secret Needed)</th> Google’s Reality (Secret Required)</th> Security Impact</th></tr></thead> Server-side</td> ❌ No (secret required)</td> ❌ No (secret required)</td> ✅ Secure (secret stays on server)</td></tr> SPA (Browser)</td> ✅ Yes (recommended)</td> ❌ No (not supported)</td> ❌ Secret exposed to users</td></tr> Mobile/Desktop</td> ✅ Yes (recommended)</td> ❌ No (not supported)</td> ❌ Secret embedded in app</td></tr> </tbody></table> The Problem: Google requires secrets for all client types, forcing developers to embed credentials in publicly distributed code—exactly what PKCE was designed to prevent. Architectural</h2> Recommendations Hybrid Approach for SPAs</h3> Browser (SPA) → Authentication only (id_token) ↓ Backend Server → API calls with client_secret</code></pre>Mobile Applications</h3> If using Google OAuth2 with mobile apps, implement additional security measures: - Use certificate pinning - Implement runtime application self-protection (RASP) - Monitor for application tampering Server-Side Applications</h3> Standard OAuth2 flow with proper secret management: - Store client_secret</code> in secure configuration - Use environment variables or secret management systems - Rotate credentials regularly Community Feedback Welcome</h2> The findings in this post are based on testing with a specific client configuration (Web Application type) and may not represent all possible scenarios. Google’s OAuth2 implementation is complex, with different behaviors across client types, API versions, and configuration options. If you have different results or experiences, please share them: - Have you successfully used PKCE without client_secret with Google OAuth2? - Do different client types (Android, iOS, Desktop) behave differently? - Are there specific Google APIs or configurations that work as expected? - Have there been recent changes to Google’s implementation? This post aims to document one specific finding to help other developers, but the OAuth2 landscape is constantly evolving. Contradicting evidence or alternative approaches would be valuable additions to the community’s understanding. Conclusion</h2> Google’s OAuth2 implementation requires client_secret</code> even when using PKCE for Web Application client types, which differs from the RFC 7636 standard. This finding, supported by community reports, indicates a consistent pattern in Google’s implementation. Understanding this behavior helps in choosing appropriate architectural patterns: Server-side applications: Use standard OAuth2 with secure secret storage </li> SPAs: Limit to authentication-only flows, handle API access server-side </li> Mobile/Desktop: Accept the embedded secret limitation or use hybrid architectures </li> </ul> When implementing OAuth2 with Google, design your architecture around these observed constraints. While other client types may behave differently, the Web Application type consistently requires client secrets alongside PKCE. References</h2> RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients</a> </li> Google OAuth 2.0 Documentation</a> </li> Google OAuth 2.0 for Mobile & Desktop Apps</a> </li> Google OAuth 2.0 JavaScript Implicit Flow</a> </li> Manage OAuth Clients - Google Cloud Platform Console Help</a> </li> Stack Overflow: Google OAuth 2.0 Authorization Code (with PKCE) requires a client secret</a> </li> Google Cloud Community: Authorization Code Flow without client secret</a> </li> </ul> Implementing Passkeys Authentication in Rust with Axum 2025-01-17T00:00:00+00:00 Introduction</h1> As a developer learning web programming and authentication in Rust, I recently undertook the challenge of implementing WebAuthn Passkeys using the Axum web framework. In this post, I'll share my experience building a basic Passkey authentication system from scratch, without relying on full-featured WebAuthn library crates. To keep things concise, I’ve included simplified code snippets for key components. The full implementation is available in my GitHub repository</a>. </video> Understanding WebAuthn and</h1> Passkeys WebAuthn is a W3C standard for passwordless authentication that uses public-key cryptography. The private keys are stored securely on user devices while public keys remain on servers. WebAuthn supports both platform authenticators (like Windows Hello or Touch ID) and roaming authenticators (like security keys). Passkeys extend WebAuthn by adding seamless account recovery through cloud-synced credentials. They integrate with platform authenticators like Google Password Manager or Apple Keychain, enabling users to authenticate using biometrics or PINs across their devices. This implementation is built on the FIDO2 protocol, which standardizes the authentication flow and user interface. The WebAuthn Flow</h1> WebAuthn authentication involves two main phases: registration and authentication. Let's examine how each phase works and then implement them. Registration Flow</h2> During registration, the server first generates a cryptographic challenge and sends it to the client along with registration options. The client then requests its authenticator to create a new key pair and generate an attestation object containing the public key. This attestation object is sent back to the server, which verifies it and stores the public key for future authentication. The attestation object returned by the authenticator contains authenticator data (including the new public key) and an attestation statement that provides information about the authenticator itself. This allows the server to verify the authenticator's authenticity and securely obtain the user's public key. Authentication Flow</h2> The authentication process begins with the server generating a new challenge. The authenticator then signs this challenge using the user's private key, and the server verifies the signature using the stored public key. Client-Side Implementation</h1> The client-side implementation handles both registration and authentication flows using the WebAuthn browser APIs. Let's walk through each process step by step. Registration Implementation</h2> The registration process begins by requesting options from the server. This establishes the parameters for creating a new credential: const response = await fetch('/register/start', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(username) }); const options = await response.json();</code></pre> The server responds with registration options that specify how the credential should be created. Here are the key parameters: { "challenge": "base64url-encoded-random-bytes", "rp_id": "example.com", "user": { "id": "user-uuid", "name": "username" }, "authenticatorSelection": { "authenticatorAttachment": "platform", "residentKey": "required" } }</code></pre> The challenge is a one-time cryptographic value that prevents replay attacks. The rp_id binds the credential to our domain for phishing protection, while the user.id provides a stable identifier for the credential. The authenticatorSelection parameters determine how the credential will be stored and used. With these options, we can create the credential using the WebAuthn API: const credential = await navigator.credentials.create({ publicKey: { challenge: base64URLToBuffer(options.challenge), rp: { id: options.rp_id }, user: { id: base64URLToBuffer(options.user.id), name: options.user.name } } });</code></pre> This code triggers the authenticator to generate a new key pair. In principle, the private key never leaves the authenticator, while the public key is included in the response. We then send this response back to the server: await fetch('/register/finish', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ id: credential.id, rawId: bufferToBase64URL(credential.rawId), response: { attestationObject: bufferToBase64URL(credential.response.attestationObject), client_data_json: bufferToBase64URL(credential.response.clientDataJSON) }, user_handle: options.user.id }) });</code></pre> The server will verify this response and store the public key for future authentications. Authentication</h2> Implementation The authentication flow follows a similar pattern but focuses on proving possession of an existing credential. We start by requesting authentication options: const response = await fetch('/auth/start', { method: 'POST' }); const options = await response.json();</code></pre> The server provides a challenge and information about accepted credentials: { "challenge": "base64url-encoded-random-bytes", "rp_id": "example.com", // Sending "allow_credentials" is optional for discoverable credentials. "allow_credentials": [ { "type": "public-key", "id": "credential-id" } ] }</code></pre> Using these options, we ask the authenticator to sign the challenge with the private key: const assertion = await navigator.credentials.get({ publicKey: { challenge: base64URLToBuffer(options.challenge), rpId: options.rp_id, allowCredentials: options.allow_credentials.map(cred => ({ id: base64URLToBuffer(cred.id), type: cred.type })) } });</code></pre> The authenticator will prompt the user for consent (and potentially biometric verification) before signing. We then send the signed assertion to the server: await fetch('/auth/verify', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ id: assertion.id, response: { signature: bufferToBase64URL(credential.response.signature), authenticator_data: bufferToBase64URL(credential.response.authenticatorData), client_data_json: bufferToBase64URL(credential.response.clientDataJSON), user_handle: bufferToBase64URL(credential.response.userHandle) } }) });</code></pre>Server Implementation in</h1> Rust The server side of our WebAuthn implementation handles credential storage, challenge generation, and cryptographic verification. Our Axum-based implementation is organized into focused modules that handle different aspects of the authentication process: src/ ├── main.rs # Server setup and routing ├── passkey.rs # Module definitions └── passkey/ ├── attestation.rs # Attestation verification ├── auth.rs # Authentication handling └── register.rs # Registration handling</code></pre> The attestation module verifies new credentials during registration, the auth module handles login attempts, and the register module manages the credential creation process. State Management</h2> Before diving into the handlers, let's look at how we manage server-side state: #[derive(Clone)] pub(crate) struct AppState { store: ArcMutexAuthStore>>, config: AppConfig, }</code></pre> This structure provides thread-safe access to our storage and configuration. The AuthStore handles both temporary challenges and permanent credentials: #[derive(Default)] struct AuthStore { challenges: HashMapString, StoredChallenge>, credentials: HashMapString, StoredCredential>, }</code></pre> For a production environment, you'd replace these HashMaps with proper databases - perhaps Redis for challenges and PostgreSQL for credentials. Registration Handler</h2> Implementation The registration process consists of two main functions. The start_registration function creates a new user identity and challenge, preparing the server side for credential creation: async fn start_registration( State(state): StateAppState>, Json(username): JsonString>, ) -> JsonRegistrationOptions> { // Generate challenge and create user info let challenge = generate_challenge(); let user_info = PublicKeyCredentialUserEntity { id: Uuid::new_v4().to_string(), name: username.clone(), display_name: username.clone(), }; // Store challenge for verification let stored_challenge = StoredChallenge { challenge: challenge.clone(), user: user_info.clone(), timestamp: SystemTime::now()... }; let mut store = state.store.lock().await; store .challenges .insert(user_info.id.clone(), stored_challenge); // Return registration options Json(RegistrationOptions { challenge: URL_SAFE.encode(&challenge), rp_id: state.config.rp_id.clone(), // ...other options }) }</code></pre> The finish_registration function processes the authenticator's response, verifying the attestation and storing the new credential: async fn finish_registration( State(state): StateAppState>, Json(reg_data): JsonRegisterCredential>, ) -> Result'static str, (StatusCode, String)> { let mut store = state.store.lock().await; // Verify the challenge and client data verify_client_data(&state, &reg_data, &store).await?; // Extract the public key from attestation let public_key = extract_credential_public_key(&reg_data, &state)?; // Store credential with user info let credential_id = base64url_decode(&reg_data.raw_id)?; let stored_user = store.challenges.get(&reg_data.user_handle)?.user.clone(); store.credentials.insert( reg_data.raw_id.clone(), StoredCredential { credential_id, public_key, counter: 0, user: stored_user, }, ); // Remove used challenge store.challenges.remove(&reg_data.user_handle); Ok("Registration successful") }</code></pre> This function performs several critical security checks: Verifies that the client data matches expectations (challenge, origin, operation type) </li> Extracts and verifies the public key from the attestation object </li> Stores the credential with associated user information </li> Removes the used challenge to prevent replay attacks </li> </ul> Authentication Handler</h2> Implementation The authentication process also uses two main functions. The start_authentication function generates a new challenge for an authentication attempt: async fn start_authentication( State(state): StateAppState> ) -> JsonAuthenticationOptions> { // Generate new challenge let challenge = generate_challenge(); // Create auth ID for this session let auth_id = Uuid::new_v4().to_string(); // Store challenge for verification let stored_challenge = StoredChallenge { challenge: challenge.clone(), user: Default::default(), timestamp: SystemTime::now()... }; let mut store = state.store.lock().await; store.challenges.insert(auth_id.clone(), stored_challenge); // Return auth options Json(AuthenticationOptions { challenge: URL_SAFE.encode(&challenge), rp_id: state.config.rp_id.clone(), // ... other options }) }</code></pre> The verify_authentication function processes the authenticator's signed assertion, verifying the signature and associated data: async fn verify_authentication( State(state): StateAppState>, Json(auth_response): JsonAuthenticatorResponse>, ) -> Result'static str, (StatusCode, String)> { // Verify client data let client_data = ParsedClientData::from_base64(&auth_response.response.client_data_json)?; client_data.verify(&state, &stored_challenge.challenge)?; // Verify authenticator data let auth_data = AuthenticatorData::from_base64(&auth_response.response.authenticator_data)?; auth_data.verify(&state)?; // Verify signature let credential = store.credentials.get(&auth_response.id)?; let public_key = UnparsedPublicKey::new(verification_algorithm, &credential.public_key); public_key.verify(&signed_data, &signature)?; Ok("Authentication successful") }</code></pre> This function performs three main security checks: Verifies the client data (challenge, origin, operation type) </li> Validates the authenticator data (RP ID hash, user presence, verification status) </li> Verifies the signature using the stored public key </li> </ul> If these verifications are successful, a session can be created and the user is regarded as logged in. WebAuthn Data</h1> Structures and API Formats Having seen both the client and server implementations, it's important to understand how they communicate with each other. While the WebAuthn standard precisely defines how browsers interact with authenticators, it doesn't specify how WebAuthn data should be transmitted between clients and servers. This gives implementations flexibility in designing their API formats. Data Flow and</h2> Transformations The WebAuthn API deals with binary data in ArrayBuffer format, but this needs to be transformed for client-server communication: Our implementation makes several key design choices for data transport: Uses JSON format for easy parsing and debugging </li> Base64url-encodes binary data for safe transport in JSON </li> Renames fields to match language conventions (camelCase in JS, snake_case in Rust) </li> Omits optional fields to simplify the implementation </li> Makes some optional fields required where it helps our implementation </li> </ul> Registration Data Structures</h2> Standard WebAuthn Interfaces</h3> The browser's navigator.credentials.create()</code> accepts PublicKeyCredentialCreationOptions</code>: PublicKeyCredentialCreationOptions { challenge: BufferSource, // Random bytes to prevent replay attacks rp: { id: string, // Domain name for phishing protection name: string // Display name for the service }, user: { id: BufferSource, // Stable identifier for the user name: string, // Username (can change) displayName: string // User's full name or display name }, // Allowed public key parameters pubKeyCredParams: [{ type: "public-key", // Currently only "public-key" is supported alg: number // Cryptographic algorithm identifier }], // Optional authenticator preferences authenticatorSelection?: { authenticatorAttachment?: "platform" | "cross-platform", residentKey?: "required" | "preferred" | "discouraged", userVerification?: "required" | "preferred" | "discouraged" }, timeout?: number // Operation timeout in milliseconds }</code></pre> And returns AuthenticatorAttestationResponse</code>: AuthenticatorAttestationResponse { clientDataJSON: ArrayBuffer, // JSON containing challenge, origin, and type attestationObject: ArrayBuffer // CBOR-encoded attestation data }</code></pre>Our Implementation's API</h3> Format Our server's /register/start</code> endpoint returns: { "challenge": "base64url-encoded-random-bytes", "rp_id": "example.com", "user": { "id": "user-uuid", // String UUID for easier handling "name": "username" }, "authenticatorSelection": { "authenticatorAttachment": "platform", // Prefer platform authenticators "residentKey": "required" // Require discoverable credentials } }</code></pre> And our /register/finish</code> endpoint accepts: { "id": "credential-id", // Base64url credential identifier "rawId": "base64url-encoded-credential-id", "response": { "attestationObject": "base64url-encoded-attestation-object", "client_data_json": "base64url-encoded-client-data" }, "user_handle": "user-uuid" // Links credential to user account }</code></pre> Design choices for registration: Base64url-encode all binary data (challenge, credential ID, attestation object) </li> Use string UUID for user.id instead of binary format </li> Require platform authenticators and resident keys for better UX </li> Add explicit user_handle to maintain credential-user connection </li> Omit timeout and other optional fields for simplicity </li> </ul> Authentication Data</h2> Structures Standard WebAuthn</h3> Interfaces The browser's navigator.credentials.get()</code> accepts PublicKeyCredentialRequestOptions</code>: PublicKeyCredentialRequestOptions { challenge: BufferSource, // Random bytes to prevent replay attacks rpId?: string, // Optional domain name restriction allowCredentials?: [{ // Optional list of allowed credentials type: "public-key", id: BufferSource // Credential identifier }], // Optional user verification requirement userVerification?: "required" | "preferred" | "discouraged", timeout?: number // Operation timeout in milliseconds }</code></pre> And returns AuthenticatorAssertionResponse</code>: AuthenticatorAssertionResponse { clientDataJSON: ArrayBuffer, // JSON containing challenge, origin, and type authenticatorData: ArrayBuffer, // CBOR-encoded authenticator data signature: ArrayBuffer, // Cryptographic signature userHandle?: ArrayBuffer // Optional user identifier }</code></pre>Our Implementation's API</h3> Format Our server's /auth/start</code> endpoint returns: { "challenge": "base64url-encoded-random-bytes", "rp_id": "example.com", // Optional for discoverable credentials "allow_credentials": [ { "type": "public-key", "id": "credential-id" } ] }</code></pre> And our /auth/verify</code> endpoint accepts: { "id": "credential-id", "response": { "signature": "base64url-encoded-signature", "authenticator_data": "base64url-encoded-authenticator-data", "client_data_json": "base64url-encoded-client-data", "user_handle": "base64url-encoded-user-handle" } }</code></pre> Design choices for authentication: Base64url-encode all binary data for transport </li> Use snake_case in API for consistency with Rust </li> Make user_handle required to simplify user lookup </li> Support discoverable credentials by making allow_credentials optional </li> Omit timeout and user verification preferences for simplicity </li> </ul> The client-side JavaScript handles all necessary conversions between WebAuthn's ArrayBuffer format and our API's JSON format, using base64url encoding for binary data. This separation of concerns keeps our API clean while maintaining compatibility with the WebAuthn standard. What's Next</h1> While this basic implementation demonstrates the core concepts of WebAuthn Passkeys, several enhancements would make it production-ready: Session management</h2> In production session management using session cookie or "Authentication: bearer token" header. This will enable us to identify access from authenticated users. OAuth2/OIDC integration</h2> The system could integrate with OAuth2/OIDC providers like Google or Apple, enabling single sign-on and unified account management. This would allow users to seamlessly link their Passkey credentials with existing accounts. Storage</h2> The current in-memory storage would need to be replaced with proper databases - SQL for user credentials and Redis for temporary challenge states. This would provide the scalability and persistence needed for production use. Conclusion</h1> Building a WebAuthn Passkey implementation from scratch was an enlightening experience that provided deep insights into both modern authentication and Rust web development. The experience showed how standards like WebAuthn and tools like Rust can make secure authentication more accessible to developers, while still demanding careful attention to security considerations. While implementing core functionality from scratch proved to be an invaluable learning experience, production systems should rely on established, well-tested WebAuthn libraries that have undergone security audits. The insights gained from this exercise, however, will prove valuable when working with these production libraries, as understanding WebAuthn's internals helps make better architectural decisions. Resources</h1> WebAuthn Specification</a> </li> Official W3C standard </li> WebAuthn Guide</a> - A practical guide to implementing WebAuthn </li> Passkeys.dev</a> - Best practices for Passkey implementation </li> WebAuthn.io</a> - Interactive demo and debugging tool </li> </ul> Axum Google OAuth2/OIDC implementation 2024-12-05T00:00:00+00:00 Introduction</h2> Modern web applications often rely on OAuth2/OIDC for secure user authentication. As part of a recent exploration into Rust and Axum, I implemented a login system that integrates Google OAuth2. In this post, I’ll walk through the details of the implementation, covering both the theoretical aspects and practical steps involved in building a secure authentication system. To keep things concise, I’ve included simplified code snippets for key components. The full implementation is available in my GitHub repository</a>. </video> Overview</h2> What Are OAuth2 and OpenID</h3> Connect? OAuth2 and OpenID Connect (OIDC) are key to modern authentication systems, and understanding how they fit together can make implementing secure authentication easier. OAuth2 serves as a foundation, allowing users to grant applications access to their resources without sharing credentials. Applications interact with these resources through access tokens. For this implementation, I used the authorization code flow, a secure and widely adopted approach, to retrieve user information from the identity provider. OIDC builds on OAuth2, adding a standardized layer for authentication. While OAuth2 focuses on “what can this app access?”, OIDC answers “who is this user?” It introduces the ID token, a JSON Web Token (JWT) that contains verified user identity information. This makes it possible to authenticate users while managing access permissions in a single, unified flow. In a nutshell, OAuth2 becomes more secure when extended with the ID token under the OIDC standard. How Authentication Works:</h3> Key Concepts Basic Authentication Flow</h4> This implementation follows a well-defined sequence for authentication: The process begins when a user clicks the login button, which opens a popup and redirects to Google’s authentication page. After a successful login, Google returns an authorization code that the server exchanges for tokens. The server verifies ID token, creates a user session, and sets a session cookie in the response to the browser, completing the authentication flow. The user is subsequently identified by this cookie in all future requests. How Session Cookies Work</h4> Session cookies play a central role in maintaining authenticated access. Once the server sets a session cookie during login, it is automatically included in future browser requests. To ensure secure session management, I used several measures: HttpOnly flag: Prevents client-side script access to cookies. </li> Secure flag: Ensures cookies are only transmitted over HTTPS. </li> SameSite settings: Protects against CSRF attacks. </li> __Host-</code> prefix: Enforces HTTPS and host-specific restrictions. </li> </ul> These settings work together to maintain secure authentication states, even across multiple tabs. OAuth2 Parameters</h4> OAuth2 and OIDC define several parameters critical to the authentication process. Here’s how I approached configuring some of the key parameters: response_type</code>: Set to code</code>, as it securely delivers an authorization code. </li> response_mode</code>: Used form_post</code> for better security by avoiding sensitive data in URLs. </li> scope</code>: Requested openid</code>, email</code>, and profile</code> for user identity and basic information. </li> state</code>: Contains encoded security tokens (CSRF token, nonce ID, and PKCE ID) to prevent CSRF attacks and maintain session state. </li> code_challenge</code> and code_challenge_method</code>: Implements PKCE for secure code exchange. </li> nonce</code>: Uniquely identifies the authentication request and prevents replay attacks. </li> </ul> These parameters are essential for controlling the authentication flow and ensuring security. Implementation Details</h2> The following sections break down the implementation into key components, explaining how the OAuth2 authentication flow integrates with session management and security mechanisms. Authentication Flow</h3> Our implementation uses a popup window for authentication to keep the main page responsive. This approach: Handles the auth flow in a separate window </li> Maintains login state using shared cookies across the windows </li> Updates the main page automatically when complete </li> </ul> The flow coordinates between four components: browser, server, Google, and session store. The session store manages login sessions and security tokens (CSRF, nonce, PKCE verifier). This diagram captures the flow of data and interactions at each step. Route Structure</h3> The application defines routes to manage each step of the authentication and session flow: let app = Router::new() .route("/", get(index)) .route("/auth/google", get(google_auth)) .route("/auth/authorized", get(get_authorized).post(post_authorized)) .route("/popup_close", get(popup_close)) .route("/logout", get(logout)) .route("/protected", get(protected));</code></pre>Main Page Behavior</h3> The main page dynamically adjusts its content based on the user’s authentication status: async fn index(user: OptionUser>) -> impl IntoResponse { match user { Some(u) => { let message = format!("Hey {}! You're logged in!", u.name); let template = IndexTemplateUser { message: &message }; (StatusCode::OK, Html(template.render().unwrap())).into_response() } None => { let message = "You're not logged in.\nClick the Login button below.".to_string(); let template = IndexTemplateAnon { message: &message }; (StatusCode::OK, Html(template.render().unwrap())).into_response() } } }</code></pre> For authenticated users: Displays a personalized greeting. </li> For anonymous users: Displays a login button to trigger the popup-based authentication flow. </li> </ul> Initiating the OAuth2 Flow</h3> The /auth/google</code> endpoint initiates the OAuth2 flow: Generates security tokens (CSRF and nonce). </li> Stores these tokens in the session. </li> Redirects the browser to Google’s authentication page. </li> </ul> async fn google_auth( State(params): StateOAuth2Params>, State(store): StateMemoryStore>, headers: HeaderMap, ) -> Resultimpl IntoResponse, AppError> { // Generate and store security tokens let (csrf_token, csrf_id) = generate_store_token("csrf_session", expires_at, Some(user_agent), &store).await?; let (nonce_token, nonce_id) = generate_store_token("nonce_session", expires_at, None, &store).await?; let (pkce_token, pkce_id) = generate_store_token("pkce_session", expires_at, None, &store).await?; // Generate PKCE challenge let pkce_challenge = URL_SAFE_NO_PAD.encode( Sha256::digest(pkce_token.as_bytes()) ); // Combine tokens into a state parameter let encoded_state = encode_state(csrf_token, nonce_id, pkce_id); // Construct the Google OAuth2 URL with required parameters let auth_url = format!( "{}?{}&client_id={}&redirect_uri={}&state={}&nonce={}\ &code_challenge={}&code_challenge_method=S256", OAUTH2_AUTH_URL, // e.g., https://accounts.google.com/o/oauth2/v2/auth OAUTH2_QUERY_STRING, // e.g., response_type=code&scope=openid+email+profile... params.client_id, params.redirect_uri, encoded_state, nonce_token, pkce_challenge, ); // Set security cookie and prepare the redirect response let mut headers = HeaderMap::new(); header_set_cookie(&mut headers, CSRF_COOKIE_NAME, csrf_id, expires_at)?; Ok((headers, Redirect::to(&auth_url))) }</code></pre>State Parameter</h4> The state parameter combines: CSRF token: Protects against cross-site request forgery. </li> Nonce ID: Validates the ID token’s authenticity. </li> PKCE ID: Identifies the PKCE verifier of the request </li> Base64URL encoding: Embeds multiple parameters in a URL safe single parameter. </li> </ul> fn encode_state(csrf_token: String, nonce_id: String, pkce_id: String) -> String { let state_params = StateParams { csrf_token, nonce_id, pkce_id }; URL_SAFE.encode(serde_json::json!(state_params).to_string()) }</code></pre> Google preserves and returns this state parameter unchanged, enabling security validations in the callback. Handling OAuth2 Callback</h3> After the user authenticates with Google, the application must process the callback to complete the authentication process. This includes exchanging the authorization code for tokens and validating their authenticity. Google returns the user’s authentication data via the /auth/authorized</code> endpoint. This endpoint supports two modes: Form Post Mode(Recommended)</h4> Google returns the authorization code and state to the browser. A Google-provided javascript sends them to the endpoint as POST body. They are processed by: async fn post_authorized( State(state): StateAppState>, Form(form): FormAuthResponse>, ) -> Resultimpl IntoResponse, AppError> { validate_origin(&headers, &state.oauth2_params.auth_url).await?; authorized(&form, state).await }</code></pre>Query Mode</h4> Google returns a redirect response with the authorization code and state as URL query parameters. They are processed by: async fn get_authorized( Query(query): QueryAuthResponse>, State(state): StateAppState>, TypedHeader(cookies): TypedHeaderheaders::Cookie>, ) -> Resultimpl IntoResponse, AppError> { csrf_checks(cookies.clone(), &state.store, &query, headers).await?; authorized(&query, state).await }</code></pre> Both callback modes eventually process the authentication response through the authorized function. This function exchanges the code for tokens, verifies their authenticity, and establishes a user session. async fn authorized(auth_response: &AuthResponse, state: AppState) -> Resultimpl IntoResponse, AppError> { let (access_token, id_token) = exchange_code_for_token(...).await?; let user_data = user_from_verified_idtoken(id_token, &state, auth_response).await?; // Optional check for user data from userinfo endpoint let user_data_userinfo = fetch_user_data_from_google(access_token).await?; if user_data.id != user_data_userinfo.id { return Err(anyhow::anyhow!("ID mismatch").into()); } let session_id = create_and_store_session(user_data, ...).await?; Ok((set_cookie_header(session_id), Redirect::to("/popup_close"))) }</code></pre>Managing User Sessions</h3> Sessions ensure secure, consistent authentication across requests. Upon successful login, a session is created and securely stored: async fn create_and_store_session( user_data: User, store: &MemoryStore, expires_at: DateTimeUtc>, ) -> ResultString, AppError> { let mut session = Session::new(); session.insert("user", &user_data)?; session.set_expiry(expires_at); let session_id = store.store_session(session).await?; Ok(session_id) }</code></pre> To protect sensitive routes, the function arguments include user: User</code>. The User</code> extractor automatically verifies the session cookie and retrieves the user data for subsequent requests: // The "user: User" argument ensures access to authenticated user data. async fn protected(user: User) -> impl IntoResponse { format!("Welcome, {}!", user.name) } // The User extractor // Extract cookie from the request, and retrieve user data from the session store #[async_trait] implS> FromRequestPartsS> for User where MemoryStore: FromRefS>, S: Send + Sync, { async fn from_request_parts(parts: &mut Parts, state: &S) -> ResultSelf, Self::Rejection> { let store = MemoryStore::from_ref(state); let session_cookie = get_session_cookie(parts)?; let user = load_user_from_session(store, session_cookie).await?; Ok(user) } }</code></pre> Having covered the implementation details, let’s examine the security mechanisms that protect our authentication flow. Security Considerations</h2> Our authentication implementation relies on several security mechanisms working together. Since we use ID token claims for authentication, these mechanisms focus on protecting the authentication process and verifying token authenticity. Nonce Validation</h3> The nonce mechanism is crucial for verifying that the ID token we’ll use for authentication was issued specifically for this request. Nonce validation confirms the ID token’s authenticity by comparing two values: Nonce in the ID token: Embedded by Google in the signed token. </li> Nonce from the session store: Retrieved using the nonce_id</code> from the state parameter. </li> </ul> This prevents replay attacks and ensures the token is tied to the current authentication request. CSRF Protection</h3> Cross-Site Request Forgery (CSRF) protection ensures that authentication callbacks come from legitimate auth flows initiated by our application. Without it, malicious sites could trick authenticated users into unwanted auth requests. The security mechanism differs between response modes due to how browsers handle redirects versus direct POST requests: Query Mode Flow: This mode requires cookie-based CSRF validation because the callback comes as a browser redirect, which could originate from any site. The CSRF token ensures the request chain started with our application: Form Post Mode: In this mode, we can’t use CSRF cookie validation because: The callback comes as a cross-origin POST request from Google’s domain </li> Browser security blocks our __Host-CsrfId</code> cookie from being sent with such requests </li> </ul> Instead, we rely on two security measures: Nonce validation: Confirms the ID token was issued for our specific auth request </li> Origin validation: Ensures the POST request comes from Google’s domain </li> </ul> This combination ensures that only Google can respond to our original authentication request, preventing any malicious sites from initiating or hijacking the authentication flow. PKCE Validation</h3> PKCE (Proof Key for Code Exchange) is a security extension to OAuth 2.0 that protects authorization codes from being intercepted or injected. Unlike CSRF and nonce validation which protect the authentication flow, PKCE specifically secures the code exchange process. PKCE ensures that only the client that initiated the authentication flow can exchange the authorization code for tokens: The implementation generates a random verifier and creates a challenge using SHA-256: let (pkce_token, pkce_id) = generate_store_token("pkce_session", expires_at, None, &store).await?; let pkce_challenge = URL_SAFE_NO_PAD.encode(Sha256::digest(pkce_token.as_bytes()));</code></pre> When exchanging the code for tokens, we include the original verifier: async fn exchange_code_for_token( params: OAuth2Params, code: String, code_verifier: String, // Original PKCE verifier ) -> Result(String, String), AppError> { let response = reqwest::Client::new() .post(params.token_url) .form(&[ // Other parameters... ("code_verifier", code_verifier), ])</code></pre> This mechanism prevents: Authorization code interception </li> Code injection attempts </li> Replay attacks </li> Man-in-the-middle attacks during code exchange </li> </ul> Cookie Security</h3> All cookies use comprehensive security settings: "{name}={value}; SameSite=Lax; Secure; HttpOnly; Path=/; Max-Age={max_age}"</code></pre> HttpOnly:</code> Prevents JavaScript access to cookies. </li> Secure:</code> Ensures transmission occurs only over HTTPS. </li> SameSite=Lax:</code> Guards against CSRF while allowing same-origin navigation. </li> __Host-</code> prefix: Enforces HTTPS and host-specific restrictions. </li> </ul> These settings ensure cookies are protected from common attack vectors. Response Mode Security</h3> Form Post Mode (Recommended) Authorization code is included in the POST body, keeping it hidden from URLs and logs. </li> Security relies on origin validation and nonce verification . </li> The most secure option for production use. </li> </ul> Query Mode Authorization code is visible in the URL, making it easier to debug but more prone to exposure (e.g., logs, bookmarks). </li> Offers full CSRF protection but carries a higher risk of leakage in environments where URLs are recorded. </li> </ul> Authentication with</h3> Authorization Code Flow The authorization code flow (response_type=code</code>) offers key security advantages: Secure Token Exchange: Tokens are obtained through secure server-to-server communication </li> Security Best Practice: Recommended approach for production applications </li> </ul> ID Token Validation</h3> The ID token, a cryptographically signed JWT, provides secure authentication through its claims: aud</code>: Ensures token was issued for our application </li> iss</code>: Verifies Google as the token issuer </li> exp</code> and iat</code>: Prevent token reuse and replay attacks </li> nonce</code>: Binds token to our specific auth request </li> </ul> While Google’s userinfo endpoint provides similar data, we rely on ID token validation because: Claims are cryptographically secured by Google’s signature </li> Validation is faster than additional userinfo requests </li> Userinfo endpoint is better suited for fetching optional profile data </li> </ul> Conclusion</h2> In this implementation, I’ve walked through building a secure OAuth2/OIDC authentication system with Axum. While implementing auth can be complex, breaking it down into manageable components helped create a system that’s both secure and maintainable. The code demonstrates practical patterns that you might find useful in your own projects for: Token validation and CSRF protection </li> PKCE implementation for code exchange security </li> Comprehensive session management </li> </ul> I’ve posted the complete implementation on GitHub</a>. Take a look if you’re interested in the implementation details - I’m particularly curious about your thoughts on the security measures and session handling approach. If you spot any potential improvements or have questions about specific design choices, I’d love to hear your feedback! AxumでGoogle OAuth2/OIDC認証を実装する 2024-12-05T00:00:00+00:00 この記事はRust Advent Calendar 2024</a> シリーズ2の6日目の記事です。 はじめに</h2> RustとAxumを使って、Google OAuth2でのログイン機能を実装しました。OAuth2とOIDCを使った認証は現代のWebアプリケーションでは一般的な方法です。この記事では、安全な認証システムを作るために必要な基礎知識と、具体的な実装方法を説明します。 ソースコードはGitHubリポジトリ</a>で公開しています。記事中のコードは理解のために簡略化していますので、完全な実装はリポジトリをご覧ください。 (本稿は英語版</a>からの翻訳記事です。) </video> 概要</h2> OAuth2とOpenID Connectとは</h3> OAuth2とOpenID Connect（OIDC）は、現代のWebアプリケーションの認証を支える重要な技術です。 OAuth2は認証の基盤となる技術で、ユーザーが自分の認証情報を直接渡すことなく、アプリケーションに特定の機能へのアクセス権を与えることができます。アプリケーションはアクセストークン（access token）を使ってこれらの機能を利用します。この実装では、広く使われている安全な方法である認可コードフロー（authorization code flow）を使って、ユーザー情報を取得しています。 OpenID Connect（OIDC）は、OAuth2を拡張して標準的な認証の仕組みを追加したものです。OAuth2が「アプリケーションに何を許可するか」を扱うのに対し、OIDCは「このユーザーは誰か」を確認することを主な目的としています。OIDCでは、ユーザー情報をJSON Web Token（JWT）形式のIDトークン（ID token）として提供します。これにより、ユーザーの認証とアクセス権限の管理を一度に行えます。 つまり、OIDCを使うことで、OAuth2をより安全に使えるようになります。 認証の仕組み</h3> 基本的な認証フロー</h4> この実装での認証は、以下のような手順で行われます： 認証の流れを詳しく説明します： ユーザーがログインボタンを押すと、ポップアップウィンドウが開きます </li> ポップアップウィンドウがGoogleの認証ページに移動します </li> ユーザーがGoogleアカウントでログインし、アプリケーションへの権限を承認します </li> Googleが認可コード（authorization code）を返します </li> この認可コードを使って、サーバーがトークンを取得します </li> サーバーがIDトークンを検証し、ユーザーセッションを作成します </li> セッションCookieをブラウザに設定して認証を完了します </li> </ul> 以降、ユーザーはこのセッションCookieを使って認証済みユーザーとして識別されます。 セッションCookieの仕組み</h4> セッションCookieはユーザーの認証状態を維持するために使われます。ログイン時にサーバーが設定したCookieは、その後のすべてのリクエストに自動的に含まれます。セキュリティを確保するため、以下の設定を使用しています： HttpOnly: JavaScriptからCookieを読み取れないようにし、XSS攻撃から保護します </li> Secure: HTTPS接続でのみCookieを送信し、通信の安全性を確保します </li> SameSite: 同じサイトからのリクエストのみCookieを送信可能にし、CSRF攻撃を防ぎます </li> __Host-</code>プレフィックス: CookieをHTTPSと特定のホストに限定し、セキュリティを強化します </li> </ul> OAuth2の設定</h4> 認証プロセスでは、以下のパラメータを使用します： static OAUTH2_QUERY_STRING: &str = "response_type=code\ &scope=openid+email+profile\ &response_mode=form_post\ &access_type=online\ &prompt=consent";</code></pre> これらのパラメータの役割は： response_type=code</code>: 認可コードを使用した安全な認証方式を指定します </li> scope=openid email profile</code>: アプリケーションが必要とするユーザー情報の範囲を指定します </li> response_mode=form_post</code>: 認証情報をURLに露出せず、POSTリクエストで送信します </li> </ul> 実装の詳細</h2> ここからは、OAuth2認証フローの具体的な実装方法について説明します。認証フロー、セッション管理、セキュリティ機能がどのように連携しているかを見ていきましょう。 認証フローの実装</h3> この実装では、ユーザー体験を向上させるため、ポップアップウィンドウで認証を行います： メインページは操作可能なまま、別ウィンドウで認証処理を実行 </li> Cookieを使ってウィンドウ間で認証状態を共有 </li> 認証完了後、自動的にメインページを更新 </li> </ul> システムは以下の4つのコンポーネントで構成されています： ブラウザ: ユーザーインターフェースを提供 </li> サーバー: 認証フローを制御 </li> Google: 認証サービスを提供 </li> セッションストア: セッションとセキュリティトークンを管理 </li> </ul> アプリケーションの構造</h3> 認証フローの各段階を処理するため、以下のようなルート構造を実装しています： let app = Router::new() .route("/", get(index)) // メインページ .route("/auth/google", get(google_auth)) // Google認証の開始 .route("/auth/authorized", get(get_authorized).post(post_authorized)) // 認証後のコールバック .route("/popup_close", get(popup_close)) // ポップアップの終了 .route("/logout", get(logout)) // ログアウト .route("/protected", get(protected)); // 認証必須ページ</code></pre>メインページの実装</h3> メインページは、ユーザーの認証状態に応じて表示を切り替えます： async fn index(user: OptionUser>) -> impl IntoResponse { match user { // 認証済みの場合 Some(u) => { let message = format!("ようこそ、{}さん！", u.name); let template = IndexTemplateUser { message: &message }; (StatusCode::OK, Html(template.render().unwrap())).into_response() } // 未認証の場合 None => { let message = "ログインボタンをクリックしてください。"; let template = IndexTemplateAnon { message: &message }; (StatusCode::OK, Html(template.render().unwrap())).into_response() } } }</code></pre>認証フローの開始</h3> /auth/google</code>エンドポイントでは、以下の3つの処理を行います： セキュリティトークンの生成 </li> セッションへの保存 </li> Google認証ページへのリダイレクト </li> </ul> async fn google_auth( State(params): StateOAuth2Params>, State(store): StateMemoryStore>, headers: HeaderMap, ) -> Resultimpl IntoResponse, AppError> { // セキュリティトークンを生成 let (csrf_token, csrf_id) = generate_store_token( "csrf_session", expires_at, Some(user_agent) ); let (nonce_token, nonce_id) = generate_store_token( "nonce_session", expires_at, None ); // Google認証URLの生成 let encoded_state = encode_state(csrf_token, nonce_id); let auth_url = format!( "{}?{}&client_id={}&redirect_uri={}&state={}&nonce={}", OAUTH2_AUTH_URL, OAUTH2_QUERY_STRING, params.client_id, params.redirect_uri, encoded_state, nonce_token ); // CSRFトークンをCookieに設定してリダイレクト let mut headers = HeaderMap::new(); header_set_cookie(&mut headers, CSRF_COOKIE_NAME, csrf_id, expires_at)?; Ok((headers, Redirect::to(&auth_url))) }</code></pre>コールバック処理</h3> Googleからの認証データは、2つの方法で受け取ることができます： フォームポストモード（推奨）</h4> Google提供のJavaScriptがPOSTリクエストで認証データを送信します： async fn post_authorized( State(state): StateAppState>, Form(form): FormAuthResponse>, ) -> Resultimpl IntoResponse, AppError> { // リクエスト元の確認 validate_origin(&headers, &state.oauth2_params.auth_url).await?; // 認証データの処理 authorized(&form, state).await }</code></pre>クエリモード</h4> 認証データがURLパラメータとして送信されます： async fn get_authorized( Query(query): QueryAuthResponse>, State(state): StateAppState>, TypedHeader(cookies): TypedHeaderheaders::Cookie>, ) -> Resultimpl IntoResponse, AppError> { // CSRFトークンの検証 csrf_checks(cookies.clone(), &state.store, &query, headers).await?; // 認証データの処理 authorized(&query, state).await }</code></pre> どちらのモードでも、最終的にauthorized</code>関数で認証処理を完了します： async fn authorized( auth_response: &AuthResponse, state: AppState ) -> Resultimpl IntoResponse, AppError> { // 認可コードをトークンに交換 let (access_token, id_token) = exchange_code_for_token(...).await?; // IDトークンを検証してユーザー情報を取得 let user_data = user_from_verified_idtoken( id_token, &state, auth_response ).await?; // ユーザー情報の追加確認（オプション） let user_data_userinfo = fetch_user_data_from_google(access_token).await?; if user_data.id != user_data_userinfo.id { return Err(anyhow::anyhow!("IDが一致しません").into()); } // セッションの作成 let session_id = create_and_store_session(user_data, ...).await?; Ok(( set_cookie_header(session_id), Redirect::to("/popup_close") )) }</code></pre>セッション管理</h3> 認証後のユーザー情報は、セッションに保存して管理します： async fn create_and_store_session( user_data: User, store: &MemoryStore, expires_at: DateTimeUtc>, ) -> ResultString, AppError> { let mut session = Session::new(); session.insert("user", &user_data)?; // ユーザー情報を保存 session.set_expiry(expires_at); // セッション有効期限を設定 let session_id = store.store_session(session).await?; Ok(session_id) }</code></pre> 認証が必要なページは、User</code>エクストラクタを使って保護します： // 認証が必要なページの例 async fn protected(user: User) -> impl IntoResponse { format!("ようこそ、{}さん！", user.name) } // Userエクストラクタの実装 #[async_trait] implS> FromRequestPartsS> for User where MemoryStore: FromRefS>, S: Send + Sync, { async fn from_request_parts(parts: &mut Parts, state: &S) -> ResultSelf, Self::Rejection> { let store = MemoryStore::from_ref(state); let session_cookie = get_session_cookie(parts)?; let user = load_user_from_session(store, session_cookie).await?; Ok(user) } }</code></pre>セキュリティ対策の詳細</h2> この実装では、複数のセキュリティメカニズムを組み合わせて認証の安全性を確保しています。IDトークンを用いた認証では、これらのメカニズムが認証プロセスの保護とトークンの正当性の検証に重要な役割を果たします。 Nonceによる検証</h3> nonceメカニズムは、IDトークンが特定のリクエストのために発行されたものであることを検証するために重要です。 Nonce検証は以下の2つの値を比較することでIDトークンの真正性を確認します： IDトークン内のnonce: Googleによって署名されたトークンに埋め込まれます </li> セッションストアからのnonce: stateパラメータのnonce_id</code>を使用して取得します </li> </ul> これによりリプレイ攻撃を防ぎ、トークンが現在の認証リクエストに紐付けられていることを確認します。 CSRF保護</h3> クロスサイトリクエストフォージェリ（CSRF）保護は、認証コールバックが我々のアプリケーションから開始された正当な認証フローからのものであることを確保します。これがないと、悪意のあるサイトが認証済みユーザーを望まない認証リクエストに誘導する可能性があります。 セキュリティメカニズムは、ブラウザがリダイレクトと直接のPOSTリクエストをどのように扱うかの違いにより、レスポンスモードによって異なります： クエリモードフロー： このモードではCookieベースのCSRF検証が必要です。コールバックはブラウザのリダイレクトとして来るため、任意のサイトから発生する可能性があるためです。CSRFトークンは、リクエストチェーンが我々のアプリケーションから開始されたことを確認します： フォームポストモード： このモードではCSRF Cookie検証を使用できません。理由は： コールバックはGoogleのドメインからのクロスオリジンPOSTリクエストとして来る </li> ブラウザのセキュリティにより、そのようなリクエストで__Host-CsrfId</code> Cookieが送信されることがブロックされる </li> </ul> 代わりに、以下の2つのセキュリティ対策に依存します： Nonce検証： IDトークンが我々の特定の認証リクエストのために発行されたことを確認 </li> Origin検証： POSTリクエストがGoogleのドメインから来ることを確認 </li> </ul> この組み合わせにより、Googleのみが我々の元の認証リクエストに応答できることを確保し、悪意のあるサイトが認証フローを開始または乗っ取ることを防ぎます。 Cookieのセキュリティ</h3> すべてのCookieは包括的なセキュリティ設定を使用します： "{name}={value}; SameSite=Lax; Secure; HttpOnly; Path=/; Max-Age={max_age}"</code></pre> HttpOnly:</code> JavaScriptからのCookieへのアクセスを防止 </li> Secure:</code> HTTPS経由でのみ送信されることを確保 </li> SameSite=Lax:</code> 同一オリジンのナビゲーションを許可しながらCSRFを防止 </li> __Host-</code>プレフィックス: HTTPSとホスト固有の制限を強制 </li> </ul> これらの設定により、Cookieが一般的な攻撃ベクトルから保護されます。 レスポンスモードのセキュリティ</h3> フォームポストモード（推奨） 認可コードがPOSTボディに含まれ、URLやログから隠される </li> セキュリティはオリジン検証とnonce検証に依存 </li> 本番環境での使用に最も安全なオプション </li> </ul> クエリモード 認可コードがURLに表示され、デバッグは容易だが露出のリスクが高い（ログ、ブックマークなど） </li> 完全なCSRF保護を提供するが、URLが記録される環境では漏洩のリスクが高い </li> </ul> 認可コードフローによる認証</h3> 認可コードフロー（response_type=code</code>）は重要なセキュリティ上の利点を提供します： セキュアなトークン交換： トークンはセキュアなサーバー間通信を通じて取得 </li> セキュリティのベストプラクティス： 本番アプリケーションに推奨されるアプローチ </li> </ul> IDトークンの検証</h3> IDトークンは暗号的に署名されたJWTで、そのクレームを通じてセキュアな認証を提供します： aud</code>: トークンが我々のアプリケーションのために発行されたことを確認 </li> iss</code>: Googleをトークン発行者として検証 </li> exp</code>とiat</code>: トークンの再利用とリプレイ攻撃を防止 </li> nonce</code>: トークンを我々の特定の認証リクエストに紐付け </li> </ul> Googleのuserinfoエンドポイントでも同様のデータが提供されますが、IDトークン検証を採用する理由は： クレームがGoogleの署名により暗号的に保護されている </li> userinfoリクエストよりも検証が高速 </li> userinfoエンドポイントはオプションのプロフィールデータの取得に適している </li> </ul> おわりに</h2> 本記事では、Axumを用いたセキュアなOAuth2/OIDC認証システムの構築方法について説明しました。認証の実装は複雑になりがちですが、機能を管理可能なコンポーネントに分割することで、セキュアで保守性の高いシステムを実現することができました。この実装は、トークンの検証、CSRF保護、セッション管理といった実践的なパターンを示しており、ご自身のプロジェクトに応用できるでしょう。 完全な実装コードはGitHub</a>で公開しています。詳細に興味のある方はぜひご覧ください。特に、セキュリティ対策やセッション管理の設計に関するご意見をお聞かせいただければ幸いです。さらに改善の余地や特定の設計選択についての質問があれば、ぜひフィードバックをお寄せください！ Sign in with Google vs OpenID Connect: Understanding the difference 2024-10-28T00:00:00+00:00 Introduction</h1> Third-party authentication has become ubiquitous in modern web applications, allowing users to sign in using existing accounts from major providers. While OAuth 2.0 and OpenID Connect (OIDC) are the standard protocols for implementing such authentication, Google offers two distinct approaches - the standard OIDC implementation and Sign in with Google - whose relationship is often misunderstood. The similarity between Sign in with Google and OIDC’s implicit flow can be particularly misleading. Though they share some characteristics, such as direct ID token delivery, they are fundamentally different implementations with distinct capabilities and limitations. This confusion is understandable. Sign in with Google’s token delivery mechanism resembles OIDC’s implicit flow (response_type=id_token), leading developers to assume it’s simply a wrapper around OIDC. However, this surface-level similarity masks significant differences in protocol implementation, security models, and available features. Note on Documentation: Google’s own documentation</a> states that “Sign in with Google is based on OAuth 2.0”. However, the same documentation describes it as a proprietary SDK that “aims to offer an easier and more secure experience for developers than the standard OAuth and OpenID Connect protocols”. This mixed messaging has contributed to developer confusion. While Sign in with Google might be inspired by OAuth 2.0 concepts, its actual implementation is a proprietary protocol that diverges significantly from standard OAuth 2.0/OIDC flows. </blockquote> Technical Relationship</h1> The resemblance between Sign in with Google and OIDC is apparent when examining OIDC’s implicit flow configuration: response_type=id_token response_mode=query</code></pre> Both approaches deliver ID tokens directly to the frontend. However, this architectural similarity obscures fundamental differences in implementation, security considerations, and extensibility. While Sign in with Google provides a streamlined, Google-specific authentication solution, OIDC offers a comprehensive, standardized protocol with multiple flows and security options. Implementation Comparison</h1> Sign in with Google</h2> Sign in with Google provides a simplified implementation through its Identity Services API: // Simple initialization google.accounts.id.initialize({ client_id: 'YOUR_CLIENT_ID', callback: handleCredentialResponse, // for popup mode login_uri: 'YOUR_LOGIN_URI' // for redirect mode }); // Callback receives: { credential: "eyJhbGci..." // JWT ID token containing user information ... }</code></pre> The Google Sign in page (loaded either in a popup window or redirected main window) receives an ID token from /gsi/issue endpoint and then: In popup mode: passes it to the main window’s callback function via gsi_client.js In redirect mode: posts it to the specified login_uri Standard OIDC</h2> OIDC provides multiple implementation options, accommodating different security needs: // Implicit Flow (Similar to Sign in with Google) /authorize? response_type=id_token& response_mode=query& client_id=...& scope=openid profile& redirect_uri=...& nonce=... // Code Flow (More secure alternative) /authorize? response_type=code& client_id=...& scope=openid profile& redirect_uri=...& state=...& nonce=...</code></pre> The client (on the web browser) can receive an ID token or authorization code as parameters in the redirect URL. Authentication Flows</h1> The flow differences reveal the architectural distinctions between these approaches. Sign in with Google implements a flow similar to OIDC’s implicit flow. However, OIDC also provides the code flow, which offers enhanced security through backend token exchange. Sign in with Google Flow</h2> +-------------+ 1. Init Sign-in +----------------+ | Web App | ----------------> | | | (Browser) | | Google Auth | | |</code></pre> Sign in with Google implements a straightforward flow focused on ID token delivery. While this approach simplifies implementation, it comes with security considerations: Applications typically need to establish sessions with their backend servers, requiring the ID token to be transmitted from the frontend to the backend </li> ID tokens contain sensitive user information and are meant for authentication </li> ID tokens are not designed to be passed between different parties - they should ideally only flow from the authentication provider to the intended recipient </li> </ul> In contrast, authorization codes in OIDC’s code flow are specifically designed for such transmission through the frontend. OIDC Code Flow</h2> +-------------+ 1. Init Auth +----------------+ | Web App | ----------------> | | | (Browser) | | Google Auth | | | | | | Server | code + client_id | Google's | | | + client_secret | Token endpoint | | | | | | |</code></pre> The OIDC code flow demonstrates the protocol’s flexibility, offering enhanced security through backend token exchange and supporting additional features like refresh tokens. Implementation Distinctions</h1> The divergence between these approaches manifests in several key areas: Protocol Implementation</h2> Sign in with Google employs a proprietary implementation that, while similar to OIDC’s implicit flow, uses custom mechanisms and focuses solely on authentication. This specialization allows for a simpler developer experience but limits flexibility and provider portability. Standard OIDC, conversely, implements a complete authentication and authorization protocol. It supports multiple flows, token types, and security models, enabling developers to choose the most appropriate approach for their specific requirements. Security Considerations</h2> The security models reflect different priorities. Sign in with Google optimizes for simplicity, handling tokens in the frontend with a predetermined security model. OIDC provides more options, including the secure code flow that keeps sensitive tokens server-side and supports various security configurations. Feature Scope</h2> Sign in with Google’s focused approach provides efficient authentication but limits additional capabilities. OIDC’s comprehensive protocol supports various authentication and authorization scenarios, multiple token types, and standardized endpoints. Choosing the Right Approach</h1> The selection between Sign in with Google and OIDC should be guided by specific project requirements: Sign in with Google excels in scenarios requiring quick implementation of Google-specific authentication, particularly when additional OAuth features aren’t needed. Its simplified approach can accelerate development for straightforward authentication needs. Standard OIDC becomes essential when projects require provider flexibility, enhanced security options, or additional OAuth features. Its standardized approach supports long-term maintainability and compliance requirements, though at the cost of increased implementation complexity. Conclusion</h1> While Sign in with Google shares surface similarities with OIDC’s implicit flow, understanding their distinct implementations is crucial for informed architectural decisions. The resemblance in token delivery mechanisms can mask significant differences in protocol implementation, security models, and available features. Developers should consider carefully whether their projects benefit more from Sign in with Google’s streamlined, focused approach or OIDC’s comprehensive, standardized protocol. This decision impacts not only initial implementation but also long-term maintenance, security posture, and provider flexibility. Remember: The similarity between Sign in with Google and OIDC’s implicit flow can be misleading. While they share some characteristics, they are different implementations with distinct capabilities and limitations. Sign in with Google in HTMX+FastAPI 2024-02-02T00:00:00+00:00 TL;DR</h1> The “Sign in with Google” feature has been integrated into a sample HTMX+FastAPI web application. Either an HTML or JavaScript version of a code snippet from Google’s code generator is included in the HTML to display the button. The FastAPI backend has been configured to create a session from the JWT and set “Set-Cookie: session_id” in the header, enabling subsequent communications to maintain the login status through a session cookie. Thanks to HTMX functionality, the application page can dynamically fetch the navigation bar upon a change in login status, indicating whether the user is logged in. Introduction</h1> As an aspiring full-stack software developer, I’ve been teaching myself various front-end web technologies recently. These include React.js, Svelte, and other shiny new JavaScript frameworks, which can sometimes be overwhelming. I was considering settling on Svelte, thanks to its simplicity in state management, when I discovered a concept called Hypermedia as the Engine of Application State (HATEOAS) and a library named htmx.js. Initially, I didn’t quite grasp how it differed from other technologies. However, after creating several web pages for practice, I realized I didn’t need to switch into a dedicated front-end programming mode. I felt liberated from the struggle of forcing myself into the React mental model, which always seemed nonsensical to me. I often questioned, ‘Why must I change my mental model every time I create a small piece of a web page?’ With htmx.js, I can simply create a page, and when I need to change parts of it, I just fire an AJAX request using hx-get and swap the DOM elements with HTML fragments in the response. I understand that as a web application becomes more complex, there might be situations where more feature-rich technologies are necessary. But now, I’m no longer intimidated by the overwhelming ecosystems of each technology. Now, I wanted to explore how I could implement a login feature in a web application, specifically using the ‘Sign in with Google’ feature on a web page developed with HTMX and FastAPI. So, I did a bit of research and figured out how to do it. Noticing a lack of use cases on the web for this particular combination of technologies, I decided to share my findings. While integrating the ‘Sign in with Google’ button into an HTMX page isn’t much different from incorporating it into a standard HTML page, the following aspects seemed particularly noteworthy: How to display the status after a successful login or logout using HTMX. </li> The handling of the JWT after a successful login on Google’s side. </li> How to maintain a session via a cookie generated upon successful JWT verification, rather than solely relying on the JWT for session management. </li> </ul> These points are especially relevant for beginners like myself. What I Implemented</h1> The webpage I developed using FastAPI and HTMX is shown in the figure below. This page integrates a ‘Sign in with Google’ option, enhancing user experience and offering a secure login method. The process begins when a user clicks on the Google logo. A pop-up window appears, guiding them through the Google account selection and authentication process, which is then executed seamlessly in the background. After logging in, the webpage dynamically updates the navigation bar to include the user’s Google account icon. Additionally, menu elements like ‘Secret#1’ become accessible, revealing exclusive content with a single click. Logging out is just as intuitive. Clicking the ‘Exit’ icon signs the user out, reverting the navigation bar to its default state for anonymous visitors. The source code is available on my GitHub repo.</a> Anonymous User Page</h2> The figure below shows a screenshot of the anonymous user page, which will be explained in more detail. The page consists of a navigation bar and a content section. On the navigation bar, an anonymous user icon, menus including the ones to secret pages, and a Google Sign-in button are shown. In this example, the ‘Secret#1’ menu is disabled. The ‘Secret#2’ menu is not disabled; however, clicking it will return an access forbidden error. The section below the navigation bar is the content section showing the “Incremental hx-get demo” page, which is accessible by both anonymous and authenticated users. Authenticated User Page</h2> The figure below shows a screenshot of the authenticated user page, which also consists of a navigation bar and content section. Shown on the navigation bar are the user’s Google account icon, menus including the ones to secret pages, and a Sign-out button. When the user is authenticated, the menus to the secret pages are both accessible and return the contents. The section below the navigation bar is the content section showing the content of the ‘Secret#1’ page, which is accessible only by authenticated users. HTMX with FastAPI</h1> FastAPI can respond with an HTML page generated from a Jinja template. The following code specifies that when the FastAPI server receives a GET request to /spa</code>, it will respond with an HTML page generated from the Jinja template spa.j2</code>. router = APIRouter() templates = Jinja2Templates(directory='templates') @router.get("/spa", response_class=HTMLResponse) async def spa(request: Request): context = {"request": request} return templates.TemplateResponse("spa.j2", context)</code></pre> Shown below is what the template spa.j2</code> looks like. {% include 'head.j2' %} {# Header #} {# Content #}</code></pre> In the body section, there are two sub-sections: one is wrapped by <header></header></code>, and the other is wrapped by <div></div></code>. The section wrapped by <header></header></code> loads the navigation bar in a responsive manner. Within this section, we encounter unfamiliar attributes: hx-get, hx-target, hx-swap, and hx-trigger. These attributes are interpreted by the HTMX JavaScript library loaded in head.j2</code>. The meanings of the attributes are summarized as follows: Attribute</th> Description</th></tr></thead> hx-get</td> issues a GET request to the given URL</td></tr> hx-target</td> specifies an element for swapping</td></tr> hx-swap</td> specifies how content is swapped</td></tr> hx-trigger</td> specifies the event that triggers the request</td></tr> </tbody></table> In this case, the HTMX library will issue a GET request to the /auth/auth_navbar</code> endpoint upon this section’s first load and when the page receives a response with “HX-Trigger: LoginStatusChange” in the header for an HTMX AJAX request. The HTMX library will then replace the content inside the <div></code> section with id="auth_navbar"</code>. The <div></code> section just below the {# Content #}</code> is there to load the main contents of the page dynamically. It also has the same set of HTMX attributes summarized in the table above. In this case, the HTMX library will issue a GET request to the /htmx/content.top</code> endpoint only upon this section’s first load. The HTMX library will then replace the content inside the <div></code> section with id="content_section"</code>. To have the HTMX attribute properly interpreted, we need to add a <script></code> tag in the document head, like this: </code></pre> The document head is included from the file head.j2</code> in the same directory as: {% include 'head.j2' %}</code></pre> These examples illustrate the basic usage of HTMX and FastAPI with Jinja templating. Sign In</h1> Overview</h2> The figure below shows a schematic diagram depicting the flow of the authentication process. When a user clicks ‘Sign in with Google’, an authentication request is sent to Google. </li> Upon successful authentication, the user’s credentials are returned as a JSON Web Token (JWT) to the page. </li> JavaScript code on the page forwards the JWT to /auth/login</code>, an authentication endpoint prepared using FastAPI. </li> The JWT is then verified using a certificate fetched from Google. </li> A user corresponding to the JWT is created in the SQLite database, if one does not already exist. </li> A new session is also created and stored in the database. </li> FastAPI sends a response with a header containing the entry “Set-Cookie: session_id=xxxxxx.” </li> </ul> Thereafter, “Cookie: session_id=xxxxxx” is always set in subsequent communications, until the cookie expires or until the user explicitly hits the logout button on the web page. Frontend Auth</h2> Sign in with Google button</h3> To display a Sign in with Google</code> button, we need to use a JavaScript library provided by Google and place a code snippet somewhere in the HTML. To load the JavaScript library, add the following <script></code> tag in the document head: </code></pre> Inside the navigation bar, we place a code snippet to show the “Sign in with Google” button. This code snippet is available in two versions: JavaScript and HTML. Either version can be used. JavaScript Version</h4> script> google.accounts.id.initialize({ client_id: "{{ client_id }}", callback: onSignIn, ux_mode: "popup", }); google.accounts.id.renderButton(document.getElementById("signInDiv"), { theme: "outline", size: "large", shape: "circle", type: "icon", }); {# google.accounts.id.prompt(); #} script> div id="signInDiv">div></code></pre> The google.accounts.id.initialize</code> function defines the initialization and behavior of the sign-in process: The client_id</code> specifies the OAuth 2.0 Client ID</a>, which is necessary. </li> The callback</code> defines a JavaScript callback function for a successful sign-in on Google’s side. </li> The ux_mode</code> sets Google’s sign-in page mode, preferred to be ‘popup’ instead of ‘redirect’. </li> </ul> The google.accounts.id.renderButton</code> function defines the presentation style of the Sign in with Google button: The google.accounts.id.prompt</code> method displays the One Tap prompt (and is disabled in this particular case). HTML Version</h4> src="https://accounts.google.com/gsi/client" async> id="g_id_onload" data-client_id="{{ client_id }}", data-context="signin" data-ux_mode="popup" data-callback=onSignIn data-close_on_tap_outside="true" data-itp_support="true" data-auto_prompt="false" > class="g_id_signin" data-type="icon" data-shape="square" data-theme="outline" data-size="large" ></code></pre> The <div id="g_id_onload"></code> element initializes and configures the sign-in process: data-client_id="{{ client_id }}"</code> specifies the necessary OAuth 2.0 Client ID</a>. </li> data-ux_mode="popup"</code> sets the mode of Google’s sign-in page to ‘popup’ instead of the more intrusive ‘redirect’. </li> data-callback=onSignIn</code> specifies a JavaScript callback function for a successful sign-in on Google’s side. </li> Setting data-auto_prompt="false"</code> determines whether to display One Tap or not. </li> </ul> The <div id="g_id_sigin"></code> division defines the presentation style of the Sign in with Google button. The Callback Function</h3> Below is an implementation of the callback function to forward the JWT to the backend: script> function onSignIn(response) { htmx.ajax('POST', '{{ login_url }}', { values: { 'credential': response.credential }, swap: 'none' }) } script></code></pre> The onSignIn</code> function sends the JWT received from Google’s sign-in page to {{ login_url }}</code>, a backend endpoint designed to handle the received JWT. Backend Auth</h2> The backend endpoint receives the JWT, verifies it using Google’s public certificate, and then creates a session to maintain a logged-in status in subsequent communications. Here is the code snippet of the backend endpoint, which performs the following operations: VerifyToken</code>: Verifies the JWT. </li> GetOrCreateUser</code>: Creates the user in the database if they don’t already exist. </li> create_session</code>: Creates a session and stores it in a session database. </li> response.set_cookie</code>: Sets the session_id in the cookie. </li> Returns the response to the frontend. </li> </ul> @router.post("/login") async def login(request: Request, ds: Session = Depends(get_db), cs: Session = Depends(get_cache)): body = await request.body() jwt = dict(urllib.parse.parse_qsl(body.decode('utf-8'))).get('credential') idinfo = await VerifyToken(jwt) if not idinfo: print("Error: Failed to validate JWT token") return Response("Error: Failed to validate JWT token") user = await GetOrCreateUser(idinfo, ds) if not user: print("Error: Failed to GetOrCreateUser") return Response("Error: Failed to GetOrCreateUser for the JWT") session_id = create_session(user, cs) if not session_id: print("Error: Failed to create session for", user.name) return Response("Error: Failed to create session for"+user.name) max_age = 600 expires = datetime.now(timezone.utc) + timedelta(seconds=max_age) response = JSONResponse({"Authenticated_as": user.name}) response.set_cookie( key="session_id", value=session_id, httponly=True, samesite="lax", max_age=max_age, expires=expires, ) response.headers["HX-Trigger"] = "LoginStatusChange" return response</code></pre> Please note that there is a line setting “HX-Trigger: LoginStatusChange” in the response header. This triggers an hx-get to The VerifyToken function below verifies the JWT from the frontend using the Google OAuth2 Python library</a>. from google.oauth2 import id_token from google.auth.transport import requests async def VerifyToken(jwt: str): try: idinfo = id_token.verify_oauth2_token( jwt, requests.Request(), settings.google_oauth2_client_id) except ValueError: print("Error: Failed to validate JWT token with GOOGLE_OAUTH2_CLIENT_ID=" + settings.google_oauth2_client_id +".") return None print("idinfo: ", idinfo) return idinfo</code></pre>Sign Out</h1> Overview</h2> The figure below shows a schematic diagram depicting the flow of the sign out process. When a user clicks the ‘Sign-out’ button, an hx-get request is sent to /auth/logout, an endpoint prepared using FastAPI. </li> The session associated with the session_id is deleted in the database. </li> FastAPI sends a response with a header containing the entry Set-Cookie: session_id="", max_age=0</code>. </li> </ul> Thereafter, the browser unsets the session_id</code> in the Cookie header and will no longer send the session_id</code> cookie in subsequent requests. Frontend</h2> Here is a snippet of the Jinja template, which shows a logout button for authenticated users in the navigation bar. class="navbar-nav me-auto mb-2 mb-lg-0"> hx-get="{{logout_url}}" hx-trigger="click" hx-target="#content_section" hx-swap="innerHTML"> class="rounded-circle" src="{{icon_url}}" alt="logout" name="logout" style="width:2rem;height:2rem;border-radius:2rem"></code></pre> The {{ logout_url }}</code> and {{icon_url}}</code> will returned to the client browsers. Upon a click, the logout button fires an hx-get request to {{ logout_url }}</code>, which translates to /auth/logout</code>, an endpoint of the backend server. The attributes hx-target="#content_section"</code> and hx-swap="innerHTML"</code> will cause the HTMX libray to replace the content in inside the <div id="content_section"></div></code>. Backend</h2> The backend endpoint receives an AJAX get request, deletes the session associated with the session_id from the database, and instructs the browser to unset the ‘Cookie: session_id’. Here is the code snippet of the backend endpoint, which performs the following operations: delete_session</code>: delete the session from the session database. </li> response.delete_cookie</code>: Causes the browser to delete the session_id</code> cookie from the Cookie header by setting Set-Cookie: session_id="", max-age=0</code> in the response header(see explanation</a> and source code</a>). </li> </ul> @router.get("/logout", response_class=HTMLResponse) async def logout(request: Request, response: Response, hx_request: Optional[str] = Header(None), cs: Session = Depends(get_cache)): if not hx_request: raise HTTPException( status_code=status.HTTP_400_BAD_REQUEST, detail="Only HX request is allowed to this end point." ) req_session_id = request.cookies.get("session_id") # get session_id from cookie of request if req_session_id: delete_session(req_session_id, cs) response.delete_cookie("session_id") # delete key="session_id" from cookie of response context = {"request": request, "message": "User logged out"} response = templates.TemplateResponse("content.error.j2", context) response.headers["HX-Trigger"] = "LoginStatusChange" return response</code></pre> Please also note that there is a line setting “HX-Trigger: LoginStatusChange” in the response header as same as the case for /auth/login endpoint. This triggers an hx-get to Switch Navbar</h1> The following code snippet returns the partial HTML content to display the navigation bar. Depending on the existence of the valid session_id in the Cookie header, the code returns the different HTMLs. When there is a valid session_id in the Cookie header, it returns the HTML generated from a Jinja template auth_navbar.logout.j2</code> for authenticated users with the user’s Google account icon and logout button. When there isn’t a valid session_id in the Cookie header, it returns the HTML generated from a Jinja template auth_navbar.login.j2</code> for anonymous users with a “Sign in with Google” button. @router.get("/auth_navbar", response_class=HTMLResponse) async def auth_navbar(request: Request, hx_request: Optional[str] = Header(None), ds: Session = Depends(get_db), cs: Session = Depends(get_cache)): if not hx_request: raise HTTPException( status_code=status.HTTP_400_BAD_REQUEST, detail="Only HX request is allowed to this end point." ) # For authenticated users, return the menu.logout component. try: session_id = request.cookies.get("session_id") user = await get_current_user(session_id=session_id, cs=cs, ds=ds) logout_url = settings.origin_server + "/auth/logout" icon_url = settings.origin_server + "/img/logout.png" context = {"request": request, "session_id": session_id, "logout_url":logout_url, "icon_url": icon_url, "name": user.name, "picture": user.picture, "email": user.email} return templates.TemplateResponse("auth_navbar.logout.j2", context) except: print("User not logged-in.") # For unauthenticated users, return the menu.login component. client_id = settings.google_oauth2_client_id login_url = settings.origin_server + "/auth/login" icon_url = settings.origin_server + "/img/icon.png" context = {"request": request, "client_id": client_id, "login_url": login_url, "icon_url": icon_url} return templates.TemplateResponse("auth_navbar.login.j2", context)</code></pre> The settings.origin_server</code> and settings.google_oauth2_client_id</code> are defined else where in the code tree to provied necessary information from a .env</code> file. Protecting Routes</h1> Access to the secret pages is controlled through the auth.is_authenticated</code> dependency, as shown in the following code snippet. If the auth.is_authenticated</code> does not raise an exception, it allows access to the routes defined in htmx/htmx_secret.py</code>; otherwise, it disallows it. from htmx import htmx_secret app = FastAPI() app.include_router( htmx_secret.router, prefix="/htmx", tags=["htmx"], dependencies=[Depends(auth.is_authenticated)], )</code></pre> The auth.is_authenticated</code> is defined as the following: In the function get_current_user</code>, the user’s email is retrieved from the session database, and then the other information is retrieved from the user database. </li> The function is_authenticated</code> raises an HTTPException when there is no user information returned by the get_current_user</code> or the user.disabled</code> is true. </li> </ul> async def get_current_user(session_id: str, ds: Session = Depends(get_db), cs: Session = Depends(get_cache)): if not session_id: return None session = get_session_by_session_id(session_id, cs) if not session: return None user_dict = get_user_by_email(session["email"], ds) user=UserBase(**user_dict) return user @router.get("/is_authenticated") async def is_authenticated(session_id: Annotated[str | None, Cookie()] = None, ds: Session = Depends(get_db), cs: Session = Depends(get_cache)): user = await get_current_user(session_id=session_id, cs=cs, ds=ds) if not user: raise HTTPException( status_code=status.HTTP_401_UNAUTHORIZED, detail="NotAuthenticated" ) elif user.disabled: raise HTTPException( status_code=status.HTTP_403_FORBIDDEN, detail="Disabled user" ) else: print("Authenticated.") return JSONResponse({"message": "Authenticated"})</code></pre>Conclusion</h1> In this post, I’ve shared what I learned about integrating the Sign in with Google feature with an HTMX+FastAPI web application. The “Sign in with Google” button has been successfully integrated into a sample HTMX+FastAPI web application. We included either an HTML or JavaScript version of a code snippet from Google’s code generator in the HTML to display the button. The FastAPI backend has been configured to create a session from the JWT and set “Set-Cookie: session_id” in the header, allowing subsequent communications to maintain the login status through a session cookie. Thanks to HTMX functionality, the application page can dynamically update the navigation bar upon a change in login status, clearly indicating whether the user is logged in. Seeking Oppotunities</h1> I’m based in Japan and am seeking remote work opportunities overseas. I’m also open to on-site positions in North America, Australia, the EU, etc., if visa support is available. LinkedIn</a> Google OAuth2 in Svelte + FastAPI: Create a Session Cookie from JWT 2024-01-09T00:00:00+00:00 Introduction</h2> I have implemented Google Sign-In functionality in a sample website built using Svelte and FastAPI. There are various methods to authenticate users in the backend API server after a successful Google Sign In. One common approach is to send the JWT received from Google in the request header as Authorization: "Bearer: JWT",</code> and if the JWT is valid, authorization to access resources is granted. Another typical method involves issuing a JWT on the backend and using it for user authentication in the Authorization</code> header. However, using JWT directly for session management poses a challenge in immediate invalidation if the JWT is leaked. Reference: Stop using JWT for sessions</a> . Therefore, I implemented a method in which, following the receipt of the JWT from Google, FastAPI assigns a new session_id. This session_id is set in a cookie to maintain the session. The session information is managed in FastAPI’s session database, allowing administrators to invalidate sessions anytime. Additionally, by adding Secure and HttpOnly attributes to the cookies, interception during transmission and access from JavaScript are prevented, enabling the development of a more secure website. Note: I am self-taught in both Svelte and FastAPI, so I would appreciate any advice on improving anything. What I Implement</h2> With authentication implemented, unauthenticated access will redirect to the login page, where you can log in with a Google account. The Customer page can only be displayed after successful authentication. In FastAPI, the Swagger UI automatically generates a documentation page. Frontend implementation</h2> with Svelte I implemented the frontend JavaScript application using Svelte. It includes authentication functionality using Google OAuth2 and retrieves customer data from the backend to display in a table. Upon successful Google Sign-In, the obtained JWT is sent to the backend API server. The backend verifies the JWT, creates a user account, sets the session_id in a cookie, and returns a response. Thereafter, the session_id is always sent in the cookie to maintain a session. The code for this implementation is available in the following repository: frontend-svelte code</a></li> </ul> I will explain the key points of implementing the login functionality below. Routing</h3> We use svelete-routing</code> to set up routing as follows: /customer : Displays the Customer component. </li> /login : Displays the LoginPage component. </li> </ul> Sample code for App.svelte</code> is as follows: import { Router, Link, Route } from "svelte-routing"; import Top from "./components/Top.svelte"; import Customer from "./components/Customer.svelte"; import NoMatch from "./components/NoMatch.svelte"; import LoginPage from "./components/LoginPage.svelte"; export let url = ""; Top Customer</code></pre>Login Page</h3> We display Google’s Sign-In button and also use the OneTap interface. After signing in with Google, the callback function backendAuth</code> is called. backendAuth</code> sends the response obtained from Google Sign-In to http://localhost/api/login</code>. The response includes the JWT token. If the backend login is successful, it redirects to the previous page. If it fails, the error is handled and “navigated” back to the login page. Sample code for LoginPage.svelte</code> is as follows: import { onMount } from "svelte"; import { apiAxios } from "../lib/apiAxios"; import { useLocation, navigate } from "svelte-routing"; import { jwtDecode } from "jwt-decode"; let location = useLocation(); let origin = $location.state?.from; const backendAuth = (response) => { const data = JSON.stringify(response, null, 2); console.log("JWT fed to backendAuth:\n", data); apiAxios .post(`/api/login/`, data) .then((res) => { console.log("Navigate back to: ", origin); navigate(origin, { replace: true }); }) .catch((error) => { console.log("backendAuth failed. Redirecting to /login... "); }); }; const onLogin = backendAuth; onMount(() => { google.accounts.id.initialize({ /* global google */ client_id: import.meta.env.VITE_APP_GOOGLE_OAUTH2_CLIENT_ID, callback: (r) => onLogin(r), ux_mode: "popup", // ux_mode: "redirect", }); google.accounts.id.renderButton(document.getElementById("signInDiv"), { theme: "filled_blue", size: "large", shape: "circle", }); google.accounts.id.prompt(); }); Login page</code></pre>Setup of Axios Instance</h3> By setting withCredentials: true</code>, axios will send cookies. Axios’s interceptors are used for error handling. If 401 Unauthorized</code> or 403 Forbidden</code> are returned from the backend, it navigates to /login</code>. Sample code for apiAxios.js</code> is as follows: import axios from "axios"; import { navigate } from "svelte-routing"; export const apiAxios = axios.create({ baseURL: `${import.meta.env.VITE_APP_API_SERVER}`, withCredentials: true, }); apiAxios.interceptors.response.use( (response) => { return response; }, (error) => { if (error.response.status === 401 || error.response.status === 403) { console.log( "apiAxios failed. Redirecting to /login... from", location.pathname ); navigate("/login", { state: { from: location.pathname }, replace: true }); } return Promise.reject(error); } );</code></pre>LogoutButton Component</h3> This component displays a Logout button. On mount, it accesses the backend server to get information about the logged-in user. If there is no session_id in the cookie, meaning the user is not logged in, the attempt to get user information fails, and the user is redirected to the /login</code> page due to the error handling in apiAxios.interceptor</code>. import { onMount } from "svelte"; import { apiAxios } from "../lib/apiAxios.js"; let user; onMount(() => { console.log("Logout Component Mounted"); getUser(); }); const handleLogout = () => { user = null; apiAxios .get(`/api/logout/`) .then((res) => { console.log("backendLogout", res); getUser(); }) .catch((error) => console.log("Logout failed: ", error)); }; const getUser = () => { apiAxios .get(`/api/user/`) .then((res) => { user = res.data; console.log("getUser: user:", user); }) .catch((error) => console.log("getUser failed: ", error.response)); }; const onLogout = handleLogout; Authenticated as {user?.username}   Sign Out</code></pre>Customer Component</h3> This component retrieves data from the backend server and displays it in a table. Since the LogoutButton</code> component is placed on the page, if the user is not logged in, it redirects to the /login</code> page. import { onMount } from "svelte"; import { apiAxios } from "../lib/apiAxios"; import LogoutButton from "./LogoutButton.svelte"; let customers = []; let Loading = true; onMount(async () => { await new Promise((r) => setTimeout(r, 1000)); apiAxios .get(`/api/customer/`) .then((res) => (customers = res.data.results)) .catch((error) => console.log(error)) .finally(() => Loading = false); }); This is Customer. {#if Loading} Loading ... {:else} id name email {#each customers as cs} {cs.id} {cs.name} {cs.email} {/each} {/if}</code></pre>Backend implementation with</h2> FastAPI I implemented the backend API server using FastAPI. It verifies the JWT received from the frontend Javascript apps, creates a user account, issues a session_id, and registers it in the session database. The created session_id is set in a cookie and returned in the response. The backend API server creates a new user if a user corresponding to the JWT does not exist in the database. When a request to an endpoint that requires authentication is received, FastAPI checks the session_id set in the cookie against the session database and returns the requested data if valid session information exists. The code for this implementation is available in the following repository: backend-fastapi code</a></li> </ul> I will explain the key points of implementing the login functionality below. /api/login Endpoint</h3> The frontend app sends the JWT, and then the backend FastAPI app verifies it using Google’s public certificates. If verification is successful, the backend FastAPI app registers the user using the email address in the JWT as the username in the user database. The information of the newly created user and the session_id are registered in the session database, and the session_id is set in a cookie in the response. Sample code for auth/auth.py</code> is as follows: async def VerifyToken(jwt: str): try: idinfo = id_token.verify_oauth2_token( jwt, requests.Request(), settings.google_oauth2_client_id) except ValueError: print("Error: Failed to validate JWT token with GOOGLE_OAUTH2_CLIENT_ID=" + settings.google_oauth2_client_id +".") return None print("idinfo: ", idinfo) return idinfo @router.post("/login") async def login(request: Request, response: Response, ds: Session = Depends(get_db), cs: Session = Depends(get_cache)): body = await request.body() jwt = json.loads(body)["credential"] if jwt == None: return Response("Error: No JWT found") print("JWT token: " + jwt) idinfo = await VerifyToken(jwt) if not idinfo: print("Error: Failed to validate JWT token") return Response("Error: Failed to validate JWT token") user = await GetOrCreateUser(idinfo, ds) if user: user_dict = get_user_by_name(user.name, ds) if not user_dict: raise HTTPException(status_code=HTTP_500_INTERNAL_SERVER_ERROR, detail="Error: User not exist in User table in DB.") user = UserBase(**user_dict) session_id = create_session(user, cs) response.set_cookie( key="session_id", value=session_id, httponly=True, max_age=1800, expires=1800, ) else: return Response("Error: Auth failed") return {"Authenticated_as": user.name}</code></pre>Function to Determine Active</h3> Users In the get_current_user</code> function, FastAPI extracts the session_id from the cookie of the received request and considers the user logged in if it matches an entry in the session database. The get_current_active_user</code> checks whether the user is disabled, and the get_admin_user</code> checks whether the user has admin privileges. Sample code for auth/auth.py</code> is as follows: async def get_current_user(ds: Session = Depends(get_db), cs: Session = Depends(get_cache), session_id: str = Depends(oauth2_scheme)): if not session_id: return None session = get_session_by_session_id(session_id, cs) if not session: return None username = session["name"] user_dict = get_user_by_name(username, ds) user=UserBase(**user_dict) if not user: raise HTTPException( status_code=status.HTTP_401_UNAUTHORIZED, detail="Invalid authentication credentials", ) return user async def get_current_active_user(current_user: User = Depends(get_current_user)): if not current_user: raise HTTPException(status_code=HTTP_401_UNAUTHORIZED, detail="NotAuthenticated") if current_user.disabled: raise HTTPException(status_code=HTTP_403_FORBIDDEN, detail="Inactive user") return current_user async def get_admin_user(current_user: User = Depends(get_current_active_user)): print("CurrentUser: ", current_user) if not current_user.admin: raise HTTPException(status_code=HTTP_403_FORBIDDEN, detail="Admin Privilege Required") return current_user</code></pre>Protecting Various Endpoints</h3> The /api/user/</code> endpoint is accessible only to logged-in users due to Depends(get_current_active_user)</code>. Sample code for auth/auth.py</code> is as follows: @router.get("/user/") async def get_user(user: UserBase = Depends(get_current_active_user)): return {"username": user.name, "email": user.email,}</code></pre> Routes defined in customer/customer.py</code> are accessible only to authenticated users, and those in admin/user.py</code> are accessible only to Admin users. Sample code for main.py</code> is as follows: import admin.debug, admin.user, auth.auth, auth.debug import customer.customer app = FastAPI() app.include_router( customer.customer.router, prefix="/api", tags=["CustomerForAuthenticatedUser"], dependencies=[Depends(auth.auth.get_current_active_user)], ) app.include_router( admin.user.router, prefix="/api", tags=["AdminOnly"], dependencies=[Depends(auth.auth.get_admin_user)], )</code></pre>Conclusion</h2> I have implemented Google Sign-In functionality in a sample website built using Svelte and FastAPI. After receiving the JWT from Google, FastAPI issues a new session_id and maintains the session through cookies. The session information is managed in FastAPI’s Session database, allowing administrators to invalidate sessions anytime. Additionally, adding Secure and HttpOnly attributes to the cookies can prevent interception and JavaScript access, enabling a more secure website development. Svelte+FastAPIでSign in with Googleを試してみた 2023-12-25T00:00:00+00:00 はじめに</h1> SvelteとFastAPIを使用して構築したサンプルウェブサイトにGoogleのサインイン機能を実装しました。 Google Sign Inに成功した後、バックエンドのAPIサーバーにログインするためには、様々な方法が考えられます。 Googleから受け取ったJWTを、RequestヘッダにAuthorization: "Bearer: JWT"</code>として送信し、正しいJWTであれば、認証されます。また、バックエンドでJWTを発行し、Authorization</code>ヘッダにセットして認証済みユーザーを識別する方法も一般的です。しかし、JWTをそのままログインユーザーの識別に利用する場合、JWTの漏洩時に即時の無効化が難しい問題があります。参考：Stop using JWT for sessions</a>。そこで、GoogleからJWTを受け取った後、FastAPI側で新たにsession_idを発行し、Cookieを介してセッションを維持する方法で実装しました。 セッション情報はFastAPIのセッションデータベースで管理されており、管理者がいつでもセッションを無効にできます。また、CookieにSecure属性とHttpOnly属性を付与することで、経路での盗聴防止やJavaScriptからのアクセス防止が可能になり、より安全なWebサイトの構築が可能です。 なお、SvelteもFastAPIも独学で学習中ですので、おかしな点があれば、アドバイスいただけると嬉しいです。 実装するもの</h1> 認証が実装されると、未ログイン時のアクセスはログインページにリダイレクトされ、そこでGoogleアカウントでログインできます。 Customerページは、認証に成功した場合にのみ表示できます。 FastAPIではSwagger UIによるドキュメントページが自動生成されます。 Svelteでのフロントエンドの実装</h1> Svelteを使用してフロントエンドを実装します。バックエンドからcustomerデータを取得し、テーブル表示するページにGoogle OAuth2を利用した認証機能を実装します。 Google Sign Inに成功し、取得したJWTをバックエンドのAPIサーバーに送信します。バックエンド側では、JWTをベリファイしユーザーアカウントを作成し、session_idをCookieにセットしてレスポンスを返信します。これ以降、バックエンドへのリクエスト時には、常にCookieにsession_idをセットして送信します。 実装したコードは以下のリポジトリにあります。 frontend-svelteのコード</a></li> </ul> ログイン機能の実装ポイントを以下に説明します。 ルーティング</h2> svelete-routingを利用し、以下のようにルーティングを設定します。 /customer: Customerコンポーネントを表示します。 </li> /login: LoginPageコンポーネントを表示します。 </li> </ul> App.svelte</code>のサンプルコードは次の通りです。 import { Router, Link, Route } from "svelte-routing"; import Top from "./components/Top.svelte"; import Customer from "./components/Customer.svelte"; import NoMatch from "./components/NoMatch.svelte"; import LoginPage from "./components/LoginPage.svelte"; export let url = ""; Top Customer</code></pre>ログインページ</h2> GoogleのSign Inボタンを表示し、OneTapインターフェースも利用します。 GoogleでSign In後、コールバックファンクションbackendAuth</code>を呼び出します。 backendAuth</code>では、Google Sign Inで得られたレスポンスをhttp://localhost/api/login</code>に送信します。レスポンスにはJWTトークンが含まれます。バックエンドでのログインが成功した場合、直前にいたページにリダイレクトします。失敗した場合、エラー処理が行われ、再度ログインページにリダイレクトされます。 LoginPage.svelte</code>のサンプルコードは次の通りです。 import { onMount } from "svelte"; import { apiAxios } from "../lib/apiAxios"; import { useLocation, navigate } from "svelte-routing"; import { jwtDecode } from "jwt-decode"; let location = useLocation(); let origin = $location.state?.from; const backendAuth = (response) => { const data = JSON.stringify(response, null, 2); console.log("JWT fed to backendAuth:\n", data); apiAxios .post(`/api/login/`, data) .then((res) => { console.log("Navigate back to: ", origin); navigate(origin, { replace: true }); }) .catch((error) => { console.log("backendAuth failed. Redirecting to /login... "); }); }; const onLogin = backendAuth; onMount(() => { google.accounts.id.initialize({ /* global google */ client_id: import.meta.env.VITE_APP_GOOGLE_OAUTH2_CLIENT_ID, callback: (r) => onLogin(r), ux_mode: "popup", // ux_mode: "redirect", }); google.accounts.id.renderButton(document.getElementById("signInDiv"), { theme: "filled_blue", size: "large", shape: "circle", }); google.accounts.id.prompt(); }); Login page</code></pre>axiosインスタンスのセットアップ</h2> withCredentials: true</code>をセットすることでaxiosはCookieを送信するようになります。 axiosのinterceptorsでエラー処理を行い、バックエンドから401 Unauthorized</code>、403 Forbidden</code>が返ってきた場合、/login</code>へリダイレクトします。 apiAxios.js</code>のサンプルコードは次の通りです。 import axios from "axios"; import { navigate } from "svelte-routing"; export const apiAxios = axios.create({ baseURL: `${import.meta.env.VITE_APP_API_SERVER}`, withCredentials: true, }); apiAxios.interceptors.response.use( (response) => { return response; }, (error) => { if (error.response.status === 401 || error.response.status === 403) { console.log( "apiAxios failed. Redirecting to /login... from", location.pathname ); navigate("/login", { state: { from: location.pathname }, replace: true }); } return Promise.reject(error); } );</code></pre>LogoutButtonコンポーネント</h2> Logoutボタンを表示するコンポーネントです。 onMount時に、バックエンドサーバにアクセスし、ログインしているユーザーの情報を取得します。 Cookieにsession_idが無い場合、すなわち未ログインの場合にはユーザー情報取得に失敗し、apiAxios.interceptorのエラー処理により、/login</code>ページにリダイレクトされます。 import { onMount } from "svelte"; import { apiAxios } from "../lib/apiAxios.js"; let user; onMount(() => { console.log("Logout Component Mounted"); getUser(); }); const handleLogout = () => { user = null; apiAxios .get(`/api/logout/`) .then((res) => { console.log("backendLogout", res); getUser(); }) .catch((error) => console.log("Logout failed: ", error)); }; const getUser = () => { apiAxios .get(`/api/user/`) .then((res) => { user = res.data; console.log("getUser: user:", user); }) .catch((error) => console.log("getUser failed: ", error.response)); }; const onLogout = handleLogout; Authenticated as {user?.username}   Sign Out</code></pre>Customerコンポーネント</h2> バックエンドサーバからデータを取得し、テーブル表示するコンポーネントです。LogoutButton</code> コンポーネントがページ内に配置されているので、未ログインの場合には、/login</code> ページにリダイレクトされます。 import { onMount } from "svelte"; import { apiAxios } from "../lib/apiAxios"; import LogoutButton from "./LogoutButton.svelte"; let customers = []; let Loading = true; onMount(async () => { await new Promise((r) => setTimeout(r, 1000)); apiAxios .get(`/api/customer/`) .then((res) => (customers = res.data.results)) .catch((error) => console.log(error)) .finally(() => Loading = false); }); This is Customer. {#if Loading} Loading ... {:else} id name email {#each customers as cs} {cs.id} {cs.name} {cs.email} {/each} {/if}</code></pre>FastAPIでのバックエンド実装</h1> FastAPIを使用して、バックエンドのAPIサーバを実装します。フロントエンドから受け取ったJWTを検証し、ユーザーアカウントを作成して、session_idを発行しセッションデータベースに登録します。作成したsession_idをCookieにセットしてレスポンスを返信します。受け取ったJWTに対応するユーザーがデータベースに存在しない場合、新たにユーザーを作成します。 認証で保護されたエンドポイントへのリクエストを受け取った場合、Cookieにセットされたsession_idとセッションデータベースを照合し、有効なセッション情報が存在している場合のみ、要求されたデータを返信します。 実装したコードは以下のリポジトリにあります。 backend-fastapiのコード</a></li> </ul> ログイン機能の実装ポイントについて以下に説明します。 /api/loginエンドポイント</h2> フロントエンドからJWTを受け取り、Googleの公開証明書を使用してJWTを検証します。検証に成功すると、JWT内のemailアドレスを使用してユーザーデータベースにユーザーを登録します。新しく作成したユーザーの情報とsession_idをセッションデータベースに登録し、Cookieにsession_idをセットしてレスポンスを返します。 auth/auth.py async def VerifyToken(jwt: str): try: idinfo = id_token.verify_oauth2_token( jwt, requests.Request(), settings.google_oauth2_client_id) except ValueError: print("Error: Failed to validate JWT token with GOOGLE_OAUTH2_CLIENT_ID=" + settings.google_oauth2_client_id +".") return None print("idinfo: ", idinfo) return idinfo @router.post("/login") async def login(request: Request, response: Response, ds: Session = Depends(get_db), cs: Session = Depends(get_cache)): body = await request.body() jwt = json.loads(body)["credential"] if jwt == None: return Response("Error: No JWT found") print("JWT token: " + jwt) idinfo = await VerifyToken(jwt) if not idinfo: print("Error: Failed to validate JWT token") return Response("Error: Failed to validate JWT token") user = await GetOrCreateUser(idinfo, ds) if user: user_dict = get_user_by_name(user.name, ds) if not user_dict: raise HTTPException(status_code=HTTP_500_INTERNAL_SERVER_ERROR, detail="Error: User not exist in User table in DB.") user = UserBase(**user_dict) session_id = create_session(user, cs) response.set_cookie( key="session_id", value=session_id, httponly=True, max_age=1800, expires=1800, ) else: return Response("Error: Auth failed") return {"Authenticated_as": user.name}</code></pre>アクティブユーザーを判別する関数</h2> FastAPIが受け取ったリクエストのCookieからsession_idを取り出し、セッションデータベース内のエントリと一致すればログイン済みとみなします。 get_current_active_user</code>では、disabledのフラグが立っていないか判別し、get_admin_user</code>では、adminのフラグが立っているかどうか判別します。 auth/auth.py async def get_current_user(ds: Session = Depends(get_db), cs: Session = Depends(get_cache), session_id: str = Depends(oauth2_scheme)): if not session_id: return None session = get_session_by_session_id(session_id, cs) if not session: return None username = session["name"] user_dict = get_user_by_name(username, ds) user=UserBase(**user_dict) if not user: raise HTTPException( status_code=status.HTTP_401_UNAUTHORIZED, detail="Invalid authentication credentials", ) return user async def get_current_active_user(current_user: User = Depends(get_current_user)): if not current_user: raise HTTPException(status_code=HTTP_401_UNAUTHORIZED, detail="NotAuthenticated") if current_user.disabled: raise HTTPException(status_code=HTTP_403_FORBIDDEN, detail="Inactive user") return current_user async def get_admin_user(current_user: User = Depends(get_current_active_user)): print("CurrentUser: ", current_user) if not current_user.admin: raise HTTPException(status_code=HTTP_403_FORBIDDEN, detail="Admin Privilege Required") return current_user</code></pre>各種エンドポイントの保護</h2> Depends(get_current_active_user)</code>により、/api/user/</code>エンドポイントはログインユーザーのみがアクセスできます。 auth/auth.py @router.get("/user/") async def get_user(user: UserBase = Depends(get_current_active_user)): return {"username": user.name, "email": user.email,}</code></pre> customer/customer.py</code>で定義されたルートは認証済みユーザーのみ、admin/user.py</code>で定義されたルートはAdminユーザーのみがアクセスできます。 main.py import admin.debug, admin.user, auth.auth, auth.debug import customer.customer app = FastAPI() app.include_router( customer.customer.router, prefix="/api", tags=["CustomerForAuthenticatedUser"], dependencies=[Depends(auth.auth.get_current_active_user)], ) app.include_router( admin.user.router, prefix="/api", tags=["AdminOnly"], dependencies=[Depends(auth.auth.get_admin_user)], )</code></pre>まとめ</h1> SvelteとFastAPIを用いて構築したサンプルウェブサイトにGoogleのサインイン機能を実装しました。 GoogleからJWTを受け取った後、FastAPI側で新たにsession_idを発行し、Cookieを介してセッションを維持する方法で実装しました。セッション情報はFastAPIのセッションデータベースで管理されており、いつでも管理者がセッションを無効にできます。また、CookieにSecure属性とHttpOnly属性を付与することで、経路での盗聴防止やJavaScriptからのアクセス防止が可能になり、より安全なWebサイトの構築が可能です。 UEFI/BIOSのどちらでもGRUB起動可能なUSBメモリを作る 2023-04-08T00:00:00+00:00 要旨</h2> UEFIモードとBIOSモードのどちらでもGRUBを起動可能なUSBメモリの作成を試みた。どちらの場合でもGRUBの起動が可能であるはずのUSBメモリを作成した。 SupermicroワークステーションとIntel NUCで実機検証したところ、Supermicroのワークステーションでは、どちらのモードでもブート可能であったが、Intel NUCはそうではなかった。ハードウェアによってはBIOSブート時にパーティションにbootable(active)フラグが必要であるものがあり、その場合は、UEFIブートと両立できないことがわかった。 はじめに</h2> USBメモリからLinuxが起動できると便利である。サーバのメンテナンスや新規OSインストールなどの様々な場面で、ディスクレスなLinuxをUSBメモリから起動し役立てることができる。私の場合、自宅や会社のルータとして、USBから起動したDebian Linuxを利用している。ファイルシステムをメモリ(tmpfs)上に展開しディスクレスで運用しているので、なにか設定をしくじった場合にも再起動すればもとの状態に戻すことができるし、ハードウェアが故障してしまった場合などは別のマシンにUSBメモリを差し替えれば簡単に復旧できるので大変重宝している。 Linuxを起動するにはGRUBというブートローダを利用することが多い。GRUBはLinuxカーネルのロードが可能なだけでなく、Windowsのチェインロードも可能である。かつてのPCは、BIOSというファームウェアがドライブの先頭にあるGRUBをロードしていたが、最近のPCではUEFIがESPにあるGRUBをロードするように仕様に変わった。 BIOSとUEFIではブート仕様が異なるので、GRUBのインストールの方式も異なっていて、一方の方式でLinux及びGRUBインストールしたドライブをもう一方の方式のPCで利用することができない。通常は、HDDやSSD等の起動ドライブをPC間で移動することはあまりないのでそれぞれのPCにそれぞれ適した方式でインストールすれば問題ない。 しかしメンテナンス用のUSBメモリは、できれば、古いBIOS方式でも新しいUEFI方式でも、どちらでも使えるようにしておきたい。そこで、今回、UEFIモードでもBIOSモードでも、GRUBを起動することができるUSBメモリの作成を試みた。 やり方</h2> LinuxパソコンにUSBメモリを挿したとき、/dev/sdaとして認識されているとし、そこにパーティションテーブルを作成しGRUBのインストールを行う。以下の手順は、ストレージのパーティションを操作するので、/dev/sdaが確かに操作しようとしているUSBメモリなのかをよく確認してから行う必要がある。 パーティション初期化と作成</h3> Linuxのルートパーティション、ESPパーティション、BIOSブートパーティションを作成する。ESPパーティションは先頭から512Mbyte、Linuxルートパーティションは残り全部を割り当てる。最近のパーティションツールは、先頭の先頭に2047セクタ分の空きを残すようなので、そこにBIOSブートパーティションを作成する。 TOP_DIR=./ dev=/dev/sda # Clear partition table sgdisk -Z $dev # Create ESP partition sgdisk -n 2::+512M $dev sgdisk -t 2:ef00 $dev # Create Linux partition sgdisk -n 1:: $dev # Create BIOS boot partition sgdisk -a 1 -n 3:34:2047 $dev sgdisk -t 3:ef02 $dev # Change the GPT name of each partition sgdisk -c 1:Linux -c 2:ESP -c 3:BIOS $dev # Show current status sgdisk -p $dev</code></pre> LinuxルートパーティションとESPパーティションをフォーマットし、ファイルシステムにマウント。 # Format ESP and Linux partition mkfs.fat -F32 -n ESP ${dev}2 mkfs.ext4 -F -L usbdebian ${dev}1 # Create mount point and mount file systems mkdir -p ${TOP_DIR}/mnt mount -L usbdebian ${TOP_DIR}/mnt mkdir -p ${TOP_DIR}/mnt/boot/efi mount -L ESP ${TOP_DIR}/mnt/boot/efi</code></pre> BIOS用GRUBのインストール。MBR（ディスクの先頭512Byte）とBIOSブートパーティションにgrubをインストール。 # BIOS setup grub-install --target=i386-pc --boot-directory=./mnt/boot/ $dev</code></pre> 動作確認用のGRUBメニューの設定ファイルを作成。今回はLinuxカーネルは入れず、このメニューが表示できるところまでがゴールなので、仮のもので良い。 # Create minimum grub.cfg for testing cat ${TOP_DIR}/mnt/boot/grub/grub.cfg set default=1 set timeout=5 menuentry "Debian Linux" { linux /boot/vmlinuz } EOF</code></pre> UEFIモードでブートするには、UEFI設定にブートするバイナリとその優先順位を登録することが一般的であるが、USBメモリの場合リームーバブルメディアであるので適さない。 UEFIブートではUEFI設定で他に指定がない場合、EFI/boot/bootx64.efiにフォールバックするので、grubx64.efiをその名前で置いておけば良い。grubx64.efiは同じディレクトリのgrub.cfgを参照するので、そこに/boot/grub/grub.cfgを更に参照するように書いておく。 UEFIモードの場合にはセキュアブートも可能である。その場合には、shimx64.efi -> grubx64.efi -> grub.cfgの順で読み込ませたいので、shimx64.efiをEFI/boot/bootx64.efiとして置き、同じディレクトリに、grubx64.efiとgrub.cfgを置けば良い。この時、shimx64.efiとgrubx64.efiは署名済みのものを用いる必要がある。 # UEFI boot setup mkdir -p ${TOP_DIR}/mnt/boot/efi/EFI/boot cp /usr/lib/grub/x86_64-efi/monolithic/grubx64.efi ${TOP_DIR}/mnt/boot/efi/EFI/boot/bootx64.efi cat ${TOP_DIR}/mnt/boot/efi/EFI/boot/grub.cfg search.fs_label usbdebian root set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg EOF # Unmount filesystem umount ${TOP_DIR}/mnt/boot/efi/ && umount ${TOP_DIR}/mnt/</code></pre> 作成したUSBメモリのパーティション構成 root@dyna:~# sgdisk -p /dev/sda Disk /dev/sda: 60088320 sectors, 28.7 GiB Model: Ultra Fit Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): 21780B2C-8682-42A0-9564-D7E7D726A7EC Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 60088286 Partitions will be aligned on 2-sector boundaries Total free space is 0 sectors (0 bytes) Number Start (sector) End (sector) Size Code Name 1 1050624 60088286 28.2 GiB 8300 Linux 2 2048 1050623 512.0 MiB EF00 ESP 3 34 2047 1007.0 KiB EF02 BIOS</code></pre> 作成したUSBメモリのファイルシステム確認（unmout前に確認） root@dyna:~# tree -L 3 ${TOP_DIR}/mnt/ mnt/ ├── boot │ ├── efi │ │ └── EFI │ └── grub │ ├── fonts │ ├── grub.cfg │ ├── grubenv │ ├── i386-pc │ └── locale └── lost+found 8 directories, 2 files root@dyna:~# tree ${TOP_DIR}/mnt/boot/efi/ mnt/boot/efi/ └── EFI └── boot ├── bootx64.efi └── grub.cfg 2 directories, 2 files</code></pre> 以上でGRUBまで立ち上がるUSBは完成である。 なぜこの構成でBIOS/UEFI両対応になるのか</h3> BIOSブートとUEFIブートでは、GRUBが読み込まれる場所が異なる。しかし、最終的に同じ /boot/grub/grub.cfg</code>を参照するように構成することで、両対応が可能になる。 BIOS: MBR → BIOS boot partition → /boot/grub/grub.cfg → kernel ↑ UEFI: ESP → bootx64.efi → ESP/grub.cfg --┘</code></pre> BIOSブートの場合: BIOSがディスク先頭のMBR（Master Boot Record）を読む</li> MBRのブートコードがBIOS boot partition内のGRUB core.imgへジャンプ</li> GRUBが/boot/grub/grub.cfg</code>を読み込み</li> 設定に従ってカーネルをロード</li> </ol> UEFIブートの場合: UEFIファームウェアがGPT上のESP（EFI System Partition）を探す</li> デフォルトパス/EFI/boot/bootx64.efi</code>を実行（リムーバブルメディアのフォールバック）</li> 同じディレクトリのgrub.cfg</code>を読む:search.fs_label usbdebian root set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg</code></pre></li> ラベルusbdebian</code>のパーティションを見つけ、/boot/grub/grub.cfg</code>を読み込み</li> 設定に従ってカーネルをロード</li> </ol> ポイント: ESPのgrub.cfg</code>はリダイレクト役。本体の設定ファイルへ誘導するだけ</li> メインの/boot/grub/grub.cfg</code>を1箇所で管理できる</li> search.fs_label</code>でラベル指定することで、デバイス名（/dev/sdaなど）に依存しない</li> </ul> 実際にブートできるのか</h2> 作成したUSBメモリで実際にブート可能であるかを、SupermicroのワークステーションとIntel NUCで試してみた。 Supermicroのワークステーションでは、UEFIブートであってもBIOSブートであっても、GRUBメーニュー画面が表示できた。 Intel NUCの場合は、UEFIモードでは無事にGRUBのメニューが表示されたが、BIOSモードでのブートができなかった。 Intel NUCの場合には、BIOSモードでブートする場合、次の手順でPMBRのパーティションテーブルでbootable(active)フラグを立ててやる必要があった。 root@dyna:~# sfdisk -A /dev/sda 1 Activation is unsupported for GPT -- entering nested PMBR. The bootable flag on partition 1 is enabled now. The partition table has been altered. Syncing disks. root@dyna:~# sgdisk -O /dev/sda Disk size is 60088320 sectors (28.7 GiB) MBR disk identifier: 0x00000000 MBR partitions: Number Boot Start Sector End Sector Status Code 1 * 1 60088319 primary 0xEE</code></pre> PMBRのパーティションテーブルでbootable(active)フラグを立てた場合、今度はUEFIブートができなくなってしまった。どうやらUEFIブートのUEFIブートの規格でPMBR上でそのフラグを立てることを明確に禁止しているらしい。再度、UEFIブートするには、以下のように、bootable(active)フラグを戻す必要がある。 root@dyna:~# sfdisk -A /dev/sda - Activation is unsupported for GPT -- entering nested PMBR. The bootable flag on partition 1 is disabled now. The partition table has been altered. Syncing disks.</code></pre> 古いハードウェアには、bootable(active)フラグが立っているパーティションが無いとBIOSブートできないものがあり、どうやらIntel NUCはそのようなハードウェアのひとつであるようだ。 参考 [Partitioning </li> wiki.archlinux.org](https://wiki.archlinux.org/title/Partitioning#Tricking_old_BIOS_into_booting_from_GPT) (このやり方はうまく行かなかった) </li> BIOS / GPT: do we need a ‘boot’ flag?</a> </li> </ul> まとめ</h2> 今回、UEFIモードでもBIOSモードでも、GRUBを起動することができるUSBメモリの作成を試みた。作成したUSBメモリでGRUB画面の表示までたどり着けるか試してみた。 Supermicroのワークステーションでは、BIOSブート、UEFIブートのどちらでもGRUB画面にたどり着くことができたが、Intel NUCではPMBR上でbootable(active)フラグの切り替えが必要であった、 UEFIブートの規格でPMBR上でそのフラグを立てることを明確に禁止しているらしい。しかし古いハードウェアにはBIOSブート時に、bootable(active)フラグが立っているパーティションが必要であるものがあることが確認された。その場合には、ブートモードに応じて作成したUSBメモリのbootable(active)フラグを切り替えることがどうしても必要になってしまうことがわかった。 KVM再入門：Qemuコマンドラインで仮想マシンを起動し、Windows11ゲストをセットアップする。 2023-03-22T00:00:00+00:00 はじめに</h2> 前回</a>に引き続き、KVM仮想マシン上にWindows11をインストールするやり方をまとめておきます。 Windows10の時とは以下のような違いがあります。 Windows11の場合、TPMとUEFI Secure Bootが必須である。 </li> KVMでTPMを使うには、ホストの/dev/tpm0をパススルーで使う方法と、ソフトウェアのTPMデバイスエミュレーター(swtpm)を使う方法がある。 </li> KVMでUEFI Secure Bootするには、ovmfパッケージにより提供されるUEFI firmwareを利用する。 </li> </ul> Window11のインストール</h2> KVM仮想マシンの起動方法</h3> Windows11のインストールメディア、virtioドライバインストール用のisoイメージをダウンロードしておきます。 Download Windows 11</a> </li> Windows用virtioドライバのありか</a> </li> </ul> 必要パッケジージのインストール sudo apt-get install qemu-system-x86 virt-viewer ovmf</code></pre> qcow2ディスクイメージを作成します。 qemu-img create -f qcow2 win11pro.qcow2 40G</code></pre> 書き込み用のFirmwareのローカルコピーを作成します。 cp /usr/share/OVMF/OVMF_VARS_4M.ms.fd ./</code></pre>ホストの/dev/tpm0をパススルーで使う場合</h4> 以下のコマンドで仮想マシンを起動できます。 sudo qemu-system-x86_64 \ -machine q35,accel=kvm \ -m 8192 -cpu host \ -smp 6,sockets=1,dies=1,cores=6,threads=1 \ -display spice-app \ -drive file=./win11pro.qcow2,if=virtio,format=qcow2,discard=unmap \ -drive file=~/Downloads/Win11_22H2_Japanese_x64v1.iso,index=0,media=cdrom \ -drive file=~/Downloads/virtio-win-0.1.229.iso,index=1,media=cdrom \ -drive if=pflash,format=raw,unit=0,file=/usr/share/OVMF/OVMF_CODE_4M.ms.fd,readonly=on \ -drive if=pflash,format=raw,file=./OVMF_VARS_4M.ms.fd \ -tpmdev passthrough,id=tpm0,path=/dev/tpm0,cancel-path=/dev/null \ -device tpm-tis,tpmdev=tpm0 \</code></pre>ソフトウェアのTPMデバイスエミュレータを使う場合</h4> TPMデバイスエミュレータswtpmを起動しておきます。 mkdir mytpm swtpm socket --tpmstate dir=./mytpm \ --tpm2 \ --ctrl type=unixio,path=./mytpm/swtpm-sock \ --log level=20</code></pre> 以下のコマンドで仮想マシンを起動できます。 sudo qemu-system-x86_64 \ -machine q35,accel=kvm \ -m 8192 -cpu host \ -smp 6,sockets=1,dies=1,cores=6,threads=1 \ -display spice-app \ -drive file=./win11pro.qcow2,if=virtio,format=qcow2,discard=unmap \ -drive file=~/Downloads/Win11_22H2_Japanese_x64v1.iso,index=0,media=cdrom \ -drive file=~/Downloads/virtio-win-0.1.229.iso,index=1,media=cdrom \ -drive if=pflash,format=raw,unit=0,file=/usr/share/OVMF/OVMF_CODE_4M.ms.fd,readonly=on \ -drive if=pflash,format=raw,file=./OVMF_VARS_4M.ms.fd \ -chardev socket,id=chrtpm,path=./mytpm/swtpm-sock \ -tpmdev emulator,id=tpm0,chardev=chrtpm \ -device tpm-tis,tpmdev=tpm0 \</code></pre>仮想マシンが立ち上がると、UEFシェルが起動してしまう。</h3> どうやらUEFIブートの場合、UEFIの設定画面でブートデバイスの優先順位を変更してやる必要があるようです。 UEFIシェルをexitで抜けるとUEFIの設定メニューに入るので、そこでUEFIシェルの優先順位をCDROM/DVDROMなどインストールメディアよりも低くします。そして、RestまたはContinueで、Windowsインストール用のCDROMからブートします。 インストール先のドライブが見えない</h3> E:ドライブ(virtio-win-xx)にあるドライバを読み込むと、qcow2のディスクイメージが見えるようになるので、そこにWindows11をインストールします。 インストール時にMicrosoftアカウントへのサインインを求められる</h3> no@thankyou.comで一度サインインに失敗すると、ローカルアカウントが作成できます。 残りのvirtioドライバーをインストール</h3> Windowsセットアップ完了後、Windows上でE:ドライブ（virtio-win-0.1.229）を開きます。そこにあるインストーラを起動し、virtioドライバをインストールしておきます。 以上で、ネットワーク関連は未設定状態ですが、Windows11がインストールされたqcow2ディスクイメージ、win11pro.qcow2ができあがります。 普段使いのために</h2> Windows11のインストールは、ネットワーク無しで行った。仮想マシン上のWindows11を利用するには、ネットワークが使えないと困るでしょう。ネットワークを使えるようにするためには、次の3つの準備が必要です。 Linuxホスト上でのネットワーク設定 </li> KVM起動コマンドをネットワークが使えるように修正 </li> Windows11ゲストマシン上でネットワーク設定 </li> </ul> Linuxホストのネットワークセットアップ</h3> Linuxホスト上では、以下の設定を行えば十分です。 brdg=kbr0 outif=wlan0 addr=10.0.0.254/24 # ブリッジインターフェースの準備 brctl addbr $brdg ip add add dev $brdg $addr ip link set dev $brdg up # IPマスカレード設定 iptables -t nat -A POSTROUTING -s $addr -o $outif -j MASQUERADE # IPフォワーディング許可 echo 1 > /proc/sys/net/ipv4/conf/$outif/forwarding echo 1 > /proc/sys/net/ipv4/conf/$brdg/forwarding</code></pre> 念の為、上記で用意したものをもとに戻すのは、以下のやり方で良いでしょう。 # IPフォワーディング許可を取り消す echo 0 > /proc/sys/net/ipv4/conf/$outif/forwarding echo 0 > /proc/sys/net/ipv4/conf/$brdg/forwarding # ブリッジインターフェースを消す ip link set dev $brdg down brctl delbr $brdg # IPマスカレード設定を消す iptables -t nat -D POSTROUTING -s $addr -o $outif -j MASQUERADE</code></pre>Windowsゲスト起動コマンド</h3> qemuコマンドはオプションが多いのでスクリプト化しておくと良いでしょう。 run.win11.sh: #!/bin/bash sudo qemu-system-x86_64 \ -m 8192 -cpu host \ -smp 6,sockets=1,dies=1,cores=6,threads=1 \ -drive file=./win11pro.qcow2,if=virtio,format=qcow2,discard=unmap \ -display spice-app \ -machine q35,accel=kvm \ -rtc base=localtime,clock=host \ -drive if=pflash,format=raw,unit=0,file=/usr/share/OVMF/OVMF_CODE_4M.ms.fd,readonly=on \ -drive if=pflash,format=raw,file=./OVMF_VARS_4M.ms.fd \ -tpmdev passthrough,id=tpm0,path=/dev/tpm0,cancel-path=/dev/null \ -device tpm-tis,tpmdev=tpm0 \ -device virtio-net-pci,netdev=dev1,mac=52:54:00:11:00:12,id=net1 \ -netdev tap,id=dev1,vhost=on,script=./qemu-ifup</code></pre> 仮想マシン起動時にデバイスをホストのブリッジにアタッチします。 qemu-ifup: #!/bin/sh bridge=kbr0 /sbin/ip link set dev $1 up promisc off /sbin/brctl addif $bridge $1</code></pre>Windowsゲストのネットワーク設定</h3> 次のアドレスを設定 IPv4アドレス: 10.0.0.1/24 ゲートウェイ: 10.0.0.254 DNSサーバ: 192.168.40.1(Linuxホストと同じ設定にすると良いと思う。)</code></pre> この他に、Windows 11 Proの場合はRemote Desktop機能があるので、利用可能にしておくと良いでしょう。 その他のTips</h2> 一旦ビューワーを閉じたあともう一度接続するには</li> </ul> $ sudo virt-viewer -c spice+unix:///tmp/.JVB811/spice.sock</code></pre> Remote Desktop接続は、例えば次のようにする</li> </ul> user=ktaka xfreerdp /u:$user /size:1900x1000 +fonts +clipboard /audio-mode:1 /v:10.0.0.1</code></pre> qemu起動時にはwindowを表示せず、rdpのみで使うには --display spice-app</code>を--display none</code>にすれば良い。</li> </ul> 参考文献</h2> QemuでのTPMの使い方</h3> 以下のドキュメントに十分な情報があります。 QEMU TPM Device</a></li> </ul> QEMUでのUEFI Secure</h3> Bootのやり方 SecureBootVirtualMachine</a> </li> Secure(ish) boot with QEMU</a> </li> </ul> どのUEFI</h3> firmwareを使うべきか Debianのドキュメントに書いてあります。 Secure Boot pre-enabledな、OVMF_CODE_4M.ms.fdとOVMF_VARS_4M.ms.fdをセットで使う。 </li> 前者はRead Onlyで、後者はコピーしたものをRead Write可能な状態で利用する。 </li> UEFIのメニューでSaveした設定変更は、OVMF_VARS_4M.ms.fdのコピーに書き込まれる。 </li> </ul> /usr/share/doc/ovmf/README.Debian The OVMF_CODE*.fd files provide UEFI firmware for a QEMU guest that is intended to be read-only. The OVMF_VARS*.fd files provide UEFI variable template images which are intended to be read-write, and therefore each guest should be given its own copy. Here's an overview of each of them: OVMF_CODE_4M.fd Use this for booting guests in non-Secure Boot mode. While this image technically supports Secure Boot, it does so without requiring SMM support from QEMU, so it is less secure. Use the OVMF_VARS.fd template with this. OVMF_CODE_4M.ms.fd This is a symlink to OVMF_CODE_4M.secboot.fd. It is useful in the context of libvirt because the included JSON firmware descriptors will tell libvirt to pair OVMF_VARS.ms.fd with it, which has Secure Boot pre-enabled. OVMF_CODE_4M.secboot.fd Like OVMF_CODE_4M.fd, but will abort if QEMU does not support SMM. Use this for guests for which you may enable Secure Boot. Be aware that the included JSON firmware descriptors associate this with OVMF_CODE_4M.fd. Which means, if you specify this image in libvirt, you'll get a guest that is Secure Boot-*capable*, but has Secure Boot disabled. To enable it, you'll need to manually import PK/KEK/DB keys and activate Secure Boot from the UEFI setup menu. If you want Secure Boot active from the start, consider using OVMF_CODE.ms.fd instead. OVMF_VARS_4M.fd This is an empty variable store template, which means it has no built-in Secure Boot keys and Secure Boot is disabled. You can use it with any OVMF_CODE image, but keep in mind that if you want to boot in Secure Boot mode, you will have to enable it manually. OVMF_VARS_4M.ms.fd This template has distribution-specific PK and KEK1 keys, and the default Microsoft keys in KEK/DB. It also has Secure Boot already activated. Using this with OVMF_CODE.ms.fd will boot a guest directly in Secure Boot mode. OVMF32_CODE_4M.secboot.fd OVMF32_VARS_4M.fd These images are the same as their "OVMF" variants, but for 32-bit guests. OVMF_CODE.fd OVMF_CODE.ms.fd OVMF_CODE.secboot.fd OVMF_VARS.fd OVMF_VARS.ms.fd These images are the same as their "4M" variants, but for use with guests using a 2MB flash device. 2MB flash is no longer considered sufficient for use with Secure Boot. This is provided only for backwards compatibility. OVMF_VARS_4M.snakeoil.fd This image is **for testing purposes only**. It includes an insecure "snakeoil" key in PK, KEK & DB. The private key and cert are also shipped in this package as well, so that testers can easily sign binaries that will be considered valid. Intended for use with OVMF_CODE_4M.secboot.fd. PkKek-1-snakeoil.key PkKek-1-snakeoil.pem The private key and certificate for the snakeoil key. Use these to sign binaries that can be verified by the key in the OVMF_VARS.snakeoil.fd template. The password for the key is 'snakeoil'. -- dann frazier , Fri, 11 Dec 2020 17:30:59 -0700</code></pre>まとめ</h2> QEMUコマンドのみでKVM仮想マシンを起動し、Windows11をインストールする方法についてまとめました。 Window10の場合との違いは、TPM及びUEFI Secure Bootが必須であることです。 Windows11の場合も、GUIプログラムvirt-managerでのインストール方法はネット上でよく見かけますが、qemuコマンドのみでのやり方はあまり多くないようです。余計なものはなるべくインストールしたくない人、ソフトウェアスタックをミニマムに保って中身を理解しながら使いたい人の役に立てば幸いです。 KVM再入門：Qemuコマンドラインで仮想マシンを起動し、Windows10ゲストをセットアップする。 2023-03-20T00:00:00+00:00 はじめに</h2> 最近Debian Linuxをインストールしたノートパソコン上に、KVM仮想マシンのゲストOSとして、Windows10をインストールする機会がありました。はじめはGUI形式のvirt-managerをつかって、ボタンをポチポチ押しながらゲストOSをインストールしていました。しかし、調べていくうちに、qemuコマンドラインのみで仮想マシンを起動しWindowsをインストールする方法にたどり着いたので、それについてまとめておこうと思います。 virt-managerは非常に便利ですが、libvirtやそれが依存する数多くのパッケージをインストールし、libvirtdなどをデーモンとして動かしておかなければなりません。 qemuコマンドラインのみでWindowsをインストールする方法をおさえておけば、本来不必要だったものをインストールしなくて済みますし、構成がシンプルであるため動作の仕組みが容易に理解でき、なにかトラブルがあった場合にも比較的容易にデバッグが可能になると期待できます。 Windows10インストール</h2> 事前準備</h3> インストールメディア、virtioドライバのダウンロード</h4> まず、あらかじめ必要なものをダウンロードしておきます。 Windows10のインストールメディアWin10_22H2_Japanese_x64.isoを、Microsoftのページ</a>からダウンロードする。 </li> virtioドライバをが必要になるので、Fedoraのページ</a>からダウンロードします。今回は、この記事の執筆時点で最新のvirtio-win-0.1.229.isoを利用しました。 </li> </ul> 必要パッケジージのインストール</h4> sudo apt-get install qemu-system-x86 virt-viewer</code></pre>インストール先ドライブのイメージファイル作成</h4> Windowsのインストール先として、40Gbyteのqcow2イメージファイルを作成します。 qemu-img create -f qcow2 win10.qcow2 40G</code></pre>不具合回避</h4> 後述のコマンドラインで仮想マシンを起動しようとすると、以下のようなエラーメッセージが出て、仮想マシンが起動できない。 qemu-system-x86_64: info: Launching display with URI: spice+unix:///tmp/.BHI811/spice.sock qemu-system-x86_64: Failed to launch spice+unix:///tmp/.BHI811/spice.sock URI: Operation not supported qemu-system-x86_64: You need a capable Spice client, such as virt-viewer 8.0</code></pre> これを回避するために/root/.config/mimeapps.listに以下の行を追加する。 [Added Associations] x-scheme-handler/spice+unix=remote-viewer.desktop</code></pre>仮想マシンの起動とWindowsのインストール</h3> 以下のコマンドで仮想マシンを起動すると、Windowsのインストーラーウィンドウが現れますので、画面の指示に従ってインストールを進めます。 sudo qemu-system-x86_64 \ -machine q35,accel=kvm \ -m 8192 -cpu host \ -smp 6,sockets=1,dies=1,cores=6,threads=1 \ -display spice-app \ -rtc base=localtime,clock=host \ -drive file=./win10pro.qcow2,if=virtio,format=qcow2,discard=unmap \ -drive file=./Win10_22H2_Japanese_x64.iso,index=0,media=cdrom \ -drive file=./virtio-win-0.1.229.iso,index=1,media=cdrom</code></pre> 最初はインストール先のドライブが見えないですが、ドライバーの読み込み→E:ドライブ→amd64→win10ディレクトリを選択しOKを押すと、virtioドライバが読み込まれ、ドライブ0が見えるようになります。 </li> Windows10のインストールメディアにはいくつかのバージョンのWindowsが入っており、プロダクトキーの入力をスキップすると、インストールするバージョンを選択できるようになります。HomeかProかをそこで選択します。 </li> Windowsのインストールを進めると、Microsoftアカウントへのサインインを求められますが、ローカルアカウントを作成し次に進めます。 </li> ローカルアカウント作成の選択肢が提示されない場合は、メールアドレスにno@thankyou.com、パスワードに適当な文字列を入力するといったんサインインに失敗し、ローカルアカウント作成ができるようになるようです。 </li> 上記の仮想マシン起動コマンドではネットワークの設定を行っていないので、いずれにせよWindowsサインインは行われないはずです。 </li> Windowsセットアップ完了後、Windows上でE:ドライブ（virtio-win-0.1.229）を開きます。そこにあるインストーラを起動し、virtioドライバをインストールしておきます。 </li> </ul> 以上で、Windows10がインストールされたKVM用のqcow2イメージができあがります。 仮想マシンの利用</h2> ライセンス認証</h3> 基本的に仮想マシン一台ごとにライセンスが必要ですので、仮想マシンのWindows上でプロダクトキーを入力し、ライセンス認証を行います。Windowsを消し、Linuxをインストールしたノートパソコン上では、プリインストールしてあったWindowsのプロダクトキーが利用可能であると思われます。しかし、あまり不正確なことはここに書けないので参考にしたリンクのみを以下に示します。 http://blog.yottun8.com/archives/794 </li> https://orebibou.com/ja/home/201905/20190527_001/ </li> </ul> https://superuser.com/questions/1313241/install-windows-10-from-an-unbooted-oem-drive-into-virtualbox https://gist.github.com/Informatic/49bd034d43e054bd1d8d4fec38c305ec</li> </ul> ホストLinuxのネットワーク設定</h3> 仮想マシンのネットワーク接続についてはいくつもやり方があります。私の場合、ゲストOSがWindowsであるかLinuxにあるかに関わらず、以下の方式を好んで利用しています。 仮想マシン用のブリッジを予め作成しておき、仮想マシンの起動時にそこにアタッチする。 </li> 外部へはSNAT(MASQUERADE)で接続する。 </li> ネットワークアドレスは、10.0.0.0/24を利用する。 </li> 仮想マシン上ではその帯域の固定IPを利用する。 </li> DNSサーバは、ホストOSが使っているのと同じもの利用する。 </li> </ul> ブリッジインターフェースの作成は、Linuxのネットワーク設定ファイルに書いておき、ノートパソコン起動時に自動的に設定が行われます。 /etc/network/interfaces.d/kbr0 auto kbr0 iface kbr0 inet static bridge_ports none bridge_fd 0 bridge_maxwait 0 address 10.0.0.254 netmask 255.255.255.0 up /etc/network/masquerade.sh</code></pre> iptables natの設定 /etc/network/masquerade.sh #!/bin/bash if ! iptables -t nat -C POSTROUTING -o eth0 -j MASQUERADE > /dev/null 2>&1 ; then iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE fi</code></pre> 仮想マシン起動時に仮想マシンのネットワークインターフェースをホストLinuxのブリッジにアタッチするためのスクリプトも用意しておきます。 /etc/network/qemu-ifup #!/bin/sh bridge=kbr0 /sbin/ip link set dev $1 up promisc off /sbin/brctl addif $bridge $1</code></pre>仮想マシンの起動コマンドライン</h3> ネットワーク接続込のコマンドライン。 sudo qemu-system-x86_64 \ -machine q35,accel=kvm \ -m 8192 -cpu host \ -smp 6,sockets=1,dies=1,cores=6,threads=1 \ -display spice-app \ -rtc base=localtime,clock=host \ -drive file=./win10pro.qcow2,if=virtio,format=qcow2,discard=unmap \ -device virtio-net-pci,netdev=dev1,mac=52:54:00:11:00:12,id=net1 \ -netdev tap,id=dev1,vhost=on,script=/etc/network/qemu-ifup</code></pre> そして、仮想マシンの起動後、Windows上でIPアドレス、DNSサーバー等の設定を行います。 まとめ</h2> QEMUコマンドのみでKVM仮想マシンを起動し、Windows10をインストールする方法についてまとめました。ネット上にはvirshコマンドラインや、virt-managerのGUIでのインストール方法はよく見かけますが、qemuコマンドのみでのやり方はあまり多くないようです。余計なものはなるべくインストールしたくない人、ソフトウェアスタックをミニマムにして中身を理解しながら使いたい人のお役に立てば幸いです。 社外からSOCKS5プロキシ経由でRemoteDesktop接続 2021-01-22T00:00:00+00:00 SOCKS5トンネル掘り hirakegoma.sh #!/bin/bash while true; do echo "Connecting gw.example.com:22 ... " ssh -4ND 18888 gw.example.com -p 22 sleep 1 echo retrying done</code></pre> xfreerdpのラッパースクリプト 社内(≈名前解決可能)なら直接、そうでないならSOCKS5プロキシ経由でRDP接続する。 rdp.sh #!/bin/bash case "$1" in host1) user=user1 host=host1.inside.example.com ;; host2) user=user2 host=host2.inside.example.com ;; *) echo Usage $1 host_nick_name exit esac if host $host ; then echo Connecting $user@$host xfreerdp /u:$user /size:1400x900 /v:$host else echo Connecting $user@$host via SOCKS proxy xfreerdp /u:$user /size:1400x900 /v:$host /proxy:socks5://localhost:18888 fi</code></pre> SSH踏み台サーバを経由して社内サーバにアクセスする 2021-01-21T00:00:00+00:00 最近のリモートワークの状況下で自宅から職場のサーバにアクセスしなければならないことも多いと思います。 VPNを使ったり、OAuth付きのproxyサーバを立てたり、いろいろとやり方があると思います。今回はSSHの踏み台サーバ経由で職場内のWEBサーバにアクセスする方法について、やり方を記録して置こうと思います。 昔から、1. SSHのダイナミックフォワードでトンネルを掘る、2. ブラウザにproxy.pacを読ませて特定の(社内サーバ)URLのみにそのトンネルを使わせる、といった方法は利用していましたが、あるバージョンを境にChromeでproxy.pacファイルを読まなくなってしまい、放置していました。 今回改めてやり方を調べてみたというのが背景です。 トンネル掘り トンネルにはSSHのダイナミックフォワードを使います。例えば以下のような感じ。 hirakegoma.sh #!/bin/bash while true; do echo "Connecting gw.example.com:22 ... " ssh -4ND 18888 gw.example.com -p 22 sleep 1 echo retrying done</code></pre> 職場内のサーバ、xxx.inside.example.comへのアクセスを上で作ったトンネルを経由させるには、例えば以下のようにすれば良い。 proxy.pac function FindProxyForURL(url, host) { if (dnsDomainIs(host, ".inside.example.com")) if (isResolvable(host)) return "DIRECT"; else return "SOCKS5 localhost:18888"; else return "DIRECT"; }</code></pre> 会社内ではサーバ名前解決ができるであろうから、名前ができないときのみトンネルを通すようになっている。 Chrome起動オプション Chromeでproxy.pacのありかを指定するには、システムの環境設定でやればいいらしい。残念なことにLinuxの場合にはそういうわけにもいかず、Chrome起動時にオプションを引数として渡してあげる必要がある。 以前は以下のような感じでうまく行っていた。 google-chrome %U --proxy-pac-url=file:///home/ktaka/proxy.pac</code></pre> 最近は"--proxy-pac-url=f"でファイルを指定しても無視されてしまうようなので、ワークアラウンド</a>が必要である。 結局行き着いたのが以下のオプション。 google-chrome %U --proxy-pac-url='data:application/x-javascript-config;base64,'$(base64 -w0 /home/me/proxy.pac)</code></pre> 最近のサーバやワークステーションは、BMCというミニプロセッサが載っていて、Webブラウザー経由で電源のオンオフ、ハードリセット、BIOS設定の変更などができます。 今回のような簡易プロキシを使うことによって、これらの職場内にあるサーバに、外部から簡単にアクセスすることができるようになります。 BMC搭載の高性能なワークステーションはこちらをどうぞ→AMD Ryzen™ Threadripper™ ECCメモリ IPMI搭載ワークステーション</a> Debian Linuxのノートパソコンでハイバネート 2021-01-17T00:00:00+00:00 Linuxカーネルには、スワップ領域にメモリの内容を書き出してハイバネートする機能がある。必要な要件等は以下の通り。 十分な大きさのスワップデバイスまたはファイルを用意する。(メモリ容量と同じくらいあれば良いが、そこまでなくても良いという情報もある。)</li> カーネル起動オプションresume=デバイス名を加えカーネルを起動。</li> uswsuspを利用することもできるが、利用しなくても良い。その場合initrdをいじる必要は無い。</li> </ul> 参考文献 https://wiki.archlinux.jp/index.php/サスペンドとハイバネート</a></li> https://www.kernel.org/doc/Documentation/power/states.txt</a></li> https://www.kernel.org/doc/html/latest/power/basic-pm-debugging.html</a></li> </ul> 以下、実際の設定 /etc/fstab (該当部分のみ) #/dev/nvme0n1p7 swap swap defaults 0 0 /swapfile swap swap defaults 0 0</code></pre> デバイスをスワップとして使う場合と、ファイル(/swapfile)をスワップとして使う場合とで必要なカーネルパラメータが異なる。後者の場合はresume_offsetも必要。オフセット値は以下のように確認可能。この場合86093824がオフセット値。 sudo filefrag -v /swapfile Filesystem type is: ef53 File size of /swapfile is 17179869184 (4194304 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 2047: 86093824.. 86095871: 2048: 1: 2048.. 4095: 86167552.. 86169599: 2048: 86095872: 2: 4096.. 8191: 86155264.. 86159359: 4096: 86169600: 以下略</code></pre> /boot/grub/grub.cfg (該当部分のみ) menuentry "Debian Linux resume-test1" { linux /boot/vmlinuz root=/dev/nvme0n1p6 vga=0x305 panic=10 net.ifnames=0 biosdevname=0 resume=/dev/nvme0n1p7 } menuentry "Debian Linux resume-test2" { linux /boot/vmlinuz root=/dev/nvme0n1p6 vga=0x305 panic=10 net.ifnames=0 biosdevname=0 resume=/dev/nvme0n1p6 resume_offset=86093824 }</code></pre> ノートパソコンのディスプレイを閉じたときにhibernateする設定 /etc/acpi/events/lid_down event=button[ /]lid action=/etc/acpi/lid_down.sh</code></pre> /etc/acpi/lid_down.sh #!/bin/sh grep -q closed /proc/acpi/button/lid/*/state if [ $? -eq 0 ] then echo platform > /sys/power/disk ; echo disk > /sys/power/state fi exit 0</code></pre> 以上で、ハイバネートできることを確認した。 Debian LinuxのノートパソコンでドトールWiFiにつなぐ 2021-01-15T00:00:00+00:00 ドトール、エクセルシオールカフェには無料のWiFiサービスがある。Linuxで接続するのにちょっと手間取ったので、やり方をメモしておく。 設定ファイルを作成。 /etc/network/interfaces.d/doutor iface dt inet dhcp wpa-ssid "DOUTOR_FREE_Wi-Fi" wpa-key-mgmt NONE</code></pre> インターフェースをアップするとDHCP経由でアドレスの取得ができる。 ktaka@dyna:~$ sudo ifup wlan0=dt Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/wlan0/3c:9c:0f:8d:c8:4a Sending on LPF/wlan0/3c:9c:0f:8d:c8:4a Sending on Socket/fallback DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14 DHCPOFFER of 10.68.161.211 from 10.68.128.2 DHCPREQUEST for 10.68.161.211 on wlan0 to 255.255.255.255 port 67 DHCPACK of 10.68.161.211 from 10.68.128.2 bound to 10.68.161.211 -- renewal in 138 seconds.</code></pre> このあとブラウザで任意のページを閲覧しようとするとWEBの認証ページが表示されるので、承諾すればネットワークが使用可能になる。 Dynabook GZ83/MLにDebian Linuxをのせて使ってます。 2021-01-15T00:00:00+00:00 先日購入したノートパソコンのご紹介です。 ちまたではM1 Macbook Air/Proの評判が高いようですが、920gの12インチMacbookが出なかったことに落胆し、軽量なノートパソコンを購入してしまいました。 M1 Macの性能がものすごく高いようなので、失敗したかなと思いつつも、でもAirといっても1.3kgもあったら持って歩けないよなぁとか、やっぱり悩みつつもLinuxを日頃から触るのは楽しいよなぁとか、自分に言い聞かせながら悶々とした日々を過ごしております。 Macbook Airとても良いんですけどね、重くなければ。 そして購入したノートパソコンがこれ。Dynabook GZ83/ML。https://dynabook.com/direct/pc/catalog/2020-spring/gz83m/spec.html</a> 洒落っ気も何も無いですけど、とにかく軽くて、そこそこ良いCPU積んでるんです。 仕様はこのページ</a>にあるとおりですが、特に気に入ってる点は、 6コアCore i7 CPU、16GBメモリ、512GB NVMe SSD、859gという軽さなどです。 あと1GNICやHDMIのコネクタが最初からついていたり、USB Type-C PDで充電できたりするのも、とても便利です。 OSはもちろん、Debian Linuxにしてるんですけど、今回はWindowsもデュアルブートできるようにしてあります。 会計ソフトやNovaのお茶の間留学のソフトなんかが、Windowsじゃないと動かないので、仕方なく残している感じです。 デュアルブートも昔からありますが、最近のノートパソコンはBiosがUEFI化されていて、ちょっと昔とは勝手が違っていたりしました。 その辺りも、追々ブログにまとめられたらと思います。 pingが通らない時 2020-11-25T00:00:00+00:00 pingができなくなるのは、うっかりファイルシステムをコピーした際にcapabilityを落としてしまったことが原因であることもあるらしい。 rsyncやtarでファイルシステムごとコピーする際は、--xattrsを忘れずに。 pingが通らない。 $ ping str ping: socket: Address family not supported by protocol $ ping -4 str ping: socket: Operation not permitted</code></pre> capabilityの確認。何も付いてない。 $ sudo getcap /bin/ping</code></pre> capabilityの付与と確認。 $ sudo setcap cap_net_raw=ep /bin/ping $ sudo getcap /bin/ping /bin/ping = cap_net_raw+ep</code></pre> "cap_net_raw+ep"が付与された。 そしてping通るようになった。 $ ping str PING stretch.h.ccmp.jp (192.168.60.3) 56(84) bytes of data. 64 bytes from stretch.h.ccmp.jp (192.168.60.3): icmp_seq=1 ttl=64 time=6.89 ms 64 bytes from stretch.h.ccmp.jp (192.168.60.3): icmp_seq=2 ttl=64 time=3.100 ms 64 bytes from stretch.h.ccmp.jp (192.168.60.3): icmp_seq=3 ttl=64 time=3.53 ms</code></pre> 以下ちょっと実験する際などに役立つコマンド達 capability, xattrの確認コマンド、何もない時 # getcap /bin/ping # getfattr -n security.capability /bin/ping /bin/ping: security.capability: No such attribute # sudo getfattr -d /bin/ping # sudo attr -l /bin/ping</code></pre> capability, xattrの確認コマンド、権限がちゃんと付与されている時 # getcap /bin/ping /bin/ping = cap_net_raw+ep # attr -l /bin/ping Attribute "capability" has a 20 byte value for /bin/ping # getfattr -n security.capability /bin/ping getfattr: Removing leading '/' from absolute path names # file: bin/ping security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=</code></pre> xattrごと削除するコマンド # setfattr -x security.capability /bin/ping</code></pre> 参考文献 https://man7.org/linux/man-pages/man5/attr.5.html</a></li> tarの場合 --xattrsを付ける https://www.gnu.org/software/tar/manual/html_node/Extended-File-Attributes.html</a></li> rsyncの場合も --xattrs, -Xを付ける https://man7.org/linux/man-pages/man1/rsync.1.html</a></li> https://wiki.archlinux.org/index.php/capabilities</a></li> </ul> LinuxでのSLAAC IPv6アドレス自動設定 2020-05-17T00:00:00+00:00 Linuxにおいて、SLAACによるIPv6アドレスアサインにはいくつかのモードがあり、以下のカーネルパラメータをセットすることで制御できるようです。 addr_gen_mode - INTEGER Defines how link-local and autoconf addresses are generated. 0: generate address based on EUI64 (default) 1: do no generate a link-local address, use EUI64 for addresses generated from autoconf 2: generate stable privacy addresses, using the secret from stable_secret (RFC7217) 3: generate stable privacy addresses, using a random secret if unset</code></pre> モード２のRFC7217形式を利用するためには以下のように、stable_secretをあらかじめセットしておく必要があります。 stable_secret - IPv6 address This IPv6 address will be used as a secret to generate IPv6 addresses for link-local addresses and autoconfigured ones. All addresses generated after setting this secret will be stable privacy ones by default. This can be changed via the addrgenmode ip-link. conf/default/stable_secret is used as the secret for the namespace, the interface specific ones can overwrite that. Writes to conf/all/stable_secret are refused. It is recommended to generate this secret during installation of a system and keep it stable after that. By default the stable secret is unset.</code></pre> https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt</a> モード0:</h4> RFC4291</a>形式のアドレスを自動生成します。 # echo 0 > /proc/sys/net/ipv6/conf/eth0/addr_gen_mode # ifdown eth0; ifup eth0 # ip -6 add show dev eth0 4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 fd00::40:c23f:d5ff:fe69:4af3/64 scope global dynamic mngtmpaddr valid_lft 86383sec preferred_lft 14383sec inet6 fe80::c23f:d5ff:fe69:4af3/64 scope link valid_lft forever preferred_lft forever</code></pre> IPv6アドレスはRAから得られたPREFIX(fd00::40/64)と、MACアドレス(c0:3f:d5:69:4a:f3)を変換したEUI64アドレス(c23f:d5ff:fe69:4af3)から生成されていることがわかります。 モード1:</h4> アドレスを自動生成しません。 # echo 1 > /proc/sys/net/ipv6/conf/eth0/addr_gen_mode # ifdown eth0; ifup eth0 # ip -6 add show dev eth0 #</code></pre>モード2:</h4> Semantically Opaque Interface Identifiers(SOII, RFC7217</a>)形式のアドレスを自動生成します。 # echo "::" > /proc/sys/net/ipv6/conf/eth0/stable_secret # echo 2 > /proc/sys/net/ipv6/conf/eth0/addr_gen_mode # ifdown eth0; ifup eth0 # ip -6 add show dev eth0 4: eth0: mtu 1500 state UP qlen 1000 inet6 fd00::40:c81b:6763:31dc:887a/64 scope global dynamic mngtmpaddr stable-privacy valid_lft 86398sec preferred_lft 14398sec inet6 fe80::df74:fff4:bdf2:e8ae/64 scope link stable-privacy valid_lft forever preferred_lft forever</code></pre> IPv6アドレスはRAから得られたPREFIX(fd00::40/64)と、RFC7217</a>に定められた方式で計算されるランダム識別子から生成されます。ランダム識別子は次のような関数から計算されsecret_keyに変更がなければ(すなわちstable_secretがセットされていれば)、毎回同じものになります。 RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)</code></pre>モード3:</h4> Semantically Opaque Interface Identifiers(SOII, RFC7217形式のアドレスを自動生成します。stable_secretがセットされている場合にはモード2と同じアドレスを生成し、されていない場合にはrandom secretを用いアドレスを生成します。 # echo 3 > /proc/sys/net/ipv6/conf/eth0/addr_gen_mode # ifdown eth0; ifup eth0 # ip -6 add show dev eth0 4: eth0: mtu 1500 state UP qlen 1000 inet6 fd00::40:73be:87b2:8746:6bb3/64 scope global dynamic mngtmpaddr stable-privacy valid_lft 86395sec preferred_lft 14395sec inet6 fe80::ddae:cc16:47e0:156d/64 scope link stable-privacy valid_lft forever preferred_lft forever</code></pre> モード2との違いは、stable_secretがセットされていない場合に、毎回異なるランダム識別子からIPv6アドレスが生成されるということです。 addr_gen_modeのパラメータは以下のコマンドでもセットできるようです。 ip link set dev eth0 addrgenmode { eui64 | none | stable_secret | random }</code></pre>参考文献</h4> 「クライアントOSのIPv6実装検証から見たネットワーク運用における課題の考察」 https://www.ipsj.or.jp/dp/contents/publication/36/S0904-R1701.html</a> 「TIPS: 拡張EUI-64を使わないIPv6アドレス生成」 http://www.drvlabo.jp/wp/archives/1713</a> LinuxルーターでのDS-Lite設定 2020-05-05T00:00:00+00:00 昨日に引き続き、自宅のLinuxルーター上でDS-Liteの設定を行いました。 BB.exciteコネクト(IPoE接続プラン)ではIPv6回線のトンネルを通して、インターネットにIPv4接続することが可能です。 実際のサービスはtransixのDS-Liteを使うことになるのですが、この回線を使うことで混み合っているNGNの網終端を通らずに済むことになるので、快適なネットライフが待っているらしいのです。 ところが我が家ではすでにPPPoEでのIPv4の固定IP契約があり、その固定IPをVPN、DNSサーバなどいろいろなサービスに使っていて、別のIPアドレスに変わってしまって困ります。またDS-Liteの場合にはグローバルIPアドレスを複数のユーザーで共有して使うので、なおさら外部からのアクセスなどには使うことができません。そういった理由で、IPv4に関しては既存のPPPoEのままにするつもりでいました。 しかしながらWebページの閲覧やYutubeコンテンツの視聴に使われるHTTPやHTTPSに限れば固定IPは不要です。また、Linuxルーターの場合には、宛先のIPやプロトコル、ポート番号に応じてきめ細かく接続先の経路を選ぶことができます。そこで、せっかくなので今回、HTTPとHTTPSに限って、DS-Liteの経路を利用する設定を試してみました。 IPv4 over IPv6のトンネルセットアップ ip -6 tunnel add dslite mode ip4ip6 \ remote 2404:8e00::feed:100 local 2409:x:x:x::1 dev eth0.10 ip link set dev dslite up</code></pre> 宛先が192.168.0.0/16以外(宛先がWAN向き)で、宛先ポート80、443のパケットにマークをつける。 iptables -A PREROUTING -i eth0 -t mangle \ ! -d 192.168.0.0/16 -p tcp --dport 443 -j MARK --set-mark 1 iptables -A PREROUTING -i eth0 -t mangle \ ! -d 192.168.0.0/16 -p tcp --dport 80 -j MARK --set-mark 1</code></pre> マークがついているパケットだけDS-Liteのトンネルを通るようにする。 ip route add default dev dslite table 100 ip rule add from all fwmark 1 table 100 prio 100</code></pre> これで自宅LAN内の任意のマシンからDS-Lite回線をHTTP、HTTPS接続できるようになりました。 経路が変わっているかどうかは、WEB上にあるアクセス元IPを判別するページ(例えばここ</a>)などで確認可能で、ちゃんと切り替わっていることが確認できました。 いままで回線の遅さに悩んでいましたが、これで解決されるのか楽しみです。 LinuxルーターでのIPv6 IPoE設定 2020-05-04T00:00:00+00:00 こんにちは、コロナの影響でステイホームでリモートワークを励行しています。多くの人たちが業務のために自宅からインターネットにアクセスしたり、外に遊びに行けず自宅でネットコンテンツを長時間視聴するためか、日時を問わずNTTフレッツ回線のネットワークが非常に遅くなっているような気がします。 フレッツ回線の混雑の情報をネットで調べてみると、もともと回線設備の容量が少なめで、主にIPv4のPPPoE接続で利用しているNTTのNGNの網終端装置で回線が混み合っているのではないかということです。 (https://eng-blog.iij.ad.jp/archives/5536</a> http://enog.jp/wp-content/uploads/2018/08/20180720-ENOG51-Kashiwazaki.pdf</a>) これを回避するには比較的空いているIPv6の接続口を利用するのが良いとのことでした。NTTのNGNネットワークとインターネットの境界の設備は、NTTの方針に依存せず増強できるとのことです。 そこでIPv6 IPoE + DS-Lite なプロバイダと契約し、もともと自宅で利用していたLinuxルーターをIPv6に対応させました。 今回契約したのはBB.exciteコネクト(IPoE接続プラン)というもので、既存のフレッツ回線に月々700円(税抜)追加でIPv6のインターネット接続を利用できるようになります。 https://bb.excite.co.jp/norikae/ipoe/</a> ちなみに、本題から外れますが、我が家のルーターは手のひらサイズのIntelのNUCです。NICが一個しかついていないため、eth0からTag VLANを利用してeth0.10のインターフェースを仮想的に作りWAN側に用いています。eth0とeth0.10を後述のコマンド例で使いますが、前者が内側、後者が外側ということです。 ちなみに、ルーターのOSはDebian Busterをtarで固めたものをUSBメモリに入れ、起動時にtmpfsに展開して、ディスクレスで運用しています。こうすることで、万が一NUCが壊れたとしても適当なパソコンをルーターとしてブートすることが可能です。 WANインターフェースの設定</h3> IPv6の世界では、Stateless Address Auto-Configuration(SLAAC)という仕組みがあり、基本的に何もしなくてもIPv6アドレスがアサインされます。 Linuxの場合、IPv6関連のコンフィグオプションを有効にしたカーネルがあり、かつicmpv6のパケットを送受信できる環境であれば、いつの間にか勝手にIPv6アドレスが付与されます。 今回契約したのBB.exciteコネクト(IPoE接続プラン)は、transixというVirtual Network Enabler(VNE)が実際の通信サービスを提供しており、transixから払い出された/64のプリフィックスがアドバタイズ(Router Advertisement (RA))され、それを受信したLinuxカーネルが、自動的にネットワーク設定を行います。 RAの内容はこのような感じになっています。 # /bin/rdisc6 -1 -r 3 eth0.10 Soliciting ff02::2 (ff02::2) on eth0.10... Hop limit : 64 ( 0x40) Stateful address conf. : No Stateful other conf. : Yes Mobile home agent : No Router preference : medium Neighbor discovery proxy : No Router lifetime : 1800 (0x00000708) seconds Reachable time : 300000 (0x000493e0) milliseconds Retransmit time : 10000 (0x00002710) milliseconds Source link-layer address: 00:yy:yy:yy:53:C3 MTU : 1500 bytes (valid) Prefix : 2409:x:x:x::/64 On-link : Yes Autonomous address conf.: Yes Valid time : 2592000 (0x00278d00) seconds Pref. time : 604800 (0x00093a80) seconds from fe80::y:y:y:53c3</code></pre> (参考: https://hirose31.hatenablog.jp/entry/20060418/1145354566</a> ) 上記のRAに基づいて自動的に設定されたIPアドレスの様子。 eth0.10@eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether c0:3f:d5:69:6f:b0 brd ff:ff:ff:ff:ff:ff inet6 2409:x:x:x:y:y:y:6fb0/64 scope global dynamic mngtmpaddr</code></pre> 同時に登録されるルーティング情報。 2409:x:x:x::/64 dev eth0.10 proto kernel metric 256 pref medium default via fe80::y:y:y:53c3 dev eth0.10 proto ra metric 1024 expires 1784sec hoplimit 64 pref medium</code></pre> SLAACによりアサインされるアドレスは、transixから払い出されたプリフィックス (2409:x:x:x::/64)とNICのMACアドレスを組み合わせたものです。 このようなIPv6アドレスを用いるとMACアドレスが一意であるため、これを用いてユーザーの行動が追跡される可能性があるなどプライバシーの上の問題があります。 この問題に対処するためにPrivacy Extensionという仕様が公開されており、これを用いると払い出されたプリフィックスとランダムな数字を組み合わせたIPv6アドレスを利用することができます。 つまりPrivacy Extensionを有効にするとMACアドレス由来でないアドレスもインターフェースにアサインすることができるのです。Linuxの場合はuse_tempaddrというパラメータを利用します。 https://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/ch06s05.html</a> https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt</a> use_tempaddr - INTEGER Preference for Privacy Extensions (RFC3041). 1 : enable Privacy Extensions and prefer temporary addresses over public addresses. Default: 0 (for most devices) -1 (for point-to-point devices and loopback devices)</code></pre> 実際にパラメータを設定してみると、 echo 2 > /proc/sys/net/ipv6/conf/eth0.10/use_tempaddr</code></pre> Temporaryなアドレスもアサインされます。 inet6 2409:x:x:x:y:y:y:d384/64 scope global temporary dynamic valid_lft 569580sec preferred_lft 50999sec</code></pre> (追記：最近ではSemantically Opaque Interface Identifiersと呼ばれる、よりプライバシーに考慮したアドレスアサイン方式があるようなのでそれにも対応しました</a>。) LANインターフェースの設定</h3> 次にLAN側のネットワークをどうするか考えます。まず思いつくのは以下の3通りの方法です。 WANインターフェースとLANインターフェースをブリッジ接続し、WANから流れてきたRAをLANにそのまま流す。 </li> WAN側で受け取ったグローバルなプリフィックスを、radvdというプログラムでLANに再広報する。 </li> WAN側とは別のプライベートなIPv6アドレス(ユニークローカルアドレス)のプリフィックスをradvdでLANに広報する。 </li> </ul> ある程度の試行錯誤の末、上記のうち3の方法を採用することにしました。 まず1の構成では、IPv6に関してはL3レベルでネットワークが分離されていないため、やはりセキュリティ設定に不安があります。まあ要するにLAN内に自分の知らないicmpv6のパケットが入ってくること自体が気持ち悪くて受け入れられないということです。 2の構成に関しては、以下に示すような技術課題があり、とりあえず設定はできるのですが、上手いルーティング設定とSLAAC自動設定が両立できません。 WANとLANで同じプリフィックスを利用すると、ゲートウェイ上でのルーティング設定がめんどう。 </li> /64を/65に分割してつかうとSLAACが機能しない。 </li> </ul> WANで受け取ったプリフィックスを利用しLAN側のeth0にアドレスをアサインすると、ルーティングテーブルが以下のようになります。 2409:x:x:x::/64 dev eth0.10 proto kernel metric 256 expires 2591991sec pref medium 2409:x:x:x::/64 dev eth0 proto kernel metric 256 pref medium</code></pre> この場合の問題点は、2409:x:x:x::/64宛のパケットに対するルーティング設定が2行あり、eth0側にパケットを流したくても先にあるeth0.10側にパケットが流れてしまい、通信がうまくいきません。 2409:x:x:x::/64向けのパケットはeth0側に流したいので、1行目を削除すれば良いのですが、この1行目の設定は、WAN側のSLAACの自動設定により自動追加されるものなので、しばらくするとまた追加されてしまいます。 この問題を回避するために2409:x:x:x::/64で許されるアドレスレンジの内半分の2409:x:x:x:8000::/65を、LAN内プリフィックスとして利用することを試みました。ルーティングルールでは長いプリフィックスの方が優先されるので、2409:x:x:x:8000::/65宛のパケットを必ずeth0に流すことができるというもくろみです。 この方法でルーティング自体はうまくいくのですが、SLAACによる自動アドレス設定はプリフィックスが64であることが前提であるため、各マシンに手動でIPv6アドレスを設定する必要が出てきます。 つまり、IPoEで配布されるグローバルプリフィックスが/64である場合、ルーティングをきれいに動かすためにLANのプリフィックスをそれより長くすると、SLAACによるLAN内の自動アドレス設定ができなくなってしまいます。 (ひかり電話契約がある場合には/56のプレフィックスが配布されるらしいが、我が家はひかり電話では無いので/64で。。。みんな/56とか、せめて/63で配布してくれれば良いのに。) 結局、このような理由から、「2. WAN側で受け取ったグローバルなプリフィックスを、radvdというプログラムでLANに再広報する。」という方法は断念しました。 LAN側はプライベートなアドレスを利用</h3> 仕方が無いので、LAN内ではユニークローカルアドレスfd00::/8を利用する第３の方法を用いることにしました。具体的にはradvdでfd00:0:0:x::/64なプリフィックスを配布します。そうするとLAN内の様々なクライアントがSLAACにより自動的にアドレスを生成し、IPv6により通信できるようになります。 /etc/radvd.confの例 interface eth0 { AdvSendAdvert on; MinRtrAdvInterval 30; MaxRtrAdvInterval 100; prefix fd00:0:0:x::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; RDNSS fd00:0:0:x::1 { }; };</code></pre> この構成だとLAN内はグローバルIPではなく、外に出る際にMASQUERADEすることが必要になります。NATが必要無いというIPv6のメリットの一つを損なってしまいますが仕方が無いです。 考えようによっては、IPv4で慣れ親しんだ構成でもあるので、管理は難しく無いというメリットもあります。 外部からのL3フィルタリング設定も、慣れ親しんだiptableと同様に行うことができます。 ip6tables設定。 /etc/ip6t.save (使用例 /sbin/ip6tables-restore < /etc/ip6t.save) *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A POSTROUTING -o eth0.10 -j MASQUERADE # <- マスカレード設定 COMMIT *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -s fd00:0:0:x::/64 -i eth0 -j ACCEPT -A INPUT -p udp --dport 53 -j ACCEPT -A INPUT -p tcp --dport 53 -j ACCEPT -A INPUT -p ipv6-icmp -j ACCEPT -A FORWARD -d fd00:0:0:x::/64 -j ACCEPT -A FORWARD -s fd00:0:0:x::/64 -i eth0 -o eth0.10 -j ACCEPT -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT COMMIT</code></pre>外部からのアクセス</h3> SLAACにより設定されるアドレスは、NICのMACアドレスから生成されるため決して覚えやすいものではありません。"プリフィックス::1"という分かり易いアドレスをマニュアルアサインすることで、外部からのアクセスが僅かながら容易になります。 /sbin/ip add add 2409:x:x:x::1/64 dev eth0.10</code></pre> ただしtransixから払い出されるプリフィックスは固定であるという約束はありません。プリフックス変わった場合にはそれを検知してマニュアルアサインしたアドレスも付け直し、そしてDNSなどを更新する必要があるでしょう(これについてはいまのところ未実装です) 。 固定のプリフィックスを払い出してくれるISPがあったら乗り換えたいです。 </h3> </h3> IPv4をどうするか</h3> IPv4に関してはPPPoE接続の固定IPの契約が元々あるので、そのまま利用することにしました。 今回契約した、DS-Liteのサービスでは、IPv4 NATとIPIPトンネリングを利用したIPv4 over IPv6接続が利用できます。PPPoE接続をやめてこちらの経路を利用することでIPv4回線も空いている方を利用できることになりますが、グローバルなIPv4アドレスを他のユーザと共用する必要があるため、いまのところそれほど魅力を感じていません。 transixも固定IPのサービスがあるのでそれが利用可能かつ安価なISPがあれば考えたいです。(https://www.mfeed.ad.jp/transix/staticip/</a>) (追記：後日、ポリシールーティングを使ってHTTP、HTTPSの通信のみDS-Liteを使うようにしました。→こちら</a>) 別のVNEである、JPNEからも同様な、v6オプション固定IPサービスがあるようなので、こちらも安価なISPがあれば考えたいです。(https://www.jpne.co.jp/service/v6plus-static/</a>) その他の注意点</h3> Linuxボックスでipv6のフォワーディングを有効にするとルーティング情報が消えてしまい、これに悩まされました。 forwarding=1でもRouter Advertisement（RA）を受信できるようにするために、以下が必要です。 echo 1 > /proc/sys/net/ipv6/conf/all/forwarding echo 2 > /proc/sys/net/ipv6/conf/eth0.10/accept_ra</code></pre> ( http://strugglers.net/~andy/blog/2011/09/04/linux-ipv6-router-advertisements-and-forwarding/</a> ) まとめ</h3> IPv6 IPoE + DS-Lite なプロバイダと契約し、LinuxルーターのIPv6設定を行いました。WAN側アドレスはSLAACにより自動的に設定されるものを用いました。LAN側アドレスはユニークローカルアドレスを利用し、MASQUERADEとフィルタリングの設定を行いました。 今後の課題としては、(1)64より短いプリフィックスが得られるなら、LAN内もグローバルアドレスを利用したい、(2)LinuxのルーティングがSLAACと両立できるようになったら、LAN内もグローバルアドレスを利用したい、(３)固定プリフィックスが利用できるISPがあれば乗り換えたい、(4)固定グローバルIPのIPv4 over IPv6が利用可能かつ安価なISPがあれば乗り換えたい、などがあります。 Keepalivedで作るMySQLフェイルオーバーシステム 2015-12-22T00:00:00+00:00 1. はじめに</h2> この記事はMySQL Casual Advent Calendar 2015</a>の22日目のエントリです。 先日、MySQL Casual Talks</a>という勉強会で登壇してきました。その時の内容をまとめておきたいと思います。 MySQLデータベースサーバに障害が起きた時、サービスを続けるには幾つかの方法があります。障害発生時にSlaveサーバーを手作業でMasterに昇格させる方法、MySQL Utilities</a>に含まれるmysqlfailoverというユーティリティーを利用する方法などです。 今回、Keepalivedというソフトウェアと、MySQLの双方向レプリケーションを使って、ほぼ無停止でフェイルオーバーする構成を試してみたので、それについてまとめておきたいと思います。 2. システム構成</h2> db1、db2という二つのサーバで、それぞれmysqldとkeepalivedを動かします。mysqldはお互いがMasterとなる双方向レプリケーションを行います。keepalivedはそれぞれのサーバでmysqldのヘルスチェック</a>を行い、どちらかがVRRPのMasterもう一方がBackupの状態となり、MasterにVirtual IP(VIP)を付与します。上の図ではdb1が現在のVRRP Masterということになります。双方向レプリケーションを行う場合に同時に両方のサーバへの書き込みを許可すると、データの不整合や、レプリケーションの停止を引き起こしてしまうことが知られています。今回VRRPスレーブに誤って書き込みが行われないようにスレーブにreadonly=1のフラグを立てておきます。 もしdb1のmysqldが停止ししkeepalivedのヘルスチェックに失敗した場合、db1のkeepalivedはFAULTステートに移行します。一方db2のkeepalivedはVRRP Masterステートに移行しVIPが付与され、クライアントからのアクセスはdb2に向かうようになります。db2のkeepalivedがMasterに昇格する際には、スクリプトによりreadonly=0となり書き込みが可能になるようにしています</a>。 この構成では、Keepalivedを使うことで迅速かつ安定的にフェイルオーバーが実行できること、あらかじめ双方向レプリケーションが行われているので障害発生時にCHANGE MASTER をする必要がなくシンプルであることがメリットだと考えられます。 3. VRRPってなに？</h2> VRRP(Virtual Router Redundancy Protocol)は、もともと2台のルーターの冗長化のために作られたプロトコルで、RFCで規定されています。。下の図は、今回利用したKeepalived v1.2.13 が準拠しているVRRP version 2</a>の動きを説明するものです。 VRRP v2では、プライオリティに基づいてMasterとBackupサーバーが決定され、MasterのみがVRRPアドバタイズパケットを予め定められた間隔、例えば１秒間隔で送信します。Masterからのアドバタイズパケットが一定期間途切れると、BackupサーバがMasterサーバに状態遷移します。 ヘルスチェック</h4> KeepalivedのVRRPデーモンには、RFCで規定されたVRRPプロコルの機能に加え、おまけとしてヘルスチェック機能があります。これによりスクリプトでmysqldの死活を監視し、監視が失敗するとKeepalivedのステータスをFAULTに遷移させることができます。この場合プライオリティ=0のVRRPアドバタイズパケットが送信され、直ちにBackupサーバがMasterに昇格します。 以下の設定は、keepalivedの設定ファイル</a>の一部ですが１秒に一回ヘルスチェックスクリプト"/etc/keepalived/vrrp/mysqlchk.sh"を実行し、二回失敗したらFAULTステートにし、２回成功するとBACKUPかMASTERに戻しています。 vrrp_script mysqlchk { script "/etc/keepalived/vrrp/mysqlchk.sh" interval 1 ← 1秒ごとにチェック fall 2 ← 2回失敗したらFAULT rise 2 ← 2回成功でBACKUP or MASTER }</code></pre> ヘルスチェックファイル"mysqlchk.sh"の内容は、今回は次のようになっていて、ソケット経由で、"show variables like 'server_id';"に応答できるかどうかを確認しています。 mysql -S $SOCK --connect-timeout=$TIMEOUT -e "show variables like 'server_id';"</code></pre>VRRPのフェイルオーバー時間</h4> 障害時にVRRPのフェイルオーバーにかかる時間は、大まかに以下のふた通りに分けることができます。 mysqldのみ死んだ場合 </li> keepalivedがFAULTステートになりpriority=0のVRRP Advertパケットを送信します。 </li> これを受信したBACKUPステートにいるkeepalivedは直ちにMASTERに昇格します。 </li> フェイルオーバーにかかる時間は、FAULTステート遷移に必要な2秒程度です。 </li> サーバごと死んだ場合 </li> 元のサーバからのVRRPパケットが途絶え、BACKUPステートにいるkeepalivedがMASTERステートに昇格します。 </li> BACKUPステートにいるkeepalivedが状態遷移を開始する時間はVRRPプロトコルで決まっており、(3 * Advertisement_Interval) + ( (256 - Priority) / 256 )になります。 </li> VRRPアドバタイズパケットの間隔、すなわちAdvertisement_Intervalが1秒の場合は４秒程度でフェイルオーバーが完了します。 </li> </ul> 以上により、この仕組みを利用する場合、2秒または4秒程度でフェイルオーバーが完了することになり、かなり速いと言って良いのではないでしょうか。 4. 双方向レプリケーションの注意点</h2> 今回のシステム構成では、db1とdb2の間で双方向のレプリケーション構成にしています。この構成には落とし穴があるので、まず簡単にレプリケーションの仕組みをおさらいしておきたいと思います。 次の図で、db1でコミットされたトランザクションはbinlogに記録されます。binlogに記録されたトランザクションは、ネットワークを介してdb2に送られIOスレッドによりrelaylogに書き込まれ、SQLスレッドによりテーブルスペースに順次コミッされていきます。 </a></a> したがって、db1で完了したコミットはすぐにSlaveのテーブルスペースに書き込まれるわけではなく、有限時間の遅延が発生します。特にレプリケーションのSQLスレッドは、mysqld-5.6までは1スキーマに対して1スレッドでしか実行できないので、SQLスレッドによるテーブルスペースへのコミットが追いつかずrelaylogにデータが溜まっていく場合が、時々見られます。 レプリケーションが遅延している時に、VRRPのフェイルオーバーが起こると以下の図のような状態になります。relaylogに溜まっているデータはSQLスレッドにより順次コミットされていきますが、同時にクライアントからの書き込みが行われると、データに不整合が起こりレプリケーションが停止する場合があります。 </a> 今回の構成ではこれを防ぐために、フェイルオーバー時にVIPがdb2に移った時、すぐに書き込み可能な状態にするのではなく、レプリケーションの遅延がなくなるのを待っててreadonly=0をセットするようにしています。 #!/bin/bash SOCK=/var/run/mysqld/mysqld.sock while true ; do mysql -S $SOCK -e "show slave status\G;"|egrep "Seconds_Behind_Master: 0|Seconds_Behind_Master: NULL" if [ "$?" = "0" ] ; then break else echo Waiting until sql thread finish. fi sleep 1 done mysql -S $SOCK -e "set @@global.read_only=0;"</code></pre>5. まとめ</h2> 今回、keepalivedのVRRP機能と、MySQLの双方向レプリケーションを組み合わせた、MySQLサーバの冗長化について試してみました。 良いところ およそ4秒以内、ほぼ瞬時にフェイルオーバーする。 </li> フェイルオーバー時にレプリケーション関連のオペレーションが入らないので、シンプルである。 </li> </ul> 課題 マルチマスターなので不整合に気をつける </li> repが遅いとなかなか昇格できない。MySQL5.7に期待。 </li> </ul> マイKVM環境を晒しておきます。My Jessie on Jessie KVM environment. 2015-10-29T00:00:00+00:00 皆さん、こんにちは。もうすっかり秋ですね。 最近、寒暖差が激しいので、お体には気をつけてくださいね。 さてさて、本日は、弊社で使っているDebian Jessie用のKVM環境をご紹介します。 KVMとはKernel Virtual Machineの略で、Linuxのカーネルで実装された仮想マシンハイパーバイザーのことです。一般的には、ハイパーバイザー自体を指すよりも、それを用いた仮想マシンの方式のことを指す場合も多いかと思います。 弊社ではKVMによる仮想環境を用い、各種サーバプログラム、WEBクラスターなどの検証を行っています。最近のLinuxディストリビューションでは、すでに簡単な操作で仮想マシンを立ち上げることが可能です。しかし、kvmが最初にバニラカーネルに組み込まれたlinux-2.6.20の頃から自家製スクリプトでkvm仮想マシンを利用しており、それが使い易く、興味を持ってくれる人もいるかもしれないのでここに公開する次第です。 仮想マシンの抽象化ライブラリであるlibvirtを介さずGUIなども無いので、比較的仕組みが理解しやすくカスタマイズが簡単であることがメリットかと考えています。カーネルの最新機能や最新のqemuに追従することもたやすくできます。 それでですね、ものはここにおいてあります。 https://github.com/ktaka-ccmp/kvm-setup-jessie</a> Debian jessieで以下のように、 sudo apt-get install make aptitude git -y git clone git@github.com:ktaka-ccmp/kvm-setup-jessie.git sudo make all</code></pre> gitとmakeとaptitudeをaptでインストール </li> githubからツールをクローン </li> make allする </li> </ul> を行えばオッケーです。busyboxとkernelのコンパイル時にmenuconfig画面が表示されますが、通常はそのままExitしてください。 何か思うところがあってカスタマイズしたい場合は、そこでカスタマイズを行ってください。 仮想マシンの実行は、/kvm/sbin/kvmスクリプトで行います。中身を見てもらえばわかりますが、このスクリプトでやっていることは、qemuコマンドの実行と、unix domainソケットを通してのqemuプロセスの制御です。 ではまず、v001という仮想マシンを起動してみます。 root@jessie64:~# kvm create v001 booting v001 ....</code></pre> v001が生きているかどうかは、次のように確認できます。 root@jessie64:~# kvm chk v001 QEMU 2.4.0.1 monitor - type 'help' for more information (qemu) info status VM status: running (qemu)</code></pre> 次にv002を起動し、状態を確認してみます。 root@jessie64:~# kvm create v002 booting v002 .... root@jessie64:~# kvm chk v002 QEMU 2.4.0.1 monitor - type 'help' for more information (qemu) info status VM status: running (qemu)</code></pre> 稼働中の仮想マシンの一覧は、以下のように確認できます。conのカラムはコンソールソケット、monのカラムはモニターソケット、imgのカラムはVMのイメージファイルの状態を表しています。v001の行を見るとv001 o o uとなっていますが、これはコンソール、モニターの両ソケットが接続可能で、イメージファイルが使用中(VMが稼働中)であることを表しています。 root@jessie64:~# kvm list id con mon img test - - - v001 o o u v002 o o u</code></pre> 今度は、v001のコンソールに接続してみます。コンソールに接続するとログインプロンプトが表示されるのでroot/rootでログインします。rootのパスワードはMakefileにベタ書きしてあり、イメージtemplate作成時に設定されます。コンソール接続を終了するには"Ctrl+]"をタイプします。 root@jessie64:~# kvm con v001 Debian GNU/Linux 8 v001 ttyS0 v001 login: root Password: Linux v001 4.2.4-64kvmg01 #1 SMP Wed Oct 28 03:50:51 UTC 2015 x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@v001:~# logout Debian GNU/Linux 8 v001 ttyS0 v001 login:</code></pre> テンプレートイメージ作成時には、/root/.ssh/authorized_keysもコピーしていますので、ホストのマシンと同じ鍵でsshログインすることが可能です。 v001のIPアドレスはinitrdの中で172.16.1.1を決め打ちで設定しています。v002の場合は172.16.1.2、v250の場合は172.16.1.250が割り当てられ、v250を上限にしてあります。 これらのホスト名、IPは、セットアップ時にホストの/etc/hostsに追記してあります。 root@jessie64:~# ssh v001 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Thu Oct 29 16:42:31 2015 from 172.16.1.254 root@v001:~#</code></pre> ゲストマシンからは、ホストマシンのNATを介して外部のネットワークと通信が可能です。 root@v001:~# ping yahoo.jp PING yahoo.jp (183.79.227.111) 56(84) bytes of data. 64 bytes from yjpn110.mobile.vip.ogk.yahoo.co.jp (183.79.227.111): icmp_seq=1 ttl=54 time=13.2 ms 64 bytes from yjpn110.mobile.vip.ogk.yahoo.co.jp (183.79.227.111): icmp_seq=2 ttl=54 time=13.3 ms 64 bytes from yjpn110.mobile.vip.ogk.yahoo.co.jp (183.79.227.111): icmp_seq=3 ttl=54 time=13.9 ms ^C --- yahoo.jp ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 13.224/13.515/13.986/0.349 ms</code></pre> また、同じホスト上の仮想マシン間で通信することも可能です。 root@v001:~# ping v002 PING v002 (172.16.1.2) 56(84) bytes of data. 64 bytes from v002 (172.16.1.2): icmp_seq=1 ttl=64 time=1.33 ms 64 bytes from v002 (172.16.1.2): icmp_seq=2 ttl=64 time=1.89 ms 64 bytes from v002 (172.16.1.2): icmp_seq=3 ttl=64 time=5.51 ms ^C --- v002 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 1.331/2.914/5.519/1.856 ms</code></pre> 別ホストからは、直接仮想マシンにアクセスできないようになっていますので、別ホスト上の仮想マシンとは通信できません。もしそうしたい場合は、ブリッジとvlanの設定を工夫することで、通信可能になるでしょう。 仮想マシンを停止したいときは、仮想マシンにログインしpoweroffを実行するか、以下のようにshutdownコマンドを発行します。 root@jessie64:~# kvm shutdown v001 QEMU 2.4.0.1 monitor - type 'help' for more information (qemu) system_powerdown (qemu) root@jessie64:~# kvm chk v001 2015/10/29 17:04:52 socat[17586] E connect(5, AF=1 "/kvm/monitor/v001.sock", 24): Connection refused</code></pre> kvm listコマンドで見ると、停止しているv001は以下のように見えます。 root@jessie64:~# kvm list id con mon img test - - - v001 - - - v002 o o u</code></pre> v001のイメージを完全に消したいときは、仮想マシンが停止した状態で、/kvm/data/v001.imgを消してください。 だいたい使い方は以上になります。 どうぞ、よろしくお願いいたします。 Lessons of Steve Jobs: Guy Kawasaki at TEDxUCSD の要点 2015-10-18T00:00:00+00:00 Guy Kawasakiのもう一つのビデオ"Lessons of Steve Jobs" 2013年UCSDでのTEDx です。 May he rest in peace, but may his influence continue to inspire us. Experts are clueless. Listen to your heart. </li> Customer cannot usually tell you what they want. </li> Get the next curve. </li> Big challenges beget the best work. </li> Design counts. </li> Use big graphics and big fonts. </li> Changing your mind is sign of intelligence. </li> Value not equal to price. </li> A players hire A+ players. </li> Real CEOs demo. </li> Real entrepreneurs ship. </li> Marketing = unique value. </li> </ul> Bonus: Some things need to be believed to be seen. I can tell you right now. In heaven Steve Jobs is telling God what to do. The art of innovation | Guy Kawasaki | TEDxBerkeley の要点メモ 2015-10-18T00:00:00+00:00 こんにちは、今日はいい天気にもかかわらず、自宅に引きこもってSNS眺めたり、Youtube見てました。本当はやらなきゃいけないお仕事があったんですが ^^;) 前からちょくちょく見ていたGuy KawasakiのTalkの一つの「The art of innovation(イノベーションの技術)」分用メモです。書き出しておかないと内容忘れて何度も見る羽目になってしまうので。 Make meaning as opposed to make money. If you start off with the sole desire to make money, you won’t make money, you won’t make meaning, you won’t change the world, and you’ll probably fail. お金よりもそれをやる意味が大事。 </li> Make Mantra. Two or three explanation why your meaning should exist. Nike: authentic athletic performance, Fedex: Peace of mind, Wendy: (should be) Healthy fast food.　その意味が存在する必要を、2、３、４語のマントラにしておくと良い。 </li> Jump to the next curve. Great innovation occurs when you get to the next curve. 10%の進歩ではなく次のカーブに乗ることが大事。 </li> Roll the DICEE. Deep, Intelligent, Complete, Empowering, Elegant　深い進歩、賢さ（マスタングは鍵ごとに最高速がプログラムされいる）、完全さ（レクサス）、可能性を与えるもの（Macbook Air）、エレガントさなどの要素が必要。参考</a> </li> Don’t worry be crappy. If you waited for perfect world, you would never ship. 完璧さを求めたらいつまでたっても出荷できない。革新的なプロダクトは多少のクラッピネスを恐れずにまず出荷することが大事。 </li> Let 100 flowers blossom. One of the reasons why I believe in God is there is no other explanations for Apple’s continued survival than the existence of God. When the customer use your product if they say it’s the desktop publishing machine, haleluya, declare the victory, it is now a desktop publishing machine. Positioning branding ultimately comes down to what the customer decides, not to what you decides. マックはワープロ、スプレッドシート、データベースではダメだったけど、DTPマシンとして成功した。ポジショニング、ブランディングは究極的には、顧客が決めるものである。 </li> Polarize people.The great product polarize people. Don’t be afraid of polarizing people. 偉大なプロダクトは時に敵を作るが恐れてはいけない。ただし、敵を作れと言っているのではない。 </li> Churn, baby churn. As soon as you ship the product, you need to start listening people and keep evolving the product. 出荷するまではエキスパートの声を無視しなければいけないが、出荷されたら直ちにユーザーの声に耳を傾け、商品を進化させ続けなければならない。 </li> Niche yourself. ユニーク、価値の2x2マトリックス、右上を取らなければいけない。 </li> Perfect your pitch. Customize your introduction. 10 20 30 rules of presentation. 10 slides 20 minutes 30 point fonts. ピッチのTips。イントロを聴衆に合わせてカスタマイズ。10スライド、20分のトーク、30ポイントフォント。聴衆年齢の半分のフォントサイズ。 </li> Don’t let the bozos grind you down. “I think there is a world of market for maybe five computers. Thomas Watson, IBM, 1943” 成功したbozo達の言葉に騙されるな。 </li> </ul> debian jessieをdebootstrapでインストールした時のメモ 2015-10-14T00:00:00+00:00 こんばんは。 ブログを書くのは苦手だけど、なんでもいいから書いてみようシリーズです。 会社ではディスクレスのネットブート環境を作ってあって、新しいOSをインストールする時には、まずディスクレスでOSを立ち上げそのOS上でdebootstrapやyum groupinstallなどを使ってファイルシステムの中身を作成することが多いです。あるいはディスクレスでブートして、あらかじめ作成しておいた標準システムをネットワーク越しrsyncやddでコピーしたりすることもあります。 このようにすることで、毎回ブレの少ない、あるいは全くブレのないイメージを作成することができ、非常に便利です。 今回は、ネットブートした後にDebian jessieをdebootstrapした時のメモです。 そして想定読者は、未来の自分です。（最近前にやったことをすぐに忘れてしまうので^^;） ネットブートしたOS上でやること。</li> </ol> apt.h.ccmp.jp:3142がMIRROR元のURLに挟んであるのは、apt-cacher-ngを間に挟んでaptの転送量を節約するためです。 parted /dev/sda mkfs.ext4 /dev/sda1 mkswap /dev/sda2 mount /dev/sda1 /mnt/ apt-get install debootstrap time debootstrap --include=openssh-server,openssh-client,rsync,pciutils,tcpdump,strace,libpam-systemd,ntpdate,openntpd jessie /mnt/ http://apt.h.ccmp.jp:3142/ftp.jp.debian.org/debian mount -t proc none /mnt/proc/ mount -t devtmpfs none /mnt/dev/ mount -t sysfs none /mnt/sys/ rsync -av ~/.ssh/ /mnt/root/.ssh/ vi /mnt/etc/network/interfaces vi /mnt/etc/fstab echo "root:root" | chpasswd --root /mnt/ echo "Asia/Tokyo" > /mnt/etc/timezone cp /mnt/usr/share/zoneinfo/Japan /mnt/etc/localtime chroot /mnt/</code></pre> /etc/fstabの中身 /dev/sda1 / ext4 defaults 1 1 /dev/sda2 swap swap defaults 0 0</code></pre> /etc/network/interfacesの中身 auto lo iface lo inet loopback auto eth0 #iface eth0 inet dhcp iface eth0 inet static address 192.168.60.31 network 192.168.60.0 broadcast 192.168.63.255 netmask 255.255.252.0 gateway 192.168.60.1 source-directory /etc/network/interfaces.d/</code></pre> chroot後にイメージ内でやること</li> </ol> apt-cache search linux-image apt-get install linux-image-3.16.0-4-amd64 grub-pc apt-get clean grub-install /dev/sda update-grub</code></pre> 以上で、jessieのミニマム環境がインストールできます。リブートしてちゃんと立ち上がればOKです。 そんなこんなで、立ち上がったOSの容量は。。。 root@jessie64:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/root 107G 585M 101G 1% /</code></pre> うーん、こんなもんかなー。 pppoe接続のインターフェース名を変更する　How to rename pppoe interface name. 2015-10-14T00:00:00+00:00 フレッツ回線などで、linuxルーターからpppoeセッションを張る場合、インターフェース名がppp0、ppp1などとなり、どのプロバイダへの接続なのか判別しづらく不便に感じることがあります。 # ip add show dev ppp0 8: ppp0: mtu 1454 qdisc pfifo_fast state UNKNOWN qlen 3 link/ppp inet x.x.x.x peer x.x.x.x/32 scope global ppp0 valid_lft forever preferred_lft forever</code></pre> ここで、ppp0の部分を任意の名前、例えば接続先のプロバイダ名などにしておけば便利でしょう。Debian Wheezyの場合は次のようにしてやれば、そういうことが可能です。 /etc/network/interfaces auto irevo iface irevo inet ppp provider irevo</code></pre> /etc/ppp/peers/irevo noipdefault hide-password lcp-echo-interval 20 lcp-echo-failure 3 connect /bin/true noauth persist mtu 1492 noaccomp default-asyncmap linkname "irevo" plugin rp-pppoe.so eth0.10 user "xxxxx@i-revonet.jp"</code></pre> /etc/ppp/ip-up.d/02ifrename #!/bin/bash ifrename(){ if [ "$LINKNAME" != "" ]; then ip link set $IFNAME down ip link set $IFNAME name $LINKNAME ip link set $LINKNAME up else exit fi } if [ "$IFNAME" == "$(/sbin/ip route |grep default | cut -f 3 -d " ")" ]; then ifrename /sbin/ip route add default dev $LINKNAME else ifrename fi</code></pre> 試してみると確かにインターフェース名がirevoになっていることがわかりました。 # ip add show dev irevo 5: irevo: mtu 1454 qdisc pfifo_fast state UNKNOWN qlen 3 link/ppp inet x.x.x.x peer x.x.x.x/32 scope global irevo valid_lft forever preferred_lft forever</code></pre> Debian Jessie以降ではpppdに以下のページの修正が入っていて、上記の/etc/ppp/peers/irevoで「linkname "irevo"」とあるところを「ifname "irevo"」 などに変更することで、インターフェースの名前を任意に設定することができるそうです。 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458646</a> おそらく、こちらの方がpppdが知っている名前を変えずに済み問題が少いでしょう。 早く、ルーターのOSをDebian jessieにしようと思います。 デスクトップパソコン新調 2015-10-03T00:00:00+00:00 みなさん、こんにちは。そろそろブログを書かなきゃなと思いつつ10ヶ月以上もブログ更新していないことに気づきました。もう何でもいいから書いてみようと思います(笑) 先日、会社で使っているデスクトップパソコンを新しくしました。パソコンのモデルは、IntelのNUC BOXDN2820FYKH0</a>というやつで、Celeron N2820</a>というデュアルコアHTなCPUが乗っています。このCPUはTDPがわずか7.5Wととても低消費電力で、電気代が安く済むので、各拠点のルーターとしても重宝しています。今回はルータ用に買ったあまりをデスクトップ用に転用しました。 主なインターフェースは、HDMI、1G LAN(Realtek)、usb 2.0 x2 、usb 3.0 x 1などです。他にwifi/bluetooth用のチップも内蔵しています。 OSはもちろんLinux。今回はDebian jessieをインストールしました。 最近のLinuxはインストールするだけで、特に苦労もせずXや日本語入力環境が使えるので、非常に助かります。(Macイラねんじゃね？とはいえMacbook Air愛用しておりますが…) 備忘録 chrome音が出ない件。 以下のコマンドで見ると、HDA Intel PCHというデバイスが搭載されており、ALC283とHDMIの２つの出力デバイスがある。 ktaka@jessie:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel PCH], device 0: ALC283 Analog [ALC283 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 </blockquote> 次のコマンドで、音が出るかどうか試してみるとちゃんと出る。 aplay -D plughw:0,3 /usr/share/sounds/alsa/Front_Center.wav </blockquote> 次のファイルを書き換えXを再起動したところ、chromeでyoutubeなどの音声が聞こえるようになりました。 /etc/asound.conf pcm.!default { type hw; card 0 ; device 3; } ctl.!default { type hw; card 0 ; device 3; } </blockquote> 以上、オチもまとめもないんですけど、 最近のLinuxはデスクトップとしても簡単に使えるので、皆さん使ってみましょう！ 今日の逸品 2014-11-03T00:00:00+00:00 こんにちは。三連休の最終日、お天気は快晴で絶好の行楽日和となりましたね！ 本当はどこかに出かけるか、外で思いっきりスポーツでもしたいところですが、某代理店さんからお借りしている最新の超高性能デバイスを本日中に返送しないといけないので、休日返上でブログを書きながらレポートしたいと思います(^^;) まずは、写真をと。。。。じゃじゃーん！今日の逸品はこちらです！ IntelのPCI express typeのSSD DC P3700です。大きなヒートシンクに囲われていて、かっこいいですね！まあ、どんだけ熱くなるんだってお話もありますが。。。 裏面も、NANDチップがびっしりです。どんだけ大容量なんだ！ どうやら1.6TBのようです！！ こんな風に、サーバのPCIeスロットに装着します。ちょっと、見えづらいかも知れませんが、この1Uサイズのサーバは、PCIeスロットが二段になっていて、上段がP3700、下段がLSI RAIDカードとなっています。 インテル® Solid-State Drive DC P3700 シリーズのカタログスペックは、こんな感じです。 容量 </th> Sequencial Read/Write [MB/s]</th> 4KB Random Read / Write [IOPS]</th> 8KB Random Read / Write [IOPS]</th></tr></thead> 400 GB</td> 2,700 / 1,080</td> 450,000 / 75,000</td> 275,000 / 32,000</td></tr> 800 GB</td> 2,800 / 1,900</td> 460,000 / 90,000</td> 285,000 / 45,000</td></tr> 1.6 TB</td> 2,800 / 1,900</td> 450,000 / 150,000</td> 290,000 / 75,000</td></tr> 2.0 TB</td> 2,800 / 2,000</td> 450,000 / 175,000</td> 295,000 / 90,000</td></tr> </tbody></table> ( http://www.intel.co.jp/content/www/jp/ja/solid-state-drives/intel-ssd-dc-family-for-pcie.html</a> こちらのページより抜粋 ) シーケンシャルのリード/ライトが2.8GB/s、1.9GB/s、4KBのランダムリード/ライトが45万IOPS、15万IOPS　！！ 一気に眠気が吹き飛びます！！ ちなみに、7200rpmのSATA HDDの場合は、ざっくりとシーケンシャル100MB、ランダム100IOPS程度ですので、どれだけ高性能かおわかりいただけるでしょう。 ライバルは、もしかしてこれ？ 使ってみたいですよね？それでは使ってみましょう。このカードは、PCIe SSDの新しい規格NVMe (http://en.wikipedia.org/wiki/NVM_Express</a>)に対応していますので、Linuxカーネルでnvmeドライバがロードされている必要があります。 バニラカーネルをコンパイルする際には、CONFIG_BLK_DEV_NVME=m　などとなるようにします。 うまく認識されると、/dev/nvmexxxとして、見えるようになります。 wheezy64:~# fdisk -l /dev/nvme0n1 Disk /dev/nvme0n1: 1600.3 GB, 1600321314816 bytes 64 heads, 32 sectors/track, 1526185 cylinders, total 3125627568 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xc55b79ff Device Boot Start End Blocks Id System </blockquote> fdiskでパーティション作成します。 wheezy64:~# fdisk /dev/nvme0n1 Command (m for help): n Partition type: p primary (0 primary, 0 extended, 4 free) e extended Select (default p): p Partition number (1-4, default 1): 1 First sector (2048-3125627567, default 2048): Using default value 2048 Last sector, +sectors or +size{K,M,G} (2048-3125627567, default 3125627567): Using default value 3125627567 Command (m for help): p Disk /dev/nvme0n1: 1600.3 GB, 1600321314816 bytes 64 heads, 32 sectors/track, 1526185 cylinders, total 3125627568 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xc55b79ff Device Boot Start End Blocks Id System /dev/nvme0n1p1 2048 3125627567 1562812760 83 Linux Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. Syncing disks. </blockquote> ファイルシステム作ります。 wheezy64:~# time mkfs.ext4 /dev/nvme0n1p1 mke2fs 1.42.5 (29-Jul-2012) Discarding device blocks: done Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 97681408 inodes, 390703190 blocks 19535159 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=4294967296 11924 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848 Allocating group tables: done Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done real 0m13.304s user 0m2.230s sys 0m0.440s </blockquote> マウントします。 wheezy64:~# mkdir /mnt/p3700 wheezy64:~# mount /dev/nvme0n1p1 /mnt/p3700/ </blockquote> wheezy64:~# df -h Filesystem Size Used Avail Use% Mounted on rootfs 48G 510M 47G 2% / tmpfs 48G 510M 47G 2% / tmpfs 9.5G 228K 9.5G 1% /run tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 10M 0 10M 0% /dev tmpfs 19G 0 19G 0% /run/shm /dev/nvme0n1p1 1.5T 70M 1.4T 1% /mnt/p3700 </blockquote> とりあえず、100GB程度、読み書きしてみます。まずは、Write。 wheezy64:~# time dd if=/dev/zero of=/mnt/p3700/hello bs=100M count=1000 oflag=direct 1000+0 records in 1000+0 records out 104857600000 bytes (105 GB) copied, 77.9616 s, 1.3 GB/s real 1m17.964s user 0m0.000s sys 0m45.700s </blockquote> そして、Read。 wheezy64:~# time dd of=/dev/null if=/mnt/p3700/hello bs=100M count=1000 iflag=direct 1000+0 records in 1000+0 records out 104857600000 bytes (105 GB) copied, 40.6814 s, 2.6 GB/s real 0m40.684s user 0m0.010s sys 0m22.650s </blockquote> カタログスペックには若干届かないですけど、爆速です！！ 大事なのでもう一度、爆速です！！ ランダムIOを測ってみます。まずはrandomwrite。 wheezy64:~# fio --filename=/mnt/p3700/hello --direct=1 --rw=randwrite --bs=4k --size=2G --numjobs=64 --runtime=180 --name=file1 --ioengine=aio --iodepth=512 --group_reporting file1: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=512 ... file1: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=512 2.0.8 Starting 64 processes Jobs: 1 (f=1): [_________________________________________________________w] [98.4% done] [0K/833.5M /s] [0 /213K iops] [eta 00m:03s]s] file1: (groupid=0, jobs=64): err= 0: pid=20537 write: io=129218MB, bw=734950KB/s, iops=183737 , runt=180039msec slat (usec): min=3 , max=2162.1K, avg=322.56, stdev=12338.02 clat (usec): min=12 , max=9825.2K, avg=166237.67, stdev=381829.66 lat (usec): min=20 , max=9825.2K, avg=166560.46, stdev=382293.33 clat percentiles (msec): | 1.00th=[ 5], 5.00th=[ 6], 10.00th=[ 7], 20.00th=[ 8], | 30.00th=[ 9], 40.00th=[ 11], 50.00th=[ 13], 60.00th=[ 22], | 70.00th=[ 70], 80.00th=[ 208], 90.00th=[ 519], 95.00th=[ 898], | 99.00th=[ 1844], 99.50th=[ 2343], 99.90th=[ 3458], 99.95th=[ 3884], | 99.99th=[ 5211] bw (KB/s) : min= 0, max=310600, per=1.82%, avg=13395.80, stdev=22803.92 lat (usec) : 20=0.01%, 50=0.01%, 100=0.01%, 250=0.01%, 500=0.01% lat (usec) : 750=0.01%, 1000=0.01% lat (msec) : 2=0.01%, 4=0.02%, 10=39.48%, 20=19.46%, 50=8.79% lat (msec) : 100=4.69%, 250=9.58%, 500=7.63%, 750=3.74%, 1000=2.47% lat (msec) : 2000=3.33%, >=2000=0.79% cpu : usr=0.92%, sys=13.35%, ctx=29141732, majf=0, minf=3026598 IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.1% issued : total=r=0/w=33079899/d=0, short=r=0/w=0/d=0 Run status group 0 (all jobs): WRITE: io=129218MB, aggrb=734949KB/s, minb=734949KB/s, maxb=734949KB/s, mint=180039msec, maxt=180039msec Disk stats (read/write): nvme0n1: ios=0/33078988, merge=0/0, ticks=0/5930480, in_queue=5933370, util=99.60% </blockquote> そしてRandomRead。 wheezy64:~# fio --filename=/mnt/p3700/hello --direct=1 --rw=randread --bs=4k --size=2G --numjobs=64 --runtime=180 --name=file1 --ioengine=aio --iodepth=512 --group_reporting file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=512 ... file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=512 2.0.8 Starting 64 processes Jobs: 12 (f=6): [r__r____r___r__r__________r_r_r_r________________________r_r_r__] [93.2% done] [1403M/0K /s] [359K/0 iops] [eta 00m:08s]] file1: (groupid=0, jobs=64): err= 0: pid=21635 read : io=131072MB, bw=1194.3MB/s, iops=305724 , runt=109754msec slat (usec): min=1 , max=104416 , avg=181.86, stdev=2273.95 clat (usec): min=88 , max=1698.4K, avg=94142.32, stdev=89737.06 lat (usec): min=102 , max=1698.5K, avg=94324.37, stdev=89854.71 clat percentiles (msec): | 1.00th=[ 17], 5.00th=[ 27], 10.00th=[ 32], 20.00th=[ 37], | 30.00th=[ 42], 40.00th=[ 57], 50.00th=[ 72], 60.00th=[ 85], | 70.00th=[ 102], 80.00th=[ 131], 90.00th=[ 180], 95.00th=[ 241], | 99.00th=[ 478], 99.50th=[ 594], 99.90th=[ 865], 99.95th=[ 979], | 99.99th=[ 1270] bw (KB/s) : min= 6, max=164272, per=1.77%, avg=21641.11, stdev=11545.90 lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01% lat (msec) : 2=0.01%, 4=0.03%, 10=0.40%, 20=1.29%, 50=34.99% lat (msec) : 100=32.37%, 250=26.29%, 500=3.75%, 750=0.66%, 1000=0.15% lat (msec) : 2000=0.05% cpu : usr=1.34%, sys=37.50%, ctx=2798932, majf=0, minf=1003485 IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.1% issued : total=r=33554432/w=0/d=0, short=r=0/w=0/d=0 Run status group 0 (all jobs): READ: io=131072MB, aggrb=1194.3MB/s, minb=1194.3MB/s, maxb=1194.3MB/s, mint=109754msec, maxt=109754msec Disk stats (read/write): nvme0n1: ios=33536051/4, merge=0/0, ticks=4207010/0, in_queue=4260150, util=100.00% </blockquote> レポートから結果を抜粋してみると。 write 183,737iops、read 305,724iopsとこれも**爆速****です！！ ** 最後にざっくりとmysqlのベンチマークを実行してみます。 Intel SSD DC P3700の場合 MySQLバージョン: "5.5.38" root@kvm3:~# time mysqlslap --concurrency=50 --iterations=1 --auto-generate-sql --engine=innodb --auto-generate-sql-load-type=write --number-of-queries=5000000 --port=3306 --host=197.3.o -proot Benchmark Running for engine innodb Average number of seconds to run all queries: 153.368 seconds Minimum number of seconds to run all queries: 153.368 seconds Maximum number of seconds to run all queries: 153.368 seconds Number of clients running queries: 50 Average number of queries per client: 100000 real 2m33.485s user 0m38.288s sys 4m37.968s </blockquote> 5,000,000クエリーを213.485秒で処理したので、約23,420クエリー/秒の処理性能でした。 ちなみに、AWSのRDSの場合は以下の通りでした。 インスタンスタイプ: db.t2.medium MySQLバージョン: "5.6.17" ストレージサイズ: 10GB root@aws2:~# time mysqlslap --concurrency=50 --iterations=1 --auto-generate-sql --engine=innodb --auto-generate-sql-load-type=write --number-of-queries=5000000 --port=3306 --host=test.hsjektsilal9.ap-northeast-1.rds.amazonaws.com -p -vv Building Create Statements for Auto Building Query Statements for Auto Generating INSERT Statements for Auto Parsing engines to use. Starting Concurrency Test Loading Pre-data Generating primary key list Generating stats Benchmark Running for engine innodb Average number of seconds to run all queries: 1082.128 seconds Minimum number of seconds to run all queries: 1082.128 seconds Maximum number of seconds to run all queries: 1082.128 seconds Number of clients running queries: 50 Average number of queries per client: 100000 real 18m2.874s user 0m8.965s sys 0m46.891s </blockquote> 5,000,000クエリーを1082.128秒で処理したので、約4,620クエリー/秒の処理性能でした。 これも爆速といえるでしょう！！ MySQL用のストレージとして、Intel DC P3700いかがでしょうか？ 現場からは以上です！ 今日のお仕事 2014-10-26T00:00:00+00:00 こんにちは。昨日、今日と暖かく過ごしやすい週末でしたね。 とはいえ、弊社では、サーバの納期が迫っていたため、休日返上で準備に追われていました。 今回のサーバはこんなやつです。 3Uのシャーシに3.5インチのHDDベイが16個並んでいて、一見ストレージサーバのように見えます。しかし、背面をのぞいてみると... こんな、1ソケットのXeonサーバボードが.... こんな感じで、8ノード搭載されています！ IPMIも使えて、ssh経由のSMASH/CLPもなかなかグッドです。 WEBやキャッシュサーバなんかには、最適なんじゃないかと思います。 休日にも関わらず、出荷のお手伝いをしてくれたスタッフのMさん、ありがとう！ 出荷を待つサーバたち 2014-08-27T00:00:00+00:00 皆さんこんばんは。今日は肌寒い一日でしたね。 季節の変り目には体調を崩しがちですので注意しましょうね。 さて以下の写真は弊社で販売しているIntel IvyBridge Xeonプロセッサを2基搭載した、とっても高性能なサーバたちです。 メモリは、最大で512GB搭載可能で、最近は100GBを超えるものがよくご注文いただきます。LSIの高性能なRAIDカードが標準装備。8本のSSDと組み合わせることで、びっくりする位のIO性能をたたき出します。 オンラインゲームなどを支えるデータベースの高速化にぴったりです。 お好みにより、10GBaseTのネットワークにも対応可能です。 商品紹介ページはこちら</a> 一家に一台。奥さんいかがですか！ 追記、開腹写真もありましたので、貼っておきます。 Intel SSDの保証とsmart情報について 2014-08-11T00:00:00+00:00 こんにちは。暑い日が続きますね。 Intel SSDの保証期間について調べる機会がありましたので、忘れないようにメモしておきます。 何のことはなくインテルの以下のページに、よくまとまってかかれています。 http://www.intel.com/jp/support/ssdc/hpssd/sb/CS-029645.htm</a> これによると、保証の条件は製品によって若干異なるようですが、大まかに言って、次の二つに大別されるようです。 SSDのフラッシュメディアのWear out(摩耗)情報が取れるものに関しては、それが限度に達するか、5年または3年の保証。 </li> 上記に当てはまらないものは、5年または3年の保証。 </li> </ul> SSDには書き込み寿命がありますので、保証期間内であっても、メディアが寿命を越えてしまった場合には、保証の対象外となってしまう場合があるようです。 手元に、Intel 520 SSD 240GBと、DC S3500 120GBがありましたので、詳しく調べてみました。 まず、Intel 520 SSD 240GBの場合。</h3> 以下のページを見ると、520は、"E9 メディア消耗指数 (Media Wear-Out Indicator) が利用できない"らしく、上述の保証条件の2番に当てはまりそうです。 http://www.intel.com/jp/support/ssdc/hpssd/sb/cs-032511.htm</a> なるほど、"Media Wear-Out Indicator"は取得できないのですね…確かめてみましょう。 手元のIntel 520 SSD 240GBと言うのは、実は、LSIのMegaraid 9266-8iという、それはそれは高性能なRAIDカードの配下にぶら下がっています。 Megaraid配下のドライブの"Media Wear-Out Indicator"情報を取得するには、RAIDのユーティリティ(megacli, storcli等)でドライブIDを特定し、smartctlでsmart情報を取得すれば良いようです。 まず、storcliでDriveIDを取得します。 # /opt/MegaRAID/storcli/storcli64 /c0 /eall /sall show Controller = 0 Status = Success Description = Show Drive Information Succeeded. Drive Information : ================= ---------------------------------------------------------------------------- EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp ---------------------------------------------------------------------------- 252:0 8 Onln 0 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:1 46 UBad - 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:2 48 Onln 0 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:3 9 Onln 0 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:4 37 Onln 0 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:5 11 Onln 0 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:6 47 Onln 0 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:7 12 JBOD - 232.375 GB SATA HDD N N 512B ST9250421AS U ---------------------------------------------------------------------------- EID-Enclosure Device ID|Slt-Slot No.|DID-Device ID|DG-DriveGroup DHS-Dedicated Hot Spare|UGood-Unconfigured Good|GHS-Global Hotspare UBad-Unconfigured Bad|Onln-Online|Offln-Offline|Intf-Interface Med-Media Type|SED-Self Encryptive Drive|PI-Protection Info SeSz-Sector Size|Sp-Spun|U-Up|D-Down|T-Transition|F-Foreign</code></pre> この例では、{8,46,48,9,37,11,47,12}が各スロットにつながっているSSD/HDDのDriveIDとなります。 スロット0番のSSDのスマート情報を取得するには、例えば以下の様にすれば良いです。 # smartctl -d megaraid,8 /dev/sdb -A smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.13.2-64kvmh01] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net /dev/sdb [megaraid_disk_08] [SAT]: Device open changed type from 'megaraid' to 'sat' === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0032 100 100 000 Old_age Always - 0 9 Power_On_Hours 0x0032 000 000 000 Old_age Always - 257801117878698 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 362 170 Unknown_Attribute 0x0033 100 100 010 Pre-fail Always - 0 171 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 172 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 174 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 353 184 End-to-End_Error 0x0033 100 100 090 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 353 225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 1902970 226 Load-in_Time 0x0032 100 100 000 Old_age Always - 65535 227 Torq-amp_Count 0x0032 100 100 000 Old_age Always - 56 228 Power-off_Retract_Count 0x0032 100 100 000 Old_age Always - 65535 232 Available_Reservd_Space 0x0033 100 100 010 Pre-fail Always - 0 233 Media_Wearout_Indicator 0x0032 097 097 000 Old_age Always - 0 241 Total_LBAs_Written 0x0032 100 100 000 Old_age Always - 1902970 242 Total_LBAs_Read 0x0032 100 100 000 Old_age Always - 2432048 249 Unknown_Attribute 0x0013 100 100 000 Pre-fail Always - 50803# smartctl -d megaraid,8 /dev/sdb -A smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.13.2-64kvmh01] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net /dev/sdb [megaraid_disk_08] [SAT]: Device open changed type from 'megaraid' to 'sat' === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0032 100 100 000 Old_age Always - 0 9 Power_On_Hours 0x0032 000 000 000 Old_age Always - 257801117878698 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 362 170 Unknown_Attribute 0x0033 100 100 010 Pre-fail Always - 0 171 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 172 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 174 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 353 184 End-to-End_Error 0x0033 100 100 090 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 353 225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 1902970 226 Load-in_Time 0x0032 100 100 000 Old_age Always - 65535 227 Torq-amp_Count 0x0032 100 100 000 Old_age Always - 56 228 Power-off_Retract_Count 0x0032 100 100 000 Old_age Always - 65535 232 Available_Reservd_Space 0x0033 100 100 010 Pre-fail Always - 0 233 Media_Wearout_Indicator 0x0032 097 097 000 Old_age Always - 0 241 Total_LBAs_Written 0x0032 100 100 000 Old_age Always - 1902970 242 Total_LBAs_Read 0x0032 100 100 000 Old_age Always - 2432048 249 Unknown_Attribute 0x0013 100 100 000 Pre-fail Always - 50803</code></pre> 上記のsmart情報で、16進数でE9、すなわち233番がMedia_Wearout_Indicatorとなっていることが分かります。上記の場合、現在の値が97で、ワースト値が97、しきい値が0ということになります。 よく分からないので調べてみると、どうやら、新品のSSDはMedia_Wearout_Indicatorの値が100で、使用するにつれてだんだん減っていき、1になるともうダメと言うことのようです。 Media Wear-out Indicator は、正規化した (normalized) 値が 100 で (SSD が新規工場出荷時)、1 へと減少していきます。値が 1 になった時、それは消耗の限界に到達したことを意味し、データ消滅を防ぐためにその SSD を交換するか、バックアップを取ることが推奨されます。 </blockquote> http://www.intel.com/jp/support/ssdc/hpssd/sb/CS-032510.htm</a> </blockquote> しきい値0と言うのは、smartの世界では、障害予測に用いないということを意味する、特別な値を示しているようです。 http://www.hdsentinel.com/smart/index.php</a>http://www.easis.com/smart-value-interpretation.html</a> </blockquote> インテルの保証のページには、520シリーズのSSDは"Media Wear-out Indicatorが取得できない"種類のSSDに大別されていましたが、どうやら取得できてしまうようですσ(^_^;) どうせ壊れるんなら、保証期間内かつMedia Wear-out Indicatorが1になる前に壊れてくれることを祈りましょう。。。 ちなみにデータシートによると、241のTotal_LBAs_WrittenのRawValueは総書き込み量を32MByteで割ったもの、同じく242のTotal_LBAs_ReadのRawValueは総読み出し量を32MByteで割ったものであるようです。 したがって、この場合の書き込み総量は、60,895,040Mbyte = 約61Tbyte、読み出し総量は、77,825,536Mbyte = 約78TByteとなります。 かなり書き込んでるにも関わらず、Media Wear-out Indicatorが3しか減っていないと言うのはうれしいですね。(この割合で行くと仮定すると、あと1PB位は余裕で書けちゃいそうですね。) 次に、DC S3500 120GBの場合です。</h3> 以下のドキュメントによると、DC S3500シリーズのSSDは保証期間に加えて、Media Wear-out Indicatorも、保証の条件として考慮されるようです。 http://download.intel.com/support/ssdc/hpssd/sb/DC_S3500_Warranty_r0_Japanese.pdf</a> </blockquote> では、実際にMedia Wear-out Indicatorの値を確かめて見ましょう。 手元のDC 3500 120GBと言うのは、Adaptec 5805Zと言う、とっても高性能なRAIDコントローラーにぶら下がっています。 AdaptecのRAIDコントローラにぶら下がった、SSDやHDDのsmart情報を取得するには、次のようなコマンドを実行すれば良いはずです。 smartctl -d sat /dev/sg3 -i</h1> </blockquote> AdaptecのRAIDカードの場合、scsi genericドライバを読み込めば、/dev/sgXにデバイスファイルを作成してくれるので、それはそれは便利です。/dev/sgXのXの値が何になるかは、dmesgの出力を見て判別してもいいですが、/dev/sgXの数自体がそんなに多くなければ、順番にsmartctl -d sat /dev/sgX -iで調べていってもいいでしょう。 dmesgの出力例 # dmesg |grep scsi scsi0 : aacraid scsi 0:0:0:0: Direct-Access Adaptec 1 V1.0 PQ: 0 ANSI: 2 scsi 0:0:1:0: Direct-Access Adaptec Device 1 V1.0 PQ: 0 ANSI: 2 scsi 0:1:0:0: Direct-Access INTEL SSDSC2BB12 D201 PQ: 1 ANSI: 5 scsi 0:1:1:0: Direct-Access INTEL SSDSC2CW24 400i PQ: 1 ANSI: 5 scsi 0:1:2:0: Direct-Access INTEL SSDSC2BB12 D201 PQ: 1 ANSI: 5 scsi 0:1:3:0: Direct-Access INTEL SSDSC2BB12 D201 PQ: 1 ANSI: 5 scsi 0:1:4:0: Direct-Access INTEL SSDSC2BB12 D201 PQ: 1 ANSI: 5 scsi 0:1:5:0: Direct-Access INTEL SSDSC2BB12 D201 PQ: 1 ANSI: 5 scsi 0:1:6:0: Direct-Access INTEL SSDSC2BB12 D201 PQ: 1 ANSI: 5 scsi 0:1:7:0: Direct-Access INTEL SSDSC2BB12 D201 PQ: 1 ANSI: 5 scsi 0:3:0:0: Enclosure ADAPTEC Virtual SGPIO 0 0001 PQ: 0 ANSI: 5 scsi 0:3:1:0: Enclosure ADAPTEC Virtual SGPIO 1 0001 PQ: 0 ANSI: 5 sd 0:0:0:0: Attached scsi generic sg0 type 0 sd 0:0:1:0: Attached scsi generic sg1 type 0 scsi 0:1:0:0: Attached scsi generic sg2 type 0 scsi 0:1:1:0: Attached scsi generic sg3 type 0 scsi 0:1:2:0: Attached scsi generic sg4 type 0 scsi 0:1:3:0: Attached scsi generic sg5 type 0 scsi 0:1:4:0: Attached scsi generic sg6 type 0 scsi 0:1:5:0: Attached scsi generic sg7 type 0 scsi 0:1:6:0: Attached scsi generic sg8 type 0 scsi 0:1:7:0: Attached scsi generic sg9 type 0 scsi 0:3:0:0: Attached scsi generic sg10 type 13 scsi 0:3:1:0: Attached scsi generic sg11 type 13 scsi1 : ata_piix scsi2 : ata_piix scsi3 : ata_piix scsi4 : ata_piix scsi 2:0:1:0: CD-ROM TEAC DV-28S-V 1.0B PQ: 0 ANSI: 5 scsi 2:0:1:0: Attached scsi generic sg12 type 5</code></pre> /dev/sg2で試して見ます。 # smartctl -d sat /dev/sg2 -i smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.14.4-64kvmh01] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Device Model: INTEL SSDSC2BB120G4 Serial Number: BTWL40150AQK120LGN LU WWN Device Id: 5 5cd2e4 04b5637db Firmware Version: D2010370 User Capacity: 120,034,123,776 bytes [120 GB] Sector Sizes: 512 bytes logical, 4096 bytes physical Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: ACS-2 revision 3 Local Time is: Mon Aug 11 13:57:01 2014 JST SMART support is: Available - device has SMART capability. SMART support is: Enabled</code></pre> Media Wear-out Indicatorの値は以下のように取得できます。 # smartctl -d sat /dev/sg2 -A smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.14.4-64kvmh01] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 1 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0032 100 100 000 Old_age Always - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 798 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 14 170 Unknown_Attribute 0x0033 100 100 010 Pre-fail Always - 0 171 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 172 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 174 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 9 175 Program_Fail_Count_Chip 0x0033 100 100 010 Pre-fail Always - 17188520638 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0033 100 100 090 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 074 074 000 Old_age Always - 26 (Min/Max 23/27) 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 9 194 Temperature_Celsius 0x0022 100 100 000 Old_age Always - 33 197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 0 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0 225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 6850 226 Load-in_Time 0x0032 100 100 000 Old_age Always - 30 227 Torq-amp_Count 0x0032 100 100 000 Old_age Always - 76 228 Power-off_Retract_Count 0x0032 100 100 000 Old_age Always - 47910 232 Available_Reservd_Space 0x0033 100 100 010 Pre-fail Always - 0 233 Media_Wearout_Indicator 0x0032 100 100 000 Old_age Always - 0 234 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 241 Total_LBAs_Written 0x0032 100 100 000 Old_age Always - 6850 242 Total_LBAs_Read 0x0032 100 100 000 Old_age Always - 21958</code></pre> Media_Wearout_Indicatorの値は100です。つまり、新品同様です。 Total_LBAs_WrittenやTotal_LBAs_Readで見ても、それぞれ、219,200Mbyte、702,656Mbyte相当となりますので、まだまだたくさん使えそうです。 まとめ</h3> Intel SSDの保証とsmart情報について調べて見ました。保証の条件は製品により異なりますが、Media Wearout Indicatorの値が取得できるとされる製品とそうでないものに大別され、前者の場合、Media Wearout Indicatorが１になってしまうと、保証交換が受けられないと考えられます。Media Wearout Indicatorはsmartctlコマンドで取得できます。手元にあったIntel 520とDC S3500は両方とも値が取得できました。SMART情報には、他にもTotal LBA WrittenなどSSDの使用状況を確認するのにちょうど良い値が記録されているので、いろいろ調べてみると良いでしょう。 Lineのインフラセミナーに参加してきました。 2014-04-16T00:00:00+00:00 昨日、LINE Developer Conference（テーマ：インフラ）に参加してきましたので、備忘録的にメモ。 Systemのお話し（講演の途中から参加）</li> </ol> 年末年始の障害、redisのレスポンスが悪化し、コネクションバースト。redisの処理とNIC割り込みを同じコアで処理していた。/proc/interruptをwatchして発見し、tasksetで解決。</li> </ul> データベースのお話し</li> </ol> Lineツムツムのデータベースのお話し。multimasterのmysql replication。PerconaのMMM Managerを使用。write VIPとread VIPをMMMが管理。Failover時にVIPを移動。 </li> Shardの自動追加。すべてのUIDに対しハッシュ関数を通しグループIDを発行。グループIDに対しshardを割り当てる。 </li> MMMはカスタマイズして使っている。主に障害判断の部分。 </li> shardの追加時には、移動するグループに対しselect/insert(update?)を複数回に分けて実行する。更新時刻でソートして実行しているので、マイグレーション中に更新されたデータも、もれなく移動することができる。 </li> </ul> 3．ネットワークのお話し 内部ネットワーク。Core-Pod-Edgeの3階層。unknown unicast flooding により、ギガビット大半の帯域を消費していた。Pod当たり数千台のサーバ。L2セグメントはPod単位だったのを、L2セグメントをEdge単位にした。 </li> ロードバランサL3DSR採用。L2セグメントを小さくしたので必要になった。DSCP方式。Tosフィールドのdscp=1などを設定し、それに応じてソースアドレスをリアルサーバで付け替える。 </li> ラックは24kVA 51U。スイッチは背面設置。サーバの排熱を避けるためにスイッチ3台を囲えるダクトを作成。 </li> 海外拠点はアメリカ、アジア3ヶ所、ヨーロッパ。リングトポロジー。専用線を節約し、冗長性を確保。MPLSでPseudo Wire。出来るだけルーティングに関与せずに、拠点間接続。 </li> サーバ間接続とユーザーエッジへの接続を、別々のネットワークにした。ユーザーがどの拠点に接続するか、登録時のユーザー情報をもとにスタティックにマッピング。クライアント側で実装。 </li> TCPコネクションはりっぱなし。ロードバランサのセッション、コネクションテーブルサイズがボトルネックになっていた。→　Stateless SLB　ハッシュテーブルに基づいて、リクエストを分散。ソースIPをキーにハッシュ値計算すればいい。サーバが落ちるとハッシュ再計算。 </li> ハッシュの再計算を部分的に行うタイプの機器で、Stateless SLBを実現。今年一月から。 </li> 箱物のロードバランサを使っているらしい。LVSとかじゃダメなのかな？ </li> </ul> お土産までいただきました。ありがとうございます！ 1CPU、Xeonサーバ紹介 2013-11-18T00:00:00+00:00 少し前に、お客さんに納品したサーバですが、写真を撮ってあったので紹介たいと思います。このサーバは、シングルソケットにXeon E3-1200シリーズCPUを搭載することができ、大変高速です。また、前面に2.5インチホットスワップベイを4つ搭載しているので、2.5インチのSSDを搭載することが可能で、運用も楽ちんです。 高速なWEBサーバ等に最適で、弊社のおすすめサーバの一つです。 スペックは、以下の通りです。 CPU：　Intel Xeon E3-1270v2(IvyBridge) 3.5GHz 4core </li> メモリ：　DDR3 ECC, 4GByte x4 (合計16GByte) </li> ストレージ：　Intel 530 SSD x2 </li> </ul> メモリスロットは4つあり、8Gbyteのメモリモジュールを用いることで、最大32GByteの構成が可能です。 シャーシの全面には、4つの2.5インチホットスワップベイがあり、2.5インチのSATA SSDを搭載可能です。そのおかげで、万が一SSDが故障した際にもサーバをラックから取り外すことなく、壊れたSSDを交換可能です。また、ソフトウェアRAIDを利用することにより、場合によっては、OSを停止することなく、SSDを交換してしまうことも可能です。 最近、このサーバの後継品も販売開始しました。 http://www.clustcom.com/products/220-intel-ssd-haswell-xeon-cpu-ez1u-e3-1200-v3</a> コストパフォーマンスの高いシンプルなサーバです。御社で導入してみてはいかがでしょうか。 sshuttle最強すぎる 2013-07-31T00:00:00+00:00 先日知った簡易vpn、sshuttleが強力過ぎる。 外出先から社内のWindowsサーバにリモートデスクトップ接続したいのだが、 # sshuttle --dns -r ktaka@fumidai.clustcom.com:22 192.168.20.0/22 Connected. ktaka@vaiox:~$ rdesktop -r sound:local -f winserver.intra.clustcom.com</code></pre> たったこれだけでOK。 ノートパソコン(Debian Linux)からdocomo wifiへの接続法(メモ) 2013-07-25T00:00:00+00:00 パソコンからドコモwifiに繋ぐための設定。 vaiox:~# cat /etc/wpa_supplicant.conf_docomo_wifi ctrl_interface=/var/run/wpa_supplicant network={ ssid="docomo" scan_ssid=1 key_mgmt=IEEE8021X eap=TTLS identity="xxxxx-spmode@docomo" password="xxxxxx" ca_cert="/etc/PCA-3.pem" phase2="auth=PAP" }</code></pre> 無線LANチップのドライバーをロードし、wpa_supplicantをデーモンとして起動、dhcpでアドレスを取得すればOK。 modprobe ath9k wpa_supplicant -Dwext -iwlan0 -c /etc/wpa_supplicant.conf_docomo_wifi -B dhclient wlan0</code></pre> sshuttle vpnでサーバのリモート管理を便利に 2013-07-25T00:00:00+00:00 データセンタに置かれたサーバに外部からネットワーク経由でアクセスし、電源のON/OFFやBIOS設定、OSインストールなどを行うことができれば、非常に便利です。 最近のサーバには、ネットワーク経由で電源をON/OFFしたり、コーンソール画面を操作するための、IPMI準拠のリモートマネージメント機能が備わっていることが多いので、既に利用されている方も多いと思います。 通常、サーバは、ファイアウォールによりネットワーク的に守られた場所にあるので、踏み台サーバにsshログインして、そこからアクセスしている場合も多いでしょう。 このような場合、リモートマネージメント機能を使うには、オフィスからデータセンタにvpnを張れると便利なのですが、vpnを張るのもなかなか面倒です。 今回、sshuttle(https://github.com/apenwarr/sshuttle</a>)という、sshポートのみの開放でOKな、簡易vpnツールを見つけたので紹介したいと思います。 sshuttleはLinuxとMacOSで利用可能な、簡易vpnです。踏み台サーバにはssh経由でアクセスするので、SSHのDynamic Port forwardingによるSOCKS proxyにプラスアルファしたような働きをします。 プラスアルファの部分は何かというと、あるIPアドレス、あるネットワークアドレスに対しては、クライアントプログラムでは何の設定も無しに透過的にproxyを使うことができるということです。 たとえば、以下のポンチ絵の様に、client、proxy、targetの3台のマシンがあったとします。 | | sshd:22 client proxy target(192.168.20.153) | | </blockquote> ここで、clientとproxyの間にはファイアウォールがあり、proxyへは22番ポートへのアクセスしか許可されていません。したがって、当然ながらclientからtargetへも直接アクセスできません。 踏み台サーバproxy:22へのsshコネクションを経由してtargetへアクセスできるようにするには次のコマンドのみでOKです。 vaiox:~# sshuttle -r ktaka@proxy:22 192.168.20.153 Connected. </blockquote> これだけで、以下のようにclientとporxy間にトンネルが張られます。 | sshuttlesshd:22 client proxy target(192.168.20.153) | | </blockquote> トンネルを張った後に、clientからtargetに http, https, vncなどでアクセスしようとすると、 sshuttlesshd:22のトンネルを通り、targetにアクセスできるようになります。 | http, https sshuttlesshd:22 -------------------> client proxy target(192.168.20.153) | | </blockquote> クライアントマシンで、どうなっているかを見てみると。 192.168.20.153宛のパケットはTTL=42以外であれば、全て12300番ポートにリダイレクトしています</li> </ul> vaiox:~# iptables -L -n -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination sshuttle-12300 all -- 0.0.0.0/0 0.0.0.0/0 Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination sshuttle-12300 all -- 0.0.0.0/0 0.0.0.0/0 Chain POSTROUTING (policy ACCEPT) target prot opt source destination Chain sshuttle-12300 (2 references) target prot opt source destination REDIRECT tcp -- 0.0.0.0/0 192.168.20.153 TTL match TTL != 42 redir ports 12300 RETURN tcp -- 0.0.0.0/0 127.0.0.0/8 </blockquote> 12300番ポートでは、pyhtonプログラム(sshuttle)が待ち受けています。</li> </ul> vaiox:~# netstat -lnp|grep 12300 tcp 0 0 127.0.0.1:12300 0.0.0.0:* LISTEN 5059/python </blockquote> これにより192.168.20.153宛のパケットは、ほぼ(TTL=42を除き) sshuttleが張ったコネクションを通るということになるのです。 出荷を待つファイルサーバー 2013-07-03T00:00:00+00:00 某お客様向けのファイルサーバーです。フロントに2.5インチのホットスワップHDDベイを8個備えています。 今回はSeagateの1TByte SATAドライブを8本搭載します。合計8TByteの構成です。 HDDはバックプレーンからminiSASケーブルを介してLSIのRAIDカードMegaRAID SAS 9271-8iに接続されています。このカードにはキャッシュ保護のためにCacheVaultというモジュールが取り付けられています。 CPUはXeon E3-1270v2、メモリは8GByte x4 合計32GByteと、なかなかハイスペックな構成です。8本のHDDドライブをSSDに交換すれば、そこそこ高速なDBサーバとしても使えそうです。 12,000回転のカウンターローテイティングファンを5個でシステムを冷却。CPUもメモリもRAIDカードも十分に冷却できます。 電源は500Wの電源モジュール2個で冗長化されています。 IOインターフェースは、PS/2 マウス、キーボード、IPMI専用LANポート、USBx2、シリアルポート、VGAポート、GLANポートｘ2となっています。 筐体内部のほぼ全体写真です。配線もまあまあ、スッキリしています。 以上です。 こんなサーバが欲しいというご要望がありましたら、是非ともご相談ください。 kvmによる仮想マシン"-cpu host"オプションで性能向上する場合がある 2013-05-22T00:00:00+00:00 kvmのゲストマシンのチューニングをするために、以下のページを眺めていたら、 http://www.linux-kvm.org/page/Tuning_KVM</a> こんな、記述を発見しました。 Modern processors come with a wide variety of performance enhancing features such as streaming instructions sets (sse) and other performance-enhancing instructions. These features vary from processor to processor. </blockquote> QEMU and KVM default to a compatible subset of cpu features, so that if you change your host processor, or perform a live migration, the guest will see its cpu features unchanged. This is great for compatibility but comes at a performance cost. </blockquote> To pass all available host processor features to the guest, use the command line switch qemu -cpu host </blockquote> なるほど-cpu hostをつければ、CPUの高速演算機能が使えて、性能が向上するかもしれないのか… ということで試してみました。 "-cpu host"が無いゲストマシン # egrep model /proc/cpuinfo model : 2 model name : QEMU Virtual CPU version 1.4.1 model : 2 model name : QEMU Virtual CPU version 1.4.1 # egrep flags /proc/cpuinfo flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl pni cx16 popcnt hypervisor lahf_lm flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl pni cx16 popcnt hypervisor lahf_lm</code></pre> "-cpu host"があるゲストマシン # egrep model /proc/cpuinfo model : 45 model name : Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz model : 45 model name : Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz # egrep flags /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm xsaveopt tsc_adjust flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm xsaveopt tsc_adjust</code></pre> CPUの認識のされ方、見えてるflagの数が違います。 実際にlinpackベンチマークを採ってみました。 "-cpu host"が無いゲストマシン　13.0GFlops # cat lin_xeon64.txt Thu May 23 18:59:36 JST 2013 Intel(R) Optimized LINPACK Benchmark data Current date/time: Thu May 23 18:59:36 2013 CPU frequency: 1.991 GHz Number of CPUs: 2 Number of cores: 2 Number of threads: 2 Parameters are set to: Number of tests: 15 Number of equations to solve (problem size) : 1000 2000 5000 10000 15000 18000 20000 22000 25000 26000 27000 30000 35000 40000 45000 Leading dimension of array : 1000 2000 5008 10000 15000 18008 20016 22008 25000 26000 27000 30000 35000 40000 45000 Number of trials to run : 4 2 2 2 2 2 2 2 2 2 1 1 1 1 1 Data alignment value (in Kbytes) : 4 4 4 4 4 4 4 4 4 4 4 1 1 1 1 Maximum memory requested that can be used=3873852256, at the size=22000 =================== Timing linear equation system solver =================== Size LDA Align. Time(s) GFlops Residual Residual(norm) Check 1000 1000 4 0.073 9.1585 1.125766e-12 3.839152e-02 pass 1000 1000 4 0.058 11.5232 1.125766e-12 3.839152e-02 pass 1000 1000 4 0.058 11.5443 1.125766e-12 3.839152e-02 pass 1000 1000 4 0.059 11.2817 1.125766e-12 3.839152e-02 pass 2000 2000 4 0.440 12.1283 4.992673e-12 4.343014e-02 pass 2000 2000 4 0.440 12.1421 4.992673e-12 4.343014e-02 pass 5000 5008 4 6.610 12.6155 2.427966e-11 3.385603e-02 pass 5000 5008 4 6.605 12.6248 2.427966e-11 3.385603e-02 pass 10000 10000 4 51.994 12.8258 8.998519e-11 3.172969e-02 pass 10000 10000 4 51.965 12.8330 8.998519e-11 3.172969e-02 pass 15000 15000 4 174.335 12.9087 2.187028e-10 3.444605e-02 pass 15000 15000 4 173.510 12.9702 2.187028e-10 3.444605e-02 pass 18000 18008 4 298.936 13.0083 2.887995e-10 3.162709e-02 pass 18000 18008 4 298.826 13.0131 2.887995e-10 3.162709e-02 pass 20000 20016 4 409.500 13.0260 3.701985e-10 3.277068e-02 pass 20000 20016 4 408.885 13.0456 3.701985e-10 3.277068e-02 pass 22000 22008 4 544.380 13.0417 4.627267e-10 3.389291e-02 pass 22000 22008 4 544.508 13.0386 4.627267e-10 3.389291e-02 pass Performance Summary (GFlops) Size LDA Align. Average Maximal 1000 1000 4 10.8769 11.5443 2000 2000 4 12.1352 12.1421 5000 5008 4 12.6201 12.6248 10000 10000 4 12.8294 12.8330 15000 15000 4 12.9395 12.9702 18000 18008 4 13.0107 13.0131 20000 20016 4 13.0358 13.0456 22000 22008 4 13.0402 13.0417 Residual checks PASSED End of tests Done: Thu May 23 19:53:14 JST 2013</code></pre> "-cpu host"があるゲストマシン　28.1GFlops # cat lin_xeon64.txt Thu May 23 18:58:46 JST 2013 Intel(R) Optimized LINPACK Benchmark data Current date/time: Thu May 23 18:58:46 2013 CPU frequency: 1.991 GHz Number of CPUs: 2 Number of cores: 2 Number of threads: 2 Parameters are set to: Number of tests: 15 Number of equations to solve (problem size) : 1000 2000 5000 10000 15000 18000 20000 22000 25000 26000 27000 30000 35000 40000 45000 Leading dimension of array : 1000 2000 5008 10000 15000 18008 20016 22008 25000 26000 27000 30000 35000 40000 45000 Number of trials to run : 4 2 2 2 2 2 2 2 2 2 1 1 1 1 1 Data alignment value (in Kbytes) : 4 4 4 4 4 4 4 4 4 4 4 1 1 1 1 Maximum memory requested that can be used=3873852256, at the size=22000 =================== Timing linear equation system solver =================== Size LDA Align. Time(s) GFlops Residual Residual(norm) Check 1000 1000 4 0.040 16.7342 1.029343e-12 3.510325e-02 pass 1000 1000 4 0.033 20.1526 1.029343e-12 3.510325e-02 pass 1000 1000 4 0.033 20.1592 1.029343e-12 3.510325e-02 pass 1000 1000 4 0.033 20.1368 1.029343e-12 3.510325e-02 pass 2000 2000 4 0.277 19.2876 4.298950e-12 3.739560e-02 pass 2000 2000 4 0.275 19.4285 4.298950e-12 3.739560e-02 pass 5000 5008 4 3.235 25.7781 2.581643e-11 3.599893e-02 pass 5000 5008 4 3.219 25.9008 2.581643e-11 3.599893e-02 pass 10000 10000 4 24.330 27.4089 9.603002e-11 3.386116e-02 pass 10000 10000 4 24.457 27.2672 9.603002e-11 3.386116e-02 pass 15000 15000 4 80.958 27.7979 2.042799e-10 3.217442e-02 pass 15000 15000 4 80.941 27.8037 2.042799e-10 3.217442e-02 pass 18000 18008 4 139.266 27.9224 2.894987e-10 3.170367e-02 pass 18000 18008 4 139.108 27.9542 2.894987e-10 3.170367e-02 pass 20000 20016 4 191.221 27.8951 4.097986e-10 3.627616e-02 pass 20000 20016 4 191.229 27.8940 4.097986e-10 3.627616e-02 pass 22000 22008 4 252.595 28.1068 4.548092e-10 3.331299e-02 pass 22000 22008 4 252.600 28.1062 4.548092e-10 3.331299e-02 pass Performance Summary (GFlops) Size LDA Align. Average Maximal 1000 1000 4 19.2957 20.1592 2000 2000 4 19.3581 19.4285 5000 5008 4 25.8395 25.9008 10000 10000 4 27.3381 27.4089 15000 15000 4 27.8008 27.8037 18000 18008 4 27.9383 27.9542 20000 20016 4 27.8946 27.8951 22000 22008 4 28.1065 28.1068 Residual checks PASSED End of tests Done: Thu May 23 19:25:57 JST 2013</code></pre> "-cpu host"無しで　13.0GFlops、有りで 28.1GFlops。 だいぶ違いますね。 使っている便利マークソフトが、Intelで最適化されたLinpackなので、最新のCPUの高速演算機能を使い倒せるようになっているのだと思います。 この他、sysbenchのcpuテストや、Unixbenchで比べてみましたが、"-cpu host"有り無しでの性能差はありませんでした。 そうすると、ものによっては、最適化によってCPUの機能(sse4やavx等)が使い倒せれば、速くなるということなのかもしれません。 MegaRAIDのStorCLIを試してみました。 2013-05-22T00:00:00+00:00 みなさんこんにちは！ 今日も相変わらず良い天気ですね。そろそろ、長袖のシャツでは暑く感じることも多くなってきました。 さて、本日は、LSIのRAIDカードの管理ユーティリティーツール、StorCLIについて、ご紹介したいと思います。 皆さんは、RAIDカードの管理ユーティリティーと言ったら、何を思い浮かべますか？ 多くの方は、綺麗なGUIツールでRAIDのアレイ削除を行ったり、Webブラウザーを使って管理することを思い浮かべるかもしれません。 今回ご紹介するのは、そういうものではなくて、sshログインしたサーバ上でコマンドラインでRAIDの設定を行う、ソフトウェアです。 古くは、3wareのtw_cliであったり、Adaptecのarcconf、LSIのmegacliをご存知の方にとっては、お馴染みかもしれません。 私個人的には、tw_cliは使いこなしており、その後、arcconfなども使っておりましたが、LSIのmegacliはあまり使いやすいとは感じておりませんでした。 つい最近、LSIのサイトでドライバなどを探していた時に、たまたま、StorCLIという比較的新しいツールがリリースされていましたので、試しに使ってみました。 インストールは以下の通り # wget http://www.lsi.com/downloads/Public/MegaRAID%20Common%20Files/1.03.11_StorCLI.zip # unzip 1.03.11_StorCLI.zip # cd StorCli_All_OS/Linux/ # alien -t storcli-1.03.11-1.noarch.rpm # tar tvf storcli-1.03.11.tgz drwxr-xr-x root/root 0 2013-05-23 01:57 ./ drwxr-xr-x root/root 0 2013-05-23 01:57 ./opt/ drwxr-xr-x root/root 0 2013-05-23 01:57 ./opt/MegaRAID/ drwxr-xr-x root/root 0 2013-05-23 01:57 ./opt/MegaRAID/storcli/ -rwxr-xr-x root/root 4956856 2013-01-30 19:25 ./opt/MegaRAID/storcli/storcli64 -rwxr-xr-x root/root 4907676 2013-01-30 19:25 ./opt/MegaRAID/storcli/storcli # tar xf storcli-1.03.11.tgz -C / # tree /opt/ /opt/ `-- MegaRAID `-- storcli |-- storcli `-- storcli64 2 directories, 2 files</code></pre> storcli64が64bit Linux用のバイナリです。早速、コマンドを叩いてみると、 # /opt/MegaRAID/storcli/storcli64 Storage Command Line Tool Ver 1.03.11 Jan 30, 2013 (c)Copyright 2012, LSI Corporation, All Rights Reserved. help - lists all the commands with their usage. E.g. storcli help help - gives details about a particular command. E.g. storcli add help List of commands: Commands Description ------------------------------------------------------------------- add Adds/creates a new element to controller like VD,Spare..etc delete Deletes an element like VD,Spare show Displays information about an element set Set a particular value to a property start Start background operation stop Stop background operation pause Pause background operation resume Resume background operation download Downloads file to given device expand expands size of given drive insert inserts new drive for missing transform downgrades the controller /cx Controller specific commands /ex Enclosure specific commands /sx Slot/PD specific commands /vx Virtual drive specific commands /dx Disk group specific commands /fx Foreign configuration specific commands /px Phy specific commands /bbu Battery Backup Unit related commands Other aliases : cachecade, freespace, sysinfo Use a combination of commands to filter the output of help further. E.g. 'storcli cx show help' displays all the show operations on cx. Use verbose for detailed description E.g. 'storcli add verbose help' Use 'page=[x]' as the last option in all the commands to set the page break. X=lines per page. E.g. 'storcli help page=10' Command options must be entered in the same order as displayed in the help of the respective commands.</code></pre> 新しいCLIツールと聞いて薄々感づいていましたが、どうやら、tw_cliと構文がそっくりです。 3wareは、2009年にLSIに買収されたのですが、使い易いと評判だった3wareのCLIの良い部分を、既存のMegaraidのプロダクトラインでも使えるようにしたのでしょう。 コントローラの情報を表示してみます。 # /opt/MegaRAID/storcli/storcli64 show Status Code = 0 Status = Success Description = None Number of Controllers = 1 Host Name = 151 Operating System = Linux3.8.8-64kvmh01 System Overview : =============== ---------------------------------------------------------------- Ctl Model Ports PDs DGs DNOpt VDs VNOpt BBU sPR DS EHS ASOs ---------------------------------------------------------------- 0 9266-8i 8 6 0 0 0 0 Msng On 1&2 Y 2 ---------------------------------------------------------------- Ctl=Controller Index|DGs=Drive groups|VDs=Virtual drives|Fld=Failed PDs=Physical drives|DNOpt=DG NotOptimal|VNOpt=VD NotOptimal|Opt=Optimal Msng=Missing|Dgd=Degraded|NdAtn=Need Attention|Unkwn=Unknown sPR=Scheduled Patrol Read|DS=DimmerSwitch|EHS=Emergency Hot Spare Y=Yes|N=No|ASOs=Advanced Software Options|BBU=Battery backup unit</code></pre> コントローラ0番が9266-8i であることがわかりますね。ポート数は8で、現在接続されているドライブは6本、BBUはMissing　…　あってます。 下の方に書いてある、説明が地味に便利ですね。 コントローラ0番の情報を、さらに詳しく見てみましょう。 # /opt/MegaRAID/storcli/storcli64 /c0 show Controller = 0 Status = Success Description = None Product Name = LSI MegaRAID SAS 9266-8i Serial Number = SV22625074 SAS Address = 500605b0050719c0 Mfg. Date = 07/03/12 System Time = 05/23/2013 02:16:39 Controller Time = 05/22/2013 17:16:38 FW Package Build = 23.9.0-0018 BIOS Version = 5.38.00_4.12.05.00_0x05180000 FW Version = 3.220.35-1998 Driver Name = megaraid_sas Driver Version = 06.504.01.00-rc1 Controller Bus Type = N/A PCI Slot = N/A PCI Bus Number = 6 PCI Device Number = 0 PCI Function Number = 0 Physical Drives = 6 PD LIST : ======= ---------------------------------------------------------------------------- EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp ---------------------------------------------------------------------------- 252:0 39 JBOD - 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:1 8 JBOD - 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:2 38 UGood - 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:3 9 UGood - 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:4 37 UGood - 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:5 11 UGood - 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U ---------------------------------------------------------------------------- EID-Enclosure Device ID|Slt-Slot No.|DID-Device ID|DG-DriveGroup DHS-Dedicated Hot Spare|UGood-Unconfigured Good|GHS-Global Hotspare UBad-Unconfigured Bad|Onln-Online|Offln-Offline|Intf-Interface Med-Media Type|SED-Self Encryptive Drive|PI-Protection Info SeSz-Sector Size|Sp-Spun|U-Up|D-Down|T-Transition|F-Foreign</code></pre> ああ、良いですね、いろんな情報とれてます。文法は、tw_cliそのまんまですね。 せっかくですので、RAIDのアレイを作ってみましょう…まずは、ヘルプを… # /opt/MegaRAID/storcli/storcli64 add help Storage Command Line Tool Ver 1.03.11 Jan 30, 2013 (c)Copyright 2012, LSI Corporation, All Rights Reserved. storcli /cx add vd type=raid[0|1|5|6|00|10|50|60] [Size=,,..|all] [name=,..] drives=e:s|e:s-x|e:s-x,y,e:s-x,y,z [PDperArray=x][SED] [pdcache=on|off|default][pi][DimmerSwitch(ds)=default|automatic(auto)| none|maximum(max)|MaximumWithoutCaching(maxnocache)][wt|wb][nora|ra] [direct|cached] [CachedBadBBU|NoCachedBadBBU] [cachevd] [Strip=] [AfterVd=X] [Spares = [e:]s|[e:]s-x|[e:]s-x,y] [force] storcli /cx add vd each type=raid0 [name=,..] [drives=e:s|e:s-x|e:s-x,y] [SED] [pdcache=on|off|default][pi] [DimmerSwitch(ds)=default|automatic(auto)| none|maximum(max)|MaximumWithoutCaching(maxnocache)] [wt|wb] [nora|ra] [direct|cached] [CachedBadBBU|NoCachedBadBBU] [Strip=] storcli /cx add vd cachecade Type = raid[0,1,10] drives = [e:]s|[e:]s-x| [e:]s-x,y [WT| WB] [assignvds = 0,1,2] storcli /cx[/ex]/sx add hotsparedrive [DGs=] [enclaffinity] [nonrevertible]</code></pre> なるほど…　スロット2，3，4のドライブを使って、RAID5のアレイ=バーチャルドライブを作ってみます。 # /opt/MegaRAID/storcli/storcli64 /c0 add vd type=raid5 drives=252:2,252:3,252:4 Controller = 0 Status = Success Description = Add VD Succeeded</code></pre> うまくいったみたいなので、確認します。 # /opt/MegaRAID/storcli/storcli64 /c0 show Controller = 0 Status = Success Description = None Product Name = LSI MegaRAID SAS 9266-8i Serial Number = SV22625074 SAS Address = 500605b0050719c0 Mfg. Date = 07/03/12 System Time = 05/23/2013 02:36:32 Controller Time = 05/22/2013 17:36:30 FW Package Build = 23.9.0-0018 BIOS Version = 5.38.00_4.12.05.00_0x05180000 FW Version = 3.220.35-1998 Driver Name = megaraid_sas Driver Version = 06.504.01.00-rc1 Controller Bus Type = N/A PCI Slot = N/A PCI Bus Number = 6 PCI Device Number = 0 PCI Function Number = 0 Drive Groups = 1 TOPOLOGY : ======== -------------------------------------------------------------------------- DG Arr Row EID:Slot DID Type State BT Size PDC PI SED DS3 FSpace -------------------------------------------------------------------------- 0 - - - - RAID5 Optl N 446.125 GB enbl N N none N 0 0 - - - RAID5 Optl N 446.125 GB enbl N N none N 0 0 0 252:2 38 DRIVE Onln N 223.062 GB enbl N N none - 0 0 1 252:3 9 DRIVE Onln N 223.062 GB enbl N N none - 0 0 2 252:4 37 DRIVE Onln N 223.062 GB enbl N N none - -------------------------------------------------------------------------- DG=Disk Group Index|Arr=Array Index|Row=Row Index|EID=Enclosure Device ID DID=Device ID|Type=Drive Type|Onln=Online|Rbld=Rebuild|Dgrd=Degraded Pdgd=Partially degraded|Offln=Offline|BT=Background Task Active PDC=PD Cache|PI=Protection Info|SED=Self Encrypting Drive|Frgn=Foreign DS3=Dimmer Switch 3|dflt=Default|Msng=Missing|FSpace=Free Space Present Virtual Drives = 1 VD LIST : ======= ----------------------------------------------------------- DG/VD TYPE State Access Consist Cache sCC Size Name ----------------------------------------------------------- 0/0 RAID5 Optl RW No RaWTD - 446.125 GB ----------------------------------------------------------- Cac=CacheCade|Rec=Recovery|OfLn=OffLine|Pdgd=Partially Degraded|dgrd=Degraded Optl=Optimal|RO=Read Only|RW=Read Write|B=Blocked|Consist=Consistent| Ra=Read Ahead Adaptive|R=Read Ahead Always|NR=No Read Ahead|WB=WriteBack| AWB=Always WriteBack|WT=WriteThrough|C=Cached IO|D=Direct IO|sCC=Scheduled Check Consistency Physical Drives = 6 PD LIST : ======= ---------------------------------------------------------------------------- EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp ---------------------------------------------------------------------------- 252:0 39 JBOD - 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:1 8 JBOD - 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:2 38 Onln 0 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:3 9 Onln 0 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:4 37 Onln 0 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:5 11 UGood - 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U ---------------------------------------------------------------------------- EID-Enclosure Device ID|Slt-Slot No.|DID-Device ID|DG-DriveGroup DHS-Dedicated Hot Spare|UGood-Unconfigured Good|GHS-Global Hotspare UBad-Unconfigured Bad|Onln-Online|Offln-Offline|Intf-Interface Med-Media Type|SED-Self Encryptive Drive|PI-Protection Info SeSz-Sector Size|Sp-Spun|U-Up|D-Down|T-Transition|F-Foreign</code></pre> ドライブグループ0番と、バーチャルドライブ0番が、今作成したRAID5のアレイ=VDです。DG=0の情報だけを見るには、次のようにします。 # /opt/MegaRAID/storcli/storcli64 /c0/d0 show Controller = 0 Status = Success Description = Show Diskgroup Succeeded TOPOLOGY : ======== -------------------------------------------------------------------------- DG Arr Row EID:Slot DID Type State BT Size PDC PI SED DS3 FSpace -------------------------------------------------------------------------- 0 - - - - RAID5 Optl N 446.125 GB enbl N N none N 0 0 - - - RAID5 Optl N 446.125 GB enbl N N none N 0 0 0 252:2 38 DRIVE Onln N 223.062 GB enbl N N none - 0 0 1 252:3 9 DRIVE Onln N 223.062 GB enbl N N none - 0 0 2 252:4 37 DRIVE Onln N 223.062 GB enbl N N none - -------------------------------------------------------------------------- DG=Disk Group Index|Arr=Array Index|Row=Row Index|EID=Enclosure Device ID DID=Device ID|Type=Drive Type|Onln=Online|Rbld=Rebuild|Dgrd=Degraded Pdgd=Partially degraded|Offln=Offline|BT=Background Task Active PDC=PD Cache|PI=Protection Info|SED=Self Encrypting Drive|Frgn=Foreign DS3=Dimmer Switch 3|dflt=Default|Msng=Missing|FSpace=Free Space Present</code></pre> VD=0の情報だけを見るには、以下のようにします。 # /opt/MegaRAID/storcli/storcli64 /c0/v0 show Controller = 0 Status = Success Description = None Virtual Drives : ============== ----------------------------------------------------------- DG/VD TYPE State Access Consist Cache sCC Size Name ----------------------------------------------------------- 0/0 RAID5 Optl RW No RaWTD - 446.125 GB ----------------------------------------------------------- Cac=CacheCade|Rec=Recovery|OfLn=OffLine|Pdgd=Partially Degraded|dgrd=Degraded Optl=Optimal|RO=Read Only|RW=Read Write|B=Blocked|Consist=Consistent| Ra=Read Ahead Adaptive|R=Read Ahead Always|NR=No Read Ahead|WB=WriteBack| AWB=Always WriteBack|WT=WriteThrough|C=Cached IO|D=Direct IO|sCC=Scheduled Check Consistency</code></pre> ライトキャッシュの設定がWTになっているので、AWBに変えてみます。 root@151:~# /opt/MegaRAID/storcli/storcli64 /c0/v0 set wrcache=AWB Controller = 0 Status = Success Description = None Detailed Status : =============== --------------------------------------- VD Property Value Status ErrCd ErrMsg --------------------------------------- 0 wrCache AWB Success 0 - ---------------------------------------</code></pre> 確認は次のようにします。 root@151:~# /opt/MegaRAID/storcli/storcli64 /c0/v0 show Controller = 0 Status = Success Description = None Virtual Drives : ============== ------------------------------------------------------------ DG/VD TYPE State Access Consist Cache sCC Size Name ------------------------------------------------------------ 0/0 RAID5 Optl RW No RaAWBD - 446.125 GB ------------------------------------------------------------ Cac=CacheCade|Rec=Recovery|OfLn=OffLine|Pdgd=Partially Degraded|dgrd=Degraded Optl=Optimal|RO=Read Only|RW=Read Write|B=Blocked|Consist=Consistent| Ra=Read Ahead Adaptive|R=Read Ahead Always|NR=No Read Ahead|WB=WriteBack| AWB=Always WriteBack|WT=WriteThrough|C=Cached IO|D=Direct IO|sCC=Scheduled Check Consistency</code></pre> AWB　Always WriteBackに変わりました。 次に、ホットスペアドライブを設定してみます。まずはヘルプで、コマンドシンタックスを確認します。 # /opt/MegaRAID/storcli/storcli64 /c0/e252/s5 add help Storage Command Line Tool Ver 1.03.11 Jan 30, 2013 (c)Copyright 2012, LSI Corporation, All Rights Reserved. NAME: Add Hot Spare Drive SYNTAX: storcli /cx[/ex]/sx add hotsparedrive [DGs=] [enclaffinity] [nonrevertible] DESCRIPTION: This command creates a hotspare drive. OPTIONS: DGs - Specifies the drive group to which the hotspare drive is dedicated. enclaffinity - Specifies the enclosure to which the hotspare is associated with. If this option is specified, affinity is set; if it is not specified, there is no affinity.NOTE Affinity cannot be removed once it is set for a hotspare drive. nonrevertible- Sets the drive as a nonrevertible hotspare. CONVENTION: /cx - specifies a controller where X is the controller index. /ex - specifies a enclosure where X is the enclosure device ID. /sx - specifies a physical drive where X is the slot number.</code></pre> そしてスロット5番のドライブをホットスペアに設定します。 # /opt/MegaRAID/storcli/storcli64 /c0/e252/s5 add hotsparedrive Controller = 0 Status = Success Description = Add Hot Spare Succeeded.</code></pre> 確認してみます。 root@151:~# /opt/MegaRAID/storcli/storcli64 /c0/e252/s5 show Controller = 0 Status = Success Description = Show Drive Information Succeeded. Drive Information : ================= ---------------------------------------------------------------------------- EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp ---------------------------------------------------------------------------- 252:5 11 GHS - 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U ---------------------------------------------------------------------------- EID-Enclosure Device ID|Slt-Slot No.|DID-Device ID|DG-DriveGroup DHS-Dedicated Hot Spare|UGood-Unconfigured Good|GHS-Global Hotspare UBad-Unconfigured Bad|Onln-Online|Offln-Offline|Intf-Interface Med-Media Type|SED-Self Encryptive Drive|PI-Protection Info SeSz-Sector Size|Sp-Spun|U-Up|D-Down|T-Transition|F-Foreign</code></pre> スロット5番のドライブがグローバルホットスペアになったようです。 グローバルホットスペアの機能を確認するために、今RAID5のアレイの作成に用いたドライブの内、スロット2番のドライブをオフラインにしてみます。 # /opt/MegaRAID/storcli/storcli64 /c0/e252/s2 set offline Controller = 0 Status = Success Description = Set Drive Offline Succeeded.</code></pre> バーチャルドライブの状態を見てみます。 # /opt/MegaRAID/storcli/storcli64 /c0/v0 show all Controller = 0 Status = Success Description = None /c0/v0 : ====== ------------------------------------------------------------ DG/VD TYPE State Access Consist Cache sCC Size Name ------------------------------------------------------------ 0/0 RAID5 Dgrd RW Yes RaAWBD - 446.125 GB ------------------------------------------------------------ Cac=CacheCade|Rec=Recovery|OfLn=OffLine|Pdgd=Partially Degraded|dgrd=Degraded Optl=Optimal|RO=Read Only|RW=Read Write|B=Blocked|Consist=Consistent| Ra=Read Ahead Adaptive|R=Read Ahead Always|NR=No Read Ahead|WB=WriteBack| AWB=Always WriteBack|WT=WriteThrough|C=Cached IO|D=Direct IO|sCC=Scheduled Check Consistency PDs for VD 0 : ============ ---------------------------------------------------------------------------- EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp ---------------------------------------------------------------------------- 252:5 11 Rbld 0 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:3 9 Onln 0 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:4 37 Onln 0 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U ---------------------------------------------------------------------------- EID-Enclosure Device ID|Slt-Slot No.|DID-Device ID|DG-DriveGroup DHS-Dedicated Hot Spare|UGood-Unconfigured Good|GHS-Global Hotspare UBad-Unconfigured Bad|Onln-Online|Offln-Offline|Intf-Interface Med-Media Type|SED-Self Encryptive Drive|PI-Protection Info SeSz-Sector Size|Sp-Spun|U-Up|D-Down|T-Transition|F-Foreign VD0 Properties : ============== Strip Size = 256 KB Span Depth = 1 Number of Drives Per Span = 3 Disk Cache Policy = Enabled Encryption = None Data Protection = Disabled Active Operations = None Exposed to OS = Yes Creation Date = 22-05-2013 Creation Time = 05:28:54 PM Emulation type = None</code></pre> vd0はDegradedとなり、ホットスペアにしてあったスロット5番のドライブがvd0に加わり、Rebuild状態になっていることがわかります。 最後にvd0を削除してみます。 root@151:~# /opt/MegaRAID/storcli/storcli64 /c0/v0 del Controller = 0 Status = Success Description = Delete VD succeeded</code></pre># /opt/MegaRAID/storcli/storcli64 /c0/e252/s2-5 show Controller = 0 Status = Success Description = Show Drive Information Succeeded. Drive Information : ================= ---------------------------------------------------------------------------- EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp ---------------------------------------------------------------------------- 252:2 38 UGood - 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:3 9 UGood - 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:4 37 UGood - 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U 252:5 11 UGood - 223.062 GB SATA SSD N N 512B INTEL SSDSC2CW240A3 U ---------------------------------------------------------------------------- EID-Enclosure Device ID|Slt-Slot No.|DID-Device ID|DG-DriveGroup DHS-Dedicated Hot Spare|UGood-Unconfigured Good|GHS-Global Hotspare UBad-Unconfigured Bad|Onln-Online|Offln-Offline|Intf-Interface Med-Media Type|SED-Self Encryptive Drive|PI-Protection Info SeSz-Sector Size|Sp-Spun|U-Up|D-Down|T-Transition|F-Foreign</code></pre> スロット2，3，4，5のドライブが、最初の状態Unconfigured Goodに戻りました。 以上、見てきたように、StorCLIの使い方について試してみました。 3wareのtw_cliに慣れた管理者の方には、直感的で大変使い易いのではないかと思います。 参考までにStorCLIのダウンロードリンクと、リファレンスマニュアルへの直リンクを貼っておきます。 StorCLI http://www.lsi.com/downloads/Public/MegaRAID%20Common%20Files/1.03.11_StorCLI.zip リファレンスマニュアル http://www.lsi.com/downloads/Public/MegaRAID%20Common%20Files/StorCLI_RefMan_revf_.pdf もろもろLinpack Benchmarkしてみました 2013-05-21T00:00:00+00:00 こんにちは！ 今日は、引きこもって仕事をするには、もったいないくらいの良いお天気でしたね♪ なかなか良い季節になってきたので、週末が楽しみです。 前回に引き続き、いくつかのサーバでベンチマークを採る機会があったので、ここに晒します。 Linpack ベンチマークは「一番じゃなきゃダメですか」で有名なスパコンのランキングを決定するためにも使われる、有名なベンチマークソフトです。 LINPACK ベンチマークは LINPACK に基づいたベンチマークプログラムで、システムの浮動小数点演算性能を評価する。ジャック・ドンガラが考案したもので、理学・工学で一般的な n×n の線型方程式系 Ax = b を解く速度を測定する。このベンチマークの最新版はTOP500で世界の高速なコンピュータの性能値としてランキングに使用されている。　http://ja.wikipedia.org/wiki/LINPACK</a>　より </blockquote> スパコンの評価のためには、並列計算用のMPIライブラリや、行列計算ライブラリ、LINPACK本体等、いろいろセットアップが必要です。 クラスター構成ではない普通のSMPマシンを評価するには、IntelのOptimized LINPACK Benchmarkというのを使えば、お手軽にベンチマークができそうです。 まず、以下のページから、tarボールをダウンロードし、展開します。 http://software.intel.com/en-us/articles/intel-math-kernel-library-linpack-download/</a> wget http://registrationcenter.intel.com/irc_nas/3058/l_lpk_p_11.0.3.008.tgz tar xvf l_lpk_p_11.0.3.008.tgz </blockquote> 以下のディレクトリにベンチマーク本体、スクリプト、入力ファイルなどが用意されているので、そのディレクトリで標準的なrunme_xeon64などのスクリプトを実行すれば良さそうです。 cd linpack_11.0.3/benchmarks/linpack/ </blockquote> 試しに実行してみます。 ./runme_xeon64 This is a SAMPLE run script for SMP LINPACK. Change it to reflect the correct number of CPUs/threads, problem input files, etc.. Tue May 14 18:47:46 JST 2013 Intel(R) Optimized LINPACK Benchmark data Current date/time: Tue May 14 18:47:46 2013 CPU frequency: 2.932 GHz Number of CPUs: 1 Number of cores: 4 Number of threads: 8 Parameters are set to: Number of tests: 15 Number of equations to solve (problem size) : 1000 2000 5000 10000 15000 18000 20000 22000 25000 26000 27000 30000 35000 40000 45000 Leading dimension of array : 1000 2000 5008 10000 15000 18008 20016 22008 25000 26000 27000 30000 35000 40000 45000 Number of trials to run : 4 2 2 2 2 2 2 2 2 2 1 1 1 1 1 Data alignment value (in Kbytes) : 4 4 4 4 4 4 4 4 4 4 4 1 1 1 1 Maximum memory requested that can be used=3202964416, at the size=20000 =================== Timing linear equation system solver =================== Size LDA Align. Time(s) GFlops Residual Residual(norm) Check 1000 1000 4 0.038 17.4850 1.236872e-12 4.218050e-02 pass 1000 1000 4 0.037 17.9669 1.236872e-12 4.218050e-02 pass 1000 1000 4 0.037 17.9904 1.236872e-12 4.218050e-02 pass 1000 1000 4 0.037 18.0328 1.236872e-12 4.218050e-02 pass 2000 2000 4 0.271 19.7349 4.570122e-12 3.975446e-02 pass 2000 2000 4 0.270 19.7479 4.570122e-12 3.975446e-02 pass 5000 5008 4 2.512 33.1981 2.113014e-11 2.946428e-02 pass 5000 5008 4 2.492 33.4647 2.113014e-11 2.946428e-02 pass 10000 10000 4 17.385 38.3576 9.365270e-11 3.302289e-02 pass 10000 10000 4 17.431 38.2572 9.365270e-11 3.302289e-02 pass 15000 15000 4 59.425 37.8704 2.005595e-10 3.158845e-02 pass 15000 15000 4 60.409 37.2536 2.005595e-10 3.158845e-02 pass 18000 18008 4 103.157 37.6964 2.980711e-10 3.264245e-02 pass 18000 18008 4 102.891 37.7938 2.980711e-10 3.264245e-02 pass 20000 20016 4 142.172 37.5190 3.917629e-10 3.467960e-02 pass 20000 20016 4 142.003 37.5634 3.917629e-10 3.467960e-02 pass Performance Summary (GFlops) Size LDA Align. Average Maximal 1000 1000 4 17.8687 18.0328 2000 2000 4 19.7414 19.7479 5000 5008 4 33.3314 33.4647 10000 10000 4 38.3074 38.3576 15000 15000 4 37.5620 37.8704 18000 18008 4 37.7451 37.7938 20000 20016 4 37.5412 37.5634 Residual checks PASSED End of tests Done: Tue May 14 19:01:30 JST 2013</code></pre> 上記は、4コア、8スレッドのCPUを搭載したサーバーですが、自動的にCPUの数を認識して、適切なThread数を設定してくれているようです。 runme_xeon64スクリプトの中で、"export OMP_NUM_THREADS=4"のように明示的にスレッド数を指定することも可能です。 入力ファイルでいくつかproblem sizeが指定されていますが、搭載しているメモリの容量から判断して、大きすぎるものは実行されないようです。 swapを含む、メモリ容量で実行可否を判断しているようなので、可能ならswapoff -aするか、あるいは、入力ファイルから大きすぎるものを削除した方が良いかもしれません。 上記の結果からは、最大で、38.4GFlopsの性能であると、判断できます。 さて、このLinpackベンチマークを、弊社にあるいくつかの物理マシン、仮想マシン上で実行してみました。 物理マシン マシン名</th> CPU スペック</th> HT</th> メモリ GByte</th> 総クロック GHz</th> スコア GFlops</th> スコア/総クロック</th></tr></thead> 1</td> Xeon E5-2650 2.00GHz 8 core x 2cpu</td> on</td> 96</td> 32</td> 229.8</td> 7.18</td></tr> 2</td> Xeon E5-2650 2.00GHz 8 core x 2cpu</td> off</td> 96</td> 32</td> 231.0</td> 7.22</td></tr> 3</td> Xeon E5-2650 2.00GHz 4 core x 2cpu</td> on</td> 96</td> 16</td> 117.1</td> 7.32</td></tr> 4</td> Xeon E5-2603 1.80GHz 4 core x 2cpu</td> na</td> 96</td> 14.4</td> 103.8</td> 7.21</td></tr> 5</td> Xeon X5650 2.67GHz 6 core x 2cpu</td> on</td> 16</td> 32.04</td> 114.1</td> 3.56</td></tr> 6</td> Xeon X3440 2.53GHz 4 core x 1cpu</td> on</td> 4</td> 10.12</td> 38.0</td> 3.75</td></tr> 7</td> Xeon X3440 2.53GHz 4 core x 1cpu</td> on</td> 4</td> 10.12</td> 38.4</td> 3.79</td></tr> </tbody></table> マシンスペック 1,2,3は同一マシンで、Supermicro 1027R-WRF/Xeon E5-2650 x 2/メモリ 96MByte/Intel 520 SSD 240GB。2ではBIOSでHyperThreadingを無効化、3ではBIOSでアクティブコア数を4個に制限しています。 4 はSupermicro 1027R-WR/Xeon E5-2603 x 2/メモリ 96MByte/Intel 520 SSD 240GB 5 はIntel S5520SC/Xeon X5650 x 2/メモリ 16MByte/Adaptec ASR-5405/HGST SATA 2TB HDD 6,7 Intel S3420GP /Xeon X3440 x 1/メモリ 4MByte/Seagate SATA 320GB HDD 表中の総クロックGHzはクロックxコア数で計算してあります。 1と2を比べるとHyperThreadingをOFFにしても、スコアが変わらないことがわかります。また、1と3を比べると、コア数が半分になり総クロックが半分になると、スコアが約半分になっています。 また、3と4からは、総クロックにだいたい比例しているようです。 したがって、Linpack性能は、同じ世代のCPUであればHTの有無には依存せず、総クロックに比例すると考えられます。 CPUの世代の異なる1と5を比べると、最新のXeon E5-2650(Sandybridge)のスコアは約230GFlopsで、一世代前のXeon X5650(Westmere)のスコア約114GFlops比べて、倍以上の性能があることがわかります。 Xeon X5650(Westmere)とXeon X3440(Lynnfield)は同じ世代のプロセッサですが、 5と6を比べてみると、だいたい総クロックに比例した性能になっていることがわかります。 一番右の行にスコア/総クロックを示してみましたが、このページ</a>によると理論性能は、Nehalem/Westmere/Lynnfield世代で4、Sandybridge世代で8であるので、だいたいこれに近い値になっていることがわかります。 次の上記のマシン上に作成した仮想マシンの性能を調べてみました。 仮想マシン マシン名</th> 仮想マシン種類</th> CPU スペック</th> メモリGByte</th> 総クロックGHz</th> スコアGFlops</th> スコア/総クロック</th></tr></thead> kvm1</td> kvm</td> 2.0GHz x 2 (Xeon E5-2650) </td> 4</td> 4</td> 28.2</td> 7.05</td></tr> kvm2</td> kvm</td> 2.0GHz x 16 (Xeon E5-2650)</td> 4</td> 32</td> 187.3</td> 5.85</td></tr> kvm3</td> kvm</td> 2.67GHz x 2 (Xeon X5650)</td> 2</td> 5.34</td> 21.9</td> 4.10</td></tr> kvm4</td> kvm</td> 2.53GHz x 2 (Xeon X3440)</td> 2</td> 5.06</td> 20.13</td> 3.98</td></tr> sak1</td> Sakura VPS</td> 2.4GHz x 2 (Core 2 DuoT7700)</td> 1</td> 4.8</td> 11.7</td> 2.43</td></tr> xen1</td> xenserver 6.1</td> 1.8GHz x 8 (Xeon E5-2603)</td> 4</td> 14.4</td> 6.8</td> 0.47</td></tr> xen2</td> xenserver 6.1</td> 1.8GHz x 1 (Xeon E5-2603)</td> 4</td> 1.8</td> 6.8</td> 3.78</td></tr> </tbody></table> kvm1のスコア/総クロックは7.05で理論値の8に近く、上の物理マシン表と比べても遜色なく、なかなか優秀と言えます。しかしながらkvm2の場合には、5.85と若干下がった値になっています。kvmのゲストカーネルはNUMA対応カーネルにしていないので、それが原因かもしれません。 kvm3、kvm4のスコア/総クロックを見ると優秀ではありますが、理論値の4に非常に近いか、又は超えてしまっており、ちょっと不自然です。ターボブースト機能により、実際のコアのクロックが上がっているのかもしれません。 sak1のスコア/総クロックは2.43は、Core 2 Duoの理論値4よりもだいぶ小さく、あまり優秀ではありません。 xen1、xen2も、Sandybridge世代の理論値8よりもかなり小さく、全く優秀ではありません。xen1は8CPUにも関わらず、1CPUのxen2とスコアが変わらず、仮想の8CPUのスレッドが、一個の物理コア上で実行されているように見受けられます。 以上、まとめると、 Linpackの性能はCPUの世代間で進歩があり、同じ世代のCPUであれば、おおよそクロックxコア数に比例しています。 また、kvmの仮想マシンは総じて優秀であるが、NUMAアーキテクチャのホストでホストのCPUと同じくらいのCPUをゲストに割り当てようとすると、性能は総クロックで期待されるよりも落ちてしまう。 xenserverはあまり、優秀ではありません。 SakuraのVPSもあまり優秀ではありません。 性能を求めるなら、最新の物理サーバを用いるのがおすすめで、仮想マシンを使いたいなら、VPSサービスではなく、自前でkvmによる仮想環境作るのが良いと言えるでしょう。 KVMのゲストマシンとさくらのVPSでUnixBench採ってみました 2013-05-09T00:00:00+00:00 みなさん、こんにちは(^^)/ 楽しかったゴールデンウィークも終わってしましたが、いかがお過ごしでしょうか？ 私はというと、行楽日和の晴天を横目に、薄暗い事務所の中でコンピューターに向かって黙々と仕事をこなす毎日ですw さて、仕事でUnixBenchを採る機会がありましたので、個人的な備忘録の意味も含め、ここに記録して(晒して)おきたいと思います。 UnixBenchは以下のページから取ってきます。 https://code.google.com/p/byte-unixbench/</a> wget http://byte-unixbench.googlecode.com/files/UnixBench5.1.3.tgz tar xvf UnixBench5.1.3.tgz cd UnixBench </blockquote> USAGEをざっと眺めると、makeして./Runスクリプトを実行すれば用意されたすべてのテストが実行されるらしいです。 バージョン5.1から新しく用意されたGRAPHICテストを実行したい場合には、Makefileを編集し"GRAPHIC_TESTS = defined"の行を有効にしてmakeする必要がありますが、今回は不要です。 CPUが二つ以上のシステムの場合、テストは二回実行されます。一回目は一セットのテストが同時実行され、二回目はCPUの数をNとすると、Nセットのテストが並列に同時実行されます。 テストの実行時間は一セットおよそ29分で、マルチCPUマシン上で、GRAPHICテストを行わない場合、およそ、58分程度かかるということです。 今回UnixBenchを実行したのは以下のマシンです。 (1)さくらのVPS512@980円　 CPU Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz　x 2 メモリー　1GByte OS Debian 6.0.7 Kernel 2.6.32 SMP x86_64 </blockquote> (2)内製KVMゲストマシン1　(ホストCPU　Xeon X5650 @ 2.67GHz) CPU QEMU Virtual CPU version 1.0 2.67GHz x 2 メモリー 512MByte OS Debian 7.0 Kernel 3.9.1 SMP x86_64 </blockquote> (3)内製KVMゲストマシン2　(ホストCPU　Xeon X3440 @ 2.53GHz) CPU QEMU Virtual CPU version 1.0 2.52GHz x 2 メモリー 512MByte OS Debian 7.0 Kernel 3.8.8 SMP x86_64 </blockquote> (4)(3)のホストマシン　 CPU Intel(R) Xeon(R) CPU X3440 @ 2.53GHz　4core 8thread メモリー 4GByte OS Debian 6.0.7 Kernel 3.4.0 SMP x86_64 </blockquote> (1)さくらのVPS512の結果 </code></pre></blockquote> BYTE UNIX Benchmarks (Version 5.1.3) System: sak1: GNU/Linux OS: GNU/Linux -- 2.6.32-5-amd64 -- #1 SMP Mon Jan 9 20:49:59 UTC 2012 Machine: x86_64 (unknown) Language: en_US.utf8 (charmap="ANSI_X3.4-1968", collate="ANSI_X3.4-1968") CPU 0: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (5320.2 bogomips) x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET CPU 1: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (5320.2 bogomips) x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET 13:48:04 up 146 days, 11:37, 1 user, load average: 0.22, 0.12, 0.04; runlevel Benchmark Run: Wed May 08 2013 13:48:04 - 14:16:18 2 CPUs in system; running 1 parallel copy of tests Dhrystone 2 using register variables 24085942.4 lps (10.0 s, 7 samples) Double-Precision Whetstone 3098.5 MWIPS (9.9 s, 7 samples) Execl Throughput 2249.6 lps (30.0 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 671875.9 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 196527.3 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 1413265.2 KBps (30.0 s, 2 samples) Pipe Throughput 1897140.7 lps (10.0 s, 7 samples) Pipe-based Context Switching 287952.8 lps (10.0 s, 7 samples) Process Creation 5839.1 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 5899.8 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 1365.4 lpm (60.0 s, 2 samples) System Call Overhead 3301152.6 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 24085942.4 2063.9 Double-Precision Whetstone 55.0 3098.5 563.4 Execl Throughput 43.0 2249.6 523.2 File Copy 1024 bufsize 2000 maxblocks 3960.0 671875.9 1696.7 File Copy 256 bufsize 500 maxblocks 1655.0 196527.3 1187.5 File Copy 4096 bufsize 8000 maxblocks 5800.0 1413265.2 2436.7 Pipe Throughput 12440.0 1897140.7 1525.0 Pipe-based Context Switching 4000.0 287952.8 719.9 Process Creation 126.0 5839.1 463.4 Shell Scripts (1 concurrent) 42.4 5899.8 1391.5 Shell Scripts (8 concurrent) 6.0 1365.4 2275.7 System Call Overhead 15000.0 3301152.6 2200.8 ======== System Benchmarks Index Score 1217.3 Benchmark Run: Wed May 08 2013 14:16:18 - 14:44:33 2 CPUs in system; running 2 parallel copies of tests Dhrystone 2 using register variables 48543864.7 lps (10.0 s, 7 samples) Double-Precision Whetstone 6093.3 MWIPS (10.0 s, 7 samples) Execl Throughput 6641.9 lps (29.6 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 775102.5 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 214100.7 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 2170934.3 KBps (30.0 s, 2 samples) Pipe Throughput 3701877.8 lps (10.0 s, 7 samples) Pipe-based Context Switching 603992.9 lps (10.0 s, 7 samples) Process Creation 21862.8 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 10135.8 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 1410.2 lpm (60.0 s, 2 samples) System Call Overhead 5432476.9 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 48543864.7 4159.7 Double-Precision Whetstone 55.0 6093.3 1107.9 Execl Throughput 43.0 6641.9 1544.6 File Copy 1024 bufsize 2000 maxblocks 3960.0 775102.5 1957.3 File Copy 256 bufsize 500 maxblocks 1655.0 214100.7 1293.7 File Copy 4096 bufsize 8000 maxblocks 5800.0 2170934.3 3743.0 Pipe Throughput 12440.0 3701877.8 2975.8 Pipe-based Context Switching 4000.0 603992.9 1510.0 Process Creation 126.0 21862.8 1735.1 Shell Scripts (1 concurrent) 42.4 10135.8 2390.5 Shell Scripts (8 concurrent) 6.0 1410.2 2350.3 System Call Overhead 15000.0 5432476.9 3621.7 ======== System Benchmarks Index Score 2166.7 (2)内製KVMゲストマシン1　(ホストCPU　Xeon X5650 @ 2.67GHz) > ``` BYTE UNIX Benchmarks (Version 5.1.3) System: v147: GNU/Linux OS: GNU/Linux -- 3.9.1-64kvmg01 -- #1 SMP Wed May 8 22:00:45 JST 2013 Machine: x86_64 (unknown) Language: en_US.utf8 (charmap="ANSI_X3.4-1968", collate="ANSI_X3.4-1968") CPU 0: QEMU Virtual CPU version 1.0 (5333.3 bogomips) x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET CPU 1: QEMU Virtual CPU version 1.0 (5333.3 bogomips) x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET 15:34:32 up 0 min, 1 user, load average: 0.16, 0.03, 0.01; runlevel 2 ------------------------------------------------------------------------ Benchmark Run: Thu May 09 2013 15:34:32 - 16:02:31 2 CPUs in system; running 1 parallel copy of tests Dhrystone 2 using register variables 30879094.2 lps (10.0 s, 7 samples) Double-Precision Whetstone 3749.0 MWIPS (9.1 s, 7 samples) Execl Throughput 4534.2 lps (30.0 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 1097888.6 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 301066.2 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 2055234.3 KBps (30.0 s, 2 samples) Pipe Throughput 2216106.5 lps (10.0 s, 7 samples) Pipe-based Context Switching 381391.5 lps (10.0 s, 7 samples) Process Creation 5417.9 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 9541.0 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 2040.2 lpm (60.0 s, 2 samples) System Call Overhead 4035159.8 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 30879094.2 2646.0 Double-Precision Whetstone 55.0 3749.0 681.6 Execl Throughput 43.0 4534.2 1054.5 File Copy 1024 bufsize 2000 maxblocks 3960.0 1097888.6 2772.4 File Copy 256 bufsize 500 maxblocks 1655.0 301066.2 1819.1 File Copy 4096 bufsize 8000 maxblocks 5800.0 2055234.3 3543.5 Pipe Throughput 12440.0 2216106.5 1781.4 Pipe-based Context Switching 4000.0 381391.5 953.5 Process Creation 126.0 5417.9 430.0 Shell Scripts (1 concurrent) 42.4 9541.0 2250.2 Shell Scripts (8 concurrent) 6.0 2040.2 3400.3 System Call Overhead 15000.0 4035159.8 2690.1 ======== System Benchmarks Index Score 1681.5 ------------------------------------------------------------------------ Benchmark Run: Thu May 09 2013 16:02:31 - 16:30:31 2 CPUs in system; running 2 parallel copies of tests Dhrystone 2 using register variables 61886737.4 lps (10.0 s, 7 samples) Double-Precision Whetstone 7438.8 MWIPS (9.1 s, 7 samples) Execl Throughput 8960.8 lps (30.0 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 1356632.6 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 228901.8 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 3404779.9 KBps (30.0 s, 2 samples) Pipe Throughput 4411432.3 lps (10.0 s, 7 samples) Pipe-based Context Switching 792350.4 lps (10.0 s, 7 samples) Process Creation 29506.4 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 16737.4 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 2339.6 lpm (60.0 s, 2 samples) System Call Overhead 6544409.1 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 61886737.4 5303.1 Double-Precision Whetstone 55.0 7438.8 1352.5 Execl Throughput 43.0 8960.8 2083.9 File Copy 1024 bufsize 2000 maxblocks 3960.0 1356632.6 3425.8 File Copy 256 bufsize 500 maxblocks 1655.0 228901.8 1383.1 File Copy 4096 bufsize 8000 maxblocks 5800.0 3404779.9 5870.3 Pipe Throughput 12440.0 4411432.3 3546.2 Pipe-based Context Switching 4000.0 792350.4 1980.9 Process Creation 126.0 29506.4 2341.8 Shell Scripts (1 concurrent) 42.4 16737.4 3947.5 Shell Scripts (8 concurrent) 6.0 2339.6 3899.4 System Call Overhead 15000.0 6544409.1 4362.9 ======== System Benchmarks Index Score 2963.7</code></pre> (3)内製KVMゲストマシン2　(ホストCPU　Xeon X3440 @ 2.53GHz) </code></pre></blockquote> BYTE UNIX Benchmarks (Version 5.1.3) System: v153: GNU/Linux OS: GNU/Linux -- 3.8.8-64kvmg01 -- #1 SMP Mon Apr 22 23:44:25 JST 2013 Machine: x86_64 (unknown) Language: en_US.utf8 (charmap="ANSI_X3.4-1968", collate="ANSI_X3.4-1968") CPU 0: QEMU Virtual CPU version 1.4.1 (5066.6 bogomips) x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET CPU 1: QEMU Virtual CPU version 1.4.1 (5066.6 bogomips) x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET 04:21:48 up 2 min, 2 users, load average: 0.06, 0.02, 0.01; runlevel 2</h2> Benchmark Run: Fri May 10 2013 04:21:48 - 04:49:56 2 CPUs in system; running 1 parallel copy of tests Dhrystone 2 using register variables 28700468.1 lps (10.0 s, 7 samples) Double-Precision Whetstone 3603.2 MWIPS (10.0 s, 7 samples) Execl Throughput 4820.8 lps (30.0 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 1136729.9 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 313902.4 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 2329713.1 KBps (30.0 s, 2 samples) Pipe Throughput 1937085.6 lps (10.0 s, 7 samples) Pipe-based Context Switching 416442.2 lps (10.0 s, 7 samples) Process Creation 4905.0 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 5206.7 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 2342.7 lpm (60.0 s, 2 samples) System Call Overhead 3696866.5 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 28700468.1 2459.3 Double-Precision Whetstone 55.0 3603.2 655.1 Execl Throughput 43.0 4820.8 1121.1 File Copy 1024 bufsize 2000 maxblocks 3960.0 1136729.9 2870.5 File Copy 256 bufsize 500 maxblocks 1655.0 313902.4 1896.7 File Copy 4096 bufsize 8000 maxblocks 5800.0 2329713.1 4016.7 Pipe Throughput 12440.0 1937085.6 1557.1 Pipe-based Context Switching 4000.0 416442.2 1041.1 Process Creation 126.0 4905.0 389.3 Shell Scripts (1 concurrent) 42.4 5206.7 1228.0 Shell Scripts (8 concurrent) 6.0 2342.7 3904.5 System Call Overhead 15000.0 3696866.5 2464.6 ======== System Benchmarks Index Score 1606.1</h2> Benchmark Run: Fri May 10 2013 04:49:56 - 05:18:04 2 CPUs in system; running 2 parallel copies of tests Dhrystone 2 using register variables 54903785.4 lps (10.0 s, 7 samples) Double-Precision Whetstone 6894.6 MWIPS (10.0 s, 7 samples) Execl Throughput 9306.8 lps (30.0 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 1347898.4 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 354944.7 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 3256880.8 KBps (30.0 s, 2 samples) Pipe Throughput 3680672.6 lps (10.0 s, 7 samples) Pipe-based Context Switching 740043.1 lps (10.0 s, 7 samples) Process Creation 34071.7 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 17647.1 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 2415.1 lpm (60.0 s, 2 samples) System Call Overhead 5929544.7 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 54903785.4 4704.7 Double-Precision Whetstone 55.0 6894.6 1253.6 Execl Throughput 43.0 9306.8 2164.4 File Copy 1024 bufsize 2000 maxblocks 3960.0 1347898.4 3403.8 File Copy 256 bufsize 500 maxblocks 1655.0 354944.7 2144.7 File Copy 4096 bufsize 8000 maxblocks 5800.0 3256880.8 5615.3 Pipe Throughput 12440.0 3680672.6 2958.7 Pipe-based Context Switching 4000.0 740043.1 1850.1 Process Creation 126.0 34071.7 2704.1 Shell Scripts (1 concurrent) 42.4 17647.1 4162.0 Shell Scripts (8 concurrent) 6.0 2415.1 4025.1 System Call Overhead 15000.0 5929544.7 3953.0 ======== System Benchmarks Index Score 2991.1 (4)(3)のホストマシン　 > ``` BYTE UNIX Benchmarks (Version 5.1.3) System: kvm: GNU/Linux OS: GNU/Linux -- 3.4.0-64kvmh01 -- #1 SMP Fri May 25 14:59:18 JST 2012 Machine: x86_64 (unknown) Language: en_US.utf8 (charmap="ANSI_X3.4-1968", collate="ANSI_X3.4-1968") CPU 0: Intel(R) Xeon(R) CPU X3440 @ 2.53GHz (5066.2 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 1: Intel(R) Xeon(R) CPU X3440 @ 2.53GHz (5066.2 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 2: Intel(R) Xeon(R) CPU X3440 @ 2.53GHz (5066.2 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 3: Intel(R) Xeon(R) CPU X3440 @ 2.53GHz (5066.2 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 4: Intel(R) Xeon(R) CPU X3440 @ 2.53GHz (5066.2 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 5: Intel(R) Xeon(R) CPU X3440 @ 2.53GHz (5066.2 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 6: Intel(R) Xeon(R) CPU X3440 @ 2.53GHz (5066.2 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 7: Intel(R) Xeon(R) CPU X3440 @ 2.53GHz (5066.2 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization 20:37:04 up 113 days, 7:51, 2 users, load average: 0.50, 0.22, 0.52; runlevel 2 ------------------------------------------------------------------------ Benchmark Run: Thu May 09 2013 20:37:04 - 21:05:17 8 CPUs in system; running 1 parallel copy of tests Dhrystone 2 using register variables 28301315.7 lps (10.0 s, 7 samples) Double-Precision Whetstone 3470.1 MWIPS (10.0 s, 7 samples) Execl Throughput 1569.0 lps (29.9 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 841958.4 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 235274.3 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 1938405.5 KBps (30.0 s, 2 samples) Pipe Throughput 1827474.3 lps (10.0 s, 7 samples) Pipe-based Context Switching 54481.2 lps (10.0 s, 7 samples) Process Creation 3844.0 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 3859.0 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 2910.4 lpm (60.0 s, 2 samples) System Call Overhead 3240538.1 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 28301315.7 2425.1 Double-Precision Whetstone 55.0 3470.1 630.9 Execl Throughput 43.0 1569.0 364.9 File Copy 1024 bufsize 2000 maxblocks 3960.0 841958.4 2126.2 File Copy 256 bufsize 500 maxblocks 1655.0 235274.3 1421.6 File Copy 4096 bufsize 8000 maxblocks 5800.0 1938405.5 3342.1 Pipe Throughput 12440.0 1827474.3 1469.0 Pipe-based Context Switching 4000.0 54481.2 136.2 Process Creation 126.0 3844.0 305.1 Shell Scripts (1 concurrent) 42.4 3859.0 910.1 Shell Scripts (8 concurrent) 6.0 2910.4 4850.6 System Call Overhead 15000.0 3240538.1 2160.4 ======== System Benchmarks Index Score 1104.1 ------------------------------------------------------------------------ Benchmark Run: Thu May 09 2013 21:05:17 - 21:33:41 8 CPUs in system; running 8 parallel copies of tests Dhrystone 2 using register variables 110467624.7 lps (10.0 s, 7 samples) Double-Precision Whetstone 21211.4 MWIPS (9.9 s, 7 samples) Execl Throughput 12952.9 lps (30.0 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 495833.5 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 134897.1 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 1547822.4 KBps (30.0 s, 2 samples) Pipe Throughput 2276741.3 lps (10.0 s, 7 samples) Pipe-based Context Switching 455844.3 lps (10.0 s, 7 samples) Process Creation 30000.0 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 28230.5 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 3724.5 lpm (60.0 s, 2 samples) System Call Overhead 3454619.9 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 110467624.7 9465.9 Double-Precision Whetstone 55.0 21211.4 3856.6 Execl Throughput 43.0 12952.9 3012.3 File Copy 1024 bufsize 2000 maxblocks 3960.0 495833.5 1252.1 File Copy 256 bufsize 500 maxblocks 1655.0 134897.1 815.1 File Copy 4096 bufsize 8000 maxblocks 5800.0 1547822.4 2668.7 Pipe Throughput 12440.0 2276741.3 1830.2 Pipe-based Context Switching 4000.0 455844.3 1139.6 Process Creation 126.0 30000.0 2381.0 Shell Scripts (1 concurrent) 42.4 28230.5 6658.1 Shell Scripts (8 concurrent) 6.0 3724.5 6207.5 System Call Overhead 15000.0 3454619.9 2303.1 ======== System Benchmarks Index Score 2686.9</code></pre> 以上の結果を見ると、CPU8個のサーバより、2CPUの仮想マシンゲストの方が最終スコアが高かったり、FileCopy関連のインデックスが仮想マシンの方が軒並み高かったり、理解に苦しむ結果が出ています。 今後、別のベンチマークツールで試してみたいと思います。 追記　System Benchmarks Index Scoreではなく、個別のテストごとに比較すべきか。 出荷を待つサーバたち 2013-04-03T00:00:00+00:00 出荷前テスト中のサーバたちです。 サーバの組上げ後、一日から二日かけて、様々な動作チェック、メモリテストや負荷テストなどを行い、お客様の元へお届けしています。パーツに初期不良がある場合、通常、この段階で発覚します。 今回のサーバは、デュアルXeon E5-2650、メモリー96GB、LSI 9266-8i、Intel 520 SSD という非常に高性能な構成です。 お客様の元で、DBサーバとして大活躍することを期待しております。 CentOSをネットワークインストールしてみる 2013-01-10T00:00:00+00:00 みなさんこんにちは！ ここ2、3年、OSのインストールも自分でやらなくなってしまった気がしますが、とあるサーバーにCentOS 6.3をインストールすることになりました。備忘録的に記録を書いておこうと思います。 CentOSのダウンロードサイトは、この辺り</a>にリスト化されているので、この中のどれかから持ってくれば良さそうです。 今回、linuxカーネルダウンロードでおなじみのkernel.orgのサイト</a>からダウンロードして来ようと思います。 ディレクトリを眺めていると、/centos/6.3/os/x86_64/images/pxeboot にネットワークインストールに必要なカーネルとinitrdイメージが置いてあるようなので、ダウンロードしてpxeサーバに置いておきます。 initrd.img 06-Jul-2012 10:13 30M vmlinuz 06-Jul-2012 10:13 3.8M</code></pre> それにしても、カーネルもinitrdもでかいですね…(^_^;) pxelinux..cfg/defaultに以下の行を追加 label cent63 kernel img/centos/6.3-x86_64/vmlinuz append vga=normal initrd=img/centos/6.3-x86_64/initrd.img panic=10 text console=tty0 </blockquote> 上記で指定した場所に、先ほどファイルを置いておきます。 tree img/centos/6.3-x86_64/</h1> img/centos/6.3-x86_64/ ├── initrd.img └── vmlinuz 0 directories, 2 files </blockquote> そして対象サーバをpxebootすると、弊社のサーバでは以下の様なメニュー画面が表示されます。 cent63を選択すると、無事インストーラが立ち上がりました。 後は普通にインストールを進めます。 ネットワーク経由でインストールするので、次のメニューではURLを選択します。 URLには、　http://mirrors.kernel.org/centos/6.3/os/x86_64/　と入力し、OKを押します。 すると、インストールイメージを取得します。 その後メニューで、textモードを選択するとインストーラーが起動します。 後は、普通にインストールすればOKです。 シングルソケットローコスト　Intelサーバー 2012-11-13T00:00:00+00:00 こんにちは。 Intelのローコスト、シングルソケットサーバの写真です。 固定式ＨＤＤベイが4つ、奥行きも短くシンプルなサーバです。 WEBサーバやＬｉｎｕｘルータ用にいかがでしょうか。 (製品紹介ページ</a>) iodrive2入荷しました 2012-10-05T00:00:00+00:00 FusionIOが製造しているpci expressタイプのフラッシュストレージiodrive2が入荷しました。http://www.fusionio.com/platforms/iodrive2/</a> SSD等のフラッシュメモリを利用したデバイスの登場により、人気のWEBサイト、ゲームサイトなどでボトルネックになりがちだった、データベースサーバが革新的に高速になるようです。 512ByteのランダムIO性能(IOPS)は、Readが143k、Writeが535kだそうです。　バンド幅に換算すると、それぞれ71.5MB/sec、267.5MB/secと、驚異的な性能です。 弊社ではFusionIOのiodriveシリーズを搭載可能なサーバを扱っております。 今回は、下の写真のようなサーバに組み込んで出荷しました。 ブログ 2012-07-06T00:00:00+00:00 構えて文章を書こうとするので、なかなか記事が書けない。下書きに未完の記事がいくつかたまっていて、旬を過ぎてしまったものもちらほら… そういう意味では、構えずに書けるマイクロブログ、Twitterの登場は革命的だったのだけど、人の言動が気になってしまうのと、ソーシャル的なやり取りが面倒くさい。 非ソーシャルなつぶやきとして、書いて行こうかな… この投稿もたいした結論が無いので、公開をためらっているナウ KVM用のマシンの引越し 2012-05-29T00:00:00+00:00 先日立ち上げたKVM用のマシン</a>ですが、同じ機種のwindows serverマシンが故障で起動不能になってしまったため、代替機として使用することになってしまいました。そこで、弊社で過去に販売していたIntel製の1Uサーバに引っ越すことにしました。 スペックは CPU: Intel QuadCore Xeon X3440, 2.53GHz, cache 8 MB　 MEM: DDR2 800MHz ECC Unbuffered 2GB x2　 HDD: Seagate ST3320613AS 320GB SATA　 NIC: Intel 82574L / 82578DM</code></pre> と、メモリが若干少ないですが、なかなか素敵なサーバです。メモリは機会を見て増設することにします。 ちなみに、このサーバの後継機種はこちら</a>になります。最新のIntel Xeon E3-12xx v2(Ivybridge)シリーズのプロセッサを搭載していて大変コストパフォーマンスに優れています。 引越し作業は次の様にしました。まず、HDDを載せ替えてブートしてみます。ネットワークが認識しなかったので、ホストカーネルをコンパイルし直しe1000eを有効にしました。 このマシンのKVM環境、前回のブログを書いてからそのまま放置していたので、まだ完成していません。 近いうちにちゃんと使えるようにしておきたいと思います。 10GBaseTとSFP+DACの比較 2012-05-14T00:00:00+00:00 タイトルの件について調べ物をしたので、メモ。 レイテンシ 10GBaseTの規格ではエラー無くデータを転送するために、ブロックエンコーディングを行う。そのためには、ブロックサイズ分のデータを送信PHYに読み込み、エンコーディングを行ったのち、送信することが必要である。受信側では、その反対が必要である。規格によると、送受信PHYのペアで2.56μsの遅延を許容している。ブロックデータのサイズを考慮に入れると、リンクあたり2μs以下にすることは不可能である。 SFP+の場合には、ブロックエンコーディングが無く、より単純なエレクトロニクス構成であるため、遅延は典型値で300ns程度である。 それぞれの場合に、さらにメディア遅延を考慮する必用があるが、光であれ電気信号であれ、およそ5ns/m程度である。 最大ケーブル長 10GBaseTの場合、Cat6AまたはCat7ケーブルの利用により、100mまで通信可能である。 パッチパネルも使用可能である。 ダイレクトアタッチケーブルの場合、8.5mまでである。 25mまで大丈夫なケーブルも提案されている。 消費電力 10GBaseTは4W-6W/port(片側) SFP+DACは1.5W/port(片側) ソースは以下のホワイトペーパー http://www.missioncriticalmagazine.com/ext/resources/MC/Home/Files/PDFs/WP_Blade_Ethernet_Cabling.pdf</a> HPCなどの分野では遅延が少ない方が良いので、SFP+DACの方がお勧めということらしい。 Webやゲームのデータセンター用途で、2.6µsの遅延が問題になるのか、気になるところ。 ちなみにアリスタの10Gスイッチの遅延は、以下のサイトによると10GBaseTで3-3.6µs、SFP+で0.8-1.15µsである。 http://www.aristanetworks.com/jp/products/7050series/7050t</a> http://www.aristanetworks.com/jp/products/7050series/7050s</a> Intel 10GBaseT NICのドライバ 2012-05-14T00:00:00+00:00 linuxでは、Intel の10G NIC X540はixgbeでサポートされるようだ。 Device 8086:1528 http://pci-ids.ucw.cz/read/PC/8086/1528</a> 2.6.38からサポートされている http://kernelnewbies.org/Linux_2_6_38-DriversArch</a> drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c バニラカーネルであれば使えそう。 10GBaseTイーサネットに関して調べ物 2012-05-10T00:00:00+00:00 10GbeのインターフェイスにはCX4、SFP+ファイバー、SFP+ダイレクトアタッチカッパー(DAC)、10GBaseTなどがある。 CX4 古い技術で、ケーブルの太さやコネクタの大きさなどから、高集積化には向かない。ケーブル長15mまで。</li> </ul> SFP+ファイバー　10GBase-SR 高価である </li> 低消費電力、ケーブル長300mまで。 </li> サーバにネットワークカードの増設が必用。 </li> </ul> SFP+DAC 比較的安価である。ケーブル長は7mまで。 </li> サーバにネットワークカードの増設が必用。 </li> </ul> 10GBaseT 安価である。 </li> 従来、消費電力が大きく、高コストであると思われていたが、最近のプロセステクノロジーによりそうでもなくなった。NICの消費電力が初期の25W/portから6W/portに低下した。 </li> 1000BaseTイーサネット環境とポート互換性がある。1ギガビットのNICを持つサーバを10GBaseTのスイッチに接続でき、10GBaseTのNICを持つサーバを1ギガのスイッチに接続することができる。 </li> サーバにネットワークカードの増設が必用。10GBaseTポートが搭載されたマザーが出始めている。 </li> レイテンシー2μs～4μs。HPCユーザや高頻度な金融取引の用途では、気になるかもしれない。 </li> 普通はCPUの割り込み負荷低減のために、Interrupt Moderationが使われ、その場合には～100μsのレイテンシーが意図的に追加されるので問題ない。 </li> </ul> 以上、Intelのホワイトペーパーより http://www.intel.com/content/www/us/en/network-adapters/10-gigabit-network-adapters/10-gigabit-ethernet-10gbase-t-paper.html</a> 10GBaseTポート標準搭載のサーバの例 Supermicro 1027R-WRFT+ http://www.supermicro.com/products/system/1U/1027/SYS-1027R-WRFT_.cfm</a> Supermicro 6017R-N3RFT+ http://www.supermicro.com/products/system/1U/6017/SYS-6017R-N3RFT_.cfm</a> 10GBaseT x 48ポートスイッチ Arista 7050T-52/7050T-64 http://www.aristanetworks.com/jp/products/7050series/7050t</a> いずれも弊社から、販売可能です！ 10ギガビットイーサネット 2012-05-08T00:00:00+00:00 そろそろ、10ギガビットイーサネットの時代に入ってきました。 データセンター向けのハイエンドソリューションやHPC向けの高速ネットワーク用途では、10ギガビットのソリューションは数年前から利用されてきたようです。 しかし、数ある10ギガの規格のうちどれがが標準になるか見極めるのが難しく、機器も高価で、なかなか導入が広まらない状況にあったと思います。 最近になって、SFP+ Direct Attach ケーブルを利用したソリューションや、10GBaseTソリューションで、比較的安価な製品が出始めています。 今年は、一気に10ギガビットイーサネットのソリューションが普及するのではないでしょうか。 弊社では、10GBaseT デュアルポートをオンボード搭載したサーバ、Arista Networks社の10GBaseTスイッチなどを、販売していきたいと思います。 Intel SSD 520 240GB 購入しました 2012-04-14T00:00:00+00:00 先日発売されたIntel 520 SSDを購入しました。 インターフェースはSATA 6Gb/s、カタログスペックはシーケンシャルリード 550MB/s、シーケンシャルライト 520MB/s、4KB Random Read 50,000 IOPS、4KB Random Write 80,000 IOPSと大変高性能です。またMTBFは1,200,000時間でニアラインクラスのHDDと同等の信頼性です。 </th></tr></thead> Intelのカッコいい箱はCPU等と同様のカラーリング。</td></tr> </tbody></table> </th></tr></thead> 同梱物の写真 SSD本体、3.5インチマウンター、CD、説明書、シール、電源ケーブル、SATAケーブル、ネジが同梱されています。</td></tr> </tbody></table> </th></tr></thead> 3.5インチマウンタ。通常の電源ケーブルとSATAケーブルを利用する。</td></tr> </tbody></table> </th></tr></thead> SSD本体</td></tr> </tbody></table> </th></tr></thead> カッコいいシールはパソコンに貼るも善し。</td></tr> </tbody></table> Raidカードに8本ぶら下げたら、FusionIOなんかよりもお得かも知れないですね。 Kernel Virtual Machine(kvm)のセットアップ 2012-02-15T00:00:00+00:00 いくつもあるサーバを、仮想化によりまとめることができれば、サーバの保管場所や電気代の節約になる。私の会社ではいくつかのサーバを仮想マシン上で運用している。kvmによる仮想環境の再構築する機会があったので、備忘録的にノウハウというか、工夫した部分について、まとめておきたいと思う。 kvmはそれ用に構築したLinuxカーネルをハイパーバイザーとする仮想マシンである。GuestOSはWindowsやLinuxのみならず、様々なOSがサポートされている。 http://www.linux-kvm.org/page/Guest_Support_Status</a>　 今回はDebianLinux上で、バニラカーネルをkvmホスト用に自前でコンパイルしたものに入れ替え、ゲストOSとしてDebianLinuxを複数動かせるようにする。ゲストOSはWEBサーバなどのネットワークサーバ用途を想定しているので、GUI機能は必要ない。したがって、コンソールログインとSSHログインが可能になれば良しとすることにした。 最近のDebianLinuxでは、おそらく標準でGUIを使ってkvmを利用可能である。しかし、仕事で使うとなると中身や仕組みをできるだけ熟知していたくもあるので、余分な機能で被われたディストリビューション標準のツールをあえて使わないことにした。 ハードウェアは、ちょっと昔のDellT105が遊んでいたので、これを使うことにした。今となってはそれほど強力なマシンではないが、4コアのAMD Opteronを搭載しており、メモリスロットも4つある。これにDDR2 ECC 2GBを4本積んで、8GBのメモリを確保した。 1. ハードウェアスペック ** ** CPU: Quad-Core AMD Opteron 1352, 2.1GHz, cache 512 KB MEM: DDR2 800MHz ECC Unbuffered 4GB x8 HDD: Seagate ST3320613AS 320GB SATA NIC: Broadcom NetXtreme BCM5722</code></pre> kvmで仮想マシンを作る場合、IntelのCPUであればIntel VT、AMDのCPUであればAMD-Vに対応している必要がある。CPUのそれらの仮想化支援機能が無ければただの低速エミュレーターになってしまう。 CPUにそれらの機能が備わっているかどうかはメーカーのサイトで確認してもいいし、Linuxが既に動いている実機上で、以下のように確認しても良い。 AMDのマシンであれば、/proc/cpuinfoのflagsを見て、svmというのがあれば良い。 root@kvm:~# egrep flags /proc/cpuinfo |head -n 1 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs npt lbrv svm_lock</code></pre> Intelのマシンの場合、vmxというのがあれば良い。 ktaka@hana:~$ egrep flags /proc/cpuinfo |head -n 1 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm ida arat epb dts tpr_shadow vnmi flexpriority ept vpid</code></pre> ** ** 2. ホストカーネルの構築 カーネルはkernel.orgにあるlinux-3.2.9をコンパイルして利用する。 このページ</a>にKVMのホストカーネルの構築に必要なコンパイルフラグがまとめてあるので、これを参考にカーネルを構築した。実際には以下の関連フラグを有効にした。 CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_MEM_RES_CTLR=y CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y CONFIG_CGROUP_PERF=y CONFIG_CGROUP_SCHED=y CONFIG_BLK_CGROUP=m CONFIG_DEBUG_BLK_CGROUP=y CONFIG_HIGH_RES_TIMERS=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_COMPACTION=y CONFIG_MIGRATION=y CONFIG_KSM=y CONFIG_HPET=y CONFIG_HPET_MMAP=y CONFIG_HAVE_KVM=y CONFIG_HAVE_KVM_IRQCHIP=y CONFIG_HAVE_KVM_EVENTFD=y CONFIG_KVM_APIC_ARCHITECTURE=y CONFIG_KVM_MMIO=y CONFIG_KVM_ASYNC_PF=y CONFIG_VIRTUALIZATION=y CONFIG_KVM=m CONFIG_KVM_INTEL=m CONFIG_KVM_AMD=m CONFIG_KVM_MMU_AUDIT=y CONFIG_VHOST_NET=m</code></pre> KVMホスト上でブリッジネットワークを利用するために必要な以下のフラグも有効にした。 CONFIG_BRIDGE_NETFILTER=y CONFIG_BRIDGE=m CONFIG_BRIDGE_IGMP_SNOOPING=y CONFIG_STP=m CONFIG_LLC=m</code></pre> カーネルコンパイル&インストール後、新規カーネルでブートしバージョン確認 root@kvm:~# uname -a Linux kvm 3.2.9-64kvmh01 #1 SMP Mon Mar 5 21:47:42 JST 2012 x86_64 GNU/Linux</code></pre> 関連モジュールの確認 root@kvm:~# lsmod |egrep "kvm|bridge" kvm_amd 71505 0 kvm 566158 1 kvm_amd bridge 125971 0 stp 2987 1 bridge llc 8862 2 bridge,stp</code></pre> 3. ホストOSのネットワーク設定 kvm用のブリッジインターフェースkbr0を作成する。 以下の内容で設定ファイル/etc/network/interfacesを作成する。 auto lo kbr0 iface lo inet loopback iface kbr0 inet static bridge_ports eth0 bridge_stp off bridge_maxwait 2 address 192.168.20.9 netmask 255.255.252.0 network 192.168.20.0 broadcast 192.168.20.255 gateway 192.168.20.1 pre-up /sbin/ip link set dev eth0 up</code></pre> ホストOSを再起動すると、以下の様な状態になります。 ブリッジの状態確認 root@kvm:~# brctl show bridge name bridge id STP enabled interfaces kbr0 8000.0022190601e3 no eth0</code></pre> ブリッジインターフェースkbr0が作成され、eth0が接続されている。 IPアドレスの確認 root@kvm:~# ip add 1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: eth0: mtu 1500 qdisc mq master kbr0 state UP qlen 1000 link/ether 00:22:19:06:01:e3 brd ff:ff:ff:ff:ff:ff 3: kbr0: mtu 1500 qdisc noqueue state UP link/ether 00:22:19:06:01:e3 brd ff:ff:ff:ff:ff:ff inet 192.168.20.9/22 brd 192.168.20.255 scope global kbr0</code></pre> ブリッジインターフェースkbr0に192.168.20.9というアドレスが割り当てられている。 4. qemuのコンパイル kvmによる仮想マシンではLinuxハイパーバイザー上で、kvmに対応したqemuエミュレーターを動作させる。qemuエミュレータ上ではwindowsやlinuxなど、サポートされているOSをゲストOSとして起動することが可能である。 当初はkvmに対応したqemuのソースをkvmプロジェクトのサイトから取得する必要があったが、最近ではqemuの本家のソースにkvmのパッチが既にマージされている。 従って、kvmの開発の最先端のソースを利用したいと言うのでなければ、qemuの本家サイトからソースを取ってくれば良い。 wget http://wiki.qemu.org/download/qemu-1.0.1.tar.gz</code></pre> 普通にtarボールを展開して、コンパイル＆インストールする。 tar xf qemu-1.0.1.tar.gz ; cd qemu-1.0.1 ./configure --prefix=/kvm/qemu/qemu-1.0.1/ --enable-kvm make install tree -L 2 /kvm/qemu/ /kvm/qemu/ `-- qemu-1.0.1 |-- bin |-- etc `-- share root@kvm:~# /kvm/qemu/qemu-1.0.1/bin/qemu-x86_64 -version qemu-x86_64 version 1.0,1, Copyright (c) 2003-2008 Fabrice Bellard</code></pre> 5. ゲストOSイメージの作成 qemuエミュレーター上で動かすゲストLinuxOSイメージを作成する。手順は以下の通り。 スパースなイメージファイルを作成 </li> ext4でファイルシステム作成 </li> debootstrapでOSインストール </li> ネットワークやルートパスワードの設定等々細々としたを行う </li> </ul> イメージ作成 dd if=/dev/zero of=./kvm.img bs=1024 seek=9999999 count=1</code></pre> ファイルシステム作成 mkfs.ext4 kvm.img</code></pre> debootstrapでDebianインストール mount -o loop kvm.img /mnt/tmp/ debootstrap --include=openssh-server,openssh-client,\ rsync,pciutils,acpid squeeze /mnt/tmp/</code></pre> その他の細々した設定 シリアルコンソール設定 /mnt/tmp/etc/inittab にttyS0の設定を加える T0:23:respawn:/sbin/getty -L ttyS0 19200 vt100</code></pre> BIOSクロックをUTCと見做さない設定(JSTのsystem dateが終了時にBIOSに書き込まれる。仮想マシンでは関係ないかも？) /mnt/tmp/etc/default/rcS UTC=no</code></pre> ネットワーク設定(DHCPでアドレスを取得するようにする。) /mnt/tmp/etc/network/interfaces auto lo eth0</code></pre> iface lo inet loopback iface eth0 inet dhcp</code></pre> 余計なudevルールの削除 rm /mnt/tmp/etc/udev/rules.d/70-persistent-net.rules</code></pre> パスワード初期設定、apt-cache掃除、timezoneをJSTに。 chroot /mnt/tmp/ passwd apt-get clean dpkg-reconfigure tzdata</code></pre> 6. ゲストカーネルのコンパイル kvm上で仮想マシンを動かす場合、ゲストOSは改変不要でハードウェア上で動かす場合のカーネルがそのまま動く。これはしばしば完全仮想化と呼ばれる。しかしながら、仮想マシン用のドライバを使うようにしてやることで、ゲストOSの性能を大幅に向上することが可能である。仮想マシン用のドライバを利用した方法は、しばしば準仮想化と呼ばれる。 今回も準仮想化を使いたいし、なるべく必要最小限のドライバのみを有効にした、シンプルなカーネルを使いたいので、バニラソースからカーネルをコンパイルする。 必要なコンパイルフラグは、ホストカーネルの場合と同様にこのページ</a>を参考にして有効にした。結局以下の関連フラグが有効にしてある。 CONFIG_HOTPLUG=y CONFIG_TICK_ONESHOT=y CONFIG_PARAVIRT_GUEST=y CONFIG_PARAVIRT_TIME_ACCOUNTING=y CONFIG_KVM_CLOCK=y CONFIG_KVM_GUEST=y CONFIG_PARAVIRT=y CONFIG_PARAVIRT_SPINLOCKS=y CONFIG_PARAVIRT_CLOCK=y CONFIG_PARAVIRT_DEBUG=y CONFIG_MEMORY_HOTPLUG=y CONFIG_MEMORY_HOTPLUG_SPARSE=y CONFIG_MEMORY_HOTREMOVE=y CONFIG_VIRT_TO_BUS=y CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_PCI_MSI=y CONFIG_VIRTIO_BLK=y CONFIG_VIRTIO_NET=y CONFIG_VIRTIO_CONSOLE=y CONFIG_HW_RANDOM_VIRTIO=y CONFIG_VIRTIO=y CONFIG_VIRTIO_RING=y CONFIG_VIRTIO_PCI=y CONFIG_VIRTIO_BALLOON=y CONFIG_VIRTIO_MMIO=y CONFIG_VIRT_DRIVERS=y CONFIG_HAVE_KVM=y</code></pre> 今回、モジュールを使わずにモノリシックなカーネルにした。コンパイルしたカーネルは、適当決めたディレクトリ/kvm/bootに置いた。 root@kvm:~# ls -la /kvm/boot/ total 8728 drwxr-xr-x 2 root root 4096 Mar 8 03:38 . drwxr-xr-x 10 root root 4096 Mar 6 17:12 .. -rw-r--r-- 1 root root 1105677 Mar 8 03:38 System.map-3.2.9-64kvmg01 -rw-r--r-- 1 root root 44798 Mar 8 03:38 config-3.2.9-64kvmg01 -rw-r--r-- 1 root root 3152304 Mar 8 03:38 vmlinuz-3.2.9-64kvmg01</code></pre> ** ** 7. ゲストOSの起動コマンド ゲストOSはqemuエミュレーター上で動作する。ゲストOSを起動するには、qemuコマンドを適切なオプションで実行すれば良い。kvmによる仮想マシンは、ホストOS(Linuxハイパーバイザー)上からは単なるqemuプロセスに見える。従って、それぞれのゲストOSがどのくらいのCPU、メモリ等のリソースを消費しているかは、ホストOS上でqemuプロセスがどのくらいそれらのリソースを消費しているかを見れば良い。不要になったゲストOSはいざとなったら、qemuプロセスをkillコマンドでkillすることで、終了させることも可能である。(実際にはもう少し丁寧にshutdownすべきであるが。) さて、qemuのコマンドのオプションはqemu-system-x86_64 --helpで確認することが可能である。それぞれオプションを試行錯誤し、最終的に我々にとって使い易くしたものが、以下のものである。 /kvm/qemu/qemu-kvm-1.0/bin/qemu-system-x86_64 \ --enable-kvm -nographic -daemonize \ -drive file=/kvm/data/kvm.img,if=virtio -m 512 \ -kernel /kvm/boot/vmlinuz-3.2.9-64kvmg01 \ -append "console=ttyS0,19200n8 root=/dev/vda" \ -net nic,vlan=0,macaddr=52:54:00:21:00:01,model=virtio \ -net tap,vlan=0,script=/kvm/etc/qemu-ifup,ifname=hoge \ -serial unix:/tmp/con.sock,server,nowait \ -monitor unix:/tmp/mon.sock,server,nowait</code></pre> 以下、それぞれのオプションについて説明する。 --enable-kvm　Intel-VT またはAMD-Vのハードウェア仮想化支援機能を利用する -nographic グラフィカルな出力を無効にし、シリアルをコンソールにリダイレクトする -daemonize　qemuをデーモンとして起動する -m 512　メモリを512MByte 割り当てる -smp 1 　仮想マシンにプロセッサを一つ割り当てる -kernel ゲストカーネルを指定。イメージの外、ホストOS上に置くことができる -append カーネルに与えるオプションを指定 -drive file=　イメージファイルの指定。if=virtioオプションによりパラヴァーチャルなブロックデバイスとして見せる -net nic,vlan=0,macaddr= ,model=virtio NICを作成しvlan=0に接続する。model=virtioオプションによりパラバーチャルなNICに見せる。 -net tap,vlan=0,script=/kvm/etc/qemu-ifup,ifname=hoge ホストにtapデバイスhogeを作成しvlan=0に接続する。そしてスクリプト/kvm/etc/qemu-ifupを実行する。 -serial unix:/tmp/con.sock,server,nowait シリアルポートをUNIXドメインソケット/tmp/con.sockにリダイレクトする。 -monitor unix:/tmp/mon.sock,server,nowait QemuのモニターをUNIXドメインソケット/tmp/mon.sockにリダイレクトする。 serial,monitorのUNIXドメインソケットへのリダイレクトがミソ。 nographic, daemonizeオプションによりバックグラウンドで実行している仮想マシンを/tmp/mon.sock、/tmp/con.sockから制御することが可能である。serial、monitorをtcpやtelnetなどなどのネットワーク接続口にリダイレクトすることも可能であるが、その場合、認証無しでmonitorコンソールアクセスしqemuをコントロールすることができてしまう。UNIXドメインソケットを利用する場合、rootユーザのみにUNIXドメインソケットへの読み書き許可を与えることで、ホストOS上ののrootユーザのみにアクセス許可を与えることができるようになる。 8. script=/kvm/etc/qemu-ifupで何をしているのか ** ** /kvm/etc/qemu-ifupの内容 #!/bin/sh /sbin/ip link set dev $1 up promisc off /usr/sbin/brctl addif kbr0 $1</code></pre> タップデバイスhogeがブリッジkbr0に接続されている。 brctl show bridge name bridge id STP enabled interfaces kbr0 8000.0022190601e3 no eth0 hoge</code></pre> 9. UNIXドメインソケットへの接続方法 socatコマンドで接続可能である。 QEMUモニタへの接続 socat -,icanon=0,echo=0 unix-connect:/tmp/mon.sock QEMU 1.0,1 monitor - type 'help' for more information (qemu)</code></pre> シリアルコンソールへの接続 socat -,icanon=0,echo=0 unix-connect:/tmp/con.sock Debian GNU/Linux 6.0 (none) ttyS0 (none) login:</code></pre> ただし、このままではctl-cでシリアルコンソール内のプロセスを終了しようとしても、socat自身がグナルを受け取ってしまうので、そのプロセスを終了することができない。その様な場合には、intrなを適当なキーに割り当てると良い。 例えば、次の様なラッパスクリプトを利用することで、socatにinterruptシグナルを送る場合のキーバインディングをctl+]に変更することができる。ctl+cを叩いた場合、socat自身gはシグナルとして受け取らず、接続先のプロセスがctl+cをinterruptシグナルとして受け取ることになる。 test_con.sh #!/bin/bash tty_setting=`stty -g` stty intr ^] socat -,icanon=0,echo=0 unix-connect:/tmp/con.sock stty $tty_setting</code></pre> **A1. 素のqemuとkvmどのくらい速さが違うの？　** sysbenchと言うベンチマークツールを使って、簡単にCPUベンチマークを実行してみた。 ベンチマークコマンド sysbench --num-threads=24 --test=cpu --cpu-max-prime=10000 run</code></pre> 素のqemu　(qemu-system-x86_64 .... ) Test execution summary: total time: 58.5005s</code></pre> kvmオプション付き　(qemu-system-x86_64 --enable-kvm .... ) Test execution summary: total time: 17.3854s</code></pre> 約3.4倍高速であった。 A2. qemu-kvmと本家qemuどちらを使うべき？(2012/3現在) 以前は、kvmを使うためには、それ用にパッチの当たったqemuを使う必要があったが、現在kvmサポートパッチは本家qemuにマージされている。しかしながら、wiki.qemu.org/downloadの他にも、sourceforgeにqemu-kvmが存在している。 そこで、sysbenchでベンチマークしてみた。 ベンチマークコマンド sysbench --num-threads=24 --test=cpu --cpu-max-prime=10000 run</code></pre> qemu-1.0.1の場合(--enable-kvmオプション付き) Test execution summary: total time: 17.3854s</code></pre> qemu-kvm-1.0の場合 Test execution summary: total time: 17.2720s</code></pre> 大きな差は見られない。 以上、kvmによる仮想マシンの構築について、備忘録的にまとめた。 部分的であれ記載した情報がお役に立てば幸いである。 1U 4ノードサーバ　SR1640TH 2012-01-12T00:00:00+00:00 Intelのクアッドノード、サーバベアボーン Xeon X3400系ですので、ちょっと古いですが… 1Uのシャーシに電源も独立したサーバユニットが二つ。 それぞれのサーバユニットにはソケットが二つ。デュアルＣＰＵサーバ一台ではなく、独立したシングルＣＰＵのサーバ二台が、一枚のマザーに載っているという構成。 サーバユニットは全面から引き出し可能。メンテナンスは2ノード毎に行うことになる。 ServerEnginesのBMC サーバユニットを、シャーシの上に乗せてみました。 1U Sandy Bridge Xeon ファイルサーバ 2012-01-12T00:00:00+00:00 先日、お客様に納品した1Ｕサーバのご紹介です。 1ＵシャーシにSandy Bridge Xeon　E3-1270を一個搭載しています。 フロントには2.5インチのＨＤＤベイが8個あり、SATA、SAS HDD、SSDなどを8本搭載可能です。 マザーボードはSupermicro X8SIU-F。このマザーボードは横方向に短いため、1Uシャーシ内への拡張カードの装着が容易になります。今回は、キャパシタ付のRAIDカードASR-5805Zを装着しましたが、いつもは置き場所に困るキャパシタが、余裕で取り付けられました。PCIスロットを二つ占有する、Teslaなどにも向いているのではないかと思います。 6本あるメモリスロットは、4Ｇbyte DDR3 ECC Reg.モジュールで、フル実装。合計24GByteのメモリを搭載しています。 ASR-5805Zは1.2GHzのデュアルコアRAIDチップを搭載しているため、比較的発熱が大きいです。十分にカードを冷却するために、FANを二つ増設しています。 今回は冗長化電源付のシャーシをご希望されました。 今日は自転車通勤 2011-04-25T00:00:00+00:00 暖かくなってきたので、自転車が気持ち良い(^^) Galaxy からBlogger アプリ 2011-04-25T00:00:00+00:00 Galaxy からBlogger アプリを使って投稿。編集機能は不十分だが、気軽に投稿できるのは便利。写真も簡単に貼り付けることができる。 ちなみに、愛用のメガネです。 HHKB Pro2 2011-04-25T00:00:00+00:00 愛用のキーボードは、Happy Hacking Keyboard Professional 2です。キータッチが秀逸です。 rsync --updateオプションで悩む 2011-04-13T00:00:00+00:00 rsyncの--updateオプションは、転送先ファイルのmtimeが転送元よりも新しい場合に、そのファイルのコピーをスキップするオプションである。 しかしながら、シンボリックリンクやスペシャルファイルの場合は、このオプションがあっても、コピーはスキップされない。 -u, --update </blockquote> This forces rsync to skip any files which exist on the destination and have a modified time that is newer than the source file. (If an existing destination file has a modification time equal to the source file’s, it will be updated if the sizes are different.) </blockquote> Note that this does not affect the copying of symlinks or other special files. Also, a difference of file format between the sender and receiver is always considered to be important enough for an update, no matter what date is on the objects. In other words, if the source has a directory where the destination has a file, the transfer would occur regardless of the timestamps. </blockquote> コピー先のシンボリックの方が新しい場合には、コピーをスキップしたいのだが、どうすれば良いのでしょう？ aufs2.1を試してみる。 2011-04-09T00:00:00+00:00 Aufs(AnotherUnionfs)は、複数のディレクトリを単一のディレクトリに見せるスタッカブルなファイルシステムです。Aufsを用いると、リードオンリーなディレクトリの上に、読み書き専用のディレクトリを重ねてマウントすることができます。 今回、これについて試してみました。 インストール手順 http://aufs.sourceforge.net/</a>にあるドキュメントを参考にインストールします。 レポジトリの同期とチェックアウト 今回はバニラカーネルにパッチを当てて、カーネルモジュールとしてコンパイルするので、aufs2-standalone.gitのみ同期します。 root@hana:~/tmp# git clone http://git.c3sl.ufpr.br/pub/scm/aufs/aufs2-standalone.git aufs2-standalone.git Cloning into aufs2-standalone.git... </blockquote> 使用するバニラカーネルのバージョンは2.6.38.2なので、aufs2.1-38 をチェックアウトします。 root@hana:~/tmp# cd aufs2-standalone.git/ </blockquote> root@hana:~/tmp/aufs2-standalone.git# git checkout origin/aufs2.1-38 Note: checking out 'origin/aufs2.1-38'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name HEAD is now at 4c5ce8c... aufs2.1 standalone version for linux-2.6.38 </blockquote> root@hana:~/tmp/aufs2-standalone.git# ls -la total 356 drwxr-xr-x 7 root root 4096 Apr 8 14:08 . drwxr-xr-x 3 root root 4096 Apr 8 14:06 .. drwxr-xr-x 8 root root 4096 Apr 8 14:08 .git -rw-r--r-- 1 root root 17990 Apr 8 14:07 COPYING -rw-r--r-- 1 root root 268285 Apr 8 14:08 ChangeLog drwxr-xr-x 3 root root 4096 Apr 8 14:08 Documentation -rw-r--r-- 1 root root 1365 Apr 8 14:07 Makefile -rw-r--r-- 1 root root 14421 Apr 8 14:08 README -rw-r--r-- 1 root root 2971 Apr 8 14:08 aufs2-base.patch -rw-r--r-- 1 root root 978 Apr 8 14:08 aufs2-kbuild.patch -rw-r--r-- 1 root root 8732 Apr 8 14:08 aufs2-standalone.patch -rw-r--r-- 1 root root 2793 Apr 8 14:08 config.mk drwxr-xr-x 2 root root 4096 Apr 8 14:08 design drwxr-xr-x 3 root root 4096 Apr 8 14:08 fs drwxr-xr-x 3 root root 4096 Apr 8 14:07 include </blockquote> linux-2.6.38用のパッチが作成されました。 カーネルソースディレクトリに移動し、パッチを当てます。 root@hana:~/Kernel/linux-2.6.38.2# patch -p1 patching file fs/splice.c patching file include/linux/namei.h patching file include/linux/splice.h root@hana:~/Kernel/linux-2.6.38.2# patch -p1 patching file fs/Kconfig patching file fs/Makefile patching file include/linux/Kbuild root@hana:~/Kernel/linux-2.6.38.2# patch -p1 patching file fs/file_table.c patching file fs/inode.c patching file fs/namei.c patching file fs/namespace.c patching file fs/notify/group.c patching file fs/notify/mark.c patching file fs/open.c patching file fs/splice.c patching file security/commoncap.c patching file security/device_cgroup.c patching file security/security.c </blockquote> 必要なファイルもコピーします。 root@hana:~/Kernel/linux-2.6.38.2# cp -R ~/tmp/aufs2-standalone.git/Documentation ./ root@hana:~/Kernel/linux-2.6.38.2# cp -R ~/tmp/aufs2-standalone.git/fs ./ root@hana:~/Kernel/linux-2.6.38.2# cp -R ~/tmp/aufs2-standalone.git/include/linux/aufs_type.h ./include/linux/ </blockquote> make menuconfig で必要な設定をします。aufsに関する設定パラメータは以下の通りです。 root@hana:~/Kernel/linux-2.6.38.2# egrep AUFS .config CONFIG_AUFS_FS=m CONFIG_AUFS_BRANCH_MAX_127=y CONFIG_AUFS_BRANCH_MAX_511 is not set</h1> CONFIG_AUFS_BRANCH_MAX_1023 is not set</h1> CONFIG_AUFS_BRANCH_MAX_32767 is not set</h1> CONFIG_AUFS_SBILIST=y CONFIG_AUFS_HNOTIFY=y CONFIG_AUFS_HFSNOTIFY=y CONFIG_AUFS_RDU=y CONFIG_AUFS_SP_IATTR=y CONFIG_AUFS_SHWH=y CONFIG_AUFS_BR_RAMFS=y CONFIG_AUFS_BR_FUSE=y CONFIG_AUFS_POLL=y CONFIG_AUFS_BDEV_LOOP=y CONFIG_AUFS_DEBUG=y CONFIG_AUFS_MAGIC_SYSRQ=y </blockquote> カーネルをコンパイル、インストールして再起動します。 root@hana:~# modprobe aufs </blockquote> root@hana:~# lsmod |grep auf aufs 464609 0 </blockquote> root@hana:~# modinfo aufs filename: /lib/modules/2.6.38.2-64aufs01/kernel/fs/aufs/aufs.ko version: 2.1-standalone.tree-38-20110404 description: aufs -- Advanced multi layered unification filesystem author: Junjiro R. Okajima license: GPL srcversion: D52E89D4B96A545C9E3E064 depends: vermagic: 2.6.38.2-64aufs01 SMP mod_unload modversions parm: sysrq:MagicSysRq key for aufs (charp) parm: debug:debug print (int) parm: brs:use /fs/aufs/si_*/brN (int) </blockquote> インストールは以上です。Debian squeezeだとmountコマンドは最初からaufsをサポートしているようです（？要確認） 試してみます。 テストディレクトリを作成する。 mkdir /tmp/{base,cover,mnt} </blockquote> /tmp/base ベースディレクトリ、リードオンリーマウントする /tmp/cover 上から重ねるディレクトリ。書き込み可能 /tmp/mnt マウントポイント </blockquote> ベースディレクトリにテストディレクトリdir1、テストファイルfile1、file11を作成する。 mkdir /tmp/base/dir1 echo 1 > /tmp/base/file1 echo 11 > /tmp/base/dir1/file11 </blockquote> aufsでマウントする。 mount -t aufs -o br=/tmp/cover=rw:/tmp/base=ro none /tmp/mnt/ mount|grep aufs none on /tmp/mnt type aufs (rw,br=/tmp/cover=rw:/tmp/base=ro) </blockquote> ディレクトリ構造は、それぞれ次のようになる。 tree -a /tmp/{base,cover,mnt} /tmp/base |-- dir1 | `-- file11 `-- file1 /tmp/cover |-- .wh..wh.aufs |-- .wh..wh.orph `-- .wh..wh.plnk /tmp/mnt |-- dir1 | `-- file11 `-- file1 4 directories, 5 files </blockquote> マウントしたディレクトリに新たにファイルを作成する。 echo 2 > /tmp/mnt/file2 </blockquote> リードオンリーの/tmp/baseは変わらずに、書き込み可能な/tmp/coverにfile2が作成される。 tree -a /tmp/{base,cover,mnt} /tmp/base |-- dir1 | `-- file11 `-- file1 /tmp/cover |-- .wh..wh.aufs |-- .wh..wh.orph |-- .wh..wh.plnk `-- file2 /tmp/mnt |-- dir1 | `-- file11 |-- file1 `-- file2 4 directories, 7 files </blockquote> ファイルの削除 /tmp/mnt/file1を削除すると、/tmp/cover/.wh.file1が作成され、/tmp/mnt/file1が見えなくなる。 /tmp/mnt/file2を削除すると、単純に/tmp/coverからfile2が消える。 rm /tmp/mnt/file{1,2} tree -a /tmp/{base,cover,mnt} /tmp/base |-- dir1 | `-- file11 `-- file1 /tmp/cover |-- .wh..wh.aufs |-- .wh..wh.orph |-- .wh..wh.plnk `-- .wh.file1 /tmp/mnt `-- dir1 `-- file11 </blockquote> 4 directories, 5 files </blockquote> 元とは違う内容で/tmp/mnt/file1を作成すると、/tm/cover/にもfile1が作成される。 echo x > /tmp/mnt/file1 tree -a /tmp/{base,cover,mnt} /tmp/base |-- dir1 | `-- file11 `-- file1 /tmp/cover |-- .wh..wh.aufs |-- .wh..wh.orph |-- .wh..wh.plnk `-- file1 /tmp/mnt |-- dir1 | `-- file11 `-- file1 4 directories, 6 files </blockquote> それぞれのファイルの内容を確認すると、/tmp/base/file1のみが元の内容のままで、/tmp/cover/file1、/tmp/mnt/file1は新しい内容になっていることがわかる。 head /tmp/{base,cover,mnt}/file1 ==> /tmp/base/file1 /tmp/cover/file1 /tmp/mnt/file1 x </blockquote> ディレクトリの削除 /tmp/mnt/dir1を削除すると/tmp/mntからはdir1が消え、/tmp/coverに.wh.dir1が作成される。 rm -r /tmp/mnt/dir1 tree -a /tmp/{base,cover,mnt} /tmp/base |-- dir1 | `-- file11 `-- file1 /tmp/cover |-- .wh..wh.aufs |-- .wh..wh.orph |-- .wh..wh.plnk `-- .wh.dir1 /tmp/mnt `-- file1 3 directories, 5 files </blockquote> もう一度/tmp/mnt/dir1を作成してみると、/tmp/coverにあった.wh.dir1が無くなり、新たに/tmp/cover/dir1、/tmp/cover/dir1/.wh..wh..opqが作成される。 mkdir /tmp/mnt/dir1 tree -a /tmp/{base,cover,mnt} /tmp/base |-- dir1 | `-- file11 `-- file1 /tmp/cover |-- .wh..wh.aufs |-- .wh..wh.orph |-- .wh..wh.plnk `-- dir1 `-- .wh..wh..opq /tmp/mnt |-- dir1 `-- file1 5 directories, 5 files </blockquote> /tmp/cover/dir1/.wh..wh..opq　の中身は空である。 file /tmp/cover/dir1/.wh..wh..opq /tmp/cover/dir1/.wh..wh..opq: empty </blockquote> /tmp/mnt/dir1/file11を作成してみると、/tmp/cover/dir1/file11が作成される。 echo xx > /tmp/mnt/dir1/file11 tree -a /tmp/{base,cover,mnt} /tmp/base |-- dir1 | `-- file11 `-- file1 /tmp/cover |-- .wh..wh.aufs |-- .wh..wh.orph |-- .wh..wh.plnk `-- dir1 |-- .wh..wh..opq `-- file11 /tmp/mnt |-- dir1 | `-- file11 `-- file1 5 directories, 7 files </blockquote> それぞれのディレクトリにあるfile11の内容は以下の通りで、/tmp/base/dir1/file11が元の内容、/tmp/cover/dir1/file11、/tmp/mnt/dir1/file11が新しい内容である。 head /tmp/{base,cover,mnt}/dir1/file11 ==> /tmp/base/dir1/file11 /tmp/cover/dir1/file11 /tmp/mnt/dir1/file11 xx </blockquote> まとめ スタッカブルなファイルシステムaufsについて試してみた。リードオンリーなディレクトリの上に、読み書き専用のディレクトリを重ねてマウントできることが確認できた。 また、簡単な例のみであるが、ファイルの作成、削除、ディレクトリの作成、削除を行った際に、どのような動作をするのか何となくわかった。 BloggerのDynamic viewがおしゃれ 2011-04-07T00:00:00+00:00 このブログのはhttp://ktaka.blog.clustcom.com/</a>ですが、 末尾に/viewを追加すると、おしゃれなページに早変わり。 現在、用意されているviewは以下の５つ。 http://ktaka.blog.clustcom.com/view/flipcard</a> </li> http://ktaka.blog.clustcom.com/view/mosaic</a> </li> http://ktaka.blog.clustcom.com/view/sidebar</a> </li> http://ktaka.blog.clustcom.com/view/snapshot</a> </li> http://ktaka.blog.clustcom.com/view/timeslied</a> </li> </ul> 詳しくはここ</a>とここ</a>にアナウンスがあります。 今後、ユーザーがview自体をカスタマイズできるようにもなるようです。 GNU tarでシンボリックリンクのタイムスタンプが保存されない - 1.24以降ならOK 2011-04-07T00:00:00+00:00 GNU tar 1.24以降であれば、タイムスタンプが保存されるようである。 http://git.savannah.gnu.org/cgit/tar.git/plain/NEWS?id=release_1_24</a> ** Symbolic link attributes When extracting symbolic links, tar now restores attributes such as last-modified time and link permissions, if the operating system supports this. For example, recent versions of the Linux kernel support setting times on symlinks, and some BSD kernels also support symlink permissions. </blockquote> Debian squeeze のtarは1.23である。 ktaka@hana:~$ tar --version tar (GNU tar) 1.23 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later . This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by John Gilmore and Jay Fenlason. </blockquote> タイムスタンプがApr 1 00:00のシンボリックリンクを作成。 ktaka@hana:~$ mkdir p </blockquote> ktaka@hana:~$ for i in a b c d e f g ; do ln -s /tmp/$i p/$i; touch -ht 04010000 p/$i ; done ktaka@hana:~$ ls -la p total 8 drwxr-xr-x 2 ktaka ktaka 4096 Apr 8 03:03 . drwx------ 79 ktaka ktaka 4096 Apr 8 03:03 .. lrwxrwxrwx 1 ktaka ktaka 6 Apr 1 00:00 a -> /tmp/a lrwxrwxrwx 1 ktaka ktaka 6 Apr 1 00:00 b -> /tmp/b lrwxrwxrwx 1 ktaka ktaka 6 Apr 1 00:00 c -> /tmp/c lrwxrwxrwx 1 ktaka ktaka 6 Apr 1 00:00 d -> /tmp/d lrwxrwxrwx 1 ktaka ktaka 6 Apr 1 00:00 e -> /tmp/e lrwxrwxrwx 1 ktaka ktaka 6 Apr 1 00:00 f -> /tmp/f lrwxrwxrwx 1 ktaka ktaka 6 Apr 1 00:00 g -> /tmp/g </blockquote> tarアーカイブを作成 ktaka@hana:~$ (cd p; tar cf - .)|gzip > p.tgz </blockquote> 中身を確認すると、確かに正しいタイムスタンプでアーカイブが作成されている。 ktaka@hana:~$ tar ztvf p.tgz drwxr-xr-x ktaka/ktaka 0 2011-04-08 03:03 ./ lrwxrwxrwx ktaka/ktaka 0 2011-04-01 00:00 ./f -> /tmp/f lrwxrwxrwx ktaka/ktaka 0 2011-04-01 00:00 ./c -> /tmp/c lrwxrwxrwx ktaka/ktaka 0 2011-04-01 00:00 ./g -> /tmp/g lrwxrwxrwx ktaka/ktaka 0 2011-04-01 00:00 ./a -> /tmp/a lrwxrwxrwx ktaka/ktaka 0 2011-04-01 00:00 ./e -> /tmp/e lrwxrwxrwx ktaka/ktaka 0 2011-04-01 00:00 ./d -> /tmp/d lrwxrwxrwx ktaka/ktaka 0 2011-04-01 00:00 ./b -> /tmp/b </blockquote> アーカイブをqディレクトリに展開 ktaka@hana:~$ mkdir q; (cd q; tar zxf ../p.tgz) ; date Fri Apr 8 03:16:26 JST 2011 </blockquote> タイムスタンプがアーカイブを展開した時刻になってしまう。 ktaka@hana:~$ ls -la q/ total 8 drwxr-xr-x 2 ktaka ktaka 4096 Apr 8 03:03 . drwx------ 79 ktaka ktaka 4096 Apr 8 03:16 .. lrwxrwxrwx 1 ktaka ktaka 6 Apr 8 03:16 a -> /tmp/a lrwxrwxrwx 1 ktaka ktaka 6 Apr 8 03:16 b -> /tmp/b lrwxrwxrwx 1 ktaka ktaka 6 Apr 8 03:16 c -> /tmp/c lrwxrwxrwx 1 ktaka ktaka 6 Apr 8 03:16 d -> /tmp/d lrwxrwxrwx 1 ktaka ktaka 6 Apr 8 03:16 e -> /tmp/e lrwxrwxrwx 1 ktaka ktaka 6 Apr 8 03:16 f -> /tmp/f lrwxrwxrwx 1 ktaka ktaka 6 Apr 8 03:16 g -> /tmp/g </blockquote> GNU tar 1.24で試してみる。 ktaka@hana:~$ ./tar-1.24/_inst/bin/tar --version tar (GNU tar) 1.24 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later . This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by John Gilmore and Jay Fenlason. </blockquote> ディレクトリrに展開してみる。 ktaka@hana:~$ mkdir r; (cd r; ../tar-1.24/_inst/bin/tar zxf ../p.tgz) ; date Fri Apr 8 03:35:37 JST 2011 </blockquote> ktaka@hana:~$ ls -la r total 8 drwxr-xr-x 2 ktaka ktaka 4096 Apr 8 03:03 . drwx------ 81 ktaka ktaka 4096 Apr 8 03:35 .. lrwxrwxrwx 1 ktaka ktaka 6 Apr 1 00:00 a -> /tmp/a lrwxrwxrwx 1 ktaka ktaka 6 Apr 1 00:00 b -> /tmp/b lrwxrwxrwx 1 ktaka ktaka 6 Apr 1 00:00 c -> /tmp/c lrwxrwxrwx 1 ktaka ktaka 6 Apr 1 00:00 d -> /tmp/d lrwxrwxrwx 1 ktaka ktaka 6 Apr 1 00:00 e -> /tmp/e lrwxrwxrwx 1 ktaka ktaka 6 Apr 1 00:00 f -> /tmp/f lrwxrwxrwx 1 ktaka ktaka 6 Apr 1 00:00 g -> /tmp/g </blockquote> 正しいタイムスタンプでシンボリックリンクを展開することができた。 参考リンク http://www.mail-archive.com/bug-tar@gnu.org/msg02281.html</a></li> </ul> ファイル編集前の簡易バックアップ 2010-09-15T00:00:00+00:00 Linuxの設定ファイルなどを編集する際に、編集前のファイルのバックアップを取って置きたいことがある。設定をしくじったりした場合に、元の設定に戻したいからだ。 私は、そのために、次のようなシェルコマンドを自作して利用している。 以下の内容で、~/.functionsを作成する。 bk () { file=${1##*/}; dir=${1%${1##*/}}; ( if [ "$dir" = "" ]; then true; else if [ -d "$dir" ]; then echo cd $dir; cd $dir; else echo "No such directory: $dir "; return 1; fi; fi; if [ -f "$file" ]; then mkdir -p .bk; echo cp -p $file .bk/$file.$(date +"%Y%m%d%H%M" -r $file); cp -p $file .bk/$file.$(date +"%Y%m%d%H%M" -r $file); else echo "No such file: $file "; fi ) } </blockquote> この関数は、以下のような動作をするものである。 バックアップを取りたいファイルが存在するディレクトリに.bk/とサブディレクトリを作成する。 </li> ファイルの最終変更日時(mtime)をサフィックスにもつコピーを作成する。 </li> </ul> 使用例 ktaka@hana:~$ . ~/.functions ktaka@hana:~$ ls -la /home/ktaka/hello -rw-r--r-- 1 ktaka ktaka 1048576000 May 27 2009 /home/ktaka/hello ktaka@hana:~$ bk /home/ktaka/hello cd /home/ktaka/ cp -p hello .bk/hello.200905270208 ktaka@hana:~$ ls -la /home/ktaka/.bk/hello.200905270208 -rw-r--r-- 1 ktaka ktaka 1048576000 May 27 2009 /home/ktaka/.bk/hello.200905270208 </blockquote> ファイルの更新時をサフィックスに持つので、複数のバックアップファイルが存在する場合でも便利である。 ~/.bashrcで.functionsを読み込むようにしておくと良い。 if [ -f ~/.functions ]; then . ~/.functions fi </blockquote> i3200でedacを使うには、カーネルを2.6.32にしなければならない。 2010-01-16T00:00:00+00:00 メモリが壊れているかな？ BIOSより、DMIログを覗いてみると。。。 Phoenix cME FirstBIOS Pro Setup Utility Advanced +---------+----------------------------------------------------------+---------+ </th> DMI Event Log</th> Help</th></tr></thead> </td> </td> </td></tr> Event</td> 01/16/2010 14:44:12 Pre-Boot Error: ^</td> ts of</td></tr> Event</td> Keyboard Not Functional .</td> og.</td></tr> </td> .</td> </td></tr> View D</td> 01/16/2010 14:44:46 Single-Bit ECC Errors in DIMM# .</td> </td></tr> Event</td> 01/16/2010 14:45:45 Single-Bit ECC Errors in DIMM# .</td> </td></tr> </td> 01/16/2010 14:45:45 Pre-Boot Error: :</td> </td></tr> Mark D</td> Keyboard Not Functional :</td> </td></tr> Clear</td> :</td> </td></tr> </td> 01/16/2010 14:46:28 Single-Bit ECC Errors in DIMM# :</td> </td></tr> </td> 01/16/2010 14:47:00 Single-Bit ECC Errors in DIMM# :</td> </td></tr> </td> 01/16/2010 14:47:00 Pre-Boot Error: :</td> </td></tr> </td> Keyboard Not Functional .</td> </td></tr> </td> </td> </td></tr> </td> [Continue]</td> </td></tr> +----------------------------------------------------------+</td> </td> </td></tr> </td> </td> </td></tr> +------------------------------------------------------------------------------</td> </td> </td></tr> </tbody></table> </blockquote> せっかくなので、linuxのedacで検出してみる。 i3200でedacを使うには、カーネルを2.6.32にしなければならない。ずっと前からコードはあったので、とっくにマージされていたと思っていました。 モジュールはこれ lenny64:~# lsmod |grep edac i3200_edac 3599 0 </blockquote> エラー出力 lenny64:~# dmesg |tail EDAC DEBUG: i3200_check: MC0: i3200_check() EDAC MC0: CE page 0x0, offset 0x0, grain 1073741824, syndrome 0x54, row 1, channel 0, label "": i3200 CE EDAC DEBUG: i3200_check: MC0: i3200_check() EDAC MC0: CE page 0x0, offset 0x0, grain 1073741824, syndrome 0x54, row 1, channel 0, label "": i3200 CE EDAC DEBUG: i3200_check: MC0: i3200_check() EDAC MC0: CE page 0x0, offset 0x0, grain 1073741824, syndrome 0x54, row 1, channel 0, label "": i3200 CE EDAC DEBUG: i3200_check: MC0: i3200_check() EDAC MC0: CE page 0x0, offset 0x0, grain 1073741824, syndrome 0x54, row 1, channel 0, label "": i3200 CE EDAC DEBUG: i3200_check: MC0: i3200_check() EDAC MC0: CE page 0x0, offset 0x0, grain 1073741824, syndrome 0x54, row 1, channel 0, label "": i3200 CE </blockquote> VAIO X linuxでの輝度調整 2009-11-09T00:00:00+00:00 ここ</a>を参考に。 setpci コマンドで直接設定を行います。 VAIO type P では 00:02.0 F4.B が輝度用のデバイスです。輝度の範囲は 00〜FF(暗い〜明い) です。 </blockquote> VAIO Xでも同じだろうということでやってみると、やはりその通り。輝度調節できました。 最小はB=0だけど、そうすると真っ暗になってしまう。B=10前後がいいところか。 setpci -s 00:02.0 F4.B=10 最大はB=FF。 setpci -s 00:02.0 F4.B=FF B=10の時の消費電力 grep rate /proc/acpi/battery/BAT0/state</h1> present rate: 6104 mW </blockquote> B=FFの時の消費電力 grep rate /proc/acpi/battery/BAT0/state</h1> present rate: 7628 mW </blockquote> Lバッテリの場合"design capacity: 33590 mWh"なので、B=10にすれば、5時間ちょっとは使えそうです。 追記 cpufreqdの設定で、ACプラグON/OFFで輝度が変わるようにしました。 /etc/cpufreqd.conf [Profile] name=Performance High minfreq=100% maxfreq=100% policy=performance exec_post=/usr/bin/setpci -s 00:02.0 F4.B=ff [/Profile] [Profile] name=Powersave Low minfreq=40% maxfreq=40% policy=powersave exec_post=/usr/bin/setpci -s 00:02.0 F4.B=10 [/Profile] [Rule] name=AC Rule ac=on profile=Performance High [/Rule] [Rule] name=AC Off - Low Battery ac=off battery_interval=0-100 profile=Powersave Low [/Rule] </blockquote> vaio x + d31hw 電池の持ちは3.5時間 2009-11-04T00:00:00+00:00 イーモバイルD31HWでロマンスカー車内から接続中。 消費電力は約10W。この調子だと、せいぜい3.5時間がいいところです vaiox:~# cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: discharging present rate: 10101 mW remaining capacity: 32240 mWh present voltage: 7992 mV </blockquote> vaio xは店頭販売モデルなのでLバッテリが標準ですが、Xバッテリが欲しくなります。 vaio xの駆動時間は実質4時間位か 2009-11-03T00:00:00+00:00 メーカーのページにL型バッテリ駆動時間は約10時間とあるので期待して購入したvaio xですが、私の環境では、4時間位がいいところのようです。 環境　Debian Linux(カーネル2.6.31.5) 電池の容量は、33590 mWh vaiox:/home/ktaka# cat /proc/acpi/battery/BAT0/info present: yes design capacity: 33590 mWh last full capacity: 33590 mWh battery technology: rechargeable design voltage: 7400 mV design capacity warning: 3350 mWh design capacity low: 120 mWh capacity granularity 1: 0 mWh capacity granularity 2: 1 mWh model number: serial number: battery type: Lion OEM info: Sony Corporation </blockquote> 800MHz動作時の、消費電力は、7669mW cat /proc/acpi/battery/BAT0/state</h1> present: yes capacity state: ok charging state: discharging present rate: 7669 mW remaining capacity: 4710 mWh present voltage: 6928 mV </blockquote> よって33590/7669 = 4.38 時間が駆動時間。 CPUのクロックは、cpufreqdのおかげで、バッテリ駆動時は800MHzになっている。 ACアダプタ使用時 1.87GHz cat /sys/devices/system/cpu/cpu{0,1}/cpufreq/cpuinfo_cur_freq</h1> 1866000 1866000 </blockquote> バッテリ駆動時 800MHz cat /sys/devices/system/cpu/cpu{0,1}/cpufreq/cpuinfo_cur_freq</h1> 800000 800000 </blockquote> cpufreqd.confの内容 [General] pidfile=/var/run/cpufreqd.pid poll_interval=2 verbosity=4 [/General] [Profile] name=Performance High minfreq=100% maxfreq=100% policy=performance #exec_post=echo 8 > /proc/acpi/sony/brightness [/Profile] [Profile] name=Powersave Low minfreq=40% maxfreq=40% policy=powersave [/Profile] [Rule] name=AC Rule ac=on # (on/off) profile=Performance High [/Rule] [Rule] name=AC Off - Low Battery ac=off # (on/off) battery_interval=0-100 #exec_post=echo 3 > /proc/acpi/sony/brightness profile=Powersave Low [/Rule] </blockquote> Poulsbo (GMA 500)のグラフィックドライバ(psb)がバニラカーネルに取り込まれていない。Ｕｂｕｎｔｕでは、カーネル2.6.28用のドライバが存在するようである。 今はLCDの輝度調節が効かないが、psbが使えれば、輝度を落とすことができ、もう少し長く使えるようになるかもしれない。 Debian Linux でイーモバイルD31HW使う 2009-11-01T00:00:00+00:00 下り最大21Mbps、上り最大5.8Mbpsのデータ通信カード(スティック)イーモバイルのD31HWを使ってみる。 事前調査によると、このカードは、ストレージとモデムの両方の機能を持っていて、とあるコマンドを送ることによりモードを切り替えられるとのこと。ストレージは、Windowsなどで最初に接続したときに、自動的にデバイスドライバをインストールするためのものであるとのこと。 http://blog.37to.net/2009/01/ubuntuemobiled21lc/ </a>http://show-cha.seesaa.net/article/125815364.html</a> カードを接続しlsusb で見ると、以下のエントリが現れる。 </blockquote> Bus 001 Device 004: ID 12d1:1446 Huawei Technologies Co., Ltd. </blockquote> ここ</a>から、usb_modeswitchをダウンロードしインストール。 /etc/usb_modeswitch.conf を以下の内容で作成。 Emobile D31HW</h1> DefaultVendor= 0x12d1 DefaultProduct= 0x1446 TargetVendor= 0x12d1 TargetProduct= 0x1429 MessageEndpoint=0x01 MessageContent="55534243000000000000000000000011060000000000000000000000000000" </blockquote> usb_modeswitchを実行すると vaiox:~# usb_modeswitch Looking for target devices ... No devices in target mode or class found Looking for default devices ... Found default devices (1) Accessing device 005 on bus 001 ... Using endpoints 0x01 (out) and 0x81 (in) Inquiring device details; driver will be detached ... Looking for active driver ... OK, driver found ("usb-storage") OK, driver "usb-storage" detached Received inquiry data (detailed identification)</h2> Vendor String: HUAWEI Model String: Mass Storage Revision String: 2.31</h2> Device description data (identification)</h2> Manufacturer: Huawei Technologies Product: HUAWEI Mobile Serial No.: not provided</h2> Setting up communication with interface 0 ... Trying to send the message to endpoint 0x01 ... OK, message successfully sent -> Run lsusb to note any changes. Bye. </blockquote> lsusbで見てみると Bus 001 Device 006: ID 12d1:1429 Huawei Technologies Co., Ltd. </blockquote> デバイスIDが1446から1429に変わっている。 カーネルモジュールをロードすると、/dev/ttyUSB0,1,2が作成される。 ls -la /dev/ttyUSB*</h1> ls: cannot access /dev/ttyUSB*: No such file or directory modprobe usbserial vendor=0x12d1 product=0x1429</h1> ls -la /dev/ttyUSB*</h1> crw-rw---- 1 root dialout 188, 0 Nov 2 01:02 /dev/ttyUSB0 crw-rw---- 1 root dialout 188, 1 Nov 2 01:02 /dev/ttyUSB1 crw-rw---- 1 root dialout 188, 2 Nov 2 01:02 /dev/ttyUSB2 </blockquote> そして、pppの設定ファイルを作成 /etc/ppp/peers/provider user "em@em" connect "/usr/sbin/chat -v -f /etc/chatscripts/pap -T 99**1#" /dev/ttyUSB0 115200 defaultroute persist noauth usepeerdns </blockquote> 接続してみる pon</h1> ps -ef |grep ppp</h1> root 2404 1 0 01:08 ttyUSB0 00:00:00 /usr/sbin/pppd call provider root 2410 2088 0 01:08 pts/5 00:00:00 grep ppp ip add show dev ppp0</h1> 6: ppp0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 3 link/ppp inet 114.48.27.146 peer 10.64.64.64/32 scope global ppp0 </blockquote> 接続できました。 </blockquote> ＶＡＩＯ X用Linuxカーネルコンフィグ 2009-11-01T00:00:00+00:00 VAIO Xの各デバイスを認識させるためにとりあえず必要そうなもの。 PATA ＳＳＤ用のドライバ　(8086:811a System Controller Hub (SCH Poulsbo) IDE Controller) CONFIG_PATA_SCH=y </blockquote> ＮＩＣドライバ(11ab:4380 Ethernet controller: Marvell Technology Group Ltd. Device 4380) CONFIG_SKY2=m CONFIG_SKY2_DEBUG=y </blockquote> 無線LANドライバ(168c:002b AR9285 Wireless Network Adapter (PCI-Express) ) CONFIG_CFG80211=m CONFIG_CFG80211_REG_DEBUG=y CONFIG_CFG80211_DEBUGFS=y CONFIG_LIB80211=m CONFIG_LIB80211_DEBUG=y CONFIG_MAC80211=m CONFIG_MAC80211_DEFAULT_PS=y CONFIG_MAC80211_DEFAULT_PS_VALUE=1 CONFIG_MAC80211_RC_PID=y CONFIG_MAC80211_RC_MINSTREL=y CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y CONFIG_MAC80211_RC_DEFAULT="minstrel" CONFIG_MAC80211_LEDS=y CONFIG_MAC80211_DEBUGFS=y CONFIG_MAC80211_DEBUG_MENU=y CONFIG_WLAN_PRE80211=y CONFIG_WLAN_80211=y CONFIG_ATH_COMMON=m CONFIG_ATH5K=m CONFIG_ATH5K_DEBUG=y CONFIG_ATH9K=m CONFIG_ATH9K_DEBUG=y </blockquote> イーモバイルＤ３１ＨＷのために... CONFIG_USB_ACM=m CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y </blockquote> イーモバイルのデータカードはこれだけではダメで、usb_modeswitchによるモード切替が必要。 VAIO X 購入しました 2009-10-31T00:00:00+00:00 薄くて、軽くて、電池が長持ち、SonyのネットブックVAIO Xを購入しました。 CPU Intel Atom Z540 (1.86GHz)</li> メモリー2GByte</li> SSD 64GByte</li> Lバッテリで約10時間駆動</li> 重量　0.765kg</li> 厚み　13.9mm</li> 無線 IEEE802.11b/g/n</li> ＬＡＮ 1000Base-T</li> </ul> スペックは必要にして十分。CPUが64ビット対応でないのだけが残念。(仕事で必要なので。) 写真は、Let’ｓ note T7と、大きさを比較したもの。Let's noteも1.2kgで電池の持ちも良かったんですが、VAIO Xはそれよりも上を(下を？)行く大きさと、軽さです。 本当にノートを持ち歩く感覚です。 ソニーの宣伝文句は「余分はいらない。十分がほしい。」ということみたいなので、早速、Windows 7を消して、Debianを入れました。 [備忘録] ノートパソコンの起動時間の短縮をしたい 2009-10-26T00:00:00+00:00 Let's note T7に Debianを入れたものを外出先で使っているのですが、Grubでカーネルを選択してから、Xが立ち上がるまでに1分近くかかっていました。その後emobileに接続したりと、メールやWebが見れるまでにはさらに時間がかかっていました。これだと、ちょこっと情報を確認したい時にはちょっと面倒です。そこでiPhoneを導入し、それはそれで快適に使えているわけですが、ノートパソコンの方ももう少し起動時間短縮できるよう頑張ってみたいと思います。 方針は 余分なサービスの停止 </li> X windowが無くても何とかなるように </li> フレームバッファを使えるようにする </li> テキストコンソールでメールの読み書きができるように。候補emacs+wanderlust </li> テキストコンソールでWebの閲覧検索ができるように。候補はemacs+w3m </li> 切換えはscreenで </li> カーネルをスリムに </li> SSD化、IntelのX-25M 80GB辺りを物色中 </li> </ul> 先ず、色々といらないサービスを起動しないようにします。 update-rc -f dhcpd3-server remove update-rc -f tftpd-hpa remove update-rc -f hogehoge remove /etc/init.d/rcで CONCURRENCY=none → CONCURRENCY=shell フレームバッファを使えるようにする lspci 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) とあるので、intelfbを使うことにします。 おそらく関係するのはこの辺り ktaka@lets:~/Kernel/linux-2.6.31.5$ egrep FB .config|egrep -v "^#" CONFIG_FB=y CONFIG_FB_DDC=y CONFIG_FB_BOOT_VESA_SUPPORT=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_FOREIGN_ENDIAN=y CONFIG_FB_BOTH_ENDIAN=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_INTEL=y CONFIG_FB_INTEL_DEBUG=y CONFIG_FB_INTEL_I2C=y 上記設定確認後、カーネルを再コンパイルしました。 そしてカーネルのオプションは、 video=intelfb:accel=0 vga=0x318 とすれば上手く行くことがわかりました。intelfbのデフォルトだとaccel=1になっていて、上手くいかないようです。 コンソールで日本語を表示する為に、jfbtermを使ってみる。 環境変LC_ALL=ja_JPでないと、日本語が表示できなかったりする。コンソールでjfbtermを使わずにmanページを見ることもあるので、普段はLC_ALL=Cで使いたい。 .bashrcで、TERM=jfbtermの時のみLC_ALL=ja_JPにするよう設定します。 if [ tty|sed -e 's/.*tty.*/tty/g'</code> == "tty" ] ; then export LC_ALL=C fi if [ $TERM == "jfbterm" ] ; then export LC_ALL=ja_JP export LANG=ja_JP.UTF-8 fi 以上の設定の後、コンソールログイン→screen起動→emacs/M-x w3mで日本語ページが表示できるようになりました。 このページもその環境から編集していますが、bloggerにログインする際、クッキーが使えないと叱られた。 .emacsに (setq w3m-use-cookies t) と書くことで解決しました。 残りは、後日。 [備忘録] jfbterm終了時に固まることがある件 2009-10-26T00:00:00+00:00 ここを参考に、以下のように変更 ktaka@lets:~/SRC$ diff -c jfbterm-0.4.7_orig/term.c jfbterm-0.4.7/term.c *** jfbterm-0.4.7_orig/term.c 2003-09-16 00:45:31.000000000 +0900 --- jfbterm-0.4.7/term.c 2009-10-26 23:09:54.000000000 +0900 *** 76,82 **** void sigchld(sig) int sig; { int st; int ret; ! ret = wait(&st); if (ret == gChildProcessId || ret == ECHILD) { tvterm_unregister_signal(); tterm_final(&gTerm); --- 76,82 ---- void sigchld(sig) int sig; { int st; int ret; ! ret = waitpid(gChildProcessId, &st, WNOHANG); if (ret == gChildProcessId || ret == ECHILD) { tvterm_unregister_signal(); tterm_final(&gTerm); 但し、asm/page.hが無といわれたり、コンパイルが通らないので、最新のデビアン用のパッチ</a>を当て、コンパイルを通す。 今のところ直っているようにみえる。 [備忘録] テキストコンソールでWeb閲覧 2009-10-26T00:00:00+00:00 LinuxのテキストコンソールでWeb閲覧したい件結局、/dev/tty1ならば、ssh-agent -> jfbterm -> screenと自動起動するようにしました。 export LC_ALL=ja_JP export LANG=ja_JP.UTF-8 if [ tty</code> == "/dev/tty1" ] ; then exec ssh-agent jfbterm -e screen fi screenのwindowでemacsを開き、そこで'M-x w3m'とすれば、Webが閲覧できる。日本語入力もemacs+skkのおかげでほぼ問題無さそうです。 screenの中からstartxでXが起動できないので、Xを使いたい時は、Alt+F[2-6]で他のttyに切り替えて使用することにします。 巷で評判のiPhone 3GSを購入しました。 2009-10-19T00:00:00+00:00 外出先から会社のメールを確認する際、今までemobileでネット接続していました。しかし、パソコンをブートするに時間がかかり、移動中の接続が面倒に感じていたので、思い切ってiPhoneを購入しました。 スマートフォンの類は、表示に問題があったり文字入力が使い難かったりであまり期待していなかったのですが、iPhoneは私にとって問題のないレベルです。 Gmailと会社のメールが両方ともIMAPで簡単に使えるということも重要なポイントです。会社のメールサーバはSSL/TLSを使っているのですが、特にポート番号を指定しなくても、勝手に探して繋がってしまいました。 keepalived-1.1.19がリリースされました 2009-10-08T00:00:00+00:00 10/1にkeepalived-1.1.19がリリースされました。 keepalivedのvrrpの実装では、ネットワークリンクがダウンするとFAULT Stateに入ります。ネットワークリンクがアップすると、FAULT StateからいきなりMASTERに昇格してしまい、コネクタの接触不良などの場合に、MASTERがバタバタ入れ替わってしまうという、かなり致命的な危険性がありました。 nopreemptオプションを有効にすることで、リンクの復旧時にBACKUPステートに入るようにでき、その様な危険性がなくなりました。 http://www.keepalived.org/changelog.html</a> カーネル読書会に参加してきました。 2009-02-24T00:00:00+00:00 先週の水曜になりますが、ylug主催の第93回カーネル読書会</a>に参加してきました。 今回のお題は、 お題：Unique experiences as x86-64 maintainer (good things, difficulties) 発表者： Andi Kleen 内容： x86-64のメンテナーとしての苦労話などをいただきます。 </blockquote> ということで、最近売られているほとんどのパソコンがサポートしている64bit機能に対応した、Linuxカーネルを開発したメンテナーのお話を聞きました。Andi Kleenは30歳位(?)のドイツ人です。2000年頃から、x86-64のカーネルを開発しているとのことでした。 Linuxカーネル開発の裏話などいろいろ聞けて楽しかったのです。 始めた頃は、x86-64のCPUが世の中に存在せず、何年もの間、ソフトウェアシミュレーターを使ってコードを動かしていたと聞き、とても感心しました。世の中には、すごい人がいるんだなぁと。 お話が終わった後は、ピザパーティでいろいろな人とお話させていただきました。 さて、ylugの勉強会はLinuxデベロッパーのすごい人が集まっていて、いつもレベルが高いのですが、何でも、第100回の読書会(今秋？)には、Linus Torvalds</a>をゲストに呼ぼうと計画しているそうです。 とても楽しみですね。 追記当日、朝日新聞の取材が入っていたということで、何気に吉岡さんの記事</a>を辿ってみたところ。。。 げげ、自分が写ってしまっている</a>。しかも顔半分。。 Intel Xeon 新モデル 2009-02-24T00:00:00+00:00 ここ</a>のニュース</a>によると、クアッドコアXeonの低消費電力版が、ようやく発売されたようである。　 同社は米国時間2月22日、45Wからの低消費電力モデルとなるXeonプロセッサを2機種と、ハイエンドモデルとなるXeonを1機種、新たに追加した。 　L3110（3.00GHz）は、6MバイトのL2キャッシュを搭載しつつ、45Wという、Xeonプロセッサとしては、Intel</a>で最低レベルの熱設計電力（TDPまたは熱設計枠とも呼ばれる）を実現している。価格は224ドルとなっている。 　L3360（2.83GHz）は、12MバイトのL2キャッシュを搭載して、TDPは65W。価格は369ドルとなる。 　ハイエンドモデルのX3380（3.16GHz）は、12MバイトのL2キャッシュで、TDPは95W、価格は530ドルに設定されている。 </blockquote> クアッドコアのXeon　X3360がTDP ９５Wだったので、TDP 65WのL3360にすることで、電流がおよそ0.3A抑えることができそうである。 さっそく、Intelのページ</a>にもスペック</a>が公開されている。 Yorkfieldを用いたサーバは、パーツの価格がこなれてきたこともあり、メインストリームがNehalemに移行するまで、まだまだ活躍しそうである。 1月の労働時間 2009-02-02T00:00:00+00:00 年始に、年間の目標労働時間を4,500時間と定めました。 100%集中していなくてもいいですが、とにかく仕事に向き合う時間を多くすることで、少しでもアウトプットを出したいという思いからの試みです。 別の言い方をすると、いくら効率を上げようと努力しても、絶対時間が不足していてはなかなか仕事の成果が出てこない、という過去の反省からの目標設定でした。 しかしながら、かなり、難しい目標設定だということがわかってきました。年間で4,500時間を達成しようとすると、月当たり375時間必要ですが、今月は、頑張ったつもりですが300時間にしかなりませんでした。 この調子でいくと年間3,600時間程度にしかなりません。せめて４,０００時間を目指したいところですが、そうすると、月当たり337時間程度必要です。 今月も頑張れればいいですが。。。心が折れないか心配です。 メルマガ配信完了 2009-02-02T00:00:00+00:00 いろいろと、ミスもありましたが、メルマガ配信完了しました。ひとまず、やれやれといったところです。今号のTopicは、 Intel SSD X25-E + RAID の記事と、Seagateのファームウェアアップデート方法に関する記事などです。 ご興味がありましたら、是非アーカイブページ</a>をご覧下さい。 DDR3への完全移行は2010年以降となるらしいです 2009-01-15T00:00:00+00:00 ネタ元</a>。 元々IntelもAMDもDDR3への完全移行を2009年としていたが、マザーボードメーカーの情報によると、現在ではどちらもDDR3のみ対応のチップを延期しており、2010年まで登場しないようだ。 DDR3メモリの価格がIntelが期待していたよりも下がらず、さらにCore i7とX58の需要も予想よりも下回ったため、IntelはDDR3のみの5 seriesチップセットを9月に延期した。 </blockquote> このIntelの言い分は本当なのかな。DDR3のメモリECC付きでも</a>結構安いと思いますが。 AMDと同じようにコンパチビリティの問題でもあるのかな？あるいはCorei7自体があまりにも人気が無いとか。 TDPが90w位に下がってくれれば使ってみたい気がしますが。まだ、時期尚早なんでしょうか？ Intelの爆速SSD 2009-01-13T00:00:00+00:00 Intelの爆速SSD、X25-Eを評価中です。 公称性能シーケンシャルリード250MB/s、シーケンシャルライト170MB/s 結果は、やはり爆速でした。詳しくは、評価レポート</a>をご参照ください。 評価をしてくれたのは、アルバイトの須永くんです。須永くんはSFCの3年生です。須永くん、ありがとう。 これだけ速いと、RAIDで8本束ねれば、1GB/s越えが狙えるかもしれませんね。楽しみです。 小さな会社の儲けのルール 2009-01-02T00:00:00+00:00 という本があります。創業当時何度も読み返し、勇気をもらった一冊です。その本を久々に開いてみると、こう書いてある 「思いは実現する」に必要なことこういう話をすると大体「いやー、そんなに働かなくてもいいでしょう」と言われます。でも、一代で何かを成し遂げた人たちがどのくらい働いていたか知っていますか？世界の偉人伝などを読んで概算すると、エジソンは年間6500時間で、それを40年間。キュリー婦人も5000時間を35年はやっていますね。本田宗一郎さんは一代で世界の本田を作った人ですが、あの方も5500時間を35年やっています。 </blockquote> 年間6500時間というと一日17.8時間を365日、5000時間だとしても13.7時間を365日働き続けたことになる。 それに比べると何と自分の甘いことか。 </blockquote> 今年の目標 2009-01-02T00:00:00+00:00 年間4,500時間働く </li> 売り上げ4倍増 </li> マーケティングがちゃんとできるようになる </li> 体重15kg減 </li> 洋服に気を使う(毎月洋服を買う) </li> </ul> 本家Linuxカーネルに採用されました！ 2008-11-07T00:00:00+00:00 うちのmitake君が書いてくれたEDACドライバが、メインラインカーネルに採用になりました。 http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.28-rc3 commit df8bc08c192f00f155185bfd6f052d46a728814a Author: Hitoshi Mitake Date: Wed Oct 29 14:00:50 2008 -0700 edac x38: new MC driver module I wrote a new module for Intel X38 chipset. This chipset is very similar to Intel 3200 chipset, but there are some different points, so I copyed i3200_edac.c and modified. This is Intel's web page describing this chipset. http://www.intel.com/Products/Desktop/Chipsets/X38/X38-overview.htm I've tested this new module with broken memory, and it seems to be working well. Signed-off-by: Hitoshi Mitake Signed-off-by: Doug Thompson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds </blockquote> 先日本ブログで紹介したIntelの2in1サーバ(SR1520ML)には、X38チップセットが搭載されています。このチップセットはECCメモリに対応しているので、1ビットエラーは訂正、2ビットエラー以上は検出可能です。 Linuxカーネルでは、この様なECCイベントをEDACというモジュールで検出することが可能なのですが、今までは、X38用のEDACドライバが存在していなかったので、検出できていませんでした。 それをmitake君が書いてくれたと言う訳です。 いずれ世界中のLinuxマシンに彼の書いたプログラムがのるわけで、これって、とてもすごいことだと思います！ mitake君、おめでとう！ 信用三本柱 2008-11-02T00:00:00+00:00 コンピューターのパーツの中で、ハードディスクが一番壊れやすい。弊社で販売したサーバのハードディスクが故障した場合に迅速に対応できるように、富山の置き薬を真似て、客先に予備のHDDを置かせて頂くサービスを開始した。 名付けて、「富山的電脳薬箱」 それに関連して、富山の薬売について、ネット上でいろいろ調べていたところ、次の様な商売の基本ともいえる心構えについての記述があったので、紹介したい。 「おきぐすりの歴史」</a>より。 三本柱とは「商いの信用」、「くすりの信用」、そしてもうひとつが「人の信用」です。　「商いの信用」の基本は、顧客との間にトラブルを起こさず、不正な商いをしないということです。一円の勘定も誤りなく正確に取引することで信頼関係が生まれます。　「くすりの信用」は、有効で安全な品質の高いくすりを提供することです。そのために、絶えず顧客の求めるくすりをリサーチし、品質開発に努めなければなりません。　「人の信用」はもっとも重視されました。顧客の悩み相談に乗って、適切なアドバイスを行ったり、励ましたりすることで信頼関係が作られています。　「くすりを売るのではなく、人間を売れ。顧客は人間を見てくすりの信用、イメージをつくる」という考え方が、人材開発を促し、くすりの量産化につながり、販売の拡大をもたらしたのです。 </blockquote> 誠にもっともな考え方であり、しかも記憶にとどめやすい。 Intel 2in1 サーバーはコストパフォーマンスが高い 2008-11-02T00:00:00+00:00 IntelのベアボーンSR1520MLを使ったローコストサーバ。</a> 同等スペックの1Uサーバ二台分のよりも、10万円以上安価です。 Quad Core プロセッサ対応のマザーボード、X38MLが二枚搭載されています。 X38MLは一枚で、Gigabit Ether 2ポート, IPMIオンボード搭載、メモリスロット4つ(最大容量8GByte)、高速なQuadCoreプロセッサを搭載可能等といった特徴があります。 電源共通のためメンテナンス性は若干落ちますが、省スペースで高性能。 HPCクラスタの計算ノードや、大規模WEBクラスタのノードにいかがでしょうか。 Intelの2in1サーバがイケてる 2008-09-20T00:00:00+00:00 発売は一年近く前になりますが、Intelの2in1サーバ、SR1520MLが意外とイケてることに気付きました。奥行き短めの1Uサーバに、i3200X38ML(10/2修正)のマザーボードが二枚はいります。何故最初はピンと来なかったのにイケてると思うようになったのか？ 　45nmのハイスペッククアッドコアCPUがそこそこ安価になった。</li> 　45nmのデュアルコアCPUが1万円以下で手に入るようになった。</li> 　i3200x38 expressチップセット(10/2修正)はLinux EDACによるメモリエラー検出ができなかったが、うちのmtk君がドライバを書いてくれた。近日メインライン(2.6.28位か？)にマージされると期待。</li> 　2.5inch HDDが、それぞれ一個ずつしか載らないのがイケてないように思っていたが、WDのScorpio Black(7200rpm)が意外と速いことがわかった。(今時2.5inchHDDでも探せば速いのがある。VelociRaptorなんか、高いけど、超速そう～)</li> 　BMCオンボードであることに気付いた。すなわちIPMI2.0で電源ON/OFFとか、SOL(Serial (console) Over Lan)が使える。</li> 　仕入値が意外と安いことに気付いた。同スペックのサーバx2 - 10万円で、販売できそう。といったことが、理由です。</li> </ul> つまり、ハイスペックCPU+省スペース+ローコスト+いろいろ便利、なサーバなわけです。 シングルソケットのNehalemが出回るまで、約一年。アレゲ(？)なサーバとして我が社でも商品化しようと思います。 WEBクラスタ、HPCクラスタのノードとして、結構良いかもと思っています。 オリジナリティ 2008-07-17T00:00:00+00:00 商売で何とか生き残るためには、オリジナリティとかクールさなんかなくても、顧客が求めるものを提供していくことが必要だと思う。でも、それだけじゃつまらないよね。 「やらなければいけないこと」と「やりたいこと」の違いを意識しないといけない 2008-07-02T00:00:00+00:00 例えば、日常のタスク次の様に属性分けしてみるとする。 「やりたいこと」、「やりたくないこと」</li> 「やれること」、「やれないこと」</li> 「やらなくてもいいこと」、「やらなければいけないこと」</li> 「やった方が良いこと」、「やらない方が良いこと」</li> </ul> 結局、取り掛かるのは、この中の「やりたいこと」「やれること」「やらなければいけないこと」、「やった方が良いこと」のいずれかの属性を持つものになるだろう。 当然、業務の中では「やらなければいけないこと」「やった方が良いこと」を、一生懸命やらないといけない。 しかしながら、中には、「やりたいこと」の属性しか持たないものばかりを、一生懸命やってしまう人がいる。「やりたいこと」に情熱を燃やすのは素晴らしいことだが、それが業務と勘違いしてはいけない。不幸のもとである。 自分も、若かりし頃、「やりたいこと」ばかりをやって、「仕事してるなぁー」と勘違いしていた記憶がある。 自分のやろうとしていることが、本当に業務として「やらなければいけないこと」なのか、単に自分が「やりたいこと」なのか、よくよく意識していないと不幸である。 その一方で、労働者としての自分自身を振り返ってみると、「やりたいこと」をやりたい。でも、「やらなければいけないこと」が残っている。手が付かないので、「やれること」に取り掛かる。そして、一日が終る。 こんなことばかり、繰り返して来た。あーあ、「やりたいこと」しかやらなくて良い職業に付きたいよー、とぼやいてみてもそんなのある訳無い。 「やりたいこと」=「やらなければいけないこと」なら良いのに。 でも、そうじゃないことが多い。 Just Do itの精神で片っ端から片付けて行くしか無い。 ひでぇ文章。 追記：このエントリ自体が、「やらなければいけないこと」からの逃避に他ならない。仕事しろよ>自分 SupermicroのIPMI 2008-04-28T00:00:00+00:00 最近のIPMIカードは、KVM(Keyboard Video Mouse) over LANとかがついていて、HTTPとか、SSHとか喋るので非常に使いにくかったのですが、古き良き時代のベーシックなIPMIカードが、Supermicroより発売されました。Supermicroのエンジニアにしつこく催促したのが功を奏したのかも知れません。 http://www.supermicro.com/manuals/other/AOC-SIMSOLC-HTC.pdf UDPの623のみを、SMBusに流すというわかりやすい仕様なので、ホストと同じIPを使うのも問題無さそうな気がします。 ボンディング使用時には、別IPにした方が無難ですが。。。 仮想化ブートキャンプ 2008-04-20T00:00:00+00:00 先週一週間、主要顧客のトップエンジニアの方々と、データセンターのサーバーを仮想サーバ上へ移行するための、インフラ開発作業を相模大野オフィスで行った。作業は、朝から夜の11時すぎ迄におよび、さながらブートキャンプの様相であった。 XenとKVM(Kernel Virtual Machine)の両睨みであるが、KVMの方が扱いやすいように思う。ツール群の充実、実績についてはXenの方が一歩先んじているが、KVMの場合は、ホストゲストともLinuxバニラカーネルで良くLinuxカーネルの機能がそのまま使え(例えばEDACなど)、非常に素直である。Xenの場合、Domain0カーネルは、2.6.18.8にパッチを当てまくったものを、xensourceで管理しておりこれが良くない。現時点で、3wareRAIDコントローラが全く使いものにならない。何で、バニラカーネル各バージョンへのパッチとして提供できないかな。私個人としては、KVM最高、Xen最悪みたいな印象。お客さんが一週間来るとさすがに気疲れします。最終日、相模大野叙々苑での焼肉パーティでリフレッシュ。おいしかった。 メガネ購入 2008-04-20T00:00:00+00:00 以前はメガネを使用していたのですが、ここ何年かずっと使い捨てのコンタクトレンズを使用していました。しかし、最近、目が充血することも多く、ちょっと前には結膜炎にかかり目脂で目もほとんど開けられないような状態のなか、仕事をしなければならなかったこともあり、久々にメガネを作りました。主に、休日ちょっと車で出かける時などに使用できれば良いので、ちょこっと色も入っています。 KVMフォーラム行きたい。。。 2008-04-20T00:00:00+00:00 けど、先立つものが。。。 http://kforum.qumranet.com/KVMForum/about_kvmforum.php</a> 仕事の中心 2008-04-10T00:00:00+00:00 仕事の中心は楽しさになければいけないと思う。新しいことにどきどき、わくわくしながら挑戦できる。そんな会社にしたい。 キャリアプランニング 2008-04-10T00:00:00+00:00 最初に、スタッフのキャリアプランニングを一緒になって考えたい。誰もが、一流のプロフェッショナルとして独り立ちできるように、成長して欲しい。将来像が見えれば、モチベーションも高くなるだろうし、いわゆるself motivating personになるだろう。 会社の仕事はスタッフのキャリアパスにすり合わせるようにすべきだ。スタッフが日々成長し結果を残せるようになれば、できないはずは無い。 ありがとう 2008-04-08T00:00:00+00:00 ありがとうと言われるような仕事をしたい。 お客に「ありがとうございます」と言うのが普通だと思われているかもしれないが、それは間違っている。何故なら、お客は金額以上の価値を感じるからこそ、購入を決めるから。本来「ありがとう」と言われるのは、サービスを提供する側で無ければならない。 そのためには、常にサービスの価値を高める努力をしなければならない。愛想も大切であるが、本来の努力を怠ってはならない。 また、お客に「ありがとう」と言われる商売程楽しいものはない。 Inspired by 神田昌典 人材の流動性 2008-04-05T00:00:00+00:00 優れた才能の持ち主が、組織の中で腐っていったり、精神的に病んでしまうのは絶対おかしい。企業側の飼い殺しは良くないし、雇われる側がフィットしないところにいつまでもしがみつくのはもっとダメ。 今の世論に逆らうようだけど、安定した正社員にこだわらずに、自分が活躍するところを求めて自由に転職できるようにならないといけないと思う。 そうしないと、才能が埋もれ、外国にどんどん引き離されてしまう。 新しい働き方、フリーエージェントなんかどうだろう？ かけ持ちで良い </li> 勤務日には期待されるアウトプットをきっちり出すこと </li> かけ持ちを認めるが故に、情報をミックスしない心がけ、脳内iptablesが必要である </li> 顧客や、契約に関する情報、顧客との取り決めで公にできない情報、公知でない新規技術情報等については、守秘義務を尊守するそれを実現するために必要なこと </li> 個々のスキルが、一社のみならず、広く業界で通用することが必要。すなわち常にスキルアップする必要あり </li> 経験が浅くスキルが完璧でなくても、その人なりに雇主からメリットと認められるアウトプットを出せることが必要 </li> フィットしなければ、後腐れなく一端離れれば良い </li> うまくいかないことは、たまたまその時ニーズとスキルがマッチしないだけもちろん、正社員とそうでない人が同じ仕事をして、同じような成果を出した場合、給与に格差があってはならない。 </li> </ul> そもそも、正社員ってなんだろう？ハローワークに募集要項を出す際には、フルタイムかパートタイムの区別しか無い。労働基準法的には、正社員も契約社員も区別が無いって、社労士さんが言っていた(要確認)。 最近はそうでも無いのかも知れないが、キャリアの大半を一社のみで過ごし、ほとんど会社の人としか接することが無い人生なんて寂しくないか？だから、私は会社を飛び出した。 六本木ヒルズ 2008-04-05T00:00:00+00:00 昨日六本木ヒルズに行って来ました。 以前、半常駐的に仕事させて頂いていた客さんでの、新規案件の打ち合せです。 不思議なオブジェ。 植え込みの花がきれいに咲いていました。 ブログの情報は良くないこともある。 2008-04-02T00:00:00+00:00 Linuxやネットワークなどの仕事をしていると、必要そうな技術情報はインターネット上に溢れている。なので、何かわからないことがあると、「グーグル先生に聞いてみよう♪」となることも多い。 しかし、検索に引っかかって来た情報を鵜呑みにしてはいけないと思う。 時々うんざりするのが、「〜について調べといてくれない？」と頼んだ時に、日本語ブログのURLがいくつも返ってくること。 そういう人って、「こうすれば動くみたいだよ」的な答えしか持っていなくて、まあ、要するに良くわかっていない。 かく言う自分も、質問されて良くわからない時に、URLをもって答えとする(笑)ことがある(反省)。 そんなレベルなら、自分でグーグル先生に聞きますよ。 少なくとも、自分の言葉で説明して欲しい</li> オフィシャルなドキュメント(あれば)かデベロッパーのメーリングリスト位あたって欲しい</li> 願わくば、ソースを拾って来て、grepかけて欲しい昔、WEBなんかまだ無かったころ、某F2研究所の上司が口をすっぱくして説いていたことを思い出す。(当時はCMOSのプロセスデバイスの研究をしていました。)</li> </ul> 「オリジナルの論文をあたりなさい」 彼は、解説書すら否定していた。 何が言いたいかというと、なるべくオリジナルな一次情報にあたることが大切であるということ。 エセ技術情報が溢れているいま、一次情報を選別し、そこから体系的知識を学び取るスキルが必要である。 と書きつつ、「エセ技術情報」を垂れ流す自分に再び深く反省。 まあ、心がけということで。 月末処理に忙殺される 2008-03-31T00:00:00+00:00 月末の入金確認と請求書の発行。買掛支払い。給料、家賃の支払。毎月のことながら骨が折れる。こういう経理処理を任せられる人がいるとすごく助かるのだが、お金のことだけに気が引ける。ましてや、うちみたいに規模が小さいと、頑張れば、自分と奥さんとで何とかなってしまうので、なかなか人に任せることができない。 毎日少しずつ書いてみよう 2008-03-26T00:00:00+00:00 ブログをはじめようと思ったはいいけど、なかなか書けない。毎日必ず、書く時間を設けるようにしよう。 クレーム 2008-03-26T00:00:00+00:00 神田昌典３６５日語録より、「クレームの質が変わっている。お客は品質ではなく、自分が大切にされないことに不満を抱いている。」なるほど、技術的にトラブルを解決することも大切ですけど、相手の立場にたって対応することが大切なんだなぁ。 ブログことはじめ 2008-03-18T00:00:00+00:00 ブログと言うものを始めてみようと思います。どんな内容にしようかな。 自分の会社のこと</li> Linuxやネットワークのこと</li> その他、いろいろ</li> </ul>

ktaka's blog

fcitx5 で日本語・中国語・英語の3言語入力環境を構築する

ピンインで繁体字を入力する</h2> fcitx5-chinese-addons に含まれる「簡繁変換」アドオン（chttrans</code>）を使うと、ピンイン入力のまま簡体字と繁体字を切り替えられます。別の入力メソッドを追加する必要はありません。</p>

トラブルシューティング</h2>

パスワードなしの認証を試す: oauth2-passkey ライブデモ

Try Passwordless Auth: oauth2-passkey Live Demo

GNU Screen ユーザーのための tmux カスタマイズ

Screen ユーザーが戸惑うポイント</h2> tmux に移行してまず戸惑ったのが、画面分割まわりの操作体系の違いです。</p>

プレフィックスキー</h3> Screen のデフォルトプレフィックスは Ctrl+a</code>、tmux は Ctrl+b</code> です。これは ~/.tmux.conf</code> で簡単に変更できるので、すぐに解決しました。</p>

カスタムキーバインドの解説</h2>

キーバインド一覧</h2>

Blogspot の記事を Zola + GitHub Pages に移行した

Phase 1: GitHub Pages の立ち上げ</h2> まず、既存の Markdown 記事を GitHub Pages で公開するところから始めました。</p>

Phase 2: Zola 導入</h2> pandoc 手動構成の限界を解消するため、静的サイトジェネレーター Zola を導入しました。</p>

Phase 3: Blogspot 全記事の移行</h2> Zola の基盤が整ったところで、Blogspot の全記事を移行しました。</p>

9年前に Joomla + wget で静的化したサイトを GitHub Pages へ移行した

移行前の構成: Joomla CMS + GCP</h2>

移行先の検討: GitHub Pages vs Netlify</h2>

OAuth2 and OpenID Connect (OIDC) Flow Testing: A Comprehensive Analysis of Response Types and Modes

Google OAuth2/OIDC and PKCE: Understanding Client Secret Requirements

Test Configuration</h3> This testing used: - Web Application client type in Google Cloud Console - Scopes: openid email profile</code> - Standard OAuth2 endpoints (https://accounts.google.com/o/oauth2/v2/auth</code> and https://oauth2.googleapis.com/token</code>) - PKCE method S256</p>

Mobile Applications</h3> If using Google OAuth2 with mobile apps, implement additional security measures: - Use certificate pinning - Implement runtime application self-protection (RASP) - Monitor for application tampering</p>

Server-Side Applications</h3> Standard OAuth2 flow with proper secret management: - Store client_secret</code> in secure configuration - Use environment variables or secret management systems - Rotate credentials regularly</p>

Implementing Passkeys Authentication in Rust with Axum

The WebAuthn Flow</h1> WebAuthn authentication involves two main phases: registration and authentication. Let's examine how each phase works and then implement them.</p>

Authentication Flow</h2> The authentication process begins with the server generating a new challenge. The authenticator then signs this challenge using the user's private key, and the server verifies the signature using the stored public key.</p>

Client-Side Implementation</h1> The client-side implementation handles both registration and authentication flows using the WebAuthn browser APIs. Let's walk through each process step by step.</p>

Registration Implementation</h2> The registration process begins by requesting options from the server. This establishes the parameters for creating a new credential:</p>

Authentication</h2> Implementation</p> The authentication flow follows a similar pattern but focuses on proving possession of an existing credential. We start by requesting authentication options:</p>

Registration Data Structures</h2>

Authentication Data</h2> Structures</p>

ピンインで繁体字を入力する</h2>
fcitx5-chinese-addons に含まれる「簡繁変換」アドオン（`chttrans</code>）を使うと、ピンイン入力のまま簡体字と繁体字を切り替えられます。別の入力メソッドを追加する必要はありません。</p>`

Screen ユーザーが戸惑うポイント</h2>
tmux に移行してまず戸惑ったのが、画面分割まわりの操作体系の違いです。</p>

プレフィックスキー</h3>
Screen のデフォルトプレフィックスは `Ctrl+a</code>、tmux は Ctrl+b</code> です。これは ~/.tmux.conf</code> で簡単に変更できるので、すぐに解決しました。</p>`

Phase 1: GitHub Pages の立ち上げ</h2>
まず、既存の Markdown 記事を GitHub Pages で公開するところから始めました。</p>

Phase 2: Zola 導入</h2>
pandoc 手動構成の限界を解消するため、静的サイトジェネレーター Zola を導入しました。</p>

Phase 3: Blogspot 全記事の移行</h2>
Zola の基盤が整ったところで、Blogspot の全記事を移行しました。</p>

Test Configuration</h3>
This testing used: - Web Application client type in Google Cloud Console - Scopes: `openid email profile</code> - Standard OAuth2 endpoints (https://accounts.google.com/o/oauth2/v2/auth</code> and https://oauth2.googleapis.com/token</code>) - PKCE method S256</p>`

Mobile Applications</h3>
If using Google OAuth2 with mobile apps, implement additional security measures: - Use certificate pinning - Implement runtime application self-protection (RASP) - Monitor for application tampering</p>

Server-Side Applications</h3>
Standard OAuth2 flow with proper secret management: - Store `client_secret</code> in secure configuration - Use environment variables or secret management systems - Rotate credentials regularly</p>`

The WebAuthn Flow</h1>
WebAuthn authentication involves two main phases: registration and authentication. Let's examine how each phase works and then implement them.</p>

Authentication Flow</h2>
The authentication process begins with the server generating a new challenge. The authenticator then signs this challenge using the user's private key, and the server verifies the signature using the stored public key.</p>

Client-Side Implementation</h1>
The client-side implementation handles both registration and authentication flows using the WebAuthn browser APIs. Let's walk through each process step by step.</p>

Authentication Data</h2>
Structures</p>