Recentemente a Red hat lançou o Satellite 6.2 GA, um produto que ganhou grandes melhorias e novas funcionalidades.

img1

O Satellite se tornou um produto essencial para gerenciamento de ciclo de vida de sistemas da Red Hat em ambientes de nuvem físicas, virtuais, privadas e públicas. A ferramenta apresenta implementação remota e estende a capacidade de gestão de pacotes, configurações, máquinas virtuais, containers, segurança entre grandes outras funcionalidades.

Uma das funcionalidades mais interessante dessa nova versão e o Remote Execute e Job Scheduling utilizando ssh. Agora será possível agenda execuções remotas em todos hosts. O OpenSCAP utilizado para auditoria de segurança, agora já vem instalado junto com o Satellite 6.2, antes precisava ser instalado manualmente. Melhorias no console web ficou notório, também percebi que a interface web está mais rápida.

Então amigos administradores de RHEL/CentOS, se você utiliza o Red Hat Satellite 5 e está pensando em implementar o Satellite 6, pode iniciar sua jornada, o Satellite 6.2 GA está finalmente atingindo o nível de maturidade necessária para gerir ambientes de pequeno e grande porte.

Migração

Atualmente estou utilizando a versão 6.1 e abaixo vou listar os passos e dificuldades encontradas no meu ambiente para migração do 6.2 GA.

Não será possível realizar migração de 6.2 Beta para 6.2 GA, antes de iniciar a migração para 6.2 verifique se seu ambiente está atualizado e com a versão 6.1.9. Não se esqueça de realizar o backup do ambiente atual.

Verificando se existe alguma atualização recente. Desabilite todos repositórios, deixe apenas os seguintes habilitado:

# subscription-manager repos --disable=*
# subscription-manager repos --enable=rhel-7-server-rpms
# subscription-manager repos --enable=rhel-7-server-satellite-6.1-rpms
# yum update

Caso atualize o kernel será necessário reiniciar o sistema

Após o update do S.O e dos novos pacotes, o satellite já estará com a versão 6.1.9, execute o seguinte comando para finalizar:

# katello-installer --upgrade

Upgrading...
Upgrade Step: stop_services...
Upgrade Step: start_mongo...
Upgrade Step: migrate_pulp...
Upgrade Step: start_httpd...
Upgrade Step: migrate_candlepin...
Upgrade Step: migrate_foreman...
Upgrade Step: Running installer...
Installing Done   [100%] 

[......................................................]
  The full log is at /var/log/katello-installer/katello-installer.log
Upgrade Step: restart_services...
Upgrade Step: db_seed...
Upgrade Step: errata_import (this may take a while) ...
Upgrade Step: update_gpg_urls (this may take a while) ...
Upgrade Step: update_repository_metadata (this may take a while) ...
Katello upgrade completed!

Vamos realizar um check antes de realizar a migração para o 6.2.

# foreman-rake katello:upgrade_check

This script makes no modifications and can be re-run multiple times for the most up to date results.
Checking upgradeability...

Checking for running tasks...
[FAIL] - There are 35 active tasks.

Checking the current version...
[PASS] - Current version of the Katello Ruby RPM is 2.2.0.92 and needs to greater than or equal to 2.2.0.90

Checking content hosts...
Calculating Host changes on upgrade.  This may take a few minutes.


Summary:
Content hosts to be preserved: 169
Content hosts to be deleted: 3
Details on Content Hosts planned for deletion saved to /tmp/pre-upgrade-1471033031.csv
You may want to manually resolve some of the conflicts and duplicate Content Hosts.
Upon upgrade those found for deletion will be removed permanently.

Como podemos ver minha migração apresentará falha “ [FAIL] - There are 35 active tasks.” Resolvendo active tasks provável lock, podemos ir manualmente na Web gui Monitor->Tasks e filtrar pelas tasks que estão em lock, assim executando manualmente os skip, também podemos identificar pelo hammer.

Apresenta um resumo das tasks em pausa

# hammer task resume --search "state=paused"

Apresenta todas tasks em pausa

# hammer task list --search "state=paused"

Removendo tasks em lock pelo foreman-rake

# service foreman-tasks stop  
# foreman-rake console

irb(main):001:0> ForemanTasks::Task.where(:state => :planned).where(:label => "Actions::Katello::Repository::Sync").destroy_all
irb(main):002:0> ForemanTasks::Task.where(:state => :planned).where(:label => "Actions::Katello::System::GenerateApplicability").destroy_all
irb(main):003:0> ForemanTasks::Task.where(:state => :paused).where(:label => "Actions::Katello::Repository::Sync").destroy_all
irb(main):004:0> ForemanTasks::Task.where(:state => :paused).where(:label => "Actions::Katello::System::GenerateApplicability").destroy_all
irb(main):005:0> ForemanTasks::Task.where(:label => "Actions::Candlepin::ListenOnCandlepinEvents").destroy_all

Caso nescessário remova a task pelo id
irb(main):001:0> ForemanTasks::Task.find("799bc5fb-2d4c-4d0d-9d7d-4e42e9a8ace8").destroy

Saindo do Foreman rake
irb(main):002:0> exit
# service foreman-tasks start 

Reindexando o banco de dados para evitar futuras inconsistências

# foreman-rake katello:reindex
# katello-service restart

Executando novamente o upgrade_check podemos notar que as pendência de tasks foram solucionadas.

# foreman-rake katello:upgrade_check

This script makes no modifications and can be re-run multiple times for the most up to date results.
Checking upgradeability...

Checking for running tasks...
[PASS] - There are 0 active tasks.

Checking the current version...
[PASS] - Current version of the Katello Ruby RPM is 2.2.0.92 and needs to greater than or equal to 2.2.0.90

Checking content hosts...
Calculating Host changes on upgrade.  This may take a few minutes.


Summary:
Content hosts to be preserved: 169
Content hosts to be deleted: 3
Details on Content Hosts planned for deletion saved to /tmp/pre-upgrade-1471269446.csv
You may want to manually resolve some of the conflicts and duplicate Content Hosts.
Upon upgrade those found for deletion will be removed permanently.

Iniciando processo de upgrade 6.2

Desabilitar repositório Satellite 6.1

# subscription-manager repos --disable rhel-7-server-satellite-6.1-rpms

Habilitando repositórios necessário

# subscription-manager repos --enable rhel-7-server-satellite-6.2-rpms

# subscription-manager repos --enable=rhel-server-rhscl-7-rpms

Parando serviço

# katello-service stop

Limpando cache yum

# yum clean all

Upgrade de todos pacotes do sistema

# yum update

Upgrade do ambiente satellite

# satellite-installer --scenario satellite --upgrade

Nessa etapa acima encontrei um erro de migração que estava relacionado a ambiente puppet orfão, caso ocorra um erro parecido, tente remove o ambiente puppet informado na msg e execute o comando novamente.

foreman-rake katello:upgrades:3.0:update_puppet_repository_distributors Updating Puppet Repository Distributors Updating Content View Puppet Environment Distributors rake aborted! ForemanTasks::TaskError: Task 541787f6-ad56-449a-be6f-1b2001fc3538: Katello::Errors::PulpError: PLP0034: The distributor Library-ccv_rhel72_puppet-jboss indicated a failed response when publishing repository Library-ccv_rhel72_puppet-jboss.

Iniciando serviço

# katello-service start

Verificando serviço

# hammer ping
candlepin:
Estado:          ok
Server Response: Duration: 19ms
candlepin_auth:
Estado:          ok
Server Response: Duration: 23ms
pulp:
Estado:          ok
Server Response: Duration: 66ms
foreman_tasks:
Estado:          ok
Server Response: Duration: 882ms

Verique também na interface web se todos os serviços estão ok, na aba Administer->About

Caso ao logar na interface Web, apresente um erro de “undefined method `label' for nil:NilClass” atualize o pacote tfm-rubygem-katello e reinicie o serviço. (https://bugzilla.redhat.com/show_bug.cgi?id=1361793)

img2

# rpm -Uvh tfm-rubygem-katello-3.0.0.73-1.el7sat.noarch.rpm
# katello-service restart

img3

Upgrade Client Satellite 6.2

Desabilite repositório antigo

# subscription-manager repos --disable rhel-7-server-satellite-tools-6.1-rpms

Habilite novo repositório

# subscription-manager repos --enable=rhel-7-server-satellite-tools-6.2-rpms

Realize upgrade do katello-agent

# yum upgrade katello-agent

Referencias:

Uma das demandas que executo diariamente está relacionado a expansão de disco em máquinas virtuais. Muitas vezes a máquina não pode ser reiniciada e todo procedimento precisa ser executado em produção.

Sempre execute um snapshot da VM antes de executar os procedimentos abaixo.

Primeiro passo temos que aumentando nosso disco, no Vmware.

Selecione a VM no seu vSphere depois, vá em “Edit Settings”, selecione o “Virtual Disk” que deseje aumentar. No meu caso aumentarei 20G.

Verificando as partições do sistema:

# df -h

FilesystemSize  Used Avail Use% Mounted on
/dev/mapper/vg_web01-lv_root 45G  1.5G   42G   4% /
tmpfs 1.9G 0  1.9G   0% /dev/shm
/dev/sda1 477M   78M  374M  18% /boot

Partição que sera expandida (/dev/mapper/vg_web01-lv_root)

Todo procedimento será realizado com a VM ligada e a partição montada.

Vamos agora realizar um procedimento para que o seu Linux reconheça o novo espaço adicionado sem precisar do reboot.

# ls /sys/class/scsi_device/
0:0:0:0    2:0:0:0 
# echo 1 > /sys/class/scsi_device/0\:0\:0\:0/device/rescan

No meu caso tenho duas controladoras e meu disco se encontra na primeira. Pronto agora quando for executar o cfdisk ou fdisk você já consegue visualizar o espaço adicionado no Vmware, no meu caso foi criado o /dev/sda3.

Caso seja um novo Virutal Disk, execute os comando abaixo para identificar o novo device no seu ambiente sem precisar realizar o reboot.

Buscando host bus number
# grep mpt /sys/class/scsi_host/host?/proc_name
/sys/class/scsi_host/host0/proc_name:mptspi

Execute o comando abaixo no host encontrado
# echo "- - -" > /sys/class/scsi_host/host0/scan

Vamos utilizar o cfdisk para criar uma nova partição com o espaço disponível do tipo LVM(8e)

# cfdisk /dev/sda3 (a utilização do cfdisk não será abordada passo-a-passo)

cfdisk

Após a criação da nova partição, execute o comando abaixo

# partprobe /dev/sda (RHEL7)
# partx -a /dev/sda (RHEL6)

Podemos visualizar com o comando abaixo a nova partição reconhecida pelo sistema chamada sda3

 # cat /proc/partitions

major minor  #blocks  name

   80   73400320 sda
   81     512000 sda1
   82   51915776 sda2
   83   20971520 sda3
 2530   47849472 dm-0
 25314063232 dm-1

Após a nova partição ser reconhecida vamos adiciona ao LVM.

# pvcreate /dev/sda3    

Physical volume "/dev/sda3" successfully created 

Expandindo grupo vg_web01

# vgextend vg_web01 /dev/sda3

Volume group "vg_web01" successfully extended

Expandindo Partição vg_web01-lv_root

# lvextend -L+20GB /dev/mapper/vg_web01-lv_root

  Size of logical volume vg_web01/lv_root changed from 45.63 GiB (11682 extents) to 65.63 GiB (16546 extents).
  Logical volume lv_root successfully resized.

Redimensionar sistema de arquivo ext4

# resize2fs /dev/vg_web01/lv_root

resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/vg_web01/lv_root is mounted on /; on-line resizing required
old desc_blocks = 3, new_desc_blocks = 5
Performing an on-line resize of /dev/vg_web01/lv_root to 16943104 (4k) blocks.
The filesystem on /dev/vg_web01/lv_root is now 16943104 blocks long.

Podemos agora verificar que a partição foi redimensionada para 65G sem precisar reiniciar ou muito menos desmontar.

# df -h
FilesystemSize  Used Avail Use% Mounted on
/dev/mapper/vg_web01-lv_root 65G  1.5G   59G   3% /
tmpfs 1.9G 0  1.9G   0% /dev/shm
/dev/sda1 477M   78M  374M  18% /boot

Caso sua partição seja xfs basta executar o seguinte comando

# xfs_growfs /dev/vg_web01/lv_root
Referências:

Sempre monitorei Jboss com zabbix, mas recentemente recebi uma demanda e encontrei algumas dificuldades que gostaria de compartilhar com a comunidade. Esse cenário foi feito no RHEL6, Weblogic 11g com jrockit 1.6, zabbix 2.4, porem entendendo o cenário, pode ser customizado para outras versões.

A Oracle tem um servidor Mbean chamado DomainRuntime, que está disponível no AdminServer. Conectando-se nesse servidor é possível coletar todas informações das JVM e do domínio. Assim não será necessário exportar JMX de cada JVM. Com essa solução ganha-se tempo de configuração, segurança, melhor administração de itens e gráficos agregados, além de não haver necessidade de abrir porta JMX em nenhuma JVM. Então, se tenho um domínio com 10 instancias(JVM), será possível apenas com a URL do console admin pegar todos Mbeans desse domínio.

Servidores MBean em Weblogic

O Middleware Weblogic é composto por três MBeanServers próprios que são exportados via RMI/IIOP como JSR-160. Estes podem ser consultados por meio de nome JNDI como mostra a lista abaixo. Além disso, existe a PlatformMBeanServer que pode ser exportado juntamente com o MbeanServer do weblogic.

  • Domain Runtime MBean Server
  • Runtime MBean Server
  • Edit MBean Server

O MbeanServer que vamos utilizar para buscar toda árvore do domínio weblogic será o Domínio Runtime MBean Servidor (weblogic.management.mbeanservers.domainruntime). Esse Mbean só está disponível na JVM do AdminServer.

Ative os seguintes itens abaixo no AdminServer do Weblogic:
Domínio->Geral->Avançado 

- Servidor MBean de Compatibilidade Ativado
- Servidor MBean da Plataforma Ativado
- Servidor MBean da Plataforma Usado

img1

Entre em cada JVM e adicione a seguinte linha no argumento que se encontra na aba Inicialização dos servidores

Domínio->Ambientes->Servidores->”NAME JVM”->Inicialização do Servidor

-Djavax.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder

img2

Será necessário reiniciar o AdminServer e as JVM do domínio.

Exportando RMI/IIOP AdminServer

Para facilitar a configuração, vamos utilizar a leitura dos Mbeans como anonymous, mas também poderíamos utilizar autenticação fixada no JNDI.

Permitir anonymous acesso de leitura, caso deseja monitorar sem autenticação no AdminServer.

Domínio->Segurança->Geral  - Marque o "Acesso Anônimo Ativado”

img3

Habilitar o IIOP no manager AdminServer

Dominio->Ambientes->Servidores->AdminServer->Protocolos->IIOP 

img4

Será necessário reiniciar o AdminServer.

Agora abra o jconsole com os seguintes parâmetros:

jconsole -J- Djava.class.path=$JAVA_HOME/lib/jconsole.jar:$JAVA_HOME/lib/tools.jar$WL_HOME/server/lib/wljmxclient.jar -J-Djmx.remote.protocol.provider.pkgs=weblogic.management.remote

Use a URL de serviço JMX via IIOP DomainRuntime:

service:jmx:rmi:///jndi/iiop://IPADMINSERVER:7001/weblogic.management.mbeanservers.domainruntime

Primeiro tente se conectar utilizando o login e a senha do AdminServer e veja se consegue ler a arvore com.bea/DomainRuntimeService. Depois tente sem autenticação e veja se consegue ler via anonymous.

img5

Caso não consiga ler como anonymous vamos alterar a permissão do JNDI.

1. Entre no AdminConsole(http://IP:7001/), click no AdminServer -> Exibir Árvore JNDI
2. Vá para o weblogic->management 
3. Click no mbeanservers 
4. Click em Segurança->Politicas 
5. Escolha o Methods= lookup e adicione a politica "Allow access to everyone" 
6. Restart AdminServer
7. Abra o jconsole com os parâmetros informados 
8. Conecte novamente URL : service:jmx:rmi:///jndi/iiop://IPADMINCSERVER:7001/weblogic.management.mbeanservers.domainruntime

img6

Modificação do external script jmx_discovery para DomainRuntime

Após Conseguir ler a arvore DomainRuntime do AdminServer com jconsole, vamos alterar o external script para realizar as coletas.

External Script original: github.com/RiotGamesMinions/zabbix_jmxdiscovery

Modificações que foram feita na class JMXDiscovery.java libs adicionadas:

import java.io.PrintStream;
import javax.naming.*;

Alteração na linha 46:

this.jmxServerUrl = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://" + hostname + ":" + port + "/jmxrmi");

Para:

this.jmxServerUrl = new JMXServiceURL("service:jmx:rmi:///jndi/iiop://" + hostname + ":" + port + "/weblogic.management.mbeanservers.domainruntime");

Como o DomainRuntime se conecta com IIOP e utiliza algumas libs especificar, foi necessário adicionar o pacote wlfullclient.jar(Pacote encontrado no servidor weblogic)

Coloque o wlfullclient.jar na pasta lib do pacote zabbix_jmxdiscovery. Após esses ajustes recompile o pacote utilizando ant.

Não irei aborta a utilização do ant, pois não e proposito deste post. Futuramente posso está criando um post especifico.

Obs: O /etc/hosts precisa estar resolvendo o nome da própria máquina local

Vá para diretório do binário compilado que foi realizado as modificações do jmx_discovery e execute o comando abaixo:

[brunocarvalho@zabbix zabbix_jmxdiscovery]# ./jmx_discovery com.bea:Name=DomainRuntimeService,Type=* 192.168.10.1:7001
{"data":[{"{#PROPTYPE}":"weblogic.management.mbeanservers.domainruntime.DomainRuntimeServiceMBean","{#JMXOBJ}":"com.bea:Name=DomainRuntimeService,Type=weblogic.management.mbeanservers.domainruntime.DomainRuntimeServiceMBean","{#JMXDESC}":"<p>Provides a common access point for navigating to all runtime and configuration MBeans in the…

Se a saída for parecida com a de cima seu external script está funcional.

Modificação do Zabbix Java Gateway para DomainRuntime

Para que o zabbix-java-gateway comece a coletar utilizando o DomainRuntime, será necessário recompilar o jar do zabbix, alterando a url do jmx na class JMXItemChecker.java.

Vamos precisar colocar a lib wlfullclient.jar na pasta src para compilar o zabbix-java-gateway

Não irei aborta a compilação do Zabbix, pois não é proposito deste post. Futuramente posso está criando um post especifico.

Fiz alterações simples para atender minha demanda, mas pode ser melhorada, de uma olhada no seguinte link: support.zabbix.com/browse/ZBXNEXT-1274

Class alterada: /opt/install/zabbix-2.4.1/src/zabbix_java/src/com/zabbix/gateway/JMXItemChecker.java

public JMXItemChecker(JSONObject request) throws ZabbixException
    {
         super(request);
            try
            {
                    String conn = request.getString(JSON_TAG_CONN);
                    int port = request.getInt(JSON_TAG_PORT);

                    Integer remoting = new Integer("7777");
                    Integer weblogic = new Integer("7001");

                    int retvaljboss = remoting.compareTo(port);
                    int retvalweblogic = weblogic.compareTo(port);
                if (retvaljboss == 0)
            {
   //suporta jboss7 na porta jmx 7777        
                url = new JMXServiceURL("service:jmx:remoting-jmx://" + conn + ":" + port);
            }
                if (retvalweblogic == 0)
            {
                 url = new JMXServiceURL("service:jmx:rmi:///jndi/iiop://" + conn + ":" + port + "/weblogic.management.mbeanservers.domainruntime");
            }
              else
            {url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://" + conn + ":" + port + "/jmxrmi");
            }

Agora sua imaginação não tem limites! Basta configurar seu zabbix para fazer LLD no server Domainruntime do weblogic utilizando o jmx_discovery igualmente como é feito no jmxrmi.

1. Adicione o host na interface jmx com o ip do AdminConole na porta 7001
2. Adicione o template weblogic anexo no host
3. Adicione macro para o host

{$ADMINSERVER} - ipadminserver:7001 
{$DOMINIO}  - nomedoseudominio

Segue anexo arquivos utilizados:

github.com/brunowcs/zabbix_weblogic/

O .RAR ficou um pouco grande por conta dos binários java, então tive que dividir em 3 partes para o github aceitar o upload.

  • Template Weblogic.xml LLD com 42 itens, 4 triggers, 16 gráficos criado para weblogic DomainRuntime (Não esqueça de configurar as macros)

  • JMXDiscovery.jar com alteração da class JMXDiscovery.java do zabbix_jmxdiscovery, recopilação alterações para connect IIOP com inclusão da lib própria do weblogic para comunicação do server Domainruntime

  • Bash do jmx_discovery para se colocar junto com o JMX na pasta do externalscripts do zabbix

  • zabbix-java-gateway-2.4.1.jar alteração da class JMXItemChecker.java do zabbix-java-gateway, compilação alterações para connect IIOP com inclusão da lib própria do weblogic comunicação do server Domainruntime

  • wlfullclient.jar (lib utilizada na compilação)

  • org-json-2010-12-28.jar (lib utilizada na compilação)

Recomendo realizar testes no seu em ambiente de homologação antes de entrar em produção

Resultado:

resultadofinal

Referências

Olá pessoal,

Nesse meu primeiro post, vou falar um pouco sobre o intuito desse blog.

Bem… para começar, as escritas por aqui serão bem informal e técnicas, então prenda-se apenas o proposito.

Essa ideia já é velha, mas venho adiando por muitos longos anos, porem recentemente tive a necessidade de relembrar alguns procedimentos executados há um bom tempo atrás, e fiquei tanto tempo pesquisando nas minhas mídias externas e na internet que agora tomei a iniciativa de documentar tudo em um só lugar, assim quando quiser compartilhar algo e relembrar algo pesquiso aqui! :)

Concluindo… esse será meu disco virtual, onde vou compartilhar com todos meus estudos, ideias, implementações e procedimentos do meu dia a dia…

Qualquer coisa comente, critique, ajude a enrique os posts o importante é a troca de experiências e conhecimentos.

Quem sou eu? Sobre.