Tuesday, June 12, 2012

BackupPC gotchas for PCBSD.

I am getting BackupPC configured to back up a new PCBSD desktop. Every time I do this, I have to relearn what tricks are required, so here is my troubleshooting checklist. Probably applicable to most Linux and Unix-like Operating Systems as well. If you've tried getting this set up before, the useless BackupPC error "Unable to read 4 bytes" has probably become the bane of your existence.

  1. Does the client sshd configuration allow root logins? Check /etc/ssh/sshd_config, specifically the the PermitRootLogin parameter. Unless you absolutely need password authentication for root, use the following configuration: PermitRootLogin without-password
  2. Make sure that the client has the public ssh for the BackupPC user on the server included in /root/.ssh/authorized_keys. If you haven't generated an ssh key for BackupPC, you should do that.
  3. The permissions for /root/.ssh/authorized_keys on the client should be 640. /root/.ssh should be 750. Ownership should be root:wheel.
  4. The .ssh/known_hosts file for the server BackupPC user should contain the fingerprint for the client. If you have connected to the client from the server before as another user (root), the fingerprint may already be in that user's known_hosts file. You can copy it into the BackupPC user's file. If you have not already connected to this host, you can verify the client configuration by connecting with the BackupPC ssh keys like so: ssh -i /path/to/bpc/.ssh/id_rsa client.example.org. The hostname you use (and known_hosts contains) MUST contain the exact hostname BackupPC is configured to connect to. If you connect to 'client' (leveraging your domain search list), but BackupPC is configured to connect to 'client.example.org', the ssh connection will fail.

Pwning the Spotify client

I've been trying to bend the Spotify client to my will for months. I love the service, but the mandatory P2P network traffic generated by the client is so abusive that I can't do my job and listen to music at the same time. You hear that Spotify, your draconian client prevents me from doing my job. I've tried all sorts of tricks to try and block the network traffic, but it's slippery to try and block without impacting legitimate traffic.

I finally decided to try poking at the storage space available to the client, in hopes that I could cut it off at the knees there. I've learned some interesting things (thanks to this blog post for a point in the _right_ direction).

  • The Spotify client for OSX puts the settings file at ~/Library/Application\ Support/Spotify/settings
  • The cache_location parameter controls where the clients tries to put downloaded data. I don't know if parameter position is important in the Spotify configuration file, but the client puts this parameter (for me) between the listen_port and cache_size params.
  • Spotify does not appear to respect the cache_size parameter when it is running, at least not in the short term. I tried setting a cache_size of 1MB, but it appears that the client continuously caches music you listen to. The cache storage directory is reduced to the configured size on client start, apparently.
  • Because of this, the client cannot be contained by changing the location of the cache to a tiny filesystem. I tried using a 20MB Mac disk image as storage; Spotify happily filled the entire image, then stopped playing, complaining about a full drive.
  • When I reduced the cache_size to 1MB and deleted the existing cache, starting the Spotify client produced a message that offline playback is disabled. It remains to be seen if this also means P2P is disabled. Time will tell.
I really wish that Spotify would allow users to control (or disable) the P2P function of the client. I am not opposed to giving a little bit of bandwidth to P2P, but I need to be able to do my job as well. I'm not optimistic though. Although their product is excellent, Spotify seems to be unresponsive to customer requests, and their customer support seems to be dismal, at least in the United States. If anyone at Spotify cares to prove any of this wrong, I would be happy to update/revise this post.