ufsdump で作成したバックアップデータをリモートホストに直接投げたい！
ということで半日ハマリましたこんちくしょう。
結論的にはこのコマンドで落ち着いた。
実行環境： Solaris8（SPARC）
# /usr/sbin/ufsdump 0f - /home | ssh bkuser@192.168.1.100 dd of=/backup/home.ufsdump
うまくとれてるっぽい。もちろん、ssh のセッティングは終わってます。
# /usr/sbin/ufsdump 0f bkuser@192.168.1.100:/backup/home.ufsdump /home
とかだと
DUMP: 192.168.1.100: Connection refused
DUMP: Cannot connect to tape host `192.168.1.100'
DUMP: The ENTIRE dump is aborted.
となってうまくいかない。
基本リモートへは rsh コマンドが読み込まれるようなので rsh あけてみたんだけど Connection refused が Permission denied に変わった。
多分これは rsh の設定不充分なんだろうけど。
環境変数 RSH を ssh にしてあげると ssh でうまくいくよとかネット上に書いてあったけどうまくいかなかった。
ufsdump(1M) にも少しもそんなこと書いてなかったし、嘘なんだろうか。
dd がよくわかってないのでもうちょっと調べてみよう。
単に、リモート側でそのユーザでの .rhosts を用意してないだけです。
僕は普通に rsh でリモートの dd にそのまま食わせてます。
.rhosts は用意してたつもりなんですけどね～
おかしいなぁ・・・
というわけでどうしても rsh を避ける方向でガンバり中です（＾＾；
~/.rhosts が本当に正しいか、ちゃんと検証汁。
- 単なる書式間違い。
- ユーザ名違い。
- パーミッションが不適切。
- rsh クライアントの IP アドレスを逆引きした結果得られる文字列 (ホスト名) が ~/.rhosts に記述してあるものと一致しない。
特に、最後のヤツは、結構引っかかる人が多い。
ウチのグループで rsh を担当してるんで、よくあります。
後は、rsh サーバ側の OS によるものとか。
rsh サーバ側で xinetd 使ってて、ident で蹴られるような設定をしていた、とかも見かけます。
rsh サーバ側で truss かけちゃうのがてっとり早いけど、
解析する人にもよる。
ゴメ。↑のコメント、俺ね。