cuspy diary on cuspy.org

マイナンバーカードと電子署名の本(無料配布)

Sat, 04 Sep 2021 00:00:00 +0000

2018年開催の技術書展5で配布した「マイナンバーカードと電子署名の本」を無料配布します。マイナンバーカードと電子署名の本(PDF) たまにSNSなどで再販しれくれないかと要望が来ていたのだけど、BOOTHなどの販売ページを用意するのが面倒で放置していました。そのたびに無料公開しようかなと考えていましたが、それは購入してくれた人に対して不義理になるのではと考えてるうちに3年が経ち、さすがにもう良かろうと思うので無料配布します。古い内容があるかもしれないのでその点ご注意ください。そういえば最近Markdownが話題ですが、この本もMarkdownで書いて組版しています。誤りなどありましたら、原稿レポジトリでissue報告をお願いします。 https://github.com/hamano/myna-book どうしてもお金を払って読みたいという人はGithub sponsorで支払いできます。

キーボード制作(PCB編)

Mon, 19 Oct 2020 00:00:00 +0000

はじめてのKiCad。 KiCadことはじめを読みつつ、公開されている基板を参考にしながら手探りでやっていく回路設計前回設計したキーレイアウトを元に回路図を起こす。余ったProMicroのピンで遊べるようにスルーホールを用意した。フットプリントの配置基板をリバーシブルにするのは最初難しそうに感じたが、 foostan/kbd のフットプリントライブラリを使うだけで意外と簡単にリバーシブルになった。配線最初は手作業で配線していたが面倒になってきたので freeroutingを使って自動配線。自動配線は楽だけど傾いたフットプリントで失敗するのでそこだけ手動配線する必要があった。シルクを入れるフォントは鬼滅の刃でおなじみの闘龍書体 GNDベタ塗りうまく塗れてない所があるけど、もうこれで良いや発注 PCB製造業者としてよく耳にする Elecrow と FusionPCB とあまり聞いたことがない JLCPCB を比較検討した。料金は100x100mm以内であれば5枚で Elecrow $4.90 FusionPCB $4.90 JLCPCB $2.00 と、JLCPCBが最安で、200x200mmだと5枚で Elecrow $38.10 FusionPCB $38.24 JLCPCB $15.50 というように基板が大きくなるとJLCPCBの安さが際立つ。 JLCPCBに決定。今回作る基板は175x136mmで$10だった。発注後JLCPCBサポートから、ドリルの穴とトレースが近すぎてこのままだとトレースが削られっぞ、という連絡が来た。 KiCad既定のクリアランスが0.2mmだったのでこれを0.23mm変更(0.24mm以上ではホールとパッドが干渉する)して再配線したら問題なしとの返事があった。 JLCPCBにガーバーファイルを送るとPCBの制作工程を動画で演出してくれる。ドミノピザみたいに。届いた待つこと10日程度、PCBが届いた刀剣をイメージしてカットしたエッジは鋭い。まさに凶器。届いたPCBをよく見るとTRRSジャックの穴が空いていない、設計をミスったのか製造業者のミスなのか分からず問い合わせてみると業者が平謝り、クーポンを貰えることになった。はるばる深センから届いた板を捨てるには勿体ないのでハンドワイヤーでなんとかしてTRRSジャックを取り付けた。これだとケースを作っても収まらないだろうな実装どうにか完成。ゴム足を付けるとこれだけで十分実用的に使える。 rev2にむけて TRONキーボードっぽく手の形に合わせて角度をつける角度をつけるとAuto Routingが失敗するので配線が大変そう基板をRJ9とかRJ11で繋ぎたい、 TRRSでつなぐとショートしそうで心配 I2C通信したい OLEDつけたい

キーボード制作(キーレイアウト編)

Sat, 26 Sep 2020 00:00:00 +0000

試作したキーボードを使い始めてしばらく経ち、壊れたり直したりを繰り返していた。その度キーレイアウトを調整しても違和感が残り、特に親指キー(最下段キー)の配置がいまひとつで、なかなかPCBの設計に移れない。修飾キーを親指で押す修飾キーは左右2個ずつ欲しいという欲求を満たすためこんな風に親指キーを5x2個にしてみたが端のAltキーがどうにも押し辛い。中指を使えば良いと思うかもしれないが修飾キーなので親指で押したい。そこで試しているのがこのレイアウトこのSuperキーは小指の先で押すのではなく小指の付け根で押す。この指の付け根による打鍵はちょっとした手首の傾きだけでキーを押せるので負担が少ないことが分かった。ホームポジションから指を移動せずに押せるキーのことを一等地キーと呼んでいるが、あらたな一等地を発見した気分。もうひとつ改善したい所として、SandSキー(長押しでShift、タップでスペース)でtypoが頻発している問題があった。長押しを判定するしきい値(ms)を調整すれば良さそうでもあるが、ShiftとSpaceの単独キーがあったほうが明らかに認知コストは低いのでこの一等地はShiftで利用することにした。従来のキーボードのShiftの位置とさほど変わらないので移行コストが少なくなる。この端のSuperもまた小指の付け根でチョップするような感じで打つと小指に負担はかからない。まだまだ調整したいと所がはあるが、永久に終わらないのでひとまずこれをMusahi60 rev1のキーレイアウトとし、PCBの制作を始める。

キーボード制作(試作編)

Fri, 03 Jul 2020 00:00:00 +0000

なぜ人はキーボードを作るのか… 皆さまざまな想いがあってキーボードを自作しているのだろうけど、既製品を選ぶ時は入手可能性について考えることが多かったように思う。人間工学に基づいたエルゴノミクスキーボードにうっすら興味はあったけど、 10年後にこれと同じものが手に入るだろうか、という不安が過り、慣れ親しんだキーレイアウトを変えるという決断が出来なかった。しかし自らの手でキーボードを作れるようになった今、既製品のキーレイアウトに囚われる理由が無くなった。壊れたらまた同じものを作れるし、不合理なキーレイアウトを少しずつ変えていくことも出来る。作ろう。自分の手に馴染むキーボードを、目指そう。完全無欠のエンドゲームを、コンセプト 60%くらいのキー数の分割キーボード Column Staggeredを採用、Row Staggeredは悪い文明数字キーあり数字キーおよびShift+数字キーの記号は単一キーであってほしい小指に優しい emacsでCtrl多用すると小指がつらい HHKBでFnを多用すると小指がつらい豊富なModifierキー普段タイル型Window Managerを使っており、あらゆるウィンドウ操作をキーボードで行っているためModキーは多ければ多いほどよい変換(IME ONにマップ)、無変換(IME OFFにマップ)の単発キーが欲しい IMEのON/OFFをトグルにすると余計な認知コストがかかる HHKBで変換・無変換とSuperキーを両方使用出来なかった不満を解消キーレイアウト & キーマップこうなった特徴は TRONキーボード風にEnter, Backspace, Esc, Tabを人差し指に持ってきたコンソールでEnterとBSはCtrl + J, Ctrl + Hを使っているのであまり違和感は無い、EscとTabは馴染めるかどうか心配 Control, Shiftを親指に持ってくる思い切った変更だけど小指がとても楽になった emacsで小指に負担がかかる問題が解消 Controlが親指のホームポジションなのでこれがまた快適 Raise + (h|j|k|l) でカーソルキーになる Webブラウザでスクロールする際にこれまでFn(小指)を使っていたのがとても楽になった Lower + (h|j|k|l) でマウス操作できる F1〜F20まであるファンクションキーってそんなにあったんだ、という印象 Hyperキーがある現代では失われてしまった歴史的補助キーを復活。Window Managerやemacsのキーバインドで使う予定。いくつかの親指キーはQMKのMod+Tap機能を利用した。 Ctrl and Spaceキーは長押しするとCtrl、タップでSpaceとなる。類似のキーボードとしてはRedoxやKeyboardio Model01と似たような感じになった。これらのキーボードは良いなとは思ったけど、細かい所が気になって結局買わなかった。

Choco60ビルドログ

Tue, 21 Apr 2020 00:00:00 +0000

Mint60は入門に適した素晴らしい自作キーボードキットで初めてでも難なく組み立てることが出来た。しかし実際に使おうとすると単にバックスペースの位置がHHKBと違うという理由でキーレイアウトに馴染むことが出来なかった。(キーマップを変更してもBACKSLASHとGRAVEをBSの上に配置できない) もう基盤から作るしかないのかな、と考えていたところChoco60という望んでいた通りの自作キットを見つけた。こうして2つ目の自作キーボードをビルドすることになった。 2度目があれば3度目もあるかもしれないので、組み立てログをここに記す。キースイッチ選定タクタイルを中心に下記3種類を検討した。 Aliaz Silent Blue Zilent v2(62g, 65g, 67g, 78g) Purple Zealios v2(62g, 65g, 67g, 78g) 遊舎工房の店舗で実際に試してみたかったけどこのご時世なので店舗には行かずYouTubeやRedditなどのレビューを参考にBlue Zilent v2(62g)に決定。結果として程良い重さだった。キーキャップ選定 Choco60に付けるキーキャップには 1.5uのバックスペース 2.75uと2.25uのスペースバー 1uのBACKSLASHとGRAVE が含まれているのが望ましい。 GMKがお勧めと書かれてたけど、結構な値段だしグルーブバイなんて待ってられないということで他のものを探してみるとリーズナブルな価格でMoonlanding 1969というキーキャップを見つけた。 Moonlanding 1969 これを中国から輸入。通常1週間で届くところ2週間程度かかった。 lube 今回タクタイルのBlue Zilent v2をTribosys 3203でlubeしてみた。 lube前と比較していないので正直なところ違いがよく分かっていない。キースイッチを取り付けて鍵打テストをしてみると、ショートしたままのスイッチが2つもあった。初期不良というよりもlubeした後にスイッチを組み立てる過程で失敗した可能性が高い。一度はんだ付けしたスイッチを外すのは大変面倒なのではんだ付けの前にきちんとテスターで確認したほうが良い。リストレスト無いよりあったほうが快適と言われるリストレスト。分割キーボード用のリストレストなんて無いだろうから木を切って作るかと思っていたところ、まさかの既成品が売ってた。かかった費用 Choco60 キット: ¥15,400 Blue Zilent v2(62g)@65: ¥8,372 Moonlanding1969キーキャップ: ¥6,141 Tribosys 3203 - 3g: ¥1,000 計(送料・税込み): ¥30,913 実用的なキーボードをビルドできてとても満足。キット製作者に感謝。参考資料 Choco60 – recompile keys Cocoa40 ・ Choco60 ビルドガイドキースイッチベストプラクティス Zilent v2 and Zealio v2 vs Holy Panda Review!

AddressSanitizerを試す

Fri, 16 Dec 2016 00:00:00 +0000

C言語 Advent Calendar 2016 16日目です。

clang 3.1, gcc 4.9以降にメモリ関連の不正な操作を検出するAddressSanitizerという仕組みが入りました。二重freeやバッファオーバーフローなどCプログラミングにありがちなメモリ操作を検出できるので、ソフトウェアの品質向上だけでなく、セキュリティ対策としても有用です。

以下に思いつく限りのメモリの不正操作を実際に試してみました。

ターミナルに雨雲を表示する

Fri, 02 Dec 2016 00:00:00 +0000

東京アメッシュ便利ですよね。 1日の天気予報が知りたいのではなく、「今」降っているのか、とか5分後に雨が降るのかどうか知りたいって時は天気予報を見るよりもアメッシュで雨雲の動きを自分で予測するほうが確実です。

