オタク日記
(Mac と Linux, 2016Q2)

目次

2016-06-11 (Sat): Let's Encrypt の Certificates を更新
2016-05-28 (Sat): Apple Support 讃……
2016-05-07 (Sat): 宅外サーバの Ubuntu をリリース版に……
2016-04-27 (Wed): ISP を乗換える

古い日記:
2016Q1  
2015Q4   2015Q3   2015Q2   2015Q1   2014Q4   2014Q3  
2014Q2   2014Q1   2013Q4   2013Q3   2013Q2   2013Q1  
2012 年   2011 年   2010 年   2009 年   2008 年   2007 年  
2006 年   2005 年   2004 年   2003 年   2002 年   2001 年


2016-06-11 (Sat): Let's Encrypt の Certificates を更新

Certificate を expire させてしまった

Let's Encrypt の front-end である SSLなう! さんのところのアプリ?を利用して、certificate を作製したのが約 3 ヶ月前。 なんやかやで、更新を先延ばしにしているうちに、とうとう expire させてしまったようだ……port 587 で、posting ができなくなって気がついた。

「コマンド一発で renew できるので、有効期間を 90 日と短く設定してある」というのをどこかで読んだが、どうやら、「SSLなう!」 で取得したのでは、そう簡単には renew できないようだ。 それでも、ややこしいヘルプを読むよりは、 もう一回「SSLなう!」でやってみようか、という怠け心が起きたが、 一方で、次からはコマンド一発で renew できたら嬉しいという、怠け心 2 が湧いてきて、結局 Let's Encrypt (LE) のツール (クライアント) にチャレンジしてみる事にした。

LE のクライアントを使うのはやはり面倒

なんと日本語の Let's Encrypt 総合ポータルなんてものができている。 コマンドも、letsencrypt-auto から certbot-auto に変わっていて、 随分新しくなっている印象。よし、とばかり意気込んで作業を始めるが、 「ややこしさ」は減ってなくて、すぐに「訳わか」になってしまった……

長い話を短くすると

というややこしさ。

だから、という事でもないが、今回やった事を一応纏めておく。 とりあえずの前提条件と選んだ選択肢は:

でやってみる事にした。こう書くと長いようだが、筋道さえ通ってしまえば、 躓きそうなところは多くない。
fukuda@digoc02:~% sudo nano /etc/apache2/sites-available/000-index.conf  #1)
fukuda@digoc02:~% git clone https://github.com/certbot/certbot
fukuda@digoc02:~% cd certbot
fukuda@digoc02:~/certbot% ./certbot-auto certonly --webroot \  #2)
    -w /var/www/html/ -d www.otacky.jp -d imap.otacky.jp -d smtp.otacky.jp \
    -w /var/www/waremo-html -d www.waremo.com 
fukuda@digoc02:~% sudo ls /etc/letsencrypt/live/www.otacky.jp
cert.pem  chain.pem  fullchain.pem  privkey.pem 
fukuda@digoc02:~% sudo nano /etc/apache2/sites-available/000-index.conf  #3)
fukuda@digoc02:~% sudo nano /etc/postfix/main.cf                         #4)
fukuda@digoc02:~% sudo systemctl reload postfix
fukuda@digoc02:~% sudo systemctl reload apache2
で OK。 ここに、
  1. #1) Apache の Virtual Host 以外のホスト (例えば、 imap.otacky.jp 等) で用いる場合は、
    <VirtualHost *:80>
            ServerName www.otacky.jp
            ServerAlias imap.otacky.jp
            ServerAlias smtp.otacky.jp
        ....
    などとして、一時的にhttp://imap.otacky.jp/var/www/html にアクセスできるようにしておく。
  2. #2) option で、webroot_1, hostname (複数可), webroot_2, hostname (複数可) のように指定する。 但し、hostname_i は DNS で名前解決できないといけない。 また、このコマンドを起動すると (結構崩れた) 擬似 GUI 画面が表われるが、 上記の webroot, hostname の設定が正しい事を確認して OK とすれば良い。
  3. #3) できた certificates を各サイトと関連させるには、 /etc/apache2/sites-available/000-otacky.conf
    <VirtualHost *:443>
            ServerName www.otacky.jp
            DocumentRoot /var/www/html
            .....
            SSLCertificateFile      /etc/letsencrypt/live/www.otacky.jp/cert.pem
            SSLCertificateKeyFile /etc/letsencrypt/live/www.otacky.jp/privkey.pem
            SSLCACertificateFile  /etc/letsencrypt/live/www.otacky.jp/chain.pem
            .....
  4. #4) また、 /etc/postfix/main.cf
        .....
    smtpd_tls_cert_file = /etc/letsencrypt/live/www.otacky.jp/cert.pem
    smtpd_tls_key_file = /etc/letsencrypt/live/www.otacky.jp/privkey.pem
    smtpd_tls_CAfile = /etc/letsencrypt/live/www.otacky.jp/chain.pem
        .....
