SSL化してから、しばらくはちゃんとオレオレGyazoも動いていたのだけど、いつの間にか動かなくなっていた。これは困る。
普段ブログの画像とかも元ネタはGyazoで撮ってた部分が大半で、それ以外にもグラブルで面白いことが起きたときとかはササッと撮影してSkypeのコミュニティに垂れ流したりしていた。
これができないのはなかなかつらい。
これは原則としては覚書である。よってほぼ文字しかない。
また、同じような問題にハマってしまった人が参考にするのは構わないが、あくまで記事の内容を読んで理解できる人に向ける。ビルドの仕方わかりませんって言われても困りますし。
エラーの内容を確認
オレオレGyazoとして使っているのはGyazo+というもの。こいつが吐くエラーはいくつかあるのだけど、今回出ているエラーはコレ。
「アップロードに失敗しましたよ。結果コードは拾えなかった。メンテ中?」
とのことである。このエラーの場合はサーバまで接続はできているはずなので、ログを探す。
エックスサーバーの場合、サーバーパネルのエラーログのところからダウンロードできた。毎日AM3:00にリセットされるそうなので、時間がかかりそうなエラーや再現が難しいエラーに出会ったときには予めダウンロードしておいたほうがいいということ。
とまれ、ダウンロードしたログを確認。
AH01215: upload.cgi:13:in `<main>': undefined method `read' for nil:NilClass (NoMethodError)
End of script output before headers: upload.cgi
タイムスタンプやIPの情報は割愛するけれど、こんな感じ。
正直、なんじゃこれって。
この「nul:NilClass」ってのは、要するにぬるぽに近い雰囲気を感じた。
rubyをきちんと学んだことがないので、間違っているかもしれないけれど、ようするに、あると思っているメソッドが、何らかの事情によってなかったということかな?くだんのこーどは以下である。
id = cgi.params['id'][0].read
パラメータ id の 0 番から”read”しようとしてここでエラー。
これ以上追いかけられなかったのだけど、多分アップロードしたはずの画像のstreamがhttpとhttpsの間の闇に飲まれてしまったのだろうと勝手に思った。
勝手にね!ほんとは違う理由かもしれない。でも、大事なことはオレオレGyazoが復活すること。
とまぁこんな理由だと思ったので、クライアント側の設定を見直してみる。
昔懐かしのiniファイルに入ってる。gyazowin+.ini
SSLに絡むところは以下2つ。
use_ssl=no
ssl_check_cert=no
この2つを求める形に変えてあげれば良さそう。
SSLを使うのだから「use_ssl=yes」チェックは別にいらないから「ssl_check_cert=no」のままでOK。
結論から行くと、この設定を変更してもエラーとなった。
しかもエラーが変わり、サーバへの接続すら失敗してしまった。
サーバ設定の見直し
このエラーが出だしたのは、SSLの設定にしてしばらく経ってから発動しだした。また、DNSが出回りきっていないことも関係するのかもしれない。
一応.htaccessで、http→httpsへ301リダイレクトはしていて、どっちでアクセスしてもhttps、つまりSSLで通信されているはず。もちろんパーミッションも確認済みで、エックスサーバーのマニュアルに記載されている通り、755にしている。というか、SSL化する前には普通に動いていたので、よく考えたらパーミッションとかあまり関係なかったという。
そこで疑ったのがそもそものGyazowin.exe。
ただ、use_ssl=yesに変えたら繋がらなくなるってことは、iniファイル自体は読み込んでいて、かつ内部でなんらかの処理が変わっていると推測できる。
今使っているGyazoがGyazo+なのは間違いないけれど、iniファイルだけSSL対応版の可能性があった。
ビルドは自分でしたので、その時のソースを確認するしかなさそうということ。
Gyazoのバージョン違いの可能性
実はオレオレGyazoには結構歴史があって、初代GyazoからGyazo+になって、さらにGyazo+のソースをマージした版があって、今はもう一つGyazoPlusという版ができている。
出張先でPCを調達したので、PCを新しくした際に前のPCからソースコードとかを救出していないので、このGyazoをビルドしたソースが無い。
最新版と思われるソースからビルド
幸いにもGyazoのソースはGitHubで公開されているので、そこからクローンする。
古いVisual Studioで作られているソリューションなので、現環境で.slnを開くと勝手にコンバートしてくれる。昔からあるけど便利な機能である。
そしてそのままバッサリとビルド。
エラーが出る。
しかも訳のわからない部分で出る。
具体的には、stdafx.hの44行目とかで出た。
#ifndef~#endifの数が合ってないらしい。
そんな馬鹿なことはない。GitHubに入れてて3年も前にコミットされているソリューションがコンパイルエラーとか無いわ。
よく見たら警告も出ている。
warning C4819: ファイルは、現在のコード ページ (932) で表示できない文字を含んでいます。データの損失を防ぐために、ファイルを Unicode 形式で保存してください。
少し調べたらスグわかった。以下のサイトが詳しい。
Visual C++ 2010で生じる、warning C4819を退治する
簡単に言うと、utf-8(BOM)としてソースを保存し直す。これだけのこと。
無事にビルドできたので、iniファイルを弄る。
[GyazoPlus]
upload_server=アップロード先のサーバー
upload_port=443
upload_path=<upload.cgi>がおいてあるパス hoge/upload.cgi とか
upload_id=
use_ssl=true
ssl_check_cert=false
use_auth=false
auth_id=
auth_pw=
up_dialog=false
copy_url=true
copy_dialog=false
open_browser=true
Gyazo+.iniと比べると少々仕様は変わっているのでそのあたりだけ注意。yes/noからtrue/falseになってるのと、ポート指定できるようになってる。
今回は動作先がSSLなので、ポートはSSL標準の443を指定する。
次いで、Gyazo+ではエラーにつながっていたuse_sslをtrueに。
合わせてssl_check_certをfalseに。そこから下はまぁお好みで。
まとめ
今回は、Gyazoの詳細を覚えていなかった、かつソースコードが手元になかった点でかなり手間取ってしまったけれど、手元にソースがアレばどこでエラーになっていたかもっと早く原因を見つけられたと思われる。
GitHubの公開リポジトリに助けてもらった感がすごい。
先日、GitHubのプライベートリポジトリも無料で使えるようになったし、エンジニアの端くれとしてはそろそろGitHubも使えるようになっておいたほうがいいなって思った。
自分の過去のソースが欲しい場面って結構あるよね!
とまれ、これでスクリーンショット撮り放題だヒャッホーイ!