Errores comunes de los administradores linux

Leo en los blogs de techrepublic (fijo en mis rss) los supuestos errores típicos que cometen los administradores de sistemas linux:

• Instalar aplicaciones de diversos tipos. Tres tipos de problemas. Añadir repositorios suele ser una una invitación a que yum o apt-get lo pasen mal, yo creo que en un sistema de producción debía estar prohibido. Instalar software a partir de las fuentes, para mi más que un problema es un engorro. Creo que se puede hacer que no moleste al resto de la instalación con un correcto compilado y selección de prefijo. Instalar software propietario es el último y a lo que más miedo le tengo. Las empresas suelen creer que su producto es el centro del mundo y no suelen tener mayor interés en hacer las cosas bien (que sería entregar un rpm o deb para cada una de las grandes versiones RHEL o Debian) así que te encuentras con un problema distinto en cada caso.
• Retrasar actualizaciones. Los sistemas linux tienen, con razón, fama de estabilidad y además las actualizaciones en los mejores casos suponen reiniciar servicios o el mismo sistema y en los peores hace que los servicios con nuevas versiones dejen de funcionar con viejas configuraciones (esto no debería ocurrir, pero ocurre sobre todo cuando no se conocen bien el funcionamiento o los ficheros de configuración). Hay casos horribles que es cuando las nuevas versiones traen nuevos errores lo que suele ser raro en sistemas estables de verdad (Debian, RHEL, ...). Esto provoca que exista una tendencia a diferir las actualizaciones a semanas con poco trabajo y se acaba actualizando de Pascuas a Ramos. En fin, hay que evitarlo y esforzarse en planificar actualizaciones periódicas y mantener las configuraciones en orden. Un linux suele ser estable y es difícil que haya problemas de seguridad (entiéndase comparando con la habitual alternativa) pero también hay fallos así que actualizar es más que necesario.
• Password de root. Si no usas sudo mereces ir al infierno pero en fin hay gente que aún no lo entiende así que la contraseña acaba siendo "memorizable" y acabamos haciendo el ridículo. Busca un sistema que mezcle números, letras y carácteres simbólicos y piensa en usar sudo que además te permite registrar los comandos que lanzas.
• Evita la línea de comandos. Yo no estoy de acuerdo con esto pero el autor indica que los comandos son más propensos a recibir errores (cierto) y que la mayor parte de tareas se puede realizar con "menos lesivas" interfaces gráficas. El razonamiento es interesante, ahora bien ya lo indica el autor un sysadmin debe conocer profundamente la interfaz de comandos y es muy difícil hacer eso cuando no se practica (esto lo digo yo), además los comandos quedan registrados en los logs con mayor facilidad que las pulsaciones en las cónsolas gráficas.
• No mantener kernels funcionales instalados. En RHEL el kernel es el paquete que siempre se instala y nunca se actualiza. Por defecto se mantienen todos los kernels que se han instalado y es una gran idea.
• No tener copia de seguridad de los ficheros de configuración. En realidad el pecado es no hacer backup o hacerlo malo. Personalmente añadiría mantener un control de versiones de los ficheros de configuración con documentación completa sobre el motivo de cada cambio.
• Arrancar un servidor con X. Esto directamente merece ir al infierno.
• No comprender los permisos. Parece que lo del 777 o 644 lo entiende cualquiera pero en la práctica pocas gentes entienden las implicaciones de los permisos o los permisos setuid y setgid. Para acabar en RHEL sufrimos de los etiquetados Selinux (debianitas cuidado que a este paso os toca dentro de poco). Algún día tengo que hablar de Selinux o mejor algún día puede que entienda ese pedazo bicho.
• Entrar como root. Otra cosa que te lleva al infierno y por enésima vez; USA SUDO! (se nota que en mi empresa no me dejan implantarlo y muchas veces me tengo que...).
• Ignorar los log. Conocer los registros que mantiene un servicio te puede evitar o solucionar muchísimos problemas. Lo mejor mantener sistemas de monitorización y registro de logs (Nagios, Cacti y muchos más son grandes alternativas) y si queréis elevar la seguridad llevar los logs a servidores remotos.