…….
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