OpenSSL library error follows - values mismatch

Řešil jsem standartní výměnu SSL certifikátu u webserveru Apache. Po domluvě s osobou, co certifikační řízení řešil u CA Thawte jsem mu vytvořil nové CSR dle zvyklostí.

openssl genrsa -des3 -out www.domena.cz.key 2048
openssl req -new -key www.domena.cz.key -out www.domena.cz.csr
openssl rsa -in www.domena.cz.key -out www.domena.cz.key-decrypt

Posléze jsem certifikáty přenesl na webserver a restartoval jej a ejhle, Apache nenaběhl s hláškou:

[Mon Nov 21 12:36:16 2011] [error] mod_ssl: Init: (www.domena.cz:443) Unable to configure RSA server private key (OpenSSL library error follows)
[Mon Nov 21 12:36:16 2011] [error] OpenSSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch

Je vhodné vždy prověřit, zda je modulus stejny u klíče (key), certifikátu (crt) a požadavku (csr)!!!

openssl x509 -noout -text -in www.domena.cz.crt -modulus
openssl rsa -noout -text -in www.domena.cz.key -modulus
openssl req -noout -text -in www.domena.cz.csr -modulus

Muj problem byl v tom, že mi pán zaslal jiný cert, než bylo domluveno :-(

SSI apache 1.3 vs apache 2.2

Překlapěl jsem konfigurace Apache 1.3.x na Apache 2.2.x a narazil jsem na problem s SSI, přesněji na práci s DATE_LOCAL. SSI jako takové fungovalo, ale duplicitní directiva zapomenutá v common.conf a nová direktiva v mods-enable/mime.conf delala problémy.

Konfigurace Apache 1.3.x

AddType text/html .shtml
AddHandler server-parsed .shtml

Konfigurace Apache 2.2.x

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

Je zvláštní že apachectl configtest nehlídá i duplicitní záznamy v konfiguraci.

Test Linux Desktop

Test Linux Desktop, a set on Flickr.

Via Flickr:
Nastal čas, čistě uživatelsky instalovat a letmo otestovat pár známých Linux distribucí platformy x86_64. Preferováno Gnome.

Testováno na zapůjčeném HW - Lenovo ThinkPad T61

Linux Mint 11 Katya base Ubuntu Natty
Gnome3 Live DVD (F15)
Fedora 15 Lovelock
Ubuntu 11.04 Natty
Debian 6.0.2 Squeeze
openSUSE 11.4 Caladon

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

Archiva - Artifact Repository Manager

V práci na mě padlo provést aktualizaci Archiva - Artifact Repository Manager http://archiva.apache.org/, což je java aplikace. Něco jako repository pro Linux distribuce, ale Archiva slouží pro Java vývojáře. Aplikace má více rolí a jednou z nich je i Proxy. Jednoduše řečeno vývojáři nemusí ručně stahovat kamsi jednotlivé knihovny. O vše se postará Maven a Archiva. Doposud jsme používali verzi 1.2.2 a nově jsme přešli na aktuální verzi 1.3.5.

Popis prostředí

Jako server pro běh aplikace jsem zvolil Linux Ubunru 10.0.4 LTS 64bit. Aplikace Archiva vyžaduje ke svému běhu web server Apache, Java, Tomcat, Maven a databázi MySQL. Ikdyž existuje i verze Standalone s vlastnim web serverem Jetty. Použíl jsem veryi WAR, která běží pod se deployne v tomcatu.

• Apache 2.2.14 - ubuntu package + moduly libapache2-mod-jk a libapache2-mod-macro
• Java 1.6.0_26 64bit - instalována manuálně
• Tomcat 6.0.26 - instalován manuálně
• Maven 2.2.1 - instalována manuálně
• MySQL 5.1.41 - ubuntu package
• Archiva 1.3.5 - instalována manuálně

Konfigurace

Apache

Nastavení webserveru apache2 jsem řešil dle balíčkové konfigurace.

apt-get install cronolog
apt-get install apache2 libapache2-mod-macro libapache2-mod-jk

joe /etc/apache2/envvars
export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data
export APACHE_PID_FILE=/var/run/apache2.pid
export APACHE_ARGUMENTS="-Don -Dtrue -Dyes"
export APACHE_FG_INSTANCE_NAME="apache01"

joe /etc/apache2/ports.conf
NameVirtualHost 80.250.16.10:80
Listen 80.250.16.10:80

cd /etc/apache2/mods-enabled
ln -s ../mods-available/rewrite.load ./
ln -s ../mods-available/headers.load ./
ln -s ../mods-available/include.load ./
ln -s ../mods-available/info.conf ./
ln -s ../mods-available/info.load ./
ln -s ../mods-available/macro.load ./
ln -s ../mods-available/macro.conf ./

joe info.conf
joe status.conf
joe jk.conf
joe macro.conf

cd /etc/apache2/sites-
joe default
joe archiva

cd /www/
mkdir -p server_log/apache01/log/

/etc/init.d/apache2 restart

Tomcat

Tomcat byl instalován dle zvyklostí.

ubuntu:~/install/tomcat-6.0.26&gt ./install-tomcat.sh
Instaled 1 Tomcast's
Install tomcat01 ...
patching file catalina.sh
patching file setclasspath.sh
patching file server.xml
patching file tomcat-users.xml

Důležité nastavení je v těchto souborech.

cd /www/server/tomcat01/apache-tomcat
joe bin/setclasspath.sh
...
## Archiva
export CATALINA_OPTS="-Dappserver.home=/www/java/archiva-home -Dappserver.base=/www/java/archiva-home"

joe conf/server.xml

Archiva vyžaduje doinstalovat pár knihoven do tomcat lib

ubuntu:/www/server/tomcat01/apache-tomcat> cat lib/readme-lml.txt
Pridal jsem soubory (jsou potreba pro aplikaci Archiva):
activation-1.1.jar
derby-10.1.3.1.jar
derbytools-10.1.3.1.jar
mail-1.4.jar
mysql-connector-java-5.1.5.jar

Archiva

Je umístěna v adresáři

ubuntu:/www/java/> ls -1
archiva # link na aktualni verzi
archiva-1.2.2 # stara verze
archiva-1.3.5 # aktualni verze
archiva-home # repo conf log atd.

Další konfigurák je v conf adresáři Maven .m2

ubuntu:~/.m2> ls -1
archiva
archiva.xml
repository
settings.xml

Tyto záznamy jsou vesměs pro mě. Podrobně je vše zdokumentováno na tránkách projektu. Pokud bude zájem ještě mám v plánu archivu dokonfigurovat, aby se autentizovala oproti LDAPu.

Ještě malá poznámka na závěr. Verze 1.3.5 nevyžadovala žádné úpravy MySQL tabulek. Udělal jsem dump a ten nalil na nový server, kam jsem aplikaci stěhoval i s archiva-home a vše běží jak má. Na stěhování repo jsem užil rsync.

PFX - PKCS and Apache

Dostal se mi pod ruce certifikat v souboru s priponou .pfx. Pátral jsem a vyplivla ho zjevně nějaká M$ CA a tak jsem hledal jak to překonvertit pro Apache.

How do I export or import a PKCS#12 certificate?

openssl pkcs12 -in cert.pfx -out cert.pem -nodes

Soubor cert.pfx je zaheslován, takže potřebujeme i heslo pro úspěčnou konverzi. Konverzí získáme soubor cert.pem, který obsahuje balast řádky typu.

Bag Attributes
1.3.6.1.4.1.311.17.2:
localKeyID: 01 00 00 00
Microsoft CSP Name: Microsoft Software Key Storage Provider
friendlyName: le-LMCZWebServer-aee00472-b103-45d9-a25c-b0da2fb35820
Key Attributes:

a

Bag Attributes
localKeyID: 01 00 00 00
friendlyName: LukasMaly.NET
subject=/CN=test.smejdil.cz
issuer=/DC=cz/DC=smejdil/CN=Test

Nás budou zajímat jen sekce

-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Které si vykopírujeme např. do souborů test.smejdil.cz.crt a test.smejdil.cz.key. Dané soubory můžeme přidat do konfigurace Webserveru Apache např. s modulem mod_ssl.

PKCS#12 je standard z rodiny PKCS a PFX Tento formát se již nepoužívá, je to starší implementace, kterou Microsoftu stale používá. Dle české wiki je PFX předchůdcem standardu PKCS#12.

Zde je ještě zajímavé povídání s nadpisem "PFX - How Not to Design a Crypto Protocol/Standard"

Sonar - manage code quality

Dnes jsem byl požádán o zprovoznění aplikace Sonar, což je Java aplikace pro správu kvality kódu. Nejsem vývojář, ale jako správce systému jsem nucen danou aplikaci nainstalovat a provozovat v nějakém rozumném stavu (zalohy konfigurace, db atd.). Sonar jsem konfiguroval s MySQL databází. Instalace je vcelku snadná.

Živá ukázka
http://nemo.sonarsource.org/

Startovaci script umisten do init.d.

root@sonar:/etc/init.d# cat sonar
#!/bin/sh

sudo -u sonar /data/app/sonar/bin/linux-x86-32/sonar.sh $1

Prvotní inicializace aplikace je pěkně viditelná v logu.

tail -f logs/sonar.log
2010.10.12 13:02:22 INFO org.sonar.INFO loading the profile Sonar way with Findbugs/java from checkstyle
2010.10.12 13:02:22 INFO org.sonar.INFO loading the profile Sun checks/java from checkstyle
2010.10.12 13:02:24 INFO org.sonar.INFO loading findbugs profiles...
2010.10.12 13:02:24 INFO org.sonar.INFO loading the profile Sonar way with Findbugs/java from findbugs
2010.10.12 13:02:39 INFO org.sonar.INFO activating java default profile...
2010.10.12 13:02:39 INFO org.sonar.INFO Load profiles done: 21394 ms
2010.10.12 13:02:39 INFO org.sonar.INFO Start services done: 30238 ms
2010.10.12 13:02:39 INFO org.sonar.INFO Loading web services...
2010.10.12 13:02:39 INFO org.sonar.INFO Loading web services...
2010.10.12 13:02:39 INFO org.sonar.INFO Sonar started: http://0.0.0.0:9000/

V budoucnu se o dané aplikaci dozvím více od vývojářů.

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ší.

FreeRADIUS - Active Directory - HP ProCurve Switch - 802.1X

Bezpečnosti není nikdy dost a tak i omezení přístupu k interní LAN nebo WLAN je vždy vítano. Aby switch mohl ověřit supplicant = žadatele o přístup do sítě, musí být nakonfigurován tak, aby se zeptal FreeRADIUS serveru, který se přeptá Active directory, zda-li daný uřivatel může být připojen k danému portu switche. Takto je to velmi jednoduše popsáno, ale tak to zjednodušeně je. Zaklínadlem je standard 802.1X, který je implementovan ve většině síťových zařízeních, jako jsou switche a wi-fi acess point.

Dobře popsaný návod se nachází na wiki freeradiusu. Radius server vyžaduje bezplatnou instalaci FreeRADIUS serveru a Samby.

Ubuntu:
apt-get install freeradius
apt-get install winbind

FreeBSD:
portinstall freeradius2
portinstall samba34

U samby postačí winbind, smbd a nmbd není třeba. Samba se musí přihlásit do Win domény.

Pokud máme vše správně nastavené, ověříme, zda nám samba ověží uživatele.

ntlm_auth --request-nt-key --domain=WINDOM --username=smejdil
password:
NT_STATUS_OK: Success (0x0)

V návodu je popsána konfigurace kerberosu, kterou jsem nedělal a ntlm_auth mi ověřuje, tak asi není třeba.

Pokud máme poladěný freeradius, můžeme testovat funkčnost ověřování.

radtest smejdil 123456abcd server-radius 1813 testing123
Sending Access-Request of id 14 to 192.168.0.10 port 1812
User-Name = „smejdil”
User-Password = „123456abcd”
NAS-IP-Address = 192.168.0.20
NAS-Port = 1813
rad_recv: Access-Accept packet from host 192.168.0.10 port 1812, id=14, length=20

Dále jsem nastavil radius server v HP ProCurve switchi, ale jen nastavil. Nastavení portů atd prozatím musí počkat.

hp-sw# configure
hp-sw(config)# radius-server host 192.168.0.10
hp-sw(config)# radius-server key 123456abcd
hp-sw(config)# show radius
hp-sw(config)# write memory

Status and Counters - General RADIUS Information

Deadtime(min) : 0
Timeout(secs) : 5
Retransmit Attempts : 3
Global Encryption Key : 123456abcd

Auth Acct
Server IP Addr Port Port Encryption Key
--------------- ----- ----- --------------------------------
192.168.0.10 1812 1813

Dále bude následovat. Ale to až zase jindy. Dále musím vyzkoušet FreeRADIUS s OpenLDAPem.

hp-sw(config)# aaa port-access

VMware Workstation upgrade z 7.0.1 na 7.1

Jsem aktivním uživatelem produktu VMware Workstation a užívám jej na Linux Ubuntu 10.04 LTS a to legálně :-) Firma nedávno zakoupila upgrade z 6.x na 7.x.

Po upgradu, který skoro vše pořešil sám. Tím mám na mysli odinstalování starší verze a instalaci nové.

sudo sh VMware-Workstation-Full-7.1.0-261024.x86_64.bundle

Po instalaci pouštím WinXP virtualku a ta nesíťuje. Kolega mi poradil a tak unončuji Workstation a pouštím příkaz.

sudo vmware-modconfig --console --install-all

Ten zkompilovat síťové drivery a asi i jiné věci a po startu XP vše funguje.

Náchod Montace

Dnes jsem se konečně zase dokopal k pohybu. Místo oběda jsem s kolegama šel běhat do městského lesa Montace. Jelikož nejsem moc běžec, tak jsem uběhl jen necelých 5 km za 33minut, ale i tak pro mě uspěch, hejbu se :-)

Trasu jsem si zaznamenal na GPS a vlozil na runmap.net

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.

Ubuntu 10.04 BETA1

Ubuntu 10.04 BETA1 - SW Center
Originally uploaded by SmEjDiL

O nové LTS verzi Ubuntu bylo již napsáno hodně. Po přečtení zprávyčky sem si musel do VMware Workstation nainstalovat nově připravované Ubuntu 10.04 BETA1. Fialový vzhled se mi osobně až tak moc nelíbí, ale vše se dá přenastavit. Na druhou stranu změn není nikdy dost. Konzervy ovšem prskaj, že co verze, tak jiný vzhled. Uvítal jsem aktualizaci postarších balíku jako je zabbix-agent a např bacula-client. Dále jsem uvítal PSI+ a jiné změny. Až vyjde final release otestuju na domácím notebooku a až bude čas a chut instalnu na firemni vercajk ... :-)

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.

Hodinová sekera

Tak jako každou středu až čtvrtek čekám na rychlík od Liberce a on nikde (prý hodina zpoždění), tak dnes mám Home Office, ještě, že to jde. Jako test, "Bloguji z mobilu."

Změna IP v iPlanet Apliacation Server 6.x

Pokud se rozhodneme měnit IP adresu v OS dříve než ji změníme v aplikačním serveru iPlanet, je to špatná volba, postup změny je opačný, protože pro změnu IP v LDAPu je třeba, aby daná instance serveru běžela.

1. Pro změnu IP v aplikačním serveru, jehož součástí je slapd - LDAP se musíme přihlásit na konzoli do X windows pod uživatelem pod, kterým aplikační server běží např. iplanet1, kde nás přivíta v mém případě SunOS 5.8, Window Manager CDE. V terminalu si pustíme aplikaci kregedit. Aplikace vyžaduje funkční X windows a s tím je spojená i proměnná systému $DISPLAY. V aplikaci lze vyhledat danou IP jako hodnotu nějaké proměnné. Dále je možno IP změnit pomocí položky v menu. Zadáme old IP a new IP. Pozor pokud server používá více IP než jednu je třeba se ujistit, která je pro LDAP a aplikační servery a která pro HTTP servery.
2. Dále je třeba upravit server.xml HTTPD serveru např. /appl/iplanet/servers/https-server.domena.cz/config/server.xml.
3. Změnu IP atd. na úrovni OS provedeme ve několika souborech /etc/host*, /etc/defaultrouter, /etc/networks.
4. Dále následuje reboot, ale nikoliv příkazem reboot použijeme shutdown -y -g 10 -i 6, který korektně ukončí vše běžící.
   

