[DISCUSSION][ANNOUNCE] Apache OpenMeetings 5.0.0-M1 is released

2019-04-03 Thread Maxim Solodovnik
Hello All,

Usually I do write ANN emails by myself, but this time I would like to
ask help from the community
I believe first 5.0.0 ANN should be sort of special
Please let me know if below announce can be enhanced

Thanks in advance!

-
The Apache OpenMeetings project is pleased to announce
the release of Apache OpenMeetings 5.0.0-M1.
The release is available for download from
https://openmeetings.apache.org/downloads.html

Apache OpenMeetings provides video conferencing, instant messaging, white board,
collaborative document editing and other groupware tools. It uses API
functions of
Media Server for Remoting and Streaming (Red5 or Kurento).

Release 5.0.0-M1, provides following improvements:

Flash plugin is not required anymore, with this milestone release
audio, video and screen-sharing in the Room is performed with WebRTC.

Unfortunately there are some limitations:
1) this version will not work in IE11
2) Edge browser support is limited due to some bugs in browser
3) External video in room is not yet supported
4) SIP integration is not yet implemented

Other fixes and improvements, 30 issues were fixed

Readme: https://github.com/apache/openmeetings/blob/5.0.0-M1/README.md

Changelog: https://github.com/apache/openmeetings/blob/5.0.0-M1/CHANGELOG.md

List of fixed issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312720&version=12342043

For more information on Apache Openmeeting please visit
project home page: http://openmeetings.apache.org

Apache OpenMeetings Team


Re: Could not connect to MariaDB

2019-04-03 Thread Maxim Solodovnik
Hello René,

after successful installation your mysql_persistense.xml file should be
copied to persistense.xml
Could you please check if persistense.xml have all necessary parameters?
1) correct DB host/port/name
2) correct DB credentials
3) this additional time-zone parameter

On Wed, 3 Apr 2019 at 16:28, R. Scholz 
wrote:

> Hm, since a few minutes the " The server time zone value 'CEST' "-error is
> back.
>
> I had change that after boot there is no GUI.
> sudo systemctl set-default multi-user.target
> and make a reboot.
>
> After that I get the installation-screen and on the scond screen with the
> Database-choice I get the error.
>
> A little bit frustrating.
>
> Best regards,
>
> René
>
>
> Am 03.04.2019 um 11:06 schrieb Maxim Solodovnik:
>
> Thanks for reporting back!
> great it works as expected :)
>
> On Wed, 3 Apr 2019 at 13:22, R. Scholz 
> wrote:
>
>> Hello Maxim,
>>
>> the result of "timedatectl":
>>   Local time: Mi 2019-04-03 08:06:21 CEST
>>   Universal time: Mi 2019-04-03 06:06:21 UTC
>> RTC time: Mi 2019-04-03 06:06:21
>>Time zone: Europe/Berlin (CEST, +0200)
>>System clock synchronized: no
>> systemd-timesyncd.service active: no
>>  RTC in local TZ: no
>>
>> Now I put the parameter you wrote helpful in your last email and it seems
>> to be functionally.
>>
>> Here is the fully parameter I actually use, if someone need it.
>>
>> > value="DriverClassName=com.mysql.cj.jdbc.Driver
>> ,
>> Url=jdbc:mysql://localhost:3306/openmeetings?autoReconnect=true&useUnicode=true&createDatabaseIfNotExist=true&characterEncoding=utf-8&connectionCollation=utf8_ge
>> , maxTotal=100
>> , maxIdle=100
>> , minIdle=0
>> , maxWaitMillis=1
>> , TestOnBorrow=true
>> , poolPreparedStatements=true
>> , serverTimezone=Europe/Berlin
>> , Username=
>> , Password=" />
>>
>> I am a little bit amazed about one thing: To test the new OM5 I made a
>> lot of times a new virtual machine with the same Ubuntu 18.04-Installation.
>> I mean that the
>> the first times the OM-MySQL-Connection runs without problems. No
>> modification necessary. Anytime the error Maxim describe occurs, and I dont
>> know why.
>> Sure, I made something different, but I have no idea what it can be.
>>
>> OK, for the moment I am very happy, get a gulp from my fresh/hot coffee
>> and look forward to test the newest modification Maxim implemented
>> yesterday in a speed where I am very surprised.
>> Maxim: Very good work!
>>
>> Best regards,
>>
>> René
>>
>>
>> Am 03.04.2019 um 05:25 schrieb Maxim Solodovnik:
>>
>> Just have tried to change TZ on my test Ubuntu server to be CEST and:
>>
>> *sudo timedatectl set-timezone CEST*
>> Failed to set time zone: Invalid time zone 'CEST'
>>
>> What is the result of `timedatectl` command on your system?
>>
>>
>> On Wed, 3 Apr 2019 at 07:35, Maxim Solodovnik 
>> wrote:
>>
>>> Hello René,
>>>
>>> I'll try to set up VM to test following steps (so here it is untested)
>>> 1) open
>>> ${OM_HOME}/webapps/openmeetings/WEB-INF/classes/META-INF/mysql_persistence.xml
>>> 2) find >> 3) add ", serverTimezone=Europe/Berlin" to the comma separated values
>>>
>>> run command line or web installer
>>>
>>> On Wed, 3 Apr 2019 at 02:16, R. Scholz
>>>  wrote:
>>> >
>>> > Hello,
>>> >
>>> > I dont know where I have to write what TimeZone-Variable.
>>> > I think it is the
>>> "/opt/open500/webapps/openmeetings/WEB-INF/classes/META-INF/mysql_persistence.xml".
>>> >
>>> > But where I have to write what to eliminate the "The server time zone
>>> value 'CEST' is unrecognized or..."-error?
>>> >
>>> > Best regards,
>>> >
>>> > René
>>> >
>>> >
>>> >
>>> >
>>> > Am 02.04.2019 um 07:35 schrieb Maxim Solodovnik:
>>> >
>>> > Hello All,
>>> >
>>> > recently I got error report from Alvaro regarding DB connection issue
>>> while MariaDB us used
>>> > After some "email ping-pong" I got logs, relevant part of logs can be
>>> found here [1]
>>> >
>>> > The first, huge stack trace provides only general information: "Could
>>> not create connection to database server. Attempted reconnect 3 times.
>>> Giving up."
>>> > Nothing to work with
>>> >
>>> > BUT the second one states: "The server time zone value 'CEST' is
>>> unrecognized or represents more than one time zone. You must configure
>>> either the server or JDBC driver (via the serverTimezone configuration
>>> property) to use a more specifc time zone value if you want to utilize time
>>> zone support."
>>> >
>>> > This one provides the root cause of the problem and possible solutions:
>>> > 1) change server TZ to be more specific i.e. Europe/Berlin (not CEST)
>>> > 2) edit persistense.xml file and add `serverTimezone` configuration
>>> property with TZ of MariaDb server
>>> >
>>> > Hope it can help
>>> >
>>> > [1]
>>> > java.sql.SQLNonTransientConnectionException: Could not create
>>> connection to databa

Re: Could not connect to MariaDB

2019-04-03 Thread R. Scholz
Hm, since a few minutes the " The server time zone value 'CEST' "-error 
is back.


I had change that after boot there is no GUI.
sudo systemctl set-default multi-user.target
and make a reboot.

After that I get the installation-screen and on the scond screen with 
the Database-choice I get the error.


A little bit frustrating.

Best regards,

René


Am 03.04.2019 um 11:06 schrieb Maxim Solodovnik:

Thanks for reporting back!
great it works as expected :)

On Wed, 3 Apr 2019 at 13:22, R. Scholz 
> wrote:


Hello Maxim,

the result of "timedatectl":
  Local time: Mi 2019-04-03 08:06:21 CEST
  Universal time: Mi 2019-04-03 06:06:21 UTC
    RTC time: Mi 2019-04-03 06:06:21
   Time zone: Europe/Berlin (CEST, +0200)
   System clock synchronized: no
systemd-timesyncd.service active: no
 RTC in local TZ: no

Now I put the parameter you wrote helpful in your last email and
it seems to be functionally.

