Ativando o SNMP no VMware 5.0

Ativar o snmp no hosts que compõe o cluster de estrutura no vmware:

SNMP v1 Configurations:

There are 4 steps:

1. Set the community string
2. Set the SNMP target which includes the port and the community string
3. Enable SNMP service on the ESXi host
4. Validate SNMP configuration by performing a test operation

esxcli system snmp set –communities public
esxcli system snmp set –targets pod23-esx-01a.pml.local@161/public
esxcli system snmp set –enable true
esxcli system snmp test

Agora é só verificar de um sistema unix/linux e que tenha o utilitário snmpwalk instalado, rode o comando como descrito abaixo para visualizar toda a árvore MIB do protocolo SNMP V1.

snmpwalk -v1 -c public pod23-esx-01a.pml.local

fonte: http://blogs.vmware.com/vsphere/2012/11/configuring-snmp-v1v2cv3-using-esxcli-5-1.html

SystemD v197 Renomeará Interfaces

Os desenvolvedores do freedesktop.org simplesmente decidiram que vão renomear todas as interfaces de rede do seu sistema operacional.

Sua interface é chamada de eth0 normalmente, porém após o boot a minha interface se chamava enp0s3. Ou seja, após a instalação eu tive que reconfigurar todos os arquivos que referenciavam o nome eth0.

Não afirmo com certeza, mas é bem provável que logo após um update e um reboot no seu desktop todas as comunicações de rede irão cessar, pois a interface eth0 não irá mais existir. Qual a melhor parte? Você não terá acesso a internet para consultar uma possível solução, você estrá por sua própria conta e risco

Baseado na explicação do site freedesktop.org a nova nomenclatura se baseia nas seguintes informações:

• Índices do Firmware/BIOS providos pelos dispositivos on-board (exemplo: eno1);
• Número do slot provido pelo Firmware/BIOS do barramento PCI Express (exemplo: ens1);
• Localização física/geográfica do conector de hardware (exemplo: enp2s0);
• Endereço MAC do dispositivo (exemplo: enx78e7d1ea46da);
• Em último caso, numeração sequencial clássica provida pelo kernel (exemplo: eth0).

E qual a vantagem de tudo isso? Isso é o que eles alegam:

• Nomes constantes mesmo após reboots;
• Nomes constantes mesmo após a substituição das placas ou remanejamento de slots;
• Nomes de interface estáveis mesmo após atualizações e mudanças de Kernel e/ou drivers;
• Nome de interface estáveis mesmo que você substitua uma interface defeituosa;
• Os nomes são determinados automaticamente sem a configuração do usuário;
• Os nomes de interface são totalmente previsíveis, por exemplo, apenas olhando pelo lspci você pode deduzir como a interface irá se chamar;
• Operações totalemente stateless, mudanças de hardware não resultarão em mudanças no /etc;
• Compatibilidade com permissões de apenas-leitura;
• Os nomes de interface agora são mais condizentes com os alias dos dispositivos de bloco e o no /dev;
• Aplica-se em todas as as arquiteturas, x86 e non-x86;
• Nomeclatura consistente para todos os sistemas que adotam o SystemD/Udev;

Desabilitando

Bem, se você usa o Arch Linux ou qualquer outra distribuição que se utiliza do SystemD e não gostou desta alteração ela pode ser facilmente revertida. Basta utilizar o seguintes comando:

ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

Montar partições LVM usando um Ubuntu Live

Montando o disco LVM usando um Ubuntu Live

Em primeiro lugar ache qualquer distribuição live que você goste, eu utilizarei para o exemplo o Ubuntu. Mas se você for utilizar outra distribuição será parecido, a exceção da manipulação dos pacotes.

Então vamos ao que realmente interessa:

1. Com o Linux rodando (o live linux lembra?), digite
   

   1

   sudo –s

   2	# apt-get install lvm2

   Se não tiver reconhecido a rede você pode procurar no cd/usb pelo pacote e instalar manualmente.
2. Para ter certeza que o disco foi reconhecido
   

   1	# sfdisk –l

