Skip to end of metadata
Go to start of metadata

Manual de uso do núcleo do OPENBUS 2.1.0

Tecgraf

15. Fevereiro 2018


Sumário

1 Introdução

Este documento visa informar apenas o procedimento necessário para instalar um barramento OPENBUS [11] da versão 2.1.0. Caso tenha interesse em entender melhor o que é um barramento OPENBUS, consulte o documento de visão geral [14].

2 Instalação

O primeiro passo para instalar o barramento deve ser descompactar o pacote do barramento da plataforma desejada. Os pacotes estão disponibilizados no site oficial do projeto: http://www.tecgraf.puc-rio.br/openbus.

As plataformas oficialmente suportadas são:

  • Linux Kernel 2.6 glibc 2.5 64 bits (Linux26g4_64)
  • Linux Kernel 2.6 glibc 2.5 32 bits (Linux26g4)

Para outras plataformas geramos pacotes sob demanda, exemplos:

  • Linux Kernel 3.2 glibc 2.11 64 bits (Linux32_64)
  • Linux Kernel 3.2 glibc 2.11 32 bits (Linux32)
  • Linux Kernel 2.4 glibc 2.3 64 bits (Linux24g3_64)
  • Linux Kernel 2.4 glibc 2.3 32 bits (Linux24g3)
  • Solaris 10 release 8/07 SPARC 64 bits (SunOS510_64)
  • Solaris 10 release 8/07 SPARC 32 bits (SunOS510)
  • Windows

Os exemplos deste documento utilizam comandos do Bash shell (interpretador de linguagem de comandos) [1]. Para executar o barramento deve-se seguir o seguinte procedimento:

  1. Extrair o pacote. Para fins de legibilidade, vamos guardar o caminho do local da extração em uma variável de ambiente. Porém, essa declaração não é obrigatória!
      
    export OPENBUS_HOME=<local de extracao do pacote>
    

  2. Testar se a execução do binário do barramento está funcionando
      
    $OPENBUS_HOME/bin/busservices --help
    

  3. Gerar um par de chaves com tamanho de 2048 bits para o barramento. A chave privada (arquivo com terminação .key) deve ser do formato PKCS8 codificada em DER, e o certificado (arquivo com terminação .crt) deve ser do formato X.509 codificado em DER. Esse par de chaves deve ser criado utilizando o comando openssl na versão 1.0.0 ou maior.
      # Para gerar a chave privada, utilize os seguintes comandos:
      openssl genrsa -out tmp_openssl.key 2048
    
      openssl pkcs8 -topk8 -nocrypt \
        -in tmp_openssl.key -out <nome do par de chaves>.key -outform DER
    
      rm -f tmp_openssl.key
    
      # Para gerar o certificado:
      openssl req -days <validade do certificado em dias> -new -x509 \
        -key <nome do par de chaves>.key -keyform DER \
        -out <nome do par de chaves>.crt -outform DER
    

  4. Configurar os validadores (ver próxima seção) e executar o barramento (binário busservices), passando as configurações da chave privada e dos validadores a serem utilizados, as quais são obrigatórias para a execução do OpenBus.

3 Validadores

3.1 Para que servem?

Os validadores representam o conceito de um módulo Lua [2] responsável por verificar se o par usuário e senha fornecido em uma tentativa de autenticação junto ao barramento é válido. Atualmente pode-se utilizar 2 tipos de validadores no OpenBus: validadores de senha e validadores de autenticação externa.

  • Validadores de senha - utilizam funções escritas em Lua para verificar a autenticidade dos usuários.
  • Validadores de autenticação externa - utilizam funções escritas em Lua que utilizam serviços externos para validar uma entidade a partir de um token.


3.2 Validadores de senha

Um validador de senha precisa ser um módulo Lua [2] que deve retornar uma função que recebe como parâmetro uma tabela de configurações do barramento e retorna uma função validator. A função validator recebe como primeiro parâmetro o nome de usuário e, como segundo, a senha. Caso o par usuário/senha seja válido, deve-se retornar verdadeiro, caso contrário, falso. Um exemplo de validador que verifica se o nome do usuário é igual à senha é dado a seguir:

-- this is the validator function
local function validator(name, password)
  if name == password then
    return true
  end
end

-- returning the factory to validation function
return function(configs) return validator end

Então, sempre que este módulo for carregado, ele retornará a fábrica de função de validação.

-- dummy usage example of this validation module
local factory = require "example.of.validator"
local validator = factory() 
local isValid = validator(login, password)

Podemos implementar os validadores tão simples ou seguros como desejarmos. É importante frisar que o validador personalizado precisa estar no LUA_PATH para que seja encontrado pelo executável busservices. Um exemplo de como configurar o LUA_PATH para um validador personalizado é apresentado no FAQ (seção 7).


3.2.1 Validador LDAP

Junto ao pacote do OPENBUS é fornecido um validador pré-definido para validação via LDAP. Esse validador usa as informações contidas em um serviço de diretórios LDAP para autenticar o acesso de usuários ao barramento. Em ambientes corporativos, é comum a administração da rede utilizar servidores LDAP [10,15] para a autenticação de usuários.

Disponibilizado em openbus.core.services.passwordvalidator.LDAP, tem suporte a servidores Microsoft Active Directory e OpenLDAP. As configurações do validador precisam estar no arquivo de configuração que é informado ao busservices através do parâmetro -configs. A seguir apresentamos quais são as propriedades, seus significados e possíveis valores:

ldap_servers
indica uma lista de URLs de servidores LDAP. Cada URL deve seguir o formato
<protocol>://<server>:<port>, onde <protocol> pode ser ldaps ou ldap. Exemplo:
ldap_servers = { 
 "ldaps://server.mycompany.com",
 "ldap://otherserver.mycompany.com:389",
}

ldap_patterns
indica uma lista de padrões de formação de nomes que serão usados na autenticação LDAP. Atualmente só há suporte para o padrão %U, e o validador irá substituir esse padrão pelo nome do usuário fornecido no ato do login. No exemplo abaixo apresentamos dois padrões, o primeiro é útil para autenticação em servidores Microsoft Active Directory (que utilizam UPN [6]) e o segundo é útil para autenticação em servidores OpenLDAP (que utilizam DN [8,9]). Exemplo:
ldap_patterns = {
  "%U@project.mycompany.com",
  "cn=%U,ou=users,ou=groups,dc=company",
}

ldap_timeout
indica um tempo máximo de espera (em segundos) da resposta do servidor LDAP. Exemplo:
ldap_timeout = 10

ldap_cleartext
indica um valor booleano que determina se a comunicação com o servidor LDAP pode ser feita sem encriptação caso o servidor rejeite conexões LDAP+StartTLS ou a URL não começe com ldaps://. Neste caso as senhas podem ser interceptadas por terceiros capazes de observar o tráfego da rede usada para acesso ao servidor LDAP. Por padrão, essa propriedade não é definida fazendo com que as senhas não sejam trafegadas em claro pela rede. Exemplo:
ldap_cleartext = true

ldap_iorpath
indica um caminho de arquivo que será utilizado para armazenar dados temporários usados internamente pelo busservices. Em particular, nesse arquivo é gravado um IOR para acesso a thread de consulta ao serviço LDAP. Por padrão é utilizado um arquivo temporário indicado pelo sistema. Exemplo:
ldap_iorpath = "/tmp/openbus/ldapthread.ior"


3.3 Validadores de autenticação externa

Um validador de autenticação externa é implementado de forma similar a um validador de senha, descrito na seção 3.2. Contudo, a função validator do validador de autenticação externa recebe os seguintes parâmetros:

  • Uma string contendo o identificador de login.
  • Uma string contendo o nome da entidade
  • Uma string contendo o token a ser validado.
  • Um objeto a ser usado para construção da cadeia. Esse objeto apresenta o método push que recebe como parâmetro um nome de entidade a ser adicionado na cadeia. O método devolve como valor de retorno o login ID que essa entidade assume na cadeia sendo criada.
O validador deve utilizar algum serviço externo para validar o token recebido e retornar verdadeiro ou falso de acordo com o sucesso ou falha da operação.


4 O executável busservices

O barramento e os serviços núcleo são distribuídos em um mesmo programa, o busservices. Logo, para disparar o barramento, basta executar o programa passando as suas configurações por linha de comando ou por arquivo de configuração. Se uma configuração não for explicitada, será utilizado o seu valor padrão.

As opções de configuração são:

-iorfile
Arquivo onde o IOR do barramento deve ser escrito.
-host
Endereço de rede usado pelo barramento.
Valor padrão é *, que significa que vai ouvir em todos os IPs da máquina.
-port
Número da porta usada pelo barramento.
Valor padrão é 2089.

-sslmode
Ativa o suporte SSL através das opções supported ou required.
-sslport
Número da porta segura a ser usada pelo barramento.
-sslcapath
Diretório com certificados de CAs a serem usados na autenticação SSL.
-sslcafile
Arquivo com certificados de CAs a serem usados na autenticação SSL.
-sslcert
Arquivo com o certificado do barramento.
-sslkey
Arquivo com a chave privada do barramento.

