Назад | Перейти на главную страницу

Переносимый язык сценариев для администратора с несколькими серверами?

Пожалуйста, обратите внимание: Portable, как в portableapps.com, а не в традиционном определении. Первоначально опубликовано на stackoverflow.com, задавая здесь вопрос по предложению другого пользователя.

Я администратор баз данных и системный администратор, в основном работаю с Windows-машинами, на которых работает SQL Server. Я ищу язык программирования / сценариев для Windows, который не требует доступа администратора или установщика и не требует процесса установки, кроме развертывания его в папку. Я намерен создать язык для автоматизации, который можно было бы стандартизировать.

До этого момента я использовал комбинацию командных файлов и оболочки Unix, используя sh.exe из UnxUtils но это далеко не идеальное решение.

Я оценил несколько вариантов, все они имеют как минимум один серьезный недостаток. Я сильно предпочитаю что-то с открытым исходным кодом или двойную лицензию, но меня больше интересует поиск подходящего инструмента, чем что-либо еще. Меня не интересует что-нибудь, что полагается на Cygwin или Java, но на данный момент я бы согласился с тем, что требует .NET.

Требования:

Бонусные очки:

Пока я пробовал:

---- вырезано: моменты уточнения ----

Почему все ограничения?
Я понимаю, что некоторые из моих критериев кажутся произвольно ограничивающими. Это в первую очередь продукт моей среды. Я работаю администратором баз данных SQL Server и администратором резервного копирования Unix в подразделении крупной компании. В дополнение к почти сотне компьютеров, на которых установлена ​​та или иная версия SQL Server в Windows, я также поддерживаю установку SQL Server Express Edition на более чем тысячу машин в полевых условиях.

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

У меня могут быть временные права администратора на коробке, но я не в админ для машины - я просто администратор базы данных. Мне неинтересно наступать на пятки администраторам Windows, и я не хочу брать на себя их обязанности.

Если я поднимаю вопрос об установке чего-либо, внезапно это становится предметом интереса для Production Control и администраторов Windows; если я копирую сценарий, никто не возражает. Это различие может не иметь большого значения для читателей, но если кто-то поймет неверную идею, мне внезапно придется долго ждать и иметь значительные накладные расходы, прежде чем я смогу установить инструмент и решить проблему.

Вот почему мне нужно что-то, что можно копировать и запускать как портативное приложение. А как насчет небольшого размера? У моей компании есть три подразделения, каждое из которых находится в разных географических точках, и одно из них - новое приобретение. У нас разные политики контроля производства / безопасности в каждом подразделении. Я поддерживаю наши базы данных MSSQL во всех трех подразделениях. Полевые машины разбросаны по США, иногда подключаясь к VPN по очень медленным каналам. Установка Ruby \ с использованием psexec заняла много времени из-за этих подключений. В этих случаях более значительным расточителем времени становятся архивы с тысячами и тысячами файлов, а не их чистый размер.

Можно сказать, что я избалован Unix, где у администраторов обычно установлен хотя бы какой-нибудь современный язык сценариев; Я бы использовал PowerShell, но я плохо его знаю и, что более важно, это не везде, где мне нужно работать.

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

Я бы сказал, что vbscript / jscript - ваш лучший выбор для существующей среды 2003 года. Если вы можете немного настроить свои спецификации, чтобы разрешить установку, PowerShell - это путь вперед, особенно потому, что в настоящее время PowerShell доступен и будет использоваться в будущем для управления sql. Если вам действительно нужна переносимость (и, честно говоря, это означает, что ваш потенциал сценариев ограничен синтаксическим анализом строк из текстовых файлов и имен файлов), то я бы сказал, что следующий лучший вариант - perl. Perl не требует установки в Windows для работы. Обратите внимание, что вам не нужны unxutils, если вам просто нужны команды unix, вам просто нужно установить службы для подсистемы unix.

Все, что было сказано, я думаю, что ваша предпосылка ошибочна. Я не могу придумать причину, по которой я хотел бы «стандартизировать» язык автоматизации, поскольку требования к задачам для * nix и задач Windows потребуют совершенно разных типов кодирования. Например, для многих системных задач в Windows вы собираетесь использовать вызовы WMI. WMI недоступен в * nix. (да, я знаю, что CIM есть, но это не то же самое). Даже такие простые вещи, как пути к именам файлов, будут анализироваться и записываться по-другому. Я бы посоветовал использовать лучший инструмент, доступный для работы, вместо того, чтобы пытаться забить неизбежно квадратный колышек в круглое отверстие.

Я не думаю, что он отвечает всем вашим требованиям (аспект SQL Server \ ODBC, который явно критичен), но у меня есть древний (с датой 1996 г.) Perlv4 exe, который я везде ношу с собой, потому что всякий раз, когда я просто хочу сделать что-то быстрое и неприятное. 379k - 1 файл, не требует установки, работает во всех ОС Windows, в которых я его пробовал.

Почему с сегодняшней емкостью хранилища ваша «управляемая площадь» так мала (и почему количество файлов вообще имеет значение)? Лично я предпочитаю Perl, недостатком которого является только размер. Фактически, если вы находитесь в одной AD, вы можете выполнить установку ActiveState Perl по пути UNC и получить доступ к этому пути UNC с любого компьютера, поэтому вам не нужно вообще ничего устанавливать на всех других ваших машинах. .

С Perl2EXE вы можете упаковать что угодно в EXE, но это не изящно или неэффективно по размеру.

Кроме того, за исключением желаемой точки совместимости не с Windows, подойдет PowerShell, за исключением требования, чтобы он работал без установщика. Честно говоря, вы могли бы также считать его необязательной частью ОС и просто добавить его в свою стандартную среду (если у вас есть какой-либо контроль над средой).

Итак, это два моих предложения.

Наполовину насмешливо: Эй ... VB-скрипт идет вместе с ОС, насколько меньше нужно занимать место?

В противном случае я очень, очень рекомендую Ruby. Зачем нужна «небольшая занимаемая площадь»? Я установил Ruby на несколько серверов Windows, потому что он чертовски удобен - и не требует прав администратора (хотя это само по себе является большим красным флажком для ваших целей, но давайте пропустим это).

Что о Портативный autohotKey

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

Справочник команд AutoHotkey

Еще одно голосование за VBScript здесь; он может удовлетворить почти все ваши требования; однако упускает большую часть «бонусных очков».

Портативный Python, определенно (я знаю, вы пробовали :)

Итак, вот мои два цента о скриптах. В производственных системах ... используйте то, что есть, Windows 2003 - VBScript, UNIX bash / perl / python / что угодно (лично я использую комбинацию bash и perl).

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

Вот мои мысли по этому поводу: я рядом с вашими администраторами - чем меньше установлено, тем лучше. Кроме того, если вы действительно серьезно думаете о задачах, которые вы выполняете, действительно ли у вас есть много, что нужно поддерживать на нескольких языках? В основном сценарии зависят от конкретной задачи и, следовательно, от ОС / приложения.

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

Кроме того, если вы поместите все свои скрипты в систему управления версиями, это также облегчит вам задачу. У меня есть небольшая установка сервера CVS с коллекциями для моих сценариев Powershell, VBscript, bash, perl и php.