Main Menu
いらっしゃいませ
入口 (Home)
出口 (リンク集)
われも工房（同）
サイト内全文検索
サイト・プロフィール New!
[RSS] RSS 購読
[twilog] Twilog
オタク系オヤジへの道
オタク日記 New!
 倉庫 19(Q1, Q2, Q3), 24Q2
 倉庫 18(Q1, Q2, Q3, Q4)
 倉庫 17(Q1, Q2, Q3, Q4)
 倉庫 16(Q1, Q2, Q3, Q4)
Mac でハック (1), (2)
自宅サーバを立てる
Python Corner
つれづれなるままに
われもかう通信
 倉庫 13(Q2 Q3) 14Q1
San Diego 通信
極私的批評空間
 倉庫 2002-2010
Lund 通信（遠島日記）
Site Management
Access Count
Server Status

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

(↓次 ↑前 目次 Home)

目次

2016-03-30 (Wed): 自宅サーバ引越し (その 5) Mailman
2016-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 年

(↓次 ↑前 目次 Home)

2016-03-30 (Wed): 自宅サーバ引越し (その 5)—Mailman

インストール

Mailman アーカイブの「移行」にはいつも苦労してきた。 最近の「苦労」は二年前だが、 その時も deb パッケージインストールから始めたものの、結局挫折して、 また mailman-2.1.14-j7 に戻る、という右往左往をやったのだった (しかも、その -j7 のインストールも大変だった)。

なので、今回、deb パッケージにするか、従来通り mailman-2.1.14-j7 から始めるか、 ちょっと迷ったが、「ここらで一気に苦労しておいて、先々の移行を楽にしよう」 と殊勝な決心をして、勇躍取り掛かったのだが……

何故か Ubuntu Mailman のインストールマニュアルが二種類有る。

最初それに気がつかず、 ふたつの間を行ったり来たりしていて、そのせいで、うまく行かなかったのでは？ という疑念もあったので、再度後者に沿ってやってみた。 (後者も「16.04 向け」とは明記されていないが、 最終更新が 2015-08-17 で、少くとも前者より新しいので。) このうちで、Mailman + Postfix + Apache2 の組合せのところを取り出して実行すればよく、 ステップは然程多くない。

ただ、例によって、一部「誤り」（というか不適切な記述）が残っているようだ。

  1. 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 =
    となっていないといけない。
  2. /etc/postfix/transport: 上の transport_maps が blank であるので、このファイルも不要。
  3. /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. #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. #2) Unicode で書かれた「説明」を、'description' attribute に代入するのに、明示的に UTF-8 で encode してやらないといけない。 (さもないと、下のスクリーンショットでの Mmtest3 のように、Python の Unicode 表現」がそのまま表示される。)
ここまでで、http://lists.otacky.jp へアクセスすると、 Mailman のフロント（一覧）ページへ行ける。
Mailman Front Page
宅外サーバ・メーリングリストのフロントページ
(クリックして拡大)
(↓次 ↑前 目次 Home)

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. #1) mydestination がディフォルトのままでは、例えば fukuda@otacky.jp へはローカルユーザと見做されない。これを救うために、myhostname を domain name ('otacky.jp') にしていたのだった。しかし、この弥縫策はその後の「病膏肓」の元になる…… ここで、最後に $mydomain をつけておけば、他は殆どディフォルトの値が使える。
  2. #2) これもディフォルトは 'all' だが、gmail.com へは何故か IPv6 でアクセスしようとし、毎回 fail となるので、IPv4 決め打ちにした。
  3. #3) local 配送は、procmail にやらせるための設定。 これまでは ~/.forwarder ~/forward にその旨記述していたが、 設定を一箇所に固めておくという意味で良さそうなので、こちらにした。
  4. #4) Mailman のための aliases 設定。(後の aliases が無かったらエラーになるかも知れない。）
  5. #5) 送信の際に Posting Server に submission port (587) 使うための certification と key の設定。
  6. #6) 上記の Posting Server をここで指定する。 今回は、自らが Posting Server になるので、指定無し、にしておく。 それぞれの MTA に port 25 で配送する。
