web-dev-qa-db-ja.com

ルートとしてuwsgiを実行できません。「bind（）：Permission denied」

私はuWsgiを設定しようとします、Django、このドキュメントでNginx： http://uwsgi-docs.readthedocs.org/en/latest/tutorials/Django_and_nginx.html

uwsgi.iniファイルの構成を完了し、/etc/uwsgi/vassalsでソフトリンクを作成します。

最後のステップで失敗しました：システムの起動時にuWSGIを起動します。

このコマンドを実行すると：

Sudo /usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals --uid www-data --gid www-data

私はこのエラーを受け取りました：

clock source: unix
detected number of CPU cores: 1
current working directory: /etc/uwsgi/vassals
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
your processes number limit is 3813
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
bind(): Permission denied [core/socket.c line 227]
Tue May 27 05:29:26 2014 - [emperor] curse the uwsgi instance uwsgi.ini (pid: 1391)
Tue May 27 05:29:29 2014 - [emperor] removed uwsgi instance uwsgi.ini

Sudoなしでこのコマンドを実行すると、すべて問題ありません。

ユーザー「kk」をグループ「www-data」に追加しました。ここにuwsgi.iniがあります

[uwsgi]
chdir           = /home/kk/XXXXXXX
module          = wsgi
home            = /home/kk/XXXXXXX

master          = true
processes       = 10
socket          = /home/kk/XXXXXXX/mysite.sock
chmod-socket    = 666
vacuum          = true

ファイルの許可を間違えたのかもしれません。誰かが良い考えを持っていますか？ありがとうございます。

更新：

公式文書は正しいです。プロジェクトに従って別の新しいVPSにプロジェクトを展開しますが、エラーは発生していません。

linuxnginxuwsgi
22
Hunger

私はこの問題を抱えていました。グループとユーザーIDを設定せずに実行すると、問題が解決しました。ディレクトリのファイルのアクセス許可を修正する時間があれば、おそらくこれを再検討しますが、今のところは動作します

/usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals

[〜＃〜] edit [〜＃〜]この答えを再検討する時間がありましたが、これはnotuwsgiを運用環境で実行する場合の適切なプラクティス。

書かれているチュートリアルの問題は、www-dataはユーザーであり、www-dataユーザーおよびグループは、サーバー上で必要なすべてのファイルにアクセスできます。特にソケットファイル。適切な引数をユーザーとグループに置き換えれば、準備完了です（サーバーに大きなセキュリティホールが残らないようにします）。

したがって、正しいコマンド（グループovangleのユーザーovangleであった場合）：

/usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals --uid ovangle --gid ovangle

サーバーを正常に実行するために必要な特定のアクセス許可を持つユーザーを作成することをお勧めしますが、それは読者の演習として残しておきます。

15
ovangle

アクセス許可が機能しない理由はわかりませんが、同じ問題に遭遇しました。

これを修正する簡単な方法の1つは、ソケットを/ tmpに移動することです！ （とにかくソケットを保持するためのかなり合理的な場所です...）

したがって、次のようにuwsgi configを更新するだけです。

socket          = /tmp/mysite.sock

およびnginx-configで：

upstream Django {
    server unix:///tmp/mysite.sock;
}

動作し始めます！

10
Norling

パーミッションを逆方向に実行しました。

uwsgiはwww-dataとして実行されています。

ソケットはkkのホームに直接あり、おそらくkkユーザーとkkグループが所有しています。

Kkがwww-dataが所有するすべてにアクセスできるようにしました。www-dataはkkが所有するものにアクセスできません。

Www-dataをkkのグループに追加します。これにより、www-dataはkkの自宅のソケットに到達できます。

usermod www-data -aG kk

groups www-dataで確認すると、www-dataがkkのプライマリグループにあることを示すwww-data : www-data kkが返されます。

現在、kkのホームフォルダーのアクセス許可には、グループアクセス許可に対して少なくとも '6'が必要です。www-dataは必要に応じてソケットを読み書きできます。例えば。 chmod 660 /home/kk/XXXXXXX/mysite.sock。

3
Joenarr Bronarsson

これが、ソケットを安全に起動する方法です。 virtualenvで実行していますか？ envにはSudoがないので、アプリでvirtualenvにアクセスしたときに同じエラーメッセージが表示されました。 uwsgiをグローバルにインストールするには、virtualenvをdeactivateする必要がありました。 uWSGIをインストールした後、Sudo apt-get install uwsgi-plugin-python3、「plugins = python3」をuWSGI iniファイルに追加します。その後、Sudo/root eqを使用してuWSGIを起動できました。 Sudo uwsgi --ini mysite.ini。

セキュリティに関しては、iniファイルに次の行を追加することをお勧めします。

uid = www-data
gid = www-data
chmod-socket = 644

# Plus here's the plugin I mentioned
plugins = python3

これらを尊重するには、www-dataがmysite.sockファイルが作成される親ディレクトリを所有している必要があり、uwsgiコマンドをSudoで起動する必要があります。これらのオプションのいずれかがオフの場合、ソケットはuwsgiコマンドを実行したユーザーとして作成されます。

1
Josh White

このエラーもありました。フォルダーの所有者とグループが間違っていることが判明しました。内部のファイルは正しかったので、しばらくはつかめませんでした。

0
Spence Wetjen

まったく同じ問題に遭遇しました。ソケットファイルに対する十分なアクセス許可を持つユーザーとグループで実行して問題を解決した後、これがおそらくバグであることに気付きました。

Sudoが追加されるとbind(): Permission deniedエラーが発生するのに対し、現在のユーザーで_uwsgi --emperor /etc/uwsgi/vassals --uid www-data --gid www-data_を使用して実際に実行できる場合、非常に混乱します。

これについての唯一の説明は、Sudoなしで実行した場合、何らかの理由で_--uid www-data --gid www-data_部分が動作しない場合で、十分な権限を持つ現在のユーザーで実際に実行します。 Sudoが追加されると、_--uid www-data --gid www-data_部分が再び魔法のように機能し、ソケットファイルをバインドするための十分な権限がない_www-data_になります。

0
Shane

古い質問を復活させるようなものですが、私はこの問題に遭遇しました。

私は解決策を見つけました。以前は、ルートとして何かをテストするためにuwsgiを実行していました。後で、www-dataとして実行してみました。最終的に私は、統計サーバーが/tmp/name.stats.sockにソケットファイルを作成し、これがrootによって所有されているため、uwsgiがクラッシュすることを理解しました。私はちょうどそれを削除し、今すぐ動作します！

これが誰かがつまずくのに役立つことを願っています。

0
clurect

UNIXソケットの代わりに（デモの最初の部分のような）Webポートソケットを使用しても問題ない場合は、これを変更できます。

# uwsgi.ini
socket = :8001

この..

# mysite_nginx.conf
upstream Django {
    # server unix:///home/teewuane/uwsgi-tutorial/mysite/mysite.sock; # for a file socket
    server 127.0.0.1:8001; # for a web port socket (we'll use this first)
}

許可の問題を回避できます。

0
teewuane

あなたが尋ねる問題の原因は、uwsgiがunixソケットファイルを作成して、設定したディレクトリのfastCGIプロトコルを介してWebサーバーとやり取りしようとしていることです/ home/kk/XXXXXXX /書き込み権限を設定する必要がありますuwsgiをディレクトリから実行するユーザーの場合/ home/kk/XXXXXXX /

0
Cmyker