1. Sonoma StateWhite Pages Implementation Barry Blackburn Andru Luvisi Brian Biggs

2. Functional Objectives • Low maintenance (automate when possible) • Allow hiding and alternate information (receptionist phone number or email address) • Correctly handle multiple jobs and phone numbers • Web based interface • LDAP based interface for email clients

3. Data To Track • cn, sn, givenName (Name) • title • telephoneNumber • ou (Department) • buildingName • roomNumber • mail (Email Address) • labeledURI

4. Challenges • No authority for office location • Unreliable Job Title information in CMS • Difficult to match phone records • Deciding which department to display • Order of values in a multi-valued attribute in LDAP is unreliable

5. Solutions • Broke White Pages information out into a separate branch of the DIT • Multiple jobs? Multiple White Pages objects. • Each White Pages entry contains a RegID indicating the person it belongs to • People maintain their own information via a web page (department is selected from drop-down list) • The helpdesk can edit anyone's information • Periodic reminders sent out via email

6. Directory Information Tree o=sonoma,o=edu ou=wp ou=people ssuWPUniqueID=2805 sonomaEduPersonRegId=sonaaaafxm telephoneNumber=... email=... ... uid=luvisi sonomaEduPersonRegId=sonaaaafxm ...

7. Custom Development • CGI for searching directory • CGI for users to maintain their information • Script to email out reminders • Auto-populate name and email for employees with no existing entries (to enable email client lookups)

8. Extra Information Needed • ssuWPDisplay (To show or not to show?) • ssuWPUniqueID (Identify WP entry) • sonomaEduPersonRegId (To link back to authentication object) • sonomaEduPersonDeptId (to auto-update "ou" when a department name changes)

9. PDF Output • Perl script generates PostScript • ps2pdf creates PDF version • PDF placed on web site for download • Same process used for both: • "At A Glance" (Just name and phone number) • Full White Pages

10. Current Status It Works!