Net snmp python windows

Created by Jay Atkinson Copyright © 2008, Doxa Logos Technologies, Inc.

Welcome to PyNetSNMP. Another python interface for SNMP! The idea behind a new python interface to the NetSNMP library stems from a painstaking experience of trying to get the python, SNMP, and NetSNMP working on a Windows operating system. I finally got it working using Cygwin, rebuilding NetSNMP to include python bindings, and many frustrating hours of debugging simple “gets” and “sets”. I also had to fix a strange error in the python modules that come with NetSNMP version 5.4.1.

After all that hard work and frustration, I figured an easier way to interface with NetSNMP using Python and still use the Windows version without the use of Cygwin. If my design turns out the way I expect, then this solution should also work on other operating systems. The key to this design involves a new feature introduced in Python 2.4: the subprocess module. With subprocess module, all a user will need is to have NetSNMP correctly installed on their machine and this new python module, PyNetSNMP, to begin building simple scripts or larger applications with SNMP support.

Some may ask why not PySNMP or YapSNMP? Both were tried, and I could not get either one to work. PySNMP choked on some standard MIBs that I and my client have been using for years (turned out to be a flaw in python itself), and YapSNMP would not install correctly. NetSNMP is a well tested and mature SNMP application and is fairly straight forward to use compared to other solutions. Also, NetSNMP got around the python problem in PySNMP, because it had no problem parsing my MIBs.

netsnmp-py 0.5.2

pip install netsnmp-py Copy PIP instructions

Released: Sep 26, 2018

Python NET-SNMP Bindings

Navigation

Project links

Statistics

View statistics for this project via Libraries.io, or by using our public dataset on Google BigQuery

License: MIT License (MIT License)

Maintainers

Classifiers

• Development Status
  • 3 — Alpha
• Intended Audience
  • Developers
• License
  • OSI Approved :: MIT License
• Operating System
  • POSIX
• Programming Language
  • C
  • Python :: 2.7
  • Python :: 3
• Topic
  • Software Development :: Libraries

Project description

The author of this package has not provided a project description

Project details

Project links

Statistics

View statistics for this project via Libraries.io, or by using our public dataset on Google BigQuery

License: MIT License (MIT License)

Maintainers

Classifiers

• Development Status
  • 3 — Alpha
• Intended Audience
  • Developers
• License
  • OSI Approved :: MIT License
• Operating System
  • POSIX
• Programming Language
  • C
  • Python :: 2.7
  • Python :: 3
• Topic
  • Software Development :: Libraries

Release history Release notifications | RSS feed

Download files

Download the file for your platform. If you’re not sure which to choose, learn more about installing packages.

Net snmp python windows

Current release: 5.9

A composite image of images from locations that use the Net-SNMP package. Click here for more information.

Simple Network Management Protocol (SNMP) is a widely used protocol for monitoring the health and welfare of network equipment (eg. routers), computer equipment and even devices like UPSs. Net-SNMP is a suite of applications used to implement SNMP v1, SNMP v2c and SNMP v3 using both IPv4 and IPv6. The suite includes:

• Command-line applications to:
  • retrieve information from an SNMP-capable device, either using single requests (snmpget, snmpgetnext), or multiple requests (snmpwalk, snmptable, snmpdelta).
  • manipulate configuration information on an SNMP-capable device (snmpset).
  • retrieve a fixed collection of information from an SNMP-capable device (snmpdf, snmpnetstat, snmpstatus).
  • convert between numerical and textual forms of MIB OIDs, and display MIB content and structure (snmptranslate).
• A graphical MIB browser (tkmib), using Tk/perl.
• A daemon application for receiving SNMP notifications (snmptrapd). Selected notifications can be logged (to syslog, the NT Event Log, or a plain text file), forwarded to another SNMP management system, or passed to an external application.
• An extensible agent for responding to SNMP queries for management information (snmpd). This includes built-in support for a wide range of MIB information modules, and can be extended using dynamically loaded modules, external scripts and commands, and both the SNMP multiplexing (SMUX) and Agent Extensibility (AgentX) protocols.
• A library for developing new SNMP applications, with both C and perl APIs.

Net-SNMP is available for many Unix and Unix-like operating systems and also for Microsoft Windows. Note: Functionality can vary depending on the operating system. Please see the README files for information specific to your platform.

The documentation section contains detailed information on command line tools, installation, configuration etc.