Here is the fully parameter I actually use, if someone need it.



I am a little bit amazed about one thing: To test the new OM5 I
made a lot of times a new virtual machine with the same Ubuntu
18.04-Installation. I mean that the
the first times the OM-MySQL-Connection runs without problems. No
modification necessary. Anytime the error Maxim describe occurs,
and I dont know why.
Sure, I made something different, but I have no idea what it can be.

OK, for the moment I am very happy, get a gulp from my fresh/hot
coffee and look forward to test the newest modification Maxim
implemented yesterday in a speed where I am very surprised.
Maxim: Very good work!

Best regards,

René


Am 03.04.2019 um 05:25 schrieb Maxim Solodovnik:

Just have tried to change TZ on my test Ubuntu server to be CEST and:

*sudo timedatectl set-timezone CEST*
Failed to set time zone: Invalid time zone 'CEST'

What is the result of `timedatectl` command on your system?


On Wed, 3 Apr 2019 at 07:35, Maxim Solodovnik
mailto:solomax...@gmail.com>> wrote:

Hello René,

I'll try to set up VM to test following steps (so here it is
untested)
1) open

${OM_HOME}/webapps/openmeetings/WEB-INF/classes/META-INF/mysql_persistence.xml
2) find mailto:rene.sch...@abakus-edv-systems.de>> wrote:
>
> Hello,
>
> I dont know where I have to write what TimeZone-Variable.
> I think it is the

"/opt/open500/webapps/openmeetings/WEB-INF/classes/META-INF/mysql_persistence.xml".
>
> But where I have to write what to eliminate the "The server
time zone value 'CEST' is unrecognized or..."-error?
>
> Best regards,
>
> René
>
>
>
>
> Am 02.04.2019 um 07:35 schrieb Maxim Solodovnik:
>
> Hello All,
>
> recently I got error report from Alvaro regarding DB
connection issue while MariaDB us used
> After some "email ping-pong" I got logs, relevant part of
logs can be found here [1]
>
> The first, huge stack trace provides only general
information: "Could not create connection to database server.
Attempted reconnect 3 times. Giving up."
> Nothing to work with
>
> BUT the second one states: "The server time zone value
'CEST' is unrecognized or represents more than one time zone.
You must configure either the server or JDBC driver (via the
serverTimezone configuration property) to use a more specifc
time zone value if you want to utilize time zone support."
>
> This one provides the root cause of the problem and
possible solutions:
> 1) change server TZ to be more specific i.e. Europe/Berlin
(not CEST)
> 2) edit persistense.xml file and add `serverTimezone`
configuration property with TZ of MariaDb server
>
> Hope it can help
>
> [1]
> java.sql.SQLNonTransientConnectionException: Could not
create connection to database server. Attempted reconnect 3
times. Giving up.
> at

com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:110)
> at

com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
> at

com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:89)
> at

com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:63)
> at

com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:73)
> at

com.mysql.cj.jdbc.ConnectionImpl.connectWithRetries(ConnectionImpl.java:905)
> at
com.mysql.cj.jdbc.

Re: Could not connect to MariaDB

2019-04-03 Thread Maxim Solodovnik
Thanks for reporting back!
great it works as expected :)

On Wed, 3 Apr 2019 at 13:22, R. Scholz 
wrote:

> Hello Maxim,
>
> the result of "timedatectl":
>   Local time: Mi 2019-04-03 08:06:21 CEST
>   Universal time: Mi 2019-04-03 06:06:21 UTC
> RTC time: Mi 2019-04-03 06:06:21
>Time zone: Europe/Berlin (CEST, +0200)
>System clock synchronized: no
> systemd-timesyncd.service active: no
>  RTC in local TZ: no
>
> Now I put the parameter you wrote helpful in your last email and it seems
> to be functionally.
>
> Here is the fully parameter I actually use, if someone need it.
>
>  value="DriverClassName=com.mysql.cj.jdbc.Driver
> ,
> Url=jdbc:mysql://localhost:3306/openmeetings?autoReconnect=true&useUnicode=true&createDatabaseIfNotExist=true&characterEncoding=utf-8&connectionCollation=utf8_ge
> , maxTotal=100
> , maxIdle=100
> , minIdle=0
> , maxWaitMillis=1
> , TestOnBorrow=true
> , poolPreparedStatements=true
> , serverTimezone=Europe/Berlin
> , Username=
> , Password=" />
>
> I am a little bit amazed about one thing: To test the new OM5 I made a lot
> of times a new virtual machine with the same Ubuntu 18.04-Installation. I
> mean that the
> the first times the OM-MySQL-Connection runs without problems. No
> modification necessary. Anytime the error Maxim describe occurs, and I dont
> know why.
> Sure, I made something different, but I have no idea what it can be.
>
> OK, for the moment I am very happy, get a gulp from my fresh/hot coffee
> and look forward to test the newest modification Maxim implemented
> yesterday in a speed where I am very surprised.
> Maxim: Very good work!
>
> Best regards,
>
> René
>
>
> Am 03.04.2019 um 05:25 schrieb Maxim Solodovnik:
>
> Just have tried to change TZ on my test Ubuntu server to be CEST and:
>
> *sudo timedatectl set-timezone CEST*
> Failed to set time zone: Invalid time zone 'CEST'
>
> What is the result of `timedatectl` command on your system?
>
>
> On Wed, 3 Apr 2019 at 07:35, Maxim Solodovnik 
> wrote:
>
>> Hello René,
>>
>> I'll try to set up VM to test following steps (so here it is untested)
>> 1) open
>> ${OM_HOME}/webapps/openmeetings/WEB-INF/classes/META-INF/mysql_persistence.xml
>> 2) find > 3) add ", serverTimezone=Europe/Berlin" to the comma separated values
>>
>> run command line or web installer
>>
>> On Wed, 3 Apr 2019 at 02:16, R. Scholz
>>  wrote:
>> >
>> > Hello,
>> >
>> > I dont know where I have to write what TimeZone-Variable.
>> > I think it is the
>> "/opt/open500/webapps/openmeetings/WEB-INF/classes/META-INF/mysql_persistence.xml".
>> >
>> > But where I have to write what to eliminate the "The server time zone
>> value 'CEST' is unrecognized or..."-error?
>> >
>> > Best regards,
>> >
>> > René
>> >
>> >
>> >
>> >
>> > Am 02.04.2019 um 07:35 schrieb Maxim Solodovnik:
>> >
>> > Hello All,
>> >
>> > recently I got error report from Alvaro regarding DB connection issue
>> while MariaDB us used
>> > After some "email ping-pong" I got logs, relevant part of logs can be
>> found here [1]
>> >
>> > The first, huge stack trace provides only general information: "Could
>> not create connection to database server. Attempted reconnect 3 times.
>> Giving up."
>> > Nothing to work with
>> >
>> > BUT the second one states: "The server time zone value 'CEST' is
>> unrecognized or represents more than one time zone. You must configure
>> either the server or JDBC driver (via the serverTimezone configuration
>> property) to use a more specifc time zone value if you want to utilize time
>> zone support."
>> >
>> > This one provides the root cause of the problem and possible solutions:
>> > 1) change server TZ to be more specific i.e. Europe/Berlin (not CEST)
>> > 2) edit persistense.xml file and add `serverTimezone` configuration
>> property with TZ of MariaDb server
>> >
>> > Hope it can help
>> >
>> > [1]
>> > java.sql.SQLNonTransientConnectionException: Could not create
>> connection to database server. Attempted reconnect 3 times. Giving up.
>> > at
>> com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:110)
>> > at
>> com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
>> > at
>> com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:89)
>> > at
>> com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:63)
>> > at
>> com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:73)
>> > at
>> com.mysql.cj.jdbc.ConnectionImpl.connectWithRetries(ConnectionImpl.java:905)
>> > at com.mysql.cj.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:830)
>> > at com.mysql.cj.jdbc.ConnectionImpl.(ConnectionImpl.java:455)
>> > at com.mysql.cj.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:240)
>> > at
>> com.mysql.cj.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:199)
>> >