あとゲリラ豪雨がやってくる季節になると、天気予報が役にたたなくなります。そんなときアメッシュを見ながら外に出るタイミングを見計らったりしていますが、わざわざブラウザを起動するのが面倒なのでつくりました。

ターミナル上に雨雲を表示するシェルスクリプトame.shです!

(これが言いたかっただけです…)

Raspberry Piでつくる! 柔らかローストビーフ♪

Fri, 25 Dec 2015 00:00:00 +0000

Cookpadに投稿しようかと思いましたが、せっかくRaspberry Pi Advent Calendar 2015の25日枠を頂けたのでこちらに参加させて頂きました。

クリスマスといえばローストビーフですね♪ 真空低温調理法という科学的に裏付けられた調理法は肉本来の旨さを最大限引き出してくれます。真空低温調理法についての詳細はCooking for Geeks ―料理の科学と実践レシピなどを読んでみてください。

Cookpadなどでは炊飯器の保温機能を利用してこの調理をやっている人を見かけますがこれはオススメ出来ません。理由はこの記事の最後に追記しましたのでこちらを読んでください。

これはRaspberry Pi 2で低温調理器を作成してローストビーフを作るためのレシピです。

YubiKeyのPIVカードでSSHする

Tue, 11 Aug 2015 00:00:00 +0000

前回はYubikey NEOをFIDO U2Fの多要素認証デバイスとして利用する方法を紹介しました。 YubiKey NEOはFIDOの他にも幾つかの機能を持っていて、PIV(Personal Identity Verification)カード仕様に準拠しています。 PIVは米NISTが定めた身分証明ICカードに関する技術仕様です。例えばNSAやCIAなどの米国公務員が身肌放さず持ち歩いているICカードの仕様となります。この様なプロフェッショナルなスパイ達も利用している認証デバイスを米国外の一般人がAmazonで購入して利用できるのは素晴らしいことですね。一方、日本の国家公務員が利用している身分証明ICカードの技術仕様は非公開です。1 技術仕様を公開することで安全性を高めている米国のICカードと、技術仕様を非公開にすることで安全性を高めいている日本のICカード、同じ所を目指しているはずなのにどうしてこれほど方針が違うのでしょうか。それはともかく、このPIVカードを持っているとCIAごっこなどをして遊ぶことができます。さらにYubiKeyのPIV機能はOpenSCを経由してアクセスできるので、OpenSSHやOpenSSLから利用できます。つまりYubiKey内の秘密鍵や証明書を用いてSSH認証やSSLクライアント認証できるということです。 SSH鍵を物理的なトークンで管理することには幾つかのメリットがあります。 SSH秘密鍵をファイルで管理するという従来のやりかたは、秘密鍵を盗まれた際に盗まれたことに気が付かないという欠点があります。 SSH鍵を複製不可能な物理トークンとして管理することで、ログイン権限を一時的に貸し出したり、金庫に入れて厳重に保管することが可能です。 YubiKey NEOを操作するためのツールはオープンソースで公開されているのでLinuxやMacOSでも簡単に利用できます。ここではYubiKey NEOで生成した秘密鍵でSSH認証を行う方法を紹介します。現在のところ、YubiKeyのPIVを操作するツールはDebian Jessieには用意されていませんので、sidから持ってくるか、自分でビルドする必要があります。 # apt-get install yubico-piv-tool opensc もしくはこちらからビルド PIVカードの状態は以下のようにして確認できます。 % yubico-piv-tool -a status CHUID: No data available Slot 9a: No data available. Slot 9c: No data available. Slot 9d: No data available. Slot 9e: No data available. PIN tries left: 3 9a, 9c, 9d, 9e という4つの空スロットが見えます。ここでは、9aスロットにRSA2048bitの秘密鍵を生成します。

Linuxでも使える! FIDO U2F認証トークン

Wed, 05 Aug 2015 00:00:00 +0000

Yubico社のYubiKey NEOはOTP、FIDO U2F,NFC通信に対応したお手頃価格のUSB認証トークンです。 FIDO U2Fに準拠した多要素認証、ワンタイムパスワード認証、PKI証明書ストア、SSH、PGP, PAMなどの用途で利用できます。 FIDOに対応しているサービスはそれほど多くありませんが、現在の所GoogleやLastPassなどのサービスで多要素認証を行うことができます。以前は輸入するしかなかったのですが最近Amazonで手軽に購入できるようになりました。この手の認証デバイスはWindows用のドライバしか用意されてなかったりしてLinuxでは利用できなことが多々ありますが、その点YubiKeyは安心です。 OTPの利用だけならYubiKeyはキーボードとして認識されるので、専用ドライバ無しで動作します。デバイスの管理ツールもオープンソースで公開されているのでLinux,MacOS,Windowsで問題なく利用できます。 DebianやUbuntuなどにはバイナリパッケージが用意されているので簡単にセットアップ出来ました。 # apt-get install ykneomgr yubikey-personalization YubiKey NEOはOTP/FIDU U2F/SmartCardなどの利用モードを切り替えて利用することができます。 YubiKey NEOに設定できる利用モードは以下の通り。 0 OTP device only. 1 CCID device only. 2 OTP/CCID composite device. 3 U2F device only. 4 OTP/U2F composite device. 5 U2F/CCID composite device. 6 OTP/U2F/CCID composite device. しかしykneomgr -mというコマンドで製品出荷時のモードを調べようとすると、 % ykneomgr -m error: ykneomgr_discover_match (-4): Backend error というエラーで現在の利用モードを調べることが出来ませんでした。 YubiKey NEOは出荷時にモード0(OTPのみ)に設定されており、このツールはPCSC経由で操作を行っているためにモードの参照/変更が出来ない、という罠でした。 ykneomgrを利用するためには、まずrootユーザーでykpersonalizeを実行し、利用モードを設定する必要があります。 # ykpersonalize -m 6 Firmware version 3.

ØMQガイドブック(日本語版)

Thu, 07 May 2015 00:00:00 +0000

ZeroMQの公式かつ唯一の入門本、「ØMQ - The Guide」を和訳しました。 ZeroMQを使ってアプリケーションを書いたのは数年ほど前なんだけど、その時この本が大変役立ったので、翻訳していました。全8章中4章まで訳して力尽きてしまいましたが、ここまででZMQの基本は十分抑えられると思います。この本は一応、ZeroMQの入門書という体裁になっていますが、もっと一般的なメッセージングシステムの設計方法を学べるように書かれています。マルチスレッドプログラミングおよびネットワークプログラミングで起こる一般的な問題の解決方法や、分散アプリケーションの設計方法などを学ぶことが出来ます。たとえば、P2Pアプリケーションや分散ハッシュテーブルなどの基盤を実装したいと考えている方にもオススメの本です。一番面白かったのは8章で、分散コンピューティングフレームワークを実装する上での現実的な問題を取り扱っています。これを読みたい人は原書を読んでください。ダウンロード PDF版 zguide-ja.pdf epub版まだ無い誤訳などあれば @hamano までソースはこちら: https://github.com/hamano/zguide-ja

第21回IOCCC入賞作品「踊る人形」

Thu, 18 Oct 2012 00:00:00 +0000

第21回IOCCCで銀賞を頂きました。とても光栄です。 http://www.ioccc.org/2012/whowon.html 自分で書いたコードですが、もう既に理解できなくなってく来ているので早うちに解説を残しておきます。作品のテーマは最も難解な部類に入るファイルフォーマットであるPDFと、あえて難解に書いたC言語のコラボレーションです。このプログラムはテキスト文字列を入力として受け取り、難読化したPDFファイルを出力します。この難読化手法は、有名な推理小説「踊る人形」に登場する単一換字式暗号です。たとえば、 % gcc -o hamano hamano.c % echo 'Hello World!' | ./hamano > hello.pdf と実行すると以下の様なPDFを出力します。このPDFファイルは、Adobe Acrobat Readerやevince, XpdfなどのPDFリーダーで読むことができます。さらにこのPDFファイルはCコンパイラでコンパイルすることができます。得られた実行ファイルは、難読化前の文字列を復元します。 % gcc -o hello -xc hello.pdf % ./hello Hello World! 任意のグリフを表現できるPDFならではの作品ですね。もちろんこのグリフは一般的なフォントとしては存在しないので、PDFに埋め込む必要があります。これらの字型はType3フォントと呼ばれるフォーマットでつくりました。 Type3フォントはPostScript言語で表現できるコンパクトなフォント仕様なのですが、現代ではほとんど使われておらず、何処を探してもこのType3フォントを利用しているPDFファイルを見つける事は出来ませんでした。 PDF仕様について興味ある方は仕様書を読んでみてください。1300ページほどあります。難しかったかったのは、どうやってこのフォントデータをプログラムに押し込めるかという事でした。いくらType3フォントが小さいといっても、まともに埋め込むと10kbyte以上のサイズを要します。これでは大会ルールのサイズ制限(2024byte)に収まりません。そこで、グリフを頭と胴体、右腕、左腕、右足、左足、逆立ちフラグという様に分解することで、データ表現を可能な限り圧縮し、実行時に完全なフォントを生成しています。たしかこんなレイアウトで分割した各部位への参照を保持しています。逆立フラグ左腕右腕右足左足 1bit 2bit 2bit 2bit 2bit これが配列v[32]実態です。実は元ネタの小説の中では「f」,「j」,「k」,「q」,「u」,「w」,「x」,「z」といった文字は登場しませんのでこれらの字型は記述量が少なくなるように私が勝手に創作しました。またスペースについても独自の解釈を加え大文字の場合に旗を付け加えています。逆立ちした場合、足で旗を持っているように見えるのは改善の余地がありますね。審査員のコメント http://www.ioccc.org/2012/hamano/hint.html ソースコード http://www.ioccc.org/2012/hamano/hamano.c ちなみに頂いた賞の名前「Most elementary use of C」はホームズの映画やドラマでおなじみのセリフ「Elementary, My Dear Watson.」(初歩的なことだよワトソン君)から来ていると思われます。

数独を解く(画像解析)

Fri, 29 Jun 2012 00:00:00 +0000

画像として与えられた数独を解きます。新聞に掲載されていたこの問題をOpenCVを使って画像解析する。(画像が斜めなのはワザとです) グレースケール変換画像解析の前処理として、まずグレースケールに変換し、ガウシアンフィルタをかけてぼかします。ガウシアンフィルタをかける事で、安定した二値化画像が得られます。二値化次に二値化を行います。二値化には、普通の方法、大津さんの手法、適応的二値化、などさまざまな手法が在ります。いろいろ試した所、適応的二値化(Adaptive Threshold)が最も数独の認識に適していることが解りました。適応的二値化(Adaptive Threshold)であれば、影になってしまった部分も上手く処理できます。膨張処理次に、数独の盤面の外枠を認識を行います。二値化の影響で枠線が途切れてしまう可能性がありますので、膨張処理(dilate)を行います。 (膨張処理は白色の部分に対して行われるので反転を行なっています。) 大枠の検出一時的に盤面の大枠以外を取り除きます。この辺りは非常に泥くさい事をやっていて、失敗する可能性が高いので改善したい所です。盤面の輪郭を検出します。矩形の頂点を見つけ出します。射影変換先ほど得られた矩形の頂点から、ホモグラフィー行列を求めて射影変換を行います。これにより、斜めに撮影した盤面を正方形に補正できます。こちらを参考に実装しました。膨張処理前の画像に対して射影変換を行うと、こうなります。ノイズ除去射影変換を行った画像を単純に9x9分割すると、以下の様にゴミが残ります。ゴミが残ると、後のOCR処理で誤認するので、取り除かなくてはなりません。このゴミを除く処理が厄介でした。ラベリングを行いその面積を計算して、認識すべき数字とゴミを区別するのですが、以下の様に枠線が残った場合に数字の「1」や「7」と区別が付かないという問題がありました。もっと上手く枠線を除去するアルゴリズムを考えたほうが良いかもしれません。数字を読み取る OpenCVによる機械学習で数字を分類する事も可能ですが、学習データを集めるのが大変そうなので、Tesseractを使って数字を読み取りました。現在最新版のTesseract 3.02はなぜか数字の識字精度が悪いのでTesseract 3.01を使うことにした。問題を解くテキストになれば、問題を解くのは容易です。こちらのアルゴリズムを実装すれば大抵の問題は解けます。昔書いた数独ソルバーに問題を渡してやります。解が得られました。 +---+---+---+ |941|836|257| |825|179|643| |736|254|189| +---+---+---+ |682|395|471| |197|642|538| |453|781|962| +---+---+---+ |568|927|314| |319|468|725| |274|513|896| +---+---+---+ まとめ上記のアイディアを実装して、大体の画像を解けるようになった。正しい認識率は10問中9問程度なのでもう少し精度を上げたい。最初はPythonで書いてたけどPythonのOpenCVバインディング(cv2系)がバグだらけだったので、所々CやC++で書いたコードが混ざってカオスになった。統一したい。 Tesseract 3.02 の数字の認識精度が悪かった参考資料 OpenCV: フィルタと色変換画像の二値化 | OpenCV.jp 射影変換 - OpenCV@Chihara-Lab. tesseract-ocr 解法アルゴリズム http://stackoverflow.

うるう秒のLinuxへの影響(2012年7月版)

Tue, 05 Jun 2012 00:00:00 +0000

2012年7月1日 08:59:59 秒(JST)の後に1秒が追加される、うるう秒が発生します。うるう秒に関する基本的な情報は以下のNICTのページで説明されています。うるう秒の対応（２０１２年７月実施版）このうるう秒発生時における、Linux上のNTPの動作について検証してみた所、各種Linuxディストリビューションによって動作が異なる事が解ったのでまとめてみました。検証はNICTで公開されている簡易NTPサーバーを利用して、LIフラグが01のパケットを受け取る方法で行いました。うるう秒発生時の挙動として以下3種類のパターンが挙げられます。 kernelの機能を利用して時刻の補正を行う LIパケット受信時、ntpdはシステムコールの adjtimex(2) を発行し、kernelの機能を利用して時刻の調整を行います。結果として、うるう秒発生時に時間の逆行が発生します。この動作は、IBMの【Technical Notes】Linux システムクロックの『うるう秒』調整で解説されている通りの動作となります。該当ディストリビューション: CentOS 5(ntp-4.2.2p1-15), CentOS 6(ntp-4.2.4p8-2), Debian Lenny(ntp-4.2.4p4+dfsg-8lenny3)で確認 kernelの機能を利用せず時刻の補正を行ううるう秒発生時、ntpdはclock_settime(2)を利用して時刻の調整を行います。結果として、時刻の進行が数ミリ秒遅れて逆行します。ディストリビューション付属のntpdとしては未確認、KERNEL_PLL が無効でビルドされたntpdでこの様な動作になりうる。古いkernelやntpdの環境はこの動作になるかもうるう秒発生時なにも行わないうるう秒発生時以降、標準時との間に1秒の誤差が発生するが、その誤差は徐々に補正されていきます。該当ディストリビューション: Debian Squeeze(ntp-4.2.6.p2+dfsg-1+b1), Debian Wheezy(ntp-4.2.6.p5+dfsg-2)調べてないけど恐らくUbuntuも各パターンにおける時刻の進行は以下の通りです。以下の様なperlスクリプトで1ミリ秒毎にgettimeofday(2)を呼んで時刻の進行を確認。gettimeofday.pl 逆行が発生するパターン(ntp-4.2.4 以前) 08:59:58.9 08:59:59.0 08:59:59.1 08:59:59.2 08:59:59.3 08:59:59.4 08:59:59.5 08:59:59.6 08:59:59.7 08:59:59.8 08:59:59.9 08:59:59.0 08:59:59.1 08:59:59.2 08:59:59.3 08:59:59.4 08:59:59.5 08:59:59.6 08:59:59.7 08:59:59.8 08:59:59.

spモードメールの脆弱性がやっとなおった

Thu, 26 Apr 2012 00:00:00 +0000

去年の暮れにIPAに報告したspモードメールアプリの脆弱性が修正されました。 JVNDB-2012-000037 spモードメールアプリにおける SSL サーバ証明書の検証不備の脆弱性 JVN#82029095 spモードメールアプリにおける SSL サーバ証明書の検証不備の脆弱性 JVN iPediaよりこの図だと、ユーザーの明示的な操作によってメールの送受信を行なっているように見えるけど、忘れてはいけないのはSPモードメールはプッシュ通知されると言うこと。攻撃者が、対象ユーザーのメールアドレスを知っている場合、対象ユーザーに空メールやSPAMメールでも送りつければ、それだけで認証情報を奪われてしまう危険性がありました。認証情報というのはESMTPS/POPSプロトコル上にBASE64(’\0’ + ユーザー名 + ‘\0’ + パスワード) という形式で流れていて、このパスワードを奪われれると、いつでも対象者のメールを盗み見れるし、対象者になりすましてメールを送ることが出来てしまいます。これほど明白な脆弱性であっても、ベンダーに直してもらうのはなかなか大変。脆弱性では無いと言い張られたり、お客様の意見として前向きに検討しますとかって逃げられる事はよくあります。当初はtwitterで少し煽ってドコモに報告すれば、さっさと直して貰えるかなとも思ったけれど、「公共の無線LANでメールを盗聴されるのは仕方がない。」だとか、「ユーザー自身が注意して使うべきだ。」などと言い出す人たちが現れ始めてウンザリしたのでやめた。 IPAとのメールのやりとりは4,5回程度、途中再試が必要になったりもしたけど非常にスムーズに進行した。報告から修正まで4ヶ月かかったけどこれはドコモの対応が遅かったのだろう。脆弱性を見つけたらIPAに届け出るという方法なら煽り力無くても出来るし、ベンダーと無駄なバトルをしなくて済むのでお手軽ですね。

MongoDBの薄い本(The Little MongoDB Book)

Tue, 17 Apr 2012 00:00:00 +0000

Karl Seguinさんの「The Little MongoDB Book」を和訳しました。この本はMongoDBの基礎を実際に手を動かして学ぶチュートリアルです。 MongoDBの基礎から、データモデルの設計方法、MapReduceなど幅広い内容をカバーしています。また、特別MongoDBに興味が無くても筆者のNoSQLへの考え方は一読の価値があるだろう。ダウンロード PDF版 the-little-mongodb-book-ja.pdf epub版 the-little-mongodb-book-ja.epub(あんまりきれいに組版できてないけど…) 誤訳などあれば @hamano までソースはこちら: https://github.com/hamano/the-little-mongodb-book 更新履歴 2012/04/17 v1.0 初版公開。 2012/06/15 v1.1 誤字、誤訳の修正。レイアウトの改善 2013/05/09 v1.4 誤訳の修正。 v2.0.5 スタイルの修正(Notoフォントとシンタックスハイライト) 2018/10/8 2.6対応版

日経SYSTEMS - 遠隔KVMマイグレーション

Thu, 01 Mar 2012 00:00:00 +0000

今月の日経SYSTEM(3月号)でOSを動かしながら東京から大阪に遠隔KVMライブマイグレーションする検証記事を書きました。 http://ec.nikkeibp.co.jp/item/backno/OS0227.html 記事書いている時に1G NICを使ってるわりに遅くて、この調査に手こずってしまった。その時、QEMUのmigrate_set_speedついて調べたので補足。 QEMUにはマイグレーションの帯域を制御できそうなコマンド、migrate_set_speedが用意されている。これは、migration.cの static int64_t max_throttle = (32 << 20); で定義されていて、デフォルトで32MByte/secになっているのでこれを増やせば早くなるかな、と思いきやそういう訳でもなかった。という話も記事に書いたので気になる人は読んでみてね。この現代になんで32MByte/secがデフォルトなのか不思議に思ってたら、ML上のみんなも不思議がってた。 https://www.redhat.com/archives/libvir-list/2011-August/msg00168.html 詳しく調べてみるとこのmigrate_set_speedは仮想マシンの動作と密接に絡んでいて、ゲストOSが動作しているクロックの合間を縫ってマイグレーションの処理を行うという実装になっている。だから、デフォルトで正確に32MByte/secに制限されているというわけでもないし、増やした所で指定した通りの速度が出るわけではない。詳しくはbuffered_file.cのbuffered_rate_tick()あたりが参考になる。それよりも、移行先でのディスクのsync(2)がネックになってたのでこっちを工夫したほうが良い、という結論でした。

mod_diary - インストールして使ってみよう

Sat, 07 Jan 2012 00:00:00 +0000

最後の目標はこのmod_diaryを自分以外の誰かに使ってもらうことです。見た目はWordPressによく似ているので騙される人も居るのではないでしょうか。 mod_diaryをインストール手順は以下の通りです。 Apache HTTPD Serverはすでにインストールされているとします。以下の手順は、Apache HTTPD Serverを自分でビルドした人向けの手順です。ディストリビューション付属のものを利用している場合、APRのヘッダなどが分離されていると思うので注意して下さい。依存ライブラリのインストール mod_diaryはテンプレートライブラリClearSilverと、Markdown処理ライブラリDiscountを利用します。この2つをダウンロードしてコンパイルして下さい。 debianであれば、 # apt-get install clearsilver-dev libmarkdown2-dev でインストールできます。(libmarkdown2-devはwheezy以降) mod_diaryをcダウンロードします % git clone git://github.com/hamano/apache-mod-diary.git ビルドします % cd apache-mod-diary % ./autogen.sh % ./configure --with-apache=<APACHE_DIR> \ % --with-discount=<DISCOUNT_DIR> \ % --with-clearsilver=<CLEARSILVER_DIR> % make # make install 設定 httpd.conf に以下のように設定します LoadModule diary_module modules/mod_diary.so <Location /diary> SetHandler diary DiaryData /path/to/diary </Location> 記事データと、テーマファイルの配置 % rsync -av diary/ /path/to/diary/ この日記は書きかけです。気が向いた時に追記されるかもしれないし、されないかもしれません。

mod_diary - URLマッピングとデータ構造

Thu, 05 Jan 2012 00:00:00 +0000

