JasperReports a plugin ElasticJasperServer

V práci jsem seznamoval s produkty Jasper Reports od společnosti Jaspersoft, která je vlastněná společností TIBCO Software.  Hlavním důvodem je generování reportů např. v PDF získaných z ElasticSearch nebo Zabbix.

Nejprve jsem instaloval JasperReports Server, což je Java aplikace běžící pod Apache Tomcat. Defaultní instalace využívá databázi PostgreSQL, ale můj požadavek byl JR Server provozovat s MySQL. Volil jsem tedy instalaci WAR využívající js-install script. Stáhnul jsem si tedy jasperreports-server-cp-5.6.1-bin.zip. Volil jsem starší verzi, protože mým cílem bylo zprovoznit rozšíření od Wedjja - https://github.com/WedjaaOpen. Které umožňuje JR Serveru komunikovat a dotazovat se pomoci JSON ElasticSearch. Aktualní verze ElasticJasperServer nepodporuje poslední verzi JR Serveru 6.x. Projekt je velmi dobře dokumentován, proto instalace JR Serveru i pluginu ElasticJasperServer není nikterak složitá.

Pro vytvoření samotných reportů se používá aplikace JasperReports Studio, která je postavena na základech vývojového prostředí Eclipse. JR Studio a JR Server spolu komunikují a vytvořené reporty je možno snadno publikovat na serveru, kde se patřičný report nechá vykonávat pravidelně a může zasílat výsledné reporty emailem nebo je uploadovat na FTP server.

JR Studio se též neobejde bez pluginu do ElasticSearch. Je třeba doinstalovat ElasticJasper. Podrobný popis jak na to je pěkně popsán na blogu Wedjja.

Samotná tvorba reportů JRXML není úplně jednoduchou disciplínou, ale výsledky mohou být velmi zajímavé.

JasperReports je v Java světě zjevně hodně znám. Čistě náhodou jsem si všiml, že účetnictví FlexiBee používá pro tisk právě JasperReports Library.

Apache Tomcat - Remove version string

Pokud někde na produkci provozujeme Apache Tomcat, je vhodné kvůli penetračním testům a potencionálním útočníkům nesdělovat verzi tomcatu. Vypnout tuto volbu někde v konfiguraci jsem nenašel. Je třeba vybalit z catalina.jar soubor ServerInfo.properties a v něm upravit - umazat verzi serveru a posleze zase soubor zabalit do jar.

Tomcat 5.x

cd CATALINA_HOME/server/lib
jar xf catalina.jar org/apache/catalina/util/ServerInfo.properties

joe org/apache/catalina/util/ServerInfo.properties
server.info=Apache Tomcat/5.5.33
na
server.info=Apache Tomcat

jar uf catalina.jar org/apache/catalina/util/ServerInfo.properties
rm -rf org

Tomcat 6.x

cd CATALINA_HOME/lib

Další bezpečnostní konfigurace jsou sepsané např. https://www.owasp.org/index.php/Securing_tomcat

P.S. u PHP se daná volba vypíná pomocí volby v php.ini

expose_php = Off

Tomcat SSL

Dnes jsem řešil pěkně vypečenej zadrhel. Před dvouma měsícema se spoustela aplikace, běžící na tomcatu, která vyžadovala užití SSL certifikátu, který app. používala pro komunikaci s jiným serverem. Vývojář vytvořil KEYSTORE a do nej uložil dodaný certifikát.

Úprava nastavení tomcatu byla následující

KEYSTORE=$CATALINA_HOME/conf/keystore
JAVA_OPTS=" ... -Djavax.net.ssl.trustStore=$KEYSTORE/mycert.truststore -Djavax.net.ssl.trustStorePassword=changeit"

Vše fungovalo. Až do doby, než se řešil problém ostatních aplikací, které dle vyjádření Java programátora nevidí Root CA certifikáty. Blesklo mi hlavou, že se to tou předchozí volbou přenastavilo.

Pátral jsem, kde má tomcat nejaké definice o keystore a nic jsem nenašel. Tak jsem hledal níže a kořenové certifikátý jsem našel v JDK.

find jdk1.6.0_21/ -name '*cert*'
jdk1.6.0_21/jre/lib/security/cacerts

Daný soubor obsahuje kořenové certifikáty certifikačních autorit, obdobně jako tomu je u prohlížečů. Pro řešení problému jsem vyexportoval certifikát z lokálního uložiště a importoval do cacert JVM, který zjevně užíva tomcat i v něm deployované aplikace (bez nutnosti nějaké konfigurace). Pro manipulaci s certifikátama java používá aplikaci keytool.

keytool -keystore mycert.truststore -list
keytool -keystore mycert.truststore -exportcert -file exportkey.crt

keytool -keystore cacerts -list
chmod 666 cacerts
keytool -keystore cacerts -importcert -file exportkey.crt
chmod 444 cacerts

Po restartu tomcatu a odstranění nevhodné konfigurace lokálního keystore z JAVA_OPTS, vše opět zařalo fungovat.

Doporučení: Po každé instalaci JVM (jre nebo jdk) je velmi vhodné změnit defaultní heslo "changeit" na nějaké bezpečnější.

APR + Tomcat-6.x + libtcnative

Na jednom serveru jsem nedávno instalovat Tomcat6, přesně apache-tomcat-6.0.26.tar.gz. Po spuštění serveru jsem v logu vídal INFO hlášku o tom, že nemůže načíst APR knihovnu. Nevěnoval jsem tomu pozornost do doby než mi napsal kolega mail a tak jsem to začal nějak řešit.

INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /opt/java/jdk1.6.0_18/jre/lib/i386/client:/opt/java/jdk1.6.0_18/jre/lib/i386:/opt/java/jdk1.6.0_18/jre/../lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib

Tyto cesty jsou evidentě defaultně načtené, některé ani neexistují.

První cesta vedla na stránky projektu kde se o APR něco píše, zaměřil jsem se na instalaci pod Linuxem.

Pro funkční kompilaci je třeba do systému Linux Ubuntu Server 8.04.4 nainstalovat pár balíčků.

apt-get install libapr1
apt-get install libapr1-dev
apt-get install libaprutil1
apt-get install libaprutil1-dev

APR je zkratka "The Apache Portable Runtime Library" podrobně popsáno na WiKi.

Manuální kompilaci a instalaci lze provádět např. takto.

./tomcatctl stop
cd /opt/apache-tomcat-6.0.26/bin
tar xvzf tomcat-native.tar.gz
cd tomcat-native-1.1.20-src/jni/native
./configure --with-apr=/usr/bin/apt-config
nebo
./configure --with-apr=/usr/bin/apr-1-config --with-java-home=$JAVA_HOME --with-ssl=yes
make
make install

v adresáři /usr/local/apr/lib/ se po instalaci objeví potřebná knihovna libtcnative-1.so

Pro funkční načtení knihovny jsem ještě nastavil patřičnou JAVA proměnnou.

JAVA_OPTS="-Djava.library.path=/usr/local/apr/lib"

Pro funkční běh jsem ještě musel lehce poladit server.xml aby tomcat vubec naběhl. Některé direktivy už nejsou asi platné.

Stávající nastaveni konektoru mám pro Tomcat5.

port="8019" protocol="AJP/1.3"
enableLookups="false"
useBodyEncodingForURI="true"
acceptCount="256"
maxThreads="500"
emptySessionPath="true"

Takovou malou zajimavostí, alespoň pro mě je, že s použitím APR se zjevně používá jiný Conector, přičemž definice v konfiguračním souboru je stejná. U Tomcatu bez APR se používá JK konektor a při použití APR se startuje Coyote JK. Některé části Tomcatu ještě zjevně nemám probádané a toto chování mě lehce rozhodilo. Každopádně jsem zvědav zda s APR získám větší výkon.

Důkladně jsem si přečetl BUILDING, kde se píše o přenastaveni konektoru

protocol="org.apache.coyote.http11.Http11AprProtocol"
protocol="org.apache.coyote.ajp.AjpAprProtocol" = protocol="AJP/1.3"

Od verze Ubuntu Intrepid je k dispozici balík libtcnative-1, ten je, použitelný v případě, že používáme tomcat jako balík v systému, což není můj případ. Takže manuální kompilaci se nevyhneme. Ikdyž použít starší verzi Apache Tomcat Native library je možné. Alespoň verze 1.1.19 mi s Tomcat 6.0.26 fungovala s tím že v dané verzi tomcatu je Apache Tomcat Native library 1.1.20. Takže by mělo být asi možné provozovat balíčkovou verzi Apache Tomcat Native library s manuální instancí Tomcatu6.

Loaded APR based Apache Tomcat Native library 1.1.20

Ve FreeBSD je port /www/tomcat-native. Použití na tomto systému jsem zatím netestoval.

MALLOC_CHECK - glibc vs java

S touto hláškou mě dnes lehce vyděsil kolega s kódovým označením PCI :-)

*** glibc detected *** double free or corruption ***

Hláška se objevila při spustění čehosi co je napsáno v jazyce Java a má to obludný název com.fg.pdf.cps.PdfToImageAction :-) Načítá si to PDF soubory a někam na určené místo to vyplivne obrázky. Budu dále pátrat co toto chování způsobuje, protože daný proces doslova sejme aplikační server Tomcat.

Řešením je pro uživatele pod kterým se to pouští nastavit tuto proměnnou. Tak jako tak je třeba přijít na příčinu přetékání paměti. MALLOC je subrutina jazyka C, která řídí dinamickou alokaci paměti.

export MALLOC_CHECK_=0

set | grep MALL
MALLOC_CHECK_=0

Testováno na Linux systémech s glibc těchto verzí:

libglib2.0-0 2.16.6-0ubuntu1.2
libglib2.0-0 2.10.3-0ubuntu1

Zde je použití proměnné MALLOC_CHECK pěkně popsané.

mod_jk 1.2.30 na Ubuntu 8.04.4 ze src

V Ubuntu Hardy Heron nebo číselně 8.04.4 LTS je velmi stará verze Apache2 modulu mod_jk 1.2.25 z 7.8..2007 :-( Např. ve FreeBSD je daný modul v aktuální vezi.

Pokud řešíte problém jako je nastavení workers.properties, ve kterém vyžaduji nastavení viz sekce v dokumentaci / Load Balancing Directives - sticky_session a Advanced Worker Directives - session_cookie / je problém na světě. Daná funkcinalita Tomcat Load Balancingu a chování session je funkční od až od veze 1.2.27. No a zde nám Debian a Ubuntu nějak usnulo. Neaktuálnost balíku v LTS verzi mě trošku zaráží. Hledal jsem nějaký externí repozitář, ale nenašel jsem. Rozhodl jsem se modul aktualizovat kompilací ze src.

Stručný popis, jak na to:

sudo su -
mkdir install
wget http:// kdesi cosi /tomcat-connectors-1.2.30-src.tar.gz
tar xvzf tomcat-connectors-1.2.30-src.tar.gz
cd tomcat-connectors-1.2.30-src/
less BUILD.txt

Dle popisu, jak kompilovat je patrné, že potřebuji APache eXtenSion tool pro Apache2. Hledám, v jakém balíčku se nachází.

apt-cache search apxs2
apache2-prefork-dev - development headers for apache2
apache2-threaded-dev - development headers for apache2

Jelikož používám apache2-mpm-worker volím druhý balík.

apt-get install apache2-threaded-dev

Kompiluji ...

cd native/
./configure --with-apxs=/usr/bin/apxs2
make
make install

Installing files to Apache Modules Directory...
/usr/bin/apxs2 -i mod_jk.la
/usr/share/apache2/build/instdso.sh SH_LIBTOOL='/usr/share/apr-1.0/build/libtool' mod_jk.la /usr/lib/apache2/modules
/usr/share/apr-1.0/build/libtool --mode=install cp mod_jk.la /usr/lib/apache2/modules/
cp .libs/mod_jk.so /usr/lib/apache2/modules/mod_jk.so
cp .libs/mod_jk.lai /usr/lib/apache2/modules/mod_jk.la
cp .libs/mod_jk.a /usr/lib/apache2/modules/mod_jk.a
ranlib /usr/lib/apache2/modules/mod_jk.a
chmod 644 /usr/lib/apache2/modules/mod_jk.a
PATH="$PATH:/sbin" ldconfig -n /usr/lib/apache2/modules
----------------------------------------------------------
Libraries have been installed in:
/usr/lib/apache2/modules

Je třeba si uvědomit, že příkazem make install se nám přepíše modul z instalované verze v systému libapache2-mod-jk 1:1.2.25-2. Dále je třeba brát v patrnosti, fakt, že jsme vzali čisté zdrojáky, ale na systémový balíček je aplikován patch udržovatelů daného balíčku. Takže je velkou neznámou, zda je možno tuto verzi modulu takto zkompilovanou nasadit na produkční server.

Dále jsem si všiml, že direktivu JkMount jem musel z jk.conf přesunout do souboru kde definuji virtualni web server, ale to si musí každý vyzkoušet sam. Jistá změna tam prostě je.

Tomcat dual IPv4 + IPv6

Pokud máme někde na serveru nahozené dvě konektivity, jak IPv4 tak IPv6, může se stát že start a stop aplikačního serveru trvá neskutečně dlouho. Podle mého soudu je duálni IP provoz na pováženou a nejsem jeho zastánce. Alespoň zatím :-)

Pro vyřešení problému se zdlouhavým startem Tomcatu je vhodné zapnout tyto volby.

Do proměnné JAVA_OPTS

-Djava.net.preferIPv4Stack=true
-Djava.net.preferIPv4Addresses=true

Tomcat balancing na Ubuntu

Tomcat Balancing je funkční za pomocí Apache modulu mod_jk. V ukázce je rychlý návod jak si na třech serverech ballancing vyzkoušet. UTS je moje zkratka "Ubuntu Test Server".

Instalace tomcatu na ubuntu
apt-get install tomcat5.5 tomcat5.5-admin tomcat5.5-webapps

Instalace apache2 a modulu mod_jk
apt-get install apache2 libapache2-mod-jk

joe /etc/apache2/mods-enabled/jk.conf
#
# jk.conf
#
JkWorkersFile /etc/libapache2-mod-jk/workers.properties
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel info

JkMount /servlets-examples/* lbw
JkMount /jsp-examples/* lbw
JkMount /status/* statusw
# EOF

joe /etc/libapache2-mod-jk/workers.properties
#
# workers.properties
#
worker.list=lbw,statusw,tomcat01,tomcat02,tomcat03

# uts-1
worker.tomcat01.port=8009
worker.tomcat01.host=172.1.1.90
worker.tomcat01.type=ajp13
worker.tomcat01.lbfactor=1
# uts-2
worker.tomcat02.port=8009
worker.tomcat02.host=172.1.2.90
worker.tomcat02.type=ajp13
worker.tomcat02.lbfactor=1
# uts-3
worker.tomcat03.port=8009
worker.tomcat03.host=172.1.3.90
worker.tomcat03.type=ajp13
worker.tomcat03.lbfactor=1
# ballancing
worker.lbw.type=lb
worker.lbw.sticky_session=0
worker.lbw.balance_workers=tomcat01,tomcat02,tomcat03
# status
worker.statusw.type=status
# EOF

Balancované ukazky:
http://uts-1.domena.cz/jsp-examples/
http://uts-1.domena.cz/servlets-examples/

Status mod_jk:
http://uts-1.domena.cz/status/

Tomcat servery v default konfiguraci s HTTP konektorem
http://uts-1.domena.cz:8180/
http://uts-2.domena.cz:8180/
http://uts-3.domena.cz:8180/

Monitorování Tomcat serverů / Monitoring Tomcat

Pro monitorování aplikačních serverů tomcat jsem se rozhodl používat ZABBIX. Je to systém, který se vyznačuje tím, že má vlastní protokol ZBX, pro komunikaci serveru s agentama. Těch existuje celá řada, hlavně pro velké množství operačních systémů. Jak monitorovat Tomcat servery? Pro monitorování Tomcatů budeme potřebovat aplikažního agenta ZABCAT, který je mostem mezi JMX a monitoring serverem ZABBIX. JMX je Java Management Extensions, je nezbytnou soužástí získávání informací o stavu Tomcat serverů. Systém pro ukládání naměžených dat používá relační databázi.

ZABCAT je možné nainstalovat i do Jabber serveru OpenFire jako plugin, kterým mužeme pomocí ZABBIXu též monitorovat stav serveru.

Monitorovací server jsem instaloval na FreeBSD. Díky existenci portu je instalace vesměs hračkou.

Dalším kandidátem na test je OpenNMS, který by měl též umět spolupracovat se ZAPCATem.