# HG changeset patch # User Yoshiki Yazawa # Date 1228707031 -32400 # Node ID 3f9f9b087109f1fe8fe55fae75e45546bcc18e56 # Parent 47830e17cd0023d9a1419f25181251c451cc429c more collab.tex diff -r 47830e17cd00 -r 3f9f9b087109 ja/collab.tex --- a/ja/collab.tex Mon Dec 08 02:34:26 2008 +0900 +++ b/ja/collab.tex Mon Dec 08 12:30:31 2008 +0900 @@ -958,67 +958,118 @@ %\subsection{Configuring the server side properly} \subsection{サーバの正しい設定} -Because ssh can be fiddly to set up if you're new to it, there's a -variety of things that can go wrong. Add Mercurial on top, and -there's plenty more scope for head-scratching. Most of these -potential problems occur on the server side, not the client side. The -good news is that once you've gotten a configuration working, it will -usually continue to work indefinitely. +%Because ssh can be fiddly to set up if you're new to it, there's a +%variety of things that can go wrong. Add Mercurial on top, and +%there's plenty more scope for head-scratching. Most of these +%potential problems occur on the server side, not the client side. The +%good news is that once you've gotten a configuration working, it will +%usually continue to work indefinitely. + +sshは慣れていないと設定が難しいため,間違いを犯す余地はいたる所にある. +Mercurialと共に動かす場合,さらに多くが待ち構えている.これらの殆んどがク +ライアント側ではなくサーバ側で起きる.しかし一度きちんと動作する設定をし +てしまえば,動作はずっと続く. -Before you try using Mercurial to talk to an ssh server, it's best to -make sure that you can use the normal \command{ssh} or \command{putty} -command to talk to the server first. If you run into problems with -using these commands directly, Mercurial surely won't work. Worse, it -will obscure the underlying problem. Any time you want to debug -ssh-related Mercurial problems, you should drop back to making sure -that plain ssh client commands work first, \emph{before} you worry -about whether there's a problem with Mercurial. +%Before you try using Mercurial to talk to an ssh server, it's best to +%make sure that you can use the normal \command{ssh} or \command{putty} +%command to talk to the server first. If you run into problems with +%using these commands directly, Mercurial surely won't work. Worse, it +%will obscure the underlying problem. Any time you want to debug +%ssh-related Mercurial problems, you should drop back to making sure +%that plain ssh client commands work first, \emph{before} you worry +%about whether there's a problem with Mercurial. -The first thing to be sure of on the server side is that you can -actually log in from another machine at all. If you can't use -\command{ssh} or \command{putty} to log in, the error message you get -may give you a few hints as to what's wrong. The most common problems -are as follows. +Mercurialからsshサーバに接続する前に,\command{ssh}または\command{putty} +コマンドを使ってサーバに接続してみることを勧める.これらのコマンドを直接 +使って問題が起きるようであれば,Mercurialは動作しないはずだ. sshの上で +Mercurialを使うことで,下位の問題が隠れてしまうので,sshに関連した +Mercurialの問題をデバッグする時は,まずsshクライアントコマンド自体が動作 +することを確認し,その後にMercurialの問題を解決すべきである. + +%The first thing to be sure of on the server side is that you can +%actually log in from another machine at all. If you can't use +%\command{ssh} or \command{putty} to log in, the error message you get +%may give you a few hints as to what's wrong. The most common problems +%are as follows. + +サーバ側でまず確認すべきなのは,他のマシンからログインできるかどうかであ +る. \command{ssh}または\command{putty}コマンドでログインできない場合は, +エラーメッセージに何が悪いのか示すヒントがあるかも知れない.最も一般的な +問題を以下に列挙する. \begin{itemize} -\item If you get a ``connection refused'' error, either there isn't an - SSH daemon running on the server at all, or it's inaccessible due to - firewall configuration. -\item If you get a ``no route to host'' error, you either have an - incorrect address for the server or a seriously locked down firewall - that won't admit its existence at all. -\item If you get a ``permission denied'' error, you may have mistyped - the username on the server, or you could have mistyped your key's - passphrase or the remote user's password. +%\item If you get a ``connection refused'' error, either there isn't an +% SSH daemon running on the server at all, or it's inaccessible due to +% firewall configuration. + \item ``connection refused''エラーが出る時は,SSHデーモンが動作していな + いか,ファイアウォール設定のためにマシンへのアクセスが不可能であ + る可能性がある. +%\item If you get a ``no route to host'' error, you either have an +% incorrect address for the server or a seriously locked down firewall +% that won't admit its existence at all. + \item ``no route to host''エラーが出る場合は,サーバのアドレスを間違え + ているか,ファイアウォールがサーバを完全に隠してしまっていること + が考えられる. +%\item If you get a ``permission denied'' error, you may have mistyped +% the username on the server, or you could have mistyped your key's +% passphrase or the remote user's password. + \item ``permission denied''エラーが出る場合は,ユーザ名を間違って入力し + ているか,ログイン用鍵のパスフレーズやユーザパスワードを間違って + 入力している可能性がある. \end{itemize} -In summary, if you're having trouble talking to the server's ssh -daemon, first make sure that one is running at all. On many systems -it will be installed, but disabled, by default. Once you're done with -this step, you should then check that the server's firewall is -configured to allow incoming connections on the port the ssh daemon is -listening on (usually~22). Don't worry about more exotic -possibilities for misconfiguration until you've checked these two -first. +%In summary, if you're having trouble talking to the server's ssh +%daemon, first make sure that one is running at all. On many systems +%it will be installed, but disabled, by default. Once you're done with +%this step, you should then check that the server's firewall is +%configured to allow incoming connections on the port the ssh daemon is +%listening on (usually~22). Don't worry about more exotic +%possibilities for misconfiguration until you've checked these two +%first. + +まとめると,サーバのsshデーモンへ接続する際には,まずデーモンが動作してい +るかを確認すること.デフォルトでインストールされてはいるが,停止されてい +るシステムもある.これを確認した後でサーバのファイアウォールがsshデーモン +の待機してるポート(通常は22番)への接続を許可しているか確認する.他の諸々 +の可能性を考える前にまずこの2点を確認すべきである. -If you're using an authentication agent on the client side to store -passphrases for your keys, you ought to be able to log into the server -without being prompted for a passphrase or a password. If you're -prompted for a passphrase, there are a few possible culprits. +%If you're using an authentication agent on the client side to store +%passphrases for your keys, you ought to be able to log into the server +%without being prompted for a passphrase or a password. If you're +%prompted for a passphrase, there are a few possible culprits. + +クライアント側で鍵のパスフレーズを記憶させるために認証エージェントを動か +しているなら,パスフレーズやパスワードの入力を促されることなしにサーバに +ログインできるはずだ.もしパスフレーズの入力を要求されるなら,いくつかの +可能性が考えられる. \begin{itemize} -\item You might have forgotten to use \command{ssh-add} or - \command{pageant} to store the passphrase. -\item You might have stored the passphrase for the wrong key. +%\item You might have forgotten to use \command{ssh-add} or +% \command{pageant} to store the passphrase. + \item パスフレーズを記憶させるために\command{ssh-add}または + \command{pageant}を実行していない. +%\item You might have stored the passphrase for the wrong key. + \item 別のキーのパスフレーズを記憶させている. \end{itemize} -If you're being prompted for the remote user's password, there are -another few possible problems to check. +%If you're being prompted for the remote user's password, there are +%another few possible problems to check. +リモートユーザのパスワードを要求される場合は別の問題があるかもしれない. \begin{itemize} -\item Either the user's home directory or their \sdirname{.ssh} - directory might have excessively liberal permissions. As a result, - the ssh daemon will not trust or read their - \sfilename{authorized\_keys} file. For example, a group-writable - home or \sdirname{.ssh} directory will often cause this symptom. -\item The user's \sfilename{authorized\_keys} file may have a problem. - If anyone other than the user owns or can write to that file, the - ssh daemon will not trust or read it. +%\item Either the user's home directory or their \sdirname{.ssh} +% directory might have excessively liberal permissions. As a result, + +% the ssh daemon will not trust or read their +% \sfilename{authorized\_keys} file. For example, a group-writable +% home or \sdirname{.ssh} directory will often cause this symptom. + \item ユーザのホームディレクトリまたは\sdirname{.ssh}ディレクトリのパー + ミッションが緩すぎる.このため,sshデーモンが + \sfilename{authorized\_keys}\sfilename{authorized\_keys}ファイルを + 信頼できないか,あるいは単純に読めない.例えばグループ書き込みパー + ミッションのあるホームディレクトリまたは\sdirname{.ssh}ディレクト + リはこの問題をしばしば引き起こす. +%\item The user's \sfilename{authorized\_keys} file may have a problem. +% If anyone other than the user owns or can write to that file, the +% ssh daemon will not trust or read it. + \item ユーザの\sfilename{authorized\_keys}ファイルに問題がある.ファイ + ルの所有者が別のユーザだったり,他のユーザが書き込みできる場合は + sshデーモンはこのファイルを信頼せず,読み込まない. \end{itemize} %In the ideal world, you should be able to run the following command @@ -1029,50 +1080,84 @@ ssh myserver date \end{codesample2} -If, on your server, you have login scripts that print banners or other -junk even when running non-interactive commands like this, you should -fix them before you continue, so that they only print output if -they're run interactively. Otherwise these banners will at least -clutter up Mercurial's output. Worse, they could potentially cause -problems with running Mercurial commands remotely. Mercurial makes -tries to detect and ignore banners in non-interactive \command{ssh} -sessions, but it is not foolproof. (If you're editing your login -scripts on your server, the usual way to see if a login script is -running in an interactive shell is to check the return code from the -command \Verb|tty -s|.) +%If, on your server, you have login scripts that print banners or other +%junk even when running non-interactive commands like this, you should +%fix them before you continue, so that they only print output if +%they're run interactively. Otherwise these banners will at least +%clutter up Mercurial's output. Worse, they could potentially cause +%problems with running Mercurial commands remotely. Mercurial makes +%tries to detect and ignore banners in non-interactive \command{ssh} +%sessions, but it is not foolproof. (If you're editing your login +%scripts on your server, the usual way to see if a login script is +%running in an interactive shell is to check the return code from the +%command \Verb|tty -s|.) -Once you've verified that plain old ssh is working with your server, -the next step is to ensure that Mercurial runs on the server. The -following command should run successfully: +サーバで,バナーやその他の意味のない文字列を表示するようなログインスクリ +プトを使っている場合,対話的なコマンド以外ではこれらを表示しないようにす +る.これらの文字列はMercurialの出力に混入してしまい,Mercurialコマンドを +リモート実行する妨げとなる. +Mercurialは非対話的な\command{ssh}ではこれらのバナーを検出し,無視しよう +と試みるが,これは万全ではない.(サーバのログインスクリプトを編集する場 +合,ログインスクリプトが対話的シェルで動作しているかを知る方法とし +て,\Verb|tty -s|コマンドのリターンコードをチェックする方法がある.) + +%Once you've verified that plain old ssh is working with your server, +%the next step is to ensure that Mercurial runs on the server. The +%following command should run successfully: +ssh単体でサーバに接続できることを確認したら,Mercurialがサーバで動作する +ことを確認する.次のコマンドが動くかどうか調べてみよう: \begin{codesample2} ssh myserver hg version \end{codesample2} -If you see an error message instead of normal \hgcmd{version} output, -this is usually because you haven't installed Mercurial to -\dirname{/usr/bin}. Don't worry if this is the case; you don't need -to do that. But you should check for a few possible problems. +%If you see an error message instead of normal \hgcmd{version} output, +%this is usually because you haven't installed Mercurial to +%\dirname{/usr/bin}. Don't worry if this is the case; you don't need +%to do that. But you should check for a few possible problems. +\hgcmd{version}の出力ではなくエラーメッセージが表示されるとき +は,\dirname{/usr/bin}にMercurialがインストールされていないことが多い. +この場合,\dirname{/usr/bin}にインストールし直す必要はない.その代わり, +いくつかの問題をチェックすべきである. \begin{itemize} -\item Is Mercurial really installed on the server at all? I know this - sounds trivial, but it's worth checking! -\item Maybe your shell's search path (usually set via the \envar{PATH} - environment variable) is simply misconfigured. -\item Perhaps your \envar{PATH} environment variable is only being set - to point to the location of the \command{hg} executable if the login - session is interactive. This can happen if you're setting the path - in the wrong shell login script. See your shell's documentation for - details. -\item The \envar{PYTHONPATH} environment variable may need to contain - the path to the Mercurial Python modules. It might not be set at - all; it could be incorrect; or it may be set only if the login is - interactive. +%\item Is Mercurial really installed on the server at all? I know this +% sounds trivial, but it's worth checking! + \item サーバにMercurialは本当にインストールされているか? これは下らな + い問いのように思えるが,確認する価値はある. +%\item Maybe your shell's search path (usually set via the \envar{PATH} +% environment variable) is simply misconfigured. + \item シェルのサーチパスが正しく設定されていない.(通常は環境変数 + \envar{PATH}で設定される.) + +%\item Perhaps your \envar{PATH} environment variable is only being set +% to point to the location of the \command{hg} executable if the login + +% session is interactive. This can happen if you're setting the path +% in the wrong shell login script. See your shell's documentation for +% details. + \item 対話的なログインセッションのとき以外は環境変数\envar{PATH}が + \command{hg}実行ファイルのあるパスを指していない.\envar{PATH}を不 + 適切なログインスクリプトで設定しているとこの問題が起きる.詳しくは + シェルのドキュメントを参照すること. +%\item The \envar{PYTHONPATH} environment variable may need to contain +% the path to the Mercurial Python modules. It might not be set at +% all; it could be incorrect; or it may be set only if the login is +% interactive. + \item 環境変数\envar{PYTHONPATH}がMercurial Pythonモジュールを含む必要 + がある場合.これが全く設定されていないか,対話的なログインでのみ + 有効になっている. \end{itemize} -If you can run \hgcmd{version} over an ssh connection, well done! -You've got the server and client sorted out. You should now be able -to use Mercurial to access repositories hosted by that username on -that server. If you run into problems with Mercurial and ssh at this -point, try using the \hggopt{--debug} option to get a clearer picture -of what's going on. +%If you can run \hgcmd{version} over an ssh connection, well done! +%You've got the server and client sorted out. You should now be able +%to use Mercurial to access repositories hosted by that username on +%that server. If you run into problems with Mercurial and ssh at this +%point, try using the \hggopt{--debug} option to get a clearer picture +%of what's going on. + +ssh接続で\hgcmd{version}を実行できたのなら準備は完了だ.サーバとクライア +ントの設定は正しく行われている.これでサーバ側のユーザ名を使ってホストさ +れているリポジトリにMercurialを使ってアクセスできるようになった.ここで問 +題があるのなら,\hggopt{--debug}オプションを使って何が問題なのかをより明 +確に把握して欲しい. %\subsection{Using compression with ssh} \subsection{sshでの圧縮の利用} @@ -1082,40 +1167,55 @@ %the default behaviour of ssh clients is \emph{not} to request %compression. -Mercurialは,sshプロトコルを使った場合は,データの圧縮は行わない.なぜな -らsshプロトコルが透過的にデータの圧縮を行うことができるためである. -しかしsshクライアントのデフォルトの挙動では,圧縮を行わ\emph{ない}. +Mercurialは,sshプロトコルを使った場合は,データの圧縮は行わない.sshプロ +トコルが透過的にデータの圧縮を行うことができるためである.しかしsshクライ +アントのデフォルトの挙動では,圧縮を行わ\emph{ない}. + +%Over any network other than a fast LAN (even a wireless network), +%using compression is likely to significantly speed up Mercurial's +%network operations. For example, over a WAN, someone measured +%compression as reducing the amount of time required to clone a +%particularly large repository from~51 minutes to~17 minutes. -Over any network other than a fast LAN (even a wireless network), -using compression is likely to significantly speed up Mercurial's -network operations. For example, over a WAN, someone measured -compression as reducing the amount of time required to clone a -particularly large repository from~51 minutes to~17 minutes. +高速なLAN以外のネットワーク(ワイヤレスネットワークも含む)で +は,Mercurialのネットワーク動作を高速化するのに圧縮の使用はとても効果的で +ある.あるユーザの計測によれば,WAN経由での大規模なリポジトリのクローン +は,圧縮を使うことで~51分から~17分に短縮することができた. -Both \command{ssh} and \command{plink} accept a \cmdopt{ssh}{-C} -option which turns on compression. You can easily edit your \hgrc\ to -enable compression for all of Mercurial's uses of the ssh protocol. +%Both \command{ssh} and \command{plink} accept a \cmdopt{ssh}{-C} +%option which turns on compression. You can easily edit your \hgrc\ to +%enable compression for all of Mercurial's uses of the ssh protocol. +\command{ssh}コマンドも\command{plink}コマンドも圧縮を有効にする +\cmdopt{ssh}{-C}オプションが使える.\hgrc\ ファイルを編集してMercurialが +圧縮つきのsshプロトコルを使用するように設定することができる. \begin{codesample2} [ui] ssh = ssh -C \end{codesample2} -If you use \command{ssh}, you can configure it to always use -compression when talking to your server. To do this, edit your -\sfilename{.ssh/config} file (which may not yet exist), as follows. +%If you use \command{ssh}, you can configure it to always use +%compression when talking to your server. To do this, edit your +%\sfilename{.ssh/config} file (which may not yet exist), as follows. +\command{ssh}でサーバへ接続する時に常に圧縮を使用するように設定することが +できる.\sfilename{.ssh/config}ファイル(存在しない場合は作成する)を次 +のように編集する. \begin{codesample2} Host hg Compression yes HostName hg.example.com \end{codesample2} -This defines an alias, \texttt{hg}. When you use it on the -\command{ssh} command line or in a Mercurial \texttt{ssh}-protocol -URL, it will cause \command{ssh} to connect to \texttt{hg.example.com} -and use compression. This gives you both a shorter name to type and -compression, each of which is a good thing in its own right. +%This defines an alias, \texttt{hg}. When you use it on the +%\command{ssh} command line or in a Mercurial \texttt{ssh}-protocol +%URL, it will cause \command{ssh} to connect to \texttt{hg.example.com} +%and use compression. This gives you both a shorter name to type and +%compression, each of which is a good thing in its own right. +これはalias \texttt{hg}を定義する.このaliasを\command{ssh}のコマンドライ +ンで使うかMercurial \texttt{ssh}-プロトコル URLで使用すると\command{ssh} +コマンドhは\texttt{hg.example.com}へ圧縮を用いて接続を行う.短縮形のホス +ト名と圧縮の設定を同時に行うことができる. %\section{Serving over HTTP using CGI} -\section{CGIを使用したHTTPでのサービス} +\section{CGIを使用したHTTPによるサービス} \label{sec:collab:cgi} Depending on how ambitious you are, configuring Mercurial's CGI