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.

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.

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.

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!

www.youtube.com/watch?v=X9dpXHnJXaE

E como foi bacana participar de um “go live” sem participar do “go live”. E como eu vi problemas e desculpas conhecidas, viu?

Acho que o problema mais clássico que aconteceu foi que um login deles não funcionava. Caracas. Nem sei quantas migrações participei que deram problema durante o processo porquê algum login não funcionava, alguma credencial não tinha permissão suficiente pra fazer alguma coisa ou simplesmente alguém digitava a senha errada tantas vezes que travava a conta.

Fora as clássicas “cara-de-bunda”, né? Nego dá o comando, todo mundo segura a respiração e…. nada. Já vi isso acontecer várias vezes também quando, por exemplo, o cara que vai subir o sistema esquece que não está no ambiente de teste, onde ele setou um monte de atalhos e scripts. Ai na máquina de produção ele digita o alias ao invés do comando, mas esse não vem configurado por padrão. Ou então falta alguma variável de ambiente e outras falhas simples do tipo… mas que geram um puta stress.

E fora coisas que ninguém nunca pensa antes da migração. Um dos problemas que aconteceu é que alguém setou o TTL do DNS muito alto, então quando o sistema foi pro ar um monte de gente que já tinha tentado acessar antes não conseguia entrar por causa de cache.

Também não podia deixar de faltar os espertinhos (eu incluso) que estavam usando uma URL que dava bypass na restrição de acesso antes do lançamento e conseguiam fazer queries no sistema, causando load antes do esperado.

Por outro lado foi muito esperto da parte deles fazerem o lançamento via webcast. Além do imenso hype que geraram (#wolframalpha foi trend topic por mais de 3 horas no twitter.) eles conseguiram troubleshoot e feedback global gratuito e imediato.

O problema do DNS que falei, por exemplo, foi alguém que gritou no chat do Justin.tv, que estava fazendo o broadcast do vídeo.

Logo depois de ativar o sistema eles observaram na sala de controle que o número de queries estava muito baixo. O Stephen Wolfram então perguntou se alguém sabia porquê tinha tão pouco acesso. E a pessoa que estava acompanhando o Twitter do @Wolfram_Alpha gritou: “Ninguém tá conseguindo acessar”. Eles jogaram mais um pó de pirilim-pimpim e o sistema subiu.

As pessoas começaram a entrar e o Stephen foi pra frente do computador e perguntou no chat de onde as pessoas estavam conseguindo acessar. Em poucos segundos centenas de pessoas de tudo quanto é canto no mundo começaram a responder de onde funcionava e de onde ainda estava indisponível. Algumas pessoas reportavam um erro que foi diagnosticado por outros usuários no chat como sendo cache no IE e um usuário já dava a dica pra outro de como acessar.

Em aproximadamente um hora eles conseguiram uma resposta maciça de todos os cantos do mundo. Com certeza economizaram uma boa grana em mão-de-obra pra isso.

E quanto ao sistema de busca é interessante, mas ainda tem que comer muito arroz-com-feijão. A base de dados parece pequena e muitas pesquisas não são entendidas ou não tem resultados. Mas se você quer ver algumas respostas interessantes, ta ai uma lista de coisas que pode perguntar:

What’s the meaning of life?
What is the airspeed velocity of an unladen swallow?
Where am I?
Where are you from?

Quem diria que eu, ao nomear meu humilde blog de Another Geek Blog 6 anos atrás, estaria à frente da moda?

www.youtube.com/watch?v=rCq6E6tnQKg

www.youtube.com/watch?v=jqLPHrCQr2I