Latest Publications

Alto Consumo de CPU com PowerPath no AIX

Se você utiliza PowerPath em algum ambiente AIX, tome cuidado para não cair em um bug no qual o processo emcp_xcryptd ou emcp_xcr (daemon de criptografia do PowerPath), consome muita CPU no sistema (no meu caso, cerca de 60%).

Esse bug é conhecido e afeta a versão 5.5 do PowePath (emc286557). Abaixo está uma solução de contorno (o ideal é atualizar a versão do PowerPath).

1 – Verifique se você realmente não está usando criptografia em nenhum disco do sistema:

# powervt xcrypt -info -dev all 
hdiskpower0 is not encrypted
hdiskpower1 is not encrypted
hdiskpower2 is not encrypted
hdiskpower3 is not encrypted
hdiskpower4 is not encrypted

2 – Pare o serviço:

# /etc/rc.emcp_xcryptd stop

3 – Desative-o da inittab para que o processo não inicie no próximo boot:

# rmitab rcxcrypt

4 – Em alguns casos, o deamon não é iniciado via inittab e sim através do arquivo de configuração /etc/PowerPathExtensions.

Provavelmente você verá o seguinte conteúdo:

mpxext:cfgmpx 
gpxext 
dmext:cfgdm 
vlumdext:cfgvlumd 
xcryptext:cfgxcrypt

Remova as duas últimas linhas, salve o arquivo e pronto. No próximo reboot o processo não será iniciado.

Atenção: Não comente essas linhas, elas precisam ser realmente removidas. Se você apenas comentá-las, irá fazer com que o PowerPath inicie o daemon, mas ele não irá tentar encriptar os discos durante o boot, por isso é necessário que elas sejam realmente removidas.

 

VMware – Como Converter Disco Virtual IDE em SCSi

Abaixo estão os procedimentos que fiz para converter uma VM Windows 2008 R2 que utilizava discos IDE para SCSI. Discos SCSi além de mas performáticos, ainda possuem a vantagem de expansão online, o que não temos em discos IDE. Se você criou a máquina via P2V (converter) provavelmente o disco padrão é o IDE caso não modifique para SCSI.

1 – Se conecte via SSH em um dos seus servidores ESXi e localize o caminho onde se encontra a máquina virtual no datastore, seguindo o padrão: /vmfs/volumes/<datastore_name>/<vm_name>/

Por exemplo:

~ # find / -name SRV-EXE-01
/vmfs/volumes/508ecc50-f496ca51-32bc-e21f135ad72f/SRV-EXE-01
~ # cd /vmfs/volumes/508ecc50-f496ca51-32bc-e21f135ad72f/SRV-EXE-01

2 – Via SSH no seu ESXi, edite com o “vi” o disco primário (.vmdk) da máquina virtual. Procure a linha:

ddb.adapterType = "ide"

Para alterar o tipo da controladora LSI Logic SAS, altere a linha para:

ddb.adapterType = "lsilogic"

Para alterar o tipo da controladora para BusLogic, altere a linha para:

ddb.adapterType = "buslogic"

No meu caso, usei a padrão LSI

Salve o arquivo.

3 – No vCenter, remova o disco atual IDE:

- Clique em Edit Settings na máquina virtual
- Selecione o disco virtual IDE.
- Escolha "Remove the Disk from the virtual machine".
- Clique em OK.

Cuidado: Cuidado para não escolher Remove from disk.

4 – Adicione novamente o disco, agora como SCSI:

- Clique em Edit Settings desta máquina virtual
- Clique em Add > Hard Disk > Use Existing Virtual Disk.
- Vá até o datastore onde estava o VMDK e escolha adicioná-lo à máquina virtual
- Escolha a mesma controladora do passo 3. A ID do SCSI deve ser SCSI 0:0

Se existir um driver de CD-ROM na máquina virtual, será necessário ajustar o canal IDE dele de IDE 0:1 para IDE 0:0. Se essa opção estiver desabilitada, remova o CD-ROM e adicione novamente, colocando como IDE 0:0.

