> Say we had Unix users (developers really) that needed to deploy plsql
> code to an Oracle DB on a remote HP-UX box. But these users would not
[quoted text clipped - 6 lines]
>
> How exactly would passwords be secured?
by using "sudo", "scp" & "ssh".
jason@cyberpine.com - 29 Jun 2005 16:15 GMT
How would you respond to the claim that these products are not entirely
secure or entirely support by the Hardware vendor as delivered
products?
What would you say about a shop that had over a dozen networked midsize
distributated unix server that refused to run these products for
security reasons? Can the products be secured?
We are being told that a more secure design would have cron processes
running on each side with a time delay. :)
IANAL_VISTA - 29 Jun 2005 16:28 GMT
> How would you respond to the claim that these products are not entirely
> secure or entirely support by the Hardware vendor as delivered
> products?
Claims & counter claims without any supporting factual evidence
are not worth the electrons that comprise them.
> What would you say about a shop that had over a dozen networked midsize
> distributated unix server that refused to run these products for
> security reasons? Can the products be secured?
Paranoia runs deep.
> We are being told that a more secure design would have cron processes
> running on each side with a time delay. :)
This statement is empty of substance.
You still need a way to transfer data from one box to another
across an insecure wire.
For the totally paranoid "Network security" is an oxymoron.
You're On Your Own (YOYO)!
DA Morgan - 29 Jun 2005 20:08 GMT
> How would you respond to the claim that these products are not entirely
> secure or entirely support by the Hardware vendor as delivered
[quoted text clipped - 6 lines]
> We are being told that a more secure design would have cron processes
> running on each side with a time delay. :)
I'd say copy to one or more 400GB hard disks.
Hire Brinks and an armoured car with police guard.
Drive the disks to the new location.
Copy the information off the disks.
Following transfer smash the disks with a sledge hammer and then send
them swimming with the fishes off a tuna trawler in the mid-Atlantic.

Signature
Daniel A. Morgan
http://www.psoug.org
damorgan@x.washington.edu
(replace x with u to respond)
> Say we had Unix users (developers really) that needed to deploy plsql
> code to an Oracle DB on a remote HP-UX box. But these users would not
[quoted text clipped - 8 lines]
>
> Thanks for any help or information.
Jason, how static are the schema's that this plsql code is going to be
deployed into?
If you don't need to be able to "dynamically" have different schema's
execute different plsql scripts, then there are a couple of ways that I
can think of doing this.
Many organizations require some kind of change control group to move
code around and to deploy it. That way you create a change control
record, follow procedures, get your change approved, prepare
scripts/etc, have them reviewed, get the change scheduled, etc.
If you bypass these kinds of controls (not necessarily recommended)
then one way would be to put scripts into a directory on the local
server, have a script that ftp's them to the remote, have a cron job on
the remote job install the scripts.
Is that what you are talking about?
Sure that kind of setup is not hard to do at all. Do you have specific
questions about that kind of approach?
jason@cyberpine.com - 30 Jun 2005 22:10 GMT
See responses below following:
> Jason, how static are the schema's that this plsql code is going to be
> deployed into?
[quoted text clipped - 12 lines]
> server, have a script that ftp's them to the remote, have a cron job on
> the remote job install the scripts.
Answer: Problem is it's a 24x7 shop with no night time Administration.
The current VC design calls for developer driven deployment - all we
want to do is log the change in CVS
> Is that what you are talking about?
>
> Sure that kind of setup is not hard to do at all. Do you have specific
> questions about that kind of approach?
Answer: I understand the cron design, the problem is CVS appears to
require that the authenticated user check the code back up to the CVS
repository. Also, CVS needs files in the users working CVS project
directory. While I'm sure it could be coded where the script is cronned
to run as the user (on each request) and pathed to their working
directory, it seems kinda messy (too many independent parts). Also
there's the issue of error handling and the fear that the schema and
CVS repository will fall out of sync resulting in old or bad code
getting checked out. The easy design appears to be a real-time script
using SSH and Sudo that confirms a good compile/deployment before
updating CVS - in real time performed by the user.
Most Ux shops seem to be running SSH and SUDO, and this just appears to
be the logical choice here, but I have to fight with the powers that
be.
Thanks for the feedback.