Shin x blog
殺伐とした黒い画面にカラフルなキャラがお出迎え
- 2013-03-25 (月)
- unix
一部では「黒い画面」と恐れられているターミナルですが、こんなキャラがお出迎えしてくれると気分も変わるのでは。
ターミナルを開いたり、SSH でログインした時にキャラを表示させる方法です。
/etc/motd にメッセージを書くとログインした時に記述したメッセージを表示することができます。レンタルサーバやクラウドサービスのサーバにログインすると表示されるメッセージも /etc/motd に記載されています。
例えば、さくらの VPS であれば、下記のように記載されています。
% cat /etc/motd SAKURA Internet [Virtual Private Server SERVICE]
AmazonLinux では以下のようになっています。
$ cat /etc/motd
__| __|_ )
_| ( / Amazon Linux AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-ami/2012.09-release-notes/
ここにキャラを表示するエスケープシーケンスを記述すると、ログインした時に表示することができます。
valllog さんのエントリに記載のあったキャラクターのデータをお借りして、データをアップしました。
このデータをダウンロードして、/etc/motd に書き込めば ok です。
$ curl -O https://gist.github.com/shin1x1/5230392/raw/82993c6c1d982447e7e99def4f58fc14fc234665/batz.txt $ sudo -s # cat batz.txt >> /etc/motd
再ログインすると勇敢な戦士が登場します。
削除する時は /etc/motd を編集して、該当部分を削除するだけです。
$ sudo vim /etc/motd
素敵な黒い画面ライフを！
- コメント (Close): 0
- トラックバック (Close): 0
FireMobileSimulator でタブ毎に端末選択を有効にする
FireMobileSimulator でタブ毎に端末選択を有効にする方法です。
単にチェック入れるだけです。Facebook で教えて頂いたのですが、こんな機能あったんですね。。。
調べてみると2011年には対応していたようです。
これまで全然気づかず、携帯サイトのテストは Firefox、スマートフォンのテストは Chrome 、と別ブラウザでやったり、別タブで開いていた Gmail や Facebook がいつの間にかおかしくなったりしてました。
こりゃ便利。
- コメント (Close): 0
- トラックバック (Close): 0
Vagrant で自分の PC に「作って、壊して、元に戻せる」サーバを作る
Vagrant 便利ですね。Web システム構築ではサーバ構築、設定を何度となく繰り返すので、こういった「作って、壊して、元に戻せる」環境が自分の PC にあるというのはとても重宝します。
ここでは Vagrant1.0 を使って、Mac OS X 上に CentOS サーバを構築します。また触ってみて便利だった機能もいくつかご紹介します。
- 1. VirtualBox のインストール
- 2. Vagrant1.0 のインストール
- 3. box ファイルのインストール
- 4. Vagrantfile の作成
- 5. 仮想サーバを起動
- 6. 仮想サーバを停止
- 7. 仮想サーバを削除
- 8. 仮想サーバでhttpdサーバを構築
- 9. sahara プラグインで、作って、壊して、元に戻せる環境を構築
- 10. 複数の仮想サーバを起動
- 11. 仮想サーバのエクスポート
- Q. OS X, ruby, gem のバージョン
Vagrant とは
きちんとして説明は本家サイトを見るのが良いのですが、端的にいうと PC にインストールできる仮想PCを便利に使うツールです。
1.0 では仮想PCとして VirtualBox に対応しています。（1.1 からは VMWare や EC2 などにも対応しています。）
1. VirtualBox のインストール
まず VirtualBox をインストールします。VirtualBox は下記サイトから無料でダウンロードすることができます。
https://www.virtualbox.org/wiki/Downloads
2. Vagrant1.0 のインストール
次に Vagrant をインストールします。最新版は1.1なのですが、まだリリースされたばかりで、後述する便利なプラグインなどが対応していないので、ここでは1.0をインストールします。
Vagrant1.0は公式サイトからパッケージをダウンロードするか、 gem でインストールします。
gem でインストールする場合は以下になります。（追記: gem でインストールした場合、sahara プラグインが動作しない場合があるので、こだわりが無ければ上記パッケージでのインストールをお勧めします。）
$ sudo gem install vagrant
インストールができたら vagrant コマンドが使えるか確認しておきます。
$ vagrant -v Vagrant version 1.0.7
3. box ファイルのインストール
Vagrant で仮想サーバを作成するには box ファイルというイメージファイルが必要になります。box ファイルは自分で作成することもできるのですが、主要な Linux については公開されているファイルがあるので、これをインストールします。
Vagrantbox.es では各OSごとのboxファイルダウンロードURLが一覧として公開されています。CentOS もいくつか種類があるので、その中から CentOS6.4_x86_64 の box ファイル（CentOS 6.4 x86_64 Minimal (VirtualBox Guest Additions 4.2.8, Chef 11.4.0, Puppet 3.1.0)）をインストールします。
下記が box ファイルのインストール例です。
vagrant box add までがコマンドで、centos64_64 の部分が box ファイルの名称です。これは任意に付けることができるので、自分が分かりやすい名前を付けます。その後に box ファイルの URL を指定します。
$ vagrant box add centos64_64 http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.4-x86_64-v20130309.box [vagrant] Downloading with Vagrant::Downloaders::HTTP... [vagrant] Downloading box: http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.4-x86_64-v20130309.box [vagrant] Extracting box... [vagrant] Verifying box... [vagrant] Cleaning up downloaded box...
インストールが完了したら、vagrant box list コマンドで確認します。
% vagrant box list centos64_64
4. Vagrantfile の作成
次に vagrant の設定ファイルである Vagrantfile を作成します。作成する仮想サーバの設定はこのファイルに記述していきます。
Vagrantfile の作成するには vagrant init コマンドを使います。
% mkdir vagrant % cd vagrant % vagrant init ready to `vagrant up` your first virtual environment! Please read the comments in the Vagrantfile as well as documentation on `vagrantup.com` for more information on using Vagrant. % ls Vagrantfile
では Vagrantfile を編集してみましょう。
デフォルトのサンプルの設定がコメントで書かていますが、一旦削除して必要な設定だけ記述しています。
config.vm.box にはベースとなる box 名を指定します。ここでは先程ダウンロードした centos64_64 という box 名を指定しています。
これだけで仮想サーバを起動できるのですが、動作が分かりやすいように config.vm.boot_mode に :gui を指定しています。
% vim Vagrantfile # -*- mode: ruby -*- # vi: set ft=ruby : Vagrant::Config.run do |config| config.vm.box = "centos64_64" config.vm.boot_mode = :gui end
5. 仮想サーバを起動
では実際に仮想サーバを起動してみましょう。
仮想サーバを起動するには、vagrant up コマンドを使います。
% vagrant up [default] Importing base box 'centos64_64'... [default] Matching MAC address for NAT networking... [default] Clearing any previously set forwarded ports... [default] Forwarding ports... [default] -- 22 => 2222 (adapter 1) [default] Creating shared folders metadata... [default] Clearing any previously set network interfaces... [default] Booting VM... [default] Waiting for VM to boot. This can take a few minutes. [default] VM booted and ready for use! [default] Mounting shared folders... [default] -- v-root: /vagrant
コマンドを実行すると VirtualBox が起動します。
起動が完了すると VirtualBox のウィンドウにログインプロンプトが表示されます。
ウィンドウをクリックして、login に vagrant 、password に vagrant を入力するとログインすることができます。
Virtualbox ウィンドウから抜ける時は、ウィンドウ右下に書いてあるとおり、左のコマンドキーを1回押します。（Mac OS X の場合）
vagrant ssh コマンドを使うと、ssh で仮想サーバにログインすることができます。
% vagrant ssh Last login: Thu Mar 21 06:46:13 2013 Welcome to your Vagrant-built virtual machine. [vagrant@localhost ~]$
vagrant status コマンドを使うと、現在の仮想サーバの状態が確認できます。下記では、起動中なので ruuning と表示されています。
% vagrant status Current VM states: default running
6. 仮想サーバを停止
仮想サーバを停止する場合、VirtualBox ウィンドウでログインした状態で、/sbin/shutdown などを実行する方法と vagrant halt コマンドで仮想サーバを停止する方法があります。
下記では vagrant halt コマンドで仮想サーバを停止しています。
% vagrant halt
vagrant status コマンドを実行すると停止していることが分かります。
% vagrant status Current VM states: web1 poweroff
7. 仮想サーバを削除
仮想サーバを削除する場合、vagrant destroy コマンドを使います。
% vagrant destory Are you sure you want to destroy the 'default' VM? [Y/N] y [default] Destroying VM and associated drives...
vagrant status コマンドを実行すると削除されていることが分かります。
% vagrant status Current VM states: default not created
8. 仮想サーバでhttpdサーバを構築
では仮想サーバにhttpdをインストールしてみましょう。
まず Vgrantfile を編集して、仮想サーバの設定を追加します。
Mac 上ですでに各種デーモンが起動しているため、ポートの競合などを避けるために仮想サーバにIPアドレス、ホスト名を付与しています。また、VirtualBox のウィンドウを隠すために config.vm.boot_mode をコメントアウトしています。
% vim Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant::Config.run do |config|
config.vm.box = "centos64_64"
#config.vm.boot_mode = :gui
config.vm.define :web do |web|
web.vm.host_name = "web"
web.vm.network :hostonly, "192.168.33.10"
end
end
では仮想サーバを起動しましょう。
% vagrand up
SSH で仮想サーバにログインします。vagrant ssh コマンドでも可能ですし、IP アドレスを指定して、ssh コマンドでもログインできます。
% vagrand ssh
% ssh vagrant@192.168.33.10 ※パスワードは vagrant
次に httpd をインストールして、起動します。
[vagrant@web ~]$ sudo yum -y install httpd (snip) [vagrant@web ~]$ sudo /sbin/service httpd start
この仮想サーバでは iptables が設定されていて、外部からの通信を遮断してしまいます。VirtualBox を実行している PC から通信できるように全てのフィルタリングルールを削除しておきます。
[vagrant@web ~]$ sudo /sbin/iptables -F [vagrant@web ~]$ sudo /etc/init.d/iptables save
ブラウザから仮想サーバの httpd にアクセスしてみましょう。http://192.168.33.10/ にアクセスするとおなじみのテストページが表示されます。
9. sahara プラグインで、作って、壊して、元に戻せる環境を構築
Vagrant にはプラグインで機能を拡張することができます。いくつかあるプラグインの中から、個人的にこれがあるから Vagrant が使いたくなるというプラグインをご紹介しましょう。
それは sahara プラグインです。sahara プラグインを使うと、データベースのトランザクションにおける rollback のように、サーバへ反映した作業をある時点まで簡単に戻すことができます。
では sahara プラグインをインストールして、気軽に元に戻せる機能を試してみましょう。
9–1. sahara プラグインをインストール
sahara プラグインをインストールするいは、vagrant gem install コマンドを使います。
% vagrant gem install sahara Fetching: Platform-0.4.0.gem (100%) Fetching: open4-1.3.0.gem (100%) Fetching: popen4-0.1.2.gem (100%) Fetching: thor-0.17.0.gem (100%) Fetching: sahara-0.0.13.gem (100%) Successfully installed Platform-0.4.0 Successfully installed open4-1.3.0 Successfully installed popen4-0.1.2 Successfully installed thor-0.17.0 Successfully installed sahara-0.0.13 5 gems installed Installing ri documentation for Platform-0.4.0... Installing ri documentation for open4-1.3.0... Installing ri documentation for popen4-0.1.2... Installing ri documentation for thor-0.17.0... Installing ri documentation for sahara-0.0.13... Installing RDoc documentation for Platform-0.4.0... Installing RDoc documentation for open4-1.3.0... Installing RDoc documentation for popen4-0.1.2... Installing RDoc documentation for thor-0.17.0... Installing RDoc documentation for sahara-0.0.13...
インストールが完了すると、vagrant で利用できるサブコマンドに sandbox が追加されます。
% vagrant
[/Users/shin/vagrant]% vagrant
(snip)
Available subcommands:
box
destroy
gem
halt
init
package
provision
reload
resume
sandbox <---- 追加
ssh
ssh-config
status
suspend
up
For help on any individual command run `vagrant COMMAND -h`
9–2. sahara プラグインを試す
実際に sahara プラグインを試してみましょう。
まず vagrant sandbox on コマンドで、snapshot mode を開始します。これは RDBMS の BEGIN にあたり、rollback した場合にこの時点まで仮想サーバを戻すことができます。
% vagrant sandbox on [web] - Enabling sandbox 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
vagrant sandbox status コマンドを実行すると snapshot mode 中であることが分かります。
% vagrant sandbox status [web] - snapshot mode is on
仮想サーバにログインして、php をインストールします。php コマンドが実行できることが確認できたらログアウトします。
% vagrant ssh Last login: Thu Mar 21 07:10:35 2013 from 192.168.33.1 Welcome to your Vagrant-built virtual machine. [vagrant@web ~]$ sudo yum -y install php [vagrant@web ~]$ php -v PHP 5.3.3 (cli) (built: Feb 22 2013 02:51:11) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies [vagrant@web ~]$ exit
php のインストールを取り消すために、vagrant sandbox rollback コマンドで vagrant sandbox on を実行した時点に戻します。
% vagrant sandbox rollback [web] - powering off machine 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% [web] - roll back machine 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% [web] - starting the machine again
これは仮想サーバが元に戻りました。再度 vagrant ssh でログインしてみると、さきほどインストールした php が存在しません。
[vagrant@web ~]$ php -bash: php: コマンドが見つかりません
rollback を実行した後も snapshot mode が有効なままとなっています。（これは DBMS とは異なります）
% vagrant sandbox status [web] - snapshot mode is on
では、つづけて、sudo rm -rf /bin を実行してみましょう。（必ず仮想サーバで実行して下さい！）
[vagrant@web ~]$ sudo rm -rf /bin (snip) [vagrant@web ~]$ ls -bash: /bin/ls: No such file or directory
こりゃ大変！でも大丈夫。サーバをログアウトして、vagrant sandbox rollback を実行すれば元通り。
% vagrant sandbox rollback [web] - powering off machine 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% [web] - roll back machine 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% [web] - starting the machine again % vagrant ssh [vagrant@web ~]$ ls
snapshot mode を終了する場合は vagrant sandbox off コマンドを実行します。vagrant sandbox off コマンドを実行すると現在の状態をそのまま保存して、snapshot mode が終了します。
% vagrant sandbox off [web] - switching sandbox off 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
vagrant sandbox status で確認すると snapshot mode が終了していることが分かります。
% vagrant sandbox status [web] - snapshot mode is off
10. 複数の仮想サーバを起動
Web システムでは複数台のサーバで構成することが多いのですが、その検証として複数の仮想サーバを起動してみましょう。
Vagrantfile で、config.vm.define を追加して、それぞれの仮想サーバの設定を記述します。以下の設定では、web サーバ 2 台と db サーバ 1 台を起動しています。
config.vm.define の第一引数が仮想サーバの名前となります。db サーバでは、db.vm.cusomise でメモリを 1GB に変更しています。（デフォルトは 512 MB）
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant::Config.run do |config|
config.vm.box = "centos64_64"
#config.vm.boot_mode = :gui
config.vm.define :web1 do |web1|
web1.vm.host_name = "web1"
web1.vm.network :hostonly, "192.168.33.10"
end
config.vm.define :web2 do |web2|
web2.vm.host_name = "web2"
web2.vm.network :hostonly, "192.168.33.11"
end
config.vm.define :db do |db|
db.vm.host_name = "db"
db.vm.network :hostonly, "192.168.33.12"
db.vm.customize ["modifyvm", :id, "--memory", 1024]
end
end
vagrant up コマンドを実行すると 3 台が順番に起動します。
% vagrant up [web1] ... [web2] ... [db] ... % vagrant status Current VM states: web1 running web2 running db running ...
それぞれのコマンドは、仮想サーバ名を指定すると、対象の仮想サーバに対して実行できます。下記では db サーバを起動して、ssh ログインしています。
% vagrant up db % vagrant ssh db
仮想サーバ間の通信は IP アドレスで可能なので、複数サーバ構成を構築することができます。
11. 仮想サーバのエクスポート
構築した仮想サーバを box ファイルにエクスポートすることができます。エクスポートした box ファイルは別の PC でインストールすることができるので、同じ開発環境をチームで共有したり、ベースとなるサーバ環境を用意しておいてプロジェクト毎に差分を変更していくなどが可能となります。
仮想サーバを box ファイルへエクスポートするには、vagrant package コマンドを実行します。
% vagrant package [web1] Attempting graceful shutdown of VM... [web1] Clearing any previously set forwarded ports... [web1] Creating temporary directory for export... [web1] Exporting VM... [web1] Compressing package to: /Users/shin/vagrant/package.box
vagrant package コマンドが完了すると、package.box という box ファイルが作成されています。
% ls package.box package.box
このファイルを vagrant box add コマンドでインストールすれば、この仮想サーバをベースに新たな仮想サーバを作成することができます。
まとめ
Vagrant は Chef や puppet などで自動構築する機能があるので、これらと組み合わせることでより真価を発揮します。
ただ、それらを使わずとも、手軽に触れるサーバ、壊せるサーバ、開発環境としても十二分に便利なツールです。
業務はもちろんですが、ハンズオンなどで参加者に同じ環境を配布したい時にも使えそうなので、活用していきたいですね。
参考
Q. OS X, ruby, gem のバージョン（追記）
ykitade
現行のsaharaはパッチを当てないと使えなくね？OSXとrubyのバージョンが知りたい。
http://b.hatena.ne.jp/ykitade/20130323#bookmark-137571070
OS X は「10.8.3」です。
Vagrant は公式サイトの dmg ファイルからインストールしています。これなら ruby や gem をパッケージに内包しているので問題無く動作しました。バージョンは以下です。
% /Applications/Vagrant/embedded/bin/ruby -v ruby 1.9.3p327 (2012-11-10 revision 37606) [universal.x86_64-darwin12.2.1] % /Applications/Vagrant/embedded/bin/gem -v 1.8.23
- コメント (Close): 0
- トラックバック (Close): 0
CentOS 6.x で ipv6 を無効化する
- 2013-03-18 (月)
- unix
CentOS 6.x で ipv6 を無効化する方法です。
Google で検索すると色々な方法が出てきますが、本家 wiki.centos.org に方法が書いてありました。
ipv6 モジュールは無効化しない
ipv6 モジュールを無効化すると SELinux など別の箇所で問題が出るようなので、これはやらない方が良いようです。
/etc/sysctl.conf で設定
/etc/sysctl.conf に以下の設定を追加します。追加した後は再起動もしくは /sbin/sysctl -p で設定を反映させます。
# ipv6 disable net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1
$ sudo /sbin/sysctl -p
/sbin/ifconfig で確認
設定が反映した後に /sbin/ifconfig -a を見ると ipv6 の情報が表示されていないことが分かります。
設定前は inet6 の行があります。
$ /sbin/ifconfig lo
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
設定後は inet6 の行が表示されません。
$ /sbin/ifconfig lo
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
ただ設定後も netstat an で見ると ipv6 で Listen しているポートがあったりするのが不思議だったりしますが。
$ netstat -an -A inet6 Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 :::111 :::* LISTEN tcp 0 0 :::22 :::* LISTEN tcp 0 0 :::50717 :::* LISTEN udp 0 0 :::855 :::* udp 0 0 :::111 :::* udp 0 0 :::38581 :::*
- コメント (Close): 0
- トラックバック (Close): 0
AWS ELB に SSL 証明書を Management Console で設定する
Management Console で AWS ELB に SSL 証明書を 設定する方法です。
ここではすでに作成されている ELB（HTTP のみを Listen）に HTTPS します。新規で ELB を作成して、そのまま HTTPS を設定する場合も似た手順で設定できます。
対象の ELB の Listeners に HTTPS を追加
対象の ELB の Listeners に HTTPS を追加します。ここでは SSL Terminaion を利用するので、Instance 側は HTTP としています。
Load Balancer Protocol を選択すると SSL Certificate に「Select」というリンクができるのでこれをクリックします。
SSL 証明書を登録
SSL 証明書を登録する画面がポップアップで表示されるので、ここに発行された証明書を登録します。
中間証明書が複数ある場合、Certificate Chain に繋げて記載します。
「Save」ボタンをクリックすると証明書が登録されて、証明書を選択している状態になります。もう一度「Save」ボタンをクリックします。
追加した Listeners を登録
最後に追加した Listeners を登録するために「Save」ボタンをクリックします。これで HTTPS の Listeners と SSL 証明書が登録されたので、ブラウザ等から HTTPS でアクセスして登録した証明書を確認します。
証明書の変更、更新
証明書の更新などで Listeners に登録した証明書を変更する場合は、Listeners の SSL Certificate にて「Change」をクリックします。
ポップアップが表示され、証明書を選択する画面になります。ここでは一度登録した証明書を変更することができないので、Upload a new SSL Certificate を選択して、証明書の登録を行ない、新しい証明書を選択します。
ブラウザで完結するので楽
SSL証明書の登録や更新は、Webを運用をしていくと地味に続くタスクなので Management Console 上で誰でもできるのは楽です。さらに証明書の削除も Management Console でできるようになるとより良いですね。
- コメント (Close): 0
- トラックバック (Close): 0
nginx で Too many open files エラーに対処する
nginx では1プロセスで多くのアクセスを捌くので、アクセス数が増えるとToo many open filesエラーが発生することがあります。
ここでは対処法と調べた内容を残しておきます。
1. fs.file-max の確認
まず fs.file-max の値を確認しておきます。fs.file-max は、システム全体でのファイルディスクリプタの上限数となっており、この値以上のファイルディスクリプタは確保することができません。
現在設定されている値は以下で確認できます。
$ cat /proc/sys/fs/file-max 167488
通常は上記の値で問題無いと思いますが、もしこの値が不足しているようなら設定値を更新します。
$ sudo -s # echo 320000 > /proc/sys/fs/file-max # cat /proc/sys/fs/file-max 320000
再起動時に有効となるように /etc/sysctl.conf に記述しておきます。
$ sudo vim /etc/sysctl.conf fs.file-max=320000
2. worker_rlimit_nofile の指定
次はプロセス毎のファイルディスクリプタ上限数を増やします。
nginx ではプロセス毎のファイルディスクリプタ上限数を指定する設定項目 worker_rlimit_nofile が用意されているので、これを記述します。設定する値は worker_connections の3〜4倍くらいが良いでしょう。
$ sudo vim /etc/nginx/nginx.conf
worker_rlimit_nofile 4096;
(snip)
events {
worker_connections 1024;
}
設定変更後は nginx をリスタートしておきます。
$ sudo /etc/init.d/nginx restart
設定値が反映されているか確認しておきます。ワーカープロセスのプロセスID で limits を確認します。下記では「Max open files」の行がこれに当たるのですが、Soft Limit と Hard Limit 双方とも worker_rlimit_nofile で指定した値が設定されていることが分かります。
$ ps ax | grep nginx | grep worker 17064 ? S 0:00 nginx: worker process $ cat /proc/17604/limits Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 10485760 unlimited bytes Max core file size 0 unlimited bytes Max resident set unlimited unlimited bytes Max processes 8191 8191 processes Max open files 4096 4096 files Max locked memory 32768 32768 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 8191 8191 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0
プロセス毎のファイルディスクリプタ上限数を設定する方法として、ulimit コマンドや /etc/security/limits.conf による記述などがあるのですが、これらは環境によってはデーモン起動では適用されなかったり、起動ファイルに記述する必要があるなど注意が必要です。
nginx ではワーカープロセス初期化処理にて worker_rlimit_nofile で指定した値をsetrlimit(2) で設定するので、ulimit などで指定された値は上書きされます。（ソフトリミット、ハードリミット両方）
参照
おまけ
調べている中で色々と試したのでメモ。
もし同じようなことを試すなら、壊しても問題無い環境で行ないましょう。（私は AWS で EC2 インスタンス（AmazonLinux）を起動して試しました。）
fs.file-max を 0 にする。
$ sudo -s
# echo 0 > /proc/sys/fs/file-max
# cat /proc/sys/fs/file-max
0
- 元のシェルは動作している
# ls -a
. ..
- 一般ユーザに戻るとだめ
# exit
$ ls -la
-bash: start_pipeline: pgrp pipe: Too many open files in system
-bash: /bin/ls: Too many open files in system
- SSH でログインできない
ローカルから別コネクションでSSHでログインしようとしたのですが、ダメでした。
% ssh ec2-user@xxx.xxx.xxx.xxx ssh_exchange_identification: Connection closed by remote host
結局、Management Console からインスタンスを stop & start することに。。。
- /var/log/messages にログが記録される。
再起動後に /var/log/messages を見ると下記のようなログが記録されていました。
Feb 11 13:36:51 ip-10-121-3-15 kernel: [ 221.357976] VFS: file-max limit 0 reached
nginx で worker_rlimit_nofile が適用される箇所
nginx が worker_rlimit_nofile で指定した値をカーネルに設定する箇所をソースコードから探してみました。（nginx1.2.7）
src/os/unix/ngx_process_cycle.c の861行目付近でこの処理が行われています。root でマスタープロセスを実行している場合は、この箇所ではまだ root ユーザで動作しているので、ソフトリミット、ハードリミット共に worker_rlimit_nofile で指定した値が設定されています。
- コメント (Close): 0
- トラックバック (Close): 0
2013年は「リーンな体質」を作り「目的志向」で動く
- 2013-01-06 (日)
- 雑記
あけましておめでとうございます。
新年が明け、2013年となりました。
昨年末は年またぎのプロジェクトが多数あり、さらに年末ぎりぎり（12/29）に勉強会を開催したので、全く年末感がなかったのですが、正月は家にのんびり過ごすことができました。日々のタスクから離れ、一息ついたところで2013年の抱負を考えてみたいと思います。
2012年ふりかえり
まずは昨年のふりかえりから。
昨年は「変化の年」ということで変化していくことを目標にしていました。
結果としては、変化したこと、変化していないことあるのですが、仕事面での大きな変化としては、１×１にこれまで在籍していたスタッフが（それぞれ理由は異なるのですが）次々と退職し、結果一人に戻りました。
2012年がこういった状況になるとは考えていませんでしたが、ある意味、開業当時に戻って新たなスタートを切れるチャンスだと前向きに捉えています。
事業面については自社サービスとして「イベ×めも」をリリースするなどチャレンジは行ったのですが、手応えを感じることはできず、大きな変化とはなりませんでした。
ともあれ、本業の開発についてはおかげさまで順調に推移したので、売上については昨年と比較しても堅調でした。本当にありがとうございました。
プライベートでは大きな良い変化がいくつかあり、その点についても良い一年でした。
Kansai PHP Users Group の活動としては、勉強会やイベントを1–2ヶ月ペースで開催でき、2回目となるPHPカンファレンス関西も5月に開催しました。2012年の大きな変化としては、自分以外の人が開催するイベントが増えたということですね。これは年初に期待していたところであり、良い方向に向かっていると思います。
2013年は「リーンな体質」を作り「目的指向」で動く
2013年は「リーンな体質」（贅肉のとれたスリムな状態）を作り、「目的指向」で動くことを目指します。
持てるリソースには限りがあり、特に時間は1日24時間しかありません。その貴重なリソースをどう振り分けるかを考えるにあたって、どういった目的のためにそれを行うのか、それは行う価値があることなのかを基準にしたいと思います。
さらにそれを効率良く実践するために、これまでの習慣を見直し、俊敏に動ける体質にしていきます。
仕事
これまでなんとなく習慣でやっていたこと、持っているものを見直して、目的を達するのに必要なこと以外は極力省いていきます。そして必要に応じて自動化するなどして効率化します。
例えば環境面として、まず社内サーバを全て廃止します。これには２つ理由があります。今後様々なロケーションで開発ができるような仕組みにしていきたいのが一つ、また可用性や安全性を考慮して、クラウド上にサーバを移したいというのがもう一つの理由です。
現在の社内サーバの用途としては「試験環境」「Git リポジトリ」「Redmine」「Jenkins」「ファイルサーバ」ですが、これらを外部サービスやクラウドへ移行します。
今のところ以下の構成を考えています。ファイルサーバは EC2 インスタンスに Samba なり WebDav なり入れようと思っていますが、そもそもファイルサーバ自体が必要なのかも再考したいところです。（ソースは Git へ、ドキュメント類はRedmineで管理すれば、それほど共有すべきファイルは少ないので。）
- 試験環境 -> AWS VPC(EC2)
- Git リポジトリ -> GitHub Private Repositories or Business Plans
- Redmine -> AWS VPC(EC2)
- Jekins -> AWS VPC(EC2)
- ファイルサーバ -> AWS VPC(EC2)？（まだ検討中）
また現在手作業で行なっている作業もツール化して自動化していきたいところです。特にサーバ構築、特にAWSを使う場合は、まだまだツール化できる余地があるので、ここはぜひやりたいです。
事業面においても、これまでリリースしてきたサービスの見直しを行い、効果が得られていないものについては順次閉鎖を行います。
blog
blog を書く時間もスリム化したいです。アウトプットの量はむしろもっと増やしたいのですが、1本書くのに要する時間が長すぎるのでこれを削減します。あえて時間制限を作って、その時間内で書き上げたものを公開するという方式が良いかもしれません。
SNS
SNS（主に Facebook / Twitter）との付き合い方にも贅肉があります。以前こんなエントリを書きましたが、ついつい見て時間を浪費することは避けたいです。
コミュニティ活動
勉強会などのコミュニティ活動も目的意識を持って取り組みたいと思います。昨年末に勉強会に関するエントリを書いたりもしましたが、「なぜ、やっているのか？」「なにを目的としているのか？」を自分の中で明確にして、活動を行なっていきます。
プライベート
プライベートでも、考えてみると無駄にダラダラと過ごしている時間があります。特に夜中にだらだらテレビ見るのがその最たるものです。夜中は基本何をやっても効率が良くないので、早く寝て朝早く起きる生活に戻していきます。
遊ぶ時間やくつろぐ時間はもちろん必要なので、それはそれとして楽しめば良いのですが、無駄な時間の使い方はしないようにしたいですね。
今年もよろしくお願いします
今年は「第二の開業の年」として、これまで少しづつ溜め込んでいた贅肉をそぎ落としていきます。俊敏に動けるスリムボディを目指していきますので、今年もよろしくお願いします！
- コメント (Close): 0
- トラックバック (Close): 0
「勉強会なんてやらなくて良い」へのコメントありがとうございました！
- 2012-12-31 (月)
- event
先日書いた勉強会なんてやらなくて良いへ多数のコメントありがとうございました。
様々な勉強会に関わる方からコメントを頂き、とても参考になりました。頂いたコメントについて主だったものをまとめておきたいと思います。
セミナー型勉強会からの脱却
頂いたコメントで多かったのが、先のエントリで書いたセミナー型勉強会への違和感、そしてそこから別の形の勉強会を行なっているという内容でした。
予想以上に同じ感覚を持たれている方が多いということに驚きました。
ちょうどエントリを書いた後にリアルでお会いした方からも同様の意見を聞くことができ、やはり従来のセミナー型勉強会から一歩進んで別の形を模索している人が多いようです。
実際に実践されている例を見ると、少人数で議論する、手を動かす、発表し合うなどが多かったです。また交流をメインとされている方もいました。すでに多くの人がそういった動きをされていることを知らなかったのでこれはとても発見がありました。（もっと色んな勉強会を見てみれば、というコメントがありましたが、まさにそういうことですね。）
もちろんセミナー型勉強会には意義はあると思うので、ケースベイケースで開催する目的に合わせて選択していきたいと思います。
やりたくないならやらなければ良いのでは？
エントリを書いた時点ではこういった意見が多いのではと思っていました。
これは至極当然の感想であり、私自身もそう思っている部分はあります。
ただこのまま漫然と同じ事の繰り返しでは意義を見出せないため、なんとか良い方向に進めることはできないかと考え、他の方からのご意見を聞きたいとエントリを書きました。
なお、先のエントリにも書きましたが、他の方が開催されている勉強会について言及する意図は無く、またこれまで開催した勉強会を否定しているわけではありませんのでご理解頂ければ幸いです。
懇親会こそ本番
懇親会についてはそれほど本筋では無かったのですが、こちらへのコメントも多かったです。
懇親会の重要性はとても分かります。お酒を飲みながら、くだけた雰囲気で技術の話をする、ときにはその場でノート PC を開いて、コードを見せて議論する、楽しいですし、とても学べることがあります。この楽しさを否定するつもりは全くないのですが、できればこの楽しみを勉強会本編をやれればと考えています。
飲んだ方がやりやすければ、勉強会開始で乾杯して、発表聞いて、その場で議論でも良いと思います。（ Fukuoka.php は実際にそうやっているそうです:D ）
もちろん場所や内容によって難しい場合があるかもしれませんが、あくまで勉強会が本番で、掘り下げた議論などはその場でできればと思います。
「勉強会」という名称について
「勉強会」という言葉に囚われているのでは？という意見もありました。
私も「勉強会」という名称があまり好きではなく、何か適した名前があればと考えていた時期もあったのですが、なかなか適した名前が思いつかず、定着していた「勉強会」をそのまま使っていました。
いくつか頂いた中で「研究会」という表現があったのですが、これであれば誰か特定の人だけが先生というわけでもなく、みんなで研究するという意味があり、適しているような気がします。（PHP研究会で調べるとあちらのPHP研究会があるようなので、また別の名称が必要ですが）
コメント、言及頂いたエントリ
頂いたコメントは下記リンクにまとめています。勉強会開催に興味がある方であれば参考になるコメントばかりですので、ご覧下さい。
先のエントリへの言及頂いた記事です。ありがとうございました。
- コメント (Close): 0
- トラックバック (Close): 0
勉強会なんてやらなくても良い
- 2012-12-27 (木)
- event
勉強会について考えているもやもやを。
私は、主にPHP界隈の勉強会やカンファレンスを開催したり、運営側として関わったりしているのですが、勉強会を開催することについて最近もやもやと考えています。
勉強会に色々な関わる人（開催、運営、発表、参加などなど）からの意見も聞いてみたく、2012年の終わりに一度吐き出しておこうと思います。勉強会についていろいろなコメントを頂けると嬉しいですm(_ _)m
はじめに、ここでいう「勉強会」というのは、オープンソース界隈で良く開催されている有志がボランティアベースで運営されているものを指します。有料セミナーや別カテゴリのものは想定していません。
また、自分が開催する勉強会について書いていますので、他の方が開催されている勉強会について指摘する意図は一切ありません。
勉強会なんてやらなくても良い
本業が忙しくなると、ついつい勉強会の開催が億劫になってきます。勉強会を開催するには少なからずのコスト（主に時間）がかかります。会場手配、発表者集め、調整、参加募集、当日運営、発表などなど。本業やプライベートが忙しくなってくるにつれて、少しづつ自分が勉強会を開催する、運営することが減って来ました。
以前は勉強会をやりたい、やらなきゃという気持ちが強くあったので、できるだけ時間を絞り出して開催していたのですが、少し熱が落ち着いてきて、開催しない期間が長くなると開催しないことに慣れてきて、さして気にならなくなってきました。
勉強会なんてやらなくても日常生活、業務には何の支障も無いんだなと思うようにもなりました。
おそらく勉強会に一番思い入れがあるのは主催者です。その主催者が「無くても良い？」と思うくらいなので、参加する人にとってもそうなのかもしれない、そもそもやる意味があるの？と考えることが増えてきました。
まだ今は、「開催しないんですか？」と声をかけて頂いたり、スタッフとしてお誘いがあったりで運営に関わったりはするのですが、以前に比べると気持ちが離れて行っているのは確かです。
なぜ勉強会をはじめたか？
そもそも勉強会を開催しはじめた理由は、関西でPHPに関する勉強会がほとんど無かったからです。
勉強会を初めて開催した2007年頃は、関西ではPHPに関する勉強会はほとんど開催されていませんでした。（それ以前は頻繁に開催されていたのですが、ちょうど誰もやっていない時期でした。）
当時は東京で活発にPHPの勉強会が開催されていたので、わざわざ東京まで通っていました。まだ Ust による配信や slideshare などによる資料共有が活発では無かったので、今より勉強会を生で参加する意義が大きかったですし、なにより勉強会というものの魅力に取り憑かれていました。
そんな勉強会をやはり地元関西でやりたいと思い、勉強会を開催するようになりました。散発的な開催でしたが、多くの人に集まって頂き、それなりに充実感がありました。関西でPHPというキーワードで交流できる場ができた、それを作ることができたというのが嬉しかったのを覚えています。
何度かの勉強会開催を経て、2011年に「PHPカンファレンス関西」を開催します。東京で行われていたPHPの大型イベント、PHPカンファレンスを関西で！という想いが、多くの人の協力のおかげで形になりました。これで自分にとって勉強会を開催するということに一つの区切りが付きました。
そして2012年の現在では、関西でもPHP関連の勉強会が開催されています。関西PHP勉強会の他には、関西PHP初心者勉強会、FuelPHP勉強会、そしてWordBench大阪、神戸、WordCampなどです。これはとても素晴らしいことだと思います。
以前は正直、義務感で開催することもあったのですが、現状は無理してまでやらなくても良いという状況になりました。
勉強会の目的
勉強会の目的ってなんでしょう。
単純に楽しい、技術的な話を聞いてみたい、色んな人と話してみたい、色々とありますが、あらためて見つめなおすと、やっぱり一番の目的は「勉強する」「学ぶ」ということだと思います。
これは学校のように知識を詰め込むような勉強ではありません。
発表を聞くのも、色んな人と話すのも学びになります。発表してみると「他人にどう伝えるか？」といった、技術とは異なる学びも得られます。楽しい雰囲気で学べるというのはとても良いことです。
勉強会を開催するようになると、ちょっと別の角度からの目的も出てきます。もっと人を多く集めたい、もっと楽しんでもらいたい、もっと色んな人に注目されたい、、、。どれもこれまである程度は考えていたことですし、悪いことだとは思いません。勉強会開催の目的がそこにあるのならそれも良いでしょう。
ただ、いま私が考える勉強会の目的はやっぱり「学び」です。そして勉強会は、参加した人全員（開催者、発表者、参加者全員）で学び合う場にしたいと思っています。
セミナー型勉強会
発表者が前に立ってスライドを映しながら発表する、参加者はそれを聞く。
勉強会ではお馴染みの形式です。
これがスタンダードな勉強会の形であるとずっと思って来ました。この形式なら会場のキャパまでは参加者数も増やせるのでスケールしやすい方法です。また参加者はただ聞くだけで良いので、気軽に参加できるというメリットもあります。
この形式は全くもって問題無いのですが、ともすれば、発表者=教える人、参加者=教わる人という構図となり、発表者から参加者へ一方通行で終わる形になりがちです。
発表者としても人前で話すだけで得られる学びはありますが、やはりそれを聞いた人からのフィードバックがあるとより深く考えることができ、さらなる学びがあります。
参加者としても漫然と話を聞くよりもフィードバックを返すために思考を張り巡らす方が、より学ぶが得られるのではないでしょうか。
こういった「教える」勉強会はあっても良いですし、自分でも何度も開催してきました。今後もきっと開催すると思います。ただ、これだけが勉強会ではないので、もっと色んな形を模索したいです。
懇親会が本番？
勉強会では良く言われるフレーズです。
「懇親会が本番だよ、だから懇親会に来いよ！」
懇親会は慣れていない人にとっては参加しづらいので、参加しやすいように言っているということもあります。また懇親会の場ならではの濃い話が面白いというのもあります。これはこれで確かに納得できる部分はあります。
一方で、それなら勉強会なんかやらずに懇親会だけやれば良いんじゃないかとも思います。
勉強会を開催することに比べたら、懇親会だけの方がよっぽど楽です。（ただの飲み会なので）
今後やりたい勉強会
こうして悶々と考えている中、色々な勉強会に参加してみて得られたヒントから自分のやりたい勉強会が何となく見えてきました。
まだ漠然としていますが、こんな勉強会をやりたいと思います。
発表者のいない勉強会
「PHP5.5を触ってみる」「BDDでテストを書いてみる」「あのサイトのあの機能を作ってみる」「あえて別の言語を触ってみる」などテーマだけ決めて集まります。あとはみんなであーだーこーだ言いながら、実際にやってみる。そしてそれを共有する勉強会です。
事前準備は場所をおさえるのとテーマを決める程度です。
時にはそのテーマに詳しい人に来てもらって発表してもらうのも良いですが、できるだけ負担無く、みんなで考えて、意見交換して、手を動かして学ぶ形が望ましいです。
これまで参加した勉強会では、読書会やFuelPHP勉強会 大阪が近い感じです。先日のScala関西ビギナーズ 第1回の演習などもそうですね。
参加者全員が発表する勉強会
逆に全員が発表者になる勉強会です。全員が自分の発表内容を考えてきて、それを披露します。勉強会といっても様々なバックグラウンドを持つ人が参加するので、それぞれの視点での発表はぜひ聞いてみたいです。全員発表するので、初めて発表する人も気軽にやりやすいと思います。
これまで参加した勉強会では、関西アンカンファレンスや俺聞けなんかがそうですね。あと以前東京でやっていたPHP懇親会はまさにこれですね。
何をやりたいのか？
勉強会なんて無理してやる必要はありません。義務感に駆られてやるものでもありません。無くなったところで、困る人もそんなにいません。
だからこそ、もしやるなら自分がやりたい勉強会をやった方が良いです。
上であげた形式の勉強会だと10人〜20人くらいで開催するのが理想でしょう。参加者数を増やすのが目的なら不向きかもしれません。
勉強会は相互扶助でこそ成り立つものだと思います。みんなが発表者で参加者で、一緒に学び合いたい、これが今自分がやりたい勉強会です。
みなさんからのコメント
多数のコメントありがとうございます！せっかくなので、togetterにまとめたので、こちらもぜひ！
「勉強会なんてやらなくても良い」へのコメントまとめ
頂いたコメントをまとめました。こちらもご覧下さい。
「勉強会なんてやらなくて良い」へのコメントありがとうございました！
- コメント (Close): 0
- トラックバック (Close): 0
CakePHP 2.3 の新機能 ServerShell の話
CakePHP 2.3 に追加された機能 ServerShell についてです。
CakePHP Advent Calendar 2012の11日目です。昨日は社会派ブロガーに仲間入りした yandod さんの「カンファレンスなどで海外からゲストを呼ぶ際に注意すること」でした。いつも横で見てるだけですが、海外から人を招くのは大変ですね。
さて11日目の今日は CakePHP 2.3 に追加された ServerShell を実装して、pull request したという話を。
ServerShell
ServerShell は CakePHPアプリケーションを動かすための httpd サーバを起動する機能です。Apache などを設定せずとも簡単にCakePHPアプリケーションを起動することができます。
使い方
まず、CakePHP2.3RC1 をダウンロードします。github に zip パッケージがあるのでこれをダウンロードするのが簡単です。
https://github.com/cakephp/cakephp/archive/2.3.0-RC1.zip
zip を解凍して、ServerShell を実行します。
$ ./app/Console server
デフォルトでは80ポートでListenするので、すでにApache等を実行している環境では、-p でポートを変更すると良いでしょう。
$ ./app/Console server -p 8001
Welcome to CakePHP v2.3.0-RC1 Console
---------------------------------------------------------------
App : app
Path: /path/to/cakephp-2.3.0-RC1/app/
DocumentRoot: /path/to/cakephp-2.3.0-RC1/app/webroot
-------------------------------------------------------
built-in server is running in http://localhost:8001/
ブラウザで最後の行に表示されたURL（http://localhost:8001/）にアクセスするとおなじみの画面が表示されます。
ああ、簡単:D
PHP5.4 以上が対象
この機能は PHP5.4 以降でのみ実行することができます。PHP5.4 未満で実行すると下記のようにエラーが表示されます。
仕組み
ここまでご覧になった方はおおよそ予想が付くと思いますが、実は ServerShell は PHP5.4 で追加されたビルトインサーバをラップしただけです。また、ビルトインサーバ上で動かすための改良を少し加えています。
ビルトインサーバをベースとしてますので、ServerShell は開発環境でのみ利用するようにして下さい。
ソースはこちらにあるので気になる方はどうぞ。
https://github.com/cakephp/cakephp/blob/2.3/lib/Cake/Console/Command/ServerShell.php
作った経緯
以前から CakePHP アプリケーションを簡単に動かすために httpd サーバを CakePHP パッケージに追加したいと思っていました。（こんなの作ったりしてみました）PHP5.4 のビルトインサーバの登場により簡単に実現することができました。
ハンズオンの勉強会を開催していても、やはり環境構築でつまづく方が多かったので、これを使えば簡単に CakePHP を試すことができます。
まだ試していないですが、CandyCane や baserCMS など CakePHP で作られたシステムも .htaccess が CakePHP デフォルトのままであれば動作すると思います。
pull request から取り込まれるまで
7月に福岡でCakePHP翻訳合宿があったのですが、その際に基本的な実装を行なって、pull request を送りました。
反応がいまひとつ予想できなかったのですが、以前にCakePHP1.3向けビルトインサーバ対応パッチを pull request して、取り込まれたこともあったので、とりあえず送って見ることにしました。
細かな指摘は多数あったのですが、結果としてはそれほど反対意見もなく、最初の pull request を投げてから 3 週間ほどして取り込めることになりました。
いくつかあった指摘事項は以下のようなものです。
名前が微妙
ServerShellの「Server」という言葉が汎用的過ぎるのでどうだろ、という意見がありました。
確かにこれは理解できます。別名として「PhpWebserverShell」や「HttpServerShell」という意見もあったのですが、コンソールから入力するのが長いので「ServerShell」で進めました。結果的には、このコマンドで php+web server以外が起動するのは想像できないという意見もあって、ServerShell のままとなりました。
2.3 ブランチへ
はじめは master（当時バージョンは2.2）へ pull request を送信したのですが、2.3 ブランチへ投げて欲しいというリクエストがあったので、2.3 ブランチへ送信し直しました。
typo, インデント, メッセージ など細々とした修正
大筋は問題無かったのですが、typo やインデント、メッセージの書き方などは多数指摘がありました。やっぱり他人の目で見るとボロボロ出てきますね＞＜コードレビュー大事です。
とくに CakePHP 本体に取り込まれるコードなので、CakePHP のコーディング規約に乗っ取るようにとの指摘がありました。コーディング規約のチェックには、phpcs を使っているようなので、CakePHP 用のルールでチェックを行い、チェックが通るまで修正を行いました。
- CakePHP Code Sniffer
https://github.com/cakephp/cakephp-codesniffer
やりとりが楽しかった pull request
実際に送信した pull request がこちらです。
https://github.com/cakephp/cakephp/pull/713
https://github.com/cakephp/cakephp/pull/714
これまでいくつか pull request を送信したり、パッチを送ったりはしていたのですが、不具合の指摘が多く、あまり議論になるようなことはありませんでした。
今回も実装の内容についての議論は無かったのですが、細かなことで指摘を受けて、こちらの意見を言って、といったやり取りが有意義でした。pull request を見てもらうと分かりますが、変な英語でもPHPのソースがあるので、それなりに意図は通じたかなと思ってます。
やっぱりこういうのは楽しいですね。
PHP5.4 が普及するのはもう少し先かもしれませんが、機会があれば ServerShell を使ってみて下さい。
- コメント (Close): 0
- トラックバック (Close): 0
- Masashi Shinbara
-
- 執筆したもの
- 固定ページ
- 最近の投稿
- カテゴリー
- アーカイブ
-
- 2016-06
- 2016-02
- 2016-01
- 2015-12
- 2015-10
- 2015-09
- 2015-07
- 2015-06
- 2015-05
- 2015-04
- 2015-03
- 2015-01
- 2014-12
- 2014-11
- 2014-10
- 2014-09
- 2014-08
- 2014-07
- 2014-06
- 2014-05
- 2014-04
- 2014-03
- 2014-02
- 2014-01
- 2013-12
- 2013-11
- 2013-10
- 2013-09
- 2013-08
- 2013-07
- 2013-06
- 2013-05
- 2013-04
- 2013-03
- 2013-02
- 2013-01
- 2012-12
- 2012-11
- 2012-10
- 2012-09
- 2012-08
- 2012-06
- 2012-05
- 2012-03
- 2012-02
- 2012-01
- 2011-12
- 2011-11
- 2011-10
- 2011-08
- 2011-07
- 2011-06
- 2011-05
- 2011-04
- 2011-03
- 2011-02
- 2011-01
- 2010-12
- 2010-11
- 2010-10
- 2010-09
- 2010-08
- 2010-07
- 2010-06
- 2010-05
- 2010-04
- 2010-03
- 2010-02
- 2010-01
- 2009-12
- 2009-11
- 2009-10
- 2009-09
- 2009-08
- 2009-07
- 2009-06
- 2009-05
- 2009-04
- 2009-03
- 2008-12
- 2008-11
- 2008-10
- 2008-08
- 2008-07
- 2008-06
- 2008-05
- 2008-04
- 2008-03
- 2008-02
- 2008-01
- 2007-12
- 2007-11
- 2007-10
- 2007-09
- 2007-08
- 2007-07
- 2007-06
- 2007-05
- 2007-04
- 2007-03
- 2007-02
- 2007-01
- 2006-12
- 2006-11
- 2006-10
- 2006-09
- 2006-08
- 2006-07
- タグクラウド
- 検索
- フィード
- メタ情報