Skip to end of metadata
Go to start of metadata

Manual de uso do núcleo do OPENBUS 2.1.0

Tecgraf

24. Janeiro 2017


Sumário

1 Introdução

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

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 [8,13] 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 [5]) e o segundo é útil para autenticação em servidores OpenLDAP (que utilizam DN [6,7]). 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 [4,3] (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).

-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 [11]. Caso já esteja familiarizado com a versão 2.0.x da ferramenta, consulte também [10].

6 Configurações opcionais para administradores do servidor

No pacote de instalação do barramento existem scripts que auxiliam algumas tarefas diárias comuns ao administrador da máquina onde o barramento está instalado. Esses scripts estão localizados na pasta bin e são eles:

businit
script de inicialização para iniciar e parar o barramento, semelhante aos scripts do /etc/init.d em servidores Unix.
buscheck
script que verifica se o barramento está executando e, caso não esteja, inicia o barramento utilizando o script businit.

6.1 Inicialização

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.2 Monitoramento

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 precisa ser alterado para indicar o local de instalação do barramento(variável INSTALL_DIR). Também como o script businit, o script buscheck também carrega configurações do arquivo /etc/default/openbus, ou do arquivo config/openbus.rc do diretório de instalação do barramento.

Como o script depende do script businit, caso o administrador decida colocar o businit em um local particular, é 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-2.0:

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

6.3 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.3.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-2.0:

  0 12 * * * /usr/sbin/logrotate --state /opt/openbus-2.0/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
Renato Maia.
OiL: An object request broker in the Lua language.
http://www.tecgraf.puc-rio.br/~maia/oil/, 2005.

4
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.

5
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.

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

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

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

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

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

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

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

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



  • No labels