Usando um FreeBSD como Bridge

Para criarmos a bridge com o FreeBSD primeiramente precisaremos criar uma interface para a bridge.

ifconfig create bridge0

Depois precisamos informar quais placas de redes irão ser agrupadas na bridge

ifconfig bridge0 addm em0 addm vr0 up

Veja que adicionamos as interfaces duas interfaces (emo e vro) para formarem a bridge.

Agora vamos levantar as interfaces de rede e a bridge

ifconfig emo up
ifconfig vr0 up
ifconfig bridge0 up

pronto nossa bridge está pronta.

Se quisermos gerenciar essa bridge é só adicionarmos um endereço IP para ela.

ifconfig bridgeo 192.168.0.230 netmask 255.255.255.0

Caso haja necessidades de limitar o trafego de rede que passa através da bridge será necessário compilar o kernel do FreeBSD com as seguintes opções.

options IPFIREWALL
options IPFIREWALL_DEFAULT_ACCEPT
options DUMMYNET
options HZ=1000

Edite o arquivo rc.conf com as seguintes caracteristicas:

firewall_enable=yes
firewall_type=open

Com essas opções você garantirá que o firewall está ativado e “aberto” para qualquer pacote.
Para habilitarmos o controle de banda sobre a bridge vamos utilizar o sysctl.

sysctl net.link.bridge.ipfw=1

Para limitar a banda escreveremos um script para facilitar o processo, o script limita-banda.sh vai ter o seguinte conteúdo:

#!/bin/sh
BANDA=5Mbit/s

case $1 in

start)
sysctl.net.link.ipfw=1
ipfw add 10 pipe 1 ip from any to any bridge0
ipfw pipe 1 config mask src-ip 0x000000ff bw $BANDA
ipfw pipe 1 config mask dst-ip 0x000000ff bw $BANDA
;;

stop)
sysctl.net.link.ipfw=1
ipfw delete 10
;;

*)
echo “Uso `basename $0` {start|stop}
;;

esac

No script estamos informando que a quantidade de banda utilizada será de 5Mbit/s e criamos um “cano” para que o trafego seja passado através dele com a velocidade máxima de 5Mbit/s.

Para executar o script podemos utilizar:

chmod +x limita-banda.sh
./limita-banda.sh

Para que ao reiniciar a bridge não seja necessário refazer todos esses passos é só editarmos o arquivo /etc/rc.local e adicionar o seguinte:

# Cria a bridge e levanta as interfaces
ifconfig bridge0 addm em0 addm vro
ifconfig emo upifconfig vro upifconfig bridge0 up
ifconfig bridge0 129.168.0.230 netmask 255.255.255.0
# Ativa o limite de banda
/root/limita-banda.sh

Pronto, uma bridge FreeBSD pronta para uso!
Boa diversão!

Dicas rápidas FreeBSD

Habilitando o IPFW no FreeBSD

Vá para o diretorio /usr/src/sys/i386/conf e copie o arquivo GENERIC para um outro nome.

Ex: cp GENERIC  ATLAS

No meu exemplo copiei o arquivo GENERIC para um novo arquivo que é o nome do meu FreeBSD (ATLAS).

Agora edite o arquivo recem criado e inclua as seguintes informações no final

options IP_FIREWALL
options IP_VERBOSE
options IP_FIREWALL_FORWARD
options IP_FIREWALL_DEFAULT_TO_ACCEPT
options IP_DIVERT
options DUMMYNET
Options HZ=1000

Salve o arquivo e compile o kernel.

cd /usr/src/
make buildkernel KERNCONF=ATLAS
make installkernel KERNCONF=ATALS

Altere o arquivo rc.conf e adicione as seguintes linhas:

firewall_enable=yes
firewall_type=simple

Com essas opções seu firewall já se encontra funcionando e com regras de restrição habilitadas, se quiser adicionar outras regras basta editar o arquivo /etc/rc.firewall.

Instalando um novo software no FreeBSD

Existe duas maneiras rápidas de instalar novos softwares em seu FreBSD, via ports e via pkg_add. Para instalar um novo software via  ports é proceder da seguinte forma:

cd /usr/ports/<categoria>/<software>/
make
make install

Ex: cd /usr/ports/www/squid/
make
make install

Esse processo irá baixar diretamente da Internet os fontes do software e irá compila-lo, ajustando-o a seu equipamento. Esse procedimento pode ser muito demorado pois o ports irá baixar as dependências dos pacotes e compila-los também.

Para se instalar um software via pkg_add é só seguir o procedimento abaixo:

pkg_add -rv <software desejado>

Ex: pkg_add -rv squid

Esse processo também irá baixar o software via Internet, porém os pacotes que irão ser baixados são pacotes pré-compilados, caso exista dependências o pkg_add irá baixar as versões pré-compiladas das dependências.

Removendo um software no FreeBSD

Assim como os pacotes foram instalados via ports e pkg_add os mesmos podem ser removidos.

Remoção via ports:
cd /usr/ports/<categoria>/<software>
make deinstall

Ex: cd /usr/ports/www/squid
make deinstall

Remoção via pkg_delete

pkg_delete -v <software desejado>
Ex: pkg_delete -v squid

Dicas rapidas OpenSolaris

Algumas dicas rápidas para quem tá iniciando no OpenSolaris igual a mim.

