サックス練習 – 33 –

ども。こんばんは。

久々に動画です。

松田聖子さんの名曲「SWEET MEMORIES」です。

いい曲ですね。

ではでは。またの機会に。

Leave a Comment

令和になったことだしクラウドへ移行する – 11 – AWSからはじめての請求がきた

ども。こんばんは。

2019/6/3に請求が来ていました。

$1.29でした。

t2.microは無料なので、データ転送量だけ課金された感じです。

以下にプラスして消費税$0.1で、$1.29でした。

 

Data Transfer

$1.19

US East (N. Virginia)

AWS Data Transfer USE1-APN1-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from Asia Pacific (Tokyo)
0.005 GB
$0.00
AWS Data Transfer USE1-APN1-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to Asia Pacific (Tokyo)
0.116 GB
$0.00
AWS Data Transfer USE1-APS1-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from Asia Pacific (Singapore)
0.000000070 GB
$0.00
AWS Data Transfer USE1-APS1-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to Asia Pacific (Singapore)
0.000000040 GB
$0.00
AWS Data Transfer USE1-CAN1-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from Canada (Central)
0.000000070 GB
$0.00
AWS Data Transfer USE1-CAN1-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to Canada (Central)
0.000000040 GB
$0.00
AWS Data Transfer USE1-CloudFront-In-Bytes
$0.00

$0.00 per GB data transfer in to US East (Northern Virginia) from CloudFront
0.000011 GB
$0.00
AWS Data Transfer USE1-CloudFront-Out-Bytes
$0.00

$0.00 per GB data transfer out of US East (Northern Virginia) to CloudFront
0.000003 GB
$0.00
AWS Data Transfer USE1-EUC1-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from EU (Germany)
0.000002 GB
$0.00
AWS Data Transfer USE1-EUC1-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to EU (Germany)
0.000093 GB
$0.00
AWS Data Transfer USE1-EUN1-AWS-In-Bytes
$0.00

USD 0.0 per GB for EUN1-AWS-In-Bytes in EU (Stockholm)
0.000000430 GB
$0.00
AWS Data Transfer USE1-EUN1-AWS-Out-Bytes
$0.00

USD 0.02 per GB for EUN1-AWS-Out-Bytes in EU (Stockholm)
0.000001 GB
$0.00
AWS Data Transfer USE1-EUW2-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from EU (London)
0.000000070 GB
$0.00
AWS Data Transfer USE1-EUW2-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to EU (London)
0.000000040 GB
$0.00
AWS Data Transfer USE1-USW1-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from US West (Northern California)
0.000004 GB
$0.00
AWS Data Transfer USE1-USW1-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to US West (Northern California)
0.000010 GB
$0.00
AWS Data Transfer USE1-USW2-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from US West (Oregon)
0.000157 GB
$0.00
AWS Data Transfer USE1-USW2-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to US West (Oregon)
0.012 GB
$0.00
Bandwidth
$1.19

$0.000 per GB – data transfer in per month
6.862 GB
$0.00
$0.000 per GB – data transfer out under the monthly global free tier
15 GB
$0.00
$0.000 per GB – regional data transfer under the monthly global free tier
0.035 GB
$0.00
$0.090 per GB – first 10 TB / month data transfer out beyond the global free tier
13.214 GB
$1.19

結局アウトバウンドトラフィックだけ課金ってことなかな。

IncapsulaでCDN効かせてるのでそこそこ節約してる・・・と信じたい。

 

Bandwidth
$1.19

$0.000 per GB – data transfer in per month
6.862 GB
$0.00
$0.000 per GB – data transfer out under the monthly global free tier
15 GB
$0.00
$0.000 per GB – regional data transfer under the monthly global free tier
0.035 GB
$0.00
$0.090 per GB – first 10 TB / month data transfer out beyond the global free tier
13.214 GB
$1.19

【バックナンバー】

ではでは。またの機会に。

Leave a Comment

パニック障害の経過 – 3 –

ども。こんばんは。

そろそろ発症から半年ほどになりますが、なかなか治りませんね。

今週は天気も悪かったせいか、いまいち調子も上がらず。。

2019/6/14から薬を調整して今こんな感じになりました。
ベースのイミドールが夜と就寝前に10mgを一錠ずつ追加です。

一日17錠ってなかなか薬多い気もしますね。

  • 朝  :ソラナックス 0.4mg x1   /ガナトン50mg x1/イミドール 25mg x1/イミドール10mg x2
  • 昼  :ソラナックス 0.4m x0.5  /ガナトン50mg x1/イミドール 25mg x1/イミドール10mg x1
  • 夜  :ソラナックス 0.4m x0.5  /ガナトン50mg x1/イミドール 25mg x1/イミドール10mg x2
  • 就寝前:ソラナックス 0.4m x0.5  /イミドール10mg x2

ここのところ、頓服薬を使わなくてもなんとか耐えれるようになってるので、だいぶ快方に向かっている気はしますが、なかなか後ちょっとのところで治りませんね。。。

【バックナンバー】

ではでは。またの機会に。

Leave a Comment

HTC U19e/HTC Desire 19+記事まとめ

でましたね。

■HTC台湾の公式ページ

https://www.htc.com/tw/smartphones/htc-u19e/

■各種ブログ、ニュース

うーん・・・。

うーん・・・・・。

過去のスマフォ遍歴。

Windows Mobile:

  • X02HT
  • X04HT
  • (X02T←唯一東芝)

Android:

  • HTC evo WiMAX(ISW11HT)
  • HTC J(ISW13HT)
  • HTC J One(HTL22)
  • HTC J Butterfly(HTV31)
  • HTC U11(HTV33)

7台続いたhTc信者ですが、ここに来てもうやっぱり駄目かな・・・。
Pixelにするかなぁ。

新機種も面白そうだし、基盤透けてるのexodusぽくて格好いいんだけど、U11でスペック的にもまだ全然戦えるし、U11がこのまま3年目突入かなー。

ではでは。またの機会に。

 

Leave a Comment

有給休暇、久々の秋葉原、煙管の掃除ほか

ども。こんばんは。

今日は有給休暇ももらいましました。

今年度に入ってまだ1日も取得してなかったし、計画的に取らないとですね。

午前中はバタバタと洗濯したり掃除したりして、午後からは久しぶりに秋葉原に出向いてみました。

平日だとちょっと空いてます。けど、海外から来てる観光客が多いですねー。

行ってみたかったお店を何件か回りましたが特に買うものもなく・・・。
iPad miniほしいなーとか、BlackBerry KEY2が意外とイケてるなーとか。
程度のいいPC-98ないかなーとかウロウロしていました。
98Noteレストアしたい熱にかられてます。

そういえばHTC U11もそろそろ2年ですね。買い替えどうしようかな。。。

さて、話変わって煙管(キセル、きせる)ネタです。

結局前回購入したヒュミストーンは加湿力が強過ぎて以下のものを買いました。

柘製作所(tsuge) ヒュミドール・アルミ・ブラック #77609

¥540なり。

どっちが表だろう?

前回購入したヒュミドールは全体がヒュミドールだったけど、今回は中になにか入ってる感じ?
大きさはちょっと小ぶりになりました。

小粋の箱にピッタリです。

まあ、なんとかこれでいい感じ?でしょうか。

