鍵を本体外に出したので、ssh 接続のたびに鍵ファイルを指定するのがだるくなってしまった。面倒なのはいけない。そこで ssh-agent を使うことにした。

ssh-agentをなんとなく避けていた

ssh-agent は今までなんとなく避けていた。というのも

ssh-agentってメモリ内にパスフレーズそのまま保存してるんじゃないの？

と思っていたから。ということはハイバネート状態のノートからは生のパスフレーズが抜き取れるよね、という話にたどり着いて、そんなあぶないもの使いたくないとか思っていたんだけど、そもそも

PC本体内に秘密鍵があるので本体奪われたらagent使っていようがいまいが一緒

という状態に目をつぶって頑なにagentを拒否していても意味がない。

ということで颯爽とポリシーを変更した。

本当は秘密鍵を抜き取ったことだし、今まで通り ssh-agent を使わない運用ならだいぶ安全になると思うんだけど、逆に接続のたびに USB メモリが必要だと結局 USB メモリ刺しっぱなしになりそうで、それだとまったく意味がない。分離した意味を持たせたうえで面倒なく運用するにはやはり agent を使った方がよさそうだ。

ssh-agentってしっくりこないんです！

ssh-agent は秘密鍵とパスフレーズを保持してくれる
ssh-agent とのやりとりは ssh-agent 自身ではサポートしてくれない
SSH_AUTH_SOCK と SSH_AGENT_PID を使った古典的な方法で、そのままでは shell が変わったら使えない
ssh-agent の多重起動も簡単に起きてしまう

ちなみにいちばん簡単な使い方は

eval `ssh-agent` で起動する
- ssh-agent は起動すると自身の管理に使える環境変数（のセット方法）を出力して daemon 化する。ここでこの出力を eval すると変数がセットされて、その shell 内では ssh-agent とやりとりできるようになる。
ssh-add で鍵を教える
- このとき必要ならパスフレーズを入力する

の2アクションを行えば、以降の ssh 接続では何もする必要がなくなる。

とは言え shell が変わったら使えなくなるのはきつすぎる。screen 起こしたらアウトだもの。

OSX標準のkeychainってしっくりこないんです！

OSX には 10.5 辺りから ssh 接続のときに GUI でダイアログが出てパスフレーズを記憶しようとしてくれる keychain さんがいる¹。ssh-agent を使いたくなかったのでこれも ~/.zshrc で

unset SSH_AUTH_SOCK

して殺していた。この記述を外して使ってやればいいじゃんと思ったりもしたが、

ssh 接続を hook して起きてくるので、接続しようとするまで ssh-agent は起きていない
ということは本体外に追い出してしまった鍵ファイルの場所を教える方法がない²
パスフレーズをシステムのキーチェーンに保存したいわけじゃない

ということでやっぱり黙っていてもらうことにした。

別途keychainをインストールする

Mac のキーチェーンじゃなくてこれ。

Keychain - Funtoo Linux

MacPorts でも Homebrew でもインストールできる。

ここで言う keychain の目的の一つは上で挙げた ssh-agent の shell をまたげないという問題を回避する方法を提供することで、もう一つは ssh-agent の多重起動も防止すること。何度呼び出しても ssh-agent は増えない。つまり、

ssh-agent を起動してSSH_AUTH_SOCK と SSH_AGENT_PID をファイルに吐き出す
ssh-agent を管理する

上の機能を提供してくれる。

実際に keychain を活用するには keychain をインストールして起動するだけではやっぱりダメで、自分の使っている shell の rc ファイルに上の 1 で吐き出されたファイルの存在チェックと、存在した場合の読み込み処理を追記してやる必要がある。

何を書けばよいかは man を読めば分かる。

OSX 標準のものを殺しつつkeychainを利用する

どこでもいいんだけど man にある通り ~/.keychain に agent 関係のファイルを保存することにしたので、

if [ ! -f $HOME/.keychain/$HOSTNAME-sh ] ; then
    unset SSH_AUTH_SOCK
fi

こんな感じで

自分で起こした keychain の使うファイルがあれば SSH_AUTH_SOCK はそのまま使う
- でないと ssh-agent とやりとりできない
存在しない場合は OSX 標準の keychain を呼ぼうとしてうざいので SSH_AUTH_SOCK は消しちゃう

ということにした。それ以外にも hostname を screen さんやいろんな人が利用していたりして結構面倒なことになっていたが、ようやく整理できた。

使い方

今はどうしているかというと、

USBメモリを刺す
eval `keychain –eval`
ssh-add /Volumes/PATH/TO/KEY
パスフレーズを入力
USBメモリを抜いて片付ける

で、快適生活してます³。

長時間席を外すときには

keychain -k all

しておくと安心。

どうやら SSHKeychain と言うらしく、/usr/sbin/systemkeychain が正体かな？そこから /usr/bin/ssh-agent -l を起動する。 ↩
と思ったけど ssh -i で教えられるな…。忘れてた。 ↩
ssh-add を keychain でやることもできる ↩

妙なライブラリの名前とコマンドラインオプション

Jun 02, 2009

Ruby

12:34:24 >wtnabe< あ、ubygems.rb っていうそういうことなのか。何この

                  typo 対応とか思ってたけど、こりゃー一本取られたわ。
12:59:32 <eban> @wtnabe un.rbもそういう意味

何のことかというと、例えば手元の MacPorts で入れた Ruby の library の中の一部はこうなってるんですよ。

$ ls -1F /opt/local/lib/ruby/vendor_ruby/1.8/
gauntlet_rubygems.rb
i686-darwin9/
rbconfig/
rubygems/
rubygems.rb
ubygems.rb

rubygems.rb があるのにこの ubygems.rb って何よ？

と思ってたわけです。しかも中身は

$ cat ubygems.rb
# This file allows for the running of rubygems with a nice
# command line look-and-feel: ruby -rubygems foo.rb
#--
# Copyright 2006 by Chad Fowler, Rich Kilmer, Jim Weirich and others.
# All rights reserved.
# See LICENSE.txt for permissions.
#++


require 'rubygems'

しかない。

なんじゃそれ！

と思ったけど、これはこうすると分かる。

$ ruby -rubygems.rb -e 'puts "foo"'
foo

どういうことかと言うと、

$ ruby --help
Usage: ruby [switches] [--] [programfile] [arguments]
  -0[octal]       specify record separator (\0, if no argument)
  -a              autosplit mode with -n or -p (splits $_ into $F)
...
  -rlibrary       require the library, before executing your script
...

ニクい。ニクいよアニキ！

Nostalgy の save は move

Jun 02, 2009

Thunderbird

しょっちゅうハマるのでメモ。

10:51:09 >wtnabe< いつまで経っても Nostalgy の save が move だと気づけ
ない
10:54:31 >wtnabe< うっかり save してその後、うわぁしまったって慌てて
move 先で該当メールを検索して copy し直さないといけない。
10:54:37 >wtnabe< なんで save なんて名前にしたの。

copy じゃないものを選べ！

『SQLの絵本』で自分の読み方を再確認

Jun 02, 2007

リンク

『SQLの絵本―データベースがみるみるわかる9つの扉』をざっと読み終えた。本屋で並んでいたのを見て何気なく手に取ったものなんだけど、それなりに良かった。値段分の価値があるのかと言われると若干微妙な気がしないでもないけど、本を汚しながら読むのが好きな自分としては Web 上の資料だけでは飽き足らなくなってくることがよくあり、やはり本てのはよくできてるなぁと改めて思った次第。

ここ数年は金がないとか場所がないとかいう理由であまり本や雑誌を買わないようにしていた。Web 上に有用な資料が揃っているし、買わなくてもやっていけるだろうということと、都会の人間と違って通勤中に本を読むという習慣がないので、意外と本を読む時間は少なくなってしまい¹、ほしい本を片っ端から買ってもどうせ消費できないことは容易に想像できたからである。