If you are new to Net-SNMP or SNMP in general, then a good place to start is the tutorial section.

The download section contains the source code and binaries for various platforms.

Please see our project development pages located at Sourceforge as well.

Last modified: Tuesday, 26-Feb-2013 21:48:19 UTC
For questions regarding web content and site functionality, please write to the net-snmp-users mail list.

pyhedgehog

Links

Fri, Dec. 14th, 2012, 06:56 pm
Обзор библиотек Python для работы с SNMP

У всех найденных библиотек очень плохо с документацией.

netsnmp

Поставляется вместе с пакетом net-snmp (библиотекой и утилитами).

Проверенная версия: 1.0a1 (соответствует версии net-snmp 5.7.2) Текущую версию можно выяснить тут: http://www.net-snmp.org/about/ChangeLog.html Источник: http://www.net-snmp.org/ Подробнее: http://www.net-snmp.org/wiki/index.php/Python_Bindings Полезная статья: http://www.rootninja.com/how-to-write-simple-netsnmp-apps-in-python/

• Использует проверенную (и в большинстве случаев используемую в качестве “системной” библиотеку).
• Поддерживает SNMPv3.

Минусы: Довольно бедный интерфейс:

• Только синхронный интерфейс.
• Только простейшие функции — get, getnext, set, walk.
• Нет возможности ресолвить именованные OID’ы (хотя их можно использовать при запросах).
• Нет “серверного” интерфейса (ловить запросы или trap’ы).

pysnmp

• Есть и серверный и клиентский интерфейс.
• Поддерживаются все версии SNMP (1-3).
• Есть ресолвинг именованных OID’в.
• Есть и синхронный и асинхронный интерфейсы.
• Не имеет проблем с переносимостью, поскольку написано на “чистом” python’е.

• Совершенно невнятная организация модулей библиотеки.
• Странное ограничение на ресолвинг — модуль нужно передавать отдельно (то есть самому разбивать по “::”, что особенно неудобно в местах куда хочется просто передать OID)

libsnmp

• Достаточно прозрачный интерфейс.
• Асинхронный интерфейс.
• Вместо документации есть примеры скриптов (snmpget-v1, snmpget-v2, snmp-walk, traplistener, trapsender).
• Не имеет проблем с переносимостью, поскольку написано на “чистом” python’е.

• Сомнительная поддержка — сайт на который ссылается метаинформация не упоминает эту библиотеку вообще.
• Только асинхронный интерфейс.
• Нет поддержки SNMPv3.
• Нет поддержки ресолвинга OID’ов ни в виде отдельного интерфейса, ни при вызове других функций.

Другие

Есть ещё много библиотек на которые у меня не хватило дыхания. Возможно там и скрываются жемчужины проектирования и реализации, но исследование “неудачников” я отложу до следующего раза.

Зачем сетевику Python

«Сетевому администратору необходимо уметь программировать» — эта фраза часто вызывает возражения у многих сетевиков.

— Зачем? Руками оно надёжнее.
— Зато можно автоматизировать типовые операции.
— И положить кучу устройств, если что-то пойдёт не так?
— Положить кучу устройств можно и руками.

Вы прослушали краткое содержание типовых дискуссий по этому вопросу. Большинство админов останавливается на редактировании в текстом редакторе ранее скопированных кусков конфига и копировании их в консоль. Или подготовка типовых конфигурационных файлов, но добавление их на оборудование руками через консоль.

Если посмотреть в сторону производителей сетевого оборудования,
то окажется, что та же cisco уже давно предлагает разнообразные варианты для автоматизации работы с сетевым оборудованием: от TCL на IOS до Python на NX-OS и IOS-XR . Называется всё это network automation или network programmability, и у Cisco есть курсы по этому направлению.

И Cisco здесь не одинока: Juniper c PyEZ, HP, Huawei и тд.

Множество инструментов — Netconf, Restconf, Ansible, Puppet и Python, Python, Python. Анализ конкретных инструментов отложим на потом, перейдём к конкретному примеру.

Второй вопрос, который иногда вызывает бурные дискуссии, как правило приводящий к полному непониманию друг друга: «А нужны сетевику сетевые устройства в DNS?».
Оставим подробный анализ позиций участников на потом, сформулируя задачу, которая привела к Python и SNMP. А началось всё с traceroute.

