For the past two weeks our CSA share from the Gildrien Farm has included several cups of dried black beans, a food I’ve eaten many times but never really cooked with. In their weekly letter Jeremy and Caitlin helpfully included a recipe for Puerto Rican Black Beans, a tasty-sounding launching pad for the evening’s dinner.

Since I didn’t have any bacon grease on hand I figured I would just fry up several large pieces of bacon and use both the meat and the grease. I had planned to make a fritata as the main course for the evening, but after sampling the beans, decided to add some more veggies and put them on bread as our main course. Unfortunately, the result was so delicious that the crostini never made it out of the kitchen for a photo shoot.

Black Bean Crostini

• 1 cup dry black beans, soaked overnight
• 1 large onion, diced as small as possible
• 1/2 a red pepper, diced
• 1/4 lb of bacon (4-5 pieces)
• 1 cup of cherry tomatoes, quartered
• salt
• 1 baguette

1. Soak the beans overnight to soften, then simmer over medium heat for 45 minutes until tender.
2. While the beans are cooking, fry the bacon in a skillet over medium heat until it is crispy and most of the fat has melted off. Pull the bacon strips out of the pan and let cool, trying to keep as much of the grease in the skillet as possible.
3. Turn down the heat on the skillet to low. Add the diced onion and some salt to the bacon grease in the skillet and cook for 15 minutes, slowly letting the onion turn clear and caramelize.
4. Drain the majority of the water from the beans (leaving about a half cup) and add the beans and their water to the skillet with the onion and bacon grease. Stir together with the red pepper. Raise the heat to medium and stew for another 15 minutes or so, until the beans begin to fall apart.
5. Mash the beans in the skillet with a utensil of some sort until you have chunky bean paste interspersed with red-pepper and bean husks. Crumble the bacon and stir it into the beans. Salt to taste.
6. Cut the baguette into thin slices. Pile a large dollop of beans on each slice and top with diced cherry tomatoes.

The RiverLevels widget provides an easy way to monitor the amount of water flowing in your favorite streams and rivers right from your Dashboard. The RiverLevels widget is of particular interest to whitewater kayakers and canoeists.

Once any United States Geological Survey (USGS) stream-gauge station is selected, it is automatically refreshed to always provide you with the latest graph of the water-level. As of version 1.2 you can choose between two graph styles: discharge in cubic feet per second (CFS) and water-height in feet.

This widget is Free software, licensed under the GNU General Public License (GPL) version 3 or later.

• Download (alternate download link)

• More Info
• Apple’s Download page for RiverLevels.wdgt
• Bug Tracker

Requirements:

• OS X – 10.4 “Tiger” or later

Change Log:
1.2.2 (2011-03-23)

• Fix for image URL change in USGS site.

1.2.1 (2008-02-10)

• New zip archive includes the ‘library’ directory missing in the 1.2 release.

1.2 (2008-02-06)

• Fixed Leopard (10.5) compatability bug.
• Added the ability to choose Gauge Height (ft) in addition to discharge (CFS).

1.1 (2007-01-08)

• Fixed graphs extending off bottom of widget
• Fixed invisibility of front refresh icon

My current woodworking project is a Mission-style bookshelf that I designed to match the sofa table that I built last year. The bookshelf will sit below a window to the kitchen, so it is low and extra wide to fit that space. To support the weight of the books without sagging, sets of stiles transfers weight from the middle shelf to the frame above and below.

I am building the bookshelf out of cherry. Like the sofa table, all joinery is mortise and tenon. This time I am squaring out the mortises with a new set of mortising chisels rather than rounding off the tenons with a knife as I did on the sofa table — which is making the process go much faster.

If you like the design and wish to build one for yourself, you can download my SketchUp model as a starting point.

For example, here is the history of my drupal repository after some work updating the cas module to the latest version (and to support the new version of phpCAS):

As you can see, I have a number of commits, followed by a merge in with the new module code, followed by some more commits.

Now, if I merge my feature branch (master-cas3-simple) into the master via

git merge  master-cas3-simple

then the history will look like this:

While the history is all there, it isn’t obvious that all of the commits beyond “Convert MS Word quote…” are a single unit of work. They all kind of blend together because git performed a “fast-forward” commit. Usually fast-forward commits are helpful since they keep the history from being cluttered with hundreds of unnecessary merge commits, but in this case we are loosing the context of these commits being a unit of work.

To preserve the grouping of these commits together I can instead force the merge operation to create a merge commit (and even append a message) by using the --no-ff option to git merge:

git merge --no-ff -m "Upgraded CAS support to to cas-6.x-3.x-dev and phpCAS 1.2.0 RC2.5" master-cas3-simple

This results in the history below:

As you can see, merging with the --no-ff option creates a merge commit which very obviously delineates work on this feature. If we decided that we wanted to roll back this feature it would be much easier to sort out where the starting point before the feature was.

The tooling has involved a few challenges however, since Jasig (the organization that hosts the CAS and phpCAS projects) uses Subversion for its source-code repositories and we use Git for all of our projects. Now, I could just suck it up and use Subversion when doing phpCAS development, but there are a few reasons I don’t:

1. We make use of Git submodules to include phpCAS along with the source-code of our applications, necessitating the use of a public Git repository that includes phpCAS.
2. The git-svn tools allow me to use git on my end to work with a Subversion repository, which is great because…
3. I find that Git’s fast history browsing and searching make troubleshooting and bug fixing much easier than any other tools I’ve used.

For the past two years I have been using git-svn to work with the phpCAS repository and every so often pushing changes up to a public Git repository on GitHub. Our applications reference this repository as a submodule when they need to make use of phpCAS. Now that I’ve been doing more work on phpCAS (and am more interested in keeping our applications using up-to-date versions), I’ve decided to automate the process of mirroring the Subversion repository on GitHub. Read on for details of how I’ve set this up and the scripts for keeping the mirror in sync.

On my development server I have a git repository I’ve cloned from the Jasig Subversion repository via:

git svn clone --stdlayout https://source.jasig.org/cas-clients/phpcas/

I use this repository for my phpCAS development and am continually using git svn rebase and git svn dcommit to update my branches from Subversion and commit changes back to the Subversion repository.

My goal was to fetch from Subversion and push all of the branches and tags from the Subversion repository to GitHub while ignoring any private branches or un-dcommited changes I might have kicking about my development repository.

Step 1: Add the GitHub repository as a remote

git remote add github git@github.com:adamfranco/phpcas.git

Step 2: Fetch the latest changes from the svn repository
To do this, I just needed to run git svn fetch to import commits from the Subversion repository into my Git repository.

Step 3: Make Git tags for Subversion tag-branches
I may be doing something wrong, but it seems that Subversion tags come through git svn as git branches rather than as git “tag” objects. Basically they are a branch with a single commit that just adds the tag message, but no content change. Using git show I found I could grab the parent id, message, and other metadata from the “tag-branch”, then feed that into git tag to create actual tag objects in the git repository.

Step 4: Push subversion branches and newly created tags to GitHub
When called with no parameters git push will push all branches that have matching names in both the source and the destination repository. This wasn’t going to work for me since I want to only automatically push the branch-state that exists in subversion (not any un-dcommitted changes in my Git repository) and want to create mirrors of any new branches that appear in the Subversion repository. To accomplish this I needed to specify every branch individually. I determined the list of branches via:

git branch -r | grep -v '/' | grep -v trunk

then looped through them and appended them to the hard-coded mapping between the svn “trunk” and the GitHub “master”:

$cmd = 'git push --tags github refs/remotes/trunk:refs/heads/master ';
foreach ($svnBranches as $branch) {
	$cmd .= 'refs/remotes/'.$branch.':refs/heads/'.$branch.' ';
}

All together: update_github_phpcas
Below is a script which performs the tasks above. I’ve added it to my crontab so that it runs every half-hour and keeps my GitHub repository in-sync with the Jasig Subversion repository.

I think that this script should work with very few changes for mirroring any Subversion repository as a Git repository.

Above Bittersweet Falls, the Beaver Brook cuts a deep ravine through layers of black slate. The gorge can be difficult to traverse without getting one’s feet wet, but is filled with cascades and mossy bottoms ringed by ferns and overshadowed by hemlocks.

I headed out the door today planing to swing by Bittersweet Falls for a few quick shots before driving out to the Dead Creek Wildlife Management Area where stargazer05756 has been following the migration of snow geese. I never made it to Dead Creek. After taking a few shots below the falls I climbed up above and noticed an impressive gorge winding upstream. Ever since I was a child I have always loved exploring up cascading streams. There is just something magical above clambering around a rock to find another waterfall or quiet pool surrounded by moss, ferns, hemlocks — and in the south, rhododendrons.

The Beaver Brook didn’t disappoint and while its steep slate side posed a challenge, I hiked about a third of a mile upstream along the stream bed before scaling the hillside and quickly walking back to the car from above.

View Larger Map

