Capítulo 2: Instalación de Linux y administración de paquetes

(Tema 102)
En este capítulo hablaremos sobre los pasos a seguir y los puntos a tener en cuenta
antes de instalar Linux. También explicaremos cómo administrar el software instalado
y mostraremos cómo agregar nuevos programas cuando sea necesario.
Uno de los pasos previos más importantes al instalar Linux y en preparación para su
uso consiste en crear particiones y sistemas de archivos. Una partición es una división
lógica que se hace a un dispositivo de almacenamiento con el propósito de definir un
espacio determinado para un uso en particular. Por otro lado, un sistema de archivos
puede definirse (en este contexto) como la forma en que se estructurarán los
contenidos (archivos y directorios) de dicha partición.

Disposición de unidades de almacenamiento

Antes de instalar Linux, es importante dedicar algunos minutos para determinar cómo
utilizaremos el espacio de almacenamiento disponible de forma eficiente. Por lo
general, lo dividiremos en secciones individuales (utilizando particionado tradicional
o volúmenes lógicos), con tamaños adecuados para el uso del sistema. Por ejemplo, si
un servidor cumplirá con la tarea de alojar directorios personales de usuarios reales
que utilizarán activamente el sistema, se deberá asignar un tamaño importante para la
partición donde se montará /home. Por otro lado, si el equipo se va a emplear para
instalar y probar múltiples kernels, la partición destinada a /boot deberá estar
preparada para alojar la cantidad de archivos necesarios.

Diseño de particiones
Teniendo en cuenta el uso que se le vaya a dar al sistema, nunca debemos permitir
que la partición asociada con / se llene, debido a que eso ocasionaría errores en el
funcionamiento de los servicios e incluso podría llegar a inhabilitar al usuario root
para iniciar sesión. Teniendo esto en cuenta, veamos qué consideraciones debemos
tener en cuenta para la creación y la asignación de espacio de cada partición:
1. El directorio /etc siempre debe debe estar dentro de la partición destinada al
directorio raíz. Dicho de otro modo, no se le debe asignar una partición dedicada.

2. Como regla general se prefiere utilizar particiones separadas para /home, /var, y
/tmp. Hay que tener en cuenta que el uso de estos directorios es un tanto difícil
de estimar en un principio.

3. En el caso de que planeemos instalar un número importante de aplicaciones de

terceros, es buena idea apartar una partición dedicada para /opt también.
4. No hay un porcentaje o fórmulas fijos que en la práctica se aplique a cualquier
escenario imaginable. Por ese motivo también será necesario recurrir al buen
juicio a la hora de crear particiones.
5. El espacio de intercambio (swap) preferentemente debe estar ubicado en un
dispositivo separado del resto por cuestiones de rendimiento. Por lo general el
tamaño de swap suele ser de 1.5 a 2 veces el tamaño de la memoria física (RAM),
aunque no es necesario que supere los 8 GB.

6. La partición destinada a /boot debe poder ser accedida desde el principio del
proceso de arranque, por lo que no debemos alojarla en una unidad de red
(preferentemente tampoco en una unidad extraíble).

Es posible que la documentación de algunas distribuciones sugiera ciertos valores

para particiones. En ese caso la experiencia del administrador indicará si son factibles
de acuerdo con el espacio de almacenamiento disponible.

Sistemas de archivos
Los sistemas de archivos más utilizados hoy en día son ext4 y xfs. Veamos algunas
características de ambos:
ext4 (tomado de la documentación oficial):
• Tamaño máximo de sistema de archivos (generalmente se extiende a toda la
partición): 1 EiB = 1024 PB (1 PiB = 1024 TiB, 1 TiB = 1024 GiB)

• Tamaño máximo de archivos: 16 TiB

• Cantidad máxima de subdirectorios: 64.000

• Journaling: permite la recuperación de archivos que estaban siendo escritos en el

momento de un fallo del sistema. Si bien esta característica no elimina totalmente
las posibilidades de encontrar archivos corruptos, sí contribuye a la confiabilidad
del sistema de archivos y a la rapidez del chequeo de los mismos.

• Permite aumentar o disminuir el tamaño del sistema de archivos.

xfs:
• Tamaño máximo de sistema de archivos (generalmente se extiende a toda la
partición): 8 EiB en sistemas operativos de 64 bits y de 16 TiB en 32 bits.

• Tamaño máximo de archivos: 9 EiB

• Journaling

• Es posible aumentar el tamaño del sistema de archivos pero no disminuirlo

Para ver más detalles sobre xfs podemos consultar el sitio oficial del proyecto.

Creación de particiones y sistemas de archivos

En Linux, la herramienta tradicional para administrar particiones basadas en MBR
(presente por defecto en computadoras fabricadas hasta 2009 aproximadamente) es
fdisk, mientras que desde 2010 en adelante (particiones basadas en GPT) se comenzó
a utilizar también otra utilidad llamada gdisk.

Es importante aclarar que todas las operaciones relacionadas con la

creación de particiones, sistemas de archivos, y montaje de dispositivos
deben ser realizadas por root o con un usuario con permisos de
superusuario.

Cabe aclarar que el estándar GPT permite crear hasta 128 particiones primarias en un
mismo disco, y permite alcanzar tamaños de particiones no soportados por MBR (el
cual soporta hasta 2 TB y hasta 4 particiones primarias – si se necesitan más
particiones se puede reemplazar una de las primarias por una extendida que pueda
dividirse en múltiples particiones lógicas).
Para crear una partición con fdisk, utilizamos el comando del mismo nombre seguido
por el identificador de dispositivo en cuestión. Por ejemplo, para /dev/sdb:
fdisk /dev/sdb

En la pantalla siguiente podemos presionar la tecla m para ver el menú de ayuda como
se muestra en la imagen (por limitaciones de espacio no se alcanzan a apreciar todas
las opciones disponibles):
Las operaciones más usuales que podemos llevar a cabo a partir de este momento son
las siguientes:
• m: mostrar el menú de ayuda

• p: mostrar la tabla de particiones del dispositivo

• l: mostrar los tipos de particiones soportadas por fdisk

• n: agregar una nueva partición

• d: borrar una partición existente

• w: guardar los cambios en la tabla de particiones y salir

• q: salir sin guardar cambios

Algunos puntos importantes para destacar:

• Al crear una nueva partición, tendremos que confirmar si deseamos que sea una
partición primaria o una extendida. Si no hemos creado ninguna partición
todavía, deberíamos elegir primaria. Para el comienzo de la partición es
conveniente aceptar el valor ofrecido por defecto por fdisk presionando Enter.
Para la finalización de la misma es conveniente especificar el tamaño deseado de
la misma utilizando el signo + seguido de un número y de la nomenclatura M, o G
(por MB y GB, respectivamente).

• La primera partición de /dev/sdb recibirá el identificador /dev/sdb1, la

segunda /dev/sdb2, y así sucesivamente. Por defecto, al crear una nueva
partición, se le asignará el tipo Linux (83). Si deseamos cambiarlo, podemos
listar los tipos disponibles con L, elegir el adecuado, y luego asignarlo con la
opción t.
• Si en el dispositivo seleccionado existe más de una partición y deseamos borrar
una de ellas, tendremos que especificar el número de la misma (a partir del orden
en el que aparecen al mostrar la tabla de particiones).
• Antes de confirmar cualquier cambio realizado, es importante revisar la tabla de
particiones, ya que una vez que se guarden los cambios y se salga del menú de
fdisk es probable que los mismos sean irreversibles (lo cual es particularmente
crítico si hemos modificado una partición que contenía datos).

Por ejemplo:
En la imagen anterior vemos cómo crear una partición de 2,5 GB que recibió la
identificación /dev/sdb1. Luego de guardar el cambio volvimos a la línea de
comandos y con
fdisk -l /dev/sdb

podemos ver la tabla de particiones actual.

Importante: Utilizar un punto en vez de una coma al especificar el tamaño de las
particiones si estamos utilizando un sistema cuyo separador de decimales es el
primero.
Una vez que disponemos de una nueva partición, es hora de crear un sistema de
archivos sobre la misma a fin de poder utilizarla. La utilidad por excelencia para
realizar esta tarea es mkfs (entre sus variantes podemos destacar mkfs.ext4 y
mkfs.xfs para sistemas de archivos ext4 y mkfs, respectivamente).

Entre las muchas opciones de las que disponemos, -L en particular nos será de gran
utilidad para asignarle una etiqueta al sistema de archivos, mediante la cual podremos
identificarlo más fácilmente a la hora de montarlo y disponerlo finalmente para su uso
(tema que trataremos en el próximo post).
Para crear un sistema de archivos del tipo ext4 en /dev/sdb1 y asignarle la etiqueta
ALUMNO (el límite es de 16 caracteres) utilizaremos el siguiente comando:
mkfs.ext4 -L ALUMNO /dev/sdb1

El uso de gdisk es prácticamente idéntico a fdisk, por lo que no entraremos en

detalles sobre el primero en el curso.
Conceptos fundamentales de LVM (Logical Volume Management)
Aunque la certificación LPIC1 no requiere un conocimiento profundo sobre LVM, sí se
espera que el candidato conozca los conceptos fundamentales de esta solución de
almacenamiento:
1. LVM es un conjunto de herramientas que permiten la administración de unidades
de almacenamiento denominadas volúmenes lógicos.
2. Permite agrupar dispositivos físicos o particiones de manera tal que el sistema
los considere como una unidad.
– Cada uno de estos discos o particiones recibe el nombre de volumen físico
(o PV por sus siglas en inglés, de Physical Volume). Cada PV está dividido
en extensiones físicas (o PEs, de Physical Extents), que representan trozos
de espacio de almacenamiento.
– Utilizando una serie de PVs se crea un grupo de volúmenes (o VG por sus
siglas en inglés, de Volume Group).
– Finalmente, cada VG se divide en volúmenes lógicos (análogos a las
particiones tradicionales) que pueden ser redimensionados utilizando el
espacio disponible en el VG. Cuando un VG se queda sin espacio,
simplemente necesitaremos crear un PV adicional, agregarlo al VG, para
luego incrementar el tamaño del LV que lo necesite.
3. Provee flexibilidad para administrar el almacenamiento del sistema de manera
que pueda expandirse fácilmente cuando la necesidad así lo requiera.
Una ventaja adicional de LVM es que permite tomar instantáneas de los volúmenes
lógicos, las cuales pueden funcionar como copias de respaldo o ser utilizadas para
migraciones, pruebas, restauraciones, etc., sin afectar el funcionamiento del sistema
en su totalidad.

Particionado tradicional versus LVM

Para empezar, recordemos que al menos en MBR, hay una limitación en el número de
particiones primarias por disco. En el caso de que se tenga que redimensionar una de
ellas, se requiere mucho cuidado. Si bien es posible achicar una partición para darle
espacio a otra que haya quedado pequeña, este procedimiento causa los siguientes
inconvenientes:
• Provoca downtime. Esto significa que mientras estemos redimensionando las
particiones nadie más podrá utilizar el sistema. Si se trata de nuestro equipo
personal, los únicos afectados seríamos nosotros. Pero si estamos hablando de un
servidor al que necesiten acceder otros usuarios, esta alternativa puede no ser
viable.
• Requiere copias de respaldo. Si no se dispone de espacio extra en alguna
partición, no quedará más remedio que agregar otro disco al equipo. Si queremos
 utilizar el nuevo dispositivo para /home (por ejemplo), esto implicará mover
todos los archivos de los usuarios de la ubicación anterior a la nueva. ¿Por qué
esto es un inconveniente? Dependiendo del tamaño del backup, la restauración
agregará tiempo al downtime del que hablamos en el punto anterior.

Por otro lado, el redimensionado de los volúmenes lógicos bajo LVM se puede realizar
sin interrumpir el funcionamiento normal del equipo. Además, el procedimiento es
mucho más rápido que en el particionado tradicional. Los cambios quedan disponibles
a los usuarios inmediatamente sin necesidad de reiniciar ningún servicio.

El gestor de arranque GRUB

Un gestor de arranque es un componente de software que ayuda al hardware y al
firmware del equipo en la carga del sistema operativo. Esto incluye también la
posibilidad de elegir entre varios sistemas operativos o kernels instalados en el
equipo e inclusive el arranque desde una partición lógica.

GRUB significa GRand Unified Bootlader. Actualmente podemos llegar

a encontrarlo en sus dos versiones: GRUB Legacy (en sistemas más
antiguos) y el más nuevo GRUB2. Aunque su configuración varía según
la versión, los principios fundamentales del funcionamiento del gestor
de arranque son los mismos. En este capítulo haremos referencia
exclusivamente a GRUB2 al referirnos a GRUB. Para más detalles sobre
la versión legacy, podemos referirnos a la documentación presente en
el sitio del proyecto GNU.

Al interactuar con GRUB, el administrador puede configurar el proceso de arranque de

un sistema Linux. Si bien es probable que no tengamos que hacerlo a menudo, es
importante saber cómo proceder ante la necesidad. Situaciones tales como la
actualización del kernel o cambios en los dispositivos del equipo pueden requerir que
recurramos a las opciones del GRUB para bootear exitosamente el sistema.

No se recomienda editar el archivo de configuración

(/boot/grub/grub.cfg) del gestor de arranque directamente. Más
bien, se debe trabajar con los scripts presentes en /etc/grub.d. La
ubicación de los archivos de configuración puede llegar a variar según
la distribución y la versión.
Interactuar con GRUB
Durante el proceso de arranque, GRUB presenta un menú de modo texto que permite
elegir entre distintos kernels o sistemas operativos instalados en el equipo. Con las
flechas del teclado se puede elegir la opción deseada y presionar Enter para
confirmarla. Además, presionando las teclas c o e se puede acceder a una línea de
comandos básica o a las opciones de arranque, respectivamente. Mediante estas
herramientas podemos adaptar el inicio del sistema a nuestras necesidades, tal como
se aprecia en la siguiente imagen:

En la imagen de arriba podemos observar algunos puntos interesantes en la

configuración de la opción Debian GNU/Linux. Las mismas pueden editarse de ser
necesario. Luego, los cambios se guardan y se retoma el proceso de inicio al presionar
Ctrl + x o F10. Además:
• insmod se utiliza para cargar los módulos gzio, part_msdos, y ext2.

• Mediante la directiva set root (recuadro rojo con flecha apuntando hacia la
derecha) se le indica a GRUB dónde buscar el archivo grub.cfg. En este caso se
trata del primer disco (hd0). Más específicamente, en la primera partición bajo el
esquema de particionado tradicional (msdos1).
Si el sistema no inicia correctamente, podemos usar la shell de GRUB para realizar un
diagnóstico preliminar. Accedemos a la misma presionando la tecla c desde el menú
principal que mencionamos antes. Esta herramienta admite el uso de varios comandos
aceptados por Bash u otras shells.

Configuración de GRUB
En el archivo /etc/default/grub se indican las directivas de configuración de GRUB,
tales como el sistema operativo o kernel que se debe utilizar por defecto en el
arranque del sistema (GRUB_DEFAULT) o el tiempo (en segundos) que se debe
esperar antes de iniciar el inicio (GRUB_TIMEOUT), por nombrar dos ejemplos:
 El resto de las opciones están disponibles en la documentación de
GRUB2.

Además, el menú que muestra GRUB en el momento de arranque se construye a partir

de las indicaciones presentes en /etc/grub.d, el cual contiene una serie de scripts que
se ejecutan en orden (de acuerdo al número presente como parte del nombre de
archivo) como vemos en la siguiente imagen:

En vez de modificar estos scripts, podemos crear nuevos si deseamos

agregar opciones personalizadas. Bastará crear un archivo y agregarlo
al final de 40_custom para que se tenga en cuenta al momento de
inicio. Sin embargo, esta habilidad no es necesaria para el examen
LPIC1, por lo que no la trataremos en este capítulo.

Para aplicar los cambios que se hayan hecho en la configuración de GRUB utilizaremos
el comando grub-mkconfig (el nombre puede también ser grub2-mkconfig) pero
antes es una buena idea hacer una copia de la configuración original en el caso de que
necesitemos restaurarla:
cp /boot/grub/grub.cfg /boot/grub/grub.cfg.original
grub-mkconfig > /boot/grub/grub.cfg

Con el paso anterior lo que hicimos en realidad fue reconstruir el archivo de

configuración. Por otro lado, si por alguna razón GRUB se hubiera dañado y no
pudiéramos iniciar el sistema normalmente desde el disco, podemos reinstalarlo
luego de arrancar desde un dispositivo de emergencia (como un live CD/DVD/USB).
Esto es posible utilizando con grub-install seguida de la opción --boot-directory,
del directorio en el que previamente hayamos montado el directorio raíz, y el disco
donde deseamos instalar GRUB.
Por ejemplo:
grub-install --boot-directory=/tmp/root/boot dev/sda

Este método de rescate es más directo y versátil que en la versión legacy. La

desventaja de GRUB2 es que es un tanto más difícil de configurar que la anterior, pero
con la ventaja de ser más flexible.

Usar la shell de GRUB

A continuación, explicaremos cómo verificar si la ubicación del archivo de
configuración de GRUB (grub.cfg) fue especificada correctamente.
Luego de acceder a la línea de comandos mínima, ejecutaremos el comando ls. El
mismo nos devolverá la lista de dispositivos encontrados. A continuación, podemos
identificar los siguientes:
ls
ls (hd0,msdos1)
ls (hd0,msdos1)/
ls (hd0,msdos1)/grub
• hd0 (primer disco), que representa a /dev/sda, y las particiones hd0,msdos1
(/dev/sda1) y hd0,msdos5 (/dev/sda5).
• Otros discos: hd1, hd2, y hd3 (/dev/sdb, /dev/sdc, y /dev/sdd,
respectivamente).

Como podemos ver en la imagen de arriba, el archivo grub.cfg efectivamente está

ubicado en la partición 1 del primer disco. Esto concuerda con el valor que
observamos para la opción set root, tal como comentamos antes. Si repitiéramos el
comando ls para ver el contenido de otros dispositivos (hd0,msdos5 por ejemplo),
nos encontraríamos con un mensaje de error. El mismo nos alertaría sobre el hecho de
que se desconoce el sistema de archivos en cuestión. Lo que sucede en realidad es que
dicha partición no es la que contiene los archivos de arranque.
Para ver la lista completa de comandos que acepta la shell de grub podemos utilizar
help en cualquier momento. Por otro lado, presionando la tecla Esc se vuelve al menú
anterior. Además, presionando la tecla Tab se muestran las posibles opciones de
automcompletado.

Librerías compartidas
Una librería es un conjunto de funciones incluidas en un mismo archivo. Dichas
funciones por lo general son utilizadas por una variedad de programas que, en vez de
incorporarlas en su propio código (enlace estático), las llaman cuando es necesario
(enlace dinámico). Esto, por supuesto, requiere que dichas librerías existan en el
sistema previo al lanzamiento del programa. La ventaja reside en que en este último
caso solamente es necesario una copia de la librería, la cual es compartida por todas
las aplicaciones que la necesitan. El enlace estático, en cambio, requiere que cada
programa disponga de su propia copia y la incluya como parte del programa en sí.

Si una librería dada no está disponible, cualquier programa que la

necesite no podrá funcionar.

En el directorio /lib (o su equivalente para sistemas de 64 bits, /lib64)

