Tutorial Ansible v1

Prévia do material em texto

INTRODUÇÃO AO ANSIBLE
Autor: Vamberto Rocha JR
Contato: vambertojr@gmail.com
-v1.0-
Introdução ao Ansible
Com o avanço e a popularização das tecnologias de virtualização e
cloud, os administradores de sistemas gerenciam muito mais servidores do que
antigamente, fazendo com que uma simples tarefa de atualização dos
servidores seja extremamente trabalhosa e demorada.
O Ansible é uma ferramenta open source para orquestração e
automação da configuração de servidores, que veio para facilitar a vida dos
administradores de sistemas. Com ele é possível realizar tarefas como:
Instalação e atualização de pacotes, configuração e deploy de aplicações,
gerenciamento de usuários e varias outras tarefas administrativas com enorme
ganho de desempenho e produtividade.
Características
• É Escrito em Python – Diferentemente de outras ferramentas como:
Puppet e Chef, que são escritos em Ruby, o Ansible é escrito em Python
que é uma linguagem interpretada, de script, imperativa e orientada a
objetos;
• Não necessita de agentes – Diferentemente de outras feramentas de
automação de configuração como: Puppet e Chef, o Ansible não
necessita que agentes sejam instalados nos hosts remotos;
• Utiliza SSH para se conectar aos hosts remotos – O protolo SSH é
utilizado para acesso seguro a hosts remotos, o Ansible utiliza esse
protocolo para o acesso aos hosts; 
• Utiliza linguagem JINJA2 para os templates;
• Utiliza a linguagem YAML para escrever os playbooks – YAML é uma
linguagem que é facilmente entendida por seres humanos;
• Vasta quantidade de módulos e códigos no github – Através do site
https://galaxy.ansible.com/ ou do comando ansible-galaxy, é possível
baixar e reutilizar playbooks escritos por outros usuários.
Outra característica importante é que o Ansible funciona de forma
idempotent, isso significa que um comando só será aplicado quando ele
realmente necessitar ser aplicado. Para entender melhor o que significa ser
idempotent, imagine que foi escrita uma tarefa para instalar um determinado
pacote, ao ser executada primeiramente o Ansible irá verificar se o pacote
existe no host remoto, caso não exista a tarefa será executada e o pacote será
instalado, caso exista a tarefa não será executada. Esse comportamento vale
para o Ansible de uma forma geral, apenas a tarefa de instalação de pacotes.
Instalação
O Ansible não necessita ser instalado em todos os hosts do seu
parque de servidores, apenas no host que irá gerenciar os outros. É necessário
apenas que nos servidores que serão gerenciados, também chamados de hosts
remotos, se tenha instalado um interpretador python. Caso o interpretador
python instalado na máquina remota seja inferior a versão 2.5, é necessário a
instalação do pacote python-simplejson 
A instalação do Ansible no host de gerência é bem simples, não são
exigidos daemons ou banco de dados. Mesmo sendo possível a instalação do
Ansible através do código fonte, só irei abordar a instalação através dos
gerenciadores de pacotes YUM e APT, que é a forma sugerida pelo próprio site
da ferramenta.
Sistema Operacionais Red Hat Like
Para instalação do Ansible em sistema operacionais baseados em
Red Hat (Red Hat, Fedora, CentOS), é necessário adicionar ao gerenciador de
pacotes YUM o repositório EPEL e em seguida, executar o seguinte comando:
$ yum install ansible
Sistemas Operacionais Debian Like
Para instalação do Ansible em sistema operacionais baseados em
Debian (Debian, Ubuntu), é necessário executar os seguintes comandos: 
$ sudo apt-get install software-properties-common
$ sudo apt-add-repository ppa:ansible/ansible
$ sudo apt-get update
$ sudo apt-get install ansible
Após a instalação, o comando “ $anisble –version ” poderá ser
executado para verificar qual a versão do Ansible foi instalada. 
Para maiores informações sobre a instalação do Ansible em outras
plataformas, ou até utilizando o código fonte, basta acessar a página da
documentação oficinal da ferramenta cujo endereço é:
http://docs.ansible.com/ansible/intro_installation.html 
Comandos 
Com a instalação do pacote ansible alguns comandos, listados logo
abaixo, são adicionados ao path do sistema operacional. Iremos detalhar cada
um dos comandos e termos apresentandos posteriormente.
• ansible – Executa tasks (tarefas) em hosts 
• ansible-doc – Exibe a documentação dos módulos do ansible
• ansible-galaxy – Gerencia roles utilizando a comunidade 
galaxy.ansible.com
• ansible-playbook - Executa um ansible playbook
• ansible-pull – É utilizado para configurar uma cópia remota do ansible em
cada host gerenciado.
• ansible-vault – Criptografa e gerência arquivos criptografados YAML
Conceitos Importantes
O Ansible não é uma ferramenta complexa, porém existem muitos
termos e conceitos que são importantes para a sua correta utilização.
Acredito que para começarmos a utiliza-lo é importante aprendermos os
itens listados a seguir: 
• Inventory – Lista de hosts que irão receber os comandos executados
pelo servidor Ansible; 
• Modules – Controlam os recursos (serviços, pacotes, arquivos, etc.) do
host remoto; 
• Tasks – Tarefa que será executada no(s) host(s);
• Playbook - Conjunto de tarefas que serão executadas no(s) host(s);
• Roles - São maneiras de carregar automaticamente determinados
arquivos como: vars_files, tasks e handles com base numa estrutura de
arquivo conhecidos.
Inventory
O inventário é uma parte importante na arquitetura do Ansible, é
nele que será definida a lista de hosts que irão receber os comandos do
servidor Ansible. Por padrão, o inventário está localizado em
/etc/ansible/hosts, mas nada impede que você informe o inventário de hosts
em outro lugar, utilizando a opção -i ao executar playbooks e comandos ad-
hoc. 
Além de hosts, o inventário pode se utilizado para declaração de
variáveis e parâmetros para acesso do Ansible ao host remoto. Lembrando que
o Ansible sempre utiliza os hosts definidos no arquivo de inventário para
execução de playbooks e comandos ad-hoc.
Em seguida é apresentado um exemplo de arquivo
/etc/ansible/hosts e no Anexo I desse documento são listados alguns
parâmetros que podem ser declarados no arquivo de inventário. 
mail.example.com
#Definindo grupo de servidores webservers
[webservers]
foo.example.com
bar.example.com
host1 http_port=80 maxRequestsPerChild=808
#Definindo grupo de servidores dbservers
[dbservers]
one.example.com 
two.example.com
# Definindo grupo global web no inventory
[web:children]
webservers
dbservers
# Definindo variáveis para o grupo webservers no inventory
[webservers:vars]
ntp_server=ntp.example.com
proxy=proxy.example.com
Módulos 
O Ansible possui uma grande quantidade de módulos predefinidos
que podem ser utilizados para executar tarefas nos hosts remotos tanto
através de comandos ad-hoc (executam apenas uma tarefa) como de
playbooks (executam várias tarefas), além disso, os usuários podem escrever
seus próprios módulos.
Para obter mais informações sobre os módulos do Ansible, basta
acessar o endereço http://docs.ansible.com/ansible/modules.html ou utilizar os
seguintes comandos:
• $ansible-doc -l : Lista todos os módulos predefinidos do Ansible
• $ansible-doc [nome_do_módulo]: Exibe informações específicas de um
módulo
 
Comandos Ansible Ad-Hoc
Lembrando que os hosts que irão receber as alterações realizadas
pelo Ansibles, devem estar cadastrados no arquivo de inventário
/etc/ansible/hosts ou em qualquer outro arquivo desde que ao executar o
comando ad-hoc ou playbook seja expecificado o arquivo de hosts com a opção
-iSegue o comando Ansible para executar tarefas
$ansible <host> [opções]
<host>- Host ou grupo de hosts que serão afetados pelo comando, all pode ser
definido para referenciar todos os hosts do arquivo de inventário. 
Seguem algumas opções importantes do comando ansible
-i [inventário] – Especificando um arquivo de inventário ex: -i /ansible/hosts
-m [módulo] – Especificando módulo
-u [usuário] – Especificando usuário SSH para acesso remoto
-k – A senha do usuário ssh será solicitada após a execução do comando
-s – O modo super usuário (sudo) irá ser utilizado para execução do comando
-K – A senha sudo do usuário irá será solicitada após execução do comando
-a [“modules_args”] - Define algumentos dos módulos
-a [“comando linux”] - Comando Linux a ser executado num host remoto
-- version – Exibe a versão instalada do Ansible
Segue o comando Ansible para executar tarefas utilizando módulos:
$ansible <host> -m <módulo> -a “<parâmetros_do_modulo>”
Com a execução do comando, você deverá receber no prompt de
comando algumas mensagens informando o resultado e se ele foi realizado
com sucesso ou falha. O quadro abaixo apresenta a execução de um comando
ansible especificando apenas o host chamado “wolverine” onde o comando
linux hostname é executado no host remoto, e como resultado é mostrado que
foi realizado com sucesso e na ultima linha o resultado de sua execução.
$ansible wolverine -i hosts -a "hostname"
wolverine | SUCCESS | rc=0 >>
wolverine 
Segue abaixo alguns exemplos de comandos ad-hoc Ansible 
utilizando os mais variados módulos:
Testando conectividade do Ansible 
#Executa um ping entre os hosts
$ansible tomcat1 -i /ansible/hosts -m ping -u root -k
Gathering Facts Ansible 
#lista as veriáveis facts do host tomcat1
$ansible tomcat1 -i /ansible/hosts -m setup -u root -k
Execução de comandos linux
#Lista informações de memória de todos os hosts cadastrados no arquivo host
$ansible all -i /ansible/hosts -a “free -m” -u root -k 
#Lista informações de partições do host remoto server1
$ansible server1 -i /ansible/hosts -a “df -m” -u root -k
#Reinicia o serviço httpd no host remoto webhost
$ansible webhost -i /ansible/hosts -a “service httpd restart” -u root -k
Instalação de pacotes
#Instala o pacote httpd(apache) em servidor Red Hat Like
$ansible webservers -m yum -a "name=httpd state=present" -u root -k
#Instala o pacote iptraf em servidor Debian Like
$ansible webservers -m apt -a "name=iptraf state=present" -u root -k
Gerenciamento de serviços
#Verifica se o serviço httpd está iniciado, caso não esteja ele será iniciado
$ansible webservers -m service -a "name=httpd state=started" -u root -k
Gerenciamento de usuários
#Cria o usuário de nome user1 em todos os hosts presentes no arquivo hosts
$ansible all -m user -a "name=user1 password=<crypted password here>" -u 
root -k
Gerencimento de arquivos e pastas
#Copia o arquivo /etc/hosts do host local para o arquivo /tmp/hosts do host
remoto atlanta. 
$ansible atlanta -m copy -a "src=/etc/hosts dest=/tmp/hosts" -u root -k
#Cria o diretório /backup/mp3 no host remoto webserver setando alguns 
parâmetros de permissão.
$ansible webserver -m file -a "dest=/backup/mp3 mode=755 owner=vamberto
group=admin state=directory" -u root -k
Gerenciamento de Banco de Dados Mysql
#Cria o database diretoria no mysql do host remoto dbserver
$ansible dbserver -m mysql_db -a “ name=diretoria state=present”
#Cria o usuário admin, define sua senha e privilégios no mysql do host remoto
dbserver 
$ansible dbserver -m mysql_user -a “name=admin password=12345 
priv=*.*:ALL state=present”
Uma lista com todos os módulos, e seus parâmetros, está
disponível no endereço:
http://docs.ansible.com/ansible/modules_by_category.html. É recomendável
que você acesse o endereço e verifique os principais módulos, juntamente com
os parâmetros para a sua utilização.
Playbooks
Playbooks são o motivo pelo qual o Ansible ser uma ferramenta tão
poderosa, são com eles que realizamos a automação da configuração e
orquestração de servidores. Se com os comandos ad-hoc nós realizamos
apenas uma tarefa por vez, com o uso de playbooks nós realizamos varias
tarefas de uma só vez. Desde a instalação de pacotes, configuração e deploy
de aplicações, verificação de serviços, atualização do sistema, etc. 
Como foi dito anteriormente, os playbooks são escritos numa
linguagem chamada YAML que é de fácil interpretação pelos humanos. Para
criarmos o nosso primeiro playbook, primeiramente devemos criar um arquivo
(com editor de texto de sua preferência) iniciando ele com os caracteres “ --- “,
isso sinaliza que o arquivo é escrito com a linguagem YAML, em seguida
declaramos quais os hosts ou grupos de hosts (de acordo com o inventário de
hosts criado anteriormente) com a opção “ – hosts: “, utilizamos a opção “
tasks: “ e depois disso podemos declarar as tarefas (tasks) que o playbook irá
executar nos hosts remotos.
---
- hosts: <hosts>
 tasks:
 - name: <Nome da tarefa>
 <modulo>: <parâmetros_do_modulo> 
Algumas conciderações devem ser feitas: A indentação é uma parte
fundamental da linguagem YAML, linhas de códigos com erro de indetação
causarão falha ao tentar executar o playbook. É possível escrever tarefas
(tasks) sem a opção “- name”, porém aconselho utilizá-la pois a descrição
utilizada na opção irá aparecer durante a execução do playbook, tornando
assim muito mais fácil de sabermos o que está sendo executado. O exemplo de
código informado acima contém apenas o mínimo necessário para se escrever
um playbook, variáveis, configuração de conexão, permissões, etc. Também
podem ser declaradas no playbook. Exemplos mais detalhados serão
apresentados posteriormente.
 
Utilização de playbooks (exemplo 1)
Antes de partirmos para a criação do nosso primeiro playbook, irei
apresentar o ambiente de teste criado. Instalei uma máquina de teste no
virtualbox (ambiente virtual) cujo hostname é ansibletest com endereço ip
192.168.0.100/24, essa máquina receberá as configurações da máquina
ansible, cujo endereço ip é 192.168.0.10/24. O host ansible utiliza o sistema
operacional Ubuntu 14.04 e possui instalado o pacote ansible, enquanto o host
ansibletest utiliza o sistema operacional CentOS 7.0 e terá o interpretador
python instalado.
Na máquina Ansible criei uma entrada IP/hosname no arquivo
/etc/hosts, referenciando a máquina ansibletest e configurei o uso do SSH sem
senha da máquina ansible para a máquina ansibletest.
/etc/hosts da máquina ansible
127.0.0.1 localhost 
127.0.1.1 ansible
192.168.0.100 ansibletest
A pasta /ansible foi criada para armazenar o arquivo de hosts e
todos os playbooks criados. Primeiramente temos que criar um arquivo
/ansible/hosts (com o editor de textos de sua escolha) que funcionará como
nosso inventário, esse arquivo terá apenas o nome do host remoto que irá
receber os comandos declarados no playbook, no nosso caso, esse arquivo terá
apenas o nome ansibletest. Caso o host remoto não tenha uma entrada no
DNS, você pode utilizar o endereço IP ao invés do nome. Em seguida, na
mesma pasta onde o arquivo de hosts está criado, vamos criar um arquivo
chamado playbook_apache.yml com as linhas apresentadas abaixo:
/ansible/playbook_apache.yml
--- 
- hosts: all 
 
 tasks: 
 - name: Atualizando o sistema operacional 
 yum: name=* state=latest 
 - name: Instalando a versão mais atual do apache 
 yum: name=httpd state=latest 
Figura 1: Topologia do ambiente de teste
 - name: Garantindo que o apache está rodando 
 service: name=httpd enabled=yes state=running
Esse playbook será aplicado em todos os servidores declarados no
arquivo hostse irá executar 3 tarefas: Atualização do sistema operacional,
instalação da versão mais recente do servidor web Apache e garantir que o
Apache esteja rodando e configurado para se iniciado automaticamente na
inicialização do sistema operacional. É importante salientar que as tasks
(tarefas) no ansible são executadas na ordem em que elas são declaradas no
arquivo playbook.
Para executar o playbook criado, basta acessar a pasta /ansible e
digitar o seguinte comando:
 $ansible-playbook -i hosts playbook_apache.yml
Na Figura Erro: Origem da referência não encontrada 2 é
apresentado o resultado da execução do playbook_apache.yml. Na primeira
task “Atualizando o sistema operacional” nenhuma alteração foi realizada, o
Sistema Operacional já estava atualizado. Na segunda e terceira task “
Instalando a versão mais atual do apache” e “Garantido que o apache está
rodando” respectivamente, podemos perceber que o Ansible realizou
alterações, instalando e inicializando o servidor web Apache. 
Figura 2: Execução do playbook_apache.yml
Observando melhor a imagem, além da execução das 3 tasks que
declaramos no playbook, uma quarta task foi executada, a “setup”. A task
setup é, por padrão, sempre executada e ela é utilizada na descoberta de
variáveis chamadas de facts do host remoto. Iremos explicar melhor o que são
e como fazer uso das facts posteriormente. 
Utilização de playbooks (exemplo 2)
No exemplo 2 nós iremos escrever um playbook que irá instalar o 
serviço Network Time Protocol (NTP) no host ansible teste e irá configura-lo 
para que ele busque a hora num suposto servidor ntp em nossa rede 
(ntpserver.minharede.com) no host ansibletest. 
O playbook apresentado abaixo será aplicado em todos os hosts do
arquivo hosts e irá executar 3 tarefas: Instalação do pacote ntp, copiar o
arquivo de configuração (ntp.conf) da máquina onde o ansible está executando
para o host remoto e efetuar o restart do serviço ntp.
Vamos utilizar a mesma topologia e arquivo hosts apresentados no
exemplo 1. Na mesma pasta onde o arquivo de hosts está criado, vamos
criar um arquivo chamado playbook_ntp.yml com o conteúdo apresentado
abaixo:
/ansible/playbook_ntp.yml
--- 
- hosts: all 
 
 tasks: 
 - name: Instalando a versão mais atual do ntp 
 yum: name=ntp state=latest 
 - name: Copiando o arq de configuração do ntp
 copy: src=/ansible/files/ntp.conf dest=/etc/ntp.conf 
 - name: Garantindo que o serviço ntp está rodando 
 service: name=ntp state=reloaded 
Além do arquivo playbook_ntp.yml, nós precisamos criar o arquivo
ntp.conf na pasta /ansible/files para que ele seja copiado e substitua o
arquivo /etc/ntp.conf no host remoto. 
/ansible/files/ntp.conf
driftfile /var/lib/ntp/ntp.drift 
statsdir /var/log/ntpstats/ 
statistics loopstats peerstats clockstats 
filegen loopstats file loopstats type day enable 
filegen peerstats file peerstats type day enable 
filegen clockstats file clockstats type day enable 
server ntpserver.minharede.com 
restrict 127.0.0.1 
restrict ntpserver.minharede.com 
restrict ::1
Para executar o playbook criado, basta digitar o seguinte comando:
 $ansible-playbook -i hosts playbook_ntp.yml
Na Figura Erro: Origem da referência não encontrada 3 é
apresentado o resultado da execução do playbook_ntp.yml. Na primeira task o
Ansible irá instalar a versão mais atual do NTP, Na segunda e terceira task
respectivamente o Ansible irá copiar o arquivo de configuração que criamos
para o host ansibletest e reiniciar o serviço NTP. 
Como prova que o Ansible funciona de maneira idempotent,
executei novamente o mesmo playbook e o resultado pode ser conferido na
Figura Erro: Origem da referência não encontrada 4. 
Figura 3: Primeira execução do playbook_ntp.yml
Como podemos perceber, o Ansible não realizou nenhuma
alteração nas tarefas de instalação e copia do arquivo de configuração do NTP,
pois ambos já tinham sido realizadas na primeira execução do
playbook_ntp.yml
Conclusão
Apensar do pouco apresentado até agora, podemos perceber o
quão poderosa e útil é o Ansible no gerenciamento da configuração e
osquestração dos servidores, nos exemplos apresentados nesse documento,
executamos tarefas em apenas um host, mas e se tivéssemos dezenas,
centenas ou até milhares de hosts para administrar ? 
Na próxima versão desse documento, ao qual já está em
desenvolvimento, irei apresentar alguns conceitos mais avançados do Ansible,
a utilização de variáveis, configuração de aplicações usando templates,
notificação de serviços utilizando handlers, organização e execução de
playbooks utilizando roles, criptografia utilizando o ansible-vault. 
Figura 4: Segunda execução do playbook_ntp.yml
Anexo I
No anexo I é apresentado uma lista com parâmetros que podem ser
utilizados na comunicação entre o servidor Ansible e o(s) host(s) remoto(s).
Todas esses parâmetros apresentados foram retirados do site da
documentalção oficial do Ansible, que pode ser acessa através do endereço
http://docs.ansible.com/ . 
ansible_connection - Connection type to the host. This can be the name of
any of ansible’s connection plugins. Common connection types are local, smart,
ssh or paramiko. The default is smart.
SSH connection:
ansible_host - The name of the host to connect to, if different from the alias
you wish to give to it.
ansible_port - The ssh port number, if not 22
ansible_user -The default ssh user name to use.
ansible_ssh_pass - The ssh password to use (this is insecure, we strongly
recommend using --ask-pass or SSH keys)
ansible_ssh_private_key_file - Private key file used by ssh. Useful if using
multiple keys and you don’t want to use SSH agent.
ansible_ssh_common_args - This setting is always appended to the default
command line for sftp, scp, and ssh. Useful to configure a ProxyCommand for
a certain host (or group).
ansible_sftp_extra_args - This setting is always appended to the default sftp
command line.
ansible_scp_extra_args - This setting is always appended to the default scp
command line.
ansible_ssh_extra_args - This setting is always appended to the default ssh
command line.
ansible_ssh_pipelining - Determines whether or not to use SSH pipelining.
This can override the pipelining setting in ansible.cfg.
Privilege escalation 
ansible_become - Equivalent to ansible_sudo or ansible_su, allows to force
privilege escalation
ansible_become_method - Allows to set privilege escalation method
ansible_become_user - Equivalent to ansible_sudo_user or ansible_su_user,
allows to set the user you become through privilege escalation
ansible_become_pass - Equivalent to ansible_sudo_pass or ansible_su_pass,
allows you to set the privilege escalation password
Remote host environment parameters:
ansible_shell_type - The shell type of the target system. You should not use
this setting unless you have set the ansible_shell_executable to a non-Bourne
(sh) compatible shell. By default commands are formatted using sh-style
syntax. Setting this to csh or fish will cause commands executed on target
systems to follow those shell’s syntax instead.
ansible_python_interpreter - The target host python path. This is useful for
systems with more than one Python or not located at /usr/bin/python such as
*BSD, or where /usr/bin/python is not a 2.X series Python. We do not use the
/usr/bin/env mechanism as that requires the remote user’s path to be set
right and also assumes the python executable is named python, where the
executable might be named something like python2.6.
ansible_*_interpreter - Works for anything such as ruby or perl and works
just like ansible_python_interpreter. This replacesshebang of modules which
will run on that host.
	INTRODUÇÃO AO ANSIBLE
	Autor: Vamberto Rocha JR
	Contato: vambertojr@gmail.com
	-v1.0-
	Introdução ao Ansible
	Características
	Instalação
	Sistema Operacionais Red Hat Like
	Sistemas Operacionais Debian Like
	Comandos
	Conceitos Importantes
	Inventory
	Módulos
	Comandos Ansible Ad-Hoc
	Testando conectividade do Ansible
	Gathering Facts Ansible
	Execução de comandos linux
	Instalação de pacotes
	Gerenciamento de serviços
	Gerenciamento de usuários
	Gerencimento de arquivos e pastas
	Gerenciamento de Banco de Dados Mysql
	Playbooks
	Utilização de playbooks (exemplo 1)
	Na Figura Erro: Origem da referência não encontrada 2 é apresentado o resultado da execução do playbook_apache.yml. Na primeira task “Atualizando o sistema operacional” nenhuma alteração foi realizada, o Sistema Operacional já estava atualizado. Na segunda e terceira task “ Instalando a versão mais atual do apache” e “Garantido que o apache está rodando” respectivamente, podemos perceber que o Ansible realizou alterações, instalando e inicializando o servidor web Apache.
	Observando melhor a imagem, além da execução das 3 tasks que declaramos no playbook, uma quarta task foi executada, a “setup”. A task setup é, por padrão, sempre executada e ela é utilizada na descoberta de variáveis chamadas de facts do host remoto. Iremos explicar melhor o que são e como fazer uso das facts posteriormente.
	Utilização de playbooks (exemplo 2)
	/ansible/files/ntp.conf
	driftfile /var/lib/ntp/ntp.drift statsdir /var/log/ntpstats/ statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable server ntpserver.minharede.com restrict 127.0.0.1 restrict ntpserver.minharede.com restrict ::1
	$ansible-playbook -i hosts playbook_ntp.yml
	Conclusão
	Anexo I
	SSH connection:
	Privilege escalation
	Remote host environment parameters: