Turns out that GDM silently disables wayland if it detects the nvidia driver is installed.

The solution is to override the upstream udev rule that prevents wayland starting:

# ln -s /dev/null /etc/udev/rules.d/61-gdm.rules
# reboot

“gnome” should be an option now when logging in from gdm (click the cog icon).

I came up with this approach to apt install the most recent one:

sudo apt install \
   $(find /home/jason/Downloads/ \
       -name 'discord*.deb' -type f -printf '%T+ %p\n' | \
      sort -r | head -1 | cut -d' ' -f2)

or you can build it into a bash function:

update-discord()
{
sudo apt install \
  $(find /home/jason/Downloads/ -name 'discord*.deb' -type f -printf '%T+ %p\n' | \
  sort -r | head -1 | cut -d' ' -f2)
}

One could also consider deleting the .deb after successful install. That is an excercise left for the reader

Free Palestine!

I couldn’t find a coherent set of instructions for setting up Let’s Encrypt DNS Challenges with hassio, especially as my DNS provider requires custom scripts in order to achieve this.

However, I came up with a work around. First let’s think about how Let’s Encrypt (LE) usually works. Suppose you want to get a certificate for my.example.com (MEC), but my.example.com is NATed behind example.com’s (EC) IP address. When you run the LE client on MEC, it requests the LE servers to do a challenge request to MEC. MEC will have the same public IP as EC. the client on MEC will some information on the MEC server at the <webroot>/.well-known/acme-challenge. The LE servers will try and query it. If they find what they are looking for, they issue you the certificate.

So I got to thinking, as this request takes place on port 80, it must contain the domain name header, and so, if you run an web server on port 80 of EC and A entry for  MEC the same public IP address as EC, EC could simply proxy that request to the MEC server.

I looked up how to do this and set it up on my server and low and behold, I was able to get a valid certificate.

In my case I did it with nginx , so the config looked like this:

On my server on port 80 (example.com) of the firewall in /etc/nginx/sites-available/my.example.com:

server {
       server_name my.example.com;
       location / {
       		proxy_pass http://192.168.1.9:80/;
		proxy_set_header Host $http_host;
	}
}

Then symlink it to /etc/nginx/sites-enabled/my.example.com and test the nginx config:

$ sudo ln -s /etc/nginx/sites-available/my.example.com  /etc/nginx/sites-enabled/my.example.com
$ sudo nginx -t
[sudo] password for jason:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Restart nginx:

sudo systemctl restart nginx.service

Now start your Let’s Encrypt certificate request on your server and you should be good to go.

echo 'deb [arch=amd64] https://packages.microsoft.com/debian/8/prod jessie main' > /etc/apt/sources.list.d/mssql-release.list

Add the key

curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -

then update and install

sudo apt update
sudo apt install msodbcsql mssql-tools

If you try and connect to sql now you get an obscure error like this:

/opt/mssql-tools/bin/sqlcmd -S 10.0.2.13 -U xxx -P yyy
Sqlcmd: Error: Microsoft ODBC Driver 13 for SQL Server : Can't open lib '/opt/microsoft/msodbcsql/lib64/libmsodbcsql-13.1.so.9.1' : file not found.

But the file exists:

$ file /opt/mssql-tools/bin/sqlcmd
/opt/mssql-tools/bin/sqlcmd: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=21a353af470e7849544daab892ec9b1bfc36dc87, not stripped

This somewhat misleading error is actually due to the libmsodbcsql lib being linked against a very specific version of libssl. Check the output of ldd:

$ ldd /opt/microsoft/msodbcsql/lib64/libmsodbcsql-13.1.so.9.1 | grep 'not found'
libcrypto.so.1.0.0 => not found
libssl.so.1.0.0 => not found

But it turns out this can easily be solved by manually installing the libssl package from Debian Jessie:

wget "http://security.debian.org/debian-security/pool/updates/main/o/openssl/libssl1.0.0_1.0.1t-1+deb8u7_amd64.deb"
sudo apt install ./libssl1.0.0_1.0.1t-1+deb8u7_amd64.deb

then you should be back in business.

find -type f -name \*.mp3 \
| xargs -n 1 -P $(getconf _NPROCESSORS_ONLN || echo 1) -i \
  bash -c \
 'i="{}"; ffmpeg -y -i "$i" -map_metadata 0 \
        -c copy -c:a libfdk_aac -b:a 128k\
        -map_metadata:s:a 0:s:a -f ipod "${i%.*}.m4b"'

What that does is:

1. find all the mp3 files and pipe their names into xargs
2. then get the number of cores available and pass that to the -P argument
3. and run ffmpeg and map all the metadata to the new file
4. and strip off the mp3 file extension and add m4b to it

There! Nothing to it!
Update 2017-03-23: Added double quotes around the bash variable $i to cope with spaces. You should always do this (and so should I)
Update 2018-12-20: Added “-c copy” so ffmpeg can cope with album art in the file

<Files xmlrpc.php>
  Order allow,deny
  Deny from all
</Files>

That brought the load back to normal so I could at least access the WordPress backend.
After googling around for a solution it appeared that fail2ban could help. Luckily there is a plugin for that. WP fail2ban has two parts. The first is a plugin that enables logging of xmlrpc events and authentication events to /var/log/auth. It is important to keep these events separate from the normal http access logs as the access log file can get very large and fail2ban can raise the load significantly just processing it.
You also need to add a few configuration options to wp-config.php

define('WP_FAIL2BAN_LOG_PINGBACKS',true);
# prevent user enumeration
define('WP_FAIL2BAN_BLOCK_USER_ENUMERATION',true);
# block some obviously invalid users
define('WP_FAIL2BAN_BLOCKED_USERS','^test

See the readme for more details about what they do
The second part is enabling filters and gaols in fail2ban. Luckily this is also provided by the WP fail2ban plugin. Copy the wordpress.conf file from the wp-fail2ban directory to the fail2ban config directory:

~# cp /var/www/wp-content/plugins/wp-fail2ban/wordpress.conf \
 /etc/fail2ban/filter.d
~#

Then edit /etc/jail.local and insert:

[wordpress]
enabled = true
filter = wordpress
logpath = /var/log/auth.log
# set the ban time to 1 hour - probably could be even higher for good measure
bantime = 3600
# needed for debian wheezy otherwise fail2ban doesn't start and reports
#   errors with the config
port = http,https

Now restart fail2ban:

~# /etc/init.d/fail2ban restart
[ ok ] Restarting authentication failure monitor: fail2ban.
~#

Remove the block on the xmlrpc.php file from your apache config and restart apache. Then you should see in your fail2ban logs something like:

2014-08-09 23:18:30,405 fail2ban.actions: WARNING [wordpress] Ban 117.195.37.14
2014-08-09 23:20:49,090 fail2ban.actions: WARNING [wordpress] Ban 78.97.220.237
2014-08-09 23:20:50,108 fail2ban.actions: WARNING [wordpress] Ban 46.108.226.105
2014-08-09 23:21:04,162 fail2ban.actions: WARNING [wordpress] Ban 120.28.140.93
2014-08-09 23:21:28,206 fail2ban.actions: WARNING [wordpress] Ban 175.142.187.77
2014-08-09 23:21:36,234 fail2ban.actions: WARNING [wordpress] Ban 88.240.97.76
2014-08-09 23:21:36,294 fail2ban.actions: WARNING [wordpress] Ban 122.177.229.110
2014-08-09 23:21:44,346 fail2ban.actions: WARNING [wordpress] Ban 89.106.102.15
2014-08-09 23:21:46,400 fail2ban.actions: WARNING [wordpress] Ban 2.122.219.188
2014-08-09 23:21:52,423 fail2ban.actions: WARNING [wordpress] Ban 95.69.53.13
2014-08-09 23:22:12,488 fail2ban.actions: WARNING [wordpress] Ban 5.12.12.66
2014-08-09 23:22:12,509 fail2ban.actions: WARNING [wordpress] Ban 182.182.89.23
2014-08-09 23:22:42,564 fail2ban.actions: WARNING [wordpress] Ban 178.36.126.249
2014-08-09 23:22:53,590 fail2ban.actions: WARNING [wordpress] Ban 36.83.125.10
2014-08-09 23:22:53,607 fail2ban.actions: WARNING [wordpress] Ban 95.231.59.185

I found however that I was being hit from over 1800 unique IP addresses and despite fail2ban successfully banning them, it was taking too long to ban enough that the load would return to normal so I re-blocked the xmlrpc.php file for 24 hours. After that, I enabled it and it seemed as though the DDoS had gone away. So far so good.

define('WP_FAIL2BAN_BLOCKED_USERS','^organictrader');

See the readme for more details about what they do
The second part is enabling filters and gaols in fail2ban. Luckily this is also provided by the WP fail2ban plugin. Copy the wordpress.conf file from the wp-fail2ban directory to the fail2ban config directory:

Then edit /etc/jail.local and insert:

Now restart fail2ban:

Remove the block on the xmlrpc.php file from your apache config and restart apache. Then you should see in your fail2ban logs something like:

I found however that I was being hit from over 1800 unique IP addresses and despite fail2ban successfully banning them, it was taking too long to ban enough that the load would return to normal so I re-blocked the xmlrpc.php file for 24 hours. After that, I enabled it and it seemed as though the DDoS had gone away. So far so good.

);

