Resolving Interrupted Yum Upgrade

Running recent CentOS update on machine with 512 MB of RAM caused yum to run out of memory. Thinking nothing of it, I stopped it to see what can be done. After stopping all services I was greeted with “Warning: RPMDB altered outside of yum” and “Found 93 pre-existing rpmdb problem(s), ‘yum check’ output follows”.

After trying a lot of things, I found the one that works. Removing older package without removing its dependencies and reinstalling the newer one worked a charm:

rpm --erase --nodeps --noscript ^^yum-plugin-fastestmirror-1.1.31-42.el7.noarch^^
yum reinstall -y ^^yum-plugin-fastestmirror^^

Of course, the same can be scripted but I leave that to more daring souls. :)

PS: Yes, the same procedure works on Red Hat too.

Changing Default Settings For Scanner

As I started scanning a batch of documents, I got annoyed by Windows Fax and Scan default settings. So I went to search for scanner dialog where you used to be able to set these things only to find it replaced by nicer looking and utterly useless interface. Again, Microsoft decided to remove the old dialog and replace it with nothing.

However, I knew settings were read from somewhere so I used Process Monitor to see what scanner was up to. That lead me to %USERPROFILE%\AppData\Local\Microsoft\UserScanProfiles directory full of XML files. And yes, scanner profiles were in that directory.

The first change I wanted was to have scanner load my last used settings by default. Fortunately settings are kept in (numbered) XML files and, knowing Photo was the current default profile, all it took was moving <default/> tag from that profile to one named “Last used settings”. Next time I tried scanning, my last values were offered as defaults.

However, while there, I also decided to customize two default settings. Instead of deciphering settings, just scan as you normally would and copy everything from WiaItem downward into the appropriate file.

My preferred settings ended up being:

<ScanProfile>
  <ProfileGUID>{F4798F9B-5FDE-4471-BC0D-4BF692AB32D8}</ProfileGUID>
  <DeviceID>{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}\0001</DeviceID>
  <ProfileName>Photo</ProfileName>
  <WiaItem>{FB607B1F-43F3-488B-855B-FB703EC342A6}</WiaItem>
  <Properties>
    <Property id="6147" type="3">600</Property>
    <Property id="4103" type="3">3</Property>
    <Property id="4108" type="3">2</Property>
    <Property id="4106" type="72">{B96B3CAE-0728-11D3-9D7B-0000F81EF32E}</Property>
    <Property id="6154" type="3">0</Property>
    <Property id="6155" type="3">0</Property>
    <Property id="6164" type="3">0</Property>
  </Properties>
</ScanProfile>

<ScanProfile>
  <ProfileGUID>{814B8B4D-45B3-440D-B40B-BC34D10B21E5}</ProfileGUID>
  <DeviceID>{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}\0001</DeviceID>
  <ProfileName>Documents</ProfileName>
  <WiaItem>{FE131934-F84C-42AD-8DA4-6129CDDD7288}</WiaItem>
  <Properties>
    <Property id="3097" type="3">2</Property>
    <Property id="6151" type="3">5100</Property>
    <Property id="6152" type="3">6600</Property>
    <Property id="6147" type="3">600</Property>
    <Property id="4103" type="3">0</Property>
    <Property id="4108" type="3">2</Property>
    <Property id="4106" type="72">{B96B3CAF-0728-11D3-9D7B-0000F81EF32E}</Property>
    <Property id="6154" type="3">0</Property>
    <Property id="6155" type="3">0</Property>
    <Property id="3088" type="3">32</Property>
    <Property id="6164" type="3">0</Property>
  </Properties>
</ScanProfile>

PS: Yes, adding a new XML in directory will result in a new profile - just don’t forget to change its GUID value.

Changing FAT12 Label Under NAS4Free

Part of my encrypted NAS setup is also key storage on TmpUsb. Idea of such USB is to self-erase its data (and thus my encryption keys) when power is lost. It’s not a full-proof system but enough to ensure any thief will get away with hardware only.

TmpUsb device behaves just as a normal USB drive with a twist that label changes are triggering various special behaviors. If one is setting up such disk remotely, the most significant operation is done by changing label to “ARMED” to actually make it erasable upon power loss.

And therein lies the problem - NAS4Free contains no command that can change the label for FAT12 disk. Well, I guess we’ll have to make such command ourselves.

First a bit about FAT12 disk layout. Looking at the raw drive, the first 512-byte sector is occupied by master boot record. There we have layout of our partitions and their types. The only byte I am interested in is the partition type for the first partition located at the 451th position and holding a value 0x01 and denoting FAT12. This byte is important as to avoid accidentally overwriting some other disk upon label change.

The next two sectors belong to the FAT12 boot sector and are filled by a lot of important information. However, the label we’re searching for cannot be found albeit there is a very similar volume label field. Here we can also see, starting at byte 54, a type of file system. This time it’s written as FAT12 and is ideal as another double-check.

Nope, the paydirt is in fourth sector, the first 11 bytes are ones holding the disk label we need. You can see the whole sector using dd and hexdump:

dd if=/dev/da0 bs=512 skip=3 count=1 2>/dev/null | hexdump -Cv

The rest of sector (and a few afterward) are filled with directory entries using both short 8.3 MS-DOS name and long Unicode one. Quite interesting topic actually, but we need only to care about the first 11 bytes here.

The final script I ended up with actually uses dd internally and allows for setting custom label under NAS4Free’s limited FreeBSD environment. As it’s using bog standard bash, I expect it’s perfectly portable to other platforms too and modifying to do other manipulations of FAT structures should be easy enough.

And, as always, it’s available for download.

[2018-07-22: NAS4Free has been renamed to XigmaNAS as of July 2018]

Slow Ansible Response Using External IP

As I was playing with Ansible’s ad-hoc commands, I’ve noticed that one host was struggling. Any command I tried took 15 seconds more for it than for any other host.

ansible all -a date

Adding IP to /etc/hosts actually solved that trouble which strongly indicated toward issue actually being connected to DNS setup. But, why the hell was my temporary lab even using DNS? It was just a bunch of virtual machines and I definitely didn’t want to add all hosts by name. I needed another solution…

After a bit of investigation, I discovered the actual culprit - SSH daemon was trying to resolve IP address. For which purpose you ask? Just to write host name to its log.

The final solution was easy - just adding UseDNS no to /etc/ssh/sshd_config:

echo -e "\nUseDNS no" | sudo tee -a /etc/ssh/sshd_config'
sudo systemctl restart sshd

VPN-only Internet Access on Linux Mint 18.3 Via Private Internet Access

Setting up Private Internet Access VPN is usually not a problem these days as Linux version is readily available among the supported clients. However, such installation requires GUI. What if we don’t want or need one?

For setup to work independently of GUI, one approach is to use OpenVPN client usually installed by default. Also needed are PIA’s IP-based OpenVPN configuration files. While this might cause issues down the road if that IP changes, it does help a lot with security as we won’t need to poke an unencrypted hole (and thus leak information) for DNS.

From the downloaded archive extract .crt and .pem files followed by your choice of .ovpn file (usually going with the one physically closest to you). Copy them all to your desktop to be used later. Yes, you can use any other directory - this is just the one I’ll use in example commands below.

Rest of the VPN configuration needs to be done from the Bash (replacing username and password with actual values):

sudo mv ~/Desktop/*.crt /etc/openvpn/
sudo mv ~/Desktop/*.pem /etc/openvpn/
sudo mv ~/Desktop/*.ovpn /etc/openvpn/client.conf

sudo sed -i "s*ca *ca /etc/openvpn/*" /etc/openvpn/client.conf
sudo sed -i "s*crl-verify *crl-verify /etc/openvpn/*" /etc/openvpn/client.conf

sudo echo "auth-user-pass /etc/openvpn/client.login" >> /etc/openvpn/client.conf
sudo echo "mssfix 1400" >> /etc/openvpn/client.conf
sudo echo "dhcp-option DNS 209.222.18.218" >> /etc/openvpn/client.conf
sudo echo "dhcp-option DNS 209.222.18.222" >> /etc/openvpn/client.conf
sudo echo "script-security 2" >> /etc/openvpn/client.conf
sudo echo "up /etc/openvpn/update-resolv-conf" >> /etc/openvpn/client.conf
sudo echo "down /etc/openvpn/update-resolv-conf" >> /etc/openvpn/client.conf

unset HISTFILE
echo '^^username^^' | sudo tee -a /etc/openvpn/client.login
echo '^^password^^' | sudo tee -a /etc/openvpn/client.login
sudo chmod 500 /etc/openvpn/client.login

To test VPN connection execute:

sudo openvpn --config /etc/openvpn/client.conf

Assuming test was successful (i.e. resulted in Initialization Sequence Completed message), we can further make sure data is actually traversing VPN. I’ve found whatismyipaddress.com quite helpful here. Just check if IP detected is different then IP you usually get without VPN.

Stop the test connection using Ctrl+C and proceed to configure OpenVPN’s auto-startup:

echo "AUTOSTART=all" | sudo tee -a /etc/default/openvpn
sudo reboot

Once computer has booted and no further VPN issues have been observed, you can also look into disabling the default interface when VPN is not active. Essentially this means traffic is either going through VPN or not going at all.

Firewall rules are to allow data flow only via VPN’s tun0 interface with only encrypted VPN traffic being allowed on port 1198.

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out on `route | grep '^default' | grep -v "tun0$" | grep -o '[^ ]*$'` proto udp to `cat /etc/openvpn/client.conf | grep "^remote " | grep -o ' [^ ]* '` port 1198
sudo ufw enable

This should give you quite secure setup without the need for GUI.