Here are the comments (can't assign task to original poster, will update forum thread):

1. Sometimes Linux Console Installer aletrs "Installation failed" after checking mysql as datastore and disabling postgres and derby going to next screen and it fails, then I run installer again, doing same steps and it continues this step and fails again next step.

this was caused by the upgrade to izpack 4.3.4 (which was intended to fix issues with exceptions in console) - I've reverted the upgrade and applied izpack fix to our patch;

2. (...)I've created it and copied files groovy-all.jar and mysql-connector-java.jar to newly created "libs" directory. I've started Tigase and it was running. I was happy until...

scripts/tigase.sh was updated to handle migration from libs to jar and this shouldn't be a problem; if you were using RHEL init script then it was corrected only recently and correct version was not included in the beta3. However editing init script and correcting variable TIGASE_LIBS from libs/ to jars/ should fix the issue (instead of copying files).

3. I have my own certificate, which works perfect on Tigase 5.1.5, so I copied it to 5.2.0 beta 3, configured init.properties and restarted Tigase. When I tried to connect from my PSI+ client, there was message, that certificate is self-signed by Tigase.org. Log below:

Certificate is a wildcard (screenshot).

could you provide the certificate, or at least its information output (i.e. @openssl x509 -in path/to/cert.pem -noout -text@), at least privately?

How did you configured it? Are the permissions to the file correct and it can be read by tigase user?

I've checked with selfsigned wildcard certificate and it didn't cause any problems.

4. I decided to run tigase as a daemon(user tigase), so I copied file from scrpits/redhat/init.d/tigase to /etc/init.d/ and configured it and changed ownership of tigase files/directories to tigase user. It was running, but message-archive-xep-0136 didn't load. Logs told me that component even didn't try to run but rest of components, plugins and server were working fine. If I run tigase as root message-archive component loads without any errors (I've double checked permission, ownership etc.).

Can't verify; just checked on CentOS 6.4 - downloaded beta3 tarbal, extracted it to my home directory, copied script from same path to same path, edited java path, username/group, edited path to libraries directory, enabled init script and tigase started and loaded component without any problem. Could you share output from logs/tigase-console.log? Did the right configuration file was loaded (i.e. with message-archive component setup)?

I haven't tried .jar installer, but nightly ...max.tar.gz

It worked, server, message-archive-xep-0136 also, Certificate didn't (I'll try later, or send cert to you to check).

There is one more problem(? maybe it doesn't do anything, but it notices):

@service tigase start

Starting Tigase XMPP server

su: uwaga: nie można zmienić katalogu na /home/tigase: Nie ma takiego pliku ani katalogu

Tigase started [ OK ]@

Probably it's because I've changed directory where tigase server is to /opt/tigase. But I've changed every path in /etc/init.d/tigase script.

About init script - I've also tested custom path (/home/wojtek/tigase/tigase-server), updated configuration in init.d and it worked without any problem. Did you use correct path?

I'm looking forward to more information about remaining certificate issue.

I sent you an email. I didn't want to give all cert output for public use.

I've received the e-mail, thanks. I'll updated the ticket after closer look.

Update: wildcard certificate works, user will verify thoroughly his certificate/certificate chain.

It seems to be

--ssl-container-class=tigase.extras.io.PEMSSLContextContainer

fault. When I remove it from init.properties, Certificate run.

Bartosz, what class is not used to handle certificates loading form PEM files? Have you implemented a new class? If so, and the old one is not updated maybe we should deprecate it?

We use

tigase.io.SSLContextContainer

by default. It handles certificates in PEM format.

I've added above remark to Creating and loading the server certificate in pem files for clarity.

Wojciech, could you please confirm all the issues are resolved before planed RC1? If so, please close the ticket.

All reported issues were resolved/explained. There was still an issue with certificate but it turned out that the certificate used by the user did not contained full CA chain thus causing problem; there were no feedback from the user afterwards so I assume correcting issue with faulty certificate resolved the issue as well thus making everything resolved.