edb@fai.UUCP (Edward Bunch) (09/30/88)
I am having a mail routing problem with pathalias. A site that will remain
nameless puts:
nameless .somedomain.foo(LOCAL)
in their pathalias entry.
For my local users I have a better way of getting through to .somedomain.foo.
So I add the line:
fai .somedomain.foo
in my pathalias.
This works for other domains I serve.
When pathalias builds its files I end up routing through nameless.
I thought of adding my own:
fai .somedomain.foo(LOCAL)
but my sendmail.cf expects ".somedomain.foo" to be a machine name in L.sys.
QUESTIONS:
1. Is this syntax legal?
2. Must I really hack sendmail.cf to understand "."'s in a name really aren't
uucp machine names?
--
Edward A. Bunch UUCP: {uunet,amdahl,sun}!fai!edb
Fujitsu America, Inc. DOMAIN: edb@fai.com
Computer Support and Administation.aad@stpstn.UUCP (Anthony A. Datri) (10/02/88)
There are several lines of my pathalias output that I know better (geographically, at least) paths for, and after attempting various more "elegant" methods, I just have my pathalias script that runs nightly pipe the output through sed, replacing the desired lines. Ugly, but it works. Now I just have to figure out how to make sendmail send foo!bar to smail instead of uux, when we don't talk to foo. Works fine for bar@foo, though. -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, or my 11/34) beak is beak is not Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad
wes@obie.UUCP (Barnacle Wes) (10/07/88)
In article <2164@stpstn.UUCP>, aad@stpstn.UUCP (Anthony A. Datri) writes: > There are several lines of my pathalias output that I know better > (geographically, at least) paths for, and after attempting various > more "elegant" methods, I just have my pathalias script that runs nightly > pipe the output through sed, replacing the desired lines. Ugly, but > it works. Another, perhaps slightly more elegant :-) way to do this is to have the sed script lower the cost on the links you want to use to some (ridiculously) low value. Obie, myth, and wsccs all use this to force certain paths that sp7040 allows us to use, but does not broadcast to the net.at.large :-). Nightly pathalias runs, huh? Must be nice having a machine with lots of processor time and i/o bandwidth and such. I haven't managed to get pathalias to run on obie yet, and it takes quite a while to run on wsccs (on the order of 20 minutes for pathalias | pathproc :-). -- {hpda, uwmcsd1}!sp7040!obie!wes "How do you make the boat go when there's no wind?" -- Me --
dg@lakart.UUCP (David Goodenough) (10/18/88)
From article <211@obie.UUCP>, by wes@obie.UUCP (Barnacle Wes): > In article <2164@stpstn.UUCP>, aad@stpstn.UUCP (Anthony A. Datri) writes: >> There are several lines of my pathalias output that I know better >> (geographically, at least) paths for, and after attempting various >> more "elegant" methods, I just have my pathalias script that runs nightly >> pipe the output through sed, replacing the desired lines. Ugly, but >> it works. > > Another, perhaps slightly more elegant :-) way to do this is to have the > sed script lower the cost on the links you want to use to some > (ridiculously) low value. Obie, myth, and wsccs all use this to force > certain paths that sp7040 allows us to use, but does not broadcast to > the net.at.large :-). Yet another (IMHO "elegant") solution is to take advantage of the fact that pathalias utilises data IN THE ORDER IT FINDS IT with respect to multiple entries. So, for example, if there was a link between my machine at home (pallio) and system blurf on the west coast (lakart & pallio are in Boston) that I want to be able to use from lakart and pallio, but I dont want anyone else to know about I do the following: create a u.PALLIO file with the following two lines: pallio blurf(HOURLY) blurf pallio(HOURLY) Now when I run pathalias (every night :-) ) I invoke it as follows: pathalias u.[A-Z]* [ud].* which causes the u.PALLIO (and u.LAKART - we have one) information to be read first, hence it takes precedence over real information. I think this may well do what you want. -- dg@lakart.UUCP - David Goodenough +---+ | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@harvard.harvard.edu +---+
john@jetson.UPMA.MD.US (John Owens) (10/20/88)
In article <292@lakart.UUCP>, dg@lakart.UUCP (David Goodenough) writes: > Yet another (IMHO "elegant") solution is to take advantage of the fact that > pathalias utilises data IN THE ORDER IT FINDS IT with respect to multiple Actually, pathalias uses the lowest cost it encounters as the cost of the link. That's why you can't increase the cost of a link just by saying "foo bar(DEAD)", and why the "dead {foo!bar}" syntax was introduced. To demonstrate: % cat one # public foo bar(5000) foo other(1000) other bar(1000) # private foo bar(100) % cat one | pathalias -l foo foo %s bar bar!%s other other!%s % cat two # private foo bar(100) # public foo bar(5000) foo other(1000) other bar(1000) % cat two | pathalias -l foo foo %s other other!%s bar bar!%s % It doesn't matter in which order pathalias sees the "foo bar(5000)" line; it will always use the "foo bar(100)" line. Regardless, I agree that it is an elegant and good idea to have a local input file to pathalias that contains reduced costs that aren't published publically. I've used that technique on every system I've run pathalias on. I just want to make sure that no one tries to use the technique to attempt to _increase_ locally the cost of a published link. Happy pathaliasing, -John -- John Owens john@jetson.UPMA.MD.US uunet!jetson!john +1 301 249 6000 john%jetson.uucp@uunet.uu.net
honey@umix.cc.umich.edu (Peter Honeyman) (10/22/88)
i found this on a man page somewhere ...
If a link is encountered more than once, the least-cost occurrence
dictates the cost and network character.
to increase a cost, run your local map last, and say
delete {foo!bar}
foo bar(DAILY)
if your version of pathalias flags this as a syntax error, drop me a
line and i'll send you fresh code.
peterdg@lakart.UUCP (David Goodenough) (10/23/88)
In article <163@jetson.UPMA.MD.US>, john@jetson.UPMA.MD.US (John Owens) sez: > In article <292@lakart.UUCP>, I say: >> Yet another (IMHO "elegant") solution is to take advantage of the fact that >> pathalias utilises data IN THE ORDER IT FINDS IT with respect to multiple > > Actually, pathalias uses the lowest cost it encounters as the cost of > the link. That's why you can't increase the cost of a link just by > saying "foo bar(DEAD)", and why the "dead {foo!bar}" syntax was > introduced. ..... I STAND CORRECTED AND APOLOGIZE FOR ANY CONFUSION I HAVE CAUSED. I had forgotten that all the stuff in our local u.LAKART file relates to reducing path costs. > Regardless, I agree that it is an elegant and good idea to have a > local input file to pathalias that contains reduced costs that aren't > published publically. So at least I scored 1 out of 10 for trying :-( -- dg@lakart.UUCP - David Goodenough +---+ | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@harvard.harvard.edu +---+
jim@eda.com (Jim Budler) (10/27/88)
In article <292@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes: >From article <211@obie.UUCP>, by wes@obie.UUCP (Barnacle Wes): >> In article <2164@stpstn.UUCP>, aad@stpstn.UUCP (Anthony A. Datri) writes: >>> There are several lines of my pathalias output that I know better >>> (geographically, at least) paths for, and after attempting various >>> more "elegant" methods, I just have my pathalias script that runs nightly >>> pipe the output through sed, replacing the desired lines. Ugly, but >>> it works. >> >> Another, perhaps slightly more elegant :-) way to do this is to have the >> sed script lower the cost on the links you want to use to some >> (ridiculously) low value. Obie, myth, and wsccs all use this to force >> certain paths that sp7040 allows us to use, but does not broadcast to >> the net.at.large :-). [other suggestions omitted] When I was wandering through the archive list 'GNU.how-to-get' (approx. title, it is from memory) describing how to annon. UUCP from osu-cis I found, in addition to pathalias9, the 'release' version, an entry for 'a newer, but unreleased' pathalias. Being a curious chipmunk, I grabbed it. Two new features were 'adjust' and 'delete'. I have a Path.fixes in addition to Path.local, which I use as follows for smail 2.5: pathalias -c Path.local [du].* Path.fixes | ... In this file I have: delete {amd,ixpierre} Guess what that does? I know amd doesn't exist anymore, but lingers in the maps, and ixpierre was announced gone in news.config. I don't use it, but adjust {site1, site2(LOW), site3(-1)} where site1 would be given the default 4000, is also in the manual. this also seems appropriate for Path.fixes. This feature is *great*, and I wonder when it will be 'released', and I hope nobody is upset at me letting the cat out of the bag. This version does appear to use a different algorithm. The resulting paths file is different in that the resulting paths are shorter. I tested it a month ago, and reran the test just now (not using Path.fixes). Same results. I like the shorter paths, and *love* the features I put in my Path.fixes file. Before I get extra flames: 1) I DO NOT actively reroute. 2) I talk to only decwrl and uunet, why would ANYONE route things *through* my site? 3) Our own mail volume is low, and the returns after a month have been extremely low (usually due to site!@site2:joe@site3 type return paths, where do they come from?) Cheers. -- uucp: {decwrl,uunet}!eda!jim Jim Budler internet: jim@eda.com EDA Systems, Inc.