Ovidiu Predescu's Weblog

SSL web site using Let's Encrypt

Yesterday I was accepted in the beta program of Let's Encrypt, and I received an email on how to obtain the server-side SSL certificates for this web site.

The setup is pretty straightforward, though you need to pay attention on how you set things up on your web server. I use nginx and this is the configuration I had to add to serve HTTPS requests:

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl on;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # ...

}

To authenticate your web site, the instructions tell you to place some files in a .well-known/acme-challenge directory. I placed those directly in the root directory that serves my site. Just make sure you have the proper permissions on the directories and files so the web server can serve them, and have the Content-Type set to application/jose+json. On Apache, this is how you do it:

<DirectoryMatch \.well-known/acme-challenge>
  ForceType application/jose+json
</DirectoryMatch>

For nginx add a config like this inside the server block for your site:

location /.well-known/acme-challenge {
  root /your/htdocs/directory/here;
  default_type application/jose+json;
}

The SSL certificates are valid for 90 days during the beta test period, but I expect they will extend them to a more usual 1 year once everything works smoothly.

Once you're done setting things up head over to SSL Labs and verify that your SSL web site is properly setup.

Overall a very pleasant experience, and I would say even better than what you get from other SSL certificate authorities.

To sign up for Let's Encrypt's Beta program click here.

MacOS X Yosemite: How to mount a disk on startup

MacOS X Yosemite removed few capabilities that existed in previous versions of MacOS X. Notably the StartupItems feature which allowed you to run scripts when the system boots up.

On my machine I want to be able to mount an internal disk as soon as the machine boots up, but before a user logs in. A common solution in the past involved a custom StartupItems script, but this no longer works on Yosemite.

To solve this problem I created a LaunchDaemons script. My disk's volume name is BigDisk and is accessible via /dev/disk0s2. To mount it on startup I created a file named com.jollyturns.disks.plist in /System/Library/LaunchDaemons with the following content:

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
  <dict>
    <key>RunAtLoad</key>
    <true/>

    <key>KeepAlive</key>
    <dict>
      <key>PathState</key>
      <dict>
        <key>/Volumes/BigDisk</key>
        <false/>
      </dict>
    </dict>

    <key>Label</key>
    <string>com.jollyturns.disks</string>

    <key>ProgramArguments</key>
    <array>
      <string>/usr/sbin/diskutil</string>
      <string>mount</string>
      <string>/dev/disk0s2</string>
    </array>        
  </dict>
</plist>

When the machine starts up, launchd will load the file since we have the RunAtLoad set to true. It then finds that /Volumes/BigDisk does not exist, since the disk is not yet mounted, so it executes the diskutil command to mount the directory.

Jollyturns

Jollyturns - a ski/snowboarding mobile application I worked on for more than 2 years, is finally live!

The focus for the first release was on providing as much ski resort information as possible. We produce the ski resort information ourselves, and it includes detailed information on ski lifts, ski runs, restaurants/lodges, snow and weather information.

Future releases will focus on better statistics and improved social interaction.

Please check it out and let me know what you think by sending email to support@jollyturns.com.

BeagleBone Black vs Arduino Uno

I just received my BeagleBone Black from Adafruit. It's a very sweet board and the price is just right. US $45 will get you a 1GHz ARM processor with 512MB RAM and 2GB flash, built-in Ethernet (10/100Mbps), video graphics card with HDMI output port, 65 I/O ports, 4 hardware UARTs. A very capable board for driving the various small projects I have in mind.

The first project I will work on is to replace a Guruplug+Arduino-based project that was driving my projection screen. The setup I had was quite nice, but it appears the Guruplug died after running great for the past few years.

Rsync over ssh: the dreaded "writefd_unbuffered failed to write 4 bytes to socket" error

I use rsnapshot to implement a backup solution for the computers in my home. Rsnapshot runs as a cron job on a ReadyNAS Pro Business Edition system with 6 2TB drives inside (a total of 7.4TB in an X-RAID2 configuration). It backs up the data from a Mac Pro using rsync over ssh. I would have used TimeMachine but its inability to reliably run on non-Apple hardware and with volumes larger than 2TB drives me nuts.

Every once in a while, especially when I have some new fresh data to be backed up, I see rsync start up but it mysteriously dies after a short while (in in /var/log/rsnapshot.log). Running the same command in a terminal gives the following error:

rsync: writefd_unbuffered failed to write 4 bytes to socket [generator]: Broken pipe (32)
rsync error: timeout in data send/receive (code 30) at io.c(1530) [generator=3.0.7]
rsync error: received SIGUSR1 (code 19) at main.c(1306) [receiver=3.0.7]

Both the source and the destination machines were using rsync 3.0.7. The command line I was running on the source machine (readynas):

root@readynas:~> /usr/bin/rsync -a -v --iconv=UTF-8 --timeout=180 --archive \
    --compress --delete --numeric-ids --relative --delete-excluded --copy-unsafe-links \
    --rsync-path="/opt/local/bin/rsync" --rsh="/usr/bin/ssh -p 22 \
    -o 'ClearAllForwardings yes' -o 'ServerAliveInterval 60'" \
    root@monster:/Volumes/BigDisk /backup/hourly.0/monster/BigDisk/

I upgraded rsync both on the source machine (the ReadyNAS), as well as on my Mac Pro to 3.0.8, by manually compiling the latest version. However the error still persisted.

Googling around didn't reveal any solution to the problem, which apparently goes back all the way to at least 2008. On one forum a poster suggested removing the compression from rsync and let ssh handle it. This works for small files but it tends to break on the larger files (larger than 15GB in size).

What seems to work best however is remove compression altogether. Another thing I've done is to use rsh instead of ssh. Here is the new command line (note the new paths to rsync 3.0.8 on each machine).

root@readynas:~> /usr/local/bin/rsync -a -v --iconv=UTF-8 --timeout=180 --archive \
    --delete --numeric-ids --relative --delete-excluded --copy-unsafe-links \
    --rsync-path="/usr/local/bin/rsync" --rsh="/usr/bin/rsh" \
    root@monster:/Volumes/BigDisk /backup/hourly.0/monster/BigDisk/