UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

CENTRO DE TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA DE COMUNICAÇÃO
CURSO DE ENGENHARIA DE TELECOMUNICAÇÕES

GESTÃO DE CONTROLE DE MUDANÇAS EM TI: AUTOMATIZAÇÃO DE

CONFIGURAÇÕES

TALLES TAYSON SALDANHA DE FARIAS

NATAL-RN
2019
 TALLES TAYSON SALDANHA DE FARIAS

GESTÃO DE CONTROLE DE MUDANÇAS EM TI: AUTOMATIZAÇÃO DE

CONFIGURAÇÕES

Trabalho de Conclusão de Curso

submetido à Coordenação do Curso de
Engenharia de Telecomunicações, do
Centro de Tecnologia da Universidade
Federal do Rio Grande do Norte, em
cumprimento as exigências necessárias à
obtenção do grau de Bacharel em
Engenharia de Telecomunicações.
Orientador: Prof. Dr. Gutembergue Soares
da Silva.

NATAL-RN
2019
 TALLES TAYSON SALDANHA DE FARIAS

GESTÃO DE CONTROLE DE MUDANÇAS EM TI: AUTOMATIZAÇÃO DE

CONFIGURAÇÕES

Trabalho de Conclusão de Curso de Engenharia de Telecomunicações da

Universidade Federal do Rio Grande do Norte, apresentando como um dos requisitos
para à obtenção do grau de bacharel em Engenharia de Telecomunicações pela
Universidade Federal do Rio Grande do Norte.

Data de Aprovação: _____/_____/_____

BANCA EXAMINADORA

___________________________________________________
Profº Dr. Gutembergue Soares Da Silva
(Orientador)

____________________________________________________
Profº. Dr. Fred Sizenando Rossiter Pinheiro
(Membro da Banca)

____________________________________________________
Profº. Dr. Antonio Salvio de Abreu
(Membro da Banca)
AGRADECIMENTOS

À minha Família por toda a estrutura necessária para chegar até esse momento, em
especial a minha mãe Maria Apresentação Saldanha, que sempre me incentivou
mesmo diante das dificuldades.

À minha noiva e futura esposa Thalita Freires pela sempre disponibilidade em ajudar
e incentivar nos inúmeros e intermináveis projetos da minha vida.

Aos Amigos do grupo de Telecom por sempre incentivarem de forma não

convencional a conclusão deste curso.

Agradeço aos colegas da USUT CAERN pela apoio, conhecimento e disponibilidade

em fornecer a infraestrutura para realização deste e outros projetos.

A todos os amigos conquistados ao longo da vida desde a 1.04 CEFET, passando

pelo IFZN, UFRN, Facex, Morgados, CAERN, em especial aos que estão sempre
presentes e aqueles que não estão mais presentes mas que tem sua igual contribuição
em minha vida.

Ao departamento e todos os docentes do curso de Engenharia de Telecomunicação

que fizeram parte da minha formação, em especial ao meu orientador Profº Dr.
Gutembergue Soares, pela confiança e por acreditar no projeto proposto.
RESUMO

Analisando o panorama atual das empresas, é notório a necessidade de manutenção

de um ambiente informatizado levando os administradores a buscarem estratégias de
implementação para o gerenciamento da infraestrutura de TI. Visando atender essa
crescente demanda foram desenvolvidas ferramentas que buscam facilitar o controle
da infraestrutura, com isso o gerenciamento de configurações vem para trazer aos
administrados controle sobre seu parque físico ou virtual. Desta forma este trabalho
engloba o estudo, analise e validação, comparando as principais ferramentas
opensource de gerenciamento de infraestrutura, abordando o uso em um ambiente
misto de desktops como temáticas alvos o controle do parque de máquinas, temática
essa que é pouco utilizada quando o tema é abordado. Utiliza-se como metodologia
de caráter descritivo e exploratório, com o objetivo de entender temas como gerência
de configuração de software, Puppet, Ansible, chef, infraestrutura como código (IaC).
O principal fator motivacional para a realização é a formação do embasamento teórico
conceitual em se tradando da demanda como abordada nesse trabalho, tendo em
vista que o assunto é pouco utilizado na temática de controle de parque desktop. Foi
possível concluir com isso que a ferramenta Puppet pode ser utilizada com êxito em
ambientes misto para controle de desktop Windows.

Palavra-Chave: Puppet, Gerenciamento de configurações, Iac, Windows

ABSTRACT

Analyzing the current business outlook, it is necessary to notify the need of

maintenance of a computerized environment, leading consumers to pursue
implementation strategies for managing their IT infrastructure. Aiming this growing
demand, bus tools have been developed to facilitate infrastructure control, with
configuration management that comes to give administrators control of their physical
or virtual park. Thus, this work includes the study, analysis and validation, comparing
as main open source infrastructure management tools, discussing the use in a mixed
environment of desktops as theme or machine park control, theme that is seldom used
when the topic is addressed. Used as a descriptive and exploratory method, with the
objective of understanding topics such as software configuration management,
Puppet, Ansible, chef, infrastructure as code (IaC). The main motivational factor for the
realization is the formation of the conceptual theoretical basis, which require demand
as approached in this work, considering that the subject is little used in the theme of
work park control. It can be concluded from this that the Puppet tool can be used
successfully in mixed environments for Windows desktop control.

Keywords: Puppet, Configuration Management, Iac, Windows.

LISTA DE FIGURAS

FIGURA 1-CAMS DEVOPS ........................................................................................... 16

FIGURA 2-LOGO PUPPET .............................................................................................. 20
FIGURA 3- FLUXOGRAMA DE FUNCIONAMENTO DO PUPPET .............................................. 21
FIGURA 4-LOGO ANSIBLE ............................................................................................. 22
FIGURA 5-FLUXOGRAMA DE FUNCIONAMENTO DO ANSIBLE .............................................. 23
FIGURA 6-LOGO CHEF ................................................................................................. 24
FIGURA 7-FLUXOGRAMA DE FUNCIONAMENTO DO CHEF .................................................. 25
FIGURA 8 - FLUXOGRAMA DE FUNCIONAMENTO DO CHEF ................................................. 26
FIGURA 9 - ORGANOGRAMA CAERN ............................................................................. 28
FIGURA 10 - REGIONAIS CAERN .................................................................................. 29
FIGURA 11 - SIGLAS REGIONAIS .................................................................................... 31
FIGURA 12 -TELA DO VIRTUAL BOX ............................................................................... 34
FIGURA 13 - TELA DE INSTALAÇÃO PUPPET AGENT ......................................................... 37
FIGURA 14 - CATEGORIA DE MÓDULOS .......................................................................... 41
FIGURA 15 - TELA PUPPET BOARD ................................................................................ 46
FIGURA 16- DASHBOARD PUPPETBOAD ......................................................................... 47
FIGURA 18- TELA DE ERRO PUPPETBOARD ................................................................... 49
FIGURA 17 - ERRO NA EXECUÇÃO DO MANIFESTO .......................................................... 49
LISTA DE TABELAS

TABELA 1 - COMPARATIVO DE FERRAMENTAS ................................................................. 27

TABELA 2 - PADRÃO DE NOMENCLATURA DE HOST ......................................................... 39
TABELA 3 - TABELA DE MÓDULOS .................................................................................. 42
LISTA DE SIGLAS E ABREVIATURAS

IAC - Infraestrutura como código

TI – Tecnologia da Informação

DESKTOPS - micro computadores de mesa

DEVOPS - Desenvolvimento" (development) e "operações" (operations)

CAMS - Cultura, Automação, Avaliação e compartilhamento

C++ - Linguagem de programação compilada multi-paradigma

BIT - Binary Digit

PUPPETDB – Banco de dados do puppet

STRING – Cadeia de caracteres

AJU – Acessória jurídica

PUPPUTEBOARD – Painel de visualização Puppet

DASHBOARD – Ferramenta para exibição de indicadores

UNCHANGED – Status de não alteração

PUPPET DEVELOPMENT KIT – Conjunto de ferramentas para desenvolvimento em

Puppet
 SUMÁRIO

AGRADECIMENTOS................................................................................................................................... 4
RESUMO ................................................................................................................................................... 5
ABSTRACT ................................................................................................................................................. 6
LISTA DE FIGURAS..................................................................................................................................... 7
LISTA DE TABELAS..................................................................................................................................... 8
LISTA DE SIGLAS E ABREVIATURAS ........................................................................................................... 9
SUMÁRIO ................................................................................................................................................ 10
1. INTRODUÇÃO ..................................................................................................................................... 11
2. OBJETIVOS GERAL............................................................................................................................... 12
2.1 OBJETIVOS ESPECÍFICOS ................................................................................................................... 12
3. JUSTIFICATIVA .................................................................................................................................... 13
4. FUNDAMENTAÇÃO TEÓRICA .............................................................................................................. 14
4.1 Governança de TI ......................................................................................................................... 14
4.2 Equipes de infraestrutura/servidores .......................................................................................... 14
4.3 Equipes de Sistemas ..................................................................................................................... 15
4.4 DevOps ......................................................................................................................................... 15
4.4.1 Cultura ................................................................................................................................... 16
4.4.2 Automação ............................................................................................................................ 17
4.4.3 Avaliação ............................................................................................................................... 17
4.4.4 Compartilhamento ................................................................................................................ 17
4.5 Gerência de configuração ............................................................................................................ 17
4.6 IaC (Infraestrutura como código) ................................................................................................. 18
4.7 Extração de configurações ........................................................................................................... 19
4.8 Análise de ferramentas SCM ........................................................................................................ 20
4.8.1 Puppet ................................................................................................................................... 20
4.8.2 Ansible ................................................................................................................................... 22
4.8.3 Chef ....................................................................................................................................... 23
4.8.4 SaltStack ................................................................................................................................ 25
4.9 Comparação das Ferramentas ..................................................................................................... 26
5. METODOLOGIA................................................................................................................................... 28
Descrição da Empresa ........................................................................................................................ 28
5.1 Estrutura Atual ............................................................................................................................. 29
5.2 Problema Conceitual .................................................................................................................... 30
 5.3 Projeto .......................................................................................................................................... 31
