La mejor manera de eliminar el comando de apagado, pero sigue reiniciando


27

Tengo un dispositivo de tipo raspi en un centro de datos, y recientemente accidentalmente toqué y pegué un comando de apagado en el terminal incorrecto de mi pantalla. ¿Hay alguna manera de mantener shutdown -rpero eliminar #poweroff #shutdown -P -Hopciones?

Quiero mantener el shutdown -r comando Me gusta ponerle un temporizador si logro congelar el sistema o bloquearme con las reglas de la tabla ip. ejemploshutdown -r +10

Respuestas:


39

Debería estar utilizando una distribución de Linux basada en systemd. En este caso, debe poder enmascarar el objetivo de apagado, de modo que systemd se niegue a ejecutarlo (y se apague). p.ej:

systemctl mask poweroff.target

Esto hace que sea completamente imposible apagar el sistema, aparte de reiniciar. Ver que no pasa nada:

Demo animada de Debian9

En este caso, el interruptor de alimentación virtual de esta VM ya no funciona para apagar el sistema. Pero todavía se reinicia perfectamente bien.

Para deshacer el cambio, por supuesto, simplemente desenmascara el objetivo. Entonces puede apagar el sistema.

systemctl unmask poweroff.target

2
¿Existe un comando systemd que enumera todos los servicios / objetivos / dispositivos con su descripción (si está disponible)? Recientemente comencé a leer sobre esto y me encantaría explorar las posibilidades.
hjpotter92

1
@ hjpotter92 Ejecutar systemctlsin argumentos. Enumerará todas las unidades activas, su estado y descripciones. Agregar --ally también mostrará una lista de las unidades que no están activas.
Michael Hampton

2
@ hjpotter92 Echa un vistazo man systemd.special.
TooTea

16

Hay algunas formas de lograr esto. Uno estaría trabajando con una cuenta regular sin privilegios que requerirá ejecutar el comando con sudo e ingresar una contraseña. Luego puede agregar lo siguiente a / etc / sudoers (ejecutando visudo):

## user is allowed to execute reboot -r only
jdoe ALL=NOPASSWD: /sbin/shutdown -r *

Además, para deshabilitar el almacenamiento en caché de credenciales de sudo, agregue también lo siguiente:

Defaults timestamp_timeout=0

Esto evitará el almacenamiento en caché de credenciales en caso de que haya invocado un comando con sudo anteriormente.

Ejemplo:

[root@ops ~]# su - jdoe
[jdoe@ops ~]$ sudo shutdown -c
[sudo] password for jdoe:
[jdoe@ops ~]$ sudo shutdown -r +10
Shutdown scheduled for Mon 2018-09-03 18:51:13 IDT, use 'shutdown -c' to cancel.
[jdoe@ops ~]$ sudo shutdown -H
[sudo] password for jdoe:
^[[A[jdoe@ops ~]$ sudo shutdown -c
[sudo] password for jdoe:

Observe cómo en el ejemplo anterior no se me solicitó ingresar mi contraseña cuando se ejecutaba sudo shutdown -r +10, pero por el resto sí. Si desea eliminar la necesidad de escribir sudo antes del comando ( sudo shutdown -r +10), agregue lo siguiente a su .bash_profile o .bashrc:

alias shutdown="sudo shutdown"

Ejemplo:

[jdoe@ops ~]$ source ~/.bash_profile
[jdoe@ops ~]$ shutdown -r +10
Shutdown scheduled for Mon 2018-09-03 19:03:14 IDT, use 'shutdown -c' to cancel.
[jdoe@ops ~]$ shutdown -c
[sudo] password for jdoe:

Tenga en cuenta que es una buena práctica trabajar con una cuenta no privilegiada y escalar con sudo cuando sea necesario.


1
Esto es genial, excepto que sudola configuración predeterminada tendrá las credenciales de caché durante algún tiempo después de la primera invocación. Esto puede ser conveniente cuando la ejecución repetida de comandos como rootse requiere en una sesión de usuario. En dicha sesión (o, de hecho, si se rootestá ejecutando un shell), sería completamente posible realizar la transacción del comando shutdowny omitir las comprobaciones.
Cosmic Ossifrage

Gracias por el aporte. Sin embargo, en este caso, estamos configurando shutdown -rpara no solicitar la contraseña cuando se ejecuta con sudo, por lo tanto, si ejecuta sudo shutdown -r ...las credenciales no se almacenarán en caché, ya que no se ingresarán. Mire el ejemplo que di arriba, puede ver que lo ejecuté seguido de a sudo shutdown -Hy se me solicitó la contraseña.
John Doe

3
De hecho, eso se entiende. Pero, considere el escenario en el que el último comando tenía el prefijo sudoy no era una NOPASSWDoperación; por ejemplo, una llamada para editar un archivo de configuración como root. En este caso, la contraseña se almacenará en caché y se realizará una llamada posterior a sudo shutdown -H. sudoEl almacenamiento en caché de contraseñas debería deshabilitarse para evitar esto.
Cosmic Ossifrage

2
En este caso, tiene razón, +1 para deshabilitar el almacenamiento en caché de contraseñas. Edité mi comentario con la sugerencia. ¡Gracias!
John Doe

2
En realidad no me gusta para nada, precisamente porque se basa en la presencia de la contraseña de sudo para supuestamente recordarle al usuario que no debe hacer lo que se supone que no debe hacer. Pero la solicitud de contraseña realmente no sirve para este propósito. Se solicita con tanta frecuencia sudoque simplemente escribimos la contraseña y seguimos adelante. Vea aquí un enfoque alternativo con sudo (que probablemente sea mucho mejor a pesar de no ser muy bueno).
Michael Hampton

10

Existe una herramienta llamada molly-guard que requiere que indique el nombre de host de la máquina que desea apagar o reiniciar.

En caso de que no esté utilizando Debian, debería ser trivial compilar esto desde la fuente, dado que el programa es bastante primitivo.


9

Para evitar contratiempos, las distribuciones basadas en RHEL ya configuraron alias para rm, cpy mvque pueden ser algo más destructivos cuando los realiza el usuario root.

Puede agregar el suyo, por ejemplo:

#/root/.bashrc
alias poweroff='echo  "poweroff: Command disabled - THINK before you type.
  Use /usr/sbin/poweroff if you really want to drive to the DC to restore power."'

2
¿Cómo mantiene esto al shutdown -rtiempo que deshabilita shutdown -P -H?
MSalters

3

Cambie el nombre del ejecutable de apagado a algo imposible de invocar accidentalmente.

Entonces alias shutdownpara ser(whatever) -r


1
¿Podría explicarme cómo cambiar el nombre del ejecutable? ¿Podría romper las actualizaciones de paquetes en el futuro?
AL

2
@AL ¿Podría romper las actualizaciones de paquetes en el futuro? Si podria. También podría romper cosas ya instaladas. En general, jugar con partes de la instalación del sistema operativo es una muy mala idea.
Andrew Henle

1
De acuerdo. Es suficiente para alias shutdowna /sbin/shutdown -r. El cambio de nombre no es necesario; Como la expansión de alias se refiere a una ruta absoluta, no está sujeta a la expansión de alias recursiva.
MSalters

Una advertencia: creo que 'nada es imposible', es poco probable
JosephDoggie el
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.