オタク日記
(Mac と Linux, 2016Q1)
目次
2016-03-30 (Wed): 自宅サーバ引越し (その 5) Mailman2016-03-23 (Wed): 自宅サーバ引越し (その 4) Postfix/Procmail
2016-03-16 (Wed): 自宅サーバ引越し (その 3) Mail System/Dovecot
2016-03-03 (Thu): 自宅サーバ引越し (その 2) HTTPd
2016-03-02 (Wed): 自宅サーバ引越し (その 1)
2016-02-24 (Wed): 「お願いしますよ」二題
2016-02-21 (Sun): VPS あれこれ
2016-02-06 (Sat): DigitalOcean VPS
2016-02-03 (Wed): ConoHa VPS を試す (その 2)
2016-01-24 (Sun): ConoHa VPS を試す (その 1)
2016-01-20 (Wed): 自宅サーバがクラッシュ
2016-01-17 (Sun): Mac-mini/Yosemite がリブートした!
2016-01-06 (Wed): お願いしますよ Apple さん
古い日記:
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-03-30 (Wed): 自宅サーバ引越し (その 5)—Mailman
インストール
Mailman アーカイブの「移行」にはいつも苦労してきた。 最近の「苦労」は二年前だが、 その時も deb パッケージインストールから始めたものの、結局挫折して、 また mailman-2.1.14-j7 に戻る、という右往左往をやったのだった (しかも、その -j7 のインストールも大変だった)。なので、今回、deb パッケージにするか、従来通り mailman-2.1.14-j7 から始めるか、 ちょっと迷ったが、「ここらで一気に苦労しておいて、先々の移行を楽にしよう」 と殊勝な決心をして、勇躍取り掛かったのだが……
何故か Ubuntu Mailman のインストールマニュアルが二種類有る。
- https://help.ubuntu.com/lts/serverguide/mailman.html
- https://help.ubuntu.com/community/Mailman
ただ、例によって、一部「誤り」(というか不適切な記述)が残っているようだ。
- Postfix (main.cf): 最近は main.cf を直接弄るのではなくて、
postconf コマンドを使うようだが、それによると、
sudo postconf -e 'relay_domains = lists.example.com' sudo postconf -e 'transport_maps = hash:/etc/postfix/transport' .....
をやるように、とあるが、これが問題。先の compatibility_level もからんでややこしいが、lists.example.com という host の上で Mailman が動いているのでなければ、 これらは全く不要。というか、先の設定が反映されている必要があるので、 これらをやってはいけない。つまり、# main.cf relay_domains = $mydestination transport_maps =
となっていないといけない。 - /etc/postfix/transport: 上の transport_maps が blank であるので、このファイルも不要。
- /etc/aliases: を編集して
..... mailman: "|/var/lib/mailman/mail/mailman post mailman" mailman-admin: "|/var/lib/mailman/mail/mailman admin mailman" mailman-bounces: "|/var/lib/mailman/mail/mailman bounces mailman" mailman-confirm: "|/var/lib/mailman/mail/mailman confirm mailman" .....
を加えよ、とあるけど、これも不要。(/usr/lib/mailman/data/aliases
に自動で入る。)
/etc/mailman/mm_cfg.py
で、留意すべき変更点は、
DEFAULT_EMAIL_HOST = 'otacky.jp' DEFAULT_URL_HOST = 'lists.otacky.jp' DEFAULT_SERVER_LANGUAGE = 'ja' MTA = 'Postfix' USE_MAILMAN_MESSAGE_ID = Yesこれらに留意して、Wiki の内容を忠実に辿ると、ダミーの ML, 'mailman' を一つ含む Mailman システムが動き出す。 但し、daemon の起動は、
fukuda@digoc02:~% sudo systemctl start mailman
等のように、systemd を使う。(始めは頭痛の種だったが、
慣れると、これはなかなか……)
Mailman アーカイブ移行
Debian package のおかげで、インストールは簡単だった (lists.example.com
まわりのスッタモンダは除く)
が、アーカイブの移行は結構面倒。(何しろ、user/group 名から
ディレクトリ構成まで変わっているんだから無理もない……。)
まずは、旧自宅サーバ Lark で archive を作る。
fukuda@lark:/usr/local/mailman% bin/rmlist -a mailman-test2 ..... fukuda@lark:/usr/local/mailman% tar -czvf mailman.tar.gz archives data lists fukuda@lark:/usr/local/mailman% scp mailman.tar.gz otacky.jp:ここで、宅外サーバ (otacky.jp) に移って、
fukua@digoc02:~% mkdir var_lib_mailman fukua@digoc02:~% sudo chown root:list var_lib_mailman fukua@digoc02:~% sudo chmod g+s var_lib_mailman fukua@digoc02:~% cd var_lib_mailman fukua@digoc02:~/var_lib_mailman% sudo tar xzvf ~/mailman.tar.gz fukua@digoc02:~/var_lib_mailman% cd fukua@digoc02:~% sudo chown root:list var_lib_mailman/* fukua@digoc02:~% sudo cd var_lib_mailman/archives/kosen fukua@digoc02:~/var_lib_mailman/archives/kosen% sudo chown list * fukua@digoc02:~/var_lib_mailman/archives/kosen% sudo chown lwww-data index.html fukua@digoc02:~/var_lib_mailman/lists% sudo chown list:list */* fukua@digoc02:~/var_lib_mailman/lists% sudo chown www-data */request.pck fukua@digoc02:~/var_lib_mailman/lists% cd fukua@digoc02:~% sudo rsync -auv var_lib_mailman/ /var/lib/mailman/ここでは、kosen@otacky.jp という ML を例に上げた。 chown が、過不足なく実行できているかどうか自信がない……要は、 上の default で作った mailman ML と同じようにできていれば良い。 (Debian パッケージはオリジナルのより file permission/owner の設定ミスについて寛大なようだし。)
次いで、移行した ML の個別の属性を変更する。(ML の一つでやった操作を例に示す。)
fukuda@digoc02:/var/lib/mailman% sudo bin/withlist -l kosen Loading list kosen (locked) The variable 'm' is the kosen MailList instance >>> m.web_page_url 'http://lark.otacky.jp/mailman/' >>> m.web_page_url = 'http://lists.otacky.jp/cgi-bin/mailman' #1) >>> m.Save() >>> list = u"高松高専電気科8期生同窓会" >>> list u'\u9ad8\u677e\u9ad8\u5c02\u96fb\u6c17\u79d18\u671f\u751f\u540c\u7a93\u4f1a' >>> m.description = list.encode('utf-8') #2) >>> m.Save()
- #1) VirtualHost で指定する hostname (
lists.otacky.jp
) に加えて、ScriptAlias で定義されたディレクトリとも一致していないといけない。<VirtualHost *:80> ServerName lists.otacky.jp ..... Alias /pipermail/ /var/lib/mailman/archives/public/ Alias /images/mailman/ /usr/share/images/mailman/ ScriptAlias /cgi-bin/mailman/ /usr/lib/cgi-bin/mailman/ ScriptAlias / /usr/lib/cgi-bin/mailman/listinfo/ ..... </VirtualHost>
- #2) Unicode で書かれた「説明」を、'description' attribute に代入するのに、明示的に UTF-8 で encode してやらないといけない。 (さもないと、下のスクリーンショットでの Mmtest3 のように、Python の Unicode 表現」がそのまま表示される。)
http://lists.otacky.jp
へアクセスすると、
Mailman のフロント(一覧)ページへ行ける。
2016-03-23 (Wed): 自宅サーバ引越し (その 4)—Postfix/Procmail
Postfix—アップグレード
自宅サーバでも既に So-net や Gmail の Posting Server を submission port (587) 越しに使っていたので、 そこまでを宅外サーバで再現するのには、比較的問題が少なかった。
ただ、Postfix 自体が 3.0.x になっているので、mail.log を詳細に見て、
warning や error を無くそうと思うと結構面倒臭い。どうやら
backward_compatibility_level
という変数でもって、Postfix
の仕様変更の影響を吸収しようとしているらしく、
fukuda@digoc02:/etc/postfix% postconf -d | grep compatibility_level
append_dot_mydomain = ${{$compatibility_level} < {1} ? {yes} : {no}}
compatibility_level = 0
mynetworks_style = ${{$compatibility_level} < {2} ? {subnet} : {host}}
relay_domains = ${{$compatibility_level} < {2} ? {$mydestination} : {}}
smtputf8_enable = ${{$compatibility_level} < {1} ? {no} : {yes}}
てな具合になっている。
つまり、compatibility_level
を main.cf
の中で変更したら、それに応じて、
mynetworks_style とか relay_domain とかのディフォルトの値が変わる、
という目論見。だがこれ、まったく上手く行かない。
compatibility_level = 2
とすると、上記の値はそれぞれ{host}, {}, {yes} となるが、Postfix
のパッケージが準備している (mynetworks や、master.cf の) ディフォルトの値は、
ちっともそれに対応していない…… (16.04 LTS がリリースされるまでには、
対応してくれるのかな?)
なので、これに固執するのは止めて、main.cf で明示的に指定する事にした。 それらを含めて、基本的な設定は以下のようにする。
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) biff = no compatibility_level = 2 smtputf8_enable = no # domain names #1) append_dot_mydomain = no myhostname = digoc02.otacky.jp mydomain = otacky.jp myorigin = $mydomain #mydestination = $myhostname, localhost.$mydomain, localhost mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain # relay_domains = otacky.jp relay_domains = $mydestination mynetworks = 127.0.0.0/8 128.199.128.0/18 # interfaces inet_interfaces = all inet_protocols = ipv4 #2) # local transfer mailbox_size_limit = 0 mailbox_command = procmail -a "$EXTENSION" #3) recipient_delimiter = + ### #4) alias_maps = hash:/etc/aliases hash:/var/lib/mailman/data/aliases alias_database = hash:/etc/aliases ### #5) smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_tls_CAfile = /etc/postfix/cacert.pem smtp_tls_security_level = may smtp_use_tls = yes ### posting server #6) # relayhost = [smtp.gmail.com]:587 # relayhost = [mail.so-net.ne.jp]:587 relayhost =
- #1) mydestination がディフォルトのままでは、例えば fukuda@otacky.jp へはローカルユーザと見做されない。これを救うために、myhostname を domain name ('otacky.jp') にしていたのだった。しかし、この弥縫策はその後の「病膏肓」の元になる…… ここで、最後に $mydomain をつけておけば、他は殆どディフォルトの値が使える。
- #2) これもディフォルトは 'all' だが、gmail.com へは何故か IPv6 でアクセスしようとし、毎回 fail となるので、IPv4 決め打ちにした。
- #3) local 配送は、procmail にやらせるための設定。
これまでは
~/.forwarder
~/forward
にその旨記述していたが、 設定を一箇所に固めておくという意味で良さそうなので、こちらにした。 - #4) Mailman のための aliases 設定。(後の aliases が無かったらエラーになるかも知れない。)
- #5) 送信の際に Posting Server に submission port (587) 使うための certification と key の設定。
- #6) 上記の Posting Server をここで指定する。 今回は、自らが Posting Server になるので、指定無し、にしておく。 それぞれの MTA に port 25 で配送する。
fukuda@digoc02:~% sendmail fukuda@computer.org From: fukuda@otacky.jp Subject: are you alive? computer.org To: fukuda@computer.org You lazy forwarder.... . fukuda@digoc02:~%これで無事外部のアカウントに転送できた。(ちょっと時間がかかったが :-)
Postfix SSL/TLS
上記で smtp_tls_xxxx を介して、送信側の smtp/submission daemon を設定したが、一方で自分が SMTP Posting Server となるためには、受信側の smtpd daemon が SSL/TLS を話せるようにする必要がある。このための certificate がオレオレ認証でダメな理由は無いような気がするのだが、 Wanderlust の送信 (つまり Posting Server への port 587 へのアクセス) が、それを要求するので、Let's Encrypt で、certificate と private key を作製したのだった——Dovecot はこれを流用しただけ。その設定には、smtpd_tls_xxxx を使う。
smtpd_sasl_type = dovecot #1) smtpd_sasl_path = private/auth smtpd_sasl_auth_enable = yes smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination smtpd_sasl_local_domain = smtpd_tls_auth_only = yes #2) smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_ask_ccert = yes ## #3) smtpd_tls_cert_file=/etc/ssl/certs/lets_cert.pem smtpd_tls_key_file=/etc/ssl/private/lets_server.key smtpd_tls_CAfile=/etc/ssl/certs/lets_chain.pem
- #1) この設定で殆ど唯一の「判断」が要求される箇所。SASL library を Dovecot もしくは Cyrus のどちらから選ぶか、とう事。Dovecot は必須なので、その SASL ライブラリを流用する事にした。
- #2) 随分解釈に悩んだが、つまりは、これが 'no' の場合、クライアント側から STARTTLS を呼ばずに auth ができる、という事。 それでは、態々 TLS にした意味が無いような気がして 'yes' にした。 その場合 port 25 からの local user へのメッセージも tls_auth_only になるのか、と思ったが杞憂だった。(RCPT TO: で local user 以外のアドレスを指定すれば、拒否する。)
- #3) Dovecot と同じ certificate と private key を使った。
この certificate は、imap.otacky.jp と smtp.otacky.jp を alternate name
として含んでいるので、これが可能。
fukuda@digoc02:~% openssl x509 -in /etc/ssl/certs/lets_cert.pem -text -noout Certificate: Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1 Validity Not Before: Mar 6 02:06:00 2016 GMT Not After : Jun 4 02:06:00 2016 GMT Subject: CN=www.waremo.com ..... X509v3 extensions: ..... X509v3 Subject Alternative Name: DNS:dms.waremo.com, DNS:imap.otacky.jp, DNS:smtp.otacky.jp, .....
fukuda@falcon:~/pve35% gnutls-cli --starttls -p 587 smtp.otacky.jp Processed 151 CA certificate(s). Resolving 'smtp.otacky.jp'... Connecting to '128.199.138.76:587'... - Simple Client Mode: 220 digoc02.otacky.jp ESMTP Postfix (Ubuntu) ehlo smtp.otacky.jp 250-digoc02.otacky.jp 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS #1) 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN starttls 220 2.0.0 Ready to start TLS # hit Ctrl-D here *** Starting TLS handshake - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: ..... - Compression: NULL - Options: safe renegotiation, auth plain AGZ1a3VxxxxxxxhlaSZIYQ== #2) 235 2.7.0 Authentication successful mail from: fukuda@otacky.jp 250 2.1.0 Ok rcpt to: fukuda@otacky.jp #3) 250 2.1.5 Ok data 354 End data with <CR><LF>.<CR><LF> from: fukuda@otacky.jp subject: test with modified lets_chain to: fukuda@computer.org this could be checking . 250 2.0.0 Ok: queued as E7B78200371 mail from: fukuda@otacky.jp 250 2.1.0 Ok rcpt to: fukudataka@gmail.com #4) 250 2.1.5 Ok data 354 End data with <CR><LF>.<CR><LF> from: fukuda@otacky.jp subject: otacky.jp to gmail.com to: fukudataka@gmail.com OK, things are going well. But then, why these had botched the first try? . 250 2.0.0 Ok: queued as 2E4CF200371 quit
- #1) 上記の smtpd_tls_auth_only が、'no' であれば、ここに
250-AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN
という行が入り、starttls しないまま、auth plain ..... でログインが可能。 - #2) secret は、username と passwd を base64 で encode したもの。
fukuda@digoc02:~% python Python 2.7.11+ (default, Feb 22 2016, 16:38:42) [GCC 5.3.1 20160222] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import base64 >>> base64.b64encode(b'\0username\0password') 'AGZ1a3VxxxxxxxhlaSZIYQ=='
として得た。 - #3) 'To:' フィールドではなく、実際の配送先を指定。実際に存在する local アドレスなので、問題なく Ok となる。
- #4) 同上。non-local であるが、自身を authenticate しているので受けつけられる。
fukuda@falcon:~% telnet smtp.otacky.jp 25 Trying 128.199.138.76... Connected to otacky.jp. Escape character is '^]'. 220 digoc02.otacky.jp ESMTP Postfix (Ubuntu) helo smtp.otacky.jp #1) 250 digoc02.otacky.jp mail from: fukuda@otacky.jp 250 2.1.0 Ok rcpt to: fukuda@otacky.jp #2) 250 2.1.5 Ok data 354 End data with <CR><LF>.<CR><LF> from: fukuda@otacky.jp sujbect: message for local to: fukuda@otacky.jp test of a message for local . 250 2.0.0 Ok: queued as 5054F200010 mail from: fukuda@otacky.jp 250 2.1.0 Ok rcpt to: fukudataka@gmail.com #3) 454 4.7.1 <fukudataka@gmail.com>: Relay access denied
- #1) Postfix が ESMTP なので、ehlo でも可。但し STARTTLS が「能力」 として表示されても、それを実行できない(Ctrl-D 止まってしまう)ので、 結局 Auth はできない。
- #2) rcpt to: が local address であれば (すなわち、mydestination の中にあれば) 配送を受けつける。
- #3) しかし、配送先に local address 以外を指定すると (つまり、リレーを依頼すると) 拒否される。
Procmail/SpamBayes
~/Maildir は Dovecot をインストールする前に rsync してあるので、 あとは ~/.procmailrc をコピーしてくるだけで、 すぐに動くようになった。コピーした.forward
でも動いたが、上述のように main.cf 内の設定でリンクさせる事にした。
fukuda@digoc02:~% sudo apt-get install spambayes procmail fukuda@digoc02:~% scp otacky.us:.procmailrc .この SpamBayes は 1.1b1 で、PyPI にある最新版 (1.1b2) より若干古いが、移行が容易である事を期待して、この deb パッケージを使う事にした。
期待通り、何の変更も必要なく
fukuda@digoc02:~% sb_mboxtrain.py -f -d ~/.hammiedb -s ~/Maildir/.spambayes.spam\
-g ~/Maildir/.spambayes.ham
で、新しい ~/.hammiedb
ができた。
何故かこれまでアップデートしてきたものの約半分のサイズ (5.2 MB) になった。
さて、切れ味はいかがなものか?
2016-03-16 (Wed): 自宅サーバ引越し (その 3)—Mail System/Dovecot
これまた予期した通り、Mail 周りの移行はとっても大変だった……ML (Mailman) のマイグレーションは大変だろうな、 と身構えていたが、(実際大変だったが) 新しい Ubuntu パッケージでは、 旧日本版インストーラの「面倒臭さ」(失礼)が大分改善されていて、 一通り動くようにするのに然程時間はかからなかった。
問題は「その後」で、せっかく So-net の OP25B の外に Linux マシンを置けるんだから、full-fledged の SMTP Posting Server を作ってやろう、なんて目論見んだのが間違いの始まり。 これにはかなり梃摺った。
全体構成(の構想)
概略次のような構成を目指した。 上の「目論見」をこの構成図に即して言うと- Postfix へのメール受信は (図中の smtpd が担当) 、
- ML のリストを含む、local user へのメールを、port 25 で受け (従来通り)、
- Posting Server としての入力を、port 587 で受ける
- Postfix からの (つまり、上の port 587 で受信したメール、ML
からのメールの) 送信は、
- Port 587 で他の Posting Server に送る (従来通り)
- Port 25 でインターネットへ直接配送する
- Dovecot で IMAPS (IMAP4 over SSL) によるアクセスを実現して、 既存のメールアーカイブを引き継ぐ。
- Mailman を、Ubuntu のパッケージで実現する (勿論、既存のアーカイブをポートする)
- Postfix-3.0.4-5: Mail の localhost 内および対 Internet の配送を行う。 新しい機能としては、Port:25 から Internet へ送信する機能を追加した。 (Port:587 からの submission と選択可能—両立はできない。)また、Internet から submission port (587) でメッセージを受け取る事が可能になった。
- Procmail-3.22-25: Postfix から localhost への mail message を受けとり、そのヘッダに基いて仕訳して Mailbox (Maildir 形式) へセーブするか Spambayes に送る
- Spambayes-1.1b1-1: Procmail から受け取った message を解析して、Spambayes-Classification: {spam|unsure|ham} のヘッダを付けて、Procmail に返す。(Procmail は、そのヘッダに基いて、 スパムはスパム溜めに放り込み、その他はハムとして通常の inbox に入れる。
- Mailman-2.1.20: Mailing List。Postfix は To: field の ML 名 (mmtest@otacky.jp 等) に基づき、Mailman へ配送、 Mailman は List 宛にそのメッセージを送る (Postfix の maildrop に置く)。 のうち
- Dovecot-2.2.18: IMAP4/POP3 サーバ。MUA からの着信メールへのアクセスは、もっぱらこれを介して行う。ここでは、IMAP4 の SSL 版(IMAPS) のみを使う。
世の中変っているんだよ……
かつては、Sendmail の代りに Postfix さえ使えば、 メールサーバの構築なんて簡単、 と嘯いていた時代も有ったのだが、今は Postfix でさえ設定が大変。 大昔の事とて記憶が定かではないが、どうも So-net さんが OP25B を始めた頃から、面倒になったような気がする。 その後も、スパム対策とかセキュリティの確保とかとの理由で、 ますます複雑怪奇になって行く。今回の Mail Server 構築にあたっては、 当然それらのサーバが「動作環境」になる訣だが、 それらを使っての「動作確認」にかなり四苦八苦した。 その理由の一つに、これまで当り前のように使ってきた外部のサーバが、 必ずしも期待通り動いてない、という事がある。
- OP25B と IP25B: 「今更……」の話題かも知れないが、
Interlink さんも OP25B を実施しているんだとか。
かつては「OP25B はやりません(勝手にポスティングサーバを立てて下さい)」と言って
いたのに……
これはすなわち、今では主立った ISP
さんは皆やっている、という事なのかも。
DoCoMo さんの tethering でも、OP25B は実施されている模様。
一方、早々と OP25B を始めた So-net さんは、IP25B とか DKIM, はたまた SPF も始めたようだ。
- computer.org mail alias (forwarder): この設定用ウェブサイトが一時応答しなくなっていた、という事は既に伸べたが、 それに加えて、時折稼働時の応答が遅くなる、という問題もある事が分った (実測した中での最長の遅れは 7 分!) これは通常の使用には然程問題にならないだろうが、試験の際には混乱の元になる。
- smtp.gmail.com: SMTP Posting サーバとしての Gmail
は、(SMTPS (port:465) だけでなく) submission (587)
ポートからもメッセージを受け付けるようになっている。
が、この事は google のサイトでは明記されていない。
しかし、RFC で明確に規定されているのは、submission (587) の方で、 SMTPS はとっくに obsolete となっている。 なので、ここでは、smtp.gmail.com に対しても port 465 ではなく、port 587 で統一しておく (つまり、いつも STARTTLS を使う) 。
- imap.gmail.com: 前にも触れたように、IMAP サーバとしての Gmail
は「受信したメッセージの Message-ID が、既存のメッセージのそれと同じであれば、
黙って落す」というポリシーに固執している。しかも「既存の」には、
WebMail 以外からの送信済みメッセージも含まれる。
これは、Web Mail 以外の IMAP クライアントからすると誠に具合が良くない。
(例えば、特定の相手とのやりとりを送受を交えてスレッドにしてリストする、
という事ができない。)
それはともかく、試験に際しては、 これと融通の効かないスパムフィルタが相俟って、 「届くかどうかは時の運」という具合になる。 (短かいテスト用のメッセージは、スパムと看做される事が多い。)
また、そのスパムフィルタは融通が効かないだけでなく、 アカウントによって、フィルタの効き方が異なる、という問題もある。 同じメッセージを fukudataka @ gmail.com と fukuda @ waremo.com に送っても、前者は受けつけるのに、後者はスパムとして弾いてしまう、 という具合。
- gmail.com: Gmail の受信用 SMTP サーバ (alt1.gmail-smtp-in.l.google.com 等。gmail.com の MX レコード) は、port 25 でメールを受け取るが、その際、相手先(送信サーバ) に、certificate だけでなく、その CA (Certificate Agent) の certificate も要求する。
Dovecot
Mailbox を自宅サーバから移してうまく動くか、 というのが最大の懸案事項だったので、まずそれからチャレンジ。 今回は珍しく :-) 昔のオタク日記が、参考になった。fukuda@digoc02:~% mkdir Maildir fukuda@digoc02:~% chmod 700 Maildir fukuda@digoc02:~% rsync -ua otacky.us:Maildir/ Maildir/ fukuda@digoc02:~% sudo apt-get install dovecot-core dovecot-imapd
# /etc/dovecot/conf.d/10-mail.conf ..... mail_location = maildir:~/Maildir # mail_location = mbox:~/mail:INBOX=/var/mail/%u .....
# /etc/dovecot/conf.d/10-auth.conf ..... disable_plaintext_auth = yes # default auth_mechanisms = plain login .....
# /etc/dovecot/conf.d/10-master.conf ..... # unix_listener /var/spool/postfix/private/auth { # mode = 0666 # } unix_listener /var/spool/postfix/private/auth { mode = 0666 user = postfix group = postfix } ....
# /etc/dovecot/conf.d/10-ssl.conf ..... # ssl = ssl = required #1) ..... #ssl_cert = </etc/dovecot/dovecot.pem #ssl_key = </etc/dovecot/private/dovecot.pem ssl_cert = </etc/ssl/certs/lets_cert.pem #2) ssl_key = </etc/ssl/private/lets_server.key #3) ..... #ssl_ca = ssl_ca = </etc/ssl/certs/lets_chain.pem #4) .....
- #1) SSL を要求する。つまり、IMAP2/3 でのアクセスは拒否する。
- #2) lets encrypt の
cert.pem
から - #3) 同
rsa_private.key
から - #4) 同
chain.pem
から。(chain.pem
を指すべき変数がssl_ca
だというのに気がつくのに、ちょっと時間が……)
上の SSL key/certificate は、インストール時のディフォルトでも、
動くようだが、SSL/TLS の上で動かせる事を考えて、
「SSL なう (Let's Encrypt
のフロントエンド)」で imap.otacky.jp
, smtp.otacky.jp
等を合わせて、 sertificate と private key を取得した。
falcon.otacky.us (家庭内 LAN) から、gnutls-cli を使ってアクセスしてみる……
fukuda@falcon:~% gnutls-cli -p 993 imap.otacky.jp Processed 151 CA certificate(s). Resolving 'imap.otacky.jp'... Connecting to '128.199.138.76:993'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `CN=www.waremo.com', issuer `C=US,O=Let's Encrypt,.....' Public Key ID: 74da35107202acd0cfafa5b7a47e9996ea9117c1 Public key's random art: +--[ RSA 2048]----+ | . ...o +. | | . . .. + . | | . + E . o | | . o. = . . | | .S . | | .o. | | o+o+ | | o=B | | o==.. | +-----------------+ - Certificate[1] info: - subject `.....' - Status: The certificate is trusted. - Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-128-GCM) - Session ID: B2:F7:52:.....:55:8D:99:50:5C:44:D4:5C:BB:60:AF:66:C6:49:ED:BB:31:EF - Ephemeral EC Diffie-Hellman parameters - Using curve: SECP256R1 - Curve size: 256 bits - Version: TLS1.2 - Key Exchange: ECDHE-RSA - Server Signature: RSA-SHA256 - Cipher: AES-128-GCM - MAC: AEAD - Compression: NULL - Options: safe renegotiation, - Handshake was completed - Simple Client Mode: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID .....] Dovecot ready. a001 login fukuda xxxxxxxx a001 OK [CAPABILITY IMAP4rev1 ....] Logged in a002 select inbox * FLAGS (\Answered \Flagged \Deleted ....) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted .... ] Flags permitted. * 6023 EXISTS * 0 RECENT * OK [UNSEEN 5770] First unseen. * OK [UIDVALIDITY 1252205310] UIDs valid * OK [UIDNEXT 65872] Predicted next UID * OK [HIGHESTMODSEQ 956] Highest a002 OK [READ-WRITE] Select completed (0.000 secs). a003 close a003 OK Close completed.すなわち、 Port 993 から IMAPS でアクセスして、きちんと認証、login, command/ response が行えている。
いくつかのコマンドを投げてみて確認した知見:
- IMAP2/3: (port 143/220) を介してのアクセスは拒否。(上記 #1) の効果)
- Hostname と CAcert: Hostname (この場合 imap.otacky.jp) は、certificate の中で alternate names の中になくてはいけない。 かつ、CA の certificate も必要。 (勿論、DNS でも定義されている必要がある。)
- STARTTLS: でも、ちゃんと応答する。つまり、
fukuda@falcon:~% gnutls-cli -p 993 imap.otacky.jp --starttls
としても正しくアクセスできる。(- Simple Client Mode:
の後に Ctl-D をキーインする必要がある。)
この IMAP サーバに、常用する MUA である Wanderlust/EmacsMac.app からアクセスしてみる。
まず、falcon の Wanderlust のディフォルトを変更する。
~/.wl
で
..... (setq elmo-imap4-default-authenticate-type 'clear elmo-imap4-default-stream-type 'ssl elmo-imap4-default-port '993) .....とする。こうする事で
~/.folders
の中で
..... # %inbox:fukuda/clear@otacky.jp:993! %inbox:fukuda@imap.otacky.jp ..... # %inbox:fukudataka/clear@imap.gmail.com:993! %inbox:fukudataka@imap.gmail.com .....のように、otacky.jp の hostname を imap.otacky.jp としつつ、各フォルダの名称 (つまりは、各サーバへのアクセス方法) を簡略化する事ができた。
ここでもし、この
':993' を ':993!!' とすれば(もしくは、
(setq elmo-imap4-default-stream-type 'starttls)
とすれば)、各 server へのアクセスを STARTTLS にできる筈であるが、
Wanderlust ではうまく行かない。これは、imap.gmail.com
についても同様なので、Wanderlust の問題であると思われる。
2016-03-03 (Thu): 自宅サーバ引越し (その 2)—HTTPd
予期した通り、ウェブサーバの移行は比較的スムースだった。 Debian 独自の Virtual Host 実現方法のお陰で CGI や Django に基いたページの問題とうまく切り離されている事もあり、 スタティックなページの移行は殆んど問題無かった。What's New
Server Status の表示によると、14.04 LTS でServer Version: Apache/2.4.7 (Ubuntu) OpenSSL/1.0.1f mod_wsgi/3.4 Python/3.4.3 Server MPM: preforkだったものが、16.04 LTS では
Server Version: Apache/2.4.18 (Ubuntu) mod_wsgi/4.4.22 Python/3.5.1+ Server MPM: eventとなっている。
ここで、mod_wsgi が 3.4 から 4.4.x になっているが、 Ubuntu のパッケージがアップグレードされたのではなく、 パッケージ内のモジュールを、無理矢理最新のものと入れ替えた事による。 (それでも Apache2 の Server Status は正しいバージョンを表示する……大したもんだよ。)
第二行目は、multi-process/thread の「方式」で、 Apache-2.4.18 では、threading がディフォルトになっている、という事。 性能的には、こちらの方がずっと有利なんだそうな……が、 WSGI を使う立場からすると、これはインパクトが大きい。 つまり、wsgi を使う xxxx.conf は、そのままでは新サーバで動かない (後述。)
CGI と文字コード
Python や Gnuplot が大きくバージョンアップされた事で、少々問題が出た。- 文字コード: HTML ファイルも、Python のスクリプトも、
とうの昔に Unicode
に統一した、と思っていたが、どうやら一部の CGI
スクリプトの string が EUC のままだったようだ。
それなら、話は簡単、
#!/usr/bin/env python # -*- coding: euc-jp -*-
となっている所を、euc-jp ⇒ utf-8 と変更し、 エディタで実際の文字コードを変更すれば済む、と思ったのだが、 うっかり、両者が矛盾しているファイルを作ってしまい、 その後、どうしても Emacs では直せなくなってしまった……既視感はあるのだが、どうやって克服したか思い出せない。かなり焦ったが、要は「(nano か何かで) 本文の coding と合うようにその行を編集すれば良い」という事だった。
- Gnuplot:
ページビューのグラフが、気味悪い色(藤色)に変わってしまった。
最初は何でそうなるのか皆目見当が付かなかったが、MacPorts の gnuplot (-5.0.3)
でプロットしてみて
Gnuplot のディフォルトの色配分(最初のプロットは「赤」、次は「青」、……)
が変わっている事がわかった。
なので、
g=Gnuplot.Gnuplot() g('set terminal pngcairo transparent font ",12" size 758,500') ## testing 748 g('set output "%s"' % temp_image) g('set linetype 1 lc rgb "red"') g('set linetype 2 lc rgb "blue"') g('set style fill solid 0.25 border lc rgb "red"') .....
のように、lc (line color) を明示的に "red" とか "blue" 等と指定してやればよい。(しかし、 なんでこんなところを変えるかねぇ、Gnuplot 開発陣の方々。)
Django + WSGI
実は、移行というか移植を目論んでいる Django アプリには二種類有って、最新の環境(Ubuntu-16.04, Django-1.9.x, mod_wsgi-4.4.xx) で動いている wrm_cwt と、少し古い環境(Ubuntu-14.04, Django-1.6.x, mod_wsgi-3.4.4) で動いている wrm_dms. 実は wrm_dms の方が実稼働中で、ここでも 16.04 にした事が悔まれる……:-)とは言え、新サーバを古い環境で統一する訣には行かないので、当然 wrm_dms を 16.04 にポートする事にした。目論んだ手順は、
- 新サーバ上で、pyvenv を作り、 django, mod_wsgi, matplotlib 以下、必要なモジュールを pip-compile & pip-sync でインストール。 (「Django Project で Virtual Host」を参照。)
- git clone で pyvenv 下に Application (スクリプト) をコピー
fukuda@digoc02:~/pve35$ git clone git://otacky.jp/wrm_dms.git wrm_dms
- 別途、名目のみの App を作って、
(pve35) fukuda@digoc02:~/pve35$ python manage.py startapp tmpapp
最新版の mysite/wsgi.py と mysite/settings.py を得る。 - 上記の settings.py をフレームワークにして、wrm_dms の settings.py を 書き直す。
- wrm_dms のディレクトリ構成を作り直す(
db.sqlite3
, static files, templates files (xxxx.html) の位置を最新の Django のディフォルトに合わせる。) - 新ディレクトリ構成に合うように、
urls.py (mysite/urls.py, index/urls.py, users/urls.py)
を変更。Runserver を起動して、(pve35) fukuda@digoc02:~/pve35$ python manage.py runserver 0.0.0.0:8000
web browser から、URL を直打ちしてアクセスできる事を確認する。 'page not found' が出なくなれば OK。 - index/views.py, user/views.py を変更。 上記の runserver で、エラーが出なくなる事を確認。 (Template file の PATH の問題が大きい筈。)
- wrm_cwt での「対応」を、wrm_dms にも適用する。
- apache2 動作のために、static files を所定の位置に集める
(pve35) fukuda@digoc02:~/pve35/wrm_dms% python manage.py collectstatic
-
libapache2_mod_wsgi_python3
をインストールして、その mod_wsgi.so が、pip-install した mod_wsgi.so を指すようにsymbolic link を張り直す。 つまりfukuda@digoc02:~% sudo apt-get install libapache2_mod_wsgi_python3 fukuda@digoc02:/usr/lib/apache2/modules$ sudo ln -s \ /home/fukuda/pve35/lib/python3.5/site-packages/mod_wsgi/server/\ mod_wsgi-py35.cpython-35m-x86_64-linux-gnu.so ./mod_wsgi.so
とやる。 -
/etc/apache2/sites_available/wrm_dms.conf
を作る。# WSGIPythonPath /home/fukuda/pve35/wrm_dms #1) <VirtualHost *:80> ServerName dms.waremo.com WSGIScriptAlias / /home/fukuda/pve35/wrm_dms/mysite/wsgi.py WSGIApplicationGroup %{GLOBAL} #2) WSGIDaemonProcess dms.waremo.com python-path=/home/fukuda/pve35/wrm_dms:/home/fukuda/pve35/lib/python3.5/site-packages WSGIProcessGroup dms.waremo.com Alias /static/ /home/fukuda/pve35/wrm_dms/htdocs/ Alias /favicon.ico /home/fukuda/pve35/wrm_dms/htdocs/img/favicon.ico <Directory /home/fukuda/pve35/wrm_dms/htdocs> Require all granted </Directory> <Directory /home/fukuda/pve35/wrm_dms/mysite > <Files wsgi.py> Require all granted </Files> </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>
上述のServer MPM: event
の「インパクト」とは、 WSGI が起動すべき Python への PATH を- #1) のように WSGIPythonPath で指定する事はできず、
- #2) のように、WSGIDaemonProcess の中で、python-path= で指定してやらねばならない、という事。
- mod_wsgi モジュールと上記 wrm_dms.conf を enable する
fukuda@digoc02:~% sudo a2enmod mod_wsgi fukuda@digoc02:~% sudo a2ensite wrm_dms.conf
- apache2 をリスタート
fukuda@digoc02:~% sudo systemctl restart apache2
2016-03-02 (Wed): 自宅サーバ引越し (その 1)
既に自宅サーバの殆んど全部の機能を VPS に移して運用を始めている (以下、自宅外サーバと呼ぶ。)それにしても、Ubuntu-16.04 にしたのは迂闊というか楽観的過ぎた。 Python-3.5.1 と Numpy-1.10.x の組合せが素晴らしかったので、 VPS の比較にもそれを使ったが、よくよく考えてみれば、 自宅外サーバにそれを使う必然性は何もない。 数値計算用とサーバを一つにすれば安くはなるだろうが、 そもそもサーバ用(現行)の VPS (2-core) の性能は VMware Fusion の Ubuntu と然程変わらないのだから。
色々困難にぶつかって後悔し始めた頃には、メールの移行他が相当進んでいて、 14.04 版の VPS を新しく作ってまた一からやりなおすのが億劫で…… しかしこれは明らかに判断ミスで「後悔後をたたず」になってしまった。
なにはともあれ
DigitalOcean (以下 DO) のコントロールパネルで、Droplet を作ったら、 メールでパスワードを送ってきて、それを使って log-in する所から話は始まる。このところというか過去半年くらいの間に、 VMware Fusion の VM, Raspberry Pi 等数え切れない程たくさんの Debian (Raspbian) と Ubuntu をインストールしてきたので、 もはや儀式化している……root でログインして、16.04 にして、一般ユーザ fukuda を作るところまで
fukuda@falcon:~% ssh root@128.199.xxx.xxx
root@128.199.xxx.xxx's password:
digoc02# passwd
Enter new UNIX password:
Retype new UNIX password:
digoc02# apt-get update
digoc02# apt-get upgrade
digoc02# do-release-upgrade -cd
Checking for a new Ubuntu release
New release '16.04 LTS' available.
Run 'do-release-upgrade' to upgrade to it.
digoc02# do-release-upgrade -d #1)
digoc02# adduser fukuda #2)
digoc02# adduser fukuda sudo #3)
digoc02# exit
- #1) このコマンド一発で、16.04 LTS へアップグレードされる。20分程かかる。
- #2) ここで (useradd でなく)adduser を使うのが一番簡単。
- #3) これも、sudoer 設定するには最も手っ取り早い。
ここまでに (DNS record を編集して) otacky.us に 128.199.xxx.xxx がアサインされているとして、設定を継続
fukuda@falcon:~% ssh otacky.us .... login display .... fukuda@digoc02:~$ sudo apt-get install zsh lv fukuda@digoc02:~$ sudo chsh fukuda Changing the login shell for fukuda Enter the new value, or press ENTER for the default Login Shell [/bin/bash]: /bin/zsh fukuda@digoc02:~$ zsh This is the Z Shell configuration function for new users, zsh-newuser-install. ..... (2) Populate your ~/.zshrc with the configuration recommended by the system administrator and exit (you will need to edit the file by hand, if so desired). --- Type one of the keys in parentheses --- 2 fukuda2@digoc02 /root % exit fukuda@digoc02:~$ cp .zshrc .zshrc.orig fukuda@digoc02:~$ nano .zshrc fukuda@digoc02:~$ zsh fukuda@digoc02:~%Bash でも悪くない(prompt が自分の常用のと殆ど同じで嬉しい)のだが、 最新のディフォルトのは、どうも history の動作がおかしい。なので、Zsh にする事にした。 ただ、これまた、最新のディフォルトのは酷い色使いである上に、 Emacs の Tramp と干渉する……。 なので、.zshrc を少し変更した。
fukuda@digoc02:~% diff .zshrc.orig .zshrc
1a2,6
> # autoload -Uz promptinit
> # promptinit
> # prompt adam1
> autoload -U colors
> colors
3,5c8
< autoload -Uz promptinit
< promptinit
< prompt adam1
---
> PROMPT="%n@%{${fg[blue]}%}%m%{${fg[default]}%}:%~%# "
13,14c16,17
< HISTSIZE=1000
< SAVEHIST=1000
---
> HISTSIZE=10000
> SAVEHIST=10000
16a20,21
> PATH=$PATH:~/scripts
>
37a43,65
>
> recent()
> {
> /bin/ls -lt $1 | head -n 20
> }
> alias -g L='|lv'
> alias -g H='|head -n 20'
> alias -g T='|tail -n 20'
> alias cp='nocorrect cp -i'
> alias mv='nocorrect mv -i'
> alias rm='rm -i'
> case "$TERM" in
> emacs) alias ls='ls -F' ;;
> *) alias ls='ls -F --color=tty' ;;
> esac
> if [[ "$TERM" == "dumb" ]]; then
> unsetopt zle
> unsetopt prompt_cr
> unsetopt prompt_subst
> unfunction precmd
> unfunction preexec
> PS1='$ '
> fi
かなりオタク趣味も入っているし、
「できるかぎりディフォルト設定を使う」から逸脱してるが、最後の設定
(if ~ fi) は、リモートの Emacs から Tramp で入るためには必須。
全般的設定
以上までで、ssh/tramp で作業する環境はととのったので、 一般的な設定を行う- Time Zone: ディフォルトの TZ が何と EST (米国東海岸標準時) になっている。
少々迷ったが、JST にした。
(しばらく使ってみると、これで正解だったようだ。)
fukuda@digoc02:~% sudo timedatectl set-timezone Asia/Tokyo
- Fire Wall:ufw (Uncomplicated FireWall) の設定は、アプリ名でできるようになっている。
fukuda@digoc02:~% sudo ufw status [sudo] password for fukuda: Status: active To Action From -- ------ ---- Apache Full ALLOW Anywhere Postfix ALLOW Anywhere Postfix Submission ALLOW Anywhere OpenSSH LIMIT Anywhere Dovecot Secure IMAP ALLOW Anywhere
実際のところどうなのかちょっと心配になるが、ポート番号でも見る事ができて、fukuda@digoc02:~% sudo ufw status verbose Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 80,443/tcp (Apache Full) ALLOW IN Anywhere 25/tcp (Postfix) ALLOW IN Anywhere 587/tcp (Postfix Submission) ALLOW IN Anywhere 22/tcp (OpenSSH) LIMIT IN Anywhere 993/tcp (Dovecot Secure IMAP) ALLOW IN Anywhere
のような具合。ディフォルトでは IPv6 がサポートされているが、 それを止めるために# /etc/default/ufw # IPV6=no .....
- Ssh の no-passphrase login:
ローカルのホストは既に RSA key pair を持っているとして、
digoc02 で作製
fukuda@digoc02:~% ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/fukuda/.ssh/id_rsa): Created directory '/home/fukuda/.ssh'. Enter passphrase (empty for no passphrase): #1) Enter same passphrase again: Your identification has been saved in /home/fukuda2/.ssh/id_rsa. Your public key has been saved in /home/fukuda2/.ssh/id_rsa.pub. The key fingerprint is: ..... fukuda@digoc02:~% scp otacky.jp:.ssh/id_rsa.pub . #2) fukuda@digoc02:~% cp id_rsa.pub .ssh/authorized_keys #3)
- #1) ここで、return key だけを押してパスフレーズ不要の key にする
- #2) 作製済みの otacky.jp の公開鍵をコピーしてきて
- #3) authorized_keys にコピー
- Logwatch: は、(14.04 server
とは違って)ディフォルトではインストールされず、
fukuda@digoc02:~% sudo apt-get install logwatch
とやる必要がある。これで、/etc/cron.daily にも登録されて、 毎日(日本時間の)早朝に自動実行され、結果がメールで root に報告される。 それとは別にコマンドラインからfukuda@digoc02:~% sudo logwatch | lv
とやるのも、なかなか役に立つ。 (ログに残る範囲の設定のミスを一挙に報告してくれるので。) 但し、14.04 には無かった logwatch 自体のバグが作り込まれたようで、 それがまだ残っている。 - Crontab: 旧自宅サーバから、一部を引き継いで、今は
fukuda@digoc02:/etc/default% crontab -l SHELL=/bin/bash #PATH=/usr/local/bin:/usr/bin:/bin:/sbin:/usr/sbin: #PATH=/usr/bin:/bin is presumed #HOME=/home/fukuda is presumed MAILTO=root ..... 14 7,20 * * * sb_mboxtrain.py -d ~/.hammiedb -s ~/Maildir/.spambayes.spam -g ~/Maildir/.spambayes.ham > /dev/null 40 10 * * * python ~/scripts/sitemap_gen.py --config=sitemap/config.xml .....
としている。(勿論この時点では spambayes も sitemap_gen.py もインストールされていないので、意味はないが。)
開発環境としての評価
DO にはコンソールも準備されているが、迷わず ssh/tramp ベースの開発環境にした。つまり、常に Falcon (Mac-mini, OSX 10.11.5) の Terminal.app と EmacsMac.app からアクセスする、 という事。(もともと GUI もつかえる Fusion や ThinkPad の上の Ubuntu/Raspbian でも、ssh で通していたので……)- 自宅外サーバと自宅サーバの間の Ping は turn around time が約 80 msec で、local network 内のそれ(≦ 1 ms) と比べると少々見劣りするが、ジッタが少ない事もあり、 レスポンスの遅れは実用上は全く気にならない。(実際 local network 内のサーバにログインしているような錯覚に陥る……)
- 外部とのネットワーク接続が速いし、Ubuntu のミラーも DO の local network 内にあるので、 パッケージのダウンロードや、update/upgrade はとっても快適。
- Emacs/Tramp によるネットワーク越しのファイルへのアクセスは、 これまでも紆余曲折が有ったが、今回も Zsh
- Tramp から otacky.us へのアクセスは快適。fukuda
にアクセス可能なファイルは、例えば、C-XC-F の後
Find File: /otacky.us:.zshrc
だけで良いし (パスワードの入力は不要)、root 権限が必要な場合はFind File: /sudo:root@otacky.us:/etc/postfix/main.cf
で OK (fukuda の (sudo) パスワードを聞かれる。) とっても明快でかつ確実。
2016-02-24 (Wed): 「お願いしますよ」二題
Google App もしくは Gmail
Google App for Business にアカウントを作って gmail のお世話になっている。 有料 (独自ドメイン)と無料 (gmail.com) を持っているが、 いままでのところ順調というか問題無く推移している。しかし、それも IMAP4 を使っている間は、という事で、 例えば SMTP posting server (smtp.gmail.com) を使おうとすると、ちょっとひっかかる事もあった。 例えば、SMTPS (465 port) は使えるけど、Submission (578 port) はダメだとか。しかし、少し前やってみると、587 port も使えるようになっていた。(本当に使えなかったのか、自分が Wanderlust の設定で STARTTLS を指定しなかったせいで使えないと思っただけなのかは未詳。) とにかく、
;; ~/.emacs.d/init.el ;; ;; (setq wl-smtp-connection-type 'ssl) ;; (setq wl-smtp-posting-port 465) ;; (setq wl-smtp-connection-type 'starttls) (setq wl-smtp-posting-port 587)connection-type と posting-port を対にして切り換えれば OK。 ついでに、ちょろっとやってみた……
;; (setq wl-smtp-authenticate-type "plain") (setq wl-smtp-authenticate-type "login")これも OK。かつてはこれもできなかった筈。偉いぞ、Google さん(か、 Wanderlust 開発チーム)!
が、「なんだかなぁ」も…… Mailman の確認をしていて(ようやく)はっきりと認識したのだが、 どうやら gmail のアカウントには、同一の Message ID をもったメッセージは一つしか置かない(置けない) というキマリになっているらしい。 私の Wanderlust は、出て行くメールは、全て Fcc で控えを残す (つまり、SMTP に載っけないで、IMAP でメッセージをアカウントに直接「注入」するようになっている。) この場合、CC: で帰ってきたメールも、ML から帰ってきたメールも一切残らない、という事になる。 (勿論これに異をとなえる人は多いが、Google さんは頑として譲らない模様。)
ML の試験では、これに気がつくまで、大いに頭をひねった。
お願いしますよ computer.org さん
もういつ始めたのか思い出せない程昔から fukuda @ computer.org を使っている。これは実は forwarder で、IEEE のサイトに登録してあるアドレスに転送するだけのもの。 つまり Message-ID を変更せず、従ってそもそも上の gmail と相性が悪いのだが、 今回 ML (Mailman) を新サーバに移動する際、 止むを得ず xxxx@otacky.jp から xxxx@gmail.com に一時的に移したのだった。ML の移転はともかく、Postfix の移転・設定はすぐに終ったので、 この一時的な設定を元に戻そうとしたのだが、なんと、 そのサイトが応答しない……(最初の変更のときも、何だか応答が悪かったが。) このままでも、Dovecot による ML の振り分け他が使えないだけで、 メールメッセージが失われる訣ではないので、 「ちぇっ、また調子が悪くなってるのかぁ」くらいのものだったが、 二日たっても三日たっても復旧しない。先にも書いたように、ML の確認には使えないという事もあり、とってもイライラさせられる。 四日目にとうとう computer.org の担当にメールを書いた。 が、梨の礫。二日待って、そのアドレスと並行してオンブズマン にも CC を入れた。そのお陰か?今度は早速 auto-reply が来た…… 「二営業日以内に返事をする」んだそうな。
結局、その二日の期限が過ぎても音沙汰無し。こっちは怒り心頭だが、 そのうちに件のサイトが応答するようになり (相変わらずレスポンスは悪いが)、なんとか転送先を元に戻す事ができた。 程なく、新アドレスに転送が始まった模様。
都合、一週間以上放置された訣だ。 四五年前あたりから、 サポートというかメンテナンスが段々酷くなっている感じはしていたが、 ここまで、とは。これでは、(単なる)forwarder としても大丈夫かなという気がしてくる。 かつては IEEE と CS (Computer Society) を止めても、computer.org は使い続けたいな、なんて思っていたけど、その熱も冷めた。 何十箇所あるか知らないけど、 登録したメールアドレスを今から変更する準備をしよう。
2016-02-21 (Sun): VPS あれこれ
ConoHa VPS
昨日の事になるが ConoHa さんより E-mail を頂き、それによると夕方二時間くらい VPS の「コントロールパネル」に不具合があって、操作できない状況に陥っていたら しい。
平素はConoHaをご利用いただきまして、誠にありがとうございます。 下記日時におきまして、ConoHaにおいて障害が発生しておりました。 お客様には大変ご不便をおかけいたしましたことを深くお詫び申しあげます。 発生日時 : 2016年02月20日(土) 16時00分頃 復旧日時 : 2016年02月20日(土) 18時05分頃 対象 : コントロールパネルおよびAPI 事象 : コントロールパネルにて各サービスの操作不可および APIが利用できない 原因 : 管理系サービスのハングアップ 対応 : 該当サービスの再起動を実施し、各操作に問題がないことを確認しました。 今後ともConoHaをよろしくお願いいたします。
私が試用を始める直前にも、ネットワークの不具合があって、 それで「何だかなぁ」となって、DigitalOcean に乗換えたのだが、 その後も、VPS 一台(?)は維持して様子を見ていたのだった。 「前回のと今回のでは、不具合の起きたシステムが違う」とか 「今回のは、server の動作に問題が有った訣ではない」とも言えるけど 「どちらにしようかな、神様の……」と思っている時にこれではなあ。
ちょっと残念だが、こうなっては是非もない、ConoHa さんとはすっぱり手を切ろう。 と思ったが、アカウントは残して、 VPS だけ消す事にする——これで請求は来ないだろうから。
DigitalOcean VPS
ずっと順調に推移してきていて、問題が無さそうなので、既に otacky.jp と waremo.com のドメインは、DigitalOcean のサーバに移している。 (旧 server (ThinkPad) は今は otacky.us になっている。)先の、やっつけ評価の後、Snapshot (ConoHa でいうイメージ)を作ったり、そこから立ち上げたり、 はたまた、それを消してしまったり、というのをやってみた。 どれも、迅速、確実、かつ解り易くて好印象。 まあ、敢えて「がっかり」を挙げるなら、 「Snapshot を取るのに数時間かかりその間パワーダウンが必要」 かつ「その Droplet を消すと該当する Snapshot も消える」って事かな。
つまり、常時動いているサーバに (数値計算用の) Snapshot を残しておいて、 必要になる度に、そこから数値計算用の Droplet を立ち上げる、なんて事は難しく、Snapshot を維持するための Droplet を確保する必要がある、という事。その Droplet をスケールアップして使うか、その Snapshot から別の Droplet を立ち上げるかは、 もうちょっとよく検討してみる必要がありそう。 (前者は使用後スケールダウンしないと意味がないが、 そうするためには、スケールアップの際に Flexible (つまりストレージを増やさない)方式を取っておく必要がある。)
2016-02-06 (Sat): DigitalOcean VPS
SLA
最初のうちは ConoHa VPS さんのコンセプトには「解り難い!」と不満たらたらだったが、 ひとわたり疑問が解消されてみると、これはなかなかのものだ、と思うようになった。 とりわけネットワークのパフォーマンスには感激した。が、「可用性」はどうなんだろうか。1/16 日あたりに有ったらしいネットワーク障害もショックだったが、 それに加えてどうやら「定期点検」が有り、3 分程ネットワークが止まる、という。それが「月一」だと、 それだけで SLA (というか稼働率) は概略 99.99% になってしまう。 つまり「障害」が一度でもあると、この目標は達成できない……
という事で、他の VPS ベンダも当ってみた。 といっても、そんなに虱潰しに調査した訣ではなくて、 値段がお手頃で、ウェブサイトが分かり易そうなところという事で、 DigitalOcean を試してみる事にした。最初に SLA を調べたが、availability 99.99% とあるだけで、 肝心の「実績」のデータがどこにもない。これに関しては 「便りがないのは良い便り」などと高を括ってよいものかどうかよく解らないが、 ユーザからは特に可用性に関する不満も上ってないようなので、まあ、良い事にする。
あと解らなかったのは、(ConoHa さんには無かった) データ転送量の上限 (3TB/Mo) があり、それがどれくらいのものか、それを超えたらどうなるのか、という事。 後者は (試用を始めてから分ったのだが) 3TB を超えてからは、 2¢/GB で課金されるらしい……。しかしこれも (DoCoMo さんのデータ通信の超過分への課金——1000円/GB) に比べたらゴミみたいなものだ。
Droplet 設定
Droplet とは DigitalOcean さんの用語で、一個のバーチャルサーバの事。 コントロールパネルは ConoHa さんに比べてかなり分かり易くなっていると思う。 ConoHa さんのとそっくりなので、私にとっては「二度目」 になるこちらが易しく思えるのはあたり前とも言えるが、ConoHa さんのコンパネに有る微妙な間違い (「動作中」というべきところを「起動中」とするような) や重複が無く、よく整理されているという面も大きいと思う。ただ、region の選択はちょっと迷った——DigitalOcean は Tokyo リージョンが無いので。東海岸、ヨーロッパ、カナダは論外として、 西海岸とシンガポールのどちらにするか…… (結局、両方にサーバを立てて、性能を比較する事にした。)
Droplet 立ち上げ
ConoHa さん同様、OS をインストールするのではなく、 イメージをダンプする方式らしい。55 秒で起動できる、というのがウリだが、 やってみると確かにそれ以下でインストールは完了し、ssh ログインできるようになる。初期設定を ConoHa さんとの比較の形で纏めてみると、
- Ubuntu-14.04.3 がインストールされる (ConoHa と同じ)
- 固定 IP address が一個与えられる (ConoHa と同じ)
- (コンパネで) 自分で選んだ hostname が付けられる (⇔ ConoHa: IP アドレスから決めた hostname が付けられる。)
- user は root のみ (ConoHa と同じ)
/etc/resolv.conf
の DNS サーバは、 Google DNS (⇔ ConoHa: IPv6 でサーバを指定)- Time Zone は EST (Singapore region でも) (⇔ ConoHa: JST)
Release-upgrade
Ubuntu-14.04(.3) から、16.04 のアップグレードは何の問題もなくスムースだった(当り前!?) ただ、OS イメージのダンプ(?)のようには迅速には行かず、 大体 11 分から 12 分くらいかかった。パフォーマンス
とてもシステマティックとは言えないが、 「箸棒かどうかくらいは解る」程度の比較をしてみた。- ThinkPad X200: 現行自宅サーバ (RAM: 2GB, HDD: 20GB)
- Fusion VM: Fusion on Mac-mini (late 2014) の VM (RAM: 2GB, HDD: 20GB)
- ConoHa VPS: ConoHa VPS (RAM: 2GB, SSD: 60GB)
- DigitalOc. (SF): DigitalOcean, San Francisco (RAM: 2GB, SSD: 40GB)
- DigitalOc. (SG): DigitalOcean, Singapore (RAM: 2GB, SSD: 40GB)
Performance Item | ThinkPad X200 | Fusion VM | ConoHa VPS | DigitalOc. (SF) | DigitalOc. (SG) |
---|---|---|---|---|---|
OS (Ubuntu) | -14.04.3 | -16.04 | -16.04 | -16.04 | -16.04 |
CPU Info | |||||
core # | x 2 | x 2 | x 3 | x 2 | x 2 |
model | Core2 Duo P8600 | Core i5-4308U | Xeon E5-2660 | Xeon E5-2630 | Xeon E5-2630L |
clock (MHz) | 800 | 2800 | 2600 | 2300 | 2000 |
cache (MB) | 3072 | 3072 | 4096 | 15360 | 4096 |
bogo mips | 4788 | 5599 | 5200 | 4600 | 4000 |
RAM (GB) | 2 | 2 | 2 | 2 | 2 |
DTR *1) (MB/s) | 3.6 | 2.6 | 23.4-64.6 | 49.9 | 65.4 |
TAT *2) (ms) | -- | 0.56 ± 0.11 | 9.4 ± 4.5 | 129.8 ± 3.8 | 77.3 ± 4.5 |
fft.fft2 *3) (ms) | 107 ± 0.6 | 54.1 ± 1.5 | 51.7 ± 2.1 | 84.7 ± 28.7 | 82.3 ± 0.8 |
Cached *4) (MB/s) | 1833 | 4430 | 9536 | 7364 | 6725 |
Buffered *4) (MB/s) | 53 | 815 | 117 | 741 | 479 |
- *1) Data Transfer Rate: wget
で
http://www.python.org
からPython-3.5.1.tar.xz
を download して測定 - *2) Turnaround Time: 各サイトから、
www.otacky.jp
(現自宅サーバ)へ ping を通して測定 - *3) 下のようにして、測定。5 回測定して、平均と標準偏差を取った。
(pve35) fukuda@digoc02:~/pve35% ipython Python 3.5.1+ (default, Jan 13 2016, 15:09:18) Type "copyright", "credits" or "license" for more information. IPython 4.1.1 -- An enhanced Interactive Python. .....
In [1]: import numpy as np In [2]: C = np.random.rand(1024, 1024) In [3]: %timeit D = np.fft.fft2(C) 10 loops, best of 3: 81.6 ms per loop ....
- *4) Timing cached reads/Timing buffered disk reads:
次のようにして、disk performance を評価した。(ここだけ bash.)
fukuda@digoc02:~/pve35$ for i in [0, 1, 2, 3, 4]; \ do sleep 3; sudo hdparm -tT /dev/vda1; done /dev/vda1: Timing cached reads: 11426 MB in 2.00 seconds = 5717.16 MB/sec Timing buffered disk reads: 1440 MB in 3.00 seconds = 479.25 MB/sec /dev/vda1: Timing cached reads: 14710 MB in 2.00 seconds = 7362.01 MB/sec Timing buffered disk reads: 1344 MB in 3.00 seconds = 447.80 MB/sec .....
まとめ
途中で、数値解析のためのパフォーマンスに拘ったりして、少々横道に逸れたが、 本来の HTTP サーバだけを VPS で立てるとして、これまでの知見を纏めると- どの VPS を使っても、ネットワーク、CPU、Disk ともに十分な容量と、速度を持っている。
- ThinkPad (memory 2GB) において、top コマンドで表示される "SWAP used" が零でない事から、2GB はぎりぎり必要だろうと思っていたが、 どうやらはこれは怪しい。 新しい (16.04 の) top コマンドでは、"memory used" は buffer を含まない値を示すようになり、 それによると、大抵の場合 500 KB 以下となっている。 なので、多分、1GB にしても問題無いだろう。
- CPU intensive なタスクに関しては、Core2 Duo も Core i5 もよく健闘している、と言える。逆に言うと Xeon は大してアドバンテージを持ってないように見えるし、 何より性能が時間的に大きく変動する。 これはひょっとすると、VPS の仮想化ソフトの問題で他の VM の負荷の影響を受けているのせいなのかも知れない。
- SSD を採用する事のアドバンテージは大きい。Mac-mini の Fusion Drive (Hybrid Drive) も、ほぼ SSD と同じかそれ以上の性能を出している。しかし、これも、ConoHa と DigtalOcean (SF) では大きく変動する。
- DigitalOcean (SG) では、これらの変動が比較的小さいように思える。 これが単に VM が混み合っていない (H/W に大して droplet の数が少ない)だけなのか、それとも仮想化ソフトが優秀なのか……
2016-02-03 (Wed): ConoHa VPS を試す (その 2)
知らぬが仏?
友人に別件で示唆されるまで知らなかったのだが、登録して使い始める直前 (1/16) に、GMO さんではかなり大規模(深刻かつ広範囲)なネットワーク障害が有ったらしい。 VPS として ConoHa (by GMO) さんを選んだ時、確かにそれ程深く考えた訣ではないが、 さすがにちょっと無造作過ぎたかも :-) (それにしても、過去の障害の記録がとっても見付け難いなぁ。) それとも関連するのか ConoHa VPS には SLA (Service Level Agreement) が無い——同じ GMO なのに Cloud VPS にはある。 ともあれ、暫くは稼働率をモニタした方が良いかも知れない。Ubuntu-16.04 対応
そもそも、御仕着せの 14.04 から 16.04 に上げたのは、- Python-3.5 (と python3.5-venv) が deb になっているのでは?
- mod_wsgi の deb が 4.4.x に上っていて、 危ういトリックを使わなくてよくなっているのではないか?
- systemd への対応がより進んでいるのではないか?
最初から Python-3.5.1 と python3.5-venv がついてくる。しかし、
この python3.5-venv がインストールする pip は、
そのままではまだちょっと古くて、pip-tools
を~/pve35/bin
へインストールできない。
deb 版 mod_wsgi のバージョンは 4.3.x だった。 このままでは、やはり mod_wsgi と Virtual Host の共存はできないように見える。 まあしかし、4.4.x に上がっても、するっとこの「共存」はできないかも知れないが。
systemd への対応も、httpd (apache2) については問題ないが(これは前からそう)、 git-daemon については、まだちょっと中途半端。(systemd コマンドで扱えるようになってはいる。)
追加設定・インストール
先日のパフォーマンス測定で、hostname の変更と、一般ユーザの追加、 及び pyvenv のあたりのインストールは終っているが、 今度は、apache2 他のインストールを主眼にして、 一般ユーザの追加の後、zsh 他のインストールから……fukuda@conoha01:~$ sudo apt-get install zsh lv git fukuda@conoha01:~$ sudo chsh fukuda [Sudo] password for fukuda: Changing the login shell for fukuda Enter the new value, or press ENTER for the default Login Shell [/bin/bash]: /bin/zsh fukuda@conoha01:~$ scp otacky.jp:.zshrc . fukuda@conoha01:~$ zsh fukuda@conoha01:~%次に ufw で iptables を enable してポートを開くのだが、enable した途端に ssh できなくなっては困るので、その前に 22 port だけは開けておく。
fukuda@conoha01:~% sudo ufw allow proto tcp from any to any port 22 fukuda@conoha01:~% sudo ufw enable fukuda@conoha01:~% sudo ufw allow 80 ..... fukuda@conoha01:~% sudo ufw status [sudo] password for fukuda: Status: active To Action From -- ------ ---- 22/tcp ALLOW Anywhere 80 ALLOW Anywhere 8000 ALLOW Anywhere 25 ALLOW Anywhere 9418 ALLOW Anywhere .... 22/tcp (v6) ALLOW Anywhere (v6) 80 (v6) ALLOW Anywhere (v6) ..... fukuda@conoha01:~%次いで、apache2 他のインストール
fukuda@conoha01:~% sudo apt-get install apache2-dev apache2 fukuda@conoha01:~% sudo systemctl status apache2 ● apache2.service - LSB: Apache2 web server Loaded: loaded (/etc/init.d/apache2; bad; vendor preset: enabled) Active: active (running) since Sun 2016-01-31 14:35:24 JST; 3 days ago Docs: man:systemd-sysv-generator(8) Process: 12605 ExecReload=/etc/init.d/apache2 reload (code=exited, status=0/SUCCESS) CGroup: /system.slice/apache2.service ├─ 9643 /usr/sbin/apache2 -k start ├─12626 /usr/sbin/apache2 -k start ├─12627 /usr/sbin/apache2 -k start └─12628 /usr/sbin/apache2 -k start Feb 03 16:46:41 conoha01 systemd[1]: Reloading LSB: Apache2 web server. Feb 03 16:46:41 conoha01 apache2[12605]: * Reloading web server apache2 Feb 03 16:46:41 conoha01 systemd[1]: Reloaded LSB: Apache2 web server. Feb 03 16:46:41 conoha01 apache2[12605]: * Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.上からわかるように、ここまでで既に apache2 は走っていて、
http://www.otacky.us/server-status
にアクセスすると、以下のような表示が得られる。
pyvenv 下の mod_wsgi と Virtual Host
まずは、改めて pyvenv 環境のためのパッケージを揃えるfukuda@conoha01:~% sudo apt-get install libopenblas-base libopenblas-dev fukuda@conoha01:~% sudo apt-get install python3.5-venv fukuda@conoha01:~% sudo apt-get build-dep python-numpy fukuda@conoha01:~% sudo apt-get build-dep python3-pip fukuda@conoha01:~% sudo apt-get build-dep libapache2-mod-wsgi-py3 fukuda@conoha01:~% pyvenv-3.5 pve35 fukuda@conoha01:~% cd pve35 fukuda@conoha01:~/pve35% . bin/activate以降、pyvenv を activate して、pyvenv 環境を整備
(pve35) fukuda@conoha01:~/pve35% (pve35) fukuda@conoha01:~/pve35% pip install -U pip (pve35) fukuda@conoha01:~/pve35% pip install pip-tools (pve35) fukuda@conoha01:~/pve35% scp otacky.us:pve35/requirements.in . (pve35) fukuda@conoha01:~/pve35% pip-compile (pve35) fukuda@conoha01:~/pve35% pip-compile ..... # # pip-compile requirements.in # click==6.2 # via pip-tools cycler==0.9.0 # via matplotlib cython==0.23.4 decorator==4.0.6 # via ipython, traitlets django==1.9.2 first==2.0.1 # via pip-tools ipython-genutils==0.1.0 # via traitlets ipython==4.1.0 matplotlib==1.5.1 mod-wsgi==4.4.22 nose==1.3.7 numpy==1.10.4 path.py==8.1.2 # via pickleshare pexpect==4.0.1 # via ipython pickleshare==0.6 # via ipython pip-tools==1.5 ptyprocess==0.5.1 # via pexpect pyparsing==2.0.7 python-dateutil==2.4.2 # via matplotlib pytz==2015.7 # via matplotlib simplegeneric==0.8.1 # via ipython six==1.10.0 # via cycler, pip-tools, python-dateutil traitlets==4.1.0 # via ipython (pve35) fukuda@conoha01:~/pve35% pip-syncできた mod_wsgi を libapache2-mod-wsgi-py3 でインストールされた
/usr/lib/apach2/modules/mod_wsgi.so3
にリンクし、同モジュールを enable して、Apache を再起動
(pve35) fukuda@conoha01:~/pve35% ls lib/python3.5/site-packages/mod_wsgi/server/ apxs_config.py __init__.py mod_wsgi-py35.cpython-35m-x86_64-linux-gnu.so* environ.py management/ __pycache__/ (pve35) fukuda@conoha01:~/pve35% sudo ln -s /home/fukuda/pve35/lib/python3.5/site-packages/mod_wsgi/server/mod_wsgi-py35.cpython-35m-x86_64-linux-gnu.so /usr/lib/apache2/modules/mod_wsgi.so (pve35) fukuda@conoha01:~/pve35% sudo a2ensite wrm_dms (pve35) fukuda@conoha01:~/pve35% sudo a2enmod wsgi (pve35) fukuda@conoha01:~/pve35% sudo systemctl reload apache2
2016-01-24 (Sun): ConoHa VPS を試す (その 1)
自宅サーバは思ったより危機的な状況かも
強制シャットダウンから、何とかまた動き出したものの、 pip-sync を始めると覿面に CPU 温度が上がるので、 pyvenv の構築は早々に諦めた。これまで、apt-get で沢山の package をインストールやアップデートをしてきたが、 然程温度が上っているようには見えなかったが、それは多分 apt-get が Internet にアクセスする時間の方が長いせいであって、 pip-sync のように、「まず必要なパッケージを集めて、 それから一気に全パッケージのコンパイルを始める」ような場合は、 危険なレベルまで温度が上る、という事のようだ。 という事は、pyvenv 構築は言うに及ばず、これまで通りの通常運転でさえ、 「いつ転けてもおかしくない状況」ではないか……最初に思いつく対策は、ThinkPad のファンを掃除もしくは交換し、 CPU の熱伝導グリースを塗り直す事——ThinkPad については(会社御仕着せのを含め)何回か経験がある。 しかし、Lenovo さんのメンテナンスのページに行ってみると、 どうやら、X200 の場合は CPU の頭を露出するには、KBD、 ファン・ヒートシンク、 本体とディスプレイの間のケーブル、etc. etc. を全て取り外して、 基板を裏返しにする必要があるらしい。 それでも、数時間でできそうな気がするし、それくらいならサーバダウンも我慢できる。 が、これだけ大掛かりにバラすとなると、ちゃんと組み上がるかどうかが心配。 Desktop 機の話だが、グリスを塗り直して、きれいに組み上げた筈なのに、 ブートが途中で止まってしまう——ブートは勿論、組み立てをやり直してもだめ、 という恐しい目に遭った事がある(何度目かで動くようになったが。) サーマルシャットダウン他の制御がらみは、一旦臍を曲げられると手に負えない。 なので、こちらを試すにしても、 とりあえずちゃんと動くサーバのバックアップが要るだろう。
そういう面からすると、ThinkPad X250 へ行く、というのは一番心魅かれる「解」であるが、 Laptop として使う事なく、いきなりサーバにしてしまうのは、 さすがに勿体無い気がする。
かくなる上は、現用の MacBook Air をサーバに、とも思ったが、 こっちは非力な上に、Ethernet port が無く、USB/Ether アダプタに頼るしかないのだが、こいつがまた頗る評判が良くない。 (Link が途中で切れる事があるというレポートが多かったし、実際私も経験がある。)
なんてのは、私が古い古いアダプタを使い続けているから、で、 今や各社から出ているし、1000Base-T 版もあるのね。 うむ、これなら、やってみる値打ちが有るかも……
で、ここはもう VPS へ行くしかないだろう。しかも、 Ubuntu-16.04 LTS が出てから、なんて悠長な事は言っていられない。 (しかし、VPS が Virtual Private Server の略だ、というのを今知ったようでは、 あんまり急ぐのは無理という気もするが……)
ConoHa VPS
あまりよく調べた訣ではないが、 中小規模サーバ向けとしては、ConoHa と「さくら」が双璧?らしい。 課金がより柔軟(初期費用無し、H/W のアップグレードに契約更改が不要) というところを買って、ConoHa を最初に試す事にした。そう決めて取り掛かったものの、いきなり暗雲が……。 とにかく「全体像」がよく解らない。そもそも、既存のユーザからの「情報が少ない」 という批判が多く見られたが、それでも「なあに、こちとら (自宅) サーバの構築には、些か経験が……」なんて高を括っていた。 しかし、「さくら」と比較するためのレベルでもピンと来なかったが、 決心した後真面目にサイトをあちこちを覗いていみたも、一向に理解が進まない。
- ネットワーク設定: IP アドレスは固定?それとも DHCP を使う? DNS はどこのを使って、どのように設定する?
- OS インストール・アップデート: 最初の構築はいくつかの代表的な OS から選べるらしい、 というあたりはすぐに分ったが、それが、 どの範囲でアップデート・アップグレードできるのか解らない。
- CUI でどこまで設定できる?: 今現在、Raspberry Pi, Fusion 上の Ubuntu, ThinkPad の Ubuntu 全て、ssh 越しで設定、運用している。 これが、ConoHa VPS どこまで可能か?
でも、まあ、ダメとなっても、すぐやめたら、数百円の出費だし…… という事で、とりあえず使い始めてみるる事にした。
アカウントを作るのは比較的スムース。
しかし、次に出てきた画面で「次は何をすればいいんだ?」と悩んでしまった。 要は、サイドメニューの「サーバ追加」 をクリックすれば良かったのだが…… それで出てくる 「コントロールパネル」(下図)も、とても「使い易い」とは言えないが、 迷ったらディフォルトを選ぶ事で、 なんとか起動してログインできるようにはなる。
これで右下の「追加」を押せば、インストール・システム構築が始まり、 下のサーバリストが表示される。「ステータス」が「構築中」から「起動中」 に変われば、構築は完了している。(ほんの数十秒しかかからない!) ここで、「ネームタグ」をクリックすると表われるページで、「ネットワーク情報」 から IP アドレスを得て、
fukuda@falcon:~% ssh root@133.130.xxx.xxx
The authenticity of host '133.130.xxx.xxx (133.130.xxx.xxx)' can't be established.
RSA key fingerprint is 6e:fc:85:03:07:65:7e:4d:a4:cd:10:fe:41:fb:b7:4c.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '133.130.xxx.xxx' (RSA) to the list of known hosts.
root@133.130.xxx.xxx's password:
Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.16.0-57-generic x86_64)
* Documentation: https://help.ubuntu.com/
System information as of Sat Jan 23 18:09:39 JST 2016
System load: 0.0 Memory usage: 3% Processes: 73
Usage of /: 3.2% of 48.11GB Swap usage: 0% Users logged in: 0
Graph this data and manage this system at:
https://landscape.canonical.com/
root@133-130-xxx-xxx:~#
のように login できる。
ネットワーク設定他の初期設定
ここまでで先の疑問に対しては、一部答が得られていて、- サーバには固定 IP が一つづつ与えられる(dhcp は必要ない。)
- ユーザは root のみ
- hostname は、固定 IP の '.' を '-' で置き換えたもの
早速、(自分にとって)普通の環境にする。
root@133-130-xxx-xxx:~# adduser fukuda Adding user `fukuda' ... Adding new group `fukuda' (1000) ... Adding new user `fukuda' (1000) with group `fukuda' ... ..... root@133-130-xxx-xxx:~# adduser fukuda sudo Adding user `fukuda' to group `sudo' ... Adding user fukuda to group sudo Done. root@133-130-xxx-xxx:~# nano /etc/hosts root@133-130-xxx-xxx:~# cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 conoha01 # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters root@133-130-xxx-xxx:~# hostname conoha01 root@133-130-xxx-xxx:~# nano /etc/hostname root@133-130-xxx-xxx:~# cat /etc/hostname conoha01ここで、DynDNS へ行って、休眠していた otacky.us を on-line にして、この IP アドレスを設定。殆ど瞬時に delegate されて、
fukuda@falcon~% dig otacky.us
; <<>> DiG 9.8.3-P1 <<>> otacky.us
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21618
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 9
;; QUESTION SECTION:
;otacky.us. IN A
;; ANSWER SECTION:
otacky.us. 59 IN A 133.130.xxx.xxx
;; AUTHORITY SECTION:
us. 158644 IN NS a.cctld.us.
us. 158644 IN NS c.cctld.us.
てな具合に「名前解決」できる。
これ以降は、IP アドレスを使わずに、
fukuda@falcon~% ssh fukuda@otacky.us
としてログインできる。
ここまで来れば、後は自宅サーバその他の Ubuntu と全く同様に操作・設定が可能。
性能評価
まずは、嬉しい驚きから。
スピードテストのつもりではなく、何気なく Python-3.5.1 のソースをダウンロードしてみて我が目を疑ってしまった。15 MB のダウンロードが一瞬で終わる。
fukuda@conoha01:~$ wget https://www.python.org/ftp/python/3.5.1/Python-3.5.1.tar.xz
.....
100%[=========================================================>] 14,830,408 60.3MB/s in 0.2s
2016-01-22 09:51:57 (60.3 MB/s) - ‘Python-3.5.1.tar.xz’ saved [14830408/14830408]
略 480 Mbps 也。しかもこれ「まぐれ」ではなくて、何度やっても、50-60 MB/s
がコンスタントに出る。ConoHa さんのコントロールパネルによると、
ネットワークスピードの仕様は 100/100 Mbps だった筈なんだが……
スループットだけでなく、パケットのターンアラウンドも短かい。
fukuda@conoha01:~$ ping www.python.org
PING python.map.fastly.net (103.245.222.223) 56(84) bytes of data.
64 bytes from 103.245.222.223: icmp_seq=1 ttl=55 time=1.53 ms
64 bytes from 103.245.222.223: icmp_seq=2 ttl=55 time=1.59 ms
64 bytes from 103.245.222.223: icmp_seq=3 ttl=55 time=1.66 ms
.....
64 bytes from 103.245.222.223: icmp_seq=14 ttl=55 time=1.60 ms
64 bytes from 103.245.222.223: icmp_seq=15 ttl=55 time=1.73 ms
^C
--- python.map.fastly.net ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 14025ms
rtt min/avg/max/mdev = 1.518/1.616/1.738/0.064 ms
python.org は確か米国に有った筈。そこへのターンアラウンドが、1.6 ms
だってぇ?しかも、標準偏差が 0.06 ms。
これはもう凄いとしか言いようがない——自宅のしょぼいネットワーク (Flet's
光、マンションタイプ)と比べたらあきまへんがな、と言われそうだが :-)
で、「今一かなぁ」の方……
新サーバは数値計算のためではないので、 CPU 性能は大した問題ではない。ましてや、BLAS による行列計算の性能なんて関係無い、筈。 だけど、OpenBLAS/LAPACK でかなり遊んだので、 どうしても新サーバでの性能が知りたくなって……
「本筋」ではないので、さっさと片付けるつもりだったが、
Ubuntu-15.10 であっさりできた事が、14.04
ではなかなかうまく行かない。
そもそも pyvenv で Numpy をビルドすると OpenBLAS
を link しない……かなり右往左往したが、結局、
pyvenv での確認を諦め、かつ
update-alternatives --config libblas.so.3
と
update-alternatives --config liblapack.so.3
で最適の組合せを捜した。
で、ようやく
fukuda@conoha01:~$ ipython3
Python 3.4.3 (default, Oct 14 2015, 20:28:29)
Type "copyright", "credits" or "license" for more information.
IPython 1.2.1 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object', use 'object??' for extra details. In [1]: import numpy as np In [2]: np.show_config() ..... lapack_info: library_dirs = ['/usr/lib'] language = f77 libraries = ['lapack'] lapack_mkl_info: NOT AVAILABLE blas_info: library_dirs = ['/usr/lib'] language = f77 libraries = ['blas'] .... In [3]: A = np.random.rand(1000, 1000) In [4]: %timeit B = np.linalg.inv(A) 10 loops, best of 3: 134 ms per loop In [5]: C = np.random.rand(1024, 1024) In [6]: %timeit D = np.fft.fft2(C) 10 loops, best of 3: 50.5 ms per loopのような結果を得た。これでもまあ中々の物だが、Ubuntu-15.04 では 82 ms, Yosemite で 71 ms 出ていたので、到底納得行かない。 FFT との比が倍以上になっている事(つまり、CPU の素の性能は上っているのに、 BLAS/LAPACK の低効率がそれを減殺している)はもっと許せない……
で、「本筋ぢゃないんだけどなぁ」という「うしろめたさ」を無視して、 色々やってみた結果、 OpenBLAS のパッケージ libopenblas に liblapack.so.3 が含まれるのは 15.04 からで、14.04 は パッケージ liblapack の liblapack.so.3 を使わざるを得ない事が、スピードの差の原因、という事が判明した。
勿論、OS X でやったように、OpenBLAS の最新のソースからライブラリを作る、 なんて事も可能だろうが、16.04 に上げる際には無駄になる……
ここは 16.04 (の開発版)に上げてみよう、と決心する。
Ubuntu を 16.04 に上げる
既に Fusion 上の VM には、Ubuntu-15.04/15.10/16.04) をインストールしてある——python-3.5 を試すため。また、mod_wsgi (libapache2-mod-wsgi-py3) や netatalk が新しくなってるのでは、と期待して。なので、今回どれにするか迷ったが、16.04 にした。 どうせ互換性の問題に苦労するならば、 15.xx で一旦本格稼働してから後で 16.04 に上げるより、今、開発版の 16.04 に上げて、逐次サーバを入れていった方が容易だし、 ダウンタイムも短かくて済むだろう……
ただ、心配は、そんな事が VPS で可能だろうか、という事。 何しろ 14.04 は従来の方法でインストールしたのではなくて、ConoHa さんが作ったイメージを、コピーしてきたのに違いないから。
しかし例によって「失敗しても大した事ない」と思う事にして、とりあえず、
do-release upgrade
を試みる。
fukuda@conoha01:~$ sudo do-release-upgrade -cd Checking for a new Ubuntu release New release '16.04 LTS' available. Run 'do-release-upgrade' to upgrade to it. fukuda@conoha01:~$ sudo do-release-upgrade -dで、アップグレードがスタートした('-d' オプションがミソ。) 例によって、「ssh で login したコンソールから、upgrade しているようだが、 お勧めしない……」とかなんとか言われるが、無視。 あと、14.04 から変更した設定を、そのまま採用するかどうか聞かれたが、 これも「そのまま採用」を選んだ。 それやこれやで、都合 20 分で release-upgrade が終了。 「新しくインストールしたシステムで再起動するか(とかなんとか)」 聞かれたが、勿論 OK (Yes?)。
すると、reboot の後、ログインすると次のような、ログイン画面が表われる。 (Ubuntu-16.04 とはならず、'Xenial Xerus' となっているが、 これは、16.04 のコードネームらしい。)
これで、手短に OpenBLAS のスピードを評価してみる。 14.04 でインストールしてあるパッケージは、 そのままアップグレードされている筈だが、
fukuda@conoha01:~$ sudo apt-get install python3.5 python3.5-dev libpython3.5-dev fukuda@conoha01:~$ sudo apt-get install pyvenv-3.5 fukuda@conoha01:~$ sudo apt-get build-dep python3-numpy fukuda@conoha01:~$ pyvenv-3.5 pve35 fukuda@conoha01:~$ cd pve35 fukuda@conoha01:~/pve35$ . bin/activate (pve35) fukuda@conoha01:~/pve35$ pip install numpy ipython (pve35) fukuda@conoha01:~/pve35$ ipython
Python 3.5.1+ (default, Jan 13 2016, 15:09:18) Type "copyright", "credits" or "license" for more information. IPython 4.0.3 -- An enhanced Interactive Python. .... In [1]: import numpy as np In [2]: np.show_config() openblas_info: libraries = ['openblas'] language = c library_dirs = ['/usr/lib'] define_macros = [('HAVE_CBLAS', None)] ..... openblas_lapack_info: libraries = ['openblas'] language = c library_dirs = ['/usr/lib'] define_macros = [('HAVE_CBLAS', None)] ..... In [3]: A = np.random.rand(1000, 1000) In [4]: %timeit B = np.linalg.inv(A) 10 loops, best of 3: 50.1 ms per loop In [5]: C = np.random.rand(1024, 1024) In [6]: %timeit D = np.fft.fft2(C) 10 loops, best of 3: 56.9 ms per loop14.04 の 134/50.5 から、50.1/56.9 になった。 何故か FFT の結果が、若干悪くなっているが、BLAS の方は、倍以上の性能改善になっている。
これは、14.04 では liblapack.so.3 として OpenBLAS base
のものが選べなかったのに対し、15.04 以降は、それが選べるようになり、
さらに 16.04 ではそれがディフォルトになった為と思われる。
(つまり、update-alternatives
でわざわざ OpenBLAS base
のものを選ぶ必要が無くなった、という事。)
まとめ
とりあえずの「理解」と印象……- 殆んど純正の Ubuntu と違わないシステムが得られる。
- 違うのは(とりあえず ssh をできるようにするための)network 関連の「構成」のみ。
- 一旦、ssh login すれば、どんな設定も可能(IP アドレスは除く)
- release-upgrade さえ可能
- 性能
- ネットワーク性能は、素晴しいものがある。スループット: 480 Mbps, パケットのターンアラウンドタイム: 1.6 ms
- CPU 性能は、そこそこ。(2 core (Xeon) + 3 GB で、2 core (i5) + 4 GB と同等。)
- これで、月 1750円。一年で約 20,000 円。5 年分 で新品の ThinkPad X250 が買えるので、ほぼ同等の C/P。
2016-01-20 (Wed): 自宅サーバがクラッシュ
ついこの間、Mac-mini が勝手にリブートして焦ったばかりなのに、 今度は、自宅サーバ (Lark, ThinkPad X200, Ubuntu-14.04) がクラッシュした。今回は強制シャットダウン?
Lark に ssh login して、 pyvenv を作っていたのだが、pip-sync で matplolib か numpy だったかをビルドしている最中に、 いきなり応答しなくなった。すぐに机の下に置いてある ThinkPad を見たら、パワーインジケータ他が全部消えている。 パワーボタンに一切反応しない。多分「強制シャットダウン」だろう。 (約 1年前のクラッシュ ではインジケータは全部点灯していて、パワーボタンの長押しで落せた。)リカバリー
という事で、ちょっと前回と様子が違うが、とりあえず同じように、DC アダプタケーブルとバッテリを外して、5 分間放置。 その後再度継ぎなおしてスイッチを入れたら、無事起動した。 (やれやれ!)- 大急ぎでサーバ類の動作を確認。Apache 下の mailman, www.otacky.jp, www.waremo.com, 他は大丈夫(主要なページにアクセスしてみただけ。)
- dhcpd, bind も問題なく動いている様子。
- dovecot, Postfix も問題無し。
-
CPU 温度は正常
fukuda@lark:~% sensors acpitz-virtual-0 Adapter: Virtual device temp1: +38.0°C (crit = +127.0°C) temp2: +35.0°C (crit = +104.0°C) coretemp-isa-0000 Adapter: ISA adapter Core 0: +32.0°C (high = +105.0°C, crit = +105.0°C) Core 1: +35.0°C (high = +105.0°C, crit = +105.0°C)
- Battery も問題ない(まだ、三ヶ月そこそこなんだから当然)
fukuda@lark:~% upower -i /org/freedesktop/UPower/devices/battery_BAT0 native-path: BAT0 vendor: SANYO model: 42T4646 serial: 8030 .... battery .... state: fully-charged energy: 45.21 Wh .... percentage: 97% capacity: 97.2012%
-
前回同様、
/var/log/syslog
には、それらしい記録は残っていなかった。.... Jan 19 17:17:18 lark kernel: [1852158.415888] [UFW AUDIT] IN= OUT=eth0 SRC=192.168.0.11 DST=8.8.8.8 LEN=107 TOS=0x00 PREC=0x00 TTL=64 ID=38979 PROTO=UDP SPT=4077 DPT=53 LEN=87 Jan 19 17:17:18 lark kernel: [1852158.415906] [UFW ALLOW] IN= OUT=eth0 SRC=192.168.0.11 DST=8.8.8.8 LEN=107 TOS=0x00 PREC=0x00 TTL=64 ID=38979 PROTO=UDP SPT=4077 DPT=53 LEN=87 ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Jan 19 17:26: 20 lark rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="583" x-info="http://www.rsys log.com"] start Jan 19 17:26:20 lark rsyslogd: rsyslogd's groupid changed to 103 Jan 19 17:26:20 lark rsyslogd: rsyslogd's userid changed to 101
単にオタオタしていた時間と、冷却のために待っていた時間を合わせて約 9分。 この後ブートアップに 1分強かかっているから、 サーバとしてのダウンタイムは約 10分という事になる。
作業再開
クラッシュの原因は「温度上昇」だと思われるが、 どうしてこの寒い最中に(室温は約19°C)という疑問もあり、あまり自信がなかった。 なので、怖々、pyvenv の構築 (つまり pip-sync) を再開——クラッシュした時に やっていた matplotlib の build からからはじまった。今度は、sensors で CPU 温度を計りながらやってみた。すると、すぐに、
fukuda@lark:~% sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +92.0°C (crit = +127.0°C)
temp2: +97.0°C (crit = +104.0°C)
coretemp-isa-0000
Adapter: ISA adapter
Core 0: +97.0°C (high = +105.0°C, crit = +105.0°C)
Core 1: +87.0°C (high = +105.0°C, crit = +105.0°C)
のような値が得られた。Core 0/1 の温度は結構変動するが、0/1
とも最高温度は 97°C あたり。かろうじて、閾値 105°C を下回っているが、
変動の大きさや速さを見ていると、
いつこの閾値をトリップしても不思議ではない。
ちなみに、これは蓋を半開きにして、屏風のように立てた状態。
通常のポジションで蓋をすれば、もっと厳しくなるだろう。
という事で、どうやらこれがクラッシュの原因らしい。
一年半前のクラッシュ(ハング)は、暑い時期だったので、まあ解るが、 今回は寒いくらいなのに何故?という疑問が残るが、「pip-sync でやる matplotlib のビルドが例外的に負荷が重かった」事が、 直接の引き金になったのは間違いないところ。あとは、この経時変化の原因だが、 「ファンが劣化してきた」か、 はたまた「ヒートシンクの間の熱抵抗が増えた」のいずれか、またはその両方だろう。 温度変動の幅が大きくてかつ速い事、 また、排気の温度がほんのり暖い程度である事を見ると、後者かも知れない。
サーバ H/W の更新をどうしよう?
この前バッテリを新しくした時に、更新を先延ばしにして、Ubuntu-16.04LTS のリリースまでは、このままで、と思っていたが、 現状を見ていると、どうやらそうも行かないようだ—— これまで無事だったのは、単に運が良かっただけ。ThinkPad を分解してグリスを塗り直すか、 また中古の Laptop を手に入れるか、 それとも思い切って ConoHa (VPS) に移行するか……迷ってしまうなぁ
2016-01-17 (Sun): Mac-mini/Yosemite がリブートした
「お願いしますよ Apple さん (その 2)」とタイトルしたいところだが……Mac Pro が壊れて、 Mac-mini (Late 2014) に乗りかえてからちょうど一年になる。 使い始めた直後や Yosemite にして暫くは色々有ったが、 その後は重大な問題は殆どなく、安い、速い (MacPro より速い!)、 旨い(結構クールで安定している)の三拍子揃っていて、 かなり満足してきた。
偶に iTunes や App Store, Fusion, Photos, Skype が固まったりレスポンスしなくなる事は有ったし、 一度だけだが Finder が not responding になった事も有った。 しかし、これらも Fusion や Yosemite のバージョンが上がってくるにつれて (つまり、夏以降は)落ち着いてきていた。 それにつれて、段々大胆になってきて、Fusion の上では、Ubuntu が二つ走りっぱなし、BasiliskII は常に開いていて、 Terminal からは、常に 3~5 台のサーバに ssh login しているという状態だった。それでも、OS のハングは無かった……
が、一周年を記念するかのように、今日いきなり(勝手に)リブートした! 正確には通常のリブートではなく、一旦完全に表示がブラックアウトして、 自動で cold start が始まった、という感じ。
何が悪いか解らない……
起動後「Apple へクラッシュをレポートするか?」というペインが表われたが、
system.log
を見るからいいや、と思って即 send
とやってしまったが、その system.log には、
どこでリブートが起きたのか解らない。
気休めに、Repair Disk Permission をやって、とりあえず様子を見る事にする……
2016-01-06 (Wed): お願いしますよ Apple さん
その前に、DoCoMo さんへ「文句」の追加……お願いしますよぉ、DoCoMo さん (その 2)
「お願いしますよぉ、DoCoMo さん(その 1)」は、少々八つ当たりだったかも。 1GB を購入したら、四国の田舎でも 1.64/0.08 Gbps 出て、然程のストレス無しに Internet にアクセスできた。 だから、ホントに「お願い」しないといけないのは、 ウチの○○○さんかも。しかも、その後よく見てみると毎月 20GB を使い切っている模様。 つまり、月末になると、いつも「そろそろ l28 kbps になるのでは?」との心配をしないといけない訣だ。そういう事もあって、またもや「公衆無線 LAN」に挑戦する事にした。 (「またもや」というのは、これまでも、SB さんや NTT さん他の御厄介になった事があるから。) 今度は勿論 DoCoMo さん。課金が、iPhone と合わせて、になるし、 何より安い(300 円/月で、最初の月は無料)。 で、とりあえず新幹線に乗る前に、契約の変更(公衆無線 LAN の追加)だけをやっておいた——これがまた解り難いんだなぁ :-p
が、実際に新幹線 (N7000) で、association/login しようとしたら、 契約の変更なんて目でないくらい、ややこしい…… 新大阪から使用可能になるのだが、京都あたりでおもむろに設定を始めたが、 とりあえず使えるようにできたのは、名古屋を出てしばらくしてから。 で、ようやく Internet にアクセスできるようになったが、 スピードが出ていないからか、レスポンスが遅いからか、 満足に名前解決さえできてないように見え、 Twitter/Facebook はおろか、otacky.jp でさえ満足に接続・表示できない。
こんなに苦労して設定・接続してこの為体では、とてもぢゃないが、 使い続ける気はしない。即「解約」する事にした。
iPhone-USB が認識されない
行きの新幹線で USB 接続の tetheringがおかしくなり、おまけに iPhone の充電が始まらなくなって大いに焦ったが、色々弄り倒しているうちに、 なんとかまた動くようになったのだった。その後一週間程、一日数度の (iPhone と MBA の間の)USB ケーブルの抜き差しや WLAN On/Off を含めて、結構無造作に扱ったが、 tethering に問題は出なかった。それが何と、潮風の中で WLAN でテザリングした後、N7000 の中で USB ケーブルを継いでも、MBA に iPhone が認識されない——克服できた、 と思った症状がまた表れた訣だ。
自宅に戻って、腰を落ち着けて原因追及するが、どうしても直らない。
しかも何と Mac-mini の Yosemite でも同じ問題が起きる。今のところ Yosemite (Mac-mini) でテザリングを使う予定はないのだが…… 何故かムキになってゴチャゴチャ弄り始めてしまった。途中、「iTunes の再インストールで直る」とか、「AppleUSBEthernetHost.kext を古いものと置き 換えれば直る」とか、いろいろ情報が有ったが、前者はやってみたが「効果無し」、 後者は「あまりに大変すぎて」やれず……
しかし、「一度はうまく行った」記憶があるので、 そんなに大変な事ではない筈……と思い悩んでいると、ふと、Network Device で、Wi-Fi 以外を全部消去した事があるのを思い出した。 で、今度は USB Ethernet(二つ)を消してみたら、これが大正解。iPhone-USB デバイスが自動で connected になった。 成程、「ごちゃごちゃやってる内に直った」の正体はこれだったらしい。
とりあえず「目出度し目出度し」であるが、気になるのは、 USB Ethernet デバイスを持たない Mac-mini で、何故 iPhone USB が Connected にならないか、であるが、これは少しの試行で、 Thunderbolt 1/2 がそれである、と分った。 つまりThunderbolt 1/2 を delete すると、iPhone USB が使えるようになるという事——ただ、まあ、Mac-mini から tethering を使う状況は有りそうもないけど。312/1,781,557 Taka Fukuda Last modified: 2019-01-01 (Tue) 13:54:00 JST