PHP для управления серверами linux

php это дырявое решето в случае не вэба

Как будто в случае веба иначе.

Коллеги хотят написать CMS для выполнения различных команд (кнопку «сделать хорошо») на серверах и предлагают использовать для этого PHP.

Беги.

Всё зависит от того, как они обеспечат аутентификацию к этой веб-морде. Если на уровне веб-сервера (mod_auth_ldap какой-нибудь), то пускай будет хоть php.

puppet, cfengine, csync2

CMS - это как бы Content Managment System. Не очень вяжется с управлением серверами.

Все кругом говорят про Chef и Puppet. Сам не пробовал, не знаю.

вебмин, не?

Мне кажется что php это дырявое решето, но никаких аргументов привести не могу.

Потому что таких аргументов и нет. «Дыры PHP» не от языка, а от низкого уровня вхождения и низкой квалификации программистов. Язык тут не при чём.

пруфы?

Я просто не знаю как это еще назвать :)

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

Есть еще вопрос удобства написания и развития в дальнейшем.

Вот так?

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

в php нет многопоточности - уже только поэтому он не сможет очень многих вещей. например не сможет на нескольких серверах выполнить действия синхронно.

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

зы. советую http://ru.wikipedia.org/wiki/Puppet

И под каждый сервер отдельно пилить pp-шку? паппет имеет смысл, если у тебя больше 1 сервера, на котором нужно выполнить определенные одинаковые действия.

Это еще и Configuration Management System

потом выложите на свободный доступ ?

Черт его знает, как там будет, в перспективе.

Меня тоже это смущает. Puppet - это все же не совсем под данную тематику, мне кажется.

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

puppet, cfengine, csync2

Плюсую за puppet

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

ну изначально речь шла о парке серверов.

При этом ни слова об идентичности их конфигурации.

А не проще сделать общее хранилище скриптов?

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

Я днище, поэтому пишу свои велосипеды на python :(

Вот все говорят puppet, а никто ничего конкретного не предложил.

Leave: да, не стоит пилить .pp под каждый сервер, но тут задача проще, просто выполнить команду. Итак, создаем класс как тут http://www.puppetcookbook.com/posts/exec-a-command-in-a-manifest.html только добавляем " creates => /tmp/command_XXX_executed" , так что когда puppet ее исполнит, он создаст файл и больше не будет исполнять эту команду. Допустим puppet клиенты забирают receipts с сервера раз в 30 мин. Далее наблюдаем в puppet-dashboard о результатах.

Я реализовывал так... Запущен php скрипт в screen который циклично проверяет содержимое базы, в базу через веб морду пишутся команды для сервера, с ключом пользователя который выполнил команду, проверил ключ, выполнил команду из скрипта в screen вернул ответ в базу, можно не ожидая ответа запустить процесс(скорее всего в твоем случае будет так), потом отслеживаешь по файлу, появился или нет, изменяется размер в течение 1 минуты или нет, ну и т.д. Аунтифекация проходила через ssl. Минусы есть у php... Допустим если надо перевернуть им кучу данных, больше 8 мб, можно сразу забыть о нем... Тайм аут выполнения операции тоже урезано до 30 секунд, по моему(точно не помню, давно не писал на php), нет многопоточности(поэтому выполнял команды по очереди и приоритету).

Применял этот способ для управления игровым сервером, в плане безопасности особо не парился, все бэкапилось...