ここまでで、apache2 用、postfix 用、imap 用の certificates が取れて、 どれも問題無く動くようになった。(実は、imap は certificates は使っていないようだが。)

まとめ

とにかく、操作自体は比較的簡単で、renewal に至っては crontab でやれそう。 要は、 ヘルプが「可能な全てのやり方」を網羅しようとして、理解しがたい物になってしまった、 という事らしい。

2016-05-28 (Sat): Apple Support 讃

私の MacBook Air は 2010 late 版だから、買ってからもう 6 年近くになる。 San Diego (SD) の Apple Store で、赤い毛氈というかテーブルクロスに山積みして あるのを as-is で買ったのだった。まさにバーゲンセールで手に入れた訣だ。

しかし、よく仕えてくれたなぁ。SD でも日本へ帰ってからも、 殆んど毎日カバンに入れて持ち歩いたが、 これまでトラブルらしいトラブルは一度もない。まあ、1.4GHz Core 2 Duo, 2GB だから、もとよりそんな厳しい使い方はしなかった、という事もある。 (Xcode と WireShark はかろうじて動く——起動はするが、 データが大きくなってくると動作が怪しくなる、 なのであまり無理押しはしなかった。) それでも、最早お約束になった観のある WiFi や SSD の劣化の問題が皆無というのは、大したもんだ。(同じ頃買った娘の MacBook Pro は、既に一度 SSD が飛んだし、この間 Buffalo の WiFi ルータは二度更新した……。)電池も WiFi ありでまだ 2 時間近く保つ。 ThinkPad のは、3 年くらいで必ずダメになった事を考えると、 これはちょっと驚き。

が、或る日、ゴム足が取れてしまった。 どうやら両面テープでくっついていたようだ。 取れてしまっただけなら何とでもなるが、どうやらそのゴム足を失くしてしまった。 もうそんなに長くない命だろうから、それまで何とか使い続けようとしたが、 これは頗る具合が悪い。平なところに置いてタイプするとガタガタする。 ワインのコルク栓を加工して、とも思うが、どうにも格好が悪い。 しようがない、という事でゴム足を調達する事にした。

が、Apple Store のサイトでは、保証期限が過ぎているものは門前払い、 というか、サポートセンターに相談するだけで、2000 円かかるらしい。 (ちぇっ、やっぱりな……。)仕方なく近所の正規サービスプロバイダ(2 軒) へ電話すると、 散々盥回しされた上に、結局は「そういう部品は在庫していません。」 (そうだろうと思ったよ!で、あろう事か) 「本体裏側のカバー全体の交換になります」

でも(どういうきっかけだったが忘れたが)最後に Apple 渋谷に電話してみた。 少し盥回しは有ったが(と言うか、 電話したつもりの渋谷店ではなく最初からサポートセンターに繋った)、 結局「ゴム足のキットはお売りできます」と言ってくれた (2,xx0 円也)。 「あー、よかった……」 しかし、後程また別の担当から電話が有って、 「先程のお返事は、シリアルナンバーからお調べした際に機種名を間違えていて、 正しくは、こちらに引き取っての修理になります。」 「えぇっ、ゴム足が取れただけなんですよぉ……」 (私の悲痛な叫び……それが通じたのか) 「先程、の御返事のお詫びという事もあり、今回は無料で……」

