Ошибка: Failed to parse the Currency Converter XML document.
$17 786.09
|
Ошибка: Failed to parse the Currency Converter XML document.
$52 217.95
|
Ошибка: Failed to parse the Currency Converter XML document.
$1 436.63
|
Unix-сервер: Установка и настройка
Несмотря на то, что для полного описания установки и настройки операционной системы и серверного ПО нужна целая книга, эта статья поможет вам увидеть основные сложности процесса и покажет последовательность действий для успешного выполнения задачи. Здесь описан процесс установки и настройки FreeBSD, тем не менее, этот же подход можно применить к любой другой операционной системе.
Планирование процесса установки
Являясь среднестатистическим пользователем open-source программного обеспечения, вы наверняка проводите много времени, устанавливая, переустанавливая и удаляя различные программы. Причем первым шагом обычно является выяснение возможностей самой операционной системы. Однако при работе с «боевыми» серверами вы не можете позволить себе проводить эксперименты с системой.
Без преувеличения можно сказать, что процесс установки операционной системы и программного обеспечения на сервер на 99% состоит из подготовительных мероприятий. Конечно, можно ограничиться экспресс-установкой системы и использовать настройки программ по умолчанию. Но в таком случае вам или тем людям, которые будут сопровождать систему после вас, придется столкнуться с массой неприятностей, вызванных таким легкомысленным подходом к установке и настройке.
Вы можете избежать многих проблем в дальнейшем, если в самом начале проясните потребности компании-заказчика. Вы должны понимать, что от вас требуется, а заказчик должен осознавать, какие из его потребностей могут быть технически осуществимы. Чтобы не получилось такой ситуации, когда после долгой и тщательной настройки Apache2, вдруг выясняется, что любимая программа шефа работает только с Apache 1.x. Так уж сложилось, что задачи и потребности руководства компании и сисадмина не всегда совпадают, поэтому терпеливо и последовательно пройдите стадию подготовки.
Наконец, вы должны объяснить руководству, что сервер -- это не обычный компьютер, на него нельзя устанавливать программы лишь потому, что кто-то хочет проверить, как работает какая-нибудь новая программка. Перечень устанавливаемого программного обеспечения должен быть четко очерчен и оформлен на бумаге.
Установка
После того, как перечень устанавливаемых программ определен, наступает стадия проектирования. Во-первых, нужно определиться с тем, будут ли все службы работать на одном сервере или для каждой основной задачи будет предусмотрен отдельный сервер. Это обычно зависит от политики безопасности компании, доступных аппаратных средств и суммы денег, выделенной на закупку дополнительного оборудования.
Во-вторых, для каждого сервера заведите отдельную папку (журнал сервера), в которую вы будете записывать или подшивать всю важную информацию, связанную с установкой операционной системы и соответствующего программного обеспечения на конкретный сервер. И не пытайтесь обмануть себя, думая, что сделаете все записи потом, когда будет время. Даже если у вас действительно появится свободная минутка, вы не вспомните и половины вещей, которые проделали, настраивая сервер, особенно если вы делали это ночью и в спешке, чтобы успеть закончить до начала рабочего дня.
В-третьих, определитесь с тем, будете ли вы устанавливать операционную систему (в нашем случае FreeBSD) с CD-диска, или загрузитесь с двух дискет и продолжите установку через Интернет. Если выход в Интернет не защищен фаерволом, лучше купить FreeBSD на CD-дисках или самому скачать образы дисков и записать их на болванки. Правило Номер Один гласит -- во время установки операционной системы сервер НЕ ДОЛЖЕН быть доступен извне до тех пор, пока не произведены все необходимые настройки безопасности. Это значит, что обязательно нужен фаервол. Причем настройка правил, регулирующих доступ к серверу, не должна проводится до тех пор, пока сервер не настроен. Разумнее будет временно открыть доступ к серверу только для одного определенного узла.
Первый важный шаг при установке системы -- разделение дискового пространства, выделенного операционной системе, на разделы (partitions). Имейте ввиду, что предлагаемый вариант по умолчанию не очень подходит для сервера.
Например, для моего десктопа программа установки предлагает следующий вариант:
256 MB /
622 MB swap
256 MB /var
256 MB /tmp
13261 MB /usr
Все разделы, за исключением раздела подкачки, получились равными 256 Мб, а остаток достался /usr. Это совершенно неприемлемо для сервера. Если вы предполагаете установить web-сервер, ftp-сервер и почтовый сервер, их работа будет фиксироваться в логах, обычно располагающихся в /var. Поэтому 256 Мб, выделяемых по умолчанию, будет недостаточно. Причем ситуация усугубляется еще и тем, что почтовый сервер хранит все письма в /var/mail. В зависимости от назначения сервера, раздел /usr также может потребовать много места, так как в нем находятся пользовательские директории и установленное программное обеспечение.
Если только у вас нет причин поступать по-своему, рекомендуется оставить размер /, swap и /tmp по умолчанию, а остаток диска распределить между /usr и /var. В идеале, я предпочитаю использовать два жестких диска: /usr занимает остаток первого диска, а /var -- весь второй диск.
Примечание: Все-таки не могу не сделать пару замечаний. Во-первых, все прогрессивное человечество предпочитает иметь отдельный раздел /home для директорий пользователей, если таковых будет действительно много. И бэкапить удобно, и опции монтирования можно установить построже для обеспечения большей безопасности. Во-вторых, при использовании двух дисков своп-разделы рекомендуется создавать на каждом.
Еще одним моментом, на который нужно обратить внимание, является количество свободных индексных дескрипторов файлов (inodes). Каждому разделу соответствует ограниченное количество индексных дескрипторов. Если свободных индексных дескрипторов не останется, вы не сможете создать файлы в этом разделе, не удалив перед этим ненужные файлы или заново не проинициализировав файловую систему с помощью newfs. В большинстве случаев настройки по умолчанию обеспечивают достаточное количество индексных дескрипторов, если только вы не храните огромное число очень маленьких файлов. Существует скрипт /etc/periodic/daily/400.status-disks, который ежедневно отправляет в почтовый ящик суперпользователя вывод команды df об использовании примонтированных разделов. После установки системы нужно подредактировать скрипт, добавив после df опции -hi. Теперь вы будете ежедневно получать информацию о наличии свободного дискового пространства с указанием объема не в блоках, а в байтах (кило-, мега- и гигабайтах), а также сведения о количестве занятых и свободных индексных дескрипторов.
Программа установки (в нашем случае sysinstall) также спросит у вас, какие компоненты системы устанавливать. Что касается серверов, я являюсь сторонником подхода «устанавливайте самое необходимое, затем добавляйте то, что вам еще нужно». Мне кажется это намного логичнее, чем «устанавливайте все по максимуму, а потом удаляйте ненужные программы». В данном случае мой подход означает, что я НЕ устанавливаю docs, manpages, games. Ведь у меня всегда будет возможность соединиться с другой системой, если понадобиться что-то найти в документации. В то же время, я устанавливаю src для того, чтобы перекомпилировать ядро и всю систему для оптимизации под конкретные серверные задачи.
Я также придерживаюсь мнения, что Иксам не место на сервере. Сервер это аскетичная отимизированная система, рассчитанная на максимальную надежность и производительность, без всяких красивостей, излишеств и дополнительных потенциальных уязвимостей, которые присущи GUI-приложениям. Вместо этого, если я знаю, что админить сервер будет несколько человек, я устанавливаю /usr/ports/sysutils/webmin и /usr/ports/sysutils/usermin. Эти приложения имеют возможность разграничить доступ для каждого админа, ограничившись лишь теми службами, за которые он персонально отвечает. Плюсом этих приложений является GUI-интерфейс и доступ к системе из вашего любимого браузера.
Устанавливая программы на сервер, вам наверняка захочется иметь возможность легко обновлять их. Хотя мне очень нравится система портов, я не устанавливаю порты на сервер, так как могу найти иное применение почти полугигабайту дискового пространства на разделе /usr. Это означает, что я также не буду использовать portupgrade для обновления программ. Вместо этого я продемонстрирую вам, как в этом случае можно обойтись утилитой porteasy.
Постинсталляционная настройка
Когда установка благополучно завершается, наступает стадия постинсталляционной настройки системы. Одно за другим появляются меню различных настроек. Когда система предложит создать нового пользователя, убедитесь что вы задали для него надежный пароль. Еще более надежный пароль следует предусмотреть для суперпользователя. Когда будет предложено установить программы, ответьте положительно, чтобы можно было установить cvsup-without-gui и porteasy из пакетов.
После того, как свежепоставленная система перезагрузится, я первым делом запускаю cvsup для получения самых последних изменений в коде системы, сделанных после выхода релиза.
После установки системы я сразу же беру в руки журнал сервера. До этого момента я делала лишь краткие заметки от руки, касающиеся сетевых настроек и размеров разделов. Однако, учитывая то, что даже я сама иногда с трудом разбираю то, что написала, просто необходимо иметь всю информацию в печатном виде. В этом нам поможет утилита scp (secure copy). Я проверяю, запущен ли sshd на другой машине с подключенным принтером и копирую туда информацию о серверном железе:
% scp /var/run/dmesg.boot dru@192.168.1.10:/usr/home/dru
Эта команда соединится с SSH-даемоном на узле 192.168.1.10, залогинится под именем пользователя «dru» и скопирует файл /var/run/dmesg.boot с сервера в мой домашний каталог на другой машине. Как вы заметили, scp работает также как cp, но позволяет скопировать файл на удаленную систему или с удаленной системы.
Затем я копирую
- настройки сетевого адаптера:
% ifconfig > nic_settings && scp nic_settings dru@192.168.1.10:/usr/home/dru
- настройки шлюза по умолчанию:
% netstat -rn > gateway && scp gateway dru@192.168.1.10:/usr/home/dru
- настройки DNS:
% scp /etc/resolv.conf dru@192.168.1.10:/usr/home/dru
- а также информацию о разделах и свопе:
% df -h > disk_usage && scp disk_usage dru@192.168.1.10:/usr/home/dru
% swapinfo > swap_usage && scp swap_usage dru@192.168.1.10:/usr/home/dru
После этого я распечатываю эти файлы с другого компьютера и подшиваю их в журнал сервера.
Защищаем OS
Теперь пора заняться безопасностью системы. Вначале я создаю /root/cvs-supfile следующего содержания:
----------------------------------------------------------------------
*default host=cvsup.ca.freebsd.org
*default base=/usr/local/etc/cvsup
*default prefix=/usr
*default tag=RELENG_5_2_1_RELEASE
*default release=cvs delete use-rel-suffix compress
src-all
----------------------------------------------------------------------
В строке host= лучше указать тот cvsup-сервер, который географически ближе всех к вам. Также убедитесь, что используете в строчке tag= именно тот тэг, который соответствует вашей ОС. (Подробнее смотрите Руководство FreeBSD (aka Handbook), Приложение A.6.).
Примечание: Во-первых, видимо автор статьи имела ввиду tag=RELENG_5_2, так как патчи выпускаются именно для ветвей, а не релизов. Во-вторых, будет лучше, если вы точно установите, какой cvsup-сервер является самым быстрым в вашем случае. Например, с помощью утилиты fastest_cvsup, которая имеется в портах.
Создаем служебный каталог для cvsup и запускаем программу:
# mkdir /usr/local/etc/cvsup
# cvsup -L 2 /root/cvs-supfile
Пока идет обновление исходников системы, решаем вопросы безопасности системы. О многом я уже писала ранее в статье «Securing FreeBSD». Я также настраиваю SSH на сервере с использованием опции AllowUsers, чтобы ограничить доступ к серверу по SSH, разрешив соединение для себя и других уполномоченных администраторов.
По окончанию загрузки приступаем к перестройки всей системы и ядра (на этой стадии пока используем GENERIC):
# cd /usr/src
# make buildworld
# make buildkernel KERNCONF=GENERIC
# make installkernel KERNCONF=GENERIC
# make installworld
Примечание: Во-первых, приведенная последовательность действий не является примером правильной процедуры пересборки системы и ядра. Правильная последовательность приводится в Хэндбуке и в файле /usr/src/Makefile. Во-вторых, когда собираете ядро GENERIC, KERNCONF= можно не указывать. По умолчанию как раз предполагается GENERIC.
После перезагрузки можно приступать к оптимизации ядра. Я делаю копию файла /usr/src/sys/i386/conf/GENERIC и просматриваю его построчно, удаляя те строки, которые относятся к неиспользуемому в нашем случае железу и ненужным опциям. Затем внимательно изучаю файл NOTES (или LINT) на предмет дополнительных опций для повышения безопасности и производительности сервера. Кое-что полезное вы можете почерпнуть из статьи, написанной Эвлином Вигом (Avleen Vig), посвященной тонкой настройки FreeBSD для разных приложений.
Следующий шаг компиляция, установка нового ядра с последующей перезагрузкой. Если с ядром все в порядке, распечатываем его конфигурационный файл с комментрариями по поводу каждой добавленной опции и подклеиваем это в журнал сервера. Обычно я также копирую конфигурационный файл в другое место на диске, например в /usr/local/etc. После этого можно удалить каталог /usr/src, освободив тем самым 400 MB дискового пространства. Однако /usr/src может понадобиться в случае выхода Security Advisories, устраняющих проблемы с безопасностью системы. Так что вам решать -- удалять исходники системы или нет.
Установка программного обеспечения
Теперь, когда у вас обновленная система с оптимизированным ядром, самое время начать установку программ. Конечно можно ограничиться использованием команды pkg_add -r для установки пакетов, однако это не лучший способ для сервера. Также не совсем правильным является установка программ из портов вслепую, без предварительного прочтения Makefile и инструкций по установке с официального сайта программного продукта. Известно, что при компиляции серверных приложений существует возможность указывать массу опций команды make, которые определяют дальнейшую работу и производительность программы. Еще до компиляции вы должны четко представлять себе какие опции возможны и какие вам следует использовать. В этом случае действует правило «99% подготовки, 1% настройки».
Это правило подводит нас к составлению серверной документации. После установки программы распечатайте или запишите в журнал опции компиляции. Вот, к примеру, два фрагмента моих записей:
#installed from /usr/ports/www/apache2
#use «make show-options» to see available make options
#use «make show-modules» to see available modules
#use anon auth and disable SSI and autoindexing:
make -DWITHOUT_AUTH -DWITHOUT_MODULES=«autoindex»
-DWITHOUT_MODULES=«include» install clean
#installed from /usr/ports/ftp/pure-ftpd
#install as stand-alone server with privilege separation
make -DWITH-PRIVSEP -DWITHOUT-INETD install clean
В этом случае вам не придется запоминать, какие опции вы использовали при компиляции программ, что поможет вам при их настройке и обновлении.
Возникает вопрос -- как же мне удалось заполучить директорию ports/ftp/pure-ftpd и ports/www/apache2, если я не устанавливала порты? Вот для этого и нужна утилита porteasy: она загружает только директории тех портов, которые понадобятся в конкретном случае. Чтобы это сделать, понадобиться сначала сообщить cvs, откуда брать исходники портов:
[list]# setenv CVSROOT :pserver:anoncvs@anoncvs.at.FreeBSD.org/home/ncvs
# touch /root/.cvspass[list]
После этого, так как нам нужна директория порта apache2, сообщаем porteasy, что конкретно мы хотим достать из cvs-хранилища:
# porteasy -u www/apache2
Вот и все -- мы получили все удобство системы портов без необходимости устанавливать сами порты.
Примечание: Наверное я не до конца понял всю глубину этой идеи, но мне кажется, что таким образом можно создать себе дополнительные проблемы. Может быть проще все-таки установить порты ?
Обновление программного обеспечения на сервере
Утилита porteasy также понадобится нам для поддержания программ в актуальном состоянии. Для этого у меня есть такой скрипт:
--------------------------------------------------------
#!/bin/sh
echo «Updating installed ports skeletons»
porteasy -uI
echo «The following ports need upgrading:»
porteasy -s |grep «<»
--------------------------------------------------------
Обратите внимание, что этот скрипт обеспечит поддержание портов в актуальном состоянии и сообщит обо всех портах, требующих обновления. Однако он не обеспечивает сам процесс обновления. Такой подход очень удобен для серверов, на которых нельзя обновлять программы просто так, без предварительной подготовки. В нашем случае требуется тщательно продумать процесс обновления, изучить все изменения в новой версии программы и то, как эти изменения могут повлиять на ее работу, выбрать время для обновления, когда с сервером работает минимальное количество людей и в случае непредвиденной ситуации потери будут небольшими. Короче говоря, читайте доки, они рулезз (тем более, что в документации к серьезным программам есть раздел «Обновление» (Upgrading), а с новыми версиями всегда идут файлы UPDATING и/или README).
Заключительное слово о настройке приложений
Настройка -- процесс во многом индивидуальный для каждой отдельной программы. К счастью, большинство из основных серверных приложений располагают исчерпывающей документацией на официальных сайтах. Иногда документация настолько подробная, что поначалу в ней даже сложно разобраться.
Если вы в первый раз сталкиваетесь с какой-либо серьезной и сложной программой вроде вэб-сервера или почтового сервера, никогда не начинайте установку программы, не ознакомившись предварительно с документацией. Многое из того, что вы прочитаете, не пригодится в процессе установки и настройки, но вы хотя бы узнаете, какие опции есть у программы, как они отражаются на ее настройке и работе. Вполне вероятно, что вы захотите распечатать некоторые важные моменты, найденные в документации, и подклеить это в журнал сервера, по крайней мере на то время, пока вы не очень хорошо ориентируетесь в программе.
Я всегда распечатываю исходные конфигурационные файлы, которые создаются при установке программы и сохраняю их в журнале сервера. В таком случае удобно записывать в распечатке те изменения, которые проделываются с фконфигурационными файлами, сопровождая их комментариями. Другой способ заключается в комментировании изменений в самом файле и распечатке итоговой его версии. В любом случае у вас остается бумажная копия всех основных настроек. Естественно, это никоим образом не освобождает вас от необходимости имееть под рукой бэкап первоначальных и текущих версий конфигурационных файлов.
PS: Если вам покажется, что эта статья ни о чем то так оно и есть.
На самом деле всю статью можно сформулировать гораздо короче. А именно:
«Поспешишь -- людей насмешишь»
«Семь раз отмерь -- один отрежь»
«Читайте доки -- они рулезз»
плюс еще что-то вроде «Сделал дело -- подшей бумажку в папку»
Правда есть надежда, что статья все-таки кому-нибудь поможет.