MBE

Na primeira parte, apresentei um cenário real que encontramos em um cliente e nessa segunda parte vamos as soluções que propomos.

Analisando cuidadosamente a situação dos dois servidores, nossa equipe chegou a conclusão que não valia a pena importar absolutamente nada dos sistemas atuais, nem mesmo as contas e grupos de usuários. A gestão anterior usava um padrão não muito prático para a criação dos shortnames, além disso a estrutura organizacional tinha mudado e os grupos não refletiam mais a realidade da empresa.

Outra coisa que nos preocupou foi a ausência do DNS nos dois servidores. Quem conhece um pouco do Mac OS X Server, sabe que o DNS é o principal pilar da estrutura do OD (Open Directory) e de outros serviços. Qualquer falha aqui, é fatal…

Durante algumas semanas planejamos e testamos em nosso laboratório a melhor estratégia para a migração dos servidores e a princípio, a topologia proposta era essa:

Os Xserves (infelizmente) são meramente ilustrativos…

A idéia era termos dois servidores na matriz, um Master e um Replica para contingência no caso de falhas. Na filial teríamos um outro Replica direto do Master, que por sua vez, possuiria seu próprio Replica direto para contingência. Um Mac OS X Server replica, que possui um replica direto é chamado de Relay.

O servidor Master tem a base de dados principal do OD (LDAP, Password Server e KDC) e nele são feitas todas as configurações de usuários, grupos, computadores, MCX e etc. Uma vez feita qualquer modificação no servidor Master, as alterações são propagadas para todos  os servidores Replica. Dessa forma o problema de trabalhar em dobro, criando contas de usuário em dois servidores distintos acaba, uma vez que teremos uma base consolidada em todo o domínio do OD.

Por questões de orçamento, não foram aprovados os servidores replica de contingência, apenas o Master na matriz e o Replica na filial…

Configurados os serviços de estrutura de rede (DNS, DHCP e OD) e os serviços de colaboração (AFP, SMB e iChat), só faltavam os usuários, grupos e políticas de segurança e backup.

Uma vez decidido o novo padrão de nomes de usuários, seus grupos e novas permissões de acesso aos serviços do servidor, criamos uma tabela com todas as informações que deveriam ser importadas no novo servidor: nome completo, shortname, email, iChat e senha padrão. Como eram menos de 100 usuários, o trabalho não foi tão grande assim. Por fim usamos o Passenger, que é um software milagroso que cuida da importação de tabelas para o OD!

Não entrarei em detalhes sobre políticas de segurança e backup por questões obvias, ok?

Primeira parte pronta, o servidor Master funcionando perfeitamente na matriz! O servidor secundário ainda não foi implementado, mas tão logo seja, eu escrevo a parte 3 desse artigo, falando sobre a integração entre eles.