「ブログのこと」カテゴリーアーカイブ

令和になったことだしクラウドへ移行する – 14 – KUSANAGIのバージョンアップとfunctions.sh(2)

ども。こんばんは。

以前も記事にしたサブディレクトリでkusanagiを動かす場合に修正が必要な/usr/lib/kusanagi/lib/functions.shですが、kusanagi-8.4.3-3くらいからいじる箇所が増えたみたいです。

これをしないと一部kusanagiコマンドが「WordPress がインストールされていません。何もしません」という表示になります。

以下、8.4.4-2対応版です。

168,169c168,169
< elif [ -e $TARGET_DIR/DocumentRoot/wp-config.php ]; then
< WPCONFIG=”$TARGET_DIR/DocumentRoot/wp-config.php”

> elif [ -e $TARGET_DIR/DocumentRoot/blog/wp-config.php ]; then
> WPCONFIG=”$TARGET_DIR/DocumentRoot/blog/wp-config.php”
1718c1718
< [ -e $KUSANAGI_DIR/DocumentRoot/wp-config.php ] || [ -e $KUSANAGI_DIR/wp-config.php ] || return

> [ -e $KUSANAGI_DIR/DocumentRoot/blog/wp-config.php ] || [ -e $KUSANAGI_DIR/wp-config.php ] || return
1785,1786c1785,1786
< if [ -e $KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins/wp-kusanagi.php ] && \
< [ -e $KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins/kusanagi-wp-configure.php ]; then

> if [ -e $KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins/wp-kusanagi.php ] && \
> [ -e $KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins/kusanagi-wp-configure.php ]; then
1788c1788
< local MU_PLUGINS_DIR=”$KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins”

> local MU_PLUGINS_DIR=”$KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins”

動作okっぽいですが、修正は自己責任でお願いします。

# kusanagi bcache
bcache は有効です
完了しました。

# kusanagi update plugin
KUSANAGI プラグインは、既に最新バージョンです。
KUSANAGI 設定プラグインは、すでに最新バージョンです。
完了しました。

【バックナンバー】

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

令和になったことだしクラウドへ移行する – 13 – KUSANAGIのバージョンアップとfunctions.sh

—-
2019/11/02追記
8.4.3-3 あたりから修正箇所が増えているようです。

令和になったことだしクラウドへ移行する – 14 – KUSANAGIのバージョンアップとfunctions.sh(2)
—-

ども。こんばんは。

このブログはkusanagiで動いています。

8.4.3-1が出ていたので更新しました。

で、見ての通りサブディレクトリにkusanagiをインストールしています。

なので、kusanagiのバージョンアップとかをしたときにちょっとした設定の書き換えをしないとこうなります。

# kusanagi update plugin
プラグインファイルが存在ません。何もしません。
完了しました。

# kusanagi bcache
WordPress がインストールされていません。何もしません
完了しました。

という感じになります。

で、以下のファイルを修正。

/usr/lib/kusanagi/lib/functions.sh

# diff functions.sh.bak.20190728 functions.sh
166,167c166,167
< elif [ -e $TARGET_DIR/DocumentRoot/wp-config.php ]; then
< WPCONFIG=”$TARGET_DIR/DocumentRoot/wp-config.php”

> elif [ -e $TARGET_DIR/DocumentRoot/blog/wp-config.php ]; then
> WPCONFIG=”$TARGET_DIR/DocumentRoot/blog/wp-config.php”
1761,1762c1761,1762
< if [ -e $KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins/wp-kusanagi.php ] && \
< [ -e $KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins/kusanagi-wp-configure.php ]; then

> if [ -e $KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins/wp-kusanagi.php ] && \
> [ -e $KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins/kusanagi-wp-configure.php ]; then
1764c1764
< local MU_PLUGINS_DIR=”$KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins”

> local MU_PLUGINS_DIR=”$KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins”

これで動くようになります。

【バックナンバー】

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

ブログのテーマを変えました。

テーマ変えてみましたー。

前のテーマはVistaliciousってやつで、確かWordPressに移行したときから使ってるはずです。

モバイル対応もしてなかったのでちょうどいいかな。

長年使ってるテーマだったので、手でカスタマイズしてた部分もある気がするけど、もういいや。

最低限Google Analyticsとかはプラグインでやってるから大丈夫だろう。。。

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

令和になったことだしクラウドへ移行する – 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

【バックナンバー】

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

令和になったことだしクラウドへ移行する – 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でキャッシュすることにしました。

【バックナンバー】

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

令和になったことだしクラウドへ移行する – 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に増やしてみたので、これで様子見ですかねー。

 

 

【バックナンバー】

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

令和になったことだしクラウドへ移行する – 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では外部→内部を処理するルールがなくなってしまう&監視するものがなくなってしまう。。

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

【バックナンバー】

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

令和になったことだしクラウドへ移行する – 1 – 全体方針

ども。こんんばんは。

今日から新元号「令和」となりましたね。

ということで、いい加減に我が家の老朽化したシステムたちを10連休後半で移行していきたいと思います。

  • 方針
    • クラウド移行対象
      • メール
        • 既存のExchange Server 2010をOffice365に移行する
      • ブログ
        • AWS EC2へ移行する
    • クラウド移行対象外
      • 監視サーバ(Zabbix)
      • ActiveDiretory
      • PBX(FreePBX)
      • ファイルサーバ
    • その他: NASもそろそろいい加減にリプレース
      • NASをリプレースし、移行しないオンプレシステムは原則コンテナで構築しなおし
        ADだけは、無線の802.1xなどもあるので、そのへんを鑑みて、AzureADで対応できるか今後調査。
        最悪FreeRADIUSとかをコンテナで・・。
      • ファイルサーバも廃止しNASのネイティブなSMB、CIFSなどに統合する
    • クラウド移行済み
      • 外部向けDNSサーバ
        • CloudFlareに移行済み

さて、それぞれですが、以下の理由により選定しました。

  • Office365:既存のExchangeからリプレースしやすそう。メールボックスはEACから移行できるっぽい。
  • AWS
    • 最初はAzure App ServiceもしくはAzureのVMを検討、ただAzureはまぁなんやかんや仕事でも使うので、あんまり触っていないAWSに挑戦してみることにする。
      すでにAzure上にはSentinelやVMが動いてるし。。
    • AWSだとLightsailがお得だと思うが、それならさくらとかのVPSとかと変わらない・・・と思うので、ちゃんとEC2を立ててみることにする。
    • GCPのAlways Freeも検討しましたが、割とチューニングしないと重くて動かなそうです。
    • その他wpXとか、mixhostとかも良さそうなんだけど、今回は勉強も兼ねてAWSですね。

ただ、ちょっと問題が早速ありそうで、macOSの標準メールだと、Exchange上の共有メールボックスがおそらく開けないと思われます。(IMAPなら行けるという記事も:APPLE MAILでOFFICE365の共有メールボックスの設定)
※WindowsのOutlookなら、それぞれのメールボックスに権限を付けるだけで勝手に見えるようになります。

過去、同じ問題に対処していますが、結局オンプレExchangeなのでボックスごとにユーザを割り当てて、複数アカウントを管理する形で逃げています

ところが今度はクラウドなのでそのやり方をすると、おそらくユーザが複数になるかと

参考:Macネタ – 2 –Macネタ – 4 –

Office 365 E1(¥870/ユーザ、アプリなし)か、Office 365 Business Premium(¥1,360/ユーザ、アプリあり)か悩みますね。

もちろんExhchage目当てにE1にするくらいなら、Buisiness Eessential(同じくExchangeくらい)で、もっと費用を落とす手もありますねぇ。

BusinessとEnterpriseうーん・・・

比較参照情報

うーーーーん。やっぱりデスクトップ版のoutlook必要かー?まぁメインのメールボックスさえ開ければあとはOWAでもいいかなぁ。

macOS標準メールでも行けそうなきがするなぁ

Adding Office 365 Shared Mailbox in Mac Mail

んーーー!!!

訴訟ホールドとかいらんし、300人超えることもありえなし、Buisines Essentialsでいいかな!

駄目だったらプラン変更すればいいし!どうせE3は変えないんだからビジネスでいいや!

ということで、次からメールの移行を始めたいと思います。

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

 

 

2018-2019年末年始振り返り、最近のこと、ブログ15年目。他。

ども。こんばんは。

すっかり年も明けて、気づけば成人の日も終わってしまいました。
1/11でこのブログも15年目に入りました。なんだかんだ続くもんですね。

では、ちょっと最近のことを書きたいと思います。

■風邪でダウン(2018/12/17-18)

風邪でダウンしました。
インフルエンザではなかったようです。

■鈴木みのりファーストアルバムが届く(2018/12/18)

【1stアルバム『見る前に飛べ!』みのり隊オリジナルセット】です!
ファンクラブ限定でリストバンド付き!やっぱりCrosswalkいいわー。

■加湿空気清浄機導入(2018/12/23、2018/12/29)

散々悩んで購入しました。
というのも、先般の風邪も乾燥が原因じゃないか?ということで・・・。

で、とりあえず加湿機だけを買うか、加湿空気清浄機を買うかいろいろ悩みました。
Amazonのクリスマス?年末?セールで、シャープのプラズマクラスターの加湿空気清浄機の型落ちが安いようだったので、せっかくならと、シャープの加湿空気清浄機に絞っていろいろ比較して購入しました。

シャープの加湿空気清浄機は、大きくKIシリーズとKCシリーズにがあります。
KCシリーズはプラズマクラスター7000を搭載、KIシリーズは一つ上の機種でプラズマクラスター25000を搭載します。
※本当は除湿もできる除加湿空気清浄機(KC-HD70の1機種のみ)も検討したのですが、値段が4万円ほどと割高で、サイズも大きいようなので諦めました。

んで、その後のアルファベットで製造年、数字でサイズ(対応する部屋の広さ)になっています。

今回購入したのは、KI-GS50というモデルの黒色です。

以下開封〜使い捨てプレフィルター取り付けの様子。

使い捨てプレフィルターって両面テープでくっつけるのですが、これちょっとダサいよね。。



KIシリーズで、Gなので、2016年モデルのプラズマクラスター25000搭載モデルという感じです。
※2017年モデルならKI-HS50、2018年モデルならKI-JS50という感じです。Hの次はIじゃなくてJに飛んだみたいですね。

同じ2016年モデルで、KC-G50がAmazonで¥17,800ととてもお買い得だったのですが、あえてひとつ上の機種のKI-GS50を¥21,800で購入しました。

以下KI-GS50とKC-G50の比較。
http://www.sharp.co.jp/support/air_purifier/lineup/kigs50_kcg50_spec.html
http://www.sharp.co.jp/kuusei/lineup/2016.html
ポイントにしたのは、KIにはホコリセンサーがついていることと、大きさがスリムなこと、プラズマクラスター25000が搭載さていることです。

で、実は罠があって、プラズマクラスター25000は、1日24時間運転だと約2年でユニット(¥3,000くらい)交換が必要ですorz
プラズマクラスター7000には必要無いようです。。。なので、本体も割高な上にランニングコストも高い方を選んでしまいました・・・が満足です。

レビューという程でも無いのですが、使った感想を。
・本気だすとうるさい。おまかせ運転だと温度にわわせて湿度を調整してくれます。
室温24℃だと、湿度33%くらいにしようと頑張るのですが、湿度が1%減るだけで、全力運転になります。。。。
全力で回ると掃除機ばりにうるさいです。
夜は照明を消すと勝手に静かに運転してくれるので、夜中も回してますがそこは大丈夫でした。
※まぁ一応心配だったので先に1台だけ買って、夜中試して問題ないかを確認して買い足しました。

・加湿力は・・・正直550ml/hですが、これって前述の通り、全開フルパワーなので、正直どうなんでしょう。。。あんまりガンガン加湿してくれてる感じはしないです。けど、確実に湿度は上がってるかなぁというくらいですね。

・湿度の表示がちょっとずれる?実際の湿度より低い気がします。(センサーの場所のせいかな?)
温度は割と手元の温度計とあってますが、例えば手元の湿度計で40%あるのに、表示上は33%くらいだったりします。

・給水タンクの強度が不安・・・。取っ手がちょっと安いっぽいです。。水の量はうちの大きさだと問題ないかな。あんまり広い家ではないし。

結論、夜中中エアコンの暖房をつけっぱなしにしても、朝方喉が痛いことは無くなりました。

■恒例の年末年始振り返り(2018/12/28-2019/1/6)

毎年グダグダな年末年始の振り返りです。


・12/28 有給休暇。通院、ヨドバシカメラで空気清浄機用の延長コードなどを購入

・12/29 特に何もせず、2台目の加湿空気清浄機の設置とか、グランツーリスモとか。

・12/30 サックスの練習納め

・12/31 大掃除、ガキ使を最後まで見る

エアコンのフィルターも頑張った。


・1/1 新年会
今年は冷凍おせちを頼みました!日テレポシュレの和洋中おせち3人前(¥12,100(送料込み))です。
サイズも4人で食べるのにちょうどよく、美味しかったです。


・1/2 ダウン

・1/3 ゴロゴロとAmazon Primeで映画を見る

・1/4 有給休暇。廃人。

・1/5 EWIの練習をしたりした。

・1/6 PSYCHO-PASSを新編集版〜2期〜劇場版の順で全部みた。

〜仕事始め〜

・1/12-14 物語シリーズをdアニメストアで全部みた。

・1/14 結局Kindle Unlimitedは解約(キャンペーンで3ヶ月¥299だった。)

 ■FortiOS v6.0.4 build0231が出ていたので更新(2019/1/20)

更新しました。
以下リリースノート

http://help.fortinet.com/fos-rn/6-0-4/Content/FOS_RN/0200_Introduction.htm

久々に問題なくアップデートできて一安心。

known issueにとんでもない一言ありますね。これもうNGFWモードやめようかな。

Bug ID

Description

435951

Traffic keeps going through the DENY NGFW policy configured with URL category.

Bug ID

Description

480003

FortiGuard category does not work in NGFW mode policy.

 

まぁそんな感じの年末年始でした。

以下、とりとめのないことをつらつらと。

実はまだサックスの練習始めをまだしていないのです。。
なんか、成人の日の三連休もグダグダとしてしまい、今週もグダグダと・・・。

なんか最近週末に全然元気が出ないですねー。
それと、最近寝起きに腰がめちゃくちゃ痛いんです。

パニック障害の方も良くなりつつあるのですが、まだ完治には時間がかかりそうです。

 

そういや、WordPress 5.0のエディタが鬼のように使いにくいので、結局Classic Editorなるプラグインを入れてしまいました。。

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