Biblioteca Online : ¡La Suscripción ENI por 9,90 € el primer mes!, con el código PRIMER9. Pulse aquí
¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
  1. Libros
  2. LINUX
  3. Instalación de Linux y de los paquetes de software
Extrait - LINUX Dominar la administración del sistema (5ª edición)
Extractos del libro
LINUX Dominar la administración del sistema (5ª edición)
1 opinión
Volver a la página de compra del libro

Instalación de Linux y de los paquetes de software

Instalar una Ubuntu

1. Soporte de instalación

A continuación se explica, paso a paso, cómo instalar una Ubuntu. La versión LTS 20.04 Focal Fossa se publicó en abril de 2020, la instalación que se desarrollará aquí será sobre la versión 19.10 (no LTS) que se encontraba disponible cuando se estaba escribiendo la última versión de esta obra. Es muy parecida a la versión LTS, incluye el nuevo instalador y gestor de paquetes Snappy. La instalación la haremos en modo texto porque representa el mejor método para un servidor de empresa. Para la instalación en modo gráfico, descargue la versión Desktop. La instalación se efectuará usando la ISO ubuntu-19.10-live-server-amd64.iso Si desea efectuar la misma instalación, debe obtener la imagen ISO (en el libro usamos la versión de 64 bits) desde el enlace: http://releases.ubuntu.com/eoan/

Las versiones previas (desde la 12.04, en el momento de escribir esta obra) cuentan todavía con acceso desde el enlace http://releases.ubuntu.com/. Grabe esta imagen como CD o llave USB, o utilice esta imagen ISO para arrancar una máquina virtual. Para las necesidades de este libro, Ubuntu se instaló en una máquina virtual Virtualbox 6.1, que es un producto gratuito, disponible bajo Linux, Windows y MacOS, y por lo tanto existe una versión libre. Esto es el ideal para probar las docenas de distribuciones y de configuraciones sin borrar el disco duro de su equipo.

La configuración de la máquina virtual es la siguiente:

  • 2 VCPUs (se puede usar 1 VCPU)

  • 4 GB de RAM (se pueden usar 2 GB de RAM)

  • 20 GB de disco (para los ejemplos futuros) (se pueden usar 2 GB)

  • Controlador gráfico VMSVGA

  • Dispositivo apuntador Tableta USB

  • Acceso NAT y puente de red (para poder conectar a través de SSH desde su red personal) 

La segunda red en modo adaptador puente no es obligatoria si decide asociar un puerto de red al de la máquina virtual para el acceso SSH, por ejemplo el puerto 2222 hacia el puerto 22. Para ello, tiene que ir a las propiedades de red de la máquina virtual, y en la configuración del primer adaptador NAT editar la redirección de puertos en las opciones avanzadas.

Podrá hacer evolucionar la máquina virtual según sus futuras necesidades....

Instalación de CentOS

1. Soporte de instalación

A continuación, se muestra el proceso de instalación paso a paso de una distribución basada en paquetes en formato RPM con un instalador en modo gráfico. Siendo menos sobria que Ubuntu pero más extendida, la instalación de una distribución CentOS es idéntica a la instalación de Red Hat en el ámbito empresarial.

La instalación se ha realizado en una máquina virtual Virtualbox configurada del mismo modo que con la distribución Ubuntu, a excepción de la elección de Red Hat (64 bits) en el asistente de configuración. Si desea instalar la misma distribución, diríjase al sitio https://www.centos.org/download/.

La instalación se ha realizado desde una imagen ISO mínima de CentOS 8, descargada desde el enlace: https://vault.centos.org/8.1.1911/isos/x86_64/CentOS-8.1.1911-x86_64-boot.iso

Use obligatoriamente Tablet USB como dispositivo apuntador, el proceso de instalación podrá tener problemas si se redimensiona la pantalla durante la instalación con otros sistemas. Por otro lado, use VMVBOX como controlador gráfico, en el caso contrario podría encontrar un bloqueo en el momento de la instalación del gestor de arranque. Para las capturas, se ha utilizado VboxSVGA.

2. Arranque del soporte

Configure su ordenador para que arranque a través del soporte e inícielo.

images/cet02_020.png

Pantalla de inicio de soporte de la instalación CentOS

La pantalla de inicio del soporte de instalación ofrece una gran cantidad de opciones. La primera entrada permite instalar o actualizar el sistema, la segunda verificar el soporte después de instalar el sistema. La entrada Troubleshooting permite acceder a un menú suplementario que ofrece una instalación empleando un controlador básico compatible con cualquier tarjeta gráfica, un arranque desde una copia de seguridad del sistema que acompaña al soporte de instalación, o efectuar un test de la memoria.

De este modo, se puede reparar su sistema incluso si es imposible iniciarlo desde el disco duro. El arranque con el disco local redirige el arranque a su disco duro.

Una opción curiosa es la comprobación de la memoria. Muchas disfunciones de un equipo se asocian a menudo erróneamente...

Red Hat Package Manager

1. Noción de paquete

Al contrario de otros sistemas operativos, con Linux y Unix no es habitual disponer de software proporcionado con un programa de instalación interactivo (y no install.exe). Algunos editores proponen scripts de instalación y, muy a menudo, éstos sólo descomprimen y desarchivan algunos archivos.

Con Linux es muy habitual disponer de varios productos, herramientas, actualizaciones, etc. en forma de paquetes (packages). Un paquete es un archivo que contiene el producto a instalar y unas reglas. Según su contenido, su tamaño puede ser muy imponente. El núcleo y todos sus módulos son, por ejemplo, proporcionados en esta forma. Las reglas pueden ser múltiples:

  • Gestión de las dependencias: sólo se podrá instalar el producto si los productos que él mismo utiliza están ya presentes.

  • Preinstalación: se deben prever acciones antes de poder instalar el producto (cambiar derechos, crear directorios, etc.).

  • Postinstalación: se deben prever acciones después de la instalación del producto (parámetros de un archivo de configuración, compilación anexa, etc.).

En las distribuciones Red Hat, SuSE y derivadas (CentOS, Fedora, OpenSUSE...), el formato de paquete por defecto es el RPM (Red Hat Package Manager). En Debian y sus derivados (Ubuntu...) es el formato DPKG (Debian Package). Además de por el formato, se diferencian principalmente por las herramientas.

El hecho de disponer de la información de dependencias permite obtener herramientas eficaces que pueden solas resolverlas en cascada. Al instalar un paquete, la herramienta podrá instalar todas las dependencias necesarias. A veces se pueden especificar varias ubicaciones (repositorios) para estos paquetes, ya sean locales (disco duro, CD-Rom, DVD, etc.) o remotos (HTTP, FTP, NFS, etc.).

Debemos favorecer el uso de un paquete previsto para su distribución cuando esté disponible. Si no es el caso, a veces se puede utilizar un paquete de un producto competidor o volver a compilar el producto por sí mismo.

Se simplifican mucho las actualizaciones de un sistema Linux que utilizan un sistema de empaquetado. Para pasar de la versión de un producto a otra, basta con recuperar el paquete del producto en versión superior e instalarlo. Todas las actualizaciones...

YUM

YUM es a los archivos rpm lo que APT es a los archivos dpkg: un programa de gestión de paquetes. Recupera los paquetes dentro de los repositorios y gestiona las dependencias en lugar de usted. YUM significa Yellow dog Updater Modified. Se utiliza principalmente en las distribuciones Red Hat (versiones Enterprise) y Fedora, pero se puede utilizar en cualquier distribución de tipo RPM si los repositorios asociados lo soportan.

Nota importante: a partir de las versiones 8 de Red Hat Enterprise Linux 8 y CentOS 8, yum se ha convertido en un alias del comando dnf, que lo hace reemplazado y es completamente compatible con el primero.

$ ls -l /usr/bin/yum 
lrwxrwxrwx. 1 root root 5 Aug  4  2020 /usr/bin/yum -> dnf-3 

Los comandos y ejemplos siguientes se basan en un servidor CentOS en versión 8. El archivo de configuración es /etc/yum.conf.

1. Configuración de los repositorios

Red Hat Enterprise Linux 8 y CentOS 8 aceptan repositorios suplementarios a los que ya están presentes por defecto. Es el caso, por ejemplo, del repositorio EPEL que añade muchos paquetes que no se encuentran en las distribuciones.

Los repositorios se ubican o en el archivo de configuración principal, o en el directorio /etc/yum.repos.d. El formato es el siguiente:

[epel] 
name=Extra Packages for Enterprise Linux $releasever - $basearch 
#baseurl=https://download.fedoraproject.org/pub/epel/$releasever/
Everything/$basearch 
metalink=https://mirrors.fedoraproject.org/metalink?repo=
epel-$releasever&arch=$basearch&infra=$infra&content=$contentdir 
enabled=1 
gpgcheck=1 
countme=1 
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8 

El repositorio se llama (nombre corto) epel y contiene:

  • name: el nombre largo del repositorio, detallado.

  • baseurl: la URL del repositorio.

  • Metalink (o mirrorlist): siempre se debe proporcionar una URL específica, mirrorlist apunta a una lista de URL. YUM se encarga de encontrar la más rápida.

  • gpgcheck: requiere una verificación de la firma GPG del repositorio.

  • enabled: si no está definido o en 1, el repositorio está activo.

  • gpgkey: ruta de la clave pública GPG.

  • failovermethod: opción que quedará pronto obsoleta en dnf. Indica cómo seleccionar el repositorio en caso de fallo (lista secuencial aleatoria).

Las URL de los repositorios pueden ser locales...

Debian Package

1. dpkg: el gestor de paquetes Debian

El comando dpkg es el equivalente de rpm para las distribuciones Debian y derivados, entre las cuales se encuentra Ubuntu. Hace lo mismo o casi que rpm. Los paquetes Debian llevan una extensión .deb para reconocerlos y disponen de la misma información y mismos medios que un paquete rpm. El comando dpkg es el encargado de la instalación, la creación, la supresión y la gestión de los paquetes Debian.

Se suele colocar la base de datos dpkg en /var/lib/dpkg. Los archivos de este directorio tienen formato de texto. Sin embargo, no edite los archivos manualmente. El archivo /var/lib/dpkg/status contiene la totalidad de los paquetes conocidos por dpkg con su estado.

# grep ^Package: /var/lib/dpkg/status | grep linux 
Package: console-setup-linux 
Package: libselinux1 
Package: linux-base 
Package: linux-firmware 
Package: linux-generic 
Package: linux-headers-5.3.0-18 
Package: linux-headers-5.3.0-18-generic 
Package: linux-headers-generic 
Package: linux-image-5.3.0-18-generic 
Package: linux-image-generic 
Package: linux-modules-5.3.0-18-generic 
Package: linux-modules-extra-5.3.0-18-generic 
Package: util-linux 

2. Instalación, actualización y eliminación

La opción -i, o --install, instala los paquetes que se pasan como argumento.

# dpkg -i mipaquete.deb 

Observe que, al igual que rpm, dpkg no gestiona las dependencias. Si faltan dependencias, el comando le informará. En este caso, tendrá que instalar las dependencias de la misma manera antes de instalar su paquete.

Puede pedir la instalación de todos los paquetes presentes en el árbol con el parámetro -R, la inicial de Recursividad. En este caso, indique como argumento un nombre de directorio y se instalarán todos los paquetes presentes en el directorio, así como sus subdirectorios.

# dpkg -R directorio 

Se actualiza de la misma manera que se instala, con -i. Si instala un paquete ya presente, dpkg efectúa su actualización. Así, una instalación o una actualización respeta la metodología siguiente:

  • Extracción de los archivos de control del nuevo paquete.

  • Cuando ya se instaló una antigua versión del mismo paquete, se ejecuta el script presupresión del antiguo paquete.

  • Ejecución...

Administrador APT

1. Fundamentos

Ya sea con rpm o dpkg, el problema sigue siendo el mismo: estas dos herramientas detectan las dependencias de los paquetes para autorizar o no su instalación, pero no las resuelven. Dicho de otro modo, si una dependencia de un paquete no está, no se instalará salvo si se resuelve la dependencia: 

  • o instalando previamente los paquetes que faltan,

  • o indicando en la misma línea la ruta de estos mismos paquetes.

Asimismo, en el momento de la actualización se presenta un problema con los archivos de configuración. ¿Qué se debe hacer?

APT permite resolver estos problemas gestionando las dependencias en lugar de usted. APT significa Advanced Packaging Tool. En vez de especificar un paquete (local o remoto), se encarga de los repositorios de paquetes situados en un CD, un DVD, en un directorio local, en una fuente remota en Internet (ftp, http), etc.

Un repositorio contiene un conjunto de paquetes que dependen o bien los unos de los otros, o bien de otros paquetes procedentes de otros repositorios. APT puede gestionar varios repositorios en varios sitios. Se las arregla solo: cuando usted instala un paquete, también instala sus dependencias (si las encuentra).

2. Los repositorios

a. Configuración

Los repositorios se definen en el archivo /etc/apt/sources.list y también en los archivos ubicados en /etc/apt/sources.list.d. El archivo siguiente proviene de una instalación Ubuntu Xenial, los comentarios y las líneas vacias se han ignorado.

$ cat /etc/apt/sources.list |egrep -v "^(#|$)" 
 
deb http://ftpd.udc.es/ubuntu xenial main restricted 
deb http://ftpd.udc.es/ubuntu xenial-updates main restricted 
deb http://ftpd.udc.es/ubuntu xenial universe 
deb http://ftpd.udc.es/ubuntu xenial-updates universe 
deb http://ftpd.udc.es/ubuntu xenial multiverse 
deb http://ftpd.udc.es/ubuntu xenial-updates multiverse 
deb http://ftpd.udc.es/ubuntu xenial-backports main restricted 
universe multiverse 
deb http://ftpd.udc.es/ubuntu xenial-security main restricted 
deb http://ftpd.udc.es/ubuntu xenial-security universe 
deb http://ftpd.udc.es/ubuntu xenial-security multiverse 

Los repositorios se ubican físicamente en el árbol de directorios del servidor. El comando genbasedir permite crear un repositorio. La sintaxis de una línea...

Administrador aptitude

1. ¿apt o aptitude?

Aptitude es un administrador de paquetes Debian con una interfaz en modo texto. Sustituye a APT (y apt-get), a los que puede reemplazar. En un sistema, puede utilizar uno u otro, o los dos al mismo tiempo.

¿Por qué aptitude? Según la opinión de muchos usuarios, APT no es perfecto. El argumento más avanzado es su gestión de dependencias, aunque tanto uno como otro instalarán su paquete de forma correcta, una diferencia evidente es visible durante la desinstalación.

APT:

  • apt-get remove eliminará el paquete pero no sus dependencias, aunque no se utilicen. Habrá que ejecutar apt-get autoremove o autoclean.

  • APT cuenta con cerca de veinte comandos (como apt-get y apt-cache) para gestionar el conjunto de posibilidades. 

  • APT no cuenta con un shell interactivo.

Aptitude:

  • Aptitude eliminará el paquete y sus dependencias si estas ya no se utilizan.

  • Aptitude solo tiene un comando unificado.

  • El comando aptitude, arrancado solo, ofrece un shell interactivo.

Estas son solo algunas diferencias. Los usuarios de Debian son más proclives a utilizar aptitude, mientras que los usuarios de Ubuntu utilizan APT con más frecuencia. Es solo una cuestión de elección.

2. Instalación

En Debian, aptitude se instala por defecto. En Ubuntu, habrá que instalarlo con APT (qué ironía):

$ sudo apt-get install aptitude 

3. Utilización

La sintaxis de la línea de comandos es cercana a la de APT. He aquí una tabla que le ayudará:

Comando

Efecto

update

Actualiza los repositorios.

install

Instala los paquetes indicados.

remove

Elimina los paquetes, al igual que sus dependencias.

markauto

Elimina el paquete cuando ya no se utiliza, de manera automática (ahora o más tarde).

purge

Elimina los paquetes y sus archivos de configuración.

safe-upgrade

Actualiza los paquetes a una versión más reciente, pero mantiene coherencia con las versiones mayores instaladas (idéntico que apt-get upgrade).

full-upgrade

Actualiza los paquetes indicados, incluidas las versiones mayores o las dependencias que hayan evolucionado.

search

Búsqueda simple o avanzada de paquetes.

La búsqueda es más avanzada que con APT. En particular, aptitude ofrecerá el conjunto de...

Zypper

Zypper es un comando (CLI) que hace uso de la biblioteca ZYpp (libwypp) que permite instalar, actualizar y suprimir programas (packages) y también los repositorios correspondientes. Los packages están en formato rpm, lo que hace de Zypper un equivalente de YUM o DNF. Zypper es utilizado por SUSE Linux y también por su versión libre openSUSE,

Se puede resaltar que la biblioteca que administra las dependencias de Zypper ha sido reutilizada por Red Hat para DNF.

El uso de Zypper puede ser sorprendente, pero su enfoque es probablemente el mejor, ya que evita accidentes. Cuando dispone de varios repositorios de packages, Zypper conserva un rastro de los repositorios que se han utilizado como fuente de instalación para cada aplicación. Cuando se hace una actualización, esta información (o más bien la del distribuidor o vendor) le permite actualizar los paquetes que provienen del mismo distribuidor, incluso en el caso de que una versión más reciente esté disponible desde otro repositorio. En este caso, habrá que autorizar a Zypper para que cambie de repositorio.

He aquí una explicación de Zypper.

1. Gestion de los repositorios

Así como APT o YUM, Zypper utiliza repositorios. Estos archivos de configuración se encuentran en /etc/zypp/repos.d y llevan el sufijo « .repo ».

pc-164:/etc/zypp/repos.d # ls -l 
total 44 
-rw-r--r-- 1 root root 177 Mar 19 11:20 openSUSE-Leap-15.2-1.repo 
-rw-r--r-- 1 root root 189 Mar 19 11:20 repo-debug-non-oss.repo 
-rw-r--r-- 1 root root 193 Mar 19 11:20 repo-debug-update-non-oss.repo 
-rw-r--r-- 1 root root 172 Mar 19 11:20 repo-debug-update.repo 
-rw-r--r-- 1 root root 167 Mar 19 11:20 repo-debug.repo 
-rw-r--r-- 1 root root 179 Mar 19 11:20 repo-non-oss.repo 
-rw-r--r-- 1 root root 173 Mar 19 11:20 repo-oss.repo 
-rw-r--r-- 1 root root 192 Mar 19 11:20 repo-source-non-oss.repo 
-rw-r--r-- 1 root root 170 Mar 19 11:20 repo-source.repo 
-rw-r--r-- 1 root root 202 Mar 19 11:20 repo-update-non-oss.repo 
-rw-r--r-- 1 root root 183 Mar 19 11:20 repo-update.repo... 

He aquí el contenido del archivo repo-oss.repo. Se le parece mucho al de un repositorio YUM, y también hace el uso de alias.

pc-164:/etc/zypp/repos.d # cat repo-oss.repo 
[repo-oss] 
name=Repositorio principal 
enabled=1 ...

Snappy

1. Imágenes oficiales

Mientras transcurre la instalación de Ubuntu, una sección del programa de instalación le propone añadir packages Snap. Estos son administrados por Snappy, un software que permite instalar otros softwares y un gestor de packages diferente de rpm o dpkg.

Snap es una imagen del sistema de archivos comprimida, en formato Squashfs, que contiene todo lo necesario (la aplicación y sus dependencias) para poder ejecutar una aplicación. Puede descargarse la imagen en local o desde una store, e iniciarla. De hecho se trata de un contenedor como es el caso de Docker, por ejemplo. Las aplicaciones instaladas usando este método utilizan mecanismos de aislamiento. 

Un servicio llamado snapd se ejecuta en segundo plano. El comando snap le permite administrar los packages snap: hacer un listado, instalar, suprimir, actualizar, iniciar, parar… Se trata de un gestor de packages como APT o YUM y, a la vez, de una aplicación que controla el entorno de ejecución.

Las imágenes se montan usando un periférico de loopback en un directorio en el seno de /snap.

La idea es interesante ya que simplifica, por ejemplo, las múltiples dependencias y se acerca bastante a lo que ya existe en otros sistemas (como MacOS) para aislar aplicaciones. Este modelo, prometedor, puede parecer un poco pesado y consumidor de recursos. Si se mezclan Snap y APT, podemos encontrar procesos duplicados o incluso triplicados. Y, sin embargo, es problablemente el futuro de la gestión de packages y gracias a este sistema se pueden, por ejemplo, tener distintas versiones de una misma aplicación o de un idioma, sin que eseo provoque conflicto alguno.

Si este asunto le interesa puede dirigirse hacia proyectos, totalmente libres, como Zero Install.

2. Uso de Snap

Para buscar un package Snap, use find:

# snap find sudoku 
Nombre        Versión                Editor      Notas  Resumen 
sudoku-game   1.1                    1bsyl       -      Sudoku...

Instalar desde las fuentes

1. Obtener las fuentes

A veces no es posible obtener un programa o una librería desde un paquete para su distribución. En este caso, queda la solución de compilar e instalar uno mismo el programa desde las fuentes.

Eso es posible para la mayoría de los programas en Linux gracias a las ventajas de los programas libres y de la licencia GPL tal como quedó definida en el primer capítulo, o con otras licencias libres. Cualquier programa libre va acompañado con sus fuentes. Por lo tanto, usted mismo puede volver a reconstruir el programa al compilarlo.

Es posible obtener un archivo fuente en diversos sitios web, como por ejemplo SourceForge. Suele ser un archivo comprimido en formato tgz (archivo tar comprimido con gzip) o tar.bz2 (archivo tar comprimido en formato bzip2). Contiene:

  • el código fuente en forma de archivos .c, .h, .cpp, etc., según el lenguaje;

  • a veces un archivo Makefile que permite automatizar la compilación del producto; 

  • a menudo un archivo .configure que permite generar el archivo Makefile en función de su instalación y de varias opciones.

2. Requisitos y dependencias

Para compilar su producto, tiene que respetar unos requisitos:

  • presencia de la herramienta make;

  • presencia del compilador o de los compiladores necesarios, en particular gcc;

  • presencia de las dependencias: librerías, intérpretes, etc.

Este último punto es muy importante. Si falta una dependencia, se arriesga a encontrarse con varios problemas:

  • no logrará preparar las fuentes para la compilación;

  • la compilación generará errores;

  • se compilará el programa, pero con menos opciones;

  • no se iniciará el binario resultante.

El comando ./configure le proporcionará las dependencias que faltan y su versión si es posible. En este caso, puede instalarlas desde los paquetes de su distribución, o bien instalarlas desde las fuentes.

Cuando se compila desde las fuentes sin pasar por un gestor de paquetes, se pierde una parte de la gestión de las dependencias. Cuando instala paquetes que dependen de una versión de la herramienta instalada desde las fuentes, es posible, si las dependencias se basan en la existencia de un paquete y no de un archivo, que el gestor le impida instalar el paquete. Busque correctamente entre los repositorios, oficiales o no, si el programa...

Gestionar las librerías compartidas

1. Fundamentos

Una librería compartida es un archivo particular que contiene una lista de funciones, o API, accesible a cualquier programa que lo necesite sin tener que volver a escribirlas. Al contrario de lo que sucede con las librerías estáticas, el programa accede de manera dinámica a las funciones situadas en un archivo aparte. N programas diferentes pueden acceder a las funciones propuestas por la librería. Las librerías agrupan funciones propias de un dominio o un conjunto de dominios coherentes: tratamiento de imágenes, sonido, acceso a una base de datos, etc.

Un conjunto de funciones propuestas por una o varias librerías compartidas forma una API, Application Programming Interface, y a veces se agrupan en un framework que ofrece una solución completa para un dominio dado.

Se establece un vínculo entre el programa y una librería compartida durante la etapa de la edición de los vínculos por el editor de vínculos ld, al cual puede llamar el compilador gcc con la opción -l<lib>.

Otra posibilidad para un programa consiste en utilizar la función C dlopen, que abre una librería dinámica como un archivo y que accede a las funciones contenidas mediante punteros de funciones.

Si un programa depende de una librería compartida y ésta está ausente, el programa no podrá funcionar nunca más.

En Linux (y Unix en general), las librerías compartidas se llaman Shared Objects (so) en el sentido en el que se trata de archivos de objetos sin bloque de instrucción main. Los nombres de los archivos asociados llevan el sufijo .so.

Una librería puede disponer de varias versiones, que pueden ser o no compatibles, y se puede precisar la versión durante la edición de los vínculos. También es posible determinar una versión por defecto.

2. Lugar de almacenamiento

Por convención se colocan las librerías compartidas en directorios llamados lib:

  • /lib: librerías de sistema básicas, vitales.

  • /lib64: librerías de sistema de 64 bits.

  • /usr/lib: librerías de usuario básicas, no necesarias para el boot.

  • /usr/local/lib: librerías locales para los programas para la máquina.

  • /usr/X11R6/lib: librerías del entorno X Window.

  • ...

$ find /usr/lib -name "*.so"...