Несмотря на наличие разнообразных систем мониторинга, которые бдят и видят многое, MPLS-TE, который разворачивает трафик причудливым образом, верный ICMP и утилиты traceroute и ping во многих случаях способны дать нужную информацию быстро и сейчас. Но вывод traceroute только ввиде IP адресов в большой сети потребует дополнительных усилий для понимания того, откуда именно пришли пакеты. Например, мы видим, что прямой и обратный трафик от пользователя идёт через разные маршрутизаторы, но по каким именно? Решение очевидно, занести адреса маршрутизаторов в DNS. А для корпоративных сетей, где редко используют unnumbered, ставя на соединители отдельные адреса, в случае занесения адресов интерфейсов в DNS, можно будет быстро понять, через какой интерфейс пакет ICMP вышел с маршрутизатора.

Однако вести вручную базу DNS на большой сети требует очень больших трудозатрат не самого сложного труда. А ведь доменное имя интерфейса будет состоят из названия интерфейса, description интерфейса, hostname маршрутизатора и названия домена. Всё это маршрутизатор несёт в своей конфигурации. Главное это собрать и правильно склеить и привязать к правильному адресу.

Значит эту задачу надо автоматизировать.

Первая мысль, анализ конфигураций, быстро угасла, сеть большая, многовендорная, да ещё и оборудование из разных поколений, поэтому идея парсить конфиги довольно быстро стала непопулярной.

Вторая мысль, использовать то, что даёт нужные ответы на универсальные запросы к оборудованию разных вендоров. Ответ был очевиден — SNMP. Он, при всех своих особенностях, реализован в ПО любого вендора.

Итак, начнём

pip3 install datetime

pip3 install ipaddress

Попробуем получить с маршрутизатора его hostname. SNMP использует для запросов к хосту OID. На OID хост вернёт информацию, соответствующую этому OID. Хотим получить hostname — нужно запрашивать 1.3.6.1.2.1.1.5.0.

И так первый скрипт, который запрашивает только hostname.

Запускаем и получаем:

Разберём скрипт поподробнее:

Сначала мы импортируем необходимые модули:

1. pysnmp — обеспечивает работу скрипта с хостом по SNMP

2. ipaddress — обеспечивает работу с адресами. Проверка адресов на корректность, проверка на вхождения адреса в адрес сети и тд.

3. datetime- получение текущего времени. В данной задаче нужен для организации логов.

Потом заводим четыре переменных:

1. community
2. адрес хоста
3. порт SNMP
4. значение OID

1. snmp_getcmd
2. snmp_get_next

Первая функция посылает запрос GET указанному хосту, по указанному порту, с указанным comminity и OID.
Вторая функция это генератор snmp_getcmd. Наверное разбивать на две функции было не совсем правильно, но уж так получилось:)

В этом скрипте не хватает некоторых вещей:

1. В скрипт необходимо загрузить ip адреса хостов. Например, из текстового файла. При загрузке необходимо проверить загружаемый адрес на корректность, иначе pysnmp может очень сильно удивиться и скрипт остановится с traceback. Непринципиально, откуда вы будете брать адреса из файла, из базы даных, но вы должны быть уверены, что адреса, которые вы получили — корректные. И так, источник адресов текстовый файл, одна строка — один адрес в десятичной форме.

2. Сетевое оборудование может быть выключено на момент опроса, может быть неправильно настроено, в итоге pysnmp выдаст в этом случае совершенно не то, что мы ждём и при дальнейшей обработке полученной информации получим остановку скрипта с traceback. Нужен обработчик ошибок для нашего взаимодействия по SNMP.

3. Нужен лог файл, в который будут записываться обработанные ошибки.

Загружаем адреса и создаём лог файл

Вводим переменную для имени файла.
Пишем функцию check_ip на проверку корректности адреса.
Пишем функцию get_from_file загрузки адресов, которая проверяет каждый адрес на корректность и если это не так, записывает об этом сообщение в лог.
Реализуем загрузку данных в список.

Создадим файл ip.txt

Error ip 12.43.dsds.f4
hostname= MikroTik
Traceback (most recent call last):
File «/snmp/snmp_read3.py», line 77, in print(‘hostname= ‘ + sysname)
TypeError: Can’t convert ‘NoneType’ object to str implicitly

Process finished with exit code 1

Из содержимого traceback невозможно понять, что причиной сбоя стал недоступный хост. Попробуем перехватить возможные причины остановки скрипта и записать всю информацию в лог.

Создаём обработчик ошибок для pysnmp

В функции snmp_get_next уже есть вывод ошибок errorIndication, errorStatus, errorIndex, varBinds. В varBinds выгружаются полученные данные, в переменные, начинающиеся с error, выгружается информация по ошибкам. Это только нужно правильно обработать. Так как в дальнейшем в скрипте будет ещё несколько функций по работе с snmp, имеет смысл обработку ошибок вынести в отдельную функцию.

И теперь добавляем в функцию snmp_get_next обработку ошибок и запись в лог файл. Функция теперь должна возвращать не только данные, но и сообщение о том, были ли ошибки.

Теперь необходимо немного переписать code section, с учётом того, что теперь есть сообщения об успешности запроса. Кроме этого, добавим несколько проверок:

1. Sysname меньше, чем три символа. Запишем в лог файл, чтобы потом присмотреться по пристальнее.

2. Обнаружим, что некоторые Huawei и Catos отдают на запрос только hostname. Так как отдельно выискивать для них OID совершенно не хочется (не факт, что он вообще есть, может это ошибка ПО), добавим таким хостам domain вручную.

3. Обнаружим, что хосты с неправильным comminity ведут себя по разному, большинство инициирует срабатывание обработчика ошибок, а некоторые почему-то отвечают, что скрипт воспринимает как нормальную ситуацию.

4. Добавим на время отладки разный уровень логирования, чтобы потом не выковыривать по всему скрипту лишние сообщения.

Проверим этот скрипт на том же файле ip.txt

Error Мусор в источнике ip адресов 12.43.dsds.f4
hostname= MikroTik.mydomain.ru
No SNMP response received before timeout ip address 172.1.1.1
hostname= MikroTik.mydomain.ru

Всё отработало штатно, мы поймали все ошибки, скрипт пропустил хосты с ошибками. Теперь этим скриптом можно собрать hostname cо всех устройств, отвечающих на snmp.

Полный текст скрипта прячу под спойлер.

Теперь осталось собрать имена интерфейсов, description интерфейсов, адреса интерфейсов и правильно разложить в конфигуционные файлы bind. Но об этом во второй части.

P.S.: Отмечу, что по-хорошему сообщения в лог файл следует формировать по-другому принципу.
Например: время спецсимвол код_ошибки спецсимвол описание_ошибки спецсимвол дополнительная_информация. Это поможет потом настроить автоматическую обработку лога.
UPD: исправление ошибок.

Читают сейчас

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Похожие публикации

Fortinet Security Fabric на практике. Часть 5. Администрирование и автоматизация

Консилиум с D-Link: базовая настройка управляемого сетевого оборудования

Зачем сетевику Python? Часть вторая

Курсы

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Минуточку внимания

Комментарии 45

Я чет так и не придумал, где может пригодится скрипт, который должен работать и там и там…
Обычно скрипты пишутся или для конкретной машины, либо для работы с сетевыми устройствами (А там другие вопроы возникают).

С другой стороны — Bash на Windows тоже есть (Порт, хотя в Win 10 — уже «нативно»… хотя это костыль, да. )

Для меня основной «Минус» питона — необходимость ставить интерпритатор. Особенно это актуально на всяких Embebed-девайсах, где банально может не быт места для установки оного.
А вот Bash/SH и CMD/PS есть «Изкаробки»…

Это запросто может быть. Например по корпоративной политике на рабочих машинах стоит Windows, а сервера, с которыми вы работаете на Windows и на Linux. Причем сервера вполне могут выполнять одни и те-же функции. И было бы хорошо, что бы скрипт работал и там и там. У меня на работе именно такой случай.

Про Win10 говорить рано. Еще только для тех, кто решился быть подопытной мышью. Да и не будем забывать, что полно оборудования где WinNT живее всех живых и Win2k3 цветет и пахнет.

На железках такого плана места действительно кот наплакал. Но там, зачастую, и скрипт не запустишь. Просто нет возможности. Но удаленно команды давать можно. Так что поставить Python нужно только в одном месте. Но я, если честно, совсем не жалуюсь. Если железка 1-2-10 вполне возможно туда что-то внедрить. Хотя то же сомнительно. А если их несколько тысяч? Лично я за то, что бы удаленно команды давать 😉

Ах если бы, ах если бы… Постоянно возникают проблемы когда скрипт, работающий на линухе, под виндой не пашет.

