Reboot and Shutdown options to users

[Scott Painter_1]

Is there a way I can write a script (if I knew how) that would allow users to either reboot or shutdown the system without giving them rootly powers or using sudo?

[Christopher McCray_1]

create a file called /etc/shutdown.allow

edit the file and use the format

hostname username

Hope this helps

Chris

[PIYUSH D. PATEL]

Hi,

Create /etc/shutdown.allow and add the user name to it.

Piyush

[Jordan Bean]

man 1m shutdown

Use /etc/shutdown.allow

Works a little like /etc/hosts.allow

[harry d brown jr]

Scott,

Quite trusting in your users, eh?

follow the shutdown.allow advice, but not something I would do.

live free or die
harry

[A. Clay Stephenson · Accepted solution]

Wild horses couldn't make me do this; bear in mind that most UNIX boxes stay up for at least months on end (sometimes years); if you need to do periodic reboots the answer is to fix the software.

[harry d brown jr]

Clay,

what's a reboot?

# uptime
3:19pm up 227 days, ....


live free or die
harry

[harry d brown jr]

Clay,

what's a reboot?

# uptime
3:19pm up 227 days, ....

That's how long my vPars has been running!

live free or die
harry

[Scott Painter_1]

So I take it you all are saying that this is not a good idea even though it can be done? I just want to try and give them the option to do it if I'm not around without giving up any passwords. I'm cool, but not THAT cool.

[harry d brown jr]

Scott,

Do this:

Set up a "special" account that has the priv's of shutting down the system, via shutdown.allow.

Put the password to that account in a SEALED envelope, and staple it to a wall - that way if they use it, they will have to rip it open and off the wall.

Of course repeat by changing the password.

live free or die
harry

[A. Clay Stephenson]

YES, I am saying that this is almost certainly a dumb idea. 1) Well-behaved UNIX boxes do not require reboots. 2) How does Sally know that it is safe to shutdown now? Susie may be in the middle of her annual payroll runs. 3) When a system is dead, it's generally a good idea to
probe at that time so that the problem does not occur.

I might relent a little bit if the power is going to be off for an extended period but again well-designed UPS scripts should handle this as well.

[Christopher McCray_1]

Hello,

The main point made by Clay and Harry is a very good one. You don't necessarily need to reboot except for in cases of patrches an/or hardware issues/upgrades. It can be done where other users can use the shutdown command, but I would carefully choose your "rebooter" so you know that this won't be done too often and by just anyone, if you decide to take that route.

To Harry and Clay,

I wish I could keep my servers running as long as yours... I am forced to do a reboot almost monthly because the government "knows whats best for these servers"

Good luck

Chris

[Martin Johnson]

Harry,

I have a server thats been up for 761 days, and counting.


Marty

[Pete Randall]

Hi Scott,

For another viewpoint, consider this:

At this point, it's probably mostly a habit retained from the old days when our Informix database server leaked memory like a sieve, but we allow (actually require) our operations staff to re-boot the server first thing Monday morning. I set up a script, owned by the Informix user (so they have to know the closely guarded Informix password), and put the Informix user in /etc/shutdown.allow. You might ask why I don't just use cron to accomplish this myself. The reason is that we have a quarterly process that runs for days on end and we don't want to re-boot while that's going on. Being a basically lazy advocate of the Keep It Simple, Stupid methodolgy, I let the people who know when that process is running determine whether it's safe to re-boot or not.

I agree with Harry and Clay that this isn't for everyone and I *will* someday get around to finding out if it's even necessary anymore, but in the meantime, we've been operating this way, without problem, for 8 years. You really have to trust (and train) your operations staff.

For what it's worth,
Pete

[Pete Randall]

Oh, and, if you do decide to go with allowing someone else to do the re-boot, our script is attached. You can ignore the informix parts, they're just overkill (courtesy of my paranoid DBA) to make sure informix gets shutdown properly. It's pretty simple.

One last thing:
I didn't mean to scare you off from assigning points (from your other post). You can and should assign points.

Good luck,
Pete

[Scott Painter_1]

Clarification: I wasn't planning on giving people access to reboot the server, just their individual machines. Yesterday, I was trying to get internet connectivity up on the workstations and had to modify the /etc/rc.config.d/netconf file which after being done required each user to reboot their machines. I feel like a dictator having to do the reboot myself, but if that's the way the industry recommends I do it, then I will. I agree that I don't want to give the users too much ability to mess with the system that I'm trying to figure out. I'm sure I cause enough damage already!!! Thanks for all your input!

Pete: I'm not afraid to give points based on yesterday's discussion, but what is an acceptable amount of points to give to someone for providing an answer to a question that you haven't been able to try and implement yet? I surely don't want to insult anybody or keep them from wanting to help in the future.

Scott

[Pete Randall]

Scott,

Waiting is fine, I just thought I might have said something that made you think you shouldn't assign points.
When you're ready, just follow the guidelines on the "assign points" page.

And - enjoy your dictatorship!

;^)

Pete

[A. Clay Stephenson]

Scott:

Even for workstations, I would not give the users the ability to reboot. They can always call you and you can do it remotely. Don't overlook they always have the expedient of simply unplugging the power, if you or your staff can't be found. When users perceive the need to reboot, something is wrong - and it needs to be fixed. I have also kept workstations doing very heavy-duty CAD work up for months on end.

I would never (and have never) tolerated sloppy software. When databases leak memory, the answer is to call the vendor and explain the problem and get it fixed. I think I even remember the memory leak that Pete refers to. Every time a SQL PREPARE was done, new memory was allocated. For the interim period before Informix provided the fix (about 3 months as I recall), I made a change to a library to cache PREPARE'd statements and to look in the cache for them before doing a new PREPARE. It wasn't a perfect fix but it probably eliminated 98% of the leaks and worked until the real fix was done. I could have simply punted and allowed weekly reboots but which is the better answer. Don't reboot, fix the problems.

[Scott Painter_1]

Thanks for the answers. CASE IS CLOSED.