5.3.1 Escolha do Puppet ................................................................................................................. 31
5.3.2 Análise de Requisitos ............................................................................................................ 32
5.4 Ambiente de teste ........................................................................................................................ 33
5.4.1 Testes Iniciais......................................................................................................................... 33
5.4.2 Servidor Puppet ..................................................................................................................... 34
5.4.3 Instalação do Puppet Master ................................................................................................ 35
5.4.5 PuppetDb............................................................................................................................... 36
5.4.6 Instalação do Puppet Agent .................................................................................................. 37
5.5 Manifestos.................................................................................................................................... 38
5.5.1 Nome do Host ....................................................................................................................... 39
5.5.2 Expressão regular .................................................................................................................. 40
5.5.3 Módulos base ........................................................................................................................ 41
5.5.4 Fatos sobre o sistema............................................................................................................ 42
5.5.4 Código do manifesto ............................................................................................................. 44
5.6 Puppet board................................................................................................................................ 46
6 RESULTADOS ....................................................................................................................................... 48
7 CONCLUSÃO ........................................................................................................................................ 51
REFERÊNCIAS BIBLIOGRÁFICAS .............................................................................................................. 52
ANEXO .................................................................................................................................................... 54
 11

1. INTRODUÇÃO

Na atualidade, os sistemas informáticos estão presentes na maioria das

empresas afim de otimizar e padronizar as atividades e informações inerentes a
empresa. Atualizações de sistemas são comuns sempre que uma nova versão de um
sistema é lançada, além das demandas dos setores.

Essa constante mudança torna essas alterações de difícil execução de forma

ágil e quando falamos de dezenas ou centenas de máquinas torna- se inviável realizar
as alterações localmente pois para atualizar os sistemas dos desktops exige-se uma
intervenção do setor de suporte técnico com interação individual para realizar essas
mudanças maquina por máquina, sendo assim busca-se cada vez mais otimizar este
serviço, afim de implementar mudanças de forma mais rápida, evitando assim o gasto
desnecessário de horas e extinguindo a necessidade de atualizar as máquinas
individualmente mesmo que por acesso remoto.

Gerenciar, hoje, é a palavra chave para o funcionamento rápido de qualquer

sistema. Para sistemas de servidores é utilizado a gestão de configuração de software
que corresponde a um conjunto de atividades que visam administrar as alterações no
software, reduzindo o tempo e trabalho para, em meio a modificações, retornar o
sistemas em produção novamente.

Em busca desta redução de tempo e demanda, este estudo propõe-se a utilizar

a gestão de gerenciamento de mudanças através da ferramenta Puppet para melhorar
a automatização de configurações da companhia de águas e esgotos do Rio Grande
do Norte (CAERN).
 12

2. OBJETIVOS GERAL

Gerenciamento do parque de desktops para controlar e garantir o padrão de

conformidade dos softwares-base (utilitários), configurações, usuários, grupos,
segurança, acesso remoto e softwares internos, para um parque misto de desktops,
em uma empresa de economia mista.

2.1 OBJETIVOS ESPECÍFICOS

 Identificar requisitos a serem implementados de acordo com o perfil da

empresa;
 Identificar os problemas da ferramenta de gerenciamento em ambiente de
cliente Windows;
 Avaliar desempenho da ferramenta Puppet no gerenciamento de desktops;
 Verificar se há melhora no tempo de atualizações com a ferramenta de
gerenciamento de configurações.
 13

3. JUSTIFICATIVA

A informatização dos sistemas nas empresas gera cada vez mais necessidade
por serviços, essa crescente demanda culmina no crescimento de infraestrutura,
porem nos nossos tempos atuais um desenvolvimento de infraestrutura significa um
crescimento virtuais (Virtualização, clouds, containers, servers). Esse avanço deu
início ao desenvolvimento de tecnologias com objetivos de gerenciar infraestrutura.

Detecção e solução rápida de problemas, menos tempo e esforço na correção

é o que nos traz o gerenciamento de infraestrutura, segundo Morris (2016), esse é o
principal pilar que nos leva a experimentar essa cultura, que apesar de parecer uma
ótima alternativa, quando não aplicada de forma limpa e documenta, pode se tornar
um futuro problema para a empresa.

Gerenciar processos e manter um parque atualizado é um grande desafio para

os administradores de rede e equipes de TI, tendo em vista os diferentes sistemas
operacionais, ao passar de uma visão macro para uma visão micro, temos diferentes
padrões para diferentes setores, o que torna a função dos administradores ainda mais
complexas. Para sanar esse problema, surgiram as ferramentas de gerência de
configuração, permitindo administrar uma infraestrutura de servidores em larga
escala, de forma eficiente e segura, garantindo confiabilidade e minimizando a
complexidade.

Dessa forma, observa-se a importância social e científica de se investigar a

utilização da ferramentas de gerenciamento de software voltada para o organização
da infraestrutura de um parque de desktop e contribuir também para a melhoria do
serviço público, pois segundo Alves (2016) a boa qualidade dos serviços públicos é
um anseio da sociedade e foco de propostas de diversos estudos para sua melhoria,
sendo assim se a Tecnologia da Informação (TI) assumir um papel estratégico dentro
das organizações pode-se obter a melhoria da infraestrutura tornando o serviço mais
ágil e eficaz para a população.
 14

4. FUNDAMENTAÇÃO TEÓRICA

Este capítulo tem por finalidade apresentar os conceitos principais acerca do

que será abordado na solução, tais temos são essenciais para o entendimento futuro.

4.1 Governança de TI

Weill e Ross (2006:8) definem governança de TI como “a especificação dos

direitos decisórios e do framework de responsabilidades para estimular
comportamentos desejáveis na utilização da TI”, ou seja definir os responsáveis pela
tomada de decisão, compartilhando as decisões entre gestores estabelecendo assim
regras para a organização e processos.

Essencialmente, a Governança de TI é um desdobramento da

Governança Corporativa (agrupamentos de procedimentos, políticas, normas e
processos que regem uma determinada organização) objetivando a gestão das
ferramentas, recursos e soluções em TI. No momento da execução, ela deve ser
praticada por todos os usuários de softwares e sistemas, incluindo gerentes e
gestores, auditores e diretores.

Dentro desse agrupamento de procedimentos descritas no conjunto da

Governança de TI, estão hábitos que garantem a segurança da informação nos
processos executados dentro de uma empresa, disponibilidade e total funcionamento
das tecnologias da informação e durabilidade de todo o sistema implantado nestas
corporações.

Segundo DE MENDONÇA (2013), a tecnologia da informação pode contribuir

bastante para o desenvolvimento de instituição e a governança vem sendo
crescentemente utilizando tanto nas organizações públicas quanto privadas para
melhor geri-las internamente.

4.2 Equipes de infraestrutura/servidores

O termo infraestrutura sempre foi utilizado para descrever grandes estruturas,

canais e estradas para transporte, com o tempo e a tecnologia ele passou a fazer
parte do nosso cotidiano transformando esse termo em infraestrutura de TI. Hoje o
termo é fundamental para descrever tudo que se relaciona com o gerenciamento de
 15

dados e informação, desde estrutura física de cabos, instalações de salas, servidores

até os softwares, que tem como objetivo auxiliar no gerenciamento de uma empresa.
Segundo Mendonça (2013), os serviços de TI quando centralizados de forma
organizada são responsáveis por definir a base da estrutura de TI da
organização/instituição.

O ciclo de vida de um serviço de TI, segundo Magalhães (2007), são os

componentes da infraestrutura responsáveis por suportar as operações de serviços
de TI, são eles: requerimentos, políticas, estratégia, planos, validação,
implementação, operação e obsolescência. As esquipes de infraestrutura são
responsáveis pelo mantenimento de toda a estrutura física e/ou virtual, nos casos de
servidores em nuvem, tudo que é necessário para que a estrutura se mantenha em
funcionamento para o usuário final desde a estação de trabalho até a aplicação é feita
por essas equipes.

4.3 Equipes de Sistemas

O Desenvolvimento, manutenção e atualizações dos sistemas internos do

negócio são mantidos e executados pela equipe de sistemas, essa equipe também é
encarregada da criação de novas funcionalidades de acordo com as necessidades da
empresa, remetidas posteriormente em novas atualização.

4.4 DevOps

O termo DevOps surgiu na Bélgica em 2009 no evento DevOpsDays, com o

objetivo de discutir problemas culturais nas áreas de TI. De acordo com Hüttermann
(2012), para o termo DevOps não existe um significado único que o define, porém,
quando tomado a perspectiva do desenvolvedor o termo se torna uma mistura de
recursos avançadas, práticas e abordagens inovadores para desafios comuns de
entrega de serviço e softwares.

Como o próprio nome já diz DevOps é uma mistura de desenvolvimento

(Programadores, testadores e engenheiros de software), responsáveis pela criação
de funcionalidades, estudo de caso, teste e a operação (administradores de rede e
 16

banco de dados, suporte técnico) responsáveis pela inclusão do software em

produção com o provimento de infraestrutura necessária para o seu funcionamento.

A comunidade passou a crescer principalmente nas startups que já usam

modelos de agilidade nos processos. Com o crescimento da ideia Willis (2010), criou
o acrônimo que passou a ser conhecido como os pilares do DevOps, o CAMS, que
posteriormente passou a ser utilizado pela comunidade DevOps, são eles: Cultura,
Avaliação, Automação e Compartilhamento.

Figura 1-CAMS DevOps

Fonte: https://instruct.com.br/entenda-cultura-devops/

