Thursday, January 28, 2021

Jitsi websockets and JWT Tokens

Bloody thing.

I'm running Jitsi on a Devuan server and they now are migrating to using websockets.

OK, first hurdle.

Websockets

https://github.com/jitsi/jitsi-videobridge/blob/master/doc/web-sockets.md

So I am running my Jitsi behind a Apache reverse proxy (long story as to the reasons)

Here's the bit that works for me after poring over multiple configs and testing til my eyes bled.



  DocumentRoot "/usr/share/jitsi-meet"

  <Directory "/usr/share/jitsi-meet">
    Options Indexes MultiViews Includes FollowSymLinks
    AddOutputFilter Includes html
    AllowOverride All
    Order allow,deny
    Allow from all
  </Directory>

  Alias "/config.js" "/etc/jitsi/meet/myjitsi.server.com-config.js"
  <Location /config.js>
    Require all granted
  </Location>

  Alias "/external_api.js" "/usr/share/jitsi-meet/libs/external_api.min.js"
  <Location /external_api.js>
    Require all granted
  </Location>

  RewriteEngine On
  RewriteCond %{REQUEST_URI} ^/[a-zA-Z0-9]+$
  RewriteRule ^/(.*)$ / [PT]

  ProxyPreserveHost Off
  ProxyTimeout 900

  <Location "/http-bind">
    RequestHeader set Host "myjitsi.server.com"
    ProxyPass http://localhost:5280/http-bind
    ProxyPassReverse http://localhost:5280/http-bind
  </Location>

  <Location "/xmpp-websocket">
    RequestHeader set Host "myjitsi.server.com"
    RewriteCond ${HTTP:Upgrade} websocket [NC]
    RewriteCond ${HTTP:Connection} upgrade [NC]
    ProxyPass "ws://localhost:5280/xmpp-websocket"
  </Location>

# Either one of the following

# https://community.jitsi.org/t/colibri-ws-websocket-not-working/88117/4

ProxyPassMatch ^/colibri-ws/default-id ws://localhost:9090
ProxyPassReverse ^/colibri-ws/default-id ws://localhost:9090

#https://community.jitsi.org/t/colibri-ws-websocket-not-working/88117/9

<Location /colibri-ws/default-id> RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC] RewriteCond %{HTTP:CONNECTION} Upgrade$ [NC] RewriteRule /colibri-ws/default-id/(.*) ws://localhost:9090/colibri-ws/default-id/$1 [P] </Location>

JWT Tokens

JWT tokens are not compulsory. They also current only seem to work via bosh, not websockets.

I am currently using authentication = internal_plain and using prosodyctl to set up users (I don't allow guest access)

This can be changed to authentication = token but needs setting up. This, like most things Jitsi, is non trivial.

If you also want to use openBridgeChannel:websocket with Jitsi meet as recommended, you need to use tokens. It is a tangled web.

// Enables / disables a data communication channel with the Videobridge.
// Values can be 'datachannel', 'websocket', true (treat it as
// 'datachannel'), undefined (treat it as 'datachannel') and false (don't
//openBridgeChannel: true,
//openBridgeChannel: websocket,

How to JWT tokens use with Rocketchat:

https://szewong.medium.com/rocket-chat-part-3-installing-jitsi-with-jwt-for-secure-video-conferencing-b6f909e7f92c


Also some other links:

https://community.jitsi.org/t/jwt-tokens-install-guide/53359/9
https://doganbros.com/index.php/jitsi/jitsi-installation-with-jwt-support-on-ubuntu-20-04-lts/
https://github.com/christiancuri/Docs

There are issues with luarocks-cjson

apt-get install --reinstall lua-basexx lua-sec lua-socket lua-cjson  libssl1.0-dev luacrypto lua5.2 luarocks
luarocks install luajwtjitsi << but this failed
luarocks build luajwtjitsi << did this again and it worked

service prosody restart && service jicofo restart && service jitsi-videobridge2 restart


Hopefully no errors in the prosody logs and you should see:

token_verification    error    'app_id' must not be empty

In /etc/prosody/conf.avail/my-server-cfg.lua set these.

-- Properties below are modified by jitsi-meet-tokens package config
-- and authentication above is switched to "token"
app_id="myweirdid"
app_secret="somelongweirdsecret"

So that gets the basics running, but it needs more configuration via the links above.

I need to sort out actually using the tokens, and the openBridgeChannel but for now I am happy websockets work, and the basics of the tokens are there.

--------------


As a FYI after a LOT of messing about trying to get a consistent setup I gave up wasting my time.

The reason I didn't use nginx was I was also running a gitlab instance on the same box. That uses an internal nginx service.

In the end I put gitlab on a different port, installed nginx as a standalone system, and added the config plus the ports I wanted.

Here's the basic config I used:

https://raw.githubusercontent.com/jitsi/jitsi-meet/master/doc/debian/jitsi-meet/jitsi-meet.example

Quite frankly the Jitsi docs (and community support for stuff) are awful for the most part. A real shame as it lets the project down.


Tuesday, January 26, 2021

Grandstream GPX2170 OpenVPN

Well, I had a bit of a struggle with this at first but got there in the end.

So, a few notes to remind myself later.

OpenVpn - I am using openvpn routed contrib with https://www.koozali.org & https://www.contribs.org Essentially CentOS (for now).

You will need some network config & firewalling but that can be found elsewhere.

Koozali SME then generates a server config like this for reference (remove the comments << ). This config is installed in /etc/openvpn/routed

 port 1194  
 proto udp  
 dev tunvpn0  
 user openvpn  
 group openvpn  
 chroot /etc/openvpn/routed  
 persist-key  
 persist-tun  
 # Certificates config  
 dh pub/dh.pem  
 ca pub/cacert.pem  
 cert pub/cert.pem  
 key priv/key.pem  
 tls-server  
 crl-verify pub/cacrl.pem  
 plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so login << required for SME for pam user authentication  
 server 192.168.29.0 255.255.255.0 << could be any network you choose  
 topology subnet  
 # up /etc/openvpn/routed/bin/up << required for SME to set local networking  
 script-security 2  
 # Options  
 keepalive 40 180  
 push "dhcp-option DOMAIN mydomain.com"  
 push "dhcp-option DNS LocalIP.Of.This.Server"  
 push "dhcp-option WINS LocalIP.Of.This.Server"  
 tun-mtu 1400  
 mssfix  
 cipher AES-256-CBC  
 passtos  
 comp-lzo adaptive << deprecated and to be removed soon  
 push "comp-lzo adaptive"  
 nice 5  
 management 127.0.0.1 11195 management-pass.txt  
 max-clients 6  
 client-config-dir ccd  
 status-version 2  
 status bridge-status.txt  
 suppress-timestamps  
 verb 3  


You may or may not need some of these options. Make sure the Ciphers agree.

Make sure your server certs are in the right place.

You should be able to connect to this with any normal OPenVPN client. You need to get it working at this point.

Next the Grandstream

Generate certificates. They must unique per device

Set the Server Address, Port, UDP,  Cipher, User and Pass, comp-lzo no, and any additional options ((I didn't need them).

Add your certificates. They must be must be PEM encoded. The CA and Certificate must end with .crt and the Key must end with .key (no idea why!)

Set to enabled. Save and Apply. Then reboot. It should connect.

Clearly you need settings to register etc.

 #OpenVPN on/off  
 P7050 1  
 #Server address  
 P7051 voip.server.com  
 #Port  
 P7052 1194  
 #Transport UDP=1 TCP=0  
 P2912 1  
 #Cipher AES-256=2 Blowfish=0  
 P8396 2  
 User  
 P8394 username  
 Pass  
 P8395 password  
 Comp LZO  
 P8508 0  
 Options  
 P8640  
 eg  
 comp-lzo no;auth SHA256  

Done.

Thanks to https://codeformatter.blogspot.com/ for tidying my code!

Monday, April 27, 2020

Firefox resize Awesome Megabar nonsense

As if the muppets at Mozilla haven't inflicted enough shit on people they now want to screw the already crap awesome bar.

With your Shiny nerw Firefox 75 if you click on the URL bar it now pops up right inyour face.

It is is SHIT. It is annoying as hell. And as with everything Firefox, trying to remove it or restore your old preference is made extremely difficult. Because they are right and you know nothing.

They are so busy telling each other how fucking wonderful they are that they forget that ordinary mortals don't necessarily drink the same Kool-Aid.

We want lean, mean, no spyware and no useless gimmicks. Stop trying to be clever, because you aren't. Stop trying to impress, because you don't.

A couple of ways to fix this bollocks.


https://lifehacker.com/how-to-disable-firefox-75s-new-address-bar-1842728031

about:config
  • browser.urlbar.openViewOnFocus
  • browser.urlbar.update1
  • browser.urlbar.update1.interventions
  • browser.urlbar.update1.searchTips

An alternative.

https://www.reddit.com/r/firefox/comments/f29syp/how_to_disable_the_new_megabar/

Add this to userChrome.css

#urlbar[breakout-extend]{
    top:calc((var(--urlbar-toolbar-height) - var(--urlbar-height)) / 2)!important;
    left:calc((var(--urlbar-toolbar-width) - var(--urlbar-width)) / 2)!important;
    width:100%!important
}
 #urlbar[breakout-extend] #urlbar-input-container{
    height:var(--urlbar-height)!important;
    padding:0px!important
}
 .urlbarView{
    margin:0px!important;
    width:100%!important
}
 .urlbarView-row{
    padding:0px!important
}



To force a restart go to about:profiles and choose:

Restart normally


Thursday, October 18, 2018

Mozilla Thunderbird developers once again lose their minds

It's fingers in their ears time over at Mozilla once again.

Got the new Thunderbird 0.60.x release ? Got a load of extensions ? Good luck.

The devs at Mozilla and Thunderbird once again reveal their complete intransigence and blinkered vision.

Here's a really good summary:

https://www.mail-archive.com/dl-ticket-service@thregr.org/msg00459.html

In short:

TB 60 decided to jump on the new FF engine, and as Firefox with the 60
release, the following happened:

- TB 60 doesn't have the WebExtension APIs required yet to develop
  FileLink extensions.

  See https://bugzilla.mozilla.org/show_bug.cgi?id=1481052 TB 63
  "should" be the first TB version that includes the required API. At
  the time, the API is still being discussed.

- Despite knowing several extensions won't work with TB 60, they still
  decided to disable "Legacy extensions" by default. Note that,
  contrarily to Firefox, TB extensions won't have *anything* in common
  with other browsers or clients, so there's no rush for "WebExtension"
  compatibility here.

- TB also deliberately changed several APIs with TB 60, which they could
  have avoided. This broke existing "legacy" extensions exactly at the
  worst possible moment.

- Cherry on top, TB also removed the installation of the xpcom SDK,
  which caused Debian to drop most of the utilities *needed* to
  fix/rebuild the extensions.

Just like FF 60, I'm actually mad at how the transition was handled.
TB is clearly understaffed, but there's no excuse for such a poor
release handling. TB 60-62 will require a specific extension just for
the transition period, and that code will have to be trashed again for
TB 63.

'Possibly working in 0.63'? Are they taking the piss or just plain stupid?

I'm sick to the back teeth of the devs. If you dare to criticise you just get banned. Anything that is remotely considerd criticism is called offensive and you get kicked.

How many times I have I seen this?

"we think it is a great idea and you will too"

No we bloody well won't. There is crap and bugs that they have ignored for years.

Mozilla have left Thunderbird in the worst of all worlds. Technically hived off from Mozilla, but still run by Mozilla with an iron fist and with no chance of community input.

Thunderbird is still one of the best independent email clients around. It is just a crying shame that the management suck. Big.




Tuesday, June 12, 2018

Gitlab reverse proxy with Apache and https behind router/firewall

Lordy I struggled.

I just could not get this running.

I wanted a single machine running an instance of Gitlab behind a gateway firewall. Not too bad if you want to accept the http defaults, but who the hell wants to use plain old http these days ?

Gitlab config is messy and this particular issue is not very well explained IMHO. But anyways, here is how I did it. I am assuming you know what you are doing here.

I had Gitlab running, but like many I struggled with the reverse proxy. I am grateful to this post which finally helped me unravel things. It was a bit out of date as it was for Apache 2.2 and not 2.4 I think (the proxy lines gave an error) but it pointed me in the right direction:

https://oliversmith.io/technology/2014/07/18/reverse-proxying-gitlab-with-apache-and-ssl/

This method leaves Gitlab running it's own version of nginx with SSL and reverse proxying Apache to that. It is simple and works.

First, get your ducks in a row.

I decided to use Devuan. A bit of systemd free goodness :-)

I am going to use an external port of 8443 with apache then reverse proxying that to the Gitlab port on 4443 Make sure you have the port forwarded on your firewall. I also suggest adding some iptables on your server just for good measure so allow the right ports there too.

So install Devuan (ASCII), gitlab-ce (cheat and use the debian repo) and apache

For gitlab-ce a sources.list file with this - you'll need keys & all that jazz :

deb https://packages.gitlab.com/gitlab/gitlab-ce/debian/ jessie main

Get yourself a Letsencrypt certificate. They are free. It is pointless not doing this.

You don't need bloatware - use the dehydrated script from here:

https://github.com/lukas2511/dehydrated

Here's my gitlab.rb It lets Gitlab run its own instance of nginx but on a https/ssl port. We will then use Apache to proxy to it.

Here's the gitlab.rb configuration file showing the only uncommented lines.

cat /etc/gitlab/gitlab.rb |egrep -v "(^#.*|^$)"

external_url 'https://gitlab.example.com:4443'
nginx['ssl_certificate']= "/etc/gitlab/trusted-certs/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/gitlab/trusted-certs/privkey.pem"

For Apache you will need some modules:

a2enmod proxy proxy_ajp proxy_http rewrite deflate headers proxy_balancer proxy_connect proxy_html xml2enc ssl

I suggest you can hit the Apache instance both internally and externally, using first http and then https.

cat /etc/apache2/ports.conf |egrep -v "(^#.*|^$)"

# http Listen disabled
# Note if you do not add 0.0.0.0 you will get IPv6 only !

Listen 0.0.0.0:8443
Listen 0.0.0.0:8443

cat /etc/apache2/sites-available/gitlab-https.conf |egrep -v "(^#.*|^$)"

        ServerName gitlab.example.com
        SSLEngine on
        SSLCertificateFile /etc/gitlab/trusted-certs/fullchain.pem
        SSLCertificateKeyFile /etc/gitlab/trusted-certs/privkey.pem
   
        Require all granted
   
    SSLProxyEngine on
    ProxyRequests Off
    ProxyPass / https://gitlab.example.com:4443/
    ProxyPassReverse / https://gitlab.example.com/
    Header edit Location ^http://gitlab.example.com/ https://gitlab.example.com/
    RequestHeader set X-Forwarded-Proto "https"

(make sure there is a symlink to sites-enabled)


I basically got Gitlab running in standard mode with no ssl. Then Apache in http mode. Then I finally added SSL to Gitlab and to Apache.

Some handy check commands for ports etc:

netstat -anp |grep apache

netstat -tan | grep 4443

iptables -L -n -v

Hope that helps someone.

Wednesday, November 29, 2017

iPXE boot from tftpd

Why do they keep making life difficult ?

Upgraded to the latest Prox v5 and went to do a test tftp boot. Always worked before. Suddenly faced with a continuously looping iPXE BIOS thingy.

And rubbish documentation on the subject.

All I wanted was a simple 'boot from existing tftpd setup'. Easy. Or not.

So, the answer is easy, ish.

http://ipxe.org/cmd/chain

Boot, press Control + B and then type

chain tftp://10.1.2.3/pxelinux.0

No idea how to make this default on Proxmox though.

What is inexcusable is that it can't figure this out by itself and means I have to go wasting time hunting about for stuff.

Grrrrrrrr. Bloody smartarse developers.

Thursday, August 24, 2017

OpenVPN error CRL has expired

I have webmin and openvpn installed.

After an upgrade to openvpn and openssl I recreated certificates and after a bit I got the following error:

error=CRL has expired

I couldn't see how to regenerate the required files in webmin, and on the commandline it kept throwing errors. I did not have easy-rsa installed.

There is some guidance on this eg here:

https://forums.openvpn.net/viewtopic.php?t=23166

https://u5r.nl/post/openvpn-crl-has-expired

However, this doesn't help too much. What I did was this open this:

/etc/openvpn/openvpn-ssl.cnf

Modify this line to something longer eg 365

default_crl_days= 30            # how long before next CRL


Add the following details from:

/etc/openvpn/keys/your-server/ca.config

to the to openvpn-ssl.cnf file:

# This definition stops the following lines choking if HOME isn't
# defined.
HOME            = .
RANDFILE        = $ENV::HOME/.rnd

# From here
CA_NAME='your-server'
CA_EXPIRE='3650'
KEY_SIZE='2048'
KEY_CONFIG='/etc/openvpn/openvpn-ssl.cnf'
KEY_DIR='/etc/openvpn/keys/your-server'
KEY_COUNTRY='AA'
KEY_PROVINCE='Province'
KEY_CITY='City'
KEY_ORG='Org'
KEY_EMAIL='email@gmail.com'

KEY_OU='OU'
KEY_CN='CN'
# To here


Now cd /etc/openvpn

openssl ca  -gencrl -keyfile keys/your-server/ca.key -cert keys/your-server/ca.crt  -out keys/your-server/crl.pem -config ./openvpn-ssl.cnf

Restart Openvpn and you should be good to go until the crl_days expire