-database
Arquivo de dados do barramento.
Valor padrão é openbus.db.
-privatekey
Arquivo com chave privada do barramento.
Valor padrão é openbus.key.
-certificate
Arquivo de certificado com chave pública do barramento.
Valor padrão é openbus.crt.

-timeout
Tempo em segundos de espera por respostas nas chamadas realizadas pelo barramento.
Valor padrão é 0 segundos, o que significa que deve esperar indefinidamente.
-leasetime
Tempo em segundos de lease dos logins de acesso.
Valor padrão é 1800 segundos.
-expirationgap
Tempo em segundos que os logins ficam válidos após o lease.
Valor padrão é 10 segundos.
-challengetime
Tempo em segundos de duração do desafio de autenticação por certificado.
Valor padrão é o valor do parâmetro expirationgap.
-sharedauthtime
Tempo em segundos de validade dos segredos de autenticação compartilhada.
Valor padrão é o valor do parâmetro leasetime

-badpasswordpenalty
Tempo em segundos com tentativas de login limitadas após falha de senha.
Após uma falha de autenticação, este é o período em que o número de falhas de autenticação por senha (ver badpasswordtries) provenientes de um mesmo IP ou entidade será limitado.
O valor padrão é 180 segundos.

-badpasswordtries
Número máximo de tentativas durante o período de badpasswordpenalty.
Número máximo de falhas de autenticação por senha de um IP ou entidade.
O valor padrão é 3 tentativas.

-badpasswordlimit
Número máximo de autenticações simultâneas com senha incorreta repassadas para os validadores de senha, ou seja, que ocorram dentro de um tempo curto (menor que 1/badpasswordrate segundos).
Por padrão, o controle de fluxo está desativado.

-badpasswordrate
Frequência máxima de autenticações com senha incorreta repassadas para os validadores de senha em períodos longos (maiores que 2*badpasswordlimit/badpasswordrate segundos).
Por padrão, o controle de fluxo está desativado.

-maxchannels
Número máximo de canais de comunicação com os sistemas.
Por padrão, nenhum limite é imposto ao número de canais mantidos abertos com os sistemas clientes.
-maxcachesize
Tamanho máximo das caches LRU de profiles IOR, sessões de entrada e de saída.
O valor padrão é 128 (mesmo valor do campo maxsize da classe loop.collection.LRUCache).

-admin
Usuário com privilégio de administração.
-validator
Define um validador de senha no formato: <domain>:<package> onde <domain> é um nome do domínio de autenticação do validador e <package> é o nome do pacote Lua que implementa o validador de senhas.
A parte <domain>: é opcional. Caso seja omitida, o domínio adotado para o validador é a string vazia.
-tokenvalidator
Define um validador de autenticação externa no formato: <domain>:<package> onde <domain> é um nome do domínio de autenticação do validador e <package> é o nome do pacote Lua que implementa o validador de autenticação externa.
A parte <domain>: é opcional. Caso seja omitida, o domínio adotado para o validador é a string vazia.

-loglevel
Nível de log gerado pelo barramento.
O valor padrão é 3. Os níveis vão de 0 a 5, onde 5 é o nível com mais detalhes, e o 0 desativa o log.
-logfile
Arquivo de log gerado pelo barramento.
Por padrão o log é direcionado para a saída padrão (standard output).
-oilloglevel
Nível de log gerado pelo OIL [5,4] (debug).
O valor padrão é 0, que desativa o log.
-oillogfile
Arquivo de log gerado pelo OIL (debug).
Por padrão o log é direcionado para a saída padrão (standard output).

-noauthorizations
Desativa o suporte à autorizações de oferta.
-logaddress
Exibe o endereço IP do requisitante no log do barramento.
-nolegacy
Desativa o suporte à versão antiga do barramento.
-legacydomain
Define o domínio de autenticação de senhas para acessos com a versão antiga do barramento.
Caso o suporte à versão antiga do barramento esteja desabilitado essa configuração não precisa ser fornecida. O valor padrão é a string vazia.

-nodnslookup
Desativa a busca no DNS por apelidos da máquina para compor os endereços de rede contidos nas referências IOR.
Por padrão, todos os apelidos de DNS são adicionados.
-noipaddress
Desativa o uso de endereços IP para compor os endereços de rede contidos nas referências IOR.
Por padrão, os endereços IP são adicionados.
-alternateaddr
Endereço e porta alternativos que devem compor os endereços de rede contidos nas referências IOR.
Essa configuração é útil para a travessia de NAT e firewalls.
Não é definido um valor padrão. O valor deve ser um nome e porta separados pelo caractere : (dois pontos).

