ActiveMQ retorna 503 ao acessar o painel de administração

3

Estou usando o fusemq, o wrapper C para o ActiveMQ-CPP.

O problema é que estou usando o broker com um módulo do servidor Apache. É suposto enviar uma mensagem ao corretor para que outro programa possa consumi-lo. Eu tenho um script que testa tudo isso e eu tenho o login no meu módulo que me diz se a mensagem foi enviada com sucesso. Quando o Apache é iniciado normalmente como root e o ActiveMQ é iniciado como root, meu script fica preso. O traceback diz que ainda estava esperando por uma resposta. Percebi em meus logs que o módulo fica preso ao criar uma sessão padrão com o intermediário. Quando passo pelo módulo no GDB sob essas mesmas circunstâncias, a mensagem é enviada com sucesso e o painel de administração diz que há uma mensagem na minha fila. Quando o módulo é executado, ele faz tudo como o usuário do apache, então eu pensei que era o problema. Então eu inicio o servidor normalmente e executo o ActiveMQ como apache. Quando faço isso, meus logs me dizem que a mensagem é enviada com sucesso, o script é concluído, mas não consigo acessar o painel de administração.

saída de activemq.log do 503:

2013-05-28 13:47:51,823 | WARN  | Committed before 503 null | org.eclipse.jetty.server.Response | qtp1146944158-23
2013-05-28 13:47:51,824 | WARN  | /admin/ | org.eclipse.jetty.server.AbstractHttpConnection | qtp1146944158-23
java.lang.IllegalStateException: Committed
     at org.eclipse.jetty.server.Response.resetBuffer(Response.java:1126)
     at org.eclipse.jetty.server.Response.sendError(Response.java:313)
     at org.eclipse.jetty.server.Response.sendError(Response.java:415)
     at org.eclipse.jetty.server.handler.ContextHandler.checkContext(ContextHandler.java:820)
     at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:916)
     at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
     at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
     at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:521)
     at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
     at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
     at org.eclipse.jetty.server.Server.handle(Server.java:363)
     at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:483)
     at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:920)
     at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:982)
     at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:635)
     at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
     at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
     at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:627)
     at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:51)
     at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
     at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
     at java.lang.Thread.run(Thread.java:722)

Editar: Estou agora executando novamente meu script no servidor enquanto o ActiveMQ está sendo executado como apache e o servidor é root e o script trava. Está ficando preso na criação de uma sessão padrão. Quando eu passo no GDB ainda funciona ...

Edit: Eu corri setenforce 0 e tudo funcionou. Não tenho certeza por que isso seria. Alguma idéia?

Edit: Eu corri ausearch -m avc -ts 30/05/2013 e esta foi a saída -

tempo- > ter Jun 4 08:47:40 2013

type=SYSCALL msg=audit(1370357260.183:29896): arch=c000003e syscall=21 success=no exit=-13 a0=c050b0 a1=7 a2=20 a3=a0 items=0 ppid=2618 pid=2633 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1370357260.183:29896): avc:  denied  { read } for  pid=2633 comm="gdm-session-wor" name="root" dev=dm-0 ino=1835009 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir
    
por thaweatherman 30.05.2013 / 17:01

1 resposta

1

Bem, eu consegui descobrir o problema no caso de alguém que se depara com isso é curioso.

Eu ativei o selinux novamente e adicionei as portas 61616 (porta para conexões openwire), 61613 (porta para conexões stomp) e 8161 (porta para console administrativo) para a lista de permissões para http_port_t.

Eu usei o comando:

semanage port -a -t http_port_t -p tcp [port number]
    
por 04.06.2013 / 17:30