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/

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!

ANSIBLE SERIES: h.t.wrt* … tasks, plays e books: como escrevê-los?

* Sigla para: < How To Write >

Recapitulando o que vimos até o momento acerca do Ansible:

  • Teoria
    • DevOps: conceito, história, curiosidades ✅
    • Por que automatizar com ansible? ✅
    • 5 conceitos fundamentais ✅
  • Prática
    • Linha de comando, hello.YML e Ad-Hoc ✅
    • Web console: AWX/TOWER ✅
    • Como executar um JOB graficamente em tempo real ✅

Poxa vida! 😲 Eu diria um bocado não é mesmo? Sendo ou não, o que importa é que a estrada ainda se encontra a nossa frente e aos poucos, devagar, mas com passos firmes vamos progredindo no ROADMAP de um DEVOPS. Portanto, e acho que todos já estão acostumados com as minhas deixas (ou chamados) para iniciar um POST do blog … Hey Ho! Let’s go!

Muito bem jovens, ao que interessa então. Se você já buscou material, ou até mesmo cursou algum tipo de preparatório para o Ansible, as chances do professor ter abordado logo no começo (imediatamente após o briefing/overview) esses itens que vou mostrar é muito grande. Em outras palavras, e simplificando, acredito que tenha sido dessa forma: 1. o que é ansible? / 2. definições e termos / 3. prompt, módulos e comandos ad-hoc / para finalmente chegar em 4. como escrever playbooks. Por último é que eles mostram o AWX, boas práticas, roles, hosts windows, network e paramiko, etc. Mas e daí Victor? Eu sei, não há nada de errado com isso. Cada um ministra e monta seu plano de aulas da maneira que achar melhor aos estudantes. E tudo bem, ok. Mas no nosso caso, vocês e eu, quis inverter um pouco as coisas e adiantar logo a parte gráfica do ansible, ou seja, o tower/awx. Na verdade o meu intuito era “cativar” a todos apresentando de cara as duas faces do mesmo: linha de comando e interface web. Assim cada pessoa poderia escolher a melhor forma de trabalhar, de acordo com seu gosto e afinidade. Gosta de terminal? Ótimo, vá de CLI e seja feliz! Não, prefiro botões, gráficos e menus. Maravilha, pegue a GUI e curta a vida! O que quero dizer aqui é não existe método certo ou errado, melhor ou pior. Não, pelo contrário, há vantagens e desvantagens em cada um deles. Cabe tão somente a você pesar os prós e contras e escolher sua forma de operar. Lembrando sempre que é possível combiná-las tá? Por exemplo, tal tarefa é mais rápido e comodo se fizer via bash, já aquela outra é necessário maior controle de usuários e permissões, então farei por meio da web. Entenderam? Ou enrolei demais? 🤔

POOL DE INFORMAÇÕES

https://docs.ansible.com/

Desde sempre admirei empresas de tecnologia, bem antes de entrar na faculdade. Talvez por isso que enveredei para este ramo. Google, Microsoft, IBM, Facebook, e tantas outras (ora gigantes, ora um pouco mais modestas) foram alguns exemplos de modelo a perseguir, almejar e quem sabe um dia entrar no time… Uma vez imerso nesse grande oceano, chamado TI, passei a ter bastante contato com Linux e suas distros. Além de ter curtido, comecei a ficar de olho, meio que acompanhar notícias e bastidores das empresas idealizadoras/responsáveis. Foi assim que fiquei maravilhado com todo o trabalho por trás de cada uma dessas distribuições. Digo, não apenas o resultado final: o lançamento periódico de novas versões. Mas sim o suporte, divulgação, comunidades, fóruns oficiais, documentação, e afins. Também vale um destaque especial, o principal “cartão de visita” dessas empresas: os websites. Falo sério, você já acessou a Canonical, Red Hat, Suse e System76 ?? É verdadeiro deleite, e de encher os olhos, devido a tanto primor e cuidado com o design e layout. São muito bonitos, sem exceção!!!

E como prova disso, trago a seguir uma captura de tela da página INDEX da documentação do ansible. Podemos dizer que ela é uma espécie de hub central, uma vitrine, para orientar sobre tudo que o mesmo é capaz, e como fazer. Confiram:

Figura 01. Docs INDEX page

Acima devidamente circulado está o nosso foco: a documentação base, ou seja, relacionada ao núcleo, chamado de ansible-core. Pelas próximas semanas vamos nos debruçar sobre a sintaxe, lógica, melhores práticas, organização de pastas e arquivos, reuso de código, otimização, e muito mais. Para isso, irei sempre pontuar já no título do POST em questão, o que vamos aprender nele. Ex: loops, variáveis, templates, roles, e assim por diante.

Qualquer dúvida ou lacuna que porventura tenha deixado, acessem o link e vão direto na fonte para saná-las. Até porque não pretendo abordar absolutamente tudo que está lá, ok? Senão o que estaria fazendo é um simples CTRL-C + CTRL-V do referido conteúdo. E isso não quero, e tão é algo ético. Resumindo: antes de ler aqui, recomendo dar uma estudada pela oficial, por favor. Embora prometo fazer o meu melhor para se aproximar ao máximo dos mestres da Red Hat 🎩

