…….
Uma das vulnerabilidades existentes no liferay que permite enumerar utilizadores existentes na plataforma encontra-se no caminho dos documentos do Liferay, para corrigir esta vulnerabilidade deve seguir-se o seguinte procedimento:
Editar o ficheiro urlrewrite.xml (…\tomcat-7.0.40\webapps\ROOT\WEB-INF
Inserir a seguinte regra:
<rule><from>^/documents/([A-Za-z]+)</from><to type=”permanent-redirect”>/</to></rule>
Na passagem do ano deparei-me com uma situação no mínimo curiosa, devido ao facto do ultimo minuto do ano ter tido 1 segundo a mais (leap second) várias JVM’s ficaram com uma utilização excessiva de CPU, afetando assim a performance de vários servidores. Depois de várias pesquisas, verifiquei que as recomendações de multiplos fabricantes era: efetuar reboot aos servidores em questão. Por se tratarem de ambientes produtivos, não considerei boa opção reiniciar as máquinas e descobri um “workaround”. Aparentemente forçar um reset à data é suficiente para corrigir o problema.
O comando a utilizar é o seguinte:
date -s "`date`"
#!/bin/sh
# description: Solr Server
# Solr Server service start, stop, restart
#solr start -d /opt/solr/core
SOLR_DIR="/opt/solr"
SOLR_CORE="/opt/solr/core"
SOLR_PORT="8983"
case $1 in
start)
echo "Starting Solr..."
$SOLR_DIR/bin/solr start -d $SOLR_CORE
sleep 1
lsof -i :8983
;;
stop)
echo "Stopping Solr..."
$SOLR_DIR/bin/solr stop -d $SOLR_CORE -p $SOLR_PORT
;;
restart)
$0 stop
sleep 2
$0 start
;;
*)
echo "Usage: $0 [start|stop|restart]"
exit 1
;;
esac
exit 0
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.
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