Xref: utzoo comp.mail.misc:1060 news.sysadmin:779 Path: utzoo!yunexus!spectrix!clewis From: clewis@spectrix.UUCP (Chris "where are you this week?" Lewis) Newsgroups: comp.mail.misc,news.sysadmin Subject: Re: My script for mapfiles/pathalias updating Summary: Simpler way if you have uuhosts. Also soln to ihnp4 and cbosgd. Keywords: pathalias, maps, update, script Message-ID: <700@spectrix.UUCP> Date: 30 Jun 88 14:51:06 GMT Article-I.D.: spectrix.700 References: <957@flatline.UUCP> <320@elan.UUCP> <3238@palo-alto.DEC.COM> Reply-To: clewis@spectrix.UUCP (Chris "where are you this week?" Lewis) Organization: Spectrix Microsystems Inc., Toronto, Ontario, Canada Lines: 101 In article <3238@palo-alto.DEC.COM> vixie@palo-alto.DEC.COM (Paul Vixie) writes: [ Regarding pulling the maps and using pathalias ] >I hacked up 'uuhosts -unbatch' to do a > touch /usr/spool/uucpmap/comp.mail.maps/.time_stamp >every time it unpacked a map article; then I wrote a Makefile for /usr/lib/mail >that has paths.dir and paths.pag depending on paths which depends on the >.time_stamp file. At 12:30am every night I run 'cd /usr/lib/mail;make', >which rebuilds the paths database if any map articles have been unpacked >since the last time the paths database was built. There's a simpler way (if you're running uuhosts): This is a fragment of our uuhosts shell script. The standard "-unbatch" has been extended by the addition of the "$BIN/uuhosts -pathalias", and the "-pathalias" has been added as a recursive call to do the path munging. Since unbatch doesn't do anything if there are no maps to process, pathalias will be run automatically only when new maps come in. Since modifications to our local file are rare, I manually run "uuhosts -pathalias" when I change it - or simply wait for the next maps to come in. -unbatch) # Unbatch map articles batched by inews. Called from cron. cd $MAPS/$UUCPMAP if [ -f Batch ]; then : else exit 1 fi mv Batch Batch.working for f in `cat Batch.working` do $BIN/uuhosts -x < $f sleep 5 done rm Batch.working $BIN/uuhosts -i $BIN/uuhosts -pathalias if [ -f $LIB/uuwhere ]; then $LIB/uuwhere fi exit 1 ;; -pathalias) cd $MAPS/$UUCPMAP $zcat d.* u.* path.* | \ pathalias -f -dutstat -dcxhq -dihnp4 -dcbosgd -dhao -lspectrix \ > /tmp/paths.1 2> $LIB/pathalias.err if [ ! -s /tmp/paths.1 ]; then echo "PATHALIAS FAILED!!!!" | $MAILER postmaster exit 1 fi pathproc < /tmp/paths.1 > /tmp/paths.2 mv /tmp/paths.2 $PATHS rm -f /tmp/paths.1 ;; (BTW: we *are* running compressed maps. pathproc comes from the smail distribution and is just a small sed script wrapped around sort.) I've been sort of wondering what all of the fuss about AT&T's dropping of external forwarding of mail thru ihnp4 and cbosgd. We've had them marked dead for 6 months without any trouble. We figgered that the load on those machines was so high, and the delays are frequently so long that it wasn't worth relying on them. Especially given when many times other sites exaggerated their links to ihnp4 so much that neighboring local-call site's mail got routed thru ihnp4. And that Henry Spencer seemed to be telling us several times a month that his link to ihnp4 was down (pre-uunet<->mnetor). And, AT&T's done yeoman's service for the net over the years - give 'em a break! Though, ihnp4 should never have let so many people connect to it - maintaining a map that size would take several people full time just ensuring that the other sites still exist from week to week! We typically mark dead sites who: - Autoroute *all* mail and have out of date maps (rutgers occasionally rejects almost everything we send it - so I periodically mark rutgers dead. Most of the time rutgers does a reasonable job - almost marked uunet dead once too...). - Insist on telling everybody about links outsider's are not permitted to use and bounce stuff (GRRRR!!!!). - Very overloaded or are having communication problems. (often mentioned in news.config) - Mention that they're going out of service temporarily or permanently. (often mentioned in news.config) - Sometimes minor sites get ridiculous about links to other machines (eg: I were to copy uunet's map and mark every cost as zero ;-) So, when a unknown machine pops into major paths, I check to ensure that it's a moderately stable one and that they intend to support the traffic. If not, it gets marked dead. -- Chris Lewis, These addresses will last only til June 30: (clewis@lsuc afterwards) UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis Moderator of the Ferret Mailing List (ferret-list,ferret-request@spectrix)