オタク日記
(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 をインストール
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 を試してみた。 個人的には、- Django の Application である事(⇔ Mezzanine は、Django Project)
- コメントには、Django 組込みの App を使う(⇔ Mezzanine は、 DISQUS を統合)
が、これのインストールは端からつまずいた。 というか、色々な時点で各パッケージの依存関係で行き詰まるのだが、 それから色々弄っていると、ますます「わけわか」になる…… という典型的「投げ出しモード」……
だが、かろうじて踏み止まり、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) 先に django をインストールする必要はない。 (それをやると、たまにおかしな事がおきる。)
- #2) pillow (PIL) だけは別途インストールする必要がある。 (無いと後の方になって文句を言われる。)
- #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) django native の application だけど、改めて追加の要あり。
- #2) Django-1.7 から?このようなディフォルトになったようだ。
- #3) ディフォルトの設定にはこの行が抜けているが、これは必須(Django の bug?)
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')), )とする。
(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 でアクセスしてみると、
下のようなページが表示された。
2014-12-15 (Mon): Django App を mod_wsgi で「実戦配備」(その 2)
公開サーバ (Lark) でゴチャゴチャやって Apache を止めてしまっては不味いだろう、 という事で、ステージングサーバ (Quadra) でまず味見したのに、 そこで動いた App を、 git push/pull で Lark に移しただけではうまく行かなかった……そうは言っても、内心ではそんなにスンナリ行くと信じていた訣ではない。 何しろ「環境」が相当違っている。前回までのトライアルの環境は、
- Python: python3 (= 3.4.0-0ubuntu2)
- Django: 1.6.6 (pip3)
- mod_wsgi: libapache2-mod-wsgi-py3 (3.4-4ubuntu2)
この環境に 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
上記で上手く行く、のは間違いないが、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: この directive は <VirtualHost> の外側にないといけない。
- #2: (ポート番号ではなく)サーバ名での VirtualHost を実現する。
- #3: Django-1.7 以降で必要。1.6.x でも有っても差し支えない。
- #4: index App. の /static/の位置を Lark 向けに変更。
- #5: Apache-2.4 からの書式
- #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
にアクセスすると、首尾良く下のような表示が得られた。
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 が山程出る。試行錯誤の結果、
- models.py の、Boolean フィールドの内 default が未定義のものには全て default=False の記述を追加
- settings.py に
TEST_RUNNER = 'django.test.runner.DiscoverRunner'
を追加
次は、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 の template を使った画面が正常に表示され
- log-in/log-out を含む session control や
- <form> での、新規 index の作製
# 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 さんが「海外パケットし放題」なるものを始めたらしい。 その当時は「俺には関係ないかな」と思っていたが、 今回の旅行のために改めて勉強した。 結構込み入っていて、なかなか理解しがたいところ(何で、 「定額料」なのに二段階なの?とか)もあるが、要は:
- 予めの申請や登録は不要
- 但し現地で特定の(定額対応)キャリアに接続する必要がある
- 一日 25 MB までは、1980円、それ以上は 2,980 円
- 一日の区切は、日本時間の午前零時
空港からパリ市内についた時点で、いきなりその思惑が外れてしまった。 第一に、路上でアクセスできる 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 が呼ばれるようになる。)
それに加えて、#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 との比較で言うと、
- web ページの表示は、大抵の場合、eww の方が良い。 特に Wikipedia は(写真や画像のサイズが押えてあるからか?)程良いレイアウトとなって、 これだけで済ませられるレベル。
- しかし、HTML メールに対しては一長一短。
- そもそも、shr.el は、画像をインライン表示しない。(最初からアテが外れた……)
- ただ、背景色の表示などは一部対応している。 しかし、これが逆効果になる事もある。
- <form> への対応も部分的で、button や list 入力? 等には対応していない。(これについては、eww でも、w3m でも同じ。)
ちなみに、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 のやたら長い意味不明綴りは上手に避けているようで、 例えば、以下のようになる。 これまでも 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 もできない。)ともあれ、新しくしてくれる、というので (今では珍しくなった事もあって、ちょっと嬉しくて :-) あまり深く考えずアップデートした……
が、やってしまって、ちょっと後悔。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 が……
なにしろ「いきなり」な上に、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 とは関係無さそう。
しかし、一番目立つ変化は、ブラウザの eww の導入だろう。 これまでは、HTML 形式の Email を見る時などは w3m (emacs-w3m) を使っていたが、このところ段々使わなくなってきていた。 その両方で、otaku_comm-14Q3 を表示してみた。
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 を持ってきたのは、
- 表示が速くなる
- style を変更できる
しかし、各ページの 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 の脆弱性に関するミステリー
しかも、私はもとより 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
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 附属のもの (nl80211) で十分
- これと関連しているが hostapd も、これについて来るもので OK
- wlan0 と eth0 を同じ subnet にしたのでは満足に動かない (ややこしい事に、ごちゃごちゃ弄っている間に暫くの間動く事もあった……)
- 上の困難を救うのに br0 I/F は役に立たない
- wlan0 と eth0 を異る subnet にし、iptables で両者の間を継ぐ設定にする、のが正解。
- isc-dhcp-server はうまくいかない。udhcpd が良い。
というか、有り体に言うと、 ここにある一番オーソドックスなアプローチでやっと動いた、という事。 (これを最初に見ていれば、こんな「解説」を書く気も起きなかったかも :-)
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/LinuxSD カードの書換えから始めなくても、最新ディストリビューション (2014-09-09) になっているようだ。
ドングルの確認
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 .....これはつまり
- *0) driver module は mac802.11
- *1) 使っているのは Buffalo の WLI-UC-G301N アダプタで、
- *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)
のようにする。ここで
- *3) この行を下手に弄ると、ssh で Raspi にログインできなくなり、Raspi にモニタと KBD を直結しないといけない騒ぎになる——要注意。
- *4) この subnet が、eth0 に dhcp でアサインされる IP の subnet と異なっている事が重要
- *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 とうまく共同するために
- *6)自身の subnet の中でなくても可
- *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:oneth0, 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 に接続。
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 ms192.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ここに、
- Lark: Myhome Server (www.otacky.jp)
- 11an: 802.11n (5GHz) 40MHz 帯域幅
- 11gn: 802.11n (2.4GHz) 20MHz 帯域幅
- 100BT: 100BASE-T Ethernet
まとめ
- Raspberry Pi type B と、Buffalo WLI-UC-GNM 及び WLI-UC-G301N で、AP が構成できた。
- 機能としては、市販の WiFi ルータと比較して遜色がない。今のところ、 Raspi AP でできない事は Ethernet 側から WiFi 側の STA へのアクセスくらいのもの。
- WiFi link のスループットは、
- WLI-UC-GNM: 17.8 Mbps
- WLI-UC-G301N: 18.6 Mbps
380/1,781,625 Taka Fukuda Last modified: 2018-08-21 (Tue) 17:35:42 JST