The Northeast Waterfalls site has directions and more info.

gawk '{ print $7}' /var/log/httpd/access_log | sort | uniq -c | sort -nr | head -n 20

Parts of the command explained:

1. gawk '{ print $7}' — return only the 7th [white-space delimited] column of text from the access log, which happens to be the path requested.
2. sort — sort the lines of the output.
3. uniq -c — condense the output to unique lines, prepending each line with the number of times that line occurs.
4. sort -nr – sort the resulting lines numerically in reverse order.
5. head -n 20 — chop off all but the first 20 lines.

The result should look something like this:

  83361 /
  49582 /feed
  39616 /robots.txt
  36265 /favicon.ico
  17048 /?feed=rss2
  10798 /archives/3
  10036 /wp-content/uploads/2007/05/img_7870_header.jpg
   9913 /wp-includes/images/smilies/icon_smile.gif
   9425 /wp-comments-post.php
   8274 /feed/
   7508 /archives/category/work/feed
   7367 /archives/88
   7312 /photos/10_small/IMG_3023.JPG.jpg
   7175 /photos/10_small/IMG_3028.JPG.jpg
   7151 /photos/10_small/IMG_3024.JPG.jpg
   7096 /photos/10_small/IMG_3026.JPG.jpg
   6381 /photosetToKML.php?set=72157594417350372&size=small
   6253 /qtvr/2007-04-05_back_deck_snow%20-%2010000x5000%20-%20SLIN%20-%20Blended%20Layer0002.jpg
   5798 /photosetToKML.php
   4344 /archives/category/photography

Why use reverse-proxy caching?

For most public-facing web applications, the significant majority of their traffic is anonymous, non-authenticated users. Even with a variety of internal data-cache mechanisms and other good optimizations, a large amount of code execution goes into executing a PHP application to generate a page even if the content of this page will be the same for many users. Code and query optimization are very important to improving the experience for all users of a web application, but even the most basic “Hello World” script will top out at about 3k requests/second due to the overhead of Apache and PHP — many real applications top out at less than 200 requests/second. Varnish, a light-weight proxy-server that can run on the same host as the webserver, can cache pages in memory and can serve them at rates of more than 10k requests/second with thousands of concurrent connections.

While the point of web-applications is to have content be dynamic and easily changeable, for most applications and most of the anonymous users, receiving content that is slightly stale (cached for 5 minutes or something similar) isn’t a big deal. Sure, visitors to your blog might not see the latest post for a few minutes, but they will get their response in 4 milliseconds rather than 2 seconds.

Should your site get posted on Slashdot, a caching reverse-proxy server will give anonymous visitor #2 and up the same page from cache (until expiration), while authenticated users continue to have their requests passed through to the Apache/PHP back-end. Everyone wins.

Caveats

Before we get into how to set this up, you should be aware of a few caveats (in addition to increased complexity) that come with this scheme.

1. Stale Content

Ideally, pages would always be served from the cache for as long as they don’t change, then the application would expire pages when they are changed on the back-end. Varnish has an API that supports this behavior and Drupal Varnish module is being developed to do this dynamic cache-clearing for Drupal sites, but overall, dynamic cache clearing is much more difficult to set up than time-based cache expiration.

When using time-based cache expiration, the challenge is to balance the needs for content freshness (shorter cache lifetimes) against the efficiency of cache hits (longer cache lifetimes will result in more clients using the cached versions). For content that doesn’t need to be up-to-the-minute fresh, a cache lifetime of around 5 minutes might be a good starting point. If the content only changes daily at certain time, a fixed expiration time (shortly after the data sync) might be appropriate.

2. Cookie Use

If your application only uses a cookies set by PHP’s session_start() function, then lazy_sessions.php should work transparently without modification of either that include file or your application (other than including the file). If your application sets other cookies then these will cause the reverse-proxy not to cache them unless you specifically exclude them in the reverse-proxy server’s configuration.

3. Data Caching in the $_SESSION

If you use the $_SESSION array as a data cache on anonymous requests, then these anonymous requests will be given a session cookie and their requests won’t be served from the reverse-proxy’s cache. Rather than using the $_SESSION array for non-user-specific data, cache such data with APC or memcached. This also has the advantage of such non-user-specific data not having to be rebuilt for every new client.

4. flush() and output buffering

The default PHP session handling mechanism adds the session cookie to the response headers right when session_start() is called and writes the data off to the file-system after the script exits and the data has been sent. This default behavior ensures that users will always get a session cookie and saves the session data as the final processing step after all class destructors have been called.

Since we don’t want to always set a session cookie, we need to remove the Set-Cookie header before headers are sent to the client. Output buffering with ob_start() will ensure that we have a chance to decide to clear the Set-Cookie header at script shutdown.

In some cases (such as incrementally sending large binary files) we want to send the content body (and therefor also the headers) before the script exits using the flush() function. To ensure that the session cookie is properly removed session_write_close() must be called before flush() or any other code that causes headers to be sent.

Implementation

Implementing reverse-proxy caching has three steps: PHP changes to enable lazy sessions, PHP changes to set cache-controlling headers, and finally the reverse-proxy server setup. For this example I’ll use the Varnish reverse-proxy server, but others could be used instead.

1. PHP: Lazy Sessions

The first thing that needs to happen to make anonymous requests cache-able in an application that uses sessions is to ensure that sessions are only started when there is session data to be stored. By default, PHP’s session handling mechanisms add a session cookie to the response header and store a session data file on the server on page-load that calls session_start(). While this behavior makes it easy to write applications that use sessions, it effectively means that there is no way to differentiate between responses that are for a particular user and those that could be for many users.

Including the lazy_sessions.php file before session_start() is called will override the default session-handling mechanism with one that checks to see if there is any data in the $_SESSION array before sending the user a Set-Cookie header and storing a session file:

<?php

// Include files or other pre-session_start code

require_once('lazy_sessions/lazy_sessions.php');
start_session();

// The rest of the application code.
?>

If your application needs to flush content and thereby send headers before script shutdown (such as incrementally sending file data), call session_write_close() if session_start() has been called for that script:

<?php

// Include files or other pre-session_start code

require_once('lazy_sessions/lazy_sessions.php');
start_session();

// other application code.

// If session_write_close() is not called before flushing, then the Set-Cookie
// header will be sent before our custom session handler has a chance to determine
// if a session is even needed.
session_write_close();

print "Hello";
flush();
print " World.";
flush();

?>

2. PHP: Cache-Control headers

Now that we have our cookies straightened out, we need to ensure that our PHP scripts respond with HTTP headers that indicate that downstream clients such as our reverse-proxy and the user’s browser are allowed to cache anonymous pages. There are a number of different Cache-Controlling Headers that may affect whether a particular cache may store a given response. By default, PHP sets all of these headers to indicate that no caches may store any pages, ensuring that they are dynamic.

<?php

// If the session data is empty, then we could assume that there is no per-user data
// and that the response can be cached.
if (!count($_SESSION)) {

// Alternatively, we could check an application-specific value (such as a user-id)
// to determine if the response is for a particular user.
// if (!isset($_SESSION['user_id'])) {

// Cache for 5 minutes
$maxAge = 300;

header('Expires: '.gmdate('D, d M Y H:i:s', time() + $maxAge).' GMT', true);
header('Cache-Control: public, max-age='.$maxAge, true);
header('Pragma: ', true);
}

header('Vary: Cookie,Accept-Encoding', true);

The two most important headers with regard to caching with varnish are the following:

The Cache-Control header.

The Cache-Control: public, max-age=300 header indicates to any clients (such as the Varnish caching proxy) that this response can be cached in public caches valid for many downstream clients. The max-age portion of the header indicates that the cache may store this response for 300 seconds.

As I understand it (possibly wrong) Varnish only looks at the max-age portion of the Cache-Control header when determining how long to store a response. Apparently it ignores the Expires header for its cache-expiration purposes, though this header is passed on to downstream clients.

The Vary header

The Vary: Cookie,Accept-Encoding header tells Varnish (and in-browser caches) that they should not respond with the cached version of a response if the request includes a cookie or a different cookie from the request that previously had its response cached. Similarly, if one client says that it accepts gzip encoding via an Accept-Encoding: gzip request header, then the cached response may be compressed with gzip and should not be sent in response to requests from clients that do not state that they accept gzip encoding.

While Varnish’s behavior is to never cache or respond from cache when cookies are present, without the Vary: Cookie response header, browsers or other downstream caches may respond with a cached response valid for only anonymous users even though a cookie is now present.

See my notes on Cache-Controlling Headers for more details about other headers and how they affect the Varnish cache and in-browser caches.

3. Varnish (Reverse-Proxy) Configuration

The /etc/varnish/default.vcl config file controls how Varnish responds to requests and responses, in particular whether or not it should cache or not. Below is the contents of my default.vcl file.

backend default {
.host = "127.0.0.1";
.port = "80";
}

