オタク日記
(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 に変わっていて、 随分新しくなっている印象。よし、とばかり意気込んで作業を始めるが、 「ややこしさ」は減ってなくて、すぐに「訳わか」になってしまった……長い話を短くすると
- バージョンがいくつか有り、上記の letsencrypt と certbot が混在していて
- さらにプラグインがいくつか有り (Webroot と Standalone)
- さらにいくつかあるインストール方法 (各 Linux のパッケージと PyPI)
- できたクライアントソフトウェアが PyVenv の作製からやる……
だから、という事でもないが、今回やった事を一応纏めておく。 とりあえずの前提条件と選んだ選択肢は:
- 環境は Ubuntu-16.04
- git clone で cerbot クライアントをインストール
- その中の cerbot-auto を使って PyVenv を構築 (初回だけ)
- Webroot プラグインを使用 (つまり、certificates を作るだけ)。
- 既存の apache2 の 000-otacky.conf の中で、対応ホスト名を指定する
- cerbot-auto で、certs を作製、登録
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) 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) option で、webroot_1, hostname (複数可), webroot_2, hostname (複数可) のように指定する。 但し、hostname_i は DNS で名前解決できないといけない。 また、このコマンドを起動すると (結構崩れた) 擬似 GUI 画面が表われるが、 上記の webroot, hostname の設定が正しい事を確認して OK とすれば良い。
- #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) また、
/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 .....
まとめ
- Let's Encrypt のクライアントを git clone でインストールし、
- これによって、certificates が作製、登録できた。
- 「SSLなう!」と殆んど同じやり方で、certificate しているようだが、 certificates の置き場が違うので、xxxx.conf や main.cf を変更する必要がある。
- 以降は、
certbot-auto renew
コマンド一発で更新できる (筈)!
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 に移して「宅外サーバ」として運用している。 頗る安定していて、レスポンスも良い——- VPS H/W (OS, control panel 含む) のトラブルは皆無。
- SG ⇔ US のデータ転送速度は、コンスタントに 400-500 Mbps 出ている。
- SG ⇔ 家庭内 LAN のレスポンス(ping のturn around time) は、 殆んどいつも 80 msec 以下。 非常に稀に(これまで二三度)echo back がタイプに若干遅れるという事があったが。
- 週一の自動バックアップ ($5/mon) を始めたが、 これによるレスポンス低下は検知できない程度。
- HTTP (Apache2): これも安定して推移している。 というかパフォーマンスが心配になるほどの「アクセスの集中」は無いのだが…… :-)。 ともあれ、multi-threading がうまく働いているようで、 たまにあるイリーガルなアクセスの嵐に際しても、 プロセスがやたら増えるという事がない(当り前か?:-)。
- Mail Server (Postfix):
現状の Postfix は、要するに ISP さんの OP25B の外側に Posting Server
を設置している訳で、
当然の事ながら、一番に心配すべきは、スパムメールの踏み台にされる事。
もしこれを見逃して、ブラックリストに載ってしまうと、メールの送受信ができなくなってしまう。
なので、当初は、JBL.JPさんで 「リレー拒否がきちんとできているか」とか、はたまた、 MxToolBox さんで「ブラックリストに載ってないか」等をかなり神経質に確かめていたが、 これが結構邪魔臭い……。 何度かやっているうちに、MxToolBox さんで、自動モニタして、 週一回メールで通知してくれるサービスが有る事を知った。 早速アカウントを作ってモニタを始めた。まだ二週間だが、 これまでのところブラックリストには載らずに済んでいるようだ。
が、失敗したかな、と思う事柄もある。
というのは、インストール時は 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 で質問したら、以外に早く回答がもらえた。 曰く、
- kernel をアップグレードしようとせず、(16.04 で) 新しく作った droplet にサーバアプリケイションをポートするのが吉。
- Ubuntu-14.04 では、kernel は Droplet 自体の外側 (control panel) から制御されているので、変更するには droplet のページで、kernel を選択する必要がある。
久し振りに、Access Monitor を使ってみたが、なんと、ifconfig が何も示さない (EthN I/F が作られていない。) これは「おいそれ」とは直せそうもないので、すぐに諦め、元の '14.04 3.13-71' に戻した。(考えてみれば、 戻した後また動いたのはとってもラッキーだったのかも知れない。)
こうなると、上の選択肢 1. に行かざるを得ないが、 それはまた大仕事の予感がするので、どうするか悩ましい……
2016-04-27 (Wed): ISP を乗換える
ありがとう、さようなら So-net さん
So-net さんには (フレッツ光になってからだけでも) 13 年くらいお世話になってきた。 かつて、OP25B を突然始めて、しかもユーザには事後報告、 という目を剥くような「暴挙」も有ったが、その後は安定しているし、 さして不満もない。しかし、 かつてお世話になっていた以下のような機能は段々使わなくなって、 3000 円/月の会費に割高感が出てきていた。- SMTP Posting Server: Google のそれ (smtp.gmail.com) より制限が少くて使い易い——特に、Mailing List の運営には不可欠。
- Mail Server: かつては POP3 オンリーだったが、 そのせいで大分前から、自宅サーバにこの機能を移している。(今現在は IMAP4 にも対応している模様)。
- Mail Address: 当初 fukuda@xx.so-net.ne.jp というアドレスをアサインされて、computer.org 共々良く使っていた。
- 家族会員サービス
- 固定 IP
残るは 5) の「固定 IP」だけだが、これだけだと他の格安の ISP でも賄える。
Interlink さんこんにちは
そのうちの一つの Interlink については、少し前に試してみて、問題無さそう、という印象だったが、 同社には「SMTP ポスティングサーバが無い」ので、 実際に移行はしなかった。 今回、宅外サーバでそれが実現できたので、再度こちらに乗換える事を試みた訳。「試みた」と言っても、かつて継げていたのだから、 それをもう一回イネーブルするだけ……の筈だったのだが、「その前に WiFi ルータの F/W のバージョンアップをしてやろう」 なんて思ったのが間違いの始まり……。 何とバージョンアップに失敗 (ダウンロードした zip ファイルを展開しないで突っ込もうとしたかも*^_^*)、起動しなくなって、 RESET をボタンを押して、また一から設定を始める羽目に。
ともあれ、So-net さんと全く同様に Interlink さんからの通知の通り、 WiFi ルータの Internet の項を設定し、So-net/Interlink を切り換えて使えるようにできた。
まさかそれで性能に差が出るとは思えないが、(久し振りに) RBB さんでスピードを測定してみた。それぞれ 5回の試行の結果は
- So-net: 上り: 13.0 ± 2.7 Mbps, 下り: 27.7 ± 4.8 Mbps
- Interlink: 上り: 11.2 ± 4.5 Mbps, 下り: 30.5 ± 7.5 Mbps
ここまで確認設定した後で、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 アドレスが変わった事によって、 問題が出そうな点を確認……
- 宅外サーバへの ssh login
- 同 SMTP サーバへの Posting
- 同 IMAP4 サーバへのアクセス
- 同 HTTP サーバの Server Status へのアクセス
<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 階以上に届くようになったら、また御厄介になるかも。)
131/1,785,469 Taka Fukuda Last modified: 2016-06-17 (Fri) 12:02:54 JST