- ベストアンサー
対話型のコマンドで入力する値をスクリプトに盛り込んで自動化したい
今まで変更した各種設定を一気に行うシェルスクリプトを作成して、サーバーを再セットアップしてもすぐに今までどおり使えるようにしようとしています。 スクリプト中に対話型のコマンドを記述すると、そこで処理が中断して、入力待ち状態になってしまいます。 しかし、入力値は大抵いつも同じですので、これをスクリプト中に記述して、処理が中断する回数を極力減少させたいと考えています。 passwdコマンドをechoコマンドと組み合わせて次のようにやってみました。 # echo "xxx xxx" | passwd user しかし次のように失敗してしまいました。 Changing password for user user. New password: Retype new password: New password: New password: passwd: Conversation error エラーメッセージより再入力がうまくできていないようです。 さらに3回目の入力が求められていますが、これも謎です。 このような対話型のコマンドとその入力値を全部シェルスクリプトに記述するなどして、処理を自動化する方法をご存知の方は、ぜひ教えてください。
- みんなの回答 (6)
- 専門家の回答
質問者が選んだベストアンサー
- ベストアンサー
noname#243622
回答No.5
その他の回答 (5)
noname#243622
回答No.6
noname#243622
回答No.4
noname#243622
回答No.3
- amru05
- ベストアンサー率63% (33/52)
回答No.2
noname#243622
回答No.1
補足
mazingaさん、決定的なご回答をありがとうございます。 頭が固すぎて、そのような代替案が思い浮かびませんでした。 私のやろうとしていたことは、せっかくのクライアントサーバー型システムの利点を無視することでした。 普通クライアント機はサーバー機よりも数が多いため、サーバー機の資源を変更することでクライアント機の設定を省略できるのであれば、迷わずこちらの手法を採用すべきでした。 そういうわけで、早速この方針でスクリプトを作成してみました。 具体的には、再セットアップする前のサーバー機の /etc/ssh/ssh_host_keyと/etc/ssh/ssh_host_key を保存しておき、再セットアップ時に生成されるこの2ファイルを、保存しておいた2ファイルで上書きするというようにしました。 これで、クライアント機のssh_known_hostsには、サーバー機の/etc/ssh/ssh_host_key.pubの内容が、始めから追加されていることになります。 しかし、このクライアント機を使用してサーバー機に接続してみると、なぜか未知のサーバーである旨の警告が表示されてしまうのです。 さらに、そのままログインすると、サーバー機に現存する/etc/ssh/ssh_host_key.pubとは異なる行がクライアント機のssh_known_hostsに追加され、以後、未知サーバーの警告は表示されなくなります。 サーバー機を何度か再セットアップして、この新しく追加された行が何なのか調査してみました。 調査の結果、この新しく追加された行は、上書きする前の/etc/ssh/ssh_host_key.pubの内容と一致することが分かりました。 どうやら、サーバー再セットアップ時に生成される/etc/ssh/ssh_host_keyと/etc/ssh/ssh_host_key.pubを、セットアップ前のもので上書きしただけでは、以前のSSHサーバーを復元できないようです。 /etc/ssh/ssh_host_keyの情報がログインユーザーには見えないサーバーの奥深くに埋め込まれているのでしょうかね。 mazingaさん、上記について何か情報をお持ちでしたら、ぜひとも教えてください。 さて、私が作成している全てを自動化するスクリプトに疑問の声があがっているようですが、 確かに、自分でもこのスクリプトは今まで消費した労力と比較すると、実用性はきわめて低いと思います。 ですのでmazingaさんの問に答えるとすれば、それは私のこだわりというか意地ですね。 また、実はシェルスクリプトを覚えたのはつい最近でして、今まで手作業でやっていたことが、いろいろ自動化できて感動したというのも、この全自動スクリプトの作成を思い立った一因だと思います。 TrueImageはよく耳にするので、いずれは勉強して導入したいと思います。 そうしたら、今作成しているスクリプトは無意味になってしまいますが・・・。 また、ディスク障害対策として、二重化やDATの導入も行く行くはやりたいです。 さらに、火災等の対策として、遠隔地への退避も、やっている人はやっているようで、バックアップについて本気で取り組むとなると色々考える必要があり、気が遠くなりますね。