まだまだこのあたりの管理方法がちゃんとわかっていませんね。

それはさておき、煙管を初めて1週間ほど経ちましたので、今日は掃除をしてみました。

火皿が結構汚れています。

1週間、毎日1〜2回喫煙しています。

これを、無水エタノール、綿棒、モール(煙管と同時に購入)で掃除します。

モールに無水エタノールを染み込ませて、吸い口側から、火皿方向に向かって通します。

おー、だいぶ汚れてた。

火皿も無水エタノールを染み込ませた綿棒で掃除してみました。

分かりづらいですがだいぶきれいになりましたね。

残骸たち。結構汚い。

私の煙管は、羅宇も金属なので、水洗いでもいい気がしてきた。。。
でも大体この流れが一応正規?の清掃の仕方みたいです。

いろいろ探していると、以下の動画のようなやり方もあるみたいですね。
エタノール飲んじゃいそうな気もしますが、次はこれでやってみようかな?

 

久々に有給を有意義に過ごした・・・気がする。

ではでは。またの機会に。
 

Leave a Comment

Facebookのプライバシー設定でスマートリストでの除外ができなくなった?

ども。こんばんは。

2019年5月25日頃?から、

投稿時に以下のようなメッセージが出るようになってしまいました。

「オーディエンスを更新してください」

このスマートリストをオーディエンスから除外することはできません。除外する人をそれぞれ選択するか、別のオーディエンスを選択してください。

私は、公開範囲を「友達」にしつつ、一部の会社や学校を除外する設定をデフォルトにしています。

どうやらそれが効かなくなったっぽいです。

こまったなー。

プライバシー設定を変えようとすると以下のようなエラーとなり更新できません。

「このスマートリストを除外することはできません」

You can’t exclude this smart list from your audience. Please select each person you want to exclude or choice a different audience.

しょうがないので、除外ではなく、公開したい人だけを公開範囲に設定しました。

どうやら影響があるのはスマートリストだけみたいですねー。

なおらないかなーこれ。

アプリでも同じようなエラーになりますね。

ではでは。またの機会に。

Leave a Comment

Lenovo Yoga Tablet 2にWindows 10 May 2019 Update(Version 1903)は今の所入らない?

ども。こんばんは。

まだギリギリ使ってるYoga Table 2を1903にアップデートしようかと。

過去記事:

えっと、結論失敗しました。

多分原因はこれ。とはいえ、容量足りないからSDは必須なんだよね。

USB デバイスや SD カードが接続されているコンピューター上の「Windows 10 にこの PC をアップグレードすることはできません」エラー

注意!Windowsアップデート1903はUSBやSDカードを外さないとエラーが起きる

 

とりあえずアップデートします。

今は1809ですね。

まだ普通のWindows Update経由ではうちには来ないみたいなので、手動アップデートします。

相変わらずの容量不足。

あと数百MBかあー。

お、Windows Updateのクリーンアップで7GBくら確保できそう。

クリーンアップしても減らなかったぞ・・・。
Kindleのダウンロード済みデータとかを消してなんとか8GBを確保。

はじまったー。

おー、進んでる。

ということで、冒頭に戻りますorz

次の作業が必要です。

このPCをWindows 10にアップグレードすることはできません。
お使いのPCはこのバージョンのWindows 10で使用する準備ができていないハードウェアがが使われています。対処は必要ありません。問題が解決された後、このバージョンのWindows 10がWindows Updateで自動的に提供されます。

 

 

そのうちうまくできるようになるのかなー。

ではでは。またの機会に。

 

Leave a Comment

「劇場版 夏目友人帳 ~うつせみに結ぶ~」を見た。

ども。こんばんは。

発売日に届いていたのですが、ようやく今日見ました。

劇場版 夏目友人帳 ~うつせみに結ぶ~(完全生産限定版) [Blu-ray] ¥6,479

めちゃくちゃ良かったそしてめちゃくちゃ泣いた(´;ω;`)

EDでもう一回泣いた。本編とEDが合いすぎ。

ではでは。またの機会に。

Leave a Comment

サックス練習 – 32 – リードを変えました。

ども。こんばんは。

昨日の会社帰りに、クロサワ楽器さんに行って、新しいリードとコルクグリスを買いました。

前回の記事で触れましたが、今までの3 1/2から3に変更しました。

Vandorenの青箱の2 1/2とWoodStoneの3はおじくらいの硬さみたいです。

サックスリード硬さの比較表

WoodStone AltoSax 3 ¥2,295(税抜き)←ネットで買うよりだいぶ安い
YAMAHA コルクグリス ¥412(税抜き)←ネットで買うよりちょっと安い

歴代リード

マメなので後ろに購入日が書いてあります。

で、今日は74回目の練習に。

目論見通り、やっぱり3のほうがあってますね。
今日は今までより下唇を噛みしめる強さも減って、疲れにくくなりました。

しばらくこのままですね。3 1/2も数枚余っててちょっともったいないですが。。。

ではでは。またの機会に。

Leave a Comment

CISMに挑戦してみる – 7 –

ども。こんばんは。

今日ようやくバッジと正式な認定証が届きました!

中身はこんな感じ。

バッジは磁石式・・・。

すでに、PDFではダウンロードできるようになっている認定証の原本?です。

もう一枚紙が入っていました。
おめとうがんばれ、的な。

 

最終的な受験〜合格〜認定まで時系列はこうなりました。

今月も月例会に参加します!

【バックナンバー】
参考にならないと思いますが、勉強方法などは3に記載しています。

ではでは。またの機会に。

Leave a Comment

令和になったことだしクラウドへ移行する – 10 – CloudFlare+Incapsulaの多段化はやっぱり無理

ども。こんばんは。

今日は連投ですね。

令和になったことだしクラウドへ移行する – 9 – t2.micro激重の原因とKUSANAGIのキャッシュの本気、CloudFlare+Incapsulaの多段化

にごちゃごちゃ追記したのですが、結論やっぱり無理です。

しばらくすると、IncapsulaでError Code 23になってしまいました。

その後、CloudFlareのCDNをoff(=DNS上、www.hits-net.comの解決結果がIncapsulaのCNAME)状態であれば通ります。

これを何度か再現テストして今の所再現率100%なので、やはり、IncapsulaのProxyは名前解決をちゃんと見ているのかもしれませんし、Free Planゆえのなにかかもしれません。

一応Error code 23の主要な原因はこれです。

https://support.incapsula.com/hc/en-us/articles/231496108-Grace-period-for-removed-sites
※24時間以内に同じFQDNを追加削除すると駄目だよっていう感じの話。

以下、完全に推測です。もしかしたら本当にIncapsulaがゴミ持ってるかもしれないし・・・。

上述の動作なら通常テストするときにhostsファイルに書いてアクセスしても同じことが起きるんじゃ?と思いますが・・・。

おそらくですが、hostsを編集した状態でアクセスしても、

元々のDNS(=Incapsulaが知っているDNS解決結果)と同じなら、通してくれる
※都度かどうかはわからないがIncapsula自身が名前解決をしている。これはoriginに対してではなく保護対象として登録したFQDNに対してと思われる。(OriginがCNAMEの場合はもちろん名前解決しますが、今回はOriginはIPアドレス直接指定なので)

のではないかと思います。

CloudFlareを前段に持ってきてCDNをOnにすると、IPアドレスの解決結果はあくまでCloudFlareです。

ということは、Incapsullaからすると、www.hits-net.comは、元々Incapsulaが最初にスキャンしたOriginのIPでもなく、Incapsulaが払い出したCNAMEでもない第3の「なにか(=ここではCloudFlare)」を解決してしまうことになります。
確かにこのパターンはそうそうないかも。

多分それが今回のError Code 23の原因かと。しばらくうまく行ったように感じるのは、CloudFlareのキャッシュが帰ってくるからかと思います。

CloudFlareのCDNをoffにすると割とすぐにError code 23はなくなります。(CloudFlareのTTLが300秒なので多分最大5分待てばいい。)

これCNAME Reuse使えれば話は違うんだろうけどなぁ。
OriginをCNAMEで登録したいなぁ。

もういいや、ということで、多段は諦めて、Incapsulaでキャッシュすることにしました。

【バックナンバー】

ではでは。またの機会に。

Leave a Comment

煙管はじめました

本記事は喫煙を推奨するものではありません。

以下タバコのパッケージ警告文(Wikipediaより)。


  • 喫煙は、あなたにとって肺がんの原因の一つとなります。疫学的な推計によると、喫煙者は肺がんにより死亡する危険性が非喫煙者に比べて約2倍から4倍高くなります。(詳細については、厚生労働省のホーム・ページ www.mhlw.go.jp/topics/tobacco/main.html をご参照ください。)
  • 喫煙は、あなたにとって心筋梗塞の危険性を高めます。疫学的な推計によると、喫煙者は心筋梗塞により死亡する危険性が非喫煙者に比べて約1.7倍高くなります。
  • 喫煙は、あなたにとって脳卒中の危険性を高めます。疫学的な推計によると、喫煙者は脳卒中により死亡する危険性が非喫煙者に比べて約1.7倍高くなります。
  • 喫煙は、あなたにとって肺気腫を悪化させる危険性を高めます。
  • 妊娠中の喫煙は、胎児の発育障害や早産の原因の一つとなります。疫学的な推計によると、たばこを吸う妊婦は、吸わない妊婦に比べ、低出生体重の危険性が約2倍、早産の危険性が約3倍高くなります。(詳細については、厚生労働省のホーム・ページ www.mhlw.go.jp/topics/tobacco/main.html をご参照ください。)
  • たばこの煙は、あなたの周りの人、特に乳幼児、子供、お年寄りなどの健康に悪影響を及ぼします。喫煙の際には、周りの人の迷惑にならないように注意しましょう。
  • 人により程度は異なりますが、ニコチンにより喫煙への依存が生じます。
  • 未成年者の喫煙は、健康に対する悪影響やたばこへの依存をより強めます。周りの人から勧められても決して吸ってはいけません。

 

ども。こんばんは。

何を思ったか煙管(キセル、きせる)を始めてみました。

過去に電子タバコのiQOSgloを始めたりしましたが、実は最近めっきり吸っていません。

結局紙巻きが一番かなと。

で、ちょっと先日新宿の紀伊国屋に立ち寄ったところ、面白そうなお店が。

喫煙具専門店 kagaya

おー、見たことない煙草、葉巻、Zippoライター、パイプ、煙管、お酒、雑貨・・・など、ちょっと大人心をくすぐるお店があるじゃないですか。

ということで、以前からちょっぴり興味のあったパイプか煙管を買おうかなと入ってみました。

パイプもたくさん並んでいたのですが、ちょっと吸うのが難しそうだったので、今回は煙管を買ってみました。

購入したのは、以下のもの。

店員さんと相談してとりあえず以下3つと、無水エタノールがあればいいんじゃないかということでした。
エタノールは過去に無線APの加水分解したラバーを剥がすのに買っていますので今回は買っていません。

・煙管本体(メーカ?とかはよくわからない。メタルの羅宇煙管) ¥2,600
・掃除用のモール ¥500
・小粋 ¥470

通常の羅宇煙管は、真ん中が竹みたいですが、これは全部金属です。
真鍮に銀メッキ?なのかな?

全部金属のものを延べ煙管と言ったりするようですが、これは一応羅宇があるので?羅宇煙管ですかね。
まだ勉強中です。

で、とりあえず一服しようかと思ったら・・・

葉が乾燥しまくっててパッキパキというか粉々になって、YouTubeとかで紹介されているように、丸めて詰めることができない・・・・。

ちょっと分かりづらいですが、つまむとバラバラと折れてしまいます。

吸えないこともないけど、リアルに一服したら燃え尽きちゃうよ。

全く知らなかったのですが、どうやら加湿してあげないと駄目らしいです。
湿気がダメそうなイメージですが・・・。

で、いいものがないかといろいろ調べて見たら、ヒュミドールというものがあるそうな。

よくよく考えるとサックス用のリードヴァイタライザーでも良さそうなんですよね。
#というか実際全く同じものを使っている人がいました。。。。

とはいえ、別の容器(タッパーとか?)に移し替えたりするのもの面倒なので、もっといいものないかなーと。

Amazonで売ってる↓が小粋の箱に入ってちょうどいいらしいという記事を見かけたのですが、

柘製作所(tsuge) ヒュミドール・アルミ・ブラック #77609 柘製作所(tsuge)

まぁ他に買うものもなく、これ一個買うのも・・・と思い、家から一番近い煙草の専門店に行ってみました。
※今後小粋を確保しなくてはならないので、そのへんの確認も兼ねて。

店員さんがとっても気軽に話を聞いてくれて、それなら、シャグ用(手巻きタバコ?なのかな)だけどこのヒュミストーンを使ってみたらどうだろう?というアドバイスをもらったので買ってきました。

左にあるのはついでに買ってきたパイプ用のコンパニオンです。
※火皿を掃除するのにいいかなーと思って買ってみました。

これを水につけて、2〜3分後に小粋の箱の入れて2〜3時間加湿すればいいかも?ということでした。

ただ、加湿しすぎるかもしれないので、様子見て、加湿しすぎなら出して、また加湿してと調整してみてください、ということでした。

ちゃんと入れた状態でも箱に収まる。

・・・。せっかく忠告をもらったのに、入れた状態でぐっすり寝てしまい・・・。

数時間後にあけてみると、ヒュミストーンのうらに若干こびりついてましたが、全体的にはもともとのカラカラ具合よりはしっとりしており、ちゃんと丸めることができるくらいの状態になっていました。

まぁ一応成功ということで・・・。

とりあえず形はそれっぽく吸えるようになりました。
いろんな方がブログやYouTubeに吸い方の動画をアップしているので参考にさせていただきました。

一つだけここでも紹介します。 

この方のように上手には吸えませんが、吸ってみての感想として・・・
普段がホープなので割とキツめなバタコに慣れているのか、煙管でもそんなにガツンとくる感じはない気がします。
※詰め方とかが下手なのかも。

ただ、一回の喫煙でのニコチンの摂取量が多い気がします。
※吸った後の次の喫煙までの時間が長い。

葉の湿度調整とか、道具とかいろいろこだわると楽しそうなので、ぼちぼちやってみたいと思います。

ではでは。またの機会に。

Leave a Comment

FortiOS v6.0.5 build0268 (GA)が出ていた

ども。こんばんは。

出てますねー。

上げました。最近比較的アップデートに失敗しないし、起動後のディスクチェックやれ!っていうのも出なくなりましたね。

 

リリースノート:

https://docs.fortinet.com/document/fortigate/6.0.5/FortiOS%20Release%20Notes/760203/introduction

これまだknown issueなの?さっさとなおしてくだいませー。
もはやバグのレベルなのか?という気がする。

Bug ID Description
435951 Traffic keeps going through the DENY NGFW policy configured with URL category.

 

6.2がもう出てるけど、うちの90Dには入らないし、本気でそろそろ50Eあたりに買い換えないと。

ではでは。またの機会に。

Leave a Comment

サックス練習 – 31 –

ども。こんばんは。

昨日は73回目の練習に行ってきました。

で、先日からGottsuのMetal HL(2018)を使っているのですが、ちょっと以前よりも下唇を押し付けている感じが強くなっていることに気が付きました。。

リードは以前から同じくWoodStoneの3 1/2です。

あと、練習不足なのもありますが、以前よりも口が疲れやすい気がしています。

で、昨日は試しに、サックス購入時に併せて購入したVandorenの2 1/2をGottsu Metal HLにつけてみたのですが、すごく吹きやすく感じ、口の疲れも少し減った気がします。

っということは、今のマウスピースとリードの組み合わせがあってないか、アンブシュアが悪いかですね。。。

音色?はWoodStoneのほうが好きな気がするので、WoodStoneの3を買ってみようかなぁ。

ではでは。またの機会に。

Leave a Comment

令和になったことだしクラウドへ移行する – 9 – t2.micro激重の原因とKUSANAGIのキャッシュの本気、CloudFlare+Incapsulaの多段化

ども、こんにちは。

前回の記事でt2.microのCPUクレジットを使い切って激重になった話を書かせていただきました。

んで、まぁ適当にKUSANAGIのnginxのログを解析していると・・・・

[root@kusanagi80 nginx]# zcat access.log-20190508 | awk ‘{ print $NF,$2,$3,$12,$10,$15,$16 }’ | sort | uniq -c | sort -rn | head -n 10
18840 “138.68.229.65” – – 200 /blog//xmlrpc.php “Mozilla/5.0 (Windows
(1位以下はすでに桁が全く違うので割愛)

どうもbot臭いのです。

「xmlrpc.php」へのアクセスを時間帯別に解析してみると、まぁ激重時間と大体一緒ですかね。

また、CdloufFlareがキャッシュしていなかったのも納得です。

[root@kusanagi80 nginx]# zcat access.log-20190508.gz |grep /blog//xmlrpc.php | awk ‘{ print $7 }’ | cut -b 2-15 | sort | uniq -c | sort -rn | head -n 10
4345 07/May/2019:17
4317 07/May/2019:16
4021 07/May/2019:18
3707 07/May/2019:15
541 07/May/2019:20
538 07/May/2019:19
519 07/May/2019:21
508 07/May/2019:22
345 07/May/2019:23
7 07/May/2019:12

ということで、CloudFlareで bot対策をしようと思ったのですが、無償だとGoogleなどのbotも止めてしまいそうです。

Before getting started

Cloudflare Firewall Rules can affect how traffic from known bots is handled. For details, see this FAQ.

ふむ。よろしい。ならばここに関しては無償のIncapsulaのほうが向いてるな。ということで、いつか失敗した多段に再挑戦します。

が、その前に、ちょっとKUSANAGIのbcacheとfcacheを設定してみます。

参考:詳解!KUSANAGIキャッシュ講座

で、うちの場合は、サブディレクトリにWordPressをおいていますので、まずはKUSANAGIのシェルを修正します。

まぁこの辺みながら雰囲気で。fcacheは早い話、nginxのリバースプロキシ機能でのキャッシュ、bcacheは動的に生成されるページを一定期間HTMLとして静的に保存する。両方組み合わせれば、bcacheで静的に生成されたHTMLをリバプロがキャッシュして返してくれると。

参考:KUSANAGIでサブディレクトリにWordPressを複数インストールする

で、onにします。

さて、実際効果はあるのかというところをちょっとテストしてみます。

WebPageTestで測ってみました。
※Tokyo, Japan – EC2 – Chromeで。

  • 旧オンプレサイト(CentOS Cpu 4コア/Mem:3GB)
    • https://www.webpagetest.org/result/190508_47_351c4d9104d0ca884007a289d9065993/
    • First Bytes 1.958s Fully Load 20.796s
  • 新サイト(AWS t2.micro) CloudFlareなし
    • https://www.webpagetest.org/result/190508_T5_c5f0471c39b6ab87f8c1434dd7518f10/
    • First Bytes 2.817s Fully Load 20.163s
    • 流石にCPU性能、メモリ性能では旧オンプレ環境に負けてるので遅いですね。
  • 新サイト(AWS t2.micro) + CloudFlare
    • https://www.webpagetest.org/result/190508_AR_24e95db4462d767499f2b0859ef05bed/
    • First Bytes 2.065s Fully Load 17.114s
    • お、早くなりました。これを基準にbcacheとfcacheを試していきます。
  • 新サイト(AWS t2.micro) + CloudFlare + KUSANAGI fcache
    • https://www.webpagetest.org/result/190508_4J_7b0928d6f924e8d4698b6753caeed8d1/
    • First Bytes 0.845s Fully Load 15.867s
    • おおー。確実に早くなりました。以下のようにF-CACHEにHITしたことがわかります。
  • 新サイト(AWS t2.micro) + CloudFlareなし + KUSANAGI fcache
    • https://www.webpagetest.org/result/190508_5W_8e0f63161b11d9fd14497d9f13b5a3b9/
    • First Bytes 0.588s Fully Load 18.046s
    • おー、CloudFlareなしfcacheオンリーだと、初速はめちゃめちゃ早いですね。
  • 新サイト(AWS t2.micro) + CloudFlare + KUSANAGI fcache + KUSANAGI bcache
    • https://www.webpagetest.org/result/190508_97_66422e4c559c1d51847abac508e88ba8/
    • First Bytes 0.892s Fully Load 15.231s
    • 初速は落ちましたね。けど、やっぱり他の静的コンテンツがCloudFlareのキャッシュから帰ってくるので、全体的なスピードはアップした、という感じでしょうか。
  • 新サイト(AWS t2.micro) + CloudFlareなし + KUSANAGI fcache + KUSANAGI bcache
    • https://www.webpagetest.org/result/190508_BD_ea283a342e16f40954704f80b313cff8/
    • First Bytes 0.614s Fully Load 18.451s
    • やはり初速は早いけど、全体的にはCloudFlareのCDNのほうが強いですね。
  • 新サイト(AWS t2.micro) + Incapsula(Static+Dynamicモード) + KUSANAGI fcache + KUSANAGI bcache
    • https://www.webpagetest.org/result/190511_A0_cda343e19da80c01960fe5d7d3c34170/
    • First Bytes 1.165s Fully Load 17.531s
    •  初速遅いけど判定は、Cですね。。
  • 新サイト(AWS t2.micro) + Incapsula(Static+Dynamicモード+Dynamic Content Acceleration(※)) + KUSANAGI fcache + KUSANAGI bcache
    • https://www.webpagetest.org/result/190511_R9_f82b1950e6e8f1b3d46e4dc9f0443109/
    • First Bytes 1.036s Fully Load 17.636s
    • Dynamic Content Acceleration機能です。今回はAWSのVPCがus-eastなので、アシュバーン?が最寄りでした。てか応答速っ。
  • 新サイト(AWS t2.micro) + CloudFlare + Incapsula(Static+Dynamicモード+Dynamic Content Acceleration(※)) + KUSANAGI fcache + KUSANAGI bcache
    • https://www.webpagetest.org/result/190512_KK_01657d85a38a8e24a91fbc0cc160285c/
    • First Bytes 1.033s Fully Load 13.971s
    • 初速ともにまぁまぁですね。一応両方ちゃんと通ってます。
      ※X-Iinfo: がNNNなので、Incapsulaのキャッシュはまだ効いてませんでした・・・けど、CloudFlareがHITしているので、結局AWSまでは取りには行ってないはず。
  • 新サイト(AWS t2.micro) + CloudFlare + Incapsula(Staticモード+Dynamic Content Acceleration(※)) + KUSANAGI fcache + KUSANAGI bcache
    • https://www.webpagetest.org/result/190512_M8_c66631c02506ebbda0a56be2d30fbda1/
    • First Bytes 1.312s Fully Load 14.404s
    • 一つ上とまぁ誤差ですね。
  • 新サイト(AWS t2.micro) + CloudFlare + Incapsula(キャッシュ無効+Dynamic Content Acceleration(※)) + KUSANAGI fcache + KUSANAGI bcache
    • https://www.webpagetest.org/result/190512_7E_1393ad66c4ae2ed3eb8490e5876edda1/
    • First Bytes 1.382s Fully Load 14.749s
    • 今これです。

ということで、初速は、CloudFlareなしで、KUSANAGIのfcacheが一番速い。
トータルは CloudFlare + Incapsula(Static+Dynamicモード+Dynamic Content Acceleration(※)) + KUSANAGI fcache + KUSANAGI bcacheが一番速いようです。

が、まぁ今回IncapsulaはBot制御目的ですし、2箇所でキャッシュ持つとややこしいので、キャッシュはCloudFlareだけにしました。

■CloudFlareとIncapsulaの多段構成について

多段構成のポイント?ですが、

Incapsulaを手前にすることは(おそらく無償版では)不可。
無償版IncapsulaはOriginにCNAMEが使えずIPアドレスしか使えない。

CloudFlareを前にする場合のポイント。(多分合ってると思う)

・CloudFlareに別のドメインを作ってそっちをIncapsulaに登録する
→同じ名前をCloudFlareとIncapsulaに存在すると以下のようなエラーになる。
※IncapsulaのProxyが名前解決したときに自分じゃない名前解決結果が来るから?と思われる。
→そんなことないです。それできなかったら導入前のhostsを使ったテストもできないので。(2019/05/26)

【2019/05/26 追記】

いろいろ間違ってます。普通にincapsulaにはwww.hits-net.comで登録してそのCNAMEをCloudFlareで向けつつCloudFlareのCDNを有効にすれば動きます。
↑のError code 23の原因にはサポートとも確認しましたが、結局わからずじまいで、なぜか今日改めて試したらうまくいきました。

CNAME reuseの機能を活用して、CloudFlareの本丸ドメインをCNAMEでIncapsulaに向ける。
→Incapsulaにはxxx.hits-net.comで登録してるけど、そこで払い出されたCNAMEをwww.hits-net.comに向けてさらにCloudFlareのCDNとDNSをオンにして、多段にしました。

 

■リダイレクトの初速を上げる

いま「/blog」へのリダイレクトは、cloudflareがやってる・・・と思う。

 

【2019/5/12追記】

何故かIncapsulaが時折古いオリジン(旧オンプレ)に転送してしまう謎現象が発生したので切り戻しました。
今はCloudFlareオンリーです。

このX.X.X.100っていまいま設定上どこにもないんですよねー。

同じドメインを何度か消したり入れたりしてるから一部のPoPにゴミ情報のこったかなぁ。

まいったなぁ。てかよく見たらCNAME Reuseって

Note: Available for Enterprise plan customers only.

あちゃー。

【2019/05/26 追記】
結局のところ、原因不明です。多分やっぱり古い情報持ってたとしか思えないですね。
上述の通りサポートともいろいろやりとりして、Incapsulaのサイト登録もやり直しましたが、結局原因不明で時間が解決したか、何らかのIncapsula側のメンテナンスで直ったとかそんな感じですね。

【2019/05/27 追記】
CloudFlareとIncapsulaの多段化はやはり無理でした。
令和になったことだしクラウドへ移行する – 10 – CloudFlare+Incapsulaの多段化はやっぱり無理

 

【バックナンバー】

ではでは。またの機会に。

Leave a Comment

令和になったことだしクラウドへ移行する – 8 – t2.microが激重になる

ども。こんばんは。

mariaDB問題は解決して、ようやく落ち着いたかと思ったら、今日はなぜかブログが激重になりました。。。

で、調べてみると、st(steal)が上昇していました。

今まで意識したことがなかったのですが、st値は、

【EC2】CPU使用率のsteal項目とは

馴染みがない項目だったのでで詳細を調べてみると、仮想サーバにおいて
「ゲストOSに処理を要求をしても、CPUリソースを割り当てられなかった時間の割合」
を意味するとのことです。

らしいです。で実際こんな感じでstが80%消費されており、実質20%しかCPUが使えない?状態のようです。

そりゃ重いわな。

AWSコンソールで、CPUクレジットを見ていると、クレジット使い切っちゃったみたいですね。

t2.microのCPUクレジットは144です。
※t3.microはほぼ値段一緒なのにCPUクレジットが多いんですよねー。やっぱt3にしたいなぁ。

バースト可能パフォーマンスインスタンスの CPU クレジットおよびベースラインパフォーマンス

とりあえず、インスタンスを再起動するとリセットされるようなのでその場しのぎですが再起動しました。

うーん。なかなかクラウドならではですねぇ。

これKUSANAGIのbcacheとか効かせたら処理減って軽くなるのかなぁ。とりあえず明日一日様子見ですね。

確かにちょっとアクセスおおかったのかなぁ。。。

 

【バックナンバー】

ではでは。またの機会に。

 

Leave a Comment

2019年 GWの振り返り

ども。こんばんは。

毎年恒例ですかね。

いろいろしましたが意外とグダグダでした。

  • 1日目(04/27):練習へ、ちょっと仕事した。
  • 2日目(04/28):寝てた。夕方仕事した。
  • 3日目(04/29):ゲームしてた。夜飲みに行った。(薬はちょっと控えてね)
  • 4日目(04/30):寝てた
  • 5日目(05/01):Office365移行
  • 6日目(05/02):練習へ
  • 7日目(05/03):寝てた
  • 8日目(05/04):Office365移行の続き
  • 9日目(05/05):ブログのAWS移行、図書館戦争見た
  • 10日目(05/06):AWS環境のトラブルシューティングした。図書館戦争の劇場版みた

今年は、連休前にちょっと仕事でトラブルががあって、そっちも気になってあんまり外出できませんでした。
※という言い訳。

ふと思い立って過去のGWを集めてみました。

今年は2012年以来の大規模インフラ更改だったかも

 

皆さんの10連休はいかがでしたか。

今日はお風呂にでもゆっくり浸かって。また明日から頑張って仕事しよ。

ではでは。またの機会に。

 

設定変えたの写真のアップロードテスト。

 

Leave a Comment

令和になったことだしクラウドへ移行する – 7 – t2.microでmariaDBが落ちる

ども。こんばんは。

昨日以降したAWS環境ですが早速トラブルです。

というかまぁ起きそうだなぁとは思ってましたが、メモリが足りずmariaDBが落ちてました。

[root@kusanagi80 blog]# more /var/log/mysql/mysqld.log

2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: The InnoDB memory heap is disabled
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Compressed tables use zlib 1.2.7
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Using Linux native AIO
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Using SSE crc32 instructions
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Initializing buffer pool, size = 384.0M
InnoDB: mmap(421724160 bytes) failed; errno 12
2019-05-06 10:23:26 140552243030272 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
2019-05-06 10:23:26 140552243030272 [ERROR] Plugin ‘InnoDB’ init function returned error.
2019-05-06 10:23:26 140552243030272 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
2019-05-06 10:23:26 140552243030272 [Note] Plugin ‘FEEDBACK’ is disabled.
2019-05-06 10:23:26 140552243030272 [ERROR] Unknown/unsupported storage engine: InnoDB
2019-05-06 10:23:26 140552243030272 [ERROR] Aborting

確かにちょいとメモリが足りないしswapがないんですよねー。

[root@kusanagi80 blog]# free -m

              total        used        free      shared  buff/cache   available
Mem:            989         678          73          76         237          81
Swap:             0           0           0

にいろんな方も同じ状況みたいで、swapを作る方法がありました。
t2.microでもssdだし、swap作っても大丈夫?かな。

参考:AWSのMySQLがよく落ちるのを解決 「Failed to start MariaDB」「InnoDB: Cannot allocate memory for the buffer pool」

手順は上記の参考サイトの通りですが、最後にfstabにも書きます(そうしないと起動時にswapがマウントされないので)

 

[root@kusanagi80 blog]# sudo dd if=/dev/zero of=/swapfile bs=1M count=1024

1024+0 レコード入力
1024+0 レコード出力
1073741824 バイト (1.1 GB) コピーされました、 35.3172 秒、 30.4 MB/秒

[root@kusanagi80 blog]# sudo mkswap /swapfile
スワップ空間バージョン1を設定します、サイズ = 1048572 KiB
ラベルはありません, UUID=81d4b5f0-bf32-4ea1-a3f5-3c4eaf7926a4
[root@kusanagi80 blog]# sudo swapon /swapfile
swapon: /swapfile: 安全でない権限 0644 を持ちます。 0600 がお勧めです。
[root@kusanagi80 blog]# sudo chmod 600 /swapfile
[root@kusanagi80 blog]# free -m

              total        used        free      shared  buff/cache   available

Mem:            989         670          83          76         235          92
Swap:          1023           0        1023

SWAPでけたー。仕上げにfstabに書いて、rebootしてswapできてたからokかな。

/swapfile swap swap defaults 0 0

さぁ、これで様子見ですね。

【追記】

また落ちました・・・。
2019年 GWの振り返り」の公開後、多分クローラーからのアクセスとかで落ちたっぽいです。
ロードアベレージが偉いことになってたのと、swapも結構浸かってしまってました。
参ったな。

以下ぱっと見た時のリソース。

こっからガッとswapへりました。多分mariaDB落ちたと思う。
※この手前でもしかしたらswap食い尽くしてたかも。

[root@kusanagi80 blog]# free -m

              total        used        free      shared  buff/cache   available
Mem:            989         857          66          10          65          12
Swap:          1023         620         403

top

top – 18:33:51 up  2:23,  1 user,  load average: 24.80, 14.64, 5.86
Tasks: 103 total,   1 running, 101 sleeping,   0 stopped,   1 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  1013192 total,   842544 free,    56472 used,   114176 buff/cache
KiB Swap:  1048572 total,   996736 free,    51836 used.   814284 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND  
9125 root      20   0  559436  23724  18016 S  0.0  2.3   0:00.04 php-fpm  
9130 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9131 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9132 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9133 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9134 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9135 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9126 httpd     20   0  559436   6808   1100 S  0.0  0.7   0:00.00 php-fpm  
9127 httpd     20   0  559436   6808   1100 S  0.0  0.7   0:00.00 php-fpm  
9128 httpd     20   0  559436   6808   1100 S  0.0  0.7   0:00.00 php-fpm  
9129 httpd     20   0  559436   6808   1100 S  0.0  0.7   0:00.00 php-fpm  
9106 httpd     20   0  126160   5240    908 S  0.0  0.5   0:00.00 nginx    
9107 httpd     20   0  124956   3680    856 S  0.0  0.4   0:00.00 nginx    
9108 httpd     20   0  124956   3680    856 S  0.0  0.4   0:00.00 nginx    
9105 root      20   0  124952   3004    392 S  0.0  0.3   0:00.00 nginx       
    1 root      20   0  191120   2496   1516 S  0.0  0.2   0:03.30 systemd  
9145 root      20   0  161880   2204   1564 R  0.0  0.2   0:00.00 top

ちょっと参ったな。swap2GBに増やしてみたので、これで様子見ですかねー。

 

 

【バックナンバー】

ではでは。またの機会に。

Leave a Comment

令和になったことだしクラウドへ移行する – 6 – ブログがAWSになりました。

ども。こんばんは。

件名のとおりです。

いろいろありつつ、半日でなんとか終わりました。

多分見れてるはず。です。

もちろんCloudFlare越しですが。

awsは12ヶ月無料枠のt2.microでKUSANAGIを入れました。
※KUSANAGIの推奨はメモリ4GB以上ですが、まぁこのくらいの規模なら全然余裕ですね。きっと。

ただ、KUSANAGIの全力は出てないと思いますが、前よりはキャッシュはCloudFlareのキャッシュも効いているはず。

疲れた。

途中経過は概ねログと画面キャプチャがあるのですが、もうありふれた話ばかりなので今回はポイントだけを自分用にメモです。

  • AWS
    • 普通にセットアップ、管理者のMFAを有効にしたくらい
    • あと一応請求が$10超えたらメール来るようにしてみた。
    • VPC
      • リージョンは最安で米国東部(バージニア)
        • どうせCloudFlare通すしきっといい感じになる。。。とおもう。
      • アベイラビリティゾーンはus-east-1f
    • EC2
      • インスタンスはt2.micro
        • 本当はt3にしたかったが、AMIのKUSANAGIが対応していなかった
      • Elastic IP一つ取得
    • KUSGANAGI
      • とりあえずyumで諸々アップデートしてから設定
      • php7だとうちの古めかしいvistaテーマが動かない&諸々エラーが出たのでphp5.6に戻した(kusanagi initやりなおし)。
      • サブディレクトリにWordPressを展開しているので多分効いてないKUSANAGIの機能がある気がする。
      • bcacheを効かせるには、多分以下の設定いれればいけるかも?
      • てか、KUSANAGIってそれ用のWordPressプラグインあるっぽいけどそのへんよくわかんない
      • あと、サブディレクトリに入れた関係か多分Let’s Encryptちゃんと動いてないと思う。
    • 引っ越しの仕方
      • BackWPupプラグインでファイルもDBの抜こうとしたが、旧環境だとPHPが2GB以上のファイルをP扱えなくてエラー(PHPバージョンで扱えない大きさのアーカイブになります。)でアーカイブがコケまくったので諦めた。
        • 一応古いPHPで2GB以上のファイルが扱えないことはないが再コンパイルなんて今さらやってられないのでスルー。
      • wp-contents配下をtgzで固めてscpでゴリゴリコピーした。
      • KUSANAGIのデフォルトのドキュメントルートをまるまる「/blog」にコピーしてwp-contentsだけ上書き。
      • DBはBackWPupで抜いたものをmysqlコマンドでどーん。
    • 心残りというか明日以降確認
      • KUSANAGIのサブディレクトリ化もう少し見直す
      • SSL化する?(Cloudflareの機能でもいいかも)
      • キャッシュのテスト
      • メールでDBのバックアップ飛ばしてるけど、多分動かないだろうなぁ。
      • ちと、ポートスキャンとか外部からのアクセス確認をば。セキュリティグループはしっかり作ったはず。
      • Google Analyticsとか大丈夫だと思うけど、明日確認
    • いずれやりたい
      • せっかくAWSのアカウント作ったし、BackWPupはS3にバックアップ取れるので、バックアップの方式を検討する

そんなところかな。

【追記】

やっぱりへんだなぁーと思ってたらやりがちなことをやってしまっていた。
参考:KUSANAGIに移設する際の5つの手順をまとめてみた

ここでの注意点は移設先のwp-content内にあるmu-pluginsを削除してしまわない事。
よくあるのがwp-contentをリネームしてまるっと置き換える方法。これやっちゃうとKUSANAGI用のオリジナルプラグインがなくなっちゃいますので、リネームしたディレクトリから移しておきましょう。

KUSANAGI用のオリジナルプラグインはWordPressの高速化の一端を担っています。
多言語に対応したWordPressが日本語で表示できるのは当たり前ですが、この翻訳が管理画面なども遅くする原因にもなっています。ですので、翻訳ファイルをキャッシュしてしまうことでWordPressの高速化を図っています。

なせ、オリジナルプラグインなのか。それはWordPressのコアを修正したりしないためです。
良く勘違いされるのがKUSANAGIで導入されたWordPressはチューニング(改造)されていると言う間違いですね。これやっちゃうとバージョンアップできなくなるので絶対やりません。

 

これで、Azure、Office365、AWSとGCPもちょっとだけ(AIY Voice Kitで)やったので、主要なクラウドには手が広げられたかなぁ。

以下画像アップロードテスト。

連休中に、メールとWebのクラウド化が無事完了したε-(´∀`*)ホッ