01-a. BECOME: acesso, usuários e permissões

Ansible utiliza meios de escalonamento de privilégios pré-existentes na máquina remota. Isso é o que eles chamam de become. Ele seria o equivalente ao su, sudo, runas e similares. O objetivo é tanto permitir quanto executar tarefas locais nos alvos (nodes), usando privilégios de root ou qualquer outra permissão já criada dentro do nó. O efeito prático disso é torna-se outro usuário¹ dentro do host² em questão, sendo o primeiro completamente diferente daquele que usou para entrar no segundo.

i ) Usando o become

É possível controlá-lo através de tasks, plays, variáveis de conexão ou linha de comando. Em caso de duas ou mais ao mesmo tempo (sim, isso é válido e às vezes comum) consulte atentamente as regras de precedência para as mesmas. Leia mais aqui: https://docs.ansible.com/ansible/latest/reference_appendices/general_precedence.html#general-precedence-rules

! ! ! Diretivas do become ! ! !

Estabeleça como definir o become, controlando o mesmo à nível de task ou play. Variáveis e diretivas são independentes entre si. Por exemplo, definir become_user não é a mesma coisa que “só” become.

become: defina para 'yes' e ative o escalonamento de privilégios
become_user : defina o usuário com os privilégios desejados. ou seja, a credencial que você pretende se tornar e não o usuário que fez login.
become_method : (à nível de play ou task) sobrescreve o método padrão definido em ansible.cfg
become_flags :(à nível de play ou task) permite o uso de flags específicas para uma tarefa ou play. bastante comum quando se quer mudar o usuário para 'nobody' em casos de 'shell' setado para 'nologin'

Por exemplo,

Gerenciar um serviço (daemon) que requer privilégios de root … Em um cenário onde o usuário conectado não é root … Neste caso, utilizamos o valor padrão de become_user, que é justamente ‘root’

- name: Ensure the httpd service is running
  service:
    name: httpd
    state: started
  become: yes

Executar algo como ‘nobody’ quando o shell (terminal) está configurado para ‘nologin’

- name: Run a command as nobody
  command: somecommand
  become: yes
  become_method: su
  become_user: nobody
  become_flags: '-s /bin/sh'

To specify a password for sudo, run ansible-playbook with --ask-become-pass (-K for short). If you run a playbook utilizing become and the playbook seems to hang, most likely it is stuck at the privilege escalation prompt. Stop it with CTRL-c, then execute the playbook with -K and the appropriate password.

! ! ! Variáveis de conexão ! ! !

Nós e grupos suportam diversas, e distintas, opções ‘become’. Em cada gerenciável existe a possibilidade de defini-las em um arquivo inventário, ou usá-las como se fossem variáveis comuns.

São elas,

ansible_become: em termos de finalidade, praticamente uma cópia da diretiva become. ou seja, define se o escalonamento de privilégio será utilizado ou não.
ansible_become_method: escolhe qual forma de privilégio será usada.
ansible_become_user: dita qual usuário você irá se tornar via método de escalonamento. não é a mesma coisa que ansible_become: yes
ansible_become_password: senha do usuário citado anteriormente. é possível, mas não aconselhável, passar segredos em texto plano. aprenda formas mais seguras em https://docs.ansible.com/ansible/latest/user_guide/vault.html#playbooks-vault
! ! ! Opções na linha de comando ! ! !
--ask-become-pass OU -K
Solicita a senha "privilegiada" ... É usada para todos os hosts
--become OU -b
Executa as instruções com o become ... Não necessariamente haverá sempre uma senha
--become-method=BECOME_METHOD
Método utilizado ... Padrão = SUDO ... Outros [su | pbrun | pfexec | doas | dzdo | ksu | runas | machinectl]
--become-user=BECOME_USER
Rode os comandos como este 'usuário' ... Padrão = ROOT ... Não é o mesmo que --become ou -b

ii ) RISCOS E LIMITAÇÕES DO BECOME

Intuitivo mas não perfeito, o become apresenta certas limitações em sua capacidade. O que gera algumas questões “interessantes” a serem avaliadas, para que não se transformem em “desagradáveis”. Todas elas podem ser estudadas no link a seguir:

https://docs.ansible.com/ansible/latest/user_guide/become.html#risks-and-limitations-of-become

  • Riscos de se tornar um usuário sem privilégios
  • Não compatível com todos os plug-ins de conexão
  • Apenas um método pode ser habilitado por host
  • O escalonamento de privilégios deve ser generalista
  • Talvez não seja possível acessar variáveis de ambiente preenchidas por pamd_systemd

CONTINUA (…)

Próximo post >>> LOOPS

REFERÊNCIAS:

https://docs.ansible.com/

https://docs.ansible.com/core.html

https://docs.ansible.com/ansible/latest/

https://docs.ansible.com/ansible/latest/user_guide/index.html

https://docs.ansible.com/ansible/latest/user_guide/index.html#writing-tasks-plays-and-playbooks

https://docs.ansible.com/ansible/latest/user_guide/become.html#become