-enableaudit
Ativa a publicação de dados de auditoria em serviço HTTP externo.
Por padrão, a auditoria está desabilitada.
-auditendpoint
Endereço e porta do serviço HTTP da auditoria.
O valor padrão é http://localhost:8080.
-auditproxy
Endereço e porta para o servidor de proxy HTTP.
O valor padrão é vazio e as conexões HTTP são realizadas diretamente.
-auditcredentials
Credenciais para autenticação pelo método básico do HTTP.
O valor padrão é vazio e não são enviados cabeçalhos de autenticação.
-auditparallel
Número máximo de corotinas simultâneas para o envio de dados de auditoria.
O valor padrão é 5. Cada corotina vai utilizar um socket comunicação HTTP.
É importante verificar que a soma desse número com a valor para maxchannels não ultrapasse o limite de sockets por processo.
-auditretrytimeout
Tempo em segundos para espera entre tentativas de conexão no serviço de auditoria.
O tempo padrão é 5 segundos.
-auditdiscardonexit
Ativa o descarte de dados de auditoria pendentes durante a parada do agente de auditoria.
Por padrão, o descarte está desativado. Assim serão feitas 10 retentativas de envio dos dados antes da parada completa do agente.
-auditfifolimit
Tamanho máximo da fila de envio de dados para o serviço de auditoria.
O tamanho padrão da fila é 100000.
-auditapplication
Identificação do código da solução no serviço de auditoria.
O valor padrão é OPENBUS.
-auditenvironment
Identificação da instância do barramento no serviço de auditoria.
O valor padrão é o BusId (criado automaticamente na primeira vez que se executa o busservices).

-nativecharset
Identificação do codepage dos caracteres usada quando um sistema solicita a conversão automática.
O valor padrão em CORBA é ISO-8859-1. Entretanto, recomenda-se usar UTF-8 que é o mais usado nos sistemas operacionais modernos.

-configs
Arquivo de configurações adicionais do barramento.
O valor padrão é openbus.cfg.

As opções admin, validator, tokenvalidator e alternateaddr podem aparecer mais de uma vez para definir multiplos valores. (ao contrário do OpenBus 2.0, isso também é válido para definições no arquivo de configuração.) O código 1 apresenta um exemplo de arquivo do configuração.

src/openbus.cfgExemplo de arquivo de configuração: Existem duas formas de se definir o arquivo de configuração que o programa irá utilizar: utilizando a opção config por linha de comando, ou definindo um valor para a variável de ambiente OPENBUS_CONFIG. Quando a variável de ambiente OPENBUS_CONFIG não é definida, o arquivo openbus.cfg no diretório corrente é usado por default como arquivo de configuração. Porém, as opções passadas por linha de comando têm prioridade sobre as opções definidas no arquivo de configuração.

Através da opção validator informa-se o módulo do validador de senhas que será utilizado pelo barramento. Disponibilizamos em openbus.core.services.passwordvalidator.LDAP um validador LDAP, que precisa ser configurado com a lista de servidores utilizados na autenticação. Para maiores informações sobre como configurar o validador LDAP, consulte a seção 3.2.1.

Através da opção tokenvalidator pode-se informar o módulo de um validador de autenticação externa que será utilizado pelo barramento.

Também é possível desabilitar o suporte de compatibilidade com a versão anterior através da opção nolegacy. Ao ativar essa opção, o barramento deixa de permitir que entidades se autentiquem no barramento utilizando as bibliotecas de acesso de versão 2.0.x.

5 O executável busadmin

A ferramenta busadmin facilita a gerentes do barramento a realização de atividades de governança (administração) sobre o barramento. Para informações sobre como utilizá-la, consulte [13]. Caso já esteja familiarizado com a versão 2.0.x da ferramenta, consulte também [12].

6 Configurações opcionais para administradores do servidor

No pacote do barramento existem facilitadores adicionais para apoiar tarefas diárias comuns ao administrador do servidor como auditoria das chamadas recebidas no barramento, inicialização no boot do servidor, monitoramento periódico do processo e rotacionamento de logs.

6.1 Auditoria

A partir da versão 2.1.0.2, o executável busservices passou a ter uma opção (-enableaudit) para coletar dados das chamadas recebidas e enviá-los para um serviço HTTP RESTful externo. O envio é realizado por um cliente HTTP embutido no processo do busservices e conhecido como agente de auditoria. O agente de auditoria envia um POST HTTP com a informação de cada requisição coletada em formato JSON[3], conforme a seguinte estrutura:

{
  solutionCode : "string",
  environment : "string",
  id : "string",
  timestamp : "yyyy-mm-dd hh:mm:ss.SSS"
  actionName : "string",
  userName : "string",
  loginId : "string",
  interfaceName : "string",
  openbusProtocol : "string",
  ipOrigin : "WWW.XXX.YYY.ZZZ:PPPP",
  input : "string",
  duration : "ss.SSSS",
  output : "string",
  resultCode : "string",
}

