![[PukiWiki]](http://www2.nao.ac.jp/~aste-www/aste_wiki/obs.jpg "[PukiWiki]")
[[Troubleshoot]] > cosmos3_connection_error -Table of contents #contents() -Revision history -- 11-Apr-11 - YO - reprinted. -- 11-Apr-11 - YT - added notes. -- 11-Apr-17 - YO - edit //================================================= *1. COSMOS3サイト間通信のトラブルシュート[#k260867d] ** はじめに [#a69e5491] - 11-Apr-11 - YT - noted. -【注意】この文書は[[田中邦彦さん＠慶応によるページ>http://www2.nao.ac.jp/~aste-www/admin/troubleShoot/cos3TroubleShootByKT.html]]をwikiに転載したものです。 + 「通信が切れた」という以外になんの情報も付されていない報告をしばしば受けます。これは対処しにくい。まずはどのようなトラブルが生じたかを調べリポートするのが、物理実験の超基本的な手順です。 +そこで、下記のトラブルシュートを順番に実施してください。 +トラブル時に通信に関する情報を収集する script が用意されています。下記のトラブルシュートでも解決しない場合には、このスクリプトの出力結果を付して、aste-comp ==at== nro.nao.ac.jp に連絡し、指示を仰いでください。この情報が出てくれば、aste-comp としても動きやすくなります。 // aste-mt2:/home/asteobs/bin/chk_connection.csh //================================================= ** 症状 [#z3c75981] 「COSMOS3でpriorityが取れない/antenna consoleの時計が止まっている」という場合、サイト間の通信がうまく行っていない、という場合がほとんどです。(ごくまれに、サイトのCOSMOS3がハッピーになっている場合があります) ~通信がおかしくなる場合、大抵は三鷹－サイト間の通信(I2,衛星)の過負荷や不安定によって誘発されたものです。 ~※COSMOS3通信はOKだが、AzTEC用通信がダメ、という場合もよくありますが、これについては後述。 ~三鷹がおかしい場合はもちろん、NROでpriorityが取れない、という場合でも、三鷹(aste-mt2)の状況を 確認しておいてください。一番脆いところですので。 一口に通信がおかしい、といっても、次の4通りが考えられます。 // -A) 三鷹－チリ大間のI2通信が不良 -B) チリ大－サイト間の衛星通信が不良 -C) ネットワークレベルでは通信はつながっているが、COSMOS3の通信が復活していない -D) サイト計算機のハードウェア障害 現在(2011/04/16)通信は以下のとおり -野辺山-(台内)-三鷹-(I1)-サンペドロ-(衛星)-サイト --A) 三鷹-サンペドロ間の通信が不良 --B) サンペドロ－サイト間の衛星通信が不良 --C) ネットワークレベルでは通信はつながっているが、COSMOS3の通信が復活していない --D) サイト計算機のハードウェア障害 それぞれに症状が微妙に異なり、対応も当然異なります。 以下、症状の確認方法と対策について書きます。 //================================================= **1.1 症状の確認方法 [#u7302fee] なにはともあれ、aste-mt2(or mt1)からpingを打ってください。 // asteobs@aste-mt2% /usr/sbin/ping aste-mt // これが帰ってこない場合は、ネットワークそのものが不通になっています。何度か試してください。不安定な ときは、pingが成功したりしなかったりを繰り返します。 あるいは、aste-mt1 or mt2でnetscapeを立ち上げ、以下のURL(smokeping)にアクセスしてください。 [[http://210.229.105.4/smokeping/smokeping.cgi?target=ASTE_NETWORK.ASTE]] pingの応答時間と、packet lossの値に注目してください。前者がよくても、後者が悪いということは よくあります。 ネットワークが不安定である場合、どこで不安定になっているかを確かめましょう。次の 二通りのやり方を使っています。 *** tracerouteによる確認方法 [#r5f19d04] asteobs@aste-mt2% /usr/sbin/traceroute -n -q 1 -i hme1 aste-2c 1 210.229.104.129 0.572 ms 2 210.229.97.54 0.732 ms 3 210.229.97.238 1.224 ms 4 210.229.97.75 1.241 ms 5 210.229.97.121 90.075 ms 6 207.231.240.8 90.760 ms 7 64.57.28.27 106.705 ms 8 64.57.28.25 143.863 ms 9 64.57.28.37 141.842 ms 10 64.57.28.13 158.324 ms 11 198.32.11.106 324.185 ms 12 200.0.204.37 350.926 ms 13 200.0.204.29 372.016 ms 14 200.0.204.142 373.650 ms 15 146.83.242.26 372.498 ms <--- チリ大まで通じた 16 200.89.75.138 374.644 ms 17 146.83.248.50 375.368 ms <--- サイトaste-2cまで通じた 18 146.83.248.50 377.466 ms 19 146.83.248.50 378.027 ms 20 146.83.248.50 376.196 ms これで、どこがおかしいかは大体わかります。 -チリ大まで通じているが、aste-2cまで通じない、という場合 は衛星通信が不良になっています。 -チリ大まで通じない、というときはI2の通信がおかしくなっています。 どちらの対処法も基本的には回復待ちの一手ですが、たまに裏技を使っています。後述。 //================================================= *** smokepingによる確認方法 [#wece5871] 上述のsmokepingでも、各HOPまでの安定性を調べることができます。 見方がやや難しいのと、ブラウザを開くのが面倒なのであまり使いませんが、tracerouteとあわせて状況 を確認するために使ってください。 -もちろん、ASTEサイトの機器や、天文台側の機器の故障ということも時々あります。その場合も、 tracerouteで見当がつくはずです。 -MTK-ASTE間通信を調査する場合は、ping先はaste-2cに決めうちせずに、aste-3c, aste-v1cも試しましょう。 -特定の計算機のみがトラブルに陥っている場合、ハードウェア的な故障である可能性が高いです。 //================================================= **1.2 衛星通信が不通/不安定な場合の対処法 [#q363a331] 大抵、強風と同期して起こります、経験上。風でアンテナがぐらついているのでは?という見方が一般的ですが、実のところはよくわかっていません。 -三鷹-サイト間が不安定なときは、大抵サンペドロ-サイト間もダメです。この場合、天候が回復するのを待つ以外にありません。 -まれに、三鷹のみ(あるいはサンペドロのみ)、衛星通信がつながらないことがあります。この場合、商用Internet回線を経由して、サンペドロを親にして三鷹につなぐ(あるいはその逆)、という裏技(難度A+)が可能です。 //================================================= ***商用回線で三鷹->サンペドロにつなぐ方法 [#h169a2f4] -''※ COSMOS3の通信についてよく理解してから作業して下さい。結構難しいです。'' -''※ 以下、サンペドロからの作業が多く発生しますので、現地組の協力が必須です。'' //============= -step1) ssh tunneling -- 三鷹->サンペドロをInternet1で直通する回線は現在ありません。なので、醜くsshのポートフォワーディングを取り回してください。 -- サンペドロにはInternet1のglobal addressを持ったマシンがありませんので、サンペドロ→三鷹という方向でsshログインをし、トンネルを張る必要があります。 --フォワードするポートは、sshのポートです。たとえば、 // asteobs@aste-at3% ssh aste-mt2 -R 30022:aste-at3:22 // とすると、aste-mt2のポート30022への接続が、aste-at3のsshポートへフォワーディングされます。aste-at3でなくと も、サンペドロのマシンならばどれでもOKです。 ---''※ これは古い情報です。現在aste-mt2は外部から直接接続できません。天文台の外部接続サーバを一度経由するような設定にしてください。あるいは、UMassのtacanaやINAOEのtacana2はグローバルマシンですので、そちらに直接つないでもOKです。'' //============= -step2) rsa key -- さて、上記でssh tunnelingができたら、このトンネルを通じて接続ができることを確認してください。 -- COSMOS3は、rootで起動し、上流ホストへ"sshcos3"ユーザでログインします。ですので、root権限で次のコマンドを試してください。 // root@aste-mt2% /opt/OpenSSH/bin/ssh -p 30022 -l sshcos3 -v lh_tunnel test --- ※ssh -p のあとには、フォワードもとのローカルポートを指定してください。この例だと"30022"です。 ---※ホスト名の"lh_tunnel"は/etc/hostsに書かれている通り、ただのlocalhostの別名です。known_hostsに配慮して、 わざとこんな名前にしてあります。 --設定がすべて正しければ、パスワード認証なしで直にaste-at3にログインできます。 --sshcos3@aste-at3側では、通常のシェルではないダミーのシェルが起動しますので、上記ログイン後も制御端末 はとれません。入力コマンド(この場合は"test")の名前を、60秒おきにエコーバックします。 ---※制御端末が取れてしまう場合には、public keyログインの設定不良が考えられます。下の記述に準じて設定を行ってください。 --ログインまでたどり着かない場合、ポートフォワードの設定をひとつづつ確認してください。 --パスワードの入力を求められてしまう場合、rsaキーがaste-at3に登録されていません。aste-mt2の/.ssh/id_rsa.pub の内容を、aste-at3の~sshcos3/.ssh/authorized_keysに登録してください。 --- authorized_keysに登録するときは、以下のオプションを忘れずに! // command="/home/cosmos3/aste/nro/sbin/dmsh",permitopen="aste-at3:9303",permitopen="aste-at3:9402", permitopen="aste-at3:9412",permitopen="aste-at3:9401",permitopen="aste-at3:9103",permitopen="aste-at3:9421", permitopen="localhost:55555",permitopen="localhost:8080",permitopen="localhost:3306",permitopen="aste-2c:22" ssh-rsa AAA(中略) root@aste-mt2 --- ※5行目の"ssh-rsa"以下はroot@aste-mt2の公開鍵の内容です。 --- ※~sshcos3/.sshと、~sshcos3/.ssh/authorized_keysのpermissionはそれぞれ700, 600でなくてはいけません。 --- ※このオプションの意味は、"ログインシェルの代わりにダミーシェルを起動し、これこれのポートのフォワーディングを許可 せよ"ということです。 --- ※~sshcos3の実体は、/home/sshcos3だったり/var/sshcos3だったりサイトによって違います --- ※ダミーシェル"dmsh"の絶対パスは、サイトによって気侭に異なります。 //============= -step3) cosmos3 routing --無事、sshのポートフォワーディング設定ができたら、COSMOS3側でも設定を変更します。 // root@aste-mt2% /home/cosmos3/aste/nro/sbin/cos3_cntl stop root@aste-mt2% su astecntl astecntl@aste-mt2% vi /home/cosmos3/aste/sbin/ssh.proc (使用前) l.15 $opt{$SVHOST} = " -L $PORT:$SVHOST:$PORT -l sshcos3 l.35 exec "$SSH", split(' ',$opt{$host}), $host, "$PROG" (使用後) l.15 $opt{$SVHOST} = " -L $PORT:$SVHOST:$PORT -l sshcos3 -p 30022" l.35 exec "$SSH", split(' ',$opt{$host}), lh_tunnel, "$PROG" astecntl@aste-mt2% vi /home/cosmos3/aste/rc3.d/S98ssh_cosmos (使用前) l.7 UPPER_SITE=cos3serv l.8 ANT_SITE=infoserv (使用後) UPPER_SITE=aste-at3 ANT_SITE=aste-at3 // --概略の意味するところは、COSMOS3が使用するsshの接続先を、"aste-2cのポート22"から、"localhostのポート30022"に変更し、かつ、COSMOS3の接続先をaste-2cからaste-at3へ変更、というところです。 (S98ssh_cosmosのUPPER_SITE, ANT_SITEには、sshログインする先のホストではなく、COSMOS3通信をフォワードする 先のホスト名を書きます) //============= -step4) restart COSMOS3 root@aste-mt2% /home/cosmos3/aste/nro/sbin/cos3_cntl start --ここで問題が発生した場合は、"ネットワークは通じるが、COSMOS3通信が切れている場合の対処法"(後述)を参考 にしてください。 --この技は、新しくサイトを増設する時や、野辺山から直接サイトにつなぐ(三鷹をスキップする)というときにも使えます。 --全裏技中最高難度ですが、しっかりマスターしましょう! ---※ 昔は、上記を簡略に行ってくれるスクリプトがあったのですが、最近の設定変更(8/20@三鷹)に伴い無効に・・ //================================================= **1.3 I2(三鷹ーチリ大間)が不安定な場合の対処法 [#ad28c8f0] tracerouteで、そもそもチリ大までたどり着かない、という場合はI2の実験用回線が不安定な場合です。たまにあります。これは比較的簡単に回避できます。 aste-mt2には(mt1にも) NICが2枚ささっており、 // eri0(on mt1), hme0(on mt2) ---> 天文台I1(146.83.220.xxx) hme0(on mt1), hme1(on mt2) ---> I2 (210.209.104.xxx) // となっています。通常、ASTEサイトにはI2回りのルーティングがなされているのですが、そのI2が不安定 な場合はI1回りでASTEサイトにつなぐようにルーティング設定を変更してください。 -※ ASTEサイトへはaste-mt1/2のI2ポートからしか繋げないはずだったのですが、なぜか今は天文台内 からならつなげてしまいます。いつぞやか、近所の漫画喫茶からつないだこともありますが、今は それは無理みたいです。 (使用前) admin@aste-mt2% netstat -rn Routing Table: Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- 210.229.104.128 210.229.104.131 U 2 393 hme1 133.40.220.0 133.40.220.72 U 3 881 hme0 146.83.248.0 210.229.104.129 UG 0 670 <--- サイト(146.83.248.xxx)へのGWが 210.229.96.0 210.229.104.129 UG 0 3998 hme1(210.229.104.129)になっている 224.0.0.0 133.40.220.72 U 3 0 hme0 default 133.40.220.254 UG 0 7234 127.0.0.1 127.0.0.1 UH 030793181 lo0 (設定変更) admin@aste-mt2% root root@aste-mt2% route delete -net 146.83.248.0 -netmask 255.255.255.0 210.229.104.129 root@aste-mt2% route add -net 146.83.248.0 -netmask 255.255.255.0 133.40.220.254 1 (使用後) admin@aste-mt2% netstat -rn Routing Table: Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- 210.229.104.128 210.229.104.131 U 2 393 hme1 133.40.220.0 133.40.220.72 U 3 881 hme0 146.83.248.0 133.40.220.254 UG 0 670 <--- サイト(146.83.248.xxx)へのGWが 210.229.96.0 210.229.104.129 UG 0 3998 hme0(133.40.220.254)になっている 224.0.0.0 133.40.220.72 U 3 0 hme0 default 133.40.220.254 UG 0 7234 127.0.0.1 127.0.0.1 UH 030793181 lo0 ※ たまに、上記作業でaste-mt2の挙動が怪しくなることがあります。その場合、rebootをすると 直るのですが、routing設定ももとに戻ってしまいます。 // routing設定を固定するには、/etc/init.d/inetsvcスクリプトの最後のほう、 // # ASTE /usr/sbin/route add -net 210.229.96.0 -netmask 255.255.224.0 210.229.104.129 1 /usr/sbin/route add -net 146.83.248.0 -netmask 255.255.255.0 210.229.104.129 1 // これを書き換えてください。(210.229.104.129 -> 133.40.220.254) //================================================= **1.4 ネットワークは通じるが、COSMOS3通信が切れている場合の対処法 [#t83a626d] 三鷹-サイト間のCOSMOS3通信がつながっていない場合のほか、NRO-三鷹のCOSMOS3通信がおかしい場合も、この項を見てください。 また、COSMOS3の接続設定を変更した後(三鷹の親をサンペドロに変更、など)、トラブった場合もこちらを参照。 基本的には、ほぼすべてのトラブルは、 - ASTEサイトから順番に(->MTK/SPdA->NRO)COSMOS3再起動 - それでだめなら、サイト計算機のリブート で解決しますが、COSMOS3の接続設定で間違った設定をしている場合などはその限りではありません。 可能性としては、次の二通りがメインです。 -サイト間でCOSMOS3通信をフォワードしているssh通信が通じていない。 -サイトのCOSMOS3が狂っている。 以下、それぞれ解説します。 //================================================= ***1.4.1 サイト間のCOSMOS3通信の確認方法 [#z5cec016] - ※以下は、基本的にaste-mt2 -- aste-2c間の接続について書いています。 サイト間の通信状況の確認方法です。以下のいくつかを組み合わせて使用してください。 a,b,c,,,と順番に確認せよ、という意味ではありません。 (もちろんそうしてもよいのですが) //============================= ''a) ssh通信プロセスの確認'' COSMOS3は、ASTEサイトを頂点としたカスケード式の通信をしています。実際に 通信を司っているのは各サイトの情報サーバです。 // ASTE(aste-2c) +-MTK(aste-mt2) - NRO(aste-w) | | +- SPdA(aste-at3) 各サイト間の通信は、すべてsshを使ったport forwardingによって担われています。 たとえば asteobs@aste-mt2% ps -ef | grep ssh を実行すると、 // root 7542 7386 0 8?? 22 ? 0:00 /home/cosmos3/aste/local/bin/perl /home/cosmos3/aste/sbin/ssh.proc cos3serv 940 root 7553 7552 0 8?? 22 ? 0:22 /opt/OpenSSH/bin/ssh -L 9421:cos3serv:9421 -l sshcos3 cos3serv SSH_LOCAL_MON root 6549 7560 0 8?? 23 ? 0:00 /home/cosmos3/aste/local/bin/perl /home/cosmos3/aste/sbin/ssh.proc cos3serv 930 root 7560 7391 0 8?? 22 ? 0:00 /home/cosmos3/aste/local/bin/perl /home/cosmos3/aste/sbin/ssh.proc cos3serv 930 root 7552 7551 0 8?? 22 ? 0:01 /home/cosmos3/aste/local/bin/perl /home/cosmos3/aste/sbin/ssh.proc cos3serv 942 root 7551 7403 0 8?? 22 ? 0:00 /home/cosmos3/aste/local/bin/perl /home/cosmos3/aste/sbin/ssh.proc cos3serv 942 root 7547 7387 0 8?? 22 ? 0:00 /home/cosmos3/aste/local/bin/perl /home/cosmos3/aste/sbin/ssh.proc cos3serv 941 root 3244 7534 0 23:58:43 ? 0:00 /home/cosmos3/aste/local/bin/perl /home/cosmos3/aste/sbin/ssh.proc infoserv 910 root 17717 7468 0 04:10:10 pts/19 0:01 /opt/OpenSSH/bin/ssh -C -N sshcos3@aste-2c -p 22 -L 3306:localhost:3306 -L 5555 root 7464 1 0 8?? 22 pts/19 0:00 sh -c /home/cosmos3/aste/nro/sbin/ssh_astaztec3 6 2>&1 | /home/local/bin/awk '{ root 3530 3529 0 23:59:56 ? 0:01 /opt/OpenSSH/bin/ssh -L 9412:cos3serv:9412 -l sshcos3 cos3serv SSH_MGUI root 3529 7547 0 23:59:55 ? 0:00 /home/cosmos3/aste/local/bin/perl /home/cosmos3/aste/sbin/ssh.proc cos3serv 941 root 6550 6549 0 8?? 23 ? 0:02 /opt/OpenSSH/bin/ssh -L 9303:cos3serv:9303 -l sshcos3 cos3serv SSH_MERGE_MON root 7535 7385 0 8?? 22 ? 0:00 /home/cosmos3/aste/local/bin/perl /home/cosmos3/aste/sbin/ssh.proc cos3serv 940 root 7468 7467 0 8?? 22 pts/19 1:28 /bin/sh /home/cosmos3/aste/nro/sbin/ssh_astaztec3 6 root 3565 3564 0 23:59:57 ? 0:01 /opt/OpenSSH/bin/ssh -L 9402:cos3serv:9402 -l sshcos3 cos3serv SSH_QLOOK_CONT root 3245 3244 0 23:58:43 ? 0:11 /opt/OpenSSH/bin/ssh -L 9103:infoserv:9103 -l sshcos3 infoserv SSH_INFO_SERVER root 3564 7542 0 23:59:57 ? 0:00 /home/cosmos3/aste/local/bin/perl /home/cosmos3/aste/sbin/ssh.proc cos3serv 940 root 7534 7384 0 8?? 22 ? 0:00 /home/cosmos3/aste/local/bin/perl /home/cosmos3/aste/sbin/ssh.proc infoserv 910 root 7541 7540 0 8?? 22 ? 0:03 /opt/OpenSSH/bin/ssh -L 9401:cos3serv:9401 -l sshcos3 cos3serv SSH_QLOOK_LINE root 7540 7535 0 8?? 22 ? 0:01 /home/cosmos3/aste/local/bin/perl /home/cosmos3/aste/sbin/ssh.proc cos3serv 940 // このようなプロセスが引っかかります。"ssh.proc"というのがsshを呼び出している元プロセスで、"/opt/OpenSSH/bin/ssh"が sshの実体です。 -たまに、"COSMOS3っぽいプロセス"といっているのは彼らのことを指しています。 -フォワードするポート一つにつき、"ssh.proc"が二つ、"/opt/OpenSSH/bin/ssh"が一つあります。通信には合計6ポート使っているので、 ssh.procが12個動いていれば、上流へのssh接続がつながっているということになります。 // 経験上、6つのフォワーディングが各々単体でおかしくなる、ということはありません。すべてが○か、すべてが×になっていることがほとんどです。たまに、COSMOS3を二重に起動している場合(ssh.procが24個など)がありますので、その場合はlocalのCOSMOS3の再起動を行ってください。 //============================= ''b) COSMOS3のログの確認'' 上記ssh.procは、COSMOS3のデーモンから自動起動されます。 該当する起動デーモンは、 // $COSMOS3/aste/rc3.d/S98ssh_cosmos です。 スクリプト中の"FACILITY=4"というのが、syslogのfacility番号です。/etc/syslog.confと照らし合わせるとわかるように、 ssh.procの出力は、/home/cosmos3/aste/log/4/mess以下に書き出されます。 このログには、sshの出力などがべた書きされていますので、ssh通信がうまくいっているかどうかを判別することができます。 -再接続を頻繁に繰り返している -ログインを拒否されている -ポートフォワードを拒否されている などがわかります。接続先の設定を間違えている場合や、接続先の~sshcos3/.ssh/authorized_keysの記述が間違っている 場合、はたまたssh daemon/clientの設定が元から正しくない場合が考えられます。 //============================= ''c) ネットワーク状態の確認 '' OSレベルで、sshの通信が成立しているかどうかを判別できます。 aste-mt2の場合、 // anyone@aste-mt2% netstat | egrep 'aste-2c\.(22|ssh)' としてみましょう。 // aste-mt2a.59213 aste-2c.22 9660 0 9660 0 ESTABLISHED aste-mt2a.59219 aste-2c.22 9660 0 9660 0 ESTABLISHED aste-mt2a.42107 aste-2c.22 9660 0 9660 0 ESTABLISHED aste-mt2a.46593 aste-2c.22 9660 0 9660 0 ESTABLISHED aste-mt2a.46665 aste-2c.22 9660 0 9660 0 ESTABLISHED aste-mt2a.46668 aste-2c.22 9660 0 9660 0 ESTABLISHED aste-mt2a.33146 aste-2c.22 9660 0 9660 0 ESTABLISHED // このように、COSMOS3用ssh通信が成立しているだけで、6つ(or 7つ)のsshが引っかかります。ほかにaste-2cにコンソールログインしている場合は、当然その分だけ増えます。 通信が正しく行われていない時には、 // aste-mt2a.59213 aste-2c.22 9660 0 9660 0 TIME_WAIT // のような開放されたソケットが大量に引っかかることがあります。これは、タイムアウトになった接続の残滓です。 一つ二つある分には通常でもありえますが、COSMOS3のssh接続に失敗し続けている間は、TIME_WAITソケットが次々に量産されます。 この状況下では、"ESTABLISHED"状態のソケットがある場合でも、信じてはいけません。1分後には、 ~"TIME_WAIT"に転落しているはずです。 //============================= ''d) 直接sshログインしてみる'' これが手っ取り早いかもしれません。 一度COSMOS3をストップして、手動で上流サイトにつないで見ましょう。 // root@aste-mt2% $COSMOS3/aste/nro/sbin/cos3_cntl stop root@aste-mt2% /opt/OpenSSH/bin/ssh -L 9402:aste-2c:9402 -v sshcos3@aste-2c // パスワード認証なしでつながりましたか? つながったら、別のターミナルを開いてcosmos3に接続してみましょう。 // anyone@aste-mt2% telnet localhost 9402 // いったんconnectedになればokです。 (ちなみに9402はcont.qlookの接続です。) - 接続拒否される場合、ポートフォワードが拒否される場合(administravely prohibitedなど)、パスワードを要求されてしまう場合、ssh deamonや、rsa keyの設定が間違っていると思われます。 - また、sshログイン後、制御端末が取れて普通にコマンドが打ててしまう場合も考え物です。本来ならば、sshcos3アカウントではダミーのシェルが起動される設定になっています。ログイン先で、 ~sshcos3/.ssh/authorized_keyのエントリを確認してください。 //============================= ''e) UMass--MTKの間の接続確認'' 以上、すべてaste-mt2とaste-2cの間の接続を例にとって説明しています。 INAOE--UMass間の場合は、ホスト名を適当に読み替えてください( aste-2c -> tacana, aste-mt2 -> tacana2) UMass--aste-mt2間の接続も基本的な原理は同じですが、間に外部接続専用サーバを介しています。つまり、 // tacana.umass --(ssh)--> aste-www.mtk --(ssh)--> aste-mt2.mtk // のようになっています。したがって、UMassにとっての上流サーバはaste-www(133.40.7.130)になります。 aste-wwwでは、COSMOS3用の接続ポート(9402など6つor7つ)をaste-mt2へフォワーディングしています。 // anyone@aste-www% ps -ef | grep ssh root 9139 9130 0 Aug22 ? 00:02:03 /usr/bin/ssh -C -N sshcos3@aste-mt2 -p 22 -L 55555:localhost:55555 -L 3306:loalhost:3306 -L 9103:aste-mt2:9103 -L 9402:aste-mt2:9402 -L 9401:aste-mt2:9401 -L 9421:aste-mt2:9421 -L 9303:aste-mt2:9303 -L 9412:aste-mt2:9412 -L 8080:zod:80 -L 40022:zod:22 -L 10022:aste-2c:22 -vvv ASTEAZTC // などのようなプロセスが存在しているはずです。これは、aztec通信用のportfowardも兼ねています(後述)。起動、終了スクリプトは、 // $COSMOS3/aste/nro/rc3.d/S99ssh_astaztec (stop|start) // です。 //================================================= ***1.4.2 ssh通信がつながらない場合の対処方法 [#a22785ae] 上記で得られた情報を組み合わせると、何がおかしいのかの手がかりはつかめるはずです。 以下のヒントにしたがって、適切に処置してください。 -0) なにはともあれlocalのCOSMOS3の再起動 -a) 何もおかしいところがない場合 -- ひたすら待ってみてください。遅くとも、10分ほどでつながります。 -- 待てど暮らせど復活しない場合、下流サイトのCOSMOS3を停止してみてください。改善する場合があります。 -- それでもだめな場合、上流サイトでトラブルが発生している可能性があります。#1.4.3へ進んでください。 -b) sshのログインが拒否される・ポートフォワーディングが拒否される場合、パスワードを聞かれる場合、 sshでログイン後、制御端末につながってしまう場合、 -- 力量が問われます(嘘)。ヒントとしては、次の設定を確認してください。 // --ログイン先のホスト、アカウントは正しいですか? (三鷹ならば、sshcos3@aste-mt2) --ログイン先の.ssh/aurhorized_keysの設定は正しいですか? --- ~sshcos3/.ssh, ~sshcos3/.ssh/authorized_keys のpermissionは700, 600 --- ~sshcos3/authorized_keysの内容は？ (正しい例) command="/home/cosmos3/aste/nro/sbin/dmsh",permitopen="aste-2c:9303",permitopen="aste-a2c:9402", permitopen="aste-2c:9412",permitopen="aste-2c:9401",permitopen="aste-2c:9103",permitopen="aste-2c:9421", ssh-rsa {localの/.ssh/id_rsa.pubの中身} --- ※"/home/cosmos3/aste/nro/sbin/dmsh"がダミーのシェルで、ログイン後はこのプロセスが強制的に立ち上がります。絶対パス名は、サイトによってまちまちです。(すみません) --- ※ ~sshcos3は、サイトによって /var/sshcos3だったり/home/sshcos3だったりします。(すみません)。/etc/passwdを見てください。 // --ログイン先の/etc/openssh/sshd_config(など)の設定は正しいですか? --- port forwardの許可, RSA認証の許可など、 --ログイン元の/etc/openssh/ssh_config(など)の設定は正しいですか? --- 認証メソッドの順番(PreferredAuthentications; publickeyが一番最初に来ているか?)など -c) COSMOS3を起動すると、意図しないサイトに接続しようとする場合 -- $COSMOS3/aste/rc3.d/S98ssh_cosmosを確認 l.7 UPPER_SITE=cos3serv <-- フォワード先のホスト名 (sshログイン先ではない) l.8 ANT_SITE=infoserv <-- フォワード先のホスト名 ---※ ここで指定したホスト名は、ログイン先の~sshcos3/.ssh/authorized_keysで許可した フォワード先と同一の名前でなくてはならない。同じIPアドレスを指していても、違う名前だとダメ、かも。 ※ localhostはだめ。 ---※ 混乱の元になるので、alias (cos3serv, infoserv)でも指定は本来よくない。hostnameべた書きがよい(aste-2c)など。 -- $COSMOS3/aste/sbin/ssh.procの確認 l.35 exec "$SSH", split(' ',$opt{$host}), $host, "$PROG"; ~~~~~ <== sshログイン先 ---※デフォルトでは、~~~~~部は"$host"となっている。 S98ssh_cosmosで指定したフォワード先のホスト名が$hostの値。大抵の場合はそのままでOK。 ---※ただし、多少凝ったconfigurationにする場合は、当然、sshログイン先とCOSMOS3通信のフォワード先は 別になることがありうる。たとえば、<<1.2 衛星通信が不通/不安定な場合の対処法>>の場合など。 ---※要するに、ssh.procは次のようなコマンドを呼んでいます(見ればわかるけど) ssh -lsshcos3 {ssh.procの~~~~~部で指定したホスト} -L {port}:{S98ssh_cosmosの$UPPER_SITE}:{port} -d) 電源スイッチは入っていますか? -e) 電源ケーブルはコンセントにささっていますか? //================================================= ***1.4.3 上流サイトへssh通信はつながっているが、いまだにCOSMOS3通信が復活しない [#b5bbbdc3] この状態に陥ったときは、pgetはエラー(connection refusedなど)にはならず、すべて"0"を返してくる ことが多いです。antenna consoleの値もすべて0になっています。ローカルのCOSMOS3をリスタートした後は、あせらずに10分ほど根気良く待ってください。 -aste-mt2の場合、NRO, UMassのCOSMOS3を落としておくと直りが早いような気がします。 -それでもだめな場合、サイトCOSMOS3がトラブルに陥っている可能性が高いです。 -特定のプロセスが暴走している場合、通常の手順(cos3_cntl stop)ではとめられないことがあったような気がします。 -プログラムの潜在的なバグである可能性も大いにありますので、時間が許す限り、安易にサイトCOSMOS3のリスタート を行う前に、原因の調査を行うことをお勧めします。 -大抵、aste-2cを調べれば十分ですが、症状によっては1c,3c,1sあたりまで疑いの目を向けてください。代表的な調査ツールは以下。 --a) top --- 定番。cpu timeを食いつぶしているプロセスの有無を調べましょう。 --b) /proc/{pid}/fd/ ---ファイルディスクリプタのリークを調べます。たとえばこんなbash scriptでプロセスの開いているfdの数を 調べられます。 root@aste-2c% for dd in /proc/*; do ( cd $dd/fd; echo -n $dd; ls | wc -l ); done 上限値いっぱいまでディスクリプタを開いているプロセスがないかどうか調べます。 pcv(fd数上限256個), scm(同64個)あたりが常習犯です。 --c) /var/adm/messages ---定番ですが、ここにエラーが残るときは相当ヤバイことが。。。 //================================================= **1.5 サイトの特定の計算機にのみつながらない [#na373969] 経験をつんでくると、上記調査中に悪寒が走ることがあります。 その場合はサイト計算機がハードウェア的な故障を起こしている可能性が高いです。 典型的な症状としては、 -1. サイトの特定の計算機のみにpingが通らない -2. pingは通るが、sshログインができない。あるいは非常に時間がかかる。 -3. /var/adm/messagesに、SCSIエラーやCPUまわりのエラーが出ているorz などがあります。 これについては別項で解説しています。 // EOF
