RE: RE: RE: Why forced to do the job the hard way?

If they don't trust you, why the heck did they hire you? Anyhow, they could have a policy of testing your scripts on a non-production server before moving them to the productions server. I do that even if I have root, and that method means I don't have to "trust" anybody... I can just test the script, and copy it over when I'm happy with it.

I don't see how having access to the server and wanting to test the scripts before they go production are related things.

Ozymandias: You are certainly correct, I only accept projects where I am in charge of IS, I wouldn't even consider working in it. But I won't work with people I'm not willing to trust.

Paris Sinclair    |    4a75737420416e6f74686572
pariss@efn.org    |    205065726c204861636b6572
I wear my Geek Code on my finger.

Comment on RE: RE: RE: Why forced to do the job the hard way?

Replies are listed 'Best First'.
RE: RE: RE: RE: Why forced to do the job the hard way? by Ozymandias (Hermit) on Jun 17, 2000 at 03:19 UTC
Thereby proving you've never worked in IS. The #1 rule in IS is "trust no one", particularly if it's a production system. The right way to do it is to develop on one system, test on a second, production is a third. Developers move freely between development and test. Test is kept as similar to the production system as possible. Only senior IS people - often only two admins per box, and one of those is just a backup - actually have access to move things from test to production. Anything less is too risky. The correct solution to the problem is to have IS install the needed module on the production system. They SHOULD do that, if you can show that it's necessary and safe. - Ozymandias	[reply]
RE: RE: RE: RE: Why forced to do the job the hard way? by BigJoe (Curate) on Jun 17, 2000 at 02:50 UTC
I work in a company of over 2000 users and the IS dept can't really assess each person. (I got put in a Tech support dept by a Consulting place, But that is another story). --Joe	[reply]