hidekiy blog

DHCP が有効になっている Raspberry Pi は、とりあえずイーサーネットケーブルで繋げば動き始めるという素晴らしい利点がありますが、ディスプレイを繋がないと IP アドレスが分からないのはリモートから操作する際に大変不便です。そこで、マルチキャスト DNS (や類似する NBT: NetBIOS over TCP/IP の名前解決) を使えばこの状況を著しく改善でき、アドレスをどこにもハードコードすることなく名前で機器を管理できるようになりとても良いと思います。 例えば Raspberry Pi のホスト名が raspberrypi のとき、Raspbian を使っているなら、sudo apt-get install avahi-daemon するだけで自動的に avahi-daemon が動き始め、他の初期設定は全く無しで Mac や Linux (名前解決で mDNS クライアント機能が有効)、Windows (Bonjour 導入済み) から、raspberrypi.local を名前解決できるようになります。 また、sudo apt-get install samba すれば、自動的に nmbd が動き始め、Windows から raspberrypi で名前解決できるようになります。 注意点として、同一ネットワークの全ての機器に対する名前解決の問い合わせが OS のセキュリティ保護機構によりブロックされないよう、ネットワーク種別はプライベートネットワークなどに設定する必要があります。 動作例 Microsoft Windows [Version 6.3.9600] (c) 2013 Microsoft Corporation. All rights reserved. C:\Users\Hideki>ping raspberrypi.local raspberrypi.local [192.168.0.3]に ping を送信しています 32 バイトのデータ: 192.168.0.3 からの応答: バイト数 =32 時間 =2ms TTL=64 192.168.0.3 からの応答: バイト数 =32 時間 =2ms TTL=64 192.168.0.3 からの応答: バイト数 =32 時間 =1ms TTL=64

Windows で chef 11.6.2 をインストールしようとするとエラーが出る件について、mixlib-shellout 1.2.0 のリリースで chef の側の依存関係が時代に取り残されたように思います。以下のような依存関係解決失敗を表すエラーが出ます。 C:\Users\Hideki>gem install chef ERROR: While executing gem ... (Gem::DependencyError) Unable to resolve dependencies: chef requires windows-pr (= 1.2.1), win32-process (= 0.6.5); win32-service requires windows-pr (>= 1.0.8); win32-dir requires windows-pr (>= 1.0.9); mixlib-shellout requires win32-process (~> 0.7.0), wind ows-pr (~> 1.2.2) chef 11.8.0.rc0 の chef-x86-mingw32.gemspec を読んでみると問題の根幹になっていた mixlib-shellout の依存関係が更新されて直っているようなので、2013/10/20 時点で未リリースですがこれを以下の手順でインストールしてみました。上手く動いている気がします。 git clone https://github.com/opscode/chef.git git checkout 11.8.0.rc.0 gem build chef-x86-mingw32.gemspec gem install chef-11.8.0.rc.0-x86-mingw32.gem 2013/11/16 追記 2013/10/31 に chef 11.8.0 がリリースされて解決済みです。

knife-solo はリモート側へのレシピ転送に rsync を使っています。この肝となる rsync を Windows でどう用意するかが鍵ですが、現状選択肢は2つあって、 Cygwin の rsync と MSYS の rsync です。 MSYS 版と比べて Cygwin 版の rsync は特にディレクトリエントリの取得の辺りが特に遅いように感じます。よって MSYS の rsync を使いたいところですが、knife-solo は Windows では /cygdrive/c/... というパスに 変換して渡してくれる 親切な仕組みがあるので、デフォルトのままの msys-rsync だと上手くいきません。 本来は knife-solo の側が気を利かせるべきかもしれませんが、とりあえず急場をしのぐ方法として、MSYS の fstab (C:\MinGW\msys\1.0\etc\fstab) に対して /cygdrive/c に C:\ をマウントする設定を入れてしまうか、mklink で NTFS 上にシンボリックリンクを張ると良いみたいです。リンクを張る場合は、C:\MinGW\msys\1.0\cygdrive\c => C:\ とすればよいです。

ソフトバンクから大量に配られた FON2405E (Fonera SIMPL) ファームウエアバージョン 4.0.1.7 では、MyPlace 用の鍵について、なぜかプリシェアードキー (PSK; Pre Shared Key; 事前共有鍵) 文字列指定の場合は56文字までは問題なく利用可能で、それ以上設定した場合は先頭から56文字が黙って使われる奇怪な仕様のようです。 WPA / WPA2 の仕様上はプリシェアードキーを ASCII で指定する場合、8文字～63文字の中で任意の長さの文字列が使用可能なので、Fonera の側に問題があるように思います。

