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.

/sbin/shutdown permission denied

I have been working on setting up a vmware-based demo environment to be used for a presentation I will be giving in about a month. As a part of the demonstation, I need a lot of nearly identical virtual machines, so PXE-booting them seems like a great idea.

I set up my test NFS server and built a PXE image, following the lead of the FreeBSD handbook, and a PXE setup that we use at $work. After getting my virtual PXE host to boot, I quickly discovered that I was unable to login as root, despite having set a password. After a lot of screwing around, including compiling 3 different FreeBSD source trees, I finally tried booting with the memory filesystems, as described in section 32.8.2 of the handbook. This allowed me to log in, but was still not ideal, since changing anything in /etc required rebuilding the archive. I was also unable to shut down the PXE VM, because calling shutdown returned "permission denied," as root.

Turning to smarter people on IRC, it was suggested that this behavior is usually seen in FreeBSD jails, a nosuid-mounted filesystem, or incorrect permissions on /sbin/shutdown. The second possibility got me to thinking, which led me to the answer. My NFS export on the server was missing the '-maproot=root:' directive. Adding this directive got everything working as expected.

Stupid Cacti tricks

I spent some time this weekend consolidating services I have running at home down to one box. I migrated my Cacti installation to its new home (from one FreeBSD jail to another), and moved the mysql server to its own jail. I quickly realized that there was a problem. My graphs weren't working anymore. Some checking and I determined that there was a problem with the rrd files failing because the timestamp of updates was in the past, by six hours, which is precisely the offset of my time zone (CST). I checked all of the time zone configuration on the Cacti jail, and everything was set correctly. I went to bed, frustrated, but figuring that the data would catch up by morning.

Morning came, and my graphs were indeed logging data again, but offset by six hours. The graph window showed the correct time range, but the end of the data line was six hours behind local time. After too much screwing around, reading through the Cacti php. I finally discovered that Cacti sends its poller results to mysql, before retrieving them to put in the rrd files (and purging the records from mysql). The times I was getting back from the new mysql server were being sent as local time, not UTC.

Long story longer, I had neglected to set the time zone in the jail containing mysql.

Who has been spamming legislators with my identity?

Early this week, I received an email from a Tiffiniy Cheng at fightforthefuture.org. I decided to open the message, despite the subject line being spammy-looking at best. The email essentially thanked me for my work in helping to defeat SOPA, and urging me to contact my legislators regarding PROTECT IP. While I have no love for either piece of legislation, I was fairly certain that I have never heard of fightforthefuture.org before, and I had not made any effort related to SOPA. Looking closer at the email, I noticed that it was sent on the behalf of fightforthefuture.org by Blue State Digital, an organization born from the ashes of the Howard Dean campaign. The email was also sent to an email address I forgot even existed; that I created years ago and set to forward to one of my primary addresses.

I wrote off the email and carried on. Yesterday morning, I received another email from Congressman Dennis Cardoza's office. The email was a form letter thanking me for contacting him regarding SOPA. I'm pretty sure that Dennis Cardoza is a California Democrat, and that California has not yet acquired Minnesota, where I am, and have always been a resident. The second email was also sent to my long-forgotten email account. That these two emails are the only messages that have been received by this account in as many years, something smells fishy.

It seems to me that someone has gotten their hands on an email list (I probably supported some democratic cause years ago), and taken it upon themselves to use that email list to spam legislators. While I may have no love for the current generation of intellectual property law, I have even less love for people using my identity without my authorization. As broken as American politics may seem, this seems particularly dishonest, as it undermines one of the core principles of our government; the ability of citizens to correspond with their elected representatives. If legislators think that correspondence from their constituents might be bogus, why bother reading ANY correspondence?

Dry firing a Ruger Mark I pistol

From the FYI department...

I contacted Sturm, Ruger support to find out if it is safe to dry-fire the .22 Standard/Mark I pistol. Here is their response. Short answer, yes.

Comment / question:

I was given an old Ruger Mark I by my father, and I wanted to know if dry firing will damage the pistol. Your FAQ mentions that this is a safe operation on the newer Mark IIIs and .22 pistols generally, but does not say anything specific about its predecessor.

Response:

The firing pin in the Ruger .22 pistols is of the inertia type and dry firing should cause no damage to the firearm as long as the firing pin stop is in place in the bolt (refer to information regarding “To Unload” and “Reassembly” in the instruction manual). When handling the firearm, ensure compliance with all warnings and instructions contained in the manual and be especially careful to keep your firearm pointed in a safe direction. If you should need further assistance please call our Service Department at 928/778-6555 between 8:00 - 4:00, MST Monday thru Friday, at a time convenient for you. A Ruger Representative will be happy to help you.

ZFS Volumes not showing up on reboot?

If you're using ZFS on FreeBSD and your ZFS volumes do not appear after rebooting the system, verify that your rc.conf file has zfs_enable="YES". This allows /etc/rc.d/zvol to run, which executes an undocumented 'zfs volinit' command to create the /dev/zvol/... device entries. The script also adds swap space volumes if the ZFS volume has org.freebsd:swap=on set.

Apache syslogging on FreeBSD

If you need to use Syslog to send Apache log output there are plenty of examples already on the Internet. The first hit on google was the O'Reilly Sysadmin blog, which is very useful. However, the page is a bit old and the perl script they provide for Syslogging access logs is in need of updating. My modified version is below. To summarize the process..

1. Put the following script in /usr/local/bin/apache_syslog.

   
   #!/usr/bin/perl
   
   # $Id$
   #
   # A wrapper script that logs apache access via syslog. Copied from an example
   # at http://oreilly.com/pub/a/sysadmin/2006/10/12/httpd-syslog.html
   # Script requires sysutils/p5-Sys-Syslog from FreeBSD ports.
   #
   
   use Sys::Syslog qw( :DEFAULT setlogsock );
   
   # Excluded, per the rules of Sys:Syslog
   # http://search.cpan.org/~saper/Sys-Syslog-0.29/Syslog.pm#THE_RULES_OF_SYS::SYSLOG
   #setlogsock('unix');
   openlog('httpd', "cons, pid", 'local2');
   
   while ($log = ) {
   syslog('notice', $log);
   }
   
   closelog;

2. Install sysutils/p5-Sys-Syslog from ports (FreeBSD).
3. In your Apache config replace your ErrorLog directive with "ErrorLog syslog:local1".
4. Replace your CustomLog directive (for access logs) with "CustomLog |/usr/local/bin/apache_syslog combined".
5. Edit /etc/syslog.conf, adding the following lines
   !httpd
   local1.* /var/log/httpd-error.log
   local2.* /var/log/httpd-access.log
   !*
   
6. Create the log files with "touch /var/log/httpd-error.log /var/log/httpd-access.log".
7. Edit /etc/newsyslog.conf, adding the following lines
   /var/log/httpd-error.log 640 14 * @T00 J
   /var/log/httpd-access.log 640 14 * @T00 J
8. (Re)start syslogd and apache.
9. Profit.