Very Computer

HELP - IS ANYONE RUNNING PCNFS UNDER UCX/AXP 3.1 ???

I posted a proiblem with PCNFS the other day. One reply suggested that I should
upgrade UCX3.1 (AXP) with the latest and greatest ECO (4). I have done so, but
I still can't get PCNFS to work. Here are the OPCOM messages when the first
client tries to log in:

%%%%%%%%%%%  OPCOM  21-OCT-1994 11:22:09.59  %%%%%%%%%%%
Message from user INTERnet on KLRVAX
INTERnet ACP Process creation success

%%%%%%%%%%%  OPCOM  21-OCT-1994 11:22:09.60  %%%%%%%%%%%
Message from user INTERnet on KLRVAX
INTERnet ACP PORTMAPPER Accept Request from Host: 130.225.149.118  Port: 673

%%%%%%%%%%%  OPCOM  21-OCT-1994 11:22:10.43  %%%%%%%%%%%
Message from user INTERnet on KLRVAX
INTERnet ACP Process creation success

%%%%%%%%%%%  OPCOM  21-OCT-1994 11:22:10.43  %%%%%%%%%%%
Message from user INTERnet on KLRVAX
INTERnet ACP PCNFS Accept Request from Host: 130.225.149.118  Port: 674

That looks quite sensible. Unfortunately, nothing else works.

The client (InterDrive from FTP software, works fine with PCNFS daemons on
various Unix boxes) sends the username BXF103, which is a valid one. It has a
proxy record:

UCX> show proxy
VMS User_name     Type      User_ID    Group_ID   Host_name
BXF103            ONCD            0           0   bear
                         BXF103

because the OLD tells you to do have one. I have no idea why. I mean, this is
PCNFS, not NFS, so a USERNAME is sent - not a UID/GID pair. The host name
"bear" is obviously the one with the IP number listed in the OPCOM messages.
Changing to fully qualified domain name does nothing. There are no OPCOM
messages of any kind complaining about missing proxies, or faulty passwords
even though the client reports an "ERROR: Authetication refused". To ensure
that the two were actually talking to each other, I killed the UCX$PCNFSD and
UCX$PORTM processes by hand, which resulted in an "ERROR: Authetication server
failed to respond" message. What does worry me is the fact that I still get the
"Authentication refused" error if I disable the PCNFS service. A SHOW PROC/CONT
on the UCX$PCNFSD process shows 10 buffered I/Os and 00.02 cpu time clicks per
attempt to authenticate from the client - regardless of the status of the PCNFS
service!

The directory I want to mount on the PC is bound and exported OK (I can NFS
mount it on a unix box).

PLEASE. Is there ANYONE out there, who has managed to get PCNFS to work ? ANY
hint would be appreciated! Especially a step-by-step instruction...

Cheers

Bernhard
--------------------------------------------------------------------------------
Bernhard Fabricius
Computer Jack-Of-All-Trades, Institute of Physics
Odense University, Odense, DENMARK

--------------------------------------------------------------------------------
****IF ULTRIX IS THE ANSWER THEN IT MUST HAVE BEEN A *Y STUPID QUESTION!****
--------------------------------------------------------------------------------

I tried briefly last week without success and went on with other things. Thanks
to you, I think I will wait or think of something else to do the job, which is
printing from PCs running PC/TCP. LPR does not work, I was going to try PC-NFS.

I'd be better to buy them a printer each ;-)

Alain Martineau

Hi Alain,

   don't give in. I just managed to get the thing to work! Various friendly
people suggested that my proxies might be wrong, or certain services not
enabled. However, the solution is the following:

1) You cannot EXPORT sub-directories. Always EXPORT the entire
   system that you have made available with BIND. The PCNFS server
   will take care that users can't see things that they're not
   supposed to see, so they might as well just IMPORT their own
   subdirectory (which the PCNFS server is happy to let them do).
   This "feature" is NOT documented. And indeed, you can EXPORT
   subdirectories via NFS, but not via PCNFS

2) Watch out for pre-expired passwords, ie accounts that have
   been given a password with AUTHORIZE without the /NOPWDEXP flag.
   Even though the account works interactively - and don't ask
   for a password change - PCNFSD will refuse to authenticate it.
   This is certainly a bug.

My services were all enabled - indeed, I could see the PCNFSD process doing
things every time I tried to connect, but it was not until I exported the
entire tree and used a different account (with an often-changed password)
that things suddenly started to work! You do NOT need a GID/UID -2/-2 proxy
for PCNFS, but you must have one for NFS! Also, the UCX HELP examples on
proxies are WRONG. Example 1 is plain WRONG. You cannot have a * for UID
or GID. We are almost back to the bad old days of UCX V2.0 plain-vanilla,
were the ONLY "quality control" was a test if the things would VMSINSTAL.
It would. It couldn't do anything, though... DEC, get you act together!

Now the thing works like a charm. Well, nearly. Certain DOS file names will
make the PCNFS daemon puke. This happens if they include non-VMS file name
characters, like {}!# and high-bit characters. Most annoying if you try to
do a "backup" with XCOPY. The XCOPY simply stops without any information.
You can start over again (the connection doesn't go away), but you are not
told, just what is wrong. You must do a TREE of the disk first, FIND the
potential troublemakers and rename them.

Another annoying "feature" is the fact that I couldn't make a "common"
area that everyone had access to. Even though I set W:RWED on the directory
(NO, I don't do that very often...), which obviously let interactive VMS users
read, write and delete to their heart's content, PCNFSD refused to let the
PC clients do the same. Strange.

But anyway, I'm a big step further down the road (away from dismissal...)

Cheers

Bernhard
--------------------------------------------------------------------------------
Bernhard Fabricius
Computer Jack-Of-All-Trades, Institute of Physics
Odense University, Odense, DENMARK

--------------------------------------------------------------------------------
****IF ULTRIX IS THE ANSWER THEN IT MUST HAVE BEEN A *Y STUPID QUESTION!****
--------------------------------------------------------------------------------

There is no problem with UCX EXPORTing subdirectories to a PCNFS
client.  At least I've never had any problem.  Perhaps you
changed something else that solved your problem, for example
adding your PC host to the EXPORT record or changing it to
/HOST=* ?

Quote:>>2) Watch out for pre-expired passwords, ie accounts that have
>>   been given a password with AUTHORIZE without the /NOPWDEXP flag.
>>   Even though the account works interactively - and don't ask
>>   for a password change - PCNFSD will refuse to authenticate it.
>>   This is certainly a bug.

I'd say it's arguable whether this is a bug.  If the account
password is expired, it does not work for new interactive logins.
I believe it does work for resuming a paused DECwindows session.

Quote:>>Also, the UCX HELP examples on
>>proxies are WRONG. Example 1 is plain WRONG. You cannot have a * for UID
>>or GID.

This is corrected in the V3.2 documentation and help.

Quote:>>Now the thing works like a charm. Well, nearly. Certain DOS file names will
>>make the PCNFS daemon puke. This happens if they include non-VMS file name
>>characters, like {}!# and high-bit characters.

If a PC user needs a container file system as the UCX EXPORTed
directory, he or she should use a container file system, just
like a UNIX user.

Quote:>>Another annoying "feature" is the fact that I couldn't make a "common"
>>area that everyone had access to. Even though I set W:RWED on the directory
>>(NO, I don't do that very often...), which obviously let interactive VMS users
>>read, write and delete to their heart's content, PCNFSD refused to let the
>>PC clients do the same. Strange.

I don't have any trouble doing this.  The only explanation I can
think of would be that the directory has an ACL denying access to
the proxy account your PC is using.

Julie

->

->
->>>2) Watch out for pre-expired passwords, ie accounts that have
->>>   been given a password with AUTHORIZE without the /NOPWDEXP flag.
->>>   Even though the account works interactively - and don't ask
->>>   for a password change - PCNFSD will refuse to authenticate it.
->>>   This is certainly a bug.
->
->I'd say it's arguable whether this is a bug.  If the account
->password is expired, it does not work for new interactive logins.
->I believe it does work for resuming a paused DECwindows session.

The AUTHORIZE utility docs clearly state that unless PWDLIFETIME is defined, the
pre-expired condition of passwords is ignored (see Table AUTH-2).  We do not use
PWDLIFETIME and nearly all our passwords work for any kind of login, even though
many are still flagged as pre-expired.  However, UCX isn't the only product with
a problem in this regard.  Wollongong's Pathway will not allow the R-series
commands to work if the password is pre-expired, regardless of the setting for
PWDLIFETIME.

-----------------------------+--------------------------------


 4141 Eastern Ave., MS129    | Hey, I said this stuff myself.
 Grand Rapids, MI 49518-8727 | My company has no part in it.
-----------------------------+--------------------------------