Операция, не разрешенная при запуске Единорога
Если Вы хотите не пустить людей затем, брандмауэр Windows очень хорошо (возможно, Вам даже не нужно это, если Вы находитесь позади брандмауэра/маршрутизатора NAT'ing).
То, где Zonealarm или другие продукты брандмауэра вступают, должно дать Вам лучшую видимость и управление тем, что устанавливает связи, в особенности исходящие соединения.
Как Bart указывает, вниз, сторона - то, что Вы можете быть засыпаны, "Делают Вы хотите позволить xyz.exe получать доступ к Интернету", и это может сбивать с толку технического человека, уже не говоря о ком-то, кто просто хочет бродить по сети в мире и безопасности.
Я наконец понял это. Проблема заключалась в том, что основная группа пользователя развертывателя была неправильной. Это должно быть «штат», но вместо «развертывающий». Это означает, что единорог пытается передать права собственности на новые рабочие процессы группе, которую он должен использовать, но это может сделать только root.
На всякий случай, если кому-то еще нужно знать, Я изменил основную группу, отредактировав / etc / passwd следующим образом:
deployer:x:1002:50:,,,:/home/deployer:/bin/bash
«50» - это gid для «Staff». Начнем с 1002 года. Чтобы получить gid группы «staff», выполните:
cat /etc/group | grep staff
Он скажет что-то вроде:
staff:x:50:<comma separated list of users in this group>
gid - это число после «x».
Если я вас хорошо понимаю, вы пытаетесь запустить службу без sudo под обычным пользователем. Это не сработает и приведет к появлению ошибок, подобных тем, которые вы получили Операция запрещена . Это верно в большинстве (если не во всех) случаях, потому что любая служба потребует одно или несколько из следующих действий для выполнения своей работы:
- Привязка / прослушивание портов <1024.
- Чтение файла (ов) не может быть прочитано другими пользователями. -root.
- Запись файлов, которые не могут быть записаны пользователем без полномочий root.
- и, возможно, больше (я не могу вспомнить).
Я столкнулся с той же проблемой. Что в итоге сработало для меня, так это установка следующего в моей конфигурации единорога в блоке after_fork do | server, worker | : (это из конфигурации github unicorn)
begin
uid, gid = Process.euid, Process.egid
user, group = 'deployer', 'staff'
target_uid = Etc.getpwnam(user).uid
target_gid = Etc.getgrnam(group).gid
worker.tmp.chown(target_uid, target_gid)
if uid != target_uid || gid != target_gid
Process.initgroups(user, target_gid)
Process::GID.change_privilege(target_gid)
Process::UID.change_privilege(target_uid)
end
rescue => e
if RAILS_ENV == 'development'
STDERR.puts "couldn't change user, oh well"
else
raise e
end
end
Я недавно потерял из-за этого один человеческий день. Контекст пытался запустить Unicorn для пользователя с именем apps, и ошибка Errno :: EPERM продолжала нас кусать. Вот трассировка стека:
E, [2018-04-12T20:45:07.277588 #2048] ERROR -- : Operation not permitted (Errno::EPERM)
/apps/cas-seas3/shared/bundle/ruby/2.2.0/gems/unicorn-5.4.0/lib/unicorn/worker.rb:143:in `initgroups'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/gems/unicorn-5.4.0/lib/unicorn/worker.rb:143:in `user'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/gems/unicorn-5.4.0/lib/unicorn/http_server.rb:657:in `init_worker_process'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/gems/unicorn-5.4.0/lib/unicorn/http_server.rb:682:in `worker_loop'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/gems/unicorn-5.4.0/lib/unicorn/http_server.rb:549:in `spawn_missing_workers'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/gems/unicorn-5.4.0/lib/unicorn/http_server.rb:563:in `maintain_worker_count'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/gems/unicorn-5.4.0/lib/unicorn/http_server.rb:293:in `join'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/gems/unicorn-5.4.0/bin/unicorn:126:in `<top (required)>'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/bin/unicorn:23:in `load'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/bin/unicorn:23:in `<top (required)>'
Инструментирование базы кода с помощью оператора печати в строке 143 дало нам следующую отладочную информацию:
user = apps
group=apps
uid=1040
gid=110
whoami=apps
Process.egid = 1001
Это несоответствие между gid и Process.egid вызвало срабатывание этого блока кода:
if gid && Process.egid != gid
Process.initgroups(user, gid)
Process::GID.change_privilege(gid)
end
и это вызвало
Я наконец проследил это до разницы между GID / EGID, и проблема заключалась в том, что пользователь приложения принадлежал к другой основной группе (admin). Когда я переместил пользователя приложений в группу приложений в качестве основной, это сработало. Это было сделано путем редактирования файла / etc / passwd, который определял учетные записи пользователей ящика.
Другой способ проверить это - использовать sg для ручного запуска единорога с правильной группой с помощью команды sg, например:
bundle exec sg apps -c unicorn -c /apps/cas-seas3/current/config/unicorn.rb -E deployment -D
Если вы обнаружите, что это работает, тогда это очень хороший знак для просмотра настроек вашего пользователя / группы.
Unicorn, похоже, очень чувствителен к настройкам пользователя / группы, чтобы проверить / etc / passwd и / etc / group, а также использовать этот ps строка, чтобы проверить разницу в выполняющемся процессе Unicorn на предмет различий в UID и GID:
ps -eo uid,gid,egid,args | grep unicorn
Примечание: хук unicorn after выше не работал у меня. Кроме этого, ничего не работало.