Novo Livro: Serviços de Redes em Servidores Linux

Olá Pessoal,

É com muita satisfação que compartilho com vocês leitores a informação de que a partir de hoje (informação atualizada em 06/10) meu novo livro intitulado Serviços de Redes em Servidores Linux está disponível em formatos impresso e digital (eBook). A versão digital já pode ser adquirida na loja eletrônica da Amazon, Apple Store, Google Play e Livraria Cultura. O livro físico está sendo distribuído para as melhores livrarias de todo o Brasil.

Certamente, este livro será uma importante ferramenta de apoio e guia de consulta rápida para estudantes e, principalmente, para profissionais responsáveis pela administração de servidores Debian GNU/Linux e Ubuntu Server, duas distribuições de Linux dentre as mais tradicionais no mercado de servidores. O livro traz roteiros com o passo a passo detalhado de como instalar e configurar os principais serviços empregados em redes de computadores mediante o uso de servidores Linux baseados no Debian GNU/Linux e Ubuntu Server, a destacar:

• Configuração de Redes IPv4 e IPv6
• Acesso Terminal Remoto via SSH (OpenSSH)
• Roteamento Estático IPv4 e IPv6
• Protocolos de Roteamento Dinâmico (Quagga)
• Servidor DHCP em IPv4 e IPv6 (ISC-DHCP)
• Servidor DNS (Bind9)
• Servidor Web (Apache2)
• Servidor de Arquivos em Ambientes Unix (NFS)
• Servidor de Arquivos em Ambientes Linux/Windows (Samba)
• Controlador de Domínio (Samba)
• Firewall (iptables)
• Servidor Proxy Web (Squid)
• VPN Site-to-Site (strongSwan)

Na página da Novatec Editora, disponível no link abaixo, é possível obter mais informações, inclusive com opções de compra do livro nos formatos impresso e digital.

https://novatec.com.br/livros/servicos-de-redes-em-servidores-linux

Samuel.

Lançamento do Emulador GNS3 v2.0.0

Olá Pessoal.

Escrevo para informá-los que agora há pouco atualizei o repositório do blog, na aba "Downloads & Laboratórios", com a última versão do GNS3 2.0.0 para Micosoft Windows (64 bits) e Mac OS X. Os instaladores têm aproximadamente 50MB e estão disponíveis apenas para plataformas 64 bits, sendo que uma das melhorias da nova versão é que os projetos abertos são salvos automaticamente. 

Já para os usuários do Linux, especificamente do Ubuntu e Debian, o procedimento de instalação segue sendo possível através dos repositórios, podendo ser facilmente instalado/atualizado através de um PPA (Personal Package Archive) no Launchpad, bastando o usuário utilizar as seguintes linhas de comando:

sudo add-apt-repository ppa:gns3/ppa

sudo apt-get update

sudo apt-get install gns3-gui

Aqueles interessados em instalar o GNS3 em outras distribuições Linux podem consultar a documentação oficial disponibilizada na plataforma GNS3 Jungle (www.gns3.com). Façam seus testes...

Samuel.

Controlador de Domínio do SAMBA 4 no Debian GNU/Linux

Olá Pessoal,

Em outro artigo intitulado "Configuração Básica do SAMBA em Servidores Linux" o leitor passou pela experiência básica de como fazer o simples compartilhamento de diretórios e arquivos através do SAMBA para integrar ambientes heterogêneos com máquinas Linux e Windows. No entanto, é importante destacar que o SAMBA 4 vai muito além do simples compartilhamento e permite que o servidor Linux assuma o papel de controlador de domínio (DC). Assim é possível ingressar máquinas Windows no serviço de diretório do servidor Linux para que a gerência dos objetos de um domínio (computadores, contas de usuários, políticas, etc) seja centralizada sem a necessidade do MS Windows Server, o que implica em economia na licença do sistema operacional do servidor e também da quantidade de clientes da rede (CAL).

O objetivo deste artigo é listar as etapas necessárias para instalar o SAMBA 4 (e seus complementos) para transformar um servidor Debian GNU/Linux no controlador do domínio denominado AULA.LOCAL. Nesse exemplo assumiremos que nosso controlador de domínio será configurado com o IP 192.168.221.1/24. Uma etapa preliminar é definir estaticamente no arquivo /etc/hosts o mapeamento do nome do servidor que posteriormente será configurado como controlador de domínio. Nessa etapa criaremos um mapeamento estático (NOME<>IP) em que o nome da máquina já será composto com o sufixo do domínio (FQDN) que será utilizado posteriormente. Por causa desse mapeamento o SAMBA irá sugerir o nome de domínio AULA.LOCAL durante sua instalação. 

###--- em /etc/hosts -------------------------

127.0.0.1       localhost

192.168.221.1   samba-dc   samba-dc.aula.local
###--- fim do arquivo ------------------------

1) Instalação do Servidor SAMBA DC

Assim como nos artigos anteriores, estou considerando que o servidor está instalado com a distribuição Debian GNU/Linux (ou seus derivados, como o Ubuntu). A primeira etapa consiste na instalação do pacote denominado samba para que o Linux possa ser posteriormente configurado como controlador de domínio. Também é necessário instalar vários pacotes com outros serviços, a exemplo do DNS (winbind), do Kerberos (krb5-user), etc. Apesar de ser bastante coisa, essa tarefa é simples e rápida através do APT:

root@samba-dc:/# apt-get update

root@samba-dc:/# apt-get install samba smbclient ntp krb5-user winbind ldap-utils acl attr

Durante a instalação irá aparecer um diálogo (modo texto) solicitando 3 informações:

- Nome do Domínio                               : AULA.LOCAL

- Endereço do Servidor Kerberos de Autenticação : 127.0.0.1

- Endereço do Servidor Administrativo           : 127.0.0.1

2) Configuração do NTP p/ Sincronização do Relógio das Máquinas

A próxima etapa é fazer alguns ajustes no serviço NTP responsável pela sincronização do relógio da máquina que será responsável por sincronizar os relógios de todas as demais máquinas do domínio. Depois de criado o diretório ntp_signd com as devidas permissões, é necessário adicionar algumas linhas ao final do arquivo de configuração localizado em /etc/ntp.conf.

root@samba-dc:/# install -d /var/lib/samba/ntp_signd/

root@samba-dc:/# chown root:ntp /var/lib/samba/ntp_signd

root@samba-dc:/# chmod 750 /var/lib/samba/ntp_signd/

###--- em /etc/ntp.conf ------------------------

(...) Conteúdo Omitido

### Adicionar Configuracoes Abaixo p/ SAMBA 4 DC

ntpsigndsocket /var/lib/samba/ntp_signd/

restrict default mssntp

disable monitor
###--- fim do arquivo --------------------------

Depois desses ajustes, basta reiniciar o serviço NTP:

root@samba-dc:/# service ntp restart

O status do serviço NTP pode ser verificado através dos seguintes comandos:

root@samba-dc:/# service ntp status

root@samba-dc:/# ntpq -p

3) Parada de Serviços em Execução

Antes de fazer a configuração do domínio propriamente dito através do processo de provisionamento do SAMBA, é necessário parar serviços que são automaticamente executados logo depois da instalação dos pacotes, além de "remover" o arquivo original de configuração do SAMBA (/etc/samba/smb.conf):

root@samba-dc:/# service smbd stop

root@samba-dc:/# service nmbd stop

root@samba-dc:/# service winbind stop

root@samba-dc:/# mv /etc/samba/smb.conf /etc/samba/smb.conf.bak

4) Provisionamento do Domínio

Uma das etapas mais importantes é o provisionamento do domínio em que serão utilizadas ferramentas automatizadas do próprio SAMBA para preparar nosso servidor como controlador do domínio AULA.LOCAL. A principal ferramenta é o comando samba-tool que serve como frontend responsável por manipular o OpenLDAP (backend), simplificando muito a tarefa de configuração. 

root@samba-dc:/# samba-tool domain provision --use-rfc2307 --interactive

Ao digitar o comandoo sistema irá indagá-lo e sugerir as seguintes configurações que podem ser aceitas através da tecla <ENTER>:

- Realm                       [AULA.LOCAL] 

- Domain                      [AULA]

- Server Role                 [DC]

- DNS Backend                 [SAMBA_INTERNAL]

- DNS Forwarder IP Address    (IP do DNS da REDE)
- Administrator Password      (SENHA FORTE)

Obs.: Os parâmetros trazidos nas chaves [] são sugeridos pelo samba-tool e podem ser aceitos. O servidor DNS integrado ao controlador de domínio será responsável pelos mapeamentos dos nomes na rede interna, de forma que todas as máquinas Windows a serem ingressadas no domínio devem ser configuradas para apontar seu DNS primário para o IP do servidor SAMBA (192.168.221.1). Caso exista(m) outro(s) servidor(es) DNS na rede (por ex. BIND), responsável por exemplo pelo mapeamento de nomes externos, pode ser feito o apontamento através do DNS Forwarder.

5) Ajustes Finais

É hora de fixar as configurações de DNS do servidor no arquivo /etc/resolv.conf e aplicar a característica de imutabilidade (+i) no mesmo para que seu conteúdo não seja mais dinamicamente atualizado. Também vamos copiar o template do arquivo de configuração do Kerberos que vem com o pacote samba (/var/lib/samba/private/krb5-conf) para o diretório /etc para que a autenticação no domínio possa funcionar. Por fim, vamos reiniciar o serviço do SAMBA como controlador de domínio.

###--- em /etc/resolv.conf ---

search aula.local

nameserver 192.168.221.1

###--- fim do arquivo --------

root@samba-dc:/# chattr +i /etc/resolv.conf

root@samba-dc:/# cp /var/lib/samba/private/krb5.conf /etc

root@samba-dc:/# service samba-ad-dc restart

6) Verificação

A primeira maneira de verificar se o SAMBA está em execução é:

root@samba-dc:/# service samba-ad-dc status

Active: active (running) since (...) 

Para fazer uma verificação mais apurada, vale testar a resolução de nomes internos de alguns registros automaticamente criados pelo controlador de domínio, além de testar a resolução de nomes externos:

root@samba-dc:/# host -t A aula.local

aula.local has address 192.168.221.1

root@samba-dc:/# host -t SRV _kerberos._udp.aula.local

_kerberos._udp.aula.local has SRV record 0 100 88 samba-dc.aula.local

root@samba-dc:/# host -t SRV _ldap._tcp.aula.local

_kerberos._tcp.aula.local has SRV record 0 100 88 samba-dc.aula.local

root@samba-dc:/# host www.debian.org

www.debian.org has address 200.17.202.197
www.debian.org has IPv6 address 2801:82:80ff:8009:e61f:13ff:fe63:8388

Finalmente vamos testar a autenticação do Kerberos:

root@samba-dc:/# kinit administrator@AULA.LOCAL
Password for administrator@AULA.LOCAL: <Senha do Administrador do Domínio>
Warning: Your password will expire in 41 days on (...)

root@samba-dc:/# klist
(...) Informações de Validade do Ticket (Kerberos)

7) Administração do Domínio

Pronto, o servidor SAMBA já está em operação como controlador do domínio AULA.LOCAL. A partir deste ponto o domínio pode ser administrador via interface de linha de comando (CLI) através da ferramenta samba-tool. São várias as opções para administração do domínio via samba-tool, por isso é recomendada a leitura do manual da ferramenta (man samba-tool). Abaixo trago uma breve relação de alguns dos comandos mais comuns:

samba-tool user list                  ### exibe todos os usuários do domínio

samba-tool user add <NOME>            ### adiciona um novo usuário

samba-tool user del <NOME>            ### remove um usuário existente

samba-tool user enable <NOME>         ### habilita um usuário desabilitado

samba-tool user disable <NOME>        ### desabilita uma conta de usuário

Caso algum usuário esqueça sua senha, o coomando abaixo pode ser utilizado para resetá-la de forma que o usuário seja obrigado a alterá-la no próximo login:

samba-tool user NOME --newpassword=SENHA --must-change-at-next-login  

Outra opção bastante atrativa é utilizar a ferramenta RSAT (Remote Server Administration Tools) que pode ser baixada gratuitamente na página da Microsoft e instalada em qualquer máquina executando o Windows (versões 7, 8 ou 10). A vantagem dessa abordagem é que a administração do domínio é feita pela mesma interface gráfica das tradicionais Ferramentas Administrativas do Windows Server, aproveitando todo o conhecimento do administrador. O RSAT pode ser baixado através dos links abaixo:

- Windows 7: https://www.microsoft.com/pt-br/download/details.aspx?id=7887 
- Windows 8: https://www.microsoft.com/pt-br/download/details.aspx?id=28972
- Windows X: https://www.microsoft.com/pt-BR/download/details.aspx?id=45520

Obs.: Depois de baixado o RSAT deve ser instalado no Windows e manualmente adicionado como recurso extra. Nos links oficiais da Microsoft onde o RSAT pode ser baixado o leitor encontra as instruções para instalação da ferramenta. 

Façam seus testes...

Samuel.

Espelhamento de Discos em Servidores Debian GNU/Linux

Olá Pessoal,

Uma prática bastante comum em servidores é a combinação de múltiplos discos físicos em arranjos lógicos denominados RAID (Redundant Array of Independent Discs), principalmente para fins de disponibilidade dos dados aramazenados em mais de um disco e também para fins de desempenho, uma vez que dados armazenados em múltiplos discos implicam em maior velocidade de leitura. 

Há diversas modalidades de RAID, sendo a mais simples delas o RAID-1 que faz o espelhamento de discos, ou seja, mantém em um segundo disco físico uma cópia exata do primeiro disco físico. Em caso de falha de um dos discos, o conteúdo continua disponível através do outro disco e o administrador pode providenciar a troca do disco defeituoso para que haja sincronização total do conteúdo no novo disco.

O RAID normalmente é implementado através de hardware, sendo gerenciado por uma controladora de discos que pode ser configurada através da BIOS (ou UEFI) da máquina antes mesmo do início de instalação do sistema operacional. Essa é a opção mais recomendada porque apresenta melhor desempenho, no entanto só está disponível em hardware particularmente desenvolvido para servidores. Como o Linux se trata de um sistema operacional aberto e gratuito, ele acaba sendo a opção natural em ambientes menores que não têm recursos para aquisição de hardware adequado para seus servidores. Nesses casos, frequentemente são utilizados computadores tradicionais que não possuem hardware apropriado com uma controladora que suporte a implementação de RAID na BIOS/UEFI.

Apesar dessa limitação de equipamento, a boa notícia é que também existe a opção de configurar o RAID por software através dos sistemas operacionais modernos, ainda que o desempenho seja pior que a solução profissional implementada por hardware. Especificamente no caso do Debian GNU/Linux, a configuração de RAID pode ser facilmente implementada durante o próprio processo de instalação do servidor, desde que a máquina tenha pelo menos dois discos físicos.

A configuração de RAID-1 na instalação do Debian consiste basicamente em criar partições idênticas nos dois discos físicos e em marcá-las com o rótulo "physical volume for RAID", ao invés de escolher um sistema de arquivos (figura 1). Depois disso é possível acessar a opção "Configure Software RAID" na própria ferramenta de particionamento do Debian e selecionar as duplas partições que serão agrupadas em RAID-1. Ao terminar de criar os agrupamentos, será possível observar o(s) novo(s) disco(s) lógico(s) do RAID na tabela de partições, onde o administrador deverá fazer a indicação do sistema de arquivos e dos pontos de montagem (figura 2).

Figura 1. Indicação de RAID em 2 Discos Físicos (Antes)

Figura 2. Particionamento de Disco Lógico RAID-1 (Depois)

A implementação do RAID-1 na instalação do Debian GNU/Linux é bastante simples, mas como lidar com o sistema operacional em caso de falha de um dos discos? Como fazer a inserção do novo disco no arranjo lógico e sincronizar os dados em ambos os discos? O objetivo desse artigo é listar as ações necessárias para recompor o RAID em caso de falha de um disco. 

Consideremos um servidor que possui dois HDs (/dev/sda e /dev/sdb) arranjados em RAID-1, cada um deles contendo 3 partições com capacidade de armazenamento apenas simbólica conforme apresentado nas figuras acima. Abaixo trago novamente o esquemático das partições:

/dev/sda1 > +/- 0.6 GB (SWAP)

/dev/sda2 > +/- 7.0 GB (/)

/dev/sda3 > +/- 1.0 GB (/home)

/dev/sdb1 > +/- 0.6 GB (SWAP)

/dev/sdb2 > +/- 7.0 GB (/)

/dev/sdb3 > +/- 1.0 GB (/home)

O RAID-1 de ambos os HDs foi configurado durante o processo de instalação do servidor Linux Debian, através da ferramenta de partição do próprio instalador (na opção Configure Software RAID), dando origem aos seguintes arranjos lógicos do tipo multi-disk (/dev/mdX):

/dev/md0 = /dev/sda1 + /dev/sdb1 (SWAP)

/dev/md1 = /dev/sda2 + /dev/sdb2 (/)

/dev/md2 = /dev/sda3 + /dev/sdb3 (/home)

Enquanto os discos estão operando normalmente, o arranjo lógico dos discos físicos em RAID-1 será responsável por realizar o espelhamento de todo o conteúdo armazenado no primeiro disco também no segundo disco, garantindo que sempre exista uma cópia de segurança dos dados. Caso haja pane em qualquer um dos discos, será necessário repor fisicamente o HD defeituoso e inserí-lo manualmente no arranjo lógico do RAID-1 para que todo o conteúdo do disco em operação possa ser sincronizado novamente no novo HD. 

Por exemplo, em caso de pane no segundo HD (/dev/sdb) será necessário:

1) Reparticionar o novo HD (/dev/sdb) com o mesmo esquema do disco em operação (/dev/sda)

root@Linux:/# sfdisk -d /dev/sda | sfdisk /dev/sdb

Feito isso, é sempre prudente verificar se o novo HD possui as mesmas partições do original:

root@Linux:/# fdisk -l /dev/sda

root@Linux:/# fdisk -l /dev/sdb

