September 2005 Archives

So I ran into an interesting comment left on the manual page for session_cache_expire.

...

The garbage collector controls the session data and destroys sessions which are older then 1440 seconds (24 minutes) by default.

So to keep a session alive longer then 24 minutes (for example when a visitor tries to POST a huge message that took him 1 hour to type), you must modify the session.gc_maxlifetime thru ini_set()

Somehow i couldn't find anything in the PHP documentation regarding this and due to that me (and i think many others) got the wrong ideas regarding PHP sessions.

A few examples to fix session timeout are already posted below but in my opinion they all missed session.gc_maxlifetime

To say that people may be missing this may be an understatement.

Some time late Saturday night or early Sunday morning a really stupid person took our mailbox. I'm not happy about it. The rumors are true, the punishment is crazy insane -- "up to $250k or up to 3 years in gangster college."

But, tomorrow is a new day and we start it with a cheap, plastic mailbox. Wish it luck. It'll need it.

The Setup

I used TypeMover to migrate a site from a MT 3.17 install to a MT 3.2 install. The site happens to use Weekly archiving as the default, so that was what the Master Archive Index was trying to pick up.

The Symptom

The generated file had no weekly archive links. Oh no!

The Problem

There is a new column in the mt_entry table called entry_week_number which is the 4-digit year concatenated with the 2-digit week number (i.e. 200517). TypeMover will not populate this and the entry will have a NULL value. This borks the MTArchiveList template tag when archive_type is set to 'Weekly.' It does not break the building of the weekly pages themselves though.

The Fix

I choose to fix the database because it would take less time. I don't dive into perl code all that well. So if you are using mysql for you datastore, this script will update you.

#/usr/bin/perl -w

use Date::Manip;
use DBI;

my $dbh = 
DBI->connect("DBI:mysql:mt32:localhost", 'user', 'password');
$sql = "SELECT entry_id, entry_created_on from mt_entry 
WHERE entry_week_number IS NULL";
$result = $dbh->prepare($sql);
$result->execute();

$sqlUpdate = 
"UPDATE mt_entry set entry_week_number = ? where entry_id = ?";
$update = $dbh->prepare($sqlUpdate);

while(my @row = $result->fetchrow_array)
{
        $id = $row[0];
        $week = UnixDate($row[1],'%Y%W');
        $update->execute($week,$id);
}

Now, wasn't that fun?

What do you get when you combine racism, jingoism, and sycophants?

Answer here.

Once again I post about why I'm not posting...

Work is very busy. Big news next week that involved more paperwork than I care to talk about. JIRA is about to take off and I'll be in charge of that. We were gone over the weekend on a camping trip.

I offer you a favorite square.

If you're using an ssh tunnel to connect a nice desktop client, like Cocoa MySQL, to a remote server with strict host-based firewall rules that doesn't allow remote connections, you need to have the desktop client connect to 127.0.0.1 and not localhost. I don't know why...maybe it's just me...but one works and one doesn't.

I'm just sayin'.

Preface: I am not an expert in encryption, SSL, or LDAP. Your install may be functioning just fine and you don’t need any of this information. You use this at your own risk as it may be completely wrong. That being said, it worked for me.

Making a secure (ldaps) connection in PHP (php-4.3.9-3.8) on Red Hat Enterprise Linux AS release 4 (Nahant Update 1) will fail if on ldap_connect (Error -1: Can’t connect to LDAP server) if the certificate cannot be verified. Due to the release of a new intermediate certificate from Verisign, it is likely that your install of openssl will not have access to that intermediate cert. Thus openssl will tell you that there is a self-signed certificate in the chain (error -19). If you recently bought a certificate from Verisign you will not find much in the way of help for dealing with LDAP, PHP, or openssl.

The answer with web servers is generally well documented, and the intermediate certificate is made available to the server to send to the client. This is good because it means that 8 trillion web browsers don’t generally need to be updated to use SSL.

It should also be noted that it is probably best to “fix” this issue at the server level rather than the client because each and every client would need to be fixed as opposed to just fixing the server once. If you do not have access to the server to fix it, this should work for you.

1. Obtain a copy of the Verisign intermediate certificate. Save it as a text file on a system where you can run openssl binaries.

2. Convert from PEM to ca-bundle format. Save this output as you may need to do the next few steps on multiple servers.

   #!/bin/sh
   # Friendly Name
   openssl x509 -in $1 -text -noout | \
   sed -n -e '/^[ ]\+Subject:/{s/^.*CN=\([^,]*\).*/\1/;p}' 
   # Underline Friendly Name with equal signs
   openssl x509 -in $1 -text -noout | \
   sed -n -e '/^[ ]\+Subject:/{s/^.*CN=\([^,]*\).*/\1/;p}' | \
   sed -e 's/./=/g'
   # Output Fingerprint and swap = for :
   openssl x509 -in $1 -noout -fingerprint | sed -e 's/=/: /'
   # Output PEM Data:
   echo 'PEM Data:'
   # Output Certificate
   openssl x509 -in $1
   # Output Cettificate text swapping Certificate with Certificate Ingredients
   openssl x509 -in $1 -text -noout | sed -e 's/^Certificate:/Certificate Ingredients:/'
   

3. Locate and backup your ca-bundle.crt

   locate ca-bundle.crt should show you where on your system this file lives. On RHEL /usr/share/ssl/cert.pem is also symlinked to your ca-bundle.crt.

4. Append the converted intermediate certificate to your ca-bundle.crt file.

   You can now test using the openssl command:

   openssl s_client -host your.ldap.edu -port 636 -CAfile /usr/share/ssl/certs/ca-bundle.crt.

   A Verify return code: 0 (ok) is what you are looking for.

5. Configure OpenLDAP on the system that PHP is running on to use your ca-bundle.crt.

   Locate your ldap.conf for OpenLDAP. On RHEL it is /etc/openldap/ldap.conf.

   Add the following: TLS_CACERT /usr/share/ssl/cert.pem (which on RHEL is a symlink to ca-bundle.crt). Thanks to Rutgers for this tidbit.

6. Restart httpd.

PHP should now successfully connect securely to your LDAP server.

Errata

Added restart of httpd (2005-09-10 11:52:00)

Is not a flunky. Yay.

FEMA has come a long way from the days of mythical treatment from the X-Files...

The people who are saying that the those stranded in NO should have left sooner and just "lost the bet" should shut the hell up until they read this WaPo article.

Court martial. Impeachment. Retirement.

I don't care.

Pick one. Pick it now. Get out of our lives and quit fucking this country up you useless bastard. We can't deal with another day of your pathetic excuse for leadership. You are a failure. You don't deserve what you have. You haven't done a damn bit of good since they day you took office. May God have mercy on your sad excuse for a soul.

Tens of thousands of people spent a fifth day awaiting evacuation from this ruined city, as Bush administration officials blamed state and local authorities for what leaders at all levels have called a failure of the country's emergency management.

The only difference between the chaos of New Orleans and a Third World disaster operation, he said, was that a foreign dictator would have responded better.