しかし画面とキーボードだけではやはりダメなんだなぁと再認識。情報の量や質という意味では今回の本は値段相応ではないように思うが、

モノとして存在し
そこに付箋を貼り、書き込みができる
そのための十分な余白が確保されている
しおりを挟んでどれくらい読み進めたのかが分かる

という点がやはり自分にはとても重要なんだなと感じた。単にリファレンスとしてほしいだけなら Web 上にある資料を全文検索に突っ込んでおけばいいんだけど、咀嚼して飲み込むためには本という物体が自分には合っているようだ。

あ、肝心の内容だけど、

Windows で SQL を初歩から学ぶ人向けになっている
- DB の設計とかパフォーマンスとか気にしちゃダメ
SQL 92 や 99 をベースにしていると書かれていて実際そうなのだが、一部に Transact-SQL（MS の SQL エンジン向け拡張 SQL）をベースにした記述もあり、最後には Windows 用の付録がついている
したがって Lightweight Language で PostgreSQL や MySQL を始めたいという人はほんのちょっと注意する必要がある。ほとんどは初歩の初歩なので DBMS の違いを気にするレベルじゃないけど、例えばサブクエリの話は MySQL では 4.1 以降でないと使えない。イマドキ、フツーは 4.1 以降だと思うけど、この本ではそういう部分へのケアはない。

とりあえず初歩の初歩としていくつか用語と考え方が分かるという程度になら十分かなという感じ。すでに何らかの知識を得ている人には物足りないが、まったくの入門には悪くないように思う。以前取り上げた『データベース村へ,ようこそ (Standard Technology Books)』は DBMS そのものの話が中心で SQL はほんのちょっとしか出てこないので、ちょうど補完し合うことができるのではなかろうか。

学生時代のように本を読むことそのものが仕事のうちという状況でない限り ↩

au のアドレスの話

Jun 02, 2006

ついていけてなかった。

auのEメールアドレスが相互接続性を保障できないルールに変更? (/.-j)

これはあれじゃないすか。

docomo が Compact HTML のときみたいに標準化へ向けたアクションを取る

のがいちばんじゃないかな。もはや世界最大のプロバイダなんだから影響力絶大でしょ。実験したところ、メジャーな MTA で問題が起きないって話もあるんだし。その方が現実的ではないかと。

それにこういう MUA 側の対応についての話題が大きくなれば、Outlook Express の添付ファイルの問題なんかももう少し真面目に考えなきゃなって機運になるんじゃなかろうか。

いずれにしても MTA, MUA の実装と RFC の乖離はあまり進まない方がいいと思うので、RFC改訂に一票。

WSH はめんどくさい

Jun 02, 2006

WSHを始めよう @IT

連載開始記念。

リンク

WSH は面倒だ。それは WSH 自身は自動化するための道具じゃないから。WSH は単にスクリプト言語と OS を多少仲良くさせるための土台でしかない。

WSH は面倒だ。tips ばかりで体系的な資料が少ない。まるで Web 上に散見される Linux セットアップ情報と同じだ。

WSH は面倒だ。スクリプト言語は結構いろんなものが選べるはずなのに、ほとんどのサンプルは VBScript で、Un*x 系の人間にとって悪夢みたいなものだから。¹

WSH は面倒だ。実は WSH のインターフェイスだけではできないことが多い。例えばファイルアクセス。これは WSH では提供されていない。WSH とはまた異なるライブラリである FileSystemObject を使うんだ。びっくりだろう？

WSH は面倒だ。実は WSH のインターフェイスだけではできないことが多い。WMI とか ADSI とか CDO とか知らないと結局外部コマンド頼みだ。しかも標準で用意されている外部コマンドではできないこともまた多いんだ。

WSH は面倒だ。WMI や ADSI に関しては WSH よりぐっと情報が少ない。オブジェクトの定義を示した英語のリファレンスは存在するので、それを読んで「こうかな？」とコードを組み立てていく必要がある。