ここまでで、digoc02 内の sendmail で配送の試験ができる。 
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. #1) この設定で殆ど唯一の「判断」が要求される箇所。SASL library を Dovecot もしくは Cyrus のどちらから選ぶか、とう事。Dovecot は必須なので、その SASL ライブラリを流用する事にした。
  2. #2) 随分解釈に悩んだが、つまりは、これが 'no' の場合、クライアント側から STARTTLS を呼ばずに auth ができる、という事。 それでは、態々 TLS にした意味が無いような気がして 'yes' にした。 その場合 port 25 からの local user へのメッセージも tls_auth_only になるのか、と思ったが杞憂だった。（RCPT TO: で local user 以外のアドレスを指定すれば、拒否する。）
  3. #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, 
                      .....
ここまでで、smtpd daemon にアクセスできるようになっている。 さらに、Maildir がポートされていて、procmail がインストールされてあれば、 次のような試験が可能…… (青い字は、手で入力した部分) 
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. #1) 上記の smtpd_tls_auth_only が、'no' であれば、ここに 
    250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
    という行が入り、starttls しないまま、auth plain ..... でログインが可能。
  2. #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. #3) 'To:' フィールドではなく、実際の配送先を指定。実際に存在する local アドレスなので、問題なく Ok となる。
  4. #4) 同上。non-local であるが、自身を authenticate しているので受けつけられる。
ちなみに、port 25 に対しては 
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. #1) Postfix が ESMTP なので、ehlo でも可。但し STARTTLS が「能力」 として表示されても、それを実行できない（Ctrl-D 止まってしまう）ので、 結局 Auth はできない。
  2. #2) rcpt to: が local address であれば (すなわち、mydestination の中にあれば) 配送を受けつける。
  3. #3) しかし、配送先に local address 以外を指定すると (つまり、リレーを依頼すると) 拒否される。
という事で、上の submission request と合わせて、期待通りの動きをしている。

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) になった。 さて、切れ味はいかがなものか？
(↓次 ↑前 目次 Home)

2016-03-16 (Wed): 自宅サーバ引越し (その 3)—Mail System/Dovecot

これまた予期した通り、Mail 周りの移行はとっても大変だった……

ML (Mailman) のマイグレーションは大変だろうな、 と身構えていたが、（実際大変だったが） 新しい Ubuntu パッケージでは、 旧日本版インストーラの「面倒臭さ」（失礼）が大分改善されていて、 一通り動くようにするのに然程時間はかからなかった。

問題は「その後」で、せっかく So-net の OP25B の外に Linux マシンを置けるんだから、full-fledged の SMTP Posting Server を作ってやろう、なんて目論見んだのが間違いの始まり。 これにはかなり梃摺った。

全体構成（の構想）

概略次のような構成を目指した。
Mail System Configuration
自宅外サーバのメールシステムの概要
(procmail へ送る旨の設定は、.forward から main.cf に変更した)
上の「目論見」をこの構成図に即して言うと
  1. Postfix へのメール受信は (図中の smtpd が担当) 、
    • ML のリストを含む、local user へのメールを、port 25 で受け (従来通り)、
    • Posting Server としての入力を、port 587 で受ける
  2. Postfix からの (つまり、上の port 587 で受信したメール、ML からのメールの) 送信は、
    • Port 587 で他の Posting Server に送る (従来通り)
    • Port 25 でインターネットへ直接配送する
    のいずれかを選択する。(後者を実現する事が、即ち Posting Server にする、という事に違いない？)
  3. Dovecot で IMAPS (IMAP4 over SSL) によるアクセスを実現して、 既存のメールアーカイブを引き継ぐ。
  4. Mailman を、Ubuntu のパッケージで実現する (勿論、既存のアーカイブをポートする)
くらいになろうか。これらも含めて、「構成要素」の概略は

世の中変っているんだよ……

かつては、Sendmail の代りに Postfix さえ使えば、 メールサーバの構築なんて簡単、 と嘯いていた時代も有ったのだが、今は Postfix でさえ設定が大変。 大昔の事とて記憶が定かではないが、どうも So-net さんが OP25B を始めた頃から、面倒になったような気がする。 その後も、スパム対策とかセキュリティの確保とかとの理由で、 ますます複雑怪奇になって行く。

今回の Mail Server 構築にあたっては、 当然それらのサーバが「動作環境」になる訣だが、 それらを使っての「動作確認」にかなり四苦八苦した。 その理由の一つに、これまで当り前のように使ってきた外部のサーバが、 必ずしも期待通り動いてない、という事がある。