Em alguns casos, um disco vmdk primário do sistema operacional é definido como IDE, mas outros discos virtuais já adicionados na VM já estão como SCSI. Nesses casos, após a edição vmdk (passo 2), altere o canal SCSI dos discos secundários a fim de liberar o SCSI 0:0 para o disco principal do sistema operacional (faça isso no Edit Settings mesmo). Altere o disco SCSI 0:0 para SCSI 0:1 e, depois, quando você voltar a adicionar o disco do sistema operacional primário à máquina virtual, será possível selecionar SCSI 0:0 para o disco.

Agora é só ligar a máquina!

Como Renomear Discos no PowerPath

Nesse post vou explicar como podemos renomear os “pseudo devices” do PowerPath de acordo com nossa necessidade.

Uma situação em que precisei fazer isso foi em um AIX 5.3 com Oracle RAC e ASM, onde os nomes das LUN estavam diferentes nos dois nós, devido um nó ter mais discos que o segundo, pois haviam alguns filesystems locais na máquina 1. Dessa forma a ordem que o PowerPath encapsulou os discos era diferente e isso dificulta o gerenciamento. Tecnicamente não há problemas, porém podemos manter os mesmos nomes para nos ajudar na gestão dos discos em ambas as máquinas. Vale salientar que eu fiz esse procedimento antes de liberar o device para o DBA usar no ASM, para evitar qualquer problema.

Para esse caso, o PowerPath a partir da versão 5.3 traz um utilitário chamado emcpadm, que só está disponível para Solaris, Linux e AIX.

No meu caso, eu até poderia usar o comando rendev no AIX, mas só está disponível a partir da versão 6.1 do AIX.

1 – Para confirmar sua versão de PowerPath:

powermt version
EMC powermt for PowerPath (c) Version 5.5 P 05 (build 1)

2 – Caso você queira listar os pseudo devices que estão em uso no momento, use o comando abaixo, ele vai mostrar os discos, bem como seu Major e Minor number.

# emcpadm getusedpseudos
PowerPath pseudo device names in use:
Pseudo Device Name      Major# Minor#
        hdiskpower0       41     0
        hdiskpower20      41    20
        hdiskpower21      41    21
        hdiskpower22      41    22
        hdiskpower23      41    23
        hdiskpower24      41    24
        hdiskpower25      41    25
        hdiskpower26      41    26
        hdiskpower27      41    27
        hdiskpower28      41    28

3- Para renomear o hdiskpower0 para hdiskpower29 por exemplo, use o comando abaixo indicando o número do disco e não o pseudo name (s – origem, t – destino):

# emcpadm renamepseudo -s 0 -t 29

4 – Utiliza novamente o comando emcpadm getusedpseudos e note que o hdiskpower0 foi substituído pelo hdiskpower29:

Pseudo Device Name      Major# Minor#
        hdiskpower20      41    20
        hdiskpower21      41    21
        hdiskpower22      41    22
        hdiskpower23      41    23
        hdiskpower24      41    24
        hdiskpower25      41    25
        hdiskpower26      41    26
        hdiskpower27      41    27
        hdiskpower28      41    28
        hdiskpower29      41    29

5 – Confirme diretamente no PowerPath com:

# powermt display dev=hdiskpower29

6 – Importante, salve as configurações com o comando abaixo para atualizar o arquivo powermt.custom

# powermt save

 

Como Instalar Windows 2012 no ESXi 4.1

Eu não trabalho com Windows, porém administro ambientes VMware no dia a dia e abaixo vou passar uma dica que chamo de “Adaptação Técnica”, vulgo gambiarra :P

O VMware ESXi 4.x não suporta oficialmente a instalação do Windows 2012. Se você tentar instalar, verá que não é possível.

Aconselho obviamente que você não faça isso em ambientes de produção:

1 – Crie uma nova máquina virtual

2 – Na opção “Guest Operating System” use “Microsoft Windows Server 2008 R2 (64-bit)”

3 – Antes de ligar sua VM, faça o download desse arquivo de BIOS e faça o upload desse arquivo para o datastore e pasta onde está a nova VM.

4 – Edite o arquivo .vmx da sua nova VM e inclua as linhas abaixo:

bios440.filename = "bios.440.rom"
mce.enable = TRUE
cpuid.hypervisor.v0 = FALSE
vmGenCounter.enable = FALSE

5 – Ligue a VM e você poderá instalar e rodar o Windows 2012.

Se houver alguma dúvida sobre algum dos passos acima, deixe um comentário.

Mac OS X – 2X Client RDP

Como administrador de sistemas Unix / Linux e também de ambientes VMware, não tenho como evitar e preciso conectar também eventualmente em servidores Windows. Eu já utilizei no Mac vários clientes de Remote Desktop para acesso remoto, inclusive da própria Microsoft, porém particularmente o que eu mais me acostumei foi um chamado 2X Client Remote Desktop.

Ele é rápido, estável e possui bons recursos, tais como:

- Gerenciamento de múltiplos servidores;
– Permite salvar as senhas para logins automáticos;
– Permite trocar conteúdo via ctr+c, cmd+v;
– Redirecionamento de dispositivos, como som, discos, etc;
– Trabalha muito bem com fullscreen e faz a troca entre as conexões rapidamente;

Múltiplos Servidores

Múltiplos Servidores

Abaixo as opções para criar uma nova conexão. Um exemplo no meu servidor de testes:

Nova conexão

Nova conexão

Compartilhando meu disco local para troca de arquivos entre as máquinas.

shared devices 1

shared devices 2

shared devices 3

O 2x Client RDP está disponível gratuitamente na própria Mac App Store:

https://itunes.apple.com/br/app/2x-client-rdp-remote-desktop/id600925318?mt=12

Se você conhecer algum outro App para RDP, deixe um comentário.

Mac OS X – Dicas Para Administradores de Sistemas

Nesse post, vou indicar ou até mesmo escrever uma série de dicas com intuito de falar sobre aplicativos que uso no meu Mac que podem facilitar a vida de quem é administrador de sistemas. No mundo Windows nós temos várias opções conhecidas, porém no OS X as opções com de boa qualidade não são tão fáceis de encontrar. Algumas pessoas me pedem indicações de apps com esse objetivo, dessa forma resolvi escrever esses posts para ajudar.

Esse post “MAC OS X – Dicas Para Administradores de Sistemas” será uma espécie de índice e a medida que vou escrevendo mais posts sobre os aplicativos eu vou atualizando esse aqui fazendo referência aos posts individuais.

Qualquer dúvida, deixe um comentário.

Índice

1 – ZOC Terminal
2 – 2X Client Remote Desktop
3 – TextWrangler

 

Mac OS X – ZOC Terminal

ZOC é um cliente profissional de telnet/SSH e também um emulador de terminal poderoso. Possui uma lista muito grande de emuladores de terminais e permite que você se conecte usando vários métodos de conexão, como vt102, vt220 e vários tipos de ANSI não apenas alguns como TN3270, TN5250, Wyse, TVI e Suns CDE.

Ele possui alguns recursos interessantes:

- Suporte a protocolos de transferência de arquivos, como SCP, X-, Y-, Z-modem e Kermit;
– Permite enviar comandos para todas as suas conexões abertas simultaneamente;
– Possui uma linguagem de automação de tarefas com mais de 200 comandos possíveis;
– Permite salvar suas senhas para conexões automáticas (mesmo que ele tenha que passar por algum servidor antes como gateway);
– Possui diversos tipos de configuração de layouts, alterações nas cores, fontes, tipos de teclados, atalhos, entre outros.

Essa é a cara do ZOC Terminal

Essa é a cara do ZOC Terminal

 

Customizações do ZOC

Customizações do ZOC

 

Vamos supor que você precise criar um perfil para se conectar automaticamente ao servidor SRV01 que possui o IP 192.168.1.20, porém você precisa passar pelo servidor 192.168.1.10 antes como ponte. Nesse caso, vamos em Host Directory e criaremos uma nova entrada. Depois de atribuir os títulos, tipos de conexão desejada, vá para a aba Login e coloque o usuário e senha do servidor de ponte (192.168.1.10). Em AutoLogin Sequence você irá criar as entradas para a nova conexão, usando os comandos do ZOC Terminal.

Send=ssh root@192.168.1.20 ^M
Wait=password:
Send=teste123^M

Send = Envio de comandos (a sequência ^M serve para indicar um enter, ou seja, fim da linha).
Wait= Se ele encontrar a saída configurada em Wait no shell, ele emitirá o próximo comando

Host Directory

Host Directory

Captura de Tela 2014-04-08 às 11.47.17

Captura de Tela 2014-04-08 às 11.47.43

O ZOC também permite conexões rápidas, por exemplo, estou me conectando ao meu terminal local.

Quick Connection

Quick Connection

Quick Connection

O seu grande problema é que não é gratuito, pelo contrário, é um valor considerável para um cliente de acesso remoto, porém ele é vendido direto em promoções (bundles) por aí. Basta fazer umas pesquisas que você encontra ele com preço bem mais acessível.

Configurar Interface VLAN no Red Hat / CentOS

Para configurar (“taguear”) uma VLAN numa interface no Linux, podemos usar os seguintes passos, que foram todos homologados em um Red Hat Enterprise 6.

1 – Primeiramente, garanta que o módulo responsável (802.1q) esteja carregado no Kernel, caso contrário, será necessário carregar:

[root@lab01 ~]# lsmod | grep 8021q
[root@lab01 ~]# modprobe 8021q
[root@lab01 ~]# lsmod | grep 8021q
8021q 25317 0
garp 7152 1 8021q

2 – Para que a configuração do módulo fique permanente ao boot, é necessário criar um arquivo com permissão de executável dentro do /etc/sysconfig/modules/*.modules, da seguinte forma:

# echo "modprobe 8021q" > /etc/sysconfig/modules/vlan.modules
# chmod +x /etc/sysconfig/modules/vlan.modules

3 – Vamos configurar a interface física que iremos taguear a VLAN, no meu exemplo a interface eth2 (/etc/sysconfig/network-scripts/ifcfg-eth2):

DEVICE=eth2
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes

4 – Agora vamos configurar a interface VLAN, que deve possuir o nome da interface física acrescentando um “.” e o número da VLAN, ou seja, no meu caso vamos configurar a VLAN 250 na eth2. Dessa forma criaremos o arquivo /etc/sysconfig/network-scripts/ifcfg-eth2.250 com o seguinte conteúdo (obviamente configurando com o seu endereçamento necessário):

DEVICE=eth2.250
BOOTPROTO=none
ONBOOT=yes
IPADDR=10.0.200.10
NETMASK=255.255.255.0
USERCTL=no
VLAN=yes

Se for necessário configurar uma outra VLAN na mesma interface física, por exemplo a VLAN 190, adicione um novo arquivo chamado ifcfg-eth2.190 com os detalhes de configuração necessárias.

5 – Reinicie os serviços de redes:

# service network restart

6 – Use o comando ifconfig para confirmar as configurações e caso queira obter informações detalhadas sobre as VLANs, visualize os arquivos localizados em /proc/net/vlan:

[root@lab01 vlan]# cat /proc/net/vlan/eth2.250
eth2.250 VID: 250 REORDER_HDR: 1 dev->priv_flags: 1
 total frames received 0
 total bytes received 0
 Broadcast/Multicast Rcvd 0

total frames transmitted 12
total bytes transmitted 720
total headroom inc 0
total encap on xmit 0
Device: eth2
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESS priority mappings:

7 – Caso não queira reiniciar o serviço de rede para validar as configurações, ao fim de tudo você pode subir manualmente as interfaces usando:

# ifup eth2
# ifup eth2.250

Existe também o comando vconfig para gerenciar manualmente as VLANs, caso queira mais informações: man vconfig ;)

ESXi – Como Quebrar Senha de Root

Nos casos de ambientes que utilizam o ESX, o processo para quebrar a senha de root é o mesmo que nos sistemas Linux tradicionais, porém quando é utilizado ESXi, oficialmente a VMware informa nos KBs de que a quebra da senha não é suportado.

Abaixo a explicação de como reiniciar a senha no ESX e a posição oficial da VMware sobre os ESXi:

http://kb.vmware.com/kb/1317898

Como visto, é indicado a reinstalação do ESXi para reiniciar a senha. Caso você não queira reinstalar, pode seguir os passos abaixo que funcionam tranquilamente:

Inicie o servidor utilizando um live CD de alguma distribuição qualquer ou como no meu caso, iniciei usando o modo Rescue da mídia do Red Hat.

Precisamos agora montar a partição onde se encontra o arquivo state.tgz, normalmente estará na partição /dev/sda5 (utilize o fdisk -l para verificar a tabela de partição)

# fdisk -l
# mkdir /mnt/sda5
# mount /dev/sda5 /mnt/sda5

Já vi relatos de máquinas HP montarem da seguinte forma:

# mount /dev/cciss/c0d0p5 /mnt/sda5

c0d0p5: controladora 0, disco 0, partição 5

Siga os seguintes passos (precisamos abrir o arquivo shadow):

# cd /mnt/sda5
# cp state.tgz /tmp/state.tgz
# cd /tmp
# tar zxf state.tgz
# tar zxf local.tgz
# cd etc

Edite agora o arquivo shadow (vi shadow) e remova o hash da senha criptografada do root (é o segundo campo separado pelos “:”)

De:

root:$1$ywxtUqvn$9e1iXjGVd45T5IAgRxAuV.:13358:0:99999:7:::

Para:

root::13358:0:99999:7:::

Salve o arquivo shadow e vamos agora fazer o processo contrário (voltando ao tmp, copiando o arquivo alterado para o disco):

# cd ..
# tar czvf local.tgz etc
# tar czvf state.tgz local.tgz
# cp state.tgz /mnt/sda5/state.tgz
# shutdown -r now

Quando o ESXi inciar, a senha de root estará vazia!

Linux – O Que São Major e Minor Numbers

Fazendo uma pesquisa para entender a teoria do assunto, lendo documentações a respeito, cheguei a uma conclusão que compartilho aqui. Qualquer observação, deixe um comentário.

Em sistemas UNIX, todos os dispositivos de hardware são basicamente arquivos, onde eles podem ser abertos, fechados, lidos e escritos usando os mesmos comandos de sistemas que são usados para manipulação de arquivos comuns. Para escrever em um disco, você escreve em um arquivo. Para gravar backups em um dispositivo de fita (Tape), você também está escrevendo em um arquivo e assim sucessivamente. Se o arquivo que você está tentando ler ou escrever é um arquivo normal, o processo é bem simples: o arquivo é aberto e você pode ler ou gravar dados. Já se o dispositivo que você quer acessar é um arquivo de dispositivo especial, existe uma etapa que precisa ser feita pelo Kernel antes dele realmente realizar a operação de leitura ou escrita.

Um ponto fundamental para que possamos compreender os arquivos de dispositivos é que diferentes dispositivos se comportam obviamente de forma diferente, ou seja, eles possuem funções e objetivos diferentes. Claro que não há teclas em um disco e nenhum setor em um teclado, por exemplo. Dessa forma, o sistema precisa de um processo pelo qual ele possa diferenciar entre os vários tipos de dispositivos e saber exatamente como tratá-lo.

Dentro do kernel, há funções para cada um dos dispositivos que ele vai acessar. Todas essas funções e rotinas combinados de um dispositivo específico, são conhecidas como um driver. Cada dispositivo no sistema tem seu próprio driver. Dentro de cada driver existem funções que são usadas para acessar o dispositivo. Para dispositivos como discos ou terminais, o sistema tem de ser capaz de (entre outras coisas) de abrir e escrever no dispositivo, ler a partir dele e saber como fechá-lo.

O kernel não só precisa saber qual o tipo de dispositivo está sendo acessado, mas também precisa saber de qualquer informação especial para que possa gerênciá-lo, como o número da partição, se é um disco ou um terminal por exemplo, entre outros. Isso é conseguido através do major e do minor number. Todos os dispositivos controlados pelo mesmo driver tem o mesmo major number em comum. Os minor number são usados para diferenciar os dispositivos específicos em si. Uma vez que o kernel determinou o tipo de dispositivo que ele está acessando, ele determina o dispositivo físico específico, o local específico que ele está conectado e outras características de controle do dispositivo por meio de um minor number.

Vamos ver o exemplo usando dispositivos SCSI:

O formato de identificação dos discos então, é definido da seguinte forma:

/dev/sd<driver><partição>

Onde sd significa que trata-se de um dispositivo SCSI, <driver> é a letra que faz referência ao dispositivo físico e <partição> é o número da partição. Sem o número da partição estamos no referindo ao disco inteiro, ex.: /dev/sda.

O major number de todo dispositivo SCSI será sempre 8 e o minor number é sempre múltiplo de 16, começando em 0. Quando é uma partição, o minor number vai incrementando um a um a partir do minor number do disco todo. Exemplificando, observe a saída a seguir.

[fsavoia@rhel-lab ~]$ ls -l /dev/sd*
brw-rw----. 1 root disk 8, 0 Jan 12 16:02 /dev/sda
brw-rw----. 1 root disk 8, 1 Jan 12 16:02 /dev/sda1
brw-rw----. 1 root disk 8, 2 Jan 12 16:02 /dev/sda2
brw-rw----. 1 root disk 8, 16 Jan 12 16:02 /dev/sdb
brw-rw----. 1 root disk 8, 17 Jan 12 16:02 /dev/sdb1
brw-rw----. 1 root disk 8, 32 Jan 12 16:02 /dev/sdc
brw-rw----. 1 root disk 8, 33 Jan 12 16:02 /dev/sdc1
brw-rw----. 1 root disk 8, 34 Jan 12 16:02 /dev/sdc2
brw-rw----. 1 root disk 8, 48 Jan 12 16:02 /dev/sdd

Como explicado anteriormente, o major number sempre será 8 para dispositivo SCSI. Para o minor number, repare que os discos são sempre múltiplos de 16: /dev/sda (minor 0), /dev/sdb (minor 16), /dev/sdc (minor 32) e /dev/sdd (minor 48). As partição são incrementadas uma a uma: /dev/sda1 (minor 1), /dev/sda2 (minor 2), /dev/sdb1 (minor 17), /dev/sdc1 (minor 33) e /dev/sdc2 (minor 34).

Os números de major e minor vão de 0 até 2^8 (256), no caso de dispositvos SCSI (dispositivos SATA usam o mesmo driver), podemos ter até 16 dispositivos em uma única controladora SCSI, assim é feita a divisão do número total por 16, por isso observa-se os discos sempre no intervalo de 16 minors. No caso de dispositivos IDEs, somente podemos ter 4 dispositivos por controladora, assim veremos os minors dos dispositivos sempre variando no intervalo de 64 minors (256/4).

No Linux, existe o arquivo /proc/devices, que mostra a lista (separada inclusive) de arquivos de caracteres e de bloco atualmente reconhecidos pelo kernel (não inclui dispositivos em que os módulos não estão carregados).

Exemplo da saída resumida:

Character devices:
 1 mem
 4 /dev/vc/0
 4 tty
 4 ttyS
 5 /dev/tty
 5 /dev/console
 5 /dev/ptmx
 7 vcs
 10 misc
 13 input
 14 sound
 21 sg
Block devices:
 1 ramdisk
259 blkext
 7 loop
 8 sd
 9 md
 11 sr
253 device-mapper
254 mdp

Dispositivos de caracteres e de blocos são bem similares, porém tem uma diferença fundamental:

Os arquivos de caracteres não necessitam de buffer. As requisições para os dispositivos de caractere são tratadas imediatamente. Os arquivos de caracteres também enviam dados sem tamanhos pré-configurados, diferentes dos dispositivos de blocos, que podemos enviar e receber informações em blocos de tamanho configurados por dispositivo. Os dispositivos de blocos trabalham com um buffer cache disponível, permitindo que ele ordene as requisições em memória antes de endereça-las ao disco físico  efetivamente. Isso é importante para dispositivos que trabalham com armazenamento, como os discos, pois isso permite melhor performance. Os dados também podem ser acessados ramdomicamente, ou seja, qualquer bloco pode ser acessado ou escrito no importa aonde ele esteja no disco.

Se alguém quiser colocar algum ponto ou discordar de algo, fique a vontade para comentar.