Back in October last year, I posted a note about the usage of variable substitution in lighttpd’s configuration files. In fact I got that post very slightly wrong (now corrected) in that I showed the test I applied in the file as: “$HTTP[“remoteip”] !~ “12.34.56.78″”. (Note the “!~” when I should have used “!=”). This works, in that it would limit access, but it is subtly wrong because it does not limit access in quite the way I intended. I only noticed this when I later came to change the variable assignment to allow access from three separate IP addresses (on which more later) rather than just one.

The “!~” operator is a perl style regular expression “not” match whilst the “!=” operator is the more strict string not equal match. This matters. My construct using the perl regex not wouldn’t actually just limit access solely to remote address 12.34.56.78 but would also allow in addresses of the form n12n.n34n.n56n.n78n where “n” is any other valid numeral (or none). So for example, my construct would have allowed in connections from 125.134.56.178 or 212.34.156.78 or 121.34.156.78 etc. That is not what I wanted at all.

The (correct) assignment and test now looks like this:

var.IP = “12\.34\.56\.78|23\.45\.67\.78|34\.56\.78\.90”

$HTTP[“remoteip”] !~ var.IP {
$HTTP[“url”] =~ “^/wp-admin/” {
url.access-deny = (“”)
}

Which says, allow connections from address 12.34.56.78 or 23.45.67.89 or 34.56.78.90 but no others.

For reference, the BNF like notation used in the basic configuration for lighty is given on the redmine wiki.

I’ve been a lighty user for many years now, having junked apache when it became obviously overweight for my target devices (the slugs in particular). Trivia is, of course, powered by lighty as are all my other websites.

Lighty’s configuration file syntax is reasonably simple to understand, and is well documented on the Redmine wiki. The guys at Calomel.org have also put together quite a nice introduction to lighty. If you haven’t tried it, and find that apache is becoming too much of a resource hog for you, I’d recommend that you give lighty a run.

I use lighty’s access control mechanisms to prevent random bots and bad guys from reaching trivia’s administrative functions and I do this in much the same way as I limit access to my ssh and openvpn daemons – I restrict access to the fixed IP address assigned to my router by my ISP. So in the lighty virtual host configuration file I use the following construct:

$HTTP[“remoteip”] != “12.34.56.78” {
$HTTP[“url”] =~ “^/wp-admin/” {
url.access-deny = (“”)
}

That says: if the remote IP address is not 12.34.56.78, then deny access to the wp-admin directory.

Now I have several virtual hosts running and I also protect several directories. I also use a similar construct to redirect all my own access to my websites to https on port 443 so that I can always be certain that my own connection is encrypted and my authentication credentials will be protected. This means, of course, that I have several entries of the form: “if this IP address, then take this action” dotted around my configuration files. Not good. A recent change of ISP meant that my IP address has changed and I needed to edit my configuration files or find myself locked out. The most important files to change were my iptables rules so that I could still get ssh access on all my VMs. This didn’t take long because I have all the important configuration details (ssh IP addresses and ports, openvpn port, DNS addresses etc.) defined at the head of the bash script. One change is all that is necessary and bash variable substitution takes care of the rest. But my lighty configuration files were a different matter and I had to check carefully to ensure that I didn’t miss an important change. That’s just daft. Surely lighty allows for variable assignment and substitution? And of course it does, I just hadn’t checked before now.

The syntax looks like this:

At the head of the configuration file make an entry of the form:

# set our fixed remote ip address used in access control

var.IP = “23.45.67.89”

and then change the earlier configuration lines to:

$HTTP[“remoteip”] != var.IP {
$HTTP[“url”] =~ “^/wp-admin/” {
url.access-deny = (“”)
}

Simple, and I feel a complete idiot for not noticing this before.

I have recently been building a new NAS box (of which, possibly, more later). In fact the build is really a rebuild because I initially built the server about three years ago in order to consolidate a bunch of services I was running on assorted separate servers into one place. That first build was a RAID 1 array of two 2 TB disks (to give me a mirrored setup with a total of 2 TB store). At the time that was sufficient to hold all my important data (backed up both to other networked devices and to standalone USB disks for safety). But I have just upgraded my main desktop machine to a nice shiny new core i7 Skylake box with 16 GB of DDR4 and a 3 TB disk. That disk is already two thirds full (my old machine had a rather full 2 TB disk). This meant that my NAS backup storage requirements exceeded the capacity of my RAID 1 setup. Adding disks wouldn’t help of course because all that would do is add mirror capability rather than capacity. So I decided to upgrade the NAS and bought a bunch of new 2 TB disks with the intention of setting up a RAID 5 array of 4 disks, thus giving a total storage capacity of 6 TB (8 TB minus 2 TB for parity). Furthermore I initially looked at using FreeNAS rather than my usual debian or ubuntu server with software RAID simply because it looked interesting and, with plugins, could probably meet most of my requirements. But I could not get the software to install properly and after three abortive attempts I gave up and decided that I didn’t really like freeBSD anyway….

Continue reading