Random Musings of an Insane Mind

I had a Raspberry Pi 3B with the PiCam 2 that stopped working. To make the video better, I needed a shroud to prevent picking up light in the room when it was dark outside and ultimately, three PiCam 2’s died while working with that shroud. I ordered a PiCam 3 the other day to see if I could get it to work with my Pi 3B, and alas, it wouldn’t work. So, I used a 2GB Raspberry Pi 4.

To set up streaming in nginx:

In your main nginx.conf you need:

rtmp {
    server {
        listen some_ip_address:1935;
        application live {
            live on;
            interleave on;

            hls on;
            hls_path /tmp/hls;
            hls_fragment 5s;
        }
    }
}

Then in your site config:

    location /live/ {
        alias /tmp/hls/;
    }

Your Raspberry Pi should run a recent image. You’ll need to install rpicam-apps to replace rpicam-apps-lite which is installed by default:

sudo apt-get install rpicam-apps

The script you’ll create a script called livevid:

#!/bin/bash

date

while [ 1 == 1 ]; do
    rpicam-vid -v 0 -n -t 0 -g 10 --bitrate 2500000 --inline --width 960 --height 540 --framerate 30 --codec libav --libav-format flv --libav-audio 0 --audio-bitrate 8600 --av-sync 200000 -n -o 'rtmp://url_of_nginx/live/cam' --awb daylight

done;

And your crontab entry (crontab -e)

@reboot cd /home/user;/usr/bin/nohup /home/user/livevid &

With this, you can at least alter the parameters to make the image quality better, or use less bandwidth.

My server backup script broke a while back – probably around Dec 14th, 2014 with a python update that debian pushed which broke my virtualenv. This isn’t the first time debian has broken virtualenvs and my last post was about this. In addition the backup script filled up the backup drive without triggering an exception which is odd, because the source didn’t exceed the size of the destination drive even prior to things breaking. The script just does a simple rsync so it wouldn’t have duplicated symlinks.

It finished its backup last night in about 30 minutes (usually takes 5-7 minutes) and now has 6gb free which matches my server.

I recognized my backups were failing because debian pushed another change where varnish overwrote the startup script without asking – and I had to reconstruct that file from the machine configuration.

At times, I wonder why OS upgrades push breaking changes without any mention. The conversion to systemd was also

Of course, a new upgrade to Python on my devbox and the virtualenv breaks. And, merely reinstalling the virtualenv over top doesn’t work.

This is where you need to make sure your python project has an adequate setup.py to install the dependencies or you’re going to end up reinstalling by hand.

First, deactivate and make sure you’re not in the virtualenv. Get into the virtualenv’s top level directory and:


cd /virtualenvroot
rm -rf bin/ include/ lib/ local/
virtualenv /virtualenvroot
source bin/activate


Then, rerun setup.py with either install or develop and you should be set.

I was called in to fix a number of WordPress sites that had been hacked. Many were running older versions of WordPress and thankfully weren’t running SetUID, so, the damage was limited to exploit scripts running in some of the world writeable directories.

After cleaning up the sites, upgrading them to the latest version of WordPress and scanning for additional exploits, I added a number of rules to each of the Apache VirtualHost configs on his server.

<Directory /var/www/domain.com/wp-content/uploads/>
AllowOverride none
RemoveHandler .cgi .pl .py
<FilesMatch "\.(php|p?html?)$">
  SetHandler none
</FilesMatch>
</Directory>

<Directory /var/www/domain.com/wp-content/cache/>
AllowOverride none
RemoveHandler .cgi .pl .py
<FilesMatch "\.(php|p?html?)$">
  SetHandler none
</FilesMatch>
</Directory>

These rules need to be placed in the VirtualHost configuration and prevent PHP, cgi scripts, Perl and Python files from being executed in the two directories that WordPress is allowed to write to. To prevent other tampering, we disallow Overrides which prevents hackers from creating a directory and including their own .htaccess that would enable PHP or CGI to be parsed.

Since making these changes, we’ve seen a few files dropped into the uploads directory, but, none have been executable.

A few days ago a client came to me and asked how they could back up a lot of data on a nightly basis that only had a few changes. Many solutions with their current hosting providers were discussed, Amazon’s S3 and Glacier, but, none gave him the flexibility he was after. So, the logical conclusion here was Amazon EC2 + Elastic Block store (EBS).

We created a micro instance of Debian, logged in and added rsync, created a volume large enough to hold his backup with some room for growth and with a little command line magic he was able to mirror his data to EBS. Of course, the instance didn’t need to be running all the time so he would need to start it, run the rsync, shut it down.

After some thought I decided it would be easy enough to write a quick Python script using boto to start the instance, rsync the volume and stop the instance. If he needed access to the instance he could start it manually and log in when needed. Now, his backups could be run via cron on a regular basis.

I put the code on GitHub: https://github.com/cd34/spawncamping-octo-ninja

Most of the instance startup situations are handled and so far it seems robust.