4.4.1 Cultura

O modelo DevOps tem como um de seus pilares o estímulo a cultura

colaborativa, motivando a integração departamental e de processos, já na TI
tradicional esse sistema é independente tendo individualmente cada um o seu papel.

O estímulo a nova cultura une setores para projetar, realizar e executar em

conjunto afim da agilizar a entrega, reduzindo a probabilidade de erros durante o
processo de criação e execução.
 17

4.4.2 Automação

A Automação também tem seu papel fundamental na cultura DevOps, sendo

aplicadas principalmente em áreas relacionadas a processos manuais e repetitivos.
Um exemplo da automação nessa cultura é monitorar log por ferramentas opensource
com objetivos de encontrar com mais agilidades erros no sistema após o lançamento
de versões.

Toda a gama de ferramentas que podem ser utilizadas para melhoria em

processos tornando-os mais rápidos são bem-vindos. A gestão de configurações
também entra no processo de automação sendo detalhada mais adiante.

4.4.3 Avaliação

O processo de medição deve ser realizado com o intuito de observar todos os

fatores de integração citados acima, que vai desde gerar uma métrica de resultados,
monitoramento até a performance para serem implementadas para visualização do
resultado final em busca de melhorias durante o processo, com esses resultados e
avaliações em mãos o gestor tem maior assertiva na tomada de decisões.

4.4.4 Compartilhamento

Um outro importante pilar quanto a cultura DevOps é o compartilhamento de

informações, facilitada devido a já adotada integração entre setores. Programadores
e operadores passam a assumir não somente suas principais funções, mas agora
acompanham todos os passos, tornando o processo mais transparente para a
organização.

4.5 Gerência de configuração

A mudança em um ambiente de gerência é inevitável, principalmente no

desenvolvimento de software, novas funcionalidades, legislações, alterações
conforme a necessidade de usuários e empresas acontece o tempo todo, para lidar
com essas constantes mudanças surgiu a gerência de configuração de software
(GCS). O gerenciamento de configurações é uma das etapas da gerência de projeto,
 18

que inclui atividades de gerência de processos, gestão de qualidade, gerencia de

risco, e também é conhecido como gerencia de configuração e mudança.

A gerência de configuração está intimamente ligada a gestão de software,

tendo como função fornecer um mecanismo de controle gradual do avanço do
desenvolvimento de um sistema de software, afirma Saleem (2019). O assunto gestão
de configurações é constantemente discutido quando se fala em desenvolvimento,
porém não é apenas durante o desenvolvimento que ela deve ser lembrado, da
mesma forma que o desenvolvimento de s SLS (SaLt State Files) software se utiliza
dessa ferramenta ela também pode ser amplamente utilizada na administração de
configurações de sistemas.

4.6 IaC (Infraestrutura como código)

A IaC, como o próprio nome diz, transforma as operações de infraestruturas

em sequencias de códigos, com o intuito de garantir a disponibilidade. Segundo
Rahman (2019), o IaC é o gerenciamento de forma automática de itens de rede,
configuração do sistema e infraestrutura através de código.

Atualmente grandes empresas como Netflix, Ambit Energy, e Wikimedia

Commons utilizam infraestrutura como código para construir implementações
automatizadas no seu processo de desenvolvimento, Rahman (2019), a utilização de
script aumentou a frequência de implementação na organização da TI moderna.

A definição do termo “infraestrutura como código” não é bem definida, Morris

(2016) afirma que não existe um autor claro para esse termo, ele complementa que a
abordagem das práticas de transformar infraestrutura em código, que surgiu
juntamente com a comunidade DevOps, inspirou a criação de ferramentas que
auxiliassem nesse pratica de IaC, ou seja, primeiro surgiu o conceito para depois o
surgimento de ferramentas que auxiliassem nessa execução.

Já Brikman (2017), também segue o mesmo conceito ao definir como a escrita

e execução de código para definir implementar ou atualizar uma infraestrutura, ele
também considera recursos com a criação de maquinas virtuais, criação ou edição de
banco de dados, gerenciamento de configurações do sistema, gerenciamento de
memória e núcleos de CPU como recursos intrínsecos da IaC.
 19

As principais ferramentas disponíveis para IaC prometem uma escrita simples

para execuções complexas, “a ideia básica de todas essas ferramentas é adicionar
uma camada de abstração para fornecer uma interface de alto nível para algumas
funcionalidades de baixo nível” (Hermanns e Steffens, 2015, p.23).
De modo geral essas ferramentas se propõem a facilitar a administração das
atividades de forma organizada e limpa, substituindo scripts escritos principalmente
em bash que são suscetíveis a práticas inadequadas que podem ocasionar defeito na
execução em larga escala além de erros humanos, para uma linguagem de mais alto
nível.
De acordo com Rahman (2019), defeitos em TI podem ter serias
consequências para a organização, diferente dos scripts IAC que garante a
confiabilidade da implementação automatizada.
Em teoria a implementação de infraestrutura em código com os chamados
Software Configuration Management (SCM) se mostra como uma excelente
alternativa para problemas como padronização, menor taxa de retrabalho, rapidez na
entrega, entre outras funções, porém, uma execução de IaC em larga escala, também
pode significar a propagação de um erro grave a toda organização de TI.
Distintos sistemas trabalham de diferentes formas em situações variadas e com
uma gama de variáveis que quando não verificadas com antecedência podem
ocasionar perdas irreversíveis a organização, portanto, testes automatizados
precisam ser realizados no código desenvolvido para a infraestrutura de TI em
diferentes ambientes para evitar riscos (Johann, 2017), ou seja quando as boas
práticas são aplicadas à criação do script evitam-se vários problemas.

4.7 Extração de configurações

Quando falamos de automação de configurações o termo fatos está bastante

presente nas nomenclaturas, de acordo com a documentação do (PUPPET, 2016a),
fatos são as informações intrínsecas ao sistema que podem vir a ser utilizada
posteriores nos manifestos. Informações de sistemas operacional, arquitetura, IP etc.,
todas podem ser retiradas dos sistemas cliente de forma a se direcionar uma
determinada execução apenas para um modelo específico de acordo com os fatos a
que ela diz respeito.
 20

Os fatos existem nas diversas ferramentas de configurações hoje utilizadas,

como Puppet, através dos facts que se fazem presentes nos agentes nos nodes, chef,
pelo uso da ferramenta Ohai Chef (2016) e Ansible, onde a realização é realizada
através de comandos pelo protocolo de comunicação SSH.
A extração de configurações é um dos principais diferenciais das ferramentas
de gerenciamento de configurações, visto que as informações extraídas são
fundamentais para especificação dos comandos que serão enviados para os clientes,
e essas informações podem determinar sua execução.

4.8 Análise de ferramentas SCM

Nesse capítulo serão mostradas as ferramentas de SCM (software

configuration management) disponíveis no mercado que possuem a licença
opensource, demostrando suas principais funcionalidades e comparações entre elas
com o objetivo de selecionar a ferramenta que mais atende os objetivos propostos
inicialmente.

4.8.1 Puppet

A Puppet Labs, criada por Luke Kanies é a empresa por trás do Puppet,
desenvolvido em 2005, é a mais antiga das ferramentas de gerenciamento entre as
citadas nesse trabalho. Desenvolvida em C++/Clojure sob a licença Apache. O Puppet

Figura 2-Logo Puppet

Fonte: https://puppet.com/

é disponibilizado com versão de código aberto e a versão Puppet Enterprise que

é gratuito por até 10 nós.
A ferramenta utiliza uma linguagem própria de alto nível baseada em Ruby para
descrever o estado da infraestrutura, essa linguagem é utilizada na elaboração dos
manifestos, onde são inseridas as descrições declarativas de ações que serão
 21

realizadas no sistema cliente bem como impõe o estado desejado em que o ambiente
deverá permanecer.
O Puppet possui uma arquitetura cliente/servidor figura 3, onde o servidor,
chamado Puppet master, controla as informações de configurações, centralizando
todos os manifestos, esses, por sua vez, são verificados periodicamente pelos clientes
que buscam em seu perfil de configuração alteração a serem realizadas.
Os agentes obtêm de suas máquinas o que na linguagem popular do
gerenciamento de configurações são chamados fatos. Fatos são descrições sobre o
estado do sistema operacional e suas configurações (versão, OS, IP, hostname),
essas informações são enviadas para o Puppet master e armazenada no PuppetDB
para uma verificação futura.

Figura 3- Fluxograma de funcionamento do Puppet

Fonte: Própria

O PuppetDB é o banco de dados próprio do Puppet, ele armazena dos nodes

as informações trocadas entre cliente e servidor, além dos fatos e os catálogos de
seus nós cliente.

Ao desenvolver suas configurações, os agentes aplicam à configuração em um

 22

intervalo regular (30 minutos por padrão), o que manterá os sistemas sempre no
estado desejado, caso o estado da configuração seja alterado, o agente Puppet
reaplicará sua configuração em intervalos diferentes do padrão.

4.8.2 Ansible

Lançado em 2012 por Michael DeHaan, o Ansible foi criado como uma forma
de busca da simplificação das operações intrínsecas ao gerenciamento de
infraestrutura, segundo Geerling (2014), o Ansible foi criado como uma alternativa a
complexidade de seus concorrentes mais próximos (Puppet e o Chef).

Figura 4-Logo Ansible

Fonte: https://www.ansible.com/

Michael observou que três tarefas comuns (gerenciamento de configurações,

implantação de servidor e execução de tarefas) eram executadas por diferentes
ferramentas, assim, desenvolveu o Ansible para unir em uma única solução as
ferramentas cujas funções são mais utilizadas por administradores.
O Ansible é escrito em python, mesma linguagem utilizada para elaboração dos
playboaks, que é a forma como a ferramenta faz a leitura da sequência de passos ou
funções a serem executadas na máquina destino, essa execução é realizada através
de acesso SSH (Secure Shell), tecnologia utilizado para operações de serviços de
rede em transferência de dados remoto de forma segura entre terminais, Garimella
(2015).
Por se tratar de uma comunicação SSH, o Ansible não necessita que exista um
agente instalado na máquina cliente, outro diferencial é que a ferramenta trabalhar
principalmente na forma push, ou seja, o servidor envia comandos diretamente para
o host cliente, não sendo necessário uma verificação por parte do cliente ao servidor,
como acontece com o Puppet, essa funcionalidade é bastante útil quando uma
determinada tarefa necessita ser enviada com urgência.
 23

Figura 5-Fluxograma de funcionamento do Ansible

Fonte: Própria

A Figura 5 acima mostra o fluxograma de funcionamento da ferramenta, como

não há a necessidade de agente a comunicação é realizada através do protocolo SSH,
diretamente aos nós sem nenhum tipo de intermediário. O servidor do Ansible
armazena playbook e inventários de hosts.
Apesar de compatibilidade com a maioria dos sistemas existentes, o Ansible
necessita de uma adaptação especial para funcionamento no Windows, pois esse
sistema não apresenta ferramenta nativa para o funcionamento da comunicação SSH,
diferente da maioria dos sistemas baseados em Linux, essa inexistência requer a
instalação de uma ferramenta adicional para o funcionamento.

4.8.3 Chef

A empresa Chef foi fundada em 2008 por Adam Jacob, Barry Steinglass,
Nathan Haneysmith e Jesse Robbins e é a criadora do sistema de gerenciamento de
configuração Chef. A empresa disponibiliza 100% da sua solução como código-fonte
aberto sob a licença Apache 2.0 e possuem também uma versão comercial (Chef
Enterprise Automation Stack ™).
 24

Figura 6-Logo Chef

Fonte: https://www.chef.io/

Esse sistema de gerenciamento utiliza um padrão no qual os engenheiros

definem as etapas individuais, essenciais para gerenciar cada máquina. Os arquivos
de definição do Chef são intitulados de receitas e quando combinados com arquivos,
atributos, bibliotecas e módulos criam-se livros de receitas. Essas receitas utilizam
uma linguagem específica do domínio exclusivo do Chef, mas elas suportam scripts
escritos em Ruby.

O Chef é composto por três elementos principais, que são eles:

 Servidores: são centralizadores para armazenamento de dados do Chef,

como dados do cliente, livros de receitas e políticas do sistema, ele é o ponto central
do sistema e é o responsável por armazenar livros de receitas e receitas, que são
scripts feitos em Ruby que dizem como as partes do sistema devem ser implantadas
e administradas.
 Clientes: também conhecidos como nós, são as máquinas que o
software gerencia sejam virtuais ou físicas e que frequentemente buscam e cumprem
as tarefas contidas nos livros de receitas do Chef Server para estar sempre
atualizados.
 As estações de trabalho: são os computadores utilizados pelos
engenheiros para desenvolver e realizar os scripts dos livros de receitas. Cada
estação se comunica com apenas um servidor que contém o repositório com os
arquivos importantes.
 25

Figura 7-Fluxograma de funcionamento do Chef

Fonte: Própria

A imagem acima mostra o diagrama de funcionamento do Chef, onde pode-se

observar que um servido pode se comunicar com diversos nodes e diversas
Workstations ao mesmo tempo.

4.8.4 SaltStack

Thomas Hatch, fundador técnico da SaltStack, em 2011, em meio a execução

de um projeto teve a necessidade de gerenciar uma estrutura grande e complexa de
data center’s, porém não conseguiu enxergar em nenhuma das opções disponíveis
no mercado uma ferramenta que englobasse todos os requisitos que ele precisava,
foi desse ponto que ele criou a ferramenta SaltStack que é desenvolvida em Python e
utiliza SLS (SaLt State Files) para determinar o estado desejado do sistema e
posteriormente abriu seu código para a comunidade.
O Salt trabalha na arquitetura master-agente, porém é mais conhecido em sua
comunidade por master-minion, onde os minions são os clientes da execução e o
master é o servidor que detém toas as configurações a serem executadas nos minions
Zadka (2019), conforme mostrado na figura 8.
 26

Figura 8 - Fluxograma de funcionamento do Chef

Fonte: Própria
O Salt é dividido principalmente em duas funcionalidades, a primeira é
responsável pela manutenção do estado das configurações, ou seja, ele define que
uma determinada configuração deve permanecer no estado desejado inicialmente
como por exemplo a execução de um serviço sempre rodando, caso ela seja alterada
retornará para o estado desejado na próxima varredura. A outra funcionalidade
trabalha como o já mencionado facts que retornar fatos sobre o sistema cliente
podendo assim determinar configurações intrínsecas a esses sistemas.

4.9 Comparação das Ferramentas

Cada ferramenta possui seus pros e contras em qualquer comparação de

sistemas, os sistemas em questão entregam uma solução semelhante, como modo
de operação, plataformas compatíveis, entre outras função. Neste trabalho a
comparação do sistemas de gerenciamento de configuração, se fez necessária afim
de escolher um sistema que atendesse o fluxo de tarefa.
A tabela 1 lista os principais elementos que são levados em consideração ao
se analisar uma ferramenta de gerenciamento de configuração.
 27

Tabela 1 - Comparativo de Ferramentas

Métricas chef Puppet Ansible Saltstack

Disponibilidade ✔ ✔ ✔ ✔

Facilidade de
Médio Médio Fácil Médio
instalação

Gestão Médio Médio Fácil Fácil

Banco de dados PostgreSQL PuppetDB n/a n/a

Altamente
Escalabilidade Altamente escalável Altamente escalável Altamente escalável
escalável

Linguagem DSL (Ruby) DSL (PuppetDSL) YAML (Python) YAML (Python)

Interoperabilidade Alto Alto Alto Alto

Cliente/Servi
Arquitetura Cliente/Servidor Cliente Cliente/Servidor
dor

Fonte: Própria

Podemos observar ao analisar o comparativo a semelhança entre as

funcionalidades, todas as quatro ferramentas têm suas próprias vantagens e
categorias nas quais são melhores que as outras, cabe a escolha baseada no foco da
aplicação.
 28

5. METODOLOGIA

Nesse presente capítulo será tratado a forma como a solução escolhida foi
planejada implantada e adaptada para o modelo da empresa alvo, os problemas
encontrados durante o processo e as alternativas escolhidas para superá-los.

Descrição da Empresa

A Companhia de Águas e Esgotos do Rio Grande do Norte (CAERN) foi criada

em 2 de setembro de 1969 pelo então governador. A empresa incorpora e põe em
prática sua missão de atender toda a população do Rio Grande do Norte com água
potável, coleta e tratamento de esgotos.

A CAERN possui atualmente 165 sistemas de abastecimento de água

distribuídos em 153 sedes de municípios e 13 localidades. No RN são 40 sistemas de
esgoto em 39 municípios e 1 localidade (Praia de Pipa). Apenas 15 cidades do Estado
possuem sistemas de abastecimento de água que não pertencem a CAERN.

A empresa é dividido em 5 grandes grupos ligados diretamente a presidência,

conforme mostra a figura 9 sendo estes divididos entre as seguintes diretorias:

Figura 9 - Organograma CAERN

Fonte: http://www.caern.com.br
 29

Administrativo, Operação e Manutenção, Empreendimentos, Comercial e de

Atendimento e Planejamento e Finanças.

A Gerência de Tecnologia da Informação (GTI), que é ligada a diretoria de

Planejamento e Finanças é responsável por desenvolver, adicionar funcionalidade e
prover o funcionamento dos sistemas internos e agregados para todos esses locais,
tendo como um dos principais objetivos, além de manter a disponibilidade, a melhoria
e otimização dos processos e procedimento que envolvem o atendimento desses
sistemas.

5.1 Estrutura Atual

A empresa dispõe atualmente de um parque de aproximadamente 1200

máquina de diferentes configurações distribuídas em 92 locais espalhados por todo o
estado, conforme mostrado na figura 10 abaixo.
Figura 10 - Regionais CAERN

Administração Central
Regional Natal
Regional Mato Grande
Regional Agreste Trairi
Regional Oeste
Regional Alto Oeste
Regional Sertão Central
Regional Seridó
Sistemas municipais

Fonte: http://www.caern.com.br

A ramificação das localidades espalhadas por toda o estado dificulta o processo

de manutenção dos sistemas internos e suas atualizações nesses computadores. A
empresa dispõe de um parque de máquinas misto, onde 92% dele é composto por
 30

máquina locadas, fornecidas por contratos com duração de no máximo 4 (quatro)

anos, e as demais máquina são próprias da CAERN.

O fato de a maioria das máquinas serem locadas gera uma obrigatoriedade de

substituição das mesmas ao fim do contrato de até 4 (quatro) anos ou também pela
necessidade de atualização das máquinas devido a defasagem do hardware e essas
mudanças de locação acabam gerando uma grande demanda de serviços. Outro
ponto que influencia em constantes alterações são as atualizações dos sistemas
internos, que regularmente precisam que suas mudanças (completas ou parciais),
sejam replicadas as máquinas clientes espalhadas por todo o estado.

Outro fator influente é a heterogeneidade do parque, que possui uma

diversidade de sistemas operacionais desde o Windows 7 até o atual Windows 10,
tendo também arquiteturas de 32 e 64 bits dispersas entre as configurações.

O modelo atual utilizado pela empresa não apresenta nenhum tipo de

automação de processo como solução para o gerenciamento do parque de máquinas.
A gestão é realizada pela ferramenta Samba 4 como controlador de domínio que,
apesar de atender a demanda de gerenciamento de usuários, grupos, permissões e
compartilhamento, por se tratar de uma ferramenta alternativa a utilização do active
directory da Microsoft, deixa a desejar na incompleta compatibilidade de suas funções.

É nesse ponto que a solução proposta nesse projeto soma-se a solução atual
implementada, gerando um ambiente de completa entrega de processos para atender
as demandas propostas nos objetivos. Como já mencionado, esse projeto teve como
foco uma área de pouca abordagem pelas atuais ferramentas gerenciamento de
configurações disponíveis no mercado, uma automação voltada para parque de
desktops esperasse um denominador comum no que se refere a utilização e utilidade
desse modelo.

5.2 Problema Conceitual

Tomando como base o modelo atual e afim de chegar a um denominador

comum acerca da padronização do parque, foi proposto um modelo de projeto de
automação de configurações observando o estado atual de das máquinas presentes
no parque, esse estudo levou a seleção dos requisitos do sistema, escolha da
 31

ferramenta, desenvolvimento dos testes em maquinas virtuais e pôr fim a possível

implementação em um determinado escopo.

5.3 Projeto

Após a revisão literária, o segundo passo foi a elaboração do projeto com base
na estrutura organizacional da empresa. Verificou-se inicialmente que a empresa é
dividida em oito regionais distribuídas pelo estado como mostra a figura 11.

Figura 11 - Siglas Regionais

CAERN

ADC NATAL ROE RMG RAG RAO RSC RSE

Administração Central
Regional Natal
Regional Oeste
Regional Mato Grande
Regional Agreste Trairi
Regional Alto Oeste
Regional Sertão Central
Regional Seridó

Fonte: Própria

Apesar da organização atual utilizar uma configuração padrão entre todas as

regionais, o projeto contempla uma estrutura escalonável, com isso podendo obter um
maior controle de implementações e atualização, ou seja, será possível a atualização
somente de uma ou mais regionais, caso seja interessante realizar testes em uma
determinada área da empresa.

5.3.1 Escolha do Puppet

A escolha da ferramenta foi fundamentada, após análise de suas principais

características, na maior compatibilidade com o ambiente Windows utilizado na
 32

empresa CAERN, visto que a mesma utiliza em seu parque de máquinas quase que
em sua totalidade esse sistema.

Esse foi o principal fator determinante para a escolha do Puppet, considerando

que todas as ferramentas analisadas apresentam funcionalidades semelhantes como
controle de estado, fatos sobre o sistema cliente, utilização de módulos externos.

Das ferramentas analisadas o Puppet é a que mais possui módulos adicionais

que se adaptam as funcionalidades do sistema Windows, como alteração de registro,
controle de atualização do sistema, controle de versão de softwares instalados,
execução de scripts, entre outros.

A grande adesão do mercado à ferramenta também foi um fator, pois leva a

crer que é uma ferramenta com grande potencial de crescimento, o que também é
levada a essa conclusão a grande participação da comunidade em suas
funcionalidades e decisões.

Em contrapartida aos benefícios da escolha do Puppet, essa decisão também

levou a uma grande dificuldade de uso, o Puppet é a ferramenta mais complexa entre
as analisadas, tendo uma alta curva de aprendizado e suas funcionalidades
executadas totalmente em código e através do console.

5.3.2 Análise de Requisitos

A fase de análise de requisitos pode determinar a facilidade e o sucesso na

implementação, é nessa fase que são abordados as funções que serão
implementadas, aquilo que deve existir no projeto, segundo Fernandes (2018), as
propriedades que um sistema deve conter ao ser construído, os requisitos expressam
a necessidade do sistema, de seus usuários e dos administradores.

Com base nesses fundamentos e observado as principais atividades, em

conjunto com o setor de suporte, foram elaborados os requisitos mínimos, ou seja, o
padrão atualmente utilizado e as novas funcionalidades que antes não eram possíveis
de serem automatizadas com a utilização somente do Samba 4,

Requisitos

 Instalar e manter os aplicativos na versão mais nova e mais segura;

 33

 Instalar novos aplicativos a nível global (para toda a rede);

 Criar e manter um padrão de usuários, grupos e senhas (acesso remoto,
administradores locais e usuários de serviços);
 Criar padrão de diretórios e arquivos administrativos (C:\suporte);
 Criação de padrão de diretórios extras (por exemplo, C:\protheus12);
 Instalação e manutenção de impressoras e scanners;
 Criar e manter padrões de aplicação de update de sistema operacional
(com reinicialização obrigatória).

Com as escolha dos requisitos em mãos os passos que se seguem mostrarão

o caminho como os requisitos foram implementados, as adaptações realizadas para
a atendimento total dessa demanda com a ferramenta Puppet.

5.4 Ambiente de teste

Afim de dar continuidade ao projeto, e seguindo os preceitos do

desenvolvimento de sistema, segundo Maldonado (2004), atividades de teste são
bastante propensas a erros, o que nos leva a definir um ambiente de teste que seja
realizado tudo aquilo que antecede a disponibilização do projeto para produção, ou
seja, para o ambiente da empresa.

Esse planejamento do ambiente não se trata apenas da configuração do

sistema, mas de toda estrutura que está em seu envolto Bastos (2007), tudo aquilo
que estará submetido no projeto.

5.4.1 Testes Iniciais

Inicialmente para a execução foi utilizado um ambiente de laboratório para

realizar e validar os primeiros testes. Devido a capilaridade de setores foi determinado
inicialmente uma padronização básica de acordo com os requisitos definidos
anteriormente, ou seja, uma configuração inicial que é presente em todos os
equipamentos do parque de máquinas da empresa.

O ambiente foi simulado com a utilização de máquinas virtuais, utilizando para

isso o programa virtual box e foi criado um ambiente de teste com quatro máquinas
virtuais, sendo eles:
 34

 Sistema CentOS 7 para o ambiente do servidor

 Windows 7 Professional Edition para cliente
 Windows 8.1 Professional Edition para cliente
 Windows 10 Professional Edition para cliente

Levando em consideração para a próxima etapa um ambiente com

aproximadamente 1200 máquinas Windows, porém com diversas versões seria
necessário validar todo o código antes da etapa de execução, para isso no ambiente
de teste foram utilizados diversos sistemas operacionais, citados acima, afim de
simular todas as situações possíveis no ambiente real.

Figura 12 -Tela do Virtual Box

Fonte: Própria

5.4.2 Servidor Puppet

A instalação do servidor foi realizada em distribuição Linux máquina Centos7

como mencionado, o Puppet trabalha na arquitetura cliente/servidor, sendo o servidor
compatível apenas com maquinas Linux, seguindo as orientações exigidas pela
biblioteca Puppet, cuja recomendação para 1000 nós é de um servidor com 4GB de
memória RAM e processador de 2 – 4 núcleos.
 35

Considerando que o laboratório possuí apenas 3 maquinas cliente, que tem por
finalidade emular os configurações dispostas no parque de máquinas, foi determinada
uma configuração intermediaria de 2gb de RAM e processador de 2 núcleos.

5.4.3 Instalação do Puppet Master

A instalação do Puppet exige alguns preparativos na máquina antes do início,

como o servidor recebe diversas solicitações de seus clientes, em que os mesmo
verificam esporadicamente sua novas configurações/estado, é necessário uma
liberação do firewall que vem ativado no sistema.

Para agilidade do processo, a liberação foi realizada através da desativação do

firewall pelo comando abaixo.

#systemctl disable firewalld

A comunicação do agente com o servidor é direcionada via DNS (Domain

Name System), responsável por converter os nomes dos domínios em endereço de
IP, como o Puppet também permite multi servidor, ou seja, permite que os agentes se
comuniquem e requisitem manifestos de um ou mais servidores, a comunicação é
realizada através do nome da máquina e não através do IP, isso facilita a utilização
de DHCP caso seja a única alternativa.

Essa preocupação se deu pelo fato de o agente ser configurado com o nome
do host servidor master, no caso de se utilizar IP, a mudança de servidor ocasionaria
uma trabalhosa substituição do apontamento para o master em todas as maquinas
com agentes instalados.

Como o ambiente de teste não possui um servidor DNS instalado e tendo em

vista a pouca quantidade de maquinas para teste a configuração foi realizada de forma
manual no arquivo de host de cada cliente, conforme descrição abaixo.

Puppet.caern.com.br >>>>> 192.168.0.10

PuppetWin8.1 >>>>> 192.168.0.11
PuppetWin10 >>>>> 192.168.0.12
PuppetWin7 >>>>> 192.168.0.13
 36

Concluído o processo de pré-configuração do servidor o próximo passo foi a

instalação do Puppet master na máquina virtual, essa passo foi realizado através do

yum install puppetserver

gerenciador de pacotes yum do próprio sistema, após a adição dos repositório da
PuppetLabs, conforme comando abaixo.

O Puppet apesar de ser escrito na linguagem ruby é executado em uma

máquina virtual do java (JVM), sendo necessário para o completo funcionamento a
configuração de uso de memória dessa máquina, caso a configuração padrão esteja
baixa, o sistema não consegue iniciar o serviço Puppet e essa foi uma das primeiras
dificuldades encontradas durando o processo de instalação do Puppet máster.

Essa configuração é realizada no arquivo /etc/sysconfig/puppetserver, que

possui as configuração básicas do Puppet server, conforme é mostrado a seguir.

JAVA_ARGS="-Xms512m -Xmx512m"

Essa configuração mínima permite o perfeito funcionamento na máquina Java

para prover o serviço para nosso laboratório, com isso foi possível a inicialização do
serviço através do comando:

service puppetserver restart.

5.4.5 PuppetDb

O PuppetDB é a base de dados utilizada pelo Puppet server, sua inclusão não
é obrigatória ao sistema, o Puppet server pode rodar independente dessa
implementação, porem, para um melhor gerenciamento da informação o PuppetDB é
de fundamental importância para que ocorra o armazenamento de informações dos
nodes.

A instalação é realizada exclusivamente no servidor, com isso as informações

armazenadas por ele podem ser disponibilizadas em formado de API tanto para a
 37

versão web do Puppet enterprise, como para a versão open source do painel web, o
pupetboard.

Esse armazenamento de informações, no nosso modelo, é importante afim de

verificar histórico de modificações aplicadas aos nós e possíveis erros de
implementação do manifesto.

Os passos de instalação foram seguidos de acordo com a documentação oficial

do Puppetdb na versão 6.0.

5.4.6 Instalação do Puppet Agent

Para o ambiente cliente se faz necessário a instalação do Puppet Agent,

responsável pelo comunicação agente/server, recebimento e execução dos manifesto
obtidos no Puppet máster. O Puppet Agent tem privilegio administrativo para execução
de todos os comandos que se fazem necessários na máquina cliente.

Foi instalado a versão 6.9.0 do Puppet Agent, durante o processo de instalação

na plataforma Windows é realizada o direcionamento para o Puppet master, no nosso
caso direcionado para o host puppet.caern.com.br conforme figura 13. As três
máquinas virtuais do laboratório receberam o agente Puppet.

Figura 13 - Tela de Instalação Puppet Agent

Fonte: Própria
 38

Ao concluir a instalação o agente cria automaticamente os certificados SSL

locais que serão responsáveis pela autenticação do nó no servidor, inicialmente é
solicitada uma autorização que deverá ser aceita diretamente no Puppet master
conforme a figura 13, após o aceite do máster o cliente está apto a receber os
manifesto fornecidos.

O código acima mostra o recebimento de uma solicitação do agente da

máquina adcgti000480l.caern.local, juntamente com sua chave SSL. As solicitações
podem ser verificadas com a utilização do comando “puppetserver ca list”. Até que a
solicitação seja aceita o cliente não tem acesso aos manifesto.

Por padrão a ferramenta não permite que as solicitação sejam aceitas

automaticamente, podendo, caso seja necessário, realizar a alteração dessa
configuração, por critérios de segurança optamos pela não alteração dessa.

Os comando abaixo foram utilizado para o aceite das solicitações pendentes,

sendo tanto o aceite de todas as solicitados como individualmente.

Puppetserver ca sign –all

Puppetserver ca sign –certname adcgti000480l.caern.local

5.5 Manifestos

Como já mencionado, o Puppet utiliza como seus arquivo de referência o

manifesto, segundo Dicio (2019), a palavra é definia como um texto de natureza
dissertativa, uma declaração pública de princípios, persuasão ou intenção.

Em nosso projeto o manifesto define o estado da infraestrutura, ou seja, a forma

padrão que todo o parque de maquinas deve permanecer para se enquadrar no
padrão definido. Os objetivos específicos desse trabalho, juntamente com a análise
de requisitos definida no item 5.3.2, foram a base para a elaboração dos manifestos.
 39

O manifesto também é responsável por direcionar a atualização para os nós,

como verificado na linha 1 do código abaixo, o código em questão está sendo
direcionado apenas para o nó “rnsedbp030336.caern.local”. No caso de a
configuração de estado ser direcionada para todos os nós, essa configuração é
alterada para “default”.

1 node 'RNSedbp030336.caern.local' {
2
3 user { 'administrador':
4 ensure => 'present',
5 groups => ['BUILTIN\Administradores'],
6 password => $adminpass,
7 require => Exec['AtivarContaAdmin']
8 }
9 }

5.5.1 Nome do Host

A empresa CAERN dividida em sete regionais como mostrado na figura 9, a

administração central não é considerada uma regional no organograma da empresa,
mas para o setor de TI é considerado um local a parte, tendo em vista que esse local
concentra a maior quantidade de equipamentos em relação aos demais locais da
empresa.

Para organização espacial desses máquinas foi definido um padrão de nome

para o host, conforme mostrado na tabela 2, ele define o local, setor, tombamento do
equipamento e se a máquina é locada ou pertence a CAERN. Essa configuração
permite visualizar o local em que o equipamento foi instalado diretamente através do
nome do host.

Tabela 2 - Padrão de Nomenclatura de Host

Regional Setor Tombamento Situação Nome do HOST
RNS USUT 1500 L rnsusut1500L
RNG GSL 3276 rmggls3276
ADC USUT 4100 L adcusut4100L
RMG UMAS 2563 Rmgumas2563

Fonte: Própria
 40

5.5.2 Expressão regular

O uso de expressões regulares permite através da filtragem de uma string

generalizada, determinar caracteres dentro de uma sequência capaz de identificar um
padrão, a finalidade é identificar cadeia de caracteres do interesse da aplicação,
Michael (2019).

Como descrito no item anterior, capilaridade dos setores é utilizada no nome

de host como forma de identificá-lo, o que facilita o uso de expressões regulares. A
ferramenta Puppet aceita esse tipo de implementação.

Objetivando colocar em pratica essa função, foi escolhido um setor com

características peculiares em suas configurações, o setor jurídico da CAERN, que é
caracterizado pela sigla AJU.

Diferentes dos demais setores as máquinas da AJU, que estão presentes em

diferentes regionais, não permitem modificação em suas configurações, visto que eles
rodam aplicações jurídicas dos diversos tribunais espalhados pelo Brasil, qualquer
mínima modificação pode ocasionar a interrupção da aplicações, gerando atrasos
jurídicos. Afim de evitar esse problema o setor será excluído das configurações padrão
das demais maquina da empresa através do uso de expressões regulares conforme
descrito baixo.

1
2 #Expressão utilizada para incluir exclusivamente o setor AJU
3
4 node /^(?i)(ADC|RMG|ROE|RNS|RAG|RNN|RSC|RSE|RAO)(AJU)\d+(l|L|).*$/ {
5
6 CODIGO DE EXECUÇÃO
7 }
8
9
10 ## Expressão utilizada para aceitar todos menos AJU
11
12 node /^(?i)(ADC|RMG|ROE|RNS|RAG|RNN|RSC|RSE)(?!AJU)([a-z]+)\d+(l|L|).*$/ {
13
14 CODIGO DE EXECUÇÃO
15
16 }
17
 41

O código acima mostra a implementação da função no manifesto, o interior do

código de execução será mostrado mais adiante. Até o momento podemos verificar o
potencial de adaptação da ferramenta Puppet.

5.5.3 Módulos base

Os módulos são utilizados para aprimoramento de funções especificas do

Puppet, eles podem ser encontrados diretamente na página oficial do Puppet forge, e
sua adição a comunidade pode ser realizada por qualquer usuário que deseje
contribuir.
Figura 14 - Categoria de Módulos

Fonte: https://forge.puppet.com/

Apesar de aberta a adição a criação de módulos segue padrões determinados

pela PuppetLabs, os módulos recebem marcações de acordo com seu nível de
confiabilidade conforme mostrado na figura 14 acima.

Com o objetivo se manter o implementação com a maior conformidade e

confiabilidade foram escolhidos módulos da categoria aprovados ou suportados. Os
módulos listados na tabela abaixo executam funções exclusivas na plataforma
Windows, principalmente com a criação de providers para a plataforma, que nada
mais são do que provedores de determinados serviços internos ao sistema.
 42

Tabela 3 - Tabela de Módulos

Módulo Status Função

windows_env Aprovado Manages Windows environment variables
chocolatey Suportado Chocolatey package provider for Puppet
Manage WSUS (Windows Server Update Service) settings
wsus_client Suportado
for client nodes
A module that will turn windows features on or off for
windowsfeature Aprovado
Windows Server 2008 and above
Adds a new exec provider for executing PowerShell
powershell Suportado
commands.
reboot Suportado Adds a type and provider for managing system reboots.
This module provides a native type and provider to
registry Suportado
manage keys and values in the Windows Registry

Fonte: Própria

Os módulos listados na tabela 3 foram instalados no servidor Puppet e

importados no código do manifesto. Dos módulos instalados apenas o módulo
chocolathey exigem importação direta no código.

5.5.4 Fatos sobre o sistema

Mencionado anteriormente os fatos mostram características intrínsecas do

sistema operacional, essa informações são importantes quando a execução de um
determinado manifesto exige uma abordagem mais profunda.

O modelo de parque apresenta diferentes sistemas operacionais com

diferentes arquiteturas (32 ou 64 bits) ao executar uma determinada função o
administrador deve garantir que uma única execução seja compatível com os diversos
sistemas operacionais e arquiteturas em execução, isso garante uma entrega correta
da aplicação.

O exemplo a seguir mostra a execução local do comando “Puppet facts”,

conforme mostrado abaixo podemos observar algumas características peculiares ao
sistema, tendo como base essas informações ao se elaborar o manifesto o
administrador pode condicionar a execução de um determinado trecho do código
apenas a uma arquitetura ou modelo de S.O. específicos.
 43

Command >> Puppet Facts

"facterversion": "3.14.4",
"fqdn": "ADCAJU0051L",
"hardwareisa": "x64",
"hardwaremodel": "x86_64",
"hostname": "ADCAJU0051L",
"id": "ADCAJU0051L\\username",
"os": {
"architecture": "x64",
"family": "windows",
"hardware": "x86_64",
"name": "windows",
"release": {
"full": "10",
"major": "10"

O código abaixo utiliza o modulo registry para execução do provider de

alteração/criação de determinada chave de registro, é observada a utilização de uma
condicional na linha 1 e 11, para explicitar a arquitetura em que o código deve ser
executado, esse modelo de condicional foi utilizada no nosso manifesto para mudança
da senha do sistema de acesso remoto, que deve ser modificada periodicamente por
critérios de segurança determinados pelo setor de suporte.

1 if $facts[os][architecture] == 'x64' {
2 warning('Senha VNC definida')
3 registry_value { 'VNCPassword':
4 path => 'HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\TightVNC\S
5 erver\Password',
6 ensure => present,
7 type => binary,
8 data => "b5 6e 2b 1a 48 95 40 d4",
9 }
10 }
11 if $facts[os][architecture] == 'x86' {
12 warning('Senha VNC definida')
13 registry_value { 'VNCPassword':
14 path => 'HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC\Server\Passw
15 ord',
16 ensure => present,
17 type => binary,
18 data => "b5 6e 2b 1a 48 95 40 d4",
19 }
20 }
 44

5.5.4 Código do manifesto

Como já descrito anteriormente o manifesto define o estado da infraestrutura,

ou seja, a forma padrão que todo o parque de maquinas deve permanecer para se
enquadrar no padrão definido.

Esse conjunto de função quando bem inseridas internamente ao manifesto

Puppet, podem definir com precisão o estado em que a infraestrutura deverá
permanecer. A elaboração do manifesto, como em uma linguagem de programação
para o desenvolvimento de um determinado software, segue normas de boas práticas
para o perfeito entendimento a quem a ele necessitar, esses por sua vez devem
compreender com clareza as diretrizes determinadas no código afim de aprimora-las
ou corrigi-las quando se fizer necessário.

O projeto foi pautado inicialmente na elaboração de apenas um manifesto,

utilizando nesse, módulos específicos do Puppet. O anexo mostra a elaboração inicial
do código, nele pode ser observado um aglomeramento único de todas as função no
mesmo local, é importante destacar que essa elaboração atende com perfeição os
requisitos e objetivos propostos inicialmente a esse projeto, porem alguns pontos em
questão devem ser observados:

 Organização – a perfeita organização do código facilita a correção de

erros e a melhor visualização das funções;
 Segurança – proteção de dados como senhas e chaves de acesso;
 Clareza – rápido entendimento para a equipe de administração;
 Fluidez da execução – execução em etapas, executar apenas o
necessário.

Como em qualquer outra linguagem o aprendizado foi importante para mostrar

como elaborar um código limpo e organizado, prática que Inicialmente não foi possível
devido à pouca experiência com a linguagem.

A evolução proporcionou o particionamento do único código em módulos

próprios. O Puppet permite a criação de módulos através do kit de desenvolvimento,
com isso foi possível transformar cada função, ou um conjunto de função em um
 45

modulo próprio independente, essa secção em módulos trouxe uma notável

compactação no código, deixando-o mais claro, como observado abaixo.

node 'default' {

include caern_vnc
include caern_adminpass
include caern_diretorios
include caern_cert
include caern_app

O manifesto acima executa em todas as máquinas do parque, de uma forma

limpa, ele contém apenas os módulos que deverão ser executados, os módulos, por
sua vez, estão divididos conformo organização abaixo, onde o arquivo init.pp é
executado inicialmente, chamando por sua vez os arquivos de referência.

o Caern_adminpass (Nome do módulo)

 Manifests
 Init.pp (arquivo padrão do módulo)
 administrador.pp (código principal do módulo)
 params.pp (arquivo de variáveis)

O arquivo params.pp contem a variável responsável por informar qual a senha

que os computadores passarão a reconhecer, inicialmente pelo anexo, caso fosse
necessário essa substituição, o arquivo necessitaria uma edição em 4 ponto, sendo
possível agora modificá-lo em apenas um ponto, direcionando a informação a
variáveis, conforme mostra o conteúdo do arquivo params.pp. Essa organização foi
necessária para um melhor entendimento do código dos manifestos e de toda a
execução como um todo.

class caern_adminpass::params {
#Configuração
$adminpass = ‘xxxxxx' #definição da senha
}
 46

5.6 Puppet board

A ferramental Puppet board é um complemento utilizado para visualização de

relatório do Puppet. Como descrito inicialmente o PuppetDB armazena as informações
porem, nativamente, apenas a versão enterprise do Puppet tem uma funcionalidade
de geração de relatório de implementações.

Afim de disponibilizar uma ferramenta gratuita com funcionalidades

semelhantes a oficial a comunidade Puppet disponibilizou o Puppetboar, responsável
por organizar e viabilizar informações contidas na base de dados do Puppet.

A implementação dessa ferramenta foi importante na organização e

visualização do estado do parque de maquinas da CAERN gerando históricos de
implementações, armazenamento de informações do parque e gerando um inventario
através das informações de facts obtidas dos nós.

Durante a implementação na empresa, o acompanhamento da modificação foi

importante na descoberta de erros durante a execução dos manifestos. Conforme é
mostrado na figura 15, o status de erro é informado pela ferramenta, podendo, de
forma precisa, elaborar uma estratégia para solução, esse erro na execução do
manifesto pode estar ligado desde a problemas internos nos nós até a inexistência de
biblioteca necessária para execução da função.

Figura 15 - Tela Puppet Board

Fonte: Puppetboard (Própria)

Assim como é mostrado o estado de erro, o estado Unchanged também é

listado nos nós que não tiveram nenhum tipo de alteração relacionada no manifesto,
ou seja, de acordo com seu estado atual, a implementações no manifesto a que ele
faz referência não são aplicáveis.
 47

Com esse controle é possível de forma escalável determinar com precisão o

nível de atualização em que o parque se encontra.

Figura 16- Dashboard Puppetboad

Fonte: Puppetboard (Própria)

A ferramenta em questão dispõem de um Dashboard para visualização geral

das informações mais importantes disponível de forma objetiva conforme pode ser
observado na figura 16 acima, essa disposição facilita a imediata visualização de
possíveis erros, bem como o andamento de aplicações e nós com pendencias de
aplicações.

Apesar de não ser uma ferramenta oficial da Puppet Lab, o Puppetboad se

mostrou útil na implementação pela facilidade de uso e a clareza na disposição das
informações a serem passadas ao administrador do sistema. É importante destacar
que a ferramenta não executa funções de modificação, mas apenas de visualização.
 48

6 RESULTADOS

Este capitulo destina-se a verificação e análises dos resultados obtidos,

demonstrando os procedimentos e impactos da utilização na empresa alvo, levando
em consideração os prós e os contras da ferramenta escolhida de forma sucinta.
Como já foi citado foi utilizado um ambiente de laboratório para a realização do projeto,
sendo inicialmente uma rede de maquinas virtuais e após foram testadas em
aproximadamente 110 máquinas em produção e com os êxitos obtidos mostram que
futuramente podem ser aplicadas em todo o parque de maquinas, o que não foi feito
neste trabalho devido ao tempo necessário para a realização e outros fatores
intrínsecos ao ambiente, mas o que já sugere a necessidade de trabalhos futuros na
temática.

Visando a segurança na implementação, foi escolhida está parcela de 10% do

total de equipamentos, afim de simular o ambiente real. Os locais foram escolhidos de
forma aleatória para as maquinas nós, porem dispostas por todo o estado, essa
disposição foi feita afim de verificar o comportamento da ferramenta em ambientes
que possuem grandes variações na velocidade do link de internet, desde a rádio até
fibra ótica.

Em se tratando de uma ferramenta que define o estado, viu-se que sua

utilização precipitada e de forma errada pode gerar danos de difícil reparação a
infraestrutura de TI da empresa por isso a cautela de não aplicar em todo o parque já
que mesmo os testes iniciais terem sido executados em laboratório foi necessário
considerar as variáveis do ambiente real, como por exemplo a idade do sistema,
aplicações instaladas, versões de atualização de sistema, versões de aplicativos
intrínsecos ao sistemas.

Durante a execução nas maquinas em produção foi constatado uma dificuldade

como mostra a figura 17, pois as maquinas não estavam homogêneas já que algumas
apresentaram versões desatualizas do Power Shell, que é um framework de execução
de comando internos nas maquinas clientes, o que acarretou em um erro no
desempenho de módulos que utilizavam provider Power Shell, exemplificado na figura
18. Devido a utilização do PuppetBoard foi possível detectar de forma ágil a falha,
acelerando assim todo o processo.
 49

Figura 18 - Erro na Execução do Manifesto

Fonte: Própria

Figura 17- Tela de Erro PuppetBoard

Fonte: Própria

No processo de implementação foi elaborado um script inicial que sofreu

modificações no decorrer do processo de acordo com a necessidade no processo de
aprendizagem da linguagem utilizada pela ferramenta e das dificuldades encontradas.
Um exemplo disso foi o seccionamento do código inicial em módulos elaborados
 50

seguindo os padrões de boas práticas do Puppet development kit, essa divisão

proporciona uma maior clareza no script, facilitando seu entendimento para os que se
utilizam do mesmo.

Outra funcionalidade da divisão em módulos foi a possibilidade de manipulação

através de variáveis de ambiente, tornando o gerenciamento e manutenção mais
centralizado, ou seja, uma variável que antes era necessário alterar em diversas
partes do código, passou a ser modificada apenas no arquivo param.pp do módulo.

Os pilares fundamentais da segurança da informação são a disponibilidade,

confidencialidade e a integridade, a quebra de um desses princípios reflete uma falha
de segurança da informação, o que também pode ser nomeado como incidente de
segurança da informação, Oliveira (2017). De acordo com esses princípios ao se
manter os padrões de definição do estado da rede é ofertado segurança já que a
medida que o parque é mantido atualizado, a vulnerabilidade é reduzida, gerando uma
integridade e por ventura uma maior disponibilidade.

No que se refere ao estado da infraestrutura foi observado que a ferramenta

proporcionou uma homogeneidade na rede, seguindo os padrões definidos nos
requisitos do sistema, pois a cada trinta minutos ocorre uma nova verificação de
estado, caso ocorra alguma alteração no manifesto será repassado as maquinas.

Um fator comum neste âmbito é a modificação de senhas do administrador das

regionais. Mesmo existindo um padrão pela gerencia para todas as maquinas, ocorre
que alguns técnicos de suportes que tem autonomia para essas alterações, acabam
modificando as senhas de acordo com seus próprios padrões, dificultando assim o
acesso de outros técnicos. Com a utilização do Puppet essas falhas não ocorreram já
que o sistema segue o manifesto assim mantendo o padrão.

Essa verificação de sistema a cada trinta minutos gera diversas aplicabilidades,

uma amostra disto é a garantia da execução continua de um serviço, por exemplo o
VNC, que é necessário que esteja sempre funcionando já que ele é quem dá acesso
remoto ao suporte das maquinas, ou seja caso esse serviço pare o Puppet irá
restaurar na sua verificação, que antes só seria percebido quando fossem utilizar e o
sistema não estaria disponível, desta forma o Puppet funciona como um verificador
automático de listas de controle.
 51

7 CONCLUSÃO

Durante o processo de elaboração do trabalho foi possível observar através da

ferramenta Puppet, bem como as demais ferramentas disponíveis no mercado que ao
entorno delas existem sempre grandes comunidades envolvidas na orientação,
desenvolvimentos de módulos e complementos, enfatizando assim a preocupação
unificada acerca de gerenciamento de configurações.

Foi possível obter bons resultados referente ao controle do parque mesmo a

amostra sendo de apenas 10% do total de máquinas da empresa, o que leva a crer
que em uma possível aplicação futuramente em 100% da máquinas geraria resultados
semelhantes.

Apesar de um alto nível de precisão em implementação ainda assim foi

necessário a intervenção de forma manual aos equipamentos que apresentaram erros
na implementação dos manifestos.

Após toda a revisão e aplicação no trabalho é possível afirmar que apesar das
ferramentas de gerenciamento de configuração terem como principal aplicação os
servidores virtuais, clouds e servidores em nuvem, é possível também ser utilizada
com êxito em um parque de desktops clientes, o que valida a proposta do trabalho.

Como acadêmico, usuário assíduo das tecnologias e apreciador de

ferramentas opensource foi uma experiência de grande satisfação que me trouxe além
da aprendizagem para complementação dos conceitos adquiridos durante a
graduação, a possibilidade de contribuir dentro do meu ambiente de trabalho e
disponibilizar a toda a comunidade acadêmica e aos demais que buscam pela
temática, uma utilização da ferramenta de gerenciamento de configuração sob uma
nova ótica.
 52

REFERÊNCIAS BIBLIOGRÁFICAS

DE MENDONÇA, Cláudio Márcio Campos et al. Governança de tecnologia da informação: um estudo

do processo decisório em organizações públicas e privadas. Revista de Administração Pública-RAP,
v. 47, n. 2, p. 443-468, 2013.

WEILL, Peter; ROSS, W. Jeanne. Governança de TI: como as empresas com melhor desempenho
administram os direitos decisórios de TI na busca por resultados superiores. São Paulo: Makron
Books, 2006.

MAGALHÃES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de serviços de TI na prática:

uma abordagem com base na ITIL: inclui ISO/IEC 20.000 e IT Flex. Novatec Editora, 2007.

HÜTTERMANN, Michael. DevOps for developers. Apress, 2012.

WILLIS, John. What Devops Means to Me. CHEF BLOG, [S. l.], p. 1, 16 jul. 2010. Disponível em:
https://blog.chef.io/what-devops-means-to-me/. Acesso em: 11 out. 2019.

SALEEM, Hussain; BURNEY, SM Aqil. Imposing Software Traceability and Configuration Management
for Change Tolerance in Software Production. IJCSNS, v. 19, n. 1, p. 145, 2019.

RAHMAN, Akond; WILLIAMS, Laurie. Source code properties of defective infrastructure as code
scripts. Information and Software Technology, v. 112, p. 148-163, 2019.

MORRIS, Kief. Infrastructure as code: managing servers in the cloud. " O'Reilly Media, Inc.", 2016.

BRIKMAN, Yevgeniy. Terraform: Up & Running: Writing Infrastructure as Code. O'Reilly Media,
2019.

HERMANNS, Joel; STEFFENS, Andreas. The current state of ‘Infrastructure as Code’and how it
changes the software development process. Full-scale Software Engineering, v. 19, 2015.

JOHANN, Sven. Kief morris on infrastructure as code. IEEE Software, n. 1, p. 117-120, 2017.

GEERLING, Jeff. Ansible for DevOps. 2014.

GARIMELLA, D.; KUMAR, R. Secure Shell-Its significance in Networking (SSH). Int. J. of Application
or Innovation in Engineering & Management, v. 4, n. 3/12, p. 187-196, 2015.

PUPPET. Facter documentation. 2016. Disponível em: <https://docs.puppet.com/

facter/>. Citado na página 18.
ZADKA, Moshe. Salt Stack. In: DevOps in Python. Apress, Berkeley, CA, 2019. p. 121-137.

FERNANDES, João M.; MACHADO, Ricardo J. Requisitos em projetos de software e de sistemas

de informação. Novatec Editora, 2018.

MALDONADO, José Carlos et al. Introduçao ao teste de software. São Carlos, p. 23, 2004

BASTOS, Anderson et al. Base de conhecimento em teste de software. São Paulo, 2007.
 53

MANIFESTO. In: DICIO, Dicionário Online de Português. Porto: 7Graus, 2019. Disponível
em: https://www.dicio.com.br/indole/. Acesso em: 02/11/2019.
MICHAEL IV, Louis G. et al. Regexes are hard: Decision-making, difficulties, and risks in programming
regular expressions. In: ACM International Conference on Automated Software Engineering
(ASE). ACM. 2019.

OLIVEIRA, Aline Devitto de. Segurança da Informação nas Organizações: Uma Reflexão
Sobre Sua Importância E Vulnerabilidades. 2017. 37 f. TCC (Graduação) - Curso de Ciência
da Computação, Anhanguera Educacional, Leme, 2017. Disponível em:
<http://repositorio.pgsskroton.com.br/bitstream/123456789/15663/1/ALINE%20DEVITTO%2
0DE%20OLIVEIRA.pdf>. Acesso em: 15 out. 2019.

ALVES, Brunno dos Passos. Proposta de Processo Ágil de Desenvolvimento de Software

em uma Instituição de Educação Pública. 2016. Especialização (Especialização em Gestão
da Tecnologia da Informação) - Instituto Federal de Educação, Ciência e Tecnologia de São
Paulo – IFSP, [S. l.], 2016.
 54

ANEXO

if $osfamily == 'windows' {
warning('O sistema é compatível com este manifesto')

file { 'c:\Suporte':
ensure => 'directory',
}

file { 'c:\Protheus23':
ensure => directory,
source => 'file://SUPORTE/Protheus/Protheus23',
recurse => true,
}

file { 'c:\Suporte\certificado.ps1':
ensure => file,
source => 'file://SUPORTE/Suporte/_Certificado/certificado.ps1',
recurse => true,
}

exec { 'AtivarContaAdmin':
command => 'Get-LocalUser -Name "admin*" | Enable-LocalUser',
unless => '$text = Get-LocalUser -
Name adm* | select enabled; if ($text.enabled -eq $false) { exit 1 }',
provider => 'powershell'
}

exec { 'certifica':
command => 'certutil -addstore -enterprise -
f "ROOT" \\\SUPORTE\Suporte\\_Certificado\\Fortinet_CA_SSL.cer',
unless => '$certt = Get-ChildItem cert:\LocalMachine\root -
Recurse |Select-String "CN=XXXXXXX" -quiet; if ($certt -ne $true) { exit 1 }',
provider => 'powershell'
}

user { 'administrador':
ensure => 'present',
groups => ['BUILTIN\Administradores'],
password => 'SENHA'
}

$installApps = [
'7zip.install',
'netfx-4.7.1-devpack',
 55

'tightvnc']

package { $installApps:
ensure => latest,
provider => 'chocolatey',
}
if $facts[os][architecture] == 'x64' {
warning('Senha VNC definida')
registry_value { 'VNCPassword':
path => 'HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\TightVNC\Se
rver\Password',
ensure => present,
type => binary,
data => " Código Hexa ",
}
registry_value { 'VNCControlPassword':
path => 'HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\TightVNC\Se
rver\ControlPassword',
ensure => present,
type => binary,
data => " Código Hexa ",
}
registry_value { 'VNCPasswordViewOnly':
path => 'HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\TightVNC\Se
rver\PasswordViewOnly',
ensure => present,
type => binary,
data => " Código Hexa ",
}

registry_value { 'VNCUseVncAuthentication':
path => 'HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\TightVNC\Se
rver\UseVncAuthentication',
ensure => present,
type => dword,
data => "00000001",
}
registry_value { 'VNCUseControlAuthentication':
path => 'HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\TightVNC\Se
rver\UseControlAuthentication',
ensure => present,
type => dword,
data => "00000001",
}
}

if $facts[os][architecture] == 'x86' {
warning('Senha VNC definida')
registry_value { 'VNCPassword':
 56

path => 'HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC\Server\Passwor

d',
ensure => present,
type => binary,
data => " Código Hexa ",
}
registry_value { 'VNCControlPassword':
path => 'HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC\Server\Control
Password',
ensure => present,
type => binary,
data => " Código Hexa ",
}
registry_value { 'VNCPasswordViewOnly':
path => 'HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC\Server\Passwor
dViewOnly',
ensure => present,
type => binary,
data => " Código Hexa ",
}

registry_value { 'VNCUseVncAuthentication':
path => 'HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC\Server\UseVncA
uthentication',
ensure => present,
type => dword,
data => "00000001",
}
registry_value { 'VNCUseControlAuthentication':
path => 'HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC\Server\UseCont
rolAuthentication',
ensure => present,
type => dword,
data => "00000001",
}
}

} else {
warning('Esse manifesto é compativel apenas com sistemas Windows')
}