You are currently browsing the monthly archive for August 2007.

I have some installations of Fedora Directory Server (FDS) running as the user nobody. It is generally preferred that services like FDS run under a dedicated user and certainly not the nobody account. The user is configured during an initial scripted interactive setup but I wanted to change the user for the existing installations. I could not find a how-to for doing this (though did not look very hard) so I did a new installation on a beater box and during setup configured it to run as user ldapperuser and group ldappergroup. I used this installation to experiment with reconfiguring the user.

I shutdown the slapd service and changed ownership of the files owned by ldapperuser and/or ldappergroup.

find /opt/fedora-ds -user ldapperuser | xargs chown ldap
find /opt/fedora-ds -group ldappergroup | xargs chgrp ldap

By grep’ing for the silly user and group names I found these text files needed to be edited to change the user and/or group.


I restarted the slapd process and confirmed in a process list that it was running as the new user.

Finally, I exported the entire directory to an ldif file and grep’ed it for the user and group names. There I found that I needed to change the nsSuiteSpotUser attribute in "cn=slapd-pepper, cn=Fedora Directory Server, cn=Server Group,,, o=NetscapeRoot"

I made this change to nsSuiteSpotUser via the Admin console.

There may very well be an official way to change the user for an installed FDS but this brute force method is simple enough.

Things I learned in the past 24 hours.

1. If you use NetNewsWire 2.1 and one day it rejects your purchased serial number with “This serial number has been used too many times, or is associated with another NewsGator account.”, then you have hit a known bug and need to get the free update.

2. An account with NewsGator is required but not necessary to use NetNewsWire. A quandary that this harshes this consumer’s buzz.

Long winded rambling about NewsGator after the jump.

Read the rest of this entry »

I frequently use placeholders and bind values with Perl DBI and during debugging phases I frequently want to see what values are being bound. The bound values are available from the statement handle’s ParamValues.

%bound_values = %{ $sth->{ParamValues} }; 

Here’s a simple script to illustrate.


use DBI;
use Data::Dumper;

my $dbh = DBI->connect(

my $sql = "select 'something' from dual where 1 = ? and 2 = ?";

my $sth = $dbh->prepare($sql);
$sth->execute(1, 2);

print Dumper $sth->{ParamValues};

Will print a result like:

$VAR1 = {
          ':p1' => 1,
          ':p2' => 2

This is handy but awkward to work with when there are a lot of placeholders. Is there a simple way to print the param values in the context of the sql statement? Like so,

select 'something' from dual where 1 = 1 and 2 = 2

That would be a swell thing to be able to do.


What are placeholders in DBI, and why would I want to use them?
DBI perldoc
Tim Bunce’s Advanced Perl DBI


August 2007