Does anyone know how you would set up an automated nightly FTP job? I'm not
talking about setting up the cron job itself, but the actual FTP commands.
Whenever I try to do the FTP in a script, it always prompts for a password.
I want to be able to include this value in the script and allow the FTP
without any intervention.
Thanks in advance,
mike
option 1: use the .netrc file man netrc.
then ftp -i host < ftp.input
option 2: code the username and password on the first line of the ftp.input
file.
the first line would look like this user someuser someusers_password and
then the rest of the commands.
then ftp -in host < ftp.input.
Matt Reller
Chris
Mike Resnick wrote:
>
> Hi all...
>
> Does anyone know how you would set up an automated nightly FTP job? I'm not
> talking about setting up the cron job itself, but the actual FTP commands.
> Whenever I try to do the FTP in a script, it always prompts for a password.
> I want to be able to include this value in the script and allow the FTP
> without any intervention.
>
> Thanks in advance,
>
> mike
hi,
hope this example will help you.
notice that you get an return code to detect error and trap them .
#!/bin/sh
# getfile.sh 20/07/00 job
# --------------------------------------
# script to retrieve file on docu01 ftp
# and trigger process of the retrived file.
# ----------------------------------------
#
# GLOBAL vars.
#--------------
WATCHDOGfile=/tmp/eodftpwatchdog.log
FTP_LOG=/tmp/tbiemoget.log
PRINTER="LJ3SI"
stamp=`date '+%Y%m%d'`
# remove ftp log file
rm $FTP_LOG
#sub prg
#---------------------
ftp_()
{
ftp -v -n << eof >> $FTP_LOG
open $MACHINE
user $ID $PASS
ascii
$ACTION
bye
eof
# test ftp result and get a return code
#--------------------------------------
#echo "$TEST_STRING"
#--------------------------------------
if grep "$TEST_STRING" $FTP_LOG
then
return 0
else
return -1
fi
}
#---------------------
# setting for connect and retrieving file
#------------------------------------------
MACHINE=machinne name
PASS='xxxxxxxx'
ID='xxxxxxxx' # if remote box = NT password will be 'domain/password'
ACTION='mget tbiemo*'
# string to test for ftp completion in ftp function
TEST_STRING='226 Transfer complete'
# do ftp
if ftp_
then
ftpstat=OK
echo " file retrieved..."
else
ftpstat=KO
echo " file not retrieved for some obscure failure"
cat $FTP_LOG >> $WATCHDOGfile
echo " no file found on xxxxxx" >> $WATCHDOGfile
echo " or somthing wrong with ftp server" >>
$WATCHDOGfile
lp -d$PRINTER $WATCHDOGfile
exit 0
fi
# parameters setting for second connect
# delete retrieve file
ACTION='mdelete tbiemo*'
TEST_STRING='250 DELE command successful.'
if ftp_
then
ftpstat=OK
echo " file deleted ..."
else
ftpstat=KO
echo " file not deleted ?" >> $WATCHDOGfile
cat $FTP_LOG >> $WATCHDOGfile
exit 0
fi
# process retrieved file
# in case of error send message or fire up next process
if [ $ftpstat = OK ]
then
# normal processing.
echo " processing tbiemo.txt"
# start EDI process for EOD
# command ...:
# grab today's filename.
# file name must be tbiemo.txt
file=`ll tbiemo.txt.$stamp* | awk '{print $9}'`
if mv $file tbiemoftp.txt
then
echo $file " moved successfully"
else
echo $file " doesn't exist ? " >> $WATCHDOGfile
fi
# fire up EOD.sh
else
# error broadcast
echo " send a file to watchdog lp"
echo " ftp fas failled " >> $WATCHDOGfile
lp -d$PRINTER $WATCHDOGfile
fi
exit
Sent via Deja.com http://www.deja.com/
Before you buy.
And much less secure. It's not a good idea to put clear text passwords
in scripts if you can avoid it; however, hiding that one script is boat
loads safer than setting up a trust relationship when it's so easy to
avoid...
ftp -i -n << eof
open machine.domain.com
user ${user} ${password}
ascii
put /tmp/source_file /tmp/destination_file
quit
eof
chmod 600 the script and hide it in a root only read/execute directory...
Doug
--
-------------------
Douglas K. O'Leary
Senior System Admin
dkol...@mediaone.net
To use r commands requires that you be properly authenticated and logged in in one
machine
that is part of a cluster of machines. You have to see the cluster as one big
machine. Security and
authentication occurs when you enter the cluster. Once you're in you can issue
commands to and from
anywhere in the pool.
The pool is secure not the individual machines, you don't have passwords to accces
every disk in a
disk array the same goes here for an array of servers.
Chris
Then we've obviously worked in different places; setting up trust
relationships even as normal users is usually the cause for dismissal -
and is usually one of the first things in a security policy that's
prohibited.
Yes, clear text passwords are a big no-no and should be avoided if at all
possible. However, if you need to set up automated file transfers
between systems and, for some reason, nfs isn't an option, then opening
up one non-priviledged user is an order of magnitude more secure than
setting up a root level trust relationship.
For that matter, we can avoid the whole argument by simply going to ssh
and scp...
> To use r commands requires that you be properly authenticated and logged
> in in one machine
Or have adequately learned how to do IP spoofing; a topic which most
script kitties can now do without even understanding the concept.
> that is part of a cluster of machines. machine. Security and
> authentication occurs when you enter the cluster. Once you're in you can issue
> commands to and from anywhere in the pool.
I don't remember the original poster mentioning clusters. Since a true
cluster is generally seen as one machine, then you're right. However, if
he's moving files between systems that simply share a network cable, then
you're wrong.
> The pool is secure not the individual machines, you don't have passwords
> to acccesevery disk in a disk array the same goes here for an array of
> servers.
The set of systems in your case is only as secure as the weakest link.
As a security conscious sysadmin, you have to try and plug all security
holes - the bad guys just have to find one. If they find one on any
single machine with a root level trust relationship, then they have the
whole network. Call me crazy, but I think that's a bad idea...
$ man netrc
This is fairly secure as the permissions on the file must be 600. Of course any
file that has clear text passwords is a security breach. In some instances,
people use a script to create a new .netrc as needed.
Also, it depends what you're copying via FTP, if it's some sort of job
to maintain systems and keep a few files in step then you're probably
better off using rdist (running over SSH of course) or cfegnine or a
similar tool.
I agree with most of the previous comments about r-utilites and
putting password in files being a bad idea of course :-)
On Mon, 31 Jul 2000 11:08:11 -0400, Kirk Gardner <kirk_g...@hp.com>
wrote:
--------------------------------------------
home page : http://meltingpot.fortunecity.com/greenwood/630/
I expressly forbid the reposting of the message to any and all other forums