VICRLDA: GNOME BOXES … cadê o modo bridge ???

Certa vez, lendo as discussões num fórum sobre Linux, me deparei com a declaração de um usuário que afirmava o seguinte: “Em grande parte, os desenvolvedores do projeto GNOME encaram a própria bandeira à níveis extremos – simples e fácil de usar (…) E como consequência, suas aplicações carregam esse DNA intrinsecamente”. Na época, honestamente não fez muito sentido para mim. Além disso, um questionamento aflorou particularmente: E o que há de errado? Isso é bom, não? Bem, e a resposta é SIM e NÃO. Continue lendo para entender melhor!

Se você, caro leitor, ficou empolgado com o Ansible mas não teve êxito no último laboratório, peço desculpas pois sim, foi minha culpa 😦 Para o sucesso deste é necessário fazer um pequeno workaround, gambiarra, ou melhor, uma solução alternativa, para soar mais bonito (rsrs) Em minha defesa, e fazendo o papel de advogado do diabo, o que aconteceu foi que travei em determinado ponto da prática, enquanto escrevia a teoria (o POST em si) ao mesmo tempo. Dessa maneira, pesquisei sobre o erro no Google, encontrei, corrigi e voltei a escrever como se nada tivesse acontecido, como se o BUG não existisse (quase que cantarolando de tanta felicidade, haha)

Eu sei que o título já entrega muita coisa, quando exponhe logo de cara sobre o que abordará, indo até o cerne e apontando o problema … Mas, mesmo assim, peço um pouco de paciência para os fatos, capturas de tela e explicações a seguir:

Acredito que o primeiro impulso de todo administrador/engenheiro de sistemas quando loga em uma máquina é verificar qual IP ela pegou. Portanto, vamos abrir o boxes e iniciar a VM. Feito isso, execute o comando que lista tais informações:

Figura 01. ip addr show

Observe atentamente para a faixa de rede atribuída (/24), neste caso sendo 10.0.2.X, e o endereço 10.0.2.15 … Guarde-a bem pois utilizaremos em um dos testes mais básicos para validar a comunicação entre máquinas: o ping.

Deixando aberto o terminal convidado, e liberando o teclado (CTRL+ALT da esquerda), dirija-se até o terminal hospedeiro, no meu caso o Pop_Shell, e digite ping -c 5 10.0.2.15

Figura 02. Pingando do HOST para o GUEST

Exatamente! Não conseguimos enxergar o CentOS 8, porque a interface é automaticamente configurada no modo NAT, processo esse considerado interno, do próprio GNOME Boxes. O porém aqui reside no fato de que não há outra opção de rede para a interface dessa ou qualquer outra máquina que esteja rodando sob o boxes. Isso porque o ecossistema GNOME Shell (interface gŕafica + aplicativos) tentam manter sempre tudo o mais simples possível. Recordam do lema deles?? Pois é, isso mesmo! Resultado: não sobra muito espaço para customizações e afins, já que a margem é quase inexistente, ínfima na maioria das aplicações 😦

Caso sirva de consolo, e graças a lógica de funcionamento do NAT, você não fica completamente isolado uma vez dentro da VM, pois a máquina visualiza sua rede doméstica/corporativa além de sair para internet sem nenhum problema.

Figura 03. Ping para a rede local e saída pela internet

Localize a pasta onde fica armazenada o disco virtual do CentOS, e copie o seu caminho completo:

Figura 04. /home/user/.var/app/org.gnome.Boxes/data/gnome-boxes/images

Instale o virt-manager no sistema hospedeiro. Disponível na Pop_Shop! ou visitando o site oficial (https://virt-manager.org/) e baixando.

Quando concluído, abrir e ir na opção Arquivo > Nova Máquina Virtual > Importar imagem de disco existente

Figura 05. QEMU/KVM

Botão “Avançar”, forneça o caminho navegando até ele ou cole aquele copiado mais cedo:

Figura 06.

Defina quanto de memória e CPU:

Figura 07.

Revise as configurações e por fim, botão “concluir”:

Figura 08.

Listada como ‘centos8’, clique com botão direito e escolha ‘executar’

Figura 09.

Em seguida, botão “abrir” para visualizar a console:

Figura 10.

Menu superior, aba “Ver”, opção “Detalhes”

Figura 11.

Um clique simples sobre o ícone ” NIC :b3:de:40 ” e copie exatamente de acordo com a captura abaixo:

Figura 12.

Aplique as alterações antes de fechar, retorne a console da máquina, e verifique o IP da interface:

Figura 13.

Finalmente, repita o teste do ping em ambos os sentidos da comunicação (HOST > GUEST e GUEST > HOST)

Figura 14. VM alcançando o hospedeiro tanto via IP quanto hostname
Figura 15. Sucesso total !!! Pop_OS enxergando a VM

Conclusão: a partir de hoje use sempre o virt-manager para executar a máquina devido a possibilidade de mais modos de rede para a interface!

ANSIBLE SERIES: YML … add sudo(ers) >> no prompt or ask

Olá! Como vai? Muito prazer, Victor é o meu nome … Ou @vicrlda, se preferir … Navegando pela internet em busca de inspiração, situações, exemplos práticos para exercitar e solucionar via ANSIBLE ??? É um sysadmin ou desenvolvedor que anseia o cargo de Engenheiro Devops / SRE ?? Por favor, peço que me deixe cumprimentá-lo e lhe dar os parabéns, pois o caro leitor (você) veio ao lugar certo! Seja mais do que bem-vindo ao @machinesbecomeservices.com … A partir de hoje, serei o seu humilde anfitrião / companheiro / fiel escudeiro nessa incrível jornada que chamo de “estrada para a automação”

Em contrapartida, se por acaso você é um veterano, não pera (…) Melhor dizendo, se já é um velho conhecido meu e do BLOG, por favor pule para a próxima etapa … Ops! Quero dizer, seção (hahaha)

Ambiente: Máquinas e Pré-requisitos

Para total compreensão e sentido, por favor, peço que…

Recém-chegados, leiam o seguinte post, e partam desse princípio:

https://machinesbecomeservices.com/2021/09/21/vicrlda-dual-boot-pop_os-gnome-boxes-vpn-checkpoint-e-novo-workflow/

Longa datas, revisem esse outro post, e iniciem suas VMs do ponto exato em que paramos:

https://machinesbecomeservices.com/2020/12/01/ansible-series-hands-on-01-modo-cli-e-hello-yml-1st-playbook/

Quem ainda não entendeu nada, acompanhe a śerie ANSIBLE desde o começo 😉

https://machinesbecomeservices.com/?s=ansible

GNOME Boxes, uma solução All-in-One: Download nativo de ISOs + Criação das instâncias + Uso integrado

Com o Boxes, não é mais necessário sair da ferramenta em busca de outros meios/softwares para baixar, instalar, configurar, usar máquinas virtuais. Destaque principalmente, e especialmente, para a primeira etapa que é fazer o download das ISOs, onde normalmente acessaríamos os respectivos sites oficiais de cada uma, e obteríamos via métodos tradicionais como o próprio GET ou até mesmo TORRENT. Bem, dito isso, vamos abri-lo agora para conhecê-lo um pouco melhor e ver como as coisas transcorrem, além de claro, testemunhar toda a sua simplicidade, praticidade e comodidade. Teclado e mouse em mãos, vem comigo!

Uma vez baixado via loja de aplicativos linux favorita (deb, rpm, flatpak, snapp), abra-o pela primeira vez e verá a seguinte tela:

Figura 01: GNOME Boxes v.40.2

Clique no ícone + para iniciar o processo de criação. Observe que a janela aberta traz consigo três opções principais, que são: (a) os sistemas operacionais mais baixados naquele momento, por outros usuários da plataforma; (b) lista de todos os outros SOs que não aparecem pois não figuram no ranking Top 3 anterior; e (c) finalmente instalar a partir de um arquivo .ISO previamente baixado e disponível localmente.

Figura 02. Opções e formas de iniciar o processo

Escolha a segunda opção, “Navegue e pesquise sistemas operacionais para instalar”.

Figura 03. Listagem dos Sistemas Operacionais

Procure por ‘centos’ na barra de pesquisa:

Figura 04. Busca por ‘centos’

Simularemos um ambiente heterogêneo, então isso significa distros variadas, com versões diferentes. Selecione CentOS 7 x86_64 (netinst) :

Figura 05. Download automático da ISO

Aguarde a conclusão do download, iniciado automaticamente, para logo em seguida começar o que o Boxes chama de “instalação expressa”. Informe um nome de usuário, e abaixo clique em adicionar senha, digitando a mesma no campo aberto:

Figura 06. Instalação Expressa / Usuário e senha

Na próxima tela, revisar e criar, defina a quantidade de RAM e tamanho máximo do HD, ambos virtuais. Para efeitos de teste, e considerando que essas máquinas serão sempre “descartáveis”, ou seja, meros templates clonados de um git, GitHub ou GitLAB via Ansible/AWX/Tower … Sinta-se livre para escolher a configuração que mais lhe agrada, e que seu hardware atual permite. Mas, tenha em mente que apenas 512 MB de RAM e 10 GB de HD, são o “mínimo” e mais do que suficientes para rodar um Linux em modo texto. Portanto, esta será a minha escolha de configuração para a maioria dos servidores-alvo (nós) que iremos criar eventualmente, ao longo da série:

Figura 07. Instalação expressa / RAM e HD virtuais

Feito! Agora basta esperar até que o sistema seja criado e pronto! Ressaltando que o ícone da imagem é uma espécie de olho que fica girando (bolinha fazendo círculos) :

Figura 08. Instalação expressa / SO sendo preparado

Caso a instalação demore e comece a achar meio estranho, faça como eu, seja curioso, e dê um simples clique em cima da bolinha. Talvez se depara com isso, um terminal bugado que por algum motivo não conseguiu finalizar o processo sozinho:

Figura 09. Instalação expressa / Kernel panic !!!

Seguindo a própria recomendação exibida em tela, digite journalctl no terminal para depurar o log e reunir mais informações sobre o possível erro.

Buscando a circunstância para tamanha anomalia, ou quem sabe com sorte, pelo menos alguma pista que levasse até o principal suspeito … Encontrei várias linhas no arquivo de log informando que “a partição X não foi montada”; “a partição Y não existe”; “a Z não possui espaço suficiente”; e coisas desse tipo … Meu primeiro palpite foi de que o particionamento automático da instalação expressa está bugando ao dimensionar, formatar e levantar o esqueleto de diretórios necessário ao sistema operacional. Cheguei ao ponto de aumentar o tamanho do disco virtual querendo testar o algoritmo de fracionamento em diferentes quantidades e valores de armazenamento, pois talvez aqueles exatos 10,7 GB iniciais estivessem sendo pulverizados em tantas micro partições, que no final uma ou outra não tivesse espaço disponível para continuar, quebrando assim toda a instalação. Outros testes realizados foram: aumentar memória, reiniciar a máquina, apagar a VM e recomeçar do zero. Nada! Sem êxito nenhum! Quase perdendo as esperanças, resolvi usar outra imagem, o CentOS 8. Além disso, ainda desconfiado de haver algum BUG no meio, desativei o processo de instalação expressa, simplesmente clicando e desmarcando a caixa de seleção. Dedos cruzados, e na torcida!!! Veremos o que nos espera adiante:

Figura 10. Repetindo o processo com CentOS 8
Figura 11. A-ha! Sem erros!!! Conclusão: instalação expressa do Boxes momentaneamente bugada

Siga em frente, definindo seus próprios parâmetros e configurações da VM, contudo sabendo que em muitas das vezes os padrões pré-selecionados de fábrica já satisfazem o nosso objetivo, salvo eventuais exceções a serem modificadas posteriormente, sem dano algum a integridade do sistema. Não explicarei em detalhes pois não cabe aqui, tão pouco é o objetivo desse POST, como instalar e configurar um CentOS. Isso porque no futuro pretendo abordar esse assunto, em particular, trazendo as possibilidades de cenários e suas variantes. Ok?

Pop_OS! : Executando o Ansible

Apostando no conhecimento prévio adquirido nos posts antecessores, vou direto ao ponto e mostro como transformar o seu Pop_OS! em um nó controlador do Ansible. Essa e tantas outras nomenclaturas, podem ser revistas a qualquer momento. Na dúvida sobre determinado termo, busque aqui no BLOG e releia! Pois cada um deles conta e todos são igualmente importantes, sem exceção.

sudo apt update
Figura 12. Atualizando a última versão dos repositórios atuais
sudo apt install software-properties-common
Figura 13. Instalando o pacote de softwares para python
sudo add-apt-repository --yes --update ppa:ansible/ansible
Figura 14. Adicionando o PPA (repo) oficial do Ansible
sudo apt install ansible
Figura 15. Instalando o pacote ‘ansible’ e suas dependências
ansible --version
Figura 16. Verificando qual versão foi instalada
ansible-config init --disabled > ansible.cfg
ansible --version
Figura 17. Criando o arquivo de configuração

LAB : Adicionando usuário e senha pré-definidos

Tarefa recorrente no cotidiano de um administrador de sistemas, informar novos usuários aos servidores linux pode ser divertido ou entediante, dependendo de como enxerga … Se não gosta de aventura, emoção ou coisas novas, então: (a) escreva um shell script, (b) copie-o para todas as máquinas em que o usuário necessita acesso, (c) execute o mesmo localmente, (d) digite o nome/senha, e por fim, repita os passos C e D até o número X de hosts envolvidos. Por outro lado, se busca tempo livre para novas demandas, novos projetos, novas habilidades, ou somente para tomar aquele cafezinho na copa com toda a calma, conversando e saboreando … Então, aprenda YAML, playbooks, Ansible: aqui, agora !!! 😉

Vamos lá! Para começar, armazenar senhas em texto plano é considerado uma falha de segurança. Qualquer atacante (externo ou interno) teria fácil acesso a esse segredo, usando-o a favor dele, e consequentemente, contra você. Por isso, dados críticos ou informações sigilosas devem sempre apresentar certo nível de criptografia, nunca expostos totalmente. Em nosso caso, utilizaremos a biblioteca passlib do python para gerar o hash de uma senha aleatória forte, sendo esse dado a constar no código-fonte, e não a credencial em si. Para tal abra o editor de texto e, sem olhar, digite algumas teclas aleatoriamente. Feito? Ótimo! Agora no terminal execute os seguintes comandos:

pip3 install passlib
python3 -c "from passlib.hash import sha512_crypt; import getpass; print(sha512_crypt.using(rounds=5000).hash(getpass.getpass()))"
CTRL-C (gedit) + CTRL-V (bash) + ENTER (tecla) = HASH (ctrl-c + ctrl-v + ctrl-s)

Salve o resultado (hash) no mesmo bloco de notas, ao lado da senha que criou há pouco. Assim você terá as duas informações, enquanto escreve o playbook, repassando apenas a última.

Com isso, ainda no terminal, monte a estrutura necessária:

mkdir awx
mkdir -p awx/inventories awx/playbooks
ls -lhR awx/
Figura 18.
cd awx/
touch inventories/hosts
touch playbooks/add-sudo-no-prompt-or-ask.yml
Figura 19.
ls -lhR awx/
Figura 20.

Edite o arquivo hosts conforme o conteúdo abaixo:

vim awx/inventories/hosts
##CENTOS-a ansible_host=10.10.2.141
##CENTOS-b ansible_host=10.10.2.143

Depois abra o playbook e cole o seguinte:

vim awx/playbooks/add-sudo-no-prompt-or-ask.yml
---
- hosts: all
  become: yes
    
  tasks:
  - name: Adiciona usuario e entrega poderes de ROOT
    ansible.builtin.user:
        name: "bob"
        state: present
        password: "$6$XxSTRcR6la4KKUl1$R7XqBVSTOTCNq8PeBpPHL5gK9x1xy8D7oICVHgc2StH7/7wuheM2rPdpw9WD4QkM.Sh1BaDaBq70kE8ScY0jd."
        update_password: on_create
        groups: wheel
        append: yes
...

1ª linha: Todo playbook, na prática um arquivo com extensão .yml ou .yaml, deve começar com três hifens (traços) para sinalizar a sintaxe da sua natureza, a linguagem YAML.

2ª linha: YAML suporta vários tipos de estruturas de dados. Quando trabalhamos com ANSIBLE as mais comuns são listas e dicionários. Uma lista pode ser um conjunto de itens, separados por linha e iniciados com hífen + espaço (“- “) cada. Já um dicionário pode ser um grupo de mapas, composto por chave:valor cada linha e nomeado exclusivamente. Também é possível misturá-los, o que acaba resultando em listas de dicionários ou dicionários com listas muitas vezes. Para encurtar, particularmente nesse caso, estamos dizendo ao Ansible que a lista “hosts” é composta por todas as entradas (sem exceção) do inventário padrão, de mesmo nome. Dessa forma, o playbook será executado em TODOS os servidores listados.

3 ª linha: Equivalente ao su/sudo, aqui definimos o método de escalonamento na máquina remota. O valor YES implica que o usuário escolhido foi o root do sistema ( become: yes = become_user: root )

5ª linha: Dicionário que contém todas as tasks daquela play em questão.

6ª linha: String que nomeia a primeira task do playbook, podendo ser uma frase, palavra, ou caractere de escolha livre.

7ª linha: Módulo ansible utilizado para cumprir aquela tarefa.

8ª linha: Parâmetro name do módulo user para informar o login de usuário.

9ª linha: Parâmetro que remove (absent) ou adiciona (present) o login anterior.

10ª linha: Parâmetro que recebe o valor da senha no formato hash, gerado em etapas superiores.

11ª linha: Parâmetro que atualiza para uma nova senha ou mantém a mesma em casos de preexistência.

12ª linha: Parâmetro que dita qual (is) grupo (s) aquela credencial será membro.

13ª linha: Parâmetro que defini se o grupo é só mais um apêndice ou substituto único e exclusivo para aquele usuário.

14ª linha: Fim do playbook (três pontos).

RUN PLAYBOOK , RUN ! ! !

Últimos metros da maratona, faltando apenas uma etapa para que tudo funcione perfeitamente … Bem, conforme dito no passado, Ansible trata-se de uma ferramenta agentless (sem agente) que faz uso do SSH para comunicação entre as partes. E sendo assim, não poderíamos esquecer de gerar o seu par de chaves correspondente. Para isso, logado como usuário SUDO (comum às duas máquinas: local e remota), no controlador execute:

ssh-keygen -t rsa -b 4096
Figura 21.
ssh-copy-id [usuario_remoto]@[ip_ou_hostname_do_alvo]
Figura 22.
ssh user@machine
Figura 23.
[password]
Figura 24.
exit or logout
ansible -i awx/inventories/hosts -m ping all
Figura 25.
ansible-playbook -i awx/inventories/hosts awx/playbooks/add-sudo-no-prompt-or-ask.yml --ask-become-pass
Figura 26.
Figura 27. ANTES e DEPOIS¹
Figura 28. ANTES e DEPOIS²

REFERÊNCIAS:

https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html

https://www.redhat.com/en/topics/automation/what-is-yaml

https://www.tutorialspoint.com/yaml/yaml_basics.htm

https://rollout.io/blog/yaml-tutorial-everything-you-need-get-started/

VICRLDA: dual-boot , pop!_os , gnome boxes , vpn checkpoint e novo workflow

Saudações terráqueos !!! Meu nome é VICRLDA-1-5-92 ... Sou um mensageiro intergaláctico, venho em paz e trago comigo um comunicado. Na verdade, trata-se de um sucinto relato sobre acontecimentos particulares ocorridos neste último mês e meio aqui na Terra, período no qual meu mestre e senhor (Victor, o grande) estava afastado e impossibilitado de deslocamento para vir lhes anunciar pessoalmente. Enfim, devaneios à parte, logo abaixo segue a transcrição da mensagem! Câmbio, desligo.

Olá pessoal ! Que bom revê-los e estar de volta após mais uma breve pausa! Não exatamente proposital, eu confesso, mas também não estava nos planos ficar tanto tempo sem postar nada. Quase 45 dias já se passaram desde o nosso último encontro, ocorrido em 09 de agosto. De lá pra cá, talvez a notícia mais importante (pelo menos pra mim) é que fui alçado e agora sou um especialista nível 03 no meu local de trabalho. Formalmente, e internamente, trata-se do setor de infraestrutura e operações, ou simplesmente setor de SUPORTE, como é o caso de muitas empresas aqui no Brasil. Redes, Banco de Dados, Segurança, Linux e Windows Server, são apenas alguns dos elementos que compõem e dão forma ao departamento de Infraestrutura de TI de uma organização. Usualmente, esse digamos “guarda-chuva”, está sob a tutela de um gerente que responde a um diretor técnico que recebe orientações do diretor-presidente. A nomenclatura varia um pouco, é claro, e outros protagonistas adicionais existem, coexistem, ou deixam de existir nesse organismo vivo chamado Governança Corporativa (estude COBIT 5 para saber mais!). Bom, e o que isso tem haver comigo? Não, não falo de você, estou perguntando a mim mesmo … rsrs! Esse reconhecimento enquanto profissional de TI só foi possível graças aos esforços com o Ansible, que dentro da empresa começou designado a mim como projeto piloto (de testes). E uma vez que apresentei os resultados inicias, muito positivos e relevantes, diga-se de passagem, foi dado o START para colocá-lo em PRODUÇÃO, com mais recursos e pessoal alocado.

No meio do caminho, enquanto trabalhava no projeto, utilizava como hospedeiro e sistema operacional principal da máquina o próprio Windows 10. Nada demais, ou contra, mas o sentimento que me acompanha já faz certo tempo, é que a “janela” da Microsoft não me satisfaz em termos de desempenho, velocidade e produtividade. Ainda mais quando se usa um hardware modesto a simples. Os maiores “pecados” estão concentrados principalmente no gerenciamento de memória e I/O. Tenho instalado 8 GB de RAM e HD convencional de 5400 rpm com um WINDOWS Limpo (fresh install, sem blotware dos fabricantes). E após um determinado período de tempo (semanas, dias, horas), especialmente se você assim como eu tem o costume de suspender/hibernar o PC ao invés de desligar toda vez, a configuração atual deixa de ser suficiente para rodar, testar, e trabalhar com diversas máquinas virtuais, mesmo estas colocadas em modo texto. O SO vai gargalhar, e verá seu uso de RAM chegar a 85/90 por cento da capacidade total. E o pior, boa parte sendo alocada para o Windows e seus incontáveis processos em segundo plano, e inúmeras atualizações pendentes, constantemente ignoradas no estado HOLD, mas que continuam ocupando espaço lá na escassa e suada memória RAM.

Somente então a partir daí que tomei a atitude de, não eliminá-lo, mas sim trocá-lo por um jogador de peso e mais experiente: Kernel Linux + Distro Pop_OS! ( … ) Quando o assunto é agilidade, ganho de tempo e mais fluidez no workflow de um sysadmin ou dev, incontestavelmente, LINUX > Windows … Ei pessoal, levem na esportiva, afinal é apenas uma opinião pessoal deste autor que vos escreve! Ok? Feito as pazes? Adiante então, vamos prosseguir! Meu conselho para você que se encaixa nessa descrição: faça dual-boot, instale qualquer distro de sua preferência (.deb ou .rpm), dê uma chance para o Linux e seja feliz, + rápido + tempo livre pra curtir a vida!!!!

Pois muito bem, caso tenha escolhido o Pop_OS! ou qualquer distro com o ambiente GNOME Shell, verifique na loja de aplicativos e procure por “Boxes” ou “GNOME Boxes”. Encurtando e simplificado bastante, o Boxes está para o VirtualBox assim como o VMware Player está para o VMware Workstation. Ou seja, todos eles são virtualizadores, contudo os primeiros são bem mais limitados de opções e muito mais restritos para ajustes finos de hardware. Então por que utilizá-lo? A primeira pergunta que vem a cabeça, correto? A resposta remonta ao ponto que mencionei mais cedo: produtividade. O GNOME Boxes, assim como tantas outras ferramentas/programas de software livre, apresentam um ás na manga quando se trata de Linux, opensource, enfim, de modo geral no comparativo com outros S.O.s disponíveis no mercado … Integração, meu caro amigo! Integração é a palavra-chave que resume perfeitamente essa relação: núcleo (kernel) < > sistema operacional < > pacotes (software). Tudo isso sai da fábrica quase configurado, ás vezes já pronto, e para todo resto o que falta é a distância de apenas um comando no terminal. Resumindo. Em outras palavras: os “meios” necessários para que um admin ou dev consiga desempenhar tarefas e atividades em diversos tipos de sistemas e ambientes, de forma simultânea, e tendo que optar como base um SO único/hospedeiro … Qualquer distribuição linux oferece enorme vantagem, sendo quase sempre a escolha mais indicada. Pois os ditos “meios”, que na verdade e na prática, são meras ferramentas que já estão presentes, ou rodam nativamente, ou ambos. Além disso, mostram benchmarks ultra rápidos, graças ao gerenciamento de memória e sistema de arquivos diferenciados.

Recapitulando a composição do meu novo workflow, temos: Linux Kernel 5.13.0 + Pop_OS! 21.04 + GNOME Boxes 40.2 + ( … ) Por último, mas não menos importante, o cliente VPN da Check Point Software Technologies Ltd. Uma empresa estadunidense de segurança cibernética com imenso portfólio de produtos, soluções e serviços voltados para a área. E assim, chegamos ao gran finale do dia de hoje … O que é uma VPN? Por que utilizar? Como instalar? Qual tipo estou usando? São perguntas a serem respondidas em outro momento, num futuro próximo.

Adeus, e até breve! 😉

https://www.kernel.org/

https://pop.system76.com/

https://wiki.gnome.org/Projects/GnomeShell

https://www.checkpoint.com/quantum/remote-access-vpn/

ANSIBLE SERIES: h.t.wrt* … tasks, plays e books: failures! (or error handling)

De tempos em tempos, a humanidade é testemunha de um curioso, engraçado e certo tipo de evento: erros que se transformam em felizes acertos! Não faz sentido pra você? Tudo bem, sem problemas! Eu lhe apresento 🥁🥁🥁 a penicilina e a coca-cola 🤭 rsrs! Então, voltando … O mesmo pode acontecer no Ansible. Eventualmente, um código de retorno com valor não-zero (diferente de zero), seja vindo de um comando ou de uma falha em determinado módulo, pode ser exatamente o que você busca no momento e por isso, não vai querer que o Ansible pare a execução naquele host e siga para o próximo. Não, muito pelo contrário. Tal código não-zero indica para você, e sua demanda/tarefa, um verdadeiro baita de um sucesso! Portanto, nada mais lógico do que tratá-lo … Correto? Bom, antes de iniciar os trabalhos, um exemplo básico de situação hipotética para ilustrar melhor: numa bela e ensolarada manhã, seu chefe propõe a você que, caso um host apresente uma falha, o Ansible pare/encerre instantaneamente a execução em todos os outros. Fim!

Agora sim, adiante! Vamos a aula de hoje, com o seu respectivo sumário listado a seguir:

  • Ignorando comandos com falha;
  • Ignorando erros de host inacessíveis;
  • Redefinindo hosts inacessíveis;
  • Manipuladores e falha;
  • Definindo falha;
  • Definindo “alterado”;
  • Garantindo o sucesso para o comando e shell;
  • Abortando uma reprodução em todos os hosts;
  • Controle de erros em blocos;

07-a. Ignorando comandos com falhas

O comportamento padrão, quando uma task qualquer falha num host particular, é puro e simplesmente parar a execução das outras tarefas no mesmo, não importando a quantidade que faltava ou em qual task ele estava (ex: a primeira, a do meio, ou a última). Dessa forma, o Ansible pularia para o próximo host sem piscar duas vezes. Contudo, é totalmente possível continuar naquele host específico apesar dos apesares, ou melhor dizendo, da(s) falha(s). Basta utilizar a palavra-chave ignore_errors:

- name: Do not count this as a failure
  ansible.builtin.command: /bin/false
  ignore_errors: yes

Mas, atenção aqui! Tenha cuidado! Pois essa regra somente funcionará com tarefas capazes de retornar o valor 'failed' (“falhou”). Sendo assim, o Ansible jamais/nunca ignora erros de: variáveis indefinidas, falhas de conexão, problemas de execução, pacotes ausentes ou até mesmo erros de sintaxe.

07-b. Ignorando erros de hosts inacessíveis

Em sua jornada diária, quantas e quantas vezes aquele seu colega sysadmin da infra/operação moveu uma VM de lugar, acrescentou uma nova regra de firewall, ou desligou um grupo de máquinas sem nenhum aviso prévio? Eu sei, talvez sua resposta seja: muitas, várias vezes … Certo? 😥 Mas calma! Por favor, peço que não brigue com ele! Afinal o dia-a-dia de um admin/ops pode ser um pouco cheio e meio estressante, de tanto deveres, rotinas e tarefas. E por isso, eis que trago a solução para os seus problemas (ou erros, neste caso). Se uma task abortar dado ao status do host ser ‘UNREACHABLE’, use ignore_unreachable. Assim o Ansible ignora os erros da tarefa atual, mas permanecendo disponível para executar eventuais futuras tarefas no host que está inacessível no momento 🤩

À nível de task:

- name: This executes, fails, and the failure is ignored
  ansible.builtin.command: /bin/true
  ignore_unreachable: yes

- name: This executes, fails, and ends the play for this host
  ansible.builtin.command: /bin/true

À nível de playbook:

- hosts: all
  ignore_unreachable: yes
  tasks:
  - name: This executes, fails, and the failure is ignored
    ansible.builtin.command: /bin/true

  - name: This executes, fails, and ends the play for this host
    ansible.builtin.command: /bin/true
    ignore_unreachable: no

07-c. Redefinindo hosts inacessíveis

Se o Ansible não puder se conectar a um host, ele marca esse host como ‘UNREACHABLE’ e o remove da lista de hosts ativos para a execução. Você pode usar meta: clear_host_errors para reativar todos os hosts, para que as tarefas subsequentes possam tentar alcançá-los novamente. ( Top demais! 👌💯 )

07-d. Manipuladores e falhas

Ansible executa handlers no final de cada play … Desde a nossa aula passada isso já é fato conhecido! PORÉM, e se uma tarefa notifica um manipulador, mas aí vem uma falha e faz o mesmo, logo em seguida ou posteriormente, na execução do playbook? O que acontece? Bem, o esperado e padrão é o manipulador não ser executado naquele host, o que pode deixar o host em um estado inesperado. Por exemplo, uma tarefa pode atualizar um arquivo de configuração e notificar um manipulador para reiniciar algum serviço. Se uma tarefa posterior na mesma execução falhar, o arquivo de configuração pode ser alterado, mas o serviço não será reiniciado.

Para evitar, reverter ou burlar (nomeie como quiser!) tal comportamento basta usar a opção de linha de comando --force-handlers, incluindo force_handlers: True em uma play, ou adicionando force_handlers = True ao ansible.cfg. Quando os manipuladores são forçados, o Ansible executará todos os manipuladores notificados em todos os hosts, até mesmo hosts com tarefas com falha. (Observe que certos erros ainda podem impedir a execução do handler, como um host inacessível.)

07-e. Definindo uma falha

O Ansible permite definir o que “falha” significa em cada tarefa usando a condição failed_when. Como acontece nas outras condicionais do Ansible, listas com várias condições failed_when são unidas com um and implícito, o que refletindo na tarefa em si, já que a mesma só falha quando todas as condições são atendidas. Caso deseje o oposto disso, que é uma “falha” quando qualquer uma das condições for atendida, você deve definir as condições em uma string com um operador oR explícito.

Você pode verificar se há falhas pesquisando uma palavra ou frase na saída de um comando:

- name: Fail task when the command error output prints FAILED
  ansible.builtin.command: /usr/bin/example-command -x -y -z
  register: command_result
  failed_when: "'FAILED' in command_result.stderr"

Ou baseado no código de retorno:

- name: Fail task when both files are identical
  ansible.builtin.raw: diff foo/file1 bar/file2
  register: diff_cmd
  failed_when: diff_cmd.rc == 0 or diff_cmd.rc >= 2

+ 1 exemplo: combinar múltiplas condições para definir uma “falha”

- name: Check if a file exists in temp and fail task if it does
  ansible.builtin.command: ls /tmp/this_should_not_be_here
  register: result
  failed_when:
    - result.rc == 0
    - '"No such" not in result.stdout'

07-f. Definindo “alterado”

O Ansible permite definir quando uma tarefa específica “mudou” um nó remoto usando a condição changed_when. Isso permite determinar, com base em códigos de retorno ou saída, se uma alteração deve ser relatada nas estatísticas Ansible e se um manipulador deve ser acionado ou não. Como acontece com todas as condicionais em Ansible, listas de várias condições changed_when são unidas com um AND implícito, o que significa que a tarefa só relata uma mudança quando todas as condições são atendidas. Se quiser relatar uma mudança quando qualquer uma das condições for atendida, você deve definir as condições em uma string com um operador OR explícito. Por exemplo:

tasks:

  - name: Report 'changed' when the return code is not equal to 2
    ansible.builtin.shell: /usr/bin/billybass --mode="take me to the river"
    register: bass_result
    changed_when: "bass_result.rc != 2"

  - name: This will never report 'changed' status
    ansible.builtin.shell: wall 'beep'
    changed_when: False

07-g. Garantindo o sucesso para o comando e shell

Os módulos de comando e shell se preocupam com os códigos de retorno, portanto, se você tiver um comando cujo código de saída bem-sucedido não seja zero, você pode fazer o seguinte:

tasks:
  - name: Run this command and ignore the result
    ansible.builtin.shell: /usr/bin/somecommand || /bin/true

07-h. Abortando uma execução em todos os hosts

Às vezes, você deseja que uma falha em um único host, ou falhas em uma certa porcentagem de hosts, aborte a execução inteira em todos os hosts. Você pode interromper a execução da reprodução após a primeira falha acontecer com any_errors_fatal. Para um controle mais refinado, você pode usar max_fail_percentage para abortar a execução após uma determinada porcentagem de hosts falhar.

07-i. Controle de erros em blocos

Veja detalhes e exemplos em https://docs.ansible.com/ansible/latest/user_guide/playbooks_blocks.html#block-error-handling

REFERÊNCIAS:

https://docs.ansible.com/ansible/latest/user_guide/playbooks_error_handling.html#playbooks-error-handling

ANSIBLE SERIES: h.t.wrt* … tasks, plays e books: handlers

CONT. 🔝

🔙 ANTERIOR: BLOCKS

Visto no final do post passado, numa breve participação coadjuvante, e já tendo aparecido em outras oportunidades aqui no BLOG, chegou a hora de conhecer um pouco mais sobre os handlers (traduzindo para o português: manipuladores). Objetiva e diretamente, são um tipo de tarefa que apenas se auto executa quando recebe uma notificação. Por exemplo, reiniciar determinado serviço (daemon) se, e somente se, alguma task modificou sua configuração. Em oposição, não fazer absolutamente nada enquanto tal permanecer inalterada. Outro fato importante, e assim como as variáveis, cada handler precisa ser nomeado exclusivamente.

  • Exemplo;
  • Controlando a execução de um handler (WHEN);
  • Usando variáveis com handlers;

06-a. Handler Example

A seguir, o playbook verify-apache.yml, apresentando uma play com handler simples:

---
- name: Verify apache installation
  hosts: webservers
  vars:
    http_port: 80
    max_clients: 200
  remote_user: root
  tasks:
  - name: Ensure apache is at the latest version
    ansible.builtin.yum:
      name: httpd
      state: latest

  - name: Write the apache config file
    ansible.builtin.template:
      src: /srv/httpd.j2
      dest: /etc/httpd.conf
    notify:
    - Restart apache

  - name: Ensure apache is running
    ansible.builtin.service:
      name: httpd
      state: started

  handlers:
    - name: Restart apache
      ansible.builtin.service:
        name: httpd
        state: restarted

Continuando, mais um playbook. Entretanto, agora é a vez de uma task (anteriormente foi uma play) ser responsável por notificar. Serve para demonstrar que uma única task é capaz de notificar mais de um handler simultaneamente:

- name: Template configuration file
  ansible.builtin.template:
    src: template.j2
    dest: /etc/foo.conf
  notify:
    - Restart memcached
    - Restart apache

  handlers:
    - name: Restart memcached
      ansible.builtin.service:
        name: memcached
        state: restarted

    - name: Restart apache
      ansible.builtin.service:
        name: apache
        state: restarted

06-b. Controlando a execução de um handler (WHEN)

Devido a sua concepção, manipuladores são executados depois que todas as tarefas em uma determinada play foram concluídas. Tal método é eficiente pois o manipulador é executado apenas uma vez, independentemente de quantas tarefas o notificam. Por exemplo, se várias tarefas atualizam um arquivo de configuração e notificam um manipulador para reiniciar o Apache, o Ansible pula o Apache apenas uma vez para evitar reinicializações desnecessárias.

Caso necessite que os handlers sejam executados bem antes do final da execução, basta adicionar uma task que os liberte para tal. Faça uso do ‘meta module’ presente no ansible-base, chamando-o para que o Ansible execute ações:

tasks:
  - name: Some tasks go here
    ansible.builtin.shell: ...

  - name: Flush handlers
    meta:flush_handlers

  - name: Some other tasks
    ansible.builtin.shell: ...

A tarefa meta: flush_handlers aciona todos os manipuladores que foram notificados naquele ponto da play em específico.

06-c. Usando variáveis com handlers

Talvez queira que seus manipuladores usem variáveis. Por exemplo, se o nome de um serviço variar ligeiramente de distro para distro, você espera que sua saída mostre o nome exato do serviço reiniciado para cada máquina de destino. Por isso, evite colocar variáveis no nome do manipulador. Como os nomes do manipulador são modelados desde o início, o Ansible pode não ter um valor disponível para um nome como este aqui:

handlers:
# This handler name may cause your play to fail!
- name: Restart "{{ web_service_name }}"

Se a variável usada no nome do manipulador não estiver disponível, toda a execução falhará. E antes que pense, não! Alterar essa variável “durante” não resultará em um manipulador recém-criado.

Em vez disso, coloque variáveis nos parâmetros de tarefa de seu manipulador. Você pode carregar os valores usando include_vars como este:

tasks:
  - name: Set host variables based on distribution
    include_vars: "{{ ansible_facts.distribution }}.yml"

handlers:
  - name: Restart web service
    ansible.builtin.service:
      name: "{{ web_service_name | default('httpd') }}"
      state: restarted

Os manipuladores também podem “ouvir” tópicos genéricos e as tarefas podem notificar esses tópicos da seguinte maneira:

handlers:
  - name: Restart memcached
    ansible.builtin.service:
      name: memcached
      state: restarted
    listen: "restart web services"

  - name: Restart apache
    ansible.builtin.service:
      name: apache
      state: restarted
    listen: "restart web services"

tasks:
  - name: Restart everything
    ansible.builtin.command: echo "this task will restart the web services"
    notify: "restart web services"

Isso torna muito mais fácil acionar vários manipuladores. Ele também desacopla os manipuladores de seus nomes, facilitando o compartilhamento de manipuladores entre playbooks e roles (especialmente ao usar funções de terceiros de uma fonte compartilhada como o Ansible Galaxy).

REFERÊNCIAS:

https://docs.ansible.com/ansible/latest/user_guide/playbooks_handlers.html#handlers

ANSIBLE SERIES: h.t.wrt* … tasks, plays e books: blocks

UPDATE! / DISCLAIMER: Depois de muitas idas e vindas ao banco … buscas e mais buscas à procura de documentos pessoais que não via há tanto tempo … cópias, xerox, pdf’s, assinaturas … e por fim, infinitas caixas/pacotes para organizar, mofo/poeira para limpar, caminhão da mudança, lavar o piso novo, desempacotar e remontar 😫😓 (…) Estou vivo, de volta e escrevendo da minha própria casa, cujo foi comprada em JUN/2021, também conhecido como ‘mês passado’. Esse foi o real motivo para o BLOG ter ficado tão parado nessas últimas semanas, caros e estimados leitores. Sendo assim, peço desculpas a todos! Espero que não fiquem chateados comigo 😥 MAS, é como dizem por aí: o show não pode parar! Então, retomando do ponto exato aonde paramos, a seguir, +1 capítulo da série ANSIBLE:

CONT. 🔝

🔙 ANTERIOR: CONDITIONALS

Analogamente (ou equivalente, se preferir) a um grupo de linhas dentro do código-fonte, blocos no contexto ‘ansible’ são formas/maneiras de lidar/tratar dois tipos de elemento básico: (a) tasks e (b) erros! Na prática, blocos acabam criando grupos lógicos, sejam micro tarefas que partilham determinado objetivo maior, sejam erros advindos de uma tarefa mal executada, displicentemente planejada. Em ambos os casos, podemos fazer um paralelo com o tratamento de exceções, observadas em outras linguagens de programação.

  • Agrupando tasks com blocos;
  • Tratando erros com blocos;

05-a. Agrupando tasks com blocos

A herança de dados, diretivas, ocorre e se aplica a todas as tarefas comuns (aninhadas) em um mesmo nível de bloco. Ou seja, a diretiva propriamente dita não afeta o bloco em si, mas sim as tasks delimitadas (contidas) por ele. Para exemplificar: uma vez validada e satisfeita a condição imposta pelo when, aplica-se a mesma numa única tacada para as diversas tarefas presentes no bloco em questão. O que é bem diferente de aplicar a ele mesmo, como pode ser levado a crer, e assim, induzido ao erro. A única exceção aqui são os loops. Esteja sempre atento!

tasks:
   - name: Install, configure, and start Apache
     block:
       - name: Install httpd and memcached
         ansible.builtin.yum:
           name:
           - httpd
           - memcached
           state: present

       - name: Apply the foo config template
         ansible.builtin.template:
           src: templates/src.j2
           dest: /etc/foo.conf

       - name: Start service bar and enable it
         ansible.builtin.service:
           name: bar
           state: started
           enabled: True
     when: ansible_facts['distribution'] == 'CentOS'
     become: true
     become_user: root
     ignore_errors: yes

Resumidamente: a condição é avaliada ANTES e TODA VEZ que “alcançamos” um host diferente. Se passar, aí sim serão executadas as três tarefas informadas no bloco, para aquele node específico (e aprovado). O escalonamento e privilégio de root também são herdados, e por tabela, executados na sequência. Por fim, a última linha ignore_errors: yes serve apenas para que o Ansible dê continuidade ao playbook em casos de falhas nas tasks.

**Names for blocks have been available since Ansible 2.3. We recommend using names in all tasks, within blocks or elsewhere, for better visibility into the tasks being executed when you run the playbook.

05-b. Tratando erros com blocos

Trechos do código identificados como blocos, e marcados com as palavras rescue e always, são chamados (igualmente definidos) de sessões. Elas são peças-chave, fundamentais para controlar as respostas direcionadas a possíveis erros de tarefa.

Blocos rescue ditam novas tasks a serem executadas quando uma task anterior (do mesmo bloco) falhar. Tal abordagem é muito parecida com o tratamento de exceções presente em diversas outras linguagens de programação. É importante frisar aqui a seguinte informação: o Ansible somente executa blocos de resgate após uma tarefa retornar estado de FALHA (failed). Tasks definidas incorretamente ou hosts inacessíveis não irão disparar/acionar nenhum bloco de resgate.

tasks:
 - name: Handle the error
   block:
     - name: Print a message
       ansible.builtin.debug:
         msg: 'I execute normally'

     - name: Force a failure
       ansible.builtin.command: /bin/false

     - name: Never print this
       ansible.builtin.debug:
         msg: 'I never execute, due to the above task failing, :-('
   rescue:
     - name: Print when errors
       ansible.builtin.debug:
         msg: 'I caught an error, can do stuff here to fix it, :-)'

Dentro de um bloco também podem haver sessões always. A partir desse ponto, tarefas serão executadas independentemente do status anterior, ou seja, da task anterior.

- name: Always do X
   block:
     - name: Print a message
       ansible.builtin.debug:
         msg: 'I execute normally'

     - name: Force a failure
       ansible.builtin.command: /bin/false

     - name: Never print this
       ansible.builtin.debug:
         msg: 'I never execute :-('
   always:
     - name: Always do this
       ansible.builtin.debug:
         msg: "This always executes, :-)"

Misturados, esses dois fornecem um belo tratamento para erros um pouco mais complexos.

- name: Attempt and graceful roll back demo
  block:
    - name: Print a message
      ansible.builtin.debug:
        msg: 'I execute normally'

    - name: Force a failure
      ansible.builtin.command: /bin/false

    - name: Never print this
      ansible.builtin.debug:
        msg: 'I never execute, due to the above task failing, :-('
  rescue:
    - name: Print when errors
      ansible.builtin.debug:
        msg: 'I caught an error'

    - name: Force a failure in middle of recovery! >:-)
      ansible.builtin.command: /bin/false

    - name: Never print this
      ansible.builtin.debug:
        msg: 'I also never execute :-('
  always:
    - name: Always do this
      ansible.builtin.debug:
        msg: "This always executes"

As tarefas do bloco são executadas normalmente. Se alguma tarefa no bloco retornar failed, a seção de resgate executa tarefas para se recuperar do erro. A seção always é executada independentemente dos resultados das seções block e rescue.

Se ocorrer um erro no bloco e a tarefa de resgate for bem-sucedida, o Ansible reverterá o status de falha da tarefa original para a execução e continuará a executar a reprodução como se a tarefa original tivesse sido bem-sucedida. A tarefa resgatada é considerada bem-sucedida e não aciona configurações max_fail_percentage ou any_errors_fatal. No entanto, Ansible ainda relata uma falha nas estatísticas do playbook.

Use blocos com flush_handlers em uma tarefa de resgate para garantir que todos os manipuladores sejam executados mesmo se ocorrer um erro:

 tasks:
   - name: Attempt and graceful roll back demo
     block:
       - name: Print a message
         ansible.builtin.debug:
           msg: 'I execute normally'
         changed_when: yes
         notify: run me even after an error

       - name: Force a failure
         ansible.builtin.command: /bin/false
     rescue:
       - name: Make sure all handlers run
         meta: flush_handlers
 handlers:
    - name: Run me even after an error
      ansible.builtin.debug:
        msg: 'This handler runs even on error'

**New in version 2.1

**Ansible provides a couple of variables for tasks in the rescue portion of a block:

ansible_failed_task

The task that returned ‘failed’ and triggered the rescue. For example, to get the name use ansible_failed_task.name.

ansible_failed_result

The captured return result of the failed task that triggered the rescue. This would equate to having used this var in the register keyword.

REFERÊNCIAS:

https://docs.ansible.com/ansible/latest/user_guide/playbooks_blocks.html#playbooks-blocks

TOPIC: OUT-OF-THE-BOX … coringa, java e encapsulamento ???

O que se pode aprender sobre programação em um filme de héroi com um certo quê policial? (…) Muito, caso preste atenção e observe os detalhes, sutileza e entrelinhas. Falo de Batman: O Cavaleiro das Trevas, de 2008 e dirigido por Christopher Nolan. Sequência direta de Batman Begins (2005), nela acompanhamos os esforços das mais diversas esferas do poder público de Gotham City para encontrar e capturar o criminoso/terrorista de alcunha ‘Coringa’. Tendo a ajuda de um certo “justiceiro mascarado”, a corrida pelo tempo transforma-se em uma verdadeira caçada para dar fim a onda de ataques e assassinatos que ocorrem por toda a cidade, vitimando desde civis desempenhando suas atividades (policiais, enfermeiros, “mafiosos”😁😆😁 ) até autoridades no exercício de suas funções (juízes, comissários, agentes públicos). OK VICTOR, MAS AONDE QUER CHEGAR? QUAL É O SEU PONTO? E O QUE ISSO TEM A VER COM JAVA? Fique comigo para descobrir e compreender tudo 😉

Bem meus amigos, é como diz aquela velha expressão em inglês: first things first … Cito ela pois farei, a seguir, um adendo na forma de parágrafo único. Trata-se de um fato sobre mim que gostaria de esclarecer. Não sou programador, tão pouco especialista na linguagem Java. Minha formação não é de desenvolvedor, mas sim de administrador de sistemas e infraestrutura. Oficialmente sou tecnólogo em redes, e minhas afinidades são Linux, Cloud, Servicedesk, Monitoramento, Devops, e linguagens estruturadas (aquelas que não são orientadas). Deixo bem explicito essa última porque é bem provável, quase certo na verdade, que em algum momento eu fale alguma “besteira”, inverdade, ou dado incongruente acerca do Java. A minha desculpa é, mais uma vez, não ser um profissional dessa área em específico. Mas, por favor, não pare de ler agora, já que acredito ter feito o dever de casa, me esforçando ao máximo para buscar fontes confiáveis e fidedignas ao assunto. Por último, antes de dar início a pauta, um apelo a todos os leitores sêniores e plenos em JAVA: comente abaixo suas ressalvas e eventuais correções, gosto de ouvir pessoas, relatos e experiências.

JAVA E POO: PAI E CONCEITO

Programação Orientada a Objetos, POO para os íntimos, é definido como um paradigma (forma de pensar) para escrever programas de computador baseando-se exclusivamente em “objetos”. Nesses casos, os dados seriam campos ou atributos, e os códigos em si, procedimentos ou métodos. Em pouquíssimas linhas, a lógica aqui é: (a) construir um objeto menor, (b) que será peça de um objeto maior, (c) que será usado por outro objeto, este maior ainda, (d) cuja a junção e interação com outros objetos maiores formaram um sistema, (e) onde finalmente será operado por um objeto chamado cliente. Exemplos de linguagens genuinamente orientadas (ou seja, significativas, que não suportam multiparadigma): o próprio Java, C++, Ruby, Perl.

Antes do surgimento da POO, os softwares eram completamente estáticos. Traduzindo em miúdos, os “objetos” contidos neles eram imutáveis durante todo o tempo de execução. Uma vez iniciado, nada se cria, nada se modifica (…) Tudo é o que é, e ponto final. Basicamente, essa era a lei vigente. Somente em meados da década de 60 para o início dos anos 70, é que ocorreria a virada de maré, tendo o nome de Simula67. Uma linguagem de programação concebida em Oslo, na Noruega, pelos pesquisadores Kristen Nygaard e Ole-Johan Dahl. Aqui foram apresentados os conceitos de classe e herança, duas características dentre um conjunto fundamental, utilizado para definir a orientação a objeto.

Sua popularização (não da Simula67, e sim da POO), ou BOOM! … aconteceria um pouco mais tarde. Foi na década de 90, com a criação do Java por James Gosling, e também, é claro, graças a outras linguagens com igual premissa. Mas sendo a citada anteriormente uma das mais populares, permanecendo até os dias de hoje.

1 2 3 Appeared in 1995 Java

THE DARK KNIGHT: “BUS DRIVER? WHAT BUS DRIVER?”

Hipoteticamente falando, imagine a seguinte situação: você foi contratado para ser o arquiteto de um assalto a banco (…) Não, não, melhor ainda 💡 Você foi contratado para escrever um programa que simula um assalto a determinado banco. Evidentemente, o êxito de tal código apenas será considerado se duas condições forem satisfeitas: (A) pelo menos um dos participantes deverá sair vivo e (B) todo o dinheiro que está na sala-cofre precisa ser retirado, movido e transportado junto. E então? Como você faria? 🤔 Difícil não? Possibilidades: (1) armamento pesado e explosivos? (2) captura de reféns para distração e negociação? (3) escavar um túnel subterrâneo até o cofre principal? (4) ataque hacker para causar um apagão interno ou roubo da grana virtualmente? (5) dispersar várias equipes, em pequenos grupos, para realizar ocorrências e delitos por toda a cidade, com o intuito de consumir os recursos locais das autoridades (viaturas, policiais, comunicação, bombeiros, etc)? Pelos parágrafos sucessores ao corrente, deixarei a minha sugestão de plano/script para tamanho objetivo.

Primeiro, divida o seu time de integrantes em dois. Um será incumbido da abordagem tradicional, velha guarda e ortodoxa da coisa, ou seja, basicamente entrar pela porta da frente anunciando o assalto, atirando para o alto e neutralizando pessoal da segurança. Em contrapartida, o outro grupo será a força técnica e especializada, responsável por desativar alarmes, burlar portas e fechaduras eletrônicas, transpor barreiras físicas como paredes e afins, e finalmente descobrir o segredo e ter acessar ao cofre aonde está todo o dinheiro. Muito óbvio, trivial e simples para o leitor? Pois aqui vai o meu pulo do gato 🐱 Se o trabalho de mentoria foi única e exclusivamente seu, por que não ficar com louros da sua conquista apenas para si? Afinal você é o cérebro da operação, não é mesmo?! Portanto, sendo assim, escreva o seguinte em seu pseudo código-fonte …

< BEGIN_OF_CODE >

Fazer reuniões de planejamento, ação, sincronismo e ajustes, que visam definir cada etapa do processo, somente com um (no máximo dois capangas) por vez. A intenção aqui é não deixar que ninguém conheça completamente como é feita a tarefa do outro, e muito menos ter ciência do panorama geral com riqueza de detalhes.

Além de dividi-los em dois grandes times, conforme mencionado no início, divida-os ainda mais em subgrupos (duplas ou trios) para evitar desentendimentos, brigas ou contratempos ocasionados pelas emoções/sentimentos da natureza humana. Esse é um fator impossível de eliminar já que é algo intrínseco e inerente ao homem. Por isso, o mesmo precisa ser mitigado ao máximo possível, para conter eventuais danos.

Escolha a dedo um indivíduo de cada subgrupo para eliminar o seu parceiro, uma vez que o segundo tenha concluído seu trabalho. Mas antes da execução sumária, oriente para que o primeiro deve aguardar um pouco e confirmar, tanto verbalmente quanto visualmente, o sucesso do seu companheiro. Isso despertará sua ambição interna e ganância por dinheiro, pois dessa forma será uma parte a menos para dividir no final, instigando assim dez vezes mais a desempenhar seu papel com perfeição.

Não fique apenas sentando atrás de uma mesa … Coordenando a ação por telefone ou computador … Não, não. Levanta-se! Vá a campo e infiltre-se na sua própria operação! Reforce a importância de todos usarem mascará (o que inclui você) para não serem rastreados depois, e também para que seus “subordinados” não saibam que o chefe está bem ao lado, supervisionando.

Finalmente, e caso tudo ocorra bem, no hall de entrada do banco, ponto de encontro e extração, sobrará apenas você e um capanga (talvez dois). Terminado de arrastar as malas de dinheiro, o(s) capanga(s) restante(s) será(ão) um daquele(s) instruído(s) a eliminar os eventuais remanescentes da equipe. Então, esteja preparado! Verá a si mesmo tornar-se um alvo ambulante. Será indagado e acusado pela suspeita de que o chefe da operação lhe disse a mesma coisa que ordenou para os outros: elimine as partes. Ganhe tempo, movimente-se devagar, posicione-se para longe da porta e confunda-o falando que está errado, pois você está encarregado de matar o motorista do ônibus (…)

– Aposto que o chefe te disse para me matar quando terminássemos.

– Não, não, não. Eu mato o motorista do ônibus!

– Que motorista? De que ônibus? AAARRGGHHHH

– ( Veículo entra de ré e atropela o dito comparsa )

– Esse aí não levanta mais … Levanta?

– ( Gesto negativo com a cabeça )

– O que houve com o resto dos caras?

– ( Disparo de tiros da sua submetralhadora apontada para o peito do motorista )

Pronto! Está feito! Sucesso absoluto!!! Carregue o ônibus com as sacolas, entre e dirija. Saia para a rua no momento em que um comboio de ônibus escolares está passando e se camufle enquanto as viaturas policiais vão no sentido contrário em direção ao banco.

Daily Heath Ledger — daily-joker: THE DARK KNIGHT 2008 |...
Figura 01. Você ☝
Daily Heath Ledger — daily-joker: THE DARK KNIGHT 2008 |...
Figura 02. O comparsa ☝

< END_OF_CODE />

ENCAPSULAMENTO: LEITURA RECOMENDADA

https://dzone.com/articles/why-encapsulation-matters

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.36.8552&rep=rep1&type=pdf

REFERÊNCIAS NERD: BATMAN O CAVALEIRO DAS TREVAS

https://www.youtube.com/watch?v=8VEGGgp-M2w

https://www.youtube.com/watch?v=vetKTtM7YyU

VICRLDA: 24 de maio de 2012

Aonde você estava na presente data logo acima? O que estava fazendo naquele dia? Sozinho ou com alguém? … Não, não … Me antecipando, e antes que me perguntem: não, eu não migrei de área, tampouco virei detetive particular ou perito forense. Talvez a minha resposta fosse igual a sua, que acredito ter sido SEI LÁ VICTOR ! NÃO ME LEMBRO !

Pois é, nove anos atrás é tempo demais para recordar eventos tão precisamente assim. No meu caso, somente sou capaz de afirmar com tanta certeza graças ao YouTube. HÃ? COMO É? Mas foi isso mesmo que acabou de ouvir! Senão fosse os três vídeos que estavam privados na minha conta eu também não saberia dizer.

Tudo aconteceu graças ao professor Thiago Gouveia, responsável pela disciplina de Administração de Sistemas Abertos, e docente no Instituto Federal de Educação, Ciência e Tecnologia da Paraíba (IFPB). Estávamos na metade do semestre letivo e como segunda nota ficou definido um seminário online por aluno, que deveria ser disponibilizado na forma de vídeo na plataforma Youtube. Sorteados tais temas, na verdade ferramentas, acabei pegando o Webmin. Ele existe até hoje, e você pode conferir em https://www.webmin.com/

Sendo considerado uma interface para gestão de servidores linux, ou melhor, uma web console para administrar sistemas Unix, o mesmo mostra-se uma excelente ferramenta para aprender e praticar conceitos básicos. Kernel, pacotes, estrutura e organização de diretórios, são alguns deles. Altamente recomendado para iniciantes mas também igualmente aos usuários de longa data, tendo em vista que os objetivos são os mesmos: facilitar a administração centralizando-a em um único ponto, e melhorar a interação tornando-a o mais gráfica possível.

Voltando ao seminário … Decidi transformar minha conta pessoal em um canal público no YouTube. Essa será outra forma de transmitir conteúdo para vocês, além de socializar. Trocaremos ideias, sugestão de novas pautas, tirar dúvidas através dos comentários, e afins. Por enquanto, e como podem imaginar, não há tanto conteúdo nele. Apenas três vídeos que compõem as partes da minha apresentação sobre o Webmin. São elas: 1) introdução e teoria; 2) instalação e configuração no Debian; 3) módulos e exercícios práticos.

Caso possa e tenha interesse, por favor, peço que se inscreva, favorite e compartilhe os vídeos com mais pessoas. Dessa maneira você dará relevância ao conteúdo, ajudará no crescimento da nossa comunidade e no alcance ao compartilhar assuntos opensource internet afora.

Espero que gostem e se divirtam! Câmbio e desligo!

https://www.youtube.com/channel/UCeY2sSz4ueavFyN0rSTgBog

BLOG SERIES: uma pausa nos estudos, lição de casa, +1 categoria, revisões periódicas e próximos posts

Olá querido leitor! E bem-vindo de volta! O sentimento que espero sempre despertar ao cumprimentá-lo, é basicamente: empatia e companheirismo. Acredito que não exista nada mais humano, nobre e belo (em uma palavra: gratificante) do que se colocar no lugar do outro, compreendê-lo, e ajudá-lo a evoluir/crescer, ensinando como você chegou ao ponto em que está hoje. Digo isso pois já fui um calouro na universidade, como sabem em um curso de tecnologia. Por vezes ao mesmo tempo que estava maravilhado com as linguagens, ide’s, sistemas operacionais, laborátorios de rede, etc, me peguei diversas outras assustado com algumas disciplinas e conteúdos específicos (alô Cálculo I, Física I, Java 😅). É claro que ao longo desse tempo tive ajuda de colegas, professores, veteranos, e amigos da área. A mesma coisa seguiu quando conclui, sai e entrei no mercado de trabalho … Foram meus pares (técnicos, analistas) e superiores (gerentes, diretores) que me auxiliaram na minha jornada profissional. Na verdade isso acontece até o presente momento, tendo em vista que a minha carreira ainda não terminou 👨‍💻

Pois muito bem, contada tal minibiografia, gostaria de resgatar brevemente (prometo!) a ideia por trás desse BLOG e sua disposição de conteúdos. DE NOVO VICTOR?! Calma, calma … Eu sei, eu sei … Somente faço isso pensando em um recém-chegado que caiu de paraquedas nessa postagem. Será rápido e indolor, palavra de escoteiro:

SERIES: Toda vez que um(a) ferramenta/tema/tópico for abordado(a) e identificado(a) por esse termo, saibam que trata-se do início de uma série de postagens ou faz parte de um mesmo conjunto prévio anteriormente criado. PLUS+: Aqui os posts darão continuidade a série “finalizada” da ferramenta presente no título. São uma espécie de extra, dica ou macete que aprendi no dia-a-dia. Algumas vezes tive que correr atrás, pesquisando, testando e documentando. Foi aí que me ocorreu a ideia de compartilhá-las separando-as em um contexto à parte. NEWS: Sugestivo e como a própria tradução do inglês para o português – serão notícias, novidades, atualizações e divulgação de eventos mundo afora. Minhas fontes? Canais oficiais das empresas/organizações responsáveis pelas ferramentas (websites, twitter, contas youtube, newsletter, RSS, etc.)

https://machinesbecomeservices.com/2020/11/04/vicrlda-im-alive-voltei-retorno-notas-e-avisos/

Igualmente importante, e sobre a categoria BLOG do site, segue:

A cada vez, quando quiser interagir, visando definir ou informar algo para o futuro (anúncios, enquetes, consultas, questionários) colocarei no início do título BLOG Series, categorizando o artigo como Blog, e marcando o texto com TAG “blog “.

https://machinesbecomeservices.com/2021/03/22/vicrlda-1-ano-25-posts-3-178-views-803-visitas-7-seguidores-no-wordpress-com/

Acerca da alternância e ordem dos posts, essas são as minhas diretrizes:

1º mandamento: Sempre que começar uma SÉRIE, terminar o mais breve possível (em um futuro próximo). Nunca, jamais deixá-la no limbo e retomar depois. O raciocínio se perde e a lógica se esvai. 2º mandamento: Manter no ar (online/disponível) no máximo duas ou três SÉRIES simultâneas. Mais que isso, corre o risco de comandos, códigos e conceitos serem trocados, gerando dessa forma uma baita confusão. 3º mandamento: Entre uma SÉRIE e outra, durante seus intervalos, fazer pequenas pausas trazendo conteúdo menos denso. Por exemplo, notícias (NEWS) e extras (PLUS+). A justificativa é dar tempo para efeitos de laboração e assimilação da(s) SÉRIE(s) principal(is).

https://machinesbecomeservices.com/2021/02/09/zabbix-series-teoria-monitoramento-e-os-3-qs-o-que-por-que-para-que/

Em suma, foi baseado nessas três colunas (ou como as chamo: pilares de argumento) que tomei algumas decisões, e portanto faço aqui anúncios relativos aos próximos eventos do BLOG.

  • Pequena pausa nas séries, incluindo (e principalmente) o Ansible … A ideia é dar tempo para laborar, praticar e buscar novos materiais. Quero dizer, por conta própria, sozinhos é claro. SUGESTÃO: referências/bibliografia que julguem interessantes, por favor, peço que compartilhem abaixo nos comentários. Tenho curiosidade, e seria bom também para os demais leitores, na minha opinião.
  • Os próximos dois posts serão, respectivamente:
    • um artigo pessoal, divulgando outro meio de interagir e revisar assuntos com vocês. Aguardem!
    • um texto inaugural, apresentando uma nova categoria. Tomara que gostem da proposta!

No mais, se cuidem, usem máscara, fiquem em casa, vacina sim, e esperança sempre!

Até logo!

%d blogueiros gostam disto: