O que é “U”? Quanto mede 1U?

 Clusterweb, Leitura Recomendada  Comentários desativados em O que é “U”? Quanto mede 1U?
out 302012
 

O “U” significa unidade de altura, é a medida padão utilizada em rack de 19″ (dezenove polegadas), seja ele de piso ou parede. A altura de 1U é aproximadamente de 4,5 cm, e a maioria dos equipamentos de redes estruturadas seguem estas medidas, como exemplo: patch panel, switch, bandeja fixa, bandeja deslizante, etc.  Vale lembrar que esta media é interna, ou seja nos espaços onde fixamos os equipamentos, sendo assim a altura externa é sempre um pouco maior.

Apresento os principais modelos de rack e altura externa:

Racks de Parede:

  • 3U = 163 mm
  • 5U = 252 mm
  • 7U = 341 mm
  • 8U = 385 mm
  • 9U = 430 mm
  • 10U = 474 mm
  • 12U = 563 mm
  • 16U = 741 mm

Rack de Piso:

  • 12 U = 648 mm
  • 16 U = 828 mm
  • 20 U = 1006 mm
  • 24 U = 1184 mm
  • 28 U = 1362 mm
  • 32 U = 1540 mm
  • 36 U = 1718 mm
  • 40 U = 1896 mm
  • 44 U = 2074 mm
  • 48 U = 2252 mm

Agora basta calcular e dimensionar o tamanho ideal para alocar todos os equipamentos dentro do rack.

Virtualização – VirtualBox em modo texto e acesso remoto

 Linux, Redes  Comentários desativados em Virtualização – VirtualBox em modo texto e acesso remoto
out 262012
 
Introdução

Este artigo demonstrará de que maneira utilizar o VirtualBox em modo texto.

Para uma introdução a respeito de virtualização e o VirtualBox, acesse o artigo Virtualização – Montando uma rede virtual para testes e estudos de serviços e servidores, pois nesse artigo irei mais direto ao ponto.

Geralmente utilizamos o VirtualBox de maneira fácil através de sua GUI de configuração, mas muitas vezes temos que instalá-lo em um servidor que não disponibiliza um ambiente gráfico para a utilização do GUI do VirtualBox, para isso podemos fazer tudo em modo texto, desde criar as VMs até importar algumas já existentes.

Testei isso tudo em um servidor rodando Ubuntu Server 9.04, com processador Dual Core 2.5 3 GB de memória e HD Sata de 160GB.

Para comandos como usuário normal usarei antes o “$” e para root “#”. Atentem a isso.

Instalação

O VirtualBox pode ser instalado de duas maneiras:

1. baixando o pacote .DEB diretamente do site e instalando usando o dpkg.

$ wget http://download.virtualbox.org/virtualbox/3.0.4/virtualbox-3.0_3.0.4-50677_Ubuntu_jaunty_i386.deb
# dpkg -i virtualbox-3.0_3.0.4-50677_Ubuntu_jaunty_i386.deb

2. adicionando o repositório do VirtualBox no sources.list e instalando pelo apt-get ou aptitude.

Comando para adicionar o repositório do VirtualBox ao arquivo sources.list:

# echo “deb http://download.virtualbox.org/virtualbox/debian jaunty non-free” >> /etc/apt/sources.list

Este comando irá baixar a chave pública para uso do repositório:

# wget -q http://download.virtualbox.org/virtualbox/debian/sun_vbox.asc -O- | apt-key add –

Atualizar o banco de pacotes:

# aptitude update

Instalação do VirtualBox e alguns pacotes necessários:

# aptitude install linux-headers-$(uname -r) build-essential virtualbox-3.0 dkms

Após o download dos pacotes será iniciada a instalação.

O instalador alertará sobre a criação do grupo vboxusers e que os usuários do VirtualBox deverão ser membros deste grupo.

Logo após ele perguntará se deseja compilar o módulo do kernel agora, responda “yes”.

Como alertado pelo instalador, teremos que adicionar o usuário que fará uso do VirtualBox ao grupo vboxusers, no meu caso o usuário é “rodrigo”.

# adduser rodrigo vboxusers

A instalação está concluída e o VirtualBox pronto para ser usado pelo usuário rodrigo.

Usando o VirtualBox por linha de comando

Criando uma máquina virtual

Para utilizar o VirtualBox por linha de comando usaremos o comando VBoxManage.

Para exemplos de comandos com o VBoxManage use o comando:

$ VBoxManage –help

Ou então visite esta página do manual do VirtualBox:

Vamos criar agora uma máquina virtual com 512MB de RAM e 20GB de HD e instalar o Ubuntu 9.04 de uma imagem que está em /home/rodrigo/ubuntu-9.04-i386.iso.

$ VBoxManage createvm -name “Ubuntu 9.04” -register
$ VBoxManage modifyvm “Ubuntu 9.04” -memory “512MB” -acpi on -boot1 dvd -nic1 nat
$ VBoxManage createvdi -filename “Ubuntu_9_04.vdi” -size 20000 -register
$ VBoxManage modifyvm “Ubuntu 9.04” -hda “Ubuntu_9_04.vdi”
$ VBoxManage registerimage dvd /home/rodrigo/ubuntu-9.04-i386.iso
$ VBoxManage modifyvm “Ubuntu 9.04” -dvd /home/rodrigo/ubuntu-9.04-i386.iso

Algumas utilidades

Para listar quais máquinas virtuais estão registradas no sistema use:

$ VBoxManage list vms

Para listar informações de uma máquina virtual específica use:

$ VBoxManage showvminfo “Ubuntu 9.04”

Depois de criada, ainda se pode modificar a máquina virtual, nesse exemplo modificaremos a memória:

$ VBoxManage modifyvm “Ubuntu 9.04” -memory “1024MB”

Outro exemplo de modificação da máquina virtual, onde mudaremos novamente a memória, colocaremos o drive de DVD como boot primário e desativaremos o suporte a USB:

$ VBoxManage modifyvm “Ubuntu 9.04” -memory 512 -boot1 dvd -usb off

Adicionar pastas compartilhadas:

$ VBoxManage sharedfolder add “Ubuntu 9.04” -name “VirtualFiles” -hostpath “/home/rodrigo/arquivos”

Para clonar um HD virtual use:

$ VBoxManage clonevdi /home/rodrigo/.VirtualBox/Ubuntu_9_04.vdi /home/rodrigo/.VirtualBox/Ubuntu_9_04-COPIA.vdi

O comando VBoxManage oferece diversas possibilidades, para ver a lista use:

$ VBoxManage –help

Iniciando a máquina virtual sem a GUI e acessando ela via RDP

Iniciando a máquina virtual

Para iniciar a máquina virtual sem que seja necessária a GUI, use o comando:

$ VBoxHeadless -startvm “Ubuntu 9.04”

VBoxHeadless irá iniciar a máquina virtual e o servidor VRDP (VirtualBox Remote Desktop Protocol), que habilitará o acesso a máquina virtual remotamente por outro computador.

O comando VBoxHeadless aceita outros parâmetros, como exemplo citarei como mudar a porta em que o servidor VRDP escutará (a padrão é 3389):

$ VBoxHeadless -vrdpport 3333

Para a lista de parâmetros execute o help:

$ VBoxHeadless –help

Acessando a máquina virtual remotamente

Para acessar a máquina virtual basta usar algum cliente de acesso RDP. No Windows podemos usar o utilitário de Conexão de Área de Trabalho Remota, que se encontra no menu iniciar > Todos os Programas > Acessórios > Conexão de Área de Trabalho Remota.

Após isso é só digitar o IP da máquina onde está a máquina virtual, no meu caso 192.168.2.100.

E logo ela estabelecerá a conexão.

Para acessar a máquina virtual no Linux é só usar o comando rdesktopem um terminal:

Ele rapidamente fará a conexão:

Conclusão

Esse foi um simples modo de se usar uma máquina virtual através de RDP, é possível implementar inúmeras soluções baseadas nisso, basta um pouco de pesquisa e muitos testes. As aplicações são diversas, desde disponibilizar uma área de trabalho com um outro sistema operacional, até oferecer serviços servidores, as possibilidades são imensas.

Espero que seja útil a alguem, deixem seus comentários, abraço a todos.

Autenticação por desafio e resposta no SSH

 Clusterweb, Linux, Redes  Comentários desativados em Autenticação por desafio e resposta no SSH
out 262012
 
Introdução

Acredito que o SSH não precise ser apresentado e tampouco detalhes de sua instalação. Até porque em praticamente todas as instalações ele já vem instalado por padrão, seja o cliente ssh ou o servidor. Em algumas o servidor precisa ser explicitamente instalado, como é o caso do Ubuntu. Mas não se apresse, é provável que você não precise de um servidor SSH em seu console, já que este é um recurso desejável justamente em servidores.

O SSH funciona sobre o protocolo SSL, da mesma forma que o HTTPS. Como o uso do SSH é feita por administradores e não por usuários leigos, é extremamente incomum o uso de certificados digitais neste caso. Afinal um administrador de redes experiente não irá cair na pegadinha do ataque do homem do meio (onde uma outra máquina se faz passar pelo teu servidor).

Durante o primeiro acesso seria prudente que o cliente verificasse se realmente é o servidor. Observe no exemplo a seguir as mensagens gerados pelo servidor no primeiro acesso:

$ ssh elgio@10.2.3.4
The authenticity of host ‘10.2.3.4 (10.2.3.4)’ can’t be established.

RSA key fingerprint is ff:7b:35:74:cd:4c:59:0b:4b:b5:cf:fe:eb:f4:ec:7a.

Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘10.2.3.4,10.2.3.4’ (RSA) to the list of known hosts.

Observe que ele lhe pede que confirme que este é mesmo o servidor. Neste ponto, se tiver certeza (e pode verificar o fingerprint), ao digitar “yes” a chave do servidor será armazenada em ~/.ssh/know_hosts.

A partir deste momento, nenhuma outra mensagem de aviso ocorrerá, salvo se o servidor for reinstalado ou se estiver mesmo sobre um ataque do homem do meio. Mas aí a mensagem será de recusar a conexão.

Meu objetivo não é exatamente descrever o SSH em si, mas sim alguns recursos pouco usados do mesmo. Um deles é o login por desafio/resposta usando uma chave pública e privada.

Como funciona o desafio resposta

Basicamente consiste em o servidor enviar um desafio para você que somente você poderia resolver. Se você acertar o desafio, passou no teste e pode autenticar-se.

Para explicar melhor o que é o desafio resposta, costumo usar um exemplo didático, porém extremamente fraco. Serve para explicar a ideia, mas não deve jamais ser usado por ser frágil.

Suponha que o cliente possua um segredo que é um número inteiro. Podemos chamá-lo de senha. O servidor conhece este segredo e permitirá login para qualquer um que provar conhecê-lo. A autenticação poderia ser da forma clássica:

  1. o cliente conta para o servidor a sua senha;
  2. o servidor verifica se ele acertou a senha;
  3. servidor aceita ou não o login.

Porém o método anterior possui um problema: a senha é enviada pela rede e alguém poderá capturar ela e se logar no futuro como sendo o cliente.

A mesma solução anterior, porém baseada em desafio e resposta, poderia ser:

  1. servidor envia uma expressão matemática para cliente resolver usando o seu segredo;
  2. cliente resolve a expressão e envia apenas a resposta;
  3. servidor, que também conhece o segredo, vê se cliente acertou a resposta;
  4. se acertou, aceita login.

Pode parecer a mesma coisa, mas a ideia é que a expressão matemática mude aleatoriamente a cada solicitação. Se alguém estiver capturando o tráfego não poderá usar a resposta em um login futuro, pois o servidor irá solicitar outra expressão matemática. Esta expressão pode ser uma simples multiplicação, como demonstra a figura:

Linux: Autenticação por desafio e resposta no ssh

O exemplo da figura anterior ilustra como é a técnica, mas não deve ser usado. Isto porque um atacante conseguirá descobrir muito facilmente a chave, bastando dividir 4305 por 123, pois ele viu o desafio e viu a resposta. Operações matemáticas que possam ser revertidas não devem ser usadas (divisão reverte a multiplicação, soma reverte a subtração). Se usar outra operação mais complexa que não possa ser desfeita e com números realmente muito grandes a técnica poderá ser usada.

Um exemplo de uma operação matemática irreversível é a de módulo, usada no RSA. Apesar de fugir um pouco do foco deste artigo, pois ainda está na minha gaveta um artigo sobre RSA, vale o exemplo:

Linux: Autenticação por desafio e resposta no ssh

O exemplo anterior ainda não pode ser usado. Poderia se os números fossem realmente grandes, com um X em torno de 512 bits de tamanho e o desafio também. Com números pequenos um ataque de força bruta seria possível, isto é, o atacante tentaria todos os possíveis valores de X até achar um que encaixe na expressão.

Já me estendi demais neste conceito, já que o objetivo era apenas explicar o princípio do desafio e resposta. No que diz respeito ao ssh, o desafio e resposta é baseado em chaves públicas e privadas.

Desafio e resposta no ssh

O ssh é suficientemente seguro se bem usado. Se você tem certeza da idoneidade do servidor e se tem certeza de que realmente é o servidor, tudo bem. Não há qualquer problema você digitar sua senha de acesso. Ela não poderá ser lida por mais ninguém.

Isto porque toda a sessão ssh é protegida por um forte algoritmo de criptografia simétrico. Quando você digita sua senha ela é cifrada com este algoritmo e transmitida pela Internet. Alguém, em posição de capturar o tráfego, não conseguirá obter esta senha.

Porém existe ainda uma forma de executar o login sem precisar enviar a senha. E uma forma segura. Mas porque não enviar a senha? Vários motivos.

Primeiro uma segurança a mais, pois agora a senha sequer viaja pela Internet, nem mesmo cifrada. Na hipótese, mesmo remota, de alguém estar aplicando um ataque do homem do meio ou de que o servidor estar corrompido, o atacante realmente não terá sua senha, de forma alguma.

Um segundo motivo pode ser a facilidade de manutenção. As vezes é chato ter que ficar colocando várias vezes a senha, principalmente se todos fizerem a coisa certa, de não usar a mesma senha em todos os servidores (por experiência pessoal, sou cético quanto a isto!).

Para resolver este problema o ssh possui o login por desafio e resposta através do uso de um par de chaves pública e privada. Você primeiro deve criar um par de chaves para si, uma chave pública e privada. A chave privada você mantém em segredo, guarda-a em segurança. Já a chave pública você deposita no servidor e diz para o ssh aceitar conexões de qualquer um que prove ser o conhecedor da chave privada.

O conceito dos algoritmos assimétricos garante que tudo que foi cifrado com a chave pública, apenas a chave privada poderá abrir. Assim o desafio gerado pelo servidor passa a ser o seguinte:

  1. servidor escolhe aleatoriamente uma sequência de bits grande (exemplo: 2048 bits aleatórios);
  2. servidor cifra estes bits com a chave pública do suposto cliente e envia;
  3. cliente precisa dizer ao servidor qual era a sequência escolhida;
  4. cliente só pode fazer isto com sucesso se conhecer a chave privada.

Este método é ainda melhor que o descrito antes, pois não envolve a senha do usuário em nenhum momento, apenas a chave privada dele. Esta chave passará a ser a parte sensível e deve ser protegida. Como ninguém conseguirá decorar uma chave de milhares de bits, ela precisa ser armazenada.

Armazenar é um problema, pois pode-se supor até o roubo do HD onde um atacante teria a chave e se logaria em seus servidores. Para evitar isto, o ssh permite que você proteja sua chave com uma frase de passagem, que você poderá lembrar-se. Pode ser qualquer sequência de caracteres que será solicitada pelo seu programa cliente quando você fizer o login.

Configuração do ssh para autenticação por desafio e resposta

A autenticação por desafio resposta no ssh deve estar habilitada no ssh server. Por minha experiência, todos os servidores ssh já vem com isto habilitado, mas convém verificar. Apenas verifique se a informação PubkeyAuthentication no /etc/ssh/sshd_config não está em “no”. Normalmente ela está comentada no arquivo, o que significa que está ativa (o padrão é permitir):

# grep Pubkey /etc/ssh/sshd_config
#PubkeyAuthentication yes

Se ela estiver comentada ou com “yes”, tudo bem. Mas se estiver com “no”, comente a regra ou mude para “yes” e reinicie o ssh server.

Com o servidor configurado para aceitar esta forma de autenticação, deve-se ainda realizar os seguintes passos:

  1. criar um par de chaves
  2. instalar a tua chave pública no servidor

Usarei o usuário fulano como teste neste artigo.

Criação do par de chaves

Usuário fulano tem um login e senha no servidor 10.2.3.4. O cliente é a máquina didaké (nome do meu notebook). Primeiro ele se logou com seu usuário e senha, só para testar:

$ ssh 10.2.3.4
The authenticity of host ‘10.2.3.4 (10.2.3.4)’ can’t be established.
RSA key fingerprint is fb:a9:ac:b6:3d:3f:42:76:11:cc:44:2f:7f:55:49:97.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘10.2.3.4’ (RSA) to the list of known hosts.
Password:
Have a lot of fun…

Voltando a máquina cliente, a didaké, ele cria seu par de chaves com o ssh-keygen. Os parâmetros indicam criar chaves usando o algoritmo dsa e com 1024 bits de tamanho. Se você não especificar o DSA, o algoritmo RSA será usado. O protocolo RSA não é usado por padrão no ssh e não funcionará a menos que você coloque o parâmetro RSAAuthentication yes no /etc/ssh/sshd_config. Este é desabilitado por padrão.

$ ssh-keygen -b 1024 -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/fulano/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/fulano/.ssh/id_dsa.
Your public key has been saved in /home/fulano/.ssh/id_dsa.pub.
The key fingerprint is:
4e:e4:ab:5c:5d:06:58:83:95:4a:77:1d:a0:7d:e7:ba fulano@didake
The key’s randomart image is:

+--[ DSA 1024]----+ 
|         o+..o.. | 
|        ooo+. .  | 
|       .ooo.. . .| 
|       o.  . . o | 
|        S   o   .| 
|       o o o   . | 
|        + .   .  | 
|     . o       . | 
|      o       E  | 
+-----------------+

Quando ele perguntar “Enter file in which to save the key (/home/fulano/.ssh/id_dsa): ” simplesmente dê um enter aceitando esta sugestão.

Como frase de passagem eu coloquei “Viva o Linux 2009″. Pode ser qualquer coisa, mas tome cuidado pois você deve digitar exatamente a mesma coisa quando solicitado. Se digitar “Viva o LINUX 2009” já não será a mesma frase, pois Linux está tudo em caixa alta. Desaconselha-se deixar sem frase de passagem, mas é uma configuração possível.

Instalação da chave pública no servidor

A instalação da chave pública no servidor consiste em simplesmente colocar ela dentro do arquivo ~/.ssh/authorized_keys. Este arquivo pode ter várias chaves públicas, não apenas uma.

Para realizar esta tarefa o usuário fulano precisará logar-se no servidor, usando ainda sua senha. A chave pública criada está em ~/.ssh/id_dsa.pub no cliente e home do fulano. Ela é texto puro (base64) logo pode-se até dar um cat nela:

$ cat id_dsa.pub
ssh-dss AAAAB3NzaC1kc3MAAACBAKaOHlNYzozRRr0Ub1kAi/mBap55fQCda0t4T4rZnskdqX /gMnKvLP8B514b3Oq8exNCkTym6nyv1LyxxG1VmhpjKN8N8eDaErp/8qEif/GvH3HaFx4GJBWFed4Z6K9HkxsBy2yFwfcBmkvGFP3ggMwhBnKYFf7DSa9/0QzHDDx3AAAAFQDEb5c3RMsEo8xU6YsvVXnIlJteLQAAAIA+3Oa2X2oW2gprZkCRe7JE +KWvH+O9xjep/7l6iGFww9IDj35VgEHMzAr6LPvw+rAOB1P5qoXZr3hbTU6pzfHiSLy6UD G+LzHLRbyImZOH/p+n7hWtEfZs6mO5ZuJFxO3fStQKWy0r48XUEaduHY5PGQc+sa/fpjyS2BPToM46XgAAAIAzsUHfOZnFhGK5cmMGjEFyjQBIKqYxRo3pR2H0au/ObwrKan6rCEqWropJElI234AeIymOS2h4Hr3lHnbmyXsxxCt14xqE7ZQlq5X7DV2QCl 0PUcgGlbVSLNTGLXapW1KN2tiBv7u8Q0agNgZ3ek3XHTKtZ6jVm0eb/ACsg0D+Sw== fulano@didake

Não faça o mesmo para a chave privada, pois ela não é em formato texto, é binário.

Então, basta pegar esta sequência esquisita de caracteres e copiá-la, assim como está, para o servidor. No Gnome pode-se até mesmo usar o recurso de copiar e colar do sistema, como demonstra a sequência de imagens.

Linux: Autenticação por desafio e resposta no ssh

Selecionando a chave pública no cliente, arquivo ~/.ssh/id_dsa.pub e usando o “Copy” do próprio Gnome.

Linux: Autenticação por desafio e resposta no ssh

Após, loga-se no servidor 10.2.3.4 ainda usando sua senha, e coloca-se a chave dentro do arquivo authorized_keys em ~/.ssh. No caso eu usei o simples cat com redirecionamento (cat >> authorized_keys).

Linux: Autenticação por desafio e resposta no ssh

Ao final, após colar, deve-se pressionar Control+D e o arquivo está com a chave pública. Na imagem, após o término, executei um cat para verificar.

Outras tantas formas podem ser usadas para obter-se o mesmo resultado, como simplesmente editar o arquivo authorized-keys com algum editor qualquer. O fato é que ele deve ter a chave pública.

Por fim, após a instalação, pode-se verificar se está funcionando. fulano sai do servidor e tenta-se logar novamente:

$ ssh 10.2.3.4
Enter passphrase for key ‘/home/fulano/.ssh/id_dsa’:
Last login: Mon Jul 27 13:40:02 2009 from 10.1.0.10
Have a lot of fun…

Agora ele pediu a frase de passagem que protege a chave pública. No caso eu tive que digitar o “Viva o Linux 2009” para poder me logar.

Conclusão

O uso desta forma de autenticação é considerado mais seguro que com usuário e senha. Porém a maior vantagem, na minha opinião, é ser bem mais prático.

Prático porque você pode colocar senhas diferentes em seus servidores e logar-se neles apenas por desafio e resposta, decorando apenas a sua frase de passagem. Pode colocar sua chave pública em todas as máquinas Linux que você deseja acessar.

Mais prático também porque hoje muitos chaveiros permitem armazenar a frase de passagem, solicitando-a apenas uma única vez por sessão e fazendo realmente um login sem senha nas conexões posteriores. É o caso do Gnome (e não uso KDE para testar).

Muitas coisas fantásticas podem ser realizadas com esta técnica, algumas com bastante cuidado, evidente. Eu, por exemplo, em um curso de Linux, criei um par de chaves e o coloquei no /root/.ssh/authorized_keys de todas as máquinas dos alunos. Assim, a partir do meu notebook, eu podia executar remotamente qualquer comando nas máquinas e sem senha, pois usava o lembrete de senhas do Gnome.

Para desligar uma máquina, bastou um:

$ ssh root@10.2.3.4 “/sbin/shutdown -h now”

Isto dentro de um for, permite executar em todas as máquinas. Um exemplo mais interessante foi quando precisei que os alunos tivessem poderes de root as vezes, mas não sempre. Quando eu queria lhes dar esta permissão para todas as 20 máquinas, executava do meu notebook:

$ for IP in `cat ubuntu.txt`; do
ssh root@$IP “/usr/sbin/adduser aluno admin”
done
echo OK

E dentro do arquivo ubuntu.txt tinha os IPs dos clientes, um por linha (nota: no ubuntu o adduser pode ser usado para inserir um usuário já existente em um grupo). Se, depois, não quero mais que o usuário aluno tenha poderes de root, então:

$ for IP in `cat ubuntu.txt`; do
ssh root@$IP “/usr/sbin/deluser aluno admin”
done
echo OK

Isto porque no Ubuntu para poder usar o sudo basta estar no grupo admin (e no ubuntu o deluser pode ser usado para remover um usuário de um grupo. Nesta forma de uso, o usuário em si não é removido, apenas sai do grupo).

Se você gerencia dezenas de máquinas pode ser extremamente criativo e deixar os scripts trabalharem por você.

Elaborando vídeo-aula no Linux com Gtk-recordMydesktop

 Clusterweb, Linux  Comentários desativados em Elaborando vídeo-aula no Linux com Gtk-recordMydesktop
out 262012
 

Introdução

Já a algum tempo o uso de vídeo-aula tornou-se um aliado para pessoas que queiram aprender ou ensinar a distância, com o uso da internet e sites que possibilitam a publicação de vídeos, está se tornando a realidade a publicação de vídeos auxiliares ao auto aprendizado. Quem nunca se deparou com vídeos no Youtube ensinando a configurar algum tipo de software, arquivo de configuração ou outro tipo de tarefa que utilize o computador?!

Já era de se esperar que de uma certa forma seria interessante esse contexto para a comunidade Open Source, pois a filosofia de ensino quebra a barreira da distância e passa utilizar de veículos de comunicações de uso livre, como sites de publicação de artigos técnicos, vídeos e entre outros.

Há algum tempo venho pensando em complementar os meus artigos com vídeos que possam ilustrar melhor o contexto aplicado, para que os leitores possam absorver melhor o conhecimento que está sendo transmitidos. Esse esforço pode minimizar alguns erros de configuração da parte de quem está lendo determinado conteúdo de um artigo ou dica que aqui está escrito.

O conceito de vídeo-aula nasceu na década de 80, que tornou viável com a popularização dos famosos videocassetes, que utilizavam fitas VHS, Alguém ainda lembra deles? Já na década de 90 os DVDs passaram os tornaram obsoletos de forma rápida e cruel. Hoje o modelo de negócio está mudando a internet os tornam muitas vezes inviáveis e com isso um novo negócio está por vir.

Linux: Elaborando vídeo-aula no linux com Gtk-recordMydesktop

Por muitas vezes me deparei com vídeos sobre Gimp no Youtube, que o Guilherme RazGriz disponibiliza e outros mais, e percebo uma grande vantagem em fazer vídeos, principalmente para iniciantes em Linux.

Como estamos falando de software livre, um dos melhores programas para fazer esse tipo de vídeo-aula é o Gtk-RecordMyDesktop, que faz toda gravação das ações e execuções de seus desktop. O software é livre e de código aberto, foi desenvolvido em python e sua versão atual é a 0.3.8.

Instalação e configuração do Gtk-RecordMyDesktop

O processo de instalação é bem simples, podendo utilizar o a linha de comando ou como gerenciador de instalação Synaptic, que atualmente é um dos mais simples e completos gerenciadores de instalação. Para instalar dê os seguintes comandos.

Comandos para instalação do Gtk-RecordMyDesktop

# apt-get update
# apt-get install gtk-recordmydesktop recordmydesktop

Após instalados os programas iremos para a parte de utilização, os screenshots abaixo ilustram de forma clara a utilização do programa. O ícone do programa pode ser encontrado na sessão multimídia do menu do Gnome ou KDE. É importante lembrar que a distribuição que estou usando é a Ubuntu 9.10. Então vamos ao iniciar a configuração!

Para iniciar a gravação, execute o programa em:

Aplicativos > Multimídia > gtk-recordMyDesktop

A tela principal é bem simples e configurável. Iniciando logo acima você pode definir a qualidade de vídeo e som, essa opção padrão requer o máximo de qualidade, portanto é importante definir a qualidade baseada na duração do seu vídeo, pois com maior qualidade maio o tamanho do arquivo a ser gerado.

Podemos selecionar uma área especifica para gravar, por exemplo, se optar por gravar somente o browser você pode marcá-lo clicando em “Selecionar janela” e em seguida começar a gravar. O processo de gravação se dá por configurações padrões, então para gravar poderá clicar diretamente em gravar e começar a fazer a sua vídeo-aula. A figura abaixo mostra a tela principal.

Linux: Elaborando vídeo-aula no linux com Gtk-recordMydesktop
Tela principal

O menu “Configurações avançadas” possui uma série de configurações que são importantes na criação do vídeo e na qualidade. Ao clicar em avançado abrirá uma tela com quatro abas, ambas são parte da configuração. Na aba “Arquivos” temos duas configurações, uma para sobrescrever arquivos já existentes e a outra o diretório de trabalho, ou seja, quando vídeo está sendo gerado, ele precisa de um diretório para colocar arquivos que possuem vida temporária. Veja na figura abaixo.

Linux: Elaborando vídeo-aula no linux com Gtk-recordMydesktop

A aba “Performance” possui as seguintes configurações:

  • Quadros por segundo: essa opção pode exigir muito do seu computador, porém é ela quem irá determinar o tempo de captura de gravação, aumentar muito essa opção pode influenciar no tamanho do arquivo.
  • Encode On the Fly: essa opção pode fazer seu computador trabalhar de forma bruta, porém é ela que define os detalhes das telas, caso não se preocupe tanto com detalhes ou se possui pouco recurso em seu computador, deixe-a desativada.
  • Compressão Zero: essa opção controla a compressão do cache, que por sua vez pode vir desabilitada por padrão e por esse motivo deve habilitá-la, para não exigir da máquina.
  • Conversão rápida de RGB para YUV: tem a ver com a qualidade da transformação das cores que é feita depois da captura e ou codificação. O servidor X geralmente usa o bitmap em RGB, enquanto o ogg utiliza o YUV. Em particular o espaço de cores YUV:420 é usado para os vídeos finalizados, em que o plano Y está em alta resolução, e o U e V uma conversão meio altura e meio largura. Habilitando essa opção, significa que durante o processamento de u e v, apenas o primeiro pixel numa quadra de bloco de quatro pixels está sendo levado em conta para a geração do rgb pixmap. Deixando isso desabilitado significa que os 4 pixels são levados em conta, e queira ser feito mais um para a conversão. (www.estudiolivre.org).
  • Screenshot completa a cada quadro: Pode exigir muito recurso da máquina, faz uso intenso dos bitmaps.
Linux: Elaborando vídeo-aula no linux com Gtk-recordMydesktop

A aba “Som” permitirá que se manipule a qualidade da captura de som e a porta em que será feita a captura.

Os canais de som podem disponibilizar duas opções para fazer a gravação do áudio, podendo ser mono ou stereo. Caso queira usar somente o microfone, deixe a opção com o valor 1, caso queira gravar música junto, atribua o valor 2. A frequência padrão é a 22048 caso for gravar com o canal com valor 2 use 44100. A frequência pode a alterar o tamanho do arquivo. Você pode definir qual o módulo de som pode ser usado o ALSA ou OSS, porém na instalação o programa já define o módulo padrão.

A última aba “Variados” traz configurações padrões, a opção “Exibição” é a que faz inteiração com o ambiente X. O cursor do mouse é uma opção para colorir a cor mouse para diferenciar em telas pretas e telas brancas, por exemplo, se estiver gravando o terminal deverá colocar o mouse na cor branca, ou se estiver usando um browser deverá usar o mouse na cor preta, mas isso não é uma convenção, é somente questão estética. Também há a opção de não gravar o mouse.

A extensão MIT-Shm usa memoria MIT compartilhada, se desabilitar essa informação pode ocasionar lentidão no computador durante a gravação. A opção “Dicas” é a que habilita as especificações quando passamos o mouse sobre cada botão ou objeto que possui hint na tela.

Linux: Elaborando vídeo-aula no linux com Gtk-recordMydesktop

Zimbra 8.0 no CentOS 6.3

 Linux, Servidor de E-mail  Comentários desativados em Zimbra 8.0 no CentOS 6.3
out 252012
 
Instalação e Configuração

Introdução

Como o objetivo é só a instalação do Zimbra, não fiz a instalação do CentOS por entender que já tenham uma Lab com um máquina instalada.

A instalação foi feita do zero, usando a instalação minimal do CentOS, só com o pacotes básicos, pois o Zimbra já inclui todos os pacotes necessários para o seu funcionamento.

Softwares necessários

Para iniciar o processo de configuração, primeiramente precisamos baixar/instalar alguns pacotes. São eles:

  • bind;
  • nc;
  • sysstat;
  • perl;
  • weget;
  • vim;
  • zimbra.

Ao instalar o CentOS, é instalado por default um servidor de e-mail para envio de mensagens locais, o Postfix. Precisamos, assim, parar e remover o Postfix da inicialização, pois o Zimbra já possui o Postfix e, se deixarmos ele rodando, o Zimbra não vai subir.

Sendo assim, vamos parar e tirar o serviço do boot:

# service postfix stop
# chkconfig –del postfix

Agora, vamos instalar os pacotes para podermos iniciar a instalação:

# yum install bind bind-utils nc sysstat perl wget vim

Pronto, agora estamos com o todos o requisitos necessários para a configuração do DNS e a instalação do Zimbra em si.

Configurando

Bom, agora com o pacotes instalados em seu sistema, vamos para à parte de configuração do named. Execute os comandos:

# cd /etc/
# cp -p named.conf named.conf-original
# > named.conf
# vim named.conf

Adicionaremos o seguinte conteúdo ao arquivo “named.conf”:

options {
        directory "/var/named";
        dump-file "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        allow-query { 127.0.0.1; 192.168.0.0/24; };
        allow-recursion { 127.0.0.1; 192.168.0.0/24; };
        forwarders { 8.8.8.8; 8.8.4.4; };
        forward first;
        notify no;
};
controls {
        inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};
zone "." IN {
        type hint;
        file "named.ca";
};
zone "zmexemplo.com.br" IN {
        type master;
        file "db.zmexemplo.com.br";
};
include "/etc/rndc.key";

Agora, criaremos o arquivo “db.zmexemplo.com.br”, este arquivo deve estar em /var/named/:

# cd /var/named/

# vim db.zmexemplo.com.br
$TTL    86400
@       IN      SOA     zmail.zmexemplo.com.br. root.zmail.zmexemplo.com.br. (
                                10118      ; Serial
                                43200      ; Refresh
                                3600       ; Retry
                                3600000    ; Expire
                                2592000 )  ; Minimum
          IN          NS         zmail.zmexemplo.com.br.
          MX         10          zmail.zmexemplo.com.br.
zmail            IN          A          192.168.0.252

Feito isso, agora iremos gerar a chave:

# rndc-confgen -a -c /etc/rndc.key

Obs.: Deve demorar uns minutinhos.

Configurando o /etc/resolv.conf:

# vim /etc/resolv.conf

Edite:

search zmexemplo.com.br
nameserver 192.168.0.252

Testando o serviço DNS

Testando a configuração do named:

# service named configtest

No retorno deste comando, deve vir algo assim:

zone zmexemplo.com.br/IN: loaded serial 10118

Se estiver tudo ok, execute:

# service named restart

Caso dê algum erro, verifique no /var/log/messenges. Se tiver algum erro de permissão, verificar a permissão com:

# ls -l /etc/rndc.key

Ou, faça da seguinte maneira:

# chown root:named /etc/rndc.key
# service named restart [ok] está tudo certo

Se não deu erro, podemos continuar. Agora vamos editar o /etc/hosts:

# vim /etc/hosts

Edite:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
192.168.0.252 zmail.zmexemplo.com.br zmail
::1       localhost localhost.localdomain localhost6 localhost6.localdomain6

Feito assim, salve a configuração a partiremos para testar o serviço DNS:

# dig +short zmail.zmexemplo.com.br

No retorno do comando dig, deverá vir o IP do servidor. No meu caso:

192.168.0.252
# dig -x 192.168.0.252 # Numero do servidor

Assim, terminamos essa parte. Agora vamos iniciar a instalação do Zimbra.

Baixando e instalando o Zimbra 8

Agora, vamos baixar e instalar o Zimbra Open Source Edition 8 x64, para RHEL. Como estamos utilizando CentOS, vamos baixar este arquivo:

# wget http://files2.zimbra.com/downloads/8.0.0_GA/zcs- 8.0.0_GA_5434.RHEL6_64.20120907144639.tgz

Extraindo o arquivo com o tar:

# tar -xvf zcs-8.0.0_GA_5434.RHEL6_64.20120907144639
# cd zcs-8.0.0_GA_5434.RHEL6_64.20120907144639

Iniciando a instalação:

# ./install.sh –platform-override

O comando –platform-override, é mais ou menos isso: “Subscreva e ignore a plataforma”.

Como baixamos para RHEL e nosso servidor é CentOS, o Zimbra chia, é para isso que serve o comando.

Quanto aparecer esta pergunta:

Do you agree with the terms of the software license agreement? [N] y

Colocamos y e apertamos ENTER.

