Sistemas de arquivos para GNU/Linux

 Clusterweb, Firewall, Linux, Redes  Comentários desativados em Sistemas de arquivos para GNU/Linux
mar 082013
 
Introdução

Antes de começar a falar sobre os sistemas de arquivos, temos que ter em mente o que é um sistema de arquivos.

Sistema de arquivos é uma estrutura lógica que permite armazenar informações em massa e de forma bem organizada, permitindo que um Sistema Operacional ou aplicações possam ser usadas pelo computador, assim como gravar novas informações, e essas informações possam ser acessadas posteriormente.

Um sistema de arquivos depende de estruturas de dados sobre os arquivos. Uma dessas estruturas são os metadados de dados que descrevem os dados. Cada arquivo está associado com um inode, o qual é identificado por um número inteiro, muitas vezes referido como um número ‘i-‘, ou número de inode.

Inodes armazenam informações sobre arquivos e diretórios (pastas), tais como a propriedade do arquivo, modo de acesso (ler, escrever, executar permissões) e tipo de arquivo. Em muitos tipos de implementações de sistemas de arquivos, o número máximo de inodes é fixado no momento da criação do sistema de arquivos, limitando o número máximo de arquivos que o sistema de arquivos pode conter.

– Posso usar Sistema Operacional, ou alguma aplicação, sem ter que aplicar um sistema de arquivos?

Não, o disco rígido que armazena as informações é formatado fisicamente pelo fabricante, e esse tipo de formatação não faz com que o disco possa armazenar informações, porém, não se consegue utilizar o mesmo, pois ainda precisa de uma estrutura lógica para utilizar todo o espaço que o disco disponibiliza.

Objetivo do artigo

Não faz parte do objetivo do artigo fazer um estudo aprofundado sobre cada sistema de arquivos abordado, mas sim, abordar as características dos mesmos, permitindo conhecer mais de cada um.

Esclarecimentos

Todo e qualquer sistema de arquivos não é ANTI-FALHAS.

O mesmo não impede que sua estrutura de dados fique corrompida ou danificada após um desligamento inesperado causado por falta de energia, ou por travamento no sistema ou aplicação, fazendo com que você seja obrigado a usar o botão de desligamento ou de reinicialização.

E após desligar ou reinicializar desta forma, pode ter certeza que seu HD logo ficará com badblocks, principalmente se este tipo de situação acontecer constantemente. Não se impressione se o seu sistema, após um acontecimento destes, não conseguir mais ser acessado, ou precisar de reparos manuais para poder ser usado novamente.

O único sistema que ouvi falar bem quanto à tolerância de falhas, mas não cheguei a usar e nem a testar, foi o ZFS, desenvolvido pela Sun Microsystems.

Aí você pode se perguntar:

– Mas o que é um ‘badblock’ e por quê o sistema pode ficar corrompido, caso aconteça o que você citou acima?

1° – Um ‘badblock’ é uma área danificada de um disco que não pode ser mais utilizada, pois o dano é permanente.

Este tipo de dano pode ser causado por desligamentos forçados, como por exemplo, apertar o botão de desligamento da máquina, assim como reinicialização forçada, formatações erradas, esbarrões no HD, falta de energia etc.

Quando há muitos ‘badblocks’, seu HD está próximo do fim de sua vida útil, pois o mesmo está com muitos problemas.

2° – O sistema de arquivos pode ficar corrompido e o SO ficar inacessível, porque algum, ou alguns dados que estejam sendo utilizados pelo sistema no momento em que acontece o que foi citado anteriormente ainda não foram salvos, fazendo com que o mesmo fique incompleto, sendo assim corrompido. E se um arquivo deste for importante para o sistema, pode fazer com que o sistema fique inacessível.

Porém, muitos dos sistemas de arquivos tem tolerância de falhas, alguns mais consistentes e robustos que os outros.

Para os sistemas de arquivos usados no GNU/Linux, toda essa consistência tem ajuda do recurso muito utilizado que é o Journaling.
Journaling

Journaling é um recurso usado pelos sistemas de arquivos que consiste em uma área dedicada para registros, armazenando todas as ações que serão feitas nos arquivos, como gravação e/ou alteração de dados, por exemplo. Seja armazenamento somente de metadados, ou de metadados e dados de arquivos, permitindo restaurar o sistema de arquivos, caso aconteça algum erro inesperado.

A principal finalidade do ‘journaling’ é recuperar o sistema de arquivos de erros (tolerância de falhas), sejam eles causados pelo sistema, aplicações ou desligamentos incorretos de forma forçada ou inesperada.

Com isso é possível localizar todas as operações que não haviam sido completadas, restaurando a consistência do sistema de arquivos e permitindo que o sistema operacional continue sendo utilizado.

Aí você ainda fica com dúvida e pergunta: Mas como assim?

Com o ‘jounaling’, o sistema de arquivos passa a registrar em uma área especial chamada journal, ou log, as ações que serão feitas nos arquivos (gravação ou alteração de dados, por exemplo) antes da gravação no FS em si.

Após a execução, as operações registradas no log são tidas como concluídas e, portanto, eliminadas. Note que todo este procedimento acontece de maneira extremamente rápida.

Mas em que exatamente, o ‘journaling’ mostra-se vantajoso?

Os registros de log são escritos antes que as mudanças efetivamente ocorram no sistema de arquivos. Estes registros somente são eliminados quando as mudanças são executadas.

Se, por exemplo, o computador for desligado repentinamente (como ocorre em falta de energia elétrica), o sistema de arquivos verificará os registros existentes no ‘journal’ e executará aquilo que estiver marcado como não realizado. Isso faz com que o risco de perda de dados diminua drasticamente, já que o sistema operacional saberá ‘onde parou’.

Porém temos que ter em mente que este recurso não é anti-falhas e sim, um recurso para tolerar falhas até um certo ponto. Pois esta tolerância não previne 100% de erros como os citados anteriormente, toda essa tolerância a falhas pode acabar de uma hora para outra, após várias quedas de energia ou desligamentos forçados.

Contudo, nem todos os sistemas de arquivos que usam o ‘journaling’ possuem uma boa implementação do mesmo, fazendo com que este recurso não seja 100% confiável.

Se você começar a desligar o sistema incorretamente com frequência, vai perceber que, algumas vezes, o sistema não será capaz de verificar o ‘journal’, e o sistema de arquivos terá que ser verificado usando um utilitário para verificação da integridade do sistema de arquivos, tentando localizar todas as operações que não haviam sido completadas para tentar recuperar a integridade de alguns arquivos, fazendo com que, quase sempre, alguns arquivos sejam perdidos.

Técnicas de journaling

  • Journal Físico: Consiste em registrar uma cópia antecipada de todos os blocos de arquivos que serão posteriormente gravados no sistema de arquivo principal. Se houver uma falha quando o sistema de arquivos está gravando, a gravação pode simplesmente ser repetida até a conclusão, quando o sistema de arquivo for montado da próxima vez.

    Se houver uma falha quando a gravação está sendo registrado no journal, a gravação parcial terá um checksum ausente, ou incompatível, e pode ser ignorada na próxima montagem do sistema de arquivos.

  • Journal Lógico: Consiste em gravar apenas os metadados que sofrerão ações, tais como leitura/gravação e alteração dos arquivos. Um sistema de arquivos, com uma ‘journal’ lógico, ainda recupera-se rapidamente após um acidente, mas pode permitir que os dados não sejam recuperados devido a não gravação antecipada dos blocos do arquivo alterado ou em uso, causando corrupção de dados. Porém, isso aumenta o desempenho, nota-se mais isso na inicialização do sistema.

Outras informações

Os sistemas de arquivos para GNU/Linux: JFS, XFS, ReiserFS, ext3 e ext4, possuem ‘journaling’.

O arquivo de log do ‘journaling’ pode estar no mesmo sistema de arquivos, ou em um sistema de arquivos de outra partição, e/ou outro disco. E seu tamanho pode ser aumentado também para melhorar o desempenho.

Então o ‘journaling’ torna-se indispensável para os sistema de arquivos usados hoje e no futuro, pois é através deste recurso que temos uma certa tolerância a certos acontecimentos não planejados.
Sistema de arquivos ext3

O sistema de arquivos ext3 já está entre a comunidade GNU/Linux a muito tempo e ainda é bastante utilizado. O ext3 é uma atualização do sistema de arquivos ext2.

Em relação ao ext2, a principal diferença é a implementação do journaling, um recurso muito interessante abordado na segunda página deste artigo, que consiste no armazenamento de registros para posterior restauração das informações, caso aconteça algum erro.

Principais vantagens

1. Possui journaling. Há três níveis de operação do journaling disponíveis na implementação do ext3:

  • Modo de Operação Ordered (default): O journal é atualizado no final de cada operação. Isto faz com que exista uma pequena perda de desempenho, já que os dados são gravados duas vezes, uma no arquivo que foi alterado ou gravado, por exemplo, e outra no journal. O conteúdo dos blocos de cada dado não é armazenado no journal, porém, os metadados de cada arquivo são armazenados no journal antes dos dados serem escritos no disco, assim como marcação de alteração dos metadados dos arquivos.
  • Modo de Operação Writeback: O journal armazena apenas informações referentes à estrutura do sistema de arquivos (metadata) e não em relação aos arquivos propriamente ditos, e é gravado de forma mais ocasional, aproveitando os momentos de inatividade.

    Este modo é o mais rápido, mas em compensação oferece uma segurança muito menor contra perda e corrompimento de arquivos causados pelos desligamentos incorretos.

  • Modo de Operação Journal: Que é o mais seguro, porém, mais lento. Nele, o journal armazena não apenas informações sobre as ações sofridas, mas também uma cópia de segurança de todos os arquivos modificados, que ainda não foram gravados no disco. A cada alteração, o sistema grava uma cópia do arquivo (no journal), atualiza as informações referentes à estrutura do sistema de arquivos, grava o arquivo e atualiza novamente o journal, marcando a operação como concluída. Como disse, isso garante uma segurança muito grande contra perda de dados, mas em compensação, reduz o desempenho drasticamente. Justamente por causa disso, este é o modo menos usado.

O modo de operação padrão é o Ordered, porém não significa dizer que você não consiga mudar isso. Para usar o modo Writeback ou o modo journal, você deve adicionar a opção “data=writeback” ou “data=journal” nas opções referentes à partição, dentro do arquivo /etc/fstab ou usando o comando tune2fs.

2. Possui indexação de maior quantidade de diretórios;

3. Suporte para tamanhos maiores de volumes e arquivos em relação a sua versão anterior.

Veja abaixo uma tabela:

Tamanho do bloco   Tamanho máx. arquivo   Tamanho máx. fs
1 KiB                            16 GiB             2 TiB
2 KiB                           256 GiB             8 TiB
4 KiB                             2 TiB            16 TiB
8 KiB                            2 TiBsp           32 TiB

4. O ext3 ainda pode contar com algumas ferramentas para gerenciamento de sistema de arquivos extFS, tais como:

  • tune2fs
  • mke2fs
  • debugfs
  • e2fsck

Principais desvantagens

  • Funcionalidade: Como o ext3 visa uma grande compatibilidade com o ext2, muitas das estruturas on-disk são similares àquelas do ext2. Por causa disso o ext3 não possui muitas das funções mais recentes, como alocação dinâmica de inodes e tamanhos de blocos variáveis (fragmentos ou caudas).

    Os sistemas de arquivos ext3 não podem ser checados enquanto são montados para escrita. Um dump do sistema de arquivos feito enquanto ele está sendo montado para leitura e escrita pode resultar em dados corrompidos dentro do arquivo de dump.

  • Desfragmentação: Apesar de não fragmentar muito o disco na estrutura do ext3, não há uma ferramenta para desfragmentação online funcional em nível de sistema de arquivos.
  • Recuperação de dados deletados: Diferentemente do ext2, o ext3 zera os ponteiros de blocos nos inodes de arquivos apagados. Ele faz isso para simplificar o acesso de leitura e escrita quando o journal está sendo utilizado após uma montagem.

    Isso, no entanto, previne efetivamente que os arquivos sejam recuperados. Isso provê uma remoção de arquivos um pouco mais segura que em sistemas ext2, o que pode ser tanto uma vantagem quanto uma desvantagem.

  • Verificação do sistema de arquivos: O ext3 é considerado lento na verificação do sistema de arquivos.
  • Criação do sistema de arquivos: O ext3 é lento quando se aplica um sistema de arquivos, e se o disco tiver que marcar badblocks, demora mais ainda.

O sistema de arquivos ext3, apesar de possuir journaling, não foi desenvolvido desde o inicio para suportar o journal, e sim, foi integrado a partir da versão 3 do mesmo, por isso, o journal não é tão eficaz no ext3.

E quando o journal falha, ele faz uso do fsck para verificar a integridade do sistema de arquivos, e se o fsck não conseguir recuperar a integridade do mesmo, seu sistema de arquivos fica corrompido.

Para muitos, este sistema de arquivos é obsoleto e para outros estável, e tem um bom desempenho.
Sistema de arquivos ext4

O sistema de arquivos ext4 é última versão do sistema de arquivos extFS até o momento, ele é na verdade a atualização do ext3, já abordado no artigo.

O ext4 trouxe, de acordo com seus desenvolvedores, alguns recursos que não existiam no ext3, mantendo alguns que a versão anterior já possuía. Na verdade são recursos que estavam tentando implantar na versão 3 do extFS (ext3), porém, devido a alguns problemas na implementação, lançaram essa nova versão com as características descritas abaixo.

Principais vantagens

  • Possui journaling com aprimoramento de checksum.
  • Melhorias no journaling: Checagem no journaling, checksum aprimorado permitindo ao ext4 ter mais tolerância à falhas que o ext3 e restruturação mais rápida;
  • Suporte para tamanhos maiores de volumes e arquivos em relação à versão 3. O ext4 tem uma margem de 1024 PB (Petabytes) ou 1EB (Exabyte) para partições e 16 TB por arquivo. Isto pode não ser importante para desktops ou servidores simples, porém com certeza é útil para servidores grandes, configurados em Raid e de alta disponibilidade.
  • A indexação de quantidade de diretórios foi aumentada;
  • Suporte a recuperação de arquivos Undelete: Suporte à recuperação de arquivos, permitindo que arquivos seja recuperados.
  • Checagem rápida do sistema de arquivos: O fsck está mais rápido por que a nova estrutura de organização de blocos permite que partes não usadas do HD sejam puladas, o que economiza tempo numa eventual checagem.
  • Desfragmentação online: ext3 deixava os arquivos com um pouquinho, mas bem pouquinho de fragmentação. Agora não deixa mais. O ext4 vai desfragmentando enquanto os arquivos vão sendo alocados.
  • Melhorias na pré-alocação: Às vezes um programa vai usar um espaço do HD mas não na hora, então ele reserva o espaço que vai usar, fazendo uma pré-alocação, ou seja, ele guarda aquele espaço pra ele e ninguém mais pode usar, como se fosse uma reserva. Para essa ação, a maioria dos file systems enchem de zeros os inodes que eles vão reservar.

    Quando essa ação é executada milhares de vezes, como em um banco de dados, esse tempo de escritas de zeros geram um delay de tempo desnecessário. O ext4 vai permitir pré-alocação de arquivos sem fazer isso, o que vai garantir uma melhoria na performance, principalmente nas rotinas de bancos de dados e em ferramentas multimídia.

  • Tempo de alocação estendido: O ext4 vai conseguir manter a alocação do espaço em disco até o último momento, o que pode trazer mais performance.
  • Maior número de subdiretórios: O ext3 colocava um limite de subdiretórios ou pastas de 32000, se você achava isso um incômodo, os limites serão apenas o do espaço fornecido pelo disco.
  • Alocação tardia: ext4 usa uma técnica de execução do sistema de arquivos chamado allocate-on-flush, também conhecida como a atribuição de atraso. Isso melhora o desempenho e reduz a fragmentação, melhorando a alocação de blocos decisões com base no tamanho do arquivo.
  • O ext4 ainda pode contar com algumas ferramentas para gerenciamento de sistema de arquivos extFS, tais como o tune2fs, mke2fs, debugfs e e2fsck.

Principais desvantagens

1. Alocação tardia e potencial perda de dados:

Com as mudanças de alocação atrasada, este recurso representa algum risco adicional de perda de dados nos casos em que o sistema trava antes que todos os dados tenham sido gravados no disco.

Devido a isto, o ext4, na versão 2.6.30 do kernel GNU/Linux, detecta automaticamente estes casos e reverte para o comportamento antigo. O cenário típico em que isso pode ocorrer é um programa que substitui o conteúdo de um arquivo sem forçar uma gravação para o disco com sync.

2. Criação do sistema de arquivos:

Assim como no ex3, o ext4 é lento quando se aplica um sistema de arquivos, e se o disco tiver que marcar badblocks, demora mais ainda.

O sistema de arquivos ext4, apesar de possuir journaling, não foi desenvolvido desde o inicio para suportá-lo e este recurso foi integrado a partir da versão 3 do mesmo, por isso o journal não é tão eficaz, nem no ext3 e no ext4, apesar que o último mencionado teve melhorias.

E quando o journal falhar, ele faz uso do fsck para verificar a integridade do sistema de arquivos, e se o fsck não conseguir recuperar a integridade do mesmo, seu sistema de arquivos fica corrompido.

Atualmente o ext4 é bem rápido, tem um ótimo desempenho, mas seu journal pode deixar a desejar quanto à tolerância de falhas, apesar que o mesmo teve melhorias e resiste bem.
Sistema de arquivos XFS

O sistema de arquivos XFS é considerado por muitos de alto desempenho, é um sistema de arquivos de 64 bits sendo compatível com sistemas de 32 bits. Foi desenvolvido inicialmente para o SO IRIX, depois portado para o kernel GNU/Linux.

O kernel e a maioria dos sistemas GNU/Linux dão suporte durante a instalação para usar o XFS como sistema de arquivos de suas partições, e assim, como os outros sistemas de arquivos apresentados até agora, possui journaling.

Principais vantagens

  • Possui journaling em sua estrutura, porém o journal no XFS se comporta de forma similar a outros sistemas de arquivos, mantendo somente a gravação dos metadados dos arquivos no journaling, fazendo com que a consistência do sistema de arquivos como um todo fique preservada.

    Diferente do que faz outros sistemas de arquivos, que se um arquivo ficar corrompido, o sistema fica inacessível, porém, se um arquivo estiver sendo usado e as alterações nos metadados não forem gravadas antes de um erro ou falha (falta de energia por exemplo), poderá ficar corrompido, já que seu conteúdo não foi salvo e os metadados não foram colocados no journal antes da gravação do arquivo no sistema de arquivos.

  • É um sistema de arquivos de 64 bits compatível com sistemas de 32 bits também.
  • Em sistemas 64 bits há um limite de tamanho de 8 EiB para cada arquivo, já em sistema de 32 bits o tamanho máximo do volume ou arquivo é limitado a 16 TiB.
  • Tamanhos de blocos variáveis: Tamanho de blocos do sistema representa a unidade de alocação mínima. XFS permite que o sistema de arquivos seja criado com tamanhos de blocos que variam entre 512 bytes e 64 kilobytes, permitindo que o sistema de arquivos ajuste-o para o uso esperado.

    Quando está trabalhando com muitos arquivos pequenos, um tamanho de bloco pequeno é o ideal, mas para um sistema lidando principalmente com arquivos grandes, um tamanho de bloco maior pode proporcionar uma vantagem quanto ao desempenho.

  • A desfragmentação online: Embora o XFS use alocação com atraso, isso melhora significativamente a resistência do sistema de arquivos para os problemas de fragmentação. XFS fornece um utilitário de desfragmentação que pode desfragmentar os arquivos com o sistema de arquivos em uso.
  • A criação do sistema de arquivos XFS é muito rápida.
  • Redimensionamento online: XFS oferece a ‘xfs_growfs’, utilitário para executar o redimensionamento online de sistemas de arquivos XFS.

    Espaço onde se encontra o sistemas de arquivos XFS podem ser alterados desde que haja espaço restante não alocado no dispositivo para adicionar ao XFS. Este recurso é normalmente usado em conjunto com o gerenciamento de volume, caso contrário a partição que mantém o sistema de arquivos terá que ser ampliada separadamente.

  • Utilitários para gerenciamento do sistema de arquivos inclusos no xfsprogs, tais para checagem do mesmo, aplicação do sistema de arquivos, ajustes no sistema de arquivos entre outros.
  • Cotas de disco: Cotas para sistemas de arquivos XFS são ativadas quando o sistema de arquivos é montado, diferente de outros sistemas de arquivos que na maioria exigem serem montados primeiro para depois ativar a quota com o quotaon.
  • Trabalha muito bem com arquivos grandes (leitura e gravação), principalmente em sistemas que armazenam muitos arquivos de grande tamanho. Lembre-se o XFS foi desenvolvido para trabalhar em grandes sistemas, principalmente de 64 bits.

Principais desvantagens

  • Redimensionamento do XFS não pode ser usado para diminuir o tamanho do mesmo, apenas aumentar.
  • Operações usando metadados em XFS são muito lentas do que com outros sistemas de arquivos, produzindo mau desempenho em operações como deleções em massa de grandes números de arquivos pequenos.
Sistema de arquivos ReiserFS

O sistema de arquivos ReiserFS foi criado por Hans Reiser e pode ser usado pelas distribuições GNU/Linux, sendo que algumas dão bom suporte durante a instalação e outras não. Sua versão atual é a 3.6.x. O ReiserFS foi o primeiro sistema de arquivos com suporte a journaling incluído no núcleo do GNU/Linux.

Algo muito interessante no ReiserFS é suporte ao journaling implantado desde o início e não depois de ter sido desenvolvido (como foi feito no extFS). Isso garante que o ReiserFS trabalhe melhor com o journal, possibilitando uma tolerância contra falhas mais eficaz.

Principais vantagens

  • Suporte a journaling, o mesmo foi integrado desde de seu desenvolvimento. Diferentemente do que acontece no ext3 e ext4, que foi implementado em versões posteriores após o desenvolvimento da primeira versão.

    O extFS permite trabalhar em vários modos de operação, já no ReiserFS é importante frisar que as técnicas de journaling limitam-se, por padrão, aos metadados (conjuntos de informação sobre arquivos, como tamanho, proprietário, permissões, data de alteração etc). Contudo, o usuário poderá alterar seu modo de operação para journal ou writeback, pois o ReiserFS também suporta os três modos de operação assim como no extFS, versão 3 e 4. Como o journaling está presente desde o inicio, faz com que esse sistema de arquivos seja eficiente na recuperação do sistema operacional como um todo em caso de problemas.

    No caso de um desligamento incorreto do sistema, o ReiserFS é capaz de recuperar a consistência do sistema de arquivos em pouco tempo e a possibilidade de perda de pastas ou partições é reduzida.

    Em compensação, os arquivos que eventualmente estiverem sendo gravados no exato momento em que acabou a energia, ficarão com seus dados corrompidos, haverá acesso aos arquivos normalmente, mas o conteúdo estará truncado ou incompleto.

  • Organização dos objetos do sistema de arquivos em uma estrutura de dados chamada B+Trees (árvores B+). Neste esquema, os dados são fixados em posições organizadas por divisões denominadas folhas.

    As folhas por sua vez são organizadas por nós, chamados de sub-árvores, que estão ligados a um nó raiz. Esse processo organizacional é mais complexo, porém apresenta performance superior na gravação e no acesso aos dados se comparado a outros sistemas de arquivos.

  • Alocação dinâmica de inodes (em poucas palavras, inodes são estruturas que contém informações sobre os arquivos), diminuindo o desperdício de espaço. Outros sistemas de arquivos têm blocos de tamanho fixo para alocação, assim, se não for necessário usar um bloco inteiro, o espaço restante fica em desuso. No ReiserFS a alocação é feita com base no tamanho do arquivo.
  • ReiserFS tem progsreiserfs, que é um conjunto de utilitários para gerenciamento de sistema de arquivos, para checagem, formatação, depuração etc.
  • A formatação em ReiserFS é muito rápida.

Principais desvantagens

  • Uma desvantagem do ReiserFS é seu consumo de CPU muito elevado, chegando a usar até 99% quando a atividade de disco é elevada.
  • O futuro do ReiserFS é atualmente dado como incerto, em virtude da prisão, em 10 de Outubro de 2006, de Hans Reiser, seu criador, e sua condenação em 28 de Abril de 2008 pelo assassinato de sua mulher no início de Setembro de 2006.

Atualmente, devido à paralisação das atividades da Namesys, que é sua principal desenvolvedora junto com Hans Reiser, o projeto ReiserFS está armazenado em kernel.org.

O ReiserFS tem um nova versão, que é a 4, mas a mesma ainda não está inclusa no kernel versão 3.x.x, que atualmente é 3.4.2 no momento da criação deste artigo, pois os desenvolvedores afirmam que o Reiser4 não segue o padrão GNU/Linux de decodificação.

Para mais informações sobre o Reiser4, acesse link:
Sistema de arquivos JFS

O JFS foi criado com o propósito principal de ser utilizado em servidores que deveriam usar poucos recursos do processador, e ser capaz de ser redimensionado mesmo em uso. JFS é um sistema de 64 bits, assim como XFS, onde existem duas versões: JFS1 e JFS2. No pinguim é usada a versão 2.

JFS está disponível na maioria das distros, assim como outros, mas durante a instalação o FS padrão, em sua maioria, é o ext4.

Principais vantagens

  • Reparação muito eficaz de um disco com badblocks, ele consegue marcar os setores defeituosos com muita precisão, algo que outros sistemas de arquivos para Linux não fazem.
  • Criação do sistema de arquivos muito rápida, desde que não inclua para marcar os badblocks existentes do disco, pois se fizer isso vai demorar bastante.
  • Possui vários utilitários para gerenciar o sistema de arquivos, todos eles inclusos no jfsutils, para aplicação e verificação de integridade do sistema de arquivos.
  • Baixo consumo do processador.
  • Suporte a journaling: O JFS usa um journal para manter somente a consistência dos metadados, ou seja, grava somente os metadados dos arquivos que sofrerão ações como modificação, por exemplo. Assim, apenas consistência de metadados (e não o conteúdo de arquivo) pode ser assegurado no caso de desligamento inadequado. Este é também o comportamento de XFS . Ext3 e ext4, por outro lado, usam o journal para gravar os metadados e os dados, apesar de ter outros modos de operação.
  • Alocação dinâmica de inodes: JFS aloca dinamicamente espaço em disco.

Principais desvantagens

  • Taxas de transferências baixas, nunca espere transferências com alta velocidade, pois o mesmo é lento.
  • Foi desenvolvido com o propósito principal de trabalhar com arquivos grandes e não trabalha bem com arquivos pequenos. Na criação e desempacotamento de arquivos sua velocidade é baixa.
  • O tamanho de uma partição e arquivo com o sistema de arquivos JFS aplicado só abriga 2 terabytes de espaço no total.
Benchmark básico dos sistemas de arquivos

Depois de tantas informações sobre cada sistema de arquivos abordado, você pode ficar com, no mínimo, um pouco de curiosidade de saber o desempenho de cada um deles em teste.

Aqui vou mostrar vários gráficos que comparam o desempenho de cada um, trata-se de benchmark básico.

ESCLARECIMENTO: Para este Benchmark não fiz otimização em nenhum dos sistemas de arquivos, todos foram instalados com suas opções padrões. O SO usado para testar foi o Debian 6, rodando em uma máquina com processador Intel Core 2 Duo e espaço em memória de 4 Gigas, além de um disco SATA Samsung.

Todos os testes não informam o uso de CPU, apenas o tempo que foi necessário para concluir a tarefa, e foram feitos em modo texto.

Primeiro teste

Trata-se de criar um arquivo de 10 Gigabytes de tamanho em cada sistema de arquivos usando o comando dd, todos concluíram o teste em minutos. Veja o resultado no gráfico abaixo:

Neste teste o mais veloz foi ext4, seguido de ext3 e logo depois XFS, seguido de ReiserFS e em último ficou o JFS.

Segundo teste

Foi desempacotado um arquivo do kernel 3.4 com tamanho de 77 Megas e todos concluíram a tarefa em menos de um minuto, ou seja, concluíram em segundos. Veja o resultado no gráfico abaixo:

Neste segundo teste, ext4 também foi mais rápido, mas a diferença não foi tanta para ext3 e ReiserFS, XFS veio logo atrás, e no último lugar, mais uma vez ficou JFS.

Terceiro teste

Fiz uso de um script para criar 30 mil arquivos de texto simples, sem conteúdo, e todos concluíram o trabalho em poucos segundos, veja o resultado no gráfico abaixo:

Nesta terceira rodada, o mais rápido foi ReiserFS, seguido de pertinho por ext4 e ext3, e mais uma vez, JFS foi o mais lento.

Quarto teste

Fiz uma listagem de todos os 30 mil arquivos criados no teste anterior, e mais uma vez todos concluíram em poucos segundos. Veja o resultado no gráfico abaixo:

Nesta rodada, o ext3 foi muito mais rápido que os outros, concluindo o trabalho em menos de um segundo, logo depois veio ext4, ReiserFS, JFS e XFS, com pouco tempo de diferença entre eles.

Quinto teste

Fiz a remoção de todos os 30 mil arquivos criados anteriormente, e mais uma vez todos concluíram o teste em menos de um minuto, veja o resultado no gráfico abaixo:

Neste teste o mais rápido foi ext4, seguido de ext3 e ReiserFS, o mais lento foi XFS, aliás, muito lento em comparação com os outros.

Sexto teste

Removi o diretório do kernel 3.4 e todos seus arquivos e subdiretórios criados após a descompactação, e o teste foi concluído em segundos. Veja o resultado no gráfico abaixo:

Neste teste o ext3 e ext4 foram absurdamente mais rápidos, respectivamente, com um pouquinho de tempo a mais, o ReiserFS demostrou muita velocidade. O JFS foi muito lento.

Sétimo teste

Fiz uso de um script para criar 30 mil diretórios vazios e a tarefa levou menos de um minuto para ser concluída, mais uma vez (foi concluída em segundos). Veja o resultado no gráfico abaixo:

Neste teste houve um certo equilíbrio na velocidade de término de tarefa de cada um, dupla exts foram um pouco mais velozes que ReiserFS e JFS, e XFS foi o mais lento mais um vez.

Oitavo teste

Removi os diretórios criados e o término da tarefa foi em segundos também:

Neste último teste os sistemas de arquivos ext4, ext3 e ReiserFS foram absurdamente mais rápidos, acabando a tarefa em menos de um segundo cada.

Você pode ver também um benchmark feito pela Phoronix acessando o link abaixo:

Nota-se neste benchmark básico realizado por mim, que os sistemas mais velozes foram ext4 e ext3, seguido do ReiserFS e depois XFS e por último, o JFS.

Tenho que levar em conta que não foi feito nenhum tipo de personalização no sistema de arquivos aplicado, tal como: aumento de tamanho do arquivo do journaling, ou journaling externo, por exemplo. Ou seja, nenhum sistema de arquivos foi turbinado.
Considerações finais

Todos os testes realizados e mostrados na página anterior foram baseados na velocidade de término de cada tarefa, contudo, não faça a escolha do sistema de arquivos somente pelo desempenho, leve em consideração as características positivas e negativas de cada um.

Quando o assunto é sistema de arquivos no GNU/Linux, é inevitável as comparações entre o ReiserFS, XFS, ext4 e o ext3, além do JFS, que é menos usado. Nada mais natural, afinal, cada administrador de sistemas e ou redes e até mesmo usuários busca qual é o melhor para suas necessidades.

Apontar qual realmente é melhor não é uma tarefa fácil. Há vários comparativos na Internet que tentam oferecer esta resposta, mas na minha opinião, a melhor coisa a fazer é testar os sistemas de arquivos que lhe atraíram para definir qual mais lhe agrada.

Definitivamente, o uso de sistemas de arquivos sem suporte a journaling, ou algum recurso similar, para tolerância de falhas e erros não é recomendável de usar, pois pode deixá-lo na mão.

NOTA: Não incluí o Btrfs, pois o mesmo é considerado instável e não é aconselhável o seu uso em produção, e ainda está em desenvolvimento constante para ser aprimorado.

Se deseja mais informações sobre o mesmo, leia o artigo:

Recomendação de uso

Se quer desempenho, recomendo ext4, pois o mesmo mostra-se muito rápido, e o suporte dele no kernel (usado como default nas instalações até então de muitas distros) é muito bom. E ext3, que apesar de ser considerado obsoleto por muitos, é bem estável e ainda é rápido também, porém, o mesmo não tem tanta eficácia com o journaling (como explicado durante o artigo).

Para isso recomendo ReiserFS e XFS, pois estou usando-os a um bom tempo, e os mesmos até o momento não apresentaram nenhum problema, mesmo já passando por desligamentos inesperados e ambos terem um desempenho muito bom, cada um com suas vantagens. XFS trabalha melhor com arquivos grandes e ReiserFS com arquivos pequenos.

São apenas recomendações, porém, recomendo que teste e veja qual é o que mais o agrada no quesito que deseja e necessita.

Concluindo, menciono mais uma vez que o journal é para tolerar falhas e erros, e não protege 100% contra perda de dados.

Metasploit – Instalação e utilização em ambiente GNU/Linux

 Clusterweb, Firewall, Linux, Redes  Comentários desativados em Metasploit – Instalação e utilização em ambiente GNU/Linux
mar 082013
 
Instalando

1. Visite a seguinte página e baixe a versão de instalação para GNU/Linux 32 ou 64 bits:

Salve o arquivo de instalação em uma pasta qualquer. Nesse tutorial será a pasta “Documentos”.

2. Abra o terminal como administrador.

3. Utilize o comando chmod +x para dar poder de execução ao arquivo baixado. Exemplo:

# chmod +x /home/pedro/Documentos/metasploit-latest-linux-installer.run

4. Execute o arquivo com:

# ./metasploit-lateset-linux-installer.run

5. Clique em “Avançar” para começar a instalação.

6. Marque: “I accept the agreement” → Clique em: “Avançar”.

7. Caso queira mudar a pasta de instalação ou clique em: “Avançar”.

8. Nesta etapa pode-se escolher registrar ou não no serviço. Neste caso escolheremos: “Yes”.

9. Deixe a porta default. Clique em: “Avançar”.

10. Escolha um nome para o servidor e clique em: “Avançar”.

11. Clique em “Avançar” para instalar.

12. Marque: “Access Metasploit Web UI” → Clique: “Finish”.

13. Aguarde cerca de 5 minutos e aparecerá essa tela para criação de login.

14. Após criado o login, clique em “GET PRODUCT KEY”, para obter a chave do Metasploit.

15. Selecione: “GET COMUNITY EDITION”.

16. Preencha o formulário e clique em: “Submit”.

17. A chave será mandada para o e-mail cadastrado, copie e cole ela, depois clique em: “ACTIVATE LICENSE”.

18. Pronto, o Metasploit está instalado e ativado.

19. Esta interface WEB é uma das interfaces que o Metasploit fornece para o usuário. Porém, utilizaremos o console do Metasploit chamado Msfconsole.

Para executar, digite no terminal: msfconsole

É aconselhável utilizar o Msfconsole em modo root.
Definições / Metasploitable / Msfconsole

Definições básicas

Antes de utilizarmos o Metasploit é importante conhecermos alguns conceitos:

  • Vulnerabilidade: falha de segurança em um software, hardware ou sistema operacional que fornece uma fonte potencial de ataque para um sistema;
  • Exploit: módulo especializado em tirar vantagem de uma vulnerabilidade específica de um sistema e prover acesso ao mesmo;
  • Payload: módulo que possibilita executar ações em um sistema após o mesmo ter sido acessado por um exploit. Podemos imaginar um exploit como um intruso que carrega um payload em sua mochila. Após invadir o sistema, o exploit libera o payload para este realizar sua tarefa.

Metasploitable

A equipe do Metasploit fornece uma máquina virtual Ubuntu para testes, chamada Metasploitable e que, intencionalmente, possui diversas vulnerabilidades.

Faça o download da Metasploitable e execute-a em algum software de virtualização, tal como VirtualBox ou VMware.

Msfconsole

É possível utilizar o Metasploit através de várias interfaces, como a interface WEB utilizada na instalação ou através de linhas de comando.

Neste tutorial, estaremos utilizando o Msfconsole, que fornece um interface com o framework do Metasploit baseada em console. O Msfconsole oferece recursos que tornam mais fácil o seu uso, tais como a auto-complementação de comandos (utilizando TAB) e a possibilidade de se usar comandos externos (nmap, por exemplo).

Para utilizar o Msfconsole, basta digitar o comando no terminal:

# msfconsole

Linux: Metasploit - Instalação e utilização em ambiente GNU/Linux

No Metasploit temos a ideia de módulos. Um módulo no Msfconsole é acessado por seu caminho completo em uma árvore de diretórios. Os módulos estão agrupados de acordo com suas características, como por exemplo, o seu tipo (exploit, payload, auxiliary, encoder, nop), sistema operacional, software vulnerável, etc.

Por exemplo, um caminho para um exploit na maioria dos casos segue este padrão:

exploit/sistema_operacional/tipo_do_serviço/ nome_do_módulo

Esse tipo de organização adicionada do sistema de auto-complementação facilita muito a pesquisa por um módulo.

Comandos

A seguir estão alguns comandos básicos do Msfconsole:

use < módulo >

Este comando é utilizado sempre que queremos executar um módulo.

back

Usado para “sair” de um módulo.

search < valor >

Comando utilizado para pesquisar um módulo. É possível utilizar filtros de pesquisa, especificando o filtro como parâmetro e o valor procurado.

Por exemplo, digitando:

search plataform:windows

Serão mostrados apenas módulos aplicáveis à plataforma Windows.

show < valor >

Mostra uma lista de módulos de acordo com o valor passado. Utilizado frequentemente dentro de um módulo (após o comando use), pois exibe somente os módulos “compatíveis” com o módulo utilizado no momento (principalmente no caso de estar se usando um exploit e procurando por um payload).

Dentro de um módulo é possível também listar outras coisas além de módulos, como a configuração do módulo em questão ou os sistemas alvo disponíveis.

set < parâmetro > < Valor >

Utilizado para configurar os parâmetros de execução de um módulo.

*info < módulo >

Utilizado para exibir os detalhes de um módulo. Estando dentro de um módulo (após o comando use) não há a necessidade do parâmetro “< módulo >” para exibir as suas informações.

Existem diversos outros comandos disponíveis que podem ser visualizados com o comando help. Para saber mais sobre o uso de um comando específico, basta digitar:

< comando > -h
Explorando sistemas vulneráveis

Para explorar as vulnerabilidades de um sistema, precisamos descobrir as portas que nele estão abertas e as aplicações que as utilizam. Podemos fazer isso de duas formas: utilizando o comando nmap ou módulos do próprio Metasploit.

Utilizando o nmap, digite no console:

nmap -sV -O < ip_alvo >

Os parâmetros “-sV -O” são utilizados para recuperar a versão do serviço que está utilizando uma porta e o sistema operacional alvo, respectivamente.

Utilizando módulos do Metasploit, devemos pesquisar por algum que realiza a verificação de portas abertas. Digite no console:

search scanner/portscan

Após escolher o tipo de scanner, basta utilizar o comando use passando o caminho do módulo como parâmetro. Exemplo:

use auxiliary/scanner/portscan/tcp

Os parâmetros que um módulo utiliza são configuráveis, e alguns obrigatórios para a sua execução. Para verificar os parâmetros do módulo digite:

show options

Para configurar uma parâmetro, devemos digitar:

set < nome_do_paramentro > < valor >

Na coluna “Required”, observamos os parâmetros que o módulo necessita que estejam configurados para executar. Neste caso, por exemplo, devemos atribuir o endereço IP do sistema alvo ao parâmetro RHOSTS. Por exemplo:

set rhosts 192.168.0.1

Uma vez configurado o módulo, digite o seguinte para executá-lo:

run

Como visto, ambas as abordagens exibem uma lista com as portas abertas no sistema alvo. A vantagem de se utilizar o nmap é que podemos obter informações mais detalhadas sobre as portas e sobre o sistema alvo, assim como configurar o modo sobre como a varredura será feita.

A lista das portas encontradas é o que devemos utilizar como guia para os próximos passos. Uma vez descoberto um serviço, a porta que ele utiliza e o sistema operacional do alvo, é hora de utilizar os comandos do Msfconsole para pesquisar exploits e payloads, que estão relacionados com aquele serviço e sistema operacional.

O primeiro passo: pesquisar um exploit. Como sabemos o serviço que utiliza determinada porta, podemos utilizar essa informação para refinar a nossa busca.

Por exemplo, podemos utilizar o comando search com a seguinte configuração:

search type:exploit name:mysql

Neste caso, serão retornados somente exploits que estão relacionados com o MySQL.

* Lembrando que o comando: info < módulo > pode ser utilizado para ver os detalhes de um módulo.

Uma vez escolhido o exploit, é hora de configurá-lo. Com o comando show options, será exibida uma lista contendo informações sobre os parâmetros utilizados pelo exploit.

Aqueles parâmetros que na coluna Required possuírem o valor “yes”, devem obrigatoriamente possuir um valor na coluna “Current Setting” para que o módulo seja executado.

Para configurar um parâmetro, utilize o comando:

set < parametro > < valor >

Como dito anteriormente, o exploit faz o trabalho de invasão do sistema através de uma aplicação com vulnerabilidades. E após a invasão ele executa o payload para realizar alguma ação naquele sistema.

Para configurar um payload para o exploit, digite o comando:

show payloads

Como estamos dentro de um exploit, será retornada uma lista contendo apenas os payloads compatíveis com o exploit em questão.

Para utilizar um payload, digite o comando:

set payload < payload >

É preciso verificar novamente com o comando show options se os parâmetros do payload estão corretamente configurados.

Caso nenhum payload seja configurado, após a invasão do exploit, o console funcionará como um terminal no sistema invadido.

Após terminada a configuração, basta digitar o comando exploit para executar o exploit:
Explorando uma vulnerabilidade no Android

Iremos agora explorar uma vulnerabilidade no sistema Android. Nesse teste estamos utilizando um aparelho com a versão 2.3 do sistema.

O primeiro passo é pesquisar um exploit para o Android:

search android

Se executarmos o comando:

info auxiliary/gather/android_htmlfileprovider

Veremos que, com esse exploit, é possível extrair arquivos do dispositivo a partir de uma conexão do browser do aparelho com a nossa máquina. O browser deve acessar um link no seguinte formato:

http://ip_da_maquina_local  (No meu caso: http://192.168.0.102/)

Ao acessar o link o browser fará o download de um arquivo enviado pelo exploit e, quando o arquivo for aberto, será exibido no console o conteúdo dos arquivos que extraímos do dispositivo.

Vamos então usá-lo:

use auxiliary/gather/android_htmlfileprovider

Se digitarmos:

show options

Veremos as configurações do exploit. Os seguintes parâmetros devem ser configurados (set < parametros > < valor >):

  • SRVHOST :: IP da máquina local
  • SRVPORT :: 80
  • FILES :: Já estão pré-configurados alguns arquivos que serão extraídos, mas nada impede que configuremos outros arquivos.

Agora basta executar o exploit com o comando:

exploit

Ao acessar o link no dispositivo Android, faremos o download de um arquivo HTML enviado pelo exploit. No Msfconsole veremos então o conteúdo dos arquivos que foram extraídos do dispositivo:

Conclusão

Com o Metasploit, podemos explorar vulnerabilidades em vários tipos de sistemas. Independente do tipo a sequência de passos, na maioria das vezes, obedece um padrão.

Quando não se tem ideia da configuração ou da existência de uma máquina alvo em uma rede, deve-se fazer a varredura de uma faixa de IPs utilizando comandos do GNU/Linux ou módulos do próprio Metasploit.

Quando se conhece o IP do sistema alvo e suas respectivas portas e serviços associados a estas, basta utilizar o comando search do Metasploit para encontrar módulos específicos para aquele sistema e serviço.

Módulos novos surgem constantemente no Metaspoit, logo, é aconselhável atualizar a ferramenta periodicamente (digite msfupdate em um terminal).

É possível também, desenvolver nossos próprios módulos. Procuraremos abordar esta parte de desenvolvimento de módulos em artigos futuros.

Para maiores informações a respeito do Metasploit, acessem o site:

E a comunidade oficial:

Bonding para Heartbeat + Bonding para DRBD + OCFS2 + Debian Squeeze

 Clusterweb, Leitura Recomendada, Linux  Comentários desativados em Bonding para Heartbeat + Bonding para DRBD + OCFS2 + Debian Squeeze
mar 082013
 
Introdução

E aí, galera.

Aqui vou abordar a configuração de Bonding para termos a redundância de interfaces físicas para o serviço de HA, pois o Heartbeat vai trabalhar no bond0 e o DRBD + OCFS2, vai trabalhar no bond1.

Estou utilizando o algoritmo round-robin, que faz o balanceamento dos dados, porém, temos outros algoritmos que podemos utilizar para o mesmo fim.

Quero ganhar disponibilidade do servidor e aumentar a performance de acesso à rede, onde temos, às vezes, gargalos como no serviço do DRBD, que é um RAID 1 via rede.

Como vai funcionar: aqui vamos agrupar 2 interfaces para montar um bond para o Heartbeat e agrupar as outras 2 interfaces para montar o bond para o DRBD.

Caso caia alguma das interfaces por causa de algum problema de hardware, o servidor vai continuar funcionando, pois temos uma interface de “Backup” trabalhando, caso as duas estejam funcionando, vamos fazer o balanceamento de carga entre elas e, com isso, melhorando a performance.

Prepare o seu sistema com o seguinte script, para que não falte nenhum pacote ou configuração:

Pré-requisitos

  • Nome Nodo1: srv01
  • IP DMZ: 10.101.0.25/24 -> VLAN DMZ
  • IP DMZ HA: 10.101.0.27/24 -> VLAN DMZ
  • IP Dados: 172.20.0.25/24 -> VLAN Dados
  • Interfaces de rede: eth0, eth1, eth2, eth3
  • Partição utilizada Nodo1: /dev/sdb1 dispositivo com 8 GB
  • Nome Nodo2: srv02
  • IP DMZ: 10.101.0.26/24 -> VLAN DMZ
  • IP DMZ HA: 10.101.0.27/24 -> VLAN DMZ
  • IP Dados: 172.20.0.26/24 -> VLAN Dados
  • Interfaces de rede: eth0, eth1, eth2, eth3
  • Partição utilizada Nodo2: /dev/sdb1 dispositivo com 8 GB
Instalação e configuração do Bond

Agora, vamos mandar atualizar os repositórios e instalar os pacotes para o bond no servidor srv01:

# aptitude update && aptitude install ifenslave ethtool -y

Agora vamos acertar a configuração dos módulos do kernel:

# echo “options bonding mode=0 miimon=100” >> /etc/modprobe.d/bonding.conf

Vamos verificar se todas as interfaces estão com link:

# mii-tool

Saída:

eth0: no autonegotiation, 1000baseT-FD flow-control, link ok
eth1: no autonegotiation, 1000baseT-FD flow-control, link ok
eth2: no autonegotiation, 1000baseT-FD flow-control, link ok
eth3: no autonegotiation, 1000baseT-FD flow-control, link ok

Agora, vamos acertar a configuração de rede para o bonding:

# vim /etc/network/interfaces

Edite:

#Interface de loopback
auto lo
iface lo inet loopback
#Interface de bonding para DMZ
auto bond0
        iface bond0 inet static
        address 10.101.0.25
        netmask 255.255.255.0
        network 10.101.0.0
        gateway 10.101.0.254
        bond-slaves eth0 eth1
#Interface de bonding para Dados
auto bond1
        iface bond1 inet static
        address 172.20.0.25
        netmask 255.255.255.0
        network 172.20.0.0
        bond-slaves eth2 eth3

Agora, precisamos reiniciar o servidor:

# reboot

E vamos listar as nossas interfaces, para verificar se subiu o bond e os endereços IPs:

# ifconfig

A saída seria:

bond0  Link encap:Ethernet Endereço de HW 08:00:27:3f:b0:b8
inet end.: 10.101.0.25 Bcast:10.101.0.255 Masc:255.255.255.0
endereço inet6: fe80::a00:27ff:fe3f:b0b8/64 Escopo:Link
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1
RX packets:12604 errors:0 dropped:0 overruns:0 frame:0
TX packets:265 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:1088563 (1.0 MiB) TX bytes:42992 (41.9 KiB)

bond1  Link encap:Ethernet Endereço de HW 08:00:27:ff:cd:7c
inet end.: 172.20.0.25 Bcast:172.20.0.2655 Masc:255.255.255.0
endereço inet6: fe80::a00:27ff:feff:cd7c/64 Escopo:Link
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1
RX packets:12260 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:1050542 (1.0 MiB) TX bytes:440 (440.0 B)

eth0    Link encap:Ethernet Endereço de HW 08:00:27:3f:b0:b8
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:6478 errors:0 dropped:0 overruns:0 frame:0
TX packets:132 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:563560 (550.3 KiB) TX bytes:22857 (22.3 KiB)

eth1    Link encap:Ethernet Endereço de HW 08:00:27:3f:b0:b8
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:6126 errors:0 dropped:0 overruns:0 frame:0
TX packets:133 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:525003 (512.6 KiB) TX bytes:20135 (19.6 KiB)

eth2    Link encap:Ethernet Endereço de HW 08:00:27:ff:cd:7c
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:6134 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:525539 (513.2 KiB) TX bytes:278 (278.0 B)

eth3    Link encap:Ethernet Endereço de HW 08:00:27:ff:cd:7c
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:6126 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:525003 (512.6 KiB) TX bytes:162 (162.0 B)

lo        Link encap:Loopback Local
inet end.: 127.0.0.1 Masc:255.0.0.0
endereço inet6: ::1/128 Escopo:Máquina
UP LOOPBACKRUNNING MTU:16436 Métrica:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:168 (168.0 B) TX bytes:168 (168.0 B)

O bonding para o srv01 já está OK, agora vamos configurar o srv02.

Vamos mandar atualizar os repositórios e instalar os pacotes para o bond no servidor srv02:

# aptitude update && aptitude install ifenslave ethtool -y

Acertar a configuração dos módulos do kernel:

# echo “options bonding mode=0 miimon=100” >> /etc/modprobe.d/bonding.conf

Verificar se todas as interfaces estão com link:

# mii-tool

Saída:

eth0: no autonegotiation, 1000baseT-FD flow-control, link ok
eth1: no autonegotiation, 1000baseT-FD flow-control, link ok
eth2: no autonegotiation, 1000baseT-FD flow-control, link ok
eth3: no autonegotiation, 1000baseT-FD flow-control, link ok

E acertar a configuração de rede para o bonding:

# vim /etc/network/interfaces

#Interface de loopback
auto lo
iface lo inet loopback
#Interface de bonding para DMZ
auto bond0
        iface bond0 inet static
        address 10.101.0.26
        netmask 255.255.255.0
        network 10.101.0.0
        gateway 10.101.0.254
        bond-slaves eth0 eth1
#Interface de bonding para Dados
auto bond1
        iface bond1 inet static
        address 172.20.0.26
        netmask 255.255.255.0
        network 172.20.0.0
        bond-slaves eth2 eth3

Agora, precisamos reiniciar o servidor:

# reboot

Agora, vamos listar as nossas interfaces para verificar se subiu o bond e os endereços IPs

# ifconfig

bond0  Link encap:Ethernet Endereço de HW 08:00:27:e4:58:4b
inet end.: 10.101.0.26 Bcast:10.101.0.255 Masc:255.255.255.0
endereço inet6: fe80::a00:27ff:fee4:584b/64 Escopo:Link
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1
RX packets:1204 errors:0 dropped:0 overruns:0 frame:0
TX packets:75 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:105536 (103.0 KiB) TX bytes:9338 (9.1 KiB)

bond1   Link encap:Ethernet Endereço de HW 08:00:27:d2:4e:60
inet end.: 172.20.0.26 Bcast:172.20.0.2655 Masc:255.255.255.0
endereço inet6: fe80::a00:27ff:fed2:4e60/64 Escopo:Link
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1
RX packets:1109 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:92286 (90.1 KiB) TX bytes:258 (258.0 B)

eth0     Link encap:Ethernet Endereço de HW 08:00:27:e4:58:4b
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:649 errors:0 dropped:0 overruns:0 frame:0
TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:59308 (57.9 KiB) TX bytes:3903 (3.8 KiB)

eth1     Link encap:Ethernet Endereço de HW 08:00:27:e4:58:4b
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:555 errors:0 dropped:0 overruns:0 frame:0
TX packets:37 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:46228 (45.1 KiB) TX bytes:5435 (5.3 KiB)

eth2     Link encap:Ethernet Endereço de HW 08:00:27:d2:4e:60
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:555 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:46182 (45.0 KiB) TX bytes:180 (180.0 B)

eth3     Link encap:Ethernet Endereço de HW 08:00:27:d2:4e:60
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:554 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:46104 (45.0 KiB) TX bytes:78 (78.0 B)

lo         Link encap:Loopback Local
inet end.: 127.0.0.1 Masc:255.0.0.0
endereço inet6: ::1/128 Escopo:Máquina
UP LOOPBACKRUNNING MTU:16436 Métrica:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Vamos testar agora, a conectividade entre os dois, iremos mandar pingar do srv01 para o srv02:

# ping -c 3 10.101.0.26

Vejamos o resultado:

PING 10.101.0.26 (10.101.0.26) 56(84) bytes of data.
64 bytes from 10.101.0.26: icmp_req=1 ttl=64 time=1.85 ms
64 bytes from 10.101.0.26: icmp_req=2 ttl=64 time=0.528 ms
64 bytes from 10.101.0.26: icmp_req=3 ttl=64 time=0.867 ms

— 10.101.0.26 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.528/1.083/1.855/0.563 ms

Agora, vamos mandar pingar do srv02 para o srv1:

# ping -c 3 172.20.0.25

Resultado:

PING 172.20.0.25 (172.20.0.25) 56(84) bytes of data.
64 bytes from 172.20.0.25: icmp_req=1 ttl=64 time=4.31 ms
64 bytes from 172.20.0.25: icmp_req=2 ttl=64 time=0.590 ms
64 bytes from 172.20.0.25: icmp_req=3 ttl=64 time=0.425 ms

— 172.20.0.25 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.425/1.777/4.318/1.798 ms

Agora que o bond está pronto, vamos configurar o Heartbeat para garantirmos um IP virtual compartilhado entre os servidores, que é o que o cliente vai utilizar para acessar os serviços.

Este IP, sempre vai setar o servidor que for definido como master, e caso ele caia por algum motivo, o servidor slave vai assumir este IP, e o cliente nem vai notar que está trabalhando em outro servidor.

Vamos acertar o arquivo de hosts, deixe o arquivo como o abaixo nos dois servidores.

# vim /etc/hosts

127.0.0.1     localhost
10.101.0.25   srv01.douglas.wiki.br   srv01
10.101.0.26   srv02.douglas.wiki.br   srv02
# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Instalação e configuração do Heartbeat

Agora, vamos instalar o Heartbeat no srv02:

# aptitude update && aptitude dist-upgrade -y && apt-get install heartbeat heartbeat-dev -y

Vamos acertar a configuração do Heartbeat:

# vim /etc/ha.d/ha.cf

#informe os nomes dos computadores que formam a replicação(deve ser igual a saída do comando "uname -n
node srv01
node srv02
#qual a interface vai ser usada para comunicação
mcast bond0 225.0.0.1 694 1 0
#Fazer com que a máquina principal receba seus serviços quando retornar a ativa
auto_failback on
#arquivos de log
debugfile /var/log/ha-debug
logfile /var/log/ha-log
#frequência, em segundos, da verificação das máquinas
keepalive 1
#tempo mínimo para declarar a outra máquina como morta
deadtime 5

Agora, vamos acertar a configuração do nosso IP compartilhado pelo Heartbeat:

# vim /etc/ha.d/haresources

srv01 IPaddr::10.101.0.27/24/bond0/10.101.0.255

Explicando o arquivo acima:

  • srv01: nome do servidor master
  • IPaddr::10.101.0.27/24: IP que vai ser compartilhado pelo Heartbeat
  • bond0: Interface que vai receber o IP compartilhado pelo Heartbeat
  • 10.101.0.25: Endereço de broadcast

Agora vamos acertar o arquivo com a senha de autenticação entre os Heartbeats:

# vim /etc/ha.d/authkeys

auth 3
3 md5 h34rt64t

Agora vamos acertar as permissões do arquivo de senha:

# chmod 600 /etc/ha.d/authkeys

Agora vamos instalar o Heartbeat no srv02:

# aptitude update && aptitude dist-upgrade -y && apt-get install heartbeat heartbeat-dev -y

Acertar a configuração do heartbeat:

# vim /etc/ha.d/ha.cf

#informe os nomes dos computadores que formam a replicação(deve ser igual a saída do comando "uname -n
node srv01
node srv02
#qual a interface vai ser usada para comunicação
mcast bond0 225.0.0.1 694 1 0
#Fazer com que a máquina principal receba seus serviços quando retornar a ativa
auto_failback on
#arquivos de log
debugfile /var/log/ha-debug
logfile /var/log/ha-log
#frequência, em segundos, da verificação das máquinas
keepalive 1
#tempo mínimo para declarar a outra máquina como morta
deadtime 5

Agora vamos acertar a configuração do nosso IP compartilhado pelo Heartbeat:

# vim /etc/ha.d/haresources

srv01 IPaddr::10.101.0.27/24/bond0/10.101.0.255

Agora vamos acertar o arquivo com a senha de autenticação entre os Heartbeats:

# vim /etc/ha.d/authkeys

auth 3
3 md5 h34rt64t

Agora vamos acertar as permissões do arquivo de senha:

# chmod 600 /etc/ha.d/authkeys

Agora vamos reiniciar o Heartbeat nos dois servidores:

# /etc/init.d/heartbeat restart

Agora no servidor master (o srv01), vamos consultar os endereços IPs:

# ifconfig

bond0  Link encap:Ethernet Endereço de HW 08:00:27:3f:b0:b8
inet end.: 10.101.0.25 Bcast:10.101.0.255 Masc:255.255.255.0
endereço inet6: fe80::a00:27ff:fe3f:b0b8/64 Escopo:Link
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1
RX packets:258509 errors:0 dropped:0 overruns:0 frame:0
TX packets:3510 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0

RX bytes:30982551 (29.5 MiB) TX bytes:419737 (409.8 KiB)

bond0:0  Link encap:Ethernet Endereço de HW 08:00:27:3f:b0:b8
inet end.: 10.101.0.27 Bcast:10.101.0.255 Masc:255.255.255.0
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1

bond1   Link encap:Ethernet Endereço de HW 08:00:27:ff:cd:7c
inet end.: 172.20.0.25 Bcast:172.20.0.2655 Masc:255.255.255.0
endereço inet6: fe80::a00:27ff:feff:cd7c/64 Escopo:Link
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1
RX packets:249676 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:19802934 (18.8 MiB) TX bytes:860 (860.0 B)

eth0    Link encap:Ethernet Endereço de HW 08:00:27:3f:b0:b8
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:133706 errors:0 dropped:0 overruns:0 frame:0
TX packets:1755 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:21086174 (20.1 MiB) TX bytes:213206 (208.2 KiB)

eth1    Link encap:Ethernet Endereço de HW 08:00:27:3f:b0:b8
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:124803 errors:0 dropped:0 overruns:0 frame:0
TX packets:1755 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:9896377 (9.4 MiB) TX bytes:206531 (201.6 KiB)

eth2    Link encap:Ethernet Endereço de HW 08:00:27:ff:cd:7c
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:124844 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:9901912 (9.4 MiB) TX bytes:516 (516.0 B)

eth3    Link encap:Ethernet Endereço de HW 08:00:27:ff:cd:7c
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:124832 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:9901022 (9.4 MiB) TX bytes:344 (344.0 B)

lo        Link encap:Loopback Local
inet end.: 127.0.0.1 Masc:255.0.0.0
endereço inet6: ::1/128 Escopo:Máquina
UP LOOPBACKRUNNING MTU:16436 Métrica:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:168 (168.0 B) TX bytes:168 (168.0 B)

Agora no servidor slave (o srv02) vamos consultar os endereços IPs:

# ifconfig

bond0  Link encap:Ethernet Endereço de HW 08:00:27:e4:58:4b
inet end.: 10.101.0.26 Bcast:10.101.0.255 Masc:255.255.255.0
endereço inet6: fe80::a00:27ff:fee4:584b/64 Escopo:Link
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1
RX packets:248388 errors:0 dropped:0 overruns:0 frame:0
TX packets:3842 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:30223554 (28.8 MiB) TX bytes:472655 (461.5 KiB)

bond1  Link encap:Ethernet Endereço de HW 08:00:27:d2:4e:60
inet end.: 172.20.0.26 Bcast:172.20.0.2655 Masc:255.255.255.0
endereço inet6: fe80::a00:27ff:fed2:4e60/64 Escopo:Link
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1
RX packets:239819 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:19101060 (18.2 MiB) TX bytes:720 (720.0 B)

eth0    Link encap:Ethernet Endereço de HW 08:00:27:e4:58:4b
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:128628 errors:0 dropped:0 overruns:0 frame:0
TX packets:1924 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:20708154 (19.7 MiB) TX bytes:241140 (235.4 KiB)

eth1    Link encap:Ethernet Endereço de HW 08:00:27:e4:58:4b
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:119760 errors:0 dropped:0 overruns:0 frame:0
TX packets:1918 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000

RX bytes:9515400 (9.0 MiB) TX bytes:231515 (226.0 KiB)

eth2    Link encap:Ethernet Endereço de HW 08:00:27:d2:4e:60
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:119916 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:9551043 (9.1 MiB) TX bytes:418 (418.0 B)

eth3    Link encap:Ethernet Endereço de HW 08:00:27:d2:4e:60
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:119903 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:9550017 (9.1 MiB) TX bytes:302 (302.0 B)

lo        Link encap:Loopback Local
inet end.: 127.0.0.1 Masc:255.0.0.0
endereço inet6: ::1/128 Escopo:Máquina
UP LOOPBACKRUNNING MTU:16436 Métrica:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Como pode ser notado, temos o IP 10.101.0.27/24 no servidor srv01, que é o master. Agora vamos fazer um teste: vamos deslitar o servidor srv01:

# telinit 0

Agora no servidor srv02 vamos consultar os endereços IPs:

# ifconfig

bond0  Link encap:Ethernet Endereço de HW 08:00:27:e4:58:4b
inet end.: 10.101.0.26 Bcast:10.101.0.255 Masc:255.255.255.0
endereço inet6: fe80::a00:27ff:fee4:584b/64 Escopo:Link
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1
RX packets:251625 errors:0 dropped:0 overruns:0 frame:0
TX packets:3959 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:30524354 (29.1 MiB) TX bytes:499147 (487.4 KiB)

bond0:0  Link encap:Ethernet Endereço de HW 08:00:27:e4:58:4b
inet end.: 10.101.0.27 Bcast:10.101.0.255 Masc:255.255.255.0
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1

bond1  Link encap:Ethernet Endereço de HW 08:00:27:d2:4e:60
inet end.: 172.20.0.26 Bcast:172.20.0.2655 Masc:255.255.255.0
endereço inet6: fe80::a00:27ff:fed2:4e60/64 Escopo:Link
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1
RX packets:243159 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:19424314 (18.5 MiB) TX bytes:720 (720.0 B)

eth0    Link encap:Ethernet Endereço de HW 08:00:27:e4:58:4b
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:130251 errors:0 dropped:0 overruns:0 frame:0
TX packets:1982 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:20859033 (19.8 MiB) TX bytes:252852 (246.9 KiB)

eth1    Link encap:Ethernet Endereço de HW 08:00:27:e4:58:4b
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:121374 errors:0 dropped:0 overruns:0 frame:0
TX packets:1977 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:9665321 (9.2 MiB) TX bytes:246295 (240.5 KiB)

eth2    Link encap:Ethernet Endereço de HW 08:00:27:d2:4e:60
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:121586 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:9712670 (9.2 MiB) TX bytes:418 (418.0 B)

eth3    Link encap:Ethernet Endereço de HW 08:00:27:d2:4e:60
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:121573 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:9711644 (9.2 MiB) TX bytes:302 (302.0 B)

lo        Link encap:Loopback Local
inet end.: 127.0.0.1 Masc:255.0.0.0
endereço inet6: ::1/128 Escopo:Máquina
UP LOOPBACKRUNNING MTU:16436 Métrica:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Note que o endereço IP 10.101.0.27/24, já foi atribuido ao servidor srv02, pois ele é o slave; então, caso o cliente esteja conectado em algum serviço, ele não vai notar quando trocar de servidor.

Agora vamos ligar novamente o servidor srv01 e consultar novamente:

# ifconfig

bond0  Link encap:Ethernet Endereço de HW 08:00:27:3f:b0:b8
inet end.: 10.101.0.25 Bcast:10.101.0.255 Masc:255.255.255.0
endereço inet6: fe80::a00:27ff:fe3f:b0b8/64 Escopo:Link
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1
RX packets:3314 errors:0 dropped:0 overruns:0 frame:0
TX packets:244 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:292621 (285.7 KiB) TX bytes:33465 (32.6 KiB)

bond0:0  Link encap:Ethernet Endereço de HW 08:00:27:3f:b0:b8
inet end.: 10.101.0.27 Bcast:10.101.0.255 Masc:255.255.255.0
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1

bond1  Link encap:Ethernet Endereço de HW 08:00:27:ff:cd:7c
inet end.: 172.20.0.25 Bcast:172.20.0.2655 Masc:255.255.255.0
endereço inet6: fe80::a00:27ff:feff:cd7c/64 Escopo:Link
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1
RX packets:3255 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:289268 (282.4 KiB) TX bytes:258 (258.0 B)

eth0    Link encap:Ethernet Endereço de HW 08:00:27:3f:b0:b8
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:1732 errors:0 dropped:0 overruns:0 frame:0
TX packets:122 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:157391 (153.7 KiB) TX bytes:15755 (15.3 KiB)

eth1    Link encap:Ethernet Endereço de HW 08:00:27:3f:b0:b8
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:1582 errors:0 dropped:0 overruns:0 frame:0
TX packets:122 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:135230 (132.0 KiB) TX bytes:17710 (17.2 KiB)

eth2    Link encap:Ethernet Endereço de HW 08:00:27:ff:cd:7c
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:1628 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:144673 (141.2 KiB) TX bytes:180 (180.0 B)

eth3    Link encap:Ethernet Endereço de HW 08:00:27:ff:cd:7c
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:1627 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:144595 (141.2 KiB) TX bytes:78 (78.0 B)

lo        Link encap:Loopback Local
inet end.: 127.0.0.1 Masc:255.0.0.0
endereço inet6: ::1/128 Escopo:Máquina
UP LOOPBACKRUNNING MTU:16436 Métrica:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Note que o IP compartilhado voltou para o servidor srv01, pois definimos ele como master.

A primeira parte já está OK, que era garantir um IP compartilhado que vai ser utilizado pelo cliente.

Pense que no servidor srv01, temos um site rodando, e este site está também no servidor srv02, com isso, o cliente vai acessar o: http://10.101.0.27

…E vai para o servidor master disponível, que em nosso caso, vai ser o srv01.

Caso o master caia, o cliente vai acessar as páginas que estão no servidor srv02, e nem vai sentir que ele está acessando outro servidor. 😉

Mas, note que ainda temos um problema: os dados têm que ser sincronizados manualmente entre os servidores, por isso que vamos utilizar agora o DRBD + OCFS2, que vai trabalhar como um RAID 1 via rede, espelhando os dados em tempo real.

Então, caso seja alterado um arquivo qualquer na partição do DRBD, o outro servidor já vai ter acesso a essas novas informações. Aqui vou utilizar o OCFS2, que é um sistema de arquivos distribuido, onde podemos trabalhar com os nodos sendo !master/master, ou seja, qualquer um dos servidores podem alterar qualquer arquivo, e esse arquivo vai aparecer alterado para a outra ponta.
Instalação e configuração do DRBD + OCFS2

Agora, vamos instalar o DRBD e o OCFS2, faça isso nas duas máquinas:

# aptitude install drbd8-utils ocfs2-tools ocfs2-tools-dev -y

Agora vamos carregar os módulos (faça isso nas duas máquinas):

# modprobe cn
# modprobe drbd

Vamos configurar o DRBD. Deixe o arquivo como abaixo nas duas máquinas:

# vim /etc/drbd.conf

include “drbd.d/global_common.conf”;
#include “drbd.d/*.res”;

Execute nas duas máquinas a parte abaixo.

Vamos fazer backup do arquivo de configuração original:

# cp /etc/drbd.d/global_common.conf{,.bkp}

Deixe o arquivo como abaixo:

# vim /etc/drbd.d/global_common.conf

#/etc/drbd.conf
# Opções Globais
# Geralmente no início do arquivo. Poucas opções são definidas nesta seção.
#
global {
 usage-count yes; # Gerar status da atualização do sistema de DRBD.
}
#
# Opções comuns a mais de um recurso, quando houver. No caso de existir opções
# definidas internamente ao recurso, elas irão sobrepor as opções comuns.
common {
 protocol C; # Método de replicação. Neste caso, replicação síncrona.
}
###  ocfs2 usando 02 primários
resource r1 {
 net {
 # Permitir/habilitar dois servidores primários.
 allow-two-primaries; #Permite habilitar dois servidores primários
 after-sb-0pri discard-younger-primary;
 after-sb-1pri consensus;
 after-sb-2pri disconnect;
}
 startup {
 # Iniciar os dois servidores como primários, por padrão.
 become-primary-on both;
 }
 syncer {
 rate 600M; #Para placas de rede de 10/100 utilizar 10M
 }
 
 on srv01 {
 device     /dev/drbd1; # Nome do dispositivo de DRBD
 disk       /dev/sdb1; # Dispositivo de baixo nível utilizado a partição
 address    172.20.0.25:7789;  # IP:porta de conexão
 meta-disk internal; # Armazenamento das informações de dados é feito
 # dentro do dispositivo de baixo nível.
 }
 on srv02 {
 device   /dev/drbd1;
 disk      /dev/sdb1;
 address   172.20.0.26:7789;
 meta-disk internal;
 }
}

Agora, vamos preparar o disco, faça isso nos dois servidores:

# fdisk /dev/sdb

Vai aparecer as peguntas:

##Saída de comando##
O dispositivo não contém nem uma tabela de partições DOS válida nem um rótulo de disco Sun, OSF ou SGI
Building a new DOS disklabel with disk identifier 0x6aadf3ff.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.
 
Aviso: a opção inválida 0x0000 da tabela de partições 4 será corrigida por gravação (w)
 
WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
 switch off the mode (command 'c') and change display units to
 sectors (command 'u').
 
Comando (m para ajuda):
####
Tecle "p".
##Saída de comando##
Disk /dev/sdb: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cilindros of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x6aadf3ff
 
Dispositivo Boot      Start         End      Blocks   Id  System
Comando (m para ajuda):
####
Aqui, tecle "n" para criar uma nova partição.
##Saída##
Comando - ação
 e   estendida
 p   partição primária (1-4)
####
Tecle "p" (primária).
##Saída##
Número da partição (1-4): 1
Primeiro cilindro (1-1044, default 1): ENTER
Using default value 1
Last cilindro, +cilindros or +size{K,M,G} (1-1044, default 1044): ENTER
Using default value 1044
Comando (m para ajuda):
####

Aqui, tecle w para escrever as mudanças no disco. E por fim, q para sair.

Agora vamos zerar as partições (tem que ser executado nos dois servidores):

# dd if=/dev/zero of=/dev/sdb1 bs=1M count=128

Execute este comando nos dois servidores, antes de passar para o próximo comando:

# drbdadm — –discard-my-data connect r1

Onde “r1”, é o nome do nosso dispositivo, que no arquivo de configuração do DRBD, está como resource r1.

Execute este comando nos dois servidores, antes de passar para o próximo comando:

# drbdadm create-md r1

Execute este comando nos dois servidores, antes de passar para o próximo comando:

# drbdadm attach r1

Execute este comando nos dois servidores, antes de passar para o próximo comando:

# drbdadm connect r1

Pronto, agora podemos iniciar o DRBD. Inicie-o nos dois servidores com o seguinte comando:

# /etc/init.d/drbd start

Podemos observar como está a situação do nosso dispositivo DRBD, com o seguinte comando:

# cat /proc/drbd

Exemplo:

version: 8.3.7 (api:88/proto:86-91)
srcversion: EE47D8BF18AC166BE219757

1: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r—-
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:8385604

Se em “Connected st” estiver como Primary/Primary, está tudo OK, porém, se estiver como “Secondary/Secondary”, temos que forçar os dispositivos a passarem para primary, e temos mais uma situação quanto ao dispositivo Unknown, normalmente é quando um dos servidores não está operante por problemas de rede, ou de configuração do arquivo do DRBD. Então, muita atenção a esses detalhes.

Vamos levar em consideração que só estamos com o problema que os dois servidores estão como secondary, resolvemos com o seguinte comando. Este comando tem que ser rodado nos dois servidores:

# drbdadm — –overwrite-data-of-peer primary r1

Agora vamos monitorar novamente:

# cat /proc/drbd

Resultado:

version: 8.3.7 (api:88/proto:86-91)
srcversion: EE47D8BF18AC166BE219757

1: cs:SyncTarget ro:Primary/Primary ds:Inconsistent/UpToDate C r—-
ns:0 nr:1368684 dw:1368672 dr:12 al:0 bm:83 lo:1 pe:10097 ua:0 ap:1 ep:1 wo:b oos:7016932
[==>……………..] sync’ed: 16.4% (6852/8188)M
finish: 0:01:04 speed: 109,344 (97,760) K/sec

Agora, é só esperar eles sincronizarem os dados, isso depende da placa de rede, da velocidade do disco e do tamanho do disco, fora os processos do DRBD, se você notar muita lentidão em algum desses fatores, veja se não é bom fazer algum upgrade.

Para acompanhar a sincronização, pode utilizar o seguinte comando:

# cat /proc/drbd

Agora depois de sincronizados:

version: 8.3.7 (api:88/proto:86-91)
srcversion: EE47D8BF18AC166BE219757

1: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r—-
ns:8385660 nr:0 dw:0 dr:8385860 al:0 bm:512 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

Agora, vamos configurar o OCFS2

Vamos configurar o cluster para o OCFS2. Tem que ser configurado nos dois servidores:

# vim /etc/ocfs2/cluster.conf

Edite:

node:
 ip_port = 7777
 ip_address = 172.20.0.25
 number = 0
 name = srv01
 cluster = ocfs2
 
node:
 ip_port = 7777
 ip_address = 172.20.0.26
 number = 1
 name = srv02
 cluster = ocfs2
 
cluster:
 node_count = 2
 name = ocfs2

Agora vamos configurar o O2CB, para ser habilitado (tem que ser configurado nos dois servidores):

# sed -i ‘s/O2CB_ENABLED=false/O2CB_ENABLED=true/g’ /etc/default/o2cb

Agora é so restartar o serviço nos dois servidores:

# /etc/init.d/o2cb restart

E criar o sistema de arquivos OCFS2 no DRBD, precimos fazer isso somente em um dos dois servidores.

Opções:

  • -C : indicado acima de 128K para grandes arquivos;
  • -b : indicado 4K;
  • -N : quantidade de nodos;
  • -L : label para a partição.

# mkfs.ocfs2 -b 4K -C 128K -N 2 -L ocfs2 /dev/drbd1

Montando a partição

Vamos criar um diretório para o OCFS2 nos dois servidores, e vamos montar:

# mkdir /ocfs2
# mount.ocfs2 /dev/drbd1 /ocfs2/

Vamos agora verificar nossas partições:

# df -Th

Resultado:

Sist. Arq.    Tipo    Size  Used Avail Use% Montado em
/dev/sda1     ext3    323M  147M  160M  48% /
tmpfs        tmpfs    249M     0  249M   0% /lib/init/rw
udev         tmpfs    244M  168K  244M   1% /dev
tmpfs        tmpfs    249M     0  249M   0% /dev/shm
/dev/sda9     ext3    2,8G   69M  2,6G   3% /home
/dev/sda8     ext3    234M  6,1M  216M   3% /tmp
/dev/sda5     ext3    2,8G  639M  2,0G  24% /usr
/dev/sda6     ext3    1,4G  273M  1,1G  21% /var
/dev/drbd1   ocfs2    8,0G  279M  7,8G   4% /ocfs2

Como podemos ver, temos nossa partição montada com OCFS2.

Agora podemos deixar isso na inicialização do sistema:

# vim /etc/fstab

Acrescentando:

/dev/drbd1 /ocfs2 ocfs2 _netdev,defaults 0 0

Agora vamos ajustar a ordem de inicialização dos serviços, no dois servidores.

Vamos primeiro acertar o DRBD nos dois servidores:

# vim /etc/init.d/drbd

Deixe como:

# Deixe a opção Default-Start como abaixo
# Default-Start:   S

Agora temos que acertar o o2CB nos dois servidores:

# vim /etc/init.d/o2cb

Adicione/edite:

# Temos que inserir a opção drbd para que ele inicialize depois que subir o dispositivo
# Required-Start: $network drbd

Agora temos que recarregar as configurações de inicialização dos serviços.

Vamos tirar os serviços da inicialização primeiro:

# insserv -r -v ocfs2
# insserv -r -v o2cb
# insserv -r -v drbd

Agora vamos colocar eles na inicialização novamente:

# insserv -f -v drbd
# insserv -f -v o2cb
# insserv -f -v ocfs2

Agora vamos reiniciar os servidores para testarmos se vai ser montado o DRBD na inicialização:

# init 6

Depois, da inicialização nodo1:

# uptime

Saída:

15:22:11 up 0 min,  1 user,  load average: 0.26, 0.07, 0.02

# df -Th

Saída:

Sist. Arq.    Tipo    Size  Used Avail Use% Montado em
/dev/sda1     ext3    323M  147M  160M  48% /
tmpfs        tmpfs    249M     0  249M   0% /lib/init/rw
udev         tmpfs    244M  168K  244M   1% /dev
tmpfs        tmpfs    249M     0  249M   0% /dev/shm
/dev/sda9     ext3    2,8G   69M  2,6G   3% /home
/dev/sda8     ext3    234M  6,1M  216M   3% /tmp
/dev/sda5     ext3    2,8G  639M  2,0G  24% /usr
/dev/sda6     ext3    1,4G  273M  1,1G  21% /var
/dev/drbd1   ocfs2    8,0G  151M  7,9G   2% /ocfs2

Depois, da inicialização nodo2:

# uptime

Saída:

15:22:13 up 0 min,  1 user,  load average: 0.21, 0.12, 0.04

# df -Th

Saída:

Sist. Arq.    Tipo    Size  Used Avail Use% Montado em
/dev/sda1     ext3    323M  147M  160M  48% /
tmpfs        tmpfs    249M     0  249M   0% /lib/init/rw
udev         tmpfs    244M  168K  244M   1% /dev
tmpfs        tmpfs    249M     0  249M   0% /dev/shm
/dev/sda9     ext3    2,8G   69M  2,6G   3% /home
/dev/sda8     ext3    234M  6,1M  216M   3% /tmp
/dev/sda5     ext3    2,8G  639M  2,0G  24% /usr
/dev/sda6     ext3    1,4G  273M  1,1G  21% /var
/dev/drbd1   ocfs2    8,0G  151M  7,9G   2% /ocfs2

Caso dê algum problema na inicialização, como um dos dois servidores não ficar como primary, podemos resolver da seguinte maneira:

– Primeiro vamos mandar desmontar as partições montadas com o OCFS2 nos dois servidores:

# umount /ocfs2

– Agora vamos mandar reiniciar o DRBD nos dois servidores:

# /etc/init.d/drbd restart

– Agora vamos forçar a utilização dos dois nodos primary:

# drbdadm — –overwrite-data-of-peer primary r1

– Depois, é só remontar as partições novamente nos dois servidores:

# mount.ocfs2 /dev/drbd1 /ocfs2/

Erros de sincronismo

Exemplo de erro de sincronismo dos discos, aonde perdemos a consistência dos dados, com isso, vamos precisar acertar este erro:

# cat /proc/drbd

Resultado:

version: 8.3.7 (api:88/proto:86-91)
srcversion: EE47D8BF18AC166BE219757

1: cs:StandAlone ro:Secondary/Unknown ds:Outdated/DUnknown  r—-
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:258100

No nodo2, vamos mandar ele desconsiderar os dados que ele já tem e ressincronizar com o nodo1:

# drbdadm — –discard-my-data connect r1

Agora vamos verificar a sincronismo:

# cat /proc/drbd

Resultado:

version: 8.3.7 (api:88/proto:86-91)
srcversion: EE47D8BF18AC166BE219757

1: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r—-
ns:0 nr:293128 dw:287336 dr:0 al:0 bm:19 lo:1448 pe:35179 ua:1448 ap:0 ep:1 wo:b oos:207647312
[>………………..] sync’ed: 0.2% (202780/203060)M
finish: 1:00:10 speed: 57,464 (57,464) K/sec

Assim que terminar este processo, precisamos somente forçar os dois como primary da seguinte forma:

# drbdadm — –overwrite-data-of-peer primary r1

O discos ainda sincronizando e forçados como primary:

# cat /proc/drbd

version: 8.3.7 (api:88/proto:86-91)
srcversion: EE47D8BF18AC166BE219757

1: cs:SyncSource ro:Primary/Primary ds:UpToDate/Inconsistent C r—-
ns:22204456 nr:0 dw:0 dr:22211888 al:0 bm:1356 lo:40 pe:1833 ua:1797 ap:0 ep:1 wo:b oos:185737536
[=>………………] sync’ed: 10.7% (181384/203060)M
finish: 0:55:40 speed: 55,560 (47,940) K/sec
Plus de Heartbeat

Pense que você precisa fazer o HA de um servidor de FW, por exemplo.

O que tem de diferente? Você poderia perguntar.

Pense nas interfaces de rede: Temos no mínimo 2 interfaces, uma WAN e uma LAN. Neste caso, precisaríamos configurar o Heartbeat para atribuir endereços virtuais para as duas interfaces.

Vamos a um exemplo, vou utilizar as interfaces de bond mesmo.

Agora vamos instalar o Heartbeat no srv02:

# aptitude update && aptitude dist-upgrade -y && apt-get install heartbeat heartbeat-dev -y

Agora vamos acertar a configuração do Heartbeat:

# vim /etc/ha.d/ha.cf

Edite:

# Informe os nomes dos computadores que formam a replicação(deve ser igual a saída do comando "uname -n
node srv01
node srv02
# Qual a interface vai ser usada para comunicação
mcast bond0 225.0.0.1 694 1 0
mcast bond1 225.0.0.1 694 1 0
# Fazer com que a máquina principal receba seus serviços quando retornar a ativa
auto_failback on
# Arquivos de log
debugfile /var/log/ha-debug
logfile /var/log/ha-log
# Freqüência, em segundos, da verificação das máquinas
keepalive 1
# Tempo mínimo para declarar a outra máquina como morta
deadtime 5

Agora vamos acertar a configuração do nosso IP compartilhado pelo Heartbeat:

# vim /etc/ha.d/haresources

srv01 IPaddr::10.101.0.27/24/bond0/10.101.0.255
srv01 IPaddr::172.20.0.27/24/bond1/172.20.0.255

Explicando o arquivo acima:

  • srv01: nome do servidor master
  • IPaddr::10.101.0.27/24: IP que vai ser compartilhado pelo Heartbeat
  • bond0: Interface que vai receber o IP compartilhado pelo Heartbeat
  • 10.101.0.25: Endereço de broadcast

Agora vamos acertar o arquivo com a senha de autenticação entre os Heartbeats:

# vim /etc/ha.d/authkeys

auth 3
3 md5 h34rt64t

Agora vamos acertar as permissões do arquivo de senha:

# chmod 600 /etc/ha.d/authkeys

Agora vamos instalar o Heartbeat no srv02:

# aptitude update && aptitude dist-upgrade -y && apt-get install heartbeat heartbeat-dev -y Agora vamos acertar a configuração do Heartbeat:

# vim /etc/ha.d/ha.cf

# Informe os nomes dos computadores que formam a replicação(deve ser igual a saída do comando "uname -n
node srv01
node srv02
# Qual a interface vai ser usada para comunicação
mcast bond0 225.0.0.1 694 1 0
mcast bond1 225.0.0.1 694 1 0
# Fazer com que a máquina principal receba seus serviços quando retornar a ativa
auto_failback on
# Arquivos de log
debugfile /var/log/ha-debug
logfile /var/log/ha-log
# Freqüência, em segundos, da verificação das máquinas
keepalive 1
# Tempo mínimo para declarar a outra máquina como morta
deadtime 5

Agora, vamos acertar a configuração do nosso IP compartilhado pelo Heartbeat:

# vim /etc/ha.d/haresources

srv01 IPaddr::10.101.0.27/24/bond0/10.101.0.255
srv01 IPaddr::172.20.0.27/24/bond0/172.20.0.255

Agora, vamos acertar o arquivo com a senha de autenticação entre os Heartbeats:

# vim /etc/ha.d/authkeys

auth 3
3 md5 h34rt64t

Agora vamos acertar as permissões do arquivo de senha:

# chmod 600 /etc/ha.d/authkeys

Agora vamos reiniciar o Heartbeat nos dois servidores:

# /etc/init.d/heartbeat restart

Agora vamos consultar as interfaces no servidor srv01:

# ifconfig

Resultado:

bond0  Link encap:Ethernet Endereço de HW 08:00:27:3f:b0:b8
inet end.: 10.101.0.25 Bcast:10.101.0.255 Masc:255.255.255.0
endereço inet6: fe80::a00:27ff:fe3f:b0b8/64 Escopo:Link
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1
RX packets:28239 errors:0 dropped:0 overruns:0 frame:0
TX packets:1356 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:2576871 (2.4 MiB) TX bytes:464634 (453.7 KiB)

bond0:0  Link encap:Ethernet Endereço de HW 08:00:27:3f:b0:b8
inet end.: 10.101.0.27 Bcast:10.101.0.255 Masc:255.255.255.0
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1

bond1  Link encap:Ethernet Endereço de HW 08:00:27:ff:cd:7c
inet end.: 172.20.0.25 Bcast:172.20.0.255 Masc:255.255.255.0
endereço inet6: fe80::a00:27ff:feff:cd7c/64 Escopo:Link
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1
RX packets:204376 errors:0 dropped:0 overruns:0 frame:0
TX packets:36125 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:230398360 (219.7 MiB) TX bytes:9571891 (9.1 MiB)

bond1:0  Link encap:Ethernet Endereço de HW 08:00:27:ff:cd:7c
inet end.: 172.20.0.27 Bcast:172.20.0.255 Masc:255.255.255.0
UP BROADCASTRUNNING MASTER MULTICAST MTU:1500 Métrica:1

eth0    Link encap:Ethernet Endereço de HW 08:00:27:3f:b0:b8
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:14227 errors:0 dropped:0 overruns:0 frame:0
TX packets:684 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:1300809 (1.2 MiB) TX bytes:246914 (241.1 KiB)

eth1    Link encap:Ethernet Endereço de HW 08:00:27:3f:b0:b8
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:14012 errors:0 dropped:0 overruns:0 frame:0
TX packets:672 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:1276062 (1.2 MiB) TX bytes:217720 (212.6 KiB)

eth2    Link encap:Ethernet Endereço de HW 08:00:27:ff:cd:7c
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:190049 errors:0 dropped:0 overruns:0 frame:0
TX packets:18077 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:229048128 (218.4 MiB) TX bytes:4820003 (4.5 MiB)

eth3    Link encap:Ethernet Endereço de HW 08:00:27:ff:cd:7c
UP BROADCASTRUNNING SLAVE MULTICAST MTU:1500 Métrica:1
RX packets:14327 errors:0 dropped:0 overruns:0 frame:0
TX packets:18048 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:1350232 (1.2 MiB) TX bytes:4751888 (4.5 MiB)

lo        Link encap:Loopback Local
inet end.: 127.0.0.1 Masc:255.0.0.0
endereço inet6: ::1/128 Escopo:Máquina
UP LOOPBACKRUNNING MTU:16436 Métrica:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Aqui, o que é preciso mudar são as interfaces, caso não trabalhe com o bond e os endereços IPs. 😉

SSH – Tradução da man page

 Clusterweb, Leitura Recomendada, Linux  Comentários desativados em SSH – Tradução da man page
mar 082013
 
Sinopse / Descrição

Nome:

SSH – Cliente OpenSSH SSH (programa de login remoto)

Sinopse:

ssh [ -1246AaCfgKkMNnqsTtVvXxYy ] [ -b bind_address ][ -c cipher_spec ]
[ -D [bind_address:]port][ -e escape_char ][ -F configfile ][ -i identity_file ]
[ -L [bind_address:]port:host:hostport][ -l login_name ][ -m mac_spec ]
[ -O ctl_cmd ][ -o option ][ -p port ][ -R [bind_address:]port:host:hostport]
[ -S ctl_path ][ -w local_tun [:remote_tun]] [user@]hostname [ command ]

Descrição:

O SSH (cliente SSH) é um programa para conectar-se e executar comandos em máquina remota. É proposital substituir o “rlogin” e o “rsh” e prover comunicações criptografadas de forma segura entre dois hosts não confiáveis sobre uma rede não segura. As conexões X11 e portas TCP arbitrárias, também podem ser encaminhadas através do canal seguro.

O SSH conecta-se e faz o login em um hostname específico (com nome de usuário opcional). O usuário deve provar sua identidade à máquina remota usando um dos vários métodos, dependendo da versão usada do protocolo (veja abaixo).

Se o comando é especificado, ele é executado em um host remoto ao invés de um acesso shell.

As opções estão a seguir:

-1 :: Obriga o SSH a tentar somente a versão 1 do protocolo;

-2 :: Obriga o SSH a tentar somente a versão 2 do protocolo;

-4 :: Obriga o SSH a usar somente endereços IPv4;

-6 :: Obriga o SSH a usar somente endereços IPv6;

-A :: Ativa o encaminhamento de uma conexão de autenticação de agente. Isto também pode ser especificado numa base por host em um arquivo de configuração.

O agente encaminhado deve ser ativado com cuidado. Usuários com a habilidade de ignorar arquivos de permissões em um host remoto (para o socket Unix-domain do agente) podem acessar o agente local pela conexão encaminhada.

Um atacante não pode obter material chave de um agente, porém, ele pode executar operações nas chaves que permite sua autenticação usando identidades carregadas no agente.

-a :: Desativa o encaminhamento da conexão da autenticação do agente;

-b bind_address :: Usa bind_address na máquina local como o endereço origem da conexão. É útil somente em sistemas com mais de um endereço.

-C :: Requer compressão de todos os dados (incluindo stdin, stdout, stderr, e dados encaminhados via X11 e conexões TCP). O algoritmo de compressão é o mesmo usado pelo gzip(1), e o “nível” pode ser controlado pela opção “CompressionLevel” da versão 1 do protocolo.

A compressão é desejada em linhas de modem e outras conexões mais lentas, mas irá somente diminuir as coisas em conexões rápidas. O valor padrão pode ser definido em uma base host-para-host nos arquivos de configuração.

Veja a opção compressão:

-c cipher_spec :: Seleciona a especificação de cifra para criptografar a sessão. A versão 1 do protocolo permite a especificação de uma cifra única.

Os valores suportados são “3des”, “blowfish”, e “des”:

  • O “3des” (triplo-des) é uma tripla (encripta-decripta-encripta) com três diferentes chaves. Acredita-se que seja seguro.
  • O “blowfish” é uma cifra de bloco rápida, parece ser muito seguro e bem mais rápido que o 3des.
  • O “des” é suportado somente no cliente ssh para interoperabilidade com a implementação do protocolo 1 que não suporta a cifra 3des. Seu uso é fortemente desencorajado devido às deficiências criptográficas. O padrão é o “3des”.

Para a versão 2 do protocolo, cipher_spec é uma lista de cifras separadas por vírgula listadas em ordem de preferência. Veja a palavra-chave “Ciphers” para mais informações.

-D [bind_address:]porta :: Especifica um encaminhamento de uma porta de nível de aplicação local “dinâmica”. Funciona alocando um socket para escutar a porta no lado local, opcionalmente limitado pelo específico “bind_address”.

Quando uma conexão é feita nessa porta ela é encaminhada sobre o canal seguro, e o protocolo da aplicação é depois usado para determinar onde se conectar na máquina remota.

Atualmente os protocolos SOCKS4 e SOCKS5 são suportados, e o SSH irá atuar como um servidor SOCKS. Somente o usuário root pode encaminhar portas privilegiadas. Encaminhamentos dinâmicos de portas podem ser especificados no arquivo de configuração.

Endereços IPv6 podem ser especificados com uma sintaxe alternativa:

[ bind_address/]porta

Ou colocando o endereço entre chaves. Somente o superusuário pode encaminhar portas privilegiadas. Por padrão a porta local é limitada de acordo com a configuração do GatewayPorts. Porém um “bind_address” explícito pode ser usado para ligar a conexão com o endereço específico.

O “bin_address” de “localhost” indica que a porta escutada pode ser limitada somente para o usuário local, enquanto um endereço vazio, ou ‘*’, indica que a porta deve estar disponível para todas as interfaces.

-e escape_char :: Define o caractere de escape para sessões com tty (default: “~”). O caractere de escape é somente reorganizado no começo de uma linha. Se o caractere de escape for seguido por um ponto (‘.’) fecha a conexão; seguido por Ctrl-Z suspende a conexão; e seguido por si mesmo envia o caractere de escape uma vez. Definindo o caractere como “none”/”nenhum” desativa quaisquer escapes e torna a sessão completamente transparente.

-F configfile :: Especifica um arquivo de configuração alternativo por usuário. Se um arquivo de configuração é passado por linha de comando, o arquivo de configuração de todo o sistema (/etc/ssh/ssh_config) será ignorado. O padrão para um arquivo de configuração por usuário é: ~/.ssh/config.

-f :: Pede para o SSH ir para background antes da execução do comando. É útil se o SSH vai perguntar por senhas ou frases secretas, mas o usuário o quer em background. Isto implica em “-n”. O modo recomendado para iniciar programas X11 em um site remoto é com alguma coisa do tipo: ssh -f host xterm.

Se a opção de configuração “ExitOnForwardFailure” for definida como “yes”, logo, um cliente iniciado com “-f” irá esperar por todos os encaminhamentos das portas remotas serem estabelecidas com sucesso antes de colocarem a si mesmos em background.

-g :: Permite hosts remotos conectarem-se à portas de encaminhamento locais.

-I smartcard_device :: Especifica o dispositivo que SSH deve usar para se comunicar com um smartcard usado para guardar a chave privada RSA dos usuários. Esta opção está disponível apenas se o suporte para dispositivos smartcards forem compilados (padrão não é suportado).

-i identity_file :: Seleciona um arquivo de onde cada identidade (chave privada) para autenticações RSA ou DAS são lidas. O padrão é ~/.ssh/identity para a versão 1 do protocolo, e ~/.ssh/id_rsa e ~/.ssh/id_dsa para a versão 2 do protocolo.

Arquivos de identidade devem ser especificados em uma base por host em um arquivo de configuração. É possível ter múltiplas opções “-i” (e múltiplas identidades especificadas em um arquivo de configuração).

-K :: Ativa a autenticação GSSAPI e encaminha (delegação) das credenciais GSSAPI para o servidor.

-k :: Desativa o encaminhamento (delegação) das credenciais GSSAPI para o servidor.

-L [bind_address:]port:host:hostport :: Especifica que a porta passada no host local (cliente) deve ser encaminhada para o host passado e porta no lado remoto.

Isso funciona basicamente alocando-se um socket para escutar uma porta no lado local, opcionalmente ligada ao “bind_address”. Sempre que uma conexão é feita nessa porta, a conexão é encaminhada sobre o canal seguro, e a conexão é feita na porta do host (host port) da máquina remota.

Encaminhamentos de portas podem ser especificados em um arquivo de configuração. Endereços IPv6 podem ser especificados com uma sintaxe alternativa:

[ bind_address/]port/host/hostport

Ou, colocando o endereço entre chaves. Somente o superusuário pode encaminhar portas privilegiadas. Por padrão, a porta local é ligada de acordo com a configuração GatewayPorts. Porém, um “bind_address” explícito pode se usado para ligar a conexão a um endereço específico.

O “bind_address” de um “localhost” indica que a porta que escuta seja ligada somente para o usuário local, enquanto um endereço vazio, ou ‘*’, indica que a porta deve estar disponível para todas as interfaces.

-l login_name :: Especifica o usuário a logar na máquina remota. Isto também pode ser especificado em uma base por host em um arquivo de configuração.

-M :: Coloca o cliente SSH no modo “master” para compartilhamento de conexão. Múltiplas opções “-M” coloca o SSH no modo “master” com confirmação necessária antes que conexões escravas sejam aceitas. Veja a descrição do ControlMaster em “ssh_config(5)” para mais detalhes.

-m mac_spec :: Adicionalmente, para o protocolo versão 2, uma lista de algoritmos MAC (código de autenticação de mensagem) separada por vírgulas pode ser especificada em ordem de preferência. Veja a palavra chave MAC para mais informações.

-N :: Não executa um comando remoto. Pode ser útil apenas para portas de encaminhamento (apenas protocolo versão 2).

-n :: Redireciona a saída “stdin” para /dev/null (na verdade, previne a leitura do “stdin”). Deve ser usado quando o SSH roda em background. Um truque comum é usar isso para executar programas X11 em uma máquina remota. Por exemplo:

$ ssh -n shadows.cs.hut.fi emacs &

Irá iniciar um Emacs em shadows.cs.hut.fi, e a conexão X11 será automaticamente encaminhada sobre um canal criptografado. O programa SSH irá ser colocado em background (isso não funciona se o SSH precisar perguntar por uma senha ou frase secreta. Veja também a opção: -f).

-O ctl_cmd :: Controla uma conexão ativa multiplexando processos mestre. Quando a opção “-O” é especificada, o argumento “ctl_cmd” é interpretado e passado para o processo mestre. Os comandos válidos são:

  • check :: Checa se o processo mestre está executando;
  • exit :: Solicita o mestre para sair.

-o option :: Pode ser usado para fornecer opções no formato usado no arquivo de configuração. Isto é útil para especificar opções que não são separadas por uma flag de linha de comando.

Para detalhes completos das opções listadas abaixo, e seus possíveis valores, veja o “ssh_config(5)”:

  • AddressFamily
  • BatchMode
  • BindAddress
  • ChallengeResponseAuthentication
  • CheckHostIP
  • Cipher
  • Ciphers
  • ClearAllForwardings
  • Compression
  • CompressionLevel
  • ConnectionAttempts
  • ConnectTimeout
  • ControlMaster
  • ControlPath
  • DynamicForward EscapeChar
  • ExitOnForwardFailure
  • ForwardAgent
  • ForwardX11
  • ForwardX11Trusted
  • GatewayPorts
  • GlobalKnownHostsFile
  • GSSAPIAuthentication
  • GSSAPIDelegateCredentials
  • HashKnownHosts
  • Host
  • HostbasedAuthentication
  • HostKeyAlgorithms
  • HostKeyAlias
  • HostName
  • IdentityFile
  • IdentitiesOnly
  • KbdInteractiveDevices
  • LocalCommand
  • LocalForward
  • LogLevel
  • MACs
  • NoHostAuthenticationForLocalhost
  • NumberOfPasswordPrompts
  • PasswordAuthentication
  • PermitLocalCommand
  • Port
  • PreferredAuthentications
  • Protocol
  • ProxyCommand
  • PubkeyAuthentication
  • RekeyLimit
  • RemoteForward
  • RhostsRSAAuthentication
  • RSAAuthentication
  • RemoteForward
  • RhostsRSAAuthentication
  • RSAAuthentication
  • SendEnv
  • ServerAliveInterval
  • ServerAliveCountMax
  • StrictHostKeyChecking
  • TCPKeepAlive
  • Tunnel
  • TunnelDevice
  • UsePrivilegedPort
  • User
  • UserKnownHostsFile
  • VerifyHostKeyDNS
  • VisualHostKey
  • XAuthLocation

-p porta :: Porta para conectar no host remoto. Isto pode ser especificado em uma base por host no arquivo de configuração.

-q :: Modo quieto. Faz com que a maioria das mensagens de aviso e diagnóstico sejam suprimidas. Apenas erros fatais são exibidos. Se um segundo “-q” é dado, então, mesmo erros fatais são suprimidos, exceto aqueles produzidos por argumentos errados.

-R [endereço_de_ligação:]porta:host:porta_do_host :: Especifica que a dada porta no host (servidor) remoto será direcionada para o host e porta dados no lado no local.

Isto funciona por meio de uma alocação de socket para escutar a porta no lado remoto, e quando a conexão é feita nesta porta, a conexão é direcionada sobre um canal seguro, e uma conexão é feita para host na porta “porta_do_host” da máquina local.

Direcionamento de portas pode também ser especificado no arquivo de configuração. Portas privilegiadas só podem ser direcionadas quando estiver logado como root na máquina remota. Endereços IPv6 podem ser especificados por meio de uma inclusão do endereço entre colchetes ou usando uma sintaxe alternativa:

[bind_address/]host/port/hostport

Por padrão o socket que está escutando no servidor será ligado para a interface de loopback somente. Isto pode ser sobrescrito especificando um endereço_de_ligação. Um endereço_de_ligação vazio, ou o endereço ‘*’, indica que o socket remoto deve escutar em todas as interfaces. Especificando um endereço_de_ligação remoto só irá ter sucesso se a opção GatewayPorts do servidor estiver habilitada (veja: ssh_config(5) ).

Se o argumento porta for ‘0’, a porta de escuta será dinamicamente alocada no servidor e reportada para o cliente em tempo de execução. Quando usado junto com “-O forward”, a porta alocada será impressa na saída padrão.

-S caminho_ctl :: Especifica a localização de um socket de controle para compartilhamento de conexão, ou a cadeia “none” para desabilitar o compartilhamento de conexão. Consulte a descrição de ControlPath e ControlMaster em ssh_config(5) para mais detalhes.

-s :: Pode ser usado para requisitar uma invocação de um subsistema no sistema remoto. Subsistemas são uma característica do protocolo SSH2 o qual facilita o uso do SSH como um transporte seguro para outras aplicações (ex.: sftp(1)). O subsistema é especificado como o comando remoto.

-T :: Desativa a alocação de pseudo-tty.

-t :: Força a alocação pseudo-tty. Isto pode ser usado para executar programas arbitrários baseados em tela em uma máquina remota, o qual pode ser muito útil, por exemplo, quando estiver implementando serviços de menu. Múltiplas opções “-t” forçam a alocação tty, mesmo se o SSH não tem um tty local.

-V :: Mostra o número da versão e sai.

-v :: Modo de detalhe. Faz o SSH imprimir mensagens de depuração sobre o seu progresso. Isto é útil para depurar problemas de conexão, autenticação e configuração. Múltiplas opções “-v” aumentam o detalhamento. O máximo é 3.

-w – local_tun[:remote_tun] :: Requisita um encaminhamento de dispositivo de encapsulamento com os dispositivos tun(4) especificados entre o cliente (local_tun) e o servidor (remote_tun).

Os dispositivos podem ser especificados por ID numérico ou pela palavra-chave “any” (qualquer), que faz utilizar o próximo dispositivo de encapsulamento disponível.

Se “remote_tun” não for especificado, “any” é utilizado por padrão. Veja também as diretivas Tunnel e TunnelDevice em ssh_config(5). Se a diretiva Tunnel estiver indefinida, será definido o modo de encapsulamento padrão, que é “point-to-point” (ponto-a-ponto).

-X :: Habilita o encaminhamento de X11. Isto pode ser especificado por host no arquivo de configuração.

O encaminhamento de X11 deve ser habilitado com cuidado. Usuários com a habilidade de contornar permissões de arquivos no host remoto (para o banco de dados de autorização X do usuário) podem acessar o display X11 local através da conexão encaminhada.

Uma pessoa pode atacar e conseguir fazer atividades como monitoramento de teclas pressionadas. Por esta razão, o encaminhamento X11 está sujeito, por padrão, à extensão de restrições X11 SECURITY (segurança).

Por favor, refira-se à opção “-Y” do SSH e a diretiva ForwardX11Trusted no “ssh_config(5)” para mais informações.

-x :: Desativa o encaminho de X11.

-Y :: Habilita o encaminhamento confiável de X11. O encaminhamento confiável de X11 não está sujeito aos controles de extensão X11 SECURITY.

-y :: Envia informações do log utilizando o módulo de sistema syslog(3). Por padrão, esta informação é enviada para stderr.

O SSH, adicionalmente, poderá obter dados de configuração de um arquivo de configuração por usuário e um arquivo abrangente do sistema. O formato do arquivo e as opções de configuração, são descritos em “ssh_config(5)”.

O SSH sai com o status de saída do comando remoto, ou com 255, se um erro ocorrer.
Autenticação

O cliente SSH do OpenSSH suporta os protocolos SSH 1 e 2. O protocolo 2 é o padrão, com SSH voltando para o protocolo 1 se detectar que o protocolo 2 não é suportado. Estas configurações podem ser alteradas usando a opção Protocol em “ssh_config(5)”, ou impostas usando as opções “-1” e “-2” (veja acima).

Ambos os protocolos suportam métodos semelhantes de autenticação, mas o protocolo 2 é preferível, pois proporciona mecanismos adicionais de confidencialidade (o tráfego é encriptado usando AES, 3DES, Blowfish, CAST128, ou Arcfour) e integridade (HMAC-MD5, HMAC-SHA1, UMAC-64, HMAC-RIPEMD160). O protocolo 1 carece de um forte mecanismo para assegurar a integridade da conexão.

Os métodos disponíveis para autenticação são:

  • Autenticação baseada em GSSAPI;
  • Autenticação baseada em host;
  • Autenticação por chave pública;
  • Autenticação desafio-resposta;
  • Autenticação por password.

Métodos de autenticação são tentados na ordem especificada acima, embora o protocolo 2 tenha uma opção de configuração para mudar a ordem padrão: “PreferredAuthentications”.

A autenticação baseada em host funciona da seguinte maneira. Se a máquina que o usuário logar estiver listada em /etc/hosts.equiv ou /etc/ssh/shosts.equiv na máquina remota, e o nome dos usuários é o mesmo em ambos os lados, ou, se os arquivos ~/.rhosts ou ~/.shosts existirem no diretório HOME do usuário na máquina remota e conter uma linha contendo o nome da máquina cliente e o nome do usuário naquela máquina, o usuário é considerado para logar.

Adicionalmente o servidor precisa ser capaz de verificar a chave de host do cliente (veja a descrição de /etc/ssh/ssh_known_hosts e ~/.ssh/known_hosts, abaixo) para o login ser permitido.

Este método de autenticação fecha buracos na segurança devido ao IP spoofing, DNS spoofing, e spoofing de roteamento.

** Nota para o administrador: /etc/hosts.equiv, ~/.rhosts e o protocolo rlogin/rsh, em geral, são inerentemente inseguros e devem ser desativados se a segurança é desejada.

A autenticação por chave pública funciona da seguinte maneira: O esquema é baseado na criptografia de chave-pública, usando criptosistemas onde a encriptação e decriptação são feitas usando chaves separadas, e é inviável derivar a chave de decriptação através da chave de encriptação.

A ideia é que cada usuário crie um par de chaves pública/privada para o propósito de autenticação. O servidor conhece a chave pública, e somente o usuário conhece a chave privada. O SSH implementa o protocolo de autenticação por chave pública automaticamente, usando o algoritmo RSA ou DAS.

O protocolo 1 é restringido a usar somente chaves RSA, mas o protocol 2 pode usar qualquer um. A seção HISTORY de “ssl(8)” (em sistemas não-OpenBSD, veja em HISTORY) contém uma breve discussão dos dois algoritmos.

O arquivo ~/.ssh/authorized_keys lista as chaves públicas que são permitidas para efetuar logon. Quando o usuário loga, o programa SSH diz ao servidor qual par de chaves gostaria de usar para a autenticação. O cliente prova que tem acesso à chave privada e o servidor checa que a chave pública correspondente está autorizada a aceitar a conta.

O usuário cria seu par de chaves executando ssh-keygen(1). Isto armazena a chave privada em ~/.ssh/identity (protocolo 1), ~/.ssh/id_dsa (protocolo 2 DSA), ou ~/.ssh/id_rsa (protocolo 2 RSA) e armazena a chave pública em ~/.ssh/identity.pub (protocolo 1), ~/.ssh/id_dsa.pub (protocolo 2 DSA), ou ~/.ssh/id_rsa.pub (protocolo 2 RSA) no diretório HOME do usuário.

O usuário deve, então, copiar a chave pública para ~/.ssh/authorized_keys em seu diretório HOME na máquina remota. O arquivo “authorized_keys” corresponde ao arquivo ~/.rhosts convencional, e tem uma chave por linha, embora as linhas podem ser muito longas. Depois disto, o usuário pode efetuar logon sem dar o password.

A maneira mais conveniente de usar autenticação por chave pública pode ser com um agente de autenticação. Veja “ssh-agent(1)” para mais informações.

