Mostrando entradas con la etiqueta actualizar kernel sin reiniciar. Mostrar todas las entradas
Mostrando entradas con la etiqueta actualizar kernel sin reiniciar. Mostrar todas las entradas

martes, 26 de enero de 2010

5 mitos sobre Linux

Artículo original: Five *nix Myths Busted

[El siguiente artículo puede ser leído en su idioma original sosteniendo el puntero del mouse sobre cada oración, entonces aparecerá en un cuadro la oración original]


Me encanta la mitología y no hay nada como escuchar un mito sobre tecnología para hacer mi día completo. Hoy mismo alguien aplicó uno de los siguientes mitos en una conversación conmigo. Yo no dije nada pero me dio la idea para este post. Éstos son los cinco mitos relacionados con los sistemas *nix que oigo cada vez más a menudo, se trate de personas técnicas y no técnicas por igual. Usted se sorprendería de que tan a menudo, incluso la persona más técnica, proclama estos mitos entre sí y hacia el transeúnte más desprevenido y poco entendido. Tengo que morderme la lengua cuando los oigo. Y ahora que los van a conocer, espero que también se les arruine su día cuando alguien se deslice en Mitolandia con una de estas gemas.

Están en orden inverso de lo mucho que me irritan. Disfruten.

5. Loguearse como root - Este mito de la larga data de que nunca se debe iniciar sesión como root es ridículo. La lógica es algo así: Iniciar sesión como un usuario estándar, a continuación, "su" para root o usar sudo para ejecutar algo como root. Sí, es más seguro hacerlo así, pero no mucho. Si "su" para root, entonces usted es un usuario root. Si utiliza sudo entonces está ejecutando un programa, editando un archivo o haciendo lo que sea que estás haciendo como root.
Debería deshabilitar la capacidad de ssh como root? Sí.
Deberías de nunca iniciar sesión como usuario root en un sistema? No.
Deberíamos usar siempre sudo para ejecutar comandos únicos como root? Si tenemos miedo de lo que podríamos hacer. Pero hay un problema
también con sudo. Si usted está activamente haciendo cosas con sudo, sólo tiene que introducir su contraseña una vez durante una sesión, a menos que vaya a darse una vuelta o tome una pausa de cinco minutos, luego se le pedirá de nuevo.
Si somos descuidados, vamos a cometer errores irrecuperables, independientemente de la utilización de "su" o sudo. Mejor tengamos cuidado.

4. "su" es SuperUsuario - OK, esto es un mito light pero vale la pena desmentirlo. Como muchas personas utilizan este término de forma incorrecta, la terminología es casi aceptable. El "su" término NO significa superusuario (super usuario). Significa usuario sustituto (substitute user). Se utiliza para iniciar la sesión como otro usuario aunque muchos lo utilizan para acceder o asumir características del usuario root.
Y para aquellos que todavía no me creen, esto es desde la página del man de "su":


su  -  ejecuta una shell con identificadores de grupo y de usuario distintos

No hay superusuario. Hay usuarios y el usuario root. Y no hay sustituto para esos términos.

3. Los sistemas *nix no se infectan con virus - Este mito es un poco gris para algunas personas. Un sistema *nix puede obtener virus en determinadas circunstancias. Un virus es un programa de ordenador que puede copiarse a sí mismo hacia otros ordenadores infectándolos con una carga perjudicial o potencialmente perjudicial. Una de las circunstancias en las que los sistemas *nix podrían obtener virus es donde el usuario tiene acceso a un sistema *nix y otros sistemas *nix en la misma red. Este usuario puede implementar un programa que podría replicarse a sí mismo y entregar su carga en todos los sistemas. El virus sería aún más eficaz si la cuenta de usuario ha adquirido o tiene acceso de usuario root y escribió a cron para que se disparara a una hora y fecha específica. Una vez que se entrega la carga, borraría sus huellas y a ella misma.
Así que, decir que es imposible que los sistemas *nix tengan virus no es correcto. No es común pero puede suceder. Y, sí, incluso el
amado Mac es susceptible y ahora es *nix-based.

2.
Los sistemas *nix son más seguros - Este es un mito muy común que se arremolina alrededor de los sistemas *nix y no espero que mi post haga que se salgan corriendo. Cualquier sistema puede ser inseguro o puede hacerse que sea muy seguro. No tiene nada que ver con el sistema operativo. Tiene todo que ver con cómo se implementa ese sistema operativo. Tuve un compañero de trabajo con un sistema FreeBSD que fue hackeado. FreeBSD es conocido por su elevada seguridad. Pero se necesita una reflexión cuidadosa sobre lo que se está haciendo. Se requiere de parches, actualizaciones y modernización para evitar problemas de seguridad. También hay que tener vigilancia para asegurarse de que sus sistemas están actualizados y no se vean comprometidos.
Recuerde que ningún sistema es completamente seguro. Solíamos decir que la única manera de garantizar un sistema es desconectarlo, pero eso no es cierto, alguien todavía puede agarrarlo y llevárselo. No olvidemos la seguridad física.

1. Nunca tendremos que reiniciar - Me encanta este. Cada
nerd *nix desinformado en el mundo le dirá que usted nunca tendrá que reiniciar un sistema *nix. Es ridículo, la verdad. Para aquellos de nosotros que existimos en el mundo real, sabemos que tenemos que reiniciar el sistema, y debemos hacerlo con regularidad. Algunas empresas reinician el sistema semanal, mensual o trimestralmente. Donde actualmente trabajo, es trimestral.
Hay buenas razones para reiniciar y algunas de ellos son: el mantenimiento del hardware y actualizaciones, cambios de kernel, parches importantes, deshacerse de los procesos zombis, diagnóstico y para refrescar la memoria.
Una vez utilice un servidor de base de datos Oracle (Solaris) que tenía un tiempo de actividad de alrededor de 5 años, que es realmente estúpido, y he aquí por qué. Los administradores del sistema necesitaban hacer algunos parches importantes en ese sistema, pero tenían miedo, ya que había estado arriba durante tanto tiempo. El sistema también necesitaba una actualización de memoria porque estaba apaleado. (Añadir "apaleado" a la lista de razones para reiniciar el sistema).
Una vez que el sistema fue parcheado y reiniciado, hubo muchos errores. Montones y montones de errores. Los problemas que había acumulado durante los últimos años que, si se toma uno por vez, podrían haberse resuelto, pero después de que vimos lo que había sucedido, nadie pudo determinar qué hacer a continuación. Habíamos actualizado la memoria RAM y reiniciado el sistema. Se mantuvo defectuoso y finalmente fue dado de baja y sustituido.
La moraleja de la historia es que los administradores de sistemas responsables habrían hecho sus deberes diligentemente (y su trabajo) y mantenido el sistema adecuadamente. Sí, así es, de hecho, necesario reiniciar el sistema *nix.

Leer más >>
......
......
......
No olvides comentar esa es la mejor forma de incentivar el trabajo (y si puedes pasa el link del blog)...

martes, 24 de noviembre de 2009

No reiniciar Ubuntu depués de una actualización (Ksplice)




Esta es una nueva herramienta pensada en especial para los encargados de Servidores ya que sirve justamente para evitar el peligroso acto de reiniciar la máquina cuando haya una actualización del Kernel.

Debemos tomar en cuenta que el programa tiene dependencias de terceros por lo tanto deberemos autorizar una licencia en la cual simplemente marcaremos una casilla y pincharemos adelante (muy a lo Windows : o).


Instalación

Primero descargamos el archivo .deb de la página oficial. Tenemos la opcion para Karmic o para Jaunty, la descargamos y después le damos doble click para instalar o simplemente elegimos la opción de abrir con GDebi como se muestra en la imagen a la derecha.

Posteriormente, iniciamos la instalación y se nos solicitará como es común nuestra contraseña, la ingresamos y esperamos hasta que nos aparezca una nueva ventana. Dicha ventana es la que ya había mencionado anteriormente, lo que hace es verificar que estemos de acuerdo con la licencia bajo la que se rige, hago esta descripción puesto que puede que estemos desacostumbrados a aceptar licencias en GNU/Linux.



Una vez aceptada la licencia, continuamos el proceso y veremos que, al finalizar la instalación, nos aparecerá una nueva ventana la cual nos brindará la opción de buscar las actualizaciones del Kernel, o instalar las que estén disponibles.


Ahora podemos elegir la opción de instalar o de buscar las actualizaciones. Adicionalmente, Kslice nos mostrará una "K" en nuestro panel superior con la información acerca de las actualizaciones disponibles (mostrando un signo de admiración "!" dentro de un triangulo si hay alguna o solamente la "K" si no las hay).

Otras herramientas

Con Kslice se instalaran otras herramientas muy útiles en la terminal:
  • uptrack-upgrade: Descarga e instala las principales actualizaciones del Kernel en nuestra computadora.
  • uptrack-install PAQUETE: Descarga e instala paquetes específicos (siendo "PAQUETE" el nombre de la actualización).
  • uptrack-remove PAQUETE: Remueve un paquete especifico (siendo "PAQUETE" el nombre de la actualización).
  • uptrack-show PAQUETE: Muestra la información detallada de un paquete especifico (siendo "PAQUETE" el nombre de la actualización).
Recuerdo que en alguna ocasión hablaba con unos amigos de lo útil que sería tener una herramienta que permitiera hacer actualizaciones sin necesidad de reiniciar la PC, en especial si se trata de un servidor con datos importantes e imprescindibles, donde, por lo general, se opta por simplemente omitir las actualizaciones automáticas las cuales muchas veces son importantes para mantener la estabilidad del sistema así como su seguridad.

Así que por fin tenemos una herramienta que nos podrá facilitar la vida y brindarnos la satisfacción de poder seguir con nuestras tareas pese a cualquier actualización. ¡Qué lo disfruten!


Leer más >>
......
......
......
No olvides comentar esa es la mejor forma de incentivar el trabajo (y si puedes pasa el link del blog)...
Powered By Blogger