Configurando o xinetd do OpenSuSE

2

Eu preciso executar approx , um proxy de pacote para pacotes Debian / Ubuntu, em uma caixa do OpenSuSE.

Até agora, converti o pacote de instalação de .deb para .rpm usando alien . Instalar o .rpm resultante deu-me o binário approx em /usr/sbin/approx .

No Debian, approx é iniciado usando inetd . O OpenSuSE parece preferir xinetd . Então, na configuração xinetd do YaST2, eu criei uma nova entrada usando

  • nome do serviço: "approx" (também tentei "9999", pois suponho que é onde o mapeamento de nomes de serviço para números de porta ocorre - esse nome deve corresponder à descrição da porta em / etc / services, certo? )
  • tipo: stream
  • protocolo: tcp
  • nowait option
  • usuário: root e
  • serviço: /usr/sbin/approx .

No entanto, não importa o status que atribuo a entrada, a configuração do xinetd pula para "desativada" assim que clico em "OK" e não consigo obter nenhuma reação do sistema ao contatá-la na porta 9999.

Então, a princípio, meu uso da configuração xinetd está correto ou eu entendi algo errado aí?

Segundo, a desativação automática do painel de configuração do xinetd no YaST2 é um software ou erro do usuário?

    
por jstarek 03.12.2011 / 12:39

2 respostas

3

Graças à entrada de Nikhil, resolvi isso.

O YaST usa apenas nomes de serviço, não números de porta, ao configurar o xinetd. Infelizmente, por algumas razões históricas, aproximadamente o padrão é a porta 9999. Isso é registrado em outro serviço, chamado "distinto".

Assim, a solução ad-hoc foi renomear o serviço da porta 9999 para "approx" em / etc / services e inserir um novo serviço na configuração xinetd com o nome "approx" (isso, como eu suspeitava, ser mapeado para a porta 9999), user approx e aprox grupo. Este é o arquivo de serviço gerado pelo YaST:

$ cat /etc/xinetd.d/approx 
service approx
{
    socket_type     = stream
    protocol        = tcp
    wait            = no
    user            = approx
    group           = approx
    server          = /usr/sbin/approx
}

Naturalmente, a solução adequada será migrar o servidor e todas as máquinas cliente para uma porta diferente (uma que ainda não esteja atribuída pela IANA).

    
por 03.12.2011 / 16:00
2

Você já tentou mencionar o número da porta na configuração? O que os logs dizem?

service approx
{
       flags          = REUSE
       socket_type    = stream
       protocol       = tcp
       wait           = no
       user           = root
       server         = /usr/sbin/approx
       log_on_failure += USERID
       disable        = no
       port           = 9999
}
    
por 03.12.2011 / 13:39