Symfony’s production environments don’t create logs, but the development environments do, and for one project I had several batch jobs logging to the myproject/log directory. (Troubleshooting batch jobs without logs is just crazy).

I was going to use symfony log:rotate, but

• I would need one cron job for each log
• I had permission issues since some of the logs belong to apache and others to root
• Everything else on the machine, pretty much, is managed with the standard Linux utility logrotate. Logrotate has been around for about 174 Linux Years, and is common to most distributions.

So here’s how I did it using with logrotate.

1. WARNING: You might want to make a convenient copy of your log directory before you do this. I accidently wiped all the logs out while messing with it.
2. Create a file config/myproject.logrotate. Very simple, I just want it to use the same rotation schedule specified for the whole machine in /etc/logrotate.conf

   /path/to/myproject/log/*.log {
           weekly
           rotate 4
   }

3. Check that it will do stuff by running it with the debug flag

   logrotate -df config/badge.logrotate

4. Make a symlink to it in /etc/logrotate.d

   ln -s /path/to/myproject/config/myproject.logrotate  /etc/logrotate.d/myproject

5. Run it the first time manually to rotate your logs and make sure it does the right thing!

   sudo logrotate -fv /etc/logrotate.d/myproject

Also, as I wrote in my post about custom error pages, I have error pages set up for each, and I hate copying them. So I have invested some time into building a plugin containing the visual assets and the customized error pages, so that it’s easier to keep them uniform across all the apps I work on, and so that it will be that much quicker to build new projects.

I don’t think anyone outside my company will want my plug-in, but these instructions will hopefully be useful for anyone who wants to do the same thing.

These instructions are for symfony 1.1 but they should apply equally to 1.0 and 1.2.

Plugin organization

Here are the files and directories in my plugin:

plugins/myThemePlugin/
  config/
    view.yml
  modules/
    default/
      config/
        view.yml
      templates/
        disabledSuccess.php
        error404Success.php
  README
  web/
    css/
      mystyles.css
      myerrors.css
      mymain.css
    errors/
      error500.php
      unavailable.php
    images/
      my_swoop.jpg
      bg_sfTAlert.jpg
      bg_sfTLock.jpg
      bg_sfTMessage.jpg
      indicator.gif
      tall_gradient.jpg

Using svn:externals to install the plugin in each symfony project

I only want one copy of this thing, with version control, so I use svn:externals (for my other plugins too ).

$ svn propget svn:externals plugins
myThemePlugin/        https://mysvnserver.com/svn/web/myThemePlugin
sfGuardPlugin/        http://svn.symfony-project.com/plugins/sfGuardPlugin/branches/1.1/
$ svn up

Publishing the assets

The chapter on plugins in the The Definitive Guide to symfony explains:

Web assets (images, scripts, style sheets, etc.) are made available to the server. When you install a plug-in via the command line, symfony creates a symlink to the project web/ directory if the system allows it, or copies the content of the module web/ directory into the project one. If the plug-in is installed from an archive or a version control repository, you have to copy the plug-in web/ directory by hand (as the README bundled with the plug-in should mention).

As I showed above, I prefer to use svn:externals for my plugins, so this is a bit of a problem for me. Also, I develop on Windows (with XAMPP and Cygwin), so the more elegant symlink solution is not an option. Symfony 1.2 has a task called plugin:publish_assets that makes the copies, but that messes up my version control strategy. SO: I am going to use svn:externals to get the web assets from my plugin too.

$ svn propset svn:externals "myThemePlugin  https://my_svn_server/svn/web/myThemePlugin/web/" web
$ svn propget svn:externals web
    myThemePlugin  https://my_svn_server/svn/web/myThemePlugin/web/
$ svn up

This lets me keep the plugin in its own repository. You could get a similar effect by just checking out the files, but it would clutter up the SVN for your main project.

The end result: I have one copy of the web assets in the SVN repository, but they’re checked out twice into each project (once under plugins/myThemePlugin/web and once under web/myThemePlugin).

view.yml files

Now the overall view.yml file in plugins/myThemePlugin/config/ sets stylesheets for my whole project:

default:
  stylesheets:    
    - /myThemePlugin/css/main: { position: last }
    - /myThemePlugin/css/bannerhealth: {position: last}
    - %SF_ADMIN_WEB_DIR%/css/main
    - %SF_CALENDAR_WEB_DIR%/skins/aqua/theme

And I have another one to apply some additional stylesheets to my error pages:

error404Success:
  metas:
    title:        404 Not Found
  stylesheets: 
    - /sf/sf_default/css/screen.css
    - /sf/sf_default/css/ie.css
    - /myThemePlugin/css/errors: {position: last}
 
disabledSuccess:
  metas:
    title:        Temporarily Unavailable
  stylesheets: 
    - /sf/sf_default/css/screen.css
    - /sf/sf_default/css/ie.css
    - /myThemePlugin/css/errors: {position: last}

relative image paths in stylesheets and error pages

I use relative paths in my stylesheets (served out of myprojecturl/myThemePlugin/css/) so they can find the images (myprojecturl/myThemePlugin/images/):

background-image: url(../images/tall_gradient.jpg);

I’d do the same if my error templates (like plugins/myThemePlugin/modules/default/templates/error404Success.php) used images, but they don’t.

The pages in plugins/myThemePlugin/web/errors (which are installed via svn:externals now in web/myThemePlugin/errors) are used when things are so broken symfony can’t build template pages, so they have full HTML structure, including full stylesheet tags:

<?php $path = '..'; ?>
 
<link rel="stylesheet" type="text/css" media="screen" href="<?php echo $path ?>/../sf/sf_default/css/screen.css" />
<!--[if lt IE 7.]>
<link rel="stylesheet" type="text/css" media="screen" href="<?php echo $path ?>/../sf/sf_default/css/ie.css" />
<![endif]-->
 
 
<link rel="stylesheet" type="text/css" media="screen" href="<?php echo $path ?>/css/main.css" />
<link rel="stylesheet" type="text/css" media="screen" href="<?php echo $path ?>/css/bannerhealth.css" />
<link rel="stylesheet" type="text/css" media="screen" href="<?php echo $path ?>/css/errors.css" />

Apache error page configuration

Finally, I tell Apache to use my customized error pages for errors in this project.

  <Directory "/path/to/myproject/web">
        ErrorDocument 404 /myproject/default/error404
	ErrorDocument 500 /myproject/bhThemePlugin/errors/error500.php
  </Directory>

There we go! Now I have a lot less to do each time I make a new app; all the pretty stuff is in my plugin, and there aren’t any surprisingly brown symfony pages to throw off any users.

What do you think? Any errors or ommissions or problems?

So it’s been secretly irking me for a while that although I installed the very nice WP-Syntax code highlighting plugin for this WordPress blog, it was hard to get it to display things in reverse-video like I prefer for all my terminal and text editor windows, and like I love in the online Symfony documentation. It’s just nicer on the eyes, you know? Digging in, I found the GeSHI syntax highlighter to be impressive in scope but scary in its inline-style-generating detail.

So today, to solve the problem for more than just me, I published my very first WordPress plugin, wp-syntax-hacktify. Very educational! I like the plugin system at wordpress.org.

The plugin tells GeSHI to use stylesheets instead and provides a slightly more commented/documented stylesheet as an example for if you’d like to override it with your own color scheme.

So now my code samples can be all nicer and stuff, like this:

  /**
   * Print a string to the log using 'debug' level.  For printf-style
   * debugging.
   *
   * @param      string $m      The string to log
   * @return     nothing
   */
  public static function debug ($m) {
    if (sfConfig::has('sf_logging_enabled') && sfConfig::get('sf_logging_enabled'))
      {
        if ($logger = sfContext::getInstance()->getLogger()) {
          $logger->debug($m);
        }
      }
    elseif (sfConfig::has('bhLDAP_echo_debugging') && sfConfig::get('bhLDAP_echo_debugging'))
      {
        echo "# $m\n";
      }
    else
      {
//      echo $m;
      }
  }
 
  /**
   * Dump a data structure to the log at the 'debug' level.  Uses
   * print_r() formatting.
   *
   * @param      mixed $v         The variable/data structure to dump
   * @param      string $label    An optional label to print in front of the dump
   * @return     nothing
   */
  public static function debugDump ($v, $label = "var dump") {
    self::debug("$label:  " . print_r($v, true));
  }

Now the code on my blog can look nice even if it’s terrifically hacky!

The documentation is good, but I want a simpler recipe that also accounts for all the forseeable errors, even those that don’t get to Symfony. Some details vary by version, but in short, for symfony 1.1:

Test URLs

We want to ultimately make sure that these URLs behave the right way:

Normal errors (must have)– 404 Not Found and 500 Server Error

I have seen error 500 pages countless times during app development, but I just could NOT reproduce one to test the 500 error page. Any quick recipes for that, anyone?

More esoteric error conditions– app unavailable/locked, module disabled

all:
  enabled:     false

Steps

1. manually create a few files for the default module. DO NOT use symfony generate:module because you only want to override a small bit of the built-in default module (found in /path/to/symfony/lib/controller/default/templates/* incidentally, if you ever want to see what you’re overriding).

   $ mkdir apps/frontend/modules/default
   $ mkdir apps/frontend/modules/default/config
   $ mkdir apps/frontend/modules/default/templates
   $ touch apps/frontend/modules/default/config/view.yml
   $ touch apps/frontend/modules/default/templates/error404Success.php
   $ touch apps/frontend/modules/default/templates/disabledSuccess.php

2. Edit the templates I just made– remember, the content for these goes inside your sitewide layout.php. I started out by copying the default templates in lib/controller/default/templates/ from my Symfony distribution.
3. create mostly static pages for web/errors/error500.php and unavailable.php*** They won’t be wrapped in layout.php so they need to have the full page structure, and basically no symfony-involving PHP code (like helpers, too bad), though I do use a bit of really basic stuff, like including the URL in my mailto form on the 500 page:

     <dl class="sfTMessageInfo">
       <dt>Something is terribly broken.</dt>
       <dd>
   	  <p>
   Please 
   <a href="mailto:webmaster@mycompany.com?subject=500 error at http://
   <?php echo $_SERVER['SERVER_NAME'] . '/'. $_SERVER['REQUEST_URI']  ?>
   <?php 
   if (array_key_exists('HTTP_REFERER', $_SERVER)) {
     echo "&body=Referrer: ".$_SERVER['HTTP_REFERER'];
   }
    ?>">
   e-mail us at webmaster@mycompany.com</a> and let us know what you were doing when this error occurred. We will fix it as soon as possible.
   </p>
   	  <p>
      If you have an urgent problem, please call the Support Desk at XXXX.
   </p>
   	  <p>
      You may also find the <a href="/README.html">documentation</a> useful.
   </p>
   </dd>
   </dl>

4. Include my stylesheets, in view.yml:

   error404Success:
     metas:
       title:        ED Log 404 Not Found
     stylesheets:
       - -*
       - mystyles1: { position: last }
       - mystyles2: {position: last}
       - /sf/sf_default/css/screen.css
       - /sf/sf_default/css/ie.css
       - errors: {position: last}
   

   (and the same thing for disabledSuccess:) My web/css/errors.css overrides some of the default symfony error page styles (compare web/sf/sf_default/css/screen.css in your symfony distribution) to make them less brown, but I keep the general thing.
5. If your application has security on by default, make sure to un-secure the error pages so people can see them without logging in. Add these above the default rule in apps/frontend/config/security.yml:

   error404:
     is_secure: off
   
   disabled:
     is_secure: off
   

6. Tell Apache where to find total 500 errors and 404 errors that don’t make it to symfony (like anything that doesn’t get to a front controller, like a misspelled controller or image name):

     <Directory "/var/www/my_sf_app/web">
           ErrorDocument 404 /default/error404
   	ErrorDocument 500 /errors/error500.php
     </Directory>

7. Hrm, the table of URLs above sounds like a good test script… BUT, it resists scripting because most of the error URLs are outside symfony, so you don’t get the custom error pages when going to an actual error with sfTestBrowser, or even a regular sfBrowser, because instead you get fancy exception stuff. So, here’s a pretty lame test script I put in test/functional/frontend/customErrors.php that tests the easiest cases, but it’s not hard to manually try the others with a browser. I welcome suggestions for improvement!

    
   <?php
    
   include(dirname(__FILE__).'/../../bootstrap/functional.php');
    
   $e404_regexp = "webmaster@mycompany";
   $disabled_regexp = "xXXXX";
    
   // create a new test browser
   $browser = new sfTestBrowser();
    
   /* http://localhost/myapp/default/error404	 
   The "real" 404 page */
    
   $browser->
     get('/default/error404')->
     isStatusCode(404)->
     isRequestParameter('module', 'default')->
     isRequestParameter('action', 'error404')->
     checkResponseElement('body', "/$e404_regexp/");
    
    
   /* http://localhost/myapp/default/disabled	 
   The "unavailable" page for when symfony is locked with symfony project:disable */
    
   $browser->
     get('/default/disabled')->
     isStatusCode(200)->
     isRequestParameter('module', 'default')->
     isRequestParameter('action', 'disabled')->
     checkResponseElement('body', "/$disabled_regexp/");

   And a few passing tests is better than none, right?

   $ php ./symfony test:functional frontend customError
   # get /default/error404
   ok 1 - status code is 404
   ok 2 - request parameter module is default
   ok 3 - request parameter action is error404
   ok 4 - response selector body matches regex /webmaster@mycompany/
   # get /default/disabled
   ok 5 - status code is 200
   ok 6 - request parameter module is default
   ok 7 - request parameter action is disabled
   ok 8 - response selector body matches regex /xXXXX/
   1..8
    Looks like everything went fine.
   

Sheesh, it’s still a little too involved for such a small benefit. If anyone has any ideas on how to streamline this procedure, let me know! Maybe it could be a plugin or an enhancement to symfony?

• Disabling projects only works if the check_lock option is enabled in e.g. apps/frontend/config/settings.yml

** Symfony 1.0 default templates are found in …/symfony/data/modules/default/templates/ and include an ‘unavailable’ template in addition to ‘disabled’. Symfony 1.2 templates are in the same place as in 1.1.

*** Symfony 1.2 wants its 500 error page in config/error/error.html.php

We need a quick-and-dirty LDAP server with basically a list of usernames and passwords to point Cisco ACS gear at, in order to provide people with limited-time authentication tokens to a wireless network. I need to populate that with an HL7 interface in Perl and make a web app UI frontend (preferably using symfony). The latter two interfaces are well established around here with MySQL, so I am trying to use OpenLDAP’s SQL backend to make that happen naturally.

Simplifications

Unlike other similar implementations out there, I have smaller goals:

• The database will be updated/written by the HL7 interface and web interface. The LDAP tools don’t need to write to it.
• All my user data should fit nicely into two tables (users and groups… and another table to relate many-to-many), and two Objectclasses in LDAPland.

Resources

These were unexpectedly hard to Google up, which is partly why I’m documenting them here for Posterity.

• Zytrax has an open source book about LDAP entitled LDAP for Rocket Scientists, which has an excellent chapter about LDAP concepts, which is nice since I don’t really understand LDAP like I do the other technologies involved.
• Section “10.10.2. back-sql Configuration” of the OpenLDAP manual
• The slapd-sql man page is indispensible. See especially the “METAINFORMATION USED” section.
• The README that comes with the back-sql samples
• The samples themselves (either unpack servers/slapd/back-sql/rdbms_depend/mysql from the source tarball or browse them, but you’ll probably want them unpacked so you can feed the schema to the mysql client. MOST OF WHAT YOU NEED TO LEARN is demonstrated in the samples.
• This 4-year-old blog article at/by “Flat Mountain” is sketchy but an improvement over the documents above!
• Albert Lash at DocuNext has a 2-year-old post similar to this one with another list of fine references!
• This HOWTO for OpenLDAP and Postgresql by Gilles Darold is far superior than the other articles, but needs adaptation of course for MySQL
• Likewise, here’s a good article for doing the same thing with Oracle/MSSQL
• And here are some extended notes from someone who did it with Oracle, including another explanation of the data mapping part.

I. Install Stuff

I’m using RHEL5 on a virtual machine. Your package system may vary. You may in fact have to compile from source to get SQL support in LDAP.

$ sudo yum install openldap openldap-clients openldap-servers openldap-devel openldap-servers-sql

II. Get and unpack the source code for the MySQL samples

1. Download the source tarball to your machine
2. Unpack it

   tar zxf openldap-stable-20080813.tgz

III. Create the database and tables

Make sure the mysql server is running of course. We’re assuming it’s on the same host as the LDAP server.

Create the database (my_db_name) and a password-having user (my_mysql_user) with all privileges to that database (I recommend the MySQL Administrator GUI for this, strangely enough since I usually dislike clicking on stuff). You should be able to connect to your database like this now:

$ mysql -umy_mysql_user -pxxxxxxxxxxxxx  my_db_name

Build the tables that configure how OpenLDAP talks to the database.

1. cd into servers/slapd/back-sql/rdbms_depend/mysql from the unpacked openldap source
2. Feed backsql_create.sql to the ‘mysql’ client

   $ mysql -umy_mysql_user -pxxxxxxxxxxxxx  my_db_name < backsql_create.sql

IV. Hack the basic config files

a. slapd.conf

Basically I’m starting from the slapd.conf in the rdbms_depend/mysql sample (see above), but folding in some RedHatese file locations from the distributed slapd.conf.

I define an adminstrative user with the rootdn and rootpw directives. Use slappasswd to generate the hashed password:

$ slappasswd -h {crypt}

and type in the password. It will spit out the string you need, which is prefixed by the algorithm in curly braces.

# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
 
pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args
# Timeout in seconds, 0 = never
idletimeout     30
threads         32
# Debuging level, 0 = none
loglevel        32
 
# THIS IS IMPORTANT-- without it you will get "<database> failed init (sql)!"
# Load dynamic backend modules:
modulepath    /usr/lib/openldap
# modules available in openldap-servers-sql RPM package:
moduleload back_sql.la
 
 
#######################################################################
# SQL Database Definitions
#######################################################################
 
database        sql
suffix          "ou=Junk,ou=AK,DC=mycompany,DC=com"
rootdn          "cn=root,ou=Users,ou=Junk,ou=AK,DC=,mycompany,DC=com"
rootpw          {CRYPT}xxxxxxxxxxxx
 
#  The name of the ODBC datasource (from odbc.ini,
#     not necessarily the database instance) to use.
dbname          my_database
dbuser          my_database_user
dbpasswd        xxxxxxxxxxxxxxxx
 
# this is important because my simple view for the ldap_entries table
# has no 'organization' object.  See `man slapd-sql`.
baseObject
 
subtree_cond    "ldap_entries.dn LIKE CONCAT('%',?)"
insentry_stmt   "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)"
has_ldapinfo_dn_ru      no
 
 
#######################################################################
# Access Control
#    see http://www.openldap.org/doc/admin24/access-control.html
#    and `man slapd.access`
#######################################################################
 
# Here we define who can see which parts of the directory
 
# Hide the password attribute (except for the root user of course) but
#   allow authentication against it
access to attrs=userPassword
        by anonymous auth
        by * none
 
# don't allow anonymous access
# allow authenticated users to see their own entry
access to *
        by self read
        by * none

I started without the Access Control section and added it after I had things basically working.

b. ODBC config files

In my case they are in /etc/odbc.ini and /etc/odbcinst.ini already existed and just needed a MySQL section added to odbcinst.ini and a section for this particular database in odbc.ini, but I had to get the paths right for Red Hat. See the MySQL section of step 2 of the samples README document

/etc/odbcinst.ini:

# Driver from the MyODBC package
# Setup from the unixODBC package
[MySQL]
Description     = ODBC for MySQL
Driver          = /usr/lib/libmyodbc3.so  # note, filename includes a 3, differs from docs
Setup           = /usr/lib/libodbcmyS.so
FileUsage       = 1

/etc/odbc.ini

[my_database]
Description         = my database
Driver              = MySQL
Trace               = No
Database            = my_db_name
Servername          = localhost
UserName            = my_database_user
Password            = xxxxxxxxxxxxxxxxx
ReadOnly            = No
RowVersioning       = No
ShowSystemTables    = No
ShowOidColumn       = No
FakeOidIndex        = No
ConnSettings        =
SOCKET              = /var/lib/mysql/mysql.sock

(OK, here’s where I dinked with the example database and read lots of examples and stuff, but hopefully you can skip that because of this excellent documentation )

V. Create and populate your user and group tables

These are my basic tables of users and groups:

CREATE TABLE my_user (
  id int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  username varchar(45) NOT NULL,
  password varchar(45) NOT NULL,
  first_name varchar(45) DEFAULT NULL,
  last_name varchar(45) DEFAULT NULL,
  PRIMARY KEY  (id,username)
);
 
CREATE TABLE my_group (
  id int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `name` varchar(45) NOT NULL,
  PRIMARY KEY  (id)
);
 
CREATE TABLE my_group_member (
  -- unique id isn't necessary but easier for symfony
  id int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  my_user_id int(10) UNSIGNED NOT NULL,
  my_group_id varchar(45) NOT NULL,
  PRIMARY KEY  (id),
  UNIQUE KEY uniquepair (my_user_id,my_group_id)
);

You’ll need to populate the tables with a user or two and at least one group, of course.

VI. Insert the special configuration rows

I entered these data sets using the MySQL Administrator GUI. The most helpful explanation was in the “METAINFORMATION USED” section of the slapd-sql man page.

Basically, the ldap_* tables show the SQL backend how to map the database tables onto LDAP objects. This is a nice reference to the common LDAP object schemas. That’s important because you can only map your database fields to fields in the schema for the objectClass you’re using (unless you want to start making your own schema, which is beyond my scope here). In my case I’m using inetOrgPerson, which inherits from organizationalPerson, which inherits from Person, and for groups, groupOfUniqueNames.

The ldap_entry_objclasses table needs one row for each objectClass we’re using:

The ldap_oc_mappings table also has a row for each objectClass, and it shows the sql backend how to find objects corresponding to those object classes.

The ldap_attr_mappings table is the most complex part. Basically you’re showing the sql backend how to build queries that map the database columns onto LDAP attributes.

Create a view for the DNs in ldap_entries

I’m going to use the username field in my DN instead of the common name (CN) in most examples, because it’s more guaranteed to be unique, and it is apparently OK to do so.

DROP TABLE ldap_entries;
 
CREATE VIEW ldap_entries AS
  SELECT 
    -- differentiate id spaces here 
    (100000 + my_user.id) AS id,
 
    -- calculate a DN for each user
    ucase(concat(
     'uid=', my_user.username, 
     ',ou=Users,ou=Junk,ou=AK,DC=mycompany,DC=com'
    )) AS dn, 
 
    -- the id of the inetOrgUser objectClass in ldap_entry_objclasses
    1 AS oc_map_id,    
 
    -- zero for every row 
    -- (see baseObject in the `slapd-sql` man page)
    0 AS parent,
 
    -- the real id in the user table
    my_user.id AS keyval 
 
  FROM
    my_user 
 
UNION 
 
  SELECT 
    -- a different id space
    (200000 + my_group.id) AS id,
 
    -- calculate a DN for each object in our group table 
    ucase(concat(
    'cn=',my_group.name,
     ',ou=Users,ou=Junk,ou=AK,DC=mycompany,DC=com'
    )) AS dn
 
    -- the id of groupOfUniqueNames in ldap_entry_objclasses
    2 AS  oc_map_id,
 
    -- like above
    0 AS parent,
    my_group.id AS id 
 
  FROM 
    my_group

VII. Test and stuff

Launch the Slap daemon

It’s nice to launch slapd in debug mode in one terminal. This is pretty verbose and will hopefully tell you if you’ve got something wrong in your mapping tables or anything:

sudo /usr/sbin/slapd -d 5

Test connectivity and data with an LDAP client

Hint: it would help to LEARN HOW TO USE ldapsearch correctly.

Connect anonymously and spit out all the LDAP data (if ACL allows it– by slapd.conf above allows anonymous connections but won’t show any of the data):

ldapsearch -x -s sub -b "ou=Junk,ou=AK,DC=mycompany,DC=com" "(objectClass=*)"

Connect as root (the special account defined in slapd.conf) and show all the data in the directory:

ldapsearch -x -D uid=root,ou=USERS,OU=JUNK,OU=AK,DC=MYCOMPANY,DC=COM -w xxxxxxxxx -s sub -b "ou=Junk,ou=AK,DC=mycompany,DC=com" "(objectClass=*)"

Here’s an example of what it shows me:

# extended LDIF
#
# LDAPv3
# base <ou=Junk,ou=AK,DC=mycompany,DC=com> with scope subtree
# filter: (objectClass=*)
# requesting: ALL
#
 
# Junk, AK, mycompany.com
dn: ou=Junk,ou=AK,dc=mycompany,dc=com
objectClass: extensibleObject
description: builtin baseObject for back-sql
description: all entries mapped in the "ldap_entries" table
description: must have "0" in the "parent" column
ou: Junk
 
# TESTUSER, USERS, JUNK, AK, MYCOMPANY.COM
dn: uid=TESTUSER,ou=USERS,OU=JUNK,OU=AK,DC=MYCOMPANY,DC=COM
objectClass: inetOrgPerson
cn: test user
ou: guest
sn: user
uid: testuser
givenName: test
userPassword:: dGVzdHBhc3M=
 
# 1234567890, USERS, JUNK, AK, MYCOMPANY.COM
dn: uid=1234567890,ou=USERS,ou=JUNK,ou=AK,DC=MYCOMPANY,DC=COM
objectClass: inetOrgPerson
cn: test2 user2
ou: guest
sn: user2
uid: 1234567890
givenName: test2
userPassword:: MTIzNDU2Nzg5MA==
 
...
 
# VALIDUSERS, GROUPS, JUNK, AK, MYCOMPANY.COM
dn: cn=VALIDUSERS,ou=GROUPS,ou=JUNK,ou=AK,DC=MYCOMPANY,DC=COM
objectClass: groupOfUniqueNames
cn: validUsers
uniqueMember: uid=1234567890,ou=USERS,OU=JUNK,OU=AK,DC=MYCOMPANY,DC=COM
...
uniqueMember: uid=TESTUSER,ou=USERS,OU=JUNK,OU=AK,DC=MYCOMPANY,DC=COM
 
# search result
search: 2
result: 0 Success
 
# numResponses: 8
# numEntries: 7

Connect as a valid user and ask for everything, but according to my ACLs the user can only see itself:

ldapsearch -x -D uid=TESTUSER,ou=USERS,OU=JUNK,OU=AK,DC=MYCOMPANY,DC=COM -w testpass -s sub -b "ou=Junk,ou=AK,DC=mycompany,DC=com" "(objectClass=*)"

Additional Considerations

chkconfig is the Red Hat tool for managing init scripts– here’s how to make sure the slapd starts at boot time.

$ sudo chkconfig --add ldap
$ sudo chkconfig ldap on

Ah, Mr. Flat Mountain reminds,

9) Ports for the Firewall LDAP runs on port 389/tcp by default and LDAP over SSL is 636/tcp.

Securing communication between the LDAP client and OpenLDAP server with SSL/TLS is beyond my scope here, but it seems to be much better documented.

Good luck!

The Problem

Sometimes a parameter in a GET string contains slashes, which are interpreted as file path delimeters by Apache and/or parameter name/value separators by Symfony.

So this URL works: http://myapp/employee/bytitle/title/System+Engineer

But this one returns a 404 (Page Not Found) error: http://myapp/employee/bytitle/title/Programmer/analyst

Wrong solution

Double-escaping the slash into ‘%252F’ (e.g. urlencode(str_replace('/', "%2f", $this->getTitle()))) works if the URL isn’t rewritten by Apache.

This threw me because my URLs would work if they included the name of the controller file, frontend_dev.php or backend.php or even index.php like http://myapp/index.php/employee/bytitle/title/Programmer%252Fanalyst,

but they wouldn’t work through the implicit, controllerless URLs like http://myapp/employee/bytitle/title/Programmer%252Fanalyst

Right solution

Both

1. Turn on the AllowEncodedSlashes Apache directive by adding this line to your server-wide section or the appropriate VirtualHost:

    AllowEncodedSlashes On

   AND,
2. DON’T double-escape the parameter as above, but do use urlencode() or equivalent to change slashes to %2F, eg. in the view layer,

   <?php echo link_to(
       $employee->getTitle(),
       '/employee/bytitle?title='.
       urlencode($employee->getTitle())
   );  ?>

Additional Complication

Browsers may treat the encoded slash in the URL differently.

IE 7, 8 and Firefox 3, and Safari 3.2.1 on Windows display the URL in the address bar with the %2F intact, as you’d expect.

In Google Chrome 1.0.154.43, the links work but the address bar displays a slash instead of the encoded %2F, so if you hit the “Go” button you get a 404 error. Weird. Bug submitted!

This is a symfony 1.0 project, but I think everything applies equally to 1.1, except the command syntax has changed from propel-load-data to propel:load-data

In this case, the application helps nurses collect and analyze data about how they’re administering intravenous therapies to their patients. At first they wanted plain text lists of the IV drugs and fluids, but in order to filter based on them, we needed to change them to discreet fields. In the View, it means changing a couple of fields from plain text to arrays of checkboxes. In the Model, it means adding separate tables, and a “through class” associating the therapy with the new class.

Changing the database schema and the generated object model

The original design had only two classes/tables: Patients, each having one or more Therapies. Now, each Therapy can have 0 or more Drugs and Fluids.

First I added additional tables to my schema.yml, using the column naming conventions so symfony will get the table relationships right:

  drug:
    id:
    name:             varchar(255)
    created_at:
    updated_at:
 
  fluid:
    id:
    name:             varchar(255)
    created_at:
    updated_at:
 
  therapy_drug:
    id:
    therapy_id:
    drug_id:
 
  therapy_fluid:
    id:
    therapy_id:
    fluid_id:

Propel will generate the table creation SQL:

./symfony propel-build-sql

But I don’t want to obliterate my existing data, so I cut the 4 CREATE TABLE statements for my 4 new tables out of data/sql/lib.model.schema.sql and put it in a file named data/sql/create_drugs_fluids.sql (and added it to Subversion with svn add)

Now I can feed that file to MySQL

mysql -uroot iv_log < data/sql/create_drugs_fluids.sql

Next, I wrote a fixture file in YAML.

Then I have to clear the cache and rebuild the model in order to populate my new tables from the fixture, but I have all the objects ready to go!

./symfony cc
./symfony propel-build-model
./symfony propel-load-data frontend

Nicer accessors in the Model

Next I’ll do some work in the model layer to make things more convenient and logical for accessing the Drug and Fluid objects attached to each Therapy.

Add accessors to the Therapy model that return the array of through-class objects (TherapyDrug and TherapyFluid), for example in lib/model/Therapy.php:

  public function getDrugs($criteria = null, $con = null)
  {
    return $this->getTherapyDrugsJoinDrug($criteria, $con);
  }

(and a similar getFluids method)

Make a list of through-class objects display like a list of the associated thing. In lib/model/TherapyDrug.php:

  public function __toString ()
  {
    $s = $this->getDrug();
      return $s->__toString();   # i've had problems not doing this explicitly
  }

(and the same for TherapyFluid.php)

Now make sure the attached objects have a good __toString() method. In lib/model/Drug.php

/**
 * Method __toString
 *
 *  @return    string   the drug name
 * @package lib.model
*/
  public function __toString ()
  {
    return $this->getName();
  }

Changing the Admin Generator GUI

Now my database and model are all set, I need to make the new tables/objects available in the GUI. I am using the Admin Generator for all the parts of the application.

First, I want them to be able to edit the list of drugs and fluids, so I build admin modules:

./symfony propel-init-admin frontend drug Drug
./symfony propel-init-admin frontend fluid Fluid

But I don’t want users to delete these values and leave orphaned rows in the related tables, or delete all related Therapy objects, so I’ll remove the ‘delete’ ability in each new module’s config/generator.yml, for example, in apps/frontend/modules/drug/config/generator.yml,

generator:
  class:              sfPropelAdminGenerator
  param:
    model_class:      Drug
    theme:            default
    list:
      display:
        - =name
      object_actions:
         _edit:          ~
    edit:
      display:
        - name
      actions:
        _save:
          params:  confirm=This will affect all existing log records that use this drug, OK?
        _list:  -

OK, now to add it to the Therapy object’s admin module. I’m going to need it in three places:

1. The list view
2. The edit form
3. The filter list on the list view

List view

In the list view, I unfortunately can’t just tell it to display the “drug” or “therapy_drug” column, because the Admin generator will print the results as “Array”. So I make a partial to display the list of related objects. I’m going to use the same partial for list, edit and filter views using the $type variable the admin generator provides to tell them apart.

I define my partial in apps/frontend/modules/therapy/templates/_drugs.php

<!--  begin _drugs partial for type '<?php echo $type ?>' -->
<?php switch ($type):  ?>
<?php case 'list': 
 
echo implode(', ', $therapy->getDrugs());
 
?>
<?php break; case 'edit':
 
   // this is handled by the admin generator
 
  ?>
<?php break; case 'filter':
   // coming in a minute
 ?>
<?php break; endswitch;  ?>
<!--  end _drugs partial -->

Now I just have to add the partials to the list of fields that display in list view, in

    list:
      fields:
        # ...
        - _drugs
        - _fluids

And hooray! My list of Therapy objects now displays their associated Drug and Fluid objects: 

Edit view

The edit view doesn’t really need the partial at this point, we can get a list of checkboxes in the edit form just by hacking the correct stuff into apps/frontend/modules/therapy/config/generator.yml:

  edit:
    display:
# ...
          - drug
          - fluid
 
    fields:
# ...
        drug:
          name:  Drug(s)
          type:  admin_check_list
          params:  through_class=TherapyDrug
        fluid:
          name:  Fluid(s)
          type:  admin_check_list
          params:  through_class=TherapyFluid

I had to make a little tweak to the .sf_admin_checklist li style in web/css/main.css, but now I have a nice set of working checkboxen!

Filter view

This will take two stages. First I put this sort of thing in my _drugs.php and _fluids.php partials:

<?php break; case 'filter': 
 
$drugs = DrugPeer::doSelect(new Criteria); // get the list of all the possible drugs
echo select_tag('filters[drug]', 
  		  objects_for_select(
				   $drugs, 'getId', 'getName', 
				   isset($filters['drug']) ? 
				     $filters['drug'] : '',
				   'include_blank=true') 
		);
 
 ?>

and tell the Admin Generator to use the partials, back in generator.yml:

    list:
      # ...
      filters:
        # ...
        - _drugs
        - _fluids

Now I have a nice widget in my filters box, but it doesn’t do anything quite yet:

To get it working I’ll need to help out the filter action, by extending the addFiltersCriteria action generated by the admin generator. I will edit my copy in apps/frontend/modules/therapy/actions/actions.class.php:

  protected function addFiltersCriteria($c)
  {
 
    if (isset($this->filters['drug']) && $this->filters['drug'] != '') {
      $c->addJoin( TherapyPeer::ID, TherapyDrugPeer::THERAPY_ID, Criteria::LEFT_JOIN);
      $c->add(TherapyDrugPeer::DRUG_ID, $this->filters['drug']);
    }
 
    if (isset($this->filters['fluid']) && $this->filters['fluid'] != '') {
      $c->addJoin( TherapyPeer::ID, TherapyFluidPeer::THERAPY_ID, Criteria::LEFT_JOIN);
      $c->add(TherapyFluidPeer::FLUID_ID, $this->filters['fluid']);
    }
 
    return parent::addFiltersCriteria($c);
  }

Now the action will add additional constraining filter criteria before displaying the list of Therapy objects, if the filters have been set. That will let the user search for only records with a particular combination of values, for example.

Whew, that got a little bit involved but I’m sure it will be easier next time.

The big breakthrough for me learning how to work with the admin generator was when I realized that it generates all its files in the cache directory, so you can look in the cache at how it’s doing everything, and override as necessary with partials and actions when you run past what you can do with generator.yml.

svn propset svn:keywords 'Id Rev URL HeadUrl' \
`find apps/ config/ doc/ lib/ web data/ test/ \
-name '*.php' -or -name '*.yml' -or -name '*.css' -or -name '*.sql'`

This tells Subversion to go into those types of files and update the $Id$ and other keyword tags.

(Note, I’ve been fooled before by not noticing the keywords are CASE-SENSITIVE. If you set them to ‘id rev url headURL’ they will NOT work!)

It works with Cygwin, if you’re stuck in Windowsland like I am for local development.

The first part of the upgrade went pretty smoothly, but my project broke due to the sfGuardPlugin. There weren’t any details about plugins in the UPGRADE doc, and removing and reinstalling it didn’t work for me.

However, this week, with the help of some friendly symfony forum users, this procedure finally worked for me:

svn rm plugins/sfGuardPlugin
svn ci plugins/sfGuardPlugin -m 'removed old version of sfGuardPlugin'
rm -rf plugins/sfGuardPlugin plugins/.channels plugins/.depdb plugins/.depdblock plugins/.filemap plugins/.lock plugins/.registry/
rm -rf cache/.pear
./symfony plugin:install sfGuardPlugin
svn add plugins/sfGuardPlugin/

my successful plugin installation looked like this:

$  ./symfony plugin:install sfGuardPlugin
>> plugin    installing plugin "sfGuardPlugin"
>> sfPearFrontendPlugin Attempting to discover channel "pear.symfony-project.com"...
>> sfPearFrontendPlugin downloading channel.xml ...
>> sfPearFrontendPlugin Starting to download channel.xml (663 bytes)
>> sfPearFrontendPlugin .
>> sfPearFrontendPlugin ...done: 663 bytes
>> sfPearFrontendPlugin Auto-discovered channel "pear.symfony-project.com", alias
>> sfPearFrontendPlugin "symfony", adding to registry
>> sfPearFrontendPlugin Attempting to discover channel
>> sfPearFrontendPlugin "plugins.symfony-project.org"...
>> sfPearFrontendPlugin downloading channel.xml ...
>> sfPearFrontendPlugin Starting to download channel.xml (639 bytes)
>> sfPearFrontendPlugin ...done: 639 bytes
>> sfPearFrontendPlugin Auto-discovered channel "plugins.symfony-project.org", alias
>> sfPearFrontendPlugin "symfony-plugins", adding to registry
>> sfPearFrontendPlugin downloading sfGuardPlugin-2.2.0.tgz ...
>> sfPearFrontendPlugin Starting to download sfGuardPlugin-2.2.0.tgz (18,589 bytes)
>> sfPearFrontendPlugin ...done: 18,589 bytes
>> sfPearFrontendPlugin Failed to download symfony/symfony (version >= 1.1.0, version
>> sfPearFrontendPlugin <= 1.2.0, excluded versions: 1.2.0), latest release is version
>> sfPearFrontendPlugin 1.1.1, stability "stable", use
>> sfPearFrontendPlugin "channel://pear.symfony-project.com/symfony-1.1.1" to install
>> sfSymfonyPluginManager Installation successful for plugin "sfGuardPlugin"

Then I did the first couple of steps from the install again to get it working:

$ symfony propel:build-model
$ symfony propel:build-sql
$ symfony cc

But grrr… my customized authentication and signin forms are hosing it up. Time to learn more about the new release I guess.

Maybe this will help other developers cook up Intranet apps that rock using symfony.

I have been able to rapidly develop some things that users really like with symfony, so I appreciate this chance to give back to the project.  Also, I’m the only one in my organization doing this sort of thing, so I hope I’ll be able to get some good feedback and contributions from others.