Hello all,

Just as a short information: As much as I'd rather spend time working on 
OpenMeeting on Fedora, I have to do something for the buns in between :-). And 
the next Fedora release is coming up, I'm involved in that too. In the meantime 
I successfully installed the demo on a box in my homelab. And I plan to 
continue early next week with a fresh start of the installation following the 
tutorial. Something I may have overlooked there. I'll get back to you and I'm 
sure I'll have more questions, maybe successes, probably errors - we'll see.  


Thanks for all the information

Peter



 

> Am 27.09.2023 um 03:39 schrieb Maxim Solodovnik <solomax...@gmail.com>:
> 
> Hello All,
> 
> sorry for top posting :(
> The discussion is now a bit hard to follow :((
> 
> I have created my version of Coturn config based on this:
> https://stackoverflow.com/questions/35766382/coturn-how-to-use-turn-rest-api
> guide
> 
> It works for me for years :)
> 
> I also got warning regarding conflicting options, but have no time to
> investigate ...
> So I'm using what working :)
> 
> "kurento.turn.user" might be left blank but, if i remember correctly,
> it was useful for debugging and for TURN server testing
> 
> According to ports:
> 
> - port 8888 is KMS port, it might be left open in case you would like
> to allow your users to directly connect to media server, and reduce
> TURN server load
> 
> In fact TURN server might work as STUN i.e. can provide the way to
> establish connections between devices at private networks that can be
> behind firewalls)
> OR as TURN server: it can work as full proxy to pass multimedia to KMS
> 
> 
> I'm starting all OM related services under user nobody to make system
> more secure :)
> 
> @Peter,
> I've just have checked your set-up (can be done via video-testing app:
> https://148.251.152.52:5443/openmeetings/hash?app=settings)
> 
> And it seems your TURN server is EMPTY :(
> 
> have you restarted OM after openmeetings.properties modification? :)
> 
> On Wed, 27 Sept 2023 at 08:01, Guofeng Zhang <guofen...@gmail.com> wrote:
>> 
>> Hi,
>> 
>> I just installed OM 7.1.0 a few days ago, and I don’t know much about the 
>> various components of OM. A few notes for my situation:
>> 
>> lt-cred-mech: It shoul be commented out like "#lt-cred-mech", becuase here 
>> we use use-auth-secret.
>> 
>> kurento.turn.user=fedorian: It should be "kurento.turn.user=" the same 
>> reason as above.
>> 
>> Port range 49152-65535, it is used for video/audio streaming when 
>> conferencing, which coTrun bridge the steaming between the client and media 
>> server (here Kurento) in many case.
>> 
>> Best regards
>> 
>> Guofeng
>> 
>> 
>> 
>> On Wed, Sep 27, 2023 at 4:39 AM Peter Boy <p...@boy-digital.de> wrote:
>>> 
>>> Hi all,
>>> 
>>> For sake of simplicity, I answer to all mails in one go.
>>> 
>>> 
>>>> Am 26.09.2023 um 02:50 schrieb Guofeng Zhang <guofen...@gmail.com>:
>>>> 
>>>> Hi,
>>>> 
>>>> I met the same issue as yours after the installation. You please first 
>>>> verify if CoTurn is set up correctly. Using stunclient from 
>>>> https://www.stunprotocol.org/ to check if CoTurn setup correctly
>>>> stunclient <turnserverIp> 3478
>>>> It should prompt "Binding test: success" if the setup is ok.
>>> 
>>> Great hint. I got on a request from my desktop to the server:
>>> 
>>> Binding test: success
>>> Local address: 192.168.158.120:54174
>>> Mapped address: 87.150.96.84:54174
>>> 
>>> But the —-mode behavior test failed.
>>> 
>>> But obviously the basic functionality works.
>>> 
>>> 
>>>> IIf there is any error message prompted, you please verify if the 
>>>> following ports are opened by your firewall. For me, this is the root 
>>>> cause (I opened port 3478 UDP, but forgot opening port 3478 TCP).
>>>> 
>>>> 3478 TCP-UDP IN
>>>> 5443 TCP IN
>>>> 8888 TCP IN
>>>> 49152:65535 UDP IN-OUT
>>> 
>>> I think, the ports are OK:
>>> 
>>> [root@letsmeet ~]# firewall-cmd  --list-all
>>> FedoraServer (active)
>>>  target: default
>>>  icmp-block-inversion: no
>>>  interfaces: enp1s0
>>>  sources:
>>>  services: cockpit dhcpv6-client http https mdns ssh
>>>  ports: 5443/tcp 3478/tcp 3478/udp 8888/tcp 49152-65535/udp
>>>  protocols:
>>>  forward: yes
>>>  masquerade: no
>>> 
>>> The firewall blocks no outgoing traffic at all.
>>> 
>>> But I wandering about port 8888. As far as I get it, this port is for 
>>> communication between OM and Kurento using the localhost interface.
>>> 
>>> Or is there any incoming traffic from the clients?
>>> 
>>> And the Port range 49152-65535, Isn’t it used by Kurento initializing p2p 
>>> traffic to the clients. So Kurento is opening the port anyway?
>>> 
>>> 
>>> 
>>>> But if your CoTurn runs on a VM in a cloud lik AWS, you should google to 
>>>> know how to configure CoTurn specially, like:
>>>> external-ip=<my public ip>/<my private ip>
>>>> listening-ip=<my private ip>
>>>> relay-ip=<my private ip>
>>> 
>>> My VM is running on my own root Server in a data center. So that’s not a 
>>> problem here. But I take that for the Fedora Server documentation when I 
>>> manage to get it running.
>>> 
>>>> 
>>>> Hope the above is helpful to you.
>>> 
>>> Yes, it is. Thanks!
>>> 
>>> 
>>> 
>>> 
>>>> Am 26.09.2023 um 06:31 schrieb Maxim Solodovnik <solomax...@gmail.com>:
>>>> 
>>>>> …….
>>>> 
>>>> Our current demo server (and Dockerized Ubuntu 22) versions will work
>>>> with Dokerized KMS
>>>> KMS natively supports Ubuntu 20 only :(
>>>> 
>>>> TURN server (listening ports 3478 TCP+UDP  AND ports being used for
>>>> proxy 49152:65535 UDP IN-OUT) should be public
>>>> In all my configurations I'm using TURN at the same server as OM and KMS
>>>> 
>>>> Coturn config should be as simple as
>>>> https://lists.apache.org/thread/x4rl7xjq6fnfy6nyl5c6lhmp57fdf4br
>>> 
>>> The source says:
>>> fingerprint
>>> lt-cred-mech
>>> use-auth-secret
>>> static-auth-secret=******************************
>>> realm=om.alteametasoft.com
>>> stale-nonce=0
>>> proc-user=nobody
>>> proc-group=nogroup
>>> 
>>> I couldn’t switch the user to nobody. Fedora create a user coturn, so the 
>>> proc is not running with root privileges.
>>> 
>>> And regarding lt-cred-mech the docs say:
>>> 
>>> # Be aware that use-auth-secret overrides some parts of lt-cred-mech.
>>> # The use-auth-secret feature depends internally on lt-cred-mech, so if you 
>>> set
>>> # this option then it automatically enables lt-cred-mech internally
>>> # as if you had enabled both.
>>> #
>>> # Note that you can use only one auth mechanism at the same time! This is 
>>> because,
>>> # both mechanisms conduct username and password validation in different 
>>> ways.
>>> #
>>> # Use either lt-cred-mech or use-auth-secret in the conf
>>> # to avoid any confusion.
>>> #
>>> #use-auth-secret
>>> use-auth-secret
>>> 
>>> And the log gave a warning.
>>> 
>>> 
>>>> 
>>>> `openmeetings.properties` file should have
>>>> 
>>>> ### localhost IP in case KMS and OM are at the same server
>>>> kurento.ws.url=ws://127.0.0.1:8888/kurento
>>>> 
>>>> ### this URL must be *Public* IP+PORT, like 8.8.8.8:3478
>>>> kurento.turn.url=
>>>> 
>>>> ### can be any string, for ex: fedora-user
>>>> kurento.turn.user=
>>>> 
>>>> ### this one should match *static-auth-secret* fron coturn config
>>>> kurento.turn.secret=
>>>> 
>>>> kurento.turn.mode=rest
>>>> 
>>> 
>>> My Kurento section is now:
>>> 
>>> ################## Kurento ##################
>>> kurento.ws.url=ws://127.0.0.1:8888/kurento
>>> kurento.turn.url=148.251.152.52:3478
>>> kurento.turn.user=fedorian
>>> kurento.turn.secret=500647a15be4f9cef63a8a5208042cfbfbc50f6ac28b1c10f901ee1caedf8421
>>>   kurento.turn.mode=rest
>>> ## minutes
>>> kurento.turn.ttl=60
>>> ## milliseconds
>>> kurento.check.timeout=10000
>>> ## milliseconds
>>> kurento.object.check.timeout=200
>>> kurento.watch.thread.count=10
>>> kurento.flowout.timeout=5
>>> ## please ensure this one is unique, better to regenerate it from time to 
>>> time
>>> ## can be generated for ex. here https://www.uuidtools.com
>>> kurento.kuid=df992960-e7b0-11ea-9acd-337fb30dd93d
>>> ## this list can be space and/or comma separated
>>> kurento.ignored.kuids=
>>> ## See 
>>> https://doc-kurento.readthedocs.io/en/latest/features/security.html#media-plane-security-dtls
>>> ## possible values: RSA, or ECDSA (capital-case)
>>> kurento.certificateType=
>>> 
>>> 
>>> 
>>>> hope this helps :)
>>> 
>>> 
>>> It does, yes, although I still get the error message:
>>> ERROR: check_stun_auth: Cannot find credentials of user 
>>> <1695739559:67d394d7-ceba-4db4-b543-fa0d01c1e5c7>
>>> 
>>> 
>>> a)
>>> As far as I know now, the configuration is OK. So the reason should be 
>>> somewhere else.
>>> 
>>> Question: what triggers the error message?
>>> 
>>> Is kurento addressing coturn with that user name and coturn can’t not find 
>>> the data or is it vice versa and coturn is addressing kurento and is asked 
>>> by kurento for the credential for that user?
>>> 
>>> Or is open meeting addressing coturn?
>>> 
>>> 
>>> b)
>>> Maybe I should leave coturn out for now and use an external turn server. 
>>> You said OM container is configured this way.  How do I need to configure 
>>> OM to make this work?
>>> 
>>> 
>>> c)
>>> Is there a diagram somewhere of how the communication between the 
>>> components involved, OM, kurento and coturn,  works?
>>> 
>>> 
>>> 
>>> 
>>>> Am 26.09.2023 um 11:07 schrieb Alvaro <zurca...@gmail.com>:
>>>> 
>>>> 
>>>> ...this dd USB stick burn works for me on Mac:
>>>> 
>>>> 
>>>> ========
>>>> 
>>>> sudo diskutil list
>>>> 
>>>> ...look for your pendrive...
>>>> 
>>>> 
>>>> sudo diskutil unmountDisk /dev/diskN
>>>> 
>>>> ...replace last N for your pendrive number-disk...
>>>> 
>>>> 
>>>> sudo dd if=./Live_OpenMeetings_7.1.0_on_Ubuntu_18.04_lts.iso  
>>>> of=/dev/diskN bs=1m
>>>> 
>>>> ...replace last N for your pendrive number-disk
>>>> and fill the empty spaces in the name "Live OpenMeetings 7.1.0...."
>>>> 
>>>> 
>>>> When finish will show something similar to this:
>>>> 
>>>> 88+0 records in
>>>> 388+0 records out
>>>> 406847488 bytes transferred in 94.024237 secs (4327049 bytes/sec)
>>>> 
>>>> =============
>>> 
>>> Thanks, you are right. I found the reason. All the test boxes in my homelab 
>>> are EFI systems. And EFI can’t boot a CD image, because there is no boot 
>>> code before the partition anymore. A friend of mine pointed that out.
>>> 
>>> After I managed to reconfigure one of the boxes to mimic a „legacy“ system 
>>> with BIOOS boot, it worked. And I have a nice OpenMeetings desktop GUI.
>>> 
>>> I suppose, many people now have an EFI system. Maybe, you should add a hint 
>>> to the description.
>>> 
>>> 
>>> 
>>>> # Respect to configuration Turn server and other,
>>>> only can say...please follow pdf tutorial. There
>>>> is any information.
>>> 
>>> 
>>> I try my best. Unfortunately, something unknown to me is going wrong. 
>>> Maybe, I should restart from scratch.
>>> 
>>> A question: Could you make a VM image (raw or qcow2) from your Fedora 
>>> installation or is it already a VM?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Thank you all for your great help. I am still confident to get OpenMeeting 
>>> running reliably and reproducibly on Fedora Server.
>>> 
>>> 
>>> Peter
>>> 
>>> 
>>> 
> 
> 
> -- 
> Best regards,
> Maxim
> 

--
Peter Boy

p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast




Reply via email to