オタク日記

(Mac と Linux, 2014Q4)

目次

2014-12-23 (Tue): Pyvenv で Zinnia をインストール
2014-12-15 (Sat): Django App を mod_wsgi で「実戦配備」(その 2)
2014-12-13 (Sat): Django App を mod_wsgi で「実戦配備」(その 1)
2014-12-06 (Sat): (久し振りに)国際ローミング
2014-11-12 (Wed): Emacs-w3m vs shr.el
2014-11-08 (Sat): Emacs 再訪
2014-11-01 (Sat): EmacsMac.app-5.0:
2014-10-25 (Sat): iTunes, Emacs, Xcode ...:
2014-10-14 (Wed): MathJax, Prettyprint 再訪
2014-10-04 (Sat): Bash の脆弱性に関するミステリー
2014-10-01 (Wed): Raspberry Pi で WiFi AP

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


2014-12-23 (Tue): Pyvenv で Zinnia をインストール

2015-01-05 (Mon): urls.py を追加

Blog Engine はいつも手強い

大昔に Zope や Plone を試した事があるが、 そもそもなかなか動くようにできなかったし、 たとえどうにか動くようになっても、その後 Python や framework を新しくすると止ってしまうという事がよく有った。

一時的に公開している Waremo DMS などは、それ程高度なプログラミングの手法を使っていない事もあり、 何とか動くようにできたが、それでも、 Quadra (OSX) から Lark (ubuntu) にポートするのに大分手間取った。 これは多分、両者が提供する環境に大きく差が有るからに違いない (私が Python-3 に拘っている所為もあるだろうが、それは措くとして :-)

なので、blog-engine のインストールと実稼働とで、 できるだけ、同一の環境で、作業したい…… となると、pyvenv (Python Virtual Environment) の出番だろう。 しかし、これについても、あんまり良い思い出が無い。

もう半年程前になろうか、Mezzanine を試してみたことがあり、 その際、home page にあるチュートリアルが良さげ(初歩から手とり足とり、 という感じ)だったので、それを読んでその記述を辿ってみた。 が、これがさっぱり思うように動いてくれない。 というより、抑々そこにある virtualenv (virtualenvwrapper) の説明がさっぱり理解できなかった。

それで、virtualenv を使わずにトライしてみて、 何とか動くようにできたが、しかし今度は、その使い方というか、 ページのカスタマイズの仕方がよく分らない。(Django の Application ではなく、Project になっている所為。)

Zinnia を試す

なので、今回は、Django Blog-Engine の界隈では Mezzanine に次ぐ評判の Zinnia を試してみた。 個人的には、 等が嬉しいような気がする。

が、これのインストールは端からつまずいた。 というか、色々な時点で各パッケージの依存関係で行き詰まるのだが、 それから色々弄っていると、ますます「わけわか」になる…… という典型的「投げ出しモード」……

だが、かろうじて踏み止まり、virtualenv (pyvenv) で再挑戦する事にした。

PyVenv

先にも書いたが、Mezzanine の時に virtualenv には凝りているのだけど、 環境に関するトライアル・エラーが必要な場合にシステムの Python, PIL, Django を一々弄っていては大変だし、 第一、それまでに実装したアプリとの backward compatibility が心配になる。 という事で、「ちょっとだけよ(つまずいたらすぐ止める)」モードで、 またトライする事にした。

ひとつだけ明るいニュースがあって、それは、Python-3.3 から pyvenv という名前の virtualenv を作るツールがバインドされ、 -3.4 からは、さらに pip も自動でインストールされるようになった、という事。 これを使えば、(実はいろいろ紆余曲折は有ったが :-)

fukuda@quadra:~% pyvenv-3.4 zinnia2               
fukuda@quadra:~% cd zinnia2
fukuda@quadra:~/zinnia2% source bin/activate
(zinnia2) fukuda@quadra:~/zinnia2% echo $PATH
    /Users/fukuda/zinnia2/bin:/opt/local/libexec/gnubin:/opt/local/bin:/Users/fukuda/script:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
(zinnia2) fukuda@quadra:~/zinnia2% which pip 
    /Users/fukuda/zinnia/bin/pip
とするだけで、pip (PyPI) を使って新たな環境を築く準備ができてしまう。 (pyvenv.cfg の設定も、default のままで良いだろう。) ちなみに、Zsh prompt の頭に付いている (zinnia2) が、その環境に居るというインジケータになっている。

それにしても、(一旦インストールできたら) これは素晴しいアイディアというかツールだと思う。 単純かつ効果抜群。これだけでも、Python-3.4 にした甲斐が有ったと思える。

Zinnia インストール

(zinnia2) fukuda@quadra:~/zinnia2% pip install django-blog-zinnia  #1
(zinnia2) fukuda@quadra:~/zinnia2% pip freeze
Django==1.7.1
beautifulsoup4==4.3.2
django-blog-zinnia==0.15
django-contrib-comments==1.5
django-mptt==0.6.1
django-tagging==0.3.4
django-xmlrpc==0.1.5
pyparsing==2.0.3
pytz==2014.10
(zinnia2) fukuda@quadra:~/zinnia2% pip install pillow  #2
(zinnia2) fukuda@quadra:~/zinnia2% rehash              #3
(zinnia2) fukuda@quadra:~/zinnia2% django-admin.py startproject myblog
ここに、
  1. #1) 先に django をインストールする必要はない。 (それをやると、たまにおかしな事がおきる。)
  2. #2) pillow (PIL) だけは別途インストールする必要がある。 (無いと後の方になって文句を言われる。)
  3. #3) これも次のコマンドのために必要(多分インストーラのバグだろう)
くらいが注意すべき点。 ここまでで、~/zinnia2/myblog/myblog の下に、Django の myblog プロジェクトに必要なファイル群ができるので、settings.py urls.py を、下記のように編集する。("# added" とか "# changed" とある行が、変更もしくは追加した箇所。)
# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
import os
BASE_DIR = os.path.dirname(os.path.dirname(__file__))
SECRET_KEY = 'xxxx'

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True
...

# Application definition
INSTALLED_APPS = (
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'django.contrib.sites', # added  #1
    'django_comments',      # added
    'mptt',                 # added
    'tagging',              # added
    'zinnia',               # added
)

MIDDLEWARE_CLASSES = (
    'django.contrib.sessions.middleware.SessionMiddleware',
    ...
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
)

ROOT_URLCONF = 'myblog.urls'
WSGI_APPLICATION = 'myblog.wsgi.application'
    
# Database
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',          #2
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    }
}

# Internationalization
# https://docs.djangoproject.com/en/1.7/topics/i18n/
LANGUAGE_CODE = 'ja-jp'        # changed from 'en-us'
TIME_ZONE = 'Asia/Tokyo'       # changed from 'UTC'
USE_I18N = True
USE_L10N = True
USE_TZ = True                   
SITE_ID = 1                       # added          #3

STATIC_URL = '/static/'
## 2014-12-22 (Mon): 
TEMPLATE_CONTEXT_PROCESSORS = (                    # added
  'django.contrib.auth.context_processors.auth',   # added
  'django.core.context_processors.i18n',           # added
  'django.core.context_processors.request',        # added
  'zinnia.context_processors.version',  # Optional # added
)                                                  # added
  1. #1) django native の application だけど、改めて追加の要あり。
  2. #2) Django-1.7 から?このようなディフォルトになったようだ。
  3. #3) ディフォルトの設定にはこの行が抜けているが、これは必須(Django の bug?)

*** 2015-01-05 (Mon): 追加 ここから ****
urls.py は、
from django.conf.urls import patterns, include, url
from django.contrib import admin

urlpatterns = patterns('',

    url(r'^admin/', include(admin.site.urls)),
    ## added
    url(r'^weblog/', include('zinnia.urls', namespace='zinnia')),
    url(r'^comments/', include('django_comments.urls')),
)
とする。
*** 2015-01-05 (Mon): 追加 ここまで ****
こうしておいて、
(zinnia2) fukuda@quadra:~/zinnia2/myblog% python manage.py migrate
とやると、Zinnia の「登録」が完了する。(Django-1.6 までは、manage.py createdb, manage.py syncdb とかしていたが、-1.7 からこんな風に簡略化された?)

動作確認

(zinnia2) fukuda@quadra:~/zinnia2/myblog% python manage.py runserver 0.0.0.0:8000
とすると、dev server が立ち上がる。Firefox でアクセスしてみると、 下のようなページが表示された。
Zinnia's Star-up Screen
Zinnia の(ブランク)スタートアップ画面

2014-12-15 (Mon): Django App を mod_wsgi で「実戦配備」(その 2)

公開サーバ (Lark) でゴチャゴチャやって Apache を止めてしまっては不味いだろう、 という事で、ステージングサーバ (Quadra) でまず味見したのに、 そこで動いた App を、 git push/pull で Lark に移しただけではうまく行かなかった……

そうは言っても、内心ではそんなにスンナリ行くと信じていた訣ではない。 何しろ「環境」が相当違っている。前回までのトライアルの環境は、

あたりで、どれ一つとして一致してない…… :-)

この環境に repository 越しに git push/pull で一昨日のファイルを転送してみたが、 案の定、うまくいかない。/var/log/apache2/error.log に、

[Sun Dec 14 16:05:43.967833 2014] [:error] [pid 30033] Exception ignored in: <module 'thr
eading' from '/usr/lib/python3.4/threading.py'>
[Sun Dec 14 16:05:43.967884 2014] [:error] [pid 30033] Traceback (most recent call last):
[Sun Dec 14 16:05:43.967899 2014] [:error] [pid 30033]   File "/usr/lib/python3.4/threading.py", line 1288, in _shutdown
[Sun Dec 14 16:05:43.968567 2014] [:error] [pid 30033]     assert tlock is not None
[Sun Dec 14 16:05:43.968589 2014] [:error] [pid 30033] AssertionError: 
のようなメッセージが吐き出されている。

いきなり「わけわか」状態となったが、Django の l.6.x, 1.7.x を wsgi で deploy するにあたっては、皆さん色々苦労されているようで、 stack-overflow にも Q/A がいくつか有った——wsgi を 3.2+ にするとか、.../mysite/wsgi.py を弄るとか、それらしい Answer はいくつも有ったが、しかし、どれも問題解決にはつながらない……。 結論から言うと、(OSX の時と同様)mod_wsgi を一からコンパイルする、 が正解だった……そもそも、 Ubuntu にパッケージ (-3.4) があるから踏み切ったのに。

しかも、Apache の tool の apxs のインストールから始めないといけない…… が、configure と build はスムース:

fukuda@lark:~/builds/mod_wsgi-3.5% apt-cache search apxs
apache2-dev - Apache HTTP Server (development headers)
fukuda@lark:~/builds/mod_wsgi-3.5% sudo apt-get install apache2-dev
fukuda@lark:~/src% wget https://github.com/GrahamDumpleton/mod_wsgi/archive/3.5.tar.gz
fukuda@lark:~/builds% tar xzvf ~/src/3.5.tar.gz
fukuda@lark:~/builds/mod_wsgi-3.5% ./configure --with-python=/usr/bin/python3.4
fukuda@lark:~/builds/mod_wsgi-3.5% make 
fukuda@lark:~/builds/mod_wsgi-3.5% sudo make install
fukuda@lark:~/builds/mod_wsgi-3.5% ls -l /usr/lib/apache2/modules/mod_wsgi.so
-rw-r--r-- 1 root root 615695 Dec 14 16:06 /usr/lib/apache2/modules/mod_wsgi.so
2015-03-25 (Wed): 補遺
上記で上手く行く、のは間違いないが、mod_wsgi-3.4 の deb (libapache2-mod-wsgi-py3) ではダメ、というのは早とちりだったようだ。
fukuda@lark:/usr/lib/apache2/modules% sudo mv mod_wsgi.so hide.mod_wsgi.so
fukuda@lark:~% sudo apt-get install libapache2-mod-wsgi-py3    
   ....
apache2_invoke wsgi: already enabled
 * Restarting web server apache2
   ...done.
のように、何の問題もなくインストールでき、wrm_dms もうまく働いているようだ。(どうして最初はダメだったのかがよく分らないが、 apxs が必要なのに、apt-get がその依存性を見逃して、単に Fail にしてしまったのかも。)

httpd.conf (wrm_dms.conf) の方は、Ubuntu 独自の構成のせいで当然変更が必要。 しかし、この場合はむしろ他の部分と独立性を強制されて、 また、個別に enable/disable でき、却って便利だったかも。 (こういう事を見越していたのかぁ、ちょっと見直したよ、Ubuntu さん。):-) /etc/apache2/sites-available/wrm_dms.conf を編集して、

WSGIPythonPath /home/fukuda/wrm_dms  #1
<VirtualHost *:80>
  ServerName dms.waremo.com  #2

  WSGIScriptAlias / /home/fukuda/wrm_dms/mysite/wsgi.py
  WSGIApplicationGroup %{GLOBAL}  #3
  Alias /static/ /home/fukuda/wrm_dms/index/static/  #4
  <Directory /home/fukuda/wrm_dms/index/static> 
   	 Require all granted  #5
  </Directory>
  <Directory /home/fukuda/wrm_dms/mysite >
    <Files wsgi.py>
      Require all granted
    </Files>
  </Directory>
  Alias /files/ /home/fukuda/wrm_dms/index/files/ #6
  <Directory /home/fukuda/wrm_dms/index/files>
    Require all granted
  </Directory>
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
  1. #1: この directive は <VirtualHost> の外側にないといけない。
  2. #2: (ポート番号ではなく)サーバ名での VirtualHost を実現する。
  3. #3: Django-1.7 以降で必要。1.6.x でも有っても差し支えない。
  4. #4: index App. の /static/の位置を Lark 向けに変更。
  5. #5: Apache-2.4 からの書式
  6. #6: pdf ファイルを読み書きするディレクトリを指定。
こうしておいて、
fukuda@lark:~/wrm_dms% sudo chown www-data mysite
fukuda@lark:~/wrm_dms% sudo chown www-data mysite/db.sqlite3
fukuda@lark:~/wrm_dms% sudo chown www-data index/files    
fukuda@lark:~% sudo a2enmod wsgi     
fukuda@lark:~% sudo a2ensite wrm_dms 
fukuda@lark:~% sudo service apache2 reload  
 * Reloading web server apache2
 *    
として、/var/log/apache2/error.log を確認してから、 http://dms.waremo.com にアクセスすると、首尾良く下のような表示が得られた。
Waremo DMS
Apache と wsgi で公開した Waremo DMS
log-in/log-out, 及び file の upload/download wsgi を含めて、 ちゃんと動いている。

