Seamos claros con todas las carpetas bin y sbin (del estándar de jerarquía del sistema de archivos):
/bines para binarios a nivel de sistema/sbines para otros archivos binarios a nivel de sistema, principalmente para el cargador de arranque y los administradores del sistema./usr/bines para binarios no esenciales/usr/sbin- aquí es donde comienza el lío - ¿no son herramientas esenciales para los administradores de sistemas? ¿Qué significa? ¿Para experimentos?/usr/local/bin- no hay noticias sobre esta carpeta/usr/local/sbin- programas de administración del sistema instalados localmente. ¿De nuevo? Qué tal si/usr/sbin?
Entonces la pregunta es: ¿ Por qué hay tantos directorios y cuáles son los significados de /usr/sbiny ?/usr/local/sbin/usr/local/bin
Muchos programas se distribuyen a través de archivos y tenemos que construirlos a partir del código fuente. Normalmente tienen un archivo MAKE, por lo que es bastante fácil. Este proceso implica la creación de archivos en usr/local/lib, usr/local/bin... usr/local/lo que sea sin crear carpetas específicas para un programa determinado.
¿Por que es esto entonces?
Creo que no está bien porque si necesitamos eliminar el programa, tenemos que eliminar manualmente cada uno de sus archivos si el creador del programa no se encargó de ello.
Respuesta1
1. Estructura del directorio
Esto debería estar cubierto en elEstándar de jerarquía del sistema de archivos (2.3 PDF)
/bin/ Binarios de comandos esenciales que deben estar disponibles en modo de usuario único;
para todos los usuarios, por ejemplo, cat, ls, cp
/sbin/ Binarios esenciales del sistema, por ejemplo, init, ip, mount.
/usr/bin/ Binarios de comandos no esenciales (no necesarios en el modo de usuario único);
para todos los usuarios
/usr/sbin/ Binarios del sistema no esenciales, por ejemplo, demonios para varios servicios de red.
/usr/local/ Jerarquía terciaria para datos locales, específica de este host.
Normalmente tiene más subdirectorios, por ejemplo, bin/, lib/, share/
2. Instalación
Utilizo un administrador de paquetes siempre que es posible (por ejemplo, yum o apt-get). Esto es posible para una gran cantidad de aplicaciones; en algunos casos, es posible que deba agregar un repositorio. Mi segunda opción serían paquetes de nivel inferior, como RPM, y compilar desde el código fuente sería mi último recurso (pero algunas personas prefieren esto)
Algunos administradores de paquetes pueden instalar desde RPM (p. ej yum install oddity.rpm.)
Si está compilando desde el código fuente, probablemente no sea un gran paso crear su propio paquete para que el instalador del sistema sepa lo que ha hecho.
Entonces su problema se reduce a, por ejemployum remove packagename
La alternativa es mantener una buena documentación sobre todas las actividades realizadas por el administrador de sistemas (de todos modos, llevo un diario en un archivo de texto)
Respuesta2
Las cosas en todos los directorios */sbin tienden a ser útiles sólo para los administradores del sistema. Puedes mantenerlos fuera de tu RUTA si eres un usuario normal.
Los diferentes directorios no tienen mucho sentido si tiene una sola máquina Unix en un solo disco, pero tienen más sentido si tiene un sistema grande y diferentes particiones. Recuerde que muchos de estos hábitos se desarrollaron en los años 80 y 90, cuando los sistemas eran un poco diferentes.
/sbintiende a sermuypequeño. Estas son utilidades que necesitas cuando estás realmente agotado. Pondrías esto en una partición raíz mínima con /root y /lib. Las cosas en /sbin solían estar vinculadas estáticamente, ya que si su partición /usr está bloqueada, cualquier aplicación vinculada dinámicamente es inútil. fsck está aquí y vinculado estáticamente. Si depende de /usr, obviamente no puede fsck /usr/. Por supuesto, si la partición raíz tiene una manguera, estás muy jodido. Esta es la razón por la que se trata de una partición tan pequeña: reduzca las probabilidades de que se produzca un bloque de disco defectuoso utilizando muy pocos bloques aquí.
/usr/sbinLos binarios son herramientas generales de administrador de sistemas donde al menos puede acceder al modo de usuario único y montar todos sus volúmenes. Se les permite estar vinculados dinámicamente.
Las particiones separadas para /sbin (bueno, /sbin en /partición) y /usr también tienen más sentido si se recuerda que la copia de seguridad era muy costosa tanto en tiempo como en cinta. Si estuvieran en particiones separadas, podría programarlas de manera diferente.
/usr/localpuede ser un sistema de archivos de red. Por lo tanto, las herramientas de administrador de sistemas escritas localmente que se pueden compartir entre muchas máquinas a veces van a /usr/local/sbin. Obviamente, ninguna utilidad de reparación de red puede ir allí.
Nuevamente, muchas cosas tenían más sentido en máquinas grandes en un entorno de red en máquinas administradas con múltiples volúmenes, menos con una máquina Linux en una única partición raíz.
Respuesta3
Realmente deberías hacer que tu segunda pregunta sea una pregunta separada aquí en Superusuario. No tiene relación con el primero.
Sí, tener archivos por todos lados apesta. Por eso existen muchas soluciones de embalaje. RedHat creó RPM que se utiliza en todas partes. Solaris tenía su formato de paquete. HP/UX tenía el suyo, y hay apt y muchos otros formatos de paquetes. Mantenga las cosas en los lugares correctos (/usr/bin, /usr/lib) según corresponda, pero permita agregarlas y eliminarlas fácilmente.
Para la fuente, solía haber herramientas que le permitían configurar e instalar en un subdirectorio de /usr/local y manejaría enlaces simbólicos a /usr/local/bin por usted. Debido a la amplia proliferación de paquetes de herramientas, esto es menos necesario y olvidé sus nombres.
A algunas personas les gusta instalar en /opt/Nombre del paquetey mantener todo junto allí. Lo bueno: todo está en un directorio y la desinstalación es rm -rf /opt/packagename. Las desventajas de esto son tener que agregar /opt/packagename/bin a la RUTA de todos, y el hecho de que la gente generalmente no coloca /opt en una partición separada y usted llena la partición raíz.
Respuesta4
Para responder a su segunda pregunta:
normalmente los programas se distribuyen con el llamadogerente de empaquetación. Un administrador de paquetes generalmente recupera paquetes binarios (software compilado para una determinada plataforma) y los distribuye entre directorios (hay algunos que descargan el código fuente, lo compilan en su máquina y lo instalan). Por lo tanto, el administrador de paquetes sabe dónde residen los archivos que pertenecen a cierto "programa" (paquete) y, cuando desea eliminar el paquete, el administrador de paquetes se encarga de limpiar todo.
Incluso cuando compilas el código fuente por tu cuenta con
make
e instalarlo con
make install
normalmente puedes hacer
make uninstall
que elimina los archivos del sistema de archivos.