(Message inbox:4907) Return-Path: csr@calvin.dgbt.doc.ca Return-Path: Received: from calvin.dgbt.doc.ca by blacks.jpl.nasa.gov (4.1/SMI-4.1) id AA03668; Mon, 5 Oct 92 12:55:57 PDT Received: by calvin.dgbt.doc.ca (4.1/SMI-4.1) id AA00900; Mon, 5 Oct 92 15:57:04 EDT Date: Mon, 5 Oct 92 15:57:04 EDT From: csr@calvin.dgbt.doc.ca (Andrew Patrick) Message-Id: <9210051957.AA00900@calvin.dgbt.doc.ca> In-Reply-To: dank@blacks.jpl.nasa.gov (Daniel R. Kegel) "Horton-2.2, part 0/4" (Aug 1, 8:18pm) Reply-To: csr@calvin.dgbt.doc.ca X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: dank@blacks.jpl.nasa.gov (Daniel R. Kegel) Subject: reviews of horton The reviews are in for your submission "horton". The reviewers uncovered a few problems with the package, and raised a number of issues that you should think about. The detailed reviews are included here and you should look at them carefully. A summary of the things to think about are: - consider installing into src and etc directories - "podunk.edu" doesn't occur in the crontab entry - add a line mentioning where hosts.poll should go - mention "dig" in the README, perhaps include it since it is really dependent on it - mention SunOS finger bug in INSTALL since large routers will have to be excluded - reconsider source routing test in monthly script - have monthly script generate report of hosts that were excluded - fix bug where fingerd returns error message - look at problems of multiple entries for the same user (perhaps look at .forward files) - look at running in a /etc/hosts only environment (i.e., no nameservers) - fix problem with error messages not recognized in monthly script - look at problem with -i option to egrep Please address these problems, and the other things mentioned by the reviewers. Then, send me a new version of horton along with a cover letter that details the changes that you made, and how you addressed these problems. We will then have a look at horton again. Thanks for sending your work to CSR. -------- Subject: horton review 1: unpack worked fine 2: README file is acceptable 3: did not like that install tells me to create the user and to make src and etc directories an then unpack. would like to see the unpack go into src with README and INSTALL at the top level. that way I wouldnt have to move the systems again. 4: Makefile did not specify compiler options. We use gcc need line CC = cc so we can modify. 5: the software has worked well. its only limitation is that it was designed for a network that does not have delegated subdomains. I had to modify a couple of the scripts to get this to work. This limitation was noted in the README and in the comments in the script. So it was not a suprise. 6: the documentation describing additional packages to use was very complete and included ftp site and directory. 7: very impressed with the ability of the scripts to self configure for each system. 8: the software did an excellent job of building a base of email addresses. In addition it pointed out numerous problems in our email system we did not realize were there. AS well as problems in our DNS. I have made some scripts of my own designed to debug a large network to be sure that the DNS and email systems are functioning correctly. 9: recommendation: very good package. only suggested change is item 3. could look at item 8 and add scripts to assist in debugging a mail system. the current scripts are looking for hosts on the network that work. It is also important to know hosts that dont work. 10: I highly recommend this package to anyone attempting to establish a baseline email directory. Be warned, before using this package on a major network, inform all system administrators. Since it can generate a lot of errors and the user name is horton, they may wonder what is up. -------- Subject: review of horton Summary: a new-and-improved whois service Recommendation: Accept with one minor change (see ***) Format: horton arrived as 4 shar files. I'd have prefered uuencoded, as it permits some (rudimentary) check on file integrity, but then it is bigger so you probably want to compress it first... Shar files are ok. They all unpacked fine, and put the files in a reasonable place. The Manifest file was included. [The CSR standard is shar files. -- Mod.] Description and Purpose: The README file was a very well-written description of what horton does, how he does it, where and to who. It also had good security suggestions, mentioning COPS, npasswd and log_tcp. All required sections were present and complete. I find no fault with the README. README. Installation: The INSTALL document was also very well-written, in general, beginning with choosing the configuration, creating the pseudo-user, running the make, followed by minimal testing, to confirm operations. The only faults I found with the installation were very minor. I would have liked to know what horton was going to do with the domain name which I was required to give. It was almost obvious, but I'd have liked to know for sure. Also, in section 5 there was a bit of confusion. The installation doc mentions "... replace podunk.edu with your domain's name...", but "podunk.edu" doesn't occur in *** the crontab entry. The only fault that really needs to be fixed is here also: INSTALL doesn't mention where hosts.poll should be (in ~horton/etc), so I created it in ~horton/src, which was were the installation instructions had left me. Not really difficult to figure out. The rest of the installation went fine, except for my typing problems. There were few conditionals and options and they were clear, except as mentioned above. The Makefile was easy to edit. Everything ran through make properly. The build and install were properly separate. I built it under SUNOS 4.1.2 with no patches. The only kernel modifications were to remove all the devices I didn't have and change the max number of users to 225, to get more processes. Testing: The testing was described in the INSTALL file, and had good descriptions of what was supposed to happen, and how to figure out if something else had happened. Since my fingers run ahead of my brain this was a good thing and permitted me to see where I'd screwed up. horton ran just fine, and, as things were going so well, I made a minor addition to it (see Functionality and Features.) Documentation: It was pretty obvious that the submitter had (gasp) read the submission guidelines and (!gasp!) followed them, without letting them restrict him (!!gasp!!). The addition of a security section was not in the guidelines, but in the context of a program which provides userids was a necessary addition. It's great to read some-one who can write english as well as code. The organization of both the README and INSTALL made the task straight-forward. Functionality and Features: Is it useful? Is a phone-book useful? No, it's necessary. horton, or something like it is a must-have. Since parts of it are in shell scripts, it was relatively easy to modify it to include static data in with the data horton gathers. I used this to include names of users who are only reachable through a gateway; not perfect, but all in one place. I think that this would be a useful (and minor work) addition. Recommendation: Accept with a line mentioning where hosts.poll should go. -------- Subject: horton review Evaluating the Format of the Submission --------------------------------------- This all looks fine. Evaluating the Description and Purpose -------------------------------------- Is there a README file that contains: - the purpose and value of the software (give details here) - the types of systems it is intended for (e.g., BSD only, Unix and DOS, etc.) - any dependencies in the system (e.g., must have perl to run) This thing is really dependent on "dig", as far as I am concerned. That should be mentioned here. Building the Software --------------------- Is there an Installation document explaining how to build the software? Yes, this is done rather well. It is nice to see the hand-holding given in detail, espcially since this involves creating new users. Did the software build on each of the architectures you were able to test? Sun SPARCstation 1+, SunOS 4.1.1. The program builds fine. I did discover one bug with the quickfinger program, but it turns out that it is a problem with the SunOS, not with horton. The problem is that nodes on the network cannot have more than 10 IP addresses, and this is sometimes violated with routers. When quickfinger, and other finger programs, attempt to contact this host they dump core. This bug is known to Sun. quickfinger dumps core when testing router finger also core dumps there! router 86400 IN A 142.92.78.1 router 86400 IN A 142.92.2.2 router 86400 IN A 142.92.3.1 router 86400 IN A 142.92.77.1 router 86400 IN A 142.92.79.1 router 86400 IN A 142.92.80.1 router 86400 IN A 142.92.81.1 router 86400 IN A 142.92.82.1 router 86400 IN A 142.92.83.1 router 86400 IN A 142.92.84.1 router 86400 IN A 142.92.85.1 The workaround is to list the routers in hosts.exclude. This should be mentioned in the docs since I spend quite a while running around finding the source of the problem. Each time it happened, the hourly horton run ended prematurely when the finger command died. This meant that hosts in the list after the routers were not getting polled! Testing the Software -------------------- Did the software run on each of the systems you tested? Did the program perform the functions it was supposed to perform? I found that the rules used by the monthly script for determining which hosts to poll to be too restrictive. Horton runs a test where it attempts to send mail to itself via a candidate host (e.g., @candidate.domain:horton@thishost.domain) and if the test fails then that host is not polled. I found that this test excluded many hosts in my domain that should have been polled, including my master server and DNS domain authority. I know that these systems run valid mail configurations as far as we are concerned. I think the author should re-think this test and, at least, make it optional. The monthly script should produce some kind of summary report of the hosts that it excluded from the polling list. I found myself running diff a lot to find out where certain hosts were being dropped from the list. A report like: host1 - failed finger test host2 - failed source routing test ... would be very nice. One of you Unix gurus also had the following comments: Something for your review ------------------------- 1. A Bug? I have noticed something funny about horton. Right now there are some entries like: in.fingerd:@dcn1.xxxx.xxx.xx d: fork: No more pr Mon Sep 14 1992 in.fingerd:@capella.xxxx.xxx.xx d: fork: No more pr Tue Sep 8 1992 I think that these two systems had run out of process table space at this point. 2. Not well suited to the more modern client/server architecture. Another thing that I see is a lot of repetition. I have 9 addresses in there! I know that horton can "deal" with workstations using a "mailhost" but it does this by having me send mail to the horton administrator and telling them to take a list of client systems off the list. Since there is (more or less) a 1 to 1 correspondence between workstations and users and since I would have to do this for each new system that I bring up I might as well just send the horton admin a list of users from my mailhosts and remove all systems in my domain from it's list of systems to poll. This could be automated with cron and a few scripts and has the added feature of being able to deal with people who don't often or never login (pop/pcmail clients) and people who only have mail aliases (eg. all Banyan users). Horton would work very well in an environment where people have to login via a terminal to read their mail but that is not the case anymore. 3. Too much mail on startup. Horton sent me a heck of a lot of mail whenever it first started up. I think that it sent me two messages from each system that it polled so there were somewhere around 26 messages stacked up for me. Many installations have hundreds more workstations than we have here, those postmasters would get a heck of a pile of mail. Horton should have a large warning about client/server environments. 4. An enhancement? Horton could be smarter about mail forwarding too. Why list an entry for a system if that entry is forwarded to another system? For example I have an entry phil@host1 and I also have an entry phil@host2 With "telnet host2 smtp" I can expand phil and find: vega% telnet host2 smtp Trying 142.92.36.36 ... Connected to host2 Escape character is '^]'. 220 host2 Sendmail 4.1/SMI-4.0 ready at Tue, 22 Sep 92 15:57:32 EDT expn phil 250 Full Name Horton could do this and then list one or the other. The Documentation ----------------- This is just a new version of the whois daemon, or a new way to feed that daemon, so there is no documentation. The info that is mailed to the polled hosts, and the finger information, is OK. Functionality and Features -------------------------- Does the software perform some function that is valuable? Yes, we will be running it on a permanent basis in our domain. Are there obvious features or additions that would improve the package? Dig should be rolled into the package by default. It was a pain to have to realize that I needed it, go and get it, build it, and then keep going with horton. I can't see any domains interested in running horton that are small enough to not want dig. Overall Evaluation ------------------ What is your overall evaluation -- would you recommend it to a friend? Yes. Would you suggest that this submission: - be accepted for posting as is - be accepted after minor revisions (that you have detailed) - be returned to the author with a recommendation to make major changes and re-submit - be rejected It should be accepted after minor changes documented above. Short Summary of Review ----------------------- Horton is a program that can automatically feed a whois daemon. If you always wanted a diretory service for your domain, but did not want to build one, then horton can build it for you. I found horton to be well documented and easy to install (SPARCstation, SunOS 4.1.1). The program is a bit limited in that it will only report users who actually login to your Unix systems, so other LANs reachable via gateways have to be included manually. However, it is a nice way to bootstrap a directory service. -------- Subject: Review: horton Tested horton on a sparc station running SunOs 4.1.2 The packet is in a shar format and the extraction didn't seem to pose any problems. altough the length of the files wasn't the same as indicated in the Manifest. The installation guide is to dependend on the fact that you should organize things the way it was originally done. So is there some suggestion of where you can extract the files but you can only read this after you have extracted them. As the installation seemed to require a src and etc subdirectory these should have been created during the extraction with the sources already in the src subdirectory. There is no general indication in the Installation guide where you have to change things if you put the sources somewhere else as sugessted. When I finally got to the installation itself I received numerous errors about newlines in string constants. It seemed that some long lines were cut in two (probably by a mailer) but the extraction hadn't complained at it. If you follow the guidelines you create a file hosts.poll in ~horton/src. Later you find out it should have been place in ~horton/etc. It would be handy is the manual suggested to check for the use of crontab for the pseudouser. After launching the hourly.sh with cron and not finding the file with the results as suggested I gave up. I had already spent more than two hours on this and only got through a third of the installation guidelines (and not because the compilation took that long) I suggested the submission is returned to the author with the recommendation that he reworks his installation notes. Preferably by reinstalling the package on a totaly unrelated place of where it came from and making notes while he proceeds. -------- Subject: Review: Horton Our system: Sequent Exl 1200, 4 processor boards with 12 i386 CPUs, Dynix 3.0.17.9, running both AT&T and BSD 4.2 environments. I did all the testing in the BSD universe. > Evaluating the Format of the Submission > --------------------------------------- > Was it in the form of a "shar" file, or similar packaging appropriate > for the architecture? shar archive (multi-part) > Did in unpack correctly? > Did it unpack in the places you expected it to? Unpacking went fine > Did it contain a MANIFEST file listing all the parts of the > submission? I didn't check the Manifest, since I didn't have any problems with the archives. > Evaluating the Description and Purpose > -------------------------------------- > Is there a README file that contains: > - the purpose and value of the software (give details here) There's quite a verbose description of the "why"'s and "how"'s. > - the types of systems it is intended for (e.g., BSD only, > Unix and DOS, etc.) The requirements that are listed in the README file are not complete. There are still a lot of hosts that don't want to connect to a name server and rely on a local /etc/hosts file. It's almost impossible to run horton in such environments. > - any dependencies in the system (e.g., must have perl to > run) > - known limitations of the software > - the authors of the software (with e-mail addresses) > - the "patchlevel" of the software (see below) > - any copying or distribution conditions All the above points are mentioned in the README file, I didn't find any obvious errors. > Is there a "patchlevel.h" file (or equivalent) indicating the version > number of the software? The patchlevel is also listed in the README document. > Building the Software > --------------------- > Is there an Installation document explaining how to build the software? > Are the options and conditional parts of the package (e.g., do this for > DOS, this for System V, etc.) clearly documented? Yes, INSTALL gives a step-by-step documentation of what you have to do. Unfortunately, a lot of the steps described here are machine-dependant, if you have some experience with Unix systems, it is no problem to see the differences, but an unexperienced administrator certainly will have some problems with the installation of the package. > Is there a proper Makefile? (Imakefile for X software?) The Makefile was ok. Since our system supports parallel make processes, I added the parallel option in the rules that are used for the compilation of the C source files. > Did the make run correctly? quickfinger.c includes string.h, which is named strings.h on our system here. There are no #define's to do OS-specific configurations, but I think most of the code is machine-independant. > Are building and installation two separate steps? Yes. In the first step, output files in the source directory are created, during installation they are copied into the etc-directory in horton's home. "make install" does not cover editing the inetd.conf (is ok, since this is machine-dependant and could cause a lot of trouble). > Did the software build on each of the architectures you were able to > test? > NOTE: It is important that you give details about the environments > you used for testing in each and every review that you do. Make > sure you describe the hardware, OS, compilers, etc. that you used, > and any other information that is relevant. This information will > be used to evaluate the portability of the package, and will be > posted along with the sources to let the readers know if the package > is appropriate for them. I tested horton only on our sequent system, and not the mail forwarding feature, since we do not have perl here and I didn't have the time to install is these days. So I just built the tools necessary for collecting the finger data and the "whois" daemon. After changing the "strings.h" include, everything went fine. > Testing the Software > -------------------- > Did the software run on each of the systems you tested? > Did the program perform the functions it was supposed to perform? I had quite a lot of problems with the package, but I think most of them come from the missing name server access here (we do have a name server, but the site pbhrzx doesn't use it, because our link to the backbone network often goes down and pbhrzx should be able to run independantly). Since horton uses full domain names as arguments for the finger program, I couldn't use the quickfinger binary from the horton distribution and wrote a little shell script running our finger program (we have two of them, one to access the local utmp and one for querying remote systems). After that, getting user data went ok. When I tried "monthly.sh", I had some trouble with the mail tester. First, it uses an "if test..." loop to locate the MTA and mail spool directory. Our system does not support the "-x" option to test, so the loop failed and the ls_mail.sh script returned with "cannot find your mail program". This error condition wasn't recognized by the monthly script, which instead interpreted this as a list of host names, which were added to the hosts.poll file as "cannot.domain", "find.domain" and so on. After I found out that ls_mail.sh was responsible for this error, I tried to test only this module, called without parameters to get the "usage" which is printed in the first few lines of the script and got an error message from our lpr binary, since there's a line of the form "Read incoming mail; print ..." in it, where the ';' isn't quoted properly. Adding a backslash solved the problem. After that, I found the problem with the bad option to test and changed the "-x" flag to "-s", so that ls_mail.sh worked as advertised. monthly.sh then began to send out mail messages to the hosts it found, created a lot of junk mail due to the bad entries resulting from the "cannot find your mail program", the messages that were delivered successfully looked a bit strange, because the first line of the mail text ("Postmaster:") was mis-interpreted as a header line by our sendmail (IDA 5.61++). I disabled the part of the program that informed the postmasters, since the postmaster mail of almost all of our systems here are forwarded to one person, who would get megabytes of junk mail otherwise. monthly.sh found our name server and created a list of the hosts in our university, but didn't append this list to the "hosts.poll"-database, but just kept them in the hosts file. I suspect that the part of the monthly script that sends test mails via the new hosts doesn't work properly, but I didn't check here much more, so I just copied the hosts file into hosts.poll and looked what's happening... (I now have a hosts.poll file with about 1000 entries). hourly.sh fingers not all of these sites, I checked several times if new users were added correctly, but after the first test runs (yes, I removed hosts.test :-), no more users were added. The documentation didn't gave me a hint what the problem could be, I finally found out that hourly.sh uses the -i option to egrep, which doesn't work on our system (only grep and fgrep know about "-i", but not egrep!). I simply removed the "-i" option, after that the name collecting worked. Since I had added quite a large host list previously, collecting the finger data took more than one hour (as I mentioned, I couldn't use the quickfinger program), so I got a recursion that resulted in "cannot fork, no more processes". I changed the crontab entry so that the finger process runs only every second our, then everything went ok. I had the problem with the bad option to egrep "-i" a second time in the in.whoisd module, where I just changed the "egrep" call to "fgrep". > The Documentation > ----------------- > General Guidelines > ------------------ > Is the documentation written in a form that is clear, precise, and > easy to understand? > Is each feature or function of the program documented? The documentation is easy to understand, but should tell more about special requirements (switches used when accessing system commands like egrep), escpecially because the software doesn't recognize such problems itself! > Is the documentation organized? Sections and sub-sections often > make documents easier to read and understand. You can read the documentation top-down and perform each of the steps while reading. I like this kind of installation guide, because I'm not interested in reading tons of documentation before getting started. > Guidelines for Unix Documentation > --------------------------------- > Is there a man page? Man pages should contain the following > sections (at least): There's no manual page, and there's, in my opinion, no need for such, since the installation document covers descriptions of all files used by the program, and general information is given in the readme file. > Functionality and Features > -------------------------- > Does the software perform some function that is valuable? There's certainly a need for such a user directory and I like the way how horton works, since with this program, nobody has to spend time in collecting user data, doing entries etc. > Are there obvious features or additions that would improve the package? The package should recognize at least some of the errors I found during installation. It seems to be a general problem with shell scripts that error recovery is bad or even non-existant, and if you aren't that experienced in system administration, it's almost impossible to find these problems. (The log files don't show up where the real problems are) > Overall Evaluation > ------------------ > What is your overall evaluation -- would you recommend it to a friend? Yes, but not in the current form, since you need to much time to install the package and find the problems. > Would you suggest that this submission: > - be accepted for posting as is > - be accepted after minor revisions (that you have detailed) > - be returned to the author with a recommendation to make > major changes and re-submit > - be rejected should be revised by the author: some more error checking, I'd also recommend supporting several "log levels" to be selected. The log files that are created by the current version of the software are not very useful for a system administrator who hasn't read all the source files. -------- Subject: review of horton Overall Evaluation ------------------ What is your overall evaluation -- would you recommend it to a friend? With some major caveats, yes. The user-visible parts are functional and usefull. Would you suggest that this submission: - be returned to the author with a recommendation to make major changes and re-submit Yes: the program is usefull, but major parts of it are not production quality. Short Summary of Review ----------------------- Overall, I find this version, like its predecessor, to be made up of both mature and immature software. It is fragile and hard to understand. To quote a comment about another shell script, ``this isn't organized like a program''. I do regard it as a ``proof-of-concept implementation''. It's good enough to use, but before distributing it widely I'd write a spec based on what it does, and decide based on experience to date how best to implement a production version. Evaluating the Format of the Submission --------------------------------------- Unpacked correctly, and contained expected components. Evaluating the Description and Purpose -------------------------------------- Is there a README file that contains: [...] Yes, and also half of the installation instructions. INSTALL only discussed non-configuration issues. Building the Software --------------------- Is there an Installation document explaining how to build the software? Yes. Are the options and conditional parts of the package (e.g., do this for DOS, this for System V, etc.) clearly documented? No, this is a single-version product. Is there a proper Makefile? (Imakefile for X software?) Yes. Did the make run correctly? Yes. Are building and installation two separate steps? Yes. Did the software build on each of the architectures you were able to test? Built on Sun 4c, SunOS 4.1.1, but not on Ultrix 4.2A with all stock vendor compilers, etc. Testing the Software -------------------- Did the software run on each of the systems you tested? No. The monthly.sh script required heavy hacking to run in a large domain, and lost functionality in the process... Did the program perform the functions it was supposed to perform? Half did. The Documentation ----------------- General Guidelines ------------------ Is the documentation written in a form that is clear, precise, and easy to understand? The README file is quite good. The INSTALL file is quite bad. See below. Is each feature or function of the program documented? Yes. Is the documentation organized? Sections and sub-sections often make documents easier to read and understand. The README is. Guidelines for Unix Documentation --------------------------------- Is there a man page? Man pages should contain the following sections (at least): No. Functionality and Features -------------------------- Does the software perform some function that is valuable? Yes. Are there obvious features or additions that would improve the package? No. Submitting Your Review ---------------------- Ok, here's the rest ----------------------- Part 1: General criticisms Structurally, it suffers from falling on the hairy border of things hard to do in shell and also hard to do in C. The individual phases of say, monthly, could be better controlled by a c program, yet most of the work is still best done with external, pre-existing programs. A decent lisp programmer could do this with his eyes closed. Algorithmicly, its a nuisance. I stumbled on a set of hueristics buried in the middle of some code doing selection from lists, and broke it while trying to avoid a limitation of fgrep. However implemented, it will sufer from dependancies on the behavior of ill-specififed programs (eg, sh/sh5, awk, fgrep). The documentation is badly ordered and full of ``remorse''. This is a term for material that should have appeared earlier in a discussion, but was added in draft when the author thought of it, but not where it belonged. The notes of part 2, below, illustrate this and some of the concerns above. Part 2: Detailed notes to date: Tested on a Sun 4c running sunos 4.1.1. (does not compile on Ultrix 4.2A: can't find mkstemp in link step) Rcsified directory Started with INSTALLATION doc'n - made name ``Horton'', and a directory -- don't know what the example is from: DEC? Sun4? README said sunos 4.1.2... which I don't have. - stared editing Makefile - found an additional installation step: horton.domain.com service-name. [remorse #1] -- requested a service-name -- need to specify what kind of ``alias'' is meant: I assume a CNAME. - made the dirs. - realized I'd already unpacked the shar file so i symlinked it into place. - this is out of order! I'm editing the makefile already. [remorse #2] - started make it dove into phquery, an optional part. distrusted symlink, restarted. compiled this time... why? - found -DDOMAIN=\"machine.domain.com\" used in phquery -- suspicious! as I said domain is domain.com in the makefile - made install saw message ``Be sure to update /etc/inetd.conf and crontab.'' [remorse #3] - created a hosts.poll file (where? where I was in src? No, that clearly didn't work, must be in etc) - created a crontab entry (aha, it is for a sun!) - ran job quite hard to debug as a cron job - ran interactively found apparent permissions mistake... - added to (sun) inetd. no example for older versions. Dec doesn't have as many fields, has to run as root or not at all. - changed permission of hourly.out and directory tree to allow daemon to read it! Omask was far too restrictive. That worked. - ran into more remorse -- I have to ftp a copy of log-tcp iff I want to restrict access [#4] - privacy.mail not updated with info from makefile. Bug! (breaks the write-once rule) - the contact address in .plan didn't match mine from the makefile. Ditto - the kill -HUP didn't restart my inetd , kill -9 /restart required have they a much newer sun or what? - missing hosts.exclude documentation in install remembered it freom doc'n of earlier version. - got horton name in dns, started to recompile. Worked, and install didn't shred anything. - ran monthly.sh, fgrep of my huge domain file failed as the wordlist was too large. used diff instead. There may be other examples... Yup, the run isn't honoring my exceptions file... found in ls_hosts.sh, in two places. - shitty csh won't let me do it right... I had to reduce functionality to fix ls_host.sh, by taking out the heuristic. This needs a rewrite in a language with more generlity, and checks for failure such as fgrep having too many lines in the exclude file. I could convince XYZZY to do it in scheme... (a lisp dialect) - in principle monthly could be ok... it just doesn't seem to try very hard. Maybe I'll run it manually some more: it still wants to treat aries (first machine in my domain) as new each time. Part 3 In general, this could be written in an higher-level language like lisp, in an extended shell like rayan z's, or in c using lots of popens and explicit selection logic. It could be witten with some difficulty in sh with shell functions, but not in csh. The monthly processing just isn't good enough to ship. Part4: Local changes I've replaced monthly with a program that reads my domain database, selects machines with MXs and lists them. At this site an MX is a necessary and suficient condition to have mail. Anyone who doesn't have good enough mailers doesn't get an MX, or has to sign off that they indemnify the postmaster from responsability to get one from networking when I've declared their mail service ``not to be used for mission-critical purposes''. The script follows: #!/bin/sh # # monthly.sh -- replacement for horton's ``monthly.sh'' # This searches for sites in the domain which have an # mx record, a necessary and sufficient condition for # email. # # Parameters are domain-name and directory to place # hosts.poll in. # TMP=/usr/tmp/horton.list.$$ DIG=dig DIGPARMS='axfr in +nocmd +noques +nostats +d2' DIGNSPARMS='ns in +pfset=0x24f9 +noques +nocmd +nostats' if [ $# -ne 2 ]; then echo Usage: $0 domain dir echo Adds sites in domain with MXs to dir/hosts.poll. echo Domain must be in lower case. exit 1 fi set -x DOMAIN=$1 cd $2 # Make sure that the domain has a trailing "." case $DOMAIN in "") echo "no domain specified, halting."; exit 1 ;; *.) ZONE=$1 ;; *) ZONE=$1. ;; esac # Find server, or if server couldn't be found, exit gracefully. SERVER=`$DIG $ZONE $DIGNSPARMS | grep -v "^ " |\ awk '$3=="NS" { print $4; exit}' |\ sort -u +0 -1` SERVER="@$SERVER" case $SERVER in "@") echo "${0}: no server for this domain, exiting." exit 1 ;; *) ;; esac # Query DNS with dig for their MX status dig $SERVER $DOMAIN $DIGPARMS |\ grep -v "^ " | awk ' $3=="MX" {print $1}' | sort -u |\ sed 's/\.$//' >hosts.poll exit ------- -------- Subject: Partial Review of 'horton' ready Environments: SUN 4/25 under SUN-OS 4.1.1 DECstation 3100 under ULTRIX V4.1 (Rev. 52) Evaluating the Format of the Submission --------------------------------------- Horton came in 4 shar files, which unpacked correctly into the local directory and two subdirectories. There was a Manifest file. Evaluating the Description and Purpose -------------------------------------- There is a README file that contains: - the purpose and value of the software - the types of systems it is intended for - any dependencies in the system - known limitations of the software - the authors of the software (with e-mail addresses) - the "patchlevel" of the software - any copying or distribution conditions There is a "patchlevel.h" file indicating the version number of the software. The README is well-written and quite understandable. The software requirements are not given completely: The recommended or perhaps-necessary programs 'dig' and 'log_tcp' are not mentioned. Building the Software --------------------- There is a good and detailed INSTALL file describing the (complicated) installation process. The Makefile is well-commented and easy to adapt. The software built without complaints on SUN-OS. On Ultrix, the linking step failed, because the 'mkstemp' function is not present in the standard C library there. 'mktemp' does exist, though, and should probably be used instead. Testing the Software -------------------- I bothered to bother the postmasters at my institution with lots of horton-generated email and did thus NOT actually install and test horton. (We have an always-up-to-date central name service at our site) The Documentation ----------------- Since horton consists of deamons only, there is no documentation apart from the (good) README and INSTALL documents. This is OK insofar that no end-user manual pages are needed. Nevertheless, it would be fine to have a prepared announcement document to be used to introduce horton to the end-users, once it is installed. The 'dot.plan' file is a good start for this, but seems to be a bit too short for me. Maybe you should also supply "manpage patches" for whois and email software, in order to mention horton there. Functionality and Features -------------------------- Does the software perform some function that is valuable? Well, the function (as seen from the outside) is clearly valuable. But the way in which it is achieved is awkward: horton is one of these programs that keeps your machines and network busy, even if nobody is actually using them -- which doesn't matter as long as nobody needs the power; but on heavily loaded networks, it is nasty to have such a regular bandwith eater running. The larger the network, the worse the effect. A name service should be maintained by a less simple-minded approach than sampling the actual use of the machines. Overall Evaluation ------------------ What is your overall evaluation -- would you recommend it to a friend? Hmm. If s/he really needs such a service, I would recommend horton. But I would at the same time suggest to do everything to make this approach to providing a name service superfluous. I suggest that this software be accepted after minor modifications (adaption to Ultrix), given that the other reviewers find that it really works. The part00 should clearly mention who will NOT need horton. Short Summary of Review ----------------------- horton provides an automatically maintained name service for those poor boys and girls, who do not have a properly administered one. While it is nice to have that service, the cost (in terms of network bandwith) of letting horton provide it will not be negligible for large networks. In principle, there are cheaper ways to automatically maintain a name service, although they would require more cooperation by external machines (that means: changes). We should use these cheaper ways in the future. Until those better times begin, horton may be a useful 'bugfix' for some people. Everbody, who is considering to use horton, should check first, whether a manually maintained name service would be easy to provide in good quality or whether such a service does even exist already (DON'T LAUGH. A year ago, I discovered that my site really HAS a good central name service but hardly anybody knows about it!) -- Andrew Patrick acting as Comp.Sources.Reviewed Moderator Department of Communications, Ottawa, CANADA csr@calvin.dgbt.doc.CA