From my experience, I don’t think a reinstall will over write, but if you delete your old Jitsi folders or build a new server, then the reinstall would have to recreate the new files.
I would build a second server and then take a clean copy of its config files from the second server, delete the second server, and restore or modify my original jitsi server based on the copy I made of the second server.
I am curious, as to which config files you are thinking about? Is it the ones ones in /etc/jitsi ?
As I use virtual machines, I can easily spin up another server for testing and delete it later. I don’t use the server so much that I have to keep it running 24/7, I can turn off my production server and spin up another test server in its place for a few hours and then take it down and put the production server back up.
If it was me, I would take a backup/copy of all files/folders under /etc/jitsi and then delete all files and folders in /etc/jitsi, then follow the instructions for removing and reinstalling (if you have not seen these at the end of the install please let me know and I will send you a link). # rm -rf /etc/jitsi (only after taking a backup of these files and folders)
As others have pointed out, the default configs works well out of the box and is always a good start.
I’ve been down that road. I made trial-and-error changes based on configs from friends, and from snippets from different forum posts until things kinda worked. And then it doesn’t and it is hard to tell what has been customised or what configs you have in place is actually applicable since Jitsi configs do evolve over time.
Here’s what I do now:
I always do fresh installs instead of in-place upgrades (so I can test new version before replacing live instance), and I always keep a backup of the original configs that were created by a fresh install. This gives me 3 versions of configs files when building a new instance:
“live configs” – config I am using on my live instance running on previous Jitsi version
“old defaults” – default config installed by previous version of Jitsi package
“new defaults” – default config installed by latest version of Jitsi package
This allows me to:
Diff old defaults vs new defaults, giving me a view of which configs have been added, removed, have new comments, or have new values.
For anything that has changed, I can then find out more about how it might be applicable to my deployment
If a config has not changed, then I know my live config can be applied verbatim
Diff “live configs” vs “old defaults”, giving me a list of customisations that I have made.
Very useful during debugging to answer question like “what have I changed that might have broken this”
Also useful when previous step shows lots of diffs between old and new defaults – sometimes cleaner to reapply customisation to new fresh version than porting diffs to customised old config.
Yes, this is an elaborate process and by no means something I am pushing as a recommended approach. But it works for me, for now. As you mentioned, there are lots of customization options and can be overwhelming; so started with defaults, tweak it over time, then use this process to keep track of ongoing changes. YMMV.
Two steps forward, one step backwards.
1- I was running openjdk 16.
2- successfully installed openjdk11.
3- where do I find the jvm.log??? Today I couldn’t find the file. (And I didn’t write a note where I found the file two days ago.)
Jitsi is running. Onward with the testing. I hope my other app is happy with openjdk 11.
I finally had a 8 user test. FAIL!
We all could see ourselves! Camera compatibility is working much better.
We all see the other participants as if the camera was off. We could not see each others video.
I hope some one can help me understand this log. jvb.log (6.4 KB)
Your jvb is announcing only its internal ip address and clients cannot reach it.
Do you have this line org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443 in your jvb config in /etc/jitsi/videobridge/sip-communicator.properties?
Thank you for your suggestion. However I don’t know how to interpret what you suggest.
1- can I just open 3 tabs in chrome pointed to google?
2- “client js console” - does this mean I want to look at js console of Chrome?
Are you suspecting that. all 8 users were having js errors?