Author: Brandon (Page 17 of 30)

I have a PHP function that I wrote a long time ago to generate a random string of characters:

function randomString($size = 25)
{
    $charset = 'abcdefghijklmnopqrstuvwyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890';
    $string = '';
    for ($i=0; $i < $size; $i++) {
        $string .= $charset[(mt_rand(0,(strlen($charset) -1)))];
    }
    return $string;
}

I have been using this to generate a random ID, which is then inserted into a database column as a unique key. Theoretically, it has
62²⁵ possible unique values (or 6.45 * 10⁴⁴) if case sensitive or 36²⁵ (2.36 * 10³⁵) when used in a case-insensitive application. That is a lot of possible combinations, and I figured it would be rare that I’d get two that ever were the same.

I was wrong.

I must be running into some kind of issue where the pseudo-randomness is not as random as I thought. I’m inserting somewhere in the neighborhood of 25k rows a day into this table for the past couple weeks and have had over 20 errors generated where the database complained that the unique key already existed. I investigated a couple and found that it was, indeed correct. My database is not case sensitive and would have complained if the two had the same characters even if the cases weren’t the same. So I was pretty surprised when I looked at the errors and found that in each case the 25 character strings were exactly the same, even all of the letters in it were the same case.

So I’ve had to revert to another method that I like a little better anyway.

I ran across a system today that was using the VHCS control panel. It looks like the system wasn’t correctly configured to allow SMTP authentication. It uses Postfix as the MTA and Courier-IMAP for the Imap/POP3 server. It was populating the Courier-authentication database with email addresses and passwords to use for logging into the incoming mail server, but postfix wasn’t configured to use the same database for authenticating and providing an outgoing mail server.

This is what I had to do to get it working

Edit your system’s smtpd.conf file (/var/lib/sasl2/smtpd.conf for RedHat and derivatives. /etc/postfix/sasl/smtpd.conf for Debian and Ubuntu derivatives). And put in this content:

I think this is a default install looks like:

pwcheck_method: saslauthd
mech_list: PLAIN LOGIN

So change it to this:

pwcheck_method: authdaemond
mech_list: PLAIN LOGIN
authdaemond_path: /var/run/courier/authdaemon/socket

Of course, make sure that the authdaemond_path is correct for your system, and change as needed.

Then restart postfix and see if that works. You can use my SMTP Authentication String tool to get your encoded password and try it through telnet. Tail your mail log to see if it gets any errors.

On the system I was working on. Postfix was configured to chroot the smtpd processes (in /etc/postfix/master.cf). I got errors in the mail log that looked like this:

Jan 24 19:52:46 host postfix/smtpd[14528]: warning: SASL authentication failure: cannot connect to Courier authdaemond: No such file or directory
Jan 24 19:52:46 host postfix/smtpd[14528]: warning: SASL authentication failure: Password verification failed
Jan 24 19:52:46 host postfix/smtpd[14528]: warning: host.local[127.0.0.1]: SASL plain authentication failed: generic failure

So, in that case, I simply hard-linked the courier authdaemon socket file inside of the chroot (/var/spool/postfix)

cd /var/spool/postfix
ln /var/run/courier/authdaemon/socket courier-authdaemon-socket

Then change the authdaemond_path to just ‘courier-authdaemon-socket’. Restart postfix and it should work

The PHP ADOdb libraries are a database abstraction layer that tries to hide the database specific commands from the programmer.  It tries to allow the programmer to write code that will be portable between any backend database engine.  Since not all databases provide an insert id, ADOdb provides a wrapper for it in the form of it’s Insert_ID() function.

It implements it in a really ugly way though. Whenever you use it’s pseudo insert_id functions, it creates a _seq table with a single column and a single row. For example, if you are inserting something into a table named ‘users’, it will create a table named ‘users_seq’ with a single ‘id’ column. It generates one row in that column with an insert id that it calculates and increments on it’s own.

First off, that is really ugly. I hate having a whole bunch of extra tables in my database, and it makes it even worse that they only have a single value in them. I wish they would have implemented that differently, and made a single ‘_sequences’ table with two columns (table and id).   At least that would keep the tables to a minimum and centralize where all of the insert id’s are at.

The other bad part about it, is if you access the database with anything other than the ADOdb application, it is difficult to use this required structure. In most cases, things break and I get duplicate key constraints and it is just generally a pain.

So I’ve decided not to use it ever again. Its not likely that I’ll ever change the database anyway, so I might as well take advantage of the handy insert_id functionality already provided by MySQL.  Just do your queries as you would normally, including the ‘INSERTID’, and then you can retrieve the insert_id like in this example:

CREATE TABLE `users` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `name` varchar(80) NOT NULL,
  `email` varchar(80) NOT NULL,
) ;

// I assume you know how to create a ADOdb object
$db ->query("
    INSERT INTO USERS (id, name, email) VALUES ('INSERTID', 'Joe User', '[email protected]')
");
$user_id = $db->_connectionID->insert_id;