Who should have the server passwords

[upinflamezzz]

I'm the IT Administrator and one of our servers is a Linux server that runs the software the my company runs on. This server is a managed server by the company that supports the software. I had to sign an agreement that stated they aren't liable if someone from my company goes into the server and messes something up. We're having problem with some processes freezing up that I kill when this happens. One of the owners knows the password as well. My new Operations Manager is asking for the password and procedure to kill these processes if I or the owner is not available. I told him to call the company that supports the server and software if this should happen. Am I in the right for refusing to give him the password and procedure? I've been in IT for quite a while and I've never had anyone in Operations ask me for passwords to servers.

 

[2ffat]

Better safe than sorry when it comes to passwords.


James P. Cottingham
I'm number 1,229!
I'm number 1,229!

 

[upinflamezzz]

Does an Operations Manager even outrank a System Administrator? I looked on Glassdoor and the salary for an Operations Manager is lower than a System Administrator.

 

[feherke]

Hi

I do not see how this is an IoT issue, so will answer from the Linux point of view.

If killing the runaway process can be automated, then write a script to do it. Add the killer script to the /etc/shells file. Create a new user and in the /etc/passwd file configure the killer script as the user's default shell. Then on every login attempt as the given user, the runaway processes will be killed. As no actual shell access will be granted, you can give that user's password to the Operation Manager too.

Otherwise I agree, you better refuse such password requests.


Feherke.
feherke.github.io

 

[IPGuru]

You should certainly ask for that request to come from who ever it is in the organisation that you report to.

form ther in in I bow to Feherke , in his sugestion that you create a dedicated user for this ops manager & ensure that his permissions are such that it is only the restart scriot that they can run.
wether this is automatic when they log in or a 2 stage process to minimise any accidental restarts is something you needd to asssess for yorself



Do things on the cheap & it will cost you dear

Avaya Remote Support Engineer (A.R.S.E)

 

[SamBones]

This is a political question, not a technical question.

I like feherke's solution, but IPGuru is right on the money too. If you do come up with a solution to kill a rogue process, then you should also get buy in from both your management, AND the vendor so you don't invalidate your support contract. Especially if this is a mission critical, or business critical app.

In general you should never give out passwords to anyone not directly involved with supporting the application. The management person you give a password to may have different standards than you, as to who might need to know the password.

 

[GriffMG]

Why would you ask that question here?

I would not.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[upinflamezzz]

Are you triggered? Do you need a safe space to run to?

 

[GriffMG]

Probably

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[SamBones]

I'm triggered by my alarm clock every morning. It sets the tone for the entire day.

 

[upinflamezzz]

But you're a programmer. Why not just program yourself to wake up when you need to?

 

[GriffMG]

He doesn't know the API for that.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​