今更ながら HP Proliant Microserver Gen7 を使う

個人的にまだ何台か使っているのでメモ。

ハードウェア

メモリは DDR3 PC3-10600 ECC DIMM 4GB x 2 で計 8GB が最大とされているけれど、 ECC なしの DDR PC3-12800 DIM 8GB x 2 で計 16GB でも大丈夫。但し相性問題があるらしく認識しないメモリもある。

非力な CPU のサーバだけどメモリ 16GB だといろいろ使えて便利。

remote access card

firmware

最新の firmware 1.4 はここ : https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX_d9b60d684ae24ba5a15a951389&swEnvOid=4168

java 設定

https://www.java.com/ja/download/ から最新の JAVA JRE (執筆時点で Version 8 Update 211) を入手してインストール。

「コントロールパネル → JAVA → セキュリティ → 例外サイト」に remote access card の URL を登録。

最近の JAVA は remote access card の KVM の通信で使われる暗号に対応しなくなったので、 C:\Program Files (x86)\Java\jre1.8.0_211\lib\security\java.security をメモ帳で開いて

#jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
#    EC keySize < 224, 3DES_EDE_CBC, anon, NULL

の2行をコメントアウト

ブラウザ対応

remote access card は Microsoft EdgeInternet Explorer では普通にアクセスできるけれど、 Firefox ではログイン画面から先に進めないという不具合があった。

Firefox のプライベートウィンドウからアクセスするとこの問題を回避できる。

OS 対応

Windows 10

Windows 10 では Radeon HD4200 のサポートが終了していて、 legacy ドライバをインストールしても 標準ドライバで上書きされてしまう。ややトリッキーな方法で対処することもできるみたいだけど、 リモートからアクセスしない用途で使うので放置。

おまけ

Windows でランダムに生成される IPV6 アドレスの使用を止めるには、

netsh interface ipv6 set global randomizeidentifiers=disabled

EUI-64で生成される固定したアドレスにしておかないと外からアクセするのに不便。

Outlook 2016のメール設定の移行

個人的なメモ

Microsoft Office 2016以降のOutlookでは、Microsoft Exchangeサーバへの接続設定が自動検出だけで手動設定ができなくなっている。自分が管理者ではない環境で自動検出がうまくできない場合は、PCを再インストールするなど環境を移行する際にいちいち管理者を呼んで設定してもらう必要があって面倒。

以下の手順で既存のPCのOutlookの設定を他のPCに移行できる。

  1. レジストリの HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Profiles\Outlook 以下をを新しい環境にコピー
  2. C:\Users(username)\AppData\Local\Microsoft\Outlook 以下のファイルを新しい環境にコピー
  3. C:\Users(username)\Documents\ にあるOutlookの .pst ファイルを新しい環境にコピー

ドメインを安全に廃止するには

前回の記事で旧山梨医大が使っていた 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 ExplorerGoogle 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 を維持し続けた方がよかったのではないかと考えます。

www.asahi.com

最近の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時間運用しても問題なくなり、FreeBSDapachesendmailといった外向けサービスと内向けのsambaを動かすサーバとして使うだけになった。 もう10年以上FreeBSDGUI環境は作っていないし、自分が管理している範囲内では X関係のライブラリさえ入れないようにしている。

Microsoft OfficeGUIな環境を使う分にはWindowsは非常に快適だけど、外向けサーバを 運用したり細かく使い込んだりするにはシステムの根幹部分から理解できているFreeBSDの 使い勝手の良さが際立つ。最近だとZFSRAIDを組んだり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 してみるかな。