STUMP and Year 2000 Many computer systems store and manipulate date information. Many of these systems were designed without the consideration of a date change around the new year of Year 2000. It is expected that many systems, especially the systems that store or print the "year" part of dates as two digits, will not handle Year 2000 properly. They might treat it as year 1900 and fail to process data correctly. This problem is referred to as the Year 2000 (Y2K) problem. In fact, one of STUMP users -- comp.software.year-2000.tech -- is a newsgroup dedicated to discussions of technical issues related to Y2K. This document attempts to assess relevance of Y2K problem to STUMP users, as well as suggests steps and procedures to identify and overcome these problems. This document is of particular interest to the moderator of alt.toys.transformers.classical.moderated, as well as anyone else who runs STUMP bot from a Unix account at Panix.com. They all have an identifiable y2K problem and their bot will NOT work right beyond y2k. CONTENTS 1. Potential Sources of Y2K Problems 1.1. STUMP source code 1.2. Auxiliary Programs used by STUMP 1.3. Host OS and System Software 1.4. Internet infrastructure 1.5. General infrastructure 2. Preparation 2.1. Checking components 2.2. Assessing likelihood of problems 2.3. Providing backup 2.4. Communications with readers 3. Getting Help 3.1. Use internal resources first 3.2. Identify problems 3.3. Ask appropriate person @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1. Potential Sources of Y2K Problems There are several sources of possible problems. For the most part, failure of even one component out of the ones outlined below means a likely outage for your moderation bot. What this means is that even if the probability of failures of individual layers (components) of the moderation system is small, the probability of the entire system failure is substantially higher. 1.1. STUMP source code When I was writing STUMP in 1996, and ever since, I kept in mind that it will be used beyond the Year 2000. There is no place in the STUMP code that does anything to dates at all. I have reviewed the STUMP code and have not found any potential trouble spots. However, at this point, I have not run any tests where the date on the computer system was set to a date close to y2k. Perhaps one of STUMP users could try this and see. Caveat: even if STUMP works fine and messages are approved, you are not likely to see them in USENET because USENET news servers reject messages with dates from the future. 1.2. Auxiliary Programs used by STUMP STUMP itself uses a number of auxiliary programs, such as: PGPMoose PGP procmail and formail perl PGP and PGPMoose have been reported to be y2k compliant. (PGPMoose has NOT been really tested, as of Nov 1998). STUMP requires PGP 2.6.3. Procmail and formail are not likely to have problems. I am somewhat wary of assurances coming from the Perl community that Perl is y2k-compliant. That is not because they are crooks or liars, but because perl is such an enormously complicated thing, written by so many people, that any systematic verification of y2k compliance is nearly impossible. However, extensive y2k wance checking has been done with perl. STUMP itself does not use perl5 modules. The binary version of WebSTUMP does use modules, however (MIME::Tools and Convert::UU), and I am not certain about their y2k compliance. 1.3. Host OS and System Software Host OS and OS Software includes the computer, the operating system kernel, as well as system utilities. The relevant subsystems are: kernel system utilities -- sh, date, sed, etc mail delivery subsystem inews/rnews (for those who use it) scheduling subsystem (cron) Please consult with your OS vendor and appropriate newsgroups to see if you or your sysadmins need to apply any OS patches to address the y2k problem. It is KNOWN, at this point, that Panix.com has a y2k problem with their "date" program. Panix's "date" outputs only the last two digits of the year. The parts that are more likely to fail are system utilities (see the previous paragraph), mail delivery subsystem, and inews/rnews programs. According to the information posted at www.sendmail.org (see the FAQ), sendmail (a popular mail delivery agent) is Y2K compliant. There is, however, a great number of non-sendmail mail programs, and I am not so sure about those. 1.4. Internet infrastructure Remember that like any moderated group, your newsgroup receives submissions via email. That means that malfunctioning of Internet email is likely to affect your group more than a unmoderated group. Internet infrastructure includes the following: modems/servers/routers mail relays USENET servers USENET bots antispamming tools (including the blackhole DNS database etc) I have a expectation that at least some mail and USENET servers will fail. Be prepared that some connectivity on the Internet will be broken. You may want to create yourself additional email addresses at Yahoo or Hotmail to provide some redundancy. Some of the modems/servers where billing software is integrated with login software, may start refusing you your logins. They might think that you exceeded your time quotas by 100 years! Another danger here is the last two categories of software: USENET bots (spam cancellers, notifiers, etc) and antispam tools such as RBL. It is not impossible that at least some USENET bots will go absolutely nuts and will start spewing messages or cancelling everything in sight. Antispam systems for email: unfortunately, some computer systems make use of centralized servers that judge whether email messages are worthy of receiving. In a typical setup, there is a centralized server that is being run by semi-professional antispammers. Various computers, when receiving or relaying a message, then query the server about the domain (or user) that originated the message. They then may reject the message if the server suggests that the originator is a spammer. The danger of these antispam systems is twofold: first, it is possible that around y2k they will start malfunctioning and recommending to reject all messages. That could cause an internet-wide email blackout. It is also going to be very hard to fix because the very notification about problems becomes impossible. Second, failures of IP connectivity may cause troubles with quick turnaround for queries, thus slowing down email messages. 1.5. General infrastructure Internet and your personal computer/connectivity relies on telephone connections, digital cable, and electric power. If those vital resources are interrupted, naturally your own connectivity will be interrupted. This particular subject is trivial with respect to STUMP-related issues, and can be discussed elsewhere. 2. Preparation I suggest that despite diligent preparation, you should expect plenty of problems. Be prepared to address them as they occur without too much emotional stress for yourself or your users/readers. 2.1. Checking components Verify that the components that I mentioned, as well as anything else you think may be relevant, are in good working order and are y2k compliant. What this verification yields is not the assurance, but hope that they will work. 2.2. Assessing likelihood of problems Assess likelihood of problems with things that are out of your control. Your assessment may be wildly wrong, therefore be very conservative and pessimistic. 2.3. Providing backup Backup all your data!!! I cannot stress this enough. Hundreds of tons of hair were pulled out by many computer users when their hard created data was trashed for various reasons. Don't become a statistic! The best way to save data, in my opinion, is to record it on CD-Recordables and then store those in a safe place. 2.4. Communications with readers Tell your readers in advance that, due to many reasons outside your control, your moderated newsgroup may experience interruptions around y2k. Encourage them to report problems to you. Tell them also that you may not be able to answer all their messages in a timely manner. 3. Getting Help I suspect that STUMP-related problems may not be on top of your list of priorities around y2k. I personally believe that the probability of doomsday scenarios that now abound is quite low, but non-negligible. (my opinion on this is no better than anyone else's). However, I think that most likely, problems with STUMP will be an indication and a consequence of much bigger problems -- problems with email, connectivity, telephone access, electricity, and so on. Those problems have repercussions that are more serious that just a newsgroup malfunctioning. My personal expectation is that most of you will be busy with them. As far as I am concerned, that is good because I expect to either be celebrating, or taking care of my own urgent business. At this moment, I do not plan to "bug out" and hide in the boonies to wait out the Y2K Armageddon, and hope to be around, more or less. So I might be able to answer your questions, but give you no assurances. 3.1. Use internal resources first Before asking for help, try to find out if you can solve the problem by yourself. 3.2. Identify problems Identify which subsystem is responsible for problems; whether messages arrive to proper addresses; which programs fail; and whether they are critical or not. Test these subsystems. Look into ~/Mail/from logfile for indications of any problems. Learn to troubleshoot them in advance. 3.3. Ask appropriate person Ask help from the persons who have control over things that are responsible for your problems. When asking a question, give as much problem identification as possible.