topic Re: .netrc file not been used in Operating System - Linux

.netrc file not been used

John Waller — Tue, 16 Oct 2007 05:18:06 GMT

I've come across a problem when calling ftp from within a cobol program.
I've created a .netrc file which lives in the home directory and when I issue an ftp -iv from the command line as the user which runs the cobol programme it works fine, but when the same command is called from within the program it doesn't appear to be reading the .netrc file.
e.g

Details of .netrc

machine 172.19.1.210 login wmsftp password notshown macdef init
cd goc
lcd /opus/test/interface/out/goc/send
mput *.DTS
close
quit

Output from a debug log taken within the cobol program

Thu Oct 11 11:48:06 BST 2007
Connected to 172.19.1.210.
220 ALPHA1.xxxxxxx.co.uk FTP Server (Version 5.4) Ready.
Name (172.19.1.210:testsys): 331 Username testsys requires a Password
530 Login incorrect.
Remote system type is VMS.
425 Session is disconnected.

The cobol program is being run by the user ID testsys.

As a matter of interest, the same procedure does work at a second site which is sending to an iSeries.

Re: .netrc file not been used

Fat Scrape — Tue, 16 Oct 2007 05:48:32 GMT

Hi John,

Is the owner of the program the same user in which home_dir the file .netrc is created?

Fat

Re: .netrc file not been used

Fat Scrape — Tue, 16 Oct 2007 05:51:05 GMT

Hi John,

and .netrc permission must be 600

Fat

Re: .netrc file not been used

John Waller — Tue, 16 Oct 2007 06:06:45 GMT

Hi,

Yes the .netrc file is in the home directory of the user testsys with permissions of 600. I don't believe I have a problem with the .netrc file itself as it works when I run the ftp from the command line.

e.g
/home/testsys>> ftp -iv 172.19.1.210
Connected to 172.19.1.210.
220 ALPHA1.xxxxxxx.co.uk FTP Server (Version 5.4) Ready.
331 Username wmsftp requires a Password
230 User logged in.
cd goc
250-CWD command successful.
250 New default directory is DISK$IANTEST1:[PITH.OPUS.DATA.GOC]
lcd /opus/test/interface/out/goc/send
Local directory now /opus/test/interface/out/goc/send
mput *.DTS
local: 0439369.DTS remote: 0439369.DTS
200 PORT command successful.
150 Opening data connection for DISK$IANTEST1:[PITH.OPUS.DATA.GOC]0439369.DTS; (
172.19.1.233,53401)
226 Transfer complete.
994 bytes sent in 0.00 seconds (3042.96 Kbytes/s)
local: 0439370.DTS remote: 0439370.DTS
200 PORT command successful.
150 Opening data connection for DISK$IANTEST1:[PITH.OPUS.DATA.GOC]0439370.DTS; (
172.19.1.233,53402)
226 Transfer complete.
994 bytes sent in 0.00 seconds (205.31 Kbytes/s)
close
221 Goodbye.
quit
/home/testsys>>

Regards

Re: .netrc file not been used

Fat Scrape — Tue, 16 Oct 2007 06:26:01 GMT

Hi John,

look the error display from script:

Name (172.19.1.210:testsys): 331 Username testsys requires a Password

testsys ???

but in your .netrc file the login name is wmsftp.

I suggest to debug the cobol script to know if the .netrc file is loaded during ftp session.

Fat

Re: .netrc file not been used

Fat Scrape — Tue, 16 Oct 2007 07:56:19 GMT

Hi John,

sorry for my stupid previous suggestion.

But I think to another stupid question

Is it possible that, during cobol program execution, some environment variabile are modified or unset?

These type of errors happen generally when env vars are unset.

Fat

Re: .netrc file not been used

John Waller — Tue, 16 Oct 2007 08:08:46 GMT

Hi,

With regards to variables being unset, that was my line of thought which is why I've posted this thread to see if anybody has come across a similar situation. To my understanding, ftp will always check for the existance of a $HOME/.netrc file. I believe the $HOME variable is OK as that is where we wrote the debug file and it's a different directory to where the cobol program which is called is located, so I presume that is OK.

Re: .netrc file not been used

OldSchool — Tue, 16 Oct 2007 09:29:27 GMT

Are you running the cobol program from the command line or via cron?

Do the permissions on the cobol executable indicate its running suid (perhaps not the user you think it is)?

Re: .netrc file not been used

Fat Scrape — Tue, 16 Oct 2007 09:43:05 GMT

Hi John,

Sorry but I don't agree with you.

Ftp command don't check the existens of $HOME/.netrc, but ftp use it only if $HOME/.netrc exist.

No error is displayed if the file $HOME/.netrc isn't found.

Fat

Re: .netrc file not been used

John Waller — Tue, 16 Oct 2007 09:55:46 GMT

The cobol program is actually part of a full application written in cobol so it is called by another program within the application itself. Everything related to the application is being run as the user testsys, which is probably why when it fails the debug file is showing it attempting to login as testsys instead of the wmsftp user.

Fat, I probably didn't explain myself correctly with regards to the use of a .netrc file within ftp sorry about the confusion. Though ftp doesn't check for the existance as you've pointed out it should use it if it exists and has the correct permissions i.e -r-------- . I've checked the sytem and the cobol rts doesn't have a SUID set. Again if it did I would have expected to see it attempt to login to the remote server as a different user e.g root and not testsys.

Re: .netrc file not been used

OldSchool — Tue, 16 Oct 2007 10:39:24 GMT

you don't accidently have the "-n" switch in your ftp command in the cobol program perhaps?

if not, then I'm at a loss....I have apps that do this all the time (not cobol, but that shouldn't matter)

Re: .netrc file not been used

John Waller — Tue, 16 Oct 2007 10:58:05 GMT

Nice try with the -n switch but no, I've checked the source code and it only runs a ftp -iv ip_address.

Re: .netrc file not been used

Fat Scrape — Wed, 17 Oct 2007 06:32:11 GMT

Hi John,

In my experience this type of problem is always caused by some env. vars unset.

I don't understand if you are sure (or you debug the script) that $HOME var is set.

Could you try, if you want, to debug and verify if this var is set?

I created a script and I modified the path of variable $HOME, netrc file wasn't found. The same problem happens if I run the same script using switch user when "-" option is omitted, because, in this way, some variables ($HOME and other) aren't set.

You said that the cobol program is called by a full application. Problaby when this cobol program is called some vars aren't set, caused by a anomaly/bug in the code, that you solve opening a case

Regards,

Fat

Re: .netrc file not been used

John Waller — Thu, 18 Oct 2007 06:01:36 GMT

Hi,
Well I'm now totally confused. I've had the programmer make a change so he performs a touch on the .netrc file before trying the ftp and when the program runs it updates the time stamp on the .netrc file but still doesn't work. The next thing I'm going to ask him to try is to change the programmes so it also sets the "LOGNAME" parameter in case it is something to do with the UserID.

Re: .netrc file not been used

Fat Scrape — Mon, 22 Oct 2007 02:05:15 GMT

Hi John,

Which is the result of your tests?
Are HOME, LOGNAME and other parameters defined during ftp session called by COBOL application?

Regards,

Fat

Re: .netrc file not been used

John Waller — Mon, 22 Oct 2007 02:20:31 GMT

Hi
Yes, by displaying the variables into a debug file everything appears to be set how I would expect them to be. In the end I've wrote a script which does the ftp.
e.g.

ftp -iv $1 <<-eof
user wmsftp notshown
cd /goc
lcd /opus/test/interface/out/goc/send
mput *.DTS
close
quit
eof

Then within the cobol program issue a call "sh /home/testsys/script $IP_address".

It's not ideal, but it works. I still don't understand why it doesn't work on this perticular machine but works on a number of others.

Re: .netrc file not been used

Steven Schweda — Mon, 22 Oct 2007 06:00:02 GMT

You've verified that the same "ftp" program
is being used in each case?

Re: .netrc file not been used

John Waller — Mon, 22 Oct 2007 08:12:03 GMT

Not exactly the same but we are using the standard hp-ux ftp in /usr/bin. On this machine with the problem I did notice there was an ftp program installed as part of perl so I renamed that to ensure it wasn't been picked up. The difference is that this server is PA-Risc 11.23. The working servers are either IA64 11.23 or PA-Risc 11.00,