2) Adicionar as partições do novo HD (/dev/sdX#) ao RAID (/dev/mdX):

root@Linux:/# mdadm --manage /dev/md0 --add /dev/sdb1 

root@Linux:/# mdadm --manage /dev/md1 --add /dev/sdb2

root@Linux:/# mdadm --manage /dev/md2 --add /dev/sdb3

Feito isso, é possível verificar que o RAID será ressincronizado (espelhamento dos discos), de forma que o novo HD seja preenchido com uma cópia exata do conteúdo armazenado no HD original:

root@Linux:/# cat /proc/mdstat

Personalities : [raid1]
md2  :  active raid1 sda3[0] sdb3[1]
        965056 blocks super 1.2 [2/2] [UU]

md1  :  active raid1 sda2[0] sdb2[1]
        6832128 blocks super 1.2 [2/2] [UU]

md0  :  active (auto-read-only) raid 1 sda1[0] sdb1[1]
        584128 blocks super 1.2 [2/2] [UU]

A saída exibe o status de cada arranjo lógico do tipo multi-disk, sendo que o conteúdo dos colchetes destacados em amarelo exibem o status individual de cada um dos discos físicos. Por exemplo, a saída [UU] indica que ambos os HDs estão em operação, enquanto que a saída [U_] indicaria que o segundo disco físico não está em operação. 

Façam seus testes...

Samuel. 

Instalação do Banco de Dados Firebird em Servidores Linux

Olá Pessoal,

O objetivo deste artigo é listar a simples instalação e configuração do Firebird em Servidores Linux. O Firebird é um popular Banco de Dados derivado do código do Borland InterBase 6.0. Trata-se de uma ferramenta open-source e gratuita que está disponível para as mais diversas plataformas, seja Linux, Windows, Mac OS, FreeBSD ou Solaris. Como ele possui código aberto e não tem licença, é possível utilizá-lo em qualquer tipo de aplicação sem pagar nada por isso, mesmo em aplicações comerciais. A ferramenta é considerada madura porque sua tecnologia de base tem mais de 20 anos. 

Assim como nos artigos anteriores que escrevi sobre Linux, estou considerando que o servidor está devidamente instalado com a distribuição Debian GNU/Linux (ou seus derivados, como o Ubuntu). A primeira etapa consiste na instalação do pacote denominado firebird2.5-superclassic para que o Linux possa ser posteriormente configurado como servidor de banco de dados para aplicações clientes. Essa tarefa é simples e rápida através do APT:

root@Linux:/# apt-get update

root@Linux:/# apt-get install firebird2.5-superclassic

Obs.: O Firebird está disponível nas arquiteturas SuperClassic (firebird2.5-superclassic) e Classic (firebird2.5-classic). Vamos utilizar a arquitetura SuperClassic porque ela é mais indicada para uso em máquinas SMP (múltiplos núcleos de processamento). 

Durante a instalação do Firebird será aberto um diálogo para definir uma nova senha para o usuário padrão SYSDBA, sendo que frequentemente essa senha é masterkey. Essa senha pode ser redefinida a qualquer momento através do comando abaixo:

root@Linux:/# dpkg-reconfigure firebird2.5-superclassic

Feito isso, o Firebird já deve estar devidamente instalado e em execução no servidor, embora ainda não esteja permitindo acessos remotos através da rede. Para verificar se o serviço está em execução, basta utilizar o comando abaixo. Caso o administrador queira parar ou iniciar o serviço manualmente, esse mesmo comando pode ser utilizado alterando o parâmetro status por start (iniciar) ou stop (parar).

root@Linux:/# service firebird2.5-superclassic status

Apenas a título de observação, outra forma de verificar se o serviço está no ar é localizar manualmente os processos em execução no servidor, particularmente observando os processos denominados fb_smp_server e fbguard. O processo fbguard é um monitorador que protege a execução do servidor (fb_smp_server), de forma que o guardião automaticamente executa uma nova instância do processo servidor em caso de falha. 

root@Linux:/# ps aux | grep fb

(...) Exemplo de Saída do Comando

firebird  1064  (...) /usr/sbin/fbguard (...)

firebird  1065  (...) /usr/sbin/fb_smp_server

root      1226  (...) tty1 (...) grep fb

Depois de instalado, o arquivo de configuração do Firebird fica localizado em /etc/firebird/2.5/firebird.conf, sendo bem documentado e organizado em diferentes seções para facilitar sua configuração. Por padrão o servidor Firebird somente permite acesso a partir da máquina local (localhost) e é executado na porta 3050/TCP. Para permitir o acesso remoto ao servidor através de outras máquinas na rede, é necessário localizar e comentar a seguinte linha no arquivo de configuração do firebird:

###--- em /etc/firebird/2.5/firebird.conf

#RemoteBindAddress = localhost

Obs.: O acesso através da rede não irá funcionar se existir algum firewall no servidor ou mesmo no meio do caminho que esteja bloqueando comunicação na porta 3050/TCP. 

Uma vez que o Firebird esteja devidamente instalado e em execução, é possível criar novas bases de dados ou mesmo instalar o pacote com exemplos para testar a conexão remota. Através do comando abaixo utilizaremos o APT para instalar o pacote com exemplos prontos do Firebird. Na sequência podemos acessar o diretório /usr/share/doc/firebird2.5-examples/examples/empbuild para descompactar o banco de exemplo denominado employee.fdb.gz. Depois de descomprimir o banco de exemplo é necessário alterar o proprietário para firebird:firebird e, por fim, vamos mover o arquivo para o diretório /var/lib/firebird/2.5/data/ onde normalmente ficam armazenadas as bases de dados do firebird em servidores Linux. 

root@Linux:/# apt-get install firebird2.5-examples firebird2.5-dev 

root@Linux:/(...)# cd /usr/share/doc/firebird2.5-examples/examples/empbuild/

root@Linux:/(...)# gunzip employee.fdb.gz

root@Linux:/(...)# chown firebird.firebird employee.fdb

root@Linux:/(...)# mv employee.fdb /var/lib/firebird/2.5/data/

Agora, além do servidor instalado e em execução, temos também um banco de dados (.fdb) localmente armazenado no servidor que pode ser acessado remotamente. Para testar se o banco de dados está funcionando através da rede, em qualquer estação cliente é possível instalar o gerenciador gráfico FlameRobin (http://www.flamerobin.org/). Seguindo o mesmo espírito do próprio Firebird, o FlameRobin é uma ferramenta open-source e gratuita, bastante leve e disponível para as mais diversas plataformas, seja Linux, Windows, Mac OS, FreeBSD ou Solaris. 

Façam seus testes...

Samuel.

Instalação do Cisco WebEx no Linux Ubuntu 16.04

Olá Pessoal.

O WebEx é uma poderosa ferramenta desenvolvida pela Cisco para realização de reuniões através da Internet em tempo real. O WebEx combina compartilhamento da área de trabalho (desktop sharing), compartilhamento de arquivos, compartilhamento de quadros brancos, conferência via telepresença, conferência via rede telefônica para permitir a participação na reunião através de um telefone convencional, entre vários outros recursos bastante úteis. Esses recursos combinados permitem aos apresentadores e participantes fazerem quase tudo o que se pode fazer pessoalmente. 

Sua instalação e configuração no Mac OS e no Windows é bastante simples e intuitiva, assim como em dispositivos móveis Android e IOS. No entanto, esse mesmo procedimento no Linux é mais complicado porque infelizmente ainda são muitas as restrições de suporte da ferramenta para esse sistema operacional. No Linux o WebEx é suportado apenas no navegador Firefox 32-bits. Para instalar o Firefox (32-bits) no Linux Ubuntu 16.04 e algumas bibliotecas complementares que melhoram sua interface gráfica podem ser utilizados os comandos abaixo no terminal:

$ sudo apt-get install firefox:i386

$ sudo apt-get libcanberra-gtk-module:i386 gtk2-engines-murrine:i386 libxtst6:i386

O WebEx é uma ferramenta baseada em Java, então é necessário instalar o Java no Linux e o plugin IcedTea para que o Firefox seja capaz de executar applets:

$ sudo apt-get install default-jre

$ sudo apt-get install icedtea-plugin

Feito isso, o Java deve estar operacional no Firefox. Na opção Menu>Add-on>Plugin deve ser verificado se o plugin está devidamente habilitado. Agora é possível acessar sua conta no WebEx (www.webex.com) para organizar as reuniões remotas. Ao tentar abrir a primeira reunião será criado o sub-diretório oculto ".webex" no diretório home do usuário (~/.webex). Caso os recursos de áudio e desktop sharing não estejam funcionando, o que é bem provável de ocorrer nessa etapa, então será necessário digitar o comando abaixo no diretório home do usuário que instalou o WebEx. Dentro desse diretório, o usuário deve procurar por sub-diretórios com números, por exemplo no formato 12_1524:

$ cd ~/.webex/XX_XXXX

$ ldd *.so | grep "not found"

A saída do referido comando listará as bibliotecas que ainda precisam ser instaladas no sistema para que o WebEx funcione com suporte a todos os seus recursos. A partir da saída desse comando é possível utilizar o apt-file para localizar os nomes dos pacotes que contêm as bibliotecas que estão faltando:

$ apt-file search nome_biblioteca.so

$ sudo apt-get install nome_biblioteca

Obs.: Caso o apt-file não esteja instalado, basta digitar apt-get install apt-file

Após todos esses passos, basta reiniciar o Firefox (32-bits) e hospedar uma nova reunião para verificar se a ferramenta está totalmente operacional, exemplo trazido na figura abaixo que mostra a interface gráfica da ferramenta com conexão de áudio. 

Embora esses procedimentos sejam suficientes para resolver os problemas em boa parte dos casos, cada máquina tem suas particularidades de hardware e software. Caso sua experiência de configuração da ferramenta seja diferente, fique à vontade para compartilhar com os demais membros da comunidade nos comentários deste post. 

Façam seus testes...

Samuel. 

Instalação do GNS3 1.4.0 no Ubuntu via Launchpad

Olá Pessoal.

Escrevo para informá-los que agora há pouco atualizei o repositório do blog, na aba "Downloads & Laboratórios", com a última versão do GNS3 1.4.0 para Micosoft Windows (64 bits) e Mac OS X. Os instaladores têm aproximadamente 40MB e estão disponíveis apenas para plataformas 64 bits.

Já para os usuários do Linux, especificamente do Ubuntu, a boa notícia é que agora não há mais necessidade de fazer o procedimento de instalação manual porque a nova versão foi adicionada nos repositórios e o software pode ser facilmente instalado/atualizado através de um PPA (Personal Package Archive) no Launchpad, bastando o usuário utilizar as seguintes linhas de comando:

sudo add-apt-repository ppa:gns3/ppa

sudo apt-get update

sudo apt-get install gns3-gui

Para adicionar o suporte ao IOU:

sudo dpkg --add-architecture i386

sudo apt-get install gns3-iou

Aqueles interessados em instalar o GNS3 em outras distribuições Linux podem consultar a documentação oficial disponibilizada na plataforma GNS3 Jungle (www.gns3.com). Façam seus testes...

Samuel.

Failover de Servidores DHCP Redundantes no Linux

Olá Pessoal.

É muito comum a utilização de um servidor DHCP no ambiente da empresa para fins de configuração dinâmica dos endereços IP das estações da rede de maneira automática. Uma vez que a implementação de um servidor DHCP é uma tarefa relativamente simples, é comum que muitos administradores acabem por dar menor importância ao seu papel crucial em qualquer rede de médio ou grande porte. É fato que o serviço de configuração automática dos endereços é fundamental para a operação de uma rede, afinal sem endereço IP nenhum host sequer consegue ser membro efetivo da rede.

É por essa simplicidade de configuração que o serviço DHCP acaba recebendo menos atenção do administrador e muitas vezes, talvez na maioria, é implantado através de um único servidor. O problema dessa abordagem tradicional é que um único servidor DHCP acaba se tornando um potencial ponto de falha que pode trazer sérios prejuízos para qualquer rede. Caso o servidor venha a cair, as máquinas que já receberam suas configurações irão mantê-las somente até que o tempo limite de empréstimo seja atingido (lease), por isso muitos administradores contornam esse problema aumentando o tempo de empréstimo. Ocorre que essa estratégia não resolve o problema por completo, uma vez que  novas máquinas não conseguirão localizar um servidor DHCP na rede e, portanto, não serão capazes de configurar automaticamente seus endereços.

No contexto específico de ambientes que possuem servidores baseados no Linux Debian, o serviço ISC-DHCP oferece a capacidade de configuração do recurso de failover através da inserção de dois servidores DHCP redundantes. Para demonstrar o roteiro de instalação de ambos os servidores primário e secundário, tomaremos por base a topologia apresentada na figura abaixo.

1. Instalação do Serviço DHCP

A primeira etapa consiste na instalação do pacote isc-dhcp-server em ambos os servidores para que o Linux possa ser posteriormente configurado com o serviço DHCP na rede. Essa tarefa é simples e rápida através do APT (Debian):

root@LinuxServer:/# apt-get install isc-dhcp-server

2. Ativar Interfaces p/ Responder Requisições DHCP

A segunda etapa é informar em ambos os servidores em qual(is) interface(s) o serviço irá responder requisições dos clientes da rede, através da edição do arquivo "/etc/default/isc-dhcp-server".

#--- em /etc/default/isc-dhcp-server
(...) Conteúdo Omitido
#On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
#Separate multiple interfaces with spaces, e.g. "eth0 eth1".

INTERFACES="eth0"

3. Configuração do Servidor DHCP Primário

Assim como a configuração tradicional de um servidor DHCP, a configuração do failover é relativamente simples. A principal diferença é que será adicionada uma nova declaração denominada "failover peer", onde definiremos a função do servidor (primário ou secundário) e as portas em que ambos os servidores parceiros irão conversar para sincronizar os empréstimos de endereços.

#--- em /etc/dhcp/dhcpd.conf

authoritative;

ddns-update-style none;
default-lease-time 3600;
max-lease-time 3600;

failover peer "NOME"

{

    primary;                     #define servidor como primário

    address 192.168.221.1;       #endereço do servidor local

    port 647;                    #porta do servidor local

    peer address 192.168.221.2;  #endereço do servidor parceiro

    peer port 647;               #porta do servidor parceiro

    max-response-delay 30;      
    max-unacked-updates 10;     

    load balance max seconds 3;

    mclt 1800;                  

    split 128;                  

} 

subnet 192.168.221.0 netmask 255.255.255.0

{

    option routers 192.168.221.254;

    option domain-name-servers 192.168.221.201, 208.67.222.222;
    option domain-name "nome.com.br";

    pool

    {

        failover peer "NOME";

        range 192.168.221.100 192.168.221.199;

    }

}

Os parâmetros mclt e split somente devem ser configurados no servidor primário. O parâmetro mclt (maximum client lead time) corresponde à extensão do tempo de lease concedido aos clientes no caso de falha do servidor responsável. O parâmetro split é uma métrica que define a proporção de balanceamento de carga entre os dois servidores, podendo variar de 0 (toda a carga no servidor secundário) até 255 (toda a carga no servidor primário), sendo que 128 equivale ao balanceamento simétrico (50/50).

4. Configuração do Servidor DHCP Secundário

A configuração do servidor secundário não é muito diferente da configuração anterior do servidor primário, exceto pelo fato de que informaremos o papel secundário e que algumas informações específicas previamente configuradas no servidor primário agora são omitidas.

#--- em /etc/dhcp/dhcpd.conf

authoritative;

ddns-update-style none;
default-lease-time 3600;
max-lease-time 3600;

failover peer "NOME"

{

    secondary;                   #define servidor como secundário

    address 192.168.221.2;       #endereço do servidor local

    port 647;                    #porta do servidor local

    peer address 192.168.221.1;  #endereço do servidor parceiro

    peer port 647;               #porta do servidor parceiro

    max-response-delay 30;

    max-unacked-updates 10;

    load balance max seconds 3;

} 

subnet 192.168.221.0 netmask 255.255.255.0

{

    option routers 192.168.221.254;

    option domain-name-servers 192.168.221.201, 208.67.222.222;
    option domain-name "nome.com.br";

    pool

    {

        failover peer "NOME";

        range 192.168.221.100 192.168.221.199;

    }

}

Além dos servidores redundantes serem úteis para fins de disponibilidade ao eliminar o ponto único de falha na rede, outra vantagem é que eles fazem um trabalho cooperativo de balanceamento de carga na oferta dos leases para os clientes da rede, dividindo igualmente os empréstimos (se split = 128). Ambos os servidores irão armazenar o registro de todos os leases, além de logar o status dos servidores.

Obs.: É importante estar ciente de que antes da configuração dos servidores primário e secundário, espera-se que ambos estejam com os clocks devidamente sincronizados, uma vez que a referência de tempo é crucial para o serviço DHCP funcionar devidamente. Uma boa opção para manter os relógios dos servidores sincronizados é a implantação do serviço NTP na rede. O leitor encontra mais informações sobre esse assunto em outro artigo do blog, intitulado "A Hora Certa na Internet Brasileira".

Façam seus testes...

Samuel.

Nova Nomenclatura de Interfaces Previsíveis no Linux

Olá Pessoal

Recentemente, a partir da versão v197 do systemd/udev, o Linux passou a utilizar um novo mecanismo para nomenclatura das interfaces de redes, denominado Predictable Network Interface Names. O objetivo da nova nomenclatura foi solucionar problemas reais decorrentes da generalização dos nomes tradicionais que utilizavam o formato ethX (ethernet), wlanX (wireless), etc.

O problema da nomenclatura tradicional é que as interfaces de mesma natureza recebem seus nomes do kernel de maneira sequencial (no formato eth0, eth1, eth2, etc...) assim que elas são consultadas pelo driver. Ocorre que o mecanismo de comunicação entre o driver e a interface não é previsível, o que implica na possibilidade de alteração nos nomes das interfaces durante o processo de boot de máquinas que tenham múltiplas interfaces de rede em caso de atualização de hardware. Essa situação traz riscos de segurança em ambientes que tenham scripts de firewall que foram baseados nos nomes tradicionais.

Obs.: O leitor pode fazer um teste rápido para verificar essa situação usando um liveCD em máquina que tenha duas interfaces de rede. Repare que a indexação das interfaces ocorre de forma aleatória a cada boot. Em sistemas devidamente instalados os nomes permanecem persistentes depois de atribuídos pelo kernel até que haja alguma alteração de hardware que demande nova reindexação. 

O novo mecanismo de nomenclatura traz suporte nativo a diferentes políticas para nomeação das interfaces de rede, a destacar:

1. Nomes Indexados via Firmware/BIOS On-Board
2. Nomes Indexados via Firmware/BIOS PCI Express
3. Nomes Indexados via Localização Física do Hardware
4. Nomes Indexados via Endereço Físico (MAC)
5. Nomes Clássicos Nativos do Kernel (Imprevisíveis)

Todas essas políticas são utilizadas em conjunto, de forma que a primeira política será adotada caso as informações do firmware on-board estejam disponíveis, seguida pela segunda política caso as informações do firmware PCI estejam disponíveis, seguida pela terceira política se disponível, seguida da quinta política caso contrário. A quarta política não é utilizada por padrão, a menos que seja explicitamente configurada pelo administrador. Por exemplo, possíveis nomes de interfaces baseados na primeira, segunda, terceira, quarta e quinta políticas, respectivamente, seriam: eno1, ens1, enp2s0, enx78e7d1ea46da e eth0. 

Apesar das políticas padrões, as configurações realizadas pelo administrador sempre têm precedência. Ou seja, se o administrador criar links para outras regras udev, por exemplo para utilizar seus próprios nomes personalizados ou mesmo os nomes tradicionais, o novo mecanismo de nomenclatura previsível não será adotado. A nova nomenclatura previsível pode ser desativada, fazendo com que o sistema volte a utilizar os nomes tradicionais, através da simples passagem de uma instrução ao kernel durante o processo de boot. Essa tarefa pode ser realizada adicionando a seguinte linha  no arquivo de configuração do GRUB que fica localizado em /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0" 

Obs.: Reparem que em distribuições desktop é provável que a opção "quiet splash" esteja presente para que o usuário, durante o processo de boot, não tenha contato direto com as várias informações de inicialização do sistema, sendo que, ao invés disso, o usuário visualiza na tela uma imagem de inicialização (splash). Se for esse o caso, basta adicionar o parâmetro net.ifnames na sequência, depois de um espaço e dentro das aspas.

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash net.ifnames=0"

Para que as alterações no arquivo de configuração do GRUB tenham efeito a partir do próximo boot, é necessário digitar update-grub. Façam seus testes...

Samuel.

Fonte:  http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20

TACACS+ na Autenticação Centralizada de Dispositivos Cisco

Olá Pessoal.

A autenticação de usuários em dispositivos Cisco pode ser realizada através de uma base local de usuários que fica distribuída em cada uma das caixas ou através de uma base centralizada na rede via servidor TACACS+ (Terminal Access Controller Access Control System Plus). O TACACS+ é um protocolo de segurança utilizado para controlar os usuários que tentam se autenticar em roteadores ou switches da Cisco (e de outros fabricantes). Ao acessar uma caixa da rede, o usuário é conectado previamente a um servidor centralizado para fins de identificação e autorização das credenciais. Se autorizado, então o servidor TACACS+ encaminha as informações de login para a caixa remota que solicitou a autenticação.

A solução comercial oficialmente recomendada pela Cisco que implementa as funcionalidades de um servidor TACACS+ é o Cisco Secure Access Control System (ACS). Uma alternativa gratuita e que pode ser instalada no Linux é a ferramenta TAC_Plus (pacote tacacs+ no Debian). Neste artigo irei detalhar os passos necessários para configurar um servidor TACACS+ no Linux Debian e também como configurar as caixas Cisco para que o processo de autenticação seja centralizado através da comunicação com o servidor. A topologia proposta é bastante simples e pode ser observada na figura abaixo, sendo que o laboratório pode ser reproduzido no GNS3 em conjunto com o VirtualBox.

A primeira etapa consiste na instalação do pacote tacacs+ para que o Linux Debian possa ser posteriormente configurado como servidor TACACS+ na rede. Essa tarefa é simples através do APT.

root@tacacs:/# apt-get install tacacs+

Depois de instalado o pacote tacacs+, o arquivo de configuração principal do servidor TACACS+ fica armazenado em /etc/tacacs+/tac_plus.conf. Nas configurações abaixo definiremos uma chave de verificação do servidor denominada "CHAVE" e criaremos dois perfis, sendo um com privilégio administrativo de nível 15 (grupo "admin") e outro com privilégio de execução de nível 7 (grupo "user"). Na sequência, criaremos o usuário "shbbrito" no grupo "admin" e definiremos sua senha que deve ser informada de maneira cifrada. 

###--- em /etc/tacacs+/tac_plus.conf

accounting file = /var/log/tac_plus.acct

key = "CHAVE"

group = "admin"
{
  default service = permit
service = exec
{
priv-lvl = 15
idletime = 10
timeout  = 60
}
}

group = "user"
{
default service = deny
service = exec
{
priv-lvl = 7
idletime = 10
timeout  = 30
}
}

user = "shbbrito"
{
name = "Samuel Henrique Bucke Brito"
member = "admin"
login = des "1oV3QcqhpSN2w"
}

Obs.: Para gerar a senha cifrada pode ser utilizado o aplicativo tac_pwd. Ao digitar tac_pwd no shell, será necessário informar a senha para que o aplicativo possa fazer a cifragem e trazer seu resultado na tela. Neste exemplo, utilizamos a senha "SENHA" que equivale a "1oV3QcqhpSN2w".

Feito isso o servidor TACACS+ já está devidamente configurado no Linux Debian.
Para inicializar o serviço, basta digitar:

root@tacacs:/# service tacacs_plus start
[ OK ] tacacs_plus.service: TACACS+ authentication daemon

Agora que o servidor TACACS+ está operacional na rede, as caixas Cisco (roteadores e switches) devem ser configuradas para fazer a autenticação via TACACS+. Essa configuração é rápida e os comandos necessários para fazê-lo são listados abaixo, com destaque em amarelo para as informações do IP do servidor e a respectiva key que configuramos anteriormente.

Roteador(config)# aaa new-model
Roteador(config)# aaa authentication login default group tacacs+ local
Roteador(config)# aaa authorization exec default group tacacs+ local
Roteador(config)# tacacs-server host 192.168.221.1
Roteador(config)# tacacs-server key CHAVE

Façam seus testes...

Samuel.