From: Deke Kassabian Cleaning out my Pobox account, I found this document from March 4, 1996. The writing style enough like mine that I think I'm the author, though it might also be a product of some collaboration, most likely with Mark Levinson. I'm guessing the audience was George McKenna and Dan Updegrove. Enjoy for hysterical raisins. There are some major laugh lines in there, whether I meant them that way or not. :) ^Deke ----- What is Assignments? The University of Pennsylvania "Assignments" program and database are used to allow for a distributed-responsibility record keeping mechanism for network connected devices. Information that allows for the automatic creation of up-to-date DNS zone data for upenn.edu, as well as information on the physical location and responsible person for the devices is kept in the database. Additionally, billing for PennNet connections takes place in part based on the contents of this database. What is the assignments machine? The host on which the database and associated programs are used is a computer known as asgs.dccs.upenn.edu or assignments.dccs.upenn.edu. It is a DecStation 5000/200 with 40Mb of RAM, running Digital Ultrix 4.4. This machine is the primary campus nameserver for upenn.edu. Other nameservers on campus which respond to DNS lookup requests, notably noc1.dccs.upenn.edu [128.91.2.13] and noc2.dccs.upenn.edu [128.91.254.4], get their zone transfers from asgs.upenn.edu. In fact, asgs.dccs.upenn.edu is the only one of our 4 nameservers which is configured to allow for zone transfers. The other three are intended only for responding to DNS name and address resolution requests. What needs to change? The Assignments program is several years old and has some implicit assumptions which may no longer be valid. Its user interface is also in need of updating. These factors alone were enough to prompt the previous DCCS Network Engineering group to place a rework of the Assignments program on their project schedule. Unfortunately, a more pressing reason has arisen. In the rollover of staff, systems, and backup tapes, the most current versions of the Assignments program source code have been completely lost. Only older versions of the source code still exist. (1) Disaster planning a) loss of the assignments platform b) loss of the assignments database (2) In the short term a) move platform to machine room b) research potential options (1) rewrite from scratch (2) use a PD replacement (see list at bottom) (3) use a commercial replacement (see list at bottom) (4) rewrite using an existing system as a base (5) abandon practice and revert to simple DNS data management (3) In the longer term (assuming any decision other than 2b5) a) survey user community to understand requirements b) develop software solution c) decide on, acquire and configure new hardware platform Disaster Planning: Loss of the Platform ------------------------------------------- A complete failure of the assignments.dccs.upenn.edu platform while the platform is still in service would have two main implications. (1) the campus nameserver data would eventually become stale and the primary nameserver from which they would need to retrieve the data would be unavailable. (2) users would lose the ability to remotely and automatically make DNS updates. In order to address (1) we would need to designate one of the other nameservers as the primary and then reconfigure the other nameservers to get their data from the new primary. In order to address (2) we would need to either re-create the assignments service on a new hardware platform or we would need to put a mechanism in place which would allow for assignments users to get DNS information to us so that we could manually make changes in the nameserver database. The former is obviously more desirable. Todd Seeleman has been able to take one of the nightly backups of the assignments machine and recreate the service on another DecStation. Stan Valciukas verifies that the replacement machine appears to operate correctly. We can plan to go to this option in an emergency to restore the assignments service. Disaster Planning: Loss of the Database ------------------------------------------- Loss of the assignments database, through database corruption for example, would require restoration from the most recent data backup. We will likely have between 10 and 14 days worth of backups of the assignments machine. In this case we would probably attempt a restore from the most recent backup first and then try to verify correct operation. If the corruption has affected the integrity of that backup, we could then move back through the backup set one day at a time until a valid backup was found and correct operation was verified. Short Term Goals: Moving the Platform ------------------------------------------- The assignments machine is currently sitting in the Engineering lab without conditioned power nor UPS backup. The lab is not reliably climate controlled. It is in our best interests to get the machine into a more controlled environment. The UMIS machine room would be among the best options. During the time when the platform is being moved, it is necessary to have a machine prepared or even running as an assignments replacement. If for any reason the assignments machine fails to come up after the move, or if the move takes longer than expected, we want to be sure that the service itself is not lost. Todd Seeleman's work in recreating the service on another DecStation (see "Disaster Planning: Loss of the Platform" above) was important to prepare for the move of the platform as well. Short Term Goals: Researching Options ------------------------------------------- Other than leaving it as it now is, there are 5 basic approaches for the future of the assignments service. (1) rewrite the system from scratch (2) use a Public Domain replacement (3) use a commercial replacement (4) rewrite the system using an existing system as a base (5) abandon the practice and revert to simple DNS data management We have begun to collect information on systems that fit in category (2) and (3). We expect that one of the Engineering programmers will take this document and the collected information and begin a more serious effort to research and understand the options sometime during the spring of 1996. Long Term: Understanding the Requirements ------------------------------------------- The assignments user community as well as the DCCS staff who rely upon assignments must provide a good deal of input into the process so that we can address the issues appropriately. Direct interviews seems like one of the best ways to achieve this. Additionally, we probably want to carefully consider what additional functionality we'd like in the assignments program. As concepts like Dynamic DNS develop into real protocols, for example, we'd like to make sure that our Assignments design doesn't preclude our use of the protocol. Long Term: Developing a Software Solution ------------------------------------------- [Based on results of the "Short Term Goals: Researching Options" and "Long Term: Understanding the Requirements" efforts.] Long Term: Developing the Hardware Platform ------------------------------------------- DCCS deploys services almost exclusively on Digital Alpha hardware platforms. It seems natural, therefore, that the assignments machine will run on an Alpha, making the administration of the platform by the current systems administration group that much simpler. The question of whether it needs to be a dedicated platform, where just the assignments service and nothing else runs on that platform, has not yet been addressed. Our assessment of the resources required by the eventual finished service and its expected use, as well as our ongoing experiences with a variety of services on a variety of different configurations within the Alpha line, will help us to make an informed decision when the time comes.