10年くらい運用していたデザインも古さを感じてきたことと、最近のデバイスの解像度に合わせて、デザインをリニューアルしました。
色々やらなければならないことは山積ですが、細々と更新を続けていきます。
既存メールサーバとOffice365のExchange Onlineを共存利用する方法（独自ドメインによるメール利用）
Office365を導入する際、ライセンスコストや互換性の問題により、Exchange Onlineで直接メールの送受信を行うのではなく、既存のメールサーバ(SMTP)を利用してメールの送受信を行いたいというケースが、少数かもしれませんがあるかと思います。
そのような場合は、管理はやや手間となりますが、以下の方法で既存のメールサーバを活かしながらExchange Onlineを利用する（既存メールサーバとExchange Onlineを共存利用する）ことが可能です。
概要
以下は、既存メールサーバがさくらインターネットのさくらのレンタルサーバである場合の例です。なお、既存メールサーバは次項の前提条件を満たしていれば、どのようなメールサーバでも対応可能です。
上記に示している内容としては、次の通りです。
- 受信メールサーバは、既存メールサーバ（レンタルサーバ等）を利用します
- 送信メールサーバは、Office365からメールを送信する場合はExchange Onlineを利用します（Office365以外からメールを送信する場合は既存メールサーバを利用）
- 既存メールサーバで受信されたメールを、Office365のデフォルトドメイン（<テナント名>.onmicrosoft.com）へ転送します
前提条件
- レンタルサーバ等の既存メールサーバ（Office365以外）が存在すること
- 既存メールサーバにはメール送受信可能なユーザーが存在すること
- 既存メールサーバは外部（ドメイン外）へのメール転送に対応していること
- Office365にOutlook(Exchange Online)が利用可能なユーザーが存在すること
- Office365のOutlook利用ユーザーとして、既存メールサーバ上に存在するユーザーと同一人物となるユーザーが存在すること（１対１で各サーバに存在すること）
- DNSサーバは、任意のレコード追加に対応していること（例えば、さくらのレンタルサーバの場合は、NSをさくらインターネットに移譲していないこと）
- 作業者は、既存メールサーバ、Office365両方の管理権限を保有していること
手順
1.ドメインを追加する
Microsoft 365管理センターを開き、[設定]-[ドメイン]をクリックし、「ドメインの追加」をクリックします。
ドメイン追加後、所有者確認のため、DNSサーバへTXTレコードの追加を求められますので、画面の指示に従い対応します。
所有者確認が完了すると、以下の画面が表示されますので、「独自のレコードを追加する」をクリックします。
以下の画面が表示され、DNSサーバへのレコード追加を指示されますので、CNAMEレコードとTXTレコードのみ、DNSサーバへ追加します。
※MXレコードは、DNSサーバへ追加しません。（追加しないでください！！）
なお、SPFレコードについては、次のとおりとします。（Office365と、既存メールサーバ両方をSPFレコードに含めます）
"v=spf1 include:spf.protection.outlook.com ip4:<既存メールサーバのIPアドレス> ~all
上記DNSレコード追加後、「戻る」をクリックし、以下の画面より「スキップして後で行う」を選択し、「続行」をクリックします。
2. 各ユーザーに対して、独自ドメインのメールアドレスを割り当てる
Exchange管理センターを開き、「受信者」をクリックします。
一覧よりユーザーを選択し、編集アイコンをクリックします。
「メールアドレス」をクリックし、＋をクリックします。
メールアドレス（独自ドメインのメールアドレス）を入力し、「このアドレスを返信アドレスに設定する」をチェックします。
設定完了後、「OK」をクリックします。
以後、同様に各ユーザーの設定を行います。
3. 現在利用中のメールサーバ側でメール転送設定を行う
既存メールサーバ側で、既存メールサーバへ届いたメールを、Office365のデフォルトドメイン（<テナント名>.onmicrosoft.com）の各ユーザーへ転送するため、メール転送設定を行います。
さくらインターネットのさくらのレンタルサーバの場合は、コントロールパネルへログイン後「メールアドレスの管理」をクリックすることで、各ユーザーのメール転送設定を行うことができます。
以上の設定を行うことで、既存メールサーバを活かしつつ、Exchange Onlineで独自ドメインによるメールを利用することができるようになります。管理は手間となりますが、よろしければご参考ください。
Ubuntu 20.04LTSでAWS EC2のNATインスタンスを構築する
前提条件（事前準備）
基本的には、やることは以下の内容(Ubuntu 18.04LTS)と変わりません。 www.tabimoba.net
- Ubuntu 20.04LTS がインストールされたEC2インスタンスを用意します。
- インスタンスタイプは最初はt2.nanoやt2.micro(あるいはt3,t3a系の同等タイプ)で問題ありません。（パフォーマンスが出ない場合は、上位のインスタンスタイプへ変更します）
- ストレージは8GB（デフォルト）で十分足ります。
- 無くても動きますが、必要に応じてSWAPも追加します。
- NATインスタンスを配置するVPCサブネットに関連付けられたルートテーブルの
0.0.0.0/0には、インターネットゲートウェイをアタッチしておきます。 - EC2インスタンスの「送信元/送信先チェック」を無効にします
sysctl.confの設定
IPv6の無効化と、IPフォワーディングの有効化を行います。
# echo "net.ipv4.ip_forward = 1 >> /etc/sysctl.conf" # echo "net.ipv6.conf.all.disable_ipv6 = 1" >> /etc/sysctl.conf # echo "net.ipv6.conf.default.disable_ipv6 = 1" >> /etc/sysctl.conf # sysctl -p
iptablesの設定
NAPT(IPマスカレード)の設定を行います。
最初に、iptablesの設定永続化のために、iptables-persistentをaptインストールします。
# apt update && apt install -y iptables-persistent
次に、以下のコマンドを実行します。
iptables -t nat -A POSTROUTING -s <IPv4 CIDR> -j MASQUERADE
<IPv4 CIDR>には、VPC全体のIPアドレス範囲を、IPアドレス（ネットワークアドレス）/サブネットマスク（マスクbit数）で指定します。例えば、10.0.0.0/16というVPCが存在する場合は、それを<IPv4 CIDR>として指定します。- NATインスタンス経由で通信させたいサブネットを限定したい場合は、AWSマネジメントコンソールのVPCダッシュボードの「ルートテーブル」で次の通り設定を行います。
- 「ルート」で、送信先を
0.0.0.0/0、ターゲットをNATインスタンスのEC2 インスタンスIDとするルートを追加します。 - 「サブネットの関連付け」で、 NATインスタンス経由で通信させたいサブネットの関連付けを行います。
設定完了後、iptablesに正しく設定されたことを以下のコマンドを実行して確認します。
# iptables -t nat --list
あわせて、他のインスタンスより、NATインスタンス経由で通信が行える（インターネット側のリソースにアクセスできる）ことを確認します。
最後に、以下のコマンドを実行し、設定を保存します。
# service netfilter-persistent save
Wired日本語版の記事を読みやすくするChrome機能拡張「Wired Nomalizer」
Wired日本語版の記事は、編集部のポリシーなのか、編集者が意識高い系なのかわかりませんが、カタカナの単語が独特で読みにくい問題があります。サーヴィスとか、プライヴァシーとか、イノヴェイションとか。この読みにくさは何とかしたい。
そんなこと思っていたら、「Wired Nomalizer」というChromeの機能拡張がありました。
これを利用することで、サーヴィスや、プライヴァシーや、イノヴェイションは、サービス、プライバシー、イノベーションになり、一般人にとって読みやすい文章に変換してくれます。Wired日本語版が読みにくくて辛いと感じていた方に是非お勧めします。
現在進行系で世の中で起こっている事柄から思い浮かんだ映画作品
復活の日
56年前の小説（映画化は1980年）ですが、新型コロナウイルスが流行し始めた際にまず最初に思いついたのがこの作品です。復活の日に出てくる殺人ウイルスや、殺人ウイルスの全世界への流行は、現代のコロナウイルスを想起させるものです。
AKIRA
www.youtube.com www.netflix.com
37年以上前の漫画（映画化は1988年）ですが、2020年の東京オリンピック開催が「予言」されていました。（実際のオリンピックは延期が決まりましたが）
AKIRAのストーリーに出てくる「ネオ東京」のような混沌とした世界も、アキラもナンバーズ（超能力を持った実験体の成長が止まった子どもたち）も、現実世界に現れることはありませんが、AKIRAに出てくるシーンの中には、東京オリンピック以外にも想像させられるものが様々あります。
シン・ゴジラ
www.youtube.com www.netflix.com
シン・ゴジラに出てくる「巨災対」のシーンではリアルな行政の姿が描かれています。
以下にまとめられた内容に出てくる厚労省の新型コロナウイルス対策本部の風景を見ると、まるで「巨災対」です。シン・ゴジラは、特撮怪獣映画として見ると内容はとても薄い（期待はずれな）感じでしたが、視点を変えて行政のリアリティを徹底的に示した映画として見ると、興味深く見ることが出来ると思います。
Qiitaから記事を移行しました。
手作業で移行を行おうとしましたが、途中で断念して先人たちの知恵を利用しました。
画像とカテゴリ対応、Qiita→Blogへの移行先案内は、これからぼちぼち行います。
Qiitaの記事を順次移行します。
タイトルの通り、徐々にQiitaから本Blogへ記事を移行していきます。
最近Qiitaでは、以下の問題が話題となりました。
最近のQiitaは「俺の作った最強のシステム」的な危うさや、「こんな機能作った俺すごい、どや」的な意識高い系エンジニアや、内輪の自己満足でサービスがリリースされている雰囲気があります。
もちろんその機能がユーザーのメリットに寄与するものであるならそれでも良いでしょう。しかし、逆にユーザーのセキュリティやプライバシーなどを危険に晒したり、ユーザーに不信感を与えるものとなっています。また、このような機能がそのままリリースされたことに不安を感じました（誰も疑問に感じなかったの？チェックしなかったの？という点で）。
これまでも、「いいね」が「LGTM」になった時に若干の違和感を感じていましたが、今回の件により、安心してQiitaを使い続けられないし、これ以上Qiitaを使い続けるのは難しいと感じました。
ということで、ぼちぼち移行を進めていきます。ご不便をお掛けしますが、よろしくお願いいたします。
ようやくAOSSL対応完了
久しぶりのBlog投稿となります。
はてなブログのAOSSL（サイトの常時SSL化）対応がものすごく面倒で放置していました。（あとは公私ともに多忙を極めていたというのも）
APIを利用して、はてなブログのMixed Content対応や文字列置換を簡単に行えるツールがあったので、それを使って対応しました。非常にありがたい。
smdn.jp
ということで、これまで「保護されていないコンテンツ」と表示されていた問題も解消され、本日から本BlogもAOSSL対応です。
あとは、10年くらい前から変わらないこのレイアウトを近々変えたいと思います。
jQuery+Colorboxでaタグ無しで画像のモーダル表示を実現する簡単な方法
※Qiitaからの移行記事となります
画像のモーダル表示のためにLightbox系のライブラリの使い方を検索してみると、モーダル表示したい画像のimgタグをaタグで囲むようなものばかりが検索結果として出てきます。
しかし、CMS等の環境の制約によりaタグでimgタグを囲めない場合や、メンテナンス効率の低下を避けるためにaタグでimgタグを囲みたくない（aタグとimgタグの両方をメンテナンスしたくないし、それ以前に入力が面倒なのでやりたくない）場合があると思います。
そのような場合は、JavaScriptで画像(img)のクリックイベントを取得し、クリックされた画像のsrcを取得し、その値をColorboxのようなモーダル表示時に表示させる画像のリンク先（パス、URL）を指定可能なライブラリへ受け渡すことで、imgタグをaタグで囲むことなく、画像のモーダル表示を行うことができます。
※事前にjQueryとColorboxのファイル一式を用意（アップロード）しておきます。
<script src="/lib/jquery/jquery.min.js"></script> <script src="/lib/jquery/jquery-migrate.min.js"></script> <script src="/lib/colorbox/jquery.colorbox-min.js"></script> <link rel="stylesheet" href="/lib/colorbox/example4/colorbox.css" media="all"> <script type="text/javascript"> $(document).ready(function() { $("#content img").css("cursor","pointer"); $("#content img").click(function() { $.colorbox({href:this.src}); return false; }); }); </script>
関連URL
PHPでmkdir時に4桁のパーミッションを文字列型の変数の値より指定するには
※Qiitaからの移行記事となります
PHPのmkdir関数でディレクトリを作成する際に8進数4桁のパーミッションを指定する場合、mkdir関数の第2引数へ
mkdir('/var/dat/hogefuga', 0755, true);
のような形で指定することで、0755(rwxr-xr-x)というパーミッションのディレクトリが作成されます。
変数でセットする場合も、
$perm = 0755;
mkdir('/var/dat/hogefuga', $perm, true);
とすることで、上記と同様のパーミッションでディレクトリを作成することができます。
しかし、変数が文字列型である場合、例えば
$perm = '0755';
mkdir('/var/dat/hogefuga', $perm, true);
である場合、0755(rwxr-xr-x)とならず（例えば、-wxr---tのようになり）、意図したパーミッションとならない場合があります。
変数が文字列型であるケースとしては、Webシステムから送信された値や、DBやAPI、ファイル等から取得した値を使用するケースが挙げられます。
原因
文字列型の値は、10進数の数値として扱われます。つまり、0755(8進数)ではなく、755(10進数)として扱われます（先頭の0は無視されます）。 これにより、意図したパーミッションでディレクトリを作成することが出来ません。
対応
octdec関数で文字列型を8進数の整数へ変換することで、この問題を解消することができます。
<?php $perm = '0755'; $mydir = '/var/dat/hogefuga'; mkdir($mydir, octdec($perm), true);