Gridberryを起動する
Windows 10/11でGridberryを起動し、モデルを接続して、SSHでアクセスできるLinuxサーバーを環境として選択します。各変更があなたを確認するまで待機する「Ask first(確認モード)」を選択してください。サーバーがまだ見慣れない場合は、「Plan only(計画のみ)」が最初の確認に適しています。
管理しているLinuxサーバー上の共有フォルダ(例:/srv/app)に対して、1つのグループに読み取りと書き込みのアクセス権限を付与する必要があります。GridberryはSSH経由でサーバーに接続し、Shellを使用して現在の所有者、グループ、およびパーミッションを確認します。変更を行う前に、正確なchgrpおよびchmodのコマンドラインを提案し、あなたの承認を待ちます。その後、同じリスト表示で変更後の結果を確認できるため、変更前後を自分で比較できます。順序は重要です:まず確認し、次に変更し、最後に検証します。典型的なケースとしては、デプロイ用フォルダ、共有アップロードフォルダ、または小規模チーム用のプロジェクトフォルダがあります。フォルダが何であれ、同じ手順が適用され、すべてのコマンドは実際の結果を伴うカードとして表示されるため、変更の全体像はチャットで後から読み返すことができます。
Windows 10/11でGridberryを起動し、モデルを接続して、SSHでアクセスできるLinuxサーバーを環境として選択します。各変更があなたを確認するまで待機する「Ask first(確認モード)」を選択してください。サーバーがまだ見慣れない場合は、「Plan only(計画のみ)」が最初の確認に適しています。
エージェントにフォルダの所有者、グループ、およびパーミッションの表示を依頼します。Shellでls -ldが実行され、カードに出力が表示されます。これを変更前に確認してください。このステップでは何も変更されず、情報の純粋な確認となります。
エージェントはグループに対してchgrpを、権限に対してchmodを提案します。各行を読み、承認し、終了コードを確認します。0以外のコードは、変更が行われなかったことを意味します。理解できない行は却下し、エージェントに説明を求めてください。
リスト表示を再度実行し、最初の結果と比較します。その後、そのグループに属するユーザーで、安全なコマンドを1つ実行してテストします。グループメンバーシップは新しいログイン後に適用されるためです。出力を保持してください。これは変更の記録となります。
bash check_access.shexit 0idexit 0getent group appteam1 matchls -ld /srv/appdrwxrwx---#!/usr/bin/env bash
# Read-only access check for a shared folder.
# It changes nothing on the system.
set -eu
DIR=/srv/app
echo "User: $(whoami)"
id
groups
head -n 5 /etc/group
getent group appteam
ls -ld "$DIR"
echo "Check finished"このスクリプトは、現在のユーザー、所属グループ、グループファイルの最初の行、appteamのメンバー、および/srv/appの所有者とグループを表示します。これは情報のみを読み取り、変更を行わないため、変更前後に実行して出力を比較できます。check_access.shとして保存し、変更前後にShellで実行し、両方の出力を保持して比較できるようにしてください。
GridberryはSSH経由でLinuxサーバーに接続し、Shellでターゲットフォルダに対してls -ldを実行します。これにより、変更前に所有者、グループ、およびパーミッションを確認できます。その後、使用する予定のグループに対してgetent groupを実行します。「Ask first(確認モード)」では、変更を行うアクションの前にエージェントが一時停止し、「Plan only(計画のみ)」に切り替えて、実行なしでステップを読むこともできます。新しいユーザーでsudoを有効にする方法は別の問題です:ユーザーをadminグループに追加し、再度ログインしてください。両方のリスト表示の出力を読み、次に進んでください。そのリストを保持してください。これは変更前のフォルダの状態の記録であり、戻りが必要になった場合に比較対象となります。
getent groupが何も表示しない場合、グループはまだ存在しません。エージェントはgroupadd appteamを提案し、正確な行をカードに表示します。別の名前を望む場合は名前を編集でき、実行前にコマンドを承認します。その後、getent group appteamで新しいエントリが表示され、要約を信じるのではなく、自分で出力を確認してください。グループファイル/etc/groupにはすべてのグループがリストされているため、事前に取得したコピーと比較できます。sudoを実行する際、スクリプトがあなたには機能するが管理者には失敗する理由として、ルート環境変数の欠如が挙げられるため、最初のステップはシンプルに保つことをお勧めします。名前が別のグループと既に競合している場合は、再利用するのではなく別の名前を選択してください。既存のユーザーを含むグループにすると、そのユーザーもフォルダにアクセスできるようになるためです。
エージェントはchgrp appteam /srv/appを提案し、フォルダの所有グループをグループに設定します。カード内の行を読み、承認してください。意図していない親フォルダやマウントポイントにコマンドを指定しないでください。期待したパスとは異なるパスを指定するカードは、却下の理由となります。終了コードはカードに表示され、2回目のls -ldで新しいグループ名が確認できます。多くのユーザーは「Linuxでフォルダにグループを追加」で再帰的なコマンドを検索しますが、単一のフォルダの方がレビューが容易なため、そこから始めてください。usermod -aG appteam usernameでメンバーを追加し、変更はユーザーが再度ログインした後に適用されることを忘れないでください。以前のミスでルート所有パスの所有権が変更された場合は、sudo chownのミスから回復するためにバックアップから復元してください。
エージェントは読み取りアクセスに対してchmod g+rx、書き込みアクセスに対してchmod g+rwxを提案し、chmod 777は使用しません。r、w、xはそれぞれ読み取り、書き込み、実行(アクセス)を意味し、gはグループを意味すると説明します。行を承認した後、エージェントは再度ls -ldを実行し、パーミッションを最初のリストと比較します。その後、グループのアカウントの1つで安全なコマンドを1つ実行してテストします。「Linuxでフォルダの権限にユーザーを追加」と検索する単一のユーザーの場合も、同じチェックが適用されます:所有者フィールドではなくグループに追加してください。確認した終了コードを保持してください。両方のカードで成功した終了コードと、一致するls -ldの行は、ステップが正常に完了した証拠となり、次の管理者がチャットでこれを読み返すことができます。