More ftp problems

[Ronelle van Niekerk]

We have a file coming in from the mainframe (working at a government department - what else can you expect?) everyday but it comes in with the wrong file permissions.
In order to rectify this I have inerted this line into the /etc/ftpd/ftpaccess file:
upload /user/home/dir /dir/to/upload yes username group 037

I have also changed the ftp line in the /etc/inetd.conf file as such:
ftp stream tcp nowait root /usr/lbin/ftpd ftpd -a -u007 -t7200 -l
(because we want all the other users to keep their permissions and timeouts.

Yesterday I tested this out on the test box and it worked fine but the production box is not working as well. When they try to transfer the file they get this error after about 10 minutes:
The control port connection is lost.

If I just take out the -a option in the inetd.config file and reconfigure the daemon (inetd -c) they can transfer the file without problems but also without the correct permissions.

What am I doing wrong?


-Ronell

[Steven E. Protter]

I think your approach should be different.

It seems that the operators of the mainframe are not careful what permissions they put on the file.

Fortuneately you have a servant, root cron that can change anything you need, including permissions.

If the file comes in at a fixed time, have root cron change the permissions a few minutes later to what they should be.

I didn't see your original post, but I've had these issues before and sometimes messing with the ftp server and inetd.conf is simply too time consuming for me.

SEP

[Ronelle van Niekerk]

I did think of this but unfortunately the files (just found out there is more than one) are not transferred at the same time every day.

They say there is no real pattern to it.

They also say that they can't set the permissions on the file before sending it.

I had this working on the test system but from my PC, not the mainframe.

[Con O'Kelly]

Hi Ronell

If you're sure these problems only occur when you enable use of ftpaccess with -a then the only thing I can think is that the timeout value being given to the ftpd daemon is being overridden by the ftpaccess file.

I have seen a timeout values being set in the ftpaccess file before, though I don't see it listed on HP-UX's man page for ftpaccess.

Might be something to investigate.

Cheers
Con

[Massimo Bianchi]

Hi,
can you post the file ftpaccess for a check ?


I'm also thinking that, since in test environt worked, there may be some difference between test and prod... patch level ?

How did you manage the test, the from and to hosts where the same, as in prod (mainframe --> hpux ) ?

If the connection is dropped, in the syslog you should have some warning. Is there anything interesting there ?

Is there any relevat time difference between mainframe and hpux ?

Massimo

[Ronelle van Niekerk]

Con,
I'll look into that. But the seission doesn't jsut timeout, nothing is transferred in the 10 minutes.

Massimo,
The test and production environments are slightly different but the base operating system is the same.
As I mentioned, I was testing from my PC to the tst box, not from the mainframe. I can't do that becasue it would mean getting the mainframe team involved in trying to ftp to the test machine and it's all too much really.
The syslog only shows that there was a connection from the mainframe but no FTP LOGIN.

The user's home directory and the directory they're uploading to are in no way related - would this be a problem

[Dave La Mar]

Ronell -
Let's start with the file coming from the "mainframe". In two of the more popular TCPIP clients used in the "IBM mainframe" world, permissions are not set in any config file or passed in the ftp job. Routinely, the permissions on a file sent are found to be that of rw by the user and group of the user that is in the ftp login session. I believe you are on the right track with the access file. Is the ftp user, the "mainframe" guy's are using, a common user on your HP-UX box?

Best of luck.

Regards,

dl

[Ronelle van Niekerk]

Dave,

No, the user was set up specifically for the ftp'ing of these files from the mainframe.

And you're right, the guys say that they have no control over the permissions of the file.

-Ronelle

[Dave La Mar]

Ronell -
Since I administer bot the HP-UX and "mainframe" side, I could run some tests here to duplicate your problem. What are the current permissions the files are coming in with and what do you want tem to be?

Regards,

dl

[Dave La Mar]

Ronell -
One last question before I leave for the day. The user that is logging in from the mainframe has what permissions to the directory being put to?

Hang in there. We'll (the forums) will get your answer.

dl

[Ronelle van Niekerk]

Dave,

They're currently coming in with -rw-rw---- and we want them to be -rw-r-----

The user's group has rwx premissions to the directory.

-Ronelle

[Tim Adamson_1]

Hi Ronell,

Have you considered implementing ACLs on the directory on the UNIX server? Maybe you can work around the problem using ACLs.

Just an idea.


Cheers!

[Ronelle van Niekerk]

Tim,

Aren't acl's for use on specific files?
Unfortunately the files they ftp will have a different name every day - or more than once a day.

[Ron Kinner]

How about putting this ftp user into a group all by themselves? Then nobody but root can read it until a cron file looks at the directory (every 5 minutes or whatever), finds a new file and moves it to a different directory while changing owner/group/permisions.

Ron

[Ronelle van Niekerk]

Ron,

A good idea but not very neat - especially considering the fact that there may be more than one file a day, the files don't all go to the same directory and the filenames are not always the same.

ftpaccess just seems like the easiest, most streamlined solution. I just wish I could get itto work on the production system.

[Tim Adamson_1]

Hi Ronelle,

Does the Unix server have multiple network cards? If so, does the same problem occur on different lan interfaces? I wonder if it is more related to the lan card (patching).

Seems like you may need to go through a process of elimination - ugghh!


Cheers!

[Ronelle van Niekerk]

Tim,

ugghh! is right.

This server has only one network card.

[Ron Kinner]

Your ftpaccess line:
"upload /user/home/dir /dir/to/upload yes username group 037"

037 is a bad value per my 11.0 man file. The examples they give use 0666 and 0600 (permissions and not mask). Perhaps that is why it doesn't want to work?

Ron

[Seth Parker]

Ronell,

This is the kind of thing that drives one crazy! It all looks like it should work.

Hmmm...

Was the -a option in inetd.conf previously? If not, then the ftpaccess file wasn't being used before. Maybe there's a problem someplace else in the file that's preventing transfers somehow. Can you post it?

Also, I noticed in the man page for ftpaccess that it's not a mask in the upload command, but a mode. So a rw-r-- mode should be 0640, not 037.

Good luck!
Seth

[Wouter Jagers]

I always try and make sure on filesystem level, by giving the directory 02xxx permissions (for example 02750).

When files are created in that directory, they should be owned by the group which owns the directory.

[Ronelle van Niekerk]

Wouter,

A good idea but the problem is that we don't want the group to be able to write to the files - the group permissions on the files are coming in as rw.

btw: are you from South Africa?

[Dave La Mar]

Ronell -
Sorry I am so late getting back to this.
I changed our inetd.conf entry for umask to
ftp stream tcp nowait root /usr/lbin/ftpd ftpd -l -a -u1000

This provided the requested result of rw-r-----
as you mentioned. Unfortunately, I believe this will be the same for all ftp jobs. Not sure this is what you really want. I tried diffrent user id's from our mainframe and all put files with the above permissions.
One thing to note in my testing, if the file already existed and was overwritten, previous files permissions did not change.

Best of luck. Let me know where you are on this problem.

Best regards,

dl

[Ronelle van Niekerk]

Ron/Seth,
Thanks guys - I changed that.
Unfortunately it doesn't solve the problem.

Dave,
Thanks for trying but we already have the -u option set for our users.
Unfortunately the files being transferred need different permissions to what our other users need.

-Ronelle

[Dave La Mar]

Ronell -
I hate not getting this resolved. I my testing I noted use of the the ftpaccess file for user permissions as you first stated. A man of this seems to infer that one can set permissions by directory and user. I'll follow up, but during testing, I tried making changes there without changing inetd.conf and failed to have any success. That is why I went back to the inetd.conf.

Best regards,

dl

[Seth Parker]

Ronnell,

I hate to ask such a seemingly obvious question, but does the mainframe have permission to connect to ftpd set up in ftpaccess?

I was doing a GSP upgrade the other day and couldn't transfer the files. It took me a while to realize that I hadn't put the address for the GSP interface in the class section of ftpaccess. Once I put it in, everything worked well and that made up for me feeling silly.

That could explain why removing the -a in inetd.conf allows it to work. Just another thought...

Regards,
Seth