Using Your Ubuntu Server As Telegram Proxy (MTProxy Snap)

Telegram is great, especially because it helps one stay away from the distractions that WhatsApp brings with it. Its unfortunately blocked in Pakistan, due to unknown reason but likely not related to censorship, given WhatsApp, Signal and every other messaging app works just fine.

The good news is Telegram upstream have their own proxy protocol and an implementation (, which seems to work well. I published MTProxy as a snap ( yesterday, so thought it would make sense to share how others could setup their own proxy. This guide, will of course help me as a future reference as well.

So lets get started by installing MTProxy

snap install mtproxy

Due to security reasons, mtproxy drops privileges (if run as root) by calling setuid(), something a strictly confined snap does not allow due to security reasons, so my workaround was to create a new user on the server, so that mtproxy does not try to drop privileges.

So lets setup a new user and download proxy configurations from Telegram servers, more details:

useradd mtproxy -m
su - mtproxy
mkdir proxyconfig
curl -s -o proxyconfig/proxy-secret
curl -s -o proxyconfig/proxy-multi.conf

Now lets exit the mtproxy user shell and create a secret to be used later by Telegram client apps

head -c 16 /dev/urandom | xxd -ps

Now we create a systemd service so that our proxy runs in the background and starts automatically whenever the server is restarted. Open the below file for editing using nano (or the editor of your choice) and paste the below configuration.
Note: you must replace the random string that was generated in previous step with “my_secret” in below config.

sudo nano /etc/systemd/system/mtproxy.sevice
 ExecStart=/snap/bin/mtproxy -u mtproxy -p 8888 -H 8000 -S my_secret --aes-pwd proxy-secret proxy-multi.conf -M 1  

Lets now start the service

systemctl enable mtproxy
systemctl start mtproxy

That’s it, we are done, you now have the Telegram proxy setup and (hopefully) working.

NOTE: This was only tested on DigitalOcean droplet, so your mileage may vary.

Control GPIO pins on a RaspberryPi 3 running Ubuntu Core 18, remotely (part 1/4)

Ubuntu Core 18 is out and one of the features that it packs with it is a set of snapd interfaces to access GPIO pins on the Raspberry Pi 2/3 in a fully confined snap. This enables one to just flash Ubuntu Core 18 on a micro sd card, boot, install a snap (which I author), connect a few interfaces and start controlling relays attached to a Raspberry Pi 2/3.

If you don’t have Ubuntu Core 18 already installed, you can see the install instructions here

To get started (assuming you have Ubuntu Core 18 installed and have working ssh access to the Pi), you need to install a snap that exposes the said functionality over the network (local)

snap install pigpio

The above command installed the pigpio server, which automatically starts in the background. The server could take as much as 30 seconds to start, you have been warned.

We also need to allow the newly installed snap to access a few GPIO pins

snap connect pigpio:gpio pi:bcm-gpio-4
snap connect pigpio:gpio pi:bcm-gpio-5
snap connect pigpio:gpio pi:bcm-gpio-6
snap connect pigpio:gpio pi:bcm-gpio-12
snap connect pigpio:gpio pi:bcm-gpio-13
snap connect pigpio:gpio pi:bcm-gpio-17
snap connect pigpio:gpio pi:bcm-gpio-18
snap connect pigpio:gpio pi:bcm-gpio-19
snap connect pigpio:gpio pi:bcm-gpio-20
snap connect pigpio:gpio pi:bcm-gpio-21
snap connect pigpio:gpio pi:bcm-gpio-22
snap connect pigpio:gpio pi:bcm-gpio-23
snap connect pigpio:gpio pi:bcm-gpio-24
snap connect pigpio:gpio pi:bcm-gpio-26

The above pin numbers might look strange, but if you read a bit about the Raspberry Pi 3’s GPIO pinout, you will realize, I only selected the “basic” pins, you are however free to connect all GPIO pin interfaces.

The pigpio snap that we installed above exposes the GPIO functionality over WAMP protocol and http. The HTTP implementation is very basic and allows to “turn on” and “turn off” a GPIO pin and get current state(s) of the pins.

Note: below commands assumes you have httpie installed (snap install http).

To get the state of all pins

http POST http://raspberry_pi_ip:5021/call procedure=io.crossbar.pigpio-wamp.get_states

If we only want the state of a specific pin

http POST http://raspberry_pi_ip:5021/call procedure=io.crossbar.pigpio-wamp.get_state args:='[4]'

To “turn on” a pin

http POST http://raspberry_pi_ip:5021/call procedure=io.crossbar.pigpio-wamp.turn_on args:='[4]'

To “turn off”

http POST http://raspberry_pi_ip:5021/call procedure=io.crossbar.pigpio-wamp.turn_off args:='[4]'

I am skipping talking about the WAMP based API for this, to keep this blogpost short, I must add though, that the WAMP implementation is much more powerful than the http one, especially because it has “event publishing”, imagine multiple people controlling a single GPIO pin from different clients, we publish an event that can be subscribed to, hence ensuring all client apps stay in sync. I’ll talk about this in a different blog post. In a later post, I will also be talking about making the GPIO pins accessible over the internet.

For me personally, I have a few projects for home and one for my co-working space that I plan to accomplish using this.

The code lives on github

Introducing PySide2 (Qt for Python) Snap Runtime

Lately at, we have been PySide2 for an internal project. Last week it reached a milestone and I am now in the process of code cleanup and refactoring as we had to rush quite a few things for that deadline. We also create a snap package for the project, our previous approach was to ship the whole PySide2 runtime (170mb+) with the Snap, it worked but was a slow process, because each new snap build involved downloading PySide2 from PyPI and installing some deb dependencies.

So I decided to play with the content interface and cooked up a new snap that is now published to snap store. This definitely resulted in overall size reduction of the snap but at the same time opens a lot of different opportunities for app development on the Linux desktop.

I created a ‘Hello World’ snap that is just 8Kb in size since it doesn’t include any dependencies with it as they are provided by the pyside2 snap. I am currently working on a very simple “sound recorder” app using PySide and will publish to the Snap store.

With pyside2 snap installed, we can probably export a few environment variables to make the runtime available outside of snap environment, for someone who is developing an app on their computer.

Software security over convenience

Recently I got inspired (paranoid ?) by my boss who cares a lot about software security. Previously, I had almost the same password on all the websites I used, I had them synced to google servers (Chrome user previously), but once I started taking software security seriously, I knew the biggest mistake I was making was to have a single password everywhere, so I went one step forward and set randomly generated passwords on all online accounts and stored them in a keystore.

I then enabled 2FA authentication on some important services (GMail, GitHub, Twitter, DO) and adopted the policy to never login to my browser’s sync features. Doing that, I realize that the browser is just a commodity, it doesn’t matter which browser I use as long as I can log into my online accounts and of course a browser that actually works.

I am pretty sure there are many things that I could still improve around my computing patterns, which I will over time.

Motto: software security over convenience.

Lets Snap The World

I am a long-time Ubuntu user and community contributor. I love how open-source communities generally work, sure there are hiccups, like companies mandating decisions that aren’t popular amongst the community. The idea of I being able to fix an issue and getting that released to hundreds of thousands of people is just priceless for me.

For the long time, I have distinguished some issues in Linux on the desktop that I want fixed. Biggest is always having the latest version of the software I use. Think of Android for example, you always get the latest version of the app, directly from the developers with no package maintainer in between. That’s the ideal scenario but for us currently on Linux it may not be possible in all cases because of the fragmentation we have.

Snaps, I believe tries to solve that.

Whenever I find a new software that I want to install these days, the first thing I do is search the snap store (snap find my_query). I have found some unexpected snaps while doing that but other times I faced disappointment. On a personal level I have slowly started to fix that. I published Android Studio as a snap, Sublime Text is work-in-progress and I am looking into snapping Keybase.

The other apps that are absolutely important for me are already available, like PyCharm and Slack.

I have also discovered that MySQL and Firefox to some extent have their snaps there, which is super awesome.

The great thing today is that most new open-source projects are doing development on GitHub, so we can just go and contribute snap support for a project and quickly get automatic builds on I hope more people who care about Ubuntu, and Linux in general get behind this effort and make application delivery on Linux the best amongst all Desktop OSes.

Its time to put our egos aside and work for a larger cause.

I am a QA Engineer and Python developer and I need a job

Yesterday I was laid off by Canonical after working 6 years with them as a QA Engineer. I really loved my job and learned quite a lot, but now I must find a new job to survive. I have been involved with Ubuntu for close to 8 years, started as a contributor to the Ubuntu community, later I was offered a role at Canonical to work on Ubuntu.

I am very passionate about software. When I am not working, I write code and when I am working I write code. I never stopped learning technologies of different domains during last few years, so apart from my full-time job, I taught myself Android app development, Django to write RESTful APIs (not a full-stack developer yet) and to some extent I am also a DevOp and have been managing a lot of my deployments.

As a QA Engineer, I can help you setup test plans, find coverage gaps, automate your tests and enable them to run as part of CI in Jenkins. Apart from automation, I do have extensive experience with manual testing as well, so I can really break your product(for good).

My Linux skills are quite competitive, having used Ubuntu exclusively for 8 years I am very comfortable with command-line, with remote debugging over ssh. I am experienced with both git and bzr. I am also very passionate about embedded devices, have experimented very cool things on the RaspberryPi.

I live in Pakistan (GMT+5) but I am pretty flexible with work hours, so if an opportunity arrives I can really work in a different timezone. I don’t have any specific preference over the size of the company, so I am very willing to work for companies of all size. I am also up for any freelance opportunities, so if you don’t have a full-time role, I can be a freelancer/consultant.

my linkedin:
my github:
my launchpad:

Exciting times ahead.