これで、なんと我が家のFWでは外部→内部を処理するルールがなくなってしまう&監視するものがなくなってしまう。。

それはそれで少しさみしいですね。
とはいえ、まだオンプレでもいろいろやりたいことはあるかなー。

【バックナンバー】

ではでは。またの機会に。

Leave a Comment

令和になったことだしクラウドへ移行する – 5 – Exchange Server 2010 to Office 365(4)

ども。こんばんは。

気づけばもう連休もあと1日半です・・・。

昨日はずっと寝てたのと、今日も夕方まで寝てしまったので、さっさと続きをやります。

とりあえず、前回の残タスクの通り、ライセンス節約のため個人メールボックスを共有メールボックスに変換します。

やり方はこんな感じ。

ユーザー メールボックスを共有メールボックスに変換する

  • 変換するユーザーメールボックスには、共有メールボックスに変換する前に割り当てられたライセンスが必要です。 そうでない場合、変換オプションがメールボックスに表示されません。ライセンスを削除した場合、メールボックスを変換するために再度それを戻す必要があります。 ライセンスは、メールボックスを共有に変換した後に、ユーザー アカウントから削除できます。
  • 共有メールボックスは、ライセンスなしで、最大 50 GB のデータを保持することができます。 これ以上のデータを保持するには、ライセンスを割り当てる必要があります。 ライセンスを削除するには、(添付ファイルがあるものなど) 大きなメールを多数削除してサイズを小さくする必要があります。
  • 古いユーザー アカウントは削除しないでください。 それは共有メールボックスの固定に必要です。 ユーザー アカウントを既に削除している場合、「削除済みユーザーのメールボックスを変換する」 (削除されたユーザーのメールボックスを変換する) を参照してください。

