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".

terça-feira, 16 de outubro de 2018

Testes de desempenho de I/O no Linux usando o comando dd



No Linux, o comando dd pode ser usado para medir o desempenho de I/O em disco utilizando escritas sequenciais. Este artigo fornecerá informações sobre quais parâmetros devem ser utilizados.


Noções básicas

dd pode ser usado para cópia de dados de baixo nível. Ao fazer isso, arquivos de dispositivos são acessados diretamente. Cuidado com o fato de que o uso incorreto do dd pode levar rapidamente à perda de dados. É recomendável executar as etapas descritas abaixo com muita atenção. Se o dd for utilizado incorretamente, o resultado será perda de dados.

Medindo o desempenho de gravação

Sistemas Operacionais modernos normalmente não gravam arquivos diretamente em sistemas de RAID ou discos rígidos. A memória temporaria que não está em uso no momento, será usada para armazenar em cache gravações e leituras.

Assim, essa medida de desempenho de I/O não será afetada por esses caches (memória temporaria),  o parâmetro oflag pode ser usado. Assim, os dois flags a seguir são interessantes (para detalhes, consulte dd --help e dd utilizando I/O direto ou sincronizado).

  • direct (utiliza I/O direto para dados)
  • dsync (utiliza I/O sincronizado para dados)
  • sync (da mema forma, mas também para metadados)
Para medir o desempenho de gravação, os dados a serem escritos devem ser lidos de /dev/zero e depois gravados em um RAID, disco rígido ou uma partição vazia (usando algo como of=/dev/sda para o primeiro disco rígido, ou of=/dev/sda2 para uma segunda partição no primeiro disco rígido. Se isso não for possível, uma file system normal pode ser utilizada (usando algo como of=/root/teste.img). Por razões de segurança se não tiverem certeza do que estão fazendo, faça os testes em um arquivo dentro da file system. No meu caso vou fazer os testes em discos raw e file system para comparação. O desempenho de gravação obtido nos testes com arquivos em file system será um pouco mais lento (porque os metadados também serão gravados no sistema de arquivo).

Importante: Ao gravar em um dispositivo (algo como /dev/sda), os dados armazenados serão perdidos. Por essa razão, escolha um RAID, disco ou partição vazia.

Nos meus testes estarei utilizando o seguinte equipamento: 
  • HP EliteBook 8460w
    • 8 GiB de RAM
    • sda (SSD)
    • sdb (SATA)
Observação:
  • Quando usar if=/dev/zero and bs=1G, o Linux precisará de 1GiB de espaço livre em memoria RAM. Se o seu ambiente de teste não tiver memória livre o suficiente, utilize um valor menor para o parâmetro bs (algo como 512MiB).
  • A fim de obter resultados mais próximos da realidade do nosso dia-a-dia, recomendo realizar os testes descritos varias vezes (tres a dez vezes, por exemplo). Ao fazer isso poderá detectar variações isoladas. Tais variações isoladas pode incluir jobs no cron, interrupções ou condições gerais devido ao processamento paralelo, o que pode afetar gravemente o desempenho. Um exemplo ao extremo, para esclarecermos essa questão, seria um job executando uma store procedure onde a mesma poderia estar fazendo muitos inserts em um banco de dados. 
HP Elite Book 8460w

Neste exemplo, nosso teste vai escrever um arquivo em /tmp , sendo a file system um XFS e SATA 5400 RPM.

1 GiB será escrito no arquivo /tmp/teste.img, primeiro com o cache ativado

merlin:/ # hdparm -W1 /dev/sdb

/dev/sdb:
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)
merlin:/ # dd if=/dev/zero of=/tmp/teste.img bs=1G count=1 oflag=direct
1+0 registros de entrada
1+0 registros de saída
1073741824 bytes (1,1 GB, 1,0 GiB) copiados, 9,96763 s, 108 MB/s
merlin:/ # 

agora com o cache desativado

merlin:/ # hdparm -W0 /dev/sdb

/dev/sdb:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)
merlin:/ # dd if=/dev/zero of=/tmp/teste.img bs=1G count=1 oflag=direct
1+0 registros de entrada
1+0 registros de saída
1073741824 bytes (1,1 GB, 1,0 GiB) copiados, 10,0717 s, 107 MB/s
merlin:/ # 

Nesse teste vamos ver a latência, 512 bytes serão escritos 1000 vezes, primeiro com o cache desativado.

merlin:/ # hdparm -W0 /dev/sdb

/dev/sdb:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)
merlin:/ # dd if=/dev/zero of=/tmp/teste.img bs=512 count=1000 oflag=direct
1000+0 registros de entrada
1000+0 registros de saída
512000 bytes (512 kB, 500 KiB) copiados, 11,7722 s, 43,5 kB/s
merlin:/ # 

agora com o cache ativado

merlin:/ # hdparm -W1 /dev/sdv

/dev/sdb:
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)
merlin:/ # dd if=/dev/zero of=/tmp/teste.img bs=512 count=1000 oflag=direct
1000+0 registros de entrada
1000+0 registros de saída
512000 bytes (512 kB, 500 KiB) copiados, 0,0947568 s, 5,4 MB/s
merlin:/ # 

Agora teste feito no disco SSD

cache ativado
merlin:/ # hdparm -W1 /dev/sda

/dev/sda:
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)
merlin:/ # dd if=/dev/zero of=/opt/teste.img bs=1G count=1 oflag=direct
1+0 registros de entrada
1+0 registros de saída
1073741824 bytes (1,1 GB, 1,0 GiB) copiados, 2,09522 s, 512 MB/s

merlin:/ # 

 cache desativado
merlin:/ # hdparm -W0 /dev/sda

/dev/sda:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)
merlin:/ # dd if=/dev/zero of=/opt/teste.img bs=1G count=1 oflag=direct
1+0 registros de entrada
1+0 registros de saída

1073741824 bytes (1,1 GB, 1,0 GiB) copiados, 2,11989 s, 507 MB/s

Latencia, cache ativado
merlin:/ # hdparm -W1 /dev/sda

/dev/sda:
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)
merlin:/ # dd if=/dev/zero of=/opt/teste.img bs=512 count=1000 oflag=direct
1000+0 registros de entrada
1000+0 registros de saída
512000 bytes (512 kB, 500 KiB) copiados, 0,0521671 s, 9,8 MB/s

merlin:/ # 

Latência, cache desativado
merlin:/ # hdparm -W0 /dev/sda

/dev/sda:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)
merlin:/ # dd if=/dev/zero of=/opt/teste.img bs=512 count=1000 oflag=direct
1000+0 registros de entrada
1000+0 registros de saída
512000 bytes (512 kB, 500 KiB) copiados, 1,29057 s, 397 kB/s

merlin:/ #