Assim sendo, uma solicitação a db.exemplo.com poderia ser redirecionada para o porto 27017 localizada no mesmo servidor por meio dos seguintes passos:

Verifique que haja uma linha habilitada a carregar a configuração de um arquivo que ainda iremos criar. Esse arquivo o chamaremos de db.exemplo.com.conf.

vi /usr/local/apache2/conf/httpd.conf

Procure por onde estejam os “Include” ou vá até o final do arquivo e adicione a seguinte linha:

Include conf/extra/db.exemplo.com.conf

Salve httpd.conf e edite db.exemplo.com.conf com o seguinte conteúdo:

<VirtualHost *:80>
  ProxyPreserveHost On
  ProxyRequests Off
  ServerName db.exemplo.com
  ProxyPass / http://localhost:27017
  ProxyPassReverse / http://localhost:27017
</VirtualHost>

Caso o módulo proxy do apache não esteja habilitado ainda, os seguintes passos resolvem essa situação:

sudo a2enmod proxy
sudo a2enmod proxy_http

E finalmente, reinicie o Apache2 para ativar a configuração:

sudo service apache2 restart

Isso feito, uma chamada a db.exemplo.com ira a ser atendido pelo servidor que estiver ouvindo no porto 27017 do localhost.

Obviamente que redirecionar para um outro servidor, apenas requer indicar o nome ou IP de dito servidor.

Redirecionando para um servidor Secundário SSL

Porém, pode ser que seja necessário repassar certa informação para um servidor secundário também Apache2. Por exemplo, como quando o servidor primário desvia o atendente a um outro servidor e este outro servidor precisa saber qual o dominio utilizado na requisição original.

Nesse caso, se faz necessário uma solução um pouco mais complexa com a mostrada a seguir em que todas as requisições que chegam a comercio.exemplo.com serão atendidas por srv2.exemplo.com:

<VirtualHost 127.0.0.1:80 _default_:80>
    ServerName comercio.exemplo.com
    Redirect / https://comercio.exemplo.com
</VirtualHost>

<VirtualHost 127.0.0.1:443 _default_:443>
    ServerName comercio.exemplo.com
    ProxyRequests Off
    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    ProxyPass / http://srv2.exemplo.com:80/
    ProxyPassReverse / http://srv2.exemplo.com:80/
    <Location />
        Order allow,deny
        Allow from all
    </Location>

    SSLCertificateFile %(SSLCertificateFile)
    SSLCertificateKeyFile %(SSLCertificateKeyFile)

    SSLProtocol -ALL +TLSv1.2
    SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
    SSLHonorCipherOrder on
    SSLCompression off

    ProxyPreserveHost On
    RequestHeader set X-Forwarded-Proto: \"https\"

    RequestHeader set X-Forwarded-Port: 443

    Header always set Strict-Transport-Security \"max-age=63072000;\"
    Header set X-Content-Type-Options \"nosniff\"
    Header always append X-Frame-Options \"SAMEORIGIN\"
    Header set Cache-Control \"no-cache, no-store, no-transform\"
    Header set Pragma \"no-cache\"
    Header set X-XSS-Protection \"1;  mode=block\"
    Header set Referrer-Policy: \"strict-origin-when-cross-origin\"
    Header set Content-Security-Policy: \"default-src https: data: 'self' 'unsafe-inline' 'unsafe-eval';\"
    Header set Feature-Policy: \"fullscreen 'self'\"
    Header set x-permitted-cross-domain-policies \"none\"

    FileETag None

</VirtualHost>

Continuando a saga, o meu cliente precisou que o sistema dele funcionasse com pdo_oci. Isso fez com que fosse necessário instalar algumas coisas e compilar o módulo do php.

Tudo o aqui feito precisa de ser super-usuário, então a primeira coisa é fazer login como root:

sudo su -

Fiz uma pasta para que fique todo junto e seja fácil copiar as coisas para outro local depois.

cd
mkdir dev
cd dev

Obviamente que a primeira coisa a fazer é atualizar o sistema:

apt update -y && sudo apt upgrade -y

Baixei os seguintes arquivos de https://www.oracle.com/database/technologies/instant-client/linux-x86-64-downloads.html:

oracle-instantclient-devel-10.2.0.5-1.x86_64.rpm
oracle-instantclient-basic-10.2.0.5-1.x86_64.rpm

Como o servidor é um Ubuntu (filho do Debian) precisamos a ferramenta alien para poder transformar esses arquivos .rpm em .deb

apt install alien -y

E converti os arquivos usando o alien

alien -d oracle-instantclient-basic-10.2.0.5-1.x86_64.rpm
sudo alien -d oracle-instantclient-devel-10.2.0.5-1.x86_64.rpm

Isso gerou dois arquivos que passei a instalar usando o dpkg

dpkg -i oracle-instantclient-basic_10.2.0.5-2_amd64.deb
dpkg -i oracle-instantclient-devel_10.2.0.5-2_amd64.deb

Com isso, agora temos uma pasta /usr/share/oracle/10.2.0.5/client64/ com a livraria do cliente e uma outra pasta /usr/include/oracle/10.2.0.5/client64/ com os arquivos necessários para a compilação.

Publiquei o ambiente:

export ORACLE_HOME=/usr/share/oracle/10.2.0.5/client64/
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
ldconfig

Sendo que nossa versão de PHP é a 5.6.40 puxei o código fonte dela:

wget http://php.net/get/php-5.6.40.tar.bz2/from/a/mirror -O php-5.6.40.tar.bz2

Expandi o arquivo:

tar xjf php-5.6.40.tar.bz2

E preparei a pasta do módulo para compilá-lo:

cd php-5.6.40/ext/pdo_oci/
phpize

Isso produz a seguinte saída (que pode variar dependendo da versão de PHP que você está usando)

Configuring for:
PHP Api Version: 20131106
Zend Module Api No: 20131226
Zend Extension Api No: 220131226

No arquivo Makefile.global, adicionei a seguinte linha logo após INSTALL e INSTALL_DATA:

EXTRA_INCLUDES = -I/usr/include/oracle/10.2.0.5/client64

Alterei o `config.m4` adicionando 10.2 à lista das livrarias suportadas

SUPPORTED_LIB_VERS="9.0 10.1 10.2 11.1 12.1"

Alterei o script configure para reconhecer nosso php_pdo_driver.h deixando ele da seguinte forma:

if test -f $abs_srcdir/include/php/ext/pdo/php_pdo_driver.h; then
    pdo_cv_inc_path=$abs_srcdir/ext
elif test -f $abs_srcdir/ext/pdo/php_pdo_driver.h; then 
    pdo_cv_inc_path=$abs_srcdir/ext
elif test -f $prefix/include/php/ext/pdo/php_pdo_driver.h; then 
    pdo_cv_inc_path=$prefix/include/php/ext
elif test -f /root/dev/php-5.6.40/ext/pdo/php_pdo_driver.h; then 
    pdo_cv_inc_path=/root/dev/php-5.6.40/ext/pdo/ 
fi

E (usando o cliente que foi instalado na sessão anterior) rodei o configure assim:

./configure --with-pdo-oci=instantclient,/opt/oracle_instantclient,10.2

Logo (e não tendo dado erros) compilei o módulo:

make

E procedi a instalar a extensão:

make install

Com o que ele nos devolve o local onde a extensão foi instalada:

Installing shared extensions:     /usr/lib/php/20131226/

Criei um arquivo para indicar ao php que desejo carregar a extensão compilada.

vi /etc/php/5.6/mods-available/pdo_oci.ini

Com o seguinte conteúdo:

; priority=20
extension=pdo_oci.so

E habilitei o módulo:

phpenmod pdo_oci

Finalmente reiniciei o apache:

apachectl restart

E comprovei se a extensão foi instalada e habilitada:

php -i | grep -i pdo

Devolvendo-me o seguinte resultado em tela:

PDO
PDO support => enabled
PDO drivers => oci
PDO_OCI
PDO Driver for OCI 8 and later => enabled
PWD => /root/dev/php-5.6.40/ext/pdo_oci
_SERVER["PWD"] => /root/dev/php-5.6.40/ext/pdo_oci

Evidentemente que essa extensão depende de ter a pasta /root/dev/php-5.6.40/ext/pdo_oci e caso seja necessário é possível instalar em outra pasta. Mas isso já não é o caso.

Recentemente me solicitaram colaborar em um problema de conexão entre OracleXE 10.2g e PHP 5.6

Por serem duas plataformas antigas, precisei montar meus servidores para emular tal situação.

Como na descrição não veio se era Apache ou Nginx e o comum era usar o Apache2 e me indicaram estar rodando em Ubuntu20, optei por Apache2.

Este, então, é o roteiro que segui para construir um laboratório que emulasse essa situação. Levantei dois servidores. Um para conter o Oracle XE e outro para o LAMP assim podia realizar meus testes.

O que se segue é o relato da saga.

Repare que estamos rodando sempre como root. Caso queira usar um usuário (como de fato é o certo a fazer) basta adicionar o sudo antes de cada comando.

No nosso caso é root pois os contêineres OpenVZ já rodam em ambiente seguro.

Garantir os templates do OpenVZ

Usamos OpenVZ para criarmos nossas VPS. A imagem do CentOS 7 já tínhamos, mas nos faltava a do Ubuntu. Começamos por ela.
Após uma busca, achamos este repositório:
https://plug-mirror.rcac.purdue.edu/ubuntu-cloud/releases/20.04/release/
Mas ele se mostrou inadequado.
Optamos então por usar o template do Ubuntu 16 disponível em http://mirror.yandex.ru/mirrors/download.openvz.org/template/precreated/

Criação da primeira VPS

Se bem temos nosso próprio script para criarmos as VPS preferi colocar linha por linha o que foi feito para que fique mais claro… e de quebra alguém se interessa em OpenVZ

$ vzctl create 104 --ostemplate ubuntu-16.04-x86_64 --config basic
$ vzctl set 104 --save --name lamp $ vzctl set 104 --save --onboot yes 
$ vzctl set 104 --save --hostname lamp.InovacaoSistemas.com.br 
$ vzctl set 104 --save --ipadd 192.168.1.104/24 
$ vzctl set 104 --save --searchdomain InovacaoSistemas.com.br
$ vzctl set 104 --save --nameserver 1.1.1.1 --nameserver 8.8.4.4 
$ vzctl set 104 --save --cpus 2 
$ vzctl set 104 --save --ram 512M 
$ vzctl set 104 --save --swap 1G 
$ vzctl set 104 --save --diskspace 20G 
$ vzctl start 104 
$ vzctl exec 104 passwd 
$ vzctl exec 104 apt-get update -y

Atualização para Ubuntu 20.04

Após instalarmos o Ubuntu 16, procedemos com um upgrade para termos um 20.04 rodando o do-release-upgrade.
O problema é que como escolhemos a imagem mínima, tivemos que primeiro instalar a ferramenta e logo a seguir atualizar o sistema.

$ apt install ubuntu-release-upgrader-core
$ apt update -y
$ apt upgrade -y

Primeiro atualizamos de 16.04 para 18.04

$ do-release-upgrade

E mais uma vez para irmos de 18.04 para 20.04

$ apt update -y
$ apt upgrade -y
$ do-release-upgrade --mode=server --quiet

Como é uma atualização de uma instalação nova, respondemos que sim a todas as perguntas…. como se fossemos usuários Windows.

Uma vez feito isso, reiniciamos a máquina e testamos algumas coisas para ver se estava tudo ok.

Como nos pode ser útil ter um Ubuntu 20, decidimos guardar uma cópia na forma de template.

$ vzctl stop 104
$ cd /vz/private/104
$ tar -cvzpf /vz/template/cache/ubuntu-20.04-server-amd64.tar.gz .

Mas isso não faz parte do roteiro. Foi apenas um agradável desvio.

Criação da segunda VPS

A segunda máquina é uma CentOS 7 mas a criamos usando o script e a chamada ficou assim:

$ ./createCentos7VM.sh 102 oracleXE inovacaosistemas.com.br

Instalando o Oracle 10.2 XE no CentOS

Dentro do CentOS realizamos as seguintes operações:

$ yum install epel-release
$ yum update -y
$ yum install libaio bc flex -y
$ yum install install glibc.i686
$ wget http://ftp.cs.stanford.edu/pub/fedora/6/i386/oracle-xe-10.2.0.1-1.0.i386.rpm
$ rpm -ivh oracle-xe-10.2.0.1-1.0.i386.rpm
$ /etc/init.d/oracle-xe configure

No arquivo /etc/bashrc adicionamos uma chamada ao script que constrói o ambiente dentro do qual os comandos do oracle podem funcionar como a seguir

. /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/oracle_env.sh

(não esqueça do ponto seguido de um espaço no inicio)

Liberamos algumas portas no firewall assim

$ firewall-cmd --permanent --zone=public --add-port=8080/tcp
$ firewall-cmd --permanent --zone=public --add-port=1521/tcp
$ firewall-cmd --reload

Feito isso, criamos a partir do nosso micro um túnel assim:

$ ssh root@192.168.1.102 -L8080:localhost:8080

Isso nos permitiu abrir o navegador localmente com o seguinte endereço:

http://localhost:8080/apex

Usando o APEX, criamos um usuário como mostramos nesta figura:

Esse usuário e senha é o que usaremos mais adiante para testarmos nossa conexão.

Instalando o Apache2 e o PHP5.6 no Ubuntu

Instalamos o apache2 da seguinte maneira

$ apt get install apache2 -y

Como não nos interessa problemas de domínio, segurança e coisas parecidas, deixamos ela como está.

Já instalar o php5.6 requer um pouco mais de voltas. Mais ou menos com quando um cachorro vai deitar.

$ apt install software-properties-common 
$ add-apt-repository ppa:ondrej/php
$ apt update -y
$ apt install -y php5.6

Criamos um pequeno script para nos mostrar a situação em /var/www/html chamado info.php com o seguinte conteúdo:

<?php
  phpinfo();

E abrimos ele no navegador para visualizar se o PHP estava rodando e em qual versão

http://192.168.1.104/info.php

Reiniciamos o servidor para termos certeza que tudo está ok.

Instalando o cliente Oracle no Ubuntu

Fizemos download do basic-10.2.0.5.0-linux.zip e sdk-10.2.0.5.0-linux.zip deste endereço: https://www.oracle.com/database/technologies/instant-client/linux-x86-64-downloads.html

E depois o instalamos

$ unzip basic-10.2.0.5.0-linux-x64.zip
$ mkdir /opt/oracle_instantclient
$ mv instantclient_10_2/* /opt/oracle_instantclient/
$ unzip ../sdk-10.2.0.5.0-linux.zip
$ mv instantclient_10_2/* /opt/oracle_instantclient/
$ cd /opt/oracle_instantclient/
$ ln -s libclntsh.so.10.1 libclntsh.so
$ apt-get install php5.6-dev -y
$ apt-get install libaio-dev -y
$ apt-get install php5.6-common php5.6-xml php5.6-cli -y
$ apt-get install php-pear -y
$ pecl channel-update pecl.php.net
$ pecl install oci8-2.0.12

Na hora em que pergunte onde está o cliente instantclient, devemos indicar instantclient,/opt/oracle_instantclient

Dando tudo certo com a compilação, devemos adicionar o oci8.so aos php.ini da seguinte forma:

$ echo "extension=oci8.so" >> /etc/php/5.6/apache2/php.ini
$ echo "extension=oci8.so" >> /etc/php/5.6/cli/php.ini

Outra coisa que precisamos fazer é indicar onde ficou a livraria do instant-client como segue:

$ echo /opt/oracle_instantclient/ > /etc/ld.so.conf.d/oracle-instantclient.conf
$ ldconfig

E finalmente reiniciamos o apache2 assim:

$ apachectl restart

Navegando novamente no http://192.168.1.104/info.php podemos confirmar que o OCI está configurado como mostra a figura

Finalmente, testamos nossa conexão com um pequeno script colocado em /var/www/html sob o nome testar-conexao-oracle.php com este conteúdo:

<?php
$conn = oci_connect("teste", "abc123", "192.168.1.102/XE");
if ($conn) {
echo "Conexão realizada com sucesso\n";
} else {
echo "Erro na conexão com o banco de dados\n";
}

E testamos o mesmo desde a linha de comando:

$ php testar-oci8.php

Se tudo ocorreu bem ele nos mostrará que a conexão deu certo.

Podemos também testar usando o navegador:

http://192.168.1.104/testar-oci8.php

Bem, com isso chegamos ao fim do problema da conexão com vanilla PHP.

MTU significa Max Transmission Unit e determina o tamanho máximo que um pacote de dados pode ter. Um tamanho grande de MTU, está associado a uma redução no overhead ao passo que um tamanho pequeno de MTU pode reduzir a demora de resposta da rede.

Esse tamanho não é o mesmo para todos os provedores de internet, já que depende das capacidades físicas da rede. Logo, deve ser ajustada para obter a melhor performance. Esse ajuste pode ser feito de forma automática ou manual.

Uma forma de descobrir o melhor MTU é usando o comando ping. Antes de começar, mude o MTU do seu roteador para o valor máximo (Geralmente é 1500).

Depois, de um micro conectado nessa rede, utilize o seguinte comando para determinar a média do seu ping:

$ ping -c 10  -D -s 1462 1.1.1.1 | tail -1| awk '{print $4}' | cut -d '/' -f 2

Na linha acima, estamos usando uma largura de pacote de 1453.

Instruimos o ping a repetir por 10 vezes com um alvo bem conhecido (1.1.1.1). Passamos o resultado disso para três comandos que nos darão a média de pingar 10 vezes o alvo com o tamanho do pacote determinado.

Devemos repetir esse teste várias vezes em diferentes momentos para obtermos uma média aceitável. Isto é, o tempo mais baixo de resposta em ms.

Comece com valores 10 bytes para cima e 10 bytes para baixo até chegar em um valor aproximadamente bom. Provavelmente obtenha mais de um valor aceitavel dependendo do período do dia. Depois que chege em valores mais ou menos aceitáveis, comece a alterar o tamanho do pacote de 5 em 5 e depois de 1 em 1 até que você se sinta satisfeito com a velocidade obtida.

Esse valor de pacote não é o de MTU. Para obter o valor de MTU, você deve adicionar os 28 Bytes de overhead ao tamanho do pacote.

Uma vez obtido o valor do MTU, modifique no seu router

No meu caso, por exemplo, eu cheguei a um tamanho de pacote de 1453 Bytes que dá um MTU 1481. Com isso a média de ping ao alvo escolhido ficou em 62ms.

A seguir a minha tabela com alguns valores de testes para poderem visualizar como foi minha experiência:

Essa tabela não é exaustiva e obtive valores de resposta bem diferentes usando o mesmo tamanho de pacote. Nesses casos, acabei descartando o tamanho do pacote inteiro ficando com a ideia que “nesse tamanho oscila muito” para acalmar o pequeno monstro cientista.

Caso esteja usando Windows, o comando ping fica assim:

C:\> ping -f -l 1449 1.1.1.1

Um ambiente LAMP nos dá os elementos básicos para poder programar.

Como o alvo é programar sobre um servidor e não sobre ambiente Desktop, a instalação será sem GUI mas fique livre para faze-lo. Eu mesmo não tenho recursos tão abundantes assim para pôr interface gráfica em um servidor que vou controlar via ssh.

Escolhemos Ubuntu por ser o Linux mais simples de instalar e usar no dia a dia do desenvolvedor. Para produção costumamos colocar CentOS que é mais leve porém às vezes mais nojentinho de configurar.

Se você já tem uma VM com Ubuntu, pode pular para “Instalando LAMP” lá no final

1. Baixe a última versão estável do Ubuntu

   No momento de escrever este artigo, estava na 18.04.4 LTS (Sempre escolha as versões 04 que tem maior durabilidade garantida pela Cannonical)

   https://ubuntu.com/download/server

2. Crie uma máquina virtual

   a. Verifique se o local de armazenamento existe

   No meu caso, eu deixo todas as máquinas virtuais em uma pasta chamada ‘VirtualBoxes’ alocada na raiz do usuário; isto é: /home/esteban/VirtualBoxes. Então, e não tem uma pasta assim e quer cria-la faça como segue:

   $ mkdir ~/VirtualBoxes

   b. Crie sua máquina virtual usando o seguinte comando:

   $ VBoxManage createvm --name MeuLAMP --ostype Debian_64 --register --basefolder ~/VirtualBoxes/ 

   O VBoxManage vai responder alguma coisa assim:

   Virtual machine 'MeuLAMP' is created and registered.
   UUID: 3156aee4-8a2e-46dd-ae69-54533c78ff5f
   Settings file: '/Users/estebandortta/VirtualBoxes/MeuLAMP/MeuLAMP.vbox'

   c. Modifique ela para seus parâmetros mínimos.

   No caso 512MB de RAM, IOAPIC ligado e uma interface de rede em modo bridge (ponte). Repare que no meu caso, a placa de rede que vai ser usada como ponte é a chamada en1. Por isso que usei ela. No seu caso isso é diferente.

   Para obter uma lista das placas conectadas na sua máquina, pode usar o seguinte comando:

   $ ifconfig | grep "^[a-z0-9]*\:" | awk '{ print $1 }'

   Uma vez determinado o nome, pode proceder como segue:

   $ VBoxManage modifyvm MeuLAMP --ioapic on
   $ VBoxManage modifyvm MeuLAMP --memory 512 --vram 128
   $ VBoxManage modifyvm MeuLAMP --nic1 Bridged  --bridgeadapter1 en1

   Estes comandos, se bem executados, não devolvem coisa alguma na tela.

   d. Agora vamos adicionar um disco

   Ele será de tamanho típico (70GB) para este tipo de serviço mas pode ser menor ou maior. Depende de sua capacidade. Não recomendo abaixo de 40GB. Repare que meu download ficou em ~/Downloads/OS/Linux/ubuntu-18.04.3-live-server-amd64.iso então modifique conforme necessário.

   $ VBoxManage createhd --filename ~/VirtualBoxes/MeuLAMP/MeuLAMP_DISK.vdi --size 70000 --format VDI
   $ VBoxManage storagectl MeuLAMP --name "SATA Controller" --add sata --controller IntelAhci
   $ VBoxManage internalcommands sethduuid ~/VirtualBoxes/MeuLAMP/MeuLAMP_DISK.vdi
   $ VBoxManage storageattach MeuLAMP --storagectl "SATA Controller" --port 0 --device 0 --type hdd --medium  ~/VirtualBoxes/MeuLAMP/MeuLAMP_DISK.vdi
   $ VBoxManage storagectl MeuLAMP --name "IDE Controller" --add ide --controller PIIX4
   $ VBoxManage storageattach MeuLAMP --storagectl "IDE Controller" --port 1 --device 0 --type dvddrive --medium ~/Downloads/OS/Linux/ubuntu-18.04.3-live-server-amd64.iso
   $ VBoxManage modifyvm MeuLAMP --boot1 dvd --boot2 disk --boot3 none --boot4 none

   e. Configuramos acesso remoto

   O configuramos via vrde para podermos lidar com a tela dela no inicio e se alguma coisa acontece com ela durante o uso posterior. O porto (no caso 10004) é da sua escolha apenas use um que não exista.

   $ VBoxManage modifyvm MeuLAMP --vrde on
   $ VBoxManage modifyvm MeuLAMP --vrdemulticon on --vrdeport 10004

   f. Finalmente, inicie sua máquina para poder configura-la

   $ VBoxManage startvm MeuLAMP

   Lembre que posteriormente, podemos usar este comando para iniciar ela “sem-cabeça”. Ou seja, sem interface. Com isso vc poupará alguns recursos de CPU, GPU, RAM, etc. Usamos isso em produção.

   $ VBoxHeadless --startvm MeuLAMP

3. Coisas a serem feitas durante a instalação

   a. Escolha a partição que ocupa o disco inteiro e sem LVM.

   Em produção é o contrário. Ou seja, particionamos o disco diferente e usamos LVM que nos permite adicionar mais discos e não apenas mudar o tamanho.

   b. Configure seu usuário.

   Este é um usuário comum mas com direitos administrativos. Não esqueça a senha mas também não a anote no post-it. Chegado o caso anote ela na manga da camisa. A mulher vai se encarregar de fixar ela na sua memória.

   b. Não esqueça de instalar o SSH (Ele vai oferecer OpenSSH logo após particionar o disco)

   É importante ter seu SSH instalado pois é por meio dele que você vai acessar sua máquina. Sim, você não está sendo treinado para ser um gnutellinha da vida. Um acesso SSH te libera da exigência brutal de ter uma banda muito larga já que os comandos e seus retornos são textuais.

   c. Deixe o restante como está.

   Se precisar de proxy, indique no momento adequado.

   d. Aguarde até o fim.

   Ele vai demorar baixando as atualizações de segurança. Deixe rolar. Melhor agora do que depois.

   c. Caso a atualização der problemas escolha “Cancel Update and Reboot”

4. Coisas a serem feitas após a instalação

   Quando chegue ao final da instalação, o sistema instalado vai reiniciar. Observe que ele solicita para remover o disco de instalação. Como colocamos o disco de instalação como “CD-ROM”, o instalador já se encarregou de “ejetar” o mesmo. É só reiniciar (dando ENTER na VM) e boa.

   Assim que a máquina reinicie, ingresse nela usando seu usuário e senha cadastrado no primeiro passo.

   Na primeira vez, ele vai estar ainda configurando algumas coisas, então tenha paciência.

   A única coisa que interessa dessa entrada, é pegar o IP dela para poder acessa-la via SSH.

   Obtemos esse IP usando o comando ifconfig da seguinte maneira:

   esteban@meulamp:~$ ifconfig

   Ele nos devolverá alguma coisa assim:

   enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
          inet 192.168.0.152  netmask 255.255.255.0  broadcast 192.168.0.255
          inet6 fe80::a00:27ff:fe07:8f8b  prefixlen 64  scopeid 0x20<link>
          ether 08:00:27:07:8f:8b  txqueuelen 1000  (Ethernet)
          RX packets 855  bytes 642531 (642.5 KB)
          RX errors 0  dropped 2  overruns 0  frame 0
          TX packets 243  bytes 30082 (30.0 KB)
          TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
   
   lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
          inet 127.0.0.1  netmask 255.0.0.0
          inet6 ::1  prefixlen 128  scopeid 0x10<host>
          loop  txqueuelen 1000  (Local Loopback)
          RX packets 104  bytes 8136 (8.1 KB)
          RX errors 0  dropped 0  overruns 0  frame 0
          TX packets 104  bytes 8136 (8.1 KB)
          TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

   Mas desse trambolho todo só nos interessa o IP da primeira placa. A ‘lo’ é uma placa virtual que existe em todo linux para que a pilha TCP/IP funcione. (Lembre que X11 é um servidor que roda no seu próprio micro e sobre TCP/IP. Assim como ele há um monte de programas que esperam que vc tenha uma pilha TCP/IP ativa. Por isso ela está embutida).

   Então, simplificamos para o seguinte comando para obtermos o IP da máquina:

   esteban@meulamp:~$ ifconfig | grep -w inet | grep -vw 127 | awk '{ print $2 }'

   Com este comando mais simples, direto, eficiente, bonito, fácil de lembrar, obtemos apenas o IP da máquina. No meu caso a saída se resume a isto aqui:

   192.168.0.152

   Agora, devemos reconhecer que é um saco ter que abrir a máquina virtual para saber qual IP que ele pegou. Por outro lado, precisamos de essa informação para trabalhar. Comigo acontece de que geralmente não posso deixar ela com IP fixo já que uso ela em diferentes redes.

   Uma forma de solucionar isso, é que a própria máquina mostre o IP que pegou na tela antes do login. Desta forma, apenas abrir a tela da VM (Lebre que vamos usar sem tela) já nos mostra esse IP. (Eu não sei vocês, mas eu esqueço dos IPs fixos tb, então eu coloco em tudo quanto é máquina)

   Para conseguir isso, vamos modificar o arquivo /etc/issue que é o arquivo que é mostrado no fim do processo de inicialização e logo antes do login.

   Como minha placa chama-se enp0s3 (Detesto esses nomes novos, gostava de quando eram eth0 por exemplo) o meu arquivo /etc/issue fica assim:

   Ubuntu 18.04.4 LTS n l
   enp0s3: 4{enp0s3}
   ------------------------------------------

   Ao reiniciar a máquina virtual, lá estará a informação que preciso para poder trabalhar.

5. Configurando seu acesso via SSH

   Usar uma máquina virtual via tela é pedir para sofrer. Ela é mais lenta, não tem jeito.

   Mesmo se instalou a GUI (como é o caso de Windows Desktop por exemplo que não tem como instalar sem interface gráfica) o melhor é o acesso remoto. Claro, há exeções, mas a regra é essa.

   Bem, antes de se apaixonar pelo ssh, você tem que ser triducidado por ele.

   Se seu ambiente é Windows, um cliente ssh potável é o PuTTY (https://putty.org) mas o que eu mais gosto é Cygwin (https://www.cygwin.com). Agora, com isso de que o Windows10 já vem com bash (e Ubuntu) embarcado, imagino que o melhor seja usar a opção que vem embarcada.

   Eu vou supor que está usando Linux, Cygwin ou bash embarcado.

   a. Acesse sua máquina virtual desde a linha de comandos da sua máquina. No meu caso fica assim:

   $ ssh esteban@192.168.0.152

   Por ser a primeira vez, o meu bash responde assim:

   The authenticity of host '192.168.0.152 (192.168.0.152)' can't be established.
   ECDSA key fingerprint is SHA256:poNetFdUSSEYn8tH2Mu7Vy7NLdq25lFaCJ449rt2bjw.
   Are you sure you want to continue connecting (yes/no)?

   Ao que eu respondo que sim em inglês fluente. Ou seja “yes” e não apenas “y”

   Com isso o servidor fica registrado na lista de alvos conhecidos pelo ssh

   Logo apósi digito a senha que registrei na hora da instalação e pronto, estou nele.

   Mas vamos sair, porque -não sei vocês- mas eu detesto ter que lembrar de senhas e tal.

   Para sair, digitamos exit ou usamos ctrl-d que dá na mesma.

   SÓ CONTINUE SE VOLTOU NA SUA MÁQUINA MÃE

   b. Tem ou não um par de chaves na sua máquina mãe?

   Pode acontecer que você não tenha um par de chaves criadas. Para verificar se tem, use o seguinte comando:

   $ ls ~/.ssh/*

   Se ele mostra dois arquivos id_rsa e id_rsa.pub, você já tem as chaves criadas e não há de que se preocupar (a não ser, claro que tenha criado as chaves com senha e as tenha esquecido)

   Se ele mostrar alguma coisa parecida com a imagem abaixo é porque você não tem o par de chaves:

   ls: cannot access '/home/esteban/.ssh/': No such file or directory

   Caso, então, tenha que criar esse par de chaves, o fazemos usando o seguinte comando:

   $ ssh-keygen

   Deixe que o demônio do usuário Windows entre em você e dé ENTER até o final. Dessa forma criará um par de chaves que não precisam senha para serem usadas. (Em produção você coloca senha nelas)

   A saída fica mais ou menos assim:

   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/esteban/.ssh/id_rsa): 
   Created directory '/home/esteban/.ssh'.
   Enter passphrase (empty for no passphrase): 
   Enter same passphrase again: 
   Your identification has been saved in /home/esteban/.ssh/id_rsa.
   Your public key has been saved in /home/esteban/.ssh/id_rsa.pub.
   The key fingerprint is:
   SHA256:1h2/DAEBwxLLwiKYFSyY3FSiFtWRAvO1t8snCgGxCAY esteban@meulamp
   The key's randomart image is:
   +---[RSA 2048]----+
   |EOB=o++oo.o.     |
   |O+O+o+o... .     |
   |=*..+.oo    o    |
   |.... .. .. . +   |
   |   .   .S . o .  |
   |    . ...    o . |
   |   .   + .    o  |
   |    . . o        |
   |     .           |
   +----[SHA256]-----+

   c. Copie sua chave pública para a VM

   Para poder facilitar o acesso via SSH, você agora vai copiar sua chave pública para a máquina que criou. No meu caso fica assim:

   $ ssh-copy-id esteban@192.168.0.152

   E ele produzirá uma saída semelhante a esta

   /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/estebandortta/.ssh/id_rsa.pub"
   /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
   /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
   esteban@192.168.0.152's password: 
   
   Number of key(s) added:        1
   
   Now try logging into the machine, with:   "ssh 'esteban@192.168.0.152'"
   and check to make sure that only the key(s) you wanted were added.

   Eu digitei a senha da VM quando me pediu. Se você criou seu par de chaves com senha, vai pedir essa senha tb. Ai vc vai lembrar o porque que eu disse para colocar sem senha.

   Bem, a partir deste momento entrar na sua máquina virtual via ssh será tão simples como fazer

   $ ssh esteban@192.168.0.152

   E ele deve ir sem pedir senha (a não ser que o par de chaves…bla bla bla)

6. Instalando o LAMP

   Entraremos na virtual. Use o comando similar ao seguinte

   $ ssh esteban@192.168.0.152

   a. Instale o básico

   O que é o básico no LAMP?

   Bom, sendo que está no Linux, só falta AMP (Apache, MySQL e PHP)

   Existem pacotes prontos que faremos bem em evitar pois buscamos aprender o que é – de fato – importante.

   Primeiro atualizaremos a base instalada (isso pode levar um tempinho a primeira vez)

   esteban@meulamp:~$ sudo apt-get update -y

   Ele vai pedir a senha de usuário para poder fazer sudo

   Em lugar do MySQL vamos instalar o MariaDB. (MariaDB é um fork de MySQL que o criador de MySQL fez quando abandonou a Oracle. O criador do MySQL tinha ido para a Oracle contando com que a Oracle ia manter seus tentáculos longe e manter o MySQL aberto. Como isso não aconteceu, ele foi embora. Perdeu o nome MySQL mas o software é o mesmo… e manteve a dignidade que – nos tempos que correm – digamos que é importante)

   esteban@meulamp:~$ sudo apt-get install apache2 php mariadb-server mariadb-client php-mysql -y
   

   Dependendo de sua distribuição, pode ser que o apache não esteja configurado para iniciar junto com o sistema. Habilite o apache e inicie ele com estes dois comandos:
   
   esteban@meulamp:~$ sudo systemctl enable apache2
   esteban@meulamp:~$ sudo systemctl start apache2
   

   Dessa forma, quando você reiniciar sua máquina, o apache estará funcionando mas para continuar agora, ele também estará funcionando.

   b.Configure o acesso ao banco de dados

   Uma vez instalado, é bom configurar o banco de dados. Basicamente precisamos que ele seja seguro o suficiente como para trabalhar, mas tb que não encha o saco com muitas exigências.

   esteban@meulamp:~$ sudo mysql_secure_installation

   Assim que ele é instalado, o root está sem senha. Então quando perguntado, crie uma senha para root.

   • Depois remova os usuários anónimos
   • Permita acesso remoto pelo root (em produção é o contrário)
   • Remova a base de testes
   • Recarregue sua tabela de privilegios

   Pronto, seu MariaDB está configurado. Agora reinicie ele:

   esteban@meulamp:~$ sudo systemctl restart mariadb

   E teste o seu acesso local:

   esteban@meulamp:~$ mysql -u root -p

   Se tudo deu certo, você vai ter uma tela parecida com esta:

   Welcome to the MariaDB monitor.  Commands end with ; or g.
   Your MariaDB connection id is 35
   Server version: 10.1.44-MariaDB-0ubuntu0.18.04.1 Ubuntu 18.04
   
   Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
   
   Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.
   
   MariaDB [(none)]> Bye

   Mas, pode ser que sua combinação de Ubuntu/MariaDB esteja meio louca. Geralmente o problema está com o protocolo de autenticação. Nesse caso ele vai mostrar uma saída como a seguinte:

   esteban@meulamp:~$ mysql -u root -p
   Enter password: 
   ERROR 1698 (28000): Access denied for user 'root'@'localhost'

   Se tiver esse problema você pode proceder da seguinte forma primeiro para confirmar o erro e depois para corregi-lo:

   esteban@meulamp:~$ sudo mysql
   MariaDB [(none)]> use mysql;
   MariaDB [mysql]> select user, plugin from user;

   Ele vai mostrar para você uma saida com esta que serve para identificar se esse é seu problema:

   +------+-------------+
   | user | plugin      |
   +------+-------------+
   | root | unix_socket |
   +------+-------------+
   1 row in set (0.00 sec)

   Corrigimos isso assim:

   MariaDB [mysql]> update user set plugin='mysql_native_password' where user='root';
   MariaDB [mysql]> flush privileges;
   MariaDB [mysql]> exit

   Agora, desde seu usuário comum, você deve ser capaz de entrar no mysql localmente

   esteban@meulamp:~$ mysql -u root -p

   Feito isso, volte na sua máquina mãe e tente o acesso ao servidor de banco de dados

   esteban@meulamp:~$ exit
   logout
   Connection to 192.168.0.152 closed.
   $ mysql -u root -p -h 192.168.0.152
   Enter password: 
   ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.0.152' (61)

   No meu caso, esse é o erro que dá. Isso está dizendo que o servidor não está ouvindo no IP indicado.

   Assim que voltamos à VM e corrigimos a configuração do MariaDB

   $ ssh esteban@192.168.0.152
   esteban@meulamp:~$ sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

   Procure pela linha que diz

   bind-address = 127.0.0.1

   e substitua pelo seguinte

   bind-address = *

   Agora reinicie o servidor

   esteban@meulamp:~$ sudo systemctl restart mariadb

   Volte à sua maquina mãe (gosto de chama-la assim… parece com ‘nave mãe’ ao final das contas somos como que alienigenas invadindo as VM da vida)

   esteban@meulamp:~$ logout
   Connection to 192.168.0.152 closed.
   [estebandortta@Estebans-MacBook-Pro ~] mysql -u root -p -h 192.168.0.152
   Enter password: 
   ERROR 1130 (HY000): Host '192.168.0.142' is not allowed to connect to this MariaDB server

   Repare que o erro mudou. Agora nos está dizendo que o nosso host (no caso 192.168.0.142 que é o IP da minha máquina mãe) está impedido de acessar.

   Voltamos à VM e – usando nosso direito de acesso ao banco lá dentro – corrigimos isso assim:

   $ ssh esteban@192.168.0.152
   esteban@meulamp:~$ mysql -u root -p

   E uma vez dentro do mysql fazemos assim:

   MariaDB [(none)]> CREATE USER 'root'@'192.168.%' IDENTIFIED BY 'tr3co';
   Query OK, 0 rows affected (0.00 sec)
   
   MariaDB [(none)]> GRANT ALL PRIVILEGES ON *.* TO 'root'@'192.168.%';
   Query OK, 0 rows affected (0.00 sec)
   
   MariaDB [(none)]> FLUSH PRIVILEGES;
   Query OK, 0 rows affected (0.00 sec)
   
   MariaDB [(none)]> exit

   Com isso criamos um novo usuário também chamado root mas com a senha tr3co que pode acessar este servidor desde qualquer micro da rede 192.168.x.x (Repare o uso do coringa ‘%’)

   Voltamos à máquina mãe e testamos o acesso.

   esteban@meulamp:~$ exit
   logout
   Connection to 192.168.0.152 closed.
   
   $ mysql -u root -ps3nha -h 192.168.0.152
   Welcome to the MariaDB monitor.  Commands end with ; or g.
   Your MariaDB connection id is 7
   Server version: 10.1.44-MariaDB-0ubuntu0.18.04.1 Ubuntu 18.04
   
   Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
   
   Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.
   
   MariaDB [(none)]>

   c. Alterando as configurações do usuário

   É necessário que o usuário comum possa escrever na pasta /var/www/html

   A forma mais fácil disso é fazer um sudo chmod -fR 0777 /var/www/html que é o análogo a colocar a saida do vaso direto no ralo do chuveiro. Funciona.

   O certo mesmo é fazer com que o usuário comum (que tb é administrativo) consiga escrever na pasta /var/www/html

   A primeira coisa a fazer é verificar em que grupo o apache2 trabalha. O seguinte comando faz isso:

   esteban@meulamp:~$ ps aux | grep apache | awk '{ print $1 }' | grep -v "root|esteban" | uniq

   No meu caso ele me devolve www-data. Para eu, usuário comum, poder escrever nas pastas desse grupo, devo pertencer ao mesmo.

   Você pode verificar os direitos que seu usuário comum tem da seguinte forma:

   esteban@meulamp:~$ id esteban
   uid=1000(esteban) gid=1000(esteban) groups=1000(esteban),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lxd)

   Como você pode observar, o meu usuário comum não pertence ao grupo www-data. Adicionamos ele ao grupo com o seguinte comando:

   esteban@meulamp:~$ sudo usermod -a -G www-data esteban

   E podemos verificar com o comando id que de fato ele foi adicionado:

   esteban@meulamp:~$ id esteban
   uid=1000(esteban) gid=1000(esteban) groups=1000(esteban),4(adm),24(cdrom),27(sudo),30(dip),33(www-data),46(plugdev),108(lxd)

   Só que se você for ver, ainda não pode criar arquivos na pasta /var/www/html:

   esteban@meulamp:~$ touch /var/www/html/info.php 
   touch: cannot touch '/var/www/html/info.php': Permission denied

   A forma mais limpa de resolver isto é se apropriando da pasta /var/www/html:

   esteban@meulamp:~$ sudo chown esteban /var/www/html
   esteban@meulamp:~$ sudo chgrp www-data /var/www/html

   Uma vez feito isso, você pode criar o arquivo /var/www/html/info.php com o seguinte conteúdo para comprovar o correto funcionamento e instalação de tudo:

   <?php
    phpinfo();
   ?>

   Proceda a testar a sua configuração solicitando ao apache que processe esse arquivo e mostre a saida na tela. Ou seja, navegue.

   http://192.168.0.152/info.php

   Se tudo ocorreu bem, tem que aparecer uma lista com as configurações atuais do apache, o php e o mysql.

7. Criando o primeiro programa

   Bom, se tudo deu certo, é hora de criarmos o primeiro programa.

   Mas para que o teste seja completo, vamos criar primeiro um banco de dados

   esteban@meulamp:~$ mysql -u root -p

   Welcome to the MariaDB monitor.  Commands end with ; or g.
   Your MariaDB connection id is 7
   Server version: 10.1.44-MariaDB-0ubuntu0.18.04.1 Ubuntu 18.04
   
   Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
   
   Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.
   
   MariaDB [(none)]> create database meuTeste;
   Query OK, 1 row affected (0.00 sec)
   
   MariaDB [(none)]> show databases;
   +--------------------+
   | Database           |
   +--------------------+
   | information_schema |
   | meuTeste           |
   | mysql              |
   | performance_schema |
   +--------------------+
   4 rows in set (0.00 sec)

   Uma vez criado o banco meuTeste (que por enquanto não tem tabelas) vamos escrever nosso primeiro programa.

   esteban@meulamp:~$ nano /var/www/html/testar-conexao.php

   Digitando o seguinte lá dentro:

   <?php
    $con = mysqli_connect("localhost:3306", "root", "czyhnp");
    if ($con) {
      $db = mysqli_select_db("meuTeste")
      echo "Ok";
    } else {
      echo "Impossível conectar";
    }

   Confirmamos que tudo esteja bem com ele usando o seguinte comando:

   esteban@meulamp:~$ php -l /var/www/html/testar-conexao.php 

   Corrigimos os erros (se você estava copiando-colando tem um erro) usando o nano e o testamos pedindo para o apache2 usar seu pre-processador, passar para o php, este realizar o serviço, devolver seu resultado numa pipe textual, e o apache2 devolver para a conexão para que o navegador renderize isso perante nós. Simplificando: navegue

   http://192.168.0.152/testar-conexao.php

8. Finalmente, reinicie

   Com isso tudo pronto, reinice seu servidor e teste novamente para ver que tudo esteja ok

   esteban@meulamp:~$ sudo reboot

   Se os passos foram seguidos, tudo tem que continuar funcionando ok.

   Lembre apenas que da próxima vez, vc pode levantar sua maquina virtual apenas usando a opção HeadLess

   $ VBoxHeadless --startvm MeuLAMP

Às vezes preciso acessa-las e ver o boot delas ou corrigir uma placa de rede virtual ou coisa assim mas a interface gráfica fica pesada por estar longe ou sobre uma internet pobre.

O melhor nesses casos, é fazer um ssh no hospedeiro e dai entrar pelo console na máquina virtual, mas se justo a rede virtual não funciona, você precisa de uma outra solução. No caso, poder acessar usando o virsh.

Se sua VM é Centos7

Edite o arquivo /etc/default/grub

No meu caso, tenho uma linha assim:

GRUB_CMDLINE_LINUX="rd.lvm.lv=centos/swap crashkernel=auto  rd.lvm.lv=centos/root vconsole.font=latarcyrheb-sun16 vconsole.keymap=br-abnt2 rhgb quiet"

Como quero permitir acesso via o porto serial (é assim que o virsh e outros se comunicam com a virtual) habilito ele e retiro o quiet ficando assim:

GRUB_CMDLINE_LINUX="rd.lvm.lv=centos/swap crashkernel=auto  rd.lvm.lv=centos/root vconsole.font=latarcyrheb-sun16 vconsole.keymap=br-abnt2 rhgb console=ttyS0"

Depois escrevo essa config no grub com o seguinte comando

grub2-mkconfig -o /boot/grub2/grub.cfg

A saída fica mais ou menos assim:

Na máquina hospedeira, listo as virtuais com o comando virsh list que produz uma saída como a seguinte

Com isso obtenho uma lista das máquinas e posso acessar (no caso o último listado) com o seguinte comando:

virsh console SignalServer

Ele irá pedir usuário e senha como se estivesse por uma tty normal

Um lance interessante é reiniciar a máquina e poder acompanhar o boot assim:

$ virsh reboot SignalServer
$ virsh console SignalServer

Caso sua VM seja Ubuntu, faça assim

$ sudo systemctl enable serial-getty@ttyS0.service
$ sudo systemctl start serial-getty@ttyS0.service

No escritório temos um servidor usando KVM e outro com OpenVZ

Nos clientes, estamos usando também estruturas mistas e muitas das máquinas virtuais são CentOS 6 ou 7

Com este último lance de que não sabemos mais em que hora vivemos (vai ver é como disse o Gadot é fake news e a gente não sabe), enfrentamos o problema de que as VM CentOS 7 foram e voltaram mas as que estavam com 6 nem foram nem voltaram ou quando foi, atrasou em lugar de adiantar.

Evidentemente que fomos de cara ver o /etc/localtime. E… Oh beleza, estavam ok. Todos eles dizendo que estavam em America/Sao_Paulo.

Parece que o problema estava no hospedeiro (a máquina física) e não nas virtuais.

Então procedemos da seguinte forma nas máquinas físicas

# removemos a configuração atual
rm /etc/localtime -f
# colocamos ele em UTC (assim não muda)
ln -s /usr/share/zoneinfo/UTC  /etc/localtime
# corrigimos o horário
date +%T -s "13:04:30"
# sincronizamos o relógio físico
hwclock --systohc

E desta forma nas virtuais

rm /etc/localtime -f 
ln -s /usr/share/zoneinfo/UTC  /etc/localtime 

Pronto, agora, quando os senhores decidirem qual é o horário certo, entraremos apenas na física e modificaremos ou o relógio na unha ou colocaremos o timezone correto. Ou seja, depois que o fuso pare de ser uma zona, indicaremos em qual zona do tempo moramos.

Estes dias me veio o problema de migrar uma máquina que estava em uma HyperV para o KVM.

O problema se resume ao seguinte lance: Transformar a imagem a um formato que o KVM entenda. Ou seja, de vhdx para qcow2 (ou qualquer um outro do seu gosto)

Os passos seguidos foram os seguintes:

1. Parar a máquina original (a que está rodando na HyperV)
2. Copiar os arquivos ao servidor em que o KVM está (se é que está em um diferente) usando WinSCP
3. Transformar a imagem
4. Integrar a imagem usando o virt-manager

Cabe depois corrigir a configuração do hardware caso necessário. Mas isso não é assunto deste deste artigo.

O bojo então é a migração do formato do arquivo. Basta apenas indicar o nome do XML modificado (arquvo .vhdx) e usar o qemu-img como segue:

$ qemu-img check -r all caramba.vhdx && \
$ qemu-img convert -O qcow2 cramba.vhdx cramba.qcow2

Uma das exigências desse imbróglio todo é que rode sobre SSL.

Por razões de testes de compatibilidade, mantemos CentOS 6.9 em alguns servidores ao passo que outros já são 7 e pelas mesmas razões mantemos alguns nós em PHP5.5 ao passo que outros já estão em PHP7.2

O problema é que com a atualização do TLS e a exigência ipso facto de ir todo mundo para https – em decorrência do uso massivo do Chrome (parece como se fosse o único navegador que existisse) – nos vemos obrigados a atualizar estes servidores que – de outra forma – repousariam em paz fazendo suas tarefas de forma impertérrita e ininterrupta.

TL;DR

Bem, introduções ordinárias à parte, vamos ao que interessa.

Fiz dois scripts que quero compartilhar; um para atualizar o php e outro o curl.

Para os marinheiros de primeira viagem, CentOS 6.9 chega só até PHP5.3

Para atualizar PHP

#!/bin/bash
# (C) 2018 Esteban D.Dortta

if [[ $EUID -ne 0 ]]; then
   echo "This script must be run as root"
   exit 1
fi

yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
yum install -y http://rpms.remirepo.net/enterprise/remi-release-6.rpm
yum install -y yum-utils
yum-config-manager --enable remi-php72
yum -y install php php-common php-mysqlnd php-mysqli php-pdo php-gd php-mbstring php-pear

apachectl restart

Para atualizar Curl

#!/bin/bash
# (C) 2018 Esteban D.Dortta

if [[ $EUID -ne 0 ]]; then
   echo "This script must be run as root"
   exit 1
fi

cat > /etc/yum.repos.d/city-fan.repo << EOF
[CityFan]
name=City Fan Repo
baseurl=http://www.city-fan.org/ftp/contrib/yum-repo/rhel\$releasever/\$basearch/
enabled=1
gpgcheck=0
EOF

yum clean all
yum install -y curl

apachectl restart

Os efeitos podem ser apreciados (hoje pelo menos) em https://teste.NossoConsultorio.com.br

De nada

Bjs do véio

Bom, o lance é que use OPNSense em algumas redes e preciso bloquear – de forma centralizada – o tráfego para determinados sites, em especial os de propaganda e mineração.

Sem explicar os pormenores, todo santo dia meu servidor cria uma lista atualizada com um arquivo em formato hosts que pode ser injetado no /etc/hosts do OPNSense (ou qualquer outro BSD/Linux, ou no seu micro Windows, enfim, onde lhe for mais útil) Essa lista pode ser obtida aqui: http://w2.inovacaosistemas.com.br/network-tools/blocklist.hosts e não posso me responsabilizar pelo seu conteúdo já que ele na realidade mama de varios serviços que me são úteis mas não tenho como garantir que a lista seja exaustiva, digna de confiança ou coisa assim. Todavia, o que lhe deve interessar é que uso ela há alguns anos e durmo tranquilo.

Bem, mas como fazer com que essa lista vá para o OPNSense?

1. Modifiquei meu /etc/hosts para que tenha uma marca de fim de arquivo. Eu inventei essa marca assim: ###END. Isso porque no /etc/hosts o símbolo ‘#’ é um comentário. Acrescentei essa marca depois dos hosts que são da rede interna.
2. Criei um script.
3. Coloquei ele para rodar cedo pela manhã

O script ficou assim:

curl http://w2.inovacaosistemas.com.br/network-tools/blocklist.hosts -o /tmp/anti-ads.hosts &&
grep -B10000 \#\#\# /etc/hosts > /tmp/hosts.orig &&
cat /tmp/hosts.orig > /etc/hosts &&
cat /tmp/anti-ads.hosts >> /etc/hosts &&
service -R dnsmasq

E a entrada no crontab ficou assim:

45	6	*	*	*	(/home/esteban/puxarListaAntiAds.sh) > /dev/null

(Sim, ele roda como root mas reside em minha pasta local)

Espero que ajude