mod_diaryの単純なデータ構造を紹介します。 mod_diaryを利用するには、apacheの設定ファイルhttpd.confに最低限以下の設定を追加します LoadModule diary_module modules/mod_diary.so <Location /diary> SetHandler diary DiaryURI http://www.example.com/diray/ DiaryData /path/to/diary </Location> このDiaryData以下に、記事データを配置します。記事は1エントリにつき1ファイルが対応し、Markdown形式で記述します。記事ファイルはgitなどのSCMで管理することを前提としているので、ローカルでもどこでも良いのでお気に入りのテキストエディタで書いてscpやrsyncでuploadしてくれ、という方針です。(サーバー上のファイルを直接編集する機能は気が向いたら実装するかもしれません) 例えば、 /path/to/diary/ 以下に 2012-01-01.md というファイルを配置すれば、 http://www.example.com/diary/2012-01-01 がエントリのURLとなります。一日に複数のエントリを書く人は、2012-01-01-1.md というファイルを配置すればよいし、URLに記事タイトルを入れたい場合、2012-01-01-hello_world.md というファイルを配置すれば、 http://www.example.com/diary/2012-01-01-hello_world というURLで参照できます。ちなみに、URLに.mdをつければ生のMarkdownファイルを表示できます。たとえばこのエントリは http://www.cuspy.org/diary/2012-01-05.md という様に表示されます。エントリに紐づいたファイルや画像を添付したいこともあるでしょう、その場合 /path/to/diary/2012-01-01/ といったディレクトリを作成し、画像やファイルを配置して記事ファイルから参照すればapacheのdefault handlerが直接serveします。ディレクトリを分ける必要は無いのですが、自分で自分の記事をgrepする際の効率を考慮しています。右端のサイドバーにある「Recent Entry」をどうするかという問題があります。これはDiaryData以下に配置したindex.hdfというファイルを参照しています。 index { 1 { uri = 2012-01-03 title = ブログシステムをつくった } 2 { uri = 2012-01-01 title = Hello world! } } これは、ClearSilverのHDFと呼ばれるデータフォーマットで詳細な仕様はこちらにあります。このファイルは別にjsonなどのフォーマットでも良かったのですが、既にテンプレートシステムとしてClearSilverを利用している、という状況があるのでHDFにしました。このHDFファイルを自動生成するコマンドがあれば良いのですが、今の所無いので手で書くしかありません。追記: 自動生成するコマンドdiary-mkindexをつくりました。 -u オプションでブログのBaseURIを指定しないとうまく動かないかもです。

mod_diary - ブログシステムをつくった

Tue, 03 Jan 2012 00:00:00 +0000

WordPressは素晴らしいブログシステムでした。プラグインをインストールして簡単に機能拡張したり、TeXだって書く事が出来た。でも様々なプラグインをインストールしていくうちに、WordPress本体のアップデートが困難になり、ブログの記事を書いている時間よりPHPのコードを読み書きする時間の方が多くなってしまった。今なら、外部のブログサービスを利用したり、他のブログシステムを構築する選択肢もあるけれど、コンテンツの永続性とデータフォーマットのポータビリティを考慮した結果、自分で作る事にした。 mod_diaryは以下の特徴を持っています apache moduleとして実装 markdown記法で記事を書ける emacsやvimなど、お気に入りのテキストエディタで書ける RDBを使用しない速くて軽い速いというのがどれ位速いかというと、同じサーバー(スペック低い)、同じ記事の内容に対してabでベンチマークを行った所。 wordpress: 2.1 req/sec mod_diary: 637 req/sec と、パフォーマンスに約300倍程度の差が出た。キャッシュシステムを実装すればまだ速くなる余地は残されてる。軽いというのは主にメモリ使用量がふわふわの軽さ、という意味です。 WordPressはMySQLを必要とする為、それだけで数百Mのメモリを使用してしまいます。それが原因で512MのさくらのVPSや、612MのEC2マイクロインスタンスで動作させるのが難しい状況がありました。 mod_diaryはapache moduleで実装されており、メモリを1Mも使用しません。さらにWorker MPMで動作するのでhttpd自体が省メモリになります。ゆえに、mod_diaryは低スペックなVPSやクラウド環境、組み込み機器でさえ動作させる事が十分可能です。本当の所、これは本日開催されたhackathonで何か正月っぽいモノを作れと言われて作ったネタですので、まだ多くの人に使ってもらえる様に出来ていませんが、一応本気でWordPressから移行するつもりでいます。未実装な機能: トップページそのうち作る検索機能 google検索にまかせるぜコメント機能コメントはtwitterなどで貰えばよいのでは無いかソースコードはこちら https://github.com/hamano/apache-mod-diary

Hello World!

Sun, 01 Jan 2012 00:00:00 +0000

This is your first post. write your diary!

第2回 Tuningathon チューニングメモ

Mon, 03 Oct 2011 00:00:00 +0000

ここから転載(このメモを書いた頃はgistをブログにしてた) https://gist.github.com/1259011 このメモは @hamano が第2回 Tuningathon に参加した際に行ったチューニングポイントと感想です。今回のお題は MediaWiki への参照性能という事でまたPHPか! とは思いましたが2台構成可、Web Serverの入れ替え可、という条件でしたのでチューニングの範囲が大きく広がった様に感じました。ただ、この程度の平行数ではapacheをその他実装に置き換えた所で大した差は出ないだろうと考え、ひとまずApache HTTPD Server 2.2.21 + PHP 5.4 + APCをビルドしました。 http_load もビルドして計測環境が整った所で最初に悩んだ事は、単一ページリクエストをabで行うと容易に 7-8 req/sec を越えるのに対し、http_loadではどうしても 1 req/sec以下になってしまい、何処もボトルネックになっていないという状況でした。原因はバトル条件に書かれていた http_load の –rate 1 による制限であることに気がつきましたが、皆にも同じように悩んでほしかったので黙っていました。(その後、計測条件は –parallel 4 に変更されました。) しかし、page.txt から生成したURLリストでランダムにアクセスしてみると、ひどいありさまです。2 req/sec程度しか出ません。原因はPHPの遅さにある事が解ったのでPHPを迂回する事の検討を始めました。 apache にはコンテンツをメモリ上にキャッシュする mod_mem_cache と、ファイルシステム上にキャッシュする mod_disk_cache というapache moduleがあります。mod_disk_cache ですべてのページは載らないにしてもある程度の高速化が見込めるのではないかというチューニングの一節として考えていました。 mod_disk_cache の設定は以下の通りです。 CacheDefaultExpire 86400 CacheMaxExpire 86400 CacheIgnoreCacheControl On CacheIgnoreNoLastMod On CacheEnable disk CacheRoot /var/www/cache ただし、この設定だけでは MediaWiki のレスポンスをキャッシュすることは出来ませんでした、CacheIgnoreCacheControl On を設定しているにもかかわらず、MediaWikiが付与する Cache-Control ヘッダが機能し、キャッシュ出来ません。この問題は、同じく apache module の mod_headers を利用して回避することが出来ました。

qemu-kvm の block migration を試してみたよ

Fri, 26 Mar 2010 00:00:00 +0000

KVM で livemigration を行う際、ストレージは両方のホストからアクセス出来る必要がある(NFS や iSCSI などで)ってここに書いてあった。 http://www.linux-kvm.org/page/Migration だから前回 iSCSIで試してみたのだけれど、なんと qemu-kvm 0.12 からブロックデバイスの migration が出来るようになったらしいので早速試してみた。 block migration するのは 10G の qcow イメージ、普通に debian をインストールして 844M 使用してある。 host1:~# qemu-img info vda.qcow image: vda.qcow file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 844M cluster_size: 4096 このディスクイメージでゲスト起動。 host1:~# qemu --enable-kvm -m 512 \ -drive file=vda.qcow,if=virtio,boot=on \ -net nic,macaddr=00:16:3E:00:FF:50,model=virtio 受け入れ側で同じサイズのqcowイメージを用意してある必要があるのかな、と思ったら、単に touch するだけで良かった。 host2:~# touch vda.qcow host2:~# qemu -enable-kvm -m 512 \ -drive file=vda.

qemu-kvm の live migration を試してみたよ

Sat, 20 Mar 2010 00:00:00 +0000

QEMU/KVM の仮想環境(ゲスト)を止めずに別のホストに移す。構成は以下ような感じ。ホスト環境 host1(192.168.1.11) で動作しているゲスト環境 guest(192.168.1.50)を別のホスト環境 host2(192.168.1.12) に live migration する。ホストOS は debian lenny ゲストOS も debian lenny ゲストOS は PXE boot して、ルートファイルシステムはkujira(192.168.1.10)のiSCSIターゲットをマウントする。 qemu-kvm のバージョンは 0.12.3 host1 のCPUは Intel Core2 Duo で host2 は AMD Opteron。この際、別ホストから guest へのTCPコネクションがどうなるか。と、guest 内で開きっぱなしのファイルがどうなるかを検証する。 rootfsの作成 iscsiターゲットのrootfsを作る。 debootstrapでお手軽サクサク。パーティション切るとloopbackマウントがめんどいので切らない。 kujira:~# dd if=/dev/zero of=disk1.img seek=10G bs=1 count=0 kujira:~# mkfs.ext3 disk1.img kujira:~# mkdir mnt kujira:~# mount -t ext3 -o loop disk1.img mnt/ kujira:~# debootstrap lenny mnt/ kujira:~# echo guest > mnt/etc/hostname kujira:~# umount mnt/ /etc/ietd.

MALLOC_MMAP_THRESHOLD_ と MALLOC_MMAP_MAX_

Mon, 22 Feb 2010 00:00:00 +0000

malloc(3)を呼んだ時、glibcはヒープ領域から指定したサイズのチャンクを確保するが、ヒープ領域が足りなかった場合glibcはbrk(2)を呼んでヒープ領域を拡張するか、Anonymous Memoryと呼ばれる領域をmmap(2)して新たなヒープ領域を確保する。この動作を制御する環境変数がMALLOC_MMAP_THRESHOLD_らしいのでこれを試しているのだけれど、効かなくて困った。しかたがないのでglibcのソースを読んでいるとmmap(2)を使用する最大サイズを指定するMALLOC_MMAP_MAX_というのも見つけた、これはばっちり効いたのでこれを使おう。 1M を 3回 malloc するだけのコード #include <stdio.h> #include <stdlib.h> int main(){ int i; for(i=0;i<3;i++){ malloc(1*1024*1024); } return 0; } % strace ./a.out (略) mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c9b000 mmap2(NULL, 2101248, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7a9a000 mmap2(NULL, 3149824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7799000 既定では3回mmap(2)してる。 MALLOC_MMAP_MAX_=0するとbrk(2)をだけを呼ぶようになった。 MALLOC_MMAP_MAX_=1にすると、 % strace env MALLOC_MMAP_MAX_=1 ./a.out (略) mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7cfe000 brk(0) = 0x94bc000 brk(0x95dd000) = 0x95dd000 brk(0x96dd000) = 0x96dd000 最初のmalloc(3)だけmmap(2)した。単位はMbyte なのね。(MALLOC_TRIM_THRESHOLD_の単位は byte だったのに…)

ARTiGO A1000 のハードウェア乱数生成器

Sun, 15 Mar 2009 00:00:00 +0000

ちょっと前に購入した、手のひらベアボーンARTiGO A1000がTRNG(ハードウェアの乱数生成器)を持ってたのでテスト。 # modprobe via-rng # ls -l /dev/hwrng crw-rw—- 1 root root 10, 183 2009-03-15 00:15 /dev/hwrng # head -c 16 /dev/hwrng | hexdump 0000000 e06d 5079 c2ae e9b5 8cc2 8781 fa6d 9497 0000010 乱数の生成速度と、品質を確かめてみる。フェアじゃないけど疑似乱数の /dev/urandom と、eToken Pro が持っている乱数生成機(これは TRNGらしい)と比べてみる。それぞれの乱数生成機で1M分の乱数を生成してみた。 /dev/urandom(PRNG) # dd if=/dev/urandom of=/dev/null bs=1024 count=1024 1024+0 records in 1024+0 records out 1048576 bytes (1.0 MB) copied, 1.60021 s, 655 kB/s /dev/hwrng(TRNG) # dd if=/dev/hwrng of=/dev/null bs=1024 count=1024 1024+0 records in 1024+0 records out 1048576 bytes (1.