Parando um serviço:

svcadm disable <serviço>
Ex: svcadm disable network/ssh

Iniciando um serviço:

svcadm enable <serviço>
Ex: svcadm enable netword/ssh

Verificando o estado de um serviço:

svcs  ou svcs -a | grep <serviço>

Ex: svcs -a | grep ssh
online         Dec_14   svc:/network/ssh:default

Instalando uma aplicativo (estilo apt/yum/urpmi):

pkg install <aplicativo>

Ex: pkg install SUNWsquid

Parece brincadeira mas essas dicas podem poupar um bom tempo para um usuário iniciante.

Matando maquinas virtuais travadas no VMWare ESXi

Não existe nada mais irritante do que buscar alguma informação no google e não achar ou pior, achar mais com informações que não implicam com o que você realmente quer. Isso aconteceu recentemente comigo para resolução de um pequeno mais desastroso problema: o travamento de uma máquina virtual no ESXi. Tudo bem, é simples a máquina virtual travou é só ir lá e dar um shutdown nela através do client do infrastructure, pois bem e quando você via lá dá um shutdown via client e o mesmo não desliga? Cortar os pulsos?! Pular do 20º andar, apelar para ignorancia e dar um shutdown no EXSi?! Não tem um procedimento simples e eficaz para essas horas, matar a maquina virtual. OK, porém o ESXi parece um Linux mas todo customizado para rodar maquinas virtuais e alguns comandos e processos existentes no VMWare Server, ESX 3.5 (Sem o “i”) e VMPlayer simplesmente não estão lá, o que pode facilmente um administrador ao desespero.

Verifiquei que o ESXi não possui o vmware-cmd, ou seja, não posso utilizar um stop hard. com isso me basta matar o processo responsavel pela máquina virtual, mas isso também não vai funcionar uma vez que o comando é o vmware-cmd. Dar um shutdown no ESXi vai para todas as máquinas e o processo pode continuar demorando para ser morto e com isso perder mais tempo ainda e agora com todas as máquinas virtuais desligadas, fora que se eu realizar um shutdown estilo Wolverine (puxar o cabo de força) pode gerar problemas no sistema de arquivos, sair matando processos arbitrariamente também não é legal, afinal qual é o processo que pode ser detonado?!

Diante desse cenário realizei as seguintes ações:

Conectei no ESXi via SSH e lá rodei um esxtop, com o qual verifiquei que o processo da máquina virtual que mandei desligar estava usando 98% de um dos processadores do ESXi.

ID    GID NAME             NWLD   %USED    %RUN    %SYS   %WAIT    %RDY
25949  25949 Magneto           7    98.82    5.86    0.05  687.24    2.05
147567 147567 Storm         7    2.49    2.50    0.03  691.49    1.17
9369   9369 Cyclops                 7    1.62    1.63    0.01  692.69    0.83

Sai do esxtop e dei um ps auwx | grep <nome da minha Máquina virtual> para localizar os processos ligados a minha máquina virtual.

~ # ps ax auxxxx | grep Magneto
21383448      vmm0:Magneto
21383449      vmm1:Magneto
21383451 21383447 mks:Magneto      /bin/vmx
21154076 21383447 vcpu-0:Magneto   /bin/vmx
21383454 21383447 vcpu-1:Magneto   /bin/vmx

Não podemos matar todos os processo simplesmente pois podem gerar problemas a máquina virtual, pelo que pude entender todas as máquinas virtuais estão ligadas a um processo vmx pai, que é responsavel por agrupar todos os demais processos ligados aquela máquina. Visto isso realizei outro ps auxwww mas agora fazendo uma grep para  vmx.

~ # ps ax auxxxx | grep vmx
61545 61545 vmx                  /bin/vmx
61547 61545 vmx                  /bin/vmx
61548 61545 mks:Storm    /bin/vmx
61549 61545 vcpu-0:Storm /bin/vmx
68727 68727 vmx                  /bin/vmx
68729 68727 vmx                  /bin/vmx
68730 68727 mks:Cyclops    /bin/vmx
68731 68727 vcpu-0:Cyclops /bin/vmx
21383447 21383447 vmx                  /bin/vmx
21383450 21383447 vmx                  /bin/vmx
21383451 21383447 mks:Magneto      /bin/vmx
21154076 21383447 vcpu-0:Magneto   /bin/vmx
21383454 21383447 vcpu-1:Magneto   /bin/vmx

Reparei que o GID do processo vmx está vinculado ao GID dos processos vinculados a minha máquina virtual, sendo assim executei o comando kill com o GID do processo VMX vinculado a minha máquina virtual.

~ # kill -9 21383447

Um novo ps auxw revelou que os processo haviam sido mortos.

~ # ps ax auxxxx | grep vmx
61545 61545 vmx                  /bin/vmx
61547 61545 vmx                  /bin/vmx
61548 61545 mks:Storm    /bin/vmx
61549 61545 vcpu-0:Storm /bin/vmx
68727 68727 vmx                  /bin/vmx
68729 68727 vmx                  /bin/vmx
68730 68727 mks:Cyclops    /bin/vmx
68731 68727 vcpu-0:Cyclops /bin/vmx

No cliente a máquina Virtual apareceu como desligada na mesma hora. Ao religar a máquina virtual a mesma voltou a responder sem alertas de anormalidade.