Ubuntu 19.10 Fails to Install Deb File

Illustration

As I upgraded to Ubuntu 19.10, I went to install a few of my Linux applications and immediately got Failed to install file: not supported error. Debian packages that worked for me with 19.04 were suddenly causing the issue.

I traced this to my control file:

Package:        Bimil
Version:        MAJOR.MINOR
Architecture:   all
Maintainer:     Josip Medved <jmedved@jmedved.com>
Homepage:       https://www.medo64.com/bimil/
Description:    Password manager.
                A small password manager compatible with Password Safe file format.
Section:        misc
Priority:       optional
Depends:        mono-complete (>=4.2), gnupg2

While this worked fine for Ubuntu 19.04, in Ubuntu 19.10, one has to have Build-Depends value too:

Package:        Bimil
Version:        MAJOR.MINOR
Architecture:   all
Maintainer:     Josip Medved <jmedved@jmedved.com>
Homepage:       https://www.medo64.com/bimil/
Description:    Password manager.
                A small password manager compatible with Password Safe file format.
Section:        misc
Priority:       optional
Depends:        mono-complete (>=4.2), gnupg2
^^Build-Depends:  mono-complete (>=4.2)^^

Once I rebuilt package with it, my .deb files worked once again.

SIGFAULT in QVector size()

Illustration

After a long time, I started playing with C++ again - this time in the form of QT. Since I learned C++ a while ago, my code was a bit rustic and probably not following all the newest recommendations, but hey, it worked. Until I decided to change it from using QVector<std::shared_ptr<FolderItem>> to QVector<FolderItem*>. Suddenly I kept getting SIGFAULT in the most innocuous method: size().

As Google is my crutch, I did a quick search for this and found absolutely nothing useful - just other people having the same issue. After finally looking at my code, I figured why - because I was asking the wrong question. Of course there was nothing wrong with size() method in QVector class used by millions. It was me all along.

I had _folder variable in main window that I never initialized and I used it to call its method which in turn used QVector.size(). Forgetting to initialize this variable if you’re using shared_ptr is nothing - it simply ends up being null pointer and I had check for those. Once I changed to raw pointer, I lost that protection and uninitialized variable did what uninitialized variable in C++ does - pointed to “something”. Executing function “somewhere” in memory is what brought SIGFAULT - not the poor size() method.

It was all solved by something I used to do reflexively: initialize any variable declared in C++ to some value - even if that value is nullptr.

PIA in Encrypted Home Directory

Upon getting Linux Mint installed, I went ahead with installing VPN by Private Internet Access. Went through the same motions as usually albeit now with slightly different result - it wouldn’t connect.

Looking at logs ($HOME/.pia_manager/log/openvpn.log) just gave cryptic errors:

SIOCSIFADDR: Operation not permitted
: ERROR while getting interface flags: No such device
SIOCSIFDSTADDR: Operation not permitted

Quick search on internet brought me to Linux Mint forum where exactly the same problem was described. And familiarity didn’t stop there; author had one other similarity - encrypted home folder. Sounded like a perfect fit so I killed PIA client and went with slightly modified procedure:

sudo mkdir /home/pia
sudo chown -R $USER:$USER /home/pia
mv ~/.pia_manager /home/pia/.pia_manager
ln -s /home/pia/.pia_manager ~/.pia_manager

However, this didn’t help. Still the same issue in my log files. So I decided to go with atomic option. First I killed PIA client (again) and removed PIA completely together with all my modifications:

rm ~/.pia_manager
sudo rm ~/.local/share/applications/pia_manager.desktop
rm -R /home/pia

With all perfectly clean, I decided to start with fresh directory structure, exactly the same as in the original solution:

sudo mkdir -p /home/pia/.pia_manager
sudo chown -R $USER:$USER /home/pia
ln -s /home/pia/.pia_manager ~/.pia_manager

With directory in place I repeated installation of PIA client:

cd ~/Downloads
tar -xzf pia-v72-installer-linux.tar.gz
./pia-v72-installer-linux.sh

And it worked! :)

Better Vi Coloring

On my default Ubuntu server installation vi is very colorful. However, most of colors are so dark that I cannot really see what’s written against dark window background. This is fortunately mitigated by setting background into “dark mode”.

set background=dark

Second issue I faced was inability to copy/paste from other applications without the whole text being indented like crazy. Of course, there is setting for that too.

filetype indent off

With these two settings, my vi was usable again.

Syncing Time Zone via IPMI

After using UTC time zone exclusively on my servers for a while, I decided to give local time a try for the next 6 months or so. In addition to “normal” shenanigans time zones bring, I got another interesting one - my IPMI servers required me to manually tell them whether daylight saving is in effect or not. What that meant is that, even with time zone set correctly, every daylight saving time change my server’s BMC will be 1 hour off.

As all my servers were Supermicro (M11SDV-4CT-LN4F and A1SRi-2558F) I decided to use Supermicro’s powerful IPMI to programmatically deal with that issue.

My thoughts were going in the following direction. As long as I keep script on my main server that will update time zone information (if needed) twice a day (at 02:00 and 03:00), it should be enough to keep me happy. As retrieving time zone information via IPMI is not something that’s standardized, I contacted Supermicro’s support to get the details. While they didn’t really provide those details, they did point me toward their SMCIPMITool utility.

Unfortunately this didn’t fully solve it for me as it didn’t support FreeBSD. However, it did have debug mode (in SMCIPMITool.properties set debug_level=1) and this really helped.

./SMCIPMITool ^^192.168.1.1^^ ^^admin^^ ^^password^^ ipmi oem x10cfg ntp timezone
 …
 [ YOU -&gt; BMC : ^^30 68 01 00 00^^ ]
 [ YOU &lt;- BMC : 00 01 2D 30 37 30 30 01 ]

With these response bytes it was easy enough to construct ipmitool raw bytes:

ipmitool -I lanplus -H ^^192.168.1.1^^ -U ^^admin^^ -P ^^password^^ raw ^^0x30 0x68 0x01 0x00 0x00^^
 01 2d 30 30 30 30 00

The first byte tells us if NTP is enabled or not, next 5 bytes tells time zone in ASCII (+0000), while the last byte says if daylight saving is on or not.

Using the same principle, it’s easy enough to update IPMI:

ipmitool -I lanplus -H ^^192.168.1.1^^ -U ^^admin^^ -P ^^password^^ raw 0x30 0x68 0x01 0x
 01 0x00 ^^0x01 0x2d 0x30 0x37 0x30 0x30 0x00^^

Trying to script this change is a bit tricky. There isn’t really easy and fireproof method of determining if daylight savings is active. However, I decided to ignore that field and just set offset every time as that’s really easy to determine (date +%z).

The final script was looking something like this:

#!/bin/bash

IP="^^192.168.1.1^^"
USER="^^admin^^"
PASSWORD="^^password^^"

CURR_STATE=`ipmitool -I lanplus -H $IP -U $USER -P $PASSWORD raw 0x30 0x68 0x01 0x00 0x00 | xargs | tr ' ' '\n' | awk '{printf " 0x" $1}' | xargs`
NEXT_STATE="0x01 `date +%z | hexdump -C | head -1 | cut -d' ' -f3-7 | tr ' ' '\n' | awk '{printf " 0x" $1}'| xargs` 0x00"

if [[ "$CURR_STATE" != "$NEXT_STATE" ]]; then
    ipmitool -I lanplus -H $IP -U $USER -P $PASSWORD raw 0x30 0x68 0x01 0x01 0x00 $NEXT_STATE 2>/dev/null
fi