Portada
mis comunidades
otras secciones
![Ejecutar el comando “rm -rf /” en un Linux arrancado con UEFI puede dejar inservible el equipo de forma permanente [ENG]](https://cdn.mnmstatic.net/cache/27/03/media_thumb_2x-link-2556713.jpeg?1454343727)
#2:
Pues menos mal que han avisado. Iba a ejecutarlo en cuanto acabase lo que estoy haciendo
#20:
#11 Fue el script que lanzaba Steam.
http://news.softpedia.com/news/Steam-for-Linux-Can-Delete-Home-Folder-with-rm-rf-470247.shtml
De todas formas casi todas estas cosas pasan por no trabajar con linux (o cualquier Unix) como debe trabajarse. Es decir, importándote todo una mierda y sin tomar precauciones ni leer lo que sale por pantalla. Más o menos es como conducir un coche y pensar que puedes prepararte un chocolate con churros porque tienes las rodillas libres para mover el volante.
http://news.softpedia.com/news/Steam-for-Linux-Can-Delete-Home-Folder-with-rm-rf-470247.shtml
De todas formas casi todas estas cosas pasan por no trabajar con linux (o cualquier Unix) como debe trabajarse. Es decir, importándote todo una mierda y sin tomar precauciones ni leer lo que sale por pantalla. Más o menos es como conducir un coche y pensar que puedes prepararte un chocolate con churros porque tienes las rodillas libres para mover el volante.
#61:
#7 Al azar no, pero cosas como:
rm -rf / tmp
Eso si puede pasar, solo es poner un espacio por error donde no debías. Combinaciones donde puedes borrar / o * (estando en /) cambiando solo un espacio hay a patadas
Todavía hace no mucho lance un rm -rf que por error se comia todo *
(Algo como rm -rf ~/folder/anotherFolder/* me salio rm -rf ~/folder/anotherFolder/ *). Vale que no era root, pero aun asi, como root o sudo si que lanzas rm -rf a veces
rm -rf / tmp
Eso si puede pasar, solo es poner un espacio por error donde no debías. Combinaciones donde puedes borrar / o * (estando en /) cambiando solo un espacio hay a patadas
Todavía hace no mucho lance un rm -rf que por error se comia todo *
(Algo como rm -rf ~/folder/anotherFolder/* me salio rm -rf ~/folder/anotherFolder/ *). Vale que no era root, pero aun asi, como root o sudo si que lanzas rm -rf a veces
#7:
#4 faltaría un sudo delante o hacerlo como root. Hay millones de combinaciones posibles en el teclado, dudo que justo "rm -fr /" sea la que te vaya a salir, de hecho es más probable que te atropelle un coche de que te salga justo esa combinación de casualidad. Si te atropella un coche estos días no me lo eches en cara...
#57:
#25 Mención obligatoria (no te olvides de poner el where en el delete from): https://www.youtube.com/watch?v=i_cVJgIz_Cs
#54:
A ver, el articulo puede llevar a confusión. Me explico:
La UEFI no vive en el disco duro junto al sistema operativo, sino en memoria ROM solo de lectura, y la configuración y actualizaciones de esta, se almacenan en la memoria CMOS, que va alimentada por la pila de la placa base.
Esto que quiere decir? Que te puedes cargar la parte del sistema operativo encargada de arrancar desde UEFI, y te veras obligado a reinstalar el sistema operativo, pero en ningún caso supone un "perma-brick" como ellos dicen.
El problema puede ser en todo caso, que algún fabricante no monte la UEFI sobre memoria ROM, y permita sobrescribirla, pero esto no es lo habitual.
La UEFI no vive en el disco duro junto al sistema operativo, sino en memoria ROM solo de lectura, y la configuración y actualizaciones de esta, se almacenan en la memoria CMOS, que va alimentada por la pila de la placa base.
Esto que quiere decir? Que te puedes cargar la parte del sistema operativo encargada de arrancar desde UEFI, y te veras obligado a reinstalar el sistema operativo, pero en ningún caso supone un "perma-brick" como ellos dicen.
El problema puede ser en todo caso, que algún fabricante no monte la UEFI sobre memoria ROM, y permita sobrescribirla, pero esto no es lo habitual.
#10:
#5 Yo conozco a uno que como administrador revocó los privilegios de una base de datos. Sí, también los suyos propios. Menudo merluzo.
También conozco a otro que con un editor de disco, cambió en el sector de arranque la palaba "WINDOWS" por su nombre. Tuvo que sacar el disco duro y ponerlo en otro equipo para volver a ponerlo bien.
Así que, sí, me lo creo.
También conozco a otro que con un editor de disco, cambió en el sector de arranque la palaba "WINDOWS" por su nombre. Tuvo que sacar el disco duro y ponerlo en otro equipo para volver a ponerlo bien.
Así que, sí, me lo creo.
#29:
#23 Se refiere a systemd.
Pero en un mundo en el que la última moda son containers corriendo microservicios, irremediablemente vamos de cabeza a que una mierda como systemd se implemente en todas partes, para que así en el microcontainer todo se pueda gestionar fácilmente.
Y al que todavía ande con servidores, pues a ese que le den morcilla (o que se pase a OpenBSD, que es un buen momento).
Pero en un mundo en el que la última moda son containers corriendo microservicios, irremediablemente vamos de cabeza a que una mierda como systemd se implemente en todas partes, para que así en el microcontainer todo se pueda gestionar fácilmente.
Y al que todavía ande con servidores, pues a ese que le den morcilla (o que se pase a OpenBSD, que es un buen momento).
Comentarios
Pues menos mal que han avisado. Iba a ejecutarlo en cuanto acabase lo que estoy haciendo
#2 Lamentablemente conozco un caso en el cual un programador que usaba linux estaba medio dormido, fue a hacer un rm -rf /[presionar tab para poner el unico archivo dentro de la carpeta]
Si, no tenia ni que poner el /, ni tampoco le dio al tab.
Y todo que si que si que si...
#5 Yo conozco a uno que como administrador revocó los privilegios de una base de datos. Sí, también los suyos propios. Menudo merluzo.
También conozco a otro que con un editor de disco, cambió en el sector de arranque la palaba "WINDOWS" por su nombre. Tuvo que sacar el disco duro y ponerlo en otro equipo para volver a ponerlo bien.
Así que, sí, me lo creo.
#10 baneé mi propia IP de un servidor y después no podía acceder.
#17: Eso es peor que un "delete from" terminando con toda vida.
#25 Activé el SSH sin password... y tenía una errata en el authorized_keys...
#25 Mención obligatoria (no te olvides de poner el where en el delete from):
#57 JAJAJA ¿De dónde has sacado eso?
#73 Apareció en portada hace unos años. Imagino que es a lo que se refiere #25.
#73: Es este envío: No te olvides de poner el where
No te olvides de poner el where
youtube.comY aquí la explicación:
¿Por qué no debes olvidar el WHERE en el DELETE FROM?
¿Por qué no debes olvidar el WHERE en el DELETE FR...
w3schools.com#57 Hasta he hecho imágenes de fractales relacionadas con esa canción. también la traduje al inglés cuando me di cuenta que nadie antes lo había hecho...
#57 Jajajaja me la has pisado, iba a ponerla ahora mismo
#25 Con un delete from aún puedes en muchos casos ir al log y recuperar lo borrado. Prueba con un drop table y me cuentas
#17 ¡ Qué grande ! Yo sólo borré la web de producción, con rm -rf, por supuesto. Pero me parece mucho más imaginativo lo tuyo. Molaría hacer un hilo con las cagadas más tontas e imaginativas.
#17 reconfiguré routers a mansalva por todo el local, con el mismo filtrado de MAC's en su firewall, pero una vez retiradas las notebooks de todos los vendedores, olvidé dejar alguno desde donde pudiera acceder para declarar mi equipo, así que tube que ir y reseteralo
#10 "Yo conozco a uno que como administrador revocó los privilegios de una base de datos. Sí, también los suyos propios. Menudo merluzo."
Eso nos pasa a todos. A todos. Y mejor antes que después.
#22 La proxima vez que pruebe un DELETE DATABASE y ya veras que risas!
#60 drop database
#22 Como el delete sin where, ¿ Quién no cuenta con alguno en su haber ? Mejor que te pase haciendo pruebas que cosas de mayores. Por eso tampoco es bueno tocar la base de datos desde el móvil...
#10 Yo hace días con herramienta de hp para crear pens bootables de dos me cepille dos particiones en un disco de 500G 10 horas de recuperación..
#2 #5 #9 Pasa muchas mas veces de las que pueda parecer en un principio.
Los script para borrar instalaciones/archivos temporales salen almacenar el path en una variable, y a veces por error esa variable puede estar en blanco (o mal escrita). Asi un "rm -rf /" se convierte en un "rm -rf /", durante la carrera de informática a toda nuestra clase le paso una vez con un makefile del profesor (mas concretamente fue un rm -rf ./) que nos ventilo todo el codigo.
También pasa a veces cuando estas usando muchos "rm -rf /" (para borrar temporales tras experimentos, por ejemplo) y sin querer se presiona la tecla intro mientras estas editando el path en consola. O metes un espacio en blanco sin querer.
#10 Eso también lo he visto en persona, y mas de una vez.
#127 De que pie cojee es irrelevante, alguno llevamos mucho en esto como para que nos importe. Para mi esto no pasa de ser un trabajo y usaré el sistema y herramientas que me manden (nunca he tenido un curro que me hiciera decidir)
El problema de esto lo veo en que puedes lanzar un rm contra /sys sin siquiera darte cuenta, como decía en #97, si haces uso de chroot puedes acabar haciendo un bind de /sys en un sitio que luego te olvidas del umount y lanzas un rm -rf contra el directorio que lo contiene
#5 Me parece recordar que alguna aplicación tuvo un bug en el que ejecutaba el comando "rm -rf /+ una variable que contiene la ruta del fichero" sin comprobar si la variable estaba o no vacía, con lo cual si se ejecutaba como root te podía causar un estropicio importante. En ese caso puede ser un descuido comprensible. Pero escribir en línea de comandos rm -rf /loquesea no se me ocurre ni harto de vino
#11 Fue el script que lanzaba Steam.
http://news.softpedia.com/news/Steam-for-Linux-Can-Delete-Home-Folder-with-rm-rf-470247.shtml
De todas formas casi todas estas cosas pasan por no trabajar con linux (o cualquier Unix) como debe trabajarse. Es decir, importándote todo una mierda y sin tomar precauciones ni leer lo que sale por pantalla. Más o menos es como conducir un coche y pensar que puedes prepararte un chocolate con churros porque tienes las rodillas libres para mover el volante.
#20 Los colegas de CCP se pulieron el BOOT.INI de windows en una actualización de EVE Online...
http://community.eveonline.com/news/dev-blogs/about-the-boot.ini-issue/
#5 como intrépido linuxero... algo falla en esa historia...
#5 Fue famosa en un repositorio de github una actualizacion en la que un a rm -rf /usr/appxxx/appdata se le cayo un espacio despues de la primera barra. Le inundaron la linea a base de memes. "No suelo borrar todo el disco, pero cuando quiero hacerlo, actualizo appxxx"
#2 Pues yo lo acabo de probar y no pasa nad
Menos mal que en Windows eso no se puede hacer
#1 Siempre tiene que haber un comentarista de la noticia sin haberla leído, en especial donde dice que se puede hacer lo mismo con cerca de 20 líneas de código en Windows.
Premio
#3 es que “rm -rf /” me puede salir de casualidad, pero 20 líneas ya sería mucha casualidad
como saltáis algunos....
#4 faltaría un sudo delante o hacerlo como root. Hay millones de combinaciones posibles en el teclado, dudo que justo "rm -fr /" sea la que te vaya a salir, de hecho es más probable que te atropelle un coche de que te salga justo esa combinación de casualidad. Si te atropella un coche estos días no me lo eches en cara...
#7 cosas más raras he visto
#8 #7 Puedo decir que hace ya años fui uno de esos [desa]graciado, menos mal que fue probando una distro .
#7 Al azar no, pero cosas como:
rm -rf / tmp
Eso si puede pasar, solo es poner un espacio por error donde no debías. Combinaciones donde puedes borrar / o * (estando en /) cambiando solo un espacio hay a patadas
Todavía hace no mucho lance un rm -rf que por error se comia todo *
(Algo como rm -rf ~/folder/anotherFolder/* me salio rm -rf ~/folder/anotherFolder/ *). Vale que no era root, pero aun asi, como root o sudo si que lanzas rm -rf a veces
#61 justo acabo de poner en #119 una anécdota muy parecida
#7 hay muchos manuales en los que se empieza:
"sudo su -"
y a continuación, todos los comandos.
#7 Por casualidad, no.
Pero la diferencia entre "sudo rm -rf /home/usuarioviejo" y "sudo rm -rf / home/usuarioviejo" es exactamente la que hay entre un pulgar mal puesto y la barra espaciadora.
Y ya sé que lo seguro es hacer "cd /home; rm -rf usuarioviejo", pero nadie es perfecto.
#7 supongo que el problema es que ese comando puede estar, accidental o maliciosamente, en un script (por ejemplo de instalación) que sí vayas a ejecutar como root.
#7 Anécdota:
Un compañero estaba como root en el directorio / y había creado una serie de directorios temporales llamados temp1 temp2 temp3 temp4 para una aplicación. (el muy mamón no quería usar /tmp)
No se le ocurrió otra cosa para borrarlos que hacer "rm -rf temp *" pensando que así borraría todos los directorios que empezaban por temp. (Para los no duchos, ese comando borra el fichero temp, y luego todo)
No pudimos pararlo hasta que fue demasiado tarde y el servidor dejó de responder. Tuvimos que reinstalar el SO y cargar un backup de la aplicación.
Los clientes se pusieron contentísimos con su gran actuación.
PD: No, no había entorno de des ni pre, así de tacaño era mi jefe de entonces.
#4 Si quieres borrar todo lo que hay en el directorio actual... ¿que haces?
rm -rf ./
Imagínate que se te olvida o te falla el punto.
#77 Hay algo peor, y es que se te cuele un espacio entre el punto y la barra (me pasó):
rm -rf . /
eso también funciona... pero no borra sólo el directorio actual...
#77 rm -rf ./
rm: refusing to remove ‘.’ or ‘..’ directory: skipping ‘./’
¿Estás seguro?
#4 oh mierda, ctrl C, ctrl C ¡¡¡¡CTRL C!!!!
#c-4" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2556713/order/4">#4 Y qué si te sale de casualidad:
# rm -rf /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe
#3 En Windows también se puede arruinar el sistema si le metes fuego o lo golpeas repetidamente con un martillo grande. Y NO HAY PARCHE.
#33 Hombre, digo yo que un par de curitas sana y una tirita lo arreglaran no?
#3 ¿cuánto crees que tardará en aparecer un virus para windows que amenace con inutilizar tu PC si no pagas un rescate?
#34 48 horas 1000€ + 5 % beneficios.
#34 Ya los hay.
#3 Si fuese al revés, una noticia sobre un bug o vulnerabilidad en Windows, y el comentario rezase "eso con Linux no pasa", probablemente aplaudirías con las orejas.
#1 Sólo te quedan 999.999 formas de joder un Windows
#6 Joder el Windows es una cosa, si jodes la UEFI el HW sirve como posapapeles.
#53 Ok. Me documentaré
#53 Me muero de curiosidad... ¿qué es un posapapeles?
#95: Una mesa.
#1 Es conveniente leerse las noticias: "Matthew says with about 20 lines of code on Windows, you can cause the same havoc."
#1 Estamos hablando de que el problema no es que se borre el sistema de ficheros, sino que al montarse el firmware de la UEFI en dicho sistema de ficheros y al necesitar permisos de escritura si por casualidad se borra el sistema de ficheros, se destroza todo el ordenador. Y esto es así tanto en linux como en windows. Y no lo digo yo, lo dice Matthew Garret, uno de los desarrolladores que lidia con UEFI en systemd:
"Matthew says with about 20 lines of code on Windows, you can cause the same havoc."
#72 destrozarse todo el PC por un error de disco ¡que forma de intentar vender más PCs diría yo! (desde un error, o tal vez un corte de luz dañando ficheros etc..)
UFF
Vamos, que nadie lo ha probado:
# rm -rf /
rm: it is dangerous to operate recursively on ‘/’
rm: use --no-preserve-root to override this failsafe
#54 No hay confusión: "On UEFI distributions by default where EFI variables are accessible via /sys".
Si borras todo el sistema de archivos afecta al directorio /sys/firmware/efi/efivars
De todas formas, no se puede hacer un rm -rf / desde hace mucho tiempo, porque rm da error, como ha dicho #47. Pero el problema está ahí, lo de menos es como se haga.
#47 Es cierto, positivo para ti pero, ¿podrías probar?
$ rm -rf /*
Y ya me cuentas
#47 Es que "no-preserve-root" es demasiado esotérico, deberían hacer como hdparm y poner algo como "please-destroy-my-drive" cuando vas a actualizar el firmware de un disco que queda mucho más claro, a la par que educado.
#76 Ciertamente, es mas facil que ocurra accidentalmente en linux. El principal problema es que aunque prácticamente todo el mundo entiende que rm -rf / va a borrar todos los ficheros de tu disco duro, es que muy poca gente se da cuenta que puede borrar información fuera de tu disco duro. No tienes más que leer este hilo para darte cuenta que mucha gente asume que con reinstalar el sistema el problema se arregla
Incluso con el warning que comenta #47, puedo tener un motivo legitimo para querer borrar todos los ficheros de / pero no soy consciente que borrando /sys puedo dañar la placa. Y hay formas de lanzar esto sin que aparezca el warning:
Pongamos este ejemplo:
mkdir /tmp/chroot/sys
mount -o bind /sys /tmp/chroot/sys (o cualquier otra variante para replicar sys para el chroot)
chroot /tmp/chroot
... do stuff
exit (exit the chroot)
rm -rf /tmp/chroot
Esto parece seguro, pero si no me equivoco, podríamos acabar dañando la placa (igual no pasa al borrar los ficheros de /tmp/chroot/sys, pero al ser un bind, imagino que si
Bueno, cuando puedes modificar la UEFI desde el SO, pues es algo que puede pasar, sí.
A veces pasa que vas a poner "aysi .ed &" y confundes la posición de las manos y te sale "sudo rm -rf /"
A mi me pasó una vez estudiando mecanografía en la consola.
#15 Y cosas peores que pasan. El otro día venía a meneame y acabé en una página de sado y al ir a retroceder en el historial me metí en una videosala, luego explicaselo a la parienta claro.
Esto nunca me pasará con mi olivetti. Claro,que cada vez es más difícil encontrar carretes de cinta de color rojo .
A ver, el articulo puede llevar a confusión. Me explico:
La UEFI no vive en el disco duro junto al sistema operativo, sino en memoria ROM solo de lectura, y la configuración y actualizaciones de esta, se almacenan en la memoria CMOS, que va alimentada por la pila de la placa base.
Esto que quiere decir? Que te puedes cargar la parte del sistema operativo encargada de arrancar desde UEFI, y te veras obligado a reinstalar el sistema operativo, pero en ningún caso supone un "perma-brick" como ellos dicen.
El problema puede ser en todo caso, que algún fabricante no monte la UEFI sobre memoria ROM, y permita sobrescribirla, pero esto no es lo habitual.
#54 Al estar la memoria mapeada en el sistema de ficheros, si sobreescribes el fichero que la mapea, sobreescribes la memoria. Y a tomar por saco todo si no puedes forzarla durante el arranque a cargar los valores de fábrica o algo similar. Y el caso es que ciertas aplicaciones tienen permiso de escritura (lo de montarla como sólo lectura se ha descartado porque por lo visto se cargaría el funcionamiento de muchas cosas, si no realmente no habría problema).
#80 Si es una memoria ROM (Read Only Memory) por definición no puedes sobreescribirla. ¿o me equivoco yo?
Otra cosa es que se haga una copia del contenido de esta en memoria y te cargues esa copia.
#117 Mira el comentario #54 que yo creo que es la mejor explicación.
(Lo de que sea tan simple hacer determinadas cosas con Linux en comparación con Windows es uno de los puntos fuertes. La cosa es que también hay que saber usarlo porque eso implica más peligro.)
¿Cuántos seres humanos, en su sano juicio, ejecutarían "rm -rf /"?
#9 "La programación es una carrera entre los desarrolladores, intentando construir mayores y mejores programas a prueba de idiotas, y el universo, intentando producir mayores y mejores idiotas. Por ahora va ganando el Universo"
-- Rich Cook
#12 AMEN!!!
#18 palabra de Cook
#12 buenísimo!!
#12 El universo ha descubierto la táctica perfecta: Meter algunos de sus mejores idiotas como gerentes de proyectos de desarrollo.
#9 en el pc d un colega... Algunos..
#43 Oye colega, ¿me dejas un momento tu PC con Linux que pruebe una cosa?, ¡verás qué risas! (al menos por mi parte, cabrón roba novias)
¿te refieres a algo así?
#9 recuerdo ciertos drivers alternativos de cierto fabricante que por un bug el script ponia rf -rf /dev /algo en su proceso de instalacion.
#9 Te podría contar el caso de un alguien que ejecutó "rm -Rf . /path_irrelevante" y se dió cuenta, algo después de confirmar y volver de fumar un cigarro, que los espacios en blanco también cuentan.
#49 espero que al menos disfrutases el cigarrillo
eso debe ser equivalente a en su dia con Mac OS pre-X (hasta el sistema 9) arrastrar a la papelera la carpeta System.
El cachondo te dejaba, y no pasaba nada, todo seguía funcionanod. Hasta que reiniciabas y te decía que no encontraba al sistema
#62 No sé porque me imagine que alguien seguro que se planteo si sería mejor dejar que el usuario lo moviera, y si no estaba, buscarlo en la papelera...
#62 prueba a borrar mp3 mientras los escuchas. En Ubuntu al menos, si tienes el archivo (ogg uso yo) abierto lo puedes seguir escuchando. Creo que tiene que ver con que abre los archivos en alguna memoria intermedia. Por ejemplo, cuando borras un exe, da igual que esté ejecutándose con WINE, te deja borrarlo y de paso te evita el "este archivo lo está usando un programa, de verdad quiere borrarlo" Sí. "¿De verdad?" Sí. "¿Seguro?". Que sí, narices. (vida real en güindous).
#94 te abre el inode. Cuando borras el fichero elimina el alias al inode pero el programa que lo tiene abierto ya no necesita el alias por lo que sigue funcionando.
#62 Probado en SheepShaver, funciona.
yo he visto en una empresa los de sistema hacer un script para borrar una aplicación en Windows con un bat que se cepillo el system32 de los equipos, el script si tenias el directorio de la aplicación no había problemas.... perooooo si no existía devolvía de variable de ruta c:windowssystem32 ... con dos cojones tumbaron las maquinas de los jefes de departamento que eran los que debían de tener la aplicación y no la tenían. 😂 😂 😂 😂
Supongo que no hace falta hacer rm -rf / sino que con un rm -rf /sys bastaría para joder la UEFI
Imagina ahora que eres "creativo" y tienes un directorio llamado /sus/ y te equivocas al teclear la orden para borrarlo porque la "u" y la "y" estan juntas en el QWERTY de mierda...
#75 Systemd al estar integrado con el kernel, tenemos que depender más de él, lo que viene a ser una reducción de libertad ya que acapara todo. Por otro lado usa otra sintaxis alejada del shell script y eso te obliga a que ahora tengas que aprender el funcionamiento de los "unit" para que puedas agregar por tu cuenta servicios en systemd.
Más o menos por ahí van las mayores quejas sobre la implementación de systemd.
#c-87" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2556713/order/87">#87 Simplemente aprovecha funcionalidades que provee el kernel que otros sistemas de inicio no aprovechaban (por portabilidad con otros sistemas unix), cualquiera de esos sistemas de inicio puede usar esas mismas funcionalidades y está igual de no-integrado con el kernel. Y no lo hace por capricho, sino porque esas funcionalidades suponen una ventaja clara y permiten hacer cosas que en otros sistemas no pueden.
El funcionamiento de los unit es el mismo que el de los ficheros de script que tenías con sysVinit con la ventaja de que son ficheros de texto que tienen estructura y procedimientos estándar (facilitas la gestión de dependencias, reutilizas código, evitas fallos, no reescribes la rueda). Símplemente refinan lo que ya había y lo hacen más fácil de usar y modificar y más seguro y rápido. Y puedes seguir usando tus scripts de inicio (systemd es compatible con los scripts de sysv, debian/ubuntu aún usa scripts de inicio para algunas cosas y creo que ni siquiera fedora ha portado el 100% de su inicio a units)
Mira esta unidad y dime que no es legible y entendible todo lo que hace, las dependencias necesarias, su entorno de ejecución, el nivel de ejecución del servicio, cómo se recupera si falla, etc:
[Unit]
Description=OpenSSH server second instance daemon
After=syslog.target network.target auditd.service sshd.service
[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
[Install]
WantedBy=multi-user.target
Ahora mira y compara con este script de inicio y lo que tienes que hacer para conseguir lo mismo:
conf_check()
make_aliasesdb() then
# /etc/aliases.db might be used by other MTA, make sure nothing
# has touched it since our last newaliases call
[ /etc/aliases -nt /etc/aliases.db ] ||
[ "$ALIASESDB_STAMP" -nt /etc/aliases.db ] ||
[ "$ALIASESDB_STAMP" -ot /etc/aliases.db ] || return
/usr/bin/newaliases
touch -r /etc/aliases.db "$ALIASESDB_STAMP"
else
/usr/bin/newaliases
fi
">
start() # Check that networking is up.
[ ${NETWORKING"> = "no" ] && exit 1
conf_check
# Start daemons.
echo -n $"Starting postfix: "
make_aliasesdb >/dev/null 2>&1
[ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE
/usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure $"$prog start"
RETVAL=$?
[ $RETVAL -eq 0 ] && touch $lockfile
echo
return $RETVAL
}
Una unit te la hace cualquiera que sepa medianamente lo que hace simplemente copiando otra; describes el servicio y su comportamiento y systemd se encarga por ti. Un script de inicio bien hecho ya no es tan "fácil", ya necesitas un especialista y todos los casos excepcionales los tiene que manejar a mano.
Mariconadas.
sudo shred -n 10 -u /sys/firmware/efi/efivars
#98: No lo tienes con nocturnidad?
#98 Mariconadas.
sudo shred -n 39 -z -u -f /sys/firmware/efi/efivars
Mi hermano una vez ejecutó por error un rm -rf en un mainframe...En el mismo día creó un algoritmo recursivo sobre ext2 que unía inodos y con data carving y estadística sacó el 100% y reconstruyó el volumen al 100%.
Al final resulta que de un error garrafal y accidental tuvimos una maravilla!!
#92 Mainframe? Comandos unix? Algo no me cuadra...
(Y en USS un rm -rf / no va a llegar muy lejos, a no ser que seas IBMUSER, y normalmente la contraseña de esa cuenta suele estar bajo llave...).
¿Pero alguien lo ha comprobado? ¿Es de fiar la fuente?
#30 Voy a probarlo. Te digo ahora
¿También si lo hago dentro de una máquina virtual?
#13 Es unix el que monta dispositivos como si fueran ficheros, de ahí que borrando el sistema de ficheros termines borrando un firmware con permisos de escritura como es el UEFI. Y eso #23 #35, es independiente del tipo de unix, o la políticas que use.
#74 Me cuesta mucho creer que una vm ofrezca acceso directo al guest al hardware. Se supone que precisamente eso es lo que no tiene que hacer. Pero no voy a poner la mano en el fuego porque no lo he mirado.
#74 En VMWare al menos el UEFI también es virtual:
https://communities.vmware.com/docs/DOC-28494
Es decir, que ese comando no se cargaría el hardware, sólo la máquina virtual.
#35 Alguna máquina virtual implementa UEFI? #preguntaseria
Ah! y otra cosa por si alguien no lo sabe. Si te tiras desde un décimo piso posiblemente te mates.
y los del PP, a martillazos, buag pardillos
Otra nueva prueba de por qué un programa monolítico que gestiona todo no es buena idea?
#13
¿Te refieres al UEFI?
#23 Se refiere a systemd.
Pero en un mundo en el que la última moda son containers corriendo microservicios, irremediablemente vamos de cabeza a que una mierda como systemd se implemente en todas partes, para que así en el microcontainer todo se pueda gestionar fácilmente.
Y al que todavía ande con servidores, pues a ese que le den morcilla (o que se pase a OpenBSD, que es un buen momento).
#29 Creo que la nueva versión de Slackware todavía no implementa systemd. Pero en cuanto a Patrik le de por meterlo, me cambio a FreeBSD.
#42 ¿y eso por qué? (o sea, detállame todas esas cosas que hacen tan malo systemd y por qué matan el espíritu de slackware, por favor)
#75 ...detállame todas esas cosas que hacen tan malo systemd y por qué matan el espíritu de slackware, por favor.
Que te detalle qué??
Tu crees que yo entro en MNM para pasar exámenes?? o para ahorrarte el trabajo de leer y experimentar??
En 1993 trabajabamos (en mi empresa) con una versión de Unixware (en ese momento de NOVEL, después de SCO y más tarde de Caldera). Recuerdo que era un rollo instalar una copia de aquel OS en los primeros PC, sobre todo en los primeros Compaq; y a principios del año siguiente un técnico nos habló de un sistema libre y abierto que era compatible con el Unixware, pero más potente y manejable.
Lo de más manejable no era cierto. Nos costó mucho instalar aquella cosa que ocupaba unos cuantos diskettes y un CD con aplicaciones. Lo único que teníamos en común era la Shell.
En el proceso de aprendizaje se incluía un nuevo sistema de arranque, diferente al System V que conocíamos, que iniciaba los demonios de forma individual o en solitario; al estilo BSD. Como tampoco conocíamos los BSD, nos hicimos con ellos y los aprendimos (unos más y otros menos); yo todavía me acuerdo aunque hace años que no uso más que FreeBSD y a veces tengo que echar mano de mis propios HOWTO para hacer algunas cosas:
https://thingoldedoriath.wordpress.com/2005/11/30/compilacion-y-optimizacion-del-kernel-en-freebsd
Pero sigo teniendo una Slackware instalada (junto a otros OS del tipo GNU/Linux) porque me acostumbré a manejar los RC de esa forma tan sencilla y sobre todo "por separado" y sin enlaces que todo lo complican.
Y esa es una de las razones por las que prefiero el arranque tipo BSD al System V. Por otra parte, todo lo que hace más vulnerable a un OS (en cuanto a su estabilidad) no me parece adecuado. Y con sistemas tan grandes y centralizados como Systemd se pierde mucho de la modularidad que antes hacía a los OS Linux, muy tolerantes a fallos.
En Slackware sigue siendo muy fácil parar un servicio sin que eso afecte a todo el sistema.
Lamento no tener tiempo para más. Ahora tengo que hacer la cena, después comérmela, después ver una película...
Saludos cordiales.
#29 ¿Y la solución es seguir usando SysVinit u otro init de los que fueron diseñados cuando las máquinas no eran ni siquiera multinúcleo, que encima esté basado en scripts, en una época donde ahora conseguir procesadores de varios núcleos está al alcance de todos?
Yo ya trabajo con Debian 8 en servidores y usando gestión de servicios al 100% usando systemd y sigo sin comprender el odio que le teneis algunos. De hecho ahora mismo facilita mucho más el control del sistema aparte de que ahora está integrado con el kernel. El journal que tiene es simplemente fantástico y no el síndrome de diógenes que generaba SysVinit que te volvias hasta loco.
#84 No entiendo a qué te refieres con lo de "máquinas multinúcleo". No veo qué tiene que ver eso con Systemd ni en qué lo hace mejor a los demás inits.
Systemd es horrible simeplemente porque tira a la basura toda la lógica de los sistemas Unix, reinventa la rueda, la reinventa MAL, introduce varios órdenes de complejidad innecesaria en algo que no debería tenerla y, de paso, añade con ello miles de puertas y agujeros en lo que antes era simple, sencillo y seguro.
Systemd es una aberración, así de claro. Que haga "más fácil" una o dos cosas (no veo en qué puede ser "más fácil" gestionar servicios de una máquina con systemd, la verdad, aunque tampoco soy sysadmin... ) no significa que sea un buen sustituto a los anteriores inits ni mucho menos "algo que necesitábamos", como te lo quiere vender el Poettering quien, por cierto además, es un puto maleducado de mierda y un insolente que va por las listas de correo de desarrolladores hablándole a la gente como si estuviera en el Menéame o el Barrapunto y a veces hasta insultando o diciéndole a desarrolladores de sistemas que llevan toda la vida programando que "no tienen ni idea", literalmente.
Los sistemas de tipo Unix están diseñados separando claramente el userspace del kernelspace y este tío ha arrejuntado todo en un mondongo que en ocasiones ni siquiera es capaz de explicar con qué motivo ni por qué. Se dedica a cacarear por ahí que "ahora todo es más fácil" y cuando se le hacen preguntas comprometidas acerca de las brechas de seguridad que pueden haber con tal o cual, se limita a dar la callada por respuesta o a decir que "ya te lo miro".
#100 Simplemente que SysVinit no ejecutaba grupos de servicios a la vez, lo hace en forma de arbol y de uno en uno según el orden que tenga etiquetados los scripts en las carpetas rcX. No tiene sentido que un sistema siga funcionando así cuando máquinas de ahora pueden procesar más de un arranque a la vez.
De alguna forma habia que innovar pero tampoco estar todo el rato en mismos conceptos. Mira X.org que está pidiendo a gritos que lo maten. Tiene muchisima basura de código porque se han dedicado a hacer parches e incluso parches de parches. No vamos a estar en lo mismo y por lo que veo no hay un fork al systemd con un planteamiento mejor (Y seria bastante asombroso que un sistema de inicio que está siendo lo que todas las distros están implementando fuese un problema de seguridad).
Sobre el user/kernel space, SysVinit que yo sepa se gestiona todo bajo root, incluyendo los arranques y paradas de servicios (Luego ya según como esté programado el servicio en cuestión, delega el trabajo a un usuario sin privilegios), así que en eso no hay ningún cambio. La diferencia es únicamente que systemd está integrado en el kernel y que para ejecutar init tiene su propia sintaxis. A nivel de usabilidad no he visto ningún cambio que me mosquee y sobre problemas de seguridad me informaré a ver en lo que dices pero como dije antes, muy asombrado me dejaria que hiciesen un sustituto lleno de brechas de seguridad.
#100 OpenBSD tiene rcctl. Hace lo mismo que Systemd, pero sin comerse todo lo demás.
#29 vamos de cabeza a systemd por algún motivo.
#29 Los BSD tienen cosas como jails mucho antes que docker y su megamonstruo jodiendo NAT .
El año de Linux en la papelera
#71 El problema es de las placas base, no del sistema operativo.
En Windows también se puede hacer. Si te hubieras leído la noticia lo hubieras visto.
Y por eso es malo estar logueado como root todo el rato. Ajo y agua.
Pues a pesar de que me consta el prestigio de Phoronix, no me creo esta noticia. A ver, si borro los archivos de la UEFI sólo tengo arrancar de otro disco duro, en el peor de los casos previamente desconectando el que he borrado con mis manos de árbol. ¿Me equivoco?
#48 Creo que si. Cuando se refieren a borrar archivos de UEFI, no se refieren a los archivos que normalmente tienes en el disco duro para arrancar UEFI, sino a archivos que directamente se almacenan dentro de la implementación UEFI de tu placa base
#66 Hay gente que monta los archivos UEFI para poder manipularlos cómodamente desde el sistema operativo (es innecesario) pero no veo cómo eso va a modificar la BIOS, que es donde está la "implementación UEFI de tu placa base". Que yo sepa tendrías que hacer un flash de la BIOS, lo que no se logra borrando los ficheros del UEFI, por ejemplo mediante rm -rf /
#66 Pero en ese caso, entrando en el SETUP del PC deberías de poder re-formatear los datos de la UEFI. Que al borrarlos la placa quede inservible me parece un error muy grave de diseño.
Esta es la mejor manera para dejar un sistema totalmente inservible:
http://cdn.losporque.com/wp-content/uploads/2012/10/explosao-da-bomba-atomica-62920.jpg
Hay otra cosa que también deja el equipo inservible: Sacar el disco duro y liarse a martillazos con él.
#45 En realidad eso solo se carga el disco, esto te deja la placa frita
#45 que se lo digan a Barcenas. Venga ya me lo pongo yo
A mi esto me parece más un problema de linux, por la facilidad de que se utilice mal ese comando que desde windows. Es obvio que si puedes modificar cosas del ordenador siempre puedes cargarte algo, pero esa funcionalidad "inesperada" me parece más probable en linux.
#76 en Güindouns también hay una terminal que necesitas a poco que te de problemas el ordenador eh...
#96 Sí, pero es fácil olvidar que existe, dame 5 minutos.
Un amigo hizo un script
rm -rf /$VAR y... Var era nula
#99 Jajajaja menudo artista. Enseñale a usar condicionales hombre.
Oj que interesante. Necesitaba saberlo para seguir viviendo.
no lo creo
alias rm='rm --preserve-root'
Hace una semana hice casi lo mismo en un servidor Ubuntu 14.04 LTS que dejaba atrás por migración a otro:
rm -rf *
Ejecutado como root y desde el raíz.
Lo gracioso es que el terminal SSH siguió funcionando, aunque me quedé casi sin comandos ni para hacer el shutdown final. Si luego arrancaba o no, ya sería cosa de preguntarle al siguiente usuario...
En otro Ubuntu 14.04:
root@archivos:~# ls -lisa /sys
total 4
1 0 dr-xr-xr-x 13 root root 0 feb 1 20:08 .
2 4 drwxr-xr-x 22 root root 4096 ene 24 06:09 ..
Ta vez no es UEFI, pero /sys (.) está sin permisos W y en /etc/fstab no figura como punto de montaje nada relacionado, puede que haya algo que desconozco al respecto.
#88 ¿no te salía más a cuenta borrar las particiones, crearlas de nuevo y formatear en otro formato? Lo digo porque tarda una burrada menos