linux: make ctrl-alt-del working with X

I want make ctrl+alt+del to initialize shutdown/reboot of the linux box while pressing it on X session.
Normally X/Xserver ignores this combination. How redirect this to init, so it would initialize shutdown?
LVL 43
ravenplAsked:
Who is Participating?
 
GnsCommented:
Yo raven!
I had an actual thought... Although the shutdown script don't have the info needed, perhaps we can ... find it out!
The reasoning is that the parent to the script would be the wdm spawned to handle the particular display, and thus having open network sessions to it.
Something like:
PARENT=$(ps -fp $$|tail +2|awk '{print $3}')
then use "lsof -p $PARENT" or "netstat -np | grep $PARENT" to get at the network connection(s)... Haven't got the time (nor machinery here at home:-) to muck about with it more, but you get the general idea:-)... Once you know the host, it's a simple matter to reboot it...;)

Cheers
-- Glenn
0
 
GnsCommented:
AFAIK this isn't really possible. It used to be that it did pass that particular sequence on (IIRC:-), but after a heated debate about the unsafe aspect of this, X now traps this as any other keypress. You could of course hack the code;-).

But then again, why not work with what X has already? There are a few ... workarounds:

- <Ctrl><Alt><F#> to any console not containing a running X server, then <Ctrl><Alt><Delete>

- If you allow server zap, press <Ctrl><Alt><Backspace>, then rather rapidly (since the display manager is likely to restart X:-) <Ctrl><Alt><Delete>

- Bind the sequence to a logout/exit action in your desktop/window manager ... "keyboard shortcut" in Gnome or KDE... This is perhaps the most sane thing, and the one that make former windoze users feel most at home.

- type up your own script/program, and bind that to the sequence...

The last one isn't exactly the best, and both the last two have the problem of not solving it when the screen is locked, or at the display manager login screen. Depending on display manager, you could simply quit it and use the sequence... Or one of the other methods:-)

-- Glenn
0
 
ravenplAuthor Commented:
> - type up your own script/program, and bind that to the sequence...
How would I do that ?

This is xterminal, so locally is only X, login prompt is run on the server. It's wdm. I tried define shutdown programm in wdm config, but encountered two propblems: no way to connect to remote(i can manage it), no way to obtain the remote IP(for some reasons wdm does not sets the DISPLAY var for shutdown script).
0
Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.

 
GnsCommented:
There is some fairly insecure tk script that some would say "solves" this for the login screen (when using xdm) ... perhaps useable here too. Hm, digging a bit... Ok, as I almost remembered(:-) this is a somewhat modified xdm that you are using... Correct me if I'm wrong, but what you want is for the "non-local" input on the X terminal to have a console-like action on the "serverside" linux, correct?

That would mean that you'd have to simulate the "passing on to init" anyway (the X terminal isn't the console;)... So why not work with what wdm gives you? Since the "magic combination" will make security go out the window (so to speak), you ould as well set these resourses to allow non-root restarts:
DisplayManager*wdmReboot:      <command to execute to reboot>
DisplayManager*wdmHalt:            <command to execute to halt>
DisplayManager*wdmVerify:      <true/false> -- Verify user for reboot/halt/exit
DisplayManager*wdmRoot:            <true/false> -- user must be verified root to exit

... how to bind the wdmReboot action to a specific key would probably have to be a very specific translation .... provided it actually provides the interface at all. Hm, doesn't look like it.
I'll perhaps find the time to actually fiddle a bit with it...

Or did I missunderstand you completely?

-- Glenn
0
 
ravenplAuthor Commented:
I tried with those
DisplayManager*wdmReboot:     <command to execute to reboot>
DisplayManager*wdmHalt:          <command to execute to halt>
but the command I applied there was unable to find the remote IP to connect and initialize shutdown...
Those commands runs on server...
0
 
GnsCommented:
Ah, now I see the light!

The problem you have is:
_linux_ X terminal needs reboot, but _server_ running the actual X server cannot correctly do it.
Did I get it right this time? Some sort of LTSP setup, perhaps? Or am I still not getting it? (I admit to feeling a bit daft ATM:-)

The advice above is mostly about rebooting the server. As you probably guessed:-):-).

Well, this could be really thorny to do locally... Does the X terminal provide the usual virtual terminal? If booted without X, does it honour <Ctrl>-<Alt>-<Delete>? Then perhaps one could use the <Ctrl><R> then <Ctrl>-<Alt>-<Delete> approach...
Or just do a "double kingston", which would be very safe if the terminal is a diskless type of thing... ("double-kingston" is reminiscent of the times when non-original RAM was a huge source of HW problems, best solved by hitting the power button... twice:-).

-- Glenn
0
 
ravenplAuthor Commented:
Yes, indeed it's like LTSP, but run from local disk(on the X terminal), rather than from NFS.
Switching to linux console Ctrl+Alt+F1 is not an option.
Power button in use currently, but I wanted the OS to shutdown properly.
<Ctrl><R> - what You mean by that?
0
 
GnsCommented:
The standard wdm (and xdm) config defines the override translation that hitting <Ctrl>-<R> will abort-display, in  other words restart wdm ... and its X server... So for a short moment before wdm starts up again, you'll effectively be able to squeeze in some keyboard input to the virtual terminal, and hence to init.
Would probably mean hitting <Ctrl>-<R>, then stomping on <Ctrl>-<Alt>-<Delete> a couple of times, just to be sure it gets through... and not being lax about it:-).
If you configure wdm to not restart after exit, one might get a more workable situation for this, but then... that would be less than workable for the normal case :-).

Now, the shutdown script... What environment variables does it set, and what command line options (if any) does it set?
#!/bin/sh
touch /tmp/logfile
echo "params:$*" >> /tmp/logfile
env >> /tmp/logfile
# End of Script
... would tell (but you know how to work that:-)
Would tell us once and for all if that is a possible way to solve it.

-- Glenn
0
 
ravenplAuthor Commented:
Ctrl-R... AS well I could tell to users: hit Ctrl-Alt-Backspace and really fast Ctrl-Alt-Del - but it's too much for users - belive me.

I already checked parameters and env variables. nothing about remote IP though...
0
 
GnsCommented:
Only thing I can think of then is to have different resources for every display, just for the reboot script, and using normal tools like ps and whatnot to find out what ip has which display. Horrendous, but perhaps doable.

And users will be users... sometimes they will surprise you though:-). I've got complete idiots that will follow that type of instruction to the letter, so all would be fine... and some "advanced users" that will never do it, thinking they are smarter/know more than me... Sigh.

-- Glenn
0
 
gheistCommented:
LTP etc are done the way that poweroff of terminal causes no damage, so I assume nobody ever cared bout that.

I imagine one can add window of "wish" program containing button for shutdown along with login menu ( one is root there ;) ) in Xsetup_0
I guess there is possibility to customize and add buttons to any xdm too.

0
 
ravenplAuthor Commented:
I tried the wish script with poweroff button, hence I guess I did something wrong. The script was crashing occasionally and was taking the X with it. Not really usefull.
0
 
GnsCommented:
Not to mention the problem of "send":-)

-- Glenn
0
 
ravenplAuthor Commented:
> Not to mention the problem of "send":-)
No.
I tried running always-on-top button on the xserver (xconsole) side. But when the scripts crashed whole X crashed as well.

maybe somwhere in the Xmodmap I could unhook the C-A-D ?
0
 
gheistCommented:
Do you have a trace of how X server crashed??? It should not, and you can now fill a bug report.
0
 
ahoffmannCommented:
as already explained by Glenn: disabled in X for obvious security reason

depending on your distribution you have various command line utilities or GUI buttons of your desktop
for example:
  /sbin/shutdown
  /sbin/reboot
  /usr/bin/reboot
  /usr/bin/poweroff
0
 
ravenplAuthor Commented:
> disabled in X for obvious security reason
It's still not obvious for me. What is the security reason? What's the security if user still can do: crtl+alt+f1 or crtrl+alt+backspace ?

> GUI buttons of your desktop
Examples? Not really familiar with GUIs...
0
 
GnsCommented:
>> disabled in X for obvious security reason
> It's still not obvious for me. What is the security reason? What's the security if user still can do: crtl+alt+f1 or crtrl+alt+backspace ?

That can be turned off....

-- Glenn
0
 
ravenplAuthor Commented:
> That can be turned off....
who does? anyway - I know how to disable ctrl+alt+del in inittab. How to disable ctrl+alt+backspace and ctrl+alt+f1 in X ?
0
 
ahoffmannCommented:
no ready to use sample handy, but:
man xmodmap
0
 
gheistCommented:
Rather simple:



       Ctrl+Alt+Backspace
               Immediately kills the server -- no questions asked.   This  can
               be disabled with the DontZap xorg.conf(5) file option.

       Ctrl+Alt+Keypad-Plus
               Change  video  mode  to next one specified in the configuration
               file.  This can be disabled with the DontZoom xorg.conf(5) file
               option.

       Ctrl+Alt+Keypad-Minus
               Change  video  mode to previous one specified in the configura-
               tion file.  This can be disabled with the DontZoom xorg.conf(5)
               file option.

       Ctrl+Alt+Keypad-Multiply
               Not  treated  specially by default.  If the AllowClosedownGrabs
               xorg.conf(5) file option is specified, this key sequence  kills
               clients  with  an  active  keyboard  or  mouse  grab as well as
               killing any application that may have locked the  server,  nor-
               mally using the XGrabServer(3) Xlib function.

       Ctrl+Alt+Keypad-Divide
               Not  treated specially by default.  If the AllowDeactivateGrabs
               xorg.conf(5) file option is specified, this key sequence  deac-
               tivates any active keyboard and mouse grabs.

       Ctrl+Alt+F1...F12
               For  BSD and Linux systems with virtual terminal support, these
               keystroke combinations are used to switch to virtual  terminals
               1  through  12,  respectively.   This  can be disabled with the
               DontVTSwitch xorg.conf(5) file option.
0
 
ahoffmannCommented:
oops, my xmodmap was a lazy answer, sorry.
Beside modern Xorg (see gheist's suggestion), most (all) X applications can be configured using Xresources file, for example /etc/X11/Xresources or /etc/X11/xdm/Xresources and/or their own X resource file.
Depending on your configuration of your X after you log in (either startx from console or using something like xdm), X and all X applications read their resource files and their class resource files, *unless* you have used xrdb (which is used by most modern window and panel managers unfortunately).
0
 
GnsCommented:
>> That can be turned off....
> who does?
The conscientous admin? Some distros come with it off by default (Ubuntu for example)...

> anyway - I know how to disable ctrl+alt+del in inittab. How to disable ctrl+alt+backspace and
> ctrl+alt+f1 in X ?
Answered nicely above:-).
man xorg.conf
or
man XF86Config
(on older distros that still employ XFree86) would have given you this info, but now (thanks to Andrew) you don't need to:-)

BTW, the xmodmap route suggested by Achim would've worked too. do an "xmodmap -pk|grep XF86_" and you'll see what you need change...;-).

When you say ...
>> Not to mention the problem of "send":-)
> No.
... this make little sense to me. If employing the tkscripts, you'd still be executing them on the server, right? So you'd need use "send" or similar to effect the reboot of the client box, which would open yourself to the insecurities of that. Or did I missunderstand you?

Did you ever try to work something out with the scriptlet I gave above? The method of working out the actual IP address should be quite easily workable...

-- Glenn
0
 
ravenplAuthor Commented:
Gns - I tried to execute some tk script from same script that starts Xserver. It runned on the workstation therefore, and always was faster that wdm, so no authentication was needed.

Thanx for the disabling combo tip. But I need one to enable another combo :(
Anyway - my problem persists...

> Did you ever try to work something out with the scriptlet I gave above?
No, but I saw that in fact it shows the socket unmangled(remote IP:port available), so if nothing better would appear - I guess I get into it...
0
 
GnsCommented:
> I tried to execute some tk script from same script that starts Xserver. It runned on the workstation therefore, and always was faster that wdm, so no authentication
> was needed.
How about ensuring a long enough delay then? Oh well, I suppose you've fiddled a lot with such already:-).

>> Did you ever try to work something out with the scriptlet I gave above?
> No, but I saw that in fact it shows the socket unmangled(remote IP:port available), so if nothing better would appear - I guess I get into it...

Exactly, it shouldn't be that hard to filter out. And then ssh ...:-).

-- Glenn
0
 
ravenplAuthor Commented:
Not really what I wanted, but it's time close this Q.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.