Consultas SNMP a Bind limitadas a 50 por rama?
Estimados, estoy tratando de obtener la mayor cantidad de datos posibles de Bind vía SNMP para luego así poder generar distintos gráficos de interés. Para hacer esto seguí los pasos indicados en la siguiente página: https://www.packetmischief.ca/monitoring-bind9/ Ya tengo los scripts funcionando y los datos se vuelcan correctamente en el archivo de estadísticas. También he realizado la configuración necesaria para poder servir dichos datos vía SNMP, para lo cual he agregado en el archivo /etc/snmp/snmpd.conf las siguientes líneas: exec bind9-query-001 /opt/snmp_bind/bind96-stats-get.sh incoming_requests:query exec bind9-query-002 /opt/snmp_bind/bind96-stats-get.sh incoming_requests:update exec bind9-query-003 /opt/snmp_bind/bind96-stats-get.sh incoming_queries:a ... ... exec bind9-query-106 /opt/snmp_bind/bind96-stats-get.sh socket_i/o_statistics:udp/ipv6_send_errors exec bind9-query-107 /opt/snmp_bind/bind96-stats-get.sh socket_i/o_statistics:udp/ipv4_recv_errors exec bind9-query-108 /opt/snmp_bind/bind96-stats-get.sh socket_i/o_statistics:tcp/ipv4_recv_errors Como ven son 108 parámetros en total los que se pueden obtener con los scripts en cuestión. La idea es obtener todo lo posible pero luego solo graficar lo que sea necesario. El problema es que cuando hago un snmpwalk solo obtengo los 50 primeros parámetros y no los 108 (a continuación resumo la salida del comando snmpwalk, en donde se ve que por cada parámetro hay distintas OID, pero en ningún caso se superan las 50 respuestas): snmpwalk -v2c -c blablabla localhost .1.3.6.1.4.1.2021.8.1 iso.3.6.1.4.1.2021.8.1.1.1 = INTEGER: 1 iso.3.6.1.4.1.2021.8.1.1.2 = INTEGER: 2 . iso.3.6.1.4.1.2021.8.1.1.49 = INTEGER: 49 iso.3.6.1.4.1.2021.8.1.1.50 = INTEGER: 50 iso.3.6.1.4.1.2021.8.1.2.1 = STRING: bind9-query-001 iso.3.6.1.4.1.2021.8.1.2.2 = STRING: bind9-query-002 . iso.3.6.1.4.1.2021.8.1.2.49 = STRING: bind9-query-049 iso.3.6.1.4.1.2021.8.1.2.50 = STRING: bind9-query-050 iso.3.6.1.4.1.2021.8.1.3.1 = STRING: /opt/snmp_bind/bind96-stats-get.sh iso.3.6.1.4.1.2021.8.1.3.2 = STRING: /opt/snmp_bind/bind96-stats-get.sh . iso.3.6.1.4.1.2021.8.1.3.49 = STRING: /opt/snmp_bind/bind96-stats-get.sh iso.3.6.1.4.1.2021.8.1.3.50 = STRING: /opt/snmp_bind/bind96-stats-get.sh iso.3.6.1.4.1.2021.8.1.100.1 = INTEGER: 0 iso.3.6.1.4.1.2021.8.1.100.2 = INTEGER: 0 . iso.3.6.1.4.1.2021.8.1.100.49 = INTEGER: 0 iso.3.6.1.4.1.2021.8.1.100.50 = INTEGER: 0 iso.3.6.1.4.1.2021.8.1.101.1 = STRING: 40755039 iso.3.6.1.4.1.2021.8.1.101.2 = STRING: 112 . iso.3.6.1.4.1.2021.8.1.101.49 = STRING: 7244253 iso.3.6.1.4.1.2021.8.1.101.50 = STRING: 196159 iso.3.6.1.4.1.2021.8.1.102.1 = INTEGER: 0 iso.3.6.1.4.1.2021.8.1.102.2 = INTEGER: 0 . iso.3.6.1.4.1.2021.8.1.102.49 = INTEGER: 0 iso.3.6.1.4.1.2021.8.1.102.50 = INTEGER: 0 iso.3.6.1.4.1.2021.8.1.103.1 = iso.3.6.1.4.1.2021.8.1.103.2 = . iso.3.6.1.4.1.2021.8.1.103.49 = iso.3.6.1.4.1.2021.8.1.103.50 = Ya consulté con el creados de los scripts y me dice que esto no debería pasar. Es por esto que me surge la duda, existe acaso alguna limitación en la configuración de SNMP que haga que no se pueda obtener más de 50 respuestas de una misma rama? Se que no es un error del parámetro número 51, puesto que si elimino el 50 y pongo el 51 en su lugar obtengo los datos del mismo, es decir, solo obtengo los 50 primeros parámetros especificados en el archivo /etc/snmp/snmpd.conf. Por cierto, en este caso el sistema es un Debian Squeeze LTS. Les agradecería mucho cualquier comentario al respecto. Saludos y muchas gracias, Mauro. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/552fd1d8.8030...@gmail.com
Re: Consultas SNMP a Bind limitadas a 50 por rama?
El Thu, 16 Apr 2015 12:14:32 -0300, Mauro Antivero escribió: Estimados, estoy tratando de obtener la mayor cantidad de datos posibles de Bind vía SNMP para luego así poder generar distintos gráficos de interés. Para hacer esto seguí los pasos indicados en la siguiente página: https://www.packetmischief.ca/monitoring-bind9/ (...) Como ven son 108 parámetros en total los que se pueden obtener con los scripts en cuestión. La idea es obtener todo lo posible pero luego solo graficar lo que sea necesario. El problema es que cuando hago un snmpwalk solo obtengo los 50 primeros parámetros y no los 108 (a continuación resumo la salida del comando snmpwalk, en donde se ve que por cada parámetro hay distintas OID, pero en ningún caso se superan las 50 respuestas): (...) snmpwalk -v2c -c blablabla localhost .1.3.6.1.4.1.2021.8.1 (...) Por cierto, en este caso el sistema es un Debian Squeeze LTS. Les agradecería mucho cualquier comentario al respecto. Parece que hay un snmpbulkwalk ¿has probado con ese comando? :-? Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.04.16.15.39...@gmail.com
Re: Consultas SNMP a Bind limitadas a 50 por rama?
El jueves, 16 abr 2015, a las 17:14 UTC+2 horas, Mauro Antivero escribió: Estimados, estoy tratando de obtener la mayor cantidad de datos posibles de Bind vía SNMP para luego así poder generar distintos gráficos de interés. Para hacer esto seguí los pasos indicados en la siguiente página: https://www.packetmischief.ca/monitoring-bind9/ Ya tengo los scripts funcionando y los datos se vuelcan correctamente en el archivo de estadísticas. También he realizado la configuración necesaria para poder servir dichos datos vía SNMP, para lo cual he agregado en el archivo /etc/snmp/snmpd.conf las siguientes líneas: exec bind9-query-001 /opt/snmp_bind/bind96-stats-get.sh incoming_requests:query exec bind9-query-002 /opt/snmp_bind/bind96-stats-get.sh incoming_requests:update exec bind9-query-003 /opt/snmp_bind/bind96-stats-get.sh incoming_queries:a ... ... exec bind9-query-106 /opt/snmp_bind/bind96-stats-get.sh socket_i/o_statistics:udp/ipv6_send_errors exec bind9-query-107 /opt/snmp_bind/bind96-stats-get.sh socket_i/o_statistics:udp/ipv4_recv_errors exec bind9-query-108 /opt/snmp_bind/bind96-stats-get.sh socket_i/o_statistics:tcp/ipv4_recv_errors Como ven son 108 parámetros en total los que se pueden obtener con los scripts en cuestión. La idea es obtener todo lo posible pero luego solo graficar lo que sea necesario. El problema es que cuando hago un snmpwalk solo obtengo los 50 primeros parámetros y no los 108 (a continuación resumo la salida del comando snmpwalk, en donde se ve que por cada parámetro hay distintas OID, pero en ningún caso se superan las 50 respuestas): snmpwalk -v2c -c blablabla localhost .1.3.6.1.4.1.2021.8.1 iso.3.6.1.4.1.2021.8.1.1.1 = INTEGER: 1 iso.3.6.1.4.1.2021.8.1.1.2 = INTEGER: 2 . iso.3.6.1.4.1.2021.8.1.1.49 = INTEGER: 49 iso.3.6.1.4.1.2021.8.1.1.50 = INTEGER: 50 iso.3.6.1.4.1.2021.8.1.2.1 = STRING: bind9-query-001 iso.3.6.1.4.1.2021.8.1.2.2 = STRING: bind9-query-002 . iso.3.6.1.4.1.2021.8.1.2.49 = STRING: bind9-query-049 iso.3.6.1.4.1.2021.8.1.2.50 = STRING: bind9-query-050 iso.3.6.1.4.1.2021.8.1.3.1 = STRING: /opt/snmp_bind/bind96-stats-get.sh iso.3.6.1.4.1.2021.8.1.3.2 = STRING: /opt/snmp_bind/bind96-stats-get.sh . iso.3.6.1.4.1.2021.8.1.3.49 = STRING: /opt/snmp_bind/bind96-stats-get.sh iso.3.6.1.4.1.2021.8.1.3.50 = STRING: /opt/snmp_bind/bind96-stats-get.sh iso.3.6.1.4.1.2021.8.1.100.1 = INTEGER: 0 iso.3.6.1.4.1.2021.8.1.100.2 = INTEGER: 0 . iso.3.6.1.4.1.2021.8.1.100.49 = INTEGER: 0 iso.3.6.1.4.1.2021.8.1.100.50 = INTEGER: 0 iso.3.6.1.4.1.2021.8.1.101.1 = STRING: 40755039 iso.3.6.1.4.1.2021.8.1.101.2 = STRING: 112 . iso.3.6.1.4.1.2021.8.1.101.49 = STRING: 7244253 iso.3.6.1.4.1.2021.8.1.101.50 = STRING: 196159 iso.3.6.1.4.1.2021.8.1.102.1 = INTEGER: 0 iso.3.6.1.4.1.2021.8.1.102.2 = INTEGER: 0 . iso.3.6.1.4.1.2021.8.1.102.49 = INTEGER: 0 iso.3.6.1.4.1.2021.8.1.102.50 = INTEGER: 0 iso.3.6.1.4.1.2021.8.1.103.1 = iso.3.6.1.4.1.2021.8.1.103.2 = . iso.3.6.1.4.1.2021.8.1.103.49 = iso.3.6.1.4.1.2021.8.1.103.50 = Ya consulté con el creados de los scripts y me dice que esto no debería pasar. Es por esto que me surge la duda, existe acaso alguna limitación en la configuración de SNMP que haga que no se pueda obtener más de 50 respuestas de una misma rama? Se que no es un error del parámetro número 51, puesto que si elimino el 50 y pongo el 51 en su lugar obtengo los datos del mismo, es decir, solo obtengo los 50 primeros parámetros especificados en el archivo /etc/snmp/snmpd.conf. Por cierto, en este caso el sistema es un Debian Squeeze LTS. Les agradecería mucho cualquier comentario al respecto. Saludos y muchas gracias, Mauro. Hay variables de configuración que limitan la respuesta dada, pero no recuerdo qué valores toman por omisión. ¿Has mirado el fichero de configuración de snmp del servidor bind si limita la cantidad de respuesta? Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150416173448.6e016...@gmail.com
Re: [OT] grub: error: cant't find command linux
El 13 de abril de 2015, 7:29 a. m., Camaleónnoela...@gmail.com escribió: El Sun, 12 Apr 2015 20:36:35 +0200, José Miguel (sio2) escribió: El Sun, 12 de Apr de 2015, a las 03:52:45PM +, Camaleón dijo: En cualquier caso, ¿dónde instalas GRUB, en el MBR o en la partición / boot/grub? En /boot/grub se instalan los módulos, la configuración menu.cfg y demás ficheros de grub. El sector de arranque de esa partición no tiene nada de especial. (...) Ya sabes que el gestor de arranque (me refiero al stage 1) puede ir instalado en dos lugares: el MBR y primer sector de la partición, la diferencia no es baladí sobre todo cuando se tienen instalados varios sistemas operativos y más aún si uno de ellos es Windows que no permite (al menos fácilmente) seleccionar dónde instalar su cargador de arranque y lo mete, sí o sí, en el MBR y adiós muy buenas a lo que hubiera anteriormente. Lo que no sé muy bien es qué ocurre cuando se elige instalar el grub en una partición DOS particular. Supongo que el código del MBR remitirá al sector de arranque de esa partición y éste al espacio entre el MBR y la primera partición. En otras distribuciones (yo lo pude comprobar con openSUSE que sí tenía esta opción) cuando se elige esa opción se instala código genérico en el MBR (lo mínimo para decirle a la BIOS dónde mirar) y el cargador de arranque (stage 1) se va al primer sector de la partición. Debian no sé cómo lo hará. A mí no me gusta tener un único GRUB porque te arriesgas a que no sea compatible con otros sistemas linux/unix (recordemos que hay distribuciones que lo modifican) Esto no lo sé. ¿Hay distribuciones que no arrancan con un grub genérico? Si, como decía antes openSUSE lo permite (o así lo hacía antes). o sencillamente te arriesgas a que por el motivo que sea te falle y no tengas otro para arrancar los sistemas operativos que tengas. Pero en este caso da igual que tengas unos o muchos: si te falla con el que deberías arrancar también vas a tener que montar el taco. Con cambiar la partición booteable a la que tenga cualquier otro GRUB ya lo tienes solucionado. En cuanto a tenerlo en su propia partición antes era la opción predeterminada y lo recomendado debido a que en algunos sistemas de archivos (p. ej., ReiserFS) tenía problemas pero ahora me parece que no y los instaladores lo ponen bajo partición raíz (/). El problema de eso es que, inopinadamente, puedes decidir cargarte uno de los sistemas operativos y que resulte que ese sea el que contenía el grub activo. Si tienes grub por separado, es más difícil que te lo cargues o por ignorancia o por descuido. En se caso ese sería el menor de los problemas porque si te cargas la partición donde tienes GRUB (que suele ser en la raíz bajo /boot/grub) te quedas sin sistema :-) ¡La de usuarios de windows que instalan linux para probar, luego lo borran y dejan de poder arrancar el sistema porque grub necesita los ficheros de /boot/grub y se los acaba de cargar al destruir la partición del linux! Si tienes instalado Windows ya se encarga él solito de sacarse las castañas del fuego e instalar su propio cargador en el MBR, así haya linux o no podrá arrancar cuando y como quiera. Saludos, Les cuento, logre que el grub me reconociera debian y manjaro, les comento como hice: En el grub presione c para entrar a la linea de comandos del grub, entonces hice lo siguiente: grubls (hd0), (hd0,1) en mi caso debian esta en (hd0,2) entonces: grubset root=(hd0,2) grublinux /boot/vmlinuz grubinitrd /boot/initrd... grunboot con esto pude acceder a debian, ya en debian reinstale el grub siguiendo este manual: https://wiki.debian.org/GrubEFIReinstall Con esto logre iniciar correctamente debian y manjaro, pero ahora ya no puedo entrar a centos :/ y me sale el mismo error de antes: grub: error: cant't find command linux pero ahora solo pasa con centos. Alguna idea de que puedo hacer para lograr iniciar centos desde el grub de debian? De antemano muchas gracias! -- El desarrollo no es material es un estado de conciencia mental -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CADpTsTafi0sPTKJoF+MiRwo=y-b8cwptu2ozebfkzopx_ke...@mail.gmail.com
