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

CONT.

👈 ANTERIOR: WHERE TASKS RUN ?

Condicionais, em bom português, são aquelas famosas palavrinhas que aprendemos (lógica da programação) com o intuito de:

  • parar momentaneamente o fluxo do programa;
  • desviar a sequência ou conteúdo de variável para um bloco de código que faz checagem;
  • chamar uma função ou sub-rotina;
  • capturar exceções e tratá-las;
  • exibir informações ou mensagens ao usuário;
  • dentre outras tarefas.

Pois bem, alguns exemplos dessas palavras que normalmente usamos para tais propósitos: SE, SENÃO, ENTÃO, ENQUANTO, PARA, E, OU, NÃO (!not) …

No casos dos playbooks, nossos objetivos vão desde: (a) executar diferentes tasks que dependem do valor de um fato (dado de um host remoto), variável ou resultado anterior (b) atribuir valor a uma variável baseando-se em outra variável precedente (c) definir e criar novos grupos de hosts em cima de alguns critérios de correspondência.

Uma pequena ressalva da documentação oficial:

Ansible usa testes e filtros Jinja2 em condicionais. O Ansible oferece suporte a todos os testes e filtros padrão e também adiciona alguns exclusivos

https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#playbooks-conditionals

E uma pequena nota de rodapé:

Existem muitas opções para controlar o fluxo de execução no Ansible. Você pode encontrar mais exemplos de condicionais com suporte em https://jinja.palletsprojects.com/en/master/templates/#comparisons

https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#playbooks-conditionals

Devido ao sumário de tamanho “razoável” que esta seção apresenta na wiki oficial, tentarei ao máximo fazer breves explanações dos códigos e talvez pule algumas delas, seja porque são muito raras de utilizar ou porque fogem muito dos nossos objetivos, ok?

Figura 01. Sumário da seção (docs.ansible.com)

04-a. Condicionais básicas com WHEN

A unidade mais básica para uma condicional, chamada por alguns de “declaração mais simples”, é essencialmente aplicada a uma única tarefa por vez. Na prática, isso quer dizer que, quando se cria uma tarefa, seguida de uma declaração when, um teste será executado. Essa cláusula when na verdade é uma expressão Jinja2 bruta e sem chaves duplas. Quando se roda uma task ou playbook o que acontece é que o Ansible valida esse teste para todos os hosts remotos. Se qualquer um deles “passar na prova”, o valor retornado é true, e então a task é executada. Para ilustrar, um exemplo:

tasks:
  - name: Configure SELinux to start mysql on any port
    ansible.posix.seboolean:
      name: mysql_connect_any
      state: true
      persistent: yes
    when: ansible_selinux.status == "enabled"
    # all variables can be used directly in conditionals without double curly braces

! ! ! BASEADAS EM ANSIBLE_FACTS ! ! !

Às vezes, ao invés de executar tarefas, simplesmente queremos o oposto. Em outras palavras, desejamos pulá-las e passar adiante. Isso pode ser feito através dos fatos, ou melhor, por meio dos atributos (dados) de um node específico. IP, SO, filesystem, status, são apenas alguns para citar.

Com as condicionais baseadas em fatos, é possível:

  • instalar pacotes somente para determinadas versões ou famílias de um sistema operacional
  • pular configurações de firewall para hosts internos à rede
  • fazer uma limpeza em sistemas de arquivos muito cheios

Veja quais fatos estão disponíveis em cada host, acrescentando uma simples tarefa do tipo debug:

- name: Show facts available on the system
  ansible.builtin.debug:
    var: ansible_facts

Exemplo 1 x 1: uma condicional para um fato

tasks:
  - name: Shut down Debian flavored systems
    ansible.builtin.command: /sbin/shutdown -t now
    when: ansible_facts['os_family'] == "Debian"

Exemplo N x N: múltiplas condicionais para múltiplos fatos

tasks:
  - name: Shut down CentOS 6 and Debian 7 systems
    ansible.builtin.command: /sbin/shutdown -t now
    when: (ansible_facts['distribution'] == "CentOS" and ansible_facts['distribution_major_version'] == "6") or
          (ansible_facts['distribution'] == "Debian" and ansible_facts['distribution_major_version'] == "7")

Outra forma, um pouco mais abreviada:

tasks:
  - name: Shut down CentOS 6 systems
    ansible.builtin.command: /sbin/shutdown -t now
    when:
      - ansible_facts['distribution'] == "CentOS"
      - ansible_facts['distribution_major_version'] == "6"

https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#commonly-used-facts

! ! ! BASEADAS EM VARIÁVEIS ! ! !

Você também pode criar condicionais com base em variáveis definidas nos playbooks ou inventários. Como as condicionais requerem entrada booleana (um teste deve ser avaliado como True para acionar a condição), você deve aplicar o | Filtro booleano para variáveis não booleanas, como variáveis de string com conteúdo como ‘sim’, ‘ativado’, ‘1’ ou ‘verdadeiro’.

https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#conditionals-based-on-variables

Defina suas variáveis exatamente assim:

vars:
  epic: true
  monumental: "yes"

Agora execute o código a seguir:

tasks:
    - name: Run the command if "epic" or "monumental" is true
      ansible.builtin.shell: echo "This certainly is epic!"
      when: epic or monumental | bool

    - name: Run the command if "epic" is false
      ansible.builtin.shell: echo "This certainly isn't epic!"
      when: not epic

Verá que o Ansible roda uma delas e pula a outra!

! ! ! BASEADAS EM LOOPS ! ! !

Processa a condição separadamente para cada item presente no laço. Isso ocorre para que você possa executar a tarefa em alguns elementos e ignorá-la em outros. Por exemplo:

tasks:
    - name: Run with items greater than 5
      ansible.builtin.command: echo {{ item }}
      loop: [ 0, 2, 4, 6, 8, 10 ]
      when: item > 5

Sobre uma lista:

- name: Skip the whole task when a loop variable is undefined
  ansible.builtin.command: echo {{ item }}
  loop: "{{ mylist|default([]) }}"
  when: item > 5

Sobre um dicionário:

- name: The same as above using a dict
  ansible.builtin.command: echo {{ item.key }}
  loop: "{{ query('dict', mydict|default({})) }}"
  when: item.value > 5

CONTINUA (…)

Próximo post >>> Blocks

REFERÊNCIAS:

https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#playbooks-conditionals

ANSIBLE SERIES: h.t.wrt* … tasks, plays e books: where tasks run ???

CONT.

👈 ANTERIOR: LOOPS

Ao executar um playbook, o comportamento que se espera do Ansible é:

  1. antes, reunir todos os fatos referentes aos nodes ( gather_facts )
  2. depois, rodar as tarefas especificadas ( playbook ) somente nas máquinas-alvo que estão expressas ou de acordo com a linha “hosts” , presente no próprio main.yml, test.yml por exemplo.

Dito isso, quatro caminhos estão abertos ao admin responsável (você, eu). São eles:

  • delegar tarefas a uma máquina em particular
  • delegar tarefas a um grupo específico
  • delegar fatos a uma série de hosts ou grupos
  • executar um playbook inteiro localmente

03-a. Tasks que NÃO podem ser delegadas !!!

A execução de algumas pouquíssimas tarefas está restrita apenas ao controlador, e essas sempre serão rodadas única e exclusivamente nele, não importando o que você faça. include , add_hosts , e debug integram essa lista, não podendo de forma nenhuma serem delegadas a terceiros.

03-b. Delegando tasks . . .

Agora sim meus caros colegas 😉, tarefas que podem ser delegadas para nodes remotos. Trecho a seguir retirado da documentação oficial:

Se você deseja executar uma tarefa em um host com referência a outros hosts, use a palavra-chave delegate_to em uma tarefa. Isso é ideal para gerenciar nós em um pool com carga balanceada ou para controlar janelas de interrupção. Você pode usar a delegação com a palavra-chave serial para controlar o número de hosts em execução ao mesmo tempo

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#delegating-tasks
---
- hosts: webservers
  serial: 5

  tasks:
    - name: Take out of load balancer pool
      ansible.builtin.command: /usr/bin/take_out_of_pool {{ inventory_hostname }}
      delegate_to: 127.0.0.1

    - name: Actual steps would go here
      ansible.builtin.yum:
        name: acme-web-stack
        state: latest

    - name: Add back to load balancer pool
      ansible.builtin.command: /usr/bin/add_back_to_pool {{ inventory_hostname }}
      delegate_to: 127.0.0.1

** 127.0.0.1 : significa que será rodado na máquina corrente, ou seja, localmente naquela que executa o Ansible!

03-c. Delegando fatos . . .

Delegar tarefas do Ansible é como delegar tarefas no mundo real – seus mantimentos pertencem a você, mesmo que outra pessoa os entregue em sua casa. Da mesma forma, quaisquer fatos reunidos por uma tarefa delegada são atribuídos por padrão ao inventory_hostname (o host atual), não ao host que produziu os fatos (o delegado ao host). Para atribuir fatos coletados ao host delegado em vez do host atual, defina delegate_facts como true.

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#delegating-facts
---
- hosts: app_servers

  tasks:
    - name: Gather facts from db servers
      ansible.builtin.setup:
      delegate_to: "{{ item }}"
      delegate_facts: true
      loop: "{{ groups['dbservers'] }}"

Esta tarefa reúne fatos para as máquinas no grupo dbservers e atribui os fatos a essas máquinas, mesmo que a play seja direcionado ao grupo app_servers. Desta forma, você pode pesquisar hostvars [‘dbhost1’] [‘ansible_default_ipv4’] [‘endereço’], mesmo que dbservers não tenham feito parte da peça ou deixados de fora usando –limit.

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#delegating-facts

03-d. Playbooks locais . . .

Pode ser útil usar um playbook localmente em um host remoto, ao invés de conectar por SSH. Isso pode ser usado para garantir a configuração de um sistema, colocando um playbook em um crontab.

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#local-playbooks
ansible-playbook playbook.yml --connection=local
---
- hosts: 127.0.0.1
  connection: local

CONTINUA (…)

Próximo post >>> Conditionals

REFERÊNCIAS:

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#playbooks-delegation

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

CONT.

👈 ANTERIOR: BECOME

O que fazer quando é necessário repetir determinada ação mais de uma vez ??? Automatizar, é claro, você diria … Tudo bem, já entendi que pegou o espírito da coisa 🙃 E fico deveras feliz por isso, diga-se de passagem! Mas, o que eu quis dizer é como fazê-lo em pormenores? Como executar valendo-se da lógica da programação? Há duas respostas válidas, contudo uma é mais inteligente e menos trabalhosa, e a outra é mais lenta (para não desmerecê-la 😬 haha) e braçal. A primeira delas seria utilizar um monte de IF’s e ELSE’s para cada entrada, interação ou condição. Em contrapartida, a segunda seria criar um laço (daí seu nome loop, em inglês) com uma variável “contador” interna. Essa controlaria a execução do mesmo em N vezes, e até que a condição X fosse satisfeita. Resultado? Um código mais bonito, limpo, enxuto, com menos linhas, e mais otimizado.

No contexto do Ansible, ou de qualquer outra ferramenta de automação, tais ações “repetitivas” abrangeriam desde adicionar vários usuários, replicar uma configuração em um pool de máquinas, até mudar a propriedade/permissão (ou dono) de uma série de arquivos e pastas, por exemplo. Para tal o ansible nos fornece duas palavras-chave: loop e with_<lookup> (lookup em português pode ser traduzido como busca, pesquisa, chave ou valor).

Antes de expor e debater os tópicos a seguir, cabe aqui, e quero destacar algumas notas acerca do recurso loop :

  • Foi introduzido a partir do Ansible 2.5
  • Está presente em todas as versões sucessoras (2.5+)
  • Ainda não substitui completamente o with_<lookup>, embora a ideia seja exatamente essa no futuro.
  • Na maioria dos casos recomenda-se, e satisfaz muito bem, o uso do loop . Somente em situações extremamente específicas o with_<lookup> dá pleno suporte, o que acaba “vencendo” seu concorrente amigo, e portanto o uso dele é o único meio viável para solucionar.
  • Não está obsoleta ou tão pouco depreciada a sintaxe do with_lookup, continuando assim totalmente válida, embora isso possa mudar no médio-longo prazo.
  • O loop encontra-se em constante mudança visando principalmente seu aperfeiçoamento. Para atualizações e alterações do mesmo, por favor consultar o CHANGELOG https://github.com/ansible/ansible/tree/devel/changelogs

02-a. Comparativo entre loop e with_*

As únicas palavras-chave capazes de complementar o with_ são aquelas que estão disponíveis em https://docs.ansible.com/ansible/latest/plugins/lookup.html#lookup-plugins Ou seja, na prática, qualquer uma delas quando utilizadas correspondem ao asterisco (presente no título desta sessão). Para refrescar a memória, * é conhecido também como o caractere-curinga na computação, especificamente quando falamos em interpretadores de comandos nos sistemas operacionais.

A palavra loop é o mesmo que usar a expressão with_list, sendo a primeira uma melhor escolha para loops que não possuem tanta complexidade. Porém, o loop não aceita como entrada nenhuma ‘string’. Veja mais em https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html#query-vs-lookup

Genericamente, e simplificando bastante, qualquer with_* pode facilmente ser trocado por loop. Claro que salva as devidas proporções e ressalvas, todas essas descritas aqui https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html#migrating-to-loop

02-b. Loops Tradicionais (ou padrão/modelos)

! ! ! Interagindo sobre uma lista simples ! ! !

Se uma task precisa ser executada mais de uma vez em determinado host, recomenda-se usar como padrão o próprio loop, assim este agiria de acordo e sobre uma lista de strings, por exemplo. Em outras palavras, defina a lista diretamente, de uma vez só e já estando dentro da task em questão:

- name: Add users and give them root powers
  ansible.builtin.user:
    name: "{{ item }}"
    state: present
    group: "wheel"
  loop:
     - victor
     - viktor
     - vitor
     - vicrlda

O código acima ☝ seria equivalente ao de baixo 👇 (só que mais elegante! e com menos tec-tec-tec-tec 🔉💻💬)

- name: Add user vitor
  ansible.builtin.user:
    name: "vitor"
    state: present
    groups: "wheel"

- name: Add user vicrlda
  ansible.builtin.user:
    name: "vicrlda"
    state: present
    groups: "wheel"

.
.

.
.

! ! ! Interagindo sobre uma lista de hashes ! ! !

Caso tenha uma lista de hashes para trabalhar, utilize referências no formato de chave:subchave dentro do loop.

- name: Add multiple users
  ansible.builtin.user:
    name: "{{ item.name }}"
    state: present
    groups: "{{ item.groups }}"
  loop:
    - { name: 'victor', groups: 'wheel' }
    - { name: 'viktor', groups: 'root' }

! ! ! Interagindo sobre um dictionary ! ! !

Neste caso, simplesmente use o dict2items https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters.html#dict-filter :

- name: Using dict2items
  ansible.builtin.debug:
    msg: "{{ item.key }} - {{ item.value }}"
  loop: "{{ tag_data | dict2items }}"
  vars:
    tag_data:
      Environment: dev
      Application: payment

02-c. Registrando variáveis com um loop

Esse artifício é comumente usado na lógica da programação, em termos genéricos, e desde sempre, remontando ao seu início e concepção. Naturalmente, por tabela, também é observado nas linguagens. Em outras palavras, o que temos é, basicamente um evento partilhado ocorrendo tanto no macro quanto no micro ecossistema. Respeitando, é claro, as particularidades de cada um (limitações, capacidades e sintaxe).

E com os playbooks não poderia ser diferente. Somos capazes de armazenar a saída de um loop dentro de uma variável. Por exemplo,

- name: Register loop output as a variable
  ansible.builtin.shell: "echo {{ item }}"
  loop:
    - "apple"
    - "banana"
  register: echo

Loops que vem logo após a variável registrada, com o intuito de inspecionar eventuais resultados, talvez se assemelhem ao trecho a seguir:

- name: Fail if return code is not 0
  ansible.builtin.fail:
    msg: "The command ({{ item.cmd }}) did not have a 0 return code"
  when: item.rc != 0
  loop: "{{ echo.results }}"

Por padrão, o comportamento da variável durante a execução/interação do loop é sempre armazenar o valor do item atual, indiferente se são números, strings ou caracteres.

- name: Place the result of the current item in the variable
  ansible.builtin.shell: echo "{{ item }}"
  loop:
    - one
    - two
  register: echo
  changed_when: echo.stdout != "one"

02-d. Loops Complexos

! ! ! LISTAS ANINHADAS ! ! !

Aninhado(a), conceitualmente restrito ao universo da programação, implica dizer que um dado elemento está contido em outro elemento. Se preferir mais sinônimos, seria o mesmo que alojado, hospedado, instalado. Isso compreende desde funções, sub-rotinas, até vetores e matrizes. Exemplo: um vetor de tamanho três [0, 1, 2] cujas posições na memória são na verdade ponteiros para outros três vetores distintos. Talvez o mais importante aqui, e que vale destacar, é o tamanho da jurisprudência do primeiro ou o limite imposto ao segundo … ❓❓❓ Certo, certo, eu explico. Vamos imaginar que os sujeitos (elementos) em questão sejam rotinas e sub-rotinas. Então, partindo do pressuposto que apresentei, uma sub-rotina “filha” somente poderia ser chamada para rodar durante o programa única e exclusivamente por sua rotina “mãe”. Caso uma rotina “madrasta”, por exemplo, tentasse invocar essa mesma sub-rotina “filha”, não haveria êxito algum. Isso porque, de antemão, a primeira (madrasta) nunca iria enxergar a segunda (filha) pois ela apenas fica visível para a terceira (mãe). Isso é o que determinados autores chamam de “fazer sentido localmente”, e que é considerada uma forma de encapsulamento.

Ufa! 🥴 Agora sim, voltando ao contexto dos playbooks, e finalizando esse tópico antes de passar para o próximo (…)

Em situações de listas aninhadas recomenda-se o uso de expressões Jinja2 para melhor tratá-las. Como segue abaixo, um loop que combina várias listas:

- name: Give users access to multiple databases
  community.mysql.mysql_user:
    name: "{{ item[0] }}"
    priv: "{{ item[1] }}.*:ALL"
    append_privs: yes
    password: "foo"
  loop: "{{ ['alice', 'bob'] |product(['clientdb', 'employeedb', 'providerdb'])|list }}"

! ! ! INVENTÁRIOS ! ! !

Mais uma opção para uso dos loops no Ansible ocorre quando se trata de arquivos de inventário. Isso nos possibilita varrê-los ou construí-los sem sair do laço. E melhor, não é obrigatório usar todo o arquivo e sim apenas uma parte dele, caso prefira assim. Para tal, basta informar a palavra-chave loop com a variável ansible_play_batch ou a variável groups

- name: Show all the hosts in the inventory
  ansible.builtin.debug:
    msg: "{{ item }}"
  loop: "{{ groups['all'] }}"

- name: Show all the hosts in the current play
  ansible.builtin.debug:
    msg: "{{ item }}"
  loop: "{{ ansible_play_batch }}"

02-e. Adicionando controles aos loops

(A partir da versão 2.1+)

(Palavra-chave: loop_control)

! ! ! LIMITANDO A TELA/SAÍDA DO LOOP ! ! !

Para estruturas de dados muito complexas, executar um laço pode ser algo extenso, e consequentemente, a saída gerada (console) se torna igualmente enorme. Evite dores de cabeça e olhos cansados utilizando a diretriz label com loop_control :

- name: Create servers
  digital_ocean:
    name: "{{ item.name }}"
    state: present
  loop:
    - name: server1
      disks: 3gb
      ram: 15Gb
      network:
        nic01: 100Gb
        nic02: 10Gb
        ...
  loop_control:
    label: "{{ item.name }}"

! ! ! Pausa dentro de um loop ! ! !

Controle o tempo, aqui medido em segundos, entre a execução de cada item dentro de uma loop task (tarefa repetitiva). Use a diretriz pause com a palavra loop_control

# main.yml
- name: Create servers, pause 3s before creating next
  community.digitalocean.digital_ocean:
    name: "{{ item }}"
    state: present
  loop:
    - server1
    - server2
  loop_control:
    pause: 3

! ! ! Definindo nomes internos e externos ao loop com loop_var ! ! !

Você pode aninhar duas tarefas de loop usando include_tasks. No entanto, por padrão, Ansible define o item de variável de loop para cada loop. Isso significa que o loop interno aninhado sobrescreverá o valor do item do loop externo. Você pode especificar o nome da variável para cada loop usando loop_var com loop_control:

# main.yml
- include_tasks: inner.yml
  loop:
    - 1
     - 2
     - 3
  loop_control:
    loop_var: outer_item

# inner.yml
- name: Print outer and inner items
  ansible.builtin.debug:
    msg: "outer item={{ outer_item }} inner item={{ item }}"
  loop:
    - a
     - b
     - c

CONTINUA (…)

Próximo post >>> WHERE TASKS RUN?

REFERÊNCIAS:

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

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/playbooks_loops.html#playbooks-loops

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

ZABBIX Series: how to … adicionar um host linux ao monitoramento zabbix

Olá, aqui e de volta outra vez ( J. R. R. Tolkien feelings 😊 ) A série não pode parar e por isso, vamos nessa!!!!

Neste episódio veremos como adicionar um servidor linux ao nosso monitoramento. Ué Victor, e por acaso não já o fizemos no POST anterior? E a reposta é: não meus caros, ainda não. Ou melhor, eu diria quase. Não basta apenas instalar o agente zabbix e esperar que ele faça o restante do trabalho, não é bem assim. Mesmo apresentando o recurso de autodescoberta (que vale um artigo num futuro próximo), é bom, e por que não saudável também, aprender a configurar sozinho um host linux na interface web do zabbix.

ADD HOST

Uma vez logado na web console, vá para Configuration >> Hosts >> Create Host

** http://192.168.1.10/zabbix/

username: Admin

password: zabbix

Figura 01

Agora, informe os detalhes para os seguintes parâmetros:

Hostname: Nome do host remoto/cliente/alvo (nó)
Visible nameNome do host, algumas vezes chamado de nó
GroupSelecionar o(s) grupo(s) de hosts ao(s) qual(is) o nó pertence
Agent Interface: Digitar o endereço IP ou o nome DNS (IP recomendado)
Connect toEscolher entre IP / DNS (Forma de comunicação: IP recomendado)

Figura 02

NÃO clique em Add, por favor … O próximo passo são os templates, a setinha amarela (canto superior)

TEMPLATE

Um template é um conjunto de entidades que reduz seu esforço manual na configuração de gatilhos, itens, gráficos, aplicativos, etc. para cada host.

Templates podem ser aplicados a vários hosts ao mesmo tempo. E para diminuir ainda mais o trabalho, o próprio Zabbix já vem com alguns pré-definidos por padrão.

Vá para Templates >> Link new templates. Aqui é possível tanto digitar para pesquisar um modelo quanto clicar em Selecionar para escolher dentre uma lista (Marque o modelo que deseja vincular ao novo host)

Figura 03
Figura 04
Figura 05

Feito isso, redirecionado automaticamente (e de volta) para Configuration >> Hosts

Observe a mensagem (tarja verde) dizendo que o novo host que foi adicionado com sucesso:

Figura 06

MONITOR

Qualquer problema é sempre listado em Monitoring >> Dashboard Então, dirija-se até lá:

Figura 07

Para dados, valores, estatísticas e informações mais detalhadas acerca dos recursos coletados, vá para Monitoring >> Graphs

Escolha um host, procure pelo parâmetro do recurso desejado (CPU, RAM, HD, etc) e finalmente clique em GRAPH, sendo esta a última coluna no canto direito.

Figura 08

Aos mais atentos, percebam que a categoria Monitoring >> (lado esquerdo) possui muitas outras opções, como OVERVIEW, LATEST DATA, MAPS, DISCOVERY, SERVICES … Mas não se preocupem, pois todas elas serão cobertas e tratadas em artigos futuros da série

Bom galera, esse foi o conteúdo que quis trazer para vocês. Como disse no início, o BLOG não pode parar e tenho planejado algumas outras séries ainda este ano. Acredito que vão gostar bastante 😋 Mas primeiro, preciso concluir essas duas em aberto: o Zabbix e o Ansible. Então, já sabem: favorite no seu browser, seja um seguidor por e-mail ou redes sociais, e volte sempre pra checar se não saiu texto novo por aqui.

Grande abraço a todos! Um ótimo fim de semana

REFERÊNCIAS:

https://www.itzgeek.com/how-tos/linux/how-to-add-a-node-to-zabbix-server-for-monitoring.html

https://blog.zabbix.com/zabbix-agent-active-vs-passive/9207/

https://www.zabbix.com/auto_discovery

ZABBIX SERIES: how to … install zbx-agent on centos_7

Saudações 🖖 Agora que a páscoa ficou para trás, e esse é oficialmente o início do 2º ano do BLOG, nada melhor que começar com o pé direito e resgatar a série “pausada” do nosso querido Zabbix … Para tal vamos aprender hoje como instalar os agentes que monitoram toda a atividade no outro lado, nas pontas, ou melhor, nas máquinas alvo (nodes).

O mais legal é: trata-se de um tutorial bem curtinho e fácil de reproduzir. Quando piscarem os olhos verão que já terá acabado. Sendo assim, terminais abertos, usuários logados, e atenção aos comandos necessários. Vem comigo! 🚶‍♂️🚴‍♂

01. REPOSITORIO

Entre como root ou mude para o mesmo:

sudo su -

ou

su -

Devido ao pacote zabbix-agent não estar listado nos repositórios base do CentOS, adicione o endereço correspondente para configurá-lo em sistemas clientes (somente aqueles que deseja monitorar, é claro)

rpm -ivh https://repo.zabbix.com/zabbix/4.0/rhel/7/x86_64/zabbix-release-4.0-1.el7.noarch.rpm

02. PACOTE

Use o comando a seguir para instalar o agente propriamente dito:

yum install -y zabbix-agent

03. ARQUIVO

Modifique o arquivo do cliente para expressividades referentes ao servidor mãe/central:

vi /etc/zabbix/zabbix_agentd.conf

Atualize as seguintes informações no arquivo de configurações:

### Zabbix Server IP Address or Hostname ###

Server=192.168.1.10

### Client Hostname ###

Hostname=control-A

04. CONTROLE

Reinicie o agente zabbix:

systemctl restart zabbix-agent

Ative o zabbix-agent para um start automático no boot:

systemctl enable zabbix-agent

Fim

Eu avisei (…) O tempo passou e você nem viu 😄 hahaha

Vejo todos na próxima !!!

Tchau 👋

Referências:

https://www.itzgeek.com/how-tos/linux/ubuntu-how-tos/how-to-install-zabbix-agent-on-centos-7-ubuntu-16-04-debian-8.html

Vicrlda: 1 ano … 25 posts, 3.178 views, 803 visitas, 7 seguidores no WordPress.com :) ;)

Olá mais uma vez 🥳 Vigésima sexta e contando… 31 de março de 2021 marcará o primeiro ciclo de vida deste BLOG 🎉 Há cerca de um ano iniciava a minha empreitada de documentar o máximo de coisas possíveis relacionadas ao mundo da TI. Sejam ferramentas, tópicos ou áreas/nichos (“macros”) da computação a ideia é criar uma verdadeira biblioteca virtual de artigos sobre cada tema que gosto, estudo e abordo aqui com vocês. Estes que irão compor séries, séries que virarão categorias com a adição de notícias e extras sobre a ferramenta em questão (SERIES + NEWS + PLUS). Não podendo negligenciar as TAGS, é claro. Um pequeno sistema que vai listando posts correlatos toda vez que você clica em uma delas. Evidenciando e ilustrando com um exemplo simples: a TAG centos direciona para textos onde o CENTOS é primordial/obrigatório… Seja porque ele é a base da instalação ou porque os alvos (hosts remotos) são centos e precisam ser tratados de acordo… Pacotes .PRM, FirewallD, SELinux, interfaces enp0s3, comandos de rede ip addr ****, etc, etc, etc.

Pontuadas tais informações, vamos agora ao conteúdo de hoje e sua respectiva estrutura, sendo esta última dividida em três partes:

  • Nova categoria “Blog” (…) Qual o significado do POST anterior? (…) O que é BLOG Series???
  • Túnel do tempo
  • Dedicatória a uma pessoal muito especial

METABLOG? UMA SÉRIE EXCLUSIVA PARA TRATAR DO BLOG? OU RECURSIVIDADE (o blog evocando ele mesmo)?

Se permite algumas perguntas: (A) Por acaso ficou assustado com o título do artigo passado? (B) E o texto propriamente dito? Não entendeu também nada? Calma… Respira, inspira, respira, inspira… Medite um pouco… Esvazie sua mente. Pronto! 😁🤭

Continuando o raciocínio. Vamos começar explicando o mais fácil: o corpo, ou melhor, os três parágrafos do post. Deixando claro que não quero subestimar a capacidade de ninguém, pois sei que a grande maioria se trata de profissionais, muitas vezes com anos de experiência. MAS, TODAVIA, CONTUDO, PORÉM, posso estar dialogando com algum leitor considerado novato, iniciante nesse ramo. Ou quem sabe um técnico/analista/sysadmin especializado só na parte de infra, e que talvez não tenha tanto interesse no mundo DEV. Então, sendo assim aqui vai a resposta: Latim… Isso mesmo! Aquela língua morta dos tempos do Império Romano que se verbalizada/falada parece ora uma sequência de palavras no plural, devido ao S no fim, ora uma eterna vibração de cordas vocais graças aos M’s nas terminações 😆😆😆😆 (Linguistas de plantão, por favor não me matem! rsrs). E de onde veio esse negócio de latim Victor? Do Sublime Text é claro, e um plugin específico chamado EMMET. Para conhecer mais clique aqui (https://www.sublimetext.com/) e aqui (https://packagecontrol.io/packages/Emmet)

Agora a outra parte, não diria difícil e sim enigmática: o título do post. Quem já possui certa familiaridade com Linux e terminal ou até mesmo atua na área de redes (seja como engenheiro, administrador, suporte) provavelmente decifrou a mensagem até certo ponto pois conhece cada comando, o operador “;” (ponto-e-vírgula), e principalmente, a saída gerada na tela que é resultante dos mesmos, respectivamente. Falando em output (telas e saídas), segue o que é mostrado quando executado o título da página anterior no bash do Linux:

Figura 01. Saída na tela de comando

E então? Desvendaram? O que eu quis dizer? NÃO?! Pois muito bem, aí vai:

De acordo com as estatísticas observadas (fim da seção), percebo que já tenho uma plateia recorrente, digamos assim “fiel”… E estou feliz demais por isso! De verdade, é alegria que não cabe no peito 😍 O problema que enxergo é: existe visualizações mas não engajamento. Aos que eventualmente discordam de mim, só posso dizer não … Essas duas coisas não são iguais e portanto explico. Visualizações tem haver com o tráfego do portal/site/blog, ou seja, simplesmente acessos e views, ponto final. Em contraste, engajamento é a parcela desse público que interage periodicamente com o autor (eu) e entre si também (respondendo, comentando e ajudando uns aos outros). E é justamente isso que sinto falta aqui 😥 Ainda não temos esse nível de proximidade e por isso faço um pedido (…) Sempre que possível, caso ache interessante o que escrevi, e se por acaso o conteúdo te ajudou de alguma forma, seja no seu trabalho ou faculdade… Por favor, considere compartilhar com seus amigos, curtir e comentar nas postagens. Dessa forma você estará ajudando o BLOG a ter mais relevância em mecanismos de busca para que outras pessoas, como você e eu, encontrem material útil aos seus estudos, laboratórios e práticas.

Por fim, a nova e mais recente categoria BLOG, batizada por mim de BLOG Series. Tive esse lampejo, pequeno momento de iluminação, para uma iniciativa particular. Toda vez que eu quiser interagir com vocês com intuito de definir algo para o futuro, por exemplo, enquetes, consultas, questionários, colocarei no título BLOG Series, classificarei como Blog (rodapé do site), e marcarei com TAG ‘ blog ‘. Ok? 😉

Figura 02. Estatísticas #01 / Painel ADMIN WordPress
Figura 03. Estatísticas #02 / Painel ADMIN WordPress

UMA MÁQUINA CHAMADA O TEMPO

A seguir um compilado de fotos que retratam o início. Com o tema Maganize do WordPress Premium, matriz 5×2=10_textos/pagina, e visual padrão (branco/claro), assim era o BLOG precisamente. ( História + escolha + motivos + mudança ) registrados nesse POST 👇🏻👇🏻👇🏻👇🏻👇🏻

Vicrlda: I’m Alive! Voltei 🙂 Retorno, notas e avisos

Figura 04. Tema Magazine do Plano WordPress Premium
Figura 05. Exemplo de Página/POST
Figura 06. Página HOME / 31 de março de 2020 / 1º artigo publicado

ANTES DE VICTOR HAVIA MARIA ESTELA

Em memória de Maria Estela, minha avó materna. Falecida em 27 de março de 2011. Um câncer a levou, para outro plano, um lugar melhor. Se cheguei aonde estou, foi por causa dela. Devo o que sou, minhas conquistas e sonhos, o homem que me tornei, tudo graças à ela. Obrigado Vovó! TE AMO!!!

👩🏻‍🦳👵🏻🧓🏻

Estela… Do latim, e que significa “estrela”… Ponto luminoso no firmamento… Corpo celeste com intenso brilho e calor próprio… Astro que serve de guia e referência para todo aquele que busca orientar-se à noite… Estelas são estrelas cuja luz jamais morrerá, e sim, iluminarão o espaço infinito universo afora…

⭐🌟🌠☄

BLOG Series: C:\ >_ echo “Hello?” ; nmap -sP (network).(ip).(range).1-254 ; whoami ; printf “Leave a comment below… \n”

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed vitae odio ac risus iaculis tempor. Donec at magna orci. Pellentesque malesuada maximus fringilla. Donec at nunc at tortor dictum dapibus eu vulputate sapien. Cras faucibus quam enim, eu congue libero vulputate non. Cras a orci quis est dapibus eleifend eu ut quam. Curabitur posuere justo ex. Nulla a blandit lorem. Aenean vitae fringilla felis, et varius nunc. Nulla faucibus massa ac lacus ultrices, condimentum tincidunt ex accumsan. Fusce vulputate quam ipsum, non interdum ligula mattis sit amet.

In nec sem gravida, rhoncus sem et, vulputate libero. Integer nec elit ipsum. Fusce a suscipit velit. In in laoreet mauris, eget condimentum turpis. Mauris faucibus ligula ante, nec dignissim lorem fringilla in. Aenean vel lectus a sapien cursus iaculis. Proin ut lectus in enim ornare interdum nec commodo ex. In hac habitasse platea dictumst. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur id pharetra sem. Aliquam erat volutpat. Proin placerat lobortis ipsum, tincidunt tempus urna dictum a. In sollicitudin justo enim, sed dignissim nisi varius at. Nam tortor diam, interdum pretium semper id, posuere eleifend elit. In ut tortor in ipsum egestas porttitor. Morbi dictum orci eget ante porta bibendum.

Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia curae; Praesent interdum massa in congue blandit. Etiam non ultrices libero. Vestibulum ut posuere sem. Nullam sed nulla a lorem sagittis porta eu ut erat. Donec at malesuada urna. Nulla eu nulla nulla. Nulla tincidunt pulvinar ligula, ac suscipit orci condimentum non. Phasellus placerat nisi quis faucibus finibus. Donec dictum, diam quis volutpat iaculis, eros ante suscipit tellus, vitae eleifend orci mi in mi. Sed tempus, ex id elementum auctor, diam ante facilisis est, at maximus diam ante vitae tellus. Curabitur finibus odio quis libero lobortis interdum. Ut a commodo mauris, nec molestie lacus. Ut posuere, lorem ut elementum tempus, ipsum arcu egestas velit, id sagittis nisl dolor sed enim. Maecenas tempus, mauris sit amet lobortis tristique, justo turpis rutrum mauris, a consectetur ligula nisl non turpis. Maecenas hendrerit felis quam, a mattis mauris commodo placerat.

ANSIBLE Series: Web … Observando a execução de um JOB em tempo real

<head>
       Dedico esse post às mulheres 🌷 Especialmente para todas as  devs,
       sysadmins, engenheiras, pesquisadoras e cientistas 👩🏻‍🔬👩🏻‍💻👩🏻‍🏫👩🏻‍🎓 da computação
       ao redor do globo
</head>

E estamos aqui novamente, de volta ao Ansible. Mais precisamente continuando a parte gráfica, batizada de AWX/Tower. Preciso que resgatem na memória o que vimos no post ANSIBLE Series: Lab … Modo GUI = Web Console

Um resumo rápido e para ajudá-los…

1ª parte – Teoria: o que é AWX, por que foi criado, funções principais, e explicação sobre cada componente integrante da arquitetura.

2ª parte – HOW TO: como instalá-lo usando o método docker-compose.

3ª parte – Mão na massa: adicionar usuários, inventários, hosts, criar projetos e templates na interface web.

Portanto, sendo assim, não pretendo repetir ou me alongar demais nas explicações de cada coisa, seja item ou subitem, seja menu ou submenu, seja aba ou opção. Para que isso ocorra e todos compreendam recomendo a leitura do já citado ANSIBLE Series: Lab … Modo GUI = Web Console … Basta pesquisar no blog ou retroceder alguns artigos, ok? 😏

O que verão a seguir serão apenas telas já com os campos preenchidos por mim, de acordo com as minhas definições e configurações, ou seja, hosts, iventário, chave SSH, repositório GIT, etc. Se por acaso os nomes que você utilizou no laboratório diferem dos meus (o que é bem provável e possível), preste atenção e preencha os campos de acordo com eles.

Ultima chamada e reforço antes da prática de hoje: Caso queira saber/localizar aonde deve clicar selecionar ou digitar em cada passo/etapa no AWX, pare agora, leia e só retorne após o ANSIBLE Series: Lab … Modo GUI… Aaaaahhhhh, vocês já sabem muito bem o quê 😂😂😂😂 Chega de enrolar!!! rsrs

IF (TIMEOUT=TRUE) OR (ERROR=TRUE) THEN:

Control-A

# firewall-cmd --zone=public --add-masquerade --permanent
# firewall-cmd --permanent --add-service=http
# firewall-cmd --permanent --add-service=https
# firewall-cmd --reload

Node-01, Node-02

# systemctl status firewalld
# systemctl stop firewalld
# iptables -L

CRIANDO UMA ORGANIZAÇÃO (…)

Figura 01

ADICIONANDO UM USUÁRIO (…)

Figura 02

DEFININDO INVETÁRIO (…)

Figura 03

ACRESCENTANDO HOSTS (…)

Figura 04

ESTABELENCENDO CREDENCIAL (…)

Figura 05

INICIANDO UM PROJETO (…)

Figura 06

CRIANDO TEMPLATE (…)

Figura 07

RUNNING A JOB (!!!)

Figura 08

(**) Legendas:

Verde -> Sucesso -> OK!
Laranja -> Modificações/Alterações!
Vermelho -> Avisos/Falhas -> ERROR!

https://www.linuxtechi.com/install-ansible-awx-docker-compose-centos-8/

https://en.wikipedia.org/wiki/Margaret_Hamilton_(software_engineer)

https://pt.wikipedia.org/wiki/Margaret_Hamilton_(cientista_da_computa%C3%A7%C3%A3o)

Margareth Hamilton & Apollo 11

Happy women’s day 🙂

OTRS News: Morre a Community Edition :'( Nascem os forks :)

Uma notícia nada alegre 😥 Quase um LUTO, na verdade, para todos os administradores que usufruíam desta ferramenta… Tomei ciência da mesma hoje pela manhã, fazendo minha “tradicional” leitura diária de e-mails, pessoal e corporativo. Ambos tinham uma mensagem cada acerca do assunto. O primeiro veio de um instrutor da Udemy que ministrava um curso sobre OTRS na plataforma. Já o segundo remetente foi uma empresa brasileira que fornece mentoria, suporte, plugins e extras para uma versão gratuita própria, desenvolvida pelo time da casa (um fork do OTRS CE original).

O resumo da ópera é o que segue:

A versão comunitária do OTRS foi “desligada”. Seu ciclo de vida será (alias já está) encerrado/descontinuado. Sem futuros updates ou patches de correção, ele acaba se tornando um sistema inseguro e vulnerável. A continuidade do uso em ambientes de produção não é mais aconselhável, sendo um risco para a rede e possível brecha/alvo de hackers. Portanto, a solução seria migrar para: (a) versão paga, (b) um fork específico, (c) outro sistema equivalente no mercado. Tamanha é essa decisão que o planejamento e execução precisam ser tomados a curto-médio prazo.

Dado o panorama geral, vamos por partes… Aos detalhes e pormenores 😦

DESLIGADA? COMO ASSIM?

Eu disse “desligada” há pouco pois a partir de agora está impossibilitado fazer o download dos pacotes da Community Edition. Isso porque todos os repositórios foram privados ou retirados do ar. Então, a menos que você já tenha feito a instalação e deixado o sistema pronto/rodando, ou salvo localmente os arquivos das versões anteriores (3, 4, 5, 6), ou em último caso, possua um colega que ceda e envie os dele… Não conseguirá instalar nem o OTRS (free) nem qualquer plugin.

MAS POR QUE? E O DELAY DE DOIS ANOS PARA NOVOS RECURSOS NA COMMUNITY ANTERIOR?

É, parece que a promessa foi quebrada não é mesmo? Caso esteja confuso, desorientado e sem contexto nenhum, por favor, PARE, LEIA e RETORNE após a publicação abaixo:

OTRS Plus+: OTRS 8 Trial

https://machinesbecomeservices.com/2021/01/08/otrs-plus-otrs-8-trial/

Recordando bem, nela vimos a notícia de uma revista alemã aonde o CEO da OTRS AG afirma categoricamente…

O QUE A COMUNIDADE ESTÁ FALANDO?

Não há nada melhor do que um fórum para saber o que os usuários pensam ou dizem…

https://forums.otterhub.org/viewtopic.php?f=53&t=41628

Topic/Thread 41628

UM POUCO DE HUMOR E ‘STAR WARS’ PARA ENTENDER MELHOR … haha

https://radiantsystem.com/community/

((OTRS)) Community Edition – what next?​

Episode 1 — The Phantom Menace

A long-long time ago, in a galaxy far, far away … … the first sub CreateTicketDB was written.
From an e-mail handler OTRS has evolved into a powerful ITSM solution. For a long time, the system used to be the only free open source solution certified by ITIL.

Due to its features and zero license cost the system won well-deserved popularity all over the world. In 2015, OTRS AG announced the OTRS Business Solution. In fact, it was the same OTRS with a set of commercial add-ons developed by OTRS AG previously. New versions of free OTRS and OTRS Business Solution were released simultaneously.

When OTRS AG renamed OTRS to ((OTRS)) Community Edition in 2018 and OTRS Business Solution became just OTRS, questions and bad sort of feeling had appeared among many people. However, the official statement clearly said — we will transfer all new features to the Community version in a few years. There was even a more certain promise from the CEO of the company Andre Mindermann — in 2 years.

We accepted that with understanding and respect. It was even better for us — our free and commercial Community Edition add-ons would get a longer lifecycle. And we continued our work — we launched a marketplace, developed the world’s only native agent mobile application for ((OTRS)) 6 Community Edition.

Episode 2 — The Empire Strikes Back

In March 2020, OTRS AG announced the release of OTRS 8. That meant that the release of OTRS 7 was ending its cycle. And everyone thought that a public version of the 7 would soon appear. Everything looked logical – the version 7 was already 2 years old, and a new version 8 was released.

However, there was no news about the new Community Edition. But at the end of the “wonderful” 2020, in which it was not easy for everyone, on December 23, OTRS AG publishes a security release — OTRS 6 and ((OTRS)) 6 Community Edition are insecure. And from January 1, 2021 there will not be any security updates anymore, despite promises in official releases and forum posts.

Tam-tam-tam … Tam-tadam … Tam-dadam …

Episode 3 — A New Hope

The time for such a release was the most inappropriate. Most of Europe and the United States went on Christmas break. Many, I’m sure, even missed this message in the mailing lists.

But already in early January 2021, many independent developers reacted to this situation. The reaction was predictable — everyone was outraged. Community Edition users also did not stand aside — people asked questions «what’s next?»

The hope that the free and open version has a future was given by several companies at once. They said they would fix bugs and make security releases, and announced a migration to version 7 Community, if released.

Episode 4 — The Force Awakens

Radiant System has been on the OTRS market for over 10 years. We were one of the first to join the OTRS partner program in 2010, and have been partners for 5 years. Despite all our efforts, we could not agree on mutually beneficial cooperation and decided to go our own way. Within these years we have strictly followed the strategy of our favorite product — OTRS, not in its current commercial sense, but in its original spirit. We have helped a large number of our customers save time and money and improve their business efficiency.

Due to the latest news from OTRS AG regarding the ((OTRS)) Community Edition we would like to declare support for the ((OTRS)) Community Edition. How we see it:

• creation of an open fork ((OTRS)) 6 Community Edition — Radiant. Repository — https://github.com/RadiantSystem/radiant
• compatibility support for Radiant c ((OTRS)) Community Edition versions 6 and 7, if released.
• support for the Radiant fork for at least 2 years — bug fixes and security update
• we plan to release of an open version of Radiant 7 in 2021 is in our plan
• we plan to release of a commercial version of Radiant 7 Service Desk in 2021
• initiation to create an alliance of developers ((OTRS)) Community Edition for the sustainable development of the product
• development of the marketplace https://rs4otrs.com
• release of new free and commercial add-ons for ((OTRS)) 6 Community Edition

Episode 5 — The Last Jedi

We believe the spirit and principles of open source software cannot be a subject of demagogic manipulations. Keeping our promises is the foundation of ethical business.

We share the initiative of all independent developers to support Community Edition and are ready to take an active part in the development and support of our favorite product.

We also offer, as written above, to bring together all developers and create a common strategy for collaboration and support. We understand that for the majority this is business, not charity. But we are sure that the developing community is the key to our success.

May the Force be with us!

😆😆😆😆😆😆😆😆

MEU FAVORITO E CANDIDATO SUBSTITUTO

>> OTOBO HELPDESK <<

https://otobo.de/en/

COM A PALAVRA … STEFAN ROTHER, Founder of Rother OSS GmbH

https://otobo.de/en/rother-oss/

FIM DA ‘OTRS SERIES’, MINHAS CONSIDERAÇÕES SOBRE, EVENTUAL ‘OTOBO SERIES’

https://doc.otobo.org/manual/installation/stable/pt_BR/content/index.html

https://otobo.de/en/community/

referências:

1. https://portal.otrs.com/external/c/otrs-6-end-of-life

2. https://community.otrs.com/?utm_campaign=migrar-otrs-para-ligerosmartv1&utm_medium=email&utm_source=RD+Station

3. https://otrs.com/product-and-service-life-cycle/

4. https://otrsbrasil.com/

5. https://radiantsystem.com/community/

%d blogueiros gostam disto: