Cómo juguetear con Linux y no morir en el intento

Conozco gente a quien le encanta Linux, pero que siempre está reinstalándolo porque se lo ha cargado intentando hacer algo que no sabía muy bien cómo hacer. Quizá un manazas que se cree está aprendiendo a ser un manitas, o quizá simplemente le guste hackear cosas. Aquí va una breve guía para quienes están en esa situación (y empiezan a hartarse).

Haz las pruebas en una máquina virtual

Todas las distribuciones Linux vienen con alguna herramienta de virtualización. Quizá la mejor en relación sencillez/funcionalidad sea VirtualBox, aunque también tenemos virt-manager para quienes necesiten más funcionalidades o Cajas para quienes necesiten más sencillez.

Si vas a empezar a trastear sin saber muy bien si va a funcionar, siempre es mejor hacer las pruebas en un entorno virtual, el cual puedes restaurar a una versión anterior con dos clicks, o eliminar y re-crear con otros dos. Tu máquina anfitriona seguirá intacta, sin importar cuánto destroces la virtual.

Crea un usuario limitado para las pruebas

Esta es otra alternativa a la máquina virtual, para cuando necesitas hacer pruebas en un entorno real para no perder rendimiento. Quizá si tienes que instalar un juego o algo así…

Realmente es muy difícil que un usuario sin permisos de superusuario pueda llegar a cargarse una instalación Linux, o siquiera cualquier cosa que no sea su $HOME, así que créate un usuario para las pruebas y no te permitas usar sudo desde esa cuenta.

Si algo sale mal, eliminas el usuario, eliminas su carpeta, lo vuelves a crear, y asunto arreglado.

Si sale bien, coges lo que has hecho, te lo copias a la $HOME de tu usuario normal, le haces un chown, y eliminas el usuario de pruebas y su carpeta.

Instala todo el software en paquetes

Evita ante todo instalar software que no venga empaquetado.

  1. Busca los paquetes para tu distribución.
  2. Si no hay, busca para otra distribución que use tu misma paquetería.
  3. Si no hay, busca para otra distribución que use paquetería distinta, y transfórmalo a la de tu distribución con herramientas como alien.
  4. Si no hay, crea tu propio paquete. No es muy diferente de compilar a mano, pero se hace todo automáticamente y es más fácil actualizar, desinstalar y encontrar errores en la compilación.

Puedes mirar el tutorial que hice hace tiempo de cómo empaquetar en RPM. De entrada te diré que para hacer un RPM sólo necesitas el código fuente del programa y un fichero de texto en el que le das las órdenes para que lo compile e instale.

Como nota adicional, los paquetes RPM forman parte del LSB. Para entendernos: toda distribución Linux debe permitir instalar paquetes RPM (aunque sea mediante convertidores) para ser considerada oficialmente una distribución Linux, de modo que son un buen lugar para empezar.

Instala los servidores en Docker

Docker es, quizá, la tecnología más influyente que ha surgido el año pasado. Permite crear servidores de la forma más fácil posible, y redistribuirlos igual de fácil.

Si vas a instalar un servidor de lo que sea, busca en hub.docker.com, y si hay una imagen oficial (o al menos confiable) instálalo desde ahí.

No es el objetivo de esta entrada enseñarte a usar Docker, pero te garantizo que si administras sistemas (en definitiva, si todo lo que has leído hasta ahora no te suena a chino), aprender a usarlo será el tiempo mejor invertido de toda tu carrera.

Usa control de versiones para guardar los cambios de /etc

En /etc es donde se almacenan las configuraciones para todos los servicios del sistema. A veces no hay más remedio que cambiar alguna, así que es bueno que tomes la costumbre de usar algún sistema de control de versiones (como Git o Mercurial) para no perder el rastro de los cambios que hagas.

Todo el software no empaquetado va en /usr/local

Si por algún motivo todos los consejos de arriba no te son suficientes, toma este último: el prefijo /usr/local en las distribuciones Linux se utiliza para colocar el software que no viene empaquetado en ningún sitio y que sólo está disponible localmente en tu máquina.

/usr/local tiene a su vez subdirectorios similares a los mismos que tiene /usr, pero el administrador del sistema ya sabe que todo lo que haya ahí no va empaquetado.

También está el prefijo /opt para cuando el software viene en un paquete difícil de encajar en la estructura de /usr/local. Es habitual que se usen subdirectorios de /opt para poner el programa, y se vinculen con ln -s los binarios en /usr/local/bin.

Puedes repasar el Filesystem Hierarchy Standard si te estás liando.

En resumen: si tienes que instalar cosas a mano, nunca te salgas de /usr/local ni /opt.

Conclusión

Estos son simplemente algunos principios que creo que podrán ayudarte a no cargarte tu instalación cada semana. De todas formas, algo puede salir mal, así que no te desesperes. Si no me hubiera pasado a mí cientos de veces, no habría podido darte todos estos consejos, así que ¡a reinstalar! La próxima vez saldrá mejor.😉

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s