VMware PowerCLI no Red Hat 7

Quem usa VMware e está acostumado a usar o PowerCLI mas sempre achou ruim o fato de ser uma ferramenta que só funciona no Windows, essa semana tivemos uma boa noticia: foi disponibilizado como um Vmware Fling o PowerCLI para Linux e Mac OS, o projeto se aproveita do lançamento do powershell core e .net core que a Microsoft lançou esse ano para outras plataformas. Fiz os testes no Redhat e funcionou legal, tive alguns problemas de performance com alguns comandos do PowerCLI, mas a possibilidade de rodar os scripts em Linux já me animou e com certeza usarei. Lembrando que o powershell para Linux ainda não é a versão final, então usem em produção por sua conta e risco 😛
Links:
PowerCli: https://labs.vmware.com/flings/powercli-core
Powershell: https://github.com/PowerShell/PowerShell/releases/

Vou mostrar aqui como instalei no RedHat 7, para instalação no Ubuntu e outros baseados em Debian verifique o pdf de instruções disponíveis no link logo acima. Para instalação via docker segue o link: https://hub.docker.com/r/vmware/powerclicore/ .

O primeiro problema que tive foi na hora de tentar conectar ao Vpshere pelo PowerCli e vi que a versão do libcurl do Redhat tinha algum problema com a conexão ssl, então vamos ver as dependências antes de instalar o que queremos. Usei os seguintes pacotes: libcurl-openssl-7.43.0-1.1.el7 e libcurl-openssl-devel-7.43.0-1.1.el7 , vamos baixa-los:

[root@localhost ~]# wget http://ftp.riken.jp/Linux/cern/centos/7/cern/x86_64/Packages/libcurl-openssl-7.43.0-1.1.el7.cern.x86_64.rpm
[root@localhost ~]# wget http://ftp.riken.jp/Linux/cern/centos/7/cern/x86_64/Packages/libcurl-openssl-devel-7.43.0-1.1.el7.cern.x86_64.rpm

Após baixar, instale os pacotes:

[root@localhost ~]# yum install libcurl-openssl-7.43.0-1.1.el7.cern.x86_64.rpm
[root@localhost ~]# yum install libcurl-openssl-devel-7.43.0-1.1.el7.cern.x86_64.rpm

Normalmente instalará as libs na pasta /opt/shibboleth/lib64/, adicionei a pasta ao $LD_LIBRARY_PATH:

[root@localhost ~]# export LD_LIBRARY_PATH=/opt/shibboleth/lib64/:$LD_LIBRARY_PATH

Agora baixe o PowerCLI_Core.zip aqui: https://labs.vmware.com/flings/powercli-core
e depois baixe a ultima versão do powershell para linux:

[root@localhost ~]# wget https://github.com/PowerShell/PowerShell/releases/download/v6.0.0-alpha.11/powershell-6.0.0_alpha.11-1.el7.centos.x86_64.rpm

Instale:

[root@localhost ~]# yum install powershell-6.0.0_alpha.11-1.el7.centos.x86_64.rpm

Descompacte o PowerCLI_Core.zip, ele deve conter dois arquivos que usaremos: PowerCLI.Vds.4523941.zip e PowerCLI.ViCore.4523941.zip:

[root@localhost ~]# unzip PowerCLI_Core.zip

Vamos para a pasta dos módulos do powershell, se ela não existir será necessário criar, e vamos descompactar os dois arquivos de antes nela:

[root@localhost ~]# cd /root/.local/share/powershell/Modules
[root@localhost ~]# unzip ~/PowerCLI.Vds.4523941.zip
[root@localhost ~]# unzip ~/PowerCLI.ViCore.4523941.zip

Agora já deveremos ter acesso aos comandos do powerCLI, primeiro importe o modulo e então é só começar a brincar. Usei o set-powercliconfiguration para ignorar o erro de certificado não confiável , como informado pelo próprio faq do PowerCLI, como estou apenas testando não tive problema com isso.

[root@localhost ~]# powershell
PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.
PS /root> Get-Module -ListAvailable PowerCLI* | Import-Module
PS /root> set-powercliconfiguration -InvalidCertificateAction Ignore
PS /root> Connect-VIServer -server vsphereserver -User usuario@vsphere.local -Password senha
PS /root> Get-VM

Você também pode rodar os scripts powershell sem precisar abrir o console, que é o queremos não é?, usando o comando: powershell -File nomedoscript.ps1

Fiz um teste com um pequeno script para mostrar os snapshots :

[root@localhost ~]# vim teste.ps1
Get-Module -ListAvailable PowerCLI* | Import-Module
Connect-VIServer -server nomedoservidorvsphere -User usuario@vsphere.local -Password senha
get-vm | get-snapshot | format-list vm,name,description

Agora só executar direto do shell:

[root@localhost ~]# powershell -File teste.ps1

Referências:
https://labs.vmware.com/flings/powercli-core
https://github.com/PowerShell/PowerShell/releases/
http://ftp.riken.jp/Linux/cern/centos/7/cern/x86_64/repoview/letter_l.group.html
https://hub.docker.com/r/vmware/powerclicore/
https://labs.vmware.com/flings/about

PowerCLI Core is now available on Docker Hub!

Anúncios

Apresentando o audit2allow para configurar politicas no SELINUX

O SELINUX é ignorado por muitos, o padrão de muito usuário e até administradores é desabilita-lo logo após instalarem o linux. Eu já fiz muito isso. Mas agora entendo que é uma ferramenta essencial para segurança do sistema e tenho a estudado melhor.
Muitas vezes ele é desabilitado porque acaba bloqueando algum serviço que precisamos. Irei mostrar aqui o audit2allow para uma simples configuração do SELINUX sem precisar desabilita-lo. No exemplo estou usando o Red Hat 7.1.

A primeira coisa é que seu SELINUX não esteja desativado. Ele tem dois modos de operação o permissive e o enforcing, o primeiro irá apenas alertar o que é negado pelas políticas e irá por padrão salvar os logs no arquivo /var/log/audit/audit.log com a tag AVC, o segundo é onde ele vai realmente aplicar as políticas e negar o que tiver que ser negado. O modo permissive é bom para troubleshooting.
Segue abaixo o arquivo de configuração, o parâmetro a ser modificado para esses modos é o SELINUX :

[root@server ~]# cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing – SELinux security policy is enforced.
#     permissive – SELinux prints warnings instead of enforcing.
#     disabled – No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of three two values:
#     targeted – Targeted processes are protected,
#     minimum – Modification of targeted policy. Only selected processes are protected.
#     mls – Multi Level Security protection.
SELINUXTYPE=targeted

Se no seu caso ele tiver desabilitado você deve reiniciar o sistema depois de modificar o arquivo. para visualizar o modo ativo pode usar o comando getenforce e para trocar o modo use setenforce 0 ou setenforce 1 (0 – permissive, 1 – enforcing).

Uma dependência no RedHat é o pacote policycoreutils-python:

[root@server ~]# yum install policycoreutils-python

Vou procurar no audit.log o que está sendo negado pelo SELINUX, usei o grep -A 1 para pegar também a mensagem de SYSCALL relativo ao acesso:

[root@server ~]# cat /var/log/audit/audit.log | grep denied -A 1
type=AVC msg=audit(1475563381.130:444590): avc:  denied  { write } for  pid=12513 comm=”logrotate” name=”www-error.log” dev=”dm-1″ ino=67955370 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:usr_t:s0 tclass=file
type=SYSCALL msg=audit(1475563381.130:444590): arch=c000003e syscall=2 success=no exit=-13 a0=2467650 a1=20002 a2=246e880 a3=7ffe8e234120 items=0 ppid=12511 pid=12513 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=21381 comm=”logrotate” exe=”/usr/sbin/logrotate” subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)

O que é importante verificar nos logs:
{ write } : Aqui é a permissão que está sendo negada, no meu caso foi a de escrita.
comm=”logrotate” : o executável que chamou o processo.
name=”www-error.log” : Aqui pode ser name ou path, é o objeto que o processo está tentando acessar.
scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023: O contexto do processo.
tcontext=system_u:object_r:usr_t:s0 tclass=file: O contexto do objeto(target).
Na na mensagem do SYSCALL temos o seguinte:
success=no : Indica se o SELINUX negou o acesso(no) ou não(yes), quando estiver em permissive provavelmente estará sempre como yes.
exe=”/usr/sbin/logrotate”: O caminho do executável que iniciou o processo.

Após verificar o log posso usar o audit2allow para verificar melhor o porquê de estar sendo negado:

[root@server ~]# grep logrotate /var/log/audit/audit.log | audit2allow -w -a
type=AVC msg=audit(1475563381.130:444590): avc:  denied  { write } for  pid=12513 comm=”logrotate” name=”www-error.log” dev=”dm-1″ ino=67955370 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:usr_t:s0 tclass=file
Was caused by:
Unknown – would be allowed by active policy
Possible mismatch between this policy and the one under which the audit message was generated.

Possible mismatch between current in-memory boolean settings vs. permanent ones.

No caso estou usando o grep para pegar apenas casos relativos ao logrotate, você pode fazer isso para algum processo especifico ou para todos. A opção -a significa que ele irá pegar as informações do audit.log e -w nos dá as informações detalhadas com as possíveis causas.

Agora que temos certeza que queremos liberar esse acesso, usaremos o audit2allow para criar um modulo, este modulo criara as políticas necessárias para liberar o acesso que queremos. Vou apresentar aqui dois exemplos. Nesse primeiro comando estamos gerando um modulo para tudo que estiver no audit.log:

[root@server ~]# audit2allow -a -M MyPolicy

o MyPolicy é o nome da seu modulo.

Nesse segundo exemplo estou filtrando por problemas de acesso apenas do logrotate:

[root@server ~]# grep -i logrotate /var/log/audit/audit.log | audit2allow -M MyPolicy

Após executar um dos comandos será criado dois arquivos com o nome do modulo, um .pp e outro .te

[root@server ~]# ls
MyPolicy.pp  MyPolicy.te

Agora é só instalar nosso modulo no SELINUX:

[root@server ~]# semodule -i MyPolicy.pp

E por fim testar seu acesso e verificar que não está mais sendo bloqueado.

Até a próxima!

Referências:

https://wiki.centos.org/HowTos/SELinux
http://danwalsh.livejournal.com/24750.html