Forcing tt_host_file_netfile to return a different netfile path?

Forcing tt_host_file_netfile to return a different netfile path?

Post by Rob Menk » Wed, 25 Feb 1998 04:00:00



I'm not a ToolTalk guru by any account, so I really need some help here.

The Solaris 2 automounter is exceptionally clever, in that it uses the
loopback file system instead of symlinks when it sees that the file
system to be mounted is on the same machine as the mount point.  The
problem is, ToolTalk reads the /etc/mnttab file directly (according to
truss) in order to generate netfile paths, and (I suspect) fails to
acknowledge the loopback mounts.

Therefore, an entry of

    /export/home/rgm        /home/rgm       lofs  ...

generates a netfile path (via tt_host_file_netfile) of

    TTN0HOST=0-3,RPATH=4-12,LPATH=13-21:elko/home/rgm/home/rgm

instead of the correct netfile path of

    TTN0HOST=0-3,RPATH=4-19,LPATH=20-28:elko/export/home/rgm/home/rgm

Any suggestions?  I tried using a hostname_map to get the information
resolved on another machine (which would avoid the loopback mounts) but
it looks like tt_host_file_netfile ignores the hostname_map file.

Have I been running in circles because of a misconfigured ToolTalk
setup?  Is this an acknowledged (and hopefully patched) bug?  If not,
then is there any way to explicitly tell tt_host_file_netfile to return
a specified netfile path?

(This problem manifests itself in dtspcd, which is why I posted to
comp.unix.cde.  This also seems to be limited to Solaris 2, hence
comp.unix.solaris.)

Thanks in advance.


 
 
 

Forcing tt_host_file_netfile to return a different netfile path?

Post by Robert All » Thu, 26 Feb 1998 04:00:00


+I'm not a ToolTalk guru by any account, so I really need some help here.
+
+The Solaris 2 automounter is exceptionally clever, in that it uses the
+loopback file system instead of symlinks when it sees that the file
+system to be mounted is on the same machine as the mount point.  The
+problem is, ToolTalk reads the /etc/mnttab file directly (according to
+truss) in order to generate netfile paths, and (I suspect) fails to
+acknowledge the loopback mounts.
+
+Therefore, an entry of
+
+    /export/home/rgm        /home/rgm       lofs  ...
+
+generates a netfile path (via tt_host_file_netfile) of
+
+    TTN0HOST=0-3,RPATH=4-12,LPATH=13-21:elko/home/rgm/home/rgm
+
+instead of the correct netfile path of
+
+    TTN0HOST=0-3,RPATH=4-19,LPATH=20-28:elko/export/home/rgm/home/rgm

What OS version is this on?  The extra "/home/rgm" here looks
familiar, as if it might have been a bug I fixed in ToolTalk
for 2.6...

Where does the file you're interested in actually live in this
case?

Tooltalk knows how to deal with lofs.  I suspect the problem here
may be in dtspcd.  In fact I'm almost certain as I think about it.
I recall the engineers who made dtspcd ToolTalk-aware (it was IBM or HP)
clearly didn't have a full grasp of the calls they used.  I
thought there was at least one case where they were using the
wrong netfile conversion call for the  circumstances they were in.

+Any suggestions?  I tried using a hostname_map to get the information

As an aside I'll note that netfiles are supposed to be opaque tokens,
useful only for converting back to regular filenames via tt_netfile_file()...

+resolved on another machine (which would avoid the loopback mounts) but
+it looks like tt_host_file_netfile ignores the hostname_map file.
+
+Have I been running in circles because of a misconfigured ToolTalk
+setup?  Is this an acknowledged (and hopefully patched) bug?  If not,
+then is there any way to explicitly tell tt_host_file_netfile to return
+a specified netfile path?
+
+(This problem manifests itself in dtspcd, which is why I posted to
+comp.unix.cde.  This also seems to be limited to Solaris 2, hence
+comp.unix.solaris.)

So you've looked at the dtspcd src to confirm this?

I fixed several bugs in dtspcd for 2.6 that had to do with
using the wrong paths for remote execution, and also there were
other problems caused by poor memory management in dtspcd.  If
you're  running pre 2.6 you may be running into  those bugs.  A
patch was released  for at least some of of those bugs in pre 1.2
CDE.

Robert

 
 
 

Forcing tt_host_file_netfile to return a different netfile path?

Post by Robert All » Thu, 26 Feb 1998 04:00:00



>Any suggestions?  I tried using a hostname_map to get the information
>resolved on another machine (which would avoid the loopback mounts) but
>it looks like tt_host_file_netfile ignores the hostname_map file.

>Have I been running in circles because of a misconfigured ToolTalk
>setup?  Is this an acknowledged (and hopefully patched) bug?  If not,
>then is there any way to explicitly tell tt_host_file_netfile to return
>a specified netfile path?

ToolTalk isn't configurable in this case.  It just reads the
/etc/mnttab file and stores intnernal copies.  This does mean
it has to know how to parse all the various forms of  entries
that can be in that file, but as far as I know, it does.
ToolTalk has understood lofs for some time now.

Robert

 
 
 

1. forcing sendmail not to use login account in return-path?

Hi netters,

My program creates SMTP emails and submits to sendmail. The mail
goes via a SMTP-x400 gateway and when the x400 user receives it, he
sees my unix account in his return-path (perhaps because my program
generated the email although I set the From: field to be user I want).
I have also tried the -f flag for sendmail but that does not work either.
(However, I have not tried a 'Return-path:' field from my program
in the email).
Looks like the sendmail is appending this field itself using my
login-account since the program runs as me.

I am not sure if it the gateway or my host where the problem lies. Most
likely my sendmail is doing it because how the gateway will know whose
account the mail is coming from.

How do I avoid it. ANy pointers ?
Thanks

Atiq.

--
----------------
Atiq Hashmi

2. Setting VGA mode in LILO.conf

3. Question: getcwd returns different paths...

4. Identifying motherboard

5. Same path pointing to different locations in different sessions?

6. Unusual Paritions are Mounted

7. diff -r return different results on different runs using DMA

8. Header mangling Solaris rmail

9. echo path shows different path

10. Force "includes" for certain paths in Apache (?)

11. Multiple SCSI cards, force different scanning order?

12. add in the PATH a path if not present in the PATH

13. forced browse path - solutions?