Opera for Linux ffmpeg codec hell

I really don’t understand what the full issue is with opera and video codecs, but every few weeks, it will stop playing videos on facebook, twitter and sometimes even youtube. People will surge into the forums to complain and largely be ignored. Here’s what I’ve been able to piece together. 

The problem

The short reason for the problem is that Opera is based on a slightly time delayed version of Chromium. If the version of Chromium that Opera is using and the version of the libffmpeg.so library don’t match, then problems ensue. [The bit I can’t figure out is why Opera can’t match these up. But moving on …]

Read moreOpera for Linux ffmpeg codec hell

Git pull stopped working

So this is a weird one. I’d previously grabbed some code from a git repository. But recently when I went to update it, I got an error

fatal: unable to connect to github.com:
github.com[0: 140.82.118.4]: errno=Connection refused
github.com[1: 140.82.118.3]: errno=Connection refused

Uh-oh. Thinking it might be a transient error, I left it for a while. But then when I got the report from my firewall logs, I saw some outbound connection attempts which it was blocking.

 Nov 15 12:20:42 DST=140.82.118.4 PROTO=TCP DPT=9418
 Nov 15 12:20:43 DST=140.82.118.4 PROTO=TCP DPT=9418
 Nov 15 12:20:43 DST=140.82.118.3 PROTO=TCP DPT=9418

So googling around I saw that this port was related to a proprietary git protocol, and then I connected the two events. So apparently the last time I checked out the code, it had used the default git protocol. Then I installed a firewall with egress filtering on the server, so now it was blocking the connection attempts. One solution would be to add tcp/9418 to my firewall rules, but there was actually a simpler way. From the code directory I edited the .git/config file and changed the url= line:

[remote "origin"]
        url = https://github.com/repo/repo.git
        # url = git://github.com/repo/repo.git

And now my git pull works again. 

Gimp 2.8 Resynthesizer Plugin Ubuntu 18.

Seems like this plugin changes the rules ever so often. This is what worked for me today. 

Remove old plugins from ~/.gimp2.8/plug-ins/

Get the latest code from https://github.com/bootchk/resynthesizer.git

git clone https://github.com/bootchk/resynthesizer.git

Install dependencies and compile code. ./configure doesn’t work as suggested, so I just ran the .autogen script, which did. 

sudo apt install libglib2.0-dev libgimp2.0-dev automake intltool
./autogen.sh 
make
sudo make install
# plugins went into here
ls /usr/lib/gimp/2.0/plug-ins

Now when you start up gimp, you can see the Filters > Map > Resynthesize menu item, but I didn’t have the all-important Enhance > Heal Selection entry. That was got by installing another gimp package. 

apt install gimp-plugin-registry   # works on Ubuntu 18.04
apt install gimp-python    # apparently works on 18.10 (with gimp 2.10)



Upgrading vnstat to 2.0 on Ubuntu

I discovered that vnstat had had a major release when I was trying to run some commands listed in the online man page, and they weren’t working. Turns out version 2 came out last month, and I was still on the old Ubuntu version 1.14 from erm … 3 years ago.

The new version uses an sqlite3 database to keep the data, so it imports this from the old files when the new version first runs. One of the reasons why I wanted to upgrade is that the new “count” parameter lets you specify how many days, months, weeks of data to display. 

Took me a few goes to get this to work. We’re compiling this so install the dependencies first. 

# install the dependencies first as root or sudo
apt install sqlite3 libsqlite3-dev
# find somewhere to put it
mkdir code
cd code
wget https://humdi.net/vnstat/vnstat-latest.tar.gz
tar -zxf vnstat-latest.tar.gz 
cd vnstat-2.0
# now configure. Specifying these dirs makes it work with 
# the same config as the previous version
./configure --prefix=/usr --sysconfdir=/etc
make
# Then now uninstall the old version, and build and 
# install the new version (as root or sudo)
apt remove vnstat 
make install

OK if you didn’t get any errors, then you should be good to test it out. If you did get errors, try installing the dependencies listed. You can test to see if it works with ‘vnstatd -d’. This starts the daemon. It should at this point give you a message that its imported the database. NB vnstatd not vnstat to start the daemon. Now vnstat should work to give you stats. 

One final thing is to get it running with systemctl. When you uninstalled vnstat with apt it ‘masked’ the service file. You need to perform the following to get it back. 

systemctl unmask vnstat.service
systemctl enable vnstat.service

#If that doesn't work, then you might need to copy the example file over. 
# But on my system they were the same apart from the name (vnstatd.service vs vnstat.service)
cd code/vnstat-2.0/examples/systemd   # where you untarred the source
cp vnstat.service /etc/systemd/system/
systemctl enable vnstat.service

Letsencrypt Wildcard Certificates, with acme.sh client

Took me a bit of time to figure this out, so I thought I’d make it public. Letsencrypt announced their new wildcard certs, and because I have to add the SSL cert to a load balancer covering many subdomains, I needed to make use of it.

First thing to note is that not all clients support the new v2 API which is required for wildcard certs. I looked at the list of v2 supporting clients on the Letsencrypt site, and chose the acme.sh bash script. Not sure if I’m going to stick with it at this point but it got me going.

First thing you need to do is to run it with the –issue flag. You’ll need to run it with DNS authentication, as that’s the supported method for wildcard certs. You’ll also need to run it with both the root domain AND the wildcard.

Read moreLetsencrypt Wildcard Certificates, with acme.sh client