ポイントとしては、上記の3点ですね。特に3つ目。読んでなかったら確実に消してたわ。

【追記:やらかした】
やかしました。多分大丈夫ですが、上記のサイトの下の方にこんなことが書いてあります。
もしかしたら、またユーザメールボックスに戻される・・・のかも???うーん・・・。まぁいっか。
強くお勧めするならもっと上に書いておいてほしかったです。。。

ハイブリッド環境でユーザーのメールボックスを変換する

この共有メールボックスがハイブリッド環境にある場合は、ユーザーのメールボックスをオンプレミスに戻して、ユーザーのメールボックスを共有メールボックスに変換してから、共有メールボックスをクラウドに戻すことを強くお勧めします。

その理由は次のとおりです。クラウド内のメールボックスを変換すると、そのメールボックスは変換されますが、新しい現実はオンプレミスに同期されないため、オンプレミスではメールボックスがユーザーのメールボックスであると見なされます。

通常、これは問題ではありませんが、オンプレミスの属性 (メールボックスがユーザーのメールボックスであると考えられる) が新しいクラウドバージョンの属性を上書きする可能性があるため、その結果、メールボックスの変換が行われる場合があります。 ユーザーメールボックスがライセンスを必要とするか、30日後に削除された場合は、この問題が発生します。

これが発生する理由のほとんどが解決されましたが、これはまだ発生する可能性があります。 安全にして、メールボックスをオンプレミスに戻すことをお勧めします。

あと、やっぱりいきなり契約せず評価ライセンスではじめてほんとに良かった。移行するにしてもライセンスが最初は必要になるんですね。

ちなみに、ちゃんと ハイブリッド構成にしたおかげて?権限も移行できてるので、ちゃんとメインで使う予定のユーザは他のメールボックスを開くことはできます。(フルアクセセスを与えており、ちゃんと引き継がれた。さすがハイブリッド!)

でもやりたいのはこうじゃないし、それぞれのボックスの所有者でログインしたり、それぞれの予定表を作る予定もなく、あくまで、システム通知やSNS系のメールの受け用のボックスがほしいのです。

参考:オンプレExchange時代の運用

で、後悔しないように改めてこちらの記事も読んでみました。うん、今回はやっぱり共有メールボックスが正しい・・はず!

参考:Office365「共有メールボックス」とは

■ユーザメールボックスを共有メールボックスに変換する

早速やってみます。

Exchange管理センターから該当メールボックスをポチッと。

はいはい。

即効でおわります。数秒。

この時点では、ライセンスを停止してない?ので、まだ元のメールボックスの所有者でログインしてOWAでメールが見えるっぽいですね。

もう一つ変換対象があるので、そっちも同様の手順でやります。(10GBくらいあるボックスだったのですが、2分くらいで終わりました。)

無事共有に変換できました。

とりあえず、OWA上で追加してみる。

メインのアカウント上で自分の名前を右クリックして「共有フォルダーの追加」をクリックします。

あとは選ぶだけ。(「他のメールボックスを開く…」と要領は同じですね。)

最終的にこんな感じになりました。

とりあえず、送受信テストしてみます。

あれ、差出人が共有メールボックスにできないですねー。

うーん。フルコントロールなんだけどなー。

一応権限つけてみました。

だめですねー。候補に出てこない。

念の為、「他のメールボックスを開く…」でやってみたところ・・・・

このメールボックスからメッセージを送信するためのアクセス許可がありません。

えー。うそんフルコンやし、ちゃんと送信する権限もつけたけどなー。反映に時間かかるのかなー。

まぁいいわ。別に。そのうちなんとかなるでしょう。「メールボックス所有者として送信する」の権限は必須ぽいので。

ちょっと先に進めます。

■ライセンスを剥奪して、サインインも禁止する!

これで、共有メールボックス化が無事できたので、旧ユーザからはライセンスを剥奪します。
あと、サインアップ時に作った「.onmicrosoft.com」もライセンス剥奪してみます。

