jeff@tc.fluke.COM (Jeff Stearns) (03/01/88)
I'm listed in the USENET maps. I run pathalias. There's something I don't
understand.
How do I gracefully change my map data? I have many uucp neighbors. The
configuration changes from week to week, so the published pathalias data is
always somewhat out-of-date.
I can easily change my path.local file, and I dutifully mail the changes off
to the uucpmap folks, but it takes many weeks for the changed d.usa.wa.1 map
file to arrive back here. Meanwhile, my new path.local file disagrees with
the now-stale map data for my site in d.usa.wa.1. When pathalias sees this
stale old data, it treats it with as much respect as my path.local file.
This causes invalid routes to be built.
Of course, I can go edit the map postings, but this kind of approach is
decidedly non-deterministic. When will another posting arrive and overwrite
my changes? Will the new posting contain my changes, or will they have
"passed each other in the mail"?
My updated map data can take weeks to arrive via netnews. (And a couple
updates never did arrive.) Meanwhile, I must await the receipt of another
out-of-date comp.mail.maps posting that could invalidate my pathalias database
again.
What is the proper way to merge my path.local data with the comp.mail.maps data?
For example, I'd like pathalias to understand that my path.local file always
has precedence over anything posted to comp.mail.maps. I furthermore expect
that most other sites would wish this as well. Is this thinking correct? If
so, how do others handle the situation? It seems like such a common scenario;
is there a clean solution?
--
Jeff Stearns
Domain: jeff@tc.fluke.COM
Voice: +1 206 356 5064
UUCP: {uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,sun}!fluke!jeff
Snail: John Fluke Mfg. Co. / P.O. Box C9090 / Everett WA 98206dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/01/88)
In article <3008@fluke.COM> jeff@tc.fluke.COM (Jeff Stearns) writes: >For example, I'd like pathalias to understand that my path.local file always >has precedence over anything posted to comp.mail.maps. I furthermore expect >that most other sites would wish this as well. Is this thinking correct? If >so, how do others handle the situation? It seems like such a common scenario; >is there a clean solution? It would be nice if one could say pathalias u.* d.* -override path.local and have everything in path.local supersede all corresponding info in the other files. But right now, the only way to supersede information from one file is to show a lower cost for a route in another file. Usually you will want to give a local link a slightly higher or lower cost than the current published maps. You can force such local changes to override the published maps by lowering the costs of ALL your local links to an abnormally low value, so they always override the published values, and then adjusting these as necessary. Then all that matters is the relative weights of your local links to each other. For example, if you are site X and you talk to A, B, and C, you could say: X A(10), B(10), C(8) These are extraordinarily low costs, but their relative weights are all that matter, and you will route most or all traffic through C regardless of what the maps say. In the above example, if you changed B(10) to B(50), it would be nearly the same as marking B as dead, even if the published cost to B was quite low. The artificially-low costs to A and C override the relatively high cost to B. Note that the rest of the world never knows about these artificial costs and is unaffected by them and relies only on the published maps. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
kls@ditka.UUCP (Karl Swartz) (03/03/88)
In article <3008@fluke.COM> jeff@tc.fluke.COM (Jeff Stearns) writes: >How do I gracefully change my map data? I have many uucp neighbors. The >configuration changes from week to week, so the published pathalias data is >always somewhat out-of-date. > >What is the proper way to merge my path.local data with the comp.mail.maps data? > >For example, I'd like pathalias to understand that my path.local file always >has precedence over anything posted to comp.mail.maps. Two things. If the published maps say fluke foo(HOURLY), bar(HOURLY) and you now call foo on demand and have dropped your link to bar, your path.local file should look like this: fluke foo(DEMAND) dead {fluke!bar} Pathalias will always use the fastest route, so your declaration for fluke!foo will effectively override the published one. And the 'dead' declaration will override anything elsewhere in the maps. When the lack of connection to bar finally propogates to the maps, you can remove the 'dead' line. -- Karl Swartz |UUCP decvax!formtek!ditka!kls 1-412/937-4930 office | {floyd,pitt,psuvax1}!idis!formtek!ditka!kls |BIX kswartz "I never let my schooling get in the way of my education." (Twain)
ntitley@btnix.UUCP (Nigel Titley) (03/10/88)
From article <3008@fluke.COM>, by jeff@tc.fluke.COM (Jeff Stearns): > I'm listed in the USENET maps. I run pathalias. There's something I don't > understand. [ Many problems with keeping pathalias database up to date ] Seems like a good argument for running domain based mailers.
honey@umix.cc.umich.edu (Peter Honeyman) (03/13/88)
pathalias provides one sort of name service, dns (or udp/53) another. pathalias is not an attempt to displace dns; by the same token, dns is not equipped to provide uucp source routes. to work properly, both pathalias and dns require access to current data. this is easy to get in the internet, not so easy to get in a dialup network. name service is the issue here, not "domain based mailers." many of us who run domain based mailers (or, in my case, domain tolerant mailers) also rely heavily on pathalias. peter ps: i should add that i'm not at all unhappy with the timeliness of the usenet maps. at the very least, we've come a long way from the days when smb, trb, sob, and ksh collected and redistributed the maps. i agree that "posted" maps should not advertise data that change from week to week.
jacob6@ntvax.UUCP (03/14/88)
Hi Jeff, Iam just curious about the USNET maps, I will like to have all node names in USA and how they connected to each other. If you have any information on this please let me know. Thanks in advance. Jey Asirvatham UUCP: convex!ntvax!jacob6
greg@ntvax.UUCP (03/14/88)
Jey, if you are interested I can send you the info we have on our system. greg