Linux

Ubuntu 12.04 LTS: Configurando Pentaho na inicialização

Posted on março 27, 2013. Filed under: Linux, Pentaho, Ubuntu | Tags:, , , , |

Introdução

O objetivo deste artigo é disponibilizar scripts de inicialização para os serviços do Pentaho BI Server e Pentaho Administration Console. Os scripts foram feitos para uso no Ubuntu Server 12.04 LTS.

Instalação do Pentaho

Recomendo o link abaixo para instalação do Pentaho BI Server no Ubuntu 12.04 LTS. Apesar do link estar se referindo ao Ubuntu Desktop, realizei a instalação normalmente em um Ubuntu Server.

http://akbarahmed.com/2012/05/24/install-pentaho-bi-server-4-5-on-ubuntu-12-04-lts-desktop/

Script init para o Pentaho BI Server

Criar o script de init abaixo em /etc/init.d/pentaho:
(PS: Configurar as variáveis de ambiente JAVA_HOME, JRE_HOME e PENTAHO_HOME de acordo com sua instalação)

#!/bin/bash
### BEGIN INIT INFO
# Provides: start-pentaho stop-pentaho
# Required-Start: networking
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Description: Pentaho BI Platform
### END INIT INFO

export JAVA_HOME="/usr/lib/jvm/jdk1.6.0_31"
export JRE_HOME="/usr/lib/jvm/jdk1.6.0_31/jre"
export PENTAHO_HOME="/opt/pentaho"

start(){
        echo "Iniciando aplicacao biserver"
        $PENTAHO_HOME/biserver-ce/start-pentaho.sh > /tmp/pentaho.out 2>&1
        echo "ok"
}

stop(){
        echo "recebi: $1"
        echo "Finalizando aplicacao biserver"
        $PENTAHO_HOME/biserver-ce/stop-pentaho.sh
        echo "ok"
}

case "$1" in
start)
        start $2
        ;;
stop)
        stop $2
        ;;
*)
        printf "\nUsage: $0 \n
                start | stop            : Inicia ou finaliza a aplicacao biserver\n"
        ;;
esac
exit 0

Instalando os links de init:

# update-rc.d pentaho defaults
 Adding system startup for /etc/init.d/pentaho ...
   /etc/rc0.d/K20pentaho -> ../init.d/pentaho
   /etc/rc1.d/K20pentaho -> ../init.d/pentaho
   /etc/rc6.d/K20pentaho -> ../init.d/pentaho
   /etc/rc2.d/S20pentaho -> ../init.d/pentaho
   /etc/rc3.d/S20pentaho -> ../init.d/pentaho
   /etc/rc4.d/S20pentaho -> ../init.d/pentaho
   /etc/rc5.d/S20pentaho -> ../init.d/pentaho

Script init para o Pentaho Administration Console

Criar o script de init abaixo em /etc/init.d/pentaho-adm:
(PS: Configurar as variáveis de ambiente JAVA_HOME, JRE_HOME e PENTAHO_HOME de acordo com sua instalação)

#!/bin/bash
### BEGIN INIT INFO
# Provides: start-pentaho-adm stop-pentaho-adm
# Required-Start: networking
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Description: Pentaho BI Platform Administration Console
### END INIT INFO


export JAVA_HOME="/usr/lib/jvm/jdk1.6.0_31"
export JRE_HOME="/usr/lib/jvm/jdk1.6.0_31/jre"

export PENTAHO_HOME="/opt/pentaho"

start(){
        echo "Iniciando aplicacao administration-console"
        cd $PENTAHO_HOME/administration-console && ./start-pac.sh > /tmp/pentaho_console.out 2>&1 &
        echo "ok"
}

stop(){
        echo "recebi: $1"
        echo "Finalizando aplicacao administration-console"
        cd $PENTAHO_HOME/administration-console && ./stop-pac.sh
        echo "ok"
}

case "$1" in
start)
        start $2
        ;;
stop)
        stop $2
        ;;
*)
        printf "\nUsage: $0 \n
                start | stop : Inicia ou finaliza o administration console\n\n"
        ;;
esac
exit 0

Instalando os links de init:

# update-rc.d pentaho-adm defaults
 Adding system startup for /etc/init.d/pentaho-adm ...
   /etc/rc0.d/K20pentaho-adm -> ../init.d/pentaho-adm
   /etc/rc1.d/K20pentaho-adm -> ../init.d/pentaho-adm
   /etc/rc6.d/K20pentaho-adm -> ../init.d/pentaho-adm
   /etc/rc2.d/S20pentaho-adm -> ../init.d/pentaho-adm
   /etc/rc3.d/S20pentaho-adm -> ../init.d/pentaho-adm
   /etc/rc4.d/S20pentaho-adm -> ../init.d/pentaho-adm
   /etc/rc5.d/S20pentaho-adm -> ../init.d/pentaho-adm
Ler Post Completo | Make a Comment ( None so far )

Dicas do comando find

Posted on setembro 3, 2012. Filed under: Linux, Tips | Tags:, |

Introdução

Neste artigo vamos informar alguns exemplos práticos do comando find. São exemplos que resolvem problemas que temos no dia a dia. Voltado para quem trabalha com administração de servidores Linux.

  • Encontrando arquivos que estão com problema de encoding no nome.
  • find . ! -regex '.*'

    Esse interessante comando do find, apesar de não ser específico para isso, irá listar todos arquivos que estão com erro de encoding no nome. Para mais informações como corrigir o encode do nome do arquivo, acesse:
    http://selectoid.wordpress.com/2009/07/23/a-commandline-preciousness-for-converting-filename-encoding-in-linux-convmv/

  • Removendo arquivos que foram criados/modificados a mais de x dias. No caso abaixo, serão removidos os arquivos modificados/criados à mais de 30 dias.
  • find . -type f -mtime +30 -exec rm -f {} \;
  • Procurando um pattern (require_once) dentro de arquivos que possuem a extensão .php, entrando nos níveis de diretório abaixo, de forma recursiva.
  • find . -name "*.php" -exec grep -Hi "require_once" {} \;
  • Esta dica é para você que precisa limpar um diretório que contém muitos arquivos. Usar somente o comando rm -f * no diretório irá gerar erro de lista de arquivos muito grande. A alternativa é usar o comando find combinado com o comando xargs, que irá limpar o diretório completo. O xargs irá passar os arquivos para o comando rm por partes.
  • find . -type f -print0 | xargs -0 rm
  • Procurando arquivos em apenas 2 níveis de sub-diretórios.
  • find . -maxdepth 2
  • Procurando arquivos/diretórios que possuem determinado dono de arquivo.
  • find . -user www-data
  • Procurando arquivos/diretórios que possuem determinado grupo de arquivo.
  • find . -group www-data
  • Procurando arquivos/diretórios que possuem determinado permissão.
  • find . -perm 644
  • Fazendo busca somente em diretórios.
  • find . -type d
  • Fazendo busca somente em arquivos.
  • find . -type f

Conclusão

É claro que esses exemplos não devem ser utilizados de forma rígida. O comando find é muito flexível, portanto fique livre para combinar seus parâmetros. As dicas acima podem ajudar em muitas situações diferentes.

Ler Post Completo | Make a Comment ( None so far )

Upgrade do Ubuntu Server para 12.04 LTS

Posted on julho 18, 2012. Filed under: Linux, Ubuntu | Tags:, , |

Introdução

Neste artigo vamos explicar o processo à ser realizado para fazer o upgrade no Ubuntu server, para à última versão, 12.04 LTS (Precise). Precisei fazer o upgrade do ubuntu server, da versão 10.10 (Maverick) para a útlima, 12.04 LTS (Precise). No caso, fiz o upgrade primeiramente para a versão 11.04 (Natty), depois para a versão 11.10 (Oneiric) e finalmente para 12.04. Pelo que andei pesquisando, pude observar que alguns textos dizem que é possível fazer o upgrade diretamente de qualquer versão para à última LTS. Porém não quis arriscar em servidores de produção. Portanto, fiz a atualização de forma gradual.

Além do processo de upgrade, procurei passar para vocês, como resolvi alguns erros que apareceram durante o procedimento. Vale salientar, que este artigo se refere somente à versão server do Ubuntu. A versão desktop pode ser feita através de um procedimento diferente.

Procedimento

  • Logar no Ubuntu server como root
  • update no apt-get
  • # apt-get update

  • Instalação/Atualização do update-manager-core
  • # apt-get install update-manager-core

  • Editar o arquivo /etc/update-manager/release-upgrades e alterar Prompt=lts para Prompt=normal:


    [DEFAULT]
    # Default prompting behavior, valid options:
    #
    # never - Never check for a new release.
    # normal - Check to see if a new release is available. If more than one new
    # release is found, the release upgrader will attempt to upgrade to
    # the release that immediately succeeds the currently-running
    # release.
    # lts - Check to see if a new LTS release is available. The upgrader
    # will attempt to upgrade to the first LTS release available after
    # the currently-running one. Note that this option should not be
    # used if the currently-running release is not itself an LTS
    # release, since in that case the upgrader won't be able to
    # determine if a newer release is available.
    Prompt=normal

  • Iniciar o processo de upgrade
  • # do-release-upgrade

    Observações:

    • Caso esteja atualizando via ssh, será alertado sobre o risco de ocorrer algum problema durante o upgrade e você perder a conexão. De qualquer forma, um ssh alternativo é aberto na porta 1022. Sempre que possível, executar o upgrade diretamente no terminal físico do servidor.
    • Durante o upgrade, você será alertado sobre alguns processos que precisam ser re-inciados devido à atualização de pacotes. Pode autorizar tranquilamente a re-inicializaçao desses processos.
    • Alguns pacotes, ao serem atualizados para novas versões (apache, php, samba, etc.), terão novos arquivos de configuração. O mecanismo de upgrade do Ubuntu irá perguntar o que deseja fazer com os novos arquivos. (Manter o atual, sobrescrever com o novo, fazer um diff, etc.) Eu aconselho a sempre instalar o arquivo de configuração da nova versão do pacote. E depois do upgrade ajustar os parâmetros de acordo com sua necessidade. Portanto, antes do upgrade, faça um backup dos seus principais arquivos de configuração. Exemplo: /etc/php5/apache/php.ini, /etc/apache2/apache2.conf, /etc/samba/smb.conf
    • Durante o upgrade, normalmente para a versão 11.10 (Oneiric), o grub acusa que precisa ser instalado novamente e te mostra as opções dos possíveis locais onde pode ser instalado. Aconselho a instalar no MBR do seu disco (ex: /dev/sda).
    • Durante o upgrade, passando pela versão 11.10 (Oneiric), existe um bug que faz o comando fuser usar 100% de CPU, fazendo fork de forma incontrolada. Percebi esse problema, pois o sistema acusa direto que não conseguia alocar memória. O fuser é disparado por um processo do php que roda no crontab. Antes de continuar com o upgrade para à versão 12.04, para não ter imprevistos, faça a devida mudança no arquivo /etc/cron.d/php5:

      Trocar a linha:
      09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete

      Para:
      09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete

    • Em um dos servidores que fiz o upgrade, tive um problema no terminal físico dele. A tela ficava em preto e não conseguia visualizar nada nela. Fiz diversas mudanças em arquivos de configuração do grub e do console. As duas configurações abaixos resolveram o meu problema:

      No arquivo /etc/default/grub, trocar a linha:
      GRUB_CMDLINE_LINUX_DEFAULT="quiet"

      Para:
      GRUB_CMDLINE_LINUX_DEFAULT="quiet nomodeset"

      No arquivo /etc/default/console-setup, trocar a linha:
      FONTFACE="VGA"

      Para:
      FONTFACE="Fixed"

Ler Post Completo | Make a Comment ( 2 so far )

Alta disponibilidade no Linux com heartbeat

Posted on abril 17, 2012. Filed under: Linux | Tags:, , |

Introdução

Neste artigo vamos demonstrar como configurar o software heartbeat com a finalidade de criar um sistema de Alta disponibildade no Linux. Vamos usar dois servidores numa solução master/slave onde o heartbeat ficará monitorando a disponibilidade dos nós configurados. Este artigo, de certa forma, serve como um complemento para o artigo Replicação Master-Master no MySQL.

Cenário

Dois servidores:

servidor1 192.168.10.1
servidor2 192.168.10.2

Ip Vip: 192.168.10.10

Para exemplo deste artigo vamos usar como nome dos servidores: “servidor1” e “servidor2”. Os nomes devem corresponder aos nomes das próprias máquinas (hostname).

O IP Vip corresponde ao ip que será compartilhado entre os dois servidores. Através do IP vip na verdade estaremos acessando o servidor que estiver como master no momento do acesso. Esse comportamento será controlado pelo heartbeat.

Insira as linhas abaixo no arquivo /etc/hosts nos dois servidores:

192.168.10.1 servidor1
192.168.10.2 servidor2

Para configurar o heartbeat de forma eficaz, dedique uma interface de rede nos dois servidores que serão conectados diretamente através de um crossover. É através dessa interface que o heartbeat determinará a disponiblidade dos nós.

Instalando heartbeat

A instalação do heartbeat em sistemas baseados em debian é bem simples:

$ sudo apt-get install heartbeat

Configuração do hearbeat

1. Arquivo /etc/ha.d/ha.cf

O conteúdo deve ser idêntico nos dois servidores:

use_logd yes
keepalive 1
deadtime 10
warntime 5
initdead 120
bcast eth4
node servidor1
node servidor2
auto_failback off

Descrição dos parâmetros:

use_logd yes – habilita log do heartbeat.
keepalive 1 – tempo em segundos entre um “heartbeat” e outro.
deadtime 10 – Tempo que o heartbeat aguarda por uma resposta até determinar que o nó esta morto.
warntime 5 – Tempo que o hearbeat aguarda por uma resposta para disparar um aviso de atraso (late warning).
initdead 120 – Quando você reinicia todas as máquinas do cluster ao mesmo tempo, pode haver uma diferença de tempo entre as máquinas até que subam todos os serviços. Esse parâmetro cuida dessa situação. Esse tempo é contado somente quando o heartbeat inicia o seu serviço.
bcast eth4 – eth4 seria a interface usada pelo heartbeat para o envio de broadcast. É através dessa interface que o heartbeat ficará “pingando” os outros nós do cluster. Normalmente esta interface é cross. Pode ser que o valor desse parâmetro mude de servidor para servidor dependendo do nome da interface que foi usada no cross.
node – nomes dos servidores presentes no cluster.
auto_failback off – Com o auto_failback on, quando ocorre uma queda no primeiro nó (master neste momento), o segundo nó assume como master. Quando o primeiro nó voltar da queda, o segundo nó passa o master para o nó 1 novamente. Com a opção off, o primeiro nó ao voltar da queda sobe como slave.

2. Arquivo /etc/ha.d/authkeys

Este arquivo deve ser idêntico para todos os servidores no cluster. Ele controla a autenticação do heartbeat. O dono do arquivo deve ser o root com a permissão 600. No exemplo abaixo, “qualquertexto” pode ser qualquer string da sua escolha, com tanto que esteja idêntica em todos servidores. Além do sha1, outros tipos de autenticação podem ser md5 e crc.

auth 1
1 sha1 qualquertexto

3. Arquivo /etc/ha.d/haresources

servidor1 192.168.10.10 apache2

Este arquivo também deve ser idêntico em todos os servidores do cluster. O primeiro parâmetro é o hostname do nó que você considera como master primário. Ao subir o heartbeat na primeira vez, esse será o nó que assumirá como master.

O segundo parâmetro é o ip vip do cluster, ou o ip “compartilhado” que estará sempre ativo independente do nó que estiver como master. Esse é o ip que você passará para outros servidores/serviços que irão acessar o “cluster”.

O terceiro e consequentes parâmetros são os nomes dos serviços que o heartbeat irá controlar. No caso apache2, como mostra o exemplo abaixo, estará ligado somente no nó master. Nos outros nós estarão desligados. Neste caso, quem controla o start/stop do serviço não será mais o linux através do rc.d e sim o heartbeat. Portanto, todos os serviços configurados no heartbeat devem ser eliminados da inicialização do Linux (rc.d).

PS: O script start/stop do serviço continua no init.d, deve ser removido somente da inicialização (rc.d).
Exemplo:

# update-rc.d -f apache2 remove

Você pode adicinar quantos serviços forem necessários para o devido funcionamento do cluster. Uma exemplo de serviço, seria um script que fica sincronizando arquivos de configuração entre os nós do cluster através de rsync. Quando você muda a configuração em um nó ele automaticamente replica para o outro nó. Exemplo:

servidor1 192.168.10.10 apache2 synconfig

No caso você deve criar um serviço chamado synconfig em /etc/init.d ! Ele irá chamar um daemon que fica sincronizando arquivos através de rsync. O serviço deve receber pelo menos os parâmetros start e stop.

Espero ter ajudado com essa contribuição. Fiquem livres para comentários e boa sorte.

Ler Post Completo | Make a Comment ( 3 so far )

Replicação Master-Master no MySQL

Posted on março 23, 2012. Filed under: Linux, MySQL | Tags:, , , |

Introdução

Neste artigo vamos demonstrar como configurar replicação Master-Master entre dois servidores MySQL. Este tipo de replicação normalmente é usado em um sistema de failover/cluster.

Preparando

O primeiro passo é sincronizar os bancos de dados, utilizados na replicação, entre os dois servidores do MySQL. Podemos usar o mysqldump nesta tarefa.

No servidor A:
# mysqldump -u root -p --databases base1 base2 > servidorA-dump.sql

No servidor B:
# mysql -u root -p < servidorA-dump.sql

Vamos assumir os seguintes endereços IPs para os servidores:

Servidor A: 192.168.0.1
Servidor B: 192.168.0.2

Configurando Permissões de Usuário

O processo de replicação do MySQL exige uma conexão ativa entre os dois servidores em ambos os lados. É preciso definir um usuário/senha para essa conexão.

No servidor A:
GRANT ALL PRIVILEGES ON *.* TO replicacao@192.168.0.2 IDENTIFIED BY 'repl123' WITH GRANT OPTION;

No servidor B:
GRANT ALL PRIVILEGES ON *.* TO replicacao@192.168.0.1 IDENTIFIED BY 'repl123' WITH GRANT OPTION;

Perceba que setamos os pervilégios do usuário replicacao para todos os bancos de dados no MySQL. Porém você pode definir somente as bases que serão incluídas na replicação ao invés de incluir todas bases.

Configurando o MySQL

As configurações abaixo devem ser incluídas na seção [mysqld] do my.cnf

Servidor A:

server-id = 1
auto-increment-increment = 2
auto-increment-offset = 1

log-bin
binlog-do-db = base1

master-host = 192.168.0.2
master-user = replicacao
master-password = repl123
master-port = 3306
master-connect-retry = 60

Servidor B:

server-id = 2
auto-increment-increment = 2
auto-increment-offset = 2

log-bin
binlog-do-db = base1

master-host = 192.168.0.1
master-user = replicacao
master-password = repl123
master-port = 3306
master-connect-retry = 60

A definição dos parâmetros auto-increment-increment e auto-increment-offset evitam colisão entre campos auto_increment. Mantenha o mesmo valor no campo auto-increment-increment para os dois servidores. O campo auto-increment-offset mantenha sequencialmente entre os servidores. No caso, 1 e 2.

O campo server-id também deve ser único entre os dois servidores. No caso, 1 e 2.

No exemplo de configuração acima estamos replicando somente o banco chamado base1. Caso precise replicar mais de uma base de dados, você pode inserir quantas linhas do parâmetro binlog-do-db forem necessárias:

binlog-do-db = base1
binlog-do-db = base2
binlog-do-db = base3
...

Caso você não especifique nenhum parâmetro binlog-do-db, todas as base de dados serão replicadas. Você tem também a opção de especificar o parâmetro binlog-ignore-db para ignorar quais base de dados não serão replicadas. É o processo inverso ao do parâmetro binlog-do-db:

binlog-ignore-db = mysql
binlog-ignore-db = information_schema

Iniciando a replicação

Reinicie o MySQL nos dois serviores:
# /etc/init.d/mysql restart

Neste momento a replicação deve ter iniciado. Se por algum motivo não tiver sido iniciado (Verificar erro no arquivo de log do mysql). Entre nos dois servidores e execute o comando:

mysql> start slave

Testando

Entre no MySQL nos dois servidores e execute o comando:
mysql> show slave status\G

Verifique os parâmetros Slave_IO_Running e Slave_SQL_Running. Ambos devem estar com o valor “YES”. Caso não esteja, refaça o processo.

Outro teste importante, é fazer alterações na base de um servidor e verificar se a mudança foi replicada para o outro servidor e vice-cversa.

Conclusão

Configurar uma replicação master-master no mysql é relativamente simples conforme demonstrado neste artigo. Outros ambientes de replicação também não são complicados. Com poucos ajustes na configuração acima você consegue adicionar mais que 2 servidores na replicação de master para master. Espero que tenha ajudado. Obrigado.

Ler Post Completo | Make a Comment ( 13 so far )

Linux, Instalando um novo Kernel através de Livecd

Posted on março 16, 2012. Filed under: Linux, Tips | Tags:, , , , |

Introdução

Existem certas situações que precisamos atualizar o kernel do sistema devido à problemas no boot. No meu caso, após restaurar um sistema de uma máquina antiga para um servidor mais novo, através de uma imagem dd, tive problemas para bootar o sistema no novo servidor devido ao kernel do sistema antigo não identificar o novo hardware.

Para solucionar essa questão, tive que instalar um novo kernel do Linux no servidor novo. Para ajudar utilizei um Livecd do Ubuntu. Segue abaixo o procedimento que usei para instalar o novo kernel.

Procedimento

  • Bootar o Livecd do Ubuntu.
  • Instalação de um novo kernel no livecd.
  • $ sudo apt-get update
    $ sudo apt-get install linux-image

    Somente com o boot do livecd não temos todos os arquivos do kernel disponíveis em /boot. Para isso instalamos um novo kernel dentro do livecd. Após a instalação acima, o importante é verificar que o arquivo vmlinuz-<versao kernel> existe no diretório /boot e os módulos do kernel dentro de /lib/modules/<versao kernel>.

    Pode ser que ocorra um erro nesse processo de instalação do kernel no livecd. Ignore o erro e continue o processo, pois o que interessa são os arquivos vmlinuz e os módulos do kernel. (Mesmo com o erro eles são instalados corretamente).

  • Montando a partição de boot.
  • $ sudo mkdir /mnt/boot
    $ sudo mount /dev/sda1 /mnt/boot

    No caso acima o /dev/sda1 é a partição onde estão os arquivos de kernel do seu servidor e do gerenciador de boot do grub. É nesse diretório que vamos instalar o novo kernel.
    Lembre-se que o acesso às partições variam de acordo como esta instalado o seu Linux.

  • Montando a partição raiz.
  • $ sudo mkdir /mnt/raiz
    $ sudo mount /dev/sda2 /mnt/raiz

    No caso acima o /dev/sda2 é a partição root do seu sistema. Precisamos montar essa partição para copiar os módulos do novo kernel.
    Lembre-se que o acesso às partições variam de acordo como esta instalado o seu Linux.

  • Copiando os arquivos
  • $ sudo cp /boot/vmlinuz-<versao kernel> /mnt/boot/
    $ sudo cp /boot/System.map-<versao kernel> /mnt/boot/
    $ sudo cp -a /lib/modules/<novo versao kernel> /mnt/raiz/lib/modules/

    Copiando a imagem do kernel, o System.map e os módulos, respectivamente, para os diretórios do seu servidor Linux.

  • Criando o initrd
  • Temos que criar um novo initrd para o novo kernel. Vamos aproveitar o initrd do kernel atual do seu sistema Linux para criar o novo. O initrd vai ajudar o novo kernel montar corretmente a partição root do seu Linux.
    Perceba que removemos os módulos do kernel atual que esta no initrd antes de copiar os módulos do kernel novo.

    $ sudo mkdir ~/initrd
    $ cd ~/initrd
    $ sudo gzip -dc /mnt/boot/initrd.img-<versao kernel atual> | cpio -id
    $ sudo rm -rf lib/modules/<versao kernel atual>
    $ sudo cp -a /lib/modules/<novo versao kernel> lib/modules/
    $ find . | cpio --quiet --dereference -o -H newc | gzip -9 > /mnt/boot/initrd-<novo versao kernel>

  • Criando nova entrada no menu do grub
  • Para concluir nosso processo, vamos criar uma nova entrada no menu.lst do grub para que seja possível bootar o novo kernel. Edite o arquivo /mnt/boot/grub/menu.lst e inclua uma nova opção no menu:

    title Novo Kernel
    root (hd0,0)
    kernel /vmlinuz-<novo versao kernel> root=/dev/sda2 ro quiet
    initrd /initrd.img-<novo versao kernel>

  • Bootando o novo kernel
  • Pronto, você já esta pronto para testar o novo kernel e bootar corretamente o seu sistema Linux. Desmonte as partições e reinicie o sistema, dessa vez, boote sem o livecd. No menu do grub escolha a nova opção e boa sorte!

    $ sudo umount /mnt/boot/
    $ sudo umount /mnt/raiz/
    $ sudo shutdown -r now

  • Referências
  • http://askubuntu.com/questions/94156/installing-with-a-different-kernel
    http://www.indiangnu.org/2009/how-to-create-editextract-initrd-in-ubuntudebian-and-redhatfedora-linux/

Ler Post Completo | Make a Comment ( 2 so far )

Erro ao tentar instalar PHP oci8 no Ubuntu: /usr/bin/ld: cannot find -lclntsh

Posted on agosto 5, 2011. Filed under: Linux, Oracle, PHP |

Utilizei o link abaixo para configurar o php para acessar Oracle, somente modo client, no Ubuntu Server:
https://help.ubuntu.com/community/PHPOracle

Porém na hora de instalar o módulo oci8 para php, obtinha o erro abaixo:

$ sudo pecl install oci8
...
libtool: link: cc -shared  .libs/oci8.o .libs/oci8_lob.o .libs/oci8_statement.o .libs/oci8_collection.o .libs/oci8_interface.o   -L/usr/local/lib/instantclient_11_2 -lclntsh  -Wl,-rpath -Wl,/usr/local/lib/instantclient_11_2   -Wl,-soname -Wl,oci8.so -o .libs/oci8.so
/usr/bin/ld: skipping incompatible /usr/local/lib/instantclient_11_2/libclntsh.so when searching for -lclntsh
/usr/bin/ld: cannot find -lclntsh
collect2: ld returned 1 exit status
make: *** [oci8.la] Error 1

Para resolver o problema é simples: Como estava seguindo o link do HowTo baixei o instantclient para Linux versão x86, porém meu servidor é 64bits, portanto deve ser instalado o pacote do instantclient para Linux x86-64 e problema resolvido.

http://www.oracle.com/technetwork/topics/linuxx86-64soft-092277.html

Ler Post Completo | Make a Comment ( None so far )

Tuning Apache 2.x

Posted on julho 19, 2011. Filed under: Linux, Tuning |

O objetivo deste artigo é ajudar você a melhorar o desempenho do seu servidor web Apache. Da versão 1.3 para versão 2.x aconteceram diversas melhorias relacionadas ao desempenho. Porém ainda é possível melhorar ainda mais a perfomance manipulando alguns parâmetros de configuração. O Objetivo aqui é abordar os principais parâmetros de configuração que possam influenciar diretamente na perfoamance.

Hardware

O principal fator no hardware que afeta a perfomance do Apache é memória. Monitore seu servidor para que ele nunca precise utilizar memória da swap. Você pode controlar a quantidade de memória utilizada pelo servidor através do parâmetro MaxClientes como veremos mais adiante. Além disso, procure sempre ter placas de redes, discos e cpus mais rápidos possíveis.

AllowOverride

Caso você esteja utilizando a solução AllowOverride junto com .htaccess, o Apache irá tentar abrir o arquivo .htaccess em cada requisição efetuada para o servidor prejudicando a perfomance. Por exemplo, caso você utilize:

DocumentRoot /var/www
<Directory />
  AllowOverride All
</Directory>

Ao chegar uma requisição para /index.html, o Apache irá tentar abrir os arquivos /.htaccess, /var/.htaccess e /var/www/.htaccess em todas requisições recebidas. Para evitar essa sobrecarga no servidor, se possível, desabilite a opção AllowOverride:

DocumentRoot /var/www
<Directory />
  AllowOverride None
</Directory>

Procure transportar toda configuração que você tiver dentro dos arquivos .htaccess para a configuração principal do apache ou virtual host. Por exemplo, caso você tenha a configuração no arquivo /var/www/protegido/.htaccess:

Deny from all

Transportando para o virtual host na configuração do apache:

<Directory "/var/www/protegido/">
  Deny from all
</Directory>

ExtendedStatus

Caso esteja usando mod_status para monitorar os processos do apache garanta que a opção ExtendedStatus esteja Off caso contrário o apache irá realizar diversas chamadas adicionais no sistema para cada requisição recebida.

<Location /server-status>
  SetHandler server-status
  ExtendedStatus Off
  Order deny,allow
  Deny from all
  Allow from localhost ip6-localhost
</Location>

SymLinks

A opção FollowSymLinks diz ao apache para seguir todos os links simbólicos do diretório. Caso essa opção esteja Off o Apache irá executar processos extras para verificar se o diretório ou arquivo não é um link simbólico. Portanto deixe essa opção sempre habilitada quando possível:

DocumentRoot /www/htdocs
<Directory />
  Options FollowSymLinks
</Directory>

Caso necessite de uma segurança maior e queira usar a opção SymLinksIfOwnerMatch ao invés da FollowSymLinks lembre-se que téra um custo maior nesse caso, pois a opção SymLinksIfOwnerMatch fará com que o apache verifique se o usuário dono do link corresponde ao mesmo usuário dono do destino do link. Então use-a com critério. Outra opção é a configuração abaixo, que faz com que a utilização SymLinksIfOwnerMatch seja menos custosa:

DocumentRoot /www/htdocs
<Directory />
  Options FollowSymLinks
</Directory>

<Directory /www/htdocs>
  Options -FollowSymLinks +SymLinksIfOwnerMatch
</Directory>

Essa última configuração evita checagens extras no DocumentRoot.

KeepAlive

A opção KeepAlive permite que o apache trabalhe com conexões persistentes, ou seja, é possível que milhares de requisições sejam tratadas em uma mesma conexão TCP. Habilitar essa opção reduz significativamente a carga do sistema.

Segue abaixo a configuração para ser inserida no arquivo de configuração do Apache, habilitando o KeepAlive:

KeepAlive On
MaxKeepAliveRequests 1000
KeepAliveTimeout 3

A diretiva MaxKeepAliveRequests determina o número máximo de requisições permitidas para uma conexão persistente. Defina um valor alto para uma melhor perfomance.

A diretiva KeepAliveTimeout determina o número de segundos que o Apache irá aguardar por uma subsequente requisição antes de fechar a conexão persistente. Defina para um valor pequeno. Valores altos poderão prejudicar a perfomance. Quanto maior o valor, maior o número de processos ficarão ocupados esperando por requisições enquanto não chega no timeout especificado.

MaxClients

A opção MaxClients determina o número limite de conexões simultâneas tratadas pelo Apache. Caso a conexão não possa ser tratada, pois chegou no limite máximo de conexões simultâneas, a conexão será colocada em uma fila. Essa diretiva influencia diretamente na performance do servidor. Caso seja definida um número pequeno, poderá estar consumindo pouco recurso do servidor, deixando-o ocisoso. Setar para um valor muito alto, poderá consumir 100% dos recursos, principalmente memória. Uma regra para calcular um número ideal para essa diretiva, é determinar a média do tamanho de um processo do apache, através de um comando como o top, e dividir pela quantidade de memória disponível, deixando, é claro, na suas contas, uma quantidade de memória para outros processos.

Segue a equação:

MaxClients ≈ (RAM - qtde memória para outros processos)/(média do processo apache)

Para obter quantidade de memória disponível no sistema: (Verificar -/+ buffers/cache: para obter quantidade de memória livre).

# free -m

Para ajudar a calcular o tamanho médio do processo do apache, pode utilizar top, ou o comando ps. Segue o comando ps abaixo para ajudar:

# ps -ylC apache2 --sort:rss

Espeque que alguma dessas dicas possa tê-lo ajudado a tornar seu apache mais rápido. Abraço!

Ler Post Completo | Make a Comment ( None so far )

firefox – ssl_error_rx_unexpected_change_cipher

Posted on outubro 6, 2010. Filed under: Firefox, Linux |

Existe um bug no OpenSSL que gera o erro “ssl_error_rx_unexpected_change_cipher” no Browser. Verifiquei que este erro ocorre indisponibilidade no Firefox, ou seja, pelo Firefox você não consegue navegar no site por https que esta usando a versão do OpenSSL com o bug. No IE e outros navegadores você consegue navegar no site normalmente.

Para corrigir este problema em sites rodando Apache, adiciona a linha abaixo na sessão de SSL do arquivo de configuração do Apache:

SSLSessionCache nonenotnull

A diretiva de configuração tem que estar fora da sessão de VirtualHost

Para maiores informações sobre o bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=430703

Ler Post Completo | Make a Comment ( None so far )

Lentidão na cópia de arquivos por NFS

Posted on agosto 27, 2010. Filed under: Linux |

Recentemente precisei criar uma forma de atualização de dados entre servidores. Para acessar as informações do servidor remoto utilizei o sistema de arquivos de rede chamado NFS ou Network File System. Não entrarei em detalhes sobre o funcionamento do NFS, gostaria apenas de informar como resolvi um problema de lentidão na cópia de arquivos de um servidor para outro. O Linux utilizado nos exemplos foi o Ubuntu Server.

Primeiramente, configurei no arquivo /etc/exports o diretório que gostaria de exportar através do nfs para os outros servidores. Minha intenção era que os servidores “clientes” tivessem acesso para gravar e permissão de root no compartilhamento nfs. A proposta do compartilhamento é para que os servidores “clientes” realizem cópias de vários arquivos para o servidor. Portanto, inicialmente meu arquivo /etc/exports ficou da seguinte maneira:

/apps ip_cliente(rw,no_root_squash)

Até aqui tudo bem, consegui montar o diretório nos servidores “clientes” e rodar os scripts de cópia. Porém percebi que o tempo que levava para cópiar os arquivos estava fora do normal. Estava muito lento. Pesquisando sobre nfs achei uma informação que foi muito util para resolver o meu problema. Duas opções que melhoraram drasticamente o desempenho da cópia foram os seguintes:

  • no_subtree_check : Habilitar essa opção influência no modo como os arquivos dentro do diretório exportado são tratados. O padrão do nfs é ter o “subtree_check” habilitado. Dessa forma todos arquivos requisitados no diretório são checados se os mesmos pertencem ao diretório exportado. Para desabilitar a checagem utilize a opção “no_subtree_check”. Como são muitos arquivos sendo requisitados dentro do diretório exportado, usar essa opção melhora a velocidade na transferência dos arquivos.
  • async : Com essa opção habilitada, a resposta da requisição é retornada antes dos dados serem gravados em disco, aumentando dessa forma o desempenho na transferência dos arquivos.

Para finalizar, vejam como ficou o /etc/exports:

/apps ip_cliente(rw,no_root_squash,async,no_subtree_check)

Ler Post Completo | Make a Comment ( 1 so far )

« Entradas Anteriores

Liked it here?
Why not try sites on the blogroll...