早い話が、テストのために gmail.com の IMAP Server や、SMTP Posting Server を使おうとすると「わけわか」になりやすい、という事。

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. #1) SSL を要求する。つまり、IMAP2/3 でのアクセスは拒否する。
  2. #2) lets encrypt の cert.pem から
  3. #3) 同 rsa_private.key から
  4. #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 が行えている。

いくつかのコマンドを投げてみて確認した知見:

この 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 の問題であると思われる。

(↓次 ↑前 目次 Home)

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 が大きくバージョンアップされた事で、少々問題が出た。

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 にポートする事にした。目論んだ手順は、

  1. 新サーバ上で、pyvenv を作り、 django, mod_wsgi, matplotlib 以下、必要なモジュールを pip-compile & pip-sync でインストール。 (「Django Project で Virtual Host」を参照。)
  2. git clone で pyvenv 下に Application (スクリプト) をコピー 
    fukuda@digoc02:~/pve35$ git clone git://otacky.jp/wrm_dms.git wrm_dms
  3. 別途、名目のみの App を作って、 
    (pve35) fukuda@digoc02:~/pve35$ python manage.py startapp tmpapp
    最新版の mysite/wsgi.py と mysite/settings.py を得る。
  4. 上記の settings.py をフレームワークにして、wrm_dms の settings.py を 書き直す。
  5. wrm_dms のディレクトリ構成を作り直す（db.sqlite3, static files, templates files (xxxx.html) の位置を最新の Django のディフォルトに合わせる。）
  6. 新ディレクトリ構成に合うように、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。
  7. index/views.py, user/views.py を変更。 上記の runserver で、エラーが出なくなる事を確認。 （Template file の PATH の問題が大きい筈。）
ここまでで、一応 Django-19.x 対応にはなっていると思われる。 さらに、これを WSGI を介して、apache2 からアクセスできるようにする。
  1. wrm_cwt での「対応」を、wrm_dms にも適用する。
  2. apache2 動作のために、static files を所定の位置に集める 
    (pve35) fukuda@digoc02:~/pve35/wrm_dms% python manage.py collectstatic
  3. 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
    とやる。
  4. /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. #1) のように WSGIPythonPath で指定する事はできず、
    2. #2) のように、WSGIDaemonProcess の中で、python-path= で指定してやらねばならない、という事。
    (それなりに筋が通っていたディレクティブの使い方を、 態々ややこしくしたように見えるが……とにかくこうしないと動かない）
  5. mod_wsgi モジュールと上記 wrm_dms.conf を enable する 
    fukuda@digoc02:~% sudo a2enmod mod_wsgi
fukuda@digoc02:~% sudo a2ensite wrm_dms.conf
  6. apache2 をリスタート 
    fukuda@digoc02:~% sudo systemctl restart apache2
後で見直したら我ながら「怖気をふるう」ような面倒臭さだが、 前半のデバッグを runserver でやれる事で、かなり負担が軽減できたように思う。（後半は Fusion 上の 15.10/16.04 で散々経験済みなので、見かけ程大変ではない。） お蔭様で、丸二日程の作業で wrm_dms が動くようになった。
(↓次 ↑前 目次 Home)

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. #1) このコマンド一発で、16.04 LTS へアップグレードされる。20分程かかる。
  2. #2) ここで (useradd でなく）adduser を使うのが一番簡単。
  3. #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 で作業する環境はととのったので、 一般的な設定を行う

開発環境としての評価

DO にはコンソールも準備されているが、迷わず ssh/tramp ベースの開発環境にした。つまり、常に Falcon (Mac-mini, OSX 10.11.5) の Terminal.app と EmacsMac.app からアクセスする、 という事。（もともと GUI もつかえる Fusion や ThinkPad の上の Ubuntu/Raspbian でも、ssh で通していたので……）
(↓次 ↑前 目次 Home)

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 は使い続けたいな、なんて思っていたけど、その熱も冷めた。 何十箇所あるか知らないけど、 登録したメールアドレスを今から変更する準備をしよう。

(↓次 ↑前 目次 Home)

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 （つまりストレージを増やさない）方式を取っておく必要がある。）

(↓次 ↑前 目次 Home)

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 さんのコンパネに有る微妙な間違い (「動作中」というべきところを「起動中」とするような) や重複が無く、よく整理されているという面も大きいと思う。
DigitalOcean control panel
Droplets を一個作製した直後のコントロールパネル
（[Create Droplet] ボタンで新droplet の config を始める。）

ただ、region の選択はちょっと迷った——DigitalOcean は Tokyo リージョンが無いので。東海岸、ヨーロッパ、カナダは論外として、 西海岸とシンガポールのどちらにするか…… （結局、両方にサーバを立てて、性能を比較する事にした。）

Droplet 立ち上げ

ConoHa さん同様、OS をインストールするのではなく、 イメージをダンプする方式らしい。55 秒で起動できる、というのがウリだが、 やってみると確かにそれ以下でインストールは完了し、ssh ログインできるようになる。

初期設定を ConoHa さんとの比較の形で纏めてみると、

Release-upgrade

Ubuntu-14.04(.3) から、16.04 のアップグレードは何の問題もなくスムースだった（当り前！？） ただ、OS イメージのダンプ（？）のようには迅速には行かず、 大体 11 分から 12 分くらいかかった。

パフォーマンス

とてもシステマティックとは言えないが、 「箸棒かどうかくらいは解る」程度の比較をしてみた。
各 VPS の構成・パフォーマンス比較
Performance Item ThinkPad X200 Fusion VMConoHa VPS DigitalOc. (SF) DigitalOc. (SG)
OS (Ubuntu)-14.04.3-16.04-16.04 -16.04-16.04
CPU Info
  core #x 2x 2x 3 x 2x 2
  modelCore2 Duo P8600Core i5-4308U Xeon E5-2660 Xeon E5-2630Xeon E5-2630L
  clock (MHz)8002800 260023002000
  cache (MB)307230724096 153604096
  bogo mips47885599520046004000
RAM (GB)22222
DTR *1) (MB/s) 3.62.623.4-64.649.965.4
TAT *2) (ms) -- 0.56 ± 0.119.4 ± 4.5129.8 ± 3.8 77.3 ± 4.5
fft.fft2 *3) (ms) 107 ± 0.654.1 ± 1.551.7 ± 2.184.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