翌日、ヤマト運輸の人が受け取りに来て、本体を渡す (梱包は不要)。 翌日には修理完了のメールが来て、その翌日には、本体が帰ってきた。 ゴム足はしっかりくっついている。一通り動かしてみて動作確認……問題無さそう。 改めて繁々と眺めてみると、あちこち綺麗になっている。 特にスクリーンの上の両側に有った磁石の「跡」が綺麗に取れている。 (どうやったんだろ。) で、裏返してみて驚いた……裏蓋が全取り替えになっている。 そこに有った筈のシリアルナンバーが無くなっているので、元のでない事は確か。 たかがゴム足のために引き取り修理とは大仰な……と思っていたけど、 実は裏蓋全取っ替えだったのか。しかも無料?

どうして最初からのこのパスに辿りつけないの、という憾みはあるが、 ともあれ、愛機は新品同様となって帰ってきた!アップルさん有り難う。


2016-05-07 (Sat): 宅外サーバの Ubuntu をリリース版に……

宅外サーバ (DigitalOcean VPS) は頗る順調

今年の初めから自宅サーバの機能の大半を DigitalOcean の VPS に移して「宅外サーバ」として運用している。 頗る安定していて、レスポンスも良い——
  1. VPS H/W (OS, control panel 含む) のトラブルは皆無。
  2. SG ⇔ US のデータ転送速度は、コンスタントに 400-500 Mbps 出ている。
  3. SG ⇔ 家庭内 LAN のレスポンス(ping のturn around time) は、 殆んどいつも 80 msec 以下。 非常に稀に(これまで二三度)echo back がタイプに若干遅れるという事があったが。
  4. 週一の自動バックアップ ($5/mon) を始めたが、 これによるレスポンス低下は検知できない程度。
あと、サーバも結構まともに動いているようだ。
  1. HTTP (Apache2): これも安定して推移している。 というかパフォーマンスが心配になるほどの「アクセスの集中」は無いのだが…… :-)。 ともあれ、multi-threading がうまく働いているようで、 たまにあるイリーガルなアクセスの嵐に際しても、 プロセスがやたら増えるという事がない(当り前か?:-)。
    Apache2 Status
    Apache の server_status
    (クリックして拡大)
  2. Mail Server (Postfix): 現状の Postfix は、要するに ISP さんの OP25B の外側に Posting Server を設置している訳で、 当然の事ながら、一番に心配すべきは、スパムメールの踏み台にされる事。 もしこれを見逃して、ブラックリストに載ってしまうと、メールの送受信ができなくなってしまう。

    なので、当初は、JBL.JPさんで 「リレー拒否がきちんとできているか」とか、はたまた、 MxToolBox さんで「ブラックリストに載ってないか」等をかなり神経質に確かめていたが、 これが結構邪魔臭い……。 何度かやっているうちに、MxToolBox さんで、自動モニタして、 週一回メールで通知してくれるサービスが有る事を知った。 早速アカウントを作ってモニタを始めた。まだ二週間だが、 これまでのところブラックリストには載らずに済んでいるようだ。

という事で、(ThinkPad を買わないで) VPS に移行したのは、とても良い判断だったと思っている。

が、失敗したかな、と思う事柄もある。

というのは、インストール時は DO のコントロールパネルから Ubuntu-14.04 LTS を選んだのだが、即 16.04 LTS の (pre-release 版? 以下 'pre') に上げて、 その OS についてくる各サーバを採用して、設定したのだった。 要は、数ヶ月後に迫っていた正式リリースの際に、手間暇かけずに、16.04 LTS にしたい、と思った訳。

Fusion 上ではあっさりリリース版にできた

実際、予備的な試行・検討のために走らせている Fusion 上の 16.04 (pre) では、上の目論見はまんまと成功した。

pre-release 版をインストールしてから絶え間なくアップグレードを続けているが、 apt-get update, apt-get upgrade を繰返しても、kernel は keep-back されている模様。(以下は、Fusion VM の上でのホスト xenial での話。)

fukuda@xenial:~% sudo apt-get upgrade
    .....