Os dados coletados na auditoria são detalhados a seguir. Caso não seja possível coletar algum deles, o dado será preenchido com null (ou <unknown> no caso da entidade e login).

solutionCode
String com código da solução que gerou evento.
O valor padrão é OPENBUS e pode ser redefinido pelo parâmetro auditapplication do busservices.
environment
String com o nome do ambiente que a solução executa.
O valor padrão é o mesmo do BusID (gerado automaticamente) e pode ser redefinido pelo parâmetro auditenvironment do busservices.
id
String com identificação única do evento.
Valor gerado automaticamente. Exemplo: d3b0fbdb138f4bfca689d30b23e1fa38.
actionName
String com nome da ação.
Valor preenchido com o campo request.operation_name da requisição CORBA. Exemplo: findServices.
interfaceName
: String que contém o tipo do serviço em uso.
Valor do campo request.interface.repID da requisição CORBA. Exemplo: IDL:tecgraf/openbus/core/v2_1/services/offer_registry/OfferRegistry:1.0.
timestamp
String de data em que a requisição foi interceptada.
Valor da chamada de sistema gettimeofday no ato do recebimento da requisição. Exemplo: 2017-09-06 09:05:37.022.
userName
String com o nome da entidade que fez a solicitação.
Valor preenchido com o CallChain.caller.entity contido no request.service_context da requisição CORBA. Exemplo: fulano.
loginId
String que contém o UUID do login da entidade que fez a solicitação.
Valor preenchido com o CallChain.caller.id contido no request.service_context da requisição CORBA. Exemplo: fbedb4ba-9ce4-11e7-a153-0050569e00fc.
openbusProtocol
String com a versão do protocolo do OpenBus sendo utilizada na requisição.
Valor é extraído da versão dos metadados do protocolo ou do nome das interfaces (quando ainda não é uma chamada do protocolo) ou ainda do request.object_key do objeto sendo acessado. Exemplo: v2_0, v2_1.
ipOrigin
String que contém o endereço de rede (IPv4) do processo cliente que fez a requisição.
Valor do campo request.channel_address da requisição CORBA. Exemplo: 10.29.234.53:44000.
input
String codificada em Base64 com os parâmetros de entrada da operação.
Valor preenchido com campo request.parameters da requisição CORBA.
resultCode
Booleano com o resultado da operação: verdadeiro caso finalizou com sucesso e falso caso ocorreu uma exceção.
Valor do campo request.success da requisição CORBA.
output
String codificada em Base64 com a resposta da requisição.
Valor do campo request.results da requisição CORBA.
duration
Duração da chamada em milisegundos com precisão de 4 dígitos.
Valor observado no ato da resposta da requisição. Exemplo: 5,2314 (5 milisegundos e 231,4 microsegundos).

Entre os campos acima, apenas environment e solutionCode podem ser alterados através da configuração dos parâmetros -auditapplication e -auditenvironment do busservices, respectivamente.

Recomenda-se usar o -auditapplication como um identificador da tecnologia, por exemplo OPENBUS, e o -auditenvironment como um identificador da instalação.

O serviço de auditoria, por sua vez, não é fornecido no pacote do barramento. Um exemplo de código baseado em Node.JS[7] que executa uma aplicação web para efeitos de teste da auditoria é dado a seguir. Este exemplo utiliza o endereço http://localhost:8080 para publicar eventos sem autenticação e http://localhost:8080/protected para experimentar uso de autenticação HTTP (será necessário usar os parâmetros -auditendpoint e -auditcredentials no busservices).

const express = require('express')
const app = express()

var basicAuth = require('basic-auth');

var auth = function (req, res, next) {
  function unauthorized(res) {
    res.set('WWW-Authenticate', 'Basic realm=Authorization Required');
    return res.sendStatus(401);
  };

  var user = basicAuth(req);

  if (!user || !user.name || !user.pass) {
    console.log(req.url + " access denied. missing authentication header");
    return unauthorized(res);
  };

  if (user.name === 'fulano' && user.pass === 'silva') {
    console.log(req.url + " access granted for user " + user.name);
    return next();
  } else {
    console.log(req.url + " access denied. invalid user credentials user " + user.name);
    return unauthorized(res);
  };
};

var bodyParser = require("body-parser");
app.use(bodyParser.urlencoded({extended:false}));
app.use(bodyParser.json());

const port = 8080

app.post('/protected', auth, (req, res) => {
  console.log('Received a protected event ' + req.url)
  console.log(req.body);
  res.end('');
})

app.post('/', (req, res) => {
  console.log('Received a public event ' + req.url)
  console.log(req.body);
  res.end('')
})

app.listen(port, () => console.log('Audit service app listening on port '+port))

6.2 Inicialização

O pacote de instalação do barramento acompanha o script de inicialização businit que serve para iniciar e parar o barramento, semelhante aos scripts do /etc/init.d em servidores Unix.

Recomendamos que o administrador coloque o script businit em /etc/init.d/openbus (ou outro lugar semelhante em seu sistema operacional) e faça o link simbólico apropriado para cada runlevel. É possível editar o script businit para redefinir o local da instalação do barramento (variável INSTALL_DIR), de modo que o script possa encontrar o executável do busservices. Alternativamente, é possível também definir a variável de ambiente OPENBUS_HOME para indicar o local de instalação do barramento para os scripts businit e buscheck (veja a seção seguinte).

Além disso, por padrão, este script carrega configurações adicionais definidas no arquivo /etc/default/openbus, ou ainda no arquivo config/openbus.rc do diretório de instalação do barramento. Num desses arquivos podem ser definidas configurações adicionais tais como o nome do arquivo a ser criado para armazenar o PID do processo do busservices disparado (variável PIDFILE), o arquivo de log do barramento (variável OUTFILE), ou ainda o mail de notificação de reinícios (variável EMAIL).

É fortemente recomendado que o administrador do sistema configure o barramento para utilizar um arquivo de configuração. Nesse caso, o administrador precisa decidir onde colocar esse arquivo de configuração. Há duas formas de fazer isso utilizando os arquivos /etc/default/openbus ou config/openbus.rc:

  1. Definindo a variável de ambiente OPENBUS_CONFIG. Exemplo:
       export OPENBUS_CONFIG=/etc/openbus.cfg
    
  2. Definindo a variável PARAMS com o parâmetro -configs e a localização do arquivo de configuração desejado. Exemplo:
       PARAMS=-configs /etc/openbus.cfg
    

6.3 Monitoramento

O pacote de instalação do barramento acompanha o script de monitoramento buscheck que verifica se o barramento está executando e, caso não esteja, inicia o barramento utilizando o script businit.

O script buscheck foi criado para ser utilizado em conjunto com o agendador de tarefas do sistema (comando cron no Unix). Assim como o script businit, o script buscheck também:

  1. Precisa ser alterado para indicar o local de instalação do barramento(variável INSTALL_DIR).
  2. Carregará as configurações do arquivo /etc/default/openbus, ou do arquivo config/openbus.rc do diretório de instalação do barramento.

Como o script buscheck depende do script businit, caso o administrador decida colocar o businit em um outro local, é importante editar o script buscheck de acordo (variável OPENBUS_INIT).

Um exemplo de agendamento no cron para utilizar o buscheck é dado a seguir, neste exemplo consideramos que o barramento está instalado em /opt/openbus:

*/10 * * * * env OPENBUS_HOME=/opt/openbus /opt/openbus/bin/buscheck

6.4 Rotacionamento de logs

O script businit desvia toda saída do barramento para um arquivo (veja variável OUTFILE no arquivo de configurações adicionais). É fortemente recomendado manter esses arquivos de saída para identificar problemas no uso do barramento. Por isso, recomendamos uma estratégia para rotacionar esses arquivos de saída.

O comando logrotate é um utilitário para simplificar a administração de arquivos de logs bem comum na maioria das instalações Linux e Solaris. O logrotate permite a rotação automática, a compressão dos logs antigos, a remoção de logs muito velhos e mesmo o envio de emails contendo os arquivos de logs.

Para rotacionar os logs do barramento, basta configurar o logrotate com as linhas a seguir. Neste exemplo consideramos que o barramento salva o log em /var/log/openbus.log:

   /var/log/openbus.log {
    weekly
    compress
    copytruncate
    rotate 4
   }

Os significados das opções recomendadas acima são dados a seguir:

  1. O rotacionamento dos logs ocorre semanalmente.
  2. Os logs antigos são comprimidos.
  3. A opção copytruncate é necessária, pois o barramento escreve continuamente no log e ocorrerá erro de escrita em disco, caso os descritores de arquivos sejam alterados. Essa opção copia os arquivos de logs e, depois, reseta o arquivo original. É o procedimento mais seguro nesses casos.
  4. Armazena-se até 4 volumes dos logs antigos.

6.4.1 Rotacionamento de logs usando o logadm (plataforma Solaris)

