Sunday, June 3, 2018

Enabling UART on the Beaglebone Black

To enable the UARTs with the recent console Debian image for the Beaglebone Black, add these lines to sudo nano /boot/uEnv.txt

Also run this if you're running the bone off an SD card, AND the eMMC does not have an up-to-date uboot.
sudo dd if=/dev/zero of=/dev/mmcblk1 count=1 seek=1 bs=128k
It seems that some recent changes to uboot have made these obsolete:
cape_disable=bone_capemgr.disable_partno=... cape_enable=bone_capemgr.enable_partno=...
They used to work before 4.4.x came about. Just bits and pieces gathered from forums plus a lot of trial and error.

Friday, February 23, 2018

Restore MySQL database from dump file

When restoring a MySQL db from a .sql file (such as an SQL dump file created by mysqldump), the login credentials on the target (including root) may be overwritten by the source .sql file if the .sql file was created with the --all-databases option.

RabbitMQ TLS

After copying the ca cert and key files, specify their locations in RabbitMQ's config file (/etc/rabbitmq/rabbitmq.config). Make sure the user "rabbitmq" can read them, especially the key file. Otherwise TLS connection attempts would just get stuck with no error message showing up in server nor client.

Thursday, December 7, 2017

Cloning a Raspberry Pi SD card

The goal is to clone the SD card of a Raspberry Pi after setup and installation, perhaps for backup or to make more copies of the same setup. Copying the SD card as an image file (.img) onto a regular machine is simple - just install Win32DiskImager (Windows) or Etcher (Windows/Mac) and click through the prompt. The tricky part is writing the .img file back into other SD cards.

All SD cards are not made equal. Not for cards that claim to have the same capacity. Not even for cards of the same stated capacity that come from the same Amazon order. Off by one byte and Win32DiskImager / Etcher would complain about the card being too small to hold the image. The simple solution is to use a bigger card. Card sizes grow by a factor of two, so you'd need a 32GB card to hold the image of a 16GB card (pretty much the smallest size you can find in Q4 2017). It works, but how'd you backup your 32GB card?

Another way to get around this is to resize the .img file. Usually very little space is actually used on a newly prepared Pi (a 2017 Raspbian Lite image with RabbitMQ, pika, numpy, etc. all installed for both Python 2 and 3 takes only 1.6GB of space), so most of the card is actually empty and can be trimmed from the image file. The process goes roughly as follow: boot a machine using a GParted / Ubuntu Live image, mount the storage device (e.g. USB stick) holding the .img file, mount the .img file as a loopback device, resize the file system using GParted, unmount the loopback device, then truncate the .img file.

First boot into the live image (if you are using the Ubuntu Live image, make sure you don't accidentally install it). You will also need to mess with the boot order of your machine at least temporarily. There's extensive resource elsewhere for this. Once in, mount the USB drive holding the .img file (if it isn't automatically mounted; use lsblk to find out what the device name is). The partition on my USB drive shows up as /dev/sdb1. My .img file is named node-080.img):

sudo mkdir /media/usb0
sudo mount /dev/sdb1 /media/usb0

Now mount the .img file as loopback device:

sudo losetup -f (take note of its output; mine is /dev/loop1)
sudo losetup -P /dev/loop1 /media/usb0/node-080.img

Launch GParted:

sudo gparted /dev/loop1

Resize the second partition (the first one is the /boot partition, which is tiny) to the content, leaving ~200MB of empty space at the end. Commit and exit.

Unmount the loopback device:
sudo -d /dev/loop1
Now truncate it, but first find out where the last sector of the partition is:

sudo fdisk -lu /media/usb0/node-080.img

Take note the sector size (512 bytes for me) and End sector. Then truncate:

truncate --size=$[(END_SECTOR+1)*512] /media/usb0/node-080.img

ls -al

Thursday, November 2, 2017

Missing stack trace in Python Flask on CentOS

To redirect Flask app traceback (exception, logging.error() etc.) to Apache's error log, add

import app

Otherwise all I get was a "500 Internal Server Error" with no debug information anywhere in the server.

For some strange reason, with Apache 2.4 on CentOS 7 using mod_wsgi and Python Flask, traceback actually goes to /var/log/httpd/ssl_error_log instead of /var/log/apache2/error.log on Ubuntu Server (even with SSL).

There are some other strange things with CentOS too, like the site would be accessible via http, but when https is used it would throw "Internal Server Error" unless the permissions of the folder that hold the Flask code are changed to allow R and X for user apache. It makes sense that Apache requires R and X, but that doesn't explain why it would work for http but not https.