Комментарии 45
Python сисадмину?
У Windows есть PowerShell (Или bat/cmd если чтото совсем простое).
У *nix'ов — Bash.
Обычно их возможностей обычному сисадмину более чем достаточно. А если нет — тут уже встает вопрос о написании (Покупке?) собственной софтины. А тут выбор языка зависит больше от предпочтений прогера. (Ну или от задач, которые должна решать софтина)
У Windows есть PowerShell (Или bat/cmd если чтото совсем простое).
У *nix'ов — Bash.
Обычно их возможностей обычному сисадмину более чем достаточно. А если нет — тут уже встает вопрос о написании (Покупке?) собственной софтины. А тут выбор языка зависит больше от предпочтений прогера. (Ну или от задач, которые должна решать софтина)
Ок, а если Вам будет надо например ходить скриптом и на вин и на никс?
Пайтон он везде пайтон, а бат на никсах особо не запустишь.
Ну ок, Вы решили заюзать Ansible, хоп, нужен свой модуль. Опять пайтон.
Надо быстренько парсинг какой нибудь логов или конфигов с подменой сделать и его запустить и в никсах и вин?
Покупать софтину для парсинга конфигов? У меня вот старый проект, приходится работать на никсах и вин одновременно, не могу отказать от какой то оси.
Пайтон он везде пайтон, а бат на никсах особо не запустишь.
Ну ок, Вы решили заюзать Ansible, хоп, нужен свой модуль. Опять пайтон.
Надо быстренько парсинг какой нибудь логов или конфигов с подменой сделать и его запустить и в никсах и вин?
Покупать софтину для парсинга конфигов? У меня вот старый проект, приходится работать на никсах и вин одновременно, не могу отказать от какой то оси.
Я чет так и не придумал, где может пригодится скрипт, который должен работать и там и там…
Обычно скрипты пишутся или для конкретной машины, либо для работы с сетевыми устройствами (А там другие вопроы возникают).
С другой стороны — Bash на Windows тоже есть (Порт, хотя в Win 10 — уже «нативно»… хотя это костыль, да...)
Для меня основной «Минус» питона — необходимость ставить интерпритатор. Особенно это актуально на всяких Embebed-девайсах, где банально может не быт места для установки оного.
А вот Bash/SH и CMD/PS есть «Изкаробки»…
Обычно скрипты пишутся или для конкретной машины, либо для работы с сетевыми устройствами (А там другие вопроы возникают).
С другой стороны — Bash на Windows тоже есть (Порт, хотя в Win 10 — уже «нативно»… хотя это костыль, да...)
Для меня основной «Минус» питона — необходимость ставить интерпритатор. Особенно это актуально на всяких Embebed-девайсах, где банально может не быт места для установки оного.
А вот Bash/SH и CMD/PS есть «Изкаробки»…
Вот пример: Пришла железка, и ее надо настроить так же, как и в другом филиале. Но в новом филиале все на виндах, а в другом было на *nix. С помощью питоновского скрипта можно настроить железку абсолютно так же, но из-под другой операционки.
Спорный вариант — Толковый сисадмин хранит подобные скрипты на рабочем ноуте (Чтобы были всегда под рукой). А в случае «Форс мажора» все вручную настраивается.
Ну я сейчас приведу такой ОЧЕНЬ частный случай( но на самом деле это рабочий момент).
Есть например мифическая разработка, внутренняя, она шлет какой то траф.
Я хочу проверить работу, урезая скорость и помониторить и послать себе писем.
Есть версия 1.0, она на вин сервере работает, есть версия 3.0 она на никс сервере работает.
Пишу какой то скрипт, он делает что надо, метрики мне шлет в течении например трех четырех дней.
Какие то если есть различия в вин и никс, можно через sys args, а в остальном логика одинакова работы на разных платформах.
Профит: мои 100 строк скрипта работают и там и там, не надо писать два разных, тестировать могу под никс (мне так удобнее).
Есть например мифическая разработка, внутренняя, она шлет какой то траф.
Я хочу проверить работу, урезая скорость и помониторить и послать себе писем.
Есть версия 1.0, она на вин сервере работает, есть версия 3.0 она на никс сервере работает.
Пишу какой то скрипт, он делает что надо, метрики мне шлет в течении например трех четырех дней.
Какие то если есть различия в вин и никс, можно через sys args, а в остальном логика одинакова работы на разных платформах.
Профит: мои 100 строк скрипта работают и там и там, не надо писать два разных, тестировать могу под никс (мне так удобнее).
Это запросто может быть. Например по корпоративной политике на рабочих машинах стоит Windows, а сервера, с которыми вы работаете на Windows и на Linux. Причем сервера вполне могут выполнять одни и те-же функции. И было бы хорошо, что бы скрипт работал и там и там. У меня на работе именно такой случай.
Про Win10 говорить рано. Еще только для тех, кто решился быть подопытной мышью. Да и не будем забывать, что полно оборудования где WinNT живее всех живых и Win2k3 цветет и пахнет.
На железках такого плана места действительно кот наплакал. Но там, зачастую, и скрипт не запустишь. Просто нет возможности. Но удаленно команды давать можно. Так что поставить Python нужно только в одном месте. Но я, если честно, совсем не жалуюсь. Если железка 1-2-10 вполне возможно туда что-то внедрить. Хотя то же сомнительно. А если их несколько тысяч? Лично я за то, что бы удаленно команды давать ;)
Про Win10 говорить рано. Еще только для тех, кто решился быть подопытной мышью. Да и не будем забывать, что полно оборудования где WinNT живее всех живых и Win2k3 цветет и пахнет.
На железках такого плана места действительно кот наплакал. Но там, зачастую, и скрипт не запустишь. Просто нет возможности. Но удаленно команды давать можно. Так что поставить Python нужно только в одном месте. Но я, если честно, совсем не жалуюсь. Если железка 1-2-10 вполне возможно туда что-то внедрить. Хотя то же сомнительно. А если их несколько тысяч? Лично я за то, что бы удаленно команды давать ;)
Пайтон он везде пайтон
Ах если бы, ах если бы… Постоянно возникают проблемы когда скрипт, работающий на линухе, под виндой не пашет.
А окружение настроено одинаково? Версия пайтона, дополнительные либы, права, пути? И при таких условиях есть скрипты, рабочие в никсах, но не рабочие в винде?
Ну как можно одинаково настроить окружение в линухе и винде? Там же разная структура путей, прав, и вообще всего.
С либами не всё гладко — нет pycurl для windows под python 3.6
Установка сертификатов для curl под Windows — отдельная морока.
В консоли могут быть ошибки если не
в начале. Вместо расцветки могут быть крякозябрики. И так далее.
С либами не всё гладко — нет pycurl для windows под python 3.6
Установка сертификатов для curl под Windows — отдельная морока.
В консоли могут быть ошибки если не
chcp 65001
set PYTHONIOENCODING=utf-8
в начале. Вместо расцветки могут быть крякозябрики. И так далее.
Powershell для никсов:
https://github.com/PowerShell/PowerShell/blob/master/docs/installation/linux.md
Bash для винды:
https://msdn.microsoft.com/en-us/commandline/wsl/about
https://github.com/PowerShell/PowerShell/blob/master/docs/installation/linux.md
Bash для винды:
https://msdn.microsoft.com/en-us/commandline/wsl/about
Вы верно подметили, у Windows — PowerShell, у *nix — Bash. Поэтому, чтобы работало и там и там берут Python. :)
В вакансиях линуксовых сисадминов скорее встретишь Python, чем Bash. В сетевых железках везде Python и Ansible, который тоже Python и может требовать доработки.
В штате у любых сетевиков при накоплении определенной массы активных устройств всегда появляется тот, кто потихоньку начинает скриптовать. Пусть даже на банальной задаче добавить еще одно snmp-community или сменить пароль локального пользователя на 100 устройств делать в ручном режиме совсем не эффективно. Что уж говорить про более сложную логику в виде резервного upload-а конфигов, визуального интерфейса для примитивных действий для смены и т.д.
Если ставить python3, то и pip ставить нужно его же — python3-pip. datetime входит в стандартную поставку python.
Пока собрали только имена хостов и то не всех. Фраза напоминает картинку — как нарисовать сову?
Теперь осталось собрать имена интерфейсов, description интерфейсов, адреса интерфейсов и правильно разложить в конфигуционные файлы bind.
Пока собрали только имена хостов и то не всех. Фраза напоминает картинку — как нарисовать сову?
Если ставить python3.4+ или python2.7.9, то pip ставить не нужно, начиная с python3.4 и python2.7.9 pip входит в комплект.
Если ставить python3, то и pip ставить нужно его же — python3-pip. datetime входит в стандартную поставку python
Справедливое замечание. Я понял, почему так — у меня по умолчанию главный в системе python3. Поэтому pip у меня ссылается на pip3.
Сейчас внесу исправления.
Вдохновлялся несколько лет назад книжкой «Python в системном администрировании» или что то похожее.
Сам уже пару лет использую питон для этих целей в своей работе (хотя выбор языка — это больше идеология, надо брать то, что больше/лучше знаешь/хочешь знать).
Правда я больше всё же через ssh работаю с схд/коммутаторами. Что то призвано автоматизировать рутину, а что то и просто ускоряет процесс работы с оборудованием. Сейчас как раз дописываю для личного блога статью по fc зоннигду и следующей статьёй хотел рассказать про работы с brocade при помощи скриптов, для облегчения жизни :)
Сам уже пару лет использую питон для этих целей в своей работе (хотя выбор языка — это больше идеология, надо брать то, что больше/лучше знаешь/хочешь знать).
Правда я больше всё же через ssh работаю с схд/коммутаторами. Что то призвано автоматизировать рутину, а что то и просто ускоряет процесс работы с оборудованием. Сейчас как раз дописываю для личного блога статью по fc зоннигду и следующей статьёй хотел рассказать про работы с brocade при помощи скриптов, для облегчения жизни :)
Считаю, что для сетевых скриптов хорошо подходит PHP. Есть все необходимые функции: snmpget, snmpwalk, все необходимые функции для подключения по SSH, поддержка expect, правда, только для PHP5, вспомогательные сетевые функции типа (long2ip, gethostbynamel и т.п.).
Правда, в больших задачах, где требуется распараллеливание опроса хостов, встречаются проблемы. Но выбор между двумя языками, считаю, это дело вкуса.
Правда, в больших задачах, где требуется распараллеливание опроса хостов, встречаются проблемы. Но выбор между двумя языками, считаю, это дело вкуса.
Писать можно на чем угодно. И если вы уже знаете PHP, то почему-бы и нет? Но большинство производителей оборудования предлагают именно Python. И это о чем-то да и говорит.
В этом у меня и вопрос. Почему-то везде продвигается мысль, что Python хорош для сетевиков. Но чего-то кардинально отличающегося от того же PHP я не увидел.
Python, обычно, уже установлен вместе с системой. Чтобы установить php, скорее всего, придется для начала настроить сеть.
Вы серьезно? Вы хотите писать сетевые скрипты без настроенной сети?
Python, обычно, уже установлен вместе с системойНа голом установленном Python'e Вы тоже далеко не уедете
Чтобы установить php, скорее всего, придется для начала настроить сеть.Ну да, надо на Python'e написать скрипт для настройки сети, иначе это сделать никак не получится))
Вы серьезно? Вы хотите писать сетевые скрипты без настроенной сети?
Ну, по крайней мере, я могу. И даже смогу их выполнить. В отличие от.
На голом установленном Python'e Вы тоже далеко не уедете
От задачи зависит.
Ну да, надо на Python'e написать скрипт для настройки сети, иначе это сделать никак не получится))
Предположу, что они уже написаны, остается только запустить. Эдакий постинсталл. Допустим, я выдумаю какую-то странную ситуацию про хитровыдуманную сеть с зубодробительными роутингами-шмоутингами и прочими айпитеблезами. Эти настройки вполне пишутся на "голом" питоне. Надуманная ситуация, разумеется. Да даже, если я от лени напишу что-то такое, делающее рутинную настройку интерфейсов. Типа ввел адрес-маску, оно само апнуло фейсы, и сделало что-то там ещё. Вот теперь можете ставить пхп и писать на нем. Кардинальная разница только в этом.
Подождите. Давайте смотреть. У вас есть огромная сеть. Есть сервер, с которой эта сеть управляется. На сервере, зачастую, стоит древняя версия например Linux. Python с библиотеками уже стоят. Потому, что это предлагает поставщик. Этот сервер стоит во внутренней сети и закрыт со всех сторон фаерволами. Выхода в интернет у этого сервера, понятное дело, нет. Что бы поставить PHP вы не ставите его сами. Вы идете в службу безопасности просите, что бы вам разрешили подключить сервер с интернету для обновления и затягивания нужных пакетов. Они смотрят на вас как на двинутого и говорят нет. Точнее они говорят «Ты что вообще дебил?!!!». А вы сами расшифровываете. Потом вы решаете идти другим путем. Вы обращаетесь к поставщику. А он в свою очередь говорит, что если он поставит вам PHP, то это будет стоить столько-то денег и вообще еще нужно вот такие фичи купить. Иначе они ни за что не отвечают. А если вы что-то поставите сами и это выяснится при аудите, то сервер за все вот эти кучи денег будет снят с супорта. И даже если вам подтвердят возможность установки самостоятельно вам придется все делать руками. Это вам не aptitude install и сиди жди. Это все качать руками, приносить не место, разворачивать. А потом вот этого не хватает, а это нужно другой версии, а это слишком новое, а это… И на сервере заменять библиотеки нельзя. Может сломаться основная часть. А вам она ведь то же нужна.
Я был в такой ситуации. Поверьте. Выучить Python- плевое дело.
Я был в такой ситуации. Поверьте. Выучить 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 еще сильнее укрепит свои позиции как в сетях, так и в связи в целом.
Откуда они там оказались? Когда вы покупаете сервер для контроля всей сети это не железо с Linux на борту в стандартной комплектации. Это решение. Вам продают настроенную систему с целой кучей софта, который помогает вам делать все-все-все. К этому прилагается документация и поддержка на определенное время на определенных условиях. Т.е. вы звоните или пишите и вам в сжатые сроки предоставляют решения ваших проблем. И если в документации написано, что вот так вы можете использовать рекомендуемый нами Python, но так не работает, то поставщик обязан это все исправить. И не всегда это ему обходится бесплатно. Поэтому поверьте. Указанная версия стоит со всем библиотеками.
В скобках написано «из вашей статьи» и дальше вы говорите «у себя в статье». Это не моя статья. Я никак не связан ни с автором, ни с этой статьей. А вот ситуация, когда сервер стоит под семью замками и пользоваться предустановленным — самый здравый вариант мне очень хорошо знаком.
Возможно вас ввело в заблуждение название «сервер». Правильнее было бы его называть Operation Support System (OSS). Это комплекс, который используется для работы с сетью и представляет готовую систему для обслуживающего персонала. Т.е. он уже выполняет целый ряд стандартных функций таких как отслеживание аварий, статистика, билинг, конфигурирование, обновление программного обеспечения и многое-многое другое.
В смысле частные случаи? Это самый обычный случай в связи. Я не знаю о каких сетях говорите вы, а я говорю о сетях национального масштаба с тысячами роутеров. Я даже не могу себе представить идиотов, которые бы взялись это обслуживать вручную. И даже не смотря на то, что это стоит безумных денег это все покупается. Просто потому, что по-другому не получится. И еще раз повторяю. На OSS есть все, о чем заявили.
Я в самом начале написал, что можно писать на чем угодно. И готов это повторить. Вопрос не в языке. Вопрос в поддержке. Когда вы пишете на рекомендуемом языке вы используете библиотеку, которую вам предоставил производитель и работу которой он гарантирует. Вы не городите велосипеды. Вы говорите connect и библиотека сама продирается через уровни security и сама запихивает ваши команды на нужный узел или узлы. И если мы говорим о ssh, то вопросов почти нет. Во всяком случае они все решаемые. А если протокол закрыт? Допустим вы таки смогли разобраться. Но что-то пошло не так. И вы обращаетесь за консультацией к поставщику. А он мало того, что обиделся, что вы его протокол ковыряли (и еще хорошо, что санкций не последовало), так еще и очень вежливо говорит, что не собирается разбираться почему в вашем велосипедике когда вы крутите педали он мало того, что едет назад, так еще и поворачивает. И это будет очень здорово, что именно этим все закончится.
Сейчас многие производители рекомендуют Python. А с учетом того, что все сейчас ломанулись в облака, то без OpenStack точно не обойдется. А значит Python еще сильнее укрепит свои позиции как в сетях, так и в связи в целом.
Вы не найдете никаких особых отличий и в других языках. Как я уже и писал можно автоматизировать на любом из них. Даже на самых экзотических. Как-то мне попалась статья, где автоматизация делалась на Haskell.
Но дело не в самих языках. Дело в производителях. Они ведь не только говорят, что используйте Python потому, что нам так нравится. Когда у вас сеть из сотен, а то и тысяч устройств вы покупаете OSS сервер (как бы он не назывался в каждом конкретном случае), который уже обладает целым рядом инструментов, но если вам нужно что-то сделать дополнительно, то у вас есть выбор написать все нужные велосипеды, а потом то, что вам нужно на любом нравящемся языке, а можно воспользоваться уже готовыми библиотеками, которые помогают вам получать данные о сети и всех устройствах, ходить на них и там получать нужные параметры, работать с данными на самом сервере. Ведь обработку статистики или обработку аварий никто не отменял. Кроме скриптом в у вас еще куча другой работы. На велосипеды просто не остается времени. Поэтому да, Python, зачастую, хороший выбор уже просто потому, что его уже выбрали.
Может быть это несколько обидно, что обошли вниманием по всей видимости любимый вами PHP, но тут только два пути. Или обижаться или выучить Python. Лично я предпочитаю второй путь. Поэтому я писал на многих языках. В том числе и на всякой экзотике, которую предлагают производители. Они могут быть кривыми и неудобными, но они позволяют быстро сделать то, что мне нужно. И это в них главное.
Но дело не в самих языках. Дело в производителях. Они ведь не только говорят, что используйте Python потому, что нам так нравится. Когда у вас сеть из сотен, а то и тысяч устройств вы покупаете OSS сервер (как бы он не назывался в каждом конкретном случае), который уже обладает целым рядом инструментов, но если вам нужно что-то сделать дополнительно, то у вас есть выбор написать все нужные велосипеды, а потом то, что вам нужно на любом нравящемся языке, а можно воспользоваться уже готовыми библиотеками, которые помогают вам получать данные о сети и всех устройствах, ходить на них и там получать нужные параметры, работать с данными на самом сервере. Ведь обработку статистики или обработку аварий никто не отменял. Кроме скриптом в у вас еще куча другой работы. На велосипеды просто не остается времени. Поэтому да, Python, зачастую, хороший выбор уже просто потому, что его уже выбрали.
Может быть это несколько обидно, что обошли вниманием по всей видимости любимый вами PHP, но тут только два пути. Или обижаться или выучить Python. Лично я предпочитаю второй путь. Поэтому я писал на многих языках. В том числе и на всякой экзотике, которую предлагают производители. Они могут быть кривыми и неудобными, но они позволяют быстро сделать то, что мне нужно. И это в них главное.
Когда-то написал вот такой вот инструмент: https://github.com/kireevco/inventory-tamer сканирует сеть при помощи nmap, логинится через ssh по базе известных пар юзернейм-пароль, узнает ОС, если VMWare добывает еще информацию о том какие виртуалки работают складывает все в отчет нужного формата.
Пригодилось несколько раз когда приходишь в организацию с запущенным инвентарем
Сейчас для управления зоопарками использую Ansible, души в нем не чаю.
Кстати, inventory-tamer может генерировать inventory для того же Ansible :)
Весьма хорошее применение Python. Спасибо за статью.
Но есть пара вопросов больше с точки зрения необходимости использования таких методов при решении подобной задачи. У меня нет опыта работы с большой сетью так что у меня возникает вопрос.
Я так понимаю что Hostname и ip железки редко меняющиеся параметры, тогда этот скрипт будет работать с отдачей по всем хостам 1 раз. Далее просто будут добавлять записи в DNS чуть ли не по 1 штуке при подключении нового оборудования.
Разве задача решаемая этим скриптом не одноразовая, разве далее не целесообразней просто сразу заносить в DNS записи об оборудовании(руками или конфигурирующим скриптом)? Если при конфигурировании железки соблюдать регламенты(представим сферического коня/ИТ-службу в вакууме), то и скрип станет просто не нужен.
Но есть пара вопросов больше с точки зрения необходимости использования таких методов при решении подобной задачи. У меня нет опыта работы с большой сетью так что у меня возникает вопрос.
Я так понимаю что Hostname и ip железки редко меняющиеся параметры, тогда этот скрипт будет работать с отдачей по всем хостам 1 раз. Далее просто будут добавлять записи в DNS чуть ли не по 1 штуке при подключении нового оборудования.
Разве задача решаемая этим скриптом не одноразовая, разве далее не целесообразней просто сразу заносить в DNS записи об оборудовании(руками или конфигурирующим скриптом)? Если при конфигурировании железки соблюдать регламенты(представим сферического коня/ИТ-службу в вакууме), то и скрип станет просто не нужен.
Тут вот в чём дело, в DNS планируется добавлять и интерфейсы тоже. А значит при каждом изменении description, адреса придётся руками менять записи в файлах зон. Проще запускать раз в неделю/месяц скрипт, который полностью заменит существующие файлы. Если на момент запуска скрипта часть устройств будет недоступна, это не критично, так как процент таковых будет очень мал.
Конечно, идею можно развить: хранить собираемое в базе данных, генерировать файлы зон из базы. Убирать из базы записи, если устройство с ними не отвечало, например, две недели. Но, наверно, тут лучше адреса брать не из файла, а из базы системы мониторинга.
Если же в DNS добавляется только один адрес с устройства, то можно и вручную заполнять. Но скрипт точно будет без опечаток:)
Конечно, идею можно развить: хранить собираемое в базе данных, генерировать файлы зон из базы. Убирать из базы записи, если устройство с ними не отвечало, например, две недели. Но, наверно, тут лучше адреса брать не из файла, а из базы системы мониторинга.
Если же в DNS добавляется только один адрес с устройства, то можно и вручную заполнять. Но скрипт точно будет без опечаток:)
Если вы что-то автоматизировали и это отработало только один раз- это нормально и в этом нет ничего плохого. Но один раз получается очень не часто. Если мы говорим про большую сеть, то ее обслуживает и большое количество людей. И такие сети могут покрывать огромные расстояния. Вы можете даже никогда не увидеть людей, с которыми сотрудничаете годами. Представьте себе вышел из строя роутер за сотни километров от вас. Его заменил кто-то на месте и допустил ошибку при конфигурировании. И совсем не обязательно это вылезет сразу. И тут скриптик понадобится еще раз. И было бы хорошо иметь данные для сравнения и разницу получать на почту. В общем нет предела совершенству.
К тому-же если скрипт написан, то его содержание всегда можно изменить на нужное. Остальные части уже готовы. И скрипт уже будет запущен еще раз, а потом и еще раз ;)
К тому-же если скрипт написан, то его содержание всегда можно изменить на нужное. Остальные части уже готовы. И скрипт уже будет запущен еще раз, а потом и еще раз ;)
Ребята а как же NOC? Он же специально заточен под сетевые девайсы. Да и питона там хватает.
Лично у меня есть небольшой опыт работы с c++, VBS, Delphi, powershell… т.е. я имею представление о синтаксисе этих языков, владею такими штуками как указатели, ссылки, классы, коллекции… и каждый раз когда возникала необходимось что то автоматизировать — в большинстве случаев это был notepad++ т.к. трудозатраты на код были слишком большими. Но самая большая проблема — это выход из зоны комфорта т.к. программироавание это не основрой навык. К питону относился со скепсисом потому что там нет скобочек, да и в целом питон — не звучит…
Но вот как то сел на него и… Код пишется буквально налету. Получается сразу! Практически любая идея заканчивается небольшим куском рабочего кода. Куча библиотек. Куча готового кода. Поддержка вендоров.
Хочу добавить, что сетевику так же необходимо освоить регулярные выражения. Это отдельный непростой слой. В отличае от питона — высокий порог вхождения, но надо. К тому же регулярные выражения нужны и в powershell и в bash.
Лично у меня есть небольшой опыт работы с c++, VBS, Delphi, powershell… т.е. я имею представление о синтаксисе этих языков, владею такими штуками как указатели, ссылки, классы, коллекции… и каждый раз когда возникала необходимось что то автоматизировать — в большинстве случаев это был notepad++ т.к. трудозатраты на код были слишком большими. Но самая большая проблема — это выход из зоны комфорта т.к. программироавание это не основрой навык. К питону относился со скепсисом потому что там нет скобочек, да и в целом питон — не звучит…
Но вот как то сел на него и… Код пишется буквально налету. Получается сразу! Практически любая идея заканчивается небольшим куском рабочего кода. Куча библиотек. Куча готового кода. Поддержка вендоров.
Хочу добавить, что сетевику так же необходимо освоить регулярные выражения. Это отдельный непростой слой. В отличае от питона — высокий порог вхождения, но надо. К тому же регулярные выражения нужны и в powershell и в bash.
Со всем согласен
а тут не соглашусь:) Сложно понять логику регулярных выражений. Однако, CLI ведущих вендоров поддерживает регулярные выражения для фильтрации выводов команда типа show. Там всё проще и наглядно.
сетевику так же необходимо освоить регулярные выражения
а тут не соглашусь:) Сложно понять логику регулярных выражений. Однако, CLI ведущих вендоров поддерживает регулярные выражения для фильтрации выводов команда типа show. Там всё проще и наглядно.
Регулярки- великолепный инструмент. Сложный? Все зависит от того, на сколько сложные выражения вы используете. Можно ведь и попроще писать, а можно и посложнее, а можно и так, что у большинства людей мозг взорвется. Но каждый может их использовать на своем уровне и от этого хуже они не будут. Но при этом могут сэкономить кучу времени.
Не все поставщики позволяют фильтровать вывод. А те, что позволяют, не всегда дают достаточно свободы. Если у вас на работе приняты внутренние стандарты на все, то вы может и будете знать как будут выглядеть нужные вам поля. А если нет? Скажем вам нужно угадать как будет называться конфиг если вы знаете только то, что он может заканчиваться на cfg, cf или conf. А у особых раздолбаев и вообще быть без расширения. И тогда вам остается или все проверять руками или таки научится пользоваться Re.
PS: Если регулярки действительно очень тяжело идут, то можно использовать специальные программы, которые почти все сделают за вас. Вам останется только вставить готовую строку в ваш скрипт. На память помню только RegexBuddy, но для понимания о чем я говорю думаю хватит.
Не все поставщики позволяют фильтровать вывод. А те, что позволяют, не всегда дают достаточно свободы. Если у вас на работе приняты внутренние стандарты на все, то вы может и будете знать как будут выглядеть нужные вам поля. А если нет? Скажем вам нужно угадать как будет называться конфиг если вы знаете только то, что он может заканчиваться на cfg, cf или conf. А у особых раздолбаев и вообще быть без расширения. И тогда вам остается или все проверять руками или таки научится пользоваться Re.
PS: Если регулярки действительно очень тяжело идут, то можно использовать специальные программы, которые почти все сделают за вас. Вам останется только вставить готовую строку в ваш скрипт. На память помню только RegexBuddy, но для понимания о чем я говорю думаю хватит.
Должен поправиться: комментарий «а тут не соглашусь:) » относился к фразе «Это отдельный непростой слой».
Регулярные выражения просты, но не интуитивны для начинающего. Самый простой способ начать их использовать в CLI сетевого оборудования, или, как уже написал evseev, использовать готовые утилиты, бросая им на вход текст и регулярные выражения, анализируя результат.
Регулярные выражения просты, но не интуитивны для начинающего. Самый простой способ начать их использовать в CLI сетевого оборудования, или, как уже написал evseev, использовать готовые утилиты, бросая им на вход текст и регулярные выражения, анализируя результат.
zw_irk продолжение будет?
Обязательно. Скрипт уже год формирует зоны bind на реальной сети. Сейчас, фактически, я заново, поэтапно восстанавливаю процесс его написания. По идее, потом, на основе этого скрипта и статей, каждый сможет собрать из кусочков свои скрипты, использующие snmp.
Я опасаюсь давать какие-нибудь обещания по поводу сроков написания второй статьи, так как сейчас пишу с больницы. Но первая страница черновика уже набрана.
Я опасаюсь давать какие-нибудь обещания по поводу сроков написания второй статьи, так как сейчас пишу с больницы. Но первая страница черновика уже набрана.
Python — мощная штука. Достаточно взглянуть на примеры из комплекта — очень похоже, что на нём можно чуть ли не пол-линукса написать (большинство утилит точно можно).
Так что, если где-то нет возможности поставить какой-то софт (зависимости там или ещё что), то вполне можно написать свой велосипед на пайтон (никак не могу отучить себя от привычки называть его питон).
P.S. Тут упоминали про скрипты, которые везде работают — так вот, писал я скрипт, который (один и тот же файл) работал и на винде, и в линуксе, да ещё и с GUI, если надо. В одном файле код для bash, cmd, powershell, (ну и чуть всякого для GUI — из hta, IE, KDE). Основная проблема — код для разных ОС всё-таки разный, и для его модификации нужно и там и там править и отлаживать. Писалось это не для рабочих целей, а так, just for fun.
Так что, если где-то нет возможности поставить какой-то софт (зависимости там или ещё что), то вполне можно написать свой велосипед на пайтон (никак не могу отучить себя от привычки называть его питон).
P.S. Тут упоминали про скрипты, которые везде работают — так вот, писал я скрипт, который (один и тот же файл) работал и на винде, и в линуксе, да ещё и с GUI, если надо. В одном файле код для bash, cmd, powershell, (ну и чуть всякого для GUI — из hta, IE, KDE). Основная проблема — код для разных ОС всё-таки разный, и для его модификации нужно и там и там править и отлаживать. Писалось это не для рабочих целей, а так, just for fun.
Написать можно, но результат не всегда вам будет нравится. Нет, работать все будет. Тут вопросов нет. Но чистый Python очень медленный. Скажем в 1000 раз медленнее, чем С++ или Java. И это не всегда подходит.
Если нет возможности поставить другой софт, то почему все будет хорошо с Python? Он, конечно, малюсенький по современным меркам, но ни как не меньше 20МB. Да и с библиотеками можно попасть в неприятную ситуацию. Особенно если это какая-то специализированная система со старым Linux. Я как-то имел удовольствие с таким повозится. Было не очень.
Я то же писал, что бы везде работал. Но язык был один. Так, по-моему удобнее.
Если нет возможности поставить другой софт, то почему все будет хорошо с Python? Он, конечно, малюсенький по современным меркам, но ни как не меньше 20МB. Да и с библиотеками можно попасть в неприятную ситуацию. Особенно если это какая-то специализированная система со старым Linux. Я как-то имел удовольствие с таким повозится. Было не очень.
Я то же писал, что бы везде работал. Но язык был один. Так, по-моему удобнее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Зачем сетевику Python