104-connecting-ja.tex

%\chapter{Connecting to Remote Nodes}
\chapter{リモートノードへの接続}
\label{chap:connecting}

%Interacting with a running server program is traditionally done in one of two ways.
旧来、稼働中のサーバープログラムとやり取りする方法は二つあります。
%One is to do it through an interactive shell kept available by using a \app{screen} or \app{tmux} session that runs in the background and letting someone connect to it.
一つは、インタラクティブシェルを利用可能にした\app{screen} や \app{tmux} のセッションをバックグラウンドに残しておき、それに接続することです。
%The other is to program management functions or comprehensive configuration files that can be dynamically reloaded.
もう一つは、管理機能や、動的にリロードする一括設定ファイルを実装する方法です。

%The interactive session approach is usually okay for software that runs in a strict Read-Eval-Print-Loop (REPL).
インタラクティブセッションを利用する方法は通常、ソフトウェアが厳密なREPL(Read-Eval-Print-Loop, 対話型評価環境)で動作している限りは問題のない方法です。
%The programmed management and configuration approach requires careful planning in whatever tasks you think you'll need to do, and hopefully getting it right.
プログラムによる管理・設定を行う方法では、あなたが必要と思うどんなタスクであっても慎重に計画し、またそれを正しく理解している必要があります。
%Pretty much all systems can try that approach, so I'll skip it given I'm somewhat more interested in the cases where stuff is already bad and no function exists for it.
ほとんどすべてのシステムで後者の方法は試されていますので、説明は飛ばすことにします。
私がもっと興味があるのは、事態が既に悪化していて、その事態に対処する機能が存在しない場合です。

%Erlang uses something closer to an "interactor" than a REPL.
ErlangはREPLというより``インタラクタ''に近いものを使っています。
%Basically, a regular Erlang virtual machine does not need a REPL, and will happily run byte code and stick with that, no shell needed.
基本的には、Erlang仮想マシンはREPLを必要とせず、バイトコードがうまい具合に動作するよう専念すれば良いのです。シェルの必要はありませんね。
%However, because of how it works with concurrency and multiprocessing, and good support for distribution, it is possible to have in-software REPLs that run as arbitrary Erlang processes.
しかしながら、同時実行とマルチプロセッシングを可能にする仕組みや素晴らしい分散サポートのおかげで、Erlangプロセスとして動作するソフトウェア内包のREPLを、好きな数だけ利用できます。

%This means that, unlike a single screen session with a single shell, it's possible to have as many Erlang shells connected and interacting with one virtual machine as you want at a time\footnote{More details on the mechanisms at \href{http://ferd.ca/repl-a-bit-more-and-less-than-that.html}{http://ferd.ca/repl-a-bit-more-and-less-than-that.html}}.
これはつまり、一つのscreenセッションと一つのシェルを使うのとは異なり、たくさんのErlangシェルを好きなだけ同時につかって、一つの仮想マシンとのやり取りを行えるということです。
\footnote{このメカニズムの詳細は\href{http://ferd.ca/repl-a-bit-more-and-less-than-that.html}{http://ferd.ca/repl-a-bit-more-and-less-than-that.html}参照}

%Most common usages will depend on a cookie being present on the two nodes you want to connect together\footnote{More details at \href{http://learnyousomeerlang.com/distribunomicon\#cookies}{http://learnyousomeerlang.com/distribunomicon\#cookies} or \href{http://www.erlang.org/doc/reference\_manual/distributed.html\#id83619}{http://www.erlang.org/doc/reference\_manual/distributed.html\#id83619}}, but there are ways to do it that do not include it.
この機能のもっとも一般的な利用方法は、接続したい二ノードが持つcookieを利用する方法\footnote{詳細は\href{http://learnyousomeerlang.com/distribunomicon\#cookies}{http://learnyousomeerlang.com/distribunomicon\#cookies} か \href{http://www.erlang.org/doc/reference\_manual/distributed.html\#id83619}{http://www.erlang.org/doc/reference\_manual/distributed.html\#id83619}参照}ですが、
cookieを利用しない方法もいくつかあります。
% Most usages will also require the use of named nodes, and all of them will require \emph{a priori} measures to make sure you can contact the node.
多くの方法では名前付きノードが必要で、どんな方法でも\emph{アプリオリな} 接続確認手段は必要です。

%\section{Job Control Mode}
\section{ジョブ制御モード}

%The Job Control Mode (JCL mode) is the menu you get when you press \command{\^{}G} in the Erlang shell.
ジョブ制御モード(Job Control Mode, JCL mode)は、Erlangシェルで \command{\^{}G} を押した時に得られるメニューのことです。
%From that menu, there is an option allowing you to connect to a remote shell:
このメニューの中に、リモートシェルの接続を許可するオプションがあります。

\begin{VerbatimEshell}
(somenode@ferdmbp.local)1>
User switch command
 --> h
  c [nn]            - connect to job
  i [nn]            - interrupt job
  k [nn]            - kill job
  j                 - list all jobs
  s [shell]         - start local shell
  r [node [shell]]  - start remote shell
  q                 - quit erlang
  ? | h             - this message
 --> r 'server@ferdmbp.local'
 --> c
Eshell Vx.x.x  (abort with ^G)
(server@ferdmbp.local)1>
\end{VerbatimEshell}

%When that happens, the local shell runs all the line editing and job management locally, but the evaluation is actually done remotely.
こうすると、ジョブ管理や行編集はローカルシェルにより実行されますが、実際の評価はリモートで行われます。
%All output coming from said remote evaluation will be forwarded to the local shell.
このリモートシェルが評価を行った結果、出力はすべて、ローカルシェルに転送されます。

%To quit the shell, go back in the JCL mode with \command{\^{}G}.
シェルを終了するには\command{\^{}G}を再び押して、ジョブ制御モードに戻ってください。
%This job management is, as I said, done locally, and it is thus safe to quit with \command{\^{}G q}:
先程も行ったように、ジョブ制御はローカルで行われますから、\command{\^{}G q}により終了させても安全です。

\begin{VerbatimEshell}
(server@ferdmbp.local)1>
User switch command
 --> q
\end{VerbatimEshell}

%You may choose to start the initial shell in hidden mode (with the argument \command{-hidden}) to avoid connecting to an entire cluster automatically.
全クラスタに自動的に接続することがないように、最初のシェルをhiddenモード(これには引数 \command{-hidden}が使えます)にしても良いですね。

%\section{Remsh}
\section{Remsh}

%There's a mechanism entirely similar to the one available through the JCL mode, although invoked in a different manner.
呼び出し方は異なりますが、ジョブ制御モードを通じた方法にきわめて似た仕組みがあります。
%The entire JCL mode sequence can by bypassed by starting the shell as follows for long names:
ジョブ制御モードの一連の手順は、ロングネームを使う場合、以下のようにシェルを起動することで省略することができます。

\begin{VerbatimText}
erl -name local@domain.name -remsh remote@domain.name
\end{VerbatimText}

%And as follows for short names:
ショートネームを使う場合は、以下のようになります。

\begin{VerbatimText}
erl -sname local@domain -remsh remote@domain
\end{VerbatimText}

%All other Erlang arguments (such as \command{-hidden} and \command{-setcookie \$COOKIE}) are also valid.
その他の引数(例えば \command{-hidden} や \command{-setcookie \$COOKIE})も利用可能です。
%The underlying mechanisms are the same as when using JCL mode, but the initial shell is started remotely instead of locally (JCL is still local).
下で動いている仕組みはジョブ制御モードの時と同じですが、最初のシェルはローカルではなくリモートで立ち上がります（ジョブ制御では依然としてローカルです）。
%\command{\^{}G}  remains the safest way to exit the remote shell.
リモートシェルから抜ける際にも最も安全な方法は先ほどと変わらず、\command{\^{}G}です。

%\section{SSH Daemon}
\section{SSHデーモン}

%Erlang/OTP comes shipped with an SSH implementation that can both act as a server and a client.
Erlang/OTPにはSSHの実装が標準で備わっており、サーバーとクライアントのどちらの方式でも動作します。
%Part of it is a demo application providing a remote shell working in Erlang.
SSHの実装の一部として用意されているデモアプリケーションは、Erlangで動作するリモートシェルを提供します。

%To get this to work, you usually need to have your keys to have access to SSH stuff remotely in place already, but for quick test purposes, you can get things working by doing:
これを起動するには普通、SSHリモート接続を行うためにあなたの鍵を所定の位置に配置しなければなりませんが、
簡単なテスト目的なら、以下のようにして実行することができます。

\begin{VerbatimEshell}
$ mkdir /tmp/ssh
$ ssh-keygen -t rsa -f /tmp/ssh/ssh_host_rsa_key
$ ssh-keygen -t rsa1 -f /tmp/ssh/ssh_host_key
$ ssh-keygen -t dsa -f /tmp/ssh/ssh_host_dsa_key
$ erl
1> application:ensure_all_started(ssh).
{ok,[crypto,asn1,public_key,ssh]}
2> ssh:daemon(8989, [{system_dir, "/tmp/ssh"},
2>                   {user_dir, "/home/ferd/.ssh"}]).
{ok,<0.52.0>}
\end{VerbatimEshell}

%I've only set a few options here, namely \expression{system\_dir}, which is where the host files are, and \expression{user\_dir}, which contains SSH configuration files.
ここではほんの少しオプションを設定しただけです。
\expression{system\_dir}はホストファイルの置き場、\expression{user\_dir}はSSH設定ファイルの置き場を設定しています。
%There are plenty of other options available to allow for specific passwords, customize handling of public keys, and so on\footnote{Complete instructions with all options to get this set up are available at \href{http://www.erlang.org/doc/man/ssh.html\#daemon-3}{http://www.erlang.org/doc/man/ssh.html\#daemon-3}.}.
この他にも多くのオプションがあり、特定のパスワードを許可したり、公開鍵の取り扱いを変えたりすることが可能です\footnote{ちゃんとしたSSHリモート接続を行うには、詳細な手順と全オプションの説明 \href{http://www.erlang.org/doc/man/ssh.html\#daemon-3}{http://www.erlang.org/doc/man/ssh.html\#daemon-3}を参照してください。}。


%To connect to the daemon, any SSH client will do:
デーモンに接続するには、どんなSSHクライアントでも、以下のようにします。

\begin{VerbatimEshell}
$ ssh -p 8989 ferd@127.0.0.1
Eshell Vx.x.x  (abort with ^G)
1>
\end{VerbatimEshell}

% And with this you can interact with an Erlang installation without having it installed on the current machine.
こうすれば、Erlangを手元のマシンでインストールしていなくても、Erlangを利用できますね。
%Just disconnecting from the SSH session (closing the terminal) will be enough to leave.
シェルから立ち去るときには、(ターミナルを閉じて）SSHセッションを切れば十分です。
%\emph{Do not run} functions such as \expression{q()} or \expression{init:stop()}, which will terminate the remote host.  \footnote{This is true for all methods of interacting with a remote Erlang node.}
\expression{q()}や\expression{init:stop()}のような関数は\emph{実行しない}でください。リモートホストが終了してしまいます\footnote{これは、どんな方法を使うにせよ、リモートのErlangノードとやり取りする際には共通です。}。

%If you have trouble connecting, you can add the \command{-oLogLevel=DEBUG} option to \app{ssh} to get debug output.
もし接続する際に問題が発生したら、\app{ssh}にオプションとして\command{-oLogLevel=DEBUG}をつければ、デバッグ出力が見られます。

%\section{Named Pipes}
\section{名前付きパイプ}

% A little known way to connect with an Erlang node that requires no explicit distribution is through named pipes.
あまり知られてはいませんが、分散Erlangを明示的に用いずにErlangノードに接続する方法として、名前付きパイプを利用するものがあります。
%This can be done by starting Erlang with \app{run\_erl}, which wraps Erlang in a named pipe\footnote{\command{"erl"} is the command being run. Additional arguments can be added after it. For example \command{"erl +K true"} will turn kernel polling on.}:
これはErlangを\app{run\_erl}で起動すれば実現できます。\app{run\_erl}が名前付きパイプの中にErlangをラップしてくれます\footnote{\command{"erl"}が実行されるコマンドです。引数はその後に追加できます。例えば\command{"erl +K true"}でカーネルポーリングが有効になります。}。

\begin{VerbatimEshell}
$ run_erl /tmp/erl_pipe /tmp/log_dir "erl"
\end{VerbatimEshell}

%The first argument is the name of the file that will act as the named pipe.
第一引数は名前付きパイプとして振る舞うファイル名です。
% The second one is where logs will be saved\footnote{Using this method ends up calling fsync for each piece of output, which may give quite a performance hit if a lot of IO is taking place over standard output}.
第二引数はログの保存場所になります\footnote{この方法を使うと出力のたびにfsyncが呼びだされますので、標準出力を介して多くの入出力が発生する場合は、性能にかなり影響するかもしれません。}

%To connect to the node, you use the \app{to\_erl} program:
ノードに接続するには、\app{to\_erl}プログラムを使います。

\begin{VerbatimEshell}
$ to_erl /tmp/erl_pipe
Attaching to /tmp/erl_pipe (^D to exit)

1>
\end{VerbatimEshell}

%And the shell is connected. 
シェルに接続できました。
%Closing stdio (with \command{\^{}D}) will disconnect from the shell while leaving it running.
標準入出力を閉じる(コマンドは\command{\^{}D})ことで、シェルを実行させたまま切断ができます。

%\section{Exercises}
\section{演習}

%\subsection*{Review Questions}
\subsection*{復習問題}

\begin{enumerate}
%	\item What are the 4 ways to connect to a remote node?
	\item リモートノードに接続する４つの方法はなんですか？
%	\item Can you connect to a node that wasn't given a name?
	\item 名前のないノードに接続することはできますか？
% \item What's the command to go into the Job Control Mode (JCL)?
  \item ジョブ制御モードに入るコマンドはなんですか？
% \item Which method(s) of connecting to a remote shell should you avoid for a system that outputs a lot of data to standard output?
  \item 標準出力に多くのデータを吐き出すシステムの場合、リモートシェルの接続方法で避けるべき方法はなんですか？
% \item What instances of remote connections shouldn't be disconnected using \command{\^{}G}?
  \item リモート接続をした際に、\command{\^{}G} で切断してはいけない場合とはどんな時ですか？
% \item What command(s) should never be used to disconnect from a session?
  \item セッションを切断するときに決して行ってはいけないコマンドはなんですか？
% \item Can all of the methods mentioned support having multiple users connected onto the same Erlang node without issue?
  \item この章で説明した方法はすべて、複数ユーザーが同じErlangノードに問題なく接続できるような方法でしょうか？
\end{enumerate}