See the readme for more details about what they do
The second part is enabling filters and gaols in fail2ban. Luckily this is also provided by the WP fail2ban plugin. Copy the wordpress.conf file from the wp-fail2ban directory to the fail2ban config directory:

Then edit /etc/jail.local and insert:

Now restart fail2ban:

Remove the block on the xmlrpc.php file from your apache config and restart apache. Then you should see in your fail2ban logs something like:

I found however that I was being hit from over 1800 unique IP addresses and despite fail2ban successfully banning them, it was taking too long to ban enough that the load would return to normal so I re-blocked the xmlrpc.php file for 24 hours. After that, I enabled it and it seemed as though the DDoS had gone away. So far so good.

1. connect to the serial terminal, or connect over the usb network interface which gives the BBB the address 192.168.7.2, log in and issue the command ip addr.
2. use nmap to try and search out its IP address on your subnet but this is time consuming and not very accurate I have found.
3. use avahi-browse -rat (thanks Madox for that tip.)

Last night I came up with a Better Way. Rather than trying to determine the BBB’s address, why not use a fully qualified domain name and a dynamic dns service? I could then just type ssh myfqdn.com or whatever and log in. Think how that would simplify one’s life!
To implement this, set up a dynamic DNS somewhere with a FQDN for your BBB. If you happen to have your own domain name already you can use a sub-domain from that. I think its fairly common for DNS hosts to offer an API to update your IP address. I happen to use Rimu Hosting and they have their own simple web api.
Then you just need to write a little script to update the IP address every time the DHCP client receives a new IP address, and drop it into /etc/dhcp/dhclient-exit-hooks.d/
Here is my script. This will only work with Rimu Hosting as they have their own privately developed API, and you’d need to insert your own KEY into the script.

#!/bin/bash
# update ip address with rimu hosting. See https://rimuhosting.com/dns/dyndns.jsp
if [[ ! -z ${new_ip_address} ]]
then
   echo $(date +"%F %T") ${new_ip_address} >> /root/ddns.txt
   curl "https://rimuhosting.com/dns/dyndns.jsp?action=SET&name=clock.emacstragic.net&value=${new_ip_address}&type=A&api_key=XXX"
else
    echo "got no ip"
fi

Update:

I discovered this didn’t work at home. Turns out that dnsmasq in OpenWRT is set to ignore this kind of dns request, due to potential security risks. There is a solution to that. Add a list rebind_domain line to your /etc/config/dhcp line on the router.

config dnsmasq
	.
	.
	.
	list    rebind_domain 'clock.emacstragic.net'

Thanks to Michal Čihař for the solution to that.