Kleyson Rios

Template addIn - tableComponent

noreply@blogger.com (Kleyson Rios) — Mon, 18 Jul 2016 05:39:00 -0300

Introdução

O template addIn faz parte do conjunto de addIn’s existentes para serem utilizados no tableComponent. Este é um addIn relativamente simples mas que trás uma grande flexibilidade para customizar as colunas de uma tabela, podendo alterar seu conteúdo baseado em um template html e um modelo de dados, ou até mesmo criar botões/checkbox’s/etc com eventos associados.

Referência

Template addIn Source Code

Valores default

Em geral todo addIn possui valores default que podem serem alterados para mudar seu comportamento, ou seja, customizar o comportamento do addIn de acordo com a necessidade de cada projeto.

Uma forma de saber quais são os valores default que podem serem alterados, é abrir do código fonte do addIn e olhar para a seguinte parte do código:


defaults: {
  templateType: 'mustache',
  template: '<div>{{items}}</div>',
  rootElement: 'items',
  formatters: [],
  events: [],
  modelHandler: function(st, opt) {
    var model = {};
    model[opt.rootElement] = $.parseJSON(st.value);
    return model;
  },
  postProcess: function(info) {}
}

Para o nosso caso, os parâmetros acima são exatamente aqueles que podemos alterar e utilizar.

Vamos passar por cada um deles para entender qual o seu papel dentro de todo o processo.

Entendendo e alterando os valores default

templateType

Permite informar qual o tipo de template html que será utilizado. As opções possíveis de template são ‘mustache’ e ‘underscore’.

template

É o template html de acordo com o templateType escolhido. Qualquer código html aqui descrito será inserido dentro da célula que está sendo processada e os tokens (ou expressões) definidos no template serão substituídos pelos dados existentes no modelo.

rootElement

Este é o nome que será utilizado como a raiz do seu modelo de dados.

formatters

Um formatter permite formatar o valor de uma expressão para ser exibida. Essa ‘formatação’ pode ser na forma de exibição, como transformar todas as letras para maiúscula, como passar um valor adicional para ser multiplicado com o valor da expressão.

Formatters podem ser concatenados usando um ‘|’. O atributo formatters espera um array composto de array’s de dois elementos, como:


formatters: [
  [ ‘formatter_name’, function(str, id) {} ],
  [ ‘uppercase’, function(str, id) {} ],
  [ ‘calcPercent’, function(str, id) {} ]
]

formatter_name: um nome que representa o que a função faz.
function(str, id): função que irá realizar o trabalho duro. O primeiro parâmetro da função é o valor da expressão ao qual você pediu para aplicar o formatter. O segundo parâmetro é um valor adicional que você possa e vir a precisar dentro da sua função. O retorno da sua função deverá ser o novo valor que deseja exibir.

Para usar o formatter no seu template, basta aplicá-lo na expressão que deseja. Considere o seguinte template :


<div>
  <div>
    <span>
      Name: {{name | formatter : "uppercase"}}
    </span>
  </div>
  <div>
    <span>
      Percent: {{value | formatter : “calcPercent” : 100}} %
    </span>
  </div>
</div>

Então, o formatter de nome ‘uppercase’ deve receber no parâmetro ‘str’ o valor de ‘name’ e retornar este em letra maiúscula.

E o formatter de nome ‘calcPercent’ deve receber no parâmetro ‘str’ o valor de ‘value’ e no parâmetro ‘id’ o número 100, e retornar uma conta que provavelmente será ‘str’ * ‘id’.

events

É um array composto de array's de dois elementos, onde você pode configurar diferentes tipos de eventos e indicar qual elemento do template esses eventos devem ser registrados. Veja:


events: [
  [ ‘event,selector’, function(e) {} ]
]

event,selector: é o nome do evento e um seletor, separado por uma vírgula, com o seletor indicando onde deve ser feito o bind dentro do template para o respectivo evento. O ‘seletor’ é opcional e se não for informado, o bind será aplicado no <td> da célula.

function(e): é a respectiva função do evento. Como parâmetro é passado dados do evento e dentro do ‘e.data’ você tem informações adicionais relacionadas ao seus dados.

Como exemplo, imagine o seguinte template:


<div>
  <div>
    <span>
      Name: {{name | formatter : "uppercase"}}
    </span>
  </div>
  <div>
    <span>
      Percent: {{value | formatter : “calcPercent” : 100}} %
    </span>
  </div>
  <button id=‘btnDelete’>Delete!</button>
</div>

E a seguinte configuração do evento:


events: [
  [ 'click,#btnDelete’, function(e) { 
      $(this).closest('tr').remove(); 
    }
  ]  
]

O exemplo acima irá registrar um evento de click no botão e que permitirá remover a respectiva linha.

modelHandler

modelHandler é uma função onde você deverá criar o modelo de dados apropriado para o template html que foi definido.

Essa função recebe dois parâmetros:

st: informações sobre os seus dados.
opt: as opções passadas para o addIn, que basicamente são os valores default com suas alterações. Isso é importante pois você pode definir uma nova função dentro do default e utilizá-la dentro do modelHandler.

Considerando nosso template acima, vamos considerar que a coluna onde estou aplicando o template tenha dados no seguinte formato : ‘Paulo/0.75’

A função abaixo cria um modelo de dados para o template definido com base no formato da string acima.


modelHandler: function(st, opt) {
  var model = {};
  var _values = st.value.split('/');
  
  var ret = {};
  ret.name = _values[0];

  ret.value = _values[1];

  return model[opt.rootElement] = ret;
}

A função acima irá retornar o seguinte objeto:


{
  items:{
    name: ‘Paulo’,
    value: 0.75
  }
}

Repare que o ‘root’ do objeto deve ser o nome definido no ‘rootElement’;

postProcess

Caso tenha a necessidade de fazer algum processamento após a execução do addIn, use o postProcess para definir sua função.

A função possui apenas um parâmetro, que recebe um objeto contendo os mesmo valores recebidos pelo addIn no início da sua execução.


info = {target: tgt, status: st, options: opt}

Utilizando o addIn

Como qualquer addIn para o tableComponent, basta definir o nome ‘template’ na propriedade ‘Column Type’ para a coluna onde o mesmo será aplicado.

Configure no preExecution do tableComponent o addIn para alterar qualquer um dos valores default, como mostrado no exemplo abaixo:


function f(){

  this.setAddInOptions("colType","template",function(state){

    return {
      events: [
        [ 'click,#btnDelete’, function(e) {
            $(this).closest('tr').remove(); 
          }
        ]
      ],
      formatters: [
        [ ‘uppercase’, function(str, id) {} ],
        [ ‘calcPercent’, function(str, id) {} ]
      ],
      template: '<div><div><span>Name: {{name | formatter : "uppercase"}}</span></div><div><span>Percent: {{value | formatter : “calcPercent” : 100}} %</span></div><button id=“btnDelete”>Delete!</button></div>',
      modelHandler: function(st, opt) {
        var model = {};
        var _values = st.value.split('/');

        var ret = {};
        
        ret.value = _values[0];
        ret.expected = _values[1];

        return model[opt.rootElement] = ret;
      },
      postProcess: function(info) {}
    };
  });
}

Exemplo

Veja o vídeo abaixo:

FreeNAS + VirtualBox

noreply@blogger.com (Kleyson Rios) — Tue, 31 May 2016 18:28:00 -0300

Introdução

Coisas que geralmente me incomodam tendem a sumir quando minha paciência com elas se esgotam. E uma das coisas que sempre me incomodou é o fato de precisar reinstalar meu notebook de trabalho, ou porque comprei um novo, ou porque resolvi trocar o HD por um maior/melhor ou porque alguma merda mesmo aconteceu e o mesmo precisou ser reinstalado.

Alguém pode dizer, basta criar uma partição de dados e colocar tudo lá. OK, é uma alternativa, mas e se quiser trocar o SO, quiser restaurar seu notebook para o padrão de fábrica, o particionamento que você achou que era o ideal não é mais, ou seja, uma das partições já está cheia e você vê a outra nadando em espaço livre até que você decide mexer nas partições e correr o risco de perder tudo.

Esse blog post visa documentar uma outra estratégia, não sei se é melhor, mais simples ou mais segura, mas é a abordagem que estarei seguindo a partir de agora para testar, e só o futuro me dirá se foi uma aposta acertada ou não.

Estratégia

Estarei usando duas tecnologias para essa nova abordagem: VirtualBox e FreeNAS.

A ideia básica é criar um servidor "NAS local" rodando em uma máquina virtual. O servidor NAS será criado utilizando o FreeNAS.

Uma vez que eu tenha um servidor NAS disponível, meu notebook estará montando os pontos de montagem disponível no NAS via NFS ou CIFS. Como isso, todos meus arquivos, programas, workspaces de trabalho, etc estarão armazenados nesse servidor NAS.

E eu posso regularmente fazer uma cópia de backup dos arquivos .vdi, sem me preocupar se estou esquecendo de copiar alguma coisa ou não.

Então, se um dia eu precisar reinstalar meu notebook ou mudar tudo que tenho para um novo, sem falar da segurança do backup de apenas um arquivo, basta eu instalar o VirtualBox na nova máquina, criar um novo servidor virtual utilizando os arquivos .vdi do NAS e refazer os pontos de montagem.

E a performance de acesso aos arquivos ? Para meu caso, como estarei rodando o NAS como uma máquina virtual no próprio notebook, e não terei o delay de uma rede no meio, acredito não ter muitos problemas de performance. Exceto é claro, se você não tiver memória RAM suficiente para tudo isso.

FreeNAS

FreeNAS é um sistema operacional que pode ser instalado em praticamente qualquer plataforma de hardware para compartilhar dados através de uma rede. FreeNAS é a maneira mais simples de criar um local centralizado e de fácil acesso para seus dados.

Não vou entrar em detalhes sobre conceitos, instalação e configuração, pois está cheio de tutoriais sobre isso por ai. Estarei mostrando apenas os passos realizados para alcançarmos nosso objetivo.

A documentação do FreeNAS recomenda 8G de memória RAM para os volumes do tipo ZFS, mas pelo o que tive lendo é necessário mais memória a medida que começa a usar recursos mais sofisticados do ZFS. Como quero apenas um repositório simples de dados, sem o uso de features que exigem muito do hardware, estarei criando uma máquina virtual com apenas 512M de RAM e 1 processador. Pode ser muito baixo em relação ao que a documentação sugere, mas como não tenho parâmetros de comparação, vou deixar um valor baixo e vou aumentando caso eu perceba problemas de performance.

A máquina virtual será criada com dois discos virtuais, sendo um disco para o sistema operacional do FreeNAS e um outro para efetivamente funcionar como minha área de storage.

Veja a instalação do FreeNAS no vídeo abaixo:

Criando mount points

Uma vez que tenhamos tudo instalado, temos que configurá-lo para termos disponíveis no sistema host os mount points pré-definidos no FreeNAS.

O vídeo abaixo mostra a configuração e teste de dois mount points configurados para serem montados via NFS.

Expandindo a área de storage

A capacidade de um disco pode aumentar sem qualquer mudança aos dados já existentes. Isto acontece de forma mais comum com máquinas virtual, quando um disco virtual se torna pequeno e precisa ser aumentado.

Para aumentarmos nossa área de storage, poderíamos criar um novo disco virtual, adicionar a máquina e então criar um novo volume com novos mount points.