3. Depois disso vamos rodar o pvscan para procurar em todos os disco por volumes físicos. Com isto teremos certeza que o disco LVM foi detectado.
   

   1

   # pvscan

   O resultado será como abaixo.

PV /dev/sdb2   VG VolGroup02   lvm2 [465,66 GB / 0    free]
PV /dev/sda2   VG VolGroup01   lvm2 [7,41 GB / 0    free]
Total: 2 [473,06 GB] / in use: 2 [473,06 GB] / in no VG: 0 [0   ]

1. Agora iremos rodar o vgscan para procurar por volume groups.
   

   1

   # vgscan

   Reading all physical volumes.  This may take a while...
   Found volume group "VolGroup02" using metadata type lvm2
   Found volume group "VolGroup01" using metadata type lvm2

2. Hora de ativar todos os volumes disponíveis.
   

   1	# vgchange –a y

2 logical volume(s) in volume group "VolGroup02" now active
2 logical volume(s) in volume group "VolGroup01" now active

1. E o último passo é rodar o lvscan para procurar volumes lógicos. Você verá as partições ativas dentro do HD.
   

   1

   # lvscan

   ACTIVE            '/dev/VolGroup02/LogVol00' [463,69 GB] inherit
   ACTIVE            '/dev/VolGroup02/LogVol01' [1,97 GB] inherit
   ACTIVE            '/dev/VolGroup01/LogVol00' [5,44 GB] inherit
   ACTIVE            '/dev/VolGroup01/LogVol01' [1,97 GB] inherit

2. O último passo é criar o ponto de montagem, e montar os discos.
   

   1	mkdir /media/disk0

   2	mkdir /media/disk1

   3	mount /dev/VolGroup00 /media/disk0

   4	mount /dev/VolGroup01 /media/disk1

Pronto com isso já podemos utilizar os discos normalmente e mexer com os dados, pacotes e arquivos que quisermos.

Obs.: Quando fui mexer com os HDs tive um problema por ter utilizado o particionamento padrão doCentOS. Quando dei o comando pvscan os dois HD possuiam o volume group igual. Com isso não daria para usar os dois ao mesmo tempo. Se você tiver esse problema faça o seguinte:

1. Rode o comando vgdisplay para descobrir o UUID de cada volume group.
   

   1

   vgdisplay

2. Agora vamos rodar o comando vgrename para alterar o nome de um deles. O UUID que utilizarei aqui é apenas um exemplo, altere conforme a sua necessidade.
   

   1	vgrename uUUSjr-mTzO-XSYW-2jlC-aAL3-QcuX-nODtu9 VolGroup00

Pronto agora quando seguir o procedimento a partir do terceiro (ou seria quarto) passo, tudo dará certo. Só não esqueça de no final do processo, desmontar o HD e alterar o nome do volume grouppara o nome original, que no meu caso era VolGroup01, para que a inicialização ocorra normalmente, senão durante o processo do boot você recebera a mensagem de Kernel Pa

Qual o melhor tipo de disco virtual no VMWare

Quando criamos uma nova maquina virtual ou apenas adicionamos um novo HD virtual a uma máquina na hora da criação temos 3 opções de disco:

Thick Provision Lazy Zeroed;
Thick Provision Eager Zeroed;
Thin Provision.

Primeiro vamos entender o “Zeroed”.

Zeroing – Esse processo sobrescreve todos os dados do disco criado com zeros dessa forma garante que não haja dados escritos no disco e ele pode ocorrer em dois momentos, na criação do disco ou no momento da primeiro escrita no espaçõ não alocado.

Inicialmente vamos dividir os tipos em dois, o Thick e o Thin, essa escolha interfere na economia de disco e também no desempenho.

O Thin – Cria o disco apenas com o espaço utilizado ou seja se você criar um disco de 100 GB e utilizar apenas 10 GB o disco ocupará 10 GB no seu storage e o zeroing ocorre no momento da gravação.
O Thick – Ocupa o espaço total determinado na criação do disco no database e temos dois tipos:
Thick Lazy Zeroed – É o padrão quando criamos um novo disco, ele ocupa o espaço do disco mas o zeroing ocorre apenas na hora da escrita.
Thick Eager Zeroed – Esse tipo faz o zeroing na criação do disco, ela é a mais demorada mas é a mais recomendada para discos que terão muito I/O.