sub vcl_recv {
// Remove has_js and Google Analytics __* cookies.
set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(__[a-z]+|has_js)=[^;]*", "");
// Remove a ";" prefix, if present.
set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", "");
// Remove empty cookies.
if (req.http.Cookie ~ "^\s*$") {
unset req.http.Cookie;
}

// Cache all requests by default, overriding the
// standard Varnish behavior.
// if (req.request == "GET" || req.request == "HEAD") {
//   return (lookup);
// }
}

sub vcl_hash {
if (req.http.Cookie) {
set req.hash += req.http.Cookie;
}
}

sub vcl_fetch {
if (!beresp.cacheable) {
	return (pass);
}

// If using PHP < 5.3 there is no way to fully delete headers, so empty
// Set-Cookie headers may be in the response. Ignore these empty headers.
if (beresp.http.Set-Cookie ~ "^\s*$") {
	unset beresp.http.Set-Cookie;
}

if (beresp.http.Set-Cookie) {
	return (pass);
}
return (deliver);
}

Over the course of the past year I built this cherry sofa table based on a design by Scott Gibson in Fine Woodworking’s "Furniture" book.

All frame joinery is mortise and tenon, while the drawers use doweled rabbit joints. The finish is boiled linseed oil topped with 3 coats of Minwax wiping varnish.

Building this table was quite a learning experience as just about every part required techniques that I hadn’t used before. Mortise and tenon joinery, biscuits to align the table top during glue-up, doweled joints fort the drawers, quartersawn veneers for the legs, breadboard-ends, and varnish; all of these were new to me and required a bit of trial and error to get right.

This project certainly had its share of "oops" moments, but nothing that couldn’t be repaired or worked-around. I cut the bottom shelf stretcher one inch too short, but was able to cut it in half and splice in a section with a small mortise and tenon in the middle. Later, I made the hipped-tenons on which the breadboard-ends of the top sit too thin. This was repaired with the addition of some 5-minute epoxy to thicken the tenon.

All that remains now is to choose and install drawer-pull hardware.

While LDAP authentication works great, there is one problem: If a person has never logged into our Bugzilla, we can’t add them to the CC list of an issue. This is important for us because issues usually don’t get submitted directly to the bug tracker, but rather come in via calls, emails, tweets, and face-to-face meetings. We are then left to submit issues to Bugzilla ourselves to keep track of our to-do items. Ideally we’d add the original reporter to the bug’s CC list so that they will automatically be notified as we make progress on the issue, but their Bugzilla account must exist before we can add them to the bug.

Searching about the internet I wasn’t able to find anything about how to import LDAP users (or any kind of users) into Bugzilla, though I was able to find some basic instructions on how to create a single user via Bugzilla’s Perl API. To improve on the lack of user-import support I’ve created an Perl script that creates users from lines in a tab-delimited text file (create_users.pl) as well as a companion PHP script that will export an appropriately-formatted list of users from an Active Directory (LDAP) server (export_users.php).

BugzillaImport.zip — Unzip in your Bugzilla directory, run via the command line. See below for examples.

File Listings:

create_users.pl

This script can safely be run repeatedly. Only new users not already in Bugzilla will be added, users matching existing email addresses will be skipped.

#!/usr/bin/env perl
##########################################################
# This is a basic script to import users into Bugzilla.
#
# Users can be imported from tab-delimited text files or
# tab-delimited lines piped to STDIN. Lines should have 3
# columns: login	email	name
#
#
# Author:
#	Adam Franco (afranco@middlebury.edu)
# Date:
#	2010-03-08
# URL:
#	http://www.adamfranco.com/archives/374
# License:
#   The contents of this file are subject to the Mozilla Public
#   License Version 1.1 (the "License"); you may not use this file
#   except in compliance with the License. You may obtain a copy of
#   the License at http://www.mozilla.org/MPL/
#
#   Software distributed under the License is distributed on an "AS
#   IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
#   implied. See the License for the specific language governing
#   rights and limitations under the License.
##########################################################

use FindBin qw($Bin);
BEGIN {
    push @INC,$Bin;
    push @INC,$Bin."/lib";
    push @INC,$Bin."/lib/x86_64-linux-thread-multi";
}
use Bugzilla;
use Bugzilla::User;
use Error qw(:try);

sub usage {
    print "
Usage:
    $0 ListOfUsers1.txt [ListOfUsers2.txt [...]]
    $0 < ListOfUsers.txt

The ListOfUsers can be passed as either a file argument or passed to STDIN.

The ListOfUsers must be tab-delimited with the following columns:
login   email   name

";
    exit 1;
}