WSH は面倒だ。ってゆーか WMI で出てくる奇妙なおまじないや WQL？ってゆーの？あれがキモイ。<> とか BASIC 風なのはゲイツの呪いかとか思っちゃう。Windows に触る限り BASIC 文化からは逃れられないってか。

WSH は面倒だ。CDO に至ってはもはや現行の資料があるんだかどうだかあやしいレベルだ。WSH と CDO を使ってメールを送信するサンプルスクリプトはいくつか見つかるが、じゃあ CDO では他に何ができるのか、教えてくれるサイトは Microsoft を含めてないに等しい。²

WSH は面倒だ。なぜなら提供されるライブラリが「機能するコマンド」ではないから。これらはあくまでプログラマが扱うオブジェクトなんだ。OS が持ってる情報を、多少スクリプトからも利用しやすいようにラップしただけなんだもの。プログラミングが得意な人ならともかく、管理コストを下げたいだけの人に対してはハードルが高いと言わざるを得ない。たぶん Visual WSH Studio なんつー製品が出る日も近い。

リンク

連載への期待と自身が WSH へ感じた落胆をミックスしてネタにしてみた。

基本的に Windows の管理の自動化は Unix の管理の自動化より面倒だと思う。標準で揃ってる道具に違いがありすぎる。log の rotate 一つサクっとできないだけで十分にいやな思いを満喫できるってもんだ。スクリプトに関しては MSH³ ベースになったら多少面白いかなとは思うんだけど⁴、そうするとまたイチからノウハウの溜め直し。この「以前のノウハウが死んでしまうことがやたら多い」のも管理する側からすると Windows の決定的にダメなところ。新機能が嬉しいなんて思うのは営業と広告記事書く人と何も分からずにお金だす人だけ。管理する人間にとっては同じノウハウが長い間通用して安定して動くことの方が何倍も嬉しい。

あと MSH/Windows PowerShell が .NET Framework 前提なのは旧世代の人間からすると嬉しくないですな。そんな追加追加でやっていいなら ActivePerl 入れてゴリゴリやっちゃうよと思ってしまう。だってその方が Windows 独自の話に悩まなくてよくなる部分が増えてハッピーだもの。

ちゅーことでスクリプトについては Vista に期待ってことで(え

※ おめーはこんな情報も押さえてねーのか、ってツッコミは大歓迎です。

参考

アサマシも含めて手元の資料を吐き出しておく。

システム管理な雑記 – Sleeve notes of a sysadmin –
- Windows管理周辺の情報はまずここから。ただしスクリプティングそのものは得意でないらしい。

WSH

Windows管理者のためのWindows Script Host入門 (@IT)
Windows Script (microsoft.com/japan)
- WSHエンジンとかドキュメントとか
Welcome to the Script Center (microsoft.com)

microsoft のサイトはできるだけ英語の方を探した方がよい。日本語版は訳が追いついてなくて結構な数のページが存在しない。あと、CHM ファイルに関するグチはこの資料を見てて感じたものです。絶対使いにくいって！

WMI & ADSI

Active Directory Service Interfaces
Active Directory Service Interfaces Reference
- この中の System Providers ってのが大事
- ADSI WinNT Provider
  - アカウントとか操作するのは実は WMI よりこっちの方が楽

Scriptomatic っていうツールがあるんですが、要するにただのサンプル閲覧環境ってだけで別に嬉しくなかった。なんかすげー絶賛されてたりするんだけど、なんでか分からん。まぁオフラインでも WMI とか ADSI 使ったスクリプトの開発ができますよってことか？

CDO つか Messaging

自由度を求めるなら CDO は使わずに Command Line SMTP Mailer for Windows や XMail Home Page (日本語) やＢＳＥＮＤＭＥＸＥなどなどの SMTP クライアント（サーバ）を自前で用意した方がたぶん確実で早い。余計なものを入れたくない気持ちは分かるが、標準状態の Windows はつらすぎる。

※ しまった。タイトルは「あなたが WSH を使うべきでない10の理由」にするんだった！