4月にはシマンテックの証明書が死亡し始めるけど、うちのサイトは大丈夫かChrome Canaryで事前確認できるよ
シマンテックがあれこれやらかして、Chromeに「もうシマンテック(グループ内のRapidSSLやジオトラスト含む)の証明書使ってるサイトは表示しない*1から」と言われてから早数ヶ月。
2016年5月以前に発行された証明書は→Chrome バージョン66から表示しない
それ以外のすべての証明書は→Chrome バージョン70から表示しない
というスケジュールなんだけど、とうとうChrome バージョン66のリリースが再来月(2018年4月)辺りにはやってきそうな予感。
Chrome Canary (通常のChromeより2~3ほど先のバージョンを利用できる開発者向けブラウザ)では、既にChrome バージョン66がリリースされていて、こんな発言も出てる。
"Starting with Chrome 66 (April 17, 2018), Chrome will remove trust in Symantec-issued certificates issued prior to June 1, 2016"
— Vincent Voyer (@vvoyer) 2018年2月3日
I am on Chrome canary (already 66), and A LOT. LOT. of websites are in error. pic.twitter.com/1Ia8iZqZRO
(意訳:2018年4月18日にリリースされるChrome バージョン66からは、2016年6月1日より前に発行されたシマンテックの証明書が信頼されなくなるね。僕すでにバージョン66のChrome Canary使ってるけど、すごくすごくたくさんのウェブサイトがエラーになってるよ)
4月に突然サイトが見られなくなって、あばばばばとならないように、「うちのサイトは大丈夫?」をChrome Canaryで事前確認しておくのがお勧めです。
ちなみにFirefoxは最近基本的に「Chrome兄さんについていきます!」という感じなので、Chromeでサイト見られなくなったら、ほぼ同時にFirefoxでも見られなくなるんだろうな、と予想している。
そしてシマンテック的にはもうDigiCertに証明書事業売ったし、過去に売った証明書がどうなろうと、もはや救済のために奮闘する意思はないんだろうな・・・。
技術書典4に当選したのでDNS本を書くよ
技術書典4、明らかに申し込みサークル数が多そうな気配をただよわせていたので、
これは落選かなーと思っていたんだけど・・・なんと・・・当選したー!
当選したら考えよう、と先延ばしにしていたので、
まだ本のタイトルも目次もサークルカットも決まってないよ。
慌ててこの本を読んでいます。
オンデマンド・・・オフセット・・・・サークルカット・・・・?
本のサイズってそもそもいくつ・・・何部刷ればいいの?
ていうか何使って書いてどういう形式で出力して印刷会社さんへ渡すの・・・?
という、頭の上に「???」しかない同人誌初心者の疑問にすべて答えてくれる安心本。
親切な人に
ブログであげられてる2つの本は両方ともGitHubで全文公開されていますよ
— わかめ@TypeScript味 (@vvakame) 2018年1月8日
と教えていただいたのだけど、GitHubでリポジトリあるね、うん、リポジトリあるし見られるけど原稿はこの中のどこですか・・・どういう形式で書いてあるのか全然分からぬ・・・となったのでそっ閉じして、大人しく電子書籍を買いました。
買ってよかったよー。
技術書典4で初めて技術同人誌作る人は、みんなこれ読むとよいと思います。
あとサークルカットとか表紙とか挿絵とかどうしたらいいの、どう頼んだらいいかも分からないし死ぬ、と思ってたんだけど、幸い一緒に面白がってやってくれるデザイナーさんが現れました。なにこれ奇跡。
という訳で、スケジュール引いて、タスクごとの〆切を決めてがんばります!
IT系でエンジニアやってるけど、DNSとかのインフラ周りは実はあんまり分かってなくて、それがちょっとコンプレックス・・・そんなエンジニア向けにドメインやDNSを分かりやすく教える一冊を作る(予定)です!
サークル名は「好きなコマンドはdigです」です。
あ!あと誰か、これ教えてください。
#技術書典4 で「当落発表後も、サークルカット、概要や頒布物情報を更新できます」とあるんだけど、印刷用カタログデータ確定(グレースケールの方)っていつまでにアップしないとカタログ間に合わないのかな?誰か、〆切教えてー>< #技術書典
— mochiko@技術書典4にはじめてサークル参加するよ (@mochikoAsTech) 2018年2月7日
いつなのー!
技術書典4に申し込んでみたー
2018年4月22日 (日) に秋葉原UDX アキバ・スクエアで開催される「技術書典4」にサークル参加で申し込んでみたー。
過去にやってた技術書典3とか、行きたいなーと思いつつ行けなかったので、えいやーで「本を作る側」として申し込んでみた。
作ったことないのに!本って何使って書くの?製本とかどうやんの?!
申し込みフォームすら「サークル名?サークル名ってなに?みんなどんなのにしてるの?」状態だったよ。結局サークル名は「好きなコマンドはdigです」にしました。
本の内容は大好きなドメインとかDNSとかのことにしようと思っている。
サイトリニューアル時、DNSの変更をしたのにいわゆる「浸透に時間がかかって」なかなかリニューアル後のサイトに切り替わらない、みたいな事例を題材にして、あのなRRにはTTLがあってな・・・とか、あるいはDNS設定されたかなーって確認してしまったがためにネガティブキャッシュで死ぬ話とか、そういう「悩み」と「解決策&解説」のセットがいっぱいある本が書きたいなー。
2月4日 (日) が当落通知日だそうで、当選しないとそもそも参加できないんだね。なるほど。当選したらサークル参加費の7,000円を入金して、それでようやく参加確定になる模様。わー、当選するといいなー。
取り合えず「本の作り方」を学ぶべく、どっちか読もうと思うんだが、どっち買うか迷ってる。こっちの方がお勧め、みたいなのあればどなたか教えて><
ステージング環境のテストユーザで「test@test.co.jp」みたいなメアド使っていませんか?
たとえばあなたが宅配ピザのサイトリニューアルを担当していて、ステージングサイトで「ログインして注文する」というテストをするため、テスト用のユーザを作ったとします。
名前は適当に田中一郎にして、誕生日も適当に2010年10月10日、メアドも適当に「tanaka@test.co.jp」にしとこう!
ちょっと待ったー!
名前と誕生日はいいとして、そのメアドは待ったー!
昨日のエントリでも書いたけど、自分が買っていない=持っていないドメインを勝手に使うのは、トラブルの元なのでやめましょう。
こういう場合に使うべきなのは、
のどちらかです。
あまり知られていませんが、実はインターネットでは「例示やテストで使っていいドメイン」というものがあります。
こういうケースではRFC2606で定められている「example.com」や「example.net」、もしくはJPRSが定めている「example.jp」「example.co.jp」などを使いましょう。
ところで先ほど「自分が買っていない=持っていないドメインを勝手に使うのはトラブルの元」と書きましたが、具体的にどんなトラブルが起きるのでしょう?
たとえば「test.com」というドメインは(恐らく)DOSarrestというサービスをやっている Internet Security LTD,という会社が所有者ですし、「test.co.jp」というドメインは有限会社教育評価研究所という会社が所有者です。(Whoisを見れば分かる)
そのため最初に書いた宅配ピザのステージングサイトで、仮に「tanaka@test.co.jp」というメアドの登録したユーザでテストを行うと、実際に有限会社教育評価研究所という会社に会員登録完了メールや注文完了メールが飛んでいってしまい、相手方にご迷惑であると共に、情報漏洩の恐れもあります。
誰かがアンケートに適当な住所を書いたせいで、全然関係ない自分の家にダイレクトメールが届いたら迷惑ですよね。実在する他人の住所を勝手に書かないのと同じように、他人のドメインも勝手に使わないようにしましょう。
じゃあ「誰のものでないドメイン」ならいいのでは?と思うかも知れませんが、現時点で誰のものでもなくても、明日には誰かが取得するかも知れないので、これもやはりお勧めしません。
Chromeで.devのドメインがHTTPだと見られない件の解説
本件、あちこちで悲鳴が上がってたけど、色々調べたら面白かったので解説。
元々はgTLDは.comとか.netとかの22種類しかなかったので、各社が組織内のネットワーク(開発環境とか)でオレオレTLDとして勝手に.devを使ってた。
でもgTLDがわんさか増えて、とうとう.devというTLDもできてしまい、色んなところで「やばい名前衝突(Name Collision)するわ・・・」という話題が出たのが2014年ごろ。
ちなみにICANNWikiによると、この.devは元々AmazonとGoogleで「俺がレジストリになる!」と奪い合ってたけど、youとtalkをAmazonに譲って、代わりにdevをGoogleがゲット、みたいな経緯があった模様。
レジストリってのはあれな、そのTLDの唯一の卸元というか、生産元みたいなもの。だからあちこちで「Googleが.devを買った」って言ってるのは、この「Googleが.devのレジストリになったこと」を指してるんだと思う。
んで今回Googleが「Chromeで.devを開くと強制的にHTTPSにリダイレクトされる」という暴挙に出たのは「Googleは2014年にdevのレジストリ(生産元)になった。でもまだ.devのドメインは一般発売していない。ってことは今.dev使ってるやつは、全部買わずに勝手に使ってるやつなので何してもいいよね。強制リダイレクトさせるわ」っていう考えなのかなと推測してる。
.devだけじゃなくて.appもみたいだし、このドメインがもうHTTPSでしか使えないってことは、Googleは.devを普通に売るんじゃなくて、何か特別な用途で使わせるつもりなのかなー?
で「.devが使えなくなったからとりあえず.testにした!解決!」みたいなのも見るんだけど、なんで.testにしたらいいのか?.testでいいなら.dev2とかでもいいのか?という疑問は浮かばないでしょうか?浮かびますよね?きっと。
ざっくり言うと、.testはいいけど.dev2はだめです。
社内ネットワークにしろ、テスト用のメアドにしろ、「例示として使っていいドメイン」や「テストとして使っていいドメイン」はRFCで定められているので、基本的にはそれを使いましょう。
自分が買ってない=持ってないドメインを勝手に使うのは、今回みたいなトラブルの元なので控えた方がいいよ、という話でした。
sudoとsuで聞かれるパスワードは違う
sudoは「他のユーザとしてコマンドを実行する」ためのコマンド、 suは「他のユーザになる」ためのコマンド。
sudoのとき聞かれるのは、「自分(今のユーザ)のパスワード」で、 suのとき聞かれるのは、「なろうとしている他のユーザ」のパスワード。
たとえば、mochikoユーザでログインして、 sudo cat /root/.ssh/authorized_keys を叩こうとしたら、mochikoユーザのパスワードを聞かれるし、 su - でrootになろうとしたら、rootのパスワードを聞かれる。
今となっては当たり前なんだけど、分かるまでは結構混乱するよね。
ネガティブキャッシュのキャッシュ残り時間が知りたい
DNSキャッシュサーバにネガティブキャッシュ(status:NXDOMAINなどのときの「そんなリソースレコードは存在しない」という情報のキャッシュのこと)が残ってしまって、あとどれだけ待ったらネガティブキャッシュが消えるのか知りたい。
そんなときは、digでキャッシュの残り時間を確認できる。
- 存在しないhogehoge.yahoo.com を引いてみる
SOAレコードで設定されている値から、ネガティブキャッシュのTTLが600秒であることが分かる。
$ dig hogehoge.yahoo.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> hogehoge.yahoo.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21575 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;hogehoge.yahoo.com. IN A ;; AUTHORITY SECTION: yahoo.com. 600 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2016052509 3600 300 1814400 600 ;; Query time: 164 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu May 26 00:02:54 2016 ;; MSG SIZE rcvd: 97
- 再度、hogehoge.yahoo.com を引いてみる
ネガティブキャッシュの残り時間が380秒であることが分かる
$ dig hogehoge.yahoo.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> hogehoge.yahoo.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36019 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;hogehoge.yahoo.com. IN A ;; AUTHORITY SECTION: yahoo.com. 380 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2016052509 3600 300 1814400 600 ;; Query time: 11 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu May 26 00:06:34 2016 ;; MSG SIZE rcvd: 97
- 380秒も待てない!ネガティブキャッシュ消したい!というときはrndc flushでDNSキャッシュサーバのキャッシュを消す
# rndc flush
- 再度、hogehoge.yahoo.com を引いてみる
ネガティブキャッシュが消えて、問い合わせに行き、そして再びネガティブキャッシュのTTLが600秒になっている。
# dig hogehoge.yahoo.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> hogehoge.yahoo.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30397 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;hogehoge.yahoo.com. IN A ;; AUTHORITY SECTION: yahoo.com. 600 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2016052509 3600 300 1814400 600 ;; Query time: 418 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu May 26 00:09:29 2016 ;; MSG SIZE rcvd: 97
これでやきもき待たなくて済むー。