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.
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.
Entre 2005 e 2007 participei da criação de algumas redes relativamente complexas, com trocentos requerimentos, especificações, servidores, redes, políticas de segurança, etc.
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.
Como sysadmins vez por outra a gente precisa dar acesso a clientes, parceiros ou outro tipo de usuário temporário/untrusted aos servidores. Apesar de criar um jail root completo ser a melhor solução muitas vezes é mais trabalho do que o necessário e começa a entrar naquele cenário em que a segurança atrapalha a usabilidade e os negócios.
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:
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.
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?
Dica rápida: Se você usa o tanto que virtualização que eu uso já deve ter dado de cara com esse problema: Você cria uma máquina virtual com um disco de x GB e quando vai mandar pra produção alguém pede mais espaço em disco.
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):
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).
Na empresa fornecemos “software as service” para centenas de clientes que preferem ter tudo gerenciado por nós do que ter que lidar com a dor-de-cabeça que é gerenciar sistema operacional + aplicação. É um modelo muito bom pois pagam uma mensalidade e tem o serviço disponível o tempo todo, assim como pagamos mensalidade de eletricidade, telefone e água.
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.
Acabei de ler este artigo no Slashdot sobre um cenário que todo mundo que já tem um pouco de tempo em IT já viu: Você começa a pesquisar soluções para um problema/necessidade da empresa, lê toneladas de documentações, manuais, baixa demos, faz laboratório, roda benchmarks, prepara uma apresentação com todas as informações mastigadas com gráficos e tabelas de prós e contras mostrando qual o melhor produto e ai…. seu chefe (ou o chefe do seu chefe, ou algum outro manda-chuva) manda bater o martelo exatamente em OUTRA opção.
Você gastou 40, 80, 120 horas da sua vida juntando informações relevantes e tecnicamente acuradas e os imbecis escolhem o que? A mesma solução que eles queriam desde o começo, mas para manter as aparências de que estavam realmente analisando o mercado te mandam fazer papel de idiota pesquisando.
Ter solução errada enfiada goela abaixo é duro, mas muitas vezes temos que aceitar. Dentro dos limites, é lógico.
Quem acompanha o blog há mais ou menos um ano acompanhou meus posts metendo o pau no meu emprego antigo, mas vou contar o que realmente engatilhou minha saída. Eu estava trabalhando num projeto para implementar uma collaboration suite que iria substituir o atual sistema de email.
Junto com mais um colega passamos infinitas horas fazendo laborátorios, lendo, estudando, implementando testes, juntando fatos, preços, informações, participando de webinars e conference calls e recrutando pessoas para testar as opções (sendo que a última coisa foi realmente o mais difícil).
Depois de muito trabalho mandamos um relatório completo, com nossa recomendação, para nosso gerente – que encaminhou para o diretor. Ficamos sem ouvir nada a respeito até um dia que o meu gerente me chama para “falar 5 minutinhos” numa reunião.
Chegando lá estavam reunidos na sala o diretor e todos os gerentes de IT: Rede e Servidor, Desenvolvimento, Web, Desktop, Audio e vídeo e suporte. Todos eles haviam sido convidados para participar dos testes, mas nenhum se deu ao trabalho de fazê-lo, que fique claro.
Quando entro o diretor me faz algumas perguntas sobre o relatório, tira 2 dúvidas tão idiotas que percebi na hora que ele não tinha entendindo lhufas e então ele vira pra mim e diz: “Obrigado. Você pode ir. Agora nós podemos continuar a discutir qual ferramente escolher nós mesmos”.
“OPA! Como é que é, meu chapa? Eu ralei igual um FDP e conheço esses sistemas por dentro e por fora, sei todas as features, limitações e parâmetros de linha de comando de cada uma das opções e você, que não sabe nem fazer uma pergunta e essa cambada de gerente incompetente, que não perdeu 5 minutos para olhar os pilotos que configurei, estão me dispensando pois acham que são capazes de decidir por vocês mesmos? Tá de brincadeira?” – Pensei.
Basta dizer que 2 semanas depois eu tinha conseguido uma entrevista e em mais 2 semanas estava começando o novo emprego.
Ainda não posso cantar vitória no emprego novo, mas estou bem mais confiante de que meu tempo está sendo bem investido dessa vez.
A procura agora é diferente: Storage. Qual a melhor opção para o nosso caso? Para o cenário da nossa empresa?
Logo que cheguei meu chefe tinha uma idéia do que ele queria (Equallogic). Eu analisei, li um pouco e logo achei que não era a melhor opção. Já escaldado do emprego antigo quase não falei nada, mas achei melhor comentar que eu tinha outra idéia que deveríamos testar (NetApp).
A surpresa foi que, na semana seguinte, ele já tinha marcado com o representante da idéia que eu dei e conseguimos um FAS 2050 emprestado por um mês para analisar e fazer os testes que me dessem na telha.
Essa semana expira o mês e eu já fiz meu relatório e entreguei para o chefe. E na quarta-feira temos reunião com a NetApp. Provavelmente não vamos ficar com a solução.
Mas dessa vez não porquê vou ter que engolir uma solução que não escolhi. Dessa vez vai ser porquê eu pude comprovar através de muitos testes que a solução simplesmente não vale o investimento.
Não temos tamanho, necessidade ou grana para gastar numa caixa NetApp e, exceto se eles arriarem as calças e derem um desconto MUITO bom, vai rolar um “thanks, but no thanks.”
Como eu disse, ainda não posso fazer a dancinha da vitória, pois não sei se vamos realmente adquirir a solução que eu recomendei no final das contas. Mas que a sensação de poder descartar minha própria sugestão baseado em méritos do produto e não em politicagem é sensacional, isso é.
ps: Para quem ficou curioso, minha recomendação é baseada num Dell Power Edge R610, um Dell Power Vault MD1000 e Solaris 10 (ZFS, baby).
O Hulu é um serviço bem bacana. Pra quem não conhece é basicamente uma TV on-demand via Internet com todos os seriados e programas das principais emissoras americanas (aka estado-unidenses).
Nele dá pra assistir todos os episódios atuais das séries que estão rolando pelo micro. Sem precisar assinar TV a cabo, de graça e com comerciais limitados (normalmente apenas 30 segundos).
Além de ser possível assistir pelo browser você também pode usar, por exemplo, o Boxee para isso. E é exatamente o que eu queria. Instalei o Boxee na minha AppleTV e quero assisitir programação do Hulu.
A pegadinha? O Hulu só transmite nos USA. Assim que tentei acessar aqui do Canadá tomei uma invertida e o site me mandou procurar minha turma.
Se por acaso você também quiser assistir o Hulu de fora dos USA eu tenho a solução (não, proxy não funciona!). Você vai precisar dos seguintes ingredientes:
1 servidor Linux em território americano (acesso root)
1 máquina virtual Linux na rede local
OpenVPN
Capacidade de editar as configurações de rede do seu media-center
No meu caso tanto o servidor nos USA como a máquina virtual estão rodando Debian então foi assim a configuração:
A partir de agora você deve configurar o default gateway do seu media center para ser o IP local da sua máquina virtual.
Pronto. Agora a única coisa que te impede de assistir de fora dos USA é a latência da sua conexão internet e sua largura de banda. Ah, sim… e caso você já tenha acessado o Hulu alguma vez sem usar essa gambi você precisa limpar cache/cookie do seu media center antes de tentar pelo túnel.
E agora que você já entendeu o processo, tavez queira melhorar um pouco a configuração da VPN, talvez se tiver um firewall mais bacana fazer uma configuração melhor no iptables principal e coisas do tipo. Se tiverem idéias para melhorar postem nos comentários.
Acompanhei esse diálogo outro dia entre um dos caras do suporte e um cliente no telefone. Infelizmente só pude ouvir as interações do lado de cá, mas foi algo mais ou menos assim…
“Ah, então o software não tá com problema? É o computador que não liga mais? Entendi. Acontece como? Sei…. Humm… parece ser um problema na fonte. Deve ter queimado.
Não… é até comum esse problema. Pico de energia pode causar isso. Precisa substituir a fonte e deve resolver.
Sim… acontece derrepente. Sim… Eu entendo. Ontem estava funcionando e hoje não. Sim… pode acontecer de um dia pro outro. Sim, é normal.
Nós que vendemos a máquina para o senhor? Se for o caso a garantia cobre. Não… nossos equipamentos são de boa qualidade. Não senhor… eles não costumam quebrar do nada.
O senhor pode me passar o número serial para eu abrir chamado de garantia por favor? Ahãn… Ahãn…
