| View previous topic :: View next topic |
| Author |
Message |
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
 Posted: Tue Jun 02, 2020 4:15 pm Post subject: Jitsi Meet server for Gentoo - ebuilds and quickstart rootfs |
 |
|
Hello,
If you're looking for a secure, FOSS alternative to Zoom, Hangouts etc. for video-conferencing, you may have come across Jitsi Meet, an Apache-licensed WebRTC-based solution. It has a client that runs purely in your web browser (with native Android and iOS clients also available), coupled with a back-end server complex that performs forum management, selective video forwarding, NAT traversal etc. The source is available here, and you can quickly try Jitsi, with no password needed, at https://meet.jit.si
Unfortunately however, setting up your own Jitsi server instance is somewhat complex, due to the requirement to cross-sectionally configure a group of services, integrate with Let's Encrypt (for certificate management) etc. While Debian has a multi-component, debconf-guided solution for this (curated by upstream), Gentoo currently does not (in tree anyhow).
To help address this, I have recently put together a set of ebuilds in my sakaki-tools overlay which covers the core Jitsi service set, including a pkg_config step that mirrors the flow of upstream's debconf / postinst logic, providing an easy, prompt-based setup for single-box installs. The ebuilds support both OpenRC and systemd, allow for use of either nginx (preferred) or apache as the webserver, and are available on ~amd64 (x86_64) and ~arm64 (aarch64). The server-side Java components are built from source (*) using the provided java-maven-pkg eclass. Automated TLS certificate issuance (and renewal) via Let's Encrypt is supported, but not mandated. Starting a new video-conference is set up to require a password by default (and once created, you can then add a password to that particular conference at your option, before distributing the URL to others).
If you'd like to try this out, two alternatives are offered. You can of course simply follow the regular path: install the sakaki-tools overlay, then emerge the top-level server package, configure it, and then start the server set. For full instructions on this, please see the section 'Option 2) Native Gentoo Install' below.
However, for a quicker start, assuming you have access to a systemd-based x86_64 box (VPS or whatever, running e.g. Ubuntu), I have also provided two prebuilt rootfs (one using OpenRC, the other systemd) which may be booted under systemd-nspawn as guest containers - there is then nothing to compile to get started, simply boot the container, grab a shell inside it, configure (using the bundled, prompt-driven tool) the Jitsi complex, and start it! The containers are full Gentoo instances - so you can even emerge -e --with-bdeps=y @world in them if you like, before use in production (the GitHub project for these rootfs may be found, with full instructions, here).
To get started then, first follow either 'Option 1) VPS Quick Install' or 'Option 2) Native Gentoo Install' instructions below. Once done, in either case then follow 'Jitsi Configuration and Bring-Up' instructions next.
Should you wish to have your Jitsi server start automatically on boot, finally follow the 'Starting Jitsi Automatically' instructions.
Have fun, and please report any issues either in this thread (preferred) or via email to sakaki@deciban.com!
Option 1) VPS Quick Install
Prerequisites: you have a VPS (or dedicated server) running a modern Linux OS with systemd init (e.g. Ubuntu, Debian, etc... this can even be Gentoo - although in my experience it is rare to find this, particularly on low-end offerings). Your server must have >=1 dedicated IPv4 addresses (IPv6 should be supported too, but I haven't fully tested it), and at least 2GiB of memory. You have a root login for the VPS and also have registered a domain name (we will use, purely as an example, foo.barfoo.org in what follows) that resolves (via A record) to the IP address of this server: you can ping foo.barfoo.org from an external machine and it answers successfully. No web, prosody, turn, videobridge or jicofo server should currently be running on the target machine. Ports 80/tcp, 443/tcp, 4445/tcp, 4446/udp and 10000/udp must be open.
OK, first log in to your host VPS, become root, and install the necessary packages (the following is for Debian / Ubuntu - adapt as appropriate for e.g. Fedora):
| Code: | | vps ~ # apt-get update && apt-get install -y systemd-container bsdtar wget |
You may need to use libarchive-tools in place of bsdtar in the above.
Next, choose the init system you prefer, and then continue with either the Option 1a) OpenRC, or Option 1b) systemd sections below.
Both deployments have identical functionality, so choose the init system you are more comfortable working with.
Option 1a) Install and Boot OpenRC Container
Download the OpenRC rootfs tarball (you can also verify the signature if you like, out of scope for this short tutorial), and unpack into /var/lib/machines/, a special marshalling location used by systemd-nspawn. To do so, issue:
| Code: | vps ~ # wget -c https://github.com/sakaki-/nspawn-gentoo-jitsi-meet/releases/download/v1.0.0/gentoo-jitsi-openrc.tar.xz
vps ~ # mkdir -p /var/lib/machines
vps ~ # bsdtar --numeric-owner -xf gentoo-jitsi-openrc.tar.xz -C /var/lib/machines/
vps ~ # rm gentoo-jitsi-openrc.tar.xz |
Create the systemd-nspawn boot settings file for this container; issue:
| Code: | vps ~ # mkdir -p /etc/systemd/nspawn
vps ~ # cat >/etc/systemd/nspawn/gentoo-jitsi-openrc.nspawn <<EOD
[Exec]
PrivateUsers=no
Capability=CAP_NET_ADMIN
[Files]
[Network]
Private=no
VirtualEthernet=no
EOD |
Now you are ready to boot the container. Issue:
| Code: | | vps ~ # systemctl start systemd-nspawn@gentoo-jitsi-openrc |
Your Gentoo rootfs should now be started in its own process namespace! Unfortunately, despite the recent transition to elogind, you cannot use machinectl login with OpenRC targets. However, the image does have root login enabled on localhost port 2222, via ssh, so issue:
| Code: | vps ~ # ssh -p 2222 root@localhost
<enter password when prompted>
...
gentoo-jitsi-openrc ~ # |
If you have problems with the above ssh invocation, try using ssh -p 2222 -o PubkeyAuthentication=no root@localhost instead.
The initial container root password is gentoo64 (of course, you should change this prior to use in production!).
You're now ready to configure Jitsi! Continue reading at "Jitsi Configuration and Bring-Up", below.
There's a little more info on how to make an arbitrary OpenRC rootfs (e.g., a vanilla stage 3) systemd-nspawn bootable here.
Option 1b) Install and Boot systemd Container
Download the systemd rootfs tarball (you can also verify the signature if you like, out of scope for this short tutorial), and unpack into /var/lib/machines/, a special marshalling location used by systemd-nspawn. Issue:
| Code: | vps ~ # wget -c https://github.com/sakaki-/nspawn-gentoo-jitsi-meet/releases/download/v1.0.0/gentoo-jitsi-systemd.tar.xz
vps ~ # mkdir -p /var/lib/machines
vps ~ # bsdtar --numeric-owner -xf gentoo-jitsi-systemd.tar.xz -C /var/lib/machines/
vps ~ # rm gentoo-jitsi-systemd.tar.xz |
Create the systemd-nspawn boot settings file for this container; issue:
| Code: | vps ~ # mkdir -p /etc/systemd/nspawn
vps ~ # cat >/etc/systemd/nspawn/gentoo-jitsi-systemd.nspawn <<EOD
[Exec]
PrivateUsers=no
Capability=CAP_NET_ADMIN
[Files]
[Network]
Private=no
VirtualEthernet=no
EOD |
Now you are ready to boot the container. Issue:
| Code: | | vps ~ # systemctl start systemd-nspawn@gentoo-jitsi-systemd |
And your Gentoo rootfs should now be booted in its own process namespace! As you have systemd running in both the host and guest, you can log in to your Gentoo system simply as follows:
| Code: | vps ~ # machinectl login gentoo-jitsi-systemd
<enter root, followed by password when prompted>
...
gentoo-jitsi-systemd ~ # |
The initial container root password is gentoo64 (of course, you should change this prior to use in production!).
You're now ready to configure Jitsi! Continue reading at "Jitsi Configuration and Bring-Up", below.
Option 2) Native Gentoo Install
NB - you can skip this section if using one of the prebuilt rootfs above - the necessary steps have already been taken for you!
You will need a PC with an up-to-date ~amd64 or amd64 Gentoo install, or a ~arm64 system (such as an RPi4 4GiB running my gentoo-on-rpi-64bit image). Ports 80/tcp, 443/tcp, 4445/tcp, 4446/udp and 10000/udp must be open.
OK, to begin, first add the sakaki-tools overlay, if you don't already have it:
| Code: | gen64 ~ # emerge -v --noreplace dev-vcs/git
gen64 ~ # cat >/etc/portage/repos.conf/sakaki-tools.conf <<EOD
[sakaki-tools]
# Various utility ebuilds for Gentoo on EFI
# Maintainer: sakaki (sakaki@deciban.com)
location = /var/db/repos/sakaki-tools
sync-type = git
sync-uri = https://github.com/sakaki-/sakaki-tools.git
priority = 50
auto-sync = yes
EOD
gen64 ~ # emaint sync --repo sakaki-tools |
If you are running on a stable amd64 build (for x86_64; on aarch64, only the ~arm64 branch, as used by e.g. my gentoo-on-rpi-64bit image, is recommended), add the necessary accept_keywords entries ("~" branch users should ignore the following step):
| Code: | gen64 ~ # cat >/etc/portage/package.accept_keywords/jitsi-meet <<EOD
*/*::sakaki-tools
net-im/coturn
app-crypt/certbot
www-servers/nginx
dev-java/icedtea
dev-java/xom # https://bugs.gentoo.org/683718
dev-java/jaxen
app-crypt/acme
EOD |
If you are using an instance installed from my EFI Install Guide, you probably have ebuilds from ::sakaki-tools masked by default. For simplicity, remove this constraint now:
| Code: | | gen64 ~ # rm -vf /etc/portage/package.mask/sakaki-tools-repo |
Next, ensure you have the correct nginx / apache modules specified:
| Code: | gen64 ~ # cat >>/etc/portage/make.conf <<EOD
APACHE2_MODULES="${APACHE2_MODULES} access_compat alias authz_core authz_host dir headers "\
"include mime proxy proxy_http rewrite socache_shmcb unixd"
NGINX_MODULES_STREAM="${NGINX_MODULES_STREAM} map ssl_preread"
EOD |
Add some required USE flags:
| Code: | gen64 ~ # cat >/etc/portage/package.use/jitsi-meet-server <<EOD
# uncomment the below two lines to use apache rather than nginx
# (nginx is preferred; it has better integration upstream)
#net-im/jitsi-meet-server apache2 -nginx
#net-im/jitsi-meet-turnserver -port-443-mux
# comment the line below if running on a with-GUI system
dev-java/icedtea-bin -gtk
EOD |
If you'd rather use apache (nginx is preferred due to better upstream support, e.g. TURN multiplexing on port 443), edit the file above and uncomment the lines directed. Similarly, if you are running on a desktop (rather than 'minimal install') system, comment out the icedtea-bin USE in the above. Save and exit once done.
With that complete, you're ready to emerge the various component servers (jicofo, jitsi-videobridge, coturn etc)! To do so, simply issue:
| Code: | | gen64 ~ # emerge -v --noreplace net-im/jitsi-meet-server |
The build will take some time. Assuming it completes OK, congratulations, you are now able to proceed with configuring and bringing up your Jitsi Meet server instance! Continue reading immediately below.
Jitsi Configuration and Bring-Up
Configuration of the Jitsi server complex is done by following a prompt-driven process to fill out a 'master' configuration file (/etc/jitsi/jitsi-meet-master-config; this is a little like the 'env' file in the Docker variant of Jitsi Meet). A set of hooks, one per component, are then automatically invoked to build the underlying configurations (and associated setup steps) for jitsi-videobridge, jicofo, the webserver etc. This ensures that passwords, UUIDs etc. are consistent across all components.
Of course, the underlying blocks may also be configured directly by those who are knowledgeable about Jitsi's 'wiring', and indeed non-single-box installs will require you to do so. But the point of the approach taken here is to help you get a simple instance up and running with the minimum of hassle.
In what follows, I'm going to assume you have a DNS 'A' record pointing to your VPS, IP address 82.221.139.201, with fully-qualified domain name (FQDN) of foo.barfoo.org — obviously, adapt this for your actual system.
NB: it is possible to reconfigure the server complex any number of times. So you could create a localhost-based version initially for testing, and then migrate to an externally visible version. Or redeploy an existing version to create fresh passwords etc. Up to you!
OK, so now (at the shell you were working at during last step, which will be either inside the container for options 1a and 1b, or natively for option 2, above) issue:
| Code: | | # emerge --config jitsi-meet-master-config |
and you should be prompted to enter the answers to various questions. In what follows, you can simply press Enter to accept the offered default (shown in square brackets) or, type a different answer and then press Enter. The configuration process provides quite a lot of explanatory text for each question but, in the interests of brevity, in the below only the questions (and responses) will be shown.
Remember, this for the (notional) domain foo.barfoo.org, at IP address 82.221.139.201, administrative email your@email.address; obviously, adapt for your own system!
Here's a full flow (minus commentary); parts you may or may not see (depending on whether or not it is the first time you are running the config) are shown in parentheses:
| Code: | # emerge --config jitsi-meet-master-config
(* Re-use existing configuration for ...? (y/n) [n]: <press Enter>)
* Hostname [...]: <type foo.barfoo.org and press Enter>
* External IP address [...]: <type 82.221.139.201 and press Enter>
* Internal IP address [...]: <type 82.221.139.201 and press Enter>
* Create a localhost alias for foo.barfoo.org? (recommended) (y/n) [y]: <press Enter>
* Copy foo.barfoo.org into "/etc/hostname"? (recommended) (y/n) [y]: <press Enter>
* Max videobridge daemon RAM [1024m]: <press Enter>
* Username [admin]: <press Enter>
* Password [horse-battery-staple]: <press Enter - your generated password will differ>
* Supply pre-existing key/crt pair for foo.barfoo.org? (y/n) [n]: <press Enter>
* Activate Let's Encrypt for foo.barfoo.org? (y/n) [y]: <press Enter>
* Email address [...]: <type your@email.address and press Enter>
* Configuration complete: write it? (y/n) [y]: <press Enter>
* Build component configurations from this? (y/n) [y]: <press Enter> |
It is possible to reconfigure the server any number of times.
Once the underlying component configuration completes, you can try starting up your new Jitsi Meet server instance!
To do so, if working in the OpenRC container (or running natively under OpenRC), issue:
| Code: | | # rc-service jitsi-meet-server restart |
Or, in the systemd container (or natively under systemd) issue:
| Code: | | # systemctl restart jitsi-meet-server |
This will start the various component servers (nginx, jitsi-videobridge, jicofo, turnserver/coturn and prosody).
Startup will take about five seconds. Once done, you should be able to browse to https://foo.barfoo.org (remember, this is just a fictional example, use your own FQDN!) from any remote machine and start a new meeting (click GO)! If all is well, you should find that the browser reports a valid TLS certificate ('padlock' symbol) issued by Let's Encrypt.
An automatic renewal job is also scheduled for you, which will keep this certificate up-to-date, restarting the webserver and turnserver as required.
In the browser, allow use of your camera / microphone when prompted, and then click on "I am the host" in the pop-up dialog which appears, and use the credentials above (in this example "admin" / "horse-battery-staple" (without quotation marks); obviously, adapt as appropriate). The new meeting will start, and you will see yourself on screen. You should then be able to send the meeting URL (click the circular (i) icon at the bottom of the window to see it, or look in your browser address bar) to others to enable them to join - they will not require these credentials (however, you can set a 'room' password before inviting any guests, if you wish, again via the circular (i) icon). Note that as you have an externally valid TLS certificate, users can also join via the official Android or iOS Jitsi apps.
To allow Android or iOS app users to initiate new meetings, you'll need to have them add your host address (in this example, https://foo.barfoo.org/) in the Server URL field, under the settings tab of the app (you will also need to let them know the convener credentials — here, "admin" / "horse-battery-staple").
Should you wish to bring the server complex down at any point, if working in the OpenRC container (or running natively under OpenRC), issue:
| Code: | | # rc-service jitsi-meet-server stop |
or, in the systemd container (or running natively under systemd) issue:
| Code: | | # systemctl stop jitsi-meet-server |
Logs may be viewed at /var/log/jitsi/... on both containers, and in /var/log/messages on the OpenRC container / the local journal on the systemd container.
Starting Jitsi Automatically
Once you have your Jitsi server instance working well, you may decide you want to start it up automatically whenever your host reboots.
To do so, if working with the OpenRC container (or natively under OpenRC), issue:
| Code: | | # rc-update add jitsi-meet-server default |
Or, if using the systemd variant container (or working natively under systemd), instead issue:
| Code: | | # systemdctl enable jitsi-meet-server |
If you have installed Jitsi natively, that's all you need to do. However, if using one of the two systemd-nspawn rootfs, you also need to ensure the container itself is booted at (host) system startup. To do so, exit back out of your container shell (using Ctrl-d under OpenRC, Ctrl-] three times within one second under systemd), and then, in the host shell, issue either:
| Code: | | vps ~ # systemctl enable systemd-nspawn@gentoo-jitsi-openrc |
if you are using the OpenRC container, or
| Code: | | vps ~ # systemctl enable systemd-nspawn@gentoo-jitsi-systemd |
if you are using the systemd container.
That's it! Now when the host VPS boots, your Gentoo container will automatically start, and then its init system will boot Jitsi.
(*) This approach - inspired with thanks by net-p2p/bisq-0.6.3.ebuild - builds the top level (Java) code for sctp, jicofo, and jitsi-videobridge from source, but still pulls in a large number of upstream jars as dependencies. Chasing through all of these to bring them into Portage is certainly possible but way too much work for the scope of this project. Where existing ebuilds exist in Portage, they can be used (as demonstrated e.g. by the dom4j example), and the bundled mvn2ebuild utility makes it relatively straightforward to convert a working maven Java build to an ebuild.
On the web application side, I have just used the upstream deb and unpacked the (compiled) webroot. The is no live server-side content (all that is done via the other components, jicofo, prosody and jitsi-videobridge), and the client-served content is either minified JavaScript or WebAssembly. It is straightforward to build your own webroot if desired (see e.g. here) but unfortunately the use of npm (coupled with interlinked git repos) makes it difficult to port straightforwardly into an ebuild (npm really doesn't want to run offline when using git ><).
_________________
Regards,
sakaki |
|
| Back to top |
|
 |
xaviermiller
Bodhisattva
Joined: 23 Jul 2004
Posts: 8723
Location: ~Brussels - Belgique
|
| Posted: Tue Jun 02, 2020 5:33 pm Post subject: |
|
|
Moved from Unsupported Software to Documentation, Tips & Tricks.
_________________
Kind regards,
Xavier Miller |
|
| Back to top |
|
|
Jackalope
n00b
Joined: 24 Sep 2018
Posts: 31
|
| Posted: Fri Jun 12, 2020 9:55 am Post subject: |
|
|
What am I doing wrong?
| Code: | emerge --config jitsi-meet-master-config
* Hostname [localhost]: jitsi.example.com
* Illegal format for hostname; please try again
* Enter the server hostname (localhost or FQDN).
* (for example: "jitsi.example.com"; default is "localhost")
* Hint: you can check everything is working first, by specifying
* "localhost", and then run this configuration process again
* with the real FQDN, if desired.
* Hostname [localhost]: "jitsi.example.com"
* Illegal format for hostname; please try again
* Enter the server hostname (localhost or FQDN).
* (for example: "jitsi.example.com"; default is "localhost")
* Hint: you can check everything is working first, by specifying
* "localhost", and then run this configuration process again
* with the real FQDN, if desired. |
|
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Fri Jun 12, 2020 10:27 am Post subject: |
|
|
Jackalope,
are you using one of the systemd-nspawn images, or building directly?
If the latter, what locale do you have set? The test for the FQDN is just:
| Code: | _check-fqdn() {
# basic check only
[[ "${1}" == "localhost" ]] || \
[[ $(grep -P '(?=^.{1,254}$)(^(?>(?!\d+\.)[a-zA-Z0-9_\-]{1,63}\.?)+(?:[a-zA-Z]{2,})$)' <<<"${1}" 2>/dev/null) ]]
} |
and I suppose e.g. the a-zA-Z ranges may go wrong with some charsets (not being [:alpha:] or whatever).
Try:
| Code: | | # LANG=C emerge --config jitsi-meet-master-config |
and see if that helps?
_________________
Regards,
sakaki |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22892
|
| Posted: Sat Jun 13, 2020 1:02 am Post subject: |
|
|
| If Sakaki's advice does not help, check that the shown grep -P expression succeeds. Since it hides stderr, it might be aborting for some reason and the script then misinterprets that as rejecting the hostname. |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Thu Jun 18, 2020 12:54 pm Post subject: |
|
|
I have modified the pkg_config function in jitsi-meet-master-config, to use LANG=C LC_ALL=C; hopefully that will address this issue.
_________________
Regards,
sakaki |
|
| Back to top |
|
|
undrwater
Guru
Joined: 28 Jan 2003
Posts: 314
Location: Caucasia
|
| Posted: Tue Aug 04, 2020 11:14 pm Post subject: |
|
|
Jitsi has moved their download directory it seems. At least, it failed on jitsi-meet-web.
Current directory is:
https://download.jitsi.org/stable/
Thanks for this Sakaki!
ETA:
I'm getting a VERIFY FAILED message when installing jicofo. Filesize does not match recrded size[/code]
https://dpaste.com/HNT49HNE4
OK...made it past this by removing the Manifest, and running ebuild digest.
_________________
Open-mindedness is painful... |
|
| Back to top |
|
|
genterminl
Guru
Joined: 12 Feb 2005
Posts: 527
Location: Connecticut, USA
|
| Posted: Thu Sep 03, 2020 9:10 pm Post subject: |
|
|
First, I'll add my thanks to Sakaki for pulling all this together. I wasted quite a bit of time trying to do it myself.
Not sure if appropriate or not, but I opened issues at the github repo for sakaki-tools for the two points mentioned in the previous post.
Using the direct install (amd64 system) from the overlay, I seem to have things working, as I can start a meeting on the server (not sure what I finally "fixed" to get it to actually prompt me for the user/password to start a meeting) but when I connect from another machine (using any internal or external IP address) I can get to the main jitsi page, but never get prompted for name/pass when trying to start a meeting, and never actually join a meeting when entering the URL for an existing meeting. I'd love any suggestions on how to troubleshoot further.
Additional question - is there any reasonable way to avoid Firefox's nags about invalid cert when I use localhost or local IP instead of FQDN of the server? |
|
| Back to top |
|
|
genterminl
Guru
Joined: 12 Feb 2005
Posts: 527
Location: Connecticut, USA
|
| Posted: Sun Sep 06, 2020 12:30 am Post subject: |
|
|
Minor note: default setup seems to have turnserver using syslog, instead of logging to a file as the other components do.
Turnserver config had the cert and key files switched, caused errors in the log.
On startup, both jitsi-videobridge and jicofo crash, but I can't find any log of either anywhere, nor have I yet found where to control their logging. Any hints would be appreciated. |
|
| Back to top |
|
|
undrwater
Guru
Joined: 28 Jan 2003
Posts: 314
Location: Caucasia
|
| Posted: Mon Dec 07, 2020 6:17 pm Post subject: |
|
|
So Sakaki has had to drop support for this I believe. I don't have the skills to pick up the ball, but I hope someone does. I had some more mundane projects take precedence over this one, so I haven't tested it yet.
_________________
Open-mindedness is painful... |
|
| Back to top |
|
|
genterminl
Guru
Joined: 12 Feb 2005
Posts: 527
Location: Connecticut, USA
|
| Posted: Mon Dec 07, 2020 6:28 pm Post subject: |
|
|
I've had this installed for a while. I've only done minimal testing, but I've had at least one successful meeting with a friend. Since then, I often try to start a meeting (from a different PC than the jitsi server) and the connection just gets dropped and reconnected - repeatedly. I haven't been able to track down the cause, but I haven't tried very hard. I also don't have the skills to support this myself, but would be glad to do some testing if it helps anyone else.
For me, one of the hardest parts of getting this going was getting the right ports forwarded through my gateway (cable modem - as configured by my ISP) and ended up having to turn off their "Advanced Security" or else it blocked everything, even with the port forwarding enabled. I also find troubleshooting difficult because the various relevant logs are all in different places. I suppose I could move some of them with the appropriate config options - but again, those are also in a variety of locations.
What I'd really love to see is a "wiring diagram" listing all the various required components, and how they fit together. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Documentation, Tips & Tricks
