Em Novembro de 2008 eu fiz esse post aqui sobre a criptografia dos discos do Daniel Dantas e disse:

“4-) [Eu acho que esse vai acontecer]: A NSA aceita o desafio, dá uma olhada no abacaxi e fala – tipo um mineiro com um fio de palha nos beiços: É. Vai dar não senhor.”

Bom… dito e feito.

Related posts

• Criptografia vs NSA (2)
• Um pouco de política (0)
• Merece, né? (4)
• Dois pesos, duas medidas (9)
• Argentina vs Probreza Funcional (0)

IMHO um bom home office precisa de Internet banda larga, uma rede local sua workstation de trabalho e um servidor de testes e um bom tanto de storage.

Pensando nisso hoje lembrei do meu primeiro home office, quando ainda morava em São Bernardo (circa 2004):

• Speed 256K
• Hub 10Mb/s
• Workstation Atlhon 900Mhz/512RAM/80GB (era também o firewall/router)
  • SuSE (??)
• Server test Atlhon 750Mhz/512 RAM/40GB
  • Debian
  • Kurumin

E a cara dele era assim:

Hoje, meu home office tem:

• Internet à cabo de 15Mb/s
• Firewall / Router / Wifi (ddwrt)
• Switch 100Mb/s
• Workstation AMD Athlon(tm) 64 X2 / 2GB RAM / 1.3TB
  • Ubuntu
• Múltiplos servidores de teste virtualizados (três hurras para virtualização)
  • Debian
  • CentOS
  • Fedora
  • ArchLinux
  • Ubuntu

Mas em compensação ele é assim:

Pois é… nem tudo na vida é upgrade.

Related posts

• What really matters (0)
• Restingindo acesso com rbash (0)
• Reforma ortográfica fácil (0)
• Pra mim não, obrigado. (2)
• Porquê as interfaces de rede trocaram de posição no Linux? (3)

Cenário: Um servidor que estava rodando e funcional há mais de um ano teve um reboot agendado  de madrugada. Depois do reboot recebo alertas que o tal não voltou automaticamente como esperado.

Servidor: Dell PE 2850 com 3 NICs: 2 Intel + 1 DLink rodando CentOS 5.2

Remotamente acessei o KVM e vi que o servidor estava OK, no tela de login. Nenhuma mensagem de erro e as interfaces em pé. Como já sou macaco velho na hora pensei que as interfaces de rede tinham mudado de lugar (já vi isso várias vezes), mas não tinha como testar pois elas estão em redes físicas separadas (não dava só pra reconfigurar uma vlan no switch), então tive que vir pra empresa mesmo.

Chegando aqui, dito e feito. As interfaces (eth0 e eth2) alternaram de posição. Eu já tinha visto isso acontecer antes, mas não sem um upgrade de kernel.

A questão é que o servidor estava up há mais de 1 ano, enquanto eu só tenho 8 meses de empresa. Isso significa que meus antecessores podem ter feito upgrade de kernel em um determinado momento, mas nunca deram boot na versão nova. Eu nunca vou saber.

Mas na verdade o problema poderia ter sido evitado facilmente se as interfaces tivessem sido configuradas adequadamente logo de cara.

No RHEL e no CentOS as interfaces são ativadas pelo /etc/sysconfig/network-scripts/ifcfg-ethX. Onde X é o número da interface. Um dos parâmetros que pode ser configurado é HWADDR, onde você amarra o endereço físico (MAC Address) à interface, de forma que na hora de subir a mesma o Linux saberá exatamente qual é qual.

Aqui tem mais detalhes desse arquivo de configuração, enquanto aqui tem uma excelente explicação de porquê as interfaces podem alternar de posição.

Related posts

• Restingindo acesso com rbash (0)
• Reforma ortográfica fácil (0)
• Pra mim não, obrigado. (2)
• What really matters (0)
• VMware nas madrugadas (0)

Eu e a esposa no sofá vendo TV e conversando sobre uma loja que precisávamos visitar no final de semana. E eis a dúvida: Que horas eles abrem?

Eu saco meu droid, ela saca seu iPod touch, acessamos o Google BUM! 30 segundos depois sabemos a resposta: Horário de funcionamento: Das 09:00 às 16:00hrs.

Nos olhamos e dizemos quase ao mesmo tempo: Como vivíamos sem o Google?

Cena 2:

Um dos gerentes aqui na empresa não está conseguindo configurar o BlackBerry dele para conectar no nosso Wifi porquê usamos um certificado self-signed.

Ele veio aqui no nosso departamento enquanto comíamos nossa pizza comemorativa pela aposentadoria de um dos servidores mais velhos da empresa (assunto pra outro post) e acabou que ficamos mais de meia hora discutindo as maravilhosas ferramentas de busca do Google.

No final da conversa alguém larga: Como vivíamos sem o Google?

Cena 3:

O pastor da nossa igreja veio em casa ontem para eu instalar o Ubuntu Netbook Remix (sensacional aliás. Eu nunca tinha visto ele antes) no Aspire One da filha dele, que veio com a porcaria do Windows Starter Edition.

Enquanto eu tentava fazer backup dos emails (Mozilla Thunderbird) surgiu uma dúvida: Como eu faço para exibir as pastas ocultas no Windows 7?

Eu não sabia, ele não sabia… Mas 30 segundos depois de procurar no Google, lá estava a resposta.

Ele olha para mim e pergunta: Como vivíamos sem o Google?

E notem que eu não estou falando “como vivíamos sem um site de busca”. Estou falando Google mesmo. Já tentei utilizar o Yahoo, Bing, Ask… sem chance. Não se comparar os resultados do Google com mais nada.

A conclusão? Tire as suas próprias, mas eu não pretendo parar de usar o Google tão cedo. E, aliás, se eles resolverem começar a cobrar pelos serviços amanhã eu digo o seguinte: Eu pago.

Related posts

• Wolfram|Alpha (0)
• Tá difícil (0)
• Ricos também comem palhacitos (1)
• Me deixem em paz (1)
• Google Wave (0)

A maior universidade aqui da região, a Dalhousie, acabou de criar um mirror de software livre.

Como se não fosse bom o suficiente ter um mirror fisicamente tão próximo, diminuindo em muito a latência na rede, ainda por cima eles usam o mesmo provedor que eu e tem um PTT (Ponto de Troca de Tráfego) dentro do datacenter deles.

Olhem só o traceroute:

Host                               Loss%   Snt   Last   Avg  Best  Wrst StDev

 1. DD-WRT.home.lan                  0.0%     3    0.5   0.6   0.5   0.7   0.1

 2. ???

 3. hlfx-asr1.eastlink.ca            0.0%     3    9.8   9.2   8.4   9.8   0.7

 4. hlfx-br1.eastlink.ca             0.0%     3    9.0  12.9   9.0  16.2   3.7

 5. hlfx-dr3.eastlink.ca             0.0%     2    7.0  21.1   7.0  35.2  19.9

 6. dal-gw.eastlink.ca               0.0%     2    7.8   9.8   7.8  11.8   2.9

 7. 198.166.1.37                     0.0%     2    8.5   8.1   7.8   8.5   0.5

 8. 192.75.96.254                    0.0%     2    9.1   9.3   9.1   9.4   0.3

Coloquei um download pra rolar, just for fun aqui. Não deu nem graça:

347,852,800 1.75M/s   in 3m 10s

Se eu ainda estivesse na universidade onde trabalhava o link entre elas é 1Gbp/s. O gargalo iria ser meu disco! Que coisa linda de imaginar.

Mas com isso eu já consigo viver feliz o suficiente, obrigado.

Related posts

• Wifi no ônibus? Aqui já tem (1)
• What really matters (0)
• Restingindo acesso com rbash (0)
• Reforma ortográfica fácil (0)
• Pra mim não, obrigado. (2)

Na época eu estava no time de redes e era minha responsabilidade alocar subnets, IPs, Vlans, etc. Até que era divertido fazer toda a engenharia de uma rede razoavelmente grande e complexa, até que chegavam os malditos clusteres.

Não manjo nada de AIX, mas toda vez que precisávamos implementar um cluster de System P era a mesma coisa:”Ô, Eri… precisamos de uma rede exclusiva pra comunicação entre sei-lá-o-que e a repimboca da parafuseta.”

Tocava eu criar uma Vlan só pra isso.

E onde tem AIX tem o que? Oracle… (sempre andam juntos ou é impressão?). Ai vem também o DBA e larga: “O Oracl RAC precisa de uma rede exclusiva pra heart beating…”

Ô minha nossa… uma rede feita com tanto capricho e cuidado, com subnets bem definidas, máscaras de rede escolhidas com cuidado, numeração IP feita com esmero o suficiente para ser possível saber o hostname baseado no IP sem precisar de DNS… E me aparecem esses filhotes de cruz-credo criando redes isoladas e horrível de documentar num diagrama. O que fazer?

Bom… Eu fazia o seguinte: Para não estragar a minha alocação de redes privadas tão bem planejada eu simplesmente alocava 1.1.1.x/xx para essas tranqueiras. Ficava limpo, bonito e todo mundo que pegava o cliente depois que eu tinha saído do projeto sabia, apenas de bater o olho, do que se tratava aquela subnet: Era isolada e não precisavam se preocupar com ela.

Até ai tudo bem… Exceto por um problema: Dia 20 de Janeiro de 2010 a rede 1.0.0.0/8 foi alocada para Asia Pacific Network Information Center.  Oops… Foi mal, hein?

O quanto isso vai ser um problema na prática eu não sei dizer, pois a maioria dessas redes que eu implementei não eram acessíveis via internet de qualquer forma… Mas potencialmente falando é um problema.

Bom…. vivendo e aprendendo… De qualquer forma, desculpa qualquer coisa.

Related posts

• Ainda não consigo acostumar (7)
• VMware nas madrugadas (0)
• Troubleshooting de DNS (3)
• Restringindo acesso via SFTP (1)
• Restingindo acesso com rbash (0)

Uma forma simples de conseguir uma segurança bacana é utilizar o modo restrito do bash. Com isso habilitado o shell irá desabilitar as seguintes funções:

• Mudar o diretório (cd)
• Mudar o valor das variáveis SHELL, PATH, ENV, or BASH_ENV
• Comandos que incluem /
• Especificar um arquivo que contenha / como fonte para o comando “.”
• Usar redirecionamento de output (>, >>, |)
• etc (man bash para todas as features)

Colocando para rodar:

Crie um link do bash para o rbash e adicione o mesmo em /etc/shells:

ln -s /bin/bash /bin/rbash
echo /bin/rbash >> /etc/shells

Depois é só mudar o shell do usuário a ser restringido para usar o rbash:

usermod -s /bin/rbash username

Combinando isso com traps (do CTRL+C, por exemplo) você consegue criar um ambiente seguro o suficiente para fornecer serviços e acessos aos seus servidores e ainda assim dormir à noite.

Como diria o SuSE: Have a lot of fun!

Related posts

• Reforma ortográfica fácil (0)
• Pra mim não, obrigado. (2)
• Porquê as interfaces de rede trocaram de posição no Linux? (3)
• checkout (0)
• What really matters (0)

Mergulhamos fundo em virtualização na empresa e eu ando varando as madrugadas migrando a infra-estrutura. Algumas coisas interessantes para dizer sobre isso…

A primeira observação é que a geração anterior de sysadmins a qual eu substituo até começou o processo – mas infelizmente por falta de fundos ou de apoio ou de conhecimento ou, mais provavelmente, de uma combinação dos três – fez uma melança horrível. E acertar esse meio-ambiente previamente virtualizado para o nosso novo vSphere tem sido mais complexo do que o previsto.

Com versões diferentes de vmware, número limitado de licenças de vCenter e vSphere (sim… no momento tenho os dois), uso de diferentes tecnologias e servidores como storage e péssimos posicionamentos dentro do rack migrar uma máquina virtual de um servidor ESX 3.5 para o vSphere pode ser uma tarefa bem ingrata. Principalmente quando você tem uma janela de manutenção limitada.

Imaginem a seguinte situação: Meu vCenter tinha 4 servidores ESX 3.5 sendo gerenciados. 2 numa subnet, 1 em outra subnet e outro numa terceira subnet. Não houve a preocupação de criar uma interface de gerenciamento na subnet de administração. Pior: subnets de níveis de segurança diferente. Então todo o tráfego do VMware passava pelo firewall.

Nem preciso dizer que vmotion não funcionava, né? Mas também não ia adiantar… No storage criaram um volume para cada ESX, de forma que um não via as VMs do outro. Então o vmotion tinha que ser full. Ah, sim… E cada ESX tinha apenas máquinas virtuais da subnet a qual a interface de administração pertencia. Trunk é para os fracos. Já falei que vmotion não funcionava?

Resumindo, eram apenas contâineres isolados com uma interface de administração centralizada. Horrível.

O que eu fiz agora, que compramos 4 Power Edges R710 top de linha e um storage EqualLogic foi sapecar placas de rede nos bichos. Cada servidor tem: 1 NIC pro iDrac, 1 NIC pra gerenciamento do vmware (incluindo vmotion), 1 NIC para cada subnet nas quais terei máquina virtual, 1 NIC para a rede de backup, 1 NIC para o storage e ainda 1 NIC disponível no momento (provavelmente utilizarei para fault-tolerance).

Para migrar as máquinas da antiga infra (!??) virtual para essa nova a forma mais fácil tem sido, acredite se quiser, usar o VMware Converter. Em alguns casos consegui fazer uma gambiarra e conectar com um ESXi novo num storage antigo e importar a VM para dentro do meu inventário e depois fazer um vmotion para o EqualLogic, mas foram poucos os casos que consegui.

E a cereja no bolo: No total já devo ter migrado – entre máquinas virtuais e P2V – uns 20 servidores. Desses todos, menos 2, eram Linux. Dos dois Windows que migrei um deles deu merda. Só 50% de aproveitamento. Como pode uma coisa dessa? Ainda bem que só servidor de uso interno é Windows, viu? Todos os servidores de serviços aos clientes são Linux. Senão a essa hora eu já tinha pedido para sair.

De qualquer forma tem sido uma tarefa longa e tediosa. Minhas madrugadas basicamente tem sido 2 horas de sono seguidas de 1 hora acordado em ciclos eternos até que acabe de migrar as máquinas do dia ou acabe a janela de manutenção e eu tenho simplesmente que destruir a VM nova e bootar a VM antiga.

Em compensação – exceto por ontem à noite – P2V tem sido uma baba. Conecto no servidor, desabilito todos os serviços e o crond, faço o P2V, dou shut na interface do switch onde a máquina físca está, subo a máquina virtual, instalo vmware-tools e corro pro abraço. No dia seguinte – quando chego no escritório – vou até o console do servidor e dou shutdown nele. Uns dois dias depois tiro a máquina do data-center e já era.

E aqui entre nós: Quando tenho a oportunidade de dormir eu até descanço mais tranquilo, pois alguns servidores muito críticos que fiz P2V estavam rodando em hardware com mais de três anos e o tempo médio para restaurar os backups é de 5 a 8 horas. Nem tava afins de enfrentar uma merda dessas.

Kudos para quem inventou o conceito de snapshot de file system direto no storage viu?

Related posts

• Goela abaixo (2)
• AppleTV (6)
• Windows 7 ou KDE 4? (0)
• Restringindo acesso via SFTP (1)
• Restingindo acesso com rbash (0)

Uma opção é adicionar outro disco virtual e juntar no seu logical volume do LVM, mas já que o VMware te dá a possibilidade de redimensionar o disco, porquê não usar essa opção?

Aumente o disco como desejado pelo VMware, boot sua máquina virtual siga os passos abaixo (como root):

Re-scaneie seu disco:

echo "1" > /sys/class/scsi_device/<device>/device/rescan

Recrie a partição:

Usando o fdisk delete a partição LVM e crie-a novamente. O cilindro inicial deve manter-se o mesmo e apenas aceite o default para o cilindro final. Não se esqueça que o fdisk cria as partições como Linux (83) por default. Se estiver usando LVM mude para Linux LVM (8e).

Redimensione o Physical Volume:

pvresize -v /dev/<particao>

Redimensione o Logical Volume:

lvextend -L +<size>G /dev/<volume_group>/<volume>

Redimensione o filesystem:

EXT2/EXT3:

resize2fs /dev/<volume_group>/<volume>

ReiserFS:

resize_reiserfs -f /dev/<volume_group>/<volume>

Related posts

• Backup LMV via rede (GOA) (0)
• VMware nas madrugadas (0)
• Restringindo acesso via SFTP (1)
• Restingindo acesso com rbash (0)
• Reforma ortográfica fácil (0)

Do nosso lado também é bom, pois fica mais fácil garantir a qualidade do hardware, acesso fácil aos servidores e sem nenhum nego fução mexendo em configuração e fazendo caquinha.

Um dos problemas de gerenciamento, porém, é quando você tem diversos clientes diferentes na mesma máquina e um deles monopoliza o tempo de processador. Isso acontece muitas vezes devido a  clientes fazendo teste em ambiente de produção, relatórios enormes sendo rodados em dias críticos ou simplesmente por bugs no software que fazem um processo chupar 100% de CPU.

Uma solução que achei recentemente foi o cpulimit, que consegue limitar o tanto de CPU que um processo usa diminuindo o problema causado por ele em caso dele começar a descer a ladeira sem freio.

O chato dele é o fato de que você precisa especificar qual processo deseja limitar e num ambiente como o nosso, onde novos processos aparecem e morrem o tempo todo, é preciso automatizar.

Acabei criando o script abaixo, que ainda precisa ser muito trabalhado, mas estou já publicando na esperança de conseguir algum bom feedback em como melhorá-lo. Não me entendam errado: ele já funciona.

Download aqui: limitcpu.py

Related posts

• Mordomo virtual (2)
• checkout (0)
• VMware nas madrugadas (0)
• Restringindo acesso via SFTP (1)
• Restingindo acesso com rbash (0)