De forma a criar um certificado auto-assinado para um virtualhost Apache deve optar-se pela utilização do OpenSSL. Uma vez que esteja assegurado que o OpenSSL está instalado deve correr-se o seguinte comando para gerar o certificado e chave privada:
# openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout mysitename.key -out mysitename.crt
Quando o servidor apache fica atrás de um proxy ou loadbalancer o IP do cliente é substituido pelo IP do balanceador/proxy. Para ultrapassar esta limitação um cabeçalho/header costumizado foi desenvolvido pela equipe de desenvolvimento do squid, o X-Forwarded-For header.
A configuração default de logging do apache tem o seguinte formato:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
CustomLog log/acces_log combined
São necessárias varias alterações à configuração por defeito de forma a que o X-Forwarded-For e o ip real do visitante seja logado. As alterações são as seguintes:
LogFormat “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\”” combined
LogFormat “%{X-Forwarded-For}i %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\”” proxy
SetEnvIf X-Forwarded-For “^.*\..*\..*\..*” forwarded
CustomLog “logs/access_log” combined env=!forwarded
CustomLog “logs/access_log” proxy env=forwarded
Estas alterações resultam no log do endereço IP de cada pedido.
Recentemente tive a necessidade de configurar um servidor aplicacional Tomcat/Liferay, para tal depois de muitas voltas conclui que para se conseguir ter o servidor atrás de um balaceador que faz o offload de SSL. Recorrer ao mod_proxy do apache não satisfaz os resultados pretendidos uma vez que o post do formulário de login segue sempre em http, impedindo assim os utilizadores de fazer login.
Consegui um comportamento correto com recurso ao mod_jk com as seguintes configurações:
Ficheiro workers.properties (/etc/httpd/conf.d/):
#Name of the load balancer workers
worker.list=loadbalancer
#Worker configuration for liferay-node-01
#AJP Connector port of node-01 on liferay-node-01 server
worker.node-01.port=8009
worker.node-01.host={IP do servidor onde está o Liferay}
worker.node-01.type=ajp13
worker.node-01.lbfactor=1
#load balancer configuration properties
worker.loadbalancer.type=lb
#list of worker nodes that are part of the cluster
worker.loadbalancer.balance_workers=node-01
worker.loadbalancer.sticky_session=1
Ficheiro mod_jk.conf em (/etc/httpd/conf.d/):
LoadModule jk_module modules/mod_jk-1.2.28-httpd-2.2.X.so
JkWorkersFile /etc/httpd/conf.d/workers.properties
JkShmFile /var/log/httpd/mod_jk.shm
JkLogFile /var/log/httpd/mod_jk.log
JkLogLevel info
JkLogStampFormat “[%a %b %d %H:%M:%S %Y] “
No ficheiro server.xml do servidor Tomcat foi necessário mudar a tag:
<Engine name=”Catalina” defaultHost=”localhost”>
Para:
<Engine name=”Catalina” defaultHost=”localhost” jvmRoute=”node-01″>
A configuração do Virtual host apache foi a seguinte (virtualhost.conf em /etc/httpd/conf.d/):
<VirtualHost *:443>
ServerName dominio.autilizar.com
ServerAdmin it@dominio.autilizar.com
ErrorLog “/var/log/httpd/error_log”
TransferLog “/var/log/httpd/access_log”
SSLEngine on
SSLCertificateFile /caminho/para/o/certificado/dominio.autilizar.com.crt
SSLCertificateKeyFile /caminho/para/a/chave/privada/dominio.autilizar.com.crt
JkMount /* loadbalancer
</VirtualHost>
Já havia tido a necessidade de utilizar o mod_jk com o tomcat anteriormente, mas devido a situações particulares em que os frontends Apache balanceavam pedidos para multiplos servidores aplicacionais. A prévia utilização deste método para situações especificas de balanceamento de aplicações facilitou a resolução deste desafio com que me deparei.
O comando screen é uma ferramenta muito pouco utilizada mas de grande utilidade uma vez que permite correr processos em background independentes da sessão do utilizador. Seguem alguns atalhos de teclas utilizados no screen.
| Combinação | Acção |
| Ctrl+a c | nova janela |
| Ctrl+a n | próxima janela |
| Ctrl+a p | janela anterior |
| Ctrl+a “ | escolher janela da lista |
| Ctrl+a Ctrl+a | ultima janela ativa |
| Ctrl+a S | dividir terminal horizontalmente em regiões |
| Ctrl+a | | dividir terminal verticalmente em regiões |
| Ctrl+a :resize | redimensionar região |
| Ctrl+a :fit | adaptar a resolução do monitor ao tamanho do novo terminal |
| Ctrl+a :remove | remover região |
| Ctrl+a tab | mover para a próxima região |
| Ctrl+a d | desanexar o screen do terminal |
| Ctrl+a A | definir titulo da janela |
| Ctrl+a x | bloquear sessão |
| Ctrl+a [ | entrar no modo de copia |
| Ctrl+a ] | buffer de paste |
| Ctrl+a > | escrever o paste buffer para fichero |
| Ctrl+a < | ler o paste buffer do ficheiro |
| Ctrl+a ? | ver key bindings/nomes dos comandos |
| Ctrl+a : | screen command prompt |
Por vezes existe a necessidade de configurar o servidor aplicacional Liferay/Tomcat para aceitar e responder corretamente pedidos https sem que exista configuração de SSL no Tomcat. Esta situação acontece quando o servidor aplicacional está atrás de um balanceador ou proxy, podendo este proxy ser por exemplo Nginx ou Apache.
De forma a que o servidor aplicacional responda devidamente aos pedidos devem adicionar-se as seguintes propriedades ao ficheiro portal-ext.properties
web.server.https.port=443
web.server.protocol=https
O Reverse “SSH Tunneling” é uma técnica que permite aceder a sistemas que se encontram bloqueados, por exemplo com uma firewall.
Por vezes é necessário aceder a partir de um sistema sem acesso à internet aos repositórios da distribuição ou a outros recursos expostos na internet.
No nosso exemplo este acesso faz-se com o privoxy, sendo que a maquina que vai servir de proxy é um servidor debian.
Para instalar o privoxy deve executar-se o seguinte comando:
$ sudo apt-get install privoxy
Uma vez instalado deve fazer-se start ao serviço com o seguinte comando:
$ sudo systemctl start privoxy
Para configurar o serviço para arrancar durante o boot executa-se o seguinte:
$ sudo systemctl enable privoxy
As configurações por defeito são suficientes para o nosso objetivo, deverá ter-se em conta que este servidor que irá servir de proxy tem de ter acesso à internet.
Uma vez instalado e feito o arranque do privoxy procedemos à criação do reverse tunel, com recurso ao seguinte comando:
$ ssh -R 8118:localhost:8118 username@REMOTEIP
Neste momento o servidor remoto que não tinha acesso à internet já tem neste momento ligação ao nosso servidor privoxy.
Para concluirmos a operação devemos configurar o proxy no servidor remoto, para tal executam-se os seguintes comandos no servidor remoto:
# export http_proxy="http://localhost:8118"
# export https_proxy="https://localhost:8118"
# export ftp_proxy="ftp://localhost:8118"
Converter imagens qcow para vmdk é um processo de extrema simplicidade. Dependendo do objetivo pode usar-se um dos seguintes comandos:
# qemu-img convert -f qcow2 file.qcow2 -O vmdk file.vmdk
# qemu-img convert -f qed file.qed -O vmdk file.vmdk
# qemu-img convert -f qcow2 file.qcow2 -O qed file.qed
HTTP Strict Transport Security (abreviado HSTS) é uma funcionalidade de de segurança que permite a um website informar o browser que deve comunicar utilizando apenas HTTPS, em vez de utilizar HTTP
Configuração para Apache
Deve adicionar-se ao virtualhost configurado para responder por HTTPS o seguinte:
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
O Apache deve ser reiniciado depois de ser efetuada a alteração à configuração
Configuração para Lighttpd
Para configuração no Lighttpd deve adicionar-se ao ficheiro /etc/lighttpd/lighttpd.conf a seguinte configuração:
server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
setenv.add-response-header = ( "Strict-Transport-Security" => "max-age=63072000; includeSubdomains; preload")
}
Deve reiniciar-se o Lighttpd para que as alterações sejam aplicadas.
Configuração para NGINX
A configuração para NGINX é ainda mais sucinta, deve ser adicionado ao bloco SERVER da configuração HTTPS a seguinte linha:
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
Por vezes a configuração de SSL requer que os certificados SSL estejam em determinados formatos, por exemplo um servidor Windows importa e exporta ficheiros .pfx enquanto um servidor apache utiliza ficheiros individuais em formato PEM.
Os comandos abaixo permitem converter certificados SSL em diferentes formatos:
OpenSSL Convert PEM
Convert PEM to DER
# openssl x509 -outform der -in certificate.pem -out certificate.der
Convert PEM to P7B
# openssl crl2pkcs7 -nocrl -certfile certificate.cer -out certificate.p7b -certfile CACert.cer
Convert PEM to PFX
# openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt
OpenSSL Convert DER
Convert DER to PEM
# openssl x509 -inform der -in certificate.cer -out certificate.pem
OpenSSL Convert P7B
Convert P7B to PEM
# openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer
Convert P7B to PFX
# openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer
# openssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -certfile CACert.cer
OpenSSL Convert PFX
Convert PFX to PEM
# openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes
No mundo do IT a automatização e agilização de tarefas é são factores determinantes para o sucesso das organizações. Face à necessidade constante de deploy de novas maquinas virtuais com características semelhantes tornou-se frequente fazer clones de máquinas, desta forma seguem algumas guidelines e comandos para criação de um clone de Red Hat Linux para ser usado como template.
# touch /.unconfigured
# rm -rf /etc/ssh/ssh_host_*
# ifdown eth0
Com recurso a um editor de texto modificar o ficheiro /etc/sysconfig/network-scripts/ifcfg-eth0 e remover a entrada HWADDR.
# ifup eth0
Utilizando um editor de texto remover a entrada para o interface de rede eth0 no ficheiro /etc/udev/rules.d/70-persistent-net.rules
# poweroff
Desta forma temos um template criado e pronto a utilizar para aprovisionamento de novas máquinas virtuais.
