あなたが持っているすべてがシリアルコンソール(たとえば、ターミナルサーバーを介してtelnetを介して)である場合、ホストとの間でファイルを転送するにはどのような方法を使用できますか?
カット/ペーストは小さい/印刷可能なもので機能し、私はuuencode/uudecodeの組み合わせ(gzipを使用)で印刷できないものを処理しましたが、すべて非常に制限されています。
接続のもう一方の端で使用するシリアルコンソールプログラムには、リモート側にファイルを送信する方法がいくつかあります。どの程度正確にそれを実行するかは、リモートシステムで使用可能なリソースによって異なります。
リモート側にlrzsz
またはKermit
があります
最も簡単なケースは、リモート側に lrzsz
または Kermit
などの固体バイナリファイル転送プログラムがインストールされている場合です。これはかつてより一般的でしたが、特定のシステムにはまだこれらのいずれかが含まれている可能性があります。
ローカル側で使用しているシリアルコンソールプログラムには、ほぼ確実にZmodemまたはKermitのアップロードを行う方法があり、必要なものを直接送信できます。
Zmodemの場合、リモートシステムでrz
と入力するだけで、ローカルシリアルターミナルが理解する必要のある特別な文字列が送信され、ファイルピッカーダイアログがポップアップします。
Kermitはより単純なプロトコルであるため、その場合は手動で転送を開始する必要があります。
バイナリファイル転送プログラムはありませんが、uuencode
/base64
はあります
lrzsz
やKermit
などの適切なバイナリファイル転送プログラムを使用すると、効率、チェックサム、自動再試行、転送再開の中止、複数ファイル転送など、いくつかの利点がありますが、これらは luxuries です。 1つのファイルのみを送信する必要がある場合、またはファイルをほとんど送信しない場合は、ASCII uploads。
ターミナルプロトコル はバイナリデータファイルで発生するバイト値の多くを解釈するため、同じ接続を介してファイルを直接送信することはできません。その場合、どちらかの端の端末エミュレーションコードがデータの一部を解釈しようとし、データを破壊します 混乱 端末処理コードも同様です。
これを回避するには、バイナリデータをローカル側でASCIIの安全なサブセットにエンコードしてから、リモート側で生のバイナリデータに戻します。これが uuencode
と base64
プログラムは、小さなアルゴリズムの選択のみが異なります。
ローカルシステムで、ファイルをエンコードします。²
$ uuencode -o sbf.uue some-binary-file.gz some-binary-file.gz
次に、リモートシステムでこのコマンドを入力し、ローカルシリアルコンソールの「ASCIIアップロード」機能を使用してファイルを送信します。
$ cat | uudecode
ファイルのアップロードが完了したら、 Ctrl-Ccat
から抜け出すために。これで、望んだとおりにリモートシステムにデコードされたファイルができました。
しかし、多くの送信するファイルがあり、印刷可能ですASCIIトランスコーディングは苦痛です!
bootstrap自分自身をより高いレベルのテクノロジーにすることは難しくありません。リモートシステムにCコンパイラがある場合は、以前の手法を使用して、リモートシステムにlrzsz
ソースのコピーを送信できます。コード。ローカル側:
$ uuencode -o lrzsz.tgz.uue lrzsz-0.12.20.tar.gz lrzsz-0.12.20.tar.gz
次に、リモートシステムで、シリアルコンソールプログラムを介して次のように入力します。
$ cat | uudecode
^C
$ tar xvf lrzsz-0.12.20.tar.gz
...build lrzsz normally
最初のコマンドを開始した後、lrzsz.tgz.uue
ファイルをリモートシステムに「ASCIIでアップロード」します。パイプラインはuuencodeされたデータを受け取り、それをバイナリtarballにデコードします。これを解凍してビルドできます。
しかし、私はリモートシステムにCコンパイラを持っていません
リモートシステムにコンパイラがない場合でも、 cross-compile ローカルシステム上のrz
(またはその他の)プログラムを実行し、上記の手法を使用してリモートシステムに送信できます。
脚注:
minicom 、 picocom 、 PuTTY 、 VanDyke CRT ...
このバージョンのuuencode
に入力ファイル名を2回指定する必要があります。1回は入力データのソースに名前を付けるため、もう1回はリモートシステムがデータを出力ファイルにデコードするときにファイルを呼び出す必要があるものを宣言するためです。リモートシステムの出力ファイルに別の名前を付けることが考えられます。
uuencode
のローカルバージョンは異なる動作をする場合があります。
基本的に、シリアルttyを介して転送するには、事前インターネット方式を使用する必要があり、反対側で転送を受信する方法が必要です。明らかにこれを行うための最良の方法は、ZMODEMを使用することです。つまり、受信側にsz
のようなツールがすでに必要です。ただし、これは常に可能であるとは限りません。たとえば、受信ターゲットがネットワークのないルーターである場合などです。
この転送を行う唯一の可能な方法は、8ビットより前のクリーンなスタイルで、ターミナルセーフASCIIを使用してチャネルを直接経由することです。私はほとんどのシステムにインストールされていると思いますより近代的なツールを使用するつもりです。
送信者:
まず、ファイルをエンコードします
base64 file.tar.gz > file.tar.gz.b64
次に、com send-fileコマンドがascii-xfr
であることを確認してください。これが私の接続コマンドラインでした
picocom -f n -p n -d 8 -b 115200 --send-cmd "ascii-xfr -snv" /dev/ttyS0
通常、受信側にascii-xfr
が必要ですが、それがないため、-n
は正しい行末を維持することでこれを回避します。
受信者:
接続が完了したので、受信したファイルが必要なディレクトリに移動します。
cd /tmp/
cat > file.tar.gz.b64
Picocomでは、CTRL + a + sと入力して、送信するファイルの完全パスを入力します。転送が完了したら、CTRL + cを実行してcat
を解除する必要があります。
次に、ファイルをデコードします。
base64 -d file.tar.gz.b64 > file.tar.gz
ASCII転送にはチェックサム保護がありません。受信ボックスにsha512sum
があったので、チェックサムコマンドで十分です。合計が一致することを手動で確認したら、転送が成功したと想定できます!
minicom を試してみてください。
シリアルコンソールだけでこれが機能するかどうかはわかりませんが、ネットワークにアクセスできる場合は、nc(1)
を使用して、TCP/IPを使用してファイルをコピーできます。
# WARNING: Depending on your setup, this could make your system unbootable
[email protected] # nc -l 8675 | dd of=/dev/sdXXX
[email protected] # dd if=/dev/sdYYY | nc destination-box.local 8675
上記の例では、ソースボックスからsdbYYY
を宛先ボックスのsdaXXX
にクローンしました。 TCPポート番号に8675を選択したのは任意であり、アクセスできる任意のポートを使用できます。デバイスである必要はなく、任意のファイルを使用できます。
[email protected] $ nc -l 12345 >> ~/.ssh/authorized_keys
[email protected] $ cat ~/.ssh/id_rsa.pub | nc destination-box.local 12345
2番目の例では、rsa公開鍵(~/.ssh/id_rsa.pub
)をターゲットホストの承認済みキーファイルに追加します。
ファイル転送プログラムの祖父母である Kermit を使用します。 Linuxが登場するずっと前から、それを使っていました。