Abaixo, deixamos tudo como default do Zimbra, só acrescentamos “Y” onde está “Y”, e “N” onde está “N”:

Select the packages to install:

Install zimbra-ldap [Y] y

Install zimbra-logger [Y] y

Install zimbra-mta [Y] y

Install zimbra-snmp [Y] y

Install zimbra-store [Y] y

Install zimbra-apache [Y] y

Install zimbra-spell [Y] y

Install zimbra-memcached [N] n

Install zimbra-proxy [N] n
Install anyway? [N] y [e dê um ENTER]
The system will be modified. Continue? [N] y [e dê um ENTER]

Agora, é só aguardar a instalação dos serviços do Zimbra.

Ao terminar, ocorrerá esse erro: ele fala que não conseguiu resolver o mx do domínio zmail.zmexemplo.com.br, pois zmail não é mx e o mx é zmexemplo.com.br, então colocamos Yes [dê ENTER].

DNS ERROR resolving MX for zmail.zmexemplo.com.br
It is suggested that the domain name have an MX record configured in DNS
Change domain name? [Yes]Yes

E ficará da seguinte forma:

Create domain: [zmail.zmexemplo.com.br] zmexemplo.com.br [de ENTER]

A próxima etapa é configurar a senha do admin. Irá surgir as opções:

Main menu
   1) Common Configuration:
   2) zimbra-ldap:                  Enabled
   3) zimbra-store:                 Enabled
        +Create Admin User:             yes
        +Admin user to create:          admin@zmexemplo.com.br
******* +Admin Password             UNSET
        +Anti-virus quarantine user:        virus-quarantine.hnh04bvgxu@zmexemplo.com.br
        +Enable automated spam training:    yes
        +Spam training user:                spam.0wby7p2sr@zmexemplo.com.br
        +Non-spam(Ham) training user:       ham.i7csumon8@zmexemplo.com.br
        +SMTP host:                 zmail.zmexemplo.com.br
        +Web server HTTP port:          80
        +Web server HTTPS port:         443
        +Web server mode:               https
        +IMAP server port:              143
        +IMAP server SSL port:          993
        +POP server port:               110
        +POP server SSL port:           995
        +Use spell check server:            yes
        +Spell server URL:              http://zmail.zmexemplo.com.br:7780/aspell.php
        +Configure for use with mail proxy: FALSE
        +Configure for use with web proxy:  FALSE
        +Enable version update checks:      TRUE
        +Enable version update notifications:   TRUE
        +Version update notification email: admin@zmexemplo.com.br
        +Version update source email:       admin@zmexemplo.com.br
   4) zimbra-mta:                   Enabled
   5) zimbra-snmp:                  Enabled
   6) zimbra-logger:                    Enabled
   7) zimbra-spell:                 Enabled
   8) Default Class of Service Configuration:
   r) Start servers after configuration     yes
   s) Save config to file
   x) Expand menu
   q) Quit

Escolheremos acima, as opções 3 e 4. Os resultados dessas opções, você confere abaixo:

Password for admin@zmexemplo.com.br (min 6 characters): [1AIAXRBsJ] SENHADOADMIN

Usado para criar as futuras contas de e-mail. A opção ‘r’ retorna, ‘a’ para salvar, ou Yes para salvar a configuração no arquivo.

Ele pedirá para notificar a VMware Zimbra do tanto de instalação que tem, no meu caso, eu coloquei “No”, pois como é uma instalação de teste não irá ser publicada e não há necessidade.

Quanto aparecer:

Configuration complete – press return to exit

Pronto, a instalação está feita.

Depois execute:

# su – zimbra

$ Zmcontrol status    # Verifica os serviços que estão rodando
$ Zmcontrol stop    # Para os serviços do Zimbra
$ Zmcontrol start    # Inicia os serviços do Zimbra

Firewall – Chat – Screenshots

Para quem usa um firewall, como via de regra, é fazer a liberação das portas no firewall para que o Zimbra funcione (envie e receba dados). Como no meu caso foi só para teste, eu desabilitei o firewall.

Um dos inúmeros recursos interessantes do Zimbra é o Zimlets, que tem a função, entre outras, que você pode ir adicionando, do chat. Este é um recurso que pode ser liberado de dentro do e-mail para os contatos do próprio domínio.

Então mãos à obra, vamos carpi. (hehehe)

Vamos logar com o usuário Zimbra:

# su – zimbra

Depois, basta executar:

$ zmprov -l -v mcf zimbraXMPPEnabled TRUE
$ zmprov -v mc default zimbraFeatureIMEnabled TRUE
$ zmprov -v mc default zimbraFeatureInstantNotify TRUE
$ zmcontrol stop
$ zmcontrol start

Screenshots

Uns screenshots das telas do Zimbra:

Linux: Zimbra 8.0 no 
CentOS 6.3   Linux: 
Zimbra 8.0 no CentOS 6.3   Linux: Zimbra 
8.0 no CentOS 6.3

Conclusão

Esta instalação foi feita em um ambiente de teste com Zimbra 8, para um ambiente de testes para estudos e conhecimento da nova versão da ferramenta.

Já para ambiente de produção, seria aconselhável o Zimbra 7.2.

Para visualizar o Zimbra no navegador, acesse:

– Esse é o console do Admin:

  • https://IP_DO_SERVIDOR:7071

– Interface do Webmail:

  • https://IP_DO_SERVIDOR