2016年10月13日木曜日

お菓子作りの原価

先日、サツマイモが1本100円と安かったので2本買って、スイートポテトを作ることにした。
自宅に余っていたレーズンをラム酒につけて入れたら美味いのが出来るんじゃないか、と思った。

果たして、それはなかなかの味わいで、1本の芋、つまり100円で大振りの8個のスイートポテトが出来たわけだが、なかなかコスパがよいな、なんて思っていた。

ところが、材料のうち、家になかった生クリームを少しだけ使って冷蔵庫に入れたまま数日忘れていたことに気付いた。


生クリームはわりと高い。200~300円くらいか。これをほぼ余らして捨てたら、スイートポテトの名目上のコストが一気に高騰してしまう。そうでなくても実際はバターや砂糖ももちろん使っているのだし。

なので、先ほど、夜だというのに思い立って、今度はずいぶん昔に何かで使って余っていた黒糖と、残り一本の芋でまたスイートポテトを作った。

黒糖バージョンもなかなか美味そうである。生クリームも半分以上は使ったし、あと残りは冷凍でもして今度料理にでもぶち込もう。


ただ、せっかくこうして節約した気になっても、材料として使った卵黄2個のために必然的に余った卵白2個。これを流しに捨てるのが忍びない。

以前はメレンゲにして焼いたり、小麦粉や砂糖やバターなんかと適当に何か作ってみたりしたが、そもそも卵白がもったいないからという理由で何か作るのに多くの材料を費やしては意味がない。しかも、さほど食いたいメニューでもないものを作って。


そこで、マーガリン(箱に「料理にも!」とあったので加熱OKのタイプなのだろう)と粉チーズ、胡椒、醤油で白身焼き料理を作ってつまみにしてみた。

スクランブルのようなものなのだが、見た感じ、大型の鳥の糞みたいなので鶏糞焼きとでも称しようか。

しかしこれが、非常にしつこかった。

バターを使う焼き料理は常に倍量くらいのバター好きだし、マーガリンもパンにはどっちゃり塗る派なのだが・・・これはやけにしつこくて胃がもたれた。


味はしょっぱくてツマミっぽいです。もたれるので皆さんも是非お試しください。



  *   *   *


けいふん焼き レシピ

材料

  • 卵白2個分
  • 粉チーズ適宜
  • 醤油数滴
  • ブラックペッパー
  • マーガリン大匙1強(パン1枚に塗るに塗るには多すぎるな!というくらいの量)
作り方
  1. フライパンを熱します
  2. マーガリンを入れます
  3. 溶けたら、卵白を入れます
  4. 適当に固まりかけたらちょっと崩してひっくり返します
  5. だいたい焼けたら火をとめ、粉チーズと醤油とブラックペッパーをかけます
  6. 更にのせて、フォークで上品にいただきます
  7. 胃がもたれます
おすすめしません。


2016年9月28日水曜日

「言ってくれなきゃわからないよ」というアレ

しばらく前にAmazon Primeに登録していて見放題ということもあり、最近よくアニメを見ていた。ドラえもんや北斗の拳も見られるが、そうではなくてわりと最近の深夜アニメっぽいもの。

そういう中でいくつかの作品にそれぞれ異なったシチュエーションで出てきたように思うのが、「言ってくれなきゃわからないよ」という話。

それを言うのはただの高校生であったり、魔法や超常の力を振るう戦士であったりするが、共通するのは美少女であることだ。とは言え、深夜アニメの登場人物の9割は美少女なので、それは特別なことではない。

つまり、近年の物語に頻出する人間関係の問題が、お互いがお互いのためを思って、悩み、行動しているのに、お互いの意図が伝わらないためにお互いが傷つけ合い、すれ違ってしまうという現象ならしい、というように感じたというのが俺が今、言いたいことだ。

それは人類の歴史と同じくらいの年季が入った問題なのだろうと思う。が、とくに最近は顕著に問題になっているのだろうか。それでよくテーマになるということなのだろうか。

しかし、そう考えてみれば確かにそうかも知れない。

安易な発想ではあるが、やはり価値観の多様化というものが背景にあるのだろう。価値観が多様であり、共有できていないから、それとなく意図を察するというのが難しくなる。

こういうことを言えば、現代でなくたって人が価値観を何でも共有して平和だったなどということはない、という反論がありそうだなと思う。

それはそうだろう。しかし、そうではない。

むしろ、現代においてだって、多くの人間はほとんどの価値観をほとんどの他人と共有しているはずだ。そうでなきゃ社会など成り立たない。とは言え、例えば古き良き時代にはズレが10%あったとして、それが今は15%になっているとか、そういう微妙な変化はきっと起きていると思う、ということだ。

そうした変化の原因になるのはやはり情報だ。人生のあり様、生き方というものも随分と多様化したという気もするが、そこは個人の価値観にそこまでの影響を与えるとは思わない。

