LINUX.ORG.RU

Основы применения Python в администрировании Linux

 , ,


0

0

В статье описаны преимущества языка Python при использовании его в качестве инструментария для решения задач системного администрирования по сравнению с возможностями стандартного командного интерпретатора bash. Python – удобный инструмент для решения задач системного администрирования, как повседневных, так и более специфических. Он одинаково подходит для создания как скриптов, так и более сложных приложений, в особенности сетевых, а также может служить заменой стандартному shell в Linux.

>>> Подробности

★★★

Проверено: boombick ()
Ответ на: комментарий от Vudod

решал на Питоне следующую задачу:


Открой для себя find /path -exec ... ;)

scott_tiger ★★★
()
Ответ на: комментарий от gns

> Черевато отсутствием питона на некоторых маргинальных конфигурациях.

fixed.

На остальных он есть изкаропки, либо доставляется по требованию.

MATPOCKUH
()
Ответ на: комментарий от anonymous

> Монологе «запустить дурочку» ваш стиль.

Позвольте, а что, теперь надо начать читать курс лекций по использованию bash в _разумном_ администрировании? Так с bash надо было знакомиться малость по-раньше... Когда в своей «верхней школе» учились. Сейчас это уже только как «самообразование».

Я же могу только проиллюстрировать на примерах. Кое-что. Итак. Как я и писал выше, у меня есть ряд задач, решаемых в повседневной жизни посредством скриптов.

Условие. Дистрибутив Slackware. Да. Я так хочу, а что, нельзя? Смотрим на список устанавлеваемого программья. Питон (равно как и много чего ещё) устанавливается _отдельно_ и не входит в «базовый» комплект. Можно ставить, можно воздержаться. К тому же, я гномовод. Гнома там вообще нет. Его ставим отдельно.

Далее. Я хочу переконвертировать (например) фидео из одного размера экрана в другой. Ну, в машине, как кар-писи использую асуску 900, так что, в пробке, где-то на МКАД, хватает времени в полглаза познакомиться с очередным «шедевром» и принять решение — смотреть на «большом экране» или воздержаться.

Скрипт от нуля писать не будем, ибо я слишком ленив и предпочитаю подточить почти готовое. Берём скрипт http://g-scripts.sourceforge.net/nautilus-scripts/Multimedia/Video/video-convert Там надо подтачивать подгонку в размеры экрана для ASUS EEE PC 900. Надеюсь, осилите? Мне здесь влом выписывать. Простите, но здесь не сайт IBM.

Итак. Беру сей скриптец, копирую его в ~/.gnome2/nautilus-scripts, ставлю ему chmod u+x video-convert. После этого, в наутилус выбираю нужный мне файл, клик правой клавишей, из контекстного меню выбираю «Сценарии» -> video-convert (хотя, религия не запрещает мне назвать файл «Видеоконвертер») и, о чудо, оно РАБОТАЕТ!!! Аааа!!! Да как же я, урод старый, без перла с питоном-то!!! :))) И я сильно удивлюсь, если Вы не найдёте в самом начале приведённой ссылки строки #!/bin/bash... :)))

Далее. В чём проблема? В «сложном» программном комплексе? Но здесь так же понятие «сложности» весьма относительно. Во-первых, на bash «писать всё» это то же самое что и «писать всё» на ассемблере или «писать всё» на php. Пример с БД выше.

Более простой пример. Дан каталог с .png-файлами. Я очень хочу убрать из некоторых файлов альфа-канал. В ряде случаев оно уменьшает размер файла и (опять-таки) в ряде случаев оно допустимо — не ухудшит качество изображения. Как пример — .pngшник 640х480 с альфой занимает ~42K, без оной — ~18K. Обрабатывается простой командой convert file.png +matte file_new.png

Пусть такие файлы лежат в некотором каталоге... 1. Создаём в данном каталоге подкаталог processed (чтоб не валить всё в кучу). 2. Предельно простой скрипт обрабатывает всё это файло (мы обрабатываем не ВСЕ файлы, а по выбору — указываем в командной строке): #!/bin/bash for file in «$@» do convert +matte «$file» «processed/$file» done

Что здесь сложного-то? Если нужен «комплекс» (например, мне отработанное файло нужно скопировать по scp в каталог на другм сервере), то что мне может помешать использовать команду scp /откуда username@host:/куда? В том же скрипте? Необходимость ввода пароля помешает? :))) Ню-ню...

В общем, вместо написания всякой ерундистики, просто научитесь объединять ряд максимально простых задач в единую логическую последовательность исполнения, да и используйте... В чём возникает проблема? В возвращаемых значениях? Ну, понятно — всенепременно надо взгромоздить в систему питон и тащщиться от него.