Waremo DMS については、これで良いようなものだが、 実はこれが主目的ではない——これを公開してもあまり意味が無いので。 本当の狙いは、Django を利用した他のアプリもしくはプロジェクトを、VirtualHost で実装する事。 そのためには、できるだけステージングホストと環境を揃えた方が良いだろう。 という事で、Django を 1.7.1 に上げた(考えてみれば、PyPI (pip) に移行しているんだから、何の事はなく、

fukuda@lark:~/wrm_dms% sudo pip3 install -U django    
fukuda@lark:~/wrm_dms% pip3 freeze                      
Django==1.7.1
....
fukuda@lark:~/wrm_dms% python3 manage.py migrate      
で済んだ。変更後も問題無く動いているようだ。

2014-12-13 (Sat): Django App を mod_wsgi で「実戦配備」(その 1)

英語の "deploy/deployment" は、軍事ならば「実戦配備(する)」だが、このような場合はなんと訳すれば良いんだろね。

Django の development server は、非常によくできていて、 それだけ使っている場合には何の問題もない……が、Apache と共存できない、つまり Virtual Server の一つにできない。勿論、Port 番号で分ける事はできる(で、今そうやって使っている)のだが、 あんまりみっとも良くないし、先々 Django のプロジェクトが増えてきた時に対応が難しくなるだろう。

という事で、「Django App を、Apache と mod_wsgi で公開する」に挑戦してみた。 (何度目になるかわからないリターンマッチ!)

OSX Lion

過去の(敗退)の経験から、難航する事は判っていたので、 まずステージング用の OSX-10.7.5 で動かせてみる事に。

MacPorts の Django が知らぬ間に 1.7.1 になっている……ここは最新にしておくべきだろう。

fukuda@quadra:~% pip freeze
    ....
Django==1.6.6
    ....
fukuda@quadra:~% sudo pip uninstall django
fukuda@quadra:~% sudo port install py34-django
fukuda@quadra:~% port installed py34-django   
The following ports are currently installed:
  py34-django @1.7.1_0 (active)
fukuda@quadra:~/Git/wrm_dms% python  manage.py runserver 0.0.0.0:8000 
しかし、これで error と warning が山程出る。試行錯誤の結果、 これで、とりあえず development server で動くようになった。

次は、mod_wsgi のインストールだが MacPorts では、python2.7 決め打ちとなっている。python3.4 を指定しようとしても無視される。

fukuda@quadra:~/Git/wrm_dms/mysite% sudo port install mod_wsgi@4.2.8_0+python34 
--->  Computing dependencies for mod_wsgi
--->  Fetching archive for mod_wsgi
--->  Attempting to fetch mod_wsgi-4.2.8_0+python27.darwin_11.x86_64.tbz2 from 
.... 
しようがないので、最新版 -3.5 をコンパイルしてインストールする事に。 code.google.com からソースを取ってきて展開、そこで
fukuda@quadra:~/build/mod_wsgi-3.5% ./configure \
    --with-apxs=/opt/local/apache2/bin/apxs \
    --with-python=/opt/local/bin/python 
しかし、これではリンクに失敗する。できた Makefile で
LDFLAGS = 
    -L/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib\
    -L/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/config-3.4m\
    -arch x86_64\
    -L/opt/local/lib 
という具合に、/opt/local/lib を追加する。(実際には一行) これで、make とインストールはできる。
fukuda@quadra:~/build/mod_wsgi-3.5% make
fukuda@quadra:~/build/mod_wsgi-3.5% sudo make install
fukuda@quadra:~/build/mod_wsgi-3.5% ls -l /opt/local/apache2/modules/mod_wsgi.* 
-rwxr-xr-x 1 root admin 166596 Dec 10 15:51 /opt/local/apache2/modules/mod_wsgi.so*
一方で、/opt/local/apache2/conf/httpd.conf を編集して、
LoadModule wsgi_module modules/mod_wsgi.so

Listen 8084
<VirtualHost *:8084>
  ServerName quadra.otacky.jp

  Alias /static/ /Users/fukuda/Git/wrm_dms/index/static/
  <Directory /Users/fukuda/Git/wrm_dms/index/static>
    Order deny,allow
    Allow from all
  </Directory>

  Alias /files/ /Users/fukuda/Git/wrm_dms/index/files/
  <Directory /Users/fukuda/Git/wrm_dms/index/files>
    Order deny,allow
    Allow from all
  </Directory>

  WSGIScriptAlias / /Users/fukuda/Git/wrm_dms/mysite/wsgi.py
  <Directory /Users/fukuda/Git/wrm_dms/mysite >
    <Files wsgi.py>
      Order deny,allow
      Allow from all
    </Files>
  </Directory>
</VirtualHost>
また、
fukuda@quadra:~% sudo chown www /Users/fukuda/Git/wrm_dms/mysite    
fukuda@quadra:~% sudo chown www /Users/fukuda/Git/wrm_dms/mysite/db.sqlite3
fukuda@quadra:~% sudo chown www /Users/fukuda/Git/wrm_dms/mysite/index/files
等として、書き込む可能性があるファイルと、その親ディレクトリの owner を www にしておく(厳密には _www の筈だが、www で OK。) こうしておいて、
fukuda@quadra:~% sudo /opt/local/apache2/bin/apachectl restart    
とすると、apache のプロセスが無事立ち上がり、 等がうまく動いてくれた。 やれやれ、と思ったが、もう一つだけ落とし穴が…… ファイルのアップロードがうまく行かず悩んだが、どうやら Django-1.7 で、それまでの "deprecate" から "error" となった事項のうち、
#               response = HttpResponse(data, mimetype=filetype)
                response = HttpResponse(data, content_type=filetype)
の地雷を踏んだらしいので、このように HttpResponse() を呼んでいるところは、全て mimetype -> content_type の変更を加えた。

これで何とか、development server での動作を再現できた。

予定では、同じ事を Ubuntu(公開サーバ)でやる筈だったのだが、 ここまでが結構大変だったので、ちょっと気が重い……


2014-12-06 (Sat): (久し振りに)国際ローミング

この 2 年近くは日本を離れた事がなかったが、 最近、パリまで旅行する機会が有ったので、その際の Mobile 通信事情を……

国際ローミング

4・5年前だったか、ウチの息子が米国に駐在中の私のところへ遊びに来た際、 「国際データローミング」を使ってみたは良いが、 それを切り忘れて、その結果箆棒な請求が来た事が有った。 (今でも母親に嫌味を言われている。) なので、「国際ローミングは鬼門」 というイメージが自分の脳裏に焼き付いている。

が、最近になって、Soft Bank さんが「海外パケットし放題」なるものを始めたらしい。 その当時は「俺には関係ないかな」と思っていたが、 今回の旅行のために改めて勉強した。 結構込み入っていて、なかなか理解しがたいところ(何で、 「定額料」なのに二段階なの?とか)もあるが、要は:

  1. 予めの申請や登録は不要
  2. 但し現地で特定の(定額対応)キャリアに接続する必要がある
  3. 一日 25 MB までは、1980円、それ以上は 2,980 円
  4. 一日の区切は、日本時間の午前零時
という事らしい。 これなら WiFi を中心にして、やむをえない場合でも対応キャリアだけに接続し、 一日の区切に気をつけて使えば、そこそこの料金で済むのではないか、 と思ったが……

空港からパリ市内についた時点で、いきなりその思惑が外れてしまった。 第一に、路上でアクセスできる WiFi に open なものはない。 第二に、キャリアを「固定」にできない。CARRIERS: Automatic: ON で、とりあえず FSR (定額対応キャリア)を選んではいるが、これを OFF にしたら、ずっと "Searching..." のままになってしまう。 どうしても、GoogleMap を使いたかったので、やむなく Auto のまま使い始めた。 その間も、キャリアが FSR である事を確認してはいた。

が、その確認がだんだん疎かになった翌々日あたりに、 違うキャリアに接続されている事に気付いた。実はそれまでにも、 SB さんから、「対応キャリア以外に接続されていて、料金が高額に……」という警告の SMS が来ていたが、確認した際はいつも FSR だったので、「何のこっちゃ」 と無視していた。 つまり、それまでも非対応のキャリアにつながっていたのだった。 「これはイカン」と、改めて Automatic を OFF にした——やっぱり暫くは Searching... だったが、2~3 分放置したら、FSR を検出して、固定できた。 「うわっ、なんぼ程請求が来るんやろ」と少々暗〜い気持になったが、 その後料金を確認したら、「対象外」通信の料金は 6,500 円程だった。

対応キャリアの請求は、9日間で総額 21,820円。これから察するに、25MB 以下に押えられた日が 5日、それを超えた日が 4日だったようだ。

ANA の WiFi サービス

ANA さんはかつて WiFi サービスを始めた事があって、その時は需要が少くて、 比較的短期間でサービスが廃止されたようだ。 (だのに、ある便の機内では同サービスの AP が生きて動いていた、という顛末もあった。)

実は今回、サービスの再開を知らなかった……。無いものと思い込み、 最後の機会とばかりにラウンジで WiFi を使い倒して、 飛行機に乗ってみたら、座席の前のポケットに「WiFi サービスのパンフレット」が入っていた。 早速 iPhone で試したら、ちゃんと入れる……へー、鷹揚だねぇ、と感心して、 一旦は iPhone を Airplane モードにする。

水平飛行に入っても、映画が面白くて、ついつい先延ばしにしていた (これが後悔の元。) さていよいよ使ってみるか、と、まず MBA の AC アダプタを継ぎ(ANA の B777 のエコノミーは、変なところに AC レセプタクルがあって、 肘痛の私には座ったままでは手が届かず、腹這いになって潜り込む必要が有った) WiFi につなごうとするが、先程の AP (OnAir) が全く応答しない。 おっかいしなぁ、と思ってパンフレットを見たら、 「衛星通信の使用を認可しない国の上空では使えない」とある。 うー、その国が中国なのかロシアなのか詳細は不明だが、 これではヨーロッパ線は毎回かなりの期間不通になるのではないか。

まあ、帰りの便で試したらいいや、と諦めたが、 帰りの便は Air France になってしまったので、結局試せなかった。

しかし、もし、予定通り ANA 便に乗れたとしても、 大した事はできなかっただろう。何しろ、5 MB あたり $6 と割高な上に前払いで自動延長無しなので、FB に写真をアップロードするなんてのは、 論外だろう——まさにそれを考えていたのだが。

Hotel WiFi

ちょっとした予約上の「行き違い」があって、4 泊づつ別のホテルに泊まる羽目になった。 どちらも三つ星で、あまり期待はしていなかったが、とりあえず、 Free の WiFi は有った。しかし、どちらも大変不安定。 ログイン後しばらくは動くのだが、そのうち接続が切られて、 再ログインを強制される。 また、時には再ログインができない(そもそもプロンプトが出ない)事もあった。

加えて、最初のホテルのは ssh が通らない……これは私には痛かった—— ssh でログインしたり、rsync で同期をとる等がメインの「作業」なので。 しかし、何故か 993 (imap4 over TLS) だけは通るのでメールは読めた。

次のホテルは、上の制限は無かったが、転送速度がとても遅い。 あんまり遅いので腹立ちまぎれに実測したら、50 kbps と出た事もあった。

つまり、どちらもあまりアテにならない、というか「使えねえ」という事。 これらでやきもきするくらいなら、 海外パケホーダイで 2980 円/日を払う、と覚悟を決めて、端から tethering を使うべきだと思った。


2014-11-12 (Wed): Emacs-w3m vs shr.el:

Emacs-w3m を全て削除しないと、Wanderlust が shr.el を使うようにならない、 なんてのはどうも私の早とちりで、
(autoload 'w3m "w3m" "Interface for w3m on Emacs." t)
(setq w3m-home-page "http://www.otacky.jp")
(setq w3m-key-binding 'info)
(setq w3m-fill-column 80)

;; (require 'w3m-load)   ;; w3m for Wanderlust  #1)
;; (require 'mime-w3m)
;; (require 'mime-setup) ;; 

(setq mime-setup-enable-inline-html 'shr)  ;; shr for Wanderlust #2)
(require 'mime-setup) ;;
(eval-after-load 'shr   ;; リージョンの colorize をdisable  #3)
  '(defun shr-colorize-region (start end fg &optional bg)
     nil)) 
とすれば、w3m を全部削除したりせずとも、shr を使うようにできる—— (require 'mime-setup) の前に、w3m か shr のどちらか一方を指定するのがキモらしい。 (#1 の部分のコメントを外してやれば、また w3m が呼ばれるようになる。)

shr on wanderlust
shr.el で 背景の着色を止めてみた
それに加えて、#3) のように shr-colorize-region を再定義してれやれば、 邪魔だった「中途半端な背景色」を消す事ができる。

という事で、何度か切り換えて試してみて、 emacs-w3m の代りに、もっぱら eww と shr.el を使う事にした。 (w3m より、shr.el の方が、配置や href の表示が私好み。) 最近では emacs-w3m の shimbun も使わないので、emacs-w3m は卒業かな……

と思いかけていたのだが、そうは問屋が……例えば Google の

[1  <text/plain; ISO-2022-JP (7bit)>]
[2  <text/html; ISO-2022-JP (base64)>] 
のようなパートを持つメールが開けない事が解った……"(base64)" を decode できないみたい……

という事で、また emacs-w3m へ戻っている——なかなかうまく行かんもんだ。


2014-11-08 (Sat): Emacs 再訪:

emacs-mac-app が 5.1 になった。いつもの事ながら、MacPorts は EmacsMac.app の改訂にはとても素早く対応してくれる。

Wanderlust で eww

Emacs には既に emacs-w3m というページャーが有るが、 実際にはそれでウェブページを見る事より、 HTML メールをレンダリングして……、 という使い方の方が断然多い。 で、今回はこれを eww に変えてみよう、と。

幸い、最新の semi (以前は semi-epg という名前だった?)は 「まず w3m を探して、それでみつからなければ、 eww (正確には shr.el) を使う」という実装になっているらしい。 なので、shr.el に移るのに追加的な設定は不要だが、 一方で、w3m 全体を全部アンインストールする必要が有った。 なので、ちょろっと設定を変えて、eww を試し、また w3m に戻して比べてみる……なんてのはそんなに簡単ではない。 つまり、

fukuda@quadra:~% export
    RES=/Applications/MacPorts/EmacsMac.app/Contents/Resources/
fukuda@quadra:~% sudo rm -rf $RES/site-lisp/w3m 
とやった。勿論、init.el で w3m-xxx を autoload するあたりは全部削除する。(が、ここまでやる必要が有るかどうかは未詳。) こうすると、Wanderlust が <html/text> な part を shr.el でレンダリングするようになる。

で、w3m との比較で言うと、

以上の事は、次の例から容易に見て取れる。
w3m on wanderlust
w3m で HTML メールをレンダリング
shr on wanderlust
shr.el で HTML メールのレンダリング


Mail.app
Mail.app によるレンダリング
ちなみに、Mail.app で表示させてみると、左のようになる。 いずれにしても、この例では、shr.el は emacs-w3m に対して然程のアドバンテージは無い、と言えるだろう。

HTML メールにも、色々なレベルのものがあって、 これなどは特に shr.el に不利な方かも知れないが、 大体に於いて両者の間に大きな差は無い、と考えて良いと思う。 (と、言うより「HTML メールは勘弁してね」が本音。)

なので、当面は、w3m とその設定を元に戻し、 wanderlust でメールを読む時は w3m、 ウェブページを閲覧する時は、eww を使う、という事にする。 (逆はできないが、こちらは可能。)

Flyspell-mode

Emacs の aspell (ispell) はとても強力で、単語をタイプして直後に M-$ とやるだけで、spell-check をやってくれ、間違っている場合は、 訂正の候補を表示してくれる。(その単語が間違いではない場合に、 辞書に入れるもの簡単←これは重要。) が、そうは言っても、そもそも「このスペルは怪しい」と思わなければ、 aspell は起動されない訣で、そうなると誤った記憶が定着する、 というか「強化」される……なので、 英文をずらずら書いている片端から spell-check をしてくれると有難い事は言うまでもない。(MacOS 7 の頃から ——BasiliskII 上の MacOS 8 では今でも——"Thunder 7" で on-the-fly でスペルチェックをしてきた。) で、当然ながら Emacs にもかなり前からそういう minor-mode はあって、代表的なのは flyspell-mode だろう。

しかしこれまであまり使わずにきている。 試してみた事が有るのは確かなのだが、 どうしてやめてしまったのかはよく憶えていない。 「そもそも動かなかった」か 「動くようにはできたが、日本語他をうまく除外できなかった」 か……どうも両方を経てきているような気がする。

Emacs も新しくなった事だし、もういっかい挑戦!と思い立ったのだが、 だがなんと、いきなり試練が……。Info に flyspell-mode の項目が無い。 いや、捜しているところが悪かった。Emacs -> Spelling と辿っていくと、 ispell command の後の方に有った。といっても、flyspell-mode と flyspell-prog-mode が有るよ、という事と、mouse-2 button 使って、訂正もしくは辞書への追加ができる、としか書いてない。

まあそれで十分と言えば十分なので、それぞれを text-mode-hook と prog-mode-hook につけ加えてみた。

(setq prog-mode-hook
      '(lambda ()
         (flyspell-program-mode 1)  
	 ))
    
(setq text-mode-hook 
      '(lambda ()
	 (setq left-margin 4)
	 (setq fill-prefix "")
	 (setq fill-column 76)
	 (setq adaptive-fill-mode nil)
	 (abbrev-mode 1)
	 (auto-fill-mode 1)
	 (electric-indent-mode 1)  ;; 2014-11-02 (Sun):  
	 (flyspell-mode 1)         ;;2014-11-08 (Sat):  
	 ))
結果はなかのもので、日本語の文章や、URL のやたら長い意味不明綴りは上手に避けているようで、 例えば、以下のようになる。
Flyspell-mode
HTML-mode での Flyspell
これまでも batch の (?) ispell (aspell) を使ってきたので、 emacs, mac, app 等が既に辞書に反映されている、という事もあるが、 誤りとされている語が、"EmacsMac", "MacPorts" はたまた "eww" 等の「本当にチェックして欲しい語」だけになっていて、 これはかなり使えるのでは、と思う。 (あちこちに大量に赤い下線が表われたのでは、チェックにならない。)

あと、C-; が、flyspell-mode にとられる……。実はこれ、"C-x 5" (multi-frame の prefix) にバインドしていて、ようやく慣れてきたところなので、ちょっとツライ。 とは言え、「直前の単語のスペルミスを修正する」という機能も捨て難いので、 今どちらを動かすかを思案中。


2014-11-01 (Sat): Emacs-Mac.app-5.0:

Mavericks や Yosemite に少し遅れたけど、Lion でも MacPorts の emacs-mac-app が 5.0 になり、 自動的に使い始めた。 で、メインマシンで使い込むとマイナーな(だけど個人的には重大な) 問題も色々見付かって、いつもの事ながらついつい……

Newline と indent

まず、C-j や C-m, Return が思うように動作しなくなった。 このあたりは、自動インデントや SKK のコマンドと関っている上に、 動作が殆んど「脊髄反射」になっているので、 「違和感が有る」という以上には「何がどうなっている」のかよく解らなかった。

加えて、いろいろ弄っているうちに、 何が「本来のあるべき姿」なのかが曖昧になってきたので、 emacs-mac-app 4.8_1 に戻ってみた。こういう時は MacPorts はとても便利で

fukuda@hawk:~% port installed emacs-mac-app          
The following ports are currently installed:
  emacs-mac-app @4.8_1 
  emacs-mac-app @5.0_0 (active)   
fukuda@hawk:~% port activate emacs-mac-app@4.8_1     
fukuda@hawk:~% port installed emacs-mac-app          
The following ports are currently installed:
  emacs-mac-app @4.8_1 (active)
  emacs-mac-app @5.0_0    
で OK。(あまり早く % sudo port uninstall inactive とやってしまうとこの手が使えない……)

で、こうすると件の「違和感」は無くなった——良かった自分の妄想ではなかった。 これから始めて「違和感を再現してみよう」と「試行錯誤」を始めたが、 幸運にもすぐにヒット。 要は electric-indent-mode が問題で、EmacsMac-4.8 (Emacs-24.3) まではそれが nil だったのに、-5.0 (同-24.4) では、それがディフォルトで 't' になった (enable されている) という事らしい。

そこで ~/.emacs.d/init.el で、これを明示的に nil にする。

(setq text-mode-hook
      '(lambda ()
         (abbrev-mode 1)
         (setq left-margin 4)
	 (setq fill-prefix "")
         (setq fill-column 76)
         (setq adaptive-fill-mode nil)
         (auto-fill-mode 1)
         (setq electric-indent-mode nil) ;; 2014-11-01
	 ))
    ....
(global-unset-key "\C-x\C-j")
(global-set-key "\C-x\C-j" 'skk-mode)
    .... 
こうしておいて、上のコマンドで emacs-mac-app の 5.0 を activate すると、元の動作が戻った。

自分の「脊髄反射」に頼れなくなっては仕事にならないので、 とりあえずこれでお茶を濁したが、いずれは、electric-indent-mode を使う方向で、操作や設定を整理するべきなんだろう。 (Python-mode のインデントの動作とも整合を取りたい……)

font-rescale

Emacs-23.3 の頃から、ASCII 文字は「Lucida Fax (改)」で、また日本語は「ヒラギノ明朝 ProN」を使っている。 今でも最強の組合せだと思っているが、 少し前からさらに凝って、font-rescale を使って、ヒラギノのサイズを 10% 増しにしていた。

が、emacs-app から emacs-mac-app に乗り換えた際に、この font-rescale が効かなくなっていた。

この際、長年の懸案に :-) カタをつけてやろう、 と意気込んで「試行錯誤」を始めたが、何のことはない、 他の設定で使っているフォント名をそのまま使えば OK だった。 (うー、なんでこれに気付かなかったのか……)

(when (and (window-system )(>= emacs-major-version 23))
  (set-face-attribute 'default nil
		      :family "Lucida Fax" ;; 2010-12-05 (Sun): 
		      :height 180)
  (set-fontset-font
   (frame-parameter nil 'font)
   'mule-unicode-0100-24ff
;;   '("Lucida Grande" . "iso10646-1"))
   '("Lucida Bright" . "iso10646-1"))
  (set-fontset-font
   (frame-parameter nil 'font)
   'japanese-jisx0208
   '("Hiragino Mincho ProN" . "iso10646-1"))
  (set-fontset-font
   (frame-parameter nil 'font)
   'japanese-jisx0213.2004-1
   '("Hiragino Mincho ProN" . "iso10646-1"))
  (setq face-font-rescale-alist
	'(("^-apple-hiragino.*" . 1.10) 
	  ("Hiragino Mincho ProN" . 1.10))  ;; 2014-11-01: added
	)
  )
 

Packages package

先に、packages にバグが有る、と書いたが、 どうやらこれも私の勘違いで、Shift-U は list でカーソルが有るパッケージだけを upgrade するのではなく、installed のパッケージ全体を upgrade するのでした。で、upgrade の結果一旦消される(古い)パッケージに 'D' が付けられる、と。(しかし、 これもあまり分かり易いとは言えないな。)

2014-10-25 (Sat): iTunes, Emacs, Xcode ...:

この時節、新しくなったと言えば Yosemite の話か?となるのが普通だろうけど、諸般の事情でそれはお預け……

iTunes

Apple は Lion のためにはもう殆んどの App のアップデートやめてしまったようだが、iTunes だけは別。 だが、こちらが段々 iTunes を使わなくなってきている。Audio book の品揃えがあまり良くない事や、Podcast を直接 iPhone へダウンロードするようになった事もあるが、 一番大きいのは、米国の iTunes Store にアクセスできなくなり、 CC のついた映画が買えなくなった事だろう。 (「字幕版」の字幕は、CC とは違って、言語を変更する事はおろか、On/Off もできない。)

ともあれ、新しくしてくれる、というので (今では珍しくなった事もあって、ちょっと嬉しくて :-) あまり深く考えずアップデートした……

iTunes-12.0.1
新しくなった iTunes (on Lion)
が、やってしまって、ちょっと後悔。Yosemite 風 (iOS 風?) になっているんだろうけど、 icon や、窓枠や、button などが斬新になってかつ平板に(安っぽく)なった。 それより、どこに何があるのかさっぱり分らなくなってしまった。 iTunes は生まれた時から、Hierarchical File System (HFS) の概念を無視していて、 その UI には(慣れる事はあっても)馴染めないできたが、それでも、 iPhone/Library/iTues_Store の最上位のカテゴリーだけはちゃんと並んで表示されていた。 しかし、今回の改訂で、それも無くなってしまった…… (どうしても HFS に止めを刺さないとおれないってか?:-)

そのせいもあるのか、iOS のアップデートは、何と iOS のページに行かないで、 完了できる……

「iOS に新バージョンがあるよ、 ダウンロードしてインストールするか」と言われて、そこで「はい」とやると (翻訳は不正確かも :-) そのまま、8.1 になってしまった。 しかし、これは不安である。実際、途中で iPhone 側の screen lock がかかった時一旦止まった。Passcode を入れるだけだったけど、ちょっと焦った。

MacPorts

Yosemite に対応するバージョンを作る「ついで」でもあるのだろうが、 MacPorts base が 2.3.2 になり、 MacPorts のパッケージが大量に upgrade された。 偶々最近 Python-3.4 が、3.4.2 になり、また、Emacs が -24.4 となって、EmacsMac.app (emacs-mac-app) が 5.0 となって、(私的には)盆と秋祭りが一緒に来たような……

EmacsMac.app

上述のように、Emacs-24.4 に対応した EmacsMac.app が出た。 しかし、何故か Lion 向けにの MacPorts の emacs-app は 24.3 のままで、 emacs-mac-app も 4.8 のままである。 ともあれ、5.0 になったらどんな感じなのかあたってみよう、という事で、 Mavericks の上でアップグレードしてみた。

早速、動作確認してみたら、いきなり、warning が……

EmacsMac.app warning
load-path がらみの warning
なにしろ「いきなり」な上に、load-path がらみではかなり右往左往した記憶が有るので、ちょっとパニックになってしまった。 で、init.el の位置を変えたり、 ~/.MacOSX/environment.plistの EMACSLOADPATH の定義を復活させたり、いろいろ弄ってみたが、効果無し。 Stackoverflow でも、いくつかこれに関する Q/A が上っているけど、 どれもなんだかえらく大仰な感じがするばっかりでよく分らない。

結局、~/.emacs.d/init.el から

(add-to-list 'load-path "/Users/fukuda/.emacs.d") 
の行を comment out するだけの事だった。 そもそも、これを入れたのが、"package" (という package) がらみだったような気がするので、M-x package-list-packages から始めていろいろやってみたが、今のところ大きな問題は 「Shift-U で upgrade を試みないで、一つ上の package に "D" を付けてしまう」というくらいか。 考えてみればこれは結構凄いバグだが、しかし、これは load-path とは関係無さそう。
2014-11-01 (Sat): これは私の勘違いで、 どうやら仕様らしい。こちらを参照

しかし、一番目立つ変化は、ブラウザの eww の導入だろう。 これまでは、HTML 形式の Email を見る時などは w3m (emacs-w3m) を使っていたが、このところ段々使わなくなってきていた。 その両方で、otaku_comm-14Q3 を表示してみた。

EmacsMac-5.0 の w3m
w3m (click で拡大可)
EmacsMac-5.0 の eww
eww (click で拡大可)

eww はインラインで?画像が表示される。これは大きい。 が、css を無視した後の次善の策?も、 ページの見栄えに相当影響するのだが、 eww が必ずしも優れていない。例えば、<h4> レベルの見出しは、w3m のように bold にしてくれた方が嬉しい。

Xcode

Xcode が 6.1 になった。勿論、Lion には関係ない話 :-(。

何はともあれ、Target がまた選べるようにり、iOS Simulator もメニューに表われるようになった。 (何故か 6.0 ではこれができなくなっていた。)

自分の仕事にはこれは大きい。Wireshark は、sniff mode (自分が、通信の片割れではない)では、擬似 Ethernet の packet analysis ができないのだった。 一台の MBA は sniff (monitor) mode にして、WLAN レベルの frame をキャプチャし、 もう一台では iOS Simulator の上で被試験アプリを走らせ、TCP レベルの packet をキャプチャする、 というのは非常に強力なツールになる。

しかし、うっかり 5.1.x から、6.0.x に上げてしまった事で、これができず、 パケット/プロトコルの解析に生かせなかった。全く残念な事である。

それはともかく、多分 Xcode のアップデートに付随しての事だと思うが、Command Line Tools が新しくなって、件の bash の Shellshock が解決されている。

fukuda@quadra:~% env x='() { :;}; echo vulnerable' /bin/bash -c 'echo hello'
vulnerable
hello
fukuda@quadra:~% /bin/bash --version
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin11)
Copyright (C) 2007 Free Software Foundation, Inc.
fukuda@quadra:~% ssh hawk           
Password:
Last login: Mon Oct 20 10:53:27 2014
fukuda@hawk:~% /bin/bash --version
GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.
fukuda@hawk:~% env x='() { :;}; echo vulnerable' /bin/bash -c "echo this is a test"
this is a test

2014-10-14 (Tue): MathJax, Prettyprint 再訪

近頃は Web 診断ツールを触っていて、 自分のサイトをその標的にする事がよく有る。 それで気がついたのだが、このところ我サイトのファイル数がやたら増えている。 で、どうやらそれは MathJax を手許に導入したせいらしい。 du コマンドで見てみると、何と、 容量ではサイトコンテンツの半分以上を占めている。
fukuda@lark:~% du -s /var/www/html            
460956	/var/www/html
fukuda@lark:~% du -s /var/www/html/script/MathJax 
265772	/var/www/html/script/MathJax 
うーむ、これでは……

そもそも、態々、手許に script を持ってきたのは、

と思ったから。

しかし、各ページの script を元に戻して

<script type="text/javascript"
    src="https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js">
    </script> 
<script type="text/javascript"
src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=MML_HTMLorMML">  
    </script>  
としても(つまり、Javascript のコードをその都度取ってくるようにしても)、 それらの色使いを変えたり、フォントサイズを変えたりするための
<link rel="stylesheet" type="text/css"
    href="style/prettify.css"/> 
<style type="text/css">
    pre.prettyprint {
      padding-left: 0.4em;
      padding-right: 0.4em;
      background: #faffff}
    </style>
    
<script type="text/x-mathjax-config">
      MathJax.Hub.Config({
         "HTML-CSS": { scale: 90 }
    });
などは、ちゃんと動くようだ。(そもそも、 どうして、当初これらが働かないと思ったんだろ。)

外部からのアクセススピードの方も問題無さそう(その都度 cache を clear して……というところまではやってないが。)まあ、考えてみれば、 外部ユーザが Java script を www.otacky.jp から取っても、はたまた google.com や mathjax.org から取っても、所要時間が然程変わる筈はない。


2014-10-04 (Sat): Bash の脆弱性に関するミステリー

2014-10-05 改訂 「MacPorts 版の bash が有るだけで……」はミステリーでもなんでもなく、 単なる私の勘違い、でした。いや、面目ない。
Bash (Bourne Again Shell) に重大なセキュリティ上の欠陥 (ShellShok 脆弱性) が見付かったとかで、かなり盛り上がっている。 しかし、「重大」と言っても、ネットワーク上のサーバの bash に外からコマンドを実行させるためには、まず ssh を突破するか、http を攻略しないといけない訣で、それ程騒ぐ程の事かな、 と私などは思ってしまうのだが…… (素人の言う事なので、あんまり真に受けないでね。)

しかも、私はもとより zsh 派なので bash は殆んど使っていない。 (唯一、Raspberry Pi では bash だが、これはネットワークに繋っていない。) なので、あんまり興味も無かったのだが、 非常に簡単に「脆弱性」を検査できるらしいので、 ちょこっと「いっちょ噛み」をやってみた。 (界隈の盛り上りもこれが原因に違いない。) つまり、色々な bash で

fukuda@quadra:~% env x='() { :;}; echo vulnerable' bash -c 'echo hello'
vulnerable
hello
とやってみた訣。結果は、
Lark (Ubuntu-14.4 LTS)
    /bin/bash: NG -> OK (9/27)  
    
Raspi0x (Raspbian 2014-09-09)
    /bin/bash: NG -> OK (9/26)
    
OSX (Lion: 10.7.5)
    /bin/sh: NG
    /bin/bash: NG 
    /opt/local/bin/bash: NG -> OK (10/2)
    
OSX (Maverics: 10.9.4)
    /bin/sh: NG
    /bin/bash: NG 
    /opt/local/bin/bash: NG -> OK (10/2)
となった。Ubuntu (Raspbian も事実上 Ubuntu) は、/bin/sh は /bin/dash のシンボリックリンクなので固より問題ない上に、 非常に素早くパッチの当った bash をリリースしている。 一方、OSX の方は、何と純正の bash/sh のみならず、 MacPorts の bash も NG で「全滅」という結果になってしまった。 (実は MacPorts の bash はインストールしてなかったが、 態々このためにインストールしてみたのだった。)

それでも、少し遅れて、純正の bash も MacPorts の bash も対応したようだ。実際 10/2 の時点で、MacPorts で upgrade すると OK となった。


2014-10-01 (Wed): Raspberry Pi で WiFi AP

2015-03-18 (Wed):
* インストールする項目に udhcpd を追加。
* /etc/udhcpd.conf/etc/default/udhcpd あたりの混乱を修正

ESSI と subnet

家庭内 LAN に WiFi ルータを導入した際に、「家中が同一 subnet の一員になる」(つまり Ethernet も WiFi も全てが例えば 192.168.1.x のような IP address を持つ)というスキームを強制された時は 「それでええんか?」と思った。 が、しかしそれでちゃんと動き、 それなりに快適だったので、その疑問もそのうち忘れた。

それでもさすがに DHCP server と DNS server 機能をそれまでの WiFi ルータから家庭内サーバに移す時にはちょっと不安だったが、 案ずるより産むが易し、 何故か WiFi ルータが、unicast packet のみならず、 DHCP request/response (つまり broadcast) packet も転送してくれるのだった。

なので、Raspi (Raspberry Pi) を WiFi AP にしようとした時、 最初に考えたのは、上のスキームを再現する事だった。

このあたりはいい加減な記事が多い……

いつもお世話になっているのに、こう言っては申し訣ない気もするが、 このトピックに関してはどうも「そのままやったのでは動かない」事が多いようだ。 おかげで、大分右往左往させられた。

で、その右往左往の結果を纏めると、

これらは勿論「こうでないといけない」というものでもないし、 「これがベスト」という訣でもなく、 「とりあえず動かすにはこうすべき」という事柄のリストに過ぎない。

というか、有り体に言うと、 ここにある一番オーソドックスなアプローチでやっと動いた、という事。 (これを最初に見ていれば、こんな「解説」を書く気も起きなかったかも :-)

Raspbian をアップグレード

まずは、Raspi02 の Raspbian を最新にする: (udhcpd (*)のインストールを追加)
fukuda@quadra:~% ssh pi@raspi02    
pi@raspi02:~% sudo apt-get update
pi@raspi02:~% sudo apt-get upgrade
pi@raspi02:~% sudo apt-get dist-upgrade
pi@raspi02:~% sudo apt-get install iw hostapd udhcpd   # (*)
pi@raspi02:~% sudo reboot
fukuda@quadra:~% ssh pi@raspi02    
pi@raspi02:~% uname -a 
  Linux raspi02 3.12.28+ #709 PREEMPT Mon Sep 8 15:28:00 BST 2014 armv6l GNU/Linux 
SD カードの書換えから始めなくても、最新ディストリビューション (2014-09-09) になっているようだ。

ドングルの確認

iTunes Installation Error
Raspi01 + WLI-UC-G (左)と Raspi02 + WLI-UC-G301N
WiFi アダプタを挿して、turn-on、raspi02 にログインして
pi@raspi02:~% lsmod
Module                  Size  Used by
...
mac80211              329911  3 rt2x00lib,rt2x00usb,rt2800lib  # *0)
...
pi@raspi02:~% lsusb
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. 
Bus 001 Device 004: ID 0411:016f BUFFALO INC. (formerly MelCo., Inc.) \
    WLI-UC-G301N Wireless LAN Adapter [Ralink RT3072]  # *1)
pi@raspi02:~% iw list 
Wiphy phy0
	Band 1:
            ....
	Available Antennas: TX 0 RX 0
	Supported interface modes:
		 * IBSS
		 * managed
		 * AP                    *2)
		 * AP/VLAN
		 * WDS
		 * monitor
                   .....
これはつまり
  1. *0) driver module は mac802.11
  2. *1) 使っているのは Buffalo の WLI-UC-G301N アダプタで、
  3. *2) これには AP になる能力が有る
という事。

Interfaces

/etc/network/interfaces を書き直して、
auto lo

iface lo inet loopback

iface eth0 inet dhcp  # *3)

allow-hotplug wlan0
iface wlan0 inet static
    address 192.168.2.1  # *4)
    netmask 255.255.255.0
#wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
#iface default inet dhcp
#up iptables-restore < /etc/iptables.ipv4.nat # *5)
のようにする。ここで
  1. *3) この行を下手に弄ると、ssh で Raspi にログインできなくなり、Raspi にモニタと KBD を直結しないといけない騒ぎになる——要注意。
  2. *4) この subnet が、eth0 に dhcp でアサインされる IP の subnet と異なっている事が重要
  3. *5) この行は、iptables.ipv4.nat が有る状態でないとエラーになる。(作ってから uncomment する事。)

DHCP Server

udhcpd を使う。/etc/default/udhcpd
DHCPD_ENABLED="no" 
DHCPD_ENABLED="yes" 
とし、さらに /etc/udhcpd.conf を編集して、
# Sample udhcpd configuration file (/etc/udhcpd.conf)
# The start and end of the IP lease block
start		192.168.2.20	#default: 192.168.0.20
end		192.168.2.25	#default: 192.168.0.254
# The interface that udhcpd will use
interface	wlan0		#default: eth0
#Examles
opt	dns	192.168.0.11 8.8.8.8  # *6)
option	subnet	255.255.255.0
opt	router	192.168.2.1    # local domain の router  *7)
opt	lease	864000	# 10 days of seconds 
のようにする。ここに、後で導入する IP forwarding/NAT とうまく共同するために
  1. *6)自身の subnet の中でなくても可
  2. *7) これは自身の subnet 内になければならない

Hostapd

さらに、/etc/hostapd/hostapd.conf を書き変えて、
interface=wlan0
driver=nl80211
ssid=Raspi02-AP # これが ESSID になる
hw_mode=g
channel=6
macaddr_acl=0
auth_algs=1 
ignore_broadcast_ssid=0
wpa=2 # WPA2
wpa_passphrase=mypassword # 当然ながら要変更
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP 
また、/etc/default/hostapd の一行を変更して
#DAEMON_CONF=""
DAEMON_CONF="/etc/hostapd/hostapd.conf"
とする。

IP Forwarding/NAT

/etc/sysctl.conf を編集して
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1
とし、さらに
pi@raspi02:~% sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
pi@raspi02:~% sudo iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
pi@raspi02:~% sudo iptables -A FORWARD -o eth0 -i wlan0 -j ACCEPT    
pi@raspi02:~% sudo sh -c "iptables-save > /etc/iptables.ipv4.nat"
pi@raspi02:~% sudo update-rc.d hostapd enable
pi@raspi02:~% sudo update-rc.d udhcpd enable
とする。(この後、上の *5) の uncomment を実行する。) ここで、reboot。

動作確認

本当は各ステップごとに確認した方が良いし、Linux にはそのための手段も豊富だが、記述が煩雑になるので、 「全部エディタで設定していきなりリブート」という体裁にした。 (iptables 関連のみは、command で設定した方が楽なので、この例外。)
pi@raspi02:~% ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:87:2a:cb  
          inet addr:192.168.0.122  Bcast:192.168.0.255  Mask:255.255.255.0
          ....
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          ....
wlan0     Link encap:Ethernet  HWaddr b0:c7:45:78:78:a8  
          inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2959 errors:0 dropped:12 overruns:0 frame:0
          TX packets:3321 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:344858 (336.7 KiB)  TX bytes:3968245 (3.7 MiB)
    
pi@raspi02:~% iwconfig
wlan0     IEEE 802.11bgn  Mode:Master  Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
eth0, wlan0 とも望みの設定になっている。iwconfig の表示が非常に貧弱であるが、これは wireless-tools の仕様がこのように変ったためらしい(/etc/proc/wireless は空っぽ。)
pi@raspi02:~% dumpleases
Mac Address       IP Address      Host Name           Expires in
78:ca:39:41:28:1e 192.168.2.24    hawk                9 days 21:19:28
udhcpd による IP アドレスのリースもうまく行っている。

www.otacky.jp に仮に置いたファイルを wget してスピードを測定

pi@raspi02:~% wget http://www.otacky.jp/MacOS8.HFD
--2014-09-30 16:58:36--  http://www.otacky.jp/MacOS8.HFD
Resolving www.otacky.jp (www.otacky.jp)... 192.168.0.11
Connecting to www.otacky.jp (www.otacky.jp)|192.168.0.11|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 243762688 (232M)
Saving to: `MacOS8.HFD.1'

100%[================================================================>] 243,762,688 7.03M/s   in 35s     

2014-09-30 16:59:11 (6.64 MB/s) - `MacOS8.HFD.1' saved [243762688/243762688]
約 52.8 Mbps。これは Lark (www.otacky.jp) と Rasipi02 の間の Ethernet link のスピードであるが、Raspi02 側が 100BASE-T である事を考えれば妥当な値だろう。

次いで、Hawk (MBA) に移動して、Raspi02-AP に接続。

iTunes Installation Error
OSX から Raspi02-AP に接続
iTunes Installation Error
DNS も正しく設定されている

www.python.org (Internet) と quadra.otacky.jp (local) にアクセスしてみる。

fukuda@hawk:~% traceroute www.python.org
traceroute to python.map.fastly.net (103.245.222.223), 64 hops max, 52 byte packets
 1  192.168.2.1 (192.168.2.1)  1.767 ms  0.988 ms  0.742 ms
 2  router.otacky.jp (192.168.0.1)  2.236 ms  1.359 ms  1.793 ms
 3  r049.tokynt01.ap.so-net.ne.jp (210.132.217.162)  9.696 ms  12.394 ms  12.851 ms
 4  tn02gi4.tokynt01.ap.so-net.ne.jp (210.132.217.190)  12.047 ms  15.863 ms  12.586 ms
^C
fukuda@hawk:~% ping quadra.otacky.jp    
PING quadra.otacky.jp (192.168.0.2): 56 data bytes
64 bytes from 192.168.0.2: icmp_seq=0 ttl=63 time=4.038 ms
64 bytes from 192.168.0.2: icmp_seq=1 ttl=63 time=3.695 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=63 time=4.133 ms
64 bytes from 192.168.0.2: icmp_seq=3 ttl=63 time=4.063 ms 
192.168.0.x へうまく forward されている上に、DNS が正しく引けている事がわかる。

上と同様にして、スピードテスト。

fukuda@hawk:~% wget http://www.otacky.jp/MacOS8.HFD            
--2014-09-30 16:59:44--  http://www.otacky.jp/MacOS8.HFD
Resolving www.otacky.jp (www.otacky.jp)... 192.168.0.11
Connecting to www.otacky.jp (www.otacky.jp)|192.168.0.11|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 243762688 (232M)
Saving to: ‘MacOS8.HFD.2’

100%[======================================>] 243,762,688 2.46MB/s   in 1m 40s 

2014-09-30 17:01:24 (2.33 MB/s) - ‘MacOS8.HFD.2’ saved [243762688/243762688]
今度は、WiFi Link のテストになっているが、l8.6 Mbps と出た。 11g のスループットとしては平均的な値だろう。

以上のように、MBA から WiFi AP を自由に選べる事を利用して、 各接続のスループットを測定した。

MacPro <-- Gbit Ether --> Lark: 824 Mbps (Reference)
MBA <-- 11an --> Buffalo Router <-- Gbit Ether --> Lark: 102 Mbsp
MBA <-- 11gn --> Buffalo Router <-- Gbit Ether --> Lark: 42.2 Mbsp
MBA <-- 11g  --> Raspi-AP (GNM)   <-- 100BT --> Lark: 17.8 Mbps
MBA <-- 11g  --> Raspi-AP (G301N) <-- 100BT --> Lark: 18.6 Mbps
ここに、
  1. Lark: Myhome Server (www.otacky.jp)
  2. 11an: 802.11n (5GHz) 40MHz 帯域幅
  3. 11gn: 802.11n (2.4GHz) 20MHz 帯域幅
  4. 100BT: 100BASE-T Ethernet

まとめ


31/1,792,086 Valid CSS! Valid HTML 5.0
Taka Fukuda
Last modified: 2018-08-21 (Tue) 17:35:42 JST