Roteiro Prático para a Migração dos Servidores Turing e Godel

Transcrição

1 Roteiro Prático para a Migração dos Servidores Turing e Godel Alfenas, Abril de Rodrigo Martins Pagliares Última atualização: 27/05/2010

2 Conteúdo 1. Introdução Instalação do Debian Lenny Política de backup dos usuários, grupos e pasta home Roteiro para backup de usuários e dados Servidor Turing Antigo Roteiro para cópia de usuários e dados via rede Servidor Turing Novo Limitando a quantidade de espaço em disco por usuário - Quota Servidor de Arquivos com NFS, NIS e Samba Servidor NFS Servidor NIS... 15

3 1. Introdução Este roteiro foi criado para tornar mais fácil a migração dos servidores GNU/Linux do BCC para novos servidores. Tal migração se torna necessária quando, por exemplo, desejarmos substituir os computadores destinados aos servidores por outros com um hardware melhor. A migração também se torna importante quando, simplesmente, desejamos ter um backup de servidores, colocando a rede novamente em atividade mesmo em caso de problemas sérios de hardware nos servidores em funcionamento. Os servidores atuais, Turing e Godel, estão rodando no sistema operacional Ubuntu. Neste roteiro, optamos por migrar estes servidores para o Debian/Lenny 5.04 devido à segurança e estabilidade. Para facilitar o entendimento deste roteiro, adotamos alguns padrões de nomenclatura. Como o objetivo é fazer migração, vamos manter os nomes Turing e Godel para as novas máquinas. Quando quisermos referir aos servidores em produção atualmente, usaremos o termo servidor(es) antigo(s). O(s) clone(s) serão referenciados neste documento como sendo servidor(es) novo(s). Os comandos a serem executados no Shell de comando serão precedidos por $, indicando que o comando deverá ser executado como usuário normal, sem privilégios de administrador. Comandos precedidos com # deverão ser executados como administrador (root). Também usamos a convenção tipográfica de fonte Courier New, tamanho 10 para comandos do Shell e para a listagem de arquivos de configuração. No ubuntu, a senha de root vem desativada por padrão. Os comandos a serem executados nos servidores antigos (que rodam no Ubuntu) deverão ser precedidos de sudo caso sejam executados com privilégios de administrador 2. Instalação do Debian Lenny 5.04 O roteiro completo de instalação do Debian Lenny 5.04 se encontra no manual do administrador de redes sendo confeccionado pelo autor deste roteiro prático e pelo estagiário de redes de computadores, Tiago Silveira. As informações básicas são: Instalação via Debian Netinst, Escolhemos a opção de configurar a rede via DHCP no momento de instalação, o nome da máquina nova é turing, o nome do domínio é bcc.unifal-mg.edu.br. Partições criadas: /, /home, /var e swap. Recomenda-se apenas que o no momento de instalação do Debian no servidor novo, seja criada uma conta de usuário normal, sem privilégios de administrador, que não exista no servidor antigo (isso é importante para evitar problemas de sobreescrita no momento de migração dos usuários do servidor antigo para a novo). Optamos por criar um usuário

4 chamado rodrigo no momento de instalação, tendo em vista que este usuário não existe no servidor antigo. 3. Política de backup dos usuários, grupos e pasta home Seria tedioso se toda vez que formatássemos o servidor ou simplesmente mudássemos a máquina como está previsto neste documento tivéssemos que cadastrar todos os usuários do sistema novamente. Para evitar isso, decidimos criar um roteiro para migração de contas e dados dos usuários do servidor antigo para o novo (o atual servidor Turing está sendo atualizado, momentaneamente por uma máquina melhor, emprestada do laboratório de redes pelo professor Flávio). Para exemplificar, suponha que o endereço IP do servidor novo sendo configurado é o Dessa forma, podemos usar o comando SCP, parte integrante da suíte SSH para a cópia dos arquivos remotos presentes na máquina Turing antiga. Teoricamente, seria necessário copiar os arquivos /etc/shadow, /etc/passwd e /etc/shadow, além do backup da pasta /home que contém os dados dos usuários cadastrados no servidor. Infelizmente, algumas considerações adicionais devem ser levadas em consideração além da simples cópia dos arquivos, conforme veremos nas próximas seções. Dessa forma, a seção 3.1 exibe o roteiro passo a passo a ser executado no servidor Turing antigo. A seção 3.2 ilustra o roteiro a ser seguido no servidor Turing novo Roteiro para backup de usuários e dados Servidor Turing Antigo Abaixo o conteúdo completo do roteiro a ser seguido para a migração de contas de usuários do servidor Turing antigo para o novo servidor. Após a listagem é feita uma explicação do funcionamento dos passos descritos. Lembre-se que este roteiro de deverá ser executado na máquina turing antiga. Nos passos abaixo, estamos usando o usuário pagliares que possui privilégios de administrador no servidor Turing antigo. Substitua a ocorrência de pagliares, daqui por diante, caso esteja seguindo este roteiro com outro usuário. O roteiro a ser executado no servidor antigo possui 4 passos: primeiramente acessaremos o servidor antigo remotamente; em seguida criaremos um diretório no servidor antigo para armazenamos o backup dos arquivos de configuração essenciais e para os dados dos usuários. Após estes dois passos criaremos uma cópia dos arquivos de configuração. Finalmente, faremos o backup da pasta home, usando o comando tar. Primeiro Passo: Acessar remotamente o servidor turing antigo # ssh pagliares@

5 Passo 2: Crie um diretório para armazenamento dos dados de backup e vá para este diretório recém-criado $ cd /home/pagliares/ $ mkdir backupturingantigo/ $ cd backupturingantigo/ Este passo pode ser executado em qualquer diretório no servidor já que é neste diretório que vai residir os arquivos de configuração e a pasta home compactada para ser transmitida pela rede para o servidor novo. Passo 3: Fazer um backup dos arquivos de configuração (explicações detalhadas após o roteiro, no fim desta seção) $ export UGIDLIMIT=1000 $ awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > /home/pagliares/backupturingantigo/passwd.bak $ awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > /home/pagliares/backupturingantigo/group.bak # sudo awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/passwd tee - sudo egrep -f - /etc/shadow > /home/pagliares/backupturingantigo/shadow.bak # sudo cp /etc/gshadow /home/pagliares/backupturingantigo/gshadow.bak Obs: os dois últimos comandos acima devem ser executados como sudo, pois os arquivos /etc/shadow e /etc/gshadow, possuem permissão 640, sendo propriedade do usuário root e grupo shadow respectivamente. Passo 4: Fazer um backup do diretório /home $ cd /home/pagliares/backupturingantigo/ # sudo tar -zcvpf home.tar.gz /home Para melhor entendimento dos passos acima, uma breve descrição referente aos diretórios e arquivos essenciais para o gerenciamento de usuários e grupos e, conseqüentemente para a migração, é exibida abaixo: Arquivo /etc/passwd Contém informações para cada conta do usuário

6 Arquivo /etc/shadow contém a senha criptografada para as contas dos usuários e informações opcionais de expiração de senhas Arquivo /etc/group define os grupos os quais os usuários pertencem Arquivo /etc/gshadow arquivo shadow dos grupos (senhas criptografadas para os grupos) Diretório /home/ Todos os dados dos usuários estão armazenados sob este diretório Precisamos fazer o backup de todos estes arquivos e diretórios presentes no servidor antigo para serem restaurados no novo servidor. Com exceção do diretório /home, todos os arquivos de configuração foram copiados no passo 3. Ainda no passo 3, usamos uma série de comandos. Inicialmente, configuramos um filtro para os identificadores de usuário(uid), para que façamos o backup apenas de usuários normais e não usuários de sistemas. No caso do Ubuntu e do Debian, as contas de usuários normais iniciam a partir do UID $ export UGIDLIMIT=1000 Copiamos as contas presentes em /etc/passwd para /home/pagliares/backupturingantigo/passwd.bak usando o utilitário awk para filtrar as contas do sistema (copiar apenas contas de usuários). Como os comandos são longos, o shell sendo usado poderá reportar um erro caso necessite de mais de uma linha para digitar o comando completo. Se isso acontecer, lembre-se que quando o comando não couber em uma linha do shell, poderemos usar uma barra no final da linha ( / ) e continuar o comando na linha seguinte. Outra alternativa é colocar o comando dentro de um arquivo texto e atribuir permissão de execução para ele (por exemplo, chmod 700 arquivocomcomandolongo) e executá-lo. Nos testes feitos no Shell default do debian 5, codinome Lenny, não foi necessária a inclusão da barra invertida ( / ), mesmo para os comandos que não couberam em uma linha. $ awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > /home/pagliares/backupturingantigo/passwd.bak O utilitário awk facilita a criação de filtros para serem usados no momento de parsing do arquivo. No exemplo acima, criamos um arquivo /home/pagliares/backupturingantigo/passwd.bak, contendo apenas usuários com UIDs entre 1000 e (limite do Debian), descartando o usuário root (UID 0) e usuários do sistema (UIDs entre 1 e 999). Podemos agora fazer a cópia do arquivo /etc/group, com o mesmo raciocino desenvolvido anteriormente.