encontraremos librerías compartidas que son utilizadas por los programas ubicados
en /bin y /sbin. En distribuciones modernas que utilizan systemd, /lib y /lib64 son
en realidad enlaces simbólicos a /usr/lib y /usr/lib64, respectivamente. En estos
directorios también encontramos las librerías de programas de usuario. Si bien son
importantes, estas últimas no son críticas para la operación del sistema.
Tomemos como ejemplo a /usr/bin/ssh y a /bin/cat. Utilizaremos el comando file
para determinar el tipo de cada archivo:
file /usr/bin/ssh
file /bin/cat

Como podemos ver en la imagen siguiente, ambos son programas enlazados

dinámicamente. En la misma imagen podemos ver, utilizando el comando ldd, cuáles
son las librerías de las que depende /bin/cat:
ldd /bin/cat

Para asegurar que los enlaces a las librerías se mantienen actualizados y en caché se
llama un programa llamado ldconfig como parte de la instalación de estas. Por lo
general no es necesario ejecutarlo manualmente a menos que hayamos hecho cambios
en el archivo /etc/ld.so.conf, que es donde se puede especificar la clase de ciertas
librerías si estas no contienen información suficiente para deducir esa información.
También podemos utilizar este archivo para indicar la ubicación de las librerías
necesarias para una aplicación en particular.

Al inspeccionar el contenido de la variable de entorno

LD_LIBRARY_PATH podemos ver la lista de directorios que se tienen en
cuenta para buscar librerías compartidas.

De esta manera es posible identificar las librerías compartidas que un archivo binario
ejecutable necesita para poder funcionar. Si por alguna razón no se encuentran
disponibles, podremos instalarlas como aprenderemos a continuación.

Administración de paquetes: vocabulario clave

En Linux a menudo se utilizan las palabras programa y paquete indistintamente,
aunque estrictamente hablando no sean iguales. Sin embargo, para nuestros
propósitos actuales podemos considerarlos equivalentes. De esa manera, cuando
hagamos referencia a la administración de paquetes estaremos hablando de
programas.
Comencemos definiendo a la administración de paquetes como el conjunto de tareas
de instalación, actualización, y desinstalación de recursos de software en nuestro
sistema. Hoy en día, la distribución de software en Linux se realiza de tres maneras
principales:
• Repositorios: son servidores centrales, mantenidos generalmente por una
distribución en particular, por la comunidad, o por otros terceros, en los que se
dispone de una colección de software para la instalación a través de Internet o de
una red local. En términos simples, un repositorio en Linux (también llamado
origen de software) es una colección de programas compatible con una
distribución dada. Un repositorio puede residir en un servidor remoto (que es lo
más común) o en un (o varios) dispositivos de almacenamiento locales.

• Archivos precompilados: son archivos ejecutables compatibles para una

distribución en particular y que pueden instalarse tanto a través de la red como
de manera local con una herramienta de la línea de comandos (en unos minutos
veremos esto en más detalle).
• Código fuente: es la forma inicial mediante la cual se distribuía software en
Linux en sus comienzos. Aunque ha sido superada por las dos anteriores, todavía
continúa usándose para ofrecer a los usuarios finales la posibilidad de compilar
un programa dado con opciones particulares. También se utiliza este método de
distribución de software para poner al alcance del público una versión más
actualizada que tenga mayores prestaciones que las presentes en los repositorios.

Cada distribución tiene distintas utilidades para la administración de paquetes.

Algunos de ellos (como yum o apt-get, para CentOS y Debian, respectivamente, junto a
los miembros de cada familia) tienen la habilidad de instalar junto con un programa
dado sus dependencias, es decir, aquellos paquetes adicionales que son necesarios
para el funcionamiento del primero. Por esa razón se los conoce más comúnmente con
el nombre de gestores de paquetes. Otros, como dpkg (Debian y derivados) y rpm
(CentOS y familiares), solamente instalan el programa presente en el archivo .deb o
.rpm pero sin instalar dependencias.

Más sobre repositorios

Por razones prácticas, no todos los repositorios disponibles son incluidos en la
instalación inicial de una distribución, pero pueden ser agregados luego cuando se los
necesite.
Todas las distribuciones mantienen sus propios repositorios oficiales, y además
dispone de otros que son mantenidos por la comunidad o usuarios particulares (en
este último caso generalmente se trata de repositorios que contienen algunos pocos
paquetes). Además, a menudo los repositorios se clasifican de acuerdo con el tipo de
software que contienen.
Aunque cada distribución difiere un poco de las otras en la forma en que maneja sus
repositorios, el principio de funcionamiento es el mismo:
1. Se configuran los repositorios en los que desea buscar software para nuestro
sistema.
2. Antes de utilizar los nuevos repositorios configurados se requiere actualizar el
índice de paquetes local de tal manera que refleje los contenidos de los
repositorios.
3. Se utiliza el gestor de paquetes de cada distribución para buscar información
sobre un paquete dado o directamente para instalarlo.

Para evitar congestionar un único repositorio, alrededor del mundo

existen varias réplicas idénticas o mirrors (espejos) de los repositorios
centrales de cada distribución.

En Debian, la lista de repositorios se mantiene en el archivo /etc/apt/sources.list y

en archivos ubicados dentro de /etc/apt/sources.list.d. En uno u otro caso, el
formato del archivo es el mismo según mostramos a continuación, tomando como
ejemplo el mirror de Debian provisto por la UBA (Universidad de Buenos Aires,
Argentina):
deb http://ftp.ccc.uba.ar/pub/linux/debian/debian/ stable main contrib no
n-free
deb-src http://ftp.ccc.uba.ar/pub/linux/debian/debian/ stable main contri
b non-free

Veamos ahora en detalle cómo están compuestas las líneas de arriba:

• deb y deb-src indican si el repositorio contiene paquetes binarios compilados
previamente o los paquetes fuente (que contienen todo lo necesario para que uno
compile un programa en particular), respectivamente.

• A continuación, encontramos la ruta al repositorio.

• Luego aparece la palabra stable (o el codename de la versión estable, como por
ejemplo stretch a la fecha de hoy).

• Finalmente, tenemos la lista de componentes del repositorio (no hacen falta que
figuren los tres necesariamente):

– main: contiene software compatible con las Políticas Debian de Software

Libre.
– contrib: contiene software compatible con las Políticas Debian de
Software Libre, aunque sus dependencias generalmente están incluídas en
non-free (ver a continuación).
 – non-free: software no compatible con las Políticas Debian de Software
Libre.
En el sitio oficial del proyecto Debian se puede consultar la lista de mirrors por países.
Podemos elegir el país en el que vivamos o utilizar la red de distribución de
contenidos (CDN) principal.
En CentOS o similares, los repositorios se configuran mediante archivos individuales
dentro de /etc/yum.repos.d. Tomemos como ejemplo a CentOS-Base.repo, cuyo
contenido podemos apreciar a continuación (no se muestra el archivo completo por
cuestiones de espacio):

En la imagen anterior podemos distinguir que la configuración de un repositorio

consta de:
• El nombre (base).

• Una lista de mirrors (mirrorlist) desde la cual se seleccionará el más próximo

geográficamente, o un repositorio fijo (baseurl).

• La indicación si se necesita utiliza la clave pública del repositorio.

• La ruta al archivo de la clave pública.

Cuando agreguemos un nuevo repositorio a CentOS se nos pedirá que

confirmemos que queremos instalar en nuestro equipo la clave GPG que
dicho repositorio provee por cuestiones de seguridad.
En algunas ocasiones será necesario agregar manualmente un repositorio de terceros.
Generalmente tendremos que recurrir a esta opción cuando deseemos instalar una
versión más reciente de un programa que la que se encuentre disponible en los
repositorios oficiales de la distribución.
Para ilustrar agregaremos el siguiente repositorio en
/etc/yum.repos.d/mariadb.repo para instalar la última versión estable de MariaDB.
En primer lugar, agreguemos las siguientes líneas dentro del archivo mencionado:
# MariaDB 10.3 CentOS repository list - created 2018-06-08 00:28 UTC
# http://downloads.mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.3/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

El nombre de los archivos de configuración de los repositorios que

añadamos manualmente deben finalizar en .repo.

Para asegurarnos de que nuestro sistema puede ver la lista completa y actualizada de
paquetes disponibles en los repositorios debemos sincronizar el índice local con los
mismos. En Debian y derivados lo hacemos mediante apt-get update, mientras que
en CentOS o similares utilizamos yum makecache fast.
En el próximo apartado explicaremos el próximo paso necesario a seguir antes de
efectuar la instalación propiamente dicha de un paquete proveniente de un
repositorio de terceros.

Administración de paquetes en Linux

Debian y derivados
Para instalar archivos .deb , utilizaremos el comando dpkg seguido de la opción -i o -
-install y de la ruta al archivo a instalar. Por ejemplo, para instalar mipaquete.deb
(presente en nuestro directorio actual de trabajo) utilizaremos el siguiente comando:
dpkg -i mipaquete.deb

Si posteriormente quisiéramos instalar una nueva versión del mismo programa

mediante un archivo .deb más reciente, podemos utilizar el mismo comando anterior.
En cambio, si necesitamos desinstalarlo emplearemos la opción -r (también puede ser
--remove) o -P (de --purge) simplemente incluyendo el nombre del paquete:
dpkg -r mipaquete
La diferencia entre --remove y --purge reside en que esta última remueve el paquete
junto con cualquier archivo de configuración que se pueda haber creado como parte
de la instalación, mientras que la primera no.
Finalmente, con -l podremos ver una lista de todos los paquetes instalados en el
sistema. Como la salida será extensa en este caso se recomienda que la visualicemos
con less o la filtremos con alguna herramienta como tail, head, o grep.
dpkg -l | head

Otras dos opciones muy útiles son --info y --contents. La primera nos permitirá ver
la información sobre el paquete en cuestión, mientras que la segunda nos mostrará el
contenido de este:
dpkg --info mipaquete
dpkg --contents mipaquete

De forma similar a --contents, podemos emplear --listfiles para ver los archivos
que se agregaron al sistema al instalar un paquete (sea que lo hayamos hecho
mediante dpkg o apt-get, como veremos a continuación).
Para asegurarnos de que un programa se instale con todas las dependencias
necesarias podemos utilizar el gestor de paquetes apt-get en vez de dpkg. La
herramienta asociada apt-cache también nos resultará útil para buscar programas en
los repositorios y para ver información detallada sobre alguno que haya captado
nuestra atención. Ambas utilidades (junto con otras) forman parte de APT (Advanced
Packaging Tool) que es el sistema de gestión de paquetes principal de Debian.
Luego de haber agregado repositorios en /etc/apt/sources.list o en algún archivo
dentro de /etc/apt/sources.list.d, sincronicemos la lista de paquetes disponibles con
los repositorios de Debian:
apt-get update

Luego de eso, podremos emplear

apt-cache search mipaquete

para utilizar a mipaquete como patrón de búsqueda, o si ya conocemos el nombre

exacto podemos emplear
apt-cache show mipaquete
apt-cache showpkg mipaquete

para ver información detallada sobre el mismo, o

apt-get install mipaquete
para instalarlo. Si agregamos la opción -f al comando anterior también podremos
completar cualquier instalación que hayamos llevado a cabo mediante dpkg y que no
se haya completado exitosamente por dependencias faltantes.

Para aceptar automáticamente los pedidos de confirmación podemos

agregar la opción -y al comando anterior. Esto puede resultar
particularmente útil en el caso de que vayamos a automatizar una
instalación (o actualización) de alguna manera. Lo mismo aplica al uso
de yum install en CentOS y similares.

Por otro lado, si mipaquete ya estuviera instalado y quisiéramos removerlo,

cualquiera de los comandos siguientes nos permitirá hacerlo:
apt-get remove mipaquete
apt-get purge mipaquete

El último de ellos no solamente eliminará mipaquete del sistema sino que también
hará lo mismo con cualquier archivo de configuración relacionado con el programa en
cuestión.
Para actualizar un paquete a la última versión disponible usaremos
apt-get upgrade mipaquete

Si en el comando anterior omitiéramos el nombre del paquete, el resultado sería que

se actualizarían todos ellos a la última versión disponible en los repositorios
configurados del sistema.

Reconfigurar paquetes
Es importante notar que durante el curso de una instalación por lo general se nos
ofrece la posibilidad de configurar el programa en cuestión. Si no lo hacemos en ese
momento, también podemos hacerlo posteriormente utilizando la herramienta dpkg-
reconfigure.

En primer lugar, podemos revisar la configuración actual con el comando debconf

seguido del nombre de un paquete dado. Usemos como ejemplo el paquete keyboard-
configuration, según se aprecia en la siguiente imagen:
debconf-show keyboard-configuration
Si vemos algo que queremos o vemos la necesidad de cambiar, ahora es el momento
de recurrir a dpkg-reconfigure. Siguiendo con el mismo ejemplo de arriba, ahora se
deberá utilizar el comando
dpkg-reconfigure keyboard-configuration

para hacer las modificaciones correspondientes utilizando solamente el teclado. La

ventaja de utilizar este método para configurar software ya instalado es que nos
evitamos tener que editar archivos de texto a mano. Incluso en el caso de que no todas
las opciones estén contempladas, nos ahorra trabajo.
Otra situación en la que dpkg-reconfigure puede resultar útil es para restaurar la
configuración de un paquete a su estado original. Si cometimos algún error y no
hicimos copias de respaldo antes de comenzar, esta herramienta puede ayudarnos a
salir del aprieto. Simplemente aceptando las opciones que se nos presenten por
defecto deberíamos resolver el inconveniente.

CentOS y similares
RPM (Red Hat Package Manager) es el gestor de paquetes utilizado por defecto en
Red Hat Enterprise Linux como en SuSE (y distribuciones derivadas como CentOS,
Fedora, u OpenSUSE). Fue desarrollado por Red Hat y luego adoptado por otras
distribuciones. Podemos decir que consta de 2 componentes fundamentales: 1) el
comando rpm, y 2) una base de datos local. Esta última contiene la lista de paquetes
instalados e información sobre estos y se encuentra dentro del directorio
/var/lib/rpm.
Para empezar, tomemos como ejemplo a bc-1.06.95-13.el7.x86_64.rpm. Podemos
descargar el mismo desde el listado de paquetes disponibles para CentOS 7. En el
nombre del archivo podemos encontrar a primera vista los siguientes datos:
• El nombre del paquete: bc
• La versión: 1.06-95-13.el7
• La arquitectura: x86_64
Por lo general, la instalación se realiza con las opciones combinadas -Uvh o -Fvh en
vez del simple -i (o su equivalente --install, también válidos). De las dos
alternativas anteriores, la primera instala o actualiza (según sea el caso), mientras que
la segunda solamente instalará el paquete y no realizará ninguna acción si ya existe
una versión previa del mismo. Para nuestra conveniencia, -v muestra el nombre del
paquete durante la instalación y -h imprime una serie de #’s para indicar el progreso
de la instalación. Ambas son útiles en particular si estamos instalando varios paquetes
a la vez.

Para desinstalar un paquete que hayamos previamente instalado con

rpm, utilizaremos la misma herramienta, pero esta vez con la opción -e
seguida del nombre del paquete. No es necesario incluir la versión de
este ni la arquitectura.

Otras opciones útiles del comando rpm que no pueden faltar en nuestro arsenal son
(siempre seguidas de -q, de query):
• -a: muestra la lista de todos los paquetes instalados.

• -l: lista de los archivos instalados por un paquete dado.

• -ip: ver información detallada sobre un archivo .rpm que no ha sido instalado.

• -f: devuelve el nombre del paquete que contiene el archivo que se especifica a
continuación.

• -Rp: muestra la lista de dependencias del paquete.

En la imagen siguiente vemos los siguientes ejemplos ilustrados:

• Verificamos si el paquete htop está instalado usando rpm -qa | grep htop

• Mostramos la lista de archivos agregados al sistema como resultado de haber

instalado htop con rpm -ql htop

• Vemos las dependencias del paquete tuxpaint mediante rpm -qRp tuxpaint-
0.9.22-1.x86_64.rpm
Para ver el contenido completo de un archivo .rpm utilizar los comandos rpm2cpio y
cpio de la siguiente manera:
rpm2cpio tuxpaint-0.9.22-1.x86_64.rpm | cpio -idv

A pesar de lo útil que es rpm, quizás la manera más práctica de instalar un programa
determinado (si es que se encuentra en los repositorios de nuestra distribución, o si la
versión disponible cumple con nuestras necesidades), es utilizar el gestor de paquetes
yum. El mismo contiene todas las utilidades necesarias para satisfacer las
dependencias requeridas y configurar el programa ya instalado (en síntesis, ¡nos
ahorra mucho trabajo!). Utilizando esta herramienta podemos:
• Buscar un paquete por palabra clave (mipaquete, por ejemplo): yum search
mipaquete

• Ver información sobre mipaquete: yum info mipaquete

• Instalarlo: yum install mipaquete

• Actualizar a la última versión disponible: yum update mipaquete

Tal como sucede en el caso de Debian con apt-get upgrade, si en este caso omitimos
el nombre del paquete se actualizarán todos los presentes en el sistema.
• Desintalarlo: yum remove mipaquete

• Averiguar en qué paquete está incluído un comando determinado (por ejemplo,

micomando): yum whatprovides "*/micomando"

La configuración de yum se encuentra en /etc/yum.conf. Si bien podemos agregar

repositorios en este archivo, por prolijidad y orden se prefiere hacerlo mediante
archivos individuales (con la extensión .repo) dentro del directorio
/etc/yum.repos.d como explicamos antes.
Cuando agreguemos un nuevo repositorio a CentOS se nos pedirá que confirmemos
que queremos instalar en nuestro equipo la clave GPG que dicho repositorio provee.
Sin este paso no será posible descargar ningún paquete de ese origen.
Si en algún momento nos interesa repasar la actividad de yum, podemos consultar el
archivo de registros (o logs) en /var/log/yum.log.
Ya sea cuando agregamos un repositorio de terceros (como en el caso de MariaDB
antes) o incluso en /etc/yum.repos.d/CentOS-Base.repo, podemos valernos de la
directiva enabled para indicar si se debe habilitar inmediatamente o no. Por ejemplo,
en la imagen podemos ver la configuración del repositorio centosplus y notar
enabled=1. Esto indica que centosplus está habilitado en nuestro sistema:

Debido a que centosplus contiene paquetes que son mejoras para los presentes en los
repositorios base y updates, es posible que queramos deshabilitarlo en ocasiones
para que no interfieran con estos últimos. Podemos hacerlo al editar el valor de la
directiva a enabled=0 antes de hacer yum update o bien indicar yum update --
disablerepo=centosplus. Lo mismo aplica si estuviera deshabilitado y quisiéramos
habilitarlo con yum update --enablerepo=centosplus.

El habilitar o deshabilitar un repositorio mediante la línea de

comandos tiene efecto solamente durante la transacción actual. Para
 hacerlo de manera permanente debemos cambiar el valor
correspondiente en la directiva enabled como mostramos antes.

En Fedora se ha comenzado a utilizar un gestor de paquetes llamado dnf desde hace

un par de años (fue presentado con la versión 18 y pasó a ser la herramienta por
defecto a partir de la 22). Guarda semejanza con las opciones disponibles de yum que
hemos visto, aunque es más rápido y consume menos memoria que su antecesor. El
proyecto Fedora provee documentación detallada sobre dnf en su sitio oficial.