まとめ

途中で、数値解析のためのパフォーマンスに拘ったりして、少々横道に逸れたが、 本来の HTTP サーバだけを VPS で立てるとして、これまでの知見を纏めると 最後の点は、「この安定性がこの先も担保されるかどうか」に関係する、と思わ れるのだがよく解らない。ともあれ、ここまでのところでは、 自宅サーバの置き換え（あわよくば、商用サイトに拡張する）ためには、 DigitalOcean (SG) にしておくのが良さそうだ。
(↓次 ↑前 目次 Home)

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 に上げたのは、
  1. Python-3.5 (と python3.5-venv) が deb になっているのでは？
  2. mod_wsgi の deb が 4.4.x に上っていて、 危ういトリックを使わなくてよくなっているのではないか？
  3. systemd への対応がより進んでいるのではないか？
という期待が有ったからだが、結論から言うと 1. 以外は期待外れだった。

最初から 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 にアクセスすると、以下のような表示が得られる。
ConoHa server-status w/o wsgi
apache2 パッケージのみをインストールした状態の 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
ConoHa apache with wsgi
mod_wsgi-4.4.22 を enmod した Apache2
(↓次 ↑前 目次 Home)

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 が途中で切れる事があるというレポートが多かったし、実際私も経験がある。）

2016-01-29 (Fri): 補遺
なんてのは、私が古い古いアダプタを使い続けているから、で、 今や各社から出ているし、1000Base-T 版もあるのね。 うむ、これなら、やってみる値打ちが有るかも……

で、ここはもう VPS へ行くしかないだろう。しかも、 Ubuntu-16.04 LTS が出てから、なんて悠長な事は言っていられない。 （しかし、VPS が Virtual Private Server の略だ、というのを今知ったようでは、 あんまり急ぐのは無理という気もするが……）

ConoHa VPS

あまりよく調べた訣ではないが、 中小規模サーバ向けとしては、ConoHa と「さくら」が双璧？らしい。 課金がより柔軟（初期費用無し、H/W のアップグレードに契約更改が不要） というところを買って、ConoHa を最初に試す事にした。

そう決めて取り掛かったものの、いきなり暗雲が……。 とにかく「全体像」がよく解らない。そもそも、既存のユーザからの「情報が少ない」 という批判が多く見られたが、それでも「なあに、こちとら (自宅) サーバの構築には、些か経験が……」なんて高を括っていた。 しかし、「さくら」と比較するためのレベルでもピンと来なかったが、 決心した後真面目にサイトをあちこちを覗いていみたも、一向に理解が進まない。

