Хватит работать сверхурочно, пора работать рационально для системных администраторов


Простые задачи, выполняемые часто



бет15/20
Дата25.07.2016
өлшемі2.53 Mb.
#220661
1   ...   12   13   14   15   16   17   18   19   20
Простые задачи, выполняемые часто. Третья категория - очевид­ный случай, здесь отдача от автоматизации будет максимальной. Время, потраченное вами на автоматизацию процедуры, вскоре окупится, потому что вы будете выполнять задачу снова и снова. Всегда автоматизируйте скучные и повторяющиеся дела.

  • Сложные задачи, выполняемые часто. Четвертая категория - ло­вушка для системных администраторов, которые часто взваливают на себя больше, чем могут нести. Эта категория требует, чтобы вы убедили руководство в необходимости выделить ресурсы (время и деньги) на решение проблемы. Результатом может быть покупка коммерческого программного продукта, интеграция бесплатных инструментов и/или инструментов с открытым кодом в вашу систе­му или разработка собственного решения.

Теперь, специально для читателей, мыслящих зрительными образа­ми, приведу эти категории в виде таблицы (рис. 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. Ее легко запомнить, не так ли?

А какую команду надо выполнить после редактирования файла trans­ports программы 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:


Достарыңызбен бөлісу:
1   ...   12   13   14   15   16   17   18   19   20




©dereksiz.org 2024
әкімшілігінің қараңыз

    Басты бет