The following packages have been kept back:
    .....
  linux-generic linux-headers-generic linux-image-generic network-manager
    .....
fukuda@xenial:~% uname -ir
4.4.0-4-generic x86_64
    
fukuda@xenial:~% sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
    .....
The following NEW packages will be installed:
    .....
  libxtables11 libyaml-0-2 libyaml-libyaml-perl linux-headers-4.4.0-21
  linux-headers-4.4.0-21-generic linux-image-4.4.0-21-generic 
  linux-image-extra-4.4.0-21-generic python-attr
    .....
The following packages will be upgraded:
    .....
fukuda@xenial:~% uname -ir
4.4.0-21-generic x86_64 
つまり、pre-release 版から、release 版へアップグレードするには、 do-release-upgrade でも do-release-upgrade -d でもなく、 (release 版が出て以降に) apt-get dist-upgrade すれば良い、という事らしい。(Kernel のみならず、(それに依存する) パッケージも大量にアップグレードされるので、これでほぼ release 版を新規インストールしたのと同じ状態になっている筈。)

DigitalOcean VPS ではうまく行かない

が、これが、肝心の宅外サーバではうまく行かない。

apt-get dist-upgrade で、溜っていた (kept-back されていた) パッケージは全てアップグレードされるし、 新カーネルもインストールされているように見えるのに、 reboot したら、相変わらず GNU/Linux 3.13.0-71-generic x86_64 が立ち上がる——これは、14.04 LTS のオリジナルのカーネル。

こうなると「GRUB の問題に違いない」という事になるが、 さすがに手許にないマシンの GRUB を弄るのは危ういように思えたので、 週一回のバックアップを完了するのを待ってから実行した。 しかし、/etc/default/grub を弄っても、というか、 これをどう設定しても 3.13.0-71 が立ち上がる……。一層の事 /boot/ の下にある、3.13.0 のカーネルイメージ他を消去してみようかとも思ったが、 さすがにそれは躊躇われる。

思い余って、 DigitalOcean Community で質問したら、以外に早く回答がもらえた。 曰く、

  1. kernel をアップグレードしようとせず、(16.04 で) 新しく作った droplet にサーバアプリケイションをポートするのが吉。
  2. Ubuntu-14.04 では、kernel は Droplet 自体の外側 (control panel) から制御されているので、変更するには droplet のページで、kernel を選択する必要がある。
1. の面倒を避けようとしての四苦八苦なのに、それはないだろうと思い、 とりあえず、2 を実行してみた。確かに、16.04 4.4.0-21 を選ぶことができ、reboot してみたら、無事立ち上がる。 が、ネットワーク越しのアクセスにまったく応答しない……

久し振りに、Access Monitor を使ってみたが、なんと、ifconfig が何も示さない (EthN I/F が作られていない。) これは「おいそれ」とは直せそうもないので、すぐに諦め、元の '14.04 3.13-71' に戻した。(考えてみれば、 戻した後また動いたのはとってもラッキーだったのかも知れない。)

こうなると、上の選択肢 1. に行かざるを得ないが、 それはまた大仕事の予感がするので、どうするか悩ましい……


2016-04-27 (Wed): ISP を乗換える

ありがとう、さようなら So-net さん

So-net さんには (フレッツ光になってからだけでも) 13 年くらいお世話になってきた。 かつて、OP25B を突然始めて、しかもユーザには事後報告、 という目を剥くような「暴挙」も有ったが、その後は安定しているし、 さして不満もない。しかし、 かつてお世話になっていた以下のような機能は段々使わなくなって、 3000 円/月の会費に割高感が出てきていた。
  1. SMTP Posting Server: Google のそれ (smtp.gmail.com) より制限が少くて使い易い——特に、Mailing List の運営には不可欠。
  2. Mail Server: かつては POP3 オンリーだったが、 そのせいで大分前から、自宅サーバにこの機能を移している。(今現在は IMAP4 にも対応している模様)。
  3. Mail Address: 当初 fukuda@xx.so-net.ne.jp というアドレスをアサインされて、computer.org 共々良く使っていた。
  4. 家族会員サービス
  5. 固定 IP
