quinta-feira, 21 de novembro de 2019

O IBM® Informix Primary Storage Manager gerencia o armazenamento para operações de backup restauração do ON-Bar, incluindo backups paralelos, que usam dispositivos de arquivo (discos).

IBM Informix Primary Storage Manager

IBM Informix Primary Storage Manager é um aplicativo que gerencia dispositivos de armazenamento usados para solicitações de backup e restauração emitidas pelo ON-Bar. O PSM suporta o processamento serial e paralelo para solicitações de backup e restauração.

O PSM consiste nos seguintes componentes:

onpsm

Utilitário de linha de comando que você pode usar para executar as seguintes tarefas:
  • Criar, modificar e remover dispositivos de armazenamento;
  • Definir e modificar os tamanhos máximos para dispositivos;
  • Mover informações de backup de um dispositivo para outro em um pool de dispositivos;
  • Determinar se volumes, objetos de armazenamento e dispositivos estão bloqueados ou ocupados;
  • Liberar volumes bloqueados, objetos de armazenamentos e dispositivos;
  • Verificar nomes e rótulos de volumes;

Biblioteca compartilhada XBSA

Uma versão exclusiva da biblioteca compartilhada da API X/Open Backup Services (XBSA) que o ON-BAR e o Informix Primary Storage Manager usam para se comunicar. Quando o ON-Bar armazena ou recupera dados armazenados em dispositivos de armazenamento, o gerenciador de armazenamento coordena a solicitação por meio da interface XBSA no nível do dispositivo. Você especifica o local da biblioteca compartilhada XBSA com o parâmetro de configuração BAR_BSALIB_PATH.

Tabelas de catálogo de armazenamento

Um conjunto de arquivos simples que rastreiam informações sobre todos os objetos, dispositivos e conjuntos de dispositivos de armazenamento. Esses arquivos são necessários para restaurar objetos de backup criados pelo PSM. Por padrão, esses arquivos são armazenados no diretório $INFORMIXDIR/etc/psm. Você pode usar o parâmetro de configuração PSM_CATALOG_PATH para especificar outro local para as tabelas do catálogo de armazenamento.

Importante

  • Faça backup das tabelas do catálogo de armazenamento com as ferramentas do sistema operacional como parte de uma estratégia de recuperação de desastre. O backup das tabelas do catálogo de armazenamento não são feitas com a instancia do banco de dados e não estão associados as tabelas do catálogo do sistema.
  • Para impedir que as tabelas do catálogo de armazenamento fiquem muito grandes, exclua regularmente gerações antigas de backups. Utilize o comando onsmsync para gerenciar políticas de expiração.

Os parâmetros de configuração que você usa para configurar o Informix Primary Storage Manager estão no arquivo onconfig. Você define e mantém dispositivos de armazenamento com o utilitário de linha de comando onpsm. Você pode configurar um dispositivo por vez ou gerar um arquivo de configuração de dispositivo para configurar vários dispositivos. Durante os backups, o Informix Primary Storage Manager seleciona um dispositivo de um conjunto de dispositivos disponíveis. Se o dispositivo ficar cheio ou falhar, o gerenciador de armazenamento altera automaticamente para outro dispositivo no mesmo pool.

O Informix Primary Storage Manager grava informações, mensagens de aviso e erros no log de atividades do gerenciador de armazenamento.  Você pode usar o parâmetro de configuração PSM_ACT_LOG para especificar o local do log de atividades. Se o parâmetro de configuração PSM_ACT_LOG não contiver informações, o gerenciador de armazenamento colocará as informações de atividades no diretório especificado com o parâmetro de configuração BAR_ACT_LOG.





Recursos do Informix Primary Storage Manager

Dispositivos de armazenamento para usar com o gerenciador de armazenamento

  • Apenas dispositivos de arquivos;
  • O gerenciador de armazenamento cria automaticamente um dispositivo padrão quando um catálogo é criado. O Dispositivo padrão é $INFORMIXDIR/backups;
  • Você pode remover o dispositivo padrão;

Tamanho da transferencia do buffer

  • Ilimitado;

Criptografia e compactação

  • Utiliza-se com os parâmetros BACKUP_FILTER, RESTORE_FILTER, FILTERS no ON-Bar ( O gerenciador de armazenamento não fornece criptografia ou compactação.)

Políticas de expiração do gerenciador de armazenamento

  • Nenhuma política de expiração.  (Você expira manualmente os objetos de backup do gerenciador de armazenamento com o utilitário onsmsync. Os comandos de expiração do objeto onsmsync removem objetos do gerenciador de armazenamento.)