Мдее... Осталось только про такую зачудительную чтучку как «dialog» расписать... Но это уже, ей Богу, в качестве домашнего задания. Я тут всё это писать просто не осилю...

anonymous
()
Ответ на: комментарий от MATPOCKUH

Я не уверен, но как не оговаривается ли в стандартах XPG4 и прочем POSIX язык написания стартовых скриптов? что-то там было на эту тему, сейчас не помню.

К тому же python лежит на /usr обычно. А /usr может и не быть смонтирвованным (вследствии ошибки, например).

Насчет «маргинальных» конфигураций, так, по-Вашему, весь «embedded linux» в маргиналы записать? :)

gns ★★★★★
()
Ответ на: комментарий от gns

Если позволите...

> Я не уверен, но как не оговаривается ли в стандартах XPG4 и прочем POSIX язык написания стартовых скриптов? что-то там было на эту тему, сейчас не помню.

Не совсем, по-моему, так... Стандарт IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools standard, по-моему, чёток в определениях. Я , к сожалению, посеял сей документ, но можно посмотреть отсылку к этому документу на странице http://www.gnu.org/software/bash/ . Вторичный, по отношению к IEEE/POSIX стандарт OpenGroup (они разрабатываются на основе стандартов IEEE), даёт определение как самого командного интерпретатора — sh http://www.opengroup.org/onlinepubs/7990989775/xcu/sh.html , так и языка команд этого интерпретатора — http://www.opengroup.org/onlinepubs/7990989775/xcu/chap2.html#tag_001

Но дело в том, что сам по себе sh и bash есть разработка одного и того же человека — Stephen R. Bourne. Таким образом, получается что описаный в документации sh и bash имеют весьма много общего. Второй, по сути дела, есть просто расширение первого.

На самом деле, в Linux довольно просто это проверить: which sh даёт /bin/sh, а ls -la /bin/sh выдаёт что это симлинк на /bin/bash.

Если кому-то захочется наиполнейшего соответствия bash _всем_ стандартам POSIX, то тогда придётся пересобрать bash с опцией --enable-strict-posix-default (как вариат --posix или -o posix) в опциях configure. Да. В этом случае всё будет более чем наполовину :) POSIX-compatible... Но смысл?

С другой стороны, на систему скриптов инициализации не накладывается особых ограничений. Она может быть либо BSD-init (семейство *BSD, слака до 12, по-моему, версии), либо SysV-init. То, что в современном Linux используется — /etc/init.d/something start|stop|restart...

Но проблема в том, что эти скрипты должны обрабатываться именно командным интерпретатором (шеллом) при старте системы. Ну, если в качестве шелл использовать питон... То... Почему бы и нет? Тогда переписать стартап-скрипты можно и на питоне... Оригинально, конечно, правда... Кто же в таком случае будет маргиналом, интересно? :)))

К тому же python лежит на /usr обычно. А /usr может и не быть смонтирвованным (вследствии ошибки, например).

Всё верно... Он относится большинством «сообщества» к user commands и носит (если верить FHS и забить на аналитиковЪ LOR) «optional» http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE20 И Perl там же... По соседству... ;)

anonymous
()
Ответ на: комментарий от anonymous

Как интересно, продолжайте

anonymous
()

Жидковатый какой-то срач получается.

Эх, маэстро Луговского бы сюда...

hozzzar
()

как командный интерпретатор bash может и пойдет, хотя подошел бы и любой другой, как язык для написания чего либо ИМХО плох; python vs perl разумен только в случае что лучше знаешь, или хочешь узнать в перспективе на будущее; perl6 радует своей попыткой повторить возможности common lisp, но если есть cl то зачем? только чтоб не использовать скобки и s нотацию?

screamager
()
Ответ на: комментарий от gns

А причем тут стартовые скрипты? Я лишь говорил, что питон доступен в любом современном дистре.

И, таки, да, по-моему, весь ембед - маргиналы относительно десктопа.

MATPOCKUH
()
Ответ на: комментарий от MATPOCKUH

Тогда посмотрите на мой самый первый комментарий. Десктор — не весь линух. И даже не самая его лучшая часть :)

gns ★★★★★
()
Ответ на: комментарий от gns

Ну... ответил на вашу фразу вне контекста про init.d, бывает. (:

Ну да, плюс сервера. Но ембед в плане администрирования еще беднее. Там обычно и баша-то полноценного нет. Поэтому да - маргиналы (:

MATPOCKUH
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.