Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How to keep wais from using full path names

1 view
Skip to first unread message

Marco Hernandez

unread,
Jul 19, 1994, 4:50:18 PM7/19/94
to
I'm sure that this has been discussed before here. I saw a thread earlier but
it did not answer the question.

When using wais and gopher, it appears that wais places the full path
of the indexed files in its indexes et. al ...

This of course means that you then can not run gopher chrooted :-(, I have
RTFM'd to no avail, I can not find out how to overcome this ...

Has anyone found a fix around this....

I am running WAIS release 8 b5 31 Oct 1992, bio patch and the latest
gopherd from Minn.

Thanks for the help, If people want to mail me directly, I will summarize
to the newsgroups ...

Cheers,

Marco Hernandez


---

Marco Hernandez <ma...@cren.net>

--


Marco Hernandez <m...@cren.net>

Christopher Blencowe

unread,
Jul 22, 1994, 11:25:32 AM7/22/94
to
Marco Hernandez (m...@cren.net) wrote:
: I'm sure that this has been discussed before here. I saw a thread earlier but

: Cheers,

: Marco Hernandez


: ---

: Marco Hernandez <ma...@cren.net>

: --


: Marco Hernandez <m...@cren.net>

Seems to me having the same problem, so please someone give a answer
Christopher

Lou Sortman

unread,
Jul 24, 1994, 3:45:31 PM7/24/94
to
In article <30oodc$m...@sun0.urz.uni-heidelberg.de>,

Christopher Blencowe <c...@convex.phazc.uni-heidelberg.de> wrote:
>Marco Hernandez (m...@cren.net) wrote:
>: I'm sure that this has been discussed before here. I saw a thread earlier but
>: it did not answer the question.
>
>: When using wais and gopher, it appears that wais places the full path
>: of the indexed files in its indexes et. al ...
>
>: This of course means that you then can not run gopher chrooted :-(, I have
>: RTFM'd to no avail, I can not find out how to overcome this ...
>
>: Has anyone found a fix around this....
>
>: I am running WAIS release 8 b5 31 Oct 1992, bio patch and the latest
>: gopherd from Minn.
>
>: Thanks for the help, If people want to mail me directly, I will summarize
>: to the newsgroups ...
>
>
>Seems to me having the same problem, so please someone give a answer
>Christopher

When I asked a similar question awhile back, a kind soul wrote me and suggested
that I create a symbolic link to point to the chrooted directory. In my case:

cd /users/lou/iog/data
ln -s /users/lou/iog/data /

That way, when the server tries to access /users/lou/iog/data/somefile, it
follows the link and finds it. You will, of course, have to hide the top
level of that link (users in my case) from the server. I did it in my
.Links file.

--
l...@tfnet.ils.unc.edu (Lou Sortman) for(i=0; i<3; i++) puts(
"Janet! Dr. Scott! \n"
"Janet! Brad! \n"
Whoever dies with the most LEGO wins. "Rocky! <Uh!> \n");

Fuzzy Fox

unread,
Jul 25, 1994, 1:52:19 AM7/25/94
to
l...@tfnet.ils.unc.edu (Lou Sortman) writes:

>When I asked a similar question awhile back, a kind soul wrote me
>and suggested that I create a symbolic link to point to the chrooted
>directory. In my case:

> cd /users/lou/iog/data
> ln -s /users/lou/iog/data /

The above line should be modified to this:

ln -s users/lou/iog/data /

In other words, leave off the leading "/".

This works fine, though gopher browsers will see your "phantom"
users/lou/iog directory and wonder what it's for.

--
Fuzzy Fox | "The aardvark is really a curious creature;
f...@netcom.com | If you're an ant, he's likely to eatcher.
<http://mikey. | Although his long nose makes him look rather hideous,
convex.com:8080/> | He's still listed first in the encyclopideous."

ro...@tfnet.ils.unc.edu

unread,
Jul 25, 1994, 9:30:17 AM7/25/94
to
In article <foxCtH...@netcom.com>, Fuzzy Fox <f...@netcom.com> wrote:
>l...@tfnet.ils.unc.edu (Lou Sortman) writes:
>
>>When I asked a similar question awhile back, a kind soul wrote me
>>and suggested that I create a symbolic link to point to the chrooted
>>directory. In my case:
>
>> cd /users/lou/iog/data
>> ln -s /users/lou/iog/data /
>
>The above line should be modified to this:
>
> ln -s users/lou/iog/data /
>
>In other words, leave off the leading "/".
>

Of course, you are right. My fingers just got into a pattern.
Thanks for pointing this out.

>This works fine, though gopher browsers will see your "phantom"
>users/lou/iog directory and wonder what it's for.
>

I can hide the directory by putting "Type=-" in my .Links file.
That successfully hides it from the standard gopher client, but,
unfortunately, MOSAIC still sees it. This trick was mentioned in one
of the man pages. I just wish that the server would recognize Type=-
entries and not send them. I could always "fix" mine, but that's not a
permanent solution.


Steven J Coile

unread,
Jul 27, 1994, 2:17:31 PM7/27/94
to
ro...@tfnet.ils.unc.edu wrote:
[...]

>I can hide the directory by putting "Type=-" in my .Links file. That
>successfully hides it from the standard gopher client, but,
>unfortunately, MOSAIC still sees it. This trick was mentioned in one
>of the man pages. I just wish that the server would recognize Type=-
>entries and not send them. I could always "fix" mine, but that's not a
>permanent solution.

Use

Type=X

to hide items. This is a documented method described in the man pages
for gopherd. An item marked with a type of X will not be sent to the
client *at all* (i.e. the server filters it out). Works fantastically--
I use it all the time.

(The above assumes that you are using the University of Minnesota's
gopherd Gopher server. We're running 2.0.16 and "Type=X" works with
it.)

-Steve Coile
MasonLink Administrator
George Mason University

Brian W. Spolarich

unread,
Jul 27, 1994, 11:58:43 PM7/27/94
to
: When using wais and gopher, it appears that wais places the full path
: of the indexed files in its indexes et. al ...


: This of course means that you then can not run gopher chrooted :-(, I have
: RTFM'd to no avail, I can not find out how to overcome this ...

The docs are somewhat less than useful, especially on the specifics. :-]

: Has anyone found a fix around this....

Well, perhaps this would work.

Say your gopher files are in /usr/private/gopher/data/ so the gopher
chroot()s to there. If your wais collection is in
/usr/private/gopher/data/wais, then the relative path from the gopher
server is simply /wais.

freeWAIS 0.202 and later support a document type called URL, which
takes two arguments: what to strip off and what to add on, explicity for
http servers. So you can do something like (this from a Makefile which
rebuilds my indexes):

waisindex -export -pos -a -d $(INDEXDIR)/$(INDEXNAME) -t URL
/ocs/ocs-info/ http://ocs.us.itd.umich.edu/ $(BASE)/r/*/index*.htm

So /ocs/ocs-info (the root of the http server) is stripped off and
http://ocs.us.itd.umich.edu is added on.

You could do the same thing with gopher. In my above gopher example,
you could do

waisindex -d whatever -t URL /usr/private/gopher/data/wais/ /wais/
$filestobeindexed

So the headlines returned by WAIS should look like

/wais/mydocs/blah/blah

Which should work fine from the point of view of your gopher server.

I haven't tried this out, and I don't know what other things the type
"URL" does to the database (probably nothing). But it might be a
solution. Let me know if it works!

: I am running WAIS release 8 b5 31 Oct 1992, bio patch and the latest
: gopherd from Minn.

Don't know if it will with work the non-CNIDR WAIS package.

-brian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Brian W. Spolarich bri...@umich.edu
UM ITD User Services (313) 747-3499
Online Consulting Systems Project http://ocs.us.itd.umich.edu
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

0 new messages