 So, part of the objective was to have GZ video conferencing on OpenBSD and to have a development environment where I can prove that all of the needed core components can be isolated. So there's no magic discovery or hidden communication, whatever, which would bite you when you try to scale out later on. So all the communication channels would be known. And to realize that I was using one bare metal machine with OpenBC, of course, and then VMM configuration to have four virtual machines for the four basic components that you need for providing a simple basic GZ video conferencing session. On OpenBSD side, a well-known VMM, nothing special here. VMC tells for controlling the VMs and the VM.conf I'm showing on how to define them. And on the GZ side, you just have a web server that can do reverse proxing of HTTP and then an XMPP server. And for, given the reference implementation, they have prosities, the, let's say, natural choice for that. From GZ itself, there's Chacovo, the GZ conference focus server, who manages all the requests about who's needing a web conference, who is talking to whom in which room, and can also assign then the needed video breaches, which is the next component, which is an SFU for all the media streams that are going out to the browser. So it's not messing up between the conferences that might be running in parallel. So that one decides, Chacovo decides which JVP is connected to, which user. And an additional thing what most people want is GZ, the GZ broadcasting infrastructure for recording those conferences and streaming them out to YouTube. And for whatever reasons that part YouTube is hard coded. So you cannot use something, something else right now. They say they will make in making it up more generic, but that's the to do list for the last three years or something. I skipped a little bit. So that's the needed TCP-IP networking you actually need. If you go to the default installation instructions, you would see an architecture of maybe 12 components and then maybe three communication channels between all those and that is just overflowing the people's mind. But this is what you actually need. So the browser to the web server and proxy to BROCID and a connection to the video bridge. That's all you need. On the internal side of GZ, there's just the video bridges. Here I've chosen to for showing a bit of scale out and an external GZ bridge recorder. And they are going all to present, advertise their presence, their health to to BROCID and Chacovo is just subscribing to that channel and pulling in health information like I have an unallocated video bridge I could use for the next web conference request. This one didn't work. That's just the install step. So we'll skip those a bit, a bit more briefly. So we are creating just a basic OpenSD installed system into a Q-Card 2 image and then copy it over for all the four machines. And with this, VM.conf, those four machines are being brought up with a local, local networking setup. So that's all you need. Of course, all those VMs could run on their own bare metal machine. There is no hidden or implicit communications channel, which would only work on VMM based machines, or that would be a valid architecture for having four VPS machines to a digital erosion and to a head snore. So that would still work with the setup. The one thing you want to have for less typing or whatever is a host entry. And there will be way more FQTNs, but you only need one DNS entry. And this is for more or less your main URL. And everything else is not only optional, but maybe you really do not want to have that, because that can have really bad side effects. So only add more DNS entries if you really know what you're doing, because you are shifting gear to completely different spaces. On the firewall side, I will skip that a bit. But all the configuration is that way that in both directions, BF is blocking, and we are allowing really only the needed communication channels inbound and outbound. And if you just cut them all together, you could just make that happen for a local whole everything on local host machine. So we need access to the web server to the Java video bridge over 10,000 UDP, the communication between the cheesy parts and crossity, hnx to crossity, of course, and then you can have also debug connections. Web server needs those two inbound and this one outbound. On the crossities side, the XMPP ports, the 5222 that's used for the internal communication with start TLS and all that. So Jack Kofo and JVB connecting there. And the other part is the Bosch or WebSocket request coming from the engine X web server to crossity. Outbound becoming inbound and the other way around. So that's just flipped over. And the video bridge is exposing a monitoring and metrics interface on 8080. So you want to restrict that if you need it at all. And the same is with Jack Kofo, which is only communicating internally. So you can have only the XMPP port to XMPP. And the health and metrics endpoint is documented on four times eight. And there is something listening a web server or jet the web server, but it's on always returning for four. So it's broken. And I had no time to research what's happening over there. On the crossities side, we need two more modules that's mainly for authentication for Jack Kofo. And there's no additional configuration in Brossody needed along that. And for Brossody itself, the main thing is to have HTTP interfaces or HTTPS because otherwise in default configuration, Brossody will only listen on local host. And that's not very useful when you're coming from a different machine to it. And the two modules you really, really need is of course, Bosch and PubSoup or PubSub. Bosch is the client protocol. They are like either the Mobeck element client or the web browser and Brossody itself. And PubSub is that part that the video bridge and Jack Kofo is using. SSL enabling is pretty painless. I will show that in a second. And you see already we have an additional virtual host, but it's really a virtual host. So please know additional DNS for off GTS. Then there's a component for the chat within the web conference. There's always a little sidebar if you enable that. You need a component registration for that being type multi user chat. This component entry is only the authentication credentials for the Java, Chizzi video bridge. And the new model of authentication here is the aforementioned client proxy. And it's using this username at this realm. Again, no DNS entry for that. Think of virtual host or realm. And this one is almost the same. But here we are talking about that part that Jack Kofo recognizes the British subscriptions. When they say we are available to handle video conferencing, then they will join this multi user chat and have something like a special signaling. Hi, I'm here. Please abuse me. And they might change from, they might change with the next release in the video bridge from this authentication scheme to this one. So if it suddenly stops working, check here. So we can create further user authentication, JVB. We had already seen as a component with a component secret. Focus Jack Kofo is using a real user. So we enable and start varsity, and then we register the user where change focus is the password. And then the subscription. I'm unsure what it's doing under the hood because it's brand new in Chizzi terms. I have had no time to look at what's happening in detail, but it's needed. So it's written on here. On terms of TLS, Java is not using ETC SSL certs directory or whatever. So you need your own part called a key store. This is the command to create such a thing. With prosody CTL search generate, you are running more or less a wrapper about open SSL request. So you get that dialogue, or whatever tool you want to have to just have a standard X5 or nine certificate request and self sign it. And this CRT file can be imported into a key store with this key to command. And you have to copy that result check over key dot store to the Chizzi Kofo VM and JVB key store, which is the same file anyway, to the JVB VM. While you do it the other way around, you copy over the CRT file and create the store files on their VM, respectively. What you really should not do is fiddling within the JDK installation itself with CA certs, the next update and you are dead. With that functionality. The Chizzi installer for DB and all in one VM is exactly doing that. So for the web server, that's a network configuration and for the software installations or Nginx, it's just a simple package ad, of course. And we can use the OpenSD Acme client for Let's Encrypt. And what we created, it was committed three days ago, something in current is Chizzi Meet. I have a bonus slide and now I can show it. How to backport it for 7.1, it should even work on 7.0. You just have to recompile or repackage the whole thing. It takes even on a slow machine, maybe 20 minutes to create the Java part. Chizzi Meet itself is just, I think, 10 megabytes of JavaScript, PNG files, MP3s for the sound effects and all that. So that's pretty quick. And Nginx configuration for using that. Of course you need a virtual host server name. Wow, Chizzi Meet is populated with that package ad. So that's already in place where it needs to be. You need server side include that client configuration is in the file system. It's a JavaScript file called config.js, I'm showing in a second. And that will be included into the delivered index page. So the client has a configuration where to look at. And these web pages are loading JavaScript, CSS and all this stuff from the file system. Again, wow, Chizzi Meet. And so that is accessed and delivered properly. External API chairs is for the element mobile client tool that's more or less legacy support until they are changing the mobile client to config.js or whatever. The connection from the web server to the prosody machine is a simple proxy pass with this HTTP bind as being the magic string here. And who can tell me what this one is doing? Who's running Chizzi? No one. Right. So that's just a regex and it's more or less saying we match everything that's likely a typical URI path. And if that happens, we just throw it away and we stop evaluation. Why would we do that? Well, in Chizzi, everything after or as a URI path you start with slash whatever, then whatever is your conference name. But whatever is not matching this location and it's not matching anything in the file system. So it would produce in four or four. And this one is just saying, no, just keep it under the rock. But the JavaScript knows that it was at the requested path. And so they can operate and then they are fiddling that information on different means by not just the plain HTTP request, that's the old trickery in here. The more you know. So that's the full configuration minus the dot well-known handling, that's just another three, four lines, but a slide is just that big. But it's in the GitHub repo included. On that very config.js, you have the domain in which you are operating and then you call what's the name of the user chat. But again, no DNS here, not needed and not not advisable. But otherwise it might run to a completely different location. So that's not nice for Bosch. Just the same. That's seamless. But actually, you could use HTTPS over here because you need HTTPS otherwise Chrome and Firefox and all those won't ever start your camera because that's unsecure. Turn UDP typically false, but if you are on double-sided not and whatever, you might try to turn that to true. If stuff improve is done, if not, you are in uncharted territory or at least difficult ones and you can have an welcome page or not where either you say you are only offering fixed conference names or you have a welcome page where everybody can start a conference with their name of choice. And also for that, you can enable or disable certain set settings. For example, by phone dial-in because I hate that. So it's not working. I have no information just to remove the button. Also in relation to NAT environments, STAN servers, here you might have to check. I don't know if this one is actually passed, but some of such information from the client could end up in the back end and then used from there to remember about restricted outbound connections. So it might happen that the video bridge is trying something in this regard. So always lock outbound connections, especially if it doesn't work. When you were using STAN, was there a particular part of the JITC? What STAN is doing here is more or less trying to figure out which side is NAT-ed and if both who has which public IP address and then telling the other side what is your public IP address and port for the upcoming connection. So it's something like NAT discovery, whatever. What's my IP address from server side and from client side and then both topples to each other? So that's the configuration in full. The default configuration file where you have all the comments in there. So it's not the default, but more or less the let's explain everything is almost 200 lines, but that's what you need. So as you can see, we have created packages for JCOFO and JVB. And this is installing not only the char file, which comes with already all dependencies included a so-called fat char. So you do not have to run or fetch char from somewhere else, but the package builder is responsible to have one nice big fat char, but it includes all the things and you are not running into wild dependency failures or whatever. And this one needs some configuration. Naturally, and this configuration is for the startup script. So we are providing an RC script so we can use RCCTL later on and you do not have to start nohab, java, dash char, whatever wild thingies, but you have a configuration file for the RCCTL startup script where to find the main configuration, the logging for it. And we are also using the standard demon logging via syslog. So that's a default already. And what you can enable in here for the real hefty debug stuff is, for example, an XMPP packet debug log. So you can see what's happening in this internal Muck channel, where JCOFO is checking for are there any video pages? Are they healthy? Are they gone? Are they allocated? And if you suspect that there's something wrong, you can look into that one. And that's just commented in here so you can use that easily. Here's the key store I've been talking about with key tool and it's password. So that's a clear reference and not it's using something, some places, but really a fixed location. And then java properties or JVM properties like how much heap to use SSL key sizes. So the internal communication right now with this setup is TLS version 1.3 everywhere, even the internal communications and from external as well. And if you need something fine tuning of like minus capital D and then some garbage collector, fine tuning stuff or so you can do that in Javasys props. The startup script is passing that on verbatim to the JVM later on. So the JCOFO configuration, it is a bit shortened. I have the full configuration is maybe 30 lines, 24, whatever. Also in the GitHub repo, two things really notable is that JVB brewery is a magic string. Do not change it. You can change almost everything in those settings if they're as long as they are in sync, but JVB brewery is some considered magic, whatever. Almost the same area, the XMPB connection name can only be client or server and please written with a capital C or S, but the actual client definition has to be with a lowercase C or S if you're using server here. And you have to disable SCTP on OpenBSD or any non-linux machine more or less. That's more for completeness right now, since this will be replaced in future setups or versions from the JCOFO and JVB as well with web sockets. Then the real username passwords and everything coming in via this authentication real will be considered a useful member of the Chitty community services. Let's put it this way. And then there's one pet peevee with me like their default self-hosting guide, whatever assumes you have not only all the components on one VPS or one machine at all, it also is directly connected with a public, with a public external reachable address and whatever and everything is pointing to that. And so for the startup of JCOFO, you need to point it to the XMPP server and you cannot use an IP address here because we would only be using an internal connection, so I cannot say please contact 100.64.3.3. That won't work because it needs the host name for the internal XMPP configuration. Just think again, again like virtual host hosting in Apache EngineX and whatever. So use a real an FQDN that fits for the virtual host and then fake the DNS entry with ETC host or split DNS if you dare to and have that. So this is a configuration that easy as you can get with all package software that's using RCCTL, just JCOFO for the called binary name, which is a shell script in this case, but anyway then enable and start it. Chitty video bridge, same game, package add, reference the configuration file and the logging, the key store again, Java garbage collector configuration and an open and Java sys props for whatever you might need. And in JVB there's a component especially for the so-called nut harvester, which is again doing silly stuff about what's my address locally, what I'm bound to, what's my external address and maybe I am on AWS and then something you're getting different results. So we have to query some cloud API, whatever. And the properties for those are still in a file called sipcommunicator.properties and the location for that must be done via two different configuration options. So you cannot merge that, you have to write it etc and the home name is JVB and then this path is being read. Good luck finding that one out. Oh, okay. Oh, all right. So in the configuration, same part, think as a realm and here it's JVB priori magic again. If you want to grab your JCOFO log, you can use a nickname or whatever you like. So that one is free, but JVB priori has to stick with that one, scdp as that. And if you really want or have to have the video stream over TCP, here's your pot setting. And that's the default for UDP. And that's this described sipcommunicator. So you have your local address and the public address, write it down fixed. So it matches your setup and tell all this auto discovery, goodbye, like disables, this harvester too. So slow configuration is already mentioned and we go. So the pitfall is to mention the IP address and please start the services in this order. I've been talking about those like version bumps without not that much of a documentation logger and the initial startup is slow. So please keep it easy. And missed commas in chasing JavaScript is always fun. The live demo, I was showing it in the main original talk. It works, but we skip it here for time reason, we can still do it and if then time permits. So it works. The ports are committed three days ago or so and we might do a meta which just bundles all the three thingies and a local all a local configuration for better reference. And with that you can can scale out, but you have to look at it like something like Chacovo is not meant to be scaled on multiple instances and all this stuff. SRTP is the next stuff to come that's inline crypto, which is like factor 20 faster or even more and moving from Bosch to WebSockets for because it's WebSockets. And the recording stuff needs a Linux VM because they are using a headless Chrome, Chrome driver and then ripping with FM pack the resulting stream on the disk. It's a mess. And Chigazi was this part, POTS zip dial in no, just no. So yeah, of course, thanks for OpenBSD and Chitzi for the software, my employer for countless and countless hours figuring this shit out. I shot Tammy really for creating the POTS packages thing because I was already so exhausted with finding out all the magical stuff within Chitzi's all the POTS stuff was done by by her, really good props and Misha providing the demo infrastructure we did a setup within two hours or so. Only following this talk and the configuration that's in the GitHub repo where this QR code or this short URL is pointing to presentation made with Quarto. I can really recommend that. And this is a demonstration how you can backport to 7.1 or it probably works in 7.0 as well. So it's not much you have to do just for a new make package. So it fits a 7.1. And then you can install it with this little hack and some interesting log files more or less like if you have the wrong key store or it's completely missing, then you get that that log file in XMPP. This one has a wrong password in the in the definition. So this would come at first. And if the key store is okay, but the password is wrong, you're getting advancing to this one. And here it is all good. And then it can take a while on the check hopeful side. You're starting JVB and it might take exactly that interval before you're seeing this one. And only after that your web conference will work. Before this point in time, I will just say it doesn't work on the on the web on the browser side, because internally it will say I do not have a healthy video page to be used. And that's it. All right. Questions? Okay.