Category Archives: Linux

mosquitto connection refused

Hi all, if you’ve just upgraded mosquitto server on some flavour of linux and wondered why all your mosquitto subscribers and publishers on your network have just started failing, you may have fallen foul of this:

the new mosquitto 2.0 requires a ‘listener’ be configured to the ports required, or else it will only listen to the localhost:1883.

So if all your clients start failing after, edit the configuation and add the following line to the top:

“listener 1883”

See the post here for more information: https://mosquitto.org/documentation/migrating-to-2-0/

Swappiness in linux

Shamelessly stolen from wikipedia because they’re thinking about removing this, as  “Wikipedia is not a howto”. *sigh*.

 

With kernel version 3.5 and over, as well as kernel version 2.6.32-303 and over, it is likely better to use 1 for cases where 0 used to be optimal.

To temporarily set the swappiness in Linux, write the desired value (e.g. 10) to /proc/sys/vm/swappiness using the following command, running as root user:

# Set the swappiness value as root
echo 10 > /proc/sys/vm/swappiness

# Alternatively, run this
sysctl -w vm.swappiness=10

# Verify the change
cat /proc/sys/vm/swappiness
10

# Alternatively, verify the change
sysctl vm.swappiness
vm.swappiness = 10

Permanent changes are made in /etc/sysctl.conf via the following configuration line (inserted, if not present):

vm.swappiness = 10

10 is generally good for ‘I don’t want swapping to happen except if you *really* need it.

 

Varnish weird error

Are you getting a weird error from varnish that you’re having trouble working out? Is it cryptically saying that there’s an issue with your host definition in your VCL?

Expected ID got ';'
 (program line 165), at
 ('input' Line 20 Pos 30)
 .first_byte_timeout = 120;
 -----------------------------#

You need to add a time unit to your timeout definitions — ‘s’ for seconds, ‘m’ for minutes.  Stupid cryptic error is dumbly cryptic. Grrr.
https://varnish-cache.org/lists/pipermail/varnish-bugs/2011-August/003983.html

Varnish nsca logging on systemd system with x-forwarded-for

So, you have a Varnish server running systemd, which is behind a reverse proxy for SSL like nginx, and you can’t work out how to make varnishncsa log IP addresses from a specified header? Well, it’s a bit of a pain in the neck really. You need to override the systemd service file, which is like systemd’s version of the init scripts. Due to it being systemd, this is not just a case of editing a file…

For Debian, you can use the service file below, and paste it into
/etc/systemd/system/varnishncsa.service

Once done, you need to reload systemd’s service listing itself;
$ systemctl daemon-reload

Congratulations, you now have varnishncsa logs including the visitor’s real IP address, as specified by Nginx. Change the name in “{X-Forwarded-For}” to change the header name, for example if you want CloudFlare’s view of the client’s IP address, use “CF-Connecting-IP”

[Service]
 RuntimeDirectory=varnishncsa
 Type=forking
 PIDFile=/run/varnishncsa/varnishncsa.pid
 User=varnishlog
 Group=varnish
 ExecStart=/usr/bin/varnishncsa -a -w /var/log/varnish/varnishncsa.log -D -P /run/varnishncsa/varnishncsa.pid -F '%%{X-Forwarded-For}i %%l %%u %%t "%%r" %%s %%b "%%{Referer}i" "%%{User-agent}i"'
 ExecReload=/bin/kill -HUP $MAINPID

 

mysql/mariadb failing to start under systemd

If SystemD MariaDB/MySQL is failing to start, make sure your logs directory is set correctly. Sometimes this is caused by failing to correctly make sure the directory is moved.

You’ll see an error log in the journal as follows;

Nov 27 18:24:55 db-a mysqld[28677]: 2017-11-27 18:24:55 140273229838208 [Note] /usr/sbin/mysqld (mysqld 10.2.10-MariaDB-10.2.10+maria~jessie-log) starting as process 28677
Nov 27 18:24:55 db-a systemd[1]: mariadb.service: main process exited, code=exited, status=1/FAILURE
Nov 27 18:24:55 db-a systemd[1]: Failed to start MariaDB database server.
Nov 27 18:24:55 db-a systemd[1]: Unit mariadb.service entered failed state.

SetEnvIf https (Tell apache we’re behind a reverse proxy handling SSL)

This is complicated, but I need to remember this, so I want to put it somewhere. You need to add this to apache config / .htaccess file to get apache to correctly set the HTTPS environment variable when the backend is secure. It trips based on the X-Forwarded-Proto header being ‘https’.

SetEnvIf X-Forwarded-Proto "https" HTTPS=on

Heartbleed, the media, and passwords. I might be annoyed.

This is a rant. It’s a long one. I’ve not proof-read it much, there’ll be mistakes.

Opening

So, unless you’ve been hiding under a rock of late, you’ve heard about Heartbleed. Heartbleed is a bug in one of the core programs used in the open-source world to keep secret those things you need, like credit card details. This particular bug is important, because it can leak information that shouldn’t be leaked, like credit card details. Just click the link above, it gives a really good basic idea as to how it works. It mainly affects those things protected by SSL.

So, now that everyone knows what it is, why is it important? The information leaked can be anything that the computer (hence -forth called “server”) responsible for keeping the website involved on the internet has in it’s memory. That can include, requests for websites, file transfers, emails, ssl certiticates, ssl keys, credit card numbers and passwords.

Passwords, memory and maths

Now that last one, that’s the one the media, and certain people, have been shouting about. This bug has the small potential to leak passwords. However, this is totally not as serious as it sounds. Passwords are only kept in plain text for a short time – normally, as long as it takes to hash them (one-way-encrypt), and check them against a database. So, your passwords aren’t sitting out in the open, for anyone to steal. Additionally, you have to have entered your password within a second (or two at the latest) of someone using this bug to pull information from a server. As problematic as this bug is, it’s limited. It lets you get 64 kilobytes of information from the server memory. That sounds a lot, till you remember that modern servers have up to 16,777,216 kilobytes, or 262,144 blocks of 64KB. Even servers a few years old (and in server terms, that can be really quite old) have 4,194,304 kilobytes, or 65,536 blocks of 64KB. So, someone has to have managed to use this bug, to grab exactly that block at the right time, to get your password. Also, trust me, we would notice if someone started reading that much information out of our servers constantly. It would be obvious something was wrong. Additionally, not every server is vulnerable to this weakness. Those running IIS, or an older (but still patched) version of operating systems used to host websites remain safe. It’s something like 2/3rds of sites, and crucially, only those 2/3rds of servers setup for SSL.

So, why all the “RESET ALL YOUR PASSWORDS!” screaming? There is a small chance of grabbing an SSL key. Now, due to the way this bug works, this is more likely than other things to have happened. Why is the key important? It’s the set of random numbers that says you ‘own’ a certificate. So in theory, it can be exposed. Why is this a problem? With the key, you can pretend to be the person for whom it was created — if you got google.com’s key, you could pretend to be google.com. Now, this *still* isn’t that easy to use, you basically have to perform a Man In The Middle attack, which is hard, and complex, and will only get you really limited information, depending where you can do it.

No, this is not as serious as it sounds

So, why have I been tweeting lots saying you shouldn’t rush out to reset all your passwords? Three reasons. The first; the likelihood of anyone actually getting your password is really, really really small. Remember, there’s that (at best) 65,536 places your password could be, and only 2 seconds to find it before it vanishes. Per affected website. Add that to the fact that these bugs are hard to find, and using them to get information is hard. Using them to get useful information is also hard – all the bug comes back with is a load of data you have to run through conversion routines to get anything out of. Additionally, due to the way this data is stored, there’s no guarantee it’ll be easy to match your password to your username, which is crucial if you don’t want to have to guess usernames.

My second reason is one of worry about the affect telling those who aren’t used to strong password security will have. You’re going to be telling people to dump every single one of their current passwords and start again. It’s already really bad – the top 2 passwords of last year were “123456” and “password”.  So, though I have no studies on this, I would bet, with hard cash, that forcing those not using good passwords to reset their passwords with fear, will weaken passwords as a whole. I suspect that we’ll find a lot more weak passwords, and a lot more passwords shared amongst websites in the next few batches of password leaks.

Finally, my third reason. Evidence. We’ve had no evidence of large scale, source-less password leaks recently. Hackers, especially some of the nicer ones have a habit of dumping their finds publicly, and a large-scale capture of passwords would show up in activity around the internet. Additionally, passwords aren’t the only thing heartbleed can expose. It can expose credit card numbers. And the credit card companies do not like sites to whom they’re traced back a hack. In fact, they have a habit of forcing said companies to go through a rigorous, lengthy, and painful auditing process, to find out exactly *how* the passwords leaked. The security community would have heard of these audits turning up nothing, of credit card data vanishing out in any significant quantity, or even the audits would have thrown up the bug.

Media

So, this password thing. It’s being pushed by the media, and by the guys who created the ‘heartbleed’ website as a much bigger impacting issue than it really is. Now that the bug is out in the open, script-kiddies will start using the heartbleed website, as will advanced state agencies. I’ve heard some rumours of people seeing internet-wide scans originating from state agencies, shortly after the bug was announced. So, it’s important that it’s patched quickly, it’s a big problem for the tech community, but with the low chance of password exposure, it’s not that important. So, why are the media saying “CHANGE ALL YOUR PASSWORDS”. Two reasons mainly, first is that’s a far better headline than “There was a bug. We’ve fixed it.” The second, is that that’s the response we, the hosting & security community, have ingrained as ‘the’ response to any sort of compromise. Yahoo got hacked? Change your passwords. last.fm got hacked? Change your passwords. So, when they hear about this hack, which they do not understand, they fall back on the thing they know, and since this bug affects ~60-70% of ssl protected servers, they think “ALL” instead of just a limited set.

Responsible Disclosure – how not to do it

In my opinion, the heartbleed release is a perfect example of how NOT to do responsible disclosure, no matter what certain lucky parties claim. First, create a website with inflammatory content. Then, get those who have insider access to patch. But crucially, don’t inform operating systems before you make it public. Don’t let anyone know in the security teams of Ubuntu, Debian, RedHat or SUSE. You know, just the people who actually have to *create* and *deploy* the patch to the millions of affected servers. Don’t let big publishers or sites know (Yahoo, BBC, Facebook). Instead, publish your site, and wait for the shitstorm to hit, as the media companies take this up, shout about it, and make customers scared.  Now, in a boon, the debian OpenSSL team got a patch out for this bug, 30 minutes after they had a bug report. But they didn’t have a bug report when heartbleed went public. No, the bug was reported hours later, after the viral-news effect had got around to someone who knew where and how to report a bug in debian’s bug tracking system.

Other, big bugs

You know, there’s a package that runs a good 22% of the internet. In the past week, they published a really critical bug, one that allows remote authenticated access to their sites. This package? WordPress. The bug will allow an attacker to gain administrative-level access to any wordpress site. In actual damage terms, this bug will cause me far, far, far more grief, and likely our customers, than the heartbleed ever will. Heartbleed was patched out in our network in the space of a few hours, with some minor services taking maybe a day or so. If we’re not running a vulnerable version of WordPress on our network, this time next year, I’ll eat my hat. If some clever black-hat hasn’t written an automatic compromise bot, to exploit this within the next few months, I’d be very surprised.

Another package that had a critical security patch in the past week? Just an addon to wordpress, that a good proportion of wordpress sites also use; Jetpack. They found that they had another remote-access, post, and privilege escalation bug in their code. Again, this single bug will cause us far more trouble in the long term, simply because people won’t upgrade.

Other, easier ways of loosing your password

Every now and then, someone’s website gets hacked, crap gets uploaded. We trace it back to their computer, using their login details. What happened? Though we’ve never been able to say with 100% certainty, they were probably infected with a keylogging virus, that saw them typing in their (s)ftp login details, and which automatically used said details to deface their site. That has become less common in the last year, but it was almost a weekly occurrence only last year.  How did the keylogger get installed? Simple, our customers either didn’t have anti-virus, weren’t maintaining it, or actively ignored it’s alerts. They click on links in emails they’re not expecting, open files in emails they’re not expecting, and get infected. Just this week, something has been quite determined to infect me – sending me ‘delivery notes’, asking me to ‘print a zip file’. The ‘zip’ file was a Microsoft Excel .xls file, and likely not an xls file, but something quite nasty.

Internet cafes. Ever used one to pick up your email? There’s a good chance that someone knows your email account password — those computers often have keyloggers installed, or have someone on the same network watching the net traffic, or intercepting it. Use that same password on paypal? Oh well, say goodbye to your money. Ever used a public wifi connection? You know, one of those unencrypted ones on your iPhone? Your iPhone logs into your email accounts without encryption? Say goodbye to your username and password.

In closing

Is heartbeat serious? For webhosts, yes. For users, in the brief period after heartbleed.com went live, till our servers were patched? Yes. Now? Not really. It could have been a lot better, and it could have been a lot worse. Hopefully, this will give the OpenSSL guys more resources to stop any future bug like this slipping through the net. Do you need to reset your passwords? Only if you connected to a vulnerable https:// site, in the brief period that the bug was around. Better would just to watch your bank statements, something you should be doing anyway. Use 2-factor authentication if you can. Use a password manager, my favourite is Keepass, with it’s database stored on Dropbox, and a key file stored elsewhere. Use separate passwords for every site, and don’t try to remember them, just auto-generate them using keepass’s algorithms.

[UPDATED] G Projects

My friends Pi, after repairs to the sd card holder.

[purple means updated on Sunday Feb 2nd 2014]

My pi in its latest incarnation:
image

The other day a good friend and fellow geek of mine acquaintance was reminding me that it’s not possible to do everything we want to do, and actually harmful to try and shoehorn everything in. Someone told him this, and he passed it along.

It got me thinking (and googling – what doesn’t these days?)
Are you a Perfectionist? Do you find yourself telling yourself this: ‘I can’t relax till i get it all done’?

If so we are kindred spirits!

Anyway, here’s all the projects that I’d like to complete:

Raspberry Pi

WebUI

V2 of the User interface.

  • Prettify
    • Layout does not work in IE9. – Who cares?! No one likes IE9 anyway!
    • Embedd/add link to xively
      • Can we get image of all feeds on one graph?
      • Change layout to 4 column 3 row to add this?
        • enough space?
    • apply css to sockets page
    • get that annoying favicon to work! (maybe it doesn’t like the filetype?
      • save as gif/make it smaller and reupp/change mimetype
  • Test – new squeezeplayer page needs testing
  • Develop ?python? code to allow setting of Home Automation parameters
    • E.g. on/off times per DOW

Pressure sensor:

  • Write Exponential moving average code to smooth the values. I found the code somewhere…refind and figure out
    how to store the data to be ema’d
    variable – can bash hold arrays?

    rrdtool – effort bruv
    use xively api to read old datapoints – ditto
  • Descriptive weather prediction – e.g. ‘rain coming’ [Just today it rained, so I have worked out the min time resolution needed to predict/try and deduce if it is raining]
  • Absolute Humidity calculations – output moisture density of air to see how much has been added(RH% is not a good measure of the amount of water bc it’s relative to temperature, and I want to find how wet the air is!)
  • Solder to Slice of Pi board

i2c LCD Screen:

  • Connect to Pi on fly lead (attach to pibox?)
  • Output status – e.g. current sensor data
  • Output interpreted status – e.g. ‘it’s getting hot in here’, Nice weather coming etc
  • Implement a simple UI with pushbuttons ->gpio
    I actually designed the UI while in a meeting!
    functions like shutdown, remote power control, network configuration/join wifi,slimclient/server control?

RFM12b 433mhz wireless transceiver module:

  • Connect to pi (on fly lead? bad reception has been problematic on the transceiver according to susa.net
  • Implement data decoding from CurrentCost transmitter
  • Control remote sockets ala home automation

Streaming Music Server – Plug and play, wireless capable – Using Squeezebox/LogitechMediaServer

Remit: To be able to rock up somewhere, plug in power, and then play music wirelessly from my collection
(Extra: stream from the internet if connection available)

  • Stream music from Pi
  • Control Music from Nook using Squeezebox Android app
  • Stream music to my Hauppage MediaMVP (wirelessly [using WEP])

Progress: 

  • Got MediaMVP to boot from Pi when pi was using wired network
    • tftpd-hpa (modify to port 16869)
    • compiled mvprelay.c 
    • wrote init.d script for mvprelay to startup and point to ip address of pi
      • Need to find a way of dynamically setting ip
      • (altho when setup on wifi, up of pi will be statically fixed)
    • downloaded mvpmc image to boot on the MVP
    • wrote a dongle.bin.config file for the MVP to load it’s config at boot and start the squeezebox ‘mclient’
      • this should enable headless playback, so won’t need a tv screen for Video
    • made a dongle.bin.ver file using dd
    • booted it

Issues/todo: 

It wouldn’t boot over the network bridge. It talked to mvprelay using UDP; tftpd-hpa gave ‘ACK connection refused, could not read’ weird errors when it tried to download the files.
My laptop however could suck the files up no problem. Weirdness!

Todo: investigate settings on Bridge AP looking at what happens to BC packets. And also check DHCP relay settings.
I think they might be flooding the network somewhat.

  1. Setup Pi hostapd: Configure the dhcpd config file
  2. Repair the wifi dongle: The usb socket is no longer solidly connected!! Need to dremmel the plastic off and resolder, then melt and reattach the plastic, (it’s meltable) but a lot tighter this time!
  3. Get the donle working ok in debian/raspbian. (haha, good luck)

 

I can’t do it all………………….

at least not all today!

Actually, part of me likes it going slowly (certainly a surprise to the rest of me!). Time to mull things over, make decisions, come up with sketched designs and sometimes even pseudocode/real code.

Seems to have it’s advantages not trying to do everything right now at least haha.

On that note, bed time! [ 2:03 am this time]