25

サーバー上のWebサイトを管理するためにgitを使用しています。

以下に示すローカルリポジトリがあります

local@workstation:myapp$ ls -l | awk '{k=0;for(i=0;i<=8;i++)k+=((substr($1,i+2,1)~/[rwx]/)*2^(8-i));if(k)printf("%0o ",k);print}'
total 16
755 drwxr-xr-x@ 18 thomas  staff   612 Jun 13 15:35 application
755 drwxr-xr-x@ 11 thomas  staff   374 Jun 12 16:25 assets
644 -rw-r--r--@  1 thomas  staff  6399 Jun 22 11:45 index.php
755 drwxr-xr-x@ 10 thomas  staff   340 May 14 15:22 system

post-receiveサーバー上に、apacheの前にリポジトリを指定するために使用するベアリポジトリがあります。Apacheのpublicフォルダの内容は以下のとおりです-ベアリポジトリではありません。

root@server:/srv/public/myapp# ls -l | awk '{k=0;for(i=0;i<=8;i++)k+=((substr($1,i+2,1)~/[rwx]/)*2^(8-i));if(k)printf("%0o ",k);print}'
total 20
700 drwx------ 15 root root 4096 Jun 27 11:31 application
700 drwx------ 10 root root 4096 Jun 27 11:31 assets
600 -rw-------  1 root root 6399 Jun 27 11:31 index.php
700 drwx------  8 root root 4096 Jun 27 11:31 system

これにより、Webサーバー上のコードに混乱が生じています。

どうすればこれを修正できますか？違いがあれば、私はギトライトを使用しています。

gitサーバー設定ファイル

[core]
        repositoryformatversion = 0
        filemode = true
        bare = true
4

2 に答える 2

35

このスレッド投稿は非常に良い説明を提供します：

これは仕様によるものです。gitデータ構造は技術的にunixモードビットをツリーに格納できますが、gitの歴史の早い段階で、単純な実行可能ビット以外のものを尊重することは、gitの通常の使用例（つまり、コードやその他の共有を格納する人々）にとってより厄介になることがわかりました。リポジトリ内のファイル）。

ファイルモードを尊重するためにconfigオプションを追加することもできますが、一般的には価値がないと見なされてきました。所有者とグループの名前またはID、およびACLなどの拡張メタデータが省略されるため、一般的なメタデータの問題の一部のみが解決されます。

モードが重要な場合、推奨される修正は次のいずれかです。

  1. gitフックから呼び出すことができる「metastore」のようなツールを使用して、リポジトリで追跡されるファイルにファイルのパーミッションを保存および復元します。このようなツールを使用する場合、ファイルの保護に競合状態が発生することに注意してください（つまり、gitはファイルを644として作成し、metastoreはそれを600に修正します。その間に、誰かがファイルを読み取る可能性があります）。

  2. 保存する内容によっては、リポジトリを別のディレクトリに保持し、権限で保護してから、別のツールを使用して、リポジトリから最終的な場所にファイルをデプロイすることが理にかなっている場合があります（Makefileやその他のインストールなど）。道具）。

于 2012-06-27T17:16:23.873 に答える
1

gitを介してデプロイするときに権限を変更する問題の解決策として機能する@ThomasReggiのコメントを拡張するために、実装したソリューションを残します。フック/受信後ファイル（または使用しているフック）にコマンドを追加できます

gitコマンドの行の前に--work-tree=（デプロイを実行する行）いくつかの「エコー」と現在のumaskの表示を追加します。これは、デプロイを正しく実行するために必要なumaskの設定であり、変更を確認するための現在のumask。（このようにして、デプロイを実行するときに表示（デバッグ）できます）

echo "Ref $ ref received. Deploying $ {BRANCH} branch to production ..."
# SHOW current uMask
echo "Current uMASK:"
umask
echo "Set uMASK to 0022"
umask 0022
echo "New uMASK seted to ..."
umask
echo "end umask conf"

# deploy
HUB_VERBOSE = 1
git --work-tree = $ TARGET --git-dir = $ GIT_DIR checkout -f

このように、umaskは現在のセッションでのみ変更され、残りのssh接続には影響しません。また、ファイルは、展開後にコマンドを使用して必要なアクセス許可を再設定する代わりに、作成/変更から必要なアクセス許可を使用して展開され、適切なアクセス許可の適用にかかる時間中にアプリケーションが失敗します。

パーミッションの問題がphpアプリケーションに影響を与える場合、正しく実行するにはそれぞれ異なるパーミッション設定が必要なため、この問題はphp（DSO、suPHP、suEXEC）の実行方法に関係しているようです。サーバーから移行した場合、またはphpハンドラーを変更した場合、この問題が発生するのは問題です。

于 2020-09-14T19:18:42.130 に答える