Especialista em ZFS poderiam nos listar diversas formas de expandir nosso volume ZFS, bem com seus dataset. Mas a forma que estarei mostrando, visa aumentar o disco virtual (.vdi) existente e o espaço adicional ser usado para criar uma nova partição que será adicionada ao ZFS pool.

Os passos abaixo listam os procedimentos necessários para expandir nossa área de storage:

1. Pare a máquina virtual do FreeNAS

2. Faça um cópia do arquivo .vdi que irá alterar

3. Aumente o tamanho do arquivo .vdi

VBoxManage modifyhd FreeNAS_data.vdi --resize 100000

4. Inicie o FreeNAS em 'User single mode'

5. Verifique os discos disponíveis no S.O. com o comando:

gpart show

6. Em meu caso, o disco ada1 representa o disco de storage, que basicamente tem o tamanho redefinido anteriormente, onde a última sessão do disco está marcada como '- free -'.

Após o resize do arquivo .vdi, se o disco foi formatado como GPT, ele pode aparecer como [CORRUPT] pois um backup da tabela de partição do GPT não se encontra mais no final do disco. Para corrigir o problema execute o comando:

gpart recover ada1

7. Verifique se o disco foi corrigido

gpart show ada1

8. Crie uma nova partição, do tipo freebsd-zfs, com o espaço disponível no disco ada1:

gpart add -t freebsd-zfs ada1

Como output deverá receber:

ada1p3 added

9. Verifique se uma nova partição foi criada

gpart show ada1

10. Restart FreeNAS

reboot

11. Após a inicialização, escolha a opção 9) Shell

12. Liste os ZFS pool's e verifique se existe o volume com o nome dado durante o processo de criação, para nosso caso storage

zpool list

13. Veja mais informações do pool

zpool status storage

Podemos verificar que o pool é composto por apenas um único disco gptid/xxx

14. (Opcional) Para saber qual partição do disco o gptid/xxx se refere use o comando:

glabel status

15. Adicione a nova partição ao pool

zpool add storage ada1p3

16. Confira se o pool agora possui dois discos

zpool status storage

17. Verifique na interface web do FreeNAS se o volume agora tem a quantidade extra de espaço adicionado.

Veja o vídeo abaixo com os procedimentos acima:

Mais+

A medida que novos procedimentos forem sendo realizados estarei colocando eles aqui.

Siga-me no twitter para ficar sabendo das novas atualizações. @kleysonr

Clonando um banco de dados HP Vertica

noreply@blogger.com (Kleyson Rios) — Sun, 8 May 2016 16:05:00 -0300

Introdução

Já precisei algumas vezes clonar uma base de dados Vertica para um outro servidor, para ter uma base idêntica de testes ou por alguma razão ter que refazer o servidor.

Mas sempre foi muito trabalhoso esse processo. Por vezes, é necessário a mesma configuração do servidor anterior, como estrutura de diretórios e/ou mesmo endereço IP. Algumas vezes atender esses requisitos é fácil, mas outras vezes não.

Existe na documentação oficial do Vertica formas de clonar uma base de dados, algumas vezes funcionou pra mim, outras vezes não devido alguma particularidade do meu ambiente.

Basicamente, o que eu gostaria de fazer era copiar os diretórios de dados/catálogo e configuração da máquina antiga para a máquina nova e pronto, subir o Vertica e ir pra casa feliz da vida. A ideia desse post é justamente mostrar como fazer isso, usando uma técnica que não está muito documentada, que é usar o 'Catalog Editor' para alterar configurações que estão armazenadas dentro dos catálogos e não em arquivos externos.

Alterar o catálogo é algo extremamento arriscado, então essa operação é por sua própria conta e risco. A boa notícia é que se estamos alterando em uma nova máquina e alguma besteira for feita isso não irá afetar as outras máquinas em produção, desde que você altere uma cópia do catálogo e não a única cópia que você tenha.

Referências

O procedimento via 'Catalog Editor' descrito nesse blog post foi baseado nos seguintes links:

Pré-Requisitos

Para o exemplo que vamos mostrar, estaremos copiando uma base de dados que está em um servidor com IP válido para uma máquina que rodará o Vertica no IP 127.0.0.1

Então quando fizermos a cópia dos diretórios de dados/catálogo e configuração para a nova máquina, teremos que ajustar todos os path's e endereço IP para refletir a nova configuração.

No meu caso irei manter a mesma estrutura de diretórios do servidor original, irei alterar apenas o endereço IP do qual o Vertica deverá ter que funcionar.

Para verificar a estrutura de diretórios que a base de dados está configurada, execute os seguintes comandos SQL:

\x
select * from nodes;
select node_name,storage_path, storage_usage from disk_storage;

Atenção para o catalog_path e storage_path do node que pretende migrar. Estes deverão serem os locais onde você precisará colocar os diretórios de dados/catálogo novamente na nova máquina.

Para esse tutorial, estou utilizando o HP Vertica 7.0.2. Não fiz o teste em uma versão mais nova, portanto não sei se é 100% compatível.

Procedimentos

1. Tenha uma cópia dos diretórios de dados, catálogo e configuração (/opt/vertica/config) da máquia de origem.

2. Instale a mesma versão do Vertica na máquina destino.

3. Crie na máquina destino um novo database 'dummy'. Esse banco servirá apenas como referência para checar as permissões e owner dos arquivos/diretórios. Na tela 'Database data directories', aponte o 'Catalog pathname' e 'Data pathname' para algum local onde possa depois verificar as permissões e owner.

4. Copie os arquivos da máquina de origem para os mesmos path's na máquina de destino. Faça antes um backup do /opt/vertica/config. Verifique as permissões e owner dos diretórios e arquivos usando o banco de dados dummy como referência, faça os ajustes se necessários. Em seguida use o admintools para remover o banco de dados dummy.

5. Edite o arquivo /opt/vertica/config/admintools.conf e altere todas referências do antigo endereço IP para o novo endereço IP, em nosso caso 127.0.0.1

6. Execute o 'Catalog Editor' com o seguinte comando:

/opt/vertica/bin/vertica -D <CATALOG_PATH> -E'interactive'

Para o meu caso particular o comando foi,

/opt/vertica/bin/vertica -D /var/db/vertica/verticadb/v_verticadb_node0001_catalog -E'interactive'

E você deve receber o seguinte output como resultado,

Catalog Editor v7.0.2-1
Sizes:  3850KB chkpt, 4440KB log (6 files) [READ-WRITE]

>

7. Liste os nodes configurados na respectiva base de dados

> list Site

Como resultado, receberá a lista de todos nodes. Para o meu caso existia apenas 1,

45035996273704980 Site:v_verticadb_node0001

8. Liste as configurações do node que iremos alterar o IP

> show name Site v_verticadb_node0001

Como resultado, receberá as configurações do node,

:Site
oid:45035996273704980
name:v_verticadb_node0001
schema:0
address:10.1.1.1
ei_address:0
catalogPath:/var/db/vertica/verticadb/v_verticadb_node0001_catalog/Catalog
hasCatalog:false
bdbPath:/var/db/vertica/verticadb/v_verticadb_node0001_data/SAL
siteUniqueID:10
isEphemeral:false
isRecoveryClerk:true
parentFaultGroupId:45035996273704974
clientPort:5433
controlAddress:127.0.0.1
controlBroadcast:127.255.255.255
controlPort:4803
controlNode:45035996273704980

Como mantemos os mesmos path's durante a cópia, os path's na configuração devem estar refletindo o path real na nova máquina. Mas o address, que aponta para 10.1.1.1 deverá ser alterado para 127.0.0.1

9. Para alterar a configuração, precisamos fazer 'unlock' no catálogo

> unlock danger

Como resultado, deve receber a seguinte mensagem,

USE AT YOUR OWN RISK!

10. Altere o endereço IP

> set name Site v_verticadb_node0001 address 127.0.0.1

Como resultado, deve receber a seguinte mensagem,

Set to 127.0.0.1

11. Verifique se o endereço IP foi alterado corretamente

> show name Site v_verticadb_node0001

:Site
oid:45035996273704980
name:v_verticadb_node0001
schema:0
address:127.0.0.1
ei_address:0
catalogPath:/var/db/vertica/verticadb/v_verticadb_node0001_catalog/Catalog
hasCatalog:false
bdbPath:/var/db/vertica/verticadb/v_verticadb_node0001_data/SAL
siteUniqueID:10
isEphemeral:false
isRecoveryClerk:true
parentFaultGroupId:45035996273704974
clientPort:5433
controlAddress:127.0.0.1
controlBroadcast:127.255.255.255
controlPort:4803
controlNode:45035996273704980

12. Grave as alterações e saia do editor

> commit
> exit

13. Finalmente, execute o admintools e inicie o banco de dados.

Pronto, nesse ponto já deve ter uma cópia do seu banco de dados rodando em uma outra máquina.

Menu de Navegação usando Dashboard Component

noreply@blogger.com (Kleyson Rios) — Tue, 5 Apr 2016 05:23:00 -0300

Introdução

Dashboard Component é um novo componente existente no CDE quando o mesmo está configurado como RequireJS.

Ele permite carregar um certo dashboard em um dado placeholder (DIV) do layout CDE, como podíamos fazer antigamente com o velho iframe.

O mesmo permite ainda fazer a ligação de parâmetros para a passagem de valores do dashboard pai para o dashboard filho.

Esse post irá mostrar como criar um menu de navegação usando o Dashboard Component disponível no CDE.

Esta abordagem permitirá, entre outros, a criação de um portal ou painel de administração onde os links de um menu, que apontam para diferentes dashboards, sejam carregados em uma área específica do dashboard principal.

Além de termos um dashboard principal que é carregado apenas uma única vez, essa abordagem nos permite também termos filtros, seletores, entre outros componentes CDE compartilhados entre todos dashboards filhos.

Temos ainda a capacidade de passarmos valores do dashboard pai para o dashboard filho e vice-versa.

Sample

Para baixar os arquivos do dashboard sample click aqui.

O sample é composto por 4 dashboards:

main.wcdf

dashboard principal
carrega outros dashboards em uma div específica
possui um seletor compartilhado pelos dashboards filhos

overview.wcdf

página de overview carregada por default pelo dashboard principal

market.wcdf

dashboard para 'análise do mercado'
escuta o seletor do dashboard principal
possui um link para voltar a tela inicial de overview

o link para voltar implementado nesse dashboard é feito pelo o envio de dados do dashboard filho que é escutado pelo dashboard pai que então carrega novamente apenas o dashboard de overview

customer.wcdf

dashboard para 'análise de clientes'
escuta o seletor do dashboard principal
possui um link para voltar a tela inicial do overview

o link para voltar implementado nesse dashboard recarrega por completo o dashboard principal

NOTA: Instale a última versão stable do CTOOLS para garantir que o sample irá funcionar como esperado em modo RequireJS.

Implementação

Os steps abaixo mostram as configurações e a forma mais básica de utilização do DashboardComponent. Para um exemplo mais completo, consulte o exemplo disponível no link acima.

1. Crie um novo dashboard CDE e salve o mesmo.

2. Altere sua configuração para o modo RequireJS.

3. Na aba de Layout, crie uma linha ou coluna que será utilizada pelo componente.

4. Adicione um novo Dashboard Component ao dashboard. O mesmo pode ser encontrado dentro do grupo Custom.

5. Configure-o.

Configurando o componente

Abaixo as principais configurações:

Dashboard Path: é o caminho absoluto, em relação ao root do repositório (PUC -> Browser File), do dashboard (.wcdf) que será inserido pelo componente.

Datasource Mapping: permite sobrescrever o resultado de uma query do dashboard filho pelo resultado de uma query do dashboard pai.

Parameter Mapping:

cria um link entre um parâmetro do dashboard pai com um parâmetro do dashboard filho.
isso significa que alterações no parâmetro do dashboard pai serão também propagadas para o parâmetro correspondente do dashboard filho.
alterações no parâmetro do dashboard filho não serão propagadas para o dashboard pai.
no dashboard filho, o parâmetro deve ter a propriedade 'Public' configurada como 'true' para haver a propagação da alteração.

Disparando alterações no dashboard pai

A configuração do 'Parameter Mapping' permite a passagem de valores em apenas uma única direção, ou seja, do dashboard pai para o dashboard filho.

Por vezes, é necessário que alterações no dashboard filho também possam ser escutadas no dashboard pai para disparar, por exemplo, alguma atualização.

Para conseguirmos essa característica, basta colocarmos o código abaixo no 'Post Execution' do DashboardComponent:

function() {

  var myself = this;
    
  // Listen to fireChange on the child dashboard
  myself.requiredDashboard.on("backParam:fireChange", function(e) {
        
    myself.dashboard.fireChange('dashParam', e.value );
    
  }); 
    
}

No dashboard filho, temos um parâmetro chamado 'backParam', e no dashboard pai temos um parâmetro chamado 'dashParam'.

O código basicamente registra um eventListener no dashboard filho e quando o respectivo evento acontece a função definida é executada recebendo como argumento o 'evento'. Dentro do 'e.value' temos então o valor do 'backParam', que foi alterado pelo dashboard filho, para fazermos o que quisermos com ele dentro do dashboard pai.

Dessa forma conseguimos ter uma comunicação nas duas direções entres os dashboards.

Existe um JIRA (http://jira.pentaho.com/browse/CDE-824) para que a comunicação exista nas duas direções de forma nativa. Vale a pena acompanhar.

Conclusão

O blog post mostrou o funcionamento básico do componente e como configurá-lo.

No exemplo disponível para download, temos dois botões, onde cada um dispara o render de um dashboard diferente. Esses botões poderiam serem substituídos por um menu mais elaborado, localizado no topo ou lateral, permitindo assim a implementação de um dashboard com uma função mais de portal ou painel de navegação.

Vídeo

Confira o dashboard sample no vídeo abaixo.

Configurando Security Logging no Pentaho

noreply@blogger.com (Kleyson Rios) — Thu, 1 Oct 2015 15:33:00 -0300

Background

Quando um processo de autenticação e autorização não está se comportando como você gostaria que estivesse, uma das primeiras ações a se fazer é habilitar o debug para as classes relacionadas a segurança.

Algumas vezes também, preciso liberar o acesso anonymous ou dar alguma permissão especial a algum recurso via spring-security. Para isso você precisa configurar o arquivo applicationContext-spring-security.xml e informar quais URL's dos recursos serão configuradas.

Então, para descobrir quais URL's são necessárias configurar para alcançar seu objetivo é necessário habilitar o log security, que permitirá identificá-las.

Referência

Passos

1. Faça uma cópia do arquivo biserver-ce\tomcat\webapps\pentaho\WEB-INF\classes\log4j.xml

2. Abra o arquivo log4j.xml e remova todos parâmetros Threshold que encontrar nos <appender>
( Como por exemplo, PENTAHOFILE e PENTAHOCONSOLE )

3. Ainda no mesmo arquivo, procure pela tag <root> e adicione ou mude a tag <priority> para:

<root>
 <priority value="WARN,ERROR,FATAL" />
 <appender-ref ref="PENTAHOCONSOLE"/>
 <appender-ref ref="PENTAHOFILE"/>
</root>

4. Procure dentro do mesmo arquivo pelas classes abaixo. Caso elas existam, configura a tag <priority> para DEBUG. Caso não existam, adicione as mesma antes da tag <root>. Elas irão habilitar o log das classes relacionadas a segurança.

<!-- all Spring Security classes will be set to DEBUG -->
<category name="org.springframework.security">
  <priority value="DEBUG" />
</category>

<!-- all Pentaho security-related classes will be set to DEBUG -->
<category name="org.pentaho.platform.engine.security">
  <priority value="DEBUG" />
</category>

<category name="org.pentaho.platform.plugin.services.security">
  <priority value="DEBUG" />
</category>

5. Salve e feche o arquivo log4j.

6. Faça uma cópia e abra o arquivo biserver-ce\pentaho-solutions\system\applicationContext-spring-security-<back-end>.xml onde <back-end> é um dos: memory, jdbc, ldap, jackrabbit (5.x) ou hibernate (4.x). Adicione a propriedade hideUserNotFoundExceptions com o valor false no bean da classe DaoAuthenticationProvider.

<bean class="org.springframework.security.providers.dao.DaoAuthenticationProvider">
   (...)

   <!-- other properties/constructor-args not shown -->
   <property name="hideUserNotFoundExceptions" value="false" />

   (...)
</bean>

7. Salve o arquivo e reinicie o BI Server. Ao iniciar você já começará a ver os logs no console.

Agora é só buscar pela informação que precisa.

Pentaho 5.4 + PostgreSQL

noreply@blogger.com (Kleyson Rios) — Wed, 9 Sep 2015 09:40:00 -0300

Background

Os passos abaixo visam configurar o Pentaho 5.4 para utilizar o Postgres como banco de dados dos metadados.

Existem algumas diferençãs entre a configuração do Pentaho 4.x para a versão 5.x.

Umas das principais mudanças é que o repositório dos arquivos e configurações do Pentaho 5.x agora ficam armazenado em um repositório de conteúdo chamado Jackrabbit, e não mais no filesystem.

Logo, adicionalmente ao que era feito para configurar o Pentaho 4.8, agora será criado também um database para armazenar os dados/metadados do Jackrabbit no PostgreSQL.

Referências

Pentaho Use Manual BA Server Installation

Pentaho BI Server 5.0.1CE MySQL installation guide

How To: Install and configure Pentaho BI Suite 5 CE | Ubuntu 12.04 | PostgreSQL 9.2

Configurações

1. Criar os banco de dados hibernate / quartz / jackrabbit

Execute os script de criação que se encontram na pasta biserver-ce\data\postgresql

2. Workaround para Bug

Crie a tabela abaixo para contornar o bug JIRA BISERVER-11028.

OBS. Deve se garantir que após a criação o nome da tabela esteja em letras MAIÚSCULAS.

CREATE TABLE "QRTZ_DUMMY"
(
  id bigint
);

ALTER TABLE "QRTZ_DUMMY" OWNER TO pentaho_user;

3. tomcat/webapps/pentaho/META-INF/context.xml

<Resource name="jdbc/Hibernate" auth="Container" type="javax.sql.DataSource"
             factory="org.apache.commons.dbcp.BasicDataSourceFactory" maxActive="20" maxIdle="5"
             maxWait="10000" username="hibuser" password="password"
             driverClassName="org.hsqldb.jdbcDriver" url="jdbc:hsqldb:hsql://localhost/hibernate"
             validationQuery="select count(*) from INFORMATION_SCHEMA.SYSTEM_SEQUENCES" />

para

<Resource name="jdbc/Hibernate" auth="Container" type="javax.sql.DataSource"
              factory="org.apache.commons.dbcp.BasicDataSourceFactory" maxActive="20" maxIdle="5"
              maxWait="10000" username="hibuser" password="password"
              driverClassName="org.postgresql.Driver" url="jdbc:postgresql://<IP>:<PORT>/hibernate"
              validationQuery="select 1" />

<Resource name="jdbc/Quartz" auth="Container" type="javax.sql.DataSource"
              factory="org.apache.commons.dbcp.BasicDataSourceFactory" maxActive="20" maxIdle="5"
              maxWait="10000" username="pentaho_user" password="password"
              driverClassName="org.hsqldb.jdbcDriver" url="jdbc:hsqldb:hsql://localhost/quartz"
              validationQuery="select count(*) from INFORMATION_SCHEMA.SYSTEM_SEQUENCES"/>

para

<Resource name="jdbc/Quartz" auth="Container" type="javax.sql.DataSource"
              factory="org.apache.commons.dbcp.BasicDataSourceFactory" maxActive="20" maxIdle="5"
              maxWait="10000" username="pentaho_user" password="password"
              driverClassName="org.postgresql.Driver" url="jdbc:postgresql://<IP>:<PORT>/quartz"
              validationQuery="select 1"/>

4. pentaho-solutions/system/applicationContext-spring-security-hibernate.properties

jdbc.driver=org.hsqldb.jdbcDriver
jdbc.url=jdbc:hsqldb:hsql://localhost:9001/hibernate
jdbc.username=hibuser
jdbc.password=password
hibernate.dialect=org.hibernate.dialect.HSQLDialect

para

jdbc.driver=org.postgresql.Driver
jdbc.url=jdbc:postgresql://<IP>:<PORT>/hibernate
jdbc.username=hibuser
jdbc.password=password
hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect

5. pentaho-solutions/system/hibernate/hibernate-settings.xml

<config-file>system/hibernate/hsql.hibernate.cfg.xml</config-file>

para

<config-file>system/hibernate/postgresql.hibernate.cfg.xml</config-file>

6. pentaho-solutions/system/hibernate/postgresql.hibernate.cfg.xml

(...)
<property name="connection.url">jdbc:postgresql://localhost:5432/hibernate</property>
(...)
<property name="connection.username">hibuser</property>
<property name="connection.password">password</property>

para

(...)
<property name="connection.url">jdbc:postgresql://<IP>:<PORT>/hibernate5</property>
(...)
<property name="connection.username">hibuser</property>
<property name="connection.password">password</property>

7. tomcat/conf/server.xml

Em alguns casos temos problemas que ocorrem devido ao tamanho máximo do HTTP Header. Para isso, iremos aumentar o seu tamanho.

<Connector URIEncoding="UTF-8" port="8080" protocol="HTTP/1.1"
             connectionTimeout="20000"
             redirectPort="8443" />

para

<Connector URIEncoding="UTF-8" port="8080" protocol="HTTP/1.1"
             maxHttpHeaderSize="65536"
             connectionTimeout="20000"
             redirectPort="8443" />

8. pentaho-solutions/system/pentaho.xml

Caso deseje desabilitar a lista de sample users da tela de login.

(...)
<login-show-users-list>true</login-show-users-list>
(...)
<login-show-sample-users-hint>true</login-show-sample-users-hint>
(...)

para

(...)
<login-show-users-list>false</login-show-users-list>
(...)
<login-show-sample-users-hint>false</login-show-sample-users-hint>
(...)

9. tomcat/conf/Catalina/localhost/pentaho.xml

Caso já tenha iniciado o pentaho alguma vez com a configuração original, apague o respectivo arquivo.

Nota: Este é um arquivo de cache do tomcat que não é recriado se o META-INF/context.xml for alterado. Deletar força o arquivo ser recriado novamente com a nova configuração.

10. pentaho-solutions/system/jackrabbit/repository

Apagar todo conteúdo da respectiva pasta.

11. pentaho-solutions/system/jackrabbit/repository.xml

É necessário configurar o JCR para usar o Postgres ao invés do H2.

Edite o respectivo arquivo e busque por configurações relacionado ao Postgres. Você pode fazer um 'Search' por 'org.postgresql.Driver'.

Descomente o respectivo bloco de configuração e faça os ajustes de conexões necessários. Não esqueça de comentar a configuração equivalente que estava ativa por padrão.

Para referência pode se utilizar os respectivos documentos:

Use Manual BA Server Installation

Use PostgreSQL as Your Repository Database

12 . Segurança dos usuários

- Altere a senha do usuário admin.
- Remova ou altere as senhas de todos usuários default.

13. Configuração de Localização PT_BR

Edite os arquivos start-pentaho.sh(.bat), e na opção 'export CATALINA_OPTS' inclua no final da linha:

-Dfile.encoding=utf-8 -Duser.country=BR -Duser.language=pt

14. Configurando tomcat/webapps/pentaho/WEB-INF/web.xml (opcional)

Para remover a mensagem de WARNING abaixo durante a inicialização:

WARNING: Security role name PENTAHO_ADMIN used in an <auth-constraint> without being defined in a <security-role>

Incluir no arquivo, antes da tag <security-constraint> a configuração:

<security-role>
  <description>security role assignment</description>
  <role-name>PENTAHO_ADMIN</role-name>
</security-role>

15. Desativar Hypersonic - tomcat/webapps/pentaho/WEB-INF/web.xml (opcional)

Para desativar o startup automático do Hypersonic, edite o arquivo e comente ou delete as seguintes configurações:

<!-- [BEGIN HSQLDB DATABASES] -->
<context-param>
  <param-name>hsqldb-databases</param-name>
  <param-value>sampledata@../../data/hsqldb/sampledata,hibernate@../../data/hsqldb/hibernate,quartz@../../data/hsqldb/quartz</param-value>
</context-param>
<!-- [END HSQLDB DATABASES] -->

<!-- [BEGIN HSQLDB STARTER] -->
<listener>
  <listener-class>org.pentaho.platform.web.http.context.HsqldbStartupListener</listener-class>
</listener>
<!-- [END HSQLDB STARTER] -->

16. Desativar SGBD H2 - pentaho-solutions/system/pentaho-spring-beans.xml

Como já é sabido, a partir da versão 5.0 a Pentaho optou por utilizar um gerenciador de conteúdos para armazenar o repositório das soluções, contrário às versões anteriores que utilizavam diretamente o sistema de arquivos.

Este gerenciador de conteúdos é o Apache Jackrrabit, que por padrão vem pré configurado na versão CE, utilizando o SGBD H2.

Então uma vez que o JCR seja migrado para o Postgres podemos desatirar o SGBD H2, da mesma forma que fizemos para o hibernate e o quartz que utilizam o SGBD HSQLDB.

Para desativá-lo remova ou comente a linha abaixo do respectivo arquivo:

<import resource="GettingStartedDB-spring.xml" /> <!-- Remove this line to unhook the Getting Started DB -->

HP Vertica ERROR 3149: Duplicate primary/unique key detected in join

noreply@blogger.com (Kleyson Rios) — Tue, 28 Jul 2015 20:37:00 -0300

Hoje fazendo a carga de alguns arquivos para meu DW me deparei com uma mensagem de erro do Vertica dizendo que havia primary keys duplicadas.

Achei muito estranho, então separei os arquivos imaginando que seria algum problema no arquivo que estava sendo carredo e que depois eu voltaria a analisá-los.

Mas quando fui rodar meu dashboard recebi o mesmo em uma das consultas SQL definidas.

Pesquisando vi que o Vertica no momento da carga não verifica as constraints no momento de carga para priorizar a performance, ou seja, você poderia por exemplo incluir dois registros com a mesma primary key.

Mas o erro acontece no momento em que você utiliza esses registros, como por exemplo um JOIN com a tabela que possui uma primary key duplicada.

Simulando o erro

> TABLE public.table1 (id int PRIMARY KEY, val char(1));

> INSERT INTO public.table1 VALUES (1, 'a');

> INSERT INTO public.table1 VALUES (1, 'b');

> CREATE TABLE public.table2 (id int PRIMARY KEY, val char(1));

> INSERT INTO public.table2 VALUES (1, 'c');

> select * from public.table1 a inner join public.table2 b on (a.id = b.id);

ERROR 3149:  Duplicate primary/unique key detected in join [(public.table2 x public.table1) using table2_super and table1_super (PATH ID: 1)]; value [1]

Veja como o Vertica permitiu a inserção de duas primary keys iguais e só reclamou durante um JOIN com a tabela.

Corrigindo o problema

A documentação diz que você deverá executar o comando ANALYZE_CONSTRAINTS nas tabelas para exibir os registros duplicados.

Na nosso exemplo acima, a mensagem de erro já diz o nome de algumas tabelas, então vamos verificá-las.

> SELECT ANALYZE_CONSTRAINTS ('public.table1');

 Schema Name | Table Name | Column Names | Constraint Name | Constraint Type | Column Values 
-------------+------------+--------------+-----------------+-----------------+---------------
 public      | table1     | id           | C_PRIMARY       | PRIMARY         | ('1')

> SELECT ANALYZE_CONSTRAINTS ('public.table2');

 Schema Name | Table Name | Column Names | Constraint Name | Constraint Type | Column Values 
-------------+------------+--------------+-----------------+-----------------+---------------
(0 rows)

Analisando os resultados podemos ver que na table1 existem registros com a primary key de valor 1 duplicada.

E cada registro no Vertica tem uma coluna epoch escondida que representa a data epoch de quando o registro foi carregado/inserido. Se os dois registros foram carregados em momentos diferentes então o epoch pode ser usado como um identificador único para deletar um registro e manter o outro. Caso tenham o mesmo epoch você terá que deletar todos os registros e inserir um novo registro manualmente.

> select epoch, * from public.table1;

  epoch  | id | val 
---------+----+-----
 1793982 |  1 | a
 1793982 |  1 | b
(2 rows)

> delete from public.table1 where epoch = 1793982 and id = 1 and val = 'b';

 OUTPUT 
--------
      1
(1 row)

> select epoch, * from public.table1;

  epoch  | id | val 
---------+----+-----
 1793982 |  1 | a
(1 rows)

E agora tudo funcionando como realmente deveria ser

> select * from public.table1 a inner join public.table2 b on (a.id = b.id);

 id | val | id | val 
----+-----+----+-----
  1 | a   |  1 | c
(1 row)

Integrator Plugin for Pentaho 5

noreply@blogger.com (Kleyson Rios) — Fri, 24 Jul 2015 16:06:00 -0300

Some people asked me about how to use the old version of Pentaho Servlet Integrator in the new Pentaho 5.

Unfortunately, the core of Pentaho 5 it's totally different from Pentaho 4.8. So, the way to authenticate the user used by Pentaho Servlet Integrator cannot be used any more in the Pentaho 5.

The Integrator Plugin for Pentaho 5 is a new implementation with the same idea, but that works in the Pentaho 5 and was developed as a pentaho plugin instead of a servlet.

Note: The plugin was not tested in the Pentaho versions prior than 5.4.

How does it work ?

First, the user authenticates on their application. From some menu, he/she asks to access some resource on the Pentaho, such as, a report or a dashboard.
Second, the application must maintain a common database table and insert a new record with the username / tokenid / url.

username: a pentaho username to be used.
tokenid: in our case we use jsessionid as token.
url: the url from the resource on the Pentaho Server coded in base64.

Note: for the url doesn't use the http://server:port. Example:
Resource: http://localhost:8080/pentaho/Home?lang=pt-BR
Url: /pentaho/Home?lang=pt-BR
Third, after the application insert the record it must send a browser redirect to
http://localhost:8080/pentaho/plugin/integrator/api/go?type=token&token=<tokenid>&urlEncoded==<url_enconded_base64>
Then, Pentaho server will decode the url and try do a select on the tokensbi table to filter the username to be used in the Pentaho session.
So, If tokenid/url is valid, the Pentaho server will create an authenticated session and redirect the user to the Pentaho resource.

How to install ?

Use the Marketplace to install it.

How to use it ?

Create a new JNDI connection in the Pentaho.
Configure the new JNDI name into integrator.properties file.
Do the proper configurations in the application.

Using a node.js app sample

To test the plugin, you can use an node.js app sample available in the folder resources/app-sample.

Install node.js
Install packages. In the folder app-sample execute npm install
Configure the postgresConnectionString property in the config.js file to access the same database configured in the JNDI connection.
Run the app: node server.js
Test it: http://localhost:1010

Video (Portuguese)

Contribution

If somebody sees any improvement opportunity, please feel free to suggest and contribute with the project.

Enjoy it !!!

How to create a Treetable (parent-child hierarchies) on CDE

noreply@blogger.com (Kleyson Rios) — Mon, 12 Jan 2015 17:56:00 -0200

Introduction

In this blog post I will be showing how to create a treetable using Pentaho CDE as shown in the bellow picture using the jQuery treetable plugin.

How to use it

First, you should add a unique data-tt-id attribute to each of the rows in your table, for example 'node-x'. Then you add a data-tt-parent-id attribute to each child of a node, give this class a value of 'node-x'. The node-x part should be the same as the data-tt-id of its parent. Do you still follow me? Let me show you an example of a very simple tree: a single parent with a single child.

<table>
  <tr data-tt-id="1">
    <td>Parent</td>
  </tr>
  <tr data-tt-id="2" data-tt-parent-id="1">
    <td>Child</td>
  </tr>
</table>

Please note that the plugin expects the rows in the HTML table to be in the same order in which they should be displayed in the tree. For example, suppose you have three nodes: A, B (child of node A) and C (child of node B). If you create rows for these nodes in your HTML table in the following order A - C - B, then the tree will not display correctly. You have to make sure that the rows are in the order A - B - C.

How to do in the CDE

Download the jQuery treetable plugin at http://plugins.jquery.com/treetable/.

Unzip the file and make a copy of the jquery.treetable.css, jquery.treetable.theme.default.css and jquery.treetable.js files to your solution project folder.

Create a new dashboard and add those files as a Resources.

Define your CDE layout, add a Table Component and a DataSource.

On the Draw Function of the Table Component, write a function to add correctly the attributes data-tt-id and data-tt-parent-id for every row.

On the Post Execution Function of the Table Component, apply the jQuery treetable plugin at the table using the code:

function() {
    $('#' + this.htmlObject + ' table').treetable({ expandable: true });
}

If everything are correct, you will get a nice treetable.

Additionally, you can apply some CSS to customize the table.

Example

Now, I'm going to show a real example!

For this sample works, the resultset from the Datasource MUST have in the first column the data in following format:

1 - AAAAA
2 - BBBBB
2.1 - CCCCC
2.1.1 - DDDDD
2.2 - EEEEE
3 - FFFFF

Do the steps defined in the before section, but on the Draw Function, use the following code:

function f() 
{
    var table = $('#' + this.htmlObject + ' table');
    var rows = $('tbody tr', table);
    var oTable = table.dataTable();

    rows.each(function(i) {

        var rowData = oTable.fnGetData(this);

        // Get ID and Parent_ID
        var res = rowData[0].split("-");
        var node = res[0].trim();
        $(this).attr('data-tt-id', node);   
        
        var nodeMatch = node.match(/^[0-9\.]+\./g);
        if (nodeMatch != null) {
            var aux_node_pai = nodeMatch[0];
            var node_pai = aux_node_pai.substr(0, aux_node_pai.length-1);        
            $(this).attr('data-tt-parent-id', node_pai);   
        }

    });
}

The code above, will identify the ID and Parent_ID and set correctly the attributes data-tt-id and data-tt-parent-id for every row.

Download the sample files here.

More Information

For more parameters and additional information about the plugin access http://ludo.cubicphuse.nl/jquery-treetable/.

That's it !!!!

Configurando Shell In A Box no CentOS

noreply@blogger.com (Kleyson Rios) — Tue, 18 Nov 2014 09:15:00 -0200

Introdução

Shell In A Box (pronunciado shellinabox) é um emulador de terminal baseado na web criado por Markus Gutschke. Ele tem internamente um servidor web próprio que roda um cliente SSH baseado na web e em uma porta específica, disponibilizando para você um emulador de terminal para acessar e controlar remotamente seu servidor linux.

Shell In A Box utiliza somente AJAX/Javascript e CSS para funcionar, sem precisar instalar nenhum outro software adicional.

Nesse tutorial, iremos descrever como instalar o shellinabox para acessar remotamente o terminal SSH de um servidor linux usando apenas um browser moderno.

Clientes SSH baseado na web são bastante úteis quando você está protegido por um firewall/proxy e somente HTTP(s) podem passar por eles.

Instalando o Shellinabox no CentOS 6

Por padrão o shellinabox já vem incluído em várias distribuições através de seus repositórios padrões.

Mas no RHEL/CentOS você precisa primeiro instalar o repositório EPEL para conseguir instalá-lo via yum.

## RHEL/CentOS 6 64-Bit ##
sudo rpm -ivh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

Caso queira instalar o EPEL em outras versões do RHEL/CentOS pode consultar o artigo How to Enable EPEL Repository for RHEL/CentOS 7.x/6.x/5.x ou então ler um pouco mais em EPEL - FedoraProject.

Configurando o Shellinabox

Por padrão, shellinabox vem configurado para escutar na porta TCP/4200. Também, durante a instalação um novo certificado auto assinado é automaticamente criando dentro do diretório "/var/lib/shellinabox".

Para editar o arquivo de configuração:

sudo vi /etc/sysconfig/shellinaboxd

# Shell in a box daemon configuration
# For details see shellinaboxd man page

# Basic options
USER=shellinabox
GROUP=shellinabox
CERTDIR=/var/lib/shellinabox
PORT=4200
OPTS="--disable-ssl-menu -s /:LOGIN"


# Additional examples with custom options:

# Fancy configuration with right-click menu choice for black-on-white:
# OPTS="--user-css Normal:+black-on-white.css,Reverse:-white-on-black.css --disable-ssl-menu -s /:LOGIN"

# Simple configuration for running it as an SSH console with SSL disabled:
# OPTS="-t -s /:SSH:host.example.com"

Inicie o shellinabox:

service shellinaboxd start

ou

/etc/init.d/shellinaboxd start

Habilite o shellinabox para iniciar automaticamente toda vez o servidor linux for ligado:

chkconfig shellinaboxd on

Testando

Depois de tudo configurado é só testar, apontando seu navegador para http://server_ip_address:4200.

Aumentando a Segurança

Enquanto o shellinabox oferece uma grande conveniência para os administradores de sistema, ele pode oferecer um fácil ponto de entrada para hackers se não estiver apropriadamente seguro.

Li em alguns fóruns pessoas questionando e condenando a utilização do shellinabox. Mas, se você já tem liberado para a internet a porta SSH do seu servidor, de certa estamos apenas criando uma outra interface para acessar um serviço que já se encontra liberado.

Mas independentemente dessa discussão filosófica, vamos trazer um pouco mais de segurança para o nosso novo serviço.

1. Altere a porta padrão

Shellinabox por padrão vem configurado para escutar na porta 4200 e o problema é que hackers sabem dela. Entretanto, alterando a porta default para um outro número qualquer dificultará outras pessoas de encontrarem o serviço.

sudo vi /etc/sysconfig/shellinaboxd

# Altere a linha
PORT=5456

2. Ative SSL

Acessar o shellinabox sobre HTTP mandará todas as informações, inclusive usuário e senha, de forma não criptografada. Isto pode ser perigoso principalmente se você estiver acessando seu shellinabox remotamente na internet. A solução então é criptografar todos os dados durante a transferência, que dificultará a interceptação dos dados por pessoas maliciosas. Para ativar e forçar o acesso no linux via HTTPS, instale a seguinte lib:

sudo yum install openssl

Garanta que as opções '-t' ou '--disable-ssl' não esteja configurada no
OPTS="..."

Reinicie seu shellinabox. Ele agora deve estar acessível pelo endereço https://server_ip_address:5456.

Note que você precisa ter um certificado SSL gerado. Como já dito, durante a instalação do shellinabox foi gerado um certificado auto assinado. Esse tipo de certificado fará com que o navegador abra uma janela de alerta quando tentar acessar o serviço.

3. Altere o SERVICE para SSH

Por padrão o shellinabox vem configurado para conectar ao sistema host através da chamada do /bin/login, pedindo o usuário e senha para então iniciar um login shell padrão.

Podemos alterar o SERVICE para SSH e dizer em qual servidor o shellinabox deverá conectar. Para isso edite o arquivo de configuração, localize a linha abaixo e faça a respectiva configuração:

sudo /etc/sysconfig/shellinaboxd

OPTS="--disable-ssl-menu -s /:SSH:127.0.0.1"

Caso quisesse que o shellinabox fizesse um SSH para um outro servidor que não fosse o mesmo onde o serviço está rodando, poderia alterar o endereço de localhost (127.0.0.1) para o endereço IP do outro servidor.

O serviço via SSH cria uma camada a mais de segurança entre o servidor shellinabox e o servidor ao qual está fazendo o acesso.

4. Restrinja o shellinabox apenas para localhost

Você pode restringir o acesso ao shellinabox apenas do localhost, ou seja, você terá acesso a ele somente do sistema onde o mesmo esta rodando.

sudo /etc/sysconfig/shellinaboxd

Encontre a linha abaixo e inclua a opção "--localhost-only"

OPTS="--localhost-only --disable-ssl-menu -s /:SSH:127.0.0.1"

Salve e reinicie o shellinabox. Enquanto essa configuração pode aumentar a segurança do serviço ela bloqueará o acesso de outros sistemas e acesso remoto pela internet, o que se torna um grande problema. Mas não se preocupe, essa configuração faz parte de um plano maior !!!

5. Configure o acesso ao shellinabox via proxy reverso

Para adicionar uma camada de conveniência a segurança do shellinabox, vamos configurar o acesso via proxy reverso. Essa configuração pode ser feita via apache, mas nesse tutorial estaremos fazendo a configuração via nginx. Então vamos primeiramente instalar o nginx:

sudo yum install nginx

Particulamente, eu tive algumas dificuldades em utilizar o certificado digital auto assinado que foi gerado na instalação do shellinabox. Você pode inicialmente tentar utilizá-lo, mas caso tenha algum problema poderá gerar um outro com os seguintes comandos:

sudo mkdir /etc/nginx/ssl
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/localhost.key -out /etc/nginx/ssl/localhost.crt

Por padrão o nginx já vem com algumas configurações do servidor WEB. Como minha instalação é exclusiva para acessar o shellinabox eu desativei essas configurações padrões.

sudo mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf.orig

Agora vamos criar as configurações de acesso ao nosso shellinabox.

sudo vi /etc/nginx/conf.d/shellinabox-ssl.conf

E adicione ao arquivo a seguinte configuração abaixo.

server {

  listen 443 default_server;
  server_tokens off;
  ssl on;
  ssl_session_timeout 5m;
  ssl_certificate /etc/nginx/ssl/localhost.crt;
  ssl_certificate_key /etc/nginx/ssl/localhost.key;
  ssl_protocols SSLv3 TLSv1;
  ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
  ssl_prefer_server_ciphers on;

  proxy_set_header Host $http_host;
  proxy_set_header X-Forwarded-Host $http_host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

  location ~* /shell/ {
    proxy_pass http://127.0.0.1:5456;                                           
    access_log /var/log/nginx/shellinabox.access.log;
    error_log /var/log/nginx/shellinabox.error.log;
  }

  location / {
    return 404;
  } 

  error_page 404 /404.html;
  location = /404.html {
    root /usr/share/nginx/html;
  } 

}

A configuração acima está basicamente dizendo:

Crie um novo servidor na porta 443 e habilite SSL;
Use o certificado que criamos um pouco mais acima;
Crie um 'location' chamado '/shell/' que fará um redirect para 'http://127.0.0.1:5456';
Se alguém tentar acessar a raiz do servidor web gere um ERROR 404;
ERROR 404 deverá exibir o arquivo 404.html.

Agora reinicie o nginx e o configure para subir sempre que reiniciar o servidor.

sudo /etc/init.d/nginx restart
sudo chkconfig nginx on

Teste a nova configuração acessando:

https://IP_ADDRESS/shell/

Acessando o endereço acima, o nginx funcionará como uma ponte transparente entre o seu navegador e o shellinabox, o que aumenta a segurança do shellinabox não revelando a porta de acesso para o mundo externo.

6. Configure o firewall para bloquear a porta do shellinabox

Apesar de você ter o nginx como uma ponte entre o shellinabox e o seu navegado, alguém poderá rodar um 'port scanner' e ainda assim encontrar a porta aberta e tentar explorá-la.

Para evitar isso, basta configurar o iptables para bloquear qualquer tipo de acesso externo na porta do shellinabox.

7. Ative a autenticação

Tanto no apache quanto no nginx você pode ativar uma tela de autenticação para acessar determinada URL. Então, cada vez que você acessar o shellinabox será solicitado a você um usuário e senha como mostrado na tela abaixo:

Para fazer isso, primeiro você precisa criar um arquivo .htpasswd. Você pode usar o programa htpasswd, que geralmente vem no pacote do apache ou então utilizar qualquer gerador online de htpasswd, como por exemplo o http://www.htpasswdgenerator.net/.

Salve o arquivo: "/etc/nginx/.htpasswd", e edite o arquivo de configuração do nginx.

sudo vi /etc/nginx/conf.d/shellinabox-ssl.conf

E insira as linhas abaixo em destaque no arquivo de configuração.

server {

  listen 443 default_server;
  server_tokens off;
  ssl on;
  ssl_session_timeout 5m;
  ssl_certificate /etc/nginx/ssl/localhost.crt;
  ssl_certificate_key /etc/nginx/ssl/localhost.key;
  ssl_protocols SSLv3 TLSv1;
  ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
  ssl_prefer_server_ciphers on;

  proxy_set_header Host $http_host;
  proxy_set_header X-Forwarded-Host $http_host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

  location ~* /shell/ {
    proxy_pass http://127.0.0.1:5456; 
    auth_basic "Access Restricted";
    auth_basic_user_file "/etc/nginx/.htpasswd";                                          
    access_log /var/log/nginx/shellinabox.access.log;
    error_log /var/log/nginx/shellinabox.error.log;
  }

  location / {
    return 404;
  } 

  error_page 404 /404.html;
  location = /404.html {
    root /usr/share/nginx/html;
  } 

}

Pronto, agora é so reiniciar o nginx para ter uma tela de autenticação no acesso do shellinabox.

8. Configure autenticação em 2 passos no SSH

Quem não conhece autenticação em 2 passos ? Basicamente é aquele sistema onde além da sua senha você tem 'token' que gera um número aleatório a cada 30s, como utilizado para acesso aos bankline's da vida.

Para saber como habilitar autenticação em 2 passos no SSH leia o artigo Configurando Autenticação em 2 Passos no CentOS 6.

9. Notifique quando usuários logar via shellinabox

Apesar das várias camadas de segurança adicionadas, vamos ainda configurar um script que será executado toda vez que alguém logar via SSH no servidor através do shellinabox.

Nesse script você poderá enviar um email, mandar um SMS ou uma mensagem via WhatsApp para você alertando qua alguém logou no sistema e esse alguém não é você.

No nosso caso estamos utilizando os serviços prestados pela empresa Torpedo SMS Fácil que possui uma API de envio de SMS, para sempre que alguém logar no nosso sistema via shellinabox sejamos avisados ao mesmo tempo via SMS, permitindo tomar ação de forma rápida antes que algo mais crítico aconteça.

Para configurar a notificação crie o script a ser executado (como no exemplo abaixo).

sudo vi /etc/ssh/ssh_script.sh

#!/bin/bash
#Script file for ssh
#

# find IP address
ip=`echo $SSH_CONNECTION | cut -d " " -f 1`

#PUT YOUR COMMANDS HERE
echo "$USER just logged in from $ip" > /tmp/test.txt

#exit by calling a shell to open for the ssh session
/bin/bash

Onde tem o comentário "#PUT YOUR COMMANDS HERE" é onde você deverá colocar o comando de enviar um SMS ou realizar alguma outra atividades. No exemplo acima, estamos simplesmente jogando as informações para dentro de um arquivo.

Vamos agora configurar o SSH para que execute o comando quando alguém fizer um logon.

sudo vi /etc/ssh/sshd_config

No final do arquivo inclua.

# Executar script quando a conexao for via shellinabox
Match Address 127.0.0.1
    ForceCommand /etc/ssh/ssh_script.sh

Usamos o "Match Address" do SSH para dizer que o script deverá ser executando somente quando acontecer um logon que o IP de origem seja 127.0.0.1, pois quem está fazendo a conexão no SSH é o nginx que roda na mesma máquina.

Dessa forma conseguimos filtrar a execução do script apenas para logins via shellinabox.

Possíveis Erros

Caso esteja encontrando alguma dificuldade no funcionamento ou algum erro esteja sendo gerado nos logs do sistema, tente desativar o SELinux.

Eu tive algum problemas durante algumas configurações e só consegui resolver depois de ter desativado o SELinux do sistema.

Conclusão

Com todos esses passos conseguimos criar um cliente SSH web-based com a ajuda do Shell In A Box e do nginx, e ainda adicionar algumas camadas de segurança ao nosso serviço.

Referências

Sites que utilizei como referências para as respectivas configurações.

Shell in a Box - Remote to your Linux server via web browser
Shell In A Box – A Web-Based SSH Terminal to Access Remote Linux Servers
5 Easy steps to Increase Shellinabox Security
How to install Shell In a Box
Shellinabox With Apache Authentication Over HTTPS 443
How to get ssh access from almost anywhere in the world to your server with ssl encypted security!
How To Create a SSL Certificate on Apache for CentOS 6

Abraços.

Configurando Autenticação em 2 Passos no CentOS 6

noreply@blogger.com (Kleyson Rios) — Tue, 18 Nov 2014 09:09:00 -0200

Introdução

Autenticação em 2 passos é aquele processo que além do seu usuário e senha tradicionais é solicitado um código validador adicional. Esse código validador pode ser enviado por SMS, gerado por algum programa ou gerado por token.

A cada intervalo de tempo, geralmente 30s, um novo código é gerado e o código anterior é invalidado.

Então mesmo que uma pessoa conheça seu usuário e senha, provavelmente ela não conseguira ter acesso ao sistema se não tiver o código validador daquele exato momento, aumentando a segurança no acesso do servidor.

Nesse artigo vamos mostrar como configurar a autenticação em 2 passos para conexões via SSH no servidor e utilizaremos para isso a libpam google-authenticator.

O Google Authenticator implementa tokens de segurança TOTP (timebased one-time-password) de acordo com a RFC6238 via o aplicativo de celular Google Authenticator. O Authenticator fornece um código de 6 dígitos que deverá ser fornecido juntamente com o usuário e senha no login, que geralmente é chamado de autenticação em dois passos.

Sincronização do relógio

Os tokens de segurança TOTP são algoritmos sensíveis ao tempo, ou seja, é necessário que o relógio das várias máquinas envolvidas no processo de criação do token e validação do mesmo estejam com seus relógios sincronizados.

Algumas implementações possuem uma tolerância para permitir que pequenas diferenças entre os relógios não afetem a validação do código.

Então a primeira etapa desse processo é habilitar o serviço ntpd no servidor e garantir que o mesmo suba sempre que o servidor for reiniciado.

sudo service ntpd start
sudo chkconfig ntpd on

Instalação do google-authenticator

Teremos que baixar o código fonte do google-authenticator e compilá-lo. Para isso vamos instalar antes alguns pacotes necessários.

sudo yum install make gcc pam-devel

Baixe o código fonte do google-authenticator.

cd /tmp
wget https://github.com/google/google-authenticator/archive/master.zip
unzip master.zip
cd google-authenticator-master/libpam

Agora compile e instale as libs.

sudo make
sudo make install

O "make install" basicamente copiará dois arquivos:

a lib pam_google_authenticator.so para /lib64/security
o executável google-authenticator para /usr/local/lib

Configurando o Google Authenticator

Antes de configurar o SSH, vamos primeiro configurar o google authenticator para um usuário. As etapas desse processo serão basicamente:

logar com o usuário;
executar o programa google-authenticator;
responder as perguntas.

su - kleyson
$ google-authenticator

Do you want me to update your "~/.google_authenticator" file (y/n) y
 
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/user@server%3Fsecret%3DABCD12E3FGHIJKLMN
Your new secret key is: ABCD12E3FGHIJKLMN
Your verification code is 98765432
Your emergency scratch codes are:
  01234567
  89012345
  67890123
  45678901
  23456789
 
Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y
 
By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) y
 
If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

Essas configurações serão gravadas dentro do diretório home do usuário no arquivo "~/.google-authenticator".

Guarde em algum lugar seguro os dados mostrados na tela:

secret key
verification code
emergency codes

Os "emergency codes" poderão serem utilizados como emergência em momento que você precise logar no servidor e por alguma razão seu smartphone não esteja com você. Por isso a necessidade de guardar esses códigos em algum lugar seguro.

Instalando e Configurando o Google Authenticator app

Entre na loja de aplicativos oficial do seu smartphone e procure pelo aplicativo "Google Authenticator" que é disponibilizado pela própria Google e faça a instalação do mesmo.

No processo de configuração do google-authenticator para o usuário, foi gerado e mostrado na tela uma URL. Abra a respectiva URL no seu navegador. Deverá ser exibido um QR code.

Esse QR code é gerado baseado no "secret key" gerado anteriormente.

Agora abra o Google Authenticator no seu smartphone. Na tela terá o ícone de um lápis, clique nele e depois clique no ícone de um "+" para adicionar uma nova entrada.

Escolha a opção "Ler código de barras" e aponte a câmera para o QR code no navegador. O app então deverá incluir uma nova entrada e começara a gerar um novo código a cada 30s.

Se por algum motivo não conseguir utilizar a opção "Ler código de barras" selecione a opção "Inserir manualmente". Insira então um nome para a "Conta" e sua "secret key" e confirme.

Você não deverá ter problema de sincronia da hora, pois a hora dos nossos celulares são sincronizados com a operadora, que com certeza devem estar sincronizados com algum servidor NTP.

OBS.: As instruções acima foram baseadas no aplicativo do iphone.

Configurando o PAM

Vamos agora configurar o PAM do SSH para utilizar a lib do google authenticator. Edite o arquivo "/etc/pam.d/sshd" e adicione no topo do arquivo a linha "auth required pam_google_authenticator.so".

sudo vi /etc/pam.d/sshd

#%PAM-1.0
auth required pam_google_authenticator.so
auth required pam_sepermit.so
auth include password-auth
account required pam_nologin.so
account include password-auth
password include password-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the
user context
session required pam_selinux.so open env_params
session optional pam_keyinit.so force revoke
session include password-auth

Com essa configuração todos usuários que tentarem logar via SSH será solicitado um código de verificação.

Caso queira exigir autenticação em 2 passos apenas para usuários que tenham o google authenticator configurado para suas contas (se o arquivo ~/.google_authenticator existir), então inclua o comando "nullok" na configuração do pam.

#%PAM-1.0
auth required pam_google_authenticator.so nullok
auth required pam_sepermit.so
auth include password-auth
account required pam_nologin.so
account include password-auth
password include password-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the
user context
session required pam_selinux.so open env_params
session optional pam_keyinit.so force revoke
session include password-auth

A ordem que você inclui essa configuração é importante. Dado essa configuração, primeiro será solicitado a você o código de verificação do google authenticator para então depois solicitar a senha do usuário.

Configurando o SSH

Edite o arquivo "/etc/ssh/sshd_config" e verifique as seguintes configurações:

PasswordAuthentication yes
ChallengeResponseAuthentication yes
UsePAM yes

Reinicie o SSH.

service sshd restart

Pronto! Agora quando você logar via SSH no servidor com um usuário que tenha google authenticator configurado para sua conta, você terá que entrar primeiramente com o código de verificação, que é exibido pelo Google Authenticator app, e apenas depois entrar com a senha do usuário.

Possíveis Erros

Se você tiver algum problema verifique os arquivos de log, principalmente o "/var/log/secure".

Se você tiver SELinux ativo, talvez você não consiga logar e o seguinte erro pode ser gerado no "/var/log/secure" .

Jan  3 23:42:50 hostname sshd(pam_google_authenticator)[1654]: Failed to update secret file "/home/username/.google_authenticator"
Jan  3 23:42:50 hostname  sshd[1652]: error: PAM: Cannot make/remove an entry for the specified session for username from 192.168.0.5

Nesse caso tente desativar o SELinux.

Para mais informações sobre esse problema veja aqui.

Bypass o google authenticator se o logon é da rede local

Se você confia nos sistemas da sua rede local, podemos então desativar o google authenticator para os logons SSH originados na sua rede local.

Edite o arquivo "/etc/pam.d/sshd" e o deixe parecido com a configuração abaixo:

auth [success=1 default=ignore] pam_access.so accessfile=/etc/security/access-local.conf
auth       required     pam_google_authenticator.so

Então crie o arquivo "/etc/security/access-local.conf" com a configuração abaixo:

# Google Authenticator can be skipped on local network
+ : ALL : 192.168.0.0/24
+ : ALL : LOCAL
- : ALL : ALL

Assumindo que o endereço da sua rede local é 192.168.0.0/24.

Referências

Sites que utilizei como referências para as respectivas configurações.

Two-Step Authentication for SSH on CentOS 6 Using Google Authenticator
google-authenticator

Abraços.

Pentaho + Bovespa