7 $ awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > /home/pagliares/backupturingantigo/group.bak No comando acima, a variável UGIDLIMIT é passada para o comando awk usando a opção -v (ela atribui o valor da variável do Shell UGIDLIMIT para o a variável chamada LIMIT). A opção F configura o separador de campos como sendo : (dois pontos). Finalmente o comando awk lê cada linha do arquivo /etc/passwd, filtra as contas do sistema e gera um novo arquivo /home/pagliares/backupturingantigo/passwd.bak. Fizemos procedimento semelhante para o arquivo /etc/shadow/. A principal diferença é que os comandos que acessam o arquivo /etc/shadow (awk e egrep) são precedidos de sudo : # sudo awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/passwd tee - sudo egrep -f - /etc/shadow > /home/pagliares/backupturingantigo/shadow.bak O arquivo /etc/gshadow, raramente usado, foi copiado por precaução # sudo cp /etc/gshadow /home/pagliares/backupturingantigo/gshadow.bak Depois de finalizados os passos acima, podemos listar o conteúdo do diretório /home/pagliares/backupturingantigo/ que deverá estar como abaixo: Observe que na figura acima, também listamos os arquivos e diretório /home originais para termos uma noção das diferenças de propriedades após o backup temporário (pode-se notar, por exemplo, que o arquivo /etc/shadow possui como proprietário o usuário root e permissão para o grupo shadow, enquanto sua cópia, /home/pagliares/backupturingantigo/shadows.bak, tem como proprietário o usuário pagliares e grupo de nome também pagliares). As propriedades originais serão restauradas após cópia do backup, via rede, discutido em seções posteriores. Finalizando, podemos observar que o arquivo ghadow.bak possui permissão 640. Isso impede que este arquivo seja copiado remotamente via scp (não podemos usar, por exemplo na máquina cliente scp root@ :/home/pagliares/backupturingantigo/gshadow.bak já que o usuário

8 root é desativado por padrão no Ubuntu). Para solucionar isso, vamos mudar a permissão deste arquivo para 644, permitindo que o arquivo seja copiado por um usuário que não seja root. No final do processo, restauremos as permissões originais (visto na próxima seção). # sudo chmod 644 /home/pagliares/backupturingantigo/ghadow.bak Eis a listagem final do backup contemplando a mudança de permissão acima (observe o r presente na terceira tríade do arquivo gshadow): 3.2.Roteiro para cópia de usuários e dados via rede Servidor Turing Novo Tendo feito o backup dos arquivos importantes e compactado os dados dos usuários no servidor antigo, podemos começar a migração para o servidor novo, também chamado turing. Lembre-se que os passos desta seção são executados no servidor novo! Para essa cópia, usaremos o scp conforme os passos abaixo: Passo 1: Criar um diretório para armazenamento do dados Primeiramente, criaremos um diretório para armazenar os dados de backup presentes no servidor antigo e que serão copiados via scp. Optamos por criar este diretório na pasta /home/rodrigo/migração, mas funcionaria para qualquer outro diretório com permissão de acesso. $ mkdir /home/rodrigo/migração Passo 2: Fazer a cópia dos arquivos remotos para o diretório recém-criado $ scp -r pagliares@ :/home/pagliares/backupturingantigo/ /home/rodrigo/migracao/ é o endereço IP do servidor antigo. Após a cópia, as permissões ficam conforme listagem abaixo:

9 Passo 3: Fazer o backup dos usuários do servidor novo novo: Por questão de segurança, vamos fazer um backup dos usuários atuais do servidor $ mkdir /home/rodrigo/migração/backupservidornovo $ su root # cp -a /etc/passwd /etc/shadow /etc/group /etc/gshadow /home/rodrigo/migração/backupservidornovo A opção a mantém os privilégios de acesso presentes nos arquivos de origem. Passo 4: Fazer a restauração dos arquivos de configuração de usuários copiados no servidor novo Antes de fazer a restauração, vamos configurar as devidas permissões (que foram alteradas no momento do backup feito no servidor antigo) $ cd /home/rodrigo/migração/backupturingantigo $ su root # chown root.root group.bak # chown root.shadow gshadow.bak # chmod 640 gshadow.bak # chown root.root home.tar.gz # chown root.root passwd.bak # chown root.shadow shadow.bak Ao final dos comandos acima, eis a listagem com as novas permissões :

10 Vamos agora restaurar os arquivos de configurações dos usuários do servidor antigo para o diretório /etc/ : $ cd /home/rodrigo/migração/backupturingantigo # cat passwd.bak >> /etc/passwd # cat group.bak >> /etc/group # cat shadow.bak >> /etc/shadow # cp a gshadow.bak /etc/gshadow Note que estamos usando o operador para inserção no final do arquivo >> (append) e não >, pois vamos manter os usuários de UID 0 a 999 existentes no servidor novo (os passos feitos na seção 3.1 fizeram o backup apenas dos usuários com UID acima de 999! Passo 5: Fazer a restauração dos dados pessoais dos usuários # cd / Vamos agora extrair o arquivo home.tar.gz para a pasta home do novo servidor. # tar xvf /home/rodrigo/migracao/backupturingantigo/home.tar.gz Passo 6: Reiniciar o sistema Vamos agora reiniciar o sistema. Após isso, o procedimento estará finalizado e poderemos logar normalmente com qualquer usuário cadastrado no sistema antigo, incluindo o usuário root que somente está habilitado no servidor debian novo. # reboot 4. Limitando a quantidade de espaço em disco por usuário - Quota Através do serviço quota, é possível limitar a quantidade de espaço em disco disponível para cada usuário. Usamos este serviço no servidor antigo, permitindo que cada aluno possa usar no máximo 200MB de espaço em disco. Para tal, configuramos o quota para atuar sobre a partição /home já que é essa partição que os usuários possuem acesso para gravação de dados.

11 Primeiramente, podemos verificar a presença/ausência do pacote quota com o comando dpkg l grep quota (dois ii antes do nome do pacote indica que está instalado). Para sabermos se o serviço está rodando, podemos usar ps aux grep quota. Outra alternativa é usar aptitude search quota (um indicador i na coluna anterior ao nome do pacote indica que o mesmo está instalado). Todas essas possibilidades foram executadas no servidor Turing antigo conforme figura abaixo. Caso ainda não esteja instalado, para que o quota funcione, é necessário instalar os pacotes quota e quotatool, que contém um conjunto de utilitários para verificar as quotas de disco. Para instalá-los, digite o comando # apt-get install quota quotatool Em seguida é necessário carregar o módulo quota_v2 para ativar o suporte necessário no kernel e para que o mesmo seja carregado no momento de boot. Uma das formas de fazer isso, é incluir a linha quota_v2 no final do arquivo /etc/modules. O quota é utilizado através do sistema de arquivos, para ativá-la temos que editar o arquivo /etc/fstab e adicionar as opções "usrquota" e "grpquota". No screenshot abaixo, adicionamos em /dev/sda5, que está sendo utilizado para o /home: Verificar o que é a opção relatime, presente no /etc/fstab

12 Precisamos agora, criar dois arquivos de controle, o aquota.user e aquota.group, com permissão de leitura e escrita somente para o root, observando que os arquivos devem ser criados no ponto de montagem do sistema de arquivos, neste caso "/home". # cd /home # touch aquota.user aquota.group # chmod 600 aquota.user # chmod 600 aquota.group Devemos reiniciar o sistema para que a quota entre em vigor. Após reiniciado podemos verificar o status com: # repquota -av Colar figura Para definir uma cota para um usuário no sistema, devemos primeiramente definir o editor que será usado via linha de comando: # EDITOR=nano Para criar a quota para um usuário, use a opção -u : # edquota -u pagliares Basta agora inserir os valores sob as colunas soft e hard (terceira e quartas colunas). O valor soft é um limite de advertência, inferior ao valor hard. Sempre que ultrapassar este valor, o usuário receberá uma mensagem de alerta, mas o usuário ainda poderá gravar, até que atinja o limite estabelecido na coluna hard, quando a gravação dos novos arquivos é bloqueada. Podemos também especificar o Grace period, que é o tempo máximo que o usuário pode ficar acima do limit soft. No exemplo abaixo pagliares tem uma quota de 200Mb(hard) sendo gerado um alerta quando atingir 150MB(soft). Não definimos o grace period: Figura A criação individual de cotas para todos os usuários (alunos, professores, etc..) demanda muito tempo. Uma alternativa é criar a cota por grupos. Por exemplo, todos os alunos cadastrados no sistema pertencem ao grupo aluno, o que pode ser verificado pelo comando no Turing antigo. # cat /etc/group grep aluno

13 Assim sendo, podemos criar uma cota de 200MB para todos os alunos do grupo com o comando: # edquota g aluno Conforme figura acima, estamos adicionando uma cota de 200MB por aluno individual pertencente ao grupo aluno, com alerta após 150MB ser ocupado Após criada a cota para o grupo, devemos reiniciar o serviço ou o servidor # /etc/init.d/quota force-reload Ou # reboot Após reiniciado, podemos verificar a mudança nas cotas para todos os alunos cadastrados no grupo aluno # quota g aluno ou # repquota av Ou repquota /home Colar figura 5. Servidor de Arquivos com NFS, NIS e Samba De longe, a melhor maneira de centralizar o compartilhamento de dados é através de um servidor de arquivos. O samba permite o compartilhamento de arquivos com PCs Windows na sua rede enquanto que o NFS permite o compartilhamento de arquivos para

14 máquinas GNU/Linux. Normalmente o NFS é combinado com o NIS para permitir que máquinas clientes GNU/Linux sejam autenticadas de forma centralizada no servidor Servidor NFS O NFS, Network File System, permite que se estenda o sistema de arquivos do Linux, conectando sistemas de arquivos de outros computadores na estrutura local de diretórios. Os passos básicos para configuração do NFS são: - Escolher o que compartilhar no servidor - Definir a política de segurança no compartilhamento - Montar o sistema de arquivos nas máquinas clientes. O principal arquivo de configuração do NFS é o Para instalar o NFS, seguimos os seguintes passos - # apt-get install nfs-common portmap nfs-kernel-server Após instalados os pacotes, podemos configurar o servidor NFS, editando o arquivo /etc/exports. Como nosso intuito é clonar o servidor, iremos copiar este arquivo para a máquina servidora nova. # cd /etc/ # scp pagliares@ :/etc/exports. O arquivo de configuração /etc/exports, define o diretório /tftpboot (verificar pra que serve) como sendo um dos diretórios exportados pelo servidor. Assim sendo, para a correta execução do servidor NFS, precisamos copiar este diretório para a raiz da máquina servidora nova. # cd / # scp r pagliares@ :/tftpboot/. Uma vez copiados o arquivo de configuração e o diretório /tftpboot, podemos iniciar o servidor NFS # /etc/init.d/nfs-kernel-server start # /etc/init.d/nfs-common start Os sistemas de arquivos do servidor precisam ser montados nas máquinas GNU/Linux atuando como cliente. A maneira mais simples de fazer isso é via arquivo /etc/fstab para que a montagem seja feita em momento de boot. Eis a configuração necessária nas máquinas cliente para correta montagem do diretório remoto nas máquinas clientes que usam GNU/Linux.

15 Conteúdo do /etc/fstab das máquinas do laboratório Servidor NIS O NIS (Network Information Server) é uma base de dados distribuída, que mantém, num servidor os arquivos que serão acessados pelos clientes. O NIS autentica os usuários através de sua base de dados chamada "yp". Os usuários ao se logarem no sistema, em qualquer computador da rede, terá seu login e senha autenticados no servidor. O servidor autentica e envia pro cliente o profile do usuário. A grande utilidade do NIS é possuir todos os usuários em uma máquina facilitando a administração. A configuração deve ser feita tanto no servidor quanto no cliente. Recomenda-se primeiramente configurar o servidor, instalando o servidor NFS e depois o NIS. Posteriormente nas estações, configurar primeiro o NFS e depois o NIS, pois o NIS necessitará que o NFS esteja corretamente configurado para poder efetuar o processo de autenticação corretamente. Por fim, todas as configurações de IP devem obrigatoriamente serem configuradas no boot automaticamente. Podemos agora instalar os pacotes necessários do servidor nis: # apt-get install nis # apt-get install portmap Agora edite o arquivo /etc/defaultdomain e insira nele o nome do domínio(bccunifal no nosso caso) que irá usar para sua rede: # echo BCCUNIFAL > /etc/defaultdomain Após isto execute o comando domainname para verificar a alteração, talvez precise reiniciar o serviço (/etc/init.d/nis) para a alteração ser visualizada. Edite o arquivo /etc/default/nis e altere a seguinte linha: NISSERVER=false para NISSERVER=master Reinicie o NIS e o Portmap: sudo /etc/init.d/portmap restart sudo /etc/init.d/nis stop sudo /etc/init.d/nis start Após iniciar o NIS devemos popular a sua base de dados com o seguinte comando: # /usr/lib/yp/ypinit -m Com a execução do script será criado os mapas que ficarão armazenados no diretório /var/yp/bccunifal.

16 A partir deste ponto o servidor NIS já esta em funcionamento, e qualquer alteração realizada na base de dados de usuários do servidor devemos refazer os mapas do NIS, de forma a disponibilizar as informações para as estações. Para tanto executamos (após a criação de usuários/alteração de senha/criação de grupos) o seguinte comando: # cd /var/yp # make Após esse procedimento, editar o arquivo /etc/hosts adicionando uma linha contendo o nome do domínio e o ip associado a ele, por exemplo: # nano /etc/hosts Após abrir, adicionar a seguinte linha: BCCUNIFAL Colocar o servidor NIS e PORTMAP para iniciarem automaticamente ao iniciar o sistema. Configuração das estações para logarem no servidor NIS Siga os passos abaixo: 1. Instalação via apt-get dos pacotes necessários: # apt-get install nis # apt-get install portmap 2. Editar o arquivo /etc/yp.conf e adicionamos a seguinte linha: # nano /etc/yp.conf Atualizar a linha com o servidor yp: ypserver Editar o arquivo /etc/nsswitch.conf: # nano /etc/nsswitch.conf As linhas a alterar são as passwd, group e shadow, e deverão ficar conforme abaixo: passwd: files nis group: files nis shadow: files nis 4. Altere o arquivo /etc/defaultdomain informando o nome do seu domínio: # echo BCCUNIFAL > /etc/defaultdomain 5. Após esse procedimento, editar o arquivo /etc/hosts adicionando uma linha contendo o nome do domínio e o ip associado a ele, por exemplo: # nano /etc/hosts Após abrir, adicionar a seguinte linha: BCCUNIFAL 6. Reinicie o NIS e Portmap: sudo /etc/init.d/portmap restart sudo /etc/init.d/nis stop sudo /etc/init.d/nis start

17 7. Para checar se as modificações ocorreram de forma satisfatória podemos verificar se o /etc/passwd do servidor NIS esta disponível na estação, executando o seguinte comando: sudo getent passwd. Este comando deverá listar o conteúdo do /etc/passwd do servidor e não da estação. 8. Colocar o NIS e PORTMAP para iniciarem automaticamente ao iniciar o sistema, lembrando que o IP da estação deverá ser carregado no boot automaticamente.