なぜなら、自由に生きる人や変人のような人というのは大昔から一定数存在していた。それこそ偉人伝に出てくるような者はほぼ残らずそうだろう。ただ、そんな人間がどこかでおかしなことをしているということは、元来、我々のような凡人には関係のないことだったはずだ。

それが、インターネットの登場以降、ホームページ、Blog、SNSといった直接的なネット経由の情報発信はもとより、ネットを基盤に企画・量産される書籍や映像のような間接的にネットを利用した情報発信まで、いろいろな意味で玉石混交の大量の情報に凡人が被ばくするようになった。

いくら大量の情報に曝されても、我々が受け取り、我が物とできる情報の量には限度がある。大量の本を読んでいろいろキャラクターの眼を通したモノの見方や価値観というものを理解しても、自分の価値観というものは通常、ひとつの一貫性のあるものとしてしか持てない。

だから、自分が体験から学習した価値観というものからひとつの類型を選択して自らの価値観の基礎とするのだと思うが、その選択肢があまりに増えてしまったのではないか、と思うのだ。

その結果、私と彼方の価値観に決定的な齟齬が生じる確率がひと昔より高まっており、それがために善意が伝わらずに悶々とするという事態が頻出し、その需要に応える形で「言ってくれなきゃわからないよ」というメッセージを発するような物語がそこかしこで語られるのではないか。


以上、オチはない。単に、深夜アニメ数本を見てサマった感想である。


ちなみに、人間は通常、一貫性のあるひとつの価値観に則って行動したくなる、というのは自分の持論です。オリジナリティがあるとは思っていないが、とにかく自分は経験的にそう思っている。特に、会社で部下をちょっと持っていて面談や指導などしていた頃にそういうことを感じた。
価値観というのは、「私は現実主義者よ」とかっこよく言い放つようなことではなく、しばしば自分でも気づいていないような、あるいは自分で思っている自分像とは違うようなもので、その人の行動、発言、感情というものを支えているものだ。

言ってみれば、その人の「世界の見え方」とも言える。本人はそれしか見えていないのだから、それを他人と比べることは簡単には出来ない。単純に言えば、「色」だって人によって見え方は違う。赤と青は物理的に違う色だろうし、特に障害がなければそれは皆、見分けているが、しかし「赤と青は違う色だね」という話と、「これが赤だね」という話が一致しているからと言って、その赤が同じに見えているとは限らない。というか、まず、違っているはずだが、その違いはあるとわかってもどう違うかは認識できない。色のような物理的な性質ならさして問題は起こらないが、これが道徳や評価といった社会的な性質のことなら軋轢が生じる。


そして、それこそ偉人伝に出てくるような天才は、きっとそこにこそ肝心な部分があるのだと思っている。つまり、様々なことを学習した結果、多様な価値観を自在に操ることが出来るのだと思う。完全に同時に2つの価値観を持つということはたぶん脳みその構造からして論理的に無理なのではないかと勝手に想像しているが、きっと天才的な人々は、多くの知識と高い思考力から、ごく短い時間に価値観を切り替えて行けるのだ。簡単な比喩をすればタイムシェアリング式の並行処理だ。

我々凡人が、人生の中のある長い時期をかけてゆっくりと価値観を育て、変容させていく(あるいはある時からまったく変えなくなる)のに対して、彼らはきっと会話の中で、いや自分がひとつの発言をする間にすら価値観を切り替える。加えて凡人の成長と違うのはその切り替えの速さのみでない。その切り替えが可逆的なのだ。そうなると言わば脳内で二人分以上の価値観を討論させることが出来る。三人寄れば文殊の知恵と云うが、それを自家発電で間に合わせてしまう。

漫画に出てくるステレオタイプな天才博士はいつも一人でブツブツと喋っているが、あれはつまりそういうことなのだろう。よく特徴を捉えているのだ。

つまるところ、「君子は豹変す」と大昔に誰ぞが喝破しておられるのも、そういうことなのだろう。


してみると逆に、我ら凡人が陥る不条理のひとつの原因も見えてくる。価値観がひとつしかなく、変化が遅く、不可逆的であること。それが我々の能力に不自由をもたらしている。

「自分の考え」を捨てられない。いちど敵と思ったもの、一度嫌いだと思ったものをどうしても好きになれない。時間をかけて苦労してそれを好きになると、今度は嫌いになれない。否定することが自分を裏切るように思えて、苦しくてそれが出来ない。「せっかく頑張ったのに」みたいな気持ち。そういったことが、よろしくない。過去の自分に執着して、自分と周囲の今と将来を犠牲にしている。・・・だからきっとお坊さんも執着を捨てよと言うのだろう(詳しいことは知らないが)。


きっとここまでの推論は正しいだろうと自分では思っている。


とは言え、ポリシーがないのがポリシーで、目標を持たないのが目標です、とか言っていた時期が自分にもあったが(しかも、社会人で、会社で)、それはそれで拗らせているというか・・・・やはり、難しいですね、社会で生きていくというこは。それでも社会の外で生きていくよりは簡単なのだろうけど。

最後に無理にまとめるなら、願わくば、俺ももっと若いころに、美少女に上目遣いで微笑みながら、怒りながらも赦しを湛えて「そういうこと、きちんと言ってくれなきゃわからないよ?」とか言われてみたかった。

まあ、野郎に目を吊り上げて呪いを込めて「んな事、言わなきゃわかんねえのかよ!?」と詰め寄られたことならあったかも知れないが、そういうのは今後も含めてノーサンキューだ。

だいたい同じことで少しズレてるだけなのに随分違う。不思議だ。なるほど。

2016年9月13日火曜日

Wikipediaの寄付要求週間がはじまっていて非常に鬱陶しい

「 今日、読者の皆さまが¥300ご援助くだされば、募金活動を一時間で終了することができます。」

これ、年に一度か何度か、ちょこちょこ始まるが、非常に鬱陶しい。要求は非常に明快だし必要性もわかるのだが、変に理詰めなところがかえってイラッとさせられる。

とは言え、Wikipediaには日頃お世話になっているし、俺は実は、寄付するのもやぶさかではない。実際、少額だが何度か寄付したこともある。

けど、そうだとしても何ともイヤな感じはぬぐえないし、何しろわざわざクレジットカードを引っ張り出して登録するというのが億劫でもあり・・・。

思うに、俺と同じように、「少しくらい寄付したっていいけど何か気乗りしない」という人は多いのじゃないかなと。それを、意識が低いとか面倒臭がるなとか詰ってもらっても構わないが、問題はやはりそういうところを乗り越えやすくしてもらわないと寄付が集まらないでしょう、ということではなかろうか。

読者を啓蒙、教育して寄付へのアクションを起こしてもらうというのは間違ってはいないが効率は良くない。

たとえば、昔に流行ったホワイトバンドだっけ?腕輪を数百円で買うと半分くらいがどこかへの寄付になるというアレ。ああいうのやったらダメなんだろうか?

別にちゃちいステッカーでもいいし、何なら何も発送されてこなくてもいいから、Amazonあたりに「Wikipediaへの寄付300円」みたいのを出品してもらってですね。1500円寄付しようというなら5個買えばいいと。

そしたら、ワンクリックですからすぐに寄付しますよ。俺は。


なんでそういうことしないのかな?と考えると、実際にそれをするとどうしても手数料でAmazonが少し潤っちゃうから、それが特定企業との関係性になってWikipediaの独立性をおかすという問題なのかも知れないけど・・・・別にAmazon以外のいろいろなモールに出品できるだろうし、現状のWikipedia直寄付のルートも残しておけばいいと思うし・・・それに今の方法だって、少なくともクレジットカード会社には手数料渡してるんじゃないの?と思うのだが・・・。

ダメなんですかね、そういうの。



2016年9月2日金曜日

AWS RDSとEC2のゾーン横断時の応答遅延

AWSのRDSは非常に便利だ。自分のように、仕事でWebアプリを作っているので常にDBを使っていながら、ビジネスロジックを書くのは嫌いじゃないがDBや基盤に関する愛がまったくなくて、チューニングや保守について調べたり設定したりするのが面倒で仕方ない人間にはものすごくありがたい。

で、表題の通り、EC2から使う場合に、RDSは同じゾーンに配置した方がネットワーク上の遅延の少なさから有利というのはAWS公式手引きでもちらほら見かけた気がするが、では実際どのくらい違うのかということについて、さっきたまたま調べたのでメモる。

※ 調べたと言っても、体系的にやったわけではない。自分の手許の環境ではこうだったというだけの話ではある。

EC2側のクライアントから実行したSQLの応答時間は次のようになった。

同じゾーン 0.5~1ms
違うゾーン 20~30ms

すべて東京リージョンで、違うゾーンというのは東京内の選択肢で末尾がaとかcとかそういうアレ。

5倍くらいかかっているということになるが、これがほぼネットワーク的な遅延そのものであると思われる。違うゾーンで使っている場合のこの遅延は、重いSQLをちょこちょこ散発的に投げるようなケースでは問題にならないはずだが、複雑なWebサイトの表示のように、細かくて軽いSQLを大量に投げるようなケースでは大きな問題になると思う。

意外に大きな遅延で驚いた。


ちなみに、上記の確認で投げたSQLはこんなもので、応答の確認はpsqlでtimingコマンドを有効にして行った。

xxxdb=> explain select val from test_table where id='xxxxyyyyzzzz';
                          QUERY PLAN
---------------------------------------------------------------
 Seq Scan on test_table  (cost=0.00..1.02 rows=1 width=32)
   Filter: (id = 'xxxxyyyyzzzz'::text)
(2 rows)
Time: 0.798 ms

テーブルにはデータは数件しか入っておらず、「id」列は主キー。件数が少ないのでシーケンシャルスキャンになっていたりするが、インデックススキャンになるようにしても応答時間はたいして変わらない(要は、どんな実行計画で実行しても限りなくゼロに近い時間で応答できる)。


また、使ったRDSのインスタンスはdb.t2.micro, db.t2.small, db.m3.large, db.m3.xlargeなどだが、それによる応答時間の差はほとんどなかった。


2016年8月31日水曜日

PSQLでの接続でパスワード入力を省略する

PostgreSQLをLinuxで使っていると必須のPSQL。接続が毎度面倒なのを楽にする方法。

ここでは、AWSでEC2のAPサーバーからRDSのPostgreSQLにつなぐ手順のメモをする。

前提として、RDSのPostgreSQLはパブリックアクセス不可、APサーバーと同じVPC、セキュリティグループという状態。

セキュリティグループで、APサーバーからPostgreSQL(ポート5432)への接続を許可する。

APサーバーに
yum install -y postgresql
でPSQLを入れる。サーバーは入れない。

で、このコマンドで接続できる。
psql -h endpointxxxxx.ap-northeast-1.rds.amazonaws.com -d dbname -U dbusername

ただ、毎度パスワードを聞かれるので面倒くさい。

そこで、普段使うユーザーでホームディレクトリに

  1. .pgpass (頭にドット)というファイルを作る
  2. アクセス権を600にする
  3. 中身に以下を書く。
endpointxxxxx.ap-northeast-1.rds.amazonaws.com:5432:dbname:dbusername:パスワード
これで、パスワードを聞かれなくなる。

なお、記述が間違っていると普通に無視される(エラーとか出ない)。自分は、ポート番号を書き忘れたりして「あっれー?なんでパスワード聞かれるんだ?」となった。

追記

上記の方法はどうもうまくいきにくい。
以下の方がかんたん。

ホームにある.bashrcに、以下を書く。
export PGPASSWORD=password

=の横に空白とか入れるとダメ。


2016年8月21日日曜日

事実、インターネットはつまらなくなった。

こういうことを言うとおっさんの懐古趣味とか言われるだろうが、やはり20世紀のインターネットは光り輝いていた。ちょっと気持ち悪く怪しげな光であったろうけど。

それが、今となっては路傍の石のごときつまらないコンテンツで溢れかえっている。

理由は簡単で、広い意味で商業になったからだ。

20世紀頃のインターネットには、テレビ局や新聞社の公式サイトなどほとんどなく(特に国内には)、またアフィリエイトというものも少なかった。存在しても、そもそものトラフィックも少ないので大した収入が見込めるものでもない。

ブログさえもなく、HTMLをせこせこ書いて、時間単価がバカ高い低速回線で一生懸命、小遣い稼ぎにさえならないホームページを作成していた人達の動機は、ただただ「俺の話を聞いてくれ」ということだったのだと思う。

友だちに話すのでは飽き足らなかったり、内容的にちょっと憚られたりするけども、自分の心の裡だけにとどめておくことが出来ない何かを、不特定多数の人間に公開したいというそればかり。一応、「アクセスカウンター」なんてものはあったが、その数字にそこまでの価値があるわけでもなく、とにかく書きたいという気持ちがホームページ作成というクソ面倒くさい作業を無償どころか出費までして行うモチベーションだった。

だから、内容は玉石混交だったけど、ひとつとして同じページはなく、そしてほとんどのサイトが良くも悪くも何かしら尖った主張をしていて、退屈しないものがあった。

ところが、ブログ以降のツールと快適環境に加えて、アフィリエイトその他、トラフィックをまとまった収入に変えることが素人にも比較的現実的に可能になったことで、爆発的に増えたネット上のコンテンツは「読者」におもねるようになった。

目的は自分の主張ではなく人集めなので当然だ。それ自体が悪いというわけでもないのだろう。けれど、それによって、「皆が気分を悪くしないようなことを言う」という、現実生活そのものなコンテンツが増えたし、あげくのはてにコピーが氾濫している。何か調べれば、1ページまるまる同じようなサイトが いくつも引っかかってくるし、それなりに編集されているように見えるサイトでもよく見ればいくつかのサイトのパラグラフをつないだ程度のものでしかなかったりする。

テレビや漫画の感想サイトなども、昔からあるような本当に自分が面白いと思ったものを面白く紹介しているところももちろんあるのだが、一方で、明らかに広告・アフィリエイトのタネとして流行りそうな番組について、どこぞからクレームが来ないように配慮した当たり障りのない内容と検索向けキーワードだけ散りばめているような、読んだところでクソの役にも立たないサイトが随分と目につく。


要は、他人の作ったコンテンツの残飯リサイクルみたいなサイトがあまりに多い。

もちろん、そうではないコンテンツもたくさんあって、インターネットの「個人が情報を発信できるツール」としての力そのものはそう衰えたと思わない。けど、その周囲を埋め尽くすゴミがやたらに多くて、なんだかため息が出ることがある。

なので、インターネットには昔にも増して面白いコンテンツというのもある一方で、やはり「おもしろさ」の平均値のようなものは下がっていると思う。


コンテンツのクオリティが低いというだけでやたらと規制や排除が出来るものでもないし、そういうことはまた良いこととも思えないので、まあ仕方ないという気もするが・・・。法律破ってるわけじゃないし楽して儲かるならいいだろう?という人間というのは絶対にどこにでも出てくるし、きっと未来永劫いなくならないのだろうと思うとちょっと嫌な気分になる。


せめて、Googleには本業の検索でもうひと頑張りしてもらって、そういうコピペアフィリサイトみたいのを検索結果のずっと後ろの方に飛ばせるようになってもらいたいなと期待している。

2016年7月19日火曜日

AWS SESでのメール送信(メルマガ・通常)

SESを使ったメール配信を作ったというより、作っていたWebアプリのメール配信機能でSMTPサーバーとしてSESを使った。

SESではバウンスメールが10%くらいになると出入り禁止になるという鉄の掟があるらしい(実際にはいきなり止まるわけではなくメール等で警告があるという噂もある)ので、バウンスを処理して、ダメなアドレスに何度も送らないようにしないといけない。

それは、↓こんなで何とかなった。

http://venzol.blogspot.jp/2015/05/amazon-ses-e-httpdocs.html


その後の話をまとめておく。

SES + SNS + SQSでどの程度のバウンスレートになったか?

もとのメールアドレスリストの品質にもよるだろうが、数%以内にはとどまっている。通常時は2%程度。

新しいアドレスが大量に投下された時は単純にそのアドレスリストのクオリティになるだろうから、どのくらいの品質があるかわからないリストであれば、一気に大量に送らないで小分けにしていった方がいいのかも知れない。(小分けにして、ちゃんと送れてる他のメールと混ざれば薄まる)


バウンスで多いもの

docomoとezwebの受信拒否機能によるバウンスが圧倒的に多い。これは盲点(抜け過ぎか?)だった。いや、そういうことがあるというのは予見していたが、問題はこれらの場合、(少なくとも俺がやっている業務では)受信拒否を解除してもらってメールを送る必要があるということ。

受信拒否の解除の連絡は、業務運用の方々の守備範囲なのでエンジニアたる俺には関係ない・・・ならよかったが、一度バウンスしてSESのSuppression List(ブラックリスト)に載ってしまったものは、手動で解除しなければならない。そして、この解除は、バッチやAPIでは出来ないようになっていて(キャプチャを入れなければいけない)、業務運用の方々がAWSのコンソールに抵抗ない場合でなければ、これがこちらの仕事になってしまう。


配信速度

現状、1万件/時間程度。SESの応答時間を早くすることは出来ないと思うが、スレッドを増やしてもあちらは遅くならないので、こちらがスレッド数を増やせばもっと早くできるはず。
SESの応答時間以外の処理時間もあり、それはどんなアプリでどんな機器なのかによるので一般論とは言えないが、自分のケースでは上記の性能のために16スレッドで動かしている。

反省というか、SESの使い方

メルマガのようなバルクでの配信をSESでやるとしても、通常の単発のメールは他のSMTPサーバーを使った方がいい。

たとえば、メルマガだとしてもその登録確認メールはSESでないので送っておき、それがバウンスしていない場合だけSESの方でも送るようにすれば、完全ではなくても、ある程度はSESで無駄にバウンス→Suppression List解除とやる手間は減らせるのではないか。


まあ、とりあえず根幹にある問題はスパム業者の跋扈と日本のケータイ会社のショボいフィルター機能(元で対処できないから端末レベルでの拒否設定に頼る)なのではないか、と苛立ちも募るが、そこは言っても詮無いことなのでどうでもいいや。くそ。

SSLについてまとめる

全体的なところがよくあやふやになるので。細かいところは書かない。
また、俺の理解によるので、他人が読んだ場合に間違った結果につながっても責任はもちろんとれない。

利用目的

  1. 暗号化通信を可能にする。暗号化の強度は鍵の長さに依存する。
  2. 通信相手のサーバーを特定・認証する。
    • ただし、これは秘密鍵を使っていることに依存するので、認証局が胡散臭い場合やオレオレ証明書では成り立たない。
    • クライアントは認証されない。暗号化通信開始時点のクライアントであることは保証できるが、HTTPレベルの話なのでセッション単位で認証されるわけではない。

各種ファイル

  • 秘密鍵ファイル xxxx.key
    • 最初に秘密鍵あり。
    • サーバーで作ってサーバーで使う。秘密鍵なだけに。
    • パスフレーズの有無はここで決定
      • 有にした場合、この後、CSRの作成やサーバーの起動で入力が必要
        • サーバーの起動は、コマンドの設定で自動入力することは可能
  • CSR (Certificate Signing Request) xxxx.csr
    • 秘密鍵を使ってサーバーで作る。
    • 公開鍵情報とディスティンギッシュネーム(組織名などの登録情報)
    • 公開鍵として、認証局に登録する(オレオレ証明書でなければ、XXXサインなどのサーバー証明書の発行をする企業に提出する)
  • サーバー証明書 xxx.crt
    • 提出したCSRを使って、認証局(XXXサイン、などの企業と思っていい)が作ってくれる。
      • 間接的に秘密鍵を使っていることになる。ペアとなる公開鍵がCSR→サーバー証明書と形を変えている状態なので。
      • 通常は、認証局がCSRと申込み情報をもとに発行(電子署名をつける)する。自己証明書ではサーバーで作る。

設定の流れ

  1. 登録情報(ディスティンギッシュネームに入れるもの)を確認
    • 鍵の長さ指定も確認
  2. 秘密鍵の作成
  3. CSRの作成
  4. サーバー証明書の申込
    1. CSRの送付
    2. 証明を受ける組織が、XXXサインなどに対して申し込む。実際の手順はサービスにより多少違う。
  5. サーバー証明書を受け取り、サーバーに設置
    1. Apacheならば、ssl.confに秘密鍵とサーバー証明書のファイルを指定し再起動(再起動時にパスフレーズが必要)

更新時の流れ

  1. 原則的に登録時と同じ
    • ssl.confを書き換える
      • SSLPassPhraseDialog
        http://venzol.blogspot.jp/2016/05/apachessl.html の、起動時にパスフレーズを入れない方法のためのshファイル
      • SSLCertificateFile
        xxx.crt
      • SSLCertificateKeyFile
        xxx.key
      • SSLCertificateChainFile ※Apache 2.4では、これがなくてSSLCertificateFileに指定する.crtファイルに、そのまま続けて.cerの内容を貼り付けておくらしい(俺が実際作業したのは2.2だから試してはいない)
        xxx.cer ← 中間CAがあるタイプだったので、crtと一緒に証明書業者から送付されてきた
    • 証明書がメール本文に書きこまれて送付されてきたりしたのでテキストエディタでファイルにしてからサーバーにアップロードしたが、最後の改行はあってもなくても大丈夫ということがわかった。
    • というか、証明書をファイルにした状態でダブルクリック(Windows10)したら、証明書の情報が表示された。保存に失敗していればこれが出ないので、この方法でもひとまずの確認をしておくとよい。
  2. 入れ損ねた場合に既存の証明書で稼働させるため、上記の各ファイルはすべて既存のものと別の名前で配置する。そうすれば、ssl.confを書き換える際に、現状のものをコピーしておけば、もし再起動でエラーが出た場合、ssl.confだけ戻せば既存の証明書で起動できるはず。

具体的な手順の補足

フォルダなども指定しない最低限の手順の例。実際にはもうちょっとファイル名などは管理しやすくする方がよい(更新などで戸惑わないように)。

Apache 2.2 + OpenSSL 1.0の環境。

    秘密鍵の作り方

    1. sudo su -
    2. cd /etc/httpd/conf
    3. openssl genrsa -des3 -out ./myprivate.key 2048
      →パスフレーズを求められる。ここでは"mypass"とした
    4. confディレクトリにmyprivate.keyができてる

    CSRの作り方

    1. openssl req -new -key ./myprivate.key -out ./myssl.csr
      → "req"が「CSRを作る」コマンド。
      → 指定した秘密鍵のパスフレーズが必要。ここでは"mypass"
      → その他設問は冒頭の国コードのみ"JP"、あとはすべて空
      ※ 秘密鍵作成時にパスフレーズのリタイプに失敗してたりすると、秘密鍵ファイルはあるくせにここで妙なエラーが出たりするので注意。その場合秘密鍵を作り直す
    2. myprivate.csrができてる。この中身のテキストを証明書発行サービスに申込時、貼り付けるなどすることになる。

    サーバー証明書の作り方(オレオレ用。通常はいらない)

    1. openssl x509 -req -days 3650 -sha256 -in myssl.csr -signkey myprivate.key -out myserver.crt
      → 秘密鍵は使いまわし
    2. myserver.crtができてる。本来であれば、サーバー証明書の発行会社がくれるもの。
    ついでに以下を作っておく。

    # vi mypass.sh
    # chmod 500 mypass.sh
    中身↓
    #!/bin/sh
    echo "mypass"


    サーバーへの組み込み

    1. vi /etc/httpd/conf.d/ssl.conf
      ここでそんなものないじゃん、という場合:
      # apachectl -t -D DUMP_MODULES | grep ssl
      としてSSLモジュール有無を確認。なければ、
      # yum install mod_ssl
      で入る(少なくとも、AWS EC2 AmazonLinuxでは。)
    2. SSLCertificateFile、SSLCertificateKeyFileをさきほどのファイルで指定
    3. SSLPassPhraseDialog  exec:/etc/httpd/conf.d/mypass.sh
      → これは起動時にパスフレーズ入れるのを省略した場合のみ

    ついでに全ページSSL

    /etc/httpd/conf.dに以下を作成。
    sslall.conf

    RewriteEngine on
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
    Apache再起動で、強制SSL。

    ※ 最初は以下のように書いていたのだが、ホスト名直下の"/"が抜けることがあった。転送先の最後の"/"を足せばいい?と思ったが、どうもRewriteRuleの方が世の多数派のようなので、それに倣うことにした。
    NameVirtualHost *:80
    <VirtualHost *:80>
      ServerName myhostname
      Redirect permanent / https://myhostname
    </VirtualHost>

    2016年6月29日水曜日

    AWS EC2が勝手に再起動するとは聞いていたけど本当にしやがった

    サーバーを動かしていて、httpでの応答を監視していたのだが、しばらくタイムアウトが続いた後、Connection Refusedになった。

    CloudWatchの方では、タイムアウトした頃からモニタリング測定値がなくなっていた。

    異常になってから15分ほどで回復したが、自分がsshで接続してみた頃には何事もなかったのようにサーバーは動いていて、最初は何が起きたかわからなかった。

     last reboot

    というコマンドで、直前のOS起動時刻がわかるそうで、それを実行してみてなるほど再起動かと。


    なお、Elastic IPは使っていないし、特に何かの設定もしていないが、EC2のIPアドレスは変わっていなかった。


    なお、せっかくきれいに再起動してくれたのに、Apacheの自動起動を設定していなかったために、サービス自体は自動復旧しなかった。

    スクリプト自体は勝手にあったので(Amazon Linuxのインスタンス)、

     chkconfig httpd on


    で、たぶん次からは自動起動するだろう(テストしてないけど)。

    2016年6月28日火曜日

    RDS(PostgreSQL)で接続が足りないエラーが出たりする状況

    本日の教訓。

    PostgreSQLで、最大接続数の設定値確認は、PSQLで

    show max_connections;

    AWS RDS(PostgreSQL)での最大接続数の原則は、

    インスタンスのメモリ(GiB)*1024*1024*1024/31457280 
    より少し少ない程度。
    ただしこれは、パラメータグループの内容により変わるかもしれない。


    2016年6月18日土曜日

    Files.listにやられた→ディレクトリが消えない

    Java7から追加されているjava.nio.file.Filesクラスは、Pathと並んで便利。

    だが、ちょっと気持ち悪いAPIのせいで気持ち悪い現象に嵌った。

    Tomcatからの操作でディレクトリをFiles.delete(path)で消すと、成功する。成功するのにディレクトリは消えていない。もう一度消すと失敗する。そりゃそうだ、さっき削除に成功しているのだから。

    でも、ディレクトリは依然として存在している・・・なぜかタイムスタンプがなくなった状態で。

    そして、Tomcatをシャットダウンするとディレクトリは消える。


    ・・・という現象。


    何かをcloseし忘れてるのだろうとは思ったが、ファイルじゃなくてディレクトリだし、空だし・・・と悩んでしまった。

    結局、Files.listで一覧を取得した際に帰ってくるStreamをcloseしていなかったから、ファイルのハンドルが閉じていなかったようだ。で、プロセスが消える時にそれが閉じるのでようやく本当に消えると。

    でもさあ。

    Files.list(path).filter(f->Files.isDirectory(f)).forEach(f->Files.delete(f));// これはダメ

    とか書きたくなるじゃん。Streamで帰ってくるんだから。

    JavaDocをよく見たら、

    try(Stream<Path> = Files.list(path)){
      //do something
    }catch(Exception e){

    みたいにやれと書いてあったけど、なんかそんなら無理にStreamとかにしなくても良かったんじゃねえの、という気がする・・・。


    なお、問題が起きてたのはWindows環境。Linuxだとどうなのかは確認してない。

    2016年6月3日金曜日

    豚の餌

    自分にはしばしばあることなのだが、外食というか飲み屋なんかで、出てきた料理を食いながら「さすがにしょっぱ過ぎる」とか「化学調味料バリバリっつうのも・・・」とか「肉ってやっぱ値段相応じゃん?」とか「豚の餌みたいな・・・」とか、そういう台詞を言った瞬間に店の人が「お待たせしました」って料理持ってきたりする。しかも、そういうときに限ってなぜかオーダー取りの姉ちゃんじゃなくて調理担当の人が持ってきてたりする。

    ・・・今夜もそうであった。

    言っておくが、上記の台詞は、けして店の料理に対して言っているのではない。店の料理もイマイチのこともあるが、だからと言ってそれを店内でケチつけるほど俺も不届きな人間ではない。

    むしろ、食いものが美味しい時に、触発されて料理の話になり、他所のひどい店で食ったものとか、自分で作った料理の失敗談とかを話しているのだ。

    でも、料理を持ってきて断片的に言葉を聞いた店の人は、きっと自分の料理が貶されたと思うのではと思い、いつも無駄にビビっており、かつ申し訳なく思う。やれやれ。

    まあ、普段からそういう汚いことを言わなきゃいいと言われたらそれもそうなんだが、でもねえ・・・・それも詰まらないしねえ・・・。

    みなさんはそういうこと、ないんですかね?

    2016年5月28日土曜日

    Apacheで、パスフレーズつきのSSLを使っていてパスフレーズなしで起動する方法

    まあ、安全のためのパスフレーズだし、そんなに頻繁に再起動しないし毎回入力すればいいかと思っていたが、運用環境で入力を一度ミスったら、「あと9回」とか出て、焦ってまた操作をミスり「あと8回」「あと7回」・・・ってカウントダウンされて心臓止まるかと思ったので。

    ↓こちらの「2」の方法
    http://www.linux-tech.info/web/entry-42.html


    要は
    #!/bin/sh
    echo 'pass-phrase'
    というようなshスクリプトのファイルを作り、実行権限を与えて、実行してパスフレーズを表示できるようにしておき、


    こんな感じでsslの設定を書き替え
    #diff ssl.conf ssl.conf.org
    < SSLPassPhraseDialog  exec:/etc/httpd/conf.d/passphrase.sh
    ---
    > SSLPassPhraseDialog  builtin

    ればOK。

    2016年4月29日金曜日

    PIXUS MG3530インク切れ警告で印刷できない場合の警告解除方法

    警告するのはいいけど、印刷させないというのはどうかと思う。

    ただでさえ最近のプリンターはインクがバカ高いのだから、擦り切れるまで使い切りたいのが心情だし、急いでいることもある。

    ということで、インク切れの警告ダイアログで印刷が 中断される場合の対処方法

    本体の「停止」ボタンを5秒長押し 

    しばらく押してると、エラー表示になっていた他のLEDがぺかっと反応するのでわかる。


    それにしても最近の家庭用インクジェットの、本体をバカ安で売ってインクをバカ高く売り、しかもいろいろ制御して無理にでも買い替えさせようとするという商法はあくどいと思う。買ってからすぐにインク切れ(最初のインクはえらく容量が少ない特別仕様)して気づいた時には、「Canonもずいぶん腐ったものだな!」と思って本体ごと捨ててやろうかと思ったが、調べてみればEPSONやHPなども皆同じ状態のようで。どこが最初かわからないけど、本体の価格競争で負けてしまうと困るので、メーカー側も好むと好まざるに関わらず止められない状態なのだろうと思うが・・・・ものすごく不健全だ。

    して、大メーカーを盲目的に信奉する消費者が多かった昔と違い、そういう不健全な商売はいつまでも上手くいかないのが現代。

    結局、俺はサンワサプライの補給インクを使ってる。これは非常に安い・・・というか普通の「インク」らしい値段で、数回黒タンクを満タンにできる。


    DIY的作業が必要といってもガンプラより遥かに簡単なレベルだし工具もついてくるし。 プリンタのソフトは「純正使わないと壊れても保証できない」とか警告してくるが、そんなことは最初から期待してねえっつうの・・・。カラーインクと黒インクセットで買ったら本体と近い値段すんだから、インク補給に失敗したら素直に本体捨てて最新のプリンタをまた買います。

    使い捨てプリンタとはエコでないし前時代的だと思うが、メーカーが妙なことを仕込むんだから仕方ない。やれやれだ。とは言っても、いまのところ黒専用プリンターとして順調に動いてます。カラーをきれいに出したかったらコンビニかカメラ屋のオンラインプリント行けばいいしね。

    ・・・・本当にアホらしいビジネスモデルだ。プリンタメーカーは早く目を覚まして欲しいものだと思う。

    2016年3月9日水曜日

    クソうざい楽天メルマガとおさらば、と思ったのだが怖ろしいことが起きた

    楽天も昔はそれなりに使っていたけれど、いつまでも前時代的なサイトは見にくいし、Amazonは便利だし、他にもメーカー等の公式サイトも便利になってきているので長らく利用していなかった。

    なのだが、どうにもメールがちょいちょい来てうざい。メルマガの類は基本的にすべてオフにしているので頻度は低いが、それでもちょいちょい使ってもいない楽天からメールが来る。

    頭に来たので一念発起し、長いこと寝かせてあった数百円のポイントを使い切り、退会することにした。

    退会画面では、退会したら一切のサービスが受けられなくなると念を押されるが、もちろん構わない。使う気がないから退会するのだ。

    これでうざい楽●天メールともおさらばだ。退会。ポチ。


    と、思ったら退会完了画面で衝撃の事実が。


    「楽天を退会しても楽天メルマガ配信は停止されません」


    ・・・・なん・・・だと?


    細かい文言は忘れたが、そういうことが書いてあった。おいおい。どういうことだよ?退会するっつってんだよ。つうかもう完了したらからログインもできねえっつうの。で、何でメルマガは送る気満々なの?

    一応、ワンタイムパスワードを使って停止手続きがとれるようだ。もちろんそういう機能は必要だ。だが、他人にアドレスを使われた場合などに、「会員でなくてもメールの受信者ならば停止できる」という機能の必要性はあっても、それが「退会した人にメール配信していい」根拠にはならないだろう。

    自分もシステム開発が仕事であり、つうか小規模ながらメルマガ配信システムなども実装したことがある。だから内部の処理の意外な面倒くささや、とにかくメールを送りたがる方の気持ちもわからないでもない。

    それでも・・・・「しかし、そういうものなのか?」という思いを禁じ得ない。