O logadm é muito parecido com o logrotate. Para a rotação dos logs, nós iremos utilizar o crontab e o logadm. Caso não seja o root da máquina, você deve utilizar o parâmetro -f para informar um arquivo de configuração. Esse arquivo irá conter todos os logs que você deseja rotacionar. Abaixo temos um exemplo de como configurar o logadmin para rotacionar os logs do barramento.

  • O agendamento do cron que faz o logadm ser executado todo dia às 5:00AM:
       00 05 * * * /usr/sbin/logadm -f /etc/openbus-logadm.conf
    
  • No arquivo /etc/openbus-logadm.conf temos:
       /var/log/openbus.log -C 5 -P 'Mon Jul 26 20:13:01 2010' -c -p 7d -z 0
    

Os significados das opções recomendadas acima são dados a seguir:

  1. Os parâmetros -C 5 -c -p 7d -z 0 fazem com que o logadm guarde os 5 últimos logs, truncando-os e comprimindo-os no formato .gz. Essa ação será feita a cada 7 dias.
  2. O parâmetro -P será adicionado pelo próprio logadm após a primeira execução, ele é responsável por controlar a próxima data que o rotacionamento ocorrerá.


7 FAQ

7.1 Não lembro a sintaxe do crontab. Qual é ela mesmo?

   
.---------------- minuto (0 - 59)
|  .------------- hora (0 - 23)
|  |  .---------- dia do mês (1 - 31)
|  |  |  .------- mês (1 - 12) 
|  |  |  |  .---- dia da semana (0 - 6) (Domingo=0 ou 7) 
|  |  |  |  |
*  *  *  *  *  comando a ser executado e suas opções

7.2 Não lembro como editar o agendamento do cron. Como é mesmo?

Para adicionar um novo agendamento pode-se usar o arquivo global /etc/crontab (caso seja root) ou editar a tabela específica do usuário (todo usuário pode usar o cronpara rodar tarefas periódicas). O comando é:

crontab -e

Um arquivo com os agendamentos já existentes será aberto e será possível adicionar conforme informado anteriormente. Se o arquivo está vazio é porque o usuário do sistema não tem nenhum agendamento ainda.

7.3 Onde devo salvar o arquivo de configuração do logrotate?

A maioria das instalações Linux recentes já dispõem do diretório /etc/logrotate.d. Nesses casos, basta criar um arquivo chamado openbus (pode ser outro nome de sua preferência) e salvar as configurações acima nele.

É importante que o administrador leia as páginas de manual do logrotate (man logrotate), pois podem haver diferenças na configuração para versões antigas desse utilitário. Uma das situações comuns é não haver suporte ao diretório /etc/logrotate.d. Nesses casos, basta adicionar as configurações acima no arquivo /etc/logrotate.conf.

7.4 Precisa ser configurada alguma permissão especial? Qual o owner e o grupo que a configuração do logrotate precisa ter?

Não é necessário nenhuma permissão especial, basta o proprietário ser root e ter leitura para qualquer usuário (pode haver plataformas onde o logrotate execute como outro usuário que não o root).

7.5 Onde os arquivos rotacionados são armazenados?

No mesmo diretório dos arquivos originais.

7.6 Preciso executar o comando logrotate /etc/logrotate.d/openbus?

Não é preciso. Normalmente o logrotate é cadastrado como uma tarefa diária no cron. Mas isso não impede de que o administrador execute tal comando passando o parâmetro force para obrigar o primeiro rotacionamento. Isso é indicado principalmente logo após a configuração inicial.

7.7 Preciso configurar para o comando logrotate /etc/logrotate.d/openbus ser colocado na inicialização automática da máquina? Como saber que ele está executando?

O logrotate não é um daemon, portanto não se mantém em execução. Normalmente, o logrotate é executado através do agendamento do cron. Caso não haja cron disponível em uma dada plataforma, então nesse caso será sim importante executar o comando do logrotate na inicialização da máquina.

7.8 Como usar o logrotate SEM precisar ter acesso de administrador na máquina?

O logrotate pode ser usado por usuários desprivilegiados (aqueles que não possuem acesso de root). Contudo, é muito comum que esses usuários ainda queiram rotacionar periodicamente seus arquivos de log. Nessa situação, recomendamos que o usuário adicione regras no agendador de tarefas do Unix (cron) para que o comando do logrotate seja chamado (ao menos) diariamente.

Para usuários desprivilegiados é importante usar alguns parâmetros do logrotate como o state. Esse parâmetro indica qual arquivo de estados será usado. O logrotate usa tal arquivo de estado para registrar a data da última rotação.

Segue um exemplo de agendamento do cron para executar o logrotate diariamente às 12:00 horas para o barramento instalado em /opt/openbus:

  0 12 * * * /usr/sbin/logrotate --state /opt/openbus/logrotate.status /etc/openbus-logrotate.conf

