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 -- Peter Boy https://fedoraproject.org/wiki/User:Pboy 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
