昼間っから鳥刺し

今日のお昼休みに食べに行ったのは『なごみ』という名前の焼き鳥屋がやっているランチ。前は良く通るんだけど、いつも混んでるなーと思ってなかなか入る機会を逸していた。
今日は満席でも待つつもりで行ったら、けっこう中が広くて席はたくさん空いていた(汗)。入ってみるもんだな。
で、メニューを見て目を引いたのが、鳥刺しのセットだ。
マジスカ。
昼間から。
鳥刺しが。
食べられるですか!

と言うわけで、鳥刺し。うまかったです。ぷりっぷりの食感と、ササミ(だと思う)の淡泊な味が醤油とワサビと相まって。鳥刺し好きなのよね。
で、びっくりしたのが丼と海苔の佃煮。驚くぐらいしょっぱくない。
海苔の佃煮とか、全然しょっぱくなくて、磯と海苔の味がすごくちゃんと出てる。なにこれ、自分ところで作ってるわけじゃないよね? どこで買ってきてるんだろう? ただそういう意味ではご飯と一緒に食べると物足りないかもだけど(笑)。
焼き鳥丼も肉の味の方が勝つくらい塩がふられてない。けど、焼き加減も柔らかめでとてもおいしい。んだけど、ご飯と一緒だとやはりしょっぱさに物足りなさを感じる。でもそこは柚胡椒と紅生姜を足しながらいただくと、イイ感じの塩加減になるのだ。
食べログの点数、もうちょっと高くてもいいんじゃないかなぁ……と思いつつ。
1511117385 1511117386 1511117388 1511117389 1511117392

夜は帰ったら食べるものがなかったので、近くの『魁力屋』に行ってきた。
普通の醤油ラーメンのハムカツ定食。
シンプルでうまい。
1511117399 1511117395 1511117397 1511117398

さて、職場で BGM を聞く件
今日まで自前の Docomo 回線でがんばって来たが、このままでは帯域制限を喰らうことは確実となってしまった。
そこでいくつかの選択肢を考えてみた。

  1. DLNA サーバを立てる
  2. 音楽のためだけの VPN を用意する
  3. USB の外付け HDD に音楽データをコピーして持ってくる

まぁ 1 かなー。1 が現実的かなー。3 は最終手段だな。
でも 1 って外部からアクセス出来るんだろうか?
というわけで Twonky Server っていうのを入れてみたのだが、これのルータ越えのやりかたがよくわからん。HTTP だけ喋れるようにしたんじゃダメなのか……(成功しているのはどれも旧バージョンのものばかりで、Ver.8 のものは出てこなかった。Ver.7 のものをみるとどうも Javascript でいろいろやらないといけないようなのだが……)? などとやっていたらどんどん時間が過ぎていくので、今日は諦めた。

サーバの話とか

11/5 にコピーをはじめた(正確には日付は 11/6 になっていたけど) amatsukami.jp サーバのデータだが、この日でもまだコピーが終わってなかった(汗)。やっぱ LAN 経由だとだめだったかー。
細かいファイルが多いせいか 20 ~ 30MB/sec をウロウロって感じ。
でかいファイルだと 80MB/sec くらいまでは行くんだけど……。

で、なんとか一通り終わったので日付は 8 日の未明、ようやく HDD を交換する。
次回からは eSATA でやろう。

しかし、コピーが終わってみると 7.6TiB あった空き容量が 2.80TiB に。この領域もいよいよドライブ一台の運用では間に合わなくなりそうだ。残り 2.8TiB は一年もたないだろう。むむぅ。
151120_ws2008r2

話変わって、何ヶ月も前になくした 64GB の MicroSD カードが出てきた。嬉しい。今年に入って 32GB とこの 64GB の計二枚を立て続けになくしていたので、本当に嬉しい限りである。特に 64GB の方は決して安いものではなかったので。
どちらもドラレコで使っていたカードである。

さらに話が変わって、TAMA NETWORKS LIVES(要するにこの日記)の記事が今日 1000 件を越えた。1000 件目の記事はこれと思われる。ちなみに写真や動画類は 5380 個(サムネールは除く)、80.2GiB らしい。けっこう使ってるなー。

小嶋と Seagate の 8TB HDD

今日は前に行ったカレー専門店『ふくてい』の並びにある定食屋さん『小嶋』。写真からして年季の入った建物と廂(ひさし)。店に入ると常連客とおぼしき人が多い印象。というのも「アレないの?」的なこそあどで注文が通る客がいたり、お店の人も気軽に「○○終わっちゃった」といった感じの会話が飛び交っていたからだ。

メニューがよく解らず、とりあえず無難にとんかつ定食を選んでしまった。
なんか他の客の注文を聞いていたら、いろいろ気になる料理の名前が飛び交っていた。その中にはメニューに載っていないものも(メニューに書いてないという会話があった)。

さて、味は素朴である。ただ味噌汁がかなり好みの塩加減と出汁だった。
おいしい。
揚げ加減はちょい片目より(揚げすぎ)。衣がかなりぱりっとしている。
中のお肉も決して柔らかいわけではないが……。

とはいえ、気になるメニューがいろいろあったので、また来よう。
1511057296 1511057292 1511057294

家に戻ると 8TB の HDD が届いていた。amatsukami.jp サーバの Projects / Users 用のドライブの残り容量がやばかったのだ。このドライブには SVN のリポジトリもある。いわゆる開発に関わるいろんなデータを入れているドライブなのだ。このドライブは Seagate の ST4000DM000 で運用されている。容量 4TB。
これを同じく Seagate の ST8000AS0002 と交換するのだ。
まず新しい ST8000AS0002 を自宅の開発機にとりつけ LAN 経由でサーバから ST4000DM000 のデータをコピーする。4TB ほぼいっぱいに使っているので転送には数日を要するだろう。
直接サーバに取り付けちゃえば 24 時間以内に終わると思うけど、なんかサーバの中を開けるのがめんどうくさかったので。
でも今思えばさ、サーバに eSATA がついてたんだよね。なーんでそっちでコピーしなかったのやら……orz
1511057298 1511057301 151105_disk

text-size-adjust とかるかん

いつからか忘れたけど、iOSSafari でウチのサイトを表示すると、妙にフォントがでかく表示される。今のデザインにしたとき、当然 iOS でもチェックしたはずなので、最初はこんな事なかったと思うんだけど……。
まぁ、iOS の Safari のフォントはソシャゲを作っていたときにも悩まされたんだけどね。

とりあえず CSS に以下の一文を追加して応急処置した。

 -webkit-text-size-adjust: 100%;

これで他のブラウザとかに変な影響が出ないといいんだけど(汗
下の SS は iPhone 6 によるもの。CSS ピクセル 375 x 667。左が修正前、右が修正後。
1510226651 1510226652

閑話休題。
出社したらボクの机に誰かからのお土産が置いてあった。よくみると「かるかん」って書いてある! これがかるかんかぁ。水曜どうでしょうで「白くま」っていう 750ml のかき氷の早食い競争をやるんだけど、鹿児島空港にそれが売ってなくて、代わりにこのかるかんで勝負しないかという一幕がある。
なるほど、確かにこれは藤村 D が得意そうな餡子の入った食べ物だった。
衣が独特。食感だ乾いてる感じなのにボロボロ崩れない。へー。
ありがとうございました。
1510076467 1510076469

金払ってなかった…

時間は何時か忘れたが、15 時頃だろうか? 自宅のネットが不通になった
んー?
プロバイダとフレッツの障害情報を見るも、特に何もナシ。
これは料金未払いじゃなかろうか?
と、116 に電話してみたら、案の定(汗)。

あれー?
払ってない月なんて、あったっけー?

どうやら先々月のを払い忘れているらしい。とはいえ、用紙などは見当たらない。
するとイージーペイだかなんだかとかいうので払えるらしい。
その番号を教えてもらって、ソッコー払いに行く。
それで解決した。うーむ(汗

実はカード払いか引き落としにしたいんだけど、ウチの光回線は父親名義になってるのよね。電話とまとまってた方がいいだろうと思って、当時、父親の名前で引いてしまったのだ。
で、カード決済に変えてもらおうかと思ったら、名義変更をしてくれと言われた。父は亡くなっている旨を説明したら、なんかよく解らん書類の束が送られてきて、必要書類がすげーめんどくさいことになっていた(汗)。なのでそれっきりだったのよね。

というわけで、お騒がせしました。
ちなみにカード払いにするように変更した(名義変更しなくて済んだ)。

以下、Twitter ネタ

ボクの周囲で男が自分の裸を撮っているというのは聞いたことがない。もっとも撮っていたとしても、周囲に言わない気がするが。
それに引き替え、女性はけっこう耳にする。
なんでだろうねって話。

 

DB を SSD に移行した

TAMA Networks は重い(汗
原因はいくつかある。まず、ウェブサーバが Active Directory を運営しているため、HDD のキャッシュができない。すでにサーバが 4 年以上経過している、等。

本当はもうサーバを入れ替えなくちゃいけないんだけど、いま amatsukami.jp でやっていることがけっこうたくさんあるため、なんとなーく先送りにしている(汗)。新サーバを立てたとしても、同じサービスを動かせるようになるまでどんくらいかかるんだ、みたいな(^^;

で、とりあえず DB と画像などをおいてある領域を SSD に移してみた。
あと DB のバッファも大幅に増やした。

目に見えて速くはなったんだけど、それでもまだ遅いね(^^;
これ以上はサーバを新しくしないとダメかなぁ……。

オープン リゾルバ事件

勤め先の会社は三つの開発室があるんだけど、それらのネットワークを管理している。で、そのうちの一つの開発室で利用しているプロバイダから、どうも大量の不正パケットが流れた形跡があると連絡をよこしてきた。
ログをみたら、一目超然、DNS amp 攻撃だった。

ぎゃーす! そういえば、DNS の設定ってどうなってたんだっけ?<ヲイ
って色々調べたら、amatsukami.jp サーバもオープン リゾルバになっていた……orz

皆さんがウェブサイトを閲覧するとき、そのサイトを運営しているサーバに正しくアクセスするためには DNS という仕組みが不可欠である。インターネット上のサーバはすべて一意の重複することのない番号(IP アドレス)が割り振られていて、この IP アドレスはグローバル IP アドレスと言って、インターネット内で重複しないように割り振られている。例えば今あなたが見ている TAMA Networks を提供しているサーバのグローバル IP アドレスは 210.136.205.247 であり、これは世界に一つしかない IP アドレスである。この番号を他の誰かが使うことはない。
でもこの 210.136.205.247 という数字を使ってデータをやりとるするのは非常に非効率だ。この数字は将来的に変わるかもしれないし、この IP アドレスで提供されるサービスは一つに限ったことではない(FTP、メールなど)。
そこで、この数字と抽象的な名前(○○.co.jp とかのことで、これをドメイン名という)を関連づけることによって、柔軟なアクセスを提供するのが DNS という仕組みだ。たとえば、TAMA Networks のブックマークをブラウザで呼び出すと、ブラウザは amatsukami.jp にアクセスしようとする。ブラウザはまず DNS を提供しているサーバに「amatsukami.jp は何番でっしゃろ?」と問い合わせに行くのだ。すると、DNS サーバが「210.136.205.247 でんがな」と答えてくるので、ブラウザはその DNS から答えられた番号の振られているコンピュータ(サーバ)にアクセスしに行くのである。
これはなにも amatsukami.jp に限ったことではなく、世の様々なサーバ(sony.co.jp とか honda.co.jp とか)すべてがこの方法でアクセスしたいサーバを求めており、これを名前解決と言い、このような DNS サーバを「フルサービス・リゾルバ」という。

ではどのフルサービス リゾルバ DNS にアクセスしに行くのかというと、それは各プロバイダが提供している。他にも Google なんかが自由に使える DNS サーバを用意してくれたりしているし、自分で設定することも出来る。
また会社では会社で建てたフルサービス リゾルバ DNS サーバがその役を担い、ウチの会社もそうなっている。

さて、では DNS サーバというのは全世界中の IP アドレスと名前の情報を持っているのかというと、そう言うワケではない。DNS サーバは例えば「amatsukami.jp は何番よ?」と問い合わされたら過去に同じ問い合わせがないかをまず調べる(キャッシュ)。なければ、.jp を管理している DNS サーバに問い合わせに行く。すると .jp を管理している DNS サーバは「amatsukami.jp なら 210.136.205.247 っていうサーバが詳しいことを知ってるぜ」と返してくるので、210.136.205.247 に問い合わせに行くと、210.136.205.247  の DNS サーバ(つまりボクのサーバ)が amatsukami.jp に関する様々な名前と数字の対応を返すのである。このようにフルサービス リゾルバは、次々とより上の DNS サーバに問い合わせていくようになっていて、これを再帰呼び出しと言う。
amatsukami.jp に関する様々な名前というのは、例えば ftp.amatsukami.jp や www.amatsukami.jp など、amatsukami.jp がつく様々な名前である。ここで初めて、amatsukami.jp も 210.136.205.247 だとって返ってくるので、これを問い合わせしに来た機械に渡すのである。
この時、この「問い合わせをしに来た機械を詐称」することができる。
つまり本来は、A というコンピュータが「amatsukami.jp は何番よ?」って聞いてきたら、その結果を A に返すはずなのだが、ここを B というコンピュータに返せとすることが出来てしまうのである。
こうすることによって DNS サーバは B に答えを送ってしまうどころか、本来定義されていない情報を問い合わせる(この問い合わせ内容が、普通の DNS 問い合わせより遙かに情報量が多いように細工されている)ことによって、DNS サーバはコンピュータ B の回線をパンクさせてしまうのだ(実際には何万台という乗っ取られたパソコンをつかって、DNS サーバにこのような攻撃を行う)。
そのためフルサービス リゾルバは、インターネットの誰からでも受けてはいけないように設定しなければならない。そもそもこの名前解決の問い合わせは各プロバイダが提供しているのであって、わざわざ他人のサーバに問い合わせる必要などない。従ってウチも社内でのみ、このサービスは提供すべきなのである。

ではなぜそれがインターネット全体にも提供していたのか?
それは上の説明にも出てきた「amatsukami.jp なら 210.136.205.247 っていうサーバが詳しいことを知ってるぜ」という部分である。ボクのサーバは全インターネットに向けて、amatsukami.jp に関してのみ責任を持って名前解決をしなければならない(こういう DNS サーバをコンテンツ サーバという)。
amatsukami.jp のついたものに関しては、ボクのサーバだけが真実を知っているのである(実際には真実を知っているサーバを定義することが出来るが)。
そして Microsoft の DNS サーバは、フルサービス リゾルバとコンテンツ サーバを分離出来ない。もし分離したかったら、フルサービス リゾルバ用の DNS と、コンテンツ サーバ用の DNS をそれぞれ別に立てないといけないんですな(ちなみに UNIX の世界で使われている BIND という DNS のプログラムは、この二つの機能を分離出来る)。

まぁ、Windows でも BIND 使うべきなのかもしれないけどね……。

で、とりあえず会社の方はコンテンツ サーバとしての役割を他の外向けサーバに移し、ルータ側で DNS の外部ポートを閉じた。
一方の amatsukami.jp は LAN 内の Active Directory を提供しているマシンにフルサービス リゾルバを設定し、SMTP(メール)のゲートウェイをしているサーバに新たに DNS をインストールし、そちらでコンテンツ サーバとして設定した。これで amatsukami.jp サーバがオープン リゾルバではなくなった。

あー、説明が長かった……orz
ちゃんと正しく説明できているかなぁ……。