また、ADから引っ越してきたユーザはパスワードがボロい可能性も大いにあるので、サインインも禁止します。

さらばライセンス。

ちなみにいいかどうか知りませんが、onmicrosoftのアカウントもライセンス剥奪しました。

これで、ライセンスを持っているのは1人のみになりました。

ちなみにライセンスを剥奪したユーザでログインしてみました。

おー、空っぽですね。

で、一応今回ADと同期してはいますが、余計なユーザはOffice365にサインインできないようにしてみます。
※onmicrosoft,comのユーザは念の為、ライセンスは剥奪しましたが、サインインは可能にしてあります。もちろん別で全体管理者は設定済み&サインアップ時の連絡先は、ライセンス付与済みユーザにしています。

 


【2019/05/05 追記】

勢い余って、Azure AD Connectに必要な同期用ユーザまでサインイン禁止にしてしまったみたいです。

なので、「Sync_[サーバ名]_[ランダム?]@hitsnetcom.onmicrosoft.com」はサインインを有効にしてあげたら治りました。

これでsyncしたら、ブロックしたユーザまたサインイン許可に戻ってしまった・・・

うーん。やっぱりAD側でログイン無効化して同期させるのが正しいんだろうけど、やだなーこれ。課題ですね。

 


 

 

で、サインイン禁止したユーザで入ってみたところ。
※てかID・PWの確認はできてしまう気がする。。。。。。

↑これは反映中だったみたいです。しばらくするとこうなります。

とはいえ、アカウントの存在とパスワードが正しいことはバレちゃいますねこれ。まぁいいか。。

Azureも一緒にかわるっぽい?(←もともとこのユーザサインインできてたか未確認です)

さぁ、だいたいできた。

■正規のライセンスを買って割り当てる

まだ評価期間は残っていますが、このっている今だからこそ正規版を買います。
※そしたら、何かあっても、最悪評価版に割り当て直して調査できる猶予がある!はず・・・。

いきなり1年契約でかいます。

住所とかを入れます。

年間¥6,998です。

何故かシークレットモードのブラウザだと手順3にいけませんでしたのでやり直し。。。

支払い方法を入れます。

かいましたー。

無事追加。

ライセンスを割り当て直します。

試用版をoffにして購入した方をonにします。

個別の機能でのon/offもできるんですね。

できましたー。

ちゃんとライセンス数が更新されていますね。

一応請求書などのメール連絡先も確認します。
予定通り、追加しておいた全体管理者が有効になっており、onmicrosoftの方の連絡先メールアドレスもライセンスのあるユーザになっています。
これならonmicrosoftにはライセンスなくても大丈夫・・・だと思います。

おまけ。ライセンス変更前後のサインイン後の画面。
ちょっとへりました。

■仕上げ:DNSレコードの変更(外部向け)

さて、ここまででもう準備は終わったのでいよいよDNSレコードの向き先を変えます。

とりあえず、CSVでエクスポートもしていたのですが、MXとCNAMEをいれます。

途中の画面を取り忘れましたが、チェックする機能があります。
終わったら確認を押すと以下のようにOKになります。

管理のドメインから状況が確認できます。
おっと、一つカスタムドメインのDNS設定が漏れていましたね。困りはしないのですが一応いれます。

使うサービスを選びます。(これによって向け先に出てくるレコードが変わるみたいですね。Exchangeなら基本MXとautodiscover用のCNAMEとSPFだけとか。)

Exchangeだけえんだので、3つだけです。
※ただし、見切れてますがこの画面上にあるエクスポート機能でエクスポートすると全サービス分のレコードがCSVででてきます。

はい。おわりました!

ちなみに今回SPFレコードは、Office365に加え、自宅の固定IPアドレスも残しています。
それでもチェック結果はOKだったので問題ないと思われます。

■仕上げ:DNSレコード+Postfixのtransportの変更(内部向け)

ここからは内部向けの話なので、関係ない人はここまでで晴れてOffice365ユーザとして利用可能になります!

さて、うちの場合は、

内部DNSサーバのMXレコード修正と、内部用メールをtransportでオンプレExchangeに向けている部分を修正します。

ありふれた手順なので省略します。reloadとかpostmapとか忘れないでね。

ということで、経路がこうなりました。
(この辺ももうリプレースしないとですね。)

内部サーバ->オンプレExchange->ハイブリッド構成->o365

内部サーバ->o365
※ここはTLSにしたいところだけど、面倒くさいのでやめました。

ちなみに、これは主に内部サーバのシステム通知系なので、自ドメイン以外には送信しません。
※内部ですけど、外から来るメールと同じ扱いにしました。

【メモ】
Zabbixの通知先に携帯キャリアメールが入っている。今はオンプレPostfixにSMTPを向けているがこれをo365に変更するときは、うちでも設定が必要。
各種サーバは全体的にSmartRelayでo365にむけないとなぁ。

なので、o365用のMXレコード宛に送りつけるだけです。自ドメイン以外の外部に送る場合は、認証がいるはずです。

この辺を参考にしてみてください。

Office 365 を使用してメールを送信するように多機能デバイスまたはアプリケーションをセット アップする方法

※昔は性的なグローバルIPアドレスを認証条件にできたけど、いつからかTLSで証明書入れるの必須にならなかったけ。

さて、あとはインターネットからメールサーバ宛の25/tcpを閉じれば終わりですね。

TTLも300だしもうとっくに伝播したと思いますが、一応旧メールサーバのmaillogを流しながら、全アドレスにテストメールを送信して、旧サーバに回っていないことを確認しました。

というかこの時点でもまだ、差出人が共有メールボックスにできないです。この記事を書いている間に数時間経過したのですが・・・。まぁそれは別の課題で。。。

ということで、一旦終わりです。

あとは細かなタスクとして・・・

  • macOSのメールアプリで共有メールボックスにアクセスする
  • 古いサーバのメールの向き先変更(snmptrapのメール変換とかもそろそろやめたい・・・)
  • Zabbixの通知メールサーバ変更(宛先にキャリアメールが入っているので注意)
  • 各種アプライアンスのメール通知先とか見直し

そんなところかな。あーWebサーバの移行できるかなぁ。

【バックナンバー】

ではでは。またの機会に。

Leave a Comment