PSU fickleness of Raspberry Pi

I’m not kind to my raspberry pi’s. I have a few, of varying pedigrees, tucked away in the attic or other inhospitable dusty places. A week ago, the imaginatively named pi2 went offline. Irritatingly, it takes the podium of my most inhospitable rpi, tucked in the attic, balanced on a rafter, in a tight spot an uncomfortably long crawl away from the hatch.

Still. Gotta be done. I’d tried switching it off and on again. Many times. That was easy enough, and can be done from a distance. Likewise, I cycled power on its network switch a few times too. I rarely go the wifi route unless it’s unavoidable. I mean, if you can get a power cable to it, it’s usually possible to get a bit of cat5 there too.

No joy. So I brought it down, blew out the dust, and plugged it in again using a spare PSU in my study. Nothing. Except a high pitch whine coming from the, well, where was it coming from? The PSU? The rpi? Yep, definitely the pi.

I’ve never skimped on PSUs for the rpi. I’ve never much understood them either. Opting usually for the recommended product rather than skimping on a cheaper option. Although buying anything branded on Amazon nowadays is a bit of a gamble. What you see in the nice picture is not always, or even often, what you get.

Still, here’s the situation. The rpi is a, er, well, what is it? It’s back up the loft, far away in dustville, but, according to the University of Google, it’s:

root@pi2-driveway:~# cat /proc/device-tree/model
Raspberry Pi 2 Model B Rev 1.1

… and the PSU that it had been happily running on since it was sent up the attic, was:

NorthPanda Model LA-520WF

In the study I plugged it in to a spare rpi PSU, an old RS favourite. And that’s where I heard the high-pitched whine …

I was assuming the rpi was goosed but had a final visit to the University of Google, and, even though the noise was definitely coming from the rpi itself, and not the PSU, I tried one more time with a different PSU.


I’m not sure when or where I bought this. According to my Amazon order history I bought this item on the 6 aug 2017 for an anker bluetooth speaker. I’m guessing that whatever it was once bought for is now jammed in a power bank, and the PSU was no longer required, until now. I’m glad I hung on to it though, because it fired up the rpi fine, and it’s back up the loft.

Another layer of security for WordPress

A simple way of deflecting brute-force attacks is to require an additional password to access the WordPress login screen. Lots of security plugins will do this for you, but again, sometimes it’s better to DIY.

I put a .htaccess file in the wp-admin directory and that almost completely worked, but mystifyingly, and irritatingly, there would be regular failed login attempts. Not very often. About very 20 minutes or so. But I was irked (I tell you), as I couldn’t work out why they were happening.

My .htaccess file looked a bit like this:

AuthName "my site"
AuthType Basic
AuthUserFile <myauthfile>
Require valid-user

A few searches made references to differences between apache 2.2 and 2.4, and I thought that perhaps it was a syntax thing. But that didn’t seem to be it.

I did two things in the end, so I’m not sure what fixed it.

  1. I modified the .htaccess entry to specifically reference the file wp-login.php.
  2. I moved the .htaccess file to the parent directory.

So the relevant code looks something like:

<FilesMatch "wp-login.php">
AuthType Basic
AuthName "Secret stuff"
AuthUserFile <my auth file>
Require valid-user

Disable xmlrpc.php

Thanks to the Simple History plugin, the first thing I noticed on my new WordPress install was hundreds of brute-force login attempts:

Anonymous user from x.x.x.x 4:25 pm (less than a minute ago)              Failed to login with         username "dougie" (incorrect password entered) warning       Showing 212 more     

And then more alarmingly, immediately the same thing on a new test user I set up a few minutes later. Of course, just because frustratingly I can’t work out how the attacker extracts the new WP username immediately doesn’t mean it ain’t happening. But the attack vector, so to speak, was the xmlrpc.php file.

Several ways to tackle this, and initially I used a security plugin to fix it. But given the choice, I’d rather do things like this manually so I have a better idea what’s going on, and maybe learn something too.

I pasted the code suggested from into my .htaccess file:

    # Block WordPress xmlrpc.php requests
    <Files xmlrpc.php>
    order deny,allow
    deny from all
    allow from

changing the allow from to the static IP for my regular connection, although strictly speaking I don’t think I need that and will try taking it out altogether sometime.

Publishing failed – JSON error

Migrating WP blog to my VM. New install of WordPress. Test posts with Guttenberg (Block) Editor. Following error:

Publishing failed. Error message: The response is not a valid JSON response.
Publishing failed. Error message: The response is not a valid JSON response.

An interesting rabbit hole. Lots of searches rightly suggested that using the classic editor would get round the problem. Or that by changing the permalinks settings to Plain would fix it. It did, but not much help if you want your permalink settings set to something else.

Eventually I discovered that the issue for me was with the .htaccess file not being processed, which was fixed by adding something along the lines of

<Directory /var/www/html>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted

to the /etc/apache2/apache2.conf file (on Debian Buster). This worked for me, but I get the impression it’s better practice to edit the files in /etc/apache2/sites-available instead for any local code in case apache2.conf gets overwritten on an upgrade. Probably also need to do a:

a2enmod rewrite
systemctl restart apache2

So for me the cause of the error message was quite obscure. Useful link:

Findster Duo – First Impressions

Cats are a worry. On the one hand we want to let them come and go as they please so they can go out, play, chase mice, climb trees, and be cats. The trouble is, they go out, play, chase mice, climb trees, and get into all sorts of scrapes. Being cats.

The real worry is not seeing them for days on end though. Brothers Willow and Mr Mittens like the summer. In the summertime, when the weather is fine, they go and talk to the students, pretending to be unloved and unfed. It’s only by putting webcams on their feeding bowls and bed that we realised they still lived with us.

On a recent holiday we left the cats at home with a homesitter as normal. But on four separate days we had phone calls from Chapel Heights, from alarmed students who’d found Willow mooching around their flats. As the crow flies Chapel Heights is only a few hundred metres from our house, but it’s near a busy dual carriageway and Willow doesn’t have any road sense.

I’ve tried a tech approach. Tile works ok. But its range is short and its use is limited. So now I’m trying another tech approach.

You’d think there’d be tons of tech for monitoring your pets. And there is, but it’s still a maturing market and there’s a long way to go. Trackers for dogs seem a lot more common than those for cats, which makes a lot of sense. The devices are still quite bulky and cats a quite small.

Half an hour ago I attached a Findster Duo to Willow’s collar. It’s light, but bulky, but he seems ok with it. I took it off its supplied strap and threaded Willows collar onto it directly. Let’s see how it goes.

Willow trying out the Findster Duo
Willow unimpressed by the big Findster Duo

Permissions on /dev/video0 running motion on Raspberry pi

[ Update: 1 July 2020 ]

I can’t say my blog sees a lot of action or sets the world on fire. That’s the way I like it. But, and I’m not saying it keeps me awake at nights, this blog post regularly sees a lot of hits. It’s about 4 years old now, and in raspberry pi times, that’s a long time. I can’t recall having had this problem for ages, and on all my new-builds it seems to have just, gone away. I still have issues with the rpi deciding on its device file, and I still don’t understand them, but I’ll get around to that one day …

Wisdom of the ancients

Post from Feb 2017

It pretty much happens that every time I setup motion on a new build that it doesn’t work right away. There’s usually a few things I miss. Usually it’s an error reading from the camera, the logs reporting something like:

Feb 17 10:51:21 pi2 motion: [1] [NTC] [ALL] motion_init: Thread 1 started , motion detection Enabled
Feb 17 10:51:21 pi2 motion: [1] [NTC] [VID] vid_v4lx_start: Using videodevice /dev/video0 and input -1
Feb 17 10:51:21 pi2 motion: [1] [ALR] [VID] vid_v4lx_start: Failed to open video device /dev/video0:

which invariably means the camera is broken or I’ve misconfigured my motion setup.

