Re: [foxboro] File Transfer
- From: "Stephen Wostal" <stephen.wostal@xxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Tue, 7 Oct 2008 17:49:49 -0500
From a security "best practices" perspective, I just thought I'd toss in
that we would generally recommend pulling >from< the DCS, rather than
pushing >to< the DCS. It's a minor nit, but if you were to isolate the DCS
using a firewall (recommended), the pull from the DCS would be much more
secure than allowing inbound connections sourced from the outside.
And if you were really, really focused on security (read: security nerd),
you'd digitally sign the file somehow so someone couldn't sneak in a rogue
file. The lock mechanism discussed below would also help - some way to
ensure the integrity of the file prior to use in the DCS.
Just my $0.02,
-- Steve
Stephen Wostal
Ensuren Corporation
(720) 256-5709
stephen.wostal@xxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of stan
Sent: Tuesday, October 07, 2008 4:22 PM
To: Johnson, Alex P (IPS)
Cc: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] File Transfer
On Tue, Oct 07, 2008 at 04:56:12PM -0400, Johnson, Alex P (IPS) wrote:
> My two cents.
>
> The application that creates the file should move it and signal that the
> move is complete. On many projects, I've used ftp to move the file and
> rsh to run the application that processes the file. This combination
> ensures that the file is fully transferred before processing begins.
>
> Failing that, I will monitor the 'modification date' on the transferred
> file and wait some period after that date before processing the file.
>
>
I agree with Alex on his points. But in practice I have run into a scenario
where we did not have control of the application on the Windows side. So,
what I did was have the DCS side transfer the file, and the Windows side
delete the file after it had processed it. At least I could check (using
ftp) for the existence of the file, and not transfer a new on if the Windows
app has died. I admit it's not an elegant solution, since I have no control
over the Windows side trying to "consume" an incomplete file, since ftp is
not atomic. My original design had their side checking for a lock file, that
I would have transfered _after_ the data file, and them then deleting this
lock file when they were done consuming the data, but it did not get
implemented that way, unfortunately.
--
One of the main causes of the fall of the roman empire was that, lacking
zero, they had no way to indicate successful termination of their C
programs.
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
