spam: the other white meat

A post about using Media Mover to mirror files across multiple servers got me thinking about how to securely manage remote server access in Drupal. Keeping server account data in Drupal’s database is a bad idea- a compromise to your site means a compromise to all the servers that you have in the system. While you could keep the accounts that you use to access the remote systems limited, it is still bad practice.

Generally this problem is solved with SSH keys- a system that can authenticate logins that have a valid key. The problem is that this really elevates the barrier to entry for people who do not want to deal with the command line. It should be the case that you can create a login for a remote server (for backups for example) inside of Drupal, in a secure fashion, which never requires firing up your trusty terminal. For those of us who deal with the command line on a regular basis, this is not so much of an issue, but for people who do not, it basically encourages bad security practices. From my perspective, the barrier to security is primarily ease of use- so long as FTP seems “easier” than SCP, it will be used.

So what might a solution look like for Drupal? I imagine a SSH keys manager module. This module handles key creation and management, and provides an API that allows other modules (like a secure ftp backup module for example) to login to a server and issue commands. I can imagine some of the following functionality:

The implementation for backing up a file might look something like:
<?php
echo shell_exec("scp ". $current_file['path'] ." ". ssh_keys_server($server_id) .":/backups/". $current_file['name']);
?>
Here ssh_keys_server() would handle making sure the path to the key file was right as well as getting the right server information from the database. This would be an example of where the key file was not password protected. If you have php-ssh installed on your machine, this could probably be vastly simplified, but this is just sort of throwing the idea out there. Any thoughts?

Spam proves itself bizarre more often than not. Here’s the most absurd one I’ve gotten of late:

Complete with lolcat speak.

I’ve just added the new Auto Run module to Media Mover’s 1.0alpha3 release. This module is a straight forward attempt to bridge the gap between people who need the complex functionality that Media Mover offers and people who need their data to be converted on demand. This module will run specified Media Mover configurations on node inserts and updates- meaning that when a user submits content or updates content, the specific Media Mover configurations will be run. In addition, this functionality leverages some earlier updates that let Media Mover run only on the specific node in question. This helps keep processing overhead down.

This screen shot shows the listing of the Media Mover configurations that are available to run. Note that the administrator should choose configurations that are harvesting from nodes- otherwise it is just wasted cycles.

Using a similar system that I built for Media Mover, I implemented an import / export system in the FLV Media Player module which allows an administrator to move configurations from one site to another. This is great if you’re working on your development site and want to port the new configuration to your live site.

Once the 1.0 release is stabilized for both, I’ll write some functions that allow modules to define FLV Media Player profiles and Media Mover configurations in custom modules so that these can be kept under version control, making it easier to deploy changes via version control.

Thanks to heyrocker for the photo.

I just realized that my talk on Media Mover at the Seattle Drupal Users’ Group from this past June was posted on Blip. I guess I’m a bit behind the times! This is similar to the talk that I did in NYC with less command line and more talking. Interestingly, some of the items that are “future plans” have actually been completed already and are in the alpha releases of Media Mover 1.

The Seattle group is really impressive- super well organized, really well attended weekend with great talks and great people. Both Robin and Gregory really knocked this one out of the park!

Just got back from the first (well that I know of) Vermont Drupal User’s Group, and it was lovely to meet other Vermonter’s who are working with Drupal. That much better to have it in my own back yard. It’s really interesting to see how high the level of conversation is- especially from people who don’t consider themselves coders. I think it really points to how sophisticated the community of Drupal is- from users to developers. The next one will be in Burlington, September 9th, 4pm, location TBA.

The power and flexibility of FFmpeg is a strength and a weakness. While it provides a huge number of options, it’s easy to create a configuration that actually doesn’t work. Case in point has been my experience with Media Mover- the most common thing that people want to use it for is creating FLV files from a variety of source material. Unfortunately, setting the codec or bit rate right can be somewhat challenging, to the point where people create configurations that will not convert the files they have.

I’ve setup FFmpeg wrapper to use configuration files. For each output format, a format file can be create which defines what kinds of options are available (codecs, bit rates, sample rates, etc). These files are loaded via ajax and any form that conforms to a set of rules can be updated on the fly as the user selects different options.

While this currently only works for Media Mover’s FFmpeg processing module, it would work for any module that wanted to implement the setup. Further, people who have experience with specific kinds of output formats can contribute back configuration files that help improve the output from FFmpeg.

The screencast below shows this process in action- I’m adding a new configuration to Media Mover and then selecting different output options for FFmpeg. While I only have one configuration complete at this time (FLV) switching between other options grabs the default (ie: all) options. It also turns the advanced configurations off when you select an option that uses the default- this way FFmpeg will take it’s best guess at converting unless you specifically tell it to.

On top of this, I’ve added support in mm_ffmpeg to enter in your own command- while this is potentially dangerous, it gives people with advanced needs of FFmpeg the ability to run what they need.