Windows 8.1 でネットワーク設定をプライベート (同一ネットワークの機器を信頼する設定) にする方法はモダン UI の PC 設定 > ネットワーク で、「デバイスとコンテンツの検索」オプションを有効に設定します。 このオプションが見当たらない方は、ユーザー種別が管理権限を持たない標準ユーザーであるか、ユーザーアカウント制御 (UAC) 設定が「常に通知する」の設定になっている可能性があります。この何れかに当てはまると「デバイスとコンテンツの検索」オプションが表示されなくなるようです。 参考画像 モダン UI はセキュリティ強化により UAC プロンプトを経由した管理者権限の取得が出来ないことは了承できますが、理由を説明することなく設定項目を隠すのは良くないと思います。PC のリフレッシュと再インストール機能も UAC が最高レベルになっていると同じ理由で使用できなくなりますが、こちらは「ユーザー アカウント制御がシステムの変更について常に通知する設定になっているため、この機能は使えません」という注意書きが出ます。 公式情報 共有を有効または無効にする - Microsoft Windows ヘルプ 関連情報 このネットワーク設定は PowerShell からも設定可能で、こちらを使うと設定項目が消滅してしまったネットワーク名の変更も可能です。 Microsoft TechNet - Set-NetConnectionProfile Newsletter #106:Solving the "How Do I Change My Firewall Profile in Windows 8?" Puzzle

最近のお勧めは express-joi です。 express-validator の都合の悪いところ：全入力値が文字列であることが前提になっているので、undefined と空文字列を区別して扱うことができない。具体的には、明示的な空文字列の指定と、指定し忘れを区別して処理したい場合など。 express-joi という別の Express 用バリデーションライブラリは、上記の欠点は無く問題なく使えます。具体的には emptyOk() と required() を駆使すれば良いです。ライブラリのバージョンは低いけれど単なるラッパーのようなので気にしなくて良いと思う。 joi は事前に用意したスキーマに適合するかによって入力値が valid かどうかを検証する仕組み。スキーマ定義がおかしいときその時点でエラーになるので、実際のバリデーションが行われるより早い段階でエラーとなるところも気に入っています。 2013/10/2 追記 現在のバージョン 0.2.4 に入っている URL エンコードのデコード処理は Express で既にデコード済みのものを二重にデコードしようとしているせいで、"% " などの入力文字列でエラーになるようです。joiを直接使うのもそんなに難しくないと思ったので直接使っています。

Underscore.js の _.sortBy を使ってオブジェクトのリストを日付 (Date オブジェクト) の入ったプロパティ updatedAt の降順でソートするには、以下のようにすれば良いです。 var sortedList = _.sortBy(list, function (item) { return -Number(item.updatedAt); });

PremierColor テクノロジー搭載デル デジタルハイエンドシリーズ U3014 30インチワイドモニタ で、YouTube の動画を見ていると最初は問題ないものの、再生開始から数秒後画面全体がチラついた後、動画の枠と少しずれた位置に青紫色の透明の長方形が表示されるという、いまいちな挙動が起こりました。 はたしてどのレイヤーで問題が起こっているのか最初良く分からなかったのですが、ディスプレイ自体の設定で Smart Video Enhance 機能を Off にすると解決しました。 参考 製品マニュアル: Dell U3014 Monitor

オプション -u, -g を接頭辞 # を付けて使うと passwd に存在しない任意の UID, GID を設定してコマンドを実行できますが、なぜかデフォルトでは -g が上手く動きません。 $ sudo -u#123 id uid=123 gid=0(root) groups=0(root) $ sudo -u#123 -g#456 id Sorry, user USERNAME is not allowed to execute '/usr/bin/id' as #123:#456 on SOMEHOST. /etc/sudoers の許可エントリを以下のように任意の GID を指定できるように少し直す必要があります。 $ sudo visudo # admin ALL=(ALL) ALL admin ALL=(ALL:ALL) ALL この設定を行うと上手く動きます。 $ sudo -u#123 -g#456 id uid=123 gid=456 groups=456 参考 man sudoers

Google 検索でクロネコヤマトの荷物問い合わせを行う機能では、クロネコヤマトと FedEx をチェックサムの計算方法が違うことからほぼ区別できるようです。しかしたまに衝突し、ヤマトなのに FedEx と認識されたりします。 その場合は「ヤマト 111122223333」と明示すると上手く調べることができるようです。 参考 ヤマト運輸のチェックデジットの算出方法 - Yahoo!知恵袋 java - Fedex checksum algorithm for tracking numbers? - Stack Overflow

NFS サーバーは設定ファイル /etc/exports に記述した順ではなく、このファイルが読み込まれた後、内部でソートされた後の順序でリクエストを処理するようです。ソート後の状況は、 $ exportfs -v で確認できます。 このソートの具体的な動作は、対象マシンのスコープの小さい順 (man exports の Machine Name Formats の順: single host, netgroups, wildcards, IP networks)、それで同順ならパスの深い順となっているように見えます。

pLaTex を使って日本語・英語論文を書くときに、紙面を突き破る overfull ではなく、文字間を広げて誤魔化す underfull にして穏便に済ませるには TeX に対して以下のパラメータを設定します。 ハイフネーション (ハイフンで区切って次行に送る) を使わないで undefull を強制するには、 \pretolerance=10000 \emergencystretch=.9\hsize ハイフネーションを許可するなら tolerance を緩和し pretolerance を設定せずデフォルト値を使ってみては？ \tolerance=10000 \emergencystretch=.9\hsize もしくは tolerance に加えて hfuzz, vfuzz を緩和することも追加する動作をする sloppy で良いようです。 \sloppy \emergencystretch=.9\hsize 行送り処理は三段階あって、ハイフネーションを許可しない pretolerance、ハイフネーションを許可する tolerance、文字間を広げて誤魔化す emergencystretch です。前二段階は試行錯誤の結果 Badness を設定した閾値以下に収めることができたときは成功とし残りの処理を行いません。 コンパイル時の警告の内、Badness が大きいものは個別に対処したほうがよいかもしれません。 参考 TeX/pretolerance GNU Texinfo 5.1: Overfull hboxes TeX Frequently Asked Questions -- question label "overfull"

潔癖な方は外出先でちょっとだけ使った Wi-Fi プロファイルなどもう二度と使うことのないことがはっきりしている Wi-Fi プロファイルを削除したいと考えると思います。 しかし Windows 8 の標準の Wi-Fi 接続インターフェースでは通信エリア外のアクセスポイントの設定は表に現れず削除する方法がなくなってしまい大変困りました。仕方なくヘルプを検索すると、 ワイヤレス ネットワーク プロファイルを管理する を発見し、コマンドラインインターフェースを使えという説明を得て無事削除できました。 ネットワークの新機能 を読むと接続プロファイルの優先度設定を抜本的に改善して操作用の GUI すら要らない状態まで持って行けたという感じに読めますが、ちゃんと消せるようになってた方が心の平穏を保てると思います。 他にもヘルプで言及されていない注意点があり、PC 設定の同期をオンにした状態で Wi-Fi プロファイルを削除しても、同期機能がそそくさと復活させてくれるので、あらかじめ同期機能全体もしくはパスワードの同期機能を切る必要があるようです。この動作 (エントリの削除を紛失と同じものとして処理する) はバグっぽいので今後のアップデートに期待します。

Windows 8 の新機能である PC 設定の同期機能でサーバー側に保存されたデータを削除する方法は、こちらの少し面白いタイトルの公式情報ページで案内されています。 PC 間で設定を同期する必要があるかどうか - Microsoft Windows 少し下の方の [すべての設定の同期を停止するには] を押して出てくる文書の一番下にある 個人設定をクラウドから削除します をクリックすると、SkyDrive のそれっぽいページに遷移します。設定データが存在している Microsoft ID でログインして削除を行ってください。 削除の確認ページで注意されているとおり、この削除機能はサーバー側で恒久的に同期機能を停止する機能ではないので、情報の再アップロードを防ぐには全てのPCの設定の同期設定を無効にする必要があります。

あるユーザーが事前に設定したパスワードを入力したこと確認するための情報を安全に保管するには、保管する際に 一方向性関数 を通せばよいことは誰もがご存知だと思います。この一方向性関数をより強力 (より計算時間がかかる) なものに更新しようとする際、ユーザーからの生のパスワードが必要なのかについて議論します。ソルトの有効性については議論しません。 いまもしイテレーション回数を増やすことができるならば、パスワード用ハッシュ関数のストレッチ度を上げることでパスワードハッシュ値へのオフライン攻撃を企む攻撃者に必要となる計算能力を世の中の進歩に合わせて増やしていくことができるので、安心してユーザーのパスワードを預かることができそうです。 例えば素朴なところで f(x) = sha256(sha256(sha256(x))) (ただし x をユーザーが入力した生のパスワードとする) のように sha256 関数に n 回通すような関数を用いているとします。この関数はユーザーからの生のパスワードを得ずとも、既に n 回通したハッシュ値にさらに m 回 sha256 に通してイテレーション回数 n + m のより強固なハッシュ値にアップグレードできるので、イテレーション回数は好きなだけ更新可能と言えます。 次に既にパラメータにイテレーション回数を持っているような鍵導出関数 PBKDF2 を使う場合でも、f(x) = PBKDF2(PBKDF2(x, salt, 100), salt, 10000) のような一方向性関数を考えれば先ほどと同様に、イテレーション回数 100 から、10100 ほどにハッシュ値の強度を強化できると言えます。 残念なことに PBKDF2(PBKDF2(x, salt, 100), salt, 10000) = PBKDF2(x, salt, 10100) みたいにはならないようですが、どの一方向性関数を通したハッシュ値なのかという情報は保持するべきで (例えば $1$saltsalt$hashhashhashhashhash の形式の 1 はハッシュ関数の種類)、保持すれば関数の使い分けに問題は無いでしょう。 またもしユーザーから入力されたパスワードを既知とするならば、ユーザー認証後に好きな一方向性関数でハッシュ値を導出しなおすことが