どれも、私にとっては「使えるかどうか」にかかわる重要なポイントだが、 どうもはっきりしない。

でも、まあ、ダメとなっても、すぐやめたら、数百円の出費だし…… という事で、とりあえず使い始めてみるる事にした。

アカウントを作るのは比較的スムース。

しかし、次に出てきた画面で「次は何をすればいいんだ？」と悩んでしまった。 要は、サイドメニューの「サーバ追加」 をクリックすれば良かったのだが…… それで出てくる 「コントロールパネル」（下図）も、とても「使い易い」とは言えないが、 迷ったらディフォルトを選ぶ事で、 なんとか起動してログインできるようにはなる。

ConoHa adding server
サイドメニューの「サーバ追加」をクリックすれば、 新サーバの概略が設定できる
これで右下の「追加」を押せば、インストール・システム構築が始まり、 下のサーバリストが表示される。「ステータス」が「構築中」から「起動中」 に変われば、構築は完了している。（ほんの数十秒しかかからない！）
ConoHa server list
サーバを新たに構築して、「起動中」となったところ
ここで、「ネームタグ」をクリックすると表われるページで、「ネットワーク情報」 から 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 できる。

ネットワーク設定他の初期設定

ここまでで先の疑問に対しては、一部答が得られていて、 Ubuntu のインストール直後の状況としてはかなり「特異」だが、 とにかく、ssh でログインできるようになった訣で、私には好都合。

早速、（自分にとって）普通の環境にする。 

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 のコードネームらしい。）

Ubuntu-1604 in ConoHa
1604 の開発版にログインできた！

これで、手短に 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 loop
14.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 のものを選ぶ必要が無くなった、という事。）

まとめ

とりあえずの「理解」と印象…… 自宅サーバから完全に乗換えられそう。 （ひょっとしたら、念願だった「（数値計算用）ベランダ・サーバ」も、 これの 16 CPU あたりで代替可能かも知れない。）
(↓次 ↑前 目次 Home)

2016-01-20 (Wed): 自宅サーバがクラッシュ

ついこの間、Mac-mini が勝手にリブートして焦ったばかりなのに、 今度は、自宅サーバ (Lark, ThinkPad X200, Ubuntu-14.04) がクラッシュした。

今回は強制シャットダウン？

Lark に ssh login して、 pyvenv を作っていたのだが、pip-sync で matplolib か numpy だったかをビルドしている最中に、 いきなり応答しなくなった。すぐに机の下に置いてある ThinkPad を見たら、パワーインジケータ他が全部消えている。 パワーボタンに一切反応しない。多分「強制シャットダウン」だろう。 （約 1年前のクラッシュ ではインジケータは全部点灯していて、パワーボタンの長押しで落せた。)

リカバリー

という事で、ちょっと前回と様子が違うが、とりあえず同じように、DC アダプタケーブルとバッテリを外して、5 分間放置。 その後再度継ぎなおしてスイッチを入れたら、無事起動した。 (やれやれ！)

作業再開

クラッシュの原因は「温度上昇」だと思われるが、 どうしてこの寒い最中に（室温は約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) に移行するか……迷ってしまうなぁ

(↓次 ↑前 目次 Home)

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 をやって、とりあえず様子を見る事にする……

(↓次 ↑前 目次 Home)

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 になった。 成程、「ごちゃごちゃやってる内に直った」の正体はこれだったらしい。

iPhone USB Setting 2
USB Ethernet デバイスを delete すれば、iPhone USB との接続が確立
とりあえず「目出度し目出度し」であるが、気になるのは、 USB Ethernet デバイスを持たない Mac-mini で、何故 iPhone USB が Connected にならないか、であるが、これは少しの試行で、 Thunderbolt 1/2 がそれである、と分った。 つまりThunderbolt 1/2 を delete すると、iPhone USB が使えるようになるという事——ただ、まあ、Mac-mini から tethering を使う状況は有りそうもないけど。
iPhone USB Setting 3
Mac-mini の場合は、iPhone USB と干渉するのは Thunderbolt 1/2
251/1,788,181 Valid CSS! Valid HTML 5.0
Taka Fukuda
Last modified: 2019-01-01 (Tue) 13:54:00 JST