perl script - chown within/after ftp?

[so.nimda]

Hi,

I have written a perl script to ftp a file from a Windows XP PC to a HP-UX server using the Net:FTP module.

The ftp part is working fine but I need to 'chown' the file once it is ftp-ed over in the UX directory.

How can it be done?

This is how the script looks like :

use Net::FTP;
$ftpobj = Net::FTP -> new ("myserver");
$ftpobj -> login("id","password");
$ftpobj -> cwd ("/home/temp");
$ftpobj -> ascii;
$ftpobj -> put (myfile);
$ftpobj -> quit;

I don't think its possible within the ftp command - "$ftpobj -> chown (id, group, filename)" doesn't work.

Do I have to separately (within the script) do a 'telnet' and then 'chown'?

Thanks !

[Steven Schweda]

> [...] a HP-UX server [...]

Not a very complete description of this
system.

> [...] I need to 'chown' [...]

Why? Who owns the files now, and whom would
you like to own them?

The FTP server on my HP-UX 11.31 system seems
to offer a "SITE CHMOD" command, but "chown"
typically requires some unusual privilege, so
I wouldn't expect an FTP server to offer it.

> [...] do a 'telnet' and then 'chown'?

And as whom were you planning to log in to do
that job? (You want to put _which_ password
into this script?) Even rsh/remsh can offer
better security than a password embedded in
a script. Ssh could be safer than rsh/remsh
for executing a remote command, but if you
give some user the power to do chown, what
else have you made possible?

If you care not at all about security, then
tasks like this get easier.

[so.nimda]

Hi Steven,

Thanks for the reply.

It's actually a UX 11v23 test system that I'm playing with so security is not a concern for now.

There's a series of steps that I'm trying to automate whereby I :

1) ftp a file from my PC to the UX server using root
2) login as root and chown the file to a specific user

The easiest way will be to ftp using that user but unfortunately, no one can remember the password and the file is used by an application running under that user ID - so the need for the chown.

The chown is pretty straight forward, e.g. chown user:ugroup filename

Nothing fancy and no need for any unusual privileges.

Hope this clarifies.

Thanks

[izad · Accepted solution]

Hi,

Not clear why you want to run chown, however if you want to do that anyway, you can use the Net::Telnet module within your perl script so that it does the 'chown' after the file is succesfully transferred.

use Net::Telnet;
$telnet = new Net::Telnet ( Timeout=>10, Errmode=>'die' Prompt => '/\$ $/i'); $telnet->open('host or IP'); $telnet->login('username', 'passwd'); print $telnet->cmd('chown usr:grp /path/to/file');

hth

regards,

[James R. Ferguson]

Hi:

> The easiest way will be to ftp using that user but unfortunately, no one can remember the password and the file is used by an application running under that user ID - so the need for the chown.

Why don't you (as 'root') change the password of the target user to something you know and then do your FTP as that user?

You could also use SFTP (I suggest Perl's 'Net::SFTP::Foreign' module) having setup public keys in lieu of hardcoding cleartext passwords.

Regards!

...JRF...

[Steven Schweda]

> Why don't you (as 'root') change the
> password [...]?

Especially considering:

> It's actually a UX 11v23 test system that
> I'm playing with so security is not a
> concern for now.

Sometimes the easy way really is the easy
way.

[so.nimda]

Thanks for all your replies.

Using root to change the password of the target user is indeed a good
solution but my fear is that once changed, things may not work (either due
to configuration, hardcoding, etc ) - that's why I'm hesitant to go that way.

Thanks again for all the help and suggestions.

[Viktor Balogh]

if the perl script runs on the HP-UX side, you could make it simply by

system("chown user:ugroup filename");
with the root user

or

system("sudo chown user:ugroup filename");
and by grating passwordless sudo to the user executing the perl script

[Dennis Handly]

>but my fear is that once changed, things may not work (either due to configuration, hardcoding, etc) - that's why I'm hesitant to go that way.

Simply save the old passwd entry and if problems, you can always put it back.

[so.nimda]

Thanks Viktor & Dennis for your replies.