foreach (@ARGV) {
    if ($_ =~ /^-h|--help$/) {
        usage();
    }
}

my $lines = 0;
my $users = 0;
my $usersAdded = 0;
while (<>) {
    chomp; # Remove the trailing new-line.
    my($login, $email, $name) = split(/\t/, $_);

    if ($login && $email && $name && $login =~ /[a-z0-9]+/ &&  $email =~ /[a-z0-9]+.*@.*[a-z0-9]+/ && $name =~ /[a-z]+/) {
        if (is_available_username($email)) {
            try {
                my $user = Bugzilla::User->create({
                    login_name    => $email,
                    realname      => $name,
                    cryptpassword => '*',
                    disable_mail  => 0,
                    extern_id     => $login
                });
                print "Account for " . $user->login . " was created.\n";
                $usersAdded++;
            } catch Error with {
                my $ex = shift;
                my $error = "Error: $ex";
                $error =~ s/\n|\r/ /g;
                print $error."\n";
            };
        }

        $users++;
    }
    $lines++;
    close (ARGV) if (eof);
}

if (!$lines) {
    print "No input lines given.\n\n";
    usage();
}

print "\n$lines lines evaluated, $users user records checked, $usersAdded users added.\n";

exit 0;

export_users.php

#!/usr/bin/env php
<?php
##########################################################
# This is a basic script to export users from an
# MS Active Directory via LDAP in the format required
# by create_users.pl.
#
# Authors:
#	Adam Franco (afranco@middlebury.edu)
#	Ian McBride (imcbride@middlebury.edu)
# Date:
#	2010-03-08
# URL:
#	http://www.adamfranco.com/archives/374
# License:
#   The contents of this file are subject to the Mozilla Public
#   License Version 1.1 (the "License"); you may not use this file
#   except in compliance with the License. You may obtain a copy of
#   the License at http://www.mozilla.org/MPL/
#
#   Software distributed under the License is distributed on an "AS
#   IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
#   implied. See the License for the specific language governing
#   rights and limitations under the License.
##########################################################

$ldaphost = "ldap.example.com";
$ldapport = 389;
$ldapuser = "username";
$ldappass = "password";
$baseDN = "DC=example,DC=com";

$connection = ldap_connect($ldaphost, $ldapport);

if (!$connection) die();

if (ldap_set_option($connection, LDAP_OPT_PROTOCOL_VERSION,3) === FALSE) die();

if (ldap_set_option($connection, LDAP_OPT_REFERRALS,0) === FALSE) die();

$bind = ldap_bind($connection, $ldapuser, $ldappass);

if (!$bind) die();

$filter = "(&(objectClass=User)(!(objectClass=Computer)))";

$search = ldap_search($connection, $baseDN, $filter, array("samaccountname", "mail", "givenname", "sn"));

$entries = ldap_get_entries($connection, $search);

print "samaccountname\temail\tname\n";

foreach($entries as $entry) {
  if(isset($entry['samaccountname'])) {
    print iconv('UTF-8', 'UTF-8//IGNORE', $entry['samaccountname'][0]);
  }
  print "\t";

  if(isset($entry['mail'])) {
    print iconv('UTF-8', 'UTF-8//IGNORE', $entry['mail'][0]);
  }
  print "\t";

  $name = '';
  if(isset($entry['givenname'])) {
    $name .= iconv('UTF-8', 'UTF-8//IGNORE', $entry['givenname'][0]);
  }  $name .= ' ';
  if(isset($entry['sn'])) {
    $name .= iconv('UTF-8', 'UTF-8//IGNORE', $entry['sn'][0]);
  }
  print trim($name);

  print "\n";
}

Example Usage

After unzipping the scripts in your Bugzilla directory you can use the create_users.pl script right away. To use export_users.php you will need to edit it and add your LDAP server configuration.
[root@hostname /var/www/htdocs/bugzilla/]# ./export_users.php | ./create_users.pl

If you’d rather import users from another source, simply create one or more tab-delimited text files that have the following columns:
login    email    name
[root@hostname /var/www/htdocs/bugzilla/]# ./create_users.pl users.txt otherusers.txt

You can pipe tab-delimited data to the script as well:
[root@hostname /var/www/htdocs/bugzilla/]# head -n 20 users.txt | ./create_users.pl

Update:

• Changed the license statement to the MPL be compatible with the rest of Bugzilla
• Changed the password to ‘*’ based on Max’s suggestion