5 votos

La operación no permitida cuando a partir de Unicornio

He creado un nginx/unicornio/capistrato el programa de instalación en Ubuntu (Amazon EC2) siguiendo en su mayoría esta guía. Supongo que todo está configurado como debería, pero cuando empiezo Unicornio puedo conseguir (un MUCHO) de este error en el log:

E, [2012-09-08T08:57:20.658092 #12356] ERROR -- : Operation not permitted (Errno::EPERM)
/home/deployer/apps/bridgekalenderen.no/shared/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn/worker.rb:82:in `initgroups'

Veo que está relacionado con los permisos del usuario, pero no puedo averiguar lo que he dejado fuera. El servidor arranca muy bien si empiezo con sudo (o, rvmsudo, la verdad).

El usuario ha sudo capacidades, he chmod ed la aplicación varias veces para que los permisos del archivo no debe aceptar. El unicornio socket en /tmp es propiedad de la implementador de usuario, por lo que no debería ser el problema.

¿Alguien tiene una idea de por dónde buscar?

ACTUALIZACIÓN:

Después de algo de investigación descubrí que todo se reduce a una llamada a Process.initgroups que arroja EPERM. He comprobado esto en el irb. No puedo entender qué es lo que causa el error. El usuario puede leer /etc/group.

4voto

Khaled Puntos 21517

Si le he entendido bien, usted está tratando de iniciar un servicio sin sudo bajo condiciones normales de usuario. Esto no va a funcionar y va a dar a sus errores como los que recibieron la Operación no permitida. Esto es cierto en la mayoría (si no todos) de los casos ya que cualquier servicio que se requieren uno o más de los siguientes para hacer su trabajo:

  1. Enlace/escuchando en los puertos < 1024.
  2. Leer archivo(s) no se puede leer por los que no son root.
  3. Al escribir el archivo(s) no de escritura por los que no son root.
  4. y posiblemente más (no puedo recordar).

2voto

pablox Puntos 185

Finalmente lo entendí. El problema era que el implementador de grupo primario del usuario que estaba equivocado. Debería ser 'personal', pero fue 'despliegue' en su lugar. Esto significa que el unicornio intenta mano sobre la propiedad de los nuevos procesos de trabajo para el grupo que se supone que debe utilizar, pero sólo root puede hacer eso.

Sólo en caso de que alguien más necesita saber, he cambiado el grupo principal por la edición de /etc/passwd como este:

deployer:x:1002:50:,,,:/home/deployer:/bin/bash

'50" es el gid de 'personal'. Fue 1002, para empezar. Para obtener el gid del 'staff' del grupo, hacer:

cat /etc/group | grep staff

Que va a decir algo que a lo largo de las líneas de:

staff:x:50:<comma separated list of users in this group>

El gid es el número después de "x".

0voto

trans1t Puntos 1

Me he encontrado con el mismo problema. Lo que terminó trabajando para mí fue la configuración de la siguiente en mi unicornio config en la after_fork do |server, worker| bloque de: (es de github unicornio config)

  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

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: