まだrzとszコマンドを使用したり、慣れている人はいますか？

Question 1

rzとszは内部的にどのように機能しますか？

それらは基本的に端末接続を使用して互いに通信し、特定のプロトコルを使用してその接続を介してファイルを送信します。これには、一部の同期（szプログラムが起動時にデータをダンプするわけではないため）、メタデータ処理（ファイル名など）、エラー検出、必要に応じて再送信が含まれます。また、可能な制御文字が送信を妨げるように解釈されるのを防ぐために、いくつかの端末設定を指定したようです。

ただし、実際の契約内容はよくわかりませんが、いくつかのリンクがありますWikipediaのZMODEMページ興味があれば。

実際にはSSH接続を必要としない作業があるかもしれません。たとえば、TCP / IPおよびイーサネットの場合、下位レベルにエラー検出コードがあり、TCPは再送信を処理し、SSHレベルの認証された暗号スイートは少なくとも送信エラーを検出する必要があります（悪意のあるように見えるため）。変更されたデータパケットで））。

SSH接続を介してファイルを送信できます

cat somefile.txt | ssh me@somewhere 'cat > somefile.txt'

これは単にSSH接続を介してデータをダンプするだけですが、SSHは8ビットクリーンなのでうまく機能し、このように使用するとリモート側に端末を設定しないため、端末制御は問題になりません。

もちろん、次のように中間ジャンプホストでSSHクライアントを手動で実行する必要がある場合

myworkstation$ ssh me@jumphost
jumphost$ ssh me@destination

これにより、パイプラインを設定するのが少し難しくなります。次の作業を行う必要があります。

myworkstation$ cat somefile.txt | ssh me@jumphost 'ssh me@destination "cat > somefile.txt"'

入れ子になったコマンドラインがSSHで動作しているかどうかはわかりません。だから、そういう意味でZMODEMを両端で使えば、少なくともターミナルセッションで使えるので、ある程度使える選択肢になりそうだ.

その後、SSHにはProxyCommandジャンプホストの使用を簡素化し、すぐに使用したり、より使いやすくするscp機能がありますsftp。たとえば、参照してください。https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts

rzとszは信頼できますか？他の人はそれを使用していますか？私のニーズに合ったより良い解決策はありますか？

このように古くて人気のないものを使うと怖がります。何が間違っているのかわかりません。私はいつもファイルをアップロードまたはダウンロードした後にsha256sumを実行するのに本当に迷惑です。

まあ、彼らは長い間使用されてきましたが、ファイルは（ほとんど）まだバイトあたり8ビットのデータダンプなので、基本的にはまだ動作する理由はありません。少し昔ながらですが、それ自体には何の問題もありません。もちろん、パフォーマンスは別の問題であり、バグを発見した場合は、それを修正するための積極的な管理者を見つけるのに苦労する準備が必要になる場合があります。

一般的に必須ではありませんが、データを大切にして確実に確認したい場合は、データ転送を手動で確認するのが悪いのかどうかはわかりません。 HTTP経由で何かを転送する場合でも、両方のように切り捨てられた転送を得ることができますwget http://...。curl -o http://...cat | ssh cat

あなたのニーズに最も適したものが何であるかを自分で決定する必要があります。

Answer

rzとszは内部的にどのように機能しますか？

それらは基本的に端末接続を使用して互いに通信し、特定のプロトコルを使用してその接続を介してファイルを送信します。これには、一部の同期（szプログラムが起動時にデータをダンプするわけではないため）、メタデータ処理（ファイル名など）、エラー検出、必要に応じて再送信が含まれます。また、可能な制御文字が送信を妨げるように解釈されるのを防ぐために、いくつかの端末設定を指定したようです。

ただし、実際の契約内容はよくわかりませんが、いくつかのリンクがありますWikipediaのZMODEMページ興味があれば。

実際にはSSH接続を必要としない作業があるかもしれません。たとえば、TCP / IPおよびイーサネットの場合、下位レベルにエラー検出コードがあり、TCPは再送信を処理し、SSHレベルの認証された暗号スイートは少なくとも送信エラーを検出する必要があります（悪意のあるように見えるため）。変更されたデータパケットで））。

SSH接続を介してファイルを送信できます

cat somefile.txt | ssh me@somewhere 'cat > somefile.txt'

これは単にSSH接続を介してデータをダンプするだけですが、SSHは8ビットクリーンなのでうまく機能し、このように使用するとリモート側に端末を設定しないため、端末制御は問題になりません。

もちろん、次のように中間ジャンプホストでSSHクライアントを手動で実行する必要がある場合

myworkstation$ ssh me@jumphost
jumphost$ ssh me@destination

これにより、パイプラインを設定するのが少し難しくなります。次の作業を行う必要があります。

myworkstation$ cat somefile.txt | ssh me@jumphost 'ssh me@destination "cat > somefile.txt"'

入れ子になったコマンドラインがSSHで動作しているかどうかはわかりません。だから、そういう意味でZMODEMを両端で使えば、少なくともターミナルセッションで使えるので、ある程度使える選択肢になりそうだ.

その後、SSHにはProxyCommandジャンプホストの使用を簡素化し、すぐに使用したり、より使いやすくするscp機能がありますsftp。たとえば、参照してください。https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts

rzとszは信頼できますか？他の人はそれを使用していますか？私のニーズに合ったより良い解決策はありますか？

このように古くて人気のないものを使うと怖がります。何が間違っているのかわかりません。私はいつもファイルをアップロードまたはダウンロードした後にsha256sumを実行するのに本当に迷惑です。

まあ、彼らは長い間使用されてきましたが、ファイルは（ほとんど）まだバイトあたり8ビットのデータダンプなので、基本的にはまだ動作する理由はありません。少し昔ながらですが、それ自体には何の問題もありません。もちろん、パフォーマンスは別の問題であり、バグを発見した場合は、それを修正するための積極的な管理者を見つけるのに苦労する準備が必要になる場合があります。

一般的に必須ではありませんが、データを大切にして確実に確認したい場合は、データ転送を手動で確認するのが悪いのかどうかはわかりません。 HTTP経由で何かを転送する場合でも、両方のように切り捨てられた転送を得ることができますwget http://...。curl -o http://...cat | ssh cat

あなたのニーズに最も適したものが何であるかを自分で決定する必要があります。

Question 2

まず、同じ単語uploadと方法を使用していることを確認しましょう。download

モデム接続では、「アップロード」は「ローカルシステムからリモートシステムにファイルを送信する」を意味し、「ダウンロード」は「リモートシステムからファイルをファイルに送信できるようにする」を意味します。「上」と「下」がどこから来たのか分からない。おそらく、単一の小型PC（または端末でも）が最低レベルで、大規模な中央コンピュータが「より高いステップ」です。

szXshellにはZMODEMプロトコルが組み込まれています。実際には、コマンドはデフォルトでは使用されませんrz。

Xshellの「アップロードコマンド」オプション

「アップロードコマンド」オプションは、どのコマンドがアップロードされるかを決定します。Xshell経由でリモートシステムに送信リモートクラウドサーバー側で何も準備せずにXshellの「ZMODEMを使ってファイルを送る」機能だけを使うなら。したがって、Xshellが送信したらクラウドサーバーが受け取る必要があるため、アップロードコマンドはですrz。

これを行うには、クラウドサーバーとのXshellセッションをコマンドプロンプト状態にし、コマンドを受け取る準備ができている必要があります。そうでない場合（たとえば、topセッションで実行してZMODEMを使用してファイルを送信しようとすると）、ディスプレイが歪んでtop約1分ほど停止し、リモート側で受信を開始できないというメッセージが表示されます。

クラウドサーバーのコマンドプロンプトに入力して、現在存在するディレクトリにファイルをrz受信する準備をクラウドサーバーに指示することもできます。cdこれにより、rzXshellが認識できる特別な文字列が出力され、Xshellは自動的に[ファイルの送信]ダイアログボックスをポップアップし、送信するファイルを指定して転送を開始します。（ZMODEMプロトコルの設計は、送信者が「アップロードコマンド」文字列を送受信者ZMODEMが受信する準備ができている場合、不要なコマンドが自動的に無視されるように設計されています。）

config-backup.zipたとえば、ローカルコンピュータのクラウドサーバーにアクセスしたい場合など、別の方法でファイルを転送したい場合は、sz config-backup.zipクラウドサーバーへのSSHセッションを入力するだけです。クラウドサーバーは、sz(Zmodem 送信)コマンドを起動して別の特殊文字列を出力します.この場合、Xshellはすぐにファイルの受信を開始し、設定されたダウンロードディレクトリにファイルを保存するか、ファイルをダウンロードした後（またはダウンロード中に）ローカルシステムにファイルを配置する場所を尋ねることができます。

少なくとも私のDebian 10システムでは、のマニュアルページにもコマンドもrz含まれており、のマニュアルページにもとが含まれています。変換は各マニュアルページで異なって指定されます。rxrbszsxsb--ascii

rzマニュアルページでこのオプションの説明は--ascii次のとおりです。

 -a, --ascii
         Convert  files to Unix conventions by stripping carriage returns
         and all characters beginning with the first Control Z (CP/M  end
         of file).

sz マニュアルページの説明は次のとおりです。

  -a, --ascii
         Convert NL characters in the transmitted file to CR/LF.  This is
         done by the sender for XMODEM and YMODEM, by  the  receiver  for
         ZMODEM.

したがって、クラウドサーバーから自分にファイルを転送すると、Xshellは実際の変換を処理します。

まだOpenVMSサーバーがいくつかの会社で働いているとき、OpenVMSサーバー管理者は、可能であれば、ファイル形式の変換を別々の明示的なステップで実行することを好むと述べました。彼の推論は、「これが何かが変換されたか、変換がどのように行われたかを確認する唯一の方法でした」でした。文字エンコーディング、ISO-8859-1、ISO-8859-15、最後にUTF-8、およびそれらの間の変換について、私は彼の意見に同意する傾向があります。

また、文字変換結果を確認するたびに、疑わしい変換結果の16進ダンプを実行し、対応するエンコードテーブルと比較して文字を確認する方法を学びました。行末の場合は、次のようにさらに表示するcat -Aことも\rできます。file説明する試してみるのではなく、行末タイプを使用してください展示するそれらを。場合によっては、変換が期待どおりに正しく適用されないことがあります。場合によっては、クラウドサーバーのテキストエディタ、TTYドライバ、または端末がチェックしたい内容を変更する別の変換レイヤを「有用に」適用して、間違った結論を出すことがあります。

Answer