Você pode executar uma restauração importada com o ON-Bar e o IPSM. Em uma restauração importada, você faz backup da instancia do Informix em uma máquina e restaura a instancia em uma maquina diferente. Use as opções de exportação e importação do comando onsmsync para exportar os objetos de backup do gerenciador de armazenamento na maquina de backup e importe-os para o gerenciador de armazenamento na máquina de restauração.

Backups em dispositivos Cloud e STDIO

Usando dispositivos STDIO para backup e restauração:
  • O PSM gravará/lerá um fluxo de dados em um utilitário externo ( por exemplo, sftp ou curl );
  • Operador para fornecer parâmetros para chamar o utilitário para operações de leitura/gravação/remoção;
  • A transferencia de dados para o programa de terceiros ocorrerá usando o STDIO, o PSM gravará na entrada padrão do utilitário e lerá sua saída padrão;
  • O operador não tem acesso direto ao fluxo de dados;
  • Para usar esse recurso, o operador deve criar um dispositivo PSM do tipo "STDIO";
  • Um dispositivo do tipo STDIO exigirá que você forneça o caminho para o programa a ser executado como o nome do dispositivo ( exemplo, /usr/bin/curl );
  • Além disso, você deve fornecer os argumentos para chamar o programa durante o backup, restauração e remoção;
  • Opcionalmente, você pode fornecer o tamanho máximo de um arquivo; se o backup for maior que esse tamanho, ele será dividido em partes;
A nova linha de comando é:

onpsm -D -add /usr/bin/sftp.sh -t STDIO  --stdio_warg "BACKUP @object_name1@.@object_part@" --stdio_rarg "RESTORE  @object_name1@.@object_part@" --stdio_darg "DELETE  @object_name1@.@object_part@" --max_part_size 

quarta-feira, 19 de junho de 2019

exit(n)

NAME
exit - Finaliza a aplicação 
SINOPSE
exit ?returnCode?
DESCRIÇÃO
Encerra o processo, retornando returnCode para o sistema como o status de saída. Se returnCode não for especificado, o valor padrão será 0.
EXEMPLO
Como os códigos de saída diferentes de zero são interpretados como erros pelo processo de chamadas, o comando exit é uma parte importante da sinalização de que algo fatal deu errado. Esse fragmento de código é útil em scripts para atuar como uma interceptação geral de problemas:
proc main {} { 
# ... coloque o código real aqui ...
 if {[catch {main} msg options]} {
       puts stderr "unexpected script error: $msg"
       if {[info exists env(DEBUG)]} {
            puts stderr "---- BEGIN TRACE ----"
            puts stderr "[dict get $options -errorinfo]
                      puts stderr "---- END TRACE ---"
                  }
 
 
 



Esse fragmento de código é útil em scripts para atuar como uma interceptação geral de problemas:
 
 

quinta-feira, 13 de junho de 2019

Comandos uteis para kvm (virsh)

Conectar uma console serial virtual para um convidado

entrar na vm guest e habilitar uma porta serial

# systemctl enable serial-getty@ttyS0

iniciar a serial

# systemctl start serial-getty@ttyS0

listar as maquinas virtuais convidadas

# virsh list

acessar a console do convidado

# virsh console 1 
ou 
# virsh console logixtst

após acessar teclar enter para o acesso

para sair , digitar exit e após digitar ctrl+]

Minhas considerações sobre essa console.... na minha opinião não serve de nada, pois a console na verdade é somente uma emulação, ele ate tentar emular um VT110, porem no lado do GUEST ele depende de um serviço de serial habilitado, que no meu entender não server para nada, pois ao rebotar uma maquina ele não corre as informações na tela como uma console mesmo ou ao iniciar um servidor ele também não mostra as informações na  tela, resumindo se precisar interagir com o boot da maquina, não conseguiremos , teremos que ir la no HOST e chamar a console real para interagir.

ainda acho mais vantagem nesse caso utilizar o SSH.

Forçar o desligamento de uma VM

# virsh destroy logixtst

Prove informações básicas sobre uma VM

# virsh dominfo logixtst

Mostra o estado de uma VM

# virsh domstate logixtst

Listar as VMs

# virsh list {--inactive | --all}

Pausar uma VM

# virsh suspend logixtst

Retomar a VM

# virsh resume logixtst

Descobrir o caminho da imagem do disco da VM

# virsh dumpxml logixtst | grep "source dev"

Criar uma VM através do arquivo de xml

# virsh dumpxml LogixTeste >  /etc/libvirt/qemu/ajm.xml

Editar o arquivo /etc/libvirt/qemu/ajm.xml e alterar a tag para o novo novo
exemplo:

LogixTeste para ajm

em seguida alterar a tag deixando-a em branco como no exemplo abaixo:

b4732438-0255-4390-9523-dc39dfb8348e (antes)

(depois)

após alteração executar o comando abaixo para criar o novo UUID da VM:

# virsh define ajm.xml

e finalmente criar a nova VM com o comando abaixo:

# virsh create ajm.xml


Backup maquina virtual KVM (kvm guest)

Desligar a VM, se tiver rodando

# virsh list

zeus:/kvm/LS # virsh list 
 Id    Nome                           Estado
----------------------------------------------------
 1     totvsLS                        executando
 3     HDR                            executando
 7     openFire                       executando

# virsh shutdown openFire

Backup da imagem do disco ( default: /var/lib/libvirt/images )

# cp -p /kvm/openFire /caminho_destino

Backup dos arquivos de configurações

# cp -p /etc/libvirt/qemu/openfire.xml /caminho_destino

Volte a VM no ar

# virsh start openFire

sexta-feira, 15 de março de 2019

Como configurar o Postfix no SLES11, SLES12 para fazer relay em um dominio

Ambiente

SUSE Linux Enterprise Server 11 Service Pack 4 (SLES 11 SP4)
SUSE Linux Enterprise Server 12 Service Pack 3 (SLES 12 SP3)


Assume-se que você ja tem um ambiente valido, uma conta de e-mail e senha. Você não pode usar "Postfix masquerading".


  • No SLES11 ou SLES12 ja deve ter um postfix instalado e rodando, tire o serviço do ar com "rcpostfix stop" ou "systemctl stop postfix".

  • Edit o arquivo sasl_passwd que se encontra no /etc/postfix e adicione seu domínio, seu usuário e senha:
[smtp.seudominio.com.br]:587  :senha

OBS: deixa a ultima linha em branco

  • Salve o arquivo;

  • agora compile o arquivo /etc/postfix/sasl_passwd com o comando:
postmap hash:/etc/postfix/sasl_passwd

isso ira atualizar ou criar o arquivo /etc/postfix/sasl_passwd_db, que o Postfix ira ler para saber as credenciais.

  • em seu arquivo /etc/postfix/main.cf adicione ou altere as seguintes linhas: 


relayhost = [smtp.ajmsolutions.com.br]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_tls_security_options = noanonymous
smtp_use_tls = yes

Salve o arquivo main.cf

inicialize o serviço e faça o teste.

quinta-feira, 14 de março de 2019

Exemplos do comando find

O comando abaixo tem o objetivo de encontrar uma string dentro de vários arquivos, muito útil quando se precisar encontrar uma arquivo com uma determinada string dentro dele. 

 find ./* -type f -exec grep -l "STRING" {} \; 


quinta-feira, 29 de novembro de 2018

IGNITE FOR LINUX

Ignite for Linux Disaster Recovery

O que é Ignite-LX?

O Ignite-LX é uma estrutura de scripts de recuperação de desastres gratuita que permite recuperar uma distribuição Linux. Este conjunto de ferramentas é baseado nas ideias do HP-UX Ignit-UX. Ele não habilita um daemon HP-UX Ignite em uma distribuição Linux, porem é uma solução como o Ignite no HP-UX.

Pré-requisitos

Ignite-LX requer os pacotes/binarios:

ip (iproute)
mkisofs 

Como o Ignite-LX trabalha


O Ignite-LX coleta todas as informações relevantes do sistema, como discos, lvm, raid, rede, etc. e cria um arquivo cpio compactado do sistema. Existem vários scripts que fazem esse trabalho. O resultado será uma imagem "ISO inicializavel e "Kernel + configurações Initrd" (isto pode ser usado para o netboot PXE, exp. by Cobbler) e um arquivo do seu sistema. A "ISO" ou "Kernel + Initrd" não contem todos os arquivos para a restauração do sistema, contém somente o necessário para rodar o recovery (baseado em menu). Somente o arquivo CPIO compactado contem todos os arquivos do SO relevantes e "este local" também está incluíndo no "ISO".

O Ignite-LX suporta "backends" multibel para criação e restauração de desastres. No momento há apenas um back-end disponível, o "nfs".  O NFS permite a criação e a restauração do seu Linux por meio de um compartilhamento NFS. Há previsão para desenvolvimento para criação do back-end em http, sftp e arquivos.

Como Instalar

Não há pacote de instalação criado até o momento. Simplesmente extraia o "ignite-lx.tar.gz" dentro do diretório "/opt", isso é tudo.
Se você quer utilizar outro diretório você deve estar a variável de ambiente "IGX_BASE" apontando para o diretório de instalação "ignite-lx".

Exemplo: export IGX_BASE=$HOME/ignite-lx"

O Ignite-LX vem com os seguintes diretórios padrão:

bin   # contem o script make_recovery.sh para a criação da imagem.
bin/backup/backends   # contem backup disponíveis.
bin/common   # contem as principais funções e os scripts auxiliares.
bin/restore/backends  # contem os arquivos de restore.

data/boot64/image   #  localização do local para criação da ISO, initrd e kernel (64 bit)

data/boot64/initrd_root   #   contem os arquivos de sistemas relevantes para restore (64 bit)

data/boot64/iso_root   #  arquivos requeridos para criação do boot (ISO) (64 bit)
data/config   # localização do local de todos os conjuntos de recuperação (info do sistema)

etc   # contem o arquivo ignite.conf para configuração de todo o ignite e back-end

log   # contem o ignite.log

mnt/arch_mnt   # ponto de montagem para o NFS 

O back-end do NFS permite a criação e a restauração do seu Linux por meio de um compartilhamento NFS.

Como utilizar o Ignite-LX (criar uma imagem de recuperação de desastre)

Ignite-LX é simples de rodar. Para o usuário final, apenas a execução de um script é necessária. Este script é chamado "make_recovery.sh" e esta localizado dentro do diretório "bin" do ignite-LX.
Adicionalmente existem alguns outros scripts de ajuda/trabalho, localizado dentro do diretório "bin/common".

Visão geral dos scripts relevantes:

bin/common/ignite_common.inc   # Principais funções de framework, (Includes nos scripts)
bin/common/make_boot.sh            # Cria o live system + iso
bin/common/make_config.sh         # Coleta as informações necessárias para o restore
bin/common/make_image.sh         # Cria o arquivo CPIO compactado
bin/make_recovery.sh                    # Scrip para o usuário final criar o backup
bin/restore/edit_restore.sh              # Utilizado num live system para editar as informações de restore
bin/restore/make_restore.sh           # Restaura o sistema se o live system é inicializado
etc/ignite.conf                                 # Contem as configurações do ignite

Para criar uma imagem de desastre do sistema, veja o seguinte exemplo abaixo:

Em um sistema secundário (chamado "backupsrv"neste exemplo) exporte um compartilhamento gravável "root", por exemplo "/var/ignite" e crie um diretório de cliente que deve ser usado para backup.

# mkdir -p /var/ignite/linuxbox
# echo "/var/ignite linuxbox(rw,no_root_squash,sync,subtree_check)" >> /etc/exports
# exportfs -a

No sistema que deve fazer o backup, edite o arquivo etc/ignite.conf

# vi /etc/ignite.conf
# ""
#
# NFS Backend configuration
#
IGX_NFS_URL="backupsrv:/var/ignite/linuxbox"
IGX_NFS_MOUNTPOINT="$IGX_BASE/mnt/arch_mnt"


Agora, execute o script de recuperação como segue e certifique-se de que todos os dispositivos ou grupos de volumes necessários para executar seu SO (Não os disco Externo) estão incluindos (consulte os detalhes de ajuda do script).

# cd /opt/ignite-lx/bin
# ./make_recovery.sh -b nfs -i vg00 -i /dev/md0 -x /tmp -x /var/tmp -x /wwwroot

As opções fazem o seguinte:

-i   inclue os devices ou grupo de volumes que queira incluir no backup
-x   diretório definido é excluido do backup
-b   define o back-end utilizado para criação do backup.

Explicação 

O sistema "linuxbox" possui os seguinte pontos de montagens:

/dev/md0 on / type xfs (rw)
/dev/mapper/vg00-lv_home on /home type xfs (rw)
/dev/mapper/vg00-lv_opt on /opt type xfs (rw)
/dev/mapper/vg00-lv_tmp on /tmp type xfs (rw)
/dev/mapper/vg00-lv_usr on /usr type xfs (rw)
/dev/mapper/vg00-lv_local on /usr/local type xfs (rw)
/dev/mapper/vg00-lv_var on /var type xfs (rw)

Os pontos de montagem acima são pontos de montagem nativo do sistema operacional e são necessários em um backup.

O script "make_recovery.sh"  resolve o ponto de montagem por dispotivos e group de volumes, portanto, temos que definir "/dev/md0" para o monto de montagem root e "vg00"para o grupo de volume chamado "vg00".