É importante notar que o arquivo logrotate.status contendo o último estado da rotação foi mantido no diretório da instalação do barramento.

7.9 Como instalar o logrotate como usuário comum numa Solaris 10?

Nas plataformas Solaris a forma mais simples é baixar o pacote binário a partir do SunFreeware e usar diretamente da pasta do usuário. Um exemplo é dado a seguir:

  1. Download e extração do pacote a partir do sunfreeware:
       wget -c ftp://ftp.sunfreeware.com/pub/freeware/sparc/10/logrotate-3.7.6-sol10-sparc-local.gz
       gunzip logrotate-3.7.6-sol10-sparc-local.gz
       mkdir /tmp/install
       pkgtrans logrotate-3.7.6-sol10-sparc-local /tmp/install
    
  2. Entendendo o conteúdo do pacote e copiando para uma pasta pessoal o binário principal:
       ls -l /tmp/install/SMClogr/reloc/
         drwxr-xr-x   3 openbus  tecgraf      512 Apr 12 15:24 doc
         drwxr-xr-x   3 openbus  tecgraf      512 Apr 12 15:24 man
         drwxr-xr-x   2 openbus  tecgraf      512 Apr 12 15:24 sbin
       cp /tmp/install/SMClogr/reloc/sbin/logrotate $HOME/bin
    

Após esse procedimento basta ter a pasta $HOME/bin no PATH.

7.10 Como configuro um validador de senha?

Um exemplo simples de configuração de um validador de senha seria criar um código como o apresentado em 3.2, e salvar o código em um arquivo com a extensão .lua. Depois, adicione o caminho onde foi salvo o arquivo à variável de ambiente LUA_PATH, da seguinte forma:

export LUA_PATH+=";<caminho onde está o validador>/?.lua"

Para maiores informações, consulte o manual da linguagem Lua [2].

7.11 Ainda estou com dúvidas. Como entro em contato?

Disponibilizamos uma lista pública de discussão com o intuito de reconhecer os usuários da nossa tecnologia, bem como receber sugestões e críticas que contribuam para a evolução do nosso projeto.

Maiores informações sobre a nossa lista de discussão veja http://listas.tecgraf.puc-rio.br/mailman/listinfo/openbus-users.

Referências Bibliográficas

1
GNU.
Bash reference manual.
http://www.gnu.org/software/bash/manual/bashref.html, 2010.

2
Roberto Ierusalimschy.
The programming language lua - modules.
http://www.lua.org/manual/5.1/#5.3, February 2008.

3
The JSON Data Interchange Format.
Technical Report Standard ECMA-404 1st Edition / October 2013, ECMA, October 2013.

4
Renato Maia.
OiL: An object request broker in the Lua language.
http://www.tecgraf.puc-rio.br/~maia/oil/, 2005.

5
Renato Maia, Renato Cerqueira, and Ricardo Calheiros.
OiL: An object request broker in the Lua language.
In Mauro S. P. Fonseca, editor, Proceedings of SBRC'06 - Salão de Ferramentas, pages 1439-1446, Porto Alegre, Brazil, June 2006. SBC.

6
Microsoft.
UPN user principal name attribute in microsoft active directory.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680857(v=vs.85).aspx, 2012.

7
Node.js Foundation.
Node.js official site, 2018.

8
OpenLDAP Foundation.
DN distinguished name in ldap.
http://www.openldap.org/doc/admin24/intro.html#What

9
OpenLDAP Foundation.
RFC 4514 - lightweight directory access protocol (ldap): String representation of distinguished names.
http://www.ietf.org/rfc/rfc4514.txt, 2012.

10
OpenLDAP Foundation.
RFC 4510 - lightweight directory access protocol (ldap): Technical specification road map.
http://www.ietf.org/rfc/rfc4510.txt, 2013.

11
TecGraf.
OpenBus - Enterprise Integration Application Middleware.
http://www.tecgraf.puc-rio.br/openbus, 2006.

12
TecGraf.
Guia do busadmin 2.1 para usuários do 2.0.
https://jira.tecgraf.puc-rio.br/confluence/x/YoIHB, 2015.

13
TecGraf.
Manual do busadmin 2.1.0.
https://jira.tecgraf.puc-rio.br/confluence/x/UoEHB, 2015.

14
TecGraf.
Overview do openbus 2.1.0.
https://jira.tecgraf.puc-rio.br/confluence/x/UoEHB, 2015.

15
Wikipedia.
Lightweight directory access protocol -- Wikipedia, the free encyclopedia, 2012.
[Online; accessed 06-March-2012].



  • No labels