No default VPC found でも大丈夫!?

AWSのVPCで、最初に172.~のCDIDでVPCがセットアップされている。
しかし、諸々の事情で192.168~でやりたいとか、10.0.~の方がしっくりくるとか人によって様々であろうと思う。

もちろんVPCを追加はできるのだが、使いもしないDefaultのVPCの設定が残っているのは気持ちが悪い。

というわけでDefault VPC配下のSubnetを削除した後、VPC自体をサクッと削除してしまい、自分で

VPC
Subnet
Internet Gateway
Route Table
Network ACLs

などをササッと自分好みに作っちゃって、さて、いざEC2でInstanceをLaunchしましょうか、という感じでWizardに入ると何やら警告が。
(なんか食べログのラーメン屋レビューみたいな文体になってきた・・・)

No default VPC found

という警告が上部に出ている。

気にせずいつも通り、進めると最後にLaunchするところでSecurity Groupの設定はOKだけど Initial Launch だか Initial Setting だかなんだかでエラーが。
Retryするかどうか聞かれるが何度やってもダメ。

結論から言うと、「ちょっと待つ もしくは ログインし直す」で解決。

Default VPCを削除し、自分のVPCを設定し、EC2 Instanceの設定時に自分のVPCとSubnetを設定しても
作成直後は上記のようなエラーが出続ける。
AWS側でVPCの設定が反映仕切っていないのかも。

大体設定後から10分~20分ぐらいすれば全く同じ設定でLaunchできるようになるので、AWSのSupportに連絡してください、とか書いているが
その必要はない(Default VPCを復活させたいなら別ですが)。
※ 私の場合は10分かそこらでログインし直したらできるようになったので、解決の理由が時間経過なのかログインによる設定再読み込みなのかは判断できず

Default VPCは消すな、という記事などを見かけたので、必ずしもそうではないよ、という記事。
※ ホントに消したらまずいこともあるかもしれないが、今は特に何もない

カテゴリー: AWS | コメントをどうぞ

SSL Pinningについて

アプリケーション内部にSSL証明書の検知手段を持つことを SSL Pinning(証明書のピン留め)というようだ。

『Gmail』公式アプリにセキュリティ上の弱点が見つかる。不正プロファイルで通信傍受の恐れ。
http://www.appbank.net/2014/07/16/iphone-news/857025.php

このニュースで議論が持ち上がったと思われる。

“そこで、通常は『証明書のピン留め』という機能をアプリに追加します。”

と言われているが、本当に”通常”の実装なのか、という疑問はある。
また、上記記事ではアプリの脆弱性のように言われているが、果たして『Gmail』アプリの脆弱性として扱うべきなのか。

というのも、2012年時点ではOSでなく、アプリケーション独自でのSSLの検証機構は
アプリケーションの範囲ではない、少なくとも脆弱性ではない、と主張されていた。
======================================================
○スマートフォンアプリケーションでSSLを使わないのは脆弱性か
http://blog.tokumaru.org/2012/02/is-smartphone-application-without-ssl.html

結論としては平文なら告知しなければ脆弱性、という見解。
ブラウザのように平文か暗号化通信かが鍵マークでわからないため、という理由
なので、平文なら基本的には脆弱性に繋がると見て良い、という結論(公開情報
であっても)。
また、SSL通信をユーザ自身や監査機構が傍受して読み取れるようにするのも
潔白の証明にもなる、という考え方。

○スマートフォンアプリのSSLとか
http://togetter.com/li/253510

SSLが防ぐのは通信経路の暗号化、第三者による傍受というところであり、
端末自体の改ざん(root化など)によるアプリケーションの通信内容の
解析/傍受は”アプリケーションの”脆弱性ではないとする。
そもそもSSLにその部分を防ぐ役割はない。
逆に通信内容をユーザ自身が確認しようと思えばできる、ということも
メリットであり、アプリ利用者の権利でないか。

○スマートフォンアプリのSSLとかの解説っぽいもの
http://togetter.com/li/253658

Googleの事例は認証局のクラックによるもの。
OSは信用しているみたいだが、アプリケーションでは信用しない状況は
かなり稀有な例で、そのために通信内容を過剰に秘匿するのは
ユーザの権利を損なっているという考え方。
======================================================

しかし、今は多少潮流が変わってきている気もする。

======================================================
○自社サーバと交信するスマホアプリにおけるサーバ証明書の発行手法について
(SSL Pinningと独自CA再考)
http://blog.kazuhooku.com/2014/07/ssl-pinningca.html

“情報漏洩の防止と利用者の同意に基づいた傍受の容易さを比較した場合、
前者を優先すべきなのは当然だと思うし、SSLにおけるpinningの実装手法に
おいて後者への配慮が望ましいとしても、それがpinningすべきでない
という理由にはならない”

======================================================

2012年時点、そして現在でも、それを希望するユーザに対してはアプリの通信内容を
検証できるようにする、というのは重要なことと思われる。
しかし、実際、CAのクラックだろうが、オペミスによる偽CAの発行であろうが
情報漏洩してしまっている事例があり、かつその可能性も今後もゼロではない以上、
上記の主張に対しては反論しづらいところがある。

Pinningを実装した場合、検証目的でユーザが追加した場合はそれを許可し、
それ以外の場合はAlertを上げて通信を行わないのが理想的な実装ではないだろうか。

ブログでは自社サーバとしか通信しないアプリについては、そもそも他社のCA自体も信用せず、
自社でCAを発行管理してしまえばいい、という案もある。

しかし、スマホアプリとウェブアプリで通信先サーバ(使用証明書)を変えているとか、
スマホアプリしかないならアリだと思うが、ウェブブラウザからの通信もあるなら
現実的ではないだろう。

“SSL Pinningについて、サーバ証明書とCA証明書のどちらをpinすべきかという
点については、前者は鍵の追加・廃止・更新が困難(heartbleedのような場合に
ユーザ側での対応が必要)という可用性の問題が、後者はCAによる誤発行のリス
クをゼロにできないという問題がある”

仕組みがわかっていないのがモロバレではあるが、これによると、CA証明書の方を
アプリ内に”ピン留め”しておけば、サーバ証明書の方を更新しても問題ない可能性がある。

“ピン留め”の問題点はサーバサイドの証明書の変更などによって同時にアプリ側の
アップデートも必要になることだと思っていた。
証明書が変更された際、アプリ側は更新を促すような作りにしなければならないし、
通常Alertと区別するための判別方法を用意しなければならない。
iOSは審査にかなり時間を要するし、Android側もアプリ審査についてはiOS側に
近づいているような気もするので今のような素早いアプリのアップデートは行えなく
なるかもしれない。
そうなると、証明書を先に更新してしまうとアプリリリースまで通信できなく
なってしまう。
アプリを先にリリースしておき、新旧両方の証明書でPinningしておいて、古い方は
有効期限が切れた時点で無効化する実装にしておく、という感じだろうか。

証明書が更新されているかどうかアプリ起動時にサーバに確認するというのは笑い話になると思う。

いずれにしろ、ここまで話が広がっていると、情報漏洩してしまってから、
“スマホの仕様のせいです”、”認証局がクラックされたせいです” という言い訳は、
使いづらい。

重要な情報をサーバと通信するアプリを作るときは、Pinningを要件として組み込むかどうか、
そのリスクを説明した上で事前に確認しておく必要があるということだろう。

現時点ではPinningしていなくても、自分の端末以外の利用者のデータを
傍受する方法は認証局クラックや偽証明書インストールぐらいしか可能性がない気もするので、
個人的にはこれから流行るかどうかわからないようなアプリにはオーバーな対策だと感じる。

偽証明書インストールは、リモートに限らず、「ちょっとスマホ貸して」などでも起こるかも
しれないが、root化は必要だと思うのでちょっと難しい。
冒頭のiPhoneなら構成プロファイルという形なので簡単そうだけど。

カテゴリー: 未分類 | コメントをどうぞ

[Memcached] session save handler に memcached を利用する

memcached をインストールして php.ini の設定をすれば良い。

memcachedのインストールはこんな感じ(CentOS 6)。
ついでにPECLもインストールしておく。


wget https://launchpad.net/libmemcached/1.0/1.0.18/+download/libmemcached-1.0.18.tar.gz
tar zxvf libmemcached-1.0.18.tar.gz
cd libmemcached-1.0.18
./configure
make
make install
/sbin/ldconfig
pecl install memcached

php.ini に 以下の設定をするだけ


session.save_handler = memcached
session.save_path = "remotehost:11211"

※ PECL Memcachedも使うなら extension=memcached.so も php.ini に追記

ロードバランサ配下だったりするとユーザーセッションの共通化で悩む。
NFSはやや大げさだし、AWSでは冗長化しにくいので使いづらい。
DBはたかがセッション程度でも負荷にしたくないし、ということでMemcachedを選択。

ちなみにMemcacheとMemcachedがある。
どちらが良いかなどはあまり調査していない。

設定時にちょっと詰まった。

Warning: session_start(): Write of lock failed
Warning: session_start(): Unable to clear session lock record

というエラーが出ていて、これは save_handler が memcached なのに session.save_path に tcp://~ の記述をしてしまっていたから。


session.save_handler = memcached
session.save_path = "tcp://remotehost:11211"

はNG。これは memcache のときの書き方らしい

カテゴリー: WordPress | コメントをどうぞ

[Solr] background merge hit exception

というエラーが出た。
ぐぐったところ

Solr – User – background merge hit exception – Lucene – Nabble

上記では質問者はファイルシステムのエラーを疑い、回答者は残り容量が少ないのが答えと言っている。

他のQ&Aサイトでも残り容量の話は出ていたが、容量は十分にある、という状況が多かった。

結論から言うと今回のケースはファイルシステムのエラーだった。
一度、エラーの出ているDiskをumoutして、

fdisk /dev/sdf

を行ったらエラーが検出されたので修復し、Optimizeを実行したところうまくいった。

EBSをfdiskでext3でフォーマットしたDiskなのだがどうにも調子が悪い。
それまではI/O性能重視でEphemeral Diskを使っていたのだが、こちらもセクタエラーが発生するようになってしまい、Stop -> Start で再生成した。
当然、Indexは消えてしまう。
500万件超のデータを再度Indexingするには相当な時間がかかるため、EBSに変更したのだ。

最初は一気にCommitしていたら、460万件ほどのところでCommitやOptimizeを行うと
Solrが落ちるようになった(selectは問題なし)。
ちなみにSolrのVersionは3.5.0

#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGBUS (0x7) at pc=0x00002aaaab26f3bb, pid=14777, tid=1102334272
#
# JRE version: 6.0_14-b08
# Java VM: Java HotSpot(TM) 64-Bit Server VM (14.0-b16 mixed mode linux-amd64 )
# Problematic frame:
# C [libc.so.6+0x7c3bb] memcpy+0x15b
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

上記のようなJava VMのエラーだが、

attempt to access beyond end of device

が/var/log/messages に吐き出されている。
要はDisk I/O多すぎ、ということらしい。

色々やってみたが治らないので一度Indexを削除し、40万件ぐらいずつCommit+Optimizeをやり直しているところで出たのが掲題のエラー。

また壊れるのではないか心配である。

カテゴリー: AWS, Solr | コメントをどうぞ

VMWareでhttpd(apache)にアクセスするために

VMWareにMySQL 5.6.11とPostgreSQL 9.2.4をインストールした後、PHP 5.3.4をインストール(全部ソースから)

ApacheはRPM版を利用しているので早速

/etc/init.d/httpd start

とやると、

error while loading shared libraries: libpq.so.5: failed to map segment from shared object: Permission denied

となる。

getenforceしてみるとenabledなので、速攻で無効にする。

vi /etc/sysconfig/selinux を編集する

そして再起動。

ところが・・・

kernel panic!!\(^o^)/

しかしそこはさすがのインターネット。下記のページを参考にブートローダを修正して直す。

SELinuxを無効にした後、Kernel panicになり起動できなくなった

上記の通りに対応したら起動しました。良かった~
と、思ったらどうやら誤情報らしい?

[指摘] 「SELinux無効化でカーネルパニック – CentOS6の備忘録」に対する指摘

なんとSELINUXではなく、SELINUXTYPEのところにdisabled設定してるから出てるエラーでしょ!とのこと。
そんな阿呆な・・・と思って再度 /etc/sysconfig/selinux を確認してみると・・・本当だ・・・
慣習的に一番下の行をdisabledにしていたような気がしたので項目を良く確認していなかった。

SELINUX=disabled <--- コメント行に埋もれている SELINUXTYPE=targeted <--- 最終行 上記のように直し、/etc/grub.conf の selinux=0 も消して再起動。 うん、大丈夫でした。 /etc/httpd/conf/httpd.confを適当に設定して /etc/init.d/httpd restart (自動起動しているため) 問題なく起動して、hostsに 192.168.79.111 example.chmonos.net (仮想マシンのIPとVirtualHostに設定したドメイン)を加える ブラウザから example.chmonos.net にアクセスしてindex.htmlが見える・・・と思ったらTimeout 何故見えない・・・ ふと思い立って iptables -L すると、やはりFirewallが有効になっていた。 これも速攻 iptables -F して /etc/init.d/iptables save Retryしたところ無事にindex.htmlが見えましたとさ

カテゴリー: 備忘録, Web, VMWare | コメントをどうぞ

VMWareのキーボード設定がおかしい

Windows7にVMWare Playerを言われるがまま入れ、CentOS 5.9のイメージISOからのインストール中に
何やら簡単インストールツール的なものを使おうよ、と促されるのでOKし、正常にインストールはできた。

NATでの外部接続と接続時の環境変数を確認しようと、curl “http://~~~” 的なコマンドでアクセスしようと
したところ、「”」が「@」になってしまう。

Google先生で「VMWare keyboard 日本語」などで検索するとおなじような例があって、キーボード設定が
USになっているのが原因の様子。

こちらを参考に直せば良いのです。
CentOSでキーボード設定が日本語じゃないときの対処法

ということで変えようと思い、Runlevelが5で立ち上がっているので terminal を起動して早速

vi /etc/sysconfig/keyboard

KEYBOARDTYPE=”pc”
KEYTABLE=”us”

KEYBOARDTYPE=”pc”
KEYTABLE=”jp106″

に変更~とするわけですが、「:」が効かないので「:wq」が打てない!!

あわてるなかれ Shift+q (Q) で EX Modeに入り、そこで wq と打てば保存して抜けられます。

続いて以下を変更(恐らくこちらが本命です。VMWare上からのキー情報に関与していると予想)

vi /etc/X11/xorg.conf

Option “XkbModel” “pc105”
Option “XkbLayout” “us”

Option “XkbModel” “jp106”
Option “XkbLayout” “jp”

変更した後、スマートにコマンドで設定を反映したいところですが探すのが面倒で、再ログインなどでは反映しないようなので
思い切って再起動しました。

これでばっちり反映です。

ちなみに teraterm などを利用し ifconfig で調べたIPにアクセスしてviを操作すると、前述のファイルの変更前でも
普通にviが使えました。

カテゴリー: 備忘録, Web, VMWare | コメントをどうぞ

あとで書こうと思っているネタメモ

2012年9月から書いていないのがすごい。
2013/4/19 Update

・AWSとNFS周りの設定の落とし穴(名前引き)
+VIP利用できない(keepalived利用不可)
+NFSをDNSラウンドロビンで運用して、DNSレコードを変更する方式ではうまくいかない
・AutoScalingの設定方法
・SolrのCJKTokenizerでSynonym設定
・辞書更新
・Solrのレプリケーションがすごく簡単
・Solr(Java)のメモリ設定(Stop the world)
・git
・VMWare入れてみた

カテゴリー: WordPress | コメントをどうぞ

Solr 辞書とシノニム

Solrのシノニム(同義語)展開は少々癖がある。

シノニム検索は例えば 「めぞん一刻」 という書籍情報があり、ユーザーが間違って「めぞんいっこく」や「メゾン一国」など入力したときにも「めぞん一刻」で検索した結果を得るというものだ。

conf/synonyms.txtに以下のように記述すると期待した結果が得られるはずだ。

めぞん一刻,めぞんいっこく,メゾン一国

ところが、辞書をチューニングしていないと「めぞんいっこく」で検索しても想定通りの結果は得られない。
理由としては「めぞんいっこく」が名詞として辞書に登録されていないと

め ぞ ん いっ こく

と5単語に形態素解析されてしまう。
そのため、synonymの条件にHITしない。

lucene-gosenが利用する辞書に「めぞんいっこく」を単語登録しなければ、「めぞん一刻」「メゾン一国」には展開してくれない。

さて、次にこのようなパターンに備えて

めぞん,メゾン
いっこく,イッコク,一刻,一国

という風に変化しやすい部分を切って展開してみる。
このようにした方が組み合わせで対応できるので効率的である。
だが、この場合は正しく1単語として認識されない文字を一つずつ辞書に登録しなければならない。
「めぞん」は め ぞ ん になってしまうし、「いっこく」は いっ こく であるから、それぞれ辞書に登録しないと他の単語には展開されない。

ここまでは変換ミスなどを想定したカバー方法で、次は勘違いレベルの場合だ。
かなり極端な例だが、どこでどう間違ったか
「デジョン一刻」
と検索されるケースが非常に多いとする。

この場合も取りうるケースとしては2パターンで

めぞん一刻,めぞんいっこく,メゾン一国,デジョン一刻

として、辞書にも「デジョン一刻」で1単語登録する。
もう1パターンは

めぞん,メゾン,デジョン
いっこく,イッコク,一刻,一国

で「デジョン」で1単語登録(naist-chasenでは デ ジョン で解析された)。
※ ちなみに片仮名->平仮名の正規化フィルタを実装している場合は全て平仮名でsynonyms.txtを統一すればよく、いちいち対応する必要はないので楽。

上記2パターンでの検索結果の違いだが、「めぞん一刻」1単語の検索では、INDEX内に展開先の「めぞん一刻」「めぞんいっこく」「メゾン一国」のいずれかがなければ検索結果に出ない。
対して「めぞん」「一刻」の2分割パターンでは、INDEX内に「めぞん」の展開先と「一刻」の展開先が両方存在すれば検索にかかる。
検索としては後者の方が有効な場面が多いと思う。

しかし、この例だと「めぞん」で検索したときも他の「デジョン」を含む結果が返ってしまう。

勘違いの特殊ケースは一方通行展開にして切り分ける。
ただし注意がある。

めぞん,メゾン
いっこく,イッコク,一刻,一国
デジョン一刻=>めぞん一刻

このように設定した場合、「デジョン一刻」で「めぞん一刻」はかからない。
何故なら、シノニム展開後のキーワードはTokenizeされないため、「めぞん一刻」という1単語での検索になる。
上記例でのIndexing時に働くシノニムでは「めぞん一刻」は「めぞん」「一刻」に分割されているはずなので、1単語での検索はHITしなくなってしまうというわけだ。
では「めぞん一刻」を辞書登録しておこうではないか、ということになるが、安易に辞書登録してしまうと、今度はIndexing時に「めぞん一刻」1単語でTokenizerが認識するため、せっかく分割した「めぞん」「一刻」の2単語はシノニム展開されなくなってしまうのだ。

そこで、苦肉の策だが

デジョン一刻=>デジョン,めぞん,一刻

と、query側を展開してやると、3単語検索になって、もともと本来の意味で「デジョン」を持つコンテンツもHITするし、「めぞん一刻」もHITするようになる。

ちなみにsynonym filterにつかうsynonyms.txtはこのような例のときのために、queryとindexで分けた方が良いと思われる。

fieldtypeの設定時にanalyzerをtype=”index”とtype=”query”で分け、
それぞれ

Query側
<filter class=”solr.SynonymFilterFactory” synonyms=”synonyms_query.txt” ignoreCase=”true” expand=”true”/>

Index側
<filter class=”solr.SynonymFilterFactory” synonyms=”synonyms_index.txt” ignoreCase=”true” expand=”true”/>

とすることが可能。

カテゴリー: Solr | コメントをどうぞ

phpMyAdminのインポートファイルサイズ制限

phpMyAdmin経由でdumpファイルをインポートする場合、デフォルトの4MBだと足りないケースがある。
その場合は php.ini の

; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize
upload_max_filesize = 4M

の部分を

upload_max_filesize = 16M

とする。

しかし、再度インポート画面を見ると「可能なMAXサイズは8,096KiB」とか書いてある。
これはおそらくPostデータの制限を見ているためだ。

; Maximum size of POST data that PHP will accept.
; http://php.net/post-max-size
post_max_size = 8M

この部分を

post_max_size = 16M

こうすると良い。

写真をアップロードするWebフォームなんかを作る場合、デジカメの写真をそのまま上げようとするユーザーに配慮すると4MBでは少ない気もするのでご注意。

カテゴリー: PHP | コメントをどうぞ

mod_rewrite で書き換えたURLにクエリーを引き継がない方法

書き換え後のURLの末尾に ? を付けるだけ。

RewriteCond %{REQUEST_URL} id=9999
RewriteRule ^/$ /NewURL/%1.html? [R=301,L]

mod_rewriteでのクエリの扱い | Muses Factory

ただ、以下のように書くとNGであった。

RewriteCond %{REQUEST_URL} id=9999
RewriteRule ^/$ /NewURL/%1? [R=301,L]

こう書くと

http://chmonos.net/9999?id=9999

となってURLが引き継がれてしまっている。

RewriteCond %{REQUEST_URL} id=9999
RewriteRule ^/$ /NewURL/%1/? [R=301,L]

とすると上手く書き換えられる。
後方参照の%1と?を分離して書く方法があればいけそうだが・・・

ちなみに %{1} はNGだった。

カテゴリー: WordPress | コメントをどうぞ