Ну как можно одинаково настроить окружение в линухе и винде? Там же разная структура путей, прав, и вообще всего.
С либами не всё гладко — нет pycurl для windows под python 3.6
Установка сертификатов для curl под Windows — отдельная морока.
В консоли могут быть ошибки если не

в начале. Вместо расцветки могут быть крякозябрики. И так далее.

Powershell для никсов:
https://github.com/PowerShell/PowerShell/blob/master/docs/installation/linux.md

Bash для винды:
https://msdn.microsoft.com/en-us/commandline/wsl/about

По-моему bash и perl в Линуксе разделили судьбу bat/vbs на Винде, где их полностью заменил PowerShell.

А написание скриптов подразумевает нечто большее, чем три строчки в .sh и нет смысла инвестировать в изучение ограниченной устаревшей технологии.

Теперь осталось собрать имена интерфейсов, description интерфейсов, адреса интерфейсов и правильно разложить в конфигуционные файлы bind.

Если ставить python3.4+ или python2.7.9, то pip ставить не нужно, начиная с python3.4 и python2.7.9 pip входит в комплект.

Если ставить python3, то и pip ставить нужно его же — python3-pip. datetime входит в стандартную поставку python

Справедливое замечание. Я понял, почему так — у меня по умолчанию главный в системе python3. Поэтому pip у меня ссылается на pip3.
Сейчас внесу исправления.

Python, обычно, уже установлен вместе с системой. Чтобы установить php, скорее всего, придется для начала настроить сеть.

Вы серьезно? Вы хотите писать сетевые скрипты без настроенной сети?

Python, обычно, уже установлен вместе с системой

На голом установленном Python’e Вы тоже далеко не уедете

Чтобы установить php, скорее всего, придется для начала настроить сеть.

Вы серьезно? Вы хотите писать сетевые скрипты без настроенной сети?

Ну, по крайней мере, я могу. И даже смогу их выполнить. В отличие от.

На голом установленном Python’e Вы тоже далеко не уедете

От задачи зависит.

Ну да, надо на Python’e написать скрипт для настройки сети, иначе это сделать никак не получится))

Предположу, что они уже написаны, остается только запустить. Эдакий постинсталл. Допустим, я выдумаю какую-то странную ситуацию про хитровыдуманную сеть с зубодробительными роутингами-шмоутингами и прочими айпитеблезами. Эти настройки вполне пишутся на «голом» питоне. Надуманная ситуация, разумеется. Да даже, если я от лени напишу что-то такое, делающее рутинную настройку интерфейсов. Типа ввел адрес-маску, оно само апнуло фейсы, и сделало что-то там ещё. Вот теперь можете ставить пхп и писать на нем. Кардинальная разница только в этом.

Подождите. Давайте смотреть. У вас есть огромная сеть. Есть сервер, с которой эта сеть управляется. На сервере, зачастую, стоит древняя версия например Linux. Python с библиотеками уже стоят. Потому, что это предлагает поставщик. Этот сервер стоит во внутренней сети и закрыт со всех сторон фаерволами. Выхода в интернет у этого сервера, понятное дело, нет. Что бы поставить PHP вы не ставите его сами. Вы идете в службу безопасности просите, что бы вам разрешили подключить сервер с интернету для обновления и затягивания нужных пакетов. Они смотрят на вас как на двинутого и говорят нет. Точнее они говорят «Ты что вообще дебил. ». А вы сами расшифровываете. Потом вы решаете идти другим путем. Вы обращаетесь к поставщику. А он в свою очередь говорит, что если он поставит вам PHP, то это будет стоить столько-то денег и вообще еще нужно вот такие фичи купить. Иначе они ни за что не отвечают. А если вы что-то поставите сами и это выяснится при аудите, то сервер за все вот эти кучи денег будет снят с супорта. И даже если вам подтвердят возможность установки самостоятельно вам придется все делать руками. Это вам не aptitude install и сиди жди. Это все качать руками, приносить не место, разворачивать. А потом вот этого не хватает, а это нужно другой версии, а это слишком новое, а это… И на сервере заменять библиотеки нельзя. Может сломаться основная часть. А вам она ведь то же нужна.

Я был в такой ситуации. Поверьте. Выучить Python- плевое дело.

Есть сервер, с которой эта сеть управляется. На сервере, зачастую, стоит древняя версия например Linux.

Python с библиотеками уже стоят.

Интересно как они там оказались? Сейчас смотрю:
-Ubuntu Server 16.04 LTS: есть python3, нет pip, нет pysnmp (из вашей статьи)
-Debian 7: нет python3, нет pip, нет pysnmp, нет ipaddress (из вашей статьи)
-CentOS Linux 7: python3, нет pip, нет pysnmp, нет ipaddress (из вашей статьи)
Других вспомогательных библиотек для работы с сетевыми устройствами, понятное дело, тоже нет.

Этот сервер стоит во внутренней сети и закрыт со всех сторон фаерволами. Выхода в интернет у этого сервера, понятное дело, нет. Что бы поставить PHP вы не ставите его сами. Вы идете в службу безопасности просите, что бы вам разрешили подключить сервер с интернету для обновления и затягивания нужных пакетов. Они смотрят на вас как на двинутого и говорят нет. Точнее они говорят «Ты что вообще дебил. ».

Однако у себя в статье эту ситуацию вы не рассматриваете и ставите нужные пакеты прямо из репозиториев. Оно и понятно, ведь цель статьи показать язык в конкретной задаче, а не о том, что он хорош тем, что предустановлен в системе.

Вы обращаетесь к поставщику. А он в свою очередь говорит, что если он поставит вам PHP, то это будет стоить столько-то денег и вообще еще нужно вот такие фичи купить. Иначе они ни за что не отвечают. А если вы что-то поставите.

Не следует свои частные случаи из жизни приводить как аргумент в общем споре. Спор шел о «PHP vs Python в программировании для сети». Главный аргумент ваш и Shtucer это «PHP надо установить, а Python уже установлен», а то, что библиотеки для Python тоже надо устанавливать, вы игнорируете. Ваша позиция мне ясна.

Или обижаться или выучить Python

Почему плохо? Часто это нормально. Все что нужно работает. Тем более, что упор делается на прикладной софт, а не на систему. А обновление может запросто все сломать. А это риски. А еще за уровень софта часто нужно заплатить. И заплатить немало.

Откуда они там оказались? Когда вы покупаете сервер для контроля всей сети это не железо с Linux на борту в стандартной комплектации. Это решение. Вам продают настроенную систему с целой кучей софта, который помогает вам делать все-все-все. К этому прилагается документация и поддержка на определенное время на определенных условиях. Т.е. вы звоните или пишите и вам в сжатые сроки предоставляют решения ваших проблем. И если в документации написано, что вот так вы можете использовать рекомендуемый нами Python, но так не работает, то поставщик обязан это все исправить. И не всегда это ему обходится бесплатно. Поэтому поверьте. Указанная версия стоит со всем библиотеками.

В скобках написано «из вашей статьи» и дальше вы говорите «у себя в статье». Это не моя статья. Я никак не связан ни с автором, ни с этой статьей. А вот ситуация, когда сервер стоит под семью замками и пользоваться предустановленным — самый здравый вариант мне очень хорошо знаком.

Возможно вас ввело в заблуждение название «сервер». Правильнее было бы его называть Operation Support System (OSS). Это комплекс, который используется для работы с сетью и представляет готовую систему для обслуживающего персонала. Т.е. он уже выполняет целый ряд стандартных функций таких как отслеживание аварий, статистика, билинг, конфигурирование, обновление программного обеспечения и многое-многое другое.

В смысле частные случаи? Это самый обычный случай в связи. Я не знаю о каких сетях говорите вы, а я говорю о сетях национального масштаба с тысячами роутеров. Я даже не могу себе представить идиотов, которые бы взялись это обслуживать вручную. И даже не смотря на то, что это стоит безумных денег это все покупается. Просто потому, что по-другому не получится. И еще раз повторяю. На OSS есть все, о чем заявили.

Я в самом начале написал, что можно писать на чем угодно. И готов это повторить. Вопрос не в языке. Вопрос в поддержке. Когда вы пишете на рекомендуемом языке вы используете библиотеку, которую вам предоставил производитель и работу которой он гарантирует. Вы не городите велосипеды. Вы говорите connect и библиотека сама продирается через уровни security и сама запихивает ваши команды на нужный узел или узлы. И если мы говорим о ssh, то вопросов почти нет. Во всяком случае они все решаемые. А если протокол закрыт? Допустим вы таки смогли разобраться. Но что-то пошло не так. И вы обращаетесь за консультацией к поставщику. А он мало того, что обиделся, что вы его протокол ковыряли (и еще хорошо, что санкций не последовало), так еще и очень вежливо говорит, что не собирается разбираться почему в вашем велосипедике когда вы крутите педали он мало того, что едет назад, так еще и поворачивает. И это будет очень здорово, что именно этим все закончится.

