Create your own #Jitsi *and* #XMPP instance

So the best, and quickest, way to get your own Jitsi instance is to follow this instructions:

As far as I can tell there is no such easy peasy way to have it running in CentOS, and I won’t be diving into it for the moment although I certainly intend to do so in the future, but I think it’s very much worth it to just build upon those instructions in order to set up (what would seem to me as essential for the free federated communication world) an XMPP instance that already is built-in in your Jitsi server!

  1. If you only want the video conference part, you only need 443/tcp (https) and 10000:20000/udp and you can skip the rest of this blog entry. You don’t need to enable http as it only redirects into https, and if you don’t plan on allowing remote public ssh you don’t have to enable it either. That’s just there as a helpful reminder in case you just created a virtual machine on some VPS provider and so you don’t get locked out by accident;
  2. But if you’d like to have your own instant messaging server, you can additionally follow the instructions below in order to expose Jitsi’s integrated XMPP address as well, and your identity will be

So you start by setting up additional permissions you’ll be needing in order to re-use the same Let’s Encrypt certificate managed by certbot:

cd /etc/letsencrypt/
chmod a+rx live live/*
chmod g+rx archive
chgrp -R ssl-cert archive
chmod g+s archive archive/*
chmod g+r archive/*/*key*pem

You’ll also have to change prosody’s certificates in order to use the correct ones, and then restart it:

cd /etc/prosody/certs
ln -sf /etc/letsencrypt/live/
ln -sf /etc/letsencrypt/live/
systemctl restart prosody

Finally, you’ll need to open prosody’s port in the firewall as well:

ufw allow 5222/tcp

That’s it. Now you have your Jitsi video conference properly integrated with XMPP/Jabber, neat hey?

PS: Oh, a minor but relevant update… use the following ufw rule rather than the correspondent one in the article above to be able to allow multiple UDP streams for the video conference, as TCP and only one UDP port will be a bit painful…

ufw allow 10000:20000/udp

How to connect to a different Jitsi site

So you have now setup your own Jitsi site, or you want to connect to your friend’s Jitsi site. How to do it?

If you’re using a computer, it’s simple: all you need is to type the address of the website and room in your browser’s url bar:

But if this was all to it, then it would be a very boring short blog. 🙂 What about the app?

At least for the Android version, Jitsi Meet doesn’t make it easy to change the server, although it’s quite easy, it could be a lot simpler.

Just press the “menu” button (the three horizontally stacked bars on the top left part of the Jitsi Meet app window):

Choose Settings:

Then choose your display name and, most importantly, the website (without any room reference, just the root):

Done. Now go back and write your desired room name.

That’s it, that’s really just all there is to it.

Now go and have fun. 🙂

pam_ipahbac, the James Bond release

So we had another take into joining AIX servers against a FreeIPA / Red Hat Identity Management domain, this time with complete success since IBM has improved a lot certain aspects that allowed a much easier integration:

  • IDSLDAP (at least 6.4) now configures properly aginst FreeIPA
  • the rpm packages (aixtoolbox) are being maintained allowing for a much more recent sudo with ldap support (we couldn’t get sudo_ids to work, just go for normal sudo)
  • sshd is finally a version with support for AuthorizedKeysCommand

So it was time for a new take on the HBAC front, and after not being successful with either pam_hbac or my own pam_ipahbac, a new look at the code was needed.

Turns out the issue was OpenLDAP. The integration of pam, sshd, idsldap… basically you now need to use idsldap’s libraries so… time for a new release.

Being much simpler to change my code rather than adapt pam_hbac, that’s what I did and now configure detects that one is on AIX and no longer requires OpenLDAP. Still you need special compilation flags so it wa smuch easier for me to just let them be setup in the rpm spec.

Anyway, you can go to the website and download shiny new binaries for 0.0.7 and tar ball if you want, as well as read my definitive AIX/FreeIPA integration guide (which is also quite relevant).

Using Let’s Encrypt with getssl and minimal root usage #letsencrypt

Let's Encrypt is an amazing initiative to have X.509 certificates for your website, or even your email servers, but most instructions just tell you to run (some more some less) complicated programs as root in order to run the periodic certificate renewal workflows, and that is sub-optimal as it substantially increases the number of attack vectors your already exposed system is susceptible to.

This article is just a way to enjoy the benefits of Let’s Encrypt while minimizing the need for root privileges in your system,and thus keeping it reasonably secure, and this example is doing it with getssl (don’t be scared it hasn’t changed much for some time, they’re working on the new APIv2 support).

It’s taking in account a typical CentOS/Red Hat 7 server, your mileage might vary with other systems but it should mostly be the same.

You can start setting up your environment by adding a non privileged user, let’s say… acme… who will run the renewal workflow:

# useradd acme

Then you can proceed to installing getssl and setting up directories for your files:

# curl > /usr/local/bin/getssl
# chmod 0755 /usr/local/bin/getssl
# mkdir -p /etc/letsencrypt/acme/ssl.{crt,key,pem}
# chown -R acme:acme /etc/letsencrypt/acme
# chmod -R 0755 /etc/letsencrypt
# chmod 0750 /etc/letsencrypt/acme/ssl.{key,pem}
# mkdir -p /var/www/html/letsencrypt/.well-known/acme-challenge
# chown letsencrypt:letsencrypt /var/www/html/letsencrypt/.well-known/acme-challenge
# echo 'letsencrypt yourhostname=NOPASSWD: /usr/bin/systemctl restart httpd' >> /etc/sudoers.d/letsencrypt

That last line adding a sudo rule is part of the magic and the single root command that is executed.  You can also make it restart Postfix, Dovecot, or any other service you use a certificate and that needs restarting in order to take the new certificate.

In order to let you read it all from this article, I’ll borrow the example’s from getssl’s github page and then add in my own suggestions.

Now you want to prepare the environment (as the user acme) for your domain:

getssl -c

This will create a ~/.getssl/ directory, the main files you want are called getssl.cfg, there’s a global file on ~/.getssl/getssl.cfg and then more specific files per domain, ~/.getssl/

In the main file, ~/.getssl/getssl.cfg, you’ll need to set up the values accordingly to your needs (I won’t dive into how to get an account), but  for this setup you’ll want to change the following:

RELOAD_CMD="/usr/bin/sudo systemctl restart httpd"

And that RELOAD_CMD right there is part of the magic…

Now edit  ~/.getssl/ and change the following:


Now all you need is to set up a cron job:

45 6 * * * /home/letsencrypt/getssl -u -a -q

And finally you configure Apache httpd to use the files paths for the CERTificate and its KEY:

SSLCertificateFile /etc/letsencrypt/acme/ssl.crt/
SSLCertificateKeyFile /etc/letsencrypt/acme/ssl.key/
SSLCertificateChainFile /etc/letsencrypt/acme/ssl.crt/lets-encrypt-x3-cross-signed.pem
Alias /.well-known/acme-challenge /var/www/html/letsencrypt/.well-known/acme-challenge

And you’re done: the cron job will run every day, and when you reach the 30 days to renew threshold your certificate will be renewed with minimal root usage.


Stallman’s great talk on surveillance

When did the great Richard Stallman start using slides?

Well, I don’t mind, they’re cute and funny!


“Should we have more surveillance than the USSR?” is a highly recommendable talk!

I’ll update this post later with more photos.

#ilovefs – I 💕 Free Software


Hey, it’s that time of the year when some megafuck dudes drop the strongest advertisement campaigns for selling chocolates, perfumes and flowers to your sweetheart!

But never fear! As usual in the world of Free Software, we like to turn things around 180º to turn around the evil powers into good powers and give a much better meaning to things.

As the GNU GPL and the copyleft movement have used copyright’s powers to bestow upon us the wonders of software freedom, let’s now turn this horrid day into a day of celebration of our love for Free Software.

Thank you all Free Software developers out there! I love your work and hope to be able to stand on your giant shoulders.

Love ya! 🙂

pam_ipahbac (and why not pam_hbac)

ipahbacThose implementing FreeIPA (possibly in the enterprise ready version called Red Hat Identity Management) in a hybrid environment (meaning… not just recent GNU/Linux operating systems but particularly including AIX and Solaris) may have noticed the lack of support of an essential component in AIX and Solaris: Host Based Access Control (HBAC).

Without HBAC support, when you join a server to a real every single enabled user will be able to login into that server, which just might not be what you want, specially in more “”””enterprise“””” (please do notice the several quotes) environments with different servers having different access roles (developers can go into development servers but not into application life-cycle, operations people not having to logon to developement servers, system administration teams, security officers, etc…).

Some applications sort of implement HBAC by letting you restrict the users that can log into them, but that is definitely not elegant as it defeats the purpose of HBAC: a centralized place where one can define such access rules.

Being a PAM module it needed to have a few features:

  1. KISS: it doesn’t have to do much more than get the rules, give success on the first match or just deny for any other reason
  2. be secure: be not fancy, worry not about UNICODE, do not worry about supporting the kitchen sink, etc. This means:
    1. most AIX and Solaris environments do not have special characters like ç or ó or µ, and actually user logins are short in length, so a design strategy was to make this module extremely restrictive about the character set it allows, UNICODE is awesome but it’s also a sea of unexpected security issues;
    2. do not over-engineer in libraries and sub-files, just implement the PAM groups it needs, do a simple ldap query, navigate through the results, reply to PAM with allowed or denied
    3. I definitely do not mean to imply pam_hbac is not secure, only that it’s a critical focus on pam_ipahbac

If in the future such fancy use cases that need these things come up, then it can be re-evaluated. It’s not set in stone. Just not the focus. Priorities and such.

And this is why pam_ipahbac was born rather than working with pam_hbac.

I believe jhrozek’s module to be much more advanced, but I also believe in the above principles, and the primary focus of this module is to work in AIX and Solaris so those plagued with those systems can at least use the awesome Free Software that FreeIPA is.

Also, because it’s fun to father some code.

Happy hacking!

Giving up on

For years I’ve been bravely maintaining a instance residing at even though the project has some unhealthy red flags, the most important of which are no development community and definitely not even great involvement from its own father.

I think Evan is an awesome guy, but sadly pump did not gain traction. I’m afraid of running web software that is so unmaintained.

I don’t believe it is secure, no software is, specially secure enough to go on for almost an year without patches (and let’s not dwelve on how few there had been previously):

Screenshot from 2015-05-03 14:59:27

It’s not lightly that I do this, and it’s actually with a lot of sorrow that I’m retiring it.

It’s html5 web interface means it’s very hard to make a static version, and I’ve never shared anything so significant in it that I’ll be sad to let it go.

I’ll keep a backup but, I’m sad to say, I simply can’t take it anymore and it’s time for much due housekeeping. 🙁