| In this section we describe the steps taken to put Netscape's internal directory service into production. Product Choice Netscape is somewhat unique in that it is a leading developer of directory technology. Netscape's products include a high-performance directory server (Netscape Directory Server) and client software development kits (SDKs). Furthermore, all of the products in Netscape's suite of server software are directory-enabled . Because of cost, performance, and support issues, and because Netscape's developers knew that using their own products would help find bugs and prove the robustness of software they planned to sell to others, Netscape chose to deploy its own products. Piloting The pilot phase of the directory deployment was rather informal. The first directory pilot was conducted by the software engineers working on the 1.0 version of Netscape Directory Server, even before the software was officially released as a product. The developers created a directory that held information about employees (including telephone numbers , office locations, and electronic mail addresses), and they publicized the availability of the directory. The engineers also created an HTML-based interface that allowed employees to search for entries and update their own directory entries. At roughly the same time, the Netscape client product development team was adding LDAP capabilities to a prerelease version of the Netscape address book. The presence of the pilot directory allowed these developers to distribute prerelease copies of the Netscape client software to employees and obtain valuable feedback on the design and usability of the address book user interface. 20/20 Hindsight: Enabling Schema Checking When the initial pilot phase began , not much thought had been put into analyzing schema requirements. To make it easier to add new attributes and object classes, schema checking was disabled on the master directory server (which allowed any attribute with any name to be added to any entry in the directory). The developers running the pilot directory found the lack of schema checking convenient because it allowed them to begin adding new attributes and object classes to the entries in the directory without modifying the schema configuration, assigning OIDs, or restarting the server. (Recent versions of the Netscape Directory Server no longer require a server restart in order to add new schemas.) Unfortunately, disabling schema checking also allowed inconsistencies to creep into the directory data. Because developers in other groups were also using the pilot directory to become familiar with LDAP, some unknown and misspelled attribute types were introduced into the data. Although these inconsistencies weren't such a serious problem in the pilot phase, they became troublesome when the pilot data was imported into the production service in which schema checking was enabled. The pilot data required a rather extensive cleanup before it could be imported. The pilot data could have been discarded; however, many employees had come to depend on the data stored in the pilot server, so the developers decided to retain as much data as possible. In retrospect, to avoid this problem it would have been better to enable schema checking even during the early stages of the pilot. | After initial deployment of the directory, several other pilots focused on new directory-enabled applications that were being developed. One such application was a mailing list manager application, which replaced an older application that used proprietary databases to manage internal and external mailing lists. These lists were migrated into the directory, and a new, HTML-based management interface was developed, piloted, and deployed. Putting Your Directory Service into Production The production rollout of the directory server coincided with the rollout of Netscape Messaging Server. These steps were followed: -
The server hardware was purchased and installed. The directory server and messaging server were both installed on a single host, so memory and disk space were sized appropriately. Hardware accelerator cards were installed to improve performance during the servicing of LDAP connections made over SSL. -
Network ports (100BaseT Ethernet) were installed, and network adapters were installed in the hosts . -
Backup procedures were developed for the messaging server. Because the directory that resides on the messaging server host is a replica and therefore can be recovered from the master server, directory data on the replica is not backed up. The directory server configuration files are backed up. -
An initial test was performed to ensure that the messaging server was able to support access via the Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) and could receive electronic mail via the Simple Mail Transfer Protocol (SMTP). This test also verified that the messaging server was able to retrieve directory data. -
User accounts were moved from the existing, non-directory-enabled messaging server to the new servers. The service was then in full production. |
