It doesn't stop at step 5 creating such a strange output DEBUG 10-13 19:14:50.827 o.a.o.u.c.CryptProvider:39 [Bean#0_Worker-9] - get:: configKeyCryptClassName: null DEBUG 10-13 19:15:05.827 o.a.o.u.c.CryptProvider:39 [ean#0_Worker-10] - get:: configKeyCryptClassName: null DEBUG 10-13 19:15:20.829 o.a.o.u.c.CryptProvider:39 [Bean#0_Worker-7] - get:: configKeyCryptClassName: null DEBUG 10-13 19:15:35.826 o.a.o.u.c.CryptProvider:39 [Bean#0_Worker-1] - get:: configKeyCryptClassName: null DEBUG 10-13 19:15:50.828 o.a.o.u.c.CryptProvider:39 [Bean#0_Worker-8] - get:: configKeyCryptClassName: null DEBUG 10-13 19:16:05.827 o.a.o.u.c.CryptProvider:39 [Bean#0_Worker-4] - get:: configKeyCryptClassName: null WARN 10-13 19:16:15.820 o.a.o.d.d.b.ConfigurationDao:139 [Bean#0_Worker-3] - Could not find key in configurations: number.minutes.reminder.send DEBUG 10-13 19:16:20.826 o.a.o.u.c.CryptProvider:39 [Bean#0_Worker-5] - get:: configKeyCryptClassName: null DEBUG 10-13 19:16:35.827 o.a.o.u.c.CryptProvider:39 [ean#0_Worker-10] - get:: configKeyCryptClassName: null DEBUG 10-13 19:16:50.827 o.a.o.u.c.CryptProvider:39 [Bean#0_Worker-7] - get:: configKeyCryptClassName: null DEBUG 10-13 19:17:05.826 o.a.o.u.c.CryptProvider:39 [Bean#0_Worker-2] - get:: configKeyCryptClassName: null DEBUG 10-13 19:17:20.827 o.a.o.u.c.CryptProvider:39 [Bean#0_Worker-6] - get:: configKeyCryptClassName: null DEBUG 10-13 19:17:35.827 o.a.o.u.c.CryptProvider:39 [Bean#0_Worker-8] - get:: configKeyCryptClassName: null DEBUG 10-13 19:17:50.826 o.a.o.u.c.CryptProvider:39 [Bean#0_Worker-4] - get:: configKeyCryptClassName: null WARN 10-13 19:17:55.820 o.a.o.d.d.b.ConfigurationDao:139 [Bean#0_Worker-3] - Could not find key in configurations: number.minutes.reminder.send DEBUG 10-13 19:18:05.827 o.a.o.u.c.CryptProvider:39 [Bean#0_Worker-5] - get:: configKeyCryptClassName: null
It never asked for a password though. Am Di., 13. Okt. 2020 um 18:44 Uhr schrieb Maxim Solodovnik < solomax...@gmail.com>: > OK > > try to > > 1) enter the machine > 2) stop everything that works on it: `sudo killall java` > 3) in NEW EMPTY folder `tar -xzf apache-openmeetings*` > 4) cd apache-openmeetings* > 5) `./admin.sh -i -v -user ui_admin -email someem...@gmail.com -tz > "Asia/Tehran" -group "yourgroup"` enter password > 6) `./bin/catalina.sh run` > 7) check https://your-ip:5443/openmeetings > (no other steps please) > > what is the result? > > On Tue, 13 Oct 2020 at 23:40, K. Kamhamea <kamha...@googlemail.com> wrote: > >> gpg --verify apache-openmeetings-5.0.1.tar.gz.asc >> apache-openmeetings-5.0.1.tar.gz >> gpg: Signature made Sat 19 Sep 2020 07:18:08 AM CEST >> gpg: using RSA key 15EB59354EBF43E3A6314BEBE8302FC78456901E >> gpg: Good signature from "Maxim Solodovnik <solo...@apache.org>" >> [unknown] >> gpg: WARNING: This key is not certified with a trusted signature! >> gpg: There is no indication that the signature belongs to the >> owner. >> Primary key fingerprint: 15EB 5935 4EBF 43E3 A631 4BEB E830 2FC7 8456 >> 901E >> >> Any Ideas? >> >> Am Di., 13. Okt. 2020 um 18:03 Uhr schrieb Thomas Scholzen < >> tschol...@buche17.de>: >> >>> Look at "about" on the login page. >>> >>> >>> >>> Am 13.10.2020 18:00, schrieb K. Kamhamea: >>> >>> > you can check the signature >>> I have no idea how I can do that. Where is the signature stored? >>> >>> > any chance your requests to new server are routed to some older one? >>> No, as I can follow the log (tail -f ./logfile) and and I see exactly my >>> requests there. >>> >>> Am Di., 13. Okt. 2020 um 17:54 Uhr schrieb Maxim Solodovnik < >>> solomax...@gmail.com>: >>> >>> you can check the signature >>> any chance your requests to new server are routed to some older one? >>> Or something cashed in the browser (I doubt it is possible ...) >>> >>> On Tue, 13 Oct 2020 at 22:51, K. Kamhamea <kamha...@googlemail.com> >>> wrote: >>> >>> That's interesting. >>> I downloaded the file from >>> >>> sudo wget >>> https://downloads.apache.org/openmeetings/5.0.1/bin/apache-openmeetings-5.0.1.tar.gz >>> >>> as described in Alvaro's tutorial. And the file downloaded that still >>> resides in the folder says >>> >>> /opt # dir >>> apache-openmeetings-5.0.1.tar.gz >>> >>> Is exactly that. I also can rule out the possibility that some older >>> version resided on that server because it is a fresh new server. >>> >>> Did someone hack into that file? >>> >>> Best K >>> >>> Am Di., 13. Okt. 2020 um 17:35 Uhr schrieb Maxim Solodovnik < >>> solomax...@gmail.com>: >>> >>> Hello K. >>> >>> well, your screen-shots are not from 5.0.1 :( >>> please check the latest UI here >>> https://om.alteametasoft.com/openmeetings/ (it has the latest release >>> installed) >>> I can't reproduce both of your issues :( >>> >>> have you customized your OM? >>> Any details on your installation? >>> >>> On Tue, 13 Oct 2020 at 22:29, K. Kamhamea <kamha...@googlemail.com> >>> wrote: >>> >>> Second, when I press this button The USER and FILES tabs disappear for >>> ever. >>> >>> [image: grafik.png] >>> In M4 there was a button with arrows pointing in the opposite direction >>> that restored these tabs. This button has miraculously disappeared. >>> >>> Am Di., 13. Okt. 2020 um 17:25 Uhr schrieb K. Kamhamea < >>> kamha...@googlemail.com>: >>> >>> Thank you for this quick response. Sorry for the first problem. It is a >>> typo not "errors" but "arrows". I hope the picture is instructive and makes >>> it clear. >>> >>> [image: grafik.png] >>> >>> >>> Am Di., 13. Okt. 2020 um 17:18 Uhr schrieb Maxim Solodovnik < >>> solomax...@gmail.com>: >>> >>> Hello K >>> >>> On Tue, 13 Oct 2020 at 22:06, K. Kamhamea <kamha...@googlemail.com> >>> wrote: >>> >>> I just installed the new version on a test server following Alvaro's >>> instruction (without Coturn and Letsencrypt) on Ubuntu 20.04. I had the >>> version M4 running before with much less issues. >>> >>> 1. First thing that annoyed me was the fact that I cannot restore the >>> USERS and FILES tab once removed the to the right. >>> >>> >>> this make no sense, please provide steps to reproduce >>> >>> >>> 2. The FILES tab shows folders with moving errors only. I suppose this >>> signals some failure. Upload is impossible too. Though I can see the file >>> in the folder, an exclamation mark signals some error, and I cannot drag it >>> on to the whiteboard. >>> >>> >>> same here >>> what is "moving errors? since upload is impossible what in the >>> logs/browser console? >>> I'm afraid no one can help you with this level of details :( >>> >>> >>> >>> I suppose the reason is some problem with permissions. I set the whole >>> OM folder to >>> chown -R nobody:nogroup ./OM-Folder >>> But nothing changed. >>> Best K. >>> >>> >>> >>> -- >>> Best regards, >>> Maxim >>> >>> >>> >>> -- >>> Best regards, >>> Maxim >>> >>> >>> >>> -- >>> Best regards, >>> Maxim >>> >>> > > -- > Best regards, > Maxim >
