sysctl es una utilidad de software de algunos sistemas operativos tipo Unix que lee y modifica los atributos del kernel del sistema , como su número de versión, límites máximos y configuraciones de seguridad. [1] Está disponible como llamada al sistema para programas compilados y como comando de administrador para uso interactivo y secuencias de comandos. Linux además expone sysctl como un sistema de archivos virtual .
En BSD, estos parámetros son generalmente objetos en una base de información de administración (MIB) que describen límites ajustables, como el tamaño de un segmento de memoria compartida, la cantidad de subprocesos que el sistema operativo usará como cliente NFS o la cantidad máxima de procesos. en el sistema; o describir, habilitar o deshabilitar comportamientos como el reenvío de IP , restricciones de seguridad en el superusuario (el "nivel seguro") o resultados de depuración. [1]
En OpenBSD y DragonFly BSD , sysctl también se usa como capa de transporte para el marco hw.sensors para monitoreo de hardware , [2] mientras que NetBSD usa la llamada al sistema ioctl para su contraparte sysmon envsys . Tanto sysctl como ioctl son dos llamadas al sistema que se pueden utilizar para agregar funcionalidad adicional al kernel sin agregar otra llamada al sistema ; [3] por ejemplo, en 2004 con OpenBSD 3.6, cuando se introdujo la utilidad tcpdrop, se usó sysctl como llamada al sistema subyacente. [3] [4] En FreeBSD , aunque no existe un marco de sensores, la temperatura individual y otros sensores todavía se exportan comúnmente a través del árbol sysctl a través de Newbus, por ejemplo, como es el caso del aibs(4)controlador que está disponible en los 4 BSD. sistemas, incluido FreeBSD. [5] [6] [7]
En BSD, generalmente se proporciona una llamada al sistema o un contenedor de llamadas al sistema para que los utilicen los programas, así como un programa administrativo y un archivo de configuración (para configurar los parámetros ajustables cuando se inicia el sistema ).
Esta característica apareció por primera vez en 4.4BSD . Tiene la ventaja sobre las constantes codificadas de que los cambios en los parámetros se pueden realizar dinámicamente sin tener que volver a compilar el kernel.
Históricamente, aunque las propias variables del kernel podían modificarse a través de sysctl, los elementos que componen la MIB del árbol sysctl estaban codificados en el momento de la compilación y, a partir de 2019, sigue siendo así en OpenBSD (con algunas excepciones como hw.sensors , que administra y proporciona su propio subárbol dinámico). FreeBSD ha tenido "magia interna sysctl" para la gestión dinámica del árbol sysctl desde 1995; NetBSD ha tenido su propia implementación de un árbol sysctl dinámico desde diciembre de 2003. [5] [6]
En Linux, el mecanismo de la interfaz sysctl también se exporta como parte de procfs en el directorio /proc/sys (no debe confundirse con el directorio /sys ). Esta diferencia significa que verificar el valor de algún parámetro requiere abrir un archivo en un sistema de archivos virtual , leer su contenido, analizarlo y cerrar el archivo. La llamada al sistema sysctl existe en Linux, pero ha quedado obsoleta y no tiene una función contenedora en glibc ; normalmente no está disponible debido a que muchas distribuciones configuran el kernel sin CONFIG_SYSCTL_SYSCALL; por lo que no se recomienda su uso. [8]
Cuando el reenvío de IP está habilitado, el kernel del sistema operativo actuará como enrutador . En FreeBSD , NetBSD , OpenBSD , DragonFly BSD y Darwin / Mac OS X , el parámetro net.inet.ip.forwarding se puede establecer en 1 para habilitar este comportamiento. En Linux, el parámetro se llama net.ipv4.ip_forward .
En la mayoría de los sistemas, el comando sysctl -w parámetro =1 habilitará un determinado comportamiento. Esto persistirá hasta el próximo reinicio. Si el comportamiento debe habilitarse cada vez que se inicia el sistema, el parámetro de línea =1 se puede agregar/reescribir en el archivo /etc/sysctl.conf . Además, algunas variables sysctl no se pueden modificar después de iniciar el sistema. Estas variables (dependiendo de la variable, la versión y el tipo de BSD) deben configurarse estáticamente en el kernel en el momento de la compilación o en /boot/loader.conf .
{{cite conference}}: CS1 maint: bot: original URL status unknown (link)