- Translator from Drupal .info to RPM .spec files

This is a very simple translation of a Drupal .info file into an RPM .spec file. It may be useful in identifying methods to assemble complex Drupal installations on dedicated servers or VPSs where the modules can be managed as RPMs. This would not be useful for casual users. It also assumes the modules will not be modified, and requires careful composition of the .info files by contributors.

I had difficulty posting the script in the blog, so the link provided must be used.

To run it, pass the URL of the module to download, for example: ./

It was tested with the annotationfield module.

Be sure to set up an .rpmmacro file at the account level.


  • Hasn’t been (and isn’t going to be) tested with an actual RPM build
  • Does not (and probably won’t) handle intermodule dependencies or conflicts

Drupal RPM spec file generator module

A Drupal RPM generator module could scan the modules installed and extract the following information:

  • Source file (full URL)
  • Requires - the modules required to support each module
  • Provides - the name of the service/capability/feature provided by each module
  • Conflicts with - modules which cannot be installed with each module

The standard BUILD, SPECS, SOURCE, RPM, SRPM directories can be used for the build process. The Drupal RPM generator would write .spec files to the SPECS directory for each module. .rpmmacros would indicate the target directory, and other common constants.

This allows a development environment to be quickly converted from a .tgz installation to an RPM managed production server.

Commandline PHP emailer

A nice commandline PHP emailer (can be adapted for sites), derived primarily from code at

Worthy of note:

  • Use of $HOSTNAME to get the name of the host. This is good for commandline when the $_SERVER variables aren’t available.
  • Separate text and HTML source files, normally, text would be derived from HTML with strip_tags.


if ($argc < 4)
die('Usage: <destination email address> <text file> <html file>'."\n");

$sHost=trim(shell_exec('echo $HOSTNAME'));





/* Courtesy of: - Modified slightly */


# Common Headers
$headers .= "From: ".$fromname."<".$fromaddress.">".$eol;
$headers .= "Reply-To: ".$fromname."<".$fromaddress.">".$eol;
$headers .= "Return-Path: ".$fromname."<".$fromaddress.">".$eol; // these two to set reply address
$headers .= "Message-ID: <".time()."-".$fromaddress.">".$eol;
$headers .= "X-Mailer: PHP v".phpversion().$eol; // These two to help avoid spam-filters

# Boundry for marking the split & Multitype Headers
$headers .= 'MIME-Version: 1.0'.$eol;
$headers .= "Content-Type: multipart/mixed; boundary=\"".$mime_boundary."\"".$eol.$eol;

# Open the first part of the mail
$msg = "--".$mime_boundary.$eol;

$htmlalt_mime_boundary = $mime_boundary."_htmlalt"; //we must define a different MIME boundary for this section
# Setup for text OR html -
$msg .= "Content-Type: multipart/alternative; boundary=\"".$htmlalt_mime_boundary."\"".$eol.$eol;

# Text Version
$msg .= "--".$htmlalt_mime_boundary.$eol;
$msg .= "Content-Type: text/plain; charset=iso-8859-1".$eol;
$msg .= "Content-Transfer-Encoding: 8bit".$eol.$eol;
# $msg .= strip_tags(str_replace("<br>", "\n", substr($body, (strpos($body, "<body>")+6)))).$eol.$eol;
$msg .=$plain.$eol.$eol;

# HTML Version
$msg .= "--".$htmlalt_mime_boundary.$eol;
$msg .= "Content-Type: text/html; charset=iso-8859-1".$eol;
$msg .= "Content-Transfer-Encoding: 8bit".$eol.$eol;
$msg .= $html.$eol.$eol;

//close the html/plain text alternate portion
$msg .= "--".$htmlalt_mime_boundary."--".$eol.$eol;
# Finished
$msg .= "--".$mime_boundary."--".$eol.$eol; // finish with two eol's for better security. see Injection.

$mail_sent = mail($sTo, "Test From $sHost", $msg, $headers);


Risks of HTML emails:

Recommending testing prior to production release
Receipt of emails on all major email clients

email forwarders

email addresses such as sales, careers, info, and help should always be forwarders. This allows them to be independent of the people that handle them. It also simplifies development and content management by using the final address, which must then be changed prior to launch.

Cleaning up after a hack

grep -rl MultiViews *  | sed  "s/\(.*\)/chown user:group \1/" > chown_multi
grep -rl bacjdzzazbzceh * | sed  "s/\(.*\)/chown user:group \1/" > chown_bacj
grep -rl MultiViews *  | sed  "s/\(.*\)/rm -f \1/" > rm_multi
grep -rl bacjdzzazbzceh * | sed  "s/\(.*\)/rm -f \1/" > rm_bacj

If you don't have root privileges on a server and need to clean up after a hack, your hosting company may be willing to change the ownership of the files so you can delete them.

You can also try to use

<?php system('./rm_multi'); ?>.