Software

The game has been reviewed as a major time suck. Don't get me wrong, the game doesn't suck, it just sucks my (and 70 million other players') time. 

I was playing with my iPad and in Desert-stage and managed to land on front wheel with a motocross bike. The trouble was, that it was evenly balanced. It wouldn't fall on either side, it just stuck there no matter what I did. Eventually I just run out of fuel. See the pic!

Darn! No new record for that attempt.

Occasionally I like to stea.... erhm.... listen to stuff from Finnish Broadcasting Company's internet-site. Most of the items they have there have some sort of limit, for example 7 days or 30 days, after which the show if off-the-air for good. The technology they're using is streaming FLV, or RTMP, making it relatively easy to steal... ermhm... borrow.

On my Fedora 19 my favorite utility for doing the ste... well... stream-redirection is YLE-DL. It is a Python-wrapper for the classic RTMPDump-utility. The Python-thingie is very much needed, as the parameters required for RTMPDump can be for example:

--playpath=mp3:areena/fi/52/52cf454f9e444f498352f65cfe7ba11d \
--swfUrl=http://areena.yle.fi/static/player/1.2.8/flowplayer/flowplayer.commercial-3.2.7-encrypted.swf \
"--app=ondemand?_fcs_vhost=cp157366.edgefcs.net&auth=eb.bEdRbFdlamabdgckdRcxdvaGbxdvbZbWbscycAdcdKbncbcpbIdSdgdLbidebVbx-br5atj-c0-vga-oxmCrAxmpvkzsqrzxlzp-kblXn9lakal5nTlfn2k6kRnZ&aifp=6&slist=areena/fi/52/52cf454f9e444f498352f65cfe7ba11d" \
--pageUrl=http://areena.yle.fi/radio/1943628 \
--rtmp=rtmpe://cp157366.edgefcs.net/ondemand \
"--tcUrl=rtmpe://217.212.252.204/ondemand?_fcs_vhost=cp157366.edgefcs.net&auth=eb.bEdRbFdlamabdgckdRcxdvaGbxdvbZbWbscycAdcdKbncbcpbIdSdgdLbidebVbx-br5atj-c0-vga-oxmCrAxmpvkzsqrzxlzp-kblXn9lakal5nTlfn2k6kRnZ&aifp=6&slist=areena/fi/52/52cf454f9e444f498352f65cfe7ba11d" \
-o "Parasta ennen! pe klo 20.00-2013-07-12.flv"

This nice script does all that for me. Except it doesn't work. It just says "Segmentation fault (core dumped)". Which is rather bad.

After very short period of GDBing, I realized that some function-API changed drastically. In this case it is Diffie-Hellman -function in the GnuTLS-library, which RTMPDump can use if chosen to do so. The API-changed for example in gnutls_calc_dh_secret()-function:

Old:
bigint_t
gnutls_calc_dh_secret (bigint_t ret_x, bigint_t g, bigint_t prime)

New:
int
gnutls_calc_dh_secret (bigint_t ret_y, bigint_t * ret_x, bigint_t g, bigint_t prime,
                      unsigned int q_bits)

Since that function is not in the GnuTLS public API, developers of RTMPDump had to declare that function in their code to make it work. That is because gcrypt and GnuTLS are using multi precision integers to process public-key -stuff. It is much easier to multiply two huge numbers with a suitable library. In this case the libraries should be compliant with each other, but ... Having void-pointers makes it compile, but it doesn't make it run. Without core dumps, that is.

The solution is not to use GnuTLS, which seems to be the default. I chose to use OpenSSL-functions instead. That builds and runs.

Tip:

To get a core dump in Fedora 19 the automatic bug reporting tool ABRT needs to be tweaked. As a default it gets all the cores, not you. See /proc/sys/kernel/core_pattern, which out-of-the-box has value of |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e

So it is a very good idea to edit the value of DumpLocation-directive in /etc/abrt/abrt.conf. I put it like this and created the directory:

MaxCrashReportsSize = 0
DumpLocation = /var/spool/abrt

Then I could get a directory like /var/spool/abrt/ccpp-2013-07-15-17\:30\:42-7463/ containing a coredump-file with the exact point of the crash.

I've been a long-time user of Parallels Plesk Panel. It really is the best product for maintaining a hosting-server. However, it is lacking the support for domain owners to update their dynamically changing IP-addresses into the panel's DNS-zone automatically.

Since I really needed such a service, I built one from parts. The central piece is DHIS client/server -software. I don't know why they stopped distributing the server-component source code, but I still have it. The license in the software is very liberal, so it can be used by anybody for anything.

As default, DHIS only supports DNS TSIG updates. That is not a good idea in Plesk, since master database for DNS-records is in the MySQL database. Also, getting BIND to refresh a zone really requires a root-access. Nobody wants to run their daemons as root, so I did two things: I added possibility of doing updates with an external script and wrote such a Perl-script to interface with Plesk's RPC API to update DNS-records.

My work is distributed here: http://opensource.hqcodeshop.com/dhis/

As the next step, I'll be investigating how to get any support for this into Plesk's GUI. It really would be nice to allow client to generate his own QRC-authentication keys instead of me doing it manually.

ISC BIND is the most popular DNS in the entire Internet. Most hostmasters never need to allow DNS-clients to change records, but then there are cases where it can be handy.

When thinking of the security, it will be very, very stupid to allow anybody to update records. Luckily there doesn't seem to be a script-kiddie-proof -tool for doing that (or at least I haven't found one yet). Most servers simply don't allow dynamic updates and those who do, don't allow it for all zones. Security-wise one of the simplest approaches is to allow updating a zone from specific subnet or hand-picked IP-addresses. That way most of the users have been excluded using a simple mechanism. Surely any motivated cracker will bend any rules, that exist.

To add security and allow updates only for those who actually are permitted, a smart move is to go TSIG. It is described in RFC 2845 Secret Key Transaction Authentication for DNS (TSIG) and is supported by many DNS-servers, including BIND. Getting it running is described poorly. Best description I found is in Jeff Garzik's blog the article is title "nsupdate: Painless Dynamic DNS".

The basic steps are pretty much following:

1. Generate update key
• This will include executing a command like:
  dnssec-keygen -a hmac-md5 -b 128 -n HOST my.dns.update.key.
2. Inform BIND-server about the key
• This will include changing the raw key-file into BIND-format, like:
  key "my-key-name" {
    algorithm hmac-md5;
    secret "somethingcompletelybullshithere==";
  };
3. Allow a zone to be updateable by anybody knowing the key
• This can be accomplished with allow-update -configuration directive.
  
4. Go update!
   

A test run for checking out if your setup succeeded would be:

# nsupdate -k my.dns.update.key
update delete a.record.my.zone. A
update add a.record.my.zone. 3600 A 192.168.0.198
show
send

If server's messsage log says something like "client 192.168.0.1#12790: request has invalid signature: TSIG dhis: tsig verify failure (BADKEY)", then your key setup failed. Either server doesn't recognize your client's key, or client failed to provide a valid key.

If server's message log says something like "client 192.168.0.1#39782: update 'my.zone/IN' denied", then the DNS-zone to be updated does not allow dynamic updates. Add something like allow-update { key "my-key-name"; }; into your zone-configuration.

A successful update will show something like this in your logs:

named[25415]: client 192.168.0.1#64975: signer "my-key-name" approved
named[25415]: client 192.168.0.1#64975: updating zone 'my.zone/IN': deleting rrset at 'a.record.my.zone' A
named[25415]: client 192.168.0.1#64975: updating zone 'my.zone/IN': adding an RR at 'a.record.my.zone' A

(Note: the named PID and client port-numbers are just copy/pasted from my log. They will differ in your case.)