Atualizando o Motorola Defy para Android Gingerbread (2.3)

Meu cunhado e minha cunhada tem um Motorola Defy, da operadora Claro. Estão bastante satisfeitos com a operadora e com o plano 3G. Mas como nada é perfeito, a ROM desse celular é horrível; travamentos, atraso na resposta da tela (que chega a impossibilitar o uso de teclado Swype), problemas com o GPS (de forma a travar o Maps). Para resolver esse problema, sugeri o uso de uma ROM da CyanoGenMod, que é a ROM que utilizo em meu idoso Milestone.
Certa vez sugeri escrever o procedimento, mas existem diversos tutoriais na internet, inclusive na própria CyanoGen. Então vou recomendar o procedimento de atualização do Defy, porque esse foge aos padrões. A ROM ainda é beta, mas com certeza centenas de vezes melhor que a ROM da operadora. O site do processo é o SuperDicas, com alguns “SuperErros” que impossibilitariam o uso da ROM. Então, antes de ler o tutorial deles, atenha-se aos procedimentos que deverão ser tomados.

Passo 3 – O botão de volume deverá ser apertado para CIMA e não para baixo, como descreve esse passo especificamente. Para os demais, o botão é para baixo mesmo.

Passo 4 (segunda rodada) – Sim, o tutorial foi escrito em etapas e essas etapas usam os mesmos números para passos diferentes. Nesse passo 4 da segunda rodada está detalhado o procedimento para fazer rooting no celular. O programa se torna irresponsível em diversos momentos, mas quando aparecer o box para encerrar o programa, mande aguardar. Insista nos cliques do botão de rooting, mesmo que pareça não surtir efeito. Se após muitas tentativas continuar sem efeito, feche o programa, abra-o novamente e repita o procedimento. Se achar necessário, reinicie o aparelho, mas não desista do rooting ou não será possível seguir adiante.

O pacote RSD está com o link apontando para os drivers USB. Para baixar o RSD, utilize esse link.

Achei estranho isso não estar descrito no tutorial e pensei que fosse um processo novo, mas há um erro em não descrevê-lo. Após instalar todos os pacotes conforme descreve o procedimento (lembrando que você não deve permitir a inicialização do sistema antes disso), faça mais um reboot no boot manager e vá até a opção wipe cache partition, confirme. Retornando ao menu, vá até a opção wipe data/factory reset e confirme. Com isso, todos os dados de usuário serão resetados e aparecerá um wizard muito legal para configurar seu aparelho como se fosse recém-tirado da caixa, além de evitar infinitos reboots (‘infinitos’ no sentido de que seu celular não tornará a carregar o sistema jamais, exceto se faça os procedimentos de wipe).

Após isso, esteja a vontade para configurar parâmetros antes indisponíveis, como configurar a cor do led para cada tipo de notificação do sistema, rotacionamento 360º, pré-visualização de multiplos windows (“beliscando” o centro da tela, como se quisesse pegar o papel de parede) e uma quantidade enorme de outros ítens no menu aplicativos, na categoria Cyanogen. Seu Defy será um novo smartphone, pode acreditar!

Replicação Master-to-Master com MySQL + HA com heartbeat

Essa solução é muito bem aplicada em ambientes que necessitem alta disponibilidade para serviço web e banco de dados.
Se sua necessidade é baseada em MySQL a partir da versão 5.5, leia esse outro post sobre a replicação com MySQL 5.5 e faça a parte do heartbeat a partir deste próprio.

O ambiente é montado por 2 servidores X (indiferente do hardware utilizado). O Software é basicamente um LAMP + heartbeat rodando em Debian e o tempo de configuração deve ser de uns 10 minutos.

Existem diversos artigos na internet de ambas soluções aplicadas aqui, porém decidi escrever um artigo sobre o assunto para que eu mesmo possa utilizado na posteridade, quando não me lembrar mais do procedimento.

Primeiros passos
Além da instalação do sistema LAMP (Linux, Apache, PHP, MySQL) e heartbeat será necessário separar 3 IPs fixos, sendo 1 para cada servidor e 1 para utilização de IP virtual. O IP virtual é o IP que será divulgado; as solicitações vindas dos peers remotos terão como destino o IP virtual. Desse modo, a máquina que estiver disponível como master responderá às solicitações. Caso essa máquina se torne indisponível, a outra assumirá automaticamente o IP virtual e passará a responder as solicitações.

No exemplo, utilizarei os IPs 172.0.0.200, 172.0.0.201 e virtual 172.0.0.202. Todas as requisições devem ir para 172.0.0.202.

A base de dados se comunica por background, diretamente pelos seus respectivos IPs. Qualquer operação que seja feita em uma, imediatamente é replicada para a outra e vice-versa. É possível adicionar slaves também para possuir um backup extra, mas não fará parte deste artigo.

Os servidores envolvidos serão nomeados aqui (e preferencialmente utilize a mesma denominação em seu ambiente) como node01 e node02.

* Configurando o heartbeat
Os arquivos de configuração do serviço heartbeat ficam em /etc/ha.d. Alguns arquivos não existem, mas basta criá-los com o respectivo conteúdo.

/etc/ha.d/authkeys
Seu conteúdo:

auth 2
2 sha1 test-ha

/etc/ha.d/haresources
Nesse arquivo especifica-se o nome do servidor master seguido do IP virtual e do script de reload das variáveis de ambiente de trabalho necessárias de se recarregar. Esse script pode ter qualquer nome e deve ficar em /etc/init.d/ como um serviço. Seu conteúdo será explanado mais adiante.

node01 172.0.0.202 reload_environment.sh

/etc/ha.d/ha.cf
Esse arquivo contém as pré-definições do funcionamento do heartbeat.

#arquivo de debug
debugfile /var/log/ha-debug
#arquivo de log
logfile /var/log/ha-log
#nivel de log
logfacility local0
#tempo de tolerância
keepalive 2
#tempo para considerar como morto
deadtime 10
#tempo de warning
warntime 10
#diretiva utilizada em tempo de inicialização do heartbeat
initdead 30
#...
udpport 694
#unicast respectivo ao host oposto; 201 no node01, 200 no node02
ucast eth0 172.0.0.201
# O auto_failback retoma como master automaticamente quando se encontra em condições de fazê-lo. Deixá-lo como
#off fará com que retorne somente se o host que assumir como master se perca.
auto_failback off
# node nodename ... -- must match uname -n
node node01 node02
#um host para ping. No caso, o gateway da rede de exemplo.
ping 172.0.0.254

#opcional
respawn root /usr/lib/heartbeat/ipfail
apiauth ipfail gid=root uid=root
apiauth default gid=root
apiauth cl_status gid=root
/etc/hostname
O nome curto deve aparecer como node01 ou node02. Constate isso com hostname -s.

/etc/hosts
Não experimentei resolver os nomes de outra maneira, então deixo a recomendação de incluir os IPs reais dos hosts no arquivo de hosts:

172.0.0.200 node01
172.0.0.201 node02

/etc/network/interfaces

Configure apenas os IPs reais em ambos os hosts. Por exemplo:

iface eth0 inet static
address 172.0.0.200
netmask 255.255.255.0
network 172.0.0.0
broadcast 172.0.0.255
gateway 172.0.0.254

/etc/apache2/ports.conf
Nesse arquivo deve-se especificar o IP virtual, tal como abaixo:

NameVirtualHost 172.0.0.202:80
Listen 80
# SSL name based virtual hosts are not yet supported, therefore no
# NameVirtualHost statement here
Listen 443

/etc/init.d/reload_environment.sh
Se preferir, renomeie o arquivo a contento, lembrando que se alterado, não esqueça de mudar o nome também no arquivo haresources.

O conteúdo desse arquivo é para exemplo. No caso, estou fazendo HA para o Asterisk:

#! /bin/sh
# /etc/init.d/reload_environment.sh
#

# Some things that run always
touch /var/lock/reload_environment.sh

# Carry out specific functions when asked to by the system
case “$1″ in
start)
#para o asterisk
/usr/sbin/asterisk -rx “restart now”
#matar o script XXX
$(which kill) -9 $(ps ax|egrep ‘XXX.py’|egrep -v ‘grep’|awk ‘{print $1}’) 2>/dev/null
exit 0
;;
stop)
echo “Nothing to do”
;;
*)
echo “Usage: /etc/init.d/blah {start|stop}”
exit 1
;;
esac

exit 0

Adeque-o para sua necessidade.

Iniciando o HeartBeat
Feitas essas configurações, o serviço pode ser iniciado:
/etc/init.d/heartbeat start

Se tiver algum erro, verifique suas configurações, os logs e finalmente faça uma busca no google. Se tudo estiver perdido, escreva o problema nos comentários e __se__ realmente for algo que julgar válido, escrevo a resposta.

Em alguns momentos o IP virtual deverá subir na interface eth0 (que foi a utilizada nesse exemplo) do node01. Isso representa o sucesso da operação.

Se desejar fazer um teste com o HA, insira em /var/www um arquivo html com o nome do host. Com ambos os hosts em um mesmo switch, a partir de um client acesse o IP virtual e veja o nome de host que aparece; faça refreshs a vontade. Enquanto isso, peça a alguém que remova o cabo do node que estiver sendo exibido durante seus refreshs. O IP virtual subirá no outro node.

No arquivo ha.cf você poderá então mudar o tempo de vida conforme desejado, para mais ou para menos, mas tudo dependerá da aplicação que pretende rodar em seu ambiente. Fatores como qualidade de rede física e lógica também podem influenciar.

Configurando o MySQL para Master-to-Master
O MySQL é impressionante por sua facilidade de configuração. Além de estar toda concentrada no arquivo /etc/mysql/my.cnf, não é necessário instalar nenhum pacote adicional para a tarefa. Não estou certo de que posso ser claro na explicação dos parâmetros, mas seguramente é uma configuração funcional. Seu conteúdo:

#padrao
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
#
# * Basic Settings
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
#bind-address = 127.0.0.1
#
# * Fine Tuning
#
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 128K
thread_cache_size = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover = BACKUP
#max_connections = 100
#table_cache = 64
#thread_concurrency = 10
#
# * Query Cache Configuration
#
query_cache_limit = 1M
query_cache_size = 16M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
#log = /var/log/mysql/mysql.log
#
# Error logging goes to syslog. This is a Debian improvement 
#
# Here you can see queries with especially long duration
#log_slow_queries = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
# other settings you may need to change.

#configuracoes para o servico
#no node02 utilize 2 e no node01 utilize 1 no server-id
server-id = 2
replicate-same-server-id= 0
auto-increment-increment= 2
auto-increment-offset = 2
log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 500M

#bases que nao serao replicadas devem ser explicitamente ignoradas
binlog_ignore_db = mysql

#bases a replicar
binlog_do_db = asterisk
replicate-do-db = asterisk

binlog_do_db = base_2
replicate-do-db = base_2

binlog_do_db = base_3
replicate-do-db = base_3

binlog_do_db = base_n
replicate-do-db = base_n
#o master para o nodeX é o outro node
master-host = 172.0.0.201
#sugestao: replicar com o mesmo usuario e senha para facilitar a configuracao
master-user = replicador
master-password = escravo
master-connect-retry = 60

#
# * BerkeleyDB
#
# Using BerkeleyDB is now discouraged as its support will cease in 5.1.12.
skip-bdb

[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition

[isamchk]
key_buffer = 16M

#
# * IMPORTANT: Additional settings that can override those from this file!
# The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/

Terminada a configuração do my.cnf, deve-se ainda executar a permissão para o usuário de replicação. Algo como isto funciona bem:

mysql> grant all privileges on *.* to replicador@'%' identified by 'escravo';

Pode ser necessário (porque tenho certeza de que funcionou sem, mas já tive que fazê-lo) utilizar um comando para levantar o slave:

mysql> start slave;
A partir de então, pode-se testar fazendo um insert em qualquer um dos nodes e verificando sua inserção no outro e vice-versa. Alguns problemas podem ser resolvidos a partir desses documentos:

http://dev.mysql.com/doc/refman/4.1/pt/replication-problems.html

http://dev.mysql.com/doc/refman/4.1/pt/replication-faq.html

Alguns comandos também podem auxiliar em diagnósticos e informações, como:

show slave status\G;
show master status\G;
show processlist;

O comando show slave status\G deverá retornar em seu primeiro campo a informação:

Slave_IO_State: Waiting for master to send event

E mais abaixo, outras duas informações essenciais:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Infelizmente é inviável explicar todos os parâmetros, todos os comandos diagnósticos, ações a tomar em casos de falhas etc, mas ao menos você poderá iniciar um projeto de replicação com HA a partir de um ambiente funcional e os avanços dependerão apenas de você. 

Bonding – Juntando interfaces de rede no Linux

Descrição do recurso
Conforme descrito na documentação do kernel do Linux, o driver bonding é utilizado para agregar múltiplas interfaces de rede em uma interface lógica única. Seu comportamento depende da necessidade e da estrutura física da rede. Então, apesar de ser uma tarefa bastante simples e bem divulgada, dificilmente encontra-se um artigo que cite o melhor modo para cada condição.

Principais modos de configuração
Há dois modos principais de configuração do bonding, sendo soma do link oumodo backup, chamados de balance-rr (balance round robin) e active backuprespectivamente. Nesse link estão descritos absolutamente todas as configurações de bonding incluindo alguns exemplos de configuração distribuidos pelo arquivo, mas esse post tratará apenas dos modelos descritos anteriormente.

No modelo acima, um host soma duas interfaces físicas em uma interface lógica, que chamaremos de bond0. Uma das interfaces será conectada a um switch e a outra interface a outro switch. Nesse modelo explicitamente deseja-se tolerância a falhas, então baseado nisso pode-se assimilar esse modelo da infra-estrutura com o modo de configuração active-backup (1), devido ao fluxo de dados distinto, onde a segunda interface de rede entrará em ação somente em caso de falha da primeira.
* Se houver interconexão dos switches (ISL), é seguro optar por active-backup.
* Se os switches não forem interconectados e as redes forem completamente independentes, então deve-se utilizar o modo broadcast.

Vejamos agora outro modelo:

No modelo acima o destino de ambas as interfaces seguem por um mesmo caminho. Há tolerância a falha nesse modelo, mas é visível que se pode somar os links para fazer um melhor aproveitamento dos recursos em caso de fluxo intenso. Apesar dessa vantagem, há um custo para sua utilização, que é a recepção desordenada dos pacotes, forçando retransmissões.

Um tunning pode ser feito alterando net.ipv4.tcp_reordering (sysctl). A velocidade de reordenação depende de diversos fatores físicos (infra-estrutura) e ficaria extenso demais gerar hipóteses aqui.

Se houver tráfego de UDP, deve-se considerar que a aplicação possa receber os dados desordenadamente, caso contrário não é recomendado a utilização da soma do link para aumentar o throughput.
Por fim, para a utilização desse modelo é necessário que o switch esteja com as respectivas portas em ‘etherchannel’ ou ‘trunking’, dependendo da marca.

Utilizando o modo active-backup não é necessário nenhuma configuração no switch, porque a interface de bonding faz spoofing do MAC da interface utilizada como mestre e ambas chegarão aos switches com o mesmo MAC. Em modo active-backup não há risco de conflito na tabela ARP dos switches porque a interface escrava só se tornará ativa em caso de falha da outra interface.

Configurando bonding
Já fiz essa configuração em diferentes sistemas em algumas empresas; não há restrições de uso para distribuições baseadas em Debian ou RedHat, mas as configurações em arquivos mudam de uma plataforma para outra, então o exemplo utilizado servirá para ambas, com configuração através de comandos que podem ser colocados em um rc que carregue após o sistema. Em caso de OpenSuse, pode-se colocá-lo em /etc/init.d/after.local; em Debian em /etc/rc.local e em RedHat em /etc/init.d/rc.local. Além disso, exemplificarei a configuração em arquivos padrão do sistema Debian.

Primeiramente será necessário carregar o módulo bonding. Ele aceita diversos parâmetros. Sua carga pode (e preferencialmente DEVE) ser feita através do arquivo /etc/modules.conf. O alias bond0 é uma convenção, poderia ter outro nome mas é comumente configurado assim:

#modelo de rede 1
alias bond0 bonding
options bond0 mode=1 miimon=100 downdelay=200 updelay=200

O parâmetro mode especifica o modo de operação da interface; balance-rr (0), active-backup (1), broadcast (3) etc.

O parâmetro miimon especifica o intervalo de monitoramento do link em milisegundos. O valor 100 é recomendado na documentação do kernel. Se o valor for 0, não haverá monitoramento do link.

O parâmetro downdelay especifica o tempo para derrubar uma interface em caso de falha. Esse valor deve ser múltiplo do parâmetro miimon.

O parâmetro updelay especifica o tempo para levantar a interface escrava. O valor também deve ser múltiplo de miimon e preferencialmente idêntico ao valor de downdelay, mas nunca menor.

Para levantar o módulo manualmente, utilize:

modprobe bonding -o miimon=100 mode=1 downdelay=200 updelay=200

O segundo passo é levantar as interfaces de rede sem IP e a interface de bonding. As interfaces físicas não receberão IP porque haverá apenas 1 para ambas as interfaces e esse IP estará configurado na interface bond0, como descrito abaixo:

ifconfig eth0 0.0.0.0 up
ifconfig eth1 0.0.0.0 up
ifconfig bond0 10.0.0.2 netmask 255.255.255.0 up
#nesse ponto pode-se já configurar o gateway também. Ex.:
route add default gw 10.0.0.1
route add -net 172.0.0.0/24 gw 10.0.0.254
#etc

Na parte de configuração de interface, finaliza-se atribuindo as interfaces ao bonding bond0:

ifenslave bond0 eth0 eth1

Perceba que isso indica que duas interfaces fazem parte do bond0. Seria possível ter mais interfaces bonding, tudo depende da disponibilidade física e necessidade.

Configurando o /etc/network/interfaces do Debian
Em Debian, o arquivo controlador de interfaces é o /etc/network/interfaces. Em openSuse e RedHat as configurações são distribuidas em arquivos em /etc/syconfig/network-scripts/, tal como ifcfg-eth0 etc.

Se os comandos anteriores forem colocados em algum script de startup, tudo deve funcionar tal como feito manualmente e servirá para qualquer uma destas distribuições Linux, mas gosto de deixar tudo ajeitado no Debian:

auto bond0
iface bond0 inet static
  address 10.0.0.2
  netmask 255.255.255.0
  gateway 10.0.0.1
  bond-slaves none
  bond-mode active-backup
  bond-miimon 100
  bond-downdelay 200
  bond-updelay 200

auto eth0
iface eth0 inet manual
  bond-master bond0
  bond-primary eth0 eth1

auto eth1
iface eth1 inet manual
  bond-master bond0
  bond-primary eth0 eth1

Se por algum motivo quiser consultar as configurações do bonding via scripts (ou por qualquer outro motivo que seja), os dados se encontrarão em /sys/class/net/bond0/bonding/ . Por exemplo, o arquivo /sys/class/net/bond0/bonding/mode contém o modo de operação do bond0.

Basicamente, é isso; diversão garantida!