This one was puzzling me a little though. It’s on a raspberry pi, imaginatively titled pi2, and it was failing to read from the camera. The reason I was puzzled was that the hardware combination had worked before. What had gone wrong was the micro-SD card, and I’d done a new raspbian build, copying over the relevant motion configuration files from the old card.

Clearly the difference had to be something to do with the OS. So what was different? I’d taken the opportunity of the SD failure to download and install the latest version of raspbian and everything looked good to go.

Running motion as root worked fine, both against the vanilla configuration file, and the customised config file I wanted to use. So let’s have a look at the video file:

root@pi2:~# ls -l /dev/video0
crw-rw----+ 1 root video 81, 0 Feb 17 11:17 /dev/video0

Looks about right. Ah, the video group. I need to be in the video group. That might be it:

root@pi2:~# usermod -G video dougie

Restart motion and try again. Nope. Let’s have a closer look at that file.

On pi2 (with a new version of raspbian):

crw-rw----+ 1 root video 81, 0 Feb 17 11:17 /dev/video0

and on pi1 (another rpi, running motion fine, with a slightly older version of raspbian):

dougie@pi1:~ $ ls -l /dev/video0
crw-rw---- 1 root video 81, 0 Jan 8 22:54 /dev/video0

Very similar, but not identical. The newer version of the device file has and extra + at the end of the permissions bit, which means the file has extra security permissions set. I’ve not had cause to use Access Control Lists (ACLs) before, and it was a temptation just to chmod 777 on the file as a quick and dirty, and lazy, fix, but I thought it’d be better to take a closer look. Using the getfacl command:

root@pi2:~# getfacl /dev/video0
getfacl: Removing leading '/' from absolute path names
# file: dev/video0
# owner: root
# group: video

I could see that I (me: dougie) did not appear on the list, although the default rpi user pi does. I rarely use the pi account. One of the first things I do is change its password, create my own user, and use that instead. So it looks like the default install for raspbian allows user pi to access /dev/video0. It also looks like I can’t access the file, despite being a member of the group video.

I found a good command summary on the (now a dead link) centos documentation website, and using that gave myself access:

root@pi2:~# setfacl -m u:dougie:rw /dev/video0

That did the trick.

Trackr Bravo battery life

The TrackR does many things badly. The Tile just does one thing well.

Another email from Trackr – this time about their new Battery Program. This is about a wizard wheeze where you can pay Trackr for replacement batteries.

Reading on in their email there’s a section subtitled:

What if every time your battery was dead, you had to buy a brand new device?

Well, what indeed. One wonders what can they be alluding to? I wonder if it’s another well known Bluetooth tracking device that has to be replaced about once a year when the battery nears end of life?

The TrackR Bravo is a slick, elegant looking device, and looks better than the Tile. But having bought a handful of both devices as soon as they hit the market, the Tile is the winner by a mile. On reliability, build quality, and Customer Service the Tile is the winner. My experience of using Trackr has been one of interminable irritability. I’ve tried its various features and abandoned them finding them gimmicky, unreliable and pointless. I’m struggling to think of any redeeming features, and the closest I can get is that the Bravo looks ok.

Trying a different brand of battery
Batteries …

I’ve just replaced the batteries in all my Trackr Bravos. The ones I’ve removed were brand new Maxells. Perhaps I was unlucky. I thought Maxell were a pretty good brand. This time I’m replacing them with GP batteries. I only found the batteries were dead by accident, as I thought I get more than 3 months out of the Maxells. It didn’t occur to me to check connectivity every day, and on the TrackR app (unlike the Tileapp), you need to check each TrackR individually – whereas with Tile you can scan all your tiles’ status in one glance.

I’ve had Tile and TrackR since they became available in the UK – and have been running them head to head since I bought them. It’s a very unequal contest. Give me the Tile any day.

TrackR Tile Head to Head
Tile and trackr

Outlook webmail won’t let you login if password renewal is due

which sorta makes sense.

But in Exchange 2013 it’s possible to change your password in OWA without logging into AD so if a user is scheduled to change their password the next time they login, I thought OWA might force a password change. Actually, thinking about that, how would that work? It would have to automatically present the change password dialogue. Perhaps that’s not possible.

Just need to remember that for users who don’t log into AD directly on a PC, but just use OWA all the time, forcing them to change their password on next login won’t work.

Web searches don’t reveal much, but if I understand Change Password Feature in Outlook Web App correctly, it’s WAD.

Find Willow’s Collar

What a difference a day makes.

Yesterday I was wondering on whether it’s possible to set up a dumb ‘slave’ iPhone to act as a part of the hive mind and pass on location info about our cats. Today Willow has wandered in, sans collar, and that means no tile either. I haven’t lost my cat, but I have lost his collar.

I’ve marked Willow’s Collar as Lost. I’ve wandered round the garden and the street staring at my iPhone at the slowly rotating grey circle. Nothing yet.

Let the games begin …

my Tiles have arrived

So almost a year after first placing my order my tiles have finally arrived.

the tiles have arrived

First impressions? Quite similar to others – they’re bigger than I expected, but light too. When attached to the cats’ collars the tiles can look a little oversized although this seems to bother me more than it bothers them.

Rosie showing off her new tile
Rosie unimpressed with her tile

The tile uses bluetooth and as such its range is nothing amazing. I’ve dabbled with bluetooth location devices and know that the “works up to …” type claims need to be treated with some skepticism. So with realistic expectations I was unsurprised to find that I was lucky if detection would work from one end of the house or garden to the other, especially if there’s a brick wall or tree in the way.

Willow with new tile on his collar

The most intriguing aspect of the tile concept for me is the idea of the hive mind. Anyone else who has the tileapp installed on their iPhone or iPad should (in theory) be picking up my tiles if they’re in range of that person’s IOS device. This begs the rather interesting question, how many tiles are there in Durham? Given that mine have just arrived and I ordered mine pretty early on, I wouldn’t be surprised if the answer is close to zero. Especially as a fundamental part of the design philosophy is that you don’t know if you’re picking up someone else’s tiles and passing the location info on.

I ordered 8 tiles, a decision partly based on cost, and partly because the tileapp can only register 8 tiles to an account. I’m not sure how that works if you want some more tiles. Perhaps you have to set up multiple accounts. Eight tiles is a nice number. That’s one for each cat, keys, wallet and one or two to experiment with.

However the main problem I’m having with my shiny new tiles is connected to a pretty irritating limitation regarding the amount of accounts that can be registered to a particular tile. Bluetooth only allows one IOS device to be connected to a tile (or any other bluetooth peripheral for that matter) at any one time. Tile explain this in an FAQ and there’s some promising sounding developments about sharing devices in the pipeline.

No matter I thought – I have a spare iPhone after upgrading to the iPhone 5S. My old iphone 4S is still working fine so I decided to install the tileapp on that too and join the Hive Mind. It doesn’t seem to be possible to do much in the app without creating an account but no problem. I created another account with no tiles registered (although it keeps bugging me to do this). I think of this as a slave account. As far as I understand it anyone with an iPhone or iPad should if they wished be able to install the app and act as a sort of volunteer conduit of tile locations. I’ve tried this and it doesn’t work. In theory my iPhone 4S should sit quietly at home and covertly collect tile location info and pass it on the the hive mind. But it’s not working.

This is a snapshot of the app driving home after an overnight stay away. According to this screenshot the three cats, Rosie, Willow and Mr Mittens have been out of range for around a day. This isn’t the case: they are at home within bluetooth range of an iPhone 4S logged into a tile account.

Logging the iphone into the ‘live’ account sorts things out and the iPhone 4S at home faithfully notes the ‘last seen’ location of the various felines so the handset is working, as is my iPad. Which rather begs the question – if someone else is running the tileapp on their iPhone on their account – will it pick up my tiles and pass the information on? I suspect it may not and I can’t think of a way of testing this apart from what I’ve been doing, which would strongly suggest it doesn’t work. I emailed support via the tile website a few days ago, nothing back yet.