Fun with Docker

Well it’s not really all that fun.

SO… in the start of the year I had decided I didn’t want to play site admin all day, and went to a hosted platform.  Things went well for a few months, then things didnt go well with constant database issues.

Then we went down hard for over 24 hours.  I was going to move back, but then everything started to work again.  But things had been spiraling down to unusability again.

So instead of just making a big VM like I had done before , I thought I’d try using Docker to host my website, with a few containers, namely each tier separate.

And oh boy does everyone love edge case docker stuff, but when it comes to actually moving something *INTO* docker, its basically you are on your own.

So yes, the http-https redirect is brokenMy categories are all missing. lots of stuff is busted.  And the redirect stuff is missing. I’ll have to re-create that one after I get more stuff sorted out.

I haven’t given up yet…

Half of the fun was setting up the haproxy container, which in itself wasn’t so bad, although some times it wouldn’t pick up any config file changes, so I had to destroy it a few times, but naturally once I ask someone to look, and it’s working fine now.

So for the hell of it, here is my haproxy.cfg

maxconn 256
mode http
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms

frontend http-in
bind *:80
bind *:443 ssl crt /etc/haproxy/haproxy.pem
http-request set-header Host if { hdr(host) -i }
http-request set-header Host if { hdr(host) -i }
redirect scheme https code 301 if !{ ssl_fc }
mode http
acl host_virtuallyfun hdr(host) -i
acl host_virtuallyfun hdr(host) -i
acl host_virtuallyfun hdr(host) -i
use_backend virtuallyfun if host_virtuallyfun

backend virtuallyfun
balance leastconn
option httpclose
option forwardfor
reqadd X-Forwarded-Proto:\ https
server node1

I wanted to use Let’s Encrypt to ‘secure’ access to the domains I have, and running the certbot manually…. in a ‘dry run’ I always got this fun and informative error:

NewIdentifier : ACMESharp.AcmeClient+AcmeWebException: Unexpected error
+Response from server:
+ Code: BadRequest
+ Content: {
“type”: “urn:acme:error:malformed”,
“detail”: “Error creating new authz :: DNS name does not have enough labels”,
“status”: 400

Which of course got me absolutely nowhere searching.  I thought it may be docker screwing things up, so I shut it down, and fire up an old fashioned standalone copy of Apache, and run the following:

certbot certonly –dry-run –non-interactive –register-unsafely-without-email –agree-tos –expand –webroot –webroot-path /docker/wordpress/html –domain –domain –domain

And get the same result.

I get to the point of absolute frustration, and just decide to forget the dry run all together, as I know I can run it at least 5 times a day before I get banned, for a while, but maybe I’ll get something more useful.

# certbot certonly –non-interactive –register-unsafely-without-email –agree-tos –expand –webroot –webroot-path /var/www/html –domain –domain –domain
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
http-01 challenge for
http-01 challenge for
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0000_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0000_csr-certbot.pem

– Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/ Your cert
will expire on 2018-06-26. To obtain a new or tweaked version of
this certificate in the future, simply run certbot again. To
non-interactively renew *all* of your certificates, run “certbot
– If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let’s Encrypt:
Donating to EFF:

Except it actually worked.

Creating the needed haproxy.pem is simple as:

cd /etc/letsencrypt/live/
cat fullchain.pem privkey.pem > /docker/haproxy.pem

To put the needed key along with the certs.  Naturally when this expires I’ll have to scramble to figure out how I did this.

Managing docker is fun as well. I went ahead and tried out, which  naturally deploys as a container.  And it can manage remote servers, which I though was a plus as that means I could deploy it in my office, then simply connect to my server.  But that is where I found out that the config files for Debian are hard coded to always listen on a local socket, which breaks setting the proper JSON file to tell it to listen on a socket, and TCP/IP.  So just edit /etc/systemd/system/docker.service.d/docker.conf and either hard code it all there, or remove it from there and place it in /etc/docker/daemon.json

As always documentation is conflicting and all over the place.

My current feelings about docker…

More thoughts on Minecraft, compression and encryption

So earlier, I had touched on Minecraft, and lamented on how it doesn’t compress it’s network data very well.  Well it turns out that yes, in the file, there is an option network-compression-threshold, which by default is set to 256, meaning packets larger than 256bytes are compressed


So using this quick stunnel guide, I thought I’d try a quick experiment.  So I loaded up Titan City, and ran some connection experiments:

First, the Minecraft server with a setting of 256000000 which I would imagine effectively turns off compression.  I’m capturing one minutes worth of game play as it tries to render the spawn point.  Then again with the threshold set to 256:

12M 28 Apr 13:44 minecraft-nocompression.cap
1.6M 28 Apr 13:46 minecraft-256compression.cap

So, uncompressed it’s 12MB worth of data!  While with the Minecraft compression on, it’s 1.6 MB worth of data.

And now with stunnel using zlib compression, we get the following results:

2.1M 28 Apr 13:42 stunnel-nocompressioninserver.cap
1.5M 28 Apr 13:48 stunnel-256compression.cap

2.1MB worth of traffic relying on zlib in this case to do all the compression, and 1.5MB with zlib compressing the Minecraft compression.  And for the heck of it, why not compress the data again?
964K 28 Apr 13:46 minecraft-256compression.cap.gz
993K 28 Apr 13:44 minecraft-nocompression.cap.gz
938K 28 Apr 13:48 stunnel-256compression.cap.gz
1.5M 28 Apr 13:42 stunnel-nocompressioninserver.cap.gz

Well, now that is strange, why is the stunnel traffic even compressible, after it’s been encrypted?  Kind of weird to me.  At any rate, here is some more data thanks to the capinfos program:
# capinfos *cap
File name: minecraft-nocompression.cap
File type: Wireshark/tcpdump/… – pcap
File encapsulation: Ethernet
Packet size limit: file hdr: 1520 bytes
Number of packets: 14 k
File size: 12 MB
Data size: 12 MB
Capture duration: 59 seconds
Start time: Tue Apr 28 13:43:30 2015
End time: Tue Apr 28 13:44:29 2015
Data byte rate: 211 kBps
Data bit rate: 1,689 kbps
Average packet size: 844.05 bytes
Average packet rate: 250 packets/sec
SHA1: ffb5542c47da69ddc93da902136e1173d76b56e0
RIPEMD160: bc2102185a924096a8cf145c54375a05ab90e3c6
MD5: ba0e1addfcb36e7db6314764941fa6af
Strict time order: True

File name: minecraft-256compression.cap
File type: Wireshark/tcpdump/… – pcap
File encapsulation: Ethernet
Packet size limit: file hdr: 1520 bytes
Number of packets: 10 k
File size: 1,686 kB
Data size: 1,524 kB
Capture duration: 54 seconds
Start time: Tue Apr 28 13:45:28 2015
End time: Tue Apr 28 13:46:22 2015
Data byte rate: 28 kBps
Data bit rate: 226 kbps
Average packet size: 150.91 bytes
Average packet rate: 187 packets/sec
SHA1: 5b5e51f53f0716fd84a39120afd68eadbfaf9816
RIPEMD160: f2bf3839c084b1d7b31fce0a8a8ce959316643a7
MD5: dc6f56a5a1c10e642548e0eeb979629b
Strict time order: True

And now let’s look at the stunnel captures:

File name: stunnel-nocompressioninserver.cap
File type: Wireshark/tcpdump/… – pcap
File encapsulation: Ethernet
Packet size limit: file hdr: 1520 bytes
Number of packets: 9,949
File size: 2,159 kB
Data size: 1,999 kB
Capture duration: 59 seconds
Start time: Tue Apr 28 13:41:13 2015
End time: Tue Apr 28 13:42:12 2015
Data byte rate: 33 kBps
Data bit rate: 270 kbps
Average packet size: 201.02 bytes
Average packet rate: 168 packets/sec
SHA1: 418cc249c3393d85e6e59a6e02c02060b7b7ce4f
RIPEMD160: bf7f56af412734260e0e96d1a0c7d2f28be3ba95
MD5: 1b96fce1db9d38d8dbbecf9bb2278079
Strict time order: True

File name: stunnel-256compression.cap
File type: Wireshark/tcpdump/… – pcap
File encapsulation: Ethernet
Packet size limit: file hdr: 1520 bytes
Number of packets: 9,585
File size: 1,554 kB
Data size: 1,401 kB
Capture duration: 59 seconds
Start time: Tue Apr 28 13:47:35 2015
End time: Tue Apr 28 13:48:34 2015
Data byte rate: 23 kBps
Data bit rate: 189 kbps
Average packet size: 146.21 bytes
Average packet rate: 162 packets/sec
SHA1: 19b2bbfff8cd9c5c0e460d64ad0f4b966cf3a141
RIPEMD160: e31c226101daea9327a8b13a4a1012a24bea11c1
MD5: a7b4b0d5ecf3e6a472255cff13466b51
Strict time order: True

Well for me this is still interesting.  The stunnel connection sent less packets, and smaller.  I know that this is horrible to ‘measure’ like this, and yes none of the datasets are the same, making this kind of bogus. However, honestly compressing with stunnel does feel faster.

So, want to try?  I guess I can let people try if they want, but you’ll need stunnel.  I’ve read horror stories on griefers and I figure if i raise the bar to connect it’ll be somewhat distractionless.

So here is my stunnel.conf I’m using on the client side.

client = yes
compression = zlib
foreground = yes
debug = 6

accept =
connect =
cert = minecraft.pem

And of course, you need my certificate pair, so here is minecraft.pem:


And I run it something like this from the client side…

# stunnel mine.conf
2015.04.28 14:25:23 LOG5[ui]: stunnel 5.16 on x86_64-apple-darwin14.3.0 platform
2015.04.28 14:25:23 LOG5[ui]: Compiled/running with OpenSSL 0.9.8zd 8 Jan 2015
2015.04.28 14:25:23 LOG5[ui]: Threading:PTHREAD Sockets:SELECT,IPv6 TLS:ENGINE,OCSP
2015.04.28 14:25:23 LOG5[ui]: Reading configuration from file mine.conf
2015.04.28 14:25:23 LOG5[ui]: UTF-8 byte order mark not detected
2015.04.28 14:25:23 LOG6[ui]: Compression enabled: 1 method(s)
2015.04.28 14:25:23 LOG6[ui]: Initializing service [minecraft]
2015.04.28 14:25:23 LOG6[ui]: Loading certificate from file: mine.pem
2015.04.28 14:25:23 LOG6[ui]: Loading key from file: mine.pem
2015.04.28 14:25:23 LOG4[ui]: Insecure file permissions on mine.pem
2015.04.28 14:25:23 LOG5[ui]: Configuration successful

Now with stunnel connected, you just have to add a server, but you connect to ‘localhost’. This will have you talking to the stunnel program which then talks to my server, which then redirects to the VM running Minecraft.


Setup a server to ‘localhost’ to access stunnel


Now you can connect to the stunnel server

No promises on how long it’ll be up though.

Titan City!

Titan City!

For normal clients... (shhhh!)

For normal clients… (shhhh!)

With all the truecrypt hysteria running around

truecrypt-logoI thought I’d go mining for old versions, and put them up on CVS web.  Turns out some old versions are missing, but oddly enough not the 1.0 stuff.

So here is the src2html version, and the raw tree view.

And for the really crazy, I dumped all versions into CVS.

I only briefly looked at it, and noticed the block driver has the ability to look at memory.. I don’t know why, but I don’t think I would want my block drivers being able to do that.  maybe it’s a good thing, I don’t know.  I haven’t tried to build it, and I’ve never used TrueCrypt so I really can’t comment on it.

Also pulling through I found some old versions of scramdisk. But I never used that either.