noreply@blogger.com (Kleyson Rios) — Thu, 17 Jul 2014 12:01:00 -0300

No dia 12 de Maio de 2014 foi inaugurado o site Mercado Analítico , que tem como objetivo ser um portal de ferramentas analíticas que permitem ajudar os investidores, em seus diversos níveis, a tomarem as melhores decisões de negócios.

O portal tem como visão ser uma plataforma completa de análise da Bovespa, Títulos Públicos, Fundos Imobiliários, rastreadores inteligentes, etc.

De forma mais técnica, a plataforma tem como base principal a suite Pentaho, utilizada para a cargas de dados no DW e construção dos painéis de acompanhamento.

Mas algumas outra integrações foram necessárias para atender particularidades específicas dos requisitos bem como adicionar uma camada extra de segurança.

Entre essas integrações existem gráficos utilizando a biblioteca Highcharts e também uma integração com NodeJS para a execução de cálculos complexos no lado do servidor.

Para aqueles que ainda tem alguma dúvida sobre o potencial do Pentaho, tem no Mercado Analítico mais um exemplo do que podemos fazer com essa fantástica ferramenta.

Abracos.

Kleyson Rios.

Pentaho Servlet Integrator

noreply@blogger.com (Kleyson Rios) — Fri, 17 Jan 2014 15:34:00 -0200

You can always see someone asking how to integrate Pentaho with a Third Party Application.

Pentaho Servlet Integrator allows you to call from a Third Party App any analyse, dashboard, report etc from the Pentaho without pass user/password on the URL.

How does it work ?

First, the user authenticate on their application. From some menu, he/she asks to access some resource on the Pentaho, such as, a report or a dashboard.
Second, their application must maintain the tokensbi table inserting a new record, storing username / tokenid / url.

username: the same username must be created on the Pentaho.
tokenid: in our case we use jsessionid as token.
url: the url from the resource on the Pentaho Server.
Third, the application do a sendRedirect to
http://pentaho-server:8080/pentaho/Integrator?token=<tokenid>&url=<url_enconded_base64>
Then, Pentaho server will decode the url and try do a select on tokensbi table, filtering by tokenid and url.
So, If tokenid/url is valid, Pentaho server will create an authenticated session for the user.

How to use it

Download Pentaho Servlet Integrator

svn checkout http://pentaho-servlet-integrator.googlecode.com/svn/trunk/ pentaho-servlet-integrator-read-only

Save Integrator.jsp on the folder biserver-ce\tomcat\webapps\pentaho\jsp

Add the following configurations on the file web.xml

<servlet>
 <servlet-name>Integrator</servlet-name>
 <jsp-file>/jsp/Integrator.jsp</jsp-file>
</servlet>

<servlet-mapping>
 <servlet-name>Integrator</servlet-name>
 <url-pattern>/Integrator</url-pattern>
</servlet-mapping>

Add the following configuration on the file system\applicationContext-spring-security.xml

\A/integrator.*\Z=Anonymous,Authenticated

after the lines

        <![CDATA[
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON

Create a table called tokensbi

CREATE TABLE public.tokensbi
(
  id bigint NOT NULL DEFAULT nextval(('public.toke_seq'::text)::regclass),
  username character varying(32) NOT NULL,
  token character varying(100) NOT NULL,
  url character varying(255) NOT NULL,
  created timestamp without time zone NOT NULL DEFAULT clock_timestamp(),
  CONSTRAINT toke_id_pk PRIMARY KEY (id),
  CONSTRAINT toke_uk UNIQUE (username, url)
)

Create on the Pentaho Server a new database connection that has access on the tokensbi table.
Edit Integrator.jsp and update the variable DatabaseJndiName, setting the name defined for the new connection.
Change the application to insert a new record on tokensbi table each time that the user click to access some Pentaho resource.

CBFL – A modified version of CTools CBF

noreply@blogger.com (Kleyson Rios) — Thu, 31 Oct 2013 13:17:00 -0200

There are no doubts about the benefits for using CTools CBF. Good blog posts are available about it.

Read http://pedroalves-bi.blogspot.co.uk/2012/09/cbf-and-versioning-how-to-develop.html and http://diethardsteiner.blogspot.com.br/2013/10/going-agile-pentaho-community-build.html.

For those ones that need customize Pentaho source code to change or include new features, CBF is the best option.

But, why do I need to compile the entire source code of Pentaho if there is no change in the source code? How to use Pentaho bundled package instead?

To addressing those questions, I’ve made some changes on CBF to use Pentaho bundled package instead of Pentaho source code. Moreover, I’ve also added some new features that I think be important.

CBFL was tested only on CE and can be found on http://code.google.com/p/cbfl/ .

I won’t go deep in how to use CBFL, however I’ll show mainly the new features on CBFL (Community Build Framework Light).

To see all the options available, run:

# ant -Dproject=samples -Denv=48_dev –p

Option	Description
all	Apply the patches and runs the solution
apply-patch	Apply the patches
clean-solution	Deletes the pentaho-solutions of the project
deploy-all	Apply patches and deploys both the solution and the server to the specified destinations
deploy-server	Apply patches and deploys the entire server to the specified destination
deploy-solution	Apply patches and deploys the solution to the specified destination
dist-clean	Deletes the target preconfigured
list	List build files of a project
run	Runs the solution
stop	Stops the solution
zip	ZIP the solution

Feature #1: apply-patch option

Copy Pentaho software to target directory and apply all patches.

This option execute also: dist-clean

Feature #2: clean-solution option

Remove the cbfl/project-samples/pentaho-solutions folder created in the apply-patch process.

CAUTION: If you use CBFL for development, you can loose projects inside the folder.

Feature #3: list option

Many config file can be created to fit specific needs for the same project, such as production.properties / dev.properties OR joe.properties / suse.properties.

List option will print on screen all files within config directory.

Feature #4: stop option

If you use CBFL for development, you can use stop option to shutdown Pentaho server.

Feature #5: zip option

A very useful option, allow you to generate a new bundled package with all patches.

The zip file generated will keep the same structure found on original Pentaho bundled package.

Feature #6: delete_list.xml config file

Is advised when installing a new version of a plugin, for instance CDF/CDA/CDE, delete the previous version of it.

Sometimes you also need to update some lib, such as a new version of Mondrian. So, you need before delete the old version of .jar file to copy the new one.

Use the config/delete_list.xml file to configure properly all folders and files that you wish to delete before.

Feature #7: rename_list.xml config file

When building a new package (zip file), the files specified in the config file will be renamed for a versioned name.

This will guarante you that some files won't be override when unziping the new package in the pentaho server.

Feature #8: patches-private option

We had a need to do a specific configuration for a server. But that wasn’t possible using just tokens.

So, patches-private gives you a second level to apply the patches. In our case, we used this second level to copy customized configuration files

Feature #9: MANDATORY token configuration

Is mandatory defining the token @SOLUTION.PATH@ on web.xml file.

For that, edit project-samples/patches/biserver-ce/tomcat/webapps/pentaho/WEB-INF/web.xml file and configure:

<context-param>
       <param-name>solution-path</param-name>
       <param-value>@SOLUTION.PATH@</param-value>
</context-param>

That configuration set up the correct location of pentaho-solutions folder when starting pentaho from cbfl or from the zip file.

Feature #10: MANDATORY token configuration

Is mandatory defining the token @SAMPLE.CATALOGS@ on datasources.xml file.

For that, edit project-samples/patches/biserver-ce/pentaho-solutions/system/olap/datasources.xml file and replace:

<Catalog name="SteelWheels">
 <DataSourceInfo>Provider=mondrian;DataSource=SampleData</DataSourceInfo>
 <Definition>solution:steel-wheels/analysis/steelwheels.mondrian.xml</Definition>
</Catalog>
<Catalog name="SampleData">
 <DataSourceInfo>Provider=mondrian;DataSource=SampleData</DataSourceInfo>
        <Definition>solution:steel-wheels/analysis/SampleData.mondrian.xml</Definition>
</Catalog>

for

@SAMPLE.CATALOGS@

That configuration will set up the sample catalogs only if you defined copy.pentaho.samples=TRUE.

Enjoy.

Controlling Data Loading Process using Kettle

noreply@blogger.com (Kleyson Rios) — Thu, 26 Sep 2013 11:33:00 -0300

Sometimes you have a process to load data from a flat file to a database, even from a database to your DW.

But if something goes wrong? How do you know if your load process finished successfully or not? If not, how do you reprocess the files without duplicate records?

This post will bring an option to try addressing those problems.

The main ideas of control process are (1) generate an ID for the process (2) save a timestamp at beginning (3) save ID on all the tables controlled (4) save a timestamp at the end.

So, if some problem occurs and aborts the job, next time you will be able to identify all data inserted by that job, delete them and insert again.

I’m assuming PostgreSQL as Database. For others databases might be necessary some adjusts.

Bellow is an overview of the whole process.

For this process works you need:

(1) Create a table called ‘ctrl_carga’ within each schema that has tables that you want to control. This table is responsible to store the ID / Start Timestamp / End Timestamp / ID_Job / Customized Fields, for each run of the job.

Create table schema.ctrl_carga (

id bigint NOT NULL DEFAULT nextval(('schema.ctrl_carga_seq'::text)::regclass),

start_process timestamp without time zone NOT NULL DEFAULT (now())::timestamp without time zone,

end_process timestamp without time zone,

id_job character varying NOT NULL

)

All fields above are mandatory, but you can add more fields if needed to do a more precise control.

Let’s imagine that inside the schema you have two tables to be controlled and each table is loaded by different jobs. The field ‘id_job’ must store a key that identifies uniquely the job.

This is important because both jobs can be aborted, so you need retrieve the ID for job1 to delete only the data inserted by job1 during that problematic run, and retrieve the ID for job2 to delete only the data inserted by job2 as well.

(2) Add the following column in each table to be controlled

ctrl_carga_id bigint NOT NULL

(3) Set some important global variables

ctrl_schema: name of the schema where the tables are.

ctrl_id_job: key that identifies uniquely the job.

ctrl_database: database used.

(4) Create a transformation that generate and save the timestamp at beginning (start_ctrl_carga step)

If some run didn’t finish correctly the step above will return the same ID created previously, otherwise it will create a new record and return the new ID.

And if you are using additional fields to control the load process, you also need to specify those fields in the step.

And set a new variable with the ID.

(5) Create a transformation (ctrl_carga) that will search for all runs didn’t finished correctly and delete all data related to them.

Search for all IDs didn’t finished.

If for some reason the ID list is necessary for others step, they are returned using a ‘Copy rows to result’.

Step just to join ID list with database type.

Use a filter rows to select the path for the data flow. Because next step it’s customized for each database.

Like said before, this step is customized for each database. It must return a list of all tables that has the field ‘ctrl_carga_id’, except the control table ‘ctrl_carga’.

So, if you are using a different database, such as Mysql, create a new customized path with the same idea.

How I don’t know which tables hold records related to IDs didn’t finished, the step will execute a delete for all IDs in all tables controlled. This step will clean up all data from the problematic runs to be stored again without duplication.

Remember, even a new ID will be recognized as a problematic run, but no data will deleted.

(6) To finalize, save the timestamp at the end to indicate that job finished successfully.

See you !!

(Any corrections for English are welcome.)

Secretaria de Saúde do Estado de Goiás utiliza Pentaho como ferramenta de BI

noreply@blogger.com (Kleyson Rios) — Sun, 22 Sep 2013 18:31:00 -0300

A Secretaria de Saúde do Estado de Goiás a três anos vem desenvolvendo projetos de Business Intelligence utilizando a suite de ferramentas Pentaho.

Dentre seus projetos encontram-se painéis para acompanhamento e monitoramento da dengue nos municípios goianos, bem como painéis que permitem monitorar as campanhas de vacinação no Estado.

Esses painéis fornecem ainda aos analistas epidemiológicos e
gestores públicos terem uma visão mais precisa do que acontece em cada região do Estado, permitindo criar ações pontuais e definir as políticas públicas de saúde de forma mais precisa.

Os respectivos painéis estão abertos a todos que queiram acompanhar e podem ser acessados através do endereço http://www.saude.go.gov.br/index.php?idMateria=99503

Os analistas BI da Secretaria também contribuem com a comunidade Pentaho, disponibilizando plugins para o Pentaho desenvolvidos internamente.

Entre os plugins destacamos pentaho-gmaps-overlay e o pentaho-download-manager.

Análise IBovespa e Vale5 - 11/06/2008

noreply@blogger.com (Kleyson Rios) — Wed, 11 Jun 2008 22:07:00 -0300

O IBOV a duas semanas está em tendência de queda. Na correção de 38,2%, aproximadamente 66.ooo pontos, o índice deve encontrar um forte suporte, pois esse região coincide com o primeiro nível de suporte do candle longo de alta e com o suporte do TH anterior, que foi rompido pelo longo candle branco, ou seja, 3 suportes em um mesmo nível de pontos.

Se o índice romper esse nível deve buscar a correção de 50%, que também corresponde quase que com o segundo suporte do candle longo de alta.

A força vendedora continua muito forte no papel da VALE5, que pode ser verificado pela frequência de candles de baixa seguidos e pelo volume financeiro dos pregrões.

Apesar do OBV estar nos níveis mais altos, está mostrando que grandes investidores estão deixando o papel.

Os preços já romperam a MM200, e caso se mantenha abaixo dessa média móvel poderá indicar uma tendência de baixa para o longo prazo. O pregão de hoje também rompeu uma LTA que já havia sido testada 2 outras vezes, caso os próximos dois pregões confirme essa quebra poderemos ter o início de uma tendência de baixa.

Existe para o próximo pregão um forte suporte para ser rompido, que é a retração de 61,8% do fibonacci. Caso o mercado rompa esse suporte ele deve buscar os 100% da correção, na faixa de 40,00 a ação.

OBS.: As informação aqui apresentadas representa única e exclusivamente a opinião do autor, e não sugere nenhum tipo de operação no mercado. E tem a finalidade também de usar o que está sendo ensinado nas aulas postadas no blog.

Curso Candlestick - Parte 4: Tamanho, cor e frequência do corpo real

noreply@blogger.com (Kleyson Rios) — Mon, 9 Jun 2008 21:42:00 -0300

O gráfico de candle possibilita a identificação de vários elementos do comportamento humano, e isso significa poder identificar as forças que estão atuando no mercado.

Então você pode identificar o tom do mercado apenas avaliando o tamanho, cor e frequência de linhas de candle, tanto de forma individual como em um grupo de candle.

Na nossa aula de hoje, vamos aprender extrair valiosas informações de um conjunto de candles, baseado na características indicadas acima.

Operação com Opção - Vender a Seco

noreply@blogger.com (Kleyson Rios) — Wed, 4 Jun 2008 15:24:00 -0300

- Operação especulativa

A venda a seco é uma operação inversa a compra a seco. Você vende para o comprador um direito de compra da ação a um determinado preço, sem você ter essa ação na sua carteira.

Qual o problema da venda a seco ? Ela quebra o cara literalmente - leva o dinheiro investido, leva a casa, o carro, o limite do cheque especial ...

Diferentemente da compra a seco, que o máximo que você perde é o valor total investido naquela operação.

Porque a venda a seco leva todo seu dinheiro ? Vamos imaginar a seguinte situação:

Você vende para um amigo um IPod por R$100,00 (valor de mercado), só que você combina de entregar o mesmo só daqui a um mês. Então na data combinada você vai ter que ir em uma loja comprar um novinho e entregar pra ele, porque você já recebeu o dinheiro.

Então daqui 1 mês, vamos imaginar que o IPod na loja esteja valendo R$80,00. Você paga esse valor, entrega o mesmo para seu amigo e ainda ganhou R$20,00.

Agora imagina se na data de comprar, ele esteja valendo R$120,00 ? Você terá que comprar a R$120,00 e entregar pelo valor de venda de R$100,00, tendo um prejuízo de R$20,00.

Agora imagina que durante esse mês o preço do IPod suba sem parar, quanto mais sobe mais prejuízo você terá. E esse é o motivo que muita gente quebra querendo especular com opções.

Primeiro o cara acha que a ação vai cair o preço, depois pelo valor da opção ser baixo ele vende um caminhão cheio pra fazer um volume financeiro que ele ache legal de ganhar, e o mercado sobe, fazendo uma "quebra exponencial".

No post de Compra a seco nós demos um exemplo. Vamos ver o resultado hoje de como estaria o cara que comprou e o cara que vendeu:

Dados da Montagem da Operação:
VALE5 = R$ 56,24
VALEF56 = R$ 2,73
Data = 15/05/2008

Dados da Fechamento da Operação:
Data Atual = 4/6/2008
VALE5 = R$ 51,10
VALEF56 = R$ 0,26
DESVALORIZAÇÃO DA AÇÃO = -9,14%
DESVALORIZAÇÃO DA OPÇÃO = -90,48%

Resultado do Comprador:
Perdeu 90,48% do capital investido

Resultado do Vendendor:
Com a recompra da opção ele ganhou 90,48% do valor da venda.

Nesse exemplo, devido a queda do mercado o vendedor se deu bem. E o risco do comprador já estava em quase 100%.

Mas caso o mercado tivesse sido somente de alta o vendedor estaria chorando, pois seu risco estaria sendo ilimitado.

Por isso, muito cuidado com opções - especialmente vendas a seco.

Abraços.

Curso Candlestick - Parte 3.4: Corpo Real / Corpo Longo de Baixa

noreply@blogger.com (Kleyson Rios) — Thu, 29 May 2008 22:52:00 -0300

Como vimos para o candle longo de alta, vamos nessa aula ver o que significa o candle longo de baixa quando:

- se encontra no alto de uma tendência de alta;
- confirma uma resistência;
- rompe um suporte;
- funciona como uma área de resistência.

Análise da Alta das Ações da Nossa Caixa

noreply@blogger.com (Kleyson Rios) — Sat, 24 May 2008 21:53:00 -0300

Ontem a noite estava em casa vendo o jornal quando vi a notícia que as ações da Nossa Caixa (BNCA3) tinham subido mais de 30%, devido a notícia de que o Banco do Brasil estava negociando a compra do mesmo. Na mesma hora resolvi fazer uma análise do gráfico, que vou compartilhar agora com vocês.

Link da notícia que CVM irá investigar movimento das ações da Nossa Caixa antes do anúncio.

Post sobre o OBV

Curso Candlestick - Parte 3.3: Corpo Real / Corpo Longo como Área de Suporte

noreply@blogger.com (Kleyson Rios) — Mon, 19 May 2008 20:18:00 -0300

Na aula de hoje vamos ver como um candle longo de alta funciona como uma área de suporte.

E ver também o casamento do nível de suporte do candle junto com as retrações de fibonacci. As duas ferramentas trabalhando juntas com uma confirmando a outra.

* O conteúdo desse post não sugere nenhum tipo de operação, todos exemplos são apenas para fins educacionais.

Análise VALE5 - 15/05/2008

noreply@blogger.com (Kleyson Rios) — Thu, 15 May 2008 21:30:00 -0300

Usando conceitos do curso de candles e outras técnicas apresentadas aqui no blog, vamos analisar o gráfico da VALE5.

Após uma longa alta iniciada em 08/2007, a ação da VALE atingiu seu TH em R$ 56,69, de lá pra cá ela vem testando vários níveis da retração de fibonacci.

No pregão de ontem ela testou a resistência do TH, não tendo força para romper. Mas no pregão de hoje os preços romperam a resistência com um candle branco relativamente longo. Indicando um rompimento com um pouco mais de força.

O OBV também está no maior volume de acordo com o histórico, mostrando a existência de bastante capital esperto no papel. E papel com capital esperto é papel que tem força para subir.

Diante do cenário, o papel da VALE5 está livre para alcançar novos patamares de preços.

O texto reflete apenas a opinião pessoal do autor e não sugere nenhum tipo de operação.

Operação com Opção - Compra a Seco

noreply@blogger.com (Kleyson Rios) — Thu, 15 May 2008 13:30:00 -0300

- Operação especulativa

Se você acredita que o mercado vai subir você pode comprar opções, esperar que elas valorizem e depois vender ganhando como lucro a diferença entre a compra e venda.

Vamos pegar um exemplo real. Nesse momento que estou escrevendo temos o seguinte cenário:
VALE5 = R$ 56,24
VALEF56 = R$ 2,73

Então se você comprar essa opção e o mercado continuar a subir ela estará sempre ganhando valor.
Quando você compra uma opção você tem a seguinte relação:
Prejuízo máximo = ao valor pago.
Lucro máximo = infinito.

O prejuízo máximo é o valor que você pagou pois se no último dia de vida dessa série F a VALE estiver valendo menos de R$ 58,00 sua opção irá micar, que significa que ela deixará de existir e você terá perdido todo dinheiro que você gastou para comprá-la.

Se o preço estiver acima de R$ 58,00 você poderá exercer seu DIREITO de compra no valor do contrato ou então vender a opção pelo preço que ela está valendo.

Por exemplo, imagine que no dia do vencimento a VALE esteja valendo R$ 62,00. Como você é titular de opções de compra você tem o direito de comprá-la do vendedor no preço do contrato, ou seja, você irá exercer seu DIREITO de compra e o vendedor terá que vender ações da VALE5 a R$ 58,00 e no mesmo momento você poderá vender as mesmas por R$ 62,00 no mercado à vista, ficando a diferença como lucro pra você.

Agora o lucro máximo é infinito pois se o papel sobe a opção sempre subirá, então se o papel subir infinitamente ela continuará ganhando valor infinitamente.

Veja que nesse caso você está operando na tendência do papel. Mas operando tendência você pode comprar e vender ações, qual a diferença ? Não existe muita diferença, o que existe é a possibilidade de alavancagem financeira.

Curso Candlestick - Parte 3.2: Corpo Real / Longo Candle Branco Rompendo uma Resistência

noreply@blogger.com (Kleyson Rios) — Tue, 13 May 2008 21:51:00 -0300

Como vimos em aulas anteriores, quando um longo candle branco testa uma linha de suporte - como por exemplo uma média móvel, uma linha de tendência, uma linha de suporte - significa que o candle confirmou com uma maior força aquela área de suporte.

Logo, quando um longo candle branco rompe uma área de resistência, o rompimento se dá com uma maior força, transformando aquele nível de preços em um forte suporte.

Como podemos ver no gráfico, um longo candle branco rompeu uma área de resistência que já havia sido testada várias vezes, transformando agora o nível de 66.000 pontos em uma forte área de suporte, onde os preços terão um pouco mais de dificuldade para quebra-lá.