Notas

1 – O Thick Provision Eager Zeroed é o disco mais rápido utilizado principalmente para banco de dados;
2- O Thick Provision Lazy Zeroed e o Thin Provision são mais lentos pois o zeroing ocorre no momento da gravação mas depois que o disco esta totalmente preenchido o zeroing não mais afetará o desempenho e os discos terão praticamente a mesma performance.

Resetando Senha do MYSQL

 

Resetar senha do user root no mysql – linux

Hoje precisei resetar a senha do root no mysql. Como eu tenho acesso root ao servidor linux, foi mais fácil do que pensei que seria.

Vamos aos passos, considerando que a distro seja slackware:

1 – parar o mysql: sh /etc/rc.d/rc.mysql stop

2 – iniciar o mysql com –skip-grant-tables: mysqld_safe –skip-grant-tables

3 – acessar o mysql sem senha: mysql -u root

4 – acessar o banco mysql: use mysql;

5 – alterar a senha do root:  UPDATE user SET PASSWORD = password(‘nova_senha’) WHERE user = ‘root’ LIMIT 1;

obs: sempre uso o LIMIT 1 pra ter certeza que não vou afetar nenhum registro caso cometa algum erro de digitação.

6 – Atualizar os privilegios: FLUSH PRIVILEGES;

7 – Sair do mysql: quit

8 – Reinicie o Mysql: sh /etc/rc.d/rc.mysql restart

Pronto.

Proxy ARP

Durante o início da configuração de um swicth powerconnect 6224, me deparei com a seguinte pergunta: "Porque o Proxy ARP vem habilitado por padrão ?", procurando na Net a resposta descobri um post no endereço: http://www.comutadores.com.br/switches-hpn-a7500-proxy-arp/, que esclareceu um pouco sobre a necessidade do Proxy ARP que vem habilitado por padrão.

Para aqueles que não conhecem a feature, o exemplo será bastante esclarecedor.

No desenho abaixo a empresa X possui as subredes 10.100.1.0/24, 10.200.1.0/24 e 10.30.1.0/24. O Roteamento entre as VLANs é efetuado no Switch Core.

Reparem que o IP do Mainframe está correto dentro do range da VLAN 1, mas o equipamento por ser antigo, não permite alterarmos a mascará de rede!!!

Nesse caso, mesmo com a configuração do Gateway corretamente no Mainframe apontando para o Switch Core, a comunicação do equipamento com as redes 10.200.1.0/24 e 10.30.1.0/24 nunca será encaminhado para o Gateway da VLAN 1 pelo fato da mascara no MainFrame deixar explicito que as subredes fazem parte da mesma rede dele.

Obs: Toda comunicação entre hosts de subredes diferentes é encaminhado para o Gateway

Para a comunicação entre dispositivos da mesma subrede, é encaminhado em Broadcast uma mensagem ARP Request. Então, se o MainFrame quiser comunicar com a máquina da VLAN 300 com o endereço IP 10.30.1.25, ele encaminhará uma requisição ARP questionando qual o endereço MAC do IP solicitado( o MainFrame pensa que o host está na mesma subrede que ele).

Como a principal função do Switch Core, é isolar domínios de Broadcast, a mensagem será ignorada por todos os dispositivos da VLAN 1, incluindo o gateway.

Com o Proxy ARP habilitado no Gateway (Interface VLAN 1 do Switch Core), o Switch responderia a solicitação em nome do host 10.30.1.25, mas com o endereço MAC da Interface VLAN 1; e encaminharia o quadro corretamente para o host desejado( encaminhando o ARP request com o endereço 10.30.1.25 na VLAN3 questionando o endereço MAC do host).

Configurando

interface VLAN 1
ip address 10.100.1.1 255.255.255.0
proxy-arp enable
! habilitando o Proxy ARP na Interface VLAN 1