Mnou provaděné změny proběhly na Solarisu 8 presně:
SunOS appsun 5.8 Generic_117350-47 sun4u sparc SUNW,Ultra-80

Návod, který jsem částečně použil je zde.

Milane díky :-)

Apt-Cacher NG

Pokud spravujeme větší množství Debian nebo Ubuntu serverů, je značně nevhodné při aktualizacích stahovat jednotlive balíky separátně a tím zatěžovat připojení k internetu. Je možno použít speciální web cache Apt-Cacher NG, která nám dané balíky drží na disku a celkově zrychluje provádění samotných aktualizací.

Daný SW jsem zprovozňoval na Ubuntu. Verze daného balíku je v Hardym hodně stará apt-cacher-ng 0.1.9-1. U tvůrce danéhé cache je k dispozici mnohem novější verze. Na launchpadu je k dispozici několik externích repozitářů.

Vím o existenci balíčku apt-cacher,který jsem zatím nezkoušel.

Instalace je velmi snadná

sudo apt-get install apt-cacher-ng

konfigurace se provádi zde
/etc/apt-cacher-ng/acng.conf

Nastavení klientských OS

echo 'Acquire::http { Proxy "http://apt-cache.domena.cz:3142"; };' | sudo tee /etc/apt/apt.conf.d/01proxy

Na obdobné adrese http://apt-cache.doména.cz:3142/acng-report.html se nachází jednoduchý přehled o využití cache.

CVSweb

Je velmi užitečný perový script, který umožní nahlížet na data v CVS repository pomocí webového prohlížeče. Script pochází z dílny FreeBSD, které CVS používá již řadu let.

Script lze provozovat např. na web serveru Apache a nebo na velmi odlehčeném Lighttpd.

Script se dá stáhnout ze stránky projektu FreeBSD CVSweb Project, nebo lze využít balíčků v OS. Např. Ubuntu má svůj balíček popsán zde. FreeBSD port je zde.

Popis stručné instalace je např. zde. Po zprovoznění je nutno nakonfigurovat cvsweb.conf, ve kterém je velké množství možností k nastavení. Jednou z hlavních direktiv je definice CVSROOT.

Firemní instant komunikace

Společnost FG Forrest a.s. začala používat interní firemní Jabber server začátkem roku 2008. Důvodů bylo hnedle několik. Hojně používané ICQ se chovalo v té době velmi nestabilně, což bylo způsobeno vypínáním starších protokolu, které AOL postupně nahradilo protokolem Oscar. Tento krok byl jistě technologicky nezbytný, ale patrně naštval velkou spoustu uživatelů, protože tímto nepopulárním krokem přestali fungovat různí alternativní ICQ klienti. Reklamou proložený AOL ICQ klient je z mého pohledu nepoužitelný. Někteří vývojáři zareagovali ryche a opravili své klienty. Ale i tak získalo ICQ jistý punc nedůveryhodnosti. Dalším aspektem odporu k ICQ je jeho centralizace, jistá nebezpečnost co se virů týče. Posledním velmi pádným argumentem je úskalí licence ICQ, která zakazuje jej používat ve firemním prostředí.

Proto se na poli Instant Messaging, dále jen (IM) systémů hledala nějaka akceprovatelná alternativa. Existuje celá řada IM systémů integrovaných přímo do Goupware systému jako je M$ Exchange - MSN nebo např. Lotus Notes SameTime Instant Messanger, ale to není správná cesta, protože tyto systémy svazují komunikaci mezi ostatními. Jabber je vhodným kandidátem, který splnil veškerá očekávání jako firemní Instant Messagnger. IM klienti umožňují nastavení více účtů a tak i firemní zaměstnanec může snadno pomocí stejné aplikace komunikovat s lidmi mimo firmu. Pri zavádění XMPP/Jabber ve FG byla prvořadá bezpečnost, modularita konfigurace a hlavně uživatelská přívětivost již používaných, oblíbených multiplafromních a multiprotokolových klientů, jako je např. Miranda, Pidgin nebo QIP. Další nespornou výhodou Jabberu - OpenFire je možnost udržovat firemní kontakty přímo v nastavení rosteru uživatelů, odpadá tak sbírání firemních kontaktů a jejich autorizace mezi zaměstnanci. V praxi toto pak funkuje tak, že server zajistí podstrčení všech předefinovaných kontaktů všem přihlášeným klientům. Protokol ICQ se ve firmě tiše toleruje, hlavně asi pro soukromé účely, či pro jiné komunikační aktivity, např. mezi klenty, kteří Jabber neznají nebo jej nechtějí používat.

Jednou z otázek bylo vybrat vhodnou implementaci Jabber serveru. Již z drívějších referencín serveru WildFire padla volba právě na OpenFire, které přináší velmi jednoduchou instalaci i správu v podobě kvalitního WebAdmin rozhraní. Mnoho uživatelů odradí od tohoto serveru Java na které je postaven. Z vlastní zkušenosti mohu potvrdit, že server funguje jak pod aktualni verzí 1.6 Sun JRE, tak i pod verzi 1.5. Což u java aplikací né vždy funguje. Server provozujeme pod distribuci Linux Ubuntu, pro kterou výrobce připravuje instalační balíček Debian. Díky Javě je server zprovoznitelný pod jakýmkoliv operačním systémem. Dále jsem testoval OpenFire i pod OS FreeBSD, pro který je vytvořen patřičný port. Instalace daného serveru je pak velmi jednoduchá a rychlá. Velkou výhodou serveru je možnost použití externí autentizace za pomocí LDAP adresáře. Z požátku se FG server používal s lokálně definovanými uživateli, ale při posledním upgradu serveru jsme přešli na interní LDAP - Active Directory. Čímž se výzazně zjednodušila správa serveru a případné nastavování hesel atd. již odpadlo.

Jabber server OpenFire používáme napříč všemi pobočkami. Umožňuje jen SSL připojení odkudkoliv, ale zamezuje komunikování s ostatními Jabber servery. Server je koncipován jako interní komunikační prostředek, který jsou všichni zaměstnanci povinni používat. Instant Messaging komunikace se ve firemním prostředí FG Forrest a.s. usadila a opravdu hojně se používá. Odpadají tak jednovětné emaily, které se řetězí a samotná informační hodnota se pak vytrácí v hromadě emailů.

Provozování Jabber/XMPP služby je pro jednotlivé firmy jednoduché a levné. Pokud mají zaměstnanci potřebu si rychle a přehledně předat nějaké informace, je to správná volba. Mnoho uživatelů internetu IM bere jako samozřejmost a hlavním tahounem je bezesporu ICQ, ale to není to pravé a tak se pak tato služba těžko prosazuje. Agrumentem pak je že "Moji známí používají Ajsko ..." Velkým hráčem, který použil Jabber ve svých produktech je Google se svou službou Gtalk, která pro textovou IM komunikaci používá právě Jabber/XMPP. Každý, kdo má účet u Googlu si tak může velmi snadno Gtalk aktivovat a tím se propojí s jakýmkoliv Jabber serverem. Na české scéně asi před necelým rokem zazněla zpráva o tom, že Seznam.cz testuje Jabber pro své uživatele. Pokud by tuto službu Seznam zprovoznil, výrazně by tak přispěl k rozšíření této velmi zajímavé služby. Asi nejznámější na poli IM je česká firma HumboldTec, která provozuje již několik domén veřejných Jabber serverů. Firma se aktivně angažuje ve tvorbě vlastního klienta Jabbim, tak i v dalších aktivitách spojených s rozvojem svých serverů. Za zmíňku dozajista stojí transporty pro spojeni s jinými IM sítěmi a nově i propojení se sociálními sítěmi jako je Facebook, Twitter, dále jsou k dispozici služby jako Slovnik, Disk atd.

Do budoucna věřím, že se Jabberu bude dařit a zaslepení Ajskaři :-) objeví nové možnosti ne jen v soukromí, ale i ve firemním světě.

Zde je FG firemní verze lehce upraveného článku, Lado díky za korekturu :-)