Sé que esta pregunta se ha hecho antes, pero no acepto la respuesta, "puede ver claramente adiciones personalizadas". Cuando agrego ppa's (que no he hecho en años), presiono una tecla en mi teclado con la etiqueta "Enter" que me permite agregar una línea vacía antes de la nueva entrada (incluso agregaría un comentario explicativo, pero soy un escritor de tecnología, entonces ...). Me gusta mi sources.conf
limpio y ordenado.
/etc/apt/sources.d
Significa que tengo media docena de archivos para analizar en lugar de solo uno.
AFAIK, no hay "absolutamente" ninguna ventaja en tener un archivo de configuración frente a 6 (en aras de la discusión, tal vez tenga 3 o incluso 2, no importa ... 1 todavía supera a 2).
¿Alguien puede aportar una ventaja racional? "Puede ver claramente adiciones personalizadas" es la excusa de un hombre pobre.
Sin embargo, debo agregar que me encanta el cambio SOLO cuando el cambio introduce beneficios.
Editar después de la primera respuesta:
Permite que las nuevas instalaciones que necesitan sus propios repositorios no tengan que buscar un archivo plano para asegurarse de que no está agregando entradas duplicadas.
Ahora, tienen que buscar un directorio de duplicados en lugar de un archivo plano. A menos que asuman que los administradores no cambian las cosas ...
Permite al administrador del sistema deshabilitar fácilmente (renombrando) o eliminar (borrando) un conjunto de repositorios sin tener que editar un archivo monolítico.
El administrador tiene que buscar el directorio grep para encontrar el archivo apropiado para cambiarle el nombre, antes, buscaría UN archivo y comentaría una línea, una línea de sed para "casi" cualquier administrador.
Permite que un mantenedor de paquetes dé un comando simple para actualizar las ubicaciones del repositorio sin tener que preocuparse por cambiar inadvertidamente la configuración de repositorios no relacionados.
No entiendo este, supongo que el mantenedor del paquete conoce la URL de su repositorio. De nuevo, tiene sed
un directorio en lugar de un solo archivo.
Respuestas:
A nivel técnico, como alguien que ha tenido que manejar estos cambios en algunas herramientas de información del sistema grandes y populares, básicamente se reduce a esto:
Para sources.list.d /
Tenga en cuenta que a menos que también estén haciendo la misma verificación que a continuación, si hubiera comentado una línea de repositorio, estas pruebas serían incorrectas. Si están haciendo la misma verificación que a continuación, es la misma complejidad exacta, excepto que se realiza en muchos archivos, no en uno. Además, a menos que estén revisando TODOS los archivos posibles, pueden, y a menudo lo hacen, agregar un elemento duplicado, lo que hace que se quejen, hasta que elimine uno de ellos.
Para fuentes.list
Los desarrolladores de Google Chrome no verificaron la presencia de fuentes de Google Chrome, confiando en el nombre de archivo exacto que su paquete de Chrome crearía para estar presente. En todos los demás casos, crearían un nuevo archivo en sources.list.d llamado exactamente de la manera que querían.
Para ver qué fuentes tiene, por supuesto, no es tan bonito, ya que no puede ser más fácil de leer y mantener que:
Así que esto se hizo básicamente con el propósito de actualizaciones automáticas, y para proporcionar comandos simples y sencillos que podría dar a los usuarios, por lo que puedo decir. Para los usuarios, significa que tienen que leer muchos archivos en lugar de 1 archivo para ver si tienen un repositorio agregado, y para apt, significa que también tienen que leer muchos archivos en lugar de uno.
Dado que en el mundo real, si iba a hacer esto bien, debe respaldar las comprobaciones de todos los archivos, independientemente de su nombre, y luego probar si la acción a realizar es obligatoria o no.
Sin embargo, si no lo hiciera bien, simplemente ignoraría las verificaciones para ver si el elemento está en algún lugar de las fuentes, y simplemente verificará el nombre del archivo. Creo que eso es lo que hace la mayoría de las cosas automatizadas, pero dado que al final, simplemente tuve que verificar todo para poder enumerarlo y actuar en función de si uno de esos archivos coincidía, el único resultado real fue hacerlo mucho más complicado.
Ediciones masivas
Dado que ejecuta muchos servidores, me vería tentado a simplemente escribir un trabajo nocturno que recorre /etc/apt/sources.list.d/ y comprueba primero para asegurarse de que el elemento ya no esté en sources.list, luego si está no, agregue ese elemento a sources.list, elimine el archivo sources.list.d y, si ya está en sources.list, simplemente elimine el archivo sources.list.d
Dado que NO hay nada negativo en usar solo sources.list más allá de la simplicidad y la facilidad de mantenimiento, agregar algo así podría no ser una mala idea, en particular dadas las acciones aleatorias creativas de los administradores del sistema.
Como se señaló en el comentario anterior, inxi -r imprimirá perfectamente por archivo los repositorios activos, pero por supuesto no los editará o alterará, por lo que eso sería solo la mitad de la solución. Si se trata de muchas distribuciones, es un dolor aprender cómo cada uno lo hace, eso es seguro, y la aleatoriedad ciertamente es la regla más que la excepción, lamentablemente.
fuente
Tener cada repositorio (o colección de repositorios) en su propio archivo hace que sea más fácil de administrar, tanto a mano como mediante programación:
fuente
.d
diseño separa claramente el estado de configuración propiedad de diferentes entidades. Uno podría ser propiedad de un paquete. Otro podría instalarse a través dewget ...
. Con un solo archivo monstruo, ¿cómo "sabe" algún procedimiento automatizado o semiautomatizado qué parte de la configuración posee? No lo hace, por eso el.d
diseño es superior..d
diseño se enfocaron inmediatamente una vez que comencé a hacer una gestión de configuración de Puppet / Salt.service.d/*
archivos) Implementar archivos en lugar de modificar los existentes Los también son mejores para el almacenamiento en caché / comparación de imágenes.Si está administrando manualmente sus servidores, estoy de acuerdo en que hace las cosas más confusas. Sin embargo, beneficia la gestión programática (es decir, "configuración como código"). Cuando se utiliza un software de gestión de configuración como Puppet, Ansible, Chef, etc., es más fácil simplemente soltar o eliminar un archivo en un directorio y ejecutarlo
apt update
, en lugar de analizar un archivo para agregar o eliminar ciertas líneas.Especialmente porque eso evita tener que administrar el contenido de un solo recurso 'archivo', por ejemplo
/etc/apt/sources.list
, desde múltiples módulos independientes que han sido escritos por terceros.Aprecio el uso generalizado de Ubuntu de los directorios ".d" por este motivo en particular, es decir, sudoers.d, rsyslog.d, sysctl.d., Cron.d, logrotate.d, etc.
fuente
Como señaló Nemo en un comentario, una de las principales ventajas de un directorio es que permite la noción de "propiedad".
Las distribuciones e instaladores modernos de Linux se basan en la idea de paquetes : piezas de software independientes que, en la medida de lo posible, se pueden agregar y eliminar atómicamente. Cada vez que instala un paquete con
dpkg
(y por lo tantoapt
), realiza un seguimiento de qué archivos en el sistema fueron creados por ese instalador. Desinstalar el paquete puede consistir en gran medida en eliminar esos archivos.La respuesta actualmente aceptada lo toma como algo malo que un instalador de Google Chrome supuso que solo debería crear o eliminar una entrada en la ubicación que esperaba, pero automatizar cualquier otra cosa conduce a todo tipo de casos extremos horribles; por ejemplo:
sources.list
durante la instalación, pero está comentada, ¿debería el instalador descomentarla o agregar un duplicado?No se requieren archivos separados para la propiedad; por ejemplo, el instalador podría incluir un bloque de comentarios que indiquen que "posee" un conjunto particular de líneas. En ese caso, siempre buscaría en el archivo ese bloque exacto, no alguna otra mención del mismo repositorio.
En igualdad de condiciones, automatizar las ediciones en un solo archivo de configuración siempre será más complicado que automatizar la creación y eliminación de un archivo separado. Como mínimo, eliminar líneas requiere el uso de alguna herramienta de coincidencia de patrones como
sed
. En un archivo más complejo, agregar y eliminar líneas puede requerir una herramienta de secuencias de comandos con conocimiento del formato de archivo, para agregar a una sección adecuada o eliminar sin dañar el formato circundante.Dado que un instalador necesitaría evitar meterse con la configuración editada manualmente de todos modos, tiene sentido colocar la configuración automatizada, propiedad de la herramienta, en un formato que sea fácil de administrar para las herramientas automatizadas.
fuente
Esto permite que los paquetes agreguen fuentes adicionales sin recurrir a scripts.
Por ejemplo, cuando instala el paquete Skype de Microsoft, una fuente para skype.com se configura automáticamente para descargar actualizaciones; eliminar el paquete de Skype del sistema también deshabilita esta fuente de paquete nuevamente.
Si desea tener el mismo efecto con un archivo plano, entonces los scripts de instalación para Skype necesitarían modificar su sources.list, lo que probablemente muchos administradores del sistema encontrarían un poco desconcertante.
fuente
No estoy convencido de que haya una buena razón, aparte de que parece estar de moda. Para mí, rompe la regla de que un directorio debe ser una hoja o un nodo, es decir, que debe contener solo archivos o directorios, no una mezcla de ambos.
Supongo que hace que los archivos sean más pequeños, más fáciles de leer; en el caso, por ejemplo, de las reglas de sudo, que pueden ser bastante largas, hace que sea más fácil tener un conjunto estandarizado de reglas para un tipo de usuario (por ejemplo, un desarrollador ) y agréguelos al directorio de configuración si se debe permitir a los desarrolladores sudo en esta máquina; por lo tanto, necesita mantener menos archivos, solo un archivo para desarrolladores, administradores, sysops, etc., en lugar de cada combinación posible de los mismos.
Ahí me he contradicho.
fuente
/var/log
. Un simple demonio podría escribir un archivo único directamente en el interior:/var/log/simple.log
. Un demonio más complejo podría tener su propio subdirectorio:/var/log/complex/a.log
,/var/log/complex/b.log
,/var/log/complex/c.log
... patrón similar con configuraciones.