のうち、1) と 2) は、VPS 上の宅外サーバで実現できた (一月余り使っているが、どうやら問題無さそう)。なので、もはや必須ではない。 3) については、スパムが多い事、また (上記のように当初は) IMAP4 に未対応という事で、かなり前から放置状態になっている。 4) については、何年も前から家族会員はゼロとなっているようだ (皆、 携帯電話のメールや、gmail を使っている模様)。

残るは 5) の「固定 IP」だけだが、これだけだと他の格安の ISP でも賄える。

Interlink さんこんにちは

そのうちの一つの Interlink については、少し前に試してみて、問題無さそう、という印象だったが、 同社には「SMTP ポスティングサーバが無い」ので、 実際に移行はしなかった。 今回、宅外サーバでそれが実現できたので、再度こちらに乗換える事を試みた訳。

「試みた」と言っても、かつて継げていたのだから、 それをもう一回イネーブルするだけ……の筈だったのだが、「その前に WiFi ルータの F/W のバージョンアップをしてやろう」 なんて思ったのが間違いの始まり……。 何とバージョンアップに失敗 (ダウンロードした zip ファイルを展開しないで突っ込もうとしたかも*^_^*)、起動しなくなって、 RESET をボタンを押して、また一から設定を始める羽目に。

ともあれ、So-net さんと全く同様に Interlink さんからの通知の通り、 WiFi ルータの Internet の項を設定し、So-net/Interlink を切り換えて使えるようにできた。

まさかそれで性能に差が出るとは思えないが、(久し振りに) RBB さんでスピードを測定してみた。それぞれ 5回の試行の結果は

となり、はっきりした差は出てないと言えるだろう。

ここまで確認設定した後で、DynDNS の otacky.us (家庭内 LAN の TLD) の A Record を Inetrlink 支給の固定 IP に書き変えた。 手で書き替えた方が早いと思うが、ちょっと「いちび」って、DynDNS からの ipcheck を使って書換えてみた。

fukuda@lark:~/DynDNS% mv ipcheck.dat bak.ipcheck.dat
fukuda@lark:~/DynDNS% python ~/DynDNS/ipcheck.py -l -c -d ~/DynDNS --syslog \
   -r checkip.dyndns.org:8245 --acctfile ~/DynDNS/account --makedat
ipcheck.py: ip1 looking up otacky.us
ipcheck.py: result: 'otacky.us'[]['192.168.0.11']
ipcheck.py: Updates required by ipcheck.dat address mismatch.
ipcheck.py: otacky.us needs updating
ipcheck.py: Prefix = /nic/update?system=custom&hostname=
ipcheck.py: Hosts  = otacky.us
ipcheck.py: Suffix = &myip=116.58.xxx.101
ipcheck.py: otacky.us good 116.58.xxx.101 
これで目出度く、DynDNS 上で otacky.us の A Record が自動修正できた。 (が、次は手でやる……)

その後、家庭内 LAN のグローバル IP アドレスが変わった事によって、 問題が出そうな点を確認……

  1. 宅外サーバへの ssh login
  2. 同 SMTP サーバへの Posting
  3. 同 IMAP4 サーバへのアクセス
  4. 同 HTTP サーバの Server Status へのアクセス
4) を除いていずれも OK。 4) は、アクセスを許可する host を IP アドレスで指定してあるので、当り前と言えば当り前なのだが…… この際という事で、ホスト名で指定しようとしたが、 うまくいかなかった。 ともかく、IP アドレスを書き直して、またアクセスできるようになった。
	<Location /server-status>
		SetHandler server-status
		#Require host otacky.us
		#Require ip 202.238.126.251 
		Require ip 116.58.xxx.101
	</Location>

Interlink のお試し期間と、So-net の課金の区切が 4/30 までなので、 それまで試用を継続して、問題なければ So-net は解約する予定。 (Neuro がマンションの 6 階以上に届くようになったら、また御厄介になるかも。)


123/1,050,021 Valid CSS! Valid HTML 5.0
Taka Fukuda
Last modified: 2016-06-17 (Fri) 12:02:54 JST