Outlook 2016のメール設定の移行
個人的なメモ
Microsoft Office 2016以降のOutlookでは、Microsoft Exchangeサーバへの接続設定が自動検出だけで手動設定ができなくなっている。自分が管理者ではない環境で自動検出がうまくできない場合は、PCを再インストールするなど環境を移行する際にいちいち管理者を呼んで設定してもらう必要があって面倒。
以下の手順で既存のPCのOutlookの設定を他のPCに移行できる。
ドメインを安全に廃止するには
前回の記事で旧山梨医大が使っていた yamanashi-med.ac.jp ドメインが アダルト業者に取得されかけた話を書きました。 motoyuki.hatenablog.jp
では、使わなくなったドメインを廃止するにはどういう手順を踏むべきなのか、 先日の飲み会で聞いた話をまとめてみました。
1. 1～2年程度、新しいドメインへ転送する。
いわゆるホームページのサーバ (WWWサーバといいます) には、別な場所に移動したことを 知らせる機能があります。山梨大の例でいえば、旧山梨医大のサーバ www.yamanashi-med.ac.jp にアクセスがあった際に、山梨大学医学部のページ http://www.med.yamanashi.ac.jp/ に移動したという情報を返すように設定します （専門用語でいうと HTTPステータスコードの301 Moved Permanentlyを返すようにします）。
Internet ExplorerやGoogle ChromeなどのWebブラウザは、自動的に移動先のページを表示します。 前の記事で挙げた例でいうと、横浜医療センターの旧ドメイン http://www.yokohama-mc.com/ のアクセスは https://yokohama.hosp.go.jp/ に転送されています。
メールには移動を知らせる機能はありませんが、古いドメインのメールアドレス宛に届いた メールを新しいメールアドレスに転送する設定が可能です。
2. ドメインを使わない状態で、ドメイン名の権利だけ10年程度保持する
インターネットドメインとは、www.yamanashi-med.ac.jp のような名前をサーバの場所（IPアドレス） に変換する仕組みです。この変換の情報を消去すると www.yamanashi-med.ac.jp ではどこにもアクセス できなくなります。
でも、インターネットの世界のあちこちに「山梨医大は yamanashi-med.ac.jp を使っている」 「山梨医大のサーバ www.yamanashi-med.ac.jp にある情報へのリンク」が残っています。 ドメイン名の権利を放棄してしまうと、別の業者がドメイン名を取得して ニュースになったような困った事態になってしまいます。
これを避けるには、ドメイン名を使わない状態でドメイン名の権利だけをある程度の期間 保有し続ける必要があります。10年くらい経過すれば「山梨医大は yamanashi-med.ac.jp」という 情報は（少なくともよく使われる情報・資料からは）ある程度消えることが期待できます。
旧山梨医大のホームページにアクセスすると風俗サイトに、という話
（某所に書いたことの再掲です）
yamanashi.ac.jp や yamanashi-med.ac.jp といった名前はインターネットドメインといいます。管理している業者に定期的（1年単位など）にお金を払うことで確保できます。権利者がお金を払わず放棄したら、先着順で誰でも取得できます。数万円程度なので、風俗サイトを同じ名前で運営されても文句は言えません。
今回の場合、 ac.jp というドメインが日本の大学専用（正確には専門学校も含む）で、新たに取得した人が大学ではなかったので日本の .jp というドメインの大元を管理している団体 （JPRS）の裁定で無効にできたようです。
大学や医学関係でインターネットドメインを独自に取得してネットに情報公開しているところは多くあります。例えば、私が初期研修1年目を過ごした国立病院機構横浜医療センターは以前 yokohama-mc.com を使っていました。それが yokohama-mc.jp を使うようになり、今では yokohama.hosp.go.jp を主に使っているようです。このうち .go.jp は日本の政府機関専用ですが、 .com と .jp は誰でも取得できるドメインなので横浜医療センターが権利を放棄して（あるいは更新手続きを忘れて）第三者に取られてしまうと取り戻せません。
世界には更新されなかったドメインを取得してアダルトサイトを開設する業者が山のようにいます。元の権利者がそれなりの額のお金を払って買い戻してくれるのを期待しているのです。
ということで、一度取得したインターネットドメインの権利は使わなくなっても権利を保持し続けたほうがよい（継続費用は年1万円程度です）というのが結論です。以前使っていたドメインの権利を維持していれば、そのドメインの名前へのアクセスを今使っているものへ自動的に転送することは簡単にできます。例に挙げた横浜医療センターもそうしています。
追記: 旧山梨大と旧山梨大が合併して(新)山梨大になり yamanashi-med.ac.jp ドメインが不要になったというのがこの話の最初です。本来であれば ac.jp ドメインは1法人1ドメインしか保持できませんが、合併による特例が適用されて2002年の合併から最近まで yamanashi-med.ac.jp を維持していたようです。
今回のケースでは yamanashi-med.ac.jp ドメインを入手したのが大学でも専門学校でもなかったので無効にできたようですが、山梨という人が「学校法人山梨医療専門学校」を設立して yamanashi-med.ac.jp を申請したとしたら阻止するのは非常に難しくなります。混乱を避けるためにも山梨大は yamanashi-med.ac.jp を維持し続けた方がよかったのではないかと考えます。
最近のFreeBSDと私
力武 健次氏の さよなら、愛しのFreeBSD が話題なのに触発されて少し書いてみる。
私がFreeBSD関係でいろいろやっていたのは、今の仕事についた2004年4月の前の話なので 既に10年以上経過した計算になる。その前に書いた原稿が掲載された号を最後に 創刊当時から関わってきたASCIIのBSD Magazineが廃刊になった。
FreeBSD関係の活動で知り合った方々との交流は続いているし、つい先日もそうしたメンバーで 3泊4日で長野にスキーに行ってきたばかりなのだけど、基本的には一人のユーザとしてFreeBSDを 使うだけになった。FreeBSD.orgのコミット権限もかなり以前に返上してしまった。
サーバ目的以外ではMicrosoft Windowsしか使わなくなった。Windowsも昔は不安定で、 FreeBSDでデスクトップ環境を構築することに魅力を感じた時代があった。そうした時期には 自分がFreeBSDで快適に生活できるようにportsを整備したりドキュメントを書いたりといった 活動をしていた訳だけど、Windows XPが出た頃からそうしたモチベーションは薄れてきた。
Windows 7では家で録画サーバを24時間運用しても問題なくなり、FreeBSDはapacheや sendmailといった外向けサービスと内向けのsambaを動かすサーバとして使うだけになった。 もう10年以上FreeBSDでGUI環境は作っていないし、自分が管理している範囲内では X関係のライブラリさえ入れないようにしている。
Microsoft OfficeやGUIな環境を使う分にはWindowsは非常に快適だけど、外向けサーバを 運用したり細かく使い込んだりするにはシステムの根幹部分から理解できているFreeBSDの 使い勝手の良さが際立つ。最近だとZFSでRAIDを組んだりsnapshotで過去のファイルの履歴を 追えるようにしたりするストレージ系の機能が便利に感じる。
一例を挙げると、私の職場ではWindows PCばかりでファイル管理が問題 （ハードディスクの故障によるデータ損失や誤消去など）になっていたので、 昔流行したHPのMicroServerを持ち込んでFreeBSDでファイルサーバを組んだ。 USBメモリから起動するハードディスク2台のZFS mirrorな構成。 最初はFreeNASなどを試してみたのだけど、結局FreeBSDでsambaをpkgで 入れるだけという超簡単な構成が一番楽だしトラブルの際の対処も簡単。
そんな感じでFreeBSDを少しずつ使い続けている。
stunnel + DeleGate でトンネルを掘る
某所は外に出るのにport 80と443だけを通すproxy serverがあるという環境なのだが、 これまでは仙石浩明氏の stone を使ってSSHで外に出るトンネルを 掘っていた。 前の記事 でも書いたようにstoneが最近のOpenSSLに追従できていない状態なので、 別な方法でトンネルを掘ろうと試してみた。
DeleGate
壁の外のサーバでpkgでdelegateをインストールして、
/usr/local/sbin/delegated -P127.0.0.1:1080:__1:1080 SERVER=socks ADMIN=my@address.jp > /dev/null 2>&1
で起動する。これでDeleGateがport 1080で待ち受けるSOCKSサーバになる。
stunnel
stunnelでトンネルを掘る。
鍵作成
OpenSSLで鍵を適当に作成。
% openssl genrsa -aes256 -out ca.key 2048 % openssl req -new -key ca.key -out ca.csr -subj "/CN=TestCA" % openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt -days 9999 % openssl genrsa -aes256 -out server.key 2048 % openssl req -new -key server.key -out server.csr -subj "/CN=test.example.com" % openssl x509 -req -CA ca.crt -CAkey ca.key -set_serial 1 -in server.csr -out server.crt -days 9999 % openssl genrsa -aes256 -out client.key 2048 % openssl req -new -key client.key -out client.csr -subj "/CN=TestClient" % openssl x509 -req -CA ca.crt -CAkey ca.key -set_serial 2 -in client.csr -out client.crt -days 9999 % openssl rsa -in server.key -out server-nopass.key % openssl rsa -in client.key -out client-nopass.key
壁の外のサーバ
/usr/local/etc/stunnelに先ほど作成したca.crt server-nopass.key server.crtの3つを置き、
chown root:wheel ca.crt server-nopass.key server.crt chmod 400 ca.crt server-nopass.key server.crt mkdir /var/run/stunnel chown stunnel:stunnel /var/run/stunnel
/etc/rc.confに以下を追加
stunnel_enable="YES" stunnel_pidfile="/var/run/stunnel/stunnel.pid"
/usr/local/etc/stunnel/stunnel.conf
cert = /usr/local/etc/stunnel/server.crt key = /usr/local/etc/stunnel/server-nopass.key CAfile = /usr/local/etc/stunnel/ca.crt setuid = stunnel setgid = stunnel chroot = /var/run/stunnel pid = /stunnel.pid socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 verify = 2 debug = local1.notice [SOCKS over SSL] accept = 443 connect = 1080 TIMEOUTclose = 0
SOCKSで待ち受けるport 1080はlocal addressのみにbindしているので危険はあまりないが、 stunnelが待ち受けるport 443は攻撃を防ぐためにfirewallを適宜設定しておく。
壁の中のサーバ
/usr/local/etc/stunnelにca.crt client-nopass.key client.crtの3つを置き、
chown root:wheel ca.crt server-nopass.key server.crt chmod 400 ca.crt server-nopass.key server.crt mkdir /var/run/stunnel chown stunnel:stunnel /var/run/stunnel
しておく。/etc/rc.confに追加する内容は壁の外のサーバと同じ。
/usr/local/etc/stunnel/stunnel.conf
cert = /usr/local/etc/stunnel/client.crt key = /usr/local/etc/stunnel/client-nopass.key CAfile = /usr/local/etc/stunnel/ca.crt debug = local1.notice verify = 2 options = NO_SSLv2 sslVersion = TLSv1 setuid = stunnel setgid = stunnel pid = /stunnel.pid chroot = /var/run/stunnel [socks_over_ssl] client = yes accept = 1080 protocol = connect protocolHost = 壁の外のサーバ:443 connect = 壁のfirewall:port
stunnelのログはsyslogのlocal1ファシリティに出力されるので、/etc/syslog.confを適宜修正しておく。 これで、壁の中のサーバのport 1080をSOCKSサーバとして指定すれば外に出ることができる。
ports/net/stone が build できない
ports/net/stoneが最近のFreeBSDでbuildできない。
調べてみると、FreeBSD 12からOpenSSLが1.1に上がった関係で壊れたようだ。原因はいくつかあって、 1つはOpenSSL 1.1ではSSLv2対応が削除されているので-DOPENSSL_NO_SSL2を定義する必要がある。
もう1つはOpenSSL 1.0までは /usr/include/openssl/ssl.hの中で
struct ssl_session_st {
int ssl_version;
unsigned int key_arg_length;
などとssl_session_stの構造体のメンバが定義されているが、OpenSSL 1.1以降ではこれがなくなっている。 stone.c 2455行付近の
if (Debug > 2) {
char str[SSL_MAX_SSL_SESSION_ID_LENGTH * 2 + 1];
int len = sess->session_id_length;
int i;
if (len > SSL_MAX_SSL_SESSION_ID_LENGTH)
len = SSL_MAX_SSL_SESSION_ID_LENGTH;
for (i=0; i < len; i++)
sprintf(&str[i*2], "%02x", sess->session_id[i]);
str[i*2] = '\0';
message(LOG_DEBUG, "%d TCP %d: SSL session ID=%s len=%d",
p2->stone->sd, p2->sd, str, sess->session_id_length);
}
で構造体のメンバsession_id_lengthを参照しようとしているのでエラーになっている。ここは 構造体のメンバを直接参照するのではなく、SSL_SESSION_get_id() を使うように書き換えればいいはず。 単純に動かすだけなら、この部分全体をコメントアウトしても大丈夫（デバッグメッセージを出力 する部分なので）。
最後の一つは3270行付近、
if (Debug > 7)
message(LOG_DEBUG, "%d TCP %d: SSL_accept ret=%d, state=%x, "
"finished=%x, in_init=%x/%x", pair->stone->sd,
sd, ret, SSL_state(ssl), SSL_is_init_finished(ssl),
SSL_in_init(ssl), SSL_in_accept_init(ssl));
でSSL_state()が使われているので、これはSSL_get_state()に書き換える必要がある。 面倒であればこちらもこの部分全体をコメントアウトするだけでいい。
という感じに修正すると手元では無事動いた。余力ができたら久しぶりにsend-pr してみるかな。
hatena blog
hatenaはサービス開始当初に motoyuki という id が取れなかったので少し敬遠していたのだけど、 http://motoyuki.hatenablog.jp/ というのが確保できたので試してみる。
