Простые задачи, выполняемые часто. Третья категория - очевидный случай, здесь отдача от автоматизации будет максимальной. Время, потраченное вами на автоматизацию процедуры, вскоре окупится, потому что вы будете выполнять задачу снова и снова. Всегда автоматизируйте скучные и повторяющиеся дела.
-
Сложные задачи, выполняемые часто. Четвертая категория - ловушка для системных администраторов, которые часто взваливают на себя больше, чем могут нести. Эта категория требует, чтобы вы убедили руководство в необходимости выделить ресурсы (время и деньги) на решение проблемы. Результатом может быть покупка коммерческого программного продукта, интеграция бесплатных инструментов и/или инструментов с открытым кодом в вашу систему или разработка собственного решения.
Теперь, специально для читателей, мыслящих зрительными образами, приведу эти категории в виде таблицы (рис. 13.1).
|
Простые задачи
|
Сложные задачи
|
Выполняются одно кратно
|
Выполните вручную
|
Автоматизируйте
|
Выполняются часто
|
Автоматизируйте
|
Купите или разработайте приложение
|
Рис. 13.1. Категории задач системного администрирования
Многие удивляются, узнав, что я автоматизирую простые, но часто выполняемые задачи. Если задача проста, зачем ее автоматизировать? Я автоматизирую многие процессы из второй и третьей категории - от крупных задач до небольших последовательностей команд - по одной причине. Автоматизация процесса придает ему повторяемость и масштабируемость, гарантируя выполнение без ошибок:
• Повторяемость означает, что я могу многократно выполнять этот процесс. Например, устанавливая новые компьютеры, я хочу, чтобы все они запускались с одной конфигурацией программного обеспечения и с одинаковыми настройками. В противном случае обслуживание этих компьютеров превратится в кошмар. Если я автоматизирую процесс установки, он станет повторяемым, и все компьютеры будут иметь одинаковую конфигурацию. Если у меня какой-то процесс работает, я хочу, чтобы он каждый раз работал одинаково.
-
Автоматизация избавляет меня от необходимости запоминать редко выполняемые сложные процессы. Иногда очень много времени уходит на выяснение опций командной строки, необходимых для выполнения поставленной задачи. Я превращаю в сценарий даже одиночную команду, чтобы через несколько месяцев мне не пришлось изобретать велосипед. Это, так сказать, долгосрочная повторяемость. Например, в Mac OS X я могу «прожечь» ISO-образ диска на CD-ROM с помощью команды hdutil. Однако вместо того чтобы читать руководство всякий раз, когда мне нужно вспомнить, какие опции подходят лучше всего, я инкапсулировал эту команду в сценарий. Теперь я всегда смогу использовать текст сценария для справки, даже не запуская его.
-
Масштабируемость. Это качество означает, что я смогу выполнить процесс независимо от того, как разрастется моя сеть. Автоматизировав процесс один раз, я смогу запускать сценарий на всех компьютерах, распространяя свое умение на все узлы сети. Например, очень легко изменить настройку конкретного SSH-сервера. Несколько секунд работы в текстовом редакторе, и файл sshd_config изменен. Однако если автоматизировать этот процесс, то я смогу запустить его на сотнях компьютеров, возможно, оставив его выполняться ночью. Мне не нужно будет присутствовать при его выполнении и волноваться о том, на скольких компьютерах он работает — на 10 или 10 000.
-
Автоматизация помогает избежать опечаток. Многие команды трудно ввести с клавиатуры без ошибок. Например, ту короткую последовательность команд, которую я постоянно использую. В нескольких строчках мне приходится трижды вводить имя пользователя и дважды - его учетный номер. Все это несложно набрать на клавиатуре, но довольно просто допустить опечатку. Превратив эту задачу в сценарий, я исключаю опечатки. Даже если надо ввести лишь несколько строк, имеет смысл создать сценарий.
Процесс автоматизации
Чтобы что-то автоматизировать, сначала следует выполнить это вручную. Затем нужно написать код для каждого шага. После этого вы должны собрать эти фрагменты кода воедино, тестируя каждое добавление. В завершение необходимо протестировать всю систему.
Шаг 1: выполнение процесса вручную
Первый шаг при автоматизации процесса состоит в обязательном выполнении его вручную. Задокументируйте каждый шаг и убедитесь, что вы знаете, как закодировать его. Потом соберите все фрагменты кода.
Один мой юный помощник постоянно подходил ко мне с просьбой помочь ему автоматизировать тот или иной процесс: «Я бьюсь над этой проблемой уже несколько часов! Я в тупике!»
«О'кей,» - отвечаю я, - «Покажи, как ты это делаешь вручную».
«Я не знаю. Мне не удалось это выяснить».
«Вот в этом твоя главная проблема, балбес. Понял?»
Как было сказано в главе 12, одним из плюсов документирования является то, что запись шагов процесса позволяет вам впоследствии автоматизировать его. Я не шучу. Если у меня нет времени автоматизировать какую-то задачу, я привожу ее поэтапное описание на своем Wiki-сайте и поручаю кому-нибудь ее выполнить. Тем самым я достигаю сразу две цели. Во-первых, я расширяю документацию, описывающую работу нашей системы. Во-вторых, я делаю первый шаг на пути автоматизации этой задачи!
Документируйте все шаги процесса, а затем автоматизируйте их. Если вы не в состоянии записать шаги, вы никогда не сможете автоматизировать их.
™
Запись процесса уже вынуждает вас идентифицировать все его этапы. Вместо того чтобы держать их в голове, вы покажете документ другим, и они смогут проверить его на практике.
Если у вас нет Wiki-сайта, воспользуйтесь ручкой и бумагой или текстовым файлом. Выполняйте процесс вручную и записывайте, что вы делаете. Каждую введенную вами команду следует включить в документ.
Шаг 2: кодирование каждого шага
Преобразуйте каждый шаг в команду или короткую программу. Протестируйте каждый шаг отдельно. Иными словами, напишите несколько маленьких сценариев, каждый из которых позволит убедиться, что код для соответствующего шага верен.
Если на каком-то шаге вы используете графический пользовательский интерфейс, необходимо найти его эквивалент в виде последовательности команд. В некоторых операционных системах это просто. Например, в SAM (System Administration Manager, диспетчер системного администрирования) из HP-UX есть кнопка, позволяющая отобразить команду операции, которую диспетчер выполнит следующей. В Mac OS X есть Automator и AppleScript, позволяющие автоматизировать операции, выполняемые с помощью графического интерфейса. Для Windows есть множество аналогичных утилит. Однако инструменты, автоматизирующие щелчки по кнопкам, могут оказаться менее эффективны, чем непосредственная установка ключей реестра или записей LDAP.
Рекомендуемая литература для администраторов Microsoft Windows:
♦ «Windows Server Cookbook» (Сервер Windows. Сборник рецептов), O'Reilly. Прочитав ее от корки до корки, вы узнаете массу полезных вещей. Вас удивит, как много операций, которые вы привыкли выполнять с помощью графического интерфейса, может быть записано
в виде сценариев путем несложного редактирования реестра. Эта книга откроет вам глаза на многое. Примеры приводятся на нескольких языках, как правило на VBasic и Perl.
-
«Perl for System Administration», O'Reilly.1 Эта книга особенно пригодится тем, кто работает и в UNIX, и в Windows. Как следует из названия, основное внимание в ней уделено языку Perl, и люди с опытом работы в Enterprise или UNIX с легкостью осилят ее. Кроме того, она будет полезна тем, кто много работает с ActiveDirectory и/или LDAP.
-
«Win32 Perl Scripting: The Administrator's Handbook» (Создание сценариев на Perl для Win32. Справочник системного администратора), Sams. Тоже весьма полезная книга, особенно если вы только начинаете писать сценарии.
Рекомендуемые книги для администраторов UNIX/Linux:
-
«Perl for System Administration» (см. выше).
-
«UNIX System Administration Handbook»,2 Prentice Hall PTR. Эта книга не только учит вас основам системного администрирования в UNIX, но и содержит много полезных ссылок и инструментов. В большинстве примеров приводится командная строка, что облегчит написание сценариев.
-
«Essential System Administration» (Основы системного администрирования), O'Reilly. Еще одна великолепная книга с примерами, в которых используется командная строка.
-
«Advanced Bash-Scripting Guide» (Расширенное руководство по написанию скриптов bash). Посетите сайт http://www.tldp.org/gui- des.html.
Шаг 3: сборка шагов воедино
Если код каждого шага работает, вы можете собрать все фрагменты в один сценарий.
При сборке кода все-таки лучше добавлять по одному шагу за раз. Тестируйте код после каждого добавления. Такой подход называется итеративной разработкой и является оптимальным при автоматизации. Тестируя сценарий после каждого добавления, вы в большей степени уверены, что вся конструкция работает, как задумано.
Например, когда на работу приходит новый сотрудник, нужно создать для него запись в каталоге LDAP, выделить ему место на внутреннем веб-сервере и протестировать его учетную запись, чтобы убедиться в ее корректности. Каждое из этих действий может быть автоматизировано само по себе. Убедитесь, что команды, выполняемые на каждом шаге, работают. Затем соберите первую группу команд в сценарий и протестируйте его. Убедитесь, что последовательность команд работает и выводится необходимая вам отладочная информация. Запустите сценарий и убедитесь в корректности записей LDAP. Если все работает, добавьте следующую группу команд и протестируйте, что получилось. Убедитесь, что записи LDAP по-прежнему корректны и что пространство на внутреннем веб-сервере выделено. Добавьте еще одну группу команд и снова все проверьте.
Шаг 4: тестирование всего процесса
Наконец, мы должны протестировать процесс в целом. Если мы тестировали его после добавления каждого шага, тут будет совсем немного работы.
Вообще-то программисты не любят тестировать. Им хочется, чтобы программа правильно работала с первого запуска. Если выполнять тестирование на каждом шаге, оно не выглядит особо трудоемким; в результате на последней стадии приходится делать не так уж много.
Простые задачи, выполняемые часто
Приведу несколько примеров часто выполняемых простых задач. Обращаю внимание системных администраторов Windows, что эти примеры ориентированы на UNIX/Linux. Тем не менее, общие принципы применимы ко всем операционным системам.
Сокращения для команд
Большинство систем с командной строкой имеет ту или иную возможность создания псевдонимов. Это позволяет вам создавать новые команды на основе существующих. В каждой операционной системе принят свой синтаксис. В системе UNIX имеется множество языков оболочки (командной строки), самыми популярными из которых являются bash и csh. Они сильно различаются, и вы заметите, что, в первую очередь, в bash приходится употреблять знак равенства. Я приведу примеры для обеих оболочек.
0
Примеры на bash будут работать в любой оболочке, смоделированной по оригинальной Bourne Shell, созданной Стивом Борном (Steve Bourne) (/bin/sh), например в Korn Shell (/bin/ksh) и Z Shell (/bin/zsh). Аналогичным образом примеры на csh будут работать в любой оболочке, имеющей корни csh, включая оболочку Тепех С shell (/bin/tcsh).
Как попасть в нужный каталог
Мне нередко приходится выдавать команду cd для перехода в каталог с очень длинным путем. Вот пример использования псевдонима:
bash:
alias book='cd ""tal/projects/books/time/cHapters1
csh:
alias book 'cd "tal/projects/books/time/chapters1
Теперь я могу набирать на клавиатуре book каждый раз, когда мне нужно перейти в каталог, где находятся файлы для текущей книги. Если я возьмусь написать другую книгу, я обновлю этот псевдоним. (Я ввожу «book» в течение последних шести лет!)
Это не только позволяет сэкономить на вводе. Вы избавлены от необходимости запоминать путь к каталогу. Освободить свою память всегда полезно.
Чтобы сделать псевдоним постоянным, вы должны добавить указанную строку в файл .profile, .bashrc (bash) или .cshrc (csh). Эти файлы считываются только во время входа в систему, так что либо выйдите из системы и войдите обратно, либо введите команду source, чтобы файлы были прочитаны снова.
bash:
. V-profile
csh:
source "/.cshrc
(Примечание: в bash эта команда обозначается точкой.)
Псевдоним может обозначать целую последовательность команд. Отделяйте их друг от друга точкой с запятой. Вот пример, где выполняется переход в некоторый каталог и устанавливается переменная окружения в зависимости от того, работаем мы в системе А или В:
bash:
alias inya='cd "tal/projects/inventory/groupa ; export INVSTYLE=A' alias invb='cd "tal/projects/inventory/groupb ; export INVSTYLE=B'
csh:
alias inva 'cd "tal/projects/inventory/groupa ; setenv INVSTYLE A' alias invb 'cd "tal/projects/inventory/grojpb ; setenv INVSTYLE B'
Вместо точки с запятой можно поставить двойной амперсанд для обозначения такого условия: «Выполнить следующую команду только в том случае, если первая завершилась удачно». Этот прием полезен, если нужно избежать выполнения команды не в том каталоге. Напри
мер, вы хотите перейти в некоторый каталог и поставить там метку времени в журнале. Однако если команда cd не будет выполнена (сервер недоступен), не следует ставить метку времени в журнале текущего каталога.
bash:
alias ranM'cd /home/rank/data && date ».log' csh:
alias rank 'cd /tiome/rank/data U date ».log'
Не пытайтесь превратить одну операционную систему в другую. Псевдонимы сами по себе хороши, но ими нельзя злоупотреблять. Я часто видел людей, создающих десятки псевдонимов для того, чтобы симулировать DOS в UNIX. Думаю, это плохая идея. Так вы никогда не научитесь работать в UNIX, а, оказавшись за чужим компьютером, где нет ваших псевдонимов, попадете впросак.
Сокращения для имен компьютеров
Если вам приходится снова и снова вводить имена каких-то компьютеров, вы можете сэкономить немного времени, создав псевдонимы. Например, если вы часто обращаетесь к серверу ramanujan.company.com, то можете создать псевдоним (запись DNS CNAME) ram.company.com. Это имя чуть проще набирать на клавиатуре.
Проблема, связанная с таким подходом, заключается в том, что он может превратить сопровождение в кошмар. Если пользователи станут употреблять оба имени, вам придется сопровождать два имени. Вопрос: как бы создать псевдоним, известный только вам, не беспокоя других пользователей?
Как правило, часто обращаясь к какому-то серверу, я почти во всех случаях использую SSH (Secure SHell). Это безопасная (криптографически защищенная) альтернатива telnet и rsh. С ее помощью вы также можете копировать файлы (вводя scp вместо гср), и многие программы, например rsync, работают с SSH. Система Unix SSH (OpenSSH и ее сестры) позволяет вам установить псевдонимы, известные всем пользователям UNIX, либо псевдонимы, доступные только вам.
Чтобы ограничиться только своими SSH-сеансами, добавьте псевдонимы в файл ~/.ssh/config. Если же вы хотите предоставить псевдонимы в распоряжение всех пользователей, добавьте псевдонимы в файл /etc/ ssh config или /etc/ssh/ssh_config в зависимости от конфигурации вашей системы. В следующем примере я создаю псевдоним es, чтобы избавить себя от необходимости вводить mm. everythingsysadmin. com:
Host es
HostName www.everythingsysadmin,com
Теперь я могу не только вводить ssh es вместо ssh www everythingsysad- min.com, но и использовать этот псевдоним в командах scp, sftp, rsync и других. Более того, сценарии и программы, которые я не могу изменить, будут автоматически воспринимать новые настройки. Вот несколько примеров:
S ssh es
$ scp file.txt es:/tmp/
$ rsync ex:/home/project/alpha "/project/alpha
Я использую ssh es так часто, что создал псевдоним на уровне оболочки: bash:
alias es='ssh es'
csh:
alias es 'ssh es'
В результате теперь я могу вводить в командной строке es, чтобы войти в систему, или с помощью всех тех же двух букв обозначить хост в командах scp или rsync. Ведь круто?
Возникает соблазн создать двухбуквенные псевдонимы для всех серверов на свете. Однако вскоре вы обнаружите, что вспоминаете обозначения дольше, чем вводите имена с клавиатуры. Я ограничил себя несколькими серверами, к которым обращаюсь через SSH.
На странице ssh_config(5) справочной системы man перечислено много других опций конфигурации. Например, иногда я обращаюсь к серверу, для которого требуется весьма специфическая комбинация опций в командной строке. (Это доморощенная версия SSH-сервера, которая не только не обладает всеми функциональными возможностями, но просто отказывается работать, получая строку, которую не понимает.) Команда, которую я должен ввести, выглядит так:
$ ssh -х -о RSAAuthentication=yes -о PasswordAuthentication=yes -о ChallengeaesponseAuthentication=no -1 peter.example.net
Я мог бы установить псевдоним, но вместо этого изменил конфигурацию SSH, и все системы, использующие SSH, работают, как надо. Если сценарий, который я не могу изменить, использует SSH для доступа к тому серверу, он воспримет эти настройки.
Соответствующие строки в моем файле ~/.ssh/config выглядят так:
Host peter.example.net ForwardXll no RSAAuthentication yes PasswordAuthentication yes ChallengeResponseAuthentication no Compression no Protocol 1
У SSH-клиентов для Windows обычно есть графический интерфейс, позволяющий сохранить настройки профиля, которые следует использовать для конкретного сервера (или нескольких серверов).
Чем больше вы знаете про SSH, тем больше вы можете сделать. Есть много хороших книг и электронных справочников с подробным описанием SSH, например «SSH, The Secure Shell: The Definitive Guide» (SSH. Безопасная оболочка: полное руководство), O'Reilly. Если в SSH и есть то, что должен знать каждый системный администратор (но, возможно, не знает), то это следующее: как настроить открытые/закрытые (public/private) ключи, чтобы, не снижая уровень безопасности, исключить необходимость ввода пароля при обращении с одного конкретного компьютера к другому через SSH.
Make-файл для каждого хоста
Этот раздел относится исключительно к системам UNIX/Linux. Тот, кто работает в Windows, может его пропустить.
В системах UNIX/Linux важная информация часто хранится в обычных текстовых файлах, которые можно отредактировать вручную. В некоторых случаях после редактирования файла необходимо выполнить специальную команду, чтобы сообщить системе, что информация изменилась.
Например, после редактирования файла /etc/aliases (к которому обращаются sendmail, Postfix и различные пакеты пересылки почты), вы должны выполнить команду newaliases. Ее легко запомнить, не так ли?
А какую команду надо выполнить после редактирования файла transports программы Postfix? Возможно, newtransports? Нет, это было бы слишком просто. Вы должны выполнить postmap transports. А еще есть команда т4, которую нужно выполнить после редактирования m4-фай- лов и т. д., и т. п.
Как обратиться к нужному серверу с помощью SSH
Предположим, у вас три сервера: serverl.example.com, server2.ex- ample.com и server3.example.com. На них расположено много вебсайтов, и вам трудно запомнить, какой сайт на каком сервере. Где находится сайт www.everythingsysadmin.com- на первом или третьем сервере? Вы думаете, что на третьем, но не исключено, что его перенесли на второй из-за нехватки места на диске. Зачем вообще все это запоминать? Нет никакой необходимости редактировать файл конфигурации. Просто укажите имя хоста веб-сайта в команде SSH! Например, введите ssh www everythingsysadmin. com, и вы окажетесь на нужном сервере. Это довольно очевидно, но вы не поверите, как часто люди забывают о такой возможности!
У кого найдется время заучить все команды, которые нужно выполнить после редактирования файлов? Такие подробности должен помнить сам компьютер.
а
щ л*
На помощь приходит команда make! Вы можете считать ее программным инструментом, чем-то вроде компилятора. Она позволяет вам указать, какую команду нужно запускать для обновления одного файла, если в другой были внесены изменения.
Команда make является одним из самых мощных инструментов системного администрирования, которые когда-либо были изобретены. Я слышал, что программисты тоже считают ее полезной!
У команды make больше функциональных возможностей, чем было мужей у Элизабет Тейлор, поэтому я лишь вкратце представлю ее вам. (Прочитав только первые две главы практически любой книги, посвященной команде make, вы узнаете 99% того, что необходимо для большинства задач системного администрирования, и в 10 раз больше, чем знают коллеги.)
Краткое описание команды make
Команда make читает файл конфигурации, весьма уместно именуемый Makefile. В этом файле находятся инструкции, которые сообщают команде make, что она должна делать.
Каждая инструкция имеет такой формат:
whole: partA partB partC команда, создающая whole
Инструкция начинается с имени файла, который должен быть создан. Затем стоит двоеточие, после которого указаны файлы, необходимые для построения главного.1 В этом примере создается файл whole, и устанавливается соотношение между partA, partB и partC. Если один из них будет отредактирован, мы должны будем выполнить команду, создающую whole.
Приведу вполне реальный пример:
aliases.db: aliases newaliases
tectio Done updating aliases
' Традиционная особенность синтаксиса команды make состоит в том, что имена файлов, следующие за двоеточием, и отступы командных строк должны отделяться одним или несколькими символами табуляции, но ни в коем случае не пробелами; на распечатке они неразличимы, на это многие «попадались»; см. далее у автора. - Примеч. науч.ред.
Этот код означает, что, если файл aliases будет изменен, команда new- aliases регенерирует файл aliases.db. В случае успеха будет выведено сообщение «Done updating aliases» (Выполнено обновление aliases).
Обратите внимание на то, что вторая и третья строчки кода написаны с отступом. Отступ обязательно достигается табуляцией, а не последовательностью пробелов. Почему? Наверное, создатель команды make хотел наказать меня за каждую попытку скопировать участок кода в системе, преобразующей табуляцию в пробелы. Впрочем, я не принимаю это на свой счет.
Обновление файла не происходит автоматически. Вы должны только запустить команду make:
Достарыңызбен бөлісу: |