シェルで外部ファイルを読み込む際の書式チェックについて

Question

前提・実現したいこと

ステージング環境サーバ上のシェルupdate.shで設定ファイル（list.txt：文字コードUTF-8）
を読み込んで、本番環境へWEBコンテンツをアップロード・削除する仕組みを作っています。
※構成図を参照ください

設定ファイルlist.txtは人が記述するので、記述の仕方が間違っていないかと、
文字コードのチェックをしたいのですが、シェルupdate.shでlist.txt読み込む際に
標準エラーで出力させて、ログで確認するしか方法はないでしょうか？

該当のソースコード

list.txt

#_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_
#
# Ver.1.0.0　　2021/03/03作成
#
# Path：
#　  /home/opt/etc/list.txt
# Description:
#　　/home/opt/bin/update.shで読み込む設定ファイル
#
#_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_

TYPE = “update”
TIMING = “schedule”
FILE = “/var/www/html/example.html”
TIME = “15:45 05/04/2021”

update.sh

#!/bin/bash
#_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_
#
# Ver.1.0.0　2021/03/03作成
#
# Path：
#　　/home/opt/bin/update.sh
# Usage :
#　　　CRONで1時間毎に定期実行する
# Description :
#　　　list.txtの各値を読み込み、値に元づき本番へコンテンツを
#　　　アップロード、およびコンテンツを削除する
#
#_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_
# ----------------------------------------------------------
# 事前処理 ： list.txt読み込み
# ----------------------------------------------------------
. ./list.txt
# ----------------------------------------------------------
# メイン処理 ：　コンテンツのアップロード・削除
# ----------------------------------------------------------
if [$TYPE = update] && [$TIMMING = schedule]; then
　 　echo “scp –r ${FILE}  root@本番WEB#1: ${FILE} | at {$TIME}”
elif [$TYPE = delete] && [$TIMMING = schedule] ; then
  　echo “ssh root@本番WEB#1 ‘-exec rm -rf {FILE} ;’ | at {$TIME}”
elif [$TYPE = update] && [$TIMMING = immediate] ; then
  　scp –r ${FILE}  root@本番WEB#1: ${FILE}
elif [$TYPE = delete] && [$TIMMING = immediate] ; then
  　ssh root@本番WEB#1 ‘-exec rm -rf {FILE} ;’
else
    mｖ  /home/opt/LIST_yyyymmdd.txt
fi

補足情報（FW/ツールのバージョンなど）

サーバ：Amazon EC2
OS：Amazon Linux 2
シェル：bash

Comments

[takasima20]

やるなら、list.txt 書いた直後にチェックするツール? にかける方が運用しやすそうな気がします。

[pond]

ありがとうございます。

[dameo]

bashの文法チェックなら、
$ bash -n list.txt
で出来そうに思います。

文字コードについては、
$ iconv -f UTF-8 -t UTF-8 list.txt
で出来そうに思います。

例えばこんな感じです。

$ cat list.txt
HOGE="FUGA"
print('こんにちは')
$ bash -n list.txt
list.txt: 行 2: 予期しないトークン `'こんにちは'' 周辺に構文エラーがあります
list.txt: 行 2: `print('こんにちは')'
$ echo $?
2
$ iconv -f UTF-8 -t CP932 list.txt >list.sjis.txt
$ iconv -f UTF-8 -t UTF-8 list.sjis.txt
HOGE="FUGA"
print('iconv: 位置 19 に不正な入力シーケンスがあります
$ echo $?
1
$

[pond]

ありがとうございます。

[pond]

大変勉強になります。

Answer 1

. ./list.txtで読むのであれば、ファイルがシェルの文法に合ってない場合、エラーになります。

. ./list.txt
if [ $? != 0 ]
then echo 文法エラー
     exit 1
fi

とか。

お書きのlist.txtも変数に代入する意図であれば文法に合ってない記述ですね。

エラーが無くても、必要な変数がセットされてないかも知れない。
rm *のような危険なコマンドが書いてあるかも知れない。

丁寧にやるには、何らかのツール（awkとかRubyとかPythonとか）で、文法をチェックして読み込めば良いのでは無いでしょうか。

Comments

[pond]

ありがとうございます。

Answer 2

受け取ってから弾くのではなく、こういうことがしたいのなら任意の内容のtxtをアップさせるのではなく、入力フォームを作ってそこでバリデーションをかけて想定外の値を入れさせないようにしたほうがいいと思います。
もっとも所詮フロントなのでそこだけで絞ってもやろうと思えば任意の値を埋め込むことはできちゃいますけどね…。

また、そもそもの話になりますが、このやり方だとlist.txtに任意のシェルコマンドを埋め込むことが可能なので危険です。
あと、本番サーバにrootでsshしているのも非常によくありません。sshでのrootログインは原則禁止しましょう。
上記を組み合わせると、本番サーバにroot権限で任意のコマンドが実行できてしまいます。
コマンドでなくても、例えば

TYPE = "delete"
FILE = "/"
TIMING = "immediate"

としただけで本番サーバを破壊できる気がするのですが…。
というわけなので、リスクが高すぎるので本番反映のやり方を見直すべきです。
（※そもそも文法が…という点は一旦度外視しています）

あと、コピペしたときに勝手に変換されたのかもしれませんが、記載の内容だとシングルクオートやダブルクオートが全角なのでどうやってもエラーになると思います。

stgのソースを本番にコピーするのはやめて、ソースをgit管理して何らかの方法でgitリポジトリの内容をデプロイする仕組みにしてはどうでしょうか。
方法はいくらでも出てくるので細かくは割愛しますが、内容によってはsshログインしてgit pull（※）でもいいですし、GitHubを使うならGitHub Actions（※）、AWSを使っているのでCodeDeploy等を使って自動化するもいいでしょう。
CircleCIみたいなサービスを使ってもいいですしね。
GitHubを使うのがダメでもAWSを使っているならCodeCommitが使えます。

※参考
gitでシンプルなデプロイ環境を作る
GitHub ActionsでEC2へのデプロイ自動化(CI/CD)
CodeDeploy のチュートリアル

Comments

[yu_1985]

なんか見覚えある構成だなと思ったら、「お勧めしません」と言った構成にしたんですね…。
https://teratail.com/questions/321751

[pond]

そうなんです。AWSCodeシリーズ、オープンソースのジョブ管理ツールも提案してみたのですが。。
いつもありがとうございます。

[yu_1985]

どのみちこの構成は書いた通りのリスクがあるのでNGですね…。
最低限権限周りを見直してください。

[pond]

ありがとうございます。そうですね。。。
見直しは多々必要そうです。。
このupdate.shだと、複数ファイルがと見込めませんし、
listもtxtでなく、jsonにしたほうが配列とオブジェクトをネスト構造で表現できるため
どんなに複雑なデータ構造でも規定可能シンプルなので動きも軽いので、jsonに変更し
jqコマンドで文字列を取りだす方法が良いのかと考え中です。

[yu_1985]

txtをSCPで上げる、というやり方をする運用者がjsonをきちんと組み立てられますかね？
あと、jsonにしたところで危険なコマンドが実行可能なことに変わりはないのでまずそっちをどうにかする必要があると思うのですが。
更に言うと、jsonにするくらいならyamlにすべきですね。
正直、まだstg経由のポートフォワードで本番アップロードさせたほうがマシだとすら思います。

こんなことするくらいなら例えばjenkinsサーバを1台立ててjenkinsにやらせるとかのほうが遥かに楽だと思うんですけど、この構成でないといけない理由があるんでしょうか？

[pond]

そうですね。AWS Codeシリーズ・Jenkinsを使えば、上記が実現可能なんですよね？
色々ありがとうございます、こちらは一旦クローズさせて頂きます。

[yu_1985]

上記とはどれを指していますか？

先の質問でも回答した内容とかぶりますが、根本的にデプロイの設計をやり直すべきと思うのでまず今の構成は忘れるべきと思います。
元となるソースがきちんと管理されてさえいれば、stgのファイルを本番コピーする必要はどこにもないかと。