A autenticação desafio-resposta funciona da seguinte maneira. O servidor envia um “desafio” arbitrário em texto, e espera por uma resposta. O protocolo 2 permite múltiplos desafios e respostas; o protocolo 1 é restrito a apenas um desafio/resposta. Exemplos de autenticação desafio-resposta incluem autenticação BSD (veja login.conf(5)) e PAM (para alguns sistemas não-OpenBSD).

Finalmente, se outros métodos de autenticação falharem, o SSH pede uma senha para o usuário. A senha é enviada para o host remoto para ser checada; entretanto, já que todas as comunicações são encriptadas, a senha não pode ser vista por alguém que esteja escutando a rede.

O SSH, automaticamente, mantém e checa um banco de dados contendo uma identificação de todos os hosts com que ele já foi usado. As chaves do host são armazenadas em ~/.ssh/known_hosts no diretório HOME do usuário.

Adicionalmente, o arquivo /etc/ssh/ssh_known_hosts é automaticamente checado para hosts conhecidos. Quaisquer novos hosts são automaticamente adicionados ao arquivo do usuário. Se a identificação de um host mudar, o SSH alerta sobre isto e desativa a autenticação por senha para prevenir ataques de spoof de servidor ou man-in-the-middle, que poderiam caso contrário ser usados para circundar a encriptação.

A opção StrictHostKeyChecking pode ser usada para controlar logins em máquinas cuja chave hospedeira não é conhecida ou tenha mudado.

Quando a identidade do usuário for aceita pelo servidor, ou o servidor executa o comando dado, ou loga na máquina e dá ao usuário um shell normal na máquina remota, todas as comunicações com o comando remoto ou shell vão ser automaticamente encriptados.

Se um pseudo-terminal foi alocado (sessão normal de login), o usuário poderá usar os caracteres de escape escritos abaixo.

Se nenhum pseudo-tty foi alocado, a sessão é transparente e pode ser usada para transferir dados binários confiavelmente. Na maioria dos sistemas, definindo o caractere de escape para “none”, também fará a sessão ser transparente mesmo se um tty for utilizado.

A sessão finaliza quando o comando, ou shell na máquina remota, sai e todas conexões X11 e TCP são fechadas.
Caracteres / Encaminhamento / Chaves de host

Caracteres de escape

Quando um pseudo-terminal for requisitado, o SSH suporta um número de funções através do uso de um caractere de escape.

Um simples til (~) pode ser enviado como “–“, ou colocando um caractere na frente no til que não esteja descrito abaixo. O caractere de escape deve sempre seguir uma quebra de linha para ser interpretado como especial.

O caractere de escape pode ser trocado nos arquivos de configuração usando a diretiva de configuração EscapeChar ou na linha de comando pela opção “-e”.

Os escapes suportados (assumindo o padrão ‘-‘) são:

  • -. :: Desconectar.
  • -^Z :: SSH em background.
  • -# :: Listar as conexões encaminhadas.
  • -& :: Coloca o SSH em background no logout quando estiver esperando conexões encaminhadas/ sessões X11 terminarem.
  • -? :: Mostra uma lista de caracteres de escape.
  • -B :: Envia um BREAK para o sistema remoto (só é útil para o procotolo SSH versão 2 e se o par suportar).
  • -C :: Abre a linha de comando. Atualmente, isto permite a adição de encaminhamento de portas usando as opções “-L”, “-R” e “-D” (veja acima). Também permite o cancelamento de encaminhamentos de porta remotos existentes usando “-KR[endereço_de_ligação:]porta”.
  • !command :: Permite o usuário executar um comando local se a opção PermitLocalCommand estiver habilitada em “ssh_config(5)”. Uma ajuda básica está disponível, usando a opção “-h”.
  • -R :: Requisita o rechaveamento da conexão (só é útil para o protocolo SSH versão 2 e se o par suportar).

Encaminhamento TCP

O encaminhamento de conexões TCP arbitrárias, sobre o canal seguro, podem ser especificadas ou na linha de comando ou no arquivo de configuração. Uma possível aplicação para o encaminhamento TCP é uma conexão segura para um servidor de correio eletrônico; outra é ir através de firewalls.

No exemplo abaixo deparamos com a encriptação da comunicação entre um cliente e servidor IRC, mesmo que o servidor IRC não suporte comunicações encriptadas diretamente.

Isto funciona da seguinte maneira. O usuário conecta no host remoto usando SSH, especificando uma porta para ser usada para encaminhar conexões para o servidor remoto. Depois disso pode-se iniciar o serviço o qual será encriptado na máquina cliente, conectando na mesma porta local, e o SSH irá encriptar e encaminhar a conexão.

O exemplo a seguir encapsula uma sessão IRC da máquina cliente “127.0.0.1” (localhost) para o servidor remoto “server.example.com”:

$ ssh -f -L 1234:localhost:6667 server.example.com sleep 10
$ irc -c ‘#users’ -p 1234 pinky 127.0.0.1

Isto encapsula uma conexão para o servidor IRC “server.example.com”, unindo ao canal “#users”, com nickname “pinky”, usando a porta 1234. Não importa qual porta é usada, desde que seja maior que 1023 (lembre-se: somente o root pode abrir sockets em portas privilegiadas) e não conflita com qualquer porta que já esteja em uso. A conexão é encaminhada para a porta 6667 no servidor remoto, já que esta é a porta padrão para serviços IRC.

A opção “-f” faz o SSH ficar em background e o comando remoto “sleep 10” é especificado para permitir uma quantidade de tempo (10 segundos, no exemplo) para iniciar o serviço que irá ser encapsulado. Se nenhuma conexão for feita no tempo especificado, o SSH sairá.

Encaminhamento X11

Se a variável ForwardX11 estiver definida como “yes” (ou veja acima a descrição das opções “-X”, “-x”, e “-Y”) e o usuário estiver usando X11 (a variável de ambiente DISPLAY está definida), a conexão para o display X11 é automaticamente encaminhada para o lado remoto, de tal maneira que, quaisquer programas X11 iniciados pelo shell (ou comando) irão através do canal encriptado, e a conexão para o verdadeiro servidor X será feita a partir da máquina local.

O usuário não deve definir DISPLAY manualmente. Encaminhamento de conexões X11 podem ser configuradas pela linha de comando ou nos arquivos de configuração.

O valor definido para DISPLAY pelo SSH irá apontar para a máquina servidor, mas com um número de display maior que zero. Isto é normal, e acontece porque o SSH cria um servidor X “proxy” na máquina servidor para encaminhar conexões sobre o canal encriptado.

O SSH também irá definir dados Xauthority automaticamente na máquina servidor. Para este fim, ele criará um cookie de autorização aleatória, armazená-lo em Xauthority no servidor, e verificar que as conexões encaminhadas que carregam esse cookie e substituí-lo pelo cookie real quando a conexão é aberta. O cookie de autenticação real nunca é enviado para a máquina servidor (e nenhum cookie é enviado na íntegra).

Se a variável ForwardAgent é definida como “yes” (ou veja a descrição das opções “-A” e “-a”, acima) e o usuário está usando um agente de autenticação, a conexão com o agente é automaticamente encaminhada para o lado remoto.

Verificando chaves de host

Ao se conectar a um servidor pela primeira vez, um fingerprint (impressão digital) da chave pública do servidor é apresentado ao usuário (a menos que a opção foi StrictHostKeyChecking desativada). Fingerprints podem ser determinados usando “ssh-keygen(1)”:

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

Se o fingerprint já é conhecido, ele pode ser comparado e a chave pode ser aceita ou rejeitada. Por causa da dificuldade de comparar chaves de host só de olhar para cadeias hexadecimais, também há suporte para comparar chaves de host visualmente, usando arte aleatória.

Ao definir a opção VisualHostKey para “yes”, um pequeno gráfico ASCII é exibido em cada login para um servidor, não importando se a sessão em si é interativa ou não.

Ao aprender o padrão que um servidor conhecido produz, um usuário pode facilmente descobrir que a chave de host mudou quando um padrão completamente diferente é exibido. Por causa que estes padrões não são ambíguos no entanto, um padrão que se parece com o padrão lembrado apenas dá uma boa probabilidade de que a chave de host é a mesma, e não uma prova garantida.

Para obter uma lista dos fingerprints, juntamente com sua arte aleatória para todos os hosts conhecidos, a seguinte linha de comando pode ser usada:

$ ssh-keygen -lv -f -/.ssh/known_hosts

Se o fingerprint é desconhecido, um método alternativo está disponível: “fingerprints de SSH verificados por DNS”. Um registro de recurso (RR) adicional, SSHFP, é adicionado a um zonefile (arquivo de zonas) e o cliente que está conectando poderá comparar o fingerprint com aquele da chave apresentada.

Neste exemplo, estamos conectando um cliente para um servidor (host.example.com). O registro de recurso SSHFP deve, primeiramente, ser adicionado ao zonefile para “host.example.com”:

$ ssh-keygen -r host.example.com

As linhas de saída terão de ser adicionadas ao zonefile. Para verificar que a zona está respondendo consultas de impressões digitais:

$ dig -t SSHFP host.example.com

Finalmente, o cliente conecta:

$ ssh -o “VerifyHostKeyDNS ask” host.example.com
[…]
Matching host key fingerprint found in DNS.

Are you sure you want to continue connecting (yes/no)?

Para mais informações, veja o VerifyHostKeyDNS, opção em “ssh_config(5)”.
Base Virtual / Ambiente / Files

SSH – Base Virtual de Redes Privadas

SSH contém suporte para Virtual Private Network (VPN) tunnelling usando tun(4) rede pseudo-device permitindo que duas redes se juntem de forma segura. O “sshd_config(5)”, opção de configuração PermitTunnel, controla se o servidor suporta isso, e em que nível (camada 2 ou 3 de tráfego).

O exemplo a seguir, iria ligar a rede cliente “10.0.50.0/24” com a rede remota “10.0.99.0/24” usando uma conexão ponto-a-ponto a partir de “10.1.1.1” a “10.1.1.2”, desde que o servidor SSH esteja rodando no gateway para a rede remota, em “192.168.1.15”, permitir.

No cliente:

# ssh -f -w 0:1 192.168.1.15 true
# ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
# route add 10.0.99.0/24 10.1.1.2

No servidor:

# ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
# route add 10.0.50.0/24 10.1.1.1

O acesso do cliente pode ser mais afinado através do arquivo /root/.ssh/authorized_keys (veja abaixo) e a opção do servidor PermitRootLogin. A entrada a seguir, permitirá conexões em tun(4) dispositivo 1 para o usuário “Jane” e em tun dispositivo 2 para o usuário “john”, se PermitRootLogin é definido para “forced-commands-only”:

tunnel=”1″,command=”sh /etc/netstart tun1″ ssh-rsa … jane
tunnel=”2″,command=”sh /etc/netstart tun2″ ssh-rsa … John

Desde que uma instalação SSH-based implica em certa quantidade de sobrecarga, pode ser mais adequado para instalações temporárias, como para VPNs sem fio. VPNs mais permanentes são melhores fornecidas por ferramentas, como “ipsecctl(8)” e “isakmpd(8)”.

Ambiente

SSH normalmente define as seguintes variáveis de ambiente:

  • DISPLAY – A variável DISPLAY indica a localização do servidor X11. É automaticamente definida por SSH para apontar a um valor na forma de “hostname:n”, onde “hostname” indica o host onde o shell é executado e ‘n’ é um inteiro “- 1. ssh” utiliza este valor especial para transmitir conexões X11 pelo canal seguro. O usuário normalmente não deveria definir DISPLAY explicitamente, como que vai tomar a conexão X11 insegura (e exigirá ao usuário copiar manualmente qualquer autorização necessária de cookies).
  • HOME – Definido para o caminho do diretório HOME do usuário.
  • LOGNAME: Sinônimo de USER – Definido para compatibilidade com sistemas que utilizam esta variável.
  • MAIL – Definido para o caminho da caixa postal (mailbox) do usuário.
  • PATH – Definido para o caminho (PATH) padrão, conforme especificado na compilação do SSH.
  • SSH_ASKPASS – Se SSH precisar de uma senha, ele irá ler a senha do terminal atual se ele foi executado a partir de um terminal. Se SSH não tem um terminal associado a ele, mas DISPLAY e SSH_ASKPASS estão definidos, ele irá executar o programa especificado por SSH_ASKPASS e abrirá uma janela X11 para ler a senha. Isso é particularmente útil quando se chama ssh de um “.xsession” ou escrita relacionada (note que em algumas máquinas, pode ser necessário redirecionar a entrada de /dev/null para fazer este trabalho).
  • SSH_AUTH_SOCK – Identifica o caminho de um domínio UNIX-soquete usado para se comunicar com o agente.
  • SSH_CONNECTION – Identifica as extremidades da conexão cliente e servidor. A variável contém quatro espaços de valores separados: endereço IP do cliente, número de porta do cliente, endereço IP do servidor e número de porta do servidor.
  • SSH_ORIGINAL_COMMAND – Esta variável contém a linha de comando original se um comando forçado é executado. Ele pode ser usado para extrair os argumentos originais.
  • SSH_TTY – Este é definido para o nome da tty (caminho para o dispositivo) associado com o shell atual ou comando. Se a sessão atual não tem tty, esta variável não está definida.
  • TZ – Esta variável é definida para indicar o fuso horário atual se ele foi definido quando o daemon (servidor) foi iniciado (i.e. o daemon (servidor) passa o valor para novas conexões).
  • User – Definido para o nome do usuário logado.

Além disso, o SSH lê ~/.ssh/environment, e adiciona linhas do formato “VARNAME = value” para o ambiente, se o arquivo existe, e os usuários têm permissão para mudar seu ambiente. Para mais informações, consulte o PermitUserEnvironment opção em “sshd_config(5)”.

Files

  • ~/.rhosts :: Este arquivo é utilizado para autentificação do host-based (veja acima). Em algumas máquinas este arquivo pode precisar ser de leitura à todos se o diretório home do usuário está em uma partição NFS, porque “sshd(8)” o lê como root. Além disso, este arquivo deve ser de propriedade do usuário, e não deve ter permissões de gravação para ninguém. A permissão recomendada para a maioria das máquinas é de leitura/escrita para o usuário, e não acessíveis por outros.
  • ~/.shosts :: Este arquivo é utilizado exatamente como “.rhosts”, mas permite a autenticação host-based sem permitir login com rlogin/rsh.
  • ~/.ssh/ :: Este diretório é o local padrão para todas as configurações específicas do usuário e informações de autenticação. Não há nenhuma exigência geral para manter todo o conteúdo do diretório em segredo, mas as permissões recomendadas são de leitura /escrita/execução para o usuário, e não acessíveis por outros.
  • ~/.ssh/authorized_keys :: Lista as chaves públicas (RSA/DSA) que podem ser usadas para fazer login como este usuário. O formato deste arquivo é descrito na página do manual do “sshd(8)”. Este arquivo não é altamente sensível, mas as permissões recomendadas são de leitura/escrita para o usuário, e não acessíveis por outros.
  • ~/.ssh/config :: Este é o arquivo de configuração por usuário. O formato de arquivo e opções de configuração são descritas em “ssh_config(5)”. Devido ao potencial para o abuso, este arquivo deve ter permissões restritas: leitura/escrita para o usuário, e não acessíveis por outros. Ele pode ser de um grupo-gravável desde que o grupo em questão tenha apenas o utilizador.
  • ~/.ssh/environment :: Contém definições adicionais para variáveis de ambiente; veja em AMBIENTE, acima.
  • ~/.ssh/identity, ~/.ssh/id_dsa e ~/.ssh/id_rsa :: Contém a chave privada para autenticação. Esses arquivos contêm dados sensíveis e devem ser legíveis pelo usuário mas não acessíveis por outros (ler/escrever/executar). O SSH irá simplesmente ignorar um arquivo de chave privada se for acessível por outros. É possível especificar uma senha ao gerar a chave que será usada para criptografar a parte sensível deste arquivo utilizando 3DES.
  • ~/.ssh/identity.pub, ~/.ssh/id_dsa.pub e ~/.ssh/id_rsa.pub :: Contém a chave pública para autenticação. Esses arquivos não são sensíveis e podem (mas não precisam) ser lidos por qualquer pessoa.
  • ~/.ssh/known_hosts :: Contém uma lista de chaves host para todos os hosts do usuário conectados que ainda não estão na lista de todo o sistema de chaves host conhecidos. Veja sshd(8) para mais detalhes sobre o formato deste arquivo.
  • ~/.ssh/rc :: Comandos deste arquivo são executados por ssh quando o usuário faz login, pouco antes do shell do usuário (ou comando) é iniciado. Veja a página de manual do sshd(8) para mais informações.
  • /etc/hosts.equiv :: Este arquivo é para autentificação do host-based (veja acima). Ele só deve ser escrito pelo root.
  • /etc/ssh/shosts.equiv :: Este arquivo é utilizado da mesma maneira como o hosts.equiv, mas permite a autenticação host-based sem permitir login com rlogin/rsh.
  • /etc/ssh/ssh_config :: Arquivo de configuração Systemwide. O formato de arquivo e opções de configuração são descritas em ssh_config (5).
  • /etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key e /etc/ssh/ssh_host_rsa_key :: Estes três arquivos contêm as partes privadas das chaves host e são usados para a autentificação do host-based. Se a versão do protocolo 1 é usado, ssh deve ser setuid root, já que a chave do anfitrião é legível apenas pelo root. Para o protocolo versão 2, ssh usa ssh-keysign(8) para acessar as chaves host, eliminando a exigência do ssh ser setuid root quando o login é baseado em host de autenticação. Por padrão o ssh não é setuid root.
  • /etc/ssh/ssh_known_hosts :: Systemwide lista de chaves host conhecidas. Este arquivo deve ser preparado pelo administrador do sistema para conter as chaves host públicas de todas as máquinas da organização. Deve ser lido/visível por todos. Veja sshd (8) para mais detalhes sobre o formato deste arquivo.
  • /etc/ssh/sshrc :: Comandos deste arquivo são executados por ssh quando o usuário faz login, pouco antes que o shell do usuário (ou comando) é iniciado. Veja a página de manual do sshd (8) para mais informações.

Veja também

  • scp(1),sftp(1),ssh-add(1),ssh-agent(1),ssh-argv0(1),ssh-keygen(1), ssh-keyscan(1),ssh-vulnkey(1),tun(4),hosts.equiv(5),ssh_config(5), ssh-keysign(8),sshd(8)
  • The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, 2006.
  • The Secure Shell (SSH) Protocol Architecture, RFC 4251, 2006.
  • The Secure Shell (SSH) Authentication Protocol, RFC 4252, 2006.
  • The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, 2006.
  • The Secure Shell (SSH) Connection Protocol, RFC 4254, 2006.
  • Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255, 2006.
  • Generic Message Exchange Authentication for the Secure Shell Protocol (SSH), RFC 4256, 2006.
  • The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, 2006.
  • The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, 2006.
  • Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345, 2006.
  • Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, 2006.
  • The Secure Shell (SSH) Public Key File Format, RFC 4716, 2006.
  • A. Perrig and D. Song, Hash Visualization: a New Technique to improve Real-World Security, 1999, International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC ’99).

Jogos PS1 no emulador ePSXe – Sem lags em placas lentas

 Clusterweb, Leitura Recomendada, Linux  Comentários desativados em Jogos PS1 no emulador ePSXe – Sem lags em placas lentas
mar 082013
 

Requisitos e procedimentos

Quem diria que, pelo menos, os jogos de PlayStation 1 poderiam rodar em boas condições em placas de vídeo SiS e em algumas outras também.

Estamos carecas de saber que a placa de vídeo SiS 661/671 (e as outras também) têm desempenho baixo, bem diferente do Windows, onde pelo menos o driver para SiS 661/671 tem suporte à aceleração 2D e 3D.

Então jogos pesados e que exigem o vídeo em fullscreen no GNU/Linux com esses tipos de placas de vídeos estão fora de escolha, pois nestas placas não vai rolar nada de bom. (rsrs)

Mas não pense que basta ter qualquer placa de vídeo lenta que isto irá dar certo. Pelo menos no Windows, a placa de vídeo deve ter um desempenho razoável, pois os desenvolvedores de drivers preferem produzir os produtos para o sistema do tio Bill, e é por isso que o desempenho é bom nesse sistema operacional. O desempenho no GNU/Linux poderá ser alcançado também.

Mas fuçando em tudo, descobri que jogos de PS1 rodam liso, pelo menos na minha SiS, e estou trazendo este artigo para habilitar sua placa de vídeo para rodar os jogos de PS1, sem lag. 😀

Sendo que sua placa precisa ter, pelo menos, os requisitos mínimos para que o emulador ePSXe faça a sua parte sem problemas e com desempenho.

Os requisitos mínimos, são:

  • Processador: Pentium 200 MHz;
  • RAM: 256 MB;
  • Sistema operacional: GNU/Linux ou Windows;
  • CD-ROM: 16x ou mais rápido (opcional).

Bom, vamos começar.

Se você não tem ou não sabe configurar o ePSXe, veja a dica postada aqui no VOL por um user que não está mais entre nós:

Depois que o seu ePSXe está configuradinho e rodando os seus jogos (com lag), vamos ao segredo que vai deixar os jogos rodando liso, até em fullscreen em seu emulador.

O segredo é, nada mais nada menos, que um plugin de vídeo (ohhhh!!).

O plugin usa sistema/modo gráfico “Software”, foi por isso que os requisitos sobre placa de vídeo eu não pude determinar, pois o segredo de tudo isso é o plugin de vídeo para o emulador.

Procedimentos

Informações sobre o plugin:

Vamos baixar o plugin para o ePSXe:

Faça os procedimentos para aplicar o plugin ao emulador em seu terminal:

$ wget http://www.pbernert.com/gpupeopssoftx118.tar.gz
$ tar -vzxf gpupeopssoftx118.tar.gz
$ sudo cp libgpuPeopsSoftX.so.1.0.18 /opt/epsxe/plugins/
$ sudo cp gpuPeopsSoftX.cfg /opt/epsxe/cfg/

* Aviso: “/opt/epsxe/plugins/” é um exemplo do diretório onde o emulador está instalado, e este diretório foi baseado no diretório padrão do emulador instalado pelo pacote “epsxe” para o Arch Linux disponível no AUR.

Então você deve substituir este diretório pelo local onde o emulador está instalado.

Configuração

Agora vamos abrir o ePSXe (recomendo abrir pelo terminal):

$ sudo epsxe

Obs.: Você deve abrir com sudo, pois o diretório e as configurações são salvas em locais onde um usuário normal não pode manusear com todos os direitos, caso contrário, qualquer configuração será perdida ao encerrar.

Após abrir o emulador ePSXe, vamos às configurações:

  1. Vá em: Config → Vídeo
  2. Em: “Select Vídeo Plugin”, selecione: “P.E.Op.S. SoftX Driver 1.18”
  3. Clique em: “Configure”

Enfim, siga o exemplo:

-Resolution-
*Fullscreen mode: 320×200

Windowed mode: 320×200
Stretching mode: 0:Full size stretch
Dithering: 1:Game dependend

-Framerate-
Show FPS display on startup (opcional ativar)
*Use FPS limit
*Auto-detect FPS/Frame skipping limit
*Use Frame skipping
Framerate: 100.0 FPS

*Use SSSPSX Frame limit

NOTA: Onde houver “*” na frente do item acima, é porque você deve marcar/ativar a opção ou configuração.

Prontinho. Se você não conseguiu acompanhar a parte sobre como configurar o plugin, veja na figura abaixo o print do plugin já configurado: =D

Linux: Rodando jogos de PS1 sem lags em placas de vídeo lentas

Agora, meu amigo, seu equipamento será capaz de rodar todos os jogos compatíveis com o emulador.

Bom, isso que eu estou ensinando hoje é o essencial, mas há configurações extras que podem melhorar ainda mais.

Resumo LPI 102: Tópico 107 – Tarefas Administrativas

 Clusterweb, Leitura Recomendada  Comentários desativados em Resumo LPI 102: Tópico 107 – Tarefas Administrativas
mar 082013
 
107.1 – Administrar contas de usuários e grupos

Em mais um resumo de tópico para a prova LPI 102, venho percebendo a facilidade em estudar usando associação. Com comandos de modo geral, procure saber para que ele serve e o que significa.

Alguns são bem intuitivos, por exemplo, o passwd (password), lsusb (list usb), nc (netcat), chfn (change information). Outros, são mais complicados. Geralmente comandos com ch, tem algo a ver com change (alteração, mudança), ls com list (listar).

Estar atento e disposto a associar os nomes dos comandos facilitará e MUITO seu estudo. O mesmo vale para parâmetros. Leia, ao menos, a descrição nas páginas de manual e faça testes, simule situações, se você ainda não passa boa parte do dia de frente pra tela preta.

Contas de usuários

O comando adduser só pode executado pelo root. Cria usuários automaticamente, com parâmetros definidos no arquivo: /etc/adduser.conf

O comando useradd só pode ser executado como root. Cria usuário setando manualmente os parâmetros desejados. Indicado para uso em scripts. Principais parâmetros:

  • -c (comment) :: Adiciona descrição à conta, geralmente nome completo do usuário;
  • -d (home dir) :: Define o caminho para o diretório pessoal do usuário;
  • -g (Group ID) :: Define o grupo principal – GID;
  • -G (groups) :: Define grupos secundários;
  • -u (User ID) :: Define o ID – UID;
  • -s (shell) :: Define o shell padrão;
  • -p (passaword) :: Define a senha;
  • -e (expire date) :: Define a data de expiração da conta;
  • -k (skel dir) :: Define se a conta do usuário usará a estrutura com base no /etc/skel;
  • -m (create home) :: Cria o diretório pessoal, se não existir.

O diretório /etc/skel/ serve como modelo na criação dos diretórios pessoais. Skel = Skeleton (esqueleto).

O comando passwd altera a senha de usuários. Sintaxe:

# passwd <usuário>
$ passwd

Ou seja, como root, é possível alterar a senha de qualquer usuário. Como usuário comum, somente é possível alterar a própria senha.

O comando chfn (change information) altera o campo descrição da conta de um usuário. Não precisa ser root.

O comando chsh (change shell) altera o shell padrão do usuário. Não precisa ser root.

O comando userdel exclui uma conta de usuário. Parâmetro principal: “-r” (remove) – remove o diretório pessoal.

O arquivo /etc/passwd armazena informações de contas de usuários e pode ser lido por qualquer usuário (permissão: rw-r–r–). Utiliza como separador de campos o “:” (2 pontos).

Observe a estrutura:

root:x:0:0::/root:/bin/bash

Enumerando os campos:

  1. Login do usuário;
  2. Senha. Se for “x”, a senha encontra-se criptografada no arquivo /etc/shadow;
  3. UID – ID do usuário;
  4. GID – ID do grupo principal do usuário;
  5. Descrição do usuário;
  6. Caminho do diretório pessoal;
  7. Shell padrão do usuário.

O comando vipw usa o editor padrão do sistema (Vi) para alterar o arquivo /etc/passwd, bloqueando-o contra edições concorrentes.

Parâmetro principal: -s (shadow) – edita o arquivo /etc/shadow, usando o modelo de bloqueio.

No arquivo /etc/shadow estão as senhas criptografadas dos usuários e mais algumas configurações. Não está visível para todos usuários, por medida de segurança (permissão: rw-r—–). Seu separador de campos também é o “:”.

Estrutura:

root:<senha>:15516:0:99999:7:::

Enumerando os campos:

  1. Login do usuário, que deve corresponder ao do /etc/passwd;
  2. Guarda a senha criptografada do usuário;
  3. Número de dias desde que a senha foi alterada pela última vez. Contando desde 01/01/1970.
  4. Número mínimo de dias que o usuário pode permanecer sem alterar a senha. Zero significa que não tem este prazo mínimo;
  5. Número máximo de dias que o usuário tem para trocar a senha;
  6. Número de dias que o usuário será avisado até que a senha expire;
  7. Número de dias a partir da expiração da senha até que a conta seja bloqueada;
  8. Mostra o número de dias que a conta encontra-se bloqueada. Contando desde 01/01/1970;
  9. Campo reservado.

O comando pwconv altera o armazenamento das senhas do arquivo /etc/passwd para o /etc/shadow.

O comando pwunconv altera o armazenamento das senhas do arquivo /etc/shadow para o /etc/passwd.

O comando chage altera informações referentes à validade de senhas de usuário. Parâmetros principais:

  • -m (minimum days) :: Número de dias mínimos para o usuário poder alterar sua senha;
  • -M (max days) :: Número máximo de dias para troca da senha;
  • -d (last days) :: Número de dias desde que a senha foi alterada, contando desde 01/01/1970;
  • -E (expire date) :: Data de expiração da conta do usuário;
  • -I (inactive) :: Número de dias a partir da expiração da senha até que a senha seja bloqueada;
  • -W (warn days) :: Número de dias para avisar o usuário que a senha deve ser trocada.

O comando usermod modifica contas de usuários. Parâmetros principais:

  • -c (comment) :: Altera o comentário da conta;
  • -d (diretory) :: Altera o caminho do diretório pessoal;
  • -m (move) :: Move o diretório pessoal do usuário para um novo local;
  • -g (group) :: Altera o grupo principal;
  • -G (groups) :: Adiciona o usuário a outros grupos;
  • -l (login) :: Altera o nome de login;
  • -p (password) :: Altera a senha;
  • -u (UID) :: Altera o ID do usuário;
  • -s (shell) :: Altera o shell padrão;
  • -e (expire date) :: Altera a data de expiração da conta do usuário. dd/mm/aaaa;
  • -f (??) :: Dias depois da expiração da senha que a conta será bloqueada. O -1 cancela essa função;
  • -L (lock) :: Bloqueia o usuário. Insere o “!” no campo da senha criptografada;
  • -U (unlock) :: Desbloqueia o usuário. Retira o “!”.

Administrando grupos de usuários

O comando groupadd cria um grupo de usuário.

Principal parâmetro: -g (GID) – Especifica um ID para o grupo.

O comando groupdel exclui um grupo de usuário.

O comando gpasswd insere e exclui usuários de grupos e realiza algumas modificações relacionadas às senhas. Este comando usado sem parâmetro cria uma senha para um grupo.

Principais parâmetros:

  • -r (remove) :: Remove a senha do grupo;
  • -a (add) :: Adiciona usuário ao grupo;
  • -d (delete) :: Deleta usuário do grupo;
  • -A (admin) :: Torna usuário administrador do grupo.

O comando groups mostra o grupo que o usuário pertence. Usado sem argumentos, mostra os grupos do usuário atual.

O comando id mostra os grupos do usuário e informações de UID e GID.

O comando newgrp altera o grupo principal do usuário. Caso ele não pertença, é adicionado automaticamente.

O arquivo /etc/group armazena informações dos grupos. Possui permissão: rw-r–r–

Estrutura:

adm:x:5012:pedro,joao

Enumerando os campos:

  1. Nome do grupo;
  2. Senha criptografada do grupo. O “x” significa que a senha está no arquivo /etc/gshadow;
  3. ID do grupo. GID;
  4. Usuários pertencentes ao grupo, separados por “,”.

O comando vigr edita o arquivo /etc/group, evitando gravações concorrentes.

Principal parâmetro: -s (shadow) – Edita o arquivo /etc/gshadow.

O arquivo /etc/gshadow armazena informações de senhas com criptografia. Possui permissão: rw–r—-

Estrutura:

adm:*::pedro

Enumerando:

  1. Nome do grupo, correspondente ao /etc/group;
  2. Senha criptografada. O “*” significa que o grupo não tem senha;
  3. Usuário administrador do grupo;
  4. Usuário pertencentes ao grupo, como no /etc/group.

O comando grpconv converte o armazenamento das senhas dos grupos, do arquivo /etc/group para o /etc/gshadow.

O comando grpunconv faz o inverso do comando grpconv.

O comando groupmod realiza algumas modificações nos grupos. Principais parâmetros:

  • -g (GID) :: Altera o GID;
  • -n (name) :: Altera o nome do grupo.
107.2 – Automatizar e agendar tarefas administrativas

O comando at é usado para agendar a execução de um comando/script apenas uma vez.

Sintaxe:

# at <quando> <comando>

O argumento “<quando>” pode ser:

  • now :: Execução instantânea;
  • midnight :: Executa à meia noite;
  • Mais opções podem ser vistas no arquivo: /usr/share//doc/at/timespec

Usuários comuns podem usar o “at”, se constarem no arquivo /etc/at.allow. Se este arquivo não existir, o arquivo /etc/at.deny será lido e só não poderá usar o “at” quem constar nele. Se nenhum dos arquivo existirem, só o root poderá usar o “at”.

Parâmetros e variações:

  • -l (parâmetro – list) :: Este parâmetro lista os agendamentos em espera;
  • atq (comando) :: Também lista agendamentos em espera;
  • atrm (comando) :: Exclui agendamentos em espera.

O cron é um daemon para agendamento de tarefas em determinados intervalos de tempo. A cada minuto este daemon verifica as tabelas de agendamento, chamadas crontabs, e executa as tarefas que estiverem configuradas.

Principal crontab (ou tabela de agendamento):

/etc/crontab :: Este é o crontab do sistema. Existem também um crontab para cada usuário.

O comando crontab é para usuários específicos, ao invés do arquivo geral do sistema. Usamos o comando comando crontab, que editará a tabela de agendamento do respectivo usuário.

Principais parâmetros:

  • -l (list) :: Lista as tarefas agendadas;
  • -e (edit) :: Edita o crontab do usuário;
  • -r (remove) :: Remove o crontab do usuário.

Sintaxe:

# crontab <parâmetro> <usuário>

Configurando uma tabela de agendamento (ou crontab). O separador pode ser:

0-59 0-23 0-31 1-12 0-6 <comando>

Enumerando:

  1. Variação dos minutos;
  2. Das horas;
  3. Dos dias;
  4. Dos meses;
  5. Dos dias da semana (0 é domingo e 6 é sábado);
  6. Comando a ser executado.

Exemplo real de utilização:

* */4 * 5,6 1-5   /root/script.sh

Nesta linha, que poderia estar no arquivo /etc/crontab, por exemplo, executaria o arquivo “script.sh” a cada quatro horas, nos meses de maio e junho de segunda à quinta-feira.

Explicando os caracteres utilizados no exemplo:

  • * → Nada a fazer;
  • – → Determina um período;
  • / → Determina um espaço de tempo. Um marcapasso;
  • , → Determina tempos específicos. Serve para intercalar o tempo, quebrar uma sequência.

Diretórios auxiliares:

  • /etc/cron.hourly/ → Executa os arquivos dentro dele de a cada hora;
  • /etc/cron.daily/ → Executa os arquivos todos os dias;
  • /etc/cron.monthly/ → Executa todos os meses;
  • /etc/cron.weekly/ → Executa toda semana.

Estes diretórios são usados quando não é necessário especificar a hora para execução de uma tarefa.

Arquivos para controle de utilização do contrab:

  • /etc/cron.allow → Se existir, só os usuário especificados nele poderão agendar tarefas;
  • /etc/cron.deny → Se existir, os usuários que forem especificados nele não poderão agendar tarefas.

Obs.: Se os dois não existirem, todos os usuários poderão agendar tarefas.
107.3 – Localização e internacionalização

Fuso horário:

O comando tzselect ajusta o fuso horário do sistema. Após configurado, é criado o arquivo /etc/timezone.

O arquivo /etc/localtime guarda informações sobre o horário de verão. As opções de configuração estão no diretório /usr/share/zoneinfo.

O comando locale exibe as variáveis de ambiente que contém informações de idioma e padrão de codificação do sistema.

A variável LANG é uma variável global usada pela maioria dos programas, como referência para definição do idioma padrão. O conteúdo dessa variável obedece o formato idioma_PAIS.CODIFICAÇÃO.

Exemplo:

$ echo $LANG
pt_BR.UTF-8

Neste caso, significa:

  • pt :: Idioma português;
  • BR :: País, Brasil;
  • UTF-8 :: Codificação Unicode, padrão do GNU/Linux.

Obs.: Em scripts é recomendável setar a variável LANG dessa forma: LANG=C. Evitando assim resultados diferentes quando o script é executado em sistemas diferentes, com configurações diferentes.

Outras variáveis de ambiente são importantes para a correta configuração de programas. São elas:

  • LC_COLLATE :: Define ordenação alfabética;
  • LC_CTYPE :: Define o tratamento de caracteres;
  • LC_MESSAGES :: Definição do idioma em avisos emitidos por programas;
  • LC_MONETARY :: Define unidade monetária e formato da moeda;
  • LC_NUMERIC :: Define o formato numérico de valores não monetários;
  • LC_TIME ::- Define o formato de data e hora;
  • LC_PAPER :: Define o tamanho padrão do papel;
  • LC_ALL :: Sobrepõe todas as demais variáveis;