Сейчас многие производители рекомендуют Python. А с учетом того, что все сейчас ломанулись в облака, то без OpenStack точно не обойдется. А значит Python еще сильнее укрепит свои позиции как в сетях, так и в связи в целом.

Вы не найдете никаких особых отличий и в других языках. Как я уже и писал можно автоматизировать на любом из них. Даже на самых экзотических. Как-то мне попалась статья, где автоматизация делалась на Haskell.

Но дело не в самих языках. Дело в производителях. Они ведь не только говорят, что используйте Python потому, что нам так нравится. Когда у вас сеть из сотен, а то и тысяч устройств вы покупаете OSS сервер (как бы он не назывался в каждом конкретном случае), который уже обладает целым рядом инструментов, но если вам нужно что-то сделать дополнительно, то у вас есть выбор написать все нужные велосипеды, а потом то, что вам нужно на любом нравящемся языке, а можно воспользоваться уже готовыми библиотеками, которые помогают вам получать данные о сети и всех устройствах, ходить на них и там получать нужные параметры, работать с данными на самом сервере. Ведь обработку статистики или обработку аварий никто не отменял. Кроме скриптом в у вас еще куча другой работы. На велосипеды просто не остается времени. Поэтому да, Python, зачастую, хороший выбор уже просто потому, что его уже выбрали.

Может быть это несколько обидно, что обошли вниманием по всей видимости любимый вами PHP, но тут только два пути. Или обижаться или выучить Python. Лично я предпочитаю второй путь. Поэтому я писал на многих языках. В том числе и на всякой экзотике, которую предлагают производители. Они могут быть кривыми и неудобными, но они позволяют быстро сделать то, что мне нужно. И это в них главное.

Когда-то написал вот такой вот инструмент: https://github.com/kireevco/inventory-tamer сканирует сеть при помощи nmap, логинится через ssh по базе известных пар юзернейм-пароль, узнает ОС, если VMWare добывает еще информацию о том какие виртуалки работают складывает все в отчет нужного формата.

Пригодилось несколько раз когда приходишь в организацию с запущенным инвентарем

Сейчас для управления зоопарками использую Ansible, души в нем не чаю.
Кстати, inventory-tamer может генерировать inventory для того же Ansible 🙂

Если вы что-то автоматизировали и это отработало только один раз- это нормально и в этом нет ничего плохого. Но один раз получается очень не часто. Если мы говорим про большую сеть, то ее обслуживает и большое количество людей. И такие сети могут покрывать огромные расстояния. Вы можете даже никогда не увидеть людей, с которыми сотрудничаете годами. Представьте себе вышел из строя роутер за сотни километров от вас. Его заменил кто-то на месте и допустил ошибку при конфигурировании. И совсем не обязательно это вылезет сразу. И тут скриптик понадобится еще раз. И было бы хорошо иметь данные для сравнения и разницу получать на почту. В общем нет предела совершенству.

К тому-же если скрипт написан, то его содержание всегда можно изменить на нужное. Остальные части уже готовы. И скрипт уже будет запущен еще раз, а потом и еще раз 😉

Ребята а как же NOC? Он же специально заточен под сетевые девайсы. Да и питона там хватает.

Лично у меня есть небольшой опыт работы с c++, VBS, Delphi, powershell… т.е. я имею представление о синтаксисе этих языков, владею такими штуками как указатели, ссылки, классы, коллекции… и каждый раз когда возникала необходимось что то автоматизировать — в большинстве случаев это был notepad++ т.к. трудозатраты на код были слишком большими. Но самая большая проблема — это выход из зоны комфорта т.к. программироавание это не основрой навык. К питону относился со скепсисом потому что там нет скобочек, да и в целом питон — не звучит…

Но вот как то сел на него и… Код пишется буквально налету. Получается сразу! Практически любая идея заканчивается небольшим куском рабочего кода. Куча библиотек. Куча готового кода. Поддержка вендоров.

Хочу добавить, что сетевику так же необходимо освоить регулярные выражения. Это отдельный непростой слой. В отличае от питона — высокий порог вхождения, но надо. К тому же регулярные выражения нужны и в